Software Evolution, Project

Management, Project Scheduling

1
Why Are Projects Late?
◼ an unrealistic deadline established by someone outside the
software development group
◼ changing customer requirements that are not reflected in
schedule changes;
◼ an honest underestimate of the amount of effort and/or the
number of resources that will be required to do the job;
◼ predictable and/or unpredictable risks that were not considered
when the project commenced;
◼ technical difficulties that could not have been foreseen in
advance;
◼ human difficulties that could not have been foreseen in advance;
◼ miscommunication among project staff that results in delays;
◼ a failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the
problem

2
Scheduling Principles
◼ Compartmentalization – Break the work into
small tasks
◼ Interdependency – Show which tasks
depend on others
◼ effort validation—be sure resources are
available
◼ defined responsibilities—people must be
assigned
◼ defined outcomes—each task must have an
output
◼ defined milestones—review for quality
3
Effort Allocation
◼ “front end” activities
◼ customer communication
40-50% ◼ analysis
◼ design
◼ review and modification
◼ construction activities
◼ coding or code
15-20% generation
◼ testing and installation
◼ unit, integration
◼ white-box, black box
◼ regression
30-40%

4
Defining Task Sets
◼ determine type of project
◼ assess the degree of rigor required
◼ identify adaptation criteria
◼ select appropriate software engineering tasks

5
Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12

6
Schedule Tracking
◼ conduct periodic project status meetings in which
each team member reports progress and problems.
◼ evaluate the results of all reviews conducted
throughout the software engineering process.
◼ determine whether formal project milestones have
been accomplished by the scheduled date.
◼ compare actual start-date to planned start-date for
each project task listed in the resource table.
◼ meet informally with practitioners to obtain their
subjective assessment of progress to date and
problems on the horizon.
◼ use earned value analysis to assess progress
quantitatively.

7
 Software Evolution
◼ Program evolution dynamics
◼ Software maintenance
◼ Complexity and Process metrics
◼ Evolution processes

8
 Software change
◼ Software change is inevitable
◼ New requirements emerge when the software is
used;
◼ The business environment changes;
◼ Errors must be repaired;
◼ New computers and equipment is added to the
system;
◼ The performance or reliability of the system may
have to be improved.
◼ A key problem for organisations is
implementing and managing change to their
existing software systems.
9
 Importance of evolution
◼ Organizations have huge investments in their
software systems - they are critical business
assets.
◼ To maintain the value of these assets to the
business, they must be changed and updated.
◼ The majority of the software budget in large
companies is devoted to evolving existing
software rather than developing new software.

10
 Program evolution dynamics
◼ Program evolution dynamics is the study of the
processes of system change.
• What triggers changes (e.g., user needs, bugs)
• How change affects software structure, cost, and complexity
• Patterns in software change (e.g., more features = more
complexity)
◼ After major empirical studies, Lehman and Belady
proposed that there were a number of ‘laws’ which
applied to all systems as they evolved.
◼ There are sensible observations rather than laws. They
are applicable to large systems developed by large
organisations. Perhaps less applicable in other cases.

11
 Lehman’s laws
Law Description
Continuing change A p rogram that is used in a real-world environment necessarily
must change or become progressively less useful in that
environment.
Increasing complexity As an evolving program changes, its structure tends to become
more complex. Extra resources must be devoted to preserving
and simplifying the structure.
Large program evolution Program evolution is a self-regulating process. System
attributes such as size, time between releases and the number of
reported errors is approximately invariant for each system
release.
Organisational stability Over a programÕs lifetime, its rate of development is
approximately constant and independent of the resources
devoted to sys tem development.
Conservation of Over the lifetime of a system, the incremental change in each
familiarity release is approximately co nstant.
Continuing growth The functionality offered by systems has to continually increase
to maintain user satisfaction.
Declining quality The quality of systems will appear to be declining unless they
are adapted to changes in their operational environment.
Feedback system Evolution processes incorporate multi-agent, multi-loop
feedback systems and you have to treat them as feedback
systems to achieve significant product improvement.
12
 Applicability of Lehman’s
laws

◼ Lehman’s laws seem to be generally applicable to

13
 Software maintenance
◼ 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.

14
 Maintenance is inevitable
◼ 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.

15
 Types of maintenance
◼ Maintenance to repair software faults
◼ Changing a system to correct deficiencies in the way
meets its requirements.
◼ Maintenance to adapt software to a different
operating environment
◼ Changing a system so that it operates in a different
environment (computer, OS, etc.) from its initial
implementation.
◼ Maintenance to add to or modify the system’s
functionality
◼ Modifying the system to satisfy new requirements.

16
 Distribution of maintenance effort

Fault repair
(17%)

Functionality
Software addition or
adaptation m odification
(18%) (65%)

17
 Maintenance costs
◼ 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.).

18
 Development/maintenance
costs

19
 Maintenance cost factors

◼ Team stability
◼ Maintenance costs are reduced if the same staff are
involved with them for some time.
◼ Contractual responsibility
◼ The developers of a system may have no contractual
responsibility for maintenance so there is no incentive to
design for future change.
◼ Staff skills
◼ Maintenance staff are often inexperienced and have limited
domain knowledge.
◼ Program age and structure
◼ As programs age, their structure is degraded and they
become harder to understand and change.
20
 Complexity metrics
◼ 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
◼ Complexity of control structures;
◼ Complexity of data structures;
◼ Object, method (procedure) and module size.

21
 Process metrics
◼ Process measurements may be used to assess
maintainability
◼ 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.
◼ If any or all of these is increasing, this may
indicate a decline in maintainability.

22
 Evolution processes
◼ Evolution processes depend on
◼ The type of software being maintained;
◼ The development processes used;
◼ The skills and experience of the people involved.
◼ Proposals for change are the driver for system
evolution. Change identification and evolution
continue throughout the system lifetime.

23
 Change identification and
evolution

24
 The system evolution
process

25
 Change implementation

26
 Urgent change requests
◼ Urgent changes may have to be implemented
without going through all stages of the software
engineering process
◼ If a serious system fault has to be repaired;
◼ If changes to the system’s environment (e.g. an OS
upgrade) have unexpected effects;
◼ If there are business changes that require a very
rapid response (e.g. the release of a competing
product).

27
 Emergency repair

28