1. Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 16, Methodologies: Putting it all together

2. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 Outline  A Mountaineering Example  Project Context  Goals, Environment, Methods, Tools, Methodology  Methodology Issues  Planning, Design Reuse, Modeling, Process, Control&Monitoring, Redefinition  Methodology Spectrum  Royce’s Methodology based on the unified process (Separate Slides)  Extreme Programming (Separate Slides)  Methodological Heuristics

3. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Key Decisions in an Expedition  A leader has to answer several key questions to create a successful expedition  What mountain should be climbed?  What process should be used?  What types of tools should be used?  Who should be member of the team?  Does the expedition need a leader?  Different answers to these questions lead to different styles  Fixed-rope Style  Alpine Style

4. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 Key Decisions in an Software Project  Project goals  Schedule  Cost  Project organization  Software life cycle Model  Tools  Methods  Team members

5. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Project Context  Project environment  Defined by the client and by the current state of the development organization. The environment constrains the project manager.  Examples: Participants’ background, problem type, location of the project.  Methods  Recipes that the project manager can select in the given environment.  Examples: use case requirements elicitation or design pattern reuse.  Tools  Devices or programs that support specific activities.  Examples: modeling tools, compilers, debuggers, change tracking tools.  Software engineering methodology  Collection of methods and tools for developing and managing a software system to achieve a specific project goal in a given project environment.  Specifies when methods or tools should be used, when not and what to do when unexpected events occur.

6. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Project Environment  Participants’ expertise  Client type(Application Domain Knowledge, Decision Power)  End user access  Technological climate  Geographical distribution  Project duration vs rate of change

7. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Client Type No ClientProxy ClientLow Pseudo Client Local King Client High LowHigh Local King Client Can make decisions Deep knowledge of application domain Usually collocated with the project. Does not report to anybody else Can answer developer questions Can effectively collaborate with developers and project manager. Proxy Client Stands in for real client, who has no time or physical distance makes collaboration with the organization difficult. Has sufficient knowledge of application domain Cannot make major decisions. Pseudo Client Often member of the development organization (e.g. marketing) The system is targeted at new market segment. Can make decisions in a short time Collaborates well with developers Limited knowledge of application domain. No Client Many projects start without a client. Example: A visionary product is developed before a market segment is opened.

8. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Local King Client  The local king client is a client who can answer developer questions and make decisions without having to ask anybody else.  The local king has deep knowledge of the application domain and is usually collocated with the project.  Local kings do not report to anybody else and can effectively collaborate with the developers and the project manager.

9. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Proxy Client  Proxy clients are sent for the “real client”. Reasons:  Real client has no time  Physical distance would make collaboration of real client with the organization difficult.  Proxy clients have sufficient knowledge of the application domain to answer clarification questions from the developers  Proxy clients do not have sufficient power of representation to make major decisions.

10. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Pseudo Client  The pseudo client is a member of the development organization (e.g., the marketing department)  The pseudo client acts as a client, because the system is targeted at a new market segment, as opposed to a single individual or company.  Pseudo clients can make decisions within a short time and can collaborate well with the development organization  Pseudo clients have a limited knowledge of the application domain.  Often developers act as pseudo clients.

11. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 “No Client”  A project can start without a client, for example, when a visionary product is developed before a market segment is opened.  In most of these cases, however, the project selects a pseudo client, so that the stakes of the developers can be balanced against the stakes of the future user.

12. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 End User Access  Clients and end users usually do not have the same interests  Clients are interested in  an early delivery date  as much functionality as possible  low cost.  End users are interested in  a familiar user interface  an easy to learn user interface  A system that supports their specific task well  The project success may also depend on a usability test to be conducted by end users

13. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Technological climate  Depending on the requirements expressed by the client, a project may be constrained in the technological components it has to use. Examples:  A project improving a legacy system deals with well-known and mature technology. But the technology might be out of date  A project developing a first-of-a-kind prototype based on a technology enabler may have to deal with preliminary versions of components and immature technology.

14. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Geographical Distribution  “Single room projects”: All participants are located in a single room, they can get to know each other, much of the important coordination can occur informally.  There are situations when single-room projects are not possible or not desirable.  The organization may have resulted from the merger or acquisition of several individual companies with different skills.  The organization is a consortium or a temporary alliance of several subcontractors, located in different geographical locations.  Some part of the development organization may need to be collocated with the client.  Geographical distribution has advantages and disadvantages:  Increases the availability of skill and lower cost labor  May take advantage of different time zones  Slows communication  Lowers awareness among teams  Leads to loss of information between sites

15. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Methodology Issues  Methodologies provide guidance, general principles and strategies for selecting methods and tools in a given project environment.  The key questions for which methodologies typically provide guidance include:  How much planning should be done in advance?  How much of the design should result from reusing past solutions?  How much of the system should be modeled before it is coded?  In how much detail should the process be defined?  How often should the work be controlled and monitored? When should the project goals be redefined?

16. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 How much Planning?  Two styles of navigation [Gladwin 1964]  European navigation:  Current Location and Desired Location  Planned Route  Route Deviation and Route Correction  “Polynesian navigation”

17. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 “European Navigation” Event: Course deviation. Auckland (Desired Location) Lima (Current Location) Planned Route Actual Route Action: Course correction

18. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Polynesian Navigation Event: “Birds seen” Lima (Current location) “We need a new place for living. Let’s go to Auckland” Tahiti (Empty island, great place for Living) Action: “Follow the birds”

19. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 Auckland Project Plan (European Navigation)  Project Goal: Auckland  Desired Outcome: Auckland is found  Team: Captain and 50 sailors  Organization: Flat hierarchy  Tools: Compass, speed meter, map  Methods: Determine planned course, write planned course before departure. Example: Start Lima. Sail West, keep the compass constantly at 97 degrees, stay at latitude 20 degrees)  Work breakdown structure  Task T1 (Check direction): Determine current direction of ship  Task T2 (Compute deviation): Determine deviation from desired course  Task T3 (Course Correction): Bring ship back on course  Process:  T1 and T2 are executed hourly. If there is a deviation, T3 is executed to bring the ship back on the planned course.  Schedule: With good wind 50 days, if doldrums are encountered, 85 days.

20. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20 Auckland Project Plan (Polynesian Navigation)  Project Goal: Auckland  Desired Outcome: A new place for living is found  Team: Captain and 50 sailors  Organization: Flat hierarchy  Tools: Use stars for navigation, measure water temperature with hand  Methods: Set up a set of event-action rules. When an event occurs, determine the action to be executed in the given context.  Work breakdown structure  Task T1 (Determine direction): Set direction of ship to a certain course  Task T2 (Check Clouds): Look for non-moving clouds in the distance  Task T3 (Check Birds): Look for birds and determine their direction  Task T4 (Compute course): Determine new course for ship  Task T5 (Change course): Change direction to follow new course  Process:  Start with T1. Tasks T2 and T3 are executed regularly. The result (cloud detected, birds detected, nothing happened) is interpreted in the current context. If the interpretation makes a new course more promising, execute task T4 and T5.  Schedule: None

21. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21 Situated action  Situated action [Suchman 1990]  Selection of action depends on the type of event, the situation and the skill of the developer. Also called context-dependent action.  Examples of navigation events: “Course deviation”, “Birds seen”, “Clouds seen”.  European Navigation is context independent:  Event: “Course deviation in the morning”  Action: “Course correction towards planned route”  Event: “Course deviation in the evening”  Action: “Course correction towards planned route”  Polynesian Navigation is context dependent:  Event: “Birds seen”, Context: Morning  Action: “Sail opposite to the direction the birds are flying”  Event: “Birds seen”, Context: Evening  Action: “Sail in the direction the birds are flying

22. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22 Example: Running a rapid A quiet river Unplanned event: A Hydraulic! Desired Location Current Location What can we do?

23. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23 Change  “Change”:  Something becomes clear (“crystalizes”)  Something new appears (“technology enabler”)  Something becomes important (“change of requirements”)

24. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24 Project duration vs Rate of Change  Three Definitions:  PT = Project Time Phase 1Phase 2Phase 3 Project Time PT = (t n - t o ) Change(t 1 )Change(t 2 ) Time between Changes = t2 - t1  TBC = Time Between Any Type of Change (Requirements, Technology)  MTBC = Mean Time Between Change toto tntn t1t1 t2t2 t

25. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25 Frequency of Change determines the Choice of the Software Lifecycle Model  Mean Time between Change >> Project Time  Change is rare  Choose an activity-oriented model: Waterfall model, V-Model  Mean Time between Change ≈ Project Time  Changes occur occasionally during the project  Choose an activity-oriented model with iterations: Boehm’s spiral model, Unified Process  Mean Time between Change << Project Time  Changes are normal (“Change is constant”)  Choose an entity-oriented model: Issue-based model, Feature- driven model

26. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26 Pros and Cons of Project Plans for Software Projects  Plus  Very useful to kick off a software project (to establish the goals, organize the teams, and start with development)  Useful also controlling a software project if the outcome is predictable or when no major change occurs.  Con:  Of limited value to control the project when the outcome is unpredictable or when unexpected (“unusual”) events occur in the project that change the project context.  Examples of unexpected events:  Appearance of new technology which was unknown at project start.  A visionary scenario turns out to be not implementable  Company is merged with another one during the project

27. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27 Methodology Issues How much planning should be done in advance?  How much of the design should result from reusing past solutions?  How much of the system should be modeled before it is coded?  In how much detail should the process be defined?  How often should the work be controlled and monitored? When should the project goals be redefined?

28. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28 How much Reuse?  Reuse can significantly reduce the development effort required to deliver a system.

29. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29

30. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30 How much Modeling?  Advantages of modeling:  Modeling enables developers to deal with complexity  Modeling makes implicit knowledge about the system explicit  Modeling formalizes it so that a number of participants can share this knowledge.  If one is not careful, models can become as complex as the system being modeled.

31. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 Managerial Challenges of Modeling  Modeling presents several challenges to the manager  Formalizing knowledge is expensive.  It takes time and effort from developers, and requires validation and consensus so that every participants agrees on the same meanings.  Models introduce redundancy.  If changes are made to the system, the models must be updated as well. If several models depict the same aspects of the system, all must be updated. If one model becomes out of sync, it loses its value.  Models become complex.  As the model complexity becomes similar to the complexity of the system, the benefit of having a model is reduced significantly.

32. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 Where do we need Models?  Models support three different types of activities:  Communication: The model provides a common vocabulary. An informal model is often used to communicate an idea.  Analysis/Design: Models enable developers to reason about the future system.  Archival: Compact representation for storing the design and rationale of the system.

33. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33 Models to support Communication  Most often used in the early phases of a project and during informal communications.  The model does not have to be consistent or complete  The notation does not even have to be correct  The model is used only to communicate an idea to another person.  If the idea is understood, the model has served its purpose.  UML is our preferred notation for models to support communication.  Other notations are acceptable, especially if the other person does not speak UML.  Example: The customer or the future end users usually don’t know UML.  Communication Media:  Can be on a Whiteboard, on a slide or even on a napkin..

34. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 “Napkin Design”

35. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35 Model for Bus Stops (used in Slide Presentation) Street Segments Adresses, length Street Bus Stop Bus Schedule name Bus Route name

36. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36 Models to support Analysis and Design  The model provides a representation that enables developers to reason about the system.  The model also forms the basis for coding, as CASE tools are able to convert models into source code templates  Used during analysis, design and implementation.  The model needs to be made consistent or complete  The notation should be correct so it the model can be entered into a CASE tool.  The model is used to communicate the idea to a tool.  UML is our preferred notation for models to models that support analysis and design. Other notations are not acceptable.  Models to support analysis and design are eventually entered into a CASE tool.

37. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37 A UML Model for Bus Stops Street Segment Addresses(left, right) length Street Bus Stop location Bus Schedule name line id Time Day number located on stops at traverses {exactly 2} next to Bus Route name type line id Intersection id x,y * * * * * * *

38. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38 Input for User Interface Generator

39. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39 Models to support Archival

40. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40 Screen Snapshot of Graphical User Interface

41. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41 UML can model more than Software Systems  UML has been designed to model software artifacts.  However, UML is a modeling language that can be used to model a variety of phenomena  projects and processes, even philosophical systems.  The models for projects and processes used in the book are models intended for communication.

42. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42 Model of a Software Project * * *

43. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43 Model of a Software Process Example: V-Model

44. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44 Models for Plato’s and Aristotle’s Views of Reality Plato Aristotle

45. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45 How do we Communicate a Complex Model?  To communicate a complex model we use navigation and reduction of complexity  Do not simply use a picture from the CASE tool and dump it in front of the user  The key is navigate through the model so the user can follow it.  Start with a simplified model and then decorate it incrementally  Start with key abstractions (use animation)  Then decorate the model with the additional classes  To reduce the complexity of the model even further  Show the use of inheritance (for taxonomies, and for design patterns)  If the model is still too complex, show the subclasses on a separate slide  Then show the use of any patterns used in the model  Make sure to use the name of the patterns

46. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46 Example: A More Complex Model of a Software Project Composite Patterns TaxonomiesBasic Abstractions

47. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47 Another attempt to navigate through the same model

48. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48 Another attempt to navigate through the same model

49. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49

50. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50 How much Process?  Modeling a software life cycle similar to modeling a system. + The process allows to reason over it, devise and implement improvements + Participants can share process knowledge with the rest of the organization. - Process knowledge is difficult to make explicit and maintain up-to-date  Trade-off faced by the project manager:  From no modeling of the process to detailed process that may be tailored.  Well-known application domain or solution domain:  Use a repeatable process model [Paulk et al., 1995]  Distributed organization:  Use of a process model enables a high degree of standardization and a lower level of miscommunication.  Prototyping or concept exploration  Trying to control such a process is difficult or not useful, as it is usually not repeated. Best to follow an entity-based life cycle.  Colocated experienced developers  Follow an entity-based life cycle or use no process.

51. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51 Pitfalls when repeating a process  When modeling a software life cycle process and reusing it in a different project, the project manager should make sure that the correct knowledge is being generalized and reused.  Example: First ascent of K2  Mahdi had experienced one climb (Nanga Parbat) which started as a hierarchical, fixed rope expedition.  At the end he saw one climber (Buhl), refusing to listen to the expedition leader and going solo for the summit (in alpine style, so to speak).  He concluded that this was the way such expeditions were conducted.

52. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52 How much Control and Monitoring?  If the project has a detailed plan the actual progress can be checked against the planned progress  On one end of the spectrum, a plan could be so detailed as to plan and monitor the progress of each participant on each day.  At the other end of the spectrum, a plan could include a single milestone indicating the delivery, leaving participants to plan their own work accordingly.  While both approaches are unreasonable, the project manager must choose a point somewhere in between that fits the project environment.  Control and monitoring is especially critical during an iterative process.  The change process needs to track changes, from request, to approval, assignment, and implementation. Metrics such as the amount of code that was scraped or reworked and the size of the change are critical to control the overall quality of the system.  In general, both planning and assessing the actual progress requires experience.  Two major problem areas:  Projects with novices  Projects involving the development of innovative systems

53. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53 Controlling Projects involving Novices Projects involving novices are hard to control. Two reasons 1.Estimation of tasks is difficult  Novice project managers are poor judges of time estimates for tasks.  Project managers without technological experience are poor judges of time estimates for development tasks.  Novice participants are poor judges of their progress 2.Difficult issues are not recognized/communicated in a timely manner Heuristics to deal with these problems:  Select a hierarchical reporting organization with more experienced participants in the middle levels.  Define milestones as demonstration and scenario-based reviews (as opposed to documents) to force participants to confront difficult issues early.  Select peer-reviews, walkthrough, and peer programming techniques, to facilitate the transfer of knowledge from experts to novices  Create the possibility of informal communication channels

54. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 54 Controlling projects for innovative systems  The development of an innovative system makes it difficult to plan accurately as there is a lack of precedents.  To control an innovative development, a project manager can increase the frequency of milestones, while leaving their exact content flexible, providing more opportunities for project goals to be refined and redirected.  If the developers are experienced, a project manager can leverage off the knowledge of experienced developers by enabling them to provide estimates for tasks and revise the project plan or the process model accordingly.

55. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 55 If the Project Goal cannot be achieved  A project goal is too ambitious or the original goal is simply wrong. Continuing is not an option.  Option 1: Ask for more resources or a revised schedule.  Often not really an option, because there is no more money and the schedule is fixed.  Option 2: Admit the problem and turn the project into a “successful failure”:  Do a thorough analysis to understand what went wrong.  Focus on the failure to determine lessons learned.  Try to recycle the work that has been achieved so far for another project.  Option 3: Revise the project goal  Turn the current project status into the goal.  Sometimes the revised project goal is actually as good or better than the originally envisioned goal (“Polynesian navigation”).

56. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 56 Methodologies  Separate Slide Set for Royce’s Methodology  Separate Slide Set For Extreme Programming

57. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 57 Methodology Do’s and Do Not’s  Try to train the client.  Train the developers about the process  Try to find a dedicated lab for all the developers  Think carefully about how to maintain the infrastructure  Use version control as an integration tool  Make sure to have resources to deal with iteration overlaps  Make sure to allow informal communication

58. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 58 Methodological Heuristics  Be prepared to change the system  Functional requirements can change during a project when the client becomes more experienced  Technological change can occur any time  Be prepared to change the organization  Move from hierarchical organization to participatory management when project participants are becoming capable of making decisions  Be prepared to change the process  Move from activity-oriented to entity-oriented during a project when beginners become experienced developers  Shorten client decision time  Train the client  Build trust  Learn the right lessons and nothing more.

59. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 59 Summary  Invest time to train the client.  Train the developers about the process  Try to find a dedicated lab for all the developers  Think carefully about how to maintain the infrastructure  Use version control as an integration tool  Make sure to have resources to deal with iteration overlaps  Make sure to allow informal communication

60. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 60 Backup Slides

61. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 61 More White Water pictures