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

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

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

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)

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

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

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

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

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?

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

Software Engineering II Lecture 35 Fakhar Lodhi

Recap