Forums

Advice on books about software quality.

Started by Elder Costa October 30, 2004
Hi.

I would appreciate having some advice on good books about software 
quality, preferably with a practical approach: how to implement a good 
development process, tools and techniques to support such a process.

I'd also appreciate your advice on books that focus on the tools for 
software testing, metrics etc.

After browsing through Amazon I got overwhelmed with so many titles and 
I am not sure how trustworthy the reviews are.

TIA for your hints and opinions.

Elder.

My cup of tea

Commandment   1: You don't actually need books, just common sense
Commandment   2: Develop standards and guidelines
Commandment   3: Don't be afraid to change your standards and guidelines
Commandment   4: Adhere to those standards and guidelines once they've been
proven themselves
Commandment   5: Don't get involved in senseless discussions about style
Commandment   6: Don't do it all on your own
Commandment   7: Document what you're about to build, the same goes for how
you'll build it.
Commandment   8: Organize structured reviews of documentation and code and
honor its outcome
Commandment   9: Make a project plan and stick to it
Commandment 10: Enjoy what you're doing

There's of course a lote more to it, but these are some of
the issues that popped into my mind. Google with "software
quality control and assurance". You'll find a truckloads of
documents on the subject.
Most of what you need in terms of quality control and assurance
depends on the size of your project. Rule of thumb: Keep It Simple!!!

Greetz

Waldemar



"Elder Costa" <elder.costa@terra.com.br> schreef in bericht
news:2uhm5hF2atel5U1@uni-berlin.de...
> Hi. > > I would appreciate having some advice on good books about software > quality, preferably with a practical approach: how to implement a good > development process, tools and techniques to support such a process. > > I'd also appreciate your advice on books that focus on the tools for > software testing, metrics etc. > > After browsing through Amazon I got overwhelmed with so many titles and > I am not sure how trustworthy the reviews are. > > TIA for your hints and opinions. > > Elder. >
Elder Costa wrote:

> Hi. > > I would appreciate having some advice on good books about software > quality, preferably with a practical approach: how to implement a good > development process, tools and techniques to support such a process. > > I'd also appreciate your advice on books that focus on the tools for > software testing, metrics etc. > > After browsing through Amazon I got overwhelmed with so many titles and > I am not sure how trustworthy the reviews are. > > TIA for your hints and opinions.
WaldermalIII's 10 commandments were a reasonable list but maybe slightly too many to remember in one hit. My paper, "Safety by Design" on my website has seven rules that can help out. If you are looking for a good book on the subject, especially with a slant to embedded systems, then Jack Ganssle's book "The Art of Designing Embedded Systems". There are also several books that deal with topics like Design & Technical Reviews, and Change Management Systems. I reccommend you consider looking at those too. I can provide a list if you need one. -- ******************************************************************** Paul E. Bennett ....................<email://peb@a...> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
"Elder Costa" <elder.costa@terra.com.br> skrev i meddelandet
news:2uhm5hF2atel5U1@uni-berlin.de...
> Hi. > > I would appreciate having some advice on good books about software > quality, preferably with a practical approach: how to implement a good > development process, tools and techniques to support such a process. >
Microsoft have some good books based on experience learned when doing Office products. -- Best Regard Ulf Samuelsson
If you've never read it before, I'd start with "Code Complete" by
Steve McConnell. It has a lot on the nuts and bolts of software
design, but with an eye to improving quality and documenttion. The
section on "Quality Improvement" would be very useful for you to read.
It has good coverage of doing code reviews, unit tests, and debugging.
This is the kind of book I wish I had read 25 years ago when I was a
beginning coder (of course no one had written something like it way
back in the stone age).

I was a little leary of the book because it is published by Microsoft,
a name I seldom equate with quality. But McConnell writes good stuff.
He's got a handful of other books out. IMHO all are worth checking
out.

Mark Hahn

PS and if Richard Ames who sat next to me at Oresis is still reading
this newsgroup, drop me a line!

Elder Costa <elder.costa@terra.com.br> wrote in message news:<2uhm5hF2atel5U1@uni-berlin.de>...
> Hi. > > I would appreciate having some advice on good books about software > quality, preferably with a practical approach: how to implement a good > development process, tools and techniques to support such a process. > > I'd also appreciate your advice on books that focus on the tools for > software testing, metrics etc. > > After browsing through Amazon I got overwhelmed with so many titles and > I am not sure how trustworthy the reviews are. > > TIA for your hints and opinions. > > Elder.
Elder Costa <elder.costa@terra.com.br> wrote in message
news:2uhm5hF2atel5U1@uni-berlin.de...
> I would appreciate having some advice on good books about software > quality, preferably with a practical approach: how to implement a good > development process, tools and techniques to support such a process. > > I'd also appreciate your advice on books that focus on the tools for > software testing, metrics etc. > > After browsing through Amazon I got overwhelmed with so many titles and > I am not sure how trustworthy the reviews are.
You can easily become overwhelmed with all that is *written* about this "process". But, why is it, despite the thousands of pages written, that software quality still *sucks*? It would be hard to imagine that no one is READING this material -- since each title sells many thousands of copies! And, hard to dismiss those copies as being read by the wrong *audience* (I doubt many grocers, lawyers, pharmacists, athletes, etc. are snapping up thesee titles!). Perhaps they are written by folks who aren't active *practitioners*? (i.e. it's real easy to "solve world hunger", "provide universal peace", etc. -- ON PAPER...) In my experience, the biggest thing you can do to improve your software quality is to HAVE A PROCESS. *Not* an ad hoc approach that varies with each project and from week to week. Rather, have *some* process that you stick to. (presumably, this process is RATIONAL!) This affords you a framework in which to operate. It lets you keep track of *where* you are in your process. Did you skip a step? Did you *forget* a step? etc. My process is quite simple. I have coding guidelines for each language that I use. These are GUIDELINES, not *rules*. They remind me of the types of things that "people" (i.e. the folks who are going to look at this stuff AFTER it has been written) are likely to stumble over (precedence rules, punctuation, etc.) when they are preoccupied trying to understand the code (i.e. if you are busy trying to figure out what the code is doing, you probably won't be observant enough to catch some subtlety -- like a /* FALL THROUGH */ in a switch statement or a /* DO NOTHING */ in a for loop). These guidelines don't waste time with things that a pretty-printer can do for me. I let mechanised tools fix the *appearance* of my code. I write test cases *while* I am writing the code. I.e. when I am writing a memory allocator I am more likely to be thinking of the "boundary conditions" that the code has to tolerate than I would be some weeks AFTER the code has been written! Every time I think of something that the code has to handle, I make sure I have a test case that will test for that. Of course, I also add other test cases in the hopes of catching something that I may have overlooked while coding the algorithm. "Hmmm... what happens if I try to strcat(foo, foo)?" I use version control systems to track *everything*. I "commit" almost every hour in some cases. Having a fine grained log of all of the incremental changes to a code sample makes it easier for me to track *where* something went wrong -- rather than having to "back out" a week's worth of changes to get back to a stable release. Note that the test cases have to be tracked in the same way! And, used for *regression* testing (if a test case doesn't apply, it means you have changed the *interface* or the *specification* -- these are BIG DEALS and not to be treated casually! That, of course, bringing me to the most important aspect of writing *good* code -- SPECIFICATION. *Design* the code up front. Resist the temptation to start writing code. Write specs, instead. Write a user manual. Make sure you have thought of EVERYTHING that the code has to deal with -- discovering something while you are in the middle of coding it is one way to guarantee you will have bugs! (because you haven't accommodated this discovery in all the other code you have already written nor do you know if your *approach*/design will accurately accommodate it!). The actual "code writing", realistically, is a *tiny* part of the job. And, there is very little skill involved in that activity (*think* about that... someone fresh out of school can write code if you tell him/her what the code has to do!). All of the "value" is in the design/specification of the algorithms -- and the design of the test cases to *verify* the code's compliance to those goals. "Bug fixes are free" is part of my business model. This gives clients a sense of security. And, gives *me* a strong incentive to make sure there are NO bugs in released code! Folks who glibly remark, "Well, you EXPECT it to have SOME bugs..." are just lazy. Do they EXPECT their automobile to catch fire when they are driving down the highway? Do they EXPECT the bridge they are driving on to suddenly crumble and drop them into the river below? Do they expect their CD player to only play every other song on the disc? *Think* about what you are setting out to design. Then, *do* it. cat flames > /dev/null HTH, --don
Elder Costa <elder.costa@terra.com.br> writes:

> Hi. > > I would appreciate having some advice on good books about software > quality, preferably with a practical approach: how to implement a good > development process, tools and techniques to support such a process. > > I'd also appreciate your advice on books that focus on the tools for > software testing, metrics etc. > > After browsing through Amazon I got overwhelmed with so many titles > and I am not sure how trustworthy the reviews are. > > TIA for your hints and opinions.
Antipatterns. Excellent book. http://www.amazon.com/exec/obidos/tg/detail/-/0471197130 S.
"WaldemarIII" <bleek004@hotmail.com> wrote in message news:<4183f218$0$46387$cd19a363@news.wanadoo.nl>...
> My cup of tea > > Commandment 1: You don't actually need books, just common sense > Commandment 2: Develop standards and guidelines > Commandment 3: Don't be afraid to change your standards and guidelines > Commandment 4: Adhere to those standards and guidelines once they've been > proven themselves > Commandment 5: Don't get involved in senseless discussions about style > Commandment 6: Don't do it all on your own > Commandment 7: Document what you're about to build, the same goes for how > you'll build it. > Commandment 8: Organize structured reviews of documentation and code and > honor its outcome > Commandment 9: Make a project plan and stick to it > Commandment 10: Enjoy what you're doing >
Hmm, my experience is that 1) people follow commandment 3 until the last day of the project, so the standards and guidelines just become a documentation of how things were done. 2) Commandment 4 never happens because tools changes, customer demands change (i.e, the customer got burned on the last project with a certain standard, so they make sure you changed it), so your back to commandment 3 3) commandment 8 is usually implemented, but the reviewers tend to be people who know very little about the project so the review is more of a superficial review. (the knowledgeable reviewers are too busy to review or are have been promoted to such a high-level they can refuse doing the review or the schedule is so tight they simply don't have enough hours in the day to perform the review) Commandment 7 and 10 are key, I believe, get smart people who enjoy their work and document it and the quality would naturally follow. By all means develope a set of standards and guidelines but don't assume they will be static throughout the project, unless perhaps if project is an upgrade or change to an existing project.
Elder,

I'd advise Jack Ganssle's "The Art of Designing Embedded Systems" for
starters. Ganssle
 is an extremely readable author and the book has lots of good advice.

Dave Bardon, Avocet

"Elder Costa" <elder.costa@terra.com.br> wrote in message
news:2uhm5hF2atel5U1@uni-berlin.de...
> Hi. > > I would appreciate having some advice on good books about software > quality, preferably with a practical approach: how to implement a good > development process, tools and techniques to support such a process. > > I'd also appreciate your advice on books that focus on the tools for > software testing, metrics etc. > > After browsing through Amazon I got overwhelmed with so many titles and > I am not sure how trustworthy the reviews are. > > TIA for your hints and opinions. > > Elder. >
Elder,

"mark hahn" <mhahn@hvc.rr.com> wrote in message
news:99bde2e0.0410301336.25e684ca@posting.google.com...
> If you've never read it before, I'd start with "Code Complete" by > Steve McConnell. It has a lot on the nuts and bolts of software > design, but with an eye to improving quality and documenttion. The > section on "Quality Improvement" would be very useful for you to read. > It has good coverage of doing code reviews, unit tests, and debugging. > This is the kind of book I wish I had read 25 years ago when I was a > beginning coder (of course no one had written something like it way > back in the stone age).
I also can vouch for "Code Complete". Years ago when I first read it, it showed me how bad a programmer I was. This was a useful lesson to learn. Dave Bardon, Avocet
> > I was a little leary of the book because it is published by Microsoft, > a name I seldom equate with quality. But McConnell writes good stuff. > He's got a handful of other books out. IMHO all are worth checking > out. > > Mark Hahn > > PS and if Richard Ames who sat next to me at Oresis is still reading > this newsgroup, drop me a line! > > Elder Costa <elder.costa@terra.com.br> wrote in message
news:<2uhm5hF2atel5U1@uni-berlin.de>...
> > Hi. > > > > I would appreciate having some advice on good books about software > > quality, preferably with a practical approach: how to implement a good > > development process, tools and techniques to support such a process. > > > > I'd also appreciate your advice on books that focus on the tools for > > software testing, metrics etc. > > > > After browsing through Amazon I got overwhelmed with so many titles and > > I am not sure how trustworthy the reviews are. > > > > TIA for your hints and opinions. > > > > Elder.