Object Oriented Analysis Project Report

Western-Budget Travel System

Spring, 2012

WESTERN-BUDGET TRAVEL

OBJECT-ORIENTED ANALYSIS REPORT

By

Group: Campus:

Tutor: Tutorial Time:

Student No.	Last Name	First Name

INSTRUCTIONS TO STUDENTS:

FOR YOUR FINAL PROJECT REPORT

· USE THIS DOCUMENT AS A STARTING POINT TO FORMAT YOUR REPORT

· YOU MUST MODIFY/IMPROVE ON THIS DOCUMENT FORMAT PROVIDED TO IMPROVE YOUR OVERALL PROJECT PRESENTATION

· THE PROBLEM STATEMENT FOR YOUR CASE STUDY IS INCLUDED IN THIS DOCUMENT. YOU MAY FURTHER MODIFY THE PROBLEM STATEMENT TO SUIT YOUR OWN UNDERSTANDING OF THE CASE STUDY

· THE HEADINGS GIVEN IN THIS PROJECT REPORT CORRESPOND TO MOST OF THE PROJECT WORK REQUIREMENTS GIVEN AT THE END OF EACH CHAPTER OF THE “PRACTICAL OBJECT ORIENTED ANALYSIS”BOOK. THESE HEADINGS WILL ENSURE YOU HAVE NOT MISSED ANY MAJOR DELIVERABLES.

· HOWEVER, YOU ARE WELCOME TO CHANGE THE SEQUENCE AND ADD/MODIFY THE HEADINGS IN THIS REPORT

· ENSURE YOU COMPLETE THE COVER PAGE CORRECTLY WITH YOUR GROUP NAME; ALSO CHANGE THE HEADER/FOOTER WITH YOUR GROUP NAMES AND DETAILS

· SPELL-CHECK YOUR REPORT THOROUGHLY

· ENSURE YOUR REPORT DOES NOT CONTAIN ANY THEORY – THIS IS A PRACTICAL PROJECT REPORT SO NO THEORY (SUCH AS “WHAT ARE OBJECTS”) SHOULD APPEAR ANYWHERE ON THE REPORT

· DELETE THIS INSTRUCTION PAGE AND OTHER INSTRUCTIONS IN THIS REPORT AFTER YOU HAVE READ THEM

Table of Contents

History of Document Revision.4

1 Executive Summary.5

2 Introduction.5

2.1 Purpose of the document5

2.2 Dictionary of Terms and Acronyms.5

3 Case Study for Project Work.6

4 Major Business Function Areas.9

5 Scope.9

6 Package Diagrams.9

7 Actor List and Documentation.9

7.1 Actor: A01-9

8 Use cases.10

8.1 Use Case “BPAYofAVISACard”.10

9 Use Case Diagrams.12

10 Activity Diagrams.12

11 Use Case Categorisation and Ranking, includes:12

12 Class Descriptions.12

13 Class Diagrams.12

14 Interaction Overview Diagrams.13

15 Sequence Diagrams.13

16 State Machine Diagrams.13

17 Prototypes (and User Interfaces)13

17.1 Screen Specifications.13

17.1.1 Login Screen.13

17.1.2 Traveller Screen.14

17.1.3 Enquiry Screen.15

17.1.4 Payment Screen.16

17.1.5 Administration/Staff Screen.17

18 Operational (Non-Functional) Requirements.18

18.1 Performance.18

18.2 Volume.18

18.3 Scalability.18

18.4 Security.18

19 Environmental Considerations.18

19.1 Test Environment19

19.2 Operational (Deployment) Environment19

19.3 Additional Environmental Considerations.19

20 Quality Assurance (Quality Plans)19

21 Test Designs.19

22 Testing Plan.19

22.1 Test Cases.19

23 Project Management21

23.1 Standard, Methodology & Techniques.21

23.1.1 Standards.21

23.1.2 Metrics.21

23.2 Project Plans.23

23.2.1 Work Plan.23

23.2.2 Roles & Responsibilities.23

23.3 Project Time Management24

23.3.1 High Level Tasks.24

23.3.2 Project Plan – Task List24

23.4 Project Minutes Of Meetings.26

23.4.1 Minutes of the Project Team Meeting of 1/1/2004.26

24 Appendix.27

25 References.27

History of Document Revision

Version	Released On	Description of Major Revision	Person Responsible
1.0

1 Executive Summary

2 Introduction

2.1 PURPOSE OF THE DOCUMENT

2.2 DICTIONARY OF TERMS AND ACRONYMS

3 Case Study for Project Work

• FOLLOWING IS A HYPOTHETICAL PROBLEM STATEMENT FOR WESTERN-BUDGET TRAVEL – A HYPOTHETICAL TRAVEL COMPANY.
• THIS PROBLEM STATEMENT IS PURPOSEFULLY KEPT INCOMPLETE REQUIRING YOU TO CONDUCT DETAILED ANALYSIS AND DOCUMENTATION TO COMPLETE THEM
• YOU ARE WELCOME TO MODIFY THIS PROBLEM STATEMENT (WITH AN AGREEMENT FROM YOUR TUTOR).
• EACH STUDENT SHOULD BE ALLOCATED A PACKAGE TO WORK INDIVIDUALLY SUCH AS: ONLINE BOOKING, ONSITE BOOKING, RESOURCE MANAGEMENT AND ASSOCIATED BUSINESSES. PACKAGE EMERGING TECHNOLOGIES AND OTHER COMMON SECTIONS SHOULD BE DONE BY ALL GROUP MEMBERS.
• IF A GROUP HAS FEWER THAN FOUR MEMBERS, WORKLOAD SHOULD BE REDUCED CORRESPONDINGLY (I.E. NUMBER OF INDIVIDUAL PACKAGES) WITH CONSULTANT(S) AND AN AGREEMENT FROM YOUR TUTOR/LECTURER.
• REMOVE THIS INSTRUCTION AT THE FINAL REPORT.

Western-Budget Travel – Problem Statement

“Western-Budget Travel” is a typical Small to Medium Enterprise (SME) that is employing around 40 people and has a turnover of approximately $15 Million per year. The company also has 3 branches at three suburbs: Campbelltown, Parramatta and Penrith. The Head Quarter and the Human Resource Department are also located in the same location at the Parramatta’s branch.

The current business is using a simple informative website, 3 workstations (1 workstation at each branch), 30 desktops, 15 laptops and 8 network printers that are all connected using a small Local Area Network (LAN) in the office. The data and business transactions are currently stored as static files at the workstations. Unfortunately, there is currently no interconnection among the workstations at the three branches. The communication between the branches is done via telephones. The data is currently stored at the servers and the backup is regularly done using CD/DVD.

The brief requirement of this project is to develop an Internet-based software solution that will handle all business aspects of the Western-Budget Travel, such as online travel booking, onsite booking, resource management, and associated businesses. The consulting group is required to provide a full document of the requirements of Western-Budget Travel firm, for their e-travel business and new management platform. This new system will be required to use Object Oriented Techniques which will be documented using the Unified Modelling Language (UML version 2.0). The decision of technology should be used for implementation is either .NET or J2EE. Your object oriented analysis report should justify the reason (advantage and disadvantage) of using your selected technology in this project. All the data and business transactions must be stored in databases for better management and retrieval. It is also a requirement to analyse the cost and technical feasibility to connect all the three workstations at the branches together. Finally, automated backup solution is also required in this project. The team should consider the important operational issues of robustness, scalability, security, performance and others in the analysis.

Based on the early analysis, the requirements of the new system (but not limited to) are:

Online Travel Booking – Online Travel booking can be done via Internet by travel customers. Western-Budget Travel hopes that their transformation to e-travel system will help them deal with at least the following markets:

• Student travel – especially with the increasing student traffic between Asia and Australia
• Business travel – especially with the increasing business traffic between Europe, Americas and Australia
• Leisure travel – especially with the incoming touring traffic.

The web system allows a customer to add new bookings (including flight/date selection), view available bookings and other functions. The customer must log onto the system before booking a travel. If a customer is not registered, the system allows the customer to register online. The required information includes username, password, title, full name, address, credit card information, and others. Cash payment is not allowed for online travel booking.

Onsite Booking Management – the system allows Western-Budget Travel’s staffs to add new bookings, view and modify available bookings, register a new customer and perform other functions. The interface and function at onsite booking system might be different from the online version. The onsite booking management system works locally using company PCs and Laptops by authorised staffs and managers. This booking system will be developed from the available system. A staff must log onto the system before he/she can use it. When the staff has logged onto the system, he/she can carry out the tasks for multiple customers.

Resource Management – Western-Budget Travel would also like to upgrade its internal business processes to a new level, including:

• Human Resource (HR) Management – adding/maintaining employees personal records (e.g. information, salary, degree, skills, etc), work schedule of employees, leave and leave balances,
• Records of cash flow (e.g. Income and expense for a daily period basic),
• Submission of taxes (e.g. GST) to the government – electronically,
• Profit and loss analysis on an ongoing basis.

All information can be accessible from anywhere by managers and/or authorised accountants via the secured internet or the internal LAN.

Associated Businesses – The managers also realise that their technology-based approach is likely to provide opportunities for Western-Budget Travel to form allianceswith associated businesses as well as interact with government agencies including:

• Airlines – in bookings and purchasing of tickets from various airline companies; booking of tour packages or conferences; special deals, etc,
• Hotels – enabling clients to book packages (with good deals) with various hotels around the world,
• Car rentals – coordinating with car rentals companies to book a car,
• Other travel agencies (especially overseas large travel agencies),
• Government agencies and websites to handle and preferably automate the numerous legal and visa requirements

Emerging Technologies – in addition, in the vision of fast growing emerging technologies, the managers are keen to utilise these technologies for the booking and marketing purpose. Therefore, they are looking for the analysis of business processes that make use of mobile technologies (such as smart phones and tablet computers) in cooperation with the online system. And thus, the interface must be adjusted and simplified to the small screens. The management believe that this will increase the customer’s accessibility. An mobile application (for iOS, Android and Windows Mobile) should be considered in the analysis.

End of Problem Statement

4 Major Business Function Areas

(Based on CRA)

Feasibility Study, includes:

Cost/Benefit Analysis

Budget

Technical Feasibility (Software, Hardware, OS etc) through prototypes

Operational Feasibility (Generic team experience, client limitations, basically SWOT Analysis)

Timeframe Feasibility (including lag-time)

5 Scope

(Mention here what is included and what is left out)

6 Package Diagrams

(Prioritise them)

7 Actor List and Documentation

THIS IS AN EXAMPLE OF AN ACTOR DOCUMENTATION FOR AN INSURANCE SYSTEM. YOU CAN DOCUMENT YOUR ACTORS IN GREATER DETAIL FOR YOUR PROBLEM STATEMENT.

7.1 ACTOR: A01-

Actor Type & Stereotype

Abstract actor representing any Borrower;

Actor Description

Actor Relationships

Three different types of concrete Actors are derived from this Actor:

A02-Personal Borrower

A03-Small Business Borrower

A04-Large Corporate Borrower

Interface Specifications

UI010_Loan_Application_Form

UI320_Web_Loan_Tracker

Author & History

Mark Douce

Reference Material

Rules related to Borrowers can be seen on the Bank’s Intranet, and are being documented in file loansBLSBorr.doc

8 Use cases

THIS IS AN EXAMPLE ONLY OF A USE CASE IN A BANKING CREDIT CARD SYSTEM. YOU NEED TO CREATE SIMILAR USE CASES FOR YOUR SYSTEM, BUT WITH GREATER DETAILS DURING ANALYSIS WORK.

8.1 USE CASE “BPAY OF A VISA CARD”

Use Case:	BPAY of Visa Card
Actors:	Customer
Description:	Customer makes BPAY payment of his/her outstanding Visa Card balance
Pre-Condition:	Account from which payment is to be made, and the Visa card account exists (optionally, logging in of customer can also be added here)
Post-Condition:	Issue of notification
Type:	Complex
Normal Course of Events:	1. Customer identifies himself/herself. 2. System verifies identification (A1) 3. Customer indicates desire to BPAY 4. System provides BPAY options 5. Customer specifies Bill Payee and Customer Reference 6. Customer specifies Amount to be paid 7. Customer specifies Date on which Amount is to be paid 8. System verifies these BPAY details (A2) 9. System accepts Payment 10. System notifies Customer of the Receipt Number 11. Customer Records Receipt Number 12. Customer Logs out of the system
Alternate Course of Events:	A1: Invalid customer, notified accordingly A2: Invalid and/or insufficient details. System notifies Customer accordingly, and provides another chance to re-enter details.
References	Name of Author; Additional references to other documents.

Use Case:
Actors:
Description:
Pre-Condition:
Post-Condition:
Type:
Normal Course of Events:
Alternate Course of Events:
References	Name of Author; Additional references to other documents.

9 Use Case Diagrams

10 Activity Diagrams

11 Use Case Categorisation and Ranking, includes:

Determine criteria for categorising and ranking use cases

Rank use cases

List of ranked use cases

Reasons for ranked use cases

12 Class Descriptions

13 Class Diagrams

14 Interaction Overview Diagrams

15 Sequence Diagrams

16 State Machine Diagrams

17 Prototypes (and User Interfaces)

17.1SCREEN SPECIFICATIONS

Only the layout of the screens is important from a requirements/usability viewpoint. The screens themselves need not be designed during this stage. The following screen headings are examples only… students are required to create their own screen names and layouts and specify them here.

17.1.1Login Screen

17.1.2Traveller Screen

17.1.3Enquiry Screen

17.1.4Payment Screen

17.1.5Administration/Staff Screen

18 Operational (Non-Functional) Requirements

18.1PERFORMANCE

18.2VOLUME

18.3SCALABILITY

18.4SECURITY

19 Environmental Considerations

The development will take place on DELL Pentium III E 1 GHz, under Windows XP Professional Build 2600.xpsp1. & Windows 2003 Server (Build 3790)

Following is a list of the software to be used:

Analytical & Design Tools:

Implementation Tools:

• Microsoft Visual Studio. NET 2005 Professional
• Sun Java 1.6 (J2EE Server)

Following is a list of the languages to be used, but not limited to:

• Javascript 1.4
• C# or Java (including JSP, Javaservlet and JavaBeen)
• ASP.NET
• HTML, CSS

19.1TEST ENVIRONMENT

Refer to test plans…

19.2OPERATIONAL (DEPLOYMENT) ENVIRONMENT

19.3ADDITIONAL ENVIRONMENTAL CONSIDERATIONS

20 Quality Assurance (Quality Plans)

21 Test Designs

22 Testing Plan

22.1TEST CASES

<<USE THIS AS A TEST CASES TEMPLATE. MODIFY AS NEEDED>>

Identification: Test Case HMS1.1 User Authentication Use case

Purpose: To check if user authentication works successfully.

Prerequisites: User name and password from User Access Profile which

would be stored in the HMS Database.

Administrative Details: System Analyst, System Programmer

Input	Actions	Expected Output	Actual Output

<<AN ALTERNATIVE TEST CASE FORMAT. YOU MAY CHOOSE ONE OR COMBINE BOTH THE FORMATS GIVEN HERE… OR CREATE YOUR OWN>>.

Test Design:		Testing Usecase / Class		Tester:		Date:

Description:

Test Case	Interface	Input		Outcome	Actual

23 Project Management

23.1STANDARD, METHODOLOGY & TECHNIQUES

23.1.1Standards

23.1.2Metrics

Metrics are used to measure various aspects of the Analysis and Design. They provide the ability to capture and track the progress of various process-components within a project. At management level, the costs, people, quality and other resources can be tracked.

Category	Measurement (How)	Metric (What)

Table 1Measurements

23.2PROJECT PLANS

23.2.1Work Plan

The plan outlines the allocation of time for the high level task and the staff they require.

Note: Due to staffing fluctuations, if a particular person is unable to fulfil his/her responsibilities, it will be the responsibility of the manager overseeing that area to ensure a replacement, with appropriate skills and experience, on a timely basis outlined in the Manpower Plan. The project plan will allow minimum lag time of 1day maximum allocation of 2 days for critical tasks that require existing knowledge of the system.

23.2.2Roles & Responsibilities

• Project Manager– Responsible for daily planning and control of the project.
• Business Analyst
• User Representative
• Quality Analyst
• Testers –
• TechnicalWriters

23.3PROJECT TIME MANAGEMENT

23.3.1High Level Tasks

23.3.2Project Plan – Task List

MS Project Plan based on Process-components provided in “Process-QA for UML-based Projects” book

ENSURE THIS PROJECT PLAN IS ITERATIVE AND INCREMENTAL IN NATURE. THEREFORE, YOU MUST SHOW REPETITION OF ACTIVITIES AND TASKS.

23.4PROJECT MINUTES OF MEETINGS

<<IF PROJECT TEAMS ARE HAVING INTRA-GROUP ISSUES, THEY SHOULD ALSO BE RECORDED HERE. PLEASE NOTE: IT IS NOT THE RESPONSIBILITY OF THE LECTURER/TUTOR TO FULLY SOLVE PERSONALITY PROBLEMS WITHIN THE GROUPS. ALTHOUGH SOME HELP/SUGGESTIONS WILL BE PROVIDED>>

23.4.1 Minutes of the Project Team Meeting of03/02/2008

Meeting No:1 Held at:Parramatta Lab / Campus library / etc.

Chairperson: Chun Ruan

Team members in attendance: Michael Turk, Ron Schmid, Jamie Yang

Minutes taken by: Chun Ruan

Agenda items discussed:

1. Interpretation of the case study e-Travel Management System …………….

2. Discovering Initial Use cases………………….

Action Plan:

Item	Description	Who	When	Initial

Agenda for Next Meeting:

Next meeting will be held at 11/3/2008, Tuesday, at xyz Coffee shop. Tentative agenda items include:

Acceptance of minutes:

Chun Ruan _______________________

Michael Turk _______________________

Ron Schmid _______________________

Jamie Yang _______________________

24 Appendix

25 References

INSERT YOUR REFERENCE HERE.

Fowler, Martin’s UML Distilled, 3^rd Edition,is a good readable book and should be referred to in addition to the course material, Addison-Wesley, 2003

Unhelkar, B., Process Quality Assurance for UML-based Projects,contains detailed discussion on the process aspect of quality. Chapter 1 for UML-based models, Chapter 3 for relevant process components, and Chapter 6 for testing are quite relevant.

Booch, G., et al, 1999, The UML User Guide, 1999,Addison-Wesley, is a substantial text and should be occasionally referred to, when students (especially teams) are looking for additional and in-depth material on a particular topic

Quatarani, Terry., Visual Modelling with Rational Rose 2000 and UML

IBM Rational Developer Network

www.OMG.org

Our website has a team of professional writers who can help you write any of your homework. They will write your papers from scratch. We also have a team of editors just to make sure all papers are of HIGH QUALITY & PLAGIARISM FREE. To make an Order you only need to click Ask A Question and we will direct you to our Order Page at WriteDemy. Then fill Our Order Form with all your assignment instructions. Select your deadline and pay for your paper. You will get it few hours before your set deadline.