Скачать презентацию Configuration management l Managing the products code and Скачать презентацию Configuration management l Managing the products code and

8fb534d29911d87f589cbe1144b8ff80.ppt

  • Количество слайдов: 44

Configuration management l Managing the products (code and documentation) of system as it changes Configuration management l Managing the products (code and documentation) of system as it changes ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 1

Configuration management l New versions of software systems are created • • l Enhancements Configuration management l New versions of software systems are created • • l Enhancements / Fixes Different stages of development For different machines/OS Less likely, tailored for particular user requirements, offering different functionality Configuration management is concerned with managing evolving software systems ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 4

Configuration management l l l Involves the development and application of procedures and standards Configuration management l l l Involves the development and application of procedures and standards to manage an evolving software product 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 2000 Software Engineering, 6 th edition. Chapter 29 Slide 5

System families ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 6 System families ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 6

CM standards l l CM should always be based on a set of standards CM standards l l CM should always be based on a set of standards which are applied within an organisation Standards should define how items are identified, how changes are controlled and how new versions are managed Standards may be based on external CM standards (e. g. IEEE standard for CM) Existing standards are based on a waterfall process model - new standards are needed for evolutionary development ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 7

CM for evolutionary development (Concurrent development and testing) l l A time for delivery CM for evolutionary development (Concurrent development and testing) l l A time for delivery of system components is agreed A new version of a system is built from these components by compiling and linking them This new version is delivered for testing using pre -defined tests Faults that are discovered during testing are documented and returned to the system developers ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 8

Daily system building l l It is easier to find problems that stem from Daily system building l l It is easier to find problems that stem from component interactions early in the process Encourages thorough unit testing - developers are under pressure not to ‘break the build’ Successful use requires stringent change management process to keep track of problems that have been discovered and repaired Produces many versions that must be managed ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 9

29. 1 Configuration management planning l All products of the software process may have 29. 1 Configuration management planning l All products of the software process may have to be managed • • • l Specifications Designs Programs Test data User manuals Thousands of separate documents are generated for a large software system ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 10

CM planning l l l Starts during the early phases of the project Must CM planning l l l Starts during the early phases of the project Must define the documents or document classes which are to be managed Documents which might be required for future system maintenance should be identified and specified as managed documents ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 11

The CM plan l l l Types of documents to be managed Who takes The CM plan l l l Types of documents to be managed Who takes responsibility for CM Policies for change control and version management CM records which must be maintained … ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 12

The CM plan l l l Tools for CM CM database used to record The CM plan l l l Tools for CM CM database used to record configuration information Other … ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 13

Configuration item identification l l Large projects produce thousands of documents Some must be Configuration item identification l l Large projects produce thousands of documents Some must be maintained for the software lifetime Document naming scheme needed Hierarchical scheme with multi-level names ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 14

Configuration hierarchy ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 15 Configuration hierarchy ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 15

The configuration database l l All CM information should be maintained in a configuration The configuration database l l All CM information should be maintained in a configuration database This should allow queries about configurations to be answered • • • l What customers have a particular system version? What platform is required for a particular version? How many versions have been created? 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 the version management system for software being managed ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 16

29. 2 Change management l Software systems are subject to continual change requests • 29. 2 Change management l Software systems are subject to continual change requests • • • l l From users From developers From market forces Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost-effective way Change management starts when materials put into configuration management ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 18

The change management process ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 The change management process ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 19

Change request form l l l Definition of change request form is part of Change request form l l l Definition of change request form is part of the CM planning process Records change required, suggestor of change, reason why change was suggested and urgency of change(from requestor of the change) Records change evaluation, impact analysis, change cost and recommendations (System maintenance staff) ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 20

Example Change request form Change Request Form Project: Proteus/PCL-Tools Number: 23/94 Change requester: I. Example Change request form Change Request Form Project: Proteus/PCL-Tools Number: 23/94 Change requester: I. Sommerville Date: 1/12/98 Requested change: When a component is selected from the structure, display the name of the file where it is stored. Change analyser: G. Dean Analysis date: 10/12/98 Components affected: Display-Icon. Select, Display-Icon. Display Associated components: File. Table Change assessment: Relatively simple to implement as a file name table is available. Requires the design and implementation of a display field. No changes to associated components are required. Change priority: Low Change implementation: Estimated effort: 0. 5 days Date to CCB: 15/12/98 CCB decision date: 1/2/99 CCB decision: Accept change. Change to be implemented in Release 2. 1. Change implementor: Date of change: QA decision Date submi tted to QA: Date submitted to CM: Commen ts ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 21

Change tracking tools l l A major problem in change management is tracking change Change tracking tools l l 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. Integrated with E-mail systems allowing electronic change request distribution May be integrated with Configuration Management DB ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 23

Change control board l l l Decide based on a cost, strategic and organizational Change control board l l l Decide based on a cost, strategic and organizational viewpoint Should be independent of project team Representatives from client and contractor staff ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 24

Derivation history l l Record of changes applied to a document or code component Derivation history l l Record of changes applied to a document or code component Should record, in outline, the change made, the rationale for the change, who made the change and when it was implemented Impact in tracked item should be marked May be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 25

Component header information ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide Component header information ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 26

29. 3 Version and release management l l Invent identification scheme for system versions 29. 3 Version and release management l l Invent identification scheme for system versions Plan when new system version is to be produced Ensure that version management procedures and tools are properly applied Plan and distribute new system releases ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 27

Version identification l l Procedures for version identification should define an unambiguous way of Version identification l l Procedures for version identification should define an unambiguous way of identifying component versions Three basic techniques for component identification • • • Version numbering Attribute-based identification Change-oriented identification ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 29

Version numbering l l Simple naming scheme uses a linear derivation e. g. V Version numbering l l Simple naming scheme uses a linear derivation e. g. V 1, V 1. 2, V 2. 1, V 2. 2 etc. However, actual derivation structure may be a tree or a network rather than a sequence Names are not meaningful. Hierarchical naming scheme may be better ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 30

Version derivation structure ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide Version derivation structure ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 31

Attribute-based identification l l l Attributes can be associated with a version with the Attribute-based identification l l l Attributes can be associated with a version with the combination of attributes identifying that version Examples of attributes are Date, Creator, Programming Language, Customer, Status etc. More flexible than an explicit naming scheme for version retrieval; Supports queries when looking for versions Can cause problems with uniqueness Awkward - needs an associated name for easy reference ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 32

System releases l l Not just a set of executable programs May also include System releases l l Not just a set of executable programs May also include • • • l 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 hardware Electronic and paper documentation Packaging and associated publicity Systems are now normally released on CD-ROM or as downloadable installation files from the web ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 36

Release problems • Release management must not assume that all previous releases have been Release problems • Release management must not assume that all previous releases have been accepted. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 37

Release decision making l l l Must plan when to distribute a system release Release decision making l l l Must plan when to distribute a system release Preparing and distributing a release is expensive Factors: • • • technical quality competition, marketing requirements customer change requests ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 38

Release creation l l l Collect all files and documentation Configuration descriptions / instructions/ Release creation l l l Collect all files and documentation Configuration descriptions / instructions/ scripts Documented to allow re-creation ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 40

29. 4 System building l l l The process of compiling and linking software 29. 4 System building l l l The process of compiling and linking software components into an executable system Different systems are built from different combinations of components Invariably supported by automated tools that are driven by ‘build scripts’ ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 41

System building ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 42 System building ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 42

System building problems l l l Do the build instructions include all required components? System building problems l l l Do the build instructions include all required components? Is the appropriate component version specified? Are all data files available? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 43

System building problems l l l Are data file references within components correct? Is System building problems l l l Are data file references within components correct? Is the system being built for the right platform Is the right version of the compiler and other software tools specified? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 44

29. 5 CASE tools for configuration management l l CM processes are standardized and 29. 5 CASE tools for configuration management l l CM processes are standardized and involve applying pre-defined procedures Large amounts of data must be managed CASE tool support for CM is therefore essential Mature CASE tools to support configuration management are available ranging from standalone tools to integrated CM workbenches ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 46

Change management tools l l Change management is a procedural process so it can Change management tools l l Change management is a procedural process so it can be modelled and integrated with a version management system Change management tools • • • Form editor Workflow system Change database, with query facilities ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 47

Version management tools l l Version and release identification Storage management. Change history recording Version management tools l l Version and release identification Storage management. Change history recording Independent development ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 48

Delta-based versioning ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 49 Delta-based versioning ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 49

e. g. Microsoft Visual Source Safe l l Part of Visual Studio Handles Sharing e. g. Microsoft Visual Source Safe l l Part of Visual Studio Handles Sharing of Files in a project • • l Handles Multiple Versions • • l Check out for making changes Check back in after changes Saves latest Saves “Backward Deltas” Mostly makes sense with network common area available to whole team ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 50

Microsoft Visual Source Safe l l l VSS keeps a database Inside DB there Microsoft Visual Source Safe l l l VSS keeps a database Inside DB there are Projects include files Users have working folder for when they are working on something Shadow Folder – common, read only versions of current code ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 51

Microsoft Visual Source Safe l l l l Check out file – copied to Microsoft Visual Source Safe l l l l Check out file – copied to your working folder While checked out, other check-outs are stopped Check back in makes file available to others If not changing file, can Get / View the file (read only) Can cancel checkout if decide not to change file VSS can show differences between versions of a file VSS keeps track of versions using numbers, by date, AND by user-defined labels (names) Can try to merge different versions of a file ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 52

System building l l l Building a large system is computationally expensive and may System building l l l Building a large system is computationally expensive and may take several hours Hundreds of 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 2000 Software Engineering, 6 th edition. Chapter 29 Slide 53

Component dependencies ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 54 Component dependencies ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 54