1. Copyright © 2015 Curt Hill Software Development Paradigms What do you need to know?

2. Introduction Most of this should be a review from previous courses We will consider briefly the following: –Waterfall model –eXtreme Programming (XP) –Scrum You should know something already on all of these topics Copyright © 2015 Curt Hill

3. Waterfall Model This is a classic engineering model Predates software engineering in its use by other engineering disciplines Copyright © 2015 Curt Hill

4. Waterfall Model Copyright © 2015 Curt Hill Requirements Design Unit Implementation Operation & Maintenance System Integration

5. Waterfall Problems Works better for very large projects –Must have solid managerial support Many such projects are canceled before rolling out the product The volatility of requirements Technical debt accumulates and is not visible until late in the project Copyright © 2015 Curt Hill

6. Technical Debt Unfinished work that is required by a design –Most often seen in projects that are released early Like financial debt this accrues interest making changes more difficult later –Prevents or makes more difficult enhancements Copyright © 2015 Curt Hill

7. Waterfall Debt We do not see the problems early enough –Requirements were insufficient –Design was poor –Early code was not good These problems come home to roost at the end of the project –This is when it is most difficult to change About 18% of real world projects are using Waterfall Copyright © 2015 Curt Hill

8. Alternatives Agile, iterative, evolutionary are now much more common The idea is quickly develop small code bases that deal with just the basics Add one feature at a time We prepare for failure by being ready to junk the whole mess if it does not satisfy the users All stakeholders review Copyright © 2015 Curt Hill

9. eXtreme Programming (XP) One of the first agile methodologies Goals to produce high quality software and increase programmer productivity XP has a set of: –Activities –Values –Rules –Principles Copyright © 2015 Curt Hill

10. XP Activities Coding – duh! Testing –Unit tests –Acceptance tests Listening –To the business experts and each other Designing –Overall structure of the system Copyright © 2015 Curt Hill

11. XP Values 1 Communication –Between the business experts and every member of the XP team Simplicity –Find the simplest solution – it can be made more complicated later Feedback –System: unit and integration tests –Customers: acceptance tests –Team: to the customers on requirements Copyright © 2015 Curt Hill

12. XP Values 2 Courage –Design for today, not tomorrow –Be fearless in refactoring, not allowing a poor design to hold things back Respect –For self: believe that you can produce high quality code –For others: do nothing that will cause impediments for rest of team Copyright © 2015 Curt Hill

13. XP Rules Frequent small releases Code unit tests before the unit Pair programming Only one pair integrates code at a time No release unless code passes all unit tests Finding a bug tests are improved Collective code ownership Copyright © 2015 Curt Hill

14. XP Principles Feedback –Frequently and promptly to keep project on track Simplicity –Often we are asked to consider the future –XP rejects, as the future is unpredictable Change –Is inevitable –Accept and move on from there Copyright © 2015 Curt Hill

15. Scrum An agile development process A process framework to manage software development It defines scrum teams with: –Roles –Events –Artifacts –rules Its approach is not incompatible with XP What is scrum named after? Copyright © 2015 Curt Hill

16. Scrum Team Three distinct roles: –Product Owner –Development Team –Scrum Master Teams are self-organizing Should have all the skills needed to accomplish their goal Products are produced incrementally Each increment should produce a workable product Copyright © 2015 Curt Hill

17. Terminology Product Backlog –Prioritized list of the features needed in the product Sprint –A time period that sees the production of a new or improved workable product –This is intending to implement a Sprint Goal –Typically less than a month Sprint Backlog –Those features intended to be implemented in this sprint Copyright © 2015 Curt Hill

18. Product Owner Creates and manages the Product Backlog –The only one to do so Sole interface with the business –Should be a business expert, not necessarily a development expert Makes sure the Development team understands the items in the backlog Copyright © 2015 Curt Hill

19. Development Team Do the work of development Organize and manage their own work –Self organizing Cross functional –All the skills necessary must be present in the team No: –Sub-teams –Titles –No ranking in importance Copyright © 2015 Curt Hill

20. Scrum Master Interface between the team and nearly everyone else Insulates the team from outside pressures Assists the Product Owner in managing the Backlog and facilitating events Assists the team in a coaching fashion Not a project manager Copyright © 2015 Curt Hill

21. Events The sprint Sprint Planning –A meeting that determines what can be delivered and this will be done Daily Scrum –A short meeting to synchronize activities Sprint Review –Final meeting in the Sprint to determine what has and has not been done Copyright © 2015 Curt Hill

22. XP and Scrum Scrum is an agile management methodology, while XP is an agile engineering methodology Duration of increments –XP 1-2 weeks, Scrum 2-4 Work goals –XP in customer defined order, Scrum has some choice Goal changes are disallowed in Scrum but possible in XP Copyright © 2015 Curt Hill

23. Finally System development methodologies vary substantially Traditional methodologies do well with good specifications and solid organizational support Agile methodologies can do well where these are absent –Many software development projects are knowledge acquisition projects which tends to favor the agile approach Copyright © 2015 Curt Hill