1.

INTRODUCTION:
Mobile based COLLEGE PORTAL is application which reduces the manual effort by introducing online ser ice! "t is a mobile application that pro ides the information about our college to students#anonymous users! "n some situations students might be out of stations or they may be non$local students if they don%t &now anything about what is new in college or what is happening in the college in that case if he#she can generally browse the net and search for our college website or may directly go to that college and consult the administration 'so it is such a big process! "t is such a waste of time' so we are introducing new online application! This application allows the (tudents to browse the college website through mobile! (tudents need to register in application along with their details li&e student$id' student name' d!o!b' gender' personal contact' and current address email$address! After registration she#he can chec& for desired details about attendance' results' and e ents!

1.1MOTIVATION:
"n present scenario' we can &now the information regarding students' attendance' e)am results' and e ents going on in the college either through notice board or by consulting the administration! so to reduce the student effort! we are introducing this application mobile based college portal management system!

1.2PROBLEM DEFINITION:
"n order to o ercome the present problem this application *college portal* is useful in &nowing information li&e attendance' e)am results' and e ents from anywhere without wasting user time and without much effort!

1.3OBJECTIVE OF PROJECT:
The main ob+ecti e of the pro+ect is that introducing mobile ser ices to the college portal management system and reducing the time of the students! This application which reduces the manual effort by introducing online ser ice! "t is a mobile application that pro ides the information about the student%s attendance' results and e ents! The purpose of this (oftware Re,uirement (pecification -(R(. is to help the pro+ect!

"t is pro ided with some re,uirements which are used in mobile based COLLEGE PORTAL ! All parts/ design' coding andtesting will be prepared with helping of (R(! The purpose of this document is tode elopers as to what is to be e)pected and how the componentsof the system are to wor& with each other with e)ternal systems!This document will be chec&ed by group member%s super isor and it willcorrected by members if super isor orders!

1.4LIMITATIONS OF PROJECT:

"t is time consuming! The information that is gi en to the user is done manually.

1.5ORGANISATION OF DOCUMENTATION
The organi0ation of document pro ides the basic report of the stages encountered in the pro+ect de elopment' in the form of chapters1111! Chapter23 The Chapter2 pro ides the "ntroduction of the pro+ect! Chapter43 The Chapter4 deals with the literature sur ey'which pro ides the information regarding the need of de eloping the pro+ect ! Chapter53 The Chapter5 specifies about the software re,uirements' which help in building the pro+ect for de eloping the code' and a database to store the information! Chapter63 The Chapter6 specifies feasibility report and design phase of pro+ect! Chapter73 The Chapter7 shows the detail "mplementation of module description! Chapter83 The Chapter8 specifies the Testing' in which Testing refers to the testing methodologies! Chapter93 The Chapter9 Result' which specifies the output of the code generated! Chapter:3 The Chapter: is the Conclusion and ;uture (cope part!
2

Chapter<3 This chapter< specifies =ibliography which consists of additional reference sites and boo&s! Chapter2>3 This chapter2> Appendi) is to specify the additional information regard the code and some e)pansions and etc!

2. LITERATURE SURVEY
2.1. INTRODUCTION: After analy0ing the re,uirements of the tas& to be performed' the ne)t step is to analy0e the problem and understand its conte)t! The first acti ity in the phase is studying the e)isting system and other is to understand the re,uirements and domain of the new system! =oth the acti ities are e,ually important' but the first acti ity ser es as a basis of gi ing the functional specifications and then successful design of the proposed system! ?nderstanding the properties and re,uirements of a new system is more difficult and re,uires creati e thin&ing and understanding of e)isting running system is also difficult' improper understanding of present system can lead di ersion from solution!

2.2 EXISTING SYSTEM:

"n the e)isting system if we want to &now about any details of our college we ha e go through the web$site of our college -or. we ha e to directly go to the college and en,uiry.

2.3LIMITATIONS IN THE EXISTING SYSTEM:

"n this e)isting system we ha e to &now about the web$site of our college! @e ha e to en,uiry all the particular detail so it is time ta&ing process! The information that is to be gi en is done manually

2.4 PROPOSED SYSTEM:

"n this proposal system we are pro iding the mobile application to the college system! "n this mobile application we can search about our desired module li&e attendance'e ents'results from e erywhere and at anytime!

2.5 CONCLUSION:
=y this mobile based application Acollege portalB'a user can get desired information about his#her attendance 'results and e ents that are to be held in our college!

3. ANALYSIS
3.1 INTRODUCTION:
The model that is basically being followed is the (P"RAL MOCEL' which states that the phases are organi0ed in a linear order! ;irst of all the feasibility study is done! Once that part is o er the re,uirement analysis and pro+ect planning begins! "f system e)ists any modification and addition of new module is needed' analysis of present system can be used as basic model! The design starts after the re,uirement analysis is complete and the coding begins after the design is complete! Once the programming is completed' the testing is done! "n this model the se,uence of acti ities performed in a software de elopment pro+ect are3 $ Re,uirement Analysis Pro+ect Planning (ystem design Cetail design Coding ?nit testing (ystem integration D testing Eere the linear ordering of these acti ities is critical! End of the phase and the output of one phase is the input of other phase! The output of each phase is to be consistent with the o erall re,uirement of the system! (P"RAL MOCEL was defined by =arry =oehm in his 2<:: article' AA spiral Model of (oftware Ce elopment and Enhancement! This model was not the first model to discuss iterati e de elopment' but it was the first model to e)plain why the iteration models! As originally en isioned' the iterations were typically 8 months to 4 years long! Each phase starts with a design goal and ends with a client re iewing the progress thus far! Analysis and engineering efforts are applied at each phase of the pro+ect' with an eye toward the end goal of the pro+ect!

The following diagram shows how a spiral model acts li&e:

;ig 5!2 3 (piral Model

3.2 SOFTWARE RE UIREMENT SPECIFICATIONS

This document is the complete product re,uirement specification for the Mobile based college portal ! This is the only document that contains all information regarding the re,uirements placed on the mobile based college portal by the administrator' catalogued in an unambiguous fashion! ?nless otherwise stated' this document' and any future re isions of this document'supersedes all other re,uirements documents that e)ist for the mobile based college portal!

3.2.1 USER RE UIREMENTS:

Few users gi e his complete personnal' address and phone details for registration! student can search for attendance

student can search for results!

6

 student can search for e ents!

3.2.2 SOFTWARE RE UIREMENTS

GCH 2!8 Apache tomcat ser er Oracle 2>g Android (CH Eclipse "CE

3.2.3 H!"#$!"% R%&'("%)%*+,:

Android mobile de ice! 4G= RAM! ECC 6> G= Eard Cis& (pace! "ntel Pentium 6

3.3 CONTENT DIAGRAM OF PROJECT:

3.4 CONCLUSION
The Analysis and (oftware Re,uirement (pecification -(R(. is to help the pro+ect! "t is pro ided with some re,uirements which are used in mobile based college portal management system! All parts/ design' coding and testing will be prepared with helping of (R(! The purpose of this document is to detail the re,uirements placed on the mobile based college portal management system and ser es as a contract between the students and the college as to what is to be e)pected of the mobile based college portal management system' and how the components of the system are to wor& with each other with e)ternal systems! This document will be chec&ed by group member%s super isor and it will corrected by members if super isor orders!

4. DESIGN
4.1 INTRODUCTION3
(oftware design sits at the technical &ernel of the software engineering process and is applied regardless of the de elopment paradigm and area of application! Cesign is the first step in the de elopment phase for any engineered product or system! The designer%s goal is to produce a model or representation of an entity that will later be built! =eginning' once system re,uirement ha e been specified and analy0ed' system design is the first of the three technical acti ities $design' code and test that is re,uired to build and erify software! The importance can be stated with a single word AIualityB! Cesign is the place where ,uality is fostered in software de elopment! Cesign pro ides us with representations of software that can assess for ,uality! Cesign is the only way that we can accurately translate a customer%s iew into a finished software product or system! (oftware design ser es as a foundation for all the software engineering steps that follow! @ithout a strong design we ris& building an unstable system J one that will be difficult to test' one whose ,uality cannot be assessed until the last stage.

4.2 ER-UML DIAGRAMS

ER.DIAGRAMS: The relation upon the system is structure through a conceptual ER$Ciagram' which not only specifics the e)istential entities but also the standard relations through which the system e)ists and the cardinalities that are necessary for the system state to continue! The Entity Relationship Ciagram -ERC. depicts the relationship between the dataob+ects! The ERC is the notation that is used to conduct the date modeling acti itythe attributes of each data ob+ect noted is the ERC can be described resign a dataob+ect descriptions! The set of primary components that are identified by the ERC are Cata ob+ect Relationships

KAttributes Larious types of indicators!

The primary purpose of the ERC is to represent data ob+ects and their relationships! E$R -Entity$Relationship. Ciagram is used to represents the relationship between entities in the table!
T/% ,0)123, ',%# (* E.R #(!4"!), !"%:

SYMBOL
"%,%*+,E*+(+0,%+, R%5"%,%*+,E*+(+0,%+, .

PURPOSE
R%5

R%5"%,%*+ !++"(1'+%,.

R%5"%,%*+ R%3!+(2*,/(5 S%+,.

L(*% "%5"%,%*+,632$

10

;"G!6!4!2 ER$C"AGRAM ;OR COLLEGE PORTAL MAFAGEMEFT (M(TEM

11

4.2.2 UML DIAGRAMS: A.USE CASE DIAGRAMS:

?se cases are used during re,uirements elicitation and analysis to represent the functionality of the system! ?se cases focus on the beha ior of the system from the e)ternal point of iew! The actor is outside the boundary of the system' where as the use cases are inside the boundary of the system!

home page

student

check attendance

check events

check results

F(4 4.2.27A8 ',%9!,% #(!4"!) 62" ',%"

12

B.CLASS DIAGRAMS:
Class diagrams to describe the structure of the system! Classes are abstraction that specifies the common structure and beha ior of a set of ob+ects! Class diagrams describe the system in terms of ob+ects' classes' attributes' operations and their association
student details
student name student-id branch year sem get student name() get student -id() get branch() get year-id() get sem-id()

results
exam type exam category subject results get exam details() check results()

attendance
date picker attendance status get attendance details() check status()

events
event type evevnt name venue time date get evevnt details() check events list()

;ig 6!4!4-=. class diagram for college portal management system

13

C.SE UENCE DIAGRAMS:

SE UENCE DIAGRAM: (e,uence diagram depicts the interactions between class instances' in the form of method calls and call returns shows a specific scenario of e)ecution in the system in terms of ob+ect instances! This diagram focuses on the time ordered messages between ob+ects that collaborate to accomplish some tas&!

: student

: home page1

: student details

: attendance

: results

: events

1.enter home page()

2.enter student details() 3.select attendance() .get attendance status() !.select results() #.check results()

".select events()

$.get events details()

F(4 4.2.27C8,%&'%*9% #(!4"!) 62" 9233%4% 52"+!3 )!*!4%)%*+ ,0,+%)

14

D.COLLABARATION DIAGRAMS:
A collaboration diagram' also called a communication diagram or interaction diagram' is an illustration of the relationships and interactions among software ob+ects in the ?nified Modeling Language -?ML.! The concept is more than a decade old although it has been refined as modeling paradigms ha e e ol ed!

2: 2.enter student details()

: student details

: attendance

: .get attendance status() : student 1: 1.enter home page() 3: 3.select attendance() $: $.get events details() #: #.check results()

: events

: results
": ".select events() !: !.select results()

: home page1

F(4 4.2.27D89233!12"!+(2* #(!4"!) 62" +/% ,0,+%)

15

4.2.5. ACTVITY DIAGRAMS:

A (tate diagram#Acti ity diagram is a specification of the se,uences of states that an ob+ect or an interaction goes through in response to e ents during its life' together with its responsi e action! E ery state diagram is ha ing one entry and e)it state! And the state can ha e any number of sub$states! The abo e state diagram represents' how admin will interact with other ob+ects' and how he will perform actions and change his state!

16

4.3 MODULE DESIGN AND ORGANISATION:

T!1 4.37!8 S+'#%*+ #%+!(3, +!13%

17

T!1 4.3718 0%!" +!13%

18

T!1 4.3798 Y%!" !*# S%) (# +!13%

19

T!1 4.37#8 S%) +!13%

20

T!1 4.37%8 B"!*9/ +!13%

21

4.3.1A++%*#!*9% )2#'3%: This is the first module in this college portal management system !"n this module user can chec& the attendance status by entering the student details and there by pic&ing a date he#she is iewed whether they are present#absent on the particular date! T!1 4.3.17!8 !++%*#!*9% +!13%

22

23

4.3.2. R%,'3+ )2#'3% This is the second module of the college portal management system!"n this results module user can &now about results according to their hall tic&et number'year'branch and semester!user can also choose e)amination type and e)amination category!After entering student details and choosing e)amination type D category student can get mar&s according to his#her selected sub+ect! Tab 6!5!4 Results table Tab 6!5!4-a. E)am category table

24

T!1 4.3.2 718E:!) +05% +!13%

25

T!1 4.3.2798 S'1;%9+ +!13%

26

T!1 4.3.27#8 R%,'3+.(# +!13%

27

T!1 4.3.27%8M!"<, +!13%

28

4.3.3 E=%*+, )2#'3%: This is the third and final module in college portal management system!E ent management module gi es information about the e ents that are going to be held in the college!it also gi es the information about the e ent enue'timings'e ent date and what type of e ents are going to be heldNwhether they are technical or cultural'by whom the e ents are going to be conducted N!All these information can be &nown in this module!

T!1.4.3.3.R%,'3+, +!13%

29

T!1 4.3.37!8 E=%*+ #%+!(3, +!13%

30

5. IMPLEMENTATION > RESULTS

5.1 EXPLANATION OF ?EY FUNCTIONS: 5.1.1 OUTPUT SCREENS:
This chapter describes about the output screens! ;ollowing are the output screens of our pro+ect! 2! Eome page 4! (tudent details 5! Attendance information 6! Results information 7! E ents information 1. HOME PAGE:

(cr3 7!2!2-A. screen shot for home page NAVIGATION: Go to $ Oeclipse$Oselect pro+ect file$Orun$Oclic& on college portal
app!

31

2. STUDENT DETAILS:

(cr3 7!2!2-=. screen shot for student details NAVIGATION: Go to $ Oeclipse$Oselect pro+ect file$Orun$Oclic& on go to college
portal button$O enter student details!

32

3. ATTENDANCE INFORMATION:

(cr3 7!2!2-C. screen shot for attendance information NAVIGATION: Go to $ Oeclipse$Oselect pro+ect file$Orun$Oclic& on college
portal$Oselect attendance module$Opic& a date$Ochec& attendance!

33

4.RESULTS INFORMATION:

34

(cr 7!2!2-C. screen shot for results information NAVIGATION: Go to $ Oeclipse$Oselect pro+ect file$Orun$Oclic& on college portal
button$Oenter student details$Oselect results$Ochoose e)am D category type$ Ochec&#get results!

35

5. EVENTS INFORMATION:

36

37

(cr3 7!2!2-E. screen shot for e ents information NAVIGATION: Go to $ Oeclipse$Oselect pro+ect file$Orun$Oclic& on college portal
button$Oenter student details$Oselect e ents$Ochoose e ent type$Ochec& e ents information!

38

5.2 RESULT ANALYSIS: FEASIBILITY REPORT

Preliminary in estigation e)amine pro+ect feasibility' the li&elihood the system will be useful to the organi0ation! The main ob+ecti e of the feasibility study is to test the Technical' Operational and Economical feasibility for adding new modules and debugging old running system! All system is feasible if they are unlimited resources and infinite time! There are aspects in the feasibility study portion of the preliminary in estigation3 Technical ;easibility Operation ;easibility Economical ;easibility

TECHNICAL FEASIBILITY:
The technical issue usually raised during the feasibility stage of the in estigation includes the following3 KCoes the necessary technology e)ist to do what is suggestedN Co the proposed e,uipments ha e the technical capacity to hold the data re,uired to use the new systemN @ill the proposed system pro ide ade,uate response to in,uiries' regardless of the number or location of usersN Can the system be upgraded if de elopedN Are there technical guarantees of accuracy' reliability' ease of access and data securityN

OPERATIONAL FEASIBILITY:
Proposed pro+ects are beneficial only if they can be turned out into information system! That will meet the organi0ation%s operating re,uirements! Operational feasibility aspects of the pro+ect are to be ta&en as an important part of the pro+ect implementation! (ome of the important issues raised are to test the operational feasibility of a pro+ect includes the following3 "s there sufficient support for the management from the usersN

39

@ill the system be used and wor& properly if it is being de eloped and implementedN @ill there be any resistance from the user that will undermine the possible application benefitsN

This system is targeted to be in accordance with the abo e$mentioned issues! =eforehand' the management issues and user re,uirements ha e been ta&en into consideration! (o there is no ,uestion of resistance from the users that can undermine the possible application benefits! The well$planned design would ensure the optimal utili0ation of the computer resources and would help in the impro ement of performance status!

ECONOMIC FEASIBILITY:
A system can be de eloped technically and that will be used if installed must still be a good in estment for the organi0ation! "n the economical feasibility' the de elopment cost in creating the system is e aluated against the ultimate benefit deri ed from the new systems! ;inancial benefits must e,ual or e)ceed the costs! The system is economically feasible! "t does not re,uire any addition hardware or software! (ince the interface for this system is de eloped using the e)isting resources and technologies a ailable at A=C Tech' There is nominal e)penditure and economical feasibility for certain!

5.3 METHOD OF IMPLEMENTATION:

HOME ACTIVITY: import android!app!Acti ity/ import android!content!"ntent/ import android!os!=undle/ import android!pro ider!Contacts!"ntents/ import android! iew!Liew/ import android! iew!Liew!OnClic&Listener/ import android!widget!=utton/ public class Eomeacti ity e)tends Acti ityP =utton atd'res'e t/ QO erride protected oid onCreate-=undle sa ed"nstance(tate. P 40

## TOCO Auto$generated method stub super!onCreate-sa ed"nstance(tate./ setContentLiew-R!layout!home./ atdR-=utton.findLiew=y"d-R!id!atdet./ resR-=utton.findLiew=y"d-R!id!reset./ e tR-=utton.findLiew=y"d-R!id!e eet./ atd!setOnClic&Listener-new OnClic&Listener-. P QO erride public oid onClic&-Liew . P ## TOCO Auto$generated method stub "ntent iRnew "ntent-Eomeacti ity!this'AtdsActi ity!class./ startActi ity-i./ S S./ res!setOnClic&Listener-new OnClic&Listener-. P QO erride public oid onClic&-Liew . P ## TOCO Auto$generated method stub "ntent i2Rnew "ntent-Eomeacti ity!this'ResultActi ity!class./ startActi ity-i2./ S S./ e t!setOnClic&Listener-new OnClic&Listener-. P QO erride public oid onClic&-Liew . P ## TOCO Auto$generated method stub "ntent i4Rnew "ntent-Eomeacti ity!this'e entlist!class./ startActi ity-i4./ S S./ S S

41

EVENTS ACTIVITY: pac&age com! iew/ import +a a!util!ArrayList/ import org!+son!G(OFArray/ import org!+son!G(OFE)ception/ import android!app!Acti ity/ import android!os!=undle/ import android! iew!Liew/ import android!widget!AdapterLiew/ import android!widget!ArrayAdapter/ import android!widget!EditTe)t/ import android!widget!(pinner/ import android!widget!AdapterLiew!On"tem(electedListener/ public class E entsActi ity e)tends Acti ityP pri ate EditTe)t e entname/ pri ate EditTe)t enet/ pri ate EditTe)t time/ pri ate EditTe)t dateet/ pri ate EditTe)t desp/ (tring re,uest'response/ QO erride protected oid onCreate-=undle sa ed"nstance(tate. P ## TOCO Auto$generated method stub super!onCreate-sa ed"nstance(tate./ setContentLiew-R!layout!e ents./ e entnameR-EditTe)t.findLiew=y"d-R!id!e entnameet./ enetR-EditTe)t.findLiew=y"d-R!id! enet./ timeR-EditTe)t.findLiew=y"d-R!id!timet./ dateetR-EditTe)t.findLiew=y"d-R!id!dateet./ despR-EditTe)t.findLiew=y"d-R!id!despet./ e entdesc-./ S oid e entdesc-.P ArrayListT(tringO nameRnew ArrayListT(tringO-./ ArrayListT(tringO descRnew ArrayListT(tringO-./ 42

ArrayListT(tringO enuRnew ArrayListT(tringO-./ ArrayListT(tringO dateRnew ArrayListT(tringO-./ ArrayListT(tringO actionRe entDidR*Ue entlist!selectedtypeid/ (ystem!out!println-re,uest./ responseRConnection?tility!send-re,uest./ (ystem!out!println-response./ G(OFArray array/ try P array R new G(OFArray-response./ for -int i R >/ i T array!length-./ iUU. P name!add-array!getG(OFOb+ect-i.!get(tring-*name*../ desc!add-array!getG(OFOb+ect-i.!get(tring-*desc*../ enu!add-array!getG(OFOb+ect-i.!get(tring-* enue*../ date!add-array!getG(OFOb+ect-i.!get(tring-*date*../ timings!add-array!getG(OFOb+ect-i.!get(tring-*timings*../ S e entname!setTe)t-name!get->../ enet!setTe)t- enu!get->../ time!setTe)t-timings!get->../ desp!setTe)t-desc!get->../ dateet!setTe)t-date!get->../ S catch -G(OFE)ception e. P ## TOCO Auto$generated catch bloc& e!print(tac&Trace-./ S S S timingsRnew ArrayListT(tringO-./ re,uestRConnection?tility!urlU*Registration(er letN

43

ATTENDANCE ACTIVITY: pac&age com! iew/ import +a a!util!ArrayList/ import +a a!util!Calendar/ import org!+son!G(OFArray/ import org!+son!G(OFE)ception/ import android!app!Acti ity/ import android!app!CatePic&erCialog/ import android!app!Cialog/ import android!os!=undle/ import android! iew!Liew/ import android! iew!Liew!OnClic&Listener/ import android!widget!=utton/ import android!widget!CatePic&er/ import android!widget!EditTe)t/ import android!widget!Te)tLiew/ public class AtdsActi ity e)tends Acti ityP =utton pic&date'ATFCATE/ EditTe)t attendancestatus/ Te)tLiew selcteddate/ static final int CATEVC"ALOGV"CR>/ pri ate int mMear'mMonth'mCay/ (tring re,uest'responseRnull/ QO erride protected oid onCreate-=undle sa ed"nstance(tate. P ## TOCO Auto$generated method stub super!onCreate-sa ed"nstance(tate./ setContentLiew-R!layout!attendance./ ATFCATER-=utton. findLiew=y"d-R!id!ATCbutton2./ pic&dateR-=utton.findLiew=y"d-R!id!attendancedate./ attendancestatusR-EditTe)t.findLiew=y"d-R!id!attendancestatuset./ selcteddateR-Te)tLiew. findLiew=y"d-R!id!attndancete)tLiew2./ getdate-./ (ystem!out!println-*selected date is*Uselcteddate!getTe)t-../ ATFCATE!setOnClic&Listener-new OnClic&Listener-. P 44

QO erride public oid onClic&-Liew . P ## TOCO Auto$generated method stub getatndance-./ S S./ S oid getdate-.P final Calendar calRCalendar!get"nstance-./ mMearRcal!get-Calendar!MEAR./ mMonthRcal!get-Calendar!MOFTE./ mCayRcal!get-Calendar!CATE./ updateCisplay-./ pic&date!setOnClic&Listener-new OnClic&Listener-. P public oid onClic&-Liew . P ## TOCO Auto$generated method stub showCialog-CATEVC"ALOGV"C./ S S./ S public oid updateCisplay-. P selcteddate!setTe)t-new (tring=uilder-.!append-mMonthU2.!append-*$*.!append-mCay.!append-*$*.!append-mMear../ S QO erride protected Cialog onCreateCialog-int id. P ## TOCO Auto$generated method stub Cialog C R null/ switch -id. P case CATEVC"ALOGV"C3 CR new CatePic&erCialog-AtdsActi ity!this' mCata(etListener' mMear' mMonth' mCay./ S return C/ S

45

pri ate QO erride

CatePic&erCialog!OnCate(etListener

mCata(etListenerRnew

CatePic&erCialog!OnCate(etListener-. P public oid onCate(et-CatePic&er iew' int year' int monthOfMear' int dayOfMonth. P ## TOCO Auto$generated method stub final Calendar cRCalendar!get"nstance-./ mMearRyear/ mMonthRmonthOfMear/ mCayRdayOfMonth/ updateCisplay-./ S S/ oid getatndance-.P (tring stuidRCetailsActi ity!getstudentid/ (tring selcteddateforatndanceR-(tring. selcteddate!getTe)t-./ re,uestRConnection?tility!urlU*Attendance(er letN actionRattendanceDstudentVidR*UstuidU*DdateR*Uselcteddateforatndance/ (ystem!out!println-re,uest./ responseRConnection?tility!send-re,uest./ (ystem!out!println-response./ try P G(OFArray arrayRnew G(OFArray-response./ ArrayListT(tringO statusRnew ArrayListT(tringO-./ for -int i R >/ i T array!length-./ iUU. P status!add-array!getG(OFOb+ect-i.!get(tring-*status*../ S if-status!si0e-.RR>.P attendancestatus!setTe)t-*not a ialble*./ Selse P attendancestatus!setTe)t-status!get->../ S S catch -G(OFE)ception e. P ## TOCO Auto$generated catch bloc& e!print(tac&Trace-./ S S 46

@. TESTING > VALIDATION

@.1. INTRODUCTION:
(oftware testing is a critical element of software ,uality assurance and represents the ultimate re iew of specification' design and coding! "n fact' testing is the one step in the software engineering process that could be iewed as destructi e rather than constructi e! A strategy for software testing integrates software test case design methods into a well$planned series of steps that result in the successful construction of software! Testing is the set of acti ities that can be planned in ad ance and conducted systematically! The underlying moti ation of program testing is to affirm software ,uality with methods that can economically and effecti ely apply to both strategic to both large and small$scale systems!

STRATEGIC APPROACH TO SOFTWARE TESTING:

The software engineering process can be iewed as a spiral! "nitially system engineering defines the role of software and leads to software re,uirement analysis where the information domain' functions' beha ior' performance' constraints and alidation criteria for software are established! Mo ing inward along the spiral' we come to design and finally to coding! To de elop computer software we spiral in along streamlines that decrease the le el of abstraction on each turn! A strategy for software testing may also be iewed in the conte)t of the spiral! ?nit testing begins at the erte) of the spiral and concentrates on each unit of the software as implemented in source code! Testing progress is done by mo ing outward along the spiral to integration testing' where the focus is on the design and the construction of the software architecture! Tal&ing another turn on outward on the spiral we encounter alidation testing where re,uirements established as part of alidated against the software that has been software re,uirements analysis are elements are tested as a whole!

constructed! ;inally we arri e at system testing' where the software and other system

47

TESTING OBJECTIVES:
Testing is a process of e)ecuting a program with the intent of finding an error! A good case is one that has a high probability of finding an error! A successful test is one that unco ers a yet undisco ered error! "f testing is conducted successfully it will unco er errors in the software! Testing cannot show the absence of defects' it can only show the software defects are present!

48

TESTING TYPES
A product can be tested in one of two ways!

1. B3!9< B2: T%,+(*4

The concept of the blac& bo) is used to represent a system whose inside wor&ings or no a ailable for inspection! "n a blac& bo)' the test item is treated as a Ablac&B since its logic is un&nown3 all that is &nown is what goes in and what comes out' or the input and output! Eere' in this AElectronic Management "nformation (ystemB the internal functionalities ha e been tested!

2. W/(+% B2: T%,+(*4

The main use of the white bo) testing is in error based testing! "t is predict on close e)amination of procedural detail logical pro iding test cases that e)ercise specific sets of conditions and#or loops test path enough the software! =asis path testing is a white bo) testing techni,ue! The basis path method enables the test case designer to deri e a logical comple)ity of a procedural design and use this measure as a guide for defining as basis set of e)ecution path!

TESTING STRATEGIES
A strategy for software testing integrates software test case design methods into a well$planned series of steps that result in the successful construction of software! Testing is the set of acti ities that can be planned in ad ance and conducted systematically! The underlying moti ation of program testing is to affirm software ,uality with methods that can economically and effecti ely apply to both strategic to both large and small$scale systems!

1. U*(+ T%,+(*4
?nit testing focuses on erifying the effort on the smallest unit of software module! The local data structure is e)amined to ensure that the date stored temporarily maintains its integrity during all steps in the algorithm%s e)ecution! =oundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing!

49

2. I*+%4"!+(2* T%,+(*4
Cata can be tested across an interface! One module can ha e an inad ertent' ad erse effect on the other! "ntegration testing is a systematic techni,ue for constructing a program structure while conducting tests to unco er errors associated with interring!

3. P%"62")!*9% T%,+(*4
Performance Testing is used to test runtime performance of software within the conte)t of an integrated system! Performance test are often coupled with stress testing and re,uire both software instrumentation! @.2. DESIGN OF TEST CASES AND SCENARIOS

50

@.2.1 T%,+ C!,% R%52"+1:

Test case 1: entry of student details Test Objective: as the student enters the details and clicks on the submit button it redirects to another page Test Description: he student click on the submit button the total details are stored in database Requirements Verified: !es Test Environment: : "pache omcat #er$er %racle 10g &cllipse '(& "ndroid #() *() 1+6 Test Setup/Pre- onditions: 1! "! #ctions he student clicks on submit button if they are $alid then it redirects to another page Pass: !es onditions pass: -o Prob%ems / 'ssues: -'. (otes: entry of student details is successesful he ,eb ser$er should be in %- state he system should ha$e a connection ,ith the database+ E$pected Resu%ts it gi$es entry of user details successful+ &ai%: -o

@.2.2 T%,+ C!,% "%52"+ 2:

51

Test case ": selection of the module Test Objective: after the entry of student details the student selects the module+ Test Description: : after the entry of student details if they are $alid it redirects to ne/t page+"fter the redirection student should select any one of the module from three modules Requirements Verified: !es Test Environment: : "pache omcat #er$er %racle 10g &clipse '(& "ndroid #() *() 1+6 Test Setup/Pre- onditions: 1! "! #ctions he student he ,eb ser$er should be in %- state he system should ha$e a connection ,ith the database+ E$pected Resu%ts selects any module from 1edirection to modules page is succesfull &ai%: -o

attendance0results0e$ents Pass: !es onditions pass: -o Prob%ems / 'ssues: -'. (otes: redirection to ne$t pa)e is succesfu%%

@.2.3T%,+ C!,% "%52"+3:

52

Test case *: attendance Test Objective: student clicks on attendance and checks the status Test case +: resu%ts Test Objective: he o check ,hether the results are displayed ordate not+ then student is $ie,ed Test Description: student selects the attendance 0picks a Description: student enters the details year0branch0semester0sub4ect theTest attendance status of he his2her as present2absent on thelike chosed date Requirements Verified: !es and searches for the result ,ith those details+ Requirements Verified: !es Test Environment: "pache omcat #er$er Test Environment: : "pache omcat #er$er %racle 10g %racle 10g &clipse '(& &clipse '(& "ndroid #() "ndroid #() *() 1+6 *() 1+6 Test Setup/Pre- onditions: Test Setup/Pre- onditions: 1! he ,eb ser$er should be in %- state 1! he ,eb ser$er should be in %- state "! he system should ha$e a connection ,ith the database+ "! he system should ha$e a connection ,ith the database+ #ctions #ctions students enters the $alid details to enter the result page #tudent clicks on attendance and enters the $alid details+ E$pected Resu%ts E$pected Resu%ts 3e can confirm the result of 3e can confirm the result of this test case as success if this test case as success if the the marks are displayed attendance status is displayed according to the search+ on the date picked by the student+ &ai%: -o &ai%: -o

Pass: !es onditions pass: -o Pass: !es onditions pass: -o Prob%ems / 'ssues: -'. Prob%ems / 'ssues: -'. (otes: resu%ts are successfu%%, disp%a,ed (otes: attendance status is successfully displayed+

@.2.4 T%,+C!,% "%52"+ 4:

53

Test case -: events Test Objective: o allo, a $alid student to check for the e$ents that are to be held in the college+ Test Description: he user selects the e$ents module and it is redirected to the e$ents page+ student can check the e$ents according to the branch5,ise and also year5,ise +student can also check ,hether it is a cultural e$ent or the technical e$ent+ student can also see the $enue0 timings and by ,hom the e$ents are conducted by+ Requirements Verified: !es Test Environment: "pache omcat #er$er %racle 10g &clipse '(& "ndroid #() *() 1+6

Test Setup/Pre- onditions: 1! "! he ,eb ser$er should be in %- state he system should ha$e a connection ,ith the database+ E$pected Resu%ts 3e can confirm the result of this test case as success if the e$ents 0e$ent5$enue0 e$ent5type0 e$ent5timings are displayed+ Pass: !es Prob%ems / 'ssues: -'. (otes: e$ents page is successfully displayed+ onditions pass: -o &ai%: -o

#ctions #tudent enters the $alid details to enter the e$ents page

@.2.5T%,+C!,% "%52"+5:

54

A. CONCLUSION
P"2;%9+ C2*93',(2*:
"f we are new to college or unable to &now information about attendance' results' e ents conducted in college this application is ery useful ! This application is di ided into three modules i0!!' attendance management' results management' e ents management !As the user registers it displays the modules! =y this student can choose his#her desired module and can the get the information he#she is loo&ing for! "f user want to &now information about attendance by gi ing student $id' branch$id'year$ id and sem Jid' he#she can &now his attendance percentage !in same manner by gi ing re,uired id%s he #she can &now the internal and e)ternal' regular and supplementary results! "f user want to &now about the e ents conducted in college by selecting the e ents module he#she can &now which types of e entsN at which placeNat what timeN Can be &nown in a easy and efficiency manner!! ?sing this application user can sa e his time!

FUTURE ENHANCEMENTS:
"n future we can pro ide notifications regarding attendance updates' results updates' e ents updates!! "n future by need of user' we will add information about the faculty! @e can pro ide the total information about infrastructure' transportation etc!!'

55

REFERENCES:
2. http3##de eloper!android!com#inde)!html 4. http3##www!ayo&asystems!com#enterprise$systems$solutions#mobileapplications$ for$manufacturing 5. http3##www!ma&etic&!com#enterprise$mobility#impact$of$mobile$applicationson$ health$sector$in$4>24!php 6. http3##www!loc$aid!com#node#74 7. http3##www!on+a a!com# 8. http3##www!oracle!com#technetwor&#+a a

56