FYP TITLE

SESSION (2013-2015)

Submitted By

Name ID
Student Name (ID)
Student Name (ID)
Student Name (ID)
Student Name (ID)

Supervised By

Mr. /Dr. Name

SCHOOL OF PROFESSIONAL ADVANCEMENT

UNIVERSITY OF MANAGEMENT & TECHNOLOGY, LAHORE
DEDICATION

DEDICATED TO MY RESPECTED PARENTS AND FAMILY WHOSE UTMOST LOVE, CARE AND

STRUGGLE AGAINST ALL ODDS BROUGHT ME TO THIS HEIGHT OF KNOWLEDGE AND

ENCOURAGED ME TO COMPLETE THIS DEGREE AND WERE MAJOR DRIVING FORCE

BEHIND MY ALL EFFORTS WITH THE BLESSINGS OF ALMIGHTY ALLAH

I
ACKNOWLEDGEMENT

I am thankful to ALMIGHTY ALLAH who gave me courage and passion and prayers of my
parents and teachers to achieve the goal that was necessary for the degree. Although it was not an
easy task, with the useful direction, kind supervision and co-operation of Dr. / Mr. / Ms. Name,
it became easy for me to complete the research work. I am really grateful to my Project
Supervisor because of his profound interest and encouragement throughout the project work.

I would like to acknowledge Prof. Dr., Chairman, School of Professional Advancement, UMT
Lahore, for encouraging and providing me all the facilities throughout the project.

Last but not least, I extend my sincere appreciativeness and thankfulness to my Family for their
incredible encouragement. Their love and support means a lot to me.

II
UNDERTAKING

FYP TITLE
SESSION (2013-2015)
This project is submitted to the School of Professional Advancement, University of Management
& Technology Lahore, for the partial fulfillment of the requirement for Master Degree in
Computer Science.

Approved on: _________________

Submitted By:
Name: (ID)
Name: (ID)
Name: (ID)
Name: (ID)

Dr. / Mr. / Ms. Name Dr. / Mr. / Ms. Name

Lecturer., S. P. A, Lecturer. S.P.A

UMT, Lahore UMT, Lahore
Program Head Project Supervisor

SCHOOL OF PROFESSIONAL ADVANCEMENT

UNIVERSITY OF MANAGEMENT & TECHNOLOGY, LAHORE

III
ABSTRACT

Computing applications and the users of these application are growing at very high rate. Cloud
computing, bioinformatics, video surveillance systems and grid computing have shown up to
meet this requirements….

IV
REVISION CHART (OPTIONAL)

This chart contains a history of this document’s revisions. The entries below are provided solely for illustration
purposes. Those entries should be deleted until the revision/s they refer to have actually been created.
The document itself should be stored in revision control, and a brief description of each version should be entered in
the Revision Control System. A brief description can be repeated in this section. Revisions need not be described
elsewhere in the document, unless they explain the document.

Version Primary Author(s) Description of Version Date Completed

Draft TBD Initial draft created for distribution and review (To be decided)
comments TBD
Preliminary TBD Second draft incorporating initial review TBD
comments, distributed for final review
Final TBD First complete draft, which is placed under TBD
change control
Revision 1 TBD Revised draft, revised according to the change TBD
control process and maintained under change
control
Revision 2 TBD Revised draft, revised according to the change TBD
control process and maintained under change
control
Etc. TBD TBD TBD

V
PREFACE THE PREFACE CONTAINS AN INTRODUCTION TO THE
DOCUMENT. IT IS OPTIONAL AND CAN BE DELETED IF DESIRED.

VI
CONTENTS

New paragraphs formatted as Heading 1, Heading 2, and Heading 3 will be added to the table automatically. To
update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the
table to be easy to maintain, do not change it manually.
DEDICATION...........................................................................................................................................I
ACKNOWLEDGEMENT.......................................................................................................................II
UNDERTAKING....................................................................................................................................III
ABSTRACT.............................................................................................................................................IV
1. INTRODUCTION.............................................................................................................................1
1.1 PROJECT OVERVIEW......................................................................................................................................1
1.1.1 Problem Statement................................................................................................................................1
1.1.2 Back Ground.........................................................................................................................................1
1.1.3 Proposed Solution.................................................................................................................................1
1.1.4 Customer...............................................................................................................................................1
1.1.5 Goals and Objectives............................................................................................................................2
1.1.6 Assumptions.........................................................................................................................................2
1.1.7 Dependencies/ External Systems..........................................................................................................2
1.1.8 Definitions and Acronyms....................................................................................................................2
1.1.9 Market Survey/ Domain Analysis........................................................................................................2
2. SYSTEM REQUIREMENT SPECIFICATION.............................................................................4
2.1 FUNCTIONAL REQUIREMENTS........................................................................................................................4
2.2 NON-FUNCTIONAL REQUIREMENT.................................................................................................................5
2.3 USE CASE MODELS........................................................................................................................................5
2.3.1 List of Actors........................................................................................................................................6
2.3.2 List of Use Cases..................................................................................................................................6
2.3.3 Use Case Diagram................................................................................................................................6
2.3.4 Usage Scenario.....................................................................................................................................7
3. SYSTEM DESIGN............................................................................................................................9
3.1 SYSTEM ARCHITECTURE................................................................................................................................9
3.2 CLASS DIAGRAM............................................................................................................................................9
3.3 SEQUENCE DIAGRAM (AGAINST EACH USE CASE).........................................................................................9
3.4 ACTIVITY DIAGRAM (AGAINST EACH USE CASE)........................................................................................10
3.5 SYSTEM COLLABORATION DIAGRAM (OPTIONAL)......................................................................................11
3.6 ENTITY RELATIONSHIP DIAGRAM................................................................................................................11
3.7 DATA FLOW DIAGRAM................................................................................................................................11
3.7.1 Level 0................................................................................................................................................11
3.7.2 Level 1................................................................................................................................................11
3.7.3 Level 2................................................................................................................................................11
3.8 DEPLOYMENT DIAGRAM (OPTIONAL)..........................................................................................................11
3.9 COMPONENT DIAGRAM (OPTIONAL)...........................................................................................................11
3.10 STATE TRANSITION DIAGRAM (OPTIONAL).................................................................................................11
4. IMPLEMENTATION.....................................................................................................................13
4.1 TOOLS........................................................................................................................................................13
4.1.1 Web Application.................................................................................................................................13
 4.1.2 Database.............................................................................................................................................13
4.1.3 Android Application...........................................................................................................................13
4.1.4 Documentation...................................................................................................................................13
4.2 TECHNIQUES............................................................................................................................................14
4.3 LANGUAGES............................................................................................................................................14
4.4 TRACEABILITY MATRIX...............................................................................................................................15
4.5 SNAPSHOTS OF FROND END.........................................................................................................................15
5. TESTING.........................................................................................................................................17
5.1 TEST CASES.................................................................................................................................................17
5.2 TID TEMPLATE.............................................................................................................................................17
5.3 DECISION TABLE..........................................................................................................................................17
5.4 BLACK BOX TESTING..................................................................................................................................17
5.5 WHITE BOX TESTING...................................................................................................................................17
6. RESULTS/OUTPUT/STATISTICS...............................................................................................19
6.1 TRACEABILITY MATRIX (TID VS UID).......................................................................................................19
6.2 % COMPLETION...........................................................................................................................................19
6.3 % ACCURACY..............................................................................................................................................19
6.4 % CORRECTNESS.........................................................................................................................................19
7. CONCLUSION AND SUMMARY.................................................................................................21
7.1 CONCLUSION...........................................................................................................................................21
7.2 SUMMARY................................................................................................................................................21
7.3 LESSON LEARNED..................................................................................................................................21
8. FUTURE WORK.............................................................................................................................23

9. REFERENCES................................................................................................................................25

10. APPENDIX..................................................................................................................................27
10.1 GLOSSARY OF TERMS...................................................................................................................................27
10.2 ENVIRONMENTAL SETUP (OPTIONAL)..........................................................................................................27
10.3 EXPERIMENTAL SETUP (OPTIONAL).............................................................................................................27
10.4 ASSUMPTIONS (OPTIONAL)..........................................................................................................................27
10.5 PRE-REQUISITES (OPTIONAL).......................................................................................................................27
10.6 DATA SETS/TEST DATA................................................................................................................................27
10.7 CODE OF BACK END.....................................................................................................................................27
10.8 PROJECT MANAGEMENT DOCUMENTS.........................................................................................................27
10.8.1 Team Structure...................................................................................................................................27
10.8.2 Roles and Responsibilities..................................................................................................................27
10.8.3 WBS (Work Breakdown Structure)....................................................................................................27
10.8.4 PERT Diagram (Based on 10 Months of Work)................................................................................27
10.8.5 Critical Path........................................................................................................................................27
10.8.6 Scope Statement.................................................................................................................................27
10.8.7 Project Charter....................................................................................................................................27
10.8.8 Meeting Summary..............................................................................................................................27
LIST OF FIGURES

New figures that are given captions using the Caption paragraph style will be added to the table automatically. To
update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the
table to be easy to maintain, do not change it manually.
This section can be deleted if the document contains no figures or if otherwise desired.
Figure 1: System Level Use Case Diagram......................................................................................................6
Figure 2: UC Scenario – I: User View..............................................................................................................7
Figure 3: System Architecture..........................................................................................................................9
Figure 4: Sequence Diagram..........................................................................................................................10
LIST OF TABLES

New tables that are given captions using the Caption paragraph style will be added to the table automatically. To
update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the
table to be easy to maintain, do not change it manually.
This section can be deleted if the document contains no figures or if otherwise desired.
Table 1: Categories of Requirement.................................................................................................................4
Table 2: List of System Function Requirements..............................................................................................5
Table 3: List of Functional requirements attributes..........................................................................................5
Table 4: UC_01 View Details...........................................................................................................................7
 1
INTRODUCTION
School of Professional Advancement (SPA) <Project Name>

1. INTRODUCTION

This section should describe the project and the software product being to be built. No text is necessary
between the heading above and the heading below unless otherwise desired.
(Just keep in your mind before start. Text size must be 10 and font name is Times New Roman. Chapter
size font 18 and heading font size is 16 and sub heading font size is 14. )

1.1 Project Overview

Give a short summary of the project objective and the system to be analyzed
Functional specifications are a description of needs or desires for a product. Identify and document what is
really needed, in a form that clearly communicates to the client and to development team members. Define
the requirements unambiguously, so that the risks are identified and there are no surprises when the product
is finally delivered.
Following are the sample artifacts for this section:
 Problems or Overview Statement
 Background
 Customer
 Scope

1.1.1 Problem Statement

The purpose of this project is to …The problem statement should be brief, comprising of no more than 50
words [1].
(a) The ideal, describes a desired goal or ideal situation; explains how things should be (to be)
(b) The reality, describes a condition that prevents the goal, state, or value in part a from being achieved or
realized at this time; explains how the current situation falls short of the goal or ideal. (as is)
(c) The consequences, impacts on the business if the problem is not fixed.
(d) Describe potential solution identifies the way you propose to improve the current situation and move it
closer to the goal or ideal.
Question 1: What is the problem that needs to be solved?
Question 2: Why is it a problem? (highlight the pain)
Question 3: Where is the problem observed? (location, products)
Question 4: Who is impacted? (customers, businesses, departments)

1.1.2 Back Ground

1.1.2.1 Existing Systems
1.1.2.2 Drawbacks
1.1.3 Proposed Solution
1.1.3.1 Merits of Proposed Solution
1.1.4 Customer
A brief description of the client. The organization, its products/services etc.
e.g.

Group Members: Name (ID), Name (ID) 1|Page

Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

Company X offers solutions for companies who want to establish a portal on the Trading Net and those
who want to host portals for others. Company X was founded in 1992 and went public in 1998.
1.1.4.1 Affected Groups
Those impacted by the deployment of the system. This can be a simple list as well as a bulleted one with
short explanations.
e.g.
 Sales staff
 Cashiers
This may include users as well as support groups

1.1.5 Goals and Objectives

This brief section should focus on what the client wants to achieve. It must enumerate the objectives of the
top management and what it hopes to accomplish from the proposed system [2].

1.1.6 Assumptions
Things we assume will be true.
e.g.:

 We will receive all necessary technical support from the engineers at cMeRun, Select and Mellon
Bank to help design the interfaces between their systems and enGyro.
 All database maintenance will be handled by the client.
 There will be no real-time interfacing with any accounting systems.

1.1.7 Dependencies/ External Systems

Systems and/ or products, this project depends upon for its completion.
e.g.
 Cyber Cash

1.1.8 Definitions and Acronyms

Provide definitions or references to all the definitions of the special terms and acronyms used within this
document.

1.1.9 Market Survey/ Domain Analysis

Group Members: Name (ID), Name (ID) 2|Page

Name (ID), Name (ID)
 2
SYSTEM REQUIREMENT SPECIFICATION
School of Professional Advancement (SPA) <Project Name>

2. SYSTEM REQUIREMENT SPECIFICATION

2.1 Functional Requirements

This section is can be skipped, if Requirement Specifications document has been developed for the project.
Otherwise this section is mandatory.
This section may contain
 end user, operator, support, or integration functions,
 performance requirements,
 design constraints,
 programming language, and
 Interface requirements.
System functions are descriptions of what a system is supposed to do. They should be identified and listed
in logical cohesive groups, with their category (priority) assigned. These system functions will be
identified as a result of the requirement gathering process conducted with the client. However, in some
cases, prior to the development of the Functional Specifications the requirements may already have been
listed in a document: if this is so then a reference to the document may suffice.
To verify that some X is indeed a system function; it should make sense in the following sentence:
The system should do <X>
The table below gives an example of how system functions can be listed:
 The Functions column gives a brief one-line description of the required functionality.
 The Category column refers to the status of the functionality for the proposed system. The
options for the Category are defined below.
 The Attribute column defines the system characteristics. The Details and Constraints column
specifies the conditions within which the attribute is applicable. Section 1.12 defines the default
Attributes and the related Constraints. In case, the default conditions are to be over-ridden then the
conditions can be defined in this table.

Function Category Meaning

Evident Should perform, and user should be cognizant that it is performed.
Hidden Should perform, but not be visible to users. This is true of many underlying
technical services, such as save information in a persistent storage mechanism.
Hidden functions are often missed during the requirements gathering process.
Frill Optional; adding it does not significantly affect cost or other functions.

Table 1: Categories of Requirement

Fun id Functions Category Attribute Details & Boundary

# Constraints
F - 001 Record the underway Evident System Response Price listing within 3 seconds
sale – the items

Group members: Name (ID) 4|Page

Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

purchased time Availability agreement in less

than 10 sec
F - 002 Reduce inventory Hidden Concurrent user
quantities when a sale load
is committed
… … …

Table 2: List of System Function Requirements

System Attributes/ Nonfunctional Requirements

System attributes are nonfunctional system qualities – such as ease of use. System attributes are
characteristics of the system; they are not functions.
System attributes have a possible set of Attribute Details, which tend to be discrete, fuzzy, symbolic values
of the attribute, such as:
Response time = psychologically appropriate
Interface metaphor = graphical, browser-based
Some system attributes may also have Attribute Boundary Constraints, which are mandatory boundary
conditions, usually on a numeric range of values of an attribute, such as:
Response time = five seconds maximum
In this section the Category column indicates whether or not the attribute is critical for the operation of the
system.
The Category can take two options:
 Optional
 Mandatory

Attribute Details and Boundary Category

Constraints
Response time (Boundary constraint) When Optional
recording a sold item, the
description and price will appear
within 5 seconds
Concurrent User Load A minimum of 10 users connected Mandatory
simultaneously

Table 3: List of Functional requirements attributes

2.2 Non-Functional Requirement

2.3 Use Case Models

Describe the following items:
 Actors & use cases
 Use case diagrams
 High level, essential use cases
No text is necessary between the heading above and the heading below unless otherwise desired.

Group members: Name (ID) 5|Page

Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

2.3.1 List of Actors

Define the system boundary and list all actors with the use cases.
For example:
Cashier; this person performs all the financial activities
Account Manager; this person supervises all financial activities

2.3.2 List of Use Cases

List all the use cases, with a brief description (should not exceed two lines):
Buy Item; captures a sale and its payment
Log In; allow user to provide account information and access the restricted services

2.3.2 Use Case Diagram

Create the system level use case diagram

Create Users

<<extends>>
Acc Manager

Create Manager Account

Buy Items
Cashier Customer

<<uses>>
<<uses>>
<<uses>>

Pay by Cash

Credit Authorization
Service Pay by Credit Pay by Check
Check Authorization
Service

Figure 1: System Level Use Case Diagram

After system Level Use Case Diagram, students should show the individual use cases for every functional
requirement and also draw the table against each use case. The sample table along with a sample use case is
given below:

Group members: Name (ID) 6|Page

Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

2.3.3 Usage Scenario

2.3.3.1 Use Case Scenario - I

Figure 2: UC Scenario – I: User View

USE CASE DESCRIPTION

Use Case Id UC_01
Fun ID F 1.1
Use Case Name View Details
Actor User
Description The user visits the website or mobile application and views the details of the places he/she
wants to visit.
Pre-conditions The user can view the details only if he visits the website or mobile application.
Include Feature N/A
Normal Flow Actions Application Response
1. User visits the website or mobile 1. Searches the details of the places
application. he/she wants to visits.
2. Enter the details of the places he/she 2. Provide list of results matching with
wants to visits. criteria.
3. Clicks on the corresponding place 3. Opens / display the detail of particular
4. Views details of that place place user has selected
Post condition The user’s request gets forwarded to our database.
The user visits the webpage containing information about the selected place.
Alternate Flow 2. A. User entered the wrong name of place, the system responds by not displaying any
data.
4. A. Can’t find the place, a pope up message will appear to enter a new place.
a* At any time, System fails:
 To support recovery and correct accounting, ensure all transaction sensitive state and
events can be recovered from any step of the scenario.
Table 4: UC_01 View Details

Group members: Name (ID) 7|Page

Name (ID), Name (ID)
SYSTEM DESIGN
School of Professional Advancement (SPA) <Project Name>

3. SYSTEM DESIGN

3.1 System Architecture

Describe the system architecture, or simply provide the architecture diagram. For School system it may
include web based front end, web server, database etc. Don’t worry too much about it just give a simple
diagram of a typical web based project?
System Architecture Diagram

HTTP HTTP
Browser In ternet Browser

Bank 1
Computer
HTTP

Base 24
ATM
ATM Host 1 Web Server Mail Server
Machin e Netw ork
Partitioning
IMAP
ATM
Machin e
Application Thir d Party
Gateway
Server Realtime Stock
Quotes
JDBC

Base 24
eAccessCard Host
User Profile
ATM
ATM Host 2 TekChand eAccessCard User Prefe rences Sta te Lotte ry
Machin e
Proprietary Database Emergency Data Servic e
Sto ck Portfolio

ATM
Machin e

Bank 2
Computer

Figure 3: System Architecture

3.2 Class Diagram

3.3 Sequence Diagram (Against each use case)

This is an optional section. It may help when the Typical Course Of Events (Section 3.4) is too detailed to
clarify the flow properly.
A system sequence diagram is a picture that shows, for a particular scenario of a use case, the events that
external actors generate their order, and intersystem events. All systems are treated as a black box; the
emphasis of the diagram is events that cross the system boundary from actor to systems.
A system sequence diagram should be completed for the typical course of events of the use case, and
possibly others, for the most interesting alternative courses.

:System :Verification
System
Group Members:: System
Name (ID), Name (ID) 9|Page
Administrator
Name (ID), Name (ID)
checkout(item,price)
 payment_type(cash, cc)
verify(amt,cc)

School of Professional Advancement (SPA) <Project Name>

reply(true)
record(amt, pymt_type)

Figure 4: Sequence Diagram

3.4 Activity Diagram (Against each use case)

Figure 4 Activity Diagram

Group Members: Name (ID), Name (ID) 10 | P a g e

Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

3.5 System Collaboration Diagram (Optional)

3.5 Entity Relationship Diagram

3.6 Data flow Diagram

3.6.1 Level 0
3.6.2 Level 1
3.6.3 Level 2

3.7 Deployment Diagram (Optional)

3.8 Component Diagram (Optional)

3.9 State Transition Diagram (Optional)

Group Members: Name (ID), Name (ID) 11 | P a g e

Name (ID), Name (ID)
 4
IMPLEMENTATION
School of Professional Advancement (SPA) <Project Name>

4. IMPLEMENTATION

Here is a sample for implementation chapter, (make sure you will not copy it) i.e. if you use any
of the following tools and techniques than you have to mention according to your project’s
working (don’t describe their definitions in fact describes how these tools and techniques works
in your project). The whole section of coding should be put in the appendix. If in implementation,
somewhere you want to discuss some coding section than you must refer it from appendix by
giving figure of the snapshot of the code.
Implementation is the phase where visions and plans become reality. This is the logical
conclusion, after evaluating, analyzing, planning, designing and coding a project.

4.1 TOOLS
4.1.1 Web Application
 VISUAL STUDIO 2015

We have used visual studio 2015 for the implementation of our web application. We have
selected this software because we have used it before as well. Another reason for its selection
is because it comes with the .NET Framework, including the Common Language Runtime,
and includes several programming languages including Visual Basic, Visual C++, and Visual
C#.
4.1.2 Database
 SQL SERVER MANAGEMENT STUDIO 2014

We have used SQL server management studio for the implementation of our database. We
have selected this software because we have used it before. Another reason for its selection is
because it is very easy to use and understand, therefore any problems we face in our database
can easily be overcome.
4.1.3 Android Application
 ANDROID STUDIO
We have used android studio for the implementation of our android application. we have
selected it because we have past experience with it. Another reason for choosing it is Android
Studio makes code writing and analysis faster, easier and more accurate.
4.1.4 Game Developmenmt
 Unity
We have used unity for the implementation of our game development. we have selected it
because we have past experience with it. Another reason for choosing it is unity makes better
interface, design, code, cross platform, writing and analysis faster, easier and more accurate.

4.1.4 Documentation
 MICROSOFT WORD

To write the documentation for our project, we chose Microsoft word, because just like
more than 3 quarters of the world we have past experience with it. Also, not only is

Group Members: Name (ID) 13 | P a g e

Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

Word relatively easy for basic users to work with; it is also a standard product and so
heavily in use across almost everywhere in the world, a document written with Word
can easily be sent to other team members for review and editing, without worrying
about whether they can open it.
 PAINT

We have used paint in our project documentation mainly to take screenshots. This document
contains many diagrams and tables which were built on some other software or applications,
and would have been impossible to attach with the documentation if it was not for the
screenshot feature of paint.
 Visual Paradigm

Visual paradigm is used in our project for making the diagrams in the design phase. With the
help of visual paradigm, it becomes easy to draw these diagrams. Also visual paradigm
tutorials for making various diagrams can be easily found on the internet which is very
helpful as well. Also it is available for a 30-day free trial version which allow students to
enjoy its benefits while not having to buy it.

4.2 TECHNIQUES
 MYSQL

MySQL is the world's most popular open source database. With its proven performance,
reliability and ease-of-use, MySQL has become the leading database choice for web-based
applications
 NoSQL

Store and sync data with our NoSQL cloud database. Data is synced across all clients in
realtime, and remains available when your app goes offline.
The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and
synchronized in realtime to every connected client. When you build cross-platform apps with
our iOS, Android, and JavaScript SDKs, all of your clients share one Realtime Database
instance and automatically receive updates with the newest data.
 HTML

HTML stands for Hypertext Markup Language. It is a standardized system for tagging text
files to achieve font, color, graphic, and hyperlink effects on World Wide Web pages.
 CSS

CSS stands for Cascading Style Sheets (CSS). It is a style sheet language used for describing the
presentation of a document written in a markup language.
 PHP

PHP is the recursive acronym for PHP: Hypertext Preprocessor. it is a widely-used open source
general-purpose scripting language that is especially suited for web development and can be embedded
into HTML.
 BOOTSTRAP

Bootstrap is a technique of loading a program into a computer by means of a few initial instructions
which enable the introduction of the rest of the program from an input device
Group Members: Name (ID) 14 | P a g e
Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

 JQUERY

JQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document
traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API
that works across a multitude of browsers.
 JAVA SCRIPT

Javascript is a dynamic computer programming language. It is lightweight and most commonly used as
a part of web pages, whose implementations allow client-sidescript to interact with the user and make
dynamic pages. It is an interpreted programming language with object-oriented capabilities.

4.3 LANGUAGES
 ANDROID

Android software development is the process by which new applications are created for

the Android operating system. Applications are usually developed in Java programming language
using the Android software development kit (SDK), but other development environments are also
available. We have used android programming language in our mobile application.
 C#

C# (pronounced "C-sharp") is an object-oriented programming language from Microsoft that aims to

combine the computing power of C++ with the programming ease of Visual Basic. C# is based on C++
and contains features similar to those of Java. We have used c# in our web application
 SQL

SQL stands for Structured Query Language. It is a domain-specific language used in programming and

designed for managing data held in a relational database management system (RDBMS), or for stream
processing in a relational data stream management system (RDSMS). We have used SQL
programming language in our database.
 HTML

HTML stands for Hypertext Markup Language. It is the set of markup symbols or codes inserted in a
file intended for display on a World Wide Web browser page. The markup tells the Web browser how
to display a Web page's words and images for the user. We have used HTML in our web application.
 CSS

Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation of a
document written in a markup language. We have used CSS in our web application.
 PHP

PHP is a server-side scripting language designed primarily for web development but also used as a
general-purpose programming language. We have used PHP for the connectivity of our web and
android application with our database.

4.4 Traceability Matrix

4.5 Snapshots of Frond End

Form Title: Heading of the form
Interface Id: UI – 01
Description: Main Window of <XYZ> System opens when application is started. This
Group Members: Name (ID) 15 | P a g e
Name (ID), Name (ID)
School of Professional Advancement (SPA) <Project Name>

window will contain welcome message for user.

Snapshot:

Group Members: Name (ID) 16 | P a g e

Name (ID), Name (ID)
 5
TESTING
School of Professional Advancement (SPA) <Project Name>

5. TESTING

5.1 Test Cases

Test Cases should be at least against use cases

Test Case Id TC_001

Test Engineer Names of testers

Functional Area Login page

Test Name Verification of login fields

Objective The purpose of this test is to ensure that the system is not allowing the admin to login if
valid username and password is not given.

Environment .Net, PHP, SQL

Strategy 1. Enter invalid login details

2. Press login

Expected Result Error message displayed indicating the missed fields and/or invalid data

Test Result Pass

Table 2 Test case of Login

5.2 TID template

5.3 Decision Table

5.4 Black Box Testing

5.5 White Box Testing

Group Members: Name (ID) 18 | P a g e

Name (ID), Name (ID)
 6
RESULTS/OUTPUT/STATISTICS
School of Professional Advancement (SPA) <Project Name>

6. RESULTS/OUTPUT/STATISTICS

6.1 Traceability Matrix (TID vs UID)

6.2 % Completion

6.3 % Accuracy

6.4 % Correctness

Group Members: Name (ID) 20 | P a g e

Name (ID), Name (ID)
 7
CONCLUSION & SUMMARY
School of Professional Advancement (SPA) <Project Name>

7. CONCLUSION AND SUMMARY

7.1 CONCLUSION

7.2 SUMMARY

7.3 LESSON LEARNED

Group Members: Name (ID) 22 | P a g e

Name (ID), Name (ID)
 8
FUTURE WORK
School of Professional Advancement (SPA) <Project Name>

8. FUTURE WORK

Group Members: Name (ID), name (ID) 24 | P a g e

Name (ID), Name (ID)
 9
REFERENCES
9. REFERENCES

[1] GansenZhao,ChunmingRong, Martin GiljeJaatun, FrodeEikaSandnes, “Deployment

Models: Towards Eliminating Security Concerns from Cloud Computing”, DOI: 978-1-
4244-6830-0/10, 2010, IEEE, Pp 189-195.

[2] Richard M. Thompson II, Cloud Computing: Constitutional and Statutory Privacy
Protections, http://www.fas.org/sgp/crs/misc/R4 3015.pdf [Accessed on 11.12.14].

[3] SianiPearson,Privacy, Security and Trust in Cloud Computing,HP Laboratories, HPL-

2012-80R1, http://www.hpl.hp.com/techreports/2012/HPL-2012-0R1.pdf [Accessed on
11.12.14]

[4] A V Parameswaran and AsheeshChaddha,Cloud Interoperability and Standardization,

SETLabs Briefings, VOL 7 NO 7, 2009, Page 19-26

[5] Piers Wilson, “Positive perspectives on cloud security”, information security technical
report (2011), 1363-4127/$, doi:10.1016/j.istr.2011.08.002, Pp 1-5.
 10
APPENDIX
School of Professional Advancement (SPA) <Project Name>

10. APPENDIX

10.1 Glossary of terms

10.2 Environmental setup (Optional)

10.3 Experimental setup (Optional)

10.4 Assumptions (Optional)

10.5 Pre-requisites (Optional)

10.6 Data sets/test data

10.7 Code of back End

10.8 Project Management Documents

10.8.1 Team Structure
10.8.2 Roles and Responsibilities
10.8.3 WBS (Work Breakdown Structure)
10.8.4 PERT Diagram (Based on 10 Months of Work)
10.8.5 Critical Path
10.8.6 Scope Statement
10.8.7 Project Charter
10.8.8 Meeting Summary

28 | P a g e