Upload
baishakhi-karmakar
View
233
Download
0
Embed Size (px)
Citation preview
8/2/2019 2 Lecture2 Intro
1/27
1
SWE 205 - Introduction toSoftware Engineering
Lecture 2
8/2/2019 2 Lecture2 Intro
2/27
2
Lecture Objectives Legacy Software Systems
Software Evolution
Software Engineering Costs
Software Myths
Software Engineering Challenges
8/2/2019 2 Lecture2 Intro
3/27
3
Legacy Software Many programs still provide a valuable
business benefit, even though they are one or
even two decades old. Software systems need to be continually
updated if they are to remain useful to theircustomers.
These programs must be maintained and thiscreates problems because their design isoften not amenable to change.
8/2/2019 2 Lecture2 Intro
4/27
4
Legacy Software Why must it change?
Software must be adapted to meet the needs of
new computing environments or technology. Software must be enhanced to implement new
business requirements.
Software must be extended to make it
interoperable with other more modern systems ordatabases.
Software must be re-architected to make it viablewithin a network environment.
8/2/2019 2 Lecture2 Intro
5/27
5
Software Evolution Continuing Change
A program that is used in a real-world
environment changes or become less andless useful in that environment
Increasing Complexity As an evolving program changes, its
structure becomes more complex unlessactive efforts are made to avoid thisphenomenon
8/2/2019 2 Lecture2 Intro
6/27
6
Software Evolution Program Evolution
Program evolution is a self-regulating
process and measurement of systemattributes such as size, time betweenreleases, number of reported errors etc.reveals statistically significant trends andin-variances
8/2/2019 2 Lecture2 Intro
7/277
Software Evolution Conservation of Organizational Stability
Over the lifetime of a program, the rate of
development of that program isapproximately constant and independent ofthe resources devoted to systemdevelopment
8/2/2019 2 Lecture2 Intro
8/27
Lehman, M et al. 'Metrics andLaws of Software Evolution - The
Nineties View', In Proceedings ofMETRICS 97, 1997 8
Software Evolution Conservation of Familiarity
Over the lifetime of a system, the
incremental system change in eachrelease is approximately constant
8/2/2019 2 Lecture2 Intro
9/279
Software Evolution Implications
Change is inevitable, plan for it
Dont attempt to make very big changes in
a single increment
Adding staff to a project will have a limited
effect on project recovery
8/2/2019 2 Lecture2 Intro
10/2710
Software Engineering Costs Distribution of costs in computing projects is
changing - software rather than hardware is
the largest single cost item. Software costs more to maintain than it does
to develop. For systems with a long life,maintenance costs may be several times
development costs
Software engineering is concerned with cost-effective software development
8/2/2019 2 Lecture2 Intro
11/2711
Software Engineering Costs Distribution of costs depends on the
development model.
Costs vary depending on
the type of system being developed and;
the requirements of system attributes such
as performance and system reliability.
8/2/2019 2 Lecture2 Intro
12/2712
Activity Cost Distribution
Specificaiton
Analysis &Design
Implementation
Integration &Testing
15%
25%
20%
40%
8/2/2019 2 Lecture2 Intro
13/27
13
Development - Maintenance
Cost Ratios
Development -Cost
Maintenance -Cost
40%60%
8/2/2019 2 Lecture2 Intro
14/27
14
Maintenance Cost Ratios
Adaption
Enhance
Bug Fixing
36%
12% 12%
8/2/2019 2 Lecture2 Intro
15/27
15
Important Question Why do we continue to have difficulty in
software development projects?
8/2/2019 2 Lecture2 Intro
16/27
16
London Ambulance Service
Case Study
ComputerAided
Dispatch
Server
Server
Automatic VehicleLocation System
RadioCommunicationInfrastructure
Ambulance
8/2/2019 2 Lecture2 Intro
17/27
17
London Ambulance Service
Case Study System could not keep track of the
location and status of ambulances.
Database entries begin to storeincorrect information.
As a result,
A large number of exception messages
System starts to slow down
8/2/2019 2 Lecture2 Intro
18/27
18
London Ambulance Service
Case Study Entire system descended into chaos
Ambulance arrives for a Stoke patient
after 11 hours.
The CAD system was removed andaspects of its function (dispatch
decisions) were performed manually.
8/2/2019 2 Lecture2 Intro
19/27
19
Software Myths Affect managers, stakeholders, and
practitioners
Are believable because they often haveelements of truth
but
Invariably lead to bad decisions,
therefore. Insist on reality as you navigate your way
through software engineering
8/2/2019 2 Lecture2 Intro
20/27
20
Management Myths We already have books full of
standards and procedures for building
software. That will provide my peoplewith everything they need to know
My people do have state-of-the-art
software development tools. After all,we buy them the latest computers
8/2/2019 2 Lecture2 Intro
21/27
21
Management Myths If we get behind schedule we can add
more programmers and catch up
If I decide to outsource the softwareproject to a third party, I can just relax
and let that firm build it
8/2/2019 2 Lecture2 Intro
22/27
22
Customer Myths A general statement of objectives is
sufficient to begin writing software - we
can fill in the details later Project requirements continually
change but change can be easily
accommodated because software isflexible
8/2/2019 2 Lecture2 Intro
23/27
23
Practitioners Myths Once we write the program and get it to
work our job is done
Until I get the program running I reallyhave no way of assessing its quality
The only deliverable for a successful
project is the working program
8/2/2019 2 Lecture2 Intro
24/27
24
Key Challenges Heterogeneity
Developing techniques for building software thatcan cope with heterogeneous platforms and
execution environments;
Delivery Developing techniques that lead to faster delivery
of software;
Trust Developing techniques that demonstrate that
software can be trusted by its users.
8/2/2019 2 Lecture2 Intro
25/27
25
Key Challenges An accompanying shift from a concern
with whether a system will work
towards how well it will work. Components are selected and
purchased off the shelf (COTS) with
development effort being refocused onconfiguration and interoperability
8/2/2019 2 Lecture2 Intro
26/27
26
How a Project Starts? Every software project is precipitated by
some business need
Need to correct a defect in an existingapplication
Need to adapt a legacy system to achanging business environment
Need to extend the functions and featuresof an existing application
Need to create a new product or system
8/2/2019 2 Lecture2 Intro
27/27
27
Key Points Software is a complex engineering
product.
Approaches which work for constructingsmall programs for personal use do notscale-up to the challenges of realsoftware construction.
A disciplined engineering process andassociated management disciplined isneeded.