Software Engineering 4 Maintenance Management PDF

IT3205: Fundamentals of
Software Engineering
(Compulsory)
IT3205 - Software Maintenance
Software
Engineering
Software Maintenance
Duration: 3 hours
Learning Objectives
• Describe the types of software maintenance
UCSC - 2014 2
• Describe the software maintenance

process
• Describe activities of configuration
management
Detailed Syllabus
7.1 Evolving nature of software
7.1.1 Different types of maintenance
7.1.1.1 Fault repair
7.1.1.2 Software adaptation
7.1.1.3 Functionality addition or modification
UCSC - 2014 3
7.1.2Maintenance prediction 7.1.3

Re-engineering
Detailed Syllabus
7.2 Configuration Management (CM)
7.2.1Importance of CM 7.2.2 Configuration
items 7.2.3 Versioning
UCSC - 2014 4
7.1 EVOLVING NATURE OF

SOFTWARE
Software change
• Software change is inevitable
– New requirements emerge when the software is used;
– The business environment changes;
– Errors must be repaired;
UCSC - 2014 5
– 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 all organizations is implementing
and managing change to their existing software
systems.
Importance of Evolution
• Organizations have huge investments in their
software systems
– they are critical business assets.
UCSC - 2014 6
• To maintain the value of these assets to the

business, they must be changed and updated.
• The majority of the so ware budget in large
companies is devoted to evolving existing software
rather than developing new software.
UCSC - 2014 7
A spiral model of Development and

Evolution
UCSC - 2014 8
UCSC - 2014 9
Evolution and Servicing
UCSC - 2014 10
UCSC - 2014 11
Evolution and Servicing

• Evolution
– The stage in a software system’s life cycle where it is in operational use
and is evolving as new requirements are proposed and implemented
in the system.
• Servicing
– At this stage, the software remains useful but the only changes made
are those required to keep it operational i.e. bug fixes and changes to
reflect changes in the software’s environment. No new functionality is
added.
• Phase-out
– The software may still be used but no further changes are made to it.
UCSC - 2014 12
Evolution processes
• Software 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.
– Should be linked with components that are affected by the
change, thus allowing the cost and impact of the change to
be estimated.
UCSC - 2014 13
• Change identification and evolution

continues throughout the system lifetime.
UCSC - 2014 14
Change Identification and Evolution

Processes
UCSC - 2014 15
UCSC - 2014 16
The Software Evolution Process
Change Impact Release Change System

request analysis planning implementation release
Fault Release System

repair planning enhancement
UCSC - 2014 17
Change Implementation
• Iteration of the development process where the revisions to
the system are designed, implemented and tested.
• A critical difference is that the first stage of change
implementation may involve program understanding,
especially if the original system developers are not
responsible for the change implementation.
• During the program understanding phase, you have to
understand how the program is structured, how it delivers
functionality and how the proposed change might affect the
program.
UCSC - 2014 18
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 to allow normal
operation to continue;
– 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).
UCSC - 2014 19
The emergency repair process
UCSC - 2014 20
Change
requests
Analyze source Modify source Deliver modified

code code system
UCSC - 2014 21
Program evolution dynamics

• Program evolution dynamics is the study of the
processes of system change.
• After several 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.
– It is not clear if these are applicable to other types of
software system.
UCSC - 2014 22
Change 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.
UCSC - 2014 23
• Systems MUST be changed if they are to

remain useful in an environment.
Lehman’s Laws
Law Description
Continuing change A program that is used in a real-world environment must necessarily
change, or else become progressively less useful in that environment.
Increasing As an evolving program changes, its structure tends to become more

complexity complex. Extra resources must be devoted to preserving and simplifying the
structure.
Large program Program evolution is a self-regulating process. System attributes such

evolution as size, time between releases, and the number of reported errors is approximately
invariant for each system release.
UCSC - 2014 24
Organizational Over a program’s lifetime, its rate of development is approximately
stability constant and independent of the resources devoted to system
development.
UCSC - 2014 25
Lehman’s Laws
UCSC - 2014 26
Law Description
UCSC - 2014 27
Conservation of familiarity Over the lifetime of a system, the incremental change in each
Applicability of Lehman’s laws

• Lehman’s laws seem to be generally applicable to
large, tailored systems developed by large
organisations.
– Confirmed in early 2000’s by work by Lehman on the
FEAST project.
• It is not clear how they should be modified for
– Shrink-wrapped software products;
– Systems that incorporate a significant number of COTS
components;
– Small organisations;
UCSC - 2014 28
– Medium sized systems.
Reasons for changes

• Errors in the existing system
– The performance or reliability of the system may have to
be improved.
• Changes in requirements
– New requirements emerge when the software is used.
• Technological advances
– New computers and equipment is added to the system.
• Legislation and other changes
UCSC - 2014 29
• The change in the business environment

Software Maintenance
• Modifying a program after it has been put into use.
• The term is mostly used for changing custom
software. Generic software products are said to
evolve to create new versions.
• Maintenance does not normally involve major
changes to the system’s architecture.
UCSC - 2014 30
• Changes are implemented by modifying

existing components and adding new components to
the system.
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 ghtly coupled with their environment.
When a system is installed in an environment it
UCSC - 2014 31
changes that environment and therefore

changes the system requirements.
• Systems MUST be maintained therefore if they are to
remain useful in an environment.
Types of maintenance
• Corrective Maintenance
– to repair software faults. Changing a system to correct deficiencies in
the way meets its requirements.
• Adaptive Maintenance
– Maintenance to add to or modify the system’s functionality
– Modifying the system to satisfy new requirements
UCSC - 2014 32
– Modifying the system to suit new operation environment
• Perfective Maintenance
– Modifying the system to satisfy new requirements.
– Improving programs performance, structure, reliability etc. Making
changes to avoid future problems or prepare for future changes
Maintenance costs
• Usually greater than development costs (2* to 100*
depending on the application).
• Affected by both technical and non-technical factors.
UCSC - 2014 33
• 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.).
Reasons for high Maintenance cost
• Program age and structure
– The design and the programming practices used in
developing old systems may not be flexible, hence
modifying existing systems may be difficult.
UCSC - 2014 34
• Team Stability
– After a system has been delivered, it is normal for the
development team to be broken up and people work on
new projects. The new team responsible for the
maintenance of the system may not understand the
design decisions and hence lot of effort during the
maintenance process is taken up with understanding the
existing system.
Reasons for high Maintenance cost

• Contractual responsibility
– The maintenance contract may be given to a difference
company rather than the original system developer. This
UCSC - 2014 35
factor along with the lack of team stability,

means that there is no incentive for a development team
to write the software so that it is easy to change.
• Staff skills
– Maintenance is seen as a less skilled process than system
development and is often allocated to junior staff
members. Programming languages and techniques used in
old systems may be obsolete, hence new staff members
may not like to learn these languages and techniques.
UCSC - 2014 36
Maintenance prediction
• Maintenance prediction is concerned with assessing
which parts of the system may cause problems and
have high maintenance costs
– Change acceptance depends on the maintainability of the
components affected by the change;
– Implementing changes degrades the system and reduces
its maintainability;
– Maintenance costs depend on the number of changes and
costs of change depend on maintainability.
UCSC - 2014 37
Change prediction
• Predicting the number of changes requires and
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
– Number and complexity of system interfaces;
– Number of inherently volatile system requirements;
– The business processes where the system is used.
UCSC - 2014 38
Software Re-engineering
• Re-structuring or re-writing part or all of a
legacy system without changing its
functionality.
• Applicable where some but not all subsystems
of a larger system require frequent
maintenance.
UCSC - 2014 39
• Re-engineering involves adding effort

to make them easier to maintain. The system
may be re-structured and re-documented.
Software Re-engineering
• What?
– Re-structuring or re-writing part or all of an existing system without changing
its functionality
• When?
– When some but not all sub-systems of a larger system require frequent
maintenance
– When hardware or software support becomes obsolete
• How?
UCSC - 2014 40
– The system may be re-structured and re-documented to make it

easier to maintain
• Why?
– Reduced risk
• New software development carries high risk.
– Reduced cost
• The cost of re-engineering is often significantly less than the costs of developing new software
Advantages of re-engineering
• Reduced risk
– There is a high risk in new software development.
There may be development problems, staffing
problems and specification problems.
UCSC - 2014 41
• Reduced cost
– The cost of re-engineering is often significantly
less than the costs of developing new software.
UCSC - 2014 42
Forward engineering and re-

engineering
UCSC - 2014 43
UCSC - 2014 44
The re-engineering process
UCSC - 2014 45
Original Program Modularized

UCSC - 2014 Original data 46
program documentation program
Re-engineering activities
• Source code translation
– The program is converted from an old programming
language to a more modern version of the same language
or to different language.
• Reverse engineering
– The program is analyzed and information extracted from it
which help to document its organization and functionality.
• Program structure improvement

– The control structure of the program is analyzed and
modified to make it easier to read and understand.
UCSC - 2014 47
Re-engineering activities
• Program modularization
– Related parts of the program are grouped together and,
where appropriate, redundancy is removed. In some cases
this stage may involve architectural transformation.
• Data re-engineering
– The data processed by the program is changed to reflect
program changes.
UCSC - 2014 48
Reengineering cost factors

• The quality of the software to be
reengineered.
• The tool support available for reengineering.
• The extent of the data conversion which is
required.
• The availability of expert staff for
reengineering.
– This can be a problem with old systems based on
technology that is no longer widely used.
UCSC - 2014 49
Preventative maintenance by
refactoring
• Refactoring is the process of making improvements to a
program to slow down degradation through change.
• You can think of refactoring as ‘preventative maintenance’
that reduces the problems of future change.
• Refactoring involves modifying a program to improve its
structure, reduce its complexity or make it easier to
understand.
UCSC - 2014 50
• When you refactor a program, you should not add

functionality but rather concentrate on program
improvement.
Refactoring and reengineering

• Re-engineering takes place after a system has been
maintained for some time and maintenance costs
are increasing. You use automated tools to process
and re-engineer a legacy system to create a new
system that is more maintainable.
• Refactoring is a continuous process of improvement
throughout the development and evolution process.
UCSC - 2014 51
It is intended to avoid the structure and code

degradation that increases the costs and difficulties
of maintaining a system.
7.2 CONFIGURATION
MANAGEMENT (CM)
UCSC - 2014 52
Configuration management
• CM is the development and application of standards and
procedures for managing an evolving software product.
• You need to manage evolving systems because, as they
evolve, many different versions of the software are created.
• These versions incorporate proposals for change, correc ons
of faults and adaptations for different hardware and
operating systems.
• There may be several versions under development and in use
at the same time. You need to keep track of these changes
that have been implemented and how these changes have
been included in the software.
UCSC - 2014 53
Configuration Management
• All products of the software process may have to be
managed
– Specifications
– Designs
– Programs
– Test data
– User manuals
• Thousands of separate documents are generated for

a large software system
UCSC - 2014 54
Configuration Management
• CM Plan
– A CM plan described the standards and procedures which
should be used for configuration management. The
starting point for developing the plan should be a set of
general, company-wide CM standards and these should be
adapted as necessary for each specific project
The contents of a CM plan
1. The definitions of what entities are to be managed and a formal
scheme for identifying these entities.
2. A statement of who takes responsibility for the CM procedures
and for submitting controlled entities to the CM team.
UCSC - 2014 55
3. The CM policies that are used for change control and

version management.
4. A description of the records of the CM process which should be
maintained.
5. A description of the tools to be used for CM and the process to be
applied when using these tools.
6. A definition of the configuration database which should used to
record configuration information.
The configuration database

• All CM information should be maintained in a configuration
database
• allow queries
– Who has a particular system version?
UCSC - 2014 56
– What platform is required for a particular version?

– What versions are affected by a change to component X? – How many
reported faults in version T?
• The CM database should preferably be linked to the so ware

being managed
– When a programmer downloads a program it is ‘booked’ out to
him/her
– Could be linked to a CASE tool
The change management process

Request change by completing a change request form
Analyze change request
If change is valid then
Assess how change might be implemented
Assess change cost
UCSC - 2014 57
Submit request to change control board
If change is accepted then repeat
make changes to software
submit changed software for quality approval
until software quality is adequate
create new system version
else reject change
request
else reject change
request
UCSC - 2014 58
Change request form
UCSC - 2014 59
UCSC - 2014 60
Derivation history
• Record of changes applied to a document or code component
• Should record, in outline, the change made, the ra onale for
the change, who made the change and when it was
implemented
• May be included as a comment in code. If a standard
prologue style is used for the derivation history, tools can
process this automatically
UCSC - 2014 61
Versions/variants/releases
• Version
– An instance of a system which is functionally distinct in
some way from other system instances
UCSC - 2014 62
• Variant
– An instance of a system which is functionally identical but
non-functionally distinct from other instances of a system
• Release
– An instance of a system which is distributed to users
outside of the development team
Versions/variants/releases
• Version Numbering
– Simple naming scheme uses a linear derivation
e.g. V1, V1.1, V1.2, V2.1, V2.2 etc.
– Better way is Attribute Naming
UCSC - 2014 63
• Examples of attributes are Date, Creator, Programming

Language, Customer, Status etc
• AC3D (language =Java, platform = NT4, date = Jan 1999)
Summary
• Software development and evolution can be thought of as an
integrated, iterative process that can be represented using a
spiral model.
• For custom systems, the costs of software maintenance
usually exceed the software development costs.
• The process of software evolution is driven by requests for
changes and includes change impact analysis, release
planning and change implementation.
UCSC - 2014 64
• Lehman’s laws, such as the notion that change is

continuous, describe a number of insights derived from long-
term studies of system evolution.
Summary
• There are 3 types of software maintenance, namely
Corrective, Adaptive and Perfective maintenance.
• Software re-engineering is concerned with re-structuring and
re-documenting software to make it easier to understand and
change.
• Refactoring, making program changes that preserve
functionality, is a form of preventative maintenance.
UCSC - 2014 65
(Compulsory)
UCSC - 2014 66
Software Project Management
Duration: 3 hours
Learning Objectives
• State the requirement of managerial control
of the development process.
UCSC - 2014 67
• Describe the main phases of software

project management.
• Describe project planning and project
scheduling activities in detail.
Detailed Syllabus
8.1 Need for the proper management of software
projects
8.2 Management activities
8.2.1 Project planning
UCSC - 2014 68
8.2.2 Estimating costs

8.2.3 Project scheduling
8.2.4 Risk management
8.2.5 Managing people
UCSC - 2014 69
8.1 NEED FOR THE PROPER

MANAGEMENT OF SOFTWARE
PROJECTS
Software Project Management
• Concerned with the activities involved in ensuring
that software is delivered on time and on schedule
UCSC - 2014 70
and in accordance with the requirements of

the organizations developing and procuring the
software.
• Project management is needed because software

development is always subject to budget and schedule
constraints that are set by the organization
developing the software.
UCSC - 2014 71
Success Criteria
• Deliver the software to the customer at the
agreed time
• Keep overall costs within budget
• Deliver software that meets the customer’s
expectations
• Maintain a happy and well-functioning
development team
UCSC - 2014 72
Software Management Distinctions

• The product is intangible
– Software cannot be seen or touched. Software project managers
cannot see progress by simply looking at the artefact that is being
constructed
• Many software projects are 'one-off' projects

– Large software projects are usually different in some ways from
previous projects. Even managers who have lots of previous experience
may find it difficult to anticipate problems
• Software processes are variable and organization specific

– We still cannot reliably predict when a particular software process is
likely to lead to development problems
UCSC - 2014 73
8.2 MANAGEMENT ACTIVITIES
SPM Activities
1. Project Planning
2. Cost Estimation
3. Project Scheduling
UCSC - 2014 74
4. Risk Management
5. Team Management
1. Project Planning
• Probably the most time consuming project
management activity
• This is a continuous activity from initial concept
through to system delivery
• Plans must be regularly revised as new information
becomes available
UCSC - 2014 75
• Various different types of plans may be

developed to support the main software project plan
that is concerned with schedule and budget
Contents of a Project Plan

• Introduction
– This briefly describes the objectives of the project and
sets out the constraints (i.e. budget, schedule, … etc.)
which affects the project management
UCSC - 2014 76
• Project organization
– This describes the way in which the development team
is organized, the people involved and their roles in the
team
• Risk analysis
– This describes possible project risks, the likelihood of
these risks arising and the risk reduction strategies
which are proposed

• Hardware & software requirements
– Describes the hardware and the support software required to
carry out the development
UCSC - 2014 77
• Work breakdown
– Describes the breakdown of the project into activities and
identifies the milestones and deliverables associated with each
activity
• Project schedule
– This describes the dependencies between activities, the estimated
time required to reach each milestone and the allocation of
people to activities

• Monitoring and reporting mechanisms
– This describes the management reports which should be
produced, when these should be produced and the project
monitoring mechanisms used
UCSC - 2014 78
• Reference to quality plan

– Quality procedures for the project must be specified in a quality
plan for the project
2. Software Cost Estimation

• Cost estimation is concerned with predicting
the resources required for a software
development process
• Fundamental estimation questions
1. How much effort is required to complete an
activity?
UCSC - 2014 79
2. How much calendar time is needed to

complete an activity?
Software Cost Components
• Hardware and software costs
• Travel and training costs
• Effort costs
– Salaries of engineers
– Social and insurance costs
• Other overheads
UCSC - 2014 80
– Costs of logging, heating and lighting

– Costs of networking and communications
– Costs of other facilities
Costing & Pricing
• Estimates are made to discover the cost of
the developer to produce software
• There is not a simple relationship between
the development cost and the price charged to
the customer
UCSC - 2014 81
• Broader organizational, economic,

political and business considerations influence
the price charged
Productivity Measures
• Size related measures
– based on some output from the software process
- For example lines of delivered source code •
Function related measures
UCSC - 2014 82
– based on an estimate of the functionality

of the delivered software
– Function Points (FP) are the best known of this
type of measure
Cost Estimation Techniques
• Expert judgment
– Use expert knowledge
• Estimation by analogy
– Use past similar projects to do the estimation
• Function point analysis
UCSC - 2014 83
– Uses the requirements specification to assess

inputs, outputs, file accesses, user interactions and
interfaces and calculates the size based on these
• Algorithmic cost modeling
– Cost is estimated as a mathematical function of product
and process attributes
3. Project Scheduling
• Split project into tasks and estimate time and
resources required to complete each task
UCSC - 2014 84
• Organize tasks concurrently to make

optimal use of workforce
• Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete
UCSC - 2014 85
The Project Scheduling Process
UCSC - 2014 86
UCSC - 2014 87
Problems in Project Scheduling

• Estimating the difficulty of problems and
hence the cost of developing a solution.
• Productivity is not proportional to the
number of people working on a task.
• Adding people to a late project makes it later
because of communication overheads.
• The unexpected always happens therefore
allow contingency in planning.
UCSC - 2014 88
Bar Charts & Activity Networks

• These are graphical notations used to
illustrate the project schedule.
• They show project breakdown into tasks.
• Activity networks show task dependencies
and the critical path.
• Bar charts show schedule against calendar
time.
UCSC - 2014 89
4. Risk Management
• Risk management is concerned with
identifying risks and drawing up plans to
minimize their effect on a project.
• A risk is a probability that some adverse
circumstance will occur.
• The results of the risk analysis should be
documented in the project plan along with the
analysis of the consequences of risks occurring.
UCSC - 2014 90
Risk Categories
• Project risks
– affect the project schedule or resources
• Product risks
– affect the quality or the performance of the
software being developed
• Business risks
– affect the organization developing or procuring
the software
UCSC - 2014 91
Examples
UCSC - 2014 92
Risk Affects Description

UCSC - 2014
Staff turnover Project Experienced staff will leave the project before it is 93
finished.
Risk Management Process

• Risk identification
– Identify project, product and business risks;
• Risk analysis
– Assess the likelihood and consequences of these
risks;
• Risk planning
– Draw up plans to avoid or minimise the effects of
the risk;
UCSC - 2014 94
• Risk monitoring
– Monitor the risks throughout the project;
UCSC - 2014 95
Risk Management Process
UCSC - 2014 96
UCSC - 2014 97
Risk Identification
• May be a team activities or based on the individual project
manager’s experience.
• A checklist of common risks may be used to identify risks in a
project.
• Types of such risks are;
– Technology risks
– People risks
– Organizational risks
– Tool risks
– Requirements risks
– Estimation risks
UCSC - 2014 98
Risk Types
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per second as
expected. (1)
Reusable software components contain defects that mean they cannot be reused as
planned. (2)
People It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Organizational The organization is restructured so that different management are responsible for the
project. (6)
Organizational financial problems force reductions in the project budget. (7)
Tools The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)
Requirements Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Estimation The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
UCSC - 2014 99
Risk Indicators
UCSC - 2014 100

Risk type Potential indicators

UCSC - 2014
Technology Late delivery of hardware or support software; many reported technology101
problems.
Risk Analysis
• Assess probability and seriousness of each
risk
• Probability may be very low, low, moderate,
high or very high
• Risk consequences might be catastrophic,
serious, tolerable or insignificant
UCSC - 2014 102

Risk Analysis - Examples
UCSC - 2014 103

Risk Probability Effects

UCSC - 2014 104
Organizational financial problems force reductions in the Low Catastrophic
Risk Analysis - Examples
UCSC - 2014 105

Risk Probability Effects

UCSC - 2014 106
The time required to develop the software is underestimated High Serious
Risk Planning
• Consider each risk and develop a strategy to
manage that risk
• Avoidance strategies
– The probability that the risk will arise is reduced •
Minimisation strategies
– The impact of the risk on the project or product
will be reduced
• Contingency plans
UCSC - 2014 107

– If the risk arises, contingency plans are

plans to deal with that risk
Risk Monitoring
• Assess each identified risks regularly to
decide whether or not it is becoming less or
more probable.
• Also assess whether the effects of the risk
have changed.
UCSC - 2014 108

• Each key risk should be discussed at

management progress meetings.
UCSC - 2014 109

Risk Management Strategies
UCSC - 2014 110

Risk Strategy
UCSC - 2014 111
Organizational financial Prepare a briefing document for senior management
Risk Management Strategies
UCSC - 2014 112

Risk Strategy
UCSC - 2014 113
Organizational Prepare a briefing document for senior management
5. Team Management
• People are an organisation’s most important
assets.
• The tasks of a manager are essentially
peopleoriented.
• Unless there is some understanding of
people, management will be unsuccessful.
• Poor people management is an important
contributor to project failure.
UCSC - 2014 114

Team Management
• Most professional software is developed by
project teams ranging in size from two to
several hundred people.
• Each group is responsible for a sub project.
• As a general rule, software engineering
project groups should normally have no more
than eight members.
UCSC - 2014 115

People Management Factors

• Consistency
– Team members should all be treated in a comparable way without
favourites or discrimination.
• Respect
– Different team members have different skills and these differences
should be respected.
• Inclusion
– Involve all team members and make sure that people’s views are
considered.
• Honesty
– You should always be honest about what is going well and what is going
badly in a project.
UCSC - 2014 116

Selecting Staff
• An important project management task is
team selection.
• Information on selection comes from:
– Information provided by the candidates.
– Information gained by interviewing and talking
with candidates.
– Recommendations and comments from other
people who know or who have worked with the
candidates.
UCSC - 2014 117

Motivating People
• An important role of a manager is to motivate
the people working on a project.
• Motivation is a complex issue but it appears
that their are different types of motivation
based on:
– Basic needs (e.g. food, sleep, etc.);
– Personal needs (e.g. respect, self-esteem);
UCSC - 2014 118

– Social needs (e.g. to be accepted as part

of a group).
Personality Types
• The needs hierarchy is almost certainly an
oversimplification of motivation in practice.
• Motivation should also take into account
different personality types:
– Task-oriented;
– Self-oriented;
UCSC - 2014 119

– Interaction-oriented.
Personality Types
• Task-oriented
– The motivation for doing the work is the work itself;
• Self-oriented
– The work is a means to an end which is the achievement of
individual goals - e.g. to get rich, to play tennis, to travel
etc.;
UCSC - 2014 120

• Interaction-oriented
– The principal motivation is the presence and actions of
coworkers. People go to work because they like to go to
work.
Teamwork
• Most software engineering is a group activity
– The development schedule for most non-trivial software projects is
such that they cannot be completed by one person working alone
• A good group is cohesive and has a team spirit. The people

involved are motivated by the success of the group as well as
by their own personal goals.
• Group interaction is a key determinant of group performance
UCSC - 2014 121

• Flexibility in group composition is limited

– Managers must do the best they can with available people
Factors that influence group working

• Group composition
– Is the group composed of the right balance of skills, experience and
personalities?
• Group cohesiveness
– Does the group think of itself as a team rather than as a collection of
individuals who are working together?
• Group communications
– Do group members communicate with each other effectively?
UCSC - 2014 122

• Group organization
– Is the team organized in such a way that everyone feels valued and is
satisfied with their role in the group?
Group Composition
• Group composed of members who share the same
motivation can be problematic
– Task-oriented:- everyone wants to do their own thing;
– Self-oriented:- everyone wants to be the boss;
– Interaction-oriented:- too much chatting, not enough work.
• An effective group has a balance of all types

• This can be difficult to achieve as software engineers are
often task-oriented
UCSC - 2014 123

• Interaction-oriented people are very important as

they can detect and defuse tensions that arise
Group Cohesiveness
• In a cohesive group, members consider the group to be more
important than any individual in it.
• The advantages of a cohesive group are:
– Group quality standards can be developed by the group members.
– Team members learn from each other and get to know each other’s
work; Inhibitions caused by ignorance are reduced.
– Knowledge is shared. Continuity can be maintained if a group
member leaves.
– Refactoring and continual improvement is encouraged. Group
members work collectively to deliver high quality results and fix
UCSC - 2014 124

problems, irrespective of the individuals who originally

created the design or program.
Group Communications
• Good communications are essential for
effective group working.
• Information must be exchanged on the status
of work, design decisions and changes to
previous decisions.
• Good communications also strengthens group
cohesion as it promotes understanding.
UCSC - 2014 125

Group Communications
• Factors that affect to the group communications
are;
– Group size
• The larger the group, the harder it is for people to communicate with other
group members
– Group structure
• Communication is better in informally structured groups than in
hierarchically structured groups
– Group composition
• Communication is better when there are different personality types in a
group and when groups are mixed rather than single sex.
UCSC - 2014 126

– The physical work environment

• Good workplace organisation can help encourage communications
Group Organization
• The way that a group is organized affects the
decisions that are made by that group, the ways that
information is exchanged and the interactions between
the development group and external project
stakeholders
– Key questions include:
• Should the project manager be the technical leader of the group?
• Who will be involved in making critical technical decisions, and how will
these be made?
UCSC - 2014 127

• How will interactions with external stakeholders and senior

company management be handled?
• How can groups integrate people who are not co-located?
• How can knowledge be shared across the group?
Group Organization
• Small software engineering groups are usually
organised informally without a rigid structure.
• For large projects, there may be a hierarchical
structure where different groups are
responsible for different sub-projects.
UCSC - 2014 128

• Agile development is always based

around an informal group on the principle that
formal structure inhibits information exchange.
Informal Groups
• The group acts as a whole and comes to a consensus
on decisions affecting the system.
• The group leader serves as the external interface of
the group but does not allocate specific work items.
UCSC - 2014 129

• Rather, work is discussed by the group as a

whole and tasks are allocated according to ability and
experience.
• This approach is successful for groups where all
members are experienced and competent.
Working Environments
• Work place makes an important effect on worker’s
performance and their job satisfaction.
• The most important environmental factors
identified:
UCSC - 2014 130

– Privacy: Programmers require an area where

they can concentrate and work without interruption.
– Outside awareness: People prefer to work in natural light
and with a review of the outside environment.
– Personalization: Individuals adopt different working
practices and have different opinions on décor. The ability
to rearrange the workplace to suit working practices and to
personalize that environment is important.
Summary
• Good project management is essential if software
engineering projects are to be developed on schedule
and within budget.
UCSC - 2014 131

• Software management is distinct from other

engineering management. Software is intangible.
Projects may be novel or innovative with no body of
experience to guide their management.
• Software processes are not as mature as traditional
engineering processes.
Summary
• Cost estimating is one of the most important steps
in software project management, which are carried
out together with project scheduling.
UCSC - 2014 132

• There is not necessarily a simple relationship

between the price charged for a system and its
development costs.
• There are various techniques of software cost
estimation. In preparing an estimate, several different
techniques should be used. If the estimates diverge
widely, this means that inadequate estimating
information is available.
UCSC - 2014 133

Summary
• Risk management is now recognized as one of the
most important project management tasks.
• Risk management involves identifying and assessing
project risks to establish the probability that they will
occur and the consequences for the project if that risk
does arise.
• You should make plans to avoid, manage or deal
with likely risks if or when they arise.
UCSC - 2014 134

Summary
• Software development groups should be fairly small
and cohesive. The key factors that influence the
effectiveness of a group are the people in that group,
the way that it is organized and the communication
between group members.
• Communications within a group are influenced by
factors such as the status of group members, the size
of the group, the gender composition of the group,
personalities and available communication channels.
UCSC - 2014 135

Software Engineering 4 Maintenance Management PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering 4 Maintenance Management PDF

Uploaded by

Copyright:

Available Formats

IT3205: Fundamentals of

• Describe the software maintenance

7.1.2Maintenance prediction 7.1.3

7.1 EVOLVING NATURE OF

– New computers and equipment is added to the

• To maintain the value of these assets to the

A spiral model of Development and

Evolution and Servicing

Evolution and Servicing

• Change identification and evolution

Change Identification and Evolution

The Software Evolution Process

Change Impact Release Change System

Fault Release System

Urgent change requests

The emergency repair process

Analyze source Modify source Deliver modified

Program evolution dynamics

• Systems MUST be changed if they are to

Increasing As an evolving program changes, its structure tends to become more

Large program Program evolution is a self-regulating process. System attributes such

Applicability of Lehman’s laws

– Medium sized systems.

Reasons for changes

• The change in the business environment

• Changes are implemented by modifying

changes that environment and therefore

– Modifying the system to suit new operation environment

• Increases as software is maintained.

Reasons for high Maintenance cost

factor along with the lack of team stability,

• Re-engineering involves adding effort

– The system may be re-structured and re-documented to make it

Forward engineering and re-

The re-engineering process

Original Program Modularized

• Program structure improvement

Reengineering cost factors

• When you refactor a program, you should not add

Refactoring and reengineering

It is intended to avoid the structure and code

• Thousands of separate documents are generated for

3. The CM policies that are used for change control and

The configuration database

– What platform is required for a particular version?

• The CM database should preferably be linked to the so ware

The change management process

Change request form

• Examples of attributes are Date, Creator, Programming

• Lehman’s laws, such as the notion that change is

Software Project Management

• Describe the main phases of software

8.2.2 Estimating costs

8.1 NEED FOR THE PROPER

and in accordance with the requirements of

• Project management is needed because software

Software Management Distinctions

• Many software projects are 'one-off' projects

• Software processes are variable and organization specific

8.2 MANAGEMENT ACTIVITIES

• Various different types of plans may be

Contents of a Project Plan