Today due to the lack of reliable measure of software design, the software engineers have a difficult choice to make with respect to choosing a particular design. There can be several possible designs for a particular software problem or a particular specification. Software design is a skilful decision making process based on a judgement of the designer. In the current scenario, many software design decisions like the number of modules, interaction between these modules, organisation of the data structures, etc; and these are based on the judgement of the designer and this is a very difficult decisions.

The design metrics should be able to measure the benefits of using a particular method or make a comparative study of several possible design methodologies and enable he software engineer to choose the best amongst these in accordance with his requirement priorities.

For a software design to be simple, the components should be independent and should not have very high degrees of interaction where it can be avoided. Coupling - a measure of independence and cohesiveness - a singleness of a function of a module are two criteria that can be used in design metrics. Coupling is one of attributes of software that have great impact on software quality and there are several methods to quantify the measurement of coupling; these are subjective measures of in the design of the software. It would also be infeasible to use these criteria for large designs.

The goals of software design metrics are to satisfy the following issues:

• The possibilities of predicting the degree of errors in the software being designed.
  
• What is the degree of maintainability that would be needed for a particular software right form its design stage?
  
• What is the degree of difficulty in testing that would be required also the level of testing needed after which it would be possible to decide if the software module is still useful?
  
• The amount of effort needed based on some quantifiable features like number of errors in a module, in developing the software based on a particular design?
  
• The amount of effort needed for testing a software module based on the design features?
  
• Does the design predict the final size of the software based on the design?
  
• Also on the basis of identification of certain outliers using metrics and identify problems in the design.

The use of design metrics based on design structures should allow us to identify the design weakness, which could lead to problems in the implementation phase of a particular design. It should also help in predicting problems in the maintainability of the software that is developed finally on the basis of this design. But design structure metrics will not be taking into account the size of the modules in a software design.

The information flow metric of Henry and Kafura, tries to capture the structural complexity of the system and provide a specific quantitative basis for the design making process. However, this metric is also does not help in accurate prediction of the degree of maintainability and error proneness of a software. Using the length of a component at is design stage itself is a difficult as the designer will not be able to identify this. Also, in this metric if either one of the factors, i.e. fan-in or fan-out is missing then the complexity itself is reduced to zero. This renders the metric useless

The basic definition of software quality is that it should meet some pre determined functional requirements at a specified level of quality. There are a large number of quality factors against which software may be validated. Modularity of a design is the an important criteria for quality software, and metrics that can predict an the best modular structure are necessary.

According to the information flow metric, the main factor determining structural complexity is the degree of connectedness of a module to its environment. It is difficult to make predictions about the software, at the design stage using the level of information flow between components the. Using the outlier analysis looks like a better way of predicting potential problems in the design. However, even here there might be modules that require the unusually high degree of interaction as a result of which they have been identified as outliers.

Design of software is an iterative process that a software engineer will use to make a choice of one design over another. Thus metrics can be used as a basis of making comparisons between the different design solutions, identify outlier modules and thus help the software engineer in coming up with better and more efficient designs.