Course: COMP1640 Enterprise Web Software Development- Group
Due date: 13th April 2017
Extenuating Circumstances Management
Group Members Nguyen Truc Giang Scrum Master, Tester
Nguyen Duc Thang Developer, DB
Tran Duc Huy Developer, DB
Ngo Nguyen Hoang Ngan Developer, Designer
Teacher To Hoai Viet
Contents
1. Introduction .......................................................................................................................................... 3
2. AGILE SCRUM DOCUMENTATION ............................................................................................................ 3
2.1 ROLES .................................................................................................................................................. 3
2.2 TOOLS ................................................................................................................................................. 3
2.3 MEETINGS ........................................................................................................................................... 4
2.4 PRODUCT BACKLOG ........................................................................................................................... 4
2.5 SPRINT BACKLOGS .............................................................................................................................. 7
2.6 PROJECT BURN DOWN CHART ........................................................................................................... 7
3. DESIGN DOCUMENTATION ...................................................................................................................... 7
3.1 USERS CASE DIAGRAMS ..................................................................................................................... 7
3.2 DATABASE DESIGN ............................................................................................................................. 8
3.2.1 Entity Relationship Diagram ....................................................................................................... 8
3.2.2 Relational Schema ....................................................................................................................... 9
3.3.1 Website Wireframes ................................................................................................................. 10
3.3.2 Sitemap ...................................................................................................................................... 12
3.4 Workflow implementation .......................................................................................................... 13
4. IMPLEMENTATION ................................................................................................................................ 14
4.1 LIST OF FILES CREATED AND ROLES ................................................................................................. 14
4.2 SCREEN SHOTS OF SYSTEM IN OPERATION ..................................................................................... 16
5. TESTING .................................................................................................................................................. 27
5.1 TEST PLAN ......................................................................................................................................... 27
5.1.1 User Interface ............................................................................................................................ 27
5.1.2 Student Form to create claims specification ............................................................................ 28
5.1.3 Approval or Rejection of claim specification ........................................................................... 29
5.1.4 Coordinator Add Assessment ................................................................................................... 30
5.1.5 Coordinator Edit, Delete Assessment ....................................................................................... 31
5.1.6 University Manager add users and view claim ........................................................................ 33
5.1.7 Reports Product......................................................................................................................... 35
5.2 TEST LOG ........................................................................................................................................... 37
6. EVALUATION........................................................................................................................................... 37
6.4 ASSUPTIONS ..................................................................................................................................... 37
6.5 CHALLENGES ..................................................................................................................................... 37
6.2 SYSTEM WEAKENESSES .................................................................................................................... 37
6.6 SYSTEM STRENGTHS ......................................................................................................................... 38
6.3 LEARNING OUTCOMES ..................................................................................................................... 38
7. Reference ................................................................................................................................................ 38
1. Introduction
This my group is required to develop a secure web-based system for managing students who can submit
one or more EC claims for any item of assessment in a major university. The generated system must be
able to display the student's complaint filing process for an examination, when requested to be
submitted the system will send a notification to the EC Faculty Coordinator, upon request. Resolving
students will receive an email containing the decision. It is important to note that the scope of this
project is 'Appeal Processing Cycle' and this project follows the processes of that request system using
agile work practices. The project and its customers are named EC University.
Below is the requirement specification as obtained. A system that accomplishes the following:
• Authorize for EC Manager to allocate or reallocation supervisors and second markers to
students
• The University EC Manager can view all the claims but cannot process any.
• An administrator maintains any system data,
• All Faculties have EC Coordinator who is responsible for managing the process for their Faculty.
• Once a claim is submitted the system emails a notification to the Faculty’s EC Coordinator, who
must process it within 14 days.
• An EC can only access claims by students in their Faculty.
• Each EC Coordinator needs to be able to process the claims by students in their Faculty in order
to approve or reject them.
• Can submit one or more EC claims for any item of assessment.
• Students need to be able to view their own claims and any decisions.
Below is a diagram of the coursework lifecycle:
2. AGILE SCRUM DOCUMENTATION
2.1 ROLES
The roles needed for the project and circulated between team members are:
• Database designer
• Programmer
• Web designer
• Tester
• Product Owner – Lecturer
2.2 TOOLS
Site functions will be developed primarily using ASP and HTML. The backend database will be
implemented using SQL. Below is a list of tools and technologies used for development and
documentation systems:
• Visual Studio 2013
• Dreamweaver
• SQL server
• Microsoft office word 2013
2.3 MEETINGS
2.3.1 Sprint planning
Our first meeting was held on 01/02/2017 at 11:00 pm. The agenda was:
• Discussion of personal ability; Strengths, weaknesses that will allow us to divide tasks.
• Review and record technology that we will use.
• Define product backlog:
✓ The requirement that we say we will have after analyzing the subject.
✓ Describe the features of the product needed.
✓ Requires order details by priority, task, person assigned to each hour to spend on duty / s.
• Set a release date
• Determine the content of the finished product
• Discuss how much sprint we will have and the duration of that.
• Define Sprint Backlog (subsets of backlog)
✓ Requirements for each job as input, then we design, code and test, then with a prototype
test as output.
✓ This will show the deliverables, tasks, hours spent, the status of the tasks; Means start, in
the process, complete.
• Create the project burn down char.
2.3.2 Pre-Kick off meeting
Held on 03/02/2017 18: 05hrs. To ensure that all goals and tasks are understood then start working.
2.3.3 Sprint Review
Done after each sprint with temporary deliveries as stated in the courses. For example: Database design,
Web site design and test planning. Attendance must also be a trainer in this case as the product owner.
2.3.4 Sprint Retrospective
Review work without the presence of product owner (trainer), we have determined whether we should
start, stop or continue the project.
2.3.5 Daily Scrum
It's been done weekly and sometimes twice a week, not every day.
2.4 PRODUCT BACKLOG
PRIORITY ITEM NO. DESCRIPTION EST HOURS BY
VERY HIGH
01 Create Database design 12 G, H,T,N
02 Create website wireframe 12 G, H,T,N
and site map
03 Create Test plan based on 12 G, H,T,N
project requirements
HIGH
04 Create requirements 5 H
snapshot for
requirements.
05 Create policy snapshot 6 H
for policies and BB
Framework - integration 4 G
of GUI with Desktop
06 Build webpages based on 4 G
wireframes and sitemap
without any functionality
behind forms.
07 Build database based on 2 N
database design; all
tables
08 Create functional Login 2 G
system
09 Populate database with 3 N
sample data
10 Create EC Manager page 2 N
with functionality of
Display list of EC Manager
and student.
11 Create EC Manager page 2 N
with functionality of the
University EC Manager
can view all the claims
but cannot process any.
12 Create EC Manager page 2 N
with functionality of An
administrator maintains
any system data
13 Create EC Coordinator 1 G,N,H
page with functionality of
Display list of students
and claims
14 Create EC Coordinator 3 G,N,T
page with functionality of
All Faculties have a EC
Coordinator who is
responsible for managing
the process for their
Faculty.
15 Create EC Coordinator 2 H
page with functionality of
Once a claim is submitted
the system emails a
notification to the
Faculty’s EC Coordinator,
who must process it
within 14 days.
16 Create EC Coordinator 2 T
page with functionality of
Once a claim is processed
the student receives an
email containing the
Coordinator decision.
17 Create EC Coordinator 1 H
page with functionality of
An EC can only access
claims by students in
their Faculty.
18 Create EC Coordinator 2 N
page with functionality of
Each EC Coordinator
needs to be able to
process the claims by
students in their Faculty
in order to approve or
reject them.
19 Create Student page 5 G
with functionality of
Display claims
20 Create Student page 3 G
with functionality of Can
submit one or more EC
claims for any item of
assessment.
21 Create Student page 2 N
with functionality of
Students need to be able
to view their own claims
and any decisions.
MEDIUM
22 Create reports with SQL 7 G
queries
23 Add data validation to all 4 G
forms
24 Compile all available 4 G,N,T,H
documentation for
project concisely
25 Run system and fix any 3 G,N,T,H
error/bugs detected
26 Implement test plan 4 G,N,T,H
27 Final documentation 3 G,N,T,H
Key
G – Giang. N – Ngan. H – Huy. T - Thang
2.5 SPRINT BACKLOGS
We had a total of four sprints during the project.
2.6 PROJECT BURN DOWN CHART
The chart below shows the combustion diagram of the project divided into 220 points representing the
whole project task. As we have four sprints; 3 runs for 12 days and last for 8 days, totaling 44 days to run
the project. The release date is set for February 3, 2017.
Figure 1.1: Burn Down Chart
3. DESIGN DOCUMENTATION
3.1 USERS CASE DIAGRAMS
For our design, we will use the 'Use Case' diagram. It should be noted that this design only describes the
design of the student claims management system in the university and not anything beyond this scope.
The internal and external agents are called actors. Therefore, use case diagram is composed of actors,
use cases and their relationship. The diagrams are used to model the systems / subsystems of an
application.
Figure 1.2 UML Diagram
: EC Manager
: Student
: EC Coordinator
3.2 DATABASE DESIGN
3.2.1 Entity Relationship Diagram
Here Coursework Lifecycle ERD. Please note that looking at the university as a whole will require other
units, however for the purpose of this system's scope; Coursework Lifecycle, only below is defined and
relationships there. This thus makes the life-cycle system a subset of a much larger university system.
ER-model is a data modeling technique used in software engineering to create a conceptual data model
of an information system. The diagram generated using the ER technique-this model is called entity-
relationship diagrams, ER diagrams or ERDs. So you can say that entity relations diagrams illustrate the
logical structure of the database. And so below
Figure 1.3 Entity Relationship Diagram
3.2.2 Relational Schema
NOTE: the Primary Keys are underlined, bold and Foreign Keys are in red
Table_User (User_ID, User_Email, User_Password, User_Frist_name, User_Full_name, User_Phone,
User_Address, User_Status, User_Role_ID)
Table_Claim (Claim_ID, Assessment_ID, Claim_Desciption, Claim_Date, Claim_Type_ID, Claim_Status,
User_Student_ID)
Table_Faculty (Faculty_ID, Faculty_Code, Faculty_Name, Faculty_Year, User_Coordinator_ID)
Table_Faculty_stu_ (Factulty_stu_ID, Faculty_ID, User_Student_ID)
Table_Claim_type (Claim_type_ID, Claim_type)
Table_Assessment_ (Assessment_ID, Assessment_Name, Assessment_Deadline, Assessment_type_ID,
Factulty_ID)
Table_Assessment_type_ (Assessment_ID, Assessment_type)
Table_Evidence (Evidemce_ID, Evidence_URL, Claim_ID)
3.3 WEBSITE DESIGN
3.3.1 Website Wireframes
Below is a design of the homepage and log in pages and other pages (the other pages follow a general
design)
Figure 1.4 Homepage and Login Wireframe
Figure 1.5: General pages wireframe
3.3.2 Sitemap
HOME
CLAIM MANAGER ABOUT US LOGIN CONTACT US
EC MANAGER STUDENT EC COORDINATOR
LIST EC MANAGER LIST CLAIM LIST STUDENT LIST STUDENT
LIST CLAIM
PROCESS FACULTIES SUBMIT AND LIST CLAIM SEND MAIL
STATISTICAL ANALYSIS
REJECT CLAIM
Figure 1.6: Website Site map
3.4 Workflow implementation
Figure 1.7: Workflow implementation
4. IMPLEMENTATION
4.1 LIST OF FILES CREATED AND ROLES
No. Page Name Role
1 HomeController.cs It controls all functions of
the project.
2 SendMailController.cs Handle function send mail.
3 Login.cshtml The site home page/landing
page that visitors see first.
Handles the login of a
student displaying text field
for username and password
and a login button.
4 Error.cshtml Handle error function
5 Home_Manager.cshtml Page displayed after
manager log in and show all
faculty.
6 Home_Coordinator.cshtml Page displayed after
coordinator log in
7 Home_Student.cshtml Page displayed after student
log in
8 Manager_viewAll_stu.cshtml Handle function view all
students.
9 Manager_Create_User.cshtml Handle function manager
create new Student,
Coordinator.
10 Manager_Edit_faculty.cshtml Handle function allocate for
Coordinator manager their
faculty.
11 Manager_viewDetail_faculty.cshtml Handle function manager
view detail faculty.
12 Manager_Delete_faculty.cshtml Handle function manager
delete faculty.
13 Manager_viewAll_claim.cshtml Handle function manager
view all claim
14 Manager_viewDetail_claim.cshtml Handle function view detail
claim
15 Manager_viewAll_coor.cshtml Handle function manager
view all Coordinator.
16 Manager_Edit_Coor.cshtml Handle function manager
edit coordinator
17 Manager_Create_faculty.cshtml Handle function manager
create new faculty
18 Coordinator_viewAll_stu.cshtml Handle function
Coordinator view all
Student.
19 Coordinator_addFaculty_stu.cshtml Handle function
Coordinator add student
new in faculty.
20 Coordinator_Edit_Ass.cshtml Handle function
Coordinator Edit
assessment.
21 Coordinator_viewClaims_Faculty.cshtml Handle function
Coordinator view claims of
assessment in their faculty.
22 Coordinator_viewAll_faculties.cshtml Handle function
Coordinator view all of
assessment in their faculty.
23 coor_Create_assessments.cshtml Handle function
Coordinator create new
assessments.
24 Student_Create_evidence.cshtml Handle function Student
create new evidence
25 Student_viewDetail_evidence.cshtml Handle function Student
view detail evidence in their
claim.
27 Student_submit_claim.cshtml Handle function Student
submit claim.
4.2 SCREEN SHOTS OF SYSTEM IN OPERATION
Figure 1.8: Main login page (Same for all user types)
Figure 1.9: Logged in student Home page
Figure 2.0: Student submit claim page
Figure 2.1: Student Detail evidence page
Figure 2.2: Logged in EC Coordinator Home page
Figure 2.3: Coordinator View claims page
Figure 2.4: Coordinator check claims status page
Figure 2.5: Coordinator Add assessment page
Figure 2.6: Coordinator Edit assessment page
Figure 2.7: Coordinator Delete assessment page
Figure 2.8: Coordinator view all student page
Figure 2.9: Coordinator add student in faculty
Figure 3.0: Coordinator send mail to student
Figure 3.1: logged in Manager Home page
Figure 3.2: Manager view all Coordinator page
Figure 3.3: Manager view all Student page
Figure 3.4: Manager View all claims page
Figure 3.5: Manager Create new Student, Coordinator
Figure 3.6: Manager edit Faculty
Figure 3.7: Manager Delete Faculty
Figure 3.8: When Manager, Student or Coordinator logout will return to login page
5. TESTING
5.1 TEST PLAN
Scope
The document provides the test methods and procedure for the Sample University Claims Management
System.
5.1.1 User Interface
Test Code T_D_1-1
Test Item Look and Feel of the system
Test Purpose To ascertain if the system user interface i.e from
the login page and all other, is user friendly and
presentable.
Prerequisite None
Test Procedures Look at all pages
Expected Result The UI should be presentable to the specific
users.
Note:
Test Result Pass []; Partly pass []; Fail []; Not-Tested [ ]
Test Result
5.1.2 Student Form to create claims specification
Test Code T_D_1-2
Test Item Create claim specification
Test Purpose To ensure that claim specification can be
created using form and email notification sent
to moderator requesting approval.
Prerequisite None
Test Procedures 1. Log in Student
2. Enter data in form
3. View created claim specification
4. Submit (email alert to Coordinator)
Expected Result Specification should be created and stored and
alert sent to coordinator.
Note:
Test Result Pass []; Partly pass []; Fail []; Not-Tested [ ]
Test Result
5.1.3 Approval or Rejection of claim specification
Test Code T_D_1-2
Test Item Specification approval system
Test Purpose To ensure that user; coordinator, can approve or
reject submitted claim specification.
Prerequisite Claim specification
Test Procedures 1. Log in as Coordinator
2. View claim specification
3. Approve
4. Or reject and add comments; email alert
sent to Student with comments
Expected Result Approved claim is created
Comment if rejected correspond with comments
in email to Student.
Note:
Test Result Pass []; Partly pass []; Fail []; Not-Tested [ ]
Test Result
5.1.4 Coordinator Add Assessment
Test Code T_D_1-2
Test Item Specification approval system
Test Purpose To ensure that coordinator can create edit,
delete assessment specification
Prerequisite Claim specification
Test Procedures 1. Log in as Coordinator
2. Enter data in form
3. View add assessment specification
4. Submit
Expected Result Specification should be created and stored
Note:
Test Result Pass []; Partly pass []; Fail []; Not-Tested [ ]
5.1.5 Coordinator Edit, Delete Assessment
Test Code T_D_1-2
Test Item Specification approval system
Test Purpose To ensure that coordinator can edit, delete
assessment specification
Prerequisite Claim specification
Test Procedures 1. Log in as Coordinator
2. View assessment specification
3. Edit, Delete assessment specification
4. Submit
Expected Result Specification should be edit, delete in database
Note:
Test Result Pass []; Partly pass []; Fail []; Not-Tested [ ]
Test Result
5.1.6 University Manager add users and view claim
Test Code T_D_1-2
Test Item Specification approval system
Test Purpose To ensure University manager can add users
Prerequisite None
Test Procedures 1. Login as University Manager
2. Select option/s to add users
3. View claim specification
Expected Result User should be added in database
Note:
Test Result Pass []; Partly pass []; Fail []; Not-Tested [ ]
Test Result
5.1.7 Reports Product
Test Code T_D_1-2
Test Item Report Displaying
Test Purpose To ensure reports are produced and can be
viewed
Prerequisite None
Test Procedures 1. Log in as user university Manager
2. Select report to be displayed
Expected Result Reports Displayed
Note:
Test Result Pass []; Partly pass []; Fail []; Not-Tested [ ]
Test Result
5.2 TEST LOG
Below is a summary of tests conducted with 3 people.
TEST PASS PARTLY PASS FAIL NOT TESTED
5.1.1 4 5 1 0
5.1.2 9 1 0 0
5.1.3 0 7 3 0
5.1.4 9 1 0 0
5.1.5 0 9 1 0
5.1.6 6 1 2 0
5.1.7 4 1 0 0
TOTAL: 32 25 7 0
6. EVALUATION
Evaluative commentary.
6.4 ASSUPTIONS
• User accounts are created when student enrollment and when working for an employee.
Therefore we do not need a clause to register. University administrators enter these details
through their account.
• An email notification is sent from the dispatcher to the moderator by opening the mail client,
which is Microsoft's office, about clicking a button on the site. We assume that the computers
the university has used ran the mail client.
• Students can submit one or more EC claims for any item of assessment. They must always
specify their Student Id.
• All Faculties have EC Coordinator who is responsible for managing the process for their Faculty.
• Once a claim is submitted the system emails a notification to the Faculty’s EC Coordinator, who
must process it within 14 days.
• An EC Coordinator can only access claims by students in their Faculty
• Each EC Coordinator needs to be able to process the claims by students in their Faculty in order
to approve or reject them.
• University administrators are the only users who can view the report.
6.5 CHALLENGES
• The difficulty of accessing the fast Internet for research can take hours to find the right materials
• One of our team members got sick so it slowed down the smooth development of our system in
that its role was shared among the rest of the group.
6.2 SYSTEM WEAKENESSES
• It is not possible to include the moderator's comments in the same panel that moderators put
into their comments
• It is not possible to view all reports of university administrators
• The college administrator login path shows the session error
• Form validation is not the maximum
• Some errors only appear after uploading which does not exist on Wamp localhost
6.6 SYSTEM STRENGTHS
• The role-based login system is very secure with a view of the user type.
• This site obeys the principles of human computer interface
• The system is specifically designed for students to submit one or more EC claims for any item of
assessment.
6.3 LEARNING OUTCOMES
Through the use of agile methods, we have learned a lot from each other in that each of us has different
skills that one person does not perform. Working with agile development has taught us how to overlap
aspects of not blaming unlike previous years; then, developers will point to a team member as a cause.
Develop the system on time or not develop the system. Enhanced system construction in sprint also
helps understand the importance of proper planning and time management to ensure that the end
product can be reached in time. It also gives us the opportunity to feel and understand the impact of the
work and the end product of losing a team member and, although difficult, adjustable. Moreover, we
have learned that working in a group brings the dynamics of different people; Attitude, strengths,
weaknesses. And use all of this to achieve a goal that is a product that works for the customer.
7. Reference
tutorialspoint.com from
http://www.tutorialspoint.com/uml/uml_use_case_diagram.htm on 09/03/17.
