They Don

1
They Dont Care About Quality

• Kathy Iberle
• Hewlett-Packard
• 18110 SE 34th Street
• Vancouver, WA 98683
• Kathy_Iberle_at_hp.com
• www.kiberle.com

CAMT Version
2
Content

• Introduction
• What is quality ?
• Practice Culture
• Business Models
• Aspects of Reality
• An example
• Fears

3
Introduction

• What is Quality ?
• Value to some person (Weinberg)
• Two examples
• Development of defibrillators and cardiographs
• Driving factor Responsibility for human lives
• Could harm a patient or operator
• Avoid legal liability or FDA investigation
• Values correctness and reliability
• Development of consumer product ( e.g. printer)
• Fear of missing the dates, having confused
  users or unexpected software/hardware
  incompatibilities
• Values usability and compatibility

4
Practice Culture

• Groups of software practitioners who share common
  definitions of quality and tend to use similar
  practices
• Most individuals live in one practice culture and
  have learned the beliefs and practices of that
  particular culture.
• People in similar businesses often share a
  practice culture
• e.g. aerospace, finance, medical domain.
• Practice cultures also cut across businesses
• More than one practice culture can appear in the
  same company
• e.g. Software Engineering versus IT Support

5
Practice Culture

• Issues to look at
• What assumptions does this practice culture make?
• How do those assumptions lead to best practices
  
• That is, practices that are favored within that
  practice culture?
• Are there best practices that dont appear to
  follow logically from the assumptions?
• This suggests that there are assumptions unknown
  to you.
• Do any of the assumptions involve factors that
  have changed in the last few years?

6
Important Aspects of Reality

• Type of product
• Business software, firmware, games.
• Criticality
• life-critical, business-critical, merely
  annoying.
• Market
• Early adopters, mainstream.
• Range of environments
• corporate common operating environment,
  household PCs, U.S. only, worldwide.

7
Most Important Reality

• Follow the Money
• Business Model
• Loosing money - Cost of fixing errors
• Distribute patches over Internet
• Install patches on all clients
• Recall all physical units

8
Business Models

• How do people profit from writing this software?
• The way in which money flows
• We make money by
• e.g. by selling services to develop other
  peoples software
• What profit depends upon appears to either drive
  or constrain other factors
• Project size, customer type/market, risks
  incurred (criticality), number of regulations
  that affect the product.

9
Business Models

• Custom systems written on contract We make
  money by selling our services to write other
  peoples software.
• Custom systems written in-house We make
  software to make our own business run better.
• Commercial products We make money by writing
  and selling software to other businesses.
• Mass-market software We make money by writing
  and selling software to consumers
• Commercial and mass-market firmware We make
  money by selling objects which happen to require
  embedded software.
• Scientific software We make software for use in
  research in biology, chemistry, physics,
  psychology, economics, and many other fields
• e.g. earthquake or nuclear simulation, climate
  modeling.

10
Situational Factors

• Attributes (characteristics) of a business model
  that seem to influence the choice of software
  engineering practices.
• Derived from or limited by the business model
• Way money flows
• End purpose of the software
• e.g. software for consumer purchase is unlikely
  to be life-critical

11
Situational Factors

• Criticality The potential for harming the
  users or purchasers interests varies depending
  on the type of product.
• Some software can kill you when it fails, other
  software can lose large sums of many peoples
  money, and yet other software can do nothing
  worse than waste the users time.
• Uncertainty of Users Wants and Needs The
  requirements for software that implements a known
  business process (such as the U.S. tax code) are
  necessarily better known than the requirements
  for a new consumer product that is so new the end
  users dont even know that they want it.
• Range of Environments
• Software written to use in a specific company
  needs to be compatible only with that companys
  officially supported computing environments,
• Software sold to the mass market has to work with
  a wide range of environments.
• The skill sets of users in the mass market also
  vary more widely than those of users in a
  specific company.

12
Situational Factors

• 4. Cost of Fixing Errors Distributing firmware
  fixes is a lot more expensive than patching a
  single website.
• 5. Regulation Regulatory agencies and contract
  terms can require practices that might not
  otherwise be adopted, or may set up a situation
  in which certain practices become useful. Some
  situations require process audits, which verify
  that a certain process was followed to make the
  product.
• 6. Project Size Multi-year projects with
  hundreds of developers are common in some
  businesses, whereas shorter single-team projects
  are more typical in other businesses.
• Communication Factors in addition to project
  size that can increase the amount of
  person-to-person communication needed, or make
  accurate communication more difficult
• The way work is distributed
• Senior staff design and juniors code.
• Specialization where specialists start assuming
  knowledge on the part of others
• Development versus Maintenance

13
Situational Factors

• Organizational Culture The organization will
  have a culture that defines how people operate.
• Four organizational cultures
• Control Control cultures, like IBM and GE, are
  motivated by the need for power and security.
• Competence A competence culture is driven by
  the need for achievement Microsoft is an
  example.
• Collaboration Collaboration cultures of
  Hewlett-Packard, are driven by a need for
  affiliation.
• Cultivation A cultivation culture motivates
  by self-actualization can be illustrated by
  start-up companies.

14
Custom Systems Written on Contract

• Largest and longest-running purchasers of custom
  software appear to be finance companies (e.g.
  Banks) and the military.
• Profit comes from staying within the allotted
  budget and avoiding penalties for late delivery.
• Contract requires a detailed set of
  specifications for the work to be done.
• Once the customer has signed off on those
  specifications, the contractor can charge extra
  for every change request
• Cost of distributing post-release fixes is
  manageable
• Fixes are distributed to a known, accessible,
  reasonably set of locations.

15
Custom Systems Written on ContractThe Fears

• Incorrect results
• Running over budget
• Penalties for late delivery
• Not delivering what the buyer ordered
• which may result in litigation (e.g. going to
  court)

16
Custom systems written on Contract The
Situational Factors

1. Criticality Software failures in a few systems
   can be life-critical (e.g. weapon system not
   working properly)
2. Uncertainty of Users Wants and Needs In
   general, they do have a detailed idea of what
   they want.
3. Range of Environments The purchasing
   organization has usually decreed a small set of
   target environments
4. Cost of Fixing Errors Generally there are
   reasonably priced ways to distribute fixes.
5. Regulation Software for the Department of
   Defense must be written in accordance with a huge
   list of regulations, most concerning the process
   of producing the software.
6. Project Size Big.
7. Communication The practice of splitting design
   and coding between senior and junior staff
8. Organizational Culture The companies that write
   software on contract often have a control
   culture.

17
Custom systems written on contractThe Assumptions

• Situational factors and capabilities together
  lead logically to a set of assumptions
• Delivery on time and within budget is very
  important.
• Software that reliably delivers correct output is
  very important.
• The requirements can and should be known in
  detail up front.
• Projects will be large and communication paths
  complex.
• We must be able to prove that we did what we
  promised.
• We need plans and regular status reports flowing
  upwards.

18
Custom systems written on contractThe Favourite
Practices

• Lots of documentation
• when project sizes are large.
• when the communications paths are complex
• to prove that we did what we promised
• requirements known in detail up front
• Often use the Capability Maturity Model of the
  SEI (e.g. CMMI).
• Waterfall Lifecycle.
• Easier to coordinate multiple large projects
  using the simpler structure of a waterfall
  lifecycle
• Formal Requirements and Analysis, Unified
  Modeling Language, Rational Unified Process
• for correct output,
• in complex communication paths.
• Process Audits
• Extensive auditing procedures to prove that you
  did what you promised.
• Rapid Application Development (RAD) and Joint
  Application Development (JAD).
• Getting users and developers to agree on
  requirements in detail up front

19
Characteristics of Scientific Software

• Scientists either write or customize much of the
  code themselves,
• Occasionally have their graduate students perform
  these tasks, since the average software developer
  does not understand the application domain
• Research laboratories are often multidisciplinary
  environments
• Developers receive their software training from
  other scientists
• Many software programs are not designed to be
  large,
• Grow and evolve in parallel with the research
  project
• Scientists are not typically trained in software
  engineering methodologies,
• Their expertise residing rather in the science of
  their field of research
• Requirements are mostly emergent, and the
  emergence of requirements is intertwined with
  evaluation and testing is cursory
• The life cycle could be long,
• e.g. a 30-year life cycle for some nuclear
  simulation software.

Adapted from Basili et al. 2008