Car_anti_hijacking_system

©M. S. Ramaiah University of Applied Sciences
1
Faculty of Engineering & Technology
Car Anti-hijacking System
Sree Nikhilendra Prasad DJ
FT 2014 Batch, Reg. No.: 14ETCS037010
M. Tech. in Real Time Embedded Systems
Module Leader: Narasimha Murthy K. R., Suchit Kumar, V. S.
Yerragudi, Padmapriya Dharishini P., Sanket
Dessai, Mahita Patel and N. D. Gangadhar
Module Name: Real Time Embedded System Development
Module Code : RTS505

2
Marking
Head Maximum Score
Technical Content 5
Grasp and Explanation 5
Quality of Slides and
Delivery
5
Q & A 5
Total 20

3
Presentation Outline
• Introduction
• Agile methods
• Factors for selection of a software development model
• Applicability of Agile Methods
• Requirement analysis
• Context level diagram
• Components
• Output of lcd
• Output of solenoid
• Hyperterminal of GSM
• Hyperterminal of GPS
• Conclusion
• References

4
Introduction
• Agile methodology is an alternative to traditional
project management, typically used in software
development.
• This methodology is introduced by Dr. Winston
Royce. It helps team to respond to unpredictability
through incremental and iterative. It mainly focus
on the client satisfaction through continuous
delivery of the prototypes.

5
Agile methods
• Scrum: it is named for the scrum in rugby and was initially developed by Ken Schwaber and Jeff Sutherland with later
collaborations with Mike Beedle. It provides a project management framework that focuses development into a month
sprint cycles in which a specified set of Backlog features are delivered. The core practice is the use of daily 15 minute team
meetings for coordination and integration. It has been in use for too many years and it has delivered a vivid range of end
products. [Hayes, 2000]
• Dynamic Systems Development Method (DSDM): it was developed in the UK, an outgrowth of rapid application
development (RAD) practices. It boasts the best supported training and documentation. Its nine principles include active
user involvement, frequency delivery, team decision making, integrated and testing throughout the project life cycle and
reversible changes in development. [Hayes, 2000]
• Crystal methods: Alistair Cockburn is the author of the crystal family of people-centered methods. It focuses on the people
aspects of development-collaboration, good citizenship and cooperation. It uses project size, criticality and objectives to
craft appropriately configured practices for each member of the crystal family of methodologies. [Hayes, 2000]
• Feature Driven Development: Jeff De Luca and Peter Coad collaborated on FDD. It consists of a minimalist, five step process
that focuses on developing an overall shape object model, building a features list and then planning-by-feature followed by
an iterative design-by-feature and build-by-feature steps. [Hayes, 2000]
• Lean Development: The most strategic oriented is also the least known Bob Charette’s Lean Development which is derived
from the principles of lean production, the restructuring of the Japanese automobile industry. In LD, traditional methodology
is extended to view of change as a risk of loss to be controlled with restrictive management practices to a view of change
producing opportunities to be pursued during risk entrepreneurship. [Hayes, 2000]
• Extreme programming (XP): It is to most aficionados and was developed by Kent Beck, Ward Cunningham and Ron Jeffries.
XP preaches the values of community, simplicity, feedback and courage. Aspects of XP are its contribution to alerting the
view of the cost of change and its emphases on technical excellence through refactoring and test first development. [Hayes,
2007]
• Adaptive software development: It was developed by the Jim Highsmith. It provides a philosophical background for agile
methods showing how software development organizations can respond to the turbulence of the current business climate
by harnessing rather than change. [Hayes, 2000]

6
Factors for selection of a software
development model
• Size of project team: heavy development models are highly process and document oriented and it provide
better communication and coordination across large group whereas small and dynamic teams enable
interactions and adaption through close relationships and unambiguous responsibilities. Industry wide
consensus is that the need for tight coordination and shared knowledge.
• Rate of expected change: light models are not concerned with the project integration within the
infrastructure or scales in production due to their low overhead, can respond to change quicker and can
support changes to the product even quite late in development cycle. The cost of change at the late stages
of development is high. Heavy models work best when the requirements are largely determinable in
advance and remain stable.
• Primary project goal: for projects which are safety critical and demand high assurance a heavy model seems
to be a better fit. Light model do not fit on plan-driven goals.
• Requirement management: heavy models first identify requirements, define it and then hand them off to
the appropriate team. Light models express requirements in terms of changeable, informal stories. There is a
close interaction between the customer and developer to determine the prioritization of set of
requirements.
• Project communication: light models recommend face-to-face communication and are not concerned with
documenting communications between entities.
• Customer relationship: light models rely on working software and presence of dedicated customer liaison.
Heavy model generally depend on some form of contracts between the developers and customers.
• Customer organizational culture: in light model, there are no specific roles that has to be finished by a team
member. If the organization dictates that clear policies and procedures will define a person’s role then the
heavy model tend to best fit that organization.

7
Applicability of Agile Methods
• Identifying the ability of the organization to adopt agile practices: since agile adoption is a
form of process improvement and change and verification is to be deployed whether the
organization is ready to engage in a change towards agility. The pre-assessment
determines whether or not the organization is ready for software process improvement.
This pre-assessment phase is important because it saves the organization much time,
money and effort by identifying upfront that the improvement initiative.
• Determining the suitability of agile practices in the development of real time embedded
systems: employing the certain agile methods to be beneficial for the development of real
time embedded system. This is the premise behind the second challenge identifying while
agile methods to introduce when developing real time embedded systems. Finding an
approach for determining the suitability of individual agile method is needed to address
this challenge.
• Determining the suitability of agile practices for the organization developing real time
embedded systems: concluding that a practice is suitable for real time embedded system
is one issue. Determining whether the organization possesses the necessary
characteristics to adopt that practice successfully is another issue. Agile methods selected
for real time embedded systems adopted only when they have been determined to be
suitable for the organization developing the system. This assertion motivates the third
challenge related to introducing agile practices in the system.

8
Requirement analysis
• System functional requirements:
• SSFR 1: The system should authenticate the key using LED.
• SSFR 2: The system should authenticate the correct password. [Depends: SSFR1]
• SSFR 3: The system should detect the forcible entry of the intruder.
• SSFR 4: The system should detect the unauthorized towing of the car.
• SSFR 5: The system should immobilize the engine when required. [Depends: SSFR1, SSFR2, SSFR3, SSFR4]
• SSFR 6: The system should turn off the fuel supply when required. [Depends: SSFR1, SSFR2, SSFR3, SSFR4]
• SSFR 7: The system should sound an alarm when required. [Depends: SSFR1, SSFR2, SSFR3, SSFR4]
• SSFR 8: The system should find the location of car. [Depends: SSFR1, SSFR2, SSFR3, SSFR4]
• SSFR 9: The system should send a notification of location of car to the user. [Depends: SSFR1, SSFR2, SSFR3, SSFR4, SSFR8]
• System non-functional requirements:
• SSNFR 1: Privacy of security access only to owner, password should be unique. [Depends: SSFR1, SSFR2]
• SSNFR 2: Performance–system should respond within 2 sec when the vehicle is hijacked. [Depends: SSFR1, SSFR2, SSFR3,
SSFR4, SSFR5, SSFR6, SSFR7, SSFR8, SSFR9]
• SSNFR 3: Correctness - system should be accurate and work properly. [Depends: SSFR1, SSFR2, SSFR3, SSFR4, SSFR5, SSFR6,
SSFR7, SSFR8, SSFR9]
• SSNFR 4: Quality of design in terms of maintainability.
• SSNFR 5: Easy use - system should be easy to use. [Depends: SSFR1, SSFR2]
• SSNFR 6: Availability- system should be available 24 X 7. [Depends: SSFR1, SSFR2, SSFR3, SSFR4, SSFR5, SSFR6, SSFR7, SSFR8,
SSFR9]

9
Context level diagram

10
Components

11
Output of lcd

12
Output of solenoid

13
Hyperterminal of GSM

14
Hyperterminal of GPS

15
Conclusion
• The notion that agile method is a radical deviation
from the long established, tried and true history of
waterfall software development is incorrect. There
are constraints which has to be addressed for the
successful development of the real time
embedded systems. Agile method is simply the
latest theory that is widely replacing the waterfall
model.

16
References
• Williams, Laurie. A Survey of Agile Development
Methodologies. 1st ed. 2007.
• Hayes, Steve, and Martin Andrews. An
Introduction to Agile Methods. 1st ed. 2000.
• Szalvay, Victor. An Introduction to Agile Software
Development. 1st ed. 2004.

Car_anti_hijacking_system

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a Car_anti_hijacking_system

Semelhante a Car_anti_hijacking_system (20)

Car_anti_hijacking_system