|
|
|
|
These books and
reports may prove useful for software developers, managers and those involved
in understanding, improving or measuring software or software development
practice. We are continually adding more to the list. If you have a particular
book you would like listed here please email us at info@osel.co.uk.
|
|
|
|
|
|
|
|
|
|
59. Making Process Improvement Work, by
Neil S. Potter and Mary E. Sakry, pub Addison Wesley, 2002, ISBN-13 978-0201-77577-8,
ISBN-10 0-21-77577-8/ This is one of the best books on
software process improvement.
The many endorsements are an accurate reflection of its quality. It is
a very clear and concise guide (only three chapters) on how to improve software
development practice. It should be read by anyone involved with process
improvement - especially if they are using CMMI or similar process models.
Potter and Sakry offer guidance on how to focus on real improvement, rather
than getting seduced by model compliance. There are plenty of useful
techniques and tools for directing and managing SPI work, measuring progress
in terms of business benefits and lots of good advice too.
|
|
|
|
|
|
|
|
|
|
58. Creating a Software Engineering Culture,
by Karl E. Wiegers, pub Dorset House, 1996, ISBN 0-932633-33-1
This book was acquired as preparation for
Tom Gilb’s ‘Changing Culture’ seminar earlier this year. As you would
expect from Karl Wiegers this is a sound, well considered and lucid book,
based largely, I suspect, on the author’s own experience. It describes the
fundamentals of process improvement and provides many hints and tips on what
to do to encourage good practice. Just as useful, it describes what will
de-rail attempts to improve. The author presumes that the objective of
process improvement, reflected in the title, is to develop a software engineering
culture. It is worth bearing in mind that this is now a software development
niche. Software development is undertaken in an enormous variety of contexts
and cultures and software development, performed by engineering oriented
developers (making embedded systems, avionics and the like) is only one of
these. As such some of the techniques and methods proposed may cause difficulties.
Inspections and SQA spring to mind. Never the less as a guide for managing
change and encouraging good practice this is a very useful (if slightly
dated) book. CCS July 2009
|
|
|
|
|
|
|
|
|
|
57. A variety of measurement books: This collection,
together with those others listed below, should equip anyone to understand,
and make a reasonable job of measuring software or software development
processes. These don’t deal with software measurement specifically, but I
increasingly believe that thinking in terms of specifically ‘software
measurement’ is unhelpful, ‘ghettoizing’ the subject and closing off
necessary ideas dealt with so well in other areas.
The first, and most
important, is Tukey’s Exploratory Data Analysis, by John W. Tukey, pub.
Addison Wesley, 1977, ISBN 0-201-07616-0. This is a classic text,
idiosyncratic but easy to read, describing deceptively simple techniques to
explore and extract information from data. These techniques are ideally
suited to software engineering data, but they are little known and rarely
encountered in the software world. Its methods can be used to establish the
character of unusual or ‘messy’ data, re-express it in meaningful and useful
ways. An important book, neglected by the software measurement community to its
cost. Copies can still be acquired second hand, but they are expensive.
The second was
recommended at the last of Tom Gilb’s seminars. Everyone had apparently heard
of this apart from me. It is The Logic of Failure: Recognizing and avoiding
error in complex situations, by Dietrich Dorner, pub. Basic Books, 1996,
ISBN-13: 978-0-201-47948-5, ISBN-10: 0-201-47948-6. It
describes how difficult it is to manage complex situations over time, even
with measurement data. This failure is then analysed and the,
apparently simple, steps needed to fix it described. It is easy to be amused
by the failures described in this book and assume that we would do better.
The value of this book is in recognizing how we make the same mistakes
ourselves, and then take the steps prescribed ourselves.
Next is Taleb’s The
Black Swan: The impact of the highly improbable, by Nassim Nicholas Taleb,
pub. Penguin, 2007, ISBN 978-0-1410-3459-1. This is the follow up to his
earlier ‘Fooled by Randomness’ (also worth reading) This highly, and
deliberately?, discursive book looks at the nature of uncertainty and the
attempts to predict the unpredictable. Taleb clearly has an agenda and lays
into statistical ‘gurus’, including Nobel prize winners, with a vengeance. He
also introduces his statistical and philosophical heros. The misapplication
of conventional ‘Gaussian‘ statistical models in ‘Extremistan’ – most of the
world, where data ‘scales’ - is taken to task. (Mediocristan is the
territory where Gaussian and other parametric statistical tools do
work.) Conventional statistics get a rough ride, unfairly so, as the
author acknowledges, but this is understandable seeing how it is so often so
badly used. The final sections of the book deal with some of the statistics that
have talked about earlier and presents some truly startling statistical facts
that reinforce his views about the nature of data in the real world. Some
approaches and tactics to deal with ‘unknown unknowns’ are described, and
there are thought provoking ideas, but a lot of distractions too. Not an easy
read, sometimes the language is unclear and requires rereading several times
to make clear what is meant, and an occasionally irritating style, but worth
it.
Finally there is
Douglas Hubbard’s How to Measure Anything: Finding the value of
intangibles in business, by Douglas W. Hubbard, pub Wiley, 2007, ISBN
978-0-470-11012-6. This is the polar opposite of Taleb’s book. (It
would be interesting to see Hubbard and Taleb compare ideas.) Hubbard’s book
is cast as a ‘business book’, but is in fact very good. It looks at the
difficulties people have measuring. The c – o – m model will be particularly
useful; many efforts at measurement fail because people just do not believe
it can be done, or think it is some sort of technical magic. The book then
looks at measurement from a classical statistical perspective, dealing with
the need for appropriate levels of accuracy and precision, and the need for
sufficient data, which can be remarkably low. Estimation ‘calibration’,
statistical modelling (in particular Monte Carlo methods, which seem to be
the coming thing) and the need to experiment and develop ideas, models and
measures are presented clearly. There is also an excellent section on
Bayesian approaches, something often presumed impenetrable except for the
statistical priesthood. There are discussions about the softer aspects of
measurement and the book is backed by some tools that can be downloaded from
the website. If there is a criticism it is that the layout of some of the
technical sections could be clearer. Discussion of formulas or expressions is
embedded in text. I found this difficult to follow. A more traditional
layout, with lots of white space would be preferred. CCS November 2008
|
|
|
|
|
|
|
|
|
|
56. Statistical Quality Control Handbook,
Western Electric Company, 1956.
This is a working handbook prepared for Western Electric people to enable
them to use statistical quality control. It is an exceptional book. It
clearly and persuasively describes many widely applicable, practical,
powerful and elegant statistical techniques to solve manufacturing and
quality problems. Its importance to software developers is as a model of
engineering practice. The software development community (and in particular
the SEI) is searching for similar statistical approaches to assist in the
management and control of quality for software. This book should be studied
for its wisdom and clarity, and used to set the standard for a similar text
for software engineers. If quantitative approaches of similar practicality
and power can be developed for the peculiar challenges software presents,
without slavish imitation of manufacturing SQC techniques, then software
development may have a claim to being software engineering. CCS June 2008
|
|
|
|
|
|
|
|
|
|
55. Dreaming in Code, by Scott Rosenberg,
pub. Three Rivers Press, 2007, ISBN 978-1-4000-8247-6.
Very entertaining story of the development of ‘Chandler’, an OS Outlook/Agenda/PIM
product by a team set up by Mitch Kapor. Developers will recognize many of
the things that make software development what it is - the author is a keen
observer of techies doing techy things. Having said that I got the very
distinct impression that the team was not one I’d want to get too close to –
way too many big names, way too much navel gazing and high concepts, no real
deadlines either. I found myself wanting to tell them to just get on with it
(I must be turning into a manager). There’s some interesting discussion on
how software is developed, taking in CMM through to the agile manifesto, and
by who – artists or engineers? As it says on the cover – ‘successor to The
Soul of a New Machine’ – good read. CCS April 2008
|
|
|
|
|
|
|
|
|
|
54. Assessment and Control of Software
Risks, by T Capers Jones, pub. Yourdon Press (Prentice Hall), 1994, ISBN
0-13-741406-4.
This is a wide ranging, intelligent and occasionally provocative review of the
ills of software development. It takes its structure from the 'Control of
Communicable Diseases in Man'. This works well - easy to navigate, thoughtful
analysis, often backed up with data.
This book should probably be considered as
obsolescent now, but it has so much useful information and cues for valuable
checklists I believe it's a classic. CCS April 2008
|
|
|
|
|
|
|
|
|
|
53. CMMI Second Edition: Guidelines for
Process Integration and Product Improvement by Mary Beth Chrissis, Mike Konrad
and Sandy Shrum, 2007, Addison Wesley, ISBN 0321279670.
The revised reference for CMMI has had the structure simplified and some of
the process areas merged, in particular IPPD is de-emphasised, and ISM, IT
and OEI deleted. (see 32 below). Common features have now disappeared, which
is a pity, and the continuous representation has all but disappeared too,
another pity. CMMI is now quite remote from software development, TS and PI
say little of interest and VER is too vague. It concentrates on project and
process management. This book still contains a lot of wisdom, CMMI and its
predecessor CMM, knew where to borrow from, but increasingly this wisdom
turns up in odd places: in the introductory section, the hints and tips in
the margins, and odd sentences scattered throughout the text. None of this
really matters now: this is the standard text used by the assessment industry
and all those chasing MLs. CCS April 2008
|
|
|
|
|
|
|
|
|
|
52. Engineering and the Mind’s Eye, by Eugene
S. Ferguson, pub. MIT Press, 1992, ISBN 0-262-06147-3.
This book was recommended by Michael Jackson at a recent BCS FACS meeting. It
isn’t directly concerned with software engineering, but the engineering
process and the visualization of engineering artefacts. It gives fascinating
insights into the design process and, since software development is a design
process, software development, and the way software developers communicate,
and fail to communicate. A small book stuffed with ideas. CCS June 2007
|
|
|
|
|
|
|
|
|
|
51. Agile Estimating and Planning, by Mike
Cohn, pub. Prentice Hall, 2006, ISBN 0-13-147941-5.
The list of citations for this book on the inside cover gives an indication
of its value. It’s unusually readable, and describes many of the situations
and issues encountered by software developers when involved in planning or
estimating, but that are not dealt with in most books on the subject. Mike
Cohn consistently gives good advice and describes useful techniques. Don’t
worry about this being about agile estimation and planning most of the
techniques can be adapted for other environments. The only criticism of this
excellent book is it’s too wordy. It could have been half the length. Never
the less if you are involved in any form of software estimation or planning
get this book – an instant classic. CCS Feb 2007
|
|
|
|
|
|
|
|
|
|
50. Software For Your Head: Core Protocols
for Creating and Maintaining Shared Vision, by Jim and Michele McCarthy, pub.
Addison Wesley, 2002, ISBN 0-201-60456-6.
The authors have set out to identify those things that make teams take off
and really perform, and the things that stop them performing. This has been
achieved at the McCarthys’ ‘boot camp’ by creating teams, making them
perform, and analysing their performance. The results are set of patterns
that can be learned and used, and corresponding antipatterns to be recognized
and avoided or eliminated. The results presented in this book are impressive,
but unsettling. The patterns may well be uncomfortable or embarrassing to
introduce and adopt, requiring team members to act with more integrity and
candour than is usual, and many of the antipatterns describe behaviour that
most team members will recognize in themselves. The McCarthys don’t pull
their punches either. No concessions are made to appeals the ‘real world’: to
build high performing teams delivering excellent intellectual property team members
must understand and value themselves, visibly and openly commit to
themselves, the team and the team’s vision, and recognize and eliminate the
second rate, faux pragmatism and the bogus. The prize is the pleasure and
satisfaction many will know from working on high performance teams, and the
‘can do’ belief and ability of the team to do almost anything. This book is
not an easy read, it will make you aware of your own, and your team’s
limitations, is perhaps longer that it needs to be and the writing can be
verbose, and occasionally pompous, but it is filled with wisdom and insights.
And it does present very clear models of behaviour rather than the usual
rather vague advice and mumbo jumbo. This may be an important book, the ideas
certainly are. CCS July 2006
|
|
|
|
|
|
|
|
|
|
49. Test Process Improvement: A practical
step-by-step guide to structured testing, Tim Koomen and Martin Pol, pub.
Addison Wesley, 1999, ISBN 0-201-59624-5.
TPI is a model of testing practice based loosely along CMM and SPICE lines,
but scoped to software quality control. It uses maturity/capability type
ideas to describe increasingly more sophisticated testing practice and in
doing so enables testers to gauge their testing practice and provides
guidance on where to focus their efforts to improve testing. Like CMM and
SPICE, TPI can be mined for good ideas and good practice or provide a roadmap
for strategies to improve test effectiveness. The book not too thick - about
200 pages - and is reasonably easy to read and understand, although the text
appears to have suffered a little from translation from the Dutch. The model
itself appears reasonable but does not have the rigour or accountability of
CMM. There are some ambiguities and inconsistencies in the model but these do
not seem to have any significant impact on its usefulness (in fact this
‘cheap and cheerful’ approach is a refreshing change from the increasingly
over-engineered, over-produced CMMI). If there are any criticisms it is the
treatment of technical reviews which is not very clear, and of process
improvement, actually making the changes to testing practice itself, which is
not altogether convincing or useful, but these are minor points. As guide for
structured and practical improvements to testing practice this is a useful
resource. CCS January 2006
|
|
|
|
|
|
|
|
|
|
48. Measuring and Managing Performance in
Organizations, by Robert D. Austin, pub. Dorset House, 1996, ISBN
0-932633-36-6.
This book explores measurement dysfunction – why it doesn’t work as expected.
And, usefully, takes the measurement of software development as its focus
because it encapsulates so many of the issues of performance measurement.
Austin develops a model for reasoning about measurement and uses this to look
at performance measurement’s fragility, and the motivations of the measured,
the measurers and the experts. It describes how performance measurement is
treated in different cultures and suggests where the value of measurement
really lays. This book will disturb and provoke those involved in software
measurement, especially consultants. It is all the more disturbing because it
convincingly reveals the reasons behind so many of the software measurement
problems we encounter. CCS July 2005
|
|
|
|
|
|
|
|
|
|
47. CMMI Assessments: Motivating Positive
Change, by Marilyn Bush and Donna Dunaway, pub. Addison Wesley, 2005, ISBN
0-321-17935-8.
The SEI’s reference text for Assessments. A comprehensive guide to
assessments describing the what, why and how of assessments by two of the
people that helped develop the CMM and the assessment process. Essential if
you are planning an assessment and want to get the best from it. Provide each
of your assessment team members with a copy. CCS June 2005
|
|
|
|
|
|
|
|
|
|
46. What is this thing called Theory of
Constraints and how should it be implemented? by Eliahu M. Goldratt, pub. North
River Press, 1990, ISBN 0884270858.
Why didn’t someone tell me about this before? A thin ‘management’ style book
on process improvement by the originator of the Theory of Constraints (TOC)
and author of ‘The Goal’, a process improvement novel - yes really. It
describes how to identify real limitations on systems, and how to control and
use them. It has two parts: part one describes the theory of constraints;
part two describes how to make changes. CCS April 2005
|
|
|
|
|
|
|
|
|
|
Some background reading for process
engineers, and other involved in managing change:
45. How to Win Friends and Influence
People, by Dale Carnegie, pub. Vermillion, ISBN 0-7493-0784-6.
A dated and quaint style now, but the
guidance is as true as ever. Look through the cliché title; it really does
describe how to influence people.
44. The Prince, by Niccolo Macheavelli, pub. Penguin, ISBN
0-14-044107-7
Describes how things are, rather than how
we’d like them to be. The section on changing the status quo is still true.
|
|
|
|
|
|
|
|
|
|
43. Measurement Theory and Practice: The
World Through Quantification, by David J. Hand, pub. Arnold, 2004, ISBN
0-340-67783-X.
This book will be of interest to software engineers wanting to understand measurement
and get it right. It takes up where Fenton leaves off (See 12 below). There
is a history of the development of measurement, a comprehensive description
of the nature of measurement itself; its theoretical foundations,
pervasiveness - and consequential invisibility. The nature of
measurement in different disciplines is discussed – in psychology, medicine,
physical sciences, economics... and briefly software. The difficulties and
controversies and limitations of measurement are also revealingly discussed;
showing that the problems encountered measuring in software engineering are
not unique, and many solutions have been found in other disciplines, but that
serious work is required to overcome them. This book is densely written, with
some maths and will require serious study, but for those committed to
software measurement it is a compelling and illuminating read. CCS April
2005
|
|
|
|
|
|
|
|
|
|
42. Facts and Fallacies of Software Engineering,
by Robert L. Glass, pub. Addison Wesley, 2003, ISBN 0321117425.
Robert Glass presents 55 facts and 5 + 5 fallacies of software engineering.
Actually they’re not facts; they’re very well founded opinions backed up with
references and data. And that’s the important signal sent by this book.
Software engineering is not developing as a discipline because hard won
knowledge is lost or ignored as soon as it’s gained. We need books like this
to encapsulate some of the eternal verities that tend to be forgotten in the
enthusiasm for the latest nostrum. Each fact is presented as a one liner –
“Fact 7 – Software developers talk a lot about tools. They evaluate quite a
few, buy a fair number and use practically none.” And then this is developed
in a page or two of discussion. The controversies that these statements are
likely to provoke are outlined and sources and references provided. The facts
and fallacies will be recognized by most experienced software engineers and
managers, but somehow seem to be overlooked in day to day work. Several times
the absurdity of software engineering practice, as practiced, is highlighted,
and our inability to break out of these destructive habits discussed.
The book is deliberately modelled on Alan Davis’s ‘201 Principles of Software
Development’ – see 31 below, and Alan Davis provides the forward. Each of the
facts or fallacies is covered in a few pages, easy to read and absorb. So
what is the book for? It’s a map of the software engineering terrain showing
where some of the pitfalls are, but it doesn’t contain methods or techniques
that can be extracted and used. It is more of the nature of ‘hints and tips’
for software engineers. Perhaps one use would be to extract the facts
as sets of checklist items to be used at key points during software
development or as concise arguments to be deployed when some sub optimal path
is proposed. It should be included in software engineering student’s reading
lists. CCS March 2005
|
|
|
|
|
|
|
|
|
|
41. Lean Software Development: An Agile
Toolkit, by Mary & Tom Poppendieck, pub. Addison Wesley, 2003, ISBN
0-321-15078-3.
This is Mary and Tom Poppendieck’s take on agile software development. It
takes its cue from lean manufacturing practice and develops this as seven
principles supported by twenty two tools. Those familiar with agile
approaches will find much that is familiar, the difference here is the
lessons learned from other manufacturing disciplines: Toyota’s seven wastes
is adapted for software, with a useful reinterpretation of unnecessary
motion, something that I instinctively reacted against in its manufacturing
incarnation. There are also some thought provoking sections on queuing theory
and cost models for software products and applications. The tools, many
familiar, cover the spectrum of software development practice from the
technical: iteration, refactoring, developer/customer testing, through to the
human and social aspects; management, leadership, motivation. I particularly
liked the value stream map – simply sketch out the timeline to get a change
or feature into use. They are quite rude about traditional project
management, claiming it is the wrong model for managing software development,
over-emphasising cost and schedule, and are (just about) polite about the CMM
but dismissive of CMMI. Chapter eight provides some advice on making lean
software development happen; good advice to moderate the over zealous. There
is also a brief section describing software development cultures, what they call
‘special work environments’ – government contract, safety critical,
distributed development…etc. It is a pity this was not developed more.
Understanding the needs and constraints of these different environments is
critical to the success of new or changed development practices. This is a
good read, it will engage you. I found myself thinking ‘Yes, but…’ time and
time again. I wanted to discuss this with the authors. There are a
couple of reservations. I wonder if there is enough information in the book
to try to use the tools listed. One, measurement, has some interesting ideas
– measure up to avoid sub-optimization – but measurement is discussed very
briefly almost as problem rather than a tool. There is also a degree of
partisanship, which is fun but can be unhelpful; this is part of the
publishers Agile Software Development Series. These are serious ideas, but
the tone may be misinterpreted to imply that everything else is wrong;
controls and software engineering disciplines, advocated and described at
length in models such as the CMM can be discarded. I hope this is not
intended. All software development requires disciplines and controls, as the
authors acknowledge, but their application lies on a very broad spectrum. An
important skill for software (production) engineers is selecting the right
approaches, rather than being faced with an Agile/Non Agile(?) dilemma. Good
book, but read carefully and critically. CCS March 2005
|
|
|
|
|
|
|
|
|
|
Two recommendations from Dez Cass at BAE Systems.
Both these are available from Amazon. “I have two books that I have
referred to on many occasions when struggling with the deployment of
quantitative management techniques in the software world. These are:
40. Understanding Variation. The Key to
Managing Chaos, Donald Wheeler, SPC Press,
ISBN 0-945320-35-3
39. Measuring the Software Process.
Statistical Process Control for Software Process Improvement
William Florac & Anita Carleton,
Addison Wesley, ISBN 0-201-60444-2 - (highly recommended)”
|
|
|
|
|
|
|
|
|
|
38. Refactoring: Improving the design of
existing code, by Martin Fowler, pub. Addison Wesley, 1999, ISBN
0-201-48567-2.
Finally got around to reading it – and enjoying it too… looking good, but a
way to go yet. I’m not sure whether I haven’t ‘got it’ yet or it’s obvious
good practice. If nothing else it’s a painless way to improve your Java… but…
|
|
|
|
|
|
|
|
|
|
37. Test-Driven Development: By Example, by
Kent Beck, pub. Addison Wesley, 2003, ISBN 0-321-14653-0.
As it says on the back cover ‘A new idea? Not at all…’ TDD isn’t a new idea,
but it is a good one. It is described here clearly and simply by the person
who has developed it. Much of TDD will be recognized by those software
developers that habitually test as they code. TDD develops this approach as a
tool-supported, automated method for producing defect free code, and as a way
of reducing uncertainty and fear - programmers will recognize that too. The
scope TDD is difficult to describe in conventional test terms. It is
recognizably related to the code/debug cycle and traditional unit test, but
its completeness and suitability as a complete testing solution, replacing
conventional integration and system test too, especially for large complex
systems, should be considered carefully. Part one is worked examples in Java
using JUnit. Part two develops xUnit in Python, using TDD of course, and part
three describes some testing patterns and the characteristics of TDD. This is
not a reference book but an ideas book; work through it to understand the
approach. If you are looking for a test ‘cook book’ this isn’t it. If there
is a concern it is that TDD integrates testing with producing code so
closely, with tests and code growing together, that the tests may be
compromised; that the tests and code converge on getting a ‘green’ to
demonstrate the code works rather than searching out defects. That said TDD
requires tests first, then code, and that is far better than the usual
code/debug/hope for the best cycles employed by many. CCS November 2004
|
|
|
|
|
|
|
|
|
|
36. The Visual Display of Quantitative
Information by Edward W. Tufte, pub. Graphics Press, 1983.
Describes how to design correct and informative graphics from numerical data.
Anyone producing statistical presentations will probably turn to computer
software tools. This book will help limit the excesses those packages
encourage. It is a very useful, and beautiful, book. CCS November 2004
|
|
|
|
|
|
|
|
|
|
35. Design Methods: Seeds of human futures
by J. Christopher Jones, pub. Wiley, 1980, ISBN 0 471 27958 7.
This book is out of print now and may be difficult to get hold of. I got our copy
second hand from Amazon; it apparently came from Bell Labs (Indian Hill). It
is a strange book, not directly related to software engineering; the author
is an industrial designer interested in the design process itself. The book
attempts to describe a set of design approaches and when they should be
applied. In describing these methods the author recognizes the true nature of
design – the uncertainty, false starts, confusion and muddle essential for
creativity – and understands that methods are tools for directing this
creative process. Like Christopher Alexander’s books this one touches on
something recognizable to every software engineer, and in particular will
strike a chord with those in the agile camp. Approached with an open mind
there is a lot to be mined from this book. If you are involved in process
improvement you could find something useful here too. For several years now
we have been attempting to identify and describe the tools for good process
improvement and these seem to have many of the same characteristics of Jones’
design methods. It’s not an easy read, and it may be difficult to get hold of
a copy, but if you have an interest in how software engineering is really
done, beyond the bald facts of proprietary methods and tools it’s worth hunting
down a copy. CCS October 2004
|
|
|
|
|
|
|
|
|
|
34. High Quality Low Cost Software
Inspections by Ronald A. Radice, pub. Paradoxicon, ISBN 0964591316.
This book is a Trojan horse. The focus is on inspections but it contains far more.
It gives a fascinating history of the development of inspections and the
background to my yellowing copies of IBM’s inspections specifications.
It has a very clear description of the inspection process itself and the
roles of the inspection moderator and other players are discussed in depth.
All of this is supported with a detailed commentary and useful checklists and
templates. If you are interested in software quality or are considering
introducing, re-introducing or resuscitating inspections in your organization
then this book will be a major resource. Buy copies for all your moderators –
supply each of your moderators with a copy when they successfully complete
their moderator training perhaps? What you also get in this book is a
convincing demonstration of the value of measurement - there are numerous
examples of the sensible use of measurement - and causal analysis, real
process improvement. These is also get a chapter discussing the economics of
inspections, if you hadn’t already been convinced of their value. The author
is an ex IBMer and it shows. The downright, rational, engineering orientation
is clear throughout. It has much in common with the books of Stephen Kan and
Bob Grady. This should be borne in mind when using this book - many organizations
just will not recognize the value of inspections, as the author clearly
knows. This is the first time I have seen a discussion, in print, of the need
and value of process data integrity. Raising this issue is often seen as some
form of bad manners. This is the first edition of this book and there are a
number of typos and other minor errors but this in no way detracts from the
value of this important book. Buy it. CCS September 2004
|
|
|
|
|
|
|
|
|
|
33. Juran’s Quality Handbook, Fifth
Edition, edited by Joseph M. Juran, A Blanton Godfrey, Robert E. Hoogstoel
& Edward G. Schilling, 1999, McGraw Hill, ISBN 0-07-034003-X.
A major resource for everyone involved in understanding industrial quality
management. Contains almost everything you could want to know about quality
in manufacturing. It is also well written and easy to read so you can trawl
through it for ideas and have it spark off new ideas too. Strangely the
section on software development (20) isn’t particularly useful - interesting
yes - but seems to lack the focus of the other areas. Don’t let this put you
off though. There are huge amounts of material throughout this book that can
be applied to software development. A great book that you should have access
to.CCS February 2004
|
|
|
|
|
|
|
|
|
|
32. CMMI: Guidelines for Process
Integration and Product Improvement by Mary Beth Chrissis, Mike Konrad and
Sandy Shrum, 2003, Addison Wesley, ISBN 0-321-15496-7.
This is the reference for the CMMI models now in book form. The first part
describes the CMMI; its rationale, use, and the structure to enable you to
navigate the process areas. Those familiar with the SW CMM will find much
that is familiar but recast, with some welcome elaboration, in this expanded
model. In particular the incorporation of Basili’s GQM is to be welcomed.
Those new to process and process improvement may be dismayed by the rather
abstract and complex structures presented. Part two defines the process areas
themselves. This is the heart of the book and the major resource for those
working to improve performance. Like the SW CMM much of the value of the
models is implicit - the structure of the processes and way they are
described says as much about process engineering as the content. The content
is simply good practice ready to be mined by process engineers. Like the SW
CMM it is worth bearing in mind where this model comes from; part three lists
the product team, steering group and reviewers. CCS 2003
|
|
|
|
|
|
|
|
|
|
31. 201 Principles of Software Development
by Alan M Davis, 1995, McGraw Hill, ISBN 0-07-015840-1.
This book is built on a simple idea. On each small page state a piece of software
development wisdom - examples: 'don't reinvent the wheel', ‘use effective
test completion measures’ - justify it and supply relevant references. The
wisdom is delivered as 201 principles partitioned broadly by development
phase. It makes for a readable and accessible aide memoire. CCS 2003
|
|
|
|
|
|
|
|
|
|
30. Rebel Code by Glyn Moody, 2001, Allen
Lane - The Penguin Press, ISBN 0-713-99520-3.
Glyn Moody give a detailed picture of the open source community by following the
development of Linux and other open source projects. The story is fascinating
but claustrophobic. The story is focussed squarely on people as individuals,
rather than teams and the key players are necessarily all coding heroes. It's
a pity there wasn't a little more about how the code is produced. Towards the
end there is an interesting discussion on the future of open source and its
effect on other economic models of software production - is open source
parasitic on the more conventional approaches? We'll have to wait and see. CCS
2001
|
|
|
|
|
|
|
|
|
|
29. Prince2: A practical handbook by Colin
Bentley, 1997, Butterworth Heinemann, ISBN 0-75-06-5330-2.
Prince2 is the UK's de facto Project Management Standard. It deserves to be better
known - or more widely used - than it is. This book by Colin Bentley
goes some way to spreading the word. It provides a clear overview of PRINCE2
describing and explaining the components of the standard to build a
convincing picture of an approach to project management that incorporates
many best practices and is both robust and flexible. The author, Colin
Bentley, has been central to the development of Prince2 and its precursors.
|
|
|
|
|
|
|
|
|
|
28. The Secrets of Consulting by Gerald M.
Weinberg, 1985, Dorset House, ISBN 0-932633-01-3.
Condensed wisdom delivered with wit and humour and summarized as a set of
'rules'. The insights are - as usual with Jerry Weinberg - penetrating, the
situations recognizable and the advice very sound. (I just wish I could
remember to act on what I now know!)
|
|
|
|
|
|
|
|
|
|
27. Debugging the Development Process by
Steve Maguire, 1994, Microsoft Press, ISBN 1-55615-650-2.
On the cover it says 'practical strategies for staying focused, hitting ship
dates, and building solid teams', and that's a pretty good summary. This is a
slim readable book with sound advice and real world examples showing a team
leader or project manager can keep project objectives in sight and actively
manage the project to achieve them. The book steers a middle course between
the tendencies to either reject all controls or overload teams with
bureaucracy and procedures. The bad coffee story was a useful illustration of
the value of simple 'systems'. CCS 2001
|
|
|
|
|
|
|
|
|
|
26. The Cathedral and The Bazaar by Eric
Raymond, 1999, O'Reilly, ISBN 1-56592-724-9.
A fascinating series of essays on the open source community's emerging challenge
to Microsoft's domination of the software market. Eric Raymond describes the
programmer culture, why programmers want to produce software, the value of
software itself and how commercial enterprises have chosen to exploit this.
Essential reading if you want to know how the future of software and software
development is being decided. CCS 2000
|
|
|
|
|
|
|
|
|
|
25. The Dilbert Principle by Scott Adams,
1997, Boxtree, ISBN 0-7522-2470-0.
If you thought process improvement and software measurement were easy this
book will remind you what you are dealing with, and show you what most
software developers and managers will think of your efforts. CCS 1999
|
|
|
|
|
|
|
|
|
|
24. Rapid Development by Steve McConnell,
1996, Microsoft Press, ISBN 1-55615-900-5.
This is an excellent resource for those that have to improve their projects'
performance. Extremely readable, very practical: Steve McConnell discusses
the motivators for improved development practice, the mistakes that are
commonly made in attempting to improve practice and attributes of good
software development practice. The book contains good advice and many
examples of best practice. CCS 1997
|
|
|
|
|
|
|
|
|
|
23. Code Complete by Steve McConnell,
1993, Microsoft Press, ISBN 1-55615-484-4.
A highly readable and comprehensive reference book for every programmer. This
impressive book is packed with clear thinking, good advice and numerous
examples for the construction of good software. Buy it, read it and keep it
by you. CCS 1997
|
|
|
|
|
|
|
|
|
|
22. Decline and Fall of the American
Programmer by Edward Yourdon, 1993, Yourdon Press, ISBN 0-13-191958-X.
Ed Yourdon gives an overview of the problems facing software engineering and
the practices that may help software development organizations maintain a
competitive advantage. CCS 1998
|
|
|
|
|
|
|
|
|
|
21. Handbook of Walkthroughs, Inspections
and Technical Reviews by Daniel P Freeman and Gerald M Weinberg, Third
Edition, published by Dorset House, ISBN: 0-9326633-19-6.
This is an important book because it describes the most important software
activity - reviewing. Human based quality control has almost an almost
magical effect on software development and software management. This book
describes the various types of reviews and their pros and cons in great
detail. Unfortunately this (third) edition of the book has an unhelpful
format. It is structured entirely as a series of questions and answers. This
can be very frustrating; the authors have assumed they know the questions the
reader would ask - but they don't. For this reason the book compares badly
with Tom Gilb and Dot Graham's book on Software Inspections. Never the less
this is an important book on an important software practice.
|
|
|
|
|
|
|
|
|
|
20. Practical Software Metrics for Project
Management and Process Improvement by Robert B. Grady, 1992, Prentice Hall, ISBN
0-13-720384-5.
This book is a useful resource for those developing or using software
measures. With a practical bias and based on work done in Hewlett Packard
measures for project management and for process improvement are described and
justified. There are lots of graphics showing how the measures can be
presented to best effect.
|
|
|
|
|
|
|
|
|
|
19. Metrics and Models in Software Quality
Engineering by Stephen H. Kan, 1995, Addison-Wesley, ISBN 0-201-63339-6.
A clear description of the application of measurement in a mature software
development organization - IBM. Many useful ideas are clearly presented here,
but their applicability to less sophisticated software development
environments should be considered carefully. CCS 1998
|
|
|
|
|
|
|
|
|
|
18. NonParametric Statistics for the
Behaviour Sciences by S.Siegal and NJ. Castellan Jr., Second Edition, 1988,
McGraw Hill,
A useful book for its clear description of the measurement scale types alone.
It also describes the appropriate statistical tests and analyses that can be
applied to data of these types. A valuable reference for anyone involved in
defining or validating measures for use in software development. CCS 1995
|
|
|
|
|
|
|
|
|
|
17. The Capability Maturity Model:
Guidelines for Improving the Software Process by The Software Engineering
Institute, 1995, Addison Wesley Publishing Company, ISBN 0-201-54664-7.
This is the definitive text on the SEI's Software Capability Maturity Model.
The first part of the book introduces the ideas of process maturity and
process improvement in software engineering organizations. The second part
describes the CMM itself. CCS 1995
|
|
|
|
|
|
|
|
|
|
16. Kaizen: The Key to Japan’s Competitive
Success by Masaaki Imai, McGraw-Hill Publishing Company, ISBN 0-07-554332-X
Not
a software process improvement book but who can be involved in SPI without at
least a good awareness of Total Quality Management thinking? This book
discusses continuous improvement as the key to success in the Japanese
manufacturing industry. IES 1994
|
|
|
|
|
|
|
|
|
|
15. Managing the Software Process by Watts
Humphrey, Addison Wesley Publishing Company, ISBN 0-201-18095-2.
This book gives the reader an insight in to the thinking and assumptions
behind software process improvement. Watts Humphrey focuses on understanding
and managing the software process to effect improvement. An easy read which
offers pragmatic advice on dozens of subjects associated with the development
of software systems. IES 1994
|
|
|
|
|
|
|
|
|
|
14. Principles of Software Engineering
Management by Tom Gilb, 1988, Addison-Wesley Publishing Company, ISBN
0-201-19246-2
A classic - one of those rare books that doesn’t seem to be ageing. It
discusses many essential software engineering ideas – evolutionary
development, design-by-objectives, attribute specification, inspection. It is
a very stimulating read and will equip you with ideas for putting in place
practical solutions for many of your development problems. Altogether a
remarkable book and essential for any practicing software manager or
engineer.
|
|
|
|
|
|
|
|
|
|
13. The Mythical Man Month, Essays on Software
Engineering, Anniversary Edition by Frederick P. Brooks Jr., 1995,
Addison-Wesley Publishing Company, ISBN 0-201-83595-9.
This well known book describes the problems of building large software
systems over twenty years ago. Although the industry has seen many 'Silver
Bullets' promise the solution to the software crisis in the last two decades,
Brooks' book is as relevant today as it was in the seventies.
|
|
|
|
|
|
|
|
|
|
12. Software Metrics: A Rigorous Approach by
Norman Fenton, Chapman & Hall, 1991, ISBN 0-412-40440-0
This book contains and discusses aspects of software measurement ranging from
the theoretical foundations of measurement to the practical issues of
implementation, with contributions from respected authorities in the field.
Its primary value is in justifying the need for rigour in measurement to
avoid measurement activity becoming an expensive exercise in meaningless data
collection. The extensive bibliography is particularly useful. This book has
now been issued in a second edition, 1996, by Norman Fenton and Shari
Lawrence Pfleeger. CCS 1996
|
|
|
|
|
|
|
|
|
|
11. Software Metrics: A practitioner's
guide to improved product development by K.H.Möller and D.J.Paulish, Chapman
& Hall, 1993, ISBN 0-412-45900-0
This book describes the findings of the Esprit 'Pyramid' Project, together
with case studies that were summarised in that project's 'Blue Book'. It is,
as the title suggests, intended for practitioners, rather than newcomers to
the field. The focus is on implementing measurement for organisational
process improvement. Useful if you are already involved with software
measurement. CCS 1994
|
|
|
|
|
|
|
|
|
|
10. Software Metrics: Establishing a Company
Wide Program by Robert Grady & Deborah Caswell,
Prentice Hall, 1987, ISBN 0-13-821844-7
Bob Grady and Deborah Caswell describe an initiative to promote the use of
software measurement in Hewlett Packard. The book is a 'how to' guide based
on their efforts. It includes the selling of software measurement to managers
and engineers, describes how the measurement effort was organised and
discusses in some detail the measurements they used. Good practical advice
but it should be borne in mind that the work was tailored to HP's distinctive
Total Quality environment. CCS 1994
|
|
|
|
|
|
|
|
|
|
9. Software Management Metrics by Herman
Schultz,
MITRE Corporation Ref.: ESD-TR-88-001
This brief report gives an excellent overview of a number of simple and
useful measurements, and their graphics to help in managing software
projects. It explains the measures, and types of data for each measure, what
they are for and how they are used. CCS 1990
|
|
|
|
|
|
|
|
|
|
8. Measuring Software Design Quality
David Card with Robert Glass, Prentice Hall, 1990, ISBN 0-13-568593-1
This is a short book that can be read in one or two evenings. It gives an overview
of the practical use of software measurement, including software project
control, but the emphasis is firmly on interpreting design metrics - and here
it comes up with some interesting conclusions. A 'starter set' of metric
primitives is proposed that Card estimates should cost less than 1% of
development effort to collect and use.
|
|
|
|
|
|
|
|
|
|
7. Controlling Software Projects,
Management Measurement & Estimation by Tom DeMarco, Prentice Hall (under Yourdon
Press imprint) 1982, ISBN 0-13-171711-1
Tom DeMarco, if not the originator, can take the credit for making famous the
phrase 'You can't control what you can't measure'. That phrase opens this
book and indicates where the emphasis lies. This book concentrates on
managing software development projects by using quantitative information.
Many useful ideas are introduced in this book. CCS 1989
|
|
|
|
|
|
|
|
|
|
6. The ami Handbook
From ami promotions, contact Alison Rowe, ami Promotions Administrator
University of South Bank, Room 401-406, 103 Borough Road, London. SE1 0AA.
The ami (application of metrics in industry) describes a framework for
introducing software measurement into software development environments. It
builds on well tried practice based on the Software Engineering Institute's
Capability Maturity Model for understanding development and management
capabilities, and Basili's Goal, Question, Metric approach to determining
what should be measured. A useful book if you are planing to introduce
software measurement. - No longer available. CCS 1991
|
|
|
|
|
|
|
|
|
|
5. The Art of Software Testing by Glenford
J. Myers, Wiley, 1979, ISBN 0-471-04328-1
Still the best book on testing despite the technical aspects starting to
date. Describes basic approaches to testing and includes useful checklists.
If you thought software testing was straightforward the first few pages
should change your mind. CCS 1989
|
|
|
|
|
|
|
|
|
|
4. The Complete Guide to Software Testing
by Bill Hetzel, QED, 1984, ISBN 0-89435-242-3
This book concentrates on the management of testing and its place in the
software development lifecycle (it isn't just something to do between coding
and release). Interesting and readable but weak on techniques - it
concentrates on the 'why' and the 'when', not the 'how'.
|
|
|
|
|
|
|
|
|
|
3. Notes on the Synthesis of Form by Christopher
Alexander, 1964, Harvard University Press.
This slim book - by an architect - on the design process is remarkably
pertinent to the design and construction software systems. It identifies the
attributes of good design and the way in which such design is produced. A
visionary book. CCS 1989
|
|
|
|
|
|
|
|
|
|
2. Peopleware by Tom DeMarco and Tim
Lister, Dorset House, 1987, ISBN 0-932633-05-6
If you've every puzzled over why some places are good to work and others not,
why some things take for ever and others almost to happen by themselves this
book will tell you why. It describes how to grow productive software
development teams, how to provide good work environments and how to get the
best out of people. It is an excellent, readable, and subversive book. CCS
1991
|
|
|
|
|
|
|
|
|
|
1. Agents of Change by Barbara M. Bouldin,
Prentice Hall (under the Yourdon Press imprint), 1989, ISBN 0-13-018508-6
Introducing a new tool or method is far more complicated than you would
expect. Dealing with the expectations and politics as well as the technical
and practical aspects can make the task a nightmare. The author describes how
she learned how to manage the introduction of tools and describes 'best
practice' for getting people to actually use them. Not a particularly easy
read, but essential if you are introducing new (or different) technology. CCS
1990
|
|
|
|
|
|
|