MARCH/APRIL 2006 (Vol. 23, No. 2) pp. 109-111
0740-7459/06/$31.00 © 2006 IEEE
Published by the IEEE Computer Society
Published by the IEEE Computer Society
|Good Medicine for Software Estimation Problems|
|UML 2.0 Style with an Agile Attitude|
|Software Engineering Aspects of Service-Oriented Architecture|
PDFs Require Adobe Acrobat
Good Medicine for Software Estimation Problems
Estimating Software-Intensive Systems by Richard D. Stutzke, Addison-Wesley, 2005, ISBN 0-201-70312-2, 944 pp., US$59.99.
In one of my favorite Dilbert cartoons, the pointy-haired boss charges an underling with going to the doctor to take the boss's physical. As the underling walks off, the boss says, "And don't listen to that diet and exercise stuff. I want pills." We groan because we know all too well that no pills—or, in software engineering vernacular, silver bullets—will spare software developers from the consistent, regular application of thoughtful discipline.
I don't imagine that many people are attracted to software development careers so that they can estimate project costs and calculate bid prices. Like diet and exercise, though, they're prerequisites of something we do want—whether it's being able to solve problems with software or simply getting paid for our time and effort. If you're responsible for predicting the resources a software solution will require, Richard Stutzke's Estimating Software-Intensive Systems should be in your arsenal. It's a virtuoso combination of principles, conventional wisdom, and down-to-earth methods that addresses nearly every aspect of estimation.
Be advised: this isn't a fluffy "seven habits of effective estimators" treatment but a hefty, 900-page component of the Software Engineering Institute's Series in Software Engineering. Stutzke's treatment of the subject, though, is deft and interesting. When I settled in (perhaps steeling myself a bit) to look at topics such as algorithmic analogy estimation, I was often surprised and delighted by how tractably Stutzke presents the material; I could see immediately how I might apply it. His typical approach is to provide background on the general concept and identify relevant models from the literature. He then makes the principles operational by applying them concretely, sprinkling in good anecdotes and examples from practice, and showing specific ways of handling the data, calculations, and presentations in Excel. Whatever your learning style, Stutzke provides an avenue to the material.
Stutzke derives several models and approaches from Barry Boehm's Cocomo. Beyond this, the text finds simple (but not simple-minded) applications for standard estimation techniques such as regression, mean time-to-failure, Delphi, statistical process control, and applications of optimization. Given Stutzke's close connection with the literature and his comprehensive inclusion of techniques focused on software estimation specifics, Estimating Software-Intensive Systems would make a wonderful textbook for an applied graduate course. If I were teaching it, though, I'd want a two-semester sequence; the content is so relevant and placed in such a good context that I could not bear to omit any of it.
This isn't, however, an academic treatment of the topic. Though Stutzke is firmly grounded in academic models, he demonstrates over and over how to apply the academic principles. Add his tips, specific implementation examples, insider advice on costing tricks, and instruction on making bids for specific clients, and you have a text that avoids the priggish academic-speak some books exhibit. Complete glossaries and appendices remove much of the mysticism that sometimes accompanies shorter treatments of costing. This is definitely a practitioner's book.
No silver bullet is included, but Estimating Software-Intensive Systems provides enough strong bows and sharp arrows to wound even the toughest costing beast. Even if you have a strong costing system in place, I recommend at least taking a look for its breadth of ideas and ways to productively apply them.
Todd Schultz is a professor of management information systems at Augusta State University. Contact him at email@example.com.
UML 2.0 Style with an Agile Attitude
The Elements of UML 2.0 Style by Scott W. Ambler, Cambridge University Press, 2005, ISBN 0-521-61678-6, 200 pp., US$14.99.
Anyone familiar with Scott Ambler's work will agree that he's well qualified to address UML. His book of UML guidelines, The Elements of UML 2.0 Style, will be simple to follow for readers with UML experience. Many of its concepts and style ideas for UML diagrams are best practices conveyed by an author who understands modeling software. The book isn't for those who want to learn UML or who haven't done any modeling; it's aimed at experienced developers and architects who want to hear a consultant's thoughts on the accepted styles for diagram design.
Many of us include too much information in designs, resulting in cluttered diagrams. This book provides appropriate measures to wean us of this temptation. Guidelines cover all the UML 1.0 diagrams as well as the new diagrams added to the UML 2.0 specification. This book would be a suitable design supplement for a development team working to communicate styles and guidelines for diagrams as a basis for setting standards for diagrams. The book could also work as a supplement for a software design class. UML's purpose is to provide a standard for design, leaving it to the individual to express the content in an understandable way (that is, the style). The principles this book establishes leave the modeler with more effective and understandable diagrams and greater productivity.
Elements of UML 2.0 Style includes all the classic UML diagrams, along with guidelines for making them more effective, understandable, and concise. For example, diagrams need adequate white space (Guideline 10), and you should only show what you must (Guideline 14). Ambler assumes a Western audience that understands UML and modeling basics and is looking for style rather than design guidelines. He makes several references to finding good UML design books and the fundamentals of UML for readers who lack the prerequisite understanding.
Ambler even understands UML's limitations. As you'll find through the guidelines, he's a proponent of agile methods and devotes a chapter to agile modeling. I appreciate his candor and willingness to help make modeling tools better and to educate practitioners.
Scott Brookhart is a software developer at the Texas Education Agency. Contact him at firstname.lastname@example.org.
Software Engineering Aspects of Service-Oriented Architecture
Service-Oriented Architecture: Concepts, Technology, and Design by Thomas Erl, Addison-Wesley, 2005, ISBN 0-201-70312-2, 944 pp., US$59.99.
After the wide success of Thomas Erl's first book, Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services, he's done it again. His second book focuses on the engineering aspects of Web services and service-oriented architecture as a whole. One challenge is the misconception of what SOA really means and entails. Erl answers this question, addressing the reality of SOA.
Erl takes two main approaches throughout Service-Oriented Architecture: Concepts, Technology, and Design: the ideal scenario and the real scenario. The ideal scenario is what we read about every day and what we'd like SOAs to be. Ideal scenarios are what standards committees shoot for when they start creating a new standard. Ideally, SOA is meant to replace the traditional distributed architecture—and to do so globally.
In reality, we're still stuck with years' worth of legacy applications to deal with. More importantly, we're not used to thinking abstractly about business processes and logic, which serviceorientation requires. A change must occur from the infrastructure all the way up to the business process level, bringing commitment from all levels, too.
Bridging the gap between business and IT has always been a challenge. Web services have widened this gap because both the technology side and the business side have numerous misperceptions about SOA. This situation requires a text that covers the SOA process and Web services in general from top to bottom, not strictly from the programmer's viewpoint but also from that of designers and architects. Software designers and architects must be able to decide what an organization's overall SOA initiative will look like, and Erl aims to simplify this task. After you decide on the overall strategy, Service-Oriented Architecture: Concepts, Technology, and Design can help bring your vision to life.
The book answers basic SOA questions, such as what characteristics Web services bring to the table. It covers Web services theory and outlines a step-by-step service orientation design process (process being the key word here) that you can easily incorporate into your software engineering process. Just like when object orientation was new and we needed to incorporate OO concepts with practice, now we need a way to incorporate SOA concepts with current practices. Erl shows how to
• perform a service-orientation analysis,
• model service candidates that are derived from business models,
• design a service-oriented business process, and
• use Web services to abstract your business processes and logic.
Erl cross-references these high-level goals with the current state of Web services. He describes more than 10 Web services specifications in detail, including appropriate code samples, and draws models from these specifications to business needs.
Agile or otherwise, software engineering processes must be modified to incorporate methodologies such as service-oriented analysis and design. One key point that Erl makes throughout is the distinction between object orientation and service orientation. The names and architecture might seem similar, but they're very different. Services in general promote decoupling throughout the engineering process (that is, design, development, testing, deployment, and usage). In OO, decoupling is done mainly at the design and development phases, and objects generally refers to finer-grained entities (relative to the term service in service orientation). In service orientation, communication patterns between services take precedence over the internal architecture. A service could be written in Cobol and run on a mainframe, and it's still considered a service if it can comply and interact with the rest of the enterprise's SOA architecture.
Erl has certainly shown his in-depth knowledge of Web services and SOA yet again in his new book. I recommend Service-Oriented Architecture: Concepts, Technology, and Design to anyone involved with designing and implementing an SOA initiative within an enterprise.
Art Sedighi is a senior consulting engineer at DataSynapse and a freelance writer. Contact him at email@example.com; www.artsedighi.com.