BACHELOR OF COMPUTER APPLICATION

Size: px

Start display at page:

Download "BACHELOR OF COMPUTER APPLICATION"

Melina Ramsey
5 years ago
Views:

1 SHREE M. & N. VIRANI SCIENCE COLLEGE RAJKOT PROJECT REPORT AS A PARTIAL REQUIREMENT FOR THE DEGREE OF BACHELOR OF COMPUTER APPLICATION YEAR: 2016 TRAFFIC POLICE GUIDED BY: Mr. PRAKASH GUJARATI SUBMITTED BY: CHAUN SHANI J. 1 Prepared By: Chaun Shani

2 `Sr.No. Chapter Name Page Number 1. Project Profile Project profile 2. Introduction to the System Overview of the System 2.3 Drawback of the System 2.3 Proposed system 3. System Planning Scope of the system 3.2 Feasibility Study 3.3 Software Development Process Model 3.4 Software Specification 3.5 Hardware Specification 4. Requirement Analysis Software Requirement Specification (SRS) 5. System Design Context DFD 5.2 Data Flow Diagram (DFD) 6. Data Dictionary System Output 30 Project Schedule Testing 8. Limitation And Scope of Development System Limitation 2 Prepared By: Chaun Shani

3 ACKNOWLEDGEMENT It gives me great pleasure to express my gratitude and respect to all who inspired me in completion of this project, with heart-felt gratitude; I would like to acknowledge the great support, help and guidance of my Internal Project Guide Prof. MR. Prakash Gujarati who stimulated my mind towards technical and logical thinking and gave me guidance to make project highly useful and knowledge based experience. I have developed a TRAFFIC POLICE APPLICATION as a project work during the Third Year (6th Semester) of B.C.A, Atmiya Institute of Technology & Science (Rajkot). I would like to thank all our faculty members of my college and staff members of this institute and our colleagues with whom we have shared thoughts and moments in improving my skills. Thanking you all for your guidance. 3 Prepared By: Chaun Shani

4 4 Prepared By: Chaun Shani

5 Traffic Police PROJECT-PROFILE Project-Title: Atmiya College Management System Institution: Shree M. & N. Virani Science College Front-End: Android (Eclipse) Back-End: SQLite Team-Size: 1 Project-Guide Mr. Prakash Gujarati Submitted By: Shani Chaun J. Submitted To: Saurashtra University. 5 Prepared By: Chaun Shani

6 6 Prepared By: Chaun Shani

7 2.1 OVERVIEW OF THE SYSTEM Official Traffic police Android App Through This App one can able to see Traffic E-Challan generated for vehicles in Gujarat State. This is a part of Road Safety and Traffic Violation Control System. 7 Prepared By: Chaun Shani

8 DRAWBACK OF THE SYSTEM The Problem with manual transaction is sometime wrong and hard to handle it. The aim of this application is traffic police can add challan from application and victim can aware about acts and rules. Some of the drawbacks of the existing system are as under. Easy to handle large amount of data. Paper less system Friendly environment 2.3 PROPOSED SYSTEM Add Challan. View Challan. List of Rules and Acts. Save paper Easy to handle data. 8 Prepared By: Chaun Shani

9 9 Prepared By: Chaun Shani

10 3.1 SCOPE OF THE PROPOSED SYSTEM The proposed system will handle all day to day transactions. Manages all the detail about challan. It will generate challan for the victim 10 Prepared By: Chaun Shani

11 3.2 FEASIBILITY STUDY Feasibility Study is the test of the system proposal according to it work ability, impact on the current system, ability to meet the needs of the current users and effective use of the resources. Its main objective is not to solve the problem, but to acquire its scope. It focuses on following: Meet user requirements. Best utilization of available resources. Develop a cost effective system. Develop a technically feasible system. There are three aspects in the feasibility study: Technical Feasibility Economical Feasibility. Operational Feasibility 11 Prepared By: Chaun Shani

12 Technical feasibility: - The technical issues usually raised during the feasibility stage of the investigation include following: The necessary technology must be existed to do what is suggested. The proposed equipment must have the technical capacity to hold the data required to use the new system. There must be technical guarantees of accuracy, reliability ease of access and data security. Software to be used for making the system like as Android eclipse and SQLite available within the organization and therefore technically the project is feasible. 12 Prepared By: Chaun Shani

13 EconomicalFeasibility: - In economical feasibility, analysis of the cost of the system is carried out. The system should be only developed if it is going to give more benefits than its cost In this system it reduces duplication of data as they are stored and used twice and thrice as it is stored in database. 13 Prepared By: Chaun Shani

14 3.3 SOFTWARE DEVELOPMENT PROCESS MODEL There are a variety of varying process models for software engineering. They are as follows: 1. The Linear Sequential Model (The Waterfall Model). 2. The Prototyping Model. 3. The RAD Model. 4. The Incremental Model. 5. The Spiral Model. Our system follows waterfall model. 14 Prepared By: Chaun Shani

15 3.4 SOFTWARE SPECIFICATION Given below is recommended specification of required software to develop the system Operating system : Microsoft Windows7 for higher Front End : Android Eclipse Back End : SQLite Browser : Jellybean 4.2 to upgrade version 3.5 HARDWARE SPECIFICATION Given below is recommended hardware specification that required at server side to run the software 512 MB Memory card 2 GB RAM 15 Prepared By: Chaun Shani

16 16 Prepared By: Chaun Shani

17 4.1 SOFTWARE REQUIREMENT SPECIFICATION (SRS) Introduction Purpose: The purpose of this document is to describe all the external requirements for the traffic police app package. Scope: Appropriate road safety policy is one of the essential elements of a well-balanced overall transport and public health policy (Michael Ray, 1995). From this point of view, the national parliament, government, government ministries and agencies have one of the main responsibilities for road safety. They prepare professional starting points, decide about transport and health policy and put them into a practice.1 Road safety responsibility also lies in private agencies, different associations, non governmental organisations and individual road users. Definition: o Traffic Police application Functional Requirements Following is the general description of Traffic Police Application. Presently, most of the processes are done online. Following are functional requirements, which atomization are expected from the Traffic Police Application. Maintain personal profile of each Police officer. Application Provide To Information all victim. Application Provide to Online Product Penalty to the victim. 17 Prepared By: Chaun Shani

18 4.1.4 Performance Constraints The application should take only reasonable amount of time while furnishing the above-mentioned reports Design Constraints Software Constraints: o In addition to this server module use SQLite as back end database management system. o It has to be written in Android eclipse. Hardware Constraints: The application will run on an android operating system jellybean 4.2 or above processor 18 Prepared By: Chaun Shani

19 5.1 DATA FLOW DIAGRAM (DFD) One of the tools of the structure analysis is the Date Flow Diagrams. A DFD is a graphical representation of the system. The Data Flow Diagram is used by the system analyst to explain the flow of the data in the system. Process A process represents some Amount of work being performed on the data. A process does transformation of data from one form to another. A circle represents a process. The process must be named and numbered appropriately. Data flow A Data Flow designates an interface among different components in the DFD. It represents the path of data as it flows through the system. An Arrow represents a data flow. The name of the data flow is written along the line. Data source A Data Source is a repository of data. An open ended rectangle or two horizontal parallel lines represent it. A DFD, which describes the system at a very general level, is called the Context Diagram. It contains a single process, but it plays a very important role in studying the system. The following pages displayed the context diagram and the DFD s of subsequent levels of the Hard & Soft Solution 19 Prepared By: Chaun Shani

20 PROCESS ENTITY DATA FLOW DATA STOCK / DATA BASE 20 Prepared By: Chaun Shani

21 5.1.1Context Level DFD (Admin) Level 0 Admin Add, Update, Delete View Record Traffic Police Display Record 21 Prepared By: Chaun Shani

22 5.1.1Context Level DFD (User Side) User Add, Update and Delete Challan Traffic Police Display Result 22 Prepared By: Chaun Shani

23 5.2.1SYSTEM ACTIVITY DIA-GRAM System Activity-Diagram Login Registerform Login successfully Login failed Home 23 Prepared By: Chaun Shani

24 1.Admin Login Add Challan Add/Update / delete Challan Update,Del ete Challan View Challan Logout 24 Prepared By: Chaun Shani

25 25 Prepared By: Chaun Shani

26 This page is Splash Screen. 26 Prepared By: Chaun Shani

27 Admin Side : login This Page is used for ADMIN Login. 27 Prepared By: Chaun Shani

28 Home This page display Home Page. 28 Prepared By: Chaun Shani

29 Registration Registration Form. 29 Prepared By: Chaun Shani

30 This page Add to Chalan. 30 Prepared By: Chaun Shani

31 All Recoreds Display in this page. 31 Prepared By: Chaun Shani

32 List & Rules This page dislay Rules and Acts. 32 Prepared By: Chaun Shani

33 This page shows about Developer 33 Prepared By: Chaun Shani

34 34 Prepared By: Chaun Shani

35 Project Schedule: Index Task Name Start Finish Duration Dec Jan Feb Mar Requirement Analysis 2. Project Planning 04/12/ /12/ Days 05/12/ /12/ Days 3. System Design 22/12/ /12/ Days 4. Detail Design 29/12/ /08/ Days 5. Coding & Unit Testing 6. System Integration & Testing 18/01/ /01/ Days 26/02/ /02/ Days 7. Submission 11/03/ /03/ Days 35 Prepared By: Chaun Shani

36 36 Prepared By: Chaun Shani

Test documentation is the complete suite of artifacts that describe test planning, test design, test execution, test results and conclusions drawn from the testing activity.

37 Test documentation is the complete suite of artifacts that describe test planning, test design, test execution, test results and conclusions drawn from the testing activity. As testing activities typically consume 30% to 50% of project effort, testing represents a project within a project. Testing activities must therefore be fully documented to support resource allocation, monitoring and control. This page identifies the types of documents you need to set up and run your test program and summaries their content. 37 Prepared By: Chaun Shani

38 TESTING: This section discusses the testing strategy, methodology and types of tests that the product must pass in order to pass quality assurance and customer acceptance. A detailed test plan will be created as part of the implementation phase. Test Strategy: The testing strategy used will focus on reliability and performance of the product. This includes the reporting client hardware, software, management software, and overall system integration. The foundation for the success of this product is the Good Bandwidth. No matter how reliable the software if the bandwidth is not good the website will not work. The next key to success is the performance of the website both the reporting user and remote server. Most operations must performance at a sub second performance level. This does not mean that the operation is completed in a sub second although every effort should be done to actually hit the task assign metric rather that the user sees the system respond in some function within a second. 38 Prepared By: Chaun Shani

39 The final key is that the internal and scheduled processes operator reliable over long stretches of time with limited user intervention. In order to grade the quality of the implementation, the testing will focus on grading the reliability and perfor mance characteristics of the all aspects of the product. The system will have to pass multiple repeated testing and hit specific metric agreed upon ranges. Failure to meet the metric will mean the product is not implemented correctly and must be corrected. This does not mean the product will be defect free however it will have no show stopper bugs and all the features work a majority of the time (95+%) or report why it did not work and how the user can correct the problem. In addition, the system if possibl e should report all exceptions. Once in the field the product reliable will be gauged by how many error reports are received. Testing Methodology: The testing team will adopt the following methodology for testing: 1. All errors anomalies will be reported to a bug database. 2. No new builds will be accepted for testing without: a. An issue report includes what issues were resolved in the build, what issues are left, their status and by when the issue will be resolved. b. The mock test results which must be all pass. c. The unit testing results which must be all pass. 3. Automated testing will be used where ever possible. These automated tests will be incorporated into the build process. Failure to pass all automated tests is a failed build. 39 Prepared By: Chaun Shani

40 4. Before a bug can be fixed every effort must be used to create a test script that reproduces the error. If a bug cannot be reproduced using a test script then the bug is marked not reproducible. If too many bugs are marked as not reproducible then all development will stop until it is determined why the bugs cannot be reproduced or the development team reproduces the bugs. 5. Hand testing will only be used if no other recourse exists. The goal of automated testing is to make sure that no new bugs are introduced while fixing bugs. Every feature will have a test that the software fails before a single line of code is written. Development will adhere to test driven development methodology. More complex tests will be created by the QA group and client for acceptance. This includes metrics. These metrics will cover: Mean time to Failure The amount of time before the system fails. The percentage reliability The percentage of passed tests divided by the total number of tests and number of runs of the tests. Performance for each major feature set This is the actual runtime performance of the system. There will be a metric for each major feature set. 40 Prepared By: Chaun Shani

41 The testing will include: Unit testing Scripted testing of all program elements including system libraries written by development and user interface. Integration testing Scripted testing of various scenarios using the whole system. Reliability and recovery testing of the reporting user Testing for breaking the system including failure scenarios like unplugging the system in the middle of a task. Scalability testing of the management server Testing to see how many users can use the system and the degradation to the performance of the system. 41 Prepared By: Chaun Shani

42 42 Prepared By: Chaun Shani

43 8.1 SYSTEM LIMITATION Most of the software projects have certain limitation. This system has limitation in its functional areas. It s provides normal security features (not encryption). Future Enhancements: 1) Handle all kind of things about police by one application. 43 Prepared By: Chaun Shani

44 BIBLIOGRAPHY Websites Books Android 44 Prepared By: Chaun Shani

SCHOOL MANAGEMENT SYSTEM

PROJECT REPORT ON SCHOOL MANAGEMENT SYSTEM (Cyber School Management) As Partial Fulfillment of Bachelor of Computer Science (Information Technology & Computer Applications) Submitted to Shree M & N Virani