Encontre la referencia a varios libros sobre calidad de software, como "
Code Complete" (que he leido) y el que pongo (que
no he leido) pero con solo el sumario del libro se aprende bastante. Probablemente hay unas 3 o 4 ideas que serán controversiales (y sin leer el libro no se que argumentación tendran) pero es una lista solida.
En especial, es un buen sumario para todos los que tenemos que hacer entender a clientes/colegas de la realidad del desarrollo. Ayuda *mucho* tener una fuente que sumarize los puntos (a veces, cuando hay una discusion entre 2, traer un tercero ayuda):
Tomado de:
https://www.amazon.com/Facts-Fallaci...ding=UTF8&me=_
Cita:
Facts and Fallacies of Software Engineering
Note: these points are taken from Robert Glass's book Facts and Fallacies of Software Engineering. You may not agree with all of them, but they are all worth thinking about.
Facts
People
Fact 1. The most important factor in software work is the quality of the programmers.
Fact 2. The best programmers are up to 28 times better than the worst programmers.
Fact 3. Adding people to a late project makes it later.
Fact 4. The working environment has a profound impact on productivity and quality.
Tools and Techniques
Fact 5. Hype (about tools and techniques) is the plague on the house of software.
Fact 6. New tools/techniques cause an initial loss of productivity/quality.
Fact 7. Software developers talk a lot about tools, but seldom use them.
Estimation
Fact 8. One of the two most common causes of runaway projects is poor estimation.
Fact 9. Software estimation usually occurs at the wrong time.
Fact 10. Software estimation is usually done by the wrong people.
Fact 11. Software estimates are rarely corrected as the project proceeds.
Fact 12. It is not surprising that software estimates are bad. But we live and die by them anyway!
Fact 13. There is a disconnect between software management and their programmers.
Fact 14. The answer to a feasibility study is almost always "yes".
Reuse
Fact 15. Reuse-in-the-small is a well-solved problem.
Fact 16. Reuse-in-the-large remains a mostly unsolved problem.
Fact 17. Reuse-in-the-large works best for families of related systems.
Fact 18. Reusable components are three times as hard to build, and should be tried out in three settings.
Fact 19. Modification of reused code is particularly error-prone.
Fact 20. Design pattern reuse is one solution to the problems of code reuse.
Complexity
Fact 21. For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
Fact 22. Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
Requirements
Fact 23. One of the two most common causes of runaway projects is unstable requirements.
Fact 24. Requirements errors are the most expensive to fix during production.
Fact 25. Missing requirements are the hardest requirements errors to correct.
Design
Fact 26. Explicit requirements "explode" as implicit (design) requirements for a solution evolve.
Fact 27. There is seldom one best design solution to a software problem.
Fact 28. Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal.
Coding
Fact 29. Designer "primitives" (solutions they can readily code) rarely match programmer "primitives".
Fact 30. COBOL is a very bad language, but all the others (for business applications) are so much worse.
Error Removal
Fact 31. Error-removal is the most time-consuming phase of the life cycle.
Testing
Fact 32. Software is usually tested at best at the 55-60 percent (branch) coverage level.
Fact 33. 100 percent coverage is still far from enough.
Fact 34. Test tools are essential, but many are rarely used.
Fact 35. Test automation rarely is. Most testing activities cannot be automated.
Fact 36. Programmer-created, built-in, debug code is an important supplement to testing tools.
Reviews and Inspections
Fact 37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
Fact 38. But rigorous inspections should not replace testing.
Fact 39. Post-delivery reviews (some call them "retrospectives" ) are important, and seldom performed.
Fact 40. Reviews are both technical and sociological, and both factors must be accommodated.
Maintenance.
Fact 41. Maintenance typically consumes 40-80 percent of software costs. It is probably the most important life cycle phase of software.
Fact 42. Enhancements represent roughly 60 percent of maintenance costs.
Fact 43. Maintenance is a solution, not a problem.
Fact 44. Understanding the existing product is the most difficult task of maintenance.
Fact 45. Better methods lead to MORE maintenance, not less.
Quality
Fact 46. Quality IS: a collection of attributes.
Fact 47. Quality is NOT: user satisfaction, meeting requirements, achieving cost/schedule, or reliability.
Reliability
Fact 48. There are errors that most programmers tend to make.
Fact 49. Errors tend to cluster.
Fact 50. There is no single best approach to software error removal.
Fact 51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
Efficiency
Fact 52. Efficiency stems more from good design than good coding.
Fact 53. High-order-language code can be about 90 percent as efficient as comparable assembler code.
Fact 54. There are tradeoffs between size and time optimization.
Research
Fact 55. Many researchers advocate rather than investigate.
Fallacies
Management
Fallacy 1. You can't manage what you can't measure.
Fallacy 2. You can manage quality into a software product.
People
Fallacy 3. Programming can and should be egoless.
Tools and Techniques
Fallacy 4. Tools and techniques: one size fits all.
Fallacy 5. Software needs more methodologies.
Estimation
Fallacy 6. To estimate cost and schedule, first estimate lines of code.
Testing
Fallacy 7. Random test input is a good way to optimize testing.
Reviews
Fallacy 8. "Given enough eyeballs, all bugs are shallow".
Maintenance
Fallacy 9. The way to predict future maintenance cost and to make product replacement decisions is to look at past cost data.
Education
Fallacy 10. You teach people how to program by showing them how to write programs.
|
14-06-2016
Temas Similares
Mode Lineal
