A Typical Project
|
|
|
|
intelligent software inside
|
|
While projects vary quite a lot, it's helpful to have a rough idea of a
typical project.
(1) Customer comes to us with a need for software development. This might
range in completeness from a rapid prototoype developed on a manufacturers
development kit, right through to developing final production quality firmware
for custom hardware. Typically the functional requirements of the product
are quite well known at this stage, but there may be a number of technical
unknowns, such as the size of processor to use, and the specific external
peripherals required.
(2) We agree a rough timescale and project spend, and if the project is large,
split it up into phases. We tend to invoice monthly at the end of the month
based on the amount of work done - we are a small company and that eases the
cashflow for us a bit.
(3) The first phase is usually all about risk reduction - i.e. deciding which
devices and peripherals to use, and where possible getting a manufacturers
development kit and proving that we can talk to all of the devices. If you
already have hardware at this stage, we'll do it on your hardware.
(4) The second phase is usually all about putting together a credible application
demo - this might be part on a dev kit, on your real hardware, or on the PC,
depending how much hardware is available at this time.
(5) The third phase is generally all about trying to get to first release candidate,
and involves the grunt work of putting the application together into a credible
product.
(6) Usually testing is managed by us doing some developer testing, and the
customer doing product verification and system integration testing - although
we do prefer it if we are involved in these phases, and we are used to working
alongside customer test teams to ease this process.
(7) There is often some work required to get a product running down a production
line smoothly. Typically customers have someone in-house that manages this
process, but we are usually highly involved in this phase ensuring that there are
necesssary calibration and test procedures written and working in the firmware.
(8) At some stage, there is normally a technology transfer, where we hand over
the software with a training course to someone in your organisation, and provide
some hand-holding for a while to allow your engineers to get up to speed on the
software. We can provide ongoing software maintenance and support, but it is
generally better if the long-term view is that you take control of and responsibility
over the full product eventually. We can always plan in product refresh projects
to clump together a set of bug fixes or feature modifications as a follow on
project.
| |
[protected email - turn on javascript to view]
| |
|