Software Project Management

1
Software Project Management

• Lecture 14

2
Lecture Outline

• Remaining topics from Chapter 26
• Software Reliability
• Software Failure
• Measures of Reliability Availability
• Software Safety
• Quality Standards
• ISO 9000
• CMM
• SQA Plan

3
Software Reliability

• Definition
• The probability of failure free operation of a
  computer program in a specified environment for a
  specified time.
• Reliability is the probability of not failing in
  a specified length of time

4
Software Reliability (Contd.)

• Mathematical representation
• F(n) 1 - R(n)
• Where,
• R(n) probability of reliability (i.e. not
  failing)
• n no. of time units,
• if time unit is assumed in days then probability
  of not failing in 1 day is R(1)
• F(n) probability of failing in a specified
  length of time

5
Software Reliability (Contd.)

• It is a quality factor that can be directly
  measured and estimated using historical
  development data.
• It measures how often s/w encounters a data input
  or other condition that it does not correctly
  process to produce correct answer
• If programX has reliability of 0.96 (over 8
  processing hours) then it means, if programX runs
  100 times it will operate correctly 96 times

6
Failure

• Non-conformance to s/w requirements leads to
  failures
• Negative results or in worst case no output is
  failure
• Some failures can be corrected in seconds, some
  in weeks and others in months
• One failure may introduce other errors (in effect
  other failures)

7
Measures of Reliability Availability

• Early work in software reliability attempted to
  extrapolate the mathematics of hardware
  reliability theory to prediction of software
  reliability. But,
• Most hardware reliability models have predicted
  on failure occur due to physical wear (corrosion
  effects, shock, temperature, etc.) rather than
  design defects.
• The opposite is true for softwares. All software
  failures can be traced to design or
  implementation problems.

8
Measures of Reliability Availability

• Measure of Reliability
• Consider a computer-based system.
• A simple measure of reliability for such a system
  is mean-time-between-failure (MTBF)
• MTBF MTTF MTTR
• MTTF Mean-time-to-failure
• MTTR Mean-time-to-repair
• Many researchers argue that MTBF is more useful
  term than defects/KLOC or defects/FP as user is
  more concerned with failure rate as compared to
  defect count.
• Each defect does not have same failure rate and
  the total defect count gives little indication of
  the reliability of a system.

9
Measures of Reliability Availability

• Measure of Availability
• Software availability is the probability that a
  program is operating according to requirements at
  a given point in time.
• It is defined as
• Availability MTTF / (MTTF MTTR) 100
• Availability measure is sensitive to MTTR

10
Software Safety

• This SQA activity focuses on identification
  assessment of potential hazards that may affect
  software negatively cause an entire system to
  fail.
• Early identification of hazards can help to have
  design features that either eliminate or control
  potential hazards.
• A modeling analysis process is conducted as
  part of s/w safety.
• Initially hazards identified categorized by
  criticality risk
• Next analysis techniques are used to assign
  severity probability of occurrence (similar to
  risk analysis methods but different as the
  emphasis in this case is on technology issues
  rather than project )

11
Software Safety (Contd.)

• The following analysis techniques can be used
• Fault tree analysis
• Real-time logic
• Petri Net model
• After hazards identification analysis, the next
  step is to specify safety related requirements,
  i.e., to find
• A list of undesirable events the desired system
  responses to these events
• Role of s/w in managing undesirable events is
  then indicated

12
The ISO 9000 Quality Standard

• A quality assurance system may be defined as the
  organizational structure, responsibilities,
  procedures, processes, resources for
  implementing quality management.
• ISO 9000 describes a quality assurance system in
  generic terms that can be applied to any business
  regardless of the products services offered.

13
Getting Certified

• To become registered to one of the quality
  assurance system models contained in ISO 9000, a
  companys quality system operations are
  scrutinized by third-party auditors for
  compliance to the standard for effective
  operation.
• Upon successful registration, the company is
  issued a certificate from a registration body
  represented by the auditors.
• Semi-annual surveillance audits ensure continued
  compliance to the standard.

14
ISO 90012000

• ISO 90012000 is the quality assurance standard
  that applies to software engineering.
• The ISO 90012000 standard contains 20
  requirements.
• For a software organization to become registered
  to this standard, it must establish policies
  procedures to address each of these requirements
• As ISO 90012000 standard is applicable to all
  engg. disciplines, a special set of ISO
  guidelines (ISO 9000-3) have been developed for
  use in software process.

15
Capability Maturity Model

• It is a model of the maturity of the capability
  of certain business processes.
• A maturity model can be described as a
  structured collection of elements that
• describe certain aspects of maturity in an
  organization, and
• aids in the definition and understanding of an
  organization's processes.
• CMM was originally developed as a tool for
  objectively assessing the ability of government
  contractors' processes (to perform a contracted
  software project).

16
Capability Maturity Model

• The Capability Maturity Model is based on the
  Process Maturity Framework first described in the
  1989 book "Managing the Software Process" by
  Watts Humphrey.
• Humphrey based this framework on the earlier
  Quality Maturity Grid developed by Phil Crosby in
  his book "Quality Is Free".
• However, Humphrey's approach differed because of
  his unique insight that organizations mature
  their processes in stages based on solving
  process problems in a specific order.
• Humphrey based his approach on the staged
  evolution of a system of software development
  practices within an organization, rather than
  measuring the maturity of each separate
  development process independently.

17
Capability Maturity Model

• The model identifies 5-levels of process maturity
  for an organization
• Level 1 - Ad hoc (Chaotic)
• At this level, the processes are (typically)
  undocumented and in a state of dynamic change,
  tending to be driven in an ad hoc, uncontrolled
  and reactive manner by users or events. This
  provides a chaotic or unstable environment for
  the processes.
• Level 2 - Repeatable
• At this level, some processes are repeatable,
  possibly with consistent results. Process
  discipline is unlikely to be rigorous, but where
  it exists it may help to ensure that existing
  processes are maintained during times of stress.

18
Capability Maturity Model

• Level 3 - Defined
• At this level, there are sets of defined and
  documented standard processes established and
  subject to some degree of improvement over time.
  These standard processes are in place (i.e., they
  are the AS-IS processes) and used to establish
  consistency of process performance across the
  organization.
• Level 4 - Managed
• At this level, using process metrics, management
  can effectively control the AS-IS process (e.g.,
  for software development ). In particular,
  management can identify ways to adjust and adapt
  the process to particular projects without
  measurable losses of quality or deviations from
  specifications. Process Capability is established
  from this level.
• Level 5 - Optimizing
• At this level the focus is on continually
  improving process performance through both
  incremental and innovative technological
  changes/improvements.

19

• Link to lecture14b
• D\oldD\MyWorkPlace\Lectures_others\SPM\SPM2010\Le
  cture14.ppt

20
The SQA Plan

• Provides a roadmap for establishing SQA
• Developed by SQA group (or software team if SQA
  group does not exist)
• A standard structure for SQA plans by IEEE
  recommends the following
• Scope purpose of the plan.
• Description of all s/w engg. work products that
  fall within range of SQA.
• All applicable standards practices that are
  applied during the software process.

21
The SQA Plan

• SQA actions tasks (including reviews audits)
  and their placement throughout the software
  process.
• Tools and methods that support SQA actions
  tasks.
• Software configuration management procedures for
  managing change.
• Methods for assembling, safeguarding, and
  maintaining all SQA-related records.
• Organizational roles and responsibilities
  relative to product quality