SMART CITY PDF

Title SMART CITY
Author Rishabh Gupta
Pages 52
File Size 3.1 MB
File Type PDF
Total Downloads 300
Total Views 354

Summary

SMART CITY WEB-APP Software Engineering Project Report 2017 Department of Computer Science Acharya Narendra Dev College University of Delhi Submitted by- Supervisor: Rishabh Gupta (15001570030) Dr. Vibha Gaur Ashish Sharma (15001570009) Introduction…………………………………………………………………………………………………….4 Problem St...


Description

Accelerat ing t he world's research.

SMART CITY Rishabh Gupta

Related papers

Download a PDF Pack of t he best relat ed papers 

SMART CITY WEB-APP

Software Engineering Project Report

2017 Department of Computer Science Acharya Narendra Dev College University of Delhi

Submitted by-

Supervisor:

Rishabh Gupta (15001570030) Ashish Sharma (15001570009)

Dr. Vibha Gaur

Introduction…………………………………………………………………………………………………….4 Problem Statement............................................................................................................................................. 5 Process Model..................................................................................................................................................... 6 1.

Software Requirement Specification....................................................................................................... 7 1.1 Overall Description................................................................................................................................7 1.1.1

Product Functions................................................................................................................. 7

1.1.2

User Characteristics.............................................................................................................. 7

1.1.3

General Constraints.............................................................................................................. 7

1.1.4

Assumptions and Dependencies............................................................................................7

1.2

External Interface Requirements.................................................................................................... 7

1.2.1

User Interfaces...................................................................................................................... 7

1.2.2

Hardware Interfaces............................................................................................................ 7

1.2.3

Software Interfaces............................................................................................................... 7

1.3

Functional Requirements................................................................................................................. 7

1.3.1

FR 1..........................................................................................................................................7

1.3.2

FR 2.......................................................................................................................................... 7

1.3.3

FR n......................................................................................................................................... 7

1.4

Performance Requirement................................................................................................................ 7

1.5

Design Constraints............................................................................................................................. 7

1.6

Data Flow Diagram............................................................................................................................ 7

1.7 2.

Data Dictionary................................................................................................................................. 7 Estimations........................................................................................................................................ 8

2.1

Function Points................................................................................................................................. 8

2.2

Efforts................................................................................................................................................ 8

3.

Scheduling......................................................................................................................................... 9

4.

Risk Management............................................................................................................................ 10

5.

Design................................................................................................................................................ 11 5.1

System Design................................................................................................................................... 11

5.2

Data Design....................................................................................................................................... 11

6.

Coding................................................................................................................................................ 12

7.

Testing................................................................................................................................................ 13

8.

References.......................................................................................................................................... 14

Introduction: The purpose of this project is to develop a smart city environment that provides person to access any information about the city via the internet. “Smart city” as the name suggests this Web-App is designed to make our city smarter. There is a need of Web-App for complete information about the city although there is information available on internet but it is not available on one site a person has to wonder from one app to another to get required piece of information. Keeping this fact in mind we have tried to put all information under one App which will make our city smarter.

Problem Statement: A person faces problem about Electricity, Water, Education, Security and many more, where to find Solution, what are smart city ways, for all these daily life’s problems we have tried to provide our users with a unified solution.

Process Model: We are using Spiral model for aforesaid project. We are using this model because project have many section and using this model we can iterate any process at any time for future development purposes. Demand of user may change in future and if we are using this model, we can add that functionality to application.

Spiral Model: Spiral model is a combination of iterative development process model and sequential linear development model i.e. waterfall model with very high emphasis on risk analysis. It allows for incremental releases of the product, or incremental refinement through each iteration around the spiral.

Diagram:

1.Software Requirement Specification: The goal of the requirements activity is to produce the Software Requirements Specification (SRS), that describes what the proposed software should do without describing how the software will do it An SRS establishes the basis for agreement between the client and the supplier on what the software product will do.

1.1 Product Functions: I. ii. iii. iv. v. vi. vii.

Complete database of Electricity, Water, Health, Education and Security section. History of the city (Delhi). Complete overview of the businesses in the city. Secure registration of all users including a personal profile Complete search/site map of the entire site for easy access. Local language support at user-interface and database level. Facilitate communication between user, experts and general public through Complaint.

1.1.1 User Characteristics: Every user should be comfortable of working with Websites. He must have basic knowledge of English too.

1.1.2 General Constraints:

I. GUI is only in English. ii. Guests are not allowed to participate in a Complaints forum. iii. The user should keep his registration details confidential iv. The login name and password is used for identification of user of the system and there is no facility for visitors.

1.1.3 Assumptions and Dependencies: I. All the services are to be purchased online so a proper online transaction module with a high level of security needs to be implemented. ii. The traffic towards the site should be low otherwise the system may not correspond properly. iii. The user should have a basic knowledge of English language, computer usage and internet.

1.2 External Interface Requirements: All the interactions of the software with people, hardware, and other software should be clearly specified. For the user interface, the characteristics of each user interface of the software product should be specified. User interface is becoming increasingly important and must be given proper attention.

1.2.1 User Interfaces: User interface, the characteristics of each user interface of the software product should be specified. User interface is becoming increasingly important and must be given proper attention. User interface for our project: User client: Any Smartphone device. : Knowledge about scheme of Govt.

1.2.2 Software Interfaces: A preliminary user manual should be created with all user commands, screen formats, an explanation of how the system will appear to the user, and feedback and error messages. Software Interface for our project: Client on Internet: Client on Intranet: Web Server: Database Server: Development End:

App Browser, Operating System(any) Client Software, App Browser, Operating System(any) WAS, Operating System(any) DB2, Operating System(any) RAD (J2EE, Java)

1.2.3 Hardware Interfaces: Hardware interface requirements, the SRS should specify the logical characteristics of each interface between the software product and the hardware components. Hardware interface requirements for our project:

Client Side

Processor

RAM

Disc Space

Web enable device.

1.0 Ghz Snapdragon Or above

512 MB

40 MB

Server Side

Processor

RAM

Disc Space

Web sphere application serverV6.1 & DB2V9.1

Pentium 4th at 1.3 Ghz.

512 MB

2 GB

1.3 Functional Requirements: The traditional approach for specifying functionality is to specify each function that the system should provide. Use cases specify the functionality of a system by specifying the behavior of the system, captured as interactions of the users with the system. Functional Requirement for our project:

FR-1:Login/Signup New Registration: Description: To request perform any operation user need to register themselves. Input: User Details. Output: Confirmation with Login-id and password.

Log-in: Description: To access user account, user need to login themselves. Input: User Details. Output: Access his/her account with his details.

FR-2: Electricity Section Maintainability: New Connection: Description: To request for New connection user need to register themselves with electricity provider. Input: Customer Details. Output: Confirmation of registration with Rag No.

Payment: Description: To pay bill user need to check their bill by submitting their CA no and click pay now. Input: Payment details. Output: Receipt of payment.

Projected Bill: Description: Calculate customer projected bill of month. Input: Unit/Day Output: Display projected bill estimate.

Complaints: Description: Complaint if any problem in Electricity section. Input: user requests. Output: Display Complaints register with complaints id.

FR-3: -Scholarship: Eligibility: Description: According to eligibility of Scholars Display scholarships. Input: Scholars Details. Output: Display Scholarships on his/her eligibility.

Apply for Scholarship: Description: To apply scholarship scholar needs to register themselves. Input: Scholar Details. Output: Confirmation with registration id.

Status: Description: To know status of his/her applied scholarships. Input: User Details.

Output: Display status of his scholarship.

Complaints: Description: Complaint if any problem in Scholarship section. Input: user requests. Output: Display Complaints register with complaints id

FR-4: -Health: Emergency: Description: In this case Locate all nearest Hospital with contact details. Input: User Details. Output: Display nearest Hospital.

Appointment: Description: To take Appointment in city hospitals. Input: User Details. Output: Display Confirmation with receipt.

Payment: Description: To payment Bill Input: Payment details. Output: Receipt.

Stores: Description: To know nearest Medical Stores. Input: User Details. Output: Display Stores Details.

Complaints: Description: Complaint if any problem in Health section. Input: user requests. Output: Display Complaints register with complaints id.

FR-4 EDUCATION: Top Online Courses:

Description: Show the top online courses.

Top Ranking College: Description: Show the list of top ranking college. Input: user input Output: Show list from various ranking category.

Colleges and schools in your city: Description: Show list of Schools and colleges in Your city.

FR-5 Income tax Calculation: Know about income tax return: Description: Show all details about Income tax return. Due Date: Description: Show due date and penalty. Income tax calculator: Description: calculate income tax according to your income. Income tax return fill: Description: fill customer’s income tax.

Complaints: Description: Complaint if any problem in Health section. Input: user requests. Output: Display Complaints register with complaints id.

FR-6 Security: Online fir: Description: Fill FIR to local police station and a copy will send for headquarter. Status of FIR: Description: show the status of FIR. whether police have taken action against guilty or not. Emergency call or message: Description: A button on home screen is available. Input: click on Emergency button. Output: it will show two buttons for call or message. Input: select if any button generates a call or mgs and location to police and headquarter. COMPLAINTS: DESCRIPTION: User can complaint about individual policeman to police headquarter.

Water: New Connection: Description: To request for New connection user need to register themselves with water provider. Input: Customer Details. Output: Confirmation of registration with Rag No.

Payment: Description: To pay bill user need to check their bill by submitting their Rag no and click pay now. Input: Payment details. Output: Receipt of payment.

FR-7 Pollution: Pollution Level: Description: To know Pollution level of your city as per normal criteria. Input: Your city name. Output: Show Pollution level.

Take Photo and clean Pollution: Description: To clean your nearby you can take photo and send to respective corporation. Input: Take pic. Output: Show response time.

DMC Contacts: Description: To know about your nearby D.M.C. Offices and contacts. Input: Your area name.

Output: Show contact details.

FR-8 Complaints: Department: Description: To complaints select respective Department. Input: input details. Output: Show Response time.

1.3

Performance Requirement: This part of an SRS specifies the performance constraints on the software system. All the requirements relating to the performance characteristics of the system must be clearly specified. Performance Requirement for our Project:

I. Better component design to get better performance at peak time. ii. Secure access of confidential data (user’s details). iii. 24 x 7 availability.

Design Constraints a design constraint refers to some limitation on the conditions under which a system is developed, or on the requirements of the system. The design constraint could be on the systems form, fit or function or could be in the technology to be used, materials to be incorporated, time taken to develop the system, overall budget, and so on. A design constraint is normally imposed externally, either by the organization or by some external regulation. Design constraints for our project: 1. Each User will have Web Enabled Device. 2. The Website would need to be always connected. 3. Each user will have a user ID and password. 4. The user interfaces of the system should prevent users from issuing commands in the wrong order.

1.6 Data Flow Diagram A DFD is drawn to model the problem domain. The analyst has little control over the problem, and hence his task is to extract from the problem all the information and then represent it as a DFD. DFD for our project:

Context Level DFD: A context diagram is a top level (also known as "Level 0") data flow diagram. It only contains one process node ("Process 0") that generalizes the function of the entire system in relationship to external entities. A context level DFD is the most basic form of DFD. It aims to show how the entire system works at a glance. There is only one process in the system and all the data flows either into or out of this process. Context level DFD’s demonstrates the interactions between the process and external entities. They do not contain Data Stores. When drawing Context Level DFD’s, we must first identify the process, all the external entities and all the data flows. We must also state any assumptions we make about the system. It is advised that we draw the process in the middle of the page. We then draw our external entities in the corners and finally connect our entities to our process with the data flows. Context Level DFD for our project:

Level-1 Data Flow Diagram: Level 1 DFD’s aim to give an overview of the full system. They look at the system in more detail. Major processes are broken down into sub-processes. Level 1 DFD’s also identifies data stores that are used by the major processes. When constructing a Level 1 DFD, we must start by examining the Context Level DFD. We must break up the single process into its sub-processes. We must then pick out the data stores from the text we are given and include them in our DFD. Like the Context Level DFD’s, all entities, data stores and processes must be labelled. We must also state any assumptions made from the text.

1.7 Data Dictionary: The data dictionary is a repository of various data flows defined in a DFD. The associated data dictionary states precisely the structure of each data flow in the DFD. Components in the structure of a data flow may also be specified in the data dictionary, as well as the structure of files shown in the DFD. Data Dictionary for our project:

Customer Data: [[Name +Registration No.] *+password + Address +Email]

Complaints Unit Bill

: [Complaint Id+Complaint status]* : [current Unit +Unit Rate+ Previous unit]* : [Previous Bill +Projected Bill+ Current Bill]*

2.0 Estimations: Estimation are needed before development is initiated. The primary reason for cost and schedule estimation is cost-benefit analysis, and project monitoring and control. A more practical use of these estimates is in bidding for software projects, where cost estimates must be given to a potential chant for the development contract.

2.1Function Points: A major problem after requirements are done is to estimate the effort and schedule for the projec...


Similar Free PDFs