Final Course Review - TUM · Final Course Review Bernd Bruegge Technische Universitaet Muenchen...

Post on 11-Aug-2020

4 views 0 download

Transcript of Final Course Review - TUM · Final Course Review Bernd Bruegge Technische Universitaet Muenchen...

Final Course Review

Bernd Bruegge Technische Universitaet Muenchen

Software Engineering II: Project Organization and Management

Outline for Today

•  Course Announcements: •  Lecture: Design Patterns (5 ECTS) •  Praktikum: Applied Software Engineering (10 ECTS)

•  Project with the Munich Airport •  Coach Positions available •  Masterpraktikum or Vertiefendes Masterpraktikum

•  Ideenwettbewerb: •  GoGeo 09

•  Review of lecture and exercise material for SE II

Lecture: Design Patterns

•  Master lecture •  2 V + 2 Ü, 5 ECTS

•  Wed 16:00-18:00, MI 00.13.009A, Start: Oct 21, 2009 •  Wed 14:00-16:00 MI 00.13.009A, Start: 20 Oct 2009

•  Topics •  Patterns as approach to structure and describe expert

knowledge •  Pattern-based software development •  Categories of patterns •  Classification and Combination of patterns •  Using patterns in analysis, in design, project

management, reverse engineering

•  http://drehscheibe.in.tum.de/myintum/kurs_verwaltung/c.html?cid=1295

Large Scale Project „DOLLI 3“

•  Up to 50 developers •  A complex problem in the area of facility

management: •  Real customer: Munich Airport •  Real problem: improve handling of airport

facility management systems •  Real data: Complete access to the CAD data

of the airport, access to real systems (about 80 real time processes)

•  Real deadline: System has to be delivered on time (by the end of the semester)

Participation as a coach

•  „Seminar: Advanced Project Management“ •  Qualification: Master student (or send vita

to instructor) •  Your responsibilities:

– You manage a team of 4-6 students – You report to top level management about

team achievements and problems – You take responsibility for a part of the

development documentation

•  Your gain: Real-life project experience! •  For more details, send e-mail to Harald

Stangl (stanglh@in.tum.de)

GoGeo Challenge

•  Find a new application of geodata •  For details:

http://www.gogeo09.de/

•  Idea: Develop the application on the iPhone!

•  Google Maps was just the beginning

•  You can use the chair’s infrastructure for iPhone programming

•  For more details, send e-mail to Florian Schneider (schneidf@in.tum.de)

Outline for Today

•  Course Announcements: •  Lecture Design Patterns (2 V + 2 Ü, 5 ECTS) •  Praktikum DOLLI 3 (10 ECTS)

•  Coach Positions available •  Masterpraktikum or Vertiefendes Masterpraktikum

•  Ideenwettbewerb: •  GoGeo 09

 Review of lecture and exercise material for SE II

The 5 Parts of an Agenda

1.  Purpose of the Meeting 2.  Desired Outcome 3.  Information Sharing 4.  Discussion 5.  Wrap-up

Agenda

Primary facilitator: Bernd Bruegge Minute taker: Time keeper: 1.  Purpose of this Meeting

•  Review of the SE II course material

2.  Desired Outcome •  A better understanding of the presented material,

new insights and inspirations, ability to connect isolated course topics

Agenda (cont’d)

3. Information Sharing [30 min] 1.  Reality and modeling 2.  Different ways to use models 3.  System modeling 4.  Rationale Management 5.  Software process 6.  WBS, Estimation and Scheduling 7.  Continuous Integration

Agenda (cont’d)

4. Discussion [15 min] I[1]: What are the questions in the exam?

5. Meeting Wrap [5 min] •  Identification of action items

•  Study the text book, mainly chapters 12 to 16 •  Study the lecture handouts (lecture slides are

posted on the web site) •  Study the exercises

Information Sharing

3. Information Sharing [30 min] 1.  Reality and modeling 2.  Different ways to use models 3.  System modeling 4.  Rationale Management 5.  Software process 6.  Scheduling 7.  Estimation 8.  Continuous Integration

Reality and Model

•  Reality R •  Real things, people, processes happening during some

time, relationships between things

•  Model M •  Abstractions from things, people , processes and

relationships between these abstractions •  The things really exist or can be abstractions (“ideas”)

as well.

Domains and System Models

Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um D

Das Bild kann nicht angezeigt werden. Dieser Computer verfügt möglicherweise über zu wenig Arbeitsspeicher, um das Bild zu öffnen, oder das Bild ist

Das Bild kann nicht angezeigt

Application Domain Solution Domain

System Model System Model

Aircraft TrafficController

FlightPlan Airport

MapDisplay

FlightPlanDatabase

Summary Display

TrafficControl

TrafficControl

System Modeling

•  Functional model •  Scenarios, use case model

•  Structural model •  Class diagrams, instance diagrams, collaboration

diagrams, deployment diagrams

•  Dynamic model •  Sequence diagrams, statechart and activity

diagrams

What is a “good” Model? •  Intuition: A model is good, if relationships valid in

reality R, are also valid in model M

•  Definition Interpretation I : R → M

fM

fR

M M

R R I I

In a good model this diagram is commutative.

•  Mapping of things in reality R to abstractions in model M

Why Modeling?

•  We use models •  To abstract away from details in the application

domain, so we can draw complicated conclusions in the reality by performing simple steps in the model

•  To get insights into the past or presence •  To make predictions about the future

•  We can model all kinds of systems •  Natural systems (Astronomy, Astrophysics) •  Human beings (Psychology, Sociology, HCI, CSCW) •  Artificial Systems (Computer Science)

Plato Aristotle

Even Philosophical Ideas can be modeled

Plato’s model of reality: •  Reality consists of many

particular things and many forms

•  Forms really exist independent from a particular thing

•  Beauty is real and exists by itself

Aristotle’s model of reality: •  Reality consists of many

particular things called substances

•  Each substance is composed of form and matter

•  Beauty is real, but it does not exist on its own, it is always part of a really existing thing called the substance.

Plato’s model of reality: •  Reality consists of many

particular things and many forms

•  Forms really exist independent from a particular thing

Plato

Plato’s Model of Reality

Plato’s model of reality: •  Reality consists of many

particular things and many forms

•  Forms really exist independent from a particular thing

•  Beauty is real and exists by itself.

Plato

Plato’s Model of Beauty

Aristotle’s model of reality: •  Reality consists of many

particular things called substances

•  Each substance is composed of form and matter

Aristotle

Aristotle’s View of Reality

Aristotle’s model of reality: •  Reality consists of many

particular things called substances

•  Each substance is composed of form and matter

•  Beauty is real, but it does not exist on its own, it is always part of a substance.

Aristotle

Aristotle’s View of Beauty

Comparison of Plato’s and Aristotle’s Views

Plato Aristotle

Comparison of Plato’s and Aristotle’s Views

Plato Aristotle

Matter

Thing

UML: Notation for Models

:Monkey

40

Hellabrunn Zoo:Zoo Baloo:Monkey

Mammal

Monkey Taxonomy

Idea

Reality

Models can be used in 3 Ways

•  Models support three different types of activities:

•  Communication: The model provides a common vocabulary. An model is communicated informally

•  Target is a human being (developer, end user) •  Analysis and Design: Models enable developers to

specify and reason about a future system •  Target is a tool (CASE tool, compiler)

•  Archival: Compact representation for storing the design and rationale of an existing system

•  Target is the human (analysis, project manager)

Common Vocabulary for Design Patterns

Example of a Conceptual Model (“Napkin Design”)

Client (Sponsor) Project Manager Project Team

Project Agreement

Problem Statement Software Project

Management Plan

How do we models these interactions in UML?

Another Example of a Conceptual Model

Project Manager Project Team Client Define Scope

Develop Proposal

Review SPMP

Approve Project

Problem Statement

SPMP

Project Agreement

Problem Statement, SPMP, Project Agreement (Activity Diagram)

Modeling Project Management: Tasks, Activities and Project Functions

Task

* Work

Activity

Project Function «invariant»

duration = project.duration

Project

duration

duration

Another Example of a Meta-Model: Controlled Items in a CVS System

Version

*

Controlled Item

*

CM Aggregate Configuration

Item

Release Promotion

Repository Master Directory

*

*

Information Sharing

3. Information Sharing [30 min] 1.  Reality and modeling 2.  Different ways to use models 3.  System modeling 4.  Rationale Management 5.  Software process 6.  Scheduling 7.  Estimation 8.  Continuous Integration

Rationale Management

•  What is rationale? •  Why is it critical in software engineering? •  Use of rationale in software development •  Issue Models •  Resolutions

display?:Issue

availability$:Criterion usability$:Criterion

terminal?:Issue

addressed by addressed by addressed by

raises meets

fails

meets

fails

input?:Issue

text-based:Proposal point&click:Proposal

Example of an Issue Model

The CTC system should have at least a 99% availability.

The time to input commands should be less than two seconds.

Information Sharing

3. Information Sharing [30 min] 1.  Reality and modeling 2.  Different ways to use models 3.  System modeling 4.  Rationale Management 5.  Software process 6.  WBS, Estimation, Scheduling 7.  Continuous Integration

Topics

•  Tailoring a process •  Customizing a process •  Different types of processes •  Agile vs traditional processes •  Process Activities (Requirements Analysis,

System Design, Object Design (Patterns), Reverse Engineering, ….

Example of a Meta-Model: The V-Model

Software Process

Key Question: How do we control software development?

•  Through organizational maturity (Humphrey) •  Defined process, Capability Maturity Model (CMM)

•  Through agility (Schwaber) •  Software development is empirical in nature •  Cannot be modeled with a defined process •  Should be described with an empirical process control

model

Requirements Analysis

1. What are the transformations? •  Talk to the client •  Observe the end user •  Get historical records •  Create scenarios and use case diagrams

Functional Modeling

Requirements Analysis (cont’d)

2. What is the structure of the system? •  Identify objects •  What are the associations between them? •  What is their multiplicity? •  What are the attributes of the objects? •  What operations are defined on the objects? •  Create class diagrams

Object Modeling

Requirements Analysis (cont’d)

Dynamic Modeling

3. What is the behavior of the system? •  Identify senders and receivers •  Show sequence of events between objects •  Identify event dependencies and concurrency •  Are there dynamically interesting objects? •  Create sequence diagrams •  Create activity and state diagrams

The Key Problems in Software Engineering

•  The three main challenges in software development

•  How do we harness complexity? •  How do we react to change? •  How do we deal with uncertainty?

 Methodologies

Methodologies

•  Software methodologies provide •  Guidance and general principles for dealing with

complexity, change and uncertainty •  Strategies for selecting methods and tools in a given

project environment •  Guidance what to do when things go wrong

Methodologies (cont’d)

•  Key questions in a methodology •  How much involvement of the customer? •  How much planning? •  How much reuse? •  How much modeling? •  How much process? •  How much control and monitoring?

Requirements Analysis: Review Checklist

•  Is the model correct? •  Does it represent the client’s view of the system?

•  Is the model complete? •  Is every scenario is described?

•  Is the model consistent? •  Does it have components that contradict each other?

•  Is the model unambiguous? •  Does the model describes one system or many?

•  Is the model realistic? •  Can the model be implemented?

Checklist for a Requirements Review (2)

•  Syntactical check of the models •  Check for consistent naming of classes, attributes,

methods in different subsystems •  Identify dangling associations (“pointing to nowhere”) •  Identify double- defined classes •  Identify missing classes (mentioned in one model but

not defined anywhere) •  Check for classes with the same name but different

meanings

Examples for typical syntactical Problems

•  Different spellings in different UML diagrams

•  Omissions in diagrams

Attributes Operations

League

Attributes Operations

Tournament

Attributes Operations

Player Attributes Operations

Match

Attributes Operations

League Owner 1 *

* *

Attributes Operations

Tournament_ Boundary

Attributes makeTournament

(name, maxp)

Announce_ Tournament_

Control

Different spellings in different UML diagrams

UML Sequence Diagram UML Class Diagram

createTournament (name, maxp)

Different spellings in different models

for the same operation

Omissions in some UML Diagrams

Attributes Operations

League

Attributes Operations

Tournament

Attributes Operations

Player Attributes Operations

Match

Attributes Operations

League Owner 1 *

* *

Attributes Operations

Tournament_ Boundary

Class Diagram

Missing Association (Incomplete Analysis?)

Missing class (The control object

Announce_Tournament is mentioned in the sequence diagram)

Information Sharing

3. Information Sharing [30 min] 1.  Reality and modeling 2.  Different ways to use models 3.  System modeling 4.  Rationale Management 5.  Software process 6.  WBS, Estimation, Scheduling 7.  Continuous Integration

WBS, Estimation and Scheduling

•  Determining Work and Tasks Sizes •  Different Approaches for developing WBSs •  Notations for Work Breakdown Structures •  Heuristics for Developing Good WBS •  Boehm’s Cone of Uncertainty •  Dependency Diagrams and Notations •  Critical Path Analysis (Forward Path and

Backward Path Analysis) •  Burndown Charts

Computing a critical path

Activity 3 t3 = 1

Activity 4 t4 = 3

Activity 2 t2 = 1

Start t = 0

Activity 1 t1 = 5

End t = 0

Activity5 5 = 2

Start t = 0

Activity 1 t1 = 5

End t = 0

Activity5 t5 = 2

Critical path with bold and red arrows

Additional Topics

•  Icebreaker •  Basic Concepts (Work Package, WBS, Task,

Activity, Project Baseline, Release, Promotion, Configuration Management, Deliverable, Audience List, etc, etc)

•  Study the talks from the invited speakers (Holger Wolf, Beck et al, Buisiness Process Engineering, Thomas Uhl, Topalis, Open Source)

•  Structures in Organization •  Functional vs Matrix vs Project-based Organizations

•  Architecture-centric Project Management •  Agile Project Management, Situated actions

Setting up a Project: Example

1. Define Subsystem decomposition (“Top-Level Design”)

UserInterface

Control

Database

2. Determine the Work Breakdown Structure

Develop

Develop Database Subsystem

Develop Control UserInterface Subsystem

Develop System

Setting up a Project: Example

2. Determine the Work Breakdown Structure

Develop

Develop Database Subsystem

Develop Control UserInterface Subsystem

Develop System

3. Set up the Teams

UserInterface :Team

Control :Team

Database :Team

Binding Roles To People Project To-Do List (from your WBS)

• Item 1 • Item 2 • Item 3 • Item 4 • Item 5 • Item 6 • Item 7 • Item 8 • Item 9

Item 1 Item 2 Item 9

Role 1

Item 4 Item 5 Item 7

Role 2

Item 3 Item 6 Item 8

Role 3

Person A

Person B

Role 1

Role 2

Role 3

To-Do Role Bindings are made during Project-Initiation Phase

Roles-Person Bindings are made during Initial Planning phase

(First team meeting, etc …)

Key Concepts for Binding Roles to People

•  Responsibility •  The commitment to achieve specific results •  Redefinition of role: A role is a set responsibilities

•  Delegation •  Rebinding a responsibility assigned to one person

(including yourself) to another person.

•  Authority •  The ability to make the binding decisions between

roles and people

•  Accountability •  Tracking a task performance to a person

Structures in Organizations

•  An organization usually has 3 different types of associations between organizational units

•  Reporting structure •  Shows how status information is reported

•  Decision structure •  Shows how decisions are propagated

•  Communication structure •  Shows how information is exchanged.

Scrum Components

Scrum�Master

Potentially shippable Product Increment

Daily Scrum meeting

Dealing with Uncertainty, Complexity and Change (Agile Manifesto)

Individuals and Interactions

Processes and Tools

Working

Software Comprehensive Documentation

Customer

Collaboration Contract Negotiation

Responding to Change Following a Plan

Dealing with Uncertainty, Complexity and Change (Agile Manifesto)

Royce Scrum

Extreme Programming Waterfall

Individuals and Interactions

Processes and Tools

Working

Software Comprehensive Documentation

Customer

Collaboration Contract Negotiation

Responding to Change Following a Plan

Light, Agile

Heavy

Lasts Hints

•  Form a study group •  Formulate questions that the others in the study group

have to answer •  Rotate questioner and answerer

•  Some questions are of the form: •  Here is ….. Model …. in UML

•  Several questions are of the form: •  What is…? Name the advantages and/or

disadvantages of ...

•  Others questions are of the form: •  Assume you are the project manager of …. How would

you handle this problem....?