------------Approach to Project Work------------
1.0 Overview
There are two main philosophies of project development; one is the waterfall approach, where the software is released in one big bang at the end of the project. The other, common in object-oriented design, is the prototype approach, where at regular intervals fully working subsets of the final project are released. Each of these prototypes represents production quality software, tested and integrated. In many projects you'd be strongly recommended to choose the latter approach (i) to avoid analysis paralysis and (ii) to try to ensure good quality software.
A process for developing software using this iterative approach is to consider the project divided into four main phases:
Inception is doing some work to see whether it's worth doing the project at all. It's a few hours work before a few days' work, or a few weeks' work before one or two years' work. Some of the use cases will be partially developed. At the end of this period, a go/no go decision will be made.
Elaboration involves:
During construction, a series of time-boxed iterations drive the implementation of the use cases described during elaboration, so that at each iteration a certain number of use cases will be built, unit tested and then integrated and tested into the production quality software already produced.
Transition is the phase in which beta testing is done, as well as user training and performance tuning.
In addition to production quality prototypes being released during construction, other forms of prototypes might be built during the early stages of the project.
1.1 Risk
The main forms of risk to be considered are:
technological risk: Is the software and hardware available to develop the project? Will the various software components fit together? For example: if someone were doing a project using Java and databases, the area of technological risk is fitting the Java code to the database, and not so much in the Java software or the database software themselves.
skills risk: Have we the necessary skills to do the project and, if not, can we acquire them in advance of the project phase in which they'll be required?
requirements risk: In the case of a project that has an well-defined external client, do you understand exactly what he/she/it requires you to do? This can be immensely complex to say the least!
1.2 Use Cases
A use case is a collection of scenarios, tied together through the aim of meeting a particular user goal. For example in an on-line shop, a use case might be "browse the catalogue and buy some goods". Among the scenarios here would ones relating to (i) new customer (ii) registered customer. At the elaboration phase a use case needn't consist of more than 1 to 3 paragraphs of text, accompanied by an optional use case diagram. Generally the riskier a use case is likely to prove, the more work will be done on its description. The construction phase will involve fleshing out each use case more fully in preparation for building it. Use cases drive the whole development process. Their sum is the external description of the system. In addition they drive the planning process leading to construction, since in each iteration, one or more use cases are built to add to the existing production quality prototype.
This page will be updated at regular intervals throughout the year.