JP6359209B2 - Development progress management device and development progress management method - Google Patents

Description

  The present invention relates to a technique for managing the progress of software development.

  In software development, each design process, such as functional design, system design, and detailed design, is performed for each request. In order to design without omission in each design process, it is desirable to establish traceability between design documents.

  However, since the traceability establishment status and the progress status of the software development process have not been synchronized in the past, the process may proceed without creating a product to be created in a certain process. As a result, there is a case where a necessary function is omitted.

  In addition, functional safety standards (IEC61508, ISO26262, etc.) require secure traceability of functional safety requirements. Therefore, in software development, it is necessary to ensure traceability and manage progress based on it.

Special table 2014-534530 gazette

  In this regard, Patent Document 1 proposes a system that measures whether or not V-shaped traceability is established and warns the user when it is not established. However, there is a need for development progress management that ensures further traceability and does not leak requirements.

  The present invention has been made in view of the above-described problems, and an object of the present invention is to provide a development progress management apparatus or a development progress management method that suppresses the omission of software development requirements.

The development progress management apparatus of the present invention includes a traceability matrix that indicates a correspondence relationship between a request acquisition unit that acquires a request for software to be developed, and a product in the development process before and after the software development process set for each request. A process transition enable / disable determination unit that determines whether or not the development process can be transferred based on whether or not the traceability matrix has been acquired , and the request is a functional safety request related to functional safety and a normal request not related to functional safety The functional safety requirement includes a safety functional requirement related to functional safety and an original functional requirement other than the safety functional requirement, the normal requirement includes only the original functional requirement, and the traceability matrix is the first function requirement related to the original functional requirement. It includes a traceability matrix, a second traceability matrix regarding safety function requirements, a second Unit artifacts correspondence relationship is shown in traceability matrix, finer than the unit artifacts correspondence relationship is shown in the first Traceability matrix, step transition determination unit and safety requirements in pairs to shift possible function determination the conditions for the step transition determination unit current development process between the first traceability matrix and a second obtaining traceability matrix contains Murrell showing the correspondence between the artifacts in the previous development step.

The development progress management method of the present invention acquires a request for software to be developed, acquires a traceability matrix indicating a correspondence relationship between deliverables in the development process before and after the software development process set for each request, and develops It is determined whether or not the process can be transferred. Software requirements to be developed include functional safety requirements related to functional safety and normal requirements not related to functional safety. Functional safety requirements include safety function requirements related to functional safety and inherent functional requirements other than safety function requirements, and normal requests include inherent functional requirements only. Traceability matrix comprises a first Traceability Matrix relates inherent functional requirements, a second Traceability matrix about the safety function requirements, the. The unit of the product whose correspondence is shown in the second traceability matrix is finer than the unit of the product whose correspondence is shown in the first traceability matrix. In the determination of the shift enable, functional safety requirements in pairs to process change is possible and the conditions for determining, first traceability matrix and the shows the correspondence between the artifacts in the current development process and the previous development step including Murrell is possible to obtain a two traceability matrix.

The development progress management apparatus of the present invention includes a traceability matrix that indicates a correspondence relationship between a request acquisition unit that acquires a request for software to be developed, and a product in the development process before and after the software development process set for each request. A process transition enable / disable determination unit that determines whether or not the development process can be transferred based on whether or not the traceability matrix has been acquired , and the request is a functional safety request related to functional safety and a normal request not related to functional safety The functional safety requirement includes a safety functional requirement related to functional safety and an original functional requirement other than the safety functional requirement, the normal requirement includes only the original functional requirement, and the traceability matrix is the first function requirement related to the original functional requirement. It includes a traceability matrix, a second traceability matrix regarding safety function requirements, a second Unit artifacts correspondence relationship is shown in traceability matrix, finer than the unit artifacts correspondence relationship is shown in the first Traceability matrix, step transition determination unit and safety requirements in pairs to shift possible function determination the conditions for the step transition determination unit current development process between the first traceability matrix and a second obtaining traceability matrix contains Murrell showing the correspondence between the artifacts in the previous development step. By obtaining multiple traceability matrices with different units of deliverables that indicate the correspondence relationship as the transition condition to the next process, traceability of requirements is ensured, so it is possible to develop high-quality software with few requirements omissions I can do it.

The development progress management method of the present invention acquires a request for software to be developed, acquires a traceability matrix indicating a correspondence relationship between deliverables in the development process before and after the software development process set for each request, and develops It is determined whether or not the process can be transferred. Software requirements to be developed include functional safety requirements related to functional safety and normal requirements not related to functional safety. Functional safety requirements include safety function requirements related to functional safety and inherent functional requirements other than safety function requirements, and normal requests include inherent functional requirements only. Traceability matrix comprises a first Traceability Matrix relates inherent functional requirements, a second Traceability matrix about the safety function requirements, the. The unit of the product whose correspondence is shown in the second traceability matrix is finer than the unit of the product whose correspondence is shown in the first traceability matrix. In the determination of the shift enable, functional safety requirements in pairs to process change is possible and the conditions for determining, first traceability matrix and the shows the correspondence between the artifacts in the current development process and the previous development step including Murrell is possible to obtain a two traceability matrix. By obtaining multiple traceability matrices with different units of deliverables that indicate the correspondence relationship as the transition condition to the next process, traceability of requirements is ensured, so it is possible to develop high-quality software with few requirements omissions I can do it.

  Objects, features, aspects, and advantages of the present invention will become more apparent from the following detailed description and the accompanying drawings.

1 is a schematic diagram illustrating a configuration of a development progress management device according to a first embodiment. It is a figure which shows the development process of a functional safety request. It is a figure which shows the development process of a normal request | requirement. It is a figure which shows the internal structure of a development progress management part. It is a flowchart which shows operation | movement of a development process setting part. It is a figure which shows process definition data. It is a figure which shows workflow management data. It is a flowchart which shows operation | movement of a process workflow management part. It is a flowchart which shows operation | movement of the process transfer possibility determination part. It is a figure which shows process transfer condition definition data. It is a figure which shows the traceability matrix of a functional safety requirement. It is a figure which shows the traceability matrix of a normal request | requirement. It is a figure which shows the hardware constitutions of a development progress management apparatus. It is a figure which shows workflow management data. It is a figure which shows workflow management data.

<A. Embodiment 1>
FIG. 1 is a schematic diagram illustrating a configuration of a development progress management apparatus 101 according to the first embodiment. The development progress management apparatus 101 acquires a software requirement specification from a customer, and performs progress management of the development process for each request according to the request.

  The development progress management apparatus 101 includes a request input unit 1, a request storage unit 2, a development progress management unit 3, a development product storage unit 4, a traceability matrix (TM) storage unit 5, and a definition storage unit 6. Is done.

  The request input unit 1 acquires a software requirement specification from a customer. The software requirement specification describes a plurality of software requirements desired by the customer. The requirement is expected to be realized as a function or non-function, and means a specification given by a customer or a higher-level design. Of the requests, a request related to functional safety is called a functional safety request, and other requests are called normal requests. It is described in the requirement specification in advance whether the requirement corresponds to that. The software requirement specification acquired by the request input unit 1 is stored in the request storage unit 2.

  The development progress management unit 3 acquires a software requirement specification from the request storage unit 2, and sets process transition conditions for each request described therein. Further, in order to realize the requirement, a development process is set for each requirement that makes the requirement concrete at the software development level. In general, one request is realized by a plurality of requirements, but may be realized by one requirement.

  The development product storage unit 4 stores development products such as a system design document created as a result of the development work. The development products stored here include the original function development product 4A and the safety function development product 4B.

  The TM storage unit 5 stores a TM (original function TM5A) originally created in the development of functional requirements and a TM (safety function TM5B) created in the development of safety function requirements.

  The definition storage unit 6 stores data defining process transition conditions and development processes for functional safety requests and normal requests, respectively. The development progress management unit 3 makes the above settings with reference to this data.

  FIG. 2 shows a process for developing functional safety requirements. Functional safety requirements development includes safety requirement definition, requirements analysis, functional design (safety analysis), method design (safety analysis), detailed design (safety analysis), coding (safety analysis), unit test (safety analysis), integrated test (Safety analysis), SW test (safety analysis), system test, and safety requirement verification are performed in this order.

  In the requirements analysis process, the requirements are analyzed to derive one or more requirements to be developed. Among the requirements, requirements related to functional safety are called safety function requirements, and other requirements are originally called functional requirements. For example, if “play DVD on car display” is a functional safety requirement, “prohibit DVD screen display while driving” can be considered a safety function requirement, and “play DVD” can be considered a functional requirement originally. . Functional safety requirements include at least one safety functional requirement, and all requirements include at least one intrinsic functional requirement.

  In the requirement analysis step, a requirement analysis document is created as a product, and a traceability matrix (TM) indicating the correspondence between the content of the requirement analysis document and the requirement is created. TM is information indicating a correspondence relationship between deliverables between different processes, and thus it is possible to track whether development is being performed without omission. These deliverables and TM are originally divided into functional requirements and safety functional requirements. In the above example, the safety function TM5B is a TM that indicates the correspondence between the functional safety request “play DVD on the car display” and the safety function requirement “prohibit DVD screen display while driving”. The TM indicating the correspondence between the functional safety request and the original functional requirement of “play DVD” is the original function TM5A. Note that here, the creation of a product and a TM as different documents between the functional requirement and the safety functional requirement is explained, but if both can be identified, these product and TM May be described on the same document.

  The requirements analysis process is also a process of defining safety function requirements. Therefore, this process is also called a safety requirement definition process for safety function requirements.

  In the function design process, the structural design of software components for realizing the requirements, the design of the interface between components, the design of dynamic behavior, the design of resource management, etc. are performed. The component refers to a SW (software) system that is decomposed into functional levels such as navigation, telephone, and audio. In the functional design process, a functional design document is created as a product, and a traceability matrix (TM) is created. These are created for both safety function requirements and inherent function requirements. The TM created here is information indicating the correspondence between the contents of the requirement analysis document and the contents of the functional design document. Specifically, the functional design content of the requirements described in the requirement analysis document is the function design. This is information indicating where in the book. FIG. 2 shows functional design (safety analysis), which means that safety analysis is performed for safety function requirements in addition to normal functional design. In the safety analysis, a risk is hidden in a product, and a dangerous event that may occur when the product breaks down is extracted, and measures are taken to deal with them. As for the functional design and detailed design, which will be described later, safety analysis is performed for safety function requirements in addition to the normal design, as in the case of functional analysis. In addition, in addition to safety analysis, dependent failure analysis may be performed.

  In the system design process, structural design of subcomponents of components for realizing requirements, design of interfaces between subcomponents, design of dynamic behavior, design of resource management, and the like are performed. The subcomponent is a further breakdown of the component, and the subcomponent may be divided into a plurality of levels depending on the size of the software. In the system design process, a system design document is created as a product, and a traceability matrix (TM) is created. These are created for both safety function requirements and inherent function requirements. The TM created here is information indicating the correspondence between the contents of the function design document and the contents of the method design document. Specifically, the method design contents corresponding to the design contents described in the function design document are the methods. This is information indicating where in the design document.

  In the detailed design process, the logic and interface are designed in units (function, class level). A unit is a minimum unit that constitutes software by sub-components being decomposed into function (class) levels. In this process, a detailed design document is created as a product, and a traceability matrix (TM) is created. These are created for both safety function requirements and inherent function requirements. The TM created here is information indicating the correspondence between the contents of the method design document and the contents of the detailed design document. Specifically, the traceability matrix corresponds to the design contents described in the method design document. This is information indicating where the detailed design content is described in the detailed design document.

  In the coding process, a computer program (code) is produced according to the detailed design. In this process, a source code and a traceability matrix (TM) are created as a product. This traceability matrix (TM) indicates the correspondence between each design item of the detailed design and the code. In addition, although coding (safety analysis) is shown in FIG. 2, in addition to normal coding, coding conditions that should be achieved in developing functional safety requirements are observed for safety function requirements. It means to make sure.

  In the unit test process, it is verified whether the program (code) operates according to the detailed design at the function or class level. Here, a unit test report is created as a deliverable, and a traceability matrix (TM) is created. The TM created here indicates the correspondence between the detailed design document and the unit test report. Specifically, it indicates in which part of the unit test result document the test result of the design item of the detailed design is described.

  In the integration test process, it is verified whether the interface between each unit and subcomponent operates according to the system design document. Here, an integrated test report is created as a deliverable, and a traceability matrix (TM) is created. The TM created here indicates the correspondence between the system design document and the integrated test report. Specifically, it indicates in which part of the integrated test report the test results of the design items of the system design are described.

  In the software (SW) test process, it is verified whether the software is as designed as a function as a component. Here, a software test report is created as a deliverable, and a traceability matrix (TM) is created. The TM created here indicates the correspondence between the function design document and the software test report. Specifically, it indicates in which part of the software test result document the test result of the functional design item is written.

  In the system test process, it is verified whether the software system as a whole has the required software. In the development of safety function requirements, this process is called a safety requirement verification process in order to verify whether the software conforms to the safety function requirements. In this process, a system test report and a traceability matrix (TM) are created as deliverables. This traceability matrix shows the correspondence between the requirement analysis report and the system test report. Specifically, it indicates in which part of the system results report the test results for each requirement described in the requirements analysis document.

  In the example of FIG. 2, the functional safety requirement originally includes a functional requirement and a safety functional requirement, and a traceability matrix is created at each step for each of the two requirements. These traceability matrices are stored in the development product storage unit 4. Here, what is originally created for the functional requirements is also called a first traceability matrix, and what is created for the safety functional requirements is also called a second traceability matrix. The second traceability matrix is created with a finer granularity than the first traceability matrix. The granularity of the traceability matrix includes the document level, chapter / section level, requirement level, etc., and the later, the more time is required. In general, the design and development of safety function requirements requires a traceability matrix with a requirement level granularity. However, if the first traceability matrix is created with the most detailed granularity, it may have the same granularity as the second traceability matrix.

  The development progress management apparatus 101 permits the transition to the next process for functional safety requirements on condition that both the first traceability matrix and the second traceability matrix are created. For example, if the current process is a system design, the transition to the detailed design process is permitted when the first traceability matrix and the second traceability matrix are created in the current process. Therefore, in the development of functional safety requirements including at least one safety function requirement, it is not possible to move to the next process without creating a traceability matrix for both the safety function requirement and the original function requirement. Is established and design development can be performed without omission.

  Next, the normally required development process will be described with reference to FIG. Since the normal requirements originally include only functional requirements, the development process set for the normal requirements does not include safety analysis. There is no safety requirement definition and safety requirement verification. Further, in the development of normal requirements, a requirement analysis document and a traceability matrix (TM) are created as deliverables for the original functional requirements. In other words, in the normally required development process, only the first traceability matrix related to the original functional requirements is created.

  The development progress management apparatus 101 permits the transition to the next process on the condition that the first traceability matrix is created for the normal request. For example, if the current process is a system design, the transition to the detailed design process is permitted when the first traceability matrix is created in the current process. As described above, since the normal process can proceed to the next process by creating the first traceability matrix having a coarse particle size, the design and development can be performed efficiently.

  In addition, by setting different processes for functional safety requirements and normal requirements in this way, development of functional safety requirements, which are important requirements, is carried out in a process that matches the importance, and development of normal requirements is performed. Can be efficiently developed by implementing the standard process.

  FIG. 4 is a block diagram showing an internal configuration of the development progress management unit 3. The development progress management unit 3 includes a process workflow management unit 31, a process transition availability determination unit 32, and a development process setting unit 33. The development process setting unit 33 sets different workflows depending on whether the requirement to be developed is a functional requirement or a safety functional requirement. The operation will be described below with reference to the flowchart of FIG.

  First, the development process setting unit 33 extracts the request R from the request storage unit 2 (step S1), and determines whether the request R is a functional safety request (step S2). Whether it is a functional safety request is described in, for example, the request R itself. When the request R is determined to be a functional safety request, the development process setting unit 33 refers to the definition storage unit 6 and extracts process definition data of the functional safety request (step S3). Alternatively, when it is determined that the request R is not a functional safety request, that is, when the request R is determined to be a normal request, the development process setting unit 33 refers to the definition storage unit 6 and extracts process definition data of the normal request (step S4).

  FIG. 6 shows process definition data managed by the request storage unit 2. FIG. 6A shows the process definition data for normal functional requirements, and FIG. 6B shows the process definition data for functional safety requirements. The development process setting unit 33 sets the workflow of the request R according to these process definition data (step S5).

  Next, if the workflow setting has not been completed for all the requests R stored in the request storage unit 2 (step S6: No), the process returns to step S1, and if completed, the workflow setting process is terminated.

  The process workflow management unit 31 holds the workflow management data shown in FIG. 7, and manages the workflow using the data. The workflow management data illustrated in FIG. 7 includes a request ID, information indicating whether the request is functional safety, a requirement ID, a mark indicating whether the requirement is functional safety, a requirement description, a current process, and a status of the current process. The ID of the product (design document etc. and traceability matrix) of each process is included. Of the requests shown in FIG. 7 (parking assist function, warning display function, music playback function), the parking assist function and the warning display function correspond to functional safety requests because they include one or more functional safety requirements. Such information is created by a design developer or the like, and is managed by the process workflow management unit 31.

  The workflow management processing by the process workflow management unit 31 will be described below with reference to the flowchart of FIG. First, the process workflow management unit 31 acquires the current process with reference to the workflow management data (step S11). According to the example of FIG. 7, the current process is scheme design. Next, the process workflow management unit 31 obtains the determination result of whether or not the process can be transferred by the process transferability determining unit 32 (step S12). If the determination result is not process transition (step S13: No), the process returns to step S11. If the determination result acquired in step S12 is process transferable (step S13: Yes), it is determined whether the development of all processes has been completed (step S14). For example, if the current process is a system test (safety requirement verification), it is determined that the development of all processes has been completed, and the development is completed. If the current process is any other process, the process proceeds to the next development process (step S15), and the process returns to step S11.

  Next, the process transition availability determination process by the process transition availability determination unit 32 will be described with reference to the flowchart of FIG. The process transition availability determination unit 32 performs a process transition availability determination process in response to a request from the process workflow management unit 31. First, the process transition condition definition data is acquired with reference to the definition storage unit 6 (step S21).

  FIG. 10 is a diagram illustrating the process transition condition definition data acquired in step S21. FIG. 10A shows the process transition condition definition data for the normal request, and FIG. 10B shows the process transition condition definition data for the functional safety request. The process transition condition definition data for functional safety requirements includes “a traceability matrix (originally functional requirements) is created” and “a traceability matrix (safety functional requirements) is created”. This indicates that in the functional safety requirement, it is not possible to determine that the process transition is possible unless these two traceability matrices are created. On the other hand, the normally requested process transition condition definition data is blank, indicating that there is no process transition condition.

  The process transfer possibility determination unit 32 acquires the required specifications from the request storage unit 2 and the development product and TM from the development product storage unit 4 (step S22), and determines whether the development process transfer condition is satisfied (step S22). Step S23). Since there is no particular process transition condition for the normal request, the result is Yes in step S23, and the determination result indicating that the transition is possible is output to the process workflow management unit 31 (step S24). As for the functional safety request, when all the conditions described in the process transition condition definition data are satisfied, a determination result indicating whether or not transfer is possible (step S24), and in other cases, a determination result indicating whether or not transfer is possible (step S25). And output to the process workflow management unit 31.

  FIG. 11 illustrates a traceability matrix of functional safety requirements. This functional safety requirement is that the DVD playback screen is not displayed during traveling. On the other hand, the safety function requirement analyzed in the requirement analysis process includes “monitor vehicle speed and side brake state and display a DVD display prohibition screen during driving”. Also, the functional design items for this safety function requirement include “acquire vehicle speed from engine ECU in CAN”, “acquire side brake state from engine ECU in CAN”, “monitor DVD playback status in navigation / AV unit” , “Distribute DVD screen display determination block on navigation / AV unit” and the like. Thus, the traceability matrix shows the correspondence of the design deliverables between the processes.

  FIG. 12 illustrates a traceability matrix for normal requests. This normal request is “DVD playback”, and similarly to FIG. 11, this shows a correspondence relationship with request analysis, function design, system design, and detailed design.

  FIG. 13 is a diagram illustrating a hardware configuration of the development progress management apparatus 101. The development progress management apparatus 101 is realized by a processor 41 such as a CPU (Central Processing Unit), a memory 42, a storage medium 43 such as an HDD (Hard Disk Drive) or SD, and an input / output interface 44. The request input unit 1 is realized by an input / output interface (I / F) 44. The request storage unit 2, the development product storage unit 4, the TM storage unit 5, and the definition storage unit 6 are realized by the storage medium 43. The development progress management unit 3 is realized as a function of the processor 41 when the processor 41 executes a program stored in a memory 42 such as a RAM (Random Access Memory). However, these may be realized in cooperation with a plurality of processors 41, for example.

<B. Modification>
Although the development product storage unit 4 has been described as the configuration of the development progress management apparatus 101 in FIG. 1, it may be an external configuration of the development progress management apparatus 101 such as an external server.

  In the above description, the development progress management unit 3 is realized by the processor 41 of FIG. 13 operating according to the software program stored in the memory 42 or the like. However, instead of this, the development progress management unit 3 may be realized by a signal processing circuit that realizes the operation by a hardware electric circuit. As a concept combining the software development progress management unit 3 and the hardware development progress management unit 3, the word “processing circuit” can be used instead of the word “part”.

  In the above explanation, different processes are set for each requirement depending on whether it is a functional safety requirement or an original functional requirement. However, different processes may be set for each request unit. That is, a different process may be set depending on whether the functional safety request is a normal request, and the same process as the safety function requirement including the safety analysis process may be set as the original functional requirement constituting the functional safety request. In this case, the workflow management data managed by the process workflow management unit 31 is as shown in FIGS. In large-scale system development, since the number of requirements becomes enormous, the efficiency of system development can be increased and the cost can be suppressed by selecting a process for each request unit.

<C. Effect>
The development progress management apparatus 101 according to the first embodiment indicates a correspondence relationship between the request input unit 1 (request acquisition unit) that acquires a request for software to be developed and the deliverables of the development process before and after the request development process. A process transition availability determination unit 32 that acquires the traceability matrix to be shown and determines whether the development process transition is possible based on the acquisition status. Software requirements to be developed include functional safety requirements related to functional safety and normal requirements not related to functional safety. Functional safety requirements include safety function requirements related to functional safety and inherent functional requirements other than the requirements for safety devices, and normal requests include inherent functional requirements only. The traceability matrix originally includes a first traceability matrix related to functional requirements, and a second traceability matrix related to safety functional requirements that is finer in granularity than the first traceability matrix. The determination condition of the process transferability determination unit 32 for the functional safety request includes that the process transferability determination unit 32 acquires the first traceability matrix and the second traceability matrix for the current process. Therefore, by obtaining a plurality of traceability matrices having different granularities as the conditions for shifting to the next process, the traceability of the requirements is ensured, so that high quality software with few requirements can be developed.

  The development progress management apparatus 101 further includes a development process setting unit 33 that sets different development processes depending on whether the software request is a normal request or a functional safety request. Therefore, for example, by setting a process such as safety analysis according to its importance for functional safety requirements, and setting a process that omits safety analysis for normal requirements, development that achieves both safety and efficiency is achieved. Can be done.

  In addition, since the process transition possibility determination unit 32 determines whether or not the process transition is possible under conditions that are less than the functional safety request with respect to the normal request, the efficiency of design development of the normal request can be increased.

  In addition, the determination condition of whether or not the process transferability determination unit 32 responds to the normal request includes that the process transferability determination unit 32 acquires the first traceability matrix for the current process. Therefore, since the first traceability matrix is coarser than the second traceability matrix, the process is transferred under a condition that is less than the functional safety requirement that the acquisition of both the first traceability matrix and the second traceability matrix is a process transfer condition. I can do it. Therefore, it is possible to efficiently perform design and development that normally requires.

  In addition, the development progress management method according to the first embodiment acquires a request for software to be developed, acquires a traceability matrix indicating a correspondence relationship between products in the development process before and after the development process of the request, The request includes a functional safety request related to functional safety and a normal request not related to functional safety, and the functional safety request is an original function other than the safety function requirements related to functional safety and the safety function requirements. The traceability matrix normally includes only functional requirements. The traceability matrix includes a first traceability matrix related to inherent functional requirements and a second traceability matrix that is finer in granularity than the first traceability matrix related to safety functional requirements. The criteria for determining whether or not a process can be transferred to a functional safety requirement is the first condition for the current process. It includes obtaining a p o capability matrix and the second traceability matrix. Therefore, by obtaining a plurality of traceability matrices having different granularities as the conditions for shifting to the next process, the traceability of the requirements is ensured, so that high quality software with few requirements can be developed.

  In the present invention, the embodiments can be appropriately modified and omitted within the scope of the invention.

  Although the present invention has been described in detail, the above description is illustrative in all aspects, and the present invention is not limited thereto. It is understood that countless variations that are not illustrated can be envisaged without departing from the scope of the present invention.

  DESCRIPTION OF SYMBOLS 1 Request input part, 2 Request storage part, 3 Development progress management part, 4 Development product storage part, 5 TM storage part, 6 Definition storage part, 31 Process workflow management part, 32 Process transfer possibility judgment part, 33 Development process setting Part, 41 processor, 42 memory, 43 storage medium, 44 input / output interface, 101 development progress management device.

Claims (5)

A request acquisition unit for acquiring a request for software to be developed;
Obtain a traceability matrix indicating a correspondence relationship between the products in the development process before and after the software development process set for each request , and determine whether the development process can be transferred based on whether the traceability matrix has been acquired. A process transition determination unit for determining,
The request includes a functional safety request related to functional safety and a normal request not related to functional safety,
The functional safety request includes a safety function requirement related to functional safety and an original functional requirement other than the safety function requirement,
The normal request includes only the original functional requirements,
The traceability matrix includes a first Traceability matrix relating to the original functional requirements, a second Traceability matrix for the previous SL safety function requirements, and
The unit of the product whose correspondence is shown in the second traceability matrix is finer than the unit of the product whose correspondence is shown in the first traceability matrix,
The process conditions for transition determination unit determines that change is possible in pairs on the functional safety requirements, the process proceeds judging unit is correspondence between artifact in the current development process and the previous development step the first traceability matrix and the second obtaining traceability matrix contains Murrell shows a
Development progress management device. A development process setting unit for setting different development processes depending on whether the software request is the normal request or the functional safety request;
The development progress management apparatus according to claim 1. The process transition propriety determination unit determines whether or not a process transition is possible under conditions that are less than the functional safety request for the normal request.
The development progress management apparatus according to claim 1. The conditions for the step transition determination unit determines that change is possible in pairs to the normal request, the correspondence between product in the step transition determination unit current development process and the previous development step It includes obtaining the first traceability matrix shown,
The development progress management apparatus according to claim 3. Get software requirements to develop,
Obtain a traceability matrix indicating the correspondence between the products of the development process before and after the software development process set for each request,
Determine whether the development process can be transferred,
The request includes a functional safety request related to functional safety and a normal request not related to functional safety,
The functional safety request includes a safety function requirement related to functional safety and an original functional requirement other than the safety function requirement,
The normal request originally includes only functional requirements,
The traceability matrix includes a first Traceability matrix relating to the original functional requirements, a second Traceability matrix relating to the safety function requirements, and
The unit of the product whose correspondence is shown in the second traceability matrix is finer than the unit of the product whose correspondence is shown in the first traceability matrix,
In the determination of the shift enable, the conditions for determining the step change is possible to pair the functional safety requirements, the first traceability showing the correspondence between artifact in the current development process and the previous development step it contains Murrell to get matrix and the second traceability matrix,
Development progress management method.

Images