A PROJECT MANAGEMENT MODEL TO A DISTRIBUTED
SOFTWARE ENGINEERING ENVIRONMENT
Lúcia Norie Matsueda Enami,Tania Fatima Calvi Tait, Elisa Hatsue Moriya Huzita
Department of Informatics, State University of Maringá, Colombo Avenue 5790, Maringá-Paraná, Brazil
Keywords: Project Management, Distributed Development, Global Software Development, Virtual Teams, PMBOK,
CMMI.
Abstract: This article presents a project management model (PMM) to a distributed environment that will be
integrated to the DiSEN (Distributed Software Engineering Environment). The model purpose is to supply
to the interested ones in the software project management the pertinent information and treat the aspects of
the team member’s physical distribution. It was based in PMBOK (Project Management Body of
Knowledge) and CMMI (Capability Maturity Model Integration) and the issues treated by the PMM include
cultural differences between the members, distribution of knowledge, a tool to facilitate the communication
between members, standardization of documents and motivating people geographically dispersed.
1 INTRODUCTION
The evolution of technology and the growing use of
Internet has been made possible the distributed
development of software (DDS). However, this
possibility requires an effective control of activities
related to software development that is treated by
project management.
Project management benefits organization, high
level managers, leaders, team members and clients
giving: more productivity, more profits, more
capacity in business solutions, better trust and
previsibility in the organization’s power, and more
satisfaction in doing the work (Cleland and Ireland,
2002).
Project management area has barriers, such as:
the organizational culture, conflicts, lack of
communication and the need of manager’s ability.
More specifically, in the software project
management area there are more difficulties to
management, such as: changing technology, turn
over of people with specific abilities about the
technology and the intangibility of software that
makes necessary the creation of artifacts and
documentations to evaluate it. With the physical
distribution of team members, all of this becomes
more complex because of the cultural differences
and communication difficulties.
In the construction of DiSEN
1
, it becomes clear
the needing of a project management model (PMM)
to fulfill the lack related to software project
management. This article presents a PMM to a
distributed software engineering environment.
This article is organized as follows: the section 2
presents DiSEN, the section 3 describes the PMMs
found in literature that provides the base to the
proposed PMM with a comparison between them.
The section 4 presents PMM proposed to DiSEN
and the last section the final considerations.
2 DISEN
To treat the DDS giving support to the project
management, DIMANAGER tool and a mechanism
to aid the selection of human resources were
developed to DiSEN.
DIMANAGER aids the project manager to plan
and control projects in an environment with DDS. In
DIMANAGER, it is possible to register: general
information of projects, project activities, the human
resources and duration associated to each activity,
the effort in man-hour to execute the activity and the
technical and organizational problems that can occur
in the activities executions (Huzita et al., 2004).
Besides, it is possible to get managerial information
by reports and graphics.
The mechanism developed aids the project
1
DiSEN = project in execution at Informatics
Department of State University of Maringá
(HUZITA, 2004).
382
Norie Matsueda Enami L., Fatima Calvi Tait T. and Hatsue Moriya Huzita E. (2006).
A PROJECT MANAGEMENT MODEL TO A DISTRIBUTED SOFTWARE ENGINEERING ENVIRONMENT.
In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 382-387
DOI: 10.5220/0002447903820387
Copyright
c
SciTePress
manager to select the person with best ability to
develop each activity in project (Huzita et al., 2005).
The work, that have been done, will contribute to
formalize a PMM to the DDS because they
undertake specific functions related to project
management such as coordinating, organizing,
controlling and leading.
3 PMM
A PMM is a way to represent the project
management in a high level of abstraction and
according to Cleland and Ireland (2002), it guides
the project manager in using a systematic approach
to manage projects efficiently.
Among the analyzed models, we considered: the
PMBOK (PMI, 2000), the CMMI (SEI, 2002), the
PMM based on PMI (Project Management Institute)
to a software development environment physically
distributed (Zanoni and Audy, 2003) and MuNDDoS
(Prikladnicki et al., 2004). A brief description about
each of them is given next.
3.1 PMBOK
This model is divided in nine knowledge areas (PMI,
2000) composed by processes: 1) Integration
Management; 2) Scope Management; 3) Time
Management; 4) Cost Management; 5) Quality
Management; 6) Human Resource Management; 7)
Communication Management; 8) Risk Management;
and 9) Acquisition Management.
Each of the processes has inputs, tools and
techniques. The processes were categorized again in
five groups to get a better visualization of when to
execute each process. They are: initialization,
planning, executing, controlling and closing.
3.2 PMM Based on PMI
The main characteristics of this model are: 1) The
spiral life cycle; 2) The use of OO paradigm, with
UML (Unified Modeling Language) and the UP
(Unified Process); and 3) Incorporate the PMBOK
extending the knowledge areas in more four areas.
The extensions proposed to the PMBOK (PMI,
2000) are: 1) Planning Management: A strategic
planning will guide the business to a future-oriented
work and a operational management will be
responsible by the goals execution; 2) Intellectual
Property Management: to care about the legal issues
of copyright; 3) Learning Management: to care
about the creation of mechanisms to transform the
individual knowledge in an organizational
knowledge; 4) Conflict Management: to solve the
conflicts generated by the cultural differences and
the physical distance between the project team
members.
3.3 CMMI
It was considered as a PMM because it treats the
processes that are related to the development of
software, what includes project management. This
model aims to evaluate and guide the organizations
to get capability and maturity in software
development and is composed by five levels of
maturity (SEI, 2002). They are: 1) Initial: the
success depends on the competence of people. The
organizations in this level produce products and
services that work but exceeds the budget and time
of their projects; 2) Managed: the processes are
planned, executed, measured and controlled. The
products and services of work satisfy the requisites,
standards and goals specified for them; 3) Defined:
the processes are documented, standardized,
integrated and specified under-measure to the
organization; 4) Quantitatively Managed:
quantitative measures are made, stored and
statistically analyzed to give support to decisions
fact-based; 5) Optimized: the process is improved in
a continuous way with the quantitative knowledge of
process and using innovated ideas and technologies.
Each of these levels has process areas that have:
specific and generic goals and specific and generic
practices.
3.4 MuNDDoS
MuNDDoS (Prikladinicki et al., 2004), is a
reference model to evaluate and guide the
organizations to get maturity in the DDS. It is
composed by three cycles: 1) Strategic Planning:
composed by the following workflows:
identification of new project and project´s allocation
to the distributed sites; 2) Tactic/operational
planning: where the project is developed; and, 3)
Knowledge: composed by project’s evaluation and
feedback workflow.
It presents the processes and issues to be treated
in the DDS to the three cycles.
This model like CMMI is divided in four levels:
initial, basic, planned and optimized. Each level is a
foundation to the next. In the initial level, only the
process of reception of new projects exists. In the
basic level, to develop projects, all the issues
presented by the model are considered. In the
planned level, the strategic and tactic/operational
planning cycles exist and in the optimized level, the
knowledge cycle is included.
A PROJECT MANAGEMENT MODEL TO A DISTRIBUTED SOFTWARE ENGINEERING ENVIRONMENT
383
3.5 A Comparison Between the
Project Management Models
Table 1 shows a brief comparison between the
PMMs presented.
PMBOK (PMI, 2000) may be used to all projects
and presents: the tools and techniques that are a
consensus to the project management community.
CMMI (SEI, 2002) may be used to software projects
and guides the organizations to get maturity and
capability reaching the levels one through five. It
presents the goals and practices that must be
reached.
The PMM based on PMI to a software
development environment physically distributed
(Zanoni and Audy, 2003) aims to treat the physical
distribution of project team members with the four
extensions proposed and it is useful to software
projects that intends use UML and UP in a
distributed way.
MuNDDoS (Prikladnicki et al., 2004) evaluate
and guide the organizations to get maturity in the
development of software in a distributed way and
presents relevant issues that must be considered in a
distributed environment.
The four models presented can be used in DiSEN
in a different way: PMBOK is more generic and can
be used in projects of all areas. CMMI, the PMM
based on PMI and MuNDDoS have specific
characteristics applicable to the software
development and the PMM based on PMI and
MuNDDoS are applicable to projects in a distributed
environment.
4 THE PROPOSED SOFTWARE
PMM
The PMM proposed to DiSEN considered issues
related to project management area, software project
management area and issues related to physical
distribution of team members. Besides this, the
model considered the works developed in DiSEN
related to project management. The proposed PMM
includes: 1) PMBOK (PMI, 2000); 2) the intellectual
property management proposed by Zanoni and Audy
(2003); and, 3) the strategic workflows proposed by
Prikadnicki et al. (2004). Besides this, the PMM
presents solutions to treat the cultural differences,
communication problems, knowledge distribution
and standardization in a distributed environment.
4.1 Determinant Elements to the
Proposed PMM
The determinant elements to the PMM was: 1)
Identify the users of DiSEN and the information
required to manage the projects; 2) Determinate a
database with project information to each user; 3)
Use PMBOK as a reference; 4) Use CMMI to
construct a basic structure to allow the organizations
achieve level 2; and, 5) Create models of documents
to facilitate managing projects.
The users categories and information identified to
each one are: a) Clients: that would like information
about the project progress; b) Developers that need
information about their schedule and the situation of
artifacts and material resources; c) Project managers
who need information to plan, control, motivate,
lead, drive and organize the project; d) General
managers that need information about the
performance of the project managers and the
situation of projects under their supervision; e)
Managers who are responsible by the project
portfolio management that need information to
select, evaluate and prioritize the projects (Reyck et
al., 2005) and f) Group managers, cited as caretakers
(Powell et al., 2004), that manage each dispersed
group and execute functions that have better results
if done face-to-face. This kind of manager needs
information to motivate and lead team members.
Each user category in the project will supply and
receive the information in a standard way.
PMBOK was used to understand issues related to
project management area and identify solutions to
DiSEN.
CMMI-Level 2-Defined was used to: develop a
basic structure that supports the organizations using
DiSEN to get level 2 and to create document models
to facilitate the communication between team
members and the information searching.
The PMM proposed differs from the models
studied in presenting a vision of project management
in a distributed software engineering environment
that: 1) Emphasizes an initial training
to minimize the communication problems; 2)
Concerns with the project knowledge distribution;
3) Points out the need of more functionalities in
DiSEN; 4) Presents document models to facilitate
standardization; 5) Suggests the “group manager” to
manage each group geographically dispersed.
Figure 1 shows the DIMANAGER tool provided
by DiSEN. Everyone in the organization will receive
the information registered in the repository through
DIMANAGER. The use of DIMANAGER will
standardize the documents provided.
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
384
Table 1: Comparison between the PMMs.
Model
Element
PMBOK CMMI
PMM Based on
PMI
MuNDDoS
Goals
Present the “best
practices” in Project
Management
Evaluate the capacity
and maturity of
organizations
Present a project
management vision
to an environment
with DDS
Present a reference model
to a DDS
Components
9 knowledge areas:
1. Integration, 2. Scope,
3. Time, 4. Cost, 5.
Quality, 6. Human
Resources, 7.
Communication, 8. Risk
and 9. Procurement.
5 Groups:
1. Initiation, 2.
Planning, 3. Execution,
4. Monitoring and
Controlling and 5.
Closing.
The 9 knowledge areas
and the 5 groups are
composed by the same
processes.
5 levels: Initial,
Managed, Defined,
Quantitatively Managed
and Optimized.
Each level has process
areas composed by:
specific goals with
specific practices and
generic goals with
generic practices.
6 phases: requisite
analysis, project,
production,
evaluation,
transition and
integration.
The 9 knowledge
areas of PMBOK
and 4 extensions:
Planning,
Intellectual
Property, Learning
and Conflict.
5 levels: initial, basic,
planned, optimized. Each
level has some of the
following workflows: (1)
identification of new
projects; (2) projects
allocation in the
distributed sites; and , (3)
evaluation and feedback
To develop projects, 5
categories are considered:
Process, Project,
Stakeholders,
Organization and
Dispersion. Each category
has relevant aspects to be
considered.
Tools,
Techniques
and
Methodo-
logies
Each process has tools
and techniques
suggested to execute the
process.
In some practices, there
are tools and techniques
suggested.
Spiral Life Cycle,
UML (Unified
Modeling
Language), e UP
(Unified Process)
-
Outlets
Each process has outlets
that usually are the
entries to another
process.
Each process area
presents a list of
products to be
delivered.
Artifacts specified
in UML e UP
A roll of projects: to be
developed; candidates to
distribution; that can be
distributed.
Sites that can develop
each project.
Developed
by
“Consensus” of the
project management
community
Industry Organizations,
Government and SEI
(Software Engineering
Institute)
Zanoni – Study
Case
Prikladnicki – Study Case
Coverage
To all projects To software projects To projects that
intend to use UML
and UP in the DDS.
To projects that intend to
use DDS.
4.2 Initial Training
An initial training is proposed to be applied to team
members to minimize the problems with
communications which can arise because of the
cultural differences involved. The problems that can
occur were related by Carmel apud (Olson and
Olson, 2004) and include: the way they consider
hierarchy and the form they manifest it; their
individual goals; the relevance of the job for people;
the quantity of risk avoidance; how long they work
future-oriented; and, the way they consider deadlines
and make deals.
The initial training will be focused in: 1)
Communication: how, who, when, how many times,
by what mechanism it will be done; 2) DiSEN: It is
necessary that team members know DiSEN to use
the environment in an appropriate way; 3) Cultural
differences: the involved cultural differences may be
understood to create a standard way to know the
A PROJECT MANAGEMENT MODEL TO A DISTRIBUTED SOFTWARE ENGINEERING ENVIRONMENT
385
meaning and avoid or minimize problems; 4)
Organizational structure: showing who is
responsible and have the authorization in making
decisions is important to give direction to team
members.
4.3 Knowledge Distribution
The project detailed information may be stored in
the local repository of DiSEN where it was created,
and the general project information may be stored in
the global repository. This type of distribution was
presented by Desouza and Evaristo (2004) because
the detailed information, such as: timesheets,
milestones, meeting minutes and training manuals
does not interest to most of people in the
organization and, in many cases, needs to be updated
daily what can result in high network traffic and
irrelevant search results. On the other hand, the
general information such as: project team members,
deadlines, cost and benefit analysis, customer
commitments and expectations and post hoc analysis
information interest everyone in organization and
doesn’t need the daily updating what makes it more
useful to be centralized.
The general information of projects can be
accessed in a centralized repository that serves as an
index and if someone is interested in detailed
information, it can be accessed in the local
repository where the project was created and
updated.
4.4 More Functionality in DiSEN
To control the project information in a distributed
environment, it is necessary to register and control
more information about the project, such as: the
distributed places involved, the human and material
resources of each distributed place registered in
DiSEN; the responsability/authority of the people
involved in the project; knowledge, ability and
training of team members; and, cultural issues of
everyone in organization.
DiSEN supplies these functionalities giving support
to the software project management in a distributed
environment. It standardizes the way to store and
retry information about the project.
4.5 Motivation
To give the motivation to each team member and
reward each one appropriately, the group manager
must know what are his/her needs. The people needs
in the Maslow Hiearchy are presented in five levels
(CLELAND and IRELAND, 2002): 1) Basic and
physiologic needs; 2) Security needs; 3) Social
needs; 4) Self-esteem and Status needs; and 5)
Solemnity-accomplishment needs.
The individuals had values and needs that differ
from each other. And to get this information, an
initial questionnaire was suggested to be applied.
O
R
G
A
N
I
Z
A
T
I
O
N
Figure 1: Supply of Information for the Management of Projects in DiSEN.
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
386
4.6 Document Models
To facilitate the comprehension of project
management, a standardization of document models
is supplied. The document models proposed include
those that refer to CMMI at level 2-Defined (SEI,
2002): requirements management, project planning,
monitoring and control, supplier management,
measurement and analysis, product and process
quality assurance and configuration management.
The document models standardization will
contribute to process quality facilitating the search
of project information since everyone must know
where it will be.
5 FINAL CONSIDERATIONS
To validate the proposed PMM, a prototype will be
developed and a questionnaire will be applied to
project managers to evaluate issues related to project
management and another one will be applied to
DiSEN team members to evaluate the accordance
with the environment.
Further, the collection and storing of the type of
solution given to a specific problem like done by
Strafacci (2002) will make possible to generate a
specialist system in project management which will
help the project manager to make decisions in
projects.
ACKNOWLEDGMENTS
Thanks to CNPQ for financial support.
REFERENCES
Cleland D. I.; Ireland L. R., 2002. Project Manager´s
Portable Handbook, McGraw-Hill. New York.
Desouza, K. C.; Evaristo, J.R., 2004. Managing
Knowledge in Distributed Projects. Communications
of the ACM, 47(4), p.87-91.
Huzita, E.H.M., 2004. Suporte à Reutilização em
Ambientes Distribuídos de Desenvolvimento de
Software. Projeto de Pesquisa em Desenvolvimento
(CNPq) no Departamento de Informática –
Universidade Estadual de Maringá. Paraná. Brasil
Huzita, E.H.M. et al., 2004. DIMANAGER: A Tool for
Distributed Software Development Management. In:
ICEIS´04 6
th
International Conference on Enterprise
Information System Porto-Portugal. Portugal: ICEIS
Press, 659-662.
Huzita, E.H.M. et al., 2005. Um Mecanismo de Suporte ao
Gerenciamento de Recursos Humanos no
Desenvolvimento Distribuído de Software [CD-
ROM]. Concordia-EntreRios-Argentina Available
from: CACIC-Congreso Argentino de Ciencias de la
Computación.
Olson J.S.; Olson, G.M. 2004. Culture Surprises in
Remote Software Development Teams. ACM Queue,
1(9), 52-59.
PMI, 2000. A Guide to the Project Management Body of
Knowledge. Pennsylvania-EUA: Project Management
Institute Publications.
Powell, A. et al., 2004. Virtual Teams: A Review of
Current Literature and Directions for Future Research.
The DATABASE for Advances in Information Systems,
35(1), 6-36.
Prikladnicki, R. et al, 2004. A Reference Model for Global
Software Development. In: PRO-VE at 18
th
IFIP
World Computer Congress, 22-27 August 2004
Toulouse-France. Toulouse-France: Kluwer, 369-378.
Reyck B.D., 2005. The Impact of Project Portfolio
Management on Information Technology Projects.
International Journal of Project Management [online].
23(7). Available from: http: //www.sciencedirect.com
[Accessed 10 Oct 2005].
SEI, 2002. CMU/SEI-2002-TR-011-Capability Maturity
Model Integration, version 1.1, Staged Representation
[online]. Carnegie Mellon University. Available from:
http://www.sei.cmu.edu/ [Accessed 15 Apr 2005].
Strafacci, V. J., 2002. Uma Metodologia de Gestão para o
Desenvolvimento de Software, Tese (Doutorado).
Instituto Tecnológico de Aeronáutica.
Zanoni, R.; AUDY, J.L.N., 2003. Project Management
Model for a Physically Distributed Software
Development Environment. EMJ Special Issues-
Engineering Management Journal [online].Special
Issue on Project Management in Information Systems
and Technology. Avaiable from:
http://csdl.computer.org/comp/proceedings/hicss/2003
/1874/08/ [Acessed 20 Jul 2005].
A PROJECT MANAGEMENT MODEL TO A DISTRIBUTED SOFTWARE ENGINEERING ENVIRONMENT
387
