Collar Finder Management Consultancy Inc.

Curriculum Vitae Management System

A Project Development Plan

Presented to the Faculty of the Graduate School
Asia Pacific College, Makati City

In Partial Fulfillment of the

Requirements of the Degree
Master in Information
Technology

JAN LUDVIK B. RANESES

 April 2016

ACKNOWLEDGEMENTS

I would like to extend my biggest thanks to everyone who has become a part of this
project. This is a son of my labors and a fruit of our best moments together. This
is possible through the guidance of the Lord Almighty.

Thank you very much.

-JAN LUDVIK BALBOA RANESES, MIT

2
Table of Contents
ACKNOWLEDGEMENTS................................................................................................................2
1. Project Overview.....................................................................................................................6
1.1 Project Name.......................................................................................................................6
1.2 Project Description...........................................................................................................6
1.2.1 Business Objectives......................................................................................................7
1.2.2 Business Case...............................................................................................................7
1.2.3 Project Objectives.........................................................................................................8
1.2.4 Project Success Criteria............................................................................................8
1.3 Project Completion Date.....................................................................................................9
1.4 Project Budget.....................................................................................................................9
1.5 Project Sponsors...............................................................................................................10
1.6 Project Key Deliverables...................................................................................................10
2.0 Project Glossary....................................................................................................................11
2.1 Key Terms.........................................................................................................................11
2.2 Acronyms...........................................................................................................................11
3.0 Project Scope.........................................................................................................................12
3.1 Product Characteristics / Requirements....................................................................12
3.2 Product Acceptance Criteria.............................................................................................13
3. Product Deliverables.........................................................................................................14
3.1. Project Management – Related Deliverables.........................................................14
3.2. Product- Related Deliverables................................................................................15
4. Project Exclusions..............................................................................................................16
5. Project Assumptions and Constraints..............................................................................16
4. Project Organization..............................................................................................................17
4.1. Project Organization Chart..............................................................................................17
4.2. Project Team Staff, Roles and Responsibilities..............................................................18
4.3. Deliverables Responsibility Matrix..................................................................................20
5.0 Project Management Approach............................................................................................22
6.0 Project Technical Approach.................................................................................................23
6.1 Product Development Methodology................................................................................23
6.2 Development Tools...........................................................................................................24
6.3 Technical Architecture......................................................................................................24
7.0 Baseline Plans.......................................................................................................................26
7.1 Scope Baseline...................................................................................................................26
7.2 Schedule Baseline.............................................................................................................35

1
 7.2.1 Milestone List.............................................................................................................35
7.3 Cost Baseline.....................................................................................................................36
7.4 Quality baseline.................................................................................................................37
8.0 Management Plans................................................................................................................40
8.1 Scope Management Plan...................................................................................................40
8.1.1 Scope Management Approach...................................................................................40
8.1.2 Roles and Responsibilities.........................................................................................41
8.1.3 Scope De[inition.........................................................................................................42
8.1.4 Scope Validation.........................................................................................................42
8.1.5 Scope Control.............................................................................................................43
8.1.6 Scope Management Tools..........................................................................................45
8.2 Change Management Plan................................................................................................45
8.2.1 Change Management Approach................................................................................45
8.2.2 De[initions of Change.................................................................................................46
8.2.3 Change Control Board................................................................................................46
8.2.4 Roles and Responsibilities.........................................................................................47
8.2.5 Change Control Process.............................................................................................47
8.2.6 Change Management Tools.......................................................................................47
8.3 Requirements Management Plan.....................................................................................48
8.3.1 Requirements Management Approach.....................................................................48
8.3.2 Roles and Responsibilities.........................................................................................49
8.3.3 Requirements Prioritization Process........................................................................50
8.3.4 Con[iguration Management.......................................................................................50
8.3.5 Requirement Traceability Matrix..............................................................................52
8.3.6 Requirements Management Tools............................................................................52
8.4 Con[iguration Management Plan.....................................................................................53
8.4.1 Roles and Responsibilities.........................................................................................53
8.4.2 Con[iguration Control................................................................................................54
8.4.3 Con[iguration Management Database......................................................................55
8.4.4 Con[iguration Status Accounting..............................................................................56
8.4.5 Con[iguration Audits..................................................................................................58
8.4.6 Con[iguration Management Tools............................................................................59
8.5 Schedule Management Plan..............................................................................................59
8.5.1 Schedule Management Approach..............................................................................59
8.5.2 Roles and Responsibilities.........................................................................................60
8.5.3 Schedule Control........................................................................................................61

1
 8.5.4 Schedule Changes and Thresholds............................................................................62
8.5.5 Schedule Change Control Process.............................................................................63
8.6 Cost Management Plan.....................................................................................................64
8.6.1 Cost Management Approach......................................................................................64
8.6.2 Roles and Responsibilities.........................................................................................65
8.6.3 Project Cost Measurements.......................................................................................65
8.6.4 Project Cost Reporting Format..................................................................................66
8.6.5 Cost Variance Process................................................................................................67
8.6.6 Cost Change Control Process.....................................................................................67
8.6.7 Cost Management Tools.............................................................................................67
8.7 Quality Management Plans...............................................................................................68
8.7.1 Quality Management Approach.................................................................................68
8.7.2 Roles and Responsibilities.........................................................................................69
8.7.3 Quality Requirements/ Standards............................................................................70
8.7.4 Quality Assurance......................................................................................................71
8.7.5 Quality Control...........................................................................................................73
8.7.6 Quality Control Measurements..................................................................................75
8.7.7 Quality Management Tools........................................................................................76
8.8 Risk Management Plan.....................................................................................................77
8.8.1 Risk Management Approach......................................................................................77
8.8.2 Roles and Responsibilities.........................................................................................77
8.8.3 Risk Identi[ication......................................................................................................78
8.8.4 Risk Quali[ication and Prioritization.........................................................................78
8.8.5 Risk Monitoring..........................................................................................................80
8.8.6 Risk Mitigation and Avoidance..................................................................................81
8.8.7 Risk Register Management........................................................................................82
8.8.8 Risk Management Tools.............................................................................................83
8.9 Human Resource Management Plan................................................................................83
8.9.1 Staf[ing Management.................................................................................................83
8.9.2 Human Resource Management Tool.........................................................................84
8.10 Communications Management Plan..............................................................................84
8.10.1 Communication Management Approach................................................................84
8.10.2 Roles and Responsibilities.......................................................................................85
8.10.3 Communication Management Constraints.............................................................86
8.10.4 Stakeholder Communication Requirements..........................................................87
8.10.5 Communication Methods and Technologies..........................................................88

1
 8.10.6 Communication Matrix............................................................................................90
8.10.7 Communication process..........................................................................................92
8.10.8 Communication Standards......................................................................................92
8.10.9 Communication Escalation Process........................................................................93
8.11 Stakeholder Management Plan......................................................................................95
8.11.1 Stakeholder Registry...............................................................................................95
8.11.2 Stakeholder Analysis Matrix...................................................................................96
8.11.3 Stakeholder Management Strategy.........................................................................98
8.12 Procurement Management Plan..................................................................................100
8.12.1 Procurement Management Approach..................................................................100
8.12.2 Procurement De[inition.........................................................................................100
9.0 Appendices..........................................................................................................................102
9.1 APPENDIX A – Project Cost- Bene[it Analysis...............................................................102
9.2 APPENDIX B – Systems Requirements Speci[ication....................................................105
9.2.1 INTRODUCTION.......................................................................................................105
9.2.2 PROJECT DESCRIPTION...........................................................................................105
9.2.3 BUSINESS CONTEXT................................................................................................109
9.2.4 SYSTEM OVERVIEW.................................................................................................110
9.2.5 USE CASE MODEL....................................................................................................115
9.2.6 Speci[ic Requirements.............................................................................................125
APPENDIX..........................................................................................................................133
9.3 APPENDIX C – Project Methodology..............................................................................135
9.4 APPENDIX D - Product Development Methodology......................................................139
9.5 APPENDIX E – Development Tools Speci[ication..........................................................143
9.6 APPENDIX F – Infrastructure Speci[ications.................................................................145
9.7 APPENDIX G – Detailed Schedule...................................................................................146
9.8 APPENDIX H – Detailed Funding Requirements and Cost Estimates..........................152
9.9 APPENDIX I – Risk Register............................................................................................156

1
5
1. Project Overview

1.1 Project Name

Collar Finder Management Consultancy Inc. Curriculum Vitae Management System

(CFMCICVMS)

1.2 Project Description

The CFMCICVMS will be developed for Collar Finder Management Consultancy Inc.

Collar Finder Management Consultancy Inc., an executive search firm. It has been doing

business for a year. Their corporate office is situated at 28th Floor Cityland Pasong Tamo

Tower u2807 2210 Chino Roces Avenue Makati City. Currently they have 5 Project

Associates working on different clients’ requirements with the CEO/ Owner Mr. Hernard

Honcolada.

CFMCI is an organization which aims for convenience, efficiency and consistency

advantages that the CFMCI CV Management System can give. One similarity among

Executive Search firms is a long response time regarding client requirements. This is a

problem being faced by all and having this kind of application can help lessen the

response time and create a good relationship with the clients. According to the CEO, 55%

of the total response time is being spent in reviewing collected CVs.

The centralization of processes is taking its rise in a lot of organizations nowadays. Aside

from the fact that is the current trend, organizations are taking this opportunity to increase

the quality of services they offer and increase profit. CFMCI has been established for

6
over a year and they have been finding ways of how they can improve the business

process to cater faster service and to have higher income. This product will be used to

contribute to the fulfilment of its vision, mission and goals. This solution will aid the

whole organization in implementing executive search activities wherein CV review

which is the backbone of the whole process will be very convenient and fast as the

software will narrow down possible candidates for different client requirements. This will

also help the organization in its goals in catering faster service to its clients.

1.2.1 Business Objectives

1. Increase annual revenue by 20%

2. Improve response time to client requirements by 10% every year.

1.2.2 Business Case

The proponent wished to develop a software to manage the CVs collected by the Collar

Finder Management Consultancy Inc. during executive search activities. This solution

will intend to develop features to create a centralized storage for the CVs collected over

time, an interface for the CEO to monitor CV uploading activities, an interface for an

easier manner of searching through the CVs using word/phrase match and frequency

indicators and an interface for viewing CVs categorized thru search tags.

This solution will aid the whole organization in implementing executive search activities

wherein CV review which is the backbone of the whole process will be very convenient

and fast as the software will narrow down possible candidates for different client

7
requirements. This will also help the organization in its goals in catering faster service to

its clients. It will also save up human resource efforts as well as man power costs.

With just a simple project, Collar Finder will be able to return its investment in just a

year. In 5 years, it will be able to add an additional of Php 10,360,119.04 revenue due to

faster service rendered because of the advantages brought by the proposed solution.

Details of Cost – Benefit Analysis in Appendix A.

1.2.3 Project Objectives

1. Improve response time by 40% to client requirements by reducing

searching time over collected CVs to increase revenue.

2. Provide a single centralized storage for the CVs collected over time

3. Allow the CEO to monitor CV uploading activities (to the centralized

storage) by project associate, duration or both in real-time.

1.2.4 Project Success Criteria

Key Area Criteria

Schedule 1. The project must be delivered by May 25, 2023.

Budget 2. The project must not exceed the budget of four hundred
sixty thousand pesos (₱ 2,010,000.00)
Product 3. The project must be formally accepted by the project
sponsor through the product acceptance criteria defined in
3.2

8
 Quality 4. All high-priority functionality defined in the requirements
specification is delivered in the first release.

5. The number of residual defects does not exceed to 3 per

module.

Satisfaction 6. Train 100% of staff within the 3-day training period

7. Improve customer satisfaction by 65% over the first three
months

1.3 Project Completion Date

February 29, 2017

1.4 Project Budget

The table below is the summarized Project Budget.

Table 1: Summary of the Project Budget

Item Description Estimated Percentage
Cost
1 Software Cost ₱ 1,208.64 0.07%
a) GoDaddy Domain (₱
1,208.64 2-years)
b) XAMPP (₱ 0.00)
c) Visual Studio Code (₱
0.00)
d) HTML (₱ 0.00)
e) JavaScript (₱ 0.00)
f) CSS (₱ 0.00)
g) MySQL (₱ 0.00)
h) PHP (₱ 0.00)
i) Android Studio (₱ 0.00)
j) GitHub (₱ 0.00)
2 Hardware/Network Cost ₱180,613 10.34%
a) ACER Aspire 7 (GeForce
RTX 3050 Graphics | AMD
Ryzen 5 5500U Processor)
(₱ 41,999.00* 2) ₱ 83,998

9
 b) Lenovo IdeaCentre 3i
07IAB7 90SM001APH w/
D22-20 21.5 Monitor, Intel
Core i3-12100/8GB
RAM/512GB SSD/UHD
Graphics 730 (₱40,995.00
*2) ₱81,990.00
c) Converge Fiber X (50mbps
₱1,625.00/month) ₱
14,625.00
3 Operational Cost ₱29,700 1.7%
a) Electricity Cost (₱ 3,000 *
9 months) ₱ 27,000
b) Water Expense (₱ 300 * 9
months) ₱ 2,700
4 Labor Cost ₱1,519,200 87%
a) Project Manager (₱
48,000/month * 9) ₱
432,000
b) QA Analyst (₱
36,800/month * 9) ₱
331,200.00
c) Programmer (₱
44,000/month * 9) ₱
396,000
d) Systems Analyst/Tester (₱
40,000 * 9) ₱ 360,000
5 Training ₱12,440 0.71%
a) Food Allowance (₱ 2,000 *
3 days) (₱ 6,000)
b) Transportation Allowance
(₱ 3,200)
c) Hotel Accomodation (₱
1,620 * 2) ₱ 3,240
6 Effort Cost ₱3,000 0.17%
a) Orientation (₱ 3,000)
Sub Total ₱1,746,161.64 100%

*** Contingency ₱ 261,924.25 15%

Total Cost ₱ 2,008,085.89

***See Appendix H for details.

10
11
1.5 Project Sponsors

The General Manager of Teafora Milk Tea House – Puerto Galera

1.6 Project Key Deliverables

The table below show the Project Deliverables per Project Phase with its Target Date

Table 2: Project Key Deliverable per Project Phase

Project Phase Project Deliverables Target Date
Mm/dd/year
Project management Project Approval 05-25-2023
Procurement Plan
Audit Findings and Reviews
Analysis Phase Requirements Management Plan 08-15-2022
Conceptual System Designs
High Level Project Strategies
Acceptance Criteria
Information Retention Criteria
Test Cases
Design Phase Solution for the Module Designs 12-30-2022
Module Design Document
Coding Phase Administrator Module 05-05-2023
Project Associate
Module CEO Module
Module Coding Document
Unit Test Results Document
Misc Elements of the Solution
Testing Phase Software 05-15-2023
System Test Report
Defect and Classification Tracking and
Methods
Updated Test Files and Records
Approved UAT
Deployment User Training 05-24-2023
Materials Training
User Support Documentation
Go

12
2.0 Project Glossary

2.1 Key Terms

1. Curriculum Vitae - a brief account of a person's education, qualifications, and

previous experience, typically sent with a job application.

2. Project Associate – the personnel in-charge of finding possible human

resource match/es to client requirements

3. CEO – the owner and the top executive of CFMCI

4. Administrator – will act as the manager for accounts being used with the

CFMCICVMS, he has the capability to activate or deactivate a certain user

account

2.2 Acronyms

1. CFMCI - Collar Finder Management Consultancy Inc.

2. CFMCICVMS - Collar Finder Management Consultancy Inc. Curriculum

Vitae Management System

3. CV - Curriculum Vitae

4. CI – Configuration Item/s

13
 5. CM – Configuration Manager

6. CCB – Change Control Board

7. CMDB – Change Management Database

8. PMI – Project Management Institute

3.0 Project Scope

3.1 Product Characteristics / Requirements

The table below shows the product features description.

Table 3: Product Features

Feature Number Description

1 Access Management for Ordering System

1.1 User Registration

1.2 User Log In

1.3 User Detail Update

1.4 Administrator interface for activating and

deactivating registered users
2 Home

2.1 Top Promos & New Products

2.2 Best Seller

2.3 Shortcuts for Full Menu

2.4 Customer Support

2.4.1 Hotline

14
 2.4.2 Chatbot (FAQ)

3 Menu

3.1 Categories – Milktea, Pastries, Coffee, Smoothies,

Fruit Tea, Latte and Snacks
3.2 Product Details

3.3 Product Reviews

4 Promo and Vouchers

4.1 Promo

4.2 Vouchers

5 Cart

6 Payment Methods – G-Cash & COD

7 About Us

Feature Number Description

1 Access Management for Inventory System

1.1 Admin Registration

1.2 Admin Log In

1.3 Admin Profile Update

1.4 Administrator interface for activating and

deactivating registered users
2 Category - Only administrator can add category on the
category section; Staff can only view categories

15
 3 Supplier Section – Only Administrator can add and
view supplier personal data
4 Items - Both Admin and Staff can add the stocks of
the products in item section
5 Update Stocks – Update Stock Levels of items

6 Stock History – Tracks Stock Updates that have

made.
7 Dashboard

7.1 Summary of sold items, stock levels

7.2 Reports

7.2.1 Stock Levels Report

7.2.2 Inventory Performance Report

7.2.3 Purchase Order Report

3.2 Product Acceptance Criteria

The table below shows the defined criteria for product acceptance.

95% of product-related deliverables has been delivered within schedule.

All requirements have been formally approved through the following reviews:

a. Requirement Review

b. Design Review

c. Code Review

d. Deployment Plan Review

16
 e. Test Plan Review

f. Test Cases Review


The system has successfully passed series of test such as the following:

a. Unit Testing

b. Integration Testing

c. Functional Testing

d. Systems Testing

17
 e. User Acceptance Testing / Quality Assurance

The system has been successfully deployed by the project team. All of the following

success indicators must be accomplished:

a. Training materials have been developed and distributed to target users

b. Training has been conducted

c. User Support has been properly documented

d. New solution has been properly installed and fully functional.

e. Installation performance monitoring has been conducted

3. Product Deliverables

3.1. Project Management – Related Deliverables

The table below shows the Project Management-Related Deliverables along with their
Target Date.

Table 4: Project Management- Related Deliverables

Number Deliverable Target Date

1 Project Proposal 10/11/22

2 Project Charter 10/26/22

3 Project Goals 10/26/22

4 Project Schedule 10/26/22

5 Project Budget 10/26/22

6 Work Breakdown Structure 10/26/22

7 Project Management & Project Team Members 08/26/22

List
8 Procurement Plan 12/09/16

9 Project Review Report 05/24/23

10 Project Close out Document 05/25/23

18
3.2. Product- Related Deliverables

The table below shows the Product -Related Deliverables along with their Target Date.

Table 5: Product-Related Deliverables

Number Deliverable Target Date
1 Prototype 07/11/16
2 Requirements Model 07/20/16
3 Requirements Management Plan 07/27/16
4 Conceptual Systems Design 07/27/16
5 Testing, Training and Implementation Strategy 08/01/16

6 Acceptance Criteria 08/02/16

7 Information Retention Criteria 08/03/16

8 Test Cases 08/05/16

9 Solution Design for Admin, Project Associate, CEO 08/26/16

Module
10 Development Environment 08/31/16
11 Admin, Project Associate, CEO Module 11/11/16

12 Module Coding Documentation 11/16/16

13 Unit Testing Results/Documentation 11/22/16

14 Test Environment and data, Training Content, 11/24/16

Implementation Components
15 Resolved Bugs 12/13/16

16 Testing Metrics 12/14/16

17 Test Reports 1/12/17

18 Training Materials 1/17/17

19 User Support Documentation 1/24/17

20 Installed System 1/26/17

19
4. Project Exclusions

The following items will not be included in the project:


The project will not be providing any ongoing support/ maintenance for the

system once it has been implemented.


This project will not be delivering any additional business reports aside from

the defined reports in the project charter.


Actual uploading of the collected CVs

5. Project Assumptions and Constraints

The table below shows the Assumptions and Constraints in 3 Key Areas – People,

Process and Technology

Table 6: List of Project Assumptions and Constraints per Key Area

Assumptions
PEOPLE Testers also act as System analysts responsible for checking
software, websites, and other technical issues that occur in the
system.
PROCESS Approval schedule may vary depending on project sponsor
availability.
TECHNOLOGY All hardware required for the undertaking have to be in precise
situation in the course of the development of the system.
Constraints

20
 PEOPLE Testers/QA Analysts are not responsible for correcting
previously encountered errors.

PROCESS User passwords must consist of at least six alphanumeric keys.

TECHNOLOGY Development of the project depends on the administrator, want
to use existing hardware or prefer new hardware.

4. Project Organization

4.1. Project Organization Chart

a. External Interfaces

The diagram below shows the external entities of the project which compose the users of

the application.

Project
Associates

CFMCICVMS

CEO Administrator

Figure 1: Project External Interfaces

21
 b. Internal Interfaces

The diagram below shows the internal entities of the project which compose the people

involved in the development, testing and implementation of the project.

Figure 2: Project Internal Interfaces

4.2. Project Team Staff, Roles and Responsibilities

The table below shows the project team roles with their responsibilities.

Table 7: Project Team Staff, Roles and Responsibilities

22
 Roles Responsibilities

Project Sponsor Provides the direction of the project.

Monitor the project’s progress.

Define Project Management process with the Project
Manager.

Arrange the timeline of the project with the Project
Manager

Sign the Project Acceptance Document.

Sign the Project Charter

Sign the Project Plan

Project Manager Ensure that the Project Team completes the project

Develops the Project Plan with the team

Manages the team’s performance of project tasks

Responsible for the outcome (success or failure) of the
project.

System Analyst Conducts One-on-One interview with the Stakeholder

Participates in the Group Interview with the Stakeholder

Participates in Phase Sign-off Meetings

Conduct a Follow People Around Elicitation Technique

Consolidate the requirements from Elicitation

Rationalize Requirements

Model the Requirements

Define Specifications

Participates in the Evaluation of Reuse, Buy(Rent), Build
Alternatives

Create Requirements Management Plan

Build Conceptual Systems Design

Develop High Level Project Strategies

Capture Additional Client Information

Validate standards and guidelines for the Modules

Design the Solution for Screen Layout, Program,
Security, Architecture and Logical Datastores of the
Modules

Document the Design phase

Construct Misc Elements of the Solution

Participates in the preparation of the Implementation

Participates in the Development of Training Materials

Participates in the Training , User Support Documentation

23
 
QA Analyst Responsible in Deliverable Review, Audit Review

Responsible in Informing Project Sponsor for Audit

Responsible for Conducting Preliminary Audit Review
and the Audit Plan

Responsible in Documenting the Audit Findings
and Reports

Responsible for validating and closing none conformities

Meeting the Project Sponsor for Audit Activity

Responsible for closing the Audits

Quality Control

Programmer Stores and assemble delivered hardware and software
products

Configure the Server

Set up training and staging environment

Code the application modules.

Develops technical specifications and plans.

Maintains the system.

Resolve reported bugs.

Conduct unit testing.

Conduct application fine tuning.

Defines restrictions, security and data integrity of the
database.

Install and create database

Create encoding log monitoring sheet

Defines procedures for backup and recovery

Tester Design and develop test plans.

Conduct functional and integration testing.

Prepare test cases.

Execute test cases.

Log bugs encountered issue register.

Sign – off functional and integration of modules.

4.3. Deliverables Responsibility Matrix

This table indicates the person Responsible, Accountable, Consulted and Informed for
each project deliverable.

24
Table 8: Deliverables Responsibility Matrix
Project Deliverables PS PM SA P QAA T

Project Proposal A/C R - - - -

Project Charter A/C R - - - -

Project Goals A/C R - - - -

Project Schedule A/C R - - - -

Project Budget A/C R C C I I

Work Breakdown Structure A/C R C I I I

Project Management & Project A/C R I I I I

Team Members List
Procurement Plan A/C R C I I I

Project Review Report A/C C I I R I

Project Close out Document A/C R I I I I

Legend:

PS – Project Sponsor PM- Project Manager

SA – Systems Analyst P- Programmer
QAA – QA Analyst T – Tester

25
5.0 Project Management Approach
In executing the project management, waterfall approach will be implemented. Waterfall

approach will work well for this kind of small, well defined project. This kind of

approach best fits this kind of project since at the beginning of the project specifics will

be clearly defined. This approach is simple and easy to understand and use.

In this model phases are processed and completed one at a time and phases do not

overlap. It is easy to manage due to the rigidity of the model – each phase has specific

deliverables and a review process. Project management, both at internal level and client’s

level, is easy again because of visible outputs each phase. Deadlines can be set for the

completion of each phase and evaluation can be done from time to time, to check if

project is going as per milestones. Since output is produced after each stage, therefore it

has high visibility. The client and project manager gets a feel that there is considerable

progress. Here it is important to understand that in any project, psychological factors also

play an important role.

It is also beneficial if this approach will be used since the amount of resources for it are

minimal. This would not incur extra cost for the project.

Mentioning its strengths as an effective approach this explains why this methodology is

pro- quality. This project has its center in its functions on how it can help the current

system of the client and playing dull regarding the quality will be a major setback for the

project.

See Appendix C for details.

26
6.0 Project Technical Approach

6.1 Product Development Methodology

In developing the project, the waterfall methodology will be implemented. The project

will be divided into sequential phases. Emphasis will be on planning, time schedules,

target dates, budget and implementation of the entire system. A tight control will be

maintained over the life of the project via extensive written documentation, formal

reviews and approval or signoff by the user and the information technology management

at the end of most phases before beginning the next phase. A written documentation is an

explicit deliverable of each phase.

This model will involve documenting the project in advance, including the user interface,

user stories, and all features’ variation and outcomes.

This methodology has been chosen because the requirements are very well known, clear

and fixed. Also, the product definition is stable so it is a good thing to use this

methodology. This methodology will also best fit small projects like this one where

technology is easily understood and there is no ambiguous requirement. See details in

Appendix D

27
6.2 Development Tools

The list below shows the development tool that will be used during product development

Table 8: Product Development Tools

a. Hardware (2) Lenovo ThinkPad L430 2465 - C 1000M / 1.8 GHz
(1) HPE ProLiant DL80 Gen9 Server
b. Software Visual Studio
HelpNDoc
Time Travel Tracing
Microsoft Office Word 2013
Microsoft Office Excel 2013
c. Database MySQL, MySQL Connector
6.3 Technical Architecture

Figure 3: Development Environment Technical Architecture

28
The system resources will be client based to avoid heavy network traffic so most

processes will take place in the terminals instead in the server. The server’s purpose will

be purely for data and file retrieval. This kind of architecture will be implemented since

the CEO is highly concerned with the project budget. Many better architecture can be

implemented but budget is a big consideration.

For Business Process Diagrams, please see APPENDIX B: Project SRS Section 5

29
7.0 Baseline Plans

7.1 Scope Baseline

The table below shows the scope baseline thru WBS, WBS ID, Effort, Resources, Start
and End Date.

Table 9: Scope Baseline

EFFOR RESOURC
WBS ID WBS DESCRIPTION T ES FROM TO
161.15 1/27/2
1 Project Management days 6/6/2016 017
Analyst[50
%],Project
manager,Pr
oject 6/14/2
1.1 Initiation 7 days Sponsor 6/6/2016 016
Analyst,Pro
ject
manager[5 6/15/201 6/29/2
1.2 Planning 10 days 0%] 6 016
160.38 1/26/2
1.3 Execution days 6/6/2016 017
Project 6/10/2
1.3.1 Acquire Project Team 5 days manager 6/6/2016 016
Identify and Hire Additional 6/10/2
1.3.1.1 Team Members 5 days 6/6/2016 016
6/6/20
1.3.1.2 Resource Contract Signing 0.5 days 6/6/2016 16
Project 6/6/20
1.3.1.3 Deploy Team 0.5 days manager 6/6/2016 16
Project 6/6/20
1.3.1.4 Roll-Off Team 0.5 days manager 6/6/2016 16
8/26/201 8/31/2
1.3.2 Procurement 2 days 6 016
Project 8/26/201 8/30/2
1.3.2.1 Plan Procurements 1 day manager 6 016
Project 8/30/201 8/31/2
1.3.2.2 Administer Procurements 0.5 days Sponsor 6 016
Project 8/31/201 8/31/2
1.3.2.3 Close Procurements 0.5 days manager 6 016

30
 Analyst,Proj
ect
manager,Pro
grammer
1,Programm
er 2,Tester
1,Tester 7/4/20
1.3.3 Project Kickoff Meeting 0.75 days 2(User) 7/4/2016 16
Project
Conduct Analysis Phase Sign Off manager,An 8/8/20
1.3.4 Meeting 0.5 days alyst 8/5/2016 16
Project
Conduct Design Phase Sign Off manager,An 8/26/201 8/26/2
1.3.5 Meeting 0.5 days alyst 6 016
Analyst,Proj
ect
manager,Pro
grammer
Conduct Construct Phase Sign Off 1,Programm 11/25/20 11/28/2
1.3.6 Meeting 0.53 days er 2 16 016
Analyst,Pro
grammer
1,Programm
er 2,Project
manager,Tes
Conduct Test Phase Sign Off ter 1,Tester 1/12/201 1/12/2
1.3.7 Meeting 0.2 days 2(User) 7 017
Analyst,Pro
grammer
1,Programm
er 2,Project
manager,Tes
ter 1,Tester
Conduct Implementation Phase 2(User),Proj 1/25/201 1/26/2
1.3.8 Sign Off Meeting/Final Approval 0.47 days ect Sponsor 7 017
7.25 1/12/2
1.4 Monitoring and Control days 1/3/2017 017
1/10/2
1.4.1 Quality Assurance 5.25 days 1/3/2017 017
1/3/20
1.4.1.1 Deliverable review 0.5 days QA Analyst 1/3/2017 17
1/4/20
1.4.1.2 Audit Review 1 day QA Analyst 1/3/2017 17
Inform Project Sponsor for 1/4/20
1.4.1.3 Audit 0.25 days QA Analyst 1/4/2017 17
Conduct Preliminary Audit 1/5/20
1.4.1.4 Review 0.5 days QA Analyst 1/4/2017 17
1/6/20
1.4.1.5 Execute Audit Plan 1 day QA Analyst 1/5/2017 17

31
 Document Audit Findings 1/6/20
1.4.1.6 and Reports 0.5 days QA Analyst 1/6/2017 17
Validate and Close 1/9/20
1.4.1.7 non conformities 0.5 days QA Analyst 1/6/2017 17
QA
Meeting with Project Sponsor Analyst,Proj 1/9/20
1.4.1.8 for Audit Activity 0.5 days ect Sponsor 1/9/2017 17
1/10/2
1.4.1.9 Close Audit 0.5 days QA Analyst 1/9/2017 017
Tester
1,Tester
2(User),QA 1/10/201 1/12/2
1.4.2 Quality Control 2 days Analyst 7 017
Project
manager,A
nalyst,Proj
ect
Sponsor,Pr
ogrammer
1,Program
mer
2,Tester
0.28 1,Tester 1/26/201 1/27/2
1.5 Project Management Sign-off days 2(User) 7 017
131.03 1/12/2
2 Execution days 7/4/2016 017
22.3 8/8/20
2.1 Analysis days 7/4/2016 16
12.45 7/25/2
2.1.1 Requirements Specifications: days 7/4/2016 016
7/14/2
2.1.1.1 Elicitation 5.25 days 7/4/2016 016
Analyst,Test
er
2.1. One-on-One Interview 2(User),Proj 7/5/20
1.1.1 with the Stakeholder 0.5 days ect manager 7/4/2016 16
2.1. Group Interview with the Analyst,Proj 7/5/20
1.1.2 Stakeholder 0.5 days ect manager 7/5/2016 16
Programme
r
1[75%],Proj
ect
2.1. manager,An 7/11/20
1.1.3 Prototyping 1.98 days alyst 7/5/2016 16
2.1. Conduct a Follow Analyst,Proj 7/13/201 7/14/2
1.1.4 People Around Elicitation 1 day ect manager 6 016
Technique

32
 7/14/201 7/20/2
2.1.1.2 Validation 4 days 6 016
2.1. Consolidate the 7/14/201 7/14/2
1.2.1 Requirements from Elicitation 0.5 days Analyst 6 016
2.1. Rationalize the 7/14/201 7/15/2
1.2.2 Requirements 0.5 days Analyst 6 016
2.1. 7/15/201 7/20/2
1.2.3 Model The Requirements 3 days Analyst 6 016
2.1. Create Process 7/15/201 7/18/2
1.2.3.1 Models(UML) 1 day 6 016
2.1. Create Data 7/18/201 7/19/2
1.2.3.2 Models 1 day 6 016
2.1. Create Data Flow 7/19/201 7/20/2
1.2.3.3 Diagram 1 day 6 016
7/20/201 7/22/2
2.1.1.3 Specification 2.2 days Analyst 6 016
2.1. Prioritize the 7/20/201 7/20/2
1.3.1 Requirements 0.2 days 6 016
2.1. Ensure Traceability of 7/20/201 7/20/2
1.3.2 the Requirments 0.5 days 6 016
2.1. Ensure Testability of the 7/20/201 7/21/2
1.3.3 Requirments 0.5 days 6 016
2.1. Create Business 7/21/201 7/22/2
1.3.4 Requirements Report 1 day 6 016
Project 7/22/201 7/25/2
2.1.1.4 Verification 1 day manager 6 016
2.1. Conduct Requirements 7/22/201 7/22/2
1.4.1 Review 0.5 days 6 016
2.1. 7/22/201 7/25/2
1.4.2 Obtain Sponsor Sign Off 0.5 days 6 016
Evaluate Reuse, Buy(Rent), Build Analyst,Proj 7/25/201 7/25/2
2.1.2 Alternatives 0.25 days ect manager 6 016
Create Requirements Management 7/25/201 7/27/2
2.1.3 Plan 2 days Analyst 6 016
7/25/201 7/27/2
2.1.4 Build Conceptual Systems Design 2 days Analyst 6 016
Analyst[50
%],Project
Develop High level Project manager[50 7/27/201 8/1/20
2.1.5 Strategies 3 days %] 6 16
7/27/201 7/28/2
2.1.5.1 Establish Testing Strategy 1 day 6 016

33
 7/28/201 7/29/2
2.1.5.2 Establish Training Strategy 1 day 6 016
Establish Implementation 7/29/201 8/1/20
2.1.5.3 Strategy 1 day 6 16
Capture Additional Analyst,Proj 8/3/20
2.1.6 Client Information 2 days ect manager 8/1/2016 16
8/2/20
2.1.6.1 Develop Acceptance Criteria 1 day 8/1/2016 16
Develop Information 8/3/20
2.1.6.2 Retention Criteria 1 day 8/2/2016 16
Tester
1,Tester 8/5/20
2.1.7 Create Test Cases 2 days 2(User) 8/3/2016 16
8/8/20
2.1.8 Sign Off Analysis Phase 0.1 days 8/8/2016 16
15.75 8/30/2
2.2 Software Design days 8/8/2016 016
Administrator Module/Project 12.75 8/24/2
2.2.1 Associate Module/ CEO Module days 8/8/2016 016
Validate Standards and 8/8/20
2.2.1.1 Guidelines for Administrator Module 0.5 days Analyst 8/8/2016 16
Validate Standards and
Guidelines for Project Associate 8/9/20
2.2.1.2 Module 0.5 days Analyst 8/8/2016 16
Validate Standards and 8/9/20
2.2.1.3 Guidelines for CEO Module 0.5 days Analyst 8/9/2016 16
Design the Solution for
Screen layouts for Adminsitrator 8/10/2
2.2.1.4 Module 0.75 days Analyst 8/9/2016 016
Design the Solution for
Screen layouts for Project Associate 8/10/201 8/11/20
2.2.1.5 Module 0.75 days Analyst 6 16
Design the Solution for 8/11/201 8/11/20
2.2.1.6 Screen layouts for CEO Module 0.75 days Analyst 6 16
Design the Solution for 8/11/201 8/12/2
2.2.1.7 Programs for Adminsitrator Module 1 day Analyst 6 016
Design the Solution for 8/12/201 8/15/2
2.2.1.8 Programs for Project Associate Module 1 day Analyst 6 016
Design the Solution for 8/15/201 8/16/2
2.2.1.9 Programs for CEO Module 1 day Analyst 6 016
Design the Solution for 8/16/201 8/17/2
2.2.1.10 Security for Project Associate Module 1 day Analyst 6 016
Design the Solution for 8/17/201 8/18/2
2.2.1.11 Security for Adminsitrator Module 1 day Analyst 6 016

34
 Design the Solution for 8/18/201 8/19/2
2.2.1.12 Security for CEO Module 1 day Analyst 6 016
Design the Solution for 8/19/201 8/22/2
2.2.1.13 Architecture for Adminsitrator Module 0.5 days Analyst 6 016
Design the Solution for 8/22/201 8/22/2
2.2.1.14 Architecture Project Associate 0.5 days Analyst 6 016
Module
Design the Solution for 8/22/201 8/23/2
2.2.1.15 Architecture for CEO Module 0.5 days Analyst 6 016
Design the Solution for
Logical Datastores for Adminstrator 8/23/201 8/23/2
2.2.1.16 Module 0.5 days Analyst 6 016
Design the Solution for
Logical Datastores for Project 8/23/201 8/24/2
2.2.1.17 Associate Module 0.5 days Analyst 6 016
Design the Solution for 8/24/201 8/24/2
2.2.1.18 Logical Datastores for CEO Module 0.5 days Analyst 6 016
8/24/201 8/26/2
2.2.2 Document 1.5 days Analyst 6 016
Analyst[50
%],Project
manager[50 8/26/201 8/30/2
2.2.3 Sign Off Design Phase 1 day %] 6 016
61.78 8/30/201 ######
2.3 Coding days 6 ###
Construct Development 8/30/201 8/31/2
2.3.1 Environment 0.5 days 6 016
Programmer
1[50%],Pro
grammer 8/31/201 9/14/2
2.3.2 Administrator Module 10 days 2[50%] 6 016
Programmer
1[50%],Pro
grammer 9/14/201 10/12/
2.3.3 Project Associate Module 20 days 2[50%] 6 2016
Programmer
1[50%],Pro
grammer 10/12/20 11/11/2
2.3.4 CEO Module 20 days 2[50%] 16 016
Programmer
1[50%],Pro
grammer 11/11/20 11/16/2
2.3.5 Document 3 days 2[50%] 16 016
Programmer
1[50%],Pro
grammer 11/16/20 11/22/2
2.3.6 Unit Testing 4 days 2[50%] 16 016

35
 ####### ######
2.3.6.1 Administrator Module 1 day # ##
####### ######
2.3.6.2 Project Associate Module 1 day # ##
####### ######
2.3.6.3 CEO Module 1 day # ##
####### ######
2.3.6.4 Document 1 day # ##
Construct Misc Elements of the 11/22/20 11/25/2
2.3.7 Solution 3.5 days 16 016
Analyst,Test ####### ######
2.3.7.1 0.5 days er 1,Tester # ##
2
Construct Testing Project ####### ######
2.3.7.2 Environment and Data 1.5 days manager # ##
Construct Implementation Project ####### ######
2.3.7.3 Compoonets 1.5 days manager # ##
Analyst,Proj
ect
manager,Pro
grammer
1,Programm
er 2,Tester 11/28/20 11/28/2
2.3.8 Sign Off Construct Phase 0.25 days 1,Tester 2 16 016
31.2 11/28/20 1/12/2
2.4 Testing days 16 017
Programmer
1[50%],Pro
grammer 11/28/20 12/13/
2.4.1 Resolve Bugs 10 days 2[50%] 16 2016
Testing Metrics(Total errors/
period, error categories, product defect 12/13/20 12/14/
2.4.2 metrics) 1 day Tester 1 16 2016
12/14/20 12/15/
2.4.3 Regression testing 0.75 days Tester 1 16 2016
12/15/20 12/16/
2.4.4 Managing Test Cases 0.75 days Tester 1 16 2016
12/16/20 12/16/
2.4.5 Validate Test Coverage 0.75 days Tester 1 16 2016
12/16/20 12/19/
2.4.6 Integration Test 0.75 days Tester 1 16 2016
Tester
1[50%],Test
er 2(User) 12/19/20 12/26/
2.4.7 System Test 4.5 days [50%] 16 2016

36
 ####### ######
2.4.7.1 Security Testing 1 day # ##
####### ######
2.4.7.2 Requirements Testing 0.5 days # ##
####### ######
2.4.7.3 Usability Testing 1 day # ##
####### ######
2.4.7.4 Interface Testing 0.5 days # ##
####### ######
2.4.7.5 Installation Testing 0.5 days # ##
####### ######
2.4.7.6 System Test Reporting 1 day # ##
Defect and Classification Tracking 12/26/20 12/29/
2.4.8 and methods 3 days 16 2016
Tester
1[50%],Test
er 2(User) 12/29/20 1/2/20
2.4.9 Update Files/Records 1 day [50%] 16 17
Tester
1,Tester
2(User),Proj
ect
manager,Pro 1/3/20
2.4.10 User Acceptance Testing 1 day ject Sponsor 1/2/2017 17
QA
Analyst,Test
er 1,Tester
2(User),Proj
ect
manager,Pro 1/12/201 1/12/2
2.4.11 Sign Off Test Phase 0.25 days ject Sponsor 7 017
9.97 1/12/201 1/26/2
3 Deployment days 7 017
Analyst,Pro
grammer
1,Program 1/12/201 1/13/2
3.1 Prepare for Implementation 1 day mer 2 7 017
1/13/201 1/23/2
3.2 User Training 6 days 7 017
1/13/201 1/17/2
3.2.1 Develop Training Materials 2 days Analyst 7 017
Analyst,Proj 1/17/201 1/23/2
3.2.2 Conduct Training 4 days ect manager 7 017
1/23/201 1/24/2
3.3 User Support Documentation 1 day Analyst 7 017

37
 Programme
r 1,Project 1/24/201 1/25/2
3.4 Implement the Solution/Go LIVE 1 day manager 7 017
Installation Management and 1/24/201 1/25/2
3.4.1 Coordination 0.5 days 7 017
Installation Performance 1/25/201 1/25/2
3.4.2 Monitoring 0.5 days 7 017
Analyst,Pro
ject
manager,Pr
oject
Sponsor,Pr
ogrammer 1/26/201 1/26/2
3.5 Sign Off Implementation Phase 0.5 days 1 7 017

38
7.2 Schedule Baseline

7.2.1 Milestone List

The table below shows the list of Project Milestones and their Target Date.

Table 10: Milestone List

No. Milestone Target Date
1 Sign-off acquire project team 06/10/2016
2 Sign-off Project Kickoff Meeting 07/04/2016
3 Sign- off Analysis Phase 08/08/2016
4 Sign-off Design Phase 08/30/2016
5 Sign-off Procurement 08/31/2016
6 Sign-off Construct Phase 11/28/2016
7 Sign-off Test Phase 1/12/2017
8 Sign-off Quality Assurance 1/10/2017
9 Sign-off Quality Control 1/12/2017
10 Sign-off Implementation Phase 1/26/2017
11 Sign-off Project Management 1/27/2017

39
7.3 Cost Baseline

The table below provides summary funding requirements along with their percentage to

the total budget with project cost contingency shown as a separate cost item.

Table 11: Summary of Project Funding Requirements

Item Description Estimated Cost Percentage

1 Software Cost Php 8,100.00 2.03%
2 Hardware/Network Cost Php 2140.00 0.54%
3 Operational Cost Php 20, 086.04 5.06%

4 Labour Cost Php 342,286.53 85.97%

5 Training Php 3,200.00 0.81%
6 Effort Cost Php 20,800.00 5.24%
Sub Total Php 396,612.57 100%
*** Contingency Php 51,559.63 13%
Total Cost Php 448,172.20

Cost Baseline S-Curve

₱500,000

₱375,000

₱250,000

₱125,000

₱0
June August October December
Baseline

Figure 4: Cost VS Time S-Curve

40
7.4 Quality baseline

Based on the gathered and elicited project requirements, company standards, and

applicable industry standards, the following quality metrics was established for this

project:

Table 12: Product Quality Baseline

Project Metric Measure Target
Objectives
Total elements usability index of all 70.00%
Usability elements
Total number of elements
Total actual response time of all 2-5 seconds
processes
Number of processes
Efficiency
Total handled transactions per > 4 Transaction
second

Total attributes of software that < 1.00%

1. Improve bear on frequency of failures
response time Total faults in the software
by 40% to
Total software faults per module < 1.00%
client Reliability
requirements Total software processes per
by reducing module
searching time Total recovery time <1
over collected
Standard recovery time
CVs to
increase Total present and appropriate tasks 95.00%
revenue. per module
Total required tasks per module
Total correct results per module 95%

41
 Total expected correct results per
Functional module
ity Total successful interaction with 95%
the database
Total interaction with the database
Total number of successful access 0%
of unregistered users
Total number of registered users
Total recovery time <1
Reliability
Standard recovery time
2. Provide a
Total data retrieval in seconds of all 2-5 seconds
single
processes per module
centralized Efficiency
storage for the Total process per module
CVs collected
over time Total number of successful access 0%
Functional of unregistered users
ity
Total number of registered users
Total elements usability index of all 70.00%
Usability elements
Total number of elements
Total actual response time of all 2-5 seconds
processes
Efficiency Number of processes
Total handled transactions per > 4 Transaction
second
Total attributes of software that < 1.00%
3. Allow the bear on frequency of failures
CEO to monitor Total faults in the software
CV uploading
Total software faults per module < 1.00%
activities (to the Reliability
centralized Total software processes per
storage) by module

42
project associate, Total recovery time <1
duration or both
in real-time. Standard recovery time
Total present and appropriate tasks 95.00%
per module
Total required tasks per module
Total correct results per module 95%
Total expected correct results per
Functional module
ity Total successful interaction with 95%
the database
Total interaction with the database
Total number of successful access 0%
of unregistered users
Total number of registered users

43
8.0 Management Plans

8.1 Scope Management Plan

8.1.1 Scope Management Approach

The scope for this project was defined through a comprehensive requirements collection

process. First, a thorough analysis was performed on the company’s current system based

on employee and user feedback through requirements eleicitation. From this information,

the project team developed the project requirements documentation, the requirements

management plan, and the requirements traceability matrix for what the new software

application must accomplish.

The project description and deliverables were developed based on the requirements

collection process and input from subject matter experts in software design, technical

support, programming and business applications. This process of expert judgment

provided feedback on the most effective ways to meet the original requirements of

providing a new software platform from which the company can improve its financial

tracking and internal financial processes. The scope will be defined through the Scope

Statement, WBS, WBS Dictionary and Statement of Work.

The scope will be measured and verified using Scope Baseline, Quality Checklists to be

created by the analyst.

44
For scope change, the Project Management Institute (PMI) philosophy of managing

change will be adapted wherein changes will be prevented if possible, if inevitable,

evaluate the impact of the change on the other constraints of the project then create

options to reduce the impact like compressing the schedule. After this, the change request

must be approved by the project manager then by the Project Sponsor.

The final deliverable and project acceptance will be forwarded to the project manager

first then to the Project Sponsor.

The analyst and project manager will be responsible for these activities.

8.1.2 Roles and Responsibilities

The table below shows the roles and responsibility for the Scope Management Plan

Table 12: Scope Management Plan Roles and Responsibilities

Role Responsibility

Analyst Responsible for the elicitation, validation and specification
of requirements

Responsible for the Requirements documentation,
requirements management Plan and Requirements
Traceability matrix

Responsible for creating the Scope Baseline and Quality
checklists

Responsible for the creating the final deliverables and
submitting it to the Project Manager

Responsible for creating and accomplishing change requests

45
 
Project Manager Responsible for the requirements verification

Responsible for creating the WBS, WBS Dictionary and
Statement of Work, work performance measurements,
Organizational process assets updates

Will approve the final project deliverables then forward it to
the Project Sponsor

Will be forwarding the project acceptance to Project
Sponsors

Project Sponsor Responsible for approving the final project deliverables and
project acceptance

8.1.3 Scope Definition

After the requirements collection, the scope will be define using the Project Charter,

Requirements documentation and Organizational process assets. Techniques like expert

judgement, product analysis, and alternatives identification will be used. Outputs like

Project scope statement and Project document updates will be expected. The Project

Scope must include scope description, acceptance criteria, deliverables, exclusions,

constraints and assumptions while updates must include stakeholder register.

Then from here the WBS can now be created by decomposition technique. Results shall

be the WBS, WBS Dictionary and Project Document Updates.

8.1.4 Scope Validation

The scope validation process focuses mainly on customer acceptance. The project

customer will formally accept all the project deliverables. This process will occur at the

46
end of each phase. During the process, the customer gives their feedback on the work that

was performed.

For validation, outputs from the previous stages are needed. Among these are the Project

Management Plan, Requirements Documentation, Requirements Traceability Matrix and

the validated deliverables. These will be measured, examined and work must be verified

versus requirements and acceptance criteria.

From here acceptable deliverable, change requests and project document updates must be

established.

Figure 5: Scope Validation Process Diagram

8.1.5 Scope Control

47
This process will involve the monitoring of the status of the project and management of

changes to the scope. The process will also involve the assessment of additional

requirements from the customer overlooking the project scope. Managers will measure

the work product against the scope baseline to ensure that the project stays on track to

prevent any unnecessary changes.

For this stage, the project management plan, work performance information,

requirements documentation, requirements traceability matrix and organizational process

assets are needed. Through variance analysis, cause and degree of variance vs. scope

baseline and corrective/ preventive actions can be determined.

After the variance analysis, the work performance measurements, corrective action

chosen, reasons and lesson learned and change requests must be established while

updated organizational process assets on causes of variances, and other updates on

management plan and documentation must be done.

48
 Figure 6: Scope Control Process Diagram

8.1.6 Scope Management Tools

1. WBS Template (Microsoft Office Excel)

2. WBS Dictionary (Microsoft Office Excel)

3. Requirements Documentation Template(Microsoft Office Word )

4. Requirements Traceability Matrix(Microsoft Office Word)

5. Change Requests Template (Microsoft Office Word)

6. Variance Analysis Results Template (Microsoft Office Word)

8.2 Change Management Plan

8.2.1 Change Management Approach

The change management plan will be consisted of three major steps – planning,

evaluating and approving. Planning is consisted by change control procedures and change

49
control plan while evaluating is consisted by change control meetings. Approving or

tracking is consisted by change control board, change authorization procedures and

change control system.

8.2.2 Definitions of Change

The table below shows the definition of each Classified Kind of Change that will be used

for the Project

Table 13: Definition for Kind of Change

Kind of Change Definition
1. Defect Repair Defects or nonconforming products which have already
been created as a result of project work must be modified or
repaired
2. Corrective Action An activity which realigns the project work, which is not
conforming to the project management plan
3. Preventive action An activity which ensures that the future project work will
be aligned with the project management plan
4. Updates Changes to the project management plan itself

8.2.3 Change Control Board

The change control board will be composed of the Project Manager, the Systems Analyst

and the Project Sponsor. The PMI philosophy are simplified by preventing changes if

possible, if inevitable, evaluate the impact of the change on the other constraints of the

project then create options to reduce the impact like compressing the schedule. After this,

the change request must be approved by the project manager then by the Project Sponsor.

50
8.2.4 Roles and Responsibilities

The table below shows the roles and responsibilities for the Change Management Plan.

Table 14: Change Management Roles and Responsibilities

Role Responsibility

Analyst Responsible for creating and accomplishing change
requests

Project Manager Will approve the change request then forward it to
the Project Sponsor

Project Sponsor Responsible for approving the change request.

8.2.5 Change Control Process

Figure 7: Change Control Process

8.2.6 Change Management Tools

1. Change Control Plan Template (Microsoft Office Word)

2. Change Control Meeting Minutes Template (Microsoft Office Word)

3. Change Request Template (Microsoft Office Word)

51
8.3 Requirements Management Plan

8.3.1 Requirements Management Approach

The approach we will use for requirements management for the project will be broken

down into four areas: requirements identification, requirements analysis, requirements

documentation, and ongoing requirements management.


Requirements Identification: The project team will facilitate various methods to

collect requirements which includes: one-on-one interviews with the stakeholder,

group interview with the Stakeholder, prototyping, follow people around Elicitation

Technique, questionnaires and surveys. These will be conducted among the project

stakeholders to ensure all requirements are captured.


Requirements Analysis: The project team will analyze requirements to determine if

they fall into project or product categories. Additionally, this analysis will determine

where in the WBS the requirements will fall or what work activities correspond to

particular requirements. Accountability and priority for each requirement will also be

determined as part of the analysis. Finally, metrics and acceptance criteria must be

determined for all requirements in order to provide a baseline for understanding when

a requirement has been fulfilled to an acceptable level.


Requirements Documentation: Once requirements have been identified and

analyzed, they will be documented and assigned to accountable personnel. These

requirements will be added to the project plan and the project team will determine

what methodology the accountable personnel will use to track and report on the status

of each requirement. All requirements will also be added to the project requirements

52
 checklist which must be completed before formal project closure is accepted by the

project sponsor.


Ongoing Requirements Management: Throughout the project lifecycle, the project

manager will ensure all team members are reporting requirement status and raising

any issues or concerns with their assigned requirements as appropriate. As the project

matures there may be situations in which requirements must change or be altered in

some way. The project team must follow the established change control process in

order to propose any changes to requirements and receive approval from the change

control board. Ongoing requirements management also includes receiving approval of

all requirements by all vested parties as part of project closure.

8.3.2 Roles and Responsibilities

The table below shows the roles and responsibilities for the Requirements management

Plan

Table 15: Roles and Responsibilities for the Requirements Management Plan
Role Responsibility

Analyst Responsible for requirements elicitation, specification,
validation and verification.

Responsible for the Requirements Analysis and Documentation

Responsible for creating and accomplishing change requests

53
 
Project Manager Responsible for requirements elicitation, specification,
validation and verification.

Responsible for ensuring all team members are reporting
requirement status and raising any issues or concerns with their
assigned requirements as appropriate

Will approve the change request then forward it to the Project
Sponsor

Responsible in making the necessary changes to the matrix and
communicate those changes to all project stakeholders.

Project Sponsor Responsible for approving the change request.

Programmer Responsible for prototyping

8.3.3 Requirements Prioritization Process

The Project manager will facilitate stakeholder meetings in order to establish priorities

for all project requirements. This project will use a three-level scale in order to prioritize

requirements.

The table below illustrates these levels and defines how requirements will be grouped:

Table 16: Requirements Priority Definition

Priority Level Definition
High These requirements are mission critical. They are required for
project/product success or for progression to the next project phase.
Medium These requirements support product/process operations but can be
completed under the next product release.
Low These requirements are quality and/or functional process
enhancements and are desirable if time and resources permit.

8.3.4 Configuration Management

54
For this project, the Requirements Management Plan will utilize the configuration

management activities outlined in the Configuration Management Plan. Key items

include documentation/version control and change control:

a) Documentation and Version Control: All project documentation will be loaded

into the Configuration Management Database (CMDB) as the central repository

for the project. Appropriate permissions will be granted to the project team for

editing and revising documentation. Any proposed changes to project requirements

must be reviewed by the Configuration Control Board (CCB) and have written

approval by the project sponsor before any documentation changes are made. Once

these proposed changes are approved and the documentation is edited, the project

manager will be responsible for communicating the change to all project

stakeholders.

b) Change Control: Any proposed changes in project requirements must be carefully

considered before approval and implementation. Such changes are likely to impact

project scope, time, and/or cost, perhaps significantly. Any proposed changes to

project requirements will be reviewed by the CCB. The role of the CCB is to

determine the impact of the proposed change on the project, seek clarification on

proposed change, and ensure any approved changes are added to the CMDB. The

project sponsor, who also sits on the CCB, is responsible for approving any

changes in project scope, time, or cost and is an integral part of the change review

and approval process.

55
8.3.5 Requirement Traceability Matrix

Below is the requirements traceability matrix template for the project. The purpose of the

requirements traceability matrix is to ensure all product requirements are completed in

accordance with the project charter. This matrix provides a thread from all product

requirements through design, testing, and user acceptance. Design document and charter

references are contained in the Project Configuration Management Plan. Any approved

changes in project scope or requirements will result in changes to the traceability matrix

below. Based on impacts of the approved changes, the Project Manager will make the

necessary changes to the matrix and communicate those changes to all project

stakeholders.

Table 17: Requirements Traceability Matrix Template

Project Name Business Area
Project Manager Business Analyst
Lead
QA Lead Target
Implementation
Date
Req. # Requirement Design Document Charter Test User Comme
Description Reference Reference Case Acceptance nts
Referen Validation
ce

1 xxxxxxxxxxxxxxxx XX-001 0.0.0 TS001

xxx
2 xxxxxxxxxxxxxxxx XX-002 0.0.0 TS002
xxx

8.3.6 Requirements Management Tools

56
 1. Requirements Traceability Matrix (Microsoft Office Word)

2. Stakeholder Meetings Minute Template (Microsoft Office Word)

3. Project Configuration Management Plan Template (Microsoft Office Word)

4. Prototyping (Visual Studio 2008)

8.4 Configuration Management Plan

8.4.1 Roles and Responsibilities

The table below shows the roles and responsibilities for the Configuration Management

Plan

Table 18: Configuration Management Plan Roles and Responsibilities

Role Responsibility
Analyst · Overall management of the CMDB
· Identification of CIs
· Providing configuration standards and templates to the project
team
· Providing any required configuration training
Project Manager · Overall responsibility for all CM activities related to the NexGen
project
· Identification of CIs
· All communication of CM activities to project stakeholders
· Participation in CCB meetings

Re-baselining, if necessary, any items affected by CM changes

Ensure all change requests comply with organizational templates
and standards prior to the CCB

Identification of CIs
Project Sponsor · Chairing all CCB meetings

Providing approval for any issues requiring additional scope,
time, or cost
C o n f i g u r a t i · Review and approve/reject configuration change requests
o n Control Board · Ensure all approved changes are added to the configuration
management database (CMDB)

Seeking clarification on any CIs as required

57
8.4.2 Configuration Control

The project will use a standardized configuration control process throughout the project

lifecycle in order to ensure all Configuration Items (CI) are handled in a consistent

manner and any approved changes are fully vetted regarding impact and communicated

to stakeholders.

As CIs are identified by the project team, the Configuration Manager will assign a CI

name and the CI will be entered into the CMDB in an “initiate” status. The CI will then

be assigned to an engineer focus group. Each member of a CIs focus group will have the

ability to access the CI through the CMDB, make changes and edits, and enter the CI

back into the CMDB with a description of the change/edit annotated in the CMDB log.

It is imperative that for any software changes testing is conducted by the focus group in

order to validate any changes made. The Project Manager assigned to manage the focus

group is responsible for ensuring that testing has been conducted, changes are entered

into the CMDB log, and that all changes/edits are saved properly into the CMDB. The

Project Manager is also responsible for assigning new version numbers and CMDB status

for any changes made by his/her assigned focus group.

Many times a CI will have a relationship with one or more other CIs within a project. The

Project Manager and the Analyst will work together to ensure these relationships are fully

58
understood. They will also then be responsible for illustrating these relationships and co-

dependencies in the CMDB to ensure a full understanding of each CI and how they relate

to one another.

Any configuration changes which are identified by the project team or stakeholders must

be captured in a configuration change request (CCR) and submitted to the CCB. The

CCB will review, analyze, and approve/deny the request based on the impact, scope,

time, and cost of the proposed change. If the change is approved, the project requirements

will be re-baselined (if necessary) and all changes will be communicated to the project

team and stakeholders by the Project Manager. Denied CCRs may be re-submitted with

additional or new information for re-consideration by the CCB.

8.4.3 Configuration Management Database

The Configuration Management Database (CMDB) will be the centralized repository for

all configuration information for the project. The CMDB provides a common platform

for the project team to edit, change, revise, and review CIs and also to ensure all

documents and data are updated with the latest revision and release formats.

Access to the CMDB will be granted and governed by standard UNIX permissions. Two

types of CMDB access will be granted for the project:

1. Full read and write access will be granted to the Analyst and Project

Manager. They will be authorized to access the CMDB to make

59
 changes, edit documents and data, and review and approve versions

and CI status.

2. Read only access will be granted to the Project Sponsor and all other

stakeholders. This access will allow these individuals to view all CIs

and CI data but they will not be authorized to make any changes. If

these individuals identify the need for a change or edit they will notify

the Analyst who will review the notification and provide feedback.

The CMDB will provide assurance that members of the project team are always working

off of the latest version of software, data, and documentation. However, it is important to

maintain the history of these assets throughout the project lifecycle. As these assets are

changed and updated, the Project Manager will be responsible for updating the status of

the CI and providing new revision numbering. This numbering will be done in

accordance with company’s standard revision control numbering process wherein higher

version numbers indicate more recent versions of the software, data, or documentation.

8.4.4 Configuration Status Accounting

It is important that for the project and the Project Sponsor have the ability to review

configuration status at any given time. The Project Manager will also submit weekly

reports, to include configuration status, every Friday. These reports will consist of the

following information as part of the configuration status section:

60
 1) Change requests

a. Aging - How long change requests have been open

b. Distribution – number of change requests submitted by owner/group

c. Trending – what area(s) are approved changes occurring in

2) Version Control

a. Software

b. Hardware

c. Data

d. Documentation

3) Build Reporting

a. Files

b. CI relationships

c. Incorporated Changes

4) Audits

a. Physical Configuration

b. Functional Configuration

Prior to any new software releases, the Analyst will work with the Project Manager

to ensure all CIs are updated with latest release versions.

61
8.4.5 Configuration Audits

Configuration audits will be an ongoing part of the project lifecycle. The purpose of the

configuration audit is to ensure all team members are following the established

procedures and processes for configuration management. Project audits for the Project

will occur prior to any major software release or at the Project Manager or Sponsor’s

discretion if they determine the need for one.

All configuration audits will be performed by the Analyst. Throughout the project the

Analyst works closely with Project Manager to ensure that all configuration processes

and procedures are being followed. As part of the configuration audit the Analyst will

perform the following tasks:

1. Establish an audit environment in the CMDB

2. The Analyst will copy all of the latest software, data, and document versions into

the audit environment

3. The Analyst will ensure all versions are correctly numbered and that version

control has been performed properly

4. The Analyst will analyze historical versions and timestamps of all software, data,

and documents to ensure all changes/edits were properly recorded and captured

5. The Analyst will copy latest software versions and conduct software testing to

ensure requirements are being met

6. The Analyst will ensure all required artifacts are present and current in the CMDB

62
 7. The Analyst will ensure all approved CCRs have been incorporated into the

project and are recorded in the CMDB

Once the audit has been performed, the Configuration Manager will compile his/her audit

findings. For each finding, the Analyst must work with the Project Manager/Team to

identify the corrective action(s) necessary to resolve the discrepancy and assign

responsibility for each corrective action. Upon completion of the project audit and

findings, the Analyst will note all discrepancies and compile a report to be presented to

the Project Manager and Sponsor.

8.4.6 Configuration Management Tools

1. Project Manager Weekly Report Template (Microsoft Office Excel)

2. Project Manager Weekly Report Template (Microsoft Office Word)

3. PowerShell DSC

8.5 Schedule Management Plan

8.5.1 Schedule Management Approach

Project schedules will be created using MS Excel 2010 starting with the deliverables

identified in the project’s Work Breakdown Structure (WBS). Activity definition will

identify the specific work packages which must be performed to complete each

deliverable. Activity sequencing will be used to determine the order of work packages

and assign relationships between project activities. Activity duration estimating will be

63
used to calculate the number of work periods required to complete work packages.

Resource estimating will be used to assign resources to work packages in order to

complete schedule development.

Once a preliminary schedule has been developed, it will be reviewed by the project team

and any resources tentatively assigned to project tasks. The project team and resources

must agree to the proposed work package assignments, durations, and schedule. Once this

is achieved the project sponsor will review and approve the schedule and it will then be

baselined.

The following will be designated as important activities related to the project schedule:

Completion of scope statement and WBS/WBS Dictionary

Baselined project schedule

Approval of final project budget

Project kick-off

Approval of roles and responsibilities

Requirements definition approval

Completion of data mapping/inventory

Project implementation

Acceptance of final deliverables

8.5.2 Roles and Responsibilities

The table below shows the roles and responsibilities for the Schedule Management Plan.

64
Table 19: Schedule Management Plan Roles and Responsibilities
Role Responsibility
Project Team · Responsible for participating in work package definition,
sequencing, and duration and resource estimating
· will also review and validate the proposed schedule and
perform assigned activities once the schedule is approved
· Providing configuration standards and templates to the project
team
· Providing any required configuration training

Project Manager Responsible for facilitating work package definition,
sequencing, and estimating duration and resources with the
project team

will also create the project schedule using MS Project 2007
and validate the schedule with the project team, stakeholders,
and the project sponsor

will obtain schedule approval from the project sponsor and
baseline the schedule

Project Sponsor will participate in reviews of the proposed schedule and
approve the final schedule before it is baselined

P r o j e c t · will participate in reviews of the proposed schedule and assist

Stakeholders in its validation.

8.5.3 Schedule Control

The project schedule will be reviewed and updated as necessary on a weekly basis with

actual start, actual finish, and completion percentages which will be provided by task

owners.

The project manager is responsible for holding weekly schedule updates/reviews;

determining impacts of schedule variances; submitting schedule change requests; and

reporting schedule status in accordance with the project’s communications plan.

65
The project team is responsible for participating in weekly schedule updates/reviews;

communicating any changes to actual start/finish dates to the project manager; and

participating in schedule variance resolution activities as needed.

The project sponsor will maintain awareness of the project schedule status and review/

approve any schedule change requests submitted by the project manager.

8.5.4 Schedule Changes and Thresholds

If any member of the project team determines that a change to the schedule is necessary,

the project manager and team will meet to review and evaluate the change. The project

manager and project team must determine which tasks will be impacted, variance as a

result of the potential change, and any alternatives or variance resolution activities they

may employ to see how they would affect the scope, schedule, and resources. If, after this

evaluation is complete, the project manager determines that any change will exceed the

established boundary conditions, then a schedule change request must be submitted.

Submittal of a schedule change request to the project sponsor for approval is required if

either of the two following conditions is true:

66
 
The proposed change is estimated to reduce the duration of an individual

work package by 10% or more, or increase the duration of an individual

work package by 10% or more.


The change is estimated to reduce the duration of the overall baseline

schedule by 10% or more, or increase the duration of the overall baseline

schedule by 10% or more.

Any change requests that do not meet these thresholds may be submitted to the project

manager for approval.

Once the change request has been reviewed and approved the project manager is

responsible for adjusting the schedule and communicating all changes and impacts to the

project team, project sponsor, and stakeholders. The project manager must also ensure

that all change requests are archived in the project records repository.

8.5.5 Schedule Change Control Process

Any changes in the project scope, which have been approved by the project sponsor, will

require the project team to evaluate the effect of the scope change on the current

schedule. If the project manager determines that the scope change will significantly affect

the current project schedule, he/she may request that the schedule be re-baselined in

consideration of any changes which need to be made as part of the new project scope.

67
The project sponsor must review and approve this request before the schedule can be re-

baselined.

8.6 Cost Management Plan

8.6.1 Cost Management Approach

Costs for this project will be managed at the third level of the Work Breakdown Structure

(WBS). Control Accounts (CA) will be created at this level to track costs. Earned Value

calculations for the CA’s will measure and manage the financial performance of the

project. Although activity cost estimates are detailed in the work packages, the level of

accuracy for cost management is at the third level of the WBS. Credit for work will be

assigned at the work package level. Work started on work packages will grant that work

package with 50% credit; whereas, the remaining 50% is credited upon completion of all

work defined in that work package.

Cost variances < 1 in the cost and schedule performance indexes will change the status of

the cost to cautionary; as such, those values will be changed to green in the project status

reports. Cost variances of > 1 in the cost and schedule performance indexes will change

the status of the cost to an alert stage; as such, those values will be changed to red in the

project status reports. This will require corrective action from the Project Manager in

order to bring the cost and/or schedule performance indexes below the alert level.

Corrective actions will require a project change request and be must approved by the

Project Sponsor before it can become within the scope of the project.

68
8.6.2 Roles and Responsibilities

The table below shows the roles and responsibilities for the Cost Management Plan.

Table 19: Schedule Management Plan Roles and Responsibilities

Roles Responsibilities

Project Manager The Project Manager will be responsible for managing
and reporting on the project’s cost throughout the
duration of the project.

During the monthly project status meeting, the Project
Manager will meet with management to present and
review the project’s cost performance for the preceding
month. Performance will be measured using earned
value.

The Project Manager is responsible for accounting for
cost deviations and presenting the Project Sponsor with
options for getting the project back on budget.

Project Sponsor The Project Sponsor has the authority to make changes
to the project to bring it back within budget.

8.6.3 Project Cost Measurements

Performance of the project will be measured using Earned Value Management. The

following four Earned Value metrics will be used to measure to projects cost

performance:


Schedule Variance (SV)

Cost Variance (CV)

Schedule Performance Index (SPI)

69
 
Cost Performance Index (CPI)

If the Schedule Performance Index or Cost Performance Index has a variance greater than

1 the Project Manager must report the reason for the exception. If the SPI or CPI has a

variance of less than 1 the Project Manager must report the reason for the exception and

provide management a detailed corrective plan to bring the projects performance back to

acceptable levels.

Table 20: Performance Measure Result Interpretation

Performance Measure Green Red
Schedule Performance Index (SPI) >1 <1
Cost Performance Index (CPI) >1 <1

8.6.4 Project Cost Reporting Format

Reporting for cost management will be included in the monthly project status report. The

Monthly Project Status Report will include a section labeled, “Cost Management”. This

section will contain the Earned Value Metrics identified in the previous section. All cost

variances outside of the thresholds identified in this Cost Management Plan will be

reported on including any corrective actions which are planned. Change Requests which

are triggered based upon project cost overruns will be identified and tracked in this

report.

70
8.6.5 Cost Variance Process

The Control Thresholds for this project is a CPI or SPI of less than 1 or greater than 1. If

the project reaches one of these Control Thresholds a Cost Variance Corrective Action

Plan is required. The Project Manager will present the Project Sponsor with options for

corrective actions within five business days from when the cost variance is first reported.

Within three business days from when the Project Sponsor selects a corrective action

option, the Project Manager will present the Project Sponsor with a formal Cost Variance

Corrective Action Plan. The Cost Variance Corrective Action Plan will detail the actions

necessary to bring the project back within budget and the means by which the

effectiveness of the actions in the plan will be measured. Upon acceptance of the Cost

Variance Corrective Action Plan it will become a part of the project plan and the project

will be updated to reflect the corrective actions.

8.6.6 Cost Change Control Process

The cost change control process will follow the established project change request

process. Approvals for project budget/cost changes must be approved by the project

sponsor.

8.6.7 Cost Management Tools

1. Earned Value Management Plan Template (Microsoft Office Word and Excel)

2. Cost Variance Corrective Action Plan (Microsoft Office Word)

71
8.7 Quality Management Plans

8.7.1 Quality Management Approach

The project team will work with the Quality Group to define and document all

organizational and project specific quality standards for both product and processes. All

quality documentation will become part of the Project Plan and will be transitioned to

operations upon the successful completion of the project.

Metrics will be established and used to measure quality throughout the project life cycle

for the product and processes. The QA Analyst will be responsible for working with the

project team to define these metrics, conduct measurements, and analyze results. Metrics

will focus on the following:


Schedule

Cost

Product and Process

o
Usability

o
Functionality

o
Reliability

o
Efficiency

Quality improvements will be identified by any member of the project team or by the

quality assurance analyst. Each recommendation will be reviewed to determine the cost

72
versus benefit of implementing the improvement and how the improvement will impact

the product or processes. If an improvement is implemented the project manager will

update all project documentation to include the improvement and the quality manager

will update the organizational documentation the improvement affects.

8.7.2 Roles and Responsibilities

The table below shows the roles and responsibilities for the Quality Management Plan.

Table 21: Quality Management Plan Roles and Responsibilities

Role Responsibility
QA Analyst 
Defining the testing activities for subordinates – testers or
test engineers.

All responsibilities of test planning.

To check if the team has all the necessary resources to
execute the testing activities.

To check if testing is going hand in hand with the software
development in all phases.

Prepare the status report of testing activities.

Required Interactions with customers.

Updating project manager regularly about the progress of
testing activities.

73
 Testers  To read all the documents and understand what needs to
be tested.
 Based on the information procured in the above step
decide how it is to be tested.
 Inform the test lead about what all resources will be
required for software testing.
 Develop test cases and prioritize testing activities.
 Execute all the test case and report defects, define severity
and priority for each defect.
 Carry out regression testing every time when changes are
made to the code to fix defects.

8.7.3 Quality Requirements/ Standards

For this project quality standards will be based from the attributes defined ISO 9126.

Quality metrics will be based from the following attributes defined in ISO 9126.

a) Functionality. Characteristics relating to achievement of the basic purpose

for which the software is being engineered.

b) Reliability. Characteristics relating to the capability of software to maintain

its level of performance under stated conditions for a stated period of time.

c) Usability. Characteristics relating to the effort needed for use and on the

individual assessment of such use, by a stated or implied set of users

d) Efficiency. Characteristics related to the relationship between the level of

performance of the software and the amount of resources used, under stated

conditions.

74
8.7.4 Quality Assurance

For the QA, the project management Plan which includes the Quality management plan,

Process Management Plan, Quality Metrics, Work performance information that includes

technical performance measures, project deliverables status, schedule progress and cost

incurred and quality control measurements are needed to initiate this step

75
For the Quality Assurance, activities below will be performed:

Table 23: QA Techniques Activities

Techniques Activities
Quality Audits – Are structured and independently reviewed to check the project
activities comply with organizational policies and procedures
– Identifying all of the good/best practices being implemented –
Identifying all the gaps/shortcomings
– Sharing the good practices introduced or implemented in similar
projects
– Proactively offering assistance in positive manner to improve
implementation of process to help the team raise productivity
– Highlighting contributions of each audit in the lesson learned
Process Analysis – Identifying needed improvements
– Examining experienced problems, constrains, and non-value
added activities
– Includes root cause analysis (problem, cause, preventive actions)

The quality manager will provide quality management and conduct process audits on a

weekly basis, monitor process performance metrics, and assure all processes comply with

project and organizational standards. If discrepancies are found, the QA Tester will meet

with the Project Manager and review the identified discrepancies.

The Project Manager will schedule regularly occurring project, management, and

document reviews. In these reviews, an agenda item will include a review of project

processes, any discrepancies and/or audit findings from the quality manager, and a

discussion on process improvement initiatives.

76
Process improvement is another aspect of quality assurance. Quality assurance reviews,

findings, and assessments will result in some form of process improvement and, as a

result, product improvement. All process improvement efforts must be documented,

implemented, and communicated to all stakeholders as changes are made.

8.7.5 Quality Control

The “V” Model will be used for the quality control of the project. This is to ensure that

the system is thoroughly tested and is aligned to the business requirements.

Figure 8: V Model Diagram

V model is a software development model that is based on the relationship between each

phase of the development life cycle as described in a typical Waterfall model of software

development and its associated phase of testing. The idea of the V-model is to have an

implementation plan for the software testing at each level namely component, interface,

77
system, acceptance and release of the software project which need to be adhered to

eliminate discrepancies in the software simultaneously rather than waiting for the

software development process to complete before handling it to the software testers.

The project team will document and finalize user requirements. The signed off user

requirements will be used by the System Analyst for designing the system. The developer

will then create a screen prototype to be approved by the Project Sponsor and Users. The

signed off design solutions will be coded by the Developers. The developers will then

setup and configure the test environment.

After coding the modules, the Developers will perform unit testing to evaluate if the

individual parts of the program are operating properly. Upon passing the unit and

function testing accordingly, the modules will be then integrated and tested. Integration

testing identifies problems that occur when modules are combined. Non-functional

testing will also occur during integration testing. Stress testing and performance testing

are included in the non-functional testing. When all the modules are integrated, system

testing through UAT will follow. This is to detect any inconsistencies between the

modules that are integrated and the hardware. System testing tests not only the design but

also the behavior and the expectations of the customer. Pilot run will follow after system

testing.

78
During UAT, the end users are invited to test the system to validate the functionalities

and to verify if the data generated are correct. Users will then sign off the UAT that will

signify that the system is ready for implementation.

8.7.6 Quality Control Measurements

All Project products and processes must be measured and fall within the established

standards and tolerances. The below log will be used by the project and quality teams in

conducting these measurements and will be maintained for use as supporting

documentation for the project’s acceptance.

79
The table below shows the Quality Assurance and Quality Control Log Template

Table 24: Quality Assurance and Quality Control Log Template

Tri D Process Required Actual Acceptable Recommen Date
al # at Measured Value Measured ? (Y/N) dation Resolve
e d

8.7.7 Quality Management Tools

1. Quality Assurance Log Template (Microsoft Office Word)

2. Quality Control Log Template (Microsoft Office Word)

3. Microsoft Office Excel

80
8.8 Risk Management Plan

8.8.1 Risk Management Approach

The approach we have taken to manage risks for this project included a methodical

process by which the project team identified, scored, and ranked the various risks. The

most likely and highest impact risks were added to the project schedule to ensure that the

assigned risk managers take the necessary steps to implement the mitigation response at

the appropriate time during the schedule. Risk managers will provide status updates on

their assigned risks in the weekly project team meetings, but only when the meetings

include their risk’s planned timeframe. Upon the completion of the project, during the

closing process, the project manager will analyze each risk as well as the risk

management process. Based on this analysis, the project manager will identify any

improvements that can be made to the risk management process for future projects. These

improvements will be captured as part of the lessons learned knowledge base.

8.8.2 Roles and Responsibilities

The table below shows the roles and responsibilities for the Risk Management Plan

Table 24: Risk Management Plan Roles and Responsibilities

Roles Responsibilities

Project Manager Serve as Risk manager

Approves Risk Management Plan

Define Risk management Plan

Participate in the risk management process

Maintain the risk register

Take the ownership of risk mitigation, planning and
execution

81
 
Project Sponsor Informed about major risks and provides input to risk
mitigation strategies

Participate in the risk management process

System Analyst Writes the Risk Management plan

Project Team Participates in the risk management process

8.8.3 Risk Identification

For this project, risk identification was conducted in the initial project risk assessment

meeting. The method used by the project team to identify risks was the Crawford Slip

method. The project manager chaired the risk assessment meeting and distributed

notepads to each member of the team and allowed 10 minutes for all team members to

record as many risks as possible.

a) Expert Interview: Two Expert Interviews were held for this project. The

interviews revealed several risks which were then mitigated by making

changes to the project plan. The remaining risks are included in the Risk

Register.

b) Risk Assessment Meeting: A risk assessment meeting was held with key

team members and stakeholders. The risks identified during this meeting were

added to the project plan and Risk Register.

c) Historical Review of Similar Projects: The project team reviewed the

history of similar projects in order to determine the most common risks and

the strategies used to mitigate those risks.

8.8.4 Risk Qualification and Prioritization

82
In order to determine the severity of the risks identified by the team, a probability and

impact factor was assigned to each risk. This process allowed the project manager to

prioritize risks based upon the effect they may have on the project. The project manager

utilized a probability-impact matrix to facilitate the team in moving each risk to the

appropriate place on the chart.

Once the risks were assigned a probability and impact and placed in the appropriate

position on the chart, the recorder captured the finished product and the project manager

moved the process on to the next step: risk mitigation/avoidance planning.

83
8.8.5 Risk Monitoring

The table below shows the sample Risk Mitigation Plan

Table 25: Sample Risk Mitigation Plan

RTP No.: 1 Project
RISK Phase: Integration Testing
MITIGATION
Milestone: Sign-off Testing Phase
Potential Failure: The modules produced is not efficient or optimal for deployment
Mitigation Plan: Systems Analyst should define standard method in using test
cases and test case summary

Detailed Remar
Steps Date of Completion ks Validated By

Verified By:
Name: Signature: Date:

Remarks:

Approved By:
Name: Signature: Date:

84
8.8.6 Risk Mitigation and Avoidance

The project manager has led the project team in developing responses to each identified

risk. As more risks are identified, they will be qualified and the team will develop

avoidance and mitigation strategies. These risks will also be added to the Risk Register

and the Project Plan to ensure they are monitored at the appropriate times and are

responded to accordingly. If necessary, the Risk Management Plan will be updated.

The risks for this project will be managed and controlled within the constraints of time,

scope, and cost. All identified risks will be evaluated in order to determine how they

affect this triple constraint. The project manager, with the assistance of the project team,

will determine the best way to respond to each risk to ensure compliance with these

constraints.

In extreme cases it may be necessary to allow flexibility to one of the project’s

constraints. Only one of the constraints for this project allows for flexibility as a last

resort. If necessary, funding may be added to the project to allow for more resources in

order to meet the time (schedule) and scope constraints. Time and scope are firm

constraints and allow for no flexibility. Again, the cost constraint is flexible only in

extreme cases where no other risk avoidance or mitigation strategy will work.

See details in Appendix I.

85
8.8.7 Risk Register Management

The risk register will be maintained in order to track risks and associated mitigation

strategies. This section describes the risk register criteria as well as where the risk register

is maintained and how these risks are tracked in the project schedule.

The Risk Register for this project is a log of all identified risks, their probability and

impact to the project, the project objective they belong to, mitigation strategy, and when

the risk will occur. The register was created through the initial project risk management

meeting led by the project manager. During this meeting, the project team identified and

categorized each risk. Additionally, the team assigned each risk a score based on the

probability of it occurring and the impact it could potentially have. The Risk Register

also contains the mitigation strategy for each risk as well as when the risk is likely to

occur.

Based on the identified risks and timeframes in the risk register, each risk has been added

to the project plan. At the appropriate time in the plan—prior to when the risk is most

likely to occur—the project manager will be the risk manager to ensure adherence to the

agreed upon mitigation strategy. The risk manager will provide the status of the risks at

the weekly project team meeting for the risk’s planned timeframe.

86
See details in Appendix I.

8.8.8 Risk Management Tools

1. Risk Mitigation Template (Microsoft Office Word)

2. Risk Register Template (Microsoft Office Word)

8.9 Human Resource Management Plan

8.9.1 Staffing Management

a) Staff Acquisition: The programmers will consist entirely of internal resources.

There will be outsourcing/contracting performed for the Project Manager, Analyst

and QA Analyst. The Project Manager will negotiate with the CEO in order to

identify and assign resources in accordance with the project organizational

structure. The testers will be coming from the Project Associates of the company.

The project team will not be co-located for this project and all resources will remain

in their current workspace.

b) Training: There is currently no training scheduled with regards to the Project since

the staffs has adequate required skill sets. However, if training requirements are

identified, funding will be provided from the project reserve.

c) Performance Reviews: The project manager will review each team member’s

assigned work activities at the onset of the project and communicate all

expectations of work to be performed. The project manager will then evaluate each

team member throughout the project to evaluate their performance and how

effectively they are completing their assigned work. Prior to releasing project

resources, the project manager will meet with the CEO and provide feedback on

87
 employee project performance. The CEO will then perform a formal performance

review on each team member.

d) Recognition and Rewards: Although the scope of this project does not allow for

ample time to provide cross-training or potential for monetary rewards there are

several planned recognition and reward items for project team members.


Upon successful completion of the project, any team member who satisfactorily

completed all assigned work packages on time will receive a certificate of thanks

from the CEO.

8.9.2 Human Resource Management Tool

1. Certificate Template (Microsoft Office Word)

2. Employee Project Performance Review Template (Microsoft Office Excel)

8.10 Communications Management Plan

8.10.1 Communication Management Approach

The Project Manager will take a proactive role in ensuring effective communications on

this project. The communications requirements are documented in the Communications

Matrix presented in this document. The Communications Matrix will be used as the guide

for what information to communicate, who is to do the communicating, when to

communicate it and to whom to communicate.

88
As with most project plans, updates or changes may be required as the project progresses

or changes are approved. Changes or updates may be required due to changes in

personnel, scope, budget, or other reasons. Additionally, updates may be required as the

project matures and additional requirements are needed. The project manager is

responsible for managing all proposed and approved changes to the communications

management plan. Once the change is approved, the project manager will update the plan

and supporting documentation and will distribute the updates to the project team and all

stakeholders. This methodology is consistent with the project’s Change Management

Plan and ensures that all project stakeholders remain aware and informed of any changes

to communications management.

8.10.2 Roles and Responsibilities

The table below shows the roles and responsibilities for the Communications

Management Plan.

Table 26: Communications Management Plan Roles and Responsibilities

Roles Responsibilities

b. Project Sponsor The project sponsor is the champion of the project
and has authorized the project by signing the project
charter.

This person is responsible for the funding of the
project and is ultimately responsible for its success.
Since the Project Sponsor is at the executive level
communications should be presented in summary
format unless the Project Sponsor requests more
detailed communications.

89
 
c. Program Manager The Program Manager oversees the project at the
portfolio level and owns most of the resources
assigned to the project. The Program Manager is
responsible for overall program costs and profitability
as such they require more detailed communications
than the Project Sponsor.

d. Key Stakeholders Normally Stakeholders includes all individuals and
organizations who are impacted by the project. For
this project we are defining a subset of the
stakeholders as Key Stakeholders. These are the
stakeholders with whom we need to communicate
with and are not included in the other roles defined in
this section.

The Key Stakeholders includes executive
management with an interest in the project and key
users identified for participation in the project.

e. Change Control The Change Control Board is a designated group
which is reviews technical specifications and
Board authorizes changes within the organizations
infrastructure.

Technical design documents, user impact analysis
and implementation strategies are typical of the types
of communication this group requires.

8.10.3 Communication Management Constraints

All project communication activities will occur within the project’s approved budget,

schedule, and resource allocations. The project manager is responsible for ensuring that

communication activities are performed by the project team and without external

resources which will result in exceeding the authorized budget. Communication activities

will occur in accordance with the frequencies detailed in the Communication Matrix in

order to ensure the project adheres to schedule constraints. Any deviation of these

90
timelines may result in excessive costs or schedule delays and must be approved by the

project sponsor.

Collar Finder organizational policy states that where applicable, standardized formats and

templates must be used for all formal project communications. Collar Finder

organizational policy also states that only the CEO may authorize the distribution of

confidential information. The project manager is responsible for ensuring that approval is

requested and obtained prior to the distribution of any confidential information regarding

this project.

8.10.4 Stakeholder Communication Requirements

As part of identifying all project stakeholders, the project manager will communicate

with each stakeholder in order to determine their preferred frequency and method of

communication. This feedback will be maintained by the project manager in the project’s

Stakeholder Register. Standard project communications will occur in accordance with the

Communication Matrix; however, depending on the identified stakeholder

communication requirements, individual communication is acceptable and within the

constraints outlined for this project.

In addition to identifying communication preferences, stakeholder communication

requirements must identify the project’s communication channels and ensure that

stakeholders have access to these channels. If project information is communicated via

91
secure means or through internal company resources, all stakeholders, internal and

external, must have the necessary access to receive project communications.

Once all stakeholders have been identified and communication requirements are

established, the project team will maintain this information in the project’s Stakeholder

Register and use this, along with the project communication matrix as the basis for all

communications.

8.10.5 Communication Methods and Technologies

The project team will determine, in accordance with the organizational policy, the

communication methods and technologies based on several factors to include:

stakeholder communication requirements, available technologies (internal and external),

and organizational policies and standards.

Collar Finder maintains a Dropbox platform within the office which all projects use to

provide updates, archive various reports, and conduct project communications. This

platform enables senior management, as well as stakeholders with compatible

technology, to access project data and communications at any point in time. Dropbox also

provides the ability for stakeholders and project team members to collaborate on project

work and communication.

92
Collar Finder maintains software licenses for MS Excel software. All project teams are

responsible for developing, maintaining, and communicating schedules using this

software. PERT Charts are the preferred format for communicating schedules to

stakeholders. The project schedule will be maintained on both the Dropbox platform.

All project communication and documentation, in addition to being maintained on the

Dropbox platform, will be archived on the internal Collar Finder shared drive which

resides in the PMO program directory. Organizational naming conventions for files and

folder will be applied to all archived work

93
8.10.6 Communication Matrix

The following table identifies the communications requirements for this project.

Table 27: Project Communication Requirements

Communic Objective Mediu Freque Audienc Owne Deliver Format
ation Type of m ncy e r able
Communic
ation
Kick-off Introduce - Face Once - Project Projec - - Soft
Meeting the project to Face Sponsor t Agenda copy
team and - Project Mana - archived
the project. Team ger Meeting on
Review - Minutes Dropbox
project Stakehol site and
objectives ders project
and website.
managemen
t approach.
Project Review - Face Weekly - Project Projec - - Soft
Team status of the to Face Team t Agenda copy
Meetings project with - Mana - archived
the team. Confer ger Meeting on
ence Minutes Dropbox
Call - site and
Project project
Schedul website.
e
Technical Discuss and - Face As - Project Techn - - Soft
Design develop to Face Needed Technica ical Agenda copy
Meetings technical l Staff Lead - archived
design Meeting on
solutions Minutes Dropbox
for the site and
project. project
website.

94
Weekly Report on - Face Monthl - PMO Projec - Slide - Soft
Project the status of to Face y t Updates copy
Status the project - Mana - archived
Meetings to Confer ger Project on
managemen ence Schedul Dropbox
t. Call e site and
project
website.
Project Report the - Email Monthl - Project Projec - - Soft
Status status of the y Sponsor t Project copy
Reports project - Project Mana Status archived
including Team ger Report on
activities, - - Dropbox
progress, Stakehol Project site and
costs and ders Schedul project
issues. - PMO e website.

95
8.10.7 Communication process

The communication flowchart below was created to aid in project communication. This

flowchart provides a framework for the project team to follow for this project. However,

there may be occasions or situations which fall outside of the communication flowchart

where additional clarification is necessary. In these situations the Project Manager is

responsible for discussing the communication with the Project Sponsor and making a

determination on how to proceed.

Does CEO

Meet CEO to make

Figure 9: Communication Process

8.10.8 Communication Standards

For this project, Collar Finder will utilize standard organizational formats and templates

for all formal project communications. Formal project communications are detailed in the

project’s communication matrix and include:

96
 a) Kick-off Meeting – project team will utilize Collar Finder standard templates for

meeting agenda and meeting minutes. Additionally, any slides presented will use the

Collar Finder standard slideshow template.

b) Project Team Meetings – project team will utilize Collar Finder standard

templates for meeting agenda and meeting minutes. Additionally, any slides

presented will use the Collar Finder standard slideshow template.

c) Technical Design Meetings - project team will utilize Collar Finder standard

templates for meeting agenda and meeting minutes. Additionally, any slides

presented will use the Collar Finder standard slideshow template.

d) Weekly Project Status Meetings - project team will utilize Collar Finder

standard templates for meeting agenda and meeting minutes. Additionally, any slides

presented will use the Collar Finder standard slideshow template.

e) Project Status Reports – project team will utilize Collar Finder standard

templates for meeting agenda and meeting minutes. Additionally the standard project

status report document, available on the share drive, will be used to provide project

status.

Informal project communications should be professional and effective but there is no

standard template or format that must be used.

8.10.9 Communication Escalation Process

97
Efficient and timely communication is the key to successful project completion. As such,

it is imperative that any disputes, conflicts, or discrepancies regarding project

communications are resolved in a way that is conducive to maintaining the project

schedule, ensuring the correct communications are distributed, and preventing any

ongoing difficulties. In order to ensure projects stay on schedule and issues are resolved,

Collar Finder will use its standard escalation model to provide a framework for escalating

communication issues.

The table below defines the priority levels, decision authorities, and timeframes for

resolution.

Table 28: Priority Levels Definition

Priority Definition Decision Timeframe for
Authority Resolution
Priority 1 Major impact to project or CEO/Project Within 4 hours
business operations. If not Sponsor
resolved quickly there will be a
significant adverse impact to
revenue and/or schedule.
Priority 2 Medium impact to project or CEO/Project Within one
business operations which may Sponsor business day
result in some adverse impact to
revenue and/or schedule.
Priority 3 Slight impact which may cause Project Within two
some minor scheduling difficulties Manager business days
with the project but no impact to
business operations or revenue.

98
 Priority 4 Insignificant impact to project but Project Work continues
there may be a better solution. Manager and any
recommendation
s are submitted
via the project
change control
process

8.11 Stakeholder Management Plan

8.11.1 Stakeholder Registry

Once all the project stakeholders have been identified, the project team will categorize

and analyse each stakeholder. The purpose of this analysis is to determine the

stakeholders’ level of power or influence, plan the management approach for each

stakeholder, and to determine the appropriate levels of communication and participation

each stakeholder will have on the project.

The project team will categorize stakeholders based on their department. Once all

stakeholders have been categorized, the project team will utilize a power/interest matrix

to illustrate the potential impact each stakeholder may have on the project. Based on this

analysis the project team will also complete a stakeholder analysis matrix which

illustrates the concerns, level of involvement, and management strategy for each

stakeholder.

99
The chart below will be used to establish stakeholders and their levels of power and

interest for use on the power/interest chart as part of the stakeholder analysis.

Table 29: Project Stakeholders Power and Interest

Key Department Name Power Interest
(1-5) (1-5)
A Top Management Hernard Honcolada 5 5
B Operations Cess Castro 1 2
C Operations Krissam Tapa 1 2
D Operations Emylou Llanes 1 2
E Operations Irene Esquillo 1 2
F Operations Joshua Saguid 1 2
G MIS/ Project Team Wilhelm Kaibigan 2 3
H MIS/ Project Team Jake Leuterio 2 3
I Project Team Jan Ludvik Raneses 5 5
J Project Team Systems Analyst 3 5
K Project Team QA Analyst 2 2

8.11.2 Stakeholder Analysis Matrix

Below is the power/interest chart for the project stakeholders. Each point represents a

stakeholder/s in accordance with the key in the chart above.

100
 K G, H

B-

Figure 10: Stakeholder Power-Interest Chart

Based on the power and interest analysis and chart above, stakeholders B, C, D, E, F and

K will require minimal management effort as they reside in the lower left quadrant of the

matrix. Stakeholder G and H in the lower right quadrant, must be kept informed through

frequent communication on project status and progress. Stakeholders A, I and J, in the

upper right quadrant, are key players and must be involved in all levels of project

planning and change management.

101
8.11.3 Stakeholder Management Strategy

The table below shows the Stakeholder Management Strategies.

Table 30: Stakeholder Management Strategy

Stakeho Concerns Quadrant Strategy

lder
A Product and Process must Key Give feedback to
comply acceptance criteria Player deliverables.
Clarify test and quality results
with the project manager, QA
Analyst and testers.
B Systems Analyst must clearly Minimal Clarify questions during
u n d e r s t a n d e n d - u s e r Effort requirements definition
perspective activities
C Systems Analyst must clearly Minimal Clarify questions during
u n d e r s t a n d e n d - u s e r Effort requirements definition
perspective activities
D Systems Analyst must clearly Minimal Clarify questions during
u n d e r s t a n d e n d - u s e r Effort requirements definition
perspective activities
E Systems Analyst must clearly Minimal Clarify questions during
u n d e r s t a n d e n d - u s e r Effort requirements definition
perspective activities
F Systems Analyst must clearly Minimal Clarify questions during
u n d e r s t a n d e n d - u s e r Effort requirements definition
perspective activities
G Questions regarding design Keep Work closely with the
solutions Informed systems analyst before
starting construct phase.
H Questions regarding design Keep Work closely with the
solutions Informed systems analyst before
starting construct phase.
I Resource and scheduling Key Obtain feedback on project
constraints for production once Player planning. Frequent
project is started communication and
addressing concerns are
imperative

102
J Ensures all design solutions Key Obtain feedback from project
w i l l be u n d e r s t o o d by Player sponsor and end-users to
Programmer ensure clarity of requirements
K Product and process must meet Minimal Communicate test results and
quality metrics Effort performance specifications
and obtain feedback on
customer requirements or any
changes. Provide frequent
status reports and updates.

103
8.12 Procurement Management Plan

8.12.1 Procurement Management Approach

The Project Manager will provide oversight and management for all procurement

activities under this project. The Project Manager will work with the project team to

identify all items to be procured for the successful completion of the project. The CEO

will review the procurement items, determine whether it is advantageous to make or buy

the items, and begin the vendor selection and purchasing. For purchases, direct

purchasing will be made since supplies to be purchased are just minimal.

Services to be procured for this project will be solicited under firm-fixed price contracts.

The project team will work with the contracts. The company’s hiring policy will be

implemented.

8.12.2 Procurement Definition

The following procurement items and/or services have been determined to be essential

for project completion and success. The following list of items/services, justification, and

timeline are pending PMO review for submission to the contracts and purchasing

department:

Table 31: Procurement Items and Justification

Item/Service Justification Needed By
Software

104
 Visual Studio Needed for software development 07/05/2016
Time Travel Tracing Needed for tracing previous versions of the 07/05/2016
software.
Hardware
UTP Cable Needed for network set up 08/31/2016
rj45 Needed for network set up 08/31/2016
Switch Needed for network set up 08/31/2016
Router Needed for network set up 08/31/2016

In addition to the above list of procurement items, the following individuals are
authorized to approve purchases for the project team:

Table 32: Authorized Team Members to Approve Purchases

Name Role
Jan Ludvik B. Raneses Project Manager
To Follow System Analyst

105
9.0 Appendices

9.1 APPENDIX A – Project Cost- Benefit Analysis

The table below shows the net present value in 5 years. 10% discount factor has been

used to calculate Net Present Value.

Table 33: Project Cost-Benefit Analysis

CollarFinder Management Consultancy Inc. Curriculum Vitae(CV) Management
System
DISCOUNT
RATE 0.1
Year CF DCF PV
0 -448,172.20 1 -448,172.20
1 2,851,200.00 0.909090909 2,592,000.00
2 2,851,200.00 0.826446281 2,356,363.64
3 2,851,200.00 0.751314801 2,142,148.76
4 2,851,200.00 0.683013455 1,947,407.96
5 2,851,200.00 0.620921323 1,770,370.88
NET PRESENT VALUE 10,360,119.04

Below is the detail of the computed benefit of Php 2, 851, 200. 00.

Table 34: Product Benefit Calculation

Benefits computed from

Commission (income) percentage 12% annual salary(12 - 18 months)

Lowest Salary in History 30,000.00
Annual Salary (12 months) 360,000.00
Income for placement 43200

Additional Placement using the system 66

106
 ₱2,851,200.0
Additional Income (Benefit ) 0

Table 35: Project Benefit Calculation Basis

66 additional Placements
Annual
Job Requirements from clients 230
Average Number of Entertained
requirements 130
Percentage 57%
Placement Percentage 66%
Annual Total Placements 86

Annual Total Working Days (Including Sat) 288

Average num of days spent on a req. 2 days
Average in hours 17.723 hours
** delay is on reviewing CVs
55% of time is consumed, 15% of time in
collecting new CVs, remaining 30%
is for contacting and processing
Time Spent on reviewing CVs 9.75 hours
Time Spent on Collecting new CVs 2.66 hours
Time Spent for contactinga nd
Processing 5.32 hours
Average Total time spent for a
requirement 17.72 hours
Using the system

Total Time spent on reviewing CVs

for a requirement would be reduced to 1 hour
Time Spent on Collecting new CVs 2.66 hours
Time Spent for contactinga nd
Processing 5.32 hours

107
 Average Total time spent for a
requirement 8.98 hours
Time saved 8.75 hours
Total Time saved in a year 1137.2 hours
Total time saved in a year in days 142.15 days
Additional number of requirements that can
be
entertained 127

108
9.2 APPENDIX B – Systems Requirements Specification

9.2.1 INTRODUCTION

Purpose

This specification documents the functional and non-functional requirements for

the Collar Finder Management Consultancy Inc. Curriculum Vitae Management

System (CFMCICVMS), including design constraints and other related factors, to

support the Collar Finder Management Consultancy Inc. Curriculum Vitae

Management System Product Vision document (see Appendix A)

Scope

This specification provides a comprehensive view of the requirements for

CFMCICVMS to implement the features and functionalities as specified in the

CFMCICVMS Product Vision document (see Appendix A)

9.2.2 PROJECT DESCRIPTION

Project Owner

The CFMCICVMS will be developed for Collar Finder Management Consultancy

Inc. Collar Finder Management Consultancy Inc. is an executive search firm. It

has been doing business for almost a year. Their corporate office is situated at

28th Floor Cityland Pasong Tamo Tower u2807 2210 Chino Roces Avenue

Makati City. Currently they have 5 Project Associates (working on different

clients’ requirements) working with the CEO/ Owner Mr. Hernard Honcolada.

109
Project Overview

CFMCI is an organization that aims for convenience, efficiency and consistency

that the CFMCI CV Management System can give. One similarity among

Executive Search firms is a long response time regarding client requirements.

This is a problem being faced by all and having this kind of application can help

lessen the response time and create a good relationship with the clients.

The centralization of processes is taking its rise in a lot of organizations

nowadays. Aside from the fact that is the current trend, organizations are taking

this opportunity to increase the quality of services they offer and increase profit.

CFMCI has been established for over a year and they have been finding ways of

how they can improve the business process to cater faster service and to have

higher profit. This product will be used to contribute to the fulfilment of its vision,

mission and goals. This solution will aid the whole organization in implementing

executive search activities wherein CV review which is the backbone of the whole

process will be very convenient and fast as the software will narrow down

possible candidates for different client requirements. This will also help the

organization in its goals in catering faster service to its clients. It will also save up

human resource efforts as well as man power costs.

110
Problem Statement

The problem of uncentralized organizing and managing of collected

CVs from executive search activities

affects the CEO, the Project Associates and the whole

institution of CFMCI

the impact of which time-consuming searching and reviewing activities

over collected Cvs for a possible candidate for a
certain client requirement

a successful solution An application which shall be used for a centralized

would be storage for the CVs collected over time, for
uploading CVs to the central storage with meta
tags(First Name,Middle Name, Last Name Position,
and extra 10 tags) with CV preview feature, for
editing the details of an Uploaded CV, for the CEO
to monitor CV uploading activities by project
associate, duration or both, for an easier manner of
searching through the CVs using last name of
candidate, word/phrase match and search tags , for
previewing and downloading searched CVs. This
would come with User Registration interface and an
Administrator interface for activating and
deactivating user accounts

Product Vision Statement

For the CEO and Project Associates

111
who have the need to make their type of work
convenient to perform as well as to maximize their
time and effort in performing daily task.
CFMCI CV is an application
Management System
that provides features user registration, administrator
interface for activating and deactivating user
accounts, an interface to store CVs into a
centralized storage, an interface for the CEO to
monitor CV uploading activities by project
associate, duration or both, an interface for an easier
manner of searching through the CVs using last
name of candidate, word/phrase match and search
tags.
Unlike the current system which is unorganized which
results to inconvenience when it comes to managing
the collected CVs over time and reviewing them
whenever there is a client requirement
our product will provide and interface for
- a centralized storage for the CVs collected over
time
- an interface for uploading CVs to the central
storage with meta tags(First Name,Middle Name,
Last Name Position, and extra 10 tags) with CV
preview feature
- an interface for editing the details of an Uploaded
CV
- an interface for the CEO to monitor CV
uploading activities by project associate, duration
or both
- an interface for an easier manner of searching
through the CVs using last name of candidate,
word/phrase match and search tags and
previewing CVs
- and interface for previewing and downloading
searched CVs
- User Registration interface
- An Administrator interface for activating
and deactivating user accounts

112
9.2.3 BUSINESS CONTEXT

Current Business Process

Project Associates save the collected CVs in different ways in each. Other Project

Associates cannot directly access the CVs collected by other Project Associates.

Searching through the CVs collected from the start of their operations is very

tiring and time consuming. Search accuracy is very low as it relies only in human

capabilities.

Sometimes, the CEO also perform searching activities and he needs to copy files

from each Project Associate every time. The CEO experience cannot monitor if

the subscription from different CV downloading sites like Monster.com are being

maximized.

Proposed Business Process

The diagram below shows the Proposed Business Process for the project.

113
 Figure 11: Proposed Business Process

9.2.4 SYSTEM OVERVIEW

System Perspective

Figure 12: System Perspective

114
System Interfaces

External Interfaces

There is no External Interface for the project

Hardware Interfaces

The table below shows the hardware interfaces needed for the project.

Table 36: Hardware Interfaces

Processor RAM Disk
(minimum) Space
Database server Intel iCore 3 2GB 1TB

Project Associate Intel Celeron 1.8GHz 1GB 500G

Terminal B
Operating server All Intel or AMD – 1Ghz 1GB 3GB

CFCMI CV Mgt Sys Intel iCore 3 1GB 500M

B
MySQL 5.7 All Intel or AMD – 1Ghz 256MB 100M
B

Software Interfaces

1. Project Associate / CEO / Administrator PC

- Windows 7 OS

- CFMCI CV Management System

2. CFMCICVMS Database Server

-MYSQL 5.7

3. Development

- Visual Basic 2008

- MYSQL 5.7

115
 - Apache

-Windows 7 OS

Communication Interface

- FTP

-ODBC- mySQLClient Connection

User Interfaces

The table below show the user interfaces for the project.

Table 37: User Interfaces

ID No. User Interface Description User

A1 Log- In UI Authentication / Project Associates,

Authorization CEO, Administrator
A2 User registration Registration for User Project Associates,
UI Accounts CEO, Administrator
A3 Manage Account Account details and Project Associates,
Password Update CEO, Administrator

B1 Project Associate Let the Project Associate Project Associate,

and CEO Search and the CEO Search CEO
CV UI through the CVs saved in
the storage
PA1 Project Associate Let The Project Project Associate
Upload CV UI Associate Upload CV/s
PA2 Project Associate Let the Project Associate Project Associate
Edit Uploaded Edit the details of the
CV Detail uploaded CV

116
CEO1 CEO View Let the CEO view CEO
Reports UI different Reports
regarding uploading
activities(by PA,
Duration, PA and
Duration or compare the
PAs in a certain
Duration)
AD1 Administrator Let the Administrator Administrator
Manage User activate and deactivate
Accounts UI registered user accounts

Assumptions and Dependencies

The following assumptions and dependencies of the capabilities of the CFMCI

CV management system as outlined in this document:

a. The development of the project will be dependent on the existing

hardware as the CEO wants to utilize existing hardware

b. For the initial run of the project, it will also use the existing storage

with the capacity of 10 TB. The CEO confirmed that a purchase for

an upgrade will be just made if the storage went full.

c. The system will be dependent to the 2 IT Personnels of CollarFinder

Consultancy who can perform 6 hours of development activities every

day. Both are capable of VB Programming as well as SQL coding.

They are also capable of doing many network structure.

117
 d. The system resources will be client-based while the database will be

server-based.

Summary of System Capabilities

The table below shows the summary of system capabilities of the product

Table 38: Summary of System Capabilities

Expected Benefits Solution Features

A more organized or a centralized storage for the CVs
standardized way of storing collected over time
collected CVs

Reduced searching time over a centralized storage for the CVs
thousands of CVs that they collected over time

have already collected over an interface for an easier manner of
time searching through the CVs using
candidates’ last name, word/phrase
match and search tags and previewing
CVs

an interface for editing the details of an
Uploaded CV

User Registration interface

Administrator interface for activating
and deactivating registered users

and interface for previewing and
downloading searched CVs

Reduced number of Project a centralized storage for the CVs
Associates needed to comply collected over time

with different client an interface for an easier manner of
requirements(direct effect to searching through the CVs using
man power cost) candidates’ last name, word/phrase
match and search tags and previewing
CVs

an interface for editing the details of an
Uploaded CV

and interface for previewing and
downloading searched CVs

118
 
Provided access to all of the a centralized storage for the CVs
collected CVs from different collected over time

sources (Applicants, CV an interface for an easier manner of
Downloading sites) of all searching through the CVs using
team members. candidates’ last name, word/phrase
match and search tags and previewing
CVs

and interface for previewing and
downloading searched CVs

User Registration interface

Administrator interface for activating
and deactivating registered users

Increased revenue of an an interface for uploading CVs to the
additional Php 4,050,000 in central storage with meta tags(First
just a year due to improved Name,Middle Name, Last Name
response time to client Position, and extra 10 tags) with preview
requirements resulting to feature

an interface for editing the details of an
Uploaded CV

an interface for the CEO to monitor CV
uploading activities by project associate,
duration or both

and interface for previewing and
downloading searched CVs

an interface for an easier manner of
searching through the CVs using
candidates’ last name, word/phrase
match and search tags and previewing
CVs

Monitoring capabilities for an interface for the CEO to monitor CV
the CEO over the CV uploading activities by project associate,
uploading activities duration or both

an interface for editing the details of an
Uploaded CV

9.2.5 USE CASE MODEL

119
Use Case Diagrams

1. Project Associate Use Case

Figure 12: Project Associate Use Case

2. CEO Use Case

Figure 13: CEO Use Case

3. Administrator Use Case

120
 Figure 14: AdminsitratorUse Case

Actor Catalogue

The table below shows the actors of the system together with their description.

Table 39: Actor Catalogue

ID No. Actor Description Represented user

1 Project People who works for Project Associates

Associate CFMCI by finding
possible candidates for
client requirement/s.
2 CEO People who owns the CEO
business. he sometimes
do searching activities
and monitors the
uploading activities of
the Project Associate
3 Administrator People managing the Administrator
Registered Account in
the System. Can
Manage his own
Account by updating his
user details and user
password

121
Use Case Catalogue

The table below shows the Use Case Details and Descriptions.

Table 40: Use Case Catalogue

ID No. Use Case Brief Description

UA-1 Identify Self PA, CEO and Adminstrator Log In.

Provide option for CEO and PAs if not
yet registered.
UA-2 Register Account Register a new Account for the PAs
and CEO.
UA-3 Manage Account PA, CEO and Adminstrator manage
Account. Update their user details and
user password. To update Password,
the current password must be entered
and confirmed correctly.
UB-4 Search Through Search, Preview or Download CV.
CVs Searching can be via Last Name,
Search Tag or Word/ Phrase Match

U1-1 Upload CVs Upload CV to the storage. The Project

Associate must upload unique files.

U1-2 Edit Detail of The Project Associate can edit the

Uploaded CV detail of an uploaded CV.

U2-1 View Uploading The CEO can generate reports to

Reports monitor the uploading activities of the
Project Associates

U3-1 Manage User The administrator can activate or

Accounts deactivate a user account which has
been registered.

122
Activity Diagrams

1. Manage Account: (UC- UA-3)

Figure 15: Manage Account Activity Diagram

2. Search through CVs: (UC – UB -4)

Figure 16: Search through CVs Activity Diagram

123
3. Upload CV: (UC – U1-1)

Figure 17: Upload CV Activity Diagram

4. Edit Detail of Uploaded CV: (UC- U1-2)

Figure 18: Edit Detail Uploaded Activity Diagram

124
5. View Upload Reports: (UC – U2 - 1)

Figure 19: View Upload Reports Activity Diagram

6. Manage User Accounts: (UC – U3-1)

125
Figure 20: Manage User Accounts Activity Diagram

Sequence Diagrams

1. Manage Account: (UC- UA-3)

Figure 21: Manage Account Sequence Diagram

2. Search through CVs: (UC – UB -4)

126
Figure 22: Search through CVs Sequence Diagram

3. Upload CV: (UC – U1-1)

Figure 23: Upload CV Sequence Diagram

127
 4. Edit Detail of Uploaded CV: (UC- U1-2)

Figure 24: Edit detail of Uploaded CV Sequence Diagram

5. View Upload Reports: (UC – U2 - 1)

Figure 25: View Upload Reports Sequence Diagram

128
 6. Manage User Accounts: (UC – U3-1)

Figure 26: Manage User Accounts Sequence Diagram

9.2.6 Specific Requirements

USE CASE Diagrams

Functional

Requirements

The table below shows the functional requirements for the product.

Table 41: Functional Requirements

D Requirement References
No.
1 All users must be asked first to enter user UC UA -1
name and password to enter the system
2 All users must be allowed to register an UC UA - 2
account

129
 3 All users must be allowed to update their UC UA– 3 ,
User Account details and User Password Activity Diagram #
1 and Sequence
Diagram # 1
4 The Project Associate and the CEO must UC UB-4,
be allowed to search through the uploaded Activity Diagram
CVs using Last Name, Search tags and #2 and Sequence
Word/Phrase Matches Diagram # 2
5 The Project Associate must be allowed to UC UB-4,
preview and download searched CVs Activity Diagram
#2 and Sequence
Diagram # 2
6 The Project Associate must be allowed to UC U1- 1, Activity
Upload CV/s Diagram #3 and
Sequence Diagram
#3

7 The Project Associate must be allowed to UC U1- 1, Activity

preview files before uploading Diagram #3 and
Sequence Diagram
#3

8 The Project Associate must be allowed to UC U1-2, Activity

edit the details of their uploaded CVs Diagram #4 and
Sequence Diagram
#4
9 The CEO must be allowed to view UC U2-1, Activity
different reports about the Uploading Diagram #5 and
activities of The Project Associates Sequence Diagram
#5
10 The Administrator must be allowed to UC U3 -1 ,
manage User Account Status (Activate or Activity Diagram
Deactivate) #6 and Sequence
Diagram # 6

Data Requirements

130
Entity Relationship Diagram

Figure 27: Data Requirements

Database Design

131
 Figure 28: Database Design

Business Rules

The table below shows the business rules of the company

Table 42: Business Rules

UC UA - 2
ID Business Rules Applies to. .
No.
1 User Account name must be consisted with the First Name and Users Table
the Last Name of the employee (Ex. SamSmith)
2 The user password must be a minimum of 6 alpha- numeric Users Table
characters
UC U1-1

1 The Project Associate cannot upload identical CVs Uploads

Table,
Activities
Table
UC U1 -2
1 The Project Associate cannot upload identical CVs Uploads
Table,
Activities
Table
UC U3-1
1 The User accounts status can be classified as Deactivated or UsersTable
Activated

132
Requirements

The table below shows the different metrics that the product must successfully pass on.

Table 43: Product Requirements

Project Objectives Metric Measure Target
Total elements usability index of all 70.00%
Usability elements
Total number of elements
Total actual response time of all 2 - 5
processes seconds
Number of processes
Efficiency
Total handled transactions per second > 4
Transactio
n

Total attributes of software that bear < 1.00%

on frequency of failures
3. Improve response
Total faults in the software
time by 40% to
client Reliability Total software faults per module < 1.00%
requirements by Total software processes per module
reducing
Total recovery time <1
searching time
over collected Standard recovery time
CVs to increase Total present and appropriate tasks 95.00%
revenue. per module
Total required tasks per module
Total correct results per module 95%
Total expected correct results per
Functionali module
ty Total successful interaction with the 95%
database
Total interaction with the database

133
 Total number of successful access of 0%
unregistered users
Total number of registered users
Total recovery time <1
Reliability
Standard recovery time
4. Provide a single Total data retrieval in seconds of all 2 - 5
centralized processes per module seconds
Efficiency
storage for the Total process per module
CVs collected
over time Total number of successful access of 0%
Functionali unregistered users
ty
Total number of registered users
Total elements usability index of all 70.00%
Usability elements
Total number of elements
Total actual response time of all 2 - 5
processes seconds
Number of processes
Efficiency
Total handled transactions per second > 4
Transactio
n
Total attributes of software that bear < 1.00%
3. Allow the CEO on frequency of failures
to monitor CV Total faults in the software
uploading activities
Reliability Total software faults per module < 1.00%
(to the centralized
storage) by project Total software processes per module
associate, duration Total recovery time <1
or both in real-time.
Standard recovery time
Total present and appropriate tasks 95.00%
per module

Total required tasks per module

134
 Total correct results per module 95%
Total expected correct results per
module
Functionali
ty Total successful interaction with the 95%
database
Total interaction with the database
Total number of successful access of 0%
unregistered users
Total number of registered users

135
Glossary

Candidate - A certain person possible for a Job

Client Requirement - Job Vacancy from a client that CFMCI needs to fill
in

Project Associate – Employees in-charge of finding a possible

candidate for a client requirement

Activate – Registered User Account Status allowed to Log

In to the System

Deactivate - Registered User Account Status NOT allowed

to Log In to the System

Acronyms and Abbreviations

CFMCI – Collar Finder Management Consultancy Inc.

CFMCIMS – Collar Finder Management Consultancy Inc.

Management System

CV – Curriculum Vitae

PA – Project Associate

CEO – Chief Executive Officer

136
APPENDIX

Table 43: List of Prototype Functionalities

ID Requirement References
No.
1 All users must be asked first to enter user name and UC UA -1
password to enter the system

2 All users must be allowed to register an account UC UA - 2

3 All users must be allowed to update their User Account UC UA– 3 , Activity
details and User Password Diagram # 1 and
Sequence Diagram #
1
4 The Project Associate and the CEO must be allowed to UC UB-4, Activity
search through the uploaded CVs using Last Name, Diagram #2 and
Search tags and Word/Phrase Matches Sequence Diagram #
2
5 The Project Associate must be allowed to preview and UC UB-4, Activity
download searched CVs Diagram #2 and
Sequence Diagram #
2
6 The Project Associate must be allowed to Upload CV/s UC U1- 1, Activity
Diagram #3 and
Sequence Diagram #
3

7 The Project Associate must be allowed to preview files UC U1- 1, Activity

before uploading Diagram #3 and
Sequence Diagram #
3

8 The Project Associate must be allowed to edit the details UC U1-2, Activity
of their uploaded CVs Diagram #4 and
Sequence Diagram #
4

137
 9 The CEO must be allowed to view different reports about UC U2-1, Activity
the Uploading activities of The Project Associates Diagram #5 and
Sequence Diagram #
5
10 The Administrator must be allowed to manage User UC U3 -1 , Activity
Account Status (Activate or Deactivate) Diagram #6 and
Sequence Diagram #
6

138
9.3 APPENDIX C – Project Methodology

INITIATION

PLANNING

EXECUTION

MONITORING AND CONTROL

Figure 29: Waterfall Approach

The project will follow a waterfall approach wherein it will be consist of the following

steps

1. Initiation

This is the start of the project, and the goal of this phase is to define the project in a

high level. This begun with a business case. This is where the research and proving

has been done. It is classified in this stage that the project must be undertaken.

Important stakeholders have their due diligence to help decide if the project is for

“go”. It is also when the project charter has been accomplished. The project charter

outlines the purpose and requirements of the project. This has included the business

needs, stakeholders and the business case.

139
2. Planning

This is a very crucial part of the approach since this focuses on developing a

roadmap that everyone must follow. This is where the goals have been set. The

S.M.A.R.T. method has been implemented. This method has been chosen because

this will ensure that the goals have been thoroughly vetted. It was also chosen

because it provides a way to clearly understand the implications of the goal-setting

process.

Also during this stage, the scope of the project was defined and the project

management plan was developed. Cost, quality, available resources and the realistic

time table was identified. The project plans also included establishing baselines

performance measures. These was generated through the scope, schedule and cost of

the project. The baseline has been identified because it is essential to determine if the

project is on track.

Roles and responsibilities were clearly defined. This will impose knowledge for

everyone regarding their involvement to the project and how they are accountable

for each assigned responsibility or task.

In this stage, the Scope Statement, Work Breakdown Schedule, Milestones, Gantt

Chart, Communication Plan and Risk Management Plan were made.

3. Execution

This is the phase where deliverables are developed and completed. Status reports and

meetings, development updates, and performance reports will be done here. This is

140
 also were the kick-off meeting will be done to officially start the Project Execution

where the teams member are informed.

During this phase the following will be accomplished:

a. Develop Team

b. Assign resources

c. Execute project management plans

d. Procurement management

e. Direction and management from the Project manager for the project

execution

f. Task assignments

g. Status meetings

h. Update on project schedule

4. Monitoring and Control

This is where the project progression and performance will be measured. Everything

will also be ensured that they are happening aligned with the project management

plan. Key performance indicators will be defined to determine that the project is on

track.

For this project, Project Objectives, Effort and Cost Tracking and Project

Performance will be used as KPI

141
142
9.4 APPENDIX D - Product Development Methodology

ANALYSIS
DESIGN
CODING
TESTING

Figure 30: Waterfall Product Development Methodology

The Waterfall methodology—also known as the Waterfall Model—is a sequential

software development process, where progress flows steadily toward the conclusion (like

a waterfall) through the phases of a project (that is, analysis, design, coding , testing).

1. Analysis

The product development team will analyze the requirements, and fully understand the

problems. This will be a research phase that will include no building except for the

prototyping. The team attempts to ask all the questions and secure all the answers they

need to build the product requirement.

For this phase, requirements will be specified using the 4 basic steps of requirements

definition – elicitation, validation, specification, and verification.

143
Activities for each step is enlisted below:

a. Elicitation

i. One- on- One Interview wiwth Stakeholder

ii. Group Interview with the Stakeholder

iii. Prototyping

iv. Conducting a Follow people Around Elicitation Technique

b. Validation

i. Consolidating the Requirements from Elicitation

ii.Rationalizing the Requirements

iii.Modeling the Requirements(UML, Data Models, DFD)

c. Specification

i. Prioritizing the Requirements

ii.Ensuring traceability of the Requirements

iii.Ensuring Testability of the Requirements

iv.Creating Business Requirements Report

144
 d. Verification

i. Requirements Review

ii. Obtaining Sponsor Sign off

During Analysis, activities like evaluating reuses, buy(rent), build alternatives, creating

requirements management plan and building conceptual Systems Design as well as

developing high level project strategies, capturing additional client information and

creating test cases will also be included.

2. Design

The analyst will design technical solutions to the problems set out by the product

requirements, including scenarios, layouts and data models. This phase will be

accompanied by documentation for each requirement, which enables other members of

the team to review it for validation.

3. Coding

First the programmers will be setting a development environment to work with. For the

software the technical implementation begins when the design has been approved. After

coding, Unit testing will be performed. Constructing miscellaneous elements of the

solution- testing environment and data, training content and implementation components

will be constructed. These steps will be accompanied by documentation.

4. Testing

145
Upon completion of full implementation, testing needs to occur before the product can be

released to customers. The software testing team will use the design documents, personas

and user case scenarios delivered by the product manager in order to perform the test

cases. Tests like regression testing, integration testing and system testing will be

performed.

146
9.5 APPENDIX E – Development Tools Specification

The table below shows the hardware needed for development

Table 44: Hardware needed for Development

Specific Detail/s Qty

Lenovo ThinkPad L430 · Intel Celeron (1.8 GHz) 2
2465 - C 1000M / 1.8 · 1 GB Memory 320 GB HDD
GHz · Intel HD Graphics 3000
· 1366 x 768
· Windows 7 Professional 64-bit
· DVD±R/RW

HPE ProLiant DL80 Intel® Xeon® E5-2600 v4 product 1
family

2 Processors

Memory: 3 TB

24 DIMM Slots

DDR4

1Gb 331i Ethernet Adapter 4 Ports
per controller

2 Flex Slot

6 Expansion Slots

The table below shows the software needed for development

Table 45: Software needed for Development

Specific Detail/s Qty
Visual Studio For creating the app for Windows by using 2
a single IDE
HelpNDoc Easy to use yet powerful help authoring 1
environment which can generate various
documentation formats from a single source
Time Travel Tracing Traces the process of execution and allow 1
debugger to move back and forth in the
process execution time.
RegexBuddy A very useful tool in working with regular 1
expressions

147
 Microsoft Office Word For documentation purposes 2
2013
Microsoft Office Excel For documentation purposes 2
2013

The table below shows the database tools needed for development

Table 46: Database Tools needed for Development

Specific Detail/s Qty
MySQL 5.7 MySQL is an open-source relational 1
database management system. It is one of
the most widely used dbms. Programmers
are literate with this.
MySQL Connector – net An extension that is needed to connect the 1
6.9.8 VB program to the dbms

148
9.6 APPENDIX F – Infrastructure Specifications

Figure 31: Infrastructure Specifications

Each end-user will be working from their work stations and will be given their own

access level. The client terminals will be connected to the server through a wired Local

Area Network to assure reliability and speed within transactions. This is a low-cost yet

effective kind of solution for the proposed system. The system will have client-based

resources and server-based database. This kind of structure has been chosen because of

the fact that the system will be process-based. Process based in the sense that data storage

and retrieval must be smoothly done and having this kind of structure will prevent too

much data traffic since the end-users are expected to engage with the system concurrently

149
9.7 APPENDIX G – Detailed Schedule

A. Gantt chart.

The tables below represents the summary of the schedule of the project.

Table 47: The Detailed Schedule of the Project

Tasks 1- 51

150
151
Tasks 51- 100

152
153
Tasks 101-141

154
155
9.8 APPENDIX H – Detailed Funding Requirements and Cost Estimates

A. Labor Cost Estimates.

The table is broken down per role, estimated number of man-hour per role, the
rate per hour and its total cost

Table 48: Labour Cost Estimates

NO. OF MAN TOTAL
LABOR COST HOUR Rate / HR COST
Roles
Project Sponsor 32.67 ₱400.00 ₱13,068.00
₱102,756.4
Project Manager 277.72 ₱370.00 0
System Analyst 460.65 ₱210.00 ₱96,736.50
Programmer 1 316.38 ₱187.50 ₱59,321.25
Programmer 2 211.17 ₱187.50 ₱39,594.38
QA Analyst 60 ₱200.00 ₱12,000.00
Tester 1 111.05 ₱100.00 ₱11,105.00
Tester 2 77.05 ₱100.00 ₱7,705.00
₱342,286.5
TOTAL 3

B. Schedule Cost Estimates.

The table shows the schedule based on the project plan. The schedule is broken
down into project phases.
Table 49: Schedule Cost Estimates
PROJECT PHASE NO. OF MAN DAYS
PROJECT MANAGEMENT 36
Project Initiation 7

156
 Project Planning 10
Execution 11.5
Monitoring & Control 7.25
PM Sign-Off 0.25
EXECUTION 131.03
Analysis 22.3
Software Design 15.75
Coding 61.78
Testing 31.2
DEPLOYMENT 10
TOTAL 177.03

157
C. Hardware and Software Cost.

The table below shows the Hardware and Software costs of the project.
Table 50: Hardware and Software Costs
TOTAL
QTY UNIT UNIT PRICE COST
Software
Visual Studio 2 pcs ₱3,000.00 ₱6,000.00
HelpNDoc (Open Source) 1 pc ₱0.00 ₱0.00
Time Travel Tracing 1 pc ₱2,100.00 ₱2,100.00
RegExBuddy(Open Source) 1 pc ₱0.00 ₱0.00
Microsoft Office
Word 2013(pre- 2 pcs ₱0.00 ₱0.00
installed)
Microsoft Office
Excel 2013(pre- 2 pcs ₱0.00 ₱0.00
installed)
Hardware/Network
UTP Cable 50 meters ₱20.00 ₱1,000.00
rj45 20 pcs ₱7.00 ₱140.00
Switch 1 pc ₱500.00 ₱500.00
Router 1 pc ₱500.00 ₱500.00
Lenovo ThinkPad L430 2465 -
C 1000M / 1.8 GHz (existing) 5 pcs ₱0.00 ₱0.00
HPE ProLiant DL80
Server(existing) 1 pcs ₱0.00 ₱0.00
TOTAL ₱10,240.00

158
D. Operation Cost

The table below shows the Operations Cost of the project.

Table 51: Operation Costs
TOTAL
QTY UNIT UNIT PRICE COST
Operation Cost
Electricity (Aircon + computer 1545.
units) 08 hours ₱13.00 ₱20,086.04
TOTAL ₱21,614.71

E. Training & Effort Cost

The table below shows the Training and Effort Costs for the Project
Table 52: Training and Effort Costs
UNIT TOTAL
QTY UNIT PRICE COST
Training 4 days ₱800.00 ₱3,200.00
Effort Cost ₱20,800.00
meeting
Meetings 32 s ₱550.00 ₱17,600.00
Communications 32 weeks ₱100.00 ₱3,200.00
TOTAL ₱24,000.00

159
9.9 APPENDIX I – Risk Register

A. Risk Measurements Definition

The tables show on how to assess risk and calculate risk rating given the
following as reference.

Table 53: Risk Measurements Definition

RISK SYMBO
MEASUREMENT L DEFINITION
Severity Rating SR Impact to the Project

Probability Rating PR Probability of Potential failure to happen

B. Risk Measurements Definition – Severity Level

The table below shows the description of the Severity levels to be used in this project.
Ta b lCe .54: Risk Measurements Definition – Severity Level

SEVERITY
LEVEL RATING DESCRIPTION
More than an hour, less than a day delay to the
Low 1 project

More than a day, less than a week delay to the

Medium 2 project

Severe 3 More than a week of delay to the project

The table below shows the Risk Frequency Probability.

Ta b lDe .55: Risk Measurements Definition – Frequency of Occurrence

PROBABILITY RATING DESCRIPTION

Low 1 20% below probability

Moderate 2 21%- 50%

160
 High 3 51% above

C. Risk Calculation

The formula to determine the risk rating is:

D. RR = SR + OR
where, RR is the Risk
Rating SR is the
Severity Rating OR is
the Occurrence Rating

D. Acceptable Level Definition

The table shows the Acceptable level of Severity and the

Frequency of happening

Table 56: Acceptable Level Definition

RISK MEASUREMENT SYMBOL RATING
Severity Rating SR 2

Occurrence Rating OR 2

This mean that risk rating with the value of 4 or less than 4 is acceptable. While risk
rating with higher value of 4 is not acceptable and those potential failures are need to be
mitigated.

161
 E. Risk Register

The table below shows the risks of the project alongside with each probability,
impact, preventive action and risk assessment
Table 57: Risk Register
Milesto Targ Risk Preventive S P R Ris Risk Mitigation
ne et Action R R R k Prior
Date Asse ity
ssme
nt
Sign-off 06/10 Acquiring project Have advanced 3 2 5 Miti 2 If unavoidable,
acquire /2016 team takes longer p o s t i n g s o n gate p r i o r i t i z e the
proj ect than expected d i f f e r e n t Systems Analyst
team platforms. since it is urgent.
Then exten
dacquiring
ofotherproj
e c t team
members up to
5 days.
Sign-off 07/04 A n u m b e r o f Communicate to 1 1 2 Acce -
Project /2016 stakeholders are stakeholders in pt
Kickoff not available advance through
Meeting email and secure
commitment
.Reschedule
earlier if there
will be
unavailability of
stakeholders
Assigned activities Discuss scope of 2 3 5 Miti 3 Include scope of
to project team a s s i g n e d gate assigned tasks to
members may lack activities during contract
on details which kickoff meeting.
are important to the
project
S i g n - 08/08 Interview with the P r e p a r e a n d 2 3 5 Miti 4 Upon realization
o f f /2016 stakeholder/s are c a t e g o r i z e gate of a neglected
Analysis ineffective as some i n t e r v i e w requirement
Phase requirements are questions as well ,
not mentioned or a s f o l l o w u s e n d
discussed p questions prior communication
to interview. (following the
communication
escalation
process) to
stakeholder to
ask about the
requirement.

162
 A number of Let interviewee 1 3 4 Acce -
business process/es enumerate all pt
was not performed b u s i n e s s
during follo processes during
wpeople arou interview. Enlist
n d elicitation and set as guide
during follow
people around
elicitation.
S yst em anal yst Counter check 1 3 4 Acce -
failed to specify requirements pt
details of certain versus business
requirement process.
R e q u i r e m e n t Set rubrics for 1 3 4 Acce -
prioritization was r e q u i r e m e n t pt
incorrect prioritizatio
n scheme.
Traceability Align traceability 1 1 2 Acce -
measures are measures t pt
improper for some o industry
a n u m b e r o f standards
requirements
Testability Align testability 1 1 2 Acce -
measures are measures t pt
i m proper for a o industry
n u m b e r o f standards
requirements
Some existin Get a l i s t of 3 1 4 Acce -
g resources are not m a t e r i a l s pt
considered for the inventory from
solution the CEO.
Approval of Provide graphic 1 1 2 Acce
Requirements takes representations pt
longer than to presentations
expected and reports to
impose higher
understanding.
Sign-off 08/30 S t a n d a r d s a n P r o v i d e 2 1 3 Acce -
D e s i /2016 d guidelines for the guidelines first pt
g n modules have not before designing.
Phase been clearly
defined
The design solution Consult the MIS 3 1 4 Acce -
for the modules are department pt
inappropriate for before finalizing
the a v a i l a b l e the design
resources solutions.

163
 The Project Update the 1 1 2 Acce -
Management project manager pt
Document has not regarding new
been updated details and
updates during
the meeting and
let the analyst
update first
documents
b e f o r e
proceeding to
next steps.
Approval of Design Provide graphic 1 1 2 Acce
Solutiontake representations pt
slonger than to presentations
expected and reports to
impose higher
understanding.
Sign-off 08/31 Different actual Base SRP from 1 2 3 Acce -
Procure /2016 cost of materials c a n v a s s i n g pt
ment f rom suggest ed activity.
retail prices
Sign-off 11/28 D e l a y o n t h e Programmer 2 3 3 6 Miti 1 Have the absent
Constru /2016 coding process and must be always gate programme
ct Phase constructing i n f o r m e d rmake up
implementati r e g a r d i n g absences through
onc o m p o n e n progress of weekends
t sbecause of Programmer 1
a n emergency
from o n e o ft h e
programmers
Too many errors/ Unit Test after 3 1 4 Acce -
bugs have been every function to pt
detected during p r e v e n t
Unit testing cumulative bugs.
P r o j e c t Update the 1 1 2 Acce -
management Plan project manager pt
Document has not regarding new
been updated details and
updates during
the meeting and
let the analyst
update first
documents
b e f o r e
proceeding to
next steps.

164
 T e s t i n g The quality 1 1 2 Acce -
Environment and analyst must pt
data is ensure that the
inappropriate with t e s t i n g
the designed environment and
solution data is
appropriate by
reviewing versus
the b usi ne ss
process and
i n d u s t r y
standards.
Sign-off 1/12/ R esol ving bugs Report bugs as 3 2 5 Miti 5 Have 2
T e s t 2017 takes longer than s o o n a s t h e gate programmers
Phase expected yhave been work for a bug
detected
Testing Metrics are Testing metrics 2 2 4 Acce -
incomplete must be pt
coordinated to
the project
manager an
d system analyst
to e n s u r e
appropriateness
a n d
completeness
Fi xing defect s/ Fix defects 3 2 5 Miti 6 Have 2
errors/bugs takes / errors/bugs as gate programmers
longer than soon as they are work for a bug
expected reported
Sign-off 1/10/ R e v i e w s a n d Prepare all things 2 2 4 Acce -
Quality 2017 Audits took longer needed before pt
Assuran than expected Reviews an
ce d Audits to save
time.
Project Sponsor is Provide email 1 2 3 Acce -
not available for report. Proceed pt
the meeting of the through video
Audit Activity or conferencing if
Close Audit possible or video
recording as last
option.
Sign-off 1/12/ UAT takes longer Let users test 2 2 4 Acce -
Quality 2017 than expected through cross pt
Control examining versus
d e f i n e d
requirements and
quality measures

165
Sign-off 1/26/ End users have Provide 15 3 2 5 Miti 7 P r o v i d e CB T
Impleme 2017 longer learning v a r i a t i o n gate materials s
ntatio c u r v e t h a n examples o o users can
n Phase expected f transactions per review things at
module. Discuss home
their concerned
modules only
Training materials P r o v i d e 1 1 2 Acce -
are inadequate additional pt
t r a i n i n g
materials(Total
numbers of
trainee + (Total
numbers of
trainee * 20% ))
User Support Update the 1 1 2 Acce -
Documentation has project manager pt
not been updated regarding new
details and
updates during
the meeting and
let the analyst
update first
documents
b e f o r e
proceeding to
next steps.
Sign-off 1/27/ Unavailability of Send emails 5 1 1 2 Acce -
Project 2017 stakeholders for the days before close pt
Manage project close out out and secure
ment confirmation. If
inevitable,
reschedule to an
earlier time.
Approval t akes Provide graphic 1 2 3 Acce
l o n g e r t h a n representations pt
expected to presentations
and reports to
impose higher
understanding.

166