1 - Web Pages



Project Proposal

Distributed Project Management

by

Passakon Prathombutr

Ashok Emani

CS551 Fall 2001

CSTP UMKC

Contents

Introduction 3

Project Goal and Objectives 4

• Overall goal 4

• Specific objectives 4

• Significance 4

Project Background 5

General Plan of Work 6

• Requirement 6

• Design of activities to be undertaken 6

• Description of methods and procedures 8

• Technologies and Tools 10

• Time table for project completion 11

Bibliography 12

Introduction

A major factor in the successful launch of the company is the early implementation of quality project management. Today project management software provides a variety of "views" of project data, including Gantt charts and Critical Path Networks and is particularly strong in resource modeling, tracking and scheduling.

However, traditional project management tools are still based upon a single-user model of planning. For example the MS Project model is a project management tool that a single general contractor makes decisions and changes then somehow notifies the people involved. The notification is done by a simple note corresponding to each task. If the users in the group want to share the schedule, they can do so by exchanging a print out or uploading the schedule onto the web page or simply use a primitive email. The main problem is that users are distributed while the recourses are standalone and those notification methods are not integrated well to the project management tool.

In another aspect, if the management groups spread over geographic distances with multiple centers of control and multiple software environments. Not only the users that are distributed but also the projects themselves. The projects may be located in different departments, different cities. Then the communication and coordination become key issues for project success. There are several solutions to communicate among “distributed” components. But what is the best solution to deploy the advantage of distributed computing onto the project management; like scalability, openness, reusability, heterogeneity, resource sharing, fault tolerance and etc? In this project, we propose the idea of Distributed Project Management (DPM) tool using Java and a standard middleware “CORBA”, Common Object Request Broker Architecture. CORBA supports heterogeneous and distributed objects. Communication between objects is achieved through an object request broker, which aims to hide heterogeneity and distribution as far as possible. In fact, there are plenty of middleware in the market like COM or EJB but we select CORBA because it is a reliable standard one. Even the EJB also supports the CORBA interface. Besides, the CORBA when integrates with the existing computer systems guarantees that the investment is risk free.

The DPM will eliminate the stand-alone problems by providing interface to communicate between users and projects, which are in various platforms/environments. The obvious examples are that the group member on Macintosh can share the scheduling with project manager using MS Windows or user in city A can have a common project with user in city B communicated via the Internet.

The DPM tools include components that facilitate team collaboration and communication. They typically include features, such as project scheduling, bulletin board and document sharing system. When people and technology work in harmony, DPM software offers several significant benefits, including: shorter project cycle times (time savings) and improved teamwork/group communications.

Project Goal and Objectives

Overall goal

The overall goal is to provide distributed project management in term of:

• Interoperability i.e., supports cross functions between multiple platforms/environments,

• Resource-sharing among team members in the project group,

• Scalability of the project component, since the component can be extent and reused,

• Portability of the project management system that can run in multiple contexts.

Specific objectives

• A distributed project management tool using facilities of Object-Oriented middleware, CORBA and Java.

• Design distributed object based on UML representations.

• DPM which resolves heterogeneity in term of user and server environments. In this project, there are two platforms of software environment, the LAN PC running Windows 2000 and Linux.

Significance

• The security is based on the CORBA security. Assume that no significance security requirement at this project.

• The distributed project management will be implemented based on the Text mode at the beginning since we pay attention on the middleware. Because of the limitation of time scale, the graphic user interface using Java will be partially implemented if necessary.

• Implement CORBA using VisiBroker v 4.5.(Evaluated version)

• The environments are PC based with MS Windows 2000 and Mandrake Linux Operating System. This program is not intent to be used outside CSTP UMKC computer labs.

Project Background

The Distributed Project Management DPM is not a new term. There exist a bunch of DPM packages in the market today. [1] survey results indicate that over 40% of all projects in the Fortune 1,000 are performed in an environmentally distributed setting. Co-location, once the norm, appears to be in rapid decline. [1]’s research indicates that only 15% of projects are undertaken in an environment where more than three quarters of the project stakeholders are located in the same physical location. [1] also states that Microsoft is the de facto standard for Project Management today in the Fortune 1,000. Just over three-quarters of all respondents indicated that Microsoft Project was at least one of the tools they utilized to complete their projects. In our project, we also apply some basic functional requirements from the Microsoft Project.

[1] have categorized the Project Management vendors profiled into four relatively broad categories. These vendor groups are:

1. Stand-Alone Vendors require 'thick client' software on all end user PCs and/or workstations, and are entirely self-supported DPM tools. These tools are broad-reaching suites, with a robust scheduling engine at their core.

2. Web Portal-Oriented Vendors are Web portals offering DPM capabilities through a standard Web browser ('thin clients'), and which utilize an ASP approach. They are not native critical path tools and usually focus on collaboration, document management, and tracking issues.

3. Hybrid Model Vendors support both thick and thin versions, and often offer traditional software licenses as well as ASP delivery of DPM services. These tools do typically support CPM natively.

4. Microsoft Project Extension Vendors are essentially 'shells' that use Microsoft Project as a plug-in for scheduling and resource management capabilities, and which add functional modules around it.

As we have seen, the DPM tools are relied on the Web or ASP approach. The Microsoft Project Extension is a plug-in for scheduling and some capabilities but not clarify in the “distributed” capabilities. They do not deploy the benefits of distributed computing. What we propose is the DPM based on the middleware capabilities. We would probably classify our project in category 2 but actually we do not require web technology for communication. The middleware should take the responsibility of all communication functions.

Unlike the Java applets or Java RMI client/server found in [2]. They developed the commercial project management tool called ActionPlan. The ActionPlan is 100 percent Java-based application from Netmosphere that supports real-time collaboration among Java thin clients to facilitate distributed project management. Java clients enable real-time data manipulation of project information on the Gantt view graphical user interface. This functionality would not have been possible using just only HTML. The ActionPlan has a nice look of GUI using Java applets. By its characteristic I would classify it as the second category, Web Portal-Oriented Vendor.

In our project, we design the DPM using the concept similar to ActionPlan. There are two groups of users, project leaders and group members. The project leader is able to setup and control the project. The group members are able to view and update the project assigned to them. The problem is how the member knows that he was assigned to the project and how many projects in his hand. The ActionPlan solved this problem by providing a check-in/check-out model for accessing the project management system. The sever has a detail of work assignment, so it know what projects the user is participated, then it can present his project schedule. In our design, when user logs in, we provide the function to lookup all the project components and find out the project that belong to him. Another solution that could be possible is the use of XML to keep track of the list of projects for users. This solution will be left for the future work.

The basic functions and resources of the Project Management are gathered from [3] and [4].

General Plan of Work

Requirement

• A distributed project management using the facilities of CORBA middleware e.g., its transparency. The client and server sides are multiple platforms and locations.

Design of activities to be undertaken

• Support three main functions of project management; scheduling/tracking system, messages board/bulletin board and file-sharing system. These functions are services of a project component. A project component can be distributed and duplicated over the network. Figure 1 presents the Distributed Project Management Collaboration.

Figure 1 Distributed Project Management – Collaboration

• Support two priority groups of users, the project manager/leader and the group member. The project manager/leader has the rights to manage the projects e.g., create schedule while the group-members update their work progress. These users are distributed over the network and invoke the services in the project components (see Figure 2 and 3).

Figure 2 System Context

Figure 3 Project Components

Figure 4 DPM – Distributed Architecture

Description of methods and procedures

The methods and procedures in Distributed Project Management are described below,

Schedule Manager:

|Name: Create_Project |

|Description: Can be called only by Project Leader, creates a new project |

|Comments: Returns a reference to the created ‘project’ object |

|Name: Delete_Project |

|Description: Can only invoked by project leader, Deletes the project specified. |

|Comments: Takes a reference to ‘project’ object as argument |

|Name: Set_Startdate |

|Description: This Method sets the starting date of the project. |

|Comments: Takes a reference to ‘project’ object as argument, and ofcourse the date |

|Name: Set_Finishdate |

|Description: This method sets the finish date of the project that is the deadline for |

|completion of the project. |

|Comments: Takes a reference to ‘project’ object as argument, and date |

|Name: Create_Task |

|Description: This method creates a task entry with all details like starting and ending |

|point, description, allotment, notes. |

|Comments: Takes a reference to ‘project’ object as argument, and the complete information of |

|the task |

|Name: Modify_Task |

|Description: This method modifies a predefined task, according to the arguments supplied |

|Comments: Takes a reference to ‘project’ object as argument, and required modified values |

|Name: Add_Member |

|Description: This method associates the given team member to the project specified. |

|Comments: Takes a reference to ‘member’ object and ‘project’ object |

|Name: Delete_Member |

|Description: This method dis-associates the given team member from the project specified. |

|Comments: Takes a reference to ‘member’ object and ‘project’ object |

|Name: Display_Schedule |

|Description: This method displays the schedule for the specified project in different views |

|based on the arguments supplied |

|Comments: Takes a reference to ‘project’ object and the type of view needed |

Bulletin Board

|Name: Post_BB |

|Description: This method posts the given message to the specified bulletin board. |

|Comments: Takes a msg in a buffer and project reference. |

|Name: View_BB_date |

|Description: This method allows the caller to view the bulletin board messages posted on a |

|particular date.. |

|Comments: Takes a reference to ‘BB’ object and the date. |

Project Repository (File-sharing system)

|Name: Put_File |

|Description: This method stores the given file in the repository associated with the project |

|and sets the type of the file {presentation, object model, diagrams, source code, binary |

|etc.} |

|Comments: Takes a reference to ‘project’ object, the file, and the type |

|Name: Get_File |

|Description: This method returns the file requested, from the specified project repository. |

|Comments: Takes the ‘project’ reference and the file name. |

| Name: View_Repository |

|Description: This method displays the available files in the repsoitoy, the display can be |

|limited to particular file type or all the files can be displayed |

|Comments: Takes a reference to repository and file type {default: ALL} |

Technologies and Tools

• Technologies: Java/CORBA

CORBA is the well-know and widely adopted by nearly 800 industrial companies which are the member of the Object Management Group (OMG). It is available on every major operating system, and is able to bind to a Java language. It provides interoperability that uses IIOP to retrieve and manipulate objects obtained from a remote ORB between different vendors. Moreover the CORBA when integrates with the existing computer systems guarantees that the investment is risk free. The new components can be easily added to the existing ones.

• Tools:

o Software: VisiBroker 4.5, Ant 1.4, JDK 1.3 and Jcreater.

o Hardware: PC running Windows 2000 and Mandrake Linux 8.0.

5 Time table for project completion

The project schedule contains three main parts; system design, Implementation and Testing. The duration and task decompositions are displayed below.

[pic]

[pic]

Bibliography

[1] .

[2] Ly E., Distributed Java Applets for Project Management on the Web, IEEE Internet Computing, May-June 1997, pp 21-26.

[3] , “Project Management Institute”, September 2001.

[4] , “Information-Driven Project Management”, September 2001.

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

PO

PO – Project Object

BB – Bulletin Board

SM – Schedule Manager

PR – Project Repository

Project Repository

Project Leader

Team Members

(can be multiple)

Bulletin Board

Schedule Manager

PR

SM

BB

Manager Interface

Member Interface

Member Interface

Project Members

Project Members

Project Leader

Project

Component

Post/view

Create/Delete/Post/view

Schedule

Manager

Project Member

Project Leader

Bulletin

Board

Repository

Create/Delete/Modify

get/put/create

Put/get

View/Update

MI

MI

MI

MI

MI

LI

LI

Project N

(New York)

Project 1

(Dallas)

MI – Member Interface

LI – Leader Interface

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download