Đang tải... (xem toàn văn)
Configuration management
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1Configuration management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 2Objectives To explain the importance of softwareconfiguration management (CM) To describe key CM activities namely CMplanning, change management, versionmanagement and system building To discuss the use of CASE tools to supportconfiguration management processes©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 3Topics covered Configuration management planning Change management Version and release management System building CASE tools for configuration management ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 4 New versions of software systems arecreated as they change:• For different machines/OS;• Offering different functionality;• Tailored for particular user requirements. Configuration management is concernedwith managing evolving software systems:• System change is a team activity;• CM aims to control the costs and effort involvedin making changes to a system.Configuration management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 5Configuration management Involves the development and application ofprocedures and standards to manage anevolving software product. CM may be seen as part of a more generalquality management process. When released to CM, software systems aresometimes called baselines as they are astarting point for further development.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 6System familiesServerversionLinuxversionPC versionInitialsystemDesktopversionWindows XPversionHPversionSunversion ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 7CM standards CM should always be based on a set of standardswhich are applied within an organisation. Standards should define how items are identified,how changes are controlled and how new versionsare managed. Standards may be based on external CM standards(e.g. IEEE standard for CM). Some existing standards are based on a waterfallprocess model - new CM standards are needed forevolutionary development.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 8Concurrent development and testing A time (say 2pm) for delivery of systemcomponents is agreed. A new version of a system is built from thesecomponents by compiling and linking them. This new version is delivered for testingusing pre-defined tests. Faults that are discovered during testing aredocumented and returned to the systemdevelopers.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 9Frequent system building It is easier to find problems that stem fromcomponent interactions early in the process. This encourages thorough unit testing -developers are under pressure not to ‘breakthe build’. A stringent change management process isrequired to keep track of problems that havebeen discovered and repaired. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 10 All products of the software process mayhave to be managed:• Specifications;• Designs;• Programs;• Test data;• User manuals. Thousands of separate documents may begenerated for a large, complex softwaresystem.Configuration management planning©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 11 Defines the types of documents to bemanaged and a document naming scheme. Defines who takes responsibility for the CMprocedures and creation of baselines. Defines policies for change control andversion management. Defines the CM records which must bemaintained.The CM plan©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 12The CM plan Describes the tools which should be used toassist the CM process and any limitations ontheir use. Defines the process of tool use. Defines the CM database used to recordconfiguration information. May include information such as the CM ofexternal software, process auditing, etc. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 13 Large projects typically produce thousands ofdocuments which must be uniquely identified. Some of these documents must be maintained forthe lifetime of the software. Document naming scheme should be definedso that related documents have related names. A hierarchical scheme with multi-level names isprobably the most flexible approach.• PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODEConfiguration item identification©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 14Configuration hierarchyPCL-TOOLSEDITSTRUCTURESBINDFORMCOMPILE MAKE-GENHELPDISP LAY QUERYAST-INTERFACEFORM-SPECS FORM-IOCODEOBJECTS TESTS©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 15 All CM information should be maintained in aconfiguration database. This should allow queries about configurations to beanswered:• Who has a particular system version?• What platform is required for a particular version?• What versions are affected by a change to component X?• How many reported faults in version T? The CM database should preferably be linked to thesoftware being managed.The configuration database ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 16CM database implementation May be part of an integrated environment tosupport software development.• The CM database and the managed documentsare all maintained on the same system CASE tools may be integrated with this sothat there is a close relationship between theCASE tools and the CM tools. More commonly, the CM database ismaintained separately as this is cheaper andmore flexible.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 17 Software systems are subject to continualchange requests:• From users;• From developers;• From market forces. Change management is concerned withkeeping track of these changes and ensuringthat they are implemented in the most cost-effective way.Change management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 18Request change by completing a change request formAnalyze change requestif change is validthenAssess how change might be implementedAssess change costSubmit request to change control boardif change is acceptedthenrepeatmake changes to softwaresubmit changed software for quality approvaluntil software quality is adequatecreate new system versionelsereject change requestelsereject change requestThe change management process ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 19 The definition of a change request form is part of theCM planning process. This form records the change proposed, requestor ofchange, the reason why change was suggested andthe urgency of change(from requestor of thechange). It also records change evaluation, impact analysis,change cost and recommendations (Systemmaintenance staff).Change request form©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 20Change request formChange Request FormProject: Proteus/PCL-Tools Number: 23/02Change requester: I. Sommerville Date: 1/12/02Requestedchange: Whenacomponentisselectedfromthestructure,displaythe name of the file where it is stored.Change analyser: G. Dean Analysis date: 10/12/02Components affected: Display-Icon.Select, Display-Icon.DisplayAssociated components: FileTableChange assessment: Relatively simple to implement as a file name table isavailable.Requiresthedesignandimplementationofadisplayfield.Nochangesto associated components are required.Change priority: LowChange implementation:Estimated effort: 0.5 daysDate to CCB: 15/12/02 CCB decision date: 1/2/03CCB decision: Accept change. Change to be implemented in Release 2.1.Change implementor: Date of change:Date submitted to QA: QA decision:Date submitted to CM:Comments©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 21 A major problem in change management istracking change status. Change tracking tools keep track the statusof each change request and automaticallyensure that change requests are sent to theright people at the right time. Integrated with E-mail systems allowingelectronic change request distribution.Change tracking tools ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 22 Changes should be reviewed by an external groupwho decide whether or not they are cost-effectivefrom a strategic and organizational viewpoint ratherthan a technical viewpoint. Should be independent of project responsiblefor system. The group is sometimes called a changecontrol board. The CCB may include representatives from clientand contractor staff.Change control board©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 23 This is a record of changes applied to adocument or code component. It should record, in outline, the change made,the rationale for the change, who made thechange and when it was implemented. It may be included as a comment in code. Ifa standard prologue style is used for thederivation history, tools can process thisautomatically.Derivation history©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 24Component header information// BANKSEC project (IST 6087)//// BANKSEC-TOOLS/AUTH/RBAC/USER_ROLE//// Object: currentRole// Author: N. Perwaiz// Creation date: 10th November 2002//// © Lancaster University 2002//// Modification history// Version ModifierDate Change Reason// 1.0 J. Jones 1/12/2002 Add header Submitted to CM// 1.1 N. Perwaiz 9/4/2003New field Change req. R07/02 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 25 Invent an identification scheme for systemversions. Plan when a new system version is to beproduced. Ensure that version management proceduresand tools are properly applied. Plan and distribute new system releases.Version and release management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 26 Version An instance of a system which isfunctionally distinct in some way from othersystem instances. Variant An instance of a system which isfunctionally identical but non-functionallydistinct from other instances of a system. Release An instance of a system which isdistributed to users outside of thedevelopment team.Versions/variants/releases©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 27Version identification Procedures for version identification shoulddefine an unambiguous way of identifyingcomponent versions. There are three basic techniques forcomponent identification• Version numbering;• Attribute-based identification;• Change-oriented identification. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 28 Simple naming scheme uses a linearderivation• V1, V1.1, V1.2, V2.1, V2.2 etc. The actual derivation structure is a tree or anetwork rather than a sequence. Names are not meaningful. A hierarchical naming scheme leads to fewererrors in version identification.Version numbering©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 29Version derivation structureV1.0 V1.1 V1.2 V2.0 V2.1 V2.2V1.1b V1.1.1V1.1a©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 30 Attributes can be associated with a version withthe combination of attributes identifying thatversion• Examples of attributes are Date, Creator,Programming Language, Customer, Status etc. This is more flexible than an explicit naming schemefor version retrieval; However, it can cause problemswith uniqueness - the set of attributes have to bechosen so that all versions can be uniquelyidentified. In practice, a version also needs an associatedname for easy reference.Attribute-based identification [...]... Tailored for particular user requirements. Configuration management is concerned with managing evolving software systems: • System change is a team activity; • CM aims to control the costs and effort involved in making changes to a system. Configuration management ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 5 Configuration management Involves the development and application... be generated for a large, complex software system. Configuration management planning ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 11 Defines the types of documents to be managed and a document naming scheme. Defines who takes responsibility for the CM procedures and creation of baselines. Defines policies for change control and version management. Defines the CM records which... version Initial system Desktop version Windows XP version HP version Sun version ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 46 Version management tools Version and release identification • Systems assign identifiers automatically when a new version is submitted to the system. Storage management. • System stores the differences between versions rather than all the version code. Change history recording •... implementor: Date of change: Date submitted to QA: QA decision: Date submitted to CM: Comments ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 21 A major problem in change management is tracking change status. Change tracking tools keep track the status of each change request and automatically ensure that change requests are sent to the right people at the right time. ...©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 34 System releases Not just a set of executable programs. May also include: • Configuration files defining how the release is configured for a particular installation; • Data files needed for system operation; • An installation program or shell script to install the system on target... 29 Slide 12 The CM plan Describes the tools which should be used to assist the CM process and any limitations on their use. Defines the process of tool use. Defines the CM database used to record configuration information. May include information such as the CM of external software, process auditing, etc. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 22 Changes... Engineering, 7th edition. Chapter 29 Slide 35 Customer may not want a new release of the system • They may be happy with their current system as the new version may provide unwanted functionality. Release management should not assume that all previous releases have been accepted. All files required for a release should be re-created when a new release is installed. Release problems ©Ian Sommerville 2004... Chapter 29 Slide 5 Configuration management Involves the development and application of procedures and standards to manage an evolving software product. CM may be seen as part of a more general quality management process. When released to CM, software systems are sometimes called baselines as they are a starting point for further development. ©Ian Sommerville 2004 Software Engineering, 7th edition.... easier to find problems that stem from component interactions early in the process. This encourages thorough unit testing - developers are under pressure not to ‘break the build’. A stringent change management process is required to keep track of problems that have been discovered and repaired. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 19 The definition of a change... files may be involved. System building tools may provide • A dependency specification language and interpreter; • Tool selection and instantiation support; • Distributed compilation; • Derived object management. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 28 Simple naming scheme uses a linear derivation • V1, V1.1, V1.2, V2.1, V2.2 etc. The actual derivation structure . supportconfiguration management processes©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 3Topics covered Configuration management. Configuration management planning Change management Version and release management System building CASE tools for configuration management ©Ian Sommerville 2004