JP2012208664A - Integrated management system for software design/operation - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an integrated management system for software design/operation, from a requirement definition to estimate, design, manufacture, operation, and defective cases.SOLUTION: An integrated management system comprises includes a database storing requirement information, estimate information, design information, and operation information. The integrated management system also includes a design information management unit, an estimate information management unit, and an operation information management unit. The design information contains at least functional specifications, external interface specifications, screen design specifications, business form design specifications, database design specifications, and program design specifications as design factors, and the design information management unit manages the design information. The estimate information contains development man-hour for cases released in the past and result values of development terms as estimate factors, and the estimate information management unit calculates an estimate value of a novel development case on the basis of the estimate factors. The operation information contains client information as an operation factor, and the operation information management unit manages the operation information. The integrated management system further comprises means for linking the design factors, the estimate factors, and the operation factors which are in a range to be affected one another, storing the linked factors and registering/modifying/retrieving/referencing that information between subsystems as well.

Description

  The present invention relates to a software design / operation integrated management system that combines requirement information, design information, program information, and operation information.

  Conventionally, many systems for supporting software design and operation or estimation of development work are known. For example, Patent Document 1 describes a design support system in which a system configuration diagram is created from input configuration information, system requirements are input, and operation policy data is generated and reflected in the configuration information. Patent Document 2 also includes an operation requirement DB for storing operation work items, operation conditions, and service levels, a screen for displaying the contents of the operation requirement DB, a means for inputting design items, and an input operation design item. In addition, an operation design support system for calculating costs and creating design documents is described. Patent Document 3 describes an estimation work support system that displays a screen that prompts the operator to specify the estimate of software scale and development man-hour, and the worker inputs information on the screen that is displayed sequentially. Yes.

JP 2009-251672 A JP 2009-075961 A JP 2003-263320 A

  However, the system described in the above-mentioned patent document supports design, operation, and estimation individually, but does not support them together. Requirement information, estimate information, design information, program information, and operation information (including failure information) are closely related to each other, and the extent of influence that some changes have on others must be managed reliably. There are many systems that support the management of program module relevance and change in the detailed design and programming stages, from requirements definition to estimation, design, manufacturing (programming and testing), operation and maintenance. There are still few mechanisms that can support all together. Therefore, there is a demand for a system capable of comprehensively managing information in a detailed level at each stage by organically combining the information.

  In the present invention, in view of the above problems, detailed information is organically associated with each component level of software from requirement definition to estimation, design, manufacturing, operation and failure, and integrated software design / operation The purpose is to provide an integrated management system.

In order to solve the above problems, the software design / operation integrated management system of the present invention provides the following solution.
A software design / operation integrated management system that supports from software requirement definition to development estimation, design, and operation, including requirement information that defines a business case, estimate information created based on the requirement information, and A database for storing design information created based on the requirement information and operation information after the release of software manufactured based on the design information is provided. The design information includes at least a functional specification and an external interface design. Document, screen design document, form design document, DB design document, and program design document as design elements, the design information management unit that manages the design information, and the estimate information includes the development man-hours of projects released in the past, Estimate information management unit that includes the actual value of the development period as an estimate element and calculates the estimate value of a new development project based on the estimate element The operation information includes customer information of the destination where the software operates as an operation element, and an operation information management unit that manages the operation information, the design element, the estimation element, and the operation element, Means for linking elements in the range of influence to each other and storing them in the database; and means for registering / modifying / searching / inquiring the linked information between the information management units. .

  According to such a configuration, the information managed by the design information management unit, the estimate information management unit, and the operation information management unit is managed on the database by linking the information that influences each other in units of elements. Since each information can be created / changed / referenced between subsystems such as the management unit, design information management unit, operation information management unit, etc. Supports estimation, design, and operation with a consistent system.

The system of the present invention can further include the following features.
The customer information includes contact information of a person in charge of the customer, and the contact information is linked to a program constituting the software or a design element corresponding to each output of the program, and when the failure of the software occurs The customer information linked to the design element in which the failure is detected is displayed.

  According to such a feature, as a failure support function of this system, with respect to design information at a detailed level corresponding to a program (program module) constituting a software or a program output (file, screen, form, etc.), Link customer contacts that need to be contacted when a program or program output fails. In this way, for each element of the design information, it is possible to display a contact that needs to be contacted at the time of failure, and it is possible to support prompt contact at the time of failure. For example, if it is a program that outputs a form to an end user, and an error is found in the form data, the customer's end user will be greatly affected. Because there is.

The system of the present invention can further include the following features.
The customer information includes information describing a coping method at the time of failure, and the coping method linked to the design element in which the failure is detected is displayed at the time of the failure.

  According to such a feature, when a failure occurs, a contact address is displayed for each element, and a predetermined countermeasure method for a failure can be displayed to an operation status monitor or the like (operator). For example, when a job is abended, it is possible to take necessary measures such as stopping a subsequent linked job. By doing in this way, the judgment at the time of a failure can be performed quickly.

The system of the present invention can further include the following features.
The coping method includes a time required for completion of failure recovery, and prompts an operator of the operation information management unit to notify a customer when the scheduled time for completion of failure recovery is later than the time required for completion of failure. It is characterized by that.

  According to such a feature, when a maintenance person or the like inputs the scheduled time for completion of recovery and recovery is expected at an early stage, it is possible to perform processing such as avoiding unnecessary communication. By doing in this way, the judgment at the time of a failure can be performed accurately.

In addition, the system of the present invention can further include the following features.
The estimate information management unit uses FP = k + a ₁ × [number of screens] + a ₂ × [number of forms] + a when the number of screens, forms, functions, and external file items are set as design parameters. _{In the} FP calculation formula defined by ₃ × [number of functions] + a ₄ × [number of external file items] +..., K ₁ , a ₁ , Various constants of a ₂ are calculated by regression analysis.

  According to such a feature, as an estimate support function of this system, the FP value of the past case stored by the estimate information management unit and the above various parameter actual values are substituted into the above calculation formula, By obtaining various constants (coefficients) by regression analysis, the estimate is quantified based on the idea of a method for measuring the scale of the software based on the number of functions in the FP (Function Point) method. One FP calculation formula can be obtained.

The estimate support function may further include the following features.
The estimate information management unit calculates a predicted FP value by inputting predicted values of the number of screens, forms, functions, and external file items of a newly developed project into the FP calculation formula obtained for the various constants. It is characterized by doing.

  According to such a feature, an estimated FP value for a new case can be obtained by estimating the number of parameters of the new case and inputting it into the FP calculation formula in which a constant (coefficient) is obtained by the above regression analysis.

The estimate support function may further include the following features.
The estimated information management unit adds the actual number of screens, forms, functions, and external file items after the release to the FP calculation formula before determining the various constants after the release of the newly developed case. Is input, and feedback is applied to the FP calculation formula by obtaining various constants again.

  According to such a feature, after a new case is released, by inputting the FP actual value and various parameter actual values, various constants of the above FP calculation formula are obtained again, and the FP calculation formula itself is fed back. be able to. By doing in this way, more accurate estimate can be performed as the case information is accumulated.

The estimate support function may further include the following features.
The estimate information management unit includes an actual value of a skill value of a developer in charge, and estimates a work period of a new case from the calculated FP estimate value and the skill value.

  According to such a feature, the FP predicted value can be obtained as an estimated number of days (estimated work period) instead of a person day.

  According to the present invention, there is provided an integrated management system for software design / operation integrated and organically related at the component level of software from requirement definition to estimation, design, manufacturing, operation, and failure. Can do.

1 is a diagram illustrating an overall image of a software design / operation integrated management system according to an embodiment of the present invention. FIG. It is a figure which shows the definition of a design term. It is a figure which shows the screen transition of subsystem information management. It is a figure which shows the link of requirement information and design information. It is a figure which shows the link of design information and a program. It is a figure which shows the judgment support at the time of trouble communication (Case1). It is a figure which shows the judgment support at the time of trouble communication (Case2). It is a figure which shows the judgment assistance screen image at the time of trouble communication. It is a figure which shows the outline | summary of estimation assistance. It is a figure which shows an estimate assistance screen image. It is a figure which shows a development man-hour estimation logic. It is a figure which shows the example of a development man-hour estimation logic. It is a figure which shows a development period estimation logic. It is a figure which shows the example of a development period estimation logic.

  DESCRIPTION OF EMBODIMENTS Hereinafter, embodiments for carrying out the present invention (hereinafter referred to as embodiments) will be described in detail with reference to the accompanying drawings. Note that the same number is assigned to the same element throughout the description of the embodiment.

  FIG. 1 is a diagram showing an overview of a software design / operation integrated management system (hereinafter referred to as the present system 100) according to an embodiment of the present invention. As shown in the figure, this system typically has a design information management unit 110, a change management unit 120, a workflow management unit 130, a release management unit 140, an estimate support tool, and an estimate information DB including a design information DB. The estimation information management unit 150 includes an operation management tool and an operation information DB 160, and the resource management unit 170 includes a resource management tool and a program source management DB. Each management unit functions as a subsystem of the system 100.

  The design information management unit 110 is a design information management subsystem that includes a design information DB that stores various design documents in conjunction with various design support tools (screen design tool, form design tool, and the like). The design information DB stores a business flow definition document, a requirement definition document, and a functional design document based on the requirement definition document as a design document. In addition to screen design documents, form design documents, external I / F design documents based on this functional design document, database (hereinafter referred to as DB) design document, layout design document, code design document, parameter design document, message design Documents, program design documents, job net design documents and the like are stored. These design documents are also called design elements, and are files including the contents defined in the table of FIG. These design documents are linked (linked) to each other and stored in the design information DB in order to show mutual dependency. In the system 100, one or a plurality of server devices are connected to a plurality of user terminals via a network, and each file having a design information DB as a core is used for version management, influence range management, and change history management of each file. Do.

  The change management unit 120 is a subsystem that manages the change when the case information based on the design information is changed or when the design information is changed. The workflow management unit 130 includes a DB (not shown) defining a creator, a changer, an inquirer, an approver, etc. and an approval route when the design document is newly created, changed, or inquired. Subsystem for The release management unit 140 is a subsystem for performing release management, distribution management, lending management, autocommitment, etc. when performing system testing by combining programs after unit testing, and at the time of production release, revision, etc. .

  The estimate information management unit 150 refers to the estimate information of a similar past case when an estimate of a new case or a change estimate of an existing case is necessary, or the currently registered developer (SE Or a programmer, etc.) and a sub-system provided with an estimate information DB storing the unit price and the like. The estimate information of the system 100 is closely related to the case information and the design information.

  The operation information management unit 160 stores an operation tool for monitoring the operation status after the software is operated in an actual user environment, and an operation information DB that stores contact information for notifying the details of the failure and the related person at the time of the failure. It is a subsystem equipped with. The operation information of the system 100 is closely related to the case information and the design information.

  The resource management unit 170 analyzes a source file of a program being developed and released, manages the relationship between programs, and creates a CRUD (Create, Read, Update) of the source file. , Delete), a subsystem including a resource management tool and a program source management DB storing such information. In addition to the above-described subsystems, the system 100 includes a unit test management unit that manages manufacturing and unit tests, a PGM generation unit that automatically generates programs based on a program design document, and the like. Yes.

  In the present system 100, in order to securely link the information relation between the subsystems and between the subsystems, documents in the requirement definition stage, estimation stage, design stage, manufacturing stage (programming stage), test stage, operation stage, An ID (identifier) is assigned to each component of the data (which will be referred to as “requirement information element”, “estimation information element”, “design information element”, “program element”, and “operation information element”, respectively). It is characterized by being defined and linked to each other and stored in a DB. In other words, a file or information given an ID is called an “element”. The design element includes the above-described various design documents, and the estimate information element includes information on past projects and information on developers and operations personnel. The operation information element includes operation status data and customer information.

The illustrated configuration is merely an example, and one functional unit (subsystem) may be further divided, or a plurality of functional units may be configured as one functional unit. Each functional unit has a CPU (Central Processing Unit) built in the server device and a ROM (Read Only
A computer program stored in a storage device such as a memory or a hard disk is read, and the computer program executed by the CPU is stored in a database (DB; Data Base) stored in the storage device or a storage area on the memory. This is realized by reading / writing necessary data and controlling related hardware (for example, input / output device, display device, communication interface device) in some cases. In addition, the database (DB) in the embodiment of the present invention may be a commercial database, but it simply means a collection of tables and files, and the internal structure of the database itself does not matter.

  FIG. 2 is a diagram showing the definition of design terms. This table summarizes the definitions of terms used mainly at the time of design. For example, “parameter design” is defined as “work that defines business data that can easily change the behavior of the system”, and the output document of the work is a parameter design document. is there. A design document (design information file) stored in the design information DB is a file that defines the contents of this table, and is created according to a predetermined format in accordance with the screen design tool, form design tool, etc. of the system 100. In addition, there are business flow definition documents, requirement definition documents, function definition documents, and the like that may be in any file format. Further, this table is an example, and there are design terms that are not particularly shown in the table.

  FIG. 3 is a diagram showing screen transition of subsystem information management. The software design / operation integrated management system 100 of the present invention is used in various aspects from requirement definition to estimation, design, programming, testing, release, operation, and troubleshooting, in order to support each aspect, It consists of multiple subsystems already mentioned. Since the information registered in the system 100 is linked and related to each other, the information needs to be shared not only within the subsystem but also between the subsystems. Here, screen transition is described for information management between a plurality of subsystems. In addition, the system 100 is provided not only with information sharing but also with a tool that supports the above-described various tasks, such as a project leader, a designer, a programmer, a tester, an operation monitor, It goes without saying that information appropriate to each role is provided to maintenance personnel.

  In order to access the system, the user must first log in from the login screen. The login screen may be common to other subsystems, or may be a separate screen for each subsystem. Here, it is assumed that a certain user is a user who normally uses the A subsystem and in some cases makes an information inquiry to another subsystem (referred to as B subsystem). When the user successfully logs in to the A subsystem, a menu screen supported by the A subsystem is displayed. Here, for information linkage, the “registration / modification screen”, “search screen”, and “inquiry screen” are broadly classified.

  At the time of searching / inquiring information registered in the system, the user searches for necessary information from the prosecution input screen (SF-A21-01) using keywords or the like, and the result is displayed as a search result screen (SF-A21-02). To display. When the necessary information ID (target definition ID) is found on the search result display screen (SF-A21-02), clicking the link displayed on the screen displays the inquiry screen (SF-A21-03). You can refer to that information. From the inquiry screen, the user can move to the change history inquiry screen (SF-B02-03) and refer to the change history. As shown in the figure, the inquiry screen can be switched to the registration / correction screen at any time by pressing a plurality of Tab keys or the like.

  At the time of registration / correction, it is possible to input information to be newly registered in the system from the input screen (SF-A21-04) or to correct the registered information. By pressing the “execute” key on the registration / correction input screen (SF-A21-04), a confirmation screen (SF-A21-05) is displayed. When registration / correction is completed, a completion screen (SF-A21-06) is displayed. ) Is displayed.

  When the user needs to access information under the management of the B subsystem, which is another subsystem, an application search for accessing the B subsystem is performed from the application search input screen (SF-B01-01). . This application is processed as it is if it is a project related person, but the approval workflow subsystem may be used when necessary, such as when an outsider accesses. Other typical uses of the approval workflow subsystem include “design information changes” that are considered important changes. When this application is processed, the application search result screen (SF-B01-02) is displayed, from which it returns to the A subsystem inquiry screen (SF-A21-03) and subsequently accesses information under the B subsystem. Will be able to. This is because, by this application, the B subsystem inquiry screen (SF-A16-03) is linked from the A subsystem inquiry screen (SF-A21-03) by the target definition ID. This eliminates the trouble of logging in to the B subsystem again. By providing such an information management screen, the user can easily access between a plurality of subsystems, and the cooperation of each information advances.

  FIG. 4 is a diagram showing a link between requirement information and design information. As described above, the files stored in the design information DB are linked (linked) to each other. Here, as an example, the link between requirement information and design information is shown. The requirement information is a file describing the business flow definition and the requirement definition. As shown in FIG. 2, the business flow is a work (activity) for clarifying the business of the customer, and the requirement definition is a work for clarifying the role that the customer desires for the system that is vaguely considered. As shown in the figure, multiple requirement definitions may be generated from one business flow definition. Each defined file is assigned a change management ID such as an activity ID (BA01) and a requirement ID (RQ01, RQ02), and each change management ID is linked (indicated by a thick solid line). Managed on DB.

  The design information repository (design information DB) includes a functional design document, an I / F design document that is an interface with humans such as screens and forms, a DB design document that defines the details (tables, etc.) of the DB, and a program (PGM). Files are stored, and IDs (function IDs, screen IDs, form IDs, table IDs, program IDs) corresponding to the respective files are assigned and the respective IDs are linked. The program ID is linked with the ID of the unit test scenario or unit test case and used in test management. Each link is made by the information creator, in many cases by specifying the ID of the information referred to when creating the information, but when creating it in a predetermined format such as a program design document The ID of the link destination is included in the format. In the case of a program source file, it is also possible to analyze the source file and automatically create link information from the module call relationship.

  FIG. 5 is a diagram showing a link between design information and a program. This figure shows a simple example of linking design information with jobs and programs. As shown in the figure, the data linkage job net 10 (ID: JN11) follows the subsequent data linkage job net 20 (ID: JN12). A job net is a collection of one or more jobs that specify an execution order. In this figure, two job nets that link data are shown.

  The data linkage job net 10 includes two jobs, a data linkage job 11 (ID: JB11) and a form output job 12 (ID: JB12). The data linkage job 11 is linked to a data linkage main 13 (ID: PG11) which is a main program for data linkage, and the data linkage main 13 includes a file output subroutine 15 (ID: PG01) and a form output subroutine 16 ( ID: PG02). The file output subroutine 15 is a program that outputs a file for data linkage with an external subsystem. The output file is assigned IF01 as an I / F ID, and this ID is managed in association with an output subroutine as an ID for file linkage, for example, HULFT (registered trademark); (Host Unix Linkage File Transfer) ID. To do. The form output subroutine 16 is also a common subroutine called from the form output main 14 (ID: PG12). The form for customer confirmation (form form 18 (ID: RP01) and form form 19 (ID: RP02)) is used. Output.

  As described above with reference to the examples of FIGS. 4 and 5, in the system 100, from the requirement definition information to the functional specification, job definition, program, and finally output file or form, Each component (element) is assigned an ID, and the relationship between each component is linked and managed in the DB, so the range of influence of each component on other components (this is called the influence range) is detailed. Can be managed. The management of the influence range can be used not only for the design information at the time of development, but also for the management of the influence of the operation maintenance information after the development stage and the estimation stage before development. Therefore, hereinafter, a specific example will be described with a particular focus on determination support and estimation support at the time of failure.

  FIG. 6 is a diagram showing determination support (Case 1) at the time of failure communication. In this figure, as a specific example of influence range management by linking design information and operation information, determination support at the time of failure notification will be described. Here, as Case 1, it is assumed that the form data is found to be incorrect after starting operation in the real environment. It is assumed that the tree structure representing the link relationship between the components shown in the figure is basically the same as that in FIG.

  Here, customer information 17a, 18a, 19a, and 22a are linked to the interfaces 17 and 22 and the form forms 18 and 19 that are outputs of each job as links between design information and operation information. “Customer information” is a file that describes the contact information (department name, person in charge, telephone number) of the customer who operates the system that runs the target software, and information on how to deal with customer management in the event of a failure. It is. Although customer information may be defined at the time of design, it is usually set at the time of operation, so it is usually stored in the operation management information DB instead of the design information DB.

  Here, let us consider a case where a data error is detected in the form form 18 (ID: RP01). In this case, when a maintenance person or the like (operator) performs a predetermined operation on the operation management tool when an error is detected in the form form 18, customer information 18a linked to the form form 18 is displayed. In addition, when the system refers to the link information, all the components (indicated here by shading) that are the target of the affected range are displayed, and the form form 19 output by the same form output subroutine 16 is also checked side by side. Can be immediately determined. Furthermore, it is easily determined from this link information that there is an error in the file 17 (ID: IF01) output by the file output subroutine 17 as well as the form itself. If it is necessary to stop the HULFT kick job or the cause investigation is likely to take time, it can be immediately determined that the customer needs to be contacted.

  In addition to the customer contact information, the customer information 18a may include information for determining whether to contact immediately. For example, information that defines a case where a report is required immediately unconditionally, information that defines a case where only a subsequent report is required if resolved within a predetermined time, and the like. Further, the customer information may include not only the contact information of the customer but also the contact information of the developer or the project leader, etc., and the contact person ID in the DB storing the contact person information is linked. Also good. With such a link, even if a failure occurs, it is possible to define in detail for each component in which a failure occurs, to whom, in what procedure, and at what timing. On the contrary, it is possible to reduce unnecessary communication and reporting.

  FIG. 7 is a diagram illustrating determination support (Case 2) at the time of failure communication. In this figure, another example of determination support at the time of failure communication will be described as influence range management by linking design information and operation information. Here, as Case 2, it is assumed that the job has abended after starting operation in the real environment. Also here, it is assumed that the tree structure representing the link relationship between the components shown in the figure is basically the same as that in FIG.

  When it is detected that the form output job 12 (ID: JB12) is abended, the system refers to the link information of the components in the affected area, and the related components are shown to the maintenance staff as shown in the shaded area. Is displayed. First, in the same job, the form form 18 and the form form 19 are the output of this job, so the customer information 18a, 19a linked to them is displayed. In the customer information, when it is necessary to immediately notify the customer that a form is not output, necessary information for contacting the customer from the operator is displayed. In this case, since the form output job 12 is abended and stopped, the subsequent data linkage job net 20 is affected. For this reason, the subsequent data linkage job net 20 displays information on the predicted completion time and required completion time linked to this. Also, the data linkage job 21 displays whether the customer will be affected unless the cause of the previous job abend is determined. You can also avoid unnecessary customer contact. Further, when there is a job net for the next data linkage, if the HULFT transmission time is likely to pass in the interface 22 (ID: IF02), link information indicating that the operator needs to be contacted can be displayed. .

  As described above with reference to FIGS. 6 and 7, by linking customer information to each component at the time of design, more flexible operation and maintenance can be performed. In addition, information such as whether or not to contact the customer immediately, the expected completion time of failure, and the required time to complete is normally unpredictable at the time of design and is therefore managed by the operation management DB. It goes without saying that each component is linked between the management information DB and the operation information DB, and creation / change of information is managed.

  FIG. 8 is a diagram showing a judgment support screen image at the time of failure communication. In this figure, one screen image of an operation management tool used by a maintenance person or the like is shown. The horizontal line 30 in the center of the figure represents the time axis. Here, for example, when the system detects that the job has been abended by some means, the abbreviated job net ID, JN12 icon in this example is displayed as “×” along with the current time (December 1, 7:45). It is displayed as "Abend" (open text in the figure). When the maintenance staff clicks on the icon 31 of the abended job net JN12, detailed information 32 of the job net is displayed. Further, if there is a job net that needs to be completed in relation to the job net JN12, these icons are displayed as indicated by reference numeral 33. In particular, job nets that are within the influence range of the job net JN12 are displayed with shading as shown in the figure, indicating that “Caution required”.

  Here, for example, when the icon of ΔJN82 is clicked in “△ job net requiring attention”, detailed information 34 of the job net JN82 is further displayed. In the detailed information 34, in addition to the description of the job net JN12, as the system status, in addition to the scheduled completion time input by the person in charge of failure recovery, the completion completion time predetermined by the system is displayed. It is displayed that there is a possibility that it will not be in time for the completion required time. Further, in the detailed information 34 of the job net JN 82, an RP022 icon is displayed as an output target form, and when this icon is clicked, the detailed information 35 of the form RP022 (here, the corresponding customer contact information and the like are included). ) Is further displayed. The maintenance staff who sees this instructs the operator to contact the customer. In addition, the interface within the range of influence of the abended JN 12 is clicked on the icon 36 of the △ IF 11 that requires attention, and a customer contact 37 linked to this (in this example, the contact of the company responsible for the development) Is displayed, and it is understood that contact is necessary here. As described above, the system of influence range management of the present system can support the judgment at the time of fault communication in real time such as grasping the situation at the time of fault and displaying necessary contact information.

  FIG. 9 is a diagram showing an outline of estimation support. This figure shows a case where the estimation stage before the development start is supported as another specific example of the management of the influence range of this system. The estimate management system shown in the figure represents an image in which the estimate information management unit 150 described in FIG. 1 is linked with the design information management unit 110.

  Usually, a new development project estimate requires a requirement definition, and an estimate of a change in an existing system requires a function for managing the definition of change outline elements and the change impact. In addition, there may be a need for a development scope that defines development policies and assumptions. Furthermore, it is also necessary to analyze the performance of past similar projects, such as the number of man-hours for development and the number of man-hours to deal with failures. It is also necessary to consider the operating status of development personnel and personal skill values. In the present system, these pieces of information are mainly stored in the design information DB and the estimate information DB. Needless to say, each piece of information is managed by a change management ID and linked to each other.

  The estimate management system can input data obtained from each of the above inputs into a function point (FP) calculation formula and estimate a new case (this will be referred to as an improved FP method). In addition, by inputting requirements, related design information, changed external shape elements, personal skill values, etc., it is possible to deal with not only new project estimates but also existing project change estimates. Further, as shown at the right end of FIG. 9, since the output of the improved FP method is obtained as the total man-days of development, the work period can be estimated by dividing it by the individual skill value. The estimation support by the improved FP method will be specifically described in the following figures.

  FIG. 10 shows an estimate support screen image. This figure shows an image of a screen displayed to the estimate person by the estimate management system. The estimate person can select the type (requirement description, block description, etc.) he / she wants to inspect from the search window 40 in the upper left, and input a keyword of the project, etc., and search for related past matters. As a result of the search, as indicated by reference numeral 41 at the left center, a requirement ID, a requirement summary, an FP, the number of external design items (number of blocks, number of screens, etc.) are displayed in a list. Then, for example, when the RQ01 icon of the case ID is clicked, information associated with each requirement is displayed in a tree structure as indicated by the reference numeral 42 on the right. Further, as indicated by reference numeral 43 in the lower right, for each person in charge of the case, the hierarchy (skill level), the process in charge, and the actual man-hour (person day) are displayed.

  FIG. 11 is a diagram illustrating the development man-hour estimation logic. This figure explains the procedure for estimating the development man-hour using the improved FP method. The development man-hour estimation procedure is performed in three stages: (1) <preparation>, (2) <use method>, and (3) <feedback>. However, (2) <Usage method> includes two methods: “a method using an FP estimation formula” and “calculated by multiplying a similar case by a scale”. Hereinafter, an implementation method is demonstrated in order.

First, as (1) <preparation>, initial values of various constants (k ₁ , a ₁ , a ₂ ,...) Of an FP calculation formula (formula (1)) as illustrated are obtained. For this purpose, input parameters such as the number of screens, number of forms, number of functions, number of external file items, etc. are input from past actual values, and regression analysis is performed to estimate the sizes of the above various constants (coefficients). . In the above FP calculation formula, FP is a dependent variable in regression analysis, and each input parameter is an independent variable. There are various methods for regression analysis, but a typical method such as a least square method may be used. Actually, the estimate management system calculates various constants from the FP actual value and the actual value of each parameter only by selecting the project ID without inputting the FP actual value and each parameter one by one by the estimater. .

  When the calculation of the above various constants is completed, in (2a) <Usage method 1>, FP is calculated by substituting values for each parameter such as the number of screens, the number of forms, etc. To obtain an FP estimate. The inputs here are the various constants calculated in (1) <Preparation>, and the predicted values of each parameter such as the number of screens, the number of forms, the number of functions, the number of external file items, etc. to be estimated this time. By substituting this into the above FP calculation formula, an FP estimated value (person day) is obtained.

  In the above (2a) <Usage method 1>, the system is a “method using an FP estimation formula” in which an FP estimate is calculated from prediction parameters based on past actual values. In (2b) <Usage method 2>, If there is a case with similar requirements from the search result, the estimater determines a sense of scale by comparing the case with the case, and calculates an FP estimate using it as an input. The sense of scale is an abstract such as a comparison of the size of a case with a similar case (how much work amount is likely to be in this case), and it depends on the past experience of the estimator. On the contrary, it is also a practical method. Further, by using together with (2a) <Usage method 1>, it is also possible to make a more accurate estimate by combining simple calculation by a machine and intuition based on human experience.

The estimated FP value obtained as described above is (3) <Feedback> after the project is released, in order to improve the accuracy of the FP calculation formula using the actual FP value of the project and the actual values of various parameters as inputs. Used. That is, various constants (k ₁ , a ₁ , a ₂ ,...) Are recalculated so that the difference between the FP estimated value and the FP actual value is minimized. The various constants thus obtained will be used in the FP calculation formulas for the subsequent projects.

  FIG. 12 is a diagram illustrating an example of development man-hour estimation logic. This figure shows a simple specific example of the development man-hour estimation logic described in FIG. First, in (1) <Preparation>, it is assumed that an actual value as shown in Table 50 is given for each past case, and by performing regression analysis, the FP calculation formula is as shown in Formula (2). I want. However, here, for simplicity, the design parameters are limited to the number of table items and the number of correction screens. In this example, the amount (thousand yen) is used as the unit of FP, but various indicators such as standard man-hours may be used.

  (2a) In <Usage method 1>, various parameters of the current case A101 are predicted as shown in the table 51, and substituted in the formula (2) obtained in (1) <Preparation>, FP estimation = 80.6 + 12 .8 × 2 + 22.2 × 10 = 328.2 [thousand yen] and the FP estimate is obtained.

  (2b) In <Usage method 2>, it is assumed that the case most similar to case A102 is A002 in the table 50. Since A102 is likely to have a slightly more complicated function than A002, the amount of work is about 120%. Then, it can be simply predicted that FP estimate = 300 [thousand yen] × 120% = 360 [thousand yen]. Alternatively, when A102 can be predicted to be realized by changing A002, if the amount of change from A002 is 50%, it can be predicted that FP estimate = 300 [thousand yen] × 50% = 150 [thousand yen] . In such a case, the estimate varies greatly depending on which development scope is used, so it can be easily determined by using this estimate management system that attention is required.

  (3) In <Feedback>, the actual man-hour required when the case A101 arrives is also used as an input for the calculation formula. When the actual value is a result as shown in the table 52, when the FP calculation formula is created again using regression analysis, FP estimate = 71.3 + 14.7 × [number of table items to be corrected] + 8.2 × [ Number of correction screens] [Thousand yen]... Formula (2) ′

  FIG. 13 is a diagram showing the development period estimation logic. This figure shows a simple specific example of the development period estimation logic described in FIG. In the development period estimation, the work history of employees (in charge SE, programmer, etc.) held in the database is also used as past results. By using these pieces of information, it is possible to estimate not only the development time for new projects but also the work period. The procedure will be described below.

  First, in (1) <Preparation>, the formula (3) as shown in the figure is applied, and an individual ability value (skill value) is estimated by regression analysis. The inputs in this case are FP (specific work per specific project / man-hours per specific process (person day)) and work man-hour of employee i (employee i spent on one project / specific department / specific process) Man-hours). The output is the skill value of employee i (value obtained by factorizing employee skill).

  (2) In <Usage method>, the estimated work period (estimated days) is calculated by dividing the “FP estimate” calculated by the development man-hour logic of FIG. 11 by the skill value of the corresponding employee (formula (4) reference). The inputs in this case are the FP estimate, the skill value of employee i, and the work ratio of employee i (ratio where the employee focuses on the case (0 to 100%)). The output is the estimated number of days (estimated work period).

  (3) In <Feedback>, after the project release, the accuracy of the FP calculation formula (3) is increased by using the FP actual value and various parameters as inputs. The input in this case is the FP actual value and the work man-hour of employee i, and the output is the skill value of the employee.

  FIG. 14 is a diagram illustrating an example of the development period estimation logic. This figure shows a simple specific example of the development period estimation logic described in FIG. Here, for simplification, it is assumed that the process and work knowledge are ignored and the case is for the same process and the same work. First, in (1) <Preparation>, it is assumed that the work man-hours of the person in charge in each case are as shown in Table 60. Using this table as an input, the ability of each employee is obtained as shown in Table 61 from Equation (3) in the previous figure.

  (2) In <Usage method>, the development man-hour estimation logic described with reference to FIG. 11 is used, and a case where FP = 200 (thousand yen) is generated. When working in a system, as shown in the figure, it takes FP = 200 ÷ (1.3 +) = 50 days. If only the employee 1 worked on the same project, the development is expected to be completed in FP = 200 ÷ 6.4 = 32 days.

  As described above, the present system 100 supports software design development and operation, but is not limited to software development, but can be applied to development of various products and services including hardware. Is possible.

  As mentioned above, although this invention was demonstrated using embodiment, it cannot be overemphasized that the technical scope of this invention is not limited to the range as described in the said embodiment. It will be apparent to those skilled in the art that various modifications or improvements can be added to the above-described embodiments. Further, it is apparent from the scope of the claims that the embodiments added with such changes or improvements can be included in the technical scope of the present invention.

10, 20 Data linkage job net 11, 21 Data linkage job 12 Form output job 13 Data linkage main 14 Form output main 15 File output subroutine 16 Form output subroutine 17, IF ID
18, 19 Form 100 Software integrated design / operation management system 110 Design information management unit 120 Change management unit 130 Workflow management unit 140 Release management unit 150 Estimated information management unit 160 Operation information management unit 170 Resource management unit

Claims (8)

A software design / operation integrated management system that supports everything from software requirement definition to development estimation, design, and operation.
Requirement information that defines a business case, estimate information created based on the requirement information, design information created based on the requirement information, and operation after release of software manufactured based on the design information With a database to store information,
The design information includes at least a functional specification, an external interface design, a screen design, a form design, a DB design, and a program design as design elements, and a design information management unit that manages the design information;
The estimate information includes the development man-hour of the previously released matter, the actual value of the development period as an estimate element, and based on the estimate element, an estimate information management unit that calculates the estimate value of the new development matter;
The operation information includes customer information of the destination where the software operates as an operation element, and an operation information management unit that manages the operation information;
Means for linking the elements in the influence range to each of the design element, the estimated element, and the operation element and storing them in the database;
Means for registering / modifying / searching / inquiring the linked information between the information management units;
Software design and operation integrated management system characterized by having.   The customer information includes contact information of a person in charge of the customer, and the contact information is linked to a program constituting the software or a design element corresponding to each output of the program, and when the failure of the software occurs The software design / operation integrated management system according to claim 1, wherein the customer information linked to a design element in which a failure is detected is displayed.   The customer information includes information describing a handling method at the time of failure, and displays the handling method linked to a design element in which the failure is detected at the time of the failure. Integrated software design and operation management system.   The coping method includes a time required for completion of failure recovery, and prompts an operator of the operation information management unit to notify a customer when the scheduled time for completion of failure recovery is later than the time required for completion of failure. The software design / operation integrated management system according to claim 3. When the estimate information management unit uses the number of screens, the number of forms, the number of functions, and the number of external file items as design parameters,
FP = k + a ₁ x [number of screens] + a ₂ x [number of forms] + a ₃ x [number of functions] + a ₄ x [number of external file items] + ...
The various constants of k ₁ , a ₁ , a ₂ are calculated by regression analysis from the past FP value and the actual value of the design parameter in the FP calculation formula defined in (1). Software design and operation integrated management system described in 1.   The estimate information management unit calculates a predicted FP value by inputting predicted values of the number of screens, forms, functions, and external file items of a newly developed project into the FP calculation formula obtained for the various constants. The software design / operation integrated management system according to claim 5, wherein:   The estimated information management unit adds the actual number of screens, forms, functions, and external file items after the release to the FP calculation formula before determining the various constants after the release of the newly developed case. The software design / operation integrated management system according to claim 6, wherein feedback is applied to the FP calculation formula by obtaining various constants again by inputting.   8. The estimate information management unit includes an actual value of a skill value of a developer in charge, and estimates a work period of a new case from the calculated FP estimate value and the skill value. Software design and operation integrated management system described in 1.

Images