词条 | Design rationale |
释义 |
A design rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to the political, collaborative process of addressing wicked problems.[1] OverviewA design rationale is the explicit listing of decisions made during a design process, and the reasons why those decisions were made.[1] Its primary goal is to support designers by providing a means to record and communicate the argumentation and reasoning behind the design process.[2] It should therefore include:[3]
Several science areas are involved in the study of design rationales, such as computer science[1] cognitive science,[2] artificial intelligence,[4] and knowledge management.[5] For supporting design rationale, various frameworks have been proposed, such as QOC, DRCS, IBIS, and DRL. HistoryWhile argumentation formats can be traced back to Stephen Toulmin's work in the 1950s[6] datums, claims, warrants, backings and rebuttals, the origin of design rationale can be traced back to W.R. Kunz and Horst Rittel's[7] development of the Issue-Based Information System (IBIS) notation in 1970. Several variants on IBIS have since been proposed.
The first Rationale Management System (RMS) was PROTOCOL, which supported PHI, which was followed by other PHI-based systems MIKROPOLIS and PHIDIAS. The first system providing IBIS support was Hans Dehlinger's STIEC.[15] Rittel developed a small system in 1983 (also not published) and the better known gIBIS (graphical IBIS) was developed in 1987.[16] Not all successful DR approaches involve structured argumentation. For example, Carroll and Rosson's Scenario-Claims Analysis approach[17] captures rationale in scenarios that describe how the system is used and how well the system features support the user goals. Carroll and Rosson's approach to design rationale is intended to help designers of computer software and hardware identify underlying design tradeoffs and make inferences about the impact of potential design interventions.[18] Key concepts in design rationaleThere are a number of ways to characterize DR approaches. Some key distinguishing features are how it is captured, how it is represented, and how it can be used. Rationale captureRationale capture is the process of acquiring rationale information to a rationale management
Rationale representationThe choice of design rationale representation is very important to make sure that the rationales we capture is what we desire and we can use efficiently. According to the degree of formality, the approaches that are used to represent design rationale can be divided into three main categories: informal, semiformal, or formal.[3] In the informal representation, rationales can be recorded and captured by just using our traditionally accepted methods and media, such as word processors, audio and video records or even hand writings. However, these descriptions make it hard for automatic interpretation or other computer-based supports. In the formal representation, the rationale must be collected under a strict format so that the rationale can be interpreted and understood by computers. However, due to the strict format of rationale defined by formal representations, the contents can hardly be understood by human being and the process of capturing design rationale will require more efforts to finish, and therefore becomes more intrusive. Semiformal representations try to combine the advantages of informal and formal representations. On one hand, the information captured should be able to be processed by computers so that more computer based support can be provided. On the other hand, the procedure and method used to capture information of design rationale should not be very intrusive. In the system with a semiformal representation, the information expected is suggested and the users can capture rationale by following the instructions to either fill out the attributes according to some templates or just type into natural language descriptions.[3] Argumentation-based models
One advantage of Toulmin model is that it uses words and concepts which can be easily understood by most people.
In the WinWin Spiral Model, the goals of each stakeholder are defined as Win conditions. Once there is a conflict between win conditions, it is captured as an Issue. Then the stakeholders invent Options and explore trade-offs to resolve the issue. When the issue is solved, an Agreement which satisfies the win conditions of stakeholders and captures the agreed option is achieved. Design rationale behind the decisions is captured during the process of the WinWin model and will be used by stakeholders and the designers to improve their later decision making.[28] The WinWin Spiral model reduces the overheads of the capture of design rationale by providing stakeholders a well-defined process to negotiate. In[30] an ontology of decision rationale is defined and their model utilizes the ontology to address the problem of supporting decision maintenance in the WinWin collaboration framework.
ApplicationsDesign rationale has the potential to be used in many different ways. One set of uses, defined by Burge and Brown (1998),[19] are:
DR is used by research communities in software engineering, mechanical design, artificial intelligence, civil engineering, and human-computer interaction research. In software engineering, it could be used to support the designers ideas during requirement analysis, capturing and documenting design meetings and predicting possible issues due to new design approach.[31] In software architecture and outcourcing solution design, it can justify the outcome of architectural decisions and serve as a design guide.[32] In civil engineering, it helps to coordinate the variety of work that the designers do at the same time in different areas of a construction project. It also help the designers to understand and respect each other's ideas and resolve any possible issues.[33] The DR can also be used by the project managers to maintain their project plan and the project status up to date. Also, the project team members who missed a design meeting can refer back the DR to learn what was discussed on a particular topic. The unresolved issues captured in DR could be used to organize further meetings on those topics.[31] Design rationale helps the designers to avoid the same mistakes made in the previous design. This can also be helpful to avoid duplication of work.[4] In some cases DR could save time and money when a software system is upgraded from its previous versions.[1] There are several books and articles that provide excellent surveys of rationale approaches applied to HCI,[34] Engineering Design[3] and Software Engineering.[35] See also
References1. ^1 2 Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M. (1992), "Design Rationale for Software Engineering: A Survey", 25th Hawaii International Conference on System Sciences, 2, pp. 577-586 2. ^1 Horner, J.; Atwood, M.E. (2006), "Effective Design Rationale: Understanding the Barriers", in Dutoit, A.H.; McCall, R.; Mistrík, I. et al., Rationale Management in Software Engineering, Springer Berlin Heidelberg, pp. 73-90 3. ^1 2 3 4 5 6 7 8 Lee, J. (1997). "Design Rationale Systems: Understanding the Issues". IEEE Expert 12 (3): 78–85 4. ^1 2 3 Burge, J.E.; Brown, D.C. (2000), "Reasoning with Design Rationale", in Gero, J., Artificial Intelligence in Design '00, Netherlands: Kluwer Academic Publ., pp. 611–629 5. ^Xin, W.; Guangleng, X. (2001), "Design Rationale as Part of Corporate Technical Memory", Systems, Man and Cybernetics, pp. 1904 - 1908. 6. ^1 Stephen Toulmin (1958). The Uses of Argument. Cambridge: Cambridge University Press. 7. ^1 2 Kunz, W.; Rittel, H. (1970), Issues as elements of information systems. Working Paper 131, Center for Urban and Regional Development, University of California Berkeley 8. ^McCall, R. (1978), On the structure and use of issue systems in design, Doctoral Dissertation, University of California, Berkeley, University Microfilms 9. ^1 Potts, C.; Burns, G. (1988), "Recording the reasons for design decisions", 10th International Conference on Software Engineering (ICSE '1988), pp. 418-427 10. ^Lee, J. (1991), "Extending the Potts and Bruns model for recording design rationale", Proceedings of the 13th International Conference on Software Engineering (ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, pp. 114-125 11. ^Maclean, A.; Young, RM.; Moran, T. (1989), "Design rationale: the argument behind the artifact", SIGCHI Bull. 20, pp. 247-252114-125 12. ^Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Questions, Options, and Criteria: Elements of Design Space Analysis", in Moran, T.; Carroll, J., Design Rationale Concepts, Techniques, and Use, Lawrence Erlbaum Associates, pp. 53-106 13. ^Barry Boehm, Ross, R (1989). "Theory-W software project management: principles and examples.". IEEE Transactions on Software Engineering 18 (7): 902-916. 14. ^1 Pena-Mora, F.; Sriram, D.; Logcher, R. (1993), "SHARED-DRIMS: SHARED Design Recommendation-Intent Management System", Proceedings Enabling Technologies Infrastructure for Collaborative Enterprise, IEEE Press, Morgantown, WV, pp. 213-221 15. ^Dehlinger, H. (1978), Project STIEC: Systems Analysis of the Generation and Dissemination of Scientific and Technological Information in the European Community" Report No. 26: Report on a Batch - Version of STIEC, Heidelberg/Stuttgart 16. ^Conklin, J.; YakemBegemanovic, M. (1988). "gIBIS: A hypertext tool for exploratory policy discussion". ACM Transactions on Office Information Systems 6 (4): 303-331. 17. ^Carroll, JM; Rosson, M (1992). "Getting around the task-artifact cycle: how to make claims and design by scenario". ACM Trans. Inf. Syst. 10 (2): 181-212 18. ^Carroll, J. M., & Rosson, M. B. (2003). Design rationale as theory. HCI models, theories, and frameworks: toward a multidisciplinary science, 431-461. 19. ^1 2 Burge, J.; Brown, D.C. (1998), Design Rationale: Types and Tools, Technical Report, Worchester Polytechnic Institute, Computer Science Dept., retrieved on 27 April 2007 20. ^Chen, A.; McGinnis, B.; Ullman, D.; Dietterich, T. (1990), "Design History Knowledge Representation and Its Basic Computer Implementation", The 2nd International Conference on Design Theory and Methodology, Chicago, IL, pp. 175-185 21. ^Reynolds, Chris (2000), What is the Toulmin Model? Paper at concentric.net. 22. ^Conklin, J.; Yakemovic, K. (1991). "A Process-Oriented Approach to Design Rationale". Human-Computer Interaction 6 (3 & 4): 357–391. 23. ^{{cite techreport |last1=Rittel |first1=Horst W. J. |authorlink1=Horst Rittel |last2=Noble |first2=Douglas |date=January 1989 |title=Issue-based information systems for design |number=492 |location=Berkeley, CA |institution=Institute of Urban and Regional Development, University of California |oclc=20155825 |url=http://cumincad.architexturez.net/system/files/pdf/ca71.content.pdf}} 24. ^McCall, R.J. (1991). "PHI: A Conceptual Foundation for Design Hypermedia". Design Studies 12 (1): 30–41. 25. ^Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Questions, Options, and Criteria: Elements of Design Space Analysis", in Moran, T.; Carroll, J., Design Rationale Concepts, Techniques, and Use, Lawrence Erlbaum Associates, pp. 53-106 26. ^1 Lee, J. (1991), "Extending the Potts and Bruns model for recording design rationale", Proceedings of the 13th International Conference on Software Engineering (ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, pp. 114-125 27. ^Burge, J. (2005), Software Engineering Using design RATionale, Worchester Polytechnic Institute, Computer Science Dept 28. ^1 Barry Boehm; Kitapci, H. (2006), "The WinWin Approach: Using a Requirement Negotiation Tool for Rationale Capture and Use", in Dutoit, A.H.; McCall, R.; Mistrík, I. et al., Rationale Management in Software Engineering, Springer Berlin Heidelberg, pp. 173-190 29. ^Barry Boehm (1998). "A spiral model of software development and enhancement". Computer 21 (5): 61–72 30. ^Bose, P. (1995). "A Model for Decision Maintenance in the WinWin Collaboration Framework". Knowledge Based Software Engineering (KBSE '95). 31. ^1 Dutoit, A.; McCall, B.; Mistrik et al., eds. (2006), Rationale Management in Software Engineering, Springer pp.1-48. 32. ^O. Zimmermann, C. Miksovic, J. Küster, Reference Architecture, Metamodel and Modeling Principles for Architectural Knowledge Management in Information Technology Services. Journal of Systems and Software, Elsevier. Vol. 85, Issue 9, Sept. 2012 33. ^Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) Application Of Design Rationale Systems To Project Definition – Establishing A Research Project. Retrieved on 27 April 2007 34. ^Moran, T.; Carroll, J., eds. (1996), Design Rationale Concepts, Techniques, and Use, Lawrence Erlbaum Associates, 35. ^Dutoit, Rationale Management in Software Engineering Further reading
External links
4 : Argument mapping|Design|Justification|Software design |
随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识,基本涵盖了大多数领域的百科知识,是一部内容自由、开放的电子版国际百科全书。