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_at_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 isnt 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 shes 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 doesnt 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 Specifiers 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