Soft audit practice・Audit Day 13: Closing Meeting and Follow-up

03/02/202121/10/2021Audit for soft-Develop..

Work on the day of the soft audit ends at the closing meeting

In the articles so far, we have introduced the opening of software development audit, detailed confirmation using checklist, preparation of audit report, and work on the day of audit. Finally, the closing meeting using the audit report.

Since the purpose of the closing meeting is to inform the audited organization of the audit results, as a general rule, all leader-class people who respond to the software development audit are invited to attend. Also, if possible, it would be better to have the head of the department of the audited organization attend.

At the closing meeting, at the beginning of the meeting, I would like to express my gratitude for responding to this software development audit . For the audit, the people in the audited organization have stopped their original development and management work and are spending their time for the audit, so I would like to thank you first for that.

The closing meeting is a place to recognize the problems found in the audit.

At the closing meeting, we will explain the contents of the report that summarizes the audit results, but the contents are still manuscripts at the meeting stage, and if there are any mistakes in the contents of the report, please point it out at the meeting. Fix it on the spot. I will also tell you that. This is because the closing meeting is not a place for explaining the report, but a place for both parties to agree on the content of the report .

Have measures implemented for correction requirements

Problems that were noticed in the software development audit are classified into two types, correction requirements and comments, and reported. Therefore, regarding the correction requirements, the audited organization considers countermeasures and submits a countermeasure plan. I will tell you again at the beginning of the closing meeting that I will get it.

After explaining how to proceed with these closing meetings, we will go through the pages of the audit report that we have created, starting from the front, and explain the summary of the audit summary, good points, correction requirements, and comments.

After explaining the report, reconfirm that there is no problem with the report and that there is no objection to the problem pointed out by us, and confirm that the attendees have agreed. To do. Then, please hand over the confirmed electronic file of the report to the person in charge of the audited organization in some way and consider measures for the correction requirements.

At this point, the on-site work of software development audit is complete. Declare the end of the closing meeting and finish the day’s work.

Follow-up after the on-site audit

After going to the site and completing the audit confirmation work, the amount of software development audit work has been completed by nearly 80%. However, for the purpose of auditing, the audit work on site is equivalent to a turning point .　

What I learned from the on-site confirmation work is how many problems there are regarding software development capabilities in the audited organization, and what the specific contents are. Based on these problems, the purpose of software development audit is to judge the quality of the software development ability of the audited organization and to improve the software development ability by implementing improvement measures. Work is also important.

However, the judgment of whether the software development ability of the audited organization is good or bad can be completed with relatively little work. It does not mean that we will give an absolute score, but we will only determine whether there is any problem even if we place an order, so we will compare it with the results of software development audits of other companies so far and judge that it is okay if it is not significantly inferior. Would also be good.

The quality of software development ability cannot be measured accurately because the fluctuation range is large.

Is it okay to make such a simple decision? You may be worried, but in reality there is no way to accurately measure software development ability, so it doesn’t make much difference no matter how you judge it . After all, all the work of software development is the product of thinking that takes place in the human mind, and the thinking ability of a person varies greatly depending on the environment, emotions, and emotions of the same person.　

The next day after staying up all night yesterday, you have only half the thinking power you normally have. Since the sum of human thinking abilities with such a large fluctuation is the software development ability of an organization, it cannot be measured accurately in the first place . Even if it can be measured, the result will change in an hour. Therefore, there is no choice but to make a rough judgment.

Improving software development capabilities will respond firmly

Another improvement in software development capability can be dealt with a little more firmly. This begins with the confirmation of the countermeasure plan submitted by the audited organization . At the closing meeting on the day of the audit, we are asked to consider the content of the countermeasures for the correction requirements and submit a countermeasure plan.

When this countermeasure plan is sent, does the audited organization understand the problem that was pointed out by carefully reading the contents, or is it planning an effective countermeasure for the problem? Make sure.

At the time of the audit, you should be aware of the problem by discussing with the leaders and designers of the development and testing departments who responded to the audit. However, it is often the case that another person has taken over when it is time to actually consider a countermeasure. In such a case, sometimes the problem pointed out here may be misunderstood, and the point may be deviated and a countermeasure plan may be proposed. Therefore, it is important to carefully check the countermeasure plan first.

If there is a misunderstanding here, we will explain the problem to the other party again by e-mail or conference call, and after reconfirming the problem, ask them to reconsider the countermeasures.

Is it possible to continue the countermeasure plan and it seems to be effective?

If there is no misunderstanding, the next step is to check the content from the perspective of whether the countermeasure plan is likely to be effective . At that time, there are two points to be aware of: whether it can be executed or whether it can be continued . In other words, isn’t there a measure that is close to the ideal theory in order to finish the software development audit as soon as possible? That’s the view.

No matter how good the plan is, if it is difficult to execute or the burden of continuing is too great, the countermeasures will not be implemented after all, and the purpose of improving software development ability cannot be achieved. It is important that the measures are taken so that if you make an effort, you can continue and really improve your software development ability.

If you check the submitted countermeasure plan from the above perspective, you will find that it is better to have some corrections. In such a case, based on the contents written in the plan, we will continue the work of examining the countermeasures by e-mail or conference call and having them revised. In my experience with Gutara, I often made revisions by email or phone two or three times and completed it as a countermeasure plan.

After completing the countermeasures, confirm that the countermeasures have been implemented at the end.

Once the countermeasure plan is completed, the final confirmation is that the audited organization has implemented the countermeasures. When about 3 months have passed since the countermeasure plan was completed , check the implementation status of the countermeasure contents based on some materials (confirmation), and if it can be confirmed that it is being implemented safely, this is the software. A series of development audit work is completed.

Did you get the image of software development audit?

In the articles so far, I have introduced the software development audit that Father Gutara came to, the preparations in advance, the work on the day of the audit, and the follow-up after the audit. Did you get an idea of ​​what software development audits look like?

From this next article, I’ll take a closer look at the contents of the checklist used by Father Gutara in the software development audit.

Next : Soft audit Checklist・No1: Requirements management process