This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
PmHome
>
MetricsHome
>
MetricsMeetings
>
MetricsMeeting20090421
(21 Apr 2009,
ArthurRyman
)
(raw view)
---+ Estimation Telecon, 2009-04-21 %TOC% See [[MetricsMeetings][Estimation and Measurement Meetings]] for meeting logistics. ---++ Agenda and Minutes ---+++ Attendees ArthurRyman, LawrencePutnamJr, Jim Koslow, AndyBerner, PeterHaumer, StevePitschke, MurrayCantor, ScottBosworth, VikrantKaulgud, LeeFischman ---+++ 1. Introductions Since this is our first telecon, let's take a few minutes to introduce ourselves. --- * Larry - QSM, interested in integrating QSM estimation tools with other develop tools, e.g. from IBM Rational * Jim - Galorath, business alliance manager, also interested in integration * Andy - IBM Rational lead architect for ISV enablement * Peter - IBM Rational lead architect for Measured Capability Improvement Framework (MCIF), interested in control framework * Steve - IBM Rational dev lead for integration of ISV estimation tools with new project management tool * Murray - IBM Rational lead for Governance solution, member of CTO team * Scott - IBM Rational lead for OSLC, member of CTO team * Vikrant - Accenture, interested in project management, estimation, data mining of development tools * Arthur - IBM Rational, chief architect for Project and Portfolio Management, will lead this workgroup initially * Lee - Galorath, will act as point of contact for Galorath Arthur is initiating this workgroup, but it should not be viewed as an IBM-run workgroup. Looking for co-leaders. Larry volunteered to co-lead. ---+++ 2. Workgroup Goals Let's discuss our goals and establish a plan for the workgroup. --- The primary goal is to define services that enable the integration of estimation tools with other development tools in order to support the key use cases that have been identified and agreed to. In general, service interfaces could be defined on both the estimation tools and the development tools. However, as an initial simplification, we'll adopt an architecture where the development tools provide the services and the estimation tools act as clients to those services. Our target is to have initial implementations this year. However, the specifications may not be final. Product support statements are independent of the level of maturity of the specifications at OSLC, e.g. a product may elect to support a draft spec or may decline to support a final spec. ---+++ 3. Use Case Prioritization We have several [[MetricsUseCases][use cases]] proposed. Are there more? Let's prioritize the list. --- We reviewed the four use cases: Initiating, Monitoring and Controlling, Re-estimating, and Closing. There was general agreement that these were the main use cases. During the discussion it became apparent that we should also include a Calibrating use case to bootstrap the models before they are used for new projects. Calibrating entails mining data for the historic project records of an organization. *ACTION*: Arthur to add a use case for Calibrating. *DONE* 2009-04-21 Murray raised some additional use cases that dealt with an orginizations ability to use estimates, and to analyse their overall improvements over time across mulitple projects. *ACTION*: Murray to add these additional uses cases for discussion at future telecons. There was agreement that the Monitoring and Controlling use case be given the highest priority since the ability to control projects has high value. In order to proceed on this, we should gather information about which metrics are most useful. The following general categories were identified: * size * schedule * effort * defects This leads into our next topic since we should adopt standard definitions for these metrics where they exist. *ACTION*: Each estimation vendor should identify the most useful metrics for project control and record them on a wiki page. There was some concern over using the wiki since many workgroup memberslack experience. In order to get over the learning curve, Arthur and Scott volunteered to provide 1-1 coaching. Arthur will create pages for each vendor. *ACTION*: Arthur to create a software metrics page for each vendor. *DONE* 2009-04-21. See MetricsAccenture, MetricsGalorath, MetricsQSM, MetricsPriceSystems. ---+++ 4. Applicable Standards Are there any applicable standards we can use, e.g. to define metrics or project properties? --- We need to all agree on the definition of software metrics since we are exchanging data. We should cite applicable standards if they exist, e.g. from IEEE or SEI. If no standard exists, we'll supply our own definitions here. *ACTION*: Each estimation vendor should cite any applicable standards in their list of key software metrics. ---+++ 5. Information Model Arthur posted a draft [[http://open-services.net/software-metrics/Estimation/default.htm][information model]] to establish concepts. You can download it as a [[http://open-services.net/software-metrics/Estimation.zip][zip]]. See also [[MetricsModel]]. --- Timed out here. ---+++ Next week Expand the Monitoring and Controlling use case. What do estimation tool users do? ---++ Comments Add your comments here: %COMMENT%
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r4 - 21 Apr 2009 - 19:45:36 -
ArthurRyman
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback