software engineering @ leic/leti · software engineering @ leic/leti ... program age and structure....

137
Software Engineering @ LEIC/LETI Lecture 22

Upload: hoangbao

Post on 26-Jul-2018

228 views

Category:

Documents


0 download

TRANSCRIPT

Software Engineering @ LEIC/LETI

Lecture 22

Last Lecture

• Software Implementation

• Coding Standards

• Coding Rules

• Defensive Programming

Today

• Software Evolution

• Project Management

Software Evolution

(Fig 9.1, Sommerville)

(Fig 9.2, Sommerville)

Lehman’s Laws

impact of system change

Evolution vs

Maintenance

lifecycle

delivery

lifecycle

delivery

development

lifecycle

delivery

development maintenance

lifecycle

delivery

development maintenance

team instability

lifecycle

delivery

development maintenance

team instabilitypoor development practices

lifecycle

delivery

development maintenance

team instabilitypoor development practiceslower staff skills

lifecycle

delivery

development maintenance

team instabilitypoor development practiceslower staff skillsprogram age and structure

lifecycle

delivery

development maintenance

team instabilitypoor development practiceslower staff skillsprogram age and structure

knowledge lost

lifecycle

lifecycle

development

lifecycle

delivery

development

lifecycle

delivery

development development

lifecycle

delivery

development

delivery

development

lifecycle

delivery

development

delivery

development development

lifecycle

delivery

development

delivery

development development

delivery

Maintenance Effort

(Fig 9.8, Sommerville)

what does this mean in terms of software architecture?

Avoid the separation of maintenance from

development

Legacy Systems

(Fig 9.7, Sommerville)

Why is expensive and risky to replace

legacy systems?

• 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

Feasibility of Maintenance

(Fig 9.9, Sommerville)

(Fig 9.9, Sommerville)

scrap the system

(Fig 9.9, Sommerville)

scrap the system

maintain

(Fig 9.9, Sommerville)

scrap the system

maintain

reengineer

(Fig 9.9, Sommerville)

scrap the system

maintain

reengineer

replace

How can do we assess a legacy

system?

• The use of the system

• The business processes efficiency

• System dependability

• The business relevance of the outputs the system generates

(Fig 9.10, Sommerville)

(Fig 9.11, Sommerville)

Predict the cost of maintenance

(Fig 9.13, Sommerville)

• number and complexity of system interfaces

• number and complexity of system interfaces

• number of inherently volatile system requirements

• number and complexity of system interfaces

• number of inherently volatile system requirements

• the business processes where the system is used

• number of requests for corrective maintenance

• number of requests for corrective maintenance

• average time required for impact analysis

• number of requests for corrective maintenance

• average time required for impact analysis

• average time taken to implement a change request

• 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

Reengineering

reduce maintenance costs

(Fig 9.14, Sommerville)

(Fig 9.15, Sommerville)

Refactoring

change the paradigm

Evolution Process

driven by change requests

(Fig 9.3, Sommerville)

(Fig 9.4, Sommerville)

(Fig 9.4, Sommerville)

(Fig 9.4, Sommerville)

(Fig 9.4, Sommerville)

(Fig 9.4, Sommerville)

(Fig 9.5, Sommerville)

(Fig 9.4, Sommerville)

(Fig 9.4, Sommerville)

Emergency Repair

Emergency Repair

compromises traceability

(Fig 9.6, Sommerville)

Project Management

Team complexity

Adding manpower to a late software project

makes it laterFred Brooks

What is the problem?

n(n-1)/2

What is the problem?

Communication vs

Work

Work! reduce Communication!

process-like

Work! reduce Communication!

process-like

reduce communication

channels

Communicate to Work!people-like

Communicate to Work!people-like

improve communication

channels

What can we do?

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 …

How can we improve the quality of

communication?

A shared language

Examples of shared languages in software

development?

Language of the programmers

Language of the designers

Language of the architects

Language of the clients

They use a reduced set of concepts

Do we lose expressive power?

Structured programming vs

Unstructured programming

Understandability vs

Expressive power

Less is more

In software, best practices become

language

A common understanding enhances

communication!

Less communication channels

work, do not talk

How can we reduce communication

channels?

Team Organisation

Cohesive groups with high internal communication and

low inter-group communication

seems software modular design ;)

Group by skills

technical and human skills?

Technical skills

good programmer, good tester, …

Human skillscommunication, cooperation, …

How do the skills fit into the organization?

Organization's roles

• …

• …

• requirements engineer

• …

• requirements engineer

• software architect

• …

• requirements engineer

• software architect

• developer

• …

• requirements engineer

• software architect

• developer

• tester

• …

• requirements engineer

• software architect

• developer

• tester

• …

Strategies to create groups?

Focussed on the business

functional staff organisation

Focussed on the technology

technical staff organization

Advantages and

disadvantages

Organizations structure

Flat vs

Hierarchical