Soft audit Checklist・No20: In-house software design/implementation technology (1/2)

19/02/2021Audit for soft-Develop..

At the end of the design and implementation checklist is a confirmation about the in-house software.

In the articles before and after this, 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, (4) design and implementation , and this article introduces (4) individual items of in-house software in design and implementation . (The checklist itself can be found in the article on Software Audit Practice / Checklist No. 17: Development Technology / Design and Implementation (Overview) , so please refer to that.)

Checking the quality of in-house software measures development ability based on specific bugs

In contrast to the three software brought in from outside the company that we have seen so far, there are various items to check for software developed in-house. For software developed in-house, we design, implement, and test it in-house, so the focus is on confirming a good development process (procedures and rules) to carry out these tasks with good quality .

And I check this development process using the checklist about the development process as described in another article . Therefore, in this design / implementation checklist, we will look at the quality of software development ability by checking the countermeasure status for bugs that often occur in more specific embedded software .

Similar bugs are repeated in the field of software development

Of course, it is not possible to cover all of the various bugs. However, it often happens that bugs with the same tendency as those who have been working in the embedded software industry for many years occur periodically. When a bug related to a certain technology occurs, measures and education are implemented to prevent similar bugs, and such a bug does not occur for several years. However, when people who experienced bugs at that time became managers and left the field of software development, that is, the field of coding and debugging, new people are causing similar bugs again. In the past and now, embedded software has many bugs, in other words, the parts that are difficult to design and implement have not changed much .

By confirming how much the development team is aware of such parts and how much attention is incorporated into the development work to prevent such bugs from occurring , the software development organization’s You can measure the quality of your development ability.

Whether there are many beginners or veterans at the development site, that is important

In fact, in every country, where there are many young software engineers, the precautions described here are often not fully recognized. On the contrary, in places where there are many veteran engineers for 10 years or more, what is written here is that, it is dangerous here, so we will check it like this.

This difference is very large in software development where design, implementation, and testing all depend on the brains of engineers . Therefore, in order to measure how much technical ability you have in designing and implementing such software, it is this check item to ask questions about some specific problems. Let’s look at them in order.

[Item number: IS-01]

The top batter is FROM. I’m sorry, Flush ROM is abbreviated as FROM, but it’s basically flash memory. It may be better to say SSD or SD card these days. This Flush ROM takes longer to write than D-RAM (Dynamic RAM) . Therefore, if you forget to perform exclusive control at a place where exclusive control of access is required , data will be written down or undefined data will be read immediately . If the data in the Flush ROM is rewritten according to the operation of the program, pay attention to whether the necessity of exclusive control is properly designed and implemented, and how to confirm the necessity of exclusive control. I will confirm it.

[Item number: IS-02]

Accessing the Flush ROM is especially time consuming to write, but in some cases it can be even longer . Depending on what intermediate processing is performed before accessing the physical Flush ROM chip, writing to the Flush ROM is realized by erasing blocks and writing new values, so the presence or absence of this block erasure The required time will change depending on the necessity of. In addition, if there is a layer of file system in between, the garbage collection process sometimes works and you may have to wait for a very long time. Including even such a scene, authors Flush ROM maximum waiting time required for access to properly guess, and not the design and implementation of software, what, etc. or in unnecessary place timeout normal and occurs The process may end with an error. We will check whether the design and implementation precautions regarding the access time of such Flush ROM are properly taken.

[Item number: IS-03]

Access to the Flush ROM actually tends to be the highest during the boot process . In addition to normal processing, many accesses to the Flush ROM occur, such as reading programs and various setting information from the Flush ROM and writing various log information at startup to the Flush ROM. Again, if you don’t properly estimate the maximum Flush ROM access time , processing timeouts will occur in unexpected places . Pay attention to the fact that the amount and timing of access to the Flush ROM at startup is properly recognized by the design and implementation so that problems do not occur.

[Item number: IS-04]

Timers and counters are often used in programs for a variety of purposes, but if not handled with care, there is a risk of introducing a time bomb bug and causing major problems. The time bomb bug is a name given by my father Gutara, but I call it a bug that always occurs over time . When a product running on the market has a problem with this bug , it is often a very big problem because all products have a problem . Therefore, you should be very careful about time bomb bugs. And be careful with timers and counters as they risk causing this time bomb bug. So, first, list the variables that make up timers and counters, and make sure that you are aware of them as important design / implementation items .

[Item number: IS-05]

The first thing to note about timers and the variables that make up counters is the data type and size . Once the data type and size are determined, the maximum value that the timer or counter can handle is determined. To determine if your design / implementation is designed with this maximum value in mind, first check how to determine the data type and size. Of course, the size must be a data type that can hold the maximum value used by the timer or counter. Note that especially when using signed integers , you can only hold up to half the value of an unsigned integer. We will pay attention to such a viewpoint and confirm.

It’s getting a little longer, so I’ll write more in the second half of the article.

Next : Soft audit Checklist ・No21: In-house software design / implementation technology (2/2)