Soft audit practice・Audit day 6: Functions required for software development and department in charge (2/2)
- 1. (4) Quality confirmation function for purchased software and free software
- 2. (5) Functions for managing development plans and development projects
- 3. (6) Horizontal development of defect cases and function of engineer education
- 4. Organizational structure and location
- 5. The following is an introduction to points to note when using the checklist.
(4) Quality confirmation function for purchased software and free software
With the benefit of increasing the scale of hardware, the scale of embedded software is getting bigger and bigger these days. As a result, not be able to develop all of the software in-house, many of the introduction of free software to purchase software has been more and more that make up Rishite, the software of the system. Especially for products that require an Internet connection, in most cases, the application is mounted on an existing OS such as Linux, Android, or Windows to implement the required functions.
By the way, is the quality of these purchased software and free software okay? As long as it’s software, someone should have written the source code somewhere and tested the compiled executable program . But does the quantity and quality of the test match the quantity and quality required by our product? Also, how many years can we continue to maintain software that provides a version that fixes bugs and vulnerabilities when they are found after shipping?
When installing purchased software or free software, it is necessary to carefully check the product quality of the software at the time of installation and whether maintenance of the software can be provided after shipment . Even if the software developed in-house is tested fairly well, the purchased software and free software may not be tested unexpectedly.
Purchased software and free software, such as who confirms the quality of free software and how, and whether there is a mechanism to determine whether the purchased software or free software can be installed in the company’s products in the first place , etc. This is an important point to check about the software.
(5) Functions for managing development plans and development projects
Software development projects are often delayed. There are various causes of process delays , such as inside the project and outside the project, but regardless of the cause, the reality is that process delays often occur .
Therefore, it is very important to manage the development progress in software development projects . However, if you focus only on the development progress, it will fail in another respect. In a software development project, there is a devil’s move to miraculously recover a process that has been delayed significantly . It’s a hand that hasn’t been tested but will be released . Well, in short, there are still potential bugs, but the basic functions are working properly, so let’s release it because the delivery date has come! It is a method.
So, in a software development project , development management is very important to keep the originally planned development schedule and quality . And the main premise when managing is that there is a plan. Management is about monitoring whether things are going according to plan and taking measures to meet the plan if it deviates from the plan. Therefore, there is no way to manage it without the original plan.
Specifically, there is a mechanism to confirm whether the necessary information is written in the software development plan, a mechanism to confirm whether the development project is proceeding as planned , and if the quality and schedule deviate from the plan. The important point to check is whether there is a mechanism to correct it as planned.
(6) Horizontal development of defect cases and function of engineer education
Regarding the horizontal development of defect cases and technical education, it is necessary to be a little careful when conducting software development audits for overseas software development contractors . What needs attention is that the way of thinking about the necessity of such activities is often different from that of Japan .
In Japan, the bugs experienced with the product A (for example, a bug that caused the system to hang 49 days after shipment due to a memory leak) were reported to the development teams of other products B and C in the same way. I think it’s normal to have an activity to check if there are any lurking bugs. Of course, even if you think about it, you often don’t have time to do it, so it doesn’t actually happen. However, I have the idea that horizontal development of such failure cases is normal .
In Japan, software engineers are also employees of the company, and it is common to increase income by promoting them within the company, so this idea is common. However, overseas software engineers are highly aware that they contract with the company to provide their abilities to the company and receive salaries in return . In extreme cases, when one development project is completed, your ability score will increase, so it is common to find a company with better conditions and change jobs.
In this way, for those who are premised on contracting with a company based on their own abilities, the failure cases that they have experienced are important technical know-how of their own and their ability to increase their value . It is a part . I don’t really feel the need to pass on that important technical know-how to others for free. The company also recruits engineers who have the necessary abilities to develop products, and dismisses existing engineers if there are many.
Since I work in such an environment, I need to assume that the concept of horizontal development of defect cases and education itself is fundamentally different from Japan . Even so, horizontal development and education of defect cases are effective means for improving the product quality of software, so I listened to the explanation of the other party paying attention to how to incorporate it into the development organization. Is good.
Organizational structure and location
Last but not least, it’s a good idea to carefully check the location of the software development organization . As the internet environment has improved and online meetings can be used normally, the influence of location is less than before. However, as with all company operations , the fact that informal information exchanged through informal communication is actually very useful is still alive.
For example, a 5-10 minute stand-up in front of a coffee vending machine or an exchange of ideas while having lunch can be quite useful for a software development project. To be able to do that, engineers need to be in the same building or on the same floor.
Whether the departments related to software development are gathered in one place, distributed in multiple buildings, distributed all over the world, where the actual engineers are working, the other party I kept it in mind when I heard the explanation of the previous company.
The following is an introduction to points to note when using the checklist.
Before introducing the checklist, I thought I would briefly introduce the points to note when listening to the explanation from the other party, but it was an unexpectedly long article. From the next article, I will introduce the points to note when proceeding with the audit according to the contents of the software development audit checklist.
In addition, each item of the actual checklist is introduced in order from the article of software audit practice / checklist details: development process (first part) , so if you are interested in the contents of the detailed items of the checklist, I think it’s good to see that article first.