A PRACTICAL APPROACH TO PROCESS DEFINITION

Presenter(s): Carol Diane Klingler

Title: A Practical Approach to Process Definition

Track: Process Improvement Track-SP1

Day: Tuesday

Keywords: process definition, process modeling, IDEF₀

A P

RACTICAL

A

PPROACH TO

P

ROCESS

D

EFINITION

1. I

NTRODUCTION

Well-defined processes are critical for producing high-quality software on schedule and within budget. Well-defined processes also facilitate communication within software develop-ment teams, training of new personnel, managedevelop-ment, and process improvedevelop-ment. Process defini-tion is a Key Process Area at level three of the Software Engineering Institute’s Capability Maturity Model [Hum89] and is a critical activity at all levels of capability maturity. There is little practical guidance available on ways to create well-defined processes. Traditional text-based pro-cedure manuals are rarely sufficient, because they are difficult to maintain and analyze, and tend to not be read by the software engineers for whom they are written. The Unisys STARS team has defined many processes and has evolved a general approach to process definition, called the

Pro-cess Description Approach in this paper.

The Process Description Approach includes techniques for information gathering, auto-mated process modeling, process analysis, and process presentation. A variety of information gathering techniques are used including: brainstorming, creating IDEF₀ diagrams, and interview-ing process performers to determine how they perform their jobs.

Process modeling techniques include IDEF₀ and Process Breakdown Structures. The Pro-cess Breakdown Structure formalism allows the representation of a proPro-cess in terms of textual descriptions of its critical attributes including activities, work products, roles, work product avail-ability constraints, and control constraints. Process Breakdown Structures and the Process Map-per tool used to capture them were developed by Innovative Software Engineering Practices Inc. (INSTEP) and Software Design & Analysis Inc. (SDA) [INS94a, INS94b, NR94]. The Process Mapper tool also provides capabilities to analyze the process model for completeness and consis-tency.

Processes are presented in both printed and electronic form using graphical and textual representations. Printed presentation forms include IDEF₀ Diagrams, Process Trees, Process Tables, and Process Packets. Electronic presentation is accomplished using Mosaic with hyper-text-links between process model data. Mosaic also enables easy transmission of the process across geographically-distributed sites. The Process Description Approach results in a well-defined process that can be easily understood, taught, and communicated.

to define a domain modeling process and the Process Description Approach itself. This approach is being evolved further based on lessons learned during its application. Unisys STARS is also investigating how to make the scope more general and include lessons learned from other process definition efforts.

Section 1 of this paper contains the introduction. In Section 2, key terminology that will be used in the rest of the paper is defined. Section 3 shows how process definition fits into a project’s process management life cycle. Sections 4, 5, and 6 describe the Process Description Approach. Recommendations based on lessons learned from using the Process Description Approach are dis-cussed in each of these sections. Section 7 discusses current and proposed uses of the Process Description Approach. Section 8 contains the conclusions.

2. T

ERMINOLOGY

A process is a set of partially ordered steps intended to reach a goal [Fei93].

An activity is a component of a process. Activities can range from individual process steps to large parts of processes.

Process description encompasses the design, analysis, and implementation of a new

pro-cess (often called propro-cess definition) or an existing propro-cess. A propro-cess description is the resultant product of the design or implementation. Processes are described to provide understanding to enable consistent process performance, to support automated performance, etc. The approach described in this paper is called a Process Description Approach because it can be used to design and implement existing or new processes.

A process performer is a tool or human that follows a process in the performance of a task. For example, a large portion of a software development process is performed by the program-mers. Other performers may include software testers, configuration managers, and project manag-ers. Tools that perform software development activities include software modeling tools, compilers, linkers, and debuggers.

A process engineer describes processes, selects process performers, monitors process per-formance, evaluates performance metrics, initiates process improvement activities, etc.

3. T

HE

P

ROCESS

M

ANAGEMENT

L

IFE

C

YCLE

The Process Concept Model shown in Figure 1 shows how process description fits into the process management life cycle. The process management life cycle begins with the description of a process based on project goals, possibly using previously described process assets. Process assets are process descriptions that have been stored in a library for reuse. The process is sched-uled by assigning resources. The process can be installed on a machine or procedures given to humans to follow. The process is monitored and measured during its use. Measurement data is evaluated and used to further evolve the process. Description of an existing process can begin

with monitoring and documenting the current informal process. Process description can then be based on the evaluation of the documented process.

The Process Management Life Cycle shown in Figure 2 shows the components of process description and the main work products produced. Process description is broken into Process Analysis, Process Design, and Process Implementation. Process Analysis involves identifying, analyzing, and capturing process requirements. Process Design involves modeling the architec-ture and functional decomposition of the process. Process Implementation involves implementing the process design to create scripts that are installed and providing training to humans who will execute the tasks. Process Implementation also involves preparing the process for performance by instantiating the process based on project-specific details and scheduling resources. Process Per-formance involves running process scripts and following manual procedures to perform the activ-ities described in the process. Metrics are gathered as the process is performed. These metrics are evaluated in Performance Evaluation, which leads to evolution of the process into a better quality process in Process Evolution. Although Figure 2 suggests that Process Analysis, Process Design, and Process Implementation occur in sequence, in practice the process engineer iterates and cycles back to previous activities as necessary.

Similar activities occur in Process Analysis, Process Design, and Process Implementation as in the traditional software development life cycle activities of Analysis, Design, and Imple-mentation. These similarities, first described in [Ost87], allow process engineers to make use of the results of research of the software development community. For example, good software mod-eling principles also apply when creating process models.

This paper focuses on the activities in the Process Description Approach, including Pro-cess Analysis, ProPro-cess Design, and ProPro-cess Implementation, as shown in the first three boxes in Figure 2. Process Implementation is currently only addressed as it relates to manually performed

Schedule and Install Evaluate Describe/Evolve Process Execution Planning Use Monitor and Measure Project

Context ProcessAssets

Figure 2. Process Management Life Cycle.

Process

Process

Process

Process

Performance

Performance

Evaluation

Process Description

Analysis

Design

Implementation

Process Evolution

life cycle but are not addressed in the Process Description Approach since they are not part of Process Description.

The approach and examples in this paper focus on the description of one process in a soft-ware development project, although the approach can also be tailored to apply to the description of multiple processes and organization processes. The approach should be tailored based on the goals of the process description effort. For example, the Process Description Approach includes modeling with IDEF₀ and Process Breakdown Structures; other modeling notations could be sub-stituted. The approach does assume a hierarchical activity decomposition in the modeling nota-tion.

The Process Description Approach described below is accompanied by IDEF₀ diagrams to show how the activities interact. IDEF₀ is based on the Structured Analysis and Design Technique (SADT) — a graphical approach to system description [MM88, Sof81]. An IDEF₀ Activity Dia-gram contains one level of decomposition of a process. Boxes within the diaDia-gram depict the sub-activities of the parent activity named by the diagram. Arrows between the boxes depict availability of work products to activities. Arrows entering the left side of a box are inputs to an activity. Arrows exiting the right side of a box are outputs from an activity. Arrows entering the top of a box are controls that regulate the activity. Arrows entering the bottom of a box are mech-anisms that support the activity. A sequential ordering of boxes in the diagram does not imply a sequential flow of control between the activities. Figure 3 shows the IDEF₀ Diagram for Process Analysis.

4. P

ROCESS

A

NALYSIS

4.1 A

P

A

As shown in Figure 3, Process Analysis involves gathering requirements levied on the process, modeling these requirements, setting process description objectives, and evaluating the requirements. Process requirements are gathered by investigating requirement sources. Model-ing these requirements and their interconnections allows the process engineer to gain a better understanding of them. Objectives are set based on process requirements and project constraints. Evaluation of process requirements is very important since all process description activities are based on them.

Process requirements can be gathered from many sources, including the project contract, the organization’s policies and procedures, and interviews with project customers and manage-ment. An example of gathering a requirement from the organization’s policies is determining that a requirement exists for peer reviews to be included in the process when the organization has a policy that peer reviews should occur in all phases of software development. Interviews with the project customer and management are used to obtain requirements not stated in the contract. Interviews are also used to clarify vague requirements. All process requirements generated are listed with their sources, to allow traceability back to the sources if necessary.

Process requirements are modeled, using standard software engineering techniques, to assist in their understanding. Modeling is particularly important for complex requirements.

Process description objectives are based on the requirements, resources, and other project constraints. Objectives address how process description will be carried out, including tools used in process design and implementation. Guidelines are developed as to the level of detail sufficient in process design and implementation. These guidelines constrain process description decomposi-tion. Setting objectives also includes defining the viewpoint to be used for process descripdecomposi-tion. For example, a software development process can be described from the viewpoint of the project manager or the programmers. If more than one viewpoint is needed, multiple process descriptions must be created.

The process requirements model and process description objectives are evaluated through review by project management, the organization’s SEPG, and the customer. Project management and the customer verify that the requirements of the process and the process description objec-tives meet their expectations. The organization’s SEPG verifies that the process requirements and process description objectives conform to the organization’s policies and procedures.

Figure 3. Process Analysis IDEF₀ Diagram.

I3 Existing Process Requirements I2 Organizational Constraints I1 Domain Knowledge Model Process Requirements A12 Evaluate Process Requirements A14 O1 Process Requirements C1 External Process Requirements Evaluated Process Requirements Requirements Modeling Tool Set Process Description Objectives A13 M1 Process Description Mechanisms Gather Process Requirements A11 Project Constraints Collected Process Requirements Process Description Objectives Process Requirements Model Policies & Procedures Rejected Process Requirements

4.2 R

P

A

• Process description should be based on process requirements.

Process requirements gathering and analysis are very important because the pro-cess description is based on these requirements. Requirements for propro-cess descrip-tion are often overlooked because there is no single concise source of these requirements.

• Set process description objectives with realistic expectations of the time required.

Detailed process analysis, process design, and process implementation are extremely time-consuming. The time required varies with the complexity of the process and the level of detail in the process description — similar to that required for software development.

• Prioritize process description based on risk.

Risk management should be used to prioritize process description. Areas of great-est risk should be identified and process activities to be described prioritized based on addressing those areas first. Process-related software engineering issues are raised and addressed during process description, reducing some of the risks.

• Skills of process performers are one factor in determining the level of detail necessary in the process description.

A process must be described in greater detail when performers have less skill in the process. For example, skilled software designers will need less instruction than those less familiar with software design techniques.

5. P

ROCESS

D

ESIGN

5.1 A

P

D

As shown in Figure 4, Process Design involves modeling the process, selecting process performers, and evaluating the process model. The process is modeled using IDEF₀ and Process Breakdown Structures. Process performers are selected based on those available and recom-mended. The model is evaluated by process engineers, process performers, and other stakehold-ers. Each of the activities in Process Design is described in a separate section below. Process modeling, process performer selection, and evaluation of the process model are carried out incre-mentally on portions of the process, as prioritized when setting process description objectives.

5.1.1 Process design modeling

Process design modeling involves determining process details, determining metrics to col-lect, and creating the design model. Detailed process design decisions are not addressed in pro-cess requirements and are often left to the propro-cess engineers and propro-cess performers to determine. For example, there may be requirements for peer reviews in the process but no requirement for when in the process these peer reviews are to occur. Determining process details is an investiga-tion and analysis activity that can include group brainstorming sessions, interviews of humans with experience in the process, research into possible performance methods, and analysis of how the process has been performed in the past. Group brainstorming sessions can be used to deter-mine subactivities of a particular activity, develop a hand-drawn IDEF₀ diagram, and interview process performers to determine how they perform their jobs. Human process performers should be included in determining process details for the activities that they will perform.

One important area in process detail determination is selection of process metrics to be collected and analyzed. Metrics are selected based on the project’s process requirements. Process requirements are analyzed to determine useful and practical metrics that can serve as indicators for measuring the process based on the Goal/Question/Metric (GQM) paradigm [Bas84, Bas88]. The GQM paradigm enforces the principle that measurement is performed for a purpose. GQM is based on a top-down approach in which project goals representative of the purpose for the

mea-Figure 4. Process Design IDEF₀ Diagram

I2 Existing Process Design Models I3 Available Process Performers O1 Process Design Model O2 Selected Process Performers Process Design Model and failed requirements Model Process A21 Process Design Model M1 Process Description Mechanisms Select Process Performers A22 C1 Process Requirements I1 Domain Knowledge Evaluate Process Model A23 Selected Process Performers Evaluated Process Design Model C2 Recommended Process Performers

surement are first developed. A set of questions are developed based on the goals, the answers to which provide some level of assessment towards achieving the goals. Answers to the questions are specified as a set of metrics. Although the GQM paradigm is simple, the process of developing goals, questions, and metrics is complex and requires training and experience. Figure 5 shows an example of how a process requirement can be analyzed using GQM and appropriate metrics selected. The figure is only intended to show a sample of the metrics that could be selected, not a complete set.

A process design is modeled by hierarchically defining activities that are part of the pro-cess, and defining the work products and roles required to perform the activities. The Process Mapper tool [INS94b] is used to develop the process model using Process Breakdown Structures. The basic elements of Process Breakdown Structures in Process Mapper are shown in Figure 6. The process is decomposed hierarchically into activities, called Process Steps in Process Mapper. Process objectives help in determining when to stop decomposing these activities. Each activity in the Process Step Decomposition contains many attributes defined in the activity’s Step

Defini-tion including Name, Purpose, Step States, etc. Model Data, including Role DefiniDefini-tions, Work Product Definitions, and Condition Definitions, can be referenced by the process attributes. For

each Work Product Definition work product attributes are defined including the Name of the work product, Synopsis, Related Work products, etc. The figure also shows the attributes that are defined for Role Definitions and Condition Definitions.

Figure 5. Example of the Application of GQM to a Process Requirement 1. Requirement

The software process should allow the development of a reliable product.

2. Goal

Evaluate the current project’s process to assess the progress in achieving a defined level of code reliability.

3. Questions and Metrics

Question A: Can the propagation of errors from the software specification and design phases be min-imized by applying inspection methods X and Y to the specification and design?

Metric A1: Keep counts of the life cycle location where defects are identified and analyze the defects to determine their origin (e.g., defect was identified during a code inspections and origin was design). This will provide a count across the life cycle of defect origins and how far they propagate before being detected.

Metric A2: Use counts in A1 as a high-level assessment of the inspection methodologies being used in the specification and design phase.

Metric A3: Determine the cost of correcting defects at each stage. Based on recommendations to invest in additional inspection technologies, assess potential cost savings and reliability improvements in a compar-ison trade-off.

Question B: Can the monitoring of changes across life cycle products (e.g., specification, design, code, etc.) be used to predict failures in the operational system?

Metric B1: Collect changes to products under configuration management control. Develop a change cate-gory scheme based on an ordinal scale that is uniform across all life cycle phases (e.g., large, medium, small). Generate category counts for each life cycle phase.

Metric B2: Correlate changes across life cycle phase, by selecting appropriate statistical method, and ana-lyze results for trends. For example, is there a strong correlation between a significant number of a certain class of changes (e.g., large) in an early life cycle phase and failure at a later life cycle phase?

Figure 7 contains a screen dump of Process Mapper windows that contain an Application Engineering Process Breakdown Structure. The Application Engineering activity decomposition is shown in the window on the left. The bottom of this window shows buttons that can be clicked to enter attributes of each activity including Purpose, Activities, Entrance Criteria, etc. The two windows on the upper right show the Purpose and Entrance Criteria attributes for the

Develop_system_model activity. The lower right window shows the Work Product Definition Edi-tor which contains attributes for Application Engineering work products. The System_model work

product is selected and a description of the work product is shown in the Synopsis attribute. The Designer delivers the Design to the QA

team for review.

NAME PURPOSE STEP STATES

SUB-STEP GROUPING AND SEQUENCING

ROLES REQUIRED

COMMUNICATIONS OBLIGATIONS ENTRANCE CRITERIA WORK PRODUCTS USED ACTIVITIES

WORK PRODUCTS PRODUCED EXIT CRITERIA

OTHER CONSTRAINTS MODEL (PROCESS STEP

DECOMPOSITION)

PROPERTY DEFINITION

MODEL DATA

ASSERTIONS STEP DEFINITION Information about the ways in which exit conditions satisfy entrance conditions as well as the ways in which exit conditions may be satisfied.

reference

DESIGN TEST PLAN

NAME SYNOPSIS

RELATED WORK PRODUCTS TEMPLATE

WORK PRODUCT STATES WORK PRODUCT DEFINITIONS DESIGNER PROJECT MANAGER NAME SYNOPSIS OCCUPANCY CONSTRAINTS RELATED ROLES SKILLS NEEDED ROLE DEFINITIONS APPROVED CHANGES NEEDED NAME SYNOPSIS EXPRESSION CONDITION DEFINITIONS

Since many process attributes can be modeled, it is useful to group these attributes into categories, as shown in Figure 8. Attribute categories allow prioritization so that modeling can occur in stages. For example, a project may decide to describe data availability for activities in one stage of process modeling and control flow in a later stage. These categories are not indepen-dent so prioritization should take dependencies into consideration. For example, work products used and produced should not be modeled without first describing each work product.

5.1.2 Process performer selection

Process performers are chosen incrementally as the process is designed. Selection of pro-cess performers allows the propro-cess engineer to refine the determination of level of detail needed in the process design model. For example, if a configuration management tool with file management capabilities will be one of the process performers, then the process model only needs to state that a file is stored or retrieved and does not have to decompose file storage or retrieval into subactivi-ties.

5.1.3 Process model evaluation

are knowledgable in the process. Evaluation by the process engineer includes analyzing the design model for correctness, completeness, and consistency. The described process is also evalu-ated for completeness. Stakeholders may not understand the modeling notation. Therefore, the model is translated into more understandable forms. These include: Process Trees, IDEF₀ Dia-grams, and Process Tables.

Figure 9 shows a Process Tree for a Develop System Model activity. Process Trees were developed on the Army/Unisys STARS Demonstration Project to depict multiple levels of func-tional decomposition of a process in a hierarchical, graphical representation. This decomposition appears with activities connected by arrows. Arrows decompose an activity to its subactivities. Process Trees provide a convenient way of navigating complex process decompositions. Nodes within Process Trees can be used to index into IDEF₀ Diagrams and Process Breakdown Struc-tures. Process Tables are currently created manually, using the output of Process Mapper. Filters are used to format the Process Tables and sort activity attributes.

Figure 10 shows a Process Table for the Develop_system_model activity. Process Tables are used to present the textual, descriptive information contained in the Process Breakdown Struc-tures. Each table shows the Process Breakdown Structure attributes of one activity, work product or role.

Once presentation forms, such as Process Trees, IDEF₀ diagrams, and Process Tables have been created, they are distributed to stakeholders and review meetings are held. The results of these review meetings are used to improve the process model.

Figure 8. Process Attribute Categories.

Activity Attribute Categories Work Product Attribute Categories Activity Definition - Purpose - Description - Other Constraints Control Flow - Entry/Exit Criteria - Step States - Substep Grouping/Sequence Roles Required - Role Names - Communication Obligations Data Availability

- Work Products Used - Work Products Produced Subactivities

- Substep Names - Methods

Work Product Definition - Name - Synopsis Workproduct Relationships Workproduct States Workproduct Templates Role Definition - Name - Synopsis - Skills Needed Role Relationships Role Attribute Categories

5.2 R

P

D

• Include process performers in description activities.

Process performers should participate in process description meetings. Their par-ticipation allows them to contribute their understanding of the process, increases their sensitivity to following the process, gains their buy-in on process decisions, and allows them to be trained in the process as it is described.

• Follow techniques for running well-organized meetings.

Techniques for running well-organized meetings should be used to ensure that brainstorming and review meetings are productive. Holding many short meetings is more conducive to development of a quality process description than fewer long meetings. In group brainstorming meetings held to determine subactivities or cre-ate an IDEF₀ diagram, a reproducible, erasable medium (such as a reproducible white board) facilitates capturing and changing the process description during development. Since software development activities and the process for perform-ing these activities are integrated, meetperform-ings must be carefully facilitated to not allow engineering issues to divert the meetings. Issues should be captured and deferred to keep the meetings focused.

• Follow techniques for creating good models.

Since process models are similar to software models, techniques learned in model-ing software can be applied to modelmodel-ing processes. Techniques for creatmodel-ing good models that are specific to process modeling can be found in the SADT methodol-ogy described in [MM88] and in Process Mapper training classes.

Develop requirements view

Develop system model

Determine system model scope Verify operational capabilities of application Develop system model from legacy code Develop code view Develop architectural view Develop traceability

Develop_system_model

Path Do_Army_STARS_demo_project / Do_application_reeng / Enact_reeng / Develop_system_model Purpose Gain an understanding of the legacy system and capture this understanding in the

system model. This system model and the understanding gained will be used to help reengineer the system.

Work Products Used

Synopsis The legacy system (source code and documentation) are analyzed to determine the functionality of the legacy system and develop the system model. The Guardrail plan and Guardrail expectations report constrain the scope of the system model. Application reengineering conventions contain guidelines followed for system model development. Issues in the issue list and their resolutions also constrain system model development.

Expression Legacy_system AND Guardrail_plan AND Guardrail_expectations_report AND Application_reeng_conventions AND Issues_list;

Work Products Produced

Synopsis A system model is created that graphically describes the legacy system. The system model contains a requirements model, architecture model, and code model, along with traceability that connects these models.

Expression System_model;

Entrance Criteria

Synopsis The process definition and schedule have been completed for system modeling.

Exit Criteria

Synopsis All parts of the system model (requirements model, architecture model, code model, and traceability) have been completed and reviewed.

Roles Required

Role Application_engineering_team

Constraints CONTROLS: Guardrail_plan, Guardrail_expectations_report,

Application_reeng_conventions, Issues_list

Substep Grouping and

Substep Sequence

Expression CONCURRENT (Determine_system_model_scope, SEQUENCE(Verify_operational_capabilities, Dev_sys_model_from_legacy_code));

• Use IDEF₀ diagrams to understand work product availability during group meetings.

IDEF₀ Diagrams are easy for process performers to understand and create. Many software engineers are already familiar with IDEF₀because it is also used for sys-tem modeling. IDEF₀ works well for determining process activities and work product availability with process performers in a group setting.

• Use Process Breakdown Structures for detailed modeling of a process.

The Process Breakdown Structure formalism is excellent for defining detailed attributes and relationships of activities, work products, and agents of a process in a simple, textual form.

• Use Process Mapper’s analysis capabilities to evaluate the process model.

One of the strengths of the Process Mapper tool is its ability to analyze aspects of both the process model and the described process. Process Mapper allows process engineers to check a model’s syntactic correctness, referential integrity, complete-ness, consistency, and structural properties. For example, process engineers may use Process Mapper’s analysis tools to check consistency between hierarchy levels (e.g., determine whether a work product used by an activity is also used by one of the activity’s subactivities). As another example, Process Mapper’s analysis capa-bilities can be used to check a commonly suggested structural property: process activities should not be decomposed into more than five subactivities. In addition, Process Mapper allows process engineers to obtain information useful in evaluat-ing the process’ completeness, static properties, and dynamic properties. For example, consistency can be checked between the dynamics of data flow in a pro-cess and the dynamics of the propro-cess’s control flow, helping to assure that work products will actually be produced before they are needed.

• Use Process Trees to present an overview of the process.

Process Trees are an excellent means of providing a hierarchical picture of major project activities that can be easily understood by both project staff and those out-side the project. Process Trees also provide hierarchical indices into activity decompositions in IDEF₀ Diagrams and Process Breakdown Structures.

• Initially focus metrics selection on a small set of metrics.

Metric collection and analysis can easily be overwhelming. If metrics collection is new to the project, initial metrics selection should focus on a small set of metrics and be incrementally built upon as further metrics are required. Even the collection of simple data can require significant coordination.

6. P

ROCESS

I

MPLEMENTATION

6.1 A

P

I

As shown in Figure 11, Process Implementation involves preparing the process for perfor-mance including scheduling resources that perform the process, writing the instructions that are performed, installing the instructions on a machine, and training process performers on how to perform the process. Installation of instructions on a machine will not be addressed here since this activity is only performed for automated processes.

Process scheduling includes instantiating the process and scheduling resources that will perform the process. Process instantiation involves making decisions about the process based on project-specific details. For example, a process could be described allowing for object oriented or structured design. The decision about which design method to use must be made before the pro-cess can be scheduled. Another example is a propro-cess coding activity that explains the procedures for coding one module. This activity must be instantiated for each module that will be coded. Once the process has been instantiated it can be scheduled. Process scheduling occurs by assigning resources to each activity in the process decomposition.

Figure 11. Process Implementation IDEF₀ Diagram.

O1 Process Program O3 Ready Process Performers C1 Selected Process Performers I2 Existing Process Descriptions I1 Process Design Model M1 Process Description Mechanisms Develop Process Instructions A31 Install Process Instructions A32 Schedule Resources A33 Train For Performance A34 Automated Process Scheduled Process Performers Installed Process Performers O2 Schedule Manual Process

Development of process instructions involves implementing the process design to create procedures to be followed manually, or scripts that automate portions of the process. For each activity at the lowest level of decomposition in the process model, detailed procedures are created that tell the person performing the process how to perform the activity.

Process training for manual performance involves developing guidebooks and training pro-cess performers. Propro-cess guidebooks are presented both in hardcopy manuals and electronically on-line. A Mosaic electronic representation of the process can be used as a training aid to provide both overview information and hypertext links to the detailed process description. As shown in Figure 12 Mosaic can be used to access Process Trees, IDEF₀ Diagrams and Process Tables and allows hypertext-links to be followed to the other presentation forms. For example, when viewing an IDEF₀ Diagram a person can click on one of the work products in the diagram to follow a hypertext link to access the Process Table with attributes of the work product.

6.2 R

P

I

• Do not attempt automation of a process before the process is stable.

A newly described process usually evolves rapidly, making impractical the devel-opment of scripts to allow performance of the process by tools. Develdevel-opment of scripts should not be attempted until a process is stable and well-understood.

• Hardcopy procedures should be presented to performers for each activity sep-arately.

Determining the proper form of hardcopy presentation for process performers to achieve an understanding of their tasks, was a significant challenge. Many presenta-tion methods were tried on the Army/Unisys Demonstrapresenta-tion Project. Process per-formers became confused when they were presented procedures for many activities Figure 12. Mosaic process representation.

Hypertext Links Process Structure Breakdown Model Mosaic Guide Book Process Trees IDEF0 Model Roles Required Work Products Used Work Products Produced

Process Table for Activity Attribute 1

about one activity along with graphics that indicate where that activity fits into the overall process. As shown in Figure 13, a Process Packet contains a Process Tree, IDEF₀ Diagram, and Process Tables for the activity and relevant work products and agents. The Process Tree and IDEF₀ Diagram orient performers where the activity fits in the overall process. The Process Table for the activity includes the detailed procedures that the performer follows. The Process Packet can be refer-enced during performance to guide a performer through the process.

• An electronic hypertext-linked process representation provides good training material for new process performers.

Humans who will be performing a process need to understand both the general process and the details of activities that they will perform. A Mosaic representation of the process that includes both overview information and hypertext links to more detailed information can provide for both of these needs. The Mosaic representa-tion can also be accessed during performance to provide on-line guidance.

7. U

SE OF THE

P

ROCESS

D

ESCRIPTION

A

PPROACH

The Process Description Approach is based on the techniques used on the Army/Unisys Demonstration Project to describe domain and application engineering processes [STA94]. It is currently being used to describe the Process Description Approach itself and to describe a domain engineering method called Organization Domain Modeling [STA95].

The Unisys STARS team is currently creating both hardcopy and Mosaic electronic guide-books for the Process Description Approach. The approach will further evolve based on lessons learned during its application. Unisys STARS is investigating how to make the scope of the approach more general by including lessons learned from other process description efforts.

Uni-Figure 13. Process Packet Components.

Process Packet Process Table for

Attribute 1 Attribute 2 Attribute 3 ... Attribute N Work Product Process Table for Roles Process Breakdown Structure Model Roles Required Work Products Used Work Products Produced

Process Table for Activity Attribute 1

IDEF0

Model ProcessTrees

Attribute 1 Attribute 2 Attribute 3

... Attribute N

sys STARS is also planning to use the Process Description Approach to describe a CASE Tool Integration Process and the complete Process Management Process. The Process Management Process encompasses all of the activities in Figure 2 and includes automating portions of process performance.

8. C

ONCLUSIONS

The Process Description Approach described in this paper has proven to be an effective vehicle for achieving a common understanding of processes.

Strengths of the Process Description Approach include:

• Process Description using the Process Description Approach has resulted in early identification and resolution of many issues related to the processes that are described. Defining the process to greater detail in high risk areas allows these risks to be detected and addressed early.

• Describing software engineering activities is a good way to determine how these activities will be performed.

• Process description has been a good training instrument for explaining unprece-dented activities to teams who are performing these activities.

• Appropriate graphical diagrams have provided a good visual form of the process description and enabled review of the description.

• Process Breakdown Structures in the Process Mapper tool have been found to be an excellent means of capturing process details. The analysis capabilities of the tool ensure consistency and completeness of these details.

• Well-structured Mosaic World Wide Web representations of guidebooks provide a good mechanism for training process performers and allowing them to reference the process while it is being performed.

For more information on the Process Description Approach, please contact: Carol Diane Klingler

Unisys

12010 Sunrise Valley Drive Reston, VA 22091 Voice: (703)-620-7019

Fax: (703)-620-7916

[email protected] Dan Schwarting

Reston, VA 22091 Voice: (703)-620-7374

Fax: (703)-620-7916 [email protected]

9. R

EFERENCES

[Bas84] Basili, V. R. and Weiss D. M. “A Methodology for Collecting Valid Software Engineer-ing Data.” IEEE Transactions on Software EngineerEngineer-ing, 10(6), 1984, 728-738.

[Bas88] Basili, V. R. and Rombach, H. D. “The TAME project: Towards improvement-oriented software environments,” IEEE Transactions on Software Engineering, 14(6), 1988, 758-773. [Fei93] Feiler, Peter H., and Humphrey, Watts S. “Software Process Development and Enactment: Concepts and Definitions.” Proceedings of the Second International Conference on the Software

Process, Continuous Software Process Improvement. Berlin, Germany, February, 1993.

[Hum89] Humphrey, Watts S. Managing the Software Process. Addison-Wesley Publishing Co., Reading, Massachusetts, 1989.

[INS94a] INSTEP Inc. and SDA Inc., Process Description and Analysis Tool Sets. Report 23-65, February 1994.

[INS94] INSTEP Inc. and SDA Inc., PM User's Manual -- Software Release 2.3. Report 23-46, August 1994.

[MM88] Marca, David A., and McGowan, Clement L. SADT, Structured Analysis and Design

Technique. McGraw-Hill, New York, NY, 1988.

[NR94] B. Nejmeh and W. Riddle. Process Description and Analysis with PBS-based Tool Sets. Report 23-67, INSTEP Inc. and SDA Inc., September 1994.

[Ost87] Osterweil, Leon. “Software Processes are Software Too.” Proceedings of the Ninth

Inter-national Conference on Software Engineering. pp. 2-13, Monterey, CA, March, 1987.

[Sof81] Softech Inc. “Integrated Computer-Aided Manufacturing (ICAM) Architecture Part II. Volume IV - Function Modeling Manual (IDEF0).” Technical Report AFWAL-TR-81-4023 Vol-ume IV, Materials Laboratory (AFWAL/MLTC), AF Wright Aeronautical Laboratories (AFSC), Wright-Paterson AFB, Dayton, Ohio, June 1981.

[STA94] Software Technology for Adaptable, Reliable Systems (STARS). “Army STARS Dem-onstration Project Experience Report.” Unisys STARS Technical Report STARS-VC-A011R/002/ 02, Defense Advanced Research Projects Agency, STARS Technology Center, 801 N. Randolph St. Suite 400, Arlington VA 22203, February 1995.

[STA95] Software Technology for Adaptable, Reliable Systems (STARS). “Organization Domain Modeling.” Unisys STARS Technical Report, Defense Advanced Research Projects Agency, STARS Technology Center, 801 N. Randolph St. Suite 400, Arlington VA 22203, work in progress to be released March 1995.