Register your product to gain access to bonus material or receive a coupon.
Process Quality Assurance for UML-Based Projects
- By Bhuvan Unhelkar
- Published Oct 30, 2002 by Addison-Wesley Professional. Part of the Addison-Wesley Object Technology Series series.
Book
- Sorry, this book is no longer in print.
Description
- Copyright 2003
- Edition: 1st
- Book
- ISBN-10: 0-201-75821-0
- ISBN-13: 978-0-201-75821-4
Quality is a subjective term, but while we may struggle defining it, experts recognize that bad quality can derail a software project or tarnish the reputation of a development organization. Good quality is difficult to achieve, but can be attained. This new book spells out a process that teaches practitioners how to achieve an acceptable level of quality. Ultimately, quality application development is all about satisfying the needs of the user. This book spells out a way to achieve that and produce a software product that can evolve, scale, and change according to the needs of the user and the business. As the Unified Modeling Language is the industry standard, the book appeals to a broad audience by defining how to use the UML to enhance quality. The author helps the reader understand the elusive nature of this pursuit, and the important role that modeling plays in software quality. The book also points out advantages, disadvantages, strengths, weaknesses, traps, and pitfalls of using the UML.
Sample Content
Online Sample Chapter
Quality Process Architecture for UML-Based Projects
Downloadable Sample Chapter
Click below for Sample Chapter(s) related to this title:
Sample
Chapter 3
Table of Contents
(NOTE: Each chapter concludes with FAQs, Exercises, References and End Notes.)
Foreword by Dr. Vicki P. Rainey.
Preface.
Acknowledgments.
I. SETTING THE SCENE FOR SOFTWARE QUALITY ASSURANCE.
1. The Quality Game.Elusive Software Quality.
Defining Quality!.
Quality and Objective Effort.
Nature of Software.
Assuring Quality: a Distinct Activity.
Pressures on Quality.
Budget.
Time.
Functionality.
Quality.
Quality Levels.
Data Quality.
Code Quality.
Model Quality.
Process Quality.
Management Quality.
Quality Environment.
Quality Software Process.
What constitutes a Process?.
A Sample Cooking Process.
The Orthogonal Process Relationship.
Process in Software Context.
Software Process.
Quality Process.
Quality Assurance and Testing: Lets not confuse them.
Modeling and Quality.
Purpose of Modeling.
Modeling Caveats.
Understanding Modeling Spaces in Software.
Problem Space.
Solution Space.
Background Space.
UML and Quality.
A Brief History of UML.
Quality of UML versus Quality by UML.
Quality by UML.
Quality of Visualization.
Quality of Specification.
Quality of Construction.
Quality of Documentation.
Quality Assurance Techniques of Syntax, Semantics, Aesthetics.
Quality Models—Syntax.
Quality Models—Semantics.
Quality Models—Aesthetics.
Quality Assurance of Software Process: Necessity, Sufficiency, Malleability.
Quality of Process—Necessity.
Quality of Process—Sufficiency.
Quality of Process—Malleability.
Reuse, Patterns and Quality.
Increasing Productivity through Reuse.
Reusing Expert Knowledge and Experience.
Applying Standards.
Quality and Usability.
Principles of Usability.
Navigability of Interfaces.
GUI Design and Quality.
UML-based Projects—types.
Development.
Integration (with Legacy).
Package Implementation (CRM, ERP).
Outsourcing.
Data Warehousing/Conversion.
Educational.
UML-Based Projects—Size and Scalability.
Small Projects.
Medium Projects.
Large Projects.
Putting it all Together (Key Points).
Bibliographic Notes.
Frequently Asked Questions (FAQs).
Exercises.
References.
II. ORGANIZING AND ENACTING THE PROCESS FOR QUALITY.
2. Quality Environment: Managing the Quality Function.Quality Management.
Quality Environment.
Non-Technical Management.
Process and Quality.
Team Organization.
Organizing the Roles in the Problem Space.
Business Analyst.
User.
End User.
Domain Expert.
Prototyper in Problem Space.
Organizing the Roles in the Solution Space.
System Designer.
Data Modeler.
Interface Designer.
Programmer.
Tester.
Prototyper in Solution Space.
Organizing the Roles in the Background Space.
System Architect.
Prototyper in Background Space.
Database Manager.
Common Roles.
Project Manager.
Steering Committee.
Business Sponser.
Organizing the Quality Team.
Quality Manager.
Quality Analyst.
Process Engineer.
User.
Tester.
The Quality Environment.
E-factor and Quality.
Soft Issues Specific to UML-based projects.
Communication in a Quality Environment.
Telecommuting.
Project Sociology.
Four models for Project Teams.
The Best Fit Approach to Creating a Homogeneous Team.
Flattening the Pyramid.
People in Reusability.
Parallel Development Teams.
Transactional Analysis in Software Projects.
A Brief History of TA.
The Parent, Adult, and Child Ego States.
The Life Positions.
Games.
Games in an OO Project.
Use It or Lose It.
Cowboy Programming.
Flour Mix.
Meetingitis.
Deadline.
Popular Quality techniques.
Walkthroughs.
Inspections.
Reviews.
Audits.
Checklists.
Interviews.
Workshops.
Standards and Quality.
Areas of application of standards.
Project, Organizational and Industrial Standards.
Process Maturity: The CMM Standards.
The Capability Maturity Model.
Personal Software Process Maturity.
Applying CMM in UML-based Projects.
Process Checks.
Checking What is Necessary.
Checking What Would Be Sufficient.
Checking the Malleability of a Process.
The Planning Deliverables.
Project Organizational Plan.
The Quality Plan.
Test Plan.
Bibliographic Notes.
Frequently Asked Questions. (FAQs).
Exercises.
References.
3. The Quality Process Architecture.The Process Backbone.
The Three Dimensions of a Process.
“What” of a Process.
“How” of a Process.
“Who” of a Process.
The Process Metamodel.
Describing the Process Metamodel.
Process Ingredients.
The Role Element in a Process.
The Activity Element in a Process.
The Task Element in a Process.
The Deliverable Element in a Process.
A Process-Component.
Iterations.
Putting Together a Process-Component: A Baking Process.
Quality Software Process.
The Software Process.
The Quality Process.
Rigorous Process.
Process Maturity.
Malleable Process.
Process Timings.
The Software Process.
Business Evaluation Process-Component.
Roles in Business Evaluation.
Activities and Tasks in Business Evaluation.
Deliverables in Business Evaluation.
Quality Comments on Business Evaluation.
Project Management Process-Component.
Roles in Project Management.
Activities and Tasks in Project Management.
Deliverables in Project Management.
Quality Comments on Project Management.
Process Configuration Process-Component.
Roles in Process Configuration.
Activities and Tasks in Process Configuration.
Deliverables in Process Configuration.
Quality Comments on Process Configuration.
Requirements Modeling Process-Component.
Roles in Requirements Modeling.
Activities and Tasks in Requirements Modeling.
Deliverables in Requirements Modeling.
Quality Comments on Requirements Modeling.
Interface Modeling and Design Process-Component.
Roles in Interface Modeling.
Activities and Tasks in Interface Modeling.
Deliverables in Interface Modeling.
Quality Comments on Interface Modeling.
System Design Process-Component.
Roles in System Design.
Activities and Tasks in System Design.
Deliverables in System Design.
Quality Comments on System Design.
Persistence Design Process-Component.
Roles in Persistence Design.
Activities and Tasks in Persistence Design.
Deliverables in Persistence Design.
Quality Comments on Persistence Design.
Implementation Process-Component.
Roles in Implementation.
Activities and Tasks in Implementation.
Deliverables in Implementation.
Quality Comments on Implementation.
Prototyping Process-Component.
Roles in Prototyping.
Activities and Tasks in Prototyping.
Deliverables in Prototyping.
Quality Comments on Prototyping.
Change Management Process-Component.
Roles in Change Management.
Activities and Tasks in Change Management.
Deliverables in Change Management.
Quality Comments on Change Management.
Enterprise Architecture Process-Component.
Roles in Enterprise Architecture.
Activities and Tasks in Enterprise Architecture.
Deliverables in Enterprise Architecture.
Quality Comments on Enterprise Architecture.
System Architecture Process-Component.
Roles in System Architecture.
Activities and Tasks in System Architecture.
Deliverables in System Architecture.
Quality Comments on System Architecture.
Deployment Process-Component.
Roles in Deployment.
Activities and Tasks in Deployment.
Deliverables in Deployment.
Quality Comments on Deployment.
Training Process-Component.
Roles in Training.
Activities and Tasks in Training.
Deliverables in Training.
Quality Comments on Training.
Reuse Process-Component.
Roles in Reuse.
Activities and Tasks in Reuse.
Deliverables in Reuse.
Quality Comments on Reuse.
The Quality Process.
Quality Management Process-Component.
Roles in Quality Management.
Activities and Tasks in Quality Management.
Deliverables in Quality Management.
Quality Comments on Quality Management.
Quality Assurance Process-Component.
Roles in Quality Assurance.
Activities and Tasks in Quality Assurance.
Deliverables in Quality Assurance.
Quality Comments on Quality Assurance.
Quality Control Process-Component.
Roles in Quality Control.
Activities and Tasks in Quality Control.
Deliverables in Quality Control.
Quality Comments on Quality Control.
Bibliographic Notes.
Frequently Asked Questions(FAQs).
Exercises.
References.
4. Enacting the Quality Software Process.Configuration of a Process.
The Waterfall-Based SDLC.
The Spiral-Based SDLC.
The Fountain-Based SDLC.
The Iterative, Incremental, and Parallel Development Process.
Need for Iterations and Increments.
Initial.
Major.
Final.
Parallel Developments within a Lifecycle.
Maintenance or Ongoing Iteration.
Adoption of the Software Process.
Ascertain Current Process State.
Crucial Pilot Project.
Point of Adoption.
Separating UML from the Process.
Keeping All CASE Tool Implementations Separate.
Training and Mentoring. BHEADS = Access to the Process.
Enacting the Quality Process.
Creating Iterations and Increments in Lucky Insurance's Development.
An Iterative Project Task Plan.
Iterative Project Management Tools.
Tracking Quality throughout the Process.
Importance of Road Factors in Process Enactment.
Quality Activities at the End of the Initial Iteration.
Quality Activities at the End of the Major Iteration.
Quality Activities at the End of the Final Iteration.
Frequently Asked Questions (FAQs).
Exercises.
References.
5. Estimates and Metrics for UML-Based Projects.About Estimates and Measures in Software Projects.
Relating Estimates to Quality.
Measurements and Estimates.
Measuring the Technological Dimension.
Measuring the Methodological Dimension.
Measuring the Sociological Dimension.
Project Metrics and Estimates.
Project Size and Type.
Project Time, Budgets, and People.
Caveats in Project Estimates.
Measurement of Processes.
Why Measure Processes?
Measuring Process-Components in Deployment.
Measuring Process-Components in Enactment.
Refining the Project Estimations at the End of Each Iteration.
Quality Metrics.
Measuring Size of Software.
Traditional Measures of Software.
Additional Measures of Software.
Object-Oriented Measures of Software.
Measures of UML Artifacts, Diagrams, and Models.
Measuring Size and Complexity of Use Cases and Use Case Diagrams.
Measuring Size and Complexity of Classes.
Measurement of a Component.
Testing Metrics.
Applying Metrics and Estimates to Lucky Insurance's Project.
Considering Metrics and Estimates Specific to Lucky Insurance's Project.
Project and Process Metrics in Enactment.
Measuring Process-Components for Enactment.
Applying Process and Project Metrics to Lucky Insurance's Project.
Arriving at the Productivity Factor for Lucky Insurance's Project.
Refining Estimates Based on the Productivity Factor for Subsequent Iterations.
Prophetic Statements on Estimates and Metrics.
Bibliographic Notes.
Frequently Asked Questions (FAQs).
Exercises.
References.
III. TESTING THE PRODUCT: QUALITY CONTROL.
6. Quality Control of Software Products.Testing in Context.
Testing Approaches in UML-Based Projects.
Black Box.
White Box.
Manual Testing.
Automated Testing.
Vertical Testing.
Horizontal Testing.
Equivalence Partitioning.
Boundary Value.
Testing Architecture.
Unit Test.
Component Test.
System Test.
Acceptance Test.
Regression Test.
Operational Testing.
Performance (Stress and Volume) Testing.
Security Testing.
Scalability Testing.
Test Planning.
A Good Test Plan.
Analyzing Risks in Testing.
Test Environment.
Test Resources.
Development Environment.
Test Environment.
Test Schedules.
Test Cycles.
Reusability in Testing.
Test Design.
Description of Test Designs.
Sources for Test Designs.
Format for Test Designs.
Test Cases.
Description of Test Cases.
Designing the Test Cases.
Format for Test Cases.
Example Test Case.
Verifying the Test Cases.
Modifying the Test Cases.
Test Execution.
Getting Ready.
Acceptance Criteria.
Execute Test Suites.
Record Incident Reports.
Recording and Analyzing Test Results.
Software Incidents.
Recording Test Results.
Analyzing Results.
Reporting.
Bibliographic Notes.
Frequently Asked Questions (FAQs).
Exercises.
References.
Glossary of Acronyms and Important Terms 345Bibliography 349
UML CASE Tools 355
Process Tools Using UML 365
Epilogue 373
Index 375 0201758210T10042002
Preface
Purpose of this Book
The convenor of the OOSIG (object-oriented Special Interest Group) of the Australian Computer Society is occasionally referred to as Chairperson. For past two years, this honorary and honourable title has been conferred upon me and, as the title suggests, it provides me with -- amongst other things -- the unenviable job of moving and organising chairs before the monthly meeting starts and ensuring they are stacked back against the wall after the meeting in the society's office is over. Getting the flipcharts and whiteboard ready, booking the room, sending the invitations, organising coffee and keeping the data projector light bulb from blowing up are some things keep the adrenaline level of the 'chairperson' always on high.
However, I had no such challenges to face when Canada-based Bran Selic, kindly addressed my SIG. Many members turned up to listen to one of the original contributors to the Unified Modelling Language's meta-model, particularly to the behind-the-scene stories. One of the interesting features of Bran's talk was the candid highlighting of the strengths and weaknesses of the UML. Couple of reasons for UML's popularity, as emerged during the talk were:
- UML is a standard and therefore accepted within the larger IT community, and
- UML came on the IT scene at the right time.
The UML fills the void that existed in software development -- a modelling mechanism that enables capture and expression of requirements, documentation of design, facilitates architectural discussion and supports software implementation. The modelling capabilities of the UML, supported by CASE tools, are widely used in numerous practical software projects. Further, professional training courses on business analysis, architecture, design and testing are routinely based on the UML standard. The UML is also popular in the academic world as many university courses use the standard notations and diagrams of the UML to teach the students principles of software engineering. Finally, through relatively less-technical and more business-focused works, object technology and the UML have shown to be capable of being used in non-software related work, such as modelling business processes (BPR), business workflows, and even software workflows.
Despite its popularity, however, the UML literature still needs discussion on and application of quality with UML. While we have some excellent literature on the processes of software development it seems to fall short of separate and detailed discussions on quality. On the other hand, works like Binder's focus on the technical aspects of testing, using the UML notations, do not provide the process-aspect of improving the quality of software development. Indeed, none of this literature deserves any criticism for the lack of quality discussion -- because these literary works do not purport to be discussing quality. The focus of these respectable and popular works is either development or testing. This book is written with an aim of directly addressing the paucity of literature in the area of process quality assurance for UML-based projects.
Good Quality is all about satisfying the needs of the user. However, good is a highly subjective term. The reference-point against which quality is judged depends on time, place, and situation -- all of which can change! Hence, the essential ingredients in producing good quality are:
- A product that satisfies the changing needs of the user
- A process that enables creation, verification and validation of such a product
- A common mechanism to establish communication
- Continuous improvement of the process of producing product
When applied to software development, these 'quality requirements' translate into producing a software product that would evolve, scale and change, according to the needs of its users -- primarily the business. Not only do we need a process for developing such a software product, we also need significant checking and crosschecking of the models and processes that have built the software product. There is a need to ensure the syntactical correctness, semantic consistency and aesthetic symmetry in the models that will be used to produce good quality software. There is also a need to create, follow and check all necessary process steps in order to achieve maturity of processes that will result in good quality software products. Furthermore, these process steps must be executed iteratively, incrementally and sufficiently. Process steps should also be malleable enough to suit various development environments, and various types and sizes of projects.
The specific and significant areas of quality related work required in a process incorporating the UML are addressed in this book. The quality techniques discussed in this book include how to organize the overall quality function, the process steps to be followed in creation of UML diagrams, the steps in verification and validation of these diagrams, when to conduct such verification, how the interpret the results of quality activities, who should create and validate the UML diagrams, and how to create a quality control (testing) strategy. Because of the process focus in this book, the techniques of creation of UML diagrams is assumed to be known to the readers.
Summary of the Book
This book is divided into 6 chapters as summarized below.
Chapter 1: The Quality Game
In this background chapter on quality assurance we discuss the elusive nature of quality in the context of software. Modelling, particularly with the UML, is shown as means to improve communication and quality and is conducted in the three distinct yet related modelling spaces of Problem, Solution and Background. Process is discussed in the context of its three dimensions of technology (what), methodology (how) and sociology (who). This is followed by discussion on the various checks (syntax, semantics and aesthetics) needed to validate and verify UML-based models and the checks of necessity, sufficiency and malleability needed for a good quality process. Organization of the quality function, and its application to various types of projects (development, integration, package implementation, outsourcing, data warehousing, and educational) as well as various sizes (small, medium, large) of projects are also discussed here.
Chapter 2: Quality Environment: Managing the Quality function
Process aspect of quality encompasses the 'management' functions of creating and managing a quality environment. This is because software quality is not just verifying and validating what has been produced but also a sustained effort at following the discipline of producing models and software. This discipline encompasses the process or the steps involved in producing good models and good software. This part of this book comprehensively considers organization and execution of the quality function with detailed emphasis on the process of developing UML based software. In other words we discuss how the quality function is organized and carried out in UML-based projects. The people issues (who) is also given due relevance in this part of the book.
Chapter 3: Quality Process Architecture
This chapter discusses what constitutes such a process, and how it will be helpful in enhancing quality in a UML-based project. This chapter does not propose a new process, but discusses a most generic Process including the Technological, Methodological and Sociological dimensions -- what constitutes a process, and what are its major dimensions of a process is described here. The technological dimension of a process deal with the what, the methodological dimension with the how and the sociological dimension with the who, of an overall process. These dimensions are described with common workday examples. Furthermore, the generic process also describes the most commonly used activities and tasks that should be there in any process. These activities and tasks, and the related roles and deliverables, are described with the aim of improving the discipline in a process, resulting in enhanced quality of UML-based deliverables and eventually the software product.
Chapter 4: Enacting the Quality Software Process
In this chapter we discuss the enactment of an example process including practical issues of configuring an iterative, incremental and parallel project plan, based on the process-components discussed in the previous chapter, are discussed here. We also discuss practical issues of tracking the progress of a project as well as modifying the project plan based on that tracking. An iterative and incremental project plan will facilitate better absorption of changes than a sequential project plan. Creation and management of such a 'changing' plan, derived from the malleability aspect of the process, are also discussed here. This chapter discusses what happens when the rubber hits the road in terms of application of a process.
Chapter 5: Estimates and Metrics for UML-based Projects
This chapter discusses the important issues of measurements and estimates in UML-based software projects. Starting with an argument for the need to make good estimates, and how good metrics help in making good estimates, this chapter delves into the importance of these measures and estimates in improving the quality of models and processes in the project. Technical measures related to sizes and complexities of the UML artefacts and diagrams is also discussed. Estimates for the example implementation project using the UML are shown with a view to demonstrate the application and significance of metrics in a practical project.
Chapter 6: Testing the product
This chapter will discuss in detail the quality control and testing aspect of a quality lifecycle. While we discussed process quality in previous chapters, quality control, or testing, is a major process-component dedicated to verifying and validating the results of our efforts thus far in creating models and following a process. Good quality control is inherently 'negative' as it is aimed at breaking everything in a system -- its logic, its execution, its performance. Thus, although Quality control is an integral part of quality assurance, but is not synonymous with it. This separation is given its due importance in this separate part of this book.
CD & Potential Web Support
The CD contains details of the chapters, diagrams, and a set of templates that can be customised for use in projects. Suggested metrics for improving quality (e.g. size of use cases, effort in creating classes) are also incorporated in the CD. Evaluation copies of relevant process tools that deal with quality process have also been provided, with permissions.
Literary Audience
There are a large number of books written on UML and similarly on processes. Their scope encompasses both academic research and practical applications. This book attempts to synergies the application of quality processes in UML-based projects. With the 'process focus', the reader is expected to be familiar with UML and its modelling techniques as the book does not purport to discuss the modelling techniques of the UML. However, a person responsible for quality assurance will find this work self-sufficient and may even be encouraged after reading this material to extend their understanding further in to UML.
Semantics
This author firmly believes in gender-neuter language. Person is therefore used wherever possible. However, in order to maintain simplicity of reading he has been used as freely, and has been balanced by equal, if not more, use of she. Terms like programmer and quality manager, unless otherwise mentioned, represent roles performed by actors. These terms don't tie down real people like you and me who, in a short span of time, can jump from the role of a programmer to a quality manager to a director and back. It is also recognised that people may be playing more than one role at a time. For example, a business analyst may also be a part-time academic or a researcher.
We throughout the text primarily refers to the reader and the author -- you and me. Occasionally, we refers to the general IT community of which the author is a member. We also refers to the teams in which the author has worked. Therefore, although this is a single author book, you may encounter we as a reference by the author to himself, as well as to the IT community. Real conversations, as you and I are having through this work, cannot be 'statically typed'.
Mapping to a Workshop
The 'practical' aspects of UML and Quality, displayed in this book, have been popular in seminars and conferences. Amongst many presentation, particular noteworthy are its acceptance as a tutorial at the UML2001 conference in Toronto, Canada and the two-day seminar series in Mumbai, Bangalore and Delhi, in India. Here is a generic outline of the two-day workshop based on this book. For the education and academic community, each chapter in this book can correspond to a 3-hour lecture topic, with earlier part of the semester used in simply creating the UML-based models based on the case study.
Acknowledgements
Encouragement and support can take various forms --a word of encouragement here, hint of a smile there! And then there are those detailed discussions and arguments with honest reviewers of the manuscript on what should be included and how it should be presented. This is interspersed with the arduous task of typing sections of the manuscript, drawing the figures and the rather trying job of proofreading someone else's writing. All this has come to me through many wonderful people whom I acknowledge here gratefully:
Anurag AgarwalRajeev Arora
Craig Bates
Paul Becker
Christopher Biltoft
Bhargav Bhatt
Graham Churchley
Kamlesh Chaudhary
Sandra Cormack
Joanne Curry
Sanjeev Dandekar
Edward D'Souza
Con DiMeglio
Julian Edwards
Nandu Gangal
Athula Ginige
David Glanville
Mark Glikson
Nitin Gupta
Brian Henderson-Sellers
Murray Heke
Ivar Jacobson
Sudhir Joshi
Ashish Kumar
Vijay Khandelwal
Akshay Kriplani
Yi-chen Lan
Chinar & Girish Mamdapur
Javed Matin
Sid Mishra
Rahul Mohod
Navyug Mohnot
Narayana Munagala
Karin Ovari
Les Parcell
Chris Payne
Andrew Powell
Abhay Pradhan
Amit Pradhan
Anand Pradhan
Prabhat Pradhan
Rajesh Pradhan
Tim Redrup
Tracey Reeve
Prashant Risbud
James Ross
Magdy Serour
Bran Selic
Ashish Shah
Paresh Shah
Prince & Nithya Soundararajan
Pinku Talati
Amit Tiwary
Murat Tanik
Asha Unhelkar
Sunil Vadnerkar
Suresh Velgapudi
John Warner
Houman Younessi
Paul Becker, my editor at Addison-Wesley, has provided invaluable support in this work and deserves special recognition. Bearing with my delayed submissions, passing encouraging comments when the progress was slow and accommodating my changes up to the last minute are some of the traits of this considerate editor that are gratefully acknowledged.
Finally, my family makes all this possible by just being around me even, and especially, when I am mentally lost. I am grateful to my wife Asha, my daughter Sonki Priyadarshini whose view on quality took a jagged turn as she stepped into her teens, my son Keshav Raja who can appreciate quality in cars, bikes and planes -- which is the ability of these 'tools of the kindergarten' trade to withstand punishment meted out by rather tough 6 year olds.
Finally, this work acknowledges all trademarks of respective organisations, whose names and/or tools have been used in this book. Specifically, I acknowledge the trademarks of Rational (for ROSETM), TogetherSoft (for TogetherControlCenterTM), Object-oriented Pty Ltd (for ProcessMentorTM) and eTrackTM.
Critiques
It reflects a healthy state of affairs within the IT world, and especially the UML and process community, if work of this nature receives its due share of criticism. All criticisms have an underlying rationale and that they should all be accepted in a positive and constructive vein. All comments on this work, both positive and negative will be accepted positively. Thus, to all my prospective critics, whose criticisms will not only enrich my own knowledge and understanding of the 'quality' topics discussed in this book, but which will also add to the general wealth of knowledge available to the IT community, I wish to say a big thank you in advance.
Bhuvan Unhelkar
Sydney, July 2001
www.unhelkar.com
0201758210P07152002
Foreword
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
Index
Click below to download the Index file related to this title:
Index