Process Definition and Modeling Guidebook

The objective of this guidebook is to guide you in efficiently developing and evolving a quality set of process definitions that will direct and improve the ways you develop software-both to improve your products and process and to allow assessment at the DoD Software Engineering Institute's (SEI) Capability Maturity Model (CMM) Levels 2 (Repeatable) and 3 (Defined). You should be better able to engineer your process descriptions and the processes themselves.

This guidebook offers a practical approach to reflecting experience and distilled research, and includes highlights from a significant, real-world example. This approach has several characteristics that help ensure a successful process definition and modeling effort. For example, Managed Process Definition Methodology (MPDM):

• Provides "how to" guidance for early success and a sound foundation for continuing success
• Organizes the definition as it is developed
• Avoids unnecessarily elaborate or formal notations
• Is driven by your goals
• Considers your context and the factors you need to deal with in your situation
• Exploits simple automation to rapidly generate and revise guidebooks, training material, etc.
• Directly supports management (including self-management) of the process definition effort

Organizations need to have a representation option that combines the strengths of text- and graphic-based representations while minimizing their respective weaknesses. MPDM is specifically designed to support process representation as three separate yet tightly integrated concerns: (1) design, development, and implementation of the process model; (2) generation of various output products, such as guidebooks and training material, from your process model; and (3) management and review of the development of both the process model and the derived output products.

The data-organizing templates presented in this guidebook can be rendered as paper templates, but their design directly facilitates "automated templates" via mainstream information management repositories. Examples of template fields include text-oriented descriptions of activities, pre- and post-conditions, internal processing, comments, role descriptions, product descriptions, risk types and levels, revision history, etc. However, through a variety of relationships the templates also convey an explicit architecture directly supporting graphical rendering and analysis. This combined template- and graphically-based approach provides you greater opportunity for the optimal combination of both text and diagrams toward the cost-effective development and use of process representations.

There are numerous goals for process definition:

• To improve your processes organization-wide such as through a Total Quality Management (TQM) initiative
• To reduce software management or technical problems
• To respond to customer or market pressures to improve or certify such as SEI CMM or ISO 9000
• To reach aggressive business goals involving software
• To augment or replace existing process documentation that is either unused or too expensive to maintain

Process definitions are needed for the same reasons sports teams need playbooks. A team without a playbook must transfer everything from head to head typically through long apprenticeship, is only as good as what is in their heads, has more trouble adjusting and improving plays, scratches their changes only in the dirt, and can never be on the same page. Though they do different things with them, playbooks are important to both coaches and players-an essential organizational asset.

Every software organization, regardless of size or maturity, has a process for developing and maintaining software. When using a defined software process, your organization may experience some of the following benefits:

• Improved productivity (and teamwork) because communication among the process users, managers, process developers, and customers is more effective
• Reduced rework because you identify and eliminate problems early in the process rather than later
• Efficient project staff start-up time because there is a documented process to train them on
• Reduced software development costs due to reduced volatility in software development processes
• Improved predictability of budgets and schedules because you have defined what to measure, when to measure it, and how to use the information
• Improved tool usage because tool usage is defined and supported by training material
• Faster project start-up because the project has a process that it can tailor
• Increased integration between resulting products due to improved coordination among and communication between teams
• Increased quality of the resulting products because reviews are defined and understood to be an integral part of the process

Existing examples of process representations include policy, procedures, and operational manuals developed by organizations to inform and guide their employees in the performance of their responsibilities. Most organizational process guidebooks only define the process, but a few make use of relatively high-level or simple process models.

Although process modeling is a comparatively rare technique for representing organizational processes, it is a well-known and mature technique for representing systems implemented by computer systems. Example techniques include State charts, Structured Analysis and Design Technique (SADTs), and the Entry-Task-Validation-eXit (ETVX) paradigm. Due to fundamental parallels between defining and modeling organizational processes and computer-based systems processes, you can apply many techniques from systems process representation to organizational process representation. Similarly, many of the advantages and benefits derived by building computer process representations can also be derived from organizational process representations.

2.0.2  1 June 94  Initial release to the PAL

Approved for public release; Distribution unlimited

This documentation is provided "AS IS" and without any expressed or
implied warranties whatsoever.  No warranties as to performance,
merchantability, or fitness for a particular purpose exist.
The user must assume the entire risk and liability of using this
document.  In no event shall any person or organization of people be
held responsible for any direct, indirect, consequential or
inconsequential damages or lost profits.