SOFTWARE ENGINEERING PROJECT REPORT || HELP FOR ADMISSION TEST STUDENTS (HATS) || USE CASE DIAGRAM || CLASS DIAGRAM || ACTIVITY DIAGRAM
SE PROJECT
SOFTWARE
ENGINEERING | fall 2019 - 2020
What to make?
Each team is required to come up with an
idea (either Category A or Category B), make a plan and submit. It
can be either purely software or a combination of software and hardware. You
must choose at least one of the options for technology, but if any team is optimistic enough: can choose all of
the available options.
How is a team made?
A team is up to four students. In
addition to each team, other people are allowed to help. A team can have a
mentor, who advises on the project. A team can also have associates, who must
be eligible students that can help the team with things, with business model
planning, marketing, and so on. These people are not members of the team as
such but it's good to have help sometimes.
Problem domain
Category A: Find a real-life problem, even in your own
life or community, and then work to solve it. Build a project that could change
lives. The next big thing could come from you. Facebook and Twitter
started as student projects. Your ideas could be next. Come up with an
innovative application idea and proceed accordingly.
OR
Category B: There might be dozens of software to solve
our real-life problems and provide benefit to business. Come up with an idea
that will extend the current version of those software.
Technology
|
Name: Rokon Md Shafaat Jamil |
ID: 17-33084-1 |
Section: E |
||||
|
Project name: Help For Admission Test Students |
||||||
|
CO4: |
Explain the roles and
their responsibilities in the software project management activities |
|||||
|
Background information and project
goals (5) |
Project management (5) |
Taking responsibility (5) |
Spelling and grammar (5) |
Total (20) |
||
|
|
|
|
|
|
||
Option A: Web
Option B: Desktop
Option C: Mobile Phones/Handheld devices
Project: Help for Admission Test Students
Table of Contents Page No.
Conceptual Foundation
Does the project have a clear target market or audience?
Does the team demonstrate a thorough
understanding of the need, problem or opportunity, including evidence of research into the
need, problem or opportunity?
Is
the project’s purpose and basic functionality easily understood? ………………………. 3
UML
Use Case
Activity Diagram
Class
Diagram ………………………………………………………………………………
6
Effort Estimation
Budgeting
Scheduling
Risk Analysis
Conceptual Foundation
u Does the
project have a clear target market or audience?
Answer: Yes, this project has a
clear target market or audience. The target audience are the students who come
for admission test and also the students who will look for a place to stay
after the admission test.
u Does the
team demonstrate a thorough understanding of the need, problem or opportunity,
including evidence of research into the need, problem or opportunity?
Answer: yes, it is understood by
the team, for example if a student comes to a new city with little to no
knowledge of the surroundings of the city and the exam venue. Then it will a
problem for him/her. In statistics, it is found that about 70% of the students
who come for admission test are clueless of where to stay before or after the
exam. About 80% do not know about the exam venue. So, it is clear that HATS
the students who are in desperate need of help will be aided with a
secure guidance university student and vertical local people of that specific
area.
u Is the
project’s purpose and basic functionality easily understood?
Answer: yes,
the project’s purpose and basic functionality easily understood.
Two types
of user in this system:
·
Students
in need of help
·
People
who are helping
Functionalities of this project:
·
Help
post will be posted
·
Assistor
will help him/her
·
Will
provide a place to stay
·
Will
take to exam venue and return as well
·
Will
stay as paying guest if necessary
·
Payment
can be paid in advance by bkash/debit card or in cash on meeting
UML
UML is an acronym that stands for Unified Modeling Language.
Simply put, UML is a modern approach to modeling and documenting software. It
is based on diagrammatic representations of software components. As the old
proverb says: “a picture is worth a thousand words”. By using visual
representations, we are able to better understand possible flaws or errors in
software or business processes. Mainly, UML has been used as a general-purpose
modeling language in the field of software engineering.
Use Case:
A use case diagram is a dynamic or behavior diagram in UML.
Use case diagrams model the functionality of a system using actors and use
cases. Use cases are a set of actions, services, and functions that the system
needs to perform. In this context, a "system" is something being developed
or operated, such as a web site. The "actors" are people or entities
operating under defined roles within the system. In our project, the use case
diagram shows that there are 3 actors who are “student”, “Admin” and the
“Assistor”. So, we can see that the “student” can register and then login to
the system but first they need to be verified. After verifying they can request
services and then make payments for it. The payment can be done in three ways;
in cash, via bKash, or by credit/debit card. The “Assistor” can register,
login, accept request made by the “students”. The “Admin” logs in and makes the
request valid and the assistor valid for the service to be applied.
Activity Diagram:
Activity
Diagram: We use Activity Diagrams to illustrate
the flow of control in a system and refer to the steps involved in the
execution of a use case. We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows visually using an activity
diagram. An activity diagram focuses on condition of flow and the sequence in
which it happens. We describe or depict what causes a particular event using an
activity diagram. In our Project, The Activity diagram shows the activity of
the student, so it starts then the user gives the information required for the
registration. After that the user is verified as show by “fork” symbol on the
diagram that the email, password and phone number have to be verified. Then the
account is either created or rejected based on the information provided, next
the app will ask for the user to give permission to locate the area he or she
is in, then it will show the available services that can be provided to him or
her therefore the student or user can then request the service. Finally, the student
or user makes the payment and is valid for the service.
Class Diagram:
This is the class diagram of our project “HATS”. There are four (04) classes here
– User, Admin, Students, Assistor. After class name all the attributes has
written. All attributes are private. Then there are all methods which is the
functionality of classes.
User class will inherit other three classes. Admin has an
association relation with Students, Assistor classes. He will manage Assistor
and Students. Assistor will help Students and that is another association
relation.
Effort Estimation:
|
Task |
Duration(days) |
Predecessor |
|
[-]Analysis |
|
|
|
1. On-Site Meetings |
2 |
|
|
2. Discussion with Stakeholders |
2 |
1 |
|
3. Document Current Systems |
6 |
2 |
|
4. Analysis Complete |
4 |
3 |
|
[-]Design |
|
|
|
5. Design Database |
7 |
4 |
|
6. Design Software |
7 |
4 |
|
7. Interface Design |
3 |
6 |
|
8. Create Design Specification |
2 |
7 |
|
9. Design Complete |
2 |
8 |
|
[-]Development |
|
|
|
10. Development system Modules |
4 |
9 |
|
11. Integrate System Modules |
3 |
10 |
|
12. Perform Initial Testing |
3 |
11 |
|
13. Development Complete |
4 |
12 |
|
[-]Testing |
|
|
|
14. Perform System Testing |
2 |
13 |
|
15. Document Issues Found |
3 |
14 |
Work
Breakdown Structure (WBS)
Effort = PM = Coefficient<Effort Factor>
*(SLOC/1000) ^P
= 2.4*
(6000/1000) ^1.05= 15.74 =16
Development time, DM = 2.50 (PM) ^T
= 2.50
(16) ^0.38 = 7.16 =
7 weeks
Required number of people, ST = PM/DM = 16/7 = 2.28 =
2
As HATS is
an organic type
software, the value
of Coefficient<Effort Factor> = 2.4 , P = 1.05 ,
T = 0.38
Budgeting:
Difficult (0.70)
TK. 40K
HATS Build
Simple (0.30)
TK. 20K
Expected Cost = (path probability) X (estimated
path cost)
= 0.3*20 + 0.7*40 = TK. 34k
Budgeting is very important part for developing our software
project HATS. If we don’t calculate our expected cost then in future it will
create problem. For example we don’t know how much money is needed to develop
our HATS project but we start to develop our system. After working one month on
this project we find that we don’t have enough money to finish the project.
Then it will be very harmful for our developer team. And we won’t be able to continue
the project. For this reason we have calculated our expected cost to complete
the project.
As we are building our project and this is a fresh new
project, from some survey we find building a new system can be cost 40K taka
for difficult part and 20K taka for simple part. We consider that our difficult
part of the system is 70% and simple part is 30%. So our calculated expected
cost for making HATS is 34K taka.
Scheduling:
|
All |
Task Name |
Week 1 |
Week 2 |
Week 3 |
Week 4 |
Week 5 |
Week 6 |
Week 7 |
|||||||||
|
1 |
[-] Analysis |
|
|
|
|
|
|
|
|||||||||
|
2 |
On-Site Meetings |
|
|
|
|
|
|
|
|
|
|||||||
|
3 |
Discussion with Stakeholders |
|
|
|
|
|
|
|
|
|
|||||||
|
4 |
Document Current Systems |
|
|
|
|
|
|
|
|
|
|
||||||
|
5 |
Analysis Complete |
|
|
|
|
|
|
|
|
||||||||
|
6 |
[-] Design |
|
|
|
|
|
|
|
|||||||||
|
7 |
Design Database |
|
|
|
|
|
|
|
|||||||||
|
8 |
Design Software |
|
|
|
|
|
|
|
|||||||||
|
9 |
Interface Design |
|
|
|
|
|
|
|
|
||||||||
|
10 |
Create Design Specification |
|
|
|
|
|
|
|
|
||||||||
|
11 |
Design Complete |
|
|
|
|
|
|
|
|
||||||||
|
12 |
[-] Development |
|
|
|
|
|
|
|
|||||||||
|
13 |
Development system Modules |
|
|
|
|
|
|
|
|
||||||||
|
14 |
Integrate System Modules |
|
|
|
|
|
|
|
|
||||||||
|
15 |
Perform Initial Testing |
|
|
|
|
|
|
|
|
||||||||
|
16 |
Development Complete |
|
|
|
|
|
|
|
|
||||||||
|
17 |
[-] Testing |
|
|
|
|
|
|
|
|||||||||
|
18 |
Perform System Testing |
|
|
|
|
|
|
|
|
|
|||||||
|
19 |
Document Issues Found |
|
|
|
|
|
|
|
|
|
|||||||
|
20 |
Correct Issues Found |
|
|
|
|
|
|
|
|
|
|||||||
We have divided our HATS project task in four parts. These
are Analysis, Design, Development, and Testing. In Analysis part we will
analyze project requirements. We will attend meeting with our developer team.
We will make documents. We will identify stakeholders and will be completed in
two weeks. In Design part we will design our database for HATS. And then we
will start designing the system. We will create design specification. And it
will be completed in two weeks. In Development part we will develop our system
modules. We will integrate system modules. And the last task is performing
initial testing. And this part will also be completed in two weeks. The last
part is testing. In this part we perform our actual system testing. And this
will be completed in one week.
|
Task: Person |
Week 1 |
Week 2 |
Week 3 |
Week 4 |
Week 5 |
Week 6 |
Week 7 |
|
1-5: Rokon |
|
|
|
|
|
|
|
|
1-5: Shakib |
|
|
|
|
|
|
|
|
6-11: Fariha |
|
|
|
|
|
|
|
|
6-11: Rokon |
|
|
|
|
|
|
|
|
12-16: Udoy |
|
|
|
|
|
|
|
|
12-16: Shakib |
|
|
|
|
|
|
|
|
17-20: Udoy |
|
|
|
|
|
|
|
Activity Key: 1-5:
Analysis
6-11: Overall Design
12-16: Developing System
17-20: System
Testing
We are four members in our team to develop the HATS. We have
divided our task in four parts. Rokon and Shakib will complete the Analysis part,
Fariha and Rokon will complete the design part, Udoy and Shakib will complete
the developing part. And Udoy will complete the testing part.
Risk
Analysis
As Project plans are based on assumptions. The risk of the
assumption being wrong is always present.
When the risk happens, it becomes a problem or a potential
issue. Risks are potential problems that might affect the successful completion
of a software project. In the HATS project, we are following the reactive risk
management. So, we will fix a problem when we face it and plan for resources to
narrow down the damages. One of the main risks of this project is how to come
up with money when it exceeds the expected cost we predicted. There are several
more risk and as we analyzed them, here are the probability of them happening:
-
|
Risk |
Category |
Probability |
Impact |
|
Staff
Shortage |
ST |
80% |
3 |
|
Lack of
experience in staffs |
ST |
60% |
3 |
|
Lack of
proper equipment |
DE |
60% |
2 |
|
Users larger
than expected |
PS |
40% |
2 |
|
Not being
able to show “newness” to customers |
TE |
20% |
1 |
|
Bad analysis
of time and cost estimation |
CU |
80% |
1 |
|
How far can
the product give services to customers |
PR |
70% |
3 |
By, analyzing the risks associated with the project, we can
say lack of experienced staff are 60% as a result out loss would be about 15000tk,
so if we try to bring in more staff the costing would be about 5000tk and this
cuts down the risk by 30%
So, if we use the equation RRL,
=>
((0.60x15000) - (0.30x15000))/5000
=>
7500/5000
=> 1.5
As RRL>1, so we should go for this solution if It ever
raises.
“Every Risk is worth taking if as long as it’s for a good
cause and contributes to a good life”
-Richard Branson
No comments