....software engineering laundry list....
Frequently Forgotten Fundamental Facts about Software Engineeringselected quotes:
Complexity
C1. For every 10-percent increase in problem complexity, there is a 100-percent increase in the software solution's complexity. That's not a condition to try to change (even though reducing complexity is always desirable); that's just the way it is.
Quality
Q1. Quality is a collection of attributes. Various people define those attributes differently, but a commonly accepted collection is portability, reliability, efficiency, human engineering, testability, understandability, and modifiability.
Q2. Quality is not the same as satisfying users, meeting requirements, or meeting cost and schedule targets. However, all these things have an interesting relationship: User satisfaction = quality product + meets requirements + delivered when needed + appropriate cost.
Q3. Because quality is not simply reliability, it is about much more than software defects.
Q4. Trying to improve one quality attribute often degrades another. For example, attempts to improve efficiency often degrade modifiability.
Reliability
RE1. Error detection and removal accounts for roughly 40 percent of development costs. Thus it is the most important phase of the development life cycle.
RE5. There is no single best approach to software error removal. A combination of several approaches, such as inspections and several kinds of testing and fault tolerance, is necessary.
Efficiency
EF1. Efficiency is more often a matter of good design than of good coding. So, if a project requires efficiency, efficiency must be considered early in the life cycle.
Maintenance
M2. Maintenance typically consumes about 40 to 80 percent (60 percent average) of software costs. Therefore, it is probably the most important life cycle phase.
M3. Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. So, software maintenance is largely about adding new capability to old software, not about fixing it.
Requirements and design
RD1. One of the two most common causes of runaway projects is unstable requirements.
RD2. When a project moves from requirements to design, the solution process's complexity causes an explosion of "derived requirements." The list of requirements for the design phase is often 50 times longer than the list of original requirements.
Reviews and inspections
RI1. Rigorous reviews commonly remove up to 90 percent of errors from a software product before the first test case is run.
RI2. Rigorous reviews are more effective, and more cost effective, than any other error-removal strategy, including testing.
Estimation
ES1. One of the two most common causes of runaway projects is optimistic estimation.
ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.
ES7. Pressure to achieve estimation targets is common and tends to cause programmers to skip good software process. This constitutes an absurd result done for an absurd reason.
Posts
