The oldest software process is “code and fix”. This actually works on small one-man projects, but as a system grows, bugs become harder to fix. A typical sign of such a system is a long test phase after the system is “feature complete”. Such a long test phase plays havoc with schedules as testing and debugging is near impossible to schedule.
The classic response comes from engineering, whose methods try to plan the software process in detail for a long time span. The goal of engineering methods is to define a process that will work well whoever happens to be using it.
In an attempt to strike a balance between these two approaches, “agile” methods appeared and current best practice at OCC follows an adaptation of an agile methodology.
Agile methods follow iterative development: frequently producing working software with subsets of required features. This kind of adaptive process requires a close relationship with the client and encourages adaptive development. The advantage is that this lowers software risk – the client sees what they are getting early. However, the project needs to be held within the client’s business constraints – we are usually hired to deliver business critical systems on time and on budget.
At OCC we usually work on fixed-price contracts. Clients issue requirements, ask for bids, accept a bid, and then the onus is on us to build the software. A fixed price contract requires stable requirements and hence a predictive process.
We cannot fix all of (time, price & functionality) in software projects. The usual agile approach is to fix time and price, and to allow the functionality to vary in a controlled manner. At OCC we fix price and functionality and manage time in a controlled manner – at our own risk. That is, we typically guarantee delivery of agreed functionality for an agreed price. We then work towards the agreed deadline. As software development is not a predictive process the deadline is at risk.
In practice, OCC accepts the risk of slippage on fixed-price contracts because we are good at estimating timescales. For large projects, we often advise breaking the project up into smaller contractual projects to contain risk for both parties.
This behaviour by OCC means our method is best described as an Agile method called Feature Driven Development[1] (FDD). Feature Driven Development separates into two distinct project phases:
- Pre-proposal (Develop an Overall Model, Develop Features List and Plan By Feature) is a “one time” process and leads to the project proposal. If the project initiation is long and complex this becomes it own small consultancy project on a time & materials basis.
- The second construction phase is iterative and proceeds in a [design by feature – build by feature] manner incrementally delivering the project with high client visibility.
We’ve been developing software since 1989 constantly enhancing and adapting our methodologies and perfecting our processes, enabling us to deliver original, robust and flexible IT soltutions.