Soft audit Checklist・No12: Acceptance condition management technology
The fifth requirement management checklist is acceptance conditions.
In this article, we will introduce each item of the audit checklist used for software development audit . The audit checklist is divided into ( 1) development process, ( 2) requirements management, (3) testing, and (4) design and implementation. In this article, (2 ) individual items of configuration management in requirements management are introduced. (The checklist itself can be found in the article on Software Audit Practice / Checklist No. 8: Development Technology / Requirements Management (General Management) , so please refer to that.)
In the acceptance condition, we check the existence of deliveries to check the process quality and product quality.
If software development is outsourced to another company, what will be delivered as a product of the outsourced development ? Design documents, source code, and executable programs are direct deliverables, so it is unlikely that these deliveries will be forgotten. Then, what kind of materials will be delivered to guarantee the quality of the delivered software ? Inspection report of査result or will only? Is it possible to judge the quality of the software only by the report that XXX tests were performed and all passed? I think it’s quite difficult.
The quality of the software is difficult to judge in the first place. That’s why, their release judgment of the software in, product quality and the quality of the process for both sides of, to collect information in a variety of point of view, it has to determine whether the quality is good or bad. Therefore, when the software is delivered as a deliverable from the development contractor, we ask them to deliver the information that can confirm the quality of the software together, and check them to see if the software is of sufficient quality. Must be judged
.. Judgment of the quality of the delivered software is the acceptance inspection of the software as a deliverable. It is important that the requirement specifications clearly describe the acceptance conditions so that information for correct acceptance can be obtained. Check items related to acceptance conditions are confirmed from this perspective. Now let’s look at four items whose item numbers start with IN-.
[Item number: IN-01]
Depending on what scope of software development work you have outsourced, the executable program is usually the final product of software development work. It is the quality of this executable program, that is, the product quality , that we, the developers, must guarantee the quality to the end users . Therefore, it is necessary that the delivery from the contractor who outsourced the development work includes materials for confirming the quality of this execution program . It sounds difficult to check the quality of an executable program, but in short, did you test enough quality and quantity to thoroughly identify potential bugs and fix all the bugs you found ? I just need to be able to confirm that. Make sure that such materials are included in the delivery.
[Item number: IN-02]
The most important thing is the quality of the execution program itself, that is, the product quality, but it is also true that good process quality is necessary to achieve good product quality . Even if you develop software randomly, you cannot make software of good quality. From such a way of thinking, if we proceed with activities to develop good software by going into the software development process of the development contractor, it is necessary to include information that can confirm the status of process quality as a deliverable of the required specifications. there is. From that perspective, we will check the contents of the requirement specifications.
[Item number: IN-03]
It is also stated in section IN-01 that testing is important as information for confirming product quality. The contents of this IN-01 item are mainly written with information on the final test results. The process of detecting and fixing bugs in the latter half of software development, especially after entering the debug phase , is actually a very important process for improving the product quality of software.
In this process, how to manage the bugs found, and whether all the bug management information is shared with our company, which is the development consignor, so that the bugs are detected and fixed correctly. (In other words, if there are still bugs left, but the delivery date has come, it has not been terminated). To do so, the requirements specification must describe how to share bug information with us. From that point of view, check the requirement specifications.
[Item number: IN-04]
The development contractor also conducts various types of tests, and the debugging process to find and fix potential bugs proceeds. Of those bug information found in the outsourced in-house testing, information on bugs that have already been fixed is usually not provided. The idea is that the released software has already fixed the bug, so it 's the same as having no bug, and you don’t have to report any bugs that aren’t there.
This idea is not wrong. However, the information about which features many bugs were found is very useful information as it suggests which features are actually of poor quality. If such information is required, it must be clearly stated in the requirement specifications, so check from that perspective.
Next to the acceptance conditions is development management
Next to the confirmation of acceptance conditions, we will introduce the confirmation items for development management in the next article.