User:Maartenvandewaarsenburg/sandbox

Software Component Lifecycle Management (SCLM) relates to software products as Product Lifecycle Management (PLM) relates to hardware products. SCLM is a supporting discipline in the Application Lifecycle Management (ALM) chain. An SCLM system, which would be an implementation of SCLM, will typically integrate with (not limited to) architectural design tools on the one side and with Continuous Integration (CI) and Revision Control systems on the other side.

Definition
SCLM is the administration of components that software products comprise of. Components1,2, in the context of this article, are the distinguishable pieces of software that are used within a given software product. The software product itself is also considered to be a component.

Administration
As SCLM is the administration of components, data of the individual components is recorded in it. The items in the list are not meant to be conclusive nor mandatory.
 * Origin (see the list below)
 * Version and how it relates to its predecessor
 * Compatibility and incompatibility with regard to its predecessor
 * Relations to other (versions of) components
 * Used interfaces
 * Phase in the lifecycle and the history of phase changes, for example:
 * Concept
 * Work
 * Test
 * Released
 * End-Of-Life
 * Applicable platform, e.g. Windows, Linux, OSX, 32 or 64 bits et cetera
 * Build artifacts
 * Build log
 * Binaries e.g. .bin, .dll, .exe, .msi, image of CD or DVD, artwork et cetera
 * Test artifacts e.g. reports on:
 * Smoke tests
 * Module tests
 * Integration tests
 * Stress tests
 * Endurance tests
 * License information
 * Manuals
 * Documentation
 * Release notes / reason for creation of a new version
 * Paper trail (incoming and outgoing documents with regard to the component)
 * Owner
 * et cetera

Configuration management
The configurations (e.g. build machines and development work stations) and tools (e.g. compilers, text editors, IDE's, drawing tools, code analyzers et cetera) involved in the process to create a software product could also considered to be components.

A build machine can then be linked to the components that are built on it. Equally to any component, a build machine can be versioned in order to capture its status (e.g. operating system, service packs, tools installed et cetera).

(In)visibility of components
A well known practice at system design time is "separation of concerns". Each component (components and concerns are equivalent in the context of this article) concentrates on its own concern, hiding its complexity (e.g. robot arm movement, data processing, calculations et cetera) from other parts of the system. Too complex components will be subdivided into more fine granular components until there are no "concerns" left, resulting in a hierarchy of components.

The work, implementing the design in software, is divided among one or more development teams that cover one or more of the required disciplines. It is also possible that parts of the system are implemented by contractors. Eventually, the system can contain software that, besides created by yourself, originates from:
 * Contractors
 * Commercial, e.g. off-the-shelve software products
 * Public domain, e.g. open source packages like being used by package managers in Linux distributions or other package managers like Maven
 * Customers, e.g. in case of software integration
 * Libraries and utilities of for example SDKs
 * et cetera

In nearly 100% of the cases a revision control system is used to bring the work of all contributors together. In the revision control system, a directory structure is created that may or may not have the same hierarchy as the fore mentioned hierarchy of components.

Revision control systems however are not designed to identify these "separate concerns" nor to guard over their separation.

Consequently, the visibility of components from outside the revision control system is lost. Therefore, the potential to contribute to the business' information is missed.

Business Information
The administration provided by SCLM is a powerful source of information and therefore contributes to business information. Some examples follow.
 * As all relations between (versions of) components are known within the SCLM administration, it is possible to create a "Bill-Of-Material" (BOM) on each (version of a) component. A Bill-Of-Material is a list of all the components that are used.
 * When the support period of a product ends and its status changes to End-Of-Life, you can bring all components belonging to its hierarchy, which are not used in other products that are still supported, to End-Of-Life also. You might save on license fees that you pay for tools and 3rd party components that are marked End-Of-Life by this.
 * When a product is going to be released, it is required that all components on the Bill-Of-Material have the "released" status as well and that none of them is marked as End-Of-Life.
 * When a component in one of your released software products is proven to have an error in it, you can invalidate (force it to End-Of-Life) that particular (version of that) component. As a consequence, all components that have this erroneous component on their Bill-Of-Material should be invalidated as well, resulting in which corrective measures to take with regard to release management.
 * When a new version of a component is marked incompatible, on one or more of its interfaces, with its predecessor, all components sharing these interfaces must be changed as well to make them compatible again.

Efficiency
There are 2 aspects regarding efficiency that need to be emphasized.
 * Re-use
 * Build and test time

Use of lifecycle management
Hardware manufacturers can and will be held liable for damage that is caused by their products or parts (components) of their products, even if it is caused by a part that has been produced by a 3rd party. It is of utmost importance to them to know every aspect of their products. Without lifecycle management systems this would not be possible.

Software manufacturers often do not consider themselves responsible for the correct working of their products. The following text could be a perfectly "acceptable" disclaimer in a software license agreement. LICENSOR PROVIDES THE LICENSED SOFTWARE "AS IS" WITH NO WARRANTIES AS TO THE FUNCTION OR USE OF IT, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LICENSED SOFTWARE IS WITH LICENSEE. LICENSOR DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE LICENSED SOFTWARE WILL MEET LICENSEE'S REQUIREMENTS OR THAT THE OPERATION OF THE LICENSED SOFTWARE WILL BE UNINTERRUPTED OR ERROR FREE. Software manufacturers therefore do not feel the need for lifecycle management.