Download Change Control Process-Methods Of Software Engineering-Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!
Lecture No. 35
Change Control Process
The first component of the change control process is the Change Control Authority (CCA) or a Change Control Board (CCB). A CCA or CCB includes people from both developer and client side.
Whenever a change is required, the CCB decides whether to allow this change to happen or deny it. If it is decided that a change is needed, an Engineering Change Order or ECO is generated. An ECO defines the change to be made, the constraints that must be respected, and the criteria for review and audit. The change control process thus involves the following steps.
- need for change is recognized
- change request from user
- developer evaluates
- change report is generated
- change control authority (CCA) decides
- Either step 6a or 6b is performed. Steps numbers 7 to 17 are performed only if step 6b is performed. a) i) change request is denied ii) user is informed iii) no further action is taken. b) assign people to SCIs
- check-out SCIs
- make the change
- review/audit the change
- check-in SCIs
- establish a ―baseline‖ for testing
- perform SQA and testing activities
- check-in the changed SCIs
- promote SCI for inclusion in next release
- rebuild appropriate version
- review/audit the change
- include all changes in release
Thus, a change is incorporated in a controlled and strict manner.
Check-in and check-out
In SCM, the processes of Check-in and Check-out take a central stage. These are two important elements of change control and provide access and synchronization control. Access control manages who has the authority to check-out the object and synchronization control ensures that parallel changes by two different people do not overwrite one another.
Synchronization control implements a control on updates. When a copy is checked-out, other copies can be checked out for use only but they cannot be modified. In essence, it implements a single-writer multiple-readers protocol. This process is depicted in the following diagram.
Configuration Audit
Configuration audit ensures that a change has been properly implemented. It involves formal technical reviews and software configuration audit. Configuration audit assess a configuration object for characteristics that are generally not considered during audit. It is conducted by the SQA group. It looks into the following aspects of the change:
Has the change specified in the ECO been made? Have any additional modifications been incorporated? Has a FTR been conducted to assess technical correctness? Has the software process been followed? Have the SE standards been properly applied? Has the change been highlighted in the SCI? o Change date and author o Have the attributes of the configuration object been updated? Have the SCM procedures for noting the change, recording it, and reporting it been followed? Have all related SCI‘s been properly updated?
An audit report is finally generated and any non-compliances are highlighted so that they may be corrected.
Software
engineer
Check-
in
Access
control
Check-
out
Configuration object (baseline version)
Configuration object (baseline version)
Ownership info
lock
Configuration object(modified version) unlock
Configuration object (extracted version) Request for Configuration object
Audit info
Project DB
Software
engineer
Check-
in
Access
control
Check-
out
Configuration object (baseline version)
Configuration object (baseline version)
Ownership info
lock
Configuration object(modified version) unlock
Configuration object (extracted version) Request for Configuration object
Audit info
Project DB
Lecture No. 36
Requirement Management and CMM
CM standards
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 ANSI/IEEE Std. No. 828-1983, 1042-1987, 1028- 1988). Existing standards are based on a waterfall process model - new standards are needed for evolutionary development.
The Requirement Problem
The goal of software development is to develop quality software – on time and on budget
- that meets customers‘ real needs. Project success depends on good requirement management. It may be recalled that requirement errors are the most common type of software development errors and the most costly to fix. It may also be recalled that requirement errors are listed as one of the roots causes of software project failure. According to a Standish Group report, lack of user input is responsible for13% of all project failures; incomplete requirements and specifications for 12% of all project failures; and changing requirements are responsible for 12% of all project failures.
The above graph shows the result of an industry survey. It is clear to see that requirement specifications are considered to be the most significant cause of major software problems by a majority of practitioners.
Largest software problems by category
0%
10%
20%
30%
40%
50%
60%
RequirementSpecificationManagiing
customer requirements Documentation
Software and
testing Project management
Coding
Major Problem Minor Problem Not a Problem
Requirement Management
Requirement management is also one of the 5 KPA defined at CMM level 2. Without having a proper requirement management function, chances of a project‘s success are slim.
Requirements Management KPA Goals statement says that:
- The software requirements are controlled to establish a baseline for software engineering and management use.
- Software plans, products, and activities are kept consistent with the software requirements.
Requirement Management is defined as a systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.
It includes establishing and maintaining an agreement with the customer on the requirement for the software project. It involves Defining the requirement baseline Reviewing proposed requirement changes and evaluating the likely impact of each proposed change before deciding whether to approve it Incorporating approved requirement changes in the project in a controlled manner Keeping project plans current with the requirements Negotiating new commitments based on estimated impact on changed requirements Tracing individual requirements to their corresponding design, source code, and test cases Tracking requirement status and change activity throughout the project
Requirement Attributes
We need to tag requirements with certain attributes in order to manage them in an orderly fashion. Attributes are used to establish a context and background for each requirement. They go beyond the description of intended functionality. They can be used to filter, sort, or query to view selected subset of the requirements. A list of possible attributes is enumerated as below:
- Requirement ID
- Creation date
- Created by
- Last modified on
- Last modified by
- Version number
- Status
- Origin
- Subsystem
- Product Release
- Priority
The changes in the requirement status can be plotted as shown below to get an idea of the stability of the requirements and the progress of the project. It is easy to see that it is normal to have unstable requirements in the beginning but if they requirements stayed volatile till the end then the progress would be slow.
Requirement Status Chart
0
10
20
30
40
50
60
70
80
90
1 2 3 4 5 6 7 8 9 10 Months
Number of Requirements
Proposed Approved Implemented Verified Deleted
Requirement Status Chart
0
20
40
60
80
100
120
140
1 2 3 4 5 6 7 8 9 10 Months
Number of Requirements
Proposed Approved Implemented Verified Deleted
Managing Scope Creep
We must always remember that requirements will change, no matter what. That means we have to be able to manage changing requirements. Software organizations and professionals must learn to manage changing requirements. A major issue in requirements engineering is the rate at which requirements change once the requirements phase has ―officially‖ ended. We therefore need to try to take it to a minimum level. For that we need to measure the change activity.
Requirement Traceability
Requirement traceability is a very important consideration for requirement management. It is really hard to manage requirements that are not traceable.
A Software Requirement Specification (SRS) is traced if the origin of its requirements is clear. That means that the SRS includes references to earlier supportive documents. An SRS is traceable if it written in a manner that facilitates the referencing of each individual requirement stated therein.
It is important to trace requirements both ways. That is from origin of a requirement to how it is implemented. This is a continuous process. It is also important that the rationale of requirements must also be traced. Traceability is important for the purposes of certification, change impact analysis, maintenance, project tracking, reengineering, reuse, risk reduction, and testing. That is it plays an important role in almost every aspect of the project and its life cycle.
Requirement Change Origins
Marketing Management
Customer
Software Engineering Hardware Engineering
Testing
Change Origin
Number of Proposed Changes
