Page 177 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING
P. 177

Unit 8: Detailed Design



                          The term CASE was originally coined by software company Nastec Corporation   Notes
                          of Southfield, Michigan in 1982 with their original integrated graphics and text
                          editor GraphiText, which also was the first microcomputer-based system to use
                          hyperlinks to cross-reference text strings in documents—an early forerunner
                          of today’s web page link.

            8.4 Verification of Logic and Algorithm Design

            The output of the design action should be established before proceeding with the activities of
            the next phase. If the design is spoken in some formal notation for which analysis tools are
            available, then through tools it can be checked for internal consistency (e.g., those modules used
            by another are defined, the interface of a module is consistent with the way others use it, data
            usage is consistent with declaration, etc.) If the design is not specified in a formal, executable
            language, it cannot be processed through tools, and other means for verification have to be used.
            The most common approach for verification is design review.
            The purpose of design reviews is to ensure that the design satisfies the requirements and is of
            good quality. If errors are made during the design process, they will ultimately reflect themselves
            in the code and the final system. As the cost of removing faults caused by errors that occur
            during design increases with the delay in detecting the errors, it is best if design errors are
            detected early, before they manifest themselves in the system. Detecting errors in design is the
            purpose of design reviews. The system design review process is similar to the inspection process,
            in that a group of people get together to discuss the design with the aim of revealing designs
            errors or undesirable properties. The review group must include a member of both the system
            design team and the detailed design team, the requirements document, the author responsible
            for maintaining the design document, and an independent software quality engineer. As with
            any review, it should be kept in mind that the aim of the meeting is to uncover design errors,
            not to try to fix them; fixing is done later.
            The number of ways in which errors can enter a design is limited only by the creativity of the
            designer. The most important design error, however, is that the design does not fully support
            some  requirement.  For  example,  some  exception  case  scenario  cannot  be  handled,  or  some
            design constraint has not been satisfied. For design quality, modularity is the main criterion.
            However, since there is a need to validate whether performance requirements can be met by a
            design, efficiency is another key property for which a design is evaluated.
            8.4.1 Metrics

            Here we discuss some of the metrics that can be extracted from a design and that could be
            useful for evaluating the design. We do not discuss the standard metrics of effort or defect that
            are collected (as per the project plan) for project monitoring.
            Size is always a product metric of interest. For size of a design, the total number of modules is
            a commonly used metric. (By using an average size of a module, from this metric the final size
            in LOC can be estimated and compared with project estimates.)
            Another metric of interest is complexity. A possible use of complexity metrics at design time is
            to improve the design by reducing the complexity of the modules that have been found to be
            most complex. This will directly improve the testability and maintainability. We describe some
            of the metrics that have been proposed to quantify the complexity of design. We first discuss
            metrics of function oriented design and then for object oriented design.
            Network Metrics Network metrics is a complexity metric that tries to capture how “good” the
            structure chart is. As coupling of a module increases if it is called by more modules, a good
            structure is considered one that has exactly one caller. That is, the call graph structure is simplest
            if it is a pure tree. The more the structure chart deviates from a tree, the more complex the system.

                                             LOVELY PROFESSIONAL UNIVERSITY                                   171
   172   173   174   175   176   177   178   179   180   181   182