Test Equipment Product Line

1. Test Equipment Product Line Josh Bowen Capstone Project - 2009 Presentation 1

2. Outline • Overview of Project • Project Vision • Project Plan • Demonstration • SQA Plan

3. Project Overview • Create a set of core assets that will form the basis for a software product line for the test equipment domain. • Focus on the process and its potential application at the NNSA’s Kansas City Plant. • The end product should be a set of assets that can yield a set of testers along with supporting documentation.

4. Test Equipment • Basic Tester Concept • Apply Stimulus • To A Unit • Take Measurements • Record Results • A tester is a device that determines if a product has been built correctly

5. Software Product Lines • Set of Software Intensive Systems • Sharing Common, Managed Features • Developed From Core Assets • In a Prescribed Way

6. Applicability of Product Lines To Testers • Testers are conceptually identical • Testers have very different qualities depending on the type of tester • A product line would enable the reuse of the majority of a tester executive while allowing the rest to be custom built to support a tester’s unique requirements

7. Product Line Challenges at KCP • Nobody knows what it looks like! • Past reuse initiatives have had limited success. • Nobody wants to give up their current freedom. • High up-front cost.

8. Bottom Line • The organization is being required to change to create commonality and reuse. • If we don’t create the solution one will be imposed. • Product Lines are better than the alternatives. • A limited implementation must be demonstrated to promote adoption.

9. Vision - Background • Approximately 40 engineers creating software, 1-2 per tester • The current tester development process is ‘clone and own’ • Organization is organized around the type of part to be tested with little communication between domains • The definition of tester executive components is not standard

10. Vision – Goal • The goal is to show what a product line ‘looks like’ and demonstrate applicable programming techniques • Long term goal is to promote product line adoption to reduce costs, improve quality, improve consistency • Main technical challenge is to make the code highly flexible • Subset of core assets will be created: • Code sufficient to support simulated testing • Reference Architecture, Sample Variability Matrix • Unit tests, Test Case Templates, Implementer’s Guide

11. Vision – Constraints / Risks • Published documents must be approved by company • Process must be created for a team, project is to be undertaken by individual • Potential Scope >> Practical Scope • Existing projects may have significant impact on Product Line project

12. Vision • Link to Vision Document: VisionC.doc • Elaborated requirements have been put into requirements document: RequirementsB.doc

13. Vision • Customers dictate driving requirements and are the most important takeaway from vision Brooks Law

14. Requirements / Scope • Project Includes • Architecture, Reusable Components, Process Templates, Testing Resources • Examples of each of these will be included primarily to show how they can be documented and executed • Project Excludes • Hardware, Instrument Drivers, Support for Non-KCP users and calibration software • These will need to be in a full product line, but this limited implementation will exclude them

15. Project Plan - Inception • Work Products – Currently Completed • Vision • Requirements/Scope • Risk Analysis • Architecture Alternatives • Architecture Analysis Plan • Project Plan • Configuration Management Plan • SQA Plan • Executable Prototype

16. Work Products – Completed by presentation 2 Phase 1 Artifacts, Action Items Architecture – Formally Defined Requirements – Formal Requirements Prototype (Executable Architecture) Detailed Work Breakdown Structure Test Plan Formal Technical Inspection Checklist/Results Make/Buy/Mine/Commission Analysis Template This phase will focus on creating the architecture of the solution SEI SAD template will be used to document architecture – This will be the primary document that undergoes technical inspections Several simple prototypes will be created to ensure viability of architecture Formal Technical Inspection Participants: TBD Project Plan - Architecture

17. Work Products – Completed by Presentation 3 Artifacts from Phase 1 + 2 Action Items AF Document (End User Instructions) Implementer’s Guide Detailed Design Product Baseline Test Results – Assessment Evaluation Project Evaluation References Formal Technical Inspection Letters Future Release Opportunities List This phase will focus on implementing the solution Testing artifacts will be created in this phase Project Plan - Construction

18. Project Plan - Timeline

19. Project Plan - Cost Estimate • Top Down vs Bottom Up • Early in project estimate costs according to previous experience • After subsystem architectures are defined estimate and sum costs of subsystems • COCOMO II may not be appropriate due to high-level nature of .Net and development tools

20. Project Plan - Cost Estimate

21. Demonstration • Demonstration of executable prototype: bin\CTAPrototype.exe • Architecture Alternatives: ArchAlternatives.doc • Architecture Analysis Plan: ArchPlanB.doc

22. Demonstration • To fulfill the demonstration requirement of the project three tester implementations will be created from the core assets • Minimal changes from the core assets • Replace a sub-system • Use a sub-system in another tester (stand alone stub) • These will ensure the assets meet their driving requirement - Flexibility

23. SQA Plan • Based on IEEE Standard • SQAPlanB.doc • This is intended to be a basis for SQA of a production product line • The processes within this document will be followed to the degree possible • Quality metrics will include outstanding tasks, % unit tests passing

24. Conclusion • Project is designed to demonstrate a concept. • Project will create a library that can be used to create a number of individual products. • Documents included in milestone 1 create the process and define the general architecture that will be used throughout the rest of the project.