Hirschmann: Automotive SPICE Requirements for development process and tools

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

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

Employees 800 Employees thereof 120 Engineers

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

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

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

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)

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

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

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
…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

Hirschmann: Automotive SPICE Requirements for development process and tools

by Intland Software GmbH

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Hirschmann: Automotive SPICE Requirements for development process and tools Presentation Transcript