1

1. INTRODUCTION

1.1 PROBLEM DEFINITION & RELEVENT THEORY:-

Why is prepaid toll system proposed?

The toll system existing nowadays is quit time consuming one. We cant get desired information about any specific vehicle from the existing toll system. Many manual processing is required to be done in order to data and still we cant get all the information.

This drawback of existing system can be overcome by the automated toll system which we are going to develop. ollowing are some advantages which we will get from this system! !"eople dont have to wait for long time on toll booth to pay toll. ! #ll users traveling information is maintained. ! $o need to carry money on toll booth. ! %ashless transactions with the help of swap card. ! &asy to operate and understand. ! 'elp to generate collection reports. Thus we get number of benefits from the new system as compared to the old one.

1.2 SCOPE:-

"repaid Toll (ystem pro)ect

gives the information of vehicles and the places

visited by that vehicle* without any manual processing and within very less time period. This can be used on the toll booths for maintenance of database of vehicle and to detect criminal activities.

1.3 OBJECTIVE:-

The main ob)ective of the system we are going to develop is that the system should be user friendly and time saving system for toll pla+a. This system should minimi+e manual processing load and should help us to

detect criminal activities and reduces the manpower requirement. The system should maintain information of transaction history of every user.

2. REQUIREMENT ANALYSIS

,equirements analysis in an software engineering* encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product* taking account of the possibly conflicting requirements of the various stakeholders* such as beneficiaries or users. ,equirement analysis forms the base for design and development. -t provides the software designer with the representation of information* function* and behavior that can be translated to data* architectural interface and component!level designs. The main ob)ective is to state clearly what customer wants exactly from the system.

2.1 REQUIREMENT SPECIFICATION:-

# software requirements specification .(,(/ is a complete description of the behavior of the system to be developed. -t includes a set of use cases that describe all of the interactions that the users will have with the software. These specifications are of three types 0!

2.1.1 Nor !" R#$%&r# #'():o N1 ! Time saving system. o N2 ! Maintain database of all users. o N3 ! ,educed manual processing on toll pla+a. o N* ! ,educed man power on toll pla+a. o N+ ! %ollection report generation.

2.1.2 E,-#.(#/ R#$%&r# #'():o E1 ! 1ser friendly system. o E2 ! %apture criminal activities. o E3 ! (olves change problem.

2.1.3 E,.&(#/ R#$%&r# #'():o 01 ! Transaction message sending to owner. o 02 ! $o need to carry cash on toll pla+a.

2.2 VALIDATION OF REQUIREMENTS:-

,equirement validation examines that all system requirements have been stated unambiguously and inconsistencies and errors have been detected and corrected. -t also ensures that the work products confirmed to the standards established for the process* pro)ect and product. The work products produced as a consequence of requirements engineering are assessed during validation.

2.2.1 V!"&/!(&o' O1 Nor !" R#$%&r# #'():o N1 ! The system should be time saving one. o N2 2 We should get information of every user from system database. o N3 2 Manual process load should be minimi+ed. o N* ! Manpower requirement on toll booth should be minimi+ed by the system. o N+ 2 We should get the collections reports from the system.

2.2.2 V!"&/!(&o' O1 E,-#.(#/ R#$%&r# #'():o E1 ! (ystem should be user friendly and easy to operate. o E2 2 (ystem should help to detect the criminal activities. o E3 2 (ystem should solve change problem on toll booth.

2.2.3 V!"&/!(&o' O1 E,.&(#/ R#$%&r# #'():o 01 2 3wner of vehicle should be informed each time card is swapped. o 02 2 %ashless transactions can be done by the swap card.

2.3 HARD3ARE REQUIREMENTS:o "rocessor "4 onwards. o 567 M8 ,#M. o (wap %ard. o (wapping Machine. o Mobile "hone. o &",3M %hip.

2.* SOFT3ARE REQUIREMENTS:o Windows 7999 onwards o #(". $et o %: o 3racle 69;

3. SYSTEM DESI5N
3.1 PROCESS MODEL:-

-n contrast to software life cycle models* software process models often represent a networked sequence of activities* ob)ects* transformations* and events that embody strategies for accomplishing software evolution. (uch models can be used to develop more precise and formali+ed descriptions of software life cycle activities. Their power emerges from their utili+ation of a sufficiently rich notation* syntax* or semantics* often suitable for computational processing. I(#r!(&6# !'/ I'.r# #'(!" /#6#"o- #'( is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. -t starts with an initial planning and ends with deployment with the cyclic interactions in between. -terative and incremental developments are essential parts of the ,ational 1nified "rocess* &xtreme "rogramming and generally the various agile software development frameworks. The basic idea is to develop a system through repeated cycles .iterative/ and in smaller portions at a time .incremental/* allowing the developer to take advantage of what was learned during the development of earlier portions or versions of the system. <earning comes from both the development and use of the system* where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the

7
evolving versions until the full system is implemented. #t each iteration* design modifications are made and new functional capabilities are added. The incremental process model is suitable for our pro)ect as the number of developers is less. The product is delivered to the customer in the form of increments and any modifications suggested by the user are accommodated in the successive increments.

(ystem engineering
#nalysis >esign %ode Test

>elivery of 6st increment

#nalysis

>esign

%ode

Test

>elivery of 7nd increment

#nalysis

>esign

%ode

Test

>elivery of ?rd increment >elivery of 4th increment

#nalysis

>esign

%ode

Test

F&8 3.1 T9# I'.r# #'(!" Pro.#)) Mo/#"

3.2 BREA:DO3N STRUCTURE:The following figure shows the breakdown structure of the "repaid Toll (ystem. -t contains following main components 2 o =alidation o 8alance deduction

;
o ,eport generation o Mobile (M( sending

The validation module includes validation of customer information* account balance and vehicle number in the card and actual number of vehicle.

F&8 3.2 Br#!</o=' S(r%.(%r# o1 S>)(#

1?
3.3 PROJECT ESTIMATION:"ro)ect estimation is nothing but calculating the time requirement and efforts required to complete the pro)ect. We can also determine the line of code of the pro)ect.

3.3.1 E)(& !(&o' o1 :LOC:;raphical 1ser -nterface >ata transfer from card to mAc =alidation of information 8alance deduction Mobile (M( sending ,eport generation Total @<3% 6.7 @<3% 9.5 @<3% 9.B @<3% 9.7 @<3% 9.? @<3% 9.4 @<3% ?.7 @<3% .#pprox./

3.3.2 E11or():&fforts required to implement the pro)ect can be calculated by using the following formula! & C ?.7 D .@<3%/ E6.95 & C ?.7 D .?.7/ E6.95 & C 69.F? person!month

11
3.3.3 D#6#"o- #'( T& #:>C&A$ & C 69.F? person!month and $C? > C ?.B6 months i.e. $o. of persons.

3.3.* To(!" D#6#"o- #'( T& #:Total development time for a pro)ect is equal to the time required for requirement analysis and system design and time required for implementation G testing.

Time required for ,equirement #nalysis and (ystem >esign ! . 6 .7 month/

@
Time required for -mplementation G Testing ! . ?.B months /

Total development time

.4.F months approx./

Thus* we require total 4.F months to complete the pro)ect.

12

*. ANALYSIS
*.1 PROJECT SCHEDULIN5 AND TRAC:IN5:-

"ro)ect (cheduling and Tracking is important because in order to build a complex system* many software engineering tasks occur in parallel* and the result of work performed during one task may have a profound effect on work to be conducted in another task. These interdependencies are very difficult to understand without a detailed schedule. *.1.1 ProA#.( 3or< Br#!</o=' S(r%.(%r# BA'!">)&)C:-

13

F&8 *.1 ProA#.( 3or< Br#!</o=' S(r%.(%r# BA'!">)&)C

ig 4.6 shows the "ro)ect Work 8reakdown (tructure. The proposed system is divided into five main tasks vi+.* %ommunication* "lanning* Modeling* %onstruction and >eployment. These Tasks are further divided in subtasks.

*.2 TAS:S:T1: "ro)ect >efinition (earching. T2: Material %ollection. T3: ,equirement ;athering and =alidating. T*: "ro)ect "lanning.

1*
T+: (ystem >esign. T2: "ro)ect (cheduling and Tracking. T4: %reation of #nalysis Model. T7: ,isk #nalysis and Management. T;: -nitial ;raphical 1ser -nterface. T1?: Writing -nformation into (wap %ard. T11: Transfer -nformation from %ard to MA%. T12: =alidation %ard -nformation. T13: %hecking %ard (tatus. T1*: >educting 8alance. T1+: (end (M( to 3wner of %ard. T12: (tore the -nformation about %ustomer Transaction 'istory. T14: 1pdate -nformation in >atabase. T17: ,eport ;eneration.

T1;: Testing. T2?: eedback from %ustomer.

T21: Make ,equired Modifications. T22: ,elease of inal (oftware.

*.3 PROJECT SCHEDULE: ! The table 4.6 describes the schedule for pro)ect development and also highlights all the tasks to be carried out along with their duration* dependency and developer.s/ assigned to accomplish the task.

1+

T!D"# *.1 ProA#.( S.9#/%"# T!)<) T6 T7 T? T4 T5 TB TH TF TI T69 T66 T67 T6? T64 T65 T6B T6H T6F T6I T79 T76 T77 Total >ays D!>) ? 4 5 5 B F 67 69 66 H ? 7 5 B 67 5 H F B 4 F ? 649 D#-#'/#'.&#) ! T6 T6*T7 T? T? T4*T5 T4*T5 T5*TB TH ! T69 T69*T66 ! T67 T69*T67 TB T66!T6B T6H ! ! T79 ! D#6!"o-#r) A))&8'#/ >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >7*>? >6*>7 >6*>7*>? >6*>7 >7*>? >6*>7 >7*>? >6*>7*>? >6**>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>?

*.3.1 T& # L&'# C9!r(:-

12

F&8 *.2 T& # L&'# C9!r(1 EA.(%!" D!>)F

0 -ndicates Milestone M6/ inali+ation of ,equirements M7/ (ystem >esign

14

F&8 *.3 T& # L&'# C9!r(2 EE,-#.(#/F

0 -ndicates Milestone M6/ %reating (wap %ard M7/ (M( (ending to 3wner M?/ Testing

*.3.2 ProA#.( T!D"#:T!D"# *.2 ProA#.( T!D"# T!)< 'o S(!r(&'8 (& # E'/&'8 T& # D#6#"o-#r) R# !r<

17
E,-#.(#/ 66A9HA66 6FA9HA66 75A9HA66 96A9FA66 9BA9FA66 66A9FA66 6IA9FA66 96A9IA66 65A9IA66 ?9A9IA66 9IA96A67 9IA96A67 9?A97A67 9BA97A67 9IA97A67 7IA97A67 95A9?A67 67A9?A67 6IA9?A67 7BA9?A67 97A94A67 9IA94A67 A.(%!" 67A9HA66 9BA9FA66 6?A9FA66 6IA9FA66 75A9FA66 ?9A9FA66 9HA9IA66 6?A9IA66 94A69A66 64A69A66 ! ! ! ! ! ! ! ! ! ! ! ! E,-#.(#/ 64A9HA66 77A9HA66 ?9A9HA66 9BA9FA66 67A9FA66 6IA9FA66 ?6A9FA66 69A9IA66 7BA9IA66 9HA69A66 67A97A67 66A97A67 9FA97A67 67A97A67 76A97A67 9?A9?A67 67A9?A67 79A9?A67 75A9?A67 ?9A94A67 69A94A67 67A94A67 A.(%!" 9HA9FA66 67A9FA66 6FA9FA66 7?A9FA66 7IA9FA66 9BA9IA66 64A9IA66 97A69A66 64A69A66 6IA69A66 ! ! ! ! ! ! ! ! ! ! ! ! A))&8'#/ >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >7*>? >6*>7 >6*>7*>? >6*>7 >7*>? >6*>7 >7*>? >6*>7*>? >6**>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>? >6*>7*>?

T6 T7 T? T4 T5 TB TH TF TI T69 T66 T67 T6? T64 T65 T6B T6H T6F T6I T79 T76 T77

*.* ANALYSIS MODEL:-

*.*.1 U)# C!)# D&!8r!

BS>)(#

O6#r6&#=C:-

# use case involves a sequence of interactions between the initiator and the system* possibly involving other actors.

1;

F&8 *.* U)# C!)# D&!8r!

1or S>)(#

O6#r6&#=

*.*.2 U)# C!)# D&!8r! BPr#-!&/ To"" S>)(# C:-

2?

F&8 *.+ U)# C!)# D&!8r!

1or Pr#-!&/ To"" S>)(#

*.*.3 C"!)) D&!8r! :-

21
-n design specification it can be used to specify interfaces and classes that will be implemented in an ob)ect oriented program. %lass diagram shows the interdependencies between the classes of the system.

F&8 *.2 C"!)) D&!8r!

22

*.*.* S#$%#'.# D&!8r! :# sequence diagram is a graphical view of a scenario that shows ob)ect interaction in a time!based sequence. (equence diagrams establish the roles of ob)ects and help provide essential information to determine class responsibilities and interfaces. This type of diagram is best used during early analysis phases in design because they are simple and easy to comprehend. (equence diagrams are normally associated with use cases.

F&8 *.4 S#$%#'.# D&!8r!

1or (9# S>)(#

23

*.*.+ A.(&6&(> D&!8r! :-

#ctivity diagrams are very similar to a flowchart because you can model a workflow from activity to activity. 8elow is the activity diagram for "repaid Toll (ystem.

F&8 *.7 A.(&6&(> D&!8r!

1or (9# S>)(#

2*

*.*.2 S(!(# M!.9&'# D&!8r! :(tate chart diagrams model the dynamic behavior of individual classes or any other kind of ob)ect. They show the sequences of states that an ob)ect goes through* the events that cause a transition from one state to another and the actions that result from a state change.

F&8 *.; S(!(# M!.9&'# D&!8r!

2+

*.*.4 Co'(ro" F"o= D&!8r! :The large class of applications having following characteristics requires control flow modeling0! The applications those are driven by the events rather than data. The applications those produce control information rather than reports or displays. The application those process information in specific time.

F&8 *.1? Co'(ro" 1"o= D&!8r!

22
*.*.7 D!(! F"o= D&!8r! :>ata flow diagram .> >/ is also called as J8ubble %hart is a graphical technique* which is used to represent information flow* and transformers those are applied when data moves from input to output. > > represents system requirements clearly and identify transformers those becomes programs in design. > > may further partitioned into different levels to show detailed information flow e.g. level9* level6 etc.

F&8 *.11 D!(! F"o= D&!8r!

B"#6#" ?C

F&8 *.12 D!(! F"o= D&!8r!

B"#6#" 1C

24

+. RIS: MANA5EMENT
R&)< !'!8# #'( is the identification* assessment* and prioriti+ation of risks followed

by coordinated and economical application of resources to minimi+e* monitor* and control the probability andAor impact of unfortunate events or to maximi+e the reali+ation of opportunities

+.1 RIS: IDENTIFICATION:-

+.1.1 C%)(o #r R#"!(#/:R1 ! %ustomer may not be a technical person* so understanding exact requirements of customer may not be possible. R2 ! -f non feasible or irrelevant requirements are provided by the customer* it may generate some unknown risk. +.1.2 Pro/%.( S&G# R#"!(#/:R3 ! "roduct si+e may increase due to inefficient implementation of system. +.1.3 B%)&'#)) I -!.(:R* ! >elay in pro)ect delivery .violation of time constraints/ can hamper the customer economically. +.1.* S(!11 S&G# R#"!(#/:R+ ! #s the scope of the pro)ect is too large* it may be difficult to complete it in given span of time with ? persons.

27

+.1.+ D#6#"o- #'( E'6&ro' #'( R#"!(#/:R2 ! <ack of training on the development tools may cause an inefficiency and difficulty in pro)ect completion. R4 ! (oftware "rocess Model is not followed upto the defined degree. R7 ! -f customer asks for modification.s/ in later stages of development* it is difficult to alter the entire system in accordance with that change.s/. +.1.2 Pro/%.( R#"!(#/:R; ! -f customer forgets to bring swap card at toll pla+a. R1? ! -f customer does not have sufficient balance. R11 ! -nput should not be other than swap card. R12 ! -f customer lost his swap card or vehicle.

+.2 STRATE5IES USED TO REDUCE RIS:S:-

S1 ! ,egular meeting with the customer reduces risks. S2 ! More time should be spend upon testing and improvement. S3 ! Time constraints must be followed to avoid economical risks.

2;

S* ! (election of incremental model so that the pro)ect can be completed with less number of persons. S+ ! "roper training on required technical tools for development of pro)ect reduces risk. S2 ! ,edefine software process at a higher degree. S4 ! (ystem should be flexible enough to adopt future changes and modifications suggested by user. S7 ! %ustomer has to make cash payment. S; ! -f card information does not match with database then show error message. S1? ! %ustomer has to purchase new swap card and make status of old card as inactive.

+.3 RIS: PROJECTION:Table below lists all possible risks which may occur at any stage during development of pro)ect. Table also clearly shows the impact of risks and ,MMM .,isk Mitigation Monitoring and Management/ plan to deal with any such risks.

3?
T!D"# +.1 R&)< T!D"# R&)< R1 R2 R3 R* R+ R2 R4 R7 R; R1? R11 R12 C!(#8or> %ustomer related %ustomer related "roduct si+e related 8usiness impact (taff si+e related >evelopment &nvironment related >evelopment &nvironment related %ustomer related %ustomer related %ustomer related %ustomer related %ustomer related ProD!D&"&(> Moderate <ess More More More <ess <ess <ess Moderate Moderate <ess <ess I -!.( 'igh Medium <ow 'igh 'igh <ow 'igh 'igh <ow <ow <ow Medium RMMM P"!' S1 S1 S2 S3 S* S+ S2 S4 S7 S7 S; S1?

31 2. CONCLUSION

The system comes handy as it provides automation for toll system. There is no need to carry cash on toll pla+a while travelling on roads for the card holders as we are providing swap card for each customer. The system is very much time saving and user friendly which is easy to operate and understand. The HPREPAID TOLL SYSTEMI reduces manual processing done on the toll pla+a and hence the manpower requirement on the toll pla+a is reduced.