Cascade model
Any project over its life goes through the following steps:
- Auction or bidding.
- The development of requirements specification (RS).
- The development of functional design (FD).
- Detailed assessment of the term.
- Development.
- Support.
Auction
At this stage, the client is preparing a brief or full RS, or simply sets forth the idea of the project, that is what he wants to get as a result of the development. Our main tasks at this stage:
- The analysis of provided RS or making a brief RS in its absence.
- The analysis of provided FD or making a brief FD in its absence.
- Preliminary assessment of the term. It should be maximum accurate for the current version of FD and RS.
These three stages are free
Evaluation of the term provided in the bidding (AE - auction estimate) is the sum of pre-assessment of the term(paid by the customer time), 30% for project management (paid by the customer time), 30-40% for contingencies (for example: sick, etc. ) This is non-paid by the client time.
Provided estimation is approximate and we have the opportunity to change it after we receive the final version of RS and FD. We must notify the customer that this estimate was made on the basis that everything will be done the easiest way for us. AE is served to the customer at the auction. We do not underestimate time. Assessment of the term should be realistic and reasonable. If the customer asks to argue estimate, we always have the opportunity to give him a document (in the form of Excel spreadsheets, project MS Project, etc.)
It is important to understand that if the customer will provide detailed RS, then in any case we would have issues and supplements to him and FD. We have to notify the customer about this fact. Time to be spent on questions and clarification of RS and FD, or to prepare a full RS and FD (if they were not provided by the customer) to be paid. That is the main rule - The customer must pay for the preparation of detailed RS and detailed FD. If the customer does not agree to pay for this job, and refuses to give any his option, we exclude further cooperation.
Specification
Specification, as a rule, can not be developed by a non-programmer (a person must learn the ropes in analytics, technology, databases, etc.).
In case if specification is provided by the customer , we must:
- Analyze it carefully. It is desirable that several people were involved in this process. You can conduct a parallel analysis, and then combine the accumulated problems, ambiguities, suggestions.
- The list of questions and suggestions is sent to the customer in one package
- After customer’s answering it is necessary to repeat points 1) and 2) once again with the information received from the client. Cycle of analysis must be repeated as long as it does not suit us and the customer.
In case if we develop RS ourselves we must:
- Expand prepared earlier a short specification, review all the control points. Be fully convinced that it has no contradictions, items which we can not implement at the moment.
- In this version, we usually (but not always) can specify ourselves with used technologies. We choose technology consciously, that is first we must specify for ourselves why it is necessary to use such technologies in this project.
- Dispatch completed RS to the customer. Getting questions (usually in the form of notes), we respond to them , if necessary, extend RS, conduct the second analysis and again refer to the customer. We continue the cycle of development of RS as long as it does not suit us and the customer.
Note: Do not underestimate the importance of analyzing RS. As this can lead to serious problems. For example, a wrong assessment of the time, and hence the delay in the timing of delivery of finished product, which can be caused unwanted conflict.
Functional design
Functional design is a document that accompanies RS, which shows on specific examples (in the schematic screens), how the future system will operate . If this is a website, it is usually a detailed description of the logic work of all its pages, if desktop- application is a description of the functioning of all its forms (in the schematic screens), ability to configure, etc. That is, functional design should fully reflect what the future product will functionally be.
Functional design, as a rule, can be developed not by the programmer. For the preparation FD it is necessary to know how to work with a computer, able to work in office applications, browsers, learn the ropes in analytics. But, nevertheless, for certain types of problems, for example, if the developed system is independent from the graphic interface (GUI), for example, using third-party file storage, development API, and so on, it is advisable to involve just the programmer.
Note: Do not confuse functional design with web-design, as they are different things. Web-design is developed separately from developed system as it requires its own RS and FD (Flash, AJAX and other dynamic effects), which should be discussed with the customer as far back as the development of RS. The system and web-design should be done parallel in order to avoid contradictions. If the client makes web-design himself, then we must discuss the next moment with him - it is the best to start doing web-design after the development FD by ourselves. If it is more important for the customer to preserve the form of web-design, which he prepared in advance, then we must carefully analyze prepared web-design before drawing FD. The time spent on this analysis, is included herewith in FD.
Functional design should be a finished product, that is, even if we will not do this project, we have to do it qualitatively, to resolve all contentious issues, to make sure that after reading it there will not be questions. Then you can send FD to the customer. It is necessary to explain to the customer that FD is a document on which he and we will check the quality of the software product.
Detailed assessment of the timing
Detailed assessment of the timing (DAT) is a document that contains time estimates (time), for which we are guaranteed to perform a particular task, for all elements of FD. In compiling the DAT we act according to the following algorithm:
- In drawing up the DAT, we proceed similarly, as we did the RS (deploy few people), but we must take into account individual characteristics (abilities, skills) of the developer - a person who is the executor directly. That is, the developers should be binding partners making the DAT. Typically, the DAT takes the form of an Excel or MSProject. It is greatly important that there would not be problems in assessing the timing with the assessment of more than 12-16 hours. If there were any found, then it must be divided into subtasks and it is necessary to perform an assessment separately for each task. This limit is set to minimize errors in the evaluation. After we have done the DAT it must be added 30% of the time for testing and debugging, and 30% for unforeseen circumstances of unpaid buffer. If the project is large, and it must be more than one programmer for its development, we add optional another 30% paid on project management with a buffer reduced to 20% for unforeseen circumstances.
Evaluation of the timing should be provided in summary form for the customer. That is, we make a similar total time, but we combine the problems into larger (such that it is clear even the non- programmer). We share the project on semantic stages of the development - the control points (MILESTONES). We obtain the document in a format that is shown in Table 1.
- After having made the DAT, we send it to the customer.
- Receiving an answer we are beginning to analyze the customer’s requirements. Perhaps some periods will be pretty big for our client, and we have to consider deciding any problems we are able to save time. And we repeat steps 1 and 2 as long as the assessment does not suit the customer and us.
According to the document the customer and we will monitor our joint work , namely its cost and duration.
Table 1
| Milestone |
Human/hour |
Dollars/hour |
| 1 |
210 |
6 |
| Big issue 1 |
100 |
|
| Big issue 2 |
50 |
|
| Big issue 3 |
60 |
|
| 2 |
150 |
7 |
| Big issue 4 |
50 |
|
| Big issue 5 |
75 |
|
| Big issue 6 |
25 |
|
| ... |
... |
... |
| Summary |
800 |
1024 |
Development
Development of the project is carried out in working order in accordance with established statute, code and notations.
Support
Support of the project is carried out in working order in accordance with established statute, code and notations
