CHAPTER ONE1.1 IntroductionVehicle maintenance and deployment
offices were structured and setting up in early days, as two
separate offices in the organization. The maintenance unit has a
full responsibility over addressing and reporting about each type
of vehicle which undergone maintenance process. The deployment
office, on the other hand, plays a great role in the cars and buses
allocation and distribution process. Additionally, the deployment
office organizes the information which has ended up under
maintenance office, for the sake of report generating and creating
deployment plans. The working system however literally faces
different problems while managing and controlling distributed data
in between the two offices of deployment and maintenance.
Apparently, vehicle deployment office has data duplication in its
system about a single entity and sorting the functional vehicles at
work then the once that are not functional becomes uncertain and un
justifiable. Currently, the organization applies the manual system
which is making use of different forms and memos for same
applications and gradually the number of forms in the operation
Creates complicated file handling system which is so difficult in
organization and creating different queries.Keeping in view of all
such problems, the existing system should be converted to automated
system for information process, management and dissemination. The
data processing structure should be centralized and functioned in
accordance with the hierarchical structure. We as team members have
an ambition to design and implement a working automated model of
the system in the problem area.
.1.2Background of the OrganizationTashale vehicle maintenance
and deployment is found in Ethiopia, Addis Ababa, Gotera. Vehicle
maintenance and deployment was begun to give service at
1985E.C.Theorganization is one of the well-known [organization]in
providing quality services to its customers. The organization
nowadays it is performing expansion and development plan which
expects a combined effort of different sectors within itself. Being
as one of the vital gain to the development plans vehicle
maintenance and deployment plays a greater role with respect to the
technical support. Technology is spreading its wings in almost
every walks of human life activities. Now days it is better if
every activity is done using which is automated system in order to
fulfill the need of human being, Organization etc. As todays world
there are many organizations and each organizations needs to be
preferable, computable, work on faster way in order to satisfy
users interest etc. i.e. they should have facilitate their
activities in computerized way. The organization uses manual system
like scheduling the vehicles to give service, scheduling vehicle
maintenance, putting detail information of each vehicle. While
giving those activities it stores the data in a file cabinet which
creates inefficiency in terms of access, track, and store
information in the working environment.
1.3 Statement of the ProblemAs starting point for problem
definition we try to identify how documents were stored in the
office and try to get some information about the current system
from staff members. From our observation of the current system and
the data we collected we identified the following major problems
and some others not listed here.
In Vehicle maintenance and deployment offices information
exchange and service control is processed in manual way and which
makes the communication of the working environment difficult to
manage and control. Difficulty to get the required detailed
information about specific vehicle or item at one place. And due to
the presence of data redundancy under different titles about the
same object, the creation of summary and the process of generating
report about individual item has become a challenge in the existing
system. It takes time to prepare the schedule of maintenance for
vehicles and the vehicles to run extra service time and this would
increase the possibility of vehicle failure. Files are randomly
processed despite the position and hierarchy of workers or clients
in the exist. For payment purpose they use manual material like
pen, pencil, paper, calculator to calculate payment for each
individual vehicle maintained. The way using this manual method
might be prone to error. Many files are easily lost or damage.
Resource consuming. Lack of organized data. Whenever updating is
required, it takes considerable time and there will be a high
probability of creating inconsistency of data and error. Task with
existing system is highly prone to error. Searching for customer
information is too difficult which needs visiting through each
record. Searching for vehicle information is too difficult which
needs visiting through each record. Searching for vehicle owner
information is too difficult which needs visiting through each
record.
From day to day vehicles are increasing, so accordingly to meet
the demands of the clients to speed the work as well as to save the
time and money, we thought that Tashale's vehicle maintenance and
deployment must be computerized soon.
1.4 Objective of the Project 1. 4.1. General ObjectiveThe main
objective of this project is to develop a reliable and more secured
automated Vehicle Maintenance and Deployment Information Management
System. 1. 4.2. Specific ObjectiveIn order to achieve the general
objective mentioned above the project will have the following
specific objectives in hand: To develop mechanisms in which
information of Vehicle Maintenance and Deployment will be well
organized and managed in the system. Implementing a Centralized
database system with respect to the hierarchy of offices and their
respective clients. Generating reports between vehicle maintenance
and deployment offices respectively for better understanding and
common working ground. Develop automated system for information
process, and storage data.
1.5 Feasibility of the Project 1.5.1 Operational FeasibilityThe
system is now deployed and works on Microsoft operating system
without any flaws, providing the employees with high benefits of
operational feasibility. The system is also tested on different
basis and mechanisms of tasting a module and the team founds the
already built system to fit any inquiries and expectations..
1.5.2 Technical FeasibilityThe system is going to be implemented
using php programming language. and the team tried to use any
methodologies at hand and developed the system with fair
practice.The total aggregated effort now makes the system to be
technically feasible1.5.3 Economic FeasibilityThe system developed
now is economically feasible and the benefit is outweighing the
cost. Since this project already computerizes the existing system,
by now the reduction of cost for materials used in manual operation
becomes beneficiary to the organization.Generally, the system we
developed for vehicle maintenance and deployment office brought a
number of Tangible and intangible benefits. Tangible benefits
Reduction of paper and pen. Reduction of space needed to record
available information.Intangible benefit: Improve employees moral
Give better and effective service Error reduction Increase security
Increase speed1.5.4 Behavioral or Political Different concerned
individuals such as the manager, secretary and other employees of
the association have good approach and view towards this project
and they wish to play an important role on this system by giving
good ideas to produce better and efficient results.
1.6 Scope, Limitation and Significance of the Project1.6.1 Scope
of the ProjectScope defines the boundaries of project what part of
the business is to studied, analyzed, designed, implement and
improve [1].As the working system makes use of manual operations in
vehicle deployment and maintenance office therefore the scope of
our project plans and targets is developing and implementing a new
automated system to replace and solve the problems within existing
manual system.Due to material and other constraints the project is
limited to automate: Vehicle record of the system Vehicle owner
record of the system Schedule the vehicles Store maintenance
request The system will process payment system The system will
process payment discount Searching, viewing & updating
registered vehicles. Searching, viewing & updating registered
vehicles owner. Viewing & updating maintenance request.
1.6.2 The Significance of the Projecti. Avoiding improper
resource consumption.ii. Avoiding data loss because of improper
data storage.iii. Minimize cost of operationsiv. Minimize time
delay in getting information/reports. v. Higher authority can get
summarized information via manager for quick decision making
process.1.6.3 Limitation of the ProjectThe limitations in
performing this project are: The system excludes daily activities
that are allocation of different vehicles to different
destinations. Deficiency of Time Lack of resource, especially
Internet access and reference materials Lack of experience Lack of
money
1.7 Beneficiaries of the SystemThere are different bodies that
will be benefited from this system. The main beneficiary of this
system is vehicle maintenance and deployment office in which,
first, the environment will be changed to a computerized system,
which improves the quality of internal operations as well as
services distributed between workers in the office. Secondly the
problem associate with manual processing is minimized and the
quality of work and services improved. Additionally the office will
be highly benefited from the system because of the aspects such as
the system reduces wait time of workers, the vehicles will be
sorted in unique identification methods, and vehicle scheduling
will be highly processed in digitally working system. The managers
benefit of quick report generated by the system.1.8 Methodology
Methodology is the way in which information is gathered to develop
of a system. Method used to facilitate us to capture information
about the system [2]. Among the different methodologies in practice
we thoughtfully pay our time to work on PHP programming language
for achieving effective and reliable working system in the future.
The reason why we use the php programming language is that it is
very simple language. The group members are going to employ the
following methodologies in the course of developing the suggested
system. 1.8.1 Data Source Different documents and files from
maintenance and deployment offices. Different critical reports
highlighting the maintenance and deployment requirements.1.8.2Data
Gathering Methodology Interview: - we gathered information by
asking personnel in vehicle maintenance and deployment offices from
the organization. Document Analysis: - To get more secondary source
information and ideas about the vehicle maintenance deployment
systems, we referred journals, project report documents and other
reading materials that were needed to develop this system.
Observation Questionnaires Internet Email By phone1.8.3Analysis
MethodologyData analysis methodology we use to perform the project
is Object Oriented Analysis (OOA).Use case diagram, activity
diagram, class diagram, state chart diagram, User Interface and
sequence diagram.1.8.4 Implementation MethodologyInclude user
notification, user training, installation of hardware and software
and integration of system until operated. Front End: PHP Back End:
MYSQL1.8.5 Testing MethodologyBefore directly deploying this
system, the team plans to perform different tests for its
functionality and meeting customers need. First the team tests each
unit at each phase. So, if a problem is encountered it will
immediately fixed. Then the team will perform an integration
testing to check whether the system meets all the functional
requirements. System is proposed to be tested using the following
system testing procedures.
Black Box Testing.Black-box testing refers to tests that are
conducted at the software interface. Although they are designed to
uncover errors, black-box tests are used to demonstrate that
software functions are operational, that input is properly accepted
and output is correctly produced, and that the integrity of
external information (e.g., a database) is maintained. A black-box
test examines some fundamental aspects of a system with little
regard for the internal logical structure of the software.
1.9 Tools Tools we will use to develop this project can be
divided as Software Requirements:Operating system Window7Web
technology PHP and Java scriptWeb server XamppDatabase MYSQL
Hardware Requirements:Processor PentiumDocumentation MS
wordPresentation MS power pointModeling Rational Rose1.10
Beneficiaries of the SystemThere are different bodies that will be
benefited from this system. The main beneficiary of this system is
vehicle maintenance and deployment office in which, first, the
environment will be changed to a computerized system, which
improves the quality of internal operations as well as services
distributed between workers in the office. Secondly the problem
associate with manual processing is minimized and the quality of
work and services improved. Additionally the office will be highly
benefited from the system because of the aspects such as the system
reduces wait time of workers, the vehicles will be sorted in unique
identification methods, and vehicle scheduling will be highly
processed in digitally working system. The managers benefit of
quick report generated by the system.
1.11 Project SchedulenoProject activities
Task descriptionExpected Time to finishLast date for
Submission
1Chapter OneProject proposalNov 22- Dec 3Dec 3/12/2013
2Chapter TwoDescription of the Existing SystemDec 4- Dec 14Dec
25/12/2013
3Chapter ThreeSystem AnalysisDec 26-Jan 28 Feb 15/12/2014
4Chapter FourSystem DesignMarch 10- April 15April 18
5Chapter FiveImplementation and TestingApril 20- May 28May
30
6Final DocumentPresentation June 13- June 23June 25
CHAPTER TWO2. Description of the Existing System and Proposed
System2.1 Introduction to the Existing SystemThe maintenance and
deployment unit has a full responsibility over addressing and
reporting about each typical vehicle which undergone maintenance
process and organizes information, which has ended up under spare
part offices for sake of report generating and creating deployment
plans. The head of vehicle deployment and maintenance office
(manager) has a crucial role and responsibility to control and
coordinate the overall process generated in the system.The working
system however literally faces different problems while managing
and controlling distributed data. Vehicle deployment office has
data duplication also in its system about a single entity and
sorting the functional vehicles at work. The currently working
manual system is making use of different forms and memos for same
applications and gradually the number of forms in the operation
creates complicated file handling system which is so difficult in
organization and creating different queries. If an authorized
person needs information about a specific vehicle he or she must go
through all the records manually which is so exhaustive and
inefficient. 2.2 Players of the Existing System The actors in the
current system are:- Vehicle scheduler Vehicle deployment manager
Secretary Mechanic
2.3 Major Activities in the Existing System Like Inputs,
Processes and OutputsThe following section summarizes the function
of existing system with their input, process and output: Vehicle
Scheduler Input:-receive the number of available vehicles which are
ready for transportation. Process: - schedule the vehicles.
Output:- give dispatch for the vehiclesDeployment Manager Input:-
accesses all information of the entire system and generate reports.
Process:- control all functions Output: -send report to the
respected body.Mechanic Input: - receive form that contains
information about the vehicle damage. Process: - repair (maintain)
the problem of the vehicle. Output: - inform to deployment manager
for scheduling the vehicle to give service.Secretary Input: -
collect all forms about vehicles status to know detail information
like how many times refuel in a day. Process: - writing letters and
all information based on the forms. Output:- send the letters to
respected body.
2.4 Business Rule Vehicles should be maintained when they are
damaged or based on schedule maintenance report. Vehicle should
have a display banner and a dispatch to make travel. Vehicle
scheduler should receive a status of vehicle information and must
prepare a deployment plan according to the data gathered. When an
employee need to transport must expect at the time of the service.
Different forms and documents should be fulfilled by the respected
body.
2.5 Report Generating in the Existing System In the manual
system reports are practically generated from vehicle maintenance
and deployment to state development facility management directory
office per three month. The state development facility management
directory office has responsibility to send the report to strategic
planning and programming directory office in the organization for
Further Consideration in decision making processes.2.6 Bottlenecks
of the Existing System 2.6.1 Performance (Response Time)In terms of
performance, the existing/manual system is not as satisfactory
because it is slow/time consuming, energy consuming and does not
support automated information system about the availability of
vehicles and their status in a fashion. In maximum cases it delays
other systems in their duties.2.6.2 Input and Output of
InformationIn the current system of Tashale Vehicle Maintenance and
Deployment, the information of a certain vehicle could be
inaccurate, redundant and inflexible and these inputs may leads to
create confusion and unnecessary burden on employees and produce
inaccurate output.2.6.3 Security and ControlsSince every file and
record of the status of vehicles is stored in the manual way, it is
difficult to control and secure these manual files/data. Any
unexpected disaster may collapse the whole database. 2.6.4
EfficiencyExisting system has limitations in terms of speed,
non-redundant, centralized / decentralized database and other
competencies than new system.
2.7 Practices to be preservedThe existing system of this project
uses files and forms that are used to perform the business rules,
describe the operations, definitions and constraints that apply in
the maintenance and deployment system and for payment purpose they
use manual material like pen, pencil, paper, calculator to process
payment for each individual vehicle maintained. Team member
preserve the following practices from the existing system. The
priority of scheduling a vehicle is dependent on the vehicle
problem that is given to the organization. The one that is more
sensitive and convincing mission always served firstly. Besides in
case of emergency vehicle scheduling is highly affected.
2.8 Description of Proposed SystemThe new system addresses the
problems of the existing system by supporting the maintenance and
deployment management with an automated technology by providing
well organized, flexible and effective means of communication.
These includes:- Changing the manual system in to automated system
without affecting the structure of the organization. Developing
easily accessible information/documents that is clear to employees
when accessing data in 24/7 model Avoiding wastage of time during
searching information due to holidays/ office time restrictions
etc. To avoid redundancy of records in the working system as the
proposed system provides mechanisms to sort files in database
system. To avoid wastage of paper work on records in the system. To
avoid manual payment system which prone to errors.
2.9 Requirements of the Proposed System 2.9.1 Functional
Requirements Vehicle registration Search vehicle information Update
vehicle record Vehicle owner registration Search vehicle owner
Update vehicle owner Schedule vehicles Maintenance request record
View Maintenance request Payment System and Discount Generate
report
2.9.2 Nonfunctional RequirementsThis requirement considers only
the front end values rather than values that have relation with the
database. In systems engineering and requirements engineering, a
non-functional requirement is a requirement that specifies criteria
that can be used to judge the operation of a system, rather than
specific behaviors. This should be contrasted with functional
requirements that define specific behavior or functions. In this
system user interface is designed user-friendly so that every user
should feel comfort to use it. The architecture of this system
presents better performance and quality outputs reports and
information dissemination framework in terms of:-
Performance This system proposed to maintain the following
nonfunctional standards towards - Timeliness Accuracy.
Authorization restriction and privileges Security and usability of
information Testability, maintainability and scalability User
InterfaceDescribe the logical characteristics of each interface
between the system and the users. This may include any GUI
standards, screen layout constraints and functions that will appear
on every screen and so on. So this system does these all functions
in easy and efficient way. Security and Access
permissionsConsideration of the security of the system has a great
advantage for this system, because the database should be secured
from the unauthorized users. Only the maintenance employers and
those who have access permission are authorized to access the
database. To prevent from the unauthorized use the system manages
the use of admin password and assigns a privilege only for workers
or clients in the system.
Backup and Recovery We have used backup mechanisms such as
removable flash disks, CDs and hard disks. Because the data might
lose due to computer viruses or power fluctuation
CHAPTER THREESystem Analysis3.1 IntroductionThe project
development team used an object oriented system development
methodology. Because the Object system development approach gives
easier and natural way to break down problems into simple, small
and manageable components so that it reduces the vague appearance
of the big problem. Moreover, it is predominately used and popular
method in present software development trend.The major activities
described in this chapter are Constructing a use case model
,Documenting the use case course of events, constructing sequence
and activity diagram analysis level class diagram and user
interface design about the proposed system.3.2 System Requirement
Specifications (SRS)A System Requirements Specification (SRS) (also
known as a Software Requirements Specification) is a document or
set of documentation that describes the features and behavior of a
system or software application. It includes a variety of elements
that attempts to define the intended functionality required by the
customer to satisfy their different users. In addition to
specifying how the system should behave, the specification also
defines at a high-level the main business processes that will be
supported, what simplifying assumptions have been made and what key
performance parameters will need to be met by the system.3.2.1 Use
Case DiagramUse case illustrates a unit of functionality provided
by system. The main purpose of the use case diagram is to help
development teams visualize the functional requirement of a
system,including the relationship of actors (human beings who will
interact with the system) to essential processes, as well as the
relationship among different use cases. Use case diagram generally
show groups of use cases either or use cases for the complete
system, or a breakout of a particular group of use cases with
related functionality. A use case diagram is typically used to
communicate the high-level functions of the system and the systems
scope.Use Case represents interaction between the user and the
system.
Figure 3-1: Use Case diagram3.3 Use Case DocumentationUse case
documentation describes that the basic flow of information of use
cases that is every activities to be done starting from
precondition up to post condition.
Table 3-3-1: Use Case Documentation for LoginThis table
describes or shows the action that must implement to access the
system. Use case nameLogin
Use case numberUC1
Actor(s)System administrator, Deployment manager, Secretary
,Mechanic, Scheduler ( User)
DescriptionThe authentication for authorized users in the system
and deliver them the right to visit their specified windows
Basic course of action Actors actionStep 1: User initiate to
loginStep 3 : User enter user name and password systems
responseStep 2: The system displays the login form.Step 4: The
system checks the validity of the entry and then verifies whether
the user is authenticated and authorized. Step 5: If the user is
authenticated & authorized for the tasks the system displays
the main page for further action.
Alternate courses of action Step 4: If the users entry (user
name and Password) is not validated and verified the system
displays error message and return to step 2.
Pre-condition The user should be registered.
Post condition User able to access the required main page.
Table 3-3-1: Use Case Documentation for Vehicle Owner
Registration This table describes or shows the action that must
implement by deployment manager to register the vehicle owner.Use
case nameVehicle owner registration
Use case numberUC2
Actor(s)Deployment manager
DescriptionThis use case describes to register the status of
detail information of vehicle owner.
Basic course of action Actor ActionStep1: Deployment manager
initiate to loginStep3: Deployment manager enter user name and
password Step6: fill all the necessary information about the
vehicle owner
System ResponseStep2: System display login page.Step4: System
checks the validity of username and password and then checks for
authentication and authorization.Step5: System display vehicle
owner registration page.Step7: System checks the validity of the
informationStep8: System registered the vehicle owner
Alternative courses of action Step 4: if the user name and
password is not validated and verified then the system respond
error message and return to step 2.Step 7: If the required input is
not validated the system displays error message and go to step6
Pre-conditionDeployment manager should be registered
Post conditionVehicles owner will be registered.
Table 3-3-3:Use Case Documentation for Search Vehicle Owner
InformationThis table describes or shows the action that must
implement by deployment manager and scheduler to veiw the vehicle
owner information.
Use case nameSearch vehicle owner information
Use case numberUC3
Actor(s)Deployment manager, Scheduler
DescriptionThis use case describes when deployment manager and
scheduler went to know detail information about vehicle owner.
Basic course of action Actor ActionStep1: User initiate to
loginStep3: User enter username and passwordStep6: User insert
engine no of the vehicle ownerStep8: User click on Search
button
.System ResponseStep2: System displays the login form.Step4:
System checks the validity of username and password and then checks
for authentication and authorization.Step5:System display Search
Vehicle owner pageStep 7: System checks the validity of the engine
numberStep9: System display detail information of vehicles
owner
Alternative courses of actionStep 4: If the username and
password is not validated and verified, system displays error
message and go to step2Step 9: if the engine no is not validated
and verified, the system displays invalid input message and go to
step8
Pre-condition:The Deployment manager and Scheduler must be
authenticated
Post condition Vehicle owner information will be displayed
Table 3-3-4: Use Case Documentation for Update Vehicle Owner
RecordThis table describes or shows the action that must implement
by deployment manager to update the vehicle owner record.Use case
name Update vehicle owner record
Use case numberUC4
Actor(s)Deployment manager
DescriptionDeployment manager modify vehicle owner information
when it is necessary
Basic course of action Actor ActionStep1: Deployment manager
initiate to loginStep3: Deployment manager enter username and
password Step 6:Deployment manager enter information related to the
record to be updatedStep8:Deployment manager updates the vehicle
owner field
System ResponseStep2: System display login page.Step4: System
checks the validity and then authentication and authorization of
username and password.Step5: System display update vehicle owner
page. Step7: System displays the vehicle owner record to be updated
Step9:System validate information Step10: System updates the
vehicle owner record.
Alternate courses of action Step 4: If the username and password
is not validated and verified, system displays error message and go
Step2Step 9: if the input is not validated and verified, the system
displays invalid input message and go to step6
Pre conditionDeployment manager should be registered
Post conditionVehicle owner record will be updated
Table 3-3-5:Use Case Documentation for Request Maintenance
RecordThis table describes or shows the action that must implement
by mechanic for Request maintenance record.Use case nameRequest
maintenance record
Use case numberUC5
Actor(s)Mechanic
DescriptionA Mechanic formulate request to repair vehicle. The
request describes briefly the vehicle problem
Basic course of action Actor ActionStep1: Mechanic initiate to
loginStep3 Mechanic enter user name and passwordStep6: Mechanic
enter information related to the maintenance request for the
vehicleSystem ResponseStep2: System display login form.Step4:
System checks the validity of username and password and then checks
for authentication and authorization.Step5: System display vehicle
maintenance form.Step 7: System checks validity of the
informationStep 10: System store the data in the database
Alternate courses of action Step 4: if the user name and
password is not validated and verified then the system respond
error message and return to step 2.Step 7: if the data is invalid
or incorrect the system displays invalid input message and return
to step 6.
Pre conditionMechanic is registered
Post conditionMaintenance record will be created.
Use Case Documentation for View Scheduled Vehicle Use case
name:View scheduled vehicle
Use case number:UC6
Actor(s): Scheduler
Description:This use case describes when Schedular need to know
the schedule program
Basic course of action :Actor Action
Step1: Scheduler initiate to loginStep3 Scheduler enter user
name and passwordStep6: Scheduler click on view schedule button
System Response
Step2: System display login form.Step4: System checks the
validity of username and password and then checks for
authentication and authorization.Step5: System display Scheduled
vehicle pageStep7: System display scheduled vehicles
Pre condition:Scheduler must registered
Post condition:Scheduled vehicles will be viewed
Table 3-3-6: Use Case Documentation of View Scheduled
Vehicles
Use Case Documentation for Prepare Vehicle Schedule Use case
namePrepare Vehicle schedule
Use case numberUC7
Actor(s)Scheduler
DescriptionThis use case describing process of scheduling
vehicle will be carried out.
Basic course of action Actor ActionStep1: Scheduler initiate to
loginStep3:Schedler enter username and password Step6: scheduler
search the vehicleStep8: scheduler fill the required data about the
vehicle
System ResponseStep2: System display login page.Step4: System
validates and verifies authentication and authorization of username
and password.Step5: System display vehicle schedule page.Step7:
System display detail information of the vehicle.Step 9: System
validate vehicle informationStep 10 : System scheduled the
vehicle
Alternative courses of action Step 4: If the username and
password is not validated and verified, system displays error
message and go to step2Step 9: if the input is not validated and
verified, the system displays invalid input message and go to
step8
Pre-conditionScheduler must registered
Post conditionVehicle will be scheduled
Table 3-3-7: Use Case Documentation of Prepare Vehicle
Schedule
Use Case Documentation for Search Vehicle InformationUse case
nameSearch vehicle information
Use case numberUC8
Actor(s)Deployment manager, Scheduler
DescriptionThis use case describes when deployment manager and
scheduler went to know detail information about vehicles.
Basic course of action Actor ActionStep1: User initiate to
loginStep3: User enter username and passwordStep6: User insert
engine no of the vehicleStep8: User click on Search button
.System ResponseStep2: System displays the login form.Step4:
System checks the validity of username and password and then checks
for authentication and authorization.Step5:System display Search
Vehicle pageStep 7: System checks the validity of the engine
numberStep9: System display detail information of vehicles
Alternative courses of actionStep 4: If the username and
password is not validated and verified, system displays error
message and go to step2Step 9: if the engine no is not validated
and verified, the system displays invalid input message and go to
step8
Pre-condition:The Deployment manager and Scheduler must be
authenticated
Post condition Vehicle information will be displayed
Table 3-3-8: Use Case Documentation of View Vehicle
Information
Use Case Documentation for Vehicle Registration Use case
nameVehicle registration
Use case numberUC9
Actor(s)Deployment manager
DescriptionThis use case describes to register the status of
detail information of vehicle.
Basic course of action Actor ActionStep1: Deployment manager
initiate to loginStep3: Deployment manager enter user name and
password Step6: Fill all the necessary information about the
vehicle
System ResponseStep2: System display login page.Step4: System
checks the validity of username and password and then checks for
authentication and authorization.Step5: System display vehicle
registration page.Step7: System checks the validity of the
informationStep8: System registered the vehicle
Alternative courses of action Step 4: If the user name and
password is not validated and verified then the system respond
error message and return to step 2.Step 7: If the required input is
not validated the system displays error message and go to step6
Pre-conditionDeployment manager should be registered
Post conditionVehicles will be registered.
Table 3-3-9: Use Case Documentation of Vehicle Registration
Use Case Documentation for Update Vehicle RecordUse case name
Update vehicle record
Use case numberUC10
Actor(s)Deployment manager
DescriptionDeployment manager modify vehicle information when it
is necessary
Basic course of action Actor ActionStep1: Deployment manager
initiate to loginStep3: Deployment manager enter username and
password Step 6:Deployment manager enter information related to the
record to be updatedStep8:Deployment manager updates the vehicle
field
System ResponseStep2: System display login page.Step4: System
checks the validity and then authentication and authorization of
username and password.Step5: System display update vehicle page.
Step7: System displays the vehicle record to be updated
Step9:System validate information Step10: System updates the
vehicle record.
Alternate courses of action Step 4: If the username and password
is not validated and verified, system displays error message and go
Step2Step 9: If the input is not validated and verified, the system
displays invalid input message and go to step6
Pre conditionDeployment manager should be registered
Post conditionVehicle record will be updated
Table 3-3-10: Use Case Documentation of Update Vehicle
Record
Use Case Documentation for Generate Report Use case nameGenerate
report
Use case numberUC11
Actor(s)Deployment manager, Scheduler, Secretary(user)
DescriptionThis process is initialized when deployment manager,
secretary and scheduler (user) want to generate report about the
tasks performed on the system
Basic course of action Actor ActionStep1: UserStep3: User enter
username and passwordStep6: User fill important data
System ResponseStep2: System displays login page.Step4: System
checks the validity and then authentication and authorization of
username and password.Step5: System displays generate report
page.Step7: System validate the informationStep8: System display
reports.
Alternate courses of action Step 4: If the username and password
is not validated and verified, system displays error message and go
to step2
Pre-conditionUser should be registered
Post conditionUser view reports
Table 3-3-11: Use Case Documentation of Generate Report
Use Case Documentation for View Maintenance RequestUse case
nameView Maintenance request
Use case numberUC12
Actor(s)Mechanic, deployment manager
DescriptionThis use case describes viewing maintenance request
to repair the vehicle
Basic course of action Actor ActionStep1: User initiate to
loginStep3:User enter username and password Step 6:User click View
System ResponseStep2: System display login page.Step4: System
checks the validity and then authentication and authorization of
username and password.Step5: System display viewing maintenance
request page. Step7: System displays information that contain
problem of the vehicle
Alternate courses of action Step 4: If the username and password
is not validated and verified, system displays error message and go
Step2
Pre conditionMechanic and Deployment manager should be
registered
Post conditionVehicles problem will be viewed
Table 3-3-12: Use Case Documentation of View Maintenance
Request
3.4 Sequence DiagramA sequence diagram in a unified modeling
language (UML) is a kind of interaction diagram that shows how
processes operate with one another and in what order. It is a
construct of a Message Sequence Chart. A sequence diagram shows
object interactions arranged in time sequence. It depicts the
objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the
functionality of the scenario. Sequence diagrams typically are
associated with use case realizations in the Logical View of the
system under development
Sequence Diagram for Login
-Figure 3-4-1: Sequence Diagram for Login
Figure 3-4-2: Sequence Diagram for Prepare Schedule
Figure 3-4-4: Sequence Diagram for Search Vehicle
Figure 3-4-5: Sequence Diagram for Vehicle Registration
Sequence Diagram for Update Vehicle
Figure 3-4-6: Sequence Diagram for Update Vehicle
Figure 3-4-7: Sequence Diagram for Generate Report
Figure3-4-8: Sequence Diagram for View Maintenance Request
3.5 Activity DiagramThe purpose of the activity diagram is to
model the procedural flow of actions that are part of a larger
activity. In projects in which use cases are present, activity
diagrams can model a specific use case at a more detailed
level.
Activity Diagram for LoginFigure 3-5-1: Activity Diagram for
Login
Activity Diagram for Vehicle Maintenance Request Record
Figure 3-5-2: Activity Diagram for Vehicle Maintenance Request
Record Activity diagram for prepare vehicle schedule
Figure 3-5-3: Activity Diagram for Prepare Vehicle Schedule
Activity Diagram for Vehicle Registration
Fig3.5.4 Activity Diagram for Vehicle Registration
Activity Diagram for Update Vehicle
Figure 3-5-5: Activity Diagram for Update Vehicle
Activity Diagram for Generate Report
Figure 3-5-6: Activity Diagram for Generate Report
3.6 CLASS DIAGRAMWe use class diagram to describe the structure
of the system. classes are abstractions that specify the common
structure and behaviour of set of objects.Class diagrams describe
the system in terms of objects, classes, attributes, operations,
and their associations.
Figure 3-5-7: Class Diagram for Vehicle Maintenance and
Deployment System 3.7 User Interface Design