Customer Reviews

Software Product-Line Engineering: A Family-Based Software Development Process

5 star:		(1)
4 star:		(0)
3 star:		(2)
2 star:		(0)
1 star:		(0)

 

 

This book really deserves two separate ratings. The first five chapters introduce domain engineering in general. If you are new to the idea of family-based software development, or need some convincing of its intended benefits, this section isn't bad. The two case studies presented gloss over some of the complicated concepts while providing too much technical detail in others. For example, the important but non-trivial job of creating the "decision model" for the domain is given minimal coverage. On the other hand, every class in the JAVA code used to illustrate one example is explained individually. I'd give this section a 3-star rating as an introduction to domain engineering.

The rest of the book is an incredibly detailed reference into the authors' implementation of the FAST process. They spend two chapters bringing the reader up-to-speed on the process modeling technique called PASTA. Then they provide almost 200 pages of reference information (also included on CD-ROM) on the specifics of FAST. If you are looking for a recipe to use to try domain analysis and implementation in your company, this section covers it. If nothing else, you'll see a very well defined process modeling notation in action, one that can be used in many applications. Without any personal experience implementing the process, I hesitate to rate this section. But if the process works as well as this section is detailed, I'd give it at least 4 stars.

Its hard to say from their examples how well the FAST process will scale to industrial-size domains. But the authors have presented an easily read book with enough detail that a motivated software engineer may be able to win management support and give domain engineering a try.

I got the book delivered within a week and the book was in the condition as mentioned.

I've just about never worked on commercial software that was shipped in only one form. There have been variations in the platform configurations, in the functional options, or in the generation of product. This book addresses the process of building families of software products, the kind that derive generally similar sets of functionality from a shared code base, i.e., the majority of commercial software in my experience.

The authors start with an obvious premise, but a premise that's overlooked far too often. They start by saying that their approach does not work in all cases, and may not work in yours - if only such honesty were more common! Although it makes the third, or fourth, or tenth member of the product family easier to develop, it incurs design and implementation costs up front. Despite long term economies, the first few family members might actually cost more than with one-off design techniques. The first step in this methodology is to decide whether the next steps will actually do you any good.

After that, though, I find this to be only an ordinary presentation of software design methodology. Although it adds steps for analyzing product families to the standard software development cycle, those steps are only a small part of the whole. At least 90% of the cycle is the same for a one-off project as for one where massive reuse is a major design goal, but the authors present the entire cycle in detail. I'd even say excruciating detail. The second half of the book, 200 pages or so, presents the methodology one step at a time, often one step per page, with forms to be filled out at each step: formal pre- and post-conditions, lists of involved participant, artifacts generated or modified at each step, and on and on and on.

Despite it's overwhelming mass of detail, I find it systematically lacking in one major respect. The first pass over the process is only a small part of any long-lived project. After that, every successive design cycle takes the entire result of the previous cycle as input. In some sense, acknowledgement of the past is the first and biggest requirement, where the past consists of all code and documentation artifacts from the previous effort. "Green field" construction is a rarity in the software world, but a premise of most design methodologies, this one included. The second major weakness in this book may just be a matter of editorial choice: it addresses the organizational aspects of the project only, with few (if any) tips for the technologist creating a line of products. The techniques of design for flexibility, especially for variation over time, cover whole ranges of topics that aren't part of this dicsussion.

So we're left with a mass of imposing organizational detail, with reams of families of forms and formalities. These could become oppressive if not handled in a context-sensitive way, but the authors say little about tailoring the process to different environments. And, anong what's presented, only a small part is specific to the product-line problem as opposed to any other software development. I'm still looking for stronger technical advice and a more flexible approach.

//wiredweird