SE: CHAPTER 2 Modeling the Process and Lifecycle

1. SE: CHAPTER 2Modeling the Process and Lifecycle • What We Mean by “process” ? • Software development product • Process and resources • Models of software process • Techniques for process modeling

2. 2.1 The Meaning of Process • A Process is : • A set of ordered tasks • Or a series of steps involving activities, constrains and resources • That is aimed at producing an intended kind of output • It usually involves a set of tools and techniques • A Process has following characteristics • Prescribes all of the major process activities • Uses resources under some constraints • May contain sub-processes as activities each has its own model • Each Activity has entry and exit criteria • The process has a set of guiding principles that explain the goal of each activity • Constraints or controls may apply to activities, resources or product

3. The meaning of process • Life Cycle • When a process involves the building of some product, we refer to the process as the product’s Life Cycle • Thus, the software development process is also called the Software Life Cycle • Since it describes the life of a software product from its conception to its implementation, delivery, use and maintenance • Consistency and Structure of a Process • They are characteristics imposed on activities • To do things well and better • Process can be described in flexible way

4. The meaning of process • Process is more than a procedure • It is a collection of procedures organized to produce products that satisfy a set of goals and standards • It guides actions in making it possible to allow us to examine, understand, control and improve the activities. • Process can be used to capture experience • Software development process (see p.24~25) • Each stage is itself a process • Each activities involves constraints,outputs and resources • Each has some contribution to software quality of final product • Each process can be described in a variety of ways • Using Text, pictures or combination • Each process has its unique features

5. 2.2 Software Process Models • Reasons for software process models • Once a process is written down, • it reflects the common understanding of activities, resources and constraints about a specific way to develop software • The Process model helps find inconsistencies, redundancies for its products • Process becomes more effective and better for building the final product • The process model helps achieve the development goal • In finding faults early, meeting required budget and schedule, building high quality software • The process model circumscribes the special situation it should be used to make it be tailored specifically • Every Process Model takes system requirements • As the input to the process • And a delivered product as output

6. Waterfall Model • See Fig 2.1, p.49 • Features of waterfall mode • Stages are depicted as cascading activities • One stage should be completed before next begins • It is a very high level view of what goes on • And what the sequence of events or activities is • Milestones and deliverables are associated with each process activity • It makes explicit which intermediate products are necessary in order to begin the next stage • Waterfall model can be very useful and widely be used • More complex models are really just the establishment of the waterfall • Incorporating feedback loops and extra activities

7. Waterfall Model • Problems with waterfall model • The biggest problem : • It does not reflect the way code is really developed. • Actually software is developed with a great deal of iteration. • Solution must be upgraded to reflect some change in business climate or operating environment • Especially when the solution to a problem has never been solved before. • And when neither the users nor the developers know all the key factors that affect the desired outcome • The actual software development process, if uncontrolled, may look like that of Fig 2.2. (p.51) • Sidebar 2.1 • The model provide no guidance to managers and developers on how to handle changes to products and activities. • Its major shortcoming it its failure to treat software as a problem-solving process.

8. Waterfall Model • Prototype can be included in the process to control the thrashing (Fig 2.3, p.52) • Prototype • Is a partially developed product that enables customers and developers to examine some aspect of the proposed system • Prototyping • Helps to decide what is suitable or appropriate for the finished product. • Parts of the design may also be prototyped, to help developers to assess alternative design structures or strategies • User interfaces are often built and tested as prototypes • Major kinks (new ideas) in the requirements or structures are addressed and fixed well before they are validated. • Validation : making sure the product is built according to the requirement specification. • Verification : checking the quality of the software implementation.

9. V Model • See Fig 2.4, p.53 • It is a variation of the waterfall model • It demonstrates how the testing activities are related to analysis and design • Analysis and design are on the left, testing and maintenance on the right side of the V branches. • It tells us that each testing should be conducted to validate and verify the corresponding requirement and design specifications. • The model’s linkage of the left side with the right side of the V implies that • If problems are found during validation and verification, then the left side’s activities should be re-executed to fix and improve the requirements, design and code • The focus of V model is activities and correctness • Whereas the focus of waterfall model is documents or artifacts.

10. Prototyping Model • See Fig 2.5, p.53 • It can itself be the basis for an effective process model. • It allows all or part of a system to be constructed quickly to understand or clarify related issues. • It has the same objective as an engineering prototype • Where requirements or design require repeated investigation to ensure common understanding, correct design and implementation. • The overall goal is to reducing risk and uncertainty in development.

11. Operational Specification • See Fig 2.6, p.55 • The system requirements are evaluated and executed • In a way that demonstrates the behavior of the system • Once the preliminary system requirements are specified. • The evaluation or execution is enacted by using a software package • The specification is formulated in a abstract or formal way • The implications can be assessed before design begins. • This model is very different from other models • The waterfall model separates the functionality of the system from the design • This model allow the functionality and design to be merged. • Example : some executable models of software architecture can be developed in the form of an architecture description language.

12. Transformational Model • See Fig 2.7, p.55 • This model tries to reduce the possibilities for error by eliminating several major development steps. • Once the system requirements are established, a series transformations are used to change the specification (normally a formal one) into a deliverable system. • The transformation is supported by using specifically constructed automatic tools. • The transformations can be • Changing data representation, selecting algorithms, … • Major impediment is the need for an abstract and formal specification. • Becoming more popular and acceptance. • e.g. code generator.

13. Phased Development:Increments & interactions • Cycle time • The time from the very beginning of the system requirements and the system delivering. • Today’s business environment no longer tolerates long delays. • This model is developed to reduce the cycle time. • The phased development model • See Fig 2.8, p.56 • The system is designed so that it can be delivered in pieces • Enabling users to have some functionalities while the rest is being developed.

14. Phased Development:Increments & interactions • The phased development model • Operational or production system • The system currently being used by customers or users • This is referred to the system in terms of their Release numbers • Development system • The next version being prepared to replace the current production system • There are two ways to organize development into releases. • Incremental or iterative development

15. Phased Development:Increments & interactions • The phased development model • Incremental development (Fig 2.9) • The system is partitioned into subsystems by functionality • The releases are defined by beginning with one small, functional subsystem, • And then adding functionalities with new release • Iterative development (Fig 2.9) • The system is delivered with full functionality, • Then changes are made to enhance the functionality of each new release • In reality, they are combined.

16. Spiral Model • See Fig 2.10, p.58 • The Purpose of this model is to • Combine development activities with risk management • To minimize and control risk. • Evaluate alternatives and risks • after the requirements and an initial plan, a step to evaluation and prototype alternatives is inserted into the process • To ensure the requirements and plan are as complete and consistent as possible. • Then, the development and test steps formulates the product • And then process returns to the next iteration of requirements and plan steps.

17. Spiral Model • See Fig 2.10, p.58 • With each iteration • The risk analysis weighs different alternatives in light of the requirements and constraints • Prototyping verifies feasibility or desirability before a particular alternatives is chosen. • Conclusion of process models • Process models presented here are only a few of those discussed and used. • Process models should be defined and tailored to the needs of user, customer and developer. • The development process should be captured as a collection of process models, rather than focusing on a single model or view. • No matter what process model is used, many activities are common to all.

18. 2.3 Techniques Process Modeling • Process modeling • The appropriate technique for you depends on your goals and your preferred working style • Your choice for notation depends on what you want to capture in your model • Possible notations include • Textual ones that express processes as functions • Graphical ones that depict processes as linked boxes and arrows • Or the combination of textual and graphical one • Static model • Depicts the process to show how the inputs are transformed to outputs • Dynamic model • Can be enacted to enable users to see how intermediate and final products are transformed over time • In the following, we just focus on the static model.

19. Static model: Lai notation • A comprehensive process notation • To model any process at any level of detail • It builds a paradigm • where people perform roles • While resources perform activities • Leading to the production of artifacts • The process model • Shows the relationships among roles, activities and artifacts • And state tables show the information about the completeness of each artifact at a given time. • The elements of a process are viewed as 7 types

20. Static model: Lai notation • A comprehensive process notation • 7 types of elements • Activity : something what will happen in a process • Be related what happen before and after • What Resources needed, what triggers the activity, what rules govern the activity, how to describe the algorithms, and how to relate the activity to project team. • Sequence : the order of activities • Process model : a view of interest about the system. Parts of the process may be represented as a separate model. • Resource : an item, tool or person. Or equipment, time, office space, people, techniques, and so on. • Control : an external influence over process enactment. Manual or automatic, human or mechanical. • Policy : a guiding principle, to enforce any constraint on the process. • Organization : the hierarchical structure of process agents.

21. Static model: Lai notation • A comprehensive process notation • The process description may has several levels of abstraction. • Artifact definition Template • Example table 2.1 (p.61) and Fig 2.11 (p.62) • Artifact • State and state variable • activity • Other templates may define relations, process states, operations, analysis, actions and roles. • Transition diagrams supplement the process model by showing how the states are related to one another. • Fig 2.12 (p.62)

22. Reuse process model • The reuse process model for airframe software • See Fig 2.17 (p.71) • The boxes represent activities • The arrows • Entering the box from left are inputs or resources • Leaving the box on the right are outputs • Entering the box from the top are controls or constraints • Example : budgets, schedules, standards • Entering the box from the bottom are mechanisms • They assist in performing the activity • Such as tools, databases, techniques

23. 2.7 What this Chapter Means • What means for you • Software development processes involves activities, resources and products • Process models are useful for guiding your behavior when you are working with a group • How to coordinate and collaborate with others • What activities should be performed in the process • What should be produced in the process • Toward process models there are several perspectives : organizational, functional, behavioral and others.

24. What this Chapter Means • What means for your team • Shows each team member what activities occur and when, by whom • Making division of duties is clear

25. Exercises • On Page 76 • Problem 2 • Problem 3 • Problem 8 • Problem 9 • Problem 11