The document discusses requirements for development processes and tools based on Automotive SPICE standards. It describes how an automotive company uses various tools like Doors, Trackers, CMDB categories, Wikis and document management to establish bidirectional traceability between requirements, designs, code and tests. URLs and hyperlinks are used to link related artifacts across different tools while maintaining the information in the original tools.

1. Automotive Spice ® Requirements for Development Process and Tools Markus Korn Hirschmann Car Communication GmbH Intland User Day 19.10.2011

2. About Hirschmann Car Communication USA Detroit Mexico Juarez France Domont Germany Neckartenzlingen Nuremberg Hungary Békéscsaba China Shanghai Japan Tokyo Korea Seoul

3. Employees 800 Employees thereof 120 Engineers

4. Business Units Antenna Systems Tuner Systems Integrated antenna systems Roof and rod antennas Hybrid (analog/digital) TV Receiver Digital TV Receiver

5. Hirschmann Car Communication in the car environment Electronics Telematics Car Diagnostic Radio-Tuner TV-Tuner Antenna Systems Devices Bus User Interfaces Navigation Mobile Communication

6. Content This presentation wants… … to show the major requirements of Automotive Spice to your development process … to focus on different tools of the engineering processes … to act as a kind of cookbook how you may combine tools with Codebeamer in a traceable way This presentation does not want… … to discus possible implementation of interfaces to various tools

7. What is Automotive Spice? ISO/IEC 12207 Software Life Cycle Processes ISO/IEC 15504 Information technology Process assessment Part 5: An exemplar Process Assessment Model = D S oftware D P rocess D I mprovement and D C apability D e termination Initiative of the Automotive Special Interest Group (SIG) P rocess A ssessment M odel (Version 2.5) P rocess R eference M odel (Version 4.5)

8. Process Assessments PRM describes processes base practices outcomes What is done PAM describes how to measure this How it is done  

9. The Process Groups and Processes of the Reference Model Management Project management Risk management Contract Agreement Measurement Acquisition Reuse Supporting Supply Process Improvement Supplier monitoring Technical requirements Legal and administrative requirements Project requirements Request for proposal Supplier qualification Reuse program management Quality assurance Verification Joint Review Documentation Configuration management Problem resolution management Change request management Supplier tendering Product release Process improvement Engineering Requirements elicitation System requirements analysis System architectural design Software requirements analysis Software design Software construction Software integration Software testing System integration System testing

10. What are Automotive SPICE ® Requirements for your Processes? There are defined Base Practices that a process must perform But there is no demand for a special tool to do this You must define quality targets and metrics to control them But you are not told which targets and what metrics to achieve Ensure consistency between sub-processes and their outcomes  establish bidirectional traceability But you are not told how to do this and with what kind of tools This can become time-consuming and painful: you may need very specialized tools in your development with poor or no interfaces you may have to use tools required by your customer …

11. Engineering Processes and bidirectional Traceability system architectural design customer requirements system requirements software requirements software architectural design software detailed design software unit test specification for software units software integration test specification software test specification system integration test specification system test specification

12. The Reality is … system architectural design customer requirements system requirements software requirements software architectural design software detailed design software unit test specification for software units software integration test specification software test specification system integration test specification system test specification Word PDF Doors Rhapsody Enterprise Architect Matlab Simulink Rhapsody Matlab Simulink OpenOffice Quality Center Excel PPT

13. How to establish all that Traceability? If you do not want to implement and maintain SW interfaces You should check your tools for a quite simple one: URLs everything in Codebeamer has a unique identifier and therefore a unique URL you can address various features from outside tickets documents CMDB items SCM commits

14. The Tools in our System Development system architectural design customer requirements system requirements software requirements software architectural design software detailed design software unit test specification for software units software integration test specification software test specification system integration test specification system test specification Wiki Wiki Tracker Tracker Wiki SlickEdit CMDB Categories Subversion Doors PDF Rhapsody PPT

15. The Trackers and CMDB „Backend“ System Requirements Software Requirements Tasks System Test Software Test Bugs System Elements SW Packages

16. Customer Requirements There are defined methods and tools for requirements interchange e.g. Doors eXchange Codebeamer Document Management We can link to from Wiki pages associate to tickets and CMDB items  Doors requirements stay in Doors Doors PDF Doors

17. System Requirements System Requirements Specification as a Wiki Page Provide additional information, images, hierarchical order etc. But the actual requirement is a ticket in the system requirements tracker linked to with [ISSUE:1234] System Requirements

18. The System Requirement Ticket We need to relate the system requirements with the customer requirements Each requirement in Doors has a unique URL in its properties You can add external links to each requirement Add Association  URL: doors://… System Requirements Paste Codebeamer URL of the ticket: http:/…/cb/issue/1234 Doors

19. The System Requirement Ticket We need to relate the system requirements with the customer requirements Add Association  [DOC:1234] Comment: Chapter heading where this relates to System Requirements Document Management

20. Traceability customer requirements system requirements Established for both Doors exchange and other requirements documents Maintenance: Whenever Doors Module changes check all system requirements of all suspected Doors requirements for impact by following external link to Whenever Document changes check all associated system requirements for impact Whenever system requirement changes check all associated documents and Doors requirements for impact

21. System Architectural Design Block diagrams describing the system CMDB Category „ System Element“ DEMUX xy DC/DC µC Name We „map“ the blocks to CMDB items Document Management upload Associate item with [DOC:2345] Add Hyperlink to CMDB item http://.../cb/item/1234 System Requirements PPT

22. CMDB Items and Tickets Block System Architectural Design URL CMDB Item Relation System Requirement Tickets System Requirements Association

23. Traceability Maintenance: add CMDB items/URLs if necessary check all CMDB items in document‘s association tab for impact Whenever block diagram is updated check system requirements in CMDB item‘s references for impact Whenever system requirement is updated check related CMDB items for impact check associated block diagrams for impact system architectural design customer requirements system requirements

24. Software Requirements As with system requirements: The SW Requirements Specification is a Wiki Page Provide additional information, images, hierarchical order etc. But the actual requirement is a ticket in the sw requirements tracker linked to with [ISSUE:1234] SW Requirements

25. The SW Requirement Ticket System Requirements Add new SW requirement ticket from within system requirement ticket SW Requirements In the ne SW requirements ticket choose the System Element CMDB items which are allocated A field relates to the System Requirements tickets

26. Traceability Maintenance: Whenever block diagram is updated – additionally to the slide system requirements check sw requirements in CMDB item‘s references for impact Whenever sw requirement is updated check related system requirement for impact check related CMDB items for impact system architectural design customer requirements system requirements software requirements

27. SW Architectural Design We use Rhapsody to design our SW + powerful design tool + simulations without target HW - developers find it more handy to write a document e.g. for comments regarding the design - viewing the design requires a license + code generation (not fully) But So what is missing? use images of the model in a document ensure that model and document are synchronous

28. Offer Images from Rhapsody in Codebeamer Package 1 Package 2 Package 3 Name each top level design element (package) gets an item CMDB Category „ SW Package“ changes in the model are committed to this item ID Export to .emf upload in folder SW-Design Document Management associate Top level design  We can use the CMDB category items in trackers, Wikis etc. comment: revision of model

29. SW Architectural Design Software Architectural Design is a Wiki page provides all textual information necessary to understand the design is searchable can be bookmarked Document Management exported images of Rhapsody model are used [!/1234!] CMDB Category „ SW Package“ providing a link to the CMDB item [ISSUE:2345] And the list of source code files implementing this design provides the valid Rhapsody model (SCM Commits) Software Requirements

30. CMDB Items and Tickets Software Architectural Design SCM commit CMDB Item Relation Software Requirement Tickets Software Requirements Link model Wiki

31. Traceability system architectural design customer requirements system requirements software requirements software architectural design software detailed design Maintenance: Whenever software requirement is updated check related CMDB item‘s scm commit of model for impact Whenever model is updated check sw requirements in CMDB item‘s references for impact update relevant images in document management (immediately takes effect in Wiki) update Wiki content if necessary

32. Code Creation code is implemented SVN Repository Remark header of a package/function links to design http://.../cb/wiki/3456 Track all that with Tasks tickets describe what has to be done by the developer (implement requirement ticket, change design, define validation criteria, …) estimate effort track effort spent set priorities and make release plan To commit a change set to the repository a developer only needs to decide: Are there just code changes or changes in design model as well? Plus: design is altered relate commit message to task #1234 relate commit message to task and CMDB item #1234, 2345

33. CMDB Items, Tickets and Repository Software Requirements Relation Software Requirement Tickets Task Ticket SVN Repository SCM commits Source Code SVN log SW Design link Remark header SW Design Wiki Source Code SVN Repository file list

34. Traceability system architectural design customer requirements system requirements software requirements software architectural design software detailed design software unit Maintenance: Whenever software design is updated check documented source code files for impact Whenever source code is updated check remark header links to design for impact

35. The Test Processes test specification for software units software integration test specification software test specification system integration test specification system test specification System Requirements CMDB Category System Test CMDB Category System Element CMDB Category System Integration Test Software Requirements CMDB Category Software Test CMDB Category Software Package CMDB Category Software Integration Test Source Code Test Framework Code

36. Summary If you have interfaces in your tool chain: you must maintain them in most cases by reviews The methods for traceability as described here are not fail-safe Could be improved by using software interfaces, e.g. plugins Could be improved by own Codebeamer extensions Any suggestions, ideas … are welcome! Thank you for your attention!