Download presentation
Presentation is loading. Please wait.
1
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
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
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 of Traditional Waterfall Model Requirements Low-Level Design Code Test High-Level Design
10
With More Rework Requirements Low-Level Design Code Test High-Level Design
11
The Trouble with Dataflow Diagrams Requirements Low-Level Design Code Test High-Level Design Where does output go? What causes this rework? What portion of activity should be done? How do we break this cycle? What to do when reviews fail?
12
Petri Net Requirements specification process Interview Develop Spec Develop Implementation Developers Real World Users RW_Desc Sys_Spec_Diag Sys_Impl_Diag + Sys_Spec_Diag Design_Spec JSD
13
Design Process Petri net Req_Spec Identify_Object Objects States Identify_Operations Operations Objects States Establish_Visibility Operations ObjectsStates Visibility Establish_Interface Interface Create_Implementation ImplementationInterface Create_Design_Spec Design_Spec BOOD
14
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)
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
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.