Software Engineering Project File, Lab Reports of Software Engineering

Download Software Engineering Project File and more Lab Reports Software Engineering in PDF only on Docsity! Indraprastha College for Women (University of Delhi) DEPARTMENT OF COMPUTER SCIENCE SOFTWARE ENGINEERING PROJECT ACCIDENT DETECTION AND ALERT SYSTEM Submitted by: Ms Kanchan Sagar(20/CS/21) Ms Palak Rani(20/CS/35) Ms Pavitra Sharma(20/CS/36) 1 ACKNOWLEDGEMENT It is my privilege to express my sincerest regards to my Software Engineering professor, Ms Vimala Parihar for her invaluable inputs, able guidance, encouragement, whole-hearted cooperation and constructive criticism without which this project would not have been able to sail through. I deeply feel honoured and blessed for getting this opportunity of being guided by her. I express my sincere thanks to her for constantly helping and supporting, encouraging and guiding me to successfully complete and present this project on the topic “ACCIDENT DETECTION AND ALERT SYSTEM”. Ms Kanchan Sagar Ms Palak Rani Ms Pavitra Sharma 4 6 TESTING PHASE 6.1 Testing 6.2 Flow Chart 6.3 Flow Graph 6.4 Cyclomatic Complexity 6.5 Independent path testing 41 7 FUTURE SCOPE 47 8 REFERENCE 48 5 1. PRODUCT DESCRIPTION 1.1 INTRODUCTION The development of a transportation system has been the generative power for human beings to have the highest civilization above creatures in the earth. Automobile has a great importance in our daily life. We utilize it to go to our work place, keep in touch with our friends and family, and deliver our goods. But it can also bring disaster to us and even can kill us through accidents. Speed is one of the most important and basic risk factors in driving. It not only affects the severity of a crash, but also increases risk of being involved in a crash. Despite many efforts taken by different governmental and non-governmental organizations all around the world by various programs to aware against careless driving, yet accidents are taking place every now and then. However, many lives could have been saved if the emergency service could get the crash information in time. A study by Virtanen et al. shows that 4.6% of the fatalities in accidents could have been prevented only if the emergency services could be provided at the place of accident at the proper time. As such, efficient automatic accident detection with an automatic notification to the emergency service with the accident location is a prime need to save the precious human life. OBJECTIVE Speed is one of the basic reasons for vehicle accident. Many lives could have been saved if emergency services could get accident information and reach in time. This project deals with accident detection system when the accident occurs it uses various components and alerts the Rescue team for help. An efficient automatic accident detection with an automatic notification to the emergency service with the accident location is a prime need to save the precious human life. The proposed system deals with accident alerting and detection. It reads the exact latitude and longitude of the vehicle involved in the accident and sends this information to nearest emergency service provider. The goal of the project is to detect accidents and alert the rescue team in time. 1.2 PROCESS MODEL we are going to use Incremental model for this project. Incremental Model is a process of software development where requirements divided into multiple standalone modules of the software development cycle. In this model, each module 6 goes through the requirements, design, implementation and testing phases. Every subsequent release of the module adds function to the previous release. The process continues until the complete system achieved. Incremental Model The various phases of incremental model are as follows: 1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise identifies the requirements. And the system functional requirements are understood by the requirement analysis team. To develop the software under the incremental model, this phase performs a crucial role. 2. Design & Development: In this phase of the Incremental model of SDLC, the design of the system functionality and the development method are finished with success. When software develops new practicality, the incremental model uses style and development phase. 3. Testing: In the incremental model, the testing phase checks the performance of each existing function as well as additional functionality. In the testing phase, the various methods are used to test the behaviour of each task. 4. Implementation: Implementation phase enables the coding phase of the development system. It involves the final coding that design in the designing and development phase and tests the functionality in the testing phase. After completion of this phase, the number of the product working is enhanced and upgraded up to the final system product. 9 USE CASE TEMPLATES LOGIN Brief description This use case describes how a user login to accident detection and alert system. Actor The following actor(s) interact and participate in this use case: User. Flow of events • Basic flow This use case starts when the actor wishes to login to the Accident detection and alert System. The System requests that the actor enter his/her name, Email and password. 1. The actor enters his/her name, Email and password. 2. The system validates the entered name, email and password, and logs the actor into the system. • Alternative Flows 1. Invalid Name/Password/Email If in the Basic Flow, the actor enters an invalid name, password and/or email, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login at which point the use case ends. Special requirements None. Pre-conditions The actor must have an User Account. Post-conditions They can Update their medical details and emergency contacts. 10 UPDATING DETAILS Brief description Allows actor to upload and update medical details and emergency contacts. Actors The following actor(s) interact and participate in this use case: User. Flow of events • Basic flow Actor needs to fill in basic details such as age, weight, height, blood group, etc. they have to provide details if they are allergic to anything and provide documents for any serious conditions such as heart condition etc. • Alternative flow 1. If user doesn’t upload the document in respective format and size as mentioned, the system will display an error. User can choose to upload the file again or cancel his form, at which point the use case ends. 2. If there is any error in the uploaded documents, then a mail specifying the invalid document and reason behind it for being invalid is mailed to the respective user. 3. The user can either choose to upload the files again or cancel his form, at which point the use case ends. 11 ACCIDENT VALIDATION Brief description If it is a false alarm, it can be confirmed by the user. Actor The following actor(s) interact and participate in this use case: User. Flow of events • Basic flow If emergency dial is not aborted then user is giving validation about accident and rescue team is sent afterwards. • Alternative flow If it’s a false alarm then the user has the facility to abort the emergency dial to responder by using control switch. Special requirements Control switch and sensors data. Pre-condition Actor must be logged into the accident detection and alert system before any activity. Post-conditions Alert message is sent to a nearby hospital for rescue team to reach the location of the accident and upon confirmation it informs their emergency contacts. 14 The rest of the SRS contains, how the intended software will interact with hardware, external interfaces, the speed of operations, the response time of a system, portability of software across various platforms, maintainability, the speed of recovery after crashing, security, quality, limitations, etc. 3.OVERALL DESCRIPTION 3.1 Product Perspective Accident Detection and Alert System searches for nearest hospital and asks to send help as soon as possible during an accident. The databases of the system will contain information about: • Login details • Documents updated • Validation given • Alert message 3.2 Product Feature Major feature of this software is to locate near by hospital when accident is detected and contact it by sending accident location. 3.3 User Characteristics 1. Main User is the actor user, who contacts hospitals for assistance by giving validation. 2. User should be able to upload necessary document, such as medical certificates. 3. Responder are required to respond to alert messages and send medical team. 4. OVERALL SPECIFICATION • Login • Update • Validation • Alerting Login: - To login to the system so as to use it. 15 Update: - To able to upload or update medical documents. Validation: - To able to give validation of occurrence of accident Alerting: - It alerts responder by contacting them and providing location and details of user. 5. SPECIFIC REQUIREMENTS: This section contains all the software requirements at a level of details sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. 5.1 EXTERNAL INTERFACES • Hardware Interfaces 2GB RAM and higher IOS and Android Working GPS • Software Interfaces C++ Back end – SQL Server • Communication Interface Document verification mail send via e-mail. 6. PERFORMANCE REQUIREMENTS • Availability: Team will be sent if it is available. • Correctness: only contacted is given validation. 16 • Usability: Used to send quick medical aid so as to save users life. 2.3 DATA FLOW DIAGRAMS (DFD) Data flow diagram takes an input process- output view of a system. It is a graphical representation of flow of data in an information system. It is capable of depicting incoming data flow, outgoing data flow, and stored data. That is, data objects flow into the software, are transformed by processing elements, ad resultant data objects flow out of the software. DFD COMPONENTS DFD can represent source, destination, storage, and flow of data using the following set of components- Entities: Entities are sources and destinations of information data. Entities are represented by rectangles with their respective names. Process: Activities and action taken on the data are represented by Circle or Round- edged rectangles. Data Flow: Movement of data is shown by pointed arrows. Data movement is shown from the base of arrow as its source towards head of the arrow as the destination. Database: The databases used in this project are represented by a single line. A few simple guidelines can aid immeasurably during the derivation of a data flow diagram: • The level 0 data flow diagram should depict the software/system as a single bubble. • Primary input and output should be carefully noted. • Refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level; all arrows and bubbles should be labelled with meaningful names. • Information flow continuity must be maintained from level 1 to level 2 and one bubble at a time should be refined. This is a natural tendency to overcomplicate the data flow diagram. > Uploaded documents 2B Inner view of VALIDATION module f Neare: \ N, [sno data collected) —— / ~ cell's st search of hospital made through GPS 's not ) meade 19 Recore of aoproved call Record ¢f unapproved calls  2c Inner view of ALERTING module RECo fporve esponses Hecote ct aparovec cl tL Yo ~N a s ‘, (Hospital's response is —( _ Validation given Pam poskive }— / Hospital's response is negative | Responder SS Tesardofragenve responses oo \ ——+( Validation not give —_» Rese af unannven cs 20 21 2.4 DATA DICTIONARY set of information describing the contents, format, and structure of a database and the relationship between its elements, used to control access to and manipulation of the database. The term can have one of several closely related meanings pertaining to databases and database management systems: • A document describing a database or collection of databases. • An integral component of a DBMS that is required to determine its structure. • A piece of middleware that extends or supplants the native data dictionary of a DBMS. The data dictionary is a crucial component of any relational database. Ironically, because of its importance, it is invisible to most database users. Typically, only database administrators interact with the data dictionary. Most of the data dictionary contains the following information: 1. Name - the primary name of the data or control item, the data store or an external entity 2. Alias - other names used for the first entry. 3. Where used - a listing of the processes that use the data or control item and how it is used external. 4. Description - a notation for representing content. S.NO NAME ALIAS WHERE USED DESCRIPTION 1 Username and password Login Details During logging in to the system To login 2 Required documents Update/upload During the time of updating of documents To upload and update information in system. 2.6 Activity diagram Sensor takes data alarm rings Lo validation fails validation true ==) ==) notice other details nd details to hospitals hospital doesnt hospital Tespond responds report to another hospital 24  2.7 State Chart Diagram verified aera Upload Details | Validation | +] Get GPS data | | oe ie a not verified p papuodses Papuodse, you Send rescue team 25 26 3. PROJECT MANAGEMENT 3.1 FUNCTION POINT Function points are one of the most widely used measures of software sizes. The basis of function point is that the “functionality” of the system that is what the system performs, is the measure of the system size. In function points, the system functionally is calculated in terms of the number of functions it implements, the number of inputs, the number of outputs etc. NUMBER OF EXTERNAL INPUTS: Each external input that provides distinct application- oriented data to the software is counted separately. NUMBER OF EXTERNAL OUTPUTS: Each external output that provides application-oriented information to the user is counted. In this context output refers to reports, screen, and error messages, etc. Individual data items within a report are not counted separately. NUMBER OF EXTERNAL INQUIRIES: An external inquiry is defined as an on- line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted. NUMBER OF INTERNAL LOGICAL FILES: Each internal logical file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted. NUMBER OF EXTERNAL INTERFACE FILES: All external interfaces (e.g., data files on storage media) that are used to transmit information to another system are counted. 29 3.3 RISK TABLE Risk is a problematic event i.e., it may occur or may not occur. We frequently have optimistic tendency to simply not see risk or wish they will not occur, which later on leads us to trouble. Hence it is advisable to identify the critical areas, assess their probabilities, estimate the impact and plan the contingency plan. The first step is Risk identification. Next each risk is analysed to determine the likelihood that it will occur and the damage it will do if it occurs. Risks are then, ranked by probability and impact. Finally, a plan is developed to manage those risks with high probability, moderate as well as low impact. These risk analysis activities assist us in developing a strategy for dealing risks. An effective strategy is the RMMM plan. It Includes: • Risk identification • Risk monitoring • Risk management and contingency plan Impact Values: • Negligible (4) • Marginal (3) • Critical (2) • Catastrophic (1) 30 RISK CATEGORY PROBABILITY IMPACT RMMM Or MANAGEMENT 1. Loss of Database Software quality risk 40.00% 1 A) The data can be restored from the backup database. B) The data concerned with the database has to be monitored by closely whenever a new user login or whenever the software is being updated C) The backup database needs to have a close monitoring. 2. Size of product Software risk 30.00% 3 A) Upper bound of storage space is specified before-hand 3. Congestion Risk Software performance risk 40.00% 3 A) Proper internet facility should be available B) The system should be able to recover instantly if any fault occur. 4. Technology expectation are not met Software requirement risk 40.00% 1 A) Technical analysis of software with testing. B) Prototyping and basic design architecture. 5. Customer risk Customer is usable to attract the targeted audience 40.00% 4 A) Usage of proper marketing strategy and advertising. 31 6. Login risk Software performance risk 20.00% 4 A) User has to store the password at some safe place that can be revisited. B) Re-register facility. 7. Development Personnel Low-skilled staff 3.00% 2 A) Development of a personnel having best possible skills appropriated to the project. 3.4 TIMELINE CHART All project tasks are listed in the far-left column. The next few columns may list the following for each task: projected start date, projected stop date, projected duration, actual start date, actual stop date, actual duration, task inter- dependencies (i.e., predecessors). The length of a horizontal bar on the calendar indicates the duration of the task the multiple bars that occur at the same time interval on the calendar, this implies task concurrency. A diamond in the calendar area of a specific task indicates that the task is a milestone; a milestone has a time duration of zero. 34 ER diagram and schema of the databases used in our project are shown below: 35 User_id name Phone_no email Password hospital_id Hospital_name address Phone_no email DATABSE FOR APPROVED CALLS hospital_id Hospital_name Phone_no 36 DATABASE FOR DISAPPROVED CALLS hospital_id Phone_no DATABASE SCEMAS Table name: User Primary key: user_id Description: This table will hold the user details s.no. Field name Data type constraints Description 1. User id INT PRIMARY KEY Unique id given to each user to distinguish among various users 2. User name VARCHAR(80) NOT NULL User name is set by person 3. Email VARCHAR(80) NOT NULL Email is set by user 4. Password VARCHAR(80) NOT NULL Password is set by user 5. Phone number INT NOT NULL Phone number is specified by user 39 5.CODE DEVELOPMENT 5.1 Pseudo code LOGIN 1. Start 2. Enter user Id 3. If Id exists 4. Enter password 5. If password is correct 6. Print login successful 7. Else 8. Print enter password again 9. Go to 4 10. Else 11. Print user Id does not exist 12. Go to 2 13. Stop SIGN UP 1. Start 2. Enter user Id 3. If Id exist 4. Enter password pwd //at least 8 character 5. Enter confirm password cpwd 6. If pwd=cpwd 7. Store password 8. Print you are signed in 9. Else 10. Print password again 11. Go to 4 12. Else 13. Print user id does not exists 14. Go to 2 15. Stop 40 Validating alarm 1. Alert alarm ring 2. Countdown starts 3. If cancel button pressed 4. Consider a false alarm 5. Else 6. Track location 7. Notify nearby hospital 8. Exit Response status 1. Start 2. System sends notification and details 3. If hospital responds to notification 4. If facilities available 5. Send facilities to the location 6. Else 7. Send details to another hospital 8. Else 9. Contact nearby hospitals 10. Send emergency status to user 41 6.TESTING PHASE 6.1 TESTING Black-box testing Black-box testing focuses on the functional requirements of the software. It enables you to derive sets of input conditions that will fully exercise all functional requirements for a program. Black-box testing finds errors in following categories: a) Incorrect or missing functions. b) Interface errors. c) Errors in data structures or external database. d) Behaviour or performance errors. e) Initialization and termination errors. White-box testing White-box testing also called glass-box testing is a test-case design philosophy that uses the control structure described as part of component- level design to derive test cases. Using white-box testing we can derive test cases that: a) Guarantee that all independent paths within a module have been exercised at least once b) Exercise all logical decisions on their true and false sides c) Execute all loops at their boundaries d) Exercise internal data structures to ensure their validity. Basic-Path testing Basic-Path testing is a white-box testing technique. The basic path method enables the test-case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Basic-path testing of module “SPLITTING BILL” is shown below. 44 One testing strategy, called Basis Path Testing by McCabe, who first proposed it, is to test each linearly independent path through the program; in this case, the number of test cases will equal the Cyclomatic complexity of the program. FORMULA IS GIVEN BY: McCabe’s Cyclomatic complexity V (G) for the flow graph is defined by V (G) =E – N+ 2P E is the number of edges in flow graph N is the number of nodes in flow graph P is connected components in flow graph Validating alarm: CC = e-n+2P = 8-8+2  2 π+1  1+1  2 Regions  2 Paths = 1→2→3→4→8 1→2→3→4→5→6→7→8 Response status: CC = e-n+2p = 10-9+2  3 π+1 2+1=3 45 Region  3 Paths = 1→2→3→7→8→9 1→2→3→4→5→9 1→2→3→4→6→9 6.5 INDEPENDENT PATH TESTING Validation Alarm: PATH CONDITION TEST CASE STATMENT STATUS 1→2→3 →4→8 False Alarm No 4 No alert message 1→2→3→5 →6→7→8 Validation given Yes 7 Alert message 46 Response status: PATHS CONDITION TEST CASES STATEMENT STATUS 1→2→3→7 →8→9 First hospital didn’t respond so contact other hospital Yes 8 Call’s made 1→2→3→4 →5→9 First hospital available Yes 5 Call’s made 1→2→3→4 →6→9 Contact second hospital Yes 6 Call’s made