Review Question Set III

Explain the benefits of devoting at least 40% of the software development effort to design.

The benefits of devoting at least 40% of the software development effort to design are :
1. the better the software quality
2. the fewer problems will occur in the later phases
3. the fewer resources will be required for the new system's total life cycle
4. the cost of correcting an error is much higher after the program has been implemented than during the design and coding phase.
What are the 2 factors that measure the degree of modularity?

Modularity is the partitioning of a software design into individual components called modules or objects, to reduce its complexity. The 2 factors that measure the degree of modularity are :
1. the level of coupling between modules, and
2. the degree of cohesion within modules.
Define coupling and cohesion.

Coupling measures the degree of independence and interaction between modules.

Cohesion measures the strength of the relationship between elements of code within a module.
Explain why tightly coupled software modules are difficult to code, test and maintain.

In tightly coupled software modules it is almost impossible to maintain one module without making changes in other modules, and are, therefore, difficult to code, test and maintain; also it is not reuseable for other applications.
List and describe modular design guidelines.

The modular design guidelines are :
1. Factoring and module sizing
  Factoring also called leveling, is decomposing or dividing one module into several modules. This is to reduce modular size and to improve coupling and cohesion properties of the modules.
2. Design splitting
  A design split occurs if the 2 parts of a decision are seperated and placed into 2 different modules. Decision splitting should be avoided, if possible.
3. Fan-in/Fan-out
  Fan-in of a module is the number of modules that call it. Fan-out or span of control, is the number of direct subordinates to a module. Generally, fan-in modules should be as high as possible for modules that serve a common function such as a print routine or some kind of utility. Generally, a superior module should not call more than 5 subordinate modules.
4. Number of modules
  There is an optimum number of modules. A general guideline measurement is to divide the total LOEC by 50.
The prime objective of structured design is modularity. But can a software have too many modules? Explain.

Modularity is used to reduce the cost of software development and maintenance. There is an optimum number of modules. A general guideline measurement is to divide the total LOEC by 50. Too may modules will result in longer development time; also when there are too many modules, a high overhead will be incurred due to modules, this slows down the software systems performance.
Explain why large, spaghetti-like programs are difficult to code, test and maintain.

Spaghetti-like programs are a result of using too many "go to" statements, that is, it is the antithesis of structured design. Such programs are not hierarchically structured, modular and do not follow a block structure. It is difficult to follow such program construct, let alone code, test or maintain it!
What role does a structure chart play in structured software design? What role does structured English play? Why are decision tables, decision trees, and equations sometimes needed as supplementary design tools?

Structured Charts and Structured English are normally used to model the software design abstracted from systems design modelled by Data Flow Diagrams (DFDs) and State Transition Diagrams (STDs). The structured chart is a hierarchical diagram that defines the overall architecture of the software design by deiplaying the program modules and their inter-relationships.

Structured English serves as a specification tool that describes detailed input, processes and outputs of structured charts.

Decision tables are used where many actions are required for any given decision. The decision trees are used for decisions that result in only one or two actions. Equations are needed to specify a process that involves much mathematical computation.
What are the rules for writing structured English?

Structured English follows the basic programming constructs of sequence, selection and iteration. It uses the keywords such as FOR, GET, READ, SET, ENTER, etc and the logical keywords such as AND, OR, GREATER THAN, and LESS THAN.
If a DFD is used as a systems design tool, why is it transformed into a structure chart?

A DFD that has been functionaly decomposed to detailed level becomes a basis for the structured software design using a structure chart. Transforming a DFD into a structure chart involves Transform Analysis, which entails an examination of the DFD to divide its processes into those that :
1. Perform input and editing, such as validating a sales order
2. Perform processing such as checking inventory
3. Generate output such as preparing shipping documents
This structure chart containing the input, processing and output processes represents the modules that will be coded.
Define object, classes and relationships.

Object provide people or things with identity; it represent concrete entities from the application domain being design. An object class describes a group of objects with similar attributes, common behaviour and common relationships to objects. Relationships describe the association between the classes and the objects.
Explain how inheritance supports reuseability.
Inheritance is the capability to define subclasses of objects from an object class. It is the ability of a descendent receive properties or characteristics from an ancestor. Thus, when an object code is completed, it can be reused for new classes that can inherit the original object class properties or characteristics.
Describe the contents of a fully defined class box.

The class box has 3 regions - class, attributes, and operations.
Explain how to achieve MURRE design factors using the object-oriented approach.

The MURRE design factors - maintainability, useability, reuseability, reliability and extenability are also applicable to object-oriented software design, for example, highly cohesive classes are desireable. As with structure software design, the most desirable form of cohesion for object-oriented software design is functional cohesion, in which all objects in a class work together to provide some well-balanced behaviour. Not only will such function specific sets of objects be easier to maintain, but their reliability can be tested more easily, their reuseability will be enhanced and extending them, if necessary, will be more efficient.
Explain encapsulation and its relationship to public and private feature of object-oriented designs.

Encapsulation also called information hiding, involves tha seperation of the public or external aspects of an object that are accessible to other objects from the private or internal attributes and operations of the object. Thus, encapsulation prevents objects from becoming so tightly related or coupled that a small change in 1 object ripples throughout the object-oriented design.
Explain the similarities between the structured approach and the object-oriented approach. Explain how the 2 approaches differ.

The similarities between the structured approach and the object-oriented approach are :
1. MURRE factors are applicable to both
2. Both desires highly cohesive classes/modules
3. Both highly desires functional cohesion classes/modules
4. Both require classes/modules to be small and understandable
5. Both require classes/modules to be documented.
The differences between the structured approach and the object-oriented approach are :
1. The structured approach deigns a system around procsses or data, whereas object-oriented approach designs a system around objects.
2. In the structured approach, the structure chart shows processes or functionality. In the object-oriented approach, the object-oriented model shows object classes and relationships between objects and classes.
3. The structured approach is based on a system, scope or boundary which may make it difficult to extend the design to new scope or boundary. On the other hand, the object-oriented approach does not have this problem; it is easy to extend an object-oriented design merely by adding objects.
4. Objects are more easily understood by users, because objects represent concepts and things in the real world. Users, therefore, do not need to comprehend attributes and operations, infact, these are usually hidden from them. The modules in the structured approach are not "hidden".
5. Well-designed modules from the structured approach also provide opportunities for reusing such modules. The ideal goal of reuseabilty is to have in a class library all the objects available to support design applications. But, due to the newness of the object-oriented approach, we are a long way from widely employing large libraries of reuseable objects, especially for business applications.
Explain why it is more difficult and costly to remove an error during the maintenance phase than it is during the design phase.

Discovering errors during maintenence usually causes a longer and more expensive correction process because the entire SWDLC process may have to be repeated; that is redesigning, recoding, and retesting to repair the system.
What is the purpose of a software design walkthrough? Explain how a walkthrough should be conducted.

A software walkthrough is conducted after the software design is completed to ensure that the design is correct and that it meets the Detailed Design Report specifications.

Procedures for a software design walkthrough :
1. It should be administered by a meeting manager or moderator.
2. Software design documents are scrutinised by reviewers who may be software engineers, user representatives and systems analysts or designers.
3. Reviewers must have clear-cut instructions and procedures. They must read the design documentation in advance of the walkthrough meeting and challenge or question it in the meeting.
4. At the meeting, neither the meeting manager nor the moderator should comment on the software design. The moderator runs the meeting including establishing meeting rules, setting meeting time and place, recognising reviewers and software designers, stopping interruptions, keeping the walkthrough on track and preparing a summary report.
5. The recorder writes all significant comments on flip chart sheets that everyone in the meeting room can see.
6. At the end of the software design walkthrough, the walkthrough team must decide whether to :
  1. Accept the design without further modifications
  2. Reject the design because of major errors
  3. Accept the design conditionally
7. Once the decision is made, the walkthrough team complete a sign-off, indicating their participation in the walkthrough and their concurrence with the walkthrough team's findings.
8. After some reasonable time elapses, the walkthrough team will conduct a follow-up walkthrough to make sure all errors have been corrected and none have been ignored.
Where do the majority of the software errors come from?

Two-thirds of software errors emanate from the software design rather than software coding.
Explain the function of the moderator, recorder and the reviewers.

The moderator administer the walkthrough meeting. The moderator runs the meeting including establishing meeting rules, setting meeting time and place, recognising reviewers and software designers, stopping interruptions, keeping the walkthrough on track and preparing a summary report.

The recorder writes all significant comments on flip chart sheets that everyone in the meeting room can see. Software design documents are scrutinised by reviewers who may be software engineers, user representatives and systems analysts or designers. Reviewers must have clear-cut instructions and procedures. They must read the design documentation in advance of the walkthrough meeting and challenge or question it in the meeting. The reviewers make up the walkthrough team. At the end of the software design walkthrough, the walkthrough team must decide whether to :
1. Accept the design without further modifications
2. Reject the design because of major errors
3. Accept the design conditionally
Once the decision is made, the walkthrough team complete a sign-off, indicating their participation in the walkthrough and their concurrence with the walkthrough team's findings.
Describe the elements that make up a Software Design Walkthrough Report.

The elements that make up a Software Design Walkthrough Report include :
1. Walkthrough Identification, which includes the project name, walkthrough number, date, location and time.
2. Software Identification, which nclude the material reviewed and by whom.
3. Material Reviewed, which includes modules and type of modeling tool.
4. Walkthrough Team, which includes the names of the whole team.
5. Software Design Appraisal, which includes a decision on the acceptibilty of the software designed.
6. Errors List, which includes a list of all the errors found.
7. Suggestions, which includes suggestions for the improvement of the software designed.
When is a software design deemed complete and ready for coding?

A software design should not be considered complete until it is approved by the software design walkthrough team.