Principals
Software engineering is based on architecture and design models to provide
visibility, prioritized use-cases to keep development cycles short
and focused, modern programming languages to
map objects from the problem space into the solution space,
and a development process that provides the framework for guiding development activities and reporting
feedback. In general, a modern development process supports the following principals:
- Software increments are released to the customer at regular intervals.
- Only fully tested software (free of any known bugs) may be released.
- The development process is iterative in nature. That is, analysis,
design, implementation, and testing are overlapping
activities.
- Each use-case is traceable to one or more enumerated requirements and visa-versa.
- Each requirement is traceable to one or more areas of the code and visa-versa.
- The architecture clearly identifies interfaces and their contracts,
components and their coupling, subsystems dependencies, and
inter-process mechanisms.
- The architecture is visually modeled and never falls out of sync with the code.
- Each component is delivered with a corresponding suite of automated regression tests.
- All software artifacts (e.g. requirements, models, components, build scripts, unit tests)
are maintained in a change management & version control system.
- A software component checked into version control will automatically trigger a build
of that component.
- The entire system is built and integrated every night and
any resulting errors, and/or warnings are dealt with the next
morning at the highest priority.
In the context of this discussion, an increment refers to a software release which has been built
by iterating as often as necessary over the various work activities in the development cycle in order to
implement a set of use-cases that are free of any known defects. Each incremental release
represents the successful conclusion and delivery of a mini-project. Although an incremental release
at say version 0.3.4 may not do much, it will be rock-solid and contain no surprises. Contrast this with that
of an ad hoc event-driven organization where version 1.0 is normally unstable, full of bugs, and avoided
like the plague.
Depending on the complexity of the domain, an incremental release can require from
four to six weeks
to produce. It is important that a release never exceed the 6-week limit
since each release provides
essential feedback, especially from the customer. With the exception of small projects, it is important
that each release allow a minimum of 4-weeks (20 working days) to develop, otherwise the process will
degenerate into hacking in order to meet the deadline. A 4-week period also provides sufficient time to
allow the release to demonstrate some meaningful capabilities. A healthy project should be able to
establish a 5-week rhythm of releases.
The incremental/iterative process is
the only pragmatic way to develop and maintain software because
it acknowledges that during development discoveries will occur
that require evolutionary changes. For example, assumptions made in the mini-project plan (i.e. the plan
for the current iteration) may prove to be false, a mistake might
exist in a model artifact, or an algorithm may need to modified
to improve performance. However, since a cycle represents a
relatively short time period, incorrect assumptions are detected early
before costly rework is required. Also, knowledge and wisdom
gained from the current release will influence the next release. Frequent
feedback is the key to success.
Professionally managed projects do NOT allow last minute
requirements to enter a development cycle once it has
started since this is not in the best interests of the customer
nor the project. Such requirements must be respectfully noted and
addressed in the next mini-release. A customer who tries to push
a new requirement into a development cycle is like someone who
will not let another person finish speaking before making their
next statement. In conversation such a person would be quickly
admonished, and by analogy so should it be when imposing
last-minute requirements on the development team.
At the conclusion of each release,
risk assessment and customer feedback information is provided to
project management to facilitate the creation of meaningful plans
for the next release. Risk assessment is an essential activity for
identifying the set of use-case scenarios that will drive the
next release. The strategy of implementing the highest risks as early as possible is not always popular with management
at the executive level since risky use-cases usually require more time
and resources and raises the possibility of having to report bad news early
in a project. In most cases the highest risks can be
overcome and closure is eventually reached when all use-case
scenarios are implemented and tested.
Summary
Working
software must be released
to the customer in manageable increments.
Prioritized
use-cases keep development cycles short and focused.
Each
requirement must be traceable to one or more areas of the code
and visa-versa.
Regression
tests and static analysis tools must constantly measure the
quality of the code.
Incremental
release
& iterative development is
the only pragmatic way to develop software.
Frequent
feedback is the key to success.
The
risk assessment activity identifies the use-cases that will drive
the next release.
Allow
a minimum of 4-weeks to develop a release, otherwise the process
will degenerate into hacking in order to meet the deadline.
The
strategy of implementing the highest risks as early as possible
is not always popular with management
Professionally managed projects do NOT allow last minute
requirements to enter a development cycle once it has
started.