Soft audit practice・Audit Day 11: Preparation of Audit Report (1/2)

02/02/2021Audit for soft-Develop..

Audit report aims to be a report that allows the other party to find effective measures

In the articles so far, we have introduced the points to note when proceeding with the audit, from the opening meeting to the actual confirmation work using the checklist, regarding how to proceed with the software development audit . After confirming the software development capabilities using the audit checklist, the next step is to create an audit report to inform the auditee of the problems found in the audit . In this article, we will introduce some points to note when preparing an audit report.

The purpose of the software development audit is one of (1) selection of a development contractor, (2) improvement of the software development capability of the outsourced organization, and (3) quality confirmation of the defect-fixed version software. In case of (1), it is undecided whether the audited organization will be selected as a development contractor, but in cases (2) and (3), it has already been selected as a software development contractor. I would like such an organization to have the ability to develop software of the highest quality possible.

Therefore, in the audit report, it is important to explain the problems in the software quality of the audited organization and make the description so that you can consider the improvement measures. Since software development auditing itself is not the purpose, it is best to make a report that will help the people in charge of the audited organization to actually implement and find effective measures .

In order to report the audit results from this perspective, I would like to introduce the points that Father Gutara was careful about.

First, identify and sort out the problems found in the software development audit

After confirming with the checklist, first reconfirm and organize the problems you found . The problems that I noticed during the checklist confirmation work are left as minutes and memos, so I will review them again and organize them.

When Father Gutara notices a problem during the confirmation work using the checklist, he asks him to show him specific materials such as design documents, work procedure manuals, and test specifications , and in some cases, he uses a whiteboard to work with him. We discussed the contents with the designers of the company and confirmed those problems concretely. Then, the materials shown at that time and the writing on the whiteboard are taken with a digital camera and left as reference materials. At the same time, I handwritten the problems and notices on the checklist I brought with me with a red ballpoint pen and left them as memos.

These reference materials and notes written looking at-out again, ① the issues What is the problem of the one ② it to see what materials ③ whether it is determined that that it is a problem and there is the problem is what bad that if ④ how We will sort out whether the problem can be solved . 

(2) and (3) are especially important so that the person in charge of the audit can understand the problem and consider the countermeasures. If the audit destination is an overseas organization, you will not be able to correctly convey what you are thinking unless you carefully prepare (2) and (3). This area is something that Japanese people, who have few opportunities to interact with people from different cultures, are not good at, so special attention is required.

After completing the general arrangement, the next step is to classify the problems into three categories: correction requirements, comments, and non-targets . Corrective requirements are items for the audited organization to consider and implement countermeasures. The comment is an item that I will tell you because I noticed that it is not necessary to consider countermeasures. Items that are not covered are items that are not included in the audit report.

Write the audit report in both Japanese and English using a template

After sorting out the problems, we will start the work of creating an audit report based on the contents. The software development audit is a method that Gutara’s father made on his own, so the format of the report has not been decided. However, the time available for organizing problems and creating a report is about one to one and a half hours, so if you do not prepare a template for the report, it will be quite time-consuming. So my dad Gutara used a template like this.

Report template (click to open pdf)

The report consists of three parts: (1) Audit outline, (2) Correction requirements, and (3) Comments. This report will be provided to the other party after reporting it to the other party’s organization at the closing meeting, so both Japanese and English are written. The English part may be written in the local language if it is accompanied by a good translator. Recently, the performance of online translation tools has improved, so writing in Japanese first and converting it to English or the local language has made it much easier to create reports. 

Make sure that the number of correction requests and comments is not too large.

(2) Correction requirements and (3) comments are the main contents of the software development audit, but the number of cases described there is not too large.

It is not limited to software development audits, but if there are too many problems pointed out, those who can implement the countermeasures will be depressed and discouraged . The purpose of software development audits is not to carry out, but to have the organization of the other party improve their software development capabilities, so it is a problem if the other party loses motivation.

Therefore, I will pick up a few problems that may be effective for the other organization , at most 6 to 7 cases, and make them as correction requirements and comment on the others. There are at most 6 to 7 comments, and the others are excluded. 

Is that so good?  You may be worried, but if you are an organization where you can find a lot of correction requirements and comments in the first place, there should be many other problems latent, so this audit alone is uneasy. is. First of all, it is better to have the corrective requirements implemented this time and to plan a re-audit again .

Well, if you find a lot of bugs in the final test of the software, it’s the same idea as postponing the release, recreating the bug-fixed version software, and testing again.

See the next article for an overview, correction requests and points to note when making comments.

In the next article, I’ll give you a little more detail on the points to take when actually writing out the overview, correction requests and comments.

Next :Soft audit practice・Audit Day 12: Preparation of Audit Report (2/2)