

































































Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
a sample project report for your software you can refere this one
Typology: Study Guides, Projects, Research
1 / 73
This page cannot be seen from the preview
Don't miss anything!


































































1.1 Title of the project:
Real-time Taxi App
1.2 Purpose: The advancement in Information Technology and internet penetration has greatly enhanced various business processes and communication between companies (services provider) and their customers of which car rental industry is not left out. City cab is developed to provide the following services:
1.3 Scope: This project transverse a lot of areas ranging from business concepts to computing field, & required to perform several researches to be able to achieve the project objectives. The area covers include: Cab hiring industry: This includes study on how the cab booking business is being done, process involved and opportunity that exist for improvement.
Android and Firebase Technology used for the development of the application. General customers/travelers as well as the company’s staffs will be able to use the system efficiently.
1.4 Overview: Sign up and Login process:
Driver:
User:
2.1 Problem Statement Given four inputs, (a). Source (b). Destination (c). Email Address (d). Time of the day to reach the destination, send an email to the given email address about booking its taxi at that very moment so that you have ample time to reach your destination which takes into consideration the following conditions:
2.2 Feasibility Study
When a project is started the first matter to establish is to assess the feasibility of a project or product. Feasibility means the extent to which appropriate data and information are readily available or can be obtained with available resources such as staff, expertise, time, and equipment. It is basically used as a measure of how practical or beneficial the development of a software system will be to you (or organization). This activity recurs throughout the life cycle.
2.2.1 Economic Feasibility A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economic feasibility, the developed cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs. The system is economically feasible. The application is developed to avoid human effort on paper works and moving from the manual system to automated system thus it is worth using the application for business organizations and gaining the benefit. There is no cost is charged for this project as it is done for a as a part of project work. So this project is economic feasible.
2.2.2 Operational Feasibility Proposed projects are beneficial only if they can be turned out into information system. That will meet the organizations operating requirements. Operational feasibility aspects of the projects are to be taken as an important part of the project implementation. Some of the important issues raised are to test the operational feasibility of a project includes the following: -
2.3 Project Planning
To solve actual problems in industry settings, software engineer or a team of engineers must incorporate a development strategy that encompasses the process, methods and tools layers and generic phases. This strategy is often referred to as process model or a software engineering paradigm. A process model for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required.
2.4 Project Scheduling
Table 2.4.1 project scheduling
2.5 Activity Chart Week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Activity (^) January February March April Study of Basic things Introduction of project Analysis Learning process Design Coding & Testing
Week Month Week 1 Week 2 Week3 Week4 Week (^1) Month st Study of studio, JAVA, Android XML.
Study of FirebaseDatabase Get overview ofour project. Start Analysis ofproject
Made databasebased on the analysis.
(^2) Monthnd^ Draw DFD and ER diagram based on the database.
Start Coding about some basicProgramming Coding Coding
3 rd Month Coding Coding Coding Coding Coding (^4) Monthth Testing and integrating Modules,Implementation
Preparation ofdocumentation Give final touch upto documentation
Integration Documentation Final documentation
Table 2.5.1 project scheduling
2.6 Software Engineering Paradigm (Process Model)
Prototype Model
The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. The prototype is usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.
Figure 2.6.1 Prototyping model
Advantages of Prototype model:
stores all the description through the use of easily understandable symbols. DFD is one of the most important modeling tools. It is used to model the system, components that interact with the system, uses the data and information flows in the system. DFD shows the information moves through the and how it is modified by a series of transformations. It is a graphical technique that depicts information moves from input or output. DFD is also known as bubble chart or Data Flows Graphs. DFD may be used to represent the system at any level of abstraction.
There are four kind of system components:
Processes External Entities Data Flow Data Stores
Data in a system moves in a specific direction that is from origin to destination. The data flow is a ‘packet’ of data indicating the movement of the data within the system. Data flow must be inputs to or outputs from processes. They must contain data and all data flows should be labeled indicating what data is flowing. If the data flow is showing an input, then the arrow should point towards the process. But in case the data flow is showing an output then the arrow should point away from the process.
Processes transform input into outputs. They are work or actions that are performed by people, machines, or computers on incoming data flow to produce outgoing data flows. The data flow leaving a process is always labeled differently from the one entering it. Each process should be given a meaningful name.
External entities are organizations, other information systems, departments or people that represent a source or destination of transactions or
data. When the system we are considering accepts data from another system to provide data to it, that other system is the external entity.
Data store could be thought of, as the ‘memory’ of the system. Any place that data accumulates is a data store.
A data store must have at least one data flow pointing towards it, or one away from it. The data store must have a label which is placed between the two parallel lines.
Symbol Description Source or Destination data
Data Flow
Process
Data Store
Table 2.7.1 Data flow diagram symbols
;
Figure 2.7.2 Level 1 DFD
Figure 2.7.3 Level 2 DFD
2.7.2 Entity Relationship Diagram (ER Diagram)
An entity-relationship (ER) diagram is a specialized graphic that illustrate the interrelationships between entities in a database. ER diagram often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes.
An entity-relationship model (ERM) in software engineering is an abstract and conceptual representation of data. Entity-relationship modelling is a relational schema database modelling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion.
An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world.
An entity may be physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order. Although the term entity is the one most commonly used, following we should really distinguish between an entity and ad entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. There are usually many instances of an entity type. Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term. Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. Entities are represented as rectangles.
A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: employee owns relationship between a company and a computer, and a supervisor supervises relationship between an employee and a department, a proved relationship between a mathematician and a theorem. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship.
Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; the proved relationship may have a date attribute. Attributes are represented as ellipse connected to their owning entity sets by a line.
Every entity (unless it is a weak entity) must have a minimal setoff uniquely identifying attributes, which is called the entity’s primary key.
Entity-relationship diagrams don’t show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set.
Lines are drawn between entity sets and relationship sets they are involved in. If all entities in an entity set must participate in the relationship set, a thick or double line is drawn. This is called a ‘participation constraint’. If each entity of the entity set can participate in at most one relationship in the relationship set, an arrow is drawn from the entity set to the relationship set. This is called a ‘key constraints’. To indicate that each entity in the entity set is involved in exactly one relationship, a thick arrow is drawn.
2.7.3 Activity Diagram
Activity diagrams, which are related to program flow plans (flowcharts), are used to illustrate activities
Activity Diagram for User
Figure 2.7.6 Activity chart for User
Activity Diagram for Driver
Figure 2.7.7 Activity chart for Driver
2.7.4 Use Case Model
Use case Diagrams represent the functionality of the system from a user’s point of view. Use cases are used during requirements elicitation and analysis to represent the functionality of the system. Use cases focus on the behavior of the system from external point of view.