BN.com Gift Guide

Process Quality Assurance for UML-Based Projects

Multimedia Set (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Multimedia Set)
  • All (4) from $1.99   
  • New (1) from $45.00   
  • Used (3) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$45.00
Seller since 2006

Feedback rating:

(341)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Boston, MA 2002 Trade paperback New. BRAND NEW. Object Technology Series. Audience: General/trade.

Ships from: Northbrook, IL

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

Software quality, by its very nature, is elusive. Add to that the issue of ever-changing user requirements and the vagaries of software project management and "quality" can easily become a mere word on a distant horizon. This highly acclaimed book demonstrates how the Unified Modeling Language (UML) can be used within a process framework to help reduce complexity, clarify requirements, and add structure to project management in order to yield software quality here and now.

Process Quality Assurance for UML-Based Projects focuses on the crucial process aspect of software quality. In an easy, entertaining way, the author outlines common-sense strategies for determining the applicability of UML to a project, creating and managing project teams, identifying levels of quality standards, applying quality techniques, and estimating and testing in UML-based projects.

With this book you will be able to:

  • Understand the elusive nature of software quality, the pressures on software quality, and the importance of processes and modeling in enhancing software quality
  • Divide modeling into three distinct but related spaces--problem, solution, and background space--and correlate the roles of business analyst, system designer, and system architect to these modeling spaces respectively
  • Understand quality discussions applicable to small, medium, and large projects
  • Appreciate the sociological aspect of quality management in software projects, including the value of transactional analysis (TA) in team formation and motivation
  • Relate to an iterative and incremental process based on the concepts of process-components and related activities, tasks, roles, and deliverables
  • Move your organization forward in terms of CMM process maturity
  • Gain valuable and practical insights into process and project metrics, measurements, and estimations
  • Appreciate the strategic aspect of testing as it relates to quality assurance
  • Understand quality discussions applicable to new developments, integration, package implementation, outsourcing, data warehousing, and educational projects
  • Access extremely well-referenced work by leading practitioners, researchers, and academicians
  • Estimate and refine process and project metrics

At the end of each chapter, key points are encapsulated in FAQs and exercises for easy referencing and team training.

0201758210B08132002

Read More Show Less

Product Details

  • ISBN-13: 9780201758214
  • Publisher: Addison-Wesley
  • Publication date: 10/28/2002
  • Series: Object Technology Series
  • Edition description: New Edition
  • Pages: 394
  • Product dimensions: 7.40 (w) x 9.20 (h) x 0.90 (d)

Meet the Author

Bhuvan Unhelkar, Ph.D., is the principal of MethodScience.com and is a globally respected consultant, trainer, author, and popular orator. Winner of the Computerworld Object Developer's Award for "Best Use of the OO Approach across the Organization," he is the author of four books and numerous papers, publications, and presentations.

0201758210AB08132002

Read More Show Less

Read an Excerpt

Purpose of This Book

This book is about the process aspect of quality assurance in UML-based projects. Process is one of the two major aspects of software quality assurance--the other being modeling. This book is written with an aim of directly addressing the paucity of literature in the area of quality assurance for UML-based projects--with a specific focus on process.

This is because despite its popularity, the UML literature needs discussion on and application of quality with UML. While we have some excellent literature on the processes of software development (most notably The Unified Process by Jacobson et al. and The OPEN Process Specification by Ian Graham et al.) it seems to fall short of separate and detailed discussions on quality.

On the other hand, works like Binder's Testing Object Oriented Software focus on the technical aspects of testing using the UML notations, but they 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 in your hand complements the current literature in the UML arena.

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 enablesthe 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 evolves, scales, and changes according to the needs of its users--primarily the business. We not only need a process for developing such a software product, but we also need significant checking and cross checking of the models and processes that have been used to construct the software product. There is a need to create, follow, and check all necessary process steps in order to achieve maturity of processes that result in good quality software products. 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. These are some of the specific and significant areas of process-quality-related work required in a project incorporating the UML that are addressed in this book. Some of this quality work includes how to organize the overall quality function, the process steps to be followed in the creation of UML diagrams, the steps in the verification and validation of these diagrams, when to conduct such verification, how to interpret the results of quality activities, who should create and validate the UML diagrams, and how to create a quality control (testing) strategy.

These process steps eventually result in good quality models. Quality, however, is further enhanced by applying quality checks to the software models--ensuring syntactical correctness, semantic consistency, and aesthetic symmetry. For detailed analysis and discussion of the model quality of UML diagrams, readers are encouraged to peruse Model Quality Assurance of UML-Based Projects (due 2003).

Summary of the Book

This book is divided into six chapters as summarized in the table below.

  1. The Quality Game: Builds the background theory and arguments for quality
  2. Quality Environment: Quality management, team formation, sociology, and psychology of quality teams; importance of process
  3. The Quality Process Architecture: Process-components encompassing activities, tasks, deliverables, and roles that make up a Quality Software Process
  4. Enacting the Quality Software Process: Quality process in practice; iterations, increments, and parallel development
  5. Estimates and Metrics for UML-Based Projects: Some suggestions on practical estimation of time, budgets, and people for UML-based projects
  6. Quality Control of Software Products: Detailed discussion on strategies for quality control and testing


Chapter 1: The Quality Game

In this background chapter on quality assurance we discuss the elusive nature of quality in the context of software. Modeling, particularly with the UML, is shown as a means to improve communication and quality and is conducted in the three distinct yet related modeling spaces of problem, solution, and background. We discuss process in the context of its three dimensions of technology (what), methodology (how), and sociology (who). This is followed by a discussion on the various checks (synt aesthetics) needed to validate and verify UML-based models and the checks of necessity, sufficiency, and malleability needed for a good quality process. Chapter 1 also discusses the 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 of projects (small, medium, and large).

Chapter 2: Quality Environment: Managing the Quality Function

The process aspect of quality encompasses the management functions of creating and managing a quality environment. This is because software quality is not just about verifying and validating what has been produced; it's also about sustaining an effort to follow the discipline of producing models and software. This discipline encompasses the process or the steps involved to produce good models and good software. This part of the book comprehensively considers the organization and execution of the quality function, with a 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") are also given due relevance in Chapter 2.

Chapter 3: The Quality Process Architecture

This chapter discusses what constitutes such a process and how it is 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 its major dimensions. The technological dimension of a process deals with "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 present in any process. These activities and tasks and their related roles and deliverables are described with the aim of improving the discipline in a process, resulting in the 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 the practical issues of configuring an Iterative, Incremental, and Parallel (IIP) project plan, based on the process-components discussed in the previous chapter. 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 facilitates better absorption of changes than a sequential project plan. The creation and management of such a changing plan, derived from the malleability aspect of the process, is also discussed. 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 to make good estimates, this chapter delves into the importance of these measures and estimates in improving the quality of models processes in the project. Technical measures related to sizes and complexities of the UML artifacts and diagrams are also discussed. Estimates for an 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: Quality Control of Software Products

This chapter discusses in detail the quality control and testing aspect of a quality lifecycle. While we discuss process quality in the previous chapters, quality control (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, and its performance. Thus, although quality control is an integral part of quality assurance, it is not synonymous with it. This separation is given its due importance in this separate part of the book.

CD-ROM and Potential Web Support

The CD-ROM contains details of the chapters, diagrams, and a set of templates (deliverables, project plan, and so forth) that can be customized for use in projects. Suggested metrics for improving quality (for example, size of use cases and effort in creating classes) are also incorporated on the CD-ROM. With permission, evaluation copies of relevant process tools that deal with quality process are also provided.

Semantics

I firmly believe in gender-neutral language. Person is therefore used wherever possible. However, in order to maintain reading simplicity 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 recognized 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.

Throughout the text, we primarily refers to the reader and the author--you and me. Occasionally, we refers to the general information technology (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. Among many presentations based on this book, particularly noteworthy are its acceptance as a tutorial at the UML 2001 Conference in Toronto, Canada, and the two-day seminar series3 in Mumbai, Bangalore, and Delhi, India. Many additional workshops and seminars are scheduled at the time of this writing. The following table is a generic outline of one day of a possible two-day workshop based on the topic of this book. For the education and academic community, each chapter in this book corresponds to a three-hour lecture topic, with the early part of the semester concentrating on creating the UML-based models based on the case study.

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 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 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
Revised, May 2002




About the Author:

Bhuvan Unhelkar, Ph.D., is the principal of MethodScience.com and is a globally respected consultant, trainer, author, and popular orator. Winner of the Computerworld Object Developer's Award for "Best Use of the OO Approach across the Organization," he is the author of four books and numerous papers, publications, and presentations.



Read More Show Less

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 345

Bibliography 349

UML CASE Tools 355

Process Tools Using UML 365

Epilogue 373

Index 375 0201758210T10042002

Read More Show Less

Preface

Purpose of This Book

This book is about the process aspect of quality assurance in UML-based projects. Process is one of the two major aspects of software quality assurance--the other being modeling. This book is written with an aim of directly addressing the paucity of literature in the area of quality assurance for UML-based projects--with a specific focus on process.

This is because despite its popularity, the UML literature needs discussion on and application of quality with UML. While we have some excellent literature on the processes of software development (most notably The Unified Process by Jacobson et al. and The OPEN Process Specification by Ian Graham et al.) it seems to fall short of separate and detailed discussions on quality.

On the other hand, works like Binder's Testing Object Oriented Software focus on the technical aspects of testing using the UML notations, but they 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 in your hand complements the current literature in the UML arena.

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 the 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 evolves, scales, and changes according to the needs of its users--primarily the business. We not only need a process for developing such a software product, but we also need significant checking and cross checking of the models and processes that have been used to construct the software product. There is a need to create, follow, and check all necessary process steps in order to achieve maturity of processes that result in good quality software products. 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. These are some of the specific and significant areas of process-quality-related work required in a project incorporating the UML that are addressed in this book. Some of this quality work includes how to organize the overall quality function, the process steps to be followed in the creation of UML diagrams, the steps in the verification and validation of these diagrams, when to conduct such verification, how to interpret the results of quality activities, who should create and validate the UML diagrams, and how to create a quality control (testing) strategy.

These process steps eventually result in good quality models. Quality, however, is further enhanced by applying quality checks to the software models--ensuring their syntactical correctness, semantic consistency, and aesthetic symmetry. For detailed analysis and discussion of the model quality of UML diagrams, readers are encouraged to peruse Model Quality Assurance of UML-Based Projects (due 2003).

Summary of the Book

This book is divided into six chapters as summarized in the table below.

  1. The Quality Game: Builds the background theory and arguments for quality
  2. Quality Environment: Quality management, team formation, sociology, and psychology of quality teams; importance of process
  3. The Quality Process Architecture: Process-components encompassing activities, tasks, deliverables, and roles that make up a Quality Software Process
  4. Enacting the Quality Software Process: Quality process in practice; iterations, increments, and parallel development
  5. Estimates and Metrics for UML-Based Projects: Some suggestions on practical estimation of time, budgets, and people for UML-based projects
  6. Quality Control of Software Products: Detailed discussion on strategies for quality control and testing

Chapter 1: The Quality Game

In this background chapter on quality assurance we discuss the elusive nature of quality in the context of software. Modeling, particularly with the UML, is shown as a means to improve communication and quality and is conducted in the three distinct yet related modeling spaces of problem, solution, and background. We discuss process in the context of its three dimensions of technology (what), methodology (how), and sociology (who). This is followed by a 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. Chapter 1 also discusses the 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 of projects (small, medium, and large).

Chapter 2: Quality Environment: Managing the Quality Function

The process aspect of quality encompasses the management functions of creating and managing a quality environment. This is because software quality is not just about verifying and validating what has been produced; it's also about sustaining an effort to follow the discipline of producing models and software. This discipline encompasses the process or the steps involved to produce good models and good software. This part of the book comprehensively considers the organization and execution of the quality function, with a 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") are also given due relevance in Chapter 2.

Chapter 3: The Quality Process Architecture

This chapter discusses what constitutes such a process and how it is 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 its major dimensions. The technological dimension of a process deals 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 present in any process. These activities and tasks and their related roles and deliverables are described with the aim of improving the discipline in a process, resulting in the 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 the practical issues of configuring an Iterative, Incremental, and Parallel (IIP) project plan, based on the process-components discussed in the previous chapter. 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 facilitates better absorption of changes than a sequential project plan. The creation and management of such a changing plan, derived from the malleability aspect of the process, is also discussed. 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 to make 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 artifacts and diagrams are also discussed. Estimates for an 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: Quality Control of Software Products

This chapter discusses in detail the quality control and testing aspect of a quality lifecycle. While we discuss process quality in the previous chapters, quality control (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, and its performance. Thus, although quality control is an integral part of quality assurance, it is not synonymous with it. This separation is given its due importance in this separate part of the book.

CD-ROM and Potential Web Support

The CD-ROM contains details of the chapters, diagrams, and a set of templates (deliverables, project plan, and so forth) that can be customized for use in projects. Suggested metrics for improving quality (for example, size of use cases and effort in creating classes) are also incorporated on the CD-ROM. With permission, evaluation copies of relevant process tools that deal with quality process are also provided.

Semantics

I firmly believe in gender-neutral language. Person is therefore used wherever possible. However, in order to maintain reading simplicity 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 recognized 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.

Throughout the text, we primarily refers to the reader and the author--you and me. Occasionally, we refers to the general information technology (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. Among many presentations based on this book, particularly noteworthy are its acceptance as a tutorial at the UML 2001 Conference in Toronto, Canada, and the two-day seminar series3 in Mumbai, Bangalore, and Delhi, India. Many additional workshops and seminars are scheduled at the time of this writing. The following table is a generic outline of one day of a possible two-day workshop based on the topic of this book. For the education and academic community, each chapter in this book corresponds to a three-hour lecture topic, with the early part of the semester concentrating on creating the UML-based models based on the case study.

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 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 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
Revised, May 2002

0201758210P10022002

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)