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

, 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

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

 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

“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.

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

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

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