Rational Unified Process for User Interface Design


Published on

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

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Rational Unified Process for User Interface Design

  1. 1. Rational Unified Process for User Interface Design g Rajendra Akerkar R. Akerkar SE 160, 2005 1
  2. 2. What Is the Rational Unified Process? The Rational Unified Process provides a disciplined approach to assigning tasks and responsibilities within a development organization. i i Its goal is to ensure the production of high- quality product that meets the needs of its end-users, end users within a predictable schedule and budget. R. Akerkar SE 160, 2005 2
  3. 3. The RUP Framework RUP = making a movie ≠ building a house movie, house. sheer size. hundreds of artifacts and activities involved involved. RUP® framework is actually easy, particularly when th i t d h theyre introduced b analogy t some d by l to familiar process. R. Akerkar SE 160, 2005 3
  4. 4. The trouble with the construction analogy RUP is so often compared to the process of constructing a building. t ti b ildi  its about producing something concrete using a similar role set and vocabulary vocabulary. As with an interactive system,  first have th f fi t h the foundation ready (th i f d ti d (the information ti architecture in the our case) before building the walls and the roof. R. Akerkar SE 160, 2005 4
  5. 5. The trouble with the construction analogy information architect deals with problems such as the internal workings of a interactive system. y The house architect is more concerned about visual and functional design,  which pretty much equals the concerns of a system analyst in the software world. R. Akerkar SE 160, 2005 5
  6. 6. The trouble with the construction analogy The main objection to comparing the two is that the building process can be a totally predictable waterfall process, while a UI development process cant! the fact is that civil engineering relies on a number of well-known physical laws of nature and nature, again, UI design doesnt! R. Akerkar SE 160, 2005 6
  7. 7. A better analogy to the RUP framework The RUP does share the basic goals and strategies of engineering processes. The actual process to achieve those goals  creative approach required by artistic disciplines  making movies,  authoring books, or g ,  even writing an article. R. Akerkar SE 160, 2005 7
  8. 8. The essential principles of the RUP RUP is based on common sense sense,  harvested from the best practices of numerous successful projects. p j Interesting fact is that similar practices exist in areas other than UI development. R. Akerkar SE 160, 2005 8
  9. 9. The essential principles of the RUP The RUP is used to mitigate the risks associated with software/UI development. By conforming to a well-defined and proven set of rules we aim to increase the rules, probability of a successful result. Why would we bother with the extra effort? R. Akerkar SE 160, 2005 9
  10. 10. The general risks associated with UIdevelopment  lack of resources for carrying out the project  insufficient funding g  not enough time and too much to do  immature, slow, or non-agile organizations These risks are the same as for any other type of development. R. Akerkar SE 160, 2005 10
  11. 11. Agile Approach Novel approach to development based on the development and delivery of very small increments of functionality. ff i li Based on Values of simplicity, communication, feedback and courage. g Relies on constant code improvement, user involvement in the development team and pairwise programming Two crucial design heuristics  never duplicate code  use simplest design possible Continuous Testing  Write the tests before we design the code R. Akerkar SE 160, 2005 11
  12. 12. The technical risks associated with UIdevelopment Unknown t h l i U k technologies. Undiscovered requirements. Complicated architecture. These risks are associated with unpredictable nature of UI development. p R. Akerkar SE 160, 2005 12
  13. 13. The RUP strategy for handing risk Develop iteratively. p y Manage requirements. Use a component architecture. architecture Model visually. Continuously verify quality quality. Manage change. The RUP gives us these primary strategies for handling such technical nature risks (the best practices of the RUP). R. Akerkar SE 160, 2005 13
  14. 14. Develop iteratively Creating something innovative, whether a motion picture or UI requires many iterations to be UI, performed on the same artifacts during the discovery process of building the final product. With a waterfall development strategy, projects cycle through the various phases in a sequential manner, postponing confrontation with potential problems t i f t ti ith t ti l bl until the product has been built and tested. Iterative development, on the other hand allows development hand, projects to proceed by small steps, or increments, to gradually build a more complete system. R. Akerkar SE 160, 2005 14
  15. 15. The RUPs iterative developmentprocess Each iteration in the RUP is a pass through the disciplines. disciplines A discipline in the RUP can be described as a grouping of interrelated activities and the artifacts or deliverables they produce. Each pass, which is like a mini waterfall, explores a new p p portion of the requirements set and offers a chance to correct defects and rework the result of the previous iteration. With each iteration, the solution is h it ti th l ti i coming closer and closer to the final product. R. Akerkar SE 160, 2005 15
  16. 16. Analogy of Moviemaking If making a movie is a pretty straightforward process of first writing a script then figuring script, out how to put the words into motion, doing the filming and editing, and finally watching g g y g the result. This would be a traditional waterfall approach. But just as the waterfall approach fails when were writing UI it would f il i making a iti UI, ld fail in ki movie as well. R. Akerkar SE 160, 2005 16
  17. 17. Analogy of Moviemaking Instead, the process is much more iterative. The actors start working with the script, and revisions arise out of that interaction. For example, the script for the blockbuster Lord of the Rings based on J R R Tolkiens classic masterpiece Rings, J.R.R. Tolkien s masterpiece, was rewritten almost every day after interaction with the actors. Director Peter J k Di t P t Jackson described th creative process d ib d the ti as a controlled chaos. Before the end of the project, the script had been rewritten many times. Each time (or iteration) resulted in an incremented (and better) version that more closely resembled the final version. R. Akerkar SE 160, 2005 17
  18. 18. Manage requirements Another essential task whenever a new product of any kind i d d t f ki d is developed i ensuring l d is i that it meets the needs of its intended users. Troublesome task - users sometimes have only a vague idea of the product under development. d l t An active requirements management strategy can it ti l i iteratively improve th requirements i t the i t into something that will satisfy users. R. Akerkar SE 160, 2005 18
  19. 19. Manage requirements The RUP enforces requirements management throughout the lifecycle lifecycle. The requirements are iteratively and incrementally identified, documented, evaluated, and refined. , , , Functional requirements are described in terms of use cases. Nonfunctional requirements are also identified and managed.  These are properties of the system that aren t described as use cases arent but usually have a great impact on them, involving the systems usability, reliability, performance, and supportability. R. Akerkar SE 160, 2005 19
  20. 20. Analogy of Moviemaking As moviemakers work with the script and the actors, they must think in terms of meeting the needs of their audience.  What kind of emotional response do they want the movie to p y evoke?  What kind of experience do they want the audience to have?  Where do they want the story to take viewers? The movie script is fine-tuned through many p g y iterations to match the directors vision of meeting these functional requirements. R. Akerkar SE 160, 2005 20
  21. 21. Analogy of Moviemaking If the functional requirements of a UI product have their counterpart in movies, then can a movie also have nonfunctional requirements? h f ti l i t ?  The answer (not surprisingly) is yes.  Maybe the movie must be viewable by children under 18 and no longer than 120 minutes minutes. Although these requirements arent directly related to the t th story line, theyll h li th ll have an iimpact on th fi l result t the final lt - just as nonfunctional software requirements must have on a computer system. In th I the same way, these requirements must be th i t tb identified and addressed in the process of making the movie. R. Akerkar SE 160, 2005 21
  22. 22. Use a component architecture A component is a replaceable piece of UI that fulfills a clear function. The RUP encourages the use of components to assemble a system. Component based Component-based development has advantages:  it facilitates reuse both within the system and by other systems,  it provides a convenient abstraction in the system design, and  it enables efficient parallel development. Furthermore, a well-structured component based well structured component-based architecture makes a system more scalable and easier to maintain. R. Akerkar SE 160, 2005 22
  23. 23. Use a component architecture( Analogy to Moviemaking) The most obvious equivalent of a component in a movie is a scene. A film is typically made up of a number of scenes unified in a coherent structure that realizes the directors vision. director s Each scene is fully replaceable, meaning that it s its possible to replace it alter it or even it, it, remove it without compromising the whole p picture ( thats what the director wants). (if ) R. Akerkar SE 160, 2005 23
  24. 24. Use a component architecture( Analogy to Moviemaking) Developing a computer application of considerable size without using a component-based architecture, something thats still done today, It is like shooting a movie in only one take.  This is how the 2002 drama Russian Ark by Aleksandr Sokurov was made - the whole movie (2 hours, 16 minutes) is one continuous shot.  Given that its pretty hard to make even a ten minute continuous it s ten-minute scene, Sokurovs achievement is truly heroic. Going back to the UI design world the RUP principle of world, component-based architecture relieves developers of the need to be heroes on impossible quests. R. Akerkar SE 160, 2005 24
  25. 25. Use a component architecture( Analogy to Moviemaking) Another movie equivalent to software components is:  In making the computer-animated adventure Finding Nemo,  The modelers were challenged with the task of creating natural- looking surging and swelling water. (under water story) The problem was not only to accurately simulate the movement of water, but also  to capture how light refracts through it,  the way particles dance around,  the colors of different types of water, and so on. This had never been achieved to that extent before in computer animation. R. Akerkar SE 160, 2005 25
  26. 26. Use a component architecture( Analogy to Moviemaking) As soon as the project was launched, the design department started experimenting with water modeling. t t d i ti ith t d li  Extensive studies, consulted experts on oceanography, made sketches and drawings, and most important of all, made prototypes based on their increasing knowledge of the problem problem. The prototypes were then exposed to the directors critical eye. Then the final result of the hard labor was a design template covering every conceivable water simulation in the movie movie. This template was a fundamental component of the films architecture; other components (templates) resolved different problems such problems, as the motion patterns of fish and plants. R. Akerkar SE 160, 2005 26
  27. 27. In the kingdom of UI development design templates tell designers how to deal with the most significant problems. Without a solid architecture or design architecture, template, there really isnt much point in moving on in the project. Until these kinds of issues can be resolved, designers will never be able to meet the requirements. R. Akerkar SE 160, 2005 27
  28. 28. Model visually A model is a simplified representation of a real-world entity or process, intended to help us imagine and process flesh out the real-world version. At some point early in the development of UI software, theres a need to understand the f interaction between the system and its users. The developers have two options:  they can implement the software as they guess it should work, or  they can create a model of it, which can then be exposed to it potential users, designers, and testers, whose feedback can in turn alter the model. R. Akerkar SE 160, 2005 28
  29. 29. Model visually This type of model, describing how a user interacts with the system, is usually referred to as a use case system model. The point of creating use case models is to mitigate p g g the risk of building the wrong system. Modeling is theoretical exercise to understand complex system behavior by simplification. The RUP encourages architecture teams to prove their architectural concepts by executing prototypes prototypes. R. Akerkar SE 160, 2005 29
  30. 30. Model visually (Analogy to Moviemaking) In the early stages of a movie project, all that exists is a script. But just as in the software case, the director needs to see the product before its completed. As with the RUP, the solution is to build a model of the story. This is known in the film industry as visualization, and it can be achieved by various techniques:  traditional actor acting,  puppet acting,  storyboarding, and  even 3D computer graphics. If storyboarding (a concept that also exists in the RUP) is used, the t b di ( t th t l i t i th i d th model consists of a sequential series of sketches illustrating stages or scenes. From the storyboards, the director can decide if a scene seems too long or should be removed, or if something is missing. removed missing The storyboards can be filmed and edited, and temporary sound effects and music can be added, just to further enhance the models usefulness. R. Akerkar SE 160, 2005 30
  31. 31. Continuously verify quality The RUP is divided into four phases, each one focusing on a certain aspect of the development g p p cycle:  Inception,  Elaboration, Elaboration  Construction, and  Transition. In each of these phases the RUP best practices give us the opportunity to verify the progress and quality of the project under development and thus to find flaws and potential improvements as early as possible. R. Akerkar SE 160, 2005 31
  32. 32. Continuously verify quality In the Inception phase, the focus is on understanding the objectives of the project project. The question to be answered before the end of this phase is whether the project is worth doing at all. Once the project has a go to continue, it enters the Elaboration phase.  Here, the focus is on establishing a solid design foundation (the architecture) and mitigating the major risks of the project. R. Akerkar SE 160, 2005 32
  33. 33. Continuously verify quality(Analogy to Moviemaking) In the RUP, the quality of the latest increment is verified in every iteration. In a movie project, the director primarily uses the modeling tools in his or her toolbox to catch problems with  a diverging story line,  scenes that dont fit together, or  a tempo (rhythm) that just isnt right. When problems are found early, its easier to do something about them. In moviemaking as in UI development the general rule is that the development, earlier a fault is discovered, the cheaper it is to fix. The best practice of continuously verifying quality can facilitate this. this R. Akerkar SE 160, 2005 33
  34. 34. Manage change change is necessary but inconvenient. Requirements will almost inevitably change over time. waterfall development so often fails is that its unable to handle change. An iterative and incremental methodology, by contrast, facilitates continuous change, iterating t it ti toward a better solution. d b tt l ti R. Akerkar SE 160, 2005 34
  35. 35. Manage Change (Analogy to Moviemaking) Making a feature film: a huge crew and a substantial budget. Communicating well about needed changes is vital to the success of such a project project.  Imagine that the director wants to improve the final scene. Although it comes at the end of the movie, the need for improvement can b id ifi d early since quality i continuously verified on all be identified l i li is i l ifi d ll levels.  Do the screenwriters have to update the script?  Who will review and approve it? pp  Does the scene have to be modeled again?  If so, will storyboards, 3D graphics, or plastic models be used?  Does the set need to be modified, or does a new set need to be built? How does this affect our budget? g  Do we have to ask for more time and money? These are the kinds of questions that result in changing plans and therefore must be addressed preferably in an iterative manner addressed, manner. R. Akerkar SE 160, 2005 35
  36. 36. A movie project plan One of the key artifacts in the RUP framework is the project plan plan. The project plan details the tasks, schedule, cost, resources, milestones, cost resources milestones and deliverables needed to complete the project. Progress is tracked against the plan and measured by work completed by milestones reached and results delivered. The plan is conceived early in the project and frequently updated throughout the lifecycle. R. Akerkar SE 160, 2005 36
  37. 37. The Iterative Model graph of RUP The horizontal axis represents time and shows the dynamic aspect of the process as it is enacted, and it is expressed in terms of cycles, phases, iterations, and milestones. The vertical axis represents the static aspect of the p p process: how it is described in terms of activities, artifacts, workers and workflows. R. Akerkar SE 160, 2005 37
  38. 38. A movie project plan = a User Interfacedevelopment project R. Akerkar SE 160, 2005 38
  39. 39. A movie project plan = a User Interfacedevelopment project In this figure, activities related to making a movie are substituted for the RUP disciplines.  Developing the screenplay is analogous to writing requirements,  filming corresponds to implementation, and  producing the movie is more or less like project management. Dividing the timeline into four p g phases pputs the focus on different aspects of the movie project at different times. We also see that the activities run in parallel, typically exchanging information and work packages in a highly efficient, cross-functional manner: f  just as the RUP. R. Akerkar SE 160, 2005 39
  40. 40. The Essentials of RUP In all projects, it is important to explore what will happen if any of these essentials is ignored. For example: 1. No vision? You may lose track of where you are going. 2. No plan? You will not be able to track progress. 3. No risk list? You may be focusing on the wrong issues now. 4. No issues li ? With t accountability, th N i list? Without t bilit these are th the roadblocks to success. 5. No architecture? You may be unable to handle communication, synchronization, communication synchronization and data access issues as they arise. R. Akerkar SE 160, 2005 40
  41. 41. The Essentials of RUP 6. No product (prototype)? Get started writing code; get something working in front of the customers customers. 7. No evaluation? Don’t keep your head in the sand. It is important to face the truth. How close are you really to your deadline? To your goals in quality or budget? 8. No change requests? How do you keep track of these? 9. No user support? What happens when a user has a pp pp question or can’t figure out how to use the product? R. Akerkar SE 160, 2005 41
  42. 42. References Rational Unified Process, version 5.5, Rational Software Corporation, Cupertino, CA (1999) Introduction to the IBM Rational Unified Process Essentials, an article by Mats Wessberg (2005). Philippe Kruchten, The Rational Unified Process An Process—An Introduction, Addison-Wesley-Longman, Reading, MA (1999) Ivar Jacobson, Grady Booch, Jim Rumbaugh, The Unified Software Development Process, Addison Wesley (1999) Process Addison-Wesley Grady Booch, et al., UML User’s Guide, Addison-Wesley- Longman, Reading, MA (1999). Stefan Bergstrand, Adopting the Rational Unified Process: Success with the RUP, Addison Wesley (2004). R. Akerkar SE 160, 2005 42