Process Quality Assurance for Uml-Based Projects

• Authors: Bhuvan Unhelkar
• Venue: Process Quality Assurance for Uml-Based Projects
• Year: 2002

From the Book:Purpose of this BookThe 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 usedin 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 productWhen 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 verificat 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 BookThis book is divided into 6 chapters as summarized below. Chapter 1: The Quality GameIn 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 functionProcess 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 ArchitectureThis 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 ProcessIn 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 ProjectsThis 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 productThis 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 SupportThe 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 AudienceThere 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.SemanticsThis 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 WorkshopThe '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. AcknowledgementsEncouragement 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 BatesPaul BeckerChristopher BiltoftBhargav BhattGraham ChurchleyKamlesh ChaudharySandra CormackJoanne CurrySanjeev DandekarEdward D'SouzaCon DiMeglio Julian EdwardsNandu Gangal Athula GinigeDavid Glanville Mark GliksonNitin GuptaBrian Henderson-Sellers Murray HekeIvar JacobsonSudhir Joshi Ashish KumarVijay KhandelwalAkshay KriplaniYi-chen LanChinar & Girish MamdapurJaved MatinSid Mishra Rahul Mohod Navyug MohnotNarayana MunagalaKarin OvariLes ParcellChris PayneAndrew PowellAbhay PradhanAmit PradhanAnand PradhanPrabhat PradhanRajesh PradhanTim RedrupTracey Reeve Prashant Risbud James RossMagdy SerourBran Selic Ashish ShahParesh ShahPrince & Nithya Soundararajan Pinku TalatiAmit TiwaryMurat TanikAsha UnhelkarSunil VadnerkarSuresh VelgapudiJohn WarnerHouman YounessiPaul 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.CritiquesIt 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 UnhelkarSydney, July 2001