Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering Lecture 9: Configuration Management.

Similar presentations


Presentation on theme: "Software Engineering Lecture 9: Configuration Management."— Presentation transcript:

1 Software Engineering Lecture 9: Configuration Management

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

3 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

4 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

5 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!

6 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

7 Relationships Between SCI Objects

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

9 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 610.12-1990) Baselines are frozen, final versions of deliverables

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

11 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)

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

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

14 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”

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

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

17 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

18 [From SEPA 5/e] Access & Synchronization Control

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

20 Making the Change [From SEPA 5/e]

21 Testing the Change [From SEPA 5/e]

22 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?

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

24 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

25 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

26 Questions?


Download ppt "Software Engineering Lecture 9: Configuration Management."

Similar presentations


Ads by Google