In House Software Development:

1
In House Software Development

• Verner, etal
• IEEE Software, Jan?feb 2005

2
The Survey
This set of questionnaires included descriptions
of 80 unique projects. In total, we surveyed 101
respondents about 122 projects. Our sample wasnt
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.
3
PM program managers
Although youd expect software development
projects to have PMs, five percent of our sample
projects didnt. 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.
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,
successful project managers are generalists,
not technical specialists.
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 werent necessarily due to using UML.
6
Iterative Rework the Good, the Bad, and the Ugly

• Fairley, etal.
• IEEE Computer, Sep 2005

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).
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
projects early stages. Less frequent reporting
and analysis is appropriate once rework
stabilizes and remains within the desired range.
9
Earned Value

• SOS section 3.7

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.

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

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

13
Progress Measures

• Earned Value(EV) BCWP/BAC
• the sum of the PVs 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

14
Example as of 4/1/05
 
15
TTYP1 2 or 3 people

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

16
Tuesday, Jan 24 - OCL

• Read SOS ch 14 and look at OCL spec.
• Bring OCL 2.0 spec to class(pp1-60)