SOFTWARE DEVELOPMENT
Risk Management
 The first thing to accept is that software development is unpredictable.
No matter what new fangled software is implemented and how many function points are estimated,
experience has shown that making the target date (let alone achieving the desired quality
outcomes), is a hit and miss affair.
Risk may arise due to loosely defined requirements, difficulties in estimating the time and/or
resources needed for the software development, dependence on individual skills and rapidly
changing requirements due to changing needs.
Here are some thoughts on how to make the unpredictable a little bit more predictable.
Spend more time setting objectives
Project objectives are important. A project should not be initiated without well thought out
objectives. Spend time analysing what the project is trying to achieve. The project objectives
need to provide guidance to the programmer for every programming task. Pin up the objectives
for each programmer to see.
Here is an example of setting an objective. I was asked to analyse the requirements of a busy
manager. His manual filing system was constantly in use, and never in order. A system was
needed that would maintain the current details, and ensure that records could always be found.
That was easy enough. However, during the interview, the phone rang constantly, with requests
for information. The objective finally agreed on was "Eliminate the phone requests". This
led to a very successful solution, but completely different to that originally envisaged.
Having set the objectives of the project, do an exhaustive analysis of how the objectives
can be achieved. This should eliminate unrealistic objectives - like "The best and nicest
and cheapest and quickest".
Do not spend too much time gathering requirements
Rigid analysis stifles programmer and user creativity. It is also no guarantee against a software
disaster. Where the documentation of the requirements runs into several volumes, it usually
guarantees a software disaster.
Users frequently do not know what they want, but they will recognise it when they see it!
What was the original requirement may not be what was wanted at all. Rather spend time on
creating a solid project framework that will enable you to achieve the major objectives.
Break a project into multiple tasks
Wherever possible, a large project should be broken into smaller tasks. Each task will then
be more predictable with less to do and less that can go wrong.
The initial programming task should be to create a framework with minimal functionality. Create
dummy procedures to show the style and the intent - it is important for the users to see the
"look and feel" of the project early in the development cycle. It is equally important for
the users to get involved right from the start. What you want is users to start "owning" the
project.
With the project objectives soundly set, the basic functionality should be subject to little
change. The dummy procedures can be completed once the project concepts and design have been
approved. Later tasks can then add the "bells and whistles".
The project must be "infinitely modifiable"
The project must be designed so that it can handle major changes to requirements. With a soundly
defined framework and infinitely modifiable design, the effect of users changing their minds
will be minimal. As will the consequences of new or better ideas as the project evolves.
There needs to extensive thought on how an "infinitely modifiable" system can be created.
This must be done before any programming is initiated. "Top down", modular design standards
will help.
The consequences of having a rigid system are unpleasant. When change occurs, and it will,
you will have very unhappy management when the target date needs to be extended. Equally unpleasant
is to send the programmers on a "death march" to get the project finished on time.
Do not use new or complex technology
Using straightforward, tried and trusted Software provides a head start. There is always some
advantage in using the latest version of software - but there can also be a heavy cost. If
new technology is essential for the project, then an independent trial of the software is
needed to ensure adequate technical knowledge and that all the software bugs have been ironed
out (are they ever?).
Relying on immature software with limited programmer exposure to the software is a recipe
for disaster.
Hire only the best and brightest
The success of a software project is mainly dependent upon the abilities of the developers.
They determine, more than any other factor, the viability of a project and have a tremendous
influence on productivity.
A few tips: The successful applicant should have a keen sense of humour (see De Bono and Lateral
Thinking) and a good grasp of idiomatic English. Excellent communication is all important.
Do not proceed with a large project where the best and brightest have recently left the company.
The company will be suffering from the "skim milk" syndrome - and you need the cream of the
crop for successful development.
Reusable code
It is always productive to collect a large library of reusable code. The procedures should
be used to standardise: error handling, database access, edit routines, grid handling, etc.
The reusable code will reduce debugging times, as each procedure will be called multiple times.
It also lessens the amount of coding needed. See the page Reusable Code – A Management Issue
|