|
There's a lot of talk floating around the Internet right now about this or that Beta software. In an effort to help you understand what people are talking about, I will try to clarify some of the mystery surrounding beta software and the Software Development Lifecycle (SDLC).
A lot of people come to me requesting a quote for a custom software solution to help them run their business more cost-efficiently. (You can see several of my finished projects here: MouseTrax Solutions.) Unfortunately, many times I have to pass on a project, because the potential client comes to me with a detailed request...and then tells me they need it next week! (Developers! Stop that, it's not nice to snicker!)
Sure, there are situations when a project can be finished in a very short time...such as a week. But it is rare and it requires a lot of organization and prior planning on the part of the client. Most folks don't understand the steps a developer needs to go through to get a working piece of software finished. And the projects I do are minor compared to big software companies, such as Microsoft...who is currently developing the next version of Windows and Office 2007.
Granted, different companies and different consultants have different ways of handling their own project planning. So this article will simply provide you with a basic overview of the general process.
Planning
Obviously, you can't attempt to tackle any project without some planning! The bigger the project, the more planning time you need. A consultant/client relationship for a small software solution may only need a few days or a week to discuss various potential aspects of a project. Companies like Microsoft start their planning several years in advance.
Background
The developers need to understand the background of what is needed. If this is a new client, it will also mean that the developer needs to understand what the company does and how they use their software.
Requirements
The client needs to sit down with all the people who will use the software and ask them...what's important? You need to decipher what the software should do. What problems will it need to solve? If the problem is too many people don't enter all the information into a form, that's important. That will help the developer see that you'll need validations to ensure that users complete the needed information. Or maybe you can code some of the more complex information into the form? If people never bother looking up an accounting code...why not put that information into the software. That way the user's can simply choose an item from a list and all the other details will be entered for them. They'll save time and you get all the info you require!
This wish list is vital in a development project. The client needs to know what their users want and this information needs to be put down in writing...with details!
Recommendations
The developer will generally go back and forth with the client to discuss various requirements and make specific recommendations regarding the best ways to implement solutions. Most clients have an idea of what they want, but don't always know what's possible. An experienced developer can offer a lot of suggestions about the best methods to use to get the wanted results. But, of course, the client should then go back and discuss these options, now that they know what can/cannot be easily done, with other members of the company who hold the purse strings, but also with the users. This will allow the client to hammer out a final list of specific requirements.
Samples
The client should be able to provide some samples of the proposed project to give the developer an idea of what they want. This may be as simple as copies of sample documents or may include complex diagrams. The developer may also create a prototype to let the client better see what is possible.
Proposal/Scope
Once both parties have a pretty good idea of what is needed and what is wanted, as well as what is possible...the developer will move forward to develop a written proposal. This can be a simple Proposal, maybe a Statement of Work (SOW) or a complex Project Scope.
This document will depend on the complexity of the project. I don't even want to think about the number of written documents that are produced for a project such as the current overhaul of Office 2003 to Office 2007!
I can generally get away with a proposal. But these documents...whether large/small...need to put detailed information in writing to ensure that everyone is on the same page. These documents outline issues such as...provide an Overview of the project; discuss the Objectives; layout the various Phases; explain the Implementation; provide details on various Concepts that may be in question; preview possible Risks; and put in writing all known Assumptions being made by both parties...and of course, provide Timelines and forecast Costs.
Approval
Once both sides hammer out all these details and finally come to an agreement, the work can actually begin.
As you can see, if you hate meetings...don't become a software developer!<grin> Granted, with small projects, a lot of this information can be outlined in a sentence or two. But some of you may have seen documents that are hundreds or even thousands of pages long to outline a software project. For the type of work I do, mine run from three to six pages, generally. But that's only if the client really knows what they want and several emails have already flown back and forth.
Development
Now the fun starts. The developer begins designing, coding, reworking, testing and cursing over the project.
At some point, they are satisfied enough that they have a workable product for initial testing. The first incarnation of this is called the Alpha version. This version is generally only seen by a few key people involved with the project.
Once it is agreed that the developer(s) is/are on the right track, work continues to refine the product.
Another milestone results when the next working version is ready for testing. Assuming all went well, this is most likely the Beta version. This version will usually go out to more users for wider testing.
Beta Testing
The client will discuss the Beta product with the testers and gather information regarding what they like, what they don't like, what works, what doesn't work. And, inevitably, the client/users will also realize potential for additional improvements that were not originally discussed...Change Orders!
This Beta testing phase can be a very, ahem, interesting time. I like to call this the you can't please everyone, but we'll try phase. If the client/users have their act together, you might get lucky. But moreover, this is a time of compromise. "Yes, that can be done, but it will cost you an additional...." And the more people involved, the longer this phase will take!
Back and forth it may go until all the bugs are worked out of the code to the satisfaction of the project managers, all original objectives are met, and as many wish list changes as can be accommodated, within the timelines and allowable budget, have been implemented.
When considering Office 2007, Microsoft sent out a Beta version some time ago and recently sent out a refreshed version of Beta 1. New Beta versions will continue to be released for testing for months on a project this large. Smaller projects can be handled in much less time...assuming key people don't run away on vacation!
Once all the testing is done, a Release Candidate will be presented for final approval. This version is generally opened up to many more users. This version should be the closest thing to a final version.
Final Approach
When it is agreed that as much as can be done has been done...within the scope of the timelines and cost barriers, the final product is released. And in the case of client projects, final payments are made, usually prior to release of the finished product. This version is often referred to as the Gold or Release to Manufacturing (RTM) version.
As you can see, there's a little more to it than slapping together a few macros. In the case of a small client project with few people involved, a development project can generally move along fairly smoothly. Unfortunately, most potential clients aren't aware of the process and don't consider all the information needed before they attempt to jump into a project. Many show up at the developer's door quite unprepared...usually because they don't yet know what's possible. An initial consultation with a developer to ask a stack of questions to find out if what you want is feasible, can be a good first step to tap an experienced developer's brain so you can be armed with information when you go back to start your planning. Expect to pay for this time.
With any luck, this article will help you plan your next small company project better. Make the most of your project timelines by planning ahead. Efficient planning will also help save you money, because by planning what you want/need ahead of the game, you'll have fewer change requests during the project. And since making changes after most of the base code has been implemented takes more time...better planning will save you money!
|
