compared with
Current by Godfrey Duke
on May 05, 2014 17:25.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
h1. Overview

Dataset agent Instrument Driver development is a complex process that required interaction between many people. The process can be broken down into three phases that will be driven by different system engineers and lead developers. These phases are *Specification, Development, and Integration*. During the specification phase the IDD IOS document is authored and verified, then code is written and verified (through qualification testing) in the development phase, and ultimately the driver is verified and integrated in within the larger system during a post-development integration phase.

*Current MI Dataset Roles*
|| Role || ||
| *MI Dataset Team Lead / System Engineer* | Steve Gaul |
| *MI Dataset Agent Software Lead* | Jeff Roy / Emily Hahn |
| *MI Driver Development Systems Team Lead* | Michele Lawton |
| *MI Driver Development Software Team Lead* | Godfrey Duke |
| *MI Software Engineer Lead* | Bill French |
| *MI Integration Team Lead* | Bill French |
h3. Verifying New Instruments Against Developed Drivers

It is quite possible that a driver will be usable for instruments on multiple platforms. When developing the driver it is important that we indicate which instrument(s) generated the data files we are developing against. Then the integration team will verify and integrate against the instrument(s) indicated in that case. It is possible that we will not have all instruments commissioned and producing data when the driver is developed and the driver will have to be verified against those instruments in the future and will need to be integrated independently of the driver development. However, we should follow the same development process for these instruments. An IDD IOS author will verify the files are the same, SE will ensure the instrument has sample stream and particle definition data files in confluence, driver developers will add automated tests, and finally it transitions to integration. Using this method we can have high confidence the driver will function as expected and should integrate easily.

{note} The second half of the above paragraph, starting with "However, ..." assumes staff will still be in place. Many of the first instance platform/instrument deployments and many follow-on deployments will take place after the development team has completed their baseline tasks. In any case, there is no budget or schedule in current plans for repeated test cycles. I agree that this repeated test should be done but there is no current plan for it. SGaul {note}

h1. Task Tracking