1 / 16

Effort metrics: Man-month

The book "The Mythical Man-Month" by Frederick P. Brooks Jr. is a timeless source of contemplation on the challenges faced in software projects. This book examines the pitfalls of large-scale programming and the myth of the man-month. Through essays and reflections, Brooks emphasizes the importance of accurate estimation, progress monitoring, and the dangers of adding manpower to a late project. Discover why software projects often fail due to poor scheduling and the misconceptions surrounding effort metrics.

princef
Download Presentation

Effort metrics: Man-month

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. Effort metrics: Man-month

  2. Mythical Man Month – the book Mythical Man Month 1st ed.Ch.1-15 (1975) • Brooks lead development of OS/360 and reflected on the problems experienced in the project. • The book consists of a number of essays. • The1986-paper started a lot of debate. • Countless reviews, discussion, etc. on www. • The book is widely recognized and – to a certain extent – timeless. Source of contemplation. ”Large-system programming has […] been a tar pit […]. Few have met goals, schedules, and budgets. […] Team after team has become entangled in the tar. No one thing seems to cause the difficulty[…]. But the accumulation of simultaneous and interacting factors brings slower and slowermotion. Everyone seems to have been surprised by the stickiness of the problem, and it is hard to discern the nature of it. But we must try to understand it if we are to solve it.” No Silver Bullet IFIPS paperCh.16 (1986) Reflection on NSBCh.17 (1995) Reflection on MM-MCh.18-19 (1995)

  3. Essay: The Mythical Man Month More software projects have gone awry due to lack of calendar time than for all other causes combined. Why is this cause of disaster so common? • Poor estimation techniques. • Gutless estimating. • Poor progress monitoring. • Schedule slippage ”solved” by adding manpower. • Confuse effort with progress.

  4. Man- Month • The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. • It implies that men and months are interchangeable.

  5. Il mese-uomo (1) • Andamento ideale della curva tempo-risorse

  6. Men/Months interchangable Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming!

  7. Men/Months interchangable The bearing of a child takes nine months, no matter how many women are assigned!

  8. Men/Months interchangable In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done

  9. Men/Months interchangable If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. The added effort of communicating may fully counteract the division of the original task

  10. Il mese-uomo (2) • Andamento reale della curva tempo-risorse

  11. Communication Overhead 5 Members 10 Interactions 10 Members 45 Interactions

  12. Peculiarità del software • Complessità • Labilità • Modificabilità • Invisibilità

  13. Men/Months interchangable The plan First task, twice as long Adding 2, at Milestone A

  14. Men/Months interchangable - Lessons • Brooks’ law: • Adding man power to a late project makes it later. • Calculate overhead when adding man power. • Use quick starters. • Take competences into account. • Today: • Plan the project so that slippage are revealed earlier (iterations + use cases).

  15. People and Effort “If we fall behind schedule we can always add more programmers and catch to late in the project” Has a disruptive effect on the project Schedules slip even further

  16. People and Effort The relationship between the number of people working in software project and overall productivity is not linear Fewer people and longer time period is a better option for software development

More Related