“Perfect” Software Design and Development Process

Executive Summary: To maximize Quality and reduce total development cost, PSE starts with design, then does testing & development.

Most software development, whether done by students for a school project, or professionals on critical software, more or less follows a “Cowboy Coder” process: I know what needs to be done, how to do it, I don't have time to do all this design nonsense, I'm just going to go do it. This tends to mostly work, for a while. Eventually, as the changes pile up, even the person who made the changes starts to lose track. If there is any turnover in the development corps, very rapidly all knowledge is lost, and the software becomes a nightmare. I have seen it; so has everyone who works in this field.

In contrast, I prefer to follow one of the most basic software engineering processes: what is known as the “Waterfall” process, named from the concept that each phase is distinct, and ‘falls’ into the next, without going back.

At PSE we do the design process before we start coding and we provide documentation. We proceed in an orderly fashion with the goal of providing you with long-term, quality software. Listed below are the steps that we, at PSE, use to take a project from conception to completion. While ideally one goes straight through this process, in reality, every bug or change requires some amount of jumping back to the previous phases.

It is important to do this, as designs and tests must be kept current. However, it does add cost. This is why it is important to try to be as complete and accurate about the requirements of the software as early as possible in the design phase.

Continually changing requirements will prevent the project from ever being completed. That being said, it is still cheaper and easier to make any changes before code has been written rather than after, which is why at we at PSE leave the task of actually writing code as late as possible.

Once code has been written, changes become far more complex and difficult. Code must either be modified (which is more difficult than initially creating it) or a whole new version must be written. Both options are costly.


The following are the steps PSE uses to design and develop software.

  1. Contract / Expectations

      - Complete detailed contract, oral & written, and communicate expectations for both parties. [Note: The numbering is a reference to the joke/truth about how computer scientists start counting at zero. It also expresses that this step is not quite like the other steps, but lays the groundwork for them.]

  2. Purpose

      - Define the goals of the project. Nail this down. This is not about the “how” but the “why”. No, “make buckets of money” is not a purpose, at least so far as this stage is concerned.

  3. General Architecture

      - Consider the broadest possible technology constraints needed to fit the purpose. What hardware will be used or supported? Which operating system(s)? Which language? Some major components might be split up, but generally avoid detail as much as possible here.

  4. Detail Functionality

      - The nitty-gritty of the core is now to be designed. Close collaboration with the client and/or the users to determine what exact functions are needed to implement the purpose. Only the most general interface-type issues (like HTML vs local UI, etc.) should be addressed in the steps up to and including this one.

  5. Detailed Design

      - In-depth planning of functional, modular, and overall design, to fit all of the requirements determined so far. NO CODE. Possible pseudocode to describe algorithms, but even this may not be necessary yet.

  6. Develop Tests & Plan for Coding

      - Final, detailed preparation for actually creating the software.

  7. Begin coding and testing

      - Self-explanatory.

  8. Release

      - Expose the software to actual users, frequently in alpha, beta, and final release stages. This will reveal bugs, which causes further development to be necessary. It often also inspires feature requests which will need to be triaged as to their importance and relevance for the purpose of the project.

  9. Maintenance

      - Ideally, there will be a slowdown of bugs and feature requests over time after release. However, a growing userbase will generally result in more bugs being exposed and features requested. Any software in long-term use will require some level of maintenance to stay compatible with the changes of the software it interfaces with, if nothing else.


Site Map: