Requirements to Configuration Management Systems to Support ...

Hilda Tellioglu - 1

Requirements to Configuration Management Systems to Support Collaboration in Software Production Hilda Tellioglu Vienna University of Technology Institute for Design and Assessment of Technology, Department for CSCW Argentinierstrasse 8/187, A-1040 Vienna, Austria email: [email protected] phone: +43.1.58801.4492 fax: +43.1.5042478

Abstract Configuration management (CM) is a 'supporting' discipline for software implementation. First of all CM enables collaboration between the members of a software production team. The work practices of these teams depend on the organizational settings, on the type of the intended software product, on the characteristics and programming styles of the team members, and on the tools they use to support their activities. After a short description of CM systems this paper reports about the experiences of two software production groups with software CM, and about the differences of handling with the configuration of software systems. On the one hand, the available CM systems offer a lot of functions to support the designers during software production, but there are still a lot of features missing. On the other hand, even if a CM system is integrated in a work environment, its optimal use requires additional organizational arrangements. The degree of its integration depends on the actors and their work practices. Through a distinction between supported and non-supported issues by CM systems the necessary organizational conditions and further requirements to CM systems are described.

2

Hilda Tellioglu - 3

1 Introduction During software production a large number of information items are created. Pressman describes these information items within three categories (1992): computer programs including source, header, resource, object, executable and library files; documents that describe the computer programs on both the practitioners' and users' side; data structures in and outside the programs. Normally, one person (designer) creates one information item which has to be used by another in the team. Sometimes it is necessary to make a step backwards, and reuse or recreate an information item again, and perhaps in a different way. The changes made to items and the status of the processes, whether information items have been already created and the process is finished, or they are actually being changed, etc., must be visible to all team members in order to be able to continue with the work. To manage the creation of information items and dependencies between them, is a complex process and can be supported by means of configuration management. Configuration management (CM) as a 'supporting' discipline is a methodology to manage the development of computer systems. It is defined as 'the discipline of identifying the configuration of a system1 at discrete points in time for purposes of systematically controlling changes to this configuration and maintaining the integrity and traceability of this configuration throughout the system life cycle' (Bersoff et al., 1980, p.20). CM is used (Rigby, 1996): to identify and document the functional and physical characteristics of information items (identification); to audit the information items to verify conformance to specifications, interface control documents and other contract requirements (audit and review); to control changes to information items and their related documentation (control); to record and report information needed to manage information items effectively, including the status of proposed changes and the implementation status of approved changes (status accounting). These four functions build up the classic operational aspects of CM defined originally by IEEE standard 729-1983 (IEEE, 1987). CM must also be defined as 'one of the most essential project management disciplines, which should give customers confidence, support management by supplying reliable contractual, requirement, resourcing and deliverables information and, above all, take the strain off the engineers by allowing them to concentrate on their

1

With system they mean a regularly interacting group of three items (software, hardware that hosts the software and other hardware) utilizing computers and software by forming a unified whole (Bersoff et al., 1980, p.7).

design and implementation without worrying about loss of data, corruption of files, illegal access, etc.' (Kelly, 1996, p.2). CM systems can be categorized by their structure and by their functionality. Analyzing their structure there are significant differences among various CM systems (Cronk, 1992, p.178ff); the system can be file- or object-oriented, it can represent changes physically or logically, and it can apply changes sequentially or selectively2. As archiving/retrieval systems of program versions, CM systems containing a version control system controlling the changes to information items, an object module librarian managing the object codes and a make utility as an automatic system builder, create a shared software production environment for all actors involved. Ad hoc data access to produce individual reports which include system information is also enabled. For medium- and large-scale projects which can be categorized as 'multiple-person, network-based projects', CM is a practical necessity (Tellioglu, 1995). The currently available CM tools are mainly stand-alone applications, and do not exchange (configuration) data with other standard applications (or software design and development tool kits). All functions of the common CM tools, like PVCS, MKS, RCS, CVS, etc., are usually arranged around a central repository, and users can access the CM functions only through the CM application itself. 2

There are two main groups of CM models (Cronk, 1992); the sequential and selectable-change models. The sequential model supports the building of systems for archiving and retrieval of previously named versions and not for really managing the software system. The version is the fundamental unit of specifications. Differences between an old version and its successor represent changes. Files are used to save the changes physically, and therefore the system is limited to the kinds of information available in files (e.g. names and contents of files). The system can retrieve only the versions that are read into it. The basic type - the 'linear sequential model' - does not provide a good method of dealing with parallel versions, whereas the 'branched sequential model' allows developers to work with parallel versions through branching and merging. A tree of versions is created which can be retrieved by the system any time. DEC's Code Management System (CMS), Intersolve's PVCS and Mortice Kern Systems (MKS) are some examples of tools based on the sequential model. PVCS will be described thoroughly within the scope of the case study in the following sections. The second type of CM systems are based on the selectablechange model. They are more than simple version-retrieval systems. They are object-oriented, and therefore a change saved logically as an object can be associated with whatever information is meaningful to the developer. With this system new combinations of prior changes can be selected to produce new versions; an old version of the file (e.g. a source code or an object file) can be compared to an altered version and applied independently. This is made possible by characterizing each version (implicitly or explicitly) by a list of changes to be administered. The change builds the fundamental unit of specifications. Any combination of changes can be used to specify a version (Tellioglu, 1995b). There are some CM systems based on selectable-change model, such as Aide-de-Camp, IBM Update, CDC Update and Historian Plus.

4

Hilda Tellioglu - 5

Some of them enable access to their functions and subprograms through calling single commands on a command line level. With the help of macro programming or configuring/entering the exact command with its options, some sophisticated (source code) editors, like Multiedit, enable configurable parametrized interfaces to call CM functions directly from the editor. Besides there is no more support by the CM tools to integrate different applications or development tools. Some of the object-oriented CM tools enable the creation of views, but only in a very restricted manner. The file and object structure of the configured items can only be viewed depending on the actual edited/changed files and substructures. The formats of the views are almost always fix, and the available interfaces to access CM data cannot be changed by users depending on their specific needs and requests. In the next section, I want to define the relation between CM and software production showing the configuration items created or updated during software production, and the appropriate CM functions required. The third section contains short description of case studies in two software production teams regarding their work practices from the CM point of view. The missing functions of the available CM tools with further requirements to offer more flexible and comfortable support for collaboration within software design/development teams and across organizational boundaries (among managers, sales and customer support personal, documentation departments, external testers, etc. and also to customers) are shown in the forth section.

2 Configuration management and software production The links between the phases of software production and CM in relation to information items are summarized in the Figure 1. It shows the traditional software life cycle3. Change/request management, reporting, revision/version and promotion management of different software production phases (from the software life cycle point of view) are continuous processes accompanying the whole software production work. During the design of data, software architecture, program procedures, test data and specifications, module identification and dependency definitions between these modules can be created by using CM systems. Module identification is followed by source code control and object library management which support coding, testing and maintaining the intended software. Through a change/request management system, bugs can be easily localized. An integrated system builder which supports the change/request management system with inputs looks after reliable, unique and consistent software building, and reduces work overhead.

3

It goes without saying that there are other common software engineering methods applied for systems production, like participatory approach, prototyping, etc. These and temporally iterations are not discussed here for simplicity reasons.

6

Hilda Tellioglu - 7

Figure 1. Relationship between information items and CM during software systems production. By differentiating the functionality of existing CM systems three categories (which show also the project size and development environment) can be defined: 1st level CM systems supporting designers and developers, 2nd level CM systems supporting project managers, and 3rd level CM systems supporting company wide requirements. 1st level CM systems include a lot of technical mechanisms to determine the software system's organization and construction, the identification of all modules that make up the system, the description of each module in the system and description of interdependencies between modules. 2nd level CM systems support project managers during their coordination of resources which can be persons, time, development environment, etc. These are coordination and reporting tools producing managers an overview about work processes and distribution of responsibilities within a team. Not every data type is necessarily visible to project managers. The coordination of different projects within a company and reuse of project parts in several projects are enabled through the 3rd level CM systems. Again, the data produced in the 1st and 2nd level is not necessarily transparent to users of the 3rd level.

3 Two cases In this section two cases are described to show work practices of software production teams. The purpose of analyzing their work practices is to determine which functions needed during all software production phases are supported by available CM systems, which are missing and which issues depend on actors’ work style and practices. From a large number of case studies two teams are chosen that enable on the one hand comparison between work practices around CM, and on the other hand descriptions of (computer supported or paper-based) CM systems in use.

3.1 The method The method of these investigations is based on the idea of producing ethnography of design work in a variety of contexts which provide “rich descriptions of particular relevant practices” (Blomberg et al., 1993). This approach rests on the grounds that the whole complex patterning of social activity derives from the practices of members themselves and not from the enactment of some underlying scheme which they have simply internalized. This is an important resource for the researcher, since it can be followed 'in the doing'. A useful approach for this purpose is to look at software development as taking place in and being shaped by communities of practice: “Communities of practice (COPs) are naturally occurring groups of people that arise more or less spontaneously around a particular task, technology or enterprise. The COP is the basic social unit that gets the work done. ... A COP could be any group of people who work together to accomplish some activity (their practice), usually involving collaboration between individuals with different roles and experience' (Jordan, 1993). We can look at the knowledge and skills on which software development is based as embedded in COP. Through interviews with some of the key participants of described project teams and through observations during different phases of the software production, I tried to find out how actors communicate and cooperate, and what their work practices are.

3.2 The first case This is the case4 of a software development team of a large manufacturer in Denmark (Carstensen et al., 1994, p.6f). The company produce instruments 4

This case description is connected to an ongoing research project by Peter Carstensen, Kjeld Schmidt and Carsten S¿rensen, Ris¿ Research Laboratory. Most of their field work in this context focuses on a variety of engineering aspects and on software testing, little attention however has been paid to the software development process. This case description is partly based on an interview I made with members of the research team, in particular with Peter Carstensen.

8

Hilda Tellioglu - 9

consisting of mechanical, electronic, chemical, optical and software components to measure quality parameters of agricultural products. The software part was implemented by the software development team, a group of between 5 and 12 software designers. Top managers of the company did not trust the software designers to successfully complete their task (Wagner and Tellioglu, 1995, p.91ff). The software designers decided to prove their ability to finish this project successfully. So the team set out to develop their own platform and some common standards such as how to document the software, how to specify the functionality and how to structure the code. Only one of the designers had a complete overview of the software consisting of approximately 20 modules. They did not use any software CM tool, but they defined a procedure for software developing process which enabled partly managing collaboration within the team, and through this the configuration of the software. The team made some important decisions with regard to the organization of their work. Three of the software designers were building a so-called 'spec-team'. They were responsible for diagnosing the bugs and for organizing the correction of the bugs by the right designer within a reasonable time limit. They have established some division of labor. One of the spec-team, called 'plan manager', was creating and updating regularly the ‘work plans’ of the designers. They contained the information needed for creating an overview of the project status and of the responsibilities, including a schedule of ongoing activities. Every time a new task was identified or a bug was corrected, the work plan should be updated. This was done during the so-called 'integration period'. The integration period marked out the time when all designers meet physically to align their work. The team has divided its work into two periods - four weeks for developing and one week for integrating the program modules. This week was also called 'platform period'. The software designer who was responsible for creating a new version of the entire program in this predefined platform period was called 'platform master'. This was a rotating assignment. Defining the structure of the program modules was done on the central computer where all files of one module were saved in one directory. Each designer was responsible for putting all files onto this server at least at 12 o'clock Monday morning before the integration period started. In this phase all met in one room and explained to each other what they had done over the last weeks. The meeting was not terminated before they had agreed on how to handle the problems that had come up. Either they could decide on a solution during the meeting or they put it on the agenda for the next one. In these integration periods no programming took place so that all files could be reviewed together, and parallel developments and the resulting inconsistencies could be

avoided. If a designer was going to add a new file into the program structure on the server, he told this to the platform master who changed the link utility which was a batch file, also adding the new file name to include it into the link process. If changes were needed during the integration period, some of the designers worked on them immediately, and uploaded the new version onto the server. To create a new program version, the platform master used his link utility. The platform master worked through a pile of bug reports which have been reported corrected, testing the software thoroughly 5.

3.3 The second case This is the case6 of a software house producing applications for insurance companies (Wagner and Tellioglu, 1995, p.83ff). The main customer of this company is very powerful. A Technical Coordinator who is a member of the customer's own IT department specifies requirements in great detail, decides which technical platforms and tools to use, and enforces quality standards. As part of this, the software company was required to obtain the ISO-9001 certificate and to use the CM tool PVCS7. The development team and their Project Manager are located in the software company. Their link to their client is the Technical Coordinator. The maintenance and update of 40 programs including 5000 subprograms are the responsibility of this development team consisting of 10 software developers and their Project Manager. It operates in a shared and highly integrated organizational-technical environment. The Project Manager is the central actor on the software house side. He provides the link to the customer through the Technical Coordinator; he distributes the work to be done and manages the software teams. This includes keeping track of the progress of work, looking through the series of detailed check lists by which work is monitored, creating new versions (using PVCS). The Project Manager is the person who receives bug reports, manages program changes and responds to new requirements. Software development in this team is closely monitored. There are written guidelines for the development process, and a manual to quality assurance. In addition, there is a series of check lists which ensure a detailed documentation of all work done. The system of check lists is designed in a way which both, ensures

5

The practice of generating and handling bug reports has been documented and analyzed in detail; see (Carstensen and S¿rensen, 1994). Currently, the Risø team is building a prototype bug report system. 6 This case description is based on field work done by Christine Hartberger as part of her MA thesis on CSCW aspects of software design and development. 7 PVCS is the CM product of Intersolv (Intersolv, 1991).

10

Hilda Tellioglu - 11

'orderly practice' and mutual control. Each team member acts as a developer and simultaneously as a controller of a piece of work developed by someone else. In this way an elaborate system of peer-review is created. Besides several tools, PVCS is used as a CM tool since approximately one year. It was introduced only because the customer required it, and developers felt the overhead to be too high and unnecessary. It was found that the tool produced much too long response times during the creation of new versions, and the benefit of having a tool which in fact reproduces the files and the program versions was not appreciated. Only when all the modules of existing projects had been successively integrated into the PVCS, the developers started experiencing the advantage of having an overview of programs and program changes. The creation of new versions is normally done by the Project Manager: First of all, he requires that all developers put their modules back onto the central unit (server) and unlock them. He then locks all files, and creates a new system version. Afterwards all files can be unlocked again to further development. Inconsistencies are visible during this process, such as if one developer forgets to put one of the files onto the server, or if an old revision of a file is put instead of the new one, etc. Of course all files which build up the software system and all interfaces between modules are tested properly before the final system is created. Developers use PVCS to access the files on the server: When starting a new task, developers from their local machine send an access request onto the server via PVCS. If the requested item is idle, i.e. not locked by another developer, PVCS allows the access to this item. The read access need not to be documented. In case of a write access, the item is locked by marking it with appropriate information like developer’s identification, date and type of access, etc. If another developer wants to make modifications to the same files, s/he tries to get the file by sending a request to the server as well. But PVCS replies to this request with a denial by attaching the appropriate information. In this case, the second developer contacts the first one, and requires a branch of the locked item. First developer unlocks the item after putting it back onto the server. Now, a branch of the item can be created with the corresponding branch numbers for identification and to enable a merge at a later time. Both developers get their branched items and lock them. After modifications and tests developers can merge their items on the server, and PVCS gives a new revision to the created new item. This branch and merge functions enable to work parallel on the same information items at the same time without loosing or overwriting the synchronous changes (Tellioglu, 1995). The team usually avoid to work with branched files although it is very easy to handle with

PVCS. If one developer needs a source file and recognizes that it is locked by someone else, they communicate directly, exchanging information about intended or ongoing changes, and the person who is in the process of working with this file might perform the modifications for both of them. As each developer has to generate a particular document file for each program where all changes and new features are described, they do not add detailed comments to files managed with PVCS. Not all functions of PVCS are actually used. Developers prefer to work with the ‘software implementation form’, which can be considered as a paper-based workflow management tool, for keeping track of activities and changes rather than the promotion management facility of PVCS.

3.4 The CM practices in both cases CM systems are essential to support the collaboration within a software production team. They enable to keep track of all tasks, and to maintain the software versions and dependencies between all modules. A common understanding of the structure and organization of software modules building up the software system must be produced with the help of CM systems. It is also necessary that the developers understand the importance of such systems, and use them regularly to insure the consistency of the software product. The described cases show varying organizational settings and values regarding work practices which strongly influences the acceptance and use of CM systems. In the first case the developers try to survive. They create a system mirroring the usual CM procedures. They need more time for these procedures than it would have taken them by using a CM system. They often don't succeed to keep the software configuration consistent through all periods of development. They make a lot of mistakes, and they start again and again to get rid of them. Their current CM practices are not totally stable and reliable. Only ‘specteam’ especially ‘plan manager’ has an overview of the whole software system that is not well-structured in terms of CM. The system’s organization is more a mapping of responsibilities within the team than showing the system structure. All modules are saved on the central computer in one directory. By means of ‘work plans’ a link between responsibilities, schedules, dependencies and, through all these, project status could be generated. There is no additional descriptions of modules and of their dependencies. The team has no possibility to keep track of changes to the modules. After each ‘integration period’ they begin working on a new set of modules as a new base for further development. Old versions can not be reproduced, and past

12


changes can not be found. Program errors are visible to ‘spec-team’ because they are responsible for diagnosing the bugs and arranging their correction. System inconsistencies could not be discovered until the ‘integration period’. There is no computer support to create versions, reproduce old versions, and enable a unique (software) system production environment. To create new software systems a link utility is used by the ‘platform master’. Only the program version created during the integration period is available on the server until it is replaced during the next integration period. After creating a new program version, the platform master sometimes forgets to change the version number of the program. That means, nothing is updated regarding the version, and all new files belonging to the new version are still saved in the old directory. This problem can be solved on the spot, since designers can be asked not to use the current directory until a new one is generated. Sometimes the designers forgets to tell the platform master that they have added new files to the modules on the server. When linking the modules the platform master receives an error message indicating some inconsistency. He can than locate the error and the person who is responsible for the module. Some of the designers also forget to compile the source files before uploading them onto the server. Errors like these happen very often. Table 1 summarizes the CM practices in this case. In the second case the team is enforced to use PVCS, but they are not convinced of its necessity and importance. Although PVCS offers different tools to support software production, this team prefers to use paper-based documents, like ‘software implementation form’ or check lists, to keep track of activities. After successively integration of all modules into PVCS, they create an overview of software structure by using PVCS. They do not comment the files on-line, but produce an extra document per release. Although they have the possibility to work on the same modules simultaneously, they do not prefer to do so. They use their lists and paper-based forms to organize their work instead of making an efficient use of PVCS (i.e. promotion manager, change/request management, report system). Through mutual control and peer-review system inconsistencies and program errors can be found. Reporting of these is done on check lists instead of using tracking and reporting facilities of PVCS. Guidelines are used to define how to work include naming conventions, coding styles, documentation of modules, changes and system versions, error reports, etc. Neither the Technical Coordinator nor the developers are using PVCS to handle with new requirements and bug reports. Instead of using PVCS they created their own specific database applications which are not compatible with each other. The

Technical Coordinator collects new requirements and error reports in a database to which the software company has only a remote read access. He regularly creates print outs of these reports which are forwarded to the development team. Parallel to this each of the developers maintain their own database of error reports; it supports the documentation of program changes and the production of statistical surveys of bug fix activities. They use make utilities to create their modules and new versions. PVCS is mainly used to manage the system versions. Table 2 summarizes the mentioned issues.

14


4 Further requirements to CM systems: What is still missing? CM helps the actors in a team to cooperate with each other and to make a collaboration within the team. The distribution of responsibilities and the control of process can be supported by sophisticated CM systems. The necessity of using CM systems increases with the number of actors involved in the software systems production, with the complexity of both the intended system and the development environment, and with the need to modify the same information items simultaneously. Besides all these issues, a CM system cannot be efficient and effective enough without being supported by the actors using it and by their work practices. The tools that support CM practices can be seen as serving mainly three purposes: (i) to create an overview of the software system (organization, construction, identification and description of its modules, dependency definitions and project status); (ii) to allow for control and visibility of changes, program errors and system inconsistencies; (iii) and integration support (system building, creating versions and revisions, libraries). The Table 3 summarizes the main functions supported by CM systems and fields which are dependent on actors' handling and work practices. Besides the main CM functions enabling overview, control, visibility, and integration support, available CM tools do not offer additional features to respond to new technological and organizational changes like software production in a wide area network, or a standard interface (for instance in HTML format) for every user type (like for real end users, managers, developers, testers, vendors, etc.). In the following new requirements to CM systems are summarized: • Real support to create integrated work environments must be offered by the CM tools. For software development different tools are necessary. Not only the CM tool and editor, but also other tools like debugger, linker, database viewer, project management and presentation tool, reporter, etc. must be able to exchange data or at least to import data from the CM repository. Through application programming interfaces it is possible to call CM functions directly from other applications, like editors, browsers, databases, documentation and presentation tools, etc. Using APIs helps to avoid the restrictions of command line calling of CM subprograms and functions. • The central unit of most CM systems is used to save all CM data that contain not only CM items, but metalevel data about these items as well. The metadata is partly created and saved directly by the CM tool itself (e.g. date, user initials, executed changes, etc.) and partly generated by users (e.g. comments,

remarks, annotations, etc.). Most file-oriented CM systems have implemented delta-storing. They put the updates and differences to the old revisions/versions into a file that they use as a database/repository and access sequentially. This type of access is a restriction because it can be done only by using the specific CM tool. New CM tools must enhance the data access functions. They have to use standard databases as their repositories and enable standardized interfaces to access database data like through SQL. The use of standard databases and query languages makes the work with views possible: a project manager in the development department can see all data saved through CM tool, a designer/developer can access only his/her files and the necessary test environment, whereas a tester or a customer can have access to the change requests and bug reports. Additionally, remote access to the central CM repository must be enabled if the software production team is geographically distributed. • Functions to create statistics and reports are often necessary to support the decision making not only within the design/development team, but on the management and marketing level as well. Visualization tools must be integrated into CM tools or CM tools must be able to export data that can be used to create different diagrams, graphics, tables or other types of visualizations. • Through an integrated email system developers can be notified of the new requests, testers can be called to test new executables, so communication between all people involved can be supported, especially if they work in separate locations. • Integrated electronic scheduler can help to arrange meetings, deadlines, demonstrations, etc. • Integrated hyperlinking tools and functions can be used to create, access and manage annotations to the CM data, to link different type of documents (for instance technical documentation in HTML format) to appropriate source files. • Other functions supporting project management by producing data that is relevant for project management, by enabling simulations for time estimations or responsibility distribution, by enabling to keep track of human efforts during all phases of software production, by enabling the management of dependencies not only on the base of software components, but on the human level as well. Access to data specifying dependencies between human/time resources and work processes must also be enabled.

16


5 Conclusion Being only a discipline and not an enforcing arrangement which must be definitely fulfilled before the next steps can be taken, CM's objectives, needs and functions can not be completely performed by means of technical tools. On the one hand additional organizational actions are required. The fields in which the fulfillment of CM's requirements is mainly dependent on actors and their work practices, and the benefits of using a CM system must be understood by all actors involved. On the other hand, new features must be added to available CM tools in order to enable a real support to collaboration within a software production team, and to make the software production easier, faster and more efficient than it is now.

6 References E. H. Bersoff, V. D. Henderson and S. G. Siegel. Software Configuration Management. An Investment in Product Integrity. Prentice-Hall Inc., Englewood Cliffs, New Jersey (1980). J. Blomberg et al. Ethnographic Field Methods and the Relation to Design. Participatory Design: Principles and Practices, eds. D. Schuler and A. Namioka, Lawrence Erlbaum Associates, Inc., Hillsdale, New Jersey, 123-156 (1993). P. Carstensen, C. S¿rensen and T. Tuikka. Let's Talk About Bugs! Scandinavian Journal of Information Systems, 7/1 (1995). P. Carstensen and C. S¿rensen. The Foss cases. Social Mechanisms of Interaction, COMIC-D3.2, Report, Lancaster University, 297-306 (1994). R. D. Cronk. Tributaries and Deltas. Tracking software change in multiplatform environments. Byte, 177-186, January (1992). IEEE. IEEE Guide to Software Configuration Management. IEEE/ANSI Standard 1042 (1987). Intersolv. PVCS. User's Reference Manual. Beaverton, OR (1991). B. Jordan. Ethnographic Workplace Studies and CSCW. Paper presented at the International Conference on the Design of Computer Supported Cooperative Work and Groupware Systems. SchŠrding, Austria (1993). M. V. Kelly. Configuration Management. The Changing Image. McGraw-Hill Book Company, London (1996). R. S. Pressman. Software Engineering. A Practitioner's Approach. McGraw-Hill, New York (1992). K. Rigby. Configuration Management Plan Model text, http://www.airtime.co.uk/users/ wysywig/cmp.htm (1996). H. Tellioglu. Software Technology in a Networked Computer Environment: Configuration Management in Software Design and Development Teams. Proceedings of the Conference Network Entities (NETIES), Athens (1995). H. Tellioglu and I. Wagner. Negotiating Boundaries. Practices of Configuration Management in Software Development Teams. Computer Supported Cooperative Work (CSCW). An International Journal (1997). I. Wagner and H. Tellioglu. Software Cultures. The influence of work organization, management style and occupational culture on systems designers’ approaches in a cross-cultural perspective, Final Report of the COST A4 Research Project.

18


Forschungsarbeiten der Abteilung für CSCW am Institut fŸr Gestaltungs- und Wirkungsforschung der TU Wien, 4, Vienna (1995).

1st level CM

paper-based

Module identification Dependency definition

only naming conventions, no other documentation on ‘work plan’, actors’ responsibilities show module dependencies only during ‘integration period’

Source code control Object library management System building

not used varying batch files used by designers, link utility used by ‘platform master’

2nd level CM

paper-based

Change/Request management

bug reports only visible to ‘spec-team’ and ‘platform master’, no change control bug reports, ‘work plan’, information exchange during ‘integration periods’

Report system 3rd level CM

paper-based

Revision/Version management information exchange during ‘integration periods’, new version created by ‘platform master’, only last version is available Promotion management not used Table 1. A summary of CM practices in the first case.

20


1st level CM

computer supported and paper-based

Module identification

‘software implementation form’, guidelines, later PVCS ‘software implementation form’, guidelines, later PVCS ‘software implementation form’, guidelines, later PVCS without detailed comments to code

Dependency definition Source code control Object library management System building

not used make utilities of PVCS

2nd level CM


Change/Request management

different types of databases used by customer and developers, printouts, ‘software implementation form’, later PVCS

Report system

‘check lists’, peer-review, visible only to Project Manager

3rd level CM


Revision/Version management PVCS used by Project Manager Promotion management ‘software implementation form’ Table 2. A summary of CM practices in the second case.

Supported by CM systems Overview

Not supported by CM systems, dependent on actor and practices

system's organization and structure: highly structured programs; transparent to all

definition of program structures

module identification

well-disciplined and robust naming conventions

module descriptions: basic detailed descriptions descriptions in the module headers module dependencies

dependency definitions and design specifications

project status: visible to all; consistent comments to project feedback of shipped, tested, versions developed and designed versions Control and Visibility

Integration Support

changes (in design and coding): well-disciplined comments to represented as files; easy modules about changes management of all documented changes; transparent to all; shared development environment program errors: visible to all

location and correction of errors, code check

check and report of system inconsistencies

correction of system inconsistencies

system building: standard; make actor practices of using make utilities utilities creating versions and revisions: allocating responsibilities for easy reproducibility of old creating versions versions, good overview of existing versions of modules linking facilities

definition of libraries

Table 3. Supported and non-supported issues by CM systems.

22