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

Transcription

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. 1

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. 2

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. 3

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

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 5

6 Questions: 1. What are project parameters? 2. Are there good patterns of organisation that we could copy? 6

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. 7

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) 8

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. 9

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) 10

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

12 It provides a fixed generic framework that can be tailored to a specific project. Project specific parameters will include: Size, (person-years) Budget, Duration. project plan = process model + project parameters 12

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

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

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!) 15

16 We can sometimes combine process models e.g. 1. waterfall inside evolutionary onboard shuttle software 2. Evolutionary inside waterfall e.g. GUI prototyping 3. SCRUM inside waterfall We can also evolve the process model together with the product to account for product maturity, e.g. rapid prototyping waterfall 16

17 1.4. Waterfall Model The waterfall model is the classic process model it is widely known, understood and used. In some respect, waterfall is the common sense approach. R.W. Royce, Managing the Development of Large Software Systems: Concepts and Techniques, Proc. IEEE Westcon, IEEE Press,

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

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

20 Disadvantages 1. Doesn t reflect iterative nature of exploratory development. 2. Sometimes unrealistic to expect accurate requirements early in a project 3. Software is delivered late, delays discovery of serious errors. 4. No inherent risk management 5. Difficult and expensive to change decisions, swimming upstream. 6. Significant administrative overhead, costly for small teams and projects. 20

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!) 21

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

23 Disadvantages 1. Dangerous! 1. No visibility/control 2. No resource planning 3. No deadlines 4. Mistakes hard to detect/correct 2. Impossible for large projects, communication breakdown, chaos. 23

24 1.6. Evolutionary Development Types Type 1: Exploratory Development: customer assisted development that evolves a product from 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. 24

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 1. Consider alternative scenarios, constraints 2. Identify and resolve risks 3. Execute the phase 4. Plan next phase: e.g. user req, software req, architecture then goto 1 25

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. 26

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

28 Advantages 1. Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements 2. Flexible: incoporates the advantages of the waterfall and evolutionary methods 3. Comprehensive model decreases risk 4. Good project visibility. 28

29 Disadvantages 1. Needs technical expertise in risk analysis and risk management to work well. 2. Model is poorly understood by nontechnical management, hence not so widely used 3. Complicated model, needs competent professional management. High administrative overhead. 29

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 30

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

32 Advantages 1. Reduces risk of incorrect user requirements 2. Good where requirements are changing/ uncommitted 3. Regular visible progress aids management 4. Supports early product marketing 32

33 Disadvantages I 1. An unstable/badly implemented prototype often becomes the final product. (Migration to a type 1 process!) 2. 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 33

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. 34

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 35

36 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, 36

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

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

39 Advantages 1. Lightweight methods suit small-medium size projects 2. Produces good team cohesion 3. Emphasises final product 4. Iterative 5. Test-based approach to requirements and quality assurance 39

40 Disadvantages 1. Difficult to scale up to large projects where documentation is essential 2. Needs experience and skill if not to degenerate into code-and-fix 3. Programming pairs is costly (but see productivity literature) 4. Test case construction is a difficult and specialised skill. 40

41 1.10. SCRUM Schwaber 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 41

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 42

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 43

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! 44

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 45

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. 46

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

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 48

49 1.11. Rational Unified Process (RUP) Hybrid model inspired by UML and Unified Software Development Process. A generic component-based process? Three views on the process Dynamic view: RUP phases Static view: RUP activities Practise view: RUP best-practise 49

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) 50

51 Inception Elaboration Transition Construction UP process RUP phase workflow (drawn as a UML Statechart!) 51

52 RUP Phases Phases are goal directed and yield deliverables: Inception Establish the business case. Identify external entities (actors, systems). Estimate ROI. Elaboration Understand problem domain. Establish architecture, and consider design tradeoffs. Identify project risks. Estimate and schedule project. Decide on build vs. buy. Construction Design, program and test. Components are bought and integrated. Transition release a mature version and deploy in real world. 52

53 RUP Workflows RUP separates what and when into two orthogonal process views. When modeled by phases What modeled by workflows (c.f. Sommerville Figure 4.13) Any workflows can be active in any phases. Anything that instantiates the following diagram is an instance of RUP!! An agile instantiation exists (Larman 2002) 53

54 Project Management Unified Process: SoftwareProcess Product Environment Workflow * * Cycle releases Requirements Analysis/ Design 4 Phase Inception Elaboration Implementation * Construction Testing Iteration Transition Deployment Business Modeling * Artifact 54

55 RUP Practise View 1. Develop software iteratively 2. Manage requirements 3. Use component-based architectures 4. Visually model software 5. Verify software quality 6. Control software changes 55

56 Use Case Model UML class diagram! specified by Analysis Model realised by deployed by implemented by Design Model verified by Deployment Model Implementation Model Visual software model = UML Model-based Development Test Model 56

57 (Dis) Advantages Difficult to judge without knowing the actual chosen instantiation of the RUP Unique use of the UML philosophy of SE. Can be as good/better than any other process Also as bad/worse than 57

58 1.12. COTS COTS = Commercial Off-The-Shelf software Integrate a solution from existing commercial software components using minimal software plumbing All projects seek some software re-use Holy Grail of SE See also Sommerville Chapter

59 Possible Approaches 1. Third-party vendors: component libraries, Java beans, 2. Integration solutions: CORBA, MS COM+, Enterprise Java Beans, software frameworks 3. Good software engineering: application generators (Yacc, Lex Sommerville 18.3), generic programming (types, polymorphism etc) 4. Commercial finished packages: databases, spread sheets, word processors, web browsers, etc. 5. Design to open source interfaces: e.g. XML, ISO standards, etc. 59

60 Distributed COTS: Web Service Providers Integration of web-services: third party service providers using (XML-based?) service models: JINI extension of Java for service discovery SOAP (Simple Object Access Protocol) WSDL (Web Services Description Language) UDDI (Universal Description, Discovery and Integration) Cloud computing 60

61 Advantages 1. Fast, cheap solution 2. Explore solutions with existing products (c.f. your project work!) 3. May give all the basic functionality 4. Well defined integration project, easy to run. 5. Open to outsourcing (c.f. Point 4) 6. Build strategic supplier partnerships 61

62 Disadvantages 1. Limited functionality/ compromise/ requirements drift. 2. Component identification can be tricky mistakes occur! 3. Licensing problems: freeware, shareware, etc. 4. Customer lock-in: license fees, maintainance fees, upgrades 5. Compatibility issues/loss of control: 1. Between components (doesn t start!) 2. During maintenance (suddenly stops!) 62