SOFTWARE ENGINEERING

(KCS 601)

Lecture Notes

UNIT V – SOFTWARE MAINTENANCE

 Unit-5 Syllabus

Software Maintenance and Software Project Management: Software as an Evolutionary

Entity, Need for Maintenance, Categories of Maintenance: Preventive, Corrective and
Perfective Maintenance, Cost of Maintenance, Software Re- Engineering, Reverse
Engineering. Software Configuration Management Activities, Change Control Process,
Software Version Control, An Overview of CASE Tools. Estimation of Various Parameters
such as Cost, Efforts, Schedule/Duration, Constructive Cost Models (COCOMO), Resource
Allocation Models, Software Risk Analysis and Management.

SOFTWARE MAINTENANCE

“Software as an Evolutionary Entity.”

In a way changes made to the software can also be termed as Software Evolution.

Some of evolution laws are: -

i) Law of Continuing Change – This law states that any software system that represents some
real world reality undergoes continuous change or becomes progressively less useful in that
environment.

ii) Law of Increasing Complexity – This law states that as software evolves, its complexity
also increases. Hence, measures must be taken to simplify the structure.

iii) Law of Program Evolution – This law states that software evolution is self-regulating with
statistically determinable trends And Metrics.

iv) Law of Conservation of Organization Stability – This law states that during the active
lifetime of software system regardless of the resources used the work output is almost
constant.

v) Law of Conservation of Familiarity – This law states that during the active life time of the
program, change made in successive releases is almost constant. This is because each change
made in the system results into new faults in the system.

SOFTWARE MAINTENANCE –
“Software Maintenance is modification of a software process after delivery to correct faults, to
improve performance or other attributes, or to adopt the product to a modified environment”

Def – “software Maintenance is a set of activities performed when software undergoes

modifications to code & associate documentation due to a problem or the need for
improvement & adoption”.
AIMS OF SOFTWARE MAINTENANCE –
1) To enhance the software by changing its functions

2) To adopt the software to cope with changes in the environment.

3) To correct Errors.

4) To update the software in anticipation of future problems.

CATEGORIES OF SOFTWARE MAINTENANCE –

1) Corrective Maintenance

2) Adaptive Maintenance

3) Perfective Maintenance

4) Preventive Maintenance

CORRECTIVE MAINTENANCE –

It is also called Bug Fixing & deals with fixing the reporting errors.

Reporting errors can be –

a) Coding Errors

b) Design Errors

c) Requirement Errors

In this Requirement related errors are most expansive to correct because of the extensive
redesign involved.

ADAPTIVE MAINTENANCE –

It changes the system to reach to changes in the environment in which the system
operates e.g. porting to a new compiler, OS hardware.

It is generally not requested by client, rather it is imposed by the external environment

PREVENTIVE MAINTENANCE –

It involves the activities to update the software in anticipation of any future problems.

We use techniques like documenting, commenting or even re implementing some part

of software using modern software engineering tools & techniques.

PERFECTIVE MAINTENANCE-

It improves the efficiency and/ or effectiveness of the system, or improves the

maintainability.

This type of maintenance concerns improving the delivered software as a result of change in
user requirements or efficiency improvements.

Maintenance programmers or support engineers must have above average debugging skills.
Once an error has been located, the maintenance programs must correct the error without
introducing more errors, called regression errors.

Once an error has been corrected, the fix must be tested to make sure it does not introduce
any other side.

SOFTWARE MAINTENANCE COSTS –

Software maintenance costs are the greatest cost incurred in developing and using a software
crisis.

Maintenance costs vary widely from application to application but on average, they sum to
be between two and four times development costs for large embedded software systems.

Extra development effort is a -ve multiplier on maintenance costs. A % increase in

development costs, if it leads to a comparable percentage decrease in maintenance costs,
results in an overall saving.

Software Maintenance Cost Factors -

There are two types of cost factors involved in software maintenance. These are:

a) Non-Technical Factors

b) Technical Factors

i) NON TECHNICAL FACTORS –

a) Application Domain

b) Staff Stability

c) Program Lifetime

d) Dependence on External Environment

e) Hardware Stability

a) Application Domain -

 If the application of the program is clearly defined & well understood the system
requirements may be definitive & maintenance due to changing requirements
minimized.
 If the application is completely new, it is likely that the initial requirements will be
modified frequently, as users gain experience with the system.

b) Staff Stability -

 It is easier for the original writer of a program to maintain and change a program rather
than some other individual who will understand the program by studying of its
documentation & code listing.
 If the programmer of a system also maintains that system maintenance costs will be
reduced.
 c) Program Lifetime -

 The useful life of a program depends on its application.

 Programs become obsolete when the application becomes obsolete or their original
hardware is replaced & conversion costs exceed rewriting costs.
 The older a program, the more it has been maintained & the more degraded its
structure.

d) Dependence on External Environment –

 If a program is dependent on its external environment it must be modified as the
environment changes.
 A program used in a mathematical application does not normally depend on humans
changing the assumption on which the program is based.

e) Hardware Stability -

 If a program is designed to operate on a particular hardware configuration & that

configuration does not change during the program’s lifetime, no maintenance costs
due to hardware changes will be incurred.

ii) TECHNICAL FACTORS –

a) Module Independence

b) Programming Language

c) Programming Style

d) Programming Validation & Testing

e) Documentation

f) Configuration Management techniques

a) Module Independence-

It should be possible to modify one program unit of a system without affecting any
other unit.

b) Programming Language –

Programs written in High Level Language are usually easier to understand than
program written in Low Level Language.

c) Programming Style –

The way in which a program is written contributes to its understandability and hence
the ease with which it can be modified.

d) Program Validation & Testing –

Maintenance costs due to error correction are governed by the type of error to be
repaired.
e) Documentation –
If a program is supported by clear, complete documentation, the task of
understanding the program can be relatively straight forward.
Program maintenance costs tend to be less for well documented systems than for
systems supplied with poor or incomplete documentation.

f) Configuration Management Techniques –

One of the most significant costs of maintenance is keeping track all systems
documents & ensuring that these are kept consistent.
Effective configuration Management can help control this cost.

SOFTWARE RE- ENGINEERING –

The process of modifying the internal mechanisms of a system or program or the data
structures of a system or program without changing its functionality/
We can define re-engineering as process of replacing legacy systems with the system
which is easy to maintain and developed with latest technology.
Legacy Systems –
In initial years, there was no systematic approach to develop software. Now a days also many
organizations are using these software. It is not simply possible to reject the software because
they contain crucial information about organization. Such types of systems are called Legacy
Systems.

Benefits of Software Re Engineering –

i) Lower Costs – Reengineering an existing system costs less than new system development.
ii) Lower Risks – Software re- engineering is based on incremental improvement of
systems,rather than radial system replacement.
iii) Better Use of Existing Staff – Existing staff expertise can be maintained, extended and
accommodate new skills during software Re Engineering.
Incremental nature of reengineering means that existing staff skill can evolve as the
systemevolves.
iv) Incremental Development – Software Re engineering can be carried out in stages, as
budget & resources are available.
Operational organization always has a working system & end users are able to gradually
adapt to the reengineered as it is delivered in increments.
SOFTWARE RE- ENGINEERING PROCESS –

REVERSE ENGINEERING -

It is any activity that improves one’s understanding of software, prepares or improves

the software itself, usually for increased maintainability, reusability or evolvability.
Reverse Engineering has 2 step processes –
i) It analyses the subject system to identify its components & their interrelationships.
ii) It creates representations of the system in another form or at a higher abstraction
level.

GOALS OF REVERSE ENGINEERING –

Facilitating Software Reuse -
A Significant issue in the movement toward software reusability is the large body of
existing software assets.

Reverse engineering can help detect candidates for reusable software components
from present systems.
Coping with Complexity –

These methods & tools will provide a way to extract relevant information so decision
makers can control the process and the process and the product in systems evolution.

Generate Alternate Views –

Reverse engineering tools can generate additional views from many perspectives (like
DFD, CFD, Structure charts & ER diagrams) to add the review & verification process.

Recovering Lost Information -

Continuing Evolution of large & long lived Systems to loss by information about system
design. Modifications are frequently not reflected in documentation, particularly at a higher
level than the code itself.

Detecting Side Effects –

Both haphazard initial design & successive modifications can lead to unintended
consequences and side effect that impede system’s performance in several ways.

Synthesizing Higher Level Abstraction -

Reverse Engineering requires methods and techniques for creating alternate views
that transcend to higher abstraction levels.

REVESRSE ENGINEERING PROCESS –

1) Collecting Information – It collects Source code, design documents etc.

2) Examining the Information – The information collected is studied to get familiar with the
system.

3) Extracting the Structure – This step concerns with identification of program structure in
the from of structure chart where each node corresponds to some routine.

4) Recording the functionality – during this step processing details of each module of the
structure charts are recorded using structured language, PDL, Decision tables etc.

5) Recording Data Flow – DFDs are derived to show flow of data among the processes.

6) Recording Control Flow – high level Control Structure of the software is recorded.

7) Review Extracted Design – Design Document extracted is reviewed several times to ensure
consistency & correctness. It is also ensured that the design represents the program.

8) Generate Documentation – The complete documentation including SRS, Design Document

History, overview etc. Is recorded for future use.
SOFTWARE CONFIGURATION SYSTEM –

It is the art of identifying, organizing & controlling modifications to the software being built
by a programming team. The goal is to maximize productivity by minimizing mistakes.
Or
SCM is the process of defining & implementing a standard configuration that results into the
primary benefits such as easier set up and maintenance, less down time, better integration
with enterprise management and more efficient and reliable backups.

GOALS OF SOFTWARE CONFIGURATION MANAGEMENT –

 Software configuration management activities are planned.

 Selected software work products are identified , controlled & available.
 Changes to identified software work products are controlled.
 Affected groups & individuals are informed of the status and contents of software
baselines.
OBJECTIVES OF SOFTWRAE CONFIGURATION STANDARDS -

 Remote System Administration

 Reduced User Down Time
 Reliable Data Backups
 Easy workstations set up
 Multi user support
 Remote software Installation

Remote System Administration-

Configuration standard should include necessary software and /or privileges for
remote system administration tools. These remote tools can be used to check the version of
virus protection, check machine configuration, or after remote help desk functionality

Reduced User Down Time -

Great advantage of using a standard Configuration is that systems become
completely interchangeable resulting in reduced user down time.

Reliable Data Backups -

Using a standard directing for user data allows backup systems to selectively back up
a small portion of machines greatly reducing the network traffic & tape usage for backup
systems. A divided directory structure, between system & user data is one of the main goals
of the configuration standard.

Easy Workstation Set Up –

Any sort of standardized configuration streamlines the process of setting up the
system & insures that vital components are available. If multiple machines are being set up
according to a standard set up, most of the set up & configuration can be automated.

Muti User Support –

It is not common for users to share a workstation, the system configuration is
designed to allow multiple users to use the same workstations without interfacing with each
other’s work. Some software packages do not support completely independent settings for
all users, however, can have independent design areas.

Remote Software Installation-

Most modern between packages are installed in factor pre-defined directories. While
software installed in this manner will function correctly for a single user, it will lead to non-
uniform configuration among a collection of machines A good configuration will have
software installed in specified directly arears to logically divide software on the disk.
SOFTWARE CONFIGURATION MANAGEMENT (SCM) PLAN –
INTRODUCTION:

 Purpose
 Scope
 Definitions and Acronyms
 References

MANAGEMENT –

 Organisations
 Configuration Management Responsibilities
 Interface Control
 Implementation of software Configuration Management Plan
 Applicable Policies , Directives & Procedures.

CONFIGURATION MANAGEMENT ACTIVITIES –

 Configuration Identification
 Configuration Control
 Configuration Status Accounting
 Audits and Reviews.

TOOLS, TECHNIQUES & METHODOLOGIES

SUPPLIER CONTROL

RECORDS COLLECTION & RETENTION

CHANGE CONTROL –
 It involves procedures & tools to bring order to the change process.
 Larger projects have a formal Change Control Board(CCB) where responsibility is to
review & approve or disapprove change.
 It is the CCB responsibility to provide the mechanism to maintain orderly change
processes.

GOALS OF CHANGE CONTROL PROCEDURE -

 It provide a mechanism for accepting changes that improves the product overall
while rejecting those that degrade it.
 Facilitate changes to work products during their initial formative development while
avoiding unnecessary overhead or formality.
 Provide revision control & backup safety for work products during their formative
development.
 Allow for formal acceptance of work products after their initial formative
development has been completed.
 Allow all parties materially affected by proposed changes to accepted work products
to assess the resource, schedule and / or product impact of the changes.
 Provide a holistic trail of the development of work products, including all proposed
changes.

CHANGE CONTROL PROCESS –

 It ensures that changes to the system are controlled and that their effect on the
system can be predicted.
 To make a change, a change control form (CCF), or a software Problem report (SPR)
is filled out.
 The form contains data on estimation costs, the date when the change was requested,
approved, implemented & validated.
 The information on the form is defined in the SCM plan & it makes up much of the
information in the SCM database .Then this form is submitted by CCB for its validity
the impact of the change and the cost. The change is then approved, or disapproved
by the CCB.
 If it is approved it is applied to the software and regression testing is done to be sure
that the change has not affected other parts of the system.

SOFTWRAE VERSION CONTROL –

 Version Control combines procedures & tools that manage different versions of
configuration items that are created during the software engineering process.
 Each version of the software is a collection of software Configuration Items (Source
Code, Documents, and Data) and each version may be composed of different
variants.
  Version Control activity is split mainly in 4 sub sections.
o Identifying new versions
o Numbering schemes
o Visibility
o Tracking
IDENTIFYING NEW VERSIONS -

Software Configuration Item (SCI) will receive a new version number when there has
been a change to its established baseline.

“Baseline is a specification or product that has been formally reviewed & agreed upon, that
thereafter serves as the basis for further development, and that can be changed only through
formal Change Control Procedures”

Each previous version will be stored in a corresponding directory such as version 0, version 2,
……

NUMBERING SCHEME -

Numbering Scheme will have the following format – Version X,Y,Z………

X – It represents the entire SCI. Therefore, changes made to the entire configuration item, or
changes large enough to warrant a completely new release of the item, will cause the first
digit to increase.

Y – It represents a component of the SCI. The digit will sequentially increase if a change is
made to a component or small changes to multiple components.

Z – It represents a section of the component of a SCI. This number will only be visible if a
component of an SCI can be broken down into individual sections.
VISIBILITY -

Version number will be visible either in a frame or below the title. The decision for
this depends upon the group decision to code all documents for a frames capable browse or
allow for non-frames capable browser.

TRACKING-

The best way to keep track of the different versions is with a Version Evolution Graph
 CAPAPBILITIES OF A GOOD SCM TOOL –

 It manages versions throughout the development Life Cycle.

 Guarantee integrity of items.
 Support & manage Concurrent Development.
 Allow identification of all components that compromise a particular change or
version release.
 Provide automated version building capabilities.
 Provide audit facilities and reporting tools.

COCOMO (Constructive Cost Model) –

COCOMO was proposed by Bohem.

He postulated that there are essentially 3 important classes of software products.
 Organic
 Semidetached
 Embedded

These three product classes correspond to application utility and system programs
respectively.

It is often referred to in the literature on software project management, particularly in

connection with software estimating.

The definition of software Product is estimated as:

Organic – Relatively small groups working in a familiar environment to develop well

understood application programs.

Semidetached – Project teams consist of a mixture of experienced and inexperienced staff.

Team members have limited experience on related system and may be unfamiliar with some
aspects of the system being developed.

Embedded – The software is strongly coupled to complex hard ware , as where there are
stringent regulations governing the operational procedures.

According to Boehm, Software Cost estimation is done in three stages:

 Basic COCOMO
 Intermediate COCOMO
 Complete COCOMO
BASIC COCOCMO MODEL –
This model provides an approximate estimation of software Costs. It aims at estimating, in a
quick and Rough fashion, most of the small to medium sized software Projects.

The Basic COCOMO equations is –

E = ab (KLOC)b^b
D = Cb(E) db

E = Effort applied in Person Month &

D = Development time in month.

The coefficients ab, bb, cb and db are given as –

Project Ab Bb Cb Db
Organic 3.2 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32

INTERMEDIATE MODEL –

Basic Model allowed for a quick & rough estimate, but it resulted in a lack of accuracy.

Bohem introduced an additional set of 15 predictors called Cost drivers to take account of
software development environment.

Cost Drivers are used to adjust the nominal cost of a project to the actual project
environment, hence increasing the accuracy of the estimates.

Cost drivers are grouped into 4 categories –

I) Product Attributes –

a) Required Software Reliability (RELY)

b) Database Size (DATA)

c) Product Complexity(CPLX)

II) Computer Attributes –

a) Execution Time Constraint (TIME)

b) Main storage Constraint (STOR)

c) Virtual Machine Volatility(VIRT)

d) Computer Turnaround time(TURN)

III) Personal Attributes –

a) Analyst Capability(ACAP)

b) Application Experience (AEXP)

c) Programmer Capability (PCAP)

d) Virtual Machine Experience( VEXP)

e) Programming Language Experience (LEXP)

IV) Project Attributes –

a) Modern programming Practices (MOPP)

b) Use of software Tools(TOOL)

c) Required Development Schedule(SCED)

The cost drivers are rated as very low, low nominal, high, very high, extra high.

COST VERY LOW LOW NOMINAL HIGH VERY EXTRA

DRIVE HIGH HIGH
RELY 0.75 0.88 1.00 1.15 1.40 -
DATA - 0.94 1.00 1.08 1.16 -
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
TIME - - 1.00 1.11 1.30 1.66
STOR - - 1.00 1.06 1.21 1.56
VIRT - 0.87 1.00 1.15 1.30 -
TURN - 0.87 1.00 1.07 1.15 -
ACAP 1.46 1.19 1.00 .86 .71 -
AEXP 1.29 1.13 1.00 .91 .82 -
PCAP 1.42 1.17 1.00 .86 .7- -
VEXP 1.21 1.10 1.00 .90 - -
LEXP 1.14 1.07 1.00 .95 - -
MODP 1.24 1.10 1.00 .91 .82 -
TOOL 1.24 1.10 1.00 .91 .83 -
SCED 1.23 1.10 1.00 1.04 1.10 -

The multiplying factor of cost drivers are multiplied to get EAF (Effort Adjustment Factor).

The value range from 0.9 to 1.4

Equations are:

E = ab(KLOC) bb * EAF
D = Cb (E ) db
The value of Coefficient ai, bi,ci and di are

Object Ai Bi Ci Di
Organic 3.2 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32

DETAILED COCOMO MODEL –

This model introduces two more capabilities.
i) Phase Sensitive effort multiplier i.e. some phases are more affected than others by factors
defined by the cost drivers. This model helps in determining the manpower allocation for each
phase of the project.

ii) Three level product hierarchy i.e. three product level modules. Subsystem & system levels
are defined. The eating of cost drivers are done at appropriate level, i.e. level at which it is
more susceptible to variation.

QUESTION – Developing a system needs about 100,000 lines of code. Compute effort &
development cost for each of the three development modes.

Solution – BASIC COCOMO Equation

E = ab (KLOC)bb
D = cb(E ) db
Estimated size = 100 KLOC

For organic

E = 2.4 (100) 1.05c= 302.14 PM

D = 2.5(302.14).0.38 = 21.9 Months.

For semidetached

E = 3.0 (100) 1.12 = 521.34 PM

D = 2.5(521.34) .35 = 22.3 months

For Embedded –

E = 3.6(100) 1.2 = 904.28 PM

D = 2.5(904.28).32 = 22.07 MONTHS

RISK ANALYSIS MANAGEMENT –
SOFTWARE RISKS –

A software risk is a problem that could cause some loss or threaten the success of a
software project, but which hasn’t happened yet.

Risk in a project or program is a measure of the inability to achieve objectives within

cost, schedule & constraints.

Risk analysis & management are a set of steps that help the software team to
understand & manage uncertainty.

It is a problem which should be assesses and properly estimates its impact. The people
from the manager to the customer are involved in risk analysis & management.

First the risk is identified & it is analyzed from which point it can occur & what damage
it can cause. After thus the risk are ranked on the basis of probability.

And a plan is developed to manage those risks which have high impact on the software.

Software risks has two characteristics-

Uncertainty – Risk may happen or not, no 100% probable risk.

Loss – unwanted loss or consequence occur if risk becomes a reality.

REACTIVE AND PROACTIVE RISK STRATEGIES –

In reactive strategies, the software team does nothing until the risk arises & create
problem for them.

Resources are set aside and when actual problem arises the team came into action to correct
the problem arises the team came into action to correct the problem rapidly and is often
called “Fine Fighting Mode” i.e. action taken when problem arises. When the risk cannot be a
managed on time, the task is taken over by ‘crisis management’ and the project is now in real
jeopardy.

In proactive strategies, the task begin when the project start & technical work is initiated.
The risk are identified, probability assessed & ranked and a plan is established for managing
risk. Main emphasis should be to avoid risk, but a contingency plan is laid to control it when it
cannot be avoided.

PROJECT RISKS-

Effort the overall working of the project and it threaten the estimated cost & project schedule.
It can be budgetary, schedule, personal etc.

TECHNICAL RISKS -
It is a threat to quality and time. The product quality can be degraded if technical
problem arises during the cause of evolution. It can be potential design, implementation,
interface, verification & maintenance problem.
BUSINESS RISKS –

It can jeopardize the project or product and threaten the software in the business world.
Business & technical environment where the project is developed e.g. Poor development
environment, lack of documents etc.

PREDICTABLE RISKS –

It can be evaluated or traced from past project or experiences which undergo the
development, staff turnover, poor communication with customer etc.

UNPREDICTABLE RISKS – These are like uncertain problem which can or cannot arise during
the course of development and extremely difficult to identify them in advance.

SOFTWARE RISK MANAGEMENT –

It is the process of identifying software risks & planning to avoid these risks or to
minimize their effects if they cannot be avoided.

CHARACTERISTICS OF GOOD RISK MANAGEMENT APPROACHES -

There is a planned and documented risk management process for the project or
program.

The process is based on a prospective assessment. The project management team looks
ahead to find & manage possible problems.

The initial assessment is particularly redone to validate the initial findings & to uncover
new problem areas.

The program has a defined set of evaluation criteria that covers all facts of the program.

The ongoing results of the risk management process are formally documented.

RISK MANAGEMENT ACTIVITIES –

RISK ASSESMENT –
 RISK IDENTIFICATION
 RISK ANALYSIS
 RISK PRIORITIZATION

Risk identification –
It is a systematic attempt to specify threats to the project plan.

Purpose is to develop a list of risk items called risk statements.

It can be facilitated with the help of a checklist of common risk areas for software projects ,
by examining of common risk areas for software projects by examining the contents of an
organizational database of previously identified risks & mitigation strategies.

The main activities are:

a) Identify Risks

b) Define Risk Attributes

c) Document

d) Communicate

Risk analysis -
When the risks have been identified, all items are analyzed using different criteria.
The purpose of the Risk Analysis is to assess the loss probability & magnitude of each risk
item.

The input is the risk statement & context developed in the identification phase.

The output of this phase is a risk list containing relative ranking of the risks and a
further analysis of the description, probability, consequence & context.

The activities are:

Group similar Risks – detect duplicates & find new risk items by grouping the identified
risks into categories.

Determine Risk Drivers – These are parameters that affect the identified risk.

Determine Source Risks –

Estimate Risk Exposure – it is a measure of the probability & the consequence of a risk
item.

Evaluate against criteria – each risk item is evaluated using the predefined criteria,
which are important for the specific project.
Risk Prioritization -
It helps the project focus on its most secure risks by assessing the risk exposure.

Exposure is the product of the probability of incurring a loss due to the risk and the potential
magnitude of that loss.

Higher the exposure, the more aggressively the risk should be tackled. It may be easier to
simply estimate both probability & impact as high, medium or low. Those items having at
least one dimension rated as high are the ones to worry about first.

RISK CONTROL-
It is the process of managing risks to achieve devised outcomes.
Risk control process involves the following activities –
 Risk Planning
 Risk Mitigation
 Risk Resolution
 Risk Monitoring
Risk Planning – It is to identify strategies to deal with risk.

Risk Mitigation – it is a plan that would reduce or eliminate the highest risks.

It includes a description of the actions that can be taken to mitigate the red rated risk &
assigns a primary handler for the action.

Risk Resolution – it is the execution of the plans for dealing with each risk

Risk Monitoring – It is the continually researching of risks as the project proceeds &
conditions change.

RISK REPORTING -

It is reporting the status of the risks that were identified during risk identification &
assessment stages.

All types of risks along with their status are reported properly as part of risk
reporting activity

The entire information about risks is documented together with the full history of
risks such as name of the risks, a risk statements, context etc.
 CASE TOOLS
CASE TOOLS (COMPUTER AIDED SOFTWARE ENGINEERING) TOOLS –
These are software programs that are designed to assist human programmers with
the complexity of the processes & the artifacts of software Engineering. CASE tools support
almost all the phases of the SDLC such as analysis design etc.

 Most of the CASE tools include one or more of the following types of tools.
 Analysis Tools
 Repository to store all diagrams , models, report definitions etc,
 Diagramming tools
 Screen & report Generations
 Code Generator
 Documentation Generators
 Reverse Engineering tools
 Re engineering tools

BENEFITS OF CASE TOOLS -

 Improved productivity.
 Better documentation.
 Reduced Lifetime Maintenance.
 Improved Accuracy.
 Opportunity to Non-Programmers.
 Intangible Benefits.

TYPES OF CASE TOOLS –

 Upper CASE tools

 Lower CASE Tools
 Integrated CASR Tools

UPPER CASE TOOLS / FRONT END CASE TOOLS –

These tools mainly focus on the analysis & design phases of software development.

They include tools for analysis modelling, reports & forms generation.

LOWER CASE TOOLS / BACK END CASE TOOLS –

These tools support implementation of system development.

They include tools for coding, configuration Management etc.

INTEGRATED CASE TOOLS –

These tools help in providing linkages between the lower & upper CASE Tools.
Thus, creating a cohesive environment for software development where programming by lo
Thus, creating a cohesive environment for software development where programming by
lower CASE tools may automatically be generated for the design that has been developed in
as UPPER CASE tool/

The software development process is expensive and as the projects become more complex
in nature the project, implementation become more demanding & expensive

The CASE tools provide the development of complex projects.

FAILURE OF CASE TOOLS -

CASE tools often fail due to following reason

 Low management involvement

 Unrealistic Expectations
 No standard of methodology
 Misuse of CASE Tools
 Looking at CASE as a risk element
 Too much emphasis on tools as total solution

SOFTWARE PROJECT MANAGEMENT –

PROJECT – It can be defined as “an enterprise carefully planned to achieve a particular aim”.

Project Management – It is therefore defined as system of management procedures,

techniques, and resources, know how, technology etc. required for successful management
of the project. If the final product of the project is software, it is called software project
management.
PROJECT MANAGEMENT PROCESS –

1) Feasibility Study

2) project Planning

3) Project Execution

4) Project Termination

1) Feasibility Study – this phase of the project management process does necessary
investigation to ensure that the project is worth considering & stailing.

2) Project Planning – Planning involves making a detailed plan to achieve the objectives

Some steps for project planning are: -

i) Select project
ii) Identify project scope and objectives.

iii) Identify project infrastructure

 iv) Analyze project characteristics

v) Identify project products and activities

vi) Estimate effort for each activity

vii) Identify activity risks

viii) Allocate resources

ix) Review plan

x) Execute plan

xi) Lower Levels of planning

PROJECT EXECUTION -

Once the proper project planning is done, project can be executed by selecting appropriate
process models.

PROJECT TERMINATION -

Projects can be terminated successfully & unsuccessfully also.

Successful projects are the ones which meet their objectives well within budget and schedule

Some of the reasons which result into unsuccessful termination or close-down budget and
schedule.

i) Inconsistency between project & organizational goals.

ii) Customer no longer interested in the product

iii) Fast changing technology

iv) Too much change in requirements by the customer

v) Current state of the art technology no longer suitable for the project

vi) Project running out of time

vii) Project exceeding budget or funds

viii) Project not meeting customer requirements

ix) Organizational politics