ev3 1 In House Software Development:… Verner, etal IEEE Software, Jan?feb 2005

ev3 2 The Survey This set of questionnaires included descriptions of 80 unique projects. In total, we surveyed 101 respondents about 122 projects. Our sample wasn’t random, but rather a convenience sample of practitioners we know. Of all the projects in the survey, the respondents regarded 62 percent as successful and 38 percent as unsuccessful. Eighty- seven percent were development projects (55 percent successful), and 13 percent were large (in terms of effort) maintenance or enhancement projects (60 percent successful). Overall, 64 percent of our projects had nine or fewer full-time employees, 27 percent had between 10 and 19, and the rest had 20 or more, with a median of eight.

ev3 3 PM – program managers Although you’d expect software development projects to have PMs, five percent of our sample projects didn’t. Most of these projects were small, with fewer than seven full-time personnel equivalents. However, one failed project with 100 internal practitioners and 25 contractors had no PM. In 16 percent of the projects, the PM changed at least once. This volatility, practitioners reported, was very disruptive. The largest project in our survey had 80 internal practitioners and 100 contractors, and the PM was changed; the practitioners viewed it as a failure. For all projects, changing the PM was significantly negatively correlated with project success.

ev3 4 PM background Neither a PM with a software development background (M14) nor one experienced in the application area (M2) was significantly associated with project success. This result agrees with observations that a broad background is more useful than expertise in any particular technical area. According to Jaak Jurison, “[s]uccessful project managers are generalists, not technical specialists.”

ev3 5 Requirements Among the 46 percent of respondents who knew about requirements gathering, four projects used prototyping and nine used JAD (joint application design) sessions with prototyping. Eleven of these 13 projects were successful. Interviews and focus groups were the remaining projects’ main requirements-gathering methods. Eight projects used UML to document requirements, but only three of these were successful. Practitioners commented that there were “too many new things without a pilot” and “unfamiliar methods.” However, the failed UML projects had other problems such as poor estimates and no risk management, so their failures weren’t necessarily due to using UML.

ev3 6 Iterative Rework: the Good, the Bad, and the Ugly Fairley, etal. IEEE Computer, Sep 2005

ev3 7 Rework Incremental build lets developers produce weekly builds of an evolving product. Each iteration involves a certain amount of rework to enhance and fix existing capabilities (the good). However, excessive rework could indicate problems in the requirements, the developers’ skills and motivation, the development processes or technology used, or all of the above (the bad). Exorbitant levels of rework result in truly untenable situations (the ugly).

ev3 8 Amount of rework For several years, our rule of thumb has been that total rework (evolutionary plus both types of avoidable) is acceptable at 10 to 20 percent of the total effort for each reporting period in an iterative development process. The reporting period typically varies from a week to a month. Weekly analysis of rework data is desirable in a project’s early stages. Less frequent reporting and analysis is appropriate once rework stabilizes and remains within the desired range.

ev3 9 Earned Value SOS section 3.7

ev3 10 Earned Value Analysis One approach to measuring progress in a software project is to calculate how much has been accomplished. This is called earned value analysis. It is basically the percentage of the estimated time that has been completed. Additional measures can be calculated. Although this is based on estimated effort, it could be based on any quantity that can be estimated and is related to progress.

ev3 11 Basic Measures - 1 Budgeted Cost of Work (BCW): the estimated effort for each work task. Budgeted Cost of Work Scheduled (BCWS): the sum of the estimated effort for each work task that was scheduled to be completed by the specified time. Budget at Completion (BAC): the total of the BCWS and thus the estimate of the total effort for the project

ev3 12 Basic Measures - 2 Planned Value (PV): the percentage of the total estimated effort that is assigned to a particular work task. PV = BCW/BAC Budgeted Cost of Work Performed (BCWP): the sum of the estimated efforts for the work tasks that have been completed by the specified time. Actual Cost of Work Performed (ACWP): the sum of the actual efforts for the work tasks that have been completed

ev3 13 Progress Measures Earned Value(EV)= BCWP/BAC the sum of the PV’s for all completed work tasks Schedule Performance Index (SPI) = BCWP/BCWS Schedule Variance (SV) = BCWP – BCWS Cost Performance Index (CPI) = BCWP/ACWP Cost Variance (CV) = BCWP – ACWP

ev3 14 Example – as of 4/1/05 taskEst effort Actual effort Est Comp Date Actual Date Comp 15101/25/052/1/ /15/ /15/ /15/054/1/ /1/ /01/05

ev3 15 TTYP1 – 2 or 3 people u Use the data from slide 6. Assume that the rest of the tasks finish 1 month late. u Calculate EV, SPI, SV, CPI, and CV at half month intervals from Jan 1 through the finish of the project. u Plot the values as line graphs. Turn in hard copy of the spreadsheet and the graphs. u 15 points

ev3 16 Tuesday, Jan 24 - OCL Read SOS ch 14 and look at OCL spec. Bring OCL 2.0 spec to class(pp1-60)