Software Development Activities

This is the description of a simple development process put together from the fundamental laws controlling software development. It is not complete, but it describes the core activities that should take place in any software development project, focusing on the creation of an executable system.

Neither of the tree activities described below, requirements capture, requirements formalization and system construction, can be avoided if a software system is to be built. They can be split up and smeared out over several phases, but they still need to be done somehow, sometime.

Always keep in mind that the goal is to create a working system. Make sure all activities generate information that is useful in the execution of the software system.

Make sure you know what the architecture looks like all the time. Use architectural patterns to split up the work in small, manageable pieces.

Use a risk driven, iterative and incremental approach. Release early and often.

The following artefacts will be the main results from the activities below.

• a requirements specification
• an architectural description
• source code
• build scripts that generate a release

These artefacts are usually complemented with other useful documentation.

• component and language descriptions
• user manuals
• installation and configuration instructions

Note that the documents are not tied to a specific phase or activity, but are created and updated throughout the entire project.

You need to have some requirements to be able to build a system. If you do not have any requirements, then you need to employ methods that help you find the requirements. There are several such methods, but none is described here.

An important part of the early requirements work is to find the domain language for the system. Model and describe the terminology used in the system domain. This activity is done together with the customer and experts on the system domain. The domain language is ideal for later implementation in the system construction phase.

The requirements capture can also be done in an incremental manner, but most of the requirements should be specified early. Otherwise it is difficult to plan the architecture and assess technical risks. If only a few requirements can be specified up front, and the rest are left unknown, then perhaps other methods like Extreme Programming are more suitable than this one.

Some people call this activity analysis. The results of analysis are new requrements and a better understanding of the problem. Other people separate analysis and requirements capture, which mostly only confuses the engineer, giving the impression that the same work is to be done twice.

This activity is probably the most important activity of all, and still it is the most overlooked of all activities.

This activity is the most difficult to give a complete an satisfying description of. In the ideal world, we would be able to specify the requirements in one or more formal languages, and then plug the requirements into a framework to be executed. In reality, some of the requirements are suitable for a formal language, but others will be embedded in the architecture, spanning several languages and components.

This means that the activity of formalizing the requirements has two aspects. One is to create the architecture that supports the requirements and the other is to create formal specifications for as many requirements as possible.

Requirements suitable to be described by a formal specification are for example custom data types, file formats, business rules and communication protocols. The specifications are then used as configuration data for the architectural framework and code generators to form the complete system.

Lots of languages exists already for the description of requirements. Use ASN.1 to specify protocols. Use BNF for file formats. Use DTD if you like to store data in XML format. Use IDL when formalizing architectural requirements. Use a data dictionary language for data types. If you can not find a suitable language to use for the specification of your business rules, then create a formal version of the domain language and use that.

The activity to formalize the requirements is very open ended, as the programmer can choose both notation and implementation freely. It is even possible to create new notations that best suits the domain. The programmer is by this given a great opportunity to create elegant, compact and correct code.

This activity is the easiest one to describe. Just implement the architecture that executes the formal requirements. The architecture is also expanded to help you manage complexity, and incorporate the reuse of already existing components.

Each component in the system should be implementable by one or two people, spending up to a couple of months on the task.