In the first installment of this series of posts I said that for a development effort to succeed in meeting its objectives, a series of steps should be taken, each one building upon the previous ones, without leaving any out. This series of steps or phases is called the System Development Life Cycle (SDLC). The phases are:
- The Definition Phase
- The Requirements Phase
- The Evaluation Phase
- The Design Phase
- The Implementation Phase
- The Final Documentation and Testing Phase
- The Maintenance Phase
Rookie developers often, after receiving a development assignment, start building the database and its associated application. Unfortunately, that is what should be done in the Implementation Phase. They have just skipped the first four phases of the SDLC and consequently, their chance of success is minimal. It is really important to go through all the phases and to perform all the tasks within each phase.
Every phase is important, but the Definition Phase is crucial, because if you don’t define the task properly at the beginning, there is no chance that the final product will meet your client’s needs.
There are five major tasks that must be performed as part of the Definition Phase. They are:
- Define the task to be performed. A database project begins when a person or group realizes that they have a problem and that a database is probably part of the solution of that problem. Depending on how experienced they are with such things, they may have a very clear idea of what the database should be and how it should perform, or they may have only a vague notion of what is needed. If you are called in to be the developer of this project, it is up to you to develop a detailed definition of exactly what the product of the development effort will do.
- Determine the scope of the project. In addition to defining the task to be performed, at this point you also want to estimate how big the project is. What equipment will be needed? How much system analyst time will it take? How much programmer time? What is the required completion date?
- Perform a feasibility analysis. The client has an idea of what she wants, when she wants it, and how much she is willing to pay for it. It is up to you to determine whether the project can be completed at all, given those constraints. If you determine that you cannot meet the requirements, you can negotiate for more time, more budget, or fewer features, or you can graciously decline to take the job.
- Form a project team. You might be able to complete a simple project by yourself, but for a big project on a tight deadline, you should build a team, where each member works on the part of the overall task that they are best qualified to address. Network with fellow professionals so that when jobs arise, you have a pool of qualified people you can draw from for a development team.
- Document everything. One important part of a development project that is often not given the attention it deserves is the documentation of what is learned and what is done. Seemingly, documentation is a side issue, perhaps to be taken up after the “real” work of producing the database is done. Nothing could be further from the truth. Documenting every step along the way is vital. It is the only way to keep things on track, starting with the initial specification of what the project is supposed to do and ending with the post mortem after it is finally retired for good. On countless occasions, you will find that detailed documentation will keep you from going down the wrong path, and often it will save you from the database becoming unmaintainable when a key team member leaves.
- Get the client to approve the Definition Phase document, in writing. It is important that you and your client be of one mind about exactly what the task is that you have been engaged to perform. Documenting exactly what you will provide (the deliverables) protects you both. It’s not uncommon for a client to tell you what you want, and then after you deliver it, say “Oh, but I thought we had agreed that you would also provide the “X” capability.” Fill in whatever you want for X. This all too common experience is called scope creep. The client wants you to do more, but does not want to pay you more for it. Your best defense is to get the client to sign the Definition Phase document at the conclusion of the Document Phase, before you start work in earnest on the project. If any additional work is desired beyond what is specified in the document, you are in a strong position to ask for additional payment.