UNIT 5

1] REACTIVE VS PROACTIVE RISK STRATEGIES

BASIS REACTIVE RISK STRATEGY PROACTIVE RISK STRATEGIES

MEANING Actions in response to hazard/risk Actions that address perceived
occurrence. hazard/risk occurrence before it
actually occurs.
DEFINITION A response based risk management Adaptive, closed loop feedback
approach, which is dependent on control strategy based on
accident evaluation and audit based measurement, observation of the
findings. present safety level and planned
explicit target safety level with a
creative intellectuality
MANAGEMENT ACTIVITY After hazard/risk occurrence, taking Before an identified hazard occurs,
measures (i.e., corrective actions) to management creates control
prevent re-occurrence. Management measures to prevent initial
does this by processing occurrence. Identifying these hazards
incident/accident reports. usually happens through proactive
activities, or by reviewing proactive
reports.
PURPOSE Reactive risk management attempts  Proactive risk management attempts
to reduce the tendency of the same to reduce the tendency of any
or similar accidents which happened accident happening in future by
in past being repeated in future. identifying the boundaries of activities,
where a breach of the boundary can
lead to an accident.
TIMEFRAME Reactive risk management solely Proactive risk management combines
depends on past accidental analysis a mixed method of past, present and
and response. future prediction before finding
solutions to avoid risks.
FLEXIBILITY Reactive risk management does not Proactive risk management
accommodate prediction, creativity, includes creative thinking, prediction.
and problem-solving ability of Further, it principally depends on the
humans in its approach which accident source to reduce the
makes it less flexible to changes accident which is a human attribute.
and challenges. So, this lets it be very adaptive to
changing environment.
EXAMPLES  MOR  Audits/inspections
 Incident report  Voluntary reporting
 Accident report  Surveys
2] FORMAL-TECHNICAL REVIEWS IN SOFTWARE QUALITY ASSURANCE

FORMAL REVIEW

It is a type of peer review.

A Formal Review follows a formal process and has a specific formal agenda.

It has a well structured and regulated process, which is usually implemented at the end of each life
cycle.

During this process, a formal review panel or board considers the necessary steps for the next life
cycle.

Features of Formal Review:

 This evaluates conformance to specification and various standards.

 Conducted by a group of 3 or more individuals.

 The review team petitions the management of technical leadership to act on the suggested
recommendations.

 Here, the leader verifies that the action documents are verified and incorporated into external
processes.

 Formal review consists of six important steps, which are:

o Planning.

o Kick-off.

o Preparation.

o Review meeting.

o Rework.

o Follow up.
 TECHNICAL REVIEW

A Technical review is a static white-box testing technique which is conducted to spot

the defects early in the life cycle that cannot be detected by black box testing
techniques.

Technical Review Characteristics:

 Technical Reviews are documented and uses a defect detection process that has peers and
technical specialist as part of the review process.
 The Review process doesn't involve management participation.
 It is usually led by trained moderator who is NOT the author.
 The report is prepared with the list of issues that needs to be addressed.
 3] ROLES OF SOFTWARE REVIEW IN ACHIEVING GOOD SOFTWARES(NEED OF SOFTWARE
REVIEW)
The reasons that make software review an important element of software development process are
numerous.
It is one such methodology that offers an opportunity to the development team & the client, to get
clarity on the project as well as its requirements.
With the assistance of software review, the team can verify whether the software is developed as per
the requested requirements or not, and make the necessary changes before its release in the market.
Other important reasons for Software Review are:

 It improves the productivity of the development team.

 Makes the process of testing time & cost effective, as more time is spent on testing the
software during the initial development of the product.

 Fewer defects are found in the final software, which helps reduce the cost of the whole
process.

 The reviews provided at this stage are found to be cost effective, as they are identified at the
earlier stage, as the cost of rectifying a defect in the later stages would be much more than
doing it in the initial stages.

 It is only at this stage the inadequacies are eliminated.

 Elimination of defects or errors can benefit the software to a great extent. Frequent check of
samples of work and identification of small time errors can lead to low error rate.

 This process results in dramatic reduction of time taken in producing a technically sound
document.
4] H0W TO IDENTIFY RISKS IN SOFTWARE DEVELOPMENT

5] WHAT IS SOFTWARE MAINTENANCE AND METHOD OF ESTIMATING MAINTENANCE COSTS

Software maintenance is defined by the  IEEE  as:

“Modification of a software product after delivery to correct faults, to improve performance or

other attributes, or to adapt the product to a modified environment.”
6] RE ENGINEERING
7] VARIOUS STRATEGIES TO OVERCOME RISK IN SOFTWARE DEVELOPMENT
8] TASK SET AND TASK NETWORK OF ANY SOFTWARE

 Taskset  -  collection of software engineering work tasks, milestones, and deliverables that must be
accomplished to complete a particular project.
 
·                  Task sets are designed to accommodate different types of projects and different degrees of
rigor.
 
 determine type of project
 assess the degree of rigor required
 identify adaptation criteria
 select appropriate software engineering task.

Defining a Task Network

·                  Individual tasks and subtasks have interdependencies based on their sequence.

·                  It is likely that development activities and tasks will be performed in parallel.

·                  Concurrent tasks must be coordinated so that they will be complete when later tasks require
their work product(s).

·                  Task network (  activity network )  is a graphic representation of the task flow for a project.

 The task network depicts major software engineering tasks.         

   Parallel tasks occur asynchronously
   Planner must determine intertask dependencies to ensure continuous progress toward
completion.
   Project manager should be aware of those tasks that must be completed on schedule if the
project as a whole is to be completed on schedule.
9] SOFTWARE QUALITY AND OVERVIEW OF SOFTWARE QUALITY FACTOR

SOFTWARE QUALITY
Traditionally, a quality product is defined in terms of its fitness of purpose. That is, a quality product
does exactly what the users want it to do. For software products, fitness of purpose is usually
interpreted in terms of satisfaction of the requirements laid down in the SRS document. Although
“fitness of purpose” is a satisfactory definition of quality for many products such as a car, a table fan,
a grinding machine, etc. – for software products, “fitness of purpose” is not a wholly satisfactory
definition of quality. To give an example, consider a software product that is functionally correct. That
is, it performs all functions as specified in the SRS document. But, has an almost unusable user
interface. Even though it may be functionally correct, we cannot consider it to be a quality product.
Another example may be that of a product which does everything that the users want but has an
almost incomprehensible and unmaintainable code. Therefore, the traditional concept of quality as
“fitness of purpose” for software products is not wholly satisfactory.
The modern view of a quality associates with a software product several quality factors such as the
following:
 Portability: A software product is said to be portable, if it can be easily made to work in different
operating system environments, in different machines, with other software products, etc.
 Usability: A software product has good usability, if different categories of users (i.e. both expert and
novice users) can easily invoke the functions of the product.
 Reusability: A software product has good reusability, if different modules of the product can easily
be reused to develop new products.
 Correctness: A software product is correct, if different requirements as specified in the SRS document
have been correctly implemented.
 Maintainability: A software product is maintainable, if errors can be easily corrected as and when
they show up, new functions can be easily added to the product, and the functionalities of the product
can be easily modified, etc.
10] SQA AND SQA ACTIVITIES