Slashdot Mirror
Formalizing the Software Development Life Cycle?
James asks: "My employer is a small consulting firm. Our owners have always tried to sell us as a solutions provider and tried to land project based contracts. Currently though our only truly successful business model is staff augmentation. I feel that our main failures in project based contracts is in our bidding and software development process. Our sales staff always seems to oversell our capabilities (not technically, time and money...I cannot squeeze 70 hours of work into one day). I want to better formalize our processes and was looking into the IEEE/EIA 12207 standard. Has anyone gone though the pains of formalizing to this extent their software development life cycle? If so, are there any tips, good resources to look to for insights?"
I can't offer input here, but I can suggest you ask in forum for the Joel on Software software management discussion/article site. Good stuff there, good people.
It's not aimed at you (or rather, it is, in theory, but it's way overkill, and you'll spend more time doing meta-work than actually getting things accomplished.)
Instead, read some of the articles at Joel On Software, especially the Painless Software Schedules and Painless Functional Specifications He's somewhat arrogant, and he's a Windows developer (ex-Microsoft), but he's dead right on how to do basic functional specs and schedules. Once you've got something basic worked up, and have actually used it on a couple of projects, you can start looking at ways to improve.
As someone said above, the formal standards (IEEE, DoD2167a, etc) are way too heavyweight and complex for your environment. There are many many books on methodologies, but for small projects (say < 10 people for 1 year) you will want something very lightweight. One thing that's fashionable right now, and actually works, is "Extreme Programming". See http://www.extremeprogramming.org for a starting point.
Rapid Development by Steve McConnell is an excellent book with case studies and descriptions of a variety of development cycles that you can use to get your projects through.
I'm guessing when you say that your main problems are bidding and software development, you mean:
Bidding is usually too low and doesn't cover costs, or is perceived by clients as too high and they don't bite. Unfortunately, there's not much you can do to control how a client responds to a bidding process. Ideally, you bid once you have a clear idea of all the work that will go into the project; if you can display just how much work it will be to the client (all the different use cases, all the different interfaces that will be involved, all the testing and re-testing that will be required) they may be more understanding of your bid -- they won't feel they're being ripped off.
In the software development process, there are so many things that can go wrong. The first is that it takes too much time. (Or is over budget, but from my experience budget *is* time--a piece of software is purchased to reduce time, or additional people are hired to reduce time.) This generally occurs because there isn't a clear understanding of the scope of the project in the beginning. The other cause for taking too long is slow response from the customer on its needs.
The solution to this can be creating a non-working prototype that shows every screen and page that the program will use. This doesn't mean creating 26,000 screens if there are 26,000 records in the program. You create screens for one or two sample records (say, one for each major "condition", such as "Approved", "Unapproved", "Expired", etc.). You also create a screen for every entry form and a sample of each report that the program will have.
You show this to your customer and get their approval. Make sure that each form matches all of the fields that they want. Ask them if there is any information they would want to know that isn't on any of the reports or forms. Then you say to your customer, "Is there anything else this program needs?" If they say no, you say, "Okay, judging by x forms, y reports, and z interactive screens, we estimate that it will take at least n months and no more than m months, with a probable time of p months."
The customer is happy because you're giving them what appears (and is) a much more firm time estimate than something off the top of your head, and they understand the complexity and process that will go into the development.
The other advantage to this process is that it kills the other software development dragon: developing the wrong software (it doesn't do what the customer wants, and offers features the customer doesn't need). By developing a prototype of all the screens, you can do a "sanity check" on the software to make sure you have the same understanding of the final project as your client does. Also, once the prototype is built, you hopefully will not have any features that need to be added on mid-project.
I hope these tips work for you. They sure have helped me out. Keep in mind I've only used these for web development, but I'm fairly confident they will work equally well in other areas.
Karma: Chevy Kavalierma.