1. Software Process Models (Sommerville Chapters 4, 17, 19, 12.4)

1. 1. Software Process Models(Sommerville Chapters 4, 17, 19, 12.4) A software process model is a standardised format for • planning • organising, and • running a development project.

2. Hundreds of different models exist and are used, but many are minor variations on a small number of basic models. In this section we: • survey the important basic models, and • consider how to choose between them.

3. 1.1. Planning with Models SE projects usually live with a fixed financial budget. (An exception is maintainance?) Additionally, time-to-market places a strong time constraint. There will be other project constraints such as staff.

4. Support e.g. sales Specialist technical staff management money staff Project constraints Computing resources time Examples of Project Constraints

5. Project planning is the art of scheduling/constraint solving the project parameters, along various dimensions: time, money, staff … in order to optimise: • project risk [low] (see later) • profit [high] • customer satisfaction [high] • worker satisfaction [high] • long/short-term company goals

6. Questions: • Whatareproject parameters? 2. Are theregoodpatterns of organisation that wecouldcopy?

7. Project parameters describe the whole project, but we must at least describe: • resources needed (people, money, equipment, etc) • dependency & timing of work (flow graph, work packages) • rate of delivery (reports, code, etc) It is impossible to measure rate of progress except with reference to a plan.

8. In addition to project members, the following may need access to parts of the project plan: • Management • Customers • Subcontractors (outsourcing) • Suppliers (e.g. licenses, strategic partners) • Investors (long term investment) • Banks (short term cash)

9. 1.2. Project Visibility Unlike other engineers (e.g. civil, electronic, chemical … etc.) software engineers do not produce anything physical. It is inherently difficult to monitor an SE project due to lack of visibility.

10. This means that SE projects must produce additional deliverables (artifacts) which are visible, such as: • Design documents/ prototypes • Reports • Project/status meetings • Client surveys (e.g. satisfaction level)

11. 1.3. What is a Software Process Model? Definition. A (software/system) process model is a description of the sequence of activities carriedout in an SE project, and the relative order of theseactivities.

12. It provides a fixedgenericframework that can be tailored to a specificproject. Project specificparameterswillinclude: • Size, (person-years) • Budget, • Duration. project plan = process model + project parameters

13. There are hundreds of different processmodels to choose from, e.g: • waterfall, • code-and-fix • spiral • rapid prototyping • unified process (UP) • agilemethods, extreme programming (XP) • Scrum • COTS … Most are minor variations on a small number of basicmodels.

14. By changing the process model, we can improveand/ortradeoff: • Development speed (time to market) • Product quality • Project visibility • Administrative overhead • Risk exposure • Customer relations, etc, etc.

15. Normally, a process model covers the entire lifetime of a product. From birth of a commercial idea to final de-installation of last release i.e. The three main phases: • design, • build, • maintain. (50% of IT activity goes here!)

16. Wecansometimescombineprocessmodelse.g. • waterfallinsideevolutionary – onboardshuttlesoftware 2. Evolutionaryinsidewaterfall–e.g. GUI prototyping 3. SCRUM insidewaterfall Wecanalsoevolve theprocessmodeltogetherwith the product to account for productmaturity, e.g.rapid prototypingwaterfall

17. 1.4.WaterfallModel • The waterfallmodel is the classicprocess • model – it is widelyknown, understood and used. • In somerespect, waterfall is the ”common • sense” approach. • R.W. Royce, Managing the Development of Large Software Systems: Concepts and Techniques, Proc. IEEE Westcon, IEEE Press, 1970.

18. phase output User Requirements User Requirements Document Software Requirements Document Software Requirements Architectural Design Document Architecture Design ”Swimming upstream” Detailed design & Coding Detailed Design & Code Testing The Waterfall Workflow Delivery Time

19. Advantages • Easy to understand and implement. • Widely used and known (in theory!) • Fits other engineering process models: civil, mech etc. • Reinforces good habits: define-before- design, design-before-code • Identifies deliverables and milestones • Document driven:People leave, documents don’t Published documentation standards: URD, SRD, … etc. , e.g. ESA PSS-05. • Works well on large/mature products and weak teams.

20. Disadvantages • Doesn’t reflect iterative nature of exploratory development. • Sometimes unrealistic to expect accurate requirements early in a project • Software is delivered late, delays discovery of serious errors. • No inherent risk management • Difficult and expensive to changedecisions, ”swimmingupstream”. • Significant administrative overhead, costly for small teams and projects.

21. 1.5. Code-and-Fix This model starts with an informal general product idea and just develops code until a product is ”ready” (or money or time runs out). Work is in random order. Corresponds with no plan! (Hacking!)

22. Advantages • No administrative overhead • Signs of progress (code) early. • Low expertise, anyone can use it! • Useful for small “proof of concept” projects, e.g. as part of risk reduction.

23. Disadvantages • Dangerous! • No visibility/control • No resource planning • No deadlines • Mistakes hard to detect/correct 2. Impossible for largeprojects, communicationbreakdown, chaos.

24. 1.6. Evolutionary Development Types Type 1: Exploratory Development: customer assisted development that evolves a productfrom ignorance to insight, starting from core, well understood components (e.g. GUI?) Type 2: Throwaway Prototyping: customer assisted development that evolves requirements from ignorance to insight by means of lightweight disposable prototypes.

25. 1.7. Type 1: Spiral Model Extends waterfall model by adding iteration to explore /manage risk Project risk is a moving target. Natural to progress a project cyclically in four step phases • Consider alternative scenarios, constraints • Identify and resolve risks • Execute the phase • Plan next phase: e.g. user req, software req, architecture … then goto 1

26. In 1988 Boehm developed the spiral model as an iterative model which includes risk analysis and risk management. Key idea: on each iteration identify and solve the sub-problems with the highest risk.

27. Cumulative cost Evaluate alternatives, Identify & resolve risks Determine objectives, alternatives & constraints C.f. Sommerville Figure 4.5 Prototypes Operational Prototype Start Phase1 Phase2 Phase3 Review & commitment Requirements plan Concept Of Operation Design, Validation & Verification Detailed design Development plan Requirements validation Coding Integration & Test plan Unit & Integration Testing End Acceptance Testing Develop & verify next-level product Plan next phase

28. Advantages • Realism: the modelaccuratelyreflects the iterative nature of software development on projects with unclearrequirements • Flexible: incoporates the advantages of the waterfallandevolutionarymethods • Comprehensivemodeldecreases risk • Good projectvisibility.

29. Disadvantages • Needstechnicalexpertise in risk analysis and risk management to work well. • Model is poorlyunderstood by non-technical management, hence not so widelyused • Complicatedmodel, needscompetentprofessional management. High administrative overhead.

30. 1.8. Type 2: Rapid Prototyping Key idea: Customers are non-technical and usually don’t know what they want. Rapid prototyping emphasises requirements analysis and validation, also called: • customer oriented development, • evolutionary prototyping

31. Requirements Capture Iterate Quick Design Build Prototype Customer Evaluation of Prototype RapidPrototype Workflow Engineer Final Product

32. Advantages • Reduces risk of incorrectuserrequirements • Good where requirements are changing/uncommitted • Regular visible progress aids management • Supports early product marketing

33. Disadvantages I • An unstable/badlyimplementedprototypeoftenbecomes the final product. (Migration to a type 1 process!) • Requires extensive customer collaboration • Costs customers time/money • Needs committed customers • Difficult to finish if customer withdraws • May be too customer specific, no broad market

34. Disadvantages II 3.Difficult to know how long project will last 4. Easy to fall back into code-and-fix without proper requirements analysis, design, customer evaluation and feedback.

35. 1.9. Type 1:Agile Software Processes Need for an adaptive process model suited to changes in: • User requirements • Customer business models • Technology • In-house environment De-emphasise documentation, esp. URD! Emphasise change management e.g. reverse engineering design! Examples include XP, SCRUM, Agile modeling etc

36. 1.9.1. Agile Principles (C.f Sommerville Fig 17.3) • Incremental delivery of software • Continuous collaboration with customer • Embrace change • Value participants and their interaction • Simplicity in code,

37. 1.9.2. XP Release Cycle Select release stories Breakdown stories to tasks Plan release Release code Develop/ Integrate/ Test code Evaluate system For a sample story see Sommerville Figure 17.6 Same as use-case?

38. 1.9.3. XP Practices (Summary) • Incremental planning • Small releases • Simple design • Programming in pairs (egoless programming, see 7.) • Test-driven development • Software refactoring (needs UML?) • Collective ownership: metaphors, standards, code • Continuous integration • Sustainable pace (No overtime!) • On-site customer!

39. Advantages • Lightweightmethodssuitsmall-mediumsizeprojects • Producesgood team cohesion • Emphasises final product • Iterative • Test-basedapproach to requirements and qualityassurance

40. Disadvantages • Difficult to scale up to largeprojectswheredocumentation is essential • Needsexperience and skillif not to degenerateintocode-and-fix • Programming pairs is costly (butseeproductivityliterature) • Test caseconstruction is a difficult and specialisedskill.

41. 1.10. SCRUMSchwaber and Beedle 2002 (1986?) • Short iterations – “sprints” • “Potentially deliverable product increment” (working and tested) • Project kick-off meeting – brainstorm first version • Produces first product backlog – vision in terms of business requirements • Current understanding – not final contract

42. Product Backlog • High level document • Items grouped into releases with planned release dates • After each sprint, product owner has 3 options • Turn sprint result into product increment • Declare project finished and release • Shift items between releases or change release dates

43. “Monthly” cycle: Sprint • Starts with sprint planning meeting: select items from product backlog for sprint backlog (2 backlogs!) • Determine tasks and estimate effort of sprint backlog • Short, typically 2-4 weeks • At end of sprint: • Review progress • Define scope of next sprint • Add unfinished work to backlog

44. Project Roles (pigs!) • Product owner (aka client): responsible for requirements, creates and prioritises backlog • Scrum master: sets up and enforces project rules and practices. Manages daily meetings, progress, obstacles. Interface between team and product owner. • Scrum team: develops increments. Cross functional, no job roles!

45. Project Roles (chickens) • Stakeholders (customers, vendors) People who enable the project and for whom project will produce the benefits. • Managers People who set up environment for the product development organizations

46. Daily Cycle • Daily scrum meeting – (also a scrum of scrums) • 15 min timeboxed, same time and place • Individual status report (yesterday’s and today’s work) • Anyone attends, but only pigs speak • New obstacles • New action for the day Update burn down chart which plots cumulative remaining sprint effort as a function of time. Each backlog item has an effort estimate that must be updated, based on new information.

47. Scrum Team Scrum Master Product Owner Client :Problem Statement Kick off project :Product Backlog Plan Sprint :Sprint Backlog Daily Scrum Daily Cycle Monthly Cycle :Action Items :Obstacles Do Work Remove Obstacle :Product Increment Review Sprint Deliver Release :Product Release

48. (Dis) Advantages • Advantages • handles changing requirements • easy to learn and use • regular working deliverables • can be used for maintenance • open to risk management • Disadvantages • Hard to predict • what documentation besides user requirements? • unrealistic to expect all do everything • not suitable for large projects (daily scrum?) • Not actually IT specific

49. 1.11. RationalUnified Process (RUP) • Hybrid modelinspired by UML and Unified Software Development Process. • A genericcomponent-based process? • Three views on the process • Dynamicview: RUP phases • Staticview: RUP activities • Practiseview: RUP best-practise

50. Details • Lifetime of a software product in cycles: • Birth, childhood, adulthood, old-age, death. • Identify product maturity stages • Each project iteration cycle is a phase, culiminating in a new release (c.f. Spiral model)