1 / 24

Automated Support for Requirements and Validation Test as Development Drivers

SV04 – ICSSEA 2004. Third Workshop on System Testing and Validation Session 1: Test Methods. Automated Support for Requirements and Validation Test as Development Drivers. Pedro P. Alarcón Juan Garbajosa Alberto Crespo Technical University of Madrid (Spain) Belén Magro Invensys (Spain).

ulf
Download Presentation

Automated Support for Requirements and Validation Test as Development Drivers

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. SV04 – ICSSEA 2004 Third Workshop on System Testing and Validation Session 1:Test Methods Automated Support for Requirements and Validation Test as Development Drivers Pedro P. Alarcón Juan Garbajosa Alberto Crespo Technical University of Madrid (Spain) Belén Magro Invensys (Spain) SV04, 2nd December 2004

  2. Contents • 1. Introduction • 2. Automation Support Architecture • 2.1. Test and OPeration Environment • 2.2. Software Engineering Environment • 2.3. CASEML Documents as Integrator Element • 2.4. TOPEN-SEE Operational Integration • 3. Traceability and System View • 4. Conclusions • 5. Acknowledgments SV04, 2nd December 2004

  3. Requirements Components Validation Tests 1. Introduction • Automation to apply validation tests as a development driver • Tests must be adequately integrated with requirements • Traceability plays an essential role in integration • The tool approach • integrates • a test and operation environment (TOPEN) • a Software/System Engineering Environment (SEE) with the concept of document underlying • possibility to develop systems using validation testing as a joint process to requirements engineering • compliant with the space engineering ECSS-e-40 process model SV04, 2nd December 2004

  4. 2. Automation Support Architecture • Approach based on four issues: • A specific environment for system validation (TOPEN) that focuses on automating validation processes including test definition, and execution • A System/Software Engineering Environment (SEE) that provides the infrastructure required to support requirements specification, component specification, tests specs and reports, and finally traceability • Documents integration of TOPEN and SEE • Integration of TOPEN and SEE from an operational point of view SV04, 2nd December 2004

  5. MONITORING UUT SYSTEM UUT I. TOPEN 1…N 1….N UUT INTERFACE SW API UUT INTERFACE HW INTERFACE WITH API TESTING TOPEN SYSTEM INTERFACE WITH SYSTEM UUT I. 2.1.Test and OPeration ENvironment SV04, 2nd December 2004

  6. 2.1.Test and OPeration ENvironment • An Operational View of TOPEN Architecture MMI MIB database MIB CG GATEWAY UUT TOPEN MMI (Man Machine Interface) SV04, 2nd December 2004

  7. 2.2.Software Engineering Environment • Software Engineering Environment: SEE • supports the development of systems conform to a given software process model • at present it supports the ECSS-e40 • it could potentially support other standards • is document-centric • all the project data can be available as documents • supports part of process integration and data integration • documents are defined in CASEML • CASE Mark-up Language (language derived from XML) • Nodes include the document structure together with nodes to support traceability to other document nodes • CASEML-Schemas to define valid structure for documents • tools integration SV04, 2nd December 2004

  8. 2.2.Software Engineering Environment Structure for any CASEML-Schema in SEE CASEML-Schema for a System Specification Document SV04, 2nd December 2004

  9. CASEML-Schema For System Specification Document <CASEML ID="1" V="*" STRUCTURE=""> <HEADER ID="2" V="*" CLASS="" TYPE="" NAME="SS STRUCTURE" ...../> <COMMENT ID="3" V=""/> <CONTENT ID="4" V=""> <TAGS ID="5" V=""> <TAG ID="*" V="*" TAGNAME="CASEML" CLASS="ROOT" TYPE="CASEML"> <DEFAULTVALUES ID="*" V="*"> <ATTR_VALUE ID="" V="" NAME="SEETREENAME" DEFAULT="SS"/> </DEFAULTVALUES> <CHILDREN ID="*" V="*"> <CHILD ID="*" V="*" NAME="HEADER" MIN="1" MAX="1"/> <CHILD ID="*" V="*" NAME="COMMENT" MIN="1" MAX="1"/> <CHILD ID="*" V="*" NAME="CONTENT" MIN="1" MAX="1"/> <CHILD ID="*" V="*" NAME="TRACES" MIN="1" MAX="1"/> <CHILD ID="*" V="*" NAME="CM" MIN="1" MAX="1"/> </CHILDREN> </TAG> ............ </TAGS> </CONTENT> <ATTRIBUTES ID="" V=""> <TAGCLASS ID="*" V="*" CLASS="ROOT" TYPE="CASEML"> <ATTRIBUTE ID="*" V="*" NAME="ID" DEFAULT=""/> <ATTRIBUTE ID="*" V="*" NAME="V" DEFAULT=""/> <ATTRIBUTE ID="*" V="*" NAME="CLASS" DEFAULT="ROOT"/> <ATTRIBUTE ID="*" V="*" NAME="TYPE" DEFAULT=""/> <ATTRIBUTE ID="*" V="*" NAME="STRUCTURE" DEFAULT=""/> <ATTRIBUTE ID="*" V="*" NAME="SEETREENAME" DEFAULT=""/> </TAGCLASS> .......... </ATTRIBUTES> <OPERATIONS ID="" V=""> <CLASS ID="*" V="*" CLASS="ROOT" TYPE=""> <OPERATION ID="*" V="*" NAME="Display" COMMAND="GUIsee::display"/> <OPERATION ID="*" V="*" NAME="Edit" COMMAND="GUIsee::edit"/> <OPERATION ID="*" V="*" NAME="Save" COMMAND="File::Save"/> <OPERATION ID="*" V="*" NAME="Print" COMMAND="Tree::Print"/> <OPERATION ID="*" V="*" NAME="Obsolete_Traces" COMMAND="Configuration::ObsoleteTraces"/> <OPERATION ID="*" V="*" NAME="Traceability_Matrix" COMMAND="Configuration::Traceability"/> <OPERATION ID="*" V="*" NAME="Close" COMMAND="GUIsee::CloseTreeWindow"/> </CLASS> .......... </OPERATIONS> </CASEML>

  10. 2.2.Software Engineering Environment SV04, 2nd December 2004

  11. 2.3. CASEML Documents as Integrator Element • Involved documents • System Specification Document • Software Requirements Specification • Software Validation Test Specification • Software Validation Test Report SV04, 2nd December 2004

  12. 2.3. CASEML Documents as Integrator Element • “Software Validation Test Specification” Document SV04, 2nd December 2004

  13. Paragraph Node Graph Node 1 Test Node 2 2.3. CASEML Documents as Integrator Element • “Software Validation Test Specification” Document SV04, 2nd December 2004

  14. 2.3. CASEML Documents as Integrator Element • “Validation Test Report” Document SV04, 2nd December 2004

  15. 3 4 2.3. CASEML Documents as Integrator Element • “Validation Test Report” Document For each of the uniquely identified software validation test, this section shall report the detailed results of each software validation test SV04, 2nd December 2004

  16. 2.4. TOPEN-SEE Operational Integration • Common framework for software developers and test engineers • allows to specify, to execute and to store execution results for validation tests from a Software Engineering Environment. • a mediator component has been created • Three levels of integration are available: • TOPEN in standalone mode • TOPEN in off-line mode (Access to Data of Test) • TOPEN in on-line mode (Validation Test Execution) SV04, 2nd December 2004

  17. 2.4. TOPEN-SEE Operational Integration Data Sources Server MIB database GUI MIB (2) Topen-See Mediator (1) SEE CG (3) GATEWAY CASEML Repository UUT1 TOPEN SV04, 2nd December 2004

  18. 2.4. TOPEN-SEE Operational Integration (1) (2) (1) (3) SV04, 2nd December 2004

  19. 3. Traceability and System View • A system understood as a number of components can be developed incrementally • Validation tests allow us to understand how close we are to what the user requires • Those components not yet developed can be simulated • This approach can be applied mainly if a proper tool infrastructure is underneath. It requires that validation tests can be executed easily, and that also easily we can get which requirements and which components are related to a test that failed SV04, 2nd December 2004

  20. Requirements Components Validation Tests 3. Traceability and System View • Traceability plays an essential role in integration • Traceability support at the level of document node allows to have permanent relationship • Traces subtree in Caseml documents • a node includes Source and Target nodes • trace allowed between predefined types of nodes • traces can be added, modified and deleted • generation of traceability matrix SV04, 2nd December 2004

  21. 3. Traceability and System View SV04, 2nd December 2004

  22. 4. Conclusions • Validation tests as a driving force in system/software development • A close integration of requirements, validation tests and components specifications is required; this is achieved combining the document paradigm support and implemented traceability dependencies • Automation approach based on the integration of SEE, a document based environment that supports ECSS-e-40 process model, and TOPEN an environment for defining and executing validation test procedures • Future work will be focused in two directions: • to enable this environment to support domain oriented system development such as wireless telecommunications • to improve the process support for evaluation and analysis SV04, 2nd December 2004

  23. 5. Acknowledgements • Thank you all, for your attendance. • TOPEN and SEE environments have been developed in a number of national and international (EU and ESA) projects. • This work has been sponsored by AGMOD project. SV04, 2nd December 2004

  24. Software Engineering Environment SV04, 2nd December 2004

More Related