Domain Knowledge Capture in the Software Process

1. Domain Knowledge Capture in the Software Process Chris Jensen Information and Computer Science University of California, Irvine cjensen@ics.uci.edu

2. Motivation • Identified as one of the most salient problem in terms of additional effort and mistakes - Curtis, Krasner, and Iscoe 1988 • “Writing code isn’t the problem. Understanding the problem is the problem.” • Only a few designers possessed enough relevant knowledge to have a significant effect on the design process • Reusability of Domain Knowledge • Decrease development lifecycle for similar systems/domains • Increase software quality through domain analysis • Requirements Tracability

3. Outline • What to capture? • How to capture it? • What to do with it?

4. What to Capture • Workflow (how) • Who are the stakeholders? • Stakeholder motivation • Authority/Knowledge structure • Communication/Collaboration • Relations with other organizations/markets • Inputs and Outputs of the target domain (what) • Government/Organizationally imposed Regulations • Physical constraints • Economic factors

5. What to Capture (cont.) • What level of the knowledge to capture? • Individual • Group • Project • Organization • Business Milieu

6. How to capture it • Formal Methods • Rapid Prototyping • The phoenix project • Participatory Design • The AI Approach • Communication Enabled Collaboration

7. Desiderata • Knowledge acquisition must not impose on or affect the domain it is modeling • Low cost (time, money, effort) while maintaining accuracy and usefulness of the model

8. Formal Methods • Possibilities: allow developers to analyze the domain, uncover inconsistencies, and derive additional information about the system via inferential operations • Formal Methods applicable to all phases of development • Problems: • Incompleteness, inaccuracy/mistranslation from informal specification, understandability • Though formal specifications eliminate ambiguity and inconsistency, they offer no assurance that a correctly specified problem will be the one the user needed solved – Gomaa and Scott • “The greatest benefit of applying a formal method often comes from the process of formalizing rather than the end result.” –Jeannette Wing

9. Rapid Prototyping • Inherently an iterative process • Previewing the expected system allows users to weigh implications of alterations which developers may learn from.

10. Rapid Prototyping (cont) • Techniques • Pen and paper • Requires little time, money, and effort, but does not map to actual implementation • Computer-based graphical tools • Provide a cleaner mockup and somewhat more realistic view of implementation (e.g. MS Paint, Adobe) • Visual Development Environments • Provide accurate representation but at a significant cost (e.g. VB, Visual Café RAD tools) • Prototyping Languages • Formal languages for specifying prototypes (e.g. PSDL)

11. The Phoenix Project • “Experience is the best teacher and she’s on the faculty at the school of hard knocks” • “Plan to throw one away. You will anyhow.” –Brooks, “The Mythical Man Month” • Ken Anderson: Brooks is essentially arguing for rapid prototypes (but doesn’t follow through)

12. Participatory Design • Methods • Observation and participation • Questionnaires and Follow ups • The CARD technique, TRILLIUM • Advantage: The client/users have a larger role in the development process (than other methods) • Direct information, rather than interpretation of indirect information • Disadvantage: cost, knowledge of client/users

13. The AI Approach • Agents • Use agents allow developers to record information on how a system is being used • This information is then stored in a knowledge base and may be incorporated into an expert system which developers may utilize in understanding the “problem” • Advantages: Understanding the work process, rather than what the client/user tells you is the process; small imposition on the client organization; small effort to gather data • Issues: conflict negotiation; reliability of “experts”/ patterns of use; payoff comes after the fact, privacy

14. Communication Enabled Collaboration • Idea: Record email, chat, and virtual meeting sessions among participants in the domain • Information may then be stored in knowledge bases for use by developers (e.g Mailman, Telenotes, Haystack) • Advantages: Grassroots support, cost, impact on work environment, scalability, resistance • Issues: privacy, information overload, verification

15. What to do with it • How to organize the information? • Domain Modeling • How to disseminate information among developers? • How to use the information to achieve increases in quality, usability, usefulness, and decrease development time?

16. Challenges • [CKI88]: danger in developing multiple similar projects: developing one system that meets 80% of each organizations’ needs vs. developing several systems that meet 100% of each organizations’ needs • Dynamic nature of domains • Representation and Utilization • Once knowledge is captured, how should it be modeled and used in development • Formal Languages? • Graphical/Diagrammatic approaches? • Cost of acquisition, distribution, and maintenance • Return on investment given programmer turnover

17. An example system for requirements acquisition • The Requirements Apprentice (Reubenstein and Waters) • Goal: Formalization of specification from informal requirements • Encode relevant domain knowledge from users into reusable “clichés,” sets of roles and constraints between them • Information is entered in Lisp-like syntax into the executive • Input is processed by the Cake, a knowledge representation and reasoning engine • Input is analyzed from its context in relation to associations in the cliché library to extract semantic information based on previous uses and the result is reported back to the (human) analyst for verification and translated into sets of implications • Implications are then stored in the Requirements Knowledge Base (RKB) and checked for consistency • Domain clichés are reused while the RKB stores requirements for a specific system.

18. References • Curtis, B., Krasner, H., and Iscoe, N. (1988), A field study of the software design process for large systems, Communications of the ACM, 31: 1268-1289. • Thomas and Wishbow. “Prototyping: Tools and Techniques- Improving Software and Documentation Quality through Rapid Prototyping,” Proceedings of theTenth International Conference of Systems Documentation: 191-199 • Luqi; Berzins, V.; Yeh, R. “A prototyping language for real-time software,” Software Engineering, IEEE Transactions on, Volume: 14 Issue: 10 , Oct. 1988: 1409 –1423 • Gomaa, Scott. “Prototyping as a tool in the Specification of Requirements,” IEEE Proceedings of the Fifth International Conference on Software Engineering: 333-342 • Jeannette Wing. “A Specifier’s Introduction to Formal Methods,” IEEE Computer, Sept 1993: 8-22

19. References (cont) • Adar, Karger, Stein. “Haystack: Per-User Information Environments,” Proceedings of the Eighth International Conference on Information Knowledge Management, pp. 413-422, 1999 • Whittaker, Swanson, Kucan, Sidner. “TeleNotes: Managing Lightweight Interactions in the Desktop,” ACM Transactions on Human-Computer Interaction, pp. 137-168, June 1997 • Mailman mailing list archive available at http://www.list.org/ • Reubenstein, Waters “The Requirements Apprentice: Automated Assistence for Requirements Acquisition,” IEEE Transactions on Software, March 1991: 226-240