What are User Interface Design and Operation oriented Metrics?

User interface design metrics are fine but above all else, be absolutely sure that your end users like the interface and are comfortable with the interactions required.
- Layout appropriateness is a design metric for human computer interface. The layout entities like graphic icons, text, menus, windows are used to assist the user.
- The cohesion metric for user interface measures the connection of on screen content to other on screen content. UI cohesion is high if data on screen belongs to single major data object. UI cohesion is low if different data are present and related to different data objects.
- The time required to achieve a scenario or operation, recover from an error, text density, number of data or content objects can be measured by direct measures of user interface interaction.

Operation oriented metrics are:
- Operation complexity is computed using complexity metrics because operations should be limited to a specific responsibility.
- Operation size depends on lines of code. As the number of messages sent by
a single operation increases, responsibilities have not been well allocated within a class.
- Average number of parameters per operation is defined as: larger the number of operation parameters, more complex is the relation between objects.

What are the metrics for object oriented design?

A more objective view of the characteristics of design can benefit both an experienced designer and the novice. The characteristics that can be measured when we assess an object oriented design are:

- Size which has four views: population, volume, length and functionality.
- Complexity is measured in terms of structural characteristics by checking how classes of an object oriented design are interrelated.
- Sufficiency is defined as the degree to which an abstraction possesses the features required from the point of view of current application.
- Coupling is defined as different connections between the elements of the object oriented design.
- Completeness is defined as the feature set against which we compare the abstraction or design component. It considers multiple points of view. It indirectly implies the degree to which abstraction or design component can be reused.
- Similarity is defined as the degree to which two or more classes are similar in structure, function, behavior etc.
- Volatility for object oriented design is defined as the likelihood that a change will occur.
- Cohesion is defined as the degree to which the set of properties it possesses is part of problem or design domain.
- Primitiveness is the degree to which the operation is not constructed out of a sequence of other operations within the class.

What are different metrics for testing?

Software testers must rely on analysis, design, and code metrics to guide them in design and execution of test cases. Metrics for testing fall into two broad categories:
- metrics that attempt to predict the likely number of tests required at various testing levels.
- metrics that focus on test coverage for a given component.

Function based metrics use a predictor for overall testing effort. Architectural design metrics provide information on the ease and difficulty which is associated with integration testing.

The metrics defined for object oriented provide a general indication of the amount of testing effort required to exercise an object oriented system. Object oriented testing can be quite complex. Metrics can assist in targeting testing resources at threads, scenarios, and packages of classes that are suspect based on measured characteristics. Design metrics that has direct influence on test-ability of object oriented system include:

- Lack of cohesion in methods (LCOM): Higher the value of LCOM, more states must be tested.
- Percent public and protected (PAP): High value of PAP increases the possibility of side effects among classes because public and protected attributes lead to high coupling.
- Public access to data members (PAD): High value of PAD increases the possibility of side effects among classes.
- Number of root causes (NOR): NOR is the count of distinct class hierarchy described in design model. As NOR increases, testing effort increases.
- Fan-in (FIN): It is an indication of multiple inheritance. If it is greater than 1, a class inherits its attributes and operations from more than one root class.
- Number of children (NOC) and depth of inheritance tree (DIT): The super class methods will have to be retested for each sub class.

What are different component level design metrics?

Component level design focuses on internal workings of software and include measures: cohesion, coupling, and complexity. It helps in judging the quality of a component level design. Once a procedural design is developed, component level design metrics can be applied. It is possible to compute measures of the functional independence, coupling and cohesion of a component and to use these to assess the quality of design.

The cohesiveness of a module can be described by a set of metrics:
- Data slice which is defined as a backward walk that searches for data values that can affect the state of the module.
- Data tokens are variables defined for a module.
- Glue tokens are set of data tokens on data slice.
- Superglue tokens are data tokens common to every data slice in a module.
- Stickiness of glue token is directly proportional to number of data slices it binds.

Coupling metrics is an indication of connectedness of a module to other modules. The metric for module coupling encompasses data and control flow coupling, global coupling and environmental coupling.

Complexity metrics are used to predict critical information about the reliability and maintainability of software systems from automatic analysis of source code. It also provides feedback during software project to help control the design activity. Cyclomatic complexity is the most widely used complexity metric.

What is the framework for product metrics? What are the measurement principles?

A fundamental framework and a set of basic principles for the measurement of product metrics for software should be established. Talking in terms of software engineering:

- Measure provides a quantitative indication of extent, amount, dimension, size of an attribute of a product or process. Measure is established when a single data point has been collected.
- Measurement is an act of determining a measure. Measurement occurs when one or more data points are collected.
- Metric is the quantitative measure of the degree to which a system, component or process possess a given attribute. It relates individual measures in some way.
- Indicator is a metric or combination of metrics providing insight into software process, project or product itself.

There is a need to measure and control software complexity. It should be possible to develop measures of different attributes. These measures and metric can be used as independent indicators of the quality of analysis and design models.

Product metrics assist in evaluation of analysis and design models, gives an indication of the complexity and facilitate design of more effective testing. Steps for an effective measurement process are:
- Formulation which means the derivation of software measures and metrics.
- Collection is the way ti accumulate data required to derive the metrics.
- Analysis is the computation of metrics.
- Interpretation is the evaluation of metrics.
- Feedback is the recommendation derived after interpretation.

Metrics characterization and validation includes:
- Metric should have desirable mathematical properties.
- The value of metric should increase or decrease in the manner in which a software characteristic increases when positive trait occurs or decreases when undesirable traits are encountered.
- Metric should be validated empirically.

What are different types of metrics?

Software Process Metrics are measures which provide information about the performance of the development process itself. The purpose of software process metrics are:
- to provide an indicator to the ultimate quality of software being produced.
- assists to the organization to improve its development process by highlighting the areas of inefficiency or error-prone areas of the process.

Software Product Metrics are measures of some attributes of the software product. The purpose of software product metrics is to assess the quality of the output.

What are most general metrics?

Requirements Management
Metrics Collected:
- requirements by state - accepted, rejected, postponed.
- number of base lined requirements.
- number of requirements modified after base lining.
Derived Metrics:
- Requirements stability Index(RSI)
- Requirements to Design Traceability

Project Management
Testing and Review
Metrics Collected:
- Number of defects found by reviews.
- Number of defects found by testing.
- Number of defects found by client.
- Total number of defects found by reviews.
Derived Metrics:
- Overall review effectiveness (ORE)
- Overall test effectiveness.

Peer Reviews
Metrics Collected:
- KLOC/FP per person hour for preparation.
- KLOC/FP per person hour for review meeting.
- Number of pages/hour reviewed during preparation.
- Average number of defects found by Reviewer during preparation.
- Number of pages/hour reviewed during review meeting.
- Average number of defects found by Reviewer during review meeting.
- Review team size vs defects.
- Review speed vs defects.
- Major defects found during review meeting.
- Defects vs Review Effort.
Derived Metrics:
- Review effectiveness.
- Total number of defects found by reviews for a project.