Essay: FLEET/LOCOMOTIVE CONVEYANCE SYSTEM

1.1 Abstract
Delivery of freight is vitally important for any type of industries from large industries to small industries. Our system Locomotive/Fleet Conveyance System works for any freight ranging from small things to giant object. It delivers the freight from source to destination of customer. Our system works for any big city to town of any country.
Customer also wants to know where their freights are reached. In a present scenario, the tracking of freights are done through checkpoint. To make reliable and user friendly system, we provides the facility of live tracking of freight of customer until it reaches the destination of customer so, Customer satisfaction can be achieved properly.
In any type of industry, it is required to know whether company’s improvement is achieved properly or not. If not then company should know about in which factor we will have to improve so, In addition to, our system also provides more facility to generate a pie chart and bar chart for whole system as a report so, it helps company to understand in which city or town the requirement becomes met more than expectation so, company gives more and more focus on particular location and congestion is reduced.
To make a system as a reliable, our system provides the facility of confirmation. After delivering of freight it provides the confirmation letter to a customer and after all processes have been done through company then customer can fill up the feedback on the basis of role of whole system from starting to end so company should also make an improvement on the basis of customer reviews and feedback.
1. 1. 1 Problem Summary
In general we can summarize the problems arising in the company as follows:
• Difficulty in Maintenance of Records
• Time Consuming
• Editing of Data becomes a tedious job
• Management of documentation
• Report Generation
• Live tracking
1.1.2. Problem and Weakness of Current System
Although system spending is increasing by the day, there is some concern regarding the rate at which system deployments are failing. This two-part piece aims to bring out the issues that system vendors are loath to talk about.
• In present scenario, The Live tracking of customer’s freights are done via checkpoint so, customer cannot be able to know where their goods exactly reached so whole system is not user friendly.
• In present scenario, if customer wants to transport the freights from source to destination then customer have two choices either customer makes a call to the company or customer visits the transportation company.
• Today, Documentation are done through paperwork so documentation management is not done properly so, there is possibility for loosing the documentation.
1.1.3. About New System
• . LOCOMOTIVE/FLEET CONVEYANCE SYSTEM is a website for an industry in which admin can manage all details regarding branches information and also customer details vehicle and driver information.
• Customer can give the order to the system. Branch staff gives a schedule to the customer and admin can approve or reject the requirement.
• Customer can see Live tracking of their Freights on the website with the help of android application installed in the driver’s cellphone.
• Customer can also upload the documentation of freights to the system.
• After delivery of the system customer can gives the feedback to the system.
1.2.Aim and Objective of the Project
Aim:
We want to develop an attractive and user friendly web application for a Freight transportation of industries from source to destination with reliability.
Objective:
The main objective of this system is to reduce the consumption of time during maintaining the records of all users who interact within the system.
In other words, our LOCOMOTIVE/FLLET CONVEYANCE SYSTEM has following objectives:
• Simple database is maintained.
• Easy operations for the admin of the system.
• User interfaces are user friendly and attractive. it takes very less time for the admin to get use-to with the system.
• Customer can see live tracking of their freight until it reaches the destination
• Proper management of documentation is done.
1.3.Problem Specifications
1.3.1.Feasibility Study
A feasibility study is a short, focused study, which aims to answer a number of questions:
Does the system contribute to the overall objectives of the organization?
Organization objective is to Administration of Archivist with better quality. And this software is fully able to achieve this goal.
Can the system be implemented using current technology and within given cost and schedule constraints?
Our current system Archivist is developed using the Microsoft visual studio 2005 (.net framework 2.0) and so we have used C-sharp as our coding. As development tools and software are easily available, there isn’t any burden of buying them. There is only 4 month available for completion of project and so we are able to complete it within a time.
Can the system be integrated with systems which are already in place?
We are developing a module project. This is part of Archivist web based application. So we develop this as a part of Archivist which can be integrated with it.
A feasibility study is a preliminary study undertaken to determine and document a project’s viability. The term feasibility study is also used to refer to the resulting document. These results of this study are used to make a decision whether to proceed with the project, or table it. If it indeed leads to a project being approved, it will — before the real work of the proposed project starts — be used to ascertain the likelihood of the project’s success. It is an analysis of possible alternative solutions to a problem and a recommendation on the best alternative. It, for example, can decide whether an order processing be carried out by a new system more efficiently than the previous one.
There are various types of feasibility studies:
 Technical feasibility study
 Schedule Feasibility study
 Cultural Feasibility study
 Legal Feasibility study
 Marketing Feasibility study
 Operational Feasibility
 Economical Feasibility
 Implementation Feasibility
Technical feasibility study:-
This involves questions such as whether the technology needed for the system exists, how difficult it will be to build, and whether the firm has enough experience using that technology. The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and procedures. This can be qualified in terms of volumes of data, trends, frequency of updating, etc. in order to give an introduction to the technical system.
• The software or tools necessary for building or running the application are easily available or not?
• The compatibility amongst software exists or not?
• Are developers aware of these technologies?
• What about the alternative of these chosen technologies?
Factors considered:
• Here we have to consider those tools, which will be required for developing the project.
• The tools, which are available, and tools, which will be required, have to take in account.
• We have to work on Microsoft visual studio 2005 (.net framework 2.0) and Microsoft SQL server 2005 as back end.
• Internet facility is always available for technical as well as advanced software help.
Time Feasibility study
This involves questions such as how much time is available to build the new system, when it can be built, whether it interferes with normal business operation, number of resources required, dependencies, etc. Contingency and mitigation plans should also be stated here so that if the project does over run the company is ready for this eventuality.
It is not important that the project gets completed, but it’s very important that it gets completed in allotted time. We had project duration of 15 weeks. As the work was divided among the team members, the schedule was planned in a way that the project within the allotted time period was possible. The campus’ environment is also supportive. So our project is feasible with respect to schedule.
We have been asked to complete the project within the working days of the organization having period of 3 months approximately. So we have managed to complete the project before given deadline. In the Project Planning section we elaborate our ideas to develop the system within the given period. Please refer to that section for thorough idea
Moreover the number of functionalities to be implemented was not fixed. It was incremental approach so the constraint of time limit was not there.
Hence, it is feasible to develop a system in predetermined time interval.
Economical Feasibility
Economical feasibility addresses to the following issues:
• Is the organization having the suitable budget to develop the proposed system?
• As it is a Private organization they are spending considerable amount of money on each project.
• How much profit can be earned from the system by an organization?
• Would it be cost-effective to develop the system or it is worthwhile to remain with current system?
1.4. Brief Literature review and Prior Art Search (PAS)
Brief Literature review:
• The growth in demand for transportation services in India is not limited to basic transportation services. Economic reforms and liberalization have driven transportation sector through several transmission channels of which these three categories are of major significance.
• The effective research cannot be accomplished without critically studying what already exists in the form of general literature and specific studies. Therefore, it is considered as an important pre-requisite for actual planning and execution of research project. This helps to formulate hypotheses and framework for further investigation. In this research, the survey of literature has been classified into two parts – studies related to education sector and studies related to marketing strategies.
1.5 Software Process Model.
Incremental model in software engineering is a one which combines the elements of waterfall model which are then applied in an iterative manner. It basically delivers a series of releases called increments which provide progressively more functionality for the client as each increment is delivered.
In incremental model of software engineering, waterfall model is repeatedly applied in each increment. The incremental model applies linear sequences in a required pattern as calendar time passes. Each linear sequence produces an increment in the work.
1.5.1.1. Stages in Incremental Model
Requirement Analysis & Definition:
All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. At each phase of the Incremental model, requirement analysis is done to ensure that user requirements are being fulfilled by the developer.
Software Design & Planning:
Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.
Construction & Testing:
After designing the system model, the coding commences. Construction of the software is based on the current build that is being built and is open to modification until the last build is built and deployed. With each round of coding, testing is done to ensure that the system works as planned.
Deployment:
Deployment is the final stage of each incremental build. The software is deployed and feedbacks from the users is recorded for the next stage of development.
Figure 3.1 Incremental model
1.5.1.2. Advantages of Incremental Model
-Initial product delivery is faster.
-Lower initial delivery cost.
-Core product is developed first i.e. main functionality is added in the first increment.
-After each iteration, regression testing should be conducted. During this testing, faulty elements of the software can be quickly identified because few changes are made within any single iteration.
-It is generally easier to test and debug than other methods of software development because relatively smaller changes are made during each iteration. This allows for more targeted and rigorous testing of each element within the overall product.
-With each release a new feature is added to the product.
-Customer can respond to feature and review the product.
-Risk of changing requirement is reduced
-Work load is less.
1.5.1.3. Justification
Incremental Model, though based on Waterfall model, contrasts the ideologies of the waterfall model. In waterfall model, before the coding starts, all the prior stages of software development life cycle have to be completed. Incremental model contrasts that ideology and depends on agile and rapid development life cycles.
The lifecycles are time-boxed and last for only a limited amount of time. After each iteration, a working code is expected from the developer for user feedback. This kind of methodology makes it easier to make changes. It also does not require concrete understanding of the entire system and little modifications can be made over time.
Since, it allows for great flexibility and rapid development, it fits well with our project.
1.5.2. Project Plan.
It deals with the order in which important planning activities may be undertaken. Some of the essential activities are:
• Estimation of some basic attributes of the project such as cost, duration, effort.
• Scheduling manpower and other resources.
Figure 1.5.2.1 Project Plan
1.5.3. Roles and Responsibilities.
For better development of a project it is better to perform requirement analysis and system design in a group and partition the implementation into modules and each team member should work on different task. Here in our project we have used “divide and conquer”. Each one had taken a particular module and performed implementation and unit testing in it. Later, performed module testing and integrated testing in group.
1.5.4. PROJECT SCHEDULE
• PROJECT SCHEDULING CHART:
Project Schedule is the process of creating a network of the software engineering tasks that will enable the job done on time. After list out the number of modules and requirement, we had scheduled the project
• Decided appropriate model.
• Estimate the amount of work and divided it into specific time iteration.
• Deciding Deadline.
• SCHEDULING:
We have scheduled our project as per Software Development Life Cycle Technology. Based on the phases of SDLC, We have performed activities for our project.
• IMPORTANCE:
The interdependencies in the complex systems are very difficult to handle and understand which became easy with proper scheduling of project. It is impossible to track complex software project without scheduling.
PROJECT SCHEDULING CHART:
Figure 1.5.1 Project Scheduling Chart
1.5.5. RISK MANAGEMENT
There are different categories of risk. Risk that are to be analyzed like project risks , business risks , technical risks , known risks , predictable risks and unpredictable risks. Project risks identify potential budgetary, schedule, personal that includes staff and organization, resources, customers and requirement problems and they impact on software projects. Technical risks identify potential design; implementation, interface, verification, maintenance problems, specification ambiguity, technical uncertainness and technical obsolesce. Business risks threaten the viability of the software to be built. Known risks are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed. Predictable risks are extrapolated from past project experience. Unpredictable risks are extremely difficult to identify in advance.
1.5.5.1. Risk Identification.
1) Technology: While system is building / compiling and end-user request to access and manipulate information then system get re-configure and user get configuration error.
2) Hardware: Website runs on some Server. So all hardware related problems like power failure and server down problems must be managed effectively by our hardware team.
3) Software: Website is depending on the database. There are other external libraries and tools like Web-Server, and client tools etc. requires regular maintenance so it won’t get failure and we can prevent data lost.
4) People: As Website is a database driven which contains lots of concepts and tools that are used, it require understanding all features and functionalities, also how it get implemented and affected by web-module. So we need to interact to Technical Manager and other employees to understand tool and concepts effectively. So we try to make this risk as small as by writing tutorials about tools and techniques we will be using.
6) Schedule: Each team member should respect the deadlines that the team has decided. When a team member knows that he will be unable to respect a given deadline, he should inform the other team members as soon as possible (preferably more than two days before the deadline), so that the team can find a way to solve the problem.
7) Delay Due to illness: This is one natural risk that can occur at any moment during project development. Illness of any person working for website in future can cause delay to the project completion.
1.5.5.2. Risk Analysis.
Probability of the risks might be assessed as very low (<10%), low (10-25%), moderated (25-50%), high (50-75%), or very high (>75%).
Effects of the risk might be assessed as catastrophic, serious, tolerable or insignificant.
Risk Probability Effect
Technology Low Catastrophic
Hardware Moderated Critical
Software Moderated Critical
People Low Catastrophic
Schedule Low Critical
Delay due to Illness Very Low Tolerable
Table Risk Analysis
1.6.Materials/Tools Required
Hardware requirements
• Client Side:
1. (For best performance) Any GUI based terminal having at least 800 * 600 256-color displays.
2. 1024 X 768 32 bit recommended.
3. Android device
• Server Side:
1. Supported architectures: x86, x64, ia64(Windows Server 2008).
2. RAM: 96 MB (256 MB Recommended).
3. 400 MHz CPU (1.0 GHz Recommended).
Software Requirement:
• Operating System : Microsoft Windows XP, Microsoft Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, Windows 8+.
• Web Server : IIS 6.0 and higher
• Server Side Scripting : .NET Framework 3.5 and Higher
• Microsoft Visual Studio
• Android 2.3 and higher
• Eclipse IDE
Chapter 2-Design
2.1 Analysis:
2.1.1. Constraints.
Regulatory Policies
System does not apply to any regulatory policy as the project developed is a Web-Based application to be used as product for the personalized use of the company’s internal use itself.
Parallel Operations
Parallel Operations can be performed as there are many customers and also guests / visitors who can visit the site / access / write to database at the same time. These changes from the customers need to be validated by the administrator before processing it.
Reliability Requirements
Validation is the main reliability requirement that is used in the system. Without proper validation, system does not allow to enter the value in the database. For e.g. there is validation which checks proper E-mail address. Compare validator is therefore used to compare values. The session gets expired when the system is not being used for more than the session time-out time. The system source code is not available for user when browsing.
Safety
The user cannot see the system source code and thus when browsing no changes can be made into the system. When the session gets timed out or the user logs off, after that, the query string supposedly obtained using unfair means will be of no use as the session variables are removed and there is no existence of the data present which can be manipulated.
2.1.2. REQUIREMENT SPECIFICATION
There are many good definitions of systems and software’s requirements specification that will provide us a good basis upon which we can both define a great specification and help us identified deficiencies in our post efforts. This is also a lot of great stuff on the web about writing good specification, the problem is not lack of knowledge about how to create a correctly formulated Specification or even what should go into the specification, We have to keep in mind that the goal is not to create specification but to create good software systems and software, nowadays are so complex that to embark on the design before knowing what you are going to build is risky but never the less, Encoding at the same time while considering the requirements of any project especially one which has online application, one need to pay attention to verify the aspects which may be specified as follows:
 Legitimate access to the system.
 Data confidently.
 Data integrity& security.
 Accurate, relevant and timely retrieval of data.
There are two types of main requirement specification:
 Functional Requirements.
 Non-Functional Requirements.
i) FUNCTIONAL REQUIREMENTS
Branch Configuration:
 Create New Branch
 Search OR View Branch
 Update Branch
 Deactivate Branch
Branch Staff Administration:
 Create New Staff
 Assign Branch Member For Shifting
 Assign Drivers
Fleet Configuration:
 Update Fleet
 Deactivate Fleet
Customer Registration and Profile:
 Customer can Register Yourself
 Login
 Update Profile
 Change Password
Customer Administration:
 Deactivation Account
 Search Customer
 View Customer Details
Requirement Submission:
 Submit New Requirement
 View My Requirement
 View My Outstanding Requirement
 View My Past Requirement
 Cancel Requirement
 Update Requirement
Requirement Delegation:
 Search Requirement
 Manage Outstanding
 Approve Requirement
 Reject Requirement
 Assign Vehicle For Requirement
 Assign Driver For Requirement
 Configure Fleet Schedule
 Assign Requirement To Branch
Fleet Tracking And Feedback:
 Approve Fleet Schedule
 Reject Schedule
 View Current Location On Map
 Acknowledgement Fleet Completion
Branch Performance Analysis:-
 Report (Bar Chart & Pie Chart)
Conveyance Request Analysis Report:-
 Graphical & Tabular Chart
ii) Non-Functional Requirements
Quality Requirement:
• The quality in software development process is maintained by periodic reviews, documentation and verification at all appropriate stages. Quality review will be done at the component level and when the data components were merged together. Also the progress report of every week is being submitted to the college for verification.
Readability:
• Appropriate comments in the project source code are provided to provide readability so that the user can easily read and understand the project if need be. So the project will be helpful for interested person. Every care is taken that the application is functionally correct. Reliability is a must in the application to make it worth for the Client Company. A great degree of care has to be taken to ensure minimum / zero defects in the code. Also if there is an error occurring then a custom error page is made to be visible. This is done because if the user of the system sees an error page with all details then he might get confused and close down the project. In order to remove the fear, if any error occurs then it is redirected to custom page.
Modularity:
• The project was initially divided into different modules so as to provide easy understanding and debugging of the system.
Modifiability:
• With the help of modularity and readability of the source code of the program the system will be easy to modify in the future as and when needed.
Portability:
• The project will be easy to implement on the client system which satisfy the minimum hardware requirements.
Easy To Use:
• This project will be easy to use and so shall incorporate self-explanatory GUI. The GUI contains the presence of tooltips and indications to navigate properly across the system. The system is provided with a user guide which may be accessed by the user when he faces some difficulty.
Maintainability:
• The project will provide easy maintenance of the otherwise loosely kept data which is only saved in the system but not used fruitfully. When an application is used, it has to be maintained. There could be additional requirements in terms of added functionality or feature. As the application is not to be maintained by the developers, the code kept is as less complex as possible such that it can be easily understood by the relevant person for modification. Also when new functionality was implemented but later on was not used then that data was also kept in various versions. If that data is also required to be implemented then that data can be taken from the earlier versions. This can be done easily by referring to the document which contains the details of all new additions in all the versions.
Fault Tolerance / Error Reporting:
• Since the application will be used by non IT users it might be possible that operation might result into errors. The application should provide user friendly error messages and fault tolerance facility whenever any error occurs so that employees can understand and act in accordance. Also errors which are not yet identified and occur then those errors are logged into the database and the user is redirected to the same page which can be informed to the developer for further assistance.
2.2 DESIGN Methodology.
Why Object oriented approach?
Here the system is going to build on Object Oriented approach. Object oriented approach is more suitable for the Online Shopping system and this system is similar to it. Object oriented approach helps to understand the whole system and the flow of the system.
Here is the reason why the system is Object oriented…
1. If the system is Object Oriented then it is easy to understand the flow of the system and hence the whole system can be understood.
2. In Object Oriented approach we have Use case to understand the modules and functionalities of each user, Activity to understand the flow, Sequence to know the process flow etc.
Hence In many way Object Oriented approach is more suitable and easier to understand for this system. Hence Object oriented approach is used here.
2.3 Implementation Strategy.
2.4 Diagrams.
Usecase Diagrams:
Figure 2.4.1 Use case for Customer
Figure 2.4.2 Use Case for Branch Staff and Admin
Figure 2.4.3 Use case for Branch Staff
Figure 2.4.4 Use Case for Driver
Sequence Diagrams:
Figure 2.4.5 Sequence of Requirement Processing
Figure 2.4.6 Sequence of User Registration
Figure 2.4.7 Sequence of Live tracking
Class Diagram:
Figure 2.4.8 Class Diagram of System
Entity-Relationship Diagram:
Figure 2.4.9 E-R Diagram Of System
ACTIVITY DIAGRAM
Figure 2.4.10 Activity Diagram Of Requirement
2.5 Canvas
AEIOU CANVAS
Figure 2.5.1 AEIOU Canvas
AEIOU is a heuristic to help interpret observations gathered by ethnographic practice in industry. Its two primary functions are to code data, and to develop building blocks of models that will ultimately address the objectives and issues of a client.
IDEATION CANVAS
Fig 2.5.2 Ideation Canvas
Ideation canvas is basically representing the set of ideas we had for our project. We decided on who all will use the project and who all are related, then the activities on how the project flow will happen, then locations that is where all the project will be located and where it will be used. The solutions are not the exact solutions but the possible set of solutions which may be the best for the project.
PRODUCT DEVELOPMENT CANVAS
Fig 2.5.3 Product Development Canvas
Product development canvas is most import to know about this project. Because in this canvas, we define purpose of this concept and detail information about product experience, features, and components. Customer revalidation and some reject, retain things also acquire.
EMPATHY CANVAS
Figure 2.5.4 Empathy Canvas
A User Empathy Map can help tee up a discussion about the needs a user has. The discussion will be centered around what was observed, and what can be inferred about these user groups’ beliefs and emotions.
DATABASE DESIGN
Branch
Field Name Data Type Description
Id Integer Primary Key
Name Varchar(100) –
Location Varchar(100) –
Phone Varchar(100) –
Address Varchar(400) –
Email_id Varchar(100) –
Requirement Documentation
Field Name Data Type Description
ReqDocID Integer Primary key
DocName Varchar (100) –
DocRequirementID Integer –
Requirement
Field Name Data Type Description
ID Integer Primary Key
CustomerID Integer Primary Key
ReqDate DateTime –
CreateDate DateTime –
Status Varchar(100) –
VehicleID Integer Primary Key
Email_id Varchar(100) Primary Key
StaffID Integer Primary Key
BranchID Integer Primary Key
PlannedStart DateTime –
PlannedEnd DateTime –
ActualStart DateTime –
ActualEnd DateTime –
GPS Varchar(100) –
Feedback Varchar(100) Foreign key
Staff
Field Name Data type Description
StaffID Integer Primary key
Name Varchar(100) –
Email Varchar(100) –
Phone Varchar(100) –
BranchID Integer –
UserName Varchar(100) –
Password Varchar(100) –
IsActive Boolean –
Vehicle
Field Name Data type Description
VehicleID Integer Primary key
Capacity Varchar(100) –
RegNO Integer Primary Key
BranchID Integer Primary key
IsActive Boolean –