capítulo 14 – hatching a catastrophe
“When one hears of disastrous schedule slippage in a project, he imagines that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes; and the schedule has slipped imperceptibly but inexorably.”
“Concrete milestones, on the other hand, are 100-percent events. (…) source coding 100 percent complete, keypunched, entered into disk library, debugged version passes all test cases. These concrete milestones demark the vague phases of planning, coding, debugging”
“But every boss needs two kinds of information, exceptions to plan that require action and a status picture for education. For that purpose he needs to know the status of all his teams. Getting a true picture of that status is hard.”
“The project manager has to keep his fingers off the estimated dates, and put the emphasis on getting accurate, unbiased estimates rather than palatable optimistic estimates of self-protective conservative ones.”
capítulo 15 – the other face
“Different levels of documentation are required for the casual user of a program, for the user who must depend upon a program, and for the user who must adapt a program for changes in circumstance or purpose.”
“To believe a program. The description of how it is used must be supplemented with some description of how one knows it is running. This means test cases.”
“1. Mailine cases that test the program’s chief functions for commonly encountered data.
2. Barely legitimate cases that probe the edge of the input data domain, ensuring that largest possible values, smallest possible values, and all kinds of valid exceptions work.
3. Barely illegitimate cases that probe the domain boundary from the other side, ensuring that invalid inputs raise proper diagnostic messages.”
capitulo 16 – No Silver Bullet – Essence and Accident in Software Engineering
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other sofware systems. No other part of the work so cripples the resulting system if done wrong. No other part is so more difficult to rectify later.
Therefore the most important function that software builders do for their clients is ther iteractive extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and the almos never have thought of the problem in the detail that must be specified. Even the simple answer – “Make the new software system work like our old manual information-processing system” – is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteraction between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for clients, event those working with software engineers, to specifiy completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.”
“Incremental development – grow, not build, software”
“The programmer delivers satisfaction of a user need rather than any tangible product”
Nome: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Autor: Frederick P. Brooks
Editora: Addison-Wesley Professional; 2 edition (August 12, 1995)