Next I want to talk about software processes.

1

We'll start with a quote from the ACM / IEEE guidelines for teaching undergraduates about software engineering.

(read it)

This quote gets at the fact that there is no one way to develop software. The best tools and methods to use depend on your environment.

So, as we talk about software processes and the best practices for developing software – keep in mind that the best methods to use will depend on things like your requirements, constraints, and resources.

2

We’ll first discuss software development processes.

Now, the dictionary definition of a process is just a series of actions to produce a result.

So, we define a software development process as a systematic method for meeting the goals of a project by (read the bullets)

Another way to think of this is "who will do what by when?" Processes answer these questions.

Note, there are different kinds of software processes, and they have different kinds of activities that may be sequential, or concurrent, or iterative. We'll talk about different software processes a little later in this lecture.

3

Now, you might ask, why do we need this rigorous, systematic approach to software development? Well, the benefit is that this approach, process-driven development, provides a number of assurances to the developers and customers.

Software processes can assure that: (read the bullets)

So, the larger or more critical the project is, typically the more formalized the process of developing that project will be.

4

When you’re choosing the process for your project, you need to consider some questions related to the aspects of software engineering that we saw earlier.

So, for instance, you'll need to decide is the software I want critical or discretionary? Are the requirements fixed? Or might they change throughout the project?Does my team have the experience necessary to do the project? Are they all located in the same area? Or are they working remotely?Is the software architecture that I'm working in flexible? That is, is it easy to change? How about the tools I have? Is the application written in C, which has a very mature compiler, or is the application written in version 0.1 of my friends' hobby language?

What about constraints? Do I have strict cost, schedule, or quality constraints – and how are they prioritized? This is important to think about in case you cannot meet one of your constraints. Also, are there any regulations or standards I'm bound to follow?

5

There are two broad classes of processes: plan-driven and iterative. “Agile” processes are an important type of iterative process – so I’ve separated agile out below.

Plan-driven processes divide software development into phases, such as requirements gathering, design, coding, and testing.These processes are also known as plan and document processes because they typically involve careful up front planning and documentation.

Because they involve a lot of planning, they assume that there are well-defined, stable requirements, that can help guide all later phases of development.In a plan-driven process, interactions among stakeholders is infrequent and often indirect.

An iterative process has a sequence of steps or iterations that produce increasingly functional versions of a system.The approach is to start with an early working version that provides just enough functionality for customers to extrapolate what they will get from the system. With each iteration, the software does more of what customers want. Their feedback on

6

previous iterations guides what gets changed or added in the next iteration.

Agile processes are a type of iterative process that were developed to meet the need for rapid software development. Agile processes have quick iteration times, often change requirements, and have frequent interactions among customers and developers to drive the process.

You can think of the difference between ‘plan and document’ processes and ‘iterative’ processes as the difference between building a project vs growing a project.

The build analogy is with physical buildings. A building goes through phases: an architect prepares a blueprint; a contractor builds the building according to the blueprint; an inspector then certifies that the building is fit for occupancy. With each phase, the building takes shape, but it is not usable until the end.With plan-driven software processes, the system comes together at the end, when coding is all done.

Grow Analogy. The grow analogy is with biological organisms. There is a living organism from the start; it’s capabilities grow as it evolves. Unlike plan-driven processes, where the system comes together near the end, with iterative software processes, there is an increasingly capable working version along the way.

// skip

Processes are sometimes called methods, as in “plan-driven method” for a specific plan-driven process.Classes of processes are sometimes called models, as in “iterative model” for the class of iterative processes.

Review slide.

Before moving on, I want to say a bit about processes in general. There is growing consensus around the following recommendations for processes:

• Deep Customer Involvement. Get the insight, guidance, and commitment of stakeholders early and often.• Iteration. Deliver working software frequently to get feedback and test hypotheses. Iteration intervals are now measured in weeks rather than months.• Verification. Test early and often. During development, maintain the integrity of the

6

system through reviews and testing. After each change, run all tests to have confidence that the change did not break something.

Some aspects of processes remain subject to debate:

• When to Design? Too much design too early and there may be wasted effort, since requirements change. Too little too late may result in an unworkable or inflexible implementation. How much is too much? How early is too early? Depends on the project; hence, the debate about when and how much to design.• How Much to Document? Should communication between team members to be formal or informal? Face-to-face informal communication can be efficient. But, a written document avoids the ambiguity of verbal communication. Documentation becomes essential when teams are distributed across locations.

6

We'll start our discussion of processes with plan-driven processes.

The idea behind these processes is to use detailed planning and specifications to guide all aspects of your project.

These processes are based on something called a phase-gate process, which originated in chemical engineering. Basically, the project is divided into stages or phases that are separated by gates. At the end of each stage, the managers would decide whether to continue with the project to the next gate or redirect somehow.

The plan-driven model was the dominant process model for software projects in the 1970s and into the 1980s. It made software development seem orderly at a time when the software industry faced a crisis.

Plan-driven processes work well enough when two preconditions are met:• Requirements are relatively stable. Relatively stable means that requirements are either fixed, or vary within known parameters; that is, any changes can be anticipated and planned in.• Phases of development can be planned up front. In other words, we can specify

7

what the system must do before we design it, we can design it before we implement it, and we can implement it before we test it, and that everything will go according to plan.

Neither of these preconditions holds, in general, which explains why many software developers have moved away from plan-driven processes. However, as we’ll see a little later, there are variations of plan-driven processes that can be used when it’s difficult to meet these preconditions.

// skip#Ad hoc “code and fix” programming methods were not meeting the challenge of increasingly complex software projects. At the time, programming was a craft that relied on skilled #programmers and there was a shortage of skilled programmers. Thousands of useful software systems were built using plan-driven processes.

7

Plan-driven processes divide software development into phases, such as requirements gathering, design, coding, and testing.

These processes are also known as plan and document processes because they typically involve careful up front planning and documentation.

I'm going to talk about a few different instances of plan and document processes

First, the classical waterfall model, which is simply to proceed sequentially through the activities associated with software development. This approach is risky because there is no provision for customer involvement as you move from phase to phase.

A variant of the waterfall process is the V-model or V-process. In this model, different phases of planning are paired with different tests after the software is ready to test.

To reduce the risks associated with plan and document, we can supplement them with other methods, such as prototyping, or developing a sequence of waterfall versions.

8

We'll discuss examples of each of these later in the lecture.

8

So, the first plan and document process I want to discuss is the waterfall process. The distinguishing characteristic of waterfall is that the phases are done sequentially. Each phase must be completed before the next one begins – as shown in the figure.

Each box represents a phase and the arrows represent the flow from one phase to the next.

The name “waterfall” comes from diagrams like this one, which is adapted from an influential 1970 paper by Winston W. Royce. The waterfall model caught on, although Royce’s paper goes on to suggest alternatives, noting that the pure waterfall model is risky and invites failure.

Part of the reason they caught on is because these waterfall diagrams are clean and easy to understand.

This process was viewed as an ideal. In fact, the belief that waterfall was ideal was so widespread that a report on the Space Shuttle software included a justification on the use of an iterative rather than waterfall process. It said:

9

"From an idealistic viewpoint, software should be developed from a concise set of requirements that are defined, documented, and established before implementation begins. The requirements on the Shuttle program, however, evolved during the software development process"

9

There are two major issues with the pure waterfall approach.

First, there is no provision for customer involvement during the flow from requirements to testing. If a requirement changes, there's no way to incorporate that into your planning.

Second, all of your testing comes at the end of the process. So, all the feedback you will receive on the software requirements, design, and its implementation will come after you've already done all the work.

These issues were sort of known all along. Although they were not described as consequences of the waterfall model, these issues were actually being discussed in the first-ever conference on Software Engineering in 1968. One of the conference attendees, Robert Graham, wrote: "We tend to go on for years, with tremendous investments to find that the system which was not well understood to begin with does not work as anticipated."

Actually, in his original paper on the waterfall model in 1970, Royce noted:

10

"The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced ... if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required."

10

To illustrate the problems with the waterfall process, consider this example.

We have a project that proceeds sequentially as shown in this figure.We collect the requirements, do the design coding, then we start to test the software. During testing, we realize there's an issue with our design. Perhaps the response time is too slow, or it won't scale to support the number of required users. We could try to tune the code, but it's not enough. We need to redesign our software.

11

So, we backtrack to the design phase, and start redesigning the software.

During the redesign, we realize we need a more efficient algorithm to improve response time, and more servers to handle user load. Coding and testing those changes will delay the project and increase its cost.

12

So, we'll also need to backtrack to the requirements phase to negotiate new requirements, or changes to the schedule and cost with the customer.

13

As an example of the sort of issues that can arise from delaying your testing until the end, consider the (relatively) recent launch of the healthcare website healthcare.gov.

Most of you have probably heard of healthcare.gov, but just in case, let me explain. The Affordable Care Act or Obamacare, which was passed in 2010, is the most significant change to the US health care system in decades. As part of the program, the government mandated that an online market place be built to sell ACA-compliant health insurance.

The software system required to implement the market place was planned as a two-year project that had components built by several different contractors. It included a website, called healthcare.gov, which launched on October 1, 2013. The launch did not go well.

There were widespread reports of serious technical problems, and people could not sign up for the insurance they wanted.

The chairman of the oversight committee opened a congressional hearing on the matter on 10/24, saying:

14

"Today the Energy and Commerce Committee continues our ongoing oversight of the healthcare law as we examine the many problems,crashes, glitches, system failures that have defined open enrollment [for health insurance]."

When questioned, one of the contractors admitted that integration testing for the website began two weeks before launch. Another contractor admitted that full end-to-end system testing did not occur until “the couple of days leading up to the launch"

So, in terms of cost, the original budget for the website was $93 million, which had already ballooned to $292 million by the time of the launch. When all was said and done, the Office of the Inspector General released a report that estimated the total cost of HealthCare.gov had reached $1.7 billion.

What was the main issue with healthcare.gov?Ask about why healthcare.gov struggledTell story about Karthik

14

This figure drives home the point about the record of failure of the waterfall model. In 1999, Jarzombek conducted a review of a sample of software projects acquired by the Department of Defense. He found that 75% of these projects were either not delivered or never successfully used. Only 2% were able to be used as delivered.

However, while it's clear that pure waterfall has risks, the risks of plan-driven processes can be mitigated by supplementing them with other methods.

Let’s talk about a few variants of waterfall that have been used successfully.

//skip

Specifically, plan-driven processes, such as waterfall, work well when:

1) Requirements are relatively stable2) Development can be planned up front

Plan-driven processes are still used when these two conditions are met.

15

The first variant is called a V-Process.

V-processes were first proposed by Herbert D. Benington at a Symposium on advanced programming methods for digital computers in 1956. His presentation was about the development process for the US SAGE air defense system.

V-Processes uses many of the same phases as waterfall, but each planning or specification phase has a corresponding test execution phase. In this way, the planning for all of the testing is done early in the process, but the execution of those tests cannot be completed after the project has actually been implemented.

The V-process, obviously, get its name because of the shape of the diagram used to depict the process.

The early part of the project proceeds down the left side of the V, and then after the implementation phase, you proceed up the V through a series of testing phases.

// skip

16

In this way, planning for each test is done early, in the part of the V that goes downward. The test execution can only be done after the software is written, so it will be done after the coding phase in the part of the V that goes upward.

16

For instance, in this example, when you meet with the customer to determine the requirements for the system, you also write the tests that must pass for the customers to accept that you have met those requirements.

But you won’t actually execute the customer acceptance tests until the project is nearly complete.

17

Then, as you do more detailed specification and design, you will write corresponding tests to validate that the implementation you have meets the planned design.

For instance, after you lay out the customer requirements, you might also write functional specifications.

The functional specs outline the behavior of the system as a blackbox. They don’t say how the system does what it does – just what it should be expected to do. For instance, a functional spec for your phone might say, ‘when the user clicks the home button, the current app will close, and focus will return to the desktop.’ So, when you write the functional specs, you would also write system tests to make sure your implementation meets the functional specification.

Next, you have a program specification, which would outline the modules in your program and how they interact.

Then, you have a coding specification that plans out what every component in each module should do.

18

And as you further refine your design, you’re also writing more refined tests to ensure that your implementation meets each part of your design.

V-processes are a subclass of waterfall processes. Note that the solid arrows in Fig. 2.3 represent the sequential flow from Customer Requirements to Customer Acceptance. There may be several testing phases in a V process, but in common with other pure waterfall processes, all coding is completed before any testing begins.

Next, I'd like to discuss a couple examples where plan-driven processes, when supplemented with some other methods, led to success.

So, a V-process consists of a sequence of specification, coding, and testing phases, where the specification and testing phases are paired, like opening and closing parentheses, surrounding the coding phase. The purpose of the testing is to validate that the code implements the corresponding specification.

18

Next, let’s talk about a couple famous examples where plan-driven processes were used to successfully implement a large-scale project.

SAGE, which stood for Semi-automated ground environment, was a distributed computing system, which the United States used for air defense during the cold war. SAGE consisted of 24 radar data collection centers 3 combat centers across the US.

This is a picture from one of the radar collection centers.

19

The SAGE team used a V-process to implement their system.

The final system had 24 radar data collection centers and 3 combat centers across the US as well as 100,000 lines of assembly code

But development began with a smaller disposable prototype system.

The prototype system was built to explore the tradeoffs between performance, costs, and risks of the system.

Herbert Bennington, who documented the development process in 1956, said that the prototype performed all the bare bones functions that they needed to perform air defense. He also said (talking about the prototype): “Twenty people understood in detail the performance of those 35,000 instructions; they knew what each module would do, they understood the interfaces, and they understood the performance requirements."

With their experience with the prototype, the team was well prepared to build the final system. After building the prototype, they knew their requirements were going

20

to stay relatively stable, and the rest of the development could be planned ahead of time.

//

"The experimental prototype ... performed all the bare-bones functions of air defense. Twenty people understood in detail the performance of those 35,000 instructions; they knew what each module would do, they understood the interfaces, and they understood the performance requirements."

20

Another way you can mitigate the issues with plan-driven processes is to deliver your product in a series of releases. The basic idea is to use experience from the previous releases to help plan the development of the next release.

This approach was used to implement AT&T’s 5ESS telephone switching system.

Early in the days of telecommunications, when you went to make a call, especially a long-distance call, that call might have to be routed through some sort of central office where actual human workers would take your call and attempt to connect it to the requested number. (shown in the image on the left).

In the 20th century, people developed automated mechanisms to connect your phone calls to where they needed to go. That’s basically what 5ess was: a sophisticated telephone switching system to automatically connect calls from around the world to each other. It was AT&T’s flagship product from 1985 to 1996.

On the right is not an image of 5ess, but what a modern telephone switching system might look like.

21

5ESS was an extremely large and complex software system:10 million lines of code, divided into 50 subsystems.At any time, there were roughly 3,000 developers working on the multiple phases of

multiple releases.

The company aimed for and achieved releases with 99.999% reliability. This is way more reliable than our cell phones today (I’m sure most people still remember having a landline – did it ever not work?)

By dividing the project into multiple releases, the development team could add new features to the system and the underlying technology in the project was refreshed several times.

New features were not added lightly. Product managers stayed in close contact with customers and maintained a backlog of features and enhancements.

22

This figure shows historical data for multiple releases of the 5ESS Switching System from 1985 to 1996.

Each row in this figure represents a release. Releases D1-D11 were for the U. S. market; releases I1-I15 were for international markets. The histograms in each row correspond to the level of effort on that release at each phase of the project. Each release was carefully planned and documented.

So, you can see that each release took roughly two years (some longer, some shorter) and the development of the different releases might overlap.

The requirements for each individual release were fixed; changes might be permitted, but only if they fit the plan.

Any changes that could not be accommodated during a release were deferred to the next release. A release might have 3,000 pages of functional requirements, 9,000 pages of high-level design, 40,000 pages of unit-level design. The unit design, coding, and unit testing phases overlapped significantly.

23

The main takeaway here is that AT&T avoided the downsides of plan and document, such as downtime or cost overruns, by allowing new features and changing requirements to be rolled into the next version of the system. Each individual version is carefully planned and documented before development, which allowed them to develop stable, working implementations with fewer defects than would have occurred without as much planning.

23

So, the SAGE and 5ess examples show that plan and document processes can be applied successfully when you can ensure that the requirements are not going to change much during the development of your project.

This brings us to the next issue I want to discuss and that is ‘what is the cost of making changes to your plan during software development?’ What is the cost of changing requirements? Or, typically, how hard is it to change your design?

The answers to these questions have implications for how much we invest in design and architecture at the start of our project.

24

To examine these questions, we'll use available data on the cost of fixing a defect as a proxy for the cost of change.

This figure shows the cost of fixing a severe defect increasing as a plan-driven project progresses.

So, what we find is that the cost of fixing a defect depends on the size of the project you’re working on.

The cost of a fix is lowest during the requirements and design phases.

However, for large projects, it jumps by a factor of 10 if the fix is during coding and jumps by another factor of 10 if the fix is during operation, for an overall factor of a 100.

The dashed curve for smaller projects is much flatter: the cost of a fix during operation is only 7 times the cost a fix during the requirements phase.

25

In other words, the cost of fixing a severe defect during the initial requirements and design phases is often 100 times less than the cost to fix a severe defect after a system is delivered and put into operation.

For non-severe defects, which are not shown in the chart, the ratio may be 2:1, instead of the 100:1 ratio for severe defects.

The figure in the previous slide is from a 1976 study by Barry Boehm. The underlying data was collected from three different large companies at the time Boehm did his study.

During a workshop in 2002, other companies reported similar ratios forplan-driven processes: (read the the slide)

• A 117:1 increase in effort was observed at IBM Rochester. The increasewas 13:1 between coding and testing, and then a further 9:1 betweentesting and operation.

26

• A 137:1 ratio was observed at Toshiba, for a software factory of 2,600workers, comparing the time needed to fix a severe defect before and aftershipment.• Workshop participants from other organizations reported similar experiences.

26

This table summarizes the comparison of the cost of late fixes (during operation, after delivery) to the cost of early fixes (during initial requirements and design) for different size projects and different severity of defects.

This data has a few implications.

A high ratio motivates up-front work to catch defects early, thereby avoiding the high cost of fixing the defects during operation. High ratios have been cited as a motivation for plan-driven processes: careful up-front planning, if feasible, can reduce the need for costly late changes.

However, if the cost of change is relatively low, then it makes more sense to allow later changes so that you can adjust to changing requirements. This is the fundamental assumption behind the Agile process. Agile basically embraces change on the assumption that the cost of change curve is relatively flat.

27

Now, to review, we've been discussing software development processes, which is a systematic method for meeting the goals of a project.

In this chapter, we first looked at Plan-Driven, or plan and document processes.

Plan-driven processes (read the bullets)

Successful plan-driven processes must meet two pre-conditions (read the bullets)

28

Waterfall processes are a subclass of plan-driven processes, where the phasesare sequential; that is, one phase ends before the next phase begins. Waterfallprocesses are widely taught, but seldom practiced in their pure form.

There are two risks with pure waterfall:• There is no provision for customer involvement during development, so thesystem as implemented may not do what customers want. Alternatively, ifrequirements change—and they often do—incorporating the changes mayinvolve replanning and rework, resulting in cost and schedule overruns.• Testing occurs at the end of the development cycle, so design and performanceissues may not surface until the end.

V-processes are a variant of waterfall processes, in which test planning andtest execution are separated. V-processes consist of a sequence of specificationphases prior to coding and a sequence of test execution phases after codingis done and there is code to be tested. The specification and testing phasesare paired; for each specification phase, there is a corresponding test executionphase—test planning is done along with specification

29

In practice, waterfall and V-processes may be used along with other methods to manage the risks associated with plan-driven processes.

For example, the team that built the successful SAGE air-defense system began with a disposable prototype to thoroughly understand the functions of air defense and the modules and interfaces in a solution.

Then, they used a V-process.

30

And we also talked about the 5ESS telecommunications switch, which effectively used multiple releases over decades. At each release, the requirements were frozen, and changes were accommodated only if they fit the redesign. The teams also reused designs and code from previous releases

The big difference between multiple releases and an iterative process is as follows:

With multiple releases, each release is planned and built separately from the others. Each release was considered its own independent project.

With iterative processes, each iteration is part of a larger process that incrementally delivers an increasingly functional system. Each iteration is part of a single development project.

31

Now let’s shift to discussing iterative and agile processes.

An iterative process has a sequence of cycles or iterations that produce increasingly functional versions of a software system. To emphasize the incremental delivery of functionality, iterative processes are sometimes called iterative and incremental.

The roots of iterative processes go back to the “plan-do-study-act” quality improvement cycles proposed in the 1930s by Walter Shewhart at Bell Labs. [Larmanand Basili. Iterative and Incremental Development: A Brief History. IEEE Computer. 2003]. PDSA was promoted vigorously by a man named W. Edwards Deming throughout the 1940’s.

In the 1950’s, the X-15 hypersonic jet became a milestone project that applied IID methods, and the practice was considered a major contribution to the X-15’s success.

Although the X-15 was not a software project, it is noteworthy because some of the people who worked on it – and thus, had experience with IID – seeded NASA’s early 1960s Project Mercury, which did apply IID in software.

32

IBM was a NASA contractor during Project Mercury in the late 1950’s to early 1960’s and brought the process to industrial software development.

32

Here’s a quote from an internal IBM report on developer recommendations by MM Lehman. Lehman’s report aimed to describe and promote the use of iterative processes within the company.

I include it here because I think it does a good job of laying out the purpose and basic structure of iterative processes.

33

It says separating design, evaluation, and documentation in software development is futile.

Then, he describes what sounds like the iterative process. He says ‘The design process is structured by an expanding model, seeded by some formal definition. Then, you expand on this initial model and develop an increasing amount of functionality and detail. Ultimately, the model becomes the final product.

34

The iterative process is a key element of the Unix style of program design.

In 1978, McIlroy et al. described the Unix program development process as follows:

• “Make each program do one thing well. To do a new job, build freshrather than complicate old programs by adding new ‘features.’ ”• “Design and build software, even operating systems, to be tried early,ideally within weeks. Don’t hesitate to throw away the clumsy parts andrebuild them.”• Software utilities “were continually improved by much trial, error, discussion,and redesign.”

Think about some of the common Unix software and tools that you’ve used. How do these ideas manifest in this software?

Pipes hook programs that do one thing well together.

Experimental kernels released to the community frequently.

35

Linux scheduler is a good example of the third point.

35

Here is the formal definition of an iterative process:

The basic idea is to have a sequence of cycles or iterations that produce increasingly functional versions of a software system.With each iteration, the system does more of what customers want.

A recent trend is an emphasis on shortening the length of each iteration. The idea is that setting early and frequent deadlines will push the developers to complete more in a shorter period of time.

36

This diagram summarizes iterative and incremental software development.

You'll have some initial project planning, but then you'll start developing some number of iterations of your system.

Notice that the phases during iteration are similar to the phases we encountered in the plan and document processes. However, the iteration cycle makes it easier to incorporate changes and new requirements from the users.

At each iteration, the developers build a minimal useful subset of the project. After they implement that functionality, they test it, review it, and then begin extending to the next version.

Eventually, the product will reach a point where the developers and customers are satisfied and the product is released.

37

There are several benefits of iterative processes.

For one, because they do not separate out requirements, design, and implementation phases, developers are able to incorporate dynamically changing requirements during each iteration.

Also, design or quality issues are more likely to be discovered earlier because you’re in frequent contact with the users of your system.

And, in contrast to sequential phase-based processes like waterfall, iterative processes enable you to work on multiple aspects of your product at a time.

Let’s look at a couple different case studies in iterative development that show how IID achieves these benefits.

38

The first case we’ll look at is the Netscape Navigator web browser.

By the mid 1990's, the Internet was starting to catch on and more and more people were looking for a convenient way to get online and browse the Internet.

This figure shows the market share of different browsers since 1996. Blue is Internet Explorer, green is Netscape Navigator, red is firefox or Mozilla, and at the top in yellow are the others, including opera and safari.

So, in the early days, Netscape Navigator was the dominant web browser with more than 70% of market share. Microsoft had sort of missed the boat on web browsing, and didn't announce it's first web browser until 1995.

39

The Netscape Navigator had to deal with both uncertainty and dynamically changing requirements

Uncertainty arises because stakeholders may not know what they need, or the development team may not have fully grasped what they want. Uncertainty is sometimes referred to as a known unknown. That is, we know there is a requirement, but we don't know exactly what it is.

Dynamic changes, on the other hand, are often the result of new information, such as a product announcement by a competitor.These are referred to as unknown unknowns. That is, we don't know anything about the change or even whether there will be a change. Dynamic changes are unexpected and can often lead to redesign.

In the case of the Internet browsers in the mid 1990's, it was clear that Microsoft had missed the boat on building an Internet browser, and Netscape had grabbed a large majority of the market share. So, in December 1995, Microsoft announced it would launch an all-out effort to build a competing web browser.

40

At Microsoft’s analysts conference that year, Bill Gates even said a “sleeping giant” had been awakened during the announcement that Microsoft was putting its efforts behind a web browser.

//

The Tidal Wave reference is from the title of an internal Microsoft memo by Bill Gates [6]. The sleeping giant allusion is from Bill Gates’s opening comments at Microsoft’s December 1995 analysts conference [5, p. 109]

40

So, in the race with Microsoft, time to market was paramount for the Navigator 3.0 project.

The development process emphasized quick iterations. This figure summarizes the iterative process that was used to build Netscape Navigator 3.0

Each gray box represents a distinct iteration. There were six external beta releases between the start of the project in January 1996 until the final release seven months later in August.

The project had both uncertain and dynamically changing requirements:

What might have been an uncertain requirement?Why were the requirements dynamic?

-- Uncertain. The company did extensive research to gather information about what was most important to users, but there was still uncertainty about whether users would like the designs and usability of the features they decided to implement.

41

-- Dynamic. And the team carefully monitored beta releases of Internet Explorer 3.0 so that they could be ready to change requirements dynamically to keep Navigator 3.0 competitive.

So, the project began with a prototype that was quickly released internally within the company as Beta 0.The prototype was followed by quick design-build-test iterations, each iteration leading to an external beta release, available for public download.The beta releases of working software provided valuable user feedback that guided the content of the next beta version.

Navigator 3.0 and Explorer 3.0 both hit the market in August 1996.

The project was considered a success, but it was short-lived. Microsoft had too many advantages, including a huge amount of resources and complete domination of the desktop OS market, that eventually led to its dominance of the web browser market.

41

Next, I want to talk about how iterative development was used to speed up development of space shuttle software in the early 1980's.

One of the major benefits of an iterative process is that it allows different components to be incrementally developed in parallel.

So, in a sequential process, like waterfall, if you're building a complex system that has custom hardware that requires custom operating system software, that might have some upper-level software as well – you have to build each component piece by piece.

But with an iterative process, you can start developing the parts of your project that depend on the other parts as soon as the first iteration is complete.

42

This is essentially why the iterative process was chosen by Nasa to develop the space shuttle software for the shuttle that launched in April 1981.

Their goal was to build a shuttle orbiter vehicle. There were also to build low-level software for navigating and controlling the vehicle and upper-level software for simulation and training purposes.

A sequential process would have been slow because they would have to

1. First, develop the shuttle orbiter vehicle.2. Then, only after the orbiter was completely done, they would develop the software for guidance, navigation, and flight control of the orbiter.3. And only then, they would develop the simulators and training that would use the software.

So, the team at IBM that developed the software decided to use an iterative approach to speed up development.

This quote from a report on the project sums up their strategy:

43

“This approach was based on incremental releases. ... The first drop for each release represented a basic set of operational capabilities and provided a structure for adding other capabilities on later drops.”

An iterative approach allowed the software requirements to adapt as the orbiter hardware changed during development. Early delivery of working software allowed development of the simulators to start before all the software was completed. Early delivery also allowed more extensive verification of the software through testing and use on simulators.

43

Overall, the development of the space shuttle software is considered an iterative development success story.

The development required 17 iterations over 31 months, with each iteration lasting about 8 weeks.

NASA and its contractors made almost 2,000 software requirements changes between 1975 and the first flight of the shuttle on April 12, 1981.

Since they were using parallel development, the software requirements had to change as the orbiter itself changed.

Another reason for changes was that, early in development, it became clear that the software system would exceed the memory and processing capacity of the on-board computer. The requirements could not be met as stated at the time. So, some functions were deleted and the performance requirements relaxed, resulting in changes to the software architecture and the detailed design of the system.

By the time development was completed, Nasa had spent about $200M on the space

44

shuttle software – about 10 times its initial estimate of $20M.

44

Next, I want to highlight a study by Alan MacCormack that tried to identify best practices for successful projects. The findings, in general, support the use of iterative processes.

A study of 29 completed projects from 17 companies identified four practices that were associated with successful projects. The study was based on interviews, surveys, and expert panels.

The study measured (1) product quality, defined as a combination of performance, functionality, and reliability; (asked 14 independent industry experts to give opinions on these items) and (2) team productivity

The four practices are• Early customer feedback to evolve the functionality and the design

The most remarkable finding was that getting a low-functionality version of the product into customers hands at the earliest opportunity improves quality dramatically.

45

Interestingly, he found that products that had most of their final functionality in their first beta release performed uniformly poorly. With a more complete beta version, there are fewer opportunities for the team to respond to customer feedback.

Earlier less complete betas generally result in better final projects because developers can use feedback to prioritize features that customers found useful and can benefit from suggestions about new or missing features.

• Daily builds and automated tests to integrate new code

About half the projects used daily, automated testing, and MacCormack found this practice resulted in higher quality.

• Major investments in a flexible loosely-coupled system architecture

Architectures that are modular and loosely coupled are more likely to be flexible that architectures that are optimized for performance. This allows them to more easily adapt to changing requirements. Measured by how much the company invested in architecture / design of the system.

• Experienced team, with experience on diverse projects

He used years of service to quantify experience. However, he found that experience by itself did not lead to higher productivity. What he did find is that if the team had worked on a diverse set of projects (where the system was not simply a derivative of a previous system), then it was more productive.

45

Agile methods are part of the evolution of iterative processes.

In February 2001, a group of self-described “independent thinkers about software development” met to explore “an alternative to document driven, heavyweight processes.” The group included proponents of a range of process models including Extreme Programming (XP) and Scrum. They eventually got together and wrote their ideas into a short statement called the Agile manifesto, which you can find online at agilemanifesto.org

The manifesto says:

(read the slide)

So, think about how this is different than a plan-driven process. In a plan-driven process, you would spend time doing careful planning and documentation before starting to write your code. The agile process specifically says we should value the delivery of working software and the ability to respond to change over planning and documentation.

46

They also published a list of twelve principles behind their manifesto.

47

You should read through all of these when you have a chance, but I want to emphasize a few of the principles highlighted here.

They say their highest priority is the continuous delivery of valuable software.

They aim to deliver working software frequently, and they say that working software is the primary measure of progress.

These principles again underscore the difference between agile and plan-driven processes. In plan-driven processes, careful planning and testing are the highest priority. While, with agile, early and frequent delivery of software is emphasized.

48

We use the term agile method or agile process to refer to any software development process that complies with the values in the Agile Manifesto.

Based on the Manifesto and the principles that accompanied it, an agile process emphasizes

• satisfying customers through collaboration,• delivering working software frequently (in weeks, not months),• accommodating changes during development, and• valuing simplicity and technical excellence.

Agile methods also have a cultural aspect: teams self organize, developers take responsibility, and communication is ideally face-to-face and informal.

It might seem like agile is meant to be a much more informal process – and in many ways – it is. There is a hint of truth to the comic – but that’s not all agile is. A main theme is that we’re de-emphasizing planning and documentation in favor of these other priorities.

49

This figure illustrates the quick iterations of the agile process. The iterations involve eliciting and prioritizing what to build, writing just enough code and integrating into a working system, and then cleaning up what you've done so it's ready for the next iteration.

For the next part of the lecture, we'll discuss the practices that support the agile process.

50

There are a number of practices and frameworks that have been developed to support the agile development process. We’ll discuss a few of these in greater detail.

Scrum is basically a project management strategy.It was invented as a framework for to organize agile projects, and as a way for development teams to provide external visibility to stakeholders into what is going on.

Many of the practices people associate with agile are associated with extreme programming (or XP).

XP basically proposes to take software development best practices to "extreme" levels. In The inventor of XP, Kent Beck, said that XP is not only a set of practices, it is also a “philosophy of software development.” We’ll discuss XP in more detail in later lectures.

Another practice, feature-driven development builds models and relies on customer-

51

valued features to drive the development process.

And Lean Software Development is adapted from lean manufacturing. Lean development uses a set of principles to guide development, including eliminate waste (that is, anything that does not add to customer value), and delaying decisions as long as possible so that more information is available when the decision has to be made.

51

First, let's talk about scrum.

Recall that, in agile, teams often self-organize and planning and communication are more informal. Well – one downside of having more informal communication is that managers and other people responsible for the project may lose visibility into what’s going on and whether or not the project will be completed on time.

Scrum is a project management strategy that was originally developed to address this issue and give product managers more visibility into what’s going on. It has been widely adopted by major software corporations.

Scrum is not supposed to be a traditional project management framework – so the developers of scrum came up with their own terminology for the system.

So, in scrum, we have:- A product owner that represents the customers. One of their main responsibilities is organizing input from the customers into a Product Backlog -- which is basically a list of tasks for the developers to do.- A development team, which is a small (<7), self-organizing group of people that

52

develops software and delivers potentially shippable increments.- A scrum master is responsible for ensuring the scrum process is followed and interfacing with the rest of the company. The scrum master is not meant to be a people or project manager – they are actually meant to remove impediments that might make it difficult for the team to do their job. They do things like promote self-organization within the team and help the team determine the product is actually done – with input from stakeholders.

The scrum processes calls its development iterations sprints, which are usually 1 to 4 weeks long and result in a potentially shippable software.

They also have special names for their meetings.

Sprint Planning: select work to be done; prepare the BacklogDaily Scrum: see later slideSprint Review with stakeholdersSprint Retrospective to review what went well and try to improve for the next project

52

This diagram summarizes the scrum framework. The product owner takes input from customers and stakeholders.

Using this information, a product backlog is written which describes the list of features or stories that need to be completed and prioritizes their completion.

Next, the team holds a sprint planning meeting to discuss what it can deliver by the end of the sprint.

Then, there's a sprint to develop the product. The scrum master oversees development during the sprint and makes sure the team is sticking to their plan, and communicates issues and progress with the outside organization.

During the sprint there's a daily scrum meeting, which I'll discuss in just a bit.

When the sprint is completed, they have a potentially shippable product and the team might have additional meetings to discuss the product with stakeholders or

53

ways to improve their development.

53

The daily scrum meeting is an important communication tool for the scrum practice.

Basically, it is a short (15 minute) meeting between all of the developers that starts at the same time in the same place every day.

During the meeting, each team member answers three questions: (read ‘em)

Any impediment identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

The intent is a quick way to update progress and catch potential issues early and often.

Discussion:

What do you think of a daily scrum meeting? Waste of time? Potentially useful?

54

Anyone ever used scrum? How strictly did you adhere to what is described?You don’t need to use scrum – but I encourage you to try it.

54

Next, I want to talk about extreme programming.Many agile practices come out of the ideas of extreme programming.

The term Extreme Programming was coined by Kent Beck in 2000. The idea is we should take recognized good practices to extreme levels.

1)2)3) Refactoring is just restructuring the code to clean up design and make it easier to add new code. People have been refactoring code as long as there has been code, but XP makes it explicitly part of the daily routine. The idea is that developers take some time at the end of their day to refactor the code they wrote earlier that day. This should over time improve the design and structure of your program.

4) Only design a solution that will meet the current requirements and no more.

5) Architecture metaphor. This practice says each project should be guided by a single over-arching metaphor. The metaphor can be naive. So, for instance, if you're talking about a parking lot management system, you could have metaphors for parking

55

spaces and cars. Other times, the metaphor needs a little explanation. Like, the computer should behave like a desktop. The idea is that all your variables and design decisions should be chosen with the metaphor in mind. See this in VM’s with GC.

6) Try to show examples of continuous integration later in the course.

7) In XP, even the planning process is done in short iterations. This is the idea behind the “Planning Game”, which is the main planning process in extreme programming. Basically, the planning game is a meeting to plan various aspects of the project that occurs once per iteration. You don’t try to predict the exact date when certain deliverables will be completed, but rather try to steer the project to completion.

55

Now, the prevailing attitude is that XP is not a practical approach – but its ideas were very influential and some of these practices have been adopted as mainstream agile practices.

This slide lists just some of the ideas from XP that have been adopted by mainstream agile development processes.

Remember the items that agile processes emphasize (slide 46)The first items here, user stories, acceptance tests, and release planning, emphasize close collaboration and input from the customer as you design and test your system.

User stories are stories, written by the users, about what the system needs to do for them.Acceptance tests are tests also written by the users. Each acceptance test asks under what scenario will the customer accept that the software is working?Release planning is the idea that developers and customers decide together on when to release, and what stories to implement in the next release / iteration.

The next two practices, test-driven development and refactoring, were adopted

56

because they make it easier to continuously deliver high-quality working software to the customer.

Test-driven development is the idea that before implementing a new feature, you write the test for that feature. So, these tests are different than the acceptance tests because they are all written by the developer.

And refactoring, which I mentioned before, is explicitly part of the agile development process due to XP.

We’re going to discuss each of these contributions in a little more detail.

56

The first contribution I want to talk about it user stories.

In Agile, the developers meet frequently (at the start of each iteration) with customers to elicit requirements and understand exactly what they want and need. To make this process easier, the idea of user stories was developed.

A user story is basically a brief description that encapsulates what the customer needs..

There are three main elements of the user story:

(1) the role or stakeholder who wants the story to work;(2) the feature or functionality to be implemented;(3) the business value of the feature to the stakeholder

An example is shown here with an ATM. (read)

User stories get clarified and sharpened during discussions between stakeholders and developers.

57

How might you clarify this story?For example, how much cash? Does it need to be in increments of $1?

57

A company named connextra developed this original user story template.

Their idea was basically to make the story short enough so that it could fit on 3x5 index card – and this has basically been used as a guideline since then.

(read the slide)

Connextra was a web technologies company. They made annoying browser add-ons –something called a sidewise bar. The company didn't make it far past the early 2000's

58

Developing user stories can be a challenge. You may need to meet with multiple people to get them right. For instance, if you have different stakeholders with different interests, you’ll need to meet with both to capture their needs in the user stories.The developers themselves can help provide a ballpark estimate for how long something will take or how much it will cost.Another developer or tester might help refine what will be delivered by forming an acceptance test.

In the process of writing stories, you might create what's known as a missing story. That's when what the customer wants (I want a) does not match the benefit (so that). A common solution is to break down the story into multiple stories (possibly over multiple iterations) so that its clear how it achieves the benefit. (“I want to withdraw cash from the ATM so that I’m rich”)

A spike is terminology that comes from XP. If it's not possible to make an estimate of how long a task will take or what it will cost, then they will create a spike. A spike is basically an investigation used to determine how much risk or uncertainty there is with some story.

59

XP advocate Bill Wake developed a mnemonic for good user stories. He said good user stories are:Specific, Measurable, Achievable, Relevant, and Time-bound or SMART.

• A story is specific if a developer can implement it.• It is measurable if acceptance tests can be defined for it.• It is achievable if the development team knows how to implement it.• It is relevant if the feature in the story contributes to the goal in the story,and the goal provides business value for the stakeholder.• It is time bound if it can be implemented in one iteration.

Wake says that if one of these criteria is not met, then the story needs to be refined until it is SMART.

For your project, you can construct your minimum viable product using user stories.Just select a subset of the complete set of user stories that make for a viable product.

60

User stories are typically accompanied by acceptance tests, which validate that a story has been implemented correctly.Acceptance tests are developed alongside user stories with the customers as part of the same conversation between stakeholders and developers.

It is useful to use this template when writing acceptance tests: Given … when … then

Given some preconditionAnd when some event occursThen some outcome should occur

This construction is often referred to as an acceptance scenario

61

Acceptance tests should be executable, and there may be more than one acceptance scenario associated with a user story.

For instance, with our ATM example, we can have a scenario for when the account is in credit

(read the slide)

62

And a scenario for when the account is overdrawn past the limit

The acceptance scenario should be written using language that is meaningful to the stakeholder, keeping in mind that the wording needs to be specific enough for a developer to implement it.

The wording should focus on what the outcome is, not on how the outcome is implemented.

For example, when the scenario on the previous slide says 'ensure the cash is dispensed', it does not say exactly how or where the cash will come from.

63

In addition to user stories and acceptance tests, customers and developers will also meet to discuss their priority and also estimate the effort required to complete each story.

Customers will typically attach priority to each story, and the developers attach estimates of effort. The estimates are usually rough, but can be useful for discussing alternatives and prioritizing stories.

Rough estimates can be made by grouping stories by level of effort. One possible grouping is on this slide. (read the first bullet)

For stories in groups 1 and 2, the team’s recent experience with similar stories can be used to estimate the time and effort that will be needed to implement a story

Stories in group three are worth revisiting. It often makes sense to modify or break the story into a simpler story if its not clear how the feature can be implemented.

64

In summary, estimates serve two purposes. First, estimates provide stakeholders with feedback so they can assign a meaningful priority to the story. Second, they can be used to estimate how much a team can accomplish during an iteration

In agile terminology, the average number of points you complete each iteration is known as your velocity.

64

This chart, which is from a chemical engineering textbook, shows another way to estimate the complexity of each user story.

Basically, it says the complexity of each item depends on how well the requirements are defined and if we have the technology / experience to implement the story.

So, if everyone agrees on the requirements, and it is clear how we will implement the story, then it’s simple, and so it’s only a 1 point story.

If either the requirements are not as clear or not agreed upon yet, or it’s not clear that we have the technology or know-how to implement the story, then it’s a more complicated story – worth 2 or 3 points.

The further you go along these dimensions, the more you need to work with your customers to break down the stories and re-write them so they are 1 or 2 point stories.

65

Some companies have developed software to help manage user stories within an agile development process.

The video shows an example of such software.

66

While user stories and backlogs are useful tools, there are several limitations to using them.

By breaking everything down into very simple user actions – there might be enough context within each story about why the user is taking this action. This might lead to the developers implementing more than is necessary for the user to meet their ultimate goals.

There's also no obvious endpoint with user stories. Users can keep requesting new stories – seemingly without bound.

In theory, developers make good estimates of everything that needs to be done, and can keep in mind the difficulty of the remaining stories, but in practice, developers can lose sight of the difficulty of upcoming work – and might discover variations or exceptions too late – causing them to miss a deadline.

67

Now, let's talk about another practice of agile development borrowed from XP: the practice of test-driven or test-first development.

In an article on the history of iterative development in the journal Computer in 2003, Larman and Basili note that the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s.

68

Here's how test driven development works.

You have some set of features that you need to implement. These could, for instance, be based on user stories. Then, for each feature you want to implement, you first write a test to test what the feature should do.

Then, run all your current tests, and see if the new one fails. It should because you actually haven't implemented the feature yet. If it succeeds, either the feature already exists or your test is bad and you need to change it.

Then, write just enough code so you pass the test. The code can be sloppy or not well thought out – just make sure it implements the feature.

Then, run all your tests again and make sure you pass your new test. The practice of re-running all of your tests any time you implement something new is known as regression testing.

69

Now, since you've probably written sloppy code, you should probably refactor it.

69

Refactoring just means restructuring your code without changing its behavior. It's things like – removing duplicate code or moving code around. You can also do things like try to minimize the number of classes and methods you use to make the code easier to maintain.

Any others? Coding style and indentation match the current project? Remove compiler warnings?

The idea is that refactoring makes the code easier to maintain going forward.

Then, once you're done, you repeat the process. Add another test that adds functionality. Try to keep it so your tests only evaluate small changes.Also, try to avoid excessive debugging. If the new code does not rapidly satisfy the new test or it causes some other tests to break, revert it and start over.

// skip

70

Refactoring consists of a sequence of correctness-preserving changes to clean up the code. Correctness-preserving means that the external behavior of the system stays the same. Each change is typically small. After each change, all tests are run to verify the external behavior of the system. Without refactoring, the design and code of the system can drift with the accumulation of incremental changes. The drift can result in a system that is hard to change, which negates the promise of agile methods.

70

While many developers practice TDD religiously, there are several limitations to test driven development.

For instance, there's no specific provision for ensuring that tests that should fail are included in the test set. (If there’s no feature driving the creation of the test, it will never be created).It can lead to developers just testing the obvious or most common use cases and tests that handle the worst case or exception conditions are not considered.Because of this, the tests and the code share the developers blind spots.

Another problem is that the code might pass your tests – but it might still have issues. For instance, your tests might not considered performance, scalability, or other ilitieslike usability. The Wikipedia page on test-driven development specifically says to avoid testing for performance.

And a late design change can cause many tests to fail, which will have to be fixed individually

71

The promise of iterative and agile processes is that they can accommodate requirements changes while a software project is underway. For the promise to be realized, the design and architecture must evolve as the system grows.

There are two approaches to evolve or maintain a design.

The first is to use a flexible design early to set direction. The idea is you start with a design that is flexible enough to handle later changes without major rework.

The other approach is to design incrementally. In this approach, you start with a minimal plausible design, add to it as needed, and refactor at the end of each iteration to incrementally clean up the design.

Both approaches involve some up front design followed by some work associated with each iteration.

The difference is in their point of view. Flexible design invests in anticipation of a later need. Incremental design defers investment until there is a need.

72

Remember the cost of change curve we saw back when we were studying plan and document processes such as waterfall.

73

The curve shows the cost of change as the project moves forward from requirements to coding to deployment.

For projects that do a lot of up-front planning, the cost of change curve will be steep like the curve on the left. As you add design into your system, it becomes harder to change.

The argument from advocates of incremental design is that waiting to do design will ensure the curve is flatter (like the figure on the right) – and we can incorporate changes to requirements and more easily change our design later in the project.

For such incremental designs, it is important to do frequent regression testing and refactoring. Regression testing ensures that the current design is safe, that the features that used to work continue to work. Refactoring keeps the design clean, which lowers the cost of making a change.

74

Extreme programming was an advocate of incremental design.

The idea was that the overall cost could be reduced by only designing when it was needed. They had an acronym YAGNI – which meant don't design up front because you ain't gonna need it.

In the early days of XP, this was often interpreted as developers should not do any design. A prominent software engineer named Martin Fowler has an article about this topic called Is Design Dead? where he argues against the XP design approach.

He says: In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design.

Kent Beck defended his approach in his second edition of Extreme Programming explained by saying that developers need to keep in mind that XP is not a license to

75

do no design. The design investment should be proportional to the needs of the system so far. So, the question is not whether or not to design, but the question is when to design.

75

So, then the question becomes: when to design?

The answer, Beck argues, depends on the task. The quality of the design you can create depends on the amount of instinct, thought, and experience you have. These figures show the quality of the design you create increases as you spend more time thinking about the design or if you have more experience.

For many tasks, however, you don't need a high quality design to implement the task.

For instance, some tasks are simple enough that they only require an instinctual design or no design at all. So for instance, if you're implementing a command line tool, you might not give that much thought to how to parse the arguments for the tool because you've done it many times before and parsing arguments is easy. With these tasks, you can wait to design them, or design them as you're writing up the code.

Other tasks might require a higher quality design that requires some thought or experience. For instance, which data structures to hold your data might be a matter of thinking through the design or might come from experience with similar projects.

76

And other tasks require a specialized design that requires experience. For instance, if I ask you to write an operating system for a new cell phone, if you haven't had a course in operating systems or at least some experience with operating systems, you will be lost if you just try to think it through. You need some experience. These sorts of tasks should be planned earlier.

76

Also, with different tasks, different amounts of instinct, thought, or experience will create high quality designs. For instance, you might have a task that requires a lot of thought, but experience is not that important. An example of a task like this might be building a complex set of tables in a database. You have to think through how the tables fit together, but as long as you understand basic functions and operations on your database tables, additional experience won't improve your design that much.

For others, experience can really help you create a higher-quality design. An example of this might be if you have to write a scheduler for an operating system. This could be done with only a little bit of thought (round robin), but if you have experience, you can design a much higher quality scheduler.

77

Before wrapping up our discussion of software development processes, I want to talkabout the idea of risk in product development.

The factors that contribute to the success or failure of the project can be thought of in terms of risk.

Choosing the right process for your particular project can substantially reduce the risk of failure.

78

Risks vary from project to project. So, it's important to be able to assess what aspects of the project contribute to risk.

This is the same diagram we saw earlier with the different aspects of software engineering. Assessing the risk related to each aspect can help you choose the appropriate process for your project.

For instance, with requirements, even with the assumption that requirements will change, it may be possible to assess what could possibly change and what is likely to be stable. Or, whether a requirement is mission critical or not.

In terms of development, having an experienced team lowers development risk. Not only is an experienced team more productive, it is better at anticipating changes in requirements and technology. You'll remember from our discussion on maccormack'sstudy that higher productivity correlates with the number of diverse projects, not with the number of years on the same project.

79

The organizational context can also have significant implications for the software development process. For example, if there's not a lot of established trust between you and your customers, a more formal process with lots of planning and communication can help build trust.

The architecture and code base for the system and the choice of tools, such as the implementation language, are risk factors, as we shall see with the next example.

79

Earlier we discussed the example with netscape navigator 3.0 project as a successful example of applying an iterative process.

However, the very next project, Communicator 4.0, using the same process, produced a poor quality product. The reason was that the 4.0 project faced multiple risks:

For one, the team took on new requirements, including email and groupware. The email features changed during the course of the project. The groupware features, such as software for doing conference calls, were unproven and were not embraced by customers.

Also, the existing code base from Navigator 3.0 needed to be re-architected to accept the new features, but the schedule did not permit a redesign.

Perhaps the biggest reason the project failed was because the team chose to write their new application in Java so that it would be portable on Windows, Mac OS, and Unix. However, at the time, Java was relatively new and did not provide the desired performance.

80

The team also faced skills shortages. Their developers weren't as experienced with Java. And with multiple platforms to support, such as Windows, Mac, and Unix, the team did not have enough testers.

80

Sometimes you need to consider that there are multiple risks that interact with each other.

This figure shows an example where product quality and market risks interact with each other.

In this example, the company is rushing to meet a deadline so that they can get their product to market ahead of a competitor. They'll gain market share if they can get their product out first. This market risk is represented by the dotted line in this figure. Notice that it is low ahead of the deadline, but jumps sharply around the deadline, since the company will then lose its first-to-market advantage.

Meanwhile, the development team is steadily improving the quality of the system through system testing. The quality risk starts out high, but continues to drop as defects are found and fixed. The quality risk is represented by the solid line. (In this example, there is a significant system-testing phase before delivery.)

81

The overall risk of the product is a combination of the market risk and the quality risk; see the dashed line. Note that the shape of the combined risk curve is quite different from either the market risk curve or the quality risk curve. Introduce the product too early and the quality risk dominates. Wait too long and the market risk dominates.

How might the company change the quality risk curve? Hire more testers, developers. If they find defects faster, then the quality risk curve will go down faster, thereby improving the combined risk curve. The tradeoff is that more testers would add more cost, which may or may not be an option, depending on the business constraints on the project.

81

The last topic in this chapter that I want to address is the spiral risk reduction approach to software development.

The spiral model was first described by Barry Boehm in a 1986 paper entitled, “A Spiral Model of Software Development and Enhancement.” The spiral framework is described as a risk-driven process model generator – which can be used to guide a team to adopt one or more development processes, such as waterfall, or incremental, based on the risks associated with the project.

There are two types of actions in the spiral framework. The first, which is shown in the top half, are customer-related. These are to identify the stakeholders and their objectives, and to identify potential solutions and constraints.

The other type is development related, shown in the bottom half of this diagram. The development activities aim to resolve risks through activities like benchmarking, modeling, and/or prototyping.

82

You would then build the next increment for the next level of risk reduction. At this point, you might make some process or design changes based on your recent experience. You would also review with stakeholders and get a commitment to proceed.

Risk-reduction cycles are represented by the loops of the spiral in the diagram. The first cycle is at the center. The widening loops of the spiral represent increasing levels of investment and commitment as the project proceeds.

82

The framework lets you use any methods or processes you like for carrying out the actions at each step.

In fact, the reason for calling it a “framework” rather than a process model is that the framework has been adapted for use with various process models – you can use it with iterative or plan-driven processes. You might even change your process as you move from cycle to cycle.

Also, although the actions in the diagram are numbered, the framework allows them to be done concurrently, where possible.

The level of effort and investment in each cycle is guided by the risk reduction planned during the cycle. The greater the risk, the more careful the investment.

//skipFor a simple project, some of the actions may be combined and the number of cycles reduced.For a complex project, a more formal approach with more cycles might be helpful.

83

In a webinar in 2013, Boehm described a real-world of the spiral risk reduction framework.

This example deals with a very large competitive contract for a system to control remotely piloted vehicles (drones).

When they were first developed, each drone required two remote pilots to manage and operate the drone from afar. At some point, some higher level people in the army decided it should be feasible to fly drones with only one pilot. And not only that, a single pilot should be able to fly four drones at a time. So, essentially they thought they could improve productivity for drone flying by a factor of 8 (from 2 people for 1 drone – to 1 person for 4 drones).

Not sure why they thought this was possible, but they decided to create a competitive contract for someone to develop a solution to achieve this productivity.

84

They used the spiral risk reduction model to reduce the risk associated with their project.

In the first risk-reduction cycle, the project had four competing teams. Each team was awarded $5M. With an additional $5M for evaluation, the initial investment was $25M. The review at the end of the first cycle concluded that a 4:1 ratio was not realistic, but that some improvement was possible.

In the second cycle, three competing teams remained, and each team was awarded $20M to build a scaled-down system. With an additional $15M for evaluation, the incremental investment was $75M. The review at the end of the second cycle concluded that a ratio of 1:1 was possible

For the final cycle, one competing team was selected to build a viable system that achieved a ratio of 1:1, (resulting in a twofold productivity improvement)

So, notice how this works. In the first cycle, risks were high, so they invested less money, and used four teams to review the problem. In the next cycle, they use what they learned from the first cycle, and invest a little more money, and build a

85

prototype system. Then, in the final iteration, they select the best team and invest a lot more money (total cost was $1B) to achieve a twofold productivity improvement.

85

So, to conclude our chapter on processes, we have these points.

First, we should fit the software development process we select to the project.

Projects vary: consider systems for scientific computing, online banking, video streaming, self-driving cars, ... Each such project benefits from a process tailored to its needs.

Although there is still a lot of variability in which processes people use, there is a consensus for the following recommendations

Deep Customer Involvement. Get the insight, guidance, and commitment of stakeholders early and often.Time-Boxed Iterations. Deliver working software frequently to get feedback and test hypotheses. Iteration intervals are now measured in weeks rather than months. With cloud deployments, iteration intervals are measured in days.Ensure software works frequently. During development, maintain the integrity of the system. Test early and often. After each change, run all tests to have confidence that the change did not break something.

86

Even with the same process model, the process instance for a project can be tailored by varying the emphasis on development activities. For example, there are options for when to design, how much to test, how to balance scope, schedule, and cost.

Understanding risks and tailoring your investments to the project’s risks can help guide decisions about the process you use.

86