1. Software Engineering The Software Process (2)

2. 2 The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

3. 3 Discussion of the Waterfall Model Advantages:  Process visibility  Dependence on individuals  Quality control  Cost control

4. 4 The Classical Software Lifecycle The classical software lifecycle models the software development as a step-by-step “waterfall” between the various development phases. The waterfall model is unrealistic for many reasons: requirements must be frozen too early in the life-cycle requirements are validated too late Design Implementation Testing Maintenance Analysis Requirements Collection

5. 5 Incremental development

6. 6 Evolutionary Process Model

7. 7 7 Evolutionary DesignCodingTestDeploymentRequirementsDesignCodingTestDeploymentRequirementsDesignCodingTestDeploymentRequirements Feedback Version 1 Version 2 Version 3 New versions implement new and evolving requirements (Some call it iterative)

8. 8

9. 9 Background on software process models 9  1950 ： Code-and-fix model  1956 ： Stagewise model (Bengington )  1970 ： Waterfall model (Royce)  1971 ： Incremental model(Mills)  1977 ： Prototyping model(Bally and others)  1988 ： Spiral model(Boehm)

10. 10 Spiral development  Process is represented as a spiral rather than as a sequence of activities with backtracking.  Each loop in the spiral represents a phase in the process.  No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.  Risks are explicitly assessed and resolved throughout the process.

11. 11 Spiral Model material adapted from Steve Easterbrook Determine goals, alternatives, constraints Evaluate alternatives and risks Plan Develop and test budget 1 budget 2 budget 3 budget 4 prototype 1 prototype 2 prototype 3 prototype 4 alternatives 4 alternatives 3 Altern- atives 2 constraints 4 constraints 3 Constr- aints 2 alternatives constraints risk analysis 4 risk analysis 3 risk analysis 2 risk analysis 1 concept of operation software requirements validated requirements software design validated, verified design detailed design code unit test system test acceptance test requirements, lifecycle plan development plan integration and test plan implementation plan

12. 12 Details of the Spiral

13. 13 Boehm’s Spiral Lifecycle evolving system initial requirements first prototype alpha demo go, no-go decision completion Planning = determination of objectives, alternatives and constraints Risk Analysis = Analysis of alternatives and identification/ resolution of risks Customer Evaluation = Assessment of the results of engineering Engineering = Development of the next level product Risk = something that will delay project or increase its cost

14. 14 Spiral model sectors  Objective setting  Specific objectives for the phase are identified.  Risk assessment and reduction  Risks are assessed and activities put in place to reduce the key risks.  Development and validation  A development model for the system is chosen which can be any of the generic models.  Planning  The project is reviewed and the next phase of the spiral is planned.

15. 15 The spiral model 15 The Risk Management Plan  Identify the project’s top 10 risk items.  Present a plan for resolving each risk item.  Update list of top risk items, plan, and results monthly.  Highlight risk-item status in monthly project reviews. Compare with previous month’s rankings, status.  Initiate appropriate corrective actions.

16. 16 Spiral Model Advantages  Focuses attention on reuse options.  Focuses attention on early error elimination.  Puts quality objectives up front.  Integrates development and maintenance.  Provides a framework for hardware/software development.

17. 17 Prototyping Model material adapted from Steve Easterbrook  Prototyping is used for:  Understanding the requirements for the user interface  Examining feasibility of a proposed design approach  Exploring system performance issues  Problems  Users treat the prototype as the solution  A prototype is only a partial specification

18. 18 V Model material adapted from Steve Easterbrook system requirements software requirements preliminary design detailed design code and debug unit test component test software integration acceptance test system integration “analyze and design” “test and integrate” time Level of abstraction

19. 19 V Model  V- model means Verification and Validation model.  Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes.  Each phase must be completed before the next phase begins.  Testing of the product is planned in parallel with a corresponding phase of development.

20. 20

21. 21 V Model  Requirements begin the life cycle model just like the waterfall model.  But, in this model before development is started, a system test plan is created.  The test plan focuses on meeting the functionality specified in the requirements gathering.

22. 22 Agile Model (XP) material adapted from Steve Easterbrook Planning game Collect User stories Write test cases code integrate test Release Each cycle: approx 2 weeks

23. 23

24. 24 Agile Software Development  Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self- organizing, cross-functional teams.  Methods  Iterative  incremental

25. 25 Agile Software Development  It promotes adaptive planning, evolutionary development and delivery, a time- boxed iterative approach, and encourages rapid and flexible response to change.  It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

26. 26 What is Agility?  Effective response to change  Effective communication among all stakeholders  Drawing the customer onto the team; eliminate the “us and them” attitude  Organizing a team so that it is in control of the work performed  Rapid, incremental delivery of software

27. 27 Agile Software Process  Agile process must be adaptable  It must adapt incrementally  Requires customer feedback  An effective catalyst for customer feedback is an operational prototype

28. 28 Agile Model Driven Development (AMDD)

29. 29 Iterative and Incremental Development Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between.

30. 30 The principles of agile methods PrincipleDescription Customer involvementCustomers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental deliveryThe software is developed in increments with the customer specifying the requirements to be included in each increment. People not processThe skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace changeExpect the system requirements to change and so design the system to accommodate these changes. Maintain simplicityFocus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.

31. 31 Principles to achieve agility 1.Highest priority -> satisfy the customer 2.Welcome changing requirements 3.Deliver working software frequently 4.Business people and developers must work together 5.Build projects around motivated individuals 6.Emphasize face-to-face conversation1

32. 32 Principles to achieve agility 7.Working software is the primary measure of progress 8.Agile processes promote sustainable development 9.Continuous attention to technical excellence and good design enhances agility 10.Simplicity – the art of maximizing the amount of work not done – is essential 11.The best designs emerge from self-organizing teams 12.The team tunes and adjusts its behavior to become more effective

33. 33 Plan-driven and agile specification

34. 34 How AM Practices Fit Together

35. 35 Agile Process Models  Extreme Programming (XP)  Adaptive Software Development (ASD)  Dynamic Systems Development Method (DSDM)  Scrum  Crystal  Feature Driven Development (FDD)  Agile Modeling (AM)

36. 36 Extreme programming  Perhaps the best-known and most widely used agile method.  Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.  New versions may be built several times per day;  Increments are delivered to customers every 2 weeks;  All tests must be run for every build and the build is only accepted if tests run successfully.

37. 37 Extreme Programming (XP)  XP uses an object-oriented approach as its preferred development paradigm  Defines four (4) framework activities  Planning  Design  Coding  Testing

38. 38 Extreme Programming (XP) - 2 planning design coding test refactoring user stories values acceptance test criteria iteration plan simple design CRC cards spike solutions prototypes pair programming unit test continuous integration acceptance testing software increment project velocity computed Release

39. 39 XP - Planning  Begins with the creation of a set of stories (also called user stories)  Each story is placed on an index card  The customer assigns a value (i.e. a priority) to the story  Agile team assesses each story and assigns a cost  Stories are grouped to for a deliverable increment  A commitment is made on delivery date  After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

40. 40 Testing in XP Testing is central to XP and XP has developed an approach where the program is tested after every change has been made. XP testing features: – Test-first development. – Incremental test development from scenarios. – User involvement in test development and validation. – Automated test harnesses are used to run all component tests each time that a new release is built.

41. 41 XP - Testing  Unit tests should be implemented using a framework to make testing automated. This encourages a regression testing strategy.  Integration and validation testing can occur on a daily basis  Acceptance tests, also called customer tests, are specified by the customer and executed to assess customer visible functionality  Acceptance tests are derived from user stories

42. 42 Test-first development  Writing tests before code clarifies the requirements to be implemented.  Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.  Usually relies on a testing framework such as Junit.  All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors.

43. 43 Tests as Primary Artifacts Reduce Documentation by Single Sourcing Information  Acceptance tests are considered to be primary requirements artifacts  You can reduce your requirements documentation dramatically by not recording the same information twice  Unit tests are considered to be detailed design artifacts  You can reduce your design documentation dramatically and increase the chance that your detailed design artifacts are kept up to date by coders

44. 44 http://www.extremeprogramming.org/map/project.html

45. 45

46. 46

47. 47

48. 48

49. 49 Reuse-oriented software engineering  Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.  Process stages  Component analysis;  Requirements modification;  System design with reuse;  Development and integration.  Reuse is now the standard approach for building many types of business system

50. 50 Types of software component  Web services that are developed according to service standards and which are available for remote invocation.  Collections of objects that are developed as a package to be integrated with a component framework such as.NET or J2EE.  Stand-alone software systems (COTS) that are configured for use in a particular environment.

51. 51 Bank example  Requirements  Open an account for a customer (savings or chequing)  Deposit ƒ  Withdraw ƒ  Display details of an account ƒ  Change LOC ƒ  Produce monthly statements ƒ  Print a list of customers  Ambiguities  What is the difference between savings and chequing?

52. 52 Case study Children hospital  Care for children in the Alexandria city and some Arab countries  The average length of stay of inpatients is 3.6 days  All patients are accompanied by a parent for the entire duration of their stay at hospital

53. 53 Case Study: Sensor Display  Consider a small system that displays the status of several sensors (e.g., pressure, temperature, rate of change, etc.) on a limited-size screen  What are some of its functional requirements?  What are some of its non-functional requirements?

54. 54 ATM system