McConnell_2004_CH03_and4_Upstream_Prerequisites_and_Key_Construction_Decisions Flashcards
The overreaching goal of preparation is…?
risk reduction. (A good project planner clears major risks out of the way as early as possible so that the bulk of the project can proceed as smoothly as possible. By far the most common project risks in software development are poor requirements and poor project planning, thus preparation tends to focus on improving requirements and project plans.)
What are 3 possible responses to WISCA/WIMP?
The “Why isn’t Sam coding anything?” or “Why Isn’t Mary Programming” If the manager of your project pretends to be a brigadier general and orders you to start coding right away, it is easy to say, “yes, sir” (What’s the harm? the old guy must know what he’s talking about) This is a bad response, and you have several better alternatives. First you can flatly refuse to do work in an ineffective order. If you relationships with your boss and your bank account are healthy enough for you to be able to do this, good luck.
A second questionable alternative is pretending to be coding when you’re not. Put an old program listing on the corner of your desk. Then go right ahead and develop your requirements and architecture, with or without your boss’s approval. You’ll do the project faster and with higher-quality results. Some people find this approach ethically objectionable, but from your boss’s perspective, ignorance will be bliss.
Third you can educate your bus in the nuances of technical projects. This is a good approach because it increases the number of enlightened bosses in the world. The next subsection presents an extended rationale for taking the time to do prerequisites before construction.
Finally you can find another job, Despite economic ups and downs, good programmers are perennially in short supply, and life is to short to work in an unenlightened programming shop when plenty of better alternatives are available.
What is the impact on cost depending on when defects are introduced and when they are found…?
purging an error by the beginning of construction allows rework to be done 10 to 100 times less expensively than when it’s done in the last part of the process, during system test or after release.
In general, the principle is to find an error as close as possible to the time at which it was introduced.
Business systems software projects tend to benefit from what sort of approach…?
Iterative approaches with prerequisites.
Some writers have asserted that projects that use iterative techniques don’t need to focus on the prerequisites much at all, but that point of view is misinformed. Iterative approaches tend to reduce the impact of inadequate upstream work, but they don’t eliminate it.
Projects that don’t focus on prerequisites:
One project is conducted sequentially and relies solely on testing to discover defects; the other is conducted iteratively and discovers defects as it progresses. The first approach delays most defect correction work to the end of the project, making the costs higher. The iterative approach absorbs rework piecemeal over the course of the project, which makes the total cost lower. The relative costs of the two general approaches are well supported by the research.
The iterative project that abbreviates or eliminates prerequisites will differ in two ways from a sequential project that does the same thing. First, average defect correction costs will be lower because defects will tend to be detected closer to the time they were inserted into the software. However, the defects will still be detected late in each iteration, and correcting them will require parts of the software to be redesigned, recoded, and retested-which makes the defect-correction cost higher than it needs to be.
Second, with the iterative approaches cost will be absorbed piecemeal, throughout the project, rather than being clustered at the end. When all the dust settles, the total cost will be similar but it won’t seem as high because the price will have been paid in small installments over the course the project, rather than paid all at once at the end.
A focus on prerequisites can reduce costs regardless of whether you use an iterative or a sequential approach. Iterative approaches are usually a better option for many reasons, but an iterative approach that ignores prerequisites can end up costing significantly more than a sequential project that pays close attention to prerequisites.
Most projects are neither completely sequential nor completely iterative. It isn’t practical to specify 100% of the requirements or design up front, but most projects find value in identifying at least the most critical requirements and architectural elements early.
One common rule of thumb is to play to specify about 80% of requirements up front, allocate time for additional requirements to be specified later, and then practice systematic change control to accept only the most valuable new requirements as the project progresses. Another alternative is to specify only the most important 20% of the requirements up front and plan to develop the rest of the software in small increments, specifying additional requirements and designs as you go.
When is it appropriate to choose a sequential approach…?
- The requirements are fairly stable.
- The design is straightforward and fairly well understood.
- The development team is familiar with the application area.
- The project contains little risk
- Long-term predictability is important.
- The cost of changing requirements, design, and code downstream is likely to be high.
When is it appropriate to choose an iterative approach…?
- The requirements are not well understood or you expect them to be unstable for other reasons.
- The design is complex, challenging, or both.
- The development team is unfamiliar with the application area.
- The project contains a lot of risk.
- Long-term predictability is not important.
- The cost of changing requirements, design, and code downstream is likely to be low.
List 14 architectural components which need to be considered before software construction…?
- Program Organization
- Major Classes
- Data Design
- Business Rules
- User Interface Design
- Resource Management
- Security
- Performance
- Scalability
- Interoperability
- Internationalization/Localization
What are three ways in which the choice of programming language can affect programmer productivity?
- Programmers are more productive using a familiar language than an unfamiliar on.
- Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages.
- Some languages are better at expressing programming concepts than others.
- Programmers may be similarly influenced by their languages.
- Evidence of the effect of programming languages on programmers’ thinking is common.
What is the difference between programming IN a programming language and programming INTO a programming language?
Programmers who program “in” a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer’s thoughts will also be primitive.
Programmers who program “into” a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.
