• No results found

Merrill Lynch Team s Development Plan v.1

N/A
N/A
Protected

Academic year: 2021

Share "Merrill Lynch Team s Development Plan v.1"

Copied!
10
0
0

Loading.... (view fulltext now)

Full text

(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

non-functional 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=0.65+34/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 Component

Complexity Of Components

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

(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 = 156.42

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 156.42 * 63 = 9854.46 this is approximately 10000 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:

Type of Component

Complexity Of Components

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=60 120 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= 220.77

Once again, we use the conversional factor for Java to get the Source Lines of Code.

220.77 * 63 = 13908.51 this is approximately 14000 SLOC

So we are assuming that we will have about 10000 to 14000 SLOC. VI. 带格式的: 字体: 四号 带格式的: 字体: 四号 带格式的: 字体: 四号 删除的内容: which is approximately 10000 SLOC. 删除的内容: which is approximately 14000 SLOC

(5)

ICED-T: Data

Request by: Intuitive Consistent Efficient Durable Thoughtful

Email 3 2 2 3 3

GCDS

DSOMS 4 4 5 4 5

Their current method uses email 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 emails. 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.

(6)
(7)

Using COCOMO, we came up with the following information: Best Case Scenario – Semi-Detached

(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 8th. 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

References

Related documents

There are different models for different purposes, such as correlation models to create and evaluate a portfolio, and covariance models to forecast VaR on a daily basis for a

Merrill Lynch receives up to $100 per year for each account that sweeps to the Merrill Lynch Bank Deposit (MLBD) Program, Merrill Lynch Business Deposit Program, Merrill Lynch

In our “Present Value” estimates, we used as instruments, the fit and its one period lag of the difference of the weighted present value of the fundament (the mark-up over real

We use dis-aggregated unemployment rate data corresponding to six demographic groups: White Total, White Males, White Females, Black Total, Black Males, and Black Females.. To

DSP Merrill Lynch Liquidity Fund, DSP Merrill Lynch Liquid Plus Fund, DSP Merrill Lynch Bond Fund, DSP Merrill Lynch Floating Rate Fund, DSP Merrill Lynch Short Term Fund, DSP

conservation policies which limit drawdown of the aquifer over a sixty year planning horizon. Because the majority of the study area is in Texas, the water conservation

1.1 The kinematic viscosity-temperature charts (see Figs. 1 and 2 ) covered by this standard are a convenient means to ascertain the kinematic viscosity of a petroleum oil or

Reducing early school leaving is amongst the investment priorities of the European Social Fund, which Member States can use to develop policies in line with the integrated