Transcript INFO 631 Prof. Glenn Booker Week 10 – Chapter 27 INFO631 Week 10 www.ischool.drexel.edu.

INFO 631
Prof. Glenn Booker
Week 10 – Chapter 27
INFO631 Week 10
1
www.ischool.drexel.edu
Closing Remarks
Ch. 27
Slides adapted from Steve Tockey – Return on Software
INFO631 Week 10
2
www.ischool.drexel.edu
Closing Remarks
Outline
•
•
•
•
Review: decision process
Review: book
Revisit primary message
Revisit secondary message
INFO631 Week 10
3
www.ischool.drexel.edu
Review: The Decision Process
Define the
selection criteria
Understand the
real problem
Identify all
reasonable
technically -feasible
solutions
Select the prefe rred
proposal
Evaluate each
proposal against the
selection criteria
Monitor the
performance of the
selected proposal
INFO631 Week 10
4
www.ischool.drexel.edu
Comments on the Process
• This same process applies at all levels of
business decision
– Smaller scale decisions can be done less
formally
• The process is more fluid than implied
– Steps can be overlapped or parallel
– Steps can be done in different orders
– Steps may be iterative
INFO631 Week 10
5
www.ischool.drexel.edu
Review the Book
•
•
•
•
Understand the real problem (Chapter 4)
Define the selection criteria (Chapter 4, 26)
Identify all reasonable technically-feasible solutions (Chapter 4, 9)
Evaluate each solution against the selection criteria (Chapter 4, 26)
– Developing cash-flow streams (Chapter 3)
•
Select the preferred proposal
–
–
–
–
–
–
•
Part II: for-profit organizations
Part III: additional accuracy in for-profit organizations
Part IV: not-for-profit organizations
Part V: break-even analysis and optimization analysis
Part VI: estimation, risk, and uncertainty
Part VII: multiple attribute decisions
Monitor performance of the selected solution (Chapter 4)
INFO631 Week 10
6
www.ischool.drexel.edu
Revisit the Primary Message
• Every day, software professionals make decisions that
affect the costs and revenues of our employers
– These decisions are usually made from a purely technical
perspective, but can have serious business implications
• Having seen the concepts and techniques in this book,
let’s examine some important decisions that a typical
software organization faces, but from a business
perspective:
–
–
–
–
–
Which software project(s) should we do?
Should we add new features or fix known defects?
Should new technology X be used on this project?
Which software development lifecycle should we use?
How much software testing is enough?
INFO631 Week 10
7
www.ischool.drexel.edu
Which Software Projects Should We Do?
•
•
•
Identify candidate software projects: the proposals (Chapter 3)
Develop cash-flow streams for each proposal (Chapter 3)
Identify mutually exclusive alternatives (Chapter 9)
– The best choice might be some combination of proposals
•
Use the decision-making techniques in for-profit (Part II) or not-for-profit
(Part IV) organizations as appropriate
– In for-profit organizations, if more accuracy is needed then also use the
advanced for-profit decision techniques (Part III)
•
Since the decision is based on estimates, techniques like ranges of
estimates, sensitivity analysis, or delaying final decisions (Chapter 23) could
come in handy
– If there are other significant risks or uncertainties in any of the alternatives (e.g.,
are any of the proposals likely to overrun their cost, schedule, or quality goals? If
so, by how much?) the decisions under risk (Chapter 24) or decisions under
uncertainty (Chapter 25) techniques can be applied as appropriate
•
If other non-financial decision criteria are relevant the multiple attribute
decision techniques (Chapter 26) can be used
INFO631 Week 10
8
www.ischool.drexel.edu
Should We Add New Feature or Fix
Defects?
• Each new feature—and fixing each known defect—can be treated
as a proposal
• Group sets of related features and/or defect fixes into “packages”
where each package is a useful collection of new features and/or
defect fixes
– Mutually exclusive alternatives correspond to completing the packages
in different orders. With the three packages, A, B, and C:
• ABC
• ACB
• BAC
• BCA
• CAB
• CBA
• Develop cash-flow streams for each alternative
• Complete the decision making process
INFO631 Week 10
9
www.ischool.drexel.edu
Should New Technology X be Used on this
Project?
• Mutually exclusive alternatives:
– Use the proposed new technology
– Use some existing, already-known technology
– Develop the capability on your own (not always viable)
• Develop cash-flow streams for each alternative
• Complete the decision making process
• Likely to be risk or uncertainty with the new technology
alternative(s)
– Use decisions under risk (Chapter 24) or decisions under
uncertainty (Chapter 25)
INFO631 Week 10
10
www.ischool.drexel.edu
Which Software Lifecycle Should We Use?
• Dozens of different software development lifecycles
– Almost religious debate between the advocates of each
– Recent major debate between the plan-based lifecycle advocates and
the agile lifecycle advocates
– Should be seen as selecting the right tool for the job
• Development lifecycles can be seen as a spectrum
– Plan-based projects plan the entire project from the start to finish and
usually includes a minimum of iteration and feedback
– Agile projects planning but only for the current iteration, usually two to
four weeks
– Middle-of-the-road development lifecycles use a small number of
iterations of two to four months each
• “Rolling wave planning”
INFO631 Week 10
11
www.ischool.drexel.edu
Optimum Duration for Plan-based Projects
Optimum duration
Total
cost
Cost
Iteration
overhead
Cost of requirements change
Iteration duration
INFO631 Week 10
12
www.ischool.drexel.edu
Optimum Duration for Agile Projects
Optimum duration
Total cost
Cost of
requirements
change
Cost
Iteration overhead
Iteration duration
INFO631 Week 10
13
www.ischool.drexel.edu
Which Lifecycle? (cont)
• Likely to be a multi-attribute decision:
– How quickly does that lifecycle deliver
functioning, usable software to the user?
– How important to the stakeholders is progress
visibility and how well does that lifecycle
provide visibility?
– What lifecycles does the project team already
know?
INFO631 Week 10
14
www.ischool.drexel.edu
How Much Software Testing is Enough?
• A difficult question for many software organizations
– Approaching it from the wrong perspective
– Not a technical question a business question
• Shipping software products exposes the software organization to
product liability
– In internal IS organizations, non-profits, and government organizations,
putting defective software into production exposes the organization to
the risk of lost data, lost production time, ...
• Essentially an optimization question, decision variable is how much
testing to perform
– More testing lowers the organization’s exposure to risk
– More testing increases testing costs and delays putting the software into
productive use for the customer
• Test until cost of more testing becomes higher than the value of the
risk reduction plus the lost business benefit of not having the
software in use
INFO631 Week 10
15
www.ischool.drexel.edu
Secondary Message: Software Engineering
vs. Computer Science
•
“Engineering” is a well-defined term
– Use relevant theory to generate as many possible solutions as reasonable then
using business criteria (engineering economy) to select the most cost-effective
one
– Book actually describes the engineering process
•
According to the engineer’s definition of engineering, software development
is not, today, a legitimate engineering discipline
– Wanting our work to be considered engineering and continually saying that it is
does not make it so
– We, as an industry, need to recognize what is truly required of legitimate
engineering disciplines and take positive steps to fill the gaps (see for example,
[Hooten90], [McConnell03], [Shaw90], [SWEBOK01])
To accurately call yourself a software engineer, you need a strong
foundation in computer science and discrete mathematics. But that’s not
enough: you also need a strong foundation in engineering economy so
that your software technical decisions are aligned with the goals of
the organization
INFO631 Week 10
16
www.ischool.drexel.edu
Key Points
• In the end it’s all about making choices
– Software professionals are faced with choices every day
– But even apparently innocuous choices can have a noticeable effect on
the organization’s finances
• As professionals, we need to be making responsible choices
– Choices that make sense both technically and to the organization
… software economics has often been misconceived as the means of estimating the
cost of programming projects. But economics is primarily a science of choice, and
software economics should provide methods and models for analyzing the choices
that software projects must make. [Levy87]
• Using the methods and models here, software technical decisions
can be aligned with the goals of the organization
INFO631 Week 10
17
www.ischool.drexel.edu