A structured method can bring considerable advantages to the development process:
• A method can define a shape and structure for the development process, so that the various activities are performed in a sensible sequence. If s much easier to do a job if you know what to do and when.
• It may bring a set of techniques and tools which will help you to define the system, and may give you guidance on which techniques to apply and when.
• It may provide templates or contents lists for the various deliverables you must produce.
Note that a structured method is sometimes, wrongly, called a methodology. That's a "study of methods", which is what you're doing reading this book. Some people also use the term formal method, but if s better to keep that for the mathematical methods used in testing and real-time system design.
There are many different structured methods, some of which are quite generalpurpose, and some specific to a particular type of problem or development environment. These may have different structures and terminology, and produce quite different-looking lists of deliverables. However, all are trying to define a sequence of activities which if followed should help you to structure your development logically, get a clear specification, and design and build a good solution to the problem. The deliverables may be structured differently, but the information they'll present is usually the same.
This book isn't tied to any particular method, and it certainly isn't useless if you follow a different one to me. I had to adopt something as a basis, so this book loosely follows a traditional "waterfall" method, using a simple structure with very clear names for things. If you use a different method then you'll have to translate my names for things into the names your method uses, and you may have to do some jobs in a different sequence, or put the results into different documents. Tve tried to make this as easy as possible by explaining why you need to do a certain job, and what the real product is, quite independent of any particular method.
If you don't use any structured method at present, then this book gives you the outline of a good method to follow. You can get more detail from another book, once you understand the principles clearly.
"He's got an 'Ology"
There are some dangers to structured methods, and if you're going to get the most out of them you need to understand their limitations. Just because someone follows an impressive-sounding "ology" doesn't mean that they are automatically going to get good results - successful development is always the result of intelligent work, properly controlled by a good manager.
The most important thing to realise is that any method is a means to an end, not an end in itself. You need to make sure you understand your eventual target, and how each part of the development process moves you nearer to it. The next chapter discusses how you measure success.
Fve often said that "A structured method, like fire, is a good servant and a very bad master". If you find yourself doing things just for the sake of the method or the standards, then ask the question "why?". However, it's probably not a good idea just to ignore the method and standards - there may be a very good reason which will become apparent later. This book should answer the question "why?" for the main steps in any method.
Some methods do demand a lot of paperwork. You will have to strike a balance between too much and too little - there is no one right solution; you make the decision, but the answer is not "none" or "tons". The key principle is to understand who will read each document and what they will use it for. Then deliver the information they need, and not too much extra.
Structured methods can also be over-prescriptive. For example, you don't need to use a "prototyping" method to do a bit of prototyping and make good use of the results, but some methods don't allow for this. Many methods only ever talk in terms of completely finishing each stage before moving on, but it can be better to break work up into phases each of which moves through the method in its own right.
Don't be afraid to use some initiative and common sense in applying your method, but remember that there are no magical short-cuts. The method is a tool to make development easier, but you must understand the development process, and make intelligent decisions based on that understanding.
Was this article helpful?