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
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
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
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