• Have any questions?
  • info.zbook.org@gmail.com

Configuration Management

3m ago
5 Views
0 Downloads
364.42 KB
51 Pages
Last View : 1d ago
Last Download : n/a
Upload by : Allyson Cromer
Share:
Transcription

Configuration managementAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 291

Objectives To explain the importance of softwareconfiguration management (CM)To describe key CM activities namely CMplanning,changemanagement,versionmanagementgand systemybuildinggTo discuss the use of CASE tools to supportconfiguration management processesAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 292

Topics covered Configuration management planningChange managementVersion and release managementSystem buildingCASE toolst l forf configurationfiti managementtAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 293

Configuration management New versions of software systems are created asthey change: For different machines/OS;Offering different functionality;Tailored for particular user requirements.Configuration management is concerned withmanaging evolving software systems: Systemychangeg is a team activity;y;CM aims to control the costs and effort involved inmaking changes to a system.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 294

Configuration management Involves the development and application ofprocedures and standards to manage anevolvingg software pproduct.CM may be seen as part of a more generalqualityqy managementgprocess.pWhen released to CM, software systems aresometimes called baselines as they are a startingpoint for further development.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 295

System familiesAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 296

CM standards CM should always be based on a set of standards whichare applied within an organisation.Standards should define how items are identified, howchanges are controlled and how new versions aremanaged.Standards may be based on external CM standards (e.g.(e gIEEE standard for CM).Some existing standards are based on a waterfallprocess model - new CM standards are needed forevolutionary development.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 297

Concurrent developmentpand testingg A time (say 2pm) for delivery of systemcomponents is agreed.A new version of a systemyis built from thesecomponents by compiling and linking them.This new version is delivered for testing usingpre-definedd fi d tests.t tFaults that are discovered during testing aredocumented and returned to the systemdevelopers.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 298

Frequentqsystemybuildingg 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 ‘break thebuild’.A stringent change management process isrequired to keep track of problems that havebeen discovered and repaired.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 299

Configuration management planning All products of the software process may have tobe managed: Specifications;Designs;Programs;Test data;User manuals.Thousands of separatepdocuments mayy begenerated for a large, complex software system.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2910

The CM plan Defines the types of documents to be managedand a document naming scheme.Defines who takes responsibility for the CMprocedures and creation of baselines.Defines policies for change control and versionmanagement.Defines the CM records which must bemaintained.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2911

The 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.Mayy include information such as the CM ofexternal software, process auditing, etc.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2912

Configuration item identification Large projects typically produce thousands of documentswhich must be uniquely identified.Some of these documents must be maintained for thelifetime of the software.Document naming scheme should be definedso that related documents have related names.namesA hierarchical scheme with multi-level names isprobably the most flexible approach. pted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2913

Configuration hierarchyAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2914

The configuration database 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 databaseThd t bshouldh ld preferablyf bl beb linkedli k d tot thethsoftware being managed.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2915

CM database implementation May be part of an integrated environment tosupport software development. The CM database and the managed documents areallll maintainedi i d on theh same systemCASE tools may be integrated with this so thatthere is a close relationship between the CASEtools and the CM tools.More commonly,y, the CM database is maintainedseparately as this is cheaper and more flexible.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2916

Change management Software systems are subject to continualchange requests: From users;From developers;From market forces.Change management is concerned with keepingtrack of these changes and ensuring that theyare implemented in the most cost-effective way.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2917

The change management processRequest change by completing a change request formAnalyze change requestif change is valid thenAssess how change might be implementedAssess change costSubmit request to change control boardif change is accepted thenrepeatmake changes to softwaresubmit changed software for quality approvaluntil software quality is adequatecreate new system versionelsereject change requestelsereject change requestAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2918

Change request form 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 and theurgencyofchange(fromrequestorofthechange).It also records change evaluation, impact nancei tstaff).t ff)Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2919

Change request formAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2920

Change tracking tools A major problem in change management istracking change status.Change tracking tools keep track the status ofeach change request and automatically ensurethat changeg requestsqare sent to the rightg ppeoplepat the right time.Integrated with E-mail systems allowingelectronic change request distribution.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2921

Change control board Changes should be reviewed by an external group whodecide whether or not they are cost-effective from astrategic and organizational viewpoint rather than at h i l viewpoint.technicalii tShould be independent of project responsiblefor system. The group is sometimes called a changecontrol board.The CCB may include representatives from client andcontractort t staff.t ffAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2922

Derivation history This is a record of changes applied to adocument or code component.It should record,record in outline,outline the change made,made therationale for the change, who made the changeand when it was implemented.pIt may be included as a comment in code. If astandard prologue style is used for the derivationhistory, tools can process this automatically.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2923

Component header information// BAN KSEC project (IST 6087)//// BAN KSEC -TOOL S/AUTH /RBAC /USER ROLE//// O bject : currentRole// A uthor: N. P erwa iz// Creation date: 10th Novemb er 2002//// L ancaster U niversity 2002//// Modifica tion history// V ersionModifier DateChangeReason// 1 .0J. Jones1/12/2002Add heade rSubm itted to CM// 1 .1N. Perwaiz9/4/2003 New fieldChange req. R07/02Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2924

Version and release management 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 systemyreleases.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2925

Versions/variants/releases Version An instance of a system which isfunctionally distinct in some way from othersystemyinstances.Variant An instance of a system which ct from other instances of a system.Release An instance of a system which isdistributed to users outside of the developmentteam.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2926

Version identification Procedures for version identification shoulddefine an unambiguous way of identifyingcomponentpversions.There are three basic techniques for componentidentification Version numbering;Attribute-based identification;Change-oriented identification.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2927

Version numbering Simple naming scheme uses a linear derivation 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.meaningfulA hierarchical naming scheme leads to fewererrorseo s in versione s o identification.de t cat oAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2928

Version derivation structureAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2929

Attribute-basedAttributebased identification Attributes can be associated with a version on ExamplesofattributesareDateDate,Programming Language, Customer, Status etc.CreatorCreator,This is more flexible than an explicit naming schemefor version retrieval; However,However it can cause problems withuniqueness - the set of attributes have to be chosen sothat all versions can be uniquely identified.In practice,practice a version also needs an associated name foreasy reference.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2930

Attribute-based queriesq An important advantage of attribute-basedattribute basedidentification is that it can support queries so thatyyou can find ‘the most recent version in Java’etc.The qqueryy selects a version dependingpg onattribute values AC3D (language Java, platform XP, date Jan2003).2003)Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2931

Change-orientedgidentification Integrates versions and the changes made to createthese versions.Used for systems rather than components.Each proposed change has a change set that describeschanges made to implement that change.Change sets are applied in sequence so that,that in principle,principlea version of the system that incorporates an arbitrary setof changes may be created.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2932

Release management Releases must incorporate changes forced onthe system by errors discovered by users and byhardware changes.gThey must also incorporate new systemfunctionality.yRelease planning is concerned with when toissue a system version as a release.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2933

System releases Not just a set of executable programs.May also include: Configuration files defining how the release is configured for aparticular installation;Data files needed for system operation;An installation program or shell script to install the system ontarget hardware;Electronic and paper documentation;Packaging and associated publicity.Systems are now normally released on optical disks (CDor DVD) or as downloadable installation files from theweb.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2934

Release problems Customer may not want a new release of thesystem They may be happy with their current system as thenew versioni may provideid unwantedd functionality.filiRelease management should not assume that allprevious releases have been accepted.accepted All filesrequired for a release should be re-created whena new release is installed.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2935

Release decision makingg Preparing and distributing a system release is anexpensive process.Factors such as the technical quality of thesystem, competition, marketing requirementsand customer changegrequestsqshould allinfluence the decision of when to issue a newsystem release.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2936

Systemyrelease strategygyFacto rDe scriptionpTechn ical qua lity ofthe systemIf serious system faults are repo rted wh ich a ffect the way in wh ichmany cus tomers use the sys tem, it may b e nec essary to issue a faultrepa ir release. Howeve r, minor sy stem faults may be repa ired by issuingpatche s (often d istributed ove r the Internet) that can be app lied to thecurrentt releaseloff theth system.tPlatform change sYou may hav e to create a new releas e of a software app lication when anew version o f the ope rating sys tem platform is released .LehmanÕs fift h law((seeCh aptert 21)This sugge sts that the increment of func tiona lity that is included in eachreleaseli app roximatelyisi t l cons tant.t t TherTh efore,fif therethh beenhasba systemtrelease with significant ne w func tiona lity, then it m ay have to befollowed by a repa ir release.Co mpetiti onA new system releas e may be n eces sary be cause a co mpeting p roduc t isava ilable.Marke tingrequ irementsThe marketing d epar tment of an org anisation may have made acommitm ent for releases to be ava ilable at a pa rticular da te.Cu stomer chang eproposapplsFor custom ised systems , cus tomers may have ma de and paid for aspecificpset of systemychangeg ppropop sals and theyy expep ct a systemyreleaseas soon as these have been implemented.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2937

Release creation Release creation involves collecting all files anddocumentation required to create a systemrelease.Configuration descriptions have to be written fordifferent hardware and installation scriptsp have tobe written.The specific release must be documented torecord exactly what files were used to create it.This allows it to be re-created if necessary.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2938

System building The process of compiling and linking softwarecomponents into an executable system.Different systems are built from differentcombinations of components.This process is now always supported byautomated tools that are driven by ‘build scripts’.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2939

System building problems Dothebuildcomponents?t ? includeallrequiredWhen there are many hundreds of components making upa system, it is easy to miss one out. This should normallybe detected by the linker.linkerIsthespecified? instructionsappropriatecomponentversionA more significant problem. A system built with the wrongversion may work initially but fail after delivery.Are all data files available? The build should not rely on 'standard' data files. Standardsvary from place to place.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2940

System building problems Aredatacorrect? referenceswithincomponentspEmbedding absolute names in code almost always causesproblems as naming conventions differ from place to place.Is the system being built for the right platform fileSometimes you must build for a specific OS version or hardwaregconfiguration.Is the right versionsoftware tools specified? ofthecompilerandotherDifferent compiler versions may actually generate different code andthe compiled component will exhibit different behaviour.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2941

SystemybuildinggAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2942

CASE tools for configurationgmanagementg CM processes are standardised and involveapplying pre-defined procedures.Largeg amounts of data must be managed.gCASE tool support for CM is therefore essential.Mature CASE tools to support configurationmanagement are available ranging from standalone tools to integrated CM workbenches.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2943

CM workbenches Open workbenches Tools for each stage in the CM process areintegratedgthroughg organizationalgprocedures andpscripts. Gives flexibility in tool selection.Integrated workbenches Provide whole-process, integrated support forconfiguration management. More tightly integratedtools so easier to use.use However,However the cost is lessflexibility in the tools used.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2944

Changeg managementgtools Change management is a procedural process so it canbe modelled and integrated with a version managementsystem.Change management tools Form editor to support processing the change request forms;Workflow system to define who does what and to automateinformation transfer;Change database that manages change proposals and is linkedto a VM system;Change reporting system that generates management reportson the status of change requests.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2945

Version management tools Version and release identification Storage management Record reasons for version creation.creationIndependent development System stores the differences between versions rather than all theversion code.Change history recording Systems assign identifiers automatically when a new version issubmitted to the system.Only one version at a time may be checked out for change. Parallelworking on different versions.Project support Can manage groups of files associated with a project rather than justsingle files.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2946

Delta-basedDeltabased versioningAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2947

Systemybuildingg Building a large system is computationallyexpensive and may take several hours.Hundreds of files may be involved.involvedSystem building tools may provide Adependencyspecificationlanguageinterpreter;Tool selection and instantiation support;Distributed compilation;Derived object management.Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 29and48

Component dependenciesAdapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 2949

Key points Configuration management

Configuration management Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 29 1. Objectives . Change management Version and release management