Preventive Risk Management for Software Projects

7 Pages·2002·0.422 MB·English

by  Murthi S.

Preventive
Risk
Management
for Software
Projects
Sanjay Murthi
D
eveloping large software systems is risky tractors,or taking resources from other projects.
business.According to a report from The In the end,the company kills the project because
Standish Group,“CHAOS:A Recipe for the cure has become too costly.
Success,”only 28 percent of all software A better approach is preventive risk manage-
projects in 2000 were on time and within budget ment based on more flexible development prac-
and had all their planned features—which means tices.The idea is to identify potential steps in
the other 76 percent either failed or did not meet development and deployment that can delay the
original goals.This is scary in an economy where project or cause it to fail and devise strategies that
software systems can make or break the organiza- will mitigate the risk should it materialize.Unlike
tion.Internet auction company eBay lost millions prescriptive risk management,in which the team
of dollars when its systems were unavailable for identifies risks only when they occur and attempts
even a few hours. Software to mitigate them only after the fact,the team
A preventive product companies like Micro- identifies and evaluates risks and devises mitiga-
soft and Oracle lose millions of tion strategies throughout development.And
approach to
dollars when product releases unlike prescriptive risk management,all project
risk management are late or do not work as ex- stakeholders are intimately involved in identifi-
pected.Even small to medium- cation,evaluation,and mitigation.
makes it part of
size projects suffer costs from
development delays.If the cost of each person IDENTIFYING AND EVALUATING RISKS
on a 10-person team is $100 per The first step in managing risks is to identify
and emphasizes
hour,a company spends $40,000 them:What could possibly cause the project to be
for every week of delay.The cost late or to fail? Risk taxonomies can guide the
flexible processes.
in terms of lost opportunities, project team in identification,but although much
lost sales,and dissatisfied cus- work has been done to develop such taxonomies,
tomers could be even greater. they still tend to overlook risks that typically
Many companies have adopted detailed and plague actual projects.The Software Engineering
heavily process-oriented methodologies,hoping Institute’s taxonomy, for example, focuses on
to reduce delays and the number of failures. internal project risks,such as design and integra-
Unfortunately,these methods contribute their tion,almost to the exclusion of the external events
own overhead and delays,and frequently provide
little guarantee of success.They are also generally
Inside
prescriptive in that the team takes action (imple-
ments a cure) when they find a problem (illness).
Resources
The cure is often worse than the disease.Senior
management becomes aware of a problem when Risk Categories in Real Projects
the team misses certain milestones or customers
Principles Behind the
report software problems.They scramble to fix the
Agile Manifesto
problem by drastically reducing project scope,
replacing project managers,hiring expensive con-
1520-9202/02/$17.00 © 2002 IEEE September ❘October 2002 IT Pro 9
S O F T W A R E D E V E L O P M E N T
more than one plan.
Resources • Determine the resource requirements for the
contingency plans.This will give you the
cost impact of each contingency plan.
• Put this risk information in the review plan.
➤ The Agile Manifesto, http://www.agilemanifesto.org:The re-
You can then communicate it to project
sults of a 2001 meeting of major practitioners of agile methods
sponsors and development managers.Also
brought these different methods under a common umbrella.
include information about likely contin-
➤ Agile Modeling,http://www.agilemodeling.com:Site devoted
gency plans and costs so that everyone will
to applying agile methods to modeling.
be on the same page if the risks occur.
➤ “CHAOS: A Recipe for Success,” http://www.pm2go.com/ • Track risks as the project progresses.Some
sample_research/chaos1998.pdf: A report by The Standish
risks may become moot.Other risks will
Group;it’s an old version,but it’s free.
become less likely or their potential impact
➤ Lean Programming, Mary Poppendieck; http://www.
will decrease.New risks can arise after the
sdmagazine.com:Series of articles in Software Development
previous review.Track risks in weekly
on an agile method that arose from experience in applying
reports so that all players know what is
total quality management to manufacturing.
happening.
➤ “The XP Paradigm Shift,” Ed Yourdon; http://www.cutter. • Periodically evaluate and modify the risk
com/summit/read03.html: Valuable insight into Extreme
evaluation approach.Use post-project
Programming from the Cutter Consortium.
meetings to review the effectiveness of risk
evaluation and management.Use feedback
to improve the process.
that can derail a project—politics, changing business
requirements,platform deficiencies,and so on.The “Risk PROACTIVE PREVENTION
Categories in Real Projects”sidebar describes how these Preventive risk management is the proactive manage-
external events can also influence projects. ment of three important areas:people,process,and con-
Risk identification must also acknowledge that risks trol systems.
change with time.New risks arise that the team has not
planned for.The Microsoft solutions framework,which People
suggests that managers continuously assess risks,is one of Of the three,people are probably the most important.
few methodologies that acknowledge changing risks. Unless they are committed and eager to work with each
The second step in managing risks is to evaluate them. other,projects frequently fail.In many projects I have
Risk evaluation should start soon after the team has final- observed,teaching people better estimation,scheduling,
ized project goals,and it should continue through the and risk management skills really helped.These skills pro-
entire project life cycle.Once the team identifies the risks, duced better estimates and timelines,and people were less
they can take the following steps: likely to underestimate or miss work items.Consequently,
there were fewer 80-hour weeks,and stress levels dropped.
• Establish potential impact.If the risk materializes,what Meeting deadlines on target produced a solid team spirit,
items would fail or have problems? Suppose the risk is which in turn produced a virtuous cycle of change—people
that the infrastructure to test an application will be two became more patient with each other and were willing to
weeks late.The impact will be large if testing must start help each other solve problems.Continuous firefighting
earlier (before the delay),but minor if testing falls later and struggling to meet deadlines,on the other hand,led to
in the cycle.Some risk may remain if it takes time to set a viciouscycle.Stress levels rose,people became irritable
up the infrastructure after delivery. and impatient,and the desire to help someone else disap-
• Rank the risks according to potential impact.Ranking peared,as each person totally focused on meeting his dates
can be as broad as high,medium,and low. and solving his personal mountain of problems.Things
• Calculate the probability that the risk will occur.Again, went steadily downhill until management had to resort to
broad categories of high,medium,and low will suffice. drastic surgery or terminate the project.
You do not need an exact percentage.
• Rank the risks by their combined impact and probabil- Processes
ity of occurrence.The combinations of high impact-high Processes also influence risk management.Flexible,adapt-
probability,high impact-medium probability,medium able processes let the team respond quickly to change.
impact-high probability,and medium impact-medium Without them,it is hard to keep a project on track.If a change
probability are the ones to watch for. control board must approve every requirement change,and
• Develop contingency plans for major risks.Aim to have the board meets only once a month,how can the team try
10 IT Pro September ❘October 2002
Risk Categories in Real Projects
Many risk taxonomies fail to consider the structure isn’t in place or the support team
external risks that affect real projects.This list isn’t ready for training or is already
reflects the risk categories most projects are stretched too thin. Sometimes this risk
likely to encounter.A flexible develop- occurs because the deployment and sup-
ment process will help mitigate risks in port teams have no idea what the proj-
the first three categories.The team is ect team is doing,let alone what it needs.
better able to stay loose in defining In this case,communication will help miti-
requirements, modify system designs or gate the risk.
platforms late in the process,or work around ➤ Integration. Most applications must
failed partnerships that introduce business risk. integrate with other applications. Mis-
communication and misunderstand-
➤ Requirements. Unclear or uncertain requirements ings cause systems to miss sharing
introduce large risks.This is the most common type accepted interfaces,so they don’t work together as
of risk and is probably responsible for most failed or expected. Communication is key to reducing this
delayed projects. Competitive forces and business risk.Try to do integration in parallel with develop-
agreements with new partners force the organiza- ment (using stubs that satisfy agreed-on interfaces).
tion and its software systems to change.Users find it Communicate variations and unexpected behavior
hard to visualize software until they use it, which to all interested parties as soon as possible.A flexi-
makes requirements fuzzy and subject to change. ble development process will let the team try differ-
➤ Technology.At some point in development (usual- ent designs if it encounters intractable integration
ly late in the cycle),the team finds that the technol- issues.
ogy can’t satisfy system requirements.For example, ➤ Schedule. These issues include components that
team members could assume that the database they aren’t available when needed, delivery at an
use is not easily corrupted,but when they actually extremely busy time, and so on. Communication
build the system,they find that it has bugs that can can help people see that timing a product upgrade
cause it to become corrupted frequently. towards the end of a quarter is not a good idea
➤ Business.Business decisions introduce many risks. because the sales staff are trying to reach their quo-
A deal with a vendor does not get signed in time to tas.They don’t want to reprice products and reed-
use the desired platform.A conflict with a partner ucate customers just when they’re about to close
who supplies part of the solution stalls the project deals. Good project planning can help prevent
or the partner goes out of business. schedule risk.
➤ Political.These are the most difficult risks to over- ➤ Maintenance and enhancement. The company
come. Large organizations tend to behave like can’t maintain and enhance the software properly
large families. Members are busy jockeying for because the documentation is inadequate,the sup-
power and influence over each other.Some groups port team isn’t properly trained, or the platform
might find the project threatening, which means has become obsolete. Planning and setting aside
that people do not cooperate, budgets get cut, or time for adequate training and documentation can
the project gets cancelled. Contingency plans for help reduce these risks. A flexible development
this risk are hard to define,because these plans can process can make things worse if managers don’t
cause embarrassment later, and if project oppo- allow enough time,money,and people for training,
nents find out about the contingency plans, they documentation,and support.
can sabotage them. ➤ Design.Bad design decisions can degrade the soft-
➤ Resources.When a project doesn’t get the required ware’s usability and system performance.A flexible
people, money, facilities, or equipment, the short- development process that can accommodate user
falls degrade both schedule and morale.Identifying input and changes late in the process can reduce
an alternative resource can help. For example, this risk.
another team might be willing to share some of its ➤ Miscellaneous.This is a catch-all category for risks
servers until yours come in. that are hard to foresee—a hurricane or fire shuts
➤ Skills.These risks arise if,for example,the team is down your offices for a week,a development serv-
unfamiliar with the technology or business process. er crashes,a virus attacks,and so on.Most of these
Providing training and bringing in consultants with risks involve a loss of some resource, so a mitiga-
the missing skills, who can mentor the team, will tion strategy is to arrange for back up.Set people
help mitigate this risk. up to work at home,store project data in multiple
➤ Deployment and support.The team can’t deploy the locations,or plan to use a spare server from anoth-
software on schedule because the required infra- er team.
September ❘October 2002 IT Pro 11
S O F T W A R E D E V E L O P M E N T
out new ideas? In some projects I have observed,the team ADDING FLEXIBILITY TO DEVELOPMENT
would work on certain requirements only to find the effort Traditional project management says that you must man-
wasted because the requirements changed at the next age three dimensions of a project:scope (requirements),
monthly board meeting.In projects involving subcontracted resources (people,equipment,and money),and time.The
work,these delays caused major budget overruns. dimensions are interdependent;hence,a broader project
Agile methods—such as Extreme Programming,feature- scope requires more resources or time.Less time requires
driven development,and Lean Programming—can help more resources or a smaller scope.
avoid this inefficiency because their mission is to cut items Project managers don’t often consider dealing with risk
that add no real value.As such,they provide low-cost ways on a par with these three dimensions,but it should be.If a
to work with requirements changes: platform does not work as the team
Deployment issues
Instead of detailed requirements doc- expects,both time and resource needs
uments,they advise close interaction can cause a project could balloon if the team is locked
between programmers and customers into maintaining the scope. The
to flesh out requirements.They also to fail. extreme and sudden effect of risk
recommend frequent iterative releases argues for making risk management
so that usable code is available as soon another leg of the stool supporting
as possible.Users can then provide the team with valuable successful project management—equal in importance to
feedback for further development.Finally,agile methods resources,scope,and time.Thus,each leg represents a
concentrate heavily on automated test cases so that the dimension that can greatly influence the project,and effec-
team can continuously check for bugs introduced from one tive project management must consider all four legs simul-
release to the next.Clearly,agile methods work extremely taneously for the life of the project.
well in situations where needs change quickly. If risk management is to be an integral part of managing
Software projects using agile methods tend to be a software development project,then traditional devel-
extremely flexible and have lower overhead.The focus on opment must become more flexible so that the team can
continuous user input and the repeated demonstrations of deal with risks if they arise.One way to achieve flexibility
working software helps catch issues early and reduces wasted is to break the project into a series of subprojects.Any proj-
time and effort.The emphasis on close stakeholder interac- ect that lasts more than a few months is a candidate.These
tion means that process decisions involve all stakeholders. subprojects effectively form a series of small-project iter-
On one project I was responsible for,our releases came at the ations,each of which adds functionality to deliverables
same time as another project’s.This caused problems for the from the previous iteration.Each iteration should last at
support team,which was short staffed.We solved this con- most two to three months.
flict by modifying our release cycle and appointing some I propose using an iterative model that follows these
team members to provide second-level support. ideas.Figure 1 shows the phases of a single iteration,which
could be from eight to 12 weeks.The concept of iterations
Control systems with increasing functionality borrows from the spiral devel-
Management control systems are important because the opment model that Barry Boehm and others proposed in
team needs some mechanism for measuring and monitor- the late 1980s.A similar focus on iterative development is
ing all aspects of development,including risk management. in the Rational Unified Process (RUP) and the more
Poor measurement and monitoring can doom a project,just recent agile methods.
as a good system can save it.I have sometimes seen project The spiral model and my iterative model differ slightly,
teams try to downplay certain risks and ignore them,but the however.In the spiral model,iterations build on function-
control system forced them to address these issues before it ality but do not necessarily end with usable software after
was too late.In one case,stakeholders from the software each subproject in the iteration.In my model,a single iter-
company’s professional-services team questioned some of ation is itself a project,so the result is software that users
the project team’s security assumptions.This caused the team will actually use.Thus,the concept is more like agile meth-
to revisit the items of concern and change the product.In ods,where the focus is on the early release of usable soft-
another case,senior management became quickly aware of ware.If the team produces commercial software,a single
problems during a project tobring the company’s products iteration would be a quarterly release.For a large in-house
into an international market.Each project team was report- project,a single iteration will release a new and enhanced
ing different dates and risk issues.This triggered warning version of the software to internal users.Real feedback is
bells that made the senior management look more deeply essential to improving the next release.
into what the company was attempting.Each team was using In my experience,most projects,even small ones,go
different techniques,and many were incorrect.If manage- through four phases:definition,implementation,stabiliza-
ment had missed this discrepancy,the whole effort would tion,and deployment.The iterative development models
have been a disaster and a costly waste of time. in agile methods recognize the first three phases,but most
12 IT Pro September ❘October 2002
Figure 1. Four stages of a single iteration within
a software development project.
Post-
project
review
Definition Implementation Stabilization Deployment
Milestone A: Milestone B: Milestone C: Milestone D: Milestone E:
• Set high-level goals • Develop budget • Implementation OK? • OK to deploy? • Close project
• Evaluate risks • Finalize goals • Any items to drop? • Finalize deployment • Set review date
• Prioritize goals • Evaluate risks and plan
• Evaluate risks and contingency plans • Set support plan
contingency plans • Evaluate risks and
contingency plans
Definition Implementation
Start of
next
iteration
A single iteration could be a quarterly release or
Milestone A: Milestone B:
an enhanced version of internal software.Unlike • Set high-level • Develop budget
other iterative development models,such as the spi- goals • Finalize goals
• Evaluate risks • Prioritize goals
ral model,each iteration produces software that
• Evaluate risks and
users actually use. contingency plans
ignore deployment.This is shortsighted because deploy- Phase 1: Definition
ment issues,such as an inadequate infrastructure or unpre- Each iteration starts with an initial meeting of major
pared support team,can cause a project to fail.Moreover, players to decide on project goals or high-level require-
killing a project at this stage is perhaps the most costly and ments for the iteration and to define initial priorities and
demoralizing:The team has seen the software through all possible risks.Project team members then investigate what
its implementation issues,but cannot see the fruit of all that they require to accomplish these goals.They get rough esti-
work.The model I propose includes a deployment phase mates of work required,collect more information on risks,
in each iteration of each subproject,as Figure 1 shows. plan the next iteration,and evaluate any new technologies
My model is suitable for both software development and for potential problems.For the first iteration,the defini-
maintenance.It might be overkill for smaller maintenance tion phase can be more elaborate because the team must
tasks,but it will work for any maintenance activity that takes still define major goals and decide on the sequence and
more than a few days.In some cases,such as a release to fix length of subsequent iterations.
a major bug,the team may have to collect a series of unre- Remember that the iteration must provide usable soft-
lated tasks to form the project’s activities.For example,some ware,not a demo.Prototypes can help you better under-
bugs may require fixes to the installer;others will require stand project needs, but they should be as simple as
fixes to the documentation;and still others to the configu- possible and created mainly within this phase.Elaborate
ration.All these might take more than a few weeks to prototypes and demos eat up time and resources that the
accomplish.Treating these maintenance activities as a proj- team could use during the implementation phase;they
ect with deliverables,risk management,and reporting will often create unrealistic expectations or requirements.
help reduce problems and delays.Of course,the lengths of Unless properly targeted,these elaborate prototypes fail
each phase could vary with an organization’s and project’s to uncover potential problems with the technologies to be
needs.For example,the stabilization phase could correspond used,interfaces,and so on.More than once I have seen
to the beta-test phase for a software company,which could customers seduced by a prototype and then focus on defin-
last a few weeks to a month or more.For an internal IT proj- ing must-have look-and-feel items like complex data entry
ect,the stabilization phase might last only a few days. forms and cool widgets.When the realities of implement-
The team can start the next iteration as soon as they com- ing the application become more obvious,the team must
plete the stabilization phase for the previous one.In such frequently drop these items,thus dashing the customer’s
cases,managers must ensure that this previous iteration expectations and wasting time.The phase ends with a
has enough time and resources to support deployment meeting to finalize the iteration’s goals,decide on the goal
issues.The team can use feedback from deployment issues priorities,evaluate risks,and accept contingency plans.The
to improve the product in the next iteration’s implemen- team usually has more goals than appear feasible for the
tation phase. iteration.Flag goals that look unlikely in light of time and
September ❘October 2002 IT Pro 13
S O F T W A R E D E V E L O P M E N T
Principles Behind the Agile Manifesto
➤ Our highest priority is to satisfy the customer is face-to-face conversation.
through early and continuous delivery of valu- ➤ Working software is the primary
able software. measure of progress.
➤ Welcome changing requirements, even late ➤ Agile processes promote sustain-
in development.Agile processes har- able development.The sponsors,
ness change for the customer’s developers, and users should be
competitive advantage. able to maintain a constant pace
➤ Deliver working software frequent- indefinitely.
ly,from a couple of weeks to a couple of ➤ Continuous attention to techni-
months, with a preference to the shorter cal excellence and good design
timescale. enhances agility.
➤ Business people and developers must work togeth- ➤ Simplicity—the art of maximizing the amount of
er daily throughout the project. work not done—is essential.
➤ Build projects around motivated individuals.Give ➤ The best architectures, requirements, and designs
them the environment and support they need,and emerge from self-organizing teams.
trust them to get the job done. ➤ At regular intervals, the team reflects on how to
➤ The most efficient and effective method of convey- become more effective,and then tunes and adjusts
ing information to and within a development team its behavior accordingly.
resources and treat them as something to attempt if time of items they are responsible for without waiting until the
permits;otherwise,they should carry over into the next last minute.In one case,stakeholders realized they had to
iteration.Make sure that everyone reviews and accepts finalize the product name soon as they kept seeing an
contingency plans,because they represent an alternative unsuitable working name on the screens and in docu-
path for the project team if the expected risk occurs. mentation.
Regular testing should also occur during this phase.
Phase 2: Implementation Because my model is limited by time,rather than require-
Team members work closely with each other and with ments,the team must be able to switch to prior software
user representatives to flesh out,implement,and test the builds if some functionality will not be usable by the cut-
requirements defined in the previous phase.This is a good off date.This means that the team should do regular builds
time to use one of the agile methods such as Extreme and have effective version control.Best practices from
Programming,Scrum,and feature-driven development, agile methods can be very useful.Doing daily builds can
customizing practices as needed. When customizing, catch problems early.Daily builds,in turn,require the team
remember the principles of agility described in the to have a working configuration management system as
“Principles Behind the Agile Manifesto”sidebar. soon as possible.Project teams should report their goals
The team works on the requirements in order of prior- and risk status to stakeholders weekly. Stakeholders
ity.A weekly demo of the evolving software to interested should also have a time and place to raise issues they see
parties helps catch potential problems during this phase.I as risks.Stakeholders are a valuable source of identifying
have often seen stakeholders surprised by what they see. risk because their universe is typically larger than that of
Sometimes they have not recognized a problem until they the team members.The stakeholder in the professional-
see it,or a miscommunication becomes clear in the demo. services group who had raised important security-related
On one of my projects,stakeholders realized during a questions, for example, was passing on what he had
product demo that major pieces required to administer learned from customer visits.
and configure the application were missing.No one had This phase ends with a review meeting to see if the
ever clearly defined them,and the developers never real- implementation is adequate and complete.
ized this problem,because they always used the database
to make the changes when they needed to test the appli- Phase 3: Stabilization
cation.These demos also help build trust because stake- In this phase,the software undergoes extensive quality
holders see the team’s timely response to their requests. assurance tests,and the team fixes major bugs.Many more
Demos also build a sense of urgency,as groups see the proj- users use the software.Documentation and support plans
ect evolve toward its goals.Stakeholders start taking care become final.This phase is crucial because the team will
14 IT Pro September ❘October 2002
Innovative New IT Titles
The Elements of UML Style
Scott W.Ambler
0-521-52547-0, Paperback, $15.00
have a truly representative sample of users.On a project to
create a new product,we found that the install program did Anytime, Anywhere
not work properly on dual-processor machines from a well- Entrepreneurship and the
known manufacturer.We had not discovered this during Creation of a Wireless World
implementation,despite extensive tests.These machines Louis Galambos and
were fairly new,and we soon found that much of our cus- Eric John Abrahamson
tomer base was planning to upgrade to them.The stabi- 0-521-81616-5, Hardback, $29.00
lization phase gave us the opportunity to make fixes before
The Simplicity Shift
we went into highly expensive disk duplication and docu-
Innovative Design Tactics in a
mentation printing.
Corporate World
This phase ends with a review meeting to see if the soft-
Scott Jenson
ware is stable and ready for deployment.When stabiliza-
0-521-52749-X, Paperback, $28.00
tion ends,a new iteration can begin in parallel with the
next phase of the old one. UML Xtra-Light
How to Specify Your Software
Phase 4: Deployment Requirements
In this phase the team deploys,or releases,the software Milan Kratochvil and
to its users.Although it is hard to pinpoint the end of this Barry McGibbon
phase,since a company can continue to deploy the software 0-521-89242-2, Paperback, $21.00
long after its first release,this phase is generally over once
Numerical Recipes in C++
all stakeholders get together for a final project acceptance
meeting.When the project is to build subcontracted appli- The Art of Scientific Computing
Second Edition
cations for an external customer,the acceptance meeting is
William H.Press,Saul A.Teukolsky,William T.Vetterling,and
a crucial milestone for the release of payments.It may also
Brian P.Flannery
represent the end of a support period.
0-521-75033-4, Hardback, $70.00
As part of the meeting,it is a good idea to set a date in
the immediate future for the post-project review,in which
Numerical Recipes in C and C++ Source Code
the team will go over everything,good and bad,about the
CDROM with Windows, DOS, or Macintosh
project with an eye toward improving the next one.The
Single Screen License
two meetings address different needs,so it is best to keep
The Art of Scientific Computing
them separate.The acceptance meeting marks the accept-
Second Edition
ance of the project deliverables and closes the project.The
0-521-75037-7, CD-ROM, $50.00
post-project review is primarily to look at lessons learned
and future improvements in project management. Numerical Recipes Example Book [C++]
0-521-75034-2, Paperback, $35.00
Unexpected risks can cause major delays and escalat-
Numerical Recipes Multi-Language Code
ing costs. Preventive risk management can help
CDROM with LINUX or UNIX Single Screen
reduce unpleasant surprises,and I have seen it imple-
License
mented successfully in many instances.Flexible develop-
Source Code for Numerical Recipes in C,C++,Fortran 77,
ment practices using proactive risk management make it
Fortran 90,Pascal,BASIC,Lisp and Modula 2 plus many extras
easier to plan for and handle risks as they occur.To imple-
0-521-75036-9, CD-ROM, $150.00
ment flexible development practices, companies must
improve team skills,and review and improve their processes Numerical Recipes Multi-Language Code
for software definition,development,and deployment.They CDROM with Windows, DOS, or Macintosh
must also put in place the management systems to effec- Single Screen License
tively plan,measure,and share information about software Source Code for Numerical Recipes in C,C++,Fortran 77,
definition,development,and delivery.With these practices, Fortran 90,Pascal,BASIC,Lisp and Modula 2 plus many extras
they can deliver better applications with fewer delays in 0-521-75035-0, CD-ROM, $90.00
spite of unexpected problems and the many requirements
and strategy changes that can happen along the way.(cid:4) Business Services Orchestration
The Hyper-Tier of Information Technology
Waqar Sadiq and Felix Racca
Sanjay Murthi is president of SMGlobal Inc.,a firm that
0-521-81981-4, Hardback, $45.00
helps companies review and improve their software defini-
tion,development,and delivery.Contact him at smurthi@ Available in bookstores or from
smglobal.com.
800-872-7423
us.cambridge.org/computerscience