PROJECT MANAGEMENT

A SOFTWARE PROJECT
MANAGEMENT
FRAMEWORK
Antonio de Amescua, José García, Manuel Velasco, Paloma Martínez, Belén Ruiz, Juan Llorens, Luis Gar cía,
Antonio Calvo-Manzano, and Tomás San Feliu

This article reports the results of research into software project management. The main contri-
bution of this research is a software project management framework that consists of a static
structure, shown in an entity-relationship diagram, and a description of each component of the
framework. It also describes the procedure to design and validate the framework. This consists
of integrating the solutions of a traditional model (information model) and a formal model
(domain analysis). This software project management framework is a key element for rapid and
effective project management process improvement of a software organization.

OFTWARE PROJECT MANAGEMENT IS A Because software process improvement re-

S software life-cycle process in the manage-
ment process category. This category
consists of a set of processes that contain
procedures that can be used by managers for
any type of software development project.
ANTONIO DE Most software projects have been more con-
AMESCUA, JOSÉ cerned with aspects of technology rather than
GARCÍA, MANUEL management. Organizations that wish to finish
VELASCO, PALOMA
their project on schedule, keep within their
MARTÍNEZ, BELÉN
budget, and maintain quality should implement
RUIZ, JUAN
LLORENS, LUIS
good software project management practices.
GARCÍA1, ANTONIO Software process improvement (SPI) mod-
CALVO-MANZANO, els such as CMM and ISO 15504 define the pro-
and TOMÁS SAN cedures involved in software processes. While
FELIU belong to the ISO 15504 model determines the process
SOMEPRO, which is a capability level of a specific process within an
group of professors organization, depending on the process activi-
from three Spanish ties carried out, the CMM model determines
universities — Carlos the capability level, called maturity level, of the
III, Madrid
organization. Each management process (Re-
Polytechnic and Open
quirement Management, Software Planning
University — whose
main purpose is
Project, Project Tracking and Oversight, Soft-
research and ware Quality Management, Software Configura-
development on tion Management, Software Subcontracting
software process Management) must reach a certain process ca-
improvement. pability level to obtain this maturity level.
quires great effort and resources, it is necessary
to provide models that offer generic solutions
for each specific process that can be tailored to
the needs of each organization.
Although little has been done so far in the
field of software management process im-
provement, reference models such as CMM,
ISO 15504, and specific project management
models help determine the practices of good
software management. We used these docu-
ments, which make up the requisites of software
project management process specification, as
our point of departure.
There are many project management tools
available today. However, few of them support
software project management. The main defect
of these tools is the lack of integral support, spec-
ified in the models and reference methods, of all
the activities related to software management.As
a result, most organizations find it difficult to im-
prove their software project management pro-
cesses.
The aim of this research is to provide the
project manager or the software engineering
process group (SEPG) responsible for the soft-
ware process with a way to improve their

78 I N F O R M A T I O N S Y S T E M S
S P R I N G 2 0 0 4
M A N A G E M E N T
 PROJECT MANAGEMENT
respective organizations using a knowledge
base from which they can store and retrieve in-
formation on software project management re-
lated to all the software projects to be
undertaken.
This knowledge base will:
T racking ❚ Describe all the practices.
❚ Store all real data of current and past
and oversight projects.
are considered ❚ Provide relevant information for project
within the managers.
❚ Provide information to improve software
SPM domain. project management processes.
FRAMEWORK FOR SOFTWARE PROJECT
MANAGEMENT
A framework represents the information model
for the objects that can be described during
software process management (SPM). To
achieve our objective, we carried out the fol-
lowing activities:
1. Defined and determined the scope of Soft-
ware Project Management
2. Defined a framework for Software Project
Management using information modeling
techniques
3. Defined a framework for Software Project
Management using the domain analysis
technique
4. Designed a generic framework for Software
Project Management
Each of these activities is described below:
For this research, we used the case study
evaluation technique and analyzed the results
of activities 2 and 3 above to validate them. As
a result of this validation, we obtained a soft-
ware project management generic design.
Scope of Software Project Management
The purpose of this activity is to obtain a deliv-
erable called “SPM domain definition.” The ar-
eas considered in the field of software project
management, and those outside it, were de-
fined to facilitate the interpretation of the re-
sults obtained in future research stages.
A summary of the “SPM domain definition” is:
Software project management can be di-
vided into two areas:
1. Software project planning
2. Project tracking and oversight
Software project planning consists of de-
veloping a detailed project plan. This process
contemplates all the activities necessary for
I N F O R M A T I O N S Y S T E M S
S P R I N G
software project management: budget control,
delivery dates and effort distribution of person-
nel, as well as risk management needed for the
project.
Software project tracking and oversight
gathers current real data, performance and pro-
ductivity from the software project, compares
real and estimated data, and takes the neces-
sary corrective actions. Tracking and oversight
are considered within the SPM domain because
the information they manage will:
❚ Register the problems that arise during the
project
❚ Compare real and estimated data regarding
size, effort, cost, and finishing date of the
project
❚ Determine the percentage of effort distribu-
tion, cost, and duration of the project for
each process used
The definition of domain project manage-
ment does not include tasks on subcontracting
management (such as requests for proposals,
evaluations, recruiting suppliers, etc.). Quality
product criteria were not considered because
they are part of quality management.
The software project management frame-
work to be designed in the following activities
should satisfy the SPM domain definition.
SPM Framework Design Using
Traditional Information Modeling
Techniques
Our objective was for experts in information
design modeling techniques and software
project management to obtain the design for an
SPM framework. The tasks carried out for this
activity were:
❚ Recruiting experts
❚ Training experts
❚ Drafting frameworks
❚ Designing a common framework
The experts involved in this project were
divided into two groups:
1. Professionals who were project managers
in their respective organizations and have a
wide range of experience in software devel-
opment projects.
2. Post-graduates doing their doctorates and
non-graduates who were final-year com-
puter science students (fifth year) from two
universities, who had mastered the tech-
niques in information modeling such as
entity-relationship and UML diagrams. The
students were placed into groups of four.
2 0 0 4
M A N A G E M E N T
79
 PROJECT MANAGEMENT

TABLE 1 Document Corpus

Code Document Name

DSP01 IEEE Standard for Software Development Plans. IEEE Std. 1058.1
DSP02-05 Capability Maturity Model Key Process Areas
DSP06-08 ISO 15504 Standard Documentation
DSP09-14 ISO 12207 Standard Documentation
DSP11-13 IEEE Std. 1074 Standard Documentation
DEP02-05 Albretch Function Points
DEP06-08 COCOMO Estimation Model
DHP01-04 Platinum Process Continuum
DHP05-06,12 Open Plan Reference Documentation
DHP07-11 Primavera Project Planner PPBook; Reference Documentation
DRP01 SEI’s risks taxonomy
DMO01-03 Distributed Object-Oriented Software Process Modeling
DMO04 Rational Unified Process; Static Structure
DMO05-06 Workflow Coalition Standard; Process Modeling, Process Definition
DMO07 SEI Report in Software Process Modeling
DMO08 ProNet Graphical Modeling Language
DMO09 SPF is based on Process Definition Criteria; Glossary
DMO10 ETVX Definition
DMO11 Workflow Reference Manual; Process Technology

The experts came from four different orga-
nizations. A single framework was designed for
the organizations and a single design from all
the students who were in the same class was
compiled. The two models were analyzed to
generate the final framework design, which is
summarized in Table 1. Due to space limita-
tions, only the objects considered for the
framework, the existing relationship, and the
main attributes are presented.
The training given to the experts differed
according to type. The professionals took an
eight-hour CMM course and a sixteen-hour
Project Software Management course, while
the students took a sixteen-hour CMM course
and a forty-hour SPM course. However, the
same material was used and the courses were
taught by the same lecturers who also partici-
pated in the project.
Both the professional and student groups
had to design a software process management
framework. Over a period of two years, they
developed a total of 108 designs: 40 by the pro-
fessionals and 68 by the students. Lecturers as-
sisted the professionals, on request, with their
SPM model designs.
The main elements of this preliminary
framework were (see Figure 1):
❚ Project.A software development project con-
sists of a set of processes needed to build a
software system that meets all the require-
ments established by users at the beginning
of the development.
80 I N F O R M A T I O N S Y S T E M S
S P R I N G
❚ Process. A process consists of a set of coordi-
nated activities, performed in sequence or in
parallel, by a set of agents that use previously
defined resources. A process can be divided
into several activities. Each activity can be
further divided into tasks.
❚ Artifact. An artifact is any kind of material
element that can be created, used, or
updated during a process performance.
There are two types of artifacts: resource and
product.
– Resource. A resource consists of hardware
and software technologies, specific
objects, and abstract concepts that can be
described or captured in the form of
objects. They are needed to help develop
software systems. Examples of concrete
substances are buildings, conference
rooms, computer s, etc. Examples of
abstract concepts can include organization
structure, management concepts, and gov-
ernment regulations.
– Product. A product consists of a docu-
ment, source code, results of verifications
and validations, etc., obtained from exe-
cuted tasks.Therefore, a product is a result
of an activity or task.
❚ Component.A component is a part of a prod-
uct. A percentage of the effort required for
each component with respect to the total
must be indicated.
❚ Role. A role consists of a group of agents that
have a common set of capabilities, skills, and
responsibilities. Each role can perform or be
responsible for a process, activity, or task.
2 0 0 4
M A N A G E M E N T
 PROJECT MANAGEMENT

FIGURE 1 SPM Framework Designed by Experts

Project

is responsible

Time
Effort
Cost

uses
Process Role Agent
performs

uses

Date
Type
System Human

establishes
updates
Service Resource

coordinates
Artifact

Resource Product Component

updates

❚ Agent.An agent is a specific person who may This activity is very important because differ-
fit into one or several roles. An agent is the ent information selection generates different
only, and ultimate, person responsible for the domain models. The final selection of docu-
execution of a task. ments used to create the corpus of information
is presented in Table 1. It must be emphasized
SPM Framework Design Using Domain
that only the documents on software project
Analysis management are included in the corpus.
Domain analysis appeared in the previous de- The documents selected for this work are
cade as a problem-solving technique in the re- related to software project management stan-
use process within the global development dards, techniques, and tools with great impor-
process of a software project. Some authors tance in this knowledge area.
(Neighbors, 1990) define it as the activity of Each document of the corpus is enclosed
identifying objects and operations of a class of on a file that is coded using the following rules:
similar systems in a specific domain.
A domain analysis global process is mainly abcXX, where:
concerned, due to domain modeling, with the a: The type of the file referenced; in our case,
definition process of information storage struc- it is always D because all the files contain
tures. The tasks to be developed in domain documents.
analysis are Information Gathering, Informa- b: The type of the document. It can be of five
tion Processing, and Information Validation. classes:
This technique is used to build an SPM ❚ Software Engineering Standard (S)
framework semi-automatically. This model can ❚ Software Project Estimation Document
be compared with the one obtained using the (E)
traditional modeling information techniques; ❚ Document of software project manage-
that is, with the results presented in Figure 1. ment tools (H)
Information on the domain analysis process is ❚ Document of software risks (R)
presented in this section. ❚ Document with information about soft-
For this purpose, the aid of two types of ware process modeling techniques (M)
experts — an expert in domain analysis and an c: Knowledge area of the information con-
expert in the particular domain — is required. tained in a document. In our case, P,
Our research team has experience in these roles. because all the documents are about soft-
For the Information Gathering activity, both ware project management.
experts had to select the information that de- XX: Sequence number of a document inside a
termined the domain as completely as possible. category.
I N F O R M A T I O N S Y S T E M S
S P R I N G
M A N A G E M E N T
2 0 0 4
81
 PROJECT MANAGEMENT
FIGURE 2 Groups of SPM Descriptors
Estimation Organization Requirements
In Information Processing, the selected cor-
pus was processed to automatically obtain
terms (descriptors) that fully represented the
static structure of the SPM domain.
The framework generated through the ap-
plication of domain analysis techniques is com-
posed of a set of descriptors that permits an
organization to efficiently classify and retrieve
information and artifacts related to software
project management.
Based on the results obtained in this activi-
ty, the significant SPM descriptors can be
grouped as shown in Figure 2.
Because the descriptors obtained through
semi-automatic filtering techniques (Indización
estadística de términos por frecuencias inver-
sas, IDF) had different levels of abstraction,
they were divided into the following catego-
ries:
❚ Object: descriptors that can be considered as
elements with their own entity.
❚ Attribute: descriptors that can be considered
as features of other objects.
❚ Value: descriptors that can be considered as
possible values of an attribute.
❚ Reports or documents: descriptors that can
be used as documents or generated during
the project management activities.
❚ Procedures: list or sequence of steps for an
activity or task related to project manage-
ment.
By applying this breakdown to the set of de-
scriptors called PLANNING, the results shown
in Table 2 were obtained. The other descriptor
groups (see Figure 2) obtained results with a
similar structure (see http://raul.ie.inf.uc3m.
es/spm.).
According to the results of this domain anal-
ysis, the framework generated should have the
objects or entities identified in the object cate-
gory. There should also be a relationship be-
tween the objects in the same group (because
there are objects that are found in several
groups, relationships between objects in differ-
ent groups are allowed). The attributes of the
framework objects will be those found under
82 I N F O R M A T I O N S Y S T E M S
S P R I N G
SPM
Planning Risks Tracking Final Balance
attributes in domain analysis. The VALUE cate-
gory will give rise to the possible values of the
attributes shown in the framework. The rela-
tionships are also found at http://raul.ie.inf.
uc3m.es/spm.
The domain analysis categories REPORTS
OR DOCUMENTS and PROCEDURES will not
be reflected in the framework because they
represent products that can be obtained by
consulting the information in the framework.
Generic Framework for Software
Management Projects
The aim of this task was to develop and validate
the project management framework so that the
model developed meets the requirements of
the specific software project management. An
information modeling technique will be com-
pared with the domain analysis technique to
verify the resulting product. Any discrepancies
will be analyzed to obtain the final version of
the framework. As the framework developed
by the project management experts had a
structure compatible with the object/at-
tribute/value, an analysis of the discrepancies
that permitted the integration of the results in
both directions was undertaken. A list of the
main discrepancies between both models is
shown in Table 3. See http://raul.ie.inf.uc3m.
es/spm for the complete discrepancy table.
Finally, a design activity integrating the dif-
ferences between the frameworks, obtained
through the two techniques applied, was un-
dertaken.
The preliminary model designed by experts
(Figure 1) was enriched, so a software project
management domain representation was de-
fined (see Figure 3). This representation is a
class diagram following the notation presented
in UML (Booch, Rumbaugh, and Jacobson,
1999). In this new model the following classes
or entities were included:
❚ This domain model contains information on
the software processes used in an organiza-
tion. A process consists of a set of coordi-
nated activities, performed in sequence or in
2 0 0 4
M A N A G E M E N T
 PROJECT MANAGEMENT

TABLE 2 Classification of the PLANNING Descriptors

Descriptors

Object Life Cycle

Plan
Planned Activity
Software Project
Project Team
Attribute Critical Path
Milestones
Phase
Planned Cost
Project Characteristics
Project Manager
Project Phase
Project Procedure
Resource Assignment
Resource Availability
Finish Date
Value Milestones Dates
Overlapping Waterfall
Single Prototyping
Spiral
Spiral Build
Waterfall
Reports or Documents Calendar
Detailed Plan
Detailed Resource Plan
Detailed Technical Plan
Process Tailoring Guidelines
Project’s Process Training Materials
Schedule
Resource Breakdown Structure
Product Breakdown Structure
Time Sheet
Procedures Project Planning
Software Development Planning

TABLE 3 Experts and Domain Analysis Framework Discrepancies

Descriptor Expert Model Action

Object Life Cycle Project.LifeCycle An Object called LifeCycle must be included

Plan Project–Process An Object called Project Plan must be included
Relationship
Planned Activity Project–Process An Object called Project Plan must be included
Relationship
Software Project Project Object No action
Project Team Agent and Role Object No action
Attribute Critical Path Not directly considered Can be obtained through a query
Milestones Not considered A new attribute in Project Plan Object must be
included
Phase Process object Distinguish between process objects and
activity
Planned Cost Project.Estimated Cost No action

parallel by a set of agents (called roles) that metrics for each process to objectively deter-
use previously defined types of material mine the process’s effectiveness.
resources. These processes use and/or ❚ Because we can define a project as a custom-
update a set types of products in order to ization of a set of software processes to build
meet objectives. They are defined as a set of a particular software system, the domain
I N F O R M A T I O N S Y S T E M S
S P R I N G 2 0 0 4
M A N A G E M E N T
83
 PROJECT MANAGEMENT

FIGURE 3 Software Project Management Framework

1..n
Requirements Risks Product
update 1..n
1..n 1..n 1..n
has has use
1..1 1..n 1..n 1..n
has
Technical has 1..1 1..n Project
Projects
Characteristics 1..n 1..n
1..n Activities
1..n 1..n
take part
Material
Human apply Resource
1..n is of
Resource 1..n
1..n
Processes is of
include
1..1 1..n 1..1
1..n
define
play Material
Metrics 1..n
has Resource Type
1..n

1..n 1..n 1..n 1..n 1..1

1..n use 1..n
1..n
Role 1..1 take part Activities Product Type
1..n 1..n update 1..n
1..1 1..1

precede contain
1..n

Component

model must permit information about a Software process improvement is a long

project to be stored. For each project, the
requirements allocated, the technical charac-
teristics that modify the requirements’ com-
plexity, and the risks related to the project
execution must be known. These technical
characteristics can be distributed functions,
data communications, performance, online
data updating, etc; and they are stored in the
Technical Characteristics class (see Figure 3).
❚ It is necessary to store information on
project tasks that come from the organiza-
tion. Standard software process customiza-
tion must be stored to maintain data on the
specific human and material resources and
the specific products used and developed
during the project. The information related
to the application of the metrics defined in
the organization’s software process is also
allocated in these classes.
See http://raul.ie.inf.uc3m.es/spm for more de-
tails.
CONCLUSION
Results of evaluations carried out worldwide
show that software process improvement —
and specifically, the improvement of software
management processes — is one of the key
challenges that organizations, in which soft-
ware is a vital part of business, face.
84 I N F O R M A T I O N
S P R I N G
and expensive process because experts are
needed and there are no tools or standard mod-
els to fully deal with it.
This research offers a software project man-
agement improvement framework. It provides
the model of the basic information structure to
define, implement, and improve the software
project management process.
The framework obtained will be useful for
those in charge of software process manage-
ment improvement: Project Managers, Soft-
ware Engineering Process group, or Quality
group.They can use the SPM framework to:
❚ Define a standard software project manage-
ment process that includes a complete
description of all the activities, products, and
roles that the organization must use to
develop its projects
❚ Design the software project process for
every project
❚ Elaborate the software project plan to deter-
mine the activities, their dependencies, the
products, and the roles included in the
project
❚ Store the results of the process management
projects
❚ Retrieve the information required for track-
ing
S Y S T E M S
2 0 0 4
M A N A G E M E N T
 PROJECT MANAGEMENT
❚ Retrieve the information managers require to
improve their software project management
process
In addition, we have just designed an appli-
cation whereby we can use the SPM frame-
work to define and support the software with
special attention to the specific goals of the or-
ganization. This application can also serve to
validate the framework defined.We plan to test
other aspects, such as the retrieval capacity
and the effectiveness of the relations of the
framework.
This software project management frame-
work has been successfully used in two soft-
ware organizations, so 79 percent of the
organization’s information needs about project
management were already represented in the
framework, and only 21 percent of the organi-
zation’s information needs had to be added
(García, 2001). ▲
Acknowledgments
This research was partially sponsored by the fol-
lowing companies: BBVA (www.bbva.es), CIRSA
(www.cirsa.com), ICM (www.comadrid.es), and
IIIS (www.iiis.es). We would also like to thank
the graduates from the Computer Science De-
partments of Carlos III University and Polytech-
nic University of Madrid for their collaboration,
Dr. W. Frakes from Virginia University and Dr. R.
Prieto who taught Domain Analysis in our Doc-
toral Program at Carlos III University.
References
1. Booch, G., Rumbaugh, J., and Jacobson, I. The
Unified Modeling Language. Addison–Wesley,
1999.
2. Euromethod Version 1.1 Euromethod Project.
July 1996.
3. García, J., Amescua, A., Velasco, V., and Sanchez,
M.I. How to Implement Domain Analysis.
Proceedings of the World Multiconference on
I N F O R M A T I O N S Y S T E M S
S P R I N G
Systemics, Cibernetics and Informatics, 2, 568–
573, Orlando, FL, July 2000.
4. IEEE Standard for Software Project Management
Plans, IEEE Std. 1058.1-1987. New York: Institute
of Electrical and Electronics Engineers.
5. ANSI/IEEE Std. 1074-1991. IEEE Standard for
Software Life Cycle Processes. The Institute of
Electrical and Electronics Engineers, New York:
IEEE Computer Society, 1991.
6. International Organization for Standardization,
ISO/IEC Std. 12207:1995 Information
Technology — Software Life Cycle Processes,
International Organization for Standardization,
Geneva, Switzerland, 1995.
7. ISO/IEC Std.15504. Software Process
Improvement and Capability dEtermination,
ISO/IEC/JTC 1, 1997.
8. Lawrence Pfleeger, Shari. Software
Engineering: Theory and Practice. Prentice
Hall, 1998.
9. Neighbors, J. The Evolution from Software
Components to Domain Analysis. International
Journal of Software Engineering and
Knowledge Engineering, 2(3), 325–354, 1990.
10. Paulk, M.C., Garcia, S.M., Chrissis, M.B., and
Bush, M. Capability Maturity Model for
Software, Version 1.1, CMU/SEI-93-TR-24.
Technical Report. Software Engineering
Institute, Carnegie Mellon University, 1993.
11. Paulk, M.C., Garcia, S.M., Chrissis, M.B., and
Bush, M. Key Process Area for Capability
Maturity Model for Software, Version 1.1,
CMU/SEI-93-TR-25. Technical Report. Software
Engineering Institute, Carnegie Mellon
University, 1993.
12. Software Engineering Measurement and Analysis
Team. “Process Maturity Profile of the Software
Community 2000 Year End Update.” Software
Engineering Institute, March 2001.
13. Fox, Terry L. and Spence, J. Wayne. “Tools of the
Trade: A Survey of Project Management Tools,”
Project Management Journal. September 1998.
14. Zipf, G.K. Human Behaviour and the Principle
of Least Effort: An Introduction to Human
Ecology. Haffner, New York. 1972.
15. García, J. Formal Approach to Software Process
Improvement. Ph.D. thesis. Carlos III University
of Madrid, November 2001.
2 0 0 4
M A N A G E M E N T
85