Productivity Tool Deployment

advertisement
CSE Senior Design I
Deploying Productivity Tools
…a killer silver bullet
Instructor: Mike O’Dell
The slides in this presentation are derived from materials in the textbook
used for CSE 4316/4317, Rapid Development: Taming Wild Software
Schedules, by Steve McConnell.
1 What are Productivity Tools?
Tools that you use in product development
that can significantly change the way you
work
 E.g., 4GLs, visual programming languages, code
generators, advanced IDE’s, etc.
Any tool/toolset that offers (claims)
dramatic reductions in work and dramatic
improvements in schedule
NOT simply a specific brand of compiler,
linker, editor, IDE, etc. that works better
than another brand.
2
1 Deployment Considerations
FACT: These tools are often “bleeding
edge” technologies, and are fraught with
risk!
Successful deployment depends on
recognizing 3 harsh realities:
 these tools seldom produce the schedule
savings that are promised
 the learning curve lowers productivity
 tools that may be discredited as “old and
tired” by “latest and greatest” proponents can
often produce significant savings
3
1 Ineffective Tool Use (C.S. 15-1)
What went wrong at the start?
What were the “hopes” of the developers
based on Blaze-O-Matic?
What would you have done?
What tools do you use in your job (if you
have one)?
Have you had any similar experiences with
“latest and greatest” tools?
4
1 The Essence of Software
 Software programs are becoming more complex,
more detailed, more precise… not less.
 The hard part of any programming effort is the
process of thinking through the thousands of
rules, procedures, etc. that the program must
implement (Fred Brooks, 1987)
 The easy part of software development is
implementing the rules, etc. in a programming
language.
 Most productivity tools address this latter task,
but not the former.
5
1 Tools and Paradigm Shifts
 To be effective, a productivity tool must strike
at the essence of what makes software
development difficult…
the thought process of problem solving
 Examples:
 the change from low-level programming languages to
high-level languages allowed us to conceptualize a
solution at a higher (more human) level
 the use of visual-programming tools can help us
simplify the thought processes associated with the
details of developing GUI/windowing environments
6
1 Areas of Special Applicability
Some kinds of software projects are
better supported by good productivity
tools than others
 DBMS-Oriented Apps: schema generators,
report generators, query generators, etc.
 Small, Custom Apps: designs well-understood,
limited functionality, “standard” features
 Rapid Prototyping: quick turn-around,
throwaway, end user-oriented feature set
(look and feel)
7
1 In general…
 Current productivity enhancement tools help
most in the area of software construction
 The smaller and simpler a development project,
the greater the percent of total lifecycle time
spent in the construction phase
Therefore: today’s productivity enhancement
tools are most valuable on small,
simple, clearly-defined products.
8
1 Overview Summary
 Small projects and specific types of products
may benefit from the “latest and greatest, rev.
1, automated, year-saving, Blaze-O-Matic” tools
 Productivity enhancement tools are neither
necessary or sufficient for achieving rapid
development! (Glass, 1993)
 However, the best projects (Hertzel, 1993) all
rely on basic principles, such as:




strong teamwork
good communications
good organization and management
solid and effective project controls
9
1 Just remember…
There is no Silver Bullet!
10
1
Productivity Enhancement Tool
Deployment Strategy
Use them to achieve a long-term,
strategic advantage…
 NOT to get a quick win on your schedule
Your deployment strategy should include:





early identification
timely and accurate evaluation
rapid deployment if tool is effective
non-deployment if tool is ineffective
continued reliance on older, proven tools
11
1 Tool Acquisition Plan
If you wait until a tool/toolset is needed
to acquire and deploy it, you’ve waited too
long!
Make tool acquisition an ongoing activity:
 set up a tools group in your organization
 stay up with what’s going on in tools
technology, at your competition, etc.
 evaluate the tools that will benefit your
project the most (consider a pilot project)
 coordinate and disseminate within your
organization
12
1 Tool Selection Criteria
Estimated Gain: develop your own
conservative estimate for your project(s).
Vendor Stability: how long have they been
around? what do others say? will they be
around next year?
Quality: test it thoroughly during your
evaluation
Maturity: Version 1, or Version 1+?
Consider the “version 3 rule”
13
1 Tool Selection Criteria
Training Time: impact of learning curve?
who in your organization can train others?
Applicability: is this a “design-to-tools”
effort, will it really help or is it a forcefit?
Compatibility: does it work/work well with
other tools/systems that you use?
Growth Envelope: does the tool support
the direction that expect, or might want,
your product to go?
14
1 When to Deploy a New Tool
Length of
Project A
Length of
Project B
PRODUCTIVITY
Nominal productivity, or level
before new tool is introduced
Productivity gained
Productivity lost
Initial productivity after
new tool was introduced
(drop due to learning curve)
TIME
15
1 Training for a New Tool
Rule of Thumb: the more powerful a new
tool, the more difficult and timeconsuming it will be to use effectively
 e.g., using a new, high-capacity backhoe for
commuting to and from the ditch you’re
digging with a shovel
Don’t underestimate the difficulty of
getting the real benefits of a new tool
16
1 Silver Bullets
The biggest risk associated with
deployment of new tools is the silver-bullet
syndrome!
 we all really, really want to believe in magic!
Hard, Cold Fact: we should dismiss most
claims of massive productivity
enhancements and schedule improvements
out of hand.
17
1 Identifying Silver Bullets
Fourth Generation Languages (4GLs)
 incremental gains, not revolutionary
 last really large gain was on move from
assembler to 3GLs
CASE Tools
 potentially valuable in database-intensive
environments
 in most organizations, CASE tools are just
used as high-end tools for creating design
diagrams.
18
1 Identifying Silver Bullets
Rapid Application Development (RAD)
 collection of IS-oriented practices
 can work well in some environments
 typically NOT good for any type of unique
software (e.g., custom, system, shrink-wrap)
Automatic Programming
 the real problem is not the programming, it’s
the conceptualization of the problem and its
solution
 a long-term promise… not kept!
19
1 Identifying Silver Bullets
Object-Oriented Programming
 powerful, in terms of maintainability and
reusability
 has fallen well short of the promises of
naturalness and ease of use… and consequently
the productivity gains in rapid development
projects
Bottom Line: there are no silver bullets!
20
1 Effective Tool Use (C.S. 15-2)
What’s different about this approach,
form that in C.S. 15-1?
What are some of your personal
experiences with use of effective and/or
ineffective productivity enhancement
tools?
How can/will any of this be applied to your
Superior Designs, Inc. projects?
21
1 Summary: Productivity Tools
Productivity tools seldom produce the
results claimed by their suppliers/vendors
Learning to use a new productivity tool or
practice initially lowers productivity
Deployment of productivity tools should be
part of long-term tools strategy, not quick
fix or a solution to a short-term issue
22
Download