Page 1
Software Engineering @ LEIC/LETI
Lecture 22
Page 2
Last Lecture
• Software Implementation
• Coding Standards
• Coding Rules
• Defensive Programming
Page 3
Today
• Software Evolution
• Project Management
Page 4
Software Evolution
Page 5
(Fig 9.1, Sommerville)
Page 6
(Fig 9.2, Sommerville)
Page 7
Lehman’s Laws
impact of system change
Page 9
Evolution vs
Maintenance
Page 10
lifecycle
delivery
Page 11
lifecycle
delivery
development
Page 12
lifecycle
delivery
development maintenance
Page 13
lifecycle
delivery
development maintenance
team instability
Page 14
lifecycle
delivery
development maintenance
team instabilitypoor development practices
Page 15
lifecycle
delivery
development maintenance
team instabilitypoor development practiceslower staff skills
Page 16
lifecycle
delivery
development maintenance
team instabilitypoor development practiceslower staff skillsprogram age and structure
Page 17
lifecycle
delivery
development maintenance
team instabilitypoor development practiceslower staff skillsprogram age and structure
knowledge lost
Page 19
lifecycle
development
Page 20
lifecycle
delivery
development
Page 21
lifecycle
delivery
development development
Page 22
lifecycle
delivery
development
delivery
development
Page 23
lifecycle
delivery
development
delivery
development development
Page 24
lifecycle
delivery
development
delivery
development development
delivery
Page 25
Maintenance Effort
Page 26
(Fig 9.8, Sommerville)
Page 28
what does this mean in terms of software architecture?
Page 29
Avoid the separation of maintenance from
development
Page 31
(Fig 9.7, Sommerville)
Page 32
Why is expensive and risky to replace
legacy systems?
Page 33
• There isn’t a complete and consistent specification of the legacy system
• Business processes are intertwined with the legacy system operation
• Business rules are embedded in the software
• New development is risky by itself
Page 34
Feasibility of Maintenance
Page 35
(Fig 9.9, Sommerville)
Page 36
(Fig 9.9, Sommerville)
scrap the system
Page 37
(Fig 9.9, Sommerville)
scrap the system
maintain
Page 38
(Fig 9.9, Sommerville)
scrap the system
maintain
reengineer
Page 39
(Fig 9.9, Sommerville)
scrap the system
maintain
reengineer
replace
Page 40
How can do we assess a legacy
system?
Page 41
• The use of the system
• The business processes efficiency
• System dependability
• The business relevance of the outputs the system generates
Page 42
(Fig 9.10, Sommerville)
Page 43
(Fig 9.11, Sommerville)
Page 44
Predict the cost of maintenance
Page 45
(Fig 9.13, Sommerville)
Page 47
• number and complexity of system interfaces
Page 48
• number and complexity of system interfaces
• number of inherently volatile system requirements
Page 49
• number and complexity of system interfaces
• number of inherently volatile system requirements
• the business processes where the system is used
Page 51
• number of requests for corrective maintenance
Page 52
• number of requests for corrective maintenance
• average time required for impact analysis
Page 53
• number of requests for corrective maintenance
• average time required for impact analysis
• average time taken to implement a change request
Page 54
• number of requests for corrective maintenance
• average time required for impact analysis
• average time taken to implement a change request
• number of outstanding change requests
Page 55
Reengineering
reduce maintenance costs
Page 56
(Fig 9.14, Sommerville)
Page 57
(Fig 9.15, Sommerville)
Page 58
Refactoring
change the paradigm
Page 59
Evolution Process
driven by change requests
Page 60
(Fig 9.3, Sommerville)
Page 61
(Fig 9.4, Sommerville)
Page 62
(Fig 9.4, Sommerville)
Page 63
(Fig 9.4, Sommerville)
Page 64
(Fig 9.4, Sommerville)
Page 65
(Fig 9.4, Sommerville)
Page 66
(Fig 9.5, Sommerville)
Page 67
(Fig 9.4, Sommerville)
Page 68
(Fig 9.4, Sommerville)
Page 70
Emergency Repair
compromises traceability
Page 71
(Fig 9.6, Sommerville)
Page 72
Project Management
Page 74
Adding manpower to a late software project
makes it laterFred Brooks
Page 75
What is the problem?
Page 93
What is the problem?
Page 94
Communication vs
Work
Page 95
Work! reduce Communication!
process-like
Page 96
Work! reduce Communication!
process-like
reduce communication
channels
Page 97
Communicate to Work!people-like
Page 98
Communicate to Work!people-like
improve communication
channels
Page 101
Quality of the information in the
channel!hi, what do you want? you know, i’d like to have a new
functionality for the clients. but what kind of functionalities? something that allows the user to spend less time doing …
Page 102
How can we improve the quality of
communication?
Page 103
A shared language
Page 104
Examples of shared languages in software
development?
Page 105
Language of the programmers
Page 106
Language of the designers
Page 107
Language of the architects
Page 108
Language of the clients
Page 109
They use a reduced set of concepts
Page 110
Do we lose expressive power?
Page 111
Structured programming vs
Unstructured programming
Page 112
Understandability vs
Expressive power
Page 114
In software, best practices become
language
Page 115
A common understanding enhances
communication!
Page 116
Less communication channels
work, do not talk
Page 117
How can we reduce communication
channels?
Page 118
Team Organisation
Page 119
Cohesive groups with high internal communication and
low inter-group communication
seems software modular design ;)
Page 120
Group by skills
technical and human skills?
Page 121
Technical skills
good programmer, good tester, …
Page 122
Human skillscommunication, cooperation, …
Page 123
How do the skills fit into the organization?
Page 124
Organization's roles
Page 127
• …
• requirements engineer
Page 128
• …
• requirements engineer
• software architect
Page 129
• …
• requirements engineer
• software architect
• developer
Page 130
• …
• requirements engineer
• software architect
• developer
• tester
Page 131
• …
• requirements engineer
• software architect
• developer
• tester
• …
Page 132
Strategies to create groups?
Page 133
Focussed on the business
functional staff organisation
Page 134
Focussed on the technology
technical staff organization
Page 135
Advantages and
disadvantages
Page 136
Organizations structure
Page 137
Flat vs
Hierarchical