Module Code & Module Title

CS5002NI – Software Engineering

Assessment Type
35% Individual Coursework

Semester
2023 Spring

Student Name: Nischal Khatiwada

London Met ID: 21049542
College ID: np01cp4a210198
Assignment Due Date: 27th April 2023
Assignment Submission Date: 26th April 2023
Submitted To: Rubin Thapa
Word Count (Where Required):

I confirm that I understand my coursework needs to be submitted online via Google Classroom under the
relevant module page before the deadline in order for my assignment to be accepted and marked. I am
fully aware that late submissions will be treated as non-submission and a marks of zero will be awarded.
Table of Contents

1. Introduction................................................................................................................ 1
2. Gantt Chart................................................................................................................. 2
3. Use Case..................................................................................................................... 4
3.1. High Level Use Case Description..........................................................................6
3.2. Expanded Use Case Description...........................................................................8
4. Collaboration Diagram.............................................................................................10
5. Sequence Diagram...................................................................................................15
6. Class Diagram.......................................................................................................... 18
7. Further Development...............................................................................................20
8. Prototype.................................................................................................................. 21
Table of Figures
Figure 1: Gantt Chart....................................................................................................... 3
Figure 2: Use Case Diagram............................................................................................5
Figure 3: Collaboration Diagram for Hire a Vehicle........................................................13
Figure 4: Sequence Diagram for Hire a Vehicle.............................................................16
Figure 5: Class Diagram................................................................................................ 18
Figure 6: Phases of Iteraive Waterfall Model (GeeksforGeeks, 2023)...........................20
Figure 7: Login Prototype...............................................................................................25
Figure 8: Login invalid prototype....................................................................................26
Figure 9: Verification code while Login prototype...........................................................27
Figure 10: Enter verification code with login...................................................................28
Figure 11: Registration prototype...................................................................................29
Figure 12: User profile prototype....................................................................................30
Figure 13: Services prototype........................................................................................31
Figure 14: Book cab prototype.......................................................................................32
Figure 15: Cab arriving prototype...................................................................................33
Figure 16: Track Driver Status prototype.......................................................................34
Figure 17: Payment method prototype...........................................................................35
Figure 18: Payment successful prototype......................................................................36
Figure 19: Rating and Feedback prototype....................................................................37
Figure 20: Hire Vehicle prototype...................................................................................38
Figure 21: Payment method prototype...........................................................................39
Figure 22: Hire payment successful prototype...............................................................40
Figure 23: Join Training Course prototype.....................................................................41
Figure 24: Join Training Course payment prototype......................................................42
Figure 25: Admin Login prototype..................................................................................43
Figure 26: Admin Login verification prototype................................................................44
Figure 27: Admin work page prototype..........................................................................45
Table of Tables
Table 1: High Level Use Case for Take Membership.......................................................5
Table 2: High Level Use Case for Book Cab....................................................................5
Table 3: High Level Use Case for Hire a Vehicle.............................................................5
Table 4: High Level Use Case for Rating.........................................................................5
Table 5: High Level Use Case for Register......................................................................6
Table 6: High Level Use Case for Report Preparation.....................................................6
Table 7: Highe Level Use Case for Join Training Courses..............................................6
Table 8: High Level Use Case for Driver Status...............................................................6
Table 9: Expanded Use Case for Hire a Vehicle..............................................................7
Table 10: Expanded Use Case for Join Training Courses...............................................8
21049542 SOFTWARE ENGINEERING

1. Introduction.

Allgemein is a well-established entertainment company which have been thriving the

entertainment industry for more than ten years with the main source of revenue
generating from a variety of entertainment endeavours. The company has recently
decided to enter the transportation sector with previously owning sizable fleet of
vehicles including cabs, trucks and bulldozers to expand its operation. The company
focuses on providing two key services, the first service being the cab service where the
customers can book the service with the country and the other being rental service
where the customer can rent the automobiles with the predefined rate presenting the
authentic identity document.

Previously during the first coursework, the students were required to prepare a project
charter and SRS, create and environmental model specification, an internal model
specification and a design specification. Different tasks are to be performed in this
coursework which includes preparation of a gantt chart which indicate the schedule for
the development of the system, producing a Use Case diagram, High Level Use Case
Descriptions and Expanded Use Case Descriptions for the system containing all the
features that are required. A Sequence Diagram and a Collaboration Diagram is to be
prepared from a selected Expanded Use Case Diagram. The coursework also includes
preparation of a class diagram, development of prototype with all the features and a
section of further development.

1
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

2. Gantt Chart.

A Gantt chart is a commonly used graphical depiction of a project schedule. It is a

specific kind of bar chart that displays the beginning and ending dates of various project
components, including resources, planning, and dependencies. The Gantt chart was
created by American mechanical engineer Henry Gantt (1861–1919).
Some key points about the Gantt chart are:
 A Gantt chart is a visual aid for planning, controlling, and keeping track of activity
and resources within a project.
 It consists of a list of tasks and bars depicting each task's progress.
 The project timeline is shown by horizontal bars of varying lengths, which can
also include task durations, start and end dates and task sequences.
 For tasks like creating motorways, bridges, and dams, as well as for software
development and creating other products and services, heavy industries employ
Gantt charts (Investopedia, 2022).

While preparing the Gantt Chart for Allgemein, the iterative waterfall model has been
used. Iterative waterfall model incorporates the necessary changes to the classical
waterfall model to make it usable in practical software development projects. It provides
feedback paths from every phase to its preceding phases. In the Gantt chart created
below, during the Design Phase review with the stakeholders subphase works as the
iteration. Any changes required in Requirement Analysis and Specification can be done
in that phase. Similarly, Test Driven Development (TDD) works as the iteration sub
phase in Coding and Unit Testing. Integration and System Testing phase contain
Iterative Regression Testing as the iteration.

2
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 1: Gantt Chart.

3
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

3. Use Case

Use cases are a way for locating, outlining, and organizing system needs in system
analysis. The use case consists of several potential interactions between users and
systems in a specific environment that are associated with a particular objective. The
procedure generates a document that lists each step a user takes to finish an activity.
The use case consists of three essential elements:
 The actor: A single user of the system, or a group of users interacting with the
process.
 The goal: The final successful outcome that completes the process.
 The system: The process and steps taken to reach the end goal, including the
necessary functional requirements and their anticipated behaviours (TechTarget,
2023).

While creating a Use Case diagram some general steps are required to be followed.
The general steps are:
 Identification of Actor: It is the first and the most important step as it represents
the external entities that interact with the system.

 Identification of the Use Cases: Use cases are the features that the system
should contain. Each use case provides some value to the actors.

 Identification of relationship: The lines are drawn to show which actors are
involved in each use case.

4
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 2: Use Case Diagram.

5
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

3.1. High Level Use Case Description

Use Case: Take Membership

Actors: New Customer, Admin
Description: A new customer who is wishing to use the services of Allgemein, fills
out the membership form with appropriate information. After the
membership form is filled a verification code is sent to the customer
for confirmation.Admin takes the membership form and provides the
member details to the customer.
Table 1: High Level Use Case for Take Membership.

Use Case: Book Cab

Actors: Customer
Description: Logging into the system the customer books a cab setting the initial
destination and the location of destination he/she wants to go.
Table 2: High Level Use Case for Book Cab.

Use Case: Hire a Vehicle

Actors: Customer, Driver
Description: Logging into the system the customer chooses to hire vehicles like
bulldozer or cargo trucks choosing the specialist driver as per the
wish. The drivers either accept or reject the request made by the
customers.
Table 3: High Level Use Case for Hire a Vehicle.

Use Case: Give Rating

Actors: Customer
Description: With the use of service, the customers provide rate experiences. The
rating can be provided for both the service and the drivers.
Table 4: High Level Use Case for Rating.

6
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Use Case: Register

Actors: Admin
Description: Admin registers new staffs and vehicles as per the requirement.
Table 5: High Level Use Case for Register.

Use Case: Prepare Report

Actors: Admin
Description: The admin gathers every data and information about the service like
customers, drivers, vehicles, revenue, ratings and generates overall
business report.
Table 6: High Level Use Case for Report Preparation.

Use Case: Join Training Courses

Actors: Customer
Description: The customer makes request to join the training courses which
teaches how to drive heavy vehicles like cargo trucks and bulldozers.
The customer pays certain amount of fee and gets enrolled into the
training courses.
Table 7: High Level Use Case for Join Training Courses.

Use Case: Track Driver Status

Actors: Customer
Description: The customer can track some details of the driver while booking the
cab like where the driver is and whether the driver have accepted or
rejected the cab request made by them.
Table 8: High Level Use Case for Driver Status.

7
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

3.2. Expanded Use Case Description

Use Case: Hire a Vehicle

Actors: Customer, Driver
Description: Logging into the system the customer chooses to hire vehicles like
bulldozer or cargo trucks choosing the specialist driver as per the
wish. The drivers either accept or reject the request made by the
customers.

Typical Course of Events:

Actor Action System Response

1. Customer chooses an option to hire a 2. Presents the option i.e. either bulldozer
vehicle.
3. Chooses within the option.
6. Chooses to use a specialist driver.
8. Chooses a driver within the list.
10. Driver provides the response.
14. Makes the payment.
Table 9: Expanded Use Case for Hire a Vehicle.
or cargo trucks.
4. Checks whether vehicles are available
or not.
5. Asks if the specialist drivers are
required.
7. Show drivers list.
9. Provide request to the driver.
11. Receives response from the driver.
12. Provides the response to customer
from the driver.
13. Indicates for payment.
15. Provides confirmation notification.

Alternative Course of action:

 Line 4. If the vehicles are not available send appropriate notification to the
customer.

 Line 6. Customer chooses to not use a specialist driver then the system indicates
for payment. The customer makes the payment, and the system provides
confirmation notification.

8
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Use Case: Join Training Courses

Actors: Customer
Description: The customer makes request to join the training courses which
teaches how to drive heavy vehicles like cargo trucks and bulldozers.
The customer pays certain amount of fee and gets enrolled into the
training courses.

Typical course of Events:

Actor Action System Response

1. The customer logs in to the system and 2. Presents the list of available courses to
chooses the option to join training the customer.
courses.
3. Selects the course.

4. Fills up the form required to join the 5. Authenticates the details filled in the
training course. form.
6. Indicates for the course payment.
7. Makes payment to enrol in the training 8. Checks whether required amount of
course. payment is made or not.
9. Enrols customer to the training courses
and provides the course details.
10. The customer get enrolled in the
training courses.
Table 10: Expanded Use Case for Join Training Courses.

Alternation Course of Action:

 Line 5. If the details filled in the form are not authentic the system displays an
error message and requests the customer to provides all the details again.

9
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

 Line 8. If the required amount of payment is not made the system displays a
message stating to make complete payment. The customer does not get enrolled
to the training courses. No course details are provided to the customers.

4. Collaboration Diagram

In the Unified Modeling Language (UML), a collaboration diagram also called a

communication diagram illustrates the connections and interactions between software
elements. These diagrams can be used to define each object's function as well as the
dynamic behaviour of a specific use case. Collaboration diagrams are created by first
identifying the structural elements required to carry out the functionality of an
interaction. A model is then built using the relationships between those elements
(TechTarget, 2023).

Creation of a collaboration diagram from a use case consists of various steps which
have been performed and are shown below:
 Identification of the possible classes for the Hire a Vehicle Use Case. It also
includes how these classes are involved during the Hire a Vehicle process. The
involvements are presented below:
 An Object of Class Vehicle will be read to get the options of vehicle
available and present it to the user.
 An Object of Driver class will be read to get the list of drivers and present
it to the user when the user chooses to hire a vehicle with specialist driver.
 An Object of class Payment will be created to record the payments made
by the user.

 Drawing an Object symbol for each of the Domain Class Objects.

10
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

 Adding a control object with the name ‘Hire Vehicle’.

 Adding a boundary object with the name ‘Hire VehicleUI’

11
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

 Adding required Actors and Associations to show the connection between the
objects.

12
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

 Adding Messages.

13
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 3: Collaboration Diagram for Hire a Vehicle.

The above collaboration diagram illustrates the connections and interactions between
the software elements. The collaboration diagram is created for hire a vehicle use case
which is a service in Allgemein allowing users to hire heavy vehicles like bulldozers or
trucks along with the specialist drivers if required. In the collaboration diagram, there are
two actors Customer and Driver. The diagram contains a boundary object named as
‘Hire VehicleUI’ and a control object with the name ‘Hire Vehicle’. There are three
domain objects present in the diagram which includes Vehicle, Driver, and Payment.
The interaction between the actor and the objects in the above diagram are described
below:
 The actor provides hire details in the UI which is forwarded to the control object.

14
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

 The vehicle option is extracted from the vehicle object and is provided to the
control object which then sends it to the Hire VehicleUI which can be seen by the
user.
 The customer chooses the required option which is forwarded to control object.
 The vehicle details are obtained from the Vehicle object and is displayed to the
user’s interface (UI).
 The customer decides to hire specialist driver. The boundary object requests the
list of drivers to the control object. The list of the drivers is obtained from the
Driver object and is provided to the boundary object.
 The customer chooses the driver from the provided list.
 A request is sent to the driver. The driver provides the response to the boundary
object.
 The indication for payment is sent by the control object to the User Interface (UI)
also called a boundary object.
 The customer makes the payment in the UI and the payment details are sent to
the control object. A new domain object with the name Payment is created which
records the Payment made by the customer.
 A payment successful message is provided from Payment object to the control
object which then sends the payment successful notification to the UI. The
customer gets notified about the confirmation of the payment.

15
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

5. Sequence Diagram

A sequence diagram is a type of interaction diagram because it illustrates the

interactions between a group of items and the order in which they occur. Software
engineers and business experts use these diagrams to comprehend the specifications
for a new system or to describe an existing procedure. Event diagrams and event
scenarios are other names for sequence diagrams (Lucidchart, 2023).

The creation of a sequence diagram from a Use Case requires identification of the
objects and the actors that are involved. The actors involved for creation of Hire Vehicle
sequence diagram are listed below:
 Customer
 Driver
And the objects involved during creation of a Hire Vehicle sequence diagram are:
 Hire VehicleUI
 Hire Vehicle
 Vehicle
 Driver
 Payment

The involvement of the domain object in the sequence diagram for Hire Vehicle are
presented below:
 An Object of Class Vehicle will be read to get the options of vehicle available and
present it to the user.
 An Object of Driver class will be read to get the list of drivers and present it to the
user when the user chooses to hire a vehicle with specialist driver.
 An Object of class Payment will be created to record the payments made by the
user.

16
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 4: Sequence Diagram for Hire a Vehicle.

17
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

The above sequence diagram illustrates the interaction between the actors and the
domain objects while hiring a vehicle. The customer chooses an option to hire a vehicle
and inserts hire details and provides request to hire vehicle. The UI provides request for
vehicle to control object with the message ‘requestforVehicle()’. The control object then
invokes ‘getVehicleOption()’ method to retrieve the options of vehicle available to be
hired from the Vehicle object and the option are provided to the user in the UI. Now the
interactions are executed in a loop fragment. The customer chooses a vehicle within the
options in the UI which is then forwarded the control object ‘Hire Vehicle’. Now, the
‘requestVehicle()’ method is invoked by control object to get the vehicle requested by
the user. The availability of the vehicle is checked, and the details of the vehicle are
sent to the user in the interface. The UI asks the customer whether a specialist driver is
required or not.

Now the interactions between the actors and the objects are executed in a condition
fragment. If the user requires specialist driver, the UI sends a message requesting the
list of drivers to the control object. The control object invokes ‘getDriverList()’ method
from the Driver object to retrieve the list of the specialist drivers. Then, the lists are
forwarded to the users in the user interface. The customer makes the choice of the
driver within the list. Now the UI sends request to the driver and the driver provides
response. After that the payment indication notification is displayed to the user in UI.
Likely, if the user does not require any specialist driver, then the payment indication
notification is displayed to the user in UI.

The customer makes the payment, and the UI forwards the payment details to the
control object. Now a new domain object with the name ‘Payment’ is created to store
and record the details of the payment made by the customer. The payment is verified
within the object. Again, the interactions are executed in a condition forward and if the

18
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

payment made by the customer is successful then, a successful notification is sent to

the user in the UI else an unsuccessful notification is sent.

6. Class Diagram

In software engineering, a class diagram in the Unified Modeling Language (UML) is a

type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among
objects (Visual Paradigm, 2022).

19
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 5: Class Diagram

The above class diagram is for the Allgemein system which allows customer to book
cab and hire vehicles. The diagram describes the structure of the system with classes,
their attributes, methods and the relationship among them. The structure of the system
is described below:
 An admin adds several Training Courses to the system.
 An admin generates either one or multiple report which can be customer report,
business report, staff report and many more.

20
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

 An admin posts single or several announcements in the system.

 An admin hires several staffs which are required for the company.
 An admin also registers multiple vehicles that are required for providing services
to the customers.
 The classes Training Course, Report, Announcement, Staff, Vehicle all can be
the part of class Admin.
 An admin hires multiple drivers required for driving the vehicles.
 A driver drives multiple vehicles.
 The Specialist Driver class is a part of class Driver.
 A single specialist driver is hired while hiring a vehicle by the customer.
 A customer can book only one cab at a time.
 A customer can hire multiple vehicles.
 A customer gets a single membership, but an admin takes multiple
memberships.
 A customer can join one or multiple training courses.
 A customer provides one or multiple ratings. Either it can only be for the driver, or
it can be for driver, vehicle, service and others.
 A customer makes payment for single service or multiple services.

7. Further Development

The analysis and design diagrams have been completed till date in the Allgemein
system. The Use Case Diagram which shows the interaction between users and the
systems in a general way have been made. Other diagram like collaboration diagram
which illustrates the connection and interaction between the software elements and
sequence diagram which illustrates the interactions between a group of items and the

21
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

order in which they occur have also been designed. Likewise, a class diagram has been
made for the Allgemein system which describes the structure of the system with
classes, their attributes, methods, and the relationship among them.

Now, for the further development of the Allgemein system the iterative waterfall mode
will be used. The iterative waterfall model has been established to incorporate the
necessary changes to the classical waterfall model to make it usable in practical
software development projects. It is almost the same as the classical waterfall model
except some changes are made to increase the efficiency of the software development.
The iterative waterfall model provides feedback paths from every phase to its preceding
phases, which is the main difference from the classical waterfall model.

Figure 6: Phases of Iteraive Waterfall Model (GeeksforGeeks, 2023).

 Requirement gathering: In this phase the goals and requirement of the website
are determined. The analysis and design diagram have already been created for
Allgemein system so, this phase has already been completed.

 Design: In this phase, the team will create a detailed design specifications based
on the analysis and diagrams created in the Requirement gathering phase.

22
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Before moving on to the next phase, the design specifications must be approved
by the stakeholders. The changes required in the specifications must be made.
 Choice of Architecture: The microkernel architecture pattern is the best
choice for the Allgemein system as the system needs to be scalable and
modular. The microkernel design pattern offers flexibility as well as feature
isolation and division by allowing you to add other application features as
plug-ins to the main program. The Allgemein system requires additional
features over time and control over which user gets which features so, the
microkernel architecture pattern is the best fit.

 Development: During this phase, the design specifications that were created in
the design phase will be implemented. The development process follows an
iterative waterfall methodology, with each stage building on the one before, and
requires close collaboration between the development and design teams to
ensure that the implementation adheres to the original plan.
 Design Pattern: The design pattern that fits well with the micro-kernel
architecture is the Observer pattern. The observer pattern is a
behavioural design pattern that defines a one-to-many relationship
between objects. The observers are notified by an object called subject
about any changes in its state. As the Allgemein system provides services
to the users, whenever the customer uses any service, the system needs
to update the changes within its server to ensure the activities performed
in the system are up to date. The server in Allgemein acts as the observer
of the microkernel and any actions performed by the users related to
services like book cab, hire vehicle and others the server gets notified.
 Programming Paradigm: The programming parading that will be used for
the development of Allgemein system is Object-Oriented Programming
(OOP). OOP paradigm is based on the ideas of classes and objects. It is
used to organize software into straightforward, reusable classes of code
blueprints, which are then utilized to build distinct instances of objects.
The use of OOP can solve any complex problems that occurs during the

23
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

development of Allgemein system. It also reduces the development time

and include the code reuse. The OOP paradigm provides huge benefit to
the system that uses iterative waterfall methodology, micro kernel
architecture and Observer Pattern.
 Coding Platforms: The coding platforms that will be used during the
development of Allgemein system includes Visual Studio (VS) code, Intellij
IDEA, Blue J or Android Studio.

 Testing: During the Testing phase, the system made in the previous phase is
thoroughly tested to ensure that it meets the requirement and the functions
properly. The testing approaches that align with microkernel architecture,
Observer design pattern and with the iterative waterfall methodology are:
 Unit Testing: It is a testing approach which tests every independent
module to determine if there are any issues or not. During the testing of
Allgemein system, the unit testing will be used to test the servers and
microkernel independently.
 Integration Testing: It is a testing approach in which individual software
modules are combined and tested as a group. During the testing of
Allgemein system, the integration testing will be used to test the
communication between the components in the system to ensure that the
components function properly.
 System Testing: It is a testing approach that tests the complete and fully
integrated system to ensure that the system meets the requirements and
provides the required functions. During the testing of Allgemein system,
the system testing will be used to monitor the performance, security, and
ability of the system.
 White box testing: It is a testing method that examines the internal
organization, code, and design of software to validate input-output
functionality and enhance design, usability, and security. During the
testing of Allgemein system, the white box testing will be used to test the
internal structure, code and design of Allgemein. The testing will be

24
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

performed so that the Allgemein system contains enhanced design,

security, and other functionalities.
 Black box testing: It is a testing approach that involves testing a system
with no prior knowledge of its internal working to generate responses to
test actions. During the testing of Allgemein system, the black box testing
will be used to identify whether the Allgemein system functions properly
with providing the appropriate services to the users or not.

 Deployment: During this phase, the produced system is deployed into the real
world and made available for the use of public. The deployment plans that are
included while the release of the Allgemein system is defined below:
 Creation of a release plan which includes the process of the system
deployment, time, Rollback plan and many more.
 Creation of a deployment plan which includes the identification of the
environment where the system is to be deployed, steps and procedure of
deployment and others.
 Deploy the system into the appropriate environment.
 Performing post deployment activites which includes validating and
verifying the performance of the system, observing the responses from the
users, thorough monitor, and maintenance and so on.

8. Prototype

25
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 7: Login Prototype.

26
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 8: Login invalid prototype.

27
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 9: Verification code while Login prototype.

28
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 10: Enter verification code with login.

29
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 11: Registration prototype.

30
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 12: User profile prototype.

31
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 13: Services prototype.

32
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 14: Book cab prototype.

33
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 15: Cab arriving prototype.

34
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 16: Track Driver Status prototype.

35
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 17: Payment method prototype.

36
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 18: Payment successful prototype.

37
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 19: Rating and Feedback prototype.

38
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 20: Hire Vehicle prototype.

39
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 21: Payment method prototype.

40
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 22: Hire payment successful prototype.

41
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 23: Join Training Course prototype.

42
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 24: Join Training Course payment prototype.

43
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 25: Admin Login prototype.

44
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 26: Admin Login verification prototype.

45
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

Figure 27: Admin work page prototype.

46
NISCHAL KHATIWADA
21049542 SOFTWARE ENGINEERING

9. Conclusion

47
NISCHAL KHATIWADA