Software Proeess Reuse in an Industrial Setting - IEEE Computer ...

Software Proeess Reuse in an Industrial

Setting

Craig Hollenbach William Frakes Virginia Tech, Departmentof Computer Science 2990 Telestar Ct., Falls Church, VA 22042 frakes @sarvis.cs.vt.edu Abstract

process reuse. As examples, IBM has replicated a defect prevention program [7] and peer review program [8] within its divisions. Other companies have developed process enactment tools, such as Process Weaver [9], Synervision [ 101,and PEAKS [ 111. The creation of reusable processes is dependent on domain analysis. Many domain analysis techniques for creating reusable software have been developed. Arango [ 121has surveyedthese techniques and created a composite domain analysis technique. This composite technique is used as a basis for the methods described later in this paper. This paper investigates how to pragmatically and systematically standardize and replicate project-specific processesin an industrial software setting. A systematic and standard method for process reuse is presented. The methodology is applied to a set of PRC business units undergoing software process improvement, and measurements of the level of reuse before and after the application of the processreuse methodology is reported. Using domain analysis and implementation techniques, software reuse principles, process architecture research, and process modeling mechanisms, projectspecific processescan be abstracted into a reusable form that can be retrieved and tailored by processengineers.

This paper describes a method for creating reusable processes and our experience using them in an industrial environment. A notation and process for creating and tailoring reusable processes is described and applied to the building of a 120 process library at PRC Inc. initial data collected on use of the library indicates large potential payo#s from process reuse such as a 10 to I improvement in the time to develop a project specific process.

eywords Software Reuse, Process Reuse, Domain Analysis, ProcessNotation, ProcessTailoring

Many software organizations are actively pursuing software process maturity. Often they use measures like the Capability Maturity Model [l] to structure their process improvement initiatives. One method often cited for accelerating process improvement within an organization is to replicate a standard, reusable organizational process within other projects. However, the creation of a process that is usable on diverse projects is a difficult task. What is needed is an effective method to capture the common and variant elements of projectspecific processesand createprocess definitions that can be applied in a variety of situations, i.e., that are reusable. A literature search shows that groundwork for process reuse exists. Research by Castano [2] concerns the abstraction of common objects from a set of objectoriented process definitions. Research at the DoDsponsored STARS project [3], the Software Engineering Institute [4], and the Software Productivity Consortium 151has developed a set of process notations and methods for defining single processes. These process notations are primarily built upon the ETVX (Entrance criteria, Task, Validation, and exit criteria) format developed at IBM [6]. Some large US companies have demonstratedinstancesof

1085-9098/96$5.00O1996IEEE

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

What

is a reusable

process?

Feiler [13] defines a process as “a set of partially ordered stepsintended to reach a goal.” We define process reuse as the usage of one process description in the creation of another process description. It is not multiple executions of the same process on a given project. What makes a process reusable? To answer that question it is important to examine what makes software reusable. Significantly, that question has not been definitely answeredeven though it has been researchedfor over ten years; there is no foolproof external indicator that can determine the reusability of a software module [14]. The best answer to date is simply that the software module is reusable only if it is reused. The same can be said for software processes;if reused,they are reusable.

22

Table

1 - Examples

The 3Cs model of reuse design provides a framework that has been found effective in the design of reusable assets [15]. The model indicates three aspects of a reusable component - its concept, its content, and its context. The concept specifies the abstract semantics of the component, the content specifies its implementation, and the context specifies the environment necessaryto use the component. Table 1 shows an example of the 3Cs model applied to a software component and to the reusable process notation described in appendix A. For a software component, the concept might correspond to an abstract data type (ADT), whose implementation might be a C module using linked lists. This component’s context might require a Sun workstation running UNIX, and an ANSI C compiler. Analogously, a reusable process will have for its concept an informal specification of: the general information, the customer description, and the interface description. The content will include the procedural description utilizing both a textual and - graphical representation. The reusable process context will be defined in the contextual description.

Halstead method

McCabe method

1

Figure

1.

A Process

Generally speaking, a process is more reusable when it can be used in various situations without changing its concept. The concept in this case is the portion of the process description that defines the customer and associatedrequirements, the interfaces, and other general information. An example of a reusable process is shown in Figure 1. Here the “estimate software complexity” process is shalwn. In the course of the process, a complexity meiasureis needed; there are three methods used to measure complexity: a Halstead measure, a McCabe measure,and a lines of code measure. The use of any of these methods should not affect the concept of the process;indeed, the degree to which it affects the concept is the degreeto which it is less re-usable.

1.

for

Recording

Reusable

For processes to be reusable, organizations need a way to express common and variant elements within a process. Frameworks provide one mechanism to accomplish this. Appendix A shows a framework for process defmititon which is used within PRC. Several portions of the framework reflect the integration of PRC’s software process improvement and quality improvement programs; see [ 161for details on this approachto quality. This framework is organized into several sections. The first three sections,known as the general information, customer description, and interface description sections, specify the process concept, or the what specification of the process. These sections describe what the processis, what is does, and what its interface is to other processes. The next section, the procedural section, specifies the process content, or the how of the process. This section describeshow thleprocess is performed by specifying the people who do the processand their interactions, the tasks and the order of their execution, and the tools and other

\

Example

23

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

Method

1.1 Notation Processes

Lines of code method

Reusability

of the 13Cs model

necessary resources. The procedural description is both textual and graphical. The graphical notation uses flowcharting symbols. The flowchart describes the process, its customers, and the indicators used to measurecompliance in meeting customer requirements. The graph is divided vertically into columns; each column represents a participant in the process. Process steps for each participant are placed in the associated column. The graph can also be divided into horizontal bands which represent sequential steps of the process. Each process starts with an oval symbol describing the customer’sneed. The steps in meeting those needsare describedusing rectanglesfor processesand diamonds for decisions. Boxes with double side bars represent a collection of sub processes that is defined graphically in a separate diagram. The arrows represent control Figure 2. flows. No attempt is made to capture data flows. Indicators, described below, are denotedusing circular symbols. The context description describesthe context in which the process can execute. The process context, which is strongly bound to the process content, defines domain, organizational, project, and managerial criteria for application of the process. The final section, the measurementdescription, spans both the what and how specification roles. The quality indicators measure how well the process meets its goal and are therefore part of the what specification. The process indicators measure how well individual steps perform. Because the process indicators measure steps, they are part of the how specification. 1.2 Context for Reusable Processes

Defining

and

Context

for Defining Processes

and Tailoring

Reusable

refine its usage, and feed back information to improve the processdescription for subsequentuse. This processlife cycle contains the following steps: The output is one Define the Reusable Process. or more process descriptions, along with tailoring guidance and output work products; these are usually packagedinto a processmanual or handbook. The process descriptions also are integrated into the life cycle and statically tested to ensurethey are fit for (re)use. Develop

Training

for

the

Reusable

Process.

Once the reusable process is completed, training for that processis developed. That training is tailored as described below.

Tailoring

The purpose of the process definition methodology is to create reusable processes so that projects within an organization can cost-effectively tailor them to their own requirements. Reusable processes aid in transferring process knowledge between projects, reducing training costs, planning common project activities based on process data, and increasing productivity and quality in a continuously improving process-orientedenvironment. The context of the process definition and tailoring methods are depicted in Figure 2, which shows the life cycle of a process description. The figure describes graphically the stepsnecessaryto createa standardreusable process description, instantiate it for use on a project,

Tailor the Reusable Process on a Project. The reusable process is tailored to meet the specific requirements and environment of a project. Projectspecific process descriptions are the result, sometimes packagedinto a handbook or set of desk instructions. Tailor the Reusable Process Training to the Tailored Project Process. The training for the

reusable process is tailored to match the project-specific process. The training is given to the appropriate staff just before they needto enact (or execute)tbe process.

24

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

Project Process Team

Organization Process Team

the Process on the Project. The projectspecific process is enacted, i.e., put into practice on the project. C M M level 3 project managementpractices track the enactment of the process and use it to monitor and control the project. The quality assurancefunction audits the project staff to ensure that the process is faithfully enacted. Measurements are taken and used in the following step. Enact

industry processdata. Domain boundariesand content are specifically described and current processesand process data are collected The data is evaluated to locate entities, events, operations, or relationships which are then modularized. Finally, these items are analyzed to determinesimilarities, variations, combinations,and tradeoffs that help structure the processfor reuse. 3. Process IPreliminary Design. In this step, precise and accuratedescriptionsof the processconcept,or what specifications, are created. For each reusable process, the customersand their requirements are defined as are the proc,essinputs and outputs, entrance and exit criteria, and quality indicators. Major sub process blocks are defined for upper level processhierarchies. When designing the processinterfaces, it is important to integrate the process into other existing processes. This implies that a process architecture has been constructed consisting of processes from all software engineering disciplines. The architecture is the starting point for integration of the reusable process. It also provides a framework for referenceduring reusableprocess definition. To determine a process’squality indicators, the goalquestion-metric paradigm [ 171is applied to the definition of the processcustomersand their requirements,as defined in the preceding step.

Based on measurementscollected in the previous step, the processis evaluated to seeif it is stable and capable. If not, an analysis is performed to determine why the process failed. The process definition is then refined, new training is developed, and the process is re-enacted. Refine the Process.

1.3 Method Processes

for

Defining

Reusable

This section describes how to create a reusable processdescription. The objective of this methodology is to develop and maintain a reusable set of software process descriptions that improve processperformance across the projects and provide a basis for cumulative, long-term benefits to the organization. The method assumesthere is a system to maintain and support reusable process definition efforts, and supporting policies and adequate funding and resources. The customers of a reusable process description are: 1) the managers and SEPGs (Software Engineering Process Groups) [l] of projects that want to reuse a process, either during proposal development, at project startup, or for a process improvement initiative; 2) the developers of the associated training for the reusable processes;and 3) corporate SEPGstasked with managing process implementations and changes. These customers require that the reusable processesbe enactable, comply with standards,and improve productivity and quality. The methodological stepsto create a reusableprocess are described below. The method derives from a generalization of standard software development and domain analysis techniques,particularly Arango’s domain analysis of domain analysismethods [ 121.

Design. The process detailed design step defines the processcontent, or the procedural, how-related process characteristics. They include methods/procedures, roles, processindicators, and feedback and control meclhanisms. It is important to use roles rather than agents in the reusable process. Roles refer to required task-oriented functions. Agents are the people or groups that perform the roles. Agents differ greatly betweenprojects, basedon project size, contractual commitments, subcontract arrangements,past project organizations,and other project environment concerns. Because of this variability, the reusableprocessdescriptionsdescribe functions and allow the projects to lmap the functions to the organizational agentsas appropriate. 4. Process Detailed

1. Process Requirements Analysis. This step defines the operating conditions under which the process will be enacted and the goals and requirements that the process will satisfy. A process definition and evaluation action plan is developed that contains this information plus basic project planning data.

Test. The process code and unit test step is used to automate a reusableprocessor a portion of the process. Trade studies are performed that weigh the benefits of commercially available tools versus the construction of an internally developed tool set. If commercial tools are selected, there is the inevitable task of tailoring the tool to meet the characteristics of the organization or project. In this case, the process definition and its contextual process architecture provide the necessaryinformation to effectively tailor the tool; in 5. Process Codle and Unit

The process analysis step Analysis. supports generic reusable process definitions by examining current project-specific processesand relevant 2. Process

25

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

other words, process definition is a necessary precursor to process automation. If local automation is done, the process description then becomes the functional specification for the automatedprocess. In this case, the process code and unit test step transforms the enactableprocess description into an executableprocessprogram. 6. Process Integration and Testing. The process integration and testing step ensures that the defined reusableprocesscan meet product and process goals. This is usually accomplished through static analysis of the process and then the process architecture which contains the integrated process. The method to create a reusable process can itself be measured using quality and process indicators. Some potential quality indicators are: . Number of projects consulted per organization process. . Percent of project-specific process reuse per organization process. . Standard set of project tracking metrics, including total effort, milestones missed/made,and cost. Method 1.4 Processes

for

Tailoring

Reusable

Process

Flowchart

Local SEPG

Process Tailoring Team

Tailc

--. 4uto mate --. Tesi --. levie

Process tailoring consists of importing a reusable process into a new environment and changing it, if need be, for a new project’s requirements. The major steps, illustrated in Figure 3, are usually performed by a team of Figure 3. Process Tailoring Methodology project or business unit staff or by a expert in the process area. The output of the tailoring method satisfied. The metrics are tuned to the peculiarities of the is a set of process descriptions that textually and project contract, available collection methods, perceived graphically describe the project-specific process. The risks, and maturity level, among other things. tailoring is performed at the direction of the local SEPG; Next, the process methods and associated indicators the tailoring plan is usually documented in the SEPG’s are tailored to accommodate the specific functional software processimprovement plan. assignments on the team, expertise in currently used After initial planning of the tailoring effort, the methods, differences in task sequencing, and existing tailoring team selects a reusable process. The team then project processes. The team then identifies opportunities adds detail to the customer definition section of the to (semi-)automate the process, integrate it into the reusableprocess so that it describesthe project’s customer. process architecture, and test it. The testing is usually Through discussions with the customer, requirements are accomplishedthrough peer reviews, augmentedby standard elicited, adding project-specific details to those abstracted testing techniques for the automated portions of the in the reusableprocessdescription. ‘process. Using knowledge of the specific project input and Finally, the tailored -process is given to the local output work products and the existing processarchitecture, SEPG for final approval, along with all applicable the team adds project-specific detail to the set of interface waivers and deviation requests,and when approved, added specifications in the reusable process descriptions. The to the organizational repository. team also tailors the reusable process metrics to measure how well the specific customer’s requirements axe

26

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

2.

Case Study

compliant with version 1.1 of the Capability Maturity Model. They used the method defined above to collect project-specific processes and data and to create reusable processes. Release 2.0 of corporate process descriptions, numbering about 120 processes,was created primarily as a result of their efforts. These processes were stored in a web-browsable Process Asset Library (PAL) which is accessible by PRC employees. Specific KPA web pages were built to house the reusable processes,project-specific instantiations, related process assets,and training material. The training a:ssociatedwith these processes was given first in pilot an.dthen in corporate training situations. In each of these, the students were taught how to tailor the corporate/reusableprocessesto meet their project-specific needs. Finally, instances of process definition and/or reuse over the 1991 to 1995 time period were collected. The results have several key points. First, contrary to past trends where reuse was tied to previous involvement in corporate process development, reuse increased for business units that had no clear link to the development of the reused organizational processes. Significantly, the time to develop a project specific process was dramatically lowered through reuse, showing at least a 10 to 1 decrease in time needed to create a process. This is significant in that two strong process improvement re,quirementsvoiced by PRC projects are 1) time to improve, and 2) effort to improve, since most improvement efforts are performed on tight, limited budgets.

Although PRC has been involved in software process improvement since 1989, this case study begins in 1991. PRC then began to work with individual projects to increase their software maturity. Efforts were centralized into one group of full-time staff in the company’s technology center. Based in part upon the experience of a pilot project, this group developed a set of approximately 300 corporate process descriptions in the level 2 key process areas, and also the peer review key process area. This set of process descriptions, referred to as Release 1.0 below, was collected into a set of process manuals. Although the pilot project used these process descriptions, there was little interest among other projects in software process improvement and process adoption. In 1993, a corporate initiative merging the company’s software process improvement and quality improvement programs secured the involvement of eleven key software projects, assisted by the full-time group from the technology center. These projects and the technology center staff formed the “phoenix” team. In this collaboration, process definition and improvement operated was more decentralized. Projects defined their own processes, sometimes using existing process definitions. To maximize process maturity, the concept of “best of breed” (BOB) processes was tried; attempts to replicate processesfrom the most mature projects to more immature projects were employed. This failed almost totally. The team determined that a more methodical approach to process reuse was needed, one that abstracted away project-specific details so that other projects could reuse the processes. Consequently, in mid-1994, research was begun on how to maximize process reuse. Project representatives were surveyed to characterize process reuse as of June 1994. A working group, initially formed to create corporate training for level 2 key process areas, was also tasked to modify or redefine processes so that they were

I

Business

Unit

Reuse Levels Compared. Has use of the method increased process reuse? To answer this question, we compared process reuse percentages in 1994 before the method was used and in 1995 after the method was introduced. As Table 2 shows, process reuse increased from 41% in 19’94 to 55% in 1995. We believe that the domain analysis and process tailoring methods and training contributed to this increase. All business units

I

Table

2. Process

Reuse

27

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

in

1994-19!95

by Business

Unit

3.

participated in the training, and business units #4 and #7 have set a standard to begin all process definition efforts by identifying reusableprocesses.More time is neededto measure the effects of the domain analysis and process tailoring methods. The decreasein total processesfrom 1994 to 1995 is due to incomplete data from 1995 (through July only), and normal fluctuations in the processcreation and use cycle.

4.

5.

Ill

Consultation.

[2]

[3]

[41

r51

28

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

Work

Acknowledgments

The authors would like to thank Voytek Kozaczynski, RebeccaJoos, Shirley Browne, Martin Griss, and Maggie Davis for their comments during WISR-7, and PRC Inc. for their involvement in and support of the case study and Paper.

Our experience with process tailoring covers several business units and KPAs. Release 2.0 processeshave been instantiated and modified in the following KPAs: peer reviews, requirements management, software project tracking and oversight, software quality assurance, and intergroup coordination. In each of these cases,an “instantiated” or “instantiated and modified” process was created in two to three hours. Participants in this process are usually excited about its power, surprised at the results, and eager to apply the samemethod to other processes. Reuse of processes within PRC is not limited to corporate processes. One business unit has taken advantageof processesfrom another businessunit and also from a tool vendor. In the first case, no particular tailoring was required; the processeswhich involved cost planning and tracking were reused without modification. In the case of the process from the tool vendor, the businessunit used the processand tool documentation as a reference for process definition, but were not able to instantiate or instantiate and modify the tool’s process information. Tailoring

and Future

The application of reuse technology to software processes is a valuable addition to process engineering methods. Process reuse enables organizations to apply carefully crafted processesto a wide variety of projects and to apply them in a shorter time frame, thus saving time and effort. In this paper we presenteda method for process reuse and rep&ted on its use in an industrial setting. In our case study at PRC we found at least a 10X improvement in time and effort to create a project or business unit process description when we instantiated a reusable process rather than building the process from scratch. Future work should continue this case study to fully measure the effects of process reuse over a statistically significant set of process definition and tailoring instances. Additionally, more researchis needed in analyzing the effects of process reuse on quality, cost reduction, and time to market.

Benefits of Process Tailoring Method. One positive thing that came from implementing the process tailoring methodology was a greater awarenessof the time and effort saved by tailoring a processrather than defining it from scratch. Metrics from both corporate and project process definition efforts place the effort spent to design processes for a KPA at around 800 to 1000 or more person-hours, depending on the breadth and depth of the KPA. One project process team serves as an example: this team built four processesin 800 hours, their efforts spanning over one full year. It could be extrapolated that one process took 200 hours. Results from processtailoring show that a project can instantiate a process in two hours, one to tailor the process textual description, and one to tailor the graphical description of processroles and tasks. When a peer review of the process is added, the total time to instantiate and produce a project-specific process is around 20 hours. Thus, conservatively speaking, our PRC experience shows a 10 to 1 improvement in time to define a projectspecific process. Process

Conclusions

References Paulk, M., Curtis, B., Chrissis, M., and Weber, C. Caoability Maturitv Model for Software. Version 1.1, CMU/SEI-93-TR-24, February 1993 Castano, S., De Antonellis, V. “Reusing Process System Specifications”, from Information ; WG8.1 Working Conference on Information System Development Process,Como, Italy, 1993 Ett, W., Kellner, M., Over, J., Phillips, D. Defining Manually Enactable ProcessesUsine the Process Definition Information Organizer Temolates, Electronic Systems Center, Contract No. F19628-C-029, Task IV02.1, CDRL Sequence A014-010, Defense Technical Information Center, Cameron Station, Alexandria, VA 22304-6145, March 6,1995 Over, J., Kellner, M. Fundamentals of Software Process Definition, Tutorial given at the 1994 SEPG National Meeting in Dallas, TX, Software Engineering Institute, Pittsburgh, PA, 1994 Bechtold, R., Brackett, J. Process Definition and Modeling Guidebook, Volume 1: Conceots and Principles of MPDM, ‘SPC-92041-CMC, Version

Appendix

02.00.02, Software Productivity Consortium, Herndon, VA 22070, March 1994 El Radice, R., Roth, N., O’Hara, Jr., A., Ciarfella, W. “A Programming Process Architecture,” IBM Svstems Journal, Vol. 24, No. 2, 1985 Gale, J., Tirso, J., and Burchfield, C. r71 “Implementing the Defect Prevention Process in the MVS Interactive Programming Organization,” IBM Svstems Journal, Vol. 29, No. 1, 1990, pages 33-43 Bl Fagan, M. “Advances in Software Inspections,” IEEE Transactions on Software Engineering, Volume SE-12, Number 7, July 1987, pages 744751 PI ProcessWeaver User’s Manual and Reference Manual. Version PW 1.2, Grenoble, France, CapGeminin Sogeti, 1992 to SvnerVision: Models of [W Introduction m Hewlett-Packard document B3261-90002, Draft May 5,1993 r111 Ett, W., Terrel, J., Lineham, A. Software Process Management System User’s Guide for the IBM RISC Svstem/6000 (SPNS/R*) Version 1.O RenamedProcessEngineerinu and Analysis Kernel Svstem (PEAKS), Electronic Systems Center, Contract No. F19628-93-C-0129, Task IU03, IBM Federal Systems Company, 800 North Frederick Avenue, Gaithersburg, MD 20879, July 31, 1993 WI Arango, G. “Domain Analysis Methods,” from Software Reusabilitv, edited by Schafer, W., Prieto-Diaz, R., and Matsumoto, M., Ellis Horwood, 1994 u31 Feiler, P., and Humphrey, W. Software Process Develonment and Enactment: Concepts and Definitions, Software Engineering Institute CMU/SEI-92-TR-04, Pittsburgh, PA, September 1992 u41 Frakes, W., Terry, C. Software Reuse Models and Metrics: A Survev (to anuear), ACM Computing Surveys, 1996 1151 Latour, L., Wheeler, T., Frakes, W. Descriptive and Prescrivtive Asvects of the 3 C’s Model: SETAl Working Grouv Summarv. Ada Letters, 1991. X1(3): p. 9-17. [161 Arthur, L., Imvroving Software Oualitv: An Insiders Guide to TOM, New York: John Wiley, 1993 u71 Basili, V., Weiss, D. “A Methodology for Collecting Valid Software Engineering Data”, IEEE Trans. Software Engineering, Vol. SE-lo, no. 3, November 1984, pp. 728-738

Name the process/sub process that is described within the document.

Name.

General Information Process ID.

Unique process identifier

Process Purpose. Provide a brief description of the purpose and objective of the activity.

Idientify the applicable process and product standards,including the SE1CMM KPA reference.

Standards.

Related Processes. Identify processes that are related to this process, especially if this process is part of a set that is normally viewed as a whole. Version

Number.

Configuration management version

number used in PAL

Customer

Description

Idientify the internal and external groups Customer. who benefit directly (receive products/services) from the results (outputs) of this process. Customer Requirements. List each of the legitimate requirementsthat have been negotiated and agreedto with the identified. These requirements should follow the RUMBA criteria in that they should be Reasonable, Understandable,Measurable,Believable, and Acceptable.

Interface

Description

Critleria. Identify the criteria that must be satisfied before the activity can be initiated. The criteria might say how to tell when a process can be started, for example at the conclusion of another activity or process. Entrance

Inputs. Identify the work products that are used at any point in the proc,ess.

Identify the work products that are produced during the process. Identify the criteria that must be Criteria.. satisfied before the activity can be considered complete. Exit criteria summarize the salient measurabletasks of the process. Exit

29

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

A - Sample Process Notation

procedural esponsibilities.

Description

Project Duration. Describe the applicability of this process in regards to project length, e.g., any project that requires over 1 person-month.

Describe the groups that participate

in the process. Problem Complexity. Describe complexity constraints. Generally phrased in terms of software size.

Tasks. Describe the tasks that must be accomplished within the process. For ease of reference, the tasks should follow the QIDW process diagram referenced as the main exhibit. If the process is procedural, describe the tasks in the order that they must be accomplished, numbering each task step. Parenthesis the responsible group to the left of the task, as shown below: ()

Physical Team Locality. Define whether the team must be collocated or can be physically distributed. Communication Infrastructure. Describe what information resources and inter group communication paths or mechanisms must exist.

Management

Use action verbs to describe the tasks. Reference by process ID all tasks that are further described elsewhere. Note any particular procedures, practices, or methods that are employed in any step.

Describe the costs and benefits of this Cost/Benefit. process in both the short and long term. Risks. List management and technical risks associated with the execution of this process.

Describe suggested or mandatory tools used during any step of the process. Tools.

Measurement

Describe resources that are necessary to enact the process.

Description

esources.

Quality indicators. List and briefly describe those measurementsthat will be used to track the performance (or outcome) of this process in terms of the product or service delivered to the internal or external customer. These indicators should be linked closely to the valid customer requirements and should be used to monitor performance of the entire process. These measuresshould be measurable,verifiable, and cost effective.

ontext Description Domain Domain. List the application domains to which this process is applicable.

Applicable

Process Indicators. List and briefly describe those measurementsthat are to be taken at critical points during the process and used to track and assessthe effectiveness of the process itself. These in-process measures should also be measurable,verifiable, and cost effective.

equired Domain Knowledge. Describe the knowledge of the application domain that participants in this process must exhibit.

Usage Information. Describe how past projects have used this process, including the results of the process (i.e., associatedmetrics) and the lessons learned. PKB‘XSS

Process Flowct-----as

team?

PKXl?SS Customer:

81.1

Organization Size. Briefly describe the organization size that limits this procedural method. Organization

Structure. Define specific groups or functions that must be in place to execute this procedural method.

Organization

Project

Proceedings of the 4th International Conference on Software Reuse (ICSR '96) 1085-9098/96 $10.00 © 1996 IEEE

z-v-.

1 -I

Customer

Participant

Participant

I