Foreword
When I agreed to write the foreword for this book, I expected to battle my way through a morass of technical jargon. I was willing to do this because the Unified Modeling Language (UML) is an approach widely used at the Raytheon Garland, Texas, site and I wanted to expand my knowledge of it. I must honestly admit that I started reading the text with dread and with a rather basic (and somewhat cynical) question: Other than a general understanding of what UML is, why should I care about it?
In my position as Director of Software Engineering, I rarely need detailed knowledge of development languages and tools, not to mention the fact that these development aids are constantly changing. UML, however, seems to have caught the attention of my software engineers, so I marched forward into Process Quality Assurance for UML-Based Projects. I convinced myself that quality assurance and process were at least familiar words and an integral part of my job.
Then something amazing happened: I couldn't put the book down. The introduction to the elusive nature of quality is consistent with my own views, and these views are well expressed (and frequently humorous). The historical facts behind UML (Booch, Jacobson, and Rumbaugh creating UML), the definition of UML (a means of visualizing, constructing, and documenting object-oriented software artifacts through a standard set of notations, diagrams, and specifications), and the relevance of UML to practical modeling are stated succinctly. The text deepens the reader's understanding of the direct and practical aspects of modeling with UML through the discussion of UML-based CASE tools and processes, which can contribute to requirements modeling and testing as well as system, database, and architectural design. As I read through the text, I condensed the information into the following major concepts:
UML standardization is a good thing for large programs.
UML supports major program activities associated with requirements, testing, design, and implementation.
UML is effective in reducing the complexity of and enhancing the ability to test reality.
UML addresses some of the most serious problems in system development, especially satisfaction of user expectations.
UML helps mitigate the long-standing problems related to the intangibility of software.
UML helps clarify interdependencies, which are common problem points in system integration.
UML is not a monolithic construct—it has a different relevance and application in each of the three modeling spaces of problem, solution, and background (architecture).
UML transition should be planned and handled carefully, particularly in separating UML techniques from its CASE tools and processes.
By the end of the first reading session, I became a fan of UML and Bhuvan Unhelkar's writing style. Instead of seeing UML as a software mystery understood by only the most esoteric guru or hard-core programmer, the reader begins to see UML as a value-added tool. In the quest for quality, UML supports system development through reduction of complexity, clarification of requirements, and addition of structure to the design and integration process.
One of the strong points of the text is the “big-picture” view of an entire program-development cycle. Unhelkar approaches the discussion of UML in the context of each modeling space and the process support required in each of these modeling spaces. The text is distinguished through the emphasis on definition of roles required to perform each process activity.
Many technical texts focus on the what, when, and how, but neglect the who. In this work, Unhelkar recognizes the importance of the sociological aspect of system development. In my own experience, I have seen system-integration program managers begin to recognize the psychological traits and attitudes of the program developers as valid parameters in determining and managing the program constraints of cost, schedule, and quality.
Traditionally, system development has been organized around technology and methodology. Nonquantifiable aspects of program success such as communication have been overlooked, despite the fact that poor communication accounts for a large percentage of project failures. Program managers focus on the triple constraints—quality, schedule, and cost. Unhelkar inspires the reader to also look at the second tier beneath each of these constraints—people, technology, and process. While making it clear that UML is not a process, the text addresses process-components with their respective roles, responsibilities, activities, tasks, and deliverables that produce UML-based artifacts.
Unhelkar has validly recognized that people are the key to building quality systems, and that training, organizing, empowering, and managing people are essential to producing a quality product. Emphasis on the human factors related to system developers and system users is found throughout the text. For example, Unhelkar states, “Proper study of quality would have to delve into other branches of science such as psychology, sociology, and social sciences.”
To develop a system, many competencies—both engineering and nonengineering—are required. Some of the less-technical competencies addressed include understanding the user, establishing trust relationships, evaluating and selecting component suppliers, developing cost estimations, preparing test plans, balancing cost and quality, balancing reuse against customer requirements and system quality/cost/schedule, creating and managing schedules, managing system configuration, developing flexible designs, and selecting and using appropriate metrics.
Obviously, finding individual engineers capable of fulfilling all the required roles in system development is a difficult task, if not an impossible one. The solution lies in the ability to form teams composed of members whose skills are complementary and cover the gamut of necessary roles. Issues that affect the ability to form such complementary and effective teams include project size, geographical distribution of team members, and inherent communication issues arising from the possible lack of face-to-face interactions.
The text addresses ways to assemble teams, the value of diversity, and issues arising in a virtual environment. Unhelkar also touches on profiling team members to help each one determine roles best aligned with their skills and interests. Domain expertise and mentoring are addressed and presented as tools to aid in team coalescence.
Unhelkar's belief in the value of mentoring is demonstrated in his approach to writing this text. He does not seem interested in impressing the reader with his technical jargon, but rather, he sets the stage for learning about the UML and its relation to quality by virtue of its application within the framework of a process. His analogies and examples are entertaining as well as instructive as he steps logically through the text material.
As a mentor to system-development professionals, he clarifies who should develop or review UML models of the problem space, the solution space, and the background space (architecture) of the system. He provides commonsense suggestions for determining the applicability of UML to a project, and for planning UML training and mentoring. His instruction is encapsulated in FAQs and exercises at the end of each chapter. As a result, the text can serve as an excellent seminal reference for practitioners, academics, and researchers. The text might also be selected as an excellent basis for a class or a self-study group as well as an ideal textbook used in a transdisciplinary or interdisciplinary engineering curriculum.
Unhelkar's practical understanding of issues that confront those who build systems adds a dimension to the text that is lacking in many technical writings. I applaud this unique blend of theory and practice and highly recommend this text as a reference for software-system projects, software engineering courses, and research in the areas of quality, modeling, and process. My best wishes are with the author for this influential work, and I offer encouragement for him to pursue future projects, especially in the areas of product integration, metrics, cost estimation, and sociological/psychological factors affecting project success. I believe that my enthusiasm for Process Quality Assurance for UML-Based Projects will be shared by all who read it.
Vicki P. Rainey, Ph.D.
Director, Software Engineering
Raytheon—Garland Texas Site