Waterfall Models

Sorry, the title might be misleading. I just came across this today while researching some software design aspects we’re looking at.

Those who are programmers have probably heard of the waterfall model, an approach towards software development which takes you through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

The waterfall model of software design originated by William Royce in 1970.

This model was cited by Royce as an example of a flawed system. Ironically, it was the most commonly referred to system in the 1970’s and 1980’s, especially by large-scale government software operations.

I write this post not in support or disagreement with the waterfall model or the many other approaches deriving from it (read: agile model, spiral model, or Big Design Up Front Model, etc.). Each of these systems have their merits and cater to different applications, teams, and developmental circumstances (i.e. startup or mid-large company), etc.

I write this because I am intrigued how the approaches all begin with the application requirements - all of them agree that you cannot move on to the next stage of design before you nail out the core requirements of your system. In other words, what will your software do? What does it solve?

Don’t worry about the little features. All of that comes in later stages – that is what alpha and beta releases are for.

The design process has to begin with the planning stages, addressing the key elements and functionality of the product. This is the best that can be done by an idea guy in the ideation stage. If you’re an entrepreneur with no programming background but have a tech idea that is so compelling it makes you jump from your seat, I bet it is hard sometimes to convey the features of your product to a technically savvy programmer without having them shoot you odd looks.

This was a grave problem and continues to be so in our early days with BARCS, our small mobile app programming group. In the beginning, when attempting to contact developers regarding our project, I would explain the idea in vague terms to the programmer describing the broad scope of the application. Unfortunately, I didn’t get many responses back from programmers because I just wasn’t speaking their language. They wanted to hear from somebody who knew that we needed a Rails developer who knew Java first and foremost, with a LOT of databse experience using MySQL. This first engineer has/had to know how to connect their system to the work of another Java engineers work on camera functionality.

Once we delved into the specifics, response rates increased. It is still in it’s infancy, but I feel that the more time I take on defining the Requirements stage of the application, the better prepared we’re to get where we want – i.e., programmers will have a much clearer vision of what needs to be done and the scope of this project.

The next few weeks for this guy will be spent learning database design (MySQL, Dubois), getting depper into Java (Head First Java, Kathy Sierra), and reading more on software development cycles (Joel on Sofwtware, Joel Spolsky).

This is a real learning experience for a young entrepreneur. I can only best prepare myself in the Requirements and Planning stage, until I can hand off the software development cycle to our programmers.

After that, the business cycle has it’s own “waterfall model” which is just as labor intensive – from planning to implementing, tweaking, testing, pitching, developing…it’s a long road ahead, but that’s the fun.