Software Engineering with an Agile Development Framework/Resources

This section isn't staying like this. It is a staging area for the rest of the book.

Eventually a chapter called resources will contain blank templates for activities throughout the book.

Butterfly

Environment report

Environmental report

The environment the project will be finally used in, will vary from very quiet when only a few people are viewing it, to very noisy when a school trip views the exhibit. The target project audience is most likely to be very noisy when in numbers. The overall temperature will be fairly constant due to the air conditioning required by the butterflies. Lighting will also be constant, as the project will be indoors, and can be easily controlled. In the habitat there will be a constant temperature of around 28 degrees Celsius with 90% humidity with the temperature only dropping slightly over night. There should be no obvious problems caused by the climate due to the fact that any hardware will be contained entirely inside or entirely outside the habitat.

Alternative matrix

Alternative Solution - Matrix Analysis
Tithlyon Solutions- Decision Matrix
Project Digifly				Popup Book/ Text Book	Interactive Exhibit	Interactive DVD/CD rom	Video Documentary	Virtual Reality
Functional Requirements	Priority	Weighting 1-10	' '
Allow the museum to have an interactive software activity based on butterflies	Essential	10		40%	100%	90%	40%	100%
Allow people to create their own virtual butterfly	Essential	10		10%	100%	100%	10%	100%
Allow a butterfly entered into the database to be retrieved by its creator	Essential	9		0%	100%	100%	0%	95%
Butterflies shall fly and move around and interact with the environment	Essential	6		50%	95%	65%	80%	100%
Butterflies will be deleted off the database after a set amount of time	Essential	7		0%	100%	80%	0%	100%
Must cater for ages from 10 and up	Essential	9		50%	95%	95%	75%	80%
Flexible enough to handle a different topic	Useful	3		0%	100%	80%	0%	100%
Give users the opportunity to take something home that relates to the exhibit	Useful	3		50%	100%	100%	50%	70%
Must have a shutdown procedure for when the power is turned off	Essential	10		0%	100%	100%	100%	100%

 

Have a type of screensaver	Essential	10		0%	100%	100%	100%	100%
Show the natural life cycle	Essential	10		100%	100%	100%	100%	100%

Easy To use (For the public)

Essential

10

100%

100%

80%

100%

50%

Total

107

31.78%

99.30%

92.94%

63.60%

92.38%

Constraints

Should not appear as a computer to users

|x||x

Offer the user a reason to return

|

Be able to handle up to 300 – 1000 people a day

|x

Be completely robust

|x

Function normally within a 28˚C and a humidity of 90%

|

Run unattended and require little as possible maintenance

|x| 

Show version number etc on start-up

 

Visual relationship between display areas

 

|Meets constraint

'x'

Breaks constraint

storyboard

Storyboarding was vital to our development. As we all hated documentation, we used storyboards as often as possible which saved a lot of time and misunderstanding as we could all see what others were thinking.

Interface storyboards had multiply stages where many details were changed and many potential problems were found. Most of the storyboarding was done in the first three months with almost post storyboards done on whiteboards in the main being small modification to the original storyboards

The following storyboard was used for presentation to show the client an overall design concept and to illustrate our current understanding of the interface requirements. The final product has two main changes from the following storyboard, there is no VR section instead there is a third person flyer section and the projection display has become the final section. Nether of these changes require any storyboarding to implement so no was ever made.

Functional requirements

Functional Requirements

	REQUIREMENT THE SYSTEM SHALL	DESCRIPTION
FR 1	Allow the museum to have an interactive software activity based on butterflies.	The museum provides a learning experience for museum\’s visitors.
FR 2	Allow people to create their own virtual butterfly.	Features will be provided to allow people to design their own butterfly.
FR 3	Allow a butterfly entered into the database to be retrieved by its creator.	A database will keep butterflies so that people can come back and see them again.
FR 4	Limit the amount of time a user can use the system.	To keep the line moving so many people can use the system.
FR 5	Appeal to both adults and children.	The need to appeal to the greatest number of people is an import factor
FR 6	Butterflies shall fly and move around and interact with the environment.	To make the display interesting to watch and a better overall experience
FR 7	Butterflies will be deleted after a set amount of time.	To free up resources for more butterflies and to complete the life cycle. Database files will remain but de-activate because it is bad practice to delete any thing of a database.
FR 8	Show the natural life cycle.	The complete life cycle of a Butterfly showing the four major stages
FR 9	Cater for ages 8 and up.	Able to be used by most people above the age of 8 without aid.
FR10	Flexible enough to handle a different topic.	The overall design should be able to handle being changed to display another concept
FR11	Give users the opportunity to take something home that relates to the exhibit.	The museum wants their visitors to have something physical to take away to inform whilst advertising the museum and the tropical house so as to generate new and repeat visits.
FR12	Must have a shutdown procedure for when the power is turned off.	There are many powered displays in a museum. A shutdown sequence is more complex than a switch therefore its desirable.
FR13	Must have a start-up procedure for when power is turned on.	The same as shut down. Power on is as complex a task that should be ask of museum staff when start the display.
FR14	Have a type of screensaver.	Screensaver will be needed because the monitors will be running for long hours. Also there is a need for a "screen saver" loop to entice and inform users to the product.
C1	Should not appear as a computer to users.	Most people find computers can be intimidating, boring or common. All of which are not aspects that are likely to enthral users to interact with them.
C2	Run unattended and be maintenance free.	Due to the fact that there will be very little maintenance available for long periods of time, there is a great need for the system to run without the need of regular attendance.
C3	Be completely robust.	Able to withstand the wear and tear of a museum interactive exhibit.
C 5	Show version number etc on start-up.	A version number is needed so there is no confusion to what version of software/ hardware is currently operating. Important when servicing or upgrading software.
C6	Function normally within a humid and varying environment.	28˚C and a humidity of 90% are the conditions within the butterfly house. The system may also be installed for a time in the museum foyer other areas which may have varying conditions.
C7	Be able to handle up to 1000 users a day.	The number of visitor to the museum is very erratic due to the likes of holidays and weather. It is also common to have large group visits such as tour or school groups. This mean that the system may have times that it is constant use throughout a day or not at all.
C8	Offer different levels of information	Able to cater for those who want to know more.
C9	Offer the user a reason to return	Some reason that a user will repeatedly return to the exhibit.

Taxi

Locked in to an expensive software system Historical Data remotely stored and not easily accessible or adjustable Upcoming legislative requirement to have historical records of all booking and dispatch data

Data Dictions

Booking Table The booking table is used to store information on specific bookings, which are later referred to on the job table if they successfully become jobs. There are 2 relationships to the Address table, one to reference a pickup address , the other to reference a destination address. There are also 2 relationships to the shift table one to record the operator who made the booking, and the other to record the dispatcher who assigned the job. Relationships Address 1..N Booking (for pickup address) Address 1..N Booking (for destination address) Shift 1 .. N Booking (for Operator) Shift 1 .. N Booking (for Dispatcher) Shift 1..N Booking (for Taxi)

Booking.BookingID General Information This field is the primary key of the table. It is used mainly to reference itself to records on the job table. Values This field contains integers Source On creation of a record the value is automatically assigned by Access Technical Specifications Data type: Autonumber Must be unique: Yes Default value: Assigned by Access Primary Key

Booking.PickupID (Address.AddressID) General Information References an address from the address table to be the pickup address for the booking Source This data is entered when the operator creates a record. It can be edited later. Technical Specifications Foreign Key See Address Table for more information Booking.DestinationID (Address.AddressID) General Information References an address from the address table to be the destination address for the booking Source This data is entered when the operator creates a record. It can be edited later. Technical Specifications Foreign Key See Address Table for more information

Booking.BookingCustomerName General Information Stores the name of the customer who made the booking Values This field may contain any text up to a limit of 255 characters Source This data is entered when the operator creates a record. It can be edited later. Technical Specifications Data type: Text Must be unique: No Default value: NULL

Address.AddressShortcut General Information Stores shortcuts used in the front end by operators to quickly reference popular public places. Values This field may contain any text up to a limit of 10 characters Source This data is managed in a special interface by a control room supervisor Technical Specifications Data type: Text Must be unique: Yes Default value: NULL

Address.AddressCustomerName General Information Stores a customer name associated with the address. Values This field may contain any text up to a limit of 255 characters Source This data is entered when the operator creates a record. It can be edited later. Technical Specifications Data type: Text Must be unique: No Default Value: NULL

Booking.BookingTaxiShiftNumber (Shift.ShiftID) General Information This field references a shift of the taxi that does the resulting job Source This data is entered when the dispatcher gives the booking to a taxi as a job Technical Specifications Foreign key

See Shift Table for more information

Booking.PostDispatchNote General Information This field contains any notes the dispatcher enters regarding the dispatching of a job Values This field contains any form of text up to a limit of 255 characters Source This data is entered when the dispatcher gives the booking to a taxi as a job Technical Specifications Data type: Text Must be unique: No Default value: NULL

Bulk Documentation

Group Management Contract

The members of innovate.It shall meet as following:

• Monday from 3:30 onwards (approx 5 hours) • At least one other night of week as pre-arranged (approx 2.5 hours)

In addition the team members will complete at least 2.5 hours of work in own time.

If circumstances lead to the above not being possible then arrangements will be made to make up the time.

Communication • Either member will communicate with the lecturer/client • Presentations will be done as a group • Any meetings conducted with stakeholders/users will require project representative to take detailed notes to take back to the group and filed in a central document holder • Communication amongst team members will be via email and text messaging, using Blackboard as a common information system • Team members must communicate with each other at least once a week • Team members must ask for clarification over any points of confusion – move forward as a team not as individuals • Team members should be comfortable in sharing ideas and have them listened to and discussed by the team • A monthly progress report will be furnished to the client following a set template (located in Blackboard), outside this time, contact will be made as necessary • Client to provide at least monthly feedback following progress report

Procedures • Documentation standards – standard formatting, clear and concise, appropriate use of white space, logical flow of information, headings differentiated from text, table of contents, page formatting/numbering, one font (12pt Times Roman) • Master documents to sit on Blackboard for group access • Hamish to backup documentation from Blackboard weekly (Monday pm) • Standard group logo on all documentation • Images/graphics used appropriately and not for cosmetic effect • Standard of final document to be checked by an independent person yet to be decided upon and based upon relevant experience • Deadlines: use steering sheets, set out each step and save on Blackboard for group access • Presentations: all work presented will be as simplistic as possible and will include all key points

Management • The group shall adhere to the same Code of Ethics as outlined by NZCS eg assure competence, responsibility, accountability, good practice, moral standards, understanding and management of risk, perception by others, integrity and loyalty, reliability, confidentiality. • Our proposal outline to the client shall include objectives and deliverables. We will identify required resources and follow the project plan as outlined to the client. Any revisions shall be explained as soon as possible. Documentation will be reviewed before final presentation.

General Strategies • Communication with all stakeholders will be transparent and regular • Any problems that arise that cannot be sorted by the group will go to mediation with lecturers. • Any resources needed will be obtained by negotiation from either Otago Polytechnic or the client.

Abandonment • A team member should be considered to have abandoned the project if they do not make contact with the Project Supervisor or other team member for a period of three weeks, unless advance notice has been given. • Upon abandonment the offending member will surrender all project material and status to the remaining member. • Any replacement members appointed may inherit material and status of project to that point, at the discretion of the Project Supervisor. • If client abandons the project then it will be at the discretion of the Project Supervisor to decide whether the project continues with another client, or whether the team joins or starts another project.

Review • Progress will be reviewed; after contact from the client, during each scrum meeting, and during the evaluation stage of each iteration (i.e. review of prototype). • After client contact, a “client contact” form will be completed.

Allocation of Grades • All members will receive the same grade unless a member doesn’t comply to the statutes of this document. Any grade adjustments will be at the discretion of the Project Supervisor.

Project executive summary

The goal of this project is to provide a dispatch system for City Taxis. The Dispatch System should be ready for use as soon as possible.

We are using a methodology that combines iterative and Agile thinking. We believe that understanding grows throughout a project, therefore through the use of prototyping and regular meetings with stakeholders, constructive feedback will be created to ensure the implementation of a successful system. The system should facilitate dispatches and provide historical records.

Main risks identified so far include: lack of compliance to legislation, loss of privacy, inaccurate data, insecure data..

Project Name: Taxi Dispatch System

Team Name: innovate.It Team Members: Hamish Smith, Shane van Dyk

Client: Allan Ward, City Taxis Project Sponsor: Otago Polytechnic Project Supervisor: Sam Mann

Project Description:

Goal: To provide a system that facilitates taxi dispatches easily and successfully, while accurately recording all data needed. 1. Record data of all dispatches accurately 2. Provide current status of dispatches easily 3. Track status of all taxis 4. Complete all dispatches in a timely manner

Section Two: Business Outline Business statements City Taxis provide transport around the “Greater Dunedin Area”, whether it be for sightseeing, corporate or pleasure.

City Taxis has been providing Dunedin with quality transport services for 55 years.

They are the preferred Taxi Company for all of Dunedin’s leading hotels and motels. Are also the preferred carrier for many of the City’s leading businesses.

Whether the cost for your taxi is a personal expense or is charged to your business or employer, in these days of prudent accounting it is the sensible choice to select that carrier who will deliver quality service at an economical price. City Taxis will do this for you.

Client Mission Statement: We provide a quality service with a fleet of modern vehicles and highly qualified drivers.

We strive for to be the best and nothing less.

With over 55 years of service to the people of Dunedin, we at City Taxis are committed to offering our customers the very best service and value for money.

Section Three: Methodology Project Methodology

The Agile methodology encourages realistic schedules and resource allocation, allows for changing requirements and technical complexity of projects. It also takes into account technical shortfalls of group members and access to appropriate technology. Phased life-cycle approach to help the group realize what activities are to be undertaken, what deliverables for each stage may be, enable different types of communication between activities and different stages, determine whether deliverables of each stage are satisfactory prior to proceeding to the next stage. The relative quickness of each cycle means that the team and client are revisiting the stages of the project a number of times, and therefore there is a higher probability of completing a project that satisfies the client. This also allows the flexibility to adjust to the changing client/ project needs. Regular use of “Scrum” meetings (15 minute regular meetings between team members, and client) facilitates a high standard of communication between team members and the client, and keeps the focus on what is happening next and who is doing what. The use of prototypes allows the client to kinesthetically experience the development of the project at regular intervals. This promotes constructive feedback from the client, and increases the probability of the project moving in a direction that meets the stakeholders requirements. Because construction and evaluation is happening throughout the project, there is a greater likelihood that the finished product will meet the stakeholders’ needs. Understanding is not expected to be obtained by all parties early in the project. It is expected that as all parties are involved in a constructing, evaluating process; understanding will continue to growSection

Project Outline

Project Description

City Taxis needs an improved dispatch system that facilitates taxi dispatches easily and successfully, while accurately recording all data needed. The main hub of City Taxis consists of phone operators and a sole dispatcher. The phone operators deal with customer bookings. The dispatcher allocates the jobs and communicates with the drivers. The current system seems to facilitate the dispatch jobs quite well in the office environment, but at a high financial cost. The current communication system between the taxi drivers and the main office, seems to have time delays and distracts the drivers more than what is considered necessary. The ability to store data that is easily accessible is paramount, as future legislative requirements specify that certain data is accessible by police. The immediate desire of the client is that a system is put in place that accurately records the dispatch data for future reference, while providing an easy to use front-end interface.

Project risks Software development is intrinsically risky and uncertain which is why we need clear and measurable goals at the start of the project. The main project risks include the inability of software to perform to expectations of users and the inability of software developers to produce a working or functioning system for users. Also:

• Failure to gain user commitment • Lack of adequate user involvement • Misunderstanding user requirements • Failure to manage end user expectations • Conflict between different users • Inadequate user training • Running out of time

Green Card, Red Card Early on in the process we left a card system for City Taxis staff to use to comment on their current system. Things they like could be written on green cards, things for improvements on red cards.

Discussion 23 July

• A booking always requires a phone number and a name • Situations are going to occur where there is no street address. In this case, the pickup needs to have a location which is to be given a suburb and an area • In theory, it doesn’t matter if there are duplicate location entries in the address table • Shortcut do not dynamically updates, and would have their own interface for editing • Instructions is an optional field • Address numbers are not compulsory • Rules that apply to pickup also apply to destination • Vehicle type is an optional field and by default is blank • Time required is compulsory and defaults to current time • Number of passengers is optional • Large boot is to be removed from the form • True value for Bike Rack will generate “, Bike Rack” to be concatenated into the vehicle type field of the dispatch screen. This happens when dispatch data is generated • A booking requires both a pickup and a destination

Current State of Booking Form • Data does not get recorded properly if there is no street name • There are currently no booking validation processes, anything appears go in regardless of how little data there is, although no data is created if some pieces of data are missing • If a blank booking is made no data goes through, yet the dialog “Booking Saved” is displayed • A booking requires a pickup and a destination address otherwise no new data is recorded

TaxiDispatch Functional Release

13 August 2007

Before going to City Taxis I made a last minute change to the code on the booking form to make phone numbers optional. This suits their needs at the moment better.

On arrival I split the database putting the backend on a folder on the computer to be used as the dispatchers workstation, mapped as the “T: drive” on City Taxis’ local area network. I packaged up the frontend into an install file, and had the setup file created to a shared folder on our polytech computer. The program was installed on all machines on the City Taxis network and testing began.

Problems and suggestions arising from the test included: • Dispatch job screen not working correctly. Jobs will not clear if there is more than one on the screen. This is probably nothing more than a programming bug. • The are delays experienced after saving a booking or clearing the booking form of around three seconds. Most of the time this is OK but could be a problem during busy times. Even so at any time a three second delay is long enough to be annoying. • There is no ability to cancel a booking. • We haven’t facilitated for different vehicle types. No restrictions are imposed, meaning a booking can be made for 6 passengers in one car even though this is not physically possible. • The drop-down boxes to help with address details do not work with the down arrow key. • Special instructions do not appear to be going into the database. • Various corrections to the street database and additions to the list of location shortcuts were made, some still need to be made. • A suggestion was made for the next release that the dispatcher needs to be able to reposition a car on the board at any time.

I spent the first hour or so showing the booking form to the staff on duty and supervised their usage thereof. Afterwards I sat at the dispatchers desk watching dispatchers and generally made myself available to write down suggestions, comments, and problems. Some problems with data I was able to fix instantly on site using the polytech computer to access the backend and edit data on tables directly.

Order of Development

• Look at dispatch board and discuss wireframe interfaces • Design wireframe interfaces • Paper based prototype • Design options • Platform discussion • Create basic prototype • Make platform decisions • Task analysis • Detailed interfaces • Back-end development/migrating • Creation of logical procedure layer • Building/modifying booking front end • Building/modifying dispatch front end • Building/modifying historical and configuration front ends • Data dictionary • Technical documentation • Software manual • Help structure • Testing • Testing on site • Live robust release

Ruled Out • Physical Board: not practical, does not fit in with needs of client

Combination Options: 1. Access tables + Access queries + Access forms 2. SQL Server + Access queries + Access forms 3. SQL Server + Stored procedures (SQL server) + Windows application 4. SQL Server + ColdFusion + HTML 5. Access tables + ColdFusion or PHP + HTML 6. SQL Server + ColdFusion or PHP + Google Maps

Ruled Out • Option 6: Google maps does not match up with the requirements of the wireframe interface • Options 1 and 2: These options use Access forms which do not practically support the features of the wireframe interface • Options 4 and 5: These options use HTML as a front end. This does not have a proper coding environment, and would make for complicated and difficult attempt to support our wireframe interface

Leaving • Option 3: SQL Server + Stored procedures (SQL Server) + Windows application

The SQL server is the best suited backend because, unlike Access, it is designed for a multi user environment and has better stability and facilities for backups. It is also less restrictive in what we can do with the data.

Stored procedures on a SQL server would make a good logical layer because they are held close to the actually data, and once it is created it will make front end development much easier. There is bigger scope for customised procedures to fit in with the needs of the front end.

A standalone windows application is also the best platform with which to make a front end, because as we will be designing and building it ourselves, we can make it meet our requirements. Microsoft Visual Studio is probably the best environment to code with, as it will have facilities to connect with a SQL server data source.

Your Fashion

1. The system shall store user profiles (user has to be a member with username and password to use the website and create a profile) 2. The system shall give tailored feedback 3. The system shall store user purchase history 4. The system shall be an ‘expert’ system 5. The system shall be comprised of web-based components 6. The system shall incorporate a virtual community/forum 7. The system shall have an online auction for second hand clothes 8. The system shall save search parameters 9. The system shall ‘intelligently’ provide targeted promotional offers 10. The system shall access the retailer’s items database 11. The system shall display the store’s relevant products 12. A user shall be able to rate other users’ profiles regarding clothing choices 13. That users can edit their profile 14. That users can delete their profile 15. The system shall provide users with the option of producing multiple profiles 16. The retailer can upload new clothing lines at anytime 17. The system shall allow users to view other users’ profiles if the user agrees to this option 18. The system shall incorporate quality graphics with plenty of white space to promote ease of use 19. The system shall allow for updates while still being used online 20. The system shall notify developers of any downtime eg message output “Screen B in Retailer XY, 111 George Street is not responding” 21. The system shall be portable using mobile platforms eg cellphone, PDA, MP3 player (therefore profile file size is important) 22. The system shall be able to build a profile online using a 56K connection 23. The system shall be able to send targeted text messages using Bluetooth technology 24. Users shall be able to search on past purchasers (eg bought within last 3 months, 6 months, 12 months, etc) 25. Users shall be able to append their wardrobe items to build upon their profile (may need to be capped eg 50 garments using low resolution images) 26. The system shall limit suggestions to top five rated out of all possible combinations according to the user profile 27. A user shall be able to continually build upon their profile by adding information eg making additions to the virtual wardrobe 28. Retailers shall be able to use the system to send purchase suggestions to targeted user profiles (eg women aged 30-35 who earn >$35,000pa and are pear-shaped with fair skin) 29. A user shall be able to search for wardrobe suggestions online via advanced searches eg particular style, retailer, price, etc 30. User shall be able to view generated fashion items, interchangeable with other suggested items 31. User shall be able to text suggested outfit to others requesting feedback (using 3G technology eg Rate this outfit for me please = 1,2,3,4,5) 32. The system shall be able to weed out bogus profiles (eg non-proportional biometrics provided by users to create unrealistic profiles)

The above diagram also shows the coathanger concept where coathangers are used to rate each item. The more green hangers an item has the more suitable that item is for the user, and the more red hangers an item has, the more unsuitable that item is for the user. Hangers can also be half green and half red as the hanger rating comes off a suitability index so an item can be 3.5 coathangers out of 5. We looked at using a colour slider bar for ranking items but decided to go with a star rating (using coathangers as that is unique) instead.