Download Software Engineering: Phases & Models for Home Security System and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!
PRACTICAL - 1
Aim: Study of phases in software development life cycle, need of software
engineering, life cycle models and their comparisons.
Software Development Life Cycle
These are the primary generics steps involved in the development process, other secondary steps may include project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others, which may or may not be applied as per requirement.
Communication - Before any technical work can commence, it is critically important to communicate and collaborate with the customer. The intent is to understand the requirements which may help in defining the features and functions of the software.
Planning - The development process can be drastically simplified if a roadmap exists. A software project is a complicated journey, and during the planning activity, the team needs to create a “roadmap” that helps guide the team as it makes the journey. The roadmap—which is the plan for the software project—defines the technical tasks to be conducted, the risks that the team might face, the resources that will be required, the products to be developed, and a working schedule.
Modeling - We create a “sketch” of the processes so that we can understand the big picture—what it will look like architecturally, how the components fit together, and many other characteristics. If required, we refine the sketch into greater and greater detail in an effort to better understand the problem and how we’re going to solve it. A software engineering team does the same thing by constructing models to better comprehend the software requirements and the design that will achieve those requirements.
Construction - This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.
Deployment - The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.
While different models may modify the flow of development as per specific requirement, the generic steps remain the same.
The Need of Software Engineering
Software engineering encompasses a process, a collection of methods and an array of tools that allow professionals to develop high-quality computer software. Software engineers build and support software, and virtually everyone in the industrialized world uses. Software is important because it affects nearly every aspect of our lives and has become pervasive in our commerce,
our culture, and our everyday activities. It enables us to build complex systems in a timely manner and with high quality.
Software engineering methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques.
Software engineering tools provide automated or semi automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.
Software Model
The Spiral Model
Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world.
Features:
- Cyclic approach for incrementally growing a system’s degree of definition and implementation.
- If used properly this model reduces high degree of risks.
- Each pass through the planning region results in adjustments to the project plan.
- The spiral model can be adapted to apply throughout the entire life cycle of an application, from concept development to maintenance.
The spiral model is a realistic approach to the development of large-scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. It demands considerable risk assessment expertise at all stages of the project and if properly applied, should reduce risks before they become problematic.
- Flexible with requirements. 5. Requirements once fixed cannot be modified.
- Refinements are easily possible 6. Refinements are not so easy.
- Phases are repeated. 7. Phases are processed and completed one at a time.
Spiral Model vs RAD Model
Spiral Model RAD Model
- Requires planning. 1. This model does not require planning.
- User involvement is high. 2. User involvement is only at the ererbeginning.
- Development cost is high. 3. Development cost is low.
- Testing after each iteration. 4. Testing after coding.
- Maintenance is hard. 5. Maintenance is easy.
PRACTICAL – 2
Aim: To develop Software Requirements Specifications for Home Security
System using IoT.
1. Introduction
1.1. Purpose
Security Systems is one of the most researched fields of today. Through this system, we can detect human activity and switch on the buzzer to alert the user. Also, this system will be connected to the internet so it can send the data to the cloud spontaneously.
User will have two ways of unlocking the door – a unique RFID (Radio Frequency Identification) card and a mobile app which also uses passcode authentication. An additional layer of fingerprint security may also be incorporated if required.
1.2. Scope
This system allows the user to ensure security of his house with features like alarm, remote lock/unlock, presence detector and also eliminates the need for a separate key (using a mobile application).
1.3. Overview
The remaining sections of this document provide a general description, including characteristics of the users of this project, the product's hardware, and the functional and data requirements of the product. General description of the project is discussed in section 2 of this document. Section 3 gives the feasibility study of the product. Sections 5 and 6 give the Functional and Non-Functional Requirements of the system. Section 7 discusses the external interface requirements.
2. General Description
The purpose of this system is to build a cost effective, easy to deploy and minimal operating cost IoT based platform to ensure the safety of the user and his house and also to provide an easier and more convenient way of unlocking his house. There is no physical key involved so the user can give access to as many people as required. Also, since this system is always connected to the internet, the user will get notified almost instantaneously if intruder presence is detected in his house. User will also be provided an Application using which he could login to his account and configure the system - like if he is not going to be present for a few days, he could enable the alarm, he could put his daily schedule, he could specify who to notify in case of emergency etc. Also, user will be provided a secondary unlock method (RFID) in case mobile phone is not available with the user at all times.
3. Feasibility Study
1.4. Economic Feasibility
Since this is an IoT-based system, it does require a constant power supply to work properly. If power supply to a system is cut, the system will just stop working and the door could not be unlocked until power is restored. So, it requires a constant power supply source like a battery/ inverter in case of a power cut. Also, it is not a standalone system and requires some changes made to the door lock. So, it has an additional initial setup cost in addition to the price of the components.
Also, even if solutions are available on the market, they do not offer this level of customizability and user configurability for the cost described here. Hence there is an abundant market for such a product.
4. Users
1.8. Primary Home Owner
This will be the main user of the system. He/she is the owner of the house and has ultimate control on who has access to the house.
1.9. Additional Home Owners
People who live in the house. They also get RFID cards and passcode-based access. They get similar functionality as the home owner.
1.10. Visitor(s)
Visitors get temporary one-time access to the house if authorized by the user.
5. Functional Requirements
1.11. Module Description
5.1. New User Registration
Register a new user by specifying user type – primary home owner (only one per system), additional home owner and visitor – also specify access type (one time, temporary or permanent).
5.2. User Schedule
Input the schedule of the home owner(s) to detect when the home will be empty – if unauthorized presence is detected during that time period, home owner(s) will be notified about it.
5.3. Registration of new RFID Card
Issue a new RFID Card – register its ID in the database and also specify user to whom it is being issued.
5.4. Alarm System
Sound an alarm if the unlock system is somehow bypassed to alert home owner(s) and neighbors.
1.12. User Functionality
5.5. Human Presence Detection
By the use of multiple Infrared Sensors installed at various places throughout the house, the system can detect whether or not a human is presence in the house at any given point. This data can be stored in a globally accessible database since the system is connected to the internet and so the user can configure the system to get notified if presence is detected even when he is not home.
5.6. RFID-based door unlocker
The primary way of unlocking the door in this system will be via a mobile application. But sometimes the user may forget to carry his phone, or the internet connection may be down for some reason, or the user may want to give someone else temporary access. So, RFID is used as a secondary door unlock method for this system – door can be unlocked by scanning the unique RFID card.
5.7. Mobile-App based door unlocker
The user can remotely unlock the door using a mobile application from anywhere using internet with a passcode-based authentication. This is so that the user can allow people into his house without having to be physically present at the door. It also eliminated the need for having to carry a separate physical key.
5.8. Notification / Alarm Mechanism
The user can configure the system (using application) as to when he will not be present at his house. If human presence if detected in that interval, he will be notified about it. He may also choose to notify via different mechanisms (e-Mail, SMS) and also ring an alarm throughout the house to alert the neighbors.
5.9. One-time Visitor Pass
If someone wishes to visit the user’s house and the user is not available at that time, the user may send him a one-time visitor passcode to him. The visitor can then unlock the door using the app using the one-time passcode. The passcode will have an expiry time and date. Also, it may not be used more than once – it would become invalid once used.
6. Non-Functional Requirements
1.13. Security
The database only needs basic security in this application since it does not contain much sensitive information about the user. But it does contain some information like the user's name and phone number so it will be protected by encryption and access control. As for the device itself, it will be concealed in the wall so it is not feasible to override the device's security features such as the alarm. Hence it does not need much physical security.
It does not require any complicated application or website – they just need basic functionality like user schedule and remote access. The website or application don't require much interactivity or design beyond that point – they don’t require things like animations or to interface with other applications.
1.20. Hardware
This system has the following Hardware requirements:
- Internet Line for constant connectivity
- Connecting device like switch / router
- Computer / mobile phone for accessing the system
- Host system for database
1.21. Software
This system has the following software requirements:
- Browser to access web application
- Android OS based phone for remote lock / unlock
- SQL-based database server to store logs and other important information
- Server operating system – either Windows or Linux
PRACTICAL – 3
Aim: To create the function-oriented diagram: DFD and Structured chart.
Data Flow Diagram:
DFD provides the functional overview of a system. The graphical representation easily overcomes any gap between ’user and system analyst’ and ‘analyst and system designer’ in understanding a system. Starting from an overview of the system it explores detailed design of a system through a hierarchy. DFD shows the external entities from which data flows into the process and also the other flows of data within a system. It also includes the transformations of data flow by the process and the data stores to read or write a data.
Symbols used in Data Flow diagram:
External entity Data store
Process Data flow
Data Flow Diagram of System:
Level 0 DFD:
Module name
Level 2 DFD:
Structure Chart:
A Structure Chart in software engineering is a chart which shows the breakdown of a system to its lowest manageable parts. They are used in structured programming to arrange program modules into a tree. Each module is represented by a box, which contains the module's name. The tree structure visualizes the relationships between modules, showing data transfer between modules using arrows. Structured Charts are an example of a top-down design where a problem (the program) is broken into its components. The tree shows the relationship between modules, showing data transfer between the models.
Symbols used in Structure Chart:
Each Box represents a programming module , this might be something that calculates the average of some figures, or prints out some pay slips
The revolving arrow denotes iteration.
Use case diagrams are a common way to communicate the major functions of a software system. A use case diagram at its simplest is a representation of a user's interaction with the system that shows the relationship between the user and the different use cases in which the user is involved. A use case diagram can identify the different types of users of a system and the different use cases and will often be accompanied by other types of diagrams as well.
Use cases are nothing but the system functionalities written in an organized manner. Now another thing which is relevant to the use cases are the actors. Actors can be defined as something that interacts with the system.
So in brief, the purposes of use case diagrams can be as follows:
- (^) Used to gather requirements of a system.
- Used to get an outside view of a system.
- Identify external and internal factors influencing the system.
- Show the interacting among the requirements are actors.
Symbols used in Use Case diagram:
Use Case Include
Association Extend
Actor Dependency
System Generalization
Use Case Diagram of System:
Multiplicity in Aggregation, Composition, or Association
Abstract Class
Class Diagram of System:
PRACTICAL – 6
Aim: To draw the data model diagram: E-R Diagram.
Entity Relationship Model
Entity-Relationship model is used to represent a logical design of a database to be created. In ER model, real world objects (or concepts) are abstracted as entities, and different possible associations among them are modeled as relationships. We represents the attributes, entities and relation using the ER diagram. Using this ER diagram, table structures are created, along with required constraints. Finally, these tables are normalized in order to remove redundancy and maintain data integrity. Thus, to have data stored efficiently, the ER diagram is to be drawn as much detailed and accurate as possible.
Importance of ER Modeling
Figure - 01 shows the different steps involved in implementation of a (relational) database.
Symbols used in ER diagram:
Entity:
Relation
Attributes
