|
Software Engineering: (Update) (8th Edition) (International Computer Science Series)
Back Cover Copy SOMMERVILLE Software Engineering 8 The eighth edition of the best-selling introduction to software engineering is now updated with three new chapters on state-of-the-art topics. New chapters in the 8th edition Ø Security engineering, showing youhow you can design software to resist attacks and recover from damage; Ø Service-oriented software engineering, explaininghow reusable web services can be used to develop new applications; Ø Aspect-oriented software development, introducing new techniques based on the separation of concerns. Key features Ø Includes the latest developments in software engineering theory and practice, integrated with relevant aspects of systems engineering. Ø Extensive coverage ofagile methods andreuse. Ø Integrated coverage of system safety, security and reliability illustrating best practice in developing critical systems. Ø Two running case studies (an information system and a control system) illuminate different stages of thesoftware lifecycle. Online resources Visit www.pearsoned.co.uk/sommerville to access a full range of resources for students and instructors. In addition, a rich collection of resources including links to other web sites, teaching material on related courses and additional chapters is available at http://www.software-engin.com. IAN SOMMERVILLE is Professor of software Engineering at the University of St. Andrews in Scotland. Reader Reviews It has been 2 years since Sommerville put out the 7th edition of this book. So what has changed? Three new chapters have been added at the end of the 8th edition. One is entitled "Service-oriented software engineering". All about Web Services, which is a burgeoning field. The 7th edition just had a relatively brief explanation about XML and the sundry services developing atop it. Now the 8th edition goes into those, like the Web Service Description Language, and the Business Process Execution Language. To be sure, the chapter is not an exhaustive explanation of the syntax and usages of these languages. For that, you need to consult books devoted to them (and these do indeed exist). Rather, the chapter furnishes a concise overview that gives you the essence of what they can do. I actually think the chapter should have been simply called "Web Services". The actual title, while accurate, is too indirect. Another new chapter looks at aspect oriented programming. Again, just an overview. But it does convey accurately what AOP offers. Centred around the key idea of cross cutting concerns. And that conventional object oriented code tends inevitably to have closely related code scattered thru many classes; making maintenance harder. It is by no means clear that AOP will ever become common. But it is one of the most intriguing ideas to arise recently, and Sommerville is correct in explaining it. In the existing chapters brought over from the 7th edition, I do still disagree with his remarks on Extreme Programming. While XP does have some laudatory features, I take issue with the constant refactoring and the pair programming, as well as having a customer onsite at the developers' place. The latter is simply not realistic in some projects. While pair programming, and not having programmers responsible for specific parts of the code, totally ignores different levels of expertise. Some programmers are simply better (or more experienced) than others. A real danger is having 2 neophyte programmers unwork complex code made by a senior programmer, that they simply did not understand. If you have done any programming, you will encounter subroutines that are highly intricate and intrinsically hard to understand. Typically, these subroutines are only a small part of the total code. But they might play a crucial part. They should be associated with specific programmers, who are responsible for them. Another reason against pair programming is when the programmers are not just "pure" programmers. They might have backgrounds in various engineering or scientific fields, where this background is needed for the project. So a programmer/engineer versed in mechanical design, and who has to code accordingly, has different responsibilities from another programmer who has to deal with modelling the electrical circuitry, for example. At the design level, it makes eminent sense to sometimes pair these, when the domains overlap. But at the programming level, each can't usually do the other's work. Comment | | (Report this)
|

