HCG Development Methodology
In today’s highly competitive climate, organisations need to develop innovative new information systems to support mission-critical products and services.
HCG's development methodology has evolved through the many projects we have successfully completed.
The HCG development methodology may be referred to as:
 |
Incremental, |
|
Phased, |
|
Spiral or |
|
Prototype development. |
The philosophy is to analyse the overall system to define an application "architecture", then from within the framework of the architecture, analyse and build sub sections of the application in controllable chunks that the user and HCG can comprehend and that can be implemented quickly. If the implementation does not meet user requirements, in general the process is repeated until the application is refined to the point where user requirements are satisfied.
HCG develops projects with this phased approach. This allows for the development of an application flexible enough to support future requirements while effectively and affordably meeting today’s critical business requirements.
Throughout all phases, the client is provided with information to make necessary project scope decisions, with a clear understanding of their impact on cost and schedule.
The HCG change control process has proven effective for accommodating the expansion of requirements while controlling project scope.
Process
The following diagram defines the HCG methodology:
For the FIRST iteration around the loop, the process is:
Notes:
|
In general, the first iteration is focused on delivering the application architecture document and a prototype for user analysis only. |
|
In subsequent iterations, true functionality is added to the application. |
|
Each iteration typically spans 2 to 10 weeks. |
|
Higher productivity is obtained in shorter cycles
(i.e. it is better to have two four week cycles than one eight week cycle). |
|
If required, a very short cycle can be used to meet a critical business requirement. |
|
The review step (5) is the formal management sign off for the next iteration, however there is informal management review at each step within each iteration. |
|
This allows for very rapid application development, so the steps can some times get a little blurred (e.g. the review process will be happening at the same time as the build process) |
For each SUBSEQUENT iteration around the loop, the process is:
Benefits
The HCG methodology has clear and tangible benefits:
|
Customised application to meet user requirements. |
|
User involvement and commitment to project. |
|
Users contribute creatively to the design process. |
|
Client management have control over the development process. |
|
Smooth transition into production environment. |
|
Generates user confidence and buy in as the project evolves. |
|
Early in the development process, users gain experience with the system which can also be used as a training tool. |
|
Users are not confronted with an excess of systems development jargon. |
|
Reduction in development time. |
|
Users understand prototypes better than written specifications. |
|
With HCG's advanced toolset, the prototype is quicker to build a than a full written specification. |
|
Reduces the requirement for formal written specifications. |
|
Errors and omissions can be caught early in the development process. |
|
It works! |
Risk Management
Our experience has shown that like all other methodologies, there are risks associated with our methodology:
|
Risk |
Counter Measure |
| 1. Design can lose structure |
At the start of each cycle the system design is reviewed at the top level. |
| 2. Some users tend to "grow" their requirements |
Client management need to supervise and control expectations. |
| 3. There is a temptation to make an early prototype the production system. |
During the review sessions the limitations of the existing system have to be clearly stated. |
| 4. Users may be too casual about the prototype and may not take the time to identify potential flaws. |
Key liaison users have to be selected by the client that have strong buy in to the project's success. |
| 5. Harder to deliver on a fixed price for the overall project.
| If the client wants a fixed price development project, then the options are:
|
Fixed price per loop or |
|
Single loop only | |
It is essential that both the Client and HCG management are aware of these risks and actively avoid them.
Historically, software development is a risky undertaking. Using these techniques it has been shown that risk can be significantly reduced.
If there is a application component that is considered "high risk" it can be put through a cycle by itself without risking the rest of the application development.
Each project is assigned a Project Review Team consisting of:
|
Client Project Manager, |
|
Client representative from each department using the system and |
|
HCG Project Manager. |
The Project Review Team is responsible for managing progress of the project.
At HCG we use the Microsoft Visual Source Safe tool for storage of all programs and documents. In this way, if needed, we can recover any previous versions of our work.
The major risk in any Information Technology project is inexperienced or unqualified personnel. That is why we have focused on building a high calibre team.
Other Development Tasks
This methodology only relates to the strict development processes, other related project tasks need to be implemented in parallel such as:
|
Hardware selection |
|
Hardware implementation |
|
Documentation development |
|
User training |
|
Data migration |
Documentation
The following documentation would typically be produced during the development life cycle:
The actual documentation produced will depend on the client's specific requirements.
While it is common to call this a prototype methodology, it is not a true prototype methodology as the previous version of the prototype is always used as an integral input to the next phase of the development. In general using the HCG methodology, a development cycle should never be discarded to build the next iteration unless the cycle has shown that a major change is needed in the requirements. | 
