Software Project Management Plan for IronX 1-Stop Centre System

8/14/2019 Software Project Management Plan for IronX 1-Stop Centre System

1/27

Software Project Management

Plan

IronX 1-Stop Centre System Services

Prepared by:

Mohd Noor Sabri bin Osman Teng

Noor Izzati bte Mohd Khalid

Raja Muhammad Asyraf bin Raja KhalifMohd Hafiz bin Muhaidin

Fatin Farhana binti Abd Khalid

Ahmad Farhan bin Azahan

Mohd Arif Gulbuddin bin Abd Halim

Table of Content


2/27

10 Introduction

1.1 Objectives

2.0 Project Organization

3.0 Risk Analysis

3.1 Risk Identification

3.2 Risk Analysis

3.3 Risk Planning Strategies

3.4 Risk Monitoring

4.0 Hardware and Software Requirements

5.0 Work Breakdown

6.0 Project Schedule

6.1 Scheduling

6.2 Gantt Chart

7.0 Monitoring and Reporting

7.1 Weekly Status Reporting

7.2 Time Reporting

7.3 Project Tracking

7.4 Revising Project Work Plans

7.5 Earned Value Reporting

1.0 Introduction


3/27

This document serves as the project plan for the IronX 1-Stop Centre System Services. The

content of this document into seven chapters: introduction, project organization, risk analysis, hardware

and software requirements, work breakdown, project schedule and monitoring and reporting.

The project organization chapter will show the people involved in this project along with their

roles.

The risk analysis chapter addresses the issues of application complexity as well as the anticipated

solution domain, database load and project size. Analysis indicates that this is small size, medium risk and

medium impact project.

The hardware and software requirements list out all the tools and device needed to implement in

this project.

The work breakdown chapter lists all the possible project activities.

The project schedule chapter will show how we split the project into tasks and estimate time and

resources required to complete each task. Organize tasks concurrently to make optimal use of workforce.

Minimize task dependencies to avoid delays caused by one task waiting for another to complete.

In the monitoring and reporting chapter it will identifies the report that should be produce by the

end of this project.

1.1 OBJECTIVE

IronX 1-Stop Centre management envisions a database application that will support basic

buy and selling operations and transmit fulfilled all the data to the IronX 1-Stop Centre

billing and accounting systems. Although the initial development effort will be only to

support core features that are critically required for successful buy and selling, the

application will be develop using open, standard-based technology that facilities integration

with other systems, additional development and significant scalability.

High level requirements are the goals that the system is to attain. All requirements, their

associated design elements and the subsequent test cases are traceable to one or more of these

goals. The high-level use cases from which these goals were derived are available on the

project web site. The high level requirements for the one stop centre application are access

control, customer management, order management, delivery management and core features.


4/27

10Project Organization

This are the people directly involved in this project.

Project Manager

Mohd Noor Sabri bin

Osman Teng


5/27

20Risk Analysis

A risk is a potential for loss or damage to an Organization from materialized threats. Risk

Analysis attempts to identify all the risks and then quantify the severity of the risks. A threat as

we have seen is a possible damaging event. If it occurs, it exploits vulnerability in the security of

a computer based system.

Project coordinator

Noor Izzati Mohd

Khalid

Risk analyst

Fatin Farhana bintiAbd Khalid

Assistant

Mohd Hafiz bin

Muhaidin

Software development

engineer

Raja Muhammad

Asyraf bin Raja Khalif

Engineering manager

Ahmad Farhan Azahan

Assistant

Muhammad Arif

Gulbuddin bin Abd


6/27

3.1 Risk Identification

1. Technology Risk

2. People Risk

3. Organizational Risk4. Financial Risk

5. Tools Risk

6. Requirements Risk

7. Estimation Risk

3.2 Risk Analysis

1. Technology risk

The database used in the system cannot process as many transactions per second

as expected

Software components that should be reused contain defects the limit their

functionality

1. People risk

It is impossible to recruit staff with skills required.

Key staffs are ill and unavailable at a critical time

Required training for staff is not available

1. Organizational risk

The organization is restructured so that different management are responsible for

the project

1. Financial risk

The budget of the project is not estimated

The project needs lower cost finance but with high expectation of the project

1. Tools risk


7/27

The code generated by CASE tools is inefficient

CASE tools cannot be integrated

1. Requirements risk

Changes the requirements that require major design rework are purposed

Customers fail to understand the impact of requirements change

1. Estimation risk

The time require to develop software is underestimated

The rate of defect repair is underestimated

The size of software is underestimated

The scope of the software is unlimited

3.3 Risk Planning Strategies

1. Technology risk strategies

Reduce the database used in the system and make it organize properly

Minimize the reused contain in the software components that defects the limit

their functionality

Investigate the possibility of buying a higher-performance database

1. People risk strategies

Reorganized team so that there is more overlap of work and people therefore

understand each others jobs

Provide training for the staffs


8/27

1. Organizational risk strategies

Prepare briefing documents for the senior management shown how the project is

making very important contribution to the goals of the business

1. Financial risk strategies

Estimated the budget of the project properly before develop any projects

Prepare briefing documents for the senior management shown how the project is

making very important contribution to the goals of the business

Minimize the costs of the project. Try to use open source and free software

1. Requirements risk strategies

Alert customer of potential difficulties and the possibility of delays, investigate

buying-in components

Derive traceability information to assess requirements change impact, minimize

information hiding in the design

1. Estimation risk strategies

Investigate buying-in components

Investigate use of a program generator

3.4 Risk Monitoring

1. Technology

Late delivery of hardware or support software, many reported technology

problems.

1. People


9/27

Poor staff morale

Poor relationship among team members

Job availability

1. Organizational

Organizational gossip

Lack of action by senior management

1. Tools

Reluctance by team members to use tools, complaints about CASE tools,

demands for higher-powered workstations

1. Requirements

Many requirements change request

Customers complaint

1. Estimation

Failure to meet agreed schedule

Failure to clear reported defects


10/27

10Hardware and Software Requirements

IronX 1-Stop Centre System

Dell / IronX 1-Stop Centre Partnership

IronX 1-Stop Centre One Stop Centre System has partnered with Dell, Inc., to offer

preconfigured hardware solutions designed to meet all of the latest hardware requirements for

installing and running this system.

The following are the hardware requirements and recommendations installations of the system.The recommendations are based on experience with many different installations and should only

be used as a reference in determining hardware needs for each individual configuration. You

may need to increase these recommendations to achieve individual performance expectations due

to environmental factors such as additional software installed on the system and network

architecture.


11/27

Workstation Recommendations

Processor: 2.1GHz or higher, x32

System Memory: 1GB DDR2

Hard Drive: 80GB HD (Minimum of 20GB space availability)

Operating System: Genuine Windows XP Professional, SP2, x32

Video Card: Integrated Video Card (Minimum of 1024 x 768 or higher)

*Ports: 4 USB, 1 Serial, 1 Parallel

* Needed if you require additional hardware for POS, Multiple Company option or barcode

scanning.

Server Recommendations

Minimum Hardware Requirements


12/27

NOTE: Minimum Requirements are not recommended for use in any environment. These

configurations are published as the minimum hardware required to receive customer support

services.

Database/Application/E-Commerce Server

Processor: Pentium 750MHz or Greater

Hard Drive: 8GB (Minimum HD Space Available)

System Memory: 256MB

Operating System: Windows 2000 Server, SP4, x32

Database Server: Microsoft SQL 2005 Express Edition

*Serial/Parallel/USB Ports

Workstation

Processor: Pentium 500MHz or Greater

System Memory: 256MB

Hard Drive: 3GB (Minimum HD Space Available

Operating System: Windows 2000 Professional, SP4, x32

Video Card: Integrated Video Card (Minimum of 1024 x 768 or higher)

*Ports: 4 USB, 1 Serial, 1 Parallel

* Needed if you require additional hardware for Point of Sale, Multiple Company option or

barcode scanning.

Network Configuration


13/27

TCP/IP LAN (Local Area Network) Connection with a Minimum of 10/100Base Uplink

between Workstations and Switches.

Note: Everest Does Not Recommend Using Hubs for Multiple Connections in a LAN

environment. This Can Cause Network Bottlenecks and Affect Network Performance.

10/100/1000Base Uplink between Servers and Switches.

Remote Users Connecting to the Network through Means of Terminal Server, VPN, etc.

Should have a Minimum of a DSL or Cable Connection.

Note: Everest Does Not Recommend the Use of Dial-Up Connection for Connecting.

Operating System and Database Compatibility

Everest supports multiple operating systems for both servers and workstations. Below is a list of

supported operating systems and database engines that have been tested for compatibility with

currently supported versions of Everest.

Server Operating Systems (32-bit) V4.0.2 V5.0 V5.0.1

Windows 2000 Server (Service Pack 4)

Windows 2000 Advanced Server (Service Pack 4)

Windows 2003 Standard Edition R2

Windows 2003 Standard Edition (Service Pack 1)

Windows 2003 Standard Edition (Service Pack 2)

Windows 2003 Enterprise Edition (Service Pack 1)

Windows 2003 Enterprise Edition (Service Pack 2)

Windows Small Business Server 2003

(Service Pack 1)

Windows Small Business Server 2003 R2


14/27

Client Operating Systems (32-bit)

Windows Vista Business Edition (Service Pack 2)

Windows Vista Ultimate Edition (Service Pack 2)

Windows Vista Enterprise Edition (Service Pack 2)

Windows XP Professional (Service Pack 3)

Windows 2000 Professional

Database Server (32-bit)

SQL 2005 Express Edition+

SQL 2005 Workgroup Edition+

SQL 2005 Standard Edition+

SQL 2005 Enterprise Edition+

SQL 2000 MSDE+

SQL 2000 Standard Edition+

SQL 2000 Workgroup Edition+

SQL 2000 Enterprise Edition+


15/27

5.0 Work Breakdown


16/27

Below are list of possible activities that can be done through this system.

Order Customer will order from the supplier by filling up the form that has been

provided in the supplier website

Receiving order Supplier will receive orders from customer and begin their analysis about

what the customer want, distance for each destination of delivery, and

alternative route for each delivery to be made.

Agreement Customer and supplier will sign up an agreement to confirm their services.

This will also include with the monthly payee services, frequency of

delivering in a week and the due date, when the customer should pay after

receiving their bills that has been sent to them.

Delivery Supplier will send the goods to the customer base on the order made by the

customer earlier. The system will print out each day delivering, publications

and items to be delivered to each house.

Bill At the end of each month, the system will automatically compute total amount

of consumed items and newspapers by the customer and bills will be sent to

the customer accordingly.

Geographic System will be able to manage and obtain some simple geographic

information so that it prints information for the delivery person.

Other service Shop owner will provide some services that not in their service but, they will

help the customer to communicate with individuals that provide those

services.


17/27


18/27

6.2 Gantt Chart

Project Status Symbols

S ScheduleA SatisfactoryC CautionF Critical

Activity %

Complete

Status Wk

1

Wk

2

Wk

3

Wk

4

Wk

5

Wk

6

Wk

7

Wk

8

Wk

9

Wk

10

Wk

11

Wk

12

Wk

13

Wk

14

Wk

15

User

Analysis

0 S sssssssss

sss

FullSpecifica

ion

0 S ssss

Architect

ural

0 S sss

s

Design 0 S sssssssss

sss

Detailed

Design

0 S sss

s

Database0 S sss

s

Test

Design

0 S sssssssss

sss

mpleme

ntation

0 S ssssssssssssssss

sssss

Module

Testing

0 S sssssssssssssss

sssss

ntegration Testing

0 S


19/27

7.0 Monitoring and Reporting

This section of the Standards and Procedures Manual describes the policies,

standards and procedures for monitoring the project costs, schedule and performance.

7.1 WEEKLY STATUS REPORTING

1. Team Member Responsibilities

Each team member is responsible to complete a weekly status report, using the

standard format. Each member gave a task and need to complete it in time and

responsible for what are they did.

2. Team Leader Responsibilities

The occasion of the weekly status report provides an opportunity for the Team

Leader to sit down with each team member at every Wednesday of every week to go over

the team member's report, and also to review whether there is any risk factor present

which should lead to a formal risk report.

A summary of the individual reports is then presented by the Team Leader and

reported to website. The Team Leader's report is to be submitted to the Project Office on

Mondays and will be discussed at the Team Leaders Meeting on that Wednesday.

Weekly reporting ensures that projected variances on the project are visible at all

times.


20/27

OVERALL PROJECT STATUS REPORT

Project Name: IroX 1- Stop Centre

Prepared By: Mohd Noor Sabri bin Osman Teng

Project Manager

Period:4 Month

Accomplished (this period): Project Organization Software Project management plan Software requirements Risk analysis Hardware and software requirements

Work breakdown Monitoring and reporting

Planned But Not Accomplished (this period): Website and software for this project


21/27

7.2 TIME REPORTING

1. Time Reporting Responsibilities

Hours spent on the project are recorded on Weekly Time Sheets. All hours arerecorded against an accounting charge number assigned by the Project Office. (See the

Project Codes defined in the Project Accounting Standards and Procedures).

Each team member will submit their Weekly Time Sheet with their Tracking

Document to the Project Administrator in accordance with the procedure defined in

section 4.

The Project Administrator will verify that all necessary supporting materials have

been provided and that the totals on the Timesheets match the Tracking Documentinformation.

All team member timesheets will be approved by the responsible Team Leader.

2. Reporting Cycle

The reporting cycle for time reporting is integrated with the reporting cycle for

project tracking as described in section 4.

To coordinate project reporting with corporate reporting, the end date of the last

reporting period of the month will be timed to coincide with the last business day of the

month. To accomplish the synchronization, the last project reporting period of the month

may be extended to the month end. In this situation, tracking documents, timesheets and

status reports are due on the last day of the month by 1:00 p.m. EST. The next tracking

period end date will be the first Friday of the new month if the first business day of the

month is Tuesday; otherwise the end date will be the second Friday of the month.


22/27

7.3 PROJECT TRACKING

1. Project Tracking Responsibilities

Project tracking will be performed weekly, using the PW Capture Actualsturnaround document to track progress against each activity.

Specifically, each Team Member will account for all time worked in the tracking

period by doing the following for each activity/task to which he/she has been assigned (as

identified on the PW Capture Actual document):

Add effort expended that period,

Thoroughly review the Estimate to complete figure and revise this as necessary to

prevent any "surprises",

Thoroughly review the projected Completion date for each activity/task and revise

this as necessary to prevent any "surprises".

Prior to the tracking report being submitted to the Project Administrator, Team

Leaders will:

Review each team member's tracking information for accuracy and completeness,

Ensure that ETCs are updated,

Ensure that end dates are revised for completed tasks (check all tasks with an ETC

of "0" to ensure they are closed or given revised estimates),

Ensure that start dates are revised (if these are different than original),

Check for new tasks which do not currently exist within their individual plans.

Tasks should not be added outside of the original project scope without a change

request,

Inform the Project Administrator exactly where in the plan new tasks should go

and how they should be defined. This information includes an original estimate

(if applicable), planned start and end dates and task dependencies.


23/27

The Project Administrator is responsible for entering project tracking information

and producing and distributing project tracking reports, using the Capturing Actual

Procedures, described in section 4.3.

Based on the input from Team Members, Team Leaders are then responsible to

adjust the PW plans as appropriate (e.g., assigning new tasks, reassigning existing tasks)

in accordance with the procedures in section 5.

2. Reporting Cycle

Each team member will submit their Tracking Document, Timesheet and Weekly

Status Report to the Project Administrator by 5:00 p.m. EST Friday.

Revised tracking documents will be distributed electronically through e-mail to team

members on Wednesday of each week.

3. PW Capture Actual Procedures

The Project Administrator will maintain the actual data in PW in accordance with the

following procedures.

1. Reconcile the time entered on tracking documents with the resource timesheets.

Record time in Lotus Time Capture spreadsheet.

2. Photocopy the timesheets and forward the signed original to the branch

administrative staff for input to BOS. File the photocopy in the project files.

3. Copy the "Master" files from the LAN (L:\PM\PW\FY94) to the workstation.

4. Determine whether Team Leaders have updated plans and the scope of the

changes. Review the changes with the Team Leader. Note changes to resources

and task dependencies.

5. Determine whether changes should be applied prior to capturing actuals. If so,

5.1 Revise the project plans to reflect the approved changes by either

replacing the original plan with the plan revised by the Team Leader

(L:\PM\PW\WORKING/FY94) or manually enter the changes.


24/27

5.2 Run Autoschedule. Make sure that Autoschedule can "see" the start date

of all open tasks by setting the VIEW to before the start date of the open

tasks.

5.3 Note any resource loading or dependency violations.

5.4 Apply the appropriate change to resolve the violation or refer the violation

to the Team Leader for resolution.

6. Ensure that today's date is the first day of the next tracking period.

7. Print out Actuals-Capture (AC) checklist.

8. Divide ACs into appropriate teams.

9. Review ACs for any new tasks or unplanned activities.

10. Check with Team Leaders if any questions; particularly in terms of unplanned

activities.

11. Enter Actual as per the Time Capture Documents.

11.1 Enter actual.

11.2 Close "completed" tasks approved by Team Leaders.

11.3 Enter revised end dates or ETC as indicated by team members and

approved by Team Leaders.

11.4 Enter "0" actual usages against tasks which have no time tracked during

the last period.

12. Run Autoschedule and identify any violations.

13. Save files and repeat above steps for the next project.

14. Print Actual Captured report.

15. Reconcile time captured in PW to time reported in BOS. Forward a copy of the

LOTUS Time Capture spreadsheet to Accounting at the end of the month for

reconciliation of InterBranch invoices.

16. Determine whether Team Leaders have new plans or major changes to plans.


25/27

16.1 Review the new plans or changes with the Team Leader. Ensure the plans

adhere to the standards. Note task dependencies and new resources.

16.2 Enter the new plans or revise existing project plans to reflect approved

changes. Manually enter changes to existing plans. New plans can be

copied from the WORKING directory or entered from scratch.

16.3 Run Autoschedule and identify any violations.

16.4. Save the file and repeat above steps for the next project.

17. Print tracking document for the next tracking period.

18. Print management reports.

19. Copy all MASTER plans to the LAN (L:\PM\PW\FY94).

20. Advise Team Leaders that the files are available.

4. PW/BOS Reconciliation

Each month the tracking information entered into PW will be reconciled with the

time reported in the BOS Time Reporting system.


26/27

7.4 REVISING PROJECT WORK PLANS

Team Leaders are responsible for providing the details of new project work plans

and changes to existing project work plans.

The project plan named "TEMPLATE" is to be used as the template for all new

projects. It contains a list of all the project resources and reflects the project standards.

The Project Plan Input Form has been created to assist with the entry of project

plan details. The input form can be used to record the Work Breakdown Structure and

task dependencies. A completed form will be used as the input form for the Project

Administrator to enter new plans into PW.

Project plans are reviewed by the Project Administrator to ensure their adherenceto project standards prior to being incorporated into the Master Plan. Planning reports are

available in Project Workbench (PW) to assist with a review of projects entered into PW.

Changes to project plans will be coordinated through the Project Administrator.

Changes can be communicated verbally or written using the Project Plan Input Form.

Alternatively, Team Leaders can "check out" a copy of a project plan and modify it

themselves.

The project plans will be located on the "L" drive of the LAN and will be backedup as part of the daily backup procedures for the LAN.

The master project plans will be located in L:\PM\PW\FY94. The master plan

directory will have restricted access to only the Project Administrator and Project

Management.

Changes to existing plans must be coordinated with the tracking process;

therefore, updated plans must be ready by 1:00 p.m. EST Monday morning.

Note that Team Leaders should not be making changes to PW files during the

period in which Actual Capture data are being entered (see section 4.3). They must wait

for the approval from the PTA. This is critical to ensure that everyone is working with

the most current version of a particular file.


27/27

7.5 EARNED VALUE REPORTING

Earned Value is a measure of the progress without regard to schedule or budget.

Because there are different ways to measure earned value, the calculation technique must

be stipulated during the project planning process. For example, if an eight section

deliverable of 150 pages is scheduled to take three weeks to develop, and two weeks into

the three week period, four sections (60 pages) are complete, what is the earned value?

Some Cost Account Managers might indicate that, since two of the three weeks have

passed, the document is 66% complete. However, an alternate view is that only four of

eight sections are complete, so that the earned value is only 50% (this assumes that all

sections have about the same effort to create, or have a similar number of pages).

Alternately, another view might be that because 60 of 150 pages are complete, the earned

value is only 40%.