CS 501: Software Engineering
Lecture 27
Risk in Software Engineering
1
CS 501 Spring 2005
Administration
2
CS 501 Spring 2005
Quiz 4
At what stage during the software development process will the
decision be made to outsource the development of the software to
an overseas software house?
List two aspects of the software development process will not be
outsourced?
3
CS 501 Spring 2005
What can be Outsourced?
In house Outsource
Feasibility study
Requirements analysis
System design
Program design
Coding
Testing
Acceptance
Operation & maintenance
4
lead
part
lead
part
lead
yes
yes
yes
yes
part
yes
CS 501 Spring 2005
Professionalism:
Planning for the Final Presentation
Questions for every presentation
1. Who is the audience? What do they want?
2. What do you want to achieve?
3. How much time do you have? How much
can you cover?
4. What facilities are in the room? Who should
be there?
5. What materials should you prepare?
6. Do you need a rehearsal?
5
CS 501 Spring 2005
Who is the Audience?
What do they Want?
Clients
The clients have invested effort in this project:
• Is it ready for production?
• Should they invest more effort to bring it into production?
• Should they abandon the project?
Course team
• What has been accomplished? What has been learned?
• Is the client satisfied?
• Are you handing over a maintainable system?
6
CS 501 Spring 2005
What do You want to Achieve?
• Personal and team satisfaction in handing over a good
piece of work to the client
• Complete the course in good style with good grade
• A clean handover without loose ends
Perhaps: a good basis for future involvement with the
client, team, or this project
7
CS 501 Spring 2005
How much Time do You Have?
How much can You Cover?
Plan for 45 minutes total. You should cover:
Presentation:
•
•
Brief review of goals
Honest summary of achievements and gaps
•
Summary of what is being delivered
Demonstration of operational system:
•
•
Show the system in operation
Be honest about gaps, weaknesses, etc.
Time for discussion
8
CS 501 Spring 2005
What Materials should you Deliver?
When you leave, all that the client has is your documentation
and your software. Imagine that you work for the client and
are asked to take over this system. What would you want?
• Materials can be in any format, need not be huge, but must
be current.
• Place your materials on your GForge or other project site.
9
CS 501 Spring 2005
Delivery: Check List for CS 501
Projects
Documentation
•
•
•
•
•
Requirements, updated to reflect delivered system
System and program design, updated to reflect delivered
system
Instructions for: users, administrators, operators
Presentation slides, updated to reflect delivered system
Business documentation, e.g., copyright license
System
•
•
•
10
Source code and matching binary for all programs
Installation scripts, etc.
Test scripts, test data, and test reports
Different projects will have different deliverables
CS 501 Spring 2005
Do you need a Rehearsal?
You need a rehearsal
• Will you have a single presenter, a moderator, or with
each presenter handing to the next?
• Decide on the running order of the presentation and
stick to it.
• When will you take questions?
• How will manage the time? Who will take notes?
Do not change the system after the rehearsal !
11
CS 501 Spring 2005
Failures and Risks
Software development projects can fail in many ways:
Bad software engineering
• Late, over budget
• Lack of function, full of bugs, bad performance
Changing circumstances
• Changing markets
• Better alternatives
• Changes of management
The biggest single source of problems is poor
understanding of requirements
12
CS 501 Spring 2005
Managing Risk
Manage projects to avoid risk:
• Open and visible software process
=> Avoid surprises
• Continual review of requirements
• Willingness to modify or cancel projects
13
CS 501 Spring 2005
Canceling a Project
Example: Andrew Window Manager (wm)
• Technically superior to X (MIT's Athena project) in 1986
but ... Digital Equipment Corporation turning X into a
product with massive support
nobody ready to support wm
• Therefore wm cancelled in 1986, Andrew user interface
and applications ported to X
14
CS 501 Spring 2005
Failure to Cancel a Project
Example: University F developed a novel programming
language.
• From 1985 to 1989, this was a promising language for
simple programming of window-based applications
• By 1990, it clearly not gaining acceptance beyond
University F
• But development continued for many more years (about
$500K)
Not cancelled because ...
15
CS 501 Spring 2005
Too Big to Cancel!
Example: University A has antiquated administrative systems.
Senior management decides to replace them all with commercial
packages from X. The timetable and budget are hopelessly
optimistic.
• Staff get dispirited.
• The Chief Information Officer finds another job.
• A new Chief Information Officer is appointed.
What should she do?
16
CS 501 Spring 2005
We are doing it the Wrong Way!
Example: University B has a (big) joint project with
Company Y to develop a new computer operating system.
After two years work, a junior software developer
persuades the university leader that the technical approach
is wrong.
• What should the university do?
• What should the company do?
17
CS 501 Spring 2005
How to Stop Gracefully
• It is harder to cancel a project than to start it.
• It is harder to withdraw a service than introduce it.
Considerations
• The proponents of the system must now reverse their
public stance.
=> Management of expectations
• Users of the service need a migration strategy.
• Technical staff must have a graceful path forward.
18
CS 501 Spring 2005
Time to Complete a Software Project
Large software projects typically take at least two years from
start to finish
• Formative phase -- changes of plan are easy to
accommodate
• Implementation phase -- fundamental changes are almost
impossible
Yet many things can change in two years.
19
CS 501 Spring 2005
A Sense of Urgency
Example: A not-for-profit corporation is developing a
system for a government organization.
• By 1996 all research had been completed and the system
demonstrated successfully with real users.
• In 2005 the system is still not in full production
Reasons:
=> Incremental improvements to the software
=> Repeated requests for more functionality
=> Reluctance to reorganize clerical staff
Nobody had a sense of urgency
20
CS 501 Spring 2005
Overtaken by Events
Example: University C has a project to develop a digital
library system, with funds from Company Z , private
foundations and the government.
• By 1993 an extensive system is running at the university
and Z is marketing the technology to its customers.
• By 1994 it is clear that web browsers and web formats
(though technically weak) are becoming widely adopted.
=> What should the university do?
=> What should the company do?
21
CS 501 Spring 2005
Changing Requirements and Design
Example: The CNRI Handle System -- a high performance,
distributed system to map names to resources (1994 - ).
Design decisions made in 1994 had to be changed.
•
•
•
•
In 1994 only Web browser was Mosaic
In 1994 Java did not exists
In 1994 mirroring and caching utilities were not available
In 1994 commercial interest was limited
Software was rewritten and greatly improved in 1998/9. In
2005, it is widely used by publishers (as DOI) and libraries.
If a job's worth doing, it's worth doing twice!
22
CS 501 Spring 2005
Changes of Leadership
Many projects are wasted because of management changes
Example: In 1988, Company W gave University D $1,000,000
to port a new operating system to its personal computers. The
work was well done, on time.
• Company W changed its president and senior technical staff
during the project. The work was wasted.
• A decade later and several presidents later, Company W is
building its future around a modern version of the same
operating system.
A graduate student from University D is now Senior Vice
President of Company W!
23
CS 501 Spring 2005
Client Oversight
When work is out-sourced, the client must be vigilant.
Example: Company G was the world's leader in software for
optimization (e.g., linear and integer programming). G had
implemented several packages for various manufacturers.
• An computer company H contracted with G to
develop an optimization package for its new operating system.
• The package was late, performed badly and disliked by
customers.
What went wrong? What can we learn?
24
CS 501 Spring 2005
Too Difficult!
A development team at University E was given
government funds to build a high-performance gateway
from protocol x to protocol y.
• A promising young developer was hired and assigned to
this task
• The project was too difficult for him, but he hid his
problems for many months.
• The project produced nothing of value.
What can we learn from this experience?
25
CS 501 Spring 2005
Accept the Obvious!
Six organizations were funded by the National Science
Foundation, for one year, to develop demonstration projects.
The National Science Foundation hoped that the six organizations
would then submit a multi-million, five year proposal to develop
the production system together.
but ... there were differences (technical and personal) between
the organizations.
Three weeks before the proposal was due, the principal
investigator at University Q decided that the plan was doomed to
failure.
What should he do?
26
CS 501 Spring 2005
Engineering and Marketing
Corporate engineering & marketing divisions at cross purposes:
Examples:
• Xerox's Palo Alto Research Center pioneered window
managers, Ethernet, graphical user interfaces, font managers,
etc,
=> Apple, Adobe, Digital, etc. brought them to the market
• IBM would not bring its first Unix workstation to the market
until the software had been largely rewritten
=> Sun's early workstations were unreliable but sold well
27
CS 501 Spring 2005
Senior Management Dynamics
• Directors and shareholders appoint the President
=> The President does not want to admit failures
• The President appoints the Chief Information Officer
=> The CIO does not want to admit failures
• The CIO appoints the computing managers
=> The computing mangers do not want to admit failures
• The computing managers appoint the developers
=> The developers do not want to admit failure
Everybody pretends that things are going well
28
CS 501 Spring 2005
Senior Management Dynamics
At last the troubles can not be hidden ...
• Directors and shareholders try to blame the President
• The President tries to blame the Chief Information Officer
• The CIO tries to blame the computing managers
(and grumbles about the President)
• The computing managers try to blame the developers
(and grumble about the CIO)
• The developers grumble about their managers
What can we do better?
29
CS 501 Spring 2005
Sobering Thoughts
• Major computing projects are very complex. Inevitably there
are delays and failures.
• Few organizations know how to manage risk & uncertainty.
• The best CIO's
=> Manage to minimize risk
=> Have the confidence of their staff who keep them
truthfully informed
=> Have the self-confidence to keep their seniors
truthfully informed
30
CS 501 Spring 2005
The End
• Software is expensive. Understand who is paying and
what they want
• Good processes help the development of good software:
the limits of heroic efforts
• Software engineering is a craft, not a fixed procedure
• Minimize risk:
visible process
function v. time v. cost
• The importance of people
31
If the requirements are not well understood, the system
will fail!
CS 501 Spring 2005