A Typical Project

Thinking Binaries Ltd
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]

prototyping, rapid prototyping, simulation, debug tools, software architecture, test tools, faster time to market