Tehtävänanto (lyhennetty): Olet menestyvän KillerApp-ohjelmiston kehitystiimissä. Tehtävänäsi on toteuttaa ohjelmiston konfiguraation hallinnan prosessi (configuration management). Kirjoita ehdotus, kuinka tämä prosessi toteutetaan.. Essee arvosteltiin asteikolla 0-10 p. Essee oli osa Teknillisen korkeakoulun kurssin T-76.3601 Ohjelmistotuotannon perusteet suorittamista. Esseen kieli on englanti.

Essay 5 - Software Configuration Management

Software configuration management (SCM), also know as change management, is a set of activities that have been developed to manage change throughout the entire life cycle of computer software. Change will always happen and SCM tries to put some order to these changes.

The first thing to put up SCM is to identify and organize all the software configuration items (SCIs) such as source files, test cases, requirements and so on. After that we must create a version control mechanism, like using a central repository where all the software configuration items are stored and versioned. This doesn't just mean source files but also specifications, requirements, test plans, data and user manuals etc. The repository also ensures data integrity and supports information sharing. So all the SCIs are available to all designers of the project.

If something goes terribly wrong, one can always revert to previous versions. Version control also helps in bug tracking. When a customer complains about some bug in the software, we can first check that is it already fixed. If not, we must know what version is the customer using and from the repository, we can test that version and see if we can repeat the bug and repair it.

The next thing to do is to create and approve some process that controls changing the SCIs. Because we have already a working product on market, it is wise to make that as a product baseline. So any changes to this baseline must have to go through a formal change control. This could be, for example, that developer making a change must get an approval from the project manager and a formal technical review must be done to the changed SCI.

This control is closely related to software quality assurance (SQA) activities. By having these formal change processes, we can assure that the changes made don't cause some non-intended side effects and the system's quality is still good. One must have also some sort of dependency tracking mechanism so that one can see how a change to one SCI affects the others. For example, if a new function is added to the program, perhaps the user manual should also be modified. One must notice that too loose change control creates chaos but too tight change control isn't good either. So some sort of balance between them must be found. If the product had not been released or baselined, change control could have been more informal.

Very important part of the SCM is the status reporting. This involves to keep track what changes have been made, who did them and when they happened. Every time when a change is made, it is recorded. Also on a regular basis, a report is made where all the designers can see what important changes have been made to the system.

References:

• Pressman. 2005. Software Engineering: A Practitioner's Approach, 6th edition. McGraw-Hill. 912 s. ISBN 007-123840-9.