SOFTWARE DEVELOPMENT LIFE CYCLE MODELS 3 16 2018 1

SOFTWARE DEVELOPMENT LIFE CYCLE MODELS 3/16/2018 1

Outlines • Classic software process models • Modern software process models 3/16/2018 2

3/16/2018 3

3/16/2018 4

3/16/2018 5

3/16/2018 6

Implementation 3/16/2018 7

3/16/2018 8

3/16/2018 9

3/16/2018 10

3/16/2018 11

Process: putting pieces together 3/16/2018 12

Classic: Waterfall Model 3/16/2018 13

• Characterized by – Feedback loops – Documentation-driven • Advantage – Maintenance is easier • Disadvantage – Can not see the product until the end 3/16/2018 14

Classic: Rapid Prototyping Model 3/16/2018 15

• Characterized by Rapid prototyping to determine what the client needs • Advantage – Deliver what the client really wants – No feedback loop needed • Requires – Rapid prototyping – Modify prototype easily 3/16/2018 16

Classic: Spiral Model Click here to see flash movie 3/16/2018 17

• Precede each phase by – Alternatives – Risk analysis • Follow each phase by – Evaluation – Planning of the next phase • Strengths – Identify and manage risks • Weaknesses – For large-scale software only – For internal (in-house) software only 3/16/2018 18

Modern: Iteration and Incrementation • Real software development process is iterative and incremental process – We make mistakes – Moving target – Miller’s Law 3/16/2018 19

3/16/2018 20

• During each increment, several iterations are performed 3/16/2018 21

• A project as a whole is considered as a set of mini projects (increments) • During each mini project we – Extend the artifacts (increment); – Check the artifacts (test) – If necessary, change the relevant artifacts (iteration) • The final set of artifacts is the complete product 3/16/2018 22

• Each iteration can be viewed as a waterfall life-cycle model – Requirements phase – Analysis phase – Design phase – Implementation phase 3/16/2018 23

Strengths of Iterative-and. Incremental Model • There are multiple opportunities for checking that the software product is correct • We can mitigate (resolve) risks early • We have a working version of the software product from the start 3/16/2018 24

Forever: Code-and-Fix Model • No design • No specification – Maintenance nightmare 3/16/2018 25

Comparisons Model Strength Weakness Code-and-fix Fine for short program that require no maintenance Totally unsatisfactory for nontrivial program Waterfall Disciplined approach, documentation driven Delivered product may not meet client’s needs Iterative-andincremental Multiple chances to check for errors Always have a working version Mitigate risks early Spiral model Risk driven 3/16/2018 Only for large in-house project Competent in risk management 26

Agile Software Development Methodology To satisfy the customer through early and continuous delivery of valuable software 3/16/2018 27

Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 3/16/2018 28

Agile Methods • Agile methods: – Extreme Programming – Scrum – Adaptive Software Development (ASD) – Dynamic System Development Method (DSDM) • Agile Alliance (www. agilealliance. org) – A non-profit organization promotes agile development 3/16/2018 29

Extreme Programming The term “extreme” comes from taking those commonsense principles and practices them to extreme levels XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing environment. 3/16/2018 30

Values of Extreme Programming • • 3/16/2018 Communication Simplicity Feedback Courage 31

XP Life Cycle 3/16/2018 32

Role and Responsibilities • Programmer – Analyze, design, test, program and integrate. • Customer – define stories to be implemented, – the order stories implemented – define functional test cases • Tester – – Help customers write functional test cases Run functional tests regularly Broadcast test results Maintain testing tools 3/16/2018 33

• Tracker (your are the conscious of the team) – Trace the estimates made by team and give feedback on how accurate they are – Trace the progress and evaluate whether a goal is reachable given the resource and time constrains • Coach – Responsible for the process as a whole – Remain calm when everyone is panicking • Consultant – External member possessing the specific technical knowledge needed • Manager (big boss) – Makes the decisions 3/16/2018 34

Scope of Use • Aimed for small and medium sized teams (3 to 20 people) • The physical environment and the business culture affecting the development unit • If you want to try XP, for goodness sake don’t try to swallow it all at once. Pick the worst problem in your current process and try to solving it the XP way. ”(Beck 1999 a) 3/16/2018 35

Scrum 3/16/2018 36

3/16/2018 37

• Roles – Product Owner – Scrum Master – Team • Artifacts – Product Backlog – Sprint Backlog 3/16/2018 38

– Product Owner • decides on and prioritizes functionality; • serves as single point of contact to answer team’s questions about functionality; • decides whether to release – Scrum Master • • guides team throughout the process helping resolve obstacles remove impediments run interference – Team (programmers, testers, UI designers, etc. ) • does the work; • produces something releasable by end of sprint 3/16/2018 39

– Product Backlog • all functionality and work that would like to have done for a product • fairly coarse-grained (all tasks not yet fleshed out), rough time estimates; – Sprint Backlog • work defined for turning product backlog for a single sprint into potentially deliverable product functionality; • more finely-grained tasks developed as start of sprint (4 -16 hours). 3/16/2018 40

A Scrum Sprint • Sprint Planning – Commit to certain functionality & estimate – Produces Sprint Backlog • Daily Scrum – 15 minutes @ start of day – What have you done since last Scrum? – What will do before next Scrum? – What obstacles? 3/16/2018 41

A Scrum Sprint • Sprint – Team does the work! • Sprint Review – Show off completed functionality • Sprint Retrospective – What went well during the Sprint? – What could be improved for the next? 3/16/2018 42

Approximate relative costs of the phases of the software life cycle [Schach 1999] 3/16/2018 43

3/16/2018 44

Key points to know • Classic – Waterfall – Spiral – Iterative and incremental – Code-fix • Agile – XP – Scrum • Processes suit projects and customers 3/16/2018 45

The Mythical Man-Month 3/16/2018 46

3/16/2018 47

Frederick P. Brooks, Jr. Kenan Professor of Computer Science Department of Computer Science University of North Carolina Chapel Hill, N. C. 27599 -3175 brooks@cs. unc. edu Phone: (919) 962 -1931 Fax: (919) 962 -1799 3/16/2018 48

A few facts about him: – Degree: • Ph. D from Harvard University (1956) – Award and medals: • ACM Turing award winner (1999) • John von Neumann Medal, IEEE (1993) • Too many to list here … – Industry experience: • IBM Corporation: – System/360: Manager of whole project, 1961 -64 3/16/2018 49

A few facts about the book: – Classic book on software project management – Published in 1975 and republished in 1995 • Tar pit • The mythical man-month • No silver bullet (added in 1995) 3/16/2018 50

– Some invaluable insights from the book • The Mythical Man-Month: Question: If you are a project manager and your project running behind schedule, what do you think about assigning more programmers to the project? Answer: Assigning more programmers to a project running behind schedule, could actually make it even later. 3/16/2018 51

3/16/2018 52

• Progress Tracking: Question: How does a large software project get to be one year late? Answer: One day at a time! Continued attention to meeting small individual milestones is required at each level of management. 3/16/2018 53

• Conceptual Integrity: In order to make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. 3/16/2018 54

• The Pilot System: When designing a new kind of system, a team will design a throw-away system (whether it likes it or not). 3/16/2018 55

• Communication: In order to avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible. 3/16/2018 56

• Software is invisible. ü Many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. ü This experience will yield insights, which will change a user's needs or the perception of the user's needs. ü The system will therefore need to be changed in order to fulfill the changed requirements of the user. 3/16/2018 57