Based on the paper “Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects” by Richard E. Fairley and Mary Jane Willshire, address the following questions:
Identify systems development life cycle (SDLC) issues in the Vasa case that were not addressed well?
What was the impact of changing requirements and specs on Vasa?
What are your recommendations for addressing and managing changing requirements?
info578_m1__why_the_vasa_sunk__10_problems_and_some_antidotes_for_software_projects_case_study__2_.pdf

Unformatted Attachment Preview

focus
process
Why the Vasa Sank:
10 Problems and Some Antidotes
for Software Projects
Richard E. Fairley, Oregon Health and Sciences University
Mary Jane Willshire, University of Portland
n 10 August 1628, the Royal Swedish Navy’s newest ship set sail
on its maiden voyage. The Vasa sailed about 1,300 meters and
then, in a light gust of wind, capsized in Stockholm’s harbor, los­
ing 53 lives. The ship was Sweden’s most expensive project ever,
and a total loss. This was a major national disaster—Sweden was at war with
Poland and needed the ship for the war effort. A formal hearing the follow­
ing month did not determine why the ship sank, and no one was blamed.
O
In 1628, the Royal
Swedish Navy
launched the Vasa.
After sailing only
about 1,300 meters,
it sank. The authors
review the project’s
problems, including
why the ship was
unstable and why it
was still launched.
They interpret the
case in terms of
today’s large,
complex software
projects and present
some antidotes.
18
IEEE SOFTWARE
After initial salvage attempts, the ship
was largely forgotten until Anders Franzen
located it in 1956.1 In 1961, 333 years af­
ter it sank, the Vasa was raised; it was so
well preserved that it could float after the
gun portals were sealed and water and
mud were pumped from it. The sheltered
harbor had protected the ship from storms,
and the Baltic Sea’s low salinity prevented
worms from infesting and destroying the
wooden vessel. Today it is housed in the
Vasa Museum (www.vasamuseet.se), near
the site where it foundered.2 Figures 1 and
2 show the restored ship and a recreation of
its sinking.
Researchers have extensively analyzed the
Vasa and examined historical records con­
cerning its construction. It sank, of course,
because it was unstable. The reasons it was
unstable, and launched when known to be
Published by the IEEE Computer Society
unstable, are numerous and varied. Although
we may never know the exact details sur­
rounding the Vasa, this article depicts our
“most probable scenario” based on the ex­
tensive and remarkably well-preserved docu­
ments of the time, evidence collected during
visits to the Vasa Museum, information from
the referenced Web sites, and publications by
those who have investigated the circum­
stances of the Vasa’s sinking. The problems
encountered are as relevant to our modernday attempts to build large, complex soft­
ware systems as they were to the 17th-cen­
tury art and craft of building warships.
The Vasa story
The story of the Vasa unfolds as follows.
Changing the shipbuilding orders
On 16 January 1625, Sweden’s King Gus­
0740-7459/03/$17.00 © 2003 IEEE
tav II Adolf directed Admiral Fleming to
sign a contract with the Stockholm ship
builders Henrik and Arend Hybertsson to
design and oversee construction of four ships.
Henrik was the master shipwright, Arend
the business manager. They subcontracted
with shipbuilder Johan Isbrandsson to build
the ships under their direction over a period
of four years. Two smaller ships were to
have about 108-foot keels; the two larger
ones, about 135-foot keels.
Based on a series of ongoing and confusing
changes the King ordered during the spring
and summer of 1625, Henrik requested oak
timbers be cut from the King’s forest for two
108-foot ships and one 135-foot ship. On 20
September, the Swedish Navy lost 10 ships in
a devastating storm. The king then ordered
that the two smaller ships be built first on an
accelerated schedule to replace two of the lost
ships. Construction of the Vasa began in early
1626 as a small, traditional ship; it was com­
pleted two and a half years later as a large, in­
novative ship, after undergoing numerous
changes in requirements.
On 30 November 1625, the King changed
his order, requiring the two smaller ships to
be 120 feet long so that they could carry
more armament: 32 24-pound guns in a tra­
ditional enclosed-deck configuration.1 (“24
pounds” refers to the weight of the shot
fired by the cannon. A 24-pounder weighed
approximately 3,000 pounds.) Henrik inven­
toried materials and found that he had
enough timber to build one 111-foot ship
and one 135-foot ship. Under the King’s di­
rection, as conveyed by Admiral Fleming,
Henrik laid the keel for a 111-foot ship be­
cause it could be completed more quickly
than the larger one. The records are unclear
as to whether the keel was initially laid for
this size or initially for a 108-foot ship and
then extended to 111 feet.
No specifications for the modified keel
After the Vasa’s 111-foot keel had been
laid, King Gustav learned that Denmark
was building a large ship with two gun
decks. The King then ordered the Vasa to be
enlarged to 135 feet and include two en­
closed gun decks (see Figure 3). No one in
Sweden, including Henrik Hybertsson, had
ever built a ship with two enclosed gun
decks. Because of schedule pressure, the
shipbuilders thought that scaling up the
Figure 1. The restored
111-foot keel using materials planned for Vasa, housed in
the bigger ship would be more expeditious Stockholm’s Vasa
Museum (model in
than laying a new 135-foot keel.
The evolution of warship architecture foreground, Vasa in
background).
from one to two enclosed gun decks in the
early 1600s marked a change in warfare tac­
tics that became commonplace in the late
1600s and 1700s. The objective became to
fire broadside volleys and sink the oppo­
nent. Before that, warships fired initial can­
non volleys to cripple their opponent’s ship
so that they could board and seize it. To this
end, earlier warships carried large numbers
of soldiers (as many as 300).
Although the contract with the Hy­
bertssons was revised (and has been pre­
served), no one has ever found specifications
or crude sketches for either the 111-foot or
135-foot Vasa, and none of the related
(and well-preserved) documents mentions
such drawings. It is unlikely that anyone
spent time preparing specifications, given
the circumstances and schedule pressure un­
der which the Vasa was constructed. They
probably would not have been prepared for
March/April 2003
IEEE SOFTWARE
19
Figure 2. A
recreation of the
Vasa disaster.
(photo by Hans
Hammarskiöld)
Figure 3. The Vasa’s
two gun decks.
20
IEEE SOFTWARE
the original 108-foot ship, because these
types of ships had been routinely built for
many years and Hybertsson was an experi­
enced shipwright, working with an experi­
enced shipbuilder. Henrik Hybertsson prob­
ably “scaled up” the dimensions of the
original 108-foot ship to meet the length and
breadth requirements of the 111-foot ship
and then scaled those up for the 135-foot
version of the Vasa.
How he scaled up the 111-foot Vasa to
h t t p : / / c o m p u t e r. o r g / s o f t w a r e
135 feet was constrained by its existing
keel, which contained the traditional three
scarfs. He added a fourth scarf to lengthen
the keel, but the resulting keel is thin in re­
lation to its length, and its depth is quite
shallow for a ship of this size.
Hybertsson’s assistant, Hein Jacobsson,
later said that the Vasa was built one foot,
five inches wider than originally planned to
accommodate the two gun decks. However,
the keel was already laid, so they could
make that change in width only in the upper
parts of the ship. This raised the center of
gravity and contributed to the Vasa’s insta­
bility (sailing ships are extremely sensitive
to the location of the center of gravity; a few
centimeters can make a large difference).
Also, those outfitting the ship for its first
voyage found that the shallow keel did not
provide enough space in the hold for the
amount of ballast needed to stabilize a 135­
foot ship. The keel’s thinness required extra
bracing timbers in the hold, further restrict­
ing the space available for ballast.
Shifting armaments requirements
The numbers and types of armaments to
be carried by the scaled-up Vasa went through
a number of revisions. Initially, the 111-foot
ship was to carry 32 24-pound guns. Then,
the 135-foot version was to carry 36 24­
pound guns, 24 12-pound guns, eight 48­
pound mortars, and 10 smaller guns. After
a series of further revisions, the Vasa was to
carry 30 24-pounders on the lower deck
and 30 12-pounders on the upper deck. Fi­
nally, the King ordered that the Vasa carry
64 24-pound guns—32 on each deck—plus
several smaller guns (some documents state
the required number as 60 24-pound
guns).
Mounting only 24-pound guns had the ad­
vantage of providing more firepower and al­
lowed standardization on one kind of ammu­
nition, gun carriage, powder charge, and
other fittings. However, the upper deck had to
carry the added weight of the 24-pound guns
in cramped space that had been built for 12­
pound guns, further raising the ship’s center
of gravity. In the end, the Vasa was launched
with 48 24-pound guns (half on each deck),
because the gun supplier’s manufacturing
problems prevented delivery of more guns on
schedule. Waiting for the additional guns
would have interfered with the requirement
Figure 4. The ship’s
ornate, gilded
carvings.
to launch the ship as soon as possible. An­
other indication of excessive schedule pres­
sure is that the gun castings were of poor
quality. They might well have malfunctioned
(exploded) during a naval battle.
Artisan shipbuilders constructed the
Vasa’s rigging and outfitting without ex­
plicit specifications or plans, in the tradi­
tional manner that had evolved over many
years. The King ordered that the ship be
outfitted with hundreds of ornate, gilded,
and painted carvings depicting Biblical,
mythical, and historical themes (see Figure
4). The Vasa was meant to impress by out­
doing the Danish ship being built; no cost
was spared, making the Vasa the most ex­
pensive ship of its time. However, the heavy
oak carvings raised the center of gravity and
further increased instability.
The shipwright’s death
Henrik Hybertsson became seriously ill
in 1626 and died in 1627, one year before
the Vasa was completed. During the year of
his illness, he shared project supervision
with Jacobsson and Isbrandsson, but ac­
cording to historical records, project man­
agement was weak. Division of responsibil­
ity was not clear and communication was
poor; because there were no detailed speci­
fications, schedule milestones, or work plans,
it was difficult for Jacobsson to understand
and implement Hybertsson’s undocumented
plans. Communication among Hybertsson,
Jacobsson, and Isbrandsson was poor. This
resulted in further delays in completing the
ship.
Admiral Fleming made Jacobsson (Hy­
bertsson’s assistant) responsible for complet­
ing the project after Hybertsson’s death. At
this time and during the subsequent year, 400
people in five different groups worked on the
hull, carvings, rigging, armaments, and bal­
lasting—apparently with little, if any, com­
munication or coordination among them.
This was the largest work force ever engaged
in a single project in Sweden up to that time.
There is no evidence that Jacobsson prepared
any documented plans after becoming re­
sponsible for completing the ship.
No way to calculate stability, stiffness, or
sailing characteristics
Methods for calculating the center of
gravity, heeling characteristics, and stability
factors for sailing ships were unknown, so
ships’ captains had to learn their vessels’
operational characteristics by trial-and­
error testing. The Vasa was the most spec­
tacular, but certainly not the only, ship to
capsize during the 17th and 18th centuries.
Measurements taken and calculations per­
formed since 1961 indicate that the Vasa was
so unstable that it would have capsized at a
heeling over of 10 degrees; it could not have
withstood the estimated wind gust of 8 knots
(9 miles per hour) that caused the ship to cap­
size.3 Recent calculations indicate the ship
would have capsized in a breeze of 4 knots.
That the wind was so light during the Vasa’s
initial (and final) cruise is verified by the
fact that the crew had to extend the sails
by hand upon launch. Lieutenant Petter
Gierdsson testified at the formal inquiry
held in September 1628: “The weather was
not strong enough to pull out the sheets, al­
though the blocks were well lubricated.
Therefore, they had to push the sheets out,
and one man was enough to hold a sheet.”4
During the formal inquiry, several wit­
nesses commented that the Vasa was “heav­
ier above than below,” but no one pursued
the questions of how and why the Vasa had
become top-heavy. No one mentioned the
weight of the second deck, the guns, the
carvings, or other equipment. In those days,
most people (including the experts) thought
that the higher and more impressive a war­
ship, and the more and bigger the guns it
carried, the more indestructible it would be.
March/April 2003
IEEE SOFTWARE
21
Table 1
Ten software project problems and some antidotes
Problem area
Antidotes
1. Excessive schedule pressure
Objective estimates
More resources
Better resources
Prioritized requirements
Descoped requirements
Phased releases
Iterative development
Change control/baseline management
Development of initial specifications
Event-driven updating of specifications
Baseline management of specifications
A designated software architect
Development of an initial plan
Periodic and event-driven updating
Baseline management of the project plan
A designated project manager
Baseline control
Impact analysis
Continuous risk management
A designated software architect
Initial requirements baseline
Baseline management
Risk management
A designated software architect
Prototyping
Incremental development
Technical performance measurement
Back-of-the-envelope calculations
Assimilation of lessons learned
Ethical work environments and work cultures
Personal adherence to a code of ethics
2. Changing needs
3. Lack of technical specifications
4. Lack of a documented project plan
5. & 6. Excessive and secondary innovations
7. Requirements creep
8. Lack of scientific methods
9. Ignoring the obvious
10. Unethical behavior
The failed prelaunch stability test
Captain Hannson (the ship’s captain) and
a skeleton crew conducted a stability test in
the presence of Admiral Fleming during out­
fitting of the Vasa. The “lurch” test con­
sisted of having 30 men run from side to
side amidship. After three traversals by the
men, the test was halted because the ship
was rocking so violently it was obvious it
would capsize if the test were not halted.
The ship could not be stabilized because
there was no room to add ballast under the
hold’s floorboards (see Figure 5). In any
case, the additional weight would have
placed the lower-deck gun portals near or
below the ship’s waterline. The Vasa was es­
timated to be carrying about 120 tons of
ballast; it would have needed more than
twice that amount to stabilize.
That the Vasa was launched with known
stability problems was the result of poor com­
22
IEEE SOFTWARE
h t t p : / / c o m p u t e r. o r g / s o f t w a r e
munication, pressure from King Gustav to
launch the ship as soon as possible, the fact
that the King was in Poland conducting a war
campaign (and thus unavailable for consulta­
tion), and the fact that no one had any sug­
gestions for making the ship more stable.
Testimony at the formal hearing indi­
cated that Jacobsson, the shipwright, and Is­
brandsson, the shipbuilder, were not present
during the stability test and were unaware
of the outcome. The boatswain, Matsson,
testified that Admiral Fleming had accused
him of carrying too much ballast, noting
that “the gunports are too close to the wa­
ter!” Mattson then claimed to have an­
swered, “God grant that the ship will stand
upright on her keel.” To which the Admiral
replied, “The shipbuilder has built ships be­
fore and you should not be worried.”4
Whether Admiral Fleming and Captain
Hannson intentionally withheld the stabil­
ity test results is a matter for speculation.
The King had ordered that the Vasa be
ready by 25 July and “if not, those respon­
sible would be subject to His Majesty’s dis­
grace.” The Vasa’s maiden voyage on 10 Au­
gust was more than two weeks later. It was
reported that after the failed stability test,
Admiral Fleming lamented, “If only the King
were here.”5
Ten problem areas and their
antidotes
Many of the Vasa project’s problems
sound familiar to those who have grappled
with large software projects. Table 1 pres­
ents 10 problems from the Vasa project that
are also common to software projects, along
with some antidotes for software projects.
1. Excessive schedule pressure
Many software projects, like the Vasa proj­
ect, are under excessive schedule pressure to
meet a real or imagined need. According to
Fred Brooks, more software projects have
failed (“gone awry”) for lack of adequate
calendar time than for all other reasons
combined.6 Excessive schedule pressure in
software projects is caused by



Truly pressing needs
Perceived needs that are not truly pressing
Changing of requirements without ad­
justing the schedule or the resources (see
Problem 2)


Unrealistic schedules imposed on projects
by outside forces
Lack of realistic estimates based on ob­
jective data
When schedule estimates are not based on
objective data, software engineers have no
basis for defending their estimates or for re­
sisting imposed schedules. You can sometimes
meet schedule requirements by increasing
project resources, applying superior re­
sources, descoping the (prioritized) require­
ments, phasing releases, or some combina­
tion of these antidotes.
2. Changing needs
Some common reasons for changes to
software requirements include competitive
forces (as in the case of the Vasa), user needs
that evolve over time, changes in platform
and target technologies, and new insights
gained during a project. There are two tech­
niques for coping with changing software
requirements:


Pursuing an iterative development strat­
egy (for example, incremental, evolu­
tionary, agile, or spiral)
Practicing baseline management
You can use these techniques alone or to­
gether. In the case of iterative development,
you can accommodate requirements changes
based on priority within the constraints of
time, resources, and technology—any of
which you can adjust as the project evolves.
When using baseline management, you ini­
tially place the requirements under version
control. Approved changes result in a new
version of the requirements (a new base­
line), which is accompanied by adjustments
to schedule, resources, technology, and
other factors as appropriate. The goal of
both approaches is to maintain, at all times,
a balance among requirements, schedule,
resources, technology, and other factors
that might pose risks to successful delivery
of an acceptable product within the project
constraints.
3. Lack of technical specifications
Software projects, like the Vasa project,
sometimes start as small, familiar activities
for which technical specifications are
deemed unnecessary. These projects often
grow to become large, innovative ones. In
the Vasa’s case, verbal communication
might have compensated somewhat for the
lack of written specifications and a written
project plan. In the case of software proj­
ects, initially developing and baselining re­
quirements, even for a small, simple proj­
ect, is much easier (and less risky) than
trying to “reverse-engineer” requirements
later, when the project has crossed a com­
plexity threshold that warrants developing
technical specifications.
Figure 5. A cross
section of the Vasa
showing its shallow
keel and its multiple
decks, including the
two gun decks.
4. Lack of a documented project plan
Because its designers saw the Vasa as a
small, familiar ship and because the project
team was experienced in building these
types of ships, they might have thought sys­ …
Purchase answer to see full
attachment