 The importance of high-quality software

Software development is a vital activity in modern society, and is likely

to have increasing significance in the future. Software manages our bank
accounts, pays our salaries, controls the aircraft we fly in, regulates
power generation and distribution, controls our communications, etc.

 Characteristics of high-quality software

1. High quality software shares the following obvious attributes:

2. high quality software is intuitive and easy to use -- the right things
happen "automatically"

3. it is efficient -- people use computers to get things done quickly

4. above all, high quality software is correct -- it always produces the

advertised results and does not crash!

 The need for precision in the specification of software

The notion that software components can be reused is a principal
motivation of object-oriented programming, and has virtually become a
postulate of programming. To reuse a previously written software
component (or create a new one), a software engineer must have a
precise description of its behavior. This precision is essential as even a
minor misconception of the function of a component that is unapparent
at the outset may cause serious errors that are difficult and expensive to
correct later in the process.

 Typical software development phases

Software development models commonly subdivide the process into

phases similar to the following :

1. requirements analysis: determine user needs

2. specification: describe precisely what the role of the software will be

3. design: determine how to realize the software, and devise overall

organization

4. implementation: formulate the algorithms and program(s)

5. verification: certify that the program(s) meet the specification

6. maintenance: perform ongoing changes and corrections after the
software is in use

 The role of formal methods

Formal methods are intended to systematize and introduce rigor into all
the phases of software development. This helps us to avoid overlooking
critical issues, provides a standard means to record various assumptions
and decisions, and forms a basis for consistency among many related
activities. By providing precise and unambiguous description
mechanisms, formal methods facilitate the understanding required to
coalesce the various phases of software development into a successful
endeavour.

The programming language used for software development furnishes

precise syntax and semantics for the implementation phase, and this has
been true since people began writing programs. But precision in all but
this one phase of software development must derive from other sources.
The term "formal methods" pertains to a broad collection of formalisms
and abstractions intended to support a comparable level of precision for
other phases of software development. While this includes issues
currently under active development, several methodologies have reached
a level of maturity that can be of benefit to practitioners.

There is a discernible tendency to merge discrete mathematics and

formal methods for software engineering (e.g., see the books by Denvir,
Ince, and Woodcock & Loomes). Many such topics do indeed support
software engineering and it is neither possible nor desirable to avoid
these topics when pursuing formal methods. But we will not take the
approach that applying discrete mathematics to software engineering
assures germane formal methods. The overriding concern of software
engineering is the creation of high quality software systems. With
"formal methods" we pursue melding those things that nurture rigor and
precision into this endeavor. While our focus on the activities that
precede the actual programming itself does lead to machine independent
abstractions often associated with mathematics, much of the material
has been developed (or tailored) to suit the context of software creation.

Some specific formalisms used in software development include:

algebraic specification (including OBJ) -- used for specification and

verification, predicate logic (including Z) -- used for specification and
verification, statecharts -- used for specification of "reactive" systems

UML -- used primarily for design, and also for requirements analysis.

Definition

Formal methods in software engineering or development are

mathematical techniques that are used in the design, implementation
and testing of computer systems. The application of mathematical
methods in the development and verification of software is very labor
intensive, and thus expensive. Therefore, it is not feasible to check all the
wanted properties of a complete computer program in detail.
 Type formal methods in Software Development

Formal methods include

Formal specification

Specification analysis and proof

Transformational development
Program verification

 Classification of Formal Methods Semantics

As with programming language semantics, styles of formal methods may

be roughly classified as follows:

Denotational semantics, in which the meaning of a system is expressed

in the mathematical theory of domains. Proponents of such methods rely
on the well-understood nature of domains to give meaning to the system;
critics point out that not every system may be intuitively or naturally
viewed as a function.

Operational semantics, in which the meaning of a system is expressed as

a sequence of actions of a simpler computational model. Proponents of
such methods point to the simplicity of their models as a means to
express clarity; critics counter that the problem of semantics has just
been delayed.

Axiomatic semantics, in which the meaning of the system is expressed in

terms of preconditions and post conditions which are true before and
after the system performs a task, respectively. Proponents note the
connection to classical logic; critics note that such semantics never really
describe what a system does (merely what is true before and afterwards).

 Uses of Formal Methods

Formal methods can be applied at various points through the

development process.

 Specification

Formal methods may be used to give a description of the system to be

developed, at whatever level(s) of detail desired. This formal description
can be used to guide further development activities additionally, it can
be used to verify that the requirements for the system being developed
have been completely and accurately specified. The need for formal
specification systems has been noted for years. In the ALGOL 58
report,John Backus presented a formal notation for describing
programming language syntax, later named Backus normal form then
renamed Backus–Naur form (BNF).
Development: Once a formal specification has been produced, the
specification may be used as a guide while the concrete system is
developed during the design process (i.e., realized typically in software,
but also potentially in hardware). For example:

•If the formal specification is in an operational semantics, the observed

behaviour of the concrete system can be compared with the behaviour of
the specification (which itself should be executable). Additionally, the
operational commands of the specification may be amenable to direct
translation into executable code.

•If the formal specification is in an axiomatic semantics, the

preconditions and postconditions of the specification may become
assertions in the executable code.

 Verification

Once a formal specification has been developed, the specification may be

used as the basis for proving properties of the specification (and
hopefully by inference the developed system).

 Human-directed proof

Sometimes, the motivation for proving the correctness of a system is not

the obvious need for reassurance of the correctness of the system, but a
desire to understand the system better. Consequently, some proofs of
correctness are produced in the style of mathematical proof:
handwritten (or typeset) using natural language, using a level of
informality common to such proofs. A "good" proof is one which is
readable and understandable by other human readers.

Critics of such approaches point out that the ambiguity inherent in

natural language allows errors to be undetected in such proofs; often,
subtle errors can be present in the low-level details typically overlooked
by such proofs. Additionally, the work involved in producing such a good
proof requires a high level of mathematical sophistication and expertise.

 Automated proof

In contrast, there is increasing interest in producing proofs of

correctness of such systems by automated means. Automated techniques
fall into three general categories: •Automated theorem proving, in which
a system attempts to produce a formal proof from scratch, given a
description of the system, a set of logical axioms, and a set of inference
rules.

•Model checking, in which a system verifies certain properties by means

of an exhaustive search of all possible states that a system could enter
during its execution. •Abstract interpretation, in which a system verifies
an over-approximation of a behavioural property of the program, using a
fixpoint computation over a (possibly complete) lattice representing it.
 Applications of formal methods

Their principal benefits are in reducing the number of errors in systems

so their main area of applicability is critical systems:
1.
Air traffic control information systems,
2. Railway signalling systems
3.
Spacecraft systems
4.
Medical control systems

Formal methods are applied in different areas of hardware and software,

including routers, Ethernet switches, routing protocols, and security
applications.

In this area, the use of formal methods is most likely to be cost-

effective Formal methods have limited practical applicability

It is more cost effective to first determine what the crucial components

of the software are. These parts can then be isolated and studied in detail
by creating mathematical models and verifying them.

 Software development

In software development, formal methods are mathematical approaches

to solving software (and hardware) problems at the requirements,
specification, and design levels. Formal methods are most likely to be
applied to safety-critical or security-critical software and systems, such
as avionics software. Software safety assurance standards, such as DO-
178B, DO-178C, and Common Criteria demand formal methods at the
highest levels of categorization.

For sequential software, examples of formal methods include the B-

Method, the specification languages used in automated theorem proving,
RAISE, and the Z notation. In functional programming, property-based
testing has allowed the mathematical specification and testing (if not
exhaustive testing) of the expected behaviour of individual functions.

The Object Constraint Language (and specializations such as Java

Modeling Language) has allowed object-oriented systems to be formally
specified, if not necessarily formally verified.

For concurrent software and systems, Petri nets, process algebra, and
finite state machines (which are based on automata theory) allow
executable software specification and can be used to build up and
validate application behaviour.

 Software verification

Important considerations when dealing with a formal system:

• Soundness/Correctness.

This property states that every property that can be obtained using the
formal system/calculus is semantically true in some sense.
– Slogan: “What you can prove is also true.”

 Completeness.

This property is the opposite implication of correctness. It states that for

every true sentence there is also a proof in the formal system/calculus.

– Slogan: “What is true can also be proven.” • Expressive power.

– Slogan: “Can I formulate all my properties in the language?”

 Decidability.

If a formal system is decidable, then all proofs can be found

automatically by a program.

Slogan: “Can a computer do my work?”

 Why use Formal Methods?

1. Improve quality of software

system Fitness for purpose

2. Maintainability

3. Ease of construction
4. Higher confidence in software product

5. Reveal ambiguity, incompleteness, and inconsistency in

system Detect design flaws

6. Determine correctness

 Some Limitations to Formal methods

Formal methods have not become mainstream software development

techniques as was once predicted.

The scope of formal methods is limited. They are not well-suited to

specifying and analysing user interfaces and user interaction

Formal methods are hard to scale up to large

systems Time consuming and expensive.

Difficult to use this model as a communication mechanism for non-

technical personnel.

Extensive training is required since only few developers have the

essential knowledge to implement this model.

 When and where to use Formal Methods?

1. Introduce FM into existing systems
2.
Verify critical properties
3.
Facilitate maintenance and
reimplementation Introduce FM into new
systems
4.
Capture requirements precisely
5.
Reduce ambiguity
6.
Guide software development process

7.
Basis for testing o Formalize requirements analysis and design

 Connectives

The study of atomic propositions is pretty boring. We therefore now

introduce a number of connectives which will allow us to build up
complex propositions. The connectives we introduce are:

and (& or .) ∨ or
(|or +)
¬ not (∼ )

⇒ implies (⊃or→)
⇔ iff

Some books use other notations; these are given in parentheses.

 AND Connective

Any two propositions can be combined to form a third proposition called

the conjunction of the original propositions.

Definition: If p and q are arbitrary propositions, then the conjunction of

p and q is written p∧q and will be true iff both p and q are true

We can summarise the operation of ∧ in a truth table. The idea of a

truth table for some formula is that it describes the behaviour of a
formula under all possible interpretations of the primitive propositions
the are included in the formula. If there are n different atomic
propositions in some formula, then there are 2n different lines in the
truth table for that formula. (This is because each proposition can take
one 1 of 2 values — true or false.) Let us write T for truth, and F for
falsity.

Then the truth table for p∧q is:

 OR Connective

Any two propositions can be combined by the word ‘OR’ to form a third
proposition called the disjunction of the originals.

Definition: If p and q are arbitrary propositions, then the disjunction of

p and q is written p∨q and will be true iff either p is true, or q is true, or
both p and q are true.

The operation of ∨ is summarised in the following truth table:

 Implies Connective (i.e., If... Then...)

Many statements, particularly in mathematics, are of the form: if p is

true then q is true.

Another way of saying the same thing is to write:

p implies q.

In propositional logic, we have a connective that combines two

propositions into a new proposition called the conditional, or
implication of the originals, that attempts to capture the sense of such a
statement.

 Introduction to Predicate

In formal methods, the natural language is scan for predicates. Each

functions and variables (bounded or free) will be translated into an
expression also usually joined using operators. Then all possible
qualifiers will be listed. Sometime a truth table is used to cover all
possible value.

But this is not practical as most statement actually contains variables

and changes in the variables will change the validity of the statement to
true or false, because some statement refers to a set of different elements.

Therefore we use predicate to handle such statement. For this subject we

will use First-Order Logic only.

To use predicate there must at least two (2) elements;

1. A variable or a constant

2. A function that will be performed on or by the variable(s)

For example:
An ostrich has wing can fly, a eagle has wing can fly

The constant object here is “Wing”

The variable object here is either “Ostrich” or “Eagle”

The function here is “Fly”

 Predicate quantifiers

The following are quantifiers that can be use with a predicate;

Qualifier is normally place with an object (variable or constant)

 Predicates and Truth Table

Because the result of a predict function can be true or false, Truth tables
can also be used with predicates.

For example:

For a one function predict A = ⌐ Fly (Airplane)

For a two (2) function predict Fly (Airplane) ^ Fly (Birds)

= ∀Airplane Fly (Airplane)

= ∀Birds Fly (Birds)

 Bound and Free (Bound) variables

This term is use in mathematics, in formal languages (mathematical

logic and computer science).

A free variable is a notation that specifies places in an expression where

substitution may take place.

A bound variable is a notation that specifies places in an expression no

changes can take place.

The idea is related to a symbol that will later be replaced with strings or
values. It can also be represented by a wildcard character that stands for
an unspecified symbol. Based on the example, below:

∀x, function (x, y)

∃x, function (x, y)
If symbol x in the function represents a bound variable because it is
stated in the qualifier. The symbol y in the function represents a free
variable because it is not stated in the qualifier. The symbol w (or any
other value) is a neither bound nor free as it was never use in the
function.

∀x on the left refers to an instance of x

function (x, y) on the right should also refers to an instance of x

But technically the left x and right x could mean something else but this
will cause a lot of confusion, thus the symbol on the left is usually kept in
consistent with the symbol on the right

Set is very basic mathematical concept use to group objects. It is

basically used to show the relationship between each type of objects. The
Venn diagram is always used to picture the set theory graphically. A set
is a group that may contain none or one (1) or more elements.

In formal methods, there are many ways to use set theory. One example
will be to categories many types of objects available in a system mostly in
the form of data. Base on the purpose of the particular system or
software the objects are properly grouped and then related to one
another.

 Universe (U)

The Universe represents the scope of the system. All elements that is
within the universe is considered necessary and elements not mentioned
in the universe is considered none existence. Thus, it is very important
that we define the universe accurately.
 Elements

All elements in a set must be unique. In the Venn Diagrams the

individual small letter element name are prefix with a dot. Capital Letter
names is use to group many duplicates elements (sets) do not have a dot.
The sequence or arrangement of the elements is not important.

There are two (2) ways to describe elements in a set.

1. Using a rule or semantic description:

A is the set whose members are the first four positive integers.

B is the set of colours of the Malaysian flag.

Listing each member of the set or extensional definition. Elements in a

list are enclosed inside curly brackets separated by commas.
 Finite Elements

Some elements may be finite (with a starting and ending value) thus it
can be representation as:

To show a value from 1 to 100 is represented as {1, 2,

3, ..., 100} To show a value between 1 to 100 is
represented as {2, 3, ..., 99}

F contains a number power by 2 minus 4 such that (: or |) all the

numbers are integer starting from 0 to 19 is represented as
F = {n2 − 4 | n is an integer; and 0 ≤
n ≤ 19} Or

F = {n2 − 4 : n is an integer; and 0 ≤ n ≤ 19}

 Infinite Elements

Some elements may be infinite (no ending value) thus it can be

representation as:

To show a integer value above 1 is represented as {1, 2,

3, ...} F contains all the teachers in FTMS Global KL is
represented as F = { F | F all the teachers in FTMS
Global KL } Or

F = { F : F all the teachers in FTMS Global KL }

 Cardinality

Cardinality means the number of elements in a set. Cardinality is

denoted by vertical bars around the set.

For example

|{1,3,9,15}|=4
|{1,2,3,...}|=∞

 Reserve Letter used by Mathematician

P Set of all primes: P = {2, 3, 5, 7, 11, 13, 17, ...}

N Set of all natural numbers: N = {1, 2, 3, . . .}

Z Set of all integers (positive/ negative / zero): Z = {..., −2, −1, 0, 1, 2, ...}

Q Set of all rational numbers (that is, the set of all proper and improper
fractions):

R Set of all real numbers (rational numbers, irrational numbers)

C Set of all complex numbers: C = {a + bi: a, b ∈ R}.

H Set of all Quaternions: For example, 1 + i + 2j − k ∈ H.

 Disjoint Sets
If every member of set A has no relation with set B and vice versa then
we say that A disjoint B. There is no special symbol to show this
relationship.

 NULL Set ( ∅ )

Every universe or set or subset contains a NULL set. A null set is an

empty set ({ }) that carries no elements. We can say that the NULL set is
a subset for every set.

 Family Sets

There are times when a set does not contain individual elements but it
contains many subsets. Conveniently this is called a family set and is it
describes using the curly bracket within a curly bracket.

A = { {1, 2, 3, 4, 5} , {6, 7, 8, 9, 10} , {11, 12, 13, 14, 15} }

 Power Sets ( P(setName) )

Remember that a set is a group that may contain none or one (1) or more
elements. A power set means to show how many possible different ways
to group all the elements in a set. In other words, power set is the set of
all subsets of a given set.
A = {1, 2, 3}, A has 3 elements, there is 8 possible ways to arrange
this 23 = 8. P(A) = { ∅ , {1}, {2}, {3}, {1,2}, {1,3}, {2,3}, {1, 2, 3} }

 Terminology used to describe sets Operation Given the

following sets:

U = {-1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10}

A = {-1, 0, 1, 2, 5, 6, 9, 10}

B = {1, 2, 4, 6, 8, 10}

C={1,3,5,7,9}
Union (∪): Add in all elements that are found in
both sets. A∪B={-1,0,1,2,4,5,6,8,9,10} A∪C={-
1,0,1,2,3,5,6,7,9,10} B∪C={1,2,3,4,5,6,7,8,9,10}
A∪B ∪C=U

Intersect (∩): Show only elements that is found only

in both sets A∩B={1,2,6,10} A∩C={1,5,9} B∩C={1}

Difference (-): Also known as subtract, this show only elements that is
found in this set but NOT found in another sets

A-B={-1,0,5,9} A-C={-1,0,2,6,10} B- B∩C={2,4,6,8,10}

A={4,8} C-A={3,7}

Complement (‘): Show only elements that is found NOT found this sets

A’ = {3, 4, 7, 8} B’ = {-1, 0, 3, 5, 7, 9} C’ = {-1, 0, 2, 4, 6, 8, 10}

(A ∪ B)’ = {3, 7} (A ∩ B)’ = {-1, 0, 3, 4, 5, 7, 8, 9}

Difference can be seen as the same as complement.

Equality: Both sets must have exactly the same number of elements with
exactly the same value. Take note that sequence and duplication does not
affect the set.

A = {3, 4, 7, 8} Z = {4, 3, 7, 8} therefore A = Z B =

{3, 4, 7, 8, 4} Y = {3, 4, 7, 8, 7} therefore B = Y
A=B=Y=Z

Compatible: Two sets are compatible if all element in one of the set can
fit nicely inside another set.

A = {x, b} Z = {x, b, c} therefore A is compatible to Z Because

elements in A (x and b) can fit inside element in Z also have (x, b)

A = {x, b} Y = {b, c} therefore A is not compatible to Y Because

elements in Y cannot contain (x) and A cannot contain (c).

 Background

A sequence is simply a list, such as 2, 4, 6, ... where the numbers 2, 4, etc.

are the terms of the sequence.
Please take time to understand this terminology:

Terms (usually represented with a subscript italic letter “n”) refers to the
index for a given sequence starting from 0 to infinite. The sequence
(usually represented with any small letter “a”) refers to the value for a
specific term. For example:

The term 0 has the number 0

The term 1 has the number 2

The term 2 has the number 4

The term 3 has the number 6

The formula for this sequence will be 2n (2 multiple by Terms)

 Type of sequence

There are two type of sequence;

1. Finite sequence A finite sequence has both a starting value

and an ending value. E.g. 1, 2, 3, 4, 5 and 6

2. Infinite sequence An infinite sequence has both a starting value

but no ending value E.g. 1, 2, 3, 4, 5, 6 …

Sequences can be applied in two areas;

 Arithmetic sequence

Arithmetic sequence a.k.a. Arithmetic progression or is a sequence of

numbers that goes from one term to the next by always adding (or
subtracting) the same value.

 Geometric sequence

Geometric sequence a.k.a. geometric progression is a sequence of

numbers that goes from one term to the next by always multiplying (or
dividing) by the same value. Value multiple by the same value, Value
divided by the same value.
How to find a SEQUENCE for a given term Arithmetic
sequence

Finite or Infinite Sequence

a = the number for the first term in the sequence

= the common difference (first term - second

term) n = the number of terms in the
sequence needed

 Geometric sequence

Finite or Infinite Sequence

= the number for the first term in the

sequence r = ratio for the sequence
n = the number of terms in the sequence needed
 What is proof?

Proof simply means to be able to show that a statement is correct or true.

No matter how the statement is twisted and turned or set against many
different scenario, that statement comes up with the constant answer.
Before a statement can be proof it can have two (2); the conditions
followed by the result. For example, if it rains then I will be wet. This can
then express in a using proposition symbols as;

Rain → I am wet (if it rains then I will be wet)

 Terminology

1) Conjecture/ Hypothesis

This is a statement that is believe to be true but has yet to C be proven.

2) Axiom/ Postulate

If the statement is taken for granted to be true even though it was never
tested, but base on logic it is assume to be true.

3) Paradox/ Antinomy

This is a statement which appears to contradict itself or contrary to

expectations 4) Theorem

This is a statement that has been proven to be true.

5) Un-decidable

This is a statement that cannot be proven right or wrong.

6) Lemma

A proven theorem that is used to prove other

statements 7) Converse

Theorem that is reversed or turned upside down or inward out thus a

converse of a theorem need not be always true.

 Proofing Methods

1. Direct Proof

In direct proof, the conclusion is established by logically combining the

axioms, definitions, and earlier theorems. From the expression one can
directly see the answer.

For example: Rain →I am wet

2. Contradiction Proof
In proof by contradiction, if that statement is true and we logically
contradict it then it will not be true anymore.

For example: Rain → I am wet

No Rain →I am Dry

3. Contra-positive/ Transposition Proof

Proof by transposition or contra-positive turns the statement inside out

and upside down. This method swaps the result into the condition and
negates both the result and condition.

 Software Development Life Cycle

The SDLC can be divided into seven (7) stages;

1. Initial Study: Team collects information regarding the problem.

2. Analysis: Team discover the source of the problem.

3. Design: Team creates the specification for the solution.

4.Development: Team built the solution base on the given specification.

5. Testing: Test the software to make sure it solves the problem.

6.Implementation: Team prepare the environment to accept software.

7. Review: Team and client review the software.

 Testing Concept

Test Flow

1. Top Down

This is a test flow that starts from a general level down to the specific
detail level. Example for an inventory system will be to start from a main
menu and slowly make the way down to the product module.

2. Bottom Up

This is a test flow that starts from a detail specific level up to the general
level. Example for an inventory system will be to start from the products
and slowly make the way up to the main menu.

 Test Size
1. Unit Testing

This is a test that focuses on an individual specific independent module.

Example for an inventory system will be to start test the products
module alone and then the customer module alone.

2. Integration Testing

This is a test that starts to join individual module. Example for an

inventory system will be after testing out the product and customer
module to test out the sales invoice module.

3. System Testing

This is a test that starts to studies the system environment surrounding

the software. Example for an inventory system will be to test if the bar
code reader at the POS can read the barcode label on the product.

4. User Acceptance Testing

This is the final a test where the end user will physically tested out the
system themselves using real life data but still in a control testing
environment. Example for an inventory system will be to ask the POS
staff to test out the POS system and enter 100 products and produce the
correct balance on the receipt.

 Software

Software is more than just a program code. A program is an executable

code, which serves some computational purpose. Software is considered
to be collection of executable programming code, associated libraries
and documentations. Software, when made for a specific requirement is
called software product.

 Engineering

Engineering on the other hand, is all about developing products, using

well-defined, scientific principles and methods.

 Software Development

Software development refers to a set of computer science activities

dedicated to the process of creating, designing, deploying and supporting
software. Software itself is the set of instructions or programs that tell a
computer what to do. It is independent of hardware and makes
computers programmable. There are three basic types:
System software to provide core functions such as operating systems,
disk management, utilities, hardware management and other
operational necessities. Programming software to give programmers
tools such as text editors, compilers, linkers, debuggers and other tools
to create code.

Application software (applications or apps) to help users perform

tasks. Office productivity suites, data management software, media
players and security programs are examples. Applications also refers to
web and mobile applications like those used to shop on Amazon.com,
socialize with Facebook or post pictures to Instagram.1

 Software Developer

Software developers have a less formal role than engineers and can
be closely involved with specific project areas — including writing code.
At the same time, they drive the overall software development lifecycle —
including working across functional teams to transform requirements
into features, managing development teams and processes, and
conducting software testing and maintenance.3

 Software Engineering

Software engineering is an engineering branch associated with

development of software product using well-defined scientific principles,
methods and procedures. The outcome of software engineering is an
efficient and reliable software product.

Definitions

IEEE defines software engineering as:

The application of a systematic, disciplined, quantifiable approach to the

development, operation and maintenance of software; that is, the
application of engineering to software.

The study of approaches as in the above statement.

Fritz Bauer, a German computer scientist, defines software engineering

as:

Software engineering is the establishment and use of sound engineering

principles in order to obtain economically viable software that is reliable
and work efficiently on real machines.
 Software Evolution

The process of developing a software product using software engineering

principles and methods is referred to as software evolution. This
includes the initial development of software and its maintenance and
updates, till desired software product is developed, which satisfies the
expected requirements.

Evolution starts from the requirement gathering process. After which

developers create a prototype of the intended software and show it to the
users to get their feedback at the early stage of software product
development. The users suggest changes, on which several consecutive
updates and maintenance keep on changing too. This process changes to
the original software, till the desired software is accomplished.

Even after the user has desired software in hand, the advancing
technology and the changing requirements force the software product to
change accordingly. Re-creating software from scratch and to go one-on-
one with requirement is not feasible. The only feasible and economical
solution is to update the existing software so that it matches the latest
requirements.

 Software Evolution Laws

Lehman has given laws for software evolution. He divided the software
into three different categories:

1. S-type (static-type) - This is a software, which works strictly

according to defined specifications and solutions. The solution and
the method to achieve it, both are immediately understood before
coding. The s-type software is least subjected to changes hence this is
the simplest of all. For example, calculator program for mathematical
computation.

2. P-type (practical-type) - This is a software with a collection of

procedures. This is defined by exactly what procedures can do. In this
software, the specifications can be described but the solution is not
obvious instantly. For example, gaming software.

3. E-type (embedded-type) - This software works closely as the

requirement of real-world environment. This software has a high
degree of evolution as there are various changes in laws, taxes etc. in
the real world situations. For example, Online trading software.

 E-Type software evolution

Lehman has given eight laws for E-Type software evolution -

1. Continuing change - An E-type software system must continue to

adapt to the real-world changes, else it becomes progressively less
useful.

2. Increasing complexity - As an E-type software system evolves, its

complexity tends to increase unless work is done to maintain or
reduce it.

3. Conservation of familiarity - The familiarity with the

software or the knowledge about how it was developed, why was it
developed in that particular manner etc. must be retained at any cost,
to implement the changes in the system.

4. Continuing growth- In order for an E-type system intended to

resolve some business problem, its size of implementing the changes
grows according to the lifestyle changes of the business.

5. Reducing quality - An E-type software system declines in quality

unless rigorously maintained and adapted to a changing operational
environment.
6. Feedback systems- The E-type software systems constitute multi-
loop, multi-level feedback systems and must be treated as such to be
successfully modified or improved.

7. Self-regulation - E-type system evolution processes are self-

regulating with the distribution of product and process measures
close to normal.

8. Organizational stability - The average effective global activity rate

in an evolving E-type system is invariant over the lifetime of the
product.

 Software Paradigms

Software paradigms refer to the methods and steps, which are taken
while designing the software. There are many methods proposed and are
in work today, but we need to see where in the software engineering
these paradigms stand. These can be combined into various categories,
though each of them is contained in one another:
 Need of Software development

The need of software development arises because of higher rate of

change in user requirements and environment on which the software is
working.

1. Large software - It is easier to build a wall than to a house or

building, likewise, as the size of software become large engineering
has to step to give it a scientific process.

2. Scalability- If the software process were not based on scientific and

engineering concepts, it would be easier to re-create new software
than to scale an existing one.

3. Cost- As hardware industry has shown its skills and huge

manufacturing has lower down he price of computer and electronic
hardware. But the cost of software remains high if proper process is
not adapted.

4. Dynamic Nature- The always growing and adapting nature of

software hugely depends upon the environment in which user works.
If the nature of software is always changing, new enhancements need
to be done in the existing one. This is where software engineering
plays a good role.
5. Quality Management- Better process of software development
provides better and quality software product.

 Characteristics of good software

A software product can be judged by what it offers and how well it can
be used. This software must satisfy on the following grounds:

Operational
Transitional
Maintenance

Well-engineered and crafted software is expected to have the following

characteristics:

 Operational

This tells us how well software works in operations. It can be measured

on:

Budget
Usability

Efficiency
Correctness
Functionality
Dependability
Security

Safety

 Transitional

This aspect is important when the software is moved from one platform
to another:

1. Portability

2. Interoperability

3. Reusability

4. Adaptability

 Maintenance

This aspect briefs about how well a software has the capabilities to
maintain itself in the ever-changing environment:

Modularity

Maintainability
Flexibility
Scalability

In short, Software engineering is a branch of computer science, which

uses well-defined engineering concepts required to produce efficient,
durable, scalable, in-budget and on-time software products.

Software Development Life Cycle, SDLC for short, is a well-defined,

structured sequence of stages in software development to develop the
intended software product.

 SDLC Activities

SDLC provides a series of steps to be followed to design and develop a

software product efficiently. SDLC framework includes the following
steps:
Communication: This is the first step where the user initiates the request
for a desired software product. He contacts the service provider and tries
to negotiate the terms. He submits his request to the service providing
organization in writing.

Requirement Gathering: This step onwards the software development

team works to carry on the project. The team holds discussions with
various stakeholders from problem domain and tries to bring out as
much information as possible on their requirements. The requirements
are contemplated and segregated into user requirements, system
requirements and functional requirements.

 Project Estimation Techniques

We discussed various parameters involving project estimation such as

size, effort, time and cost.
Project manager can estimate the listed factors using two broadly
recognized techniques:

 Decomposition Technique

This technique assumes the software as a product of various

compositions. There are two main models -

Line of Code Estimation is done on behalf of number of line of codes in

the software product.
Function Points Estimation is done on behalf of number of function
points in the software product.

 Empirical Estimation Technique

This technique uses empirically derived formulae to make

estimation.These formulae are based on LOC or FPs.

 Putnam Model

This model is made by Lawrence H. Putnam, which is based on Norden’s

frequency distribution (Rayleigh curve). Putnam model maps time and
efforts required with software size.

 COCOMO
COCOMO stands for COnstructive COst MOdel, developed by Barry W.
Boehm. It divides the software product into three categories of software:
organic, semi-detached and embedded.

 Project Scheduling

Project Scheduling in a project refers to roadmap of all activities to be

done with specified order and within time slot allotted to each activity.
Project managers tend to define various tasks, and project milestones
and arrange them keeping various factors in mind. They look for tasks
lie in critical path in the schedule, which are necessary to complete in
specific manner (because of task interdependency) and strictly within
the time allocated. Arrangement of tasks which lies out of critical path
are less likely to impact over all schedule of the project.

For scheduling a project, it is necessary to -

Break down the project tasks into smaller, manageable

form Find out various tasks and correlate them

Estimate time frame required for each

task Divide time into work-units

Assign adequate number of work-units for each task

Calculate total time required for the project from start to finish

 Resource management
All elements used to develop a software product may be assumed as
resource for that project. This may include human resource, productive
tools and software libraries. The resources are available in limited
quantity and stay in the organization as a pool of assets. The shortage of
resources hampers the development of project and it can lag behind the
schedule. Allocating extra resources increases development cost in the
end. It is therefore necessary to estimate and allocate adequate
resources for the project. Resource management includes -
Defining proper organization project by creating a project team and
allocating responsibilities to each team member

Determining resources required at a particular stage and their

availability

Manage Resources by generating resource request when they are

required and de-allocating them when they are no more needed.

 Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software

development project. Hence, they must be clear, correct and well-
defined. A complete Software Requirement Specifications must be:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized

 Software Requirements

We should try to understand what sort of requirements may arise in the

requirement elicitation phase and what kinds of requirements are
expected from the software system.
Broadly software requirements should be categorized in two categories:

 Functional Requirements

Requirements, which are related to functional aspect of software fall into

this category. They define functions and functionality within and from
the software system. Examples -

Search option given to user to search from various invoices. User should
be able to mail any report to management.

Users can be divided into groups and groups can be given separate
rights. Should comply business rules and administrative functions.

Software is developed keeping downward compatibility intact.

 Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall

into this category. They are implicit or expected characteristics of
software, which users make assumption of.

Non-functional requirements include -

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility

Must Have: Software cannot be said operational without them.

Should have: Enhancing the functionality of software.

Could have: Software can still properly function with these

requirements.

Wish list: These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should

have’ is a matter of debate with stakeholders and negation, whereas
‘could have’ and ‘wish list’ can be kept for software updates.

 User Interface requirements

UI is an important part of any software or hardware or hybrid system. A

software is widely accepted if it is -

easy to operate
quick in response
effectively handling operational errors
providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software.
UI is the only way for users to perceive the system. A well performing
software system must also be equipped with attractive, clear, consistent
and responsive user interface. Otherwise, the functionalities of software
system cannot be used in convenient way. A system is said be good if it
provides means to use it efficiently. User interface requirements are
briefly mentioned below:
Content presentation
Easy Navigation
Simple interface
Responsive
Consistent UI elements
Feedback mechanism
Default settings
Purposeful layout
Strategical use of colour and texture.
Provide help information
User centric approach
Group based view settings.

 Software System Analyst

System analyst in an IT organization is a person, who analyzes the

requirement of proposed system and ensures that requirements are
conceived and documented properly & correctly. Role of an analyst
starts during Software Analysis Phase of SDLC. It is the responsibility of
analyst to make sure that the developed software meets the
requirements of the client.
Software design is a process to transform user requirements into some
suitable form, which helps the programmer in software coding and
implementation.

For assessing user requirements, an SRS (Software Requirement

Specification) document is created whereas for coding and
implementation, there is a need of more specific and detailed
requirements in software terms. The output of this process can directly
be used into implementation in programming languages.

Software design is the first step in SDLC (Software Design Life Cycle),
which moves the concentration from problem domain to solution
domain. It tries to specify how to fulfil the requirements mentioned in
SRS.

 Software Design Levels

Software design yields three levels of results:

1. Architectural Design - The architectural design is the highest

abstract version of the system. It identifies the software as a system
with many components interacting with each other. At this level, the
designers get the idea of proposed solution domain.

2. High-level Design- The high-level design breaks the ‘single entity-

multiple component’ concept of architectural design into less-
abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design focuses on how the
system along with all of its components can be implemented in forms
of modules. It recognizes modular structure of each sub-system and
their relation and interaction among each other.

3. Detailed Design- Detailed design deals with the implementation

part of what is seen as a system and its sub-systems in the previous
two designs. It is more detailed towards modules and their
 implementations. It defines logical structure of each module and
their interfaces to communicate with other modules.

 Modularization

Modularization is a technique to divide a software system into multiple

discrete and independent modules, which are expected to be capable of
carrying out task(s) independently. These modules may work as basic
constructs for the entire software. Designers tend to design modules
such that they can be executed and/or compiled separately and
independently.

Modular design unintentionally follows the rules of ‘divide and conquer’

problem-solving strategy this is because there are many other benefits
attached with the modular design of a software.

 Advantages of modularization:

1. Smaller components are easier to maintain

2. Program can be divided based on functional aspects

3. Desired level of abstraction can be brought in the

program Components with high cohesion can be
re-used again

4. Concurrent execution can be made

possible Desired from security aspect
 Concurrency

Back in time, all software are meant to be executed sequentially. By

sequential execution we mean that the coded instruction will be
executed one after another implying only one portion of program being
activated at any given time. Say, a software has multiple modules, then
only one of all the modules can be found active at any time of execution.

In software design, concurrency is implemented by splitting the software

into multiple independent units of execution, like modules and
executing them in parallel. In other words, concurrency provides
capability to the software to execute more than one part of code in
parallel to each other.

 Example

The spell check feature in word processor is a module of software, which

runs along side the word processor itself.

 Coupling and Cohesion

When a software program is modularized, its tasks are divided into

several modules based on some characteristics. As we know, modules
are set of instructions put together in order to achieve some tasks. They
are though, considered as single entity but may refer to each other to
work together. There are measures by which the quality of a design of
modules and their interaction among them can be measured. These
measures are called coupling and cohesion.
 Cohesion

Cohesion is a measure that defines the degree of intra-dependability

within elements of a module. The greater the cohesion, the better is the
program design. There are seven types of cohesion, namely –

1. Co-incidental cohesion - It is unplanned and random cohesion,

which might be the result of breaking the program into smaller
modules for the sake of modularization. Because it is unplanned, it
may serve confusion to the programmers and is generally not-
accepted.

2. Logical cohesion - When logically categorized elements are put

together into a module, it is called logical cohesion.

3. Temporal Cohesion - When elements of module are organized

such that they are processed at a similar point in time, it is called
temporal cohesion.

4. Procedural cohesion - When elements of module are grouped

together, which are executed sequentially in order to perform a task,
it is called procedural cohesion.

 Design Process
Software design process can be perceived as series of well-defined steps.
Though it varies according to design approach (function oriented or
object oriented, yet it may have the following steps involved:

A solution design is created from requirement or previously used system

and/or system sequence diagram.

Objects are identified and grouped into classes on behalf of similarity in

attribute characteristics.

Class hierarchy and relation among them is defined. Application

framework is defined.

 Software Design Approaches

Here are two generic approaches for software designing:

 Top-Down Design

We know that a system is composed of more than one sub-system and it

contains a number of components. Further, these sub-systems and
components may have their onset of sub-system and components and
creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then
decomposes it to achieve more than one sub-system or component
based on some characteristics. Each sub-system or component is then
treated as a system and decomposed further. This process keeps on
running until the lowest level of system in the top-down hierarchy is
achieved.

Top-down design starts with a generalized model of system and keeps

on defining the more specific part of it. When all components are
composed the whole system comes into existence.

Top-down design is more suitable when the software solution needs to

be designed from scratch and specific details are unknown.

 Bottom-up Design

The bottom-up design model starts with most specific and basic
components. It proceeds with composing higher level of components by
using basic or lower-level components. It keeps creating higher level
components until the desired system is not evolved as one single
component. With each higher level, the amount of abstraction is
increased.

Bottom-up strategy is more suitable when a system needs to be created

from some existing system, where the basic primitives can be used in the
newer system.
Both, top-down and bottom-up approaches are not practical individually.
Instead, a good combination of both is used.

User interface is the front-end application view to which user interacts

in order to use the software. User can manipulate and control the
software as well as hardware by means of user interface. Today, user
interface is found at almost every place where digital technology exists,
right from computers, mobile phones, cars, music players, airplanes,
ships etc.

User interface is part of software and is designed such a way that it is

expected to provide the user insight of the software. UI provides
fundamental platform for human-computer interaction.

UI can be graphical, text-based, audio-video based, depending upon the

underlying hardware and software combination. UI can be hardware or
software or a combination of both.

 Structured Programming

In the process of coding, the lines of code keep multiplying, thus, size of
the software increases. Gradually, it becomes next to impossible to
remember the flow of program. If one forgets how software and its
underlying programs, files, procedures are constructed it then becomes
very difficult to share, debug and modify the program. The solution to
this is structured programming. It encourages the developer to use
subroutines and loops instead of using simple jumps in the code,
thereby bringing clarity in the code and improving its efficiency
Structured programming also helps programmer to reduce coding time
and organize code properly.

Structured programming states how the program shall be coded.

Structured programming uses three main concepts:

Top-down analysis - A software is always made to perform some

rational work. This rational work is known as problem in the software
parlance. Thus, it is very important that we understand how to solve the
problem. Under top-down analysis, the problem is broken down into
small pieces where each one has some significance. Each problem is
individually solved and steps are clearly stated about how to solve the
problem.

Modular Programming - While programming, the code is broken

down into smaller group of instructions. These groups are known as
modules, subprograms or subroutines. Modular programming based on
the understanding of top-down analysis. It discourages jumps using
‘goto’ statements in the program, which often makes the program flow
non-traceable. Jumps are prohibited and modular format is encouraged
in structured programming.
Structured Coding - In reference with top-down analysis, structured
coding sub-divides the modules into further smaller units of code in the
order of their execution. Structured programming uses control structure,
which controls the flow of the program, whereas structured coding uses
control structure to organize its instructions in definable patterns.

 Functional Programming

Functional programming is style of programming language, which uses

the concepts of mathematical functions. A function in mathematics
should always produce the same result on receiving the same argument.
In procedural languages, the flow of the program runs through
procedures, i.e. the control of program is transferred to the called
procedure. While control flow is transferring from one procedure to
another, the program changes its state.
In procedural programming, it is possible for a procedure to produce
different results when it is called with the same argument, as the
program itself can be in different state while calling it. This is a property
as well as a drawback of procedural programming, in which the
sequence or timing of the procedure execution becomes important.

Functional programming provides means of computation as

mathematical functions, which produces results irrespective of program
state. This makes it possible to predict the behaviour of the program.

Functional programming uses the following concepts:

First class and High-order functions - These functions have

capability to accept another function as argument or they return other
functions as results.

Pure functions - These functions do not include destructive updates,

that is, they do not affect any I/O or memory and if they are not in use,
they can easily be removed without hampering the rest of the program.

Recursion - Recursion is a programming technique where a function

calls itself and repeats the program code in it unless some pre-defined
condition matches. Recursion is the way of creating loops in functional
programming.
Strict evaluation - It is a method of evaluating the expression passed
to a function as an argument. Functional programming has two types of
evaluation methods, strict (eager) or non-strict (lazy). Strict evaluation
always evaluates the expression before invoking the function. Non-strict
evaluation does not evaluate the expression unless it is needed.

λ-calculus - Most functional programming languages use λ-calculus as

their

type systems. λ-expressions are executed by evaluating them as they

occur. Common Lisp, Scala, Haskell, Erlang and F# are some examples
of functional programming languages.

 Programming style

Programming style is set of coding rules followed by all the

programmers to write the code. When multiple programmers work on
the same software project, they frequently need to work with the
program code written by some other developer. This becomes tedious or
at times impossible, if all developers do not follow some standard
programming style to code the program.

An appropriate programming style includes using function and variable

names relevant to the intended task, using well-placed indentation,
commenting code for the convenience of reader and overall presentation
of code. This makes the program code readable and understandable by
all, which in turn makes debugging and error solving easier. Also, proper
coding style helps ease the documentation and updating.

 Coding Guidelines

Practice of coding style varies with organizations, operating systems and

language of coding itself.

The following coding elements may be defined under coding guidelines

of an organization:

Naming conventions - This section defines how to name functions,

variables, constants and global variables.

Indenting - This is the space left at the beginning of line, usually 2-8
whitespace or single tab.

Whitespace - It is generally omitted at the end of line.

Operators - Defines the rules of writing mathematical, assignment and

logical operators. For example, assignment operator ‘=’ should have
space before and after it, as in “x = 2”.
Control Structures - The rules of writing if-then-else, case-switch,
while-until and for control flow statements solely and in nested fashion.

Line length and wrapping - Defines how many characters should be

there in one line, mostly a line is 80 characters long. Wrapping defines
how a line should be wrapped, if is too long.

Functions - This defines how functions should be declared and invoked,

with and without parameters.

Variables - This mentions how variables of different data types are

declared and defined.

Comments - This is one of the important coding components, as the

comments included in the code describe what the code actually does and
all other associated descriptions. This section also helps creating help
documentations for other developers.

 Software Implementation Challenges

There are some challenges faced by the development team while

implementing the software. Some of them are mentioned below:
Code-reuse - Programming interfaces of present-day languages are
very sophisticated and are equipped huge library functions. Still, to
bring the cost down of end product, the organization management
prefers to re-use the code, which was created earlier for some other
software. There are huge issues faced by programmers for compatibility
checks and deciding how much code to re-use.

Version Management - Every time a new software is issued to the

customer, developers have to maintain version and configuration related
documentation. This documentation needs to be highly accurate and
available on time.

Target-Host - The software program, which is being developed in

the organization, needs to be designed for host machines at the
customers end. But at times, it is impossible to design a software that
works on the target machines.

 Software Documentation

Software documentation is an important part of software process. A well

written document provides a great tool and means of information
repository necessary to know about software process. Software
documentation also provides information about how to use the product.

A well-maintained documentation should involve the following

documents:
Requirement documentation - This documentation works as key
tool for software designer, developer and the test team to carry out their
respective tasks. This document contains all the functional, non-
functional and behavioural description of the intended software.

Source of this document can be previously stored data about the

software, already running software at the client’s end, client’s interview,
questionnaires and research. Generally, it is stored in the form of
spreadsheet or word processing document with the high-end software
management team.

This documentation works as foundation for the software to be

developed and is majorly used in verification and validation phases.
Most test-cases are built directly from requirement documentation.

Software Design documentation - These documentations

contain all the necessary information, which are needed to build
the software. It contains: (a) High-level software architecture, (b)
Software design details, (c) Data flow diagrams, (d) Database design

These documents work as repository for developers to implement the

software. Though these documents do not give any details on how to
code the program, they give all necessary information that is required
for coding and implementation.
Technical documentation - These documentations are maintained
by the developers and actual coders. These documents, as a whole,
represent information about the code. While writing the code, the
programmers also mention objective of the code, who wrote it, where
will it be required, what it does and how it does, what other resources
the code uses, etc.

Software Testing is evaluation of the software against requirements

gathered from users and system specifications. Testing is conducted at
the phase level in software development life cycle or at module level in
program code. Software testing comprises of Validation and Verification.

 Software Validation

Validation is process of examining whether or not the software satisfies

the user requirements. It is carried out at the end of the SDLC. If the
software matches requirements for which it was made, it is validated.

Validation ensures the product under development is as per the user

requirements.

Validation answers the question – "Are we developing the product which

attempts all that user needs from this software?".

Validation emphasizes on user requirements.

 Software Verification

Verification is the process of confirming if the software is meeting the

business requirements, and is developed adhering to the proper
specifications and methodologies.

Verification ensures the product being developed is according to design

specifications.

Verification answers the question– "Are we developing this product by

firmly following all design specifications?"

Verifications concentrates on the design and system specifications.

Errors - These are actual coding mistakes made by developers. In

addition, there is a difference in output of software and desired output,
is considered as an error.

Fault - When error exists fault occurs. A fault, also known as a bug, is a
result of an error which can cause system to fail.
Failure - failure is said to be the inability of the system to perform the
desired task. Failure occurs when fault exists in the system.

 Manual Vs Automated Testing

Testing can either be done manually or using an automated testing tool:

Manual - This testing is performed without taking help of automated

testing tools. The software tester prepares test cases for different
sections and levels of the code, executes the tests and reports the result
to the manager.

Manual testing is time and resource consuming. The tester needs to

confirm whether or not right test cases are used. Major portion of testing
involves manual testing.

 Black-box testing

It is carried out to test functionality of the program. It is also called

‘Behavioural’ testing. The tester in this case, has a set of input values and
respective desired results. On providing input, if the output matches
with the desired results, the program is tested ‘ok’, and problematic
otherwise.
In this testing method, the design and structure of the code are not
known to the tester, and testing engineers and end users conduct this
test on the software.
 Black-box testing techniques:

1. Equivalence class - The input is divided into similar classes. If one

element of a class passes the test, it is assumed that all the class is
passed.

2. Boundary values - The input is divided into higher and lower end
values. If these values pass the test, it is assumed that all values in
between may pass too.

3. Cause-effect graphing - In both previous methods, only one input

value at a time is tested. Cause (input) – Effect (output) is a testing
technique where combinations of input values are tested in a systematic
way.

4. Pair-wise Testing - The behaviour of software depends on multiple

parameters. In pairwise testing, the multiple parameters are tested
pair-wise for their different values.

5. State-based testing - The system changes state on provision of input.

These systems are tested based on their states and input.

 White-box testing
It is conducted to test program and its implementation, in order to improve
code efficiency or structure. It is also known as ‘Structural’ testing.

In this testing method, the design and structure of the code are known to
the tester.

Programmers of the code conduct this test on the code.

The below are some White-box testing techniques:

Control-flow testing - The purpose of the control-flow testing to set up

test cases which covers all statements and branch conditions. The branch
conditions are tested for both being true and false, so that all statements
can be covered.
Data-flow testing - This testing technique emphasis to cover all the data
variables included in the program. It tests where the variables were
declared and defined and where they were used or changed.

 Testing Levels

Testing itself may be defined at various levels of SDLC. The testing process
runs parallel to software development. Before jumping on the next stage, a
stage is tested, validated and verified.

Testing separately is done just to make sure that there are no hidden bugs
or issues left in the software. Software is tested on various levels -

 Unit Testing

While coding, the programmer performs some tests on that unit of

program to know if it is error free. Testing is performed under white-box
testing approach. Unit testing helps developers decide that individual units
of the program are working as per requirement and are error free.

 Integration Testing
Even if the units of software are working fine individually, there is a need
to find out if the units if integrated together would also work without errors.
For example, argument passing and data updating, etc.

 System Testing

The software is compiled as product and then it is tested as a whole. This

can be accomplished using one or more of the following tests:

Functionality testing - Tests all functionalities of the software against

the requirement.

Performance testing - This test proves how efficient the software is. It
tests the effectiveness and average time taken by the software to do desired
task. Performance testing is done by means of load testing and stress
testing where the software is put under high user and data load under
various environment conditions.

Security & Portability - These tests are done when the software is meant
to work on various platforms and accessed by number of persons.

 Acceptance Testing
When the software is ready to hand over to the customer it has to go
through last phase of testing where it is tested for user-interaction and
response. This is important because even if the software matches all user
requirements and if user does not like the way it appears or works, it may
be rejected.

Alpha testing - The team of developer themselves perform alpha testing

by using the system as if it is being used in work environment. They try to
find out how user would react to some action in software and how the
system should respond to inputs.

Beta testing - After the software is tested internally, it is handed over to

the users to use it under their production environment only for testing
purpose. This is not as yet the delivered product. Developers expect that
users at this stage will bring minute problems, which were skipped to
attend.

 Regression Testing

Whenever a software product is updated with new code, feature or

functionality, it is tested thoroughly to detect if there is any negative impact
of the added code. This is known as regression testing.

 Testing Documentation
Testing documents are prepared at different stages - Before Testing

Testing starts with test cases generation. Following documents are needed
for reference –

SRS document - Functional Requirements document

Test Policy document - This describes how far testing should take place
before releasing the product.

Test Strategy document - This mentions detail aspects of test team,

responsibility matrix and rights/responsibility of test manager and test
engineer.

Traceability Matrix document - This is SDLC document, which is

related to requirement gathering process. As new requirements come, they
are added to this matrix. These matrices help testers know the source of
requirement. They can be traced forward and backward.

While Being Tested

The following documents may be required while testing is started and is
being done:

Test Case document - This document contains list of tests required to be

conducted. It includes Unit test plan, Integration test plan, System test
plan and Acceptance test plan.

Test description - This document is a detailed description of all test

cases and procedures to execute them.

Test case report - This document contains test case report as a result of
the test. Test logs - This document contains test logs for every test case
report.

Test summary - This test summary is collective analysis of all test reports
and logs. It summarizes and concludes if the software is ready to be
launched. The software is released under version control system if it is
ready to launch.

 Testing vs. Quality Control, Quality Assurance and Audit

We need to understand that software testing is different from software

quality assurance, software quality control and software auditing.
Software quality assurance - These are software development process
monitoring means, by which it is assured that all the measures are taken as
per the standards of organization. This monitoring is done to make sure
that proper software development methods were followed.

Software quality control - This is a system to maintain the quality of

software product. It may include functional and non-functional aspects of
software product, which enhance the goodwill of the organization. This
system makes sure that the customer is receiving quality product for their
requirement and the product certified as ‘fit for use’.

Software audit - This is a review of procedure used by the organization

to develop the software. A team of auditors, independent of development
team examines the software process, procedure, requirements and other
aspects of SDLC. The purpose of software audit is to check that software
and its development process, both conform standards, rules and
regulations.