1. © 2005 Prentice Hall14-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML

2. © 2005 Prentice Hall14-2 Learning Objectives Discuss some of the reasons why information system development projects fail. Describe the goals of project management. Name some of the risk factors associated with users, the development team, and the project itself. Explain why it is important to manage users’ expectations for a project.

3. © 2005 Prentice Hall14-3 Learning Objectives (continued) Discuss how risk, coverage, and criticality can contribute toward developing a project strategy. Read a Gantt chart and a critical path model. Discuss how object-oriented software benefits software development. Explain why the Unified Process creates a detailed project plan for the next iteration only.

4. © 2005 Prentice Hall14-4 Learning Objectives (continued) Identify the disciplines in the Unified Process which are related to project management. Discuss issues related to preparing estimates of project costs and resources. Explain the use of prototyping in object-oriented software development. Discuss some alternatives to custom software development.

5. © 2005 Prentice Hall14-5 Overview The history of software development is full of examples of failed projects. These failures are seldom due to lack of technical competence. Instead, they are related to poor management and poor communication. Project management seeks to identify and mitigate risks, prepare project plans and schedules, maintain continuing communication, and manage users’ expectations.

6. © 2005 Prentice Hall14-6 Overview (continued) A project plan and schedule are the basis for managing a system development project. The plan allocates tasks, responsibilities, and resources to a team of people. Object-oriented technology and the Unified Process facilitate effective software development and a flexible, adaptable development process.

7. © 2005 Prentice Hall14-7 Overview (continued) Project management requires quantitative measurements of progress, ideally by outsiders to the development team. Best practices of software development incorporate prototyping. Not every system development project requires custom software development.

8. © 2005 Prentice Hall14-8 Why Software Development Projects Fail Projects fail because: Users fail to communicate requirements completely and accurately. Users are not sufficiently committed to the project. The project has no top management champion.

9. © 2005 Prentice Hall14-9 Why Software Development Projects Fail (continued) Project budget and schedules are unrealistic. Risks are not adequately identified and mitigated. According to DeMarco, however, the chief cause of failure is because: Users’ expectations are inflated and unreasonable.

10. © 2005 Prentice Hall14-10 Goals of Project Management The primary goal of software project management is a successful outcome for the project. This means that the project must: Meet users’ reasonable expectations. Be delivered on time. Be delivered within budget.

11. © 2005 Prentice Hall14-11 Goals of Project Management (continued) Secondary goals include: Identify risks to the project and avoid or mitigate them. Prepare project plans. Monitor project progress against the plans. Earn and maintain users’ trust through communication. Manage users’ expectations.

12. © 2005 Prentice Hall14-12 Risk Analysis A risk is any uncertainty which has a significant probability of preventing the successful completion of a project milestone. Three major categories of risk are those associated with:  Users  The development team  The project

13. © 2005 Prentice Hall14-13 Managing Users’ Expectations Trust and credibility are key to managing users’ expectations. The Unified Process fosters credibility by deferring firm commitments about cost and delivery date until the end of the Initiation and Elaboration phases. By then, the system requirements and system architecture should be stable.

14. © 2005 Prentice Hall14-14 Project Strategy Three important factors can be used to organize a strategy for requirements and iterations: Degree of risk – address high risk areas early. Coverage – how much of the system is included in an iteration? Criticality – functions with the greatest value to the business should be implemented early.

15. © 2005 Prentice Hall14-15 Project Planning and Scheduling A project plan includes: A breakdown of the necessary work The time dependencies among the project tasks The assignment of personnel and other resources to each of the tasks

16. © 2005 Prentice Hall14-16 Project Planning and Scheduling (continued) A project schedule is a set of project artifacts or deliverables listed in the sequence in which they are to be produced. The units of work in a project schedule are tasks or activities. Milestones are marked by the completion of specified deliverables.

17. © 2005 Prentice Hall14-17 Network Planning Models A critical path model or network shows the sequential dependencies among activities in a project. It permits the calculation of: the earliest project completion date and the activities which will delay the project if not completed on time (the critical path).

18. © 2005 Prentice Hall14-18 Network Planning Models (continued).

19. © 2005 Prentice Hall14-19 Network Planning Models (continued) A Gantt chart presents a project schedule as horizontal bars on a vertical time grid. It does not show dependencies among the project activities. It can help communicate the overall features of a project schedule.

20. © 2005 Prentice Hall14-20 Network Planning Models (continued).

21. © 2005 Prentice Hall14-21 Object Technology and Project Management Object-oriented software benefits software development: Objects help attack complexity. Objects build systems resilient to change. Objects allow partial systems to work. Objects are natural units for re-use.

22. © 2005 Prentice Hall14-22 Project Planning in the Unified Process The Unified Process does not plan the entire project in detail in advance. The high-level Phase Plan specifies the major milestones and their deliverables and estimates their completion dates. An Iteration Plan is a detailed plan for the next iteration only.

23. © 2005 Prentice Hall14-23 Management-Related Disciplines in the UP Three core disciplines of the Unified Process are related to project management. Configuration and Change Management manages the artifacts of the system. Project Management manages the development process. Environment supports the process with processes and tools.

24. © 2005 Prentice Hall14-24 Estimating, Measuring, and Controlling Project management requires quantitative measurements of progress. Estimators are responsible for predicting costs and for keeping project records and measurements. The project team is responsible for the project plan and strategy. They should maximize the function delivered per dollar of lifetime cost.

25. © 2005 Prentice Hall14-25 Prototyping A prototype is a partial or limited version which simulates a proposed system. Analysis prototypes – clarify requirements. Design prototypes – explore system architecture or study system performance. Vertical prototypes – implement completely a portion of the system. Feasibility prototypes – study feasibility.

26. © 2005 Prentice Hall14-26 Prototyping Strategies Throwaway prototyping: The prototype is discarded when the construction of the system is complete. These prototypes are not expected to function in a production environment. Evolutionary prototyping: The prototype evolves into the new system. These prototypes must be constructed with enough robustness for the production environment.

27. © 2005 Prentice Hall14-27 Alternatives to Custom Software Development Packaged software: For common applications, if users are willing to change their procedures to adapt to the package Customizable software: Can tailor some of the processes to users’ needs, especially with complex systems. It can be as expensive as custom software.

28. © 2005 Prentice Hall14-28 Summary Failure to manage users’ expectations is probably the most important reason for failed software projects. A project plan and schedule are the basis for software project management. Object-oriented technology can facilitate flexible, adaptive practices in system development, including prototyping. Alternatives to custom development are the use of packaged or customizable software.