Notesale: Turn your study into money

Document Preview

Extracts from the notes are below, to see the PDF you'll receive please use the links above

---

Software Engineering Notes
Compiled from

Software Engineering
A Practitioner’s Approach
APRACTITIONECH
FIFTH EDITION

- Roger S
...
- 1
Chap
...
- 3
Chap
...
- 5
Chap
...
- 7
Chap
...
- 9
Chap
...
- 13
Chap
...
- 18
Chap
...
What are the Software Characteristics ?
Software Characteristics:
To gain an understanding of software (and ultimately an understanding of software
engineering), it is important to examine the characteristics of software that make it different
from other things that human beings build
...
If
we build a new computer, our initial sketches, formal design drawings, and breadboarded
prototype evolve into a physical product (chips, circuit boards, power supplies, etc
...

Therefore, software has characteristics that are considerably different than those of hardware:
1
...

Although some similarities exist between software development and
hardware manufacture, the two activities are fundamentally different
...
Both activities are dependent on people, but the relationship between
people applied and work accomplished is entirely different (see Chapter 7)
...


Software costs are concentrated in engineering
...

2
...
"
Figure 1
...
The
relationship, often called the "bathtub curve," indicates that hardware exhibits
relatively high failure rates early in its life (these failures are often attributable to
design or manufacturing defects); defects are corrected and the failure rate drops to a
steady-state level (ideally, quite low) for some period of time
...
Stated simply, the hardware begins to wear out
...
In
theory, therefore, the failure rate curve for software should take the form of the
“idealized curve” shown in Figure 1
...
Undiscovered defects will cause high failure
rates early in the life of a program
...
The idealized curve is a
gross over simplification of actual failure models (see Chapter 8 for more information)
for software
...
But it does
deteriorate! This seeming contradiction can best be explained by considering the
“actual curve” shown in Figure 1
...
During its life, software will undergo change
(maintenance)
...
2
...
Slowly, the minimum failure rate level begins to
rise—the software is deteriorating due to change
...
When a hardware component wears out, it is replaced by a spare part
...
Every software failure indicates an error in design
or in the process through which design was translated into machine executable code
...

3
...

Consider the manner in which the control hardware for a computer-based
product is designed and built
...

Each integrated circuit (called an IC or a chip) has a part number, a defined and
validated function, a well-define interface, and a standard set of integration guidelines
...

As an engineering discipline evolves, a collection of standard design
components is created
...
The reusable components have been created
so that the engineer can concentrate on the truly innovative elements of a design,
that is, the parts of the design that represent something new
...
In the software world, it
is something that has only begun to be achieved on a broad scale
...
In the 1960s, we built scientific subroutine libraries that were
reusable in a broad array of engineering and scientific applications
...
Today, we have extended our view of reuse to encompass not
only algorithms but also data structure
...
For example, today's graphical user
interfaces are built using reusable components that enable the creation of graphics

4

windows, pull-down menus, and a wide variety of interaction mechanisms
...


2
...
e
...
Information content and determinacy are important
factors in determining the nature of a software application
...
For example, many business applications use
highly structured input data (a database) and produce formatted “reports
...
g
...

Information determinacy refers to the predictability of the order and timing of
information
...
Such applications are determinate
...
Applications with these characteristics are indeterminate
...
As software complexity grows, neat compartmentalization disappears
...


System software
...

Some system software (e
...
, compilers, editors, and file management utilities)
process complex, but determinate, information structures
...
g
...
In either case, the system software area is
characterized by heavy interaction with computer hardware; heavy usage by multiple
users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external
interfaces
...


Real-time software
...
Elements of real-time software include a data gathering component
that collects and formats information from an external environment, an analysis
component that transforms information as required by the application, a control/output
component that responds to the external environment, and a monitoring component
that coordinates all other components so that real-time response (typically ranging
from 1 millisecond to 1 second) can be maintained
...


Business software
...
Discrete "systems" (e
...
, payroll, accounts receivable/payable, inventory) have
evolved into management information system (MIS) software that accesses one or
more large databases containing business information
...
In addition to conventional data processing application, business

5

software applications also encompass interactive computing (e
...
, point of- sale
transaction processing)
...


Engineering and scientific software
...
Applications range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics, and from molecular
biology to automated manufacturing
...

Computer-aided design, system simulation, and other interactive applications have
begun to take on real-time and even system software characteristics
...


Embedded software
...
Embedded software resides in read-only memory and is used
to control products and systems for the consumer and industrial markets
...
g
...
g
...

f
...


The personal computer software market has burgeoned over the past two decades
...

g
...


The Web pages retrieved by a browser are software that incorporates executable
instructions (e
...
, CGI, HTML, Perl, or Java), and data (e
...
, hypertext and a variety
of visual and audio formats)
...

h
...


Artificial intelligence (AI) software makes use
of non-numerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis
...


6

Chapter 2 : The Process
1
...
THE LINEAR SEQUENTIAL MODEL :
Sometimes called the classic life cycle or the waterfall model, the linear sequential model
suggests a systematic, sequential approach5 to software development that begins at the
system level and progresses through analysis, design, coding, testing, and support
...
4 illustrates the linear sequential model for software engineering
...

Because software is always part of a larger system (or business), work begins by
establishing requirements for all system elements and then allocating some subset of these
requirements to software
...
System engineering and analysis
encompass requirements gathering at the system level with a small amount of top level
design and analysis
...

Software requirements analysis
...
To understand the nature of the program(s) to be built, the software engineer
("analyst") must understand the information domain for the software, as well as required
function, behavior, performance, and interface
...

Design
...
The design process translates requirements into a representation of the
software that can be assessed for quality before coding begins
...

Code generation
...
The code generation
step performs this task
...

Testing
...
The testing process focuses
on the logical internals of the software, ensuring that all statements have been tested, and on
the functional externals; that is, conducting tests to uncover errors and ensure that defined
input will produce actual results that agree with required results
...

Software will undoubtedly undergo change after it is delivered to the customer (a
possible exception is embedded software)
...
g
...

Software support/maintenance reapplies each of the preceding phases to an existing program
rather than a new one
...
Among the problems that are sometimes encountered when the linear
sequential model is applied are:
1
...

Although the linear model can accommodate iteration, it does so indirectly
...


2
...
The
linear sequential model requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects
...


The customer must have patience
...
A major blunder, if undetected
until the working program is reviewed, can be disastrous
...
However, the classic life cycle paradigm has a
definite and important place in software engineering work
...
The classic life
cycle remains a widely used procedural model for software engineering
...


b
...
5) begins with requirements gathering
...
A "quick
design" then occurs
...
g
...

The quick design leads to the construction of a prototype
...
Iteration
occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time
enabling the developer to better understand what needs to be done
...
If a
working prototype is built, the developer attempts to use existing program fragments or
applies tools (e
...
, report generators, window managers) that enable working programs to be
generated quickly
...
" The one that Brooks recommends we throw
away
...
It is true that both customers and developers like the
prototyping paradigm
...
Yet, prototyping can also be problematic for the following reasons:

8

1
...
When informed that the product must be rebuilt so that high levels of
quality can be maintained, the customer cries foul and demands that "a few fixes" be
applied to make the
prototype a working product
...

2
...
An inappropriate operating system or programming language may be
used simply because it is available and known; an
inefficient algorithm may be implemented simply to demonstrate capability
...
The less-than-ideal choice has now become an integral part of
the system
...
The key is to define the rules of the game at the beginning; that is, the
customer and developer must both agree that the prototype is built to serve as a
mechanism for defining requirements
...


c
...
The RAD model is a “highspeed” adaptation of the linear sequential model in which rapid development is achieved by
using component-based construction
...
g
...
Used primarily for information
systems applications, the RAD approach encompasses the following phases :
Business modeling
...

The information flow defined as part of the business modeling phase is refined into a
set of data objects that are needed to support the business
...

Process modeling
...
Processing descriptions are
created for adding, modifying, deleting, or retrieving a
data object
...

RAD assumes the use of fourth generation techniques
...
In all cases, automated tools are used to facilitate construction of the software
...

Since the RAD process emphasizes reuse, many of the program components have
already been tested
...
However, new components must be
tested and all interfaces must be fully exercised
...
Each major function can be addressed by a separate RAD team and then
integrated to form a whole
...


•

RAD requires developers and customers who are committed to the rapid-fire activities
necessary to get a system complete in a much abbreviated time frame
...


•

Not all types of applications are appropriate for RAD
...
If high
performance is an issue and performance is to be achieved through tuning the interfaces
to system components, the RAD approach may not work
...
This occurs when a new application
makes heavy use of new technology or when the new software requires a high degree of
interoperability with existing computer programs
...
THE EVOLUTIONARY SOFTWARE PROCESS MODEL :
Evolutionary models are iterative
...


i
...
The incremental model applies linear
sequences in a staggered fashion as calendar time progresses
...
It should be noted that the process flow
for any increment can incorporate the prototyping paradigm
...
That is, basic requirements are addressed,

10

but many supplementary features (some known, others unknown) remain undelivered
...
As a result of use
and/or evaluation, a plan is developed for the next increment
...
This process is repeated following the delivery of each
increment, until the complete product is produced
...
Early increments are stripped down versions of the final product, but they do
provide capability that serves the user and also provide a platform for evaluation by the user
...
The Spiral Model
The spiral model is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the linear sequential model
...
Using
the spiral model, software is developed in a series of incremental releases
...
During later iterations,
increasingly more complete versions of the engineered system are produced
...

Typically, there are between three and six task regions
...
8 depicts a spiral model that
contains six task regions:
• Customer communication
tasks required to establish effective communication between developer and customer
...

• Risk analysis
tasks required to assess both technical and management risks
...

• Construction and release
tasks required to construct, test, install, and provide user support (e
...
,
documentation and training)
...


Each of the regions is populated by a set of work tasks, called a task set, that are adapted
to the characteristics of the project to be undertaken
...
For larger, more critical projects, each task region contains
more work tasks that are defined to achieve a higher level of formality
...
The WINWIN Spiral Model
The spiral model suggests a framework activity that addresses customer communication
...
In an ideal
context, the developer simply asks the customer what is required and the customer provides
sufficient detail to proceed
...
In reality, the customer and the
developer enter into a process of negotiation, where the customer may be asked to balance
functionality, performance, and other product or system characteristics against cost and time
to market
...
That is, the customer wins by getting the
system or product that satisfies the majority of the customer’s needs and the developer wins
by working to realistic and achievable budgets and deadlines
...
Rather than a single customer communication
activity, the following activities are defined:
1
...
”
2
...
”
3
...

Successful completion of these initial steps achieves a win-win result, which becomes
the key criterion for proceeding to software and system definition
...

In essence, the anchor points represent three different views of progress as the project
traverses the spiral
...
For example, as part of LCO, a set of
objectives establishes the definition of top-level system/product requirements
...
For example, as part of LCA, the software
project team must demonstrate that it has evaluated the applicability of off-the-shelf and
reusable software components and considered their impact on architectural decisions
...


e
...
The object oriented paradigm emphasizes the
creation of classes that encapsulate both data and the algorithms used to manipulate the data
...

The component-based development (CBD) model incorporates many of the characteristics
of the spiral model
...
However, the component-based development model composes
applications from prepackaged software components (called classes)
...
This is
accomplished by examining the data to be manipulated by the application and the algorithms
that will be applied to accomplish the manipulation
...


The component-based development model leads to software reuse, and reusability provides
software engineers with a number of measurable benefits
...
Once candidate classes are identified, the class library is searched to determine if
these classes already exist
...
If a
candidate class does not reside in the library, it is engineered using object-oriented methods
...
Process
flow then returns to the spiral and will ultimately re-enter the component assembly iteration
during subsequent passes through the engineering activity
...
Using the Unified
Modeling Language (UML), the unified process defines the components that will be used to
build the system and the interfaces that will connect the components
...
It then couples function
with an architectural framework that identifies the form the software will take
...
Explain W5HH Principle
W5HH Principle :
In an paper on software process and projects, Barry Boehm suggests an approach that
addresses project objectives, milestones and schedules, responsibilities, management and
technical approaches, and required resources
...
Stated in another way, does the business purpose justify the
expenditure of people, time, and money?


What will be done, by when?
The answers to these questions help the team to establish a project schedule by
identifying key project tasks and the milestones that are required by the customer
...
The answer to this question helps accomplish this
...
The customer,
users, and other stakeholders also have responsibilities
...



How much of each resource is needed?
The answer to this question is derived by developing estimates based on answers to
earlier questions
...
The questions noted provide an excellent planning outline for the project manager
and the software team
...
Explain Measures, Metrics & Indicators
Although the terms measure, measurement, and metrics are often used interchangeably, it
is important to note the subtle differences between them
...
Within the software engineering context, a
measure provides a quantitative indication of the extent, amount, dimension, capacity, or size
of some attribute of a product or process
...

The IEEE Standard Glossary of Software Engineering Terms defines metric as “a
quantitative measure of the degree to which a system, component, or process possesses a
given attribute
...
g
...
Measurement occurs as the
result of the collection of one or more data points (e
...
, a number of module reviews are
investigated to collect measures of the number of errors for each)
...
g
...

A software engineer collects measures and develops metrics so that indicators will be
obtained
...

An indicator provides insight that enables the project manager or software engineers to
adjust the process, the project, or the process to make things better
...
Each team must
conduct design reviews but is allowed to select the type of review that it will use
...
Assuming all other
parameters equal, this provides the project manager with an indicator that formal review
methods may provide a higher return on time investment than another, less formal review
approach
...
The
metric provides the manager with insight
...


2
...
g
...
g
...
Software metrics can be categorized similarly
...
Direct
measures of the product include lines of code (LOC) produced, execution speed, memory
size, and defects reported over some set period of time
...


16

The cost and effort required to build software, the number of lines of code produced, and other direct
measures are relatively easy to collect, as long as specific conventions for measurement are established
in advance
...


a
...
If a software
organization maintains simple records, a table of size-oriented measures, such as the one
shown in Figure 4
...


The table lists each software development project that has been completed over the past
few years and corresponding measures for that project
...
4) for project alpha:
12,100 lines of code were developed with 24 person-months of effort at a cost of $168,000
...
Further information
for project alpha indicates that 365 pages of documentation were developed, 134 errors were
recorded before the software was released, and 29 defects were encountered after release to
the customer within the first year of operation
...

In order to develop metrics that can be assimilated with similar metrics from other
projects, we choose lines of code as our normalization value
...

• Defects4 per KLOC
...

• Page of documentation per KLOC
...

• LOC per person-month
...


17

b
...
Since ‘functionality’ cannot be measured directly, it must
be derived indirectly using other direct measures
...

Function points are derived using an empirical relationship based on countable (direct)
measures of software's information domain and assessments of software complexity
...
5
...
Information domain values are defined in the following manner :
Number of user inputs
...
Inputs should be distinguished from inquiries, which are counted
separately
...
Each user output that provides application oriented information to
the user is counted
...

Individual data items within a report are not counted separately
...
An inquiry is defined as an on-line input that results in the
generation of some immediate software response in the form of an on-line output
...

Number of files
...
e
...

Number of external interfaces
...
g
...

Once these data have been collected, a complexity value is associated with each count
...
Nonetheless, the determination of complexity
is somewhat subjective
...
65 + 0
...
5
...

2
...

4
...

6
...

8
...

10
...

12
...

14
...
The constant values in Equation (4-1) and the
weighting factors that are applied to information domain counts are determined empirically
...

• Defects per FP
...

• Pages of documentation per FP
...


3
...


Direct Measures :
Measurement
Parameter

Count

No
...
of User Outputs
No
...
of Files
No
...

1
...

3
...

5
...

7
...

9
...

11
...

13
...


Indirect Measures :
Does the system require reliable backup and recovery?
Are data communications required?
Are there distributed processing functions?
Is performance critical?
Will the system run in an existing, heavily utilized operational
environment?
Does the system require on-line data entry?
Does the on-line data entry require the input transaction to be
built over multiple screens or operations?
Are the master files updated on-line?
Are the inputs, outputs, files, or inquiries complex?
Is the internal processing complex?
Is the code designed to be reusable?
Are conversion and installation included in the design?
Is the system designed for multiple installations in different
organizations?
Is the application designed to facilitate change and ease of use
by the user?

5
3
2
4
5
3
3
3
5
2
3
5
4
3

∑(Fi) = 50
FP = Count-Total * [ 0
...
01 * ∑(Fi) ]
FP =
=
=
=
~

72 * [ 0
...
01 * 50 ]
72 * [ 0
...
50 ]
72 * 1
...
8
83
Function Point = 83

20

Chapter 5 : Software Project
Planning
1
...
Boehm's Book Software engineering
economics as a model for estimating effort, cost, and schedule for software projects
...
The study examined projects ranging in size from 2000 to
100,000 lines of code, and programming languages ranging from assembly to PL/I
...

References to this model typically call it COCOMO 81
...

COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern
software development projects
...
The need for the new model came as software
development technology moved from mainframe and overnight batch processing to desktop
development, code reusability and the use of off-the-shelf software components
...

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms
...




Intermediate COCOMO
It takes the Cost Drivers into account



Advance / Detailed COCOMO
It additionally accounts for the influence of individual project phases
...
COCOMO
applies to three classes of software projects:



Organic projects - are relatively small, simple software projects in which small teams
with good application experience work to a set of less than rigid requirements
...


21



Embedded projects - are software projects that must be developed within a set of
tight hardware, software, and operational constraints
...
The coefficients ab, bb, cb and db are
given in the following table
...
4
3
...
6

1
...
12
1
...
5
2
...
5

0
...
35
0
...




Intermediate COCOMO :

Intermediate COCOMO computes software development effort as function of program size
and a set of "cost drivers" that include subjective assessment of product, hardware, personnel
and project attributes
...









Product attributes
o Required software reliability
o Size of application database
o Complexity of the product
Hardware attributes
o Run-time performance constraints
o Memory constraints
o Volatility of the virtual machine environment
o Required turnabout time
Personnel attributes
o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience
Project attributes
o Use of software tools
o Application of software engineering methods
o Required development schedule

Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to
"extra high" (in importance or value)
...
The product of all effort multipliers results in an effort adjustment factor (EAF)
...
9 to 1
...

The Intermediate Cocomo formula now takes the form:
(b )

E=ai(KLoC) i
...
The
coefficient ai and the exponent bi are given in the next table
...
2

1
...
0

1
...
8

1
...




Advance / Detailed COCOMO :

Detailed COCOMO - incorporates all characteristics of the intermediate version with an assessment
of the cost driver's impact on each step (analysis, design, etc
...


4
...
of required Persons

S/W Project

Ab

Bb

Cb

Db

Organic
Semi-Detached
Embedded

2
...
0
3
...
05
1
...
2

2
...
5
2
...
38
0
...
32

23

a) Overall cost & schedule estimates :
Here, we will take the Project to be Organic
...
4 ( 12 )

1
...
5 ( 32
...
61

Months

= 3
...
61 / 9
...
3975

0
...
61 X 2000 = Rs
...
0 (4)

1
...
17
Persons-Months
D = 2
...
17)0
...
32
Months

N = 14
...
32
= 2
...
12

E = 3
...
52

Persons-Months
D = 2
...
52)0
...
81
Months

N = 6
...
81
= 1
...
12

E = 3
...
0

Persons-Months
D = 2
...
0)0
...
67
Months

N = 3
...
67
= 0
...
12

E = 3
...
52

Persons-Months
D = 2
...
52)0
...
81
Months

N = 6
...
81
= 1
...
0 (3)

1
...
42
Persons-Months
D = 2
...
42)0
...
84
Months

N = 3
...
84
= 0
...
Explain Software Risks
Risk is defined as "The possibility of suffering harm or loss; danger
...
We are
aware of the potential dangers that permeate even simple daily activities, from getting
injured when crossing the street to having a heart attack because our cholesterol level
is too high
...
Experience (or a parent) has taught us to
look both ways before stepping off the curb and most of us at least think twice before
ordering a steak
...

Risks in Software Project Management
Unlike the hazards of daily living, the dangers in the young and emerging field of
software engineering must often be learned without the benefit of lifelong exposure
...
Such an approach involves studying the
experiences of successful project managers as well as keeping up with the leading
writers and thinkers in the field
...
Barry W
...
In his article "Software Risk Management: Principles and Practices" he lists
the following top 10 software risk items:
1
...
Unrealistic schedules and budgets
3
...
Developing the wrong user interface
5
...
Continuing stream of requirements changes
7
...
Shortfalls in externally performed tasks
9
...
Straining computer-science capabilities
There is a general agreement that risk always involves two characteristics :



Uncertainty—the risk may or may not happen; that is, there are no 100% probable risks
...


When risks are analyzed, it is important to quantify the level of uncertainty and the degree of
loss associated with each risk
...



Project risks threaten the project plan
...
Project risks identify
potential budgetary, schedule, personnel (staffing and organization), resource,
customer, and requirements problems and their impact on a software project
...



Technical risks threaten the quality and timeliness of the software to be produced
...

Technical risks identify potential design, implementation, interface, verification, and
maintenance problems
...

Technical risks occur because the problem is harder to solve than we thought it would
be
...
Business risks often
jeopardize the project or the product
...


It is extremely important to note that simple categorization won't always work
...

Another general categorization of risks is:


Known risks are those that can be uncovered after careful evaluation of the project
plan, the business and technical environment in which the project is being developed,
and other reliable information sources (e
...
, unrealistic delivery date, lack of
documented requirements or software scope, poor development environment)
...
g
...




Unpredictable risks are the joker in the deck
...


2
...
Resources are set aside to deal with
them, should they become actual problems
...
Then, the team flies into action in an attempt to
correct the problem rapidly
...

When this fails, “crisis management” takes over and the project is in realjeopardy
...
A proactive strategy
begins long before technical work is initiated
...
Then, the software team
establishes a plan for managing risk
...


3
...

The project planner, along with other managers and technical staff, performs four risk
projection activities :
(1) establish a scale that reflects the perceived likelihood of a risk,
(2) delineate the consequences of the risk,
(3) estimate the impact of the risk on the project and the product,
(4) note the overall accuracy of the risk projection so that there will be no
misunderstandings
...


A project team begins by listing all risks (no matter how remote) in the first column of the
table
...
3
...
g
...
The probability of occurrence of each risk is entered in the next
column of the table
...
Individual team members are polled in round-robin fashion until their assessment
of risk probability begins to converge
...
Each risk component is assessed using the
characterization presented in Figure 6
...

The categories for each of the four risk components—performance, support, cost, and
schedule—are averaged to determine an overall impact value
...
High-probability, high-impact risks percolate to the top of the table,
and low-probability risks drop to the bottom
...

The project manager studies the resultant sorted table and defines a cutoff line
...

Risks that fall below the line are re-evaluated to accomplish second-order prioritization
...
3, risk impact and probability have a distinct influence on management
concern
...
However, high-impact risks with
moderate to high probability and low-impact risks with high probability should be carried
forward into the risk analysis steps that follow
...
The column labeled RMMM
contains a pointer into a Risk Mitigation, Monitoring and Management Plan or alternatively, a
collection of risk information sheets developed for all risks that lie above the cutoff
...
Explain Risk Mitigation, Monitoring, Management
Risk Projection :
All of the risk analysis activities have a single goal—to assist the project team in developing
a strategy for dealing with risk
...
This is achieved by developing a plan for risk mitigation
...
Based on past
history and management intuition, the likelihood, l1, of high turnover is estimated to be 0
...
That is, high turnover will
have a critical impact on project cost and schedule
...
Among the possible steps to be taken are
• Meet with current staff to determine causes for turnover (e
...
, poor working conditions, low
pay, competitive job market)
...

• Once the project commences, assume turnover will occur and develop techniques to ensure
continuity when people leave
...

• Define documentation standards and establish mechanisms to be sure that documents are
developed in a timely manner
...

• Assign a backup staff member for every critical technologist
...
The project manager
monitors factors that may provide an indication of whether the risk is becoming more or less
likely
...

• The degree to which the team has jelled
...

• Potential problems with compensation and benefits
...

In addition to monitoring these factors, the project manager should monitor the
effectiveness of risk mitigation steps
...
This is one mechanism for ensuring continuity, should a critical
individual leave the project
...

Management :
Risk management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality
...
If the mitigation strategy has been
followed, backup is available, information is documented, and knowledge has been dispersed
across the team
...
” Those individuals who are leaving are
asked to stop all work and spend their last weeks in “knowledge transfer mode
...

RMMM Plan :
A risk management strategy can be included in the software project plan or the risk
management steps can be organized into a separate Risk Mitigation, Monitoring and
Management Plan
...
Some software teams
do not develop a formal RMMM document
...

Once RMMM has been documented and the project has begun, risk mitigation and
monitoring steps commence
...
Risk monitoring is a project tracking activity with three primary objectives:
(1) to assess whether predicted risks do, in fact, occur;
(2) to ensure that risk aversion steps defined for the risk are being properly applied;
(3) to collect information that can be used for future risk analysis
...

Another job of risk monitoring is to attempt to allocate origin (what risk(s) caused which
problems throughout the project)
...
Explain Task Set Selector
Different software models offer different paradigms for software development
...

No single set of tasks is appropriate for all projects
...
Therefore, an effective software process should define a
collection of task sets, each designed to meet the needs of different types of projects
...

The task set to be chosen must provide enough discipline to achieve high software quality
...

Task sets are designed to accommodate different types of projects and different degrees of
rigor
...
Concept development projects that are initiated to explore some new business concept
or application of some new technology
...
New application development projects that are undertaken as a consequence of a
specific customer request
...
Application enhancement projects that occur when existing software undergoes major
modifications to function, performance, or interfaces that are observable by the end-user
...
Application maintenance projects that correct, adapt, or extend existing software in ways
that may not be immediately obvious to the end-user
...
Reengineering projects that are undertaken with the intent of rebuilding an existing
(legacy) system in whole or in part
...

When taken in combination, these factors provide an indication of the degree of rigor
with which the software process should be applied
...
The degree of rigor is a function of many project
characteristics
...
It
should be noted, however, that all projects must be conducted in a manner that results in
timely, high-quality deliverables
...


All process framework activities (Chapter 2) are applied, but only a minimum
task set is required
...
All basic principles of software engineering are still
applicable
...


Strict
...
Framework activities
and related tasks appropriate to the project type will be applied and umbrella
activities necessary to ensure high quality will be applied
...


The full process will be applied for this project with a degree of discipline that will
ensure high quality
...


Quick reaction
...
“Back-filling” (i
...
, developing a complete set of
documentation, conducting additional reviews) will be accomplished after
the application/product is delivered to the customer
...
Eleven adaptation criteria are defined for
software projects:
• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staff
• Reengineering factors
Each of the adaptation criteria is assigned a grade that ranges between 1 and 5, where 1
represents a project in which a small subset of process tasks are required and overall
methodological and documentation requirements are minimal, and 5 represents a project in
which a complete set of process tasks should be applied and overall methodological and
documentation requirements are substantial
...
Review each of the adaptation criteria in Section 7
...
2 and assign the appropriate grades
(1 to 5) based on the characteristics of the project
...
1
...
Review the weighting factors assigned to each of the criteria
...
8 to 1
...

If modifications are required to better reflect local circumstances, they should be made
...
Multiply the grade entered in Table 7
...
The entry point multiplier takes on a value
of 0 or 1 and indicates the relevance of the adaptation criterion to the project type
...
1 for each adaptation criteria individually
...
Compute the average of all entries in the Product column and place the result in the
space marked task set selector (TSS)
...


Interpreting the TSS Value and Selecting the Task Set
Once the task set selector is computed, the following guidelines can be used to select the
appropriate task set for a project:
Task set selector value Degree of rigor
TSS < 1
...
0 < TSS < 3
...
4
strict
Table 7
...
The project
manager selects the grades shown in the Grade column
...
Therefore, entry point multipliers are selected from the NDev column
...
8
...
The final decision is made once all project factors
have been considered
...
Explain Scheduling or Tracking & Scheduling
Risk Projection :
Scheduling of a software project does not differ greatly from scheduling of any multitask
engineering effort
...
Program evaluation and review technique
(PERT) and critical path method (CPM) are two project scheduling methods that can be
applied to software development
...
Tasks, sometimes
called the project work breakdown structure (WBS), are defined for the product as a whole or
for individual functions
...

Boundary time calculations can be very useful in software project scheduling
...

Riggs describes important boundary times that may be discerned from a PERT or CPM
network:
(1) the earliest time that a task can begin when all preceding tasks are completed in the
shortest possible time,
(2) the latest time for task initiation before the minimum project completion time is delayed,
(3) the earliest finish—the sum of the earliest start and the task duration,
(4) the latest finish— the latest start time added to task duration,
(5) the total float—the amount of surplus time or leeway allowed in scheduling tasks so that
the network critical path is maintained on schedule
...

Both PERT and CPM have been implemented in a wide variety of automated tools that are
available for the personal computer
...


34

Timeline Charts
When creating a software project schedule, the planner begins with a set of tasks (the
work breakdown structure)
...
Effort, duration, and start date are then input for
each task
...

As a consequence of this input, a timeline chart, also called a Gantt chart, is generated
...
Alternatively, separate
charts can be developed for each project function or for each individual working on the project
...
4 illustrates the format of a timeline chart
...
5) for a new word-processing
(WP) software product
...
The horizontal bars indicate the duration of each task
...
The diamonds indicate
milestones
...
5)
...


35

Tracking the Schedule
The project schedule provides a road map for a software project manager
...
Tracking can be accomplished in a number of
different ways:
• Conducting periodic project status meetings in which each team member reports progress
and problems
...

• Determining whether formal project milestones (the diamonds shown in Figure 7
...

• Comparing actual start-date to planned start-date for each project task listed in the resource
table (Figure 7
...

• Meeting informally with practitioners to obtain their subjective assessment of progress to
date and problems on the horizon
...

In reality, all of these tracking techniques are used by experienced project managers
...
If things are going well (i
...
, the project is on schedule and
within budget, reviews indicate that real progress is being made and milestones are being
reached), control is light
...
After a problem has been diagnosed,10
additional resources may be focused on the problem area: staff may be redeployed or the
project schedule can be redefined
...
The time-boxing strategy
recognizes that the complete product may not be deliverable by the predefined deadline
...
The tasks associated with each increment are then time-boxed
...
A “box” is put around each task
...
The initial reaction to the
time-boxing approach is often negative: “If the work isn’t finished, how can we proceed?” The
answer lies in the way work is accomplished
...
11 The remaining 10
percent, although important, can
(1) be delayed until the next increment
or
(2) be completed later if required
...


37

Chapter 8 : Software Quality
Assurance
1
...
But how do we define quality?
Many definitions of software quality have been proposed in the literature
...

There is little question that this definition could be modified or extended
...
For the purposes of this book, the
definition serves to emphasize three important points:
1
...
Lack of
conformance to requirements is lack of quality
...
Specified standards define a set of development criteria that guide the manner in which
software is engineered
...

2
...
g
...
If software conforms to its explicit requirements but fails to
meet implicit requirements, software quality is suspect
...

Software engineers address quality (and perform quality assurance and quality control
activities) by applying solid technical methods and measures, conducting formal technical
reviews, and performing well-planned software testing
...
The Software Engineering Institute [PAU93] recommends a set of SQA activities that
address quality assurance planning, oversight, record keeping, analysis, and reporting
...


The plan is developed during project planning and is reviewed by all interested parties
...
The plan identifies
• evaluations to be performed
• audits and reviews to be performed
• standards that are applicable to the project
• procedures for error reporting and tracking
• documents to be produced by the SQA group
• amount of feedback provided to the software project team

38



Participates in the development of the project’s software process description
...
The SQA
group reviews the process description for compliance with organizational policy,
internal software standards, externally imposed standards (e
...
, ISO-9001), and other
parts of the software project plan
...


The SQA group identifies, documents, and tracks deviations from the process and verifies
that corrections have been made
...


The SQA group reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made; and periodically reports the results of its
work to the project manager
...


Deviations may be encountered in the project plan, process description, applicable
standards, or technical work products
...


Noncompliance items are tracked until they are resolved
...


2
...
If a program repeatedly and frequently fails to perform, it matters little whether
other software quality factors are acceptable
...

Software reliability is defined in statistical terms as "the probability of failure-free operation
of a computer program in a
specified environment for a specified time"
...
96 over eight elapsed
processing hours
...

Whenever software reliability is discussed, a pivotal question arises: What is meant by the
term failure? In the context of any discussion of software quality and reliability, failure is
nonconformance to software requirements
...
Failures can be only annoying or catastrophic
...
Complicating the issue
even further, the correction of one failure may in fact result in the introduction of other errors
that ultimately result in other failures
...
In hardware, failures due to physical wear (e
...
, the effects of
temperature, corrosion, shock) are more likely than a design-related failure
...
In fact, all software failures can be traced to design or
implementation problems; wear (see Chapter 1) does not enter into the picture
...
Although an irrefutable link has yet be established, it is
worthwhile to consider a few simple concepts that apply to both system elements
...

Many researchers argue that MTBF is a far more useful measure than defects/KLOC or
defects/FP
...
Because each error contained within a program does not have the same failure rate,
the total error count provides little indication of the reliability of a system
...
Many errors in this program
may remain undetected for decades before they are discovered
...
Other errors, as yet
undiscovered, might have a failure rate of 18 or 24 months
...

In addition to a reliability measure, we must develop a measure of availability
...
The availability
measure is somewhat more sensitive to MTTR, an indirect measure of the maintainability of
software
...
System safety
techniques are designed to cope with random failures in these [nonprogrammable] systems
...

When software is used as part of the control system, complexity can increase by an order of
magnitude or more
...

Software safety is a software quality assurance activity that focuses on the identification and
assessment of potential hazards that may affect software negatively and cause an entire
system to fail
...


40

A modeling and analysis process is conducted as part of software safety
...
For example, some of the hazards
associated with a computer-based cruise control for an automobile might be
• causes uncontrolled acceleration that cannot be stopped
• does not respond to depression of brake pedal (by turning off)
• does not engage when switch is activated
• slowly loses or gains speed
Once these system-level hazards are identified, analysis techniques are used to assign
severity and probability of occurrence
...
For example, a subtle user input error (people are system
components) may be magnified by a software fault to produce control data that improperly
positions a mechanical device
...

Analysis techniques such as fault tree analysis, real-time logic, or petri net models can
be used to predict the chain of events that can cause hazards and the probability that each of
the events will occur to create the chain
...
That is, the specification can contain a
list of undesirable events and the desired system responses to these events
...

Although software reliability and software safety are closely related to one another, it is
important to understand the subtle difference between them
...
However, the
occurrence of a failure does not necessarily result in a hazard or mishap
...
That is,
failures are not considered in a vacuum, but are evaluated in the context of an entire
computer-based system
...
Short Note : Software Quality Assurance Plan
The SQA Plan provides a road map for instituting software quality assurance
...
A standard for SQA plans has been recommended by the IEEE
...
All documents noted in the SQA Plan
are listed and all applicable standards are noted
...

The documentation section describes (by reference) each of the work products produced as
part of the software process
...
g
...
g
...
g
...
g
...
The standards, practices, and conventions section lists all applicable
standards and practices that are applied during the software process (e
...
, document
standards, coding standards, and review guidelines)
...

The reviews and audits section of the plan identifies the reviews and audits to be conducted
by the software engineering team, the SQA group, and the customer
...

The test section references the Software Test Plan and Procedure
...
Problem reporting and corrective action defines procedures for
reporting, tracking, and resolving errors and defects, and identifies the organizational
responsibilities for these activities
...


2
...
iPIi)/PS

42

Chapter 9 : Software configuration
Management
1
...
Because change can occur at any time, SCM activities are
developed to
(1)
(2)
(3)
(4)

identify change,
control change,
ensure that change is being properly implemented,
report changes to others who may have an interest
...
Support is a set of software engineering activities that occur after
software has been delivered to the customer and put into operation
...

The output of the software process is information that may be divided into three broad
categories:
(1) computer programs (both source level and executable forms);
(2) documents that describe the computer programs (targeted at both technical practitioners
and users),
(3) data (contained within the program or external to it)
...

As the software process progresses, the number of software configuration items (SCIs)
grows rapidly
...
These in turn spawn
other documents to create a hierarchy of information
...

Unfortunately, another variable enters the process—change
...

Software configuration management is a set of activities that have been developed to
manage change throughout the life cycle of computer software
...

Any discussion of SCM introduces a set of complex questions:
• How does an organization identify and manage the many existing versions of a program
(and its documentation) in a manner that will enable change to be accommodated efficiently?
• How does an organization control changes before and after software is released to a
customer?
• Who has responsibility for approving and ranking changes?
• How can we ensure that changes have been made properly?
• What mechanism is used to appraise others of changes that are made?

43

These questions lead us to the definition of five SCM tasks: identification, version control,
change control, configuration auditing, and reporting
...
IDENTIFICATION OF OBJECTS IN THE SOFTWARE CONFIGURATION :
To control and manage software configuration items, each must be separately named and
then organized using an object-oriented approach
...

A basic object is a "unit of text" that has been created by a software engineer during
analysis, design, code, or test
...

An aggregate object is a collection of basic objects and other aggregate objects
...
" The object name is a character string that identifies the
object unambiguously
...
g
...
VERSION CONTROL :
Version control combines procedures and tools to manage different versions of
configuration objects that are created during the software process version control in the
context of SCM:
“Configuration management allows a user to specify alternative configurations of the
software system through the selection of appropriate versions
...
”
These "attributes" mentioned can be as simple as a specific version number that is attached
to each object or as complex as a string of Boolean variables (switches) that indicate specific
types of functional changes that have been applied to the system
...
3
...
Each version of the software is a collection of SCIs (source code, documents, data),
and each version may be composed of different variants
...
CHANGE CONTROL :
Change control is vital
...
We
worry about change because a tiny perturbation in the code can create a big failure in the
product
...
We worry about
change because a single rogue developer could sink the project; yet brilliant ideas originate in
the minds of those rogues, and a burdensome change control process could effectively
discourage them from doing creative work
...
For
such projects, change control combines human procedures and automated tools to provide a
mechanism for the control of change
...
5
...
The results of the evaluation are presented as a change
report, which is used by a change control authority (CCA)—a person or group who makes
a final decision on the status and priority of the change
...
The ECO
describes the change to be made, the constraints that must be respected, and the criteria for
review and audit
...
The object is then "checked in"
to the database and appropriate version control mechanisms are used to create the next
version of the software
...
Access control governs which software
engineers have the authority to access and modify a particular configuration object
...

Based on an approved change request and ECO, a software engineer checks out a
configuration object
...
Note that other copies can be checked-out, but other updates cannot be made
...
After appropriate SQA and testing, the modified version of the object is checked in
and the new baseline object is unlocked
...
CONFIGURATION AUDIT
A software configuration audit complements the formal technical review by assessing a
configuration object for characteristics that are generally not considered during review
...
Has the change specified in the ECO been made? Have any additional modifications been
incorporated?
2
...
Has the software process been followed and have software engineering standards been
properly applied?
4
...
Have SCM procedures for noting the change, recording it, and reporting it been followed?
6
...
However,
when SCM is a formal activity, the SCM audit is conducted separately by the quality
assurance group
...
STATUS REPORTING
Configuration status reporting (sometimes called status accounting) is an SCM task
that answers the following questions:
(1) What happened?
(2) Who did it?
(3) When did it happen?
(4) What else will be affected?
The flow of information for configuration status reporting (CSR) is illustrated in Figure 9
...

Each time an SCI is assigned new or updated identification, a CSR entry is made
...
e
...
Each time a
configuration audit is conducted, the results are reported

46

Chapter 10 : System Engineering
1
...
”
The goal may be to support some business function or to develop a product that can be
sold to generate business revenue
...

Computer programs, data structures, and related documentation that serve to effect the
logical method, procedure, or control that is required
...

Electronic devices that provide computing capability, the interconnectivity devices (e
...
,
network switches, telecommunications devices) that enable the flow of data, and
electromechanical devices (e
...
, sensors, motors, pumps) that provide external world function
...

Users and operators of hardware and software
...

A large, organized collection of information that is accessed via software
...

Descriptive information (e
...
, hardcopy manuals, on-line help files, Web sites) that portrays
the use and/or operation of the system
...

The steps that define the specific use of each system element or the procedural context in
which the system resides
...
The
macro element is a computer-based system that is one part of a larger computer-based
system
...
At the lowest level of the hierarchy we have a numerical control
machine, robots, and data entry devices
...

The elements of the numerical control machine include electronic and electromechanical
hardware (e
...
, processor and memory, motors, sensors), software (for communications,
machine control, interpolation), people (the machine operator), a database (the stored NC
program), documentation, and procedures
...
The manufacturing
cell is a computer-based system that may have elements of its own (e
...
, computers,
mechanical fixtures) and also integrates the macro elements that we have
called numerical control machine, robot, and data entry device
...
In some cases, macro elements may share a generic
element
...
In other cases, generic elements are exclusive
to one system
...
Explain Effective Modular Design
Also…
Explain Coupling and/or Cohesion
Modularity has become an accepted approach in all engineering disciplines
...


1) Functional Independence
The concept of functional independence is a direct outgrowth of modularity and the
concepts of abstraction and information hiding
...
Stated another way, we want
to design software so that each module addresses a specific sub-function of requirements
and has a simple interface when viewed from other parts of the program structure
...
Software with effective modularity, that is,
independent modules, is easier to develop because function may be compartmentalized and
interfaces are simplified (consider the ramifications
when development is conducted by a team)
...
To summarize, functional
independence is a key to good design, and design is the key to software quality
...

Cohesion is a measure of the relative functional strength of a module
...


2) Cohesion
Cohesion is a natural extension of the information hiding concept
...
Stated simply, a cohesive module should
(ideally) do just one thing
...
" We always strive for high cohesion,
although the mid-range of the spectrum is often acceptable
...
That is, low-end cohesiveness is much "worse" than middle range, which is nearly
as "good" as high-end cohesion
...
Rather, the overall concept should be understood
and low levels of cohesion should be avoided when modules are designed
...
Such modules are termed coincidentally
cohesive
...
g
...
When a module contains tasks that are
related by the fact that all must be executed with the same span of time, the module exhibits
temporal cohesion
...
The module is called when computed data exceed prespecified bounds
...
Combining the functions into a single
module can serve only to increase the likelihood of error propagation when a modification is
made to one of its processing tasks
...
When processing elements of a module are related and must be executed in a
specific order, procedural cohesion exists
...
High cohesion is
characterized by a module that performs one distinct procedural task
...

Rather it is important to strive for high cohesion and recognize low cohesion so that software
design can be modified to achieve greater functional independence
...
Coupling
depends on the interface complexity between modules, the point at which entry or reference
is made to a module, and what data pass across the interface
...
Simple connectivity among
modules results in software that is easier to understand and less prone to a "ripple effect",
caused when errors occur at one location and propagate through a system
...
6 provides examples of different types of module coupling
...
Each is unrelated and therefore no direct coupling occurs
...
As long as a simple argument list is present (i
...
, simple data
are passed; a one-to-one correspondence of items exists), low coupling (called data
coupling) is exhibited in this portion of structure
...
This occurs between modules b and a
...

Control coupling is very common in most software designs and is shown in Figure
13
...

Relatively high levels of coupling occur when modules are tied to an environment external
to software
...
External coupling is essential, but should be limited to a small
number of modules with a structure
...
Common coupling, as this mode is called, is shown in Figure
13
...
Modules c, g, and k each access a data item in a global data area (e
...
, a disk file or a
globally accessible memory area)
...
Later module g re-computes
and updates the item
...

Much later in processing module, k reads the item, attempts to process it, and fails, causing
the software to abort
...

Diagnosing problems in structures with considerable common coupling is time consuming and
difficult
...
" It does
mean that a software designer must be aware of potential consequences of common coupling
and take special care to guard against them
...
Secondarily,
content coupling occurs when branches are made into the middle of a module
...

The coupling modes just discussed occur because of design decisions made when
structure was developed
...
For example, compiler coupling ties source code to specific (and often nonstandard)
attributes of a compiler; operating system (OS) coupling ties design and resultant code to
operating system "hooks" that can create havoc when OS changes occur
...
Explain Design Heuristic For Effective Modularity
Once program structure has been developed, effective modularity can be achieved by
applying the various design concepts
...
Evaluate the "first iteration" of the program structure to reduce coupling and
improve cohesion
...
An exploded module
becomes two or more modules in the final program structure
...

An exploded module often results when common processing exists in two or more modules
and can be redefined as a separate cohesive module
...


2
...

The structure shown inside the cloud in Figure 13
...
All modules are “pancaked” below a single control module
...
The structure takes an oval
shape, indicating a number of layers of control and highly utilitarian modules at lower levels
...
Keep the scope of effect of a module within the scope of control of that module
...
The scope of control of module e is all modules that are
subordinate and ultimately subordinate to module e
...
7, if module e makes a decision that affects module r, we have a
violation of this heuristic, because module r lies outside the scope of control of module e
...
Evaluate module interfaces to reduce complexity and redundancy and improve
consistency
...
Interfaces should be
designed to pass information simply and should be consistent with the function of a module
...
e
...
The module in question should be reevaluated
...
Define modules whose function is predictable, but avoid modules that are overly
restrictive
...
7 Modules that have
internal "memory" can be unpredictable unless care is taken in their use
...
However, a module that arbitrarily restricts the size of a local
data structure, options within control flow, or modes of external interface will invariably require
maintenance to remove such restrictions
...
Strive for “controlled entry” modules by avoiding "pathological connections
...
Software is easier to
understand and therefore easier to maintain when module interfaces are constrained and
controlled
...


53

Chapter 17 : Software Testing
Technique
1
...
Using white-box
testing methods, the software engineer can derive test cases that
(1) guarantee that all independent paths within a module have been exercised at least once,
(2) exercise all logical decisions on their true and false sides,
(3) execute all loops at their boundaries and within their operational bounds,
(4) exercise internal data structures to ensure their validity
...

Errors tend to creep into our work when we design and implement function,
conditions, or controls that are out of the mainstream
...




We often believe that a logical path is not likely to be executed when, in fact, it
may be executed on a regular basis
...




Typographical errors are random
...
Many will be uncovered by syntax and type
checking mechanisms, but others may go undetected until testing begins
...


Each of these reasons provides an argument for conducting white-box tests
...
White-box testing is
far more likely to uncover them
...
Explain Cyclomatic Complexity
Cyclomatic complexity is a software metric that provides a quantitative measure of the
logical complexity of a program
...

An independent path is any path through the program that introduces at least one new set
of processing statements or a new condition
...


54

For example, a set of independent paths for the flow graph illustrated in Figure 17
...
The path
1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
is not considered to be an independent path because it is simply a combination of already
specified paths and does not traverse any new edges
...
2B
...
It should be noted that the basis set is not
unique
...

How do we know how many paths to look for? The computation of cyclomatic complexity
provides the answer
...

Complexity is computed in one of three ways:
1
...

2
...

3
...


Referring once more to the flow graph in Figure 17
...
The flow graph has four regions
...
V(G) = 11 edges _ 9 nodes + 2 = 4
...
V(G) = 3 predicate nodes + 1 = 4
...
2B is 4
...


3
...
That is, black-box testing enables the software engineer to derive sets of
input conditions that will fully exercise all functional requirements for a program
...
Rather, it is a complementary approach
that is likely to uncover a different class of errors than white-box methods
...

Unlike white-box testing, which is performed early in the testing process, black-box testing
tends to be applied during later stages of testing
...
Tests are
designed to answer the following questions:
• How is functional validity tested?
• How is system behavior and performance tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input values?
• How are the boundaries of a data class isolated?
• What data rates and data volume can the system tolerate?
• What effect will specific combinations of data have on system operation?
By applying black-box techniques, we derive a set of test cases that satisfy the following
Criteria :
(1) test cases that reduce, by a count that is greater than one, the number of additional test
cases that must be designed to achieve reasonable testing
...


Black-box testing methods :






Graph-Based Testing Methods
Equivalence Partitioning
Boundary Value Analysis
Comparison Testing
Orthogonal Array Testing

56

Chapter 18 : Software Testing
Strategies
1
...
The strategy
provides a road map that describes the steps to be conducted as part of testing, when these
steps are planned and then undertaken, and how much effort, time, and resources will be
required
...
A software testing strategy should be
flexible enough to promote a customized testing approach
...

The following issues must be addressed if a successful software testing strategy is to be
implemented:
Specify product requirements in a quantifiable manner long before testing commences
...
These
should be specified in a way that is measurable so that testing results are unambiguous
...

The specific objectives of testing should be stated in measurable terms
...

Understand the users of the software and develop a profile for each user category
...

Develop a testing plan that emphasizes “rapid cycle testing
...
” The feedback generated from these rapid cycle tests can be used to
control quality levels and the corresponding test strategies
...

Software should be designed in a manner that uses anti-bugging techniques
...
In addition, the design
should accommodate automated testing and regression testing
...

Formal technical reviews can be as effective as testing in uncovering errors
...

Conduct formal technical reviews to assess the test strategy and test cases
themselves
...
This saves time and also improves product quality
...

The test strategy should be measured
...


57

3
...
Using the component-level design description as a guide, important
control paths are tested to uncover errors within the boundary of the module
...
The unit test is white-box oriented, and the step can be conducted in parallel for
multiple components
...
The local data structure is examined to ensure that data stored
temporarily maintains its integrity during all steps in an algorithm's execution
...
All independent paths (basis paths) through the
control structure are exercised to ensure that all statements in a module have been executed
at least once
...


Because a component is not a stand-alone program, driver and/or stub software must be
developed for each unit test
...
5
...
Stubs serve to
replace modules that are subordinate (called by) the component to be tested
...

Unit testing is simplified when a component with high cohesion is designed
...


3
...
The objective is
to take unit tested components and build a program structure that has been dictated by
design
...
All components are combined in advance
...
And chaos usually results! A set of errors is encountered
...
Once these errors are corrected, new ones appear and the process continues
in a seemingly endless loop
...
The program is
constructed and tested in small increments, where errors are easier to isolate and correct;
interfaces are more likely to be tested completely; and a systematic test approach may be
applied
...
Modules are integrated by moving downward through the control hierarchy,
beginning with the main control module (main program)
...


The integration process is performed in a series of five steps:
1
...

2
...
e
...

3
...

4
...

5
...

The process continues from step 2 until the entire program structure is built
...
In a wellfactored program structure, decision making occurs at upper levels in the hierarchy and is
therefore encountered first
...
If
depth-first integration is selected, a complete function of the software may be implemented
and demonstrated
...
e
...
Because
components are integrated from the bottom up, processing required for components
subordinate to a given level is always available and the need for stubs is eliminated
...
Low-level components are combined into clusters (sometimes called builds) that perform a
specific software sub-function
...
A driver (a control program for testing) is written to coordinate test case input and output
...
The cluster is tested
...
Drivers are removed and clusters are combined moving upward in the program structure
...
7
...
Each of the clusters is tested using a driver (shown as a dashed block)
...

Drivers D1 and D2 are removed and the clusters are interfaced directly to Ma
...
Both Ma and Mb will
ultimately be integrated with component Mc, and so forth
...
In fact, if the top
two levels of program structure are integrated top down, the number of drivers can be
reduced substantially and integration of clusters is greatly simplified
...
New
data flow paths are established, new I/O may occur, and new control logic is invoked
...
In the context
of an integration test strategy, regression testing is the re-execution
of some subset of tests that have already been conducted to ensure that changes have not
propagated unintended side effects
...
Whenever software is corrected, some aspect of the software
configuration (the program, its documentation, or the data that support it) is changed
...


60

Regression testing may be conducted manually, by re-executing a subset of all test cases
or using automated capture/playback tools
...

The regression test suite (the subset of tests to be executed) contains three different
classes of test cases:
• A representative sample of tests that will exercise all software functions
...

• Tests that focus on the software components that have been changed
...

Therefore, the regression test suite should be designed to include only those tests that
address one or more classes of errors in each of the major program functions
...




Smoke Testing

Smoke testing is an integration testing approach that is commonly used when “shrinkwrapped” software products are being developed
...
In
essence, the smoke testing approach encompasses the following activities:
1
...
” A
build includes all data files, libraries, reusable modules, and engineered components that are
required to implement one or more product functions
...
A series of tests is designed to expose errors that will keep the build from properly
performing its function
...

3
...
The integration approach may be top down or bottom up
...
However,
frequent tests give both managers and practitioners a realistic assessment of integration
testing progress
...
It does not have to be
exhaustive, but it should be capable of exposing major problems
...


3
...




Validation Test Criteria

Software validation is achieved through a series of black-box tests that demonstrate
conformity with requirements
...

Deviation or error discovered at this stage in a project can rarely be
corrected prior to scheduled delivery
...




Configuration Review

An important element of the validation process is a configuration review
...
The configuration review is sometimes called an Audit
...
The software is used in a
natural setting with the developer "looking over the shoulder" of the user and recording errors
and usage problems
...

The beta test is conducted at one or more customer sites by the end-user of the software
...
Therefore, the beta test is a "live"
application of the software in an environment that cannot be controlled by the developer
...
As a result of problems reported during
beta tests, software engineers make modifications and then prepare for release of the
software product to the entire customer base
...
SYSTEM TESTING
A classic system testing problem is "finger-pointing
...
Rather
than indulging in such nonsense, the software engineer should anticipate potential interfacing
problems and
(1) design error-handling paths that test all information coming from other elements of the
system,
(2) conduct a series of tests that simulate bad data or other potential errors at the software
interface,
(3) record the results of tests to use as "evidence" if finger-pointing does occur,
(4) participate in planning and design of system tests to ensure that software is adequately
tested
...
Although each test has a different purpose,
all work to verify that system elements have been properly integrated and perform
allocated functions
...
If recovery is automatic (performed by the system
itself), re-initialization, check-pointing mechanisms, data recovery, and restart are evaluated
for correctness
...




Security Testing

Security testing attempts to verify that protection mechanisms built into a system will, in
fact, protect it from improper penetration
...
Anything goes! The tester may attempt
to acquire passwords through external clerical means; may attack the system with custom
software designed to breakdown any defenses that have been constructed; may overwhelm
the system, thereby denying service to others; may purposely cause system errors, hoping to
penetrate during recovery; may browse through insecure data, hoping to find the key to
system entry
...

The role of the system designer is to make penetration cost more than the value of the
information that will be obtained
...
In essence, the
tester who performs stress testing asks: "How high can we crank this up before it fails?"
Stress testing executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume
...

Essentially, the tester attempts to break the program
...

Performance testing is designed to test the run-time performance of software within the
context of an integrated system
...
Even at the unit level, the performance of an individual module may be
assessed as white-box tests are conducted
...


63

Chapter 19 : Technical Metrics For
Software
1
...
g
...
g
...

Referring to the factors noted in the figure, McCall and his colleagues provide the following
descriptions:

Correctness
...

Reliability
...
[It should be noted that other, more complete definitions of reliability have
been proposed
...

The amount of computing resources and code required by a program to perform its
function
...

Extent to which access to software or data by unauthorized persons can be controlled
...

Effort required to learn, operate, prepare input, and interpret output of a program
...

Effort required to locate and fix an error in a program
...

Effort required to modify an operational program
...

Effort required to test a program to ensure that it performs its intended function
...

Effort required to transfer the program from one hardware and/or software system
environment to another
...

Extent to which a program [or parts of a program] can be reused in other applications
— related to the packaging and scope of the functions that the program performs
...

Effort required to couple one system to another
...
Therefore, a set of metrics are defined and used to develop expressions for each of
the factors according to the following relationship:
Fq = c1 _ m1 + c2 _ m2 +
...

The following metrics are used in the grading scheme:
Auditability
...

Accuracy
...

Communication commonality
...

Completeness
...

Conciseness
...

Consistency
...

Data commonality
...

Error tolerance
...

Execution efficiency
...

Expandability
...

Generality
...


65

Hardware independence
...

Instrumentation
...

Modularity
...

Operability
...

Security
...

Self-documentation
...

Simplicity
...

Software system independence
...

Traceability
...

Training
...


66

These notes are for quick & selective study
...
Pressman

All The Best…
- Gaurav Sharma

67



---