2 Overview Development Process

The main focus of these guidelines is the implementation process. The following sub chapters give an overview and some recommendations for the development process with a small team. For bigger teams, separate documentation for the development process (and other procedures) needs to be added.

Visio would be a good tool to support the development process. It is integrated into Visual Studio .Net. Unfortunately, my trials have shown that the integration doesn抰 go far enough. It is possible to design some objects in Visio and create code for it, bur changing the generated code doesn抰 update the diagrams properly. After some time the diagrams don抰 reflect the implementation anymore ! If a tool is needed just for design but not code generation and documentation, Visio Should be able to do the job.

2.1 Requirement Phase

The requirement specification might be produced by the IT team, but the input comes from the business users. It抯 important that the scope of the project is clearly defined at project start. Good tools to collect user requirements are use cases.

2.2 Analysis & Design

If the project is not big enough to allow for an architecture team, it抯 usually best if the objects are modeled in the database. The database schemas are based on actual code and are easily understood by the developers. It can even be used to automatically generate strongly typed datasets, .NET抯 preferred class to handle business data.

Of course additional design documents might be need like:

• Storyboard showing the flow between different screens and their content

• State diagrams for complicate objects

2.3 Implementation

The implementation is described in detail in the following chapters.

2.4 Test Procedures

One of the most important implementation activities for a successful project and for easy maintenance is testing. Unfortunately, proper testing is also often neglected. Writing test code takes time, but doesn抰 add any functionality to the system. If a developer is under time pressure to deliver, it is tempting for him to do just some ad hoc testing instead of writing proper test procedures. However, having no test code will lead later to serious problems, because it is not easy possible to verify that future changes will not break existing code. Missing testing can even lead to the total failure of the project !

This chapter describes quite a number of tests. The idea is to catch errors early. If the developer catches an error himself, he might spend minutes. If the error is caught during code review, hours are needed to detect and correct it. During User Acceptance Test, easily man-days might be needed because of the number of people involved. But should an error slip through all the tests, it might never be found and lead to an unstable, unreliable system.

2.4.1 Individual Test

Each developer has to test himself that his code runs properly. He creates test code, which can be run as part of the integration test.

2.4.2 Peer Review

The peer review gives the developer the chance to discuss his code and catch errors early in the project. It also ensures that at least 2 persons have a thorough understanding of all code. It consists of code review, single stepping through test procedures and using of actual code.

2.4.3 Integration Test

In regular intervals (approximately every second week), all modules are compiled together, all test scripts run. That抯 the time to test newly added functionality from the user interface through all layers down to the database.

2.4.4 Project Cycles

Usually the activities analysis/design => implementation => test are performed in cycles. It is more manageable to tackle small problems at a time. This gives also an early feedback how fast the project is progressing.

2.4.5 User Acceptance Test

Once all modules are implemented and tested, alpha users of the production system test together with developers the new system / release by performing the activities defined in the use cases during requirement specifications. Problems found in a first round of testing have to be tested again in a second round.

2.4.6 Release Test

Once everybody agrees that the code is ready to be used, the last test in the development environment is performed, the Release Test. The environment should mirror as closely as possible the production system. Data is copied from the current production system and scripts are run to upgrade the system automatically.

2.5 Deployment

Once the Release Test runs without errors, the debugged code can be ported to the production server. Even most activities run automatically, it takes time to perform the deployment and testing (!) properly. During that time, the production system is not available.

Chapters Overview