When BNT Solutions was incorporated in 2001 there was one goal in particular that ran as a thread through everything that was done: simplify, simplify, simplify! Of course there are some things that, even though you try to keep them as simple as possible, are still going to be somewhat complicated. In these cases, the only solution is to Hold Hands with the customer as We Walk Through the Project Together. Towards that end, many documents were written and prepared over the years that try to help the customer to understand the How and Why of success in various areas.

The Software Development Cycle is one of those documents. The on-time and on-budget delivery of a successful software project is not difficult to achieve but it's never an accident. The only way to build a software system successfully is to work together, taking all the necessary steps while following a solid and reliable process.

This article is a big-picture overview of the Software Development Cycle as followed at BNT Solutions, Inc.

1. Together, we will Build the Right Software, ie: make sure that the software being built is actually going to meet the real needs of the people who are going to use it, and
2. Together, we will Build the Software Right, ie: make sure that the software actually works as expected.

This is accomplished through the use of many short development cycles, each one consisting of four distinct phases: Evaluation, Design, Implementation and Testing. By keeping the cycles short, we can release early and often - the key to ensuring that our project meets the real and immediate needs of the end-users.

Let's take a quick look at each phase in the SDC:

Evaluation

Before starting our project, we prepared a roadmap showing where we wanted the project to go and how we wanted to get there. As such, the first development cycle doesn't include much of an evaluation. Still, it’s always a good idea to review the work that is planned for the future to see if there is anything we can do better. Subsequent cycles will also benefit from anything that was learned in the previous cycle. The results of our evaluation will be used to update the roadmap.

The main purpose of this phase is to reduce costs and avoid problems. There are often many ways to complete a task. We want to review all our tasks, prioritize them, evaluate risk and find the simplest and easiest way of moving forward with each of part of the system.

Improvements in the plan that are made in this phase might dramatically reduce costs throughout the project. If we find a simpler way of getting something done in this step, we will have saved the cost of the more complicated steps that we avoided. If we find a problem with our existing plan and correct it before the work begins, we will have saved the cost of implementing the buggy code, testing and correcting it. This can add up to a significant time and cost savings for each cycle and the overall project.

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.
  

Testing & Review

In this phase the developers tag the completed modules as being ready for testing and copy their product to a testing sandbox so that the Quality Assurance staff can execute the test plans that were written/updated during the development phase of the cycle.

After each test execution, a meeting is held to review the bugs that were found and prioritize them. The developers then fix the prioritized bugs and the tests are executed again. These test-fix cycles continue until the product is stable.

Once a stable product is ready for User testing, the developers tag the completed modules and copy their product to a sandbox that is accessible to the users. Not all users will test this product. The Project Manager will find a few Power Users who will take the time to review the software and report their conclusions. They might also log bugs into the bug tracking system which will be reviewed and most likely fixed by the development team (after being prioritized.)

Expectations

Remember that, during the Design and Implementation phases, the customers were discussing all sorts of great ideas between themselves - but the development team is not working on any of these ideas. It is very important to manage the expectations of the customers who see the software in this phase. Customers who will be involved in testing must understand that they will be looking at the results of the last Evaluation Phase.

To maintain end-user buy-in for the project, it is important that the users have a clear picture in their minds of what has been done with the ideas that they've been discussing. In practice their ideas may not have been passed along to the Project Manager - so the development team is often limited in their ability to discuss specific new ideas and how they are being integrated into future cycles. Nevertheless, the customers need to know that their ideas have been documented and will be considered.

End-users need to have a clear idea of what they will be testing in the current phase of the software development cycle. In later cycles, after the stakeholders have experienced a few cycles of regular software releases, expectations will become a much less important issue - everybody will know that their ideas will be passed along to the development team during the Evaluation phase in a future cycle and not the current one.

Failure to manage these expectations can result in a situation where the Design and Implementation phases of the current cycle are revisited without completing the current cycle. This prevents the building of a solid foundation on which the project can grow successfully. Over time, development will continue but there will be no way to determine if the project meets the real needs of the end-users. Perceived needs will be met but at a cost which can't be evaluated relative to the real value of the features produced. This stretching of the Implementation phase can seriously threaten the success of the project overall.

Acceptance Testing

If this cycle is expected to produce a result which is intended to satisfy a contractual obligation, a special test is executed. This test, called an Acceptance Test, contains only test steps designed to verify that the software meets the contractual obligation. Acceptance tests are usually simple and quick to execute. They are far less detailed than the majority of tests that are performed before the acceptance step. The customer may already have been using the software for some time prior to the acceptance test and is already prepared to accept the software. Therefore, the acceptance test is often omitted if the customer signs an acceptance statement or approves the software for release to a production server.

Go No-Go Approval

If this cycle is expected to produce a result which is to be posted to a production server, formal approval of the posting is required from the customer. To obtain this approval a Go-No-Go meeting is held. During this meeting the heads of any departments affected by the release of the software will review all bugs remaining in the Bug Tracking System. Department heads will be able to query the development team leaders to ensure that everybody has a clear idea of the risks, if any, involved in making the release. If all department heads approve the release, the package can be installed on the production server. Otherwise, the various managers must decide what they want to do and take action to ensure that it is done.

Unfortunately, many Go-No-Go meetings result in the software being approved but the release being deferred. There are many reasons for this:

• Many releases involve functionality changes that require employee training. If the employees have not been trained to use the new software, the release might have to wait for the training to be completed.
• Many releases are of no value to the customer if the necessary data is not available. If the customer needs time to prepare the necessary data, the release will be delayed.
• Many releases involve components that must interface with new features that are in external systems. If one of those external systems is not ready yet, the release of the current product will have to wait until it is.
• Many releases add complexity and overhead to existing software. This might necessitate increasing the amount of available memory or disk space in the production server. From time to time a new feature in the software to be released requires an Operating System or Component upgrade before it can be used on the production server. If these upgrades are held up for some reason, the release to production will have to wait for them to be completed.

Regardless of the results of a Go-No-Go meeting, the development team can simply branch the software in the Revision Control System and move forward with the Evaluation Phase of the next cycle. When the next Go-No-Go meeting is called, the software will still be available for posting to production.

At this point, we know that we have a solid product in our hands. It does what the customer wants it to do and it works correctly - thereby meeting the two main objectives of the Software Engineering process. When we start writing additional software, we know we won't have any problems with the software we've written already; we are confident that the work will go smoothly as we will be building on a solid foundation.

Finally, we close this Software Development Cycle with a review of the work that has been done in the current cycle. Are we on track? Did we learn anything in this cycle that we need to incorporate into our future cycles (good or bad?) Is there anything we need to change in our Project Roadmap?

Following this review, we start the Evaluation Phase of the next cycle and repeat these steps again.

Summary

The Software Development Cycle is critical to the success of any software project. By properly performing the simple steps involved in this process, we can ensure the successful completion, on-time and on-budget, of our project.

Each iteration in the cycle can produce not only a useful result, but also an understanding of any disparity that exists between the real needs of the user community and the project being implemented. If it becomes necessary to change course at some stage in the project, the mass of work that will be affected is limited to whatever was done in previous cycles - not the whole project.

Most importantly, customers can exercise precise control over the process, especially during the Evaluation and Design phases. Any stakeholder or member of the user community can make suggestions which will be added to the task tracking system. These suggestions, called Enhancement Requests, will be prioritized by the Project Manager. The Lead Developer for the project can then determine how much the change will cost. During the Evaluation and Design phases of a SDC, the various Project Managers can decide if they want to include the enhancement work in the next cycle or not.

The same is also true for tasks that are planned: The Project Manager can delay or cancel them altogether as per the needs of the project. In all cases, the consequences of these actions can be determined prior to the start of the implementation phase so that the project manager is able to make the best possible use of the time allotted to the cycle.

FAQ

• Q. What's the difference between the last phase in the cycle, the Review, and the initial Evaluation phase?
  A. The review is typically a meeting with as many people as were involved in the previous cycle. In this meeting people talk about the experience they had during the cycle: What went well that they'd like to keep doing and what went wrong that they want to avoid in the future. The Evaluation phase is very different in the sense that decisions that change the course of the project are taken by management staff based on all available input.
  
  
• Q. My company has some steps in our Software Development Cycle that you don't list above. Why is that?
  A. This document lists the steps that BNT Solutions will follow for the vast majority of development projects. Some projects or industries might require additional steps to be added.

  If you look into a software engineering text book you will find lots and lots of steps that are not listed above. Often they are intended to deal with issues that are common to really huge projects. Academic text books list many issues that can be handled in many different ways by different development teams.

  The Software Development Cycle that you see documented above is the one that we actually practice at BNT Solutions. In fact, the documentation above comes out of documentation that was written as part of our ISO certification project.