1 / 20

Test Equipment Product Line

Test Equipment Product Line. Josh Bowen Capstone Project - 2009 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

dedwards
Download Presentation

Test Equipment Product Line

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. Test Equipment Product Line Josh Bowen Capstone Project - 2009 Presentation 2

  2. Outline • Overview of Project • Vision • Project Plan • Requirements • Architecture • Test Plan • Executable Prototype

  3. 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)

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

  5. 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

  6. 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

  7. 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

  8. 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.cmd • Demonstration

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

  10. Architecture • Using architecture to provide • Documentation of design decisions • Communication within development group • Communication to customers and implementers • 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”

  11. 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

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

  13. 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. Main Page

  14. 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 <?xml version="1.0" encoding="utf-8"?> <Tester> <AMNumber>AM1001</AMNumber> <AMSuffix>101</AMSuffix> <Nomenclature>PT1001</Nomenclature> <PartLocation>Parts</PartLocation> <ResultsDB Type="Access"> <DataFile>..\..\Results.mdb</DataFile> <ConnectionString>Provider=Microsoft.Jet.OLEDB.4.0;Data Source=..\..\Results.mdb;User Id=admin;Password=;</ConnectionString> <DataDirectory>c:\Results</DataDirectory> </ResultsDB> <Devices> <Device Type="DMM"> <Name>DMM1</Name> <Address>GPIB:1</Address> </Device> <Device Type="Counter"> <Name>Counter 1</Name> <Address>GPIB:2</Address> <DeviceCommands> <DeviceCommand ID="StartCounting"> <CommandString>CNT:STA 1000</CommandString> </DeviceCommand> <DeviceCommand ID="StopCounting"> <CommandString>CNT:STP</CommandString> </DeviceCommand> <DeviceCommand ID="GetCount"> <CommandString>CNT:RTV?</CommandString> <Type>Query</Type> </DeviceCommand> </DeviceCommands> </Device> </Devices> </Tester> Configuration Files

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

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

  17. 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

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

  19. 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 Factory

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

More Related