Software Engineering Lecture 9: Configuration Management

Today’s Topics l SCM Concepts l Configuration Objects & Baselines l SCM Tasks l Access and Synchronization l Managing Change Example: GNATS

Configuration Management l Change is inevitable! Maximize productivity by minimizing mistakes [Babich, 1986] l Changes should be: analyzed in advance recorded before implementation reported on a need-to-know basis controlled to improve quality and reduce error

Software Configuration Management (SCM) l Umbrella activity with subtasks: Identify change Control change Ensure proper implementation Reporting change(s) to others l Effective change management is a characteristic of good SE

First Law of System Engineering “No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.” [Bersoff et al., 1980] Change management is a life-cycle activity, not just a maintenance activity!

SCI: Software Configuration Item There are a growing number of artifacts to manage during the SE process: Programs Source, binary, resource files Documents Technical docs, user docs Data Inside programs, or in separate files

Relationships Between SCI Objects

Four Sources of Change l New business or market conditions l New customer needs l Reorganization l Budget and scheduling constraints

Baselines baseline (n): “a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.” (IEEE ) Baselines are frozen, final versions of deliverables

Baselined SCIs & Project Database [From SEPA 5/e]

Types of SCIs l Requirements specification l Project plan l Preliminary user manual l Design specification l Source code listing(s) l Test specification l Installation / operation manuals l Executable program(s)

Types of SCIs [2] l Database description l As-built user manual l Maintenance documents l Standards and procedures

SCM Tasks l Identification l Version control l Change control l Configuration auditing l Reporting

SCI Identification l Every SCI has: a name, a description, resource list a “realization” (pointer to code/text/etc.) l Basic vs. Aggregate objects aggregates contain other aggregates or basic objects aggregates have no “realization”

The Version Space [From SEPA 5/e] Note: A particular “version” of an entity might have several variants!

Evolution of SCI Objects [From SEPA 5/e] Alternate implementations may be developed & evaluated in parallel

Controlled Evolution l Tools to model change in the evolution graph, e.g.: RCS (Revision Control System) CVS (Concurrent Versioning System) l Version Control Procedures and tools to manage different versions of objects Both access and synchronization must be controlled

[From SEPA 5/e] Access & Synchronization Control

Deciding Whether to Make a Change [From SEPA 5/e]

Making the Change [From SEPA 5/e]

Testing the Change [From SEPA 5/e]

Configuration Audit l Review the state of an SCI: Specified change completed? Technical review? SE standards followed? Change documented? SCM notification procedures followed? Related SCIs updated?

Example: GNATS l Change request management based on “Problem Reports” (PRs) l GNATS is freely available: l Tracks a PR from initial creation (by the customer) to final closure (after release testing)

GNATS PRs l Problem reports include: Originator, date, status, priority Software version, input / output Description of problem Responsibility assignment Proposed solution & time estimate Test data

PR Process l Customer: submits initial PR l Manager: classify / route internally prioritize PRs with customer l Developer: identify error, if any propose solution, estimate time create test data implement / test / document change

Questions?