Managing Quality and Productivity Risks in Software Projects Real Life Experiences

1
Managing Quality and Productivity Risks in
Software Projects - Real Life Experiences
MR. AMITAVA BANERJEE
SQC OR Unit, ISI, Kolkata bamitava_at_isical.ac.in,
amitava_banerjee2001_at_yahoo.com
2
Content

• Current system of project and risk management
• Problems of software development
• New approach to project and risk management
• Technical control and improvement
• Understanding SLA
• Winning customer confidence
• Measurement of productivity

3
System of Project and Risk Management

• Project plan is a set of tasks with estimated
  timeline / effort.
• This is more a wish-list than a plan.
  (Planning is a set of
• activities aimed at controlling the future)
• Note A plan is incomplete without specific
  quality goals. A
• plan should also specify alternatives

4
System of Project and Risk Management (Continued)

• Project control is based on only output variables
  like
• schedule, effort, defects etc. These cannot be
  
• controlled directly
• The limits of variability for control are usually
  arbitrary
• and rather tight. This increases the frequency
  of root
• cause analyses
• Note Control should be on the basis of actual
• variability rather than arbitrary limits.
  Control should be
• based on internal characteristics

5
System of Project and Risk Management (Continued)

• The root cause analyses are usually explanations
  rather than
• fundamental causes. How many examples of RCA
  do you
• remember where you have found some
  fundamental issue
• and corrected the same? How many times your
  findings were
• existence of typical problems like unclear
  requirements, non-
• availability of skill, time pressure and the
  like?
• Note Contrary to popular belief the frequency of
  RCA should
• be decreased rather than increased

6
System of Project and Risk Management (Continued)

• Quality of software is equated to functional
  correctness only. Other internal parameters like
  extensibility are rarely covered
• Defects are typically classified in terms of
  severity. Technical reasons for defects are often
  unknown and hence improvements are hard to come
  by
• Note As long as technical reasons for defects
  are not known skill improvement is an impossible
  task

7
System of Project and Risk Management (Continued)

• Identified risks are often constraints (e.g.
  on-availability of
• skill)
• Size, schedule, scope creep and quality risks are
  often not
• tied up with technical characteristics of the
  software
• Customer and contract related risks are not
  quantified

8
System of Project and Risk Management (Continued)

• Applications taken over for maintenance are often
  
• not understood properly. (Would it be prudent
  to
• refactor the application? Can applications be
• combined?)
• Note It is essential to identify the potential
• dangers and plan development accordingly. It
  is
• also important to ensure that only important
  risks
• are tackled.

9
System of Project and Risk Management (Continued)

• The Service Level Agreements (SLA) agreed upon
  are often
• infeasible - even from an arithmetic
  perspective
• The risks associated with SLA are often not
  understood from
• a quantitative perspective - in particular
  for turn around time
• Note It is important to understand the
  variability of ticket
• arrival as well as the variability of effort
  required to service
• tickets

10
System of Project and Risk Management (Summary)

• Lack of understanding of planning
• Confusion between risk and constraints
• Failure to appreciate variability
• Frequent RCA
• Controlling on output variables only
• Failure to classify defects technically
• Not identifying skill requirements correctly
• Failure to link complexity and plan
• Not being able to quantify threats
• Not understanding implications of SLA

11
Problems of Software Development

• Three major areas
• At a technical level
• Containing complexity
• Identification of right skill
• At a managerial level
• Appreciation of variability
• Identification of right measurements
• At customer level (may be a combination of the
  above)
• Measurement of level of relationship
• Identification and quantification of threats

12
Technical Control (Planning / Improvement)

• Complexity of software depends on
• Level of coupling and cohesiveness
• Module / package / class size
• Structural (path) complexity
• Usage of risky constructs (e.g pointer
  arithmetic, bit
• level operations)
• Non-usage of standard analysis models

13
Technical Control (Planning / Improvement)

• Most of these parameters can be determined at the
  design stage
• The control steps are
• Assess complexity of modules (Use size and other
• measures)
• Ensure that the complex modules are developed /
• tested early
• Introduce control on the defined internal
• characteristics
• Set improvement targets on internal
  characteristics

14
Using RCA Judiciously

• Measure actual variability of effort, turn around
  time, productivity, number of defects etc.
• If you do not have adequate data, collect the
  same on campaign basis. In case you have limited
  number of projects, collect data on module /
  class basis and roll up.

15
Using RCA Judiciously

• Use stratification methodologies to reduce
  variability. Useful stratification variables are
• Size
• Language level
• Extent of code domination
• Use RCA only when the statistical limits are
  violated
• Do not panic if these limits are large. There is
  no point aiming at narrow limits without
  understanding the reasons for variability

16
Reduction of Impact of Skill

• Categorize defects from technical perspective
  (use IEEE standards / Bug patterns of Java)
• Use tools to identify risky constructs and
  correlate the same with defects
• Introduce training programmes on specific
  technical defect / code quality / design quality

17
Reduction of Impact of Skill

• For performance critical applications ensure
  usage of optimal indexing schemes as well as
  optimization of schema / normalization schemes.
  Collect data on impact of various indexing /
  normalization schemes for different types of
  queries as well as tables of different sizes.
  Prepare clear on-line guides

18
Understanding SLA

• In many cases SLA are defined in percentage
  terms. Ensure that you have adequate sample size
  for the same
• In case sample sizes are low, negotiate for
  continuous measures rather than percentage
  compliance
• Collect data on arrival and service time for
  individual tickets. Understand the variability in
  these areas

19
Understanding SLA

• In case you do not have data on individual
  tickets, estimate
• extreme values of effort assuming log normal
  distribution
• Make sure you understand the effort that is
  necessarily
• required.
• Do not compute the manpower requirement on the
  basis of
• average values only. Ensure that the extreme
  cases have
• been taken care of

20
Winning Customer Confidence

• Ensure adequate testing of risky modules. Ensure
  minimum
• coverage criteria are met
• Look at extensibility of software being
  developed. Ensure a
• minimum level of extensibility so as to reduce
  total cost to
• customer
• Look at ways and means of combining applications
• Work out the onsite - offshore effort mix on the
  basis of
• actual arrival and service time. This is
  likely to have very
• high cost impact

21
Improvement of Productivity

• The largest advantage of Indian IT industries is
  productivity
• Lack of extensibility is one major cause of lower
  productivity
• Increase design effort and introduce formal
  design
• methodologies for improvement of productivity
• Introduce appropriate measures of size -
  particularly in
• maintenance / production support /
  infrastructural support
• areas

22
Way Forward

• Step 1
• Introduce statistical control systems and reduce
  RCA
• Introduce formal design methodologies
• Start measuring internal parameters and try to
  improve
• Start collecting ticket-by-ticket data and
  estimate manpower/
• onsite - offshore effort ratio accordingly
• Whenever possible move to continuous measures

23
Way Forward

• Step 2
• Develop models to understand defect / change
  proneness
• of modules
• Link development plans with module size /
  complexity
• Start capturing defect data from technical
  perspective

24
Way Forward

• Step 3
• Compile defect data and identify patterns from
  technical
• perspectives
• Identify tools and start using to reduce
  occurrence of risky
• constructs
• Star using models to improve extensibility
• Estimate effort for routine activities in
  maintenance
• environment
• Estimate fat in the system

25
Way Forward

• Step 4
• Introduce formal testing (ensure minimum
  coverage)
• Ensure testing of all risky modules
• Star optimizing effort mix
• Start collecting data on arrival pattern of
  enhancement
• requirements

26
Way Forward

• Step 5
• Combine applications to reduce costs
• Work towards minimization of fat in the system
• Automate reviews to the extent possible
• Introduce skill development in appropriate
  technical areas

27
Thank You