Working software, iteratively
For the second month's iteration, we ported the existing data-processing algorithms to the new architecture. Rather than testing these against data passed over hardware interfaces, we wrote production-quality import/export modules to provide the algorithms with data read from prerecorded data logs and to write the results to output files. Such modules are invaluable for providing unit tests for the algorithms; they enable the processing to be tested before hardware drivers or user interfaces are available. We also found the modules to be valuable for adding a demonstration mode and enhanced debug to the production system. Delivery of these features was as for the previous iteration, with the addition of automated integration tests demonstrating the interaction of multiple modules. As the software had been written in an OS-agnostic manner, the customer could run these integration tests on their desktop PCs. This let them perform data processing across a variety of data files recorded from their existing system and confirm for themselves that the results were as expected.
The third iteration saw the implementation of the hardware data interfaces importing and exporting data from the system. This was the first iteration where it was necessary to use the target hardware, and the delivery of this iteration was the first time that the customer, who for this project owned system level validation, could start their validation activities. All hardware drivers were developed in isolation with their own dedicated unit tests before being integration tested within the wider system.
We're now in the fourth iteration and we've moved from porting existing data sources to adding new hardware devices not previously used within the existing system. The customer gained flexibility in having an extra quarter to finalize the requirements for this new functionality, and we're working closely with the product owner to refine the requirements, safety cases, and so on, as we learn more about the new devices. Future iterations will introduce the new user interface and higher level application services. The customer, having full oversight, can choose which deliveries will be targeted for release and hence schedule formal validation, instigate change management, etc.
To summarize, by building modular components and managing dependencies on hardware, we have been able to deliver working software in early iterations followed by incremental introduction of software and hardware features. Our customer has really appreciated the level of visibility and collaboration that this iterative and collaborative approach allows, and they have been surprised at how quickly they have been delivered a working solution that they can validate themselves.
Mike Hogg leads an embedded development team within Zuhlke, an engineering consultancy. He and his colleagues have been using agile techniques and their precursors for over a decade in multiple sectors including telecoms, transport, and medical. He has 15 years development experience primarily in real-time embedded systems written in C++ and C, and he has also delivered business applications in Java. Mike writes the blog Agile Adventures in an Embedded World for Embedded.com.
Loading comments... Write a comment