Soft audit Checklist・No1: Requirements management process
Introducing the check items of the development process checklist
Software development auditing is an auditing method that Gutara’s father arbitrarily named to determine the capabilities of software development contractors. Overview of software development audit and pre-preparation of the audit at the time and the work of the audit on the day for, have been introduced in other articles. Also, please refer to another article for the points when using the audit checklist used in software development audits .
In this article, we will introduce each item of the following four audit checklists in order.
- Development process checklist
- Checklist of requirements management for the first development technology
- Checklist for the second test of the developed technology
- Third design and implementation checklist for development technology
This article first introduces each item in the development process checklist. The points when using the development process checklist are explained in the article on software audit practice / audit day No. 7: Points for checking the development process , so it is easy to understand if you also read it. I think.
How to use the development process checklist
Software development process is, initially planned function of the software with and performance time that you planned the purpose of the software development project that releases to complete in, always be stable to achieve is very important things in order.If the development process is immature, the development project may go well or fail, and you will not be able to outsource software development with confidence. Therefore, even in software development audits, confirmation of the development process is a very important item as well as confirmation of development technology.
There is no right answer because the method of software development audit itself is just made by Gutara’s father and called by himself . Regarding the checklist of the development process, this is not the correct answer, but in order to introduce that my father Gutara was careful about these items when checking the development process, check below. Please see the article while looking at the example of the list.
The checklist consists of one item per line and six columns next to it.
In the development process checklist, one line is one check item, and there are six columns in the horizontal direction, so let’s briefly explain each column first.
The No. column is the unique number for each blind person. When indicating an item at the time of audit, this unique number is used when referring to the item in an audit report or the like.
The Category column is the major category name (Category name) of the development process . This Category name uses the CMMI Level2 name. By the way, the abbreviation of the category name is used after the prefix of the number in the No. column.
The Item column is an overview of the check items . Check items are created with reference to the items of CMM Level2. The CMM that my father Gutara referred to is one before the CMMI, so there are some subtle differences from the latest CMMI. Well, since this check item was created by Gutara’s father who interpreted the contents of CMM Level 2 in his own way, the correspondence with CMM is not very strict. The CMMI translations are available here , so if you want to know more about CMMI, please have a look.
The Check Point column is a breakdown of the contents of the Item column into more specific confirmation contents . In the actual software development audit, we will proceed with the confirmation using this Check Point column.
The Answer and Evidence (Pre) column is a column that asks the organization of the other party to fill in before the audit . It is used to look at the written contents in advance and decide the items to be confirmed on site on the day of the audit. For details on how to actually proceed with the audit, please refer to the article on practical work and preparations up to the day .
The Comment column is a memo column for adding things that you noticed on the day of the audit . On the day of the audit, Father Gutara printed a checklist on paper and handwritten what he noticed during the audit in this Comment field and used it as a memo.
Now that we have introduced the outline of the development process checklist, let’s finally introduce each item. First is requirements management as a development process. In addition, there is a requirement management checklist in the checklist type, which is confusing, but the requirement management item in the development process checklist is a confirmation about the requirements management process, and the requirements management checklist is Confirmation of the contents of the requirements.
Details of requirements management check items
The check items for requirements management are the four items whose item numbers start with RM-. When outsourcing software development work, it is important to communicate the development requirements to the outsourcer as accurately as possible. From the perspective of the contractor of development work, it is important to accurately understand the development requirements presented by the customer . It is this Category that confirms what kind of development process you are using to accurately understand your customer’s development requirements. Let’s look at the item numbers in that order.
[Item number: RM-01]
Development requirements have a great influence on the development plan such as the scale and complexity of the contracted development work and the required development period . So, before forming a development team and starting development, how big a team can be contracted, how many engineers are needed, how long it will take, etc. Relevant departments need to be gathered and reviewed to create an appropriate development plan .
It is a confirmation that there is a review for that as a development process. To put it a little more flatly, it is a confirmation that the sales staff will receive an order from the customer without carefully considering whether or not it can be outsourced in-house, and then the situation of throwing the whole thing to the development department will not occur.
[Item number: RM-02]
We will create a business plan to proceed with software design, implementation, and testing according to the contracted development work . The actual development work proceeds according to this business plan, but it is a problem if unnecessary development requirements are mixed in or the necessary development requirements are omitted.
What is important is that the personnel, equipment, and period required to develop software that meets the requirements indicated by the customer are properly planned and written in the business plan. In a nutshell, it is a confirmation that the business system is such that a business plan that seems to meet the requirements of the customer can be created.
[Item number: RE-03]
Unfortunately, it is common in software development that development requirements change along the way. If the amount of change is large, it will affect the required development man-hours and development delivery date, and in some cases it may be necessary to review the software structure. When there is a change in development requirements, in order to correctly judge the scope of influence , we review the business plan after reviewing it with the parties concerned, and confirm that the development work is proceeding according to the revised business plan. increase. In a nutshell, this is also a confirmation that if the development requirements increase, is there a mechanism to consider whether to increase the number of people or extend the delivery date accordingly?
[Item number RE-04]
When there is a change in the development requirements, the development plan must be reviewed first according to it as described above. Then, in actual development, work is required to add or modify design documents, source code, test items, etc. according to new development requirements . In response to such changes in requirements during development, we will check whether there is a mechanism to confirm that the contents of the actual development work have been changed without omission . For example, if you are adopting a development management method that assigns a unique ID number to each requirement and describes the ID number of the requirement corresponding to the design document, source code, or test specification, it is new. It would be nice if there was a development process that confirmed in a review somewhere that the ID number of the development requirement added to was included in the design document, source code, and test items.
Next to requirements management is planning management
Next to the requirements management confirmation, the confirmation items for planning management will be introduced in the next article.