| Outsourcing |
Software Development |
| |
|
Our software development process is designed
to deliver the software our customer's want. That means it
has to allow customers to change their minds. It has to allow
us to rework our code freely to improve and optimise our designs.
It has to keep customers involved and the software visible
at all times. It has to help us be adaptable.
A brief overview of our process is described below. That said, being adaptable sometimes means changing the process itself. After all, two projects are rarely the same.
|
| |
Establish Requirements |
| |
System complexity often makes complete and accurate specification difficult. We try to solve this problem in several ways:
Our process allows changes to specifications to be made during development without impacting costs or timescales.
We regularly demonstrate progress, so required changes are spotted early with less impact.
We purposely organize development to produce a bare-bone application
first geared towards the functionality that can demonstrate
our understanding of the requirements and expose problems, misunderstandings
and inconsistencies. This may take the form a dedicated demonstrator
application that will be replaced once specification is agreed.
|
| |
| Quote a Fixed Price |
| |
|
If possible, the specification phase should
be a relatively short and separately costed activity. That
way, we should be able to estimate the effort more accurately
required to complete the job. Without a separate phase, it
is likely we will quote a higher price (sometimes significantly
higher) to allow for unforeseen problems and requirements.
|
| |
| Plan Deliveries |
| |
We will plan multiple deliveries, containing partial functionality throughout the development time. The content of each delivery will be discussed and agreed so that, as far as possible, the customer gets the functionality in their preferred order. We will also try to implement higher risk components first. |
| |
Develop the Software |
| |
Each delivery will have been tested, even though it only constitutes a partial system. This is because we develop our tests as we develop our code. As far as possible, these tests are designed to be automatic, so that retesting, following changes, is at the touch of a button. |
| |
Integrate and submit for Customer Acceptance |
| |
Once complete, the application is submitted for acceptance by the customer. This often involves the customer performing their own test and integration tasks. We'll help diagnose integration issues and make appropriate code updates to get the system working. |
| |
Formally Release and Document |
| |
Once integrated, the software is formally released. At this point, we would develop any documentation that is required. Our preferred documents are a Maintainer's Guide and a User's Guide, because these are useful to maintainers and users of the software. Often, there are many lengthy documents produced that add no value, apart from a tick in a Quality Assurance box.
We prefer not to develop design documents during the development process, as the document maintenance overhead reduces our ability to adapt to changing requirements quickly or cost effectively. |
| |
Initial Support |
| |
The software enters a free support period where we will agree to fix problems found when the software is in service. To some extent, this is included in the original price, unless exceptional response and bug-fix turnaround times are required. |
|
Maintenance |
|
A separately negotiated maintenance contract can include longer term support, or perhaps provision for changes and extensions to the software to be accommodated. |
| |
