Object-Oriented Software Engineering, ch13lect1

1、Chapter 13Configuration ManagementOutline of the LecturePurpose of Software Configuration Management (SCM)Motivation: Why software configuration management?Definition: What is software configuration management?Activities and roles in software configuration managementSome TerminologyConfiguration Ite

2、m, Baseline, SCM Directory, Version, Revision Release.Software Configuration Management ActivitiesPromotion Management, Release Management, Change ManagementOutline of a Software Configuration Management PlansStandards (Example: IEEE 828-1990)Basic elements of IEEE 828-1990Configuration Management T

3、oolsWhy Software Configuration Management ?The problem:Multiple people have to work on software that is changingMore than one version of the software has to be supported:Released systemsCustom configured systems (different functionality)System(s) under developmentSoftware must run on different machi

4、nes and operating systemsNeed for coordinationSoftware Configuration Management manages evolving software systemscontrols the costs involved in making changes to a systemWhat is Software Configuration Management?Definition: A set of management disciplines within the software engineering process to d

5、evelop a baseline.Description:Software Configuration Management encompasses the disciplines and techniques of initiating, evaluating and controlling change to software products during and after the software engineering process.Standards (approved by ANSI)IEEE 828: Software Configuration Management P

6、lansIEEE 1042: Guide to Software Configuration ManagementForward Definition!Software Configuration Management is a Project FunctionSCM is a Project Function (as defined in the SPMP) with the goal to make technical and managerial activities more effective.Software Configuration Management can be admi

7、nistered in several ways:A single software configuration management team for the whole organizationA separate configuration management team for each projectSoftware Configuration Management distributed among the project membersMixture of all of the aboveConfiguration Management ActivitiesSoftware Co

8、nfiguration Management Activities: Configuration item identification Promotion managementRelease managementBranch managementVariant managementChange management No fixed rules: Activities are usually performed in different ways (formally, informally) depending on the project type and life-cycle phase

9、 (research, development, maintenance).Configuration Management Activities (continued)Configuration item identification modeling of the system as a set of evolving componentsPromotion managementis the creation of versions for other developersRelease managementis the creation of versions for the clien

10、ts and usersChange management is the handling, approval and tracking of change requestsBranch managementis the management of concurrent developmentVariant managementis the management of versions intended to coexistThis lectureReadingConfiguration Management RolesConfiguration ManagerResponsible for

11、identifying configuration items. The configuration manager can also be responsible for defining the procedures for creating promotions and releasesChange control board memberResponsible for approving or rejecting change requestsDeveloperCreates promotions triggered by change requests or the normal a

12、ctivities of development. The developer checks in changes and resolves conflictsAuditorResponsible for the selection and evaluation of promotions for release and for ensuring the consistency and completeness of this releaseTerminologyWe will define the following terms Configuration ItemBaselineSCM D

13、irectoriesVersionRevisionReleaseThe definition of the terms follows the IEEE standard. Different configuration management systems may use different terms. Example: CVS configuration management system used in our projects uses terms differeing from the IEEE standard.Terminology: Configuration Item “A

14、n aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process.”all type of code filesdrivers for testsanalysis or design documentsuser or developer manualssystem configurations (e.g. version of com

15、piler used)In some systems, not only software but also hardware configuration items (CPUs, bus speed frequencies) exist!Tasks for the Configuration Managers Define configuration itemsFinding Configuration ItemsLarge projects typically produce thousands of entities (files, documents, data .) which mu

16、st be uniquely identified.Any entity managed in the software engineering process can potentially be brought under configuration management controlBut not every entity needs to be under configuration management control all the time. Two Issues:What: Selection of Configuration ItemsWhat should be unde

17、r configuration control?When: When do you start to place entities under configuration control?Conflict for the Project Manager:Starting with CIs too early introduces too much bureaucracyStarting with CIs too late introduces chaosFinding Configuration Items (continued)Some items must be maintained fo

18、r the lifetime of the software. This includes also the phase, when the software is no longer developed but still in use; perhaps by industrial customers who are expecting proper support for lots of years.An entity naming scheme should be defined so that related documents have related names.Selecting

19、 the right configuration items is a skill that takes practiceVery similar to object modelingUse techniques similar to object modeling for finding Cis!Find the CIsFind relationships between CIsWhich of these Entities should be Configuration Items?Problem Statement Software Project Management Plan (SP

20、MP)Requirements Analysis Document (RAD)System Design Document (SDD)Project Agreement Object Design Document (ODD)Dynamic ModelObject modelFunctional Model Unit testsIntegration test strategySource codeAPI SpecificationInput data and data basesTest planTest dataSupport software (part of the product)S

21、upport software (not part of the product)User manualAdministrator manualPossible Selection of Configuration ItemsProblem Statement Software Project Management Plan (SPMP)Requirements Analysis Document (RAD)System Design Document (SDD)Project Agreement Object Design Document (ODD)Dynamic ModelObject

22、modelFunctional Model Unit testsIntegration test strategySource codeAPI SpecificationInput data and data basesTest planTest dataSupport software (part of the product)Support software (not part of the product)User manualAdministrator manualOnce the Configuration Items are selected, they are usually o

23、rganized in a tree“The project” CIModelsSubsystemsDocumentsObject ModelDynamic ModelDatabaseUser Interface. . . .CodeDataUnit TestRADODD. . . . . . . . . .“The project”Configuration Item Tree (Example) Terminology: Version The initial release or re-release of a configuration item associated with a c

24、omplete compilation or recompilation of the item. Different versions have different functionality.Terminology: Baseline “A specification or product that has been formally reviewed and agreed to by responsible management, that thereafter serves as the basis for further development, and can be changed

25、 only through formal change control procedures.”Examples: Baseline A: All the API have completely been defined; the bodies of the methods are empty.Baseline B: All data access methods are implemented and tested.Baseline C: The GUI is implemented.More on BaselinesAs systems are developed, a series of

26、 baselines is developed, usually after a review (analysis review, design review, code review, system testing, client acceptance, .)Developmental baseline (RAD, SDD, Integration Test, .)Goal: Coordinate engineering activities.Functional baseline (first prototype, alpha release, beta release) Goal: Ge

27、t first customer experiences with functional system.Product baseline (product)Goal: Coordinate sales and customer support.Many naming scheme for baselines exist (1.0, 6.01a, .)A 3 digit scheme is quite common: Release (Customer)Version (Developer)Revision (Developer)Baselines in SCMOfficial ReleaseB

28、aseline A (developmental)Baseline B (functional, first prototype)Baseline C (functional, beta test)How do we manage changes in the baselines?TimeChange managementChange management is the handling of change requestsA change request leads to the creation of a new release General change processThe chan

29、ge is requested (this can be done by anyone including users and developers)The change request is assessed against project goalsFollowing the assessment, the change is accepted or rejectedIf it is accepted, the change is assigned to a developer and implementedThe implemented change is audited.The com

30、plexity of the change management process varies with the project. Small projects can perform change requests informally and fast while complex projects require detailed change request forms and the official approval by one more managers.Two types of controlling change:Promotion: The internal develop

31、ment state of a software is changed.Release: A changed software system is made visible outside the development organization.Approaches for controlling change (Change Policy)Informal (good for research type environments and promotions)Formal approach (good for externally developed CIs and for release

32、s)Controlling ChangesPromotionReleaseSoftware RepositoryUserProgrammerPromotePolicyReleasePolicyMasterDirectoryTerminology: SCM DirectoriesProgrammers Directory (IEEE: Dynamic Library)Library for holding newly created or modified software entities. The programmers workspace is controlled by the prog

33、rammer only.Master Directory (IEEE: Controlled Library)Manages the current baseline(s) and for controlling changes made to them. Entry is controlled, usually after verification. Changes must be authorized.Software Repository (IEEE: Static Library)Archive for the various baselines released for genera

34、l use. Copies of these baselines may be made available to requesting organizations.Foo95Foo98Standard SCM DirectoriesProgrammers Directory (IEEE Std: “Dynamic Library”)Completely under control of one programmer.Master Directory (IEEE Std: “Controlled Library”) Central directory of all promotions.Sof

35、tware Repository(IEEE Std: “Static Library”)Externally released baselines.Central sourcecode archiveReleasePromotion. . . .“The project” CIpromote()release()DocumentsODD“The project” CIModelsSubsystemsObject ModelDynamic ModelDatabaseUser InterfaceCodeDataUnit TestRAD. . . . . . . . . .“The project”

36、Promotion and Release are Operations on CIsLets Create a Model for Configuration Management ReleaseRepositoryPromotionMaster Directory*We just learned that promotions are stored in the master directory and releases are stored in the repository Problem: There can be many promotions and many releases

37、Solution: Use Multiplicity Lets Create a Model for Configuration Management ReleasePromotionRepositoryMaster Directory*Insight: Promotions and Releases are both versions VersionSolution: Use Inheritance Lets Create a Model for Configuration Management ReleasePromotionRepositoryMaster Directory*Probl

38、em: A configuration item has many versionsVersionConfiguration Item*Solution: Create a 1-many association between Configuration Item and VersionLets Create a Model for Configuration Management ReleasePromotionRepositoryMaster Directory*Problem: Configuration items can themselves be groupedVersionSol

39、ution: Use the composite design pattern Configuration Item*Configuration itemControlled itemCM AggregateConfiguration Item Model (UML Class Diagram)Version*Controlled item*CM AggregateConfiguration itemReleasePromotionRepositoryMaster Directory*Change PoliciesWhenever a promotion or a release is per

40、formed, one or more policies apply. The purpose of change policies is to guarantee that each version, revision or release (see next slide) conforms to commonly accepted criteria.Examples for change policies: “No developer is allowed to promote source code which cannot be compiled without errors and

41、warnings.” “No baseline can be released without having been beta-tested by at least 500 external persons.”Terminology: Version vs. Revision vs. Release Version: An initial release or re-release of a configuration item associated with a complete compilation or recompilation of the item. Different ver

42、sions have different functionality.Revision: Change to a version that corrects only errors in the design/code, but does not affect the documented functionality.Release: The formal distribution of an approved version.Question: Is Windows98 a new version or a new revision compared to Windows95 ?Tasks

43、for the Configuration ManagersDefine configuration itemsDefine promote /release policiesSoftware Configuration Management PlanningSoftware configuration management planning starts during the early phases of a project. The outcome of the SCM planning phase is the Software Configuration Management Pla

44、n (SCMP) which might be extended or revised during the rest of the project.The SCMP can either follow a public standard like the IEEE 828, or an internal (e.g. company specific) standard.The Software Configuration Management PlanDefines the types of documents to be managed and a document naming sche

45、me.Defines who takes responsibility for the CM procedures and creation of baselines.Defines policies for change control and version management.Describes the tools which should be used to assist the CM process and any limitations on their use.Defines the configuration management database used to reco

46、rd configuration information.Outline of a Software Configuration Management Plan (SCMP, IEEE 828-1990)1. IntroductionDescribes purpose, scope of application, key terms and references2. Management (WHO?) Identifies the responsibilities and authorities for accomplishing the planned configuration manag

47、ement activities3. Activities (WHAT?)Identifies the activities to be performed in applying to the project.4. Schedule (WHEN?) Establishes the sequence and coordination of the SCM activities with project mile stones.5. Resources (HOW?) Identifies tools and techniques required for the implementation o

48、f the SCMP6. MaintenanceIdentifies activities and responsibilities on how the SCMP will be kept current during the life-cycle of the project.SCMP Section 1: Introduction 1.1 Simplified overview of the configuration management activities.1.2 Scope:Overview description of the projectIdentification of

49、the CI(s) to which software configuration management will be applied.1.3 Identification of other software to be included as part of the SCMP (support software and test software)1.4 Relationship of SCM to hardware of system configuration management activities1.5 Degree of formality and depth of contr

50、ol for applying SCM to project.1.6 Limitations and time constraints for applying SCM to this project1.7 Assumptions that might have an impact on the cost, schedule and ability to perform defined SCM activities.SCMP Section 2: Management2.1 OrganizationOrganizational context (technical and managerial

51、) within which the SCM activities are implemented. IdentifiesAll organizational units (client, developers, managers) that participate in an SCM activity Functional roles of these people within the projectRelationship between organizational units 2.2. ResponsibilitiesFor each SCM activity list the na

52、me or job title to perform this activityFor each board performing SCM activities, listpurpose and objectivesmembership and affiliationsperiod of effectivity, scope of authorityoperational procedures3. Applicable Policies External constraints placed on the SCMPSCMP Section 3: Activities3.1 Configurat

53、ion Identification3.2 Configuration Control3.3 Configuration Status Accounting3.4 Configuration Audits and Reviews3.5 Interface Control3.2 Configuration ControlDefines the following steps3.2.1 How to identify the need for a change (layout of change request form)3.2.2 Analysis and evaluation of a cha

54、nge request3.2.3 Approval or disapproval of a request3.2.4 Verification, implementation and release of a change3.2.1 Change RequestSpecifies the procedures for requesting a change to a baselined CI and the information to be documented:Name(s) and version(s) of the CI(s) where the problem appearsOrig

55、inators name and addressDate of requestIndication of urgencyThe need for the changeDescription of the requested change3.2.2 Evaluation of a ChangeSpecifies the analysis required to determine the impact of proposed changes and the procedure for reviewing the results of the analysis.3.2.3 Change Appro

56、val or DisapprovalThis section of the SCMP describes the organiztion of the configuration control board (CCB).Configuration Control Board (CCB)Can be an individual or a group.Multiple levels of CCBs are also possible, depending on the complexity of the projectMultiple levels of CCBs may be specified

57、. In small development efforts one CCB level is sufficient.This section of the SCMP also indicates the level of authority of the CCB and its responsibility. In particular, the SCMP must specify when the CCB is invoked.3.2.4 Implementing ChangeThis section of the SCMP specifies the activities for ver

58、ifying and implementing an approved change. A completed change request must contain the following information:The original change request(s)The names and versions of the affected configuration itemsVerification date and responsible partyIdentifier of the new versionRelease or installation date and r

59、esponsible partyThis section must also specify activities for Archiving completed change requestsPlanning and control of releasesHow to coordinate multiple changesHow to add new CIs to the configurationHow to deliver a new baseline3.3 Configuration Status AccountingThis section of the SCMP must cont

60、ain the following sectionsWhat elements are to be tracked and reported for baselines and changes?What types of status accounting reports are to be generated? What is their frequency?How is information to be collected, stored and reported?How is access to the configuration management status data cont