Comprehensive Software Project Management Workbook: E-Donation Project

This document serves as a project management workbook for the E-Donation project, an initiative aimed at facilitating online donations, particularly in response to the challenges posed by the COVID-19 pandemic. The workbook encompasses various crucial sections including a project charter detailing project information, objectives, and success criteria; a stakeholder analysis outlining the interests, needs, and communication modes of key stakeholders; and a communication strategy that defines the approach to be taken with each stakeholder group. It also includes a project scope statement, which describes the product scope and deliverables, such as documentation, UX/UI studies, and design mock-ups. The project employs the agile model, emphasizing flexibility, user feedback, and continuous testing. The workbook also addresses system requirements, budget, and project planning, including the maintenance of timesheets for team members. The project's objectives include providing a user-friendly interface, ensuring reliable donation methods, and promoting transparency, with a focus on bridging the communication gap between donors and beneficiaries. The workbook covers detailed planning, including the project charter, scope, and stakeholder analysis, and is based on international standards for software project management documents.

Using the Document
This document provides a set of templates for the Project Management
Workbook to be submitted as Assessment for the course of Software
Project Management.
The content is based upon the appropriate International Standards for
Software Project Management Documents.
These templates should be considered the minimum level of detail
required for the Workbook. It is expected that you would conduct further
research into relevant material that may be required in each section.
Items that are intended to stay in as part of your final document are in
bold; italic text is used for explanatory information that should be
removed when the template is used.
At the top of each workbook section is a table. This table records who has
worked on each section, and the work that they have contributed. This
table must be kept up to date as the sections are completed, and the
entire team must agree to the content of the table.
Sections 1-7 are planning documents that you complete based on the
project you have chosen. Section 8 of the workbook is a post project
review based on your work over the semester, and this section of the
workbook refers to the development of the workbook itself, NOT the
project you chose. In order to complete this section you will need details
relating to how your team conducted themselves in building the
workbook, as well as the planning material from section 9. Treat the
workbook development as a project.
Section 9 covers the project planning for your workbook. Each team
member needs to keep a weekly timesheet detailing time spent and tasks
completed in this section. This is where tasks may be allocated and
tracked, and individuals can enter timesheet information. This section
must be maintained from the beginning of the project

1. Project Charter
Revision History
Date Ver. Author Addition/Alteration
12/02/20 1.0 Fasiha Fatima
12/03/20 1.0 Fasiha Fatima
1.1 Company Information
Project Title: E-Donation
Project Manager: Zain Abbas
Company Name: TechTree
Team Members:
Fasiha Fatima (17-SE-25)
Muhammad Hamza (17-SE-43)
Zain Abbas (17-SE-103)
Business Experience:
Our company is working since 2019.It is an
international company.
Project Description:
Our project(app) is a platform to donor and beneficiary for making
donation process easier and reliable. Due to Covid-19 ,there is a difficulty for the people to
make donations because have to maintain social distancing .This app will help them to give
donations online .People can give charity or donate to poor e.g. clothes, extra furniture, toys,
extra cooking wares and money etc through our application. Through this application people
can able to find needy people so they could donate things and money of Zakat and Sadqa. In

this application people who know and trust each other will share the details of a needy
person. So that anyone from the group who wants to help can contact that needy person and
can help them through money or things. Our project E-Donation is a social welfare
mobile application. With the help of this application people will make donations
easily and directly.
Project Objectives and Success criteria:
Project Objectives Success Criteria Person Approving
Scope:
Milestones are
 Requirement
phase
 Design phase
 Development
phase
 Testing phase
Project manager will
measure the
performance by using
the AON,AOA and
Gantt chart techniques.
Project Sponsor
Time:
Goals are:
 Provide a user-
friendly interface
for the donor.
 Provide easier and
reliable ways to
make donations
based on social
trust.
 Directly involve
the donor in the
process to improve
transparency.
 Enable users to
organize online
charity events.
 Suggest potential
beneficiaries to
donors and bridge
the gap of
communication
between them
On Fridays of every
week performance will
be measured and gap
will be founded and
then covered.
Project Sponsor
Cost:
Budget ranges from
5000 to 6000.

Google Play Console
Account(3500 to 4000)
Logo Designing (1500
to 2000)
Rupees will be the
currency
Project Sponsor
Other:
All features should be
according to the need
of
stakeholders ,providing
extra satisfaction to
the users.
Performance will be
measured in terms of
planned cost and time. Project Sponsor
Approach:
We are using agile model for this project. Agile model’s phases are different from simple
SDLC .
 Requirement Analysis
 Design
 Coding and developing
 Testing
 Deployment
 Maintenance
Agile has become the go-to framework for helping app startups and development agencies
maintain a focus on delivering a quality app quickly and efficiently. Agile maximizes value
throughout the development process and significantly reduces the overall risk of a project.
Agile model is best for our android application(E-Donation).Agile model is being used
because of following reasons:
1. Quality Product
It was common to test software before launch, but with Agile, testing is integrated throughout
every stage of development to ensure a quality end product. Continuous testing allows room
for adjustments and can catch issues and bugs before they manifest.

2. Faster Time to Market
Sprints play a major role when working Agile. These set periods of time allow teams to
deliver frequently and rapidly. Speed is key for startups.
3. Flexibility
Flexibility is praised as one of the most beneficial reasons to use Agile. Because the
methodology allows for change, there is always room for mistakes and opportunity to iterate.
4. Cost Effective
Becoming more Agile is proven to save money, and most importantly, it helps to invest funds
wisely.
5. People Focused/Collaborative
Agile puts a strong focus on people and collaboration, Which provides the development team
with many opportunities to work with the client and understand their vision.
6. Reduced Risk
Working on small tasks that build up to the big picture will help you identify issues early.
Reducing risk and making it easier to respond to any changes.
7. Enjoyable Work Environment
Instead of team members and clients working in complete isolation for hours, everyone will be
working together to deliver a quality end product. Workshops, brainstorming sessions, and
meaningful conversations are all part of the development process.

8. User Feedback
In most cases, Agile utilizes user stories to determine product features. When you create user
stories, you’ll focus on solving the real needs users have, instead of developing features that
could turn out useless.
9. Quick Decision Making
Working under set deadlines and timeframes will force you to be on your toes at all times.
This applies to decision making as well, because you won’t b to sit down with your team to
agree on every decision.
10. Results Driven
Instead of focusing on the process itself, team will be driven to achieve milestones and
results.
Stakeholders:
Sr. no Stakeholders
1. Client
2. User
3. Consultants
4. Core Team
5. Marketing people
6. Adjacent Systems

7. Technical Experts
8. Special Interest Groups
9. Supervisor
Start and Finish:
Start Date : 5/10/20
Finish Date: 15/01/21
Budget:
Our project requires at least Rs. 6000/- and budget sheet is shown in the
table given below:
System Requirements Costs(PKR)
Google Play Console Account 4000
Logo Designing 2000
1.2 Stakeholder Analysis
Stakeholder Analysis
Following are interests ,needs and communication modes of each stakeholder:

1. Client:
Client pays for the development of product. Client shall need on time delivery of
project within time, budget and meets the requirements of client. Client can
communicate with developer through emails, online and offline meetings.
2. User:
User uses the product. User shall need that product/project should work properly and
efficiently. User can communicate with developer through emails and contact number.
3. Consultants:
Consultants who internal to the organization and external are people who have some
expertise you need to help you uncover the right requirements. Consultants shall need
weekly or monthly reports i.e progress reports and information reports. Consultants
can communicate through emails, online and offline meetings.
4. Core Team:
Core team is the people who are the part of building effort for the product.Core team
needs code files,baselines ,technical tools etc.Core team can communicate through
emails, phone numbers ,online and offline meetings.
5. Marketing people:
The marketing department of the organization probably represents market forces.
They needs banners and some information about project .They can communicate
through emails and meetings.
6. Adjacent Systems:
The adjacent systems on your work context diagram are the systems, people or work
areas that directly interferes with the work that is being studied.It needs information
about the project. They can communicate through emails, meetings and through any
platform.
7. Technical Experts:
For the stakeholders from this constituency consider usability experts, security
consultants ,hardware experts, software specialists or the expert from any technical
field that the product could use.They need information and reports of the project.They
can communicate through emails, online and offline meetings.
8. Special Interest Groups:
Handicaped interest group, environmental bodies, foreign people, old people, or any
other group that may come in contact with product.They need information that how to
use the product.They can communicate through emails and phone numbers.
9. Supervisor:
Supervisor lead the project. Supervisor need weekly or monthly reports i.e status
reports and progress reports. Supervisor can communicate through emails,phone
numbers , online and offline meetings.

1.3 Communication Strategy
Following are the communication strategies that are adapted to each stakeholder:
1. Client:
User Manual and SRS is provided to Client. Formal meetings can be conducted in
hour of need or weekly.
2. User:
User Manual is provided to User. User can sent emails and can text or call to the
developer when required .Communication would be formal with Users.
3. Consultants:
Progress Reports, SRS and user manual of project is provided to Consultants.Formal
meetings can be conducted weekly or monthly.
4. Core Team:
SRS, User manual ,code files and baselines are provided to Core Team. Informal
meetings can be conducted when required .Meetings can also be conducted weekly.
5. Marketing people:
Banners and User Manual are provided to them .Formal meetings can be conducted
with them when required.
6. Adjacent Systems:
User manuals are provided to them .Formal meetings can be conducted in hour of
need.
7. Technical Experts:
User Manuals and SRS are provided to technical experts.Formal Meetings are
conducted between them.These meetings can be conducted in hour of need or weekly.
8. Special Interest Groups:
User Manuals are provided to them. They can sent emails and can text or call to the
developer when required .Communication would be formal with them.
9. Supervisor:

Progress Reports, User Manuals and Status Reports are given or provided to
Supervisors. Formal meetings are conducted with supervisor. Meetings can be
conducted weekly or when required.
2 Project Scope Statement
Revision History
Date Ver. Author Addition/Alteration
12/02/2020 1.0 Zain Abbas
2.1 Product Scope Description
The outbreak of COVID-19 has made it extremely risky to attend or arrange
charity events and to give donations. With the dire need for social distancing, we
should find ways to remotely help and interact with the needy. The fundamental
goal of this project is to facilitate as much as possible the act of charitable
giving. Our purpose is to provide donors and beneficiaries with a platform to
facilitate and ensure the donation process. People like and want to donate many
things to poor people such as clothing, extra furnishings, toys, extra kitchen
wares, and money. But it can become difficult to find the right person. Using this
application, people will be able to find truly deserving beneficiaries. The users
who know and trust each other will be able to share the details of a needy person
and this interaction will also bring donors together for when a combined effort is
essential. Through our best efforts, we aim to:
 Provide a user-friendly interface for the donor.
 Provide easier and reliable ways to make donations based on social trust.
 Directly involve the donor in the process to improve transparency.
 Enable users to organize online charity events.
 Suggest potential beneficiaries to donors and bridge the gap of
communication between them.
2.2 Product Deliverables
Documentation
Different types of documents are created through the whole software
development lifecycle (SDLC). This will encompass all the documentation and
materials generated regarding the app development and use. Documentation

exists to explain product functionality, unify project-related information, and
allow for discussing all significant questions arising between stakeholders and
developers.
UX/UI study/wireframes, design mock-ups and other artwork
This will include UX/UI design elements such as icons, images, prototypes, and
logos etc. Wireframe will be the app's blueprint that shows its structure and how
all of its elements work together. Wireframes can help one determine the app
development cost, as they visually outline the app's functionality and technical
needs.
Source Code of the Versions
As opposed to the widespread assumption that source code “self-documents”,
there is a great deal of code behavior that cannot be expressed simply through
source code but requires the power and flexibility of natural language. In most
cases, the source code documentation acts as a specification of behavior for
other engineers. Without documentation, they are forced to get the information
they need by making dangerous assumptions, scrutinizing the implementation,
or interrogating the author. These alternatives are unacceptable. Consequently,
source code documentation is an irreplaceable necessity, as well as an important
discipline to increase development efficiency and quality.
Compiled versions of the app (.apk on Android, .ipa on iOS)
Since the intended software product will be developed using and incremental
software development model; it becomes essential to compile versions of the
app at each project milestone. These versions will help in tracking the progress
of the project. These versions also act as insurance since they give us the ability
to rollback updates in case they do not work as intended.
3 Work Breakdown Structure
Revision History
Date Ver. Author Addition/Alteration
12/02/2020 1.0 Zain Abbas

3.1 WBS Tree
3.2 WBS Table
ID Task Name Duration Predecessors
unique id Description in days dependent tasks
Ed_01
Problem Domain
Identification 2 Days
Ed_02 Prepare SRS 7 Days
Ed_03
Process Model
Identification 3 Days
Ed_04 Designing 30 Days
Ed_05
Task Management
and WBS 3 Days
Gantt Chart, Activity
Network Diagram
Ed_06 Coding 90 Days
Ed_07 Testing 20 Days
White Box Testing,
Black Box Testing
Ed_08 Maintenance
Lifetime of
Project
Adaptive, Corrective,
Preventive and
Emergency
4 Estimation
Revision History
Date Ver. Author Addition/Alteration