Introduction. Course Information

Июль 25, 2022

Главная
Английский язык
Introduction. Course Information

Содержание

2. Course Information Textbooks (see more on the course website) Bruegge & Dutoit: Object-Oriented Software Engineering: Using
3. Introduction: Software is Complex Complex ≠ complicated Complex = composed of many simple parts related to
4. Complexity Example: Scheduling Fence Construction Tasks Setting posts [ 3 time units ] Cutting wood [
5. More Complexity Suppose today is Tuesday, November 29 What day will be on January 3? [
6. The Frog in Boiling Water Small problems tolerate complacency—lack of immediate penalty leads to inaction Negative
7. The Role of Software Engg. (1) Customer Software Engineering Programmer A bridge from customer needs to
8. The Role of Software Engg. (2)
9. Example: ATM Machine Understanding the money-machine problem:
10. Problem-solving Strategy Divide-and-conquer: Identify logical parts of the system that each solves a part of the
11. How ATM Machine Might Work
12. Cartoon Strip: How ATM Machine Works
13. Software Engineering Blueprints Specifying software problems and solutions is like cartoon strip writing Unfortunately, most of
14. Second Law of Software Engineering Software should be written for people first ( Computers run software,
15. Software Development Methods Method = work strategy The Feynman Problem-Solving Algorithm: (i) Write down the problem
16. Waterfall Method Each activity confined to its “phase”. Unidirectional, no way back; finish this phase before
17. UML – Language of Symbols UML = Unified Modeling Language Online information: http://www.uml.org
18. How Much Diagramming? Use informal, ad-hoc, hand-drawn, scruffy diagrams during early stages and within the development
19. Understanding the Problem Domain System to be developed Actors Agents external to the system that interact
20. ATM: Gallery of Players Actors (Easy to identify because they are visible!)
21. Gallery of Workers + Tools Concepts (Hard to identify because they are invisible/imaginary!)
22. Use Case: Withdraw Cash
23. How ATM Machine Works (2) Domain Model (2) Alternative solution
24. How ATM Machine Works (3) Domain Model (3) Alternative solution Which solution is the best or
25. Rube Goldberg Design Garage door opener
26. Actual Design
27. Feasibility & Quality of Designs Judging feasibility or quality of a design requires great deal of
28. Software Measurement What to measure? Project (developer’s work), for budgeting and scheduling Product, for quality assessment
29. Formal hedge pruning
30. Work Estimation Strategy Make initial guess for a little part of the work Do a little
31. Sizing the Problem (1) Size( ③ ) = 10 Size( ② ) = 7 Size( ①
32. Sizing the Problem (2) Step 3: Estimate the size of the total work Total size =
33. Sizing the Problem (3) Assumptions: Relative size estimates are accurate That’s why parts should be small
34. Exponential Cost of Estimation Improving accuracy of estimation beyond a certain point requires huge cost and
35. Estimation Error Over Time Time Estimation error Completion Start Waterfall method cone of uncertainty starts high
36. Estimation Error Over Time Time Estimation error Project Completion Start Agile method cone of uncertainty starts
37. Agile Project Effort Estimation
38. Measuring Quality of Work
39. Concept Maps SENTENCE: “My friend is coding a new program” translated into propositions Useful tool for
40. Case Study: Home Access Control Objective: Design an electronic system for: Home access control Locks and
41. Case Study – More Details
42. Know Your Problem Mortise Lock Parts
43. Concept Map for Home Access Control
45. Скачать презентацию

Слайд 2

Course Information
Textbooks (see more on the course website)
Bruegge & Dutoit: Object-Oriented

Software Engineering: Using UML, Patterns and Java, Third Edition, Prentice Hall, 2010. | ISBN 0-13-6061257
Miles & Hamilton: Learning UML 2.0, O’Reilly Media, 2006. ISBN: 0-596-00982-8

Слайд 3

Introduction: Software is Complex
Complex ≠ complicated
Complex = composed of many simple

parts related to one another
Complicated = not well understood, or explained

Слайд 4

Complexity Example: Scheduling Fence Construction Tasks
Setting posts
[ 3 time units ]
Cutting wood
[

2 time units ]

Painting
[ 5 time units for uncut wood;
4 time units otherwise ]

Nailing
[ 2 time units for unpainted;
3 time units otherwise ]

Setting posts < Nailing, Painting

Cutting < Nailing

…shortest possible completion time = ?

[ ⇒ “simple” problem, but hard to solve without a pen and paper ]

Слайд 5

More Complexity
Suppose today is Tuesday, November 29
What day will be on

January 3?

[ To answer, we need to bring the day names and the day numbers into coordination, and for that we may need again a pen and paper ]

Слайд 6

The Frog in Boiling Water
Small problems tolerate complacency—lack of immediate penalty

leads to inaction
Negative feedback accumulates subtly and by the time it becomes painful, the problem is too big to address
Frog in gradually heated water analogy:
The problem with little things is that none of them is big enough to scare you into action, but they keep creeping up and by the time you get alarmed the problem is too difficult to handle
Consequently, “design smells” accumulate, “technical debt” grows, and the result is “software rot”

https://en.wikipedia.org/wiki/Design_smell
https://en.wikipedia.org/wiki/Technical_debt
https://en.wikipedia.org/wiki/Software_rot

Слайд 7

The Role of Software Engg. (1)
Customer
Software Engineering
Programmer
A bridge from customer

needs to programming implementation

First law of software engineering
Software engineer is willing to learn the problem domain
(problem cannot be solved without understanding it first)

Слайд 8

The Role of Software Engg. (2)

Слайд 9

Example: ATM Machine
Understanding the money-machine problem:

Слайд 10

Problem-solving Strategy
Divide-and-conquer:
Identify logical parts of the system that each solves a

part of the problem
Easiest done with the help of a domain expert who already knows the steps in the process (“how it is currently done”)
Result: A Model of the Problem Domain (or “domain model”)

Слайд 11

How ATM Machine Might Work

Слайд 12

Cartoon Strip: How ATM Machine Works

Слайд 13

Software Engineering Blueprints
Specifying software problems and solutions is like cartoon strip

writing
Unfortunately, most of us are not artists, so we will use something less exciting: UML symbols
However …

Слайд 14

Second Law of Software Engineering
Software should be written for people first
(

Computers run software, but hardware quickly becomes outdated )
Useful + good software lives long
To nurture software, people must be able to understand it

Слайд 15

Software Development Methods
Method = work strategy
The Feynman Problem-Solving Algorithm: (i) Write down

the problem (ii) think very hard, and (iii) write down the answer.
Waterfall
Unidirectional, finish this step before moving to the next
Iterative + Incremental
Develop increment of functionality, repeat in a feedback loop
Agile
Continuous user feedback essential; feedback loops on several levels of granularity

Слайд 16

Waterfall Method
Each activity confined to its “phase”.
Unidirectional, no way back; finish this

phase before moving to the next

Слайд 17

UML – Language of Symbols
UML = Unified Modeling Language
Online information:
http://www.uml.org

Слайд 18

How Much Diagramming?
Use informal, ad-hoc, hand-drawn, scruffy diagrams during early stages

and within the development team
Hand-drawing forces economizing and leads to low emotional investment
Economizing focuses on the essential, most important considerations
Prioritize substance over the form
Not being invested facilitates critique and suggested modifications
Always take snapshot to preserve records for future
Use standardized, neat, computer-generated diagrams when consensus reached and designs have “stabilized”
Standards like UML facilitate communication with broad range of stakeholders
But, invest effort to make neat and polished diagrams only when there is an agreement about the design, so this effort is worth doing
Invest in the form, only when the substance is worth such an investment

Слайд 19

Understanding the Problem Domain
System to be developed
Actors
Agents external to the system

that interact with it
Concepts/ Objects
Agents working inside the system to make it function
Use Cases
Scenarios for using the system

Слайд 20

ATM: Gallery of Players
Actors
(Easy to identify because they are visible!)

Слайд 21

Gallery of Workers + Tools
Concepts
(Hard to identify because they are invisible/imaginary!)

Слайд 22

Use Case: Withdraw Cash

Слайд 23

How ATM Machine Works (2)
Domain Model (2)
Alternative solution

Слайд 24

How ATM Machine Works (3)
Domain Model (3)
Alternative solution
Which solution is the

best or even feasible?

Слайд 25

Rube Goldberg Design
Garage door opener

Слайд 26

Actual Design

Слайд 27

Feasibility & Quality of Designs
Judging feasibility or quality of a design

requires great deal of domain knowledge (and commonsense knowledge!)

Слайд 28

Software Measurement
What to measure?
Project (developer’s work), for budgeting and scheduling
Product, for quality assessment

Слайд 29

Formal hedge pruning

Слайд 30

Work Estimation Strategy
Make initial guess for a little part of the

work
Do a little work to find out how fast you can go
Make correction on your initial estimate
Repeat until no corrections are needed or work is completed

Слайд 31

Sizing the Problem (1)
Size( ③ ) = 10
Size( ② ) =

Size( ① ) = 4

Size( ④ ) = 3

Size( ⑤ ) = 4

Size( ⑥ ) = 2

Size( ⑦ ) = 4

Size( ⑧ ) = 7

Step 2:
Estimate relative sizes of all parts

Step 1: Divide the problem into small & similar parts

Слайд 32

Sizing the Problem (2)
Step 3: Estimate the size of the total

work
Total size = Σ points-for-section i (i = 1..N)
Step 4: Estimate speed of work (velocity)
Step 5: Estimate the work duration
Travel duration =

Слайд 33

Sizing the Problem (3)
Assumptions:
Relative size estimates are accurate
That’s why parts should

be small & similar-size!
Advantages:
Velocity estimate may need to be adjusted (based on observed progress)
However, the total duration can be recomputed quickly
Provided that the relative size estimates of parts are accurate —accuracy easier achieved if the parts are small and similar-size
Unfortunately:
Unlike hedges, software is mostly invisible and does not exist when project is started ? The initial estimate hugely depends on experience and imagination

Слайд 34

Exponential Cost of Estimation
Improving accuracy of estimation beyond a certain

point requires huge cost and effort (known as the law of diminishing returns)
In the beginning of the curve, a modest effort investment yields huge gains in accuracy

Слайд 35

Estimation Error Over Time
Time
Estimation
error
Completion
Start
Waterfall method cone of uncertainty starts high and

gradually converges to zero as the project approaches completion.

Requirements

Design

Implementation

Waterfall Method

Слайд 36

Estimation Error Over Time
Time
Estimation
error
Project
Completion
Start
Agile method cone of uncertainty starts high and

in leaps converges to zero as the project approaches completion.

Requirements
Design
Implementation

Agile Method

Leaps in estimation accuracy caused by insight about the overall project, gained through completion of parts of work

Requirements
Design
Implementation

Part 1 completion

Part 2 completion

Слайд 37

Agile Project Effort Estimation

Слайд 38

Measuring Quality of Work

Слайд 39

Concept Maps
SENTENCE: “My friend is coding a new program”
translated into propositions
Useful

tool for problem domain description

Слайд 40

Case Study: Home Access Control
Objective: Design an electronic system for:
Home access

control
Locks and lighting operation
Intrusion detection and warning

Слайд 41

Case Study – More Details

Слайд 42

Know Your Problem
Mortise Lock Parts

Слайд 43

Introduction. Course Information

Содержание

Course InformationTextbooks (see more on the course website)Bruegge & Dutoit: Object-Oriented

Introduction: Software is ComplexComplex ≠ complicatedComplex = composed of many simple

Complexity Example: Scheduling Fence Construction TasksSetting posts[ 3 time units ]Cutting wood[

More ComplexitySuppose today is Tuesday, November 29What day will be on

The Frog in Boiling WaterSmall problems tolerate complacency—lack of immediate penalty

The Role of Software Engg. (1)CustomerSoftware Engineering ProgrammerA bridge from customer

The Role of Software Engg. (2)

Example: ATM MachineUnderstanding the money-machine problem:

Problem-solving StrategyDivide-and-conquer:Identify logical parts of the system that each solves a

How ATM Machine Might Work

Cartoon Strip: How ATM Machine Works

Software Engineering BlueprintsSpecifying software problems and solutions is like cartoon strip

Second Law of Software EngineeringSoftware should be written for people first(

Software Development MethodsMethod = work strategyThe Feynman Problem-Solving Algorithm: (i) Write down

Waterfall MethodEach activity confined to its “phase”.Unidirectional, no way back; finish this

UML – Language of SymbolsUML = Unified Modeling LanguageOnline information:http://www.uml.org

How Much Diagramming?Use informal, ad-hoc, hand-drawn, scruffy diagrams during early stages

Understanding the Problem DomainSystem to be developedActorsAgents external to the system

ATM: Gallery of PlayersActors(Easy to identify because they are visible!)

Gallery of Workers + ToolsConcepts(Hard to identify because they are invisible/imaginary!)

Use Case: Withdraw Cash

How ATM Machine Works (2)Domain Model (2)Alternative solution

How ATM Machine Works (3)Domain Model (3)Alternative solutionWhich solution is the

Rube Goldberg DesignGarage door opener