|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|