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