Embed Size (px)
DESCRIPTION
Current requirements engineering practices for gathering user input are characterized by a number of communication gaps between users and engineers which might lead to wrong requirements. The problem situations and context which underlie user input are either gathered back in time, or submitted with wrong a level of details. We think that making user input a first order concern of both software processes and software systems harbours many innovation opportunities. We propose and discuss a continuous and context-aware approach for communicating user input to engineering teams and other users, by a) instrumenting the problem domain, b) proactively recommending to share feedback and c) annotating graphical interfaces.
Citation preview
When Users Become Collaborators: Towards Continuous and Context-Aware User Input
Walid Maalej (TU München)Hans-Jörg Happel, Asarnusch Rashid (FZI Karlsruhe)
OOPSLA Onward! Orlando, FL, October 29th, 2009
Motivation
A Benchmarking
A New Approach
Technical Enablers
Next Steps
Outline
2
Reasons for project failure
Incomplete Requirements
No customer requirements
Lack of resources
Unrealistic expectations
Uncontrolled changes of
requirements
User involvement is critical for the success of software development projects
13%
12%
11%
10%
9%
Reasons for project success
Customer/User involvement
Ex. Management support
Clear Statement of
requirements
Proper planning
Realistic expectations
16%
14%
13%
10%
8%
[Standish Group 2003, recent studies with similar results] 3
Various concepts to address end users in software development
4
Motivation
A Benchmarking
A New Approach
Technical Enablers
Next Steps
Outline
5
Various types of user input
??Perpetual Beta
Legacy Documents
Usage Data
Implicit Explicit
Pull
PushIssue and Bug Report
Enhancement Request
Feature Request
Workshop
Interview, Survey
Clarification Request
Field Observation
Lead Users
(Not used in SE)
Communication
Feed
back
6
Various realizations of user input
7
Mysterious stack traces
8
Bug reports from within a program
9
Application usage data
10
Discussions in user communities
11
Various realizations of user input
…but most applications stilldo not consider feedback at all…
12
• Gaps through fragmented streams of user interaction – feedback cross-cuts proceses
• User input difficult to understand
• No frameworks for systematic integration into application
• Gaps through fragmented streams of user interaction – feedback cross-cuts proceses
• User input difficult to understand
• No frameworks for systematic integration into application
Problems of the status quo
13
How can we make user Input as a first-orderconcern in both processes and architectures?
For EngineersFor Engineers For UsersFor Users
User input is usually…•Tedious to provide (e.g. writing detailed context information)
• Incomplete or imprecise• Focussed on one particular
step (e.g. bug reporting)• Uni-directional and singular
User input is usually…•Tedious to provide (e.g. writing detailed context information)
• Incomplete or imprecise• Focussed on one particular
step (e.g. bug reporting)• Uni-directional and singular
Streams of interaction
14
RequirementsRequirements
EngineersEngineers UsersUsers
RealizationRealization
ProvisionProvision DeploymentDeployment
ProblemProblem
UsageUsageEvolutionEvolution
FixFix
QuestionQuestionSupportSupport
Motivation
A Benchmarking
A New Approach
Technical Enablers
Next Steps
Outline
15
A Continuous Feedback Model
Prospectiv
e
Observatio
n
Assisted Feedback
Improvement
Decision
Back-Feedback
System
atic
An
alysis
Application
User
Engineering Team
Development Infrastructure
Community
Sharing
16
Motivation
A Benchmarking
A New Approach
Technical Enablers
Next Steps
Outline
17
Technical building blocks
Makinguser input a
1st order concern
Visual Annotation
Recommend end user to share their experience with engineering
teams end other end users
Observation & Context Elicitation
Allow user to annotate and „paint“ on the GUI
in the work context
Proactive Assistance
Detect user intention and problem situations through observation of user and application
18
TeamWeaver Context Framework
problem problem problem problem
ExecutionOntology
Interaction Ontoloy
Feedback Reporting Interface
OS sensors
User Profile
Elicitation
Problem Problem
events
update
trigger
Application sensors
Execution Env. sensors
Additional feedback
interact
Session-ization
Context Observer
http://www.teamweaver.org 19
Visual Annotation with OpenProposal
End user applicationEnd user application OpenProposalOpenProposal
plus Username, Application, Version, Date, etc.
Issue Tracker
Issue Tracker
20http://www.openproposal.de
Inverse Search to recommend usersto share their experience
Conventional recommendation systems:
1. Match interests of users against a given set of information
2. Push information to the user Users providing information are not part of
this model although they are potential sources for additional information
Recommendation using inverse search:
3. Matches the private/local information of users (information providers) against a given set of needs
4. Identify information (e.g. experiences and interactions) worth sharing
User Information Provider
Experiences
Needs 3. iSearch3. iSearch
4. Share4. Share
1. Query1. Query
2. Results2. Results
21
Engineer / User Information Seeker
Motivation
A Benchmarking
A New Approach
Technical Enablers
Next Steps
Outline
22
Conclusion
• Feasability– Technical building blocks are there– Further technologies to enable tighter collaboration between users
and developers emerge (e.g. Microblogging)– Communication and transparency in Open Source projects– Several services on the web decide on realization options based on
implicit feedback– Users are motivated by feedback
• Challenges– Privacy– Development culture– Non-intrusiveness– Context-similarity
23
Summary
• Results– Comparing different types of user input– Identification of technology and process enablers
for feedback-driven development
• User input deserves to become a first order concern in development processes and architectures– How can users become prosumers instead of
mere consumers of applications?– How to give engineering teams more
continuous, direct and rich input for development?
• Tools– www.teamweaver.org– www.openproposal.de
24
References
• Walid Maalej and Hans-Joerg Happel: A Lightweight Approach for Knowledge Sharing in Distributed Software Teams. In Proceeedings of the 7th International Conference on Practical Aspects of Knowledge Management (PAKM2008).
• Happel, H.-J. and Maalej, W.: Potentials and Challenges of Recommendation Systems for Software Development. In Proceedings of the International Workshop on Recommendation Systems for Software Engineering (RSSE 2008).
• Rashid, A., Wiesenberger, J., Meder, D. Baumann , J.: Bringing Developers and Users closer together: The OpenProposal story. In: Multikonferenz Wirtschaftsinformatik 2008 (MKWI 2008), 26.2. - 28.2.2008, München.
• Standish Group: The 2003 CHAOS Chronicles report.• Walid Maalej: Task-First or Context-First? Tool Integration Revisited. In: 24th
IEEE/ACM International conference on Automated Software Engineering (ASE 2009) Auckland, New Zealand. 16th-20th November 2009.
25
