/SPMP

SOFTWARE PROJECT MANAGEMENT PLAN

(SPMP)

for the

Marks Collecting System

(MCS)

of the

Course Name:

Software Engineering Project

(MANP 1135)

Prepared by:
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

Saba Zahedieh
Hoang Tran Khoi Nguyen
know them without prior written consent of RFTI-UTM.

Hu XinBin

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS)

A4 2.0 COVER
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be
Reproduced nor disclosed to any person except to those having a need to
know them without prior written consent of RFTI-UTM.

Client
Manager
Verified By:

Approved By:
Project Manager

Authenticate By:

___________________
____________________
____________________

Software Work Package

SYSTEM NAME
Name
SIGNATURE PAGE

Mark Collection System (MCS)

A4
FORMAT
DOCUMENT IDENTIFICATION
Date

2.0
VERSION

i
PAGE
/SPMP
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be
Reproduced nor disclosed to any person except to those having a need to
know them without prior written consent of RFTI-UTM.

Revision
Written by

Verified by

Approved by
Authenticated by
E
B

D
C
A
REVISION

A
B

SYSTEM NAME

Mark Collection System (MCS)

CHANGE HISTORY

A4
FORMAT
D

DOCUMENT IDENTIFICATION
DESCRIPTION

2.0
VERSION
E

ii
PAGE
/SPMP
 /SPMP

Table of Contents

List of Figure ............................................................................................................................................ v

List of Table ............................................................................................................................................. vi
1. OVERVIEW ............................................................................................................................. 1
1.1. Project Summary ..................................................................................................................... 1
1.1.1. Purpose, Scope and Objective .......................................................................................................... 1
1.1.1.1. Purpose ............................................................................................................................................. 1
1.1.1.2. Scope ................................................................................................................................................ 1
1.1.1.3. Objective........................................................................................................................................... 1
1.1.2. Assumptions and Constraints ........................................................................................................... 1
1.1.2.1. Assumptions ..................................................................................................................................... 1
1.1.2.2. Constraints ........................................................................................................................................ 1
1.1.3. Project Deliverables .......................................................................................................................... 1
1.1.4. Schedule Summary ........................................................................................................................... 2
1.2. Evolution of the Project Management Plan ........................................................................... 2
2. REFERENCES ......................................................................................................................... 2
3. DEFINITIONS AND ACRONYMS ....................................................................................... 3
4. PROJECT ORGANIZATION ................................................................................................ 4
4.1. Interfaces .................................................................................................................................. 4
4.2. Internal Structure .................................................................................................................... 4
4.3. Roles and Responsibilities ....................................................................................................... 5
5. MANAGERIAL PROCESS PLAN ........................................................................................ 5
5.1. Start-up Plan ............................................................................................................................ 5
5.1.1. Estimation Plan ................................................................................................................................ 5
5.1.2. Staffing Plan ..................................................................................................................................... 5
5.1.3. Resource Acquisition Plan ............................................................................................................... 6
5.1.4. Project Staff Training Plan ............................................................................................................... 7
5.2. Work Plan ................................................................................................................................. 7
5.2.1. Work Activities ................................................................................................................................. 7
5.2.2. Schedule Allocation .................................................................................................................... 8
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

5.2.3. Resource Allocation .................................................................................................................... 9

© All Copyrights Reserved, 2021 and confidential. They shall not be

5.2.4. Budget Allocation ....................................................................................................................... 9

5.3. Control Plan ............................................................................................................................... 9
know them without prior written consent of RFTI-UTM.

5.3.1. Requirements Control Plan ......................................................................................................... 9

5.3.2. Schedule Control Plan ................................................................................................................. 9
5.3.3. Budget Control Plan .................................................................................................................... 9

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) iii

A4 2.0
 /SPMP

5.3.4. Quality Control Plan.................................................................................................................... 9

5.3.5. Reporting Plan ........................................................................................................................... 10
5.3.6. Metrics Collection Plan ............................................................................................................. 10
5.4. Risk Management Plan............................................................................................................. 11
5.5. Closeout Plan ........................................................................................................................... 12
6. Technical Process Plans ............................................................................................................. 12
6.1. Process Model .......................................................................................................................... 12
6.2. Methods, Techniques and Tools............................................................................................... 12
6.2.1. Development Methodology ....................................................................................................... 12
6.2.2. Diagrams ................................................................................................................................... 13
6.2.3. Programming Languages and Tools .......................................................................................... 13
6.2.4. Software development techniques ............................................................................................. 13
6.3. Infrastructure Plan .................................................................................................................... 14
6.3.1. Software Infrastructure .............................................................................................................. 14
6.3.2. Hardware Infrastructure ............................................................................................................ 14
6.4. Product Acceptance Plan .......................................................................................................... 14
7. SUPPORTING PROCESS PLAN ............................................................................................ 15
7.1. Configuration Management Plan.............................................................................................. 15
7.2. Verification and Validation Plan .............................................................................................. 15
7.3. Documentation Plan ................................................................................................................. 16
7.4. Quality Assurance Plan ............................................................................................................ 16
7.5. Review and Audits ................................................................................................................... 16
7.6. Problem Resolution Plan .......................................................................................................... 17
7.7. Subcontractor Management Plan.............................................................................................. 17
7.8. Process Improvement Plan ....................................................................................................... 17
8. ADDITIONAL PLANS.............................................................................................................. 17
APPENDIX A ......................................................................................................................................... 18
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) iv

A4 2.0
 /SPMP

List of Figure

Figure 1: Interfaces between internal and external entities ................................................................... 4

Figure 2: Project Organization (Internal Structure) .............................................................................. 4
Figure 3: Work Breakdown Structure (WBS) ........................................................................................ 7
Figure 4: Gantt Chart .............................................................................................................................. 8
Figure 5: The Waterfall Software Development Lifecycle Model ....................................................... 12
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) v

A4 2.0
 /SPMP

List of Tables

Table 1: Schedule Summary ................................................................................................................... 2

Table 2: Roles and Responsibilities ...................................................................................................... 5
Table 3: Estimation Plan of time and cost .............................................................................................. 5
Table 4: Overview of team members and experiences ........................................................................... 6
Table 5: Staffing Plan ............................................................................................................................. 6
Table 6: Hardware and Software Required............................................................................................. 6
Table 7: Risk Management Plan ........................................................................................................... 11
Table 8: Software development techniques according to its phases ..................................................... 13
Table 9: The list of deliverables and its due date of submission .......................................................... 14
Table 10: Identifications and naming conventions of documents......................................................... 15
Table 11: Roles and Tasks in Problem Resolution ............................................................................... 17
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) vi

A4 2.0
 /SPMP

1. OVERVIEW
1.1. Project Summary
1.1.1. Purpose, Scope and Objective
1.1.1.1. Purpose
The purpose of this SPMP is to produce a common understanding of the CMS project with the
development organisation and team members. This project's relationship to other projects, as well
as how it will be combined with other projects or ongoing work processes, will be stated in the
SPMP.

1.1.1.2. Scope
The scope of this SPMP covers the business or system demands that the project should meet, as
well as a brief statement of the project objectives, the products that will be produced to fulfil those
objectives, and the methodology for assessing satisfaction.

1.1.1.3. Objective
The objective of this project is to develop an effective prototype of a Mark Collection System. After
a student has completed his or her master project, calling MCS and performing an automated
computation on the filled-out grading sheet. Additionally, as soon as the presenting session is
completed, this system notifies the lecturer feature to complete the evaluation on the marking
scheme.

1.1.2. Assumptions and Constraints

1.1.2.1. Assumptions
i. The MCS system shall be able to access anywhere and anytime.
ii. The MCS down time shall not exceed 24 hours.
iii. The MCS shall support multiple accesses from several lecturers and master project
coordinator.
iv. Access to operate the functions available to the actors will be restricted by use of the
correct password.
v. The lecturer shall not able to access the master project coordinator functionality and
master project coordinator shall not able to modify the entered marks by the lecturer.
1.1.2.2. Constraints
i. Object-oriented development (OOD) techniques with UML notation shall be applied to the
project
1.1.3. Project Deliverables
The complete product, including all documentations, will be delivered 6 weeks after the project
commences. Project document deliverables include:
i Software Project Management Plans (SPMP)
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

ii Software Requirement Specification (SRS)

© All Copyrights Reserved, 2021 and confidential. They shall not be

iii Software Design Document (SDD)

iv Software Test Description (STD
know them without prior written consent of RFTI-UTM.

v Software Test Review (STR)

vi Software Development Fundamental (SDF)

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 1/18

A4 2.0
 /SPMP

1.1.4. Schedule Summary

The duration of each phase is as in Table 1 below:

Requirement and Analysis 1 week

Design 1 week
Development 1 week
Tests 1 week
Closure 1 week
Total 6 weeks
Table 1: Schedule Summary

1.2. Evolution of the Project Management Plan

All changes to the project management plan must be agreed to by the Project Manager before they
are deployed.
All changes should be recorded and documented in order to keep the project management plan
correct and up to date.

2. REFERENCES
[1] IEEE Standard for Software Project Management Plans, in IEEE Std 1058-1998.
[2] ISO/IEC/IEEE International Standard - Systems and software engineering -- System life cycle
processes, in ISO/IEC/IEEE 12207. First edition 2017-11
[3] IEEE Standard for Configuration Management in Systems and Software Engineering, in IEEE
Std 828-2012.
[4] IEEE Standard for Software Quality Assurance Processes, in IEEE Std 730-2014.
[5] IEEE Standard for Software Reviews and Audits, in IEEE Std 1028-2008.
[6] IEEE Standard Classification for Software Anomalies," in IEEE Std 1044-2009.
[7] IEEE Recommended Practice for Software Requirements, in IEEE Std 830-1998
[8] IEEE Standard for Information Technology- Systems Design- Software Design Descriptions, in
IEEE Std 1016-2009
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 2/18

A4 2.0
 /SPMP

3. DEFINITIONS AND ACRONYMS

CMS Collection Marking System

CRF Change Request Form
CSCI Computer Software Configuration Item
DB Database
GB Gigabyte
IDE Integrated Development Environment
PHP Hypertext Pre-processor
RFTI Razak Faculty of Technology and Informatics
RAM Random Access Memory
SDD Software Design Document
SPMP Software Project Management Plan
SRS Software Requirement Specification
STD Software Test Document
SQL Structured Query Language
TM Thesis Management
UTM Universiti Teknologi Malaysia
UML Unified Modelling Language
WBS Work Breakdown Structure
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 3/18

A4 2.0
 /SPMP

4. PROJECT ORGANIZATION
4.1. Interfaces

The Interfaces between internal and external entities in this project are illustrated in Figure 1 below.

Figure 1: Interfaces between internal and external entities

The internal structure, which is the project organization, communicates with external entities
through the Work Package Manager. The Project Manager shall be the mediator (middle person)
between the project organization and the client.

4.2. Internal Structure

The Internal Organizational Structure chart is illustrated in Figure 2 below.
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

Figure 2: Project Organisation (Internal Structure)

© All Copyrights Reserved, 2021 and confidential. They shall not be

The internal structure or the project organisation comprises of 4 members namely the Work Package
know them without prior written consent of RFTI-UTM.

Manager, Quality Manager, Configuration Manager and Developer. This team will be led by the Work
Package Manager. All roles and responsibilities of each team members will be explained in 4.3 Roles
and Responsibilities subsection.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 4/18

A4 2.0
 /SPMP

4.3. Roles and Responsibilities

The responsibilities of all relevant stakeholders (Roles) are specified in Table 2 below.

Roles Responsibilities
Software Work Package Manager Verify that tasks are scheduled, assigned, and
executed in compliance with project deadlines and
quality standards.
Quality Manager Project Manager receives reports from Quality
Manager. Ensure that each project employees
adheres to project standards in a consistent and
verifiable manner.
Configuration Manager Develop the desired functionality in conformance
and processes established by the project. It could
involve activities in any of the disciplines of
requirements, analysis and design,
implementation, and testing.
Developer Is in responsible for the entire development cycle.
They're the ones who work with the customer to
develop a theoretical design. They
might employ programmers to write the code
needed to execute the app properly.
Table 2: Roles and Responsibilities

5. MANAGERIAL PROCESS PLANS

5.1. Start‐up Plan

This subsection of the SPMP shall specify the estimation plan, staffing plan, resource acquisition
plan, and training plan.

5.1.1. Estimation Plan

The estimation plan for this project is summarized in Table 3 below:

Parameter Estimation
Total Development Time 6 weeks
Table 3: Estimation Plan of time and cost

5.1.2. Staffing Plan

Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

Throughout the organization of the project, team members have been assigned main
responsibilities/roles, and have a general responsibility to follow up the progression of the other
know them without prior written consent of RFTI-UTM.

team members. This is done so that other team members can take part of and learn all the main
responsibilities assigned to other team members.
The overview of team members, assigned responsibility and experiences are summarised in Table 4
below:

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 5/18

A4 2.0
 /SPMP

Main Responsibility Experience and Strength Highest education level

Software Work Package Manager Experienced in managing Masters of Software
projects Engineering
(5 years)
Quality Assurance Manager Experienced in Masters of Software
managing Quality of Engineering
Software Product
(5 years)
Configuration Experienced in managing Masters of Software
Manager configuration Engineering
(5 years)
Developer as System Engineer, Experience in developing Masters of Software
Web Designer, Service Designer and programming Engineering
and Database Designer (5 years)
Table 4: Overview of team members and experiences

The summary staff required by phase for this project is explained in Table 5 below:

Phase Number of staff required

Initiation 3

Requirement and Analysis 3

Design 3

Development 3

Tests 3

Closure 3

Table 5: Staffing Plan

5.1.3. Resources Acquisition Plan

All necessary hardware and software required for the project are summarized in Table 6 below.

Details Amount Source

Hardware Desktop 3 FTIR
Laptop 3 Personal
Software Microsoft Windows 10 Each installed in FTIR
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

Microsoft Word each hardware

© All Copyrights Reserved, 2021 and confidential. They shall not be

Microsoft PowerPoint
know them without prior written consent of RFTI-UTM.

Microsoft Excel
Rational Rose
Google Chrome
Table 6: Hardware and Software Required
DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 6/18

A4 2.0
 /SPMP

5.1.4. Project Staff Training Plan

No additional staff training is needed for this project.

5.2. Work Plan

5.2.1. Work Activities

The work activities for this project are illustrated by a work breakdown structure
(WBS) as in theFigure 3 below.

Figure 3: Work Breakdown Structure (WBS)

Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 7/18

A4 2.0
 /SPMP

5.2.2. Schedule Allocation

The work activities for this project are illustrated by a Gantt Chart as in the Figure 4 below.

Week 1

Week 2

Week 3

Week 4

Week 5

Week 6

July
May June

27
31
18
19
20
23
24

10
13
14
15

20

22

24
27
29
03
16

23
25
26

30

17

21
17

4
5
6
7
2
3

8
9
1
Milestone Description
T W T F M T W T F M T WT F S S M T W T F M T WT F M T WT F M T S
Initialization
Define Project Scope
Prepare Risk Plan
Plan Resources and Timeline
Prepare SPMP
Requirement and Analysis
Get user requirement
Analyze user requirement
Prepare SRS
Conduct Software Specification Review
Update SRS based on SSR Amendments
Design
Prepare SDD
Prepare Preliminary Design
Conduct Preliminary Design Review
Update SDD based on PDR Amendments
Development
Write Code
Review Code
Execute Unit Test
Tests
Prepare Test Case
Prepare STD
Perform Software Integration Testing
Produce STR
Conduct Test Readiness Review
Update STD and STR based on TRR Amendments
Product Demonstration
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

Closure
© All Copyrights Reserved, 2021 and confidential. They shall not be

Review acceptance deliveries

Finalizing documents
Perform Retrospective
know them without prior written consent of RFTI-UTM.

Organize Project Celebration

Figure 4: Gantt Chart

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 8/18

A4 2.0
 /SPMP

5.2.3. Resource Allocation

The team members will work on their assigned artifact individually. The software work package
manager will keep track of the other team members' daily efforts and supervise implementation. At
the conclusion of each day, the team will gather to review challenges and progress. Weekly
meetings with the project manager will be conducted. On request, formal meetings with the
customer will be arranged to report progress and assess whether any modifications are required.

5.2.4. Budget Allocation

No budget allocated for this project.

5.3. Control Plan

Software Work Package Manager manages effort, personally oversees support tasks deemed
critical, prepares various administrative reports, responds to information requests from client, and
participates in various meetings.

5.3.1. Requirements Control Plan

Any significant modifications to the requirements that would have an impact on the milestones
must be requested using a "Change Request Form (CRF)" (Appendix A). The request is then
submitted, with the Project Manager's permission being granted or declined and documented. A
report will be written and given to the acquirer once the adjustments have been made. Every day, all
progress will be recorded. Any severe concerns that the team members encounter will be
communicated to the Software Work Package Manager right away.

5.3.2. Schedule Control Plan

Any major changes regarding the scheduling that would affect the milestones have to be approved
by the Project Manager and documented. All progresses shall be reported on daily basis. Any major
problems faced by the team members will immediately be reported to the Software Work Package
Manager.

5.3.3. Budget Control Plan

Not applicable.

5.3.4. Quality Control Plan

Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

The Quality Assurance Manager responds to requests for service in the event of Critical Failures,
© All Copyrights Reserved, 2021 and confidential. They shall not be

Failures and External System Failures. Any major changes regarding quality are reported to the
SoftwareWork Package Manager.
know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 9/18

A4 2.0
 /SPMP

5.3.5. Reporting Plan

Each of preliminary versions of all the documents and updates and status reports will be sent and
discussed with the Project Manager for approval. Upon approval, the documents will be circulated
to the other members. At the major deliverable due dates, the deliverables will be delivered to the
client.

5.3.5.1. Internal Reporting Plan

All progress of assigned tasks and changes made to artefacts will be reported to the Work Package
Manager.

5.3.5.2. External Reporting Plan

All overall progresses and changes to deliverables will be reported to the client with the approval of
the Project Manager.

5.3.6. Metrics Collection Plan

The Configuration Manager is responsible to extract the appropriate status and metrics reports, if
needed.
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 10/18

A4 2.0
 /SPMP

5.4. Risk Management Plan

The risk management plan for the project is explained in the Table 7 below.

Level Risk Control Trigger Point Role/PIC

High 1 Deadline missing  Set prioritized goals  Improper Project Manager

 Break project into estimation
smaller parts  Lack of planning

2 Develop the wrong  Establish  Inaccurate SDD Developer

function (group requirement
project)

3 Inaccurate decision  Prepare alternative  Inexpensive Software work

making plan project manager package manager
 Seek advice from  Rush decision
experts

4  Enhance  Improper Software work

Misunderstand
requirements communicate communicate package manager

5 Code missing  Back up  System attack Developer

Medium 6 Miscommunication  Team building  Varying Software work

 Meeting (track of background package manager
progress)

Low 7 Lack of skill  Training  Assign the Software work

 Share knowledge wrong person package manager
 Hire expert  Lack of training
& experience
 New technology/
obsolete
technology

8 Failure to follow the  Alert progress  Inexperience Quality Manager

methodology schedule  Unfamiliarity

9 Hardware defect  Use new hardware  Lack of Developer

 Back up/ use maintenance
version control  Lack of R&D
 Properly maintain / before
pre check implementation
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

 
© All Copyrights Reserved, 2021 and confidential. They shall not be

10 Facilities Back up Lack of Quality Manager

malfunctions  Properly maintain maintenance
 Pre-check
know them without prior written consent of RFTI-UTM.

Table 7: Risk Management Plan

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 11/18

A4 2.0
 /SPMP

5.5. Closeout Plan

Once the entire project is terminated for whatever reason, whether the objectives were reached or
not, there are a number of closing actions that must be completed before the project is officially
concluded.

These actions are summarized as follows: Release or reassign team, communicate decision, identify
outstanding work, provide released software, obtain customer approvals, return or release vendor or
customer materials

6. Technical Process Plans

6.1. Process Model

The "Waterfall Model," which will be employed in this project, is the technique used in software
development. The whole software development process is separated into discrete process stages in
this paradigm. Requirement Specifications, Software Design, Implementation, and Testing &
Maintenance are the phases involved. Figure 5 illustrates the "Waterfall Model" in practice.

Figure 5: The Waterfall Software Development Lifecycle Model

6.2. Methods, Techniques and Tools

6.2.1. Development Methodology

This project will employ the Waterfall Development Methodology for the following reasons:
 Early in the project, requirements are accomplished, allowing the team to establish the whole
project scope, construct a detailed timetable, and design the overall application.
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,


© All Copyrights Reserved, 2021 and confidential. They shall not be

The amount of resources required to implement this model is minimal.

 It is a greater system design since all of the requirements and deliverables are better understood.
know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 12/18

A4 2.0
 /SPMP

6.2.2. Diagrams

The standard UML diagrams to represent data, relationships, and requirements will be used.

6.2.3. Programming Languages and Tools

Due to the general project's web-based nature, it will be built using the Laravel
framework, which is a framework built on top of the PHP programming language, as
well as additional relevant tools that will be determined as they become necessary. The
team will use a variety of pre-built web application technologies.

6.2.4. Software development techniques

The software development techniques according to its phases are explained in Table 8 below.

Phases Techniques
Software Requirements Analysis Upon a discussion with the client, the basic system requirements will be
defined. Before finalising with the customer, the team will examine the
first system requirements with the Project Manager. Meanwhile, SRS is
being produced, which will be examined and approved as a project
deliverable after a Software Specification Review meeting.
Design The software team will choose a design technique to employ in the design
process, generate preliminary designs, and create an SDD. The design
will then receive a preliminary evaluation to confirm that it satisfies the
criteria (both system and derived software requirements).
Following the evaluation, crucial designs will be produced and tested.
When the design is finished, Software Package Manager will provide the
customer the Software Design Document (SDD).
Coding and CSU Testing The modification will be developed and unit tested according to the
developer's software development methods. The developer will adhere to
the coding standards established by quality assurance. Throughout the
development process, the developer will undertake internal peer
evaluations.
CSCI Testing CSCI Test Planning includes CSCI Integration Testing and Qualification
Testing by the CSCI. Qualification by CSCI As a condition of admittance
into CSCI Integration Testing, test planning will be completed for each of
the CSCIs. Each CSCI will have its own SRS, allowing it to progress
through the life cycle phases independently until it is integrated. The
Quality Assurance Manager and the Configuration Manager are in charge
of planning and performing individual CSCI component testing.
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

Each functional component of a CSCI will have its own set of test
© All Copyrights Reserved, 2021 and confidential. They shall not be

methods. The goal is to ensure that the CSCI's functional components

fulfil its SRS separately and that the CSCI as a whole meets the SRS's
know them without prior written consent of RFTI-UTM.

performance standards.
Table 8: Software development techniques according to its phases

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 13/18

A4 2.0
 /SPMP

6.3. Infrastructure Plan

6.3.1. Software Infrastructure

At least one computer is devoted to each developer for development and unit testing. Dual displays,
development tools such as Integrated Development Environments (IDEs), source control software,
database tools (SQL Developer or Toad), schema building tools (XMLSpy), and other productivity
tools are all standard on all PCs. RU management suggests that depending on the kind of code,
several IDEs be used. AccuRev (stream-based source control solution) is also used by the
contracting firm, which allows developers to effortlessly manage numerous release versions in
development and maintenance at the same time.A fully virtualized private server which has
following specifications will be used:

i. 2 GB RAM
ii. 40 GB SSD Storage
iii. 2.00 Ghz x 2 Cores CPU
iv. 100 Mbps internet connection
v. PHP 7
vi. MariaDB 5.5
vii. Apache 2.4

6.3.2. Hardware Infrastructure

Software Work Package Manager will establish and maintain a detailed schedule for computer
hardware resource utilization that identifies anticipated users, purposes, and scheduled time to
support analysis, software design, coding, integration, testing, and documentation. It will address
sharing of resources by multiple users and workarounds to resolve conflicts and equipment
downtime. If computer hardware resource scheduling requires supplementing, potential sources of
computer hardware resources including other projects or commercial vendors will be identified.
The Software Work Package Manager will coordinate resource needs with development,
integration, and test groups.

6.4. Product Acceptance Plan

All documents will be reviewed by both Project Manager and rest of the project team. All
deliverables will be reviewed and approved by the Project Manager and client. After testing at the
end ofdevelopment process, the software will be presented to the client for acceptance process.

The list of deliverables and its due date of submission is summarized in the Table 9 below.

Product/Artefact Due date

Software Project Management Plan (SPMP) 23 May 2022
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

Software Requirement Specification (SRS) 30 May 2022

© All Copyrights Reserved, 2021 and confidential. They shall not be

Software Design Description (SDD) 09 June 2022

Software Test Description (STD) 22 June 2022
know them without prior written consent of RFTI-UTM.

Software Test Report (STR) 22 June 2022

Product Demonstration 29 June 2022
Table 9: The list of deliverables and its due date of submission

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 14/18

A4 2.0
 /SPMP

7. SUPPORTING PROCESS PLAN

7.1. Configuration Management Plan

The Configuration Manager makes sure that the version management of code and documents can be
done with ease and in a correct manner. Configuration Management shall ensure the precise
visibility and therefore improved control over an evolving system. It also improves the traceability
of changes inthe team’s work.

The configuration manager is responsible to manage different versions of the work products,
control the changes that are imposed and audit and report on the changes that are made. She/he will
also update the project’s web application developed on a regular basis. In our project, two people
have been identified in Table 3 Roles and Responsibilities will be responsible for this duty. The
documents and new version documents are controlled lastly and established by them. GitHub is
used for configuration management tools for this project entirely. Guideline for naming convention
for documents is as in Table 10 below:

Convention Explanation Example

HaSH-title- Document for project in HaSH organization, HaSH-SPMP-

dmy(date)-V(X) identified bythe title of the document, date that the 23052022-V2
document was created and the version of the
document.

Table 10: Identifications and naming conventions of documents

Next, for development files, the configuration will follow the development framework used for
maintaining the code base and stored in the HaSH repository on Github. Github is used due to its
extensive usage by open source contributors around the world. This is done due to most
development frameworks which prefer convention over configuration style of naming. Overriding
the filenames will result in modifying the set of rules initially applied to the source code structures.
Configuration manager is responsible to ensure all project team members follow the rules and
regulation imposed for naming convention and configuration tools used throughout the project
timeline.

Finally, the documents and source codes need to be updated into the repository once they
are completedfor tracking and recording purposes.

7.2. Verification and Validation Plan

All group members are responsible for verification activities. Validation is the process of making
sure that the product is being built correctly. At the completion of each milestone, a validation
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

analysis should be done. The validation will be performed by group member during internal
© All Copyrights Reserved, 2021 and confidential. They shall not be

reviews to make sure that the delivered products are right. A demonstration of the user interfaces to
the acquirer will be made for validation. All the testing activities are under the test team members’
know them without prior written consent of RFTI-UTM.

responsibilities. There will be two types of testing. One of them will be done after coding of each
part; the other will be done before publishing of the web site.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 15/18

A4 2.0
 /SPMP

Goals of Verification and Validation for this project are:

 Enhancing product through cost-effective, timely detection of defects

 Promoting personal growth and communication among software development professionals
 Fostering teamwork professionalism, participatory decision-making, and high morale
 Improving ability of reviews to prevent defects in their own work
 Enhancing the effectiveness of testing by detecting errors prior to testing
 Find errors, not fix them

7.3. Documentation Plan

The configuration manager is the responsible person to publish all the deliverables via GitHub
depository and eLearning submission webpage. All the deliverables will be prepared by group
members. The demonstration of the product and final product will be done by group members.
Documentations list and their respective due date is seen at Table 9.

7.4. Quality Assurance Plan

For quality assurance plan, review and configuration management methods will be used. The
project team will make both internal and external meetings. In internal meetings, only team
members will be in that meeting and they will make plans about their deliverables deadlines.

In external meetings, the project team will meet the client to get the requirements. In these
meetings, team members will take notes to provide that the deliverables are correct and meets the
requirements specifications in SRS report. The Project Manager will arrange these external
meetings.

7.5. Review and Audits

Review sessions with the client will be performed after the initial plan, the SRS, and SPMP to
ensure that the client's requirements are satisfied. All the members of the team members will
participate in these reviews. Internal reviews and reviews between Software quality team and team
members will be done for verification and validation purposes. The schedule of the internal reviews
will be done during all the phases of the project and all the members of the team members will
participate in these reviews.

Before the delivery of each document, team members will have a meeting about the existing
document. Project group review the document lastly. If some corrections are necessary, these are
made during these meetings. After the document is established, the Quality Manager examines the
documents and adds some comment to correct the fault. Then group members correct the faults and
established again with second version.
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 16/18

A4 2.0
 /SPMP

7.6. Problem Resolution Plan

Problems would be resolved informally between the Project Manager and the
team members.The tasks for each role are summarized in the Table 11 below.

Roles Tasks
Software Work Package Manager  Resolution review and approve
Quality Manager  Problem Detection
 Problem Logging
 Error Record
Configuration Manager  Record Changes and Update
 Version Control
Developer  Problem Diagnosis
 Problem Workaround
Table 11: Roles and Tasks in Problem Resolution

7.7. Subcontractor Management Plan

Not applicable.

7.8. Process Improvement Plan

Not applicable.

8. ADDITIONAL PLANS

Not applicable.
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,
© All Copyrights Reserved, 2021 and confidential. They shall not be

know them without prior written consent of RFTI-UTM.

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 17/18

A4 2.0
 /SPMP

APPENDIX A

CHANGE REQUEST FORM

Section A: To be filled by Submitter

Project
Requested by Name Position Contact No.

CHANGE DETAILS
Problem Name
Problem No.
Problem Description

High Medium Low

Priority
Date Submit
Received by
Date Receive
Section B: To be filled by Project Leader
Impact of change

Corrective Action

Person in Charge <role>

Project Leader Name
Urgency High Medium Low

Complexity High Medium Low

Approval Status of the Request Approved Rejected Waiting

Solution

Status
Reproduced nor disclosed to any person except to those having a need to
This document and the information it contains are property of RFTI-UTM,

Section D: To be filled by Project Leader

© All Copyrights Reserved, 2021 and confidential. They shall not be

Approved by Verified by
Request Completion
Remarks
know them without prior written consent of RFTI-UTM.

Date
Appendix A: Change Request Form (CRF)

DOCUMENT IDENTIFICATION
SYSTEM NAME FORMAT VERSION PAGE

Mark Collection System (MCS) 18/18

A4 2.0