Job Board Project Plan

AASTU LAPTOP E-LEDGER SYSTEM
PROJECT MANAGEMENT PLAN
Version 1.0
01/19/2022
Group Members
- Ezira Ashenafi FTP0414/11
- Getachew Muhabaw FTP0469/11
- Yohannes Fenta FTP1139/11
AASTU Laptop E-ledger System
- TABLE OF CONTENTS
1 INTRODUCTION 3
1.1 Purpose of Project Management Plan 3
2 EXECUTIVE SUMMARY OF PROJECT 4
2.1 Assumptions/Constraints 4
3 SCOPE MANAGEMENT 5
3.1 Scope Definition 5
3.2 Work Breakdown Structure 6
3.3 Deployment Plan 7
3.4 Change Control Management 9
4 SCHEDULE/TIME MANAGEMENT 10
4.1 Milestones 10
4.2 Project Schedule 11
4.2.1 Dependencies 12
5 COST/BUDGET MANAGEMENT 13
5.1 Effort 15
5.2 Estimated Development Time 15
5.3 Estimated Staff size 16
5.4 Cost 16
6 QUALITY MANAGEMENT 18
6.1 Software Quality Assurance Model 19
6.2 Quality Management Plan 22
7 RESOURCE MANAGEMENT 25
7.1 Software Resources 25
7.2 Hardware Resources 26
7.3 Staff Management Plan 27
8 STAKEHOLDER MANAGEMENT PLAN 29
8.1 Project Stakeholder Management Plan Process 29
9 COMMUNICATIONS MANAGEMENT 34
9.1 Purpose 34
9.2 Project Communication Plan 34
9.2.1 Communication matrix 34
10 RISK MANAGEMENT 37
Page 1 of 47
10.1 Risk Identification 37

10.2 Qualitative Risk Analysis 42
10.3 Risk Response Planning 42
11 PROCUREMENT MANAGEMENT 44
11.1 Hardware Resources 44
11.2 Software Resources 44
APPENDIX A: REFERENCES 45
APPENDIX B: KEY TERMS 46
APPENDIX C: LIST OF TABLES AND FIGURES 47
Page 2 of 47
1 INTRODUCTION
AASTU looks to track laptop devices entering and leaving the university’s campus. This is in an
attempt to prevent theft of property. Before an individual leaves the campus with a laptop or
computer device, the university verifies that the device is their personal property.
This is currently achieved by registering an individual’s identification number and the device’s
serial number onto physical ledgers. “Serial numbers are used to distinguish items from others of
a similar appearance”[1]. Officials at the gates then cross check the serial number of the device
an individual has on their person, against what is present in the ledger.
While this method is an appropriate measure to prevent theft, the current implementation is
prone to errors and duplication of data. There is, currently, no means to ensure that ledgers at
each of the gates are kept synchronized which can lead to duplication of the data and creates
issues when individuals attempt to leave at a gate they haven’t registered through. It is also prone
to causing congestion at the gates due to the manual nature of the cross checking/lookup process.
The proposed system will use a digital ledger to insure interoperability and synchronization
amongst the several gates of the campus. By using a digital ledger, it also aims to remove data
redundancy and automate as much of the system as possible and improve the system’s overall
performance. It also aims to provide several fail-safes for events that might impact the system
like internet availability and electricity issues.
1.1 Purpose of Project Management Plan
This is a formal document that aims to outline all the components of the project and describe
how project activities are to be executed, monitored, controlled and concluded. Some of these
components include the scope of the project, the stakeholders involved, the proposed project
schedule, risk management and contingency plans, and etc. This document is intended to provide
the necessary structure to start, execute and, critically, complete the project[2, Ch. 2.1]. The
project management plan is intended for all project stakeholders. These include the university
(AASTU), system developers, project managers, and final end-users.
Page 3 of 47
2 EXECUTIVE SUMMARY OF PROJECT
The current method used to register computers involves using physical, paper ledgers to
record. This means that when an individual attempts to leave the university, gate officials
perform a manual lookup and cross-check registered values against the serial number of the
device on the individual’s person. There is currently no way to fully synchronize the ledgers
present at each of the university’s gates. Furthermore, these physical ledgers are prone to damage
and deterioration.
The proposed system will make use of information technology and software to electronically
register and track laptops entering and leaving the campus. It will achieve this by scanning
device identifying barcodes that encode the laptop’s serial number and the individual’s unique ID
barcode present in their AASTU identification card.
The above-mentioned barcodes provide a way to identify the user and his/her device within a
fraction of the time it would take for a human to manually search for entries. It also provides a
further simplification of the registration process by using electronic media. The system will be
centralized, enabling a laptop registered once to leave and enter the campus through any one of
the campus’s gates.
The project will also provide a means of reporting theft that is more streamlined than the existing
manual system. This will be achieved by making a theft-reporting interface available over the
internet where individuals can authenticate and then report their devices stolen or lost. The
system will also provide a means to analyze and report on the devices in the campus at any given
time. This will also eliminate false reports of theft within the university’s campus.
2.1 Assumptions/Constraints
An assumption that has a very high impact on the project is that the university will have the
willingness and the resources to deploy the final software product in the university’s existing ICT
architecture. The project assumes the university will provide the servers on which to deploy the
server-side components of the system and also client computers (at the gates) to deploy the client
side component of the system.
Page 4 of 47
Another assumption is that the university will provide the necessary labor force to operate the
system. The project assumes that the university will provide at least one security official at each
of the gates to observe and oversee the system recording computers exiting and/or entering the
campus and also one or more officials that can perform computer registration and possibly
barcode generation. The project also assumes that security officials will be fully capable to react
to any reports of stolen or lost devices.
3 SCOPE MANAGEMENT
This section of the document will describe the scope of the project. It will describe the
responsibilities of various actors in accordance with the project scope. It will finally describe the
change management plan for the various aspects of the scope.
During the course of the proposed project, scope management is the sole responsibility of the
project manager. The project manager is responsible for managing any change requests to the
project. The project manager will be the one who evaluates and accepts/rejects any proposed
scope changes. Furthermore, they will also be responsible for maintaining scope measurements
including deliverable quality checklists and measures. However change requests may originate
from either the project manager or the stakeholders.
The scope of this project and the various deliverables were defined through an intensive
requirement elicitation phase. We analyzed the state of the current system, what was required or
needed, and what the environment was. This led us to define the scope to what is listed below.
However, this scope can be subject to change due to a wide variety of predictable and predictable
developments. One reason for change can be a change in the requirements of the user (AASTU).
Another could be an unexpected development in the environment of the project
3.1 Scope Definition
This project includes the design, development, testing, staff training and deployment of a new
software application for managing computer devices entering and leaving AASTU’s campus.
The deliverables for this project are a completed software application and a user manual
document pertaining to the operation of the software application. This project will be accepted
Page 5 of 47
once the new software has been successfully tested and a comprehensive user manual
documented. This project will not include any current systems or maintenance of the software
product. It will be limited to the production of a software application for AASTU.
The functionalities and features provided by the system will be limited to providing a registration
and cataloging system for computer devices entering/leaving the university’s campus. It will also
allow for individuals to flag lost or stolen devices. The software application will have client
computers at each of the university’s gates, while a centralized server will be deployed on the
university’s existing ICT infrastructure.
3.2 Work Breakdown Structure
In order to organize, categorize and properly manage activities of this project, they have been
divided into 6 phases as listed below:
1. Project Analysis and Planning: Identifying the project scope and preparing plans for the
various activities in the project.
2. Project Estimation: Estimation of project cost, effort and duration
3. Design: Designing the various interfaces and components
4. Development and Testing: Developing and testing the components of the software
application
5. Training: Preparing user manual documents and training staff on how to use the system
6. Deployment: Final deployment of the software application
Page 6 of 47
Figure 1. Work breakdown structure
3.3 Deployment Plan
Some of the high-level tasks and considerations that will be addressed during the deployment of
AASTU LAPTOP E-LEDGER system are listed in the table shown below.
Table 1. Deployment Plan
Task Start date Finish date owner status

& time & time
Stand up the 3/11/2022 3/11/2022 Ezra A. planned

production 08:00 AM 10:00AM
environment
Page 7 of 47
Run 3/11/2022 3/11/2022 Getachew planned

deployment 12:00PM 02:00 PM M. &
wizard Yohannes F.
Check error 3/12/2022 3/12/2022 Ezra a. planned

log & resolve 08:00 AM 10:00AM
any issue
manually if
needed
Review 3/12/2022 3/11/2022 Ezra A. planned

production 10:00AM 03:00 PM
Deployment Diagram
As in the diagram below we have depicted how we want to deploy our proposed system. The
hardware topology used and the runtime system assigned can be represented by the deployment
diagram.
Figure 2. Deployment diagram
Page 8 of 47
3.4 Change Control Management
Changes in the scope can arise from a wide variety of sources. However a scope change request
must be submitted to the project manager. The project manager is responsible for evaluating the
change request as listed above. During evaluation, the project manager will analyze the impact of
the change, its effects on cost and schedule, mitigation strategies, and overall viability of the
change. After evaluating, the project manager will either accept or reject the scope request. Upon
acceptance, the project manager will present the scope change in question to the change control
board.
The change control board will be constituted from all sections of the project stakeholders. It will
have members from the university as well as members from the system developers. The board is
responsible for finally accepting the changes to the project scope or rejecting the change
altogether. Any change to the project scope requires the acknowledgment and permission of the
change control board.
The following steps will be used to change control process for all projects and will be utilized on
this project:
1. Any changes can be submitted by stakeholders or future team members by using a change
request form.
2. Changes will be registered in the change request register by the project manager and it
will maintain change requests for the duration of the project.
3. Conduct an evaluation of the change (Project Manager) The project manager will conduct
an evaluation of the impact of the change to cost, risk, schedule, and scope
4. The project manager will analyze the changes and review the project management plan
5. Present Change to change control board
6. The change control board will communicate on the review of changes and decide whether
or not it will be approved based on all submitted information
7. Upon acceptance, Document and Implement change
If a change is approved, the project manager will update and re-baseline project documentation
as necessary as well as ensure any changes are communicated to the team and stakeholders.
Page 9 of 47
4 SCHEDULE/TIME MANAGEMENT
The project was begun on Thursday, 30th of December 2021. and will reach completion on
Friday, 11th of March 2022. This means that the project will span 71 days in total.
4.1 Milestones
The project will be divided into seven distinct phases. Each of these phases indicates a major
progress in the project. However, it should be noted that requirement gathering milestones are a
part of the analysis and planning milestone. The deliverables of the analysis and planning
milestone includes the deliverables of the requirement gathering milestone.
Table 2. Milestones
Milestones Description Deliverables Time
Analysis and Planning Studying the existing Inception Report, 12/30/21 - 1/14/22
system to identify System Requirement
major problems by Specification
employing different
methodologies
Requirement Requirements System Requirement 1/5/22 - 1/14/22

Gathering elicitation from all Specification
stakeholders
Project Estimation Based on the Project management 1/14/22 - 1/22/22

requirement estimate Plan
cost, scope, and time
of the project
Design Design the new system Software Design 1/22/22 - 2/2/22

Document
Page 10 of 47
Development and Implementing the new Software Product 2/2/22 - 3/9/22

Testing system and take unit
test for bugs
Testing Perform final test for Test Plan, Status 2/2/22 – 2/9/22
the system Report
Training Train users how to use User manual document 3/9/22 – 3/10/22
the system
Deployment Deplothe system and - 3/11/22 – 3/11/22

check error log
4.2 Project Schedule
Below is a gantt chart depicting the schedule for the project. The project is divided into seven
distinct milestones as listed above. These milestones may have internal phase divisions for
further classification and organization
Page 11 of 47
Figure 3. Project Schedule chart
4.2.1 Dependencies
Each of the phases listed above have a hierarchical dependency. The completion of one will be
the requirement for another phase. Below is a table that describes the dependencies between the
different phases of the project
Table 3. Dependencies list
Phase Dependencies Reasoning
- This is the first phase of the

Analysis and Planning project and thus has no
dependencies
Analysis and Planning Phase The requirement elicitation

Requirement Gathering will be carried out following
plans designed in the analysis
and planning phase
Requirement Gathering Project estimation requires

Project Estimation Phase, Analysis And Planning information and insight
Phase gathered during requirement
Page 12 of 47
elicitation and analysis
Requirement Gathering Design will be based on

Design requirements gathered
Requirement Gathering Development will be solely

Development and Testing Phase, Design Phase based on the guidelines and
information set by the
designing and requirement
gathering phases
Development and Testing This phase will test the

Testing Phase, Requirement developed software product
Gathering phase, Design against the listed requirement
Phase and design specification
Development and Testing This phase will provide

Training Phase, Requirement training based on the design
Gathering Phase, Design specified and also various
Phase aspects of the final software
product
ALL Final Deployment of the

Deployment system requires all of the
above phases to be completed
5 COST/BUDGET MANAGEMENT
5.1. Project Estimation
We use the Line of Code method to calculate the KLOC. First, we divide the project into
different modules and divide the modules into submodules after that we approximate the code for
each submodule. Module lists:
● Frontend
● Backend
● Database management
Based on our approximation the total line of code is 3,000. To convert the line of code to KLOC
we divide the line of code with 1000 and we get KLOC of 3. Since our project is less strict and
Page 13 of 47
our team has considerable experience, we use an organic intermediate COCOMO model. We use
an intermediate COCOMO model because our project has some cost driver attributes. Assume
the average monthly salary for each staff member is 8000 birr/per month. And the monthly salary
for the manager is 12000.
Table 4. Cost driver factors
id Cost driver Factor Priority Value
1 RELY, required reliability Very high 1.4
2 CPLX, product complexity Low 0.85
3 STOR, main storage constraint High 1.06
4 PCAP, programmer capability Very high 0.70
5 PLEX, programmer language High 0.95

experience
6 DB, database size High 1.08
7 Others factors Nominal 1.0
Page 14 of 47
5.1 Effort
By using the formula below we try to estimate how much effort is required to develop the
system. The total effort to develop the system is 20.54 person months.
Ei (initial effort) = a* (KDLOC) b
a=3.2, b=1.05
Ei (initial effort) =3.2* (3KDLOC) 1.05
Ei (initial effort) = 10.14PM
Effort Adjustment Factor = is the product of 15 cost driver attributes
EAF =1.4*0.85.1.06*0.70*0.95*1.08*1.0
EAF = 0.91
Total effort =Initial effort *EAF
Total effort = 10.14 *0.91 PM
Total effort = 9.23 person Month is total effort required to develop our system
5.2 Estimated Development Time
Development time is the total time required for the project. According to the intermediate
COCOMO model, the project will take 5.8 months with the minimum amount required of
development personnel.
Development time = ci*(Total effort) di
Tdev = 2.5*(9.23)0.38
Tdev = 5.8Months
Page 15 of 47
5.3 Estimated Staff size
Based on the intermediate COCOMO model the estimated total development time is 5.8 Month
with estimated staff size is 1.59. However when accommodating the project the available three
developers, the estimated development time according to the intermediate COCOMO model will
be 3.074 months
Staff size(ss) =Total effort/Development time
Staff size(ss)=20.54/7.5 Persons
Staff size = 1.59 Persons
5.4 Cost
A cost estimate is a summation of all the costs involved in successfully finishing a project, from
inception to completion (Project duration). The principal components of the project cost are
listed below:
- Traveling and Training cost

- Support and Training cost
● End-user training
● Administrator training
- Overhead cost
● Printing
● Telephone
● Transport cost
● Miscellaneous
- Effort cost (the cost of paying software engineering)
- Dependency costs (external software or service)
● Firewall program
● Manual preparation
● User guide manual
● Technical manual
Page 16 of 47
Table 5. Dependency costs budget
ITEM/Labor ITEM/Labor Unit Birr/Unit TOTAL

NAME DESCRIPTION
Firewall Firewall program to 1 1500 birr 1500 birr

Program (tool) secure our virtual
server
Visual Paradigm Software program 1 938 birr/month 2814 birr for

(tool) used to design the 3 month
system subscription
User manuals Manuals supporting 1 100 birr 100 birr

the user to use the
(tool)
system without
difficulty
Technical Manuals about the 1 100 birr 100 birr

technical structure
manuals (tool)
of the system
Wi-Fi For internet use 8 Mbit/sec 1900 birr/month 13300 birr

for 3 Month
Page 17 of 47
Overhead cost Printing, Telephone , 1 4000 birr 4000 birr

Transport cost and
(service cost)
miscellaneous
Project cost =The average salary staff *The development time
Project cost = (8000*3)*3 + 12000*3
Project cost = 108000 +14214 birr
Total cost=122214 birr
6 QUALITY MANAGEMENT
Quality-specific metrics will be collected and used to track the quality of work products. All
members of this project team will play a role in quality management. It is imperative that the
team ensures that work is completed at an adequate level of quality from individual work
packages to the final project deliverable.
The Project Manager is responsible for quality management throughout the duration of the
project. The Project Manager is responsible for implementing the Quality Management Plan and
ensuring all tasks, processes, and documentation are compliant with the plan. The Project
Manager will also be responsible for communicating and tracking further quality standards
consulting our professor, project team members and stakeholders.
The remaining member of the project team that will be formed will be responsible for assisting
the Project Manager in the establishment of acceptable quality standards. They will also work to
ensure that all quality standards are met and communicate any concerns regarding quality to the
Project Manager.
Page 18 of 47
6.1 Software Quality Assurance Model
Among the wide variety of software quality factor models available, this project will use
McCall’s factor model[3]. This model classifies software requirements into 11 quality factors.
These quality factors are then classified into three software metrics:
- Product Operation: Factors directly linked to the operation of the system
- Product Revision: Factors that are related to changes in the software application or
requirements
- Product Transition: Factors pertaining to the interaction of the software with other
softwares and services
Listed below are the 11 quality factors (as defined by McCall’s factor model) and their respective
correlation with the project at hand.
Table 6. Quality Assurance Factors using McCall’s factor model
Software Metrics Quality Factors Details according to our project
Correctness The software must be complete, consistent

and fully functional in all AASTU gates. It
must provide the functionalities required by
the university and also described in the scope
above.
Reliability If an error occurs in our system, the system

must decrease the time to recovery by
modularizing the server and also allowing for
Product Operation
standalone client systems in failure events. It
must also avoid data inconsistency errors,
especially during synchronization with the
central server.
Page 19 of 47
Efficiency Make the system operate within expected

time stamp and concurrency operational
within differ Gates.
Integrity The system must not allow unauthorized

personnel to make any changes within the
system. Only authorized university staff must
be able to register devices on the system.
Usability The system should be easy to learn within a

short time period training for Security Guards
at the Gate. It must also provide a user
manual.
Maintainability As the time goes, technology also updates to

tackle this situation. We are going to
modularize the code using design patterns
and easily upgrade as we want and make it
open to add new features in our software.
Product Revision Flexibility Here our software should run on any Desktop
platforms that support a web browser and that
can connect a Barcode reader device.
Page 20 of 47
Testability Each of the application’s interfaces should be

testable. Furthermore, the major components
of the system should also be testable as a
means to prevent errors.
Portability The system should provide easy installation

and mechanisms, especially for client
devices.
Reusability Make our coding proper package for future

use and make it component based if another
developer wants to use the code we are going
to available to GitHub and can clone or use
part of the code
Product Transition
Interoperability Make it functional within a great efficiency

and operate with proper time across all
AASTU Gates. It should attempt to work
alongside any of the services currently
deployed at the gates.
6.2 Quality Management Plan
Below is a table that describes various software quality measures and their targets. These will be
used to measure and quantify the quality of the software product and also allow for the
evaluation of quality at any given time.
Page 21 of 47
Table 7. Quality Management Plan
Measure Unit Frequency Our Target How
Defect removal % After the 96 and above Make the code

efficiency and completion of modularizing and
debugging every iteration 6 % tolerance component base
using OOP and
design Pattern
Requirement % Weekly 98 and above If the University

volatility index is give a good
7% tolerance feedback we will
handle their
requirement and
make integrable
for another
service using API
Schedule Days Weekly 0% Design the

Variance schedule while
15% tolerance accommodating
for slight
variances in the
project schedule
Cost Variance ETB Weekly 0% Minimize the

volatility of
Up to 20% resources used in
tolerance the project
Page 22 of 47
Customer % As the customer 90 % and Providing a

satisfaction needs some above software product
index feature and that strictly
request for 5 % tolerance adheres to the
another requirements
requirement specified. In the
come event of change
to those
requirements, the
system must
accommodate
those changes
swiftly.
Software -- As new 97% and above The software

Evolution requirement will should be
come and the designed and
software needs implemented in a
5% tolerance
upgrade to manner that is
handle new maintainable and
technology well documented
Easy to Use and -- As the security 98% and above Proved a training
handle guards want and as the user uses
concurrency and active any 3 % tolerance the software and
time at all proper user
AASTU gates documentation
will provided
Project -- At the end of the 90% and above Make the code
Deliverables & project and if it less complexe
Project is approve by 10% tolerance and handle all
Processes University we business of the
Page 23 of 47
will plan for team within

Future proper schedule
Stakeholder -- Expectation will 90% and above The system

Expectations handle with the should strictly
requirement of 10% tolerance adhere to the
the user requirement
specifications
Performance and -- If it will approve 95% and above The software

speed by the campus should aim for
we will asses 5% tolerance optimal
with 2-3 days performance at
per week all of the
university’s gates
and make not
much more
replay on the
internet
connection speed
7 RESOURCE MANAGEMENT
The following are a list of resources that are required in development and deployment of the
proposed system. The specifications have been determined in respect to the requirements
imposed by the system. The prices are estimated using analysis of the current Ethiopian and
worldwide market where they may be available.
7.1 Software Resources
The project will primarily be using open source software. Open source software is software that
is distributed and maintained by a community of software developers [4]. This allows the project
Page 24 of 47
to attain most of its software resources freely. Below is a list of the major software resources that
will be utilized by the system.
- HTML: Hypertext Markup Language, a language used to describe content on the world
wide web
free
- Reactjs: An open-source javascript library for building user interfaces
free
- NodeJs: A javascript runtime for servers-side.
free
- VScode: An open-source IDE
free
- Git: A free and open source distributed version control system.
free
- Visual Paradigm: A suite of design, analysis and management tools that drive your IT
project development and digital transformation.
933.85 birr per month
As Visual Paradigm is a paid, closed source program, a subscription fee is required to acquire a
license for use of the software. The fee is a monthly fee. All the other software resources used
are provided free, however development needs to be carried out in a manner that respects their
individual licenses.
7.2 Hardware Resources

Below is a list of the hardware resources required during the design, development and
deployment of the system.
- Barcode reader: devices that read barcode labels. These devices are used to read the
barcode label for the serial number on the user’s device and also the barcode present on
their AASTU Id card.
● Amount: 4 (1 during development and 3 during deployment, one for each of
AASTU’s gates)
Page 25 of 47
● Note: As AASTU currently uses ID scanning during entry at each of the gates, the
gates have their respective barcode readers that can be utilized for this system
without need for procurement.
● Estimated Price per unit: 4750 birr (on average)
- Deployment Computer Devices: Devices that each barcode reader connects and that the
guards can use to connect to the system. Each gate requires one of these for the system to
be operational.
● Specifications: Windows 7 or later, minimum 2 GB RAM, ethernet Port,
● Note: As each gate has an existing deployment of an ID scanning system,
computer devices exist. The system can be deployed on the existing system and
procurement may not be necessary.
● Estimated Price: 9830 birr (minimum)
- Development Computer Devices: Devices that will be used by the developers to
develop and write the software product
● Specifications: Windows 10 or later, minimum 8 GB RAM
● Note: As each developer has their own personal computer device for current use,
procurement of this item may not be necessary.
● Estimated Price: 9830 birr (minimum)
- Deployment Server: Servers the system and the database will be deployed on. These can
be part of the existing AASTU ICT infrastructure.
● Specifications: Internet connectivity, minimum 2GB RAM, minimum 512MB of
harddisk space
7.3 Staff Management Plan
The staff involved during the development of this project can be organized into one of two job
fields listed below:
- Fullstack Developers: Developers capable of working on both the frontend and backend
architectures of a system. They are capable of assuming various roles within the project.
Deal with the development of the client side interfaces and server implementation of the
application logic. A fullstack developer can assume the role of frontend engineer,
backend engineer, or a quality assurance tester.
Page 26 of 47
- Salary: 8850 birr (on average in the Ethiopian Market)

- Quantity: 3
- Project Manager: An individual responsible for coordinating and managing the project.
- Salary: 11300 birr (on average in the Ethiopian Market)
- Quantity: 1
Listed below are the roles and responsibilities of the various actors present in the development of
the system. It also includes the mapping of these roles with the staff available (developers
available).
Table 8. Roles and Responsibilities
Roles Who Responsibilities
Ezira Ashenafi - Initiation, planning,

Project Manager executing the project
- Controlling, monitoring
- Change control
- Closing down the project
Getachew Muhabaw, - Designing, Developing and

Frontend Developer Yohanns Fenta maintaining the user interface
of the system.
Yohannes Fenta, Ezira - Designing, Developing,

Backend Developer Ashenafi configuring and maintaining
the server and database of the
system.
- Develop mobile interface

Special mobile interface Getachew Muhabaw that run on mobile browsers
Developer
Page 27 of 47
Ezira Ashenafi - Executes test case under

different circumstance
QA and Tester - Documents and evaluate
test results
- Detect, log and reports
program bugs and glitches
- Track defects and
troubleshoot errors
Change Control Board Getachew Muhabaw, - Review Changes to the

Yohannes Fenta, Ezira project
Ashenafi, and 2 additional - Approve or Decline
members from AASTU proposed changes to
project scope
- Document changes
8 STAKEHOLDER MANAGEMENT PLAN
Stakeholder is a person, group or company that is directly or indirectly involved in the project
and who may affect or get affected by the outcome of the project.
In our project the stakeholders are the team members involved in the development and the final
stakeholder is the user of the software after we release which means the end users.
8.1 Project Stakeholder Management Plan Process
The PMI identifies four key processes that are associated with stakeholder management
knowledge in Initiating, planning, executing, and monitoring and controlling process groups[5].
Stakeholder involved in the project process, that are involved either directly or indirectly from
the software data collection to software deployment process are:
Page 28 of 47
Table 9. Stakeholder list and their descriptions
Stakeholder list Process group Detail Type of stakeholder
Project Manager Initiating, Monitoring and A person who controls the Internal stakeholder
controlling, planning overall activity of the project
and gives directions to the
team members.
Developer executing Members of our team like Internal stakeholder

frontend developer, backend
developer, special mobile
interface developer and tester
Students executing Includes all students found in External stakeholder

different levels that have a
registered computer
Page 29 of 47
Staffs executing Staff members like lecturers, External stakeholder

Administers, and all member
that are employed in our
campus
Security officer executing An authorized body that can Internal stakeholder

register computers and control
issues associated with
registering computers
Gate Security Guards executing A person who controls leaving External stakeholder
and entering computes among
different gates in the campus.
As we work on the project in a team the major tasks and activities are done by ours. So let us explore the developer stakeholder more
specifically.
Page 30 of 47
Table 10. Developer stakeholder (Team)
Stakeholder Title/role Interest: How Influence: How What is How will he Best way to
much does the much do they stakeholder’s contribute? manage
project affect them have most important
goal?
(1,2,3) (1,2,3)
Ezira Ashenafi Project Manager 2 2 Stay consistent Assign tasks for Phone call,
and do works team members Talking on
effectively and compile the telegram group,
according by the document google docx,
schedule email, Face to
face meeting
Getachew 2 1 Design cool look Make user

Muhabaw and feel user interface and
Frontend interface and receive feedback
Developer attract the users form the team
of the system member
Page 31 of 47
Yohannes Fenta Backend 2 1 Make the system Integrate the

Developer easily integrated backend to the
to other system frontend and
and use effective control the
data structure database system
of the software
Page 32 of 47
9 COMMUNICATIONS MANAGEMENT
9.1 Purpose
The Communication Plan defines the means and frequency of communications between
members of the project team. It should be read by all members of the project team in order to
ensure a common view of communications. Communication is required between a number of
parties. This document defines the following groups of individuals/stakeholders listed on the
table.
9.2 Project Communication Plan
The project team needs to know what the project is about, what is the requirement of the project.
To make this happen the client must clearly identify or explain what he needs, functional and
non-functional requirements the system should have. And for project success the project team
must not only be doing a good job but be seen to be doing a good job by the other project
stakeholders.
The team who is going to produce the system requirement specification needs information from
the client and from the user. And the client and the user should be committed and give everything
they know to help the team to correctly identify and specify the requirement. And the client
needs information about the cost and time the project will consume. And also client need
information about the current position and progress of the project.
To fulfill the information needed by various stakeholders. We should facilitate communication

among them. The following table shows a communication plan.
9.2.1 Communication matrix
A communication matrix identifies various actors or stakeholders in the system and describes
how they communicate. A communication matrix is key to allow collaboration and a productive
communication environment between the various stakeholders of the project. Below is the
communication matrix for the project.
Page 33 of 47
Table 11. Communication Matrix
Who stockholder What Why do they When they How will they get it
information do need it for will
they need get it
Requirement gathering Client‘s need To correctly specify At project initiation - By Asking what
team features system the requirement and the client and
would have need of the client user need
- Observing and
gathering
Designing team SRS To build the design After the completion Copy of Documented
from the SRS of requirement requirement
gathering specification
Implementation team What is the design To implement the After completion of Documented
design design architectural and
detailed design.
Page 34 of 47
Client project manager Report about the To see the progress After monthly meeting Copied on monthly
progress of the of the project and to progress report
project evaluate how
successful the project
is going on
Prototypes of design To evaluate a design At every iteration of Formally drawn or

for example to design sketched Picture of
evaluate GUI design design
Project team Progress report In order to know the Bi- monthly Minted meetings
progress and to
estimate remaining
resources.
Page 35 of 47
10 RISK MANAGEMENT
A risk is any event that adds uncertainty to the project. This means a risk may have an additive or
subtractive effect upon the project’s goals and objectives. This section of the document will
define the risks associated with the project and also how they will be managed. It will describe
how risk management activities will be carried out.
For risks that are predictable in nature and/or listed in this document, the risk management
process will involve carrying out the respective risk mitigation plan listed below. For risks that
may arise due to unprecedented circumstances and that are wholly unpredictable, the project
manager will be responsible for formulating a risk management process. This means the project
manager is responsible for analyzing the risk and formulating a mitigation plan in a short period
of time for any unforeseen risk that arises during project development.
10.1 Risk Identification
The risks associated with the proposed project can be classified into the following categories
based on their source and area of effect[6]:
- Strategic Risk: risks that can disrupt the normal processes of the university. They may
arise from within or outside the university
- Operational Risk: risks that may result in failure of any aspect of the system’s use or
operation
- Technological Risk: risks involved with the introduction of new technologies and
systems
- Environmental Risk: risks surrounding the operational environment of the system.
Risks in this category are often from external sources that are beyond control.
- Technical Risk: risks associated with the evolution of the system’s design and
production
Page 36 of 47
Table 12. Risk mitigation plan
Number Risk Risk Description Categories
During development and testing, the developers

require a barcode reader device to scan device
serial numbers and user IDs, identify and test
interfaces, and implement the system accordingly .
1. Availability of a Barcode reader Strategic, Operational
These readers have to either be purchased or
requested from AASTU. Due to possible time and
resource constraints, these items might not be
available.
Page 37 of 47
As the proposed system is centralized, each instance

of the system deployed at the gate needs internet
Internet connectivity and reliability
2. connectivity. However this connection might be Environmental, Operational
issues.
interrupted leading to service availability and
synchronization issues.
Individuals may provide incorrect and fraudulent

Fraudulent Registry of device device serial numbers and user IDs. This could
3. Operational
serial number and user ID happen due to errors by the individual. However this
can lead to security issues in the future.
Some devices (due to deterioration, or various

manufacturing issues) might not have scannable
barcodes that can be used for identification. This can
Operational, Strategic,
4. Lack of Scannable Barcode render a device unregistrable or prevent the
Technological
individual from leaving the campus with their
device.
Page 38 of 47
If the number of students that leaves and enters the

gate increases it may take a time if and only the
5. Increased traffic at gates number of barcode readers are limited. This can lead Strategic
to long waiting queues and congestion at the gates.
The system requires integration in the existing

Student information management system (SIMS) to
access student information. This is essential for the
6. SIMS Integration system as it allows for user identification. However, Operational, Technical
access to SIMS interfaces might not be available.
This will affect how the system processes the
individual’s id and personal information
Page 39 of 47
AASTU has a student ID scanning system currently

implemented at the gates to the campus. This system
uses a barcode reader and a laptop at each gate to Environmental, Technical
7. Conflict with Existing systems function. There is a risk that our system and the
existing system cannot work on the same system,
due to how inputs from a barcode reader are
handled.
In the event of power outages at the campus or at

one of the gates, there can be a gap in information
8. Power Fluctuation about laptops entering and leaving the campus. This Environmental, Operational
can lead to malicious individuals targeting these
times to smuggle stolen laptops.
Page 40 of 47
10.2 Qualitative Risk Analysis
Both the probability and the possible impact of each of the risks listed above can be organized
into a scale of values high, medium and low. High indicates a high probability of occurrence or a
potential to greatly impact the project while low signifies a low probability of occurrence or very
little impact on the project.
SIMS Integration
High Conflict with Existing
Power Fluctuations Availability Of Barcode
Systems
Reader
Lack of Scannable
Barcode
Medium Increased Traffic at Gates
Internet Connectivity
Issues
Fraudulent Registry of
Low
Device Serial Number
Low Medium High
Impact
Figure4. Risk Analysis Matrix
10.3 Risk Response Planning
Issues marked red and yellow in the above matrix mark issues that are unacceptable. This means
that these issues require mitigation, and if possible, contingency plans. However all the risks
stated above require some form of a response. This response may follow an avoid, mitigate or
accept response strategy. Below is a list of the risks and their respective response plans.
- Availability of Barcode Reader
● Response Strategy: Accept
● Response Details: The project must attempt to procure one or more barcode
readers. In the event that a barcode reader is not available, the system should be
Page 41 of 47
built using mobile phone cameras to scan device barcodes. The appropriate
interfaces should be provided to allow for this and ensure no loss of functionality
- Internet Connectivity and Reliability
● Response Details: The proposed system will be made to maintain a local copy of
the server database on each of the computer devices used at the gates. In the event
that an internet connection is not available, the system should work offline off of
each individual computer device at the gates. Furthermore each of the computer
devices at the gates should be capable of synchronizing with the central server
when internet connection is restored.
- Fraudulent Registry of device serial number and user ID
● Response Strategy: Avoid
● Response Details: The system will attempt to avoid this risk by only allowing
authorized personnel and security guards to register device serials and user IDs.
The guards will be responsible for verifying device serials and user IDs during
registration
- Lack of Scannable Barcode
● Response Details: The system should attempt to accommodate devices with
unreadable serial numbers by allowing for a special registry by which university
staff manually record the serial number of the device. The system will then print a
barcode that can be used during future interactions with the system.
- Increased Traffic at gates
● Response Strategy: Mitigate
● Response Details: The system must attempt to perform each registry and
subsequent lookups in a very short period of time. It should avoid any inefficient
processes that might further aggravate the risk of having individuals on long
queue for service.
- SIMS Integration
Page 42 of 47
● Response Details: The system should provide a failsafe identification and

registration system for the event that an integration into the existing SIMS
platform is not available. This will ensure that the system will maintain its own
database of students and staff that can be linked to device serial numbers.
However this failsafe must use AASTU provided IDs as a source.
- Conflict with Existing Systems
● Response Strategy: Mitigate
● Response Details: The system should be deployed in a non-intrusive manner that
minimizes conflict with other systems present. The system must allow gate
officials to switch between the various existing systems and the proposed system.
Furthermore, the system should be able to work alongside other systems that use a
barcode scanner.
11 PROCUREMENT MANAGEMENT
Section 6 of this document listed various hardware and software resources required by the
project. This section of the document will describe in detail the procurement plan for each of
these resources
11.1 Hardware Resources
The client (AASTU) will be the responsible party for the procurement of the majority of the
hardware resources. This includes deployment servers, deployment computer devices, and
barcode scanners. As stated in section 2 of this document, the ability of the university to provide
these resources has been assumed as possible. Therefore the project will assume the procurement
of the system’s hardware resource requirement will be the sole responsibility of the university.
11.2 Software Resources

The majority of the software resource requirements of the system can be obtained for free.
However each of these resources have their own licenses that have their respective requirements.
Therefore Procurement of these resources will require attention to these requirements.
Visual Paradigm however is a paid software that requires a monthly subscription fee. The fee for
this software has been included as a project cost. The procurement of software licenses to use
Visual paradigm is the responsibility of the Project manager. The licenses for the software should
be available during the entirety of the project timeline.
Page 43 of 47
APPENDIX A: REFERENCES
[1] C. Petterd, “PATTERN EVIDENCE | serial number,” in Encyclopedia of Forensic Sciences, Elsevier,
2000, pp. 1205–1210.
[2] E. J. Jeong, J. H. Bae, and S. R. Jeong, “Guidelines Aimed at Reducing the Risks of User
Acceptance Delay in the Context of an IT Service Project Management Plan,” Int. J. Elect. Computer
Syst. Eng., vol. 5, no. 4, 2015, [Online]. Available: https://core.ac.uk/download/pdf/329118034.pdf
[3] J. P. Cavano and J. A. McCall, “A framework for the measurement of software quality,” in
Proceedings of the software quality assurance workshop on Functional and performance issues, Jan.
1978, pp. 133–139.
[4] J. Feller, B. Fitzgerald, and Others, Understanding open source software development.
Addison-Wesley London, 2002.
[5] Project Management Institute, Guide to the Project Management Body of Knowledge (PMBOK
Guide) and the Standard for Project Management. Project Management Institute, 2021.
[6] Z. Kremljak and C. Kafol, “Types of Risk in a System Engineering Environment and Software Tools
for Risk Analysis,” Procedia Engineering, vol. 69, pp. 177–183, Jan. 2014.
Page 44 of 47
APPENDIX B: KEY TERMS
Term Definition
AASTU Addis Ababa Science and Technology University
PMI Project management Institute
COCOMO Constructive Cost Model
EAF Effort Adjustment Factor
KLOC Thousands of lines of code
KDLOC Thousands of developed lines of code
Tdev Development time
Page 45 of 47
APPENDIX C: LIST OF TABLES AND FIGURES
List of Tables page

Table 1. Deployment Plan . . . . . . 7
Table 2. Milestones . . . . . . 10
Table 3. Dependencies list . . . . . . 12
Table 4. Cost driver factors . . . . . . 14
Table 5. Dependency costs budget . . . . . 17
Table 6. Quality Assurance Factors using McCall’s factor model. . 19
Table 7. Quality Management Plan . . . . . 23
Table 8. Staff roles and responsibility . . . . 27
Table 9. Stakeholder list and their descriptions . . . 29
Table 10. Developer stakeholders . . . . . 31
Table 11. Communication matrix . . . . . 34
Table 12. Risk mitigation plan . . . . . 37
List of Figures page

Figure 1. Work breakdown structure . . . . . 7
Figure 2. Deployment diagram . . . . . 8
Figure 3. Project schedule chart . . . . . 12
Figure 4. Risk analysis matrix . . . . . 42
Page 46 of 47

Job Board Project Plan

Uploaded by

Copyright:

Available Formats

Job Board Project Plan

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Job Board Project Plan

Uploaded by

Copyright:

Available Formats

AASTU LAPTOP E-LEDGER SYSTEM

PROJECT MANAGEMENT PLAN

10.1 Risk Identification 37

1.1 Purpose of Project Management Plan

2 EXECUTIVE SUMMARY OF PROJECT

3.1 Scope Definition

3.2 Work Breakdown Structure

Figure 1. Work breakdown structure

3.3 Deployment Plan

Table 1. Deployment Plan

Task Start date Finish date owner status

Stand up the 3/11/2022 3/11/2022 Ezra A. planned

Run 3/11/2022 3/11/2022 Getachew planned

Check error 3/12/2022 3/12/2022 Ezra a. planned

Review 3/12/2022 3/11/2022 Ezra A. planned

Figure 2. Deployment diagram

3.4 Change Control Management

Milestones Description Deliverables Time

Requirement Requirements System Requirement 1/5/22 - 1/14/22

Project Estimation Based on the Project management 1/14/22 - 1/22/22

Design Design the new system Software Design 1/22/22 - 2/2/22

Development and Implementing the new Software Product 2/2/22 - 3/9/22

Deployment Deplothe system and - 3/11/22 – 3/11/22

4.2 Project Schedule

Figure 3. Project Schedule chart

- This is the first phase of the

Analysis and Planning Phase The requirement elicitation

Requirement Gathering Project estimation requires

elicitation and analysis

Requirement Gathering Design will be based on

Requirement Gathering Development will be solely

Development and Testing This phase will test the

Development and Testing This phase will provide

ALL Final Deployment of the

5.1. Project Estimation

Table 4. Cost driver factors

id Cost driver Factor Priority Value

1 RELY, required reliability Very high 1.4

2 CPLX, product complexity Low 0.85

3 STOR, main storage constraint High 1.06

4 PCAP, programmer capability Very high 0.70

5 PLEX, programmer language High 0.95

6 DB, database size High 1.08

7 Others factors Nominal 1.0

Ei (initial effort) = a* (KDLOC) b

Ei (initial effort) =3.2* (3KDLOC) 1.05

Ei (initial effort) = 10.14PM

Effort Adjustment Factor = is the product of 15 cost driver attributes

Total effort =Initial effort *EAF

Total effort = 10.14 *0.91 PM

5.2 Estimated Development Time

Development time = ci*(Total effort) di

5.3 Estimated Staff size

Staff size(ss) =Total effort/Development time

Staff size(ss)=20.54/7.5 Persons

Staff size = 1.59 Persons

- Traveling and Training cost

Table 5. Dependency costs budget

ITEM/Labor ITEM/Labor Unit Birr/Unit TOTAL

Project cost = (80003)3 + 12000*3