3) Generating Initial Plans

1. 3) Generating Initial Plans

2. Outline • Software Lifecycle Models • Key Components of an Initial Plan • Defining and Tailoring the Software Process

3. The Overall Planning Cycle Manage Risks Analyze Job Generate Initial Plans Generate Detailed Plans Execute Measure, Manage Productivity and Quality

4. Software Lifecycle Models

5. Software Lifecycles • The software lifecycle is the top level view of the software process • The specific lifecycle chosen depends on the software to be built - its goals and requirements and its intended uses • Selection of the software lifecycle model(s) is a primary responsibility of a software manager

6. Waterfall Model of theSoftware Lifecycle Requirements Analysis Rqmts Specs Design Specs Design Unit Tested Code Code Tested Code Test Integrate

7. Waterfall Model of theSoftware Lifecycle Requirements Analysis Rqmts Specs Design Specs Design Unit Tested Code Code Tested Code Test Each phase ends with a review and/or signoff Integrate

8. Waterfall Model of theSoftware Lifecycle Each phase produces artifacts that are input to the next phase Requirements Analysis Rqmts Specs Design Specs Design Unit Tested Code Code Tested Code Test Integrate

9. Waterfall Assumptions Good Requirements • System or other requirements have been established (defined and validated); • Those requirements to be addressed by software are clearly defined • Requirements are allocated to all system components (software products or configuration items)

10. Waterfall Assumptions (continued) Good System Design • The system design is complete • Software has been fully identified • The software has been divided into individual “products” (configuration items) • Each product can be developed independently • Requirements are clearly allocated to each configuration item • Interfaces are clearly defined

11. An Important Conceptin the Waterfall Model • Different groups could be assigned to each phase without loss of quality, performance, or time • This concept is the reason behind some of the documentation and review / signoff requirements • May be very realistic on a big project • But it may be costly and unrealistic in many cases

12. The Organization or The Project May Not Fit This Model • Does each phase have a different organization? Or does one group do all steps of the process? • Can the requirements be established firmly before design begins? • Can the design be complete before coding begins?

13. Waterfall Model Benefits • Intuitive, logical, basic structure • Tells what, not how • Includes all of the basic parts • Adaptable to many situations by making simple changes or tailoring • Serves as a reference model • Other models are often explained by contrasting and comparing them with the waterfall model

14. Waterfall Model Drawbacks • Assumes that requirements are clearly understood • Assumes that phases occur sequentially • What about errors that require iteration? • Is it more efficient to overlap phases? • Assumes that the customer can understand the requirements specification and verify that it is correct • Prototyping and technical interchange may be necessary in practice

15. Spiral Model • Originated by Barry Boehm in the 1970’s Definition • Development proceeds as a series of successively more capable prototypes, each of which is designed to build on the previous results and to address the areas of highest risk

16. Spiral Model Plan Next Iteration; Get Commitment Determine What to Do Start Here Evaluate the Results Develop the Next Version of Product

17. Spiral Assumptions • Initial requirements are established but may change based on results of prototypes • (Same as waterfall) - good design, allocation • You know how to identify, analyze, and rank the risks associated with the project

18. Advantages of Spiral Model • Accommodates changes in requirements • Each iteration can accommodate new information about the requirements • Early iterations often provide important lessons that help you refine the requirements • Facilitates risk management • You can evaluate risky concepts early before making major commitments

19. The “Cycles of Learning” Benefit • You learn a lot during each iteration, which makes the next one more efficient • Studies show that by the third or fourth iteration (when you are doing the bulk of the actual work), the development team is functioning very effectively • And the total time may be less than one “big” iteration, as in the waterfall

20. Drawbacks of the Spiral Model • Admits lack of understanding (may be hard for management and customers to accept) • Harder to achieve good synchronization with other parts of the project • Makes it harder to track the progress • Harder to manage • Can be costly - lots of “throwaway” code - if not managed well

21. Spiral Model Advances • Today some organizations use the “win-win” spiral model • This model has more explicit steps for gaining stakeholder support for what is done at each turn of the spiral • More can be found at the Cocomo II web site (see later notes)

22. Rapid Application Development (RAD) • An extension/extrapolation of the spiral model • Evolved in the 1980’s and 1990’s among developers of software for the mass market and networks (e-commerce) • Need products quickly • Products often have short lifetimes • Requirements change very rapidly • The system/environment is fluid

23. Definition Rapid Application Development (RAD) • A collection of programming tools and methods that enables quick production of working software • Key elements of RAD include: • use of short, incremental development cycles • libraries of pre-compiled, commonly used components, such as user interface elements

24. Requirements Analysis Rqmts Specs Design Specs Design Unit Tested Code Code Tested Code Test Integrate RAD Rqmts Specs Design Specs Code Artifacts On-line And Dynamic Requirements Analysis Design Integrate Component Library Test Code

25. RAD Assumptions • Interface requirements are established early and kept relatively firm • Application requirements and system design are fluid • Risks of quality problems are mitigated by short product life cycles and opportunity to correct in next release

26. Advantages of RAD Model • Accommodates changes in requirements • Each iteration can accommodate new information about the requirements • Produces a usable product on each iteration • Deals effectively with the biggest risk in this specific type of software – failing to meet market windows!

27. The “Cycles of Learning” Benefit • Even more than with the spiral model, you learn a lot during each iteration, which makes the next one more efficient • Reuses proven components, so you don’t spend time reinventing

28. Drawbacks of the RAD Model • Hard for outsiders to understand where you are • Can be chaotic if not managed effectively • Comprehensive quality checks and testing are not normally part of the process • Many documents and artifacts are not produced or not permanent, so long term maintenance can suffer

29. Extreme Programming (XP) • A “lightweight” discipline of software development derived from object oriented programming and based on these principles: • Simplicity • Communication among developers • Feedback • Courage! • Originated with the “C3” project at Chrysler Corporation in 1997

30. Simple Definition of XP • A highly iterative form of RAD where the focus is on minimalism • Evolutionary design rather than planned design • 3-week cycles are typical, even for large projects • Don’t plan ahead because you will probably be wrong • Do only what must be done now - add functionality in later iterations

31. XP Assumptions • Small, co-located teams • Customers will change their minds • A perfect product cannot be produced, so get something out and then improve it • Close customer contact with programmers • This is an essential assumption because there are no formal requirements

32. Key XP Practices • Re-factoring - ongoing redesign to respond to change • Test first, then code • Don’t design or code anything until you know how you will test it • Pair programming - two people inspect each others’ work • Continuous integration - daily builds to solidify interfaces early

33. XP Drawbacks • Simplicity is not always easy to accomplish • It is easy to drop the discipline and descend into “hacking” • It doesn’t scale well to really large projects • The whole thing hinges on the developers understanding the problem well - no design specs to work from!

34. Key Components of an Initial Plan

35. Prototype Task Objective: Devise a prototype of the data base that utilizes the new object oriented data base engine Evaluation Criteria: Performance, response time, reliability, ... Prototype Task Objective: Devise a prototype of the data base that utilizes the new object oriented data base engine Evaluation Criteria: Performance, response time, reliability, ... Prototype Task Objective: Devise a prototype of the data base that utilizes the new object oriented data base engine Evaluation Criteria: Performance, response time, reliability, ... Prototype Task Objective: Devise a prototype of the data base that utilizes the new object oriented data base engine Evaluation Criteria: Performance, response time, reliability, ... Prototype Task Objective: Devise a prototype of the data base that utilizes the new object oriented data base engine Evaluation Criteria: Performance, response time, reliability, ... Key Components of an Initial PlanIntegrated Master Plan (IMP) A summary of the work to be done on the project: • All major project tasks • Significant accomplishments to be attained in order to complete each task • Exit criteria for each task

36. Software Role in Developing the Integrated Master Plan • Ideal project • Participate in developing this plan • Make sure the top level software tasks are represented properly • Document these for use in software planning. • Less-than-ideal project • May need to prod others to do their part in making this plan

37. Key Components of an Initial PlanIntegrated Master Schedule (IMS) An overall project schedule that shows how the parts fit together • Task duration and timing • Key events and milestones • Expected dates • Dependencies among tasks Such a schedule is typically very large

38. The Key is to Show How The Whole Project Interacts Build Final Design Design Build Prototype Final Design Design Prototype Build Final Design Design Prototype Build Final Design Design Code Test Design Prototype Build Final Design Build Design Prototype Build Final Design Contract Delivery Design Prototype Build Final Design Design Prototype Build Final Design Design Build Prototype Final Design Design Prototype The tasks in the IMS should be the same top-level tasks that are included in the IMP

39. Warning from Dilbert “For large projects, team leaders use sophisticated project management software to keep track of who’s doing what. The software collects the lies and guesses of the project team and organizes them into instantly outdated charts that are too boring to look at closely. This is called ‘planning.’” Adams, The Dilbert Principle

40. Software Role in Developing the Integrated Master Schedule • Ideal project • Participate in developing this schedule, • Make sure the top level software tasks are represented properly, and • Document these for use in software planning. • Less-than-ideal project • May need to prod others to do their part in making this schedule

41. Manager Accounting Chief Engineer Contract Administration Support Manager Software Development Manager Electrical Design Manager Mechanical Design Manager Software Manager’s Primary Responsibility Team for Product 1 Team for Product n .... Organizational Breakdown Structure

42. Customer Interface Support Engineering Accounting Program Management Team Product Engineering Contract Administration Team for Product 1 Team for Product n Engineering Team Software Manager’s Responsibility (may need to convince PM to have an overall sw manager) .... Team for Product 2 A Team-Oriented Organizational Breakdown Structure

43. Project Company A Company B A’s Specialty Other B’s Specialty Other Joint Responsibility A Typical Organizational Problem You may need to be sure there is a workable relationship

44. Software Responsibilities Make sure you know whom you depend on and who depends on you. • Develop an interdependency checklist to show all “independent” activities on which software depends or that software depends on • The purpose of this is to make you and others aware of how software is affected by other parts of the project

45. Software Depends on ... Software Depends On: ItemDueMust have by Emulator Build 3/5 4/1 Keyboard Prototype 5/31 6/15 Numeric Keypad SW 6/30 7/1 These are the items you must track closely, as they can endanger your schedule

46. Software Impacts ... Software Impacts: ItemDueLatest Keyboard Final 7/5 8/1 Design These are items you must also track closely, as your slips can endanger them and perhaps the whole project

47. Who’s Who • A major issue on a project is “who is responsible for what”. This is important to decide as part of planning so everyone knows how to get things done efficiently • Among the roles people might play: • Responsible – the person who does the work • Authority – the person who approves it • Consultant – someone who should be consulted due to their expertise • Informee – someone who “needs to know” that the task is being done

48. Who’s Who Example • Issue: Deciding what to do about a proposed change in requirements • Responsible: the person who collects relevant data and makes a recommendation • Authority: the person who approves it • Consultant: someone who is an expert on something related to this change • Informee: someone who would be affected and “needs to know” that the change is being considered

49. RACI Charts • A RACI Chart is a way of documenting the roles for all important tasks that involve more than one person, so everyone knows who does what

50. Sample RACI Chart