Guide the reader in creating a quality set of process definitions

Move to top-level taxonomy
Move to keyword list


2.0.2, SPC-92041-CMC, 01-DEC-93
Software Productivity Consortium
Approved for public release; distribution unlimited
1993 SPC


Directory Display

  File Name                 Size
  ---------                 ----
  README                   6,004          8,322,037

  ==============  ==============
    2 Files            8,328,041


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

* 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

* Improved productivity (and teamwork) because communication among the
process users, managers, process developers, and customers is more

* 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

* 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

* 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.