F/A-18 Interactive Electronic Technical Manual (IETM) Verification Lessons Learned

1. F/A-18 Interactive Electronic Technical Manual (IETM) Verification Lessons Learned ATCS Jeffrey Woell NAWCAD R& M Division jeffrey.woell@navy.mil

2. IETM Verification Lessons Learned • Why Verification is needed? • The configuration sensitivity and enhanced capabilities of a Type II IETM vice traditional paper technical manuals introduces new potential data errors: • Task Linking Errors (referential issues) • Missing/Incorrect Configuration sensitivities • Graphics associations • Step Sequencing • Increased performance expectations from the Fleet of the IETM raises the quality bar • Every data error is taken as proof that IETMs are worse then paper • Provides an opportunity to assess the Integrated IETM product (data, presentation system, business rules, and software infrastructure)

3. IETM Verification Lessons Learned • Performing a Type II IETM Verification • Government must take the responsibility for performing an independent verification of the IETM product • Verification team should include IETM Author representation in an integrated/supporting role • Verification plan should be modeled after Systems Engineering based Test Plans and not after the traditional paper Verification plans • Formal system documentation should be developed and utilized throughout project life-cycle • Detailed formal MOAs, MOUs, Contracts/SOWs, and other interagency documents should be negotiated and signed between all involved team elements and the government team lead • Verifiers need significant personal experience with maintenance practices on the platform(s) being supported • Or at a minimum with the closest fit existing platforms were direct experience is not achievable (previous versions, similar platforms)

4. IETM Verification Lessons Learned • Performing a Type II IETM Verification • All elements of the Verification Team should receive robust training in the process and use of the IETM product to be verified • Critical to differentiating between system, data, and user errors • Fleet involvement from an operational and/or test squadron is a significant enabler • Creates a sense of product ownership by Fleet community • Provides pre-implementation opportunity to assess Fleet interaction with IETM product • Verifies IETM data and software functionality in ‘real-world’ environment • Anomalies should be addressed in parallel to the IETM Verification effort • Ensures IETM Authoring community has access to verifier • Aids in identification of systemic, training, software, and other errors not typically evaluated in the context of paper verifications • Allows taking full advantage of the decreased time to revise an IETM product vice paper