Some thoughts on the ASPICE development process.

Author: sky8336

Recently, while reading about ASPICE development processes and combining it with my work experience, I gained some insights.

How to approach ASPICE

ASPICE almost encompasses every aspect of software development. Whenever there are doubts arising during the software development process, we can refer to ASPICE to seek inspiration.

For startups, it is essential to focus on people. By leveraging their strengths, we can encourage everyone to exhibit their initiative and enthusiasm, rather than relying on job descriptions to hire people.

ASPICE demands many work products, including documentation. If not handled properly, it could lead to formalism.

My approach to this is to emphasize on practicality. For instance, the documentation of system requirements can be done at a later stage. If done too early, it could result in formalism and serve merely as a memo.

There is always a cost for any action, therefore, anything should only be done when the benefits outweigh the costs.

The value of ASPICE

So why should we devote our time and effort to documentations?

I am mainly interested in the following points:

Firstly, to provide input for the next stage of work. When the next phase begins, we can use this input to systematically carry out the work. For example, system requirements serve as an input for software requirements.

Secondly, to make explicit the hidden ideas in everyone’s minds. Writing down the contents serves as a baseline for discussion and communication. All stakeholders can discuss it and reach a consensus, thus reducing redundant discussion for the agreed points, and focusing on the areas yet to be resolved.

Thirdly, to make documentation traceable, which requires ensuring that any change starts from the source. Only clear requirements can reduce blind change due to inadequate discussion. Change is a cost.

Documentation should be easily retrievable in the future and serve as backup for work results.

Documentation is not the end goal. Its purpose should be to facilitate communication, reduce redundancy and waste, reduce ambiguity, and minimize waste caused by insufficient communication. It should also be able to facilitate the continuous progress of a task at various times. If documentation does not bring any benefits, then we need to adjust the way we record documentation.

Exploration without tool support

To do a good job in anything, one must first use the right tools. Without tool support, many things will fall into the most primitive and inefficient mode. Combining with the tools like Jira that are widely used in the industry, I have intentionally explored how to better implement some of these concepts and established some of my own understandings.

Many small companies or individuals tend to verbally assign tasks or communicate. This is simple and the most primitive way, which everyone is capable of. However, it is limited by the following factors:

1. Repetitive communication, which means the repetitive part is a waste;

2. What is said verbally is easily forgotten, and important issues cannot be tracked and traced, nor can they provide a view of the overall situation.3. When there are disagreements, the progress of the matter becomes difficult. Communication records are often an effective means of opening up the way and gradually accumulating consensus in documents. However, oral communication can cause costs such as information synchronization and forgetting, and misunderstandings.

3. Oral communication cannot solidify valuable work results, and it cannot effectively reuse past excellent results.

4. Oral communication should be accompanied by valuable records. Of course, this is still the most primitive way.

5. Oral communication should also start with the end in mind, just like writing documents. Before writing, you should have the final appearance of the document, who should see it, what you want to show, and how to present it better.

ASPICE Practice

In practice, I combined Jira with insights from agile development on the Internet. The primary requirement is treated as the epic, and the secondary requirement is treated as the story. These two-level requirements are broken down from the PRD, indicating the corresponding section in the description. During the process, I repeatedly communicated with the product manager to achieve what purpose and what the result should be.

Internet team features are treated as epics, while functions are treated as stories. The granularity of the requirement splitting and the essence of the work (whether to develop a specific function or integrate a supplier’s code) have been appropriately adjusted to achieve a balance between achieving traceability goals and traceability costs.

Under the secondary requirements, our development team combined with the software architecture document to create an RTM subtask for each requirement to split the work that completed a specific requirement into multiple tasks that are easy for developers to execute. The testing team created a task for testing under the secondary requirement, and this task corresponded to software integration testing. Secondary requirements may not be divided into different development modules. In fact, there is some corresponding relationship between the Aspice software requirement tested by software integration testing and the two-way traceability.

These are the expected goals:

1. From requirement splitting to task splitting, it can be split from top to bottom and combined with discovering the omission of requirements from the bottom to top. From top to bottom, the requirements can be put forward to each task, like an inverted tree.

2. The Jira requirements can correspond to the PRD, and the product manager can trace them. The development team can trace up to the PRD along the tree.

3. Requirements changes can be transmitted along the tree, and change requests need to be made on Jira to trace.

4. The developer’s tasks are clear at a glance, and the rhythm of development is controlled accordingly, with accurate costs to achieve maximum results.

5. The work of developers is transparent, letting managers know what everyone has done, avoiding situations where the managers know nothing about the developers’ work.

6. Make the development process smoother, standardized, and less wasteful.

7. Focus on doing the right thing, “doing the right thing.”

This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.