System Request, Analysis, and Design
System Request
Some person or group has to be "the owner" of the new system.
This should be an absolute requirement for every project. The reason is that somebody has to be able to say, "Yes, it's finished. I'll take it." People who are not in the software biz might be amazed to discover how often a system doesn't have an "owner" - or has lots of competing "owners". The old saying, "success has many fathers, but failure is an orphan" accounts for much of the reason why. Sometimes, the software development department just wants to build systems that nobody really wants built. (And that is a guarantee of disaster if there ever was one.)
One of the first jobs that the "owner" of the system has to do in most organizations is to convince whoever supplies money for building systems that this system can be done and that it should be done. This is often called a "feasibility study". Guru Dan Clark (An Introduction to Object-Oriented Programming with Visual Basic .NET - Apress) calls it a "Software Requirement Specification" and gives it an acronym: SRS.
After somebody does this horrible job, they're usually "on board" to help get the system done to the bitter end. Management usually holds the "owner" of a system equally responsible for success or failure of the development project.
In my experience, having the solid support from somebody who really, really wants the system built is the most important factor in whether project succeeds or fails. It's more important than picking the right technology. It's more important than having a lot of funding. And it's even more important than the skill of the programmers. If there is somebody out there that you can drown your sorrows with when things don't go well, or celebrate with when they do, you are much more likely to finish the project.
Analysis
A description of what the new system will do must be completed.
Design
This step creates a detailed plan to build the new system.
These two steps often go together and they're often repeated more than once before the design is "right". The end result is a description of what the new system will do and a detailed plan of the rest of the steps to build the new system.
The analysis and design phases of a project are the deadly tar pit of systems development. Many, many systems have died a horrible death in "analysis paralysis". The reason this happens is that it's incredibily difficult to decide when enough has actually been done - especially in a big project.
For one thing, the requirements often keep changing. The systems development people sometimes come to the conclusion that the "owner" never understood the problem in the first place. And the "owner" strikes back by saying that the developers don't listen and they're the ones who don't understand. In some cases, a requirements statement can never be completed because the owner and developers start to distrust each other. The lack of communication just keep going around and around and around until the money runs out and top management finally kills the project. Often, it's a mercy killing.
This horror story, which is repeated more often than people realize, is a very big reason why "the owner" must be totally committed to completing the project before it ever starts. Only then can the compromises and hard work of ironing out the requirements in a difficult project be successful.
Because this phase is so critically important to get right, most large companies employ specialists just for this part of the job. A technology called UML, the Unified Modeling Language is a traditional technology for getting the job done. Although Microsoft has been a big supporter of UML in the past, their enthusiasm for it hasn't been the same since IBM bought the leading UML company, Rational Software. Marie Huwe, general manager for Microsoft's Developer and Platform Evangelism Division was quoted as saying, "We're designing for ease of use, and we didn't think UML was the way to go." Funny, they used to think that UML was the way to go.
Especially for large systems development, companies often use another technology that goes by the acronym CASE - Computer Aided Systems Engineering. The basic idea is that requirements and specifications are captured in computer files. Then software can check the specifications for consistency, completeness, and in some cases, even automatically generate the program code.
When you create a design for your program, keep it simple. Remember the golden rule: having a detailed design should make the programming easier, not harder. So here's a four step beginner's guide to software design.
- Write down a description of what the system or program is supposed to do.
A few paragraphs ought to do it. If you can't describe what the program will do, how will you know when you're finished?
- List all the inputs and outputs of the program.
A form, for example, can be both an input and an output. Examples of form input might be a text box, radio buttons, or even a random number that the computer creates. Examples of output might be as simple as another text box or as complex as commands sent to a rocket guidance system.
- Describe what happens to the inputs until all the functions of the program have been described and all the outputs created.
Again, when you're just starting out, a text description will do just fine. The goal is to be sure that you understand it. If you can't describe it, then you probably don't understand it.
And ... perhaps most important of all
- Keep your design up to date.
As you learn about the program requirements, you'll change your mind about the design. That's good. Nobody thinks of the one, best way to do something the first time around. But just because the requirements change, never go back to bad, "no design" habits. Rules one through three worked the first time and should be followed again whenever you need to create a new design.
On the next page, we finally get to the heart of the matter: writing the code!
