Software Tools for Supporting Project Management

Copyrighl © IFAC Experience wil h the M,magelllent of SOfl\\:are Projects. Heidelberg . FRG. 1986

SOFTWARE TOOLS FOR SUPPORTING PROJECT MANAGEMENT H.-H. Maier SI EME.vS AG . MII(,II(ill'II-Pn/{[(h , FRG

Abstract

For the successful and efficient realisation of a new version of an operating system, procedures and tools must be emp l oyed. Such a project is characterized by tile large number of functions, programs, interfaces, cross references , and dependencies witll earlier versions. For instance, they can reach a magnitude of up to 500 , 000 modified or new statements. Without such tools it would not be possihle to develop and release to the customer new operating system versions with the required hIgh quality at acceptable time intervals . For most of the tasks concerned, procedures and tools have been in use for years. They serve to relieve the project manager of routine work, enhance the quality of the products and production processes, and are suited to all project types (new development, ma i ntenance, redesign, etc.). The i r basic structure is derjved from the specifjc requirements of operating systems: Tools and procedures for managing operating system versions. rools and procedures for managing component groups or subsystems constituting a new operating system version (see Table 1) A central department is in charge of the development and maintenance of those tools. A control center for handl i ng customer service as well as for the administration of data has been established . This report presents the experience gained in the use of these procedures and tools . The focal point is PULS, a system for contolling the development and maintenance of our operating system. Finally, new trends emerging in this area are descr i bed. An example is given showing how expert system techniques may help In solving project management problems.

Keywords:

Project management, tools, operating system

1. Special Problems Encountered with Planning and Control of Very Large Software Projects

Contents

----------------- -- ----------- ---------------1. 2. 3.

Special Problems Encountered with Planning and Control of Very Large Software Projects Solution Approaches Use of Tools during the Preparation of a New Version 3.1 PULS 3.2 KENIA 3 . 3 SINET 3. 4 SIPUS/PACI I /AC T

Almost all problems occurring with software developments are also encountered in the develop ment and maintenance of a large- size operating system. The main prohlem concerns the dependencies, resulting from the l arge number of interfaces, that must be taken into account when implementing new functions or modify i ng existing functions . As a consequence, the realization of a function must usually be organized in successive steps until it is completed. In order to solve the pr oblem caused by the large number of interfaces special actions have already been taken.

3. 5 EDB/COCOMO 4. 5.

Use of Procedures Outlook References

141

H.-H. Maier

142

For example: 1. The operating system has been divided into a number of subsystems and some interfaces have been encapsulated. 2. A number of tools has been developed which analyse and document the access to interfaces. However, a truly satisfactory solution cannot be achieved ty the use of tools and procedures alone; a continuous communication between the departmen ts involved is required.

Further problems concern: - High rate of evolution of programs caused bv market requirements and adaptation of programs to new hardware and outdated program design (maintenance) - Limited degree of flexihtlity in the modification of interfaces - High qualit.y requirements, especially in reliability, ease of use and performance. In each new vers i on quality must be increased, or at lelist mai.ntained - Short development time

~.

Solution Approaches particularly concerning quantitative problems

a number of problems can be solved through the use of tools - particularly concerning quantitative problems - ~urther basic rules and refined methods and procedures are required ~or the production of new operating system versions.

- System management comprises the planning, monitoring and control of an overall version as well as the version sequence and, in particular, the coordination of version projects and the extern"l relationships and dependencies of a vers i on as well as the coordinaUon of i.ntegration, the system test and acceptance test. - Project management comprIses the planntng and control of a project from the initial step 'requirement studv' to the final step 'function test'.

System manaRement The hasic flow of version development is shown in Fi g. 1: 1. Continuous collection and evaluation of requirements by a 'Change Request' meeting. Requirements mainly come from the customers based on applications, from new hardware development - which must be supported by the operating system -, from functions offered by competitors and from t he operating system development departments themse lves.

Althou~h

- Creation of independent subsystems with narrow, well-defined i nterfaces. - Listing of users of tnterface through analysIs tools. - Transfer of i nterfaces to a higher level while mainta i ning upward compatibility. - Reviewing all design documents for interface errors (see Chapter 4 for details). - Reducing the number of change requests by the strict use of requirements engineering. - Increased use of high-order languages. - Cont i nual execution of code restructuring. - Continuous execution of quality assurance measures such as program runtime measurements, staff training and the use of review. - Definite allocation of program developers to specific components as well as continuity regarding technical responsibility. - Standardized procedure for projects in regard to follow i ng points: a. the use of a quality step following each development step b. observance of the priority sequence , qualIty-release date-function' c. the control of projects according to definite process steps.

3. Use of Tools During the Development of a New Version The use of tools is demonstrated for the development of a new operating system version; the functions of the tools used are described on the basis of the functions to be performed in the process. Two management levels are to be distinguished:

;:>. Decision-making on the functions

to he implemented and their characteri stics as well as their inclusion in the l i st of functions. For each product it is decided separately which requirements will be observed. The inclusion in this list Qocuments that the function is to be implemented; however, the version where thi.s will take place may not yet be specified. The final decision is made by the manager responsible for this product in the Marketing department after having discussed this with the production manager. 3. Version plann i ng Preparations for version planning are handled by a separate department; planning, in th i s case, involves: - Determining the version sequence tak i ng into account production periods for Integration and System Test - Allocating of functions to versions - Determining milestone dates - Determining the vers i on designation - Observing marginal conditions such as hardware supplies - Developing and realizing a long-term strategy 4./5./6. Definition of requirements and allocation of functions to individual projects Once the decision has been made to create a new version, the requirements are examined in the form of studies and exactly defined. One of the results of studies 1.s the determination of who \o1i.ll be responsible for a function; this makes it possible to combine project functions and to allocate these projects to individual departments where they are realized. If conflicts of responsibility arise in spite of this, they are resolved by opting for supplies.

Tools for Supporting Project Management

7 ./Il. Relea.se of a version to Marketing and

to all customers Once a version has been developed completely, it is released to Marketing and delivered to t~e customers who requested this version after successful field test ing .

The overall execution of a projec t is illustra ted in Fi.g. 2: 1./2 . /~./4 .

Project execution up to the function t est A project must implement t~e specIfied requ ire ments, .i.e. it must, within the scope of a process model, go t.hrough the steps of planning, i. mplementation and function test and then supply the result to Integration after production release . If considerable delays result - as indicated in Fig. 2 for project 1 - , the funct i ons may be included in the next version - as indicated in Fig . 2, VersJ on 11. The reason for this is that version production has a fixed time schedule and later integrations are usually not possible for reasons of ensuring quality. A rescheduling of this kind, however, is
5./6 . /7. Vers ion integration, system test and release to Marketing As shown in Fig . 2, the integration of results from project 2 is done in stage 1 of the version c reation. If errors occur here, they are corrected by project ?; the repaired parts are again handed over to Integration, where object corrections are permH ted in order to speed up testing. Following successful stepwise i ntegration of all project results, the system test is performed by spec ia 1 teams; it covers, in particular, performance tests, configuration tests, and stahility tests. The last activitv tn the chain is acceptance testing by Marketing. 8 . Annual capacity plannin~ The relationships between projects and annual planning are illustrated in thIs part of Fi.o:. 2 . Each department plans the budget in coordination with Marketing - and the product manager, who knows the projects in process and can determine how many new functions can be accepted . The functions described here must be planned and controlled by system management and project mana.o:ement; the following tools are avai l ab l e f or this purpose: - PULS - KENIA - SINET -

(Production and control system) (Inhouse order costing) (Syste m for interactive network pl anning) SIPUS (SINET- supported planning and control procedure) PACII (Project analysis and control) (Activity chart for human resource ACT allocation) (Cost da ta base) EDB COCOMO (Constructive cos t model)

143

3 .1 The Functions of PULS will be Described

on the Following Pages

-----------------------------------------PULS supplies the most important information for system management and project management. PULS ensures data consistency and supplies all persons invo l ved in the development process with reliable data for decision-making (based on ) . PULS is based on a on-li ne data base system (UTM/UDS) which ensures reliable information exchange for different users at various locations. For instance, the status of a reauirement may be determined at any time as w~ll as the date of it.s release . PULS operates on the principle of approval by the next authori.ty: For instance, if a component has been declared as 'completed', it does not actually attai n this state until the test team has tested and accepted this component in accordance with the acceptance conditions . Fig. j shows the underlying principles of using PULS; note that., due to project complexit ies, deployment characteristics may vary from case to case. - Maintaining a Hst of all functions New func~ions are analyzed and described in a first step; a basic decision on their implementation and inclusi.on in the function list is made in the second ste p. - VersiP't1 allocation Allocation of functions to a given version; starti ng at th Is time, the list of functions can be created for each version with the aid of PULS . - Project allocation Allocation of functions to a given project; it is now up to the pro ject manager to enter the pro ject plan dates. - Component allocation Allocat ion of components to functions and creation of the function/component matrix. These constitute the preconditions for performi.ng the development steps implementation and function test. - Transfer of components Transfer of the new or corrected components from Deve lopment . Here they are checked for conformity with handover conventions, and updating of the affected relationships, e.g. irlentifying the functions, change requests comp onen t handed over . Normally, source components are handed over . However, in the interest of speeding up testing, it is frequently necessary to provide corrections for object components; in these cases, PULS checks for consistency between the source components of the development teams and the test teams . The result of this step is a change log and a handover log for the integration test. - Inspection upon reception Afte r all items have been handed over by the development teams, they are inspected by the test team. Depending on the inspection resu l t, these items are either accepted, partially accepted or rejected; the resulting status from the inspection is recorded.

H.-H. Maier

144

- The creation of test versions and delivery unIts The handed-over and inspected components are combined tnto versions for the phased tnte gration test; t~is is a recurring step whic~ serves mainly to record the specific corrections to be considered for a specific inte gration stage. Another function serves to record the specific functions a.nd components comprising a version; inspite of well-defined specifications at the start of the project, considerable changes may occur during the duration of the project. - The acceptance and tracking of error notices Acquisition of error notices resulting from testing which initiate corrections. The error notices are entered in PULS by the tester, who also assigns them to the person who is responsible for the component in questIon. After analyzing the problem, he submits his comment; the error notice is then ass ig ned the 'accepted' status. After the error has been corrected, this is recordeQ, giving the version number from which the correction validity begins. After it has been checked by the test team, the error notice is assigned the 'closed' status if the test team is of the opinIon that the error has heen elimjnated. This procedure ensures that all error notices can be checked to see whether they are actually being processed and what processing status they are in . PULS prov i des consistency checks to ascertain that all errors in the new versions have been eliminated, which had also been eliminated in the old versions . A good indication of the problems that PULS is capable of solving are the 400,000 items of information - such as components, component groups, subsystem module s, subsystems, error notices, comments - and thei.r interrelations that are stored and continuously accessed for analyses. Without machine assistance, many operations would be either extremely errorprone or could not be executed at all. Thus PULS constitutes the major tool for quality assurance during new version development.

3. 2

KENIA

This tool is expected and to make them ment s in the

designed to enter and analyze actual costs for all projects and available to projects and depart form of monthly reports.

The major functIons of KENIA are shown in Fig. 5: - Organizational structure Entering the organizational structures of all departments - Annual planning Entering the budget planning for the next business year; the expected values for the projects are derived from these data when the agreement with the contractor is concluded. - Software calculation Performing precalculation, continuous calculation and postcalculation using a standardized calculation method

- Entering the actual effort Entering all resources used, costs of materials, man-hours, CPU time, outside costs-, monthly comparison with the expected values. - Corrections and debiting The 'Correction' function is provided to correct entry errors that are not detected until after analysis. The 'Dehiting' function is used to prepare invoices - in cases Hhere the project has provided services for others - and to capture invoices directed to the project. - Analyses Analyses are performed monthly accordi.ng to the rules established by the 'Organizational Structure' function. Analyses are provided for - Pro .iects, with Expected I Actual comparison for all cost types and process steps - Quality costs, broken down by costs before and after results have been released - Departments, with all projects of a department being combined by expected and actual values. Fo~ the project manager, KENIA is a reliable tool for monitor ing pro.iect costs; handling is centralized, requlr l ng no effort on the project manager side.

3.3

SINET

SINET supports scheduling and control as well as capacity planning. SINET is used for large-size projects with many dependencies to other departments (see I for details on netwo rking). The functions are: - Scheduling - Schedule monitoring - Reporting on the basis of network plans. In actual operation, a service department performs all techn ical functions related to network plan generation and updating . The project i.tself supplies only the expected and actual values and receives the current schedules at monthly intervals.

3.4

SIPUS/PACII/ACT

SIPUS, PACII an0 ACT are requisite modules for KENIA. Thev permit the deployment of staff on the basis of worl{ package~. The actual effort per staff member is captured and checked for deviations from planned values over a fixed time period. The control mechanjsms of the three tools are as follows: SIPUS:

Indicates how much capacity remains for the work packages of a project or whel'e capacity has been exceeded; work packages can be declared as 'finished'. SIPUS has an interface to SINET that can be activated, i f required.

Tools for Supporting Project Management PACII:

Basic functions like SlPUS; in addition, the dependencies and oates for the work packages can be entered as well. I f i t turns out during project execution that individual work packages require more effort than was planned, PACII determines a new finish date for the project, taking into account dependencies ano new expenses.

ACT:

Planning establishes, on the basis of the work packages to be implemented, which staff members are Jnvolved and .,ith what percentage of the monthly capacity - refer to the example in - Table 3 - ; time not yet planned is entered as 'free '. After the time period has expired, the actual percentage that a staff member has worked on different work packages as well as these work packages themselves, are listed. It is a salient feature of ACT that, contrary to SIPUS and PACII, the user interface is designed to permit the project manager to easily perform all ACT-related functions instead of relying on serv ice units. Further, ACT may be used to control the ass ignment of staff members in several projects.

The introduction of these tools was smooth with good results and little effort for project managers since very little training is required for both initial and routine use.

3.5

EDB/COCOMO

Both tools support effort estimation and project planning. EDB functions include: - Determining of characteristic figures (rates) for software - Information on project experience - Calculating CacOMO table values _ Tak i ng over central data from completed projects (e.g. costs from KENIA postcalculation) COCOMO functions (detailed description in /
:MSP-K

145

Both applications are designed so they can be used by project managers without requiring any learn i ng effort. The results achieved with COCOMO were very favorable; COCOMO covers all major effort estimation and planning aspects in a straightforward manner, may be adapted to specific requirements, and is easy to l earn . The only disadvantage concerns the fact that COCOMO continues to be based on LOC's that are not known at the start of the project ann are difficult to esti_mate; a better solution must be found for this problem in the future.

4. Use of Procedures WPile tools are designed mainly to ensure reliable processing of large volu mes of project data, procedures are provided to keep those involved in decision-making processes up to date on the planned course of action and to control project flow. The major proceoures are shown in ~able 2; their ma in functions are: Project Meettngs - Change request meetings In these meetings, decisions are prepared about changes of functions and the changes in the scope of the functions. - Version management and daily management Meetings for controllIng and monitoring version projects and subsystem projects. - Phase completion meetings At these meetin~s, the results of the completed process step are checked against spec ified mi.lestones, and planning for pro jec t continuation is authorized . - Manual plannl.ng Manual planning is a tool for coordinating manual preparation with program development, particularly from the time the external interfaces are ready . This ensures that a manua l reflecting the current fun"tion status is avail able in time for every product . - Flnal project meeting Final meeting, when ver y large projects are concerned, where experiences and knowledge are discussed; the result is a final report. If required, a change of rules or new rules are proposed based on the knowledge gained from the project.

- QA report Report on the quality objectives reached on the basis of the characteristic figures for quality specified in the QA plan. - Test report Report on the test results (number of errors found, number of test cases, text coverage, etc.) in the different test steps. - Measurement report Report on the measures and results concerning program runtime behavior and memory requirements. - Final project report Report after completion of a process step and of a project (see Tables 4 and 5 for contents).

H.-H. Maier

146

- MTA (Milestone Trend Analysis) Presentation of release dates. A check is made at 2-week intervals to see if, under the current circumstances, the planned date can be met or if it should be moved up or extended. MTA's serve primarily to track dates below the milestone level; at that level, many changes occur that do not require the milestone date itself to be changed (see Fig. 6).



Tom de Marco: Controlling Software Pro j ects Yourdon Press New York, 1982, ISBN 0-917072-'\2-4



Peter Rinza: Projektmanagement VDI Verlag Duesseldorf, 1985, ISBN 3-18-40063~-8

Reviews - DDC (Development Document Control) Under this procedure, expert comments are submitted to the document originator through a referee. Used when a large number of persons must be involved i n the examina tion process. - Code Inspection The source code is checked by a team for adherence to the rules, conformity with design, correctness and performance. - WT (Walk Through ) In a WT, the document originator walks a team through th i s document or parts of it while the team asks quest ions or makes comments.

'5. Cone lusions

Efforts are now beIng made to improve management support through tools even further. The main emphasis of these activities is on an assembly program which automatically puts together all elements of a version. At this time they are checked for completeness and formal consis tency. Further, studies are being conducted on the use of expert systems f or project management; initi al results are available from a pUot on the subject of 'Work Breakdown Structure Plan for the Design Phase'. The objective i s to extract a work breakdown structure plan from the project description entered by the project manager and to calculate a proposal for the effort. Fig. 7 shows a section of the top-level structure of the knowledge base for this problem. An interesting si de effect emerged after initial experi ence was gained; since the creation of a structured knowledge base requires a much more precise definition of actual project flows and the i r information needs, new measures f or increasing the efficiency of projec t handling can easily be derived from these results. References



E.H. Bersoff: Software Configuration Management Prentic Hall London, 1980, ISBN 0-13-8::>1769-6



Barry W. Boehm: Software Engineering Economics Prentice Ha ll London, 1981, ISBN 0-13-822122-7

H. Wille/K. Gewald/H. D. Weber: Netzplantechnik R. Oldenbourg Verlag Muenchen, 197 2 , ISBN 3- 486- 3743 3-8

Tools for Supporting Project Management =========================================:=================Development Handbook Requirem. Management

Configur. Management

Quality Assurance

Time/Cost Management

f===-========-===============F============= =============F================ S y

S T E M L E V E L

Procedures

Tools

Version Management

Meetings for Change Requests

QA Report

Final Project Meeting Final Project Report

PULS

PULS

PULS

PULS KENIA SINET

DaHy Management

P R

QA Plan

Phase Compl. Meeting QS Meetings MTA Final Project DDC, PES Charac. Figs. Report Test Report WT Code Insp. Meas. Report Manual Planning

0 G

R A M

L E V E L

Procedures

PULS

SIPUS PACII ACT EDB COCOMO

PULS

Tools

-===-========-===============-=============-=============-================ Table 1: Tools and procedures

Table 2:

Development Step

Quality Assurance Step

Requirement study Solution study Function design Test design Component design Coding design Code Component test Integr. and funct. test System test Pilot application

DDC DDC DDC WT WT WT

Code Test Test Test Test

inspection report report report report

Example of QA measures for each development step

147

148

H.-H. Maier

Employee: Maier

JAN

Topics

Function-1

Date: 27.03.86

Process Step: E40

-------r-----lI-----FEB MAR IAPR

MAY

40(40)

80(90)

90

90

10(00)

10

10

Function-2

90(95)

50(55)

SWT

10(05)

10(05)

DDC

(10)

JUN

JUL

Maintenance

60

Leave

30

10

Free

10

90

Legend :

Table 3:

80 (gO)

Activity Chart

Project description

Project statistics

Project experience

80 % expected, 90 % actual

-

Project Subject Project Project

name field (e.g. Compiler, Sort) type (e.g. Redesign, Maintenance, new development) organizaUon plan

Per project:

Per process step:

-

-

COCOMO factors Start date, end date No. of man-hours No. of logon hours DLOC, Progr. language

Process step name Start date, end date No. of man-hours No. of logon hours No. of employees 1 reference value 1)

regarding the following topics (examples): - Experience with tools and methods per process step (positive, negative, measurable effects, effort - e.g. for introduction reasons for explicit rejection, if appl.) - Recommendations for project management/organization - Reasons for deviations from estimate - Reasons for project success - Experience regarding code estimation - Major influence factors for the project - Measures to improve quality - Obstacles for the project - Reusable modules (generated, used) - Effect of control measures on project flow

Table 4:

1)

Contents of project report

That reference value should be selected that has the most pronounced effect on effort (e.g. number of functions/components/DLOC/test cases/ errors/pages/interfaces).

Tools for Supporting Project Management

Task

Team

Mile-

stone

Start-End

Hoursn Logon Team

Result

-------------------- -------------- ----- ------------- --------------Training Requirements Prelim. Design Design Funct. Design Det. Design Code Funct. Test Documentation Supplier Softw.

S35 s40 F40 F70

2.04-30.04.83 1.05-20.06.83 21.06-30.07.83 1.08-30.11.83 1.12-20.02.84 1.12-20.02.84 21.02-20.05.84 21.05-31.08.84 1.09-20.09.84

-------------------- -------------Project Name Date Start-End Team Hours Logan Hours DLOC, Language Cost Driver

Table 5:

: : : : :

:

Example of a project report

5 5 5 5 2 3 5 5 5

-----

720 880 1.120 2.320 400 1.280 1.280 2.080 720 1.840

20 50 267 420 600 450 1.500 200

12 4 180 220 40 40 40 25 800

modules functions pages pages modules modules modules test cases pagesn

------------- ---------------

Example 02.04.83-30.09.84 12.640 4.250 19.000 ASSEMBLER hnh hhnn hhhhh hhh

149

H.-H. Maier

150

fig

1

Version generation flow

Tools for Supporting Projec t Management

15 1

Ejg 3 . PU LS f un cti on f l ow

PULS - DB

FM 2000

Proj ect

Managemen t ,Top ic l eader

510

890

Desig n

Test

Assurance

I I I

I I I

Ope ration

Ma intenan ce

152

~g

H.-H. Maier

4

KEN IA funk! lon flow

fig . 5 : (OB Information fla w

\ !..!'iI.!!!.t

CD

OQtr~ ddQ)'~d dUI to ~ ls s jn9 purcha, i1rms



DOlts moved up dut to rUCh t (lvllfl9

fjg 6

£..Ig 7

Kno wledge bose structur e 10eSlg!,phasel

Milestone trend ona ly2i!