Smart Card System for Buses

For a Better Tomorrow, Tomorrow

Project Vision

A ticketing procedureThat is

Convenient, well managed and reliable to

The passenger who travels,The bus conductor

andThe bus owner.

Problem

• Handling money• Ticketing takes time• Not having change to return the balance• Bus owners don’t get the actual profit to their

hands

Solution

• No cash involved• Smart card for the passenger• Hand-held ticketing machine for the

conductor• Income directly transferred to the owner’s

bank account

Main Features

• Smart cards can be purchased• Recharged trough merchants or automated

machines• One reading machine is associated with a

single FBTT account• Immediate account updates through GPRS• Terminals to transfer data from the machines

Main Features

• Two accounts for the bus owner– At the Goliath National Bank– At the FBTT

• Automatic update to the bank account• Online interface to check account activity• Disaster Recovery Centre• 24/7, 365 days per year available Data Centre• Immediate replacements for faulty machines

Stake Holders

• Bus owner• Conductor• Passenger• Goliath National Bank• Hoodwink Mobile• Merchants• FBTT

Bus Owner

• Have to open an account with the Goliath National Bank to participate in the program.

• View the activity of this account through an online interface.

Conductor

• Charge the fair from the passenger.

• If the GPRS connection failed, transmit the data in the device to the FBTT data center using a provided terminal.

Passenger

• Buy a smart card• Review balance• Recharge smart card

Goliath National Bank

• Handle account updates using the data provided by the datacenters.

Hoodwink Mobile

• Provide GPRS connection to the device

Merchants

• Issue Smart cards.• Recharge cards.

FBTT

• Replace devices• Update bank account• Disaster recovery

Implementation Process

Rational Unified Process will be used.

Why RUP? • This methodology has accurate documentation.• RUP is able to resolve the project risks.• Less time is required for integration.• The development time required is less due to

reuse of components.

RUP Phases and Disciplines.

Project ManagementEnvironment

Business Modeling

ImplementationTest

Analysis & Design

Preliminary Iteration(s)

Iter.#1

Process Workflows

Iterations

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration & Change Mgmt

Requirements

Elaboration TransitionInception Construction

A high-level architecture of the solution.

Major Milestones

• Completion of Business Case• Requirement Analysis• Adjustments for Risks• Schedule• Architectural Design• Software for devices• Data Center implementation

• Connecting to support services• System Integration and Testing• Finalized System• Cope to the System environment• Product Release • Maintenance

Major Milestones (cont.)

• Business Case Development phase• Initial Planning and Analysis phase• System Design Phase• System Development and Demonstration

phase• System Verification and Validation Phase• System Deployment Phase

Major Phases of The Project

Phase Effort Estimate (Man Days)

Business Case development phase 7

Initial Planning and Analysis phase 12

System Design Phase 16

System development and Demonstration phase 55

System Verification and Validation Phase 35

System Deployment Phase 25

Rough Effort Estimate for Each Phase

The High-Level Project Timeline

The Project Team

• Team Size : 15• Roles and Responsibilities

– Project MangerCoordinate the overall project while ensuring that software is delivered on time and on schedule and in accordance with the requirements

– System AnalystRequirement elicitation, requirement analysis, create requirement documentations

– System DesignerModel the system architecture

– DeveloperDevelop the software and perform basic testing

– TesterPerform release testing and handle configuration management

– Tech leadProvide technical support

– TrainerTrain the users of the system

Number of personnel allocated to each role:• Project Manger - 1• System Analyst - 1• System Designer - 1• Programmer - 5• Tester - 2• Interface Designer - 1• Database Developer - 1• Tech lead - 1• Trainer - 2

Documentation

• Feasibility ReportEvaluation and analysis of the potential of the proposed project

• Requirements DocumentationGathered features required by the customer

• System DesignDetailed system architecture which shows how to implement the system.

• Project Management PlanDetailed project schedule which will be used to measure progress in the future.

Documentation (cont.)

• Database specificationsDatabase requirements with design details

• Test PlanThis will be used to check if the product meets user specifications

• User ManualsThese show how to use the system

Project-Client Communication PlanCommunication

Type Parties

Involved Frequency Mode of Communication Purpose

Requirement Gathering SS to NTC As

neededFace to Face meetings

Gather project Requirements and resolve ambiguities

Requirement Changes NTC to SS As

neededFace to Face / Email

Discuss any changes to the previously specified requirements

Project Status Update SS to NTC Weekly Email

Provide updates on the current progress of the project

Feedback NTC to SS Weekly Email Provide feedbacks to the status updates provided

Project-Client Communication PlanCommunication

Type Parties

Involved Frequency Mode of Communication Purpose

Interface Specification SS to HM As

needed

Face to Face / Internet Messenger Service

Specify of the interface to wireless network

Interface Specification SS to GNB As

needed

Face to Face / Internet Messenger Service

Specify of the interface to bank network

cont.…

Project Risks

• Unavailability of the staff• Lack of experienced staff• Staff turnover• High level technical complexity• Incorrect time estimation• Incorrect budget estimation

Project Risks• Unavailability of hardware components• Third-party tasks take longer than expected • Change of customer requirements• Lack of communication between

organizations• Users are not used to the new system

cont.…

User Acceptance Guide Prepare

acceptance test plan

Prepare test scripts

Validate test scripts

Execute tests

Evaluate test

feedback

Fix test problems

Re-execute tests

Expected Participants

• Project Manager• Training staff• Members of NTC• Bus conductors• Bus owners• Data Center Employees• Team from Goliath National Bank• Team from Hoodwink Mobile

Acceptance Criteria Test Matrix (sample)

ID DescriptionCritical Test Result

CommentsYes No Accepted Rejected

<Test ID>

<Test Description>

<Comments on the outcome>

Thank You !For a Better Tomorrow, Tomorrow.