Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
32Activity
0 of .
Results for:
No results containing your search query
P. 1
MC0071 - Set 2

MC0071 - Set 2

Ratings:
(0)
|Views: 1,916|Likes:
Published by nikeneel
SMU MCA Assignments
SMU MCA Assignments

More info:

Published by: nikeneel on Jun 02, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

01/25/2013

pdf

text

original

 
February 2010Master of Computer Application (MCA) –Semester 3MC0071 – Software Engineering
Assignment Set – 2
1. Explain the following with respect to ConfigurationManagement: A) Change Management B) Version and Release Management 
Ans –
A)Change Management
 The change management process should come into effects when thesoftware or associated documentation is put under the control of theconfiguration management team. Change management proceduresshould be designed to ensure that the costs and benefits of change areproperly analyzed and that changes to a system are made in a controlledway.Change management processes involve technical change analysis,cost benefit analysis and change tracking. The pseudo-code, shown intable below defines a process, which may be used to manage softwaresystem changes: The first stage in the change management process is to complete achange request form (CRF). This is a formal document where therequester sets out the change required to the system. As well asrecording the change required, the CRF records the recommendationsregarding the change, the estimated costs of the change and the dateswhen the change was requested, approved, implemented and validated.It may also include a section where the maintenance engineer outlineshow the change is to be implemented. The information provided in the change request form is recorded in theCM database.Once a change request form has been submitted, it is analyzed tocheck that the change is valid. Some change requests may be due to
 
user misunderstandings rather than system faults; others may refer toalready known faults. If the analysis process discovers that a changerequest is invalid duplicated or has already been considered the changeshould be rejected. The reason for the rejection should be returned tothe person who submitted the change request.For valid changes, the next stage of the process is changeassessment and costing. The impact of the change on the rest of thesystem must be checked. A technical analysis must be made of how toimplement the change. The cost of making the change and possiblychanging other system components to accommodate the change is thenestimated. This should be recorded on the change request form. Thisassessment process may use the configuration database wherecomponent interrelation is recorded. The impact of the change on othercomponents may then be assessed.Unless the change involves simple correction of minor errors onscreen displays or in documents, it should then be submitted to a changecontrol board (CCB) who decide whether or not the change should beaccepted. The change control board considers the impact of the changefrom a strategic and organizational rather than a technical point of view.It decides if the change is economically justified and if there are goodorganizational reasons to accept the change. The term ‘change control board’ sounds very formal. It implies arather grand group which makes change decisions. Formally structuredchange control boards which include senior client and contractor staff are a requirement of military projects. For small or medium-sizedprojects, however, the change control board may simply consist of aproject manager plus one or two engineers who are not directly involvedin the software development. In some cases, there may only be a singlechange reviewer who gives advice on whether or not changes are justifiable.When a set of changes has been approved, the software is handedover to the development of maintenance team for implementation. Oncethese have been completed, the revised software must be revalidated tocheck that these changes have been correctly implemented. The CMteam, rather than the system developers, is responsible for building anew version or release of the software.Change requests are themselves configuration items. They shouldbe registered in the configuration database. It should be possible to usethis database to discover the status of change requests and the changerequests, which are associated with specific software components.As software components are changed, a record of the changes made toeach component should be maintained. This is sometimes called thederivation history of a component. One way to maintain such a record is
 
in a standardized comment prologue kept at the beginning of thecomponent. This should reference the change request associated withthe software change. The change management process is very procedural. Each personinvolved in the process is responsible for some activity. They completethis activity then pass on the forms and associated configuration items tosomeone else. The procedural nature of this process means that achange process model can be designed and integrated with a versionmanagement system. This model may then be interpreted so that theright documents are passed to the right people at the right time.
B)Version and Release Management
Version and release management are the processes of identifying andkeeping track of different versions and releases of a system. Versionmanagers must devise procedures to ensure that different versions of asystem may be retrieved when required and are not accidentallychanged. They may also work with customer liaison staff to plan whennew releases of a system should be distributed.A system version
 
is an instance of a system that differs, in some way,from other instances. New versions of the system may have differentfunctionality, performance or may repair system faults. Some versionsmay be functionally equivalent but designed for different hardware orsoftware configurations. If there are only small differences betweenversions, one of these is sometimes called a variant of the other.A system release is a version that is distributed to customers. Eachsystem release should either include new functionality or should beintended for a different hardware platform. Normally, there are moreversions of a system than releases. Some versions may never bereleased to customers.For example, versions may be created within an organization for internaldevelopment or for testing.A release is not just an executable program or set of programs. It usuallyincludes:(1) Configuration files defining how the release should be configured forparticular installations.(2) Data files which are needed for successful system operation.(3) An installation program which is used to help install the system ontarget hardware.(4) Electronic and paper documentation describing the system.

Activity (32)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
pawanmdp liked this
Amit Sharma liked this
Ganesh Adiga liked this
Subodh Chandra liked this
AbhijitChandra liked this
Yogesh Bhatt liked this
Vishal Rajput liked this
alokrocks liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->