Release judgment criteria・See also concern and risk management and baseline management

Concern and risk management and baseline management are also important in the development process

In this article, I 　will introduce the management of concerns and risks, and the management of baseline , among the seven items that Father Gutara checked to judge the process quality in the release judgment . The other 5 items (development planning, software design, implementation test planning, maintenance system and maintenance contract, gate process implementation status) are introduced in the previous and subsequent articles. Please have a look there.

4. Management of concerns and risks

Concerns and risks are also mentioned a bit in the confirmation section of the development plan. In the development plan, it is important to first write down the concerns and risks, but more importantly, as the development project progresses, manage the concerns and risks (create and implement a response plan). Situation tracing) to resolve concerns and risks by the time of release .

By the way, what are the concerns and risks in the first place, and what is the difference between the two? If you try to answer clearly, I think that there are many people who get stuck a little. There are various definitions of concerns and risks in software development projects, but Father Gutara used them properly as follows.

• Pending　: The problem in advancing the development project, is already happening now want it
• Risk : The problem in advancing the development project, it has been found likely to happen in the future want it

Concerns are problems that have already occurred, and risks are problems that will occur in the future.

Both concerns and risks are problems in advancing software development projects. There are various problems when trying to proceed with the project, such as technical problems , equipment problems used for development , delivery problems , personnel problems, and so on.

Among such problems, the problems that have already occurred are called concerns, and the problems that will occur in the future are called risks . For example, let’s take the problem of lack of test personnel as an example. If you’re still designing and testing hasn’t started, it’s a risk that you’ll run out of test staff, as it’s a future problem estimated at the planning stage. However, if the testing work has already begun and there is actually a shortage of test personnel, this is a problem that has already occurred and is a concern.

In other words, at the beginning of a development project, most problems are risks. Risks turn into concerns over time, and all issues that remain unaddressed at the end of a development project are concerns.

It is important that both concerns and risks have been dealt with at the time of release.

Both concerns and risks are issues that need to be addressed by the end of the project . Risks should be eliminated by taking some measures before they become a concern. On the other hand, the issue is a problem that has already occurred, so it is necessary to take action as soon as possible so that the impact on the project will not spread. It is necessary to plan and implement specific measures, such as who, what, and by what time to consider and implement the measures.

For that purpose, what kind of concerns and risks exist, who will consider and implement the measures by what time, the delivery date of the measures and the person in charge are clarified, and the progress is appropriately traced . I need a mechanism. This is, in other words, management of concerns and risks. Dealing with concerns and risks is one of the important items in managing software development projects, so it is important that the management is well done.

For example, at regular project meetings, you can check the status of countermeasures using a list of concerns and risks, or share a list of risks and concerns with project members and manage the status of countermeasures. There are various methods, such as checking at any time. Since it is only necessary to decide which method to adopt for each project, whether or not the process of managing the status of countermeasures for any concerns or risks was implemented as a process of the development project is determined in the development process. I confirmed it as one item of quality .

5. Baseline management

The next thing to check as the status of the management process is the status of baseline management . Some people may be a little unfamiliar with the baseline. The base line, documentation and source code and development environment on which to base the development of the software is that of.　

More specifically, it is the version of specifications and design documents, the version of source files, and the version of development environment (Build environment, integrated development environment, SDK tools) used when developing Sof . For example, if you need to use version 2.1 of the A-functional design document when using the functional design document for A-function, this version 2.1 is the baseline of the A-functional design document in its development .

Everyone involved in the project must refer to version 2.1 of the A-Functional Design Document . If anyone refers to version 1.0 or version 3.1, development will be disrupted.

Even in the source code, if there is a source file called Function-Ac, which is an A-function file, and if you modify Rev2.3.1 as its version to add functions, all the coder in charge will code based on Rev2.3.1. Must proceed.

Also, if there are tools used in the software development environment (code registration, build, debugging, etc.), everyone must be using the same version of the tool.

When it comes to writing, it’s quite natural. But, in a large software development is a little scale, mechanisms for the management of the base line and does not operate reliably it properly thought himself, using the design documents and source files and development environment that is different from person to person disturbed the base line It is possible that you were working on it.

For example, let’s assume that a software development project involving 30 software engineers was being developed on XXX-Develop-Tool using 15 design documents and 50 source files. prize.

As a matter of course, the versions of both the design document and the source file will be revised as the software development progresses . Occasionally, you may notice a design or implementation error and downgrade to the previous version. A revised version of XXX-Develop-Tool may also be released in the middle of a development project.

How can I ensure that all 30 people are always looking at the correct version of the design and source files ? Email notification to everyone every time a version change, always keep the latest version on the server and not keep it locally, regularly check the version of the design document and files that everyone is referring to, version control system There are various countermeasures to introduce.

Also, considering the development environment, how can we ensure that all 30 people are using the same version of XXX-Develop-Tool ? There are various countermeasures, such as one person preparing the development environment and everyone using it, or checking the version of the tool that everyone is using on a regular basis.

Any method can be used, but what kind of mechanism was used to manage the design documents, source files, and baselines of the development environment ? That is also an important part of confirming the software development process.