3 of 4 people found the following review helpful:
5.0 out of 5 stars
It's about time! Signed, a former software engineer on the Space Shuttle, April 12, 2006
This review is from: Trustworthy Systems Through Quantitative Software Engineering (Hardcover)
Well, this is certainly a much different type of software engineering textbook than I have seen in the last score of years ☺! I was a reviewer of early editions of Pressman, and a user of every edition since the second one at four different universities. Shooman's classic 20+ years ago is another early data point for a graduate course. The Software Engineering Lectures of Tom DeMarco and Ed Yourdon from 1979 are still shelved six feet away from me, and have been referenced in every undergrad and graduate software engineering related course I have taught since 1984. The same shelves contain Pfleeger, Leach, Lethbridge, Peters, Watts & Humphrey, Sommerville, Thayer and many others within the combined 12 foot lineal span. They obviously are used, but not to the extent of Pressman.
That may be about to be changed! Larry Bernstein's new text states on page 32 ".. none of these [principles of sound organizations] will work unless our profession recognizes the next core element in the evolution of software processes as a fundamental principle. Software trustworthiness is the next major area in which academic and industry must focus -- both for national security reasons as well as to ensure that the U.S. software industry maintains its leadership. The three attributes of software reliability, security and safety comprise trustworthiness."
I totally agree with the belief about where we should focus our attention in coming years, but not for the reasons that Larry cites. Let me explain:
* Having worked as a software/knowledge engineer on the Space Shuttle program for Rockwell International for four years, including the maiden flight of Discovery within a few months of my hire date in 1984, I am a very firm believer that the trustworthiness of the software in the shuttle and all the support effort was a gold standard at the time. I was also a full-time professor of CS concurrently, so could bring such issues to all of my classes. Although I have given up my dream of going to the moon, hatched when my small team of high school students fired off rockets in a farmer's field prior to Sputnik, I still hope to make it to the international space station, so a trustworthy system is not only of academic interest! In the last 20+ years, the ubiquity of computing, particularly embedded systems in all modes of transportation, makes such a standard a MUST, not just "nice to have" in our cars, trucks, planes, etc. When a team of Ford software engineers showed up in my office 10+ years ago, asking for help in developing safe software systems for next generation side impact sensors, I could not brush off their concerns! Obviously, software systems pervade the lives of many of the 6.6 billion people residing on this planet today, not just the billion or so who access the Internet. It is irresponsible, not to mention a direct violation of codes of ethics for computing and software engineering, NOT to develop such trustworthy systems.
* I cannot agree with Larry's rationale about the leadership of the U.S. in software. Trustworthiness of software systems knows no national boundaries! Other engineering artifacts do not know such artificial boundaries - do we want the bridges and high rise buildings of Europe, Asia, the Middle East, South America, Africa, etc. to be less safe, reliable and secure than those in the United States? I think not, if for not other reason than millions of our citizens travel to and live in those countries every day. Clearly, the lives of people across the world are just as valuable as those fortunate enough to live in our 50 states. The state-of-the-art in engineering methods is being advanced on a world-wide basis - why should we think software engineering education is somehow an exception? I would hope that this new text would be published in many languages and used by students and practitioners worldwide. I had first met Professor Bernstein on November 30, 2000 during my sabbatical to set up an International Software Engineering University Consortium (www.iseuc.org). So Larry clearly knows of my penchant for the world-wide importance of software engineering ☺!
Why do I think this new text is different from earlier ones and would recommend strongly that all current faculty and practitioners consider it carefully, especially for an introduction? The rationale includes the following. The text:
1. Focuses on the increasingly vital role that trustworthy software systems will play in the lives of current and future generations. Consequently, it is quite easy to engage or "hook" students in an introductory software engineering course about the importance of the topic - they see the impact of the lack of such systems on a weekly, if not daily, basis. Many of them will be able to share personal and professional experiences. The marvelous column by Neumann in every copy of ACM's SIGSOFT Software Engineering News provides ample examples, in any case.
2. Is cleverly written with excellent and realistic case studies with real questions and answers
3. Draws on the demonstrated expertise of the primary author when he was the CTO for Bell Labs
4. Truly demonstrates the rationale for the role of quantitative software engineering methods throughout the development life-cycle, beginning on page 4!
Reliabilty = e-k?t, where k is a normalizing constant, ? is complexity/(effectiveness x
staffing) and t is the time the software executes from its launch.
5. Emphasizes the "why" as well as the "how"
6. Includes excerpts from student teams related to the growing use of Real Projects for Real Client Courses - RPRCC-in software engineering and other courses
7. Covers most of the topics in a traditionally-structured software engineering text, but does so in a more contemporary and intuitive way. Some of the topics in other texts that wind up at the end, hence often not covered, are main-line chapters in the Bernstein text*. The newest edition of Sommerville's text does indeed have a 20-page chapter 3 on "Critical Systems" and a complete 120 page Part 4 on the same topic, but this is certainly an anomaly among current texts. The Bernstein text emphasizes trustworthiness as a continuing theme throughout, with the continual use of quantitative measures - witness the large number of "Magic Number" boxes for empirical results and heuristics contained in virtually each chapter. I admit that there would be a "learning curve" for most of us, but hey, aren't we supposed to be paragons for "life-long learning" that we espouse for our students?
8. Has fewer pages than virtually every other text. This is a real advantage. Students (and faculty) feel they have a "prayer" of being able to use the material in one course!
9. Has nice on-line support site.
10. And, finally, Larry will go to great personal lengths to support his text ☺!
A couple of possible sources of improvement for the second edition would include the following:
1. Include Failure Mode Effect Analysis (FMEA) as a major component when designing critical systems. This is a common engineering tool that was used in the design and testing of the Space Shuttle Main Engines (SSME) over the last 30 years.
2. How can the vital concept covered in the text be applied to the massive task of rendering trustworthy the extant base of millions of software systems? The text does a superb job for developing such systems, but can trustworthiness be "bolted on" existing systems? I doubt it, but cannot see an easy answer here.
3. A friendlier website for both instructors and students would be helpful, ala those for other software engineering textbooks
*Topics in the text
Part I. Getting Started
1. Think Like an Engineer - Especially for Software
2. People, Product, Process, Project - The Big Four
Part II. Ethics and Professionalism
3. Software Requirements
4. Prototyping
5. Architecture
6. Estimation, Planning, and Investment
7. Design for Trustworthiness
Part III. Taking the Measure of the System
8. Identifying and Managing Risk
9. Human Factors in Software Engineering
10. Implementation Details
11. Testing and Configuration Management
12. The Final Project: By Students, For Students
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
