Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
SWEN 256 – Software Process & Project Management
Software change is inevitable
o New requirements emerge when the software is under
development or being used
o The business environment changes
o Errors must be repaired, Risks mitigated
o New equipment must be accommodated
o The performance or reliability may have to be improved
A key problem for organisations is implementing
and managing change to their current projects and
legacy systems
Sometimes change occurs during development
that necessitates changes in scope o Approval of CCB (Change Control Board) and
o Requires extensive planning
o May require more time/resources (project triangle)
Plan-driven methodologies may or may not have this built in
(i.e. Spiral) or may be specifically built to resist change (i.e.
Waterfall)
Agile Methodologies embrace change
o Scrum allows for change to the Product Backlog at any time, but
manages risk by freezing the current Sprint Backlog
Stakeholder Communication IS KEY
Software maintenance
o Changes are made in response to changed requirements
but the fundamental software structure is stable
Architectural transformation
o The architecture of the system is modified generally from
a centralised architecture to a distributed architecture
Software re-engineering
o No new functionality is added to the system but it is
restructured and reorganised to facilitate future changes
These strategies may be applied separately or
together
Law Description
Cont inuing change A program that is used in a real-world environment
neces sarily must change or become progress ively less
useful in that environment.
Increasing complexity As an evolving program changes , its st ructure tends
to become more complex. Extra res ources must be
devoted to pres erving and simplifying the s tructure.
Large program evolut ion Program evolution is a s elf-regulating process .
Syst em att ributes such as size, time between releas es
and the number of reported errors are approximately
invariant for each s ystem release.
Organis ational st ability Over a program’s lifet ime, its rate of development is
approximately const ant and independent of the
resources devoted to sys tem development.
Cons ervation of
familiarit y
Over the lifetime of a sys tem, the incremental change
in each releas e is approximately constant.
This has not yet been established
They are generally applicable to large, tailored
systems developed by large organisations
It is not clear how they should be modified for
o Shrink-wrapped software products
o Systems that incorporate a significant number of COTS
components
o Small organisations
o Medium sized systems
Modifying a program after it has been put into
use
Maintenance does not normally involve major
changes to the system’s architecture
Changes are implemented by modifying existing
components and adding new components to the
system
The system requirements are likely to change
while the system is being developed because
the environment is changing. Therefore a
delivered system won't meet its requirements!
Systems are tightly coupled with their environment.
When a system is installed in an
environment it changes that environment and
therefore changes the system requirements.
Systems MUST be maintained therefore if they
are to remain useful in an environment
Maintenance to repair software faults
o Changing a system to correct deficiencies in the way meets
its requirements (Corrective Maintenance)
Maintenance to adapt software to a different operating
environment
o Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation (Adaptive
Maintenance)
Maintenance to add to or modify the system’s functionality
o Modifying the system to satisfy new requirements (Perfective
Maintenance)
F u nc t io na li ty
a dd it io n or
m o di fi c a ti on
(65 % )
F a u lt re pa i r
(17 % )
S o f tw are
a da p ta t io n
(18 % )
S p e ci f ic a t io n Im pl e m e nt io n
V a li da t io nO p e ra ti on
S ta rt
R e le as e 1
R e le as e 2
R e le as e 3
Usually greater than development costs (2* to
100* depending on the application)
Affected by both technical and non-technical
factors
Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.
Ageing software can have high support costs
(e.g. old languages, compilers etc.)
0 5 0 1 00 1 50 2 00 2 50 3 00 3 50 4 00 4 50 5 00
S y st e m 1
S y st e m 2
D e v e lo pm e n t c os ts M a in te n a nc e c os ts
$
Team stability
o Maintenance costs are reduced if the same staff are involved with
them for some time
Contractual responsibility
o The developers of a system may have no contractual responsibility
for maintenance so there is no incentive to design for future change
Staff skills
o Maintenance staff are often inexperienced and have limited domain
knowledge
Program age and structure
o As programs age, their structure is degraded and they become
harder to understand and change
Rather than think of separate development and
maintenance phases, evolutionary software is
software that is designed so that it can
continuously evolve throughout its lifetime
YES, but how/much?
Maintenance prediction is concerned with
assessing which parts of the system may cause
problems and have high maintenance costs
o Change acceptance depends on the maintainability of
the components affected by the change
o Implementing changes degrades the system and
reduces its maintainability
o Maintenance costs depend on the number of changes
and costs of change depend on maintainability
P re di c ti ng
m a in ta i na b il it y
P re di c ti ng sy st e m
c ha n ge s
P re di c ti ng
m a in te n a nc e
c os ts
W h a t w i ll be th e li fe ti m e
m a in te n a nc e c os ts of th is
s ys te m ?
W h a t w i ll be th e c os ts o f
m a in ta i ni ng t hi s s ys t em
o ve r t he n e xt y e a r?
W h a t pa r t s o f t he s ys te m
w i ll be t he m os t e x pe ns iv e
t o m a i nt a in ?
H o w m a ny c ha n ge
re qu e st s c a n b e
e xp e c te d ?
W h a t pa r ts o f the sy ste m a re
m os t li ke ly t o b e a f fe c te d by
c ha n ge re qu e st s?
Predicting the number of changes requires an
understanding of the relationships between a
system and its environment
Tightly coupled systems require changes whenever
the environment is changed
Factors influencing this relationship are
o Number and complexity of system interfaces
o Number of inherently volatile system requirements
o The business processes where the system is used
Predictions of maintainability can be made by
assessing the complexity of system components
Studies have shown that most maintenance effort
is spent on a relatively small number of system
components
Complexity depends on
o Complexity of control structures
o Complexity of data structures
o Procedure and module size
Process measurements may be used to assess
maintainability
o Number of requests for corrective maintenance
o Average time required for impact analysis
o Average time taken to implement a change request
o Number of outstanding change requests
If any or all of these is increasing, this may indicate
a decline in maintainability
There is a need to convert many legacy systems
from a centralised architecture to a client-server
architecture
Change drivers
o Hardware costs. Servers are cheaper than mainframes
o User interface expectations. Users expect graphical user
interfaces (CLIGUI)
o Distributed access to systems. Users wish to access the
system from different, geographically separated,
computers
Factor Description
Business importance Returns on the investment of distributing a legacy system depend on its
importance to the business and how long it will remain important. If
distribution provides more efficient support for stable business
processes then it is more likely to be a cost-effective evolution strategy.
System age The older the system the more difficult it will be to modify its
architecture because previous changes will have degraded the structure of
the system.
System structure The more modular the system, the easier it will be to change the
architecture. If the application logic, the data management and the user
interface of the system are closely intertwined, it will be difficult to
separate functions for migration.
Hardware procurement
policies
Application distribution may be necessary if there is company policy to
replace expensive mainframe computers with cheaper servers. .
Ideally, for distribution, there should be a clear
separation between the user interface, the system
services and the system data management
In practice, these are usually intermingled in older
legacy systems
D a t a ba s e
U s e r i nt e r fa c e
S e rvi c e s
Ide a l m o de l for di st r ib ut io n R e a l le g a c y s ys te m s
D a t a ba s e
U s e r i nt e r fa c e
S e rvi c e s
St ra tegy A dva nt age s D is adva nt age s
Imp lem e nta t ion
u s ing th e w indow
m a nage m ent
s ys tem
A cc e ss to a ll UI f unc t ion s so no
re a l re s tri ct ions on UI de s ign
Be t te r UI pe rf o rm ance
P la tf o rm dep e ndent
M ay be m o re di ffi cul t to ach ieve
in te rf a c e con s is te ncy
Imp lem e nta t ion
u s ing a w eb
b ro w ser
P la tf o rm ind e penden t
Lo w e r tr ain ing co s ts due to u s e r
fa m il ia r ity w i th th e WWW
E a sie r to a chi e ve int erf ac e
con s is te ncy
P oten t ia l ly poo re r UI
pe rf o rm anc e
Int erf ac e des ign i s con s tra ined
by th e f ac i li t ie s p rovid e d by web
b ro w ser s
The costs of software change usually exceed the
costs of software development
Factors influencing maintenance costs include
staff stability, the nature of the development
contract, skill shortages and degraded system
structure
Architectural evolution is concerned with evolving
centralised to distributed architectures
A distributed user interface can be supported using
screen management middleware