SENG 609.24 Agile Software Processes

1. SENG 609.24Agile Software Processes Feature-driven development The Unified Process Agile Modeling Kobe Davis, Lance Titchkosky, and Paul Werbicki SENG 609.24 - Agile Software Processes

2. Presentation Agenda • Feature-Driven Development • (FDD exercise) • The Unified Software Process • Comparison of FDD to XP • Comparison of UP to XP • Agile Modeling • Agile modeling and UP SENG 609.24 - Agile Software Processes

3. Feature-Driven Development (FDD) Agenda • Introduction to the authors • The problem: accommodating shorter business cycles • The solution: Feature-driven development • Defining features using FDD • The five FDD processes • Roles within FDD • Metrics and progress tracking with FDD SENG 609.24 - Agile Software Processes

4. Introduction to FDD • Presented in Java Modeling in Colour With UML • Developed by Peter Coad, Eric Lefebvre, and Jeff De Luca • “A process for delivering frequent, tangible working results, on time and on budget” • Other FDD articles available at http://www.nebulon.com/articles/ Chapter available for download online at: http://www.togethersoft.com/services/tutorials/jmcu/index.html SENG 609.24 - Agile Software Processes

5. The problem: accommodating shorter business cycles Large software projects tend to: • Exceed budget • Miss schedules • Deliver short of providing business value Why is this happening? • Business changes rapidly • Technology advances often within a single large build cycle SENG 609.24 - Agile Software Processes

6. The solution: Feature-Driven Development • How about delivering frequent, tangible, working results? • Deliver results that are “useful in the eyes of the client” • Use a feature as the smallest divisible task • Attack very small block of client-valued functionality • Group blocks into business-related sets • Focus on delivering results every two weeks • Track and report progress by feature progress SENG 609.24 - Agile Software Processes

7. Defining features using FDD • A feature is a client-valued function that can be implemented in two weeks • Start with an informal list gathered from: • Conversations with domain members • Current documentation • Build a detailed list after developing the overall model SENG 609.24 - Agile Software Processes

8. Defining features using FDD (cont.) Building an informal feature list helps to: • Bring domain members together to talk • Increase developer’s understanding of the domain • Fosters creativity and innovation • Encourages exploring several questions: • What could be done? • What might be done? • What could make a real difference? • Leads to the discovery of features that add significant business value SENG 609.24 - Agile Software Processes

9. Defining features using FDD (cont.) Feature sets and features use definition templates: • Feature: <action> the <result> <by|for|of|to> a(n) <object> • Feature set: <action> <-ing> a(n) <object> • Major feature set: <object> management SENG 609.24 - Agile Software Processes

10. Defining features using FDD (cont.) Example: • Major feature set: Product-sale management • Feature set: Making a product sale to a customer • Features • Calculate the total of a sale • Assess the fulfillment timeliness for a sale • Calculate the total purchases by a customer • Calculate the tax for a sale • Assess the current preferences of a customer SENG 609.24 - Agile Software Processes

11. Defining features using FDD (cont.) Exercise (10 minutes): • Separate into your project groups • Take your XP user stories and come up with as many features/feature sets/major feature sets as you can • We will then share some of these with the class • Feature: <action> the <result> <by|for|of|to> a(n) <object> • Feature set: <action> <-ing> a(n) <object> • Major feature set: <object> management SENG 609.24 - Agile Software Processes

12. Roles within FDD • Chief Programmer • Class Owner • Features Teams SENG 609.24 - Agile Software Processes

13. Roles within FDD (cont.) Chief Programmer • FDD requires someone to lead the DBF/BBF processes • Should lead by example and mentor others • Should be significantly more productive than other team members • Adding programmers usually slows projects down, but adding an in-parallel chief programmer can accelerate a project SENG 609.24 - Agile Software Processes

14. Roles within FDD (cont.) Class Owner • Responsible for design and implementation of a class • Developers gain a sense of “pride of ownership” • Provides local consistency to a class • The norm is one class to one class owner SENG 609.24 - Agile Software Processes

15. Roles within FDD (cont.) Feature team • Features are assigned to a chief programmer • The CP identifies class owners • Together the CP and class owners form a temporary feature team • Interactions are primarily between the CP and the class owners • This ensures on-going mentoring and promotes uniformity of design and implementation SENG 609.24 - Agile Software Processes

16. The five FDD processes Pg. 190, Java Modeling in Color with UML • Develop an overall model • Build a detailed, prioritized features list • Plan by feature • Design by feature • Build by feature SENG 609.24 - Agile Software Processes

17. The five FDD processes (cont.) Why use a process? • Lightweight process can help a team deliver results • With larger projects, repeatable success is achievable • New staff require shorter ramp-up time • Focus on high-payoff results What to avoid in a process • Process for process’ sake or “process pride” • Process over-specification SENG 609.24 - Agile Software Processes

18. The five FDD processes (cont.) Develop an overall model • Domain members and developers work together with chief architect • Domain members present a high-level walkthrough • Everyone works to develop a skeletal model • Small pieces are presented by domain members in more details • Sub-teams create a more detailed model which is merged into the skeletal model producing an overall model SENG 609.24 - Agile Software Processes

19. The five FDD processes (cont.) Build a detailed, prioritized features list • The development team identifies features • Features are grouped hierarchically • A priority is assigned to each feature • Each feature is weighted by importance • Smaller teams can tackle specialized feature areas • Domain member participation is welcome but not required SENG 609.24 - Agile Software Processes

20. The five FDD processes (cont.) Play by feature • Using the features list project manager, development manager, and chief programmers establish milestones • These milestones mark each design by feature and build by feature iterations SENG 609.24 - Agile Software Processes

21. The five FDD processes (cont.) Design by feature • Chief programmer takes a feature iteration back to his group, now a feature team • S/he identifies classes and assigns class owners • The feature team works out a detailed sequence diagram • Class owners prototype classes • Team conducts a design inspection SENG 609.24 - Agile Software Processes

22. The five FDD processes (cont.) Build by feature • Using the design by feature artifacts, each class owner implements their class methods • Class owner implements class-level testing • Feature team inspects the code • After classes pass inspection the code is check into the version control system • When all classes are checked in the chief programmer promotes the code to the build process SENG 609.24 - Agile Software Processes

23. Metrics and progress tracking with FDD How much time is spent in each process? SENG 609.24 - Agile Software Processes

24. Metrics and progress tracking with FDD (cont.) Pg. 198, Java Modeling in Color with UML SENG 609.24 - Agile Software Processes

25. Metrics and progress tracking with FDD (cont.) Reporting • Release manager meets weekly with chief programmers • Reports are generated weekly for the teams, clients and senior management • Primary metric is percentage complete • Reports for each feature set and major feature set are compiled graphically SENG 609.24 - Agile Software Processes

26. Metrics and progress tracking with FDD (cont.) Pg. 201, Java Modeling in Color with UML SENG 609.24 - Agile Software Processes

27. Metrics and progress tracking with FDD (cont.) http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html SENG 609.24 - Agile Software Processes

28. FDD Case Study (or lack thereof) Attempted to contact the FDD authors Peter Coad pc@oi.com • Mail server problems Eric Lefebvre lefee@groupe-progestic.com • Email address unknown Jeff DeLuca jdl@nebulon.com • No response SENG 609.24 - Agile Software Processes

29. FDD Case Study (a response finally!) Stephen Palmer steve.palmer@togethersoft.com • Editor of the Coad Letter http://www.togethercommunity.com/coad-letter/index.shtml • Author of “Practical Guide to Feature-Driven Development” • “I am not aware of any formal case studies that have been performed” • “FDD itself is a blend of proven techniques” • “FDD blends these proven ingredients into a cohesive and intuitive whole” SENG 609.24 - Agile Software Processes

30. FDD Case Study (cont.) • Too new of a method or process • Companies tailor FDD to their specific needs • Object Modeling is well established • All modern processes use some sort of list of functional requirements to plan, track and report the project's progress • Design and code inspections processes have a large number of case studies supporting them • FDD works because of the “sum of its parts” SENG 609.24 - Agile Software Processes

31. Conclusion Amazing yet true! • Developers and clients and managers like FDD • Process for helping teams produce frequent tangible results • Very small blocks of client valued functionality, called features • Focuses on developers producing results every two weeks • Allows precise tracking of progress SENG 609.24 - Agile Software Processes

32. The Unified Process Agenda • History • Overview • 4 P’s • Use-Case Driven • Architecture Centric • Iterative and Incremental • Conclusion SENG 609.24 - Agile Software Processes

33. History • Developed over three decades • Ericsson Approach, 1967 • Objectory AB established by Ivar Jacobson, 1987 • Developed the Objectory process, which extends Ericsson approach • Rational Software Corporation acquires Objectory AB, 1995 • Rational Objectory process is created SENG 609.24 - Agile Software Processes

34. History (cont.) • UML standardized in 1997, supported by OMG • Rational Objectory Process defines all models using UML • Through acquisitions, mergers and internal development the Rational Objectory Process is extended to cover all aspects of the software development life cycle, the new process is called the Rational Unified Process SENG 609.24 - Agile Software Processes

35. History (cont.) • The Unified Process was released to the general public in the form of the book ‘The Unified Software Development Process. (Jacobson, Booch, Rumbaugh)’, 1999 SENG 609.24 - Agile Software Processes

36. Overview • The Unified Software Development Process is a software development process that is ‘use-case driven, architecture-centric and iterative and incremental’. (Jacobson, Booch, Rumbaugh) • The Unified Process is component based • The Unified Process uses the Unified Modelling Language for documentation and design SENG 609.24 - Agile Software Processes

37. 4 P’s • The Unified Process recognized four aspects of software development as being equally important • People • Project • Product • Process • (Tools) Figure 2.1 The Unified Software Development Process SENG 609.24 - Agile Software Processes

38. 4 P’s (cont.) • People are crucial • Projects make the product • Product is not just the code • Process directs Projects • Tools are integral to the process SENG 609.24 - Agile Software Processes

39. Use Case Driven • What is a Use Case? • A use case specifies a sequence of actions, including variants, that the system can perform and that yields an observable result of value to a particular actor SENG 609.24 - Agile Software Processes

40. Use Case Driven (cont.) • Why use Cases? • Systematic and intuitive means of capturing functional requirements • Supports identifying software to meet user goals • Evaluate what system should do for each user • Provides complete specification for all possible uses of the system SENG 609.24 - Agile Software Processes

41. Use Case Driven (cont.) • How do Use Cases drive the process? • Use Cases are used for Requirements Capture • Use Cases also provide input for… • Finding and specifying classes, subsystems, and interfaces • Finding and specifying test cases • Planning development iterations and systems integration SENG 609.24 - Agile Software Processes

42. Example Use Case Model http://www.zoo.co.uk/~z0001039/PracGuides/index.htm SENG 609.24 - Agile Software Processes

43. Use Case Model (exercise) • Create a Use Case Model for your 609.24 project • Gives us a picture/model of the overall project (not just assorted white cards) • Allows us to pick the most important use cases for implementation SENG 609.24 - Agile Software Processes

44. Models • Analysis Model • Set of use cases for each iteration • Design Model • Design model adapted to environment • Implementation Model • Everything to produce executable system • Testing Use Cases • Verify system correctly implements specification SENG 609.24 - Agile Software Processes

45. Architecture Centric • What is Architecture? • Organization of a software system • Structural elements and interfaces that will comprise a system together with their behavior • Composition of the structural and behavioral elements into progressively larger systems • Architectural style that guides the organization SENG 609.24 - Agile Software Processes

46. Architecture Centric (cont.) • Why do we need an Architecture? • Understand the system • Organize development • Foster reuse • Evolve the system SENG 609.24 - Agile Software Processes

47. Architecture Baseline • An architecture is developed iteratively during the elaboration phase through requirements, analysis, design, implementation and test • The architecturally significant use cases and a range of other input is used to implement the architectural baseline or skeleton system. • Architecture Description SENG 609.24 - Agile Software Processes

48. Iterative and Incremental • What is iterative and incremental? • The Unified Process moves through a series of clearly defined milestones • Milestones provide the managers and development team with the criteria they need to authorize movement from one phase into the next phase of the life cycle • For each phase the process moves through a series of iterations SENG 609.24 - Agile Software Processes

49. Iterative and Incremental (cont.) • Why Iterative and Incremental? • Identify critical and significant risks early • Create an architecture to guide development • Allow for requirements and other changes • Build system over time rather than all at once at the end of the process when changes are expensive • Provide a process which is more effective SENG 609.24 - Agile Software Processes

50. Iterative and Incremental (cont.) • Phases • Inception • Elaboration • Construction • Transition SENG 609.24 - Agile Software Processes