The demand for quality in software engineering raises new challenges forsoftware engineers. The solutions proposed for the quality problem are basedon standards which provide an abstract frame and drive further tailoring andinstallation of quality control principles. These principles encompass arational design process supported by design rationales and defect prevention& immediate defect removal techniques. The present paper discusses somenew topics such as design rationale, CSCW, TQM and CASE, which asoftware engineer should master and applies these to a new type of review - acollaborative review.
INTRODUCTION
It is accepted that quality cannot be added to software but must be built into itstep by step. This means that we must focus on defect prevention andimmediate defect removal, i.e. place emphasis on the software engineer's ownevaluation during construction instead of an independent testing group. Whenwe characterize the new skills required of a software engineer (i.e. a softwarequality engineer), we find the pure software engineering research traditioninsufficient. We need a new foundation which encompasses informationsystems, software engineering, quality assurance and artificial intelligence.The specific research topics in these traditions are design rationale, CSCW(computer supported cooperative work), TQM (total quality management) andCASE (computer-aided software engineering).
Quality-driven assessment and collaborative review are quality controlactivities which make use of these research topics. They are also examples ofan individual assessment activity performed by the software quality engineer,
playing extra demands on his/her work. He/she should understand thedevelopment process and its continuous improvement and actively evaluatethe outcomes (i.e. descriptions at different levels of abstraction) and justify themajor design decisions. He/she should understand the groupwork nature ofsoftware development and be able to work together with other participants andto use advanced CASE tools. These tools enable engineers to work in parallelas much as possible, allow them to work together effectively in a distributedmeeting and allow them to use multimedia. In summary we can state that"although we cannot guarantee the quality, we can make the software engineerresponsible for it."
WHAT A SOFTWARE QUALITY ENGINEER SHOULD KNOW
When characterizing the role of a software quality engineer we can identifythree major research traditions which have a very heavy impact on it, namelyInformation Systems (IS), Software Engineering (SE) and Quality Assurance(QA). In addition, Artificial Intelligence (AI) provides some relatedtechniques and tools. In the Information Systems tradition we considerconceptual models, e.g. OCT (Organizational (O), Conceptual (C) andTechnical (T) [16], [17], which form a framework for a specific SoftwareEngineering methodology, which may be structured [38] or object-oriented[4], [5], [33], for example. The general OCT model is further applied to theobject-oriented approach by livari [18]. Software Configuration Management(SCM) is used to identify the configuration of the software, controllingchanges to this configuration and maintaining its integrity and traceabilitythroughout the software life cycle. Quality assurance (QA) forms a relevantresearch tradition which ties together the IS and SE approaches. In the QAtradition (e.g. the Software Quality Metrics (SQM) approach [1], [27]), qualitycharacteristics such as quality factors, criteria and checklists [10], [12] formthe cognitive framework which we use further in quality-driven assessment toevaluate the usefulness of the descriptions and to justify choices betweenalternative descriptions. These research traditions and some related topics aredescribed in Figure 1.
A design rationale provides us with more knowledge about the advantagesand disadvantages of a specific solution. It is an explanation of why an artifactis designed the way it is, and an early article of Freeman [13] explains howrecorded design rationales could improve design review. The Total QualityManagement (TQM) philosophy, proposed for continuous qualityimprovement, includes the Quality Function Deployment (QFD) technique,emphasizing the "voice of the customer" and translating high-level customerrequirements into low-level constraints that can be used to guide the designalternatives.
Information Systems (IS)- a conceptual modele.g. OCT
Software Engineering (SE)- a design methodologye.g. object-oriented-SCM
What a softwarequality engineershould know
Quality Assurance (QA)- a quality model (e.g. SQM)
Figure 1: Related research traditions for a software quality engineer
Due to the groupwork nature of software construction and review inparticular, Computer Supported Cooperative Work (CSCW) has many linkswith Software Engineering. Advances in the CSCW field also have impacts onaugmenting technology, e.g. augmenting reviews. The CSCW technology isexplained in four categories, communication mechanism, shared workspacefacilities, shared information facilities and group activity support facilities[43]. Concurrent Engineering (CE) follows the idea of CSCW andcollaborative review, especially meeting practices with the specified roles ofparticipants and their distribution between workstations. CASE tools aretypically appropriate for drawing, whereupon quality is limited to improveddocumentation and understandability. The continuous improvements made inthe CASE area now enable it to support integrated characteristics such asproject management and version management, but even these lack moreadvanced quality characteristics such as support for quality measurement anddecision making throughout the software development process.
NECESSARY RESEARCH TOPICS
We characterized above four research traditions and four research topics. Wenow specify the research topics further and deline related work in theseparticular areas.
Design rationalesA design rationale is an explanation of why an artifact is designed the way itis, and we can define it as a synonym for argumentation. This follows thecharacterization of design rationale presented by Carroll & Moran [3], who
justify an explicit design rationale on three grounds: (a) to support reasoningprocesses in design, (b) to facilitate communication among the variousparticipants in the design process (designers, implementers, maintainers,users, etc.), and (c) to further the accumulation and development of designknowledge across design projects and products.
The earliest model of argumentation used in design rationale systems isthe Toulmin schema [37], which looks at a single claim in isolation. Itsproblem is its inability to represent relationships between claims. A moreadvanced model is the IBIS (issue-based-information-system) methoddeveloped by Rittel [24], which includes a number of links between issues andsupports systematic documentation of the design rationale as a part of design.The origin of software design rationales can be traced to the article ofFreeman [13] in which he explains how recorded design rationales couldimprove design review. Some researchers (e.g. [8], [26], [29], [30]) havedeveloped this approach further, and some have experimented with it incertain environments. This wide field of application means that the emphasisof the term changes accordingly, knowledge-based design placing emphasison knowledge acquisition and the formalizing aspects of design whereasinformation systems design and software design place the weight of theirsupport on maintenance.
Total Quality ManagementAccording to the fifth level of Humphrey's [15] maturity model, qualityimprovement should be a continuous process ("Everyone is involved inimproving everything all the time" [42]). This philosophy is called TotalQuality Management (TQM) or Total Quality Control (TQC). TQM has beenpopularized through the influential works of Deming (cf. [6], [43]), and theconcept of TQC was originated by Feigenbaum [11], who defines it as "aneffective system for integrating the quality development, quality maintenance,and quality improvement efforts of the various groups in an organization so asto enable production and service at the most economical levels which allowfor full customer satisfaction." There are now two branches of TQC in use[19], the western-type TQC which emphasizes a well-organized managementfunction whose only area of operation is in quality control jobs, and theJapanese approach, "Company-wide TQC", which means that everyone inevery division in the company must study, practice and participate in qualitycontrol.
The TQM approach of Deming has met with impressive success in manycountries and many application areas. According to Zultner [44], it is not just"statistical process control", or a "manufacturing approach", but a"management approach for continuous improvement of quality" leading tohigher productivity and lower costs. In his recent article, Zultner [45]
characterizes the three major components of TQM in terms of (1) makingimprovements, (2) satisfying customers and (3) advancing the organization.
CASE tools
A problem arises with existing CASE (Computer Aided SoftwareEngineering) tools when the enterprise is not mature enough. Mosley [28] andHumphrey [39], for example, warn us against using CASE tools if we cannotmanage the development process. Jarke & Pohl [20] consider the usefulness ofquality-oriented CASE tools at different levels of maturity, and argue that"quality aspects are most strongly emphasized in the 'defined' level and itstransition to the 'managed' level". We agree with them on placing quality-oriented CASE tools in the maturity model, but we do not agree that weshould refrain from using CASE tools until the enterprise has reached the"repeatable" or "defined" level. Rather, we follow the ideas of Jorgensen [22]that "the CASE technology can accelerate the development process maturity",and those of Yourdon [40] that we should start by learning to use cheap CASEtools "because the anarchy within the organization precludes the consistent,rigorous use of more advanced features". We follow this suggestion ofYourdon, i.e. to start with cheap tools and proceed to more advanced ones.
The expectations of clients in the CASE area focus on improved qualityand maintainability (cf. [14], [25]), but a problem arises from the expectationsregarding improved quality, for example. Typically, CASE tools areappropriate for drawing, whereupon quality is limited to improveddocumentation and understandability. The best CASE tools include integratedcharacteristics such as project management and version management, but eventhese lack more advanced quality characteristics such as support for qualitymeasurement and decision making throughout the software developmentprocess. We focus in this paper on the support of quality-driven assessmentand collaborative reviews using design rationales. The support requires twoactivities: (1) defining and constructing design rationales, i.e. justifying thedesign decision in terms of tailored quality issues and (2) using designrationales, i.e. enabling software engineers to understand the material better inthe private review phase. These aspects will be relevant to future CASE tools,although low maturity causes some hindrances.
cscwComputer supported cooperative work (CSCW) is a blend of computerscience, information processing science and social science. This blend wascalled computer -based systems for group decision support in the early 1980s,and it was in the mid-eighties that a new paradigm, CSCW, began to emerge[23]. Following Kraemer & King [23], CSCW maintains that facilitating thetasks of group decision making is just one of the broader set of challengesinvolved in the use of computer technologies to facilitate cooperative work.CSCW is commonly considered to denote a new perspective on computer
system design and use - a perspective that asserts that we need to providecomputer support for work processes involving more than a single individual[32]. When we focus on communication, collaboration and coordination inparticular, we can use the term groupware, which Ellis et al.[9] define as:"computer-based systems that support groups of people engaged in a commontask (or goal) and that provide an interface to a shared environment". Schmidt[34] characterizes the groupwork in cooperative work as "mutuallydependent", i.e. the people engaged in cooperative work are mutuallydependent in their work.
Concurrent engineering (CE) is a similar principle to CSCW, and allowsdistributed meetings for decision making, for example. The meetings aredistributed geographically, and permit concurrent planning, i.e. effectivecollaboration among team members. Reddy et al. [31] define the CE conceptas "a systematic approach to integrated product development that emphasizesresponse to customer expectations and embodies team values of cooperation,trust and sharing."
Although CSCW is a very diverse and broad field, there are two distinctbut interrelated areas of concern: the group working process, and thetechnology that might be employed to support it [43]. The group work processand other human-oriented aspects central to the problem of improving groupefficiency embrace (1) individual human characteristics, e.g. conversationpatterns and the way humans make commitments, (2) organizational aspects,e.g. the structure and culture of organizations, (3) group work design issues,e.g. user involvement in the work design process, prototyping and usabilitytesting, and (4) group dynamics aspects, e.g. group decision making and theway humans collaborate with each other. The CSCW technology is furtherclassified into four categories [43]: communication mechanism, sharedworkspace facilities, shared information facilities and group activity supportfacilities.
Advances in the CSCW field have indirect and direct impacts on thequality control issues focused on in this paper. The indirect impacts comefrom the IBIS (Issue Based Information Systems) method of Rittel [24], whichhas nodes of three types (issues, positions and arguments) and uses relationsof nine types to link these nodes. In a typical application, someone posits anissue, then that person or others establish positions regarding that issue, andthen the positions are argued using an argument node.
COLLABORATIVE REVIEWS
Collaborative review, augmented by means of design rationales, is a potentialactivity in which a software quality engineer needs special skills. These skillsare based on knowledge of conventional inspections and reviews, design
rationales, groupwork (i.e. collaboration, communication and coordination),geographical distribution and justification. We can characterize these links bymeans of threads from the research traditions to the notion of collaborativereview, as depicted in Figure 2.
Figure 2: Deriving collaborative review from existing research traditions
Our specific interest is focused on quality-driven assessment (referred toearlier as quality-driven validation term, cf. [35], [36]) and its impact oncollaborative review. The core implementations of collaborative inspectionsand reviews are examples of direct impacts of CSCW, whereas quality-drivenassessment places emphasis on justification and design rationale. Distributionbetween workstations is a specific characteristic derived from the CSCWprinciple, although it inherits major characteristics from inspections andvarious types of walkthrough. The main objective of justification isexplanation of the design process, i.e. design decisions enhanced with designrationales explain more than do pure descriptions.
The phases in a hypothetical collaborative review, following theCollaborative Software Review System (CSRS) of Johnson & Tjahjono [21],comprise (1) orientation, (2) private review, (3) public review, (4)consolidation, (5) group review and (6) reworking. The orientation phaseprepares the participants for the private reviews, in which they inspect thesoftware objects privately, mark them as reviewed and generate new issues,
i.e. problems or defects concerned with the software. The review leadermonitors the private review process, and if new issues arise, the processproceeds to a public review, in which the participants react to all the issuesand the reviewers can also create new issues and links between them. Finally,the reviewers indicate their agreement about the existing actions by voting. Atthe consolidation phase the review leader creates a consolidated representationof the state of the review, and if controversy is evedent a group meeting maybe called. This entails a group review in which the group may vote aboutunresolved issues which can lead to reworking, or else the review leader maydecide on some reworking or simply conclude the review. We next introducethree additional tools for distributed, collaborative reviews and inspections,and then discuss how to augment them by means of design rationales.
CSI (Collaborative Software Inspector), ICICLE (Intelligent CodeInspection Environment in a C Language Environment) and CSRS(Collaborative Software Review System) are three experiments with advancedQA tools for augmenting collaborative reviews and inspections. The Flecse(Flexible Environment for Collaborative Software Engineering) is a newmultimedia environment [7], which features tools designed to surmount thecollaboration problems that software engineers are increasingly encountering.The various Flecse tools include a distributed version control tool, aconcurrent debugging tool, an inspection tool and a multiuser program editor.The inspector component of Flecse, called CSI (Collaborative SoftwareInspector) is interesting from the concurrent review viewpoint in particular, asit covers many augmenting characteristics and supports concurrent softwareengineering in three ways: (1) it enables engineers to work in parallel as muchas possible, (2) it lets engineers work together effectively in a distributedmeeting, and (3) it allows the use of multimedia.
ICICLE (Intelligent Code Inspection Environment in a C LanguageEnvironment) is a tool intended to augment the process of formal codeinspection [2]. The code to be inspected is presented in a "code window", andthe reader guides the inspectors through the module being analyzed. As thereader scrolls from place to place or views different files, all the inspectors'code windows move with that of the reader. The inspectors can also split thewindow in two and scroll the second window freely, independent of thereader. The inspectors comment or give annotations to this code by means of a"comment window". When an inspector proposes a comment, a small windowwith the text of the comment pops up on every inpector's screen and theinspectors may discuss the validity of the comment just as in any inspectionmeeting. Finally the scribe accepts or rejects the comment on the basis of thediscussion.
In CSRS (Collaborative Software Review System [21]), each programobject, such as a function, procedure, macro, variable or data type declaration,
is retrieved from the source code and placed at a node of its own in ahypertext-style database. The data model of the CSRS comprises nodes suchas source node, issue node, action node, comment node, evidence node,consolidated issue node and consolidated action node. The review participantsfirst individually review the source code and document any suspectedproblems or defects in issue nodes. Any question concerning the source is alsorecorded in comment nodes. The action nodes represent solutions to theproblems in issue nodes. Because private review leads to redundant issues,they must be summarized into a single consolidated issue, and related actionsinto a consolidated action. Actual reworking activities are based on a singleconsolidated action. The benefits of CSRS can be summarized under threepoints: (1) it results in a richly linked repository for all review artifacts andthus facilitates reworking, project scheduling and access todesign/maintenance rationales, (2) it reduces dependence on traditional reviewmethods as used in same-time, same-place group work, and (3) it providesautomated support for the roles of producer, review leader and reviewer.
Our own contribution in this area is based on earlier experiments withquality-driven validation, which makes active use of software quality factorsand criteria for the validation and justification of software [35]. Designrationales are derived from quality issues by breaking down quality factorsinto criteria and using their quality estimates to derive a quality estimate foreach factor. We can use the definition, checklist or estimated quality value ofeach criterion, or the designer's own opinion, as a design rationale at thecriterion level to characterize the "value" of the specific criterion. If we usethe quality factors Reusability, Usability and Expandability, for example, thenExpandability can be broken down into criteria such as Conciseness,Readability and Upgradeability, and the object-oriented, tailored definition forConciseness is "The degree to which existing subclasses with methods areutilized in present development". We can now justify the solution by means ofConciseness criteria and some extra, case-specific statements. Thesestatements are "the designer's own opinions" and are connected here with theConciseness criteria. The main objective of this kind of justification is toexplain the design decisions and record the design rationales in connectionwith software descriptions. This is extremely important in the private reviewphase of a collaborative review, for example.
CONCLUSIONS
The primary contribution of this paper is to introduce a collaborative reviewmethod and to discuss the new challenges posed for software engineers. Thesolution proposed here is based on quality control principles which encompassa rational design prosess supported by design rationales and and defectremoval techniques. When we characterize the new skills required of asoftware engineer (i.e. a software quality engineer), we find the pure software
engineering research tradition insufficient. Thus we are led to introduce a newfoundation which encompasses information systems, software engineering,quality assurance and artificial intelligence. The specific research topics inthese traditions are design rationale, CSCW, TQM and CASE .
Our specific interest is focused on quality-driven assessment and itsimpact on collaborative reviews. The core characteristics of a collaborativereview are derived from the QA tradition, the distribution betweenworkstations from the CSCW tradition, and the notion of justification anddesign rationale from the quality-driven assessment principle. Collaborativereview, augmented by means of design rationales, is a potential activity inwhich a software quality engineer needs special skills such as (1) anunderstanding of the development process and its continuous improvement,(2) active evaluation of outcomes (i.e. descriptions at different levels ofabstraction) and justification of major design decisions, (3) ability to worktogether with other participants, and (4) ability to use advanced CASE tools.These tools enable software quality engineers to work in parallel as much aspossible and to work together effectively in a distributed meeting.
REFERENCES
1. Boehm B.W., Brown T.R., Kasper H., Lipow M., Macleod G.J. andMerritt M.J, Characteristics of Software Quality, North-Holland, 1978
2. Brothers L., Sembugamoorthy V., and Muller M., ICICLE: Groupwarefor Code Inspection, in Proceedings of the CSCW'90, ACM Press, 1990, pp.169-181
3. Carroll J.M., and Moran T.P., Introduction to This Special Issue onDesign Rationale, Human-Computer Interaction, vol 6, no 3&4, 1991, pp.197-200
4. Coad P., and Yourdon E., Object-Oriented Analysis, Second Edition,Prentice Hall, Englewood Cliffs, NJ , 1991
5. Coad P., and Yourdon E., Object-Oriented Design, Prentice Hall,Englewood Cliffs, NJ, 1991
6. Deming W.E., Out of the Crisis: Quality, Productivity and CompetitivePosition, MIT Center for Advanced Engineering Study, Cambridge, Mass.,1986
7. Dewan P., and Riedl J., Toward Computer-Supported ConcurrentSoftware Engineering, IEEE Computer, vol 26, no 1, 1993, pp. 17-27
8. Dhar V., and Jarke M., Using Teleological Design Knowledge for LargeSystems Development and Maintenance, in Proceedings of the 6th Int.
Workshop on Expert Systems and Their Applications, Avignon, 1986, pp. 359-3oo
9. Ellis C.A., Gibbs S.J., and Rein G.L., Groupware: Some Issues andExperiences, Communication of the ACM, vol 34, no 1, 1991, pp. 38-58
10. Pagan M.E., Design and Code Inspections to Reduce Errors in ProgramDevelopment, IBM Systems Journal vol 15, no 3, 1976, pp. 182-211
11. Feigenbaum, A., Total Quality Control, 3rd Edition, McGraw-Hill BookCo., Singapore, 1991
12. Freedman D.P., and Weinberg G.M., Handbooks of Walkthroughs,Inspections, and Technical Reviews: evaluating programs, projects, andproducts, Third edition, Little, Brown and Company (Inc.), Boston, 1982
13. Freeman P., Toward Improved Review of Software Designs, inProceedings of the National Computer Conference, 1975, pp. 329-334
14. Herbert M., Evaluating the Effects of CASE on Software Development: ASurvey, Software Engineering, Tools, Techniques, Practice, vol 3, no 1, 1992,pp. 5-16
15. Humphrey W.S., Managing the Software Process, Addison-Wesley,Reading, Mass., 1989
16. livari J., Hierarchical Spiral Model for Information System and SoftwareDevelopment. Part 1: theoretical background, Information and SoftwareTechnology, vol 32, no 6, 1990, pp. 386-399
17. livari J., Hierarchical Spiral Model for Information System and SoftwareDevelopment. Part 2: design process, Information and Software Technology,vol 32, no 7, 1990, pp. 450-458
18. livari J., Object-Oriented Information Systems Analysis, A Frameworkfor Object Identification, in Proceedings of the 24th HICSS Conference, vol H,IEEE Computer Society Press, 1991, pp. 205-218
19. Ishikawa K., What Is Total Quality Control? The Japanese Way, PrenticeHall, Englewood Cliffs, NJ, 1985
20. Jarke M., and Pohl K., Information Systems Quality and QualityInformation Systems, in (Ed., Kendall K.E. et al.) The Impact of ComputerSupported Technologies on Information Systems Development, ElseviewScience Publishers, 1992, pp. 345-375
21. Johnson P.M., and Tjahjono D., Improving Software Quality throughComputer Supported Collaborative Review, in (Ed. De Michelis G., SimoneC., and Schmidt K.,), Proceedings of the Third European Conference onComputer Supported Cooperative Work, Milan, Italy, 1993, pp. 61-76
22. Jorgensen P.C., Accelerating Process Maturity with CASE, AmericanProgrammer, vol 3, no 9, 1990, pp. 10-15
23. Kraemer K.L., and King J.L., Computer-Based Systems for CooperativeWork and Group Decision Making, ACM Computing Surveys, vol 20, no 2,1988, pp. 115-146
24. Kunz W., and Rittel H.W.J., Issues as Elements of Information Systems,Working Paper 131, Center for Planning and Development Research,University of California, 1970
25. Kusters R.J., and Wijers G.M., On the Practical Use of CASE-ToolsResults of a Survey, in CASE'93, Proceedings of the 6th InternationalWorkshop on CASE, Singapore, IEEE Computer Society Press, 1993, pp. 2-10
26. Lee J., Extending the Potts and Bruns model for recording DesignRatioanle, in Proceedings of the 13th International Conference on SoftwareEngineering Conference, IEEE Computer Society Press, 1991, pp. 114-125
27. McCall J.A, Richards P.K, and Walters G.F., Factors in Software Quality,Volumes I, H, and HI, RADC reports, 1977
28. Mosley D.: Are We Ready for CASE, American Programmer, vol 2, no 3,1989, pp. 20-25
29. Mostow J., Toward Better Models of The Design Process, The AIMagazine, Spring, 1985, pp. 44-56
30. Potts C, and Bruns G., Recording the Reasons for Design Decisions, inProceedings of the 10th International Conference on Software EngineeringConference, IEEE Computer Society Press, 1988, pp. 418-427
31. Reddy Y.V.R., Srinivas K., Jagannathan V., and Karinthi R., ComputerSupport for Concurrent Engineering, IEEE Computer, vol 26, no 1, 1993, pp.13-15
32. Rein G.L., Singh B., and Knutson J., The Grand Challenge: BuildingEvolutionary Technologies, in Proceedings of the 26th HICSS Conference, volIV, IEEE Computer Society Press, 1993, pp. 23-31
33. Rumbaugh J., Blaha M., Premerlani W., Eddy F., and Lorensen W.,Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ,1991
34. Schmidt K., Riding a Tiger, or Computer Supported Cooperative Work, in(Ed. Bannon L., Robinson M., and Schmidt K.), Proceedings of the SecondEuropean Conference on Computer-Supported Cooperative Work, KluwerAcademic Publishers, Amsterdam, 1991, pp. 1-16
35. Tervonen I., Quality Derivation, Refinement and Generalization inObject-Oriented Software Construction, in Proceedings of the 26th HICSSConference, vol IV, IEEE Computer Society Press, 1993, pp. 777-786
36. Tervonen I., Towards Quality-Oriented CASE Tools, in CASE'93,Proceedings of the 6th International Workshop on CASE, Singapore, IEEEComputer Society Press, 1993, pp. 18-28
