Merrill Lynch Team s Development Plan v.1

Transcription

1 Merrill Lynch Team s Development Plan v.1 *** Score 100/100 yet I feel that there is more to the story. The next issue needs to be more specific on the architecture. As I manager I would assume that this project is doing well and be furious if problems came up in March and April that could have been identified in January. I. The purpose of this project is to create a Customer Relationship Management tool, or CRM, for internal users of the Global Client & Data Services data. It will allow Global Client & Data Services to better understand and service their clients through tracking of data being used by different clients of Merrill Lynch. II: The goal of this project is to reduce the time spent requesting and fulfilling customer s requests for data. There was not a quantitative number given for the time reduced. III: Team members: Kressley A. Dahll Project Manager Dan Stier Project Architect David E. Barker Ian Parks Ilan Pollak John Jungmin Lee Keith J. Glennon Marc Lee Hardik Mehta Murshed Choudhury Management Plan: Save for the Project Manager and the Project Architect, the team is broken into three groups: Database Management, Data

2 Request and Data Fulfillment. The Database Management team is responsible for maintaining the current database of the information, creating the database needed for our CRM, and any queries. The Data Request team is responsible for the GUI and logic required for requesting data from GCDS. The Data Fulfillment team is responsible for the GUI and logic required for GCDS to fulfill the customer s request of the data. The Project Manager is responsible for communication with Merrill Lynch, defining and documenting the Development Process, making trade-offs among features, schedule, development cost and quality. The Project Manager also chairs the project meetings, assigns and tracks action items, and communicates any changes to the aforementioned to the rest of the team. The Software Architect is responsible for assuring that the requirements are valid and quantitative. He also defines nonfunctional requirements, components, and interface structures. He also acts as a liaison between the groups to insure that there is fluidity between the different teams. IV: There are three main requirements for this project: search functionality, the ability to update fields, and handling data requests. The search functionality has to allow the user to search by organizational alignment, like business unit, group/department, and application name, and delivery information, like service name, data object name and delivery type. For the ability to update fields, all records have to be modifiable. This includes adding new records, modifying existing records, and deleting records. The main functionality of this project is to handle data requests. These have to able to be viewed and accepted through various stages in the workflow. V. Using the Function points formula (FP=(UFP)(VAF)), we made our FPA. First, we needed to determine the VAF.

3 We used the 14 General System Characteristics (GSC) to get the value to compute the VAF. We used Wideband Delphi to determine the values in the GSC with our architect and the remainder of the group. This is our GSC: Data Communication 3 Distributed Data Processing 1 Performance 2 Heavily Used Configuration 0 Transaction Rate 5 Online Data Entry 5 End-User Efficiency 5 Online Update 4 Complex Processing 0 Reusability 5 Installation Ease 1 Operational Ease 1 Multiple Sites 0 Facilitate Change 2 Total= 34 Then with this information, we calculated the VAF VAF= /100=0.99 Then we separated the components of the architecture that we had and determined whether they were External Inputs (EI), External Outputs (EO), External Inquires (EQ), Internal Logical Files (ILF), and External Interface Files (EIF). Using the worksheet on pg 180 of TSQTE, we determined the UFP by using the table. This is our UFP result for a best case scenario: Type of Complexity Of Components Component Low Average High Total EI 5*3=15 2*4=8 0*6=0 23 EO 6*4=24 3*5=15 0*7=0 39 EQ 1*3=3 1*4=4 0*6=0 7

4 ILF 6*7=42 4*10=40 0*15=0 82 EIF 0*5=0 1*7=7 0*10=0 7 UAF=158 With the VAF and the UAF, we can calculate the function points for our best case scenario. FP=0.99 * 158 = Since we are coding in Java, we used the conversional factor for Java which is 63 and multiplied it by the Function points. *** Use UAF to avoid double counting complexity * 63 = this is approximately SLOC. In our worst case scenario, we used the same method to get the UFP in our best case using the same worksheet. This is the UAF result for the worst case scenario: 删 除 的 内 容 : which is approximately SLOC. Type of Complexity Of Components Component Low Average High Total EI 0*3=0 5*4=20 2*6=12 32 EO 0*4=0 6*5=30 3*7=21 51 EQ 0*3=0 1*4=4 1*6=6 10 ILF 0*7=0 6*10=60 4*15= EIF 0*5=0 0*7=0 1*10=10 10 UAF=223 Then we calculated the FP using the same formula: FP= 0.99 * 223= Once again, we use the conversional factor for Java to get the Source Lines of Code * 63 = this is approximately SLOC So we are assuming that we will have about to SLOC. 删 除 的 内 容 : which is approximately SLOC VI.

5 ICED-T: Data Request by: Intuitive Consistent Efficient Durable Thoughtful GCDS DSOMS Their current method uses as a form of communication between their customers and themselves. This is not a good method because it is slow, and communication can be broken down through many s. It is also hard to keep track of who has ordered what information in the past. With our program, they will be able to communicate and serve their customers in a much more organized and precise fashion. It will also allow them to track information in the past, so they can better help their customers in the future. VII.

6

7 Using COCOMO, we came up with the following information: Best Case Scenario Semi-Detached E = 3.0(10) 1.12 = 39.5

8 D = 2.5(39.5) 0.35 = 9.1 P = 39.5 / 9.1 = 4.34 Worse Case Scenario Semi-Detached E = 3.0(14) 1.12 = 57.6 D = 2.5(57.6) 0.35 = 10.3 P = 57.6 / 10.3 = 5.6 From our analysis, we are within our estimations because we have more people than recommended. **See attached Gantt Chart for full chart** VIII. Summary: The following document outlines the testing plan our group will take to ensure software that is as bug free as possible. The key limitation to our testing will be that there will be only limited opportunities to test the application in the environment it will be run in. Despite this we will Endeavour to provide well developed, easy to read, bug free code to the best of our abilities. Scope Testing will be handled first individually by the team developers. After developers submit working versions of their modules to the project manager and architect, they will be integrated into a more complete version of the project and tested by the project manager and architect. By limiting the amount of coupling between individual developer modules testing should remain simple, and not require significant testing during integration. Deliverables Deliverables include a test single sign on program, to be compiled and run by Merrill Lynch to test our implementation of

9 single sign on. We plan to provide a staging version of the application to Merrill Lynch April 8 th. As development progresses we plan to send Merrill Lynch screenshots or power point presentations of what the screens of the application will look like and how they work. We plan to deliver an updated database schema on Jan 31 for review. Release Criteria The primary criteria for release will be a generally complete application tested for all known use cases in the development environment. The HR sync process and the single sign on module s status will not affect release criteria, these two pieces are considered separate. While both were important requests made by Merrill Lynch, these are not show stoppers, and the bulk of the application can function without them. Risks and Contingencies The primary risk is that the application will fail to work in the Merrill Lynch environment. This had been mitigated by developing in Merrill s preferred language, Java, using their preferred web server, Apache Tomcat, and using their preferred version of Oracle database. By keeping the development environments as close to Merrill s production environments as possible the risk should be minimal, but there are no contingencies. There are further risks, however; the standalone server we have to write to synchronize and alert from the HR database will have very limited testing opportunities. We have the correct version and schema information, but again, without the ability to test this application in a production environment there is considerable risk here, and we have no contingencies, if our implementation does not work.

10 The largest risk associated with this project is the single-sign on module, requested by Merrill Lynch. We will not receive any information about the Merrill LDAP system, meaning that our testing will likely be using a different version of the LDAP software, and will be given only limited knowledge of their schema. As a contingency to single sign on, we will include in the application a simple database controlled login. Testing Use Cases Our testing will include the ability to: Create/Edit Subscription Requests for new projects Create/Edit Subscription Requests for current projects Create/Edit Tracking Requests for projects Browse Entire Software Catalog Use catalog to pre-fill fields for Subscription Requests View All Reports Filter all filterable grids on any/all filters Create/Edit Applications Create/Edit/Deactivate Contacts Associate Contacts with Applications Associate Contacts with Project and Requests