Decision Metrics Matrix Process



Decision Metrics Matrix Process

INTRODUCTION

This lecture will develop a decision metric matrix process using concepts from the Goal-Driven Measurement (Basili) concept more commonly called Goal Question Metric (GQM).

TECHNICAL APPROACH

A software engineering analysis approach will be taken to identify a set of decision parameters and to establish decision criteria. The particular decision analysis tool applied will be titled decision metric matrix.

The decision analysis strategy and the decision matrix in particular was chosen because it identifies software and hardware conditions and suggestions actions to be taken based on the conditions. The decision metric matrix establishes decision criteria based on the actions and incorporates all the condition to form a decision rule. The decision rule is then acted on and implemented to improve the product, process or resources.

The decision metric matrix concept developed for this lecture contains rows and columns that show the decision parameters and associated action statements. The action statements indicate selections to make when certain conditions exist. The matrix also contains action values and weights applied to the action statements. A decision rule is formed from the action values to establish the decision criteria.

To build the decision metric matrix perform the following steps:

1. Establish the decision goal.

2. Determine the most relevant factors to be considered, that is, identify the condition statements for the decision parameters.

3. Determine the most feasible steps or activities that apply to each statement. These form the action statements.

4. Study the combination of action statements for each condition statement. arrange the action statements in an order and assign the action statements an appropriate weight.

5. Fill the internal rows and columns of the matrix with the possible set of action statements.

6. Apply a decision rule with assumptions.

7. Develop indicators using the matrix. Develop plots, tables, graphs etc., to present the result for decision making.

8. Based on the decisions implement the process.

9. Continue to collect (process, product, resource) data in a database for improvement.

|Decision |Decision Criteria |Decision |

|Parameters | |weights |

| |Action Values | |

|Condition |Action Statements |Weight Values |

|Statements | | |

| |Weight Summation |Total Weight |

FIGURE 1 Decision Metrics Matrix

The decision metric matrix form is shown in figure 1 contains: the Decision Parameter title (row 1 and 2, column 1); Condition Statements (rows 3 through m, column 1); the Decision Criteria title (row 1, column2 through n); the Action Values (row 2, column 2 through n); the Decision Weights title (row 1 and 2, column n+1); the Action Statements (row 3 through m-1, columns 2 through n); the Weight Values (rows 3 through m); the Weight Summation (row m+1, columns 2 through n); and the Total Weight (row m+1, column n+1).

The Decision Criteria is the title of the established Goal as determined in step1. The Decision Parameters is the title for the condition statements. The condition statements identify the relevant decision parameters. The Action Statements list, by row and column, a set of events or selections that exist for each condition statement. The action values specify a range of choices and assigned weights that apply to each action statement for the chosen condition. The decision weight column is filled in based on the some of the values chosen from the action statement list.

A decision rule is developed from the decision weight column. An example of a decision is:

where:

n = the number of decision parameters

w = normalization weight factor

d = decision weights.

The decision rule can be shown as an indicator using a plot or graphic. The example decision rule plot is shown in Figure 2. As an assumption the analyst might assume to reject the decision if one or more of the decisions is zero.

Figure 2 Indicator for the Decision Rule

Example Problem Statement

At the Turtle Corporation, existing software systems consisting of millions of lines of code are planned for continued use with maintenance and modifications in projects that will span the next decade. The software systems and tool sets, under configuration control, are proven, reliable and operable. For Turtle, it would appear cost effective to recover as many of these software systems as possible. Since the new Language Faster Better Cheaper FBC has been mandated by the Department of Programming Emeritus (DOPE) as the future language and due to FBC's portability and life cycle cost reduction, it is being considered as a language for modification to existing software systems.

The Goal

The Goal of the Turtle Co. is to investigate the feasibility of using FBC and newly developed FBC modules in the existing software environments. An existing group of software environments will be identified. From these environments a decision criteria for implementing FBC code in the existing environment will be determined.

DECISION METRICS MATRIX

A software engineering analysis methodology using a decision metrics matrix process was developed. To construct the matrix software environments (product, process, resources) were identified for improvement. Experts from each environment were interviewed using the one on one interview concept ( ). Questionnaires were developed for users in the different environments and distributed where onsite inspections were not possible. Using the results of the interviews and questionnaires the following information was gathered. A set of twelve condition statements for the decision parameters was established. For each condition statements, three action statements were defined from the results of the interview and questionnaires. For each group of action statements, action values were defined with an associated weight. Using the condition statements, action values and action statements the decision metrics matrix was developed.

The condition statements used for the decision parameters were:

1. Validated compiler

2. Coupling and Cohesion

3. Real Time Environment

4. Life Critical Software

5. Existing Tool Set

6. Software Life Cycle

7. Independent Software Modifications

8. Reusability

9. Training

10. Interface Mechanisms

11. Language Features

12. Cost Considerations

Each condition statement is further dissected to expand into the action statements. Then the action statements are evaluate, clarify and assigned a measurement for its potential contribution to the action values. The action values are then used to establish the indicators for the decision rule.

1. Validated compiler

A major concern was the existence of a validated Language FBC compiler to produce target code. Several validated Language FBC compilers now exist that will allow formatting and transferring Language FBC program files from a host computer to a target compatible computer. This will not be a future concern due to the effort being expended by software vendors, however it must be researched.

2. Coupling and Cohesion

The coupling and cohesion was a concern to the existing software environment. Language FBC with its strong typing, abstraction, generic definitions and separate compilation will simplify the previous problems encountered with module cohesion and modules coupled by common or global variables. Coupling is defined here as a measure of the strength of interconnection between one module and another. Common environment coupling is when two or more modules interact with a common data environment.

Cohesion is the degree of functional relatedness of processing elements within a single module. There are seven levels of cohesion. The seven levels are coincidental, logical, temporal, procedural, communicational, sequential and functional. For existing software modules that are highly coupled it will be difficult to integrate new Language FBC modules. Also, if the existing software has no identifiable cohesive form, integrating a Language FBC module would not be practical.

3. Real Time Environment

In a real time environment analysis must be performed on the Language FBC compiled code to determine if the compiled code would degrade the efficiency of the computer. The following equation could be used:

Cm X Ce + E < 100% U

Where:

Cm Current machine utilization as a percent the machine is utilized for non-Language X

Ce Compiler efficiency, a factor computed between Language FBC and non-Language X

E Percent of CPU required for future expansion

U Central processing unit utilization

4. Life Critical Software

Even though validated Language FBC compilers exist the validation process does not prove the reliability of the compiler. The compiler could compile code that contains faults that go undetected during testing. Therefore, for life critical software environments the decision to use Language FBC should be based on its past performance.

5. Existing Tool Set

Careful consideration must be given to the adaptability of the existing tool sets or a transition to Language FBC tools before making the decision to implement Language FBC. There are three categories of tool sets most vendors have or will be developing. The three sets are data base control, application and target development tools.

The Data Base Control Tools are divided into three areas, the Data Base Manager (DBM), the Configuration Control Management (CCM), and the Librarian. The DBM predefines data base primitives and allows definition of user primitives. It also provides services for creating, accessing, modifying, relating, and deleting all Language FBC development environment (FBCE) data base objectives. The CCM provides control over the manipulation of FBCE data base objects, including archiving and revision control services. The Librarian is responsible for controlling the logical grouping of objects comprising Language FBC library units and subunits, as well as controlling access to those objects.

Application development tools include the Editor, Formatter, Pretty Printer, File Maintainer, and Debugger. The Editor is used by programmers to enter Language FBC source text, as well as other textual materials; it must be capable of Language FBC-indenting and format control. The Formatter processes text files and reformats them into documentation files. The Pretty Printer prints Language FBC programs in a logical Language FBC format and highlights Language FBC reserve words, etc. The File Maintainer allows comparisons of object programs; text files and typeless files can each be compared. The Debugger provides a symbolic debugging facility to aid in testing Language FBC application programs.

Target development tools are configured to support specific target machines. The tools include the Language FBC compilers themselves, Runtime Support Packages, Assemblers, Object Importers, Linkers, and Exporters. The Language FBC compilers with unique code generators will (eventually) be available for target CPU's. A unique Runtime Support Package must be supplied for each target environment. Each target also requires its own Assembler. The assembler must be available as a cross development tool also.

The Object Importer is used to bring into the Language FBC development environment binary modules produced by other languages. FORTRAN 2000 is probably the only language considered at this time. The Linker combines Language FBC -binary with Libraries and Runtime Support Packages to create Language FBC Program Files. The Exporter tools are responsible for formatting and transferring Language FBC Program Files from the host environment to the target environment.

There is no standard library packages defined for Language FBC other than those given in the FBC language reference manual. Predefined packages must be supplied for standard math functions, statistical packages and common abstract data types. Special standard math packages will be required for particular applications similar to scientific subroutine packages. For avionics applications matrix and quaternion math routines will need to be developed.

I/O packages are provided by means of predefined FBC packages. The generic packages SEQUENTIAL_IO and DIRECT_IO define I/O operations applicable to files containing elements of a given type. Text I/O is supplied in the package TEXT_IO. The package IO_EXCEPTIONS defines the exceptions needed by the above three packages. A package LOW-LEVEL-IO is provided for direct control of peripheral devices.

6. Software Life Cycle

For existing software systems, the remaining software life cycle must be considered. Large software systems, with no foreseeable need to upgrade, should be left intact and maintained until they become obsolete and can be phased out. Language FBC should be considered when the additional cost to implement in Language FBC is less than the life cycle cost savings over the remainder of an existing project.

7. Independent Software Modifications

Software for large systems is continuously changing due to design changes either in hardware or software. For independent software modifications, Language FBC permits program units to be subdivided into units that can be modified, coded, checked out, integrated and documented [3]. The Language FBC software modifications must conform to the basic program units independent of the software in the system. Otherwise further consideration must be given to the logical grouping and the hierarchical compilation.

8. Reusability

When a software package has a high potential for reusability beyond the current project, it is a candidate for Language FBC, even though it might not be cost efficient on the current project. This becomes a cost saving factor realized on future projects due to DOD's commitment, the language's portability and maintainability.

9. Training

Since Language FBC is the language of the future, it will be cost effective to train in Language FBC. The initial implementation of Language FBC will require a substantial investment in training. This is due to Language FBC's programming language strength, potential as a development tool, and its maintenance requirements. Personnel should be trained at levels compatible with their level of involvement. Five possible levels are for managers, support personnel, basic, intermediate and system software engineers.

10. Interface Mechanisms

The Language FBC vendors have developed object importers to import non-Language FBC code into Language FBC. Very few have provided for Language FBC to be called by other languages, handle exceptions and share data with non-Language FBC code through parameter argument calls, global variables or common blocks. One vendor, Dig Equipment Company, using MVS operating system, has provided these capabilities. The DEC Language FBC conforms to the calling standards, which provides the ability to call and be called by code written in other languages. DEC Language FBC is also able to handle exceptions from non-Language FBC code, generate exceptions to be handled by non-Language FBC code, and share data with non-Language FBC code through global variables and common blocks.

TeleFBC, another Language FBC vendor, supplies a system interface program. The program allows an experienced programmer to interface between TeleFBC Language FBC and another language based on the DEC operating system. Special modifications must be made to the interface routine. The routine must be recompiled and linked with the assembler run time support package.

The decision to develop a module in Language FBC must be based on the host and target computer, the operating system and the Language FBC compiler vendor. In all probability a system level interface mechanism will have to be developed.

11. Language Features

Two important issues concerning necessary or desired language features are programming methodology and software engineering. Programming methodology is concerned with the structured programming, program verification, information hiding and hardware representation. Software engineering is concerned with the issue of large system construction and maintenance. Language FBC was designed to support and incorporate both of these issues.

12. Cost Considerations

The decision criteria. called cost considerations includes software design specifications, coding specifications, software testing, software design review, software configuration control and deliverable documentation.

The software design specification should address the use of Language FBC as a programming design language (PDL), the best way to package systems and subsystems and guidelines for module composition.

Coding specifications and coding style guides will be required to insure that the delivered code is readable and maintainable.

Software testing becomes a factor since Language FBC encourages separate module development, compilation and independent testing. The module, package, subsystem and system level software test hierarchy becomes a time phase factor for integrated testing.

Software design reviews will require engineers to be knowledgeable in Language FBC so they can analyze code specifications for their area of expertise.

As compilers are upgraded the question of placing software under configuration control becomes important. Criteria must be established to determine when a compiler and a Language FBC tool set are sufficient to begin full-scale development.

Well-written Language FBC code will not in all likelihood meets deliverable documentation standards. Therefore the questions left unanswered are what additional documentation will be required and will module packaging provide a system overview of systems and subsystems.

PROTOTYPE DECISION MATRIC MATRIX

Using the twelve conditions statements and the three columns of action statements, prototype FBC Decision Metrics Matrix was developed. Figure 3 Prototype Decision Metrics Matrix is an example set of decision weights was applied to the matrix to show how decision criteria would evolve. Applying the decision rule, the value .66 indicates FBC is the acceptable choice. A future study will be investigated to validate the prototype matrix using the original software experts. Their independent responses will be combined to justify a decision.

|Decision |Decision Criteria |Decision |

|Parameters | |weights |

| |Very Strong |Strong |Good |Fair |Weak |Reject | |

| |10 |9 |8 |7 |6 |5 |4 |3 |2 |1 |0 |0 | |

|1. Validated |a1,1 |a1,2 |a1,3 |9 |

|compiler | | | | |

|2. Coupling and |a2,1 |a2,2 |a2,3 |5 |

|Cohesion | | | | |

|3. Real Time |a3,1 |a3,2 |a3,3 |5 |

|Environment | | | | |

|4. Life Critical |a4,1 |a4,2 |a4,3 |4 |

|Software | | | | |

|5. Existing Tool |a5,1 |a5,2 |a5,3 |4 |

|Set | | | | |

|6. Software Life |a6,1 |a6.2 |a6,3 |5 |

|Cycle | | | | |

|7. Independent |a7,1 |a7,2 |a7,3 |7 |

|Software | | | | |

|Modifications | | | | |

|8. Reusability |a8,1 |a8,2 |a8,3 |9 |

|9. Training |a9,1 |a9,2 |a9,3 |7 |

|10. Interface |a10,1 |a10,2 |a10,3 |8 |

|Mechanisms | | | | |

|11. Language |a11,1 |a11,2 |a11,3 |8 |

|Features | | | | |

|12. Cost |a12,1 |a12,2 |a12,3 |8 |

|Considerations | | | | |

| |Weight Summation |79 |

Figure 3 Prototype Decision Metrics Matrix

Where:

a1,1 Compiler exists for Host and Target computer. Both operating systems and software are compatible.

a2,1 Module easily decoupled from global common or databases. Module cohesive and components identifiable.

a3,1 Compiled code is efficient, runs in real-time on target computer and allows for expansion

a4,1 Past performance has proven the compiled code to be fault free.

a5,1 The following tool sets exist: Data base control, application development, target development

a6,1 Additional cost to implement is less than life cycle cost saving over remainder of existing project.

a7,1 Modification divide into program units for coding, checkout, integration and documentation

a8,1 reusable beyond current project

a9,1 Adequate resources available projects life cycle justifies training effort

a10,1 Select computer, compiler and operating system have interface mechanisms

a11,1 Supports both programming methodology and software engineering methodology

a12,1 Cost consideration in these areas are minor impact.

a1,2 Compiler exists for target computer and host however both are not compatible

a2,2 Coupling and cohesion of modules can be resolved with modifications

a3,2 Compiled code efficient on host is compatible with target but is not efficient doesn't allow for expansion.

a4,2 The compiled code is still in a test and checkout phase. Two years validation critical.

a5,2 Some of the tool set are in place or are under development

a6,2 Implementation and LCC saving are equivalent

a7,2 Modifications require improvising to be devisable into program units

a8,2 Software might be reusable but has not been identified

a9,2 Limited resources available to train a number of key individuals for project

a10,2 Interface mechanisms can be developed or work arounds established

a11,2 Need either programming methodology or software engineering

a12,2 These conditions are marginal impacts

a1,3 Compiler not validated for either target or host computer

a2,3 Existing software highly coupled or modules are not cohesive

a3,3 Compiled code runs on host but is not target efficient

a4,3 The compiled code has not been fully tested or was tested and is not reliable.

a5,3 The tool sets have been identified and some exist or are planned

a6,3 Cost to implement is greater than LCC saving for remainder of existing project

a7,3 Modifications are very difficult to integrate part of into existing program units

a8,3 Software will not be reused

a9,3 Project life cycle is short and resources not available

a10,3 No provisions available for interfacing

a11,3 Language features not supported

a12,3 Major impact and could restrict implementation

CONCLUSION

This lecture investigated the feasibility of using FBC. A software engineering analysis approach was taken to develop decision criteria. An FBC decision metrics matrix and decision rule was developed. The FBC decision metrics matrix relates conditions, which are the decision parameters, and actions to establish a decision rule. The decision rule incorporates all the conditions that must be satisfied for a related set of actions. The lecture also exposes the need for FBC interface or linkage mechanisms as one of the decision parameters.

References

Basili, V. R., C. Caldiera, H.D. Rombach, "Goal Question Metric Paradigm", Encyclopedia of Software Engineering, Volume 1, John Wiley & Sons, 1994.

Kendall, Kenneth E., and Kendall, Julie E, Systems Analysis and Design, Prentice-Hall, 1992, Chapter 5.

-----------------------

[pic]

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download