Analyzing Requirements and Defining Microsoft.NET Solution Architectures, Part XI...

Creating Standards and Processes (Part B)

By: Chris Sully Date: August 30, 2005

Introduction

The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so it is following Microsoft’s recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.

We’ve looked at the following thus far:

Article I: phase 1 of the process, the envisioning phase.

Article II: started on phase 2 (gathering and analysing requirements) focussing on business requirements.

Article III: continued with phase 2, focussing on user requirements and issues surrounding globalisation and localisation of your application.

Article IV: finished off phase 2, focussing on operational and infrastructure requirements

Article V: phase 3, developing specifications.

Article VI: phase 4, creating the conceptual design.

Article VII: phase 5, creating the logical design (application architecture).

Article VIII: phase 5, creating the logical design (logical data model)

Article IX: phase 6, creating the physical design.

Article X: phase 6, creating the physical design (deployment and maintenance).

In the last two articles in the series we consider a subject that applies to all phases of the project development lifecycle, looking at the key area of standards and processes.

Establishing standards for the team we've left until the final topic but it is not the last chronologically; in fact it should be one of the first. Standards define the 'minimally acceptable' practices that the team has agreed on. Processes define how you are to get from the project inception to project completion with the least risk and the highest quality.

A key issue is that the whole team must follow the agreed standards or processes or the project will be compromised. These standards should be best practice standards ... just because they are agreed standards doesn't automatically make them any good or more likely to lead to a quality solution! The standards themselves must be good.

In these last two articles we'll consider some of the key areas where standards are important.

In the last two articles in the series we're considering a subject that applies to all phases of the project development lifecycle, looking at the key area of standards and processes. This consideration we'll now continue.

Code review Standards

You may want to enforce a policy of checking though the code with another person against published project standards, maintaining an issue log until all issues have been resolved.

FxCop is an automated tool for reviewing code against the Microsoft published standards.

UI

You should have a document laying out the standards, down to the font/ colour scheme level, how user prompts should be formatted, etc. A few areas for consideration:

• Most large teams have a usability group (or person) with the main responsibility of ensuring that the final product conforms to the agreed-on standard.
• Consider accessibility!
• For international applications localisation and multi-language consideration should be a part of your standards document.

Testing

See later but in terms of standards:

• Use your use cases to generate your test plans.
• Write your test plan before you complete the code; even better don't let coders write the test plan!
• Test at each stage.
• Make your test environment as real as you can.

Establishing processes for the team

Here's what Microsoft recommends at a minimum:

Testing

A partial list of the various stages a typical process might enforce:

• Code coverage – test every single line of code.
• Unit – functionality testing at the lowest level; a test at the class, module, or method level, testing the inputs and outputs.
• Build validation – a short test of the application should be made after each build to ensure the general integrity of all components.
• Assembly/ regression – a fuller version of the build test. All areas of the application are tested for base functionality to see whether any new defects have been injected and to ensure that the necessary fixes/ enhancements are there without breaking other areas.
• QA – testing in an environment as close to real life as possible.
• Performance/ load.
• User acceptance – ensures that the solution's business goals are met upfront.
• Pilot.

Documentation Review

All key documents (deliverables) should be reviewed before being flagged as complete or submitted for sign off. This is especially true of the technical design documents created from the planning phase of your project.

Code review

Code should be reviewed before it gets moved into the 'production' area of VSS (or wherever you are keeping your code scheduled for the next build). All open issues discovered in code reviews should be resolved and signed off before the code is moved forward in the process. VSS security can be useful for facilitating this process.

Build

In some situations daily builds are appropriate. In others, builds on an ad hoc basis are more effective. After a build is a good time to do a quick assembly test before the compiled code finds its way onto too many machines. Generally the more frequent the build the better the chance of building quality software. Using automated build tools, bought or built, is likely to be a good idea on all but the smallest of projects.

The build itself should be carried out on a 'clean' machine. The pre-build process should be followed: the developer should make the changes and unit test; the code should then be stored in a holding area of VSS for review; when approved for release it should then be promoted in the VSS production area, from where the builder or build tool retrieves.

Issue Tracking

A good system for tracking bugs/ defects and enhancements is essential. Bugs should be prioritised according to their impact on users. Each bug is effectively a mini-project in itself, going through the various stages of envisioning, planning, building and testing.

Source code management

This is often achieved via VSS. It is essential that two (or more) people cannot checkout code for editing at one time. To avoid delays due to this modularisation should be employed.

Change management

If a change in scope is required for technical or business reasons change management is required. All parties meet to discuss the ramifications of changing scope. The impact, usually one or more of spending more money, extending the deadline, or taking a risk must be understood and agreed by all. Good practice is to have stake holders sign off on all change management requests.

Release management

Logistics: what goes where and when. It may be, for example, that OSs need upgrading before the new application can be deployed.

Maintenance

Typically the application will require maintenance as long as users continue to use it. Files get corrupted, hard drives fail, new software on a machine breaks old software, etc. So a process should be in place for maintaining an application.

Enterprise Templates

Enterprise templates are a way of capturing best practices and making them readily available to the entire development team. You can include items such as pre-written code structure and patterns and locking down IDE features that are not required. This gives you a way of enforcing standards and processes.

Microsoft divides the functionality of Enterprise templates into the following:

• Application structure – code markers, file structure etc.
• Policy – excluded items, e.g. menu items
• Guidance

Measuring Quality

Project control metrics

This is basically use of a scheduling tool such as Microsoft Project, verifying that you are conforming to two of the three variables in the success equation: deadlines and cost. You are dealing with actuals against forecast. Good project control gives you advanced warning of when matters might be getting off track.

Organisational performance metrics

Various metrics can be chosen. One might be 'severity 1 defects after release' with severity one meaning the application crashed/ became unusable.

Return on investment metrics

ROI is basically benefits over cost. Benefits usually come down to money, so this becomes additional revenue generated via the solution over the cost of implementing it.

Final Summary

That's our whistle stop tour through Analyzing Requirements and Defining Microsoft .NET Solution Architectures completed. I hope the series of articles has proved useful. If there is any topic that has left you wanting more, and I'm well aware we've covered some topics in scant detail by necessity, please drop me an e-mail at dotnetjohn@sullyc.plus.com.

Let's have a quick final review of what we've covered and place in a little context.

Most recently we looked at standards and processes which are important in all phases of the project lifecycle. The phases we looked at are:

1. Envisioning the Solution
2. Gathering and Analyzing Business Requirements including
   1. User requirements
   2. Infrastructure requirements
3. Developing Specifications
4. Creating the Conceptual Design
5. Creating the Logical Design including
   1. creating the logical data model
6. Creating the Physical Design including
   1. deployment and maintenance

Finally, I just want to clarify the distinction between phases 3 through 6 by placing them in the context of the Microsoft Solution Framework (MSF) as well as tieing in a few more concepts, including the use of UML models.

The MSF Process Model consists of five distinct phases:

• Envisioning
• Planning
• Developing
• Stabilizing
• Deploying

Note these are not sequential activities in MSF but parallel, iterative activities with later activities feeding knowledge to the earlier as well as vice versa.

How do the MSF phases map to the 'phases' as we introduced them:

• Envisioning
• Envisioning the Solution
• Planning
• During the planning phase, you create a collection of models and requirements documents, thus planning includes:
• Gathering and Analyzing Requirements
• Developing Specifications
• Creating the Conceptual Design
• Creating the Logical Design
• Creating the Physical Design
• Developing
• Stabilizing
• Deploying

Thus you can see basically almost all we have covered belongs to the planning phase of MSF. The three design steps can be considered as follows:

Considering the remaining steps:

• Developing should follow directly from the physical design.
• Stabilizing: is primarily stabilizing the quality of the solution via testing.
• Deploying: the final deployment.

References

Exam Cram 2 .NET Solution Architectures
Cornish et al.
Que

70-300 Analyzing Requirements and Defining .NET Solution Architectures
Microsoft

http://msdn.microsoft.com/architecture/