Modern software development tools are wonderful. There
is no doubt they have decreased the time – and therefore cost – of
developing a system dramatically.
In some respects, they have also improved the quality of
the systems produced. In particular, the opportunity new techniques offer
for users to sit with developers and see their ideas take place and develop
on the spot is a huge advance.
As with all things though, there are disadvantages if the
tools are not used sensibly.
There is a great temptation to jump straight in to system
development. Often this starts as “prototyping” or “proof of concept”, with
the unwritten supposition that, once the concept is accepted, the “proper”
development will commence with a rigorous design procedure.
The prototype seems so good though, it often seems best
to just carry on and make it better.
That is a
mistake. It is like starting to build a house with nothing but a roll of
carpet and an idea for a kitchen you like. Most of us get so involved in
the details we are looking at, we just don’t consider the bigger picture.
Eventually, but perhaps not until we have spent a lot of money, we find we
have pieces of house which do not fit together. Furthermore, they have no
foundations to sit on!
You run the
same risk when you start a system development by writing programmes. They
may be very good at what they do, but will they work together? – will they
handle what is going to happen in the business next year? – do they fit the
systems become more pervasive and more complex, it is more important than
ever for their development to be based upon sound analysis of the
requirements. Equally, it is important for the system design both to
satisfy current requirements and to provide the flexibility you know will be
important next month or next year.
The people who are best to write your programs are not
always best to perform this analysis and design work. The one requires a
thorough understanding of technical matters. The other requires a thorough
understanding of how organisations operate. But there is a limit to how
many experts you can keep fully employed.
contract will make our expertise yours for as long as you
need it, producing any or all of
Review of your existing procedures and organisational habits
Requirements Definition of what you and your staff think should
happen; what should be computerised and what should be done by people
Design Specification, from which programmers may develop the code which
fits your organisation and your needs
Evaluation, indicating how well ready-made software fits your
analysis and requirements definition has further benefits too; as a basis
for procedures documentation and for staff training; as the foundation for
ISO qualification; as a yardstick for performance measurement and, perhaps
most important of all, as a key to understanding exactly how your
organisation operates from day to day.
What’s happening in my organisation?
How should we do it?
Functional Requirements Definition.
How do I tell the programmer what I need?
Can I get an off-the-shelf package to do this?