Perspectives on Process Formalisms for Enhanced Software Effectiveness

1. Perspectives on Process Formalisms forEnhanced 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

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

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

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

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

6. The Capability Maturity Model (CMM)is a Test Plan for Software Processes It supports a Black Box Testing Approach to Software Process Improvement

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

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

9. Data Flow Diagram ofTraditional Waterfall Model Requirements High-LevelDesign Low-LevelDesign Code Test

10. With More Rework Requirements High-LevelDesign Low-LevelDesign Code Test

11. The Trouble with Dataflow Diagrams Where does output go? Requirements What to do when reviews fail? What causes this rework? High-LevelDesign What portion of activity should bedone? Low-LevelDesign Code Test How do we break this cycle?

12. Petri Net Requirements specification process Developers Users Real World JSD Interview RW_Desc Develop Spec Sys_Spec_Diag Develop Implementation Sys_Impl_Diag + Sys_Spec_Diag Design_Spec

13. Req_Spec Design Process Petri net BOOD Req_Spec Identify_Object Objects States Identify_Operations Objects Operations States Establish_Visibility Objects States Operations Visibility Establish_Interface Interface Create_Implementation Implementation Interface Create_Design_Spec Design_Spec Design_Spec

14. (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)WhereReal_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) HFSP design model

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

16. High-Level Process

17. Requirements Details

18. Design Details

19. Requirements Rework

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