Understanding of ASPICE
Latest update time：2023-02-03
Reads：
Author
| Xiaolu
Produced by
| Automotive Electronics and Software
Aspice (Automotive SPICE) Chinese translation is automotive software process improvement and capability assessment. It is a specification to ensure software quality and requires suppliers to design and develop products in accordance with the requirements of Automotive SPICE. It is a tool commonly used in the automotive industry for quality management.
Aspice's process groups include
supplier
process group, system process group, software process group, support process group, management process group, process improvement process group, and reuse process group
. This article focuses on the system process group and software process group, two parts that are closely related to developers.
01 Schematic of the “V” model
Let’s look at process groups first. Because the organization of all engineering (ie: systems engineering and software engineering) processes is similar to the word "V", it is often called
the V model
in people's mouth
. The process on the left corresponds exactly to the process on the right, but what needs to be known is that the processes "SWE.3 Software Detailed Design and Unit Construction" and "SWE.4 Software Unit Verification" are independent and separated.
The V model well explains several important work processes and work contents in our project development process.
Figure 1 Schematic diagram of the “V” model
02 Traceability and consistency
One of the important things about ASPICE is that it needs to have two-way traceability and consistency
. Traceability focuses on the existence of references and links between work products, further supporting coverage, impact analysis, requirements implementation, status tracking, etc. Instead, consistency focuses on content and definition.
Figure 2 Schematic diagram of two-way traceability and consistency
Bidirectional traceability is more defined as the bidirectional traceability between test cases and test results, often missing the bidirectional traceability between test cases and software requirements.
Figure 2 shows that we need to have two-way traceability: system requirements and software requirements; software requirements and software unit testing; software detailed design and software unit testing, etc., which can be seen in the blue part of the figure.
It should be noted that software integration testing mainly relies on software architecture design
; software integration testing mainly tests the data between various interfaces within a subsystem based on the interface design of the software architecture and the data timing and data flow direction between interfaces. Is the input/transmission/output correct? For detailed introduction, please see my article here: A brief talk about integration testing.
03 Detailed introduction to each process of ASPICE
-
SYS1 system requirements (screening review)
-
It includes all customer requirements such as hardware/software/structure.
-
Main output: system requirement feature list/system requirement function specification
-
SYS2 system requirements analysis
-
In this process, requirements are analyzed and divided into which parts belong to software tasks and which parts belong to hardware tasks or tasks related to structural design. Analyze whether the requirements are achievable, etc., to pave the way for subsequent architecture design.
-
Main output: system requirement feature list/system requirement function specification
-
SYS3 system architecture design
-
Establish a system architectural design, identify which system requirements are assigned to which system elements, and evaluate the system architectural design against defined criteria. It is a dependent object of software architecture design. It requires existing system architecture design and software architecture design. The detailed design of the software is defined, describing the software units, each software unit and its interfaces.
-
Main output: system architecture design documentation
-
SYS4 system integration and integration testing
-
Write system integration test cases based on system requirements and system architecture design, and then conduct system integration testing. It belongs to white box testing.
-
Main output: system integration test cases/system test plan/system integration test report
-
SWE1 Software Requirements Analysis
-
Conduct requirements analysis on the software part based on the screened system requirements.
-
Main output: Software requirements Feature list
-
SWE2 software architecture design
-
The purpose is to establish a software architecture design, which software elements are assigned to each piece of software according to requirements, and to evaluate the software architecture design according to defined standards.
-
Main output: software architecture design documentation
-
SWE3 software detailed design and unit construction
-
The purpose is to provide an evaluated detailed design for the software unit to be implemented
-
Main output: software detailed design documentation
-
SWE5 software integration and integration testing
-
Developed a system integration strategy, formulated an integration test strategy including regression testing, and formed a test plan; selected test cases to form test cases in the integration test specification; then conducted testing and formed system integration test results
-
Main output: software integration test plan/software integration test case/software integration test report
-
SWE6 Software Qualification Test Output
-
Develop software qualification testing strategy, including regression testing strategy; develop software qualification testing specifications; then select test cases; test integrated software; summarize and communicate results: Summarize software qualification test results
-
Main output: software qualification test report
04 Summary
1.
The pros and cons
of the ASPIC E process
ASPICE is to
standardize our code development process and improve the quality of our code
. We strictly ensure that we have a clear development plan and clear development process before development. Any code design has a reliable source of evidence, which is the guarantee
of our code quality. ensure
.
Simply put, it means completing our project goals on time while ensuring code quality. If it is just to complete the project goals without making a final "valuation" of our completed deliverables, then I think the task we completed has no meaning because it is not accepted satisfactorily by people. Completing this final "valuation" requires the support of the documents we output. We use this document and test results for acceptance to judge whether the design and development meet the needs of the customer and whether they meet the original project goals.
As project managers, we prefer that this document be output according to standards. It is more like a bridge for us to communicate with developers. Through these documents, we can know more detailed design plans and ideas of developers. In communication, a lot of early communication costs will be reduced.
Perhaps for developers, the biggest challenge in following this process is the output of documents. To develop projects strictly in accordance with standard ASPICE, we
need to follow the V model from top to bottom
. That is: first complete the system requirements, system architecture design, then complete the software requirements, software architecture, detailed software design, and finally code development and testing. In reality, many projects have code development and document writing in parallel due to time constraints. It does not meet the requirements of ASPICE and does not fully utilize the advantages of ASPICE to control the quality of our code.
And if this process is strictly followed, the time on the development side will be at least doubled, which will also be a big challenge to our labor costs.
The design documents required by ASPICE need to be output by relevant developers
. In the words of programmers: it takes longer to write these documents than to write the code. To write a functional development document, I can complete at least 3 equivalent functions. development.
Second, the ASPICE process is standardized. Does it need to be tailored?
Although ASPICE has a good guiding role in our project development process, do we need to follow it completely "rigidly". As mentioned before, although our ASPICE process is good, it takes a long time and has high labor costs. It is not friendly to projects with heavy tasks and short cycles. Therefore, my answer to this question is: tailor it according to the actual situation of the project.
During project development, we often participate in or organize project phase summary meetings. In a previous project summary meeting organized by Xiaolu, many engineers often had great doubts about the priority of project tasks: Should the document design work be completed first or the code delivery work be completed first? This confusion often occurs in projects with short life cycles, where engineers are often urged to output documents and code at the same time. The standard answer is: According to the development process, document design is completed first, and then code development is done, but because our time is tight, they are done simultaneously. At the meeting, the unified goal we achieved was: full use, reasonable arrangement, appropriate tailoring of document requirements to meet customer needs, and prior to this condition, completing the project goals on time and with quality.
Trimming is simply about squeezing limited time into what matters.
For projects with a long life cycle, you can strictly follow it; for projects with a short life cycle and heavy tasks, you can make appropriate cuts, cut out relatively unimportant processes and processes, or do parallel processing. Of course, it will be evaluated based on the actual situation.
Xiaolu said: ASPICE is our tool to ensure code quality and optimize the code development process. It can guide us in project development, but we can tailor it according to the development tasks. Actual analysis of the actual situation!
The above is just my personal opinion. Welcome everyone's advice.
Read the original text and follow the author’s Zhihu blog
Add the WeChat account below to join the automotive R&D management exchange group
(Professionals only)
Add a note name + company + field
京公网安备 11010802033920号