Eventos New

EVENTOS
Abeera Shahid
Usama Bugvi
DEPARTMENT OF COMPUTER SCIENCES

COMSATS UNIVERSIY ISLAMABAD, WAH CAMPUS
PAKISTAN
SESSION 2016-2020
EVENTOS
Undertaken By: Abeera Shahid
REG. NO CIIT/FA16-BSE-165/WAH
Undertaken By: Usama Bugvi

REG. NO CIIT/FA16-BCS-085/WAH
Supervised By:
Dr. Muhammad Wasif Nisar
A DISSERTATION SUBMITTED AS A PARTIAL FULFILMENT OF THE

REQUIREMENTS FOR THE DEGREE OF BACHELORS IN SOFTWARE ENGINEERING
DEPARTMENT OF COMPUTER SCIENCES

COMSATS UNIVERSITY ISLAMABAD, WAH CAMPUS
PAKISTAN
SESSION 2016-2020
FINAL APPROVAL
This is to certify that we have read the thesis submitted by Abeera Shahid having
Registration no. FA16-BSE-165 and Usama Bugvi having Registration no: FA16-
BSE-085. It is our judgment that this report is of sufficient standard to warrant it
acceptances by the COMSATS University Islamabad, Wah Campus for the
Bachelor Degree in Software Engineering.
1. Internal Examiner
Mr. /Miss __________________________________
Mr. /Miss___________________________________
Mr. /Miss___________________________________
Department of Computer
Science, COMSATS
University Islamabad, Wah
Campus.
1. External Examiner
Mr. /Miss___________________________________
ii
Mr. /Miss___________________________________
Mr. /Miss___________________________________
4. Supervisor
___________________________________
Department of Computer
Science, COMSATS
University Islamabad, Wah
Campus.
5. Head of Department
___________________________________
Associate Professor Department of Computer Science COMSATS University
Islamabad,
Wah Campus.
A report submitted to COMSATS University Islamabad, Wah Campus

As a partial fulfillment of requirements for the award of
the degree of Bachelor of Science in Software
Engineering
iii
DEDICATION
We dedicate this project to our beloved parents without them we are nothing and
we were unable to get here, teachers and the friends who helped and supported us
on every step. Without their support and intellectual, we were unable to complete
this project.
iv
ACKNOWLEDGEMENT
First of all, we are thankful to Almighty Allah who helped us and enabled us to
accomplish this project. We would like to acknowledge and show our deep
gratitude to our supervisor, Dr. Muhammad Wasif Nisar for his constant
assistance, advice and support which was so freely given during the whole project.
We would also like to thank our parents who have given us the chance to study and
acted as a backbone and a major reason behind our accomplishment. We express
heartiest gratitude to our friends and all those who helped us in completing this
project and project report.
v
PROJECT BRIEF
PROJECT NAME EVENTOS.

ORGANIZATION NAME COMSATS UNIVERSITY
ISLAMABAD, WAH CAMPUS
OBJECTIVE TO PROVIDE A PLATFORM

FOR UNIVERSITY STUDENTS
ESPECIALLY FOR SOCITIES TO
MANAGE EVENTS HANDLING
ON A SINGLE CLICK.
UNDERTAKEN BY ABEERA SHAHID

USAMA BUGVI
SUPERVISED BY DR.WASIF NISAR
STARTED ON SEPTEMBER 2019
COMPLETED ON AUGUST 2020
SOURCE LANGUAGE JAVA, PHP, BOOTSTRAP
OPERATING SYSTEM ANDROID OS, WINDOWS
TOOLS USED ANDROID STUDIO, XAMPP, SUBLIME
vi
ABSTRACT
Eventos management system is used to manage all the activity related to society’s
events. To manage all these activity we have developed this software. To get
success in this event management, user should have strong network contacts of
participants, society heads and administration. These contacts are essentially
providers of specific services who can be mobilized quickly to participate in any
given event for students and vice versa it’s easy for administration to keep check
and balance on events through app or website. To make an event successful society
event manager needs different materials for events which they write on demand
form like sound systems services, lighting providers(fairy lights, disco lights etc.),
stage props and so on. It is also important for event organizer that he has all the
contacts details of the participants so that he can contact them any time to plan an
event at given time which is not manageable for all events so online system is
better solution for this. To keep all payment information on papers for event
registrations is so problematic. There is no system to check the past expenses plus
registrations of any event. To do this they have to check payment register and this
task is very time consuming and tiresome. All these arising problems are resolve in
our online system with extended features
vii
Table of Contents
DEDICATION................................................................................................................................................iii
ACKNOWLEDGEMENT.................................................................................................................................iv
PROJECT BRIEF.............................................................................................................................................v
ABSTRACT...................................................................................................................................................vi
LIST OF ABBREVIATION...............................................................................................................................xi
1. INTRODUCTION...................................................................................................................................1
1.1. Introduction.................................................................................................................................2
1.1.1. Purpose of Project...............................................................................................................2
1.1.2. Objective of this project.......................................................................................................2
1.1.3. Scope of Project...................................................................................................................2
1.1.4. Product Function..................................................................................................................2
1.1.5. Tools and Techniques..........................................................................................................3
1.2. Report Layout..............................................................................................................................3
2. EXISITING SYSTEM...............................................................................................................................4
2.1. Existing systems...........................................................................................................................5
2.2. User Problem Statement.............................................................................................................5
2.3. User Characteristics.....................................................................................................................5
2.4. User Objectives............................................................................................................................5
3. Requirements Analysis........................................................................................................................5
3.1. Requirement Analysis:.................................................................................................................6
3.2. Functional Requirements.............................................................................................................6
3.2.1. Login/Sign Up.......................................................................................................................6
3.2.2. Student Week information..................................................................................................6
3.2.3. Register for event................................................................................................................7
3.2.4. Dashboard............................................................................................................................7
3.2.5. Chat box system...................................................................................................................8
3.2.6. Event notification.................................................................................................................8
3.3. Non-functional requirements......................................................................................................9
3.3.1. Reliability.............................................................................................................................9
3.3.2. Maintainability.....................................................................................................................9
viii
3.3.3. Extensibility..........................................................................................................................9
3.3.4. Reusability.........................................................................................................................10
3.3.5. Compatibility......................................................................................................................10
3.3.6. Security..............................................................................................................................10
OBJECT ORIENTED DESIGN........................................................................................................................11
4.1. Introduction to UML:.................................................................................................................12
4.1.1. Goals of UML:........................................................................................................................12
4.2. Use Case Diagrams.....................................................................................................................13
Figure1: Use Case..................................................................................................................................14
4.3. Activity Diagram:........................................................................................................................15
Figure 2: System Activity Diagram........................................................................................................15
4.4. Class Diagram.............................................................................................................................16
Figure 3: Class Diagram.........................................................................................................................16
Figure 4: ER Diagram.............................................................................................................................17
4. SYSTEM DESIGN.................................................................................................................................18
5.1. Designing...................................................................................................................................19
5.2. User Friendly..............................................................................................................................26
5.3. Design Constraints.....................................................................................................................26
5.4. Standards Compliance...............................................................................................................26
5.5. Hardware Limitations................................................................................................................26
5.6. Development Setup...................................................................................................................26
5. QUALITY ASSURANCE &TESTING.......................................................................................................28
6.1. Introduction...............................................................................................................................29
6.2. Testing Levels.............................................................................................................................29
6.3. Testing plane..............................................................................................................................29
6.3.1. Black Box Testing...............................................................................................................29
6.3.2. White Box Testing..............................................................................................................29
6.4. Test Cases:.................................................................................................................................30
7.1. Implementation:.................................................................................................................................34
7.1.1. Tools Used:..................................................................................................................................34
7.1.2. Sublime Text 3:............................................................................................................................34
6. Risk Performance...............................................................................................................................39
8. Risk Assessment.................................................................................................................................40
ix
8.1. Performance Risk.......................................................................................................................40
8.2. Project Risk................................................................................................................................41
8.3. Technical Risk.............................................................................................................................42
CONCLUSION.............................................................................................................................................43
9.1. Conclusion.................................................................................................................................44
References.............................................................................................................................................44
x
LIST OF ABBREVIATION
UML The Unified Modeling Language (UML) is a general-purpose, developmental,
modeling language in the field of software engineering that is intended to
provide a standard way to visualize the design of a system.
OS Operating System
GUI Graphical User Interface
XML Extensible Markup Language
xi
CHAPTER 1
1.INTRODUCTION
1
Chapter 1 = Introduction
1.1. Introduction
Many applications and websites are there which help to manage the events, but our system is
a bridge for the different stakeholders. The stakeholders would have separate authorities in
our system. The purpose of this document is to give a complete description about how our
system will work in university it’s for the ease of major stakeholders. Our project is a social
network on which students can have complete detailed information of sports week events,
games, schedules, societies complete information as well as higher authorities (student affair
in-charge, faculty) can manage sports week activities properly through our online system.
1.1.1. Purpose of Project
The main purpose is to provide and online system which can give information of sports
week events because not everyone know what event is occurring at which venue and how to
register in it. Faculty heads of societies have check and balance on every activity happening in
their society on a single click and admin panel can control and manage whole sports week at a
single platform. It’s basically online event handling system.
1.1.2. Objective of this project.
The purpose of this project is to design and develop a user-friendly system that provides online
system of student week for the university.
1.1.3. Scope of Project
The product will be developed to assist university their events online, our aim is to make easy events
handling for faculty and students. We are creating a system in which all paperwork done will be done by
online system.
1.1.4. Product Function
This system will enable inter communication between the administration, faculty, head
organizers and the participants. In which admin and faculty communicate with each other
using chat box and also arrange meetings and head of society easily communicate with
president of society. Application for new events can be submitted and in-charge of student
2
affairs can accept or reject any new event application. Users can also give their feedbacks
below every event. Event organizers can fill and submit their demand forms using this system
and issue their needed items. Users can also volunteer himself as a helper of organizers of
events. Participants can register themselves whenever they want.
1.1.5. Tools and Techniques
Selection of most suitable tools and techniques for development of software plays an important
role in the development of project.
1.2. Report Layout
This report is organized in a way to cover all essential points which can be required to make
this record a self-exploratory one. The report is split into following chapters:
1. The chapter 1 entitled Introduction in brief describes the reason and scope of the system.
2. The chapter 2 entitled Existing System explains about project in further more details.
3. The chapter 3 entitled Requirements Analysis including functional and non-functional

requirements
4. The chapter 4 entitled Object Oriented Design shows the diagrams including Use Case
Diagrams.
5. The chapter 5 entitled System Design shows the design views of whole system including
application GUI interfaces.
6. The chapter 6 entitled Quality assurances shows the quality measure of the software and
test cases implemented.
7. The chapter 7 entitled Risk Performance explains what we have achieved while making this
project and what more work can be done on this project in future.
8. The chapter 8 entitled Conclusion explains what we have achieved while making this
project and what more work can be done on this project in future and also the references used
for this project.
3
CHAPTER 2
2. EXISITING SYSTEM
4
2.1. Existing systems
As there is similar system regarding our project exists like event management but not for specific
university purpose our system will provide services to the university for handling events online.
2.2. User Problem Statement
This application removes the fatigue and paperwork for organizers and participants for
maintaining the record and applying for membership, respectively. Instead of doing it manually
this service is provided 24/7 with in the deadline which makes it more effective in making the
events collaborative.
2.3. User Characteristics
In our system faculty can schedule, communicate and arrange meetings with head members,
organizing members maintain and organize events and participants can register themselves for
membership and can participate in different societies.
Primary User: Admin (student affair), faculty, it department, society head are primary user
Developer: The role of a developer is to design and maintain the application.
Client: Client is the secondary actor of proposed project that is student (participants), organizers.
2.4. User Objectives
Our system will improve the coordination and performance of events handling in societies:
 Administration can easily access and notify to societies faculty head.
 Faculty head can handle and manage his/her society.
 Head members can easily get information from participants.
 Participants can register themselves whenever they want.
 Organizers can easily issue their needed items using demand form.
 Students can also volunteer him in arranging events who are not a part of any society.
5
2.5. Project Overview:
The overall system is depending on a single centralized database that can be access through
different platforms, web and android. Architecture diagram for the functioning of our software is
shown in figure below:
6
CHAPTER 3
3. Requirements Analysis
5
Chapter 3 Requirements Analysis
3.1. Requirement Analysis:
Requirement analysis is the process of determining user expectations for a new or

modified project and is well-defined stage in Software Development Life Cycle model.
Requirements are description of how a system should behave or a description of a system
properties or attributes. It can alternatively be a system of „what‟ an application is
expected to do. The Software requirements analysis process covers the complex tasks of
eliciting and documenting the requirements of all these users, modeling and analyzing the
requirements and documenting them as a basis for system design. The requirements are
divided into functional and nonfunctional requirements. This section chapter is the
complete description of our project. It states the perspective of the system. This chapter
also shows the constraints faced by the system, and the assumptions we made both about
the systems it will be interacting with, and the people who will be using the system
3.2. Functional Requirements
3.2.1. Login/Sign Up
Title Login or signup
Login/signup is provided to students, faculty, admin,

Description
store person
Criticality Important Functionality
Technical Issues Requires internet connection
Cost and Schedule 1 week
Risks
No
Dependencies with another

-
requirement
3.2.2. Student Week information

6
Title Student Week information
Students will be able to get student week event

Description
information
Cost and Schedule 2-3 days
Risks
No
Dependencies with other

Student must be login
requirement
3.2.3. Register for event.
Title Register for event
Students will have the online form where they can

Description
register for an event.
Cost and Schedule 1 week
Risks
No

requirement
7
3.2.4. Dashboard
Title Dashboard
Students, teachers, admin, society head, organizers will

Description
have separate dashboard.
Cost and Schedule 2-3 week
Risks
No

requirement
3.2.5. Chat box system.

Title Chat box system
Description Admin and faculty will have chat box system
Risks
No

Admin and faculty must be login
requirement
8
3.2.6. Event notification
Title Event notification
Students will get two times notification before event

Description starts and on event day, notification of meetings for
sports week.
Risks
No

User must be login
requirement
3.3. Non-functional requirements
3.3.1. Reliability
If changes required then system will easily handle them without disturbing whole
system, because we will use 3-tier architecture in this application. The user interface
layer, logical layer & database layer will be separated from each other. In this way only
that layer will be touched in which updating is required? The application would be quite
reliable.
3.3.2. Maintainability
In case of any update in system could be required there will be a developer support to
full fill those updates requirement. Whereas system will not be disable for
implementing new requirements. Unless it’s a major upgrade
9
3.3.3. Extensibility
In future, the IOS version of this project can also be launched, such that to compete with
the latest technology & society.
3.3.4. Reusability
The languages & sources used for developing this project are free. Therefore, we can
reuse or update anything in this project very easily at any time.
3.3.5. Compatibility
This project will be compatible on 90% android devices & different screen sizes.
3.3.6. Security
As the system deals with critical data security should be up to date on user access and
server level
10
CHAPTER 4
OBJECT ORIENTED DESIGN
11
Chapter 4 Object Oriented Design
4.1. Introduction to UML:
The Unified Modeling Language (UML) is a standard language for specifying,

visualizing, constructing, and documenting the artifacts of software systems, as well as
for business modeling and other non-software systems. The UML represents a collection
of best engineering practices that have proven successful in the modeling of large and
complex systems. The UML is a very important part of developing objects-oriented
software and the software development process. The UML uses mostly graphical
notations to express the design of software projects. Using the UML helps project teams
communicate, explore potential designs, and validate the architectural design of the
software.
4.1.1. Goals of UML:
The primary goals in the design of the UML are to provide users with a ready to-use,
expressive visual modeling language so they can develop and exchange meaningful
models. Provide extensibility and specialization mechanisms to extend the core concepts.
Be independent of programming languages and development processes. Provide a formal
basis for understanding the modeling language. Encourage the growth of the Object-
oriented tools market. Support higher-level development concepts such as collaborations,
frameworks, patterns and components. Integrate best practices.
12
4.2. Use Case Diagrams
A use case diagram at its simplest is a representation of a user's interaction with the system that
shows the relationship between the user and the different use cases in which the user is involved
We use UML Standard Notation for making Object Oriented Design as like Use cases, activity
diagrams.
The use case diagram is used to identify the primary elements and processes that form the
system. The primary elements are termed as “actors" and the processes are called "use cases."
The use case diagram shows which actors interact with each use case
13
Figure1: Use Case
14
4.3. Activity Diagram:
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the UML activity diagrams are intended to
model both computational and organizational processes
Figure 2: System Activity Diagram.
15
4.4. Class Diagram
A class diagram in UML is a type of static structure diagram that describes the structure of a
system by showing the system’s classes, their attributes, operations and relationships among the
objects. Class diagram is the basic building of object-oriented modeling.
Figure 3: Class Diagram.
16
4.5. Entity–relationship model (ER model)
An Entity–relationship model (ER model) describes the structure of a database with
the help of a diagram, which is known as Entity Relationship Diagram (ER Diagram).
An ER model is a design or blueprint of a database that can later be implemented as a
database. The main components of E-R model are: entity set and relationship set
Figure 4: ER Diagram
17
Chapter 5 System Design
CHAPTER 5
4. SYSTEM DESIGN
18
5.1. Designing
Designing has become one of the most compelling and attractive strategies of the android
applications in the present era. Interface of the app and website (i.e. Input, output, and login)
screens are attached. Besides having attraction and beauty it should be simple and user-friendly
so that the people may have little knowledge about the Internet can get benefits by easy
navigations and user-friendly designs. When the users using the app, they do not feel hesitation.
All the major segments provided in a way that everyone can use the system efficiently. To cope
with the requirements and trends of the world we have also paid our attention on the designing of
our website which is very important.
Figure 5: App front screen Figure 6: App Home Screen
19
Figure 7: App login screen:
20
Figure 8: App verification screen:
21
Figure 9: App home screen:
22
Figure 10: Website home page:
23
Figure 11: Website dashboard
24
Figure 12: Society events display
25
5.2. User Friendly
Our application on android as well as on web is designed to be fully user friendly so that user
doesn't get confused while using it. All the controls are pretty self-explanatory and are designed
that way to keep the user guided and engaged.
5.3. Design Constraints
The design of the application has to be in a certain way so it can fit on different screens as
android phones have different screen sizes so that creates a constraint on the type of screen you
want to design.
5.4. Standards Compliance
Our application and website follows the existing standards and regulations of working and
database CMS operations.
.
5.5. Hardware Limitations
This Application will be available for every platform that can access internet on web and in
mobile environment it will be available for android phones.
5.6. Development Setup
Programming language: JAVA, PHP

Frontend: HTML, XML, CSS, bootstrap, JAVA Script
Hardware interface: windows 7/8
Database: MYSQL XAMPP
26
Tools: ANDROID STUDIO, SUBLIME TEXT EDITOR

Server,
Framework: MVC
MySQL server is an open source relational database management system
which is used to store the database using SQL queries. In this project data
of halls, wedding lawns and data of accounts are stored in it.
MVC (Model View Controller) is used for implementing user interface on computers
27
CHAPTER 6
5. QUALITY ASSURANCE &TESTING
28
Chapter 7 Implementation
6.1. Introduction
In quality assurance phase which is mainly based on Test plan including testing strategies and
types of testing applied to ensure the reliability, security and accuracy of the system to give the
user a great and error free learning experience. Happiness and satisfaction of customer (User) is
our first and foremost priority to ensure that a proper testing mechanism was devised and the
results are tabulated in the form of test cases and to trace each test case against desired functional
requirement.
6.2. Testing Levels

The system testing can be performed at different levels. Following are the different software
testing level.
• Unit Testing.
• Integration Testing.
• System Testing.
6.3. Testing plane
6.3.1. Black Box Testing

We tested our software according to the requirement specification document and found that
every functionality that was required was completed and no misplaced functions, coding error
were found.
6.3.2. White Box Testing

In this testing we have inspected the inner data composition, algorithms and the implemented
code of the system. Every major inner component of the software like integration module was
tested logically and was found to be working in accordance with how it was supposed to be
working.
6.3.3 Static Testing:

Testers examine the software’s code and documentation but don’t execute the program. Static
tests start at the early stages when the product is under development during the verification
process.
6.3.4 Dynamic Testing:

The software is executed with various inputs, and testers compare outputs with expected
behavior with this method.
29
6.3.5 GUI Testing:

This tests GUI characteristics -- text formatting, text boxes, buttons, lists, layout, colors, fonts,
font sizes, and so on. GUI testing is time-consuming, and third - party companies often take on
the task instead of developers.
6.4. Test Cases:
Definition.
A test case is a specification of the inputs, execution conditions, testing procedure, and expected
results that define a single test to be executed to achieve a particular software testing objective,
such as to exercise a particular program path or to verify compliance with a specific requirement.
Test case 1
Test Test Test Steps: Test Data: Expected Actual Pass/Fai

case id: Scenario: results: results: l
TCID Check student Go to site/app Reg no: ___ Student As Pass
1 login with valid Enter student reg Student should expected
data no password: login into
Enter student ******* application.
password
Check submit
30
Test case 2

case id: Scenario: results: results: l
TCID Check student Go to site/app Reg no: ___ User should Incorrect Fail
2 login with in- Enter student reg no Student not login Data
valid data Enter student into enter
password:
password application.
*******
Check submit
Test case 3

case Scenario: results: results: l
id:
TCID Check student Go to student profile Reg no: ___ User Incorrect Fail
3 Event Enter game reg details Student should not Data
registration Enter password: login into enter
process Check submit ******* application.
Test case 4:
31

id:
TCID Super admin Go to login Correct email: User correct Pass
4 can enter Enter password ___ should Data
roles Check submit Admin login into enter
password: application.
*******
Test case 5:

id:
TCID Test  Go to site Correct email: User As Pass
5 User  Enter user id ___ should expected
forgot  Enter user password: login into
password password: application.
 “password Empty
forgot”
Verification
 Enter
verification code: *****
Code Enter new
 Enter new password
password. : ****
32
CHAPTER 7
IMPLEMENTATION
33
7.1. Implementation:
This chapter is about the overview of the implementation techniques and technologies used to
develop this project. Implementation is the most important part of any project when actual work
starts. It is the process of making your dream into reality. In this project we have covered
modules and software development methodologies and technologies used to develop the project.
We adopted agile development methodology. Implementation is the phase, where vision and plan
become reality.
This phase involves evaluation, visioning, planning, allocation of budget and provision of
financial resources for the project. First, we developed version 1 by adding basic requirements.
Then we added other requirements in version 2
Process whereby “project inputs are converted into project outputs”
 Putting in action the planned activities

 Putting the project proposal into the actual project
 Management and execution of the project
It is important to recognize that, planning and engaging in the implementation of any

innovation, evidence-based practice, or cluster of practices take time, energy and resources.
The change process can be understood and organized using defined steps and subsequent
activities that are necessary to shift a concept into reality. Some of the reasons for programs
in a change process are:
 A newly defined vision or direction

 A crisis
 A new mandate
 Data that supports a change is needed
 New information/ research
 Old procedures are incapable to give desired outcomes
7.1.1. Tools Used:
Following are the tools that are used throughout the development of the system.
7.1.2. Sublime Text 3:
Sublime Text 3 is a source code editor designed for Windows, Linux and mac OS. It
includes support for debugging, embedded GIT control, syntax highlighting, intelligent
code completion, snippets, and code refactoring.
34
Figure 13.
35
Figure 14:
36
Figure 15:
37
Figure 16:
Figure 17:
38
Chapter 8
6. Risk Performance
39
Chapter 9 Risk Performance
8. Risk Assessment
It is necessary to review at the risks that might be involved in our system. These risks must be
documented as seen before the coding for the project is started. Majority of the risk components
lie under the following categories.
• Performance Risk
• Project Risk
• Technical Risk
8.1. Performance Risk
The degree of uncertainty that the product will meet. Its requirement will be fit for its intended
use. Table describes about performance risk according to criticality of the various aspect of the
performance
40
Table
: Performance Risk
# Risk Likelihood Impact
1 Will the product not meet the specified Low Critical

standards?
2 Will the software not generate records Low Critical
properly
3 Will software degrade the performance Very Low Critical
of the user’s computer
4 Will software have bugs and defects Low Catastrophic
after the release
8.2. Project Risk

Project risk will threaten the project plan. That is if project risk becomes real, it is likely that project
schedule will slip and the cost will increase. Project risk identifies potential budgetary, schedule,
personal (staffing and organization), resource, customer and requirement problem and their impact on
software project. Table 16 describes about project risk according to various critical aspect of our system.
Table: Project Risk
1 Will the project fall short over the Medium Critical

expectations?
2 Will customer requirements not remain Low Critical
constant throughout the development
of project?
8.3. Technical Risk

Technical risk will threaten the quality and timeliness of the software to be produced. If the
technical risk becomes a reality; implementation will become difficult or impossible. Technical
risk identifies potential design, implementation, interface, verification and maintenance problem.
In addition, specification ambiguity, technical uncertainty and leading-edge technology are also
41
risk factors. Technical risk occurs because the problem is harder to solve than we thought it
would be.
Table: Technical Risk
1 Is support material for the development Low Catastrophic

of project available (Research papers,
Documents of similar software etc.)?
2 Are the developers incapable of Medium Critical
developing the system?
3 Is the existing technology incapable of Low Catastrophic
providing a base to develop this
software?
42
CHAPTER 9
CONCLUSION
43
9.1. Conclusion
In the end we are thankful to ALMIGHTY ALLAH who has provided us with the strength and
courage to fulfill our task. By completing this project we have gained some idea of how
professional software’s are developed. The main objective of our project was to provide the
students an event management system for the student week which is not available right now and
we have done our best in developing such system. We have worked to the best of our abilities to
develop this system and completed all the requirements mentioned in the proposal.
References
1. http://www.w3schools.com/
2. http://stackoverflow.com/
3. https://www.tutorialspoint.com/web_development_tutorials.htm
4. http://github.com/
5. http://www.vogella.com/tutorials/dotnet/artcle.html
44

Eventos New

Uploaded by

Copyright:

Available Formats

Eventos New

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eventos New

Uploaded by

Copyright:

Available Formats

EVENTOS

DEPARTMENT OF COMPUTER SCIENCES

Undertaken By: Usama Bugvi

A DISSERTATION SUBMITTED AS A PARTIAL FULFILMENT OF THE

DEPARTMENT OF COMPUTER SCIENCES

Mr. /Miss __________________________________

A report submitted to COMSATS University Islamabad, Wah Campus

PROJECT NAME EVENTOS.

OBJECTIVE TO PROVIDE A PLATFORM

UNDERTAKEN BY ABEERA SHAHID

SUPERVISED BY DR.WASIF NISAR

STARTED ON SEPTEMBER 2019

COMPLETED ON AUGUST 2020

SOURCE LANGUAGE JAVA, PHP, BOOTSTRAP

OPERATING SYSTEM ANDROID OS, WINDOWS

TOOLS USED ANDROID STUDIO, XAMPP, SUBLIME

1.1.1. Purpose of Project

1.1.2. Objective of this project.

1.1.3. Scope of Project

1.1.4. Product Function

1.1.5. Tools and Techniques

1.2. Report Layout

3. The chapter 3 entitled Requirements Analysis including functional and non-functional

2.1. Existing systems

2.2. User Problem Statement

2.3. User Characteristics

2.4. User Objectives

2.5. Project Overview:

3.1. Requirement Analysis:

Requirement analysis is the process of determining user expectations for a new or

3.2. Functional Requirements

Title Login or signup

Login/signup is provided to students, faculty, admin,

Criticality Important Functionality

Technical Issues Requires internet connection

Cost and Schedule 1 week

Dependencies with another

3.2.2. Student Week information

Title Student Week information

Students will be able to get student week event

Criticality Important Functionality

Technical Issues Requires internet connection

Cost and Schedule 2-3 days

Dependencies with other

3.2.3. Register for event.

Title Register for event

Students will have the online form where they can

Criticality Important Functionality

Technical Issues Requires internet connection

Cost and Schedule 1 week

Dependencies with other

Students, teachers, admin, society head, organizers will

Criticality Important Functionality

Technical Issues Requires internet connection

Cost and Schedule 2-3 week

Dependencies with other

3.2.5. Chat box system.

Description Admin and faculty will have chat box system