Metrics and ALM Assessment for Architecture, Analysis and Design
This chapter will cover the metrics and assessment questions for the architecture, analysis, and design areas in ALM. Let us start with the metrics and see what we can get there.
There are not many metrics in TFS that we can use for KPI assessment for architecture, but we can use some taken from the development area. Using the code metrics, we can get information on how our architecture and design really are working, including:
- Lines of code. This is an approximate number based on IL code. A high count might indicate that a type or method is doing too much work and should be split up. This might also be a warning that code will be hard to maintain.
- Class coupling. Measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Strive for low coupling; high coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types.
- Depth of inheritance indicates the number of class definitions that extend to the root of the class hierarchy. The deeper the hierarchy, the more difficult it might be to understand where particular methods and fields are defined and/or redefined.
- Cyclomatic complexity is created by calculating the number of different code paths in the flow of the program and shows the complexity of the code. A high complexity makes the maintainability suffer, and it can also be hard to get good code coverage.
- Maintainability index is an index value between 0 and 100 that represents the relative ease of maintaining the code. The higher the better: A rating above 19 is good. Below that, maintainability suffers.
Using the architecture explorer, we can create dependency graphs (see Chapter 12) instead. Running analyzers on these graphs will give us useful information as well:
- Circular Reference, which will identify nodes that have circular dependencies on one another.
- Find hubs, which will identify nodes that are in the top 25 percent of highly-connected nodes
- Unreferenced nodes, which will identify nodes that have no references from any other nodes.
Using these analyzers, we can see if we have loops or circular dependencies so that we can simplify them or maybe break the cycles. We also can see if we have too many dependencies, which could be a sign that they are performing too many functions. In order to make the code easier to maintain, test, change, and maybe reuse, we need to look into whether we need to refactor these code areas to make them more defined. Maybe we can also find code that performs similar functionality and merge with this. If the code has no dependencies at all, we should reconsider keeping it.
Standard Reports
Unfortunately, there are no built-in reports that we can use for architecture analysis and design.
Assessment
To help us evaluate an organization’s maturity in different ALM areas, Microsoft developed its ALM assessments, which we discussed in Chapter 4. Based on the assessment score, we received a maturity level for a specific area that we can use in evaluating in which direction to take our ALM efforts.
Based on the score, we can help the organization reach the maturity level it needs for these areas. Table 14-1 lists questions that can be used as a basis for an ALM Assessment in the architecture, analysis, and design phase. The online assessment has very few questions covering this area, so you might want to use some of your own.
Table 14-1. Assessment questions for architecture, analysis, and design phase
| Area | Sample question | Discussion |
|---|---|---|
| Architecture Framework | Does architecture definition follow a formal process? | |
| Are there tools for documenting and sharing architecture models? | Using the features of TFS will help customers who don’t have good tooling for this. All architecture tools will help in this area. | |
| Is the architecture well documented? | Using the features of TFS will help customers who don’t have good tooling for this. All architecture tools will help in this area. | |
| Do major architectural decisions follow a defined process? | ||
| Analysis & Design | Do all team members have access to the design diagrams? | Using the features of TFS will help the customers who don’t have good tooling for this. All architecture tools will help in this area. |
| Are the diagrams updated throughout the project lifecycle? | In TFS, there is a flow back and forth between code and diagrams. | |
| Are these diagrams stored and version controlled? | Of course they are, in TFS. | |
| Is forward/backward engineering performed between the code and the diagrams? | In TFS, there is a flow back and forth between code and diagrams. | |
| If using UML, are Sequence Diagrams created? | Can be created easily in TFS. | |
| If using UML, are State Diagrams created? | Can be created easily in TFS. | |
| Database Modeling | Do you use formal modeling methodologies? | |
| Is your database being documented? |
Summary
As we have seen in this chapter, we have only a few metrics that we can use for KPI analysis for the architecture and design area.
From an assessment point of view, the online assessment offers questions directed at this area that focus on establishing practices around the design and architecture process.
Let us now see what TFS 2012 offers in the area of developer practices.