Software Engineering Paradigms : Software Characteristics, Software

myths, Software Applications, Software Engineering Definitions, Various

Software Process Models, Process iteration, Process activities, The Rational
Unified Process, Computer-aided software engineering

Project Management, Management activities, Project planning, Project

scheduling, Risk management

Software Requirements, Functional and non-functional requirements, User

requirements, System requirements, Interface specification, software
requirement document

Requirements Engineering Processes, Feasibility studies, Requirements

elicitation and analysis, Requirements validation, Requirements
management

System Models, Critical Systems Specification, Risk-driven specification,

Safety specification, Security specification, Software reliability
specification

Software Metrics and Measures — Process Metrics, Project metrics,

Software Project Planning, Empirical, Putnam, COCOMO. Risk Identification
and Projection: RMMM, Project Scheduling and Tracking.

Application Architectures — Data processing systems, Transaction

processing systems, Event processing systems, Language processing
systems, User Interface Design — Design issues, The user interface design
process, User analysis, User interface prototyping, Interface evaluation

Rapid Software Development — Agile methods, Extreme programming,

Rapid application development, Software prototyping. Software Reuse —
Design patterns, Generator-based reuse, Application frameworks,
Application system reuse, Software Evolution Verification and validation,
Verification and Validation — Planning verification and validation,
Software inspections, Automated static analysis, Verification and formal
methods.

Software Testing — System testing, Component testing, Test case design,

Test automation. Software Cost Estimation — Software productivity,
Estimation techniques, Algorithmic cost modeling, Project duration and
staffing.

Quality Management — Process and product quality, Quality assurance

and standards, Quality planning, Quality control, Software measurement
and metrics

Process Improvement — Process and product quality improvement,

Process classification, Process measurement — Process analysis and
modeling, Process change, The CMMI process improvement framework.
1. 0 Software Engineering Paradigms
1.1 Software Characteristics : Set of instructions written in a sequence to carry
out any specific task is called Program. Set of such programs is called software. It also
includes data structures that enable the programs to adequately manipulation information
and documents that describe the operation and use of the programs. Software is logical
rather than physical system element. It possess the following characteristics :
• Software is developed or engineered, it is not manufacture in the classical sense.
Therefore some separate care is to be done for its development.
• Software does not wear out but it detoriates. The failure rate of hardware is bit
high where as that of the software is not high. The failure curve of hardware is
represented using bathtub curve. Software is not susceptible to environment
maladies that causes hardware to wear out.

Failure Rate
Failure Rate

Wear Out

Ideal Curve

Time Time
Failure Curve for Hardware Failure Curve for Software

• Although the industry is moving toward component based assembly, most

software continues to be custom built.

1.2 Software Myths : There are some mis-conception about Software called
software Myths. The software myths propagate misinformation and confusions. These
myths ar classified into three categories viz. Management Myths, Customer Myths and
Practitioner’s Myths.

a. Management Myths : The Manager with software responsibility are under

pressure to maintain budgets, keep schedule etc. Some of the myths related to this
categories are as follows :
• There is a book consisting of standard procedure for building software. It
will be sufficient for the development of the software. (As a real fact it is yet
to determine that practioners are aware of it or not. Does it reflect modern
development proccedures or not etc.)
• State-of-art software development tools are available. (As a real fact the
development professionals even require it to use them efficiently, simple
availability will not be sufficient.)
• If the development is lacking its schedule then by arranging more
programmmer will catch the schedule properely. (As a real fact adding more
programmer at later stage will add more delay in it.)
 • By outsourcing the software development, the manager can get relax. (As
a real fact the manager will now be in more trouble).
b. Customer Myths : These Myths leads to false expactation and ultimately results
in dis-satisfaction. There are following myths of this nature.
• A general statement of objectives is sufficient to begin writing of
programs and the details can be filled later. (As a real fact the poor definition
always results in improper development.)
• The project’s requirement regularly change and these changes can easily
be accomodated later. (As a real fact no ammendments are practically possile
after development of the software.)
c. Practioner Myths : Following are some myhs of this nature.
• Once a program is written and has started to work then the job is over. (As
a real fact the job of maintenance starts at this stage).
• The qualiy of software can be assessed only after its development. (As a
real fact the quality can be anticipated before its development).
• Software engineering will create un-necessary documentation. (As a real
fact documents created are all essential).

1.3 Software Application : The software may be applied to many segments of our
life. Information contents and determinancy are two important factors used to determine
nature of software application. Contents refers to the meaning and form of incomming
and out going information. Information determinancy refers to the predictability of the
order and timing of information. Following are the area of application for software.
• System Software : System software is a collection of programs written toservice
other programs. e.g. compilers, editors, operating systems, linkers, loaders,
drivers etc. The system software are characterized by heavy interaction with the
computer hardware, heavy usange by multi users, concurrent operation etc.
• Real-Time Software : The softwares which controls the events / data as and
when they occurs are called real-time softwares. Hence these software are
characterized by quick response or reaction without any delay.
• Business Software : It is the larges application area. Various tasks of business
like payroll, inventory, accounting and different MIS softwares as per
requirements are some of the examples of this nature.
• Engineering and Scientific Software : These software ar characterized by
number crunching algorithms. These software performs large complicated
operation with a set of small data. E.g. CAD, CAM etc.
• Embeded Software : These softwares rside in the read only memory provided
with the industrial product. Generally these softwares are used to automate the
operations of the product. E.g. automation of washing machine, microware oven
etc.
• Personel Computer Software : Some applications like word processing, spread
sheets, graphics, multi-media, DBMS etc are examples of personnel computer
softwares.
• Web-based software : Various web enabled softwares which supports the user to
interact with the system by providing the data and getting required results. E.g.
online banking etc. These software are in the form of a collection of web pagaes.
 • Artificial Intelligence software : These softwares make use of non-numerical
algorithms to solve complex problems. E.g. Expert System, Neural Networks,
various games are some of the examples of such softwares.

1.4 Software Engineering :

Definition : Software engineering (SE) is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of software. It is
an engineering discipline that is concerned with all aspects of software production.
Software engineering is the establishment and use of sound engineering principles in
order to economically obtain software that is reliable and works efficiently on real
machines.

Software Engineering includes knowledge, tools, and methods for defining software
requirements, and performing software design, computer programming, user interface
design, software testing, and software maintenance tasks. It also draws on knowledge
from fields such as computer science, computer engineering, management, mathematics,
project management, quality management, software ergonomics, and systems
engineering.

Need : Software is often

found in products and
situations where very high
reliability is expected, even
under demanding conditions,
such as monitoring and
controlling nuclear power
plants, or keeping a modern
airliner aloft. Such
applications contain millions
of lines of code, making them comparable in complexity to the most complex modern
machines. For example, a modern airliner has several million physical parts (and the
space shuttle about ten million parts), while the software for such an airliner can run to 4
million lines of code.
Without using software engineering principles it would be difficult to develop large
programs. In industry it is usually needed to develop large programs to accommodate
multiple functions. A problem with developing such large commercial programs is that
the complexity and difficulty levels of the programs increase exponentially with their
sizes as shown in the following figure.

For example, a program of size 1,000 lines of code has some complexity. But a program
with 10,000 LOC is not just 10 times more difficult to develop, but may as well turn out
to be 100 times more difficult unless software engineering principles are used. In such
situations software engineering techniques come to rescue. Software engineering helps to
reduce the programming complexity.
Hence to make the taks simple and less complex the software engineering principles are
employed which helps the developer to improve quality of the software product as well as
productivity of development team.

Software engineering principles: These principles use two important techniques

to reduce problem complexity: abstraction and decomposition.

The principle of abstraction implies that a problem can be simplified by omitting

irrelevant details. In other words, the main purpose of abstraction is to consider only
those aspects of the problem that are relevant for certain purpose and suppress other
aspects that are not relevant for the given purpose. Once the simpler problem is solved,
then the omitted details can be taken into consideration to solve the next lower level
abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the
problem.

Fig. : A hierarchy
of abstraction

The other approach to tackle problem complexity is decomposition. In this technique, a

complex problem is divided into several smaller problems and then the smaller problems
are solved one by one. However, in this technique any random decomposition of a
problem into smaller parts will not help. The problem has to be decomposed such that
each component of the decomposed problem can be solved independently and then the
solution of the different components can be combined to get the full solution. A good
decomposition of a problem is as shown in the following figure. It should minimize
interactions among various components. If the different subcomponents are interrelated,
then the different components cannot be solved separately and the desired reduction in
complexity will not be realized.

Fig. : Decomposition of a large problem into a set of smaller problems.

1.5 Causes of and solutions for software crisis : Software engineering appears
to be among the few options
available to tackle the present
software crisis. To explain the
present software crisis in simple
words, consider the following. The
expenses that organizations all
around the world are incurring on
software purchases compared to
those on hardware purchases have
been showing a worrying trend over
the years as shown in the following
figure.

Organizations are spending larger and larger portions of their budget on software. Not
only are the software products turning out to be more expensive than hardware, but they
also present a host of other problems to the customers: software products are difficult to
alter, debug, and enhance; use resources non-optimally; often fail to meet the user
requirements; are far from being reliable; frequently crash; and are often delivered late.
Among these, the trend of increasing software costs is probably the most important
symptom of the present software crisis. Remember that the cost we are talking of here is
not on account of increased features, but due to ineffective development of the product
characterized by inefficient resource usage, and time and cost over-runs.
There are many factors that have contributed to the making of the present software crisis.
Factors are larger problem sizes, lack of adequate training in software engineering,
increasing skill shortage, and low productivity improvements.

1.6 Program vs. software product : The following table shows a comparision
between program and software product.

Program Software Product

It is developed by individuals for their It is developed by a Team of experts.
personal use
Small in size and have limited functionality Extremely large and full fills requirements
of the entire organization.
The programmer himself is the sole user Most users are not involved with the
development.
The user interface may not be very User interface must be carefully designed
important, because the programmer is the and implemented because developers of
sole user that product and users of that product are
totally different
Very little documentation is expected. It must be well documented
It can be developed according to the It must be developed using the accepted
programmer’s individual style of software engineering principles.
development,
1.7 Process : Software Engineering is a layered technology. The following diagram
shows the layered approach of software engineering.

Tools
Methods
Process

A quality Focus
The engineering approach, including software engineering generally rests on quality
commitment. The major point that supports software engineering is quality focus. The
foundation for software engineering is the process layer. It holds technology layers
together. It defines a framework for key process areas. Software engineering methods
provide the technical way for development of the software. Software engineering tools
provide automated or semi-automated support for process and methods.

Thus process is framework consisting of a number of task sets each consisting of work
tasks, project milestone, work products and quality assurance point.

Process Models : It is also called software engineering paradigm. It is an approach

used by software engineer which encompasses process, methods and tools. There are
many types of process models available. Some of then are as follows :

• Linear Sequential Model : This is similar to classical life cycle approach. It has a
linear sequential approach for development of the software. The phases of software
development are used one
after another in a sequential
manner. The following
diagram shows this model.
System / Information
Engineering : It encompasses Test
Design
System / Information
Analysis Code
requirements gathering and Engineering
system view to interact with
hardware and other components
of the system.
Analysis : It is Software
Requirement Analysis. It
supports to understand the
nature of programs to build, function and behaviour of the software to be built etc.
Design : It focuses on Data Structure, software architecture, interface and various
procedures.
Coding : It is concerned about writing programs for the software.
Testing : It focuses on logical internals of software. It ensures that the statement of
programs will perform correct output when used.
• Prototyping Model : If a customer defines a set of general objectives but does not
include details, the developer is not sure about efficiency of the programs and its
adoptability by the operating system, or when developer is not very much aware of
type of software and customer is not aware of development strategies then in such
cases it is better to have
prototyping paradigm. It is as
shown in the following diagram :

Prototyping Paradigm begins with Listen to Build / Revise

requirements gathering. The Customer Mockup
developer and the customer both
jointly define the overall objectives
of the software. A quick design leads
to construction of a prototype. The
prototype is evaluated by the
customer / user and used to refine the
software to be developed. The Customer Test
Drive Mockup
process is iteratively repeated till the
satisfaction of the customer.

A prototype is a toy implementation of the system. A prototype usually exhibits limited

functional capabilities, low reliability, and inefficient performance compared to the actual
software. A prototype is usually built using several shortcuts. The shortcuts might involve
using inefficient, inaccurate, or dummy functions. The shortcut implementation of a
function, for example, may produce the desired results by using a table look-up instead of
performing the actual computations. A prototype usually turns out to be a very crude
version of the actual system.

There are several uses of a prototype. An important purpose is to illustrate the input data
formats, messages, reports, and the interactive dialogues to the customer. This is a
valuable mechanism for gaining better understanding of the customer’s needs:

• how the screens might look like

• how the user interface would behave
• how the system would produce outputs

This is something similar to what the architectural designers of a building do; they show
a prototype of the building to their customer. The customer can evaluate whether he likes
it or not and the changes that he would need in the actual product. A similar thing
happens in the case of a software product and its prototyping model.

Another reason for developing a prototype is that it is impossible to get the perfect
product in the first attempt. Many researchers and engineers advocate that if you want to
develop a good product you must plan to throw away the first version. The experience
gained in developing the prototype can be used to develop the final product.

A prototyping model can be used when technical solutions are unclear to the
development team. A developed prototype can help engineers to critically examine the
technical issues associated with the product development. Often, major design decisions
depend on issues like the response time of a hardware controller, or the efficiency of a
sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way
to resolve the technical issues.
Team #1 Team #2
• RAD Model : It is Team #3
called Rapid
Application Business Business
Development Modeling Modeling Business
Model. It is high Modeling
speed adoption of
the linear sequential Data Data
Modeling Modeling Data
model. The
Modeling
activities are
accomplished using
component based Process Process
Modeling Modeling Process
construction. Modeling
Multiple RAD
teams works on
different Application Application
Generation Generation Application
components and due
Generation
to parallel work the
software is
developed quickly. Testing Testing
The following Testing
diagram shows the
RAD Model :

• Incremental Model : It is a kind of Evolutionary software process Model. The

evolutionary software process models are iterative. The linear model cpmbines
elements of the linear sequential model with iterative methodology. In the first
increment, basic requirements are addressed. Therefore it is called core product. But
later on many supplementary features are added. The following diagram shows the
incremental model.

System / Information
Increment-1
Analysis Engineering Design Code Test

Analysis Design Code Test Increment-2

Analysis Design Code Test Increment-3

Increment-4
Analysis Design Code Test
• Spiral Model : The Spiral model of software development is shown in the following
figure. The diagrammatic representation of this model appears like a spiral with many
loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral
represents a phase of the software process. For example, the innermost loop might be
concerned with feasibility study. The next loop with requirements specification, the
next one with design, and so on. Each phase in this model is split into sectors. These
sector are numbered from 3 to 6. The following activities are carried out during each
phase of a spiral model.
• Customer Communication : Effective communication between customer
and developed is maintained at his point.
• Planning : Tasks required to define resources, timeliness, and other project
related information are carried out at this point.
• Risk Analysis: Technical and Management risks are evaluated at this point
• Engineering : One or more representation of the application is created.
• Construction and Release : Testing, installation etc are varied out at this
point.
• Customer Evaluation : Customer feedback is obtained.

The spiral model is called a meta model since it encompasses all other life cycle
models. Risk handling is inherently built into this model. The spiral model is suitable for
development of technically challenging software products that are prone to several kinds
of risks. However, this model is much more complex than the other models – this is
probably a factor deterring its use in ordinary projects.
1.8 Process Iteration : System requirements ALWAYS evolve in the course of a project
so process iteration where earlier stages are reworked is always part of the process for
large systems. Iteration can be applied to any of the generic process models like
Incremental development, Spiral development.

Process Activities : The process is the foundation layer for software. It defines a
framework for a set of key process areas which are used to deliver effective software
engineering technology. These key process areas are sufficient enough for management
to control the over all development of the software. The major process activities include :

• Elicitation
• Requirements Process, Such As Marketing
• Feasibility Studies.
• Analysis
• Specification
• Design
• Testing and Validation

1.9 Computer Aided

Software Engineering Project
Managemen
(CASE) : A CASE Coding and t Facilities
Support Prototyping
(Computer Aided Software Activity
Engineering) tool is a generic
term used to denote any form Consistency
and Configuratio
of automated support for Complete n
Management
software engineering. In a Analysis
Facilities
more restrictive sense, a
CASE tool means any tool Document
Structured
used to automate some activity Generation Diagram
Central
associated with software Repository Facilities
development. Many CASE
tools are available. Some of Document
these CASE tools assist in Generation
Query &
phase related tasks such as Report
specification, structured Transfer Facilities
Structured facility in
analysis, design, coding, Analysis different
testing, etc.; and others to non- Facilities format
phase activities such as project
management and configuration management. The primary reasons for using a CASE tool
are:
• To increase productivity
• To help produce better quality software at lower cost

Although individual CASE tools are useful, the true power of a tool set can be realized
only when these set of tools are integrated into a common framework or environment.
CASE tools are characterized by the stage or stages of software development life cycle on
which they focus. Since different tools covering different stages share common
information, it is required that they integrate through some central repository to have a
consistent view of information associated with the software development artifacts. This
central repository is usually a data dictionary containing the definition of all composite
and elementary data items. Through the central repository all the CASE tools in a CASE
environment share common information among themselves. Thus, a CASE environment
facilitates the automation of the step-by-step methodologies for software development. A
schematic representation of a CASE environment is shown in the following figure.

Benefits of CASE : Some of those benefits are as follows :

• A key benefit arising out of the use of a CASE environment is cost saving through
all development phases. Different studies carry out to measure the impact of CASE
put the effort reduction between 30% to 40%.

• Use of CASE tools leads to considerable improvements to quality. This is mainly

due to the facts that one can effortlessly iterate through the different phases of
software development and the chances of human error are considerably reduced.

• CASE tools help produce high quality and consistent documents. Since the
important data relating to a software product are maintained in a central repository,
redundancy in the stored data is reduced and therefore chances of inconsistent
documentation is reduced to a great extent.

• CASE tools take out most of the drudgery in a software engineer’s work. For
example, they need not check meticulously the balancing of the DFDs but can do it
effortlessly through the press of a button.

• CASE tools have led to revolutionary cost saving in software maintenance efforts.
This arises not only due to the tremendous value of a CASE environment in
traceability and consistency checks, but also due to the systematic information
capture during the various phases of software development as a result of adhering to
a CASE environment.

• Introduction of a CASE environment has an impact on the style of working of a

company, and makes it oriented towards the structured and orderly approach.

Structured analysis and design with CASE tools : Several diagramming techniques
are used for structured analysis and structured design. The following supports might be
available from CASE tools.
• A CASE tool should support one or more of the structured analysis and design
techniques.
• It should support effortlessly drawing analysis and design diagrams.
• It should support drawing for fairly complex diagrams, preferably through a
hierarchy of levels.
• The CASE tool should provide easy navigation through the different levels and
through the design and analysis.
• The tool must support completeness and consistency checking across the design
and analysis and through all levels of analysis hierarchy. Whenever it is possible,
 the system should disallow any inconsistent operation, but it may be very difficult
to implement such a feature. Whenever there arises heavy computational load
while consistency checking, it should be possible to temporarily disable
consistency checking.

Code generation and CASE tools : As far as code generation is concerned, the general
expectation of a CASE tool is quite low. A reasonable requirement is traceability from
source file to design data. More pragmatic supports expected from a CASE tool during
code generation phase are the following:
• The CASE tool should support generation of module skeletons or templates in one
or more popular languages. It should be possible to include copyright message,
brief description of the module, author name and the date of creation in some
selectable format.
• The tool should generate records, structures, class definition automatically from
the contents of the data dictionary in one or more popular languages.
• It should generate database tables for relational database management systems.
• The tool should generate code for user interface from prototype definition for X
window and MS window based applications.

Test case generation CASE tool : The CASE tool for test case generation should have
the following features:
• It should support both design and requirement testing.
• It should generate test set reports in ASCII format which can be directly imported
into the test plan document.

Following is a table consisting of various tools used in different process activities at

various levels of the software management :
Tool type Examples
Planning Tools PERT tools, Estimation tools and Spread Sheets
Editing Tools Text Editors, Diagram Editors and word Processors
Change Management Requirements Traceable tools, change control systems
Tools
Configuration Version management tools, system building tools
management tools
Prototyping tools Very high level language tools, user interface generators
Method support tools Design editors, data dictionary, code generators
Language processing tools Compilers, interpreters etc.
Program Analysis Tools Cross Reference generator, Static analyzer, Dynamic
analyzer
Testing Tools Test Data generator, filecomparator etc.
Debugging Tools Interactive Debugging systems
Documentation Tools Page Layout programs, image editors
Re-engineering Tools Cross Reference systems, Program Re-structuring Systems
 Project Management

The software project management is helpful in controlling budget and schedule

considerations. Therefore the Software engineering managers and leaders shall subscribe
to and promote an ethical approach to the management of software development and
maintenance. Software engineering is different from other types of engineering project in
the following manner :
• The software project is intangible. The development of the software cannot be
seen physically nor it can be touched. The software manager simply relay on the
documentation prepared during its development of various activities.
• There are no standard software processes.
• Large software are often “one-off” projects.
Effective software project management focuses on the four P’s: people, product, process,
and project.

Management Activities : The job of a software manager is versatile. It cannot be

fixed.
• Proposal writing
• Project planning and scheduling
• Project costing
• Project monitoring and reviews
• Personnel selection and evaluation
• Report writing and presentations

Following are the management commonalities :

• These activities are not peculiar to software management
• Many techniques of engineering project management are equally applicable to
software project management
• Technically complex engineering systems tend to suffer from the same problems
as software systems

Following considerations are taken care off for staff engaged in project management.
• May not be possible to appoint the ideal people to work on a project
o Project budget may not allow for the use of highly-paid staff
o Staff with the appropriate experience may not be available
o An organization may wish to develop employee skills on a software
project
• Managers have to work within these constraints especially when (as is currently
the case) there is an international shortage of skilled IT staff

Project planning : Project planning includes the following :

• Probably the most time-consuming project management activity

• Continuous activity from initial concept through to system delivery. Plans must be
regularly revised as new information becomes available
 • Various different types of plan may be developed to support the main software
project plan that is concerned with schedule and budget. Some of the plans are as
shown in the following table :

Project planning process is as shown below :

• Establish the project constraints

• Make initial assessments of the project parameters
• Define project milestones and deliverables
• while project has not been completed or cancelled loop
o Draw up project schedule
o Initiate activities according to schedule
o Wait ( for a while )
o Review project progress
o Revise estimates of project parameters
o Update the project schedule
o Re-negotiate project constraints and deliverables
o if ( problems arise ) then
 Initiate technical review and possible revision
o end if
• end loop

Project plan structure is as follows :

• Introduction
• Project organisation
• Risk analysis
• Hardware and software resource requirements
 • Work breakdown
• Project schedule
• Monitoring and reporting mechanisms

Activity organization
• Activities in a project should be organised to produce tangible outputs
for management to judge progress
• Deliverables are project results delivered to customers
• The waterfall process allows for the straightforward definition of
progress milestones
• Milestones are the end-point of a process activity. The following
diagram shows some milestones in a project.

Project scheduling : Project scheduling includes the followings :

• Split project into tasks and estimate time and resources required to
complete each task
• Organize tasks concurrently to make optimal use of workforce
• Minimize task dependencies to avoid delays caused by one task
waiting for another to complete
• Dependent on project managers intuition and experience
Scheduling problems
• Estimating the difficulty of problems and hence the cost of developing
a solution is hard
• 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. Always allow contingency in
planning

Bar charts and activity networks

• Graphical notations used to illustrate the project schedule
• Show project breakdown into tasks. Tasks should not be too small.
They should take about a week or two
• Activity charts show task dependencies and the the critical path
• Bar charts show schedule against calendar time

Following table shows various tasks and their dependencies :

The following diagram shows an activity network :
The following diagram shows activities timelines:

The following diagram shows the allocation of staff :

Risk Management : The software manager anticipates various risks which might
affect the project schedule or the quality. He / She also takes some actions to avoid these
risks. Identifying the risks and drawing up plans to minimize the effect of these risks on
the project is called Risk Management. The risks can be broadly be divided in to three
categories.

• Project risks : Which affects the schedule or resources of the project.

• Product Risks : which affects the quality of the software product.
• Business Risks : which affects the organization developing the software.

The following table shows various types of risks along with their category.

Risk Risk Type Description

Staff Turnover Project Experienced staff will leave the project
before its completion.
Management Change Project Team members of the management has been
changed
Hardware Project The requires hardware may not be available
Unavailability in the market.
Requirements Change Project & There is a large no. of changes in the
Product requirements.
Specification Delays Project & Specification f essential interfaces are not
Product available on schedule.
Size underestimate Project & The size of the system has been
Product underestimated.
CASE tool Product CASE tools do not perform as it was
underperformance anticipated
Technology Change Business There is a drastic change in the technology
Product competition Business Another identical product is available in the
market.

The entire process of risk management involves various stages. These are Risk
identification, risk analysis, risk planning and risk monitoring. It is shown as follows :

Risk
Risk Risk Risk
Identificati
Analysis Planning Monitoring
on

Risk avoidance
List of potential Prioritized Risk
and contingency Risk Assessment
risks Kist
plans
 • Risk Identification : It is the first stage.

Technology risks The database used in the system cannot process as many
transaction as expected.
People risks It is impossible to recruit staff with skill required.
Organizational risks The organization is restructured. Hence Management has been
changed
Tools Risks The CASE tools are inefficient
Requirement Risks There is a change in the requirements
Estimation Risks The Time, Rate and size of the software is underestimated.

• Risk Analysis : Each identified risk is considered to judge its seriousness. The
judgment of the risk is converted into a numeric figure.
Very Low : < 10%
Low : 10 – 25 %
Moderate : 25 – 50%
High : 50-75%
Very High : > 75%

The effect of the risk might be assessed as catastrophic, serious, tolerable or

insignificant. The result of such analysis is tabulated. The following table shows an
example of the risk analysis.

Risk Probability Effects

Organizational Financial problems forces reductions Low Catastrophic
in the project budget.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project Moderate Serious
Software components which should be reused contain Moderate Serious
defects which limit their functionality
Changes to requirement which require major design Moderate Serious
rework are proposed
Organization is restructured so that different High Serious
management are responsible for the project
The database used in the system cannot process as Moderate Serious
many transactions per second as expected
The tie required to develop the software is High Serious
underestimated
CASE tools cannot be integrated High Tolerable
Required training for staff is underestimated Moderate Tolerable
Customer failed to understand the impact of change Moderate Tolerable
in requirements
 • Risk Planning : It considers each of the key risks which have been identified and
identifies strategies to manage the risk. These strategies fall into following three
categories :
• Avoidance strategies : It reduces the probability of the risk. E.g. strategies
for dealing with defective components should be avoided.
• Minimising Strategies : Minimises the impact of the risk. E.g. strategies
for staff illness.
• Contingency strategies : In case of worst case the thighs must be replaced.
e..g organizational financial problems.

The following table shows some of the risk and their corresponding strategies
to be adopted.

Risk Strategy
Organizational Prepape a document showing importance and benefits to the
Financial Problems orgnnization to top lelevel management.
Recruitment problems Alert customer of potential difficulties and the possibilities of
delays
Staff illness Reorganise the team so that more overlap of the work and people
therefore understand each other’s job.
Defective Replace them with newer ones
components
Requirement changes Trace the information changes cautiously

• Risk Monitoring : It involves each of the identified risks to decide whether or not
that risk is becoming more or less probable and whether the effect of the risk has
been reduced. It is a continuous process through the organization all level and
each activity of the project.