Design

The initial design stages of the project are devoted to the detailed analysis of the project requirements and the design of a plan that will meet them. Once we have verified that the design will meet the requirements as documented, we build a task list that the programmers can follow.

Later design stages involve amending the long-term plans as a result of the decisions taken in the Evaluation Phase of the cycle. Once we have amended our long-term plans, we are able to update our design and amend our task list.

Note that the level of communication with you, the customer, may be reduced during the Design, Implementation and Testing phases in the cycle. You, of course, are still thinking about the project. You get all sorts of great ideas and you discuss them with your colleagues. It would be a problem, though, to stop the implementation work and revisit the Evaluation and Design phases of a cycle whenever new ideas are proposed - the software development team wouldn't be able to get anything done if that were allowed to happen. So, at this stage in the process, the software development team begins working on the conclusions from the Evaluation phase of the current cycle. Everything you discuss with your colleagues - even if you discuss it with the Project Managers - will have to wait until the next Evaluation cycle before it can be evaluated, incorporated into the requirements, analyzed, prioritized and designed.

In practice, most projects get into trouble from time to time in the Design and Implementation phases of a cycle. This is usually because the stakeholders lack the discipline necessary to allow the development team to complete a cycle. It takes time for customers to learn just how easy it is to get everything they want and to understand and know that anything that they think of can be done - but only if some of the things that they want to do are allowed to be completed.

Note that, on the flip-side: projects that have numerous completed development cycles behind them are able to incorporate new ideas quickly!

Getting back to the amended task list:

Risk

Any new tasks on the task list must be evaluated for risk. Some tasks, as designed, are too complicated or might lead to future problems:

• The technology might not work as expected,
• the programmers might not have the skill or experience to implement the task within the desired schedule,
• the resulting module might be too expensive to test
• the resulting module might be too expensive to maintain

Such tasks must be redesigned to eliminate the unwanted risks.

Schedule

Next, we need to prioritize the tasks remaining in our project. We need to determine what we want to do next.

From the prioritized task list we need to pick enough of those tasks to fill up the anticipated development time for this cycle. Here we estimate man-days of work per task and divide it among the developers in the team.

The idea here is to make sure that we don't try to do too much in the current cycle. We want to have something useful to show for our work without spending too many weeks between reviews and evaluations. This step is also designed to ensure that the current cycle will result in something that we can look at. Hopefully it will be something that can be released to the users so that they can offer some practical feedback.

Implementation

Once a short list of prioritized tasks has been assigned to the development team for this cycle, they start coding.

At the same time, the Quality Assurance team is able to review the task list and prepare Test Plans that will be used, once coding is completed, to determine if the software works as expected.

Although this phase appears in the charts and diagrams as being the same size as the other phases, Implementation is often the longest phase in the overall cycle.

FAQ

• Q. What's the difference between the Analysis Phase and the Design phase that follows? How is Analysis different from Design?
  A. Analysis is a largely cerebral process - people discuss how things should work and decide on the direction that the design work will take. In fact, much design work is often done during the meetings that are held - but this is always high-level design. It does not often go into great detail, does not systematically match design elements against requirements and does not generally result in documentation that can be translated into detailed task lists for the development team.
  
  
• Q. What's the difference between the Risk analysis in the Analysis Phase and the Design Phase.
  A. The concept is the same but some risks are apparent during high-level analysis while others are only noticed after a detailed task list is produced.

  In some cases a solution will be proposed in the Analysis phase of a cycle that involves the use of new technology, tools or techniques that are perceived to be risky for some reason. In these cases, tests can be scheduled to determine how the new ideas might fit into the system. These situations can result in risks that recur through multiple cycles and phases in attempts to add new features or make other important changes.
  

• Q. How do you know when a design is complete?
  A. When it meets all documented requirements and is easy to explain.

  You can see that your design is not finished when you try to explain it to someone and find yourself getting confused. When the design is really simple you can explain it easily.

  When there are elements that are not clear you will find it difficult to understand or explain those parts of the design. This is an indication that it is still possible to simplify or reduce the design further.

  Note that this is often an issue for all members of any project team: if somebody is having trouble discussing an idea it's probably because the idea is not clear in that persons' mind.

  It happens quite often that a customer will try to get a development team to produce a new module or feature - but the customer is unable to explain clearly what the module is intended to do, who will use it or how it might work. Such modules are often the basis for important innovations in business. Every analyst wants very much for them to succeed. However, red flags are raised when an experienced analyst finds that customers are having trouble answering questions about a new idea. The analyst then tries to find ways to answer the questions before allowing the programmers to start their work. This is because the most expensive mistake a project team can make is to implement an idea and put it into production - then remove it for some reason. To avoid this situation it is necessary to make sure that the ideas and the important details are clear in everybody's minds.

  If you have a great idea and you want to turn it into a reality: you know why you want to do it - which is a good start. Before programming work can begin, though, we need to work together to figure out who will use it, what it will do and how it will be done. It helps if you can document a paper process that can be automated. Otherwise, perhaps a small demo program can be written and used by a small group of people to help iron out the details.
  

• Q. How much time should be allocated to the Requirements Gathering process prior to the start of the first cycle?
  A. The amount of time required is dependent on the nature of the project.

  If the purpose of your project is to automate an existing business process, it is possible to simplify the requirements gathering by having your staff prepare a detailed process flow document. By documenting your existing manual procedure, you will effectively capture much of the detail that the analyst will need. This information will then be used as the basis for the overall project plan.
  

• Q. How much time should be allocated to the Analysis and Design process prior to the start of the first cycle?
  A. An estimate of the time required can be prepared after the main elements of the project have been identified.

  These days everyone considers himself to be a qualified analyst. This dramatically reduces the perceived value of the documentation produced by an experienced analyst. However, the work done by an experienced analyst: documenting requirements, analyzing problems, designing simple solutions and preparing a detailed project plan, is critical to the overall success of any project. Investing time in analysis, design and documentation always results in significant returns through reduced project complexity. The shortest path between where you are and where you want to be is a straight line. Amateur analysts might eventually get you to where you want to be; an experienced analyst will draw you a map, then walk directly there with you.

  That being said, it is not necessary - and not desirable - for the entire project to be planned in every detail from the start. An experienced analyst will go into detail where required. By following the Software Development Cycle, the project plan is guaranteed to be reviewed and updated regularly. Detail information needed for upcoming cycles and new ideas and information can be incorporated into the project plan as needed.
  

• Q. What is the difference between simplification and reduction?
  A. Simplification eliminates unnecessary steps in a sequence and reduction factors common steps out into a library module.

  A software module is basically one or more long sequences of steps that a computer is required to execute.

  • A simplified sequence involves fewer steps.
  • A reduced sequence factors-out common sequences of steps, moving them to library functions that can be called repeatedly from other modules.

  A simplified sequence of steps is less expensive to implement, takes less memory and disk space in the computer, runs faster and is less expensive to maintain in the future. A reduced sequence of steps is also less expensive to implement and maintain in the future. It might also save some disk space but does not necessarily run faster or use less memory.

  Note that the cost of having an analyst simplify and reduce a design is dramatically lower than the cost of implementing a more complex design. The difference can be quite shocking.

  It's interesting to note that the less experienced analysts produce designs that look more sophisticated. The more experienced analysts produce designs that appear almost to be the work of a child. The greatest compliment that an analyst can receive is when a customer remarks that a system turned out to be much easier than originally expected!
  

• Q. Why not stop the development when a new idea is proposed? Wouldn't that be cheaper than modifying the code later?
  A. The interruptions themselves are severely damaging to the overall project. Also, the cost of future changes is usually very low. This is because much of the code written in a cycle is generally reused in the next cycle.

  In practice, a system which is not in production can't be successful regardless of what it can do. The success of a project is based entirely on the ability of the resulting system to earn a return on the investment made into it. This can only happen if it goes into production and meets some of the real needs of the user community.

  Of course, the only needs that the customers can design solutions for are the perceived needs. It is sometimes difficult to determine if a system meets real needs before some initial version of the system is tested in some way. If the development of that initial test version is never allowed to finish it becomes impossible to determine the value of the system. Worse still: there can be no foundation on which to base changes to the requirements or the associated design.

  The simple solution to these problems is to meet some of the initial requirements by allowing the current cycle to finish. The system will then have been tested and reviewed in some way. In the next cycle, it becomes possible to evaluate the results of the previous cycle and prioritize the many suggestions and new ideas that come in.

  This requires surprisingly little patience or discipline if the cycle time is short. Most importantly: The quality of the resulting product is always incrementally improving - ending in success for everybody concerned. Hence the old saying, "Release Early, Release Often!"

  Note that most of the components in the resulting software are likely to be reused in future modules - even if the requirements change to some extent from cycle to cycle. As such, the bulk of the work done during a given development cycle is always going to be useful. It constitutes a solid foundation on which to build the next iteration and is therefore tremendously valuable - even if there are many excellent ideas for changing it before it is completed.