55 Facts and 10 Fallacies about Software Engineering

55 Facts




ABOUT MANAGEMENT

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.
Fact 5 : Hype (about tools and techniques) is the plague on the house of software.
Fact 6 : New tools and 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 feasability 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 problem 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.



ABOUT THE LIFE CYCLE

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 solition 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 programmers 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 55 to 60 precent (branch) coverage level.
Fact 33 : One hundred 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 : Rigorous inspections should not replace testing.
Fact 39 : Postdelivery reviews (some call them “retrospectives”) are important and seldon perfromed.
Fact 40 : Reviews are both technical and socialogical, and both factors must be accommodated.

MAINTENANCE:

Fact 41 : Maintenance typically consumes 50 to 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.



ABOUT QUALITY



QUALITY:

Fact 46 : Quality is a collection of attributes.
Fact 47 : Quality is not user satisfaction, meeting requirements, achieveing cost and 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 from 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.



ABOUT RESEARCH



Fact 55 : Many researchers advocate rather than investigate.


5+5 Fallacies




ABOUT MANAGEMENT



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 tecniques: one size fits all.
Fallacy 5 : Software needs more methodologies.

ESTIMATION:

Fallacy 6 : To estimate cost and schedule, first estimate lines of code.




ABOUT THE LIFE CYCLE


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 the future maintenance costs and to make product replacement decisions is to look at past cost data.


ABOUT EDUCATION
Fallacy 10 : You can teach people how to program by showing them how to write programs.





Thanks & Regards ,

Prashant Vadher | QA Engineer



0 Comments:

Post a Comment

 
Design by Prashant Vadher