1 / 4

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

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

anisa
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related