Process Modeling in Software Development: Principles and Challenges

1. Chapter 2 Main Concepts of Process Modeling Prof.Dr.Michael M. Richter

2. Additional Recommended Literature • A good overview over MILOS can be found in http://ser..ucalgary.ca/~milos/Library.htm • B. Dellen, F. Maurer: Change impact analysis support for software development processes, International Journal of Applied Software Technology, ISSN 1198-5577, Vol 4, No 2/3, International Academic Publishing, Scarborough, Ontario, Canada, 1998. • H.D. Rombach: Practical Benefits of Goal Oriented Measurements. Software Reliebility and Metrics. Elsevier Applied Sycience,1991 Prof.Dr.Michael M. Richter

3. PART 1 General Principles Prof.Dr.Michael M. Richter

4. Motivation • The main tasks for a software project are the creation of a project plan in order to deliver certain software products. • This can be supported in various ways: • coordination of different activities within a project following a defined development process • coordinating planning and enactment (execution) • providing access to multiple information related to the current project context. This information can be • distributed, heterogeneous, unstable and hard to find. • The support is provided by Process-centered Software Engineering Environments (PSEE). Prof.Dr.Michael M. Richter

5. Socio-Technical Processes (1) • Software development processes are processes where the participating members („agents“) can be humans as well as machines. • This requires a careful organization of the division of labor: • What do humans? • What do machines? • A particular problem is the communication between humans and machines: • Humans have difficulties to understand the results of machines • Machines have difficulties to understand the results of humans Prof.Dr.Michael M. Richter

6. Socio-Technical Processes (2) • Conflicting demands: • Machines need precise instructions • Humans want to use creativity. • Plans and Executions: • They alternate, before all requirements are present and before planning is finished execution of some actions start. • Requirements may change over time • Requirements are often imprecise and incomplete Prof.Dr.Michael M. Richter

7. Human versus Machine • Who is better, human or machine? • This is the wrong question. Better: Who is better, human with machine or human without machine? • The relation is not symmetric: • The human has the responsibility and makes the decisions • The machine is a servant and does what it is told (it is an assistant system). • In extreme cases there are only humans or only machines. • In relality, there will be a mix. This mix is not fixed. If a task is fully understood it can switch from a human to a machine agent. Prof.Dr.Michael M. Richter

8. Socio-Technical Processes are Concurrent Concurrent, parallel: Execution Collecting Information Planning All three arrows represent again complex concurrent activities. Concurrency creates communication problems! Prof.Dr.Michael M. Richter

9. Consequences • Because of • Incomplete information and knowledge • Creativity of human agents • Partially unknown behavior of machines: • Planning on the level of details is often impossible • Therefore: Planning is essentially organization • Questions: • How should that be done? • What has to organized? Prof.Dr.Michael M. Richter

10. Formal versus Informal Communication • Traditionally, computer scientist prefer a formal communication: They exchange formal documents. • This may not always be the best choice because the two partners in the discussion can have different contexts and formal statements may have a different meaning in these contexts. Also, formal statements are often too detailed. • As a consequence one can use informal expressions which the partner interprets using his/her own intelligence. • Therefore a support system should allow informal entries. Prof.Dr.Michael M. Richter

11. Semi-Formal Documents • Semi-formal documents combine formal and informal parts. • Formal parts can be programs, strict advises (e.g. deadlines) or structures for documentation (e.g. a graph structure). They can be interpreted by machines. • Informal parts can be texts, annotations etc. They can only be interpreted by humans. • In process modeling semi-formal documents occur frequently. Prof.Dr.Michael M. Richter

12. Execution (1) • Planning takes place in a model. • There is also an external world. In this world • actions are executed; executions can never be retracted, they are done. In contrast to planning, an execution can fail. • costs apply (“in reality”) • additional information may be available. • The external world is partially mapped into a model world but it exists independent of the model. • It can be influenced by the user but not completely controlled. Prof.Dr.Michael M. Richter

13. Execution (2) • Planning steps can withdrawn on the cost of planning steps, execution steps can never be withdrawn. There may be only other steps that reverse some activity and this is sometimes impossible: • If you inform someone the information cannot be withdrawn • If you delete something etc. • In any case, some costs will apply. • Execution needs extra agents with special skills and special knowledge is necessary. Prof.Dr.Michael M. Richter

14. Realizing Flexibility: The Overall View • Techniques & methods for integrated planning and execution • Detailed Planning during execution • Plan correction during execution • Techniques & methods for dependency derivation and administration • Controlling dependencies and the flow of activities and artifacts (products) Prof.Dr.Michael M. Richter

15. PART 2 Details Prof.Dr.Michael M. Richter

16. MILOS • The terminology is taken mainly from the MILOS-System (which is a specific PSEE) but is essentially also in most other systems: The difference to other support systems is mainly notationally (e.g. Protege´). The successor of MILOS in Calgary is MASE. • MILOS: Minimally Invasive Long Term Organizational Support is a support system for socio-technical processes which realizes most of the concepts and method presented in this chapter. • It supports knowledge management activities. • The main additions are • scheduling and release planning • experience support • explanation aspects Prof.Dr.Michael M. Richter

17. Process Modeling Languages • Systems that support planning and coordination of software development have to represent the entities used in project plans. They allow representing knowledge about software development processes. • We need to define • ·        Process, product and resource models • ·        Project plans • ·        Product deliverables developed within projects • ·        Background knowledge such as guidelines, business rules, studies etc. Prof.Dr.Michael M. Richter

18. Concept Description process Description of a set of activities that have to be executed in order to reach a given goal containing e.g. input and output documents etc. method A method describes how a process goal can be achieved. complex method Problem solving method that refines a process into one or more subprocesses. atomic method Leaf within the process/method hierarchy. It produces or modifies a product. Overview: Basic Concepts (1) Prof.Dr.Michael M. Richter

19. Overview: Basic Concepts (2) Attribute of a process. process attribute A product is an information unit for example a document or a piece of code. product The description of type and structure of a class of products. product type parameter Describes a product within a process. It consists of product name and type (e.g. ClassDiagram or URL) Prof.Dr.Michael M. Richter

20. resource Resources are used for the execution of the project. Overview: Basic Concepts (3) product attribute Attribute of a product. Product references stand for the type of products that are used and/or produced by a process or a method. We distinguish between products that are consumed for planning, consumed for execution, produced, and modified. product reference This parameter type stands for a product of a given type that is produced by an atomic method of a process. produce product Prof.Dr.Michael M. Richter

21. resource attribute process models project plan Attribute of a resource. Process models are generic, reusable descriptions of how to execute projects A project specific model precondition A condition that has to be valid to carry out a process. postcondition A condition that has to be valid after a process has been executed. Overview: Basic Concepts (4) A human or machine that carries out activities within a process. agent Prof.Dr.Michael M. Richter

22. Plan-Processes and Methods (1) • In a project plan there are alternating • Processes • Methods • Each process is realized by some method. The method can be atomic or complex. Often one has the choice between different methods and has to select one. • Below some complex method one or more subprocesses can be created. • Atomic methods cannot be refined furthermore. • This gives a hierarchical organization. • To each process one or more agents can be assigned. The agents are taken from an agent pool („Resources“) that has to be filled before. Prof.Dr.Michael M. Richter

23. Plan-Processes and Methods (2) • Methods are either complex or atomic. Complex methods refine a process into one or more subprocesses whereas the application of an atomic method results in the production of products that are the outputs of the process. • Inputs of a process may either be products that are produced by other processes during project enactment or predefined background knowledge (e.g. manuals or guidelines) taken from generic process models. Prof.Dr.Michael M. Richter

24. Example: Project Plan Requirements Design Process System Design Implementation Code Java OO Create class diagramm Class diagram Define operations Prof.Dr.Michael M. Richter

25. Example in the representation language of Milos: We see a top-down plan of a task. Each plan is realized by a method. Each complex method is subdivided into different subplans. Prof.Dr.Michael M. Richter

26. Partial Tree View of the Same Project Plan Prof.Dr.Michael M. Richter

27. Process Description (1) Formal definitions: • Process: <process name> • Goal: <process goal description> • Instructions: <process instructions> • Input Products: {<product name>’:’<product type>}* • Output Products: {<product name>’:’<product type>}* • Modify Products: {<product name>’:’<product type>}* • Context Products: {<product name>’:’<product type>}* • Entry/Exit Conditions: {boolean expression} • Methods: {<method name>}* Prof.Dr.Michael M. Richter

28. . Process Description (2) Process name: It is a process identifier, unique within the scope of a method. Process goal: Textual description of the intended results of a process execution. Process instructions: Textual description of special tasks and guidelines how to perform the process. Product name: It is a product identifier, unique within the scope of a method. Product type: Each product has an uniquely associated product type. For example, a TestReport can be of type TextProduct. Each possible product type is discussed in more detail in the Product Model description Prof.Dr.Michael M. Richter

29. Process Description (3) • Context products: products that are already accessible at modeling time. For example guidelines, handbooks, etc. • Entry/Exit conditions: determine the control flow between processes. Entry condition should be fulfilled to start the process execution. Exit Input/Output/Modify products: products that can be consumed, created or changed by a process. It is a parameter declaration. • condition state the condition that should hold after the process has been finished. • To control the process flow Entry/Exit conditions can reference the state of processes and products. • Product state: A product attribute that indicates the development grade of a product. For this work we considered four possible states: no-existent, to- Review, toChange, complete. The state transition diagram depicts detailed relationships between these product states. Prof.Dr.Michael M. Richter

30. Table of Method Description • Method: <method name> • Goal: <method goal> • Instructions:<method instructions> • Additional Input/Modify/Output Products: • {<product name>’:’<product type>}* • Refined Input/Modify/Output Products: • {<product name>’:’<product sub-type>}* • Additional Entry/Exit Conditions: {boolean expression} • Parameter Mappings: {<process name>’.’<product name> • ’-->’<process name>’.’<product name>}* • Sub-Processes: {<process name>}* Prof.Dr.Michael M. Richter

31. Process Models • A project plan describes an individual process. • A process model describes a set of processes, it allows to define specific processes. • Therefore: A process model may contain plan processes that have more then one method, e.g. • one may use Java or C++ for an implementation • one may use the GUI A or the GUI B. • These methods are seen as alternatives and can be seen as experiences. Therefore they are stored as experiences. • For a specific plan one method is selected. • In experience bases it is important to mention under which conditions some alternative is useful. Prof.Dr.Michael M. Richter

32. Process Models and Methods • Within process models activities and their interrelationship are described. • A more general description of processes in process models defines a • the process goal, • a set of conditions, • process attributes, • the products needed to plan and to execute the process, • a set of alternative methods to reach the process goal, • the products to be produced and resource allocations. Prof.Dr.Michael M. Richter

33. Example: Process Model for Software Development (1) Processes, Inputs, Outputs system design requirements design process system design implementation code Prof.Dr.Michael M. Richter

34. Example: Process Model for Software Development (2) Alternative Processes Implementation Design process Atomic methods Complex methods Use Cobol Use Java Use C++ Object oriented design Procedural design Prof.Dr.Michael M. Richter

35. Example: Process Model for Software Development (3) Design process Object Oriented design Process refinement Create class diagram Define operations Prof.Dr.Michael M. Richter

36. Example: Process Model for Medical Applications Alternative Processes Methods used Evaluation process Atomic methods Complex methods Use Ultra Sound Use X-Ray Use MR Local statistical evaluation National evaluation Prof.Dr.Michael M. Richter

37. Product Models • We need the specification of hierarchical, object-oriented product models. A product type defines the structure of a set of products with the same behavior. • A product type is either basic or complex. • Basic types are predefined and may be integer, real, string, text, date, or external references such as a www page URLs or word documents. A complex type consists of one or more typed subproducts and attributes. Complex product types can be specialized (IS-A relation). • Based on a given product model, products instances (synonyms: products, deliverables) that contain general and specific project knowledge of a company can be defined. Prof.Dr.Michael M. Richter

38. Example: DICOM-Standard • DICOM (Digital Imaging and Communication in Medicine) is a standard covering medical data format for digital medical data. • It is developed by the American College of Radiology and the National Electric Manufacturs Association. • The standard deals with the exchange of digital information between medical image equipment. • Main application areas: • Network image management • Structured reporting • Network print management • Image procedure management • Offline storage media management Prof.Dr.Michael M. Richter

39. Example: Computer-Based Patient Record • A Computer-Based Patient Record (CPR) is an electronic patient health record that documents and provides access to information about the patient´s general health condition, present and past illnesses and diagnosis, the status and treatment data. • A DICOM Structured Report is a structured Document which contains documentation of a patient´s examinations, diagnosis and treatment data. • It may also contain embedded references to other structured reports, images, waveforms, and audio. • It contains context information, such as scheduled procedures, observer, previous reports and images. • It encodes only semantic information and not presentation information. Prof.Dr.Michael M. Richter

40. DICOM Network Transport Section Association Control Service Element (ACSE) OSI Presentation Kernel OSI Session Kernel TCP OSI Transport DICOM Data Link OSI Network LLC Standard Network Physical Layer (Ethernet, FDDI, ISDN, etc.) Example: Medical Imaging Application DICOM Application Entity OSI Upper Layer Boundary DICOM Upper Layer Protocol for TCP/IP DICOM Physical Conection (50 pins) IP Point-to-Point Environment Network Environment Prof.Dr.Michael M. Richter

41. Parameter Mappings (1) If two processes use the same product this has to be documented. This is done by mappings between the corresponding parameters. We distinguish vertical and horizontal mappings. Example: Parameter 1 Process1 map 1 on2 Process 1.2 Parameter 2 Process 1.1 Parameter 3 Parameter 4 Prof.Dr.Michael M. Richter

42. Parameter Mappings (2) • Vertical mappings connect two input or two output parameter in a process refinement. • A horizontal mapping in a refinement map an output parameter of one process to an input parameter of the other process. • The parameter mappings describe the flow of products in a project. • An extension of this principle becomes necessary if one wants to describe the product flow between different projects. Prof.Dr.Michael M. Richter

43. Precedence Relations • This relation says: One process B must precede another process B • The major reason for such a relation is: an output parameter of one process A is an input parameter of the other process B. • This means: The flow of products determines to some degree the order of the enactment of the processes. Prof.Dr.Michael M. Richter

44. Agents (1) • The participants in an assistant system are also called agents. • Intelligent machine assistants that use software tools are often called softbots. • Softbots have knowledge, methods and strategies. • Agents may act • on demand • on their own: Pro-active • Actions of agents must be triggered. • The behavior of agents may be known to other agents. The behavior of softbots may not be known even to humans (e.g. search machines in the internet). Prof.Dr.Michael M. Richter

45. Agents (2) • „Agent“ is used as a modeling concept to describe active entities that carry out tasks. In order to make this precise the properties of an agent have to be specified precisely. • Two sub-concepts of agent are defined: • Actor: A human agent working on a project like a project planner or developer. An actor interacts with the system via graphical interfaces. • Computer agent: A software entity that can be started on a computer and performs a task, e.g. a delegation or compilation of a program. • Both, actors and computer agents have qualifications that determine the tasks they can carry out. • Both can use tools. • Both are not restricted to a specific location. Prof.Dr.Michael M. Richter

46. Agents (3) • Agents occur essentially in two ways: 1) A company has agents, organized in a pool. 2) A task requires agents in order to be performed. • This defines a matching problem. • Because of restricted available agents this also is an optimization problem. • In a project plan this match has to be performed. However, the plan does not say how this is done; for this purpose one needs extra support by scheduling tools. Prof.Dr.Michael M. Richter

47. Resource Models • The resource pool component manages roles, agents and agent properties. It allows representing the organizational structure of a company as well as a skill ontology. • An agent can have a set of skills. Resource models allow assigning roles and qualifications to project team members. • These models describe knowledge needed by project managers to find appropriate people for a task. The project planner can query the resource pool for all agents with specific skills. • Agents can be humans or software agents Prof.Dr.Michael M. Richter

48. Project Planning • Project planning is essentially an instantiation of process models. • Planning a project comprises: • · Selecting appropriate processes (e.g. from some experience base), and inserting them into the plan, • · Selecting applicable development methods according to the characteristics of the organizations (e.g. familiarity with specific methods) and the goals of the project. ·  Instantiating the variables in pre- and post conditions, Prof.Dr.Michael M. Richter

49. Typical Problems in Project Planning • Are concerned with the specific task • Selection of processes • Instantiation of general steps • Obtaining missing information • Decisions about details and execution • Availability of resources • Sequence and ordering problems • Time planning, scheduling Prof.Dr.Michael M. Richter

50. Project Plan Management • The project plan management component allows customizing a process model, resulting in a project plan. • It includes as major elements • adding/removing tasks • scheduling planned start and end times of processes • assigning agents to processes. Prof.Dr.Michael M. Richter