SOFTWARE DEVELOPMENT LIFE CYCLE MODELS

1. SOFTWARE DEVELOPMENT LIFE CYCLE MODELS Chapter 2 from Object-oriented and classical software Engineering (7ed) by Stephen R. Schach

2. Outlines • Classic models • Agile models • Other models

3. Waterfall Model

4. Characterized by • Feedback loops • Documentation-driven • Advantage • Maintenance is easier • Disadvantage • Can not see the product until the end

5. Spiral Model Figure 2.11

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

7. Rapid Prototyping Model

8. Characterized by Rapid prototyping to determine what the client needs • Advantage • Deliver what the client really needs • No feedback loop needed • Requires • Rapid prototyping • Modify prototype easily

9. Iteration and Incrementation • Real software development process is iterative and incremental process • We make mistakes • Moving target • Miller’s Law

11. Iteration is performed during each incrementation

12. We can consider the project as a whole 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

13. Each iteration can be viewed as a waterfall life-cycle model • Requirements phase • Analysis phase • Design phase • Implementation phase

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

15. Code-and-Fix Model • No design • No specification • Maintenance nightmare

16. Agile Software Development Methodology To satisfy the customer through early and continuous delivery of valuable software Agile Software Development Methods - Review and Analysis

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

18. Comparisons

19. Extreme Programming The term “extreme” comes from taking those commonsense principles and practices them to extreme levels Extreme Programming Explained – Embrace Change By Kent Beck

20. What is Extreme Programming? XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing environment.

21. Values of Extreme Programming • Communication • Simplicity • Feedback • Courage

22. Communication • Most problems in development are caused by communication problems • XP aims to keep the right communications flowing by employing many practices that can’t be done without communicating: • unit testing • pair programming • task estimations • XP employs a coach whose job It is to notice when people aren’t communicating and reintroduce them.

23. Simplicity • Simplicity is not easy. • It is the hardest thing in the world not to look toward the things you’ll need to implement tomorrow and next week and next month. • XP is making a bet. • It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do more complicated thing today that never be used anyway.

24. Feedback • Feedback works at the scale of minutes and days. • Feedback works at the scale of weeks and months.

25. Courage • When there is an architectural flaw and there is no way forward, fix the flaw. • Throwing code away if you know it is not the most promising solution.

26. XP Life Cycle

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

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

29. Roots of XP Practices

30. Planning game Small/short releases Metaphor Simple design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards Open workspace Just rules Practices

31. Planning game Close interaction between the customer and the programmers. The programmers estimate the effort needed for the implementation of customer stories and the customer then decides about the scope and timing of releases. Small/short releases A simple system is “productionized” rapidly – at least once in every 2 to 3 months. New versions are then released if not daily, but at least monthly. Metaphor The system is defined by a metaphor/set of metaphors between the customer and the programmers. This “shared story”guides all development by describing how the system works. Simple design The emphasis is on designing the simplest possible solution that is implementable at the moment. Unnecessary complexity and extra code are removed immediately.

32. Testing Software development is test driven. Unit tests are implemented before the code and are run continuously. Customers write the functional tests. Refactoring Restructuring the system by removing duplication, improving communication, simplifying and adding flexibility. Pair programming Two people write the code at one computer. Collective ownership Anyone can change any part of the code at any time. Continuous integration A new piece of code is integrated into the code-base as soon as it is ready. Thus, the system is integrated and built many times a day. All tests are run and they have to be passed for the changes in the code to be accepted.

33. 40-hour week A maximum of 40-hour working week. No two overtime weeks in a row are allowed. If this happens, it is treated as a problem to be solved. On-site customer Customer has to be present and available full-time for the team. Coding standards Coding rules exist and are followed by the programmers. Communications through the code should be emphasized. Open workspace A large room with small cubicles is preferred. Pair programmers should be placed in the center of the space. Just rules Team has its own rules that are followed, but can also be changed at any time. The changes have to be agreed upon and their impact has to be assessed.

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 1999a)