Analyzing the Development Process

Introduction

A development process models the activities required to move an idea from concept to product. Anyone who has been in the engineering field long enough is familiar with the fundamental processes of product development.
 

The Waterfall Model

Most engineers are familiar with the so called waterfall model of development. In this model it is expected that the processes listed above are executed sequentially. For example, the requirements are gathered into a document that specifies the product, an anaylisis document is produced that describes the problem to be solved, a design is produced from the analysis docuement, an implementation is produced from the design docuement, and finally the implementation is tested to ensure that it meets the requirements of the specification.

While the waterfall model is a convenient mapping for traditional project tracking, it is an overly simplified model of the actual process. As the stages of development progress, more and more detail is exposed, and enevitably issues are uncovered that affect earlier process stages. The result is that if one expects earlier stages (e.g. Specification/Requirements) to be completed before later stages (e.g. Design), or for the later stages to be not begin untiil earlier stages complete, several things can happen.
 


Thus, the expectations of the waterfall model are not only unrealistic, but they are counter productive. As we will see, the development process is iterative rather than sequential.
 

The Iterative Model

The iterative development model is an acknowledgment of reality. Each stage in the development process is dependent not only upon the preceeding stage, but also on the realities of the subsequent stages.

For example, if it a feature is discovered to be technologically infeasible in the analysis, design or implementation phase, then there is no need to have a detailed specification of its user interface. Factors such as: component availability; development cost; and technical feasibility, can cause changes in development statges that traditionally occur earlier in the development cycle.

Among the realities that have a feedback effect on the development process are those concerned with effeciencies. For example, is it more effecient to completely specify a product before performing any analysis? Or is it more effecient to completely design a product before attempting any implementation?

These days almost everyone is conceptually familiar with the benefits of performing activities in parallel rather than sequentially.

System Development

While Hypothesis is focused primarily on embedded systems software development, embedded systems involve much more than just the software. Systems are a combination of various elements, and it is important that all the disciplines reflected components of the system participate in the design of the system.

One of the most frustrating experiences for an embedded software developer is to be faced with the task of writing the software for a hardware platform designed without input from software developers.  Unfortunately, this situation is encountered all too frequently. The Hardware Design Pattern document proposes solutions to some of the more common issues in this vein. It is important for experienced embedded software developers to get involved in the system design.

Development Activities

Specification

This activity involves documenting the expected behavior of the system at its boundaries. The result is the definition of what the system must do to be successful. Unfortunately, it is often an o

Analysis

Design

Implementation

Verification

 

 
 
 
 
 
 
 
 
 
 
 

The following is a list of typical operations that are performed by a software engineer:


mike@mnmoran.org