Soft audit practice・Audit day 2: First of all, the opening meeting
- 1. First reconfirm the audit procedure and time allocation at the opening meeting
- 2. First of all, explain the purpose of the audit firmly
- 3. Don’t forget to explain the closing meeting
- 4. First of all, get an introduction of the development process by the other party and grasp the whole
- 5. Where it is difficult to understand, while checking the actual thing and reality with 3 realism
- 6. Audit using the audit checklist is finally complete after the introduction by the other party
- 7. The checklist consists of four parts: process, requirement specifications, testing, and design / implementation.
- 8. Checklist will proceed with confirmation while explaining the purpose of each item to attendees
- 9. If a problem is found, explain why it is a problem with the content and risk to gain understanding
First reconfirm the audit procedure and time allocation at the opening meeting
Everything is important at the beginning, but in software development audits, audits that are not common to the general public are performed, so the first explanation to the person to be audited is especially important. For the leaders and staff of the other company to be audited, what kind of things are asked about software development audits, and what kind of impact does the audit have on their work? I think there are some concerns.
The cooperation of leaders and personnel is indispensable to enter the field of development and testing in order to proceed with auditing on a three- pronged basis, so solve their concerns and questions at the beginning. By doing so, the audit will proceed smoothly. Therefore, it is good to carefully explain the purpose of the audit and how to proceed at the opening meeting .
Therefore, I request that all the people who will respond to this audit attend the opening meeting . Of course, as the audit progresses, we may ask engineers who were not originally scheduled to come to the audit, but at least all leaders should be invited to the opening meeting.
First of all, explain the purpose of the audit firmly
At the beginning of the meeting, I will explain the purpose of this software development audit. The purpose of software development audits can be broadly divided into three parts: ( 1) grasping competence, (2) improving competence, and ( 3) checking the quality of software for defect countermeasures . First of all , I would like to introduce what the purpose of this audit is .
Next, I will briefly introduce how to proceed with the audit based on the schedule of the audit plan . First, we will be introduced to the development process and software quality assurance activities by the partner company, then we will confirm according to the audit checklist, and finally we will report the audit results at the closing meeting. to introduce.
Don’t forget to explain the closing meeting
In the closing meeting, the audit of the report How can report the audit results on the basis of, the contents of the report when there is objection if Kurere The alleged in the conference, also referred to modify the contents, first to tell It is good to keep it.
I would also like to take this opportunity to inform you that the audit report contains the points to be pointed out by the audit, and there are two types of points to be pointed out: correction requirements and comments . I will also explain at the opening meeting that there will be a follow-up to confirm the implementation status of the correction plan two months after the correction request is submitted by having the correction plan submitted about one month ahead . Regarding comments, it is not necessary to submit a correction plan, so I will tell you that it will be useful for improving the software development ability of the partner company in the future.
After briefly introducing the above at the opening meeting, we will move on to the actual audit work.
First of all, get an introduction of the development process by the other party and grasp the whole
When the opening meeting is over, the actual audit will finally begin. First of all, you will be introduced to the software development organization and development process by the partner company. Regarding the outline of software development of the other company, we have been preparing based on the materials obtained in advance, but we will ask the other company to explain again including the specific contents.
While listening to the other party’s explanation about the product group, organization, development base, and development process, pay attention to the following points, and in some cases, show the other party’s software development process, etc. I will understand .
- Location of organizations and offices that develop software and support it
- Whether the testing department exists independently of the software development department
- How many software engineers and test engineers are there?
- What is the system for quality assurance of software, and is there a software quality assurance department?
- Who is the judge (responsible person) for software release?
- Is there an organization to improve software technology (architect team or senior engineer team)?
- Is there an organization that improves the software development process (SEPG in CMMI)?
- Is there a method for the team that manages the quality of software (SQA in CMMI)?
- Do you have metrics to evaluate the quality of software?
Where it is difficult to understand, while checking the actual thing and reality with 3 realism
Just listening to the explanation given by the person in charge of the other party does not give you a concrete image. In such a case, if you take a step forward and show a concrete example of what you explained, you will understand. It will be easier. For example, when it is explained that the test department exists independently of the software development department, “When and how is the test request issued to the test department?" Or “Test in the test department". If you ask a little specific activity such as “How will the result of the above be fed back to the development department?", The actual situation can be seen.
When you go into a specific situation and listen to it, you often see problems with the organization or process at this stage . No company has a perfect software development process, so there are always some deficiencies. When a problem becomes apparent, ask them to show you specific materials as much as possible , explain to the other party where the problem is based on the material, and what the risks the problem causes, and there is a problem. Let the other person understand.
Then, on the spot, record it as a problem in the material at hand. It will be decided at the time of preparation of the final report whether the content should be a correction requirement, a comment, or no particular record. This is the same for the subsequent confirmation work using the audit checklist. At the end of the audit, we will look back and decide whether to make a correction request or a comment.
Audit using the audit checklist is finally complete after the introduction by the other party
After the introduction by the other company, it is finally time for the audit using the soft audit checklist . Which item of the soft audit checklist to check on the day of the audit is decided at the stage of soft audit practice / preparation part 3: pre-filling of the checklist , so check in that order. increase.
However, you don’t have to worry too much about the items you have decided in preparation for the day of the audit . As you listen to the explanation from the other company on the day of the audit and proceed with the confirmation by the soft audit checklist, if you think that you want to hear a little more detail here or you can omit it, change the items to actually check There is no problem.
Roughly speaking, it takes about 10 to 15 minutes to check one item, so it is good to check the items on the audit checklist while watching the progress of time. Also, when the planned end time arrives in the itinerary, it does not matter if the checklist items remain or the confirmation work is completed there. The soft audit checklist is just a tool to achieve the purpose of auditing. Since it is a tool, the standard usage is decided for the time being, but there is no need to follow that usage at all.
The checklist consists of four parts: process, requirement specifications, testing, and design / implementation.
The software audit checklist used by my father Gutara is divided into four types of EXCEL sheets: (1) development process, (2) required specifications, (3) testing, and (4) design and implementation. The actual audit checklist is attached to the articles after the software audit practice / checklist # 1: Development process (requirements management) , and each item is explained there, so if you are interested, please see that as well. Please.
In this article, I will introduce a little more concretely how to proceed with the confirmation work using the audit checklist. The audit checklist is an EXCEL table with horizontal columns for ID number, title, summary, specific confirmation items, answers, and remarks . And in the vertical direction, one confirmation item is written for each line, and the audit progresses when looking from the top.
The audit checklist is a soft audit practice / preparation part 3: At the stage of pre-filling the checklist, it is handed over to the partner company and asked to fill in the answer column. On the day of the audit, project this checklist with a projector so that all attendees can understand which item is being confirmed, and the confirmation work will proceed smoothly.
Checklist will proceed with confirmation while explaining the purpose of each item to attendees
Also, even though the software audit checklist has been given in advance, not all attendees have read the contents, and even if they do, they often forget the contents. Therefore, in the confirmation work, the purpose and specific confirmation items are explained for each item first, then the software development rules (process) of the partner company are explained, and the implementation status according to the rules is actually explained. We will proceed in the order of confirming the implementation status of the work while showing the output (confirmation).
The important thing is to have the software engineer, test engineer, or manager of the partner company show you the work records such as the system, worksheets, and design documents that are actually used in the business . Only when you show the actual work record and explain the reality along the work flow, if there is a problem in the way of proceeding or managing the work, you can see the problem.
If a problem is found, explain why it is a problem with the content and risk to gain understanding
When a problem becomes apparent, explain the content and risk of the problem to the other party so that the other party can understand the problem. Then, on the spot, record it as a problem in the material at hand. It will be decided at the time of preparation of the final report whether the content should be a correction requirement, a comment, or no particular record. This is the same as when the first party introduced the development process.
Now, let’s take a closer look at the four checklists used by Father Gutara: (1) development process, (2) required specifications, (3) testing, and (4) design and implementation. However, before that, first of all, there is an introduction of the development organization and process from the other party, so I will introduce the points to note when listening to this introduction in the next article.
Discussion
New Comments
No comments yet. Be the first one!