PRAGMATIC ASPICE
DOCUMENTATION EXPERIENCE
Björn Möller
2015-03-25
COMMITTED TO SUSTAINABLE PRODUCTIVITY
We stand by our responsibilities towards our customers,
towards the environment and the people around us.
We make performance stand the test of time. This is what
we call – Sustainable Productivity.
AGENDA
 The Atlas Copco Group
 Product solutions
 ASPICE
 Our situation
 Short overview of ASPICE requirements
 ASPICE similar to safety standards
 Document status
 What we did together with Addalot
 How do we maintain this?
 Experience
THE ATLAS COPCO GROUP
 Compressor Technique
 Mining and Rock Excavation Technique
 Construction Technique
 Industrial Technique
PRODUCT SOLUTIONS
Five steps of quality assurance
• Step 5
Zero fault
fastening
• Step 4
Safety critical
tightening OK!
• Step 3
Joint OK!
• Step 2
Batch OK!
• Step 1
Torque OK!
PRODUCT SOLUTIONS
Power Focus 600 with accessories
PRODUCT SOLUTIONS
Virtual Station concept
PRODUCT SOLUTIONS
Electrical nutrunners
PRODUCT SOLUTIONS
Synchronized tightening system with 34 tools
ASPICE
 ISO/IEC 15504 - SPICE - Software Process Improvement and Capability
Determination(Evaluation) – is a set of technical standards documents for
the software development process
 The Automotive SPICE Process Assessment Model is used to perform
conformant assessments of the software process capability of automotive
suppliers
 The results of assessment are used for the identification of process
improvements at a supplier as well as a criterion for supplier selection
OUR SITUATION
 One of our customer requires that we comply to ASPICE
 Addalot was invited to help us
 Initial APSICE assessment revealed large gaps in documentation and
traceability
 Addalot supported us both with the documentation and traceability in
addition to a traditional ASPICE process improvement project
 The combination of the process and technical work gave synergies, i.e. the
process could be better adapted to the architecture
SHORT OVERVIEW OF ASPICE REQUIREMENTS
Architecture is a central part of Engineering
Table 3 – Primary Life Cycle Processes – ENG process group
Process ID
Process name
 ENG.1
Requirements elicitation
 ENG.2
System requirements analysis
 ENG.3
System architectural design
 ENG.4
Software requirements analysis
 ENG.5
Software design
 ENG.6
Software construction
 ENG.7
Software integration test
 ENG.8
Software testing
 ENG.9
System integration test
 ENG.10
System testing
System requirements
System architectural design
Software requirements
Software architectural design
Software detailed design
OUTPUT: 04-04 SOFTWARE ARCHITECTURAL DESIGN
 Describes the overall software structure
 Describes the operative system including
task structure
 Identifies inter-task/inter-process
communication
 Identifies the required software elements
 Identifies own developed and supplied
code
 Identifies the relationship and dependency
between software elements
 Identifies where the data (such as
parameters) are stored and which
measures (e.g. checksums, redundancy)
are taken to prevent data corruption
 Describes how variants for different model
series or configurations are derived
 Describes the dynamic
behaviour of the software
(Start-up, shutdown, software
update, error handling and
recovery, etc.)
 Describes which data is
persistent and under which
conditions
 Consideration is given to:
– any required software
performance characteristics
– any required software interfaces
– any required security
characteristics required
– any database design
requirement
ASPICE SIMILAR TO SAFETY STANDARDS
 Functional safety standards require a similar level of architecture and
component design as ASPICE
 In the safety standards there are more requirements on specific
documentation techniques, but the structure and content is similar
 The traceability requirements between requirements and design are tougher
in ASPICE. The safety standard 26262 only requires traceability for safety
requirements
DOCUMENT STATUS
 SW architecture documents not updated during the last 5 years
 UML diagrams and code in IBM Rhapsody, unclear whether diagrams are
up to date or not
 Requirements in Caliber database, but not very good quality and no
traceability to design
 Reasonable good traceability between requirements and test cases, but no
test coverage control
 One of our customers require their suppliers to be on ASPICE level 2
DOCUMENT STATUS
This causes other problems like:
 No documentation to use when introducing new developers
 Implementation estimates were often incorrect, many impacts were
discovered late
 SW quality problems, very long stabilization
WHAT WE DID TOGETHER WITH ADDALOT
 SW architecture:
– Gathered existing documentation
– Went through overall architecture
– Agreed on a documentation structure
– Organized existing documentation according to new structure
– Interviewed domain experts, wrote down, reviewed
– Final review of complete document
WHAT WE DID TOGETHER WITH ADDALOT
SW High Level Design Spec.
1
Introduction .................................................................................................................................... 3
2
References and abbreviations ..................................................................................................... 4
3
General concepts .......................................................................................................................... 6
4
Overall SW structure - Logical view .......................................................................................... 11
5
Key use cases .............................................................................................................................. 31
6
Process view ................................................................................................................................ 45
7
Interfaces ...................................................................................................................................... 47
8
Storage ......................................................................................................................................... 49
9
Design patterns/principles ......................................................................................................... 50
10
Variants and configuration ......................................................................................................... 51
11
Non-functional requirements ..................................................................................................... 52
12
Platform used ............................................................................................................................... 53
13
Verification strategy .................................................................................................................... 58
14
Connection to Rhapsody model ................................................................................................ 60
15
Build structure ............................................................................................................................. 64
16
Index of SW components ............................................................................................................ 65
WHAT WE DID TOGETHER WITH ADDALOT
 SW components
– SW Component Design Specification(SWDS) template
– Component responsibility distributed to developers
– Example SWDS developed by a pilot
– Template and example presented to all developers
– Each developer started with one component each
– Developers got continuous feedback during documentation
– Review of each SWDS
WHAT WE DID TOGETHER WITH ADDALOT
Component SW Design Spec. template
1 Purpose
The purpose of this document is to describe the low level design of the software
component ComponentName.
2 General component description
Describe the component. Why does it exist, which important tasks does it handle.
Describe the services if applicable.
3 Interfaces
3.1 Interface1
A short description for each interface.
4 Classes
4.1 Class1
A short description for each class. The description for the more complex/important
classes should be more detailed.
5 Structure of the implementation packages
Explain the implementation packages and their purpose.
6 Important sequences
Describe important sequences within the component. This should be on a high level
and not a detailed sequence diagram copied from Rhapsody.
7 Implementation hints
Are there any traps to watch out for during development of the component or any
other things to keep in mind?
8 Improvement possibilities
Add stuff you think could improve the component.
9 Test strategy
A description about how the tests are structured. What is important/hard to test?
WHAT WE DID TOGETHER WITH ADDALOT
 Requirements traceability
– Requirements were distributed to developers (by chapter)
– Each developer traced requirements to main SW component, unclear
requirements were ”sent back”
– Requirements were improved when necessary
– Review of requirements
HOW WILL WE MAINTAIN THIS?
 Described in process
 Design proposal document contains explicit chapter on requirements and
design documentation
 Feature process supported by Jira template that includes requirement and
documentation tasks
 Document responsible appointed
 Document release is part of the release process, where the document
responsible shall release his document
EXPERIENCE
 We were quite skeptical in the start
– Documentation is heavy and no one has “the time over” to write
– Can this be done by someone from the outside? Our system is too complex!
 We hade strong need for better documentation, i.e.
– Many new people
– It was hard to get an overview of the system
– Experts were asked all the time
– Quality problems
 Now
– It was simpler than we thought, it was good to get it documented
– The use of an external person helped focusing the work
– Several areas needing improvements have been revealed and agreed
– Easier to do impact analysis
– Increased competence within organization
– Our work has been accepted by the ASPICE customer
COMMITTED TO
SUSTAINABLE PRODUCTIVITY.