Upload
hashini-senaratne
View
841
Download
0
Embed Size (px)
DESCRIPTION
This is a presentation to be presented at the project kick-off meeting. (A group work of 5 undergraduates of CSE - UOM)
Citation preview
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.