1 / 33

Chapter 18

Chapter 18. Configuration Management. The Need for Configuration Management.     “What is the correct version of the software module that I have to continue its coding?”    “Who can provide me with an accurate copy of the last year’s version 4.1 of the TMY software package?”

elisa
Download Presentation

Chapter 18

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 18 Configuration Management

  2. The Need for Configuration Management •     “What is the correct version of the software module that I have to continue its coding?” •    “Who can provide me with an accurate copy of the last year’s version 4.1 of the TMY software package?” •    “What version of the design document matches the software version we are adapting to a new customer?” •     “What version of the software system is installed at ABC Industries?” •     “What changes have been introduced in the version installed at the ABC Industries’ site?” •     “What changes have been introduced in the new version of the software?” •     “Where can I find the full list of customers that use version 6.8 of our software?” •     “Can we be sure that the version installed at Top Com Ltd. does not include undocumented changes?” • “Where can I find the full list of customers that use version 6.8 of our software?” • “Can we be sure that the version installed at Top Com Ltd does not include undocumented changes and changes that have not been approved??

  3. Introduction • Typically, active software systems are always in a state of flux. • Changes are the name of the game • Often hundreds of changes (some small, some not) annually! • Need to be able to answer aforementioned questions! • Note: all users of your software may NOT be using the same version! • Must have quality assurance of all changes. • Documented and released versions and installed versions by various users. • Recognize that software systems must be maintained over years! • This is where companies make their money!

  4. Introduction • Software Configuration Management (SCM) is a component of SQA. • SCM deals with issues related to control of software changes, proper documentation of changes, registering and storing the approved software versions, tracking registered versions and more throughout the software system’s life cycle. • SCM is covered in ISO 9000-3 standards as well as in CMM Guidelines among other standards! • We will spend time on CMM (Capability Maturity Model) and ISO (International Standards Organization).

  5. Introduction • Upon completing this chapter, you should be able to: • Define the concept software configuration version. • Explain the objectives of software configuration management • Explain the objectives of software change management • Explain the difference between baseline and intermediate software configuration versions • Explain the objectives of software configuration management plans • Explain the nature of the tasks fulfilled by software configuration management audits. • These are very important concepts to computing professionals!

  6. Software Configuration Management - Definitions • Software Configuration Item(SCI) • An approved unit of software code, a document or piece of hardware that is designed for configuration management and treatedas a distinct entity in the software configuration management process. •  Software Configuration ItemVersion (SCI version) • The approved state of an SCI at any given point of time during the development or maintenance process • Software Configuration Version • An approved selected set of documented SCI versions, that constitute a software system or document at a given point of time, where the activities to be performed are controlled by software configuration management procedures.

  7. Common Types of Software Configuration Items • Almost anything can be a software configuration item. • These are ‘things’ we want to keep track of and control/ • Examples: (normally placed into classes of configured SCIs) • Design documents (development plans, requirements doc, preliminary design, interface design, database description, software test plan, software test procedures, software test reports, software user manuals, software maintenance manuals. Software installation plans, software change requests, software maintenance requests (including problem reports) • Software code •        * Source code •       * Object code • * Prototype software • Data files •        * Test cases and test scripts •        * Parameters, codes, etc. • Software development tools (the versions applied in the development and maintenance stages) •        * Compilers and debuggers •      * Application generators •        *  CASE tools

  8. Example of two softwre configuration versions and the SCIs included in each one. Release and release date Why do you think we have these various version that must be maintained, documented, configured, etc???

  9. Software Configuration Management - Definition • An SQA component responsible for applying (computerized and non-computerized) technical tools and administrative procedures that enablecompletion of the tasks required to maintainSCIs and software configuration versions.

  10. The Tasks of the Software Configuration Management • Components used to control software configurations are usually divided into groups of software capabilities: • *** Control Software Change • *** Release of SCI and Software Configuration Versions • *** Provision of SCM Information Services • *** Verification of compliance to SCM procedures

  11. Tasks of Software Configuration Management (more) • Let’s consider only Software Change Control as an example: • grant approval to carry out changes • control the changes and assure the quality of approved changes • document the approved changes • apply mechanisms that coordinate the changes made to the SCI by preventing more than one item from simultaneously introducing changes into the same SCI • Can readily see this is really software management!

  12. Factors Affecting Approval of Proposed Change • So who oversees implementation of these tasks during software development and/or maintenance? • Usually assigned to senior people or a committee responsible for SCM issues. • Software Change Control  is also usually done by committee, sometimes called a software change control board, or software change authority. • If during development, the project manager may be charged with authority to carry these things out.

  13. Factors to be Considered as to whether to implement the Change: • * Expected contribution of the proposed change •     * Urgency of the change •     * Effect of the proposed change on project timetables, level of service, etc. •     * Efforts required in making the change operational •     * Required software quality assurance efforts • * Estimated required professional resources and cost of performing the change

  14. More Facts • Absolutely tru that once any baseline (or initial version) is installed, changes will begin to flow rapidly! • To control change, we need a coordinated effort by an authorized body to ensure changes follow project or customer priorities • Those factors (previous slide) must be considered! • Despite perceived urgency, changes are not necessarily always approved! • Must ensure high quality of each changed SCI, and • Must ensure high quality of the entire new version that includes the changes SCIs.

  15. The Need to Release a New Software Configuration Version So, why do we release new versions of software? 1. Defective SCIs 2. Special features demanded by new customers 3. Team’s initiatives to introduce SCI improvements

  16. Three Main Types of Releases: • Baseline versions • Intermediate versions, and • Revisions • They are all quite different and serve different needs.

  17. Baseline Versions • These are the bigges. • Planned early • Reviewed, tested, and approved with all their SCIs too. • These are milestone in the software system’s life cycle. • These are the major releases! • Usually have major changes or upgrades or enhancements.

  18. Intermediate Versions • Usually designed to address immediate problems as to correct defects in an important SCI or to include an immediate adaptations for a new customer. • This is an intermediate version of the software. • May be done to serve only a small segment of the firm’s clients; perhaps for a limited period until a new baseline is developed. • Does not receive the detailed attention of baselines. • Realize that all clients may not be using the same version of software!! Oftentimes this is the case.

  19. Revisions • Minor changes and corrections. • May include several small changes in a revision • Sometimes we have several small revisions prior to a major baseline release.. • Examples: documentation errors; no show stoppers.

  20. Numbering and Plans • Major baselines (and major SCIs) have whole numbers, such as1.0 or 2.0. • Note: SCIs have their own numbering system too. • We have version and revision numbers, as in 2.3

  21. Software Configuration Management Plan (SCMP) • Why needed? (Book) • Main objective of an SCMP is to plan ahead the schedule for baseline version releases and the required resources to carry out all the activities required for the software configuration releases. • An additional objective is to enable one to follow up the progress of activities involved in software version release. • SCMP are needed for development as well as operations (maintenance).

  22. Software Configuration Management Plan (SCMP) • The plan includes: • *A list of scheduled baseline version releases. • * A list of SCIs (documents, code, etc.) to be included in each version. • *A table identifying the relationship of software development project plans and maintenance plans to scheduled releases of new SCIs or SCI versions. • *A list of assumptions about the resources required to perform the SCMP. • * Estimates of the human resources and budget needed to perform the SCMP.

  23. SCMP for Development • Based on the project plan, the SCMP sets the release dates of baseline versions, which usually coincide with the conclusion of one or more of the following three events: • The design stage • The coding stage • The system test stage. • All of the instructions and procedures necessary for performing SCM tasks at this stage are documented in the SCMP. • The project manager is usually the person responsible for carrying out these tasks.

  24. SCMP for Maintenance • During maintenance, further releases of baseline versions are necessary to deploy imporved software versions after accumulation of SCI changes made during regular customer use. • Often, the releases are annual, semi-annually, or according to the anticipated number of accumulated changes in SCIs. • Periodic releases contain corrections as well as new versions of SCIs. • As in development plans, all the instructions and procedures for performing SCM tsks during operations / maintenance are likewise documented in the respective SCMP. • Maintenance SCMPs may be incorporated in the comprehensive SCMP for the system’s entire life cycle..

  25. Documentation of Software Configuration Versions • It is the responsibility of the project manager to ensure all of the documentation tasks are performed. • This includes documentation of the SCI versions and documentation of the software configuration releases (versions and revisions) • Lots of detailed information must be accommodated. • Frame 18.5 in your book lists those documentation items required for SCIs. • Frame 18.6 (next slides) presents those information items needed in software configuration releases. • These are often referred to as Version Description Documents:

  26. Software Configuration Release Documentation VDD Template • a. Identification and installations • *Release version and revision number, including date • * List of installations where the release was installed • b. Configuration of the released version • * List of SCIs (including SCI’s version) in the released software version • * List of hardware configuration items required for operating the specified version • * List of interfacing software and hardware systems • * Installation instructions for the new release • (Honeywell 6080s, 6060s, at different sites….)

  27. Software Configuration Release Documentation VDD Template - cont • C. Changes in the new version • * Previous software configuration version • * List of SCIs that have been changed, new SCIs, and deleted SCIs • * Short description of introduced changes. (may be defects) • * Operational and other implications of changes in the release. • D. Further development issues • * List of software system problems that have not been solved in the new version. • * List of delayed SCRs and proposals for development of the software system.

  28. SCM information Services • Need to provide information to professionals (developers and maintainers and customers who have requested the changes. • Information related to software change control: • * Change request status information  (decisions made) • * Change order progress information  (order for changes, schedule, implementation progress and test results; info on delays too, perhaps)

  29. SCM Information Services • Need to provide information to professionals (developers and maintainers and customers who have requested the changes. • Information about SCIs and software configuration versions: • * Accurate copies of SCI versions (code SCIs, document SCIs, etc.) and entire software configuration versions. • * Full reports of changes between successive releases (versions and/or revisions) of code SCIs and between successive releases of other types of SCIs. • * Copies of SCI version documentation and software configuration version documentation (VDDs). • * Detailed version and revision history for SCIs and software configurations. • * Progress information about planned versions and releases • * Information correlated about versions installed at a given site and about the site itself. • * List where a given software configuration version is installed.

  30. Audits and Accountability • It is all about accountability. • There’s a great variety of tasks by the SCM authority and the Change Control Board (CCB) • There will be audits to ensure SCM procedures have been followed and that internal quality issues have been adhered to. • Samples of change requests, SCIs, and software configuration versions will be carefully audited. • This is part of software development that developers and maintainers do not like, but it is necessary!

  31. Some Sample Audit Items: • Percentage of unapproved changes introduced in the system during development • Percentage of SCOs not carried out according to instructions and not fully complying with procedures • Percentage of design reviews and softwre tests of changed SCIs that have not been performed according to the relevant procedures • Percentage of SCOs that have been completed on schedule. • Percentages of properly documented new SCIs and software configuration versions. • Percentage of cases of failure to transmit all version-related information to the customer • More

  32. Homework – Chapter 18 • Individually, you are to develop answers to the following questions and submit for grading via Blackboard Assignment. • Question 18.4 • Question 18.6

  33. Team Assignment • Question 18.2 (1) and (2) • Question 18.4 • Question 18.6

More Related