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 Khalif
Mohd Hafiz bin Muhaidin
Fatin Farhana binti Abd Khalid
Ahmad Farhan bin Azahan
Mohd Arif Gulbuddin bin Abd Halim

Table of Content
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
 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.
10Project Organization
This are the people directly involved in this project.

Project Manager

Mohd Noor Sabri bin

Osman Teng
 Project coordinator

Noor Izzati Mohd

Khalid

Software development Risk analyst Engineering manager

engineer
Fatin Farhana binti Ahmad Farhan Azahan
Raja Muhammad Abd Khalid
Asyraf bin Raja Khalif

Assistant Assistant

Mohd Hafiz bin Muhammad Arif

Muhaidin Gulbuddin bin Abd
Halim

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.
3.1 Risk Identification
1. Technology Risk
2. People Risk
3. Organizational Risk
4. 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
 • 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 other’s jobs

• Provide training for the staffs

 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
 • 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

• Customer’s complaint

1. Estimation

• Failure to meet agreed schedule

• Failure to clear reported defects

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

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
• 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

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+

5.0 Work Breakdown
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.

Below are list of possible activities that can be done through this system.
6.0 Project Scheduling
6.1 Scheduling

Item Due date

Software Project Management Plan (this document) Week 1
Software Requirements Specifications Week 1

Software Design Document Week 3

Software Quality Assurance and Verification & Validation Plan Week 4

Studio I Presentation Week 5

Updated SPMP Week 6

Database Week 7

Software Testing Description Week 12

System Integration Week 14

Final Studio Paper Week 15

Studio II Presentation Week 16

 Activity % Status Wk Wk Wk Wk Wk Wk Wk Wk Wk Wk Wk Wk Wk Wk Wk Wk
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Complete

User 0 S sssssssss
Analysis sss

Full 0 S sss
Specifica s
tion

Architect 0 S sss
ural s

Design 0 S sssssssss
sss

Detailed 0 S sss
Design s

Database 0 S sss
s

Test 0 S sssssssss
Design sss

Impleme 0 S ssssssssssssssss
ntation sssss

Module 0 S sssssssssssssss
Testing sssss

Integratio 0 S sss
n Testing s

6.2 Gantt Chart

Project Status Symbols

S Schedule
A Satisfactory
C Caution
F Critical
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.
OVERALL PROJECT STATUS REPORT

Project Name: IroX 1- Stop Centre

Prepared By: Mohd Noor Sabri bin Osman Teng Period:4 Month
Project Manager
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
7.2 TIME REPORTING

1. Time Reporting Responsibilities

Hours spent on the project are recorded on Weekly Time Sheets. All hours are
recorded 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 Document
information.

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.
7.3 PROJECT TRACKING

1. Project Tracking Responsibilities

Project tracking will be performed weekly, using the PW Capture Actuals

turnaround 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.
 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.
 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.
 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.
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 adherence
to 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 backed
up 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.
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%.