SAAF-SUTHRI CITY APP SOFTWARE ENGINEERING PROJECT REPORT

[Submitted in partial fulfilment]

As a part of the curriculum of B.SC. (H) COMPUTER SCIENCE

Submitted by: - LOVELY SANGAHI (18044570006)

KANWALPREET KAUR DHINGRA(18044570020)

B.Sc. (H) COMPUTER SCIENCE IV SEMESTER

Mata Sundri College for Women, University of Delhi

Mata Sundri Lane, New Delhi 110002

2

ACKNOWLEDGMENT

Any project being done always requires the help and support of different people who, through their experience and guidance show us the correct path and keep guiding us with the correct process.

Thus, we would like to express our gratitude and we are highly obliged by the help and guidance of our mentor Ms Ashema Hasti, for giving us the right kind of opportunity for the successful completion of our project titled “SAAF-SUTHRI CITY APP”.

We thank her for her continuous support, guidance, help and mentoring before, during the tenure and after completion of the project. Her expert guidance and knowledge helped us getting through with the project successfully.

We are also grateful to our friends who helped us in brainstorming sessions to help us analyse in a better way.

LOVELY SANGAHI (18044570001) KANWALPREET KAUR DHINGRA (18044570020)

3

CERTIFICATE

This is to certify that the project titled “Smart waste management app” is the bona fide work carried

out by

Lovely Sangahi,

Kanwalpreet Kaur Dhingra,

Students of B.Sc (H) Computer Science of Mata Sundri College for Women, Delhi affiliated to Delhi

University under the supervision of Ms. Ashema Hasti.

Ms. Ashema Hasti

(Mentor)

4

ABSTRACT

Rapid increase in population, has led to the improper waste management in cities resulting in increased pests and spreading of diseases. Nowadays, the Garbage Collecting Vehicle (GCV) collects the waste twice or thrice in a week. So, the problem is over flowing of wastages on the roads. Hence, to overcome this limitation, in this project a scheme on smart waste management using Wireless Sensor Networks (WSN) is introduced. There are two three of people that can have the access to this application: the User, the eco-green driver and the authority. User segregates their waste themselves and put accordingly in that particular type of bin. This information is made available on their app .After this the app provide them the shortest path from their home to the trash area. The garbage bins are deployed with sensors and are networked together using WSN. The sensors deployed in the garbage bins collect the data for every determined interval. Once the threshold is reached, it raises a request to the GCA (Garbage Collector Agent). This agent receives the messages of all the filled trashes and therefore will go and collect those trashes by using optimize route from his duty area to the full trash area and will empty those trashes. We gathered the requirements for the projects from our friends, relatives and teachers. Authority keep control on the app as well as on the complaints made by the user. We have used the prototype Model for our project. We have created our SRS, DFD till level 2.We then calculated the project metrics and estimated effort using COCOMO model. We analysed the types of risks that can occur in our project and created the RMMM plans. We also created designs and later performed Basis Path testing for our software. Also, we have shown some sample screens.

5

LIST OF FIGURES

Figure No. Description Page No.

2.1 Prototype model 8 3.1 Context Diagram 9

3.2 Level 1 DFD 10 3.3 Module of Login Functionality 11

3.4 Module of Trash Details Functionality 12 3.5 Module of Search bin Functionality 13

3.6 Module of Finding optimized route Functionality 14 3.7 Module of report a problem functionality 15 4.1 Diagram depicting trash type and category 22 6.1 ER Diagram for the software 36

7.1 Shortest path Diagram 39 7.2 Control flow diagram 39

8.1 SCREEN 1- Home Screen 41 8.2 SCREEN 2- Forgot password 41 8.3 SCREEN 3-Setting up new password 42

8.4 SCREEN 4- Trash choosing Screen 42

8.5 SCREEN 5- Trash type screen 43 8.6 SCREEN 6- Trash choice screen 43

8.7 SCREEN 7-Shortest path screen 44 8.8 SCREEN 8-User’s accurate path screen 44 8.9 SCREEN 9- Driver’s last activity 45 8.10 SCREEN 10- garbage collector’s last activity display Screen 45

8.11 SCREEN 11- trash volume display Screen 46 8.12 SCREEN 12- optimize path for driver to the filled bin Screen 46

LIST OF TABLES

Table No. Description Page No. 1 Data Dictionary 16 2 Project Schedule 25 3 Timeline Chart 26 4 Value Adjustment Factor Table 28 5 FP Calculation Table 29 6 Weighing Complexity 30 7 Productivity Rate 31 8 Risk management Table 33 9 Data Design Table 34,35

6

TABLE OF CONTENTS 1. PROBLEM STATEMENT …………………………………………………………………….1 2. PROCESS MODEL ……………………………………………………………………………2 3. REQUIREMENTS ANALYSIS

3.1 DFD 3.1.1 Context Diagram ………………………………………………………………. 3 3.1.2 Level 1 DFD ……………………………………………………………………4 3.1.3 Level 2 DFD …………………………………………………………………… 5

3.2 DATA DICTIONARY …………………………………………………………………. 16 4. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

4.1 INTRODUCTION………………………………………….17 4.1.1. Purpose 4.1.2. Project Scope 4.1.3. Definitions, acronyms, and abbreviation 4.1.4. References 4.1.5. Overview

4.2. PROJECT DESCRIPTION……………………………….18 4.2.1. Product Perspective 4.2.2. Product Functions 4.2.3. User Characteristics 4.2.4. General Constraints 4.2.5. Assumptions and Dependencies

4.3. SPECIFIC REQUIREMENTS…………………………..20 4.3.1. External Interfaces

4.3.1.1. User Interfaces 4.3.1.2. Hardware Interfaces 4.3.1.3. Software Interfaces 4.3.1.4. Communication Interfaces

4.3.2. Functional Requirements……………………………..21 4.3.3. Performance requirements………………………….22 4.3.4. Logical database requirements……………………………23 4.3.5. Design constraints………………………………..23

4.3.5.1. Standard Compliance 4.3.5.2. Hardware Limitations 4.3.5.3. Reliability & Fault Tolerance 4.3.5.4. Security Requirements

4.3.6. Software System Attributes……………………………………………24 5. PROJECT PLANNING

5.1 PROJECT SCHEDULING……………………………………25 5.2 TIMELINE CHART……………………………..26 5.3 EFFORT ESTIMATION & FP –BASED COMPUTING……………………………………27 5.4 COST ESTIMATION: COCOMO-II MODEL……………………………….29 5.5 RISK ANALYSIS………………………………………32

6. DESIGN 6.1 ER DIAGRAM……………………………..34 6.2 DATA DESIGN………………………………….34 6.3 COMPONENT LEVEL DESIGN……………………………36

7. TESTING……………………………………………37 8. ANNEXURES……………………………………………………………………41

7

1. PROBLEM STATEMENT Indian cities generate a massive amount of waste that goes uncollected and untreated. Most landfills lack proper on-site waste management thereby contributing to additional threats to the environment.

In the long-term, landfills leak and pollute ground water and other neighbouring environmental habitats making waste management very difficult. They also give off potentially unsafe gases.

In general, the traditional waste management system gives the following problems:

1) Most people throw the trash here and there, anywhere and the simple reason behind it is that they are unaware of the nearest bin.

2) Some trash bins are overfilled while others are underfilled by the trash collection time.

3) Unoptimized truck routes result in excessive fuel usage and environmental pollution.

4) All collected trash is combined which complicates sorting at the recycling facility.

5) Overfilled trash bins create unhygienic conditions, Some of these problems can be mitigated by implementing smart waste management systems.

This project deals with the problem of Waste management in smart cities, where the garbage collection system is not optimized. This project enables the organizations to meet their needs of smart garbage management system.

This system provides the following functionalities:-

1) Navigate the users to the nearest available EMPTY bin.

2) Let knows the truck drivers, the fill level of each garbage bin in a locality or city at all time.

3) Gives a cost effective and time saving route to the truck drivers.

4) Find right bin for your waste type – general, glass, plastic, etc.

5) Allows user to take a picture and file a report to Administration in-charge in case of any

overflow or poor service.

8

2. PROCESS MODEL

We chose prototype model because of the following reasons:

• Users are actively involved in the development. • Since in this methodology a working model of the system is provided, the users get a

better understanding of the system being developed. • Errors can be detected much earlier. • Quicker user feedback is available leading to better solutions

Fig 2.1: Prototype Model

9

3. REQUIREMENTS ANALYSIS

3.1 DFD

3.1.1 Context Diagram/Level-0 DFD

Fig 3.1: Level-0 DFD/Context Diagram

10

3.1.2 Level 1 DFD

Fig 3.2: Level-1 DFD

11

3.1.3 Level 2 DFD

3.1.3.1 Login Module

Fig 3.3: Module for login functionality

12

3.1.3.2 Trash Details Module (asks user to select the category of trash he//she has)

Fig 3.4: Module for trash details functionality

13

3.1.3.3 Search bin Module (for users)

Fig 3.5: Module for Search bin functionality

14

3.1.3.4 Find Optimized route Module

Fig 3.6: Module for Finding optimized route functionality

15

3.1.3.5 Report a problem Module

Fig 3.7: Module for Report a problem functionality

16

3.2. DATA DICTIONARY Legal character: [a-z|A-Z]

Digit: [0-9]

Special character: [@|$|#|+|-|.]

1.

Name

Firstname+Lastname

2. usertype {legal characters}*

3. Duty area {legal characters+Digit }*

4. Username {legal characters+Digit+special characters}*

5. Password {legal characters+Digit+special characters}*

6. Contact {Digit+ Digit+ Digit+ Digit+ Digit+ Digit+ Digit+ Digit+ Digit+ Digit}

7. Complaint {Legal character}*

8. Complaint id {Digit Digit+ Digit+ Digit+ Digit+}

Table 1: Data Dictionary

17

4 SOFTWARE RESOURCE SPECIFICATION (SRS)

4.1 INTRODUCTION

4.1.1 PURPOSE The main purpose of this SMART-E-TRASH app is to increase the efficiency by reducing the drawbacks of existing waste collection process. It allows the citizens to properly dispose off their household trash in an effective manner so that it’s easy to segregate it properly afterwards. Also, it provides a nice platform for the truck drivers by providing them an optimized dynamic route to collect the trash; thereby resulting in a cost-effective collection process(saving fuel and lowering carbon emissions ). A friendly UI is provided so that the requests made by the user give correct results by accessing the information stored in the database. It also allows the citizens to report an issue regarding any problem with the bins or poor service.

4.1.2 SCOPE

This app aims at providing a data driven collection process to the trash collection trucks by giving them a dynamic route instead of any predefined route on the basis of the analysis done by knowing the fill-level of bins. It will also provide a platform to the citizens by allowing them to view the nearest bins with exact trash type and fill-level and also for reporting any issue directly to the main authority in-charge.

4.1.3 DEFINITIONS

• UI - User Interface • SRS-Software Resource specification • GPS-Global Positioning System • DBMS – Database Management System

4.1.4 OVERVIEW

The rest of the document not only describes various functions but also gives details about how these functions are related to each other. Apart from the data flow diagrams, the document also contains cost estimates for developing this system; various risks associated

18

with the system and the ways to mitigate them. The timeline chart describing how the entire project was scheduled has been attached followed by the architectural design of the software. A flow graph has been generated corresponding to this module, cyclomatic complexity has been computed and test cases that were used to test the system have also been mentioned.

4.1.5 REFERENCES • [1] 2017 5th International Conference on Instrumentation, Control, and

Automation (ICA) Yogyakarta, Indonesia, August 9-11, 2017

• [2] IOT Based Smart Garbage alert system using Arduino UNO Date and journal: 2016 IEEE Region 10 Conference (TENCON) Author: Dr.N.SATHISH KUMAR, B.VIJAYALAKSHMI, R. JENIFER PRARTHANA, A .SHANKAR (S.R.M., Coimbatore, INDIA)

• [3] Solid waste management based upon IoT or Smart city Date and Journal: ICICCS 2017 Author: Krishna Nirde, Prashant S. Mulay, UttamM.Chaskar (C.O.E. Pune).

• [4] SMART WASTE MANAGEMENT SYSTEM Date and journal: 2015, ICCES Author: MS. NIRMALA Y BARIKER, MR. JASON VINOD D’SOUZA (MIT, Mangalore)

• [5] SVASTHA: An effective solid waste management system in Android OS Date and journal: 2013 by IEEE Global humanitarian technology Author: Issac and akshai

• [6] Smart bin using Arduino and other sensors Date and journal: 2013 by FCIS Author: Yusuf et al may 2018 (IJESRT) Author: Swati Sharma and sarabjeet Singh.

4.2 PROJECT DESCRIPTION

4.2.1 PROJECT PERSPECTIVE

The existing waste collection process works on a predefined basis and needs to be altered in way so as to make it dynamic. There is no way to file a complaint in case the nearby citizens face some problems with the bins, neither the trash bin collectors are able to achieve a fuel and cost saving route.

Hence, Saaf-suthri city app is proposed with the following product perspective:

19

• The computerization of the traditional system will allow the citizens to know real time fill-levels of the bins, so that they adjust their plans to throw the trash according to it.

• The app allows the bin collectors to know which bin has exceeded a certain limit and needs to be genuinely emptied.

• The customer complaints will be actively tracked and the status will be displayed as {1. Filed 2. In process 3. Recovered}

• The system provides for user-ID validation, hence unauthorized access is prevented.

4.2.2 PRODUCT FUNCTION

The Saaf-suthri city app is an independent android based application with many user interfaces. These interfaces help the user to interact with the app. The entire functionality of this app can be subdivided into the following modules:

1. LOGIN 2. TRASH DETAILS 3. SEARCH BIN 4. FIND OPTIMIZED ROUTE 5. REPORT AN ISSUE

4.2.3 USER CHARACTERISTIC

• The user must have a basic knowledge of accessing android smartphones. • The user should be comfortable working with English language. • The user must have enabled google maps(GPS System) in his/her smartphone.

4.2.4 GENERAL CONSTRAINT

This app is an IoT based application that would take data from the sensors embedded in the trash bins. It is a multi-user app and can handle 1K customers at this point of time and in future this number will increase. This app is compatible with android version 7.0 and further.

4.2.5 ASSUMPTION AND DEPENDENCIES

20

This app requires active GPS system (GOOGLE MAPS )to be installed in user’s mobiles otherwise the app will not show accurate results.

4.3 SPECIFIC REQUIREMENTS

4.3.1 EXTERNAL INTERFACES The external interfaces for the Saaf-Suthri city app are relative to the various users which have independent access to the app and to the main system controlled by the admin. These interfaces are described below:

4.3.1.1 User Interfaces This interface must be highly intuitive or interactive. It has different screens for different tasks with properly selected icons It defines the human-computer interaction of the E-Banking Software. The user interacts with the system to authenticate transactions and to make use of the various services provided by the software. The Administrator interact with the system with master control and have special privileges such as managing users, access to the database etc. The pin and password confidentiality should be maintained. This can be done by using asterisks at the password panel. Proper security messages should be displayed at most of the places.

4.3.1.2 Hardware Interfaces As this system is an online Web-based application so a client server will be the most suitable Organizational style for this system. Computer systems will be needed by each of the actor as well as that user must be connected to the internet. So, concisely following hardware will be needed.

1) Computer systems

2) Internet availability

4.3.1.3 Software Interfaces The software requirements of the system include:

1) Any windows operating system. 2) The PHP must be installed. For the database handling MYSQL must be installed. These

products are open source products. 3) The final application must be packaged in a set up program, so that the products can

be easily installed on machines. This application must be networked to corresponding banks.

21

4.3.1.4 Communication Interfaces All system interfaces communicate in order to service the requests made by the user. The communication medium (wired or wireless) are external interfaces that communicates with control panel of the E-Banking Software. This communication allows for failure messages and requests to be sent and received by the main system.

4.3.2 FUNCTIONAL REQUIREMENTS

This section provides the functional overview of the product. The project will require the PHP as a front end and at the back end the database MYSQL will be running. Various functional modules that can be implemented by the product will be:

1. LOGIN 2. TRASH DETAILS 3. SEARCH BIN 4. FIND OPTIMIZED ROUTE 5. REPORT AN ISSUE

4.3.2.1 LOGIN – Both customers as well as truck drivers will login by entering their username and password. They would be given an option to choose whether they are customers or truck drivers and screens will be displayed according to that. In case, the customer forgets the password they can select the forget password option and answer the security questions to create a new password.

4.3.2.2 TRASH DETAILS – After the customer successfully logs in, the trash details page is displayed. Here the customer needs to select the type of trash he/she has(as for instance if a person Manoharlal has a trash including some plastic, some paper and some vegetable peels) so the app will suggest you to segregate it right away by your end only and will display the below image and guide you in case you face some problem . In this screen you will, fill in the details of your trash.

22

Fig 4.1: Select category list

4.3.2.3 SEARCH BIN – Since the customer has already enabled GPS system in his/her mobile, so automatically the app traces user’s location. Accordingly the app tells the nearest available bins; keeping in mind the type of trash, user has. After the user selects the appropriate bin according to his/her convenience , the app will provide the location to that bin.

4.3.2.4 FIND OPTIMIZED ROUTE – This functionality is designed by focusing on truck drivers .This screen will open if the user is a truck driver(Truck driver must be entered in user type). The truck driver would enter his/her area of duty along with date and timeslot in which he/she is planning to come and collect the trash With the help of embedded sensors in the bin, the app will display the volume of bins(depicting their fill levels). Apart from this an optimized route would be designed automatically and displayed to the truck driver which would probably give an idea to the truck driver of an appropriate time for collection.

4.3.3 PERFORMANCE REQUIREMENTS The performance requirements are as follows:

• System login shall take less than 5 seconds.

• Enabling location shall return results within 10 seconds.

23

• Entering type of trashes shall be processed within 10 seconds.

• Optimize/shortest path shall be processed within 10 seconds.

• System shall support any number of users simultaneously and maintain the speed at

maximum.

• Authority will be working whole 24*7 times.

4.3.4 LOGICAL DATABASE REQUIREMENTS A one-to-many relational database shall be used in order to validate various user complaints and failure types. Moreover, failures are to be logged for future reference.

4.3.5 DESIGN CONSTRAINTS

The saaf-suthri city software run on an embedded system. The system shall use a

real-time processor for dynamic memory allocation in order to handle continuous

activity. The software must be simple and user friendly. System supports all web

browsers (i.e. graphical, non-graphical).

4.3.5.1 Standard compliance: The ‘saaf - suthri city ' will follow existing standards and regulations, which are stated in the smart city disclaimer policy.

4.3.5.2 Hardware Limitations: This software shall run only on a computer with internet connection. Authority can perform operations either offline or online.

4.3.5.3 Reliability and Fault Tolerance:The application should be highly reliable and it should generate all the updated information in correct order.

24

4.3.5.4 Security: It should require a login password for user for entry to a new environment and for garbage collector ,it needs complete information(name, phone number, duty area and time of duty).

4.4 SOFTWARE SYSTEM ATTRIBUTES

4.4.1 Reliabilty:-The average time of failure shall be 30 days. In the event that a server does crash, a backup server will be up and running within the hour 4.4.2 Availability: Any information about the account should be quickly available from any computer to the authorized user. The previously visited customer’s data must not be cleared.

4.4.3 Maintainability: Any updates or detect fixes shall be able to be made on authority-side computers only without any patches required by the user

4.4.4 Portability: The application should be portable on any windows-based system. It should not be machine specific.

4.4.5 Security:-Users will be able to access only their personal information and not

that of other users. Any other garbage collector can’t seek other’s information.

25

5 PROJECT PLANNING 5.1 PROJECT SCHEDULING

Work Tasks Planned Start

Actual Start Planned Complete

Actual Complete

Assigned Person

Effort Allocated

Problem statement

Jan.w1 Jan.w2 Jan.w2 Jan.w3 Lovely, kanwal 2 person per week

Software Lifecycle Model

Jan.w2 Jan.w3 Jan.w3 Jan.w3 Lovely 1 person per week

Project Scheduling

Jan.w3 Jan.w4 Jan.w3 Jan.w4 kanwal 1 person per week

Timeline Chart Jan.w3 Jan.w4 Jan.w3 Jan.w4 kanwal 1 person per week

Software Requirement Specification

Jan.w3 Jan.w4 Feb.w1 Feb.w2 Lovely, kanwal 2 person per week

Context Level Diagram Feb.w1 Feb.w2 Feb.w2 Feb.w2 kanwal 1 person per

week

Data Flow Diagram 1 Feb.w2 Feb.w3 Feb.w2 Feb.w3 kanwal 1 person per

week

Data Flow Diagram 2 Feb.w3 Feb.w4 Feb.w3 Feb.w4 Lovely, kanwal 2 person per

week

Data Dictionary Feb.w3 Feb.w4 Feb.w3 March.w1 Lovely 1 person per week

Project Metrics Feb.w4 March.w1 Feb.w4 March.w1 kanwal 1 person per

week

Effort Estimation (cocomo model)

March.w1 March.w2 March.w2 March.w3 kanwal 1 person per week

Risk Analysis March.w3 March.w3 March.w3 March.w4 Lovely, kanwal 2 person per

week

ER Diagram March.w4 March.w4 March.w4 April.w1 Lovely, kanwal 2 person per

week

Data Design March.w4 April.w1 March.w4 April.w1 Lovely 1 person per week

System Design April.w1 April.w1 April.w1 April.w2 Lovely 1 person per week

Testing April.w2 April.w2 April.w2 April.w2 Lovely, kanwal 2 person per

week

References April.w2 April.w3 April.w2 April.w3 Lovely 1 person per week

26

Annexure March.w1 March.w2 March.w1 March.w3 Lovely 1 person per week

Table 2: Project scheduling

5.2 TIMELINE CHART WORK TASKS JANUARY FEBRUARY MARCH APRIL

W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4

Problem Statement

Software Lifecycle Model

Project Scheduling

Timeline Chart

Software Requirement Specification

Context Level Diagram

Data Flow Diagram 1

Data Flow Diagram 2

Data Dictionary

Project Metrics

Effort Estimation (COCOMO)

Risk Analysis

ER Diagram

Data Design

Component Design

Testing

References

Annexure

27

Table 3: Timeline chart

5.3 FUNCTION POINT METRICS

• It is used as a means for measuring the functionality delivered by a system.

• Using historical data, Function Point metric can be used to: -

i. Estimate the effort or cost required to design, code or test the software.

ii. To predict number of errors that will be encountered during testing.

iii. Forecast number of components or number of projected source links in

implemented system.

• Function points are derived using empirical relationship based on countable (direct)

measures of software's information domain and quantitative assessment of software

complexity.

• Information Domain Values are defined as:

i. External Inputs (EI)

ii. External Outputs (EO)

iii. External Query (EQ)

iv. Number of Internal Logical Files (ILF)

v. Number of External Interface Files (EIF)

To compute function points (FP), the following relationship is used:

FP= count total × [0.65 + 0.05 × ∑ (Fi)]

Calculation of Value Adjustment Factors (VAF) is based on the responses of the following questions:

1. Does the system require reliable backup and recovery? 4

2. Are specialised data communications required to transfer the

information to and from the application?

3

3. Are there distributed processing functions? 3

4. Is performance critical? 3

28

5. Will the system work in an existing heavily utilised operational

environment?

3

6. Does the system require online data entry? 2

7. Does the online data entry require input transaction to be built over

multiple screens or operations?

3

8. Are Internal Logical Files updated online? 3

9. Are input-output queries or files complex? 2

10. Is the internal processing complex? 3

11. Is the code designed to be reusable? 4

12. Are conversion and installation included in design? 2

13. Is the system designed for multiple installations in multiple

organizations?

2

14. Is the application designed to facilitate changes and ease of use by

the user?

5

COUNT TOTAL (Σ Fi) 42

Table 4: Value Adjustment Factors (VAF)

The count total is the sum of all FP entries obtained from the following table:

INFORMATION

DOMAIN

VALUES

COUNT WEIGHING FACTOR

SIMPLE AVERAGE COMPLEX

External Inputs

(EI)

12×

3

4

6

= 36

External Outputs

(EO)

7×

4

5

7

= 28

29

External

Enquiries

(EQ)

5×

3

4

6

= 15

Internal Logical

Files

(ILF)

5×

7

10

15

= 30

External

Interface Files

(EIF)

1×

5

7

10

= 5

TOTAL COUNT

114

Table 5: Risk management table

FUNCTION POINT (FP) = Total Count × [0.65 + (0.01×Σ (Fi))]

= 114× [0.65 + (0.01×30)]

=108.3

= 108

5.4 COCOMO II MODEL

Barry Boehm gave a hierarchy of software estimation models called COCOMO i.e.

constructive cost model. The original COCOMO model was widely used in the industry and

was later evolved into a comprehensive. Estimation model called COCOMO II model.

COCOMO II is a hierarchy of estimation models that consists of:-

1. Application composition model

2. Early design stage model

30

3. Post-architecture stage model

Application Composition Model

It is used during the early stages of software engineering when prototyping of user interfaces,

assessment of performance and software system interaction are important.

Early Design Stage Model

It is used once. The requirement has been stabilized and basic software architecture is

established.

Post Architecture Stage Model

This model is used during the construction of software.

These model use sizing information for which 3 options are available which are object

points, function points and lines of source code.

Object-point is an indirect software measure computed using counts of number of

screens are the user interface, number of reports generated and number of reusable

components and 3 GL Components required to build the application. Each object

instance is classified into one of 3 complexity level: Simple, Medium or Difficult.

Complexity is a function of number and source of client and server data tables

required to generate screen or report and number of views or sections presented as part

of the screen or report.

Complexity weighting for object types

OBJECT TYPE

COMPLEXITY

WEIGHT

SIMPLE MEDIUM DIFFICULT

SCREENS 1 2 3

REPORT 2 5 8

3GL

COMPONENTS

10

31

Table 6: Complexity weight for object type

Object point count=Original number of object instance*Weighting factor

=12*1 = 12

No reusable components used [reuse = 0]

NOP = New Object Points (or Object Point Counts)

= (Object Points)*[(100-%reuse)/100]

= (12)*[(100-0)/100] = 12

Productivity rate for object points

Developer’s

experience or

capability

VERY LOW LOW NORMAL HIGH VERY HIGH

Environment

maturity or

capability

VERY LOW LOW

NORMAL HIGH VERY HIGH

Value 4 7 13 25 50

Table 7: Productivity weight for object point

PROD (Productivity Rate) = NOP/Person Month

PROD = (7+7)/2 = 7

Estimated Effort = NOP/PROD

= 12/7

= 2 PM

32

The total number of screens in reality will be more in number but because we are just

showing the sample screens, our effort calculated is 2PM which is according to 12screens

only.

5.5 RISK ANALYSIS

• SOFTWARE RISKS It involves 2 aspects: uncertainty and loss. Uncertainty means risk may or may not happen. If risk becomes reality then unwanted consequences or loss will occur.

• TYPES OF RISKS According to general categorization there are 3 types of risks:

1. Known Risk 2. Predictable Risk 3. Unpredictable Risk

Another category of risk type:

1. Project Risk 2. Technical Risk 3. Business Risk

Project Risk: Identify potential problems that might occur in budget, schedule and staffing. It also includes project complexity, project size and degree of structural uncertainty. Technical Risk: Identify potential design problem, implementation problem, interface problems, verification problem and maintenance problem. They threaten the quality of the software produced. Business Risk: Threatens the viability of the software to be built and often jeopardize the project or the product. There are 5 types of business risks:

a) Market risk b) Strategic risk c) Sales risk d) Management risk

33

e) Budget risk

RISK ANALYSIS TABLE S.no. Risk Category Probability Impact RMMM Plan 1. Delivery deadline

will be tightened. Project Risk 30% 1 In this case, we

use extra members to finish the work early.

2. Losing all the project data either due to attack of virus on the hard disk or hard disk failure.

Project Risk 20% 2 A backup of the database should be taken for the source code and documentation.

3. Some team might leave the project in between.

Technical Risk

30% 2 A staff should always be prepared beforehand those who know about the project.

4. Lack of cohesion Project Risk 10% 3 Prescribed guidelines should be prepared of how to deal with each other.

Table 8: Risk management table

34

6. DESIGN 6.1 ER DIAGRAM

Fig 6.1: ER diagram for the software

6.2. DATA DESIGN

S.NO. FIELD

NAME

DATA TYPE FIELD

LENGTH

DESCRIPTION

1.USER Usertype String 15 Give the name of

customer

Username Alphanumeric 30 Primary key, Gives the

username to login as

user

Password Alphanumeric 20 Primary key, Gives the

password to login as

user

35

Table 9:Data design table

complaint String 20 Gives the detail about

complaint

2.GARBAGE

COLLECTOR

Name String 15 Gives the name

a_username Alphanumeric 20 Primary key, Gives the

username

a_password Alphanumeric 20 Primary key, Gives the

password

a_phone Numeric 10 Gives the phone no.

Area of duty Alpha

numeric

50 Gives the address of

the area

3.ADMIN/AUTHORITY id Alphanumeric 20 Primary key, Gives the

id of complaint

Status of

complaint

String 30 Gives the status of

complaint(approved,in-

process)

36

6.3 COMPONENT LEVEL DESIGN BFS(V, E, s) for shortest path to the bin in customer's locality /*

color[u] = White - for the "undiscovered" state, color [u] = Gray - for the "discovered but not fully explored" state, and color [u] = Black - for the "fully explored" state. s=source vertex=customer's location u=dustbin area/locality of customer viewed in map

*/

• for each u in V -{s} • do color[u] <- WHITE • d[u] <- infinity • ^[u] <- NIL • color[s] <- GRAY • d[s] <- 0 • ^[s] <- NIL • Q <- {} • ENQUEUE(Q, s) • while Q is non-empty • do u <- DEQUEUE(Q) • for each v adjacent to u • do if color[v] <- WHITE • then color[v] <- GRAY • d[v] <- d[u] + 1 • ^ [v] <- u • ENQUEUE(Q, v) • DEQUEUE(Q) • color[u] <- BLACK

Print-Path(G, s, v) if v = s

then print s else if p[v] <- NIL

then print "no path exists from " s "to" v" else Print-Path(G, s, p[v])

print v //path from my location to that bin

37

7.TESTING White box testing, sometimes called glass box testing is a test case design philosophy that uses the control structure described as a part of component level design to derive test cases. We are performing whit box testing for shortest path. Using white box testing technique, we can derive test cases that: 1. Guarantee that all the independent paths within a module have been exercised at least once. 2. Exercise all logical decisions on their true and false sides. 3. Execute all loops at their boundaries and within their operational bounds 4. Exercise internal data structures to ensure their validity. We are performing white box testing of procedure transaction Pseudocode for shortest path:-

BFS(V, E, s) for shortest path to the bin in customer's locality /* 1. color[u] = White - for the "undiscovered" state, 2. color [u] = Gray - for the "discovered but not fully explored" state, and 3. color [u] = Black - for the "fully explored" state. 4. s=source vertex=customer's location 5. u=dustbin 6. area/locality of customer viewed in map */ 1. for each u in V -{s} //for each u in V[G] except s 2. do color[u] <- WHITE 3. d[u] <- infinity 4. ^[u] <- NIL

5. color[s] <- GRAY // Source vertex discovered 6. d[s] <- 0 // initialize 7. ^[s] <- NIL // initialize 8. Q <- {} // Clear queue Q

38

9. ENQUEUE(Q, s) 10 while Q is non-empty 11. do u <- DEQUEUE(Q) // That is, u = head[Q] 12. for each v adjacent to u // for loop for every node along with edge. 13. do if color[v] <- WHITE // if color is white you've never seen it before 14. then color[v] <- GRAY 15. d[v] <- d[u] + 1 16. ^ [v] <- u 17. ENQUEUE(Q, v) 18. DEQUEUE(Q) 19. color[u] <- BLACK

if v = s then print s else if p[v] <- NIL then print "no path exists from " s "to" v" else Print-Path(G, s, p[v]) print v //path from my location to that bin

Figure 7.1 :Shortest path

39

FLOW GRAPH:

Fig 7.2:control flow graph

CYCLOMATIC COMPLEXITY-

V(G) = E-V+2

=16-11+2

=7

Number of region= number of predicate node + 1

=6 + 1 = 7

Number of independent paths=4

Independent paths: -

• 1-2-3-4-5-6-7-8-9-10-11

40

• 1-2-3-4-5-6-11 • 1-2-3-5 • 1-2-3-4-5-6-7-8-11

8. ANNEXURES

41

Figure 8.1: SCREEN 1- Home Screen

Figure 8.2: SCREEN 2-forgot password screen

42

Figure 8.3: SCREEN 3- setting up new password Screen

Figure 8.4: SCREEN 4- trash choosing Screen

43

Figure 8.5: SCREEN 5- user Screen to enter particular type of trash

Figure 8.6: SCREEN 6- user’s trash choice detail Screen

44

Figure 8.7: SCREEN 7- shortest path screen for user

Figure 8.8: SCREEN 8- user last Screen for the accurate path

45

Figure 8.9: SCREEN 9- driver’s personal detail Screen

Figure 8.10: SCREEN 10- garbage collector’s last activity display Screen

46

Figure 8.11: SCREEN 11- trash volume display Screen

Figure 8.12: SCREEN 12- optimize path for driver to the filled bin Screen