Basic Software Development Lifecycle

A software development lifecycle accomplishes a few things, one being that your product actually gets into the hands of customers. Apparently quite a few Zuckerburg CEOs seem to think it means that you rename and reversion your product 80 times for your own delight and glee.

Yes, I’m aware that I’ve done the exact same thing. First there was Serenity Project Manager. Then Serenity Enterprise Server. Then Rhapsody. Then Synapse Publisher. Then SerenityAP. At least I stick with the Serenity name.

The difference being that two times, we were legally obligated to change the name due to trademark issues, and Serenity Project Manager is still developed especially for several large companies and websites. Due to time constraints and contracts, we decided to work especially with those companies on Serenity PM, and stop selling it to the public.

Fast forward to today, and now we’re offering up some community pieces, such as the free blog software and CMS, and the more expensive Enterprise suite that is aimed to replace Serenity PM.

Where the software lifecycle comes into play is the fact that even after renaming and version changes for Serenity, it still has followed a lifecycle from design, to develop, to test, to maintenance. Our SDM and lifecycle hasn’t changed since we first started the company in 2006, and although I’ve had to stray from it a few times in the past two years, SerenityAP and Enterprise has undergone the full lifecycle ( save for maintenance, that comes next ), and it’s paid off in more ways to one. Namely, it’s actually going to be released on time, with proper documentation, and it’s not something we’ve been talking about for eight years and shown 0 results for.

I was poking around over the weekend and came across one such example of a failed SDM. The lead programmer has a serious air about him, which is why it was funny that he throws his development into the wind and sees where it lands. Naturally the five different projects that the company develops have yet to see a public release, but have somehow been notched up to version 1.2 The question is, what the hell happened to 1.0? And 1.1?

For those of you out there thinking of jumping into startup land, or just want to release your latest project to the world, here are four important development stages to keep in mind:

Design
Although it should be a given, the design phase of a lifecycle is one of the most important stages in the life of a software product or service. Skipping over the design phase is a great way to get a product into beta faster, but will also plague you with feature creep and some nice unforeseen bugs. This is especially true when starting the lifecycle over for a new release. If you skip the design phase for upgrades, expect some angry customers, especially after a missing code block eats their valuable data.

Development
This step is required. Well, for those of us that actually get a product to market. Development itself consists of a few sub stages, including feature gathering, wireframing, and others. That’s another topic for another day.

Test
This is another stage that is often skipped, especially in the day and age of Web2.0 It’s much easier to just slap a “BETA” star tag on the product/service than putting it under stress and usability testing.

At E29 we use JMeter from the Apache group for the stress testing, and a detailed test plan to work out any last minute bugs. While user beta testing is important and useful, generally we get our best results from internal testing.

Documentation should be prepared at this stage. Many companies and developers make the mistake of documenting while developing or even designing. This is pretty much useless, as products tend to change and evolve even during the development phase.

Maintenance
Ah, the end of the road. The product has been released, and now it’s maintenance time. Generally you will also start a parallel lifecycle for your next major release, starting back at the design phase. For the maintenance stage, you will kick back to developing, then testing, and then releasing the new patch.

Obviously, these stages are pretty basic and easy to follow. You’d be surprised how much faster your product cycle will go if you just follow a standard development lifecycle.