Requirements to Configuration Management Systems to Support Collaboration in Software Production
|
|
- Dwayne Rodgers
- 8 years ago
- Views:
Transcription
1 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 hilda.tellioglu@tuwien.ac.at phone: fax:
2 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
3 Hilda Tellioglu 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 system 1 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 (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).
4 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 selectively 2. 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
5 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.
6 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 cycle 3. 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
7 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: 1 st level CM systems supporting designers and developers, 2 nd level CM systems supporting project managers, and 3 rd level CM systems supporting company wide requirements. 1 st 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. 2 nd 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 3 rd level CM systems. Again, the data produced in the 1 st and 2 nd level is not necessarily transparent to users of the 3 rd level.
8 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 case 4 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
9 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
10 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 The second case This is the case 6 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 PVCS 7. 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
11 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
12 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
13 Hilda Tellioglu - 13 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
14 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
15 Hilda Tellioglu 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,
16 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 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
17 Hilda Tellioglu 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.
18 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, (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, (1994). R. D. Cronk. Tributaries and Deltas. Tracking software change in multiplatform environments. Byte, , 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, 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
19 Hilda Tellioglu - 19 Forschungsarbeiten der Abteilung für CSCW am Institut fÿr Gestaltungs- und Wirkungsforschung der TU Wien, 4, Vienna (1995).
20 1st level CM Module identification Dependency definition Source code control Object library management System building paper-based only naming conventions, no other documentation on work plan, actors responsibilities show module dependencies only during integration period not used 2 nd level CM paper-based Change/Request management Report system 3 rd level CM paper-based varying batch files used by designers, link utility used by platform master bug reports only visible to spec-team and platform master, no change control bug reports, work plan, information exchange during integration periods 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
21 Hilda Tellioglu st level CM Module identification Dependency definition Source code control Object library management System building computer supported and paper-based software implementation form, guidelines, later PVCS software implementation form, guidelines, later PVCS software implementation form, guidelines, later PVCS without detailed comments to code not used make utilities of PVCS 2 nd level CM computer supported and paper-based Change/Request management Report system different types of databases used by customer and developers, printouts, software implementation form, later PVCS check lists, peer-review, visible only to Project Manager 3 rd level CM computer supported and paper-based Revision/Version management PVCS used by Project Manager Promotion management software implementation form Table 2. A summary of CM practices in the second case.
22 Overview Control and Visibility Integration Support Supported by CM systems system's organization and structure: highly structured programs; transparent to all module identification Not supported by CM systems, dependent on actor and practices definition of program structures well-disciplined and robust naming conventions module descriptions: basic detailed descriptions descriptions in the module headers module dependencies project status: visible to all; feedback of shipped, tested, developed and designed versions dependency definitions and design specifications consistent comments to project versions 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 check and report of system inconsistencies system building: standard; make utilities location and correction of errors, code check correction of system inconsistencies actor practices of using make 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
Enterprise 2.0 in Action: Potentials for Improvement of Awareness Support in Enterprises
Enterprise 2.0 in Action: Potentials for Improvement of Awareness Support in Enterprises Hilda Tellioglu & Simon Diesenreiter Institute of Design and Assessment of Technology Vienna University of Technology,
More informationThe 7 Attributes of a Good Software Configuration Management System
Software Development Best Practices The 7 Attributes of a Good Software Configuration Management System Robert Kennedy IBM Rational software Benefits of Business Driven Development GOVERNANCE DASHBOARD
More informationConfiguration Management. Software Configuration Management. Example of System Families. Configuration Management
Configuration Management Software Configuration Management New versions of software systems are created as they change: For different machines/os; Offering different functionality; Tailored for particular
More informationF15. Towards a More Mature Test Process. Anne Mette-Hass. P r e s e n t a t i o n
Towards a More Mature Test Process Anne Mette-Hass International Conference On Software Testing, Analysis & Review November 19-23 Stockholm, Sweden P r e s e n t a t i o n F15 Friday 23rd November, 2001
More informationWhat Is Software Configuration Management?
C H A P T E R 1 What Is Software Configuration Management? The title of this chapter asks such a simple question, the answer to which, one would think, ought to be known by anyone with any kind of record
More informationConfiguration management. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1
Configuration management Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1 Objectives To explain the importance of software configuration management (CM) To describe key CM activities
More information1-04-10 Configuration Management: An Object-Based Method Barbara Dumas
1-04-10 Configuration Management: An Object-Based Method Barbara Dumas Payoff Configuration management (CM) helps an organization maintain an inventory of its software assets. In traditional CM systems,
More informationHow To Develop Software
Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which
More informationSoftware Configuration Management (SCM)
Software Configuration Management (SCM) SCM actually consists of several separate yet cumulative disciplines. Version Management is an entry point for SCM T M Abstract : Software Configuration Management
More informationIntellect Platform - The Workflow Engine Basic HelpDesk Troubleticket System - A102
Intellect Platform - The Workflow Engine Basic HelpDesk Troubleticket System - A102 Interneer, Inc. Updated on 2/22/2012 Created by Erika Keresztyen Fahey 2 Workflow - A102 - Basic HelpDesk Ticketing System
More informationEssential Visual Studio Team System
Essential Visual Studio Team System Introduction This course helps software development teams successfully deliver complex software solutions with Microsoft Visual Studio Team System (VSTS). Discover how
More informationCHAPTER 7 Software Configuration Management
CHAPTER 7 Software Configuration Management ACRONYMS CCB CM FCA MTBF PCA SCCB SCI SCM SCMP SCR SCSA SEI/CMMI SQA SRS USNRC INTRODUCTION Configuration Control Board Configuration Management Functional Configuration
More informationSurveying and evaluating tools for managing processes for software intensive systems
Master Thesis in Software Engineering 30 Credits, Advanced Level Surveying and evaluating tools for managing processes for software intensive systems Anuradha Suryadevara IDT Mälardalen University, ABB
More informationPage 1. Outline of the Lecture. What is Software Configuration Management? Why Software Configuration Management?
Books: Software Configuration Management 1. B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering: Using UML, Patterns, and Java (Chapter 13) Outline of the Lecture Purpose of Software Configuration
More informationConfiguration & Build Management
Object-Oriented Software Engineering Using UML, Patterns, and Java Configuration & Build Management Outline of the Lecture Purpose of Software Configuration Management (SCM) Some Terminology Software Configuration
More informationSAP 3D Visual Enterprise Rapid-Deployment Solution
SAP 3D Visual Enterprise 8.0 July 2014 English SAP 3D Visual Enterprise Rapid-Deployment Solution SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf Germany Copyright 2014 SAP AG or an SAP affiliate company.
More informationSoftware Configuration Management Plan
For Database Applications Document ID: Version: 2.0c Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 22 Copyright 2000-2005 Digital Publications LLC.
More informationContinuous Integration. CSC 440: Software Engineering Slide #1
Continuous Integration CSC 440: Software Engineering Slide #1 Topics 1. Continuous integration 2. Configuration management 3. Types of version control 1. None 2. Lock-Modify-Unlock 3. Copy-Modify-Merge
More informationThis presentation introduces you to the Decision Governance Framework that is new in IBM Operational Decision Manager version 8.5 Decision Center.
This presentation introduces you to the Decision Governance Framework that is new in IBM Operational Decision Manager version 8.5 Decision Center. ODM85_DecisionGovernanceFramework.ppt Page 1 of 32 The
More informationAn introduction to the benefits of Application Lifecycle Management
An introduction to the benefits of Application Lifecycle Management IKAN ALM increases team productivity, improves application quality, lowers the costs and speeds up the time-to-market of the entire application
More informationRevision Control. Solutions to Protect Your Documents and Track Workflow WHITE PAPER
Revision Control Solutions to Protect Your Documents and Track Workflow WHITE PAPER Contents Overview 3 Common Revision Control Systems 4 Revision Control Systems 4 Using BarTender with Revision Control
More informationThe preliminary design of a wearable computer for supporting Construction Progress Monitoring
The preliminary design of a wearable computer for supporting Construction Progress Monitoring 1 Introduction Jan Reinhardt, TU - Dresden Prof. James H. Garrett,Jr., Carnegie Mellon University Prof. Raimar
More informationIncreasing business values with efficient Software Configuration Management
Increasing business values with efficient Software Configuration Management A Softhouse White Paper Leif Trulsson February 2005 Softhouse Consulting, Stormgatan 14, SE-211 20 Malmö info@softhouse.se www.softhouse.se
More informationSubversion Integration for Visual Studio
Subversion Integration for Visual Studio VisualSVN Team VisualSVN: Subversion Integration for Visual Studio VisualSVN Team Copyright 2005-2008 VisualSVN Team Windows is a registered trademark of Microsoft
More informationIncreasing Development Knowledge with EPFC
The Eclipse Process Framework Composer Increasing Development Knowledge with EPFC Are all your developers on the same page? Are they all using the best practices and the same best practices for agile,
More informationSoftware Configuration Management. Context. Learning Objectives
Software Configuration Management Wolfgang Emmerich Professor of Distributed Computing University College London http://sse.cs.ucl.ac.uk Context Requirements Inception Elaboration Construction Transition
More informationAccess Control and Audit Trail Software
Varian, Inc. 2700 Mitchell Drive Walnut Creek, CA 94598-1675/USA Access Control and Audit Trail Software Operation Manual Varian, Inc. 2002 03-914941-00:3 Table of Contents Introduction... 1 Access Control
More informationREVIEW ON THE EFFECTIVENESS OF AGILE UNIFIED PROCESS IN SOFTWARE DEVELOPMENT WITH VAGUE SYSTEM REQUIREMENTS
REVIEW ON THE EFFECTIVENESS OF AGILE UNIFIED PROCESS IN SOFTWARE DEVELOPMENT WITH VAGUE SYSTEM REQUIREMENTS Lisana Universitas Surabaya (UBAYA), Raya Kalirungkut, Surabaya, Indonesia E-Mail: lisana@ubaya.ac.id
More informationGlobal Software Change Management for PVCS Version Manager
Global Software Change Management for PVCS Version Manager... www.ikanalm.com Summary PVCS Version Manager is considered as one of the leading versioning tools that offers complete versioning control.
More informationConfiguration Management for Reusable Software
Configuration Management for Reusable Software William B. Frakes Computer Science Department Virginia Tech wfrakes@vt.edu Abstract This paper discusses the configuration management of reusable software,
More informationDie Mobiliar Insurance Company AG, Switzerland Adaptability and Agile Business Practices
Die Mobiliar Insurance Company AG, Switzerland Adaptability and Agile Business Practices Nominated by ISIS Papyrus Software 1. EXECUTIVE SUMMARY / ABSTRACT The Swiss insurance company Die Mobiliar is the
More informationIntegrity 10. Curriculum Guide
Integrity 10 Curriculum Guide Live Classroom Curriculum Guide Integrity 10 Workflows and Documents Administration Training Integrity 10 SCM Administration Training Integrity 10 SCM Basic User Training
More informationThe Recipe for Sarbanes-Oxley Compliance using Microsoft s SharePoint 2010 platform
The Recipe for Sarbanes-Oxley Compliance using Microsoft s SharePoint 2010 platform Technical Discussion David Churchill CEO DraftPoint Inc. The information contained in this document represents the current
More informationRequirements Management
REQUIREMENTS By Harold Halbleib Requirements Management Identify, Specify, Track and Control Requirements Using a Standard Process About the author... Harold Halbleib has a degree in Electrical Engineering
More informationIn this Lecture you will Learn: Implementation. Software Implementation Tools. Software Implementation Tools
In this Lecture you will Learn: Implementation Chapter 19 About tools used in software implementation How to draw component diagrams How to draw deployment diagrams The tasks involved in testing a system
More informationPart I What Is Configuration Management?
Part I What Is Configuration Management? Configuration, to form from or after, derives from the Latin com-, meaning with or together, and figurare, to form. It also means a relative arrangement of parts
More informationSoftware Configuration Management. Addendum zu Kapitel 13
Software Configuration Management Addendum zu Kapitel 13 Outline Purpose of Software Configuration Management (SCM) Motivation: Why software configuration management? Definition: What is software configuration
More informationD6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013
D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 The purpose of these questions is to establish that the students understand the basic ideas that underpin the course. The answers
More informationFoundations for Systems Development
Foundations for Systems Development ASSIGNMENT 1 Read this assignment introduction. Then, read Chapter 1, The Systems Development Environment, on pages 2 25 in your textbook. What Is Systems Analysis and
More informationBusiness 360 Online - Product concepts and features
Business 360 Online - Product concepts and features Version November 2014 Business 360 Online from Software Innovation is a cloud-based tool for information management. It helps you to work smarter with
More informationVerification and Validation of Software Components and Component Based Software Systems
Chapter 5 29 Verification and Validation of Software Components and Component Based Christina Wallin Industrial Information Technology Software Engineering Processes ABB Corporate Research christina.wallin@mdh.se
More informationTESSY Automated dynamic module/unit and. CTE Classification Tree Editor. integration testing of embedded applications. for test case specifications
TESSY Automated dynamic module/unit and integration testing of embedded applications CTE Classification Tree Editor for test case specifications Automated module/unit testing and debugging at its best
More informationDocument Management. Introduction. CAE DS Product data management, document data management systems and concurrent engineering
Document Management Introduction Document Management aims to manage organizational information expressed in form of electronic documents. Documents in this context can be of any format text, pictures or
More information"Code management in multi programmer environments."
Another installment in the 'Computing in high energy physics' series (16 02 2004). "Code management in multi programmer environments." Author: D. Hatton (DESY/Hamburg) Table of Contents: 1. Overview 2.
More informationTowards Collaborative Requirements Engineering Tool for ERP product customization
Towards Collaborative Requirements Engineering Tool for ERP product customization Boban Celebic, Ruth Breu, Michael Felderer, Florian Häser Institute of Computer Science, University of Innsbruck 6020 Innsbruck,
More informationWHITEPAPER. Managing Design Changes in Enterprise SBM Installations
WHITEPAPER Managing Design Changes in Enterprise SBM Installations By Tom Clement Serena Software, Inc. October 2013 Summary This document explains how to organize your SBM maintenance and development
More informationA system is a set of integrated components interacting with each other to serve a common purpose.
SYSTEM DEVELOPMENT AND THE WATERFALL MODEL What is a System? (Ch. 18) A system is a set of integrated components interacting with each other to serve a common purpose. A computer-based system is a system
More informationIBM Rational ClearCase, Version 8.0
IBM Rational ClearCase, Version 8.0 Improve software and systems delivery with automated software configuration management solutions Highlights Improve software delivery and software development life cycle
More informationAbstract. 1 Introduction
Amir Tomer Amir Tomer is the Director of Systems and Software Engineering Processes at RAFAEL Ltd., Israel,with whom he has been since 1982,holding a variety of systems and software engineering positions,both
More informationCS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping
More informationChapter 13 Configuration Management
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 13 Configuration Management Outline of the Lecture Purpose of Software Configuration Management (SCM)! Motivation: Why software
More informationSoftware Engineering for LabVIEW Applications. Elijah Kerry LabVIEW Product Manager
Software Engineering for LabVIEW Applications Elijah Kerry LabVIEW Product Manager 1 Ensuring Software Quality and Reliability Goals 1. Deliver a working product 2. Prove it works right 3. Mitigate risk
More informationSOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK
Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost
More informationContent Author's Reference and Cookbook
Sitecore CMS 6.2 Content Author's Reference and Cookbook Rev. 091019 Sitecore CMS 6.2 Content Author's Reference and Cookbook A Conceptual Overview and Practical Guide to Using Sitecore Table of Contents
More informationLeveraging TEWI Platform to Enhance Scientific Collaboration on Universities
JOURNAL OF APPLIED COMPUTER SCIENCE Vol. 20 No. 1 (2012), pp. 35-50 Leveraging TEWI Platform to Enhance Scientific Collaboration on Universities Marcin Kłosiński Łodź University of Technology Institute
More informationDevelopment Best Practices
Development Best Practices 0 Toad Toad for Oracle v.9.6 Configurations for Oracle Standard Basic Toad Features + Team Coding + PL/SQL Profiler + PL/SQL Debugging + Knowledge Xpert PL/SQL and DBA Toad for
More informationSoftware Configuration Management
Reto Bonderer reto.bonderer@fh-htwchur.ch University of Applied Sciences Chur V 1.01 2002, R. Bonderer 1 Learning Goals The participant knows why configuration management is important knows what version,
More informationSoftware Engineering. Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti
Software Engineering Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical
More informationAgile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS
Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS In order to ease the burden of application lifecycle management,
More informationModule 12. Software Project Monitoring and Control. Version 2 CSE IIT, Kharagpur
Module 12 Software Project Monitoring and Control Lesson 31 Risk Management and Software Configuration Management Specific Instructional Objectives At the end of this lesson the student would be able to:
More informationChapter 13: Program Development and Programming Languages
Understanding Computers Today and Tomorrow 12 th Edition Chapter 13: Program Development and Programming Languages Learning Objectives Understand the differences between structured programming, object-oriented
More informationBetter management through process automation.
Process management with IBM Rational ClearQuest software White paper Better management through process automation. David Lawrence, technical marketing specialist May 2006 Page 2 Contents 2 Introduction
More informationDriving Your Business Forward with Application Life-cycle Management (ALM)
Driving Your Business Forward with Application Life-cycle Management (ALM) Published: August 2007 Executive Summary Business and technology executives, including CTOs, CIOs, and IT managers, are being
More informationAn Automated Workflow System Geared Towards Consumer Goods and Services Companies
Proceedings of the 2014 International Conference on Industrial Engineering and Operations Management Bali, Indonesia, January 7 9, 2014 An Automated Workflow System Geared Towards Consumer Goods and Services
More informationOverview of sharing and collaborating on Excel data
Overview of sharing and collaborating on Excel data There are many ways to share, analyze, and communicate business information and data in Microsoft Excel. The way that you choose to share data depends
More informationVersion Control. Luka Milovanov lmilovan@abo.fi
Version Control Luka Milovanov lmilovan@abo.fi Configuration Management Configuration management is the management of system change to software products Version management: consistent scheme of version
More informationAppendix A Statement of Work: Digitization, Archiving and Digital Documents Management System
Page 1 Appendix A Statement of Work: Digitization, Archiving and Digital Documents Management System 1 Page 2 Table of Contents Table of Contents... 2 TERMS AND ABBREVIATIONS... 3 Statement of Work Overview...
More informationTIBCO Spotfire and S+ Product Family
TIBCO Spotfire and S+ Product Family Compliance with 21 CFR Part 11, GxP and Related Software Validation Issues The Code of Federal Regulations Title 21 Part 11 is a significant regulatory requirement
More informationA Guide To Evaluating a Bug Tracking System
A Guide To Evaluating a Bug Tracking System White Paper By Stephen Blair, MetaQuest Software Published: October, 2004 Abstract Evaluating a bug tracking system requires that you understand how specific
More information.CRF. Electronic Data Capture and Workflow System for Clinical Trials
.CRF Electronic Data Capture and Workflow System for Clinical Trials Business challenge Most research takes place in different centers simultaneously. These are often located in different cities or even
More informationSAS System and SAS Program Validation Techniques Sy Truong, Meta-Xceed, Inc., San Jose, CA
SAS System and SAS Program Validation Techniques Sy Truong, Meta-Xceed, Inc., San Jose, CA ABSTRACT This course will teach methodologies of performing SAS system and SAS program validation including new
More informationSoftware Configuration Management. Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman
Chapter 22 Software Configuration Management Slide Set to accompany Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman
More informationXenData Archive Series Software Technical Overview
XenData White Paper XenData Archive Series Software Technical Overview Advanced and Video Editions, Version 4.0 December 2006 XenData Archive Series software manages digital assets on data tape and magnetic
More informationOpen S-BPM: Goals and Architecture
Open S-BPM: Goals and Architecture Albert Fleischmann Werner Schmidt Table of Content 1 Introduction... 2 2 Mission, Vision and Objectives... 2 3 Research and Development Areas... 3 4 Open S-BPM Architecture...
More informationelearning Content Management Middleware
elearning Content Management Middleware Chen Zhao Helsinki 18.2.2004 University of Helsinki Department of Computer Science Authors Chen Zhao Title elearning Content Management Middleware Date 18.2.2004
More informationTo introduce software process models To describe three generic process models and when they may be used
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
More informationData management by Autodesk
Autodesk Vault Workgroup 2015 Data management by Autodesk Autodesk Vault helps design, engineering, and manufacturing workgroups manage Digital Prototyping information. In order to provide Autodesk Productstream
More informationEffective Release Management for HPOM Monitoring
Whitepaper Effective Release Management for HPOM Monitoring Implementing high-quality ITIL-compliant release management processes for HPOM-based monitoring Content Overview... 3 Release Management... 4
More informationRelease Management in Free Software Projects: Practices and Problems
Release Management in Free Software Projects: Practices and Problems Martin Michlmayr, Francis Hunt, and David Probert Centre for Technology Management University of Cambridge Cambridge, CB2 1RX, UK martin@michlmayr.org
More informationBasic Trends of Modern Software Development
DITF LDI Lietišķo datorsistēmu programmatūras profesora grupa e-business Solutions Basic Trends of Modern Software Development 2 3 Software Engineering FAQ What is software engineering? An engineering
More informationAuthoring Within a Content Management System. The Content Management Story
Authoring Within a Content Management System The Content Management Story Learning Goals Understand the roots of content management Define the concept of content Describe what a content management system
More informationContent. Development Tools 2(63)
Development Tools Content Project management and build, Maven Version control, Git Code coverage, JaCoCo Profiling, NetBeans Static Analyzer, NetBeans Continuous integration, Hudson Development Tools 2(63)
More information(Refer Slide Time: 01:52)
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
More informationGetting started with API testing
Technical white paper Getting started with API testing Test all layers of your composite applications, not just the GUI Table of contents Executive summary... 3 Introduction... 3 Who should read this document?...
More informationMOVING THE CLINICAL ANALYTICAL ENVIRONMENT INTO THE CLOUD
MOVING THE CLINICAL ANALYTICAL ENVIRONMENT INTO THE CLOUD STIJN ROGIERS, SENIOR INDUSTRY CONSULTANT, LIFE SCIENCES/HEALTH CARE (EMEA/AP) SANDEEP JUNEJA CONSULTING MANAGER (SSOD) AGENDA Move towards cloud
More information19 Configuration Management
TIMe TIMe Electronic Textbook 19 Configuration Management Introduction.......................................................2 What...................................................................2 Why
More informationChange Management for Rational DOORS User s Guide
Change Management for Rational DOORS User s Guide Before using this information, read the general information under Appendix: Notices on page 58. This edition applies to Change Management for Rational
More informationPeter Mileff PhD SOFTWARE ENGINEERING. The Basics of Software Engineering. University of Miskolc Department of Information Technology
Peter Mileff PhD SOFTWARE ENGINEERING The Basics of Software Engineering University of Miskolc Department of Information Technology Introduction Péter Mileff - Department of Information Engineering Room
More informationAgile SCM Build Management for an Agile Team. Some Definitions. Building and Agility. Steve Berczuk, Brad Appleton, and Steve Konieczka October 2003
Agile SCM Management for an Agile Team Steve Berczuk, Brad Appleton, and Steve Konieczka October 2003 A number of people work together to develop a software application. The application is useful only
More informationThe Real Challenges of Configuration Management
The Real Challenges of Configuration Management McCabe & Associates Table of Contents The Real Challenges of CM 3 Introduction 3 Parallel Development 3 Maintaining Multiple Releases 3 Rapid Development
More informationUser experience storyboards: Building better UIs with RUP, UML, and use cases
Copyright Rational Software 2003 http://www.therationaledge.com/content/nov_03/f_usability_jh.jsp User experience storyboards: Building better UIs with RUP, UML, and use cases by Jim Heumann Requirements
More informationORACLE PROCESS MANUFACTURING QUALITY MANAGEMENT
ORACLE PROCESS MANUFACTURING QUALITY MANAGEMENT KEY FEATURES Automated stability study management Lot expiration handling and retesting Potency or variability management Quality holds during receiving
More informationIntroduction to Software Engineering. 8. Software Quality
Introduction to Software Engineering 8. Software Quality Roadmap > What is quality? > Quality Attributes > Quality Assurance: Planning and Reviewing > Quality System and Standards 2 Sources > Software
More informationEnhance visibility into and control over software projects IBM Rational change and release management software
Enhance visibility into and control over software projects IBM Rational change and release management software Accelerating the software delivery lifecycle Faster delivery of high-quality software Software
More informationXEGENCY ARTWORK PRODUCTION MANAGEMENT SYSTEM FOR AD AGENCIES
XEGENCY ARTWORK PRODUCTION MANAGEMENT SYSTEM FOR AD AGENCIES An innovative workflow management solution for Ad agencies and Design agencies to efficiently manage the artwork production process. Right from
More informationSOFTWARE ENGINEERING INTERVIEW QUESTIONS
SOFTWARE ENGINEERING INTERVIEW QUESTIONS http://www.tutorialspoint.com/software_engineering/software_engineering_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Software Engineering
More informationSuccessfully managing geographically distributed development
IBM Rational SCM solutions for distributed development August 2004 Successfully managing geographically distributed development Karen Wade SCM Product Marketing Manager IBM Software Group Page 2 Contents
More informationAnatomy of an Enterprise Software Delivery Project
Chapter 2 Anatomy of an Enterprise Software Delivery Project Chapter Summary I present an example of a typical enterprise software delivery project. I examine its key characteristics and analyze specific
More informationDocument Management User Guide
IBM TRIRIGA Version 10.3.2 Document Management User Guide Copyright IBM Corp. 2011 i Note Before using this information and the product it supports, read the information in Notices on page 37. This edition
More informationImprove Quality and Decrease Time to Market with Better Requirements Management
Improve Quality and Decrease Time to Market with Better Requirements Management Requirements Engineering: Right Requirements, Right Products Nearly 20% of development cost is due to rework because of ill-defined
More information