Software Configuration Management (SCM)

1. Software Configuration Management (SCM)

2. Product Integrity As software becomes more and more complex we need to ensure that software developed has the following characteristics: • fulfills user functional needs. • can easily and completely be traced through its life cycle. • meets specified performance criteria. • meets cost expectations. • meets delivery expectations.

3. Product Developer Disciplines When developing a system, developers structure themselves into three discipline sets. • Project Management • Development • Product Assurance

4. Product Developer Disciplines When developing a system, developers structure themselves into three discipline sets. • Project Management • Assignment of resources • Allocation of resources • Control of resources • Development • Product Assurance

5. Product Developer Disciplines When developing a system, developers structure themselves into three discipline sets. • Project Management • Development • Elicitation • Design • Implementation • Product Assurance

6. Product Developer Disciplines When developing a system, developers structure themselves into three discipline sets. • Project Management • Development • Product Assurance • quality assurance • validation and verification • test and evaluation • configuration management

7. Configuration Management Definition: The discipline of identifying the configuration of a system at discrete points in time for the purpose of systematically controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system’s life cycle.

8. Configuration Item (CI) A system component or artifact: • design document • source code module • test suite • ... In the case of software, they are called Software Configuration Items (SCI).

9. System Configuration A set of system configuration items • sometimes referred to as a version of a system.

10. Software Configuration Management A set of procedures that tracks: • Requirements that define what the system should do. • Design modules that are generated from requirements. • Program code that implements the design. • Tests that verify the functionality of the system. • Documents that describe the system.

11. Elements of SCM There are four elements of SCM: • Software Configuration Identification. • Software Configuration Control. • Software Configuration Auditing. • Software Configuration Status Accounting.

12. Software Configuration Identification Provides labels for the baselines and their updates. Baseline: • stable snapshot of the aggregate system components as they exist at a given point in time • a configuration or version that has been verified and released

13. Software Configuration Identification First identify the elements that will make up a configuration. software == SRS + design + tests + code + … An early configuration may only have a few configuration items (e.g. requirements)

14. Software Configuration Identification • Identify a labeling scheme for baselines • Identify a labeling scheme for updates to baselines Example: HATS GUI 1.4 Baseline: 1.0 4 updates to baseline 1.0 Next Baseline: 2.0

15. Software Configuration Control • Provides a mechanism for precipitating, preparing, evaluating, and approving or disapproving all change proposals throughout the life cycle.

16. Software Configuration Control Three basic ingredients to SCC • Documentation for formally precipitating and defining a proposed change to a software system. • An organizational body (Configuration Control Board) for formally evaluating and approving or disapproving a proposed change to a software system. • Procedures for controlling changes to a software system.

17. Software Configuration Control Why needed? • Not all possible changes are beneficial. • Need a mechanism to control access to different items of the configuration. • Example: We don’t want everyone to be accessing everyone else’s code and be able to make changes. • other example?

18. Software Configuration Auditing Activity performed to independently evaluate the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures.

19. Software Configuration Auditing • Determines the extent to which an item satisfies the required functional and physical characteristics • Can be conducted at key points in the life cycle • Two types of formal audits might be required • Functional Configuration Audit (FCA) • Physical Configuration Audit (PCA)

20. FCA • Purpose: ensure that the audited software item is consistent with its governing specifications • Output of the software verification and validation activities is a key input to this audit

21. PCA • Purpose: ensure that the design and reference documentation is consistent with the as-built software product

22. Software Configuration Auditing Why needed? • We need to ensure that changes are correct according to specifications and to the customer. We can approve good changes but if it is not what the customer wants then it is useless. • If we never establish a baseline then we can’t proceed with the development of the system.

23. Software Configuration Status Accounting • Provides a mechanism for maintaining a record of where the system is at any point with respect to what appears in published baseline documentation. • When a change proposal is approved it may take some time before the change is initiated or completed.

24. Software Configuration Status Accounting • Why needed? • We need to ensure that there is progress within the development of the project. • Updates to baselines must take place sometime, otherwise we can’t continue.

25. Source Code Control • Version control, revision control, source code management • CVS • SVN • Visual Source Safe

26. Source Code Control • Goals: • Manage source code for multiple users • Serve as repository of work • Prevent collisions

27. SVN • Assignment: • Find out about SVN • Write a 1-2 paragraph description of SVN • Describe the use of the SVN commands for checkout, update, add, and commit. • Due: Nov. 25.