Page 172 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes Failure to get a group of people to agree about the solution to an optimization problem is
itself significant. It means that the attribute is probably optimized, and any improvement in
one attributes results in an unacceptable degradation in another. The structured programming
method discourages optimization because of its effect on reliability and maintainability. Code
should be clear and simple, and its optimization should be left to the compiler. Compilers are
more likely to do a better job of optimization than programmers, because compilers incorporate
detailed knowledge of the machine. Often the actual causes of inefficiency are quite different
from what programmers might suspect, and can only be revealed with a dynamic analysis tool.
8.1.7 Prototyping
Experimental prototyping can be useful for:
• Comparing alternative designs;

• Checking the feasibility of the design.
The high-level design will usually have been recognized during the AD phase. Detailed designs
may have to be prototyped in the DD phase to find out which designs best meet the requirements.
The feasibility of a novel design idea should be checked by prototyping. This ensures that an
idea not only works, but also that it works well enough to meet non-functional requirements
for quality and performance.
8.1.8 Design Reviews

Detailed designs should be reviewed top-down, level by level, as they are generated during
the DD phase. Reviews may take the form of walkthroughs or inspections. Walkthroughs are
useful on all projects for informing and passing on expertise. Inspections are efficient methods
for eliminating defects before production begins.

Two types of walkthrough are useful:
• Code reading;
• ‘What-if?’ analysis.
In a code reading, reviews trace the logic of a module from beginning to end. In “what-if?”
analysis, component behaviour is examined for specific inputs. Static analysis tools evaluate
modules without executing them. Static analysis functions are built in to some compilers. Output
from static analysis tools may be input to a code review.
When the detailed design of a major component is complete, a critical design review must certify
its readiness for implementation. The project leader should participate in these reviews, with
the team leader and team members concerned.

8.1.9 Documentation
The developers must produce the DDD and the sum. While add specifies tasks, files and programs,
the DDD specifies modules. The sum describes how to use the software, and may be affected
by documentation requirements in the SRD.
The recommended approach to module documentation is:
• Create the module template to contain headings for the standard DDD entries:
• Component identifier
1. Type
2. Purpose
3. Function
4. Subordinates
5. Dependencies

166 LOVELY PROFESSIONAL UNIVERSITY