Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

User Interface Derivation from Business Processes: A Model-Driven Approach for Organizational Engineering


Published on

This presentation defines a model-driven approach for organizational engineering in which user interfaces of information systems are derived from business processes. This approach consists of four steps: business process modeling in the context of organizational engineering, task model derivation from the business process model, task refinement, and user interface model derivation from the task model. Each step contributes to specify and refine map-pings between the source and the target model. In this way, each model modification could be adequately propagated in the rest of the chain. By applying this model-driven approach, the user inter-faces of the information systems are directly meeting the require-ments of the business processes and are no longer decoupled from them. This approach has been validated on a case study in a large bank-insurance company

Published in: Business, Technology
  • Be the first to comment

User Interface Derivation from Business Processes: A Model-Driven Approach for Organizational Engineering

  1. 1. Towards User Interface Derivation from Business Processes: A Model-Driven Approach for Organizational Engineering Kênia Sousa, Hildeberto Mendonça, Jean Vanderdonckt Université catholique de Louvain (UCL) Louvain School of Management (LSM) Information Systems Unit (ISYS) Belgian Laboratory of Computer-Human Interaction (BCHI) ACM SAC 2008 Organizational Engineering Track
  2. 2. Issues <ul><li>Weak correlation between business process and UI design; </li></ul><ul><li>Difficulties in understanding business process documents; </li></ul><ul><li>Difficulties to understand, find, and keep updated information spread in different artifacts; </li></ul><ul><li>Product knowledge owned mostly by business analysts; </li></ul><ul><li>Design is done mainly by example, not based on processes; </li></ul><ul><li>Difficulties in doing impact analysis after changes. </li></ul>“… receiving only screen shots not linked with the process makes our work very difficult. ” Business Analyst System Analyst “… docs are too detailed… no prior training… they use a tool we do not have… we wait for updated docs…” UI Designer “ we are overloaded to stop and read these documents…” All: “changes impact hundreds of screens…we spend lots of times on meetings to decide what to do…”
  3. 3. Main Goals <ul><li>Provide a communication means between these two domains </li></ul><ul><li>Maintain consistency between business processes and user interfaces </li></ul><ul><li>Predict the impact of changes on business processes and user interfaces </li></ul>(Smith, 2007)
  4. 4. UI –Business Alignment Task Model Business Process
  5. 5. UI –Business Alignment Task Model User Interface
  6. 6. Why task models? <ul><li>Its hierarchical structure provides an overview of the user interaction; </li></ul><ul><li>Decomposition and temporal operators deliver the flexibility that users need. </li></ul><ul><li>It is closer to business process structure ; </li></ul><ul><li>Using task models to bridge business processes and UI design addresses the user perspective; </li></ul><ul><li>User interaction has increased its importance in making IT add value for organizations. </li></ul>
  7. 7. Model-Driven Approach <ul><li>The Cameleon Reference Framework is a flexible approach for model-driven UI development using UsiXML. </li></ul><ul><li>For the context of large organizations, we present a business–driven approach organized in three phases: </li></ul>External Models Tools Task & Concepts Abstract UI Concrete UI Task & Concepts Abstract UI Concrete UI Conception Management Application Platform A Platform B Tools Final UI (Calvary, 2003)
  8. 8. Roles, Artifacts, Tools
  9. 9. Conception Phase (1 of 3) <ul><li>Business analysts model business processes that serve as requirements for UI design. </li></ul><ul><li>They can be created using any available process modeling tool. </li></ul><ul><li>These tools are able to export their models into XML format, to interchange information with tools for UI models. </li></ul>
  10. 10. Business Process Process = 10 sub-processes Sub-process = 17 activities Activity = 30 tasks Task = 99 business rules
  11. 11. Management Phase (2 of 3) <ul><li>The focus changes from business orientation to user orientation. </li></ul><ul><li>Business process analysts help system analysts to create the task model. </li></ul><ul><li>Task models should be reviewed by human factors experts to make sure that the user perspective was considered. </li></ul><ul><li>Tools can use the exported XML and transform it into a UsiXML representation of the task model. </li></ul>
  12. 12. Associate tasks and screens
  13. 13. Grouping tasks in screens One subprocess can present one screen. Screen 1 Screen 2 Screen 1 But the same subprocess can also be decomposed into several screens.
  14. 14. Application Phase (3 of 3) <ul><li>A tool processes the models to transform them into a FUI. </li></ul><ul><li>Each CUI is derived into a FUI, when aspects such as architecture, programming languages and infra-structure are taken into account. </li></ul>
  15. 15. Final UIs
  16. 16. Traceability Business Process Data Model Task Model Domain Model Abstract UI Business User Interface Screen group Screen Screen fragment Screen element Decompose the task model in containers New activity compare Task not here New screen
  17. 17. Traceability Screen group Screen Screen fragment Screen element Abstract UI Title of page Task Model Task Model Task Model Task Model Task Model Label of field Label of field Label of field Name of fragment Name of fragment Concrete UI Final UI A concrete UI can be inspired in an abstract UI Java Swing HTML Render Style Guide
  18. 18. Forward Example <ul><li>Business analysts and UI designers noticed that different activities had tasks related to personal information of the applicant. </li></ul><ul><li>Difficult for bank agents to interact with customers because related information were placed in different screens. </li></ul><ul><li>Some tasks from the activity ‘present insurance’ were moved to the activity ‘inform applicant’ </li></ul><ul><li>Screen fragment ‘personal data’ (for activity ‘inform applicant’) had to add the screen elements ‘marital status’ and ‘birth date’ and deleted f rom the screen fragment ‘insurance data’ (for activity ‘present insurance’). </li></ul>
  19. 19. Backward Example <ul><li>Tasks running business rules; </li></ul><ul><li>As users fill out fields certain rules are executed in parallel; </li></ul><ul><li>The return of a rule requiring to change values appears on the top of the screen (the scroll is down); </li></ul><ul><li>They receive a second warning because of restrictive range of vision and extra navigation (scrolling); </li></ul><ul><li>More compact CUI enables a better user experience. </li></ul>
  20. 20. Backward Example
  21. 21. Example of rules <ul><li>Change the business process; </li></ul><ul><li>Update the task model; </li></ul><ul><li>Find out what kind of change is necessary in screens based on comparing BP and task model: </li></ul><ul><ul><li>Add screen/SF - new activity in the BP not in TM </li></ul></ul><ul><ul><li>Delete screen/SF – task in TM, but deleted from BP </li></ul></ul><ul><ul><li>Add screen element – new task in BP, not in TM </li></ul></ul><ul><ul><li>Delete screen element – task in TM, but deleted from BP </li></ul></ul><ul><ul><li>Change order of SF – order act. in BP <> order in TM </li></ul></ul><ul><ul><li>Change order of SF – order tasks in BP <> order in TM </li></ul></ul><ul><ul><li>Simple review - new description, rule, but same structure in BP and TM </li></ul></ul>
  22. 22. Tool Support
  23. 23. Assessment (1 of 2) Criteria Sub-criteria Automation Cost Training on task modeling 2 days Training on new method 1 day Implementation XML > UsiXML + synchronization Working time Creation and refinement of task models Feasibility Tool support Development
  24. 24. Assessment (2 of 2) Criteria Sub-criteria Automation Maintainability Avoid Redundancy Need for synchronization Task model refinement Relationships + grouping manually Impact analysis Association with any screen level Acceptance Change in way of work Creation of Task model
  25. 25. Intended Results <ul><li>Continuity – Models are derived one from each other with aligned and consistent result. </li></ul><ul><li>Traceability – Models are synchronized to propagate changes when needed. </li></ul><ul><li>User centered – The user experience is considered in alignment with business needs. </li></ul><ul><li>Efficient communication – designers use specific models for each goal. </li></ul>
  26. 26. Thank you for your attention BCHI Lab Program Alban UI extensible Markup Language