Tuesday, August 17, 2010

Design Heuristics for Effective Modularity from MI0024 MBA Assignment

“Summarize design heuristics for effective modularity.” The question of SMU MBA assignment for Software Engineering (MI0024) has to solve students. It is one more solved assignment for students of Sikkim Manipal University with Information System (IS) specialty MBA MI0024. There are already some assignments of MBA MI0024 for students of SMU - Formal technical reviews, COCOMOL model and Linear Sequential Model.

Once the program structure has been developed, effective modularity can be achieved by applying the design concepts introduced earlier in this chapter. The program structure can be manipulated according to the following set of heuristics:

Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion. Once the program structure has been developed, modules may be exploded or imploded with an eye toward improving module independence. An exploded module becomes two or more modules in the final program structure. An imploded module is the result of combining the processing implied by two or more modules.

Attempt to minimize structures with high fan-out; strive for fan-in as depth increases. The structure shown inside the cloud does not make effective use of factoring. All modules are “packed” below a single control module. In general, a more reasonable distribution of control is shown in the upper structure.

Keep the scope of effective a module within the scope of control of that module.

The scope of effect of module is defined as all other modules that are affected by a decision made in module. The scope of control of module is all modules are subordinate and ultimately subordinate to module; if module makes a decision that affects module we have a violation of this heuristic, because module lies outside the scope of control module.

Evaluate module interfaces to reduce complexity and redundancy and improve consistency. Module interface complexity is a prime cause of software errors. Interfaces should be designed to pass information simply and should be consistent unrelated data passed via an argument list or other technique is an indication of low cohesion.

Define modules whose function is predictable, but avoid modules that are overly restrictive. A module is predictable when it can be treated as a black box; that is, the same external data will be produced regardless of internal processing details. Modules that have internal “memory” can be unpredictable unless care is taken in their use.

Strive for “controlled entry” modules by avoiding “pathological connections.” This design heuristic warns against content coupling. Software is easier to understand and therefore easier to maintain when module interfaces are constrained and controlled.

Tuesday, August 3, 2010

Formal Technical Reviews for MI0024 MBA Assignment of SMU

“Explain the formal technical reviews.” It is the question of SMU MBA assignment for Software Engineering (MI0024). It is for students of Sikkim Manipal University with Information System (IS) specialty MBA MI0024. I have already written some assignments of MBA MI0024 for students of SMU - Earned value is a measure of progress, COCOMOL model and Linear Sequential Model.

A formal technical review is a software quality assurance activity performed by software engineers (and others). The objectives of the FTR are (1) to uncover errors in function, logic, or implementation for any representation of the software; (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more manageable. In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because a number of people become familiar with parts of the software that they may not have otherwise seen.

(1) The review Meeting:

The review meeting is attended by the review leader, all reviewers, and the producer. One of the reviewers takes on the role of the recorder; that is, the individual who records (in writing) all important issues raised during the review. The FTR begins with an introduction of the agenda and a brief introduction by the producer.

(2) Review Reporting and Record Keeping:

The review summary report is a single page form (with possible attachments). It becomes part of the project historical record and may be distributed to the project leader and other interested parties.

(3) Review Guidelines:

Guidelines for the conduct of format technical reviews must be established in advance, distributed to all reviewers, agreed upon, and then followed. A Review that is uncontrolled can often be worse that no review at all.