Software Engineering II Introduction

1. TUM Software Engineering IIIntroduction Prof. Bernd Brügge, Ph.D Technische Universität München Institut für Informatik Lehrstuhl für Angewandte Softwaretechnik http://wwwbruegge.in.tum.de

2. Can you develop this?

3. What we intend Requirements Software

4. Requirements Analysis Design Implementation Testing Delivery and Installation How it should go: Our plan of attack

5. D E L A Y Vaporware How it often goes Requirements Analysis

6. Software Production has a Poor Track Record Example: Space Shuttle Software • Cost: $10 Billion, millions of dollars more than planned • Time: 3 years late • Quality: First launch of Columbia was cancelled because of a synchronization problem with the Shuttle's 5 onboard computers. • Error was traced back to a change made 2 years earlier when a programmer changed a delay factor in an interrupt handler from 50 to 80 milliseconds. • The likelihood of the error was small enough, that the error caused no harm during thousands of hours of testing. • Substantial errors still exist. • Astronauts are supplied with a book of known software problems "Program Notes and Waivers".

7. Quality of today’s software…. • The average software product released on the market is not error free.

8. …has major impact on Users

9. Software Engineering: A Problem Solving Activity • Analysis: Understand the nature of the problem and break the problem into pieces • Synthesis: Put the pieces together into a large structure that prepares for the solution • For problem solving we use • Techniques(Methods): Formal procedures for producing results using some well-defined notation • Methodologies: Collection of techniques applied across software development and unified by a philosphical approach • Tools: Instruments or automated systems that help in accomplishing a technique • Where does management come in? • When the available resources to solve the problem are limited (time, people, budget), or • If we allow the problem to change.

10. Software Engineering: Definition • Software Engineering is a collection oftechniques, • methodologies and tools that support the • development of • a high quality software system • with a given budget • before a given deadline • while change occurs

11. Our Plan Example: Running a rapid A quiet river Unplanned event: A Hydraulic! Desired Location Current Location What can we do?

12. Change • Something becomes clear (“it crystalizes”) • Something new appears (“technology enabler”) • Something becomes important (“change of requirements”) • A process or product changes (“process change”) • Products and processes have to support multiple versions • Developers have the power to make decisions • Work is performed where it makes sense: Outsourcing • Change can happen fast • Most of the important changes are unexpected • Manager must anticipate and react to unusual technology happenings • Wayne Gretzky: “ I go where the puck is going to be, not where it is” • Hammer (Reengineering): “Change is the only thing that is constant”

13. Changes in the Business of Software Development • Several Jobs combined • Example: Case Worker, a person who deals with the whole process • Developers have the power to make decisions • Processes have multiple versions • Checks and controls reduced • Work performed where it makes sense • Outsourcing

14. Project Time PT = (tn - to) Iteration 1 Iteration 2 Iteration 3 Change Change Time between Changes = t2 - t1 t2 t1 to tn t Project Duration vs Rate of Change PT = Project Time TPBC = Time Between Changes (Requirements, Technology) MTBC = Mean Time Between Changes

15. Methodology Issues • Methodology: Provides guidance, general principles and strategies for selecting methods and tools in a given project environment in the context of change • The key questions for which methodologies typically provide guidance include: • Customer: How much should the customer be involved? • Planning: How much planning should be done in advance? • Reuse: How much of the design should result from reusing past solutions? • Modeling: How much of the system should be modeled before it is coded? • Process: In how much detail should the process be defined? • Project Monitoring: How often should the work be controlled and monitored? When should the project goals be redefined?

16. Assumptions and Requirements for this Class • Assumption: • You understand the issues in the analysis or design of a system • You want to learn more about the managerial aspects of analysis and design of complex software systems • Requirements: • You have taken Software Engineering I or an equivalent class • Beneficial: • You have practical experience with maintaining or developing a large software system and have experienced major problems

17. Appreciate Software Engineering management Manage the construction complex software systems in the context of frequent change Understand how to Produce a high quality software system within time while dealing with complexity and change and create an estimate for the resources needed Appreciate that managerial knowledge is needed when developing software system We assume that you have the technical knowledge Objectives of the Class

18. Intended audience • Primary Audience: • Students in Informatik (Diplom, Bachelor with focus on software engineering) • Secondary Audience • Students who anticipate careers that require significant interaction with software engineers • 2+2 SWS, ECTS Credits: 5 • Lecture Time: • Every Tuesday 12:15-13:45, MI HS2 • First Lecture: 19. April, Last Lecture: 16. July • Exercises • Every Wednesday 12:15-13:45, MI 00.08.038 • Office Hourse: By appointment

19. Required Technical Knowledge • You understand the problems of system modeling • You are familiar with UML (Unified Modeling Language) • You are able to use a CASE Tool: • CASE (Computer Aided Software Engineering) • Examples: Together-J, Rational Rose • You understand model-driven design (MDD) • You are able to apply different modeling methods: • Use case modeling, object modeling, dynamic modeling • You are able to use design patterns and frameworks • You understand component-based Software Engineering (CBSE)

20. What do you learn in this class? • The concept of software lifecycle • Learn about different software lifecycles • Different project types • Greenfield Engineering, Interface Engineering, Reengineering • The difference between Process vs Product • Basic project management activites and dealing with resources: • Schedule: How to map activities into time • Organization and People: How to set up a project organization • Cost: How to estimate the cost of a project • How to deal with change and uncertainty • How to set up a project plan, how to control its execution • How to become a leader, how to deal with teams, and make decisions in the context of project management trade-offs • Cost vs Schedule, People vs Functionality, Buy vs Build, …

21. Management vs Project Mangement • Management: Getting a specific task done through people • Management is usually defined in terms of functions: • Planning, organizing, directing, controlling and communicating are typical management functions • Project management is defined in the context of a project • Project management tries to accomplish a specific task within a time frame and limited resources. • Software project management is defined in the context of a software project • Activities to develop a software system within a given time frame and with limited resources. • Think about this distinction as we go through the next slides

22. April 19: Introduction and Basic Concepts (SPMP, IEEE 1058) April 26: Configuration Management (Dealing with change, SCMP, IEEE 1042) May 3: Project Management: Work Breakdown structures (Decomposition of work) May 10: Project Management: Estimation (Software economics, metrics) May 17 : No lecture (Pfingsten) May 24: Project Management: Organization (Organization forms, team-based projects) May 31: Project Management: Scheduling (Project duration, critical path analysis) June 7 : Software Testing (Planning and Managing Tests) June 14 : Lifecycle: Models (Lifecycle models, IEEE 1074) June 21 : Software Lifecycle: Unified Process (An industrial software process) June 28 : Agile Processes and Project Management (XP, Scrum) July 5: Rationale Management (Acquiring and externalizing knowledge, dealing with conflicts and resolutions) July 12: WritingProject Proposals (Guest Lecture) July 19: Exam Lecture Schedule (Tentative)

23. April 19: Software Project Management Plan (SPMP) April 27: Configuration Management (SCMP) May 4: Work Breakdown structures (Create a WBS) May 11: Estimation (Establish Estimates) May 18 : No session (Pfingsten) May 25: Project Organization (Define an Organization) June 1: Scheduling (Set up a schedule for a software project) June 8 : Testing (Create a software test plan) June 29: Agile Process Management (Manage with SCRUM) July 6: Rationale Management (Maven) Exercise Schedule (Tentative) • Exercises May 4, May 11, May 25 and June1 are done in collaboration with Wolfgang Behr, Accenture • You need to do the exercises if you want to be admitted to the exam

24. Readings • Required Reference • Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Using UML, Patterns and Java, Prentice Hall 2003. ISBN 0-13-191179-1 Chapters 11-16 • Additional References • Chris Kemerer, Software Project Management: Readings and Cases, MacGraw Hill 1997. ISBN: 0-256-18545-X • Walker Royce, Software Project Management: A Unified Framework, Addison Wesley, 1998. ISBN 0-201-30958-0 • IEEE Standards Collection Software Engineering. We cover the following standards • [IEEE Std 1058], Software Project Management Plan (SPMP) • [IEEE Std 828] Software Configuration Management • [IEEE Std 1042] Guide to Configuration Management Plan (SCMP) • [IEEE Std 1074] Software Lifecycle Management • [IEEE Std. 1074.1] Guide to IEEE 1074 • More references are given at the end of each lecture

25. Where to find more Information • Lecture Portal: • http://wwwbruegge.in.tum.de/Lehrstuhl/SoftwareTechnikSoSe2005 • Contains • Lecture Schedule • Presentations (PDF Format) • Bibliography

26. Outline of today’s lecture • Software lifecycle and activities • Basic definitions: Project, Project Plan • Software Project Management Plan • Project Organization • Managerial Processes • Technical Processes • Work Packages

27. Defining a Software Lifecycle • Software lifecycle: • Set of activities and their relationships to each other to support the development of a software system • Time relationship • Logical relationship • Typical lifecycle questions: • Which activities should I select for the software project? • What are the dependencies between activities? • Can I break these activities into more manageable parts? • How should I schedule the activities? • How do I assign people to these activities • How do I control the execution of the activities • What do I do if the activities are not proceedings as planned?

28. Iteration 1 Iteration 3 Iteration 2 Frequency of Change determines Choice of Software Lifecycle • Mean Time between Changes >> Project Time Change is rare Choose an activity-oriented model: Waterfall model, V-Model Mean Time between Changes ≈ Iteration Time Changes occur occasionally during the project Choose an activity-oriented model with iterations: Spiral model, Unified Process Mean Time between Changes << Iteration Time Changes are frequent Choose an entity-oriented model: Issue-based model, Feature-driven model

29. Standard for modeling lifecycles: IEEE Std 1074 • The IEEE Std 1074 defines the set of activities that constitute • The technical processes for the development and maintenance of software • The management and support processes • From concept exploration through retirement • The standard does not define a specific software lifecycle • This is done by the organization or the project manager • Also called „Tailoring the standard“

30. Process Group - Project Initiation - Project Monitoring &Control - Software Quality Management - Requirements Analysis - Design - Implemen- tation - V & V - Configuration Management - Documen- tation - Training - Installation - Operation & Support - Maintenance - Retirement - Concept Exploration - System Allocation Process IEEE Std 1074: Standard for Software Lifecycles IEEE Std 1074 Develop- ment Pre- Development Project Management Post- Development Cross- Development (Integral Processes)

31. Software lifecycle activities are important abstractions when planning and executing a project • Managing them will be a recurring topic during the lectures • Defining software life cycle activities is just one type of activity that has to be managed during a project • We are interested in all the technical and managerial activities in a software project

32. Basic Definitions: Project and Project Plan • Software Project: • All technical and managerial activities required to deliver the deliverables to the client. • A software project has a specific duration, consumes resources and produces work products. • Management categories to complete a software project: • Tasks, Activities, Functions • Software Project Management Plan (SPMP): • The controlling document for a software project. • Specifies the technical and managerial approaches to develop the software product. • Companion document to requirements analysis document: Changes in either may imply changes in the other document. • The SPMP may be part of the project agreement.

33. Project: Functions, Activities and Tasks A project has a duration and consists of project functions, activities and tasks Function Project Function Activity Activity Activity Activity Activity Activity Task Task Task Task UML

34. Project Function • Definition Project Function: An activity or set of activities that span the duration of the project

35. Examples of Project Functions • Configuration Management • Documentation • Quality Control (V&V: Verification and validation) • Training • Testing • Project management activities Project functions in the IEEE 1058 standard are called Integral processes in the IEEE 1074 standard. Sometimes also called cross-development processes UML

36. Tasks Function Project Function • Smallest unit of work subject to management Activity Activity Activity Activity Activity Activity • Small enough for adequate planning and tracking Task Task Task Task • Large enough to avoid micro management

37. Tasks • Smallest unit of management accountability • Atomic unit of planning and tracking • Tasks have finite duration, need resources, produce tangible result (documents, code) • Specification of a task: Work package • Name, description of work to be done • Preconditions for starting, duration, required resources • Work product to be produced, acceptance criteria for it • Risk involved • Completion criteria • Includes the acceptance criteria for the work products (deliverables) produced by the task.

38. Finding the appropriate task size is problematic Todo lists from previous projects During initial planning a task is necessarily large You may not know how to decompose the problem into tasks at first Each software development activitity identifies more tasks and modifies existing ones Tasks must be decomposed into sizes that allow monitoring Depends on nature of work and how well task is understood. Work package sould corresponds to a well defined work assignment for one participant for a week Determining Task Sizes

39. Action Item • Definition Action Item: A task assigned to a person to be done by a certain time • What?, Who?, When? • Heuristics for Duration: be done within two week or a week • Action items should appear on the meeting agenda in the Status Section • Definition Todo: An action item that is missing either the person or the deadline • Examples of todos: • Unit test class Foo, Develop project plan. • Example of action items: • Bob posts the next agenda for the context team meeting before Sep 10, 12 noon. • The test team develops the test plan by Sep 18

40. Activities Function Project Function • Major unit of work with precise dates Activity Activity Activity Activity Activity Activity • Consists of smaller activities or tasks Task Task Task Task • Culminates in project milestone.

41. Major unit of work Culminates in major project milestone: Internal checkpoint should not be externally visible Scheduled event used to measure progress Milestone often produces project baselines: formally reviewed work product under change control (change requires formal procedures) Activitites may be grouped into larger activities: Establishes hierarchical structure for project (phase, step, ...) Allows separation of concerns Precedence relations often exist among activities Activities

42. Work package, Product, Baseline, Deliverable • Work Package: • A specification for the work to be accomplished in an activity or task • Work Product: • Any tangible item that results from a project function, activity or task. • Project Baseline: • A work product that has been formally reviewed and agreed upon. • A project baselines can only be changed through a formal change procedure • Project Deliverable: • A work product to be delivered to the customer

43. Project Agreement • Project Agreement: Document written for a client that defines: • the scope, duration, cost and deliverables for the project. • the exact items, quantities, delivery dates, delivery location. • Client: Individual or organization that specifies the requirements and accepts the project deliverables. • Deliverables: Work Products to be delivered to the client • Documents • Demonstrations of functions • Demonstration of nonfunctional requirements • Demonstrations of subsystems • The form of a project agreement can be a contract, a statement of work, a business plan, or a project charter.

44. IEEE Std 1058: Standard for Software Project Management Plans (SPMP) • What it does: • Specifies the format and contents of software project management plans. • It provides a standard set of abstractions for a project manager or a whole organization to build its set of practices and procedures for developing software project management plans • Abstractions: Project, Function, Activities, Tasks • What it does not do: • It does not specify the procedures or techniques to be used in the development of the plan • It does not provide examples

45. Client Project Manager Project Team (Sponsor) Problem Statement Software Project Management Plan Project Agreement Project Agreement, Problem Statement, SPMP

46. How much planning should you do? • Two styles of navigation [Gladwin 1964] • European navigation: • Current Location and Desired Location • Planned Route • Route Deviation and Route Correction • “Polynesian navigation” • Goal • Reaction to unexpected: Change the route The main difference is the reaction to events This leads us to the notion of situated action

47. Situated action [Suchman 1990] Situation Action: Selection of action depends on the type of event, the situation and the skill of the developer. Also called context-dependent action. • Example: Events “Course deviation”, “Birds seen”, “Clouds seen”. • European Navigation consists of context independent actions: • 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 consists of context dependent actions: • 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

48. Pros and Cons of Project Plans • Advantages: • Very useful to kick off a software project (to establish the goals, organize the teams, and start with development) • Useful also for software projects if the outcome is predictable or when no major change occurs. • Disadvantages: • Of limited value to control software 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

49. 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 course and write it 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; with doldrums 85 days.

50. Auckland Project Plan (Polynesian Navigation) Project Goal: Auckland Desired Outcome: A new place for living Team: Captain and 50 sailors Organization: Flat hierarchy Tools: Use stars for navigation, measure water temperature with hand Methods: A set of event-action rules. When an event occurs, the action to be executed is determined in the current 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. Then execute T2 and T3 regularly. Interpret task results (cloud detected, birds detected) in the current context. If the interpre-tation makes a new course more promising, execute tasks T4 and T5. Schedule: None