Analyzing the Development Process
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
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.
The early stages remain incomplete until the project is complete.
The project schedule becomes inaccurate.
The stage documentation (e.g. Analysis Document) becomes obsolete.
[add your favorite fiasco here]
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.
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.
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
The following is a list of typical operations that are performed by
a software engineer:
Analyze the Problem
Identify the problem scope by identifying all interfaces.
Characterize the interfaces.
Identify problem domain objects.
Characterize the roles of the problem domain objects.
Identify relationships between the problem domain objects.
Classify data flows at interfaces and intra-faces.
Lather, rinse, repeat.
Design a (partial) Solution
Implement/Code the Solution
Build the executable
Test the solution
Add files to repository
Move files in the repository
Delete files from the repository
Check-out files from repository
Check-in changed files to repository
Resolve repository merging confilicts