Software Development Methodologies Analysis Information Technology Essay

The report will be divided into sections, which describe the different stages of the project life cycle and provide information about the project scope, purpose and defines project objectives.

Furthermore this report investigates the different software development methodologies and examines which one would be the best to use for the purpose of the final year project.

Moreover the Summary and Critical Review of the project is provided with conclusions on, possible, future changes and improvements to the project.

Finally the report’s Appendix section includes all relevant diagrams, testing and coding and other information related to the project.

Acknowledgments

I would like to thank both of my project supervisors; Jon Bennett and Matthew Wake for their help and encouragement throughout this project.

Furthermore I would like to thank Karren Burrows for her help on improving my database design and Mary Spence for guidance in the complicated world of VBA.

In addition I would like to express my gratitude to Kevin Potterton, a friend and co-worker at Investmaster Group ltd. for providing helpful input, recommendations and moral support in difficulties with project management.

Finally my boyfriend Andrew Steer for his patience, support and proof reading.

Table of content

Introduction

The main aim of this project was to document and develop an Order Processing Scenario for a car rental company.

The system stores customer and car details, car availability, calculates rental costs and fines, prints bills, and highlights unpaid transactions.

This information will be available through a user friendly interface; with clear error messages.

To accomplish this, knowledge acquired throughout the years at university was used to analyse and solve problems encountered during the project.

Furthermore, the information required for the project was gathered and synthesised to provide a practical and high-quality end product that could actually be used in a real world situation.

Additionally, research into different software development methodologies was completed and an appropriate development methodology selected.

By using techniques and tools covered during the course the requirements for an order processing system were captured, including; different users and views of customers and clerks.

What is more, using the research, self-learning and additional Visual Basic tutorials enabled the use of more sophisticated and advanced coding techniques.

Finally, the system was tested by users with different levels of IT knowledge and was accepted for covering the relevant HCI criteria. (Appendix14)

To develop and implement a fully functioning GUI ‘front end’ for the above system.

Problem definition.

Currently, Aleks’ Car Rental is a small car renting company and all record maintenance within the company is carried out manually, on paper.

Customer and reservation details are written down in log books and transactions are not backed up anywhere in case of any data loss and sensitive data is quite easily accessible; making the company susceptible to data theft.

This way of working is not particularly effective because the paperwork is frequently lost or misplaced, which leads to the customers being unhappy with the service provided and complaints concerning the standard of data security.

The aim of this project is to produce a cheap, automated solution that will enable safe storage of sensitive customer data. It should allow permitted users to check on; the availability of cars, customer accounts and to produce relevant reports.

In addition to this, the system should be easy to use with clear instructions and messages as the users (clerks) have only basic IT knowledge.

Objectives

To select and follow an appropriate development methodology.

To capture requirements for an order processing system including different users and views of customers and clerks.

Investigate different software options.

Design the order processing system.

To include a variety of subsystems including the maintenance of customer information, car details, clerk details and the payment of fines.

To identify a variety of users for system testing against relevant HCI criteria(Appendix15).

Produce a prototype with basic functionality.

Conduct an evaluation of the prototype.

To develop and implement a fully functioning GUI ‘front end’ for the above system.

Basic Project Requirements

1) Acquire and analyse user requirements.

2) Develop a working system prototype with basic functionality specified by the user.

3) Design and implement a database for the system prototype.

Possible Further Enhancements

1) Add administration section to the system.

2) Develop a fully functional order processing system

3) Investigate possible security problems

Deliverables

1) Report

2) Working order processing system

Project Schedule

The duration of each task was controlled through the production of a Gantt chart; an outline of each key task was highlighted therein. This chart can be seen in Appendix B.

Nevertheless it is not always possible to stick to the produced schedule, so the second, reviewed Gantt chart was created. This chart can be seen in Appendix B.

It shows the actual start and completion tasks dates presented week by week, the tasks that were completed in the different time than expected are presented in blue.

Appendix C – Project Development Diary and Error: Reference source not found, highlights the problems encountered during the development and times when project was feeling behind the original schedule.

The main reason for running behind the schedule was that the planed amount of time to learn VBA language was an optimistic prediction and the task was much more difficult than predicted.

Another factor that had a big influence on delaying the project was sudden unavailability ot the project supervisor during to his health issues. This had place in January, and caused significant suspension of the database development as the supervisor was a project client and a main source of help in using VBA code.

Furthermore, accommodating for deadlines in other modules, and obligations at work lead to further delays.

However by working extensively during the weekends and bank holidays all of the project objectives were fulfilled on time.

Project Management

Scheduling the project stages had a massive influence on the development of time management skills.

Successful time management helps to increase the person productivity and overall efficiency. Setting goals, prioritising them and monitoring its execution help to gain conscious control over the project and its separate stages.

Developing these skill can seriously influence the person future ability to manage the projects in the work environment.

One of the techniques useful when managing the project is the MoSCoW analysis (see Error: Reference source not found).

It divides the tasks into different categories to enable the decision on which of them are the most and the least important. Tasks paced high in the hierarchy are the ones that had to be completed first, when the completion of tasks placed lower in the hierarchy of importance was optional.

In cases where completion of the most important tasks was taking longer than expected the less important functions were completed earlier, to ensure that there are as many working functions as possible.

Furthermore to ensure that all of the good project management practices are conducted during the final year project development, weekly meetings with Jon Bennett, supervisor, were carried out.

During these meetings supervisor pointed out parts of the project that might take longer to complete and highlighted the areas requiring the biggest effort concentration.

Unfortunately, because of the supervisors health problems meeting in the last few month of the project development were suspended but they were resumed with the new project supervisor although not with the same frequency.

2.Software Development Methodology

Software Development Methodologies Analysis

When developing a system it is crucial to choose a methodology that will fulfil all of the project requirements within the allocated timescale.

A successful methodology is one that enables the developer to manage, evaluate and control the system throughout its life cycle.

There is a wide range of different models, which differ in; the number of iterations of the project lifecycle, the intensity of user involvement in the project and the level of evaluation.

Therefore, the decision on which methodology to use for a final year project might be a very difficult one and to succeed, the complete spectrum of requirements has to be taken into account and many techniques and tools have to be considered.

Agile vs. Heavyweight Methodology

Project development methodologies can be divided into two main types; agile and heavyweight. Both of these methodology types possess aspects useful for the purpose of the final year project but none of them could be fully used as a separate technique. In order to find the methodology that is most suitable for the project it would be recommended to combine some of their individual aspects together.

Agile Methodology

Using some of the agile methodology features can significantly limit the amount of documentation produced for the purpose of the project and assure that the project will be finished in the given amount of time.

Furthermore, the agile approach concentrates on good design, technical excellence and simplicity, which are the main goals whilst working on the final year project.

Another argument for using an agile methodology is that it can also be used for the purpose of small, self-organised teams or individuals, helping them to adapt to changing circumstances, which is often the case in projects such as these.

Heavyweight Methodology

Nevertheless, using some of the aspects of a heavyweight methodology should also be considered when developing an order processing system like Aleks’ Car Rental.

Although heavyweight methods are mainly used by large teams for the purpose of developing large projects, some of the methodology tools and techniques could be also useful when developing student project.

Following a heavyweight methodology helps to identify the different stages of the project and what lifecycle would be the best to follow for the purpose of the final year project.

RAD (Rapid Application Development)

One of the examples of an agile methodology is Rapid Application Development (RAD). Its main advantage is that the working systems are created within a short time period, which is very useful as the time frame for the student final year project is quite restricted.

Furthermore, according to the RAD methodology the project needs to be frequently reviewed by the user as new functionalities are added during the development process.

This is called iterative prototyping and should be applied to the student’s final year project development. User participation is very important in this process as it ensures that the developed system satisfies the end user’s requirements.

Another aim of the RAD method is to reuse existing software components. Unfortunately as Aleks’ Car Rental order processing system needs to be created from scratch this aspect of RAD is not suitable for the purpose of this project.

Another feature of RAD is the use of Computer Assisted Software Engineering (CASE) tools and techniques, which could be extremely useful to the developer in the project planning stages and all stages that follow the development of the system. These techniques should also be used in the development of the final year project.

RAD questions the use of high-level documentation, like this report, as it is very time consuming, and, instead, concentrates on the low ceremony level such as system testing, training and implementation plans.

For a diagram see

Appendix D.

Extreme programming

Another example of the agile methodology is the Extreme Programming Method.

Its success depends upon the level of customer satisfaction with the system. For customer satisfaction to be optimal, this method engages the client in constant communication so that user requirements can be catered for during the development lifecycle.

This could be easily applied to the final year project as contact with the client (supervisor) should be persistent throughout the whole development process.

By delivering the product in modules, over short timeframes, the Extreme Programming method concentrates on short term goals instead of delivering the full product over a much longer period.

The complexity is added to the project sequentially, which means that individuals will be working on something new periodically.

This would be the perfect path to follow when developing the final year project as short term goals could be delivered to the project supervisor on a weekly basis.

What is more, Extreme Programming allows the developer to quickly respond to changes in customer requirements, which would be highly desirable for the unstable requirements of the final year project.

Another feature of the Extreme Programming method is that it is mainly used for small to medium sized projects; such as a final year project.

System Development Life Cycle Methodology (SDLC)

A good example of a heavyweight methodology is the System Development Life Cycle Methodology (SDLC).

This methodology is mainly modelled around the Waterfall Life Cycle which breaks the project structure into stages consisting distinct goals.

It is good for projects with clearly specified requirements and a large time frame.

A key feature of this model is that the process needs to stay free from any overlapping or duplication. To achieve that undertaken goals always have to be accomplished before proceeding from the one phase to the next one. There is very little possibility for the designers to go back and change any of the finished stages as this would dramatically slow down the whole development process.

This methodology doesn’t seem to be suitable for the purpose of developing the final year project.

. For a diagram see

Appendix D.

Structured Systems Analysis and Design Method (SSADM)

Another heavy weight methodology example is Structured Systems Analysis and Design Method. It is the waterfall life cycle method which breaks the project structure into stages and rejects overlapping theses stages.

Three major tools used by SSADM are Logical Data Modelling (Entity Relationship Diagram), Data Flow Modelling and Entity Event Modelling. The method combines all three techniques to enable the complete view of the developed system.

Furthermore SSADM is structured from 5 complex hierarchies of stages: feasibility study, requirements analysis, requirement specification, logical system specification and physical design.

As this methodology is a high ceremony method and it involves extensive planning and wide documentation, its elements should be used in a final year project to document the development process.

Nevertheless SSADM doesn’t really address the issue of changing requirement specifications and it doesn’t allow any iteration after the project phase completion, so following this methodology rigorously might be really time consuming and not appropriate for the purpose of developing the final year project.

User Centred Design methodology

UCS could be described as a methodology that attempts to optimize the product around the user specifications. The main aim is to create a product that user can, want, or needs to use, rather than creating something that user will have to accommodate their behaviour around.

To achieve that client has to be regularly updated with the project progress and consulted regards any changes.

According to the methodology specifications there are several ways to gather required information from the users: focus groups, questionnaires, interviews, usability testing, card sorting and participatory design.

Furthermore, although USC mainly replicates the waterfall life cycle method it is also focusing on its four key stages: Use Specification, Requirements Specification, Design and Evaluation.

The stages are repeated until the project’s usability scope is achieved.

USC methodology uses many techniques that could be useful in the development of the final year project like use cases, scenarios and persona (customer for the purpose of Alek’s car rental).

Methodology used for this Project

Time spent on the planning, documentation development and testing is often dependent on the chosen methodology and can increase or decrease accordingly to the used method.

That is why, to meet the project objectives successfully the common practice is to combine different aspects of the different methodology types in the way they will suit the purpose of the student’s final year project.

As the user (project supervisor) was consulted about the project requirements and progress on many occasions during the project development, it would indicate that aspects of Extreme Programming, UCD and RAD methodologies were used to full the project requirements.

Also, using use cases, project scenario (Alek’s car rental) and persona (client) taken from the UCD method made project goals easier to understand and fulfill.

Furthermore, to design the order of the different stages in the project the waterfall life cycle technique was used, but as many iterations to the project throughout the different stages were made, and object oriented techniques and tools were used, this would indicate the aspects of SSADM and User Centered Design method were used in the final year project.

Moreover Diagrams such as the Logical Data Model (Entity Relationship Diagram) and the Data Flow Model taken from SSADM were also used to establish the data flow in the system and what tables should be created in order for system to work as specified by the client.

Additionally to confirm that all of the client requirement were covered the testing of the system was undertaken as it have place in RAD and UCD methodologies.

To conclude, there is no one appropriate methodology for this project but many aspects of different methodologies combined together enabled to fulfil the requirements set by the project stakeholder.

3. Gathering Requirements

3.1 User Requirements

For the purpose of this project the assumption was made that the person called system user will be the project proposer and initial project supervisor, Jon Bennett.

To enable gathering of the most accurate requirements, two different data gathering methods were undertaken.

Firstly, frequent consultations with the system user enable assembling essential system requirements and allows in depth research into user needs .

Secondly investigation into current car hire solutions on the Internet was undertaken and features of the car renting company systems identified and reused if appropriate.

3.2Research Methods

Two main research method types can be identified, quantitative and qualitative.

Quantitative method is often used when the question is how many or how often. http://www.orau.gov/cdcynergy/demo/Content/activeinformation/tools/toolscontent/quantiativemethods.htm

The most commonly used techniques are usually structured questionnaires and surveys.

Further to that statistical data is produced and, in order to analyse and interpret the collected data, converted into charts and graphs.

This method can be very time consuming and requires gathering large samples of data.

As the final year project has a strict time frame and it is an individual task, quantitative method doesn’t seem to be the right one to use.

Second type of research methods is a text based qualitative method.

In order to obtain the most accurate information, methods such as focus groups, interviews, observations, and case studies are used.

The main data gathering method is to take a description of a problem from someone experiencing it or by observing the individual user.

By using this method more in depth information is provided which will allow better understanding of user needs.

The success of this method depends mostly on the researcher’s skills and should only be used if there are only a few cases to investigate.

As the amount of stakeholders in the project is limited to one and it is possible to observe or interview the user, using qualitative method seems to be more suited for this project.

3.3Interviews

Interview is a formal meeting and discussion with someone. http://www.thefreedictionary.com/interview

Gathering information through an interview means evaluating the situation through the conversation with user. There are different kinds of interviews: structured, semi-structured, unstructured, group interviews and focus groups.

In order to gather all necessary information about the required system functionalities regular weekly meetings with the user were taking place during a four month period. This is documented in appendix X.

During these meetings functional and usability requirements were recognised and different methods on how to fulfil them were discussed.

3.4Functional Requirements

Functional requirements indicates what actions should the system be able to do and what functions it should perform.

Login – Only permitted users should be able to login in to the system.

Make Loan- Permitted users should be able to rent a car, and loan information should be stored in the system

Add Customer- Permitted users (clerk) should be able to add new customer details.

Edit Customer – Permitted users (clerk) should be able to update/edit customer details.

Find Customer – Permitted users (clerk) should be able to find existing customer details.

Delete Customer – Permitted users (clerk) should be able to delete existing customer details.

Add Car – Permitted users (clerk) should be able to add new car details.

Edit Car – Permitted users (clerk) should be able to edit existing car details.

Find Car – Permitted users (clerk) should be able to find existing car details.

Delete Car – Permitted users (clerk) should be able to delete existing car details.

Register car damages – Permitted users (clerk) should be able to add any car damage details.

Add Clerk – Permitted users (manager) should be able to add new clerk details into the system.

Edit Clerk details – Permitted users (manager) should be able to edit clerk details in the system.

Find Clerk – Permitted users (manager) should be able to find clerk details in the system.

Delete Clerk – Permitted users (manager) should be able to delete clerk details from the system.

Produce Reports – Permitted users (manager) should be able to produce monthly and yearly income reports.

Produce Loan Receipt – Permitted users (clerk) should be able to produce client receipt with the loan details.

Calculate Payment – System should calculate the total payment for the loan.

Calculate Fine – System should automaticaly calculate fine for late returns.

Notifying about overdue loans – Permitted users (clerk) should be able to view details of the overdue loans.

Close Option – Use should be able to close all the forms.

Cancel Option – User should be able to cancel undertaken activity.

Logout Option – User should be able to logout from the system.

3.5 Usability Requirements

Usability requirements measures how the software is suitable for its users, considering

how easy it is to learn, how effective it is, how efficient it is, and user satisfaction.

When designing a system there are ten usability principles that should be taken into consideration . Jakob Neilsenal. (2001).

These 10 rules are outlined below with relevance to the order processing scenario Aleks’ car rental.

Visibility of system status – The user should be informed about any system status changes through the use of appropriate feedback e.g. When information in the system is updated a message box

should be displayed informing the user whether this procedure has been successful or not.

Appendix 16

Match between system and the real world – Language used in the system should be appropriate and easy to understand by the user, egz meaningful error messages. Appendix17

User control and freedom -All possible activities undertaken by the user should be supported by the system (navigation).

Consistency and standards – To prevent any confusion the system the consistency of the interface should be kept throughout the whole system. It is reassured by using the same colours, fonts and format.

Error prevention – Any errors should be avoided when possible, where errors do occur, user should be clearly informed what has happened.

Recognition rather than recall – The interface should be informative enough for the user to understand how to navigate around the system in order to fulfil the undertaken action, egz. placing order.

It should be clear to the user what they are required to do without recalling any information.

Flexibility and efficiency of use – The system should be designed for both experienced and

inexperienced. Although the ‘Aleks’ car rental’ system is easy and straight forward to use all of the users will be provided with user guide.

Aesthetic and minimalist design – Using only the basic graphics and presenting only the necessary information prevents user from getting distracted from the system.

Help users recognize, diagnose, and recover from errors – When an error occures, the meaningful information should be displayed to indicate what coused the error and suggest how to resolve the problem.

Appendix 17.

Help and documentation -A user guide, listing clear steps on how to complete the tasks should be available.

Appendix 18

3.6 Requirements gathered from available solutions

This section of the report studies existing booking systems, available on-line or sold to car renting companies.

See Appendix 18 for screen shots of these solutions.

An investigation throuought existing booking systems was carried out in order to identify

any reusable features that can be used for Aleks’ car rental System. Furthermore, undertaken research helped to recognise problems that should to be avoided. These are discussed below:

General Usability:

Usability is about design focused on helping customers perform tasks, with little effort and making the

experience enjoyable. It is important from both the customers’ perspective as it is the means by which

the user interacts; it should not lead to frustration. A well designed website interface is user friendly,

simple, efficient, the functionality easy to learn and use in addition to providing effective interaction.

Use of Multimedia:

A range of high quality multimedia through color, sound, and graphics collaborated creates a powerful

impression and generates interest, making the experience enjoyable. This sets a positive expectation

for the rest of the website ultimately the customers’ choice of place to hire a vehicle. Use of

multimedia should be kept to a minimal, with lot of white space and contrasting text. The average

customers computer specification and bandwidth should be kept in mind thus it affects load up and

response time.

Search for Information:

A customer likes a booking experience that enables them to find, select and pay for the service with

ease. The solution to this is efficient navigation and search facilitation.

A search function by keyword can help retrieve specific information; reducing frustration.

Grouping meaningful data in a structured list should be applied as it minimizes confusion. Further

subcategory help narrow down relevant information making it easier for customers to find what they

are looking for.

Online Order:

The website should support secure online payment transactions, customers should be made aware of

this, also other methods of payment options should be acceptable as customers are vulnerable to

carrying out online payments.

Status of reservation:

It is important that the customer is updated with the status of the service once the reservation has been

completed i.e. confirmation of the booking.

3.7 Safety Requirements

There is a wide range of safety requirements to consider when designing a system, but as specifying them is outside the final year project scope only the basic ones will be covered.

Backup – when additional copies of the data are make. This could be done either by the user or automatically by the system.

Backed data should not be stored anywhere within close proximity of the original system in case of a natural disaster such as fire or flood was to take place where the system is located.

It is highly recommended that Aleks’ car rental company use a backup option to secured informations stored in the system.

System stability testing – to minimise system failure and possible data loss the thorough testing should be always performed on any new system.

3.8 Security Requirements

Personal information stored in the system should only be accessible by authorised person.

Password – to prevent unauthorised individuals from accessing the data, system should always be protected with the password.

Encryption – protects information by making it unreadable to anyone except authorised person.

This is use to protect the password when login in to the Aleks’ car rental.

4.Software and Hardware solutions

5.Car rental Company System Prototype

In order to develop a fully working system student had to design and develop a working prototype of the booking system as a part of the project development lifecycle. See Appendix G for screen shots of the prototype system.

Use Case Diagrams

To gain an overall view of the system to be developed a diagram was drawn using UML (Unified

Modelling Language). UML is used to show the interaction between the reservation system and the

several actors/users. See Appendix H for a UML diagram.

User Authentication

As the system is designed to stored potentially sensitive data the user identification must be in place.

In order to secure the system from the unauthorised entries the username and password authentication will be used to register to the database.

This will allow s to access their account with view/update privilege rights to the registerd users.

6.3 Database Implementation

Before development of the website could begin the database needed to be constructed. Whilst

developing the database, all the tables created were normalised. This process ensures that data is not

unnecessary duplicated in the tables by using foreign keys. This can be seen in Appendix I

Database Manipulation

Throughout the reservation system data was manipulated using sql commands. To retrieve data from

the database tables and display them on the web page, sql functions had to be manually created as

Dreamweaver is not able to generate such complex commands. Examples can be seen in Appendix J

6.4 Story Boards

Web design storey boards were used to come up with rough sketches of each web page interface,

taking into account the layout, information that will be displayed and the functionality on that

particular web page. This stage gives the stakeholders the opportunity to review and alter the designs

before the site is developed. Once approved the development phase can begin. See Appendix K for

storyboards.

6.5 Future Additional Features

Increased

6. Prototype Evaluation

According to the lifecycle model once a prototype has been developed it should be evaluated and

further requirements produced to develop another prototype if necessary.

7.1 Scoring Checklist & Heuristic Inspection

A simple scoring checklist was produced, see Appendix this was used to evaluate Oakewll Hires prototype reservation system, in terms of its effectiveness for marketing and sales purposes. This

scoring system had ten sections that were felt important within a simple buying process. The check list

related the website behaviour directly to the P R Smith model of buying. The scoring system included

a checklist for each item and rating for each section. 5 represent an excellent score, and 1 indicates

work needs to be done to improve the web site. My scoring strategy was that regardless of whether or

not all the points on the checklist were covered, the website could still score high; the check list did

not the affect the rating. This is because some features outweigh others in importance.

Oakwell Hire is using the online method as ‘just another channel for customers’ (Managing Director

of a Major UK Retailer). Their aim is to cross sell to existing customers and attract and also retain new

customers.

A Heuristic Inspection involves evaluating a system against a list of known standards. Based on the

following usability guideline by Nielsen (1993) Effective to Use, Efficient To Use, Safe To Use,

Good Utility, Easy to Learn, Easy to and Remember and the checklist produced the reservation

system was evaluated the results show that the system was a success in terms of design and

functionality:

In terms of performance, load up and response time was fast enough.

The sites made it possible for users to browse around without having to register and login.

The website did not have a keyword search facility, although a good navigation system was in place,

this allowed users to navigate easily through all sections of the website.

Some found the alert text boxes used to notify users when incorrect input was entered on a form

annoying, they commented that simple text in a different colour displayed at the top of the page would

be more bearable.

FAQ (Frequently Asked Questions) page seemed to have been omitted, this will also be added to the

additional future features, although additional guides were on hand.

Users are able to successfully place a booking online, interface functionality in all the cases is easy to

learn, efficient and easy to use. Also allows effective interaction.

When the user reserves a car or personal data is updated clear indication of the system status is

provided through confirmation.

The site is user friendly and consistent, providing clear, simple instructions guiding through the site.

Graphics have been kept very minimal, lots of white space with contrasting text.

7.2 User Section – User Testing and Satisfaction

Users were asked to evaluate the reservation system by completing a set of tasks this can be seen in

Appendix M comments were added on each.

7. Evaluation of Project

To establish whether the project was successful key issues were analysed.

Investigation into different software development methodologies.

As outlined in section 2 of this report detailed research was carried out into a number of methodologies to

determine the most appropriate one for this project. The methodology chosen was proved suitable.

To develop a system testing the prototype and reviewing the requirements continuously, by involving

users and obtaining their feedback was good practice. The chosen methodology allowed the

project to be completed with the users and the requirements at the core of the development

process.

Investigate requirements

Appropriate techniques of gathering requirements were investigated and a method was selected. Many

functional requirements were gathered from the focus group arranged. Additionally if a one to one

interview had been carried out the requirements may have been more detailed. The usability

requirements were then determined, producing a complete collection of requirements for the online

reservation system.

Investigate hardware and software options

All appropriate technologies were investigated, decision of chosen hardware and software options

were based on availability, cost, knowledge and experience. The chosen technologies allowed the

functional requirements to be effectively implemented thus the choice made on selecting the suitable

technologies were proven to be successful.

Design the reservation system

An ER (Entity Relationship) diagram was created for the proposed system. Usability issues were then

applied this resulted in a structure to be followed during the coding of the interface. Throughout the design stage the requirements were constantly referred to making sure that they are successfully

achieved.

Produce a prototype with basic functionality

Once the design for the system was completed the development process began. This was not straight

forward with my limited knowledge of VBA. Difficulty was experienced coming to grips with the

language whilst ensuring the usability criteria was met. In order to overcome this problem, source

code from the internet was studied allowing a deeper knowledge and understanding to be acquired.

The prototype meets the objectives of this project thus it is regarded successful. There are

nevertheless always room for improvements.

Conduct an evaluation of the prototype

To evaluate the prototype a number methods were employed. This allowed a better oversight into the

success of the reservation system and provided helpful guidance if the project is to be continued in the

near future.

Appendix A – Personal Reflections

PROJECT CONTRACT

Aleksandra Brzezinska, P06003392,

Business Information Technology HND/BSc

[email protected]

Project title

To document and develop an Order Processing Scenario.

(Car rental company).

Project proposer:

Jon Bennett, De Montfort University Department of Computer Technology; [email protected]

Project background:

I will be designing and implementing a booking system for a car rental company.

The system will store clients and cars details, cars availability, calculate rental cost and deposit, print bills, highlight unpaid transactions.

System will also inform the user if required car do not exists in the system and show alternative model available.

This information will be available through user friendly interface, with clear error messages.

System will be used by qualified staff and will be protected with a password.

Aim:

Aim is to develop fully working Car Rental Company booking system.

Objectives:

To select and follow an appropriate development methodology.

To capture requirements for an order processing system including different users and views of customers and clerks.

To include a variety of subsystems including maintaining customer information, products, orders, back-orders.

To recognize, agree and test for a variety of users – relevant HCI criteria.

To develop and implement a fully functioning GUI ‘front end’ for the above system.

Resources:

Software – Microsoft Access

VBA coding

My SQL

Constrains:

Time

Sources of Information:

David Whiteley: ‘Introduction to Information Systems’

Philip Weaver: Success in your project- a guide to student development project.

Library/Internet

Student: Date:

Proposer: Date:

MoSCoW Analysis

One of the techniques that help prioritising requirements during the project development is the MoSCoW analysis.

“You use this technique to divide the requirements into four categories: must, should, could and won’t. There are very specific definitions for each of these four categories.

Must: These requirements are a must have.  Think of them as very high priority requirements for your project.  They must be part of the final solution in order for that solution to be considered successful.  

Should: These requirements are also high-priority requirements, and are every bit as important as the requirements in the must category. However, there might be workarounds that satisfy these requirements or they may not be as time critical.

Could: These desirable requirements are of lesser priority and are nice to have capabilities in the solution. They really don’t affect anything else in the solution one way or the other and will be included if time and resources permit.

Won’t: These requirements will not be implemented in a given solution release. They may be considered for inclusion in a future release (future requirements that stakeholder would like to have) or be omitted from the solution altogether.” (1)

http://project-management.learningtree.com/2011/01/18/requirements-prioritization-technique-moscow-analysis/

Must Have Requirements:

Needs to be a fast loading system

Username and password protection for all users

Allows user to add, edit, find and delete customers.

Allows user to add, edit, find and delete cars.

Allows administrator to add, edit, find and delete clerk details.

Allows user to make a loan.

Provide two user profiles, administrator and normal user.

Should Have Requirements:

Allows user to print receipt for the transaction.

Allows user to print monthly and yearly income reports.

Easy to identify menu functions.

Allows user to add car damage details.

System should notify about overdue loans.

Could Have Requirements:

Converting the first letters of the word into capitals.

Differentiation into private and corporate customers with different price range applied.

Would Have Requirements:

Allows user to print receipt for returning car.

Allows user to print receipt for paying fine.

Rapid Application Development (www.credadata.com/research/rad.html)

http://www.extremeprogramming.org/map/images/iteration.gif

http://www.extremeprogramming.org/map/iteration.html

User Testing

Login

1 Go to Vehicle Guide

2 Register with Oakwell Hire

4 Make a reservation

5 View Reservation

6 Delete the reservation

7 Logout

8 Leave Feedback