Soft audit practice・Audit day 10: Points to check design and mounting technology
- 1. Design and implementation technology is audited paying attention to the competence of software engineers
- 2. Design and implementation capabilities are judged from the status of dealing with specific problems.
- 3. Precautions for checking design and implementation technology
- 4. After confirming with the checklist, it is time to create an audit report.
Design and implementation technology is audited paying attention to the competence of software engineers
Continuing from the previous article, this article introduces the points when auditing using the checklist for the design and implementation checklist , which is the last of the four checklists for software development auditing . Since the technical capabilities of the organization’s design and implementation are the technical capabilities of the software engineer itself, what is done in the software audit is to judge whether the technical capabilities of the software engineer are good or bad.
The design and implementation checklist is similar to the development process checklist, and each check item is introduced in the article on practice / checklist (development technology / design and implementation) , so I am interested in specific items. If you have one, please see that article first.
Below is an example of the checklist, so please read the article while also looking at it.
Design and implementation checklist
Design and implementation capabilities are judged from the status of dealing with specific problems.
The purpose of this checklist is to understand the quality of software design and implementation capabilities of the other organization . For that purpose, we guess the skill of software development by asking questions about technical items related to software and confirming how the other party recognizes those items.
However, in a word, the skill of software development covers a wide range of technical fields, so it is difficult to find a way to easily check the quality of the skill. If you have the skills to create software such as clarification of required specifications, experience in system design, software structure design, data structure design, or code implementation technology, you can use software introduced from outside the company as product software. There is also the skill to integrate with . Furthermore, considering the area of application software, the types of skills required to develop software are endlessly expanded, and it becomes impossible to judge whether the skills are good or bad.
However, the purpose of the software association development audit cannot be achieved unless the skill of software development of the partner organization is judged in a short time. Therefore, Father Gutara decided to hear what the other organization is doing about the specific software problems that he had experienced in the past . In short, if the other organization can immediately understand the content and importance of the problem that you have encountered, if you have already taken measures, or if you have not taken measures, they will recognize the importance and think about some action. From such a point of view, I judged the skill of the other party regarding software development.
Precautions for checking design and implementation technology
Since the checklist of development technology is an extraction of the items experienced by Father Gutara, there may be a discrepancy with the skill of software development in the general public. I think it is better to bring in cases where problems have occurred in the past in each organization and use them as confirmation items.
However, I think that some people may use the check item of Gutara’s father as a connection until such items are prepared, so I will briefly introduce the points to note when using this check item.
First of all, there are items about the quality check procedure of purchased software, OSS and Free Soft . Purchased software is software that you have purchased for a license fee in the form of objects or sources, which has existed for a long time. OSS is open source, and recently, Linux, Android, and software stacks running on it have been increasingly adopted as software for products. The last Free Soft is interface software such as drivers provided free of charge by chip vendors to use the chip . In many cases, it is provided as sample code , so there is no guarantee by the chip vendor and it is the responsibility of the user to guarantee the quality. This is called Free Soft.
In the case of purchased software / OSS / Free Soft, make sure that you have clear rules and processes regarding the selection method, quality confirmation method, and post-shipment maintenance system. Having clear rules and processes means that the organization is responsible for the software as a whole, including the software introduced from outside the company . In short, I don’t want to outsource the development of our software to an organization that has the idea that “it is software introduced by another company that is not our own software, so we cannot guarantee it", so this is a confirmation.
Next, there are FROM-related confirmation items. Flush ROM has a slow access speed for a long time and requires Erase processing by a special procedure, so it is a little troublesome to handle, such as sandwiching the cache by RAM or applying exclusive control of access , so according to it Bugs are often latent. Recently, the capacity has been increasing, and some devices have extremely short lifespans. In short, since it is an element that requires careful handling, the skill of the organization’s embedded software was judged by how much it was aware of the technical know-how related to its handling .
Next comes the timer / counter problem and checking for memory leaks and resource leaks . These are confirmations of what Father Gutara calls a time bomb bug . All of them have no problem immediately after the device is put into operation, but it is a bug that causes problems in all products after a certain period of time. Compared to regular bugs (though the definition is vague), the range of problems that occur is extremely wide , and in some cases there is a high risk of causing problems in all products, so this is a bug that requires special attention. By confirming whether or not we are aware of the high risk of such a time bomb bug, we judge the skill of Sof development.
The last is the state transition . This is also a bug whose cause is hard to find when it causes a problem in the market. When some special condition is met, the internal state transition causes a deadlock, which causes the function to stop without getting out of the special state. Since the conditions of occurrence are often special, it is difficult to find this kind of bug in the test, and it is difficult to deal with it without a mechanism to find it in the review at the design stage. Therefore, we judge the skill of software development by checking whether such measures are taken.
After confirming with the checklist, it is time to create an audit report.
So far, we have introduced how to proceed with software development audits using checklists. After checking using the checklist, the final task is to create an audit report and explain the audit results to the other organization. In the next article, we will introduce the points to be noted when creating an audit report.
Discussion
New Comments
No comments yet. Be the first one!