Lectures Software Engineering - Chapter 29: Configuration management

52 trang hoanguyen 8590

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 29: Configuration management", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_29_configuration_manag.ppt

Nội dung text: Lectures Software Engineering - Chapter 29: Configuration management

Configuration management l Managing the products of system change ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 1
Objectives l To explain the importance of software configuration management (CM) l To describe key CM activities namely CM planning, change management, version management and system building l To discuss the use of CASE tools to support configuration management processes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 2
Topics covered l Configuration management planning l Change management l Version and release management l System building l CASE tools for configuration management ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 3
Configuration management l New versions of software systems are created as they change • For different machines/OS • Offering different functionality • Tailored for particular user requirements l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 4
Configuration management l Involves the development and application of procedures and standards to manage an evolving software product l May be seen as part of a more general quality management process l When released to CM, software systems are sometimes called baselines as they are a starting point for further development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 5
CM standards l CM should always be based on a set of standards which are applied within an organisation l Standards should define how items are identified, how changes are controlled and how new versions are managed l Standards may be based on external CM standards (e.g. IEEE standard for CM) l Existing standards are based on a waterfall process model - new standards are needed for evolutionary development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 7
Concurrent development and testing l A time for delivery of system components is agreed l A new version of a system is built from these components by compiling and linking them l This new version is delivered for testing using pre -defined tests l Faults that are discovered during testing are documented and returned to the system developers ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 8
Daily system building l It is easier to find problems that stem from component interactions early in the process l This encourages thorough unit testing - developers are under pressure not to ‘break the build’ l A stringent change management process is required to keep track of problems that have been discovered and repaired ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 9
Configuration management planning l All products of the software process may have to be managed • Specifications • Designs • Programs • Test data • User manuals l Thousands of separate documents are generated for a large software system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 10
CM planning l Starts during the early phases of the project l Must define the documents or document classes which are to be managed (Formal documents) l Documents which might be required for future system maintenance should be identified and specified as managed documents ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 11
The CM plan l Defines the types of documents to be managed and a document naming scheme l Defines who takes responsibility for the CM procedures and creation of baselines l Defines policies for change control and version management l Defines the CM records which must be maintained ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 12
The CM plan l Describes the tools which should be used to assist the CM process and any limitations on their use l Defines the process of tool use l Defines the CM database used to record configuration information l May include information such as the CM of external software, process auditing, etc. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 13
Configuration item identification l Large projects typically produce thousands of documents which must be uniquely identified l Some of these documents must be maintained for the lifetime of the software l Document naming scheme should be defined so that related documents have related names. l A hierarchical scheme with multi-level names is probably the most flexible approach ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 14
The configuration database l All CM information should be maintained in a configuration database l This should allow queries about configurations to be answered • 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? l The CM database should preferably be linked to the software being managed ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 16
CM database implementation l May be part of an integrated environment to support software development. The CM database and the managed documents are all maintained on the same system l CASE tools may be integrated with this so that there is a close relationship between the CASE tools and the CM tools l More commonly, the CM database is maintained separately as this is cheaper and more flexible ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 17
Change management l Software systems are subject to continual change requests • From users • From developers • From market forces l Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost-effective way ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 18
Change request form l Definition of change request form is part of the CM planning process l Records change required, suggestor of change, reason why change was suggested and urgency of change(from requestor of the change) l Records change evaluation, impact analysis, change cost and recommendations (System maintenance staff) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 20
Change tracking tools l A major problem in change management is tracking change status l 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. l Integrated with E-mail systems allowing electronic change request distribution ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 22
Change control board l Changes should be reviewed by an external group who decide whether or not they are cost-effective from a strategic and organizational viewpoint rather than a technical viewpoint l Should be independent of project responsible for system. The group is sometimes called a change control board l May include representatives from client and contractor staff ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 23
Derivation history l Record of changes applied to a document or code component l Should record, in outline, the change made, the rationale for the change, who made the change and when it was implemented l 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, 6th edition. Chapter 29 Slide 24
Version and release management l Invent identification scheme for system versions l Plan when new system version is to be produced l Ensure that version management procedures and tools are properly applied l Plan and distribute new system releases ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 26
Versions/variants/releases l Version An instance of a system which is functionally distinct in some way from other system instances l Variant An instance of a system which is functionally identical but non-functionally distinct from other instances of a system l Release An instance of a system which is distributed to users outside of the development team ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 27
Version identification l Procedures for version identification should define an unambiguous way of identifying component versions l Three basic techniques for component identification • Version numbering • Attribute-based identification • Change-oriented identification ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 28
Version numbering l Simple naming scheme uses a linear derivation e.g. V1, V1.1, V1.2, V2.1, V2.2 etc. l Actual derivation structure is a tree or a network rather than a sequence l Names are not meaningful. l Hierarchical naming scheme may be better ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 29
Attribute-based identification l Attributes can be associated with a version with the combination of attributes identifying that version l Examples of attributes are Date, Creator, Programming Language, Customer, Status etc. l More flexible than an explicit naming scheme for version retrieval; Can cause problems with uniqueness l Needs an associated name for easy reference ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 31
Attribute-based queries l An important advantage of attribute-based identification is that it can support queries so that you can find ‘the most recent version in Java’ etc. l Example • AC3D (language =Java, platform = NT4, date = Jan 1999) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 32
Change-oriented identification l Integrates versions and the changes made to create these versions l Used for systems rather than components l Each proposed change has a change set that describes changes made to implement that change l Change sets are applied in sequence so that, in principle, a version of the system that incorporates an arbitrary set of changes may be created ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 33
Release management l Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes l They must also incorporate new system functionality l Release planning is concerned with when to issue a system version as a release ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 34
System releases l Not just a set of executable programs l 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 hardware • Electronic and paper documentation • Packaging and associated publicity l Systems are now normally released on CD-ROM or as downloadable installation files from the web ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 35
Release problems l 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 l Release management must 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 36
Release decision making l Preparing and distributing a system release is an expensive process l Factors such as the technical quality of the system, competition, marketing requirements and customer change requests should all influence the decision of when to issue a new system release ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 37
Release creation l Release creation involves collecting all files and documentation required to create a system release l Configuration descriptions have to be written for different hardware and installation scripts have to be written l The specific release must be documented to record exactly what files were used to create it. This allows it to be re-created if necessary ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 39
System building l The process of compiling and linking software components into an executable system l Different systems are built from different combinations of components l Invariably supported by automated tools that are driven by ‘build scripts’ ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 40
System building problems l Do the build instructions include all required components? • When there are many hundreds of components making up a system, it is easy to miss one out. This should normally be detected by the linker l Is the appropriate component version specified? • A more significant problem. A system built with the wrong version may work initially but fail after delivery l Are all data files available? • The build should not rely on 'standard' data files. Standards vary from place to place ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 41
System building problems l Are data file references within components correct? • Embedding absolute names in code almost always causes problems as naming conventions differ from place to place l Is the system being built for the right platform • Sometimes must build for a specific OS version or hardware configuration l Is the right version of the compiler and other software tools specified? • Different compiler versions may actually generate different code and the compiled component will exhibit different behaviour ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 42
System representation l Systems are normally represented for building by specifying the file name to be processed by building tools. Dependencies between these are described to the building tools l Mistakes can be made as users lose track of which objects are stored in which files l A system modelling language addresses this problem by using a logical rather than a physical system representation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 44
CASE tools for configuration management l CM processes are standardised and involve applying pre-defined procedures l Large amounts of data must be managed l CASE tool support for CM is therefore essential l Mature CASE tools to support configuration management are available ranging from stand- alone tools to integrated CM workbenches ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 45
Change management tools l Change management is a procedural process so it can be modelled and integrated with a version management system l Change management tools • Form editor to support processing the change request forms • Workflow system to define who does what and to automate information transfer • Change database that manages change proposals and is linked to a VM system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 46
Version management tools l Version and release identification • Systems assign identifiers automatically when a new version is submitted to the system l Storage management. • System stores the differences between versions rather than all the version code l Change history recording • Record reasons for version creation l Independent development • Only one version at a time may be checked out for change. Parallel working on different versions ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 47
System building l Building a large system is computationally expensive and may take several hours l Hundreds of files may be involved l 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, 6th edition. Chapter 29 Slide 49
Key points l Configuration management is the management of system change to software products l A formal document naming scheme should be established and documents should be managed in a database l The configuration data base should record information about changes and change requests l A consistent scheme of version identification should be established using version numbers, attributes or change sets ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 51
Key points l System releases include executable code, data, configuration files and documentation l System building involves assembling components into a system l CASE tools are available to support all CM activities l CASE tools may be stand-alone tools or may be integrated systems which integrate support for version management, system building and change management ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 29 Slide 52