Test Equipment Product Line Josh Bowen Capstone Project Presentation 2

Outline Overview of Project Vision Project Plan Requirements Architecture Test Plan Executable Prototype

Action Items from Presentation 1 Add narrative to Vision Document Add use cases for product line use Add explanation of factory concept (Architecture Document) Quality Metrics – Demonstrate testing infrastructure (Prototype)

Project Overview Develop Sample Product Line Core Assets – Demonstrate Product Line Process – Produce Significant Prototype Fulfill Requirements of Capstone Project

Vision VisionE.doc The vision document was updated to include narrative of functioning product line Includes description of domain, product line concept, customers, important qualities Provides entry point and scope to project

Project Plan..\Project Plan-0.2.doc Specifies work products for each phase Provides timeline for project, highlights planned vs actual schedule Shows that project is significantly behind schedule Completion dates will need to be extended, attempting completion by the end of September 2009

Requirements RequirementsC.doc Filled in requirements for subsystems Continued Use Case -> Requirements style Includes requirements for both product line and implemented core assets Includes Features Survey along with calculation of implemented features

Formal Requirements Created formal specification of domain with UML and OCL Used USE tool FormalRequirements.doc Created document detailing the process of creating the model Created tests for each restriction and included tests in TestConstraints.cmdTestConstraints.cmd Demonstration

Architecture Majority of time spent in this milestone has been creating/testing the architecture View-0.doc, Views.doc View-0.docViews.doc Divided document into two documents to demonstrate “View Packet” technique Used SEI SAD template and “Views and Beyond” method

Architecture Using architecture to provide 1. Documentation of design decisions 2. Communication within development group 3. Communication to customers and implementers 4. Basis for design analysis and optimization Architecture is > 100 pages with 6 views Difficult to keep architecture consistent and complete “SAD should be up-to-date but not TOO up-to-date”

Test Plan Document specifies when/who/how/why testing occurs Relies heavily on unit testing Specifies importance/thoroughness of testing increases as product approaches qualification Unit tests are demonstrated in prototype Unit testing will need to be supplemented with user testing, however, focus should be on unit testing for the core asset development

Executable Prototype Demonstration - CommonArchitecture\CommonArchitecture\b in\Release\CommonArchitecture.exe CommonArchitecture\CommonArchitecture\b in\Release\CommonArchitecture.exe Following slides include screen shots, these will be used off-line. Presentation will include execution of actual prototype

Main Page Main page provides navigation to the rest of the application. Testing is inactive until self check completes without errors. Utilities allows for less used functions to be separated from main flow.

Configuration Files XML configuration files are used to configure – Tester – Parts Configuration file can be split into separate files for ease of editing. Put into file structure based on the executable location so that the entire program can be moved without installation. Provision made for new nodes, provides extensibility on top of the required and optional nodes AM PT1001 Parts..\..\Results.mdb Provider=Microsoft.Jet.OLEDB.4.0;Data Source=..\..\Results.mdb;User Id=admin;Password=; c:\Results DMM1 GPIB:1 Counter 1 GPIB:2 CNT:STA 1000 CNT:STP CNT:RTV? Query

Testing Parameters Notice use of base form to provide consistent UI Implements an interface so that form can be overridden

Test Run Inspection Provides verification of parameters before testing starts. Will require customization for most testers Easy customization by providing an overridable method to set contents

Testing Multiple Testing Forms available by setting configuration options, no need for creating custom code. Most elements optional, though ABORT button required Separate thread from testing, provides responsive UI

Devices Utility Uses forms assigned to tabs as controls Controls instruments in the tester directly Allows for generic or custom forms for controlling instruments

Factory Uses singleton factory concept for creating custom subsystems Allows for.exe to replace a subsystem within a.dll without recompilation of the.dll. Requires unit tests to assure that the replacement subsystems adhere to the interface Shared Sub Main() CTACore.Factory.SetPart("PartA", New PartA.PartA()) CTACore.Factory.SetPart("PartB", New PartB.PartB()) CTACore.Factory.SetTest("CoilResistance", New PartA.TestCoilResistance) CTACore.Factory.SetTest("FileCount", New PartB.FileCountTest) CTACore.Factory.SetDevice(New DMM, "DMM") CTACore.Factory.SetTestingForm(New CTACore.frmTestingTS) Dim MyTester As Tester = Factory.GetTester() If System.IO.File.Exists(Application.StartupPath & "\TesterSettings.xml") Then MyTester.LoadSettings(Application.StartupPath, "TesterSettings.xml") Else MyTester.LoadSettings("C:", "TesterSettings.xml") End If Dim MainForm As frmMain MainForm = Factory.GetMainForm() MainForm.SetTester(MyTester) MainForm.ShowDialog() End Sub

Unit Tests NUnit used to provide testing in prototype Final product will (hopefully) use Team System Three sets of unit tests to be created 1. Interface testing 2. Qualification testing 3. Metrics testing