html5-img
1 / 23

Software Project Management

Software Project Management. Peking University Fall Semester, 2001. Course Description. Catalog Process context of software development. Task decomposition. Size and schedule estimation. Risk management. Project planning and control mechanisms. Strategic Objective

fern
Télécharger la présentation

Software Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Project Management Peking University Fall Semester, 2001

  2. Course Description • Catalog • Process context of software development. Task decomposition. Size and schedule estimation. Risk management. Project planning and control mechanisms. • Strategic Objective • To study traditional and modern software project management methods and techniques. • Tactical Objectives • Understand the traditional process of software project management. • Understand the basics for improving the traditional process. • Know the disciplines for successful software project management. • Look ahead to the future of software project management.

  3. Format Lectures Oral reports by students Course Texts Software Project Management by Walker Royce The Mythical Man-month by Frederick Brooks, Jr. Grading Oral Presentation on Brook’s book (10%) Class Attendance (20%) Mid-term Exam (30%) Final Exam (40%) Instructor Dr. Jerry B. Williams, P.E. Office and contact Office, Rm 1109M by appointment Phone (US Seattle University 206-296-2112 Email williaj1@seattleu.edu Course Specifics

  4. Software Project Management Part I, Software Management Renaissance Part II, Software Management Process Framework Part III, Software Management Disciplines Part IV, Looking Forward The Mythical Man-Month Chapters 1-17, covering from “The Tar Pit” to “No Silver Bullet”. Chapter 18, “Propositions of the Mythical Man-month”. Course Syllabus

  5. Training versus Education • Education • Study and analyze information on a subject. • Gain knowledge and understanding on the subject. • Training • Learn how to do a task. • Practice how to do the task.

  6. About learning …… • From Mortimer Adler • The basic pedagogical precept…is that all genuine learning arises from the activity of the learner’s own mind.…When the activities performed by the teacher render students passive, the latter cease to be learners…memorizers,, perhaps,, but not learners. • So…….students will make oral presentations on the reading assignments this quarter. (Seattle University students)

  7. . Oral Presentations by a Student Each Class Period • Book report to the students each class period on an assigned Chapter from Brooks’ Mythical Man-month book. (Seattle University students) • Describe what “Brooks says” in the chapter. • Pay special attention to his propositions. • Prepare a 20 minute presentation on what Brooks says in the chapter, and what you think of what he says. • Use Power-point format if convenient.

  8. First Lecture Hour(8:30 – 9:20 am September 8) Conventional Software Management (Royce’ Software Project Management, Chapter 1)

  9. Topics for Today • Conventional Software Development – The Waterfall Model • Conventional Software Development Experience • Typical progress profile • Expenditures • Risk profile • Documents and Reviews • Necessary Improvements to Waterfall Model • Conventional Software Management Performance • Barry Boehm’s “Top 10 List”

  10. Typical Progress Profile – Conventional Project

  11. The Software Development Experience • Development is highly unpredictable. • Only 10% of projects on time and budget. • Management discipline is more of a discriminator in success or failure than are technology advances. • The level of software scrap and rework is indicative of an immature process.

  12. Two Basic Steps

  13. Classical Waterfall Model

  14. Expenditures – Conventional Project • Management 5% • Requirements 5% • Design 10 % • Code and unit testing 30% • Integration and test 40% • Deployment 5% • Environment 5%

  15. Risk Profile – Conventional Project

  16. Typical Software Project Documents and Control • The contractor prepared a draft contract-deliverable document that captured an intermediate artifact and delivered it to the customer for approval. • 2. The customer was expected to provide comments {typically within 15 to 30 days). • 3. The contractor incorporated these comments and submitted {typically within 15 to 30 days) a final version for approval.

  17. Typical Program Experience Early success via paper designs and thorough (often too thorough) briefings. Commitment to code late in the life cycle. Integration nightmares due to unforeseen implementation issues and inter- face ambiguities. Heavy budget and schedule pressure to get the system working. Late shoe-horning of non-optimal fixes, with no time for redesign. A very fragile, un-maintainable product delivered late

  18. Summary of Problems in Conventional Practice…… 1. Protracted integration and late design breakage . 2. Late risk resolution . 3. Requirements-driven functional decomposition. 4. Adversarial stakeholder relationships. 5. Focus on documents and review meetings.

  19. Five Improvements for the Waterfall Model to Work • Complete program design before analysis and coding begin. • Maintain current and complete documentation. • Do the job twice, if possible. • Plan, control, and monitor testing. • Involve the customer.

  20. Fixing after delivery costs 100 times as much as early fix. You can compress schedule 25%, but no more. For every $1 spent on development you will spend $2 on maintenance. Costs are primarily a function of source lines of code. Variations among people account for the biggest differences in productivity Ratio of software to hardware cost is 85:15 and still growing. Only about 15% of software development cost is due to programming. Software systems cost 3 times as much as software programs. Software system products cost 9 times as much. Walkthroughs catch 60% of the errors. 80% of the contribution comes from 20% of the contributors. Boehm’s Top Ten List

  21. The 80/20 Rule 80% of the engineering is consumed by 20% of the requirements. 80% of the software cost is consumed by 20% of the components. 80% of the errors are caused by 20% of the components. 80% of software scrap and rework is caused by 20% of the errors. 80% of the resources are consumed by 20% of the components. 80% of the engineering is accomplished by 20% of the tools. 80% of the progress is made by 20% of the people.

  22. Summary • Conventional software development process today is unreliable and and immature. • The Waterfall Method needs improvements to work satisfactorily. • Conventional practices provide a benchmark for future improvements and changes to software development methods.

  23. Assignment for Next Class • Read Chapter 1, Conventional Software Management, of Royce’ book. • Learn the seven steps of the waterfall model. • Learn the five improvements needed for the approach. • Learn the expenditures figures by activity for conventional software projects. • Learn Barry Boehm’s Metric “Top Ten List” for the state of software development. • Read Chapter 1, “The Tar Pit”, of Brook’s book. • If assigned to you, prepare the “Brook’s Chapter 1” 20 minute report (for presentation to the class).

More Related