Perspectives on Process Formalisms for

Enhanced Software Effectiveness

Leon J. Osterweil (ljo@cs.umass.edu)University of Massachusetts

Amherst, MA 01003

URL: laser.cs.umass.edu

DOD Software Summit

USC -- 7 August 2001

What do we mean by “process”

• Activities related to the development, verification, evolution, evaluation, management, etc. of software products

• Examples of high level processes:– Develop requirements– Do Object Oriented Design– Formally verify

• Examples of low level processes– Archive result of running a test case– Compile a piece of code

• Tend to be concurrent (coordination of people, systems)• Usually (regrettably) informal or undefined

Why the interest in process?

• Superior quality from superior processes– Build quality in, don’t “test in” quality (manufacturing)– Many observed “process errors”• Real processes are intricate, have intricate

interconnections• Machines can help people with process complexities

– Process effectiveness from human/machine synergy

Processes

• Are intangible and invisible– Although their effects are substantial

• How to improve their effectiveness?– Make them tangible, visible– Engineer them as first-class objects

• Use computer science formalisms to define processes

The Capability Maturity Model (CMM)is a Test Plan for Software Processes

The Capability Maturity Model (CMM)is a Test Plan for Software Processes

It supports a Black Box Testing Approach to Software Process

Improvement

The Capability Maturity Model (CMM)is a Test Plan for Software Processes

It supports a Black Box Testing Approach to Software Process

Improvement

We advocate White Box Analysis based on explicit process definition

Approaches to Process Definition• Process Definition may have different goals

– Communication

– Coordination

– Intuitive understanding

– Verification

– Training

– Automation

– Deep understanding

– Etc.

• Different definition formalisms support different of these goals to different degrees

• Formalisms vary in rigor, precision (semantic detail), semantic scope, clarity

Data Flow Diagram ofTraditional Waterfall Model

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

With More Rework

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

The Trouble with Dataflow Diagrams

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

Where does output go?

What causes this rework?

What portion ofactivity should bedone?

How do we break this cycle?

What to do when reviews fail?

Petri Net Requirements specification process

Interview

Develop Spec

Develop Implementation

DevelopersReal World

Users

RW_Desc

Sys_Spec_Diag

Sys_Impl_Diag +Sys_Spec_Diag

Design_Spec

JSD

Design Process Petri net

Req_Spec

Req_Spec

Identify_Object

Objects States

Identify_Operations

Operations Objects States

Establish_Visibility

Operations

Objects States

VisibilityEstablish_Interface

Interface

Create_Implementation

Implementation InterfaceCreate_Design_Spec

Design_Spec

Design_Spec

BOOD

HFSP design model

(a) JSD(Real_World | Design_Spec) =>(1)Develop_Spec(Real_World_Desc |System_Spec_Diagram)(2)Develop_Impl(System_Spec_Diagram |System_Impl_Diagram)(3)Where Real_World_Desc = Interview(Users, Developers,Real_World)(4) Design_Spec = union(System_Spec_Diagram, System_Impl_Diagram)

Second_level(b) Develop_Spec(Real_World_Desc |System_Spec_Diagram) =>(1)Develop_System_Model(Real_World_Desc |Real_World_Model, Init_System_Spec_Diagram)(2)Develop_System_Func(Real_World_Model, Init_System_Spec_Diagram |System_Spec_Diagram)

Third_level(c) Develop_System_Model(Real_World_Desc|Real_World_Model, Init_System_Spec_Diagram) =>(1)Model_Reality(Real_World_Desc |Real_World_Model)(2)Model_System(Real_World_Model |Init_System_Spec_Diagram)

(d) Develop_System_Func(Real_World_Model,Init_System_Spec_Diagram |System_Spec_Diagram)(1)Define_Func(Real_World_Model, Init_System_Spec_Diagram |System_Function, Function_Process)(2)Define_Timing(Init_System_Spec_Diagram, System_Function |Timing)(3)Where System_Spec_Diagram =is_composed_of(Init_System_Spec_Diagram, System_Function, Function_Process, Timing)

Fourth_level(e)Model_Reality(Real_World_Desc | Real_World_Model) =>(1)Identify_Entity_Action(Real_World_Desc | Entity_Action_List)(2)Draw_Entity_Structure(Entity_Action_List | Entity_Structure_List)Where Real_World_Model = is(Entity_Structure_List) Real_World_Process = is(Entity_Structure)(f) Model_System(Real_World_Model | Init_System_Spec_Diagram) =>(1)Identify_Model_Process(Real_World_Model | M_Proc_Name_List)(2)Connect(Real_World_Model, M_Proc_Name_List | Connection_List)(3)Specify_Model_Process(Connection_List, Real_World_Model, M_Proc_Name_List |Model_Process_List)(4)Where Init_System_Spec_Diagram = is(Model_Process_List)(5)Connection = is(State_Vector) or is(Data_Stream)

Little JIL

• Graphical language with execution semantics– Expresses process coordination– Designed to be used interchangeably with

other product, resource, scheduling factors• Visual JIL is the graphical interface to Little JIL

High-Level Process

Requirements Details

Design Details

Requirements Rework

Opportunities and Directions• Evolve and Improve Software Processes and Products• Through improving process languages by – Defining key processes– Using them to integrate tools– Automating processes– Analyzing and improving processes

• Effecting the definition and automation of superior processes for– Software development– Management– Procurement

• To assure superior software products