This is the extension to the first book, Process Patterns, and covers the testing, release and production milestone processes in the system development life cycle.

Highlights:

- All processes are cataloged by life cycle milestone and presented in pattern format for quick reference and consistency.

- The author provides an excellent tutorial on patterns in the front of the book.

- Will work with any life cycle model (waterfall, spiral, iterative, etc.).

The material is well thought out and complete. I was impressed at the depth and detail in each of the patterns, and am gratified that someone has taken the time to write a book that covers what happens after development. If you are working in the Rational Unified Process environment you may want to consider, instead, the author's newer book titled "The Unified Process Transition and Production Phases" (ISBN 0521652626), which contains the same material, but aligns it to the Unified Process (the book calls it the Enterprise Unified Process, but it's essentially the RUP).

This book provides set of well designed patterns from which to develop service delivery processes. This is the only book I have come across that manages a clean, seamless segue from application delivery to service delivery.

First, to appreciate this book's approach it is important to know what OOSP and patterns are - this will set your expectations about the book and what you can get from it.

OOSP stands for Object-Oriented Software Process. It is an approach to software development within the context of object-orientation. Put another way, it is an object oriented approach to application delivery. Both of my definitions fall short, but if you are familiar with the unified modeling language (UML) or the Rational Unified Process (both of which are nearly inescapable judging from the sheer volume of literature on both subjects) then you will get the idea.

Patterns are like templates for actions and activities. Using a pattern assures a high degree of consistency in presenting a collection of activities, and also allows you to distill the key elements of a particular process into a succinct format. What I especially like about the concept of patterns is that provide a "container" into which you can capture best practices for any process.

This book presents a set of patterns for the final stages of application delivery (i.e., software development)and segues directly into service delivery. The patterns grouped into phases that roughly follow the Rational Unified Process, and the phases are further grouped into stages.

From the application delivery point of view, the processes are: test and rework. The bridge to service delivery is provided in the release stage processes. From there the processes are firmly in the service delivery domain, starting with the assess stage, and moving into the maintain and support phase. One of the best parts of this book from a service delivery practitioner's point of view is the "Identify Defects and Enhancements". This if often overlooked in the body of literature for applications and service delivery (but is a key process in software quality assurance). The patterns associated with this stage are an ideal vehicle to communicate operational requirements from service delivery back to application delivery.

I also liked the project and cross-project tasks that are presented in this book. As the co-developer of the Tarrani-Zarate Information Technology Management Model one of the fuzzy areas was the link between maintenance and support and the project-related tasks. This section clarified some of the dependencies and linkages.

What did this book do for me? As a service delivery practitioner it gave me a clear understanding of the potential synergies that can be achieved if application and service delivery are treated as a coherent whole. It also heavily influenced my thoughts when developing the Tarrani-Zarate model, and refined my view of service delivery. It also showed the value and power of employing patterns for capturing best practices. As such, this book is probably of value to knowledge management practitioners.

What does this mean to you? It depends on your role. If your role is project manager, in development or QA/test, then the process patterns provided will underscore the fact that development is not complete until the product is in production. If you are in production control, production support or applications support (help desk, tier 2 or 3), then this book provides some excellent ideas on how to "connect" service delivery to application delivery. If you are a project sponsor or business process owner, the defects and enhancement stages are a good starting point for understanding your role on a configuration control board at the project or product management level.

The author sums up the key point of this book with a quote from his web page: "A good developer knows that there is more to development than programming. A great developer knows that there is more to development than development." To paraphrase, development isn't what it is about - it's about delivering functions to business users so they can do their job. This book provides ideas and tools to do this.

I was really impressed with this book. When you first read the description of it - it's about releasing software and then maintaining and supporting it - you wouldn't guess how valuable it really is to developers. Writing the greatest software in the world won't do you any good if you can't get it in the hands of your users, and the author tells you exactly how to do this. Gems of wisdom permeate the book, for example you need to plan to rework your software once you've tested it and that you should take the time to do an assessment, what I would consider a post-mortem, to learn from your mistakes (the author says experiences but call it like it is). The material in the book isn't rocket science, which the author is quick to point out, but it is something that is key to the success of your project.

I really liked his idea of assessing your staff once your software is baselined for his "testing in the large." I think its exactly as he says, that developers will stick it out until the current release is ready to go out the door and then leave for greener pastures. By assessing them and investing the time to do career management you increase the chance of keeping your staff.

I also liked his treatment of how to release the software, he's one of the few people that seem to recognize that you have to release software to your operations department, your support department, and to your end users. Once again, not rocket science but something that is often overlooked until the last minute.

A strength of the book is the Maintain & Support phase. I've done software support before and it's a bitch. It's about time somebody finally wrote about it and told people how hard it actually is. Including Maintenance & Support in your software process is really important in my mind.

Just like the author points out, the best developers take maintenance into consideration, the best project managers must also take into consideration how their software will be supported too. This philosophy is a big strength over the Unified Process in my mind because the full spectrum of the software lifecycle is taken into account, not just development. The author's "Identify Defects and Enhancement" stage process pattern is really just basic change control once your software is out the door but once again he did a really good job of saying how to do it.

Another strength of the book is that it is based on real-world experience -- this stuff sounds to me like it would actually work. The book also has a solid foundation in theory, bringing both proven and theoretical practices together in an effective manner.

I also liked chapter 10 because it summarizes key project management issues, such as training and education of your staff, risk management, metrics, quality assurance, and risk management from both Process Patterns and this book, More Process Patterns. These are all important issues that must be taken into account to succeed. In fact, for many people this book is a good buy just to get this chapter alone.

The one thing that I don't like is that you really do need to buy two books, this one and the one before it, Process Patterns, to get a full picture of the overall software process. However, both books are pretty big and they both contain excellent information so its not such a bad thing in the end.

In the Unified Process (or any systems life cycle) the milestones/phases up to transition are well documented, but these represent the tip of the iceberg with respect to determining project success and total cost of ownership. This unique book examines the transition and production support requirements, addressing some of the deficiencies in the Unified Process (production support is all but ignored), and can be applied to other development life cycle models, nearly all of which have the same blind spots.

Many of the ideas and the approach for this book were born in the author's earlier book, " More Process Patterns", which examined the very transition and support requirements in a more generic manner. In fact this book, like the earlier one, is a collection of best practice patterns that cover the transition and production milestones. After an introduction that explains the rationale and approach, the book covers the workflows and patterns in the sequence in which they will occur: testing, deployment and environment, operations and support, project management and infrastructure management.

What makes this book important is that it extends the Unified Process to include the key milestones that account for cost and quality, and goes into great detail about what is required and how to avoid failure. If you work in operations and support you will find the material in this book invaluable - you should also buy copies for key members of the project team that is delivering your system so they have an understanding of and appreciation for the task of supporting their creation. While this book will obviously benefit shops that employ the Unified Process, the information and workflows are equally useful in any development approach.

There are two people I look to for information about UML: Martin Fowler (noteably: UML Distilled), and Scott Ambler.

With this book all the pieces are there. "UML Distilled" tells us how to use UML, "Agile Modeling" tells us how to use it in an agile way, and now "The Elements of UML Style" tells us how to use it so that the results look good and are understandable.

Physically, it's a nice book. Small and thin, it packs well, and will fit easily into the most overstuffed briefcase or backpack.

The format is good as well. Organized around the different diagrams, with extras for general guidelines and a quick overview of Agile Modeling, it covers related issues together in an easy to digest format. The guidelines themselves are short, concise, and well illustrated with examples.

I found it an easy book to read, being able to pick it up for a few minutes at a time without having to spend a lot of time to regain my context.

No matter how much you model, or what tools you use to do it, this little book will help make your diagrams better.

This book has lots of excellent recommendations on style and presentation of UML diagrams. Ambler offers up 236 recommendations to questions such as: How often should I use stereotypes? Should we model keys into our DBMS? Should we require activation boxes on our sequence diagrams?

I have to recommend this little book to anyone beginning to use UML. More experienced object modelers will have developed their own modeling conventions, but they also will benefit from reading Ambler's articulate perspective. He is an accomplished modeler and an effective communicator.

Ambler covers style guidelines for all 9 UML 1.x diagrams. IMHO most of his suggestions are right-on, and his explanations are consise and accessible. I have been modeling OO systems for 10 years, and I don't agree with every recommendation Ambler makes, but I appreciate what he is offering in this book.

I especially like the fact that Ambler included an Appendix that lists all 236 guidelines in just a few pages. The book also has a high-quality bibliography of other modeling resources, and I was quite pleased that this short book also includes an Index for rapid access to terms.

Most development groups endorse the need for programming conventions and consistent naming standards. "The Elements of UML Style" is an extension of this philosophy to UML models, and every project will benefit from the ideas it presents.

In writing The Elements of UML Style, Scott Ambler has done the software modeling community a great service. As a consultant and trainer of numerous corporate clients, I see many teams whose individuals understand the semantics of UML, but have yet to gel as a team with common practices and style. On these teams, communication and productivity often suffer when arguments erupt over why something is modeled the way it is and how my way is better. Teams need to agree on a set of common practices and style. The Elements of UML Style is a great starting point.

The Elements of UML Style is small, concise, intuitively organized, and well explained. It proceeds section by section through the various UML diagrams, in the order they are used on a project. These sections provide many tried and true common sense guidelines and some valuable, but less obvious guidelines aimed at creating well-formed models.

Is it necessary? Yes. This is the best compendium of UML modeling guidelines I have seen published. Projects would be foolish to start from scratch.

Is it sufficient? No. It is a starting point. Projects will want to adjust and go beyond what Ambler writes here. For example, The Elements of UML Style provides general guidelines that urge adopting common naming conventions (section 2.3). A corporation or project will want to nail down specific guidelines for their use case, class, and component names. Also, Ambler focuses on the diagrams of UML, but there is more to modeling than the diagrams. UML itself avoids topics such as what constitutes a well-formed use case specification, and so does Ambler's book. One would have to turn to other books or training, such as IconMedialab's Advanced Use Case Lab course for detailed guidelines in these areas.

Will I be an object modeler just by reading this book? No. This is not an intro book to modeling. Read Craig Larman's "Applying UML and Patterns" (for example) to learn how to object model. Instead, The Elements of UML Style brings together many of the nuggets that will help to become a better, more consistent, and easily understood modeler. I will be recommending this book to my clients.

If you want to master EJB, then the Mastering Enterprise JavaBeans is the right book for you! It covers everything from basics of the EJB to the more advanced topics like transactions, performance and clustering. You will also learn how to choose the most suitable EJB server for your project.

Thanks to Ed Roman, et al for the most comprehensive book about EJB technology. I would strongly recommend this book to the community.

P.S. Don't forget to download the source code from TheServerSide.com and enjoy testing what you have learnt!

This is one of those rare books that is equally beneficial both to readers who are brand new to the topic and readers with substantial experience in the topic. EJB is a very large and challenging topic to explain to beginning EJB developers. The authors do an excellent job of explaining the concepts in a very clear and well thought out manner. The book is very focused on those topics that are most important to the beginning EJB developer and clarifies them wonderfully. I believe individuals who have already been programming EJBs for a little while will also enjoy this book as a way to add depth and clarity to their EJB knowledge. The author's inter-mingle a substantial number of "best-practices," and advanced issues that will be very interesting to the new and old EJB developer.

If you have the time and patience to read a 1200 page book, "Professional EJB" by Wrox Press covers a lot more material and depth. However, if you don't have the time, patience, or desire to read a 1200 page book, this "Mastering EJBs" book is much more manageable and focused at 600 pages. The O'Reilly press "Enterprise Java Beans" book by Monson-Haefel is also quite good. However, like most O'Reilly books, I think it is actually too focused and doesn't provide a clear enough picture of how the whole EJB world fits together. So if you want a moderate size book with excellent explanations, good level of depth, and excellent insights, this book is it.
Enjoy!

Mastering Enterprise Java Beans, Second Edition, is perhaps the best book I have ever read on the topic of Enterprise Java Beans (EJB). Ed Roman, et al, have done an excellent job! The book is concise, to the point, and leaves you with a clear understanding of EJB. He thoroughly covers the new EJB 2.0 standard and the book includes many additional perks such as Transactions and EJB Best Practices. I had many questions in mind when I started reading the book and the book answered them all. If you are serious about EJBs you must have this book!

I probably purchased somewhere upwards of twenty books on the topics of the UML and object-oriented development before buying The Object Primer, 2nd Edition. Yeah, it probably would have been nice to have read this one first, but on the other hand, it may have been just the right book at the right time in terms of my learning process. As a result of my previous efforts, I was getting overwhelmed and confused by the sheer volume of concepts, notations, diagrams, development processes, and tools associated with becoming proficient with UML modeling and object-oriented development. While I had learned lots of important terminology and techniques from the previous books, I found The Object Primer to be enormously practical and useful in terms of putting it all together and breaking through to a working level of proficiency.

Among the aspects of the book that I appreciated are it's easy-to-read style, effective use of diagrams and visual examples, and the "techniques" sections with clear directives about what to do, and what not to do, in specific areas. I was able to use the technique lists in somewhat of a cookbook style as I applied what I was learning to some of my own work.

So far, in my growing library of OO development books, this one provides the "biggest bang for the buck".

OO came first and then came UML to model it! This book is all about the principles of object-oriented requirements, analysis, and design first and secondly about the UML tools for modeling these steps in project development. That's as it should be since OO is the thing most to be admired, and UML is (just) a popular and very useful language for modeling OO development. Too many UML books are so intent on UML that the fundamentals of OO are ignored. The first edition of this book was published in 1995 just before UML was born. Its author, Scott Ambler, is a prolific and renowned writer and developer.

The book has many detailed UML diagrams and is clearly written in a pleasant, professional style. The book is not about implementation. Look elsewhere for sample code, including some of Ambler's fine other publications.

Don't be lislead by the word "Primer" in the title. It's for the serious reader and would make a good text, but for a junior or senior level CS course. If you are a professional and could have just two references in your library for your first OO project, this 523-page book together with a good programming reference (Java, C++, C#, or VB.NET) would be a good choice.

This new edition of the book was well worth the wait. Finally someone has put it all together and described how to develop software using object-oriented technologies. Ambler covers development from requirements all the way through testing. Although the book does an excellent job explaining the UML, IMHO focusing on the 20% of the UML that you would actually use in practice, he supplements the UML with other techniques such as business rules, CRC cards, essential user interface prototypes, UI flow diagrams, and physical data models which he calls persistence models for some strange reason. He also goes a bit into system integration issues with external interface models, a topic that I rarely see covered in all the other OO books out there.

A huge strength of the book is that it shows how to go from OO design to actual code, giving a brief but good overview of how to implement your design in Java and in a relational database. Ambler describes important implementation issues such as how to map your objects into relational databases, how to write clean code, how to write good internal documentation, and how to design your user interface cleanly. Frankly, I don't know of any books other than this one that actually deals with real-world issues like this, and I really wish he had written this book years ago.

The testing chapter was solid but brief, summarizing material in his process patterns books, the 10th chapter very briefly overviewed technologies such as the RUP, EJB, and XP, and the final chapter provided career advice for success in the object industry. I would suggest this book for anyone new to object development, particularly people getting into Java or C++ for the first time, or even modelers or project managers than simply need to get up to speed on the UML.

This book's collection of process patterns is the foundation for best practices in applications delivery, and align to a variety of methodologies, including the Rational Unified Process. These patterns can also be used as the basis for key process areas for achieving increasing levels of capability maturity or process improvement capability for organizations that use SEI's CMM or ISO/IEC
15504 (SPICE).

Chapter 1 assumes no prior knowledge of patterns or object-oriented software processes, and gives a descriptive overview of both. It also discusses various approaches to software development, which provides a context for how patterns can fit within various approaches, such as serial, iterative, incremental or parallel projects. It also introduces a process framework called Object-Oriented Software Process (OOPS)and compares this process to other common OO approaches to development. Although this book is structured for OOSP, the patterns will fit within any framework or methodology. This makes the book valuable to any shop regardless of whether OO or traditional procedural languages and approaches are used. A highlight of this chapter is the discussion of process maturity that uses SEI's CMM as a baseline. The information can be realigned to SPICE or Bootstrap as well because there is no firm bias towards the CMM - I suspect the CMM is used because it's well known to U.S. readers.

The book is divided into parts after chapter 1, with each part aligned to a life cycle stage and comprised of a collection of chapters that describe patterns that are applicable to the stage. Each chapter is a pattern and is structured as Initial Context, Solution, Solution Project Tasks, Resulting Context, Process Checklist and What you have learned.

Part I is the INITIATE stage. Patterns include: Initiate Phase (how to start the phase itself), Define and Validate Initial Requirements, Define Initial Documents, Justify and Define Infrastructure. Part II is CONSTRUCT, with patterns for Construct Phase Initiation, Model, Program (development), Generalize and Test in the Small.

What I like is the format of the patterns make them easy to read and consistent. It is easy to tailor them for organizational use, as well as to add more patterns. It also adds a defined structure to the development process itself, providing a solid basis for documenting key process areas and defining development workflow. The second book in this series, More Process Patterns, completes the pattern library by addressing test, release and operational aspects of applications and systems. I read that book last February and feel that both books should be a part of any mature development organization, or organizations that are seeking to improve their processes and capabilities maturity.

In the two years since I first read this book I have found myself going back to it like an old friend. It is a constant source of information that focuses on application development processes that are set forth in the form of patterns.

The explanatory text covering processes, phases and stages in the OOSP (object-oriented software process) has crystalized the development process like no other book in my library. The accompanying patterns have been a source of best practices that I keep referring to in one consulting engagement after another.

This, and the companion (More Process Patterns) are an A to Z resource for development, application delivery and service delivery. I have used it in the past as a resource for developing and implementing software engineering processes. My present situation (in early 2001) finds me using this book as a source of ideas on how to integrate application delivery and service delivery for a model on information technology management that I co-developed. The approach provided in the book, the framework of OOSP, and the patterns themselves have heavily influenced the development and refinement of the model. They have also further clarified my ideas on development life cycles that have led me into the Rational Unified Process camp.

From the foregoing it is clear that this book remains a valid reference on system development, as well as the foundation of service delivery (which is addressed in more detail in More Process Patterns). It is also must reading for project managers and software engineering process practitioners. What is not so obvious, but in my opinion eaqually valid, is that this book also provides a foundation for a solid software quality assurance program. It does so by providing patterns that have clearly defined quality objectives for every phase and stage in the development life cycle. This is an unexpected bonus that I did not catch the first time through the book.

I strongly recommend that anyone involved in development (maintenance or project level efforts), and SQA read this book. If your focus is application and service delivery, get this book as a foundation for More Process Patterns, which is more applicable to those areas. Regardless of what your job is in the IT or consulting world you will find information and ideas that in this book that will influence your thinking and approach.

I was really impressed with this book, and it's follow-up, More Process Patterns. It's about time someone described a software process that can be used by actual development teams, likely because it is written based on the author's real-world experiences. He tackles all the issues of software development, not just the cool ones such as modelling and programming that everyone else appears to focus on. The fact that he has shown how "boring" topics such as quality assurance, risk management, reuse, and people management fit into the picture throughout the entire software process makes the book worthwhile for any project manager. The programmers that I've shared the book with have gotten a lot out of it, in fact one was even amazed at how complex software development actually is. A true eye opener. There is something in this book for everyone.

I think readers will benefit most from the general philosophies that pervade the book, such as testing early and often, letting requirements drive modeling which drives programming (i.e. think first, then act), taking maintenance and support into consideration, and actually doing the work necessary to obtain high levels of reuse. I highly suggest this book to anyone involved in the development of software. Although the book is large, 550 pages, it is an easy read. Another good thing about it is that it's size and content make it a good book to beat your pointy-haired managers over the head with when they do something stupid like set an unrealistic schedule for your team.

Be forewarned. This book expresses very little original thought and is merely a collection of "other peoples" articles. This provides for very little logical flow for someone wanting to apply RUP. Where are the examples, tips of the trade, and how-to's?

Shame on me for not having gone to the book store first to look at the book as the online description gives no indication that it was in a periodical format.

I expected more from Scott after having read is other great "original thought" books.

The guy from Toronto got it right. This is a great book that collects really good articles written by some of my favorite writers. I first read the Construction Phase book then quickly bought this book and the Inception phase book and have found all three to be valuable. My company is trying to implement the RUP right now and struggled because there was clearly some missing techniques. This book series presents a lot of what is missing in the RUP, and it really helped us to fill in a lot of the missing stuff. Too bad Ambler and Constantine don't work for Rational.

This is a really great book. It goes into detail about an improved version of the lifecycle for the Unified Process, one that actually addresses the real world needs of most companies. Trying to use the RUP on multiple projects? Trying to have a common architecture between them? Worried about integrating with your legacy systems? This book covers these topics and more with some of the best articles ever published in Software Development magazine. I'm really into some of the philosophies of XP and as a result really liked the chapter on testing which presents a wide range of testing techniques and strategies. The A&D chapter included a really great article about distributed object design by Scott Ambler and one about Java interface design by Peter Coad, two topics critical for EJB development IMHO. The business modeling chapter was excellent, covering essential modeling, business rules, and a great UML article by Martin Fowler. It's amazing how this book collects some of the best material written by the best minds in the computer industry.

Personally, I can't imagine anyone adopting the RUP without first reading this book series. I think it's great that someone has gone to the effort to sort through the best articles written by some of the best minds in this industry. Kudos to Ambler and Constantine for having the courage to stand up and say what many others have been afraid to.

A good coding standard should focus on advice that encourages the correct and consistent application of a language. The more widely-adopted a standard is, the more benefit. No less than the Java Language Specification acknowledges this by listing a limited set of naming and usage practices. While the JLS falls far short of establishing a complete coding standard, the naming conventions it established have alone been of great benefit to the Java community. The "Elements of Java Style" nicely fills the gap left by the JLS in other areas, although it too falls a little short in places--thus the 4 star rating instead of 5.

I strongly suggest "Effective Java" by Joshua Bloch as a companion to this book. Whereas the 108 rules in this book focus on style, format and many pearls of practical advice, "Effective Java" provides an excellent set of 57 rules that go much deeper and tackle more advanced aspects of writing correct and consistent code. The two books complement each other well.

Of the 108 rules, the most glaring technical error is rule #99 which promotes the use of the flawed double-check synchronization pattern. Ignore this rule.

The 108 rules are divided into six chapters as follows:

4 General Principles: While I would have added a few, the four here are quite sound.

4 Formatting Conventions: Programmers tend to get weird about code format. After long enough you realize any reasonable and consistently adhered to standard is fine, so just use this well-considered set.

23 Naming Conventions: These are of great benefit as they resolve the ambiguities left by the JLS. I especially like rule #12, "Join the vowel generation".

35 Documentation Conventions: These very well-reasoned conventions will help to produce useful documentation as well as to eliminate unnecessary or excessively wordy documentation. The rules target both internal and external documentation as emphasize the different goals of each.

37 Programming Conventions: While there is a lot of good advice in this section, it also contains some of the weakest advice. Rule #74 on enumerations is flawed ("Effective Java" provides better coverage on how to use enumeration classes). The section on using assertions (4 rules) doesn't mention the important rule to only use tests with no side effects. It will also need to be modified for the assertion facility being added in J2SE 1.4. The section on threads and synchronization is the weakest (7 rules) as it contains rule #99 as well as some weak and incomplete advice in rules #97 and #98.

5 Packaging Conventions: This section contains some good advice not just on how to organize your classes into packages, but also on how to design stable packages.

Particularly on points of style and format, individuals will find aspects of any coding standard (at least any standard they didn't author) that they disagree with. Having written several coding standards in a variety of languages, I too have some rules I would have written differently. However, the benefit of a language-wide coding standard is that if everyone follows it, then everyone benefits from that shared agreement.

My company has adopted "The Elements of Java Style" as its coding standard with as few amendments as possible. You and your company should too.

This is an excellent quality work that can be used to instill quality in others. Don't bother writing up a long list of company do's and don'ts, just hand out this book. It covers coding style, documentation style, and lots of Java tips and techniques. It's exactly what I've been looking for, I just wish someone would write a similar book for HTML, XML, XSL, Transact-SQL, and all the other languages we use at work. This book is very concise, I was able to read it in a day, but it very heavily favored quality over quantity. I can't think of a tip that they left out, and every tip that needed illustration had an accompanying clear example. A perfect work and just what I've been needing.

This book offers a good style reference for programmers to agree upon, enabling them to move on to focus attention on larger issues for discussion. Along with style guidelines, the book offers a good assortment of coding practice suggestions as well. Such as; lazy instantiation of objects, not creating objects that might go unused, and many more. The book consists primarily of concepts most programmers would consider common sense. However, the fact that it pools so many of these relatively simple concepts is what makes it so valuable. For work environments where people care about spending their time debating more architectural and design related issues, this book is a must to snub out any time wasting coding standards bickering. This book coupled with Dov Bulka's 'Java Performance and Scalability' are must-reads.

This book is great! As a hotshot developer who now finds himself in the ranks of management, this book is a life saver! It is harder and harder for me to get time to do all the reading I really need to do. This book brings together the articles with substance and then flavors the content with insightful editor review. Thanks for producing this series.

I appreciate this effort by Ambler & Constantine. It is hard for someone like me who has moved from hotshot developer to "visionary leader" (management) to keep up with all my reading. This series has been a blessing by consolidating the appropriate articles for me read. The contents give me many useful perspectives to consider. Thanks.

This is a great book that is part of a great book series. I wasn't sure that a collection of magazine articles was worth paying for, but this book is far more than that. It helps to put the Construction Phase of the RUP into context and actually goes beyond the vanilla version of the RUP to provide advice that I could actually use.

There was a lot of articles about storing objects in relational databases, an idea that put me off at first, but being on an EJB project right now I discovered that these articles really helped me out.

An adept application of common sense--and the author's significant experience--to the use of models in software development.

A model can be almost anything that developers make to describe the software that they build--just like an architect's drawings.

A given software development effort might call for any number of different types of models including data models, class models, sequence diagrams, dataflow diagrams, statechart diagrams, etc. The set of models used on any particular project will depend partly on the nature of the project and partly on the preferred methodology of the software developers.

Agile Modeling (AM) is not itself a software development methodology. It is a collection of principles and practices to follow when using models to develop software according to a methodology like Rational Unified Process (RUP) or eXtreme Programming (XP). Many of the practices derive from an application of XP concepts.

AM challenges a number of practices widely followed (or at least preached) in organizations developing software:
1. Specializing personnel in producing a single type of model
2. Dedicating work sessions to producing a single type of model
3. Saving models after the software is developed
4. Keeping models up-to-date during and after the development project
5. Using sophisticated software to assist in modeling
6. Finishing models before coding software

AM does not in all cases prohibit these practices, but it emphasizes that the purpose of a software development project is to develop software--not just to develop models. The practices of AM help to keep models in their proper subordinate relation to the working software that is the true goal of any development project.

People with more luck than experience might doubt the need for agile modeling. Please accept from a reader with much more experience than luck an assurance that the need is great. This reader has personally witnessed development projects undertake the costly construction of models having at best a tenuous relation to the software to be developed.

It should in fact come as no surprise. Who would not agree that it is easier to waste other people's money than to abandon one's own obsessions?

At any rate, Mr. Ambler tries to keep us on track with this excellent book, challenging us to use models but to stay focused on software.

Different readers are likely to be challenged to different degrees by AM's various principles and practices. This reader easily accepted, for example, the practice "Create Several Models in Parallel," counseling us to construct multiple model types simultaneously and to eschew the antipatterns of "Single Artifact Developers" and "Single Artifact Modeling Sessions" (pp. 47-50).

The principle "Maximize Stakeholder Investment" proved more challenging. It counsels that project stakeholders (i.e. the businesspeople commissioning the development project)--not software developers--ought to decide whether to develop software documentation (p. 37). True, the stakeholders pay the bills, but architects and accountants also have paying clients who are nevertheless not able to dictate everything about their work. Clearly software development should have professional standards whose suspension may not be commanded even by a paying client.

Another challenge for this reader: "Agile modelers typically do not bother to distinguish between the different "flavors" of modeling, . . . (p. 252)." Here Mr. Ambler is writing about what Martin Fowler calls "perspectives"--conceptual, specification, and implementation--that a model might take on its subject. These perspectives correspond to the business analysis, system analysis, and system design phases of a software development project.

In his "UML Distilled," Mr. Fowler differs sharply from Mr. Ambler: "Understanding perspective is crucial to both drawing and reading class diagrams. . . . it is very important to separate the specification perspective and the implementation perspective (p. 52)."

Or does he? Mr. Ambler hedges his position in the very same sentence: ". . . they just model appropriately as the situation calls for." Now, how can one "model appropriately" if one does not first "bother to distinguish"?

Elsewhere too, the advice of AM can seem equivocal (or is it "nuanced"?). The practice "Collective Ownership" allows everyone on a project to work on any of the project's models. This "power to the people" is however greatly diluted by the practice "Model with Others," prohibiting anyone from modeling alone. Further dilution appears in the case study, where it is recognized that one would be foolish to work on a database design without consulting "Brendan, the database administration (DBA) expert on the team (p. 288)."

It is interesting to compare Mr. Ambler's populist principles for teamwork with the more elitist principles of Frederick Brooks in "The Mythical Man-Month." Mr. Brooks begins his third chapter by citing the "wide productivity variations between good programmers and poor ones." He derives from this observation a software development organization patterned after a surgical team--with one operating surgeon and a small flock of assistants.

Although starting from opposite principles, Brooks and Ambler finish peculiarly close in their team-building practices. A la XP, Brooks's ideal team pairs the "surgeon" with a colleague equally gifted though less experienced. Inversely, Ambler approaches Brooks by listing in Chapter 12 the qualities of superior software developers. "Everyone can learn from everyone else" is one of the "supplementary principles" of agile modeling, but clearly some people have less to learn than others.

Mr. Ambler seems well read. He frequently cites related books throughout the text, adding a special recommendation here and there. One of these recommendations surprised this reader, who was astounded that Mr. Ambler found "UML for Database Design" by Messrs. Naiburg and Maksimchuk "a good read (p. 170)." You may find this reader's differing opinion filed with Amazon.com

Our difference on this small point serves only to highlight the strength of this reader's recommendation.

This is a provocative and well-reasoned explication. Agile Modeling will leave its mark.

If you are involved in any way with software development, you need this book. Although the title might suggest that it's concerned only with modeling, or with agile processes, the book implicitly (and necessarily) deals with most if not all aspects of the business of developing software.

Because the work was itself actually created using some of the agile practices (most notably, interaction with "customers" via the Agile Modeling mailing list), it speaks remarkably well to the concerns of actual practitioners, and is a remarkably thorough treatment of an issue with broad scope. Following the best principles of both agile development and open-source (and key AM values of Humility and Courage), the author revised and extended the book over the course of several months, displaying many draft elements on the AM website to be reviewed (and criticized) by fellow practitioners.

This book is grounded in reality, discussing what practices (agile and otherwise) people actually use, how they use them, and which of them work. Moreover, it describes many of the MOTIVATIONS behind certain practices, which is invaluable information both in applying (or eschewing) them, and in understanding and predicting the attitudes of various stakeholders to them.

Because it ties so many ideas together, this book will help to define software engineering into the future, even though it does not prescribe a methodology. It is well-structured and easy to use as a reference.

In short, this book has high technical AND business value. Indeed, it has value beyond the software business, probably across most business and engineering disciplines. I have my own copy, and plan to give some away as well.

Buy it.

In this book, Scott Ambler provides a practical approach to modeling that allows you to successfully deploy best practices on your agile software development project. From use case modeling to deployment diagrams, agile modeling defines these best practices for rapidly moving from requirements to code in a single, easy to read book. Additionally, Scott presents many of the nuances of software modeling that cannot be found in any other book.
Perhaps the most interesting part of Agile Modeling is that it is not only a book about a great software development methodology; it also suggests cultural changes to the way that we view modeling. These changes blur the line between traditional approaches such as those espoused by the Unified Process and the new culture espoused by XP. These ideas are very much in line with the way that software is successfully produced.
This book is not an entry-level UML book. If you are looking for basic UML, look at some of the entry level UML books. Instead, this book geared toward those who are actively producing customer grade software applications. It hits the mark squarely for those who want to be more successful in this endeavor.