We have looked at the model and the methodology. Now we bring it all
together into a development process.
The process is what controls the development. We need to control the quality
of the system, the changes that can be made to the system, and the progress
in developing the system. The fourth pillar for managing a project is
knowledge distribution.
Change Control
The fundamental tool for managing change is the version control system. I am
amazed at how often I find projects that have not even this.
However, change control goes beyond what version control systems can provide.
You must be able to constrain the development to what is necessary to satisfy
the requirements. How you do this will depend on the project - it could be
nothing more than some guidelines in a document - or it might be a system that
prevents access to the code base without explicit authorisation, teamed with
a gate keeper that only allows changes to be merged in once they have been
thoroughly tested and reviewed.
A comprehensive test suite can be of great benefit in managing changes. One of
the impediments to applying a change is not knowing if it will break some
existing component. If you can run the test suite after applying the change
you can tell immediately if it has introduced a defect. The test suite thus
gives you the freedom to attempt to introduce more complex changes.
As well as changes to the code base, you will also need to manage changes to
the requirements. Once the users see the product they will start to
request changes. This may be because they can see that some of the COTS products
have more capability than they originally expected, or because the product allows
for new capabilities for the business.
The incremental development model allows us to manage the changes to requirements
in a controlled manner. At the start of each increment we should schedule a
short analysis task to consider how any new requirements might influence the
design. These requirements can then be scheduled into future increments, allowing
the product to evolve to meet the business needs.
In order to keep things under control you will need to keep a register of
change requests where you track how each one is progressing through the
development cycle. I find that an increment plan which describes what is going
to be done in future development cycles (and any dependencies) is a useful
device for explaining the long term development strategy.
Quality Control
The quality of a system has many aspects. The most important is functionality -
the system does need to do what it was required to do, but there are many, many
others. In the literature I have found over 130 terms used to describe some form
of quality attribute.
Quality Measurement
The first step to controlling something is to be able to measure it. There are
a few ways to measure the quality of a software system:
Code reviews can be a source of data for measuring the quality of the system.
A simple count of the noted defects (perhaps grouped by severity) will give a
guide to how well things are going.
Test harnesses are another source of quality data. The unit tests should provide
a report detailing the number of tests run, and the number of failures found.
Of course these are mostly aimed at the functionality of the system.
In order to test the non-functional quality requirements there needs to be a
set of tests designed to evaluate how well they are satisfied. For some
requirements this can be as simple as measuring the resource footprint, but
others will require more sophisticated tests, and others are so subjective as
to be close to untestable.
Actions
The spiral development model enables us to get the quality of the system under
our control. By deliberately starting with a lower quality product we can still
deliver much of the required functionality early in the process. We can then
make decisions about the best way of improving the quality of the product
and apply them, one by one, until the desired quality performance is met.
Progress Control
The aim of progress control is to deliver a system that satisfies the requirements
within the budget allocated to the project.
The first step is to determine what the budget actually is, and that involves
estimating the size of the project, based on little more than the initial
analysis and perhaps a feasibility study. Obviously, as the development unfolds
it gets easier to develop an accurate estimate, but this is often long after
any funding arrangements have been made.
Measuring the progress is the usual project management task of plotting the tasks
in a project management tool (such as MS Project) and keeping track of how much of
each one has been completed. Finer measurements, such as counting lines of code
can be used, but might be compromised if they are susceptible to tampering.
The iterative aspects of the modern development models can be an issue with
these project management tools. You need to add extra tasks for supporting
the subsequent tasks - for example there will need to be two implementation
tasks, one to create the code, and a second to fix the bugs found by the
test team.
Controlling progress is primarily achieved by assigning a suitable number of
developers to the project. Additional control can be had by using the incremental
model to defer some functionality, or the spiral model to defer some of the
quality, so that something useful gets delivered as early as possible.
Knowledge Management
This is an addendum to the original article.
On a recent project it occurred to me that there was a fourth element to the
development process, namely the distribution of knowledge about the system.
A quick way to ruin a project is to make one or more of the team members
indispensable because only they know some important aspects of how it all works.
In the examples that I have seen over the years the issue is not the fine details
of the algorithms that causes the problems, but rather the overall flow of data through
the processing that causes the most difficulty for new members of a team. Once they
have that big picture they can zero in on almost any issue. Conversely, without
that overview they are left utterly confused and reliant on the experienced team
members to point them at the likely cause of a bug. My preference is for a set of
diagrams showing the static relationships, a set showing the flow of data (including
processes, files and database tables) and a set of collaboration diagrams for most
use cases (preferably generated from the running code).
I once heard about a company (Japanese if I recall) that had a policy of firing
anyone who had become indispensable. This is perhaps a little to extreme, but not
by much, because if that person were to leave then your project might be in
difficulty.
Some mechanisms for knowledge distribution include collaborative working, code and
design reviews and regular team meetings to discuss deep technical issues. The
documentation for the system needs to be kept current and useful.
This work is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International License.
