Project Methodologies

1. Project Methodologies AD643From a lecture by QutaibahMalluhi, Qatar University

2. Agenda • Waterfall Lifecycle Model • RUP Lifecycle Model • Agile Software Development Methodologies • Extreme Programming

3. Waterfall Model • Activity-centered view of the software lifecycle • Define detailed upfront requirements • Come up with the design that will support the required behavior. • Implement the required system. • Integrate and test the components. • Activities are performed in sequence • Described in 1970 by Royce.

4. Concept Exploration Process System Allocation Process Requirements Process Design Process Implementation Process Verification & Validation Process Installation Process Operation & Support Process Waterfall Model Illustrated

5. About Waterfall Lifecycle • Managers love waterfall models: • Nice milestones • No need to look back (linear system), one activity at a time • Easy to check progress : 90% coded, 20% tested • Developers hate the waterfall model • Requirements are a moving target • They have to come up with estimates based on no data.

6. Problems with the Waterfall (I) • Complete up-front specifications with sign-off • Research showed that 45% of features created from early specifications were never used—with an additional 19% rarely used [Johnson02]. • Over-engineering, a study of 400 projects spanning 15 years showed that less than 5% of the code was actually useful or used [CLW01].

7. Problems with the Waterfall (II) • Late Integration and Test • The waterfall pushes this high-risk and difficult issues toward the end of the project. Waterfall is called fail-late lifecycle. • Reliable Up-front Estimates and Schedules • Can not be done when the full requirements and risks are not reliably known at the start, and high rates of change are the norm. • “Plan the work, work the plan” values • Limited value for high change, novel, innovative domains such as software development.

8. Iterative and Incremental Lifecycle Models • 1960’s: ad-hoc code-and-fix • 1970’s: Waterfall was thought to be the ideal approach to software development • In practice, waterfall is only applicable to the most straightforward projects. • 1980’s: Iterative and incremental lifecycle models • The lifecycle is composed of a sequence of iterations. • Each iteration is a mini-project composed of activities such as requirements analysis, design, programming and testing. • An iteration ends with an iteration release, a stable, integrated and tested partially complete system. • 1990’s: Rational Unified Process • Popular example of Iterative and incremental lifecycle • A product and a process based on object orientation and UML

9. RUP: Rational Unified Process • Derived from the work on the UML at Rational • Booch, Jacobson, and Rumbaugh (1999) • 4 Phases: • Inception • Elaboration • Construction • Transition • Several Iterations in each phase • For each iteration, several parallel activities (workflows)

10. Over time… (this Figure is from www.rational.com)

11. RUP Dimensions • First Dimension: A dynamic perspective that shows phases and iterations over time • Second Dimension: static perspective that shows process activities (workflows)

12. RUP Dynamic Perspective Phases can be enacted incrementally Each phase is enacted In an iterative way

13. RUP Phases • Inception • Establish the business case for the system • Identify actors and initial use cases • Initial planning, estimation and schedule • Elaboration • Understand problem domain • Requirements model (use case model) • Overall system architecture • Construction • System design, object design, programming and testing • Develop a working software system ready to deliver to users • Transition • Deploy the system in its operating environment.

14. Static workflows

15. RUP Illustrated Time Workflows

16. RUP Good Practice • Develop software iteratively • Plan increments based on customer priorities • Manage requirements • Explicitly document requirements and track requirement changes • Analyze impact of changes before accepting them • Use component-based architectures • Visually model software (UML) • Control changes to software • Manage changes to software using a change management system and configuration management procedures and tools

17. What is a Software Development Methodology? • Collection of techniques and tools that provide guidance, general principles, and strategies for developing and managing a software system unified by a philosophical approach • Examples of methodology issues • How much planning should be done in advance? • How much of the design should result from reusing past solutions? • How much of the system should be modeled before it is coded? • In how much detail should the software development process be defined? • How often should the work be controlled and monitored? • When should the project goals be redefined?

18. Agile Methods • In the 1980s and early 1990s there was a widespread view that the best way to achieve better software was through • careful project planning • formalised quality assurance • the use of analysis and deign methods supported by CASE tools • controlled and rigorous software development

19. Agile Methods (Cont.) • This view came from software engineers who were developing large, long-lived software systems • Teams in different companies and geographically distributed • When heavy weight, plan-based development approaches were applied to small and medium size systems • The overhead sometimes dominated the software development process • Consider the cost of changing requirements

20. Agile Methods (Cont.) • More time was spent on how the system should be developed than on program development and testing • In the 1990s new agile methods were formulated which • relied on an iterative & incremental approach • allowed for changing requirements • Rapid software delivery to customers

21. General Principles of Agile Methodologies • Customer close involvement • Incremental delivery • A focus on people, not the process • Team members develop their own ways of working • Embrace requirements and change • Maintain simplicity

22. Examples of Agile Methodologies • Extreme programming (covered here) • Crystal • Adaptive Software Development • Scrum • DSDM Best suited for small and medium sized systems

23. Light-weight Methodologies • Heavy-weight methodologies: (based on waterfall or RUP) • Up-front analysis & design documentation • Strict phases • Large teams, long iteration cycles, long release times • Feature intensive • Light-weight (Agile) methodologies: (E.g., XP) • No up-front analysis & design documentation • Test-first coding • Small teams, short iteration cycles, short release times • Change intensive

24. Software Development Processes Iterative Waterfall Extreme Programming (XP) Analysis Design Code Design

25. XP Highlights • Probably the best known and most widely used agile method • Founded on four values: communication, simplicity, feedback, and courage (courage in changing requirements and code). • Programmers work in pairs • Develop tests for each task before writing code • New versions of the software may be created several times a day • Increments are delivered to customers roughly every two weeks

26. XP Highlights (Cont.) • All scenarios and requirements are represented as user stories • Customer is involved in specifying and prioritising requirements • The customer is part of the development team • The software is continually refactored

27. User Stories • Written by customer • Used instead of large requirements documents • Similar to scenarios but not limited to features visible to the outside world. • Used for release planning • Used for the creation of acceptance test • Typically much less detailed than scenarios and use cases • Typically takes 1-3 weeks to implement

28. Select user stories for this release Breakdown stories into tasks Plan release Evaluate System Release software Develop/integrate/ test software XP Release Cycle

29. 12 XP Practices • Pair-programming • On-site Customer • Test-first • Iterative Development • Refactoring • Simple Design • Planning Game • Coding Standards • Continuous Integration • Metaphor • 40-Hour Rule • Collective Code Ownership

30. Pair Programming • All code to be included in a production release is created by two people working together at a single computer. • One person types and codes, the other one observes and constantly monitors the code. • The observer is doing real-time code review, and perhaps thinking more strategically than the person typing. • Pairs dynamically swap rolls • Active communication, sharing expertise

31. On-Site Customer • Programmers and customers work together in the same team (same room). • Immediate check, feedback, and clarification by customer through face-to-face communication. • Customer performs acceptance test of features as they are completed. • Customer satisfaction: early and frequent delivery of software features.

32. Test-First Development • Develop automated tests before implementation • Test-then-code instead of code-then-test • Test-driven coding: constant validation and verification • Constant testing: unit, integration, acceptance (by onsite customer) • Automated testing (JUnit framework) • Open source framework for implementing unit tests in Java • Comes with Eclipse

33. Iterative Development • Customers choose the story cards for next iteration (next features to be implemented) depending on their business priorities. • Short iterations, release frequency, customer prioritized short cycles • Iteration plan, release plan from planning games • Small complete and continuous releases • Frequent delivery of working software progressively acquiring new features

34. Refactoring • Improves code quality • Extreme re-factoring for continued improvement of design • Constantly simplifies code • Changing existing program to make adding new features simple • Re-factoring after adding a new feature to clean up and organize the effect of the change • Re-factor as often as needed

35. Simple Design • Design fornow, not for the future • Extreme simplicity in design: avoid shortcuts, smart hard-to-understand code • No duplicate logic (no parallel class hierarchies) • Fewest possible classes and methods • Only features in the current iteration • Good design (re-factored) and technical excellence

36. Planning Game (I) • The goal is to choose the stories for next iteration (1-3 weeks) • discovering what the customer wants and estimating how long this will take to do. • Outline: Customers divide up the work to be done into a set of stories, each of which can be written on a 3 by 5 card (CRC cards) in a few sentences. The developers then estimate how much effort is required to build each story. The customer then chooses which stories she wants built in the next cycle, based on the time available and the estimates from the developers.

37. Planning Game (II) • By customer • Desirable features (business-wise) for next iteration • Order (priority of one feature over another) • Release planning by business: features, dates • By Developer • Possible technical features • Estimating development time for iteration tasks • Development-process planning and organization of work and development team members • Consequences of business decision communicated to customer • Face-to-face communication in planning game

38. Continuous Integration • Integration and integration testing of tasks frequently (every few hours, at least once a day) • Integration on a machine dedicated for integration • Integration testing before completing current integration session • Continuous code review: integration testing and code review of completed code

39. Metaphor • Use of best practices: design patterns, naming, defining • Easy to use system of names: consistent naming of classes and methods

40. 40-Hour Rule • Best individual effort without overwork and undue pressure • Uniform individual velocity: sustainable development pace • Fresh and eager team when starting in the morning • Satisfied and not tired when finishing the day in the evening • 40 hr may vary (35 - 45) • Discourage overtime. No two successive days of over-time. • Vacation and weekend work discouraged for best developer contribution • Highly motivated and fully fit developing members

41. Collective Code Ownership • Any pair programmers may re-factor any part of the code • Faster development by eliminating the bottleneck associated with change requests in an individual code ownership model • Pair programming, adherence to the code standard, and continuous integration lower the danger of this free model of modifying the code. • No individual (or pair) responsibility or blameafter integration

42. XP Achieves • Timing: Delivery On Time • Releasing: Frequent Releases (with Business Prioritized Features) • Quality: Simple Code--easy to test and modify • Reliability: Constantly Tested, Pair-programmed & Integrated Features • Flexibility: Rapid Response to Feedback, Change, Re-scheduling • Low Initial Cost: Flattened Change Cost Curve, No Future-safe Cost • Communication: Face-to-face, On-site Customer, Pair-programming • Team-work: Constant Team Integration, Team Spirit & Esteem • Iterating: Micro-iterations, Small Analyze/Test/Design/Code Episodes • People-Centered: Stand-up Meetings, Planning Games, Individual Velocities