CS223Introduction to Software Engineering Software Development Team Project

c 2005, Department of Computer Science University of Warwick Handed out: Wednesday 26 October 2005

Abstract This document species the team project for the academic year 2005/2006, which represents 70% of the assessment for CS223. The aim of this project is to give experience of software design and development within a small group.

Introduction

Candidates taking the Introduction to Software Engineering module (CS223) are required to undertake a Team Project. In the Autumn Term all that is required of candidates is the formation of a team. The bulk of the work will be undertaken in the Spring Term. Teams will be required to submit two reports: one detailing project planning, requirements, and an initial analysis of the problem, the other an overall report containing detailed analysis and design, as well as the user manual. Teams will also have to submit the source of their system to be tested and assessed. The objectives of the Team Project are to test the following skills: Team working Programming in Java Use of appropriate data structures and algorithms Use of modern object-oriented modelling and design tool (UML) Design of exible and reusable software Systematic and comprehensive testing of software Writing of clear and precise documentation Above all, the purpose of the Team Project is to enable candidates to exhibit professional software engineering skills in the design, management and production of a substantial software system. The rest of this document outlines in detail the Team Project for the academic year 2005/2006. Additional information may be posted to the module web-page, accessible at the URL: http://www.dcs.warwick.ac.uk/people/academic/Doron.Peled/course/cs223/ Each team is expected to check the web-page daily. 1

Requirements

The software product required is a Car Rental Information System.

Car Fleet
You will be provided with a le detailing the eet of the agency, which the system should read in. The le will be accessible from the module web page, and will contain records in the following format: Car Model Car Type Price 1 Price 2 Number Available

Car Model: This represents the model of the car, e.g., VW Golf, BMW etc Car Type: This represents the type of the car, e.g., BMW Sport, BMW Touring, VW Golf GTI etc. Price 1: This indicates the price per day for a driver with a British Licence. Price 2: This indicates the price per day for a driver with a non-British licence. Number available: This indicates the number of vehicles owned by the agency. Here are some possible entries from the le: BMW 318 40GBP 60GBP 4 BMW 320 50GBP 70GBP 2 VW Golf1.6 30GBP 50GBP 6 VW GolfGTI 35GBP 55GBP 3

2.1

Top Level GUI

The top level interface of the system should look like that in Fig. 1, which shows that the system will need to handle 3 dierent views of the system.

Customer OK Agent

Manager

Figure 1: Top level GUI for the system.

Graphical User Interface

The graphical interface for a customer (i.e., when the customer button is clicked) is intended to capture values for various variables that are of importance. The variables are: Car model: This represents the model of car that the current customer wants. It is to be implemented as a drop box, with all car models available. Car type: This represents the type of the car the customer wants. This is to be implemented as a drop box. The content of the drop box will only present car types that are relevant with the model chosen. For example, if the customer chose BMW, the drop box should only contain 318, and 320. Licence: This represents whether the customer has a British or International licence. B will stand for British licence and I for international licence. Number of days: This represents the number of days the customers wishes to hire the car for. First day of rental: This represents the day the rental agreement starts. The format of the date should be dd/mm/yy. Time of booking: This represents the time the customer is booking a car. The format of the time should be dd/mm/yy:hh:mm (time is recorded in 24-hour format). A snapshot of the GUI is as follows:

Car Rental Information Systems Car Model First Day of rental

Car Type

Number of days

Licence

International UK Licence

Time of booking

OK

Cancel

Figure 2: GUI for Customer View

Perspectives
The system will need to provide three dierent perspectives of the business, namely (i) a customer view, (ii) a agent view, and (iii) a manager view.

Customer View
The customer view will allow a customer to identify a car, and book it. The information the customer has to enter is: (i) Model of car, (ii) type of car, (iii) duration of rental, and (iv) Licence, (v) First day of rental, and (vi) time of booking. The GUI is as in Fig. 2. If the booking cannot be satised, an error message will be reported stating Booking impossible. The process is repeated until the search is successful, where a message Booking successful is output. When a search is successful, a window with a summary of the booking details, containing (i) car model, (ii) car type, (iii) number of days booked for, (iv) rst day of rental, (v)total cost, and (vi) the time of booking is displayed with an OK button for conrming the booking, and a cancel button for cancelling the search.

Agent View
An agent view will have a similar GUI as the customer, and will only dier from a customer view in having the following additional features: All Car back: When this button is clicked, it returns a list of cars that are due back on the same day. So, if a customer wants to rent a car, and is unsuccessful, an agent can notify the customer of the future availability of cars during the same day. Model Car back: When this button is clicked, a window pops up with a drop box holding all the models of cars owned by the company. The model of the car is selected and a list of cars for that model is returned together with their return dates.

Manager View
The manager view will allow an oce manager to perform the following functions: Money in: When this button is clicked, a window appears with a From Date text box, and a To Date text box. When the information is entered, it allows a manager to view the amount of money the company made from From Date to To Date. Popular cars: When this button is clicked, it allows a manager to view what cars are popular. It ranks the types of cars according to their popularity based on their number of rentals for the time period From Date to To Date. Report: When this button is clicked, a window pops up, with a From Date text box, and a To Date text box. The result is a summary of the rentals of cars belonging to the company from From Date to To Date. The elds in the summary report are: (i) Model of car, (ii) Type of car, (iii) Number of rentals, (iv) Total duration of the rentals, (v) total price, and (vi) Number of Licenses of each type.

Testing
When an agent or customer enters the rental information for a car, the information is entered into a data le (see next section). The le will contain all the rentals from a given date onwards. For testing purposes, the system should be able to work directly on such a le, without having to input values from the GUI. Hence, the system will run in dual mode , (i) in normal mode, or (ii) in testing mode. In normal mode, when the system is run, the top level GUI appears. On the other hand, in testing mode, no GUI is shown and the system prompts for a lename containing a list of rental requests. Also, every function available in normal mode is expected to be present in testing mode, i.e., every function available in each view should work in testing mode also. The system will be tested with a given set of test cases that will be provided at a later date. If the system passes these tests, the system will be deemed correct, and further testing will not be required.

Data File
The data le will contain details of rentals from a given date onwards. The data le in the system will have the following format: Car Model Car Type Licence Price/Day First day of rental Number of days rented Time of booking

Constraints

The following constraints must be observed by every team without exception. 1. The system must be implemented in its entirety using the Java programming language. You MUST NOT use a relational database. 2. The source must compile on Warwick University Computer Science (DCS) Linux machines. You may develop the system on any machine, but the nal program you submit must run on DCS Linux machines. 3. You should use only classes from the standard Java class libraries in the Java 1.4.2/1.5 distribution as installed on the DCS Linux machines. No other external class libraries are allowed.

Suggested Schedule

Here is a suggested schedule to help your team deliver a high-quality project.

Week Week Week Week

11 12 13 14

Week 15 Week 16 Week 17 Week 18 Week 19 Week 20

Project Planning Requirements (Use Case Diagrams) Initial Problem Analysis (both Static and Dynamic) Complete Planning, Use Case Models, & Initial Analysis Models produce Part A submission document First Iterative Analysis, Design, Coding in Java, Testing and Debugging Review the development, and the distribution of work among team members Second Iterative Analysis, Design, Coding in Java, Testing and Debugging complete Analysis Models Review the development, and the distribution of work among team members complete Design Models Further Testing and Debugging; System Integration and Testing Complete Implementation and Testing & Preparation of User Manual produce Part B submission document

Deadlines

There are two submission deadlinesone each for parts A and B. Please familiarise yourself with these dates now (write them in your diary!). Part A: Part B: 12 noon on Thursday 26 January, 2006 (week 14) 12 noon on Thursday 09 March, 2006 (week 20)

No late submissions will be accepted except under exceptional circumstances and supported by documentation. A team submitting late will be penalised according to University of Warwick regulations.

Deliverables

There will be a single team submission for each part. Each team submission (for both parts) must contain a contribution assessment form for each team member, giving a percentage for the team members contribution to the team deliverables. (Two blank contribution forms are given at the back of this document, but further copies can be obtained from the module web-page.)

6.1

Part A

Each team must submit a Planning, Requirements, and Problem Analysis report. This should contain the following information. The front page should list the team name, number and the names of the team members. The Project Planning, Requirements (Use Case models), and Initial Problem Analysis (Static and Dynamic models). (This should be no longer than twenty sides of A4.) The minutes of the Team meetings for this part. A Team Contribution Form, signed by all members of the team. Your team should keep a copy of this documentation. The submitted copy will not be returned to you. 6

6.2

Part B

At the end of the Project, teams must submit the source code of their systems. Submission arrangements will be notied in due course. In addition to the on-line submission, each team will be required to submit a report. This should contain the following information. The front page should list the team name, number and the names of the Team members. A description of how the Team Project was managed, including the allocation of duties. (This should be no longer than ve sides of A4.) The minutes of the Team meetings for this part. The nal Analysis and Design models (UML), including a description of the design decisions made. This should also demonstrate the exibility of the design, and show how the system could be easily expanded and enhanced in the future. (This should be no longer than twenty sides of A4.) The user manual for the system. (This should be no more than six sides of A4.) A completed and signed Individual Contribution Form for each member of the team. To avoid disagreement among team members at the nal submission, a team is encouraged to keep a joint log of the individual contributions when the minutes of the meeting are taken at the team meetings. If problems arise, such logs should be nalised at the teams next meeting with its tutor. (IMPORTANT: No individual contribution should result in a group member failing the project Please note that it is the responsibility of the group as a whole to inform the Tutors of the likelihood of such an eventuality as early as possible, so that appropriate actions could be taken well before the deadline date for Part B.) A Team Contribution Form, signed by all members of the team.

Team Meetings

Managing a software project involves regular meetings to assess the progress of the system and to stop a project failing. All teams are expected to hold regular meetings. A team would be expected to hold at least ve meetings over the term; some teams will hold many more. The minutes of team meetings should be written up immediately after the meeting. The module organisers reserve the right to call teams at short notice to present the minutes of their meetings. Guidance on writing minutes is available on the module web page.

Choosing a Team

The choice of a team is left entirely up to you. Any student not managing to choose a team by the 19th of November will be allocated to one. Some important points concerning the teams are as follows. Every team must consist of no less than 5 and no more than 6 students. It is strongly advised that a team contain no more than one option student (i.e. someone who is not CS, CMS, CSE, CBS).

 An option student who joins a group will be understood to have made a rm commitment to complete the group project. A team is allowed to select a name. However each team will also be given a number. The module organisers reserve the right to add people to teams. Students may nd the CS223 newsgroup a suitable medium to nd team members. A single text message from each team should be e-mailed to Professor D. Peled (Doron.Peled@warwick.ac.uk) before the end of week 8 (Friday 18th November). This should contain: Team Name Team Leader name (Surname, Fore-names) For each team member: name (Surname, Fore-names), degree program (CS, CBS, etc.), University ID, University Email (in the form A.N.Other@warwick.ac.uk), DCS user code Communication to each team will be through the rst-named team member. IMPORTANT: On Wednesday, 30th November the details of the groups will be posted on the module web-page. It is up to each group to ensure that the details are correctany problems must be brought to the attention of Prof. Peled before the end of the autumn term.

D. A. Peled A. Jhumka R. A. Packwood A. Amatya 8