|
This is a list of books and reports that may prove useful
for software developers, managers and those involved in 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 professional 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
|
|
|
|
|
|
|