- Email: [email protected]
Automated Software Project Planning and Control
Copyright © IFAC Experience with the Management of Software Projects , Sarajevo, Yugoslavia , 1988
METHODS AND TOOLS
AUTOMATED SOFTWARE PROJECT PLANNING AND CONTROL R. Melli Softwar!' ElIgilleNillg Sen.'ice, .\'l'lIbiberg, ,Hullich , FRG
Abstract. This paper describes an automated software project planning and control system developed in Budapest, Hungary and now in operation in three large West German corporations. The system consists of five major components, one for each basic project management task: - system requirements analysis and documentation, - project cost and time estimation, - project activity and result planning, - project monitoring and control, - system configuration management and quality control. It operates on IBM and Siemens mainframe computers under the operating systems MVS, VM and BS2000. The methodological basis of the system is the entity/relationship model of Chen. In the first phase, the functional applications, information areas, participating organizations and requirements on these entities are defined using entity/attribute formats. The functional applications and information areas are defined both in terms of their estimated quantities - number of instructions and data elements, number of components, and number of function points and in terms of their desired quality characteristics reliability ergonomy, efficiency, maintainability, etc. Projects are then defined to fulfill the requirements placed on the applications and data areas as prescribed by IBM in its Business Systems Planning Approach. In the second phase, the project effort and calendar time as well as the predicted maintenance effort are automatically calculated using three different estimation techniques - COCOMO, Function Point, and Component Analysis. In the third phase, a product breakdown tree is designed to obtain the elementary results. Corresponding to this result tree, an activity tree is generated which includes an activity for each desired result - module, data capsule, document, test procedure, etc. It is then transformed into a network for computing the activity dependencies and the critica l path using the MPM method. In the fourth phase, the project progress is monitored in terms of quantity of results produced, quality of results obtained, time spent and cost accrued. Deviations from the plan are automatically reported and the differences documented. In the fifth and final phase, all of the software components produced are registed in a product status database together with their quality assessment on a scale of 0:1 ratio of achieved quality to desired quality. Components are also given a version numbe r, a completion date and a configuration status. Incoming error reports and change requests are accumu lated and their relationships to the software components established. These a re then a gg re ga ted and transformed into requirements so as to close the cycle and initiate a new project. 1.
Problems of Software Engineering Management
There are few software engineering environments which deal with the aspects of software project management and even less which cover all of those aspects. Often, management issues are not considered within the domain of software engineering. Yet, of the problems which plague software engineers most in developing complex software systems, the majority are of a managerial nature. (1) These problems have been sited many times in the literature. First and formost, is the problem of developing software based on an inadequate requirement definition. Barry Boehm has singled this out as the most significant problem in software engineering. If there is no solid baseline, there can be no solid development, no matter what tools and methods are used. Implementation techniques cannot make up for the lack of well defined objectives. (2) Secondly, there is the problem of unrealistic deadlines coupled with insufficient capacity. This
is also referred to as backwards planning. First a deadline is set, next the resources are allocated, and then it i s decided what is to be done. On the one hand, the time available to complete a project has no relation to the task to be accomplished. On the other hand, the resources required to complete the task cost far more than what the user is willing to pay. There is often no correlation between the work to be done, the time to do it, and the capacity required. This situation has nothing to do with the tools and methods of software development. For no matter how high the productivity of the software people is, it can always be overestimated. Insufficient time and capacity to do a job right is the result of inadequate planning, leading to time and cost overruns of 300 % and more. (3) Another problem is that of quality. If a project is finished on schedule it is often done at the cost of product quality. This again leads to excessive maintenance costs far exceeding the original development costs. In order to prevent this the software quality must be assured. (4)
2
R. Melli
Finally, there is the problem of control. Nanagers are unable to control software projects because of a lack of timely and accurate information on the project status. They often are informed of failure to meet deadlines long after the slippage has occurred. Their vision of the product status is at most hazy. Therefore, they have no exact information upon which to base their decisions. The true status of the software development is known only to the developers themselves who exploit this knowledge to their own benefit. The hapless manager is at their mercy. (5) For these and other reasons the SOFTMAN system was developed. Its objective is to support the entire project management life cycle from requirements analysis to configuration management. To do this, it offers the manager an online, menu driven interface through which he can invoke five different major functions: -
requirements analysis, cost estimation, project planning, project monitoring, configuration management.
Ihthin each of these functions data may be submitted via preformatted SPF type panels, reports may be generated, and checks of internal completeness and consistency of the project management database may be initiated. 2.
Software Requirements Analysis
According to the SOFTMAN model of software project management, a project is viewed as a one time effort bounded by time and costs to fulfill a particular set of functional objectives under a given set of constraints. (6) In effect, all of the parameters stated in this definition are requirements. Thus, the domain of a software project is bounded by its requirements which are of four types: -
time requirements, cost requirements, quantity requirements, and quality requirements. (7)
The first step in the project management process is, therefore, the analysis and definition of the above named requirements. Defining time and costs has always been a relatively easy task. There are only a few rules of experience which must be observed: For instance on the time scale no software project should last more than 2 years, since after 2 years the users requirements will have changed and the technological basis as well. (8) On the cost scale it is known that groups of more than 7 persons are difficult to manage and that productivity decreases sharply as inter project commmunication increases. (9) In view of the fact that productivity decreases in exponential proportion to the number of project members above 7, it is unwise to have any projects with more than la persons. This limits the total effort of individual software projects to no more than 20 man-years. The upper bounds of two years calendar time and 20 man-years of effort do not give software system builders much leeway. The question arises as to how large software systems such as operating systems, command and control systems, and management information systems requ1r1ng several hundred man-years of effort could ever be built.
In the past, such systems have always been too large to handle, have surpassed their deadline by months or even years, and have always cost much more than originally allocated. The only way to plan and control such large systems is to break them down into a series of subprojects which can run either concurrently or sequentially. (la) Project concurrency implies having several project groups working on subsystems adjacent to one another with one or more project groups coordinating them. Project sequence means one project group incrementally delivering subsystems, i.e. incremental software delivery. (11) These two forms can, of course, be combined so that there are two or more project groups concurrently delivering incremental subsystems. The crux of the matter is that large systems have to be decomposed into hierarchies of subsystems each of which can be implemented within two years time by no more than la persons. This is in itself a requirement on the requirements analyst. Software projects must be made manageable before project management can be made effective. Defining quantity and quality is a matter of the methodology used to model the application. In the case of SOF1}~N there is an enterprise schema based on the entity/relationship model of Chen. In the enterprise schema each application, each data area, and each resource is defined as a separate entity with attributes and relationships to other entities. (12) The approach taken to define the enterprise schema is to first create a tree of the applications with superordinate and subordinate applications. A production planning and control system may be subdivided into order entity, production planning, resource allocation, production control, quality assurance, and product disposition subapplications. Parallel to this decomposition of the business applications, another tree is devised which decomposes the information areas into subareas. For instance, the production data is divided up into product, customer and resource databases as well as into subsystem interfaces and user interfaces. The data bases contain the reusable data, the subsystem interface areas contain the data passed from one subsystem to another via networking, and the user interface areas encompass the masks and lists used to communicate with the system users. A third tree contains as nodes the resources available to the applications computers, software systems and human resources. These are also decomposed to an elementary level. Each of the applications, data areas, and resources identified in the decomposition hierarchies are inserted automatically into a management dictionary. There it is up to the business planer to define such descriptive attributes as costs, benefits, date of operation, type, etc. as well as their compositive attributes or component parts. (13) Applications and information areas have two distinct sets of compositive attributes. These are - quantitative, and - qualitative. Quantitative attributes are the data objects or entities of the information areas and the processes or logical transactions of the applications. An object may be a file, database table, view, or data communication containing a
Automated Software Project Planning and Control set of n elementary data items. A transaction may be a batch program, an online module or a real time processing action encompassing a set of m elementary functions or action steps. The sum of the objects and their associated data items determines the scope of an information area. The sum of the logical transactions and their associated functions determines the size of an application. The total quantity of an application is the sum of its logical transactions plus the data objects processed by those transactions. (14) Qualitative attributes are the characteristics of a system such as the - reliability, - ergonomy, - efficiency, - portability, - maintainability, - testability, - extendability of the application and the - security, - efficiency, - independence, - flexibility, - maintainability, - extendability of the information areas. (15)
desired
Each of these quality attributes can be assigned a desired numeric measure on a scale from 0 to whereby zero implies the total absence of that quality and one the total presence of that quality. The quality attributes can also be weighted in accordance with their relative importance. A quality multiplication factor is derived from the desired quality grade and its relative weight. In accordance with Iloehm's COCOHO model this factor can vary from 0.5 to 1.5 with 1 as an average quality. (16) The total quality of a software system is the product of the quality characteristics of both the application covered by that system and the information areas used by that application. In the SOFTMAN system the definition of quantity is supported by normalized tables of logical processes and the definition of quality by normalized tables of quality characteristics both of which must be filled out in CRT panels by the system planer. The definition of time and cost constraints is coupled with the definition of the individual requirements. There is also a CRT form for the definition of each available resource hardware, software or personnel with its attributes such as cost, availability and productivity. The final step in the requirements analysis phase is the definition of the relationships between the applications, information areas, resources, and requirements. Requirements can be placed upon applications of information areas. Applications process information areas and utilize resources. Information areas utilize resources for their storage and access. Finally, a project is defined to cover a set of one or more requirements. For the definition of these relationships, SOFTMAN provides n-ary relation tables for each base entity in which each relationship to a target entity can be defined in terms of its type, its cardinality, and its conditionality. The results of the requirements analysis with SOFTMAN are the - hierarchies of applications, information areas, resources, requirements, and projects,
3
- definitions of applications and information areas including their quantity and quality tables, - definitions of resources with their costs and utility, - definitions of requirements with their time and cost constraints, definitions of projects with their start and termination deadlines, - tables of normalized relationships among the planning entities. These results provide the basis for both the definition and calculation as well as the planning of projects aimed at fulfilling one or more of the given requirements. 3.
Project Cost Estimation
There is a large body of literature on the subject of software cost estimation and an equally large number of approaches to the problem. Among the most common approaches are Putnams SLIM Hodel (17) Boehm's COCOI-IO Model (18) Albrecht's Function Point Model (19), and \,101 verton 's Component Analysis Model. (20) Each of the above named models is based on a different measure of software quantity. SLIM is based on the total number of executable statements. COCOHO is based on Kilo deliverable lines of code. Function Point is based on the number of program inputs and outputs. Component Analysis is based on the total number of documents. Besides having a differ e nt quantitative base the various cost estimation methods also have different ways of "eighting quality and of treating factors of influence. Quality can be an added value, a multiplication factor, or an exponent. Factors of influence can have a mlnlmum effect as with the function point method where they add up to a total of 70 additional points or a profound effect as in the COCOMO method where they are multiplied together to give a product of up to factor 4 times the basic estimation. In view of these significant differences among the most common cost estimation models, it is highly unreliable to calculate projects with any single method. Instead, it is imperative to estimate with at least three different approaches and to have them converge. In this way, if one method is out of the range of the other two it can be discarded and the remaining two converged. If all three methods provide similar results, the estimation has a high degree of reliability. And, if the three results are highly scattered, it is an indication that the estimation is unreliable. (21) This diverse method approach to software cost estimation is the only way to reliably estimate. To this end, the SOrnlAN methods: COCOMO, - Function Point, and - Component Analysis.
system
supports
three
For each method there is a unique productivity table - for COCOMO in lines of code per man-month, - for Function Point in functions per man-month, - for Component Analysis in documents per manmonth, and a table with the factors of influence. In addition, there is a
different
algorithm
for
4
R. Melli
computing quality for each of the three methods and, of course, a different algorithm for deriving the estimated effort in man-months from the three parameters - quantity, quality, and - factors of influence. In the case of COCOMO, quantity is computed from the sum of the estimated lines of code for all objects and logical transactions. In the case of Function Point, quantity is computed from the number of data and communication objects and from the relationships of these objects to the logical transactions. In the case of Component Analysis, quantity is computed from the prescribed number of documents necessary for each object and logical transaction. man-months is Once the estimated effort in obtained, the calendar time necessary for the Boehm's project is computed from that using formula T = 2.5 (Effort in MM) 0.38 (22) The estimations are performed by SOFTMAN interactively with the user and presented on a CRT panel. In this way, the user can easily go back and correct either the application size, the desired quality characteristics, or the factors of influence. The estimations are then repeated until a convergence is obtained. The final estimated result in man-months is automatically converted to costs using a costing table and compared with the total acceptable costs given by the end user in his requirements. If the project is fulfilling n requirements, the costs of all requirements must be added together. The final estimated calendar time is also automatically compared to the maximum time allowable for the requirement which must be finished first, i.e. the minimum project duration. If either the estimated costs exceed the total costs budgeted or the estimated time exceeds the minimum time allowable, the planned project must be reduced. This means, either reducing the quantity in terms of objects and/or logical transactions, or reducing the quality in terms of quality characteristics. Another alternative would be to increase the project budget and extend the time frame. It is, however, much better to do this before the project begins, rather than after. In any case, the automatic feedback from the cost and time estimation to the cost and time constraints attached to the requirements obliges the project planner to correlate the estimation with the constraints before proceeding with the project planning. 4.
Project Planning
Project planning with SOFTMAN is based on the 11PM method in which the activities denote the nodes of the project network. (23) This method has been found to be somewhat more flexible and easier to update than the CPM method in which the transitions from one activity to another build the nodes of the network. Another approach is the PERT method which uses the results of the activities as nodes in the network. In so far, as there is only one result for each activity the MPM and PERT methods are equivalent. The PERT method emphasizes the relationship between results, the MPN method the relationship between activities. (24) In accordance with the planning methodology, SOFTMAN imposes two hierarchies on the project planner. The one hierarchy is the activity tree corresponding to Boehm's work breakdown chart.
The other hierarchy is the result tree corresponding to the product configuration plan. (25) Each tree contains set nodes and elementary nodes. A set node contains two or more subordinate nodes which may either be sets or elementary nodes. An elementary node is either an indivisable activity which can be assigned to one resource or a basic component of the software product which can be separately tested and maintained. Examples of basic components are: - specification of a mask or list, specification of a data object, - specification of a logical transaction, - design of a file, - design of a program, - design of a module, - module code, - file description, - test procedure, JCL procedure. For each such basic component there must be a corresponding basic activity which produces it. Thus, the user is animated to first create a product tree of all the soft,;are components grouped by partial product in accordance with the IEEE standards for software engineering. - requirement specification, - system design, database design, - programs, - unit test procedures, system test procedures. (26) Once the product tree, i.e. software configuration, plan is complete and confirmed, the activity tree is generated automatically. In addition, both components and activities are automatically inserted into respective component and activity dictionaries where each component and activity must be described in terms of their attributes. Components have attributes such as: - type, - desired completion date, - costs, - desired quality, - version.
Activities have such attributes as: - type, - starting date, - completion date, - predicted effort, - duration. Once the components and activities have been defined, it is then possible to define the relationships between them. There are three types of relationships for the activities depending on the target entity: - activity to component result, - activity to resource, - activity to activity. The activity to component result relationship describes the inputs and outputs of each activity. Each activity produces one result but it may need the results of several other activities in order to produce that result. The activity to resource relationship describes what hardware, software and human resources are needed by each activity to produce its result. The activity to activity relationship describes the precedence among activities, that is what other activies must be completed before an activity can be triggered. From these relationships an activity network is generated and documented in accordance with the MPH method displaying the order of the activities on a time axis. From this activity network a critical path
Automated Software Project Planning and Control is taken based on the duration of the individual tasks. This gives the project planner the minimum calendar time which is then compared to the estimated calendar time. Another measure is the sum of all the effort involved in the individual activities. If this accumulated effort happens to be more than the estimated effort, it will be necessary to either revise the original estimation or to reduce the number of activities. Reducing the number of activities means reducing the number of component results. This, in term, means reducing the quantity or quality of the planned software product. Dropping a module or a file is definitely a loss of functionality, i.e. quantity. Dropping a test procedure or a formal specification document may not result in a reduction in function, but it will most certainly result in a reduction of quality. If either the planned time as derived from the critical path analysis exceeds the estimated time or the planned effort as derived from the accumulation of all individual activity effort exceeds the estimated effort, the original requirements will have to be adjusted and the project costs recalculated. It may also turn out that the necessary resources will not be available when they are required. This will cause an adjustment to the project plan which again will cause an adjustment to the requirements. I'i thout the support of an automated system like SO~lAN these complex dependencies among requirements, estimations and plans are impossible to trace let alone to manage. lVith SOFTMAN they are automatically traced, documented and checked for consistency. The resulting project hierarchies, networks, dependency graphs, dictionaries, and consistency/completeness reports provide the project manager with the information he needs to make the necessary planning decisions. 5.
Project Honitoring & Control
Once a project has been launched the main task of management is to retain control of it. The project must progress toward the objectives set by the requirements definition within the constraints of quality, time, and costs. If the effort planned is insufficient, it will have to be supplemented. If the time planned is not enough, the deadlines will have to be postponed. If the quality desired is unattainable, it may be necessary to reduce the quantity or increase the effort. Important is that deviations from the plan are immediately reported so that management will have an opportunity to react. This presupposes strict project monitoring of effort, time, quality, and quantity. For the monitoring of effort SO~~N provides tables for each project resource and project participant to record the effort expended. Computer and software usage is recorded in system time, human effort is registered in man-hours. For each project resource whether software, hardware, or human there is both a projected plan calendar as well as an actual effort calendar. If it is up to each project member to record his hours worked by day and by task using his actual calendar displayed as a CRT form. The effort recorded is then checked against the planned calendar and the discrepancies reported. In addition, the effort is aggregated by task and checked against the work breakdown plan, i.e. the task data is updated automatically from the effort tables. This allows a current network plan to be produced and a new actual path to be computed.
5
For the monitoring of time SOFTMAN uses the deadlines taken from the original task plan. Since each task is assigned to produce one and only one software component, it is only necessary to check whether the component is finished to determine if the task is complete. Each time a component passes its verification test, the task assigned to it is automatically closed with the date of the component verification. Periodically a search is made of all tasks closed out and the closure dates are then compared to the planned deadlines and the exceptions reported. Concurrently, the actual network plan is updated to reflect the slippages. For the monitoring of quantity and quality SOFTMAN is integrated with a series of operational tools for all phases of the software life cycle. At the end of each phase, all of the elements within the partial product are checked for existence, completeness, consistency, correctness, and coherence with the standards. The completed elements are then reported together with their quality grade. The quality grade on a scale of 0 to 1, the status, the date, the version, and other attributes are passed to the management system via a component status file. By searching through the component status file, SOF1}IAN is able to determine which results are finished and to what degree of quality. The status of a result is either - planned, - in work, - complete, or verified. Verified results must all have a quality grade higher than the minimum set for that characteristic in the requirements definition. By comparing the results verified against the product tree, SOFTMAN can measure completeness. By transposing the product tree onto the project tree, SOFTMAN can ascertain which tasks are completed and generate a project completion rate chart for the manager displaying both the planned and the actual completion rate curves. (27) Thus, both quantity in terms of ratio of completed components to planned components and quality in terms of the weighted ratio of actual quality to planned quality are monitored. With the information provided, the project manager is able to determine the status of the project at any time and to initiate the appropriate corrective action. He is no longer at the mercy of the developers for his information. 6.
Software Configuration Nanagement
Once a software system has been developed, tested, and delivered, it enters into a maintenance status in which it has to be administered. This is referred to as configuration management. Not only is management responsible for keeping track of the existing software components. It must also register the incoming error reports and change requests, initiate corrections, alterations, and enhancements and assure that they are carried out properly. Configuration management in connection with software maintenance has become an established subdiscipline of software engineering. (28) To support this activity provides four functions: -
a a a a
the
system
user reporting function, system status reporting function, change tracking function, and quality assurance feedback function.
SOFTMAN
6 User reporting entails the collection of error reports and change requests from the system users. These reports are CRT panels containing preformatted forms identifying the product, the component, the error, the environment, the reporter, and other pertinent attributes pertaining to the error or change. These incoming reports are checked for formal correctness and their contents stored in a user request file. From here they are displayed to the configuration manager for the assignment of priorities and the input of additional information. Then, upon demand by the configuration manager they are transferred to the requirement file where they initiate new mini projects. It is here that the software cycle is closed and repeated. System status reporting is directed toward informing the configuration manager of the current status of all software components of a particular system. These components may be requirements documents, specification documents, design documents, modules, da ta capsules, command procedures, test procedures, test data files, user documents, or any other stored information belonging to the software product. The IEEE standards provide a useful basi s for identifying the component parts of a software system. In SOF1}~N it is up to the use r to maintain a tr ee of components which he desires to account for. The status reporting subsystem is connected to the operational software engineering systems via a status file. For each component identified by the configuration manager a r ecord is maintained containing the status a nd quality of that component as well as the author and the date of completion. Through the reporting system, the manager can have reports printed using alternative selection criteria such as the date , the author, the status, or the component type. Change tracking also involves the use of the status file. Each time a component is altered by a developer, the date and time of the alteration is stored in the appropriate record in the status file. The status of that component is also automatically placed in an under change state. Hhen a status report is produced, all of the components under cha nge and all elements affected by that change are marked as change candidates. They remain marked until they have been changed and verified. A change or error correction is not complete until all of the components changed have been verified and validated. Hith the change reporting the configuration manager is able to track changes through the system from initialization to specification, to design, to implementation, to testing, to integration, and to acceptance. Quality assurance feedback keeps the manager informed of the quality of the individual components as well as the quality of the partial products and the product as a whole. The grades of all components of a partial product, e.g. system specification, are summed and averaged to give a quality grade for that partial product. The grades of the partial products are aggregated and averaged to give the quality grade of the product as a whole. Besides this overall quality grade, there are also grades for the individual quality characteristics. For each characteristic identified in the software requirements analysis a separate grade is computed. Thus, there is a grade for reliability based upon test coverage and found error rate. The grade for maintainability is taken from the
R. Melli complexity and modularity metrics. The grade for integrity is derived from the percentage of input data checked. These actual grades are compared automatically with the planned quality level and the differences reported g~v~ng the manager a quantitative assessment of the quality attained as compared to the quality desired. (29)
7.
Summary
In this paper the problems of software engineering management have been outlined and the contribution of the SOF1}~N system to the solution of these problems described. The problems mentioned are those of inadequate requirements definition, unrealistic deadlines, inadequate quality, and the lack of control over software development. The combination of these factors leads inevitably to cost and time over runs and to quality and quantity short of that required. SOF1}~N,
as an automated project management system, attempts to solve the above named problems by structuring the requirements definition on the basis of an entity/relationship enterprise model, by automated support of three different cost estimation techniques , by applying proven planning methods to computer supported project planning, by collecting information directly from the developer and the products developed on the status of the project, and finally, by automatically tracing the status of the software product itself and deriving statical data to assess the quality of the product. In the hand s of trained software engineering manager s , SOFTMAN has proven to be a powerful tool in definin g , calculating, planning, and controlling complex software projects. In the hands of untrained ma nagers, unfamiliar with modern software engineering technology, SOFTMAN cann still serve as a pedagogic tool to help in training these managers. Experience in German industry has demon s trated tha t such an automated system is an indispensable part of any large software production environment. (30) REFERENCES (1) Thayer,R. / Pyster , A.: " The challenge of Software Engineering Projec t Managemen t" IEEE Comput er, Aug . 1980 ( 2 ) Boehm, B.: "Software Engineering" IEEE Trans. on Computers , Dec . 1976 (3) Wo l verton, R.: "The Cost of Developing LargeScale So f tware " I EEE Trans . on Computers , June 1974 (4) Abde l - Hami d , T. / Madni c k , S .: " Impac t of Sche du le Est imation on Software Proj e ct Behavi o r" IEEE Software , July 1986 ( 5) Brooks, F.: " The Mythical Man- Mont h" Datamation, Dec . 1974 ( 6 ) Ca ve , W. / Salysbury , A. : "Controlli ng the Software Li fe Cycle - The Project Management Task" IEEE Trans . SE-4, Nr. 4, July 1978 (7 ) Sneed, H.: Re qui rements Analysis of Business Systems", Proc.Int . Comp. SympOSium, AGM German Chapter, NUmbe rg, 1983 (8) Jeffeny, D.R.: "Time - Sens i ti ve Cost Models in t he Corrmerci al MIS Envi ronmen t" , IEEE Trans. SE-13 , Nr. 7, July 1987 ( 9 ) Howes, N.: Managi ng Sof tware Devel opment Proj e cts f o r Maximum Productivity", IEEE Trans. SE-10 , Nr. I, Jan. 1984 (lO)Shatz, S. / Wang, J .-P.: " Introduc ti on to Distri buted Sof tware Enginee ring" IEEE Computer, Oc t. 1987 ( ll )Basili, V. / Tume r,A. : "Iterati ve Enhancement A prac tical Technique f o r Sof tware Engineering" IEEE Trans., Dec . 1975
Auto mated Softwa re Pro ject Plannin g and Con trol ( 12) Chen , P.: "Entity- Relationship Model - Toward a uni fied View of Data" , ACM Trans. on DB Systems , Vol . 1 , Nr. 1 , March 1976 (13) Zachman , G. : "Business Systems Planning and Bu s i ness I nformation Control Study", IBM SysTems J ournal, Vol . 21 , Nr . 1 , 1982 (14 ) Sil verrnann, B.: "Software Cost and Produc t i vi ty Improvements - An Analogical Vi ew" , I EEE Computer, May , 1985 (15) Boehm,B . /Brown , J . : "Characteristics of Software Quality" Nor th- Holland , Amsterdam , - 1978 (16) Boehm, B. : " Software Engineering Economics" , I EEE Trans. SE- 10 , Nr . 1 , Jan . 1984 (17) Putnam , L. : "A General Empirical SolutIon to t he Macro Software Sizing and Estimating Problem" , IEEE Trans . SE- 4 , Nr . 7 , July 1978 (18) Boehm , B.: Software Engineering EconomiCS , Prentice Hall, Englewood CliffS , 1983 (19) Albrecht, A. : "Software Function , Source Lines of Code , and Development Effort Prediction" , I EEE Trans . SE- 9, Nr . 6 , 1983 (20) Wolverton , R. : " Software Cost Analysis and Estimati ng ", U. S. Ai r Force, Wri ght- Patterson Air Base , Feb. 1980 (21) Ferrentino, A. : "Making Software Development EstImates Good " DATAMATION , Sept. 1981 (22) Boehm, B. : "Software Engineering Economics", IEEE Trans . SE- 10 , Nr . 1 , Jan . 1984 (23) Done 1 son , W. : " Project Planning and Control " , DATAMATION , June 1976 (24) Reuter , V.: "Using Graphic Management Tools" , Journal of Systems Mgt . , April 1979 (25) Tausworthe, R. : "Work Breakdown Structure in Software Project Mgt ." , Journal of Sys . and Software, Nr . 1, 1980 (26) Branstad , M. /Powell, P . : " Software Engineering Project Standards" IEEE Trans . SE-lO , Nr . 1, Jan . 1984 (27) Snyder , T . : " Rate Charting" , DATAMATION, Nov . 1976 (28) Bersoff/Henderson/Siegel: Software Configurati on Management, Prentice Hall, Englewood Cliffs , 1980 (29) Sneed , H.: Softwre-Qualitatssicherung" , Rudol f MUller Verlag , Koln , 1988 (30) Sneed , H.: Software- Management, Rudolf MUller Verlag, Koln , 1987
METHODS AND TOOLS
AUTOMATED SOFTWARE PROJECT PLANNING AND CONTROL R. Melli Softwar!' ElIgilleNillg Sen.'ice, .\'l'lIbiberg, ,Hullich , FRG
Abstract. This paper describes an automated software project planning and control system developed in Budapest, Hungary and now in operation in three large West German corporations. The system consists of five major components, one for each basic project management task: - system requirements analysis and documentation, - project cost and time estimation, - project activity and result planning, - project monitoring and control, - system configuration management and quality control. It operates on IBM and Siemens mainframe computers under the operating systems MVS, VM and BS2000. The methodological basis of the system is the entity/relationship model of Chen. In the first phase, the functional applications, information areas, participating organizations and requirements on these entities are defined using entity/attribute formats. The functional applications and information areas are defined both in terms of their estimated quantities - number of instructions and data elements, number of components, and number of function points and in terms of their desired quality characteristics reliability ergonomy, efficiency, maintainability, etc. Projects are then defined to fulfill the requirements placed on the applications and data areas as prescribed by IBM in its Business Systems Planning Approach. In the second phase, the project effort and calendar time as well as the predicted maintenance effort are automatically calculated using three different estimation techniques - COCOMO, Function Point, and Component Analysis. In the third phase, a product breakdown tree is designed to obtain the elementary results. Corresponding to this result tree, an activity tree is generated which includes an activity for each desired result - module, data capsule, document, test procedure, etc. It is then transformed into a network for computing the activity dependencies and the critica l path using the MPM method. In the fourth phase, the project progress is monitored in terms of quantity of results produced, quality of results obtained, time spent and cost accrued. Deviations from the plan are automatically reported and the differences documented. In the fifth and final phase, all of the software components produced are registed in a product status database together with their quality assessment on a scale of 0:1 ratio of achieved quality to desired quality. Components are also given a version numbe r, a completion date and a configuration status. Incoming error reports and change requests are accumu lated and their relationships to the software components established. These a re then a gg re ga ted and transformed into requirements so as to close the cycle and initiate a new project. 1.
Problems of Software Engineering Management
There are few software engineering environments which deal with the aspects of software project management and even less which cover all of those aspects. Often, management issues are not considered within the domain of software engineering. Yet, of the problems which plague software engineers most in developing complex software systems, the majority are of a managerial nature. (1) These problems have been sited many times in the literature. First and formost, is the problem of developing software based on an inadequate requirement definition. Barry Boehm has singled this out as the most significant problem in software engineering. If there is no solid baseline, there can be no solid development, no matter what tools and methods are used. Implementation techniques cannot make up for the lack of well defined objectives. (2) Secondly, there is the problem of unrealistic deadlines coupled with insufficient capacity. This
is also referred to as backwards planning. First a deadline is set, next the resources are allocated, and then it i s decided what is to be done. On the one hand, the time available to complete a project has no relation to the task to be accomplished. On the other hand, the resources required to complete the task cost far more than what the user is willing to pay. There is often no correlation between the work to be done, the time to do it, and the capacity required. This situation has nothing to do with the tools and methods of software development. For no matter how high the productivity of the software people is, it can always be overestimated. Insufficient time and capacity to do a job right is the result of inadequate planning, leading to time and cost overruns of 300 % and more. (3) Another problem is that of quality. If a project is finished on schedule it is often done at the cost of product quality. This again leads to excessive maintenance costs far exceeding the original development costs. In order to prevent this the software quality must be assured. (4)
2
R. Melli
Finally, there is the problem of control. Nanagers are unable to control software projects because of a lack of timely and accurate information on the project status. They often are informed of failure to meet deadlines long after the slippage has occurred. Their vision of the product status is at most hazy. Therefore, they have no exact information upon which to base their decisions. The true status of the software development is known only to the developers themselves who exploit this knowledge to their own benefit. The hapless manager is at their mercy. (5) For these and other reasons the SOFTMAN system was developed. Its objective is to support the entire project management life cycle from requirements analysis to configuration management. To do this, it offers the manager an online, menu driven interface through which he can invoke five different major functions: -
requirements analysis, cost estimation, project planning, project monitoring, configuration management.
Ihthin each of these functions data may be submitted via preformatted SPF type panels, reports may be generated, and checks of internal completeness and consistency of the project management database may be initiated. 2.
Software Requirements Analysis
According to the SOFTMAN model of software project management, a project is viewed as a one time effort bounded by time and costs to fulfill a particular set of functional objectives under a given set of constraints. (6) In effect, all of the parameters stated in this definition are requirements. Thus, the domain of a software project is bounded by its requirements which are of four types: -
time requirements, cost requirements, quantity requirements, and quality requirements. (7)
The first step in the project management process is, therefore, the analysis and definition of the above named requirements. Defining time and costs has always been a relatively easy task. There are only a few rules of experience which must be observed: For instance on the time scale no software project should last more than 2 years, since after 2 years the users requirements will have changed and the technological basis as well. (8) On the cost scale it is known that groups of more than 7 persons are difficult to manage and that productivity decreases sharply as inter project commmunication increases. (9) In view of the fact that productivity decreases in exponential proportion to the number of project members above 7, it is unwise to have any projects with more than la persons. This limits the total effort of individual software projects to no more than 20 man-years. The upper bounds of two years calendar time and 20 man-years of effort do not give software system builders much leeway. The question arises as to how large software systems such as operating systems, command and control systems, and management information systems requ1r1ng several hundred man-years of effort could ever be built.
In the past, such systems have always been too large to handle, have surpassed their deadline by months or even years, and have always cost much more than originally allocated. The only way to plan and control such large systems is to break them down into a series of subprojects which can run either concurrently or sequentially. (la) Project concurrency implies having several project groups working on subsystems adjacent to one another with one or more project groups coordinating them. Project sequence means one project group incrementally delivering subsystems, i.e. incremental software delivery. (11) These two forms can, of course, be combined so that there are two or more project groups concurrently delivering incremental subsystems. The crux of the matter is that large systems have to be decomposed into hierarchies of subsystems each of which can be implemented within two years time by no more than la persons. This is in itself a requirement on the requirements analyst. Software projects must be made manageable before project management can be made effective. Defining quantity and quality is a matter of the methodology used to model the application. In the case of SOF1}~N there is an enterprise schema based on the entity/relationship model of Chen. In the enterprise schema each application, each data area, and each resource is defined as a separate entity with attributes and relationships to other entities. (12) The approach taken to define the enterprise schema is to first create a tree of the applications with superordinate and subordinate applications. A production planning and control system may be subdivided into order entity, production planning, resource allocation, production control, quality assurance, and product disposition subapplications. Parallel to this decomposition of the business applications, another tree is devised which decomposes the information areas into subareas. For instance, the production data is divided up into product, customer and resource databases as well as into subsystem interfaces and user interfaces. The data bases contain the reusable data, the subsystem interface areas contain the data passed from one subsystem to another via networking, and the user interface areas encompass the masks and lists used to communicate with the system users. A third tree contains as nodes the resources available to the applications computers, software systems and human resources. These are also decomposed to an elementary level. Each of the applications, data areas, and resources identified in the decomposition hierarchies are inserted automatically into a management dictionary. There it is up to the business planer to define such descriptive attributes as costs, benefits, date of operation, type, etc. as well as their compositive attributes or component parts. (13) Applications and information areas have two distinct sets of compositive attributes. These are - quantitative, and - qualitative. Quantitative attributes are the data objects or entities of the information areas and the processes or logical transactions of the applications. An object may be a file, database table, view, or data communication containing a
Automated Software Project Planning and Control set of n elementary data items. A transaction may be a batch program, an online module or a real time processing action encompassing a set of m elementary functions or action steps. The sum of the objects and their associated data items determines the scope of an information area. The sum of the logical transactions and their associated functions determines the size of an application. The total quantity of an application is the sum of its logical transactions plus the data objects processed by those transactions. (14) Qualitative attributes are the characteristics of a system such as the - reliability, - ergonomy, - efficiency, - portability, - maintainability, - testability, - extendability of the application and the - security, - efficiency, - independence, - flexibility, - maintainability, - extendability of the information areas. (15)
desired
Each of these quality attributes can be assigned a desired numeric measure on a scale from 0 to whereby zero implies the total absence of that quality and one the total presence of that quality. The quality attributes can also be weighted in accordance with their relative importance. A quality multiplication factor is derived from the desired quality grade and its relative weight. In accordance with Iloehm's COCOHO model this factor can vary from 0.5 to 1.5 with 1 as an average quality. (16) The total quality of a software system is the product of the quality characteristics of both the application covered by that system and the information areas used by that application. In the SOFTMAN system the definition of quantity is supported by normalized tables of logical processes and the definition of quality by normalized tables of quality characteristics both of which must be filled out in CRT panels by the system planer. The definition of time and cost constraints is coupled with the definition of the individual requirements. There is also a CRT form for the definition of each available resource hardware, software or personnel with its attributes such as cost, availability and productivity. The final step in the requirements analysis phase is the definition of the relationships between the applications, information areas, resources, and requirements. Requirements can be placed upon applications of information areas. Applications process information areas and utilize resources. Information areas utilize resources for their storage and access. Finally, a project is defined to cover a set of one or more requirements. For the definition of these relationships, SOFTMAN provides n-ary relation tables for each base entity in which each relationship to a target entity can be defined in terms of its type, its cardinality, and its conditionality. The results of the requirements analysis with SOFTMAN are the - hierarchies of applications, information areas, resources, requirements, and projects,
3
- definitions of applications and information areas including their quantity and quality tables, - definitions of resources with their costs and utility, - definitions of requirements with their time and cost constraints, definitions of projects with their start and termination deadlines, - tables of normalized relationships among the planning entities. These results provide the basis for both the definition and calculation as well as the planning of projects aimed at fulfilling one or more of the given requirements. 3.
Project Cost Estimation
There is a large body of literature on the subject of software cost estimation and an equally large number of approaches to the problem. Among the most common approaches are Putnams SLIM Hodel (17) Boehm's COCOI-IO Model (18) Albrecht's Function Point Model (19), and \,101 verton 's Component Analysis Model. (20) Each of the above named models is based on a different measure of software quantity. SLIM is based on the total number of executable statements. COCOHO is based on Kilo deliverable lines of code. Function Point is based on the number of program inputs and outputs. Component Analysis is based on the total number of documents. Besides having a differ e nt quantitative base the various cost estimation methods also have different ways of "eighting quality and of treating factors of influence. Quality can be an added value, a multiplication factor, or an exponent. Factors of influence can have a mlnlmum effect as with the function point method where they add up to a total of 70 additional points or a profound effect as in the COCOMO method where they are multiplied together to give a product of up to factor 4 times the basic estimation. In view of these significant differences among the most common cost estimation models, it is highly unreliable to calculate projects with any single method. Instead, it is imperative to estimate with at least three different approaches and to have them converge. In this way, if one method is out of the range of the other two it can be discarded and the remaining two converged. If all three methods provide similar results, the estimation has a high degree of reliability. And, if the three results are highly scattered, it is an indication that the estimation is unreliable. (21) This diverse method approach to software cost estimation is the only way to reliably estimate. To this end, the SOrnlAN methods: COCOMO, - Function Point, and - Component Analysis.
system
supports
three
For each method there is a unique productivity table - for COCOMO in lines of code per man-month, - for Function Point in functions per man-month, - for Component Analysis in documents per manmonth, and a table with the factors of influence. In addition, there is a
different
algorithm
for
4
R. Melli
computing quality for each of the three methods and, of course, a different algorithm for deriving the estimated effort in man-months from the three parameters - quantity, quality, and - factors of influence. In the case of COCOMO, quantity is computed from the sum of the estimated lines of code for all objects and logical transactions. In the case of Function Point, quantity is computed from the number of data and communication objects and from the relationships of these objects to the logical transactions. In the case of Component Analysis, quantity is computed from the prescribed number of documents necessary for each object and logical transaction. man-months is Once the estimated effort in obtained, the calendar time necessary for the Boehm's project is computed from that using formula T = 2.5 (Effort in MM) 0.38 (22) The estimations are performed by SOFTMAN interactively with the user and presented on a CRT panel. In this way, the user can easily go back and correct either the application size, the desired quality characteristics, or the factors of influence. The estimations are then repeated until a convergence is obtained. The final estimated result in man-months is automatically converted to costs using a costing table and compared with the total acceptable costs given by the end user in his requirements. If the project is fulfilling n requirements, the costs of all requirements must be added together. The final estimated calendar time is also automatically compared to the maximum time allowable for the requirement which must be finished first, i.e. the minimum project duration. If either the estimated costs exceed the total costs budgeted or the estimated time exceeds the minimum time allowable, the planned project must be reduced. This means, either reducing the quantity in terms of objects and/or logical transactions, or reducing the quality in terms of quality characteristics. Another alternative would be to increase the project budget and extend the time frame. It is, however, much better to do this before the project begins, rather than after. In any case, the automatic feedback from the cost and time estimation to the cost and time constraints attached to the requirements obliges the project planner to correlate the estimation with the constraints before proceeding with the project planning. 4.
Project Planning
Project planning with SOFTMAN is based on the 11PM method in which the activities denote the nodes of the project network. (23) This method has been found to be somewhat more flexible and easier to update than the CPM method in which the transitions from one activity to another build the nodes of the network. Another approach is the PERT method which uses the results of the activities as nodes in the network. In so far, as there is only one result for each activity the MPM and PERT methods are equivalent. The PERT method emphasizes the relationship between results, the MPN method the relationship between activities. (24) In accordance with the planning methodology, SOFTMAN imposes two hierarchies on the project planner. The one hierarchy is the activity tree corresponding to Boehm's work breakdown chart.
The other hierarchy is the result tree corresponding to the product configuration plan. (25) Each tree contains set nodes and elementary nodes. A set node contains two or more subordinate nodes which may either be sets or elementary nodes. An elementary node is either an indivisable activity which can be assigned to one resource or a basic component of the software product which can be separately tested and maintained. Examples of basic components are: - specification of a mask or list, specification of a data object, - specification of a logical transaction, - design of a file, - design of a program, - design of a module, - module code, - file description, - test procedure, JCL procedure. For each such basic component there must be a corresponding basic activity which produces it. Thus, the user is animated to first create a product tree of all the soft,;are components grouped by partial product in accordance with the IEEE standards for software engineering. - requirement specification, - system design, database design, - programs, - unit test procedures, system test procedures. (26) Once the product tree, i.e. software configuration, plan is complete and confirmed, the activity tree is generated automatically. In addition, both components and activities are automatically inserted into respective component and activity dictionaries where each component and activity must be described in terms of their attributes. Components have attributes such as: - type, - desired completion date, - costs, - desired quality, - version.
Activities have such attributes as: - type, - starting date, - completion date, - predicted effort, - duration. Once the components and activities have been defined, it is then possible to define the relationships between them. There are three types of relationships for the activities depending on the target entity: - activity to component result, - activity to resource, - activity to activity. The activity to component result relationship describes the inputs and outputs of each activity. Each activity produces one result but it may need the results of several other activities in order to produce that result. The activity to resource relationship describes what hardware, software and human resources are needed by each activity to produce its result. The activity to activity relationship describes the precedence among activities, that is what other activies must be completed before an activity can be triggered. From these relationships an activity network is generated and documented in accordance with the MPH method displaying the order of the activities on a time axis. From this activity network a critical path
Automated Software Project Planning and Control is taken based on the duration of the individual tasks. This gives the project planner the minimum calendar time which is then compared to the estimated calendar time. Another measure is the sum of all the effort involved in the individual activities. If this accumulated effort happens to be more than the estimated effort, it will be necessary to either revise the original estimation or to reduce the number of activities. Reducing the number of activities means reducing the number of component results. This, in term, means reducing the quantity or quality of the planned software product. Dropping a module or a file is definitely a loss of functionality, i.e. quantity. Dropping a test procedure or a formal specification document may not result in a reduction in function, but it will most certainly result in a reduction of quality. If either the planned time as derived from the critical path analysis exceeds the estimated time or the planned effort as derived from the accumulation of all individual activity effort exceeds the estimated effort, the original requirements will have to be adjusted and the project costs recalculated. It may also turn out that the necessary resources will not be available when they are required. This will cause an adjustment to the project plan which again will cause an adjustment to the requirements. I'i thout the support of an automated system like SO~lAN these complex dependencies among requirements, estimations and plans are impossible to trace let alone to manage. lVith SOFTMAN they are automatically traced, documented and checked for consistency. The resulting project hierarchies, networks, dependency graphs, dictionaries, and consistency/completeness reports provide the project manager with the information he needs to make the necessary planning decisions. 5.
Project Honitoring & Control
Once a project has been launched the main task of management is to retain control of it. The project must progress toward the objectives set by the requirements definition within the constraints of quality, time, and costs. If the effort planned is insufficient, it will have to be supplemented. If the time planned is not enough, the deadlines will have to be postponed. If the quality desired is unattainable, it may be necessary to reduce the quantity or increase the effort. Important is that deviations from the plan are immediately reported so that management will have an opportunity to react. This presupposes strict project monitoring of effort, time, quality, and quantity. For the monitoring of effort SO~~N provides tables for each project resource and project participant to record the effort expended. Computer and software usage is recorded in system time, human effort is registered in man-hours. For each project resource whether software, hardware, or human there is both a projected plan calendar as well as an actual effort calendar. If it is up to each project member to record his hours worked by day and by task using his actual calendar displayed as a CRT form. The effort recorded is then checked against the planned calendar and the discrepancies reported. In addition, the effort is aggregated by task and checked against the work breakdown plan, i.e. the task data is updated automatically from the effort tables. This allows a current network plan to be produced and a new actual path to be computed.
5
For the monitoring of time SOFTMAN uses the deadlines taken from the original task plan. Since each task is assigned to produce one and only one software component, it is only necessary to check whether the component is finished to determine if the task is complete. Each time a component passes its verification test, the task assigned to it is automatically closed with the date of the component verification. Periodically a search is made of all tasks closed out and the closure dates are then compared to the planned deadlines and the exceptions reported. Concurrently, the actual network plan is updated to reflect the slippages. For the monitoring of quantity and quality SOFTMAN is integrated with a series of operational tools for all phases of the software life cycle. At the end of each phase, all of the elements within the partial product are checked for existence, completeness, consistency, correctness, and coherence with the standards. The completed elements are then reported together with their quality grade. The quality grade on a scale of 0 to 1, the status, the date, the version, and other attributes are passed to the management system via a component status file. By searching through the component status file, SOF1}IAN is able to determine which results are finished and to what degree of quality. The status of a result is either - planned, - in work, - complete, or verified. Verified results must all have a quality grade higher than the minimum set for that characteristic in the requirements definition. By comparing the results verified against the product tree, SOFTMAN can measure completeness. By transposing the product tree onto the project tree, SOFTMAN can ascertain which tasks are completed and generate a project completion rate chart for the manager displaying both the planned and the actual completion rate curves. (27) Thus, both quantity in terms of ratio of completed components to planned components and quality in terms of the weighted ratio of actual quality to planned quality are monitored. With the information provided, the project manager is able to determine the status of the project at any time and to initiate the appropriate corrective action. He is no longer at the mercy of the developers for his information. 6.
Software Configuration Nanagement
Once a software system has been developed, tested, and delivered, it enters into a maintenance status in which it has to be administered. This is referred to as configuration management. Not only is management responsible for keeping track of the existing software components. It must also register the incoming error reports and change requests, initiate corrections, alterations, and enhancements and assure that they are carried out properly. Configuration management in connection with software maintenance has become an established subdiscipline of software engineering. (28) To support this activity provides four functions: -
a a a a
the
system
user reporting function, system status reporting function, change tracking function, and quality assurance feedback function.
SOFTMAN
6 User reporting entails the collection of error reports and change requests from the system users. These reports are CRT panels containing preformatted forms identifying the product, the component, the error, the environment, the reporter, and other pertinent attributes pertaining to the error or change. These incoming reports are checked for formal correctness and their contents stored in a user request file. From here they are displayed to the configuration manager for the assignment of priorities and the input of additional information. Then, upon demand by the configuration manager they are transferred to the requirement file where they initiate new mini projects. It is here that the software cycle is closed and repeated. System status reporting is directed toward informing the configuration manager of the current status of all software components of a particular system. These components may be requirements documents, specification documents, design documents, modules, da ta capsules, command procedures, test procedures, test data files, user documents, or any other stored information belonging to the software product. The IEEE standards provide a useful basi s for identifying the component parts of a software system. In SOF1}~N it is up to the use r to maintain a tr ee of components which he desires to account for. The status reporting subsystem is connected to the operational software engineering systems via a status file. For each component identified by the configuration manager a r ecord is maintained containing the status a nd quality of that component as well as the author and the date of completion. Through the reporting system, the manager can have reports printed using alternative selection criteria such as the date , the author, the status, or the component type. Change tracking also involves the use of the status file. Each time a component is altered by a developer, the date and time of the alteration is stored in the appropriate record in the status file. The status of that component is also automatically placed in an under change state. Hhen a status report is produced, all of the components under cha nge and all elements affected by that change are marked as change candidates. They remain marked until they have been changed and verified. A change or error correction is not complete until all of the components changed have been verified and validated. Hith the change reporting the configuration manager is able to track changes through the system from initialization to specification, to design, to implementation, to testing, to integration, and to acceptance. Quality assurance feedback keeps the manager informed of the quality of the individual components as well as the quality of the partial products and the product as a whole. The grades of all components of a partial product, e.g. system specification, are summed and averaged to give a quality grade for that partial product. The grades of the partial products are aggregated and averaged to give the quality grade of the product as a whole. Besides this overall quality grade, there are also grades for the individual quality characteristics. For each characteristic identified in the software requirements analysis a separate grade is computed. Thus, there is a grade for reliability based upon test coverage and found error rate. The grade for maintainability is taken from the
R. Melli complexity and modularity metrics. The grade for integrity is derived from the percentage of input data checked. These actual grades are compared automatically with the planned quality level and the differences reported g~v~ng the manager a quantitative assessment of the quality attained as compared to the quality desired. (29)
7.
Summary
In this paper the problems of software engineering management have been outlined and the contribution of the SOF1}~N system to the solution of these problems described. The problems mentioned are those of inadequate requirements definition, unrealistic deadlines, inadequate quality, and the lack of control over software development. The combination of these factors leads inevitably to cost and time over runs and to quality and quantity short of that required. SOF1}~N,
as an automated project management system, attempts to solve the above named problems by structuring the requirements definition on the basis of an entity/relationship enterprise model, by automated support of three different cost estimation techniques , by applying proven planning methods to computer supported project planning, by collecting information directly from the developer and the products developed on the status of the project, and finally, by automatically tracing the status of the software product itself and deriving statical data to assess the quality of the product. In the hand s of trained software engineering manager s , SOFTMAN has proven to be a powerful tool in definin g , calculating, planning, and controlling complex software projects. In the hands of untrained ma nagers, unfamiliar with modern software engineering technology, SOFTMAN cann still serve as a pedagogic tool to help in training these managers. Experience in German industry has demon s trated tha t such an automated system is an indispensable part of any large software production environment. (30) REFERENCES (1) Thayer,R. / Pyster , A.: " The challenge of Software Engineering Projec t Managemen t" IEEE Comput er, Aug . 1980 ( 2 ) Boehm, B.: "Software Engineering" IEEE Trans. on Computers , Dec . 1976 (3) Wo l verton, R.: "The Cost of Developing LargeScale So f tware " I EEE Trans . on Computers , June 1974 (4) Abde l - Hami d , T. / Madni c k , S .: " Impac t of Sche du le Est imation on Software Proj e ct Behavi o r" IEEE Software , July 1986 ( 5) Brooks, F.: " The Mythical Man- Mont h" Datamation, Dec . 1974 ( 6 ) Ca ve , W. / Salysbury , A. : "Controlli ng the Software Li fe Cycle - The Project Management Task" IEEE Trans . SE-4, Nr. 4, July 1978 (7 ) Sneed, H.: Re qui rements Analysis of Business Systems", Proc.Int . Comp. SympOSium, AGM German Chapter, NUmbe rg, 1983 (8) Jeffeny, D.R.: "Time - Sens i ti ve Cost Models in t he Corrmerci al MIS Envi ronmen t" , IEEE Trans. SE-13 , Nr. 7, July 1987 ( 9 ) Howes, N.: Managi ng Sof tware Devel opment Proj e cts f o r Maximum Productivity", IEEE Trans. SE-10 , Nr. I, Jan. 1984 (lO)Shatz, S. / Wang, J .-P.: " Introduc ti on to Distri buted Sof tware Enginee ring" IEEE Computer, Oc t. 1987 ( ll )Basili, V. / Tume r,A. : "Iterati ve Enhancement A prac tical Technique f o r Sof tware Engineering" IEEE Trans., Dec . 1975
Auto mated Softwa re Pro ject Plannin g and Con trol ( 12) Chen , P.: "Entity- Relationship Model - Toward a uni fied View of Data" , ACM Trans. on DB Systems , Vol . 1 , Nr. 1 , March 1976 (13) Zachman , G. : "Business Systems Planning and Bu s i ness I nformation Control Study", IBM SysTems J ournal, Vol . 21 , Nr . 1 , 1982 (14 ) Sil verrnann, B.: "Software Cost and Produc t i vi ty Improvements - An Analogical Vi ew" , I EEE Computer, May , 1985 (15) Boehm,B . /Brown , J . : "Characteristics of Software Quality" Nor th- Holland , Amsterdam , - 1978 (16) Boehm, B. : " Software Engineering Economics" , I EEE Trans. SE- 10 , Nr . 1 , Jan . 1984 (17) Putnam , L. : "A General Empirical SolutIon to t he Macro Software Sizing and Estimating Problem" , IEEE Trans . SE- 4 , Nr . 7 , July 1978 (18) Boehm , B.: Software Engineering EconomiCS , Prentice Hall, Englewood CliffS , 1983 (19) Albrecht, A. : "Software Function , Source Lines of Code , and Development Effort Prediction" , I EEE Trans . SE- 9, Nr . 6 , 1983 (20) Wolverton , R. : " Software Cost Analysis and Estimati ng ", U. S. Ai r Force, Wri ght- Patterson Air Base , Feb. 1980 (21) Ferrentino, A. : "Making Software Development EstImates Good " DATAMATION , Sept. 1981 (22) Boehm, B. : "Software Engineering Economics", IEEE Trans . SE- 10 , Nr . 1 , Jan . 1984 (23) Done 1 son , W. : " Project Planning and Control " , DATAMATION , June 1976 (24) Reuter , V.: "Using Graphic Management Tools" , Journal of Systems Mgt . , April 1979 (25) Tausworthe, R. : "Work Breakdown Structure in Software Project Mgt ." , Journal of Sys . and Software, Nr . 1, 1980 (26) Branstad , M. /Powell, P . : " Software Engineering Project Standards" IEEE Trans . SE-lO , Nr . 1, Jan . 1984 (27) Snyder , T . : " Rate Charting" , DATAMATION, Nov . 1976 (28) Bersoff/Henderson/Siegel: Software Configurati on Management, Prentice Hall, Englewood Cliffs , 1980 (29) Sneed , H.: Softwre-Qualitatssicherung" , Rudol f MUller Verlag , Koln , 1988 (30) Sneed , H.: Software- Management, Rudolf MUller Verlag, Koln , 1987