Software Engineering

2016
Sample Assignment 1

Tutors Name: Sumera Saleem Team Members:

Group Number: Casey Acworth 1408157
Number of Errors Found Marshall Allen 1411344
Before First Compile: Uday Pathak 1695944
After First Compile: Mark Pickersgill 1170261
Lines of code: Michal Zajac 1576784

Project Schedule

Phase Expected Actual Est. Time Actual Member(s)

Completion Completion to Time Responsible
Date Date complete Taken
(hrs) (hrs)
Planning Mon. 26/03/01 Tue. 27/03/01 7.5 6 All

Requirements
Development Thur. 29/03/01 Thur. 29/03/01 10 9 Casey, Mark
Validation Fri. 30/03/01 Fri. 30/03/01 7.5 7.5 Marshall, Michal, Uday
Correction Fri. 30/03/01 Fri. 30/03/01 8 4 Casey, Mark

Design
Development Mon. 02/04/01 Fri. 06/04/01 13.5 15 Uday, Michal, Marshall
Verification Tue. 03/04/01 Fri. 06/04/01 8 7.5 Casey, Mark
Correction Tue. 03/04/01 Fri. 06/04/01 7.5 5 Uday, Michal, Marshall

Implementation
Development Fri. 06/04/01 Sat. 07/04/01 12.5 13 All
Verification Fri. 06/04/01 Sun. 08/04/01 7.5 6 All
Correction Sat. 07/04/01 Mon. 09/04/01 7.5 3.5 All

Testing
Development Sun. 08/04/01 Mon. 09/04/01 6 8.5 Michal, Marshall
Verification Mon. 09/04/01 Mon. 09/04/01 3 2 Uday, Casey, Mark
Response Tue. 10/04/01 Mon. 09/04/01 4 1.5 Michal, Marshall

Project Analysis Tue. 10/04/01 Tue. 10/04/01 5 9.5 All

 Contents
1. Project Planning.........................................................................................................................1
1.1. Project Overview..................................................................................................................2
1.2. Project Productivity..............................................................................................................2
1.3. Summary of Project Costing and Progress Reporting..........................................................3
1.4. Project Schedule...................................................................................................................4
1.5. Project Task List...................................................................................................................5
2. Requirements..............................................................................................................................6
2.1. Requirement 1......................................................................................................................7
2.1.1. Original Problem Statement (PS1)...............................................................................7
2.1.2. Problem Statement Analysis........................................................................................7
2.1.3. Rewritten Requirement (RR1)......................................................................................7
2.1.4. Assumptions.................................................................................................................7
2.2. Requirements Inspection......................................................................................................8
2.2.1. Requirements Moderator’s Report...............................................................................8
2.2.2. Requirements Inspector’s Report.................................................................................9
2.3. Functional Requirements Validation..................................................................................10
3. Design........................................................................................................................................12
3.1. High Level Design..............................................................................................................13
3.2. Detailed Design..................................................................................................................13
3.2.1. Low Level Design 1 – Car Park (LLD1)....................................................................13
3.3. Design Inspection...............................................................................................................15
3.3.1. Moderator’s Report....................................................................................................15
3.3.2. Inspector’s Report......................................................................................................16
3.4. Design Verification............................................................................................................17
3.4.1. High Level Design to Functional Requirements........................................................17
4. Implementation.........................................................................................................................18
4.1. Java Source Code...............................................................................................................19
4.1.1. Car Park View – CarParkView.java...........................................................................19
4.1.2. Moderator’s Report....................................................................................................20
4.1.3. Inspector’s Report......................................................................................................21
4.2. Implementation Traceback and Verification......................................................................22
5. Testing.......................................................................................................................................24
5.1. Testing: Own Program.......................................................................................................25
5.1.1. Valid Test Cases.........................................................................................................25
5.1.2. Invalid Test Cases......................................................................................................26
5.2. Test Case Inspection...........................................................................................................26
5.2.1. Moderator’s Report....................................................................................................26
Inspector’s Report......................................................................................................................27
5.2.2. Test Cases to Functional Requirements.....................................................................28
6. Error Analysis...........................................................................................................................29
6.1. Defects Summary...............................................................................................................29
6.2. Defect Analysis..................................................................................................................29
6.2.1. Requirements..............................................................................................................29
6.2.2. Design.........................................................................................................................29
6.2.3. Implementation...........................................................................................................29
6.2.4. Test Cases...................................................................................................................29
7. Project Analysis........................................................................................................................30
7.1. Analysis of project 1...........................................................................................................31
7.1.1. Problems Encountered................................................................................................31
 7.1.2. Lessons.......................................................................................................................31
7.1.3. Suggestions.................................................................................................................32
7.1.4. Measurements.............................................................................................................32
8. Bibliography...............................................................................................................................33
 1. Project Planning
Members Responsible For: -

Project Management: Ali

Development: All

Verification: All

Correction: All

Errors Found: 0

Time to Complete: 6 hrs

Car Park System 1

 Planning

1.1. Project Overview

A software system is to be developed to control the operations of a Car Park system. The operation
of this system includes the control of entry and exit of vehicles and charging the appropriate amount
for the time the vehicles have been in the car park.

The system is to be designed so that it uses components that can later be re-used in other projects.

1.2. Project Productivity

At the outset of the project, the overall estimated time to complete each phase was divided up
equally between the team members responsible for the tasks in that phase. During the project, each
team member was responsible for keeping track of the time they took to complete their tasks. On
completion of the project, each team member’s timesheets were collected, entered into the table
below, and for each task, the individual times were combined to give the total person hours and
total cost spent on each of the phases. The following table summarises the individual and group
effort for each phase in the project.

Phase Ali Usman Uday Mark Michal Combined Combined

Pathak Pickersgill Zajac Time Cost

Est. Act. Est. Act. Est. Act. Est. Act. Est. Act. Est. Act. Est. Act.
Planning 1.5 1 1.5 1 1.5 1 1.5 2 1.5 1 7.5 6 225 180

Requirements
Development 5 4 2 5 3 10 9 300 270
Verification 1.5 2.5 1 2.5 1.5 1.5 2.5 2 7.5 7.5 225 225
Correction 4 4 4 8 4 240 120

Design
Development 4.5 4.5 4.5 3 4.5 7.5 13.5 15 405 450
Verification 4 2.5 0.5 4 4 0.5 8 7.5 240 225
Correction 2.5 2 2.5 2 0.5 2.5 0.5 7.5 5 225 150

Implementation
Development 2.5 2.5 2.5 6 2.5 1.5 2.5 1.5 2.5 1.5 12.5 13 375 390
Verification 1.5 1 1.5 1 1.5 1 1.5 1 1.5 2 7.5 6 225 180
Correction 1.5 1.5 3 1.5 1.5 1.5 0.5 7.5 3.5 225 105

Testing
Development 2 3 1.5 0.5 3 4.5 6 8.5 180 255
Verification 1 1 1 0.5 1.5 3 2 90 60
Response 2 2 1.5 4 1.5 120 45

Project Analysis 1 5.5 1 1 1 1 1 1 1 1 5 9.5 150 285

Total 22 20 23 22 19 12.5 22 19.5 23 24 108 98 $3,225 $2,940
Cost rate ($/hour): 30
Est = Estimated time in hours, Act = Actual time in hours

Total person hours to complete the project: 98

2 Car Park System

 Planning

1.3. Summary of Project Costing and Progress Reporting

The following table is a progressive review of the project at particular review dates.

Review Date Est. Cost Act. Cost Earned Time

(to date) (to date) Value (to Behind
date) (hrs)
Thur. 29/03/01 $525 $450 $525 0
Fri. 30/03/01 $990 $750 $893 3.75
Mon. 02/04/01 $1,395 $1,020 $1,193 6.75
Tue. 03/04/01 $1,860 $1,320 $1,515 11.5
Fri. 06/04/01 $2,460 $1,620 $1,860 20
Sat. 07/04/01 $2,685 $1,845 $2,048 21.25
Sun. 08/04/01 $2,865 $2,265 $2,573 9.75
Mon. 09/04/01 $2,955 $2,580 $2,955 0
Tue. 10/04/01 $3,225 $2,940 $3,225 0

Projected cost (estimated cost at completion date) = $3,225

Actual cost (estimated cost at completion date) = $2,940
Lines of code: 363 (excluding comment lines)
Cost per line of code: $8.09/LOC

Car Park System 3

 Planning

1.4. Project Schedule

Phase Expected Actual Est. Time Actual Member(s)
Completion Completion to Time Responsible
Date Date complete Taken
(hrs) (hrs)
Planning Mon. 26/03/01 Tue. 27/03/01 7.5 6 All

Requirements
Development Thur. 29/03/01 Thur. 29/03/01 10 9 Casey, Mark
Validation Fri. 30/03/01 Fri. 30/03/01 7.5 7.5 Marshall, Michal, Uday
Correction Fri. 30/03/01 Fri. 30/03/01 8 4 Casey, Mark

Design
Development Mon. 02/04/01 Fri. 06/04/01 13.5 15 Uday, Michal, Marshall
Verification Tue. 03/04/01 Fri. 06/04/01 8 7.5 Casey, Mark
Correction Tue. 03/04/01 Fri. 06/04/01 7.5 5 Uday, Michal, Marshall

Implementation
Development Fri. 06/04/01 Sat. 07/04/01 12.5 13 All
Verification Fri. 06/04/01 Sun. 08/04/01 7.5 6 All
Correction Sat. 07/04/01 Mon. 09/04/01 7.5 3.5 All

Testing
Development Sun. 08/04/01 Mon. 09/04/01 6 8.5 Michal, Marshall
Verification Mon. 09/04/01 Mon. 09/04/01 3 2 Uday, Casey, Mark
Response Tue. 10/04/01 Mon. 09/04/01 4 1.5 Michal, Marshall

Project Analysis Tue. 10/04/01 Tue. 10/04/01 5 9.5 All

The table on the following page lists the tasks for each phase, and who was initially responsible.
Throughout the course of the Project, the tasks were assigned different people due to workload or
other commitments.

4 Car Park System

 Planning

1.5. Project Task List

Project Schedule Mark
Requirements (Document) Mark
Original Problem Statements Casey
Problem Statement Analysis Casey
Problem Statement Assumptions Casey
Rewritten Requirements Mark
Functional Requirement Mark
Req. Inspection Preparation (Producers) Mark/Casey
Req. Inspection Individual Inspector Reports * Marshall/Michal/Uday
Req. Inspection Moderator & Moderator Report Uday
Req. Inspection Inspector Report Marshall
Req. Traceback & Validation Michal
Design (Document) Marshall
Flowcharts Marshall
Design Inspection Preparation (Producers) Marshall/Uday/Michal
Design Inspection Individual Inspector Reports * Mark/Casey
Design Inspection Moderator & Moderator Report Casey
Design Inspection Inspector Report Mark
HLD to Functional Requirements Traceback Casey
LLD to HLD Traceback Mark
Implementation (Document) Uday
Coding of Classes All
Implementation Inspection Preparation (Producers) All
Imp. Inspection Individual Inspector Reports * All
Imp. Inspection Moderator & Moderator Report Michal
Imp. Inspection Inspector Report Uday
Imp. Traceback & Verification Mark
Testing (Document) Michal
Development of Valid Test Cases Michal
Development of Invalid Test Cases Michal
Testing Inspection Preparation (Producers) Michal/Marshall
Testing Inspection Individual Inspector Reports * Uday/Casey/Mark
Testing Inspection Moderator & Moderator Report Mark
Testing Inspection Inspector Report Uday
Testing Traceback & Verification Uday
Testing of OUR program Michal
Testing of Another group's program Marshall
Commenting on test results FROM another group Marshall
Error Analysis (Document) Casey
Error Summaries Casey
Error and Error Removal Measurements Casey
Project Analysis (Document) Casey
Process Improvement Casey/Mark
* signifies that the document is NOT included in the final report

Car Park System 5

 2. Requirements
Members Responsible For: -
Development: Casey Acworth
Mark Pickersgill

Verification: Marshall Allen

Uday Pathak
Michal Zajac

Correction: Casey Acworth

Mark Pickersgill
Marshall Allen

Errors Found: 19

Time to Complete: 20.5

Car Park System 6

 Requirements

2.1. Requirement 1
2.1.1.Original Problem Statement (PS1)
A ticket is issued to each car prior to entry. On each ticket is printed the time of entry, and the
ticket number. As soon as the driver takes the ticket the entry gate opens then closes after the
car enters.

2.1.2.Problem Statement Analysis

 Ticket number range not defined.
 Ticket number may or may not reset at a particular time.
 Action/event that causes ticket to be issued is not specified.
 There is nothing to indicate to the system that a car has entered.
 No precondition.
 ‘prior to entry’ is ambiguous.

2.1.3.Rewritten Requirement (RR1)

When the car park is open and drivers can enter, and if the car park is not at capacity, the
ticket dispenser issues a ticket to each driver when they arrive at the ticket dispenser. On
each ticket is printed the time of entry and a unique ticket number. As soon as the driver
removes the ticket from the ticket dispenser the entry gate opens. When the driver passes
through the entry gate, the entry gate closes. The car park can then allow another driver to
enter.

2.1.4.Assumptions
A1 The ticket number should be unique for each car in the car-park
A2 The ‘unique ticket number’ includes the date and a number that ranges from 0 to
the number of cars that have entered on a particular day.
A3 The time recorded should be 24-hour time.
A4 The system is notified when a driver is at the entry, before the entry gate.
A5 The system is notified when the driver has passed through the entry or exit gate.
A6 The carpark is open when the user starts the system
A7 ‘prior to entry’ means that the driver is at the ticket dispenser.
A9 The driver is assumed to be in a car.
A12 The capacity means 5 cars.
A13 The gates close after the driver passes through.
A15 Entry is not permitted when the car park is at capacity.
A23 A ticket dispenser issues the tickets.
A24 The physical component which notifies the system of when a car is at the entry
gate is unknown, hence this input to the system has been incorporated into the
driver component.
A25 The physical component which notifies the system of when a car has passed
through the entry gate or exit gate is unknown, hence this input to the system
has been incorporated into the driver component.

Car Park System 7

 Requirements
Requirements Inspection

2.1.5.Requirements Moderator’s Report

Moderator's Inspection Report

Project Car Park Date 21/03/01

Moderator Uday Pathak

Inspection Start Time 1:35

Inspection End Time 3:00
Inspection Prep Time 20mins Total Lines or Pages Inspected 12
Inspection Duration 1hr 5 mins

Est. Rework Time 1 hrs

Reworkers Casey, Mark, Marshall
ReInspection Date

Reviewers Uday Producers Mark

Marshall Casey
Michal

Recorder Marshall

Meeting Comments

There was a big discussion about pre-conditions, and how the intergration is going to take place with the current specification
The meeting went pretty well, lots of things were clarified, and the group is starting to see
the big picture.

8 Car Park System

 Requirements

2.1.6.Requirements Inspector’s Report

Inspection Error Log

Project Car Park Control Recorder Marshall Date 30/03/01

Moderator Uday

Review Type Requirements (Req./Des./Code/Doc.)

Location/ Defect Description Category To be Resolution

Line# Resolved Date
by
FR1 Missing arrow after "car entered" state M2 Mark 30-Mar
FR1 can't see question mark W2 Mark 30-Mar
FR1 Driver should have when condition W1 Mark 30-Mar
RR2 Reword first sentence W2 Mark 30-Mar
FR2 Needs, "when driver at exit" followed M1 Mark 30-Mar
by Carpark [car at exit]
FR2 Remove "carpark not empty" W2 Mark 30-Mar
FR1 Remove carpark idle E2 Mark 30-Mar
FR5 Remove carpark idle E2 Mark 30-Mar
FR5 Attendant should be a when condition W2 Mark 30-Mar
FR5 Missing arrow after "carpark [report requested]" M2 Mark 30-Mar
A1,A2 Poor order. Swap them W2 Mark 30-Mar
Assumptions Missing system is notified when driver at exit M2 Mark 30-Mar
A8 Should not count minutes W2 Mark 30-Mar
A12 Don't need E2 Mark 30-Mar
Assumptions Missing, "leaves means that the driver is at exit gate" M2 Mark 30-Mar
A13 Do not need "for testing the system" E2 Mark 30-Mar
Assumptions Needs, "average time each car means average time a M2 Mark 30-Mar
car"
A7 Reword, "prior to entry means that the driver is at the W2 Mark 30-Mar
entry gate"
Asumptions Needs, "a ticket dispensor issues the tickets" M2 Mark 30-Mar

1-Major MT-Maintainability SN-Syntax HF-Human Factor

2-Minor DC-Documentation FN-Functionality OT-Other
M-Missing IO-Input/Output IF-Interface
W-Wrong PF-Performance DA-Data
E-Extra ST-Standards LO-Logic

Car Park System 9

 Requirements

2.2. Functional Requirements Validation

FR RR AS PS Justification
FR1 RR1 A1, A2, A3, A4, PS1  Defines the ticket number range.
A5, A6, A7, A9,  Specifies when ticket numbers are reset.
A12, A13, A15,  Specifies what action/event causes ticket
A23, A24, A25 to be issued.
 Clarifies what indicates to the system
that the car has entered.
 Defines the precondition of when the
ticket can be issued.
 Defines ‘prior to entry’.
FR2 RR2 A2, A8, A9, A10, PS2  Specifies the calculation of money
A20, A21 owed.
 Defines ‘leaves’.
FR3 RR3 A5, A9, A13 PS3  Specifies when the gate closes.
FR4 RR4 A12, A14, A26 PS4  Specifies what the sign displays when
the car park is not at capacity.
 Defines ‘specified capacity’.
 Specifies what the sign displays when
the car park is at capacity.
FR5 RR5 A6, A11, A16, PS5  Defines ‘end of day’.
A17, A18, A19,  Specifies length of time that the report
A22 details.
 Specifies what action/event causes the
report to be requested.
 Defines ‘amount’.
 Specifies where the report is output.
 Defines ‘average time each car’.

The above table verifies and justifies that each of Problem Statements are incorporated into one or
more of the Rewritten Requirements and that the Functional Requirements satisfy the original
problem statements using the listed assumptions.

10 Car Park System

 Requirements

Car Park System 11

 3. Design
Members Responsible For:-
Development: Marshall Allen
Uday Pathak
Michal Zajac

Verification: Casey Acworth

Mark Pickersgill
Marshall Allen

Correction: Marshall Allen

Uday Pathak
Michal Zajac
Mark Pickersgill

Errors Found: 15

Time to Complete: 27.5 hrs

Car Park System 12

 Design

3.1. High Level Design

Identification of all modules.

3.2. Detailed Design

The following tables provide the low level design of the car park system components. The low level
design details the interface methods and interface members for the component. Each component has
one interface method called, process. The method process performs all necessary actions and data
exchange between components.

3.2.1. Low Level Design 1 – Car Park (LLD1)

For the detailed design, the attendant, driver, paid button and report button components have
been absorbed into the car park LLD as symbolic constants. The symbolic constants are what
the graphical user interface class will pass to the car park to represent those components.

Component
Car Park
Description This component models the car park system and handles the main flow of control
for the program. The user interface components of the car park have been
absorbed into this component and are represented as symbolic constants.

Interface Methods
Method Name Parameters Description
process event  The symbolic constants representing events are passed
through this variable.

Car Park System 13

 Design

14 Car Park System

 Design

3.3. Design Inspection

3.3.1. Moderator’s Report

Moderator's Inspection Report

Project Assignment 2 Date 3/4 to 6/4/01

Moderator Casey Acworth

Inspection Start Time 2:27, 4:00, 1:02

Inspection End Time 3:04, 4:20, 1:36
Inspection Prep Time 1h 45 Pages Inspected 24
Inspection Duration 1h 31

Est. Rework Time 2 hours

Reworkers Mark, Mike, Marshall
ReInspection Date none

Reviewers Casey Producers Marshall

Mark Uday
Michal

Recorder Mark

Meeting Comments

Questions raised for Flowgraphs logic

errors were mostly with documenation - particularly the use of new notation concepts

Car Park System 15

 Design

3.3.2. Inspector’s Report

Inspection Error Log

Project Car Park Control Recorder Mark Date 3/04/2001-6/04/2001

Moderator Casey

Review Type Design (Req./Des./Code/Doc.)

Location/ Defect Description Category To be Resolution

Line# Resolved Date
by
Int. Tree Boxes not big enough 2WDC Marshall 4-Apr
Int. Tree Add 'OR' explaination 2MDC Marshall 4-Apr
Requirements Add 'OR' explaination 2MDC Mark 4-Apr
ICN Move '18' down 2WDC Marshall 5-Apr
Requirements Change Ticket Reader output to <ticket data> 1WFC Mark 4-Apr
& Int. Tree Marshall 5-Apr
ICN Swap Carpark[car at entry] & 1WFC Marshall 5-Apr
Carpark ?not at capacity?

CarPark CompRemove 'OR' sign at Carpark[car entered] 2EFC Uday 4-Apr

CarPark CompRemove Carpark[ticket processed] 1EFC Uday 4-Apr
CarPark CompRemove "@" signs 1EDC Uday 4-Apr

Req. & Dev. 'car' is used instead of 'driver' 1WDC Mark 5-Apr
Req./Int. Tree Add 'drivers can exit' and 'drivers can enter' as 2MFN Mark 5-Apr
terminating states
Req./Int. Tree The level of the state changes are not shown ('.') 1MFN Mark 5-Apr
nor are the recursive states ('*')
FR5 & Int. Tree Change Carpark[report requested] to a data out 1WFN Mark 5-Apr
statement.
Int. Tree 4 terminating nodes are not needed 2EFN Mark 6-Apr
Ind. Comp.
Trees Extra nodes not needed 2EFN Michal 6-Apr

1-Major MT-Maintainability SN-Syntax OT-Other

2-Minor DC-Documentation FN-Functionality
M-Missing IO-Input/Output IF-Interface
W-Wrong PF-Performance DA-Data
E-Extra ST-Standards LO-Logic

16 Car Park System

 Design

3.4. Design Verification

3.4.1. High Level Design to Functional Requirements
The table below indicates which architectural components satisfy which functional
requirements and why.

Architectural Functional Justification

Component Requirement
HLD1 FR1, FR2, Models the required behaviour, states and functionality of
FR3, FR4, the car park.
FR5
HLD2 FR1 Models the required states of the entry gate.
HLD3 FR3 Models the required states of the exit gate.
HLD4 FR2, FR5 Models the required behaviour of the screen.
HLD5 FR2, FR3, Models the required behaviour of the attendant.
FR5
HLD6 FR1, FR2, Models the required behaviour of the driver.
FR3
HLD7 FR4 Models the required behaviour of the sign.
HLD8 FR1 Models the required behaviour of the ticket dispenser.
HLD9 FR2 Models the required behaviour of the ticket reader.
HLD10 FR3 Models the required behaviour of the paid button.
HLD11 FR5 Models the required behaviour of the report button.

Car Park System 17

 4. Implementation
Members Responsible for:-
Development: All

Verification: All

Correction: All

Errors Found: 19

Time to Complete: 22.5 hrs

Car Park System 18

 4.1. Java Source Code
4.1.1. Car Park View – CarParkView.java
1. /*
2. * CLASS CarParkView
3. * SYNOPSIS Provides the graphical user interface for the car park system.
4. * AUTHOR Marshall Allen
5. * DATE 7 April 2001
6. */
7.
8. import java.awt.*;
9. import java.awt.event.*;
10.
11. public class CarParkView extends Frame {
12.
13. // Global GUI objects
14. private TextArea uiScreen, uiTicketDispenser;
15. private TextField uiTicketID, uiTicketTime;
16. private Label uiSign, uiEntryGate, uiExitGate;
17. private Button uiPaidButton, uiReportButton, uiAtEntry, uiAtExit,
18. uiTakeTicket, uiPassEntry, uiPassExit, uiSwipeTicket;
19. private CarPark carPark;
20.
21. // Constructor
22. public CarParkView() {
23. // create user interface components and handle messages
24. setupView();
25.
26. // instantiate a car park
27. carPark = new CarPark(uiScreen, uiTicketDispenser, uiTicketID,
28. uiTicketTime, uiSign, uiEntryGate, uiExitGate,
29. uiPaidButton, uiReportButton, uiAtEntry, uiAtExit,
30. uiTakeTicket, uiPassEntry, uiPassExit, uiSwipeTicket);
31. }
32.
33. // Setup the user interface window and run the application
34. public static void main(String[] args) {
35. // create user interface window
36. Frame frm = new CarParkView();
37. frm.setSize(520, 300);
38. frm.setTitle("Car Park System");
39. frm.setResizable(false);
40. frm.setVisible(true);
41.
42. // handle the close box message
43. frm.addWindowListener(new WindowAdapter() {
44. public void windowClosing(WindowEvent e) {
45. System.exit(0);
46. }});
47. }
48.
49. // Creates user interface components and handles messages
50. private void setupView() {
51. // instantiate main interface objects
52.
53. // TextAreas
54. uiScreen = new TextArea("", 5, 40, TextArea.SCROLLBARS_NONE);
55. uiTicketDispenser = new TextArea("", 2, 12, TextArea.SCROLLBARS_NONE);
56.
57. // TextFields
58. uiTicketID = new TextField("", 8);
59. uiTicketTime = new TextField("", 8);
60.
61. // Labels
62. uiSign = new Label("Vacancies", Label.CENTER);
63. uiEntryGate = new Label("Entry gate closed", Label.CENTER);
64. uiExitGate = new Label("Exit gate closed", Label.CENTER);
65.
66. // Buttons
67. uiPaidButton = new Button(" Paid ");
68. uiReportButton = new Button("Print Report");
69. uiAtEntry = new Button("Enter Car Park");
70. uiAtExit = new Button(" Exit Car Park ");
71. uiTakeTicket = new Button("Take Ticket");
72. uiPassEntry = new Button(" Drive In ");
73. uiPassExit = new Button(" Drive Out ");

Car Park System 19

 Implementation

4.1.2. Moderator’s Report

Moderator's Inspection Report

Project Car Park System Date 8/4/01

Moderator Michal Zajac

Inspection Start Time 6:00pm

Inspection End Time 7:56pm
Inspection Prep Time 30min Total Lines of Code Inspected 363
Inspection Duration 1hr & 56min

Est. Rework Time 2 hrs

Reworkers All
ReInspection Date none

Reviewers All Producers All

Recorder Marshall Allen

Meeting Comments
As it can be seen in the tables below the implementation inspection has been considered
very successful by all individuals that were present. The inspection revealed many defects in
the smaller classes but failed to pick up some of the major errors in the larger classes. These were
found during the first compile. Overall, 19 defects were found some of which would not have
been picked up if the inspection had not taken place. These defects were addressed by the
producers and all have been corrected. I am pleased to comment that all staff involved in the
inspection have once again shown the level of professionalism that you come to expect.

20 Car Park System

4.1.3. Inspector’s Report

Inspection Error Log

Project Car Park Control Recorder Marshall Date 4/08/01

Moderator Michal

Review Type Implementation (Req./Des./Code/Doc.)

Location/ Defect Description Category To be Resolution

Line# Resolved Date
by
Gate Shouldn't extend CarParkView 1 W FN Michal 9-Apr
Gate getLabel' is not a suitable name, use 'gateLabel' 2 W MT Michal 9-Apr
Gate getState' is not a suitable name, use 'gateOpen' 2 W MT Michal 9-Apr
Gate getState' should be of type Bool and not boolean 1 W FN Michal 9-Apr
Gate java.awt package has not been imported 1 M FN Michal 9-Apr
Gate Symbolic constants should be public 1 W FN Michal 9-Apr
Gate Doesn't assign false to open 1 M FN Michal 9-Apr
Gate Doesn't print the state of the gate 2 M FN Michal 9-Apr

Screen TextField should be a TextArea 2 W IF Uday 9-Apr

Screen Constructor missing argument for TextArea 1 M FN Uday 9-Apr
Screen Assignment should be this.screenField = screenField 1 W FN Uday 9-Apr
Screen Method 'message' should be called 'process' 2 W MT Uday 9-Apr
Screen Method 'process' shouldn't return anything 1 W FN Uday 9-Apr
Screen variable 'data' should be called 'message' 2 W MT Uday 9-Apr
Screen java.awt package has not been imported 1 M FN Uday 9-Apr
Screen There is insufficient commenting 2 M MT Uday 9-Apr

Sign Colon after import should be a semi-colon 2 W SN Mark 9-Apr

Car Park Colon after atEntryGate() should be a semi-colon 2 W SN Marshall 9-Apr

Car Park = in pressedButton() conditional should be '='= 2 W SN Marshall 9-Apr

1-Major MT-Maintainability SN-Syntax OT-Other

2-Minor DC-Documentation FN-Functionality
M-Missing IO-Input/Output IF-Interface
W-Wrong PF-Performance DA-Data
E-Extra ST-Standards LO-Logic

Car Park System 21

 Implementation

4.2. Implementation Traceback and Verification

In the implemented Car Park System, the user interface components, such as the Paid button and
Report button, were absorbed into the User interface component, and has been called the
“CarParkView” class.

Each class has been implemented to match the design, so that each class contains a method that will
handle the various inputs to that component, and report back (if necessary) the result (such as the
change of state) of processing that input.

The table below traces the implementation of classes back to the Low Level Designs.

Class Satisfies Justification

CarParkView LLD1 Provides a correct simulates of the visual inputs and outputs of the
Car Park System.
CarPark LLD1 Provides a correct representation of the Car Park System, which
allows the input of the designed inputs to the system. Each designed
interface method has been implemented according to the design.
Gate LLD2 Processes the inputs and outputs of an Entry/Exit Gate in the system.
Each designed interface method has been implemented according to
the design
Screen LLD3 Processes the inputs and outputs of the Screen component correctly.
Each designed interface method has been implemented according to
the design
TicketDispenser LLD4 Processes the designed inputs and outputs of the Ticket Dispenser
component. Each designed interface method has been implemented
according to the design.
Sign LLD5 Processes the inputs and outputs of the Sign component correctly.
Each designed interface method has been implemented according to
the design.
TicketReader LLD6 Processes the designed inputs and outputs of the Ticket Reader
component. Each designed interface method has been implemented
according to the design.
Data - Helper object to encapsulate the ticket data
Bool - Helper object to encapsulate a Boolean return value

22 Car Park System

Car Park System 23
 5. Testing
Members Responsible For: -
Development: Ali
Verification: Michal Zajac
Mark Pickersgill

Correction: Michal Zajac

Errors Found in Test Cases:

Errors Found in Program:

Time to Complete:

Car Park System 24

 Testing

5.1. Testing: Own Program

Testing Carried Out By: Michal Zajac

5.1.1. Valid Test Cases

The table below lists our test results for valid inputs into our Car Park System.

Test Case Input Expected Output Actual Output Comments

Car Park System 25

 Project Analysis

5.1.2. Invalid Test Cases

The table below lists our test results for invalid inputs into our Car Park System.

Visible State of Expected

Test Case Input Actual Output Comments
Component Output

5.2. Test Case Inspection

5.2.1. Moderator’s Report

Project Car Park System Date 9/4/01
Moderator Mark

Inspection Start Time 9:00pm

Inspection End Time 11:35pm
Inspection Prep Time 10min Total Pages Inspected 2
Inspection Duration 35min

Est. Rework Time 30min

Re-Workers Michal
Re-Inspection Date -

Reviewers Michal Producers Casey

Mark Michal
  Mark
Uday
Recorder Michal

Meeting Comments
- In total 15 errors were found.
- The Inspection revealed some minor problems with wording of the Test Cases.
- Some comments needed rewording as they were either missing or were incorrect.
- Few of the inputs were incorrect and this was addressed.
- Overall the Inspection went smoothly and with out any major problems.

26 Car Park System

 Testing

Inspector’s Report

Project Car Park System Recorder Michal Date 9/4/01

Moderator Mark

Review Type Doc (Req./Des./Code/Doc.)

Location/ Defect Description Category To be Resolution

Line# Resolved Date
by
VTC2 Test Case Named Incorrectly   W Michal 9/4/01
VTC2 Expected Output Incorrect   W Michal 9/4/01
VTC3 Test Case Named Incorrectly   W Michal 9/4/01
VTC3 Invalid Comment     W Michal 9/4/01
VTC5 Missing Comment     M Michal 9/4/01
VTC6 Test Case Named Incorrectly   W Michal 9/4/01
VTC9 Incorrect Input     W Michal 9/4/01
VTC10 Incorrect Input     W Michal 9/4/01
             
ITC3 Input Incorrectly Worded   W Michal 9/4/01
ITC5 Input Incorrectly Worded   W Michal 9/4/01
ITC5 Invalid Comment     W Michal 9/4/01
ITC6 Comment Missing     W Michal 9/4/01
ITC7 Incorrect ‘Invalid Test Case’ (To be removed) W Michal 9/4/01
ITC8 Input Incorrectly Worded   W Michal 9/4/01
ITC9 Invalid Comment     W Michal 9/4/01
             

1-Major MT-Maintainability SN-Syntax HF-Human Factor

2-Minor DC-Documentation FN-Functionality OT-Other
M-Missing IO-Input/Output IF-Interface
W-Wrong PF-Performance DA-Data
E-Extra ST-Standards LO-Logic

Car Park System 27

 Project Analysis

5.2.2. Test Cases to Functional Requirements

The table below indicates which valid test cases satisfy which functional requirements and why.

Note: Only the Valid test cases have been traced back to the functional requirements, since the
functional requirements, are primarily concerned with valid usage of the system.

Functional
Test Case Justification
Requirements
Tests if the Screen is displaying the correct
VTC1 FR2
Amount Owed.
Tests if the Paid Button is actually there and if it
VTC2 FR3
performs its required action(s).
Tests if the Report Button is actually there and if it
VTC3 FR5
performs its required action(s).

28 Car Park System

 6. Error Analysis
Members Responsible For: - Casey Acworth
Time to Complete: 1 hr

6.1. Defects Summary

Phase Time taken Rate
Inspection Defects found finding defects (defects/hour)
Requirements 19 1h 25 13.4
Design 16 3h 16 4.9
Implementation 19 2h 26 7.8
Test Cases 15 0h 45 20
Total 69 7h 52 8.77

6.2. Defect Analysis

6.2.1.Requirements
Defects found in inspection: 19

The efficiency and value of the requirements inspection is apparent. The rate at which defects
were found was high, and there were few issues raised after the inspection.

6.2.2.Design
Defects found in inspection 16

The rate at which errors were found in the design inspection was considerably lower than the
inspections for other phases. This may in part be due to the complexity of design, however there
is opportunity for improvement here.

6.2.3.Implementation
Defects found at inspection: 19
Defects found during compile: 9
Defects found at run-time: 1

65.5% of all code errors were found during the inspection. Several of these were maintainability
issues that would have gone unnoticed without the inspection.

6.2.4.Test Cases

Defects found in inspection: 15

The inspection carried out on the proposed test cases was not considered necessary, however, it
managed to locate some important problems in a relatively small amount of time. The
thoroughness of these test cases was significantly improved by this inspection.
Car Park System 29
 Project Analysis
7. Project Analysis
Members Responsible For: -
Development: All

Verification: All

Correction: All

Time to Complete: 3 hrs

Following, is a report on the analysis of the project, conducted to allow for future improvements to
be implemented. It contains, first, the issues and suggestions raised during the previous project, then
a description of changes made in order to resolve them. Following this is an analysis of this project,
and a comparison of several measurements with the previous one.

30 Car Park System

 7.1. Analysis of project 1
This section is a collection of issues raised by individuals of the team, and the suggestions made to
try and overcome them. Also included, is a list of measurements that should be taken in order for
the team to monitor its process improvements. These issues were documented in an analysis of
Project 1 completed for Workshop 5.

7.1.1.Problems Encountered
 Confusion with the use of behaviour trees due to different interpretations
 Inexperience with, and lack of understanding of software development elements. I.e.
planning, design, implementation, etc.
 Lack of standards and templates for documentation and code
 Inaccurate recording of time spent on tasks
 Inefficient and insufficient meetings. (Time wasting, lateness).
 Poor time management. Ie. Not sticking to schedules
 The software development process was not well defined
 Team members unfamiliar with each other and working as a team
 Insufficient planning. The breakdown of tasks and task distribution was not as good
as it could have been
 Communication between group members was not always effective
 Document preparation took too long and the document control became difficult
 Design stage was rushed; more time should have been spent developing alternative
designs and ensuring the chosen design was correct
 Feedback on various phases was usually infrequent and of poor quality

7.1.2.Lessons
With the raising of the key problems listed above, it was found that several valuable lessons
could be learnt. These lessons are listed below.

 Understand exactly what needs to be done, and how it is done before even beginning
it. Software engineering processes need to be explicitly defined
 Teamwork is essential to the success of the project
 Certain processes, such as design and requirements specification are vital to
developing quality software
 Must allow sufficient time for design phase
 All team members need to be knowledgeable on each phase and all aspects of the
project process and also the project overall
 Planning and monitoring the project progress are critical in keeping the project on
time.
 Re-planning is necessary and planning needs to be broken down into detail.
 It is important to have inspections that are formal, and a set of standards (such as
checklists for inspections)

Car Park System 31

 Project Analysis

7.1.3.Suggestions
The following suggestions were made as methods of improving the efficiency and productivity
of the team.

 Develop checklists and standards to formalise meetings and inspections

 Create detailed task/process forms during planning. Eg. A broken down list of tasks
and deliverables to produce for each phase of the project would be useful
 Develop a template and enforce standards for source code
 Enforce document naming conventions and organising guidelines to improve
document handling and version control
 Identify critical tasks such as certain aspects of design, and plan to spend more time
on those critical aspects
 Improve understanding of software development concepts and processes by revising
relevant material and teaching other members
 Use proven time management techniques in order to stay on schedule
 Develop a set of templates and standards for documenting the various tasks
 Be aware of the importance of a good communication and ensure everyone is clear on
what is being discussed and what is happening at each phase

7.1.4.Measurements
It was suggested that the following measurements be made in order to track the team’s
improvement.

 Initial development time or value per 1000 lines of code (Kloc)

 Inspection time or value per Kloc
 Defect correction time or value per Kloc
 Number of defects per Kloc
 Number of defects found at each phase
 Number of defects per Kloc
 Errors before first compile vs errors after first compile
 A consensus of group opinion on how the project process went, and how much each
member learnt from the exercise

32 Car Park System

 8. Bibliography
Humphrey, W. (1990). Software Engineering – Management. United States of America:
Addison-Wesley Publishing Company, Inc.

Dromey, G. (Lecture Notes 2001). Genetic Software Engineering.

Car Park System 33