Soft audit Checklist・No3: Tracking process
The third part of the development process checklist is tracking
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, (1 ) individual items of tracking in the development process are introduced. (The checklist itself can be found in the article on Software Audit Practice / Checklist Part 1: Development Process (Requirements Management) , so please refer to that.)
Tracking is the confirmation and correction of actual results for a plan.
After making a plan and starting the actual development work, it is necessary to check whether the work is proceeding according to the plan, and if it deviates from the plan, it is necessary to devise a way to return it to the plan. In Japanese, it 's the confirmation of achievements and the implementation of corrections . Together, the term tracking is used in English-speaking countries .
Gutara’s father also uses the term tracking because it’s a relatively convenient term and it’s easy to understand when talking to overseas development contractors. Traking is 8 items whose item numbers start with TR-, so let’s look at them in order.
[Item number: TR-01]
Software development is a task in which design, implementation, and testing are mostly carried out in the human mind, so it is difficult to understand the progress . However, the results of designs, implementations, and tests that people have done in their heads are written out as deliverables such as design documents, source code, and test reports . Therefore, in order to quantitatively grasp the progress in software development, compare the performance of these design documents, source code and test reports with the plan. possible to grasp the progress by .
For example, if only 4 types of design documents are completed for a plan for which 6 types of design documents have been completed as of today, it can be judged that the plan is delayed by 2/6. In this way, the progress of software development is judged by the quality of the deliverables, and if there is a delay, it is confirmed whether or not the progress management action is taken to take measures.
[Item number: TR-02]
While planning and proceeding with a software development project, there is no project that can proceed safely without any problems. Unfortunately any project has some risks and concerns . However, some projects will succeed with great risks and concerns, while others will fail without major risks and concerns.
This depends on whether the project has successfully addressed the risks and concerns, and whether the project has the ability to manage the risks and concerns . In order to know the management ability of these risks and concerns, a mechanism to manage the risks and concerns that were noticed at the start of the software development project using a list etc. and proceed with countermeasures check whether there is to .
[Item number: TR-03]
There are many ways to manage the progress of a software development project, but the easiest way is to manage important milestones as planned. And as an important milestone in software development, an official review in which multiple related departments also participate. .
If the schedule for this official review is significantly behind schedule or significantly ahead of schedule, it’s safe to assume that something is wrong with the progress of the work. If you realize that a problem is occurring, you can take action to resolve the problem. In this way, make sure that important milestone schedule management is in place.
[Item number: TR-04]
Review is an important activity to improve quality at the stage of software design and implementation . There are various purposes and methods of conducting reviews, but does your department decide what kind of review to do and when to do it? What kind of design or implementation to review, who decides whether to review, which review method to use, who will be the participants of the review, how to record the points of the review Who will trace the measures and who will record the implementation status of the review?
These review plans need to be somewhat clear in order to be efficiently implemented for designs and implementations that require critical reviews . Make sure you have a standard on how to plan such a review, and whether the actual review is planned and implemented according to that standard.
[Item number: TR-05]
Neither design reviews nor code reviews improve quality just by conducting reviews . The most important thing in the review is to improve the design quality and code quality by taking all measures against the points pointed out in the review. .
For that purpose, it is necessary to record all the points to be pointed out in an easy-to-understand manner, and to steadily track the points to be pointed out, such as whether countermeasures have been considered and implemented based on the records. There are many ways to do this, such as using the minutes of a review, tracking with a list of issues, or using a tracking system. There is no right answer, but check how you actually record and track your findings.
[Item number: TR-06]
Development progress is necessary for internal development management, but if you are developing for customers, regular information sharing with customers is also important. There is no problem if the development is proceeding according to the original plan, but unfortunately in many software developments, process delays become apparent toward the end of development. If this process delay cannot be recovered, it will eventually be necessary to delay the release date later.
In that case, various adjustments will occur on the customer side as well, so various in-house adjustments will be required. Even if such a thing becomes clear just before the release date, internal adjustments will be very difficult. Therefore, if it seems dangerous, you should take measures as soon as possible . For that purpose, it is good to share the development status with customers from the middle of development, so check whether such activities are taking place.
[Item number: TTR-07]
Sharing information about the development status is necessary not only at the person-in-charge level but also at the management level . Especially when something goes wrong person in charge of the consignor and the consignee tries to solve it, but if it still does not work, it is necessary to make adjustments at the next level of management. Will be.
When such a situation occurs, it requires quite strict negotiations, but in order to find a good solution for both sides, it is important that both managers understand the situation correctly . Therefore, it does not have to be as frequent as the person in charge level, so it is important for managers to have a place to share information on a regular basis. Make sure that the trustee is aware of such activities.
[Item number: TR-08]
The development contractor delivers the deliverables to the contractor when the contracted development work is completed . Since it is a product of software development work, design documents, source code, various instruction manuals, test reports, etc. are the products. These deliverables must be reviewed internally by the contractor before being delivered to the contractor . In order to be in time for the delivery date, we will set a schedule for in-house review in advance and carry out it, and if possible, specify the specific item such as what time the review schedule for the deliverables of the work currently outsourced is. Use to check the planning status of the trustee’s review.
Next to tracking is quality assurance
Next to tracking, we will introduce the items to be checked for quality assurance in the next article.