The document provides a summary of a project documentation for a university coursework lifecycle management system developed using agile scrum methodology. It includes sections on agile scrum documentation covering roles, tools, meetings, product and sprint backlogs, and a burn down chart. It also includes design documentation with use case diagrams, database design, and website design. Implementation details such as files created and screenshots are presented. Finally, it outlines the testing plan and approach for the system.

1. ENTERPRISE WEB SOFTWARE
DEVELOPMENT
COMP1640
PROJECT DOCUMENTATION
PROJECT NAME: SAMPLE UNIVERSITY
COURSEWORK LIFECYCLE
Due: 20 Nov 2013
GROUP 5
Edwin Kamangala
Njilika Chewe
Owen Muzi

2. 1
NO. CONTENT PAGE NO.
1.0 INTRODUCTION………………………………… 02
2.0 AGILE SCUM DOCUMENTATION…………....
2.1 ROLES……………………………………….
2.2 TOOLS……………………………………….
2.3 MEETINGS…………………………………..
2.4 PRODUCT BACKLOG……………………..
2.5 SPRINT BACKLOGS……………………….
2.6 PROJECT BURN DOWN CHART………...
03
03
03
03
04
05
05
3.0 DESIGN DOCUMENTATION…………………..
3.1 USE CASE DIAGRAMS……………………
3.2 DATABASE DESIGN……………………….
3.3 WEBSITE DESIGN…………………………
06
06
06
08
4.0 IMPLEMENTATION……………………………..
4.1 LIST OF FILES CREATED AND ROLES…
4.2 SCREEN SHOTS OF SYSTEM IN
OPERATION……………………………………...
11
11
13
5.0 TESTING………………………………………….
5.1 TEST PLAN………………………………….
5.2 TEST LOG……………………………………
19
19
22
6.0 EVALUATION…………………………………….
6.1ASSUPTIONS………………………………...
6.2CHALLENGES……………………………….
6.2 SYSTEM WEAKENESSES…………………
6.3 SYSTEM STRENGTHS…………………….
6.3 LEARNING OUTCOMES……………
22
23
23
23
23
24
7.0 REFERENCES………………………………….. 25

3. 2
1.0 INTRODUCTION
This group coursework is for the development of a secure web-based system for
managing the lifecycle of a coursework in a large university. The created system
must be able to show the processes from the creation of the coursework to the point
where students view their marks and reports viewed. It must therefore be noted that
the scope of this project is the ‘Coursework lifecycle’ and this project implements the
processes of that required system using agile scrum working practices. The project
and client is named Sample University.
Below is the requirement specification as obtained; A system that accomplishes the
following:
 Creation of coursework specification by specific user; Course Coordinator
 Approval of coursework specification by specific user; Course Moderator
 Downloading of coursework by students
 Uploading/ submitting of coursework by students
 After due date; marking of and commenting on submitted coursework by
Course Coordinator
 Commenting and approval of moderation by Course moderator
 Viewing of marks and comments by students
 At every step an email notification must be sent to the relevant so action can
be taken where required
 Viewing reports to show current system status, statistics and exceptional
reports
Below is a diagram of the coursework lifecycle:
Figure 1.1

4. 3
2.0 AGILE SCRUM DOCUMENTATION
2.1 ROLES
The roles required for the project and rotated amongst the group members are that
of:
 Database designer
 Programmer
 Web designer
 Tester
 Product Owner - Lecturer
2.2 TOOLS
The site functionalities are to be developed majorly using PHP and HTML. The
backend database will be implemented using MYSQL and run on WAMP server.
Below is a list of tools and technologies used to develop and document the system:
 Notepad++
 Wamp Server 1.7.4 (with PHP and MYSQL)
 Macromedia Dreamweaver
 Numbers ’09 version 2.3(554)
 Microsoft office word 2010
2.3 MEETINGS
2.3.1 Sprint planning
Our first meeting was held on 05/10/13 at 11:00hrs
The Agenda was to:
 Discuss individual capabilities; strengths, weaknesses which will enable us
divide tasks
 Consider and record technologies that we will use
 Define Product backlog
o Requirements which we said we would get after analyzing the
coursework
o Properly state the features of the required product
o Detailed requirements ordered by priority, tasks, person assigned to
each, hours to be spent on task/s
 Set a release date
 Define content of finished product
 Discuss how many sprints we will have and durations thereof
 Define Sprint Backlog (Subset of product backlog)
o Requirements for each as inputs, then we design, code and test, then
with a tested prototype as the output
o This should show deliverables, tasks, hours spent on each, status of
tasks; i.e. started, in process, completed
 Create the project burn down chart.
2.3.2 Pre-Kick off meeting
Held on 07/10/13 at 20:05hrs
To ensure that all goals and tasks are understood then work began

5. 4
2.3.3 Sprint Review
Done after each sprint with the Interim deliverables as stated in the coursework. i.e.
Database design, Site Design and Test plan. In attendance also should be the
lecturer who in this case is the product owner.
2.3.4 Sprint Retrospective
Review of work without the presence of the product owner (lecturer), were we state
whether we should start, stop or continue with project.
2.3.5 Daily Scrum
Were done weekly and sometimes biweekly rather than daily.
2.4 PRODUCT BACKLOG
PRIORITY ITEM
NO.
DESCRIPTION EST
HOURS
BY
VERY
HIGH
01 Create Database design 12 NC
02 Create website wireframes and sitemap 12 OM
03 Create Test plan based on project requirements 12 EK
HIGH
04
Build webpages based on wireframes and sitemap
without any functionality behind forms. 5 EK
05 Build database based on database design; all tables 6 NC
06 Create functional Login system 4 NC
07 Populate database with sample data 4 OM
08
Update Coordinator page with functionality for
coursework creation forms which connects to database
and writes coursework specifications 2 OM
09
Update Coordinator page with functionality to send
email notification to moderator for approval 2 EK
10
Create functionality of uploading a file from local
machine to server folder 3 EK
11
Update coordinator page with functionality of being
able to view student coursework answers from the
database 2 OM
12
Create functionality of Coordinator being able to insert
student marks into database. 2
OM,
NC
13
Add functionality to Moderator page to insert
comments for students in Moderator table 1 EK
14
Create functional Student page for upload of
coursework answer; including actual file into database 3 OM
15 Add functionality for student to download coursework 2
NC,
EK
16
Create functionality for students to view only their
results 2 NC
17
Add Functionality for super user University
administrator to add staff and student details 5
OM,N
C
MEDIUM

6. 5
18 Create reports with SQL queries 7
NC,
EK,
OM
19 Add data validation to all forms 4
EK,
OM
20
Compile all available documentation for project
concisely 4 EK
21 Run system and fix any errors/bugs detected 3
NC,E
K,OM
22 Implement test plan 4
NC,E
K,OM
23 Final documentation 3
NC,E
K,OM
KEY
OM – Owen Muzi. NK – Njilika Chewe. EK – Edwin Kamangala
Figure 1.2
2.5 SPRINT BACKLOGS
We had a total of 4 sprints during the project
2.6 PROJECT BURN DOWN CHART
The chart below shows the burn down chart of the project divided into 220 points,
which represent the entire project tasks. As above we had 4 sprints; 3 running for 12
days each and the last one for 8 days giving a total of 44 days for the project to run.
The release date was set for 19 November 2013.
Figure 1.3

7. 6
3.0 DESIGN DOCUMENTATION
3.1 USE CASE DIAGRAMS
For our design, we will use ‘Use Case’ diagrams. It should be noted that this design
only describes the design for the university coursework management system and not
anything outside this scope. These internal and external agents are known as actors.
So use case diagrams are consists of actors, use cases and their relationships. The
diagram is used to model the system/subsystem of an application.
tutorialspoint.com
Figure 1.4 UML Diagram
3.2 DATABASE DESIGN
3.2.1 Entity Relationship Diagram
Below is the Coursework Lifecycle ERD. Please note that looking at the University as
a whole would necessitate other entities, However for the purpose of the scope of
this system; Coursework Lifecycle, only the below are identified and relationships
thereof. This therefore makes the lifecycle system only a subset of a much bigger
university system. ER-modeling is a data modeling technique used in software
engineering to produce a conceptual data model of an information system. Diagrams
created using this ER-modeling technique are called Entity-Relationship Diagrams,
or ER diagrams or ERDs. So you can say that Entity Relationship Diagrams illustrate
the logical structure of databases. And therefore the below.
datanamic.com

8. 7
Figure 1.5 Entity Relationship Diagram
3.2.2 Relational Schema
NOTE: the Primary Keys are underlined and Foreign keys are in red
Staff (staffid, staffname, email, position)
Moderator (staffid, password, courseid )
Coordinator (staffid, password, courseid )
UniversityAdmin (staffid, password)
Course (coursid, coursename, year, level)
CourseStudent (coursed, studentid)
Student (studentid, studename, email, password)
Coursework (coursed, couseworkname, releasedate, duedate, yearlevel)
CoursworkUpload (studentid, timeupload, uploadedcoursework)
Courseworkweight (studentid, coursed, mark, coordinatorcomment,
moderatorcomment)

9. 8
3.3 WEBSITE DESIGN
3.3.1 Website Wireframes
Below is a design of the homepage, log in pages and other pages (the other pages
follow a general design)
Figure 1.7 Homepage Wireframe

10. 9
Figure 1.8 Login pages wireframe
Figure 1.9 General pages wireframe

11. 10
3.3.2 Sitemap
Figure 2.0 Website sitemap

12. 11
4.0 IMPLEMENTATION
4.1 LIST OF FILES CREATED AND ROLES
N
o.
Page Name Role
1 Index.php The site home page/ landing page that visitors see first
2 Header.php Php file containing the banner, handling sessions and links to other parts
of the site with the Student
3 Function.php Php file containing the database connector, and functions for students
4 Login.php Handles the login of a student displaying text field for username and
password and a login button
5 Logout.php Handles the logging out of a student
6 mainlogin.php page that allows a visitor to select which user type to log in
7 coordinator.php page displayed after coordinator logs in
8 coordinatorheader.
php
Php file containing the banner, handling sessions and links to other parts
of the site for coordinator
9 coordinatorfunction Php file containing the database connector, and functions for
coordinator user type
1
0
coordinatorlogin.ph
p
Handles the login of a coordinator user type user displaying text field for
username and password and a login button
1
1
logout2.php Handles the logout of the coordinator
1
2
courses.php courses page
1
3
coursessubmitted.p
hp
report page for university administrator listing the number of
coursework’s uploaded
1
4
cwupload2.php Page allowing coordinator to enter and save coursework specification/
details
1
5
fileupload.php handles the upload of the actual coursework file by the moderator
thereby making available to students
1
6
markcoursework.ph
p
Page for coordinator to mark coursework
1
7
contact.php contact us page
1
8
about.php about us page
1
9
members.php page displayed after member logs in
2
0
moderator.php page displayed after moderator logs in
2
1
moderatorfunction.
php
Php file containing the database connector, and functions for moderator
user type
2
2
moderatorheader.p
hp
Php file containing the banner, handling sessions and links to other parts
of the site for moderator
2
3
moderatorlogin.php Handles the login of a moderator user type user displaying text field for
username and password and a login button
2
4
moderatorlogout.ph
p
Handles the logout of the moderator
2
5
profile.php handles profiles

13. 12
2
6
results.php Displays the results of a student
2
7
staffaccount.php displays form and writes a new staff details to the staff table
2
8
studentaccount displays form and writes a new staff details to the student table
2
9
studentsupload.php handles the upload of coursework by students
3
0
submittedcoursewo
rk.php
university administrator view of submitted course works
3
1
universityadmin.php university administrator user landing page after successful login
3
2
universityadminfunc
tion.php
Php file containing the database connector, and functions for university
administrator
3
3
universsityadminhe
ader.php
Php file containing the banner, handling sessions and links to other parts
of the site with the university administrator
3
4
universityadminlogi
n.php
Handles the login of a university administrator user type user displaying
text field for username and password and a login button
3
5
universityadminlogo
ut.php
Handles the logout of the university administrator
3
6
updatemarks.php Page for coordinator to update student marks
3
7
uploadfile.php handles serverside logic of uploading of a file
3
8
adminviewsubmitte
dcoursewor.php
handles university administrators viewing of submited courseworks
3
9
approvecw.php For Moderator to upload approved coursework
Figure 2.1 List of website files

14. 13
4.2 SCREEN SHOTS OF SYSTEM IN OPERATION
Figure 2.2 Homepage or website landing page
Figure 2.3 Main login page where users select their user type

15. 14
Figure 2.4 Enter Password page (same for all user types)
Figure 2.5 Page shown when correct password is entered
Figure 2.6 Logged in student Home page
Figure 2.7 Students results page

16. 15
Figure 2.8 Student logged out page
Figure 2.9 Coordinator home page
Figure 3.0 Coordinator create coursework specification page
Figure 3.1 Coordinator mark coursework page

17. 16
Figure 3.2 Coordinator Logged out page
Figure 3.3 Moderator Home page
Figure 3.4 Moderator Approve/upload coursework page
Figure 3.5 Moderator Logged out page

18. 17
Figure 3.6 University Administrator Home page
Figure 3.7 University administrator ‘ Number of courseworks submitted ‘ reports page
Figure 3.8 University administrator, Create student page

19. 18
Figure 3.9 University administrator, Create staff member page

20. 19
5.0 TESTING
5.1 TEST PLAN
Scope
The document provides the test methods and procedure for the Sample University
Coursework Management System.
5.1.1 User Interface
Test Code T_D_1-1
Test Item Look and Feel of the UI for the system
Test Purpose
To ascertain if the system’s user interface i.e from the login page and all
other pages, 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 [ ]
5.1.2 Coordinator Form to create Coursework specification
Test Code T_D_1-2
Test Item Creating coursework specification
Test Purpose
To ensure that Coursework specification can be created using form and
email notification sent to moderator requesting approval
Prerequisite None
Test Procedures 1. Log in as Coordinator
2. Enter data in form
3. View created coursework specification
4. Submit (email alert to moderator)
Expected Result Specification should be created and stored and alert sent to moderator

21. 20
Note：
Test Result Pass []; Partly pass [ ]; Fail [ ]; Not-tested [ ]
5.1.3 Approval or Rejection of Coursework specification
Test Code T_D_1-3
Test Item Specification approval system
Test Purpose
To ensure that user; moderator, can approve or reject submitted
coursework specification
Prerequisite Coursework Specification
Test Procedures 5. Log in as Moderator
6. View coursework specification
7. Approve
8. Or reject and add comments; email alert sent to coordinator with
comments
Expected Result - Approved coursework is created
- Comments if rejected correspond with comments in email to
coordinator
Note：
Test Result Pass []; Partly pass [ ]; Fail []; Not-tested [ ]
5.1.4 Coursework release
Test Code T_D_1-4
Test Item Date condition for coursework release
Test Purpose
To ascertain if coursework is released(made visible) to students when
release time and date has reached
Prerequisite Coursework
Test Procedures 9. Release time is reached
10. Coursework is made visible to students
Expected Result Coursework is visible to students for download
Note:
Test Result Pass [ ]; Partly pass [ ]; Fail [ ]; Not-tested []
5.1.5 Student coursework upload
Test Code T_D_1-5
Test Item Coursework upload system/ form
Test Purpose To see whether coursework can be uploaded
Prerequisite Completed coursework file
Test Procedures 1. Log in as student
2. Select file from directory and upload
Expected Result Coursework is uploaded and confirmation is given to student
Note:
Test Result Pass [ ]; Partly pass [ ]; Fail [ ]; Not-tested [ ]

22. 21
5.1.6 University Admin add users
Test Code T_D_1-6
Test Item University admin to add users
Test Purpose To ensure University admin can add users
Prerequisite None
Test Procedures 1. Login as University admin
2. Select option/s to add users
Expected Result User should be added in database
Note:
Test Result Pass [ ]; Partly pass [ ]; Fail [ ]; Not-tested [ ]
5.1.7 Latest Coursework marked
Test Code T_D_1-7
Test Item Marking latest submitted coursework
Test Purpose
To check whether latest coursework submitted by student is the one
marked
Prerequisite Student courseworks
Test Procedures 1. Submit various courseworks at different times before deadline
Expected Result Latest coursework is the one made available to coordinator for marking
Note:
Test Result Pass [ ]; Partly pass [ ]; Fail [ ]; Not-tested [ ]
5.1.8 Coordinator coursework marking
Test Code T_D_1-8
Test Item Courwork marking and commenting
Test Purpose To allow coordinator to view and mark coursework
Prerequisite Student courseworks on system
Test Procedures 1. Coordinator logs in
2. Coordinator views ‘Marking form’ and can can download/ view
individual courseworks
Expected Result Coordinator should be give a mark and comment then coursework made
visible to moderator
Note:
Test Result Pass [ ]; Partly pass [ ]; Fail []; Not-tested [ ]
5.1.9 Moderator Approval and Commenting
Test Code T_D_1-9
Test Item Moderator approval and commenting
Test Purpose For moderator to approve mark by coordinator and comment
Prerequisite Marked coursework

23. 22
Test Procedures 1. Log in as moderator
2. View marks and comments by coordinator
3. Approve or disapprove and add comments
Expected Result Marking is completed and results are made available too specific student
Note:
Test Result Pass [ ]; Partly pass [ ]; Fail []; Not-tested [ ]
5.1.10 Reports production
Test Code T_D_1-10
Test Item Reports displaying
Test Purpose To ensure reports are produced and can be viewed
Prerequisite None
Test Procedures 1. Log in as user university admin
2. Select report to be displayed
Expected Result Reports displayed
Note:
Test Result Pass [ ]; Partly pass [ ]; Fail [ ]; Not-tested [ ]
5.2 TEST LOG
Below is a summary of tests conducted with 10 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 8 2 0 0
5.1.5 10 0 0 0
5.1.6 9 1 0 0
5.1.7 0 1 1 8
5.1.8 0 1 7 2
5.1.9 4 4 2 0
5.1.10 0 9 1 0
TOTAL 44 31 15 10

24. 23
6.0 EVALUATION
Evaluative commentary.
6.4ASSUPTIONS
 User accounts are created when enrolling for students and upon employment
for staff. We therefore do not need a provision for sign up. The university
admin enters these details through his/her account.
 Email notifications are sent from the coordinator to moderator by opening the
mail client, i.e. Microsoft office outlook on the click of a button on the site. We
assume that the university computers used have running mail clients
 When students are uploading, they must always specify their student Id
 Extenuating Circumstance are ignored
 No changes are needed once the coursework is released to students
 All courses are fully assessed by coursework (i.e. no examinations)
 The course coordinator only writes the coursework specifications and then
attaches the coursework file to the notification email which goes to the
moderator. The moderator then uploads the coursework file upon approval
which makes the file available to students.
 If a moderator does not approve with a coursework, he responds to the
coordinator in an email with comments.
 University administrator is the only user who can view reports.
6.5CHALLENGES
 One of our team members was discontinued by Greenwich hence making a
retard on the smooth development of our system in that his roles to be shared
among the remaining team members
 Difficulties in accessing fast internet for research for it took hours to find the
right materials to be used for the coursework
 The accessing or release of the coursework was not properly timed. Students
are used to access the coursework a week or two after opening to enable
them prepare adequately.
6.2 SYSTEM WEAKENESSES
 Unable to insert the moderator comments in the same table the coordinator
enters comment
 The system is an able to upload coursework due limited file write privileges on
the Greenwich wamp server and hence inability to take screen shots of file
upload and coursework download pages which have been successfully
implemented
 Unable to implement download of the coursework to be marked by the
coordinator in the database
 Unable to implement all report viewing by university administrator
 University admin login path displays a session error
 Validation of forms was not don’t to the maximum
 Some errors appeared only after upload that do not exist on Wamp localhost
6.6 SYSTEM STRENGTHS
 Very secure role based login system with views by user type.

25. 24
 The site conforms the principles the human computer interface
 The system is built specifically for the course lifecycle as required by in this
coursework’s requirements
6.3 LEARNING OUTCOMES
Through the use of agile methodology we learnt a lot from each other in that each
one of us had different skills that another would not perform. Working with agile
development taught us how to overlap the no blame aspects unlike in that past years
where, developers would single point a team member as to be cause of not
developing the system on time or failure to develop the system. Incremental building
of the system in sprints also helped understand the importance of proper planning
and time management in order to ascertain whether finishing the product in time
would be attainable. It also gave the opportunity for us to feel and understand the
effects on work and the end product itself of losing a team member and though
difficult, adjust. Further we have learned that working in a team bring the dynamics of
different people together; attitudes, strengths, weaknesses. And using all these to
achieve a goal which is a working product for the client.

26. 25
7.0 REFERENCES
tutorialspoint.com from
http://www.tutorialspoint.com/uml/uml_use_case_diagram.htm on 20/11/13
datanamic.com from
http://www.datanamic.com/support/lt-dez006-what-is-an-erd.html on 20/11/13
Robin Nixon (2012) Leaning PHP, MySQL, Javascript and CSS, Second Edition,
O'Reilly Media