Software Design Metrics

Prasad Narasimhan – Technical Architect

Software Architecture Anomaly

• Architecture is based on – business & Technical assumptions– Abstracted level of information.– Major Boundaries are only defined– Attributes of the software is set based on

Customer expectations– Precise definition makes it difficult to understand

and change

Software Design Anomaly

• Design is based on – More implementation depended.– Assumptions & Risks are not validated.– Design may not capture architecture details fully– Quality Attributes are not properly captured in

design– Multiple level of diagrams represent different

information should be an expert to understand as a whole

– Business & Technical link may be split.

Software Code Anomaly

• Code is based on – Fully the implementation.– Assumptions & Risks are not fully validated.– Design representation in code is still a concern– Quality Attributes if not properly captured in

design it may not be realized in Architecture– Interpretation of designs from multiple

viewpoints is still an issue.– Business & Technical link may be split.

Software Anomaly

• Software which is created may not match Customer expectations

• The Major issues are identified during acceptance testing phase.

• No Proper Metrics to show the disconnect between Architecture -> Design -> Code.

• There are few set of tools in market which caters to few of the above issues.

Where are we headed

• MDA(Model Driven Architecture) – Realizing code from Design and architecture still need to meet end goal.

• Agile Based Development – Quick Iterative demo based approach solves the expectation mismatch , But still the integrity of Architecture -> Design -> Code is still not there.

Quick Solution

• Agile provides Management level metrics and its discussed on Stand-up meeting. If the Code , Design & Architecture metrics are available which could be discussed on Stand-up meeting. The disconnect can be quickly resolved and it enables easy refactoring of code.