Solid Software

Rating:
Summary: Solid Software, mushy in the middle
Review: I teach software engineering at the University of Colorado. I have begun a 3 course graduate series and am using Solid Software as one of two texts in the first course, Software Engineering of Stand Alone Programs. (Subsequent courses cover multiprogramming and distributed systems.) I have found Solid Software to cover the right topics but not to the right level of detail for my purposes. It is hard to find a general book on software engineering that covers adequately enough development factors that contribute to robustness such as requirements and design reviews, static and dynamic testing, etc. I was pleased when I read through the table of contents and saw the 9 areas addressed by the book. However, it is written to, say, first level managers of programming teams, not to the programmers themselves. On many topics, there are excerpts from books or papers that give a high level "hit". The good news is that the reference list at the end of each chapter includes excellent references. I think it's fair to say that my students' (all with industry experience) reaction is that it's not quite detailed enough to really understand. They are not expecting a how-to guide but ... more than this level. But you *can* follow the reference trail to get to more substance. If you ARE a 1st level manager, wondering what more can be done, what is reasonable to ask for, then this may be a great book for you.

Rating:
Summary: Solid Software, mushy in the middle
Review: I teach software engineering at the University of Colorado. I have begun a 3 course graduate series and am using Solid Software as one of two texts in the first course, Software Engineering of Stand Alone Programs. (Subsequent courses cover multiprogramming and distributed systems.) I have found Solid Software to cover the right topics but not to the right level of detail for my purposes. It is hard to find a general book on software engineering that covers adequately enough development factors that contribute to robustness such as requirements and design reviews, static and dynamic testing, etc. I was pleased when I read through the table of contents and saw the 9 areas addressed by the book. However, it is written to, say, first level managers of programming teams, not to the programmers themselves. On many topics, there are excerpts from books or papers that give a high level "hit". The good news is that the reference list at the end of each chapter includes excellent references. I think it's fair to say that my students' (all with industry experience) reaction is that it's not quite detailed enough to really understand. They are not expecting a how-to guide but ... more than this level. But you *can* follow the reference trail to get to more substance. If you ARE a 1st level manager, wondering what more can be done, what is reasonable to ask for, then this may be a great book for you.