The Software Lifecycle

In Review

1. Introduction

Like anything, software has a "life cycle". Each program starts as an idea, is completed to some level, and then (hopefully) used for a while.

50% of all software projects never are completed and 90% are late. This is a sad statistic. Imagine if you were paying someone to build a house for you knowing that there was only a 50% chance it would ever be finished, and that if it was finished, it would probably cost you twice what the builder estimated! There are a number of key problems that cause software projects to fail and properly managing a software life cycle can help prevent these problems. Below is a list of some of the common software problems.

1. The Nature of Developers

Most developers like computers. Many will go home to play computer games after a long day at work, on a computer! They like the latest and greatest technology and the latest features. They also like implementing new technology but rarely like testing and fixing defects in their code. This means they will tend to add new features and try new things that the user may or may not want. Users will tend to ask for new features as well but they are really annoyed by software that crashes and will change venders quickly if they can.

Strategy for Success: Developers are not the customer!

Always listen to your users. Talk to them about what they really need,watch them using your software and think about how to make it easier from their perspective. Over time you'll build a model of what users are like in your head which will be somewhat different from what you are like.

When building reusable modules, make sure to remember that you are one of the customers but it may be you a year or two down the road. Will you remember why you implemented something they way you did? Will you have to retrace the same paths you took to update the software that you made in creating it originally? This is where commenting code and even adding external documentation can really help.

2. Feature Creep

It's easy for folks to ask you to change something in software and it's easy to agree to make the change. The problem is that these changes will them come more and more frequently and as software is near completion and folks are using it regularly, they will think of more and more features to add. This creates a situation where software is being changed more frequently at the end of a project instead of becoming "stable" so it can be tested and the defects addressed.

Strategy for success: The train is leaving the station!

The person who taught me the most about managing projects was Dean Buck. He used the metaphor that the train is leaving the station (the current product is shipping) but there will be another one coming along in just a bit. We used this to focus new feature development and, even fixing defects, on the next release of the software. This allowed current release to go forward.

3. Communication

Below is a famous cartoon from Alan Chapman (http://www.businessballs.com/treeswing.htm). While the cartoon is funny, there are a large number of products that fail because of lack of communication, especially between the customer and the development team.

 

4. Throwing Resources at a Project and the Mythical Man Month

One response is to get more "help", especially at the end of the project. Imagine you've been working on a program for several months and you are late so they give you someone brand new to "help" you. You now have to bring them up to speed and interact with them to get them to where they can help. This actually causes the project to slip more!

Strategy for Success: Panic up Front!

The idea is to panic at the start of the project and get the resources you need to hit the schedule on target. The first thing I will do on a project (especially one that is in trouble) is get everyone together and do a quick "end to start" schedule where we work backwards from the date the software has to done and see where we are at. In almost all cases, we found out we were already late! Then we would work through what we needed to have a schedule that we felt good about and the resources we needed to make it happen. If we needed to slip the end date, we did it then, not at the end when everyone is expecting the software to be done and is breathing down our neck to finish. Then, as the project progresses, we watch for potential problems and constantly move new features to the next release.

Overview

The software life cycle helps you to make sure that software is finished on time and meets user needs. The basic steps are:

1. Investigation: Discovering what the user needs and what is possible
2. Design: Creating how the software will be constructed
3. Implementation: Actually writing the software
4. Testing: Making sure the software meets the user needs
5. Release: Getting the software to the users in a way they can get it and use it!
6. Maintenance: Updating the software for version changes and defects

The software world used to run these one after another in what was called a "waterfall" where one phase would end and another would begin. The problem is that sometimes when you are imp le meting the software you find out you have to make a design change. This led to the "spiral" software model where everything was happening at once. This led to projects that no one could tell if they were progressing and many never finished. Rick Lesser and I then invented the "stair-step" model where each phase has a start and an end but they overlap so you can integrate learnings into the other phases.

When doing web development, this evolved into a very fast software life cycle that we repeat each month.

Stair-step software life cycle with the phases overlapping and with checkpoints at the end of each phase.

Overall User Needs

The needs of research are very different from "production" environments where software may be used thousands of times by a large number of users.

Attribute	Research	Production
Quality	Accurate	Robust
Number of Users	Few	Lots
Technology	Latest and greatest	What works
Learning Curve	Typically long	Short
Support	None to Informal	Must
Documentation	Minimal and techy is OK	Must be complete and easy to understand
Bottom Line	If it's cool they will come	If it doesn't work, they will go elsewhere

 

Additional Resources

Book: The Last Place On Earth - one of the best management books I have read and a great adventure story

Book: The Mythical Man Month

Book: The One Minute Manager

Book: The Seven Habits of Highly Successful People - a must read for any graduate student or professional!