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 IV&V concept is already familiar to many large and government customers and IV&V 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.