I like to re-read my favorite books every few years, so I brought Robert Glass' seminal Facts and Fallacies of Software Engineering with me on my most recent trip. I thought it was a decent, but imperfect read when I originally bought it in 2004. As I scanned through the introduction and table of contents, I realized that I've written about almost everything in this book by now.I'm not sure I gave Facts and Fallacies its due on my first read.Simply reciting the various facts and fallacies feels like a zen koan to software engineering. Even without any of the background discussion and explanation in the book, it's therapeutic to ponder the brief one sentence summaries presented in the table of contents. As you read these, what comes to mind, based on your experience?PeopleThe most important factor in software work is the quality of the programmers.The best programmers are up to 28 times better than the worst programmers.Adding people to a late project makes it later.The working environment has a profound impact on productivity and quality.
Tools and TechniquesHype (about tools and technology) is a plague on the house of software.New tools and techniques cause an initial loss of productivity / quality.Software developers talk a lot about tools, but seldom use them.
EstimationOne of the two most common causes of runaway projects is poor estimation.Software estimation usually occurs at the wrong time.Software estimation is usually done by the wrong people.Software estimates are rarely corrected as the project proceeds.It is not surprising that software estimates are bad. But we live and die by them anyway!There is a disconnect between software management and their programmers.The answer to a feasability study is almost always "yes".
ReuseReuse-in-the-small is a solved problem.Reuse-in-the-large remains a mostly unsolved problem.Reuse-in-the-large works best in families of related systems.Reuseable components are three times as hard to build and should be tried out in three different settings.Modification of reused code is particularly error-prone.Design pattern reuse is one solution to the problems of code reuse.
RequirementsOne of the two most common causes of runaway projects is unstable requirements.Requirements errors are the most expensive to fix during production.Missing requirements are the hardest requirements errors to correct.
DesignExplicit requirements 'explode' as implicit requirements for a solution evolve.There is seldom one best design solution to a software problem.Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.
CodingDesigner 'primitives' rarely match programmer 'primitives'.COBOL is a very bad language, but all the others are so much worse.
Error removalError removal is the most time-consuming phase of the lifecycle.
TestingSoftware is usually tested at best to the 55 to 60 percent coverage level.100 percent test coverage is still far from enough.Test tools are essential, but rarely used.Test automation rarely is. Most testing activities cannot be automated.Programmer-created, built-in debug code is an important supplement to testing tools.
Reviews and InspectionsRigorous inspections can remove up to 90 percent of errors before the first test case is run.Rigorous inspections should not replace testing.Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.Reviews are both technical and sociological, and both factors must be accommodated.
MaintenanceMaintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.Enhancements represent roughly 60 percent of maintenance costs.Maintenance is a solution-- not a problem.Understanding the existing product is the most difficult maintenance task.Better methods lead to more maintenance, not less.
QualityQuality is a collection of attributes.Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.
ReliabilityThere are errors that most programmers tend to make.Errors tend to cluster.There is no single best approach to software error removal.Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
EfficiencyEfficiency stems more from good design than good coding.High-order language code can be about 90 percent as efficient as comparable assembler code.There are tradeoffs between optimizing for time and optimizing for space.
ResearchMany researchers advocate rather than investigate.
I had forgotten how much ground the book covers; it's a perfect springboard to all the essential topics in software engineering.I've posted on almost every one of these facts in the intervening four years since I originally read them. As I delved into the table of contents presented above, I could barely contain myself. I remembered and mentally checked each post off the list as I went: check, check, check. I've been accused of gratuitous self-linking in the past, so I won't clutter up the rules with dozens of links to my old posts on these topics. If you're interested, you can find it. That's sort of the point.If those are the fifty-five facts, then these are the ten fallacies presented at the end. Fallacies have the ring of truth, but upon closer inspection, turn out to be problematic when applied to a real live software project.You can't manage what you can't measure.You can manage quality into a software product.Programming can and should be egoless.Tools and techniques: one size fits all.Software needs more methodologies.To estimate cost and schedule, first estimate lines of code.Random test input is a good way to optimize testing."Given enough eyeballs, all bugs are shallow".The way to preduct future maintenance costs and to make product replacement decisions is to look at past cost data.You teach people how to program by showing them how to write programs.
If you're curious about the rationale behind these facts and fallacies, that's entirely the reason the book exists: to remind us to question what we're doing. We should be thinking about our craft every day, in some small way, on our own software projects. That's how we collectively advance software engineering-- by building our shared memory and history in the field. As Mr. Glass states in the introduction:In presenting these facts, I am also indentifying problems in the field. It is not my intention to present solutions to these problems. This is a what-is book, not a how-to book. That's important to me. I want to bring these facts into the open, where they can be freely discussed, and we can act on them to make progress.I encourage you to pick up a copy of the full book for a deeper exploration. I do believe there's a rich learning experience-- or a rich remembering experience-- here for those of you who choose to read on.
Facts and Fallacies of Software Engineering
So back to the book. Robert lays out 55 facts and fallacies across areas including management, the life cycle and quality. Pretty much all of then I recognise and agree with. There are a couple of odd-ball / controversial ones, COBOL is a very bad language, but all the others are so much worse for example.
The book simply presents these facts and fallacies grouped by domain and subject, provides rationale and examples of them and supports their credibility through referencing other work. It can be a bit dry to read front to back, but the text's really meant for dipping in and out of when you're looking for that inspiration to solve your project's issues.
The book is a very easy read and well separated into various facts and fallacies. So, you can read one-two facts at a time. It is also a great example in the software field to be able to understand the software much better since the author is knowledgeable quite a bit in the area.
Software requirements involve both design and understanding of what is needed by the application. This is a creative activity that calls for abstract models to analytically analyze and to reason out requirements. Design decisions and conformance criteria, making sure these are well understood prior to coding. Starting with software requirement analysis methodologies, abstraction principles and specification paradigms. Students will learn how to use modeling as an effective instrument for making software systems more reliable, the requirements gathering process more predictable, and overall improve the quality of the resulting product. Students will evaluate contrasting methodologies and how to ensure high quality requirements be provided to the development stage of software engineering process.TopicsRequirements position in the Software Development Lifecycle (SDLC)
Scoping
Methods for requirements analysis
Design Models
Functional and Non-Functional Requirements
Risk Identification and Management
Requirements Management
Completeness and Consistency checking
Formal Specifications
Importance of User Community to Requirements Engineering
Reference BooksSoftware Engineering, 10th Edition, Ian Sommerville, Addison-Wesley, 2015, 9780133943030, General reference to basic software engineering principles
Facts and Fallacies of Software Engineering, Robert L. Glass, Addison-Wesley, 2003, 9780321117427
The Logic of Failure, Dietrich Dorne, Basic Book, 1996, 9780201479485
Code Complete, Steve mcConnell, Microsoft Press, 2004, 9780735619678
Managing Software Requirments A Use Case Approach 2nd edition, Dean Leffingwell Don Widrig, addison wesley, 2003, 9780321122476
2ff7e9595c
Comentarios