project life cycle management.doc

MASTER’S PROJECT REPORT

Spring 2006 (CS 698)

Project Life Cycle Management System

ADVISORSDr. Irwin Levinstein

Mr. Ajay Gupta

PRESENTED BYNageswara Rao SripathiStudent ID: @00074301

[email protected]

DEPARTMENT OF COMPUTER SCIENCEOLD DOMINION UNIVERISITY

mailto:[email protected]

ABSTRACT

Project Life Cycle Management System (PLMS) aims to simplify the process of

managing an IT Project by consolidating all the project information in one place. This

system will help track the different stages of an IT project including – Risk Analysis,

Requirements Gathering, Development, Testing and Maintenance. The typical users of

this tool will be – Project Managers, Business Analysts, Project End-Users, Developers

and Testers.

Document Management module of this application is integrated with all of the project

phases. Users can check-in, check-out , set access controls and manage all the

documents of the project using this module.

The tool has been developed using a three-tier architecture comprising of interaction

between the client, the web server and the database server. The front-end has been

developed using the ASP.NET framework in Microsoft Visual Studio. The middle tier has

been coded in C# and the application is hosted on IIS web server. MS SQL Server

database used. A combination of triggers, stored procedures and views has been

developed to reduce the load on the web server.

1. INTRODUCTION

Every IT Project implementation goes has the following stages –

Feasibility/Risk Analysis

Requirement Analysis

Development

Testing

Maintenance

Having worked in different roles in Project implementations in different phases of the

Project Lifecycle, I have noticed that a single tool, which can keep track of the whole life

cycle of the project is a critical ingredient for the success of the project.

Information management in a project implementation, spread across different

geographical locations and involving hundreds of people is not an easy task. For

example – at my current client, Risk analysis was done before the project, but mostly

through emails, requirements were gathered from users and converted into requirements

for the application, but in excel sheets. Development was tracked but in MS Projects and

Bugs where reported, but in a different web based application.

So to know the current status of the project, a Project Manager would have to look

through multiple databases and work with multiple applications. And a person on the

road, and people sitting in different locations did not have access to the excel files sitting

in network drives in the centralized location.

The Project Lifecycle Management System, solves this problem by providing a single

point of access to collect and manage all this information.

2. PROCESS FLOW

The following section talks about the different kinds of users, who use this system and

the logical flow of data in the system.

Admin

The System Administrator will have the ability to create new projects and add users to

the project.

Typical Users: System Administrator

User

This tool is designed to work with multiple projects. Hence when a user logs in, the user

will have to select the project that he wants to work on.

Typical Users: Project Manager, Developer, Tester, End-User

Modules

The system will be divided into the following Modules –

1. Risk Analysis / Delphi Study

The user will be able identify the different risks associated with the project, through an

iterative process of getting input from various project users. The risks will then be

validated, filtered, ranked and rated until consensus as determined by Mathematical

formula.

Log InSetup New

ProjectCreate Users

Assign Project to

UserSet User Access

Log In Select Project

System shows modules that

user has accessSelect Module

Delphi Methodology has been used to identify the major risks. According to this, the Risk

Analysis process is divided into 5 major Phases – with a minimum of 3 completed

Phases.

Phase I

IT Managers and Business Analysts in different locations and depts., who have an

interest in the project, log into the system and enter the risks that they think pose the

greatest threat to the project.

4 types of risks/barriers are identified in Phase I -

Set Up Barriers

Data Collection Barriers

Data Analysis Barriers

Knowledge Sharing Barriers

A Delphi Process Administrator will then login and eliminate duplicate risks and

consolidate the barriers/risks entered by different users. He will then activate Phase II.

Phase II

The users identify the top 20 risks of all the risks entered in Phase I.

The Delphi Admin will then activate Phase III of the process, there by triggering a

process, which carries the top 20 risks, selected by the most users, into the next phase.

Phase III

In this phase the users rank (relatively) and rate (absolutely) the importance of each

barrier. The most important barrier is the one that most inhibits the project. The barriers

are listed in decreasing order based on the percentage of panelists who included them in

their top twenty selection.

The users rank the barriers from 1-20, with 1 being the most important and 20 being the

least important. Ties are not allowed in this phase and all ranks should be used.

The users rate the importance of each barrier on a 9-point scale (1-9 with 1 being least

important, 9 being most important and NR indicating not rated). For this scale, there

may be ties (for instance, any number of items could be rated as “8”). However, the

rating should be consistent with your ranking.

The users also need to explain the reason for choosing their top barrier.

The Delphi Admin will check the Kendals W (a mathematically computed value, based

on the ranking of the users) at this time. If it is less than 0.5, he activates Phase IV,

where the same process is repeated. The top 20 barriers with the highest average rank

are carried forward from Phase III to Phase IV.

Phase IV

Phase IV is a repetition of the previous step to get a better Kendals W value. The user,

though, is now equipped with more information, including responses from the remaining

members of the group.

The Delphi Admin will check again check Kendals W after this phase. If it is below the

required value, he activates Phase V. 20 barriers with the highest average rank are

carried forward to PhaseV.

Phase V

Phase 5 also requires the user to rank the barriers, but this time, the user is provided

with the standard deviation of his rank from the average rank. The highlighted barriers in

this Phase indicate where the user differs most from the other people in the group. This

will help the user, to put the barriers in a better perspective and make any changes, if

he/she thinks necessary.

Typical Users: Project Managers, Business Analysts

Identify Risks

Review Risks / Add

missing Risks

Select top 20 Risks

Rank & Rate Risks.Repeat until Phase 5 or Kendals W > 0.5.

2. Requirement Analysis

The requirements for a project come from different business users / depts. in the

Organization. Not every requirement can be feature of the implemented IT System. The

Project Management team identifies the Requirements that are feasible and incorporate

them as Requirements for the Project. The Requirement Analysis Team develops use

cases to expand on the requirements. The use case will break down the requirements by

giving more details.

For ex: If there is requirement to create a Purchase Order, the use-case will include

steps that say – Create a Purchase Order by selecting the Vendor, Item, Cost etc. Save

the Purchase Order and submit it for approval and so on.

Some of the requirements may require custom development. For ex: Puchase Orders

with a dollar amount below $500 in Location A should be automatically approved, while

the rest should be routed to the Manager. This would require development of a

Purchasing Approval Workflow.

Such requirements can be marked as requiring Development. These requirements can

then be tracked in the development module.

Typical Users: Business Analyst, Stakeholders

3. Development

The requirements that need custom development can be assigned to principal

developers. The progress on development – in terms of percent complete also can be

updated.

Enter Business Requests

Enter Requirements.

Identify Development

Req.

Map Requirem

ents to Business Requests

Enter Use case

details

Map Use cases to

Requirements

Upload supporting documents

Any supporting documentation, including Technical Specification Documents can be

attached in this module.

Testing

Typical Users: Project Manager, Developer

4. Testing

All development objects can be assigned to principal QA testers in this module after the

development is complete. The progress of testing can also be tracked.

Any supporting documentation, including Test Plans and Results can be attached in this

module.

Typical Users: Project Manager, Developer, Tester

Show completed Dev. Items

Select Dev Item

Assign Tester &

Enter Details

Upload Supporting

Docs

Show Items under Testing

Select Testing Item

Update Percent

Complete & Status

Upload Supporting

Docs

Show new Development

ReqsSelect

Requirement

Assign Developer & Enter Details

Upload Supporting

Docs

Show Items under

DevelopmentSelect Dev.

Item

Update Percent

Complete & Status

Upload Supporting

Docs

5. Maintenance

The users will have the ability to enter bugs in this module. The entered bugs can be

assigned to developers and the progress and updates on the bugs can be tracked. The

bug history can also be viewed.

Any supporting documentation, including screen shots of bugs can be attached in this

module.

Typical Users: Project Manager, Developer, Tester, End-User

6. Document Repository

As mentioned above, the document repository is integrated into each of the modules.

Documents can also be attached at the project level. Once the documents are uploaded,

view / download access can be given on these documents to other project users. Only

one user can work on a document at any given point of time. Once a document is

checked out, no other user can check out this document. Only the person who has

checked out the document and check it back in. The Check-in / Check-out history of the

document can also be viewed.

Owner

EnterNewBugs

Show existing

BugsSelect Bug

Upload Supporting

DocsUpdate

Bug Details

SelectProject

Select Module

UploadDoc

Grant Access to

Users

SelectProject

Select Module

View Docs Listing

View/Delete Docs

Owner / User

7. Reports

The system will provide the following reports depending on User Access.

The homepage of every module will display the current status report.

The following reports are available –

1) Project Status: Show number of Business Requests, Project Requirements,

Usecases, the number of Items under development, Items for which

development is complete, Items under Testing, Items for which testing is

complete, the number of bugs entered and the ones that are resolved.

2) Risk Analysis Module Status: Shows number of risks identified and module

status.

3) Requirement Analysis Module Status: Shows number of Business Requests,

Project Requirements, Usecases.

4) Development Module Status: Shows number of Items under development, Items

for which development is complete.

5) Testing Module Status: Shows Items under Testing, Items for which testing is

complete.

6) Maintenance Module Status: Shows the number of bugs entered and the ones

that are resolved.

SelectProject

Select Module

View Available

DocsCheck-out Docs

SelectProject

Select Module

View Checked-

OutDocs

Check-in Docs

7) Project Requirements – Business Request Mapping: Shows the Requirements

and the Business requests that they originated from.

8) Use Cases – Project Requirements: Shows the Use Cases and Requirements

that they define.

3. TECHNICAL SPECIFICATIONS

Application Server : IIS

Front-End : ASP.NET

Middle-Tier : C#

Database : MS SQL SERVER

ARCHITECTURE DIAGRAM

COMPONENTS

IIS Web Server

IIS (Internet Information Services) is the web server on which the application is hosted.

ASP.NET

An ASP.NET page is contains HTML code and server-side scripts that are processed by

a web server before being sent to the client’s browser. ASP.NET framework has been

used in developing the presentation layer and maintaining Session Data. Form Security

feature of .NET has been used for Application Security. .NET Configuration feature has

been used to set Application variables and standardize features across the application.

ADO.NET

ADO.NET stands for ActiveX Data Objects for .NET. It refers to the suite of data access

technologies used to manipulate databases. ADO.NET provides database access to

web applications (ASP.NET) through data providers.

C#

The code-behind has been developed in C#. Database connectivity and business logic

has been encapsulated in the middle-tier. Each aspx page has an associated .cs file that

contains all the event-handling code written in C#.

VS.NET IDE

Visual Studio .NET is used as the IDE. Visual Studio .NET is a complete set of

development tools for building ASP Web applications, XML Web services, desktop

applications, and mobile applications.

MS SQL SERVER

Microsoft SQL Server is the relational database management system used as the

database for this application. Stored procedures and Triggers have been developed to

reduce the load on the front-end and number of database calls to the database from the

front-end.

SQL

SQL is a standard language for accessing and manipulating relational databases.

PL / SQL

Transact-SQL, which is commonly referred to as T-SQL or TSQL, is a step-up version of

SQL used by Microsoft in both SQL Server 7 and SQL Server 2000. It is an extension to

SQL statement set, which allows the developer to impose flow control, logic design and

exception handling in SQL blocks.

4. CODING

The following coding has been done for this project -

Front-End

About 54 Web Forms have been developed for this project. All the forms have been

developed in ASP.NET framework using Microsoft IDE – Visual Studio.

Lookups for values like Requirements, Use Cases, Developers, Testers etc have been

enforced using Java Script.

The following is the breakdown of the files by module –

Admin

createProject.aspx - Create new projects

updateProject.aspx - Update Project details

showProjects.aspx - List projects registered in the application

createUser.aspx - Create new Users

setUserAccess.aspx - Set User Access to Application Modules

showUsers.aspx - List all users of the system

Project

home.aspx - Module Status page

projectStatus.aspx - Display current Status of all modules in Project

updateProject.aspx - Update Project Details

Risk Analysis / DELPHI Study


admin.aspx - Activate next phase.

adminPhase1.aspx - Consolidate Phase I Barriers

phase1.aspx - Phase I Page

phase2.aspx - Phase II Page

phase3.aspx - Phase III Page

phase4.aspx - Phase IV Page

phase5.aspx - Phase V Page

Results.aspx - Display top 20 risks and Kendals W

Requirement Analysis


addStkhRequests.aspx - Add Stakeholder Requests

addRequirements.aspx - Add Requirements

addUseCases.aspx - Add Use Cases

mapReqStkh.aspx - Map Requirements to Stakeholder Requests

mapUsecaseReq.aspx - Map Use Cases to Requirements

Development


enterDevDetails.aspx - Enter new development object details

updateDevDetails.aspx - Update development object details

showDevReqs.aspx - Show requirements ready for development

showReqsInDev.aspx - Show current development objects

Testing


enterTestDetails.aspx - Enter new testing details

updateTestDetails.aspx - Update testing details

showTestReadyItems.aspx - Show development objects ready for testing

showDevInTesting.aspx - Show development objects being currently tested

Maintenance


enterBugs.aspx - Enter new bugs

updateBugs.aspx - Update bugs and view history

showBugs.aspx - List all bugs reported in the system

Repository

deleteFile.aspx - Delete File from repository

documents.aspx - Show My Documents

downloadFile.aspx - Check-Out File from repository

fileInfo.aspx - Show File Information and History

otherDocs.aspx - Show Documents owned by others, that you have access

reload.aspx - Check-In the downloaded Documents

reloadDocs.aspx - Perform actual file upload

setACL.aspx - Show all users to Set Access Control List

setPermissions.aspx - Grant Permissions to other uses in your file

uploadDocs.aspx - Upload new documents

Reports

home.aspx - Place-holder for future Project-level Reports

Common

changePassword.aspx - Change Password

logout.aspx - Logout from Application

lookup.aspx - Requirement/Use Case/Developer/Tester/User lookup

projects.aspx - Select Project

setSessionState.aspx - Set Application State

HomePage

home.aspx - Application login Page

Code-Behind

An equal number of code-behind files i.e., 54 have been developed for the middle-tier of

this project. The code is written in C#. ADO.NET has been used for Database

connectivity.

Each of the above mentioned aspx pages, have their own corresponding .cs files.

Database

50 Tables

2 Views

14 Stored Procedures &

6 Triggers

have been developed for this project.

The database has been normalized to prevent data redundancy and improve efficiency.

A combination of Stored Procedures, Triggers and Views has been used to reduce the

number of calls made from the Application Server to the Database server, thereby

enhancing the performance and making it more efficient.

Primary Keys, NOT NULL and Unique constraints have been used to maintain data

integrity. Referential integrity is maintained using Foreign Key – Primary Key

relationships. For ex: A row in Projects table cannot be deleted before all the rows in the

dependent tables (like requirements, use_cases etc are deleted). The ER Diagrams are

attached with the project report.

Less used features of T-SQL like Temporary tables have been used in stored

procedures to prevent permanent data storage space.

Here is a listing of all the database objects –

Tables

document_history - Document history

document_acl - Document access control list

documents - All documents in repository

file_actions - Master table for actions performed on Files (Ex: Check-In)

users - Master table of all users

projects - Master table of all Projects

project_users - Users of Project

modules - Master table of Modules

user_access - Module Assignment to Users

stkh_requests - Stakeholder Requests

requirements - Requirements

use_cases - Use Cases

request_requirement_mapping - Requirement & Stakeholder Request Mapping

requirement_usecase_mapping - Use Case & Requirement Mapping

dev_objects - Development Objects

testing - Testing Objects

bugs - Bugs

bug_history - History of reported bugs

Barrier - Risks/Barriers

barrier_comments - Phase I Comments

PhaseII - Phase II Details

PhaseIII - Phase III Details

PhaseIV - Phase IV Details

PhaseV - Phase V Details

delphi_status - Delphi Status Activation Details

Views

document_acl_v - Document Access Control List and Status

project_status - Status of all modules

Stored Procedures

insert_req_stkh_mapping - Insert Requirement & Stakeholder Mapping Details

update_req_stkh_mapping - Update Requirement & Stakeholder Mapping Details

insert_uc_req_mapping - Insert Use Case & Requirement Mapping Details

update_uc_req_mapping - Update Use Case & Requirement Mapping Details

insert_bug - Insert new Bugs

user_access_details - Return modules that user has access to

set_user_access - Set User access to modules

get_phase3_barriers - Pull Phase 3 Barriers based on Phase 2 response



update_delphi_status - Update Delphi Phase Activation Status

get_results - Returns Results based on Ranking of Barriers

download_document - Updates database when document is downloaded from

download manager

Triggers

bugs_history_trg - Populates Bug History when action is performed on Bug

phase1_to_phase2_trg - Populates Phase2 table when Admin consolidates Phase1

data

project_delphi_status - Insert Phase Status rows into Delphi Status when Proj is

created

new_file_update - Creates transaction entry for initial Doc upload

delete_document_history - Deletes Doc ACL & Doc History on Doc delete

update_file_status - Updates file status when doc is uploaded/downloaded

Web.config

The web.config has been used to set Application Variables that have been used across

the application.

For ex: the database connection string has been set here and is used in all files where

database connectivity is required. This helps standardize things and also makes it easy

to make changes. So when the database changes, change in code is required in just this

one file. The following is the entry –

<appSettings><add key="connectionString" value="server=localhost;database=project;uid=sa;pwd=abc123" />

</appSettings>

This config file has also been used to enforce Forms Security feature provided by .NET,

which will be explained in greater detail below.

ASP.NET Security

Web security is primarily about preventing access of secure pages by un-authorized

users. A web server identifies the users using a mechanism called authentication.

ASP.NET thus provides 3 different kinds of authentication – Windows Authentication,

Forms Authentication and Passport Authentication. Forms Authentication has been

used in this application.

Forms Authentication is enforced by making the configuration entries in the web.config

file. Create a folder called protectedFiles and copy all secure files into this folder. Then

make the following entry in web.config –

<authentication mode="Forms"><forms loginUrl="home.aspx"></forms>

</authentication>

Create a web.config file in the directory – protectedFiles and make the following entry in that file –

<configuration> <system.web>

<customErrors mode="Off" /><authorization>

<deny users="?" /></authorization>

</system.web></configuration>

Add the following code in the login page (home.aspx in this case) –

if (CustomAuthenticate(txtUserName.Text, txtPassword.Text))FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, false);elselblMessage.Text="Invalid Login";

Write the database authentication code in the function CustomAuthenticate.

Session Maintenace

Session Object of ASP.NET has been extensively used maintain the state of the

application. For ex: once a user logs in, he selects the project that he wants to work on.

Session variables have been used across the application to make sure that the data is

thus segregated by the selected project.

The Session variable is set by –

Session["pname"] = "Project1";

Application Security

When a user logs into the Application, the Menus are set for the user based on his

access restrictions for the modules.

CONCLUSION

This tool would definitely be a great help for management of a project. In the current

scenario, where geographic location of users is no longer considered a limitation and

vast amount of information at each person’s disposal, a web-based application like this

will make project management easy and efficient. People need not look into multiple

systems to get the information they need. Everything they want to know about the

project is available in this application.

6. REFERENCES

1. http://msdn.microsoft.com/library/default.asp

2. http://www.asp.net

3. Jeff Poise (2002). CD ROM Edition. Programming Microsoft .NET. Microsoft Press.

4. David Chappell (2002). 1st Edition. Understanding .NET: A Tutorial and Analysis. Addison

Wesley Professional.

http://www.asp.net/

http://msdn.microsoft.com/library/default.asp

project life cycle management.doc

Technology

project phases

project information

project managers

project endusers

project implementations

various project users

different users

different risks