Travel

Arrangement
System
(TAS)
Project Plan
27.10.2014

Ege University
Computer Engineering
Software Engineering Fall 2014

Mustafa Alper Klc / Burak Beynek /

Kadri Suner / zge Torunolu

Index
1. Introduction.............................................................................................................................. 3
2. Work Breakdown and Milestones ........................................................................................... 3
3. Project Schedule ......................................................................................................................
3.1 Gantt Chart ................................................................................................................
3.2 Network Diagram.......................................................................................................
3.3 Division of Labour.......................................................................................................

5
5
6
7

4. Risk Analysis.............................................................................................................................. 8

1 Introduction
This is a software development project which aims to create a functional web based application for
travel agencies.
The system will provide the following basic functionalities to its users:
planning and arranging trips between two given cities
arranging reservations for accommodation
buying tickets for means of transportation
purchasing package and custom tours
arranging custom tours
TAS will facilitate searching and purchasing every kind ofaccommodation and means of
transportation according to the preferences of the customers that are specified through the system.
On the other hand, it has to facilitate targeting and personalizing the marketing of transportation and
accommodation providers to appropriate potential customers. Our project group will design and
make the demonstration of a complete system that can handle all basic aspects (with preferably
additional features) of the TAS defined above.
Team Members:

Kadri Suner

zge Torunolu

Burak Beynek

Mustafa Alper Klc

2 Work Breakdown and Milestones

PROJECT PLAN (27.10.2014)
1) Gantt Chart of the Project Plan
2) Network Diagram of the Project Plan
3) Division of labor within the team (who is going to do what)
4) Risk analysis document
5) Any other schema or other forms of description that you think is necessary
REQUIREMENTS (ANALYSIS) REPORT (17.11.2014)
1) Introduction
2) Identification of Viewpoints
Principal Viewpoints of the System
Viewpoint Hierarchy Diagram
2

Requirements of each Viewpoint

3) Requirements Definition (considering functionality)
Functional Requirements
Non-functional Requirements
Domain Requirements
** If any of #4 is applicable to your project:
4) Requirements Definition (considering lifetime)
Volatile Requirements
Enduring Requirements
5) Fully Dressed Use Cases
6) Domain Model as a UML class diagram
7) Any other schema or other forms of description that you think is necessary
REQUIREMENTS PRESENTATION (24.11.2014)
The teams are required to present the results of their analysis efforts as a short Power-Point slideshow.
ARCHITECTURAL MODEL (08.12.2014)
- Define the architecture of your system in order to indicate the major components of your system
(subsystems) and the relations between them.
- Show your architecture as a block diagram or a class diagram.
- Indicate if you have employed any generic architecture, architectural style or a reference model.
- Be realistic in determining your subsystems. Note that you will need to refer to this architectural
partitioning in the project plan while arranging the division of labor between your developers.
- Clarify all your entities with a legend or dictionary where necessary.

DESIGN DOCUMENT (15.12.2014)

1. Introduction (purpose of the design document, organization of the document)
2. System Sequence Diagram of each use case
3. Sequence Diagram of main use cases
4. Design Class Diagram
5. Glossary (Explain your terms in a dictionary)
6. Any other schema or other forms of description that you think is necessary
7. Conclusion
DESIGN PRESENTATION (29.12.2014)
The teams are required to present the results of their design efforts and prototype implementation
(demo) as a short (20 min.) presentation and demonstration. We expect to be able to understand
your system design clearly from your presentation, so you should include anything you think is
necessary to achieve this. You are recommended to present your design, referencing your system
architecture. You may change any part of your previous choices as long as you explain in your report
what has been changed and why.
The prototype should cover the main use cases of your design and indicate how the user interface
will function. The underlying system need not be implemented.

3 Project Schedule
3.1 Gantt Chart

3.2 Network Diagram

3.3 Division of Labour

Task Name

Duration Start

Requirement Analysis Report

Identification of Viewpoints
Principal Viewpoints of the System
Viewpoint Hierarchy Diagram
Requirements of each Viewpoint
Functional Requirements Definition
Functional Requirements
Non-Functional Requirement
Domain Requirements
Lifetime Requirements Definition
Volatile Requirements
Enduring Requirements
Fully Dressed Use Cases
Drawing Domain Model as UML
Requirement Presentation
Design Architectural Model
Define Architecture of System
Draw Architecture as a Class Diagram
Write Design Document
Introduction
System sequence Diagram of each use
case
Sequence Diagram of main use cases
Draw Design Class Diagram
Glossary
Conclusion
Design Presentation

16 days
3 days
1 day
1 day
1 day
4 days
2 days
1 day
1 day
2 days
1 day
1 day
2 days
4 days
1 day
9 days
4 days
5 days
6 days
1 day
1 day
1 day
1 day
1 day
1 day
1 day

Sun 26.10.14
Sun 26.10.14
Sun 26.10.14
Mon 27.10.14
Tue 28.10.14
Wed 29.10.14
Wed 29.10.14
Fri 31.10.14
Mon 03.11.14
Tue 04.11.14
Tue 04.11.14
Wed 05.11.14
Thu 06.11.14
Mon 10.11.14
Mon 24.11.14
Tue 25.11.14
Tue 25.11.14
Mon 01.12.14
Mon 08.12.14
Mon 08.12.14
Tue 09.12.14

Finish

Resource Names

Fri 14.11.14
Tue 28.10.14
Sun 26.10.14 Alper
Mon 27.10.14 zge
Tue 28.10.14 Burak
Mon 03.11.14
Thu 30.10.14 Alper;Burak
Fri 31.10.14 Alper
Mon 03.11.14 Burak
Wed 05.11.14
Tue 04.11.14 Kadri
Wed 05.11.14 zge
Fri 07.11.14 Alper;Burak
Thu 13.11.14 Kadri;zge
Mon 24.11.14 Alper;Burak;Kadri;zge
Fri 05.12.14
Fri 28.11.14 Alper;Burak
Fri 05.12.14 Kadri;zge
Mon 15.12.14
Mon 08.12.14 zge
Tue 09.12.14 Alper;Burak

Wed 10.12.14 Wed 10.12.14 Alper;Burak

Thu 11.12.14 Thu 11.12.14 Kadri;zge
Fri 12.12.14
Fri 12.12.14 Kadri
Mon 15.12.14 Mon 15.12.14 Alper
Mon 29.12.14 Mon 29.12.14 Alper;Burak;Kadri;zge

4 Risk Analysis
Risk

Time

Problems in the software development environment

Problems caused by database
Midterms and the process of graduation thesis
Hardware problems
Hardware problems
Personal problems of team members
Changes to requirements that require major design
rework are proposed

Any time
Medium
After Design Medium
Any time
High
<= Design
Very Low
After Design Very Low
Any time
Moderate
>=Requirement
Low
Analysis
>=Requirement
High
Analysis
Any time
Moderate
Any time
Moderate

The size of the software is underestimated

To deviate from the scheduled time
Wrong division of labor

Probablity

Effects

Tolerable
Tolerable
Tolerable
Insignificant
Catastrophic
Serious
Serious
Tolerable
Serious
Tolerable