Escolar Documentos
Profissional Documentos
Cultura Documentos
Ch. 1: Introduction:
1.1Project detail:
1.1.1Definition: The definition of the project is College Technical Event Scheduling and Organization. This application leads for the handling and formation of the event and its schedule. 1.1.2 Project Profile:
Name of Project:
College Technical Festival Event organization application. The Application generally relates to a system and method to schedule events, and more particularly, to a system and
Object Description:
Android Android version 4.2 SQLite Database Object Oriented Development Eclipse Indigo Android Virtual Device(AVD)
Time Duration:
1 year
1.2 Purpose:
The purpose of making this application is to provide a easiness of finding the event schedule at one place. The user will find the technical event schedule in one application rather to visit different web pages. The invention satisfies the foregoing needs and avoids the drawbacks and limitations and frustrations of the prior art, and provides a better, more timely and effective process of communication to schedule and coordinate events by utilizing Internet-based application. The people may get fail to answer the call or would be
abhaykorat89@gmail.com
KORAT ABHAY M. unable to check the email so this Application will lead a better communication of the people about the event.
1.3Project Scope:
The scope of the project includes creating a user interface to Android system as well as a backend that will emulate some of its behaviour, specifically for testing. Event management is the application of management to the creation and development of Technical festivals, events and conference. The Application generally relates to a system and method to schedule events, and more particularly, to a system and method for scheduling technical events among entities such as organization that may have limitations for scheduling, such as geographical requirements, constraints by timing, conflicts, availability, or other factors. This Application leads to provide the user especially the student the reliability in finding the schedule of events at one place rather to go for each of the college websites. The college will just have to post the event in .pdf file and that will be downloaded by students. By this Application the matter of time which go in informing each other for the event will also be solved out.
1.4Objectives:
The people sending mail or message of technical event to other is wasting of time and memory. To overcome this problem our invention provides a medium where one can get the schedule of an event by just opening our application with the internet connection and refreshing it.Another thing our Application provides is all in one characteristic. i.e. all technical event schedule in just one application.
abhaykorat89@gmail.com
KORAT ABHAY M. upcoming events in the database. The other person who will use this application will be student they will get the details of the upcoming technical events by just logging to the application and downloading the desired event details. Product Features Functionality The invention satisfies the foregoing needs and avoids the drawbacks and limitations and frustrations of the prior art, and provides a better, more timely and effective process of communication to schedule and coordinate events by utilizing Internet-based application. This product contains three major Users. First the admin will allow the user for accessing this application by giving the permission rights and access control. Second The college login will have a right to see the events listing and they can post their new schedule of a technical event as well. And third The End User i.e. Student, they can see the list of the events and schedule of event. User Classes and Characteristics Admin The Admin will have all the access to this product. The Admin will provide the access permission to the users which are students and Colleges. The admin can also delete or discard the unwanted events reported as spam. They also manage the database like deleting the past events.
College The college admin will be the second admin to this product, but with less access control. The college admin will be provided the access the database like to add event in .pdf format and to delete event. The college admin will be logged in using their id and password provided. Student The student are the end-user entity, they will be having the access rights to see the event schedule by pdf format. And register their new account providing their basic details. Other Non-Functional Requirements Performance Requirements
abhaykorat89@gmail.com
KORAT ABHAY M. Better performance will lead to better operating environment. For better environment the user needs a high speed internet so that the upload and download will be done better. Security Requirements The login details must be kept confidential so that other user may not login using other's id and password. Especially the college login details must be kept confidential so that other user may not post a fake event schedule.
2.2Feasibility Study
Feasibility Analysis: A feasibility study is a short focused, which aims to answer a number of questions: Does the system contribute to the overall objective of the organization? Can the system be implemented using the current technology and within given cost and schedule constraints? Can the system be integrated with system which is already in place? Economic Feasibility: The project is economically feasible as it only requires a mobile phone with Android operating system. The application is free to download once released for student and payable for college into Android market. The users should be able to connect to internet through mobile phone and this would be the only cost incurred on the project. Technical Feasibility: To develop this application, an internet connection, a database server, a web server and software are required. The current project is technically feasible as the application was successfully deployed on Android Emulator. Behavioral Feasibility: The application is behaviorally feasible since it requires no technical guidance, all the modules are user friendly and execute in a manner they were designed to.
abhaykorat89@gmail.com
KORAT ABHAY M. we thought we would use for refactoring. We alsopondered on a suitable name to give the project. The group was then divided that would work on parts of the code. We kept in touchwith each other and whenever we had difficulties, we asked each other questions. On someoccasions, we had to pretend we were the customer so as to try to figure out some of the things thatuser would desire, such as the friendliness of the user interface and ease of navigation through thesoftware.
Figure 1 GanttChart
Ch. 3: Analysis:
3.1 Technology And Analysis
The technology used here is ANDROID. Android is basically an operating system for smartphones. But we find now integrated into PDAs, touch pads or televisions, even cars (trip computer) or netbooks. The OS was created by the start-up of the same name, which is owned by Google since 2005. Now a days people using android as an operating system in their mobile phones have been increased. So people using android are, much more and they are familiar with it. Students increase their craze about android phones. The operating system is based on Linux. Android allows multitasking in the sense that multiple applications can run simultaneously. The database here used is SQLite. The lighter version of SQL. Software and Hardware Requirements Software Requirements: Android version 2.3 or above. Hardware Requirements: Minimum 128MB RAM
abhaykorat89@gmail.com
KORAT ABHAY M.
Hardware Constraints/Limitations Require Android supporting devices. Would work better in android 4.1 or above. Internet access needed.
Ch. 4: Design:
4.1E-R Diagram
Entity-Relationship diagram is a detail & logical representation of entities and data elements for an organization. This technique is used in database that helps in an enterprise are related to each other. There are 3 types of E-R diagram: 1. one to one : It is a one to one relationship is an association between 2 entities. 2. one to many: One-to-many relationship exists when one entity related to one or more entity. 3. Many to many: It describes entities that may have many relationships among each other.
The basic symbols for E-R diagram are as described below: This rectangle represents entity set. This arrow is known as flow line. It links attributes to entity set & entity set to relationship.
This diamond represents relationship among entity set. The association among several entities in E-R diagram is known as Relationship.
This oval represents various types of data items that describes an entity are known as its attributes.
abhaykorat89@gmail.com
KORAT ABHAY M.
Following are the Symbols used in DFD: Process: Here flow of data is transformed. E.g. Purchase of items, update inventory file, etc. External Entity: A source or destination of data which is external to the system. E.g. Customer, Supplier etc.
abhaykorat89@gmail.com
KORAT ABHAY M.
A data flow: It is packet of data. It may be in the form of document, letter etc.
Data store: Any store data but with no reference to the physical method of storing. Context Diagram:
College Information
(0.0) Student Registration Information College Technical Festival Event Organization Application Event Organize College Admin
Event Schedule
Give Fnctionality
Services
User Acess
Admin
abhaykorat89@gmail.com
KORAT ABHAY M.
Send Message Request Password Send Message Request Password
Fetch Password Person Database Request data Check Data Admin Access
Admin Database
College Information Get Data (1.0) Student Registration Information Registration Event Schedule Give Fnctionality Event Organize College
Login Information
Services
User Access
User information
Fetch data
(1.2) Login
College Information
College
abhaykorat89@gmail.com
KORAT ABHAY M.
(2.2) Update Details Update Person_data
Give Details
Event Title
view
Fetch
Accept Enter details (2.1) Give Login Details Request (2.4) College registration Insert
Registration
College
Figure 7 Level-2 DFD for Admin Level-2 DFD for Forget Password:
10
abhaykorat89@gmail.com
KORAT ABHAY M.
Receive
(3.1) Student/ College Provide Username Forget password Access Person_data Send password
(3.2) Message
SYSTEM BOUNDARY
Login * * *
* Payment *
* *
* * *
* * * Get Schedule * * *
* Delete User
* Register College
Figure 9 Use Case Diagram for System Use Case for Admin:
11
abhaykorat89@gmail.com
KORAT ABHAY M.
ADMIN BOUNDARY
Login *
Register College *
View Users
Login *
Update Details *
Payment
12
abhaykorat89@gmail.com
KORAT ABHAY M.
STUDENT BOUNDARY
Login *
Update Details *
Check Schedule * * * * **
Registration
4.4Activity Diagram
Student Registration:
Strat Application
/ NO
Incorrect
/ NO
VALID?
/ YES
Save Data
Registration Sucessful
13
abhaykorat89@gmail.com
Strat Application
Incorrect
/ NO
VALID?
/ YES
Payment
Enter Details
Login
Incorrect
/ NO
VALID?
/ YES
Check Schedule
KORAT ABHAY M.
Enter Details
Login
Incorrect
/ NO
VALID?
/ YES
Choose Option
See Events
Create Event
Enter Details
Post Event
15
abhaykorat89@gmail.com
Strat Applicatin
Re-enter
admin login
/ NO
valid / YES
/ NO
logout
16
abhaykorat89@gmail.com
KORAT ABHAY M.
4.5Class Diagram
17
abhaykorat89@gmail.com
KORAT ABHAY M.
4.6Sequence Diagram
Student Login Activity College Admin Activity Event Activity Payment Activity Admin Activity
Request For Registration Acknowlegement Payment ( ) Get Response Get Payment ( ) Response ( ) Verify Request ( )
Login
Do Login ( ) Generate Event ( ) Notification Event ( ) Event Schedule ( ) Get Schedule ( ) Update Schedule ( ) Get New Schedule ( )
18
abhaykorat89@gmail.com
KORAT ABHAY M.
2. College _login:
19
abhaykorat89@gmail.com
KORAT ABHAY M. Table 2College_login Field Name Username Password College_name College_no E-Mail ID Data Type Varchar Varchar Varchar Number Varchar Size 30 30 50 15 30 Null Not Null Not Null Not Null Not Null Not Null
3. Student_login:
Table 3Student_login Field Name Username Password First Name Last name Gender Contact No. Reg_Type E-Mail ID Data Type Varchar Varchar Varchar Varchar Boolean Number Varchar Varchar Size 30 30 30 30 2 12 10 30 Null Not Null Not Null Not Null Not Null Not Null Not Null Not Null Not Null
4. Event_pdf:
Table 4Event_pdf Field Name Event_id Event_name Pdf_no Pdf_size Pdf_date/time Data Type Number Varchar Number Number Date/time Size 30 30 30 30 8 Null Not Null Not Null Not Null Not Null Not null
5. Event_registerd_information:
Table 5Event_registerd_information Field Name Event_name Event_id Data Type Varchar Number Size 30 30 Null Not Null Not Null
20
abhaykorat89@gmail.com
KORAT ABHAY M. Event_date/time Student_name Student_id Student_add Student_contact E-Mail ID Date/time Varchar Number Varchar Number Varchar 30 30 15 50 15 30 Not Null Not Null Not Null Not Null Not Null Not Null
4.9User Interface
Loading Page: This page is shown at the starting of the application.
21
abhaykorat89@gmail.com
KORAT ABHAY M. Login Page: The below figure shows the login screen/activity of an application.
Figure 22 Login Page Student Registration Page: This below given figure shows the user interface of the registration activity of student.
22
abhaykorat89@gmail.com
KORAT ABHAY M. Student Registration Success: The given figure shows the activity strike to the student user when the login is successfully done.
23
abhaykorat89@gmail.com
KORAT ABHAY M. College Registration Success: The given figure shows the activity strike to the College user when the login is successfully done.
Figure 25 College Login Success Admin Login: The figure shows the activity when Admin is successfully login.
Figure 26 Admin Login Success List Of User(Admin Login): The figure given below shows the list of user in an activity. This can be seen by only admin of the application.
24
abhaykorat89@gmail.com
KORAT ABHAY M.
Figure 27 List Of User(Admin Login) College Registration Activity: The given figure shows the activity of college registration. This can be done by admin only.
Figure 28 College Registration Forget Password: Thebelow figure shows the activity for forget password when the user forget the password they will get it by entering the username.
25
abhaykorat89@gmail.com
KORAT ABHAY M.
Figure 29 Forget Password Activity Receive Password: The password is received by the user to their registered mobile number.
26
abhaykorat89@gmail.com
KORAT ABHAY M.
Ch.5: Testing:
5.1 Testing Plan
5.1.1 The Testing Process: We have tested the software process activities such as design, implementation and requirement engineering because design errors are very costly to repair once system has been started to operate. Therefore, it is quite obvious to repair them at early stage of the system. So analysis is the most important process of any project. 5.1.2 Requirement Traceability: As the most interested portion is whether the system is meeting its requirements or not, for that testing should be planned so that all requirements are individually tested. We have to check out that output of certain combinations of inputs gives the desirable results or not. Your requirement specification gives us the path to get the desirable result. 5.1.3 Tested Modules: Administrator Users Visitors
5.1.4 Testing Schedule: We have tested each procedure back to back so that errors and omissions can be found as early as possible. Once the system has been developed fully we tested it on another machines, which differs in combinations.
27
abhaykorat89@gmail.com
KORAT ABHAY M. Testing begins at the component level and works outward towards the integration of the entire computer based system. Different testing techniques are appropriate at different points in time. Testing & Debugging are different activities but debugging must be accommodated in any testing strategy. We checked entire project thoroughly so not even a single mistake would be there.
28
abhaykorat89@gmail.com
KORAT ABHAY M. and the second is cyclometer complexity. In flow graph notation we are checking logical control of flow. By using cyclometer complexity we find complexity of our project structure. 5.3.2 Black-Box Testing: Black-box testing focuses on the functional requirements of the software. That is blackbox testing enables the software engineer to drive sets of input conditions that will fully exercise all functional Requirements for the program. Black-box testing is not an alternative to white-box testing techniques. Rather, it is a complementary approach that is likely to uncover a different class of errors than white-box methods. We use in our coding to find errors in the following categories: Incorrect or missing functions Interface errors Errors in database Performance errors Initialization and termination errors.
Unlike white-box testing, which is performed earlier in the testing process, black-box testing tends to be applied during later stages of testing. Because black-box testing purposely disregards control structure, attention is focused on the information domain. By applying black-box techniques, we derive a set of test cases that satisfy following criteria test cases that reduce, by a count that is greater than one, the number of additional test cases must be designed to achieve reasonable testing. Level 1 - Build Acceptance Tests Other related test cases ensure that adopters received the proper Development Release Document plus other build related information (drop point, etc.). The objective is to determine if further testing is possible. If any Level 1 test case fails, the build is returned to developers un-tested.
Level 2 - Smoke Tests The objective is to determine if further testing is possible. These test cases should emphasize breadth more than depth. All components should be touched, and every major feature should be tested briefly by the Smoke Test. If any Level 2 test case fails, the build is returned to developers un-tested.
29
abhaykorat89@gmail.com
KORAT ABHAY M. Level 2a - Bug Regression Testing Every bug that was Open during the previous build, but marked as Fixed, Needs Re-Testing for the current build under test, will need to be regressed, or retested. Once the smoke test is completed, all resolved bugs need to be regressed. It should take between 5 minutes to 1 hour to regress most bugs. Level 3 - Critical Path Tests Critical Path test cases must pass by the end of every 2-3 Build Test Cycles. They do not need to be tested every drop, but must be tested at least once per milestone. Thus, the Critical Path test cases must all be executed at least once during the Iteration cycle, and once during the Final Release cycle. Level 4 - Standard Tests Test Cases that need to be run at least once during the entire test cycle for this release. These cases are run once, not repeated as are the test cases in previous levels. Functional Testing and Detailed Design Testing (Functional Spec and Design Spec Test Cases, respectively). These can be tested multiple times for each Milestone Test Cycle (Iteration, Final Release, etc.).Standard test cases usually include Installation, Data, GUI, and other test areas. Level 5 - Suggested Test These are Test Cases that would be nice to execute, but may be omitted due to time constraints Bug Regression: Bug Regression will be a central tenant throughout all testing phases. When a Severity 1 bug fails regression, adopters testing team should also put out an immediate email to development. The Test Lead will be responsible for tracking and reporting to development and product management the status of regression testing.
5.4Test Cases
Table 6 Testing New Student Entries Sr. No 1 New Student Entry Test Case Validation or Test Data Requirement User ID auto generation Adding a new User Expected Result New entry should be done successfully Actual Result Modification done
Successful No modification
30
abhaykorat89@gmail.com
KORAT ABHAY M. 2 New Student Entry 3 New Student Entry as admin or existing username Table 7Testing For Forget Password Sr.No Test Case Validation or Requirement 1 Provide username correctly Username Send Successfully successful No Modification Done. Test Data Expected Result Actual Result Modification done All Data Inserted All Details Shows Error Showing error No Modification All Data must be required All details Successful entry Successful No Modification
Table 8Testing Login for Administrator/Student/College Sr. Test Case No 1 Right Login Validation or Test Requirement Data Expected Result Login Done Successfully Actual Result Successful Modification done No modification
Wrong Login
Login Wont be
Unsuccessful No modification
Table 9Testing New College Entries Sr. Test Case Validation Test Data Expected Actual Modification
31
abhaykorat89@gmail.com
KORAT ABHAY M. No or Requirement 1 New College Entry User ID auto generation Adding a new User New entry should be done successfully 2 New College Entry 3 New College Entry as admin or existing username All Data Inserted All Details Shows Error Showing error No Modification All Data must All details be required Successful entry Successful No Modification Successful No modification Result Result done
Future Enhancement:
Registration Services: The future needs of providing registration for the specific event will be provided. This provides students not to interact with the college for registration, but they can directly register their names in any event. Email Services: When the user is registered they will get the confirmation mail to their registered mail. This service will make sure to the Student that they are successfully registered to the event.
32
abhaykorat89@gmail.com