The engineering lead writes the product development plan. It sets the IEC 62304 lifecycle, the design phases and their reviews, configuration management, the traceability plan and the verification and validation approach. Engineers also read the client's existing code, models and data pipeline to judge what can be carried into the device and what must be rebuilt under design controls. The plan fixes where training and test data are stored and who can reach them, so the test set stays independent from the first day.
On the map: Product Development Plan. IEC 62304 lifecycle. Read the client's code and models.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Agree the device boundary with regulatory and cybersecurity before writing the development plan, and confirm with quality whose QMS it runs under. The boundary sets how much code needs documentation.
Engineers run the existing pipeline end to end and inspect its inputs and outputs visually. They look for data import errors, leakage between training and validation splits, and augmentation that produces unrealistic images. Code that is readable, tested and reproducible is brought under configuration management. Code that nobody can explain or rebuild is rewritten before documentation is written around it.
The plan names one version scheme for released builds and ties the major number to new premarket submissions. Source code, dependencies with pinned hashes and datasets each go under version control so any release can be rebuilt. Training and test data are stored apart, and the test store is closed to the developers.
The team picks one tool that links user needs, requirements, software items, risks and verification records. Links are kept current as work happens instead of reconstructed at submission time. Code review checks that each merged change updated its requirement, design and test records.
See the open positions and apply.