1. Change Control Process—I
need for change is recognized
change request from user
developer evaluates
change report is generated
change control authority (CCA) decides
request is queued for action –
Engineering change order (ECO)
generated
CCA or CCB – both developer and client side
ECO –
the change to be made
the constraints that must be respected
criteria for review and audit
change request is denied
change control process—II
user is informed

2. Change Control Process-II
assign people to SCIs
check-out SCIs
make the change
review/audit the change
check-in SCIs
Check-in and check-out
two important elements of change control – access and synchronization control
Access control – who has the authority to check-out the object
Synchronization control – ensures that parallel changes by two different people do not overwrite one another.
establish a “baseline” for testing
change control process—III

3. Check-in and check-out
Access and synchronization control
Access control –
who has the authority to check-out the object
Synchronization control –
ensures that parallel changes by two different people do not overwrite one another.
Control on updates
Other copies can be checked out for use
Single writer, multiple readers

4. Check- in Check- in Access control Access control Software engineer
Configuration object (modified version)
Configuration object (modified version)
Configuration object (baseline version)
Configuration object (baseline version)
Audit info
unlock
unlock
Access
control
Access
control
Software
engineer
Software
engineer
Project DB
Project DB
Ownership info
Ownership info
Configuration object (extracted version)
Configuration object (extracted version)
lock
Request for Configuration object
lock
Request for Configuration object
Check-
out
Check-
out
Configuration object (baseline version)
Configuration object (baseline version)

5. Change Control Process-III
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

6. Configuration Audit
Ensuring that a change has been properly implemented
Formal technical reviews
Software Configuration audit
Configuration audit assess a configuration object for characteristics that are generally not considered during audit
Conducted by the SQA group

7. Configuration audit
Has the change specified in the ECO been made? Have any additional modifications been incorporated?

8. Configuration audit
Has a FTR been conducted to assess technical correctness?
Has the software process been followed?
Have the SE standards been properly applied?

9. Configuration audit Has the change been highlighted in the SCI?
Change date and author
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?

10. Configuration Status reporting (CSR)
Aka status accounting
What happened?
Who did it?
When did it happen?
What else will be affected?

11. Software Engineering II
Lecture 35
Fakhar Lodhi

12. Recap