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
带格式的: 字体: 四号
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.
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
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
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.
Using COCOMO, we came up with the following information: Best Case Scenario – Semi-Detached
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
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.
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