When Users Becom Collaborators: Towards Continuous and Context-Aware User Input

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    fast development cycles/reduce time-to implementation There are many studies, proving that the biggest problems in software projects lie in the requirement analysis, the first stage of every software project. The interviewed experts in the study of the Standish Group have the opinion that insufficient requirements are the biggest problem and that the involvement of customer and user is very important. This study was performed again in the last years and the results didn’t changed significantly.

    "Perpetual beta" "Perpetual beta" "Perpetual beta" "Perpetual beta" "Perpetual beta" "Agile development" "Agile development" "Agile development" "User innovation" "User innovation" Prototyping Prototyping Prototyping Feedback Feedback Feedback Feedback Feedback Feedback Feedback "Continuous improvement" "Continuous improvement" "Continuous improvement" "End-user development" "End-user development" "End-user development" "End-user development" "Usability Engineering" "Usability Engineering" "User Experience" "Participatory Design" "Participatory Design" "Participatory Design" "User-Centered Design" Mockup Continuous process improvement Continuous process improvement Continuous process improvementv

    lead users adjust by themselves

    Horizontal (user/dev) and vertical (iterations) gaps + user2user gap * Gap ** Actual distribution ** Media switches when sending requests (vs. feedback channels) ** Community interaction ** Difficult to monitor heterogeneous comm. streams

    * back-feedback: ** customized release notes ** root updates in need

    * Visual annotations: important, but only snapshot tools

    * Proactive assistnce: ** Rate MR ** Extend help info ** Get recommendation for workaround

    1 Favorite

    When Users Becom Collaborators: Towards Continuous and Context-Aware User Input - Presentation Transcript

    1. 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 29 th , 2009
    2. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
      • 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. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    5. Various types of user input ? Perpetual Beta Legacy Documents Usage Data Implicit Explicit Pull Push Issue and Bug Report Enhancement Request Feature Request Workshop Interview, Survey Clarification Request Field Observation Lead Users (Not used in SE) Communication Feedback
    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 still do not consider feedback at all…
    12. Problems of the status quo
      • Gaps through fragmented streams of user interaction – feedback cross-cuts proceses
      • User input difficult to understand
      • No frameworks for systematic integration into application
      How can we make user Input as a first-order concern in both processes and architectures? For Engineers For 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
    13. Streams of interaction Requirements Engineers Users Realization Provision Deployment Problem Usage Evolution Fix Question Support
    14. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    15. A Continuous Feedback Model Prospective Observation Assisted Feedback Improvement D ecision Back- Feedback Systematic Analysis Application User Engineering Team Development Infrastructure Community Sharing
    16. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    17. Technical building blocks 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 Making user input a 1 st order concern
    18. TeamWeaver Context Framework problem problem Execution Ontology Interaction Ontoloy Feedback Reporting Interface OS sensors User Profile Elicitation Problem events update trigger A pplication sensors Execution Env. sensors A dditional feedback interact Session- ization Context Observer http://www.teamweaver.org
    19. Visual Annotation with OpenProposal End user application http://www.openproposal.de OpenProposal plus Username, Application, Version, Date, etc. Issue Tracker
    20. Inverse Search to recommend users to share their experience
      • Conventional recommendation systems:
        • Match interests of users against a given set of information
        • 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:
        • Matches the private/local information of users (information providers) against a given set of needs
        • Identify information (e.g. experiences and interactions) worth sharing
      Experiences Needs 3. iSearch 4. Share 1. Query 2. Results Engineer / User Information Seeker User Information Provider
    21. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    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.

    + Hans-Joerg HappelHans-Joerg Happel, 4 weeks ago

    custom

    75 views, 1 favs, 0 embeds more stats

    Current requirements engineering practices for gath more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 75
      • 75 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 2
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories