LightWeight Development

1
Light-Weight Development

• SESC Meeting August 2002
• Ted Byrne

2
Light-Weight Development

• We recognize that Light-weight software
  development methods are a new phase in software
  creation.
• We predicted (or at least I predicted) that SESC
  might be able to perform some useful service
  here.
• Scott suggested that some standard might be
  useful to light-weight developers. They said no
  thanks, probably properly so.
• I propose a second attempt, based on defining the
  interface between light-weight developers and a
  large customer who might not otherwise meet the
  light-weight model.

3
Reasons

• The customer cannot provide full-time on-site
  representation and participation at the
  developer. They are contracting precisely
  because they do not have such ability.
• Even if they did, they have no one with the
  expertise to be a partner developer. Their
  business is not software development.
• Even if they did, their representative could not
  make the day-by-day decisions implied by
  Light-weight.Decisions in large organizations
  require interaction with many stake-holders and
  levels of management.

4
Reasons 2

• The concept of relative importance of
  requirements is not valid. In real-time and
  high-reliability systems substantially all of the
  requirements are necessary if the product is to
  be useable at all.
• The assumption that 'light-weight' attracts and
  uses above average developers is less valid for
  large companies and large projects. Anything
  large is, by definition, average.
• Typical requirements go beyond functionality to
  system interfaces, Reliability, design
  constraints, product support, etc. Light-weight
  stresses functionality requirements.

5
.Reasons 3

• They do business by development contract, with
  costs, results, milestones, penalties/incentives
  etc. This is contrary to the "do-our-best"
  "most-important-first Light-weight philosophy,
  which is more like hiring contract programmers.
• Even if they could create such a "best-effort"
  contract, they would have trouble getting funding
  approval for it and paying for performance of it.
  Funding agencies want oversight that is
  pre-specified objectives, schedules and
  milestones.
• They want some demonstration of competence up
  front, such as ISO 9000 compliance or SEI CMM
  certified level of performance. This is not
  likely for, and philosophically incompatible
  with, Light-weight.

6
Proposal

• The proposal described here is for a
  standard-defined buffer between the user/customer
  and the light weight software developer.
• Its purpose is to provide a typical
  contract-style interface to the customer that
  resolves the above concerns
• a results-oriented rather than level-of-effort
  contract
• infrequent but more formal and higher level
  interaction between customer and developer
• invisibility of low level aspects of the
  development.
• The Interface function could be implemented by
  the developer or by some third party who would be
  an intermediary or Ombudsman between the customer
  and the developer.

7
This is not a novel proposal

• It acts very much like an insurance policy. It
  indemnifies the customer to assure that their
  results, costs and schedule are met. It absorbs
  the risks and receives the rewards that it
  believes are due because the average developer
  can do better than the contract specifies. The
  role of insurance companies is well known.
• It acts very much like an Independent
  Verification and Validation Company. The IVV
  concept is already familiar to many large and
  government customers and IVV companies already
  exist to perform that function.

8
What Would it Do?

• define the interface between customer light
  weight methods.
• Convert system/software requirements to a suite
  of tests.
• Interpret requirements in day-to-day decisions.
• Summarize low-level progress to periodic status
  reports.
• Evaluate risk and determine how to minimize it.
• Determine how much of the job has been done, and
  therefore which milestones have been met and how
  much payment should be made.
• Discover problems and bring them to the attention
  of the customer.