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.
© Copyright 2024