Description
This is a document about IT project of bank of baroda.
SOW: Bank of Baroda Capital Market Ltd.
IT Consulting
Contents
Project Description........................................................................................................................................ 3 Project Scope ............................................................................................................................................ 3 Project Approach: ..................................................................................................................................... 4 N-Tier Architecture ............................................................................................................................... 4 Our Responsibilities ...................................................................................................................................... 5 Deliverables............................................................................................................................................... 6 Assumptions .......................................................................................................................................... 7 Your responsibilities .................................................................................................................................. 8 Assumptions .......................................................................................................................................... 8 Estimated Schedule & Timelines................................................................................................................... 9 Acceptance Process for project deliverables .............................................................................................. 10 Acceptance Criteria for Milestones and Deliverables............................................................................. 11 Resource Planning and Costing: .................................................................................................................. 16 Costing .................................................................................................................................................... 18 Phase wise Costing .............................................................................................................................. 18 Ending Project Early .................................................................................................................................... 19 Project Change Management ..................................................................................................................... 20
SOW: BCML
Page 2
PROJECT DESCRIPTION
Bank of Baroda Capital Markets Ltd. (BCML) is a fully owned subsidiary of Bank of Baroda one of the largest public sector Bank in India with a Branch network of over 2800 branches in India and 25 other overseas countries. BCML is engaged in Merchant Banking, Mutual Fund Distribution and is desirous of commencing Broking business for which the company has obtained SEBI registration, through two exchanges i.e. BSE and NSE. Now, they are looking for Back Office solution provider for supply, Installation, Customization and Commission of software for carrying out broking activity. The Request for Proposal document (“RFP”) has been prepared to enable BOB Capital Markets Ltd. (BCML) in the selection of Back Office Solution Provider for Broking business of BCML. PROJECT SCOPE The selected Solution will be provided for Back Office solution for Broking Business of BCML (Based on the contents of the RFP) with standards and best practices acceptable to market, clients and regulators. BCML’S memberships to BSE & NSE are approved by respective Exchanges and SEBI’S clearance has been received. BCML has applied for Dealing in Cash Segment, Wholesale Debt Market and F&O. The BCML clearly states that the selection of Back Office Solution provider under the RFP is on the understanding that the RFP contains only the principal (or primary) provisions for the entire assignment. We will undertake all such tasks, render services required and make such resources available as may be required for the successful completion of the entire assignment at no additional costs to BCML. We will provide the details of the Platforms including (but not limited to) Hardware like Servers, Routers, Switches, Firewalls etc. and Software Licenses like Operating Systems, RDBMS (SQL/Oracle or others) and other licenses required for successful and smooth functioning of the Infrastructure.
SOW: BCML
Page 3
Indicative details of SRS (Software Requirement Specifications) are mentioned in separate Document i.e. ANNEXURE-I of the RFP. During the course of the review, we may suggest any other critical methods/improvement as deemed fit from the point of view of system provider experience for each of the SRS mentioned. However, the BCML reserves the right to change the scope of the RFP considering the size and variety of the requirements and the changing business conditions as per regulators or otherwise. PROJECT APPROACH: Keeping in mind the various elements namely performance, scalability and future development issues of the proposed project by BCML, the architecture we would be adopting is N-Tier Architecture. N-TIER ARCHITECTURE N-Tier architecture refers to the architecture of an application that has at least 3 "logical" layers - or parts -- that are separate. Each layer interacts with only the layer directly below, and has specific function that it is responsible for. Because each layer can be located on physically different servers with only minor code changes, hence they scale out and handle more server load. Also, what each layer does internally is completely hidden to other layers and this makes it possible to change or update one layer without recompiling or modifying other layers. This is a very powerful feature of n-Tier architecture, as additional features or change to a layer can be done without redeploying the whole application. An n-Tier application usually has three tiers, and they are called the presentation tier/client application layer, the business tier/business rules layer and the data tier/layer. Let's have a look at what each tier is responsible for.
SOW: BCML
Page 4
Presentation / Client application Layer Presentation Layer is the layer responsible for displaying user interface and "driving" that interface using business tier classes and objects. Business Tier/Business Rules Layer Business Tier is the layer responsible for accessing the data tier to retrieve, modify and delete data to and from the data tier and send the results to the presentation tier. This layer is also responsible for processing the data retrieved and sent to the presentation layer. Data Tier/Layer Data tier is the database or the source of the data itself.
OUR RESPONSIBILITIES
The following deliverables will be delivered on time, failing which BMCL can levy a charge of Rs.50000 per week for weeks of delay thereafter, as mentioned in the RFP.
SOW: BCML Page 5
DELIVERABLES A. Back Office Software and Support: Software will be provided which can support the required number of clients. The details of the software is given in the attached form “Functional Evaluation – Back Office Software Required Specification (SRS)”, which was part of the RFP. Support and maintenance will be provided for a period of 5 years as mentioned in the compliance certificate, subject to certain criteria like location, severity etc. (Note: the SRS is not attached in this assignment but required during actual submission of proposal since the form was given in the RFP itself)
B. Live, Implemented and Successfully Operable Application meeting the Requirements enumerated by BCML. A live, implemented and successfully operable application will be first demonstrated in selected sites, which can be installed in all the sites in a phased manner.
C. Licenses A license fee will be charged for initial number of software copies and any number of copies purchased thereafter in case the bank requires extension.
D. Application support for minimum 5 years will be provided
E. Documentations- Administrative Manual ? ? Operational Manual – Softcopy and hardcopy will be provided at the time of installation and updates and corrections will be handled in later versions. User Manual – Generic user manual will be provided along with training for selected employees who can be champions later. F. Training for –Operational Staff, Technical staff, Help Desk Personnel and others in the following areas: A detailed training will be provided to employees, which will cover the architecture, process flows, usage, handling and basic troubleshooting. The training will cover only the software
SOW: BCML
Page 6
handling and it would be fare to assume that the user have the basic functional knowledge and expertise.
G. Functional and Technical Guidance, through on site support till 6 months after going live of Retail trading. Technical and functional guidance for the software would be given but not for the functional domain specific training. The users are expected to know about banking fundamentals, capital markets and basic computing skills.
H. Development and Integration of the Interface with Front Office, BSE, NSE, Core Banking System of the Bank, Depository Software of the Bank and other software if required. Depending on the feasibility, interfaces can be developed with other front office softwares. A need based feasibility analysis can be done for each software thus identified and interfaces can be incorporated during upgrades. The cost will depend on information available, Intellectual property rights of other vendors, man hours spent t develop interface etc. For third party interfaces identified if available in market, only a consultancy fee will be charged by us. ASSUMPTIONS The following assumptions are made during the preparations of this document. 1. The project will be deployed in a phased manner across the nation and not as a big bang approach. 2. The project will have upgrades which can be charged depending on new hardware and software requirements. 3. “General terms and conditions” as given in section 1.5 of RFP will be adhered. 4. Our company should also have the right to change the team leader and team members. We would ensure that the quality will not suffer due to this. This process is to ensure that our employees get a fare chance for their career progression. 5. We assume that at no point further major changes would be made in the requirement by BCML. Minor adjustments can be managed, but major functional changes would result in a change in deadline and billable hours.
SOW: BCML Page 7
6. We can provide BCML with IP rights for any new modules developed solely for BCML but the IP rights for generic modules remain with us. Also any new ideas, patents and methods developed by our engineers during the course of this project should be evaluated and if they are generic solutions applicable in other domains also, then we would insist to have the IP rights with us. YOUR RESPONSIBILITIES The following responsibilities are expected from BCML. 1. Infrastructure requirements like space, air conditioning, networking, connectivity etc should be available in each branch. 2. The hardware and software has to be centrally procured under a single onetime payment, although transportation and installation of computers and servers in each location can be maintained by us. 3. The installation would be done in a phased manner. Payments are also expected to be only in a phased manner though not in a similar ratio. 4. We expect utmost commitment from all levels of BCML employees especially the top management. No IT project can be success without commitment from your employees. To facilitate this we expect that a project leader and project team would be assigned from your side who would constantly work alongside us during the planning, development and implementation phases. 5. We expect BCML to provide champions from each department who have enough expertise in managing computers and handling similar software. These champions would be trained and they can in turn help in training other employees. 6. We expect that while our employees are working in BCML premises, they would be treated well and their requirements would be addressed at the earliest. 7. We expect BCML to provide us with references and certificates after successful completion of the project. ASSUMPTIONS 1. We assume that BCML would follow a strict and clear evaluation and selection process for identifying the vendor for this project.
SOW: BCML Page 8
2. It would be easier for integrating multiple modules if the project is given to only one vendor. 3. We expect BCML also to adhere to the general rules and laws of the land. 4. BCML has the right to audit the progress of the project subject to a maximum of 2 times a year.
ESTIMATED SCHEDULE & TIMELINES
The following list the detailed schedule of each and every stage of the project with the duration of each stage. It is assumed that the project will start after 1 and 1/2 month from Response to RFP Due date as mentioned in RFP. Sr. No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Stage Name Concept and Feasibility Study Requirement Analysis Architecture of the System High Level Design Detail Level Design Coding Setting Development Environment Setting Test Environment Unit Testing Integration Testing System Testing User Acceptance Testing Deployment of System Document Delivery Duration (days) 20 2-Feb-09 60 20-Apr-09 20 18-May-09 20 15-Jun-09 25 20-Jul-09 40 20-Jul-09 10 3-Aug-09 10 17-Aug-09 20 14-Sep-09 10 28-Sep-09 10 12-Oct-09 15 2-Nov-09 5 9-Nov-09 5 13-Nov-09 13
Page 9
Start 7-Jan-09
Finish 31-Jan-09 17-Apr-09
Predecessors
1 15-May-09 2 12-Jun-09 3 17-Jul-09 4 11-Sep-09 4 31-Jul-09 6 14-Aug-09 6 11-Sep-09 5, 7 & 8 25-Sep-09 9 9-Oct-09 10 30-Oct-09 11 6-Nov-09 12
SOW: BCML
16-Nov-09 15 16 17 User Training Going Live Hand Holding 10 30-Nov-09 2 2-Dec-09 10
27-Nov-09 12 & 14 1-Dec-09 15 15-Dec-09 16
ACCEPTANCE PROCESS F OR PROJECT DELIVERABLES
The acceptance process for “Back Office Solution for Brokering Business” provides roadmap for incremental acceptance by Bank of Baroda Capital Market Ltd. and associated deliverables at the following key milestones.
? ? ? ? ? ?
Project Phase Concept Complete Phase Requirements Complete Phase Design Complete Phase Application Ready For Pilot Phase Application Ready For Rollout Phase Complete.
Following key deliverables are subject to acceptance within the context of above milestones. Milestone Deliverables Project Initiation and Implementation Document, Software Project Phase Concept Complete Phase Requirements Complete Phase Design Complete Project Management Plan Software Requirements Specification Template Software Design Specification Application, Software Test Plan, Software Transition Plan, Phase Application Ready For Pilot Phase Application Ready For Rollout Phase Complete Training Plan, User’s Handbook, Business Continuity Plan Application, Software Test Plan, Software Transition Plan, Training Plan, User’s Handbook, Business Continuity Plan Closeout Review, Lessons-learned
SOW: BCML
Page 10
ACCEPTANCE CRITERIA FOR MILESTONES AND DELIVERABLES The acceptance criterion in the table defines the conditions under which BCML agree and accept completion of milestones and deliverables subject to these acceptance criterions. Milestone Deliverable Acceptance Criteria Prioritized scope and high level requirements have Project Initiation and Project Phase Concept Complete Implementation Document been reviewed by the Design Team, which consists of stakeholders from BCML in addition to key members of the project team. Prioritized scope and high level requirements have been reviewed by the Design Team, which consists of Project Phase Concept Complete Software Project Management Plan stakeholders from BCML in addition to key members of the project team. The Software Requirements Specification describes what capabilities the application should have and includes:
? ? ? ? ? ?
Business Process Business Requirements Use Cases Functional Requirements Data Requirements Non Functional Requirements
The Design Team has reviewed the Specification and its prioritized requirements for correctness, completeness, and consistency with respect to BCML’s business processes and business needs within the scope established.
The application development team has reviewed the Phase Requirements Complete
SOW: BCML
Software Requirements Specification
Specification to ensure its sufficiency for beginning application design and to determine which
Page 11
requirements can be met within the constraints of the current project phase.
The software test team has reviewed the Specification to ensure that all requirements are testable. The project manager has reviewed the Specification to ensure that all requirements are traceable to the scope, goals, and objectives established The Software Design Specification describes how the application should function and be constructed to provide the capabilities defined in the Software Requirements Specification. This document includes:
? ? ? ? ? ? ? ? ?
Screen flows Screen designs Letters design Report designs Logical data model Physical data model User roles Security model Detailed system interface designs
The Design Team has reviewed the Specification for correctness, completeness, and consistency with respect to the prioritized requirements established in the Software Requirements Specification.
The business team has reviewed the specification to ensure that all requirements are fully represented in Phase Design Complete Software Design Specification the design and that the design includes no items that are not part of the established requirements.
SOW: BCML
Page 12
The application development team has reviewed the Specification to ensure its sufficiency for beginning application development and to validate the feasibility of implementing the design within the constraints of the current project phase. The software test team has reviewed the Specification to ensure that the design is testable.
The completed application will be delivered into the test environment with functionality as specified in the Software Requirements Specification, Supplemental Specification for Nonfunctional Requirements, and Software Design Specification. The completed application passed through system testing with the following results:
?
All test cases completely executed for functional modules with a system test priority ranking between 1 and 3 inclusive.
? ?
Zero severity 1* (critical) defects. Zero severity 2** (major) defects in business priority# 1 functional modules
?
No more than 2 severity 3 defects (minor) per business priority 1 functional module and no more than 20 severity 3*** defects total in business priority one functional module.
?
No more than 1 severity 2 defect per business priority 2 functional module and no more than 5 severity 2 defects total in business priority 2
Phase Application Ready For Pilot
SOW: BCML
functional modules Software Test Plan
?
No more than 5 severity 3 defects per business
Page 13
priority 2 functional module and no more than 40 severity 3 defects total in business priority 2 functional modules The User’s Handbook describes in detail the procedures for using all of the functionality provided Phase Application Ready For Pilot User’s Handbook in the application in terms understandable to the typical user. The Software Transition Plan describes the tasks and activities that need to take place to efficiently and effectively move the application from the development or test environment to the production environment and to integrate use of into the business processes of BCML.
The Plan includes deployment schedules, resource estimates, identification of special resources and staffing. The transition plan also defines management controls and reporting procedures, as well as the risks and contingencies. An impact statement outlining the potential impact of the transition to the existing Phase Application Ready For Pilot Software Transition Plan infrastructure, operations, and support staff and to the user community is also included. The Training Plan describes what training will Phase Application Ready For Pilot Training Plan provided to users to prepare them to use the application and how this training will be performed. The Business Continuity Plan describes how business Phase Application Ready For Pilot Phase Application Ready For Rollout
SOW: BCML
functions supported by will be performed in the event Business Continuity Plan that the application is unavailable for a period of time. Any application issues that the Design Team and Pilot Application users identified as needing to be addressed prior to
Page 14
rollout have been addressed.
The User’s Handbook was updated to include any Phase Application Ready For Rollout User’s Handbook changes necessary to support application changes made after the Pilot. The Software Transition Plan was updated to include Phase Application Ready For Rollout Phase Application Ready For Rollout Training Plan Software Transition Plan any changes necessitated by problems with the Pilot rollout. The Training Plan was updated to include any changes necessitated by problems with the Pilot training. The Business Continuity Plan was updated to include any changes necessitated by problems with the Phase Application Ready For Rollout Business Continuity Plan evaluation of business continuity procedures during the Pilot. All project activities and any approved change requests have been completed. All users have been trained and provided access to the application as specified in the Software Transition Phase Complete Closeout Review Plan and Training Plan.
*Severity 1, or Critical, defects include issues that result in degraded system performance beyond stated performance criteria, deny access to functionality, and/or corrupt data or display data incorrectly. ** Severity 2, or Major, defects include issues that prevent a user from correctly completing a task in the system, but can be managed by a workaround, and/or issues that promote data errors or reduce data quality substantially. *** Severity 3, or Minor, defects include issues that interfere with, but do not prevent a user from performing normal tasks.
SOW: BCML
Page 15
#Business priority refers to the business priority assigned to a functional module in the Software Requirements Specification, where priority 1 is business critical, priority 2 is moderately important, and priority 3 is optional.
RESOURCE PLANNING AND COSTING:
Project Manager (PM): The Project Manager will work with the BCML Project Manager to communicate the details of the project plan, including assignments, milestones, schedules, and budget. Role responsibilities include assigning team members to activities/tasks and monitoring team progress against the plan. The Project Manager resolves or evaluates project issues in the areas of operating policies, staffing, and project scope. The Project Manager also conducts scheduled, periodic meetings with the Project Team, Project Sponsor, and other Committee groups. This person also acts as a liaison between engineers and designers and serves as the project contact person for external (non-project) resources. Business Analyst (BA): This individual provides business representation and leadership for a core functional area impacted by the implementation and provides overall business process expertise to the project team. There may be multiple analysts assigned to a core functional area, each having ownership of a subset of core business processes. The Business Analyst attends all of the prototyping sessions where the majority of business process discovery will occur. This role serves as the liaison between the user organization and the project team Technical Lead (TL): The Technical Lead assures that the integrity of design is maintained across business processes. Technology Expert (TE): The Technology Expert designs and creates technology solutions in response to business requirements. The Technology Expert joins a project when the solution requires some specific knowledge in the emerging technologies Developer: Developer coverts the low level designs in the form of code. This individual has experience in the technology being used for implementation. Tester: This individual ensures that all the detailed test plans are created for all the business processes and tested for the same.
SOW: BCML Page 16
Elapsed Time Phase Stage Concept and Project Phase Complete Phase Requirements Complete Feasibility Study Requirement Analysis System Architecture High Level Design Low Level Design 20 1 PM, 1 TL, 1 BA 20 1 PM,1 TL, 1 BA, 2 TE 20 1 PM,1 TL, 1 BA, 2 TE 1 PM,1 TL, 1 BA, 2 TE, Phase Design Complete Coding Setting Development Environment Setting Test Environment 1 PM,1 TL, 1 BA, 2 TE, 10 5 Developers 1 PM,1 TL, 1 BA, 2 TE, 10 5 Developers 1 PM,1 TL, 1 BA, 2 TE, Unit Testing 20 5 Developers, 3 Testers 1 PM,1 TL, 1 BA, 2 TE, Integration Testing Phase Application Ready for Pilot System Testing User Acceptance Testing Deployment of System Document Phase Ready for Roll Out Delivery 10 5 Developers, 3 Testers 1 PM,1 TL, 1 BA, 2 TE, 10 5 Developers, 3 Testers 1 PM,1 TL, 1 BA, 2 TE, 15 5 Developers 1 PM,1 TL, 1 BA, 2 TE, 5 3 Developers 1 PM,1 TL, 1 BA, 2 TE, 5 3 Developers 8 8 10 13 13 13 10 10 40 5 Developers 10 3 5 5 60 1 PM, 3 BA 4 20 1 PM, 2 BA 3 (Days) Resources Total
SOW: BCML
Page 17
1 PM,1 TL, 1 BA, 1 TE, User Training 10 1 Developers 1 PM,1 TL, 1 BA, 1 TE, Go Live 2 1 Developers 1 PM,1 TL, 1 BA, 1 TE, Phase Complete Hand Holding 10 1 Developers 5 5 5
COSTING Costing for the project will be done as per the billing rates given in the following table.
Resource PM BA TL TE Developer Tester
Billing Rate (Rs Per Duration (Man Hour) Days) 1200 1150 950 850 700 650
287 427 207 352 627 120
Total Cost Total Hours (Rs) 2296 2755200 2768 3928400 1656 1573200 2816 2393600 5016 3511200 960 624000 14785600
PHASE WISE COSTING Phase Project Phase Concept Complete Phase Requirements Complete Phase Design Complete Phase Application Ready For Pilot Phase Application Ready For Rollout Phase Complete. Total Cost 560000 2232000 4848000 4704000 1588000 853600 14785600
SOW: BCML
Page 18
ENDING PROJECT EARLY
The following describes the exit criteria for both companies if the terms and conditions stated and agreed are not acceptable at later point in time. If the performance of the system is not satisfactory to BCML, the satisfaction criteria should be clearly stated before initiation of the project. Some of the criteria’s can be 1. The system may take lot of time to respond to the users input. The user input in this case can be entering of certain key data like name of the broking company, transaction amount, trading amount, etc. The system may take lot of time to save data on the server. The problem could be either because of heavy traffic on the web server due to which the data resources on the server can be clogged. This implies improper designing of the system in handling such errors. 2. The system may be slow to respond to the user needs as the data storage and handling of data may not be proper by the system. This can be due to improper designing of database. It can also imply that the tables may not be optimized and the indexes on the table might not be created. 3. The system may also take lot of time to respond as the front end code is not properly designed. It can be due to lots of functions or web pages calls before the data is properly stored or retrieved from the system. The code which can be either in JSP or Dot Net might not have been efficiently coded or might not have followed the standards or the optimized way of coding. All the team members working on the project will sign a Non Disclosure Agreement (NDA). This NDA binds each member working on the team not to reveal any information pertain the client to any outside party. If any case any of the team member working on the project advertently or inadvertently reveals any information which is confidential to BCML then the respective company in this case BCML have the right to end the project early. If there are any discrepancies regarding the billing of the project which can be either due to wrong estimation of time and material required or overpricing of the project then the client (BCML) have the full right to end the project early.
SOW: BCML
Page 19
If BCML is not satisfactory with the progress of the project either in the timelines met or the quality of the products delivered then BCML has the full right to discontinue the project. In any of the case if it is found that it is our fault which leads to closure of the project early then necessary compensation will be paid to BCML.
PROJECT CHANGE MANAGEMENT
Organization wide change: if the project entails a change that is as a result of the organization wide change then the Organizational Change Analyst (OCA) identifies the total impact of the change. It is the responsibility of the OCA to completely analyze the changes needed at BCML right from the business processes affected to the input output of each process. It will be the responsibility of OCA from BCML sides to clearly state and note down the change requirement in a proper change requirement document.
Throughout the change requirement we will provide a full fledged Business Analyst totally devoted to the project. The responsibility of BA will be to make the OCA understand the intricacies of the technical difficulties which the project team might face. In certain cases it may not at all be possible the changes process in a necessary software. In these circumstances the OCA will have to alter the process slightly to accommodate the technical difficulties. In case of any kind of change request the following process will be followed 1. The change request will have to be raised by BCML. It can be either raised by OCA or
any other person in charge of the project from BCML’s side 2. The change request has to be clearly explained to the business analyst from our side. The
business implication and the modules implicated have to be clearly explained so that the BA can clearly identify which modules in the software will be impacted. 3. The BA will note down the necessary details of the change request in a fixed format
followed by us. The format will be shared to BCML if need be.
SOW: BCML
Page 20
4.
The BA will then take the necessary approval either from OCA or Project Manager in
charged from BCML’s side. 5. Unless and until the sign is not taken we will not follow with the further process of
making necessary changes in the system/software. 6. Once the approval is got for the change request the necessary estimation of time and cost
will be made. The client i.e. BCML will have to allocate the extra money and time for the change request as it was not present in the sign off of the project that was done initially. 7. If suppose during the course of the change request BCML feels that further changes are
needed in any of the progressing change request then we will follow the process right from the starting state and again an approval will be taken from OCA or Project Manager from BCML. 8. For the change request the version system of Microsoft VSS will be used so that if any
changes have to be reverted back it can be done easily. The extra cost of the license to Microsoft VSS will be charged to BCML or it has to be provided by BCML. This is needed as our immense experience in IT domain has made us understand the importance of maintaining versions for a particular project. 9. At any point in time if the time of deliverable is not met as was accepted initially due to
any change request then we are not responsible for it. It can be either financially or the agreement of deadlines to BCML’s clients.
SOW: BCML
Page 21
doc_156595569.docx
This is a document about IT project of bank of baroda.
SOW: Bank of Baroda Capital Market Ltd.
IT Consulting
Contents
Project Description........................................................................................................................................ 3 Project Scope ............................................................................................................................................ 3 Project Approach: ..................................................................................................................................... 4 N-Tier Architecture ............................................................................................................................... 4 Our Responsibilities ...................................................................................................................................... 5 Deliverables............................................................................................................................................... 6 Assumptions .......................................................................................................................................... 7 Your responsibilities .................................................................................................................................. 8 Assumptions .......................................................................................................................................... 8 Estimated Schedule & Timelines................................................................................................................... 9 Acceptance Process for project deliverables .............................................................................................. 10 Acceptance Criteria for Milestones and Deliverables............................................................................. 11 Resource Planning and Costing: .................................................................................................................. 16 Costing .................................................................................................................................................... 18 Phase wise Costing .............................................................................................................................. 18 Ending Project Early .................................................................................................................................... 19 Project Change Management ..................................................................................................................... 20
SOW: BCML
Page 2
PROJECT DESCRIPTION
Bank of Baroda Capital Markets Ltd. (BCML) is a fully owned subsidiary of Bank of Baroda one of the largest public sector Bank in India with a Branch network of over 2800 branches in India and 25 other overseas countries. BCML is engaged in Merchant Banking, Mutual Fund Distribution and is desirous of commencing Broking business for which the company has obtained SEBI registration, through two exchanges i.e. BSE and NSE. Now, they are looking for Back Office solution provider for supply, Installation, Customization and Commission of software for carrying out broking activity. The Request for Proposal document (“RFP”) has been prepared to enable BOB Capital Markets Ltd. (BCML) in the selection of Back Office Solution Provider for Broking business of BCML. PROJECT SCOPE The selected Solution will be provided for Back Office solution for Broking Business of BCML (Based on the contents of the RFP) with standards and best practices acceptable to market, clients and regulators. BCML’S memberships to BSE & NSE are approved by respective Exchanges and SEBI’S clearance has been received. BCML has applied for Dealing in Cash Segment, Wholesale Debt Market and F&O. The BCML clearly states that the selection of Back Office Solution provider under the RFP is on the understanding that the RFP contains only the principal (or primary) provisions for the entire assignment. We will undertake all such tasks, render services required and make such resources available as may be required for the successful completion of the entire assignment at no additional costs to BCML. We will provide the details of the Platforms including (but not limited to) Hardware like Servers, Routers, Switches, Firewalls etc. and Software Licenses like Operating Systems, RDBMS (SQL/Oracle or others) and other licenses required for successful and smooth functioning of the Infrastructure.
SOW: BCML
Page 3
Indicative details of SRS (Software Requirement Specifications) are mentioned in separate Document i.e. ANNEXURE-I of the RFP. During the course of the review, we may suggest any other critical methods/improvement as deemed fit from the point of view of system provider experience for each of the SRS mentioned. However, the BCML reserves the right to change the scope of the RFP considering the size and variety of the requirements and the changing business conditions as per regulators or otherwise. PROJECT APPROACH: Keeping in mind the various elements namely performance, scalability and future development issues of the proposed project by BCML, the architecture we would be adopting is N-Tier Architecture. N-TIER ARCHITECTURE N-Tier architecture refers to the architecture of an application that has at least 3 "logical" layers - or parts -- that are separate. Each layer interacts with only the layer directly below, and has specific function that it is responsible for. Because each layer can be located on physically different servers with only minor code changes, hence they scale out and handle more server load. Also, what each layer does internally is completely hidden to other layers and this makes it possible to change or update one layer without recompiling or modifying other layers. This is a very powerful feature of n-Tier architecture, as additional features or change to a layer can be done without redeploying the whole application. An n-Tier application usually has three tiers, and they are called the presentation tier/client application layer, the business tier/business rules layer and the data tier/layer. Let's have a look at what each tier is responsible for.
SOW: BCML
Page 4
Presentation / Client application Layer Presentation Layer is the layer responsible for displaying user interface and "driving" that interface using business tier classes and objects. Business Tier/Business Rules Layer Business Tier is the layer responsible for accessing the data tier to retrieve, modify and delete data to and from the data tier and send the results to the presentation tier. This layer is also responsible for processing the data retrieved and sent to the presentation layer. Data Tier/Layer Data tier is the database or the source of the data itself.
OUR RESPONSIBILITIES
The following deliverables will be delivered on time, failing which BMCL can levy a charge of Rs.50000 per week for weeks of delay thereafter, as mentioned in the RFP.
SOW: BCML Page 5
DELIVERABLES A. Back Office Software and Support: Software will be provided which can support the required number of clients. The details of the software is given in the attached form “Functional Evaluation – Back Office Software Required Specification (SRS)”, which was part of the RFP. Support and maintenance will be provided for a period of 5 years as mentioned in the compliance certificate, subject to certain criteria like location, severity etc. (Note: the SRS is not attached in this assignment but required during actual submission of proposal since the form was given in the RFP itself)
B. Live, Implemented and Successfully Operable Application meeting the Requirements enumerated by BCML. A live, implemented and successfully operable application will be first demonstrated in selected sites, which can be installed in all the sites in a phased manner.
C. Licenses A license fee will be charged for initial number of software copies and any number of copies purchased thereafter in case the bank requires extension.
D. Application support for minimum 5 years will be provided
E. Documentations- Administrative Manual ? ? Operational Manual – Softcopy and hardcopy will be provided at the time of installation and updates and corrections will be handled in later versions. User Manual – Generic user manual will be provided along with training for selected employees who can be champions later. F. Training for –Operational Staff, Technical staff, Help Desk Personnel and others in the following areas: A detailed training will be provided to employees, which will cover the architecture, process flows, usage, handling and basic troubleshooting. The training will cover only the software
SOW: BCML
Page 6
handling and it would be fare to assume that the user have the basic functional knowledge and expertise.
G. Functional and Technical Guidance, through on site support till 6 months after going live of Retail trading. Technical and functional guidance for the software would be given but not for the functional domain specific training. The users are expected to know about banking fundamentals, capital markets and basic computing skills.
H. Development and Integration of the Interface with Front Office, BSE, NSE, Core Banking System of the Bank, Depository Software of the Bank and other software if required. Depending on the feasibility, interfaces can be developed with other front office softwares. A need based feasibility analysis can be done for each software thus identified and interfaces can be incorporated during upgrades. The cost will depend on information available, Intellectual property rights of other vendors, man hours spent t develop interface etc. For third party interfaces identified if available in market, only a consultancy fee will be charged by us. ASSUMPTIONS The following assumptions are made during the preparations of this document. 1. The project will be deployed in a phased manner across the nation and not as a big bang approach. 2. The project will have upgrades which can be charged depending on new hardware and software requirements. 3. “General terms and conditions” as given in section 1.5 of RFP will be adhered. 4. Our company should also have the right to change the team leader and team members. We would ensure that the quality will not suffer due to this. This process is to ensure that our employees get a fare chance for their career progression. 5. We assume that at no point further major changes would be made in the requirement by BCML. Minor adjustments can be managed, but major functional changes would result in a change in deadline and billable hours.
SOW: BCML Page 7
6. We can provide BCML with IP rights for any new modules developed solely for BCML but the IP rights for generic modules remain with us. Also any new ideas, patents and methods developed by our engineers during the course of this project should be evaluated and if they are generic solutions applicable in other domains also, then we would insist to have the IP rights with us. YOUR RESPONSIBILITIES The following responsibilities are expected from BCML. 1. Infrastructure requirements like space, air conditioning, networking, connectivity etc should be available in each branch. 2. The hardware and software has to be centrally procured under a single onetime payment, although transportation and installation of computers and servers in each location can be maintained by us. 3. The installation would be done in a phased manner. Payments are also expected to be only in a phased manner though not in a similar ratio. 4. We expect utmost commitment from all levels of BCML employees especially the top management. No IT project can be success without commitment from your employees. To facilitate this we expect that a project leader and project team would be assigned from your side who would constantly work alongside us during the planning, development and implementation phases. 5. We expect BCML to provide champions from each department who have enough expertise in managing computers and handling similar software. These champions would be trained and they can in turn help in training other employees. 6. We expect that while our employees are working in BCML premises, they would be treated well and their requirements would be addressed at the earliest. 7. We expect BCML to provide us with references and certificates after successful completion of the project. ASSUMPTIONS 1. We assume that BCML would follow a strict and clear evaluation and selection process for identifying the vendor for this project.
SOW: BCML Page 8
2. It would be easier for integrating multiple modules if the project is given to only one vendor. 3. We expect BCML also to adhere to the general rules and laws of the land. 4. BCML has the right to audit the progress of the project subject to a maximum of 2 times a year.
ESTIMATED SCHEDULE & TIMELINES
The following list the detailed schedule of each and every stage of the project with the duration of each stage. It is assumed that the project will start after 1 and 1/2 month from Response to RFP Due date as mentioned in RFP. Sr. No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Stage Name Concept and Feasibility Study Requirement Analysis Architecture of the System High Level Design Detail Level Design Coding Setting Development Environment Setting Test Environment Unit Testing Integration Testing System Testing User Acceptance Testing Deployment of System Document Delivery Duration (days) 20 2-Feb-09 60 20-Apr-09 20 18-May-09 20 15-Jun-09 25 20-Jul-09 40 20-Jul-09 10 3-Aug-09 10 17-Aug-09 20 14-Sep-09 10 28-Sep-09 10 12-Oct-09 15 2-Nov-09 5 9-Nov-09 5 13-Nov-09 13
Page 9
Start 7-Jan-09
Finish 31-Jan-09 17-Apr-09
Predecessors
1 15-May-09 2 12-Jun-09 3 17-Jul-09 4 11-Sep-09 4 31-Jul-09 6 14-Aug-09 6 11-Sep-09 5, 7 & 8 25-Sep-09 9 9-Oct-09 10 30-Oct-09 11 6-Nov-09 12
SOW: BCML
16-Nov-09 15 16 17 User Training Going Live Hand Holding 10 30-Nov-09 2 2-Dec-09 10
27-Nov-09 12 & 14 1-Dec-09 15 15-Dec-09 16
ACCEPTANCE PROCESS F OR PROJECT DELIVERABLES
The acceptance process for “Back Office Solution for Brokering Business” provides roadmap for incremental acceptance by Bank of Baroda Capital Market Ltd. and associated deliverables at the following key milestones.
? ? ? ? ? ?
Project Phase Concept Complete Phase Requirements Complete Phase Design Complete Phase Application Ready For Pilot Phase Application Ready For Rollout Phase Complete.
Following key deliverables are subject to acceptance within the context of above milestones. Milestone Deliverables Project Initiation and Implementation Document, Software Project Phase Concept Complete Phase Requirements Complete Phase Design Complete Project Management Plan Software Requirements Specification Template Software Design Specification Application, Software Test Plan, Software Transition Plan, Phase Application Ready For Pilot Phase Application Ready For Rollout Phase Complete Training Plan, User’s Handbook, Business Continuity Plan Application, Software Test Plan, Software Transition Plan, Training Plan, User’s Handbook, Business Continuity Plan Closeout Review, Lessons-learned
SOW: BCML
Page 10
ACCEPTANCE CRITERIA FOR MILESTONES AND DELIVERABLES The acceptance criterion in the table defines the conditions under which BCML agree and accept completion of milestones and deliverables subject to these acceptance criterions. Milestone Deliverable Acceptance Criteria Prioritized scope and high level requirements have Project Initiation and Project Phase Concept Complete Implementation Document been reviewed by the Design Team, which consists of stakeholders from BCML in addition to key members of the project team. Prioritized scope and high level requirements have been reviewed by the Design Team, which consists of Project Phase Concept Complete Software Project Management Plan stakeholders from BCML in addition to key members of the project team. The Software Requirements Specification describes what capabilities the application should have and includes:
? ? ? ? ? ?
Business Process Business Requirements Use Cases Functional Requirements Data Requirements Non Functional Requirements
The Design Team has reviewed the Specification and its prioritized requirements for correctness, completeness, and consistency with respect to BCML’s business processes and business needs within the scope established.
The application development team has reviewed the Phase Requirements Complete
SOW: BCML
Software Requirements Specification
Specification to ensure its sufficiency for beginning application design and to determine which
Page 11
requirements can be met within the constraints of the current project phase.
The software test team has reviewed the Specification to ensure that all requirements are testable. The project manager has reviewed the Specification to ensure that all requirements are traceable to the scope, goals, and objectives established The Software Design Specification describes how the application should function and be constructed to provide the capabilities defined in the Software Requirements Specification. This document includes:
? ? ? ? ? ? ? ? ?
Screen flows Screen designs Letters design Report designs Logical data model Physical data model User roles Security model Detailed system interface designs
The Design Team has reviewed the Specification for correctness, completeness, and consistency with respect to the prioritized requirements established in the Software Requirements Specification.
The business team has reviewed the specification to ensure that all requirements are fully represented in Phase Design Complete Software Design Specification the design and that the design includes no items that are not part of the established requirements.
SOW: BCML
Page 12
The application development team has reviewed the Specification to ensure its sufficiency for beginning application development and to validate the feasibility of implementing the design within the constraints of the current project phase. The software test team has reviewed the Specification to ensure that the design is testable.
The completed application will be delivered into the test environment with functionality as specified in the Software Requirements Specification, Supplemental Specification for Nonfunctional Requirements, and Software Design Specification. The completed application passed through system testing with the following results:
?
All test cases completely executed for functional modules with a system test priority ranking between 1 and 3 inclusive.
? ?
Zero severity 1* (critical) defects. Zero severity 2** (major) defects in business priority# 1 functional modules
?
No more than 2 severity 3 defects (minor) per business priority 1 functional module and no more than 20 severity 3*** defects total in business priority one functional module.
?
No more than 1 severity 2 defect per business priority 2 functional module and no more than 5 severity 2 defects total in business priority 2
Phase Application Ready For Pilot
SOW: BCML
functional modules Software Test Plan
?
No more than 5 severity 3 defects per business
Page 13
priority 2 functional module and no more than 40 severity 3 defects total in business priority 2 functional modules The User’s Handbook describes in detail the procedures for using all of the functionality provided Phase Application Ready For Pilot User’s Handbook in the application in terms understandable to the typical user. The Software Transition Plan describes the tasks and activities that need to take place to efficiently and effectively move the application from the development or test environment to the production environment and to integrate use of into the business processes of BCML.
The Plan includes deployment schedules, resource estimates, identification of special resources and staffing. The transition plan also defines management controls and reporting procedures, as well as the risks and contingencies. An impact statement outlining the potential impact of the transition to the existing Phase Application Ready For Pilot Software Transition Plan infrastructure, operations, and support staff and to the user community is also included. The Training Plan describes what training will Phase Application Ready For Pilot Training Plan provided to users to prepare them to use the application and how this training will be performed. The Business Continuity Plan describes how business Phase Application Ready For Pilot Phase Application Ready For Rollout
SOW: BCML
functions supported by will be performed in the event Business Continuity Plan that the application is unavailable for a period of time. Any application issues that the Design Team and Pilot Application users identified as needing to be addressed prior to
Page 14
rollout have been addressed.
The User’s Handbook was updated to include any Phase Application Ready For Rollout User’s Handbook changes necessary to support application changes made after the Pilot. The Software Transition Plan was updated to include Phase Application Ready For Rollout Phase Application Ready For Rollout Training Plan Software Transition Plan any changes necessitated by problems with the Pilot rollout. The Training Plan was updated to include any changes necessitated by problems with the Pilot training. The Business Continuity Plan was updated to include any changes necessitated by problems with the Phase Application Ready For Rollout Business Continuity Plan evaluation of business continuity procedures during the Pilot. All project activities and any approved change requests have been completed. All users have been trained and provided access to the application as specified in the Software Transition Phase Complete Closeout Review Plan and Training Plan.
*Severity 1, or Critical, defects include issues that result in degraded system performance beyond stated performance criteria, deny access to functionality, and/or corrupt data or display data incorrectly. ** Severity 2, or Major, defects include issues that prevent a user from correctly completing a task in the system, but can be managed by a workaround, and/or issues that promote data errors or reduce data quality substantially. *** Severity 3, or Minor, defects include issues that interfere with, but do not prevent a user from performing normal tasks.
SOW: BCML
Page 15
#Business priority refers to the business priority assigned to a functional module in the Software Requirements Specification, where priority 1 is business critical, priority 2 is moderately important, and priority 3 is optional.
RESOURCE PLANNING AND COSTING:
Project Manager (PM): The Project Manager will work with the BCML Project Manager to communicate the details of the project plan, including assignments, milestones, schedules, and budget. Role responsibilities include assigning team members to activities/tasks and monitoring team progress against the plan. The Project Manager resolves or evaluates project issues in the areas of operating policies, staffing, and project scope. The Project Manager also conducts scheduled, periodic meetings with the Project Team, Project Sponsor, and other Committee groups. This person also acts as a liaison between engineers and designers and serves as the project contact person for external (non-project) resources. Business Analyst (BA): This individual provides business representation and leadership for a core functional area impacted by the implementation and provides overall business process expertise to the project team. There may be multiple analysts assigned to a core functional area, each having ownership of a subset of core business processes. The Business Analyst attends all of the prototyping sessions where the majority of business process discovery will occur. This role serves as the liaison between the user organization and the project team Technical Lead (TL): The Technical Lead assures that the integrity of design is maintained across business processes. Technology Expert (TE): The Technology Expert designs and creates technology solutions in response to business requirements. The Technology Expert joins a project when the solution requires some specific knowledge in the emerging technologies Developer: Developer coverts the low level designs in the form of code. This individual has experience in the technology being used for implementation. Tester: This individual ensures that all the detailed test plans are created for all the business processes and tested for the same.
SOW: BCML Page 16
Elapsed Time Phase Stage Concept and Project Phase Complete Phase Requirements Complete Feasibility Study Requirement Analysis System Architecture High Level Design Low Level Design 20 1 PM, 1 TL, 1 BA 20 1 PM,1 TL, 1 BA, 2 TE 20 1 PM,1 TL, 1 BA, 2 TE 1 PM,1 TL, 1 BA, 2 TE, Phase Design Complete Coding Setting Development Environment Setting Test Environment 1 PM,1 TL, 1 BA, 2 TE, 10 5 Developers 1 PM,1 TL, 1 BA, 2 TE, 10 5 Developers 1 PM,1 TL, 1 BA, 2 TE, Unit Testing 20 5 Developers, 3 Testers 1 PM,1 TL, 1 BA, 2 TE, Integration Testing Phase Application Ready for Pilot System Testing User Acceptance Testing Deployment of System Document Phase Ready for Roll Out Delivery 10 5 Developers, 3 Testers 1 PM,1 TL, 1 BA, 2 TE, 10 5 Developers, 3 Testers 1 PM,1 TL, 1 BA, 2 TE, 15 5 Developers 1 PM,1 TL, 1 BA, 2 TE, 5 3 Developers 1 PM,1 TL, 1 BA, 2 TE, 5 3 Developers 8 8 10 13 13 13 10 10 40 5 Developers 10 3 5 5 60 1 PM, 3 BA 4 20 1 PM, 2 BA 3 (Days) Resources Total
SOW: BCML
Page 17
1 PM,1 TL, 1 BA, 1 TE, User Training 10 1 Developers 1 PM,1 TL, 1 BA, 1 TE, Go Live 2 1 Developers 1 PM,1 TL, 1 BA, 1 TE, Phase Complete Hand Holding 10 1 Developers 5 5 5
COSTING Costing for the project will be done as per the billing rates given in the following table.
Resource PM BA TL TE Developer Tester
Billing Rate (Rs Per Duration (Man Hour) Days) 1200 1150 950 850 700 650
287 427 207 352 627 120
Total Cost Total Hours (Rs) 2296 2755200 2768 3928400 1656 1573200 2816 2393600 5016 3511200 960 624000 14785600
PHASE WISE COSTING Phase Project Phase Concept Complete Phase Requirements Complete Phase Design Complete Phase Application Ready For Pilot Phase Application Ready For Rollout Phase Complete. Total Cost 560000 2232000 4848000 4704000 1588000 853600 14785600
SOW: BCML
Page 18
ENDING PROJECT EARLY
The following describes the exit criteria for both companies if the terms and conditions stated and agreed are not acceptable at later point in time. If the performance of the system is not satisfactory to BCML, the satisfaction criteria should be clearly stated before initiation of the project. Some of the criteria’s can be 1. The system may take lot of time to respond to the users input. The user input in this case can be entering of certain key data like name of the broking company, transaction amount, trading amount, etc. The system may take lot of time to save data on the server. The problem could be either because of heavy traffic on the web server due to which the data resources on the server can be clogged. This implies improper designing of the system in handling such errors. 2. The system may be slow to respond to the user needs as the data storage and handling of data may not be proper by the system. This can be due to improper designing of database. It can also imply that the tables may not be optimized and the indexes on the table might not be created. 3. The system may also take lot of time to respond as the front end code is not properly designed. It can be due to lots of functions or web pages calls before the data is properly stored or retrieved from the system. The code which can be either in JSP or Dot Net might not have been efficiently coded or might not have followed the standards or the optimized way of coding. All the team members working on the project will sign a Non Disclosure Agreement (NDA). This NDA binds each member working on the team not to reveal any information pertain the client to any outside party. If any case any of the team member working on the project advertently or inadvertently reveals any information which is confidential to BCML then the respective company in this case BCML have the right to end the project early. If there are any discrepancies regarding the billing of the project which can be either due to wrong estimation of time and material required or overpricing of the project then the client (BCML) have the full right to end the project early.
SOW: BCML
Page 19
If BCML is not satisfactory with the progress of the project either in the timelines met or the quality of the products delivered then BCML has the full right to discontinue the project. In any of the case if it is found that it is our fault which leads to closure of the project early then necessary compensation will be paid to BCML.
PROJECT CHANGE MANAGEMENT
Organization wide change: if the project entails a change that is as a result of the organization wide change then the Organizational Change Analyst (OCA) identifies the total impact of the change. It is the responsibility of the OCA to completely analyze the changes needed at BCML right from the business processes affected to the input output of each process. It will be the responsibility of OCA from BCML sides to clearly state and note down the change requirement in a proper change requirement document.
Throughout the change requirement we will provide a full fledged Business Analyst totally devoted to the project. The responsibility of BA will be to make the OCA understand the intricacies of the technical difficulties which the project team might face. In certain cases it may not at all be possible the changes process in a necessary software. In these circumstances the OCA will have to alter the process slightly to accommodate the technical difficulties. In case of any kind of change request the following process will be followed 1. The change request will have to be raised by BCML. It can be either raised by OCA or
any other person in charge of the project from BCML’s side 2. The change request has to be clearly explained to the business analyst from our side. The
business implication and the modules implicated have to be clearly explained so that the BA can clearly identify which modules in the software will be impacted. 3. The BA will note down the necessary details of the change request in a fixed format
followed by us. The format will be shared to BCML if need be.
SOW: BCML
Page 20
4.
The BA will then take the necessary approval either from OCA or Project Manager in
charged from BCML’s side. 5. Unless and until the sign is not taken we will not follow with the further process of
making necessary changes in the system/software. 6. Once the approval is got for the change request the necessary estimation of time and cost
will be made. The client i.e. BCML will have to allocate the extra money and time for the change request as it was not present in the sign off of the project that was done initially. 7. If suppose during the course of the change request BCML feels that further changes are
needed in any of the progressing change request then we will follow the process right from the starting state and again an approval will be taken from OCA or Project Manager from BCML. 8. For the change request the version system of Microsoft VSS will be used so that if any
changes have to be reverted back it can be done easily. The extra cost of the license to Microsoft VSS will be charged to BCML or it has to be provided by BCML. This is needed as our immense experience in IT domain has made us understand the importance of maintaining versions for a particular project. 9. At any point in time if the time of deliverable is not met as was accepted initially due to
any change request then we are not responsible for it. It can be either financially or the agreement of deadlines to BCML’s clients.
SOW: BCML
Page 21
doc_156595569.docx