A software project management method
Dr. Sergio Coronado, Experience Application Factory
Dr. José Alberto Jaén, ETSI Industriales Universidad Politécnica de Madrid
Three studies about the development of Practices in software Engineering carried out during the mid-nineties (Jones 1996; The Standish Group 1994; KPMG 1995), produced results that led to the conclusion that the success rate of software projects is very low, and one of the main problems lays in the project management. To understand the behavior of a project it is necessary to build a model of it, simulate it, and analyze the results of the simulation in order to comprehend all the possible occurrences during the execution of the project that could affect the achievement of the established objectives. A project without a structure is an unmanageable project, it cannot be planned or estimated, nor can its progress be controlled, and it could hardly reach any compromises on costs and delivery times.
Software project management arises from the necessity to ensure the quality in the development of software products in terms of schedule, effort, and costs. Most of the started software projects are never finished, and those that are finished usually are finished out of the planned timeframes, at higher costs than planned, and with specifications that deviate form the initial requirements. This lack of quality in software developments is mainly due to the lack of an adequate project management. The deficiencies in software projects have forced the development of a process, which main objectives are the management of the project, the selection of the tools and techniques based on the real needs of the development and the characteristics of the problem, the quality assurance, and the management of risks.
According to the research and studies carried out by the scientific community (Pressman 1997; Putnam and Myers 1997; Jones 1996; The Standish Group 1995; KPMG 1995; Royce 1998), the failure of software projects is centered on three elements. The main failure elements in software projects are:
• Inadequate project management
• Inadequate project planning and estimation
• Project management methods not suited for software projects.
A solution of this common problem is a method to guide the project managers to create a project process to structure, estimate, and plan the possible path in the development. The proposed method presents a unified three-dimensional matrix view of project activities (A3) combining two process dimensions (product and project) and one product dimension, and their union in a three-dimensional conceptual matrix. This unified view is supported by risk analysis and continuous adaptive quality control, both through predictive cost models (COCOMOII) and statistical estimation techniques (Monte Carlo simulation). The method, as a system, creates a Probability Activity Network, an output based on two types of inputs. Inputs related to the product development in form of software requirements and inputs in form of project characteristics; Organization Characteristics, Risk and External Dependencies, and QA Characteristics (Exhibit 1). The A3 model consists of six elements:
- Three-dimensional structuring of software projects
- Planning based on the three-dimensional structure
- Estimations based on probability distributions
- Modeling of risk and quality
- Simulation and project analysis
- Visualization of structures and results
Exhibit 1.A3 Method Inputs and Outputs
Exhibit 2. Three-Dimensional Space and Matrix for A3 Model
Exhibit 3. WebTutor Subproducts
The method models the Software Project as a product identifying three elements; the software product itself and two types of processes: product-oriented processes (PdP) and project-oriented (PjP) processes. The PdP are all the processes needed for the software construction like requirement analysis, design, coding, and so on (IEEE 1991; ISO/IEC 1995). The PjP are all processes related with the management of the project activities (Project Management Institute 1996) (project office, HHRR, configuration management, QA, Risk, and son on) and are designed to provide support to the PdP and to the project structure. The products and processes, acting as construction pieces, permit the creation of the project's structure. The graphic representation of the product-oriented processes (PdP), the project-oriented processes (PjP), and the products (P) is made by assigning each of them an axis forming a three-dimensional space, as shown on Exhibit 2. The integration of these three elements (software product, PdP, and PjP) defines a model named A3 Model, which represents the product Software Project visually and structurally.
The three-dimensional space resulting from the connection of the three elements is a cubic matrix of elements (Exhibit 2). Each cell constitutes a series of activities (a cell represent an activity package create by three references, A3), and results from defining the necessary activities for a product process and a project process applied to a product. The structure is started by breaking down the products into sub-products. Breakdown simplifies the problem because it creates smaller sized problems, facilitating the planning and estimation activities.
3. A3 Method
The description of each one of these steps will be supported by an example of the use of the method in a software project. The project selected is called “WebTutor, a Knowledge Based System for Evaluation and Tutorship” (Coronado et al 1998). The main objective for developing the WebTutor system, was providing a new technologies-based (Object Oriented Databases, Internet/Intranets, and Multimedia) tool to help both, the evaluation and tutoring, of students in short and defined periods of time on an individual basis. The result of the application of this tool is a series of data that shows the knowledge level of a student or group of students on specific subjects (Mathematics, Physics, Chemistry, and so on). With this information the students will be able to review, with special emphasis, those subjects on which their knowledge level is not adequate. On the other hand, the human tutors will have the opportunity to direct their courses to the level of the present group. The system is designed to be implemented in any subject. Its implementation is made possible by the development, by a team of experts, of a questions database in the specific subject to be evaluated.
3.1. Three-Dimensional Structuring of Software Projects
The products are identified based on the objectives of the project and the software requirements defined by the client. In some projects the product identification itself generates new products that are necessary for the construction of the main product, or that have as primary objective the reusability or the development of components. In the case of WebTutor, the product identified is a software product that will manage the student's interface with the human tutor interface through a contents database.
Once the products to be developed are identified, they are broken down into simpler products, which are easier to develop, control, and follow-up, just as in software design the products are divided or broken down into smaller, simpler products. Likewise, on a project level, breakdown reduces complexity. The result of the product breakdown is defined as subproducts (SP). Three subproducts are identified to build the WebTutor software (Exhibit 3), two of them are at the same level and are responsible of handling (content management) and storing (database) all data elements. The third subproduct implements all the users interface components, allowing students and human tutors to interact with the contents.
According to the characteristics of the products to be developed, the characteristics of the developing organization itself, the software life cycles and the objectives of the project, the definition of the product-oriented processes necessary for the construction of such products is carried out. The product-oriented processes used in the tool implementation of the method (WebTutor) are based on IEEE 1074 standard, ISO 12207, and a 5 process Incremental Software Life Cycle (Pressman 1997). The PdPs selected are Requirements (RS), Analysis (A), Design (D), Construction (C), and Testing (T), and are the base of the example construction.
The identification of project-oriented processes defines all the processes necessary to support the construction on the level of each product and subproduct process. The project-oriented processes used in the tool implementation of the method (WebTutor) are based on A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute 1996). The PjPs selected are project office (PO), HHRR (HR), configuration management (CM), infrastructure management (Inf), document management (Doc), QA, and risk, and in conjunction with the PdPs are used in the example construction.
3.2. Planning Based on the Three-Dimensional Structure
With the three defined axis, the three-dimensional model is constructed and the processes that constitute each sub-product are assembled. The three-dimensional elements are represented and organized in a matrix. Exhibit 4 shows the basic A3 Model for the WebTutor, building the matrix with the three sub-products, PdPs, and PjPs.
Subproducts must be integrated once developed in order to create or construct the final product. This integration generates new products, which are the result of the integration effort and are defined as integration subproducts. The integration design defines the dependency (link) between the product processes of each subproduct and the integration, and between the products and external activities not controlled by the project, defining the project’ structure. The whole set of entwined subproducts will represent the project’ static activity network. The integration process forces the planning of effort and schedule of the integration (Cleanroom Engineering Handbook 1993) reducing the overrun in software projects. The integration process for the WebTutor development is designed with two integration products (Exhibit 5). The first product integrates the content management with the database, allowing the solution to handle different types of contents in persistence media. The second integration product adds user interface capabilities to the data management creating the final solutions. Three external activities have been identified; text management and image formatting for the content management process, and resource allocation for the user interface development.
3.3. Estimations Based on Probability Distributions
Once the project structure has been defined, the size of each subproduct is estimated using traditional estimation techniques or historic data from previous similar projects in the organization. These estimation tools are used on the broken down level reducing the complexity of the estimation, which is done on smaller sized products. The basic estimation is carried out with probability distributions.
The estimation of effort and time in the A3 method is based on the utilization of an adapted COCOMOII model (Boehm 1995). The application of the COCOMOII model to the A3 method incorporates an adaptation of the method derived from the breakdown to a product processes level, that allows the application of the effort multipliers and the scale factors to this level. The application, for example in an incremental software life cycle of five processes, is carried out through the following equations:
Exhibit 4.WebTutor Basic A3 MODEL
Exhibit 5.WebTutor Integrated Model
PP: Product process [Requirements, Analysis, Design, Construction, Test]
(%E)pp: Effort percentage for a product process
(%D)pp: Duration percentage for a product process
Effort percentages are assigned according to historic data or distributions available from other investigations, like the ones carried out by Boehm (1981), and the duration percentages are calculated starting from the effort percentages and using the Rayleigh model (Kan 1995; Evans et al 1993), equation (6).
The calculated effort and duration values are modeled in the A3 method using probability distributions that allow the representation of the uncertainty associated to the estimation process and the unique characteristics of a software project. Traditionally estimations are weighted by calculating a weighted average for three points; optimistic estimation, most likely estimation, and pessimistic estimation. The weighted approximation does not evaluate the possibility of the occurrence of both, the optimistic and the pessimistic estimation, and the uncertainty model in estimation is based on a single number. The A3 method models the effort and duration variables using a triangular probability distribution or beta distribution (Evans et al 1993).
The total duration of each product process is calculated according to equation (7) duration and (8) effort, assuming that the effort of each project process is equal to a percentage of the PMpp effort.
Dpp … DQA: Duration of the corresponding project process.
Epp … EQA: Effort of the corresponding project process.
The estimation for all components of the A3 model starts on the historic data from similar projects, there are no formulas to calculate effort, times, and probabilities without error. This limitation in software projects originates the need to create a statistic planning, where the estimation is distributed according to a probability. This way, it is possible to model the delay using a triangular distribution where the most likely value will be displaced to the right.
The estimation process for the WebTutor example is done based on the product size of a desktop version of the WebTutor, and the WebTutor final product size. The effort and scheduled distributions are modeled as a triangular with 80 percent as the lowest value and 125 percent as the highest or the most likely.
3.4. Modeling of Risk and Quality
The effect of late detection of a defect in the planning of software projects is modeled in the A3 method through the Incremental Quality Network. The incremental quality network (IQN) allows modeling, in terms of time and effort, the impact of correcting a defect detected in a product process that has been caused by a previous product process. IQN's fundamental characteristic is that it models sub-branches on the product process level related with the previous product processes.
For example, let's say that for a Linear Sequential Model of five processes, the development is on the Analysis process; the IQN creates an additional branch which contains the Requirements and Analysis processes, and another that contains the process under study Analysis. The number of subbranches is equal to the total number of processes previous to the one in study plus the process in study itself. In the case of Design, there are two previous processes, which means that there will be three sub-branches. Exhibit 6 represents the IQN model for the Linear Sequential Model of five processes.
The IQN is incremental because, as the project progresses through the life cycle processes, the number of branches increases in proportion with the existing number of processes. The occurrence of a defect is an unknown or uncertain element. The quality branches are dependent on the uncertainty of a defect occurring and being detected. Uncertainties in the IQN branches are modeled as the probability P(x) of defect occurrence on a certain process. The probability P(x) is estimated independently for each product process and is applied to each of its IQN branches; consequently each of the branches has a probability Pnp(x), where np is the product process in study. Equation (9) mathematically expresses the duration and equation (10) the effort for a product process through the evaluation of its IQN.
Dnp: Total duration of the product process np.
Da: Total duration of the activities associated to the product process np.
Prn(x): Probability of the branch n.
DRrn: Duration of the rework on the branch n.
Enp: Total effort of the product process np.
Exhibit 6. Incremental Quality Network
Exhibit 7. WebTutor Complete Model
Exhibit 8. Effort/Months Distribution for the WebTutor Example
Da: Total effort of the activities associated to the product process np.
ERrn: Effort of the rework on the branch n
The IQN models the rework generated by the insufficient level of knowledge on some of the new technologies that were used as part of the WebTutor example. An object-oriented database was used when the development team had only a basic knowledge of designing and implementing this technology. The network was defined around 10 percent of rework with 10 percent of probability in most of the processes and 20 percent of rework with 20 percent of probability on the design and construction of the Database and User Interface products. These assumptions identify the worst case for this project, helping the project manager to plan and justify project reserves.
Risk branches model each of the risks identified by product process, relating with the effort and schedule and based on a probability of occurrence. Risk, from a project management's point of view, affects or impacts the number of resources assigned to a project and its performance times. Risk is the possibility of occurrence of an event that has a negative impact on the fulfillment of the project's objectives. Traditionally, risk is estimated and modeled through what is known as the Reserve for Risk. The organizations that manage the project reserve a percentage of the economical resources to cover the effects of the occurrence of a risk, or to cover the costs associated to the execution of contingency plans. Citing Kitchenham and Linkman (1997):
The occurrence of a risk can drastically modify the execution of a project; modeling and simulating the risk is basic for the identification of sensible areas within the project. Risk modeling is a complex activity that intends to represent events that could occur in the future. Modeling starts with the identification of possible risks though the use of historic data and the knowledge associated to the type of project, organization, technology, and product to be developed. Historic data offers information on how, and how much, a certain type of risk has affected similar projects.
The risks are uncertainties associated to future events and they have to be modeled as probabilities, assigning them a certain probability at particular stages of the project. Identified risks must be defined by estimating their probability of occurrence, their impact from the effort and duration points of view, and the stage of the project where they are most likely to impact.
The A3 method defines a specific model for modeling and simulating risks on product processes. The Risk Elements model is represented graphically by entwining risk symbols to the product process on which they are more likely to impact, and defining their three estimation characteristics: probability, effort, and duration. A product process can have as many risk elements as risks have been identified, and their evaluation is mutually independent. The advantage of risk modeling on the A3 method is that it permits the simulation and evaluation of the sensibility of a product when faced with risks in terms of time and effort. This allows not only to know the optimistic cases (where the risk does not occur or has a probability equal to 0), and the pessimistic cases (where the risk always occurs or has a probability equal to 1), but also the tendency of the project, and the probability distribution that results from the simulation of all identified risks and the sensibility on all possible points. Identified risks on an A3 model create multi-branched activity networks that expand the project in terms of time and effort.
Exhibit 9. WebTutor Project Processes and Product Processes Effort/Months Distribution
Two risk elements have been identified in the WebTutor project; new query process at design level of the data management process, and performance at testing level of the user interface process. These risk elements will help to model and simulate possible project delays and branches in the project.
3.5. Simulation and Project Analysis
The construction of the A3 model creates the base structure of product and project processes necessary to carry out the estimation of the project planning. The plans define the development strategy, the assorted activities to be developed, and their relations (activity network). Software estimation is not an exact science and, in some cases, some of the estimations developed are theoretically impossible.
The estimation process on the A3 model allows its definition on a low level, applying traditional estimating techniques on the subproducts and the integration products. Estimations are then modeled as probability distributions and are simulated using the Monte Carlo technique (Sobol’ 1994; Gilks et al 1996; United States Department of Energy 1995). The simulation through the Monte Carlo technique evaluates each of the probability distributions in the A3 model's structure, calculating the statistics for each product and project process. These statistics provide the average value, maximum and minimum values, values between the maximum and the minimum, standard deviation and the sensibility between the processes, the Incremental Quality Network, the external elements, and the risk branches.
The complete WebTutor model is shown in Exhibit 7, representing the project’ structural dependence between three products, two integration products, three external activities, and two risk elements in the visual representation. Exhibit 8 shows the best case, the mean case, and the worst case, for a 1,000 repetitions over the model, representing the spectrum of possible stages in the project.
3.6. Visualization of Structures and Results
With the results of the simulation and the three-dimensional model, it is possible to visualize the effort and time distribution on the three axes, which provides points of view on the project. Different views are developed on the three-dimensional model, facilitating the understanding of its structure and functioning as an abstraction of the complexity of the structure itself.
Exhibit 9 shows the effort/months distribution for the PdP and PjP processes providing different views of the resource allocations and helping the project manager to understand what resource is needed and when.
The proposed model for software projects management is based on the implementation of a three-dimensional management method that connects the product-oriented processes (such as analysis and design), the project-oriented processes (such as quality and configuration management), and the product to be developed itself. This three-dimensional model facilitates the planning process, the estimation, the construction of the activity network, and the simulation of projects, providing an analytical tool to study the structure of the project in development. The model had been successfully used to manage the development of the Local Result Information System in the Sydney 2000 Olympic Games. The Local Result Systems is a combine development of thirty-seven Information Systems, common components, and communications interfaces with a total of more than 10 millions of SLOC.
Boehm, B. (1981). Software Engineering Economics. Prentice Hall PTR.
______. (1995). COCOMO II Model Definition Manual. University of Southern California.
Cleanroom Engineering Handbook. (1993). SOFTWARE TECHNOLOGY FOR ADAPTABLE, RELIABLE SYSTEMS (STARS) PROGRAM, Task ID52—STARS Technology Transfer Demonstration Project for the U.S. Army.
Coronado, S., A. García-Beltrán, J. Jaén, J., and R. Martínez. (1998). WebTutor, A Knowledge Based System for Evaluation and Tutorship, Lecture Notes in Artificial Intelligence 1416, Springer.
United States Department of Energy. (1995). Computation Science Education Project, Introduction to Monte Carlo Methods.
Evans, M., N. Hastings, and B. Peacock. (1993). Statistical Distributions. John Wiley & Sons, Inc.
Gilks, W., S. Richardson, and D. Spiegelhalter. (1996). Markov Chain Monte Carlo in Practice, Interdisciplinary Statistics. Chapman & Hall/CRC.
IEEE. (1991). IEEE Standard for Developing Software Life Cycle Processes 1074.
ISO/IEC. (1995). ISO/IEC 12207 Software Life Cycle Processes. Jones, C. (1996). Patterns of Software Systems Failures and Success. International Thomson Computer Press.
Kan, S. (1995). Metrics and Models in Software Quality Engineering. Addison Wesley.
Kitchenham, B., and S. Linkman. (1997, May/June). Estimates, uncertainty and risk. IEEE Software.
KPMG, and A. Cole. (1995). Runaway projects—Cause and effects. Software World 26 (3).
Project Management Insitute Standard Committee. (1996). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Upper Darby, PA: Project Management Institute.
Pressman, R. (1997). Software Engineering: A Practitioner's Approach. McGraw-Hill.
Putnam, L., and W. Myers. (1997). Industrial Strength Software, Effective Management Using Measurement. IEEE Computer Society.
Royce, W. (1998). Software Project Management, A Unified Framework. Addison Wesley.
Sobol’, I. (1994). A Primer for the Monte Carlo Method. CRC Press.
The Standish Group. (1995). Chaos.