Unit-1

ALGORITHM:
An Algorithm is a finite sequence of instructions, each of which has a clear meaning and can be performed with a
finite amount of effort in a finite length of time. No matter what the input values may be, an algorithm
terminates after executing a finite number of instructions. In addition, every algorithm must satisfy the following
criteria:

Input: there are zero or more quantities, which are externally supplied; Output: at least one quantity is
produced;

Definiteness: each instruction must be clear and unambiguous;

Finiteness: if we trace out the instructions of an algorithm, then for all cases the algorithm will terminate after a
finite number of steps;

Effectiveness: every instruction must be sufficiently basic that it can in principle be carried out by a person using
only pencil and paper. It is not enough that each operation be definite, but it must also be feasible.

In formal computer science, one distinguishes between an algorithm, and a program. A program does not
necessarily satisfy the fourth condition. One important example of such a program for a computer is its operating
system, which never terminates (except for system crashes) but continues in a wait loop until more jobs are
entered.

We represent algorithm using a pseudo language that is a combination of the constructs of a programming
language together with informal English statements.

DESIGNING ALGORITHMS:
In Computer Science, developing an algorithm is an art or a skill. Before actual implementation of the program,
designing an algorithm is very important step.

Steps are:
1. Understand the problem
2. Decision making on
a. Capabilities of computational devices
b. Select exact or approximate methods
c. Data Structures
d. Algorithmic strategies
3. Specification of algorithms
4. Algorithmic verification
5. Analysis of algorithm
6. Implementation or coding of algorithm

ANALYZING ALGORITHMS:
The efficiency of an algorithm can be decided by measuring the performance of an algorithm.

Performance of a program:

Page no: 1
 The performance of a program is the amount of computer memory and time needed to run a program. We use
two approaches to determine the performance of a program. One is analytical, and the other experimental. In
performance analysis we use analytical methods, while in performance measurement we conduct experiments.

Time Complexity:
The time needed by an algorithm expressed as a function of the size of a problem is called the time complexity of
the algorithm. The time complexity of a program is the amount of computer time it needs to run to completion.

The limiting behavior of the complexity as size increases is called the asymptotic time complexity. It is the
asymptotic complexity of an algorithm, which ultimately determines the size of problems that can be solved by
the algorithm.

Space Complexity:
The space complexity of a program is the amount of memory it needs to run to completion. The space need by a
program has the following components:

Instruction space: Instruction space is the space needed to store the compiled version of the program
instructions.

Data space: Data space is the space needed to store all constant and variable values. Data space has two
components:

Space needed by constants and simple variables in program.

Space needed by dynamically allocated objects such as arrays and class instances.

Environment stack space: The environment stack is used to save information needed to resume execution of
partially completed functions.

Instruction Space: The amount of instructions space that is needed depends on factors such as:

The compiler used to complete the program into machine code. The
compiler options in effect at the time of compilation The target
computer.

Algorithm Design Goals

The three basic design goals that one should strive for in a program are:
1. Try to save Time
2. Try to save Space
3. Try to save Face

A program that runs faster is a better program, so saving time is an obvious goal. Likewise, a program that saves
space over a competing program is conside ed desi a le. We a t to sa e fa e preventing the program from locking
up or generating reams of garbled data.

Basic techniques of designing efficient algorithm

1. Divide-and-Conquer
2. Greedy method
3. Dynamic Programming
4. Backtracking
5. Branch-and-Bound

Page no: 2
 In this section we will briefly describe these techniques with appropriate examples.
1. Divide & conquer technique is a top-down approach to solve a problem.
The algorithm which follows divide and conquer technique involves 3 steps:
• Divide the original problem into a set of sub problems.
• Conquer (or Solve) every sub-problem individually, recursive.
• Combine the solutions of these sub problems to get the solution of original problem.

2. Greedy technique is used to solve an optimization problem. An Optimization problem is one in which,
we are given a set of input values, which are required to be either maximized or minimized (known as
objective function) w. r. t. some constraints or conditions. Greedy algorithm always makes the choice
(greedy criteria) that looks best at the moment, to optimize a given objective function. That is, it
makes a locally optimal choice in the hope that this choice will lead to an overall globally optimal
solution. The greedy algorithm does not always guarantee the optimal solution but it generally
produces solutions that are very close in value to the optimal.

3. Dynamic programming technique is similar to divide and conquer approach. Both solve a problem by
breaking it down into a several sub problems that can be solved recursively. The difference between
the two is that in dynamic programming approach, the results obtained from solving smaller sub
problems are reused (by maintaining a table of results) in the calculation of larger sub problems.
Thus, dynamic programming is a Bottom-up approach that begins by solving the smaller sub-
problems, saving these partial results, and then reusing them to solve larger sub-problems until the
solution to the original problem is obtained. Reusing the results of sub-problems (by maintaining a
table of results) is the major advantage of dynamic programming because it avoids the re-
computations (computing results twice or more) of the same problem.
Thus, Dynamic programming approach takes much less time than naïve or straightforward methods,
such as divide-and-conquer approach which solves problems in top-down method and having lots of
re-computations. The dynamic programming approach always gives a guarantee to get an optimal
solution.

4. The term backtrack was coined by American mathematician D.H. Lehmer in the 1950s. Ba kt a ki g a e
applied o l fo p o le s hi h ad it the o ept of a pa tial a didate solutio a d elati el ui k test of hethe it a
possi l e o pleted to a valid solution. Backtrack algorithms try each possibility until they find the right
one. It is a depth-first-search of the set of possible solutions. During the search, if an alternative
doesn t work, the search backtracks to the choice point, the place which presented different
alternatives, and tries the next alternative. When the alternatives are exhausted, the search returns
to the previous choice point and try the next alternative there. If there are no more choice points, the
search fails.

5. Branch-and-Bound (B&B) is a rather general optimization technique that applies where the greedy
method and dynamic programming fail.
B&B design strategy is very similar to backtracking in that a state-space- tree is used to solve a
problem. Branch and bound is a systematic method for solving optimization problems. However, it is
much slower. Indeed, it often leads to exponential time complexities in the worst case. On the other
hand, if applied carefully, it can lead to algorithms that run reasonably fast on average. The general
idea of B&B is a BFS-like search for the optimal solution, but not all nodes get expanded (i.e., their
children generated). Rather, a carefully selected criterion determines which node to expand and
when, and another criterion tells the algorithm when an optimal solution has been found. Branch and

Page no: 3
 Bound (B&B) is the most widely used tool for solving large scale NP-hard combinatorial optimization
problems.

The following table-1.1 summarizes these techniques with some common problems that follow these techniques
ith thei u i g ti e. Ea h te h i ue has diffe e t u i g ti e …ti e o ple it .

Design strategy Problems that follows

Divide & Conquer Binary search
•
Multiplication of two n-bits numbers
•
Quick Sort
•
Heap Sort
•
Merge Sort
•
Greedy Method • Knapsack (fractional) Problem
• Minimum cost Spanning tree o
Kruskal‟s algorithm o Prim‟s
algorithm
• Single source shortest path problem
o Dijkstra‟s algorithm
Dynamic • All pair shortest path-Floyed algorithm
Programming • Chain matrix multiplication
• Longest common subsequence (LCS)
• 0/1 Knapsack Problem
• Traveling salesmen problem (TSP)
Backtracking • N-queen‟s problem
• Sum-of subset
Branch & Bound • Assignment problem
• Traveling salesmen problem (TSP)
Table 1.1: Various Design Strategies Classification of Algorithms
If is the number of data items to be processed or degree of polynomial or the size of the file to be sorted or
searched or the number of nodes in a graph etc.

Next instructions of most programs are executed once or at most only a few times. If all the instructions of a
program have this property, we say that its running time is a constant.

Log n When the running time of a program is logarithmic, the program gets slightly slower as n grows. This
running time commonly occurs in programs that solve a big problem by transforming it into a smaller problem,
cutting the size by some constant fraction. When n is a million, log n is a doubled. Whenever n doubles, log n
increases by a constant, but log n does not double until n increases to n2.

n When the running time of a program is linear, it is generally the case that a small amount of processing is done
on each input element. This is the optimal situation for an algorithm that must process n inputs.

nlog n This running time arises for algorithms that solve a problem by breaking it up into smaller sub-problems,
solving then independently, and then combining the solutions. When n doubles, the running time more than
doubles. n2 When the running time of an algorithm is quadratic, it is practical for use only on relatively small
problems. Quadratic running times typically arise in algorithms that process all pairs of data items (perhaps in a

Page no: 4
 double nested loop) whenever n doubles, the running time increases four-fold. n3 Similarly, an algorithm that
process triples of data items (perhaps in a triple–nested loop) has a cubic running time and is practical for use
only on small problems. Whenever n doubles, the running time increases eight-fold.

2n Few algorithms with exponential running time are likely to be appropriate for practical use, such algorithms
arise naturally as ute–fo e solutio s to p o le s. Whe e e dou les, the u i g time squares.

Complexity of Algorithms
The complexity of an algorithm M is the function f(n) which gives the running time and/or storage spa e e ui e e t
of the algo ith i te s of the size of the i put data. Mostl , the sto age spa e e ui ed a algo ith is si pl a ultiple of the
data size . Co ple it shall efe to the running time of the algorithm.
The function f , gi es the u i g ti e of a algo ith , depe ds ot o l o the size of the i put data but also on the particular
data. The complexity function f(n) for certain cases are:
1. Best Case : The minimum possible value of f(n) is called the best case.
2. Average Case : The expected value of f(n).
3. Worst Case : The maximum value of f(n) for any key possible input.

ASYMPTOTIC NOTATIONS (RATE OF GROWTH):

The following notations are commonly use notations in performance analysis and used to characterize the
complexity of an algorithm:
1. Big–OH (O)
2. Big–OMEGA Ω
3. Big–THETA Ө
1. Big–OH O (Upper Bound) f(n) = O(g(n)), (pronounced order of or big oh), says that the growth rate of f(n) is
less than or equal (<) that of g(n) figure 1.1.

C.g(n)

f(n) F(n)

n0

Figure 1.1: Big O Notation

2. Big–OMEGA Ω (Lower Bound) f(n) = Ω (g(n)) (pronounced omega), says that the growth rate of f(n) is greater
than or equal to (>) that of g(n) figure 1.2.

Page no: 5
 F(n)

f(n) C.g(n)

n0

Figure 1. : Big Ω Notatio

3. Big–THETA Ө (Same order) f(n) = (g(n)) (pronounced theta), says that the growth rate of f(n) equals (=) the
growth rate of g(n) [if f(n) = O(g(n)) and T(n) = Ө (g(n)] figure 1.3.

C2.g(n)

F(n)
C1.g(n)

f(n)

n 0

Figure 1. : Big Ω Notatio

Analyzing Algorithms
“uppose M is a algo ith , a d suppose is the size of the i put data. Clea l the o ple ity f(n) of M increases as n
increases. It is usually the rate of increase of f(n) we want to examine. This is usually done by comparing f(n) with
some standard functions. The most common computing times are:

Page no: 6
 O(1), O(log n), O(n), O(nlogn), O(n2), O(n3), O(2n), n! and nn

Numerical Comparison of Different Algorithms

The execution time for six of the typical functions is given below:

n logn n*logn n2 n3 2n
1 0 0 1 1 2
2 1 2 4 8 4
4 2 8 16 64 16
8 3 24 64 512 256
16 4 64 256 4096 65,536
32 5 160 1024 32,768 4,294,967,296
64 6 384 4096 2,62,144 Note 1
128 7 896 16,384 2,097,152 Note 2
256 8 2048 65,536 1,677,216 ????????

Table 1.2: Comparison among various complexities

HEAP AND HEAP SORT:

A heap is a data structure that stores a collection of objects (with keys), and has the following properties:
 Complete Binary tree
 Heap Order
It is implemented as an array where each node in the tree corresponds to an element of the array.

Binary Heap:
• A complete binary tree is a binary tree in which every level, except possibly the last, is
completely filled, and all nodes are as far left as possible.
• A Binary Heap is a Complete Binary Tree where items are stored in a special order such that
value in a parent node is greater (or smaller) than the values in its two children nodes. The
former is called as max heap and the latter is called min heap. The heap can be represented
by binary tree or array.

Page no: 7
 Figure 1.4: Heap

 The root of the tree A[1] and given index i of a node, the indices of its parent, left child and right
child can be computed PARENT (i)

return floor(i/2)
LEFT (i) return 2i
RIGHT (i)

return 2i + 1

Types of Heaps
Heap can be of 2 types:

Max Heap
 Store data in ascending order
 Has property of
A[Parent(i)] A[i]

Min Heap
 Store data in descending order
 Has property of
A[Pa e t i ] A[i]

Page no: 8
 Figure 1.5: Max Heap example

Figure 1.6: Min Heap example

Heap sort is a comparison-based sorting technique based on Binary Heap data structure. It is similar to selection
sort where we first find the maximum element and place the maximum element at the end. We repeat the same
process for remaining element.

Heap Sort Algorithm for sorting in increasing order:

1. Build a max heap from the input data.
2. At this point, the largest item is stored at the root of the heap. Replace it with the last item of the heap
followed by reducing the size of heap by 1. Finally, heapify the root of tree.
3. Repeat above steps while size of heap is greater than 1.

Procedures on Heap
• Heapify
• Build Heap
• Heap Sort

1. Heapify
Heapify picks the largest child key and compare it
to the parent key. If parent key is larger than
heapify quits, otherwise it swaps the parent key
with the largest child key. So that the parent is
now becomes larger than its children.

Heapify(A, i)

l  left(i) r  right(i) if l <=

heapsize[A] and A[l] > A[i] then largest
Figure 1.10: Component
l else largest  i if r <=
Assembly Model
heapsize[A] and A[r] > A[largest]

Page no: 9
 then largest  r
if largest != i

then swap A[i]  A[largest]

Heapify(A, largest)

}
2. Build Heap
We can use the procedure 'Heapify' in a bottom-up fashion to convert an array A[1 . . n] into a heap.
Since the elements in the subarray A[n/2 +1 . . n] are all leaves, the procedure BUILD_HEAP goes through
the remaining nodes of the tree and runs 'Heapify' on each one. The bottom-up order of processing
node guarantees that the subtree rooted at children are heap before 'Heapify' is run at their parent.
Buildheap(A)

heapsize[A] length[A] for i |

length[A]/2 //down to 1

do Heapify(A, i)

}
3. Heap Sort
The heap sort algorithm starts by using procedure BUILD-HEAP to build a heap on the input array A[1 . .
n]. Since the maximum element of the array stored at the root A[1], it can be put into its correct final
position by exchanging it with A[n] (the last element in A). If we now discard node n from the heap than
the remaining elements can be made into heap. Note that the new element at the root may violate the
heap property. All that is needed to restore the heap property.

Heapsort(A)

Buildheap(A) for i 
length[A] //down to 2 do swap
A[1]  A[i] heapsize[A] 
heapsize[A] - 1
Heapify(A, 1)

Complexity
Time complexity of heapify is O(Logn). Time complexity of create and BuildHeap() is O(n) and overall time
complexity of Heap Sort is O(n Logn).

INTRODUCTION TO DIVIDE AND CONQUER TECHNIQUE:

Divide & conquer technique is a top-down approach to solve a problem.

The algorithm which follows divide and conquer technique involves 3 steps:
• Divide the original problem into a set of sub problems.
• Conquer (or Solve) every sub-problem individually, recursive.
• Combine the solutions of these sub problems to get the solution of original problem.

Page no: 10
 BINARY SEARCH:
The Binary search technique is a search technique which is based on Divide & Conquer strategy. The entered
array must be sorted for the searching, then we calculate the location of mid element by using formula mid=
(Beg + End)/2, here Beg and End represent the initial and last position of array. In this technique we compare
the Key element to mid element. So there May be three cases:-
1. If array[mid] = = Key (Element found and Location is Mid)
2. If array[mid] > Key, then set End = mid-1. (continue the process)
3. If array [mid] < Key, then set Beg=Mid+1. (Continue the process)

Binary Search Algorithm

1. [Initialize segment variable] set beg=LB,End=UB and Mid=int(beg+end)/2.
2. Repeat step 3 and 4 while beg<=end and Data[mid] != item.
3. If item< data[mid] then set end=mid-1
Else if Item>data[mid] then set beg=mid+1[end of if structure]
4. Set mid= int(beg+end)/2.[End of step 2 loop]
5. If data[mid]=item then set Loc= Mid. Else set loc=null[end of if structure]
6. Exit.

Time complexity
As we dispose off one part of the search case during every step of binary search, and perform the search
operation on the other half, this results in a worst case time complexity of O(log2 n).

MERGE SORT:
Merge sort is a divide-and-conquer algorithm based on the idea of breaking down a list into several sub-lists until
each sublist consists of a single element and merging those sublists in a manner that results into a sorted list.

• Divide the unsorted list into NN sublists, each containing 11 element.

• Take adjacent pairs of two singleton lists and merge them to form a list of 2 elements. NN will now
convert into N/2N/2 lists of size 2.
• Repeat the process till a single sorted list of obtained.

While comparing two sublists for merging, the first element of both lists is taken into consideration. While
sorting in ascending order, the element that is of a lesser value becomes a new element of the sorted list. This
procedure is repeated until both the smaller sublists are empty and the new combined sublist comprises all the
elements of both the sublists.

Merge sort first divides the array into equal halves and then combines them in a sorted manner.

How Merge Sort Works?

To understand merge sort, we take an unsorted array as the followig −

We know that merge sort first divides the whole array iteratively into equal halves unless the atomic values are
achieved. We see here that an array of 8 items is divided into two arrays of size 4.

Page no: 11
 Figure 1.7: Merge Sort

Algorithm:
MergeSort(A, p, r)
{
if( p < r )
{
q = (p+r)/2; mergeSort(A,
p, q); mergeSort(A, q+1, r);
merge(A, p, q, r);
}
}

Merge (A, p, q, r )

n1 = q – p + 1

n2 = r – q

Page no: 12
 de la e L[ … 1 + ] a d [‘ … 2 + 1] temporary arrays for i =
1 to n1 L[i] = A[p + i - 1] for j = 1 to n2 R[j] =
numbers[q+ j]

L[n1 + ] = ∞
R[n2 + ] = ∞ i
=1 j=1
for k = p to r
If L[i] ‘[j]
A[k] = L[i]

i=i+1
else

A[k] = R[j]
j=j+1

Time Complexity:
Sorting arrays on different machines. Merge Sort is a recursive algorithm and time complexity can be expressed
as following recurrence relation.

T =T / +Ө
The above recurrence can be solved either using Recurrence Tree method or Master method. It falls in case II of
Master Method and solution of the e u e e is Ө Log .

Ti e o ple it of Me ge “o t is Ө Log i all ases o st, average and best) as merge sort always divides the array in two
halves and take linear time to merge two halves.

Auxiliary Space: O(n)

Algorithmic Paradigm: Divide and Conquer

Sorting In Place: No in a typical implementation

Stable: Yes

QUICK SORT:
Like Merge Sort, QuickSort is a Divide and Conquer algorithm. It picks an element as pivot and partitions the
given array around the picked pivot. There are many different versions of quickSort that pick pivot in different
ways.

• Always pick first element as pivot.

• Always pick last element as pivot (implemented below)  Pick a random element as pivot.
• Pick median as pivot.

The key process in quickSort is partition(). Target of partitions is, given an array and an element x of array as
pivot, put x at its correct position in sorted array and put all smaller elements (smaller than x) before x, and put
all greater elements (greater than x) after x. All this should be done in linear time. /* low --> Starting index, high
--> Ending index */

Page no: 13
 Quick Sort Algorithm
quickSort(arr[], low, high)

if (low < high)

/* pi is partitioning index, arr[p] is now

at right place */

pi = partition(arr, low, high);

quickSort(arr, low, pi - 1); // Before pi quickSort(arr,

pi + 1, high); // After pi

/* This function takes last element as pivot, places the

pivot element at its correct position in sorted array,
and places all smaller (smaller than pivot) to left of
pivot and all greater elements to right of pivot */
partition (arr[], low, high)

// pivot (Element to be placed at right position) pivot =

arr[high];

i = (low - 1) // Index of smaller element

for (j = low; j <= high- 1; j++)

// If current element is smaller than or

// equal to pivot

if (arr[j] <= pivot)

i++; // increment index of smaller element

swap arr[i] and arr[j]

swap arr[i + 1] and arr[high])

Page no: 14
 return (i + 1)

Analysis of QuickSort
Time taken by QuickSort in general can be written as following.

T(n) = T(k) + T(n-k- + Ө

The first two terms are for two recursive calls, the last term is for the partition process. k is the number of
elements which are smaller than pivot.

The time taken by QuickSort depends upon the input array and partition strategy. Following are three cases.

Worst Case: The worst case occurs when the partition process always picks greatest or smallest element as pivot.
If we consider above partition strategy where last element is always picked as pivot, the worst case would occur
when the array is already sorted in increasing or decreasing order. Following is recurrence for worst case. T(n) =
T(0) + T(n- + Ө

which is equivalent to

T(n) = T(n- + Ө
2
The solutio of a o e e u e e is Ө ).

Best Case: The best case occurs when the partition process always picks the middle element as pivot. Following
is recurrence for best case.

T =T / +Ө
The solutio of a o e e u e e is Ө Log . It a e sol ed usi g ase of Maste Theo e .

Average Case:
To do average case analysis, we need to consider all possible permutation of array and calculate time taken by
ever pe utatio hi h does t look eas .

We can get an idea of average case by considering the case when partition puts O(n/9) elements in one set and
O(9n/10) elements in other set. Following is recurrence for this case.

T =T /9 + T 9 / +Ө

Solution of above recurrence is also O(nlogn)

Although the worst-case time complexity of QuickSort is O(n2) which is more than many other sorting algorithms
like Merge Sort and Heap Sort, QuickSort is faster in practice, because its inner loop can be efficiently
implemented on most architectures, and in most real-world data. QuickSort can be implemented in different
ways by changing the choice of pivot, so that the worst case rarely occurs for a given type of data. However,
merge sort is generally considered better when data is huge and stored in external storage.

Page no: 15
 “TRA““EN’“ MATRIX MULTIPLICATION:
The “t asse s ethod of at i ultipli atio is a t pi al di ide a d o ue algo ith . We e see so far, some divide and conquer
algorithms like merge sort and the Ka atsu a s fast ultipli atio of large numbers. However, let s get agai o hat s ehi
d the di ide a d o ue app oa h. U like the d a i p og a i g he e e e pa d the solutio s of su -problems in order to get
the final solution, here we are talking more on joining sub-solutions together. These solutions of some
subproblems of the general problem are equal and their merge is somehow well defined. Ge eral Algorith
without “trasse ’s

MMult(A,B, n)

1. If n = 1 Output A × B
2. Else
3. Compute A11,B11, . . . ,A22,B22 % by computing m = n/2
4. X1 MMult(A11,B11, n/2) 5. X2 MMult(A12,B21, n/2) 6. X3 MMult(A11,B12, n/2) 7. X4 MMult(A12,B22,
n/2)
8. X5 MMult(A21,B11, n/2)
9. X6 MMult(A22,B21, n/2)
10. X7 MMult(A21,B12, n/2)
11. X8 MMult(A22,B22, n/2)
12. C11 X1 + X2 13. C12 X3 + X4 14. C21 X5 + X6
15. C22 X7 + X8
16. Output C
17. End If

log (8)
Co ple it of a o e algo ith is: T =Ө 2 = Ө 3)

Strassen Multiplication Algorithm

Strassen(A,B)

1. If n = 1 Output A × B
2. Else
3. Compute A11,B11, . . . ,A22,B22 % by computing m = n/2
. P “t asse A ,B − B
5. P2 Strassen(A11 + A12,B22)
6. P3 Strassen(A21 + A22,B11)
. P “t asse A ,B − B
8. P5 Strassen(A11 + A22,B11 + B22)
9. P “t asse A −A ,B21 + B22)
. P “t asse A − A ,B + B
.C P+P−P+P
12. C12 P1 + P2
13. C21 P3 + P4
.C P+P−P−P
15. Output C
16. End If

log (7)
Co ple it = T =Ө 2 = Ө 2.8)

Page no: 16
 CS403 Software Engineering UNIT-I

SOFTWARE PRODUCT AND PROCESS CHARACTERISTICS:

Software: -
Software is nothing but collection of computer programs and related documents that are planned to provide desired
features, functionalities and better performance.

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 on the other hand, is all about
developing products, using well-defined, scientific principles and methods.
Characteristics of software: -
1. Software is developed or engineered; it is not manufactured in the classical sense:
• Although some similarities exist between software development and hardware manufacturing, but few activities
are fundamentally different.
• In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can
introduce quality problems than software.
2. “oft a e does t ea out.
• Hardware components suffer from the growing effects of dust, vibration, abuse, temperature extremes, and
many other environmental maladies. Stated simply, the hardware begins to wear out.
• Software is not susceptible to the maladies environmental that cause hardware to wear out. In theory, therefore,
the failure rate cu e fo soft a e should take the fo of the idealized u e .
• When a hardware component wears out, it is replaced by a spare part.
• There are no software spare parts.
• Every software failure indicates an error in design or in the process through which design was translated into
machine executable code. Therefore, the software maintenance tasks that accommodate requests for change
involve considerably more complexity than hardware maintenance.
• However, the implication is clear—soft a e does t ea out. But it does deteriorate.

Figure 1.1 Hardware Failure Curve Figure 1.2 Software Failure Cure

3. Although the industry is moving toward component-based construction, most software continues to be custom
built.
• A software component should be designed and implemented so that it can be reused in many different
programs.

Page no: 1
 • Modern reusable components encapsulate both data and the processing that is applied to the data, enabling the
software engineer to create new application form reuable parts.
• In the hardware world, component reuse is a natural part of the engineering process

Good Software are-

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:

• Portability
• Interoperability
• Reusability
• Adaptability Maintenance: -
This aspect briefs about how well 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 Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation
and maintenance of software; that is, the application of engineering to software.
Software product classified in 2 classes:

2. Generic software: Developed to solution whose requirements are very common fairly stable and well understood by
software engineer.
3. Custom software: Developed for a single customer according to their specification.
A Layered Technology:

Page no: 2
 Figure 1.3 Layed Architecture A
quality Focus:
• Every organization is rest on its commitment to quality.
• Total quality management, Six Sigma, or similar continuous improvement culture and it is this culture ultimately
leads to development of increasingly more effective approaches to software engineering.
• The foundation that supports software engineering is a quality focus.
Process:
• The software engineering process is the glue that holds the technology layers together and enables rational and
timely development of computer software.
• Process defines a framework that must be established for effective delivery of software engineering technology.
• The software process forms the basis for management control of software projects and establishes the context in
which technical methods are applied, work products are produced, milestones are established, quality is
ensured, and change is properly managed.
Methods:
• Software engineering methods provide the technical aspects for building software.
• Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling,
program construction, testing, and support.
• Software engineering methods rely on the set of modeling activities and other descriptive techniques.
Tools:
• Software engineering tools provide automated or semi automated support for the process and the method.
• When tools are integrated so that information created by one tool can be used by another, a system for the
support of software development, called CASE (Computer- aided softeware engineering), is established.
SOFTWARE PROCESS MODEL:
Software process can be defining as the structured set of activates that are required to develop the software system.
To solve actual problems in an industry setting, a software engineer or a team of engineers must incorporate a
development strategy that encompasses the process, methods, and tools layers. This strategy is often referred to as a
process model or a software engineering paradigm.
A process model for software engineering is chosen based on the nature of the project and application, the methods and
tools to be used, and the controls and deliverables that are required.
Goal of Software Process Models: -
The goal of a software process model is to provide guidance for systematically coordinating and controlling the tasks that
must be performed in order to achieve the end product and their project objectives. A process model defines the
following:
• A set of tasks that need to be performed.
• The inputs to and output from each task.
• The preconditions and post-conditions for each task.

Page no: 3
 • The sequence and flow of these tasks. Characteristics of Software Process: -
Software is often the single largest cost item in a computer-based application. Though software is a product, it is different
from other physical products.
i. Software costs are concentrated in engineering (analysis and design) and not in
production.
ii. Cost of software is not dependent on volume of production. iii. Software does not wear
out (in the physical sense). iv. Software has no replacement (spare) parts.
v. Software maintenance is a difficult problem and is very different from hardware (physical product) maintenance.
vi. Most software is custom-built.
vii. Many legal issues are involved (e.g. inter-actual property rights, liability). Software Product: -
A software product, user interface must be carefully designed and implemented because developers of that product and
users of that product are totally different. In case of a program, very little documentation is expected, but a software
product must be well documented. A program can be developed according to the p og a e s i di idual st le of de elop e t,
ut a soft a e p odu t ust e de eloped usi g the a epted software engineering principles.
Various Operational Characteristics of software are:
• Correctness: The software which we are making should meet all the specifications stated by the customer. 
Usability/Learn-ability: The amount of efforts or time required to learn how to use the software should be less. This
makes the software user-friendly even for IT-illiterate people.
• Integrity: Just like medicines have side-effects, in the same way software may have aside-effect i.e. it may affect the
working of another application. But quality software should not have side effects.
• Reliability: The software product should not have any defects. Not only this, it shouldn't fail while execution.
• Efficiency: This characteristic relates to the way software uses the available resources. The software should make
effective use of the storage space and execute command as per desired timing requirements.
• Security: With the increase in security threats nowadays, this factor is gaining importance. The software shouldn't
have ill effects on data / hardware. Proper measures should be taken to keep data secure from external threats.
• Safety: The software should not be hazardous to the environment/life.
Difference between software process and software product: -
Table 1 Difference between software process and software product
Software Process Software Product
Processes are developed by individual user and it It is developed by multiple users and it is used by
is used for personal use. large number of people or customers.
Process may be small in size and possessing It consists of multiple program codes; relate
limited functionality. documents such as SRS, designing documents,
user manuals, test cases.
Process is generally developed by process Process is generally developed by process
engineers. engineers. Therefore systematic approach of
developing software product must be applied.
Software product relies on software process for It is important than software product. Multiuser
its stability quality and control Only one person no lack of user interface.
uses the process, hence lack of user interface
Software Development Life Cycle/Process model/ Software Development Life Cycle: -
Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in software engineering
to develop the intended software product. it is a team of engineers must incorporate a development strategy that
encompasses the process, method and tools layers. Each phase has various activities to develop the software product. It
also specifies the order in which each phase must be executed. A software life cycle model is either a descriptive or

Page no: 4
 prescriptive characterization of how software is or should be developed. A descriptive model describes the history of
how a particular software system was developed. Definition: Software Development Life Cycle (SDLC) is a process used
by software industry to design, develop and test high quality software. The SDLC aims to produce high-quality software
that meets or exceeds customer expectations, reaches completion within times and cost estimates.
SDLC is the acronym of Software Development Life Cycle. It is also called as Software development process. The software
development life cycle (SDLC) is a framework defining tasks performed at each step in the software development
process.
LINEAR SEQUENTIAL MODEL:
A few of software development paradigms or process models are defined as follows:

Waterfall model or linear sequential model or classic life cycle model: -

Sometimes called the classic life cycle or the waterfall model, the linear sequential model suggests a systematic,
sequential approach to software development that begins at the system level and progresses through analysis, design,
coding, testing, and maintenance.

4. Figure 1.4 Waterfall model

Software requirements analysis: The requirements gathering process is focused specifically on software. 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. Requirements for both the system and
the software are documented and reviewed with the customer.
Design: Software design is actually a multi-step process that focuses on four distinct attributes of a program: data
structure, software architecture, interface representations, and procedural (algorithmic) detail. The design process
translates requirements into a representation of the software that can be assessed for quality before coding begins. Like
requirements, the design is documented and becomes part of the software configuration.
Coding : The design must be translated into a machine-readable form. The code generation step performs this task. If
design is performed in a detailed manner, code generation can be accomplished mechanistically. Testing: Once code has
been generated, program testing begins. 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.
Maintenance: Software will undoubtedly undergo change after it is delivered to the customer (a possible exception is
embedded software). Change will occur because errors have been encountered, because the software must be adapted
to accommodate changes in its external environment (e.g., a change required because of a new operating system or
peripheral device), or because the customer requires functional or performance enhancements. Software
support/maintenance reapplies each of the preceding phases to an existing program rather than a new one.
Advantages of waterfall model: -
• This model is simple and easy to understand and use.
• Waterfall model works well for smaller projects where requirements are very well understood.
• Each phase proceeds sequentially.
• Documentation is produced at every stage of the software's development. This makes understanding the product
designing procedure, simpler.

Page no: 5
 • After every major stage of software coding, testing is done to check the correct running of the code.
help us to control schedules and budgets.

Disadvantages of waterfall model: -

• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.
• High amounts of risk and uncertainty.
• Customer can see working model of the project only at the end. after reviewing of the working model if the
customer gets dissatisfied then it causes serious problem.
• You cannot go back a step if the design phase has gone wrong, things can get very complicated in the
implementation phase.
PROTOTYPING MODEL:
A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low
reliability, and inefficient performance compared to the actual software. A prototype is usually built using several
shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut implementation of
a function, for example, may produce the desired results by using a table look-up instead of performing the actual
computations. A prototype usually turns out to be a very crude version of the actual system.

5. Figure 1.5 Prototype Model

Need for a prototype in software development: -

There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports,
and the interactive dialogues to the customer. This is a valuable mechanism for gaining better u de sta di g of the usto e s
eeds:
• How the screens might look like
• How the user interface would behave
• How the system would produce outputs
A prototyping model can be used when technical solutions are unclear to the development team.

Page no: 6
 A developed prototype can help engineers to critically examine the technical issues associated with the product
development. Often, major design decisions depend on issues like the response time of a hardware controller, or the
efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the
technical issues.

A prototype of the actual product is preferred in situations such as:

• User requirements are not complete
• Technical issues are not clear RAPID APPLICATION MODEL:
Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of
rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product. In RAD
model, the functional modules are developed in parallel as prototypes and are integrated to make the complete product
for faster product delivery.
Since there is no detailed pre-planning, it makes it easier to incorporate the changes within the development process.
RAD projects follow iterative and incremental model and have small teams comprising of developers, domain experts,
customer representatives and other IT resources working progressively on their component or prototype. The most
important aspect for this model to be successful is to make sure that the prototypes developed are reusable.
Rapid application development (RAD) is an incremental software development process model that emphasizes a e t e el
sho t de elop e t le. The ‘AD odel is a high-speed adaptatio of the li ea se ue tial model in which rapid development is
achieved by using component-based construction. If requirements are well understood and project scope is constrained,
the RAD process enables a development team to create a full fu tio al s ste ithi e sho t ti e pe iods e.g., to 9 da s . Used p i
a il fo i fo atio systems applications, the RAD approach encompasses the following phases:

Business modeling: The information flow among business functions is modeled in a way that answers the following
questions: What information drives the business process? What information is generated? Who generates it? Where
does the information go? Who processes it?
Data 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. The characteristics (called attributes) of each object are identified and the
relationships between these objects defined.
Process modeling: The data objects defined in the data modeling phase are transformed to achieve the information flow
necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object.
Application generation: RAD assumes the use of fourth generation techniques. Rather than creating software using
conventional third generation programming languages the RAD process works to reuse existing program components
(when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate
construction of the software.
Testing and turnover: Since the RAD process emphasizes reuse, many of the program components have already been
tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully
exercised.

Page no: 7
 Figure 1.6.1:Rapid Application Model

6. Figure 1.6.2:Rapid Application Model Teamwise

Advantages of the RAD model:

Page no: 8
 • Reduced development time.
• Increases re usability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD model:
•Depends on strong team and individual performances for identifying business requirements.  Only system
that can be modularized can be built using RAD  Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
When to use RAD model:
• RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.
• It should e used if the e s high a aila ilit of desig e s fo odeli g a d the udget is high e ough to afford their cost
along with the cost of automated code generating tools.
• RAD SDLC model should be chosen only if resources with high business knowledge are available and there is
a need to produce the system in a short span of time (2-3 months).

EVOLUTIONARY PROCESS MODEL:

Evolutionary Software Process Model Evolutionary software models are iterative. They are characterized in manner that
enables the software engineers to develop increasingly more complete version of software. In programming "iteration"
means sequential access to objects. It is typically a cycle. Software engineers can follow this process model that has been
clearly designed to put up a product that regularly complete over time.
Iterative Model design:
Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances
the evolving versions until the full system is implemented. At each iteration, design modifications are made and new
functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles
(iterative) and in smaller portions at a time (incremental).

Following is the pictorial representation of Iterative and Incremental model:

Figure 1.7 Iterative Model Iterative

Model Application:
Like other SDLC models, Iterative and incremental development has some specific applications in the software industry.
This model is most often used in the following scenarios:
• Requirements of the complete system are clearly defined and understood.
• Major requirements must be defined; however, some functionalities or requested enhancements may evolve
with time.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team while working on the project.

Page no: 9
 • Resources with needed skill set are not available and are planned to be used on contract basis for specific
iterations.
• There are some high-risk features and goals which may change in the future.

Evolutionary Process Model is of 2 types

• Incremental model and
• Spiral model

INCREMENTAL MODEL:
• The incremental model combines the elements of waterfall model and they are applied in an iterative fashion.
• The first increment in this model is generally a core product.
• Each increment builds the product and submits it to the customer for any suggested modifications.
• The next increment implements on the customer's suggestions and add additional requirements in the previous
increment.
• This process is repeated until the product is finished.
For example, the word-processing software is developed using the incremental model.

7. Figure 1.8 Incremental Model

Advantages of Incremental model: -
•Generates working software quickly and early during the software life cycle.
•This model is more flexible – less costly to change scope and requirements.
•It is easier to test and debug during a smaller iteration.
•In this model customer can respond to each built.
•Lowers initial delivery cost.
•Easie to a age isk e ause isk pie es a e ide tified a d ha dled du i g it d ite atio .
•There is low risk for overall project failure.
•Customer does not have to wait until the entire system is delivered.
Disadvantages of Incremental model: -

Page no: 10
 • Needs good planning and design at the management a technical level.
• Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.
• Total cost is higher than waterfall.
• Time foundation create problem to complete the project.
When to use the Incremental model:
• This model can be used when the requirements of the complete system are clearly defined and understood.
• Major requirements must be defined; however, some details can evolve with time.  There is a need to get a
product to the market early.  A new technology is being used
• Resources with needed skill set are not available  There are some high-risk features and goals.
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. It provides the potential for rapid development of
incremental versions of the software. Using the spiral model, software is developed in a series of incremental releases.
During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly
more complete versions of the engineered system are produced.
A spiral model is divided into a number of framework activities, also called task regions. Project entry point axis is
defined this axis represents starting point for different types of project. Every framework activities represent one section
of the spiral path. As the development process starts, the software team performs activities that are indirect by a path
around the spiral model in a clockwise direction. It begins at the center of spiral model. Typically, there are between
three and six task regions. In blow Figure depicts a spiral model that contains six task regions:
• Customer communication—tasks required to establish effective communication between developer and
customer.
• Planning—tasks required to define resources, time lines, and other project related information.
• Risk analysis—tasks required to assess both technical and management risks.
• Engineering—tasks required to build one or more representations of the application.
• Construction and release—tasks required to construct, test, install, and provide user support(e.g.,
documentation and training).
• Customer evaluation—tasks required to obtain customer feedback based on evaluation of the software
representations created during the engineering stage and implemented during the installation stage.
Figure 1.9 Spiral Model

Advantages of Spiral model: -

• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.
Disadvantages of Spiral model: -  Can
be a costly model to use.
• Risk analysis requires highly specific expertise.
• P oje t s su ess is highl dependent on the risk analysis phase.
• Does t ok ell fo s alle p oje ts.
When to use Spiral model:
• When costs and risk evaluation is important.
• For medium to high-risk projects.

Page no: 11
 • Long-term project commitment unwise because of potential changes to economic priorities.  Users are unsure
of their needs.
• Requirements are complex.
• New product line.
• Significant changes are expected (research and exploration).
COMPONENT ASSEMBLY MODEL:
Component Assembly Model is just like the Prototype model, in which first a prototype is created according to the
requirements of the customer and sent to the user for evaluation to get the feedback for the modifications to be made
and the same procedure is repeated until the software will cater the need of businesses and consumers is realized. Thus
it is also an iterative development model.
This model work in following manner:

1. Identify all required candidate component i.e. classes with the help of application data and algorithm.
2. If these candidate components are used in previous software project then thy must be present in library.
3. Such preexisting component can be extracted from the library and used for further development.
4. But if required component is not presented in the library then build or create the component as per
requirement.
5. Place the newly created component in library. This makes one iteration of the syste
6. ‘epeat step to fo eati g ite atio . Whe e de otes the o of ite atio s e ui ed to de elop complete application.

Page no: 12
 7.

Component Assembly Model Characteristics:

• Use of object-oriented technology.
• Components – classes that encapsulate both data and algorithms.
• Components developed to be reusable.
• Paradigm similar to spiral model, but engineering activity involves components.  System produced by
assembling the correct components.
RATIONAL UNIFIED PROCESS (RUP):
Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. RUP is a
software application development technique with many tools to assist in coding the final product and tasks related to
this goal. RUP is an object-oriented approach used to ensure effective project management and high-quality software
production. It divides the development process into four distinct phases that each involves business modeling, analysis
and design, implementation, testing, and deployment. The four phases are:

Page no: 13
 1. Inception - The idea for the project is stated. The development team determines if the project is worth pursuing
and what resources will be needed.
2. Elaboration - The project's architecture and required resources are further evaluated. Developers consider
possible applications of the software and costs associated with the development.
3. Construction - The project is developed and completed. The software is designed, written, and tested.
4. Transition - The software is released to the public. Final adjustments or updates are made based on feedback
from end users.
The RUP development methodology provides a structured way for companies to envision create software programs.
Since it provides a specific plan for each step of the development process, it helps prevent resources from being wasted
and reduces unexpected development costs. Advantages of RUP Software Development: -

• This is a complete methodology in itself with an emphasis on accurate documentation

• It is pro-actively able to resolve the project risks associated with the client's evolving requirements requiring
careful change request management
• Less time is required for integration as the process of integration goes on throughout the software development
life cycle.
•The development time required is less due to reuse of components.
•There is online training and tutorial available for this process.
Disadvantages of RUP Software Development: -
• The team members need to be expert in their field to develop a software under this methodology.
• The development process is too complex and disorganized.
• On cutting edge projects which utilize new technology, the reuse of components will not be possible. Hence the
time saving one could have made will be impossible to fulfill.
• Integration throughout the process of software development, in theory sounds a good thing. But on particularly
big projects with multiple development streams it will only add to the confusion and cause more issues during
the stages of testing.

8. Figure 1.11 Rational Unified Process (RUP)

AGILE DEVELOPMENT MODEL
Agile Process:-The o d agile ea s a le to thi k ui kl a d lea l . I usi ess, agile is used fo des i i g ways of planning and doing
work wherein it is understood that making changes as needed is an important part of the job.
Agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This
results in small incremental releases with each release building on previous functionality. Each release is thoroughly
tested to ensure software quality is maintained. It is used for time critical applications.
Extreme Programming (XP) is currently one of the most well known agile development life cycle model.

Advantages of Agile model:

• Customer satisfaction by rapid, continuous delivery of useful software.

Page no: 14
 • People and interactions are emphasized rather than process and tools. Customers, developers and testers
constantly interact with each other.
• Working software is delivered frequently (weeks rather than months).
• Face-to-face conversation is the best form of communication.
• Close, daily cooperation between business people and developers.
• Continuous attention to technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed Disadvantages of Agile model:
• In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the
beginning of the software development life cycle.
• There is lack of emphasis on necessary designing and documentation.
• The project can easily get taken off track if the customer representative is not clear what final outcome that they
want.
• Only senior programmers are capable of taking the kind of decisions required during the development process.
Hence it has no place for new programmers, unless combined with experienced resources.
Extreme Programming
Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software,
and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding
appropriate engineering practices for software development.
Extreme Programming is based on the following values- 
Communication

• Simplicity
• Feedback
• Courage
• Respect
Extreme Programming takes the effective principles and practices to extreme levels.
• Code reviews are effective as the code is reviewed all the time.
• Testing is effective as there is continuous regression and testing.
• Design is effective as everybody needs to do refactoring daily.
• Integration testing is important as integrate and test several times a day.
• Short iterations are effective as the planning game for release planning and iteration planning.

Page no: 15
 9. Figure 1.12 Extrem Programming

CAPABILITY MATURITY MODEL (CMM):

The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software
engineering capabilities that should be present as organizations reach different levels of process maturity. To dete i e a o
ga izatio s u e t state of p o ess atu it , the
SEI uses an assessment that results in a five-point grading scheme. The grading scheme determines compliance with a
capability maturity model (CMM) that defines key activities required at different levels of process maturity. The SEI
approach provides a measure of the global effectiveness of a company's software engineering practices and establishes
five process maturity levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined,
and success depends on individual effort.
Level 2: Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The
necessary process discipline is in place to repeat earlier successes on projects with similar applications.
Level 3: Defined. The software process for both management and engineering activities is documented, standardized,
and integrated into an organization wide software process. All projects use a documented and approved version of the
organization's process for developing and supporting software. This level includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software
process and products are quantitatively understood and controlled using detailed measures. This level includes all
characteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from
testing innovative ideas and technologies. This level includes all characteristics defined for level 4. The five levels defined
by the SEI were derived as a consequence of evaluating responses to the SEI assessment questionnaire that is based on
the CMM. The results of the questionnaire are distilled to a single numerical grade that provides an indication of an
organization's process maturity.

Page no: 16
 10. Figure 1.13 Capability Maturity Model

Process maturity level 2: -

• Software configuration management
• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3: - 
Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus
Process maturity level 4: -
• Software quality management
• Quantitative process management
Process maturity level 5: -
• Process change management
• Technology change management
• Defect prevention
SOFTWARE PROCESS CUSTOMIZATION:
In software industry, most of the projects are customized software product 3 major factors that are involved in software
process customization and those are:
• PEOPLE
• PRODUCT
• PROCESS
People: -

Page no: 17
 The primary element of any project is the people. People gather requirements, people interview users (people), people
design software, and people write software for people. No people -- no software. I'll leave the discussion of people to the
other articles in this special issue, except for one comment. The best thing that can happen to any software project is to
have people who know what they are doing and have the courage and self-discipline to do it. Knowledgeable people do
what is right and avoid what is wrong. Courageous people tell the truth when others want to hear something else.
Disciplined people work through projects and don't cut corners. Find people who know the product and can work in the
process.
Process: -
Process is how we go from the beginning to the end of a project. All projects use a process. Many project managers,
however, do not choose a process based on the people and product at hand. They simply use the same process they've
always used or misused. Let's focus on two points regarding process: (1) process improvement and (2) using the right
process for the people and product at hand.
Product: -
The product is the result of a project. The desired product satisfies the customers and keeps them coming back for more.
Sometimes, however, the actual product is something less. The product pays the bills and ultimately allows people to
work together in a process and build software. Always keep the product in focus.
PRODUCT AND PROCESS METRICS:
Software process metrics measure the software development process and environment. Example productivity, effort
estimates, efficiency and failure rate.
Software Product metrics measure the software product. Example: -
size, reliability, complexity and functionality.
Process Metrics and Software Process Improvement: -
The only rational way to improve any process is
• To measure specific attributes of the process
• Develop a set of meaningful metrics based on these attributes
• Use the metrics to provide indicators that will lead to a strategy for improvement

11. Figure 1.14 Product and Process Metrics

Processes it s at the e te of a t ia gle o e ti g th ee fa to s that ha e p ofou d i flue e o soft a e quality and organizational
performance
• The skill and motivation of people has most influential factor in quality and performance.
• The complexity of the product has impact on quality and team performance.
• The technology (the software engineering methods) the process triangle exists within a circle of environmental
conditions that include the development environment, business conditions, customer characteristics.

Page no: 18
 12. Unit-2 Notes
Study of Greedy strategy, examples of greedy method like optimal merge patterns, Huffman
coding, minimum spanning trees, knapsack problem, job sequencing with deadlines, single source
shortest path algorithm

Greedy Technique
Greedy is the most straight forward design technique. Most of the problems have n inputs and
require us to obtain a subset that satisfies some constraints. Any subset that satisfies these
constraints is called a feasible solution. We need to find a feasible solution that either maximizes or
minimizes the objective function. A feasible solution that does this is called an optimal solution.

The greedy method is a simple strategy of progressively building up a solution, one element at a
time, by choosing the best possible element at each stage. At each stage, a decision is made
regarding whether or not a particular input is in an optimal solution. This is done by considering the
inputs in an order determined by some selection procedure. If the inclusion of the next input, into
the partially constructed optimal solution will result in an infeasible solution then this input is not
added to the partial solution. The selection procedure itself is based on some optimization
measure. Several optimization measures are plausible for a given problem. Most of them, however,
will result in algorithms that generate sub-optimal solutions. This version of greedy technique is
called subset paradigm. Some problems like Knapsack, Job sequencing with deadlines and
minimum cost spanning trees are based on subset paradigm.

Algorithm Greedy (a, n)

// a : o tai s the i puts
{

solution := ; // initialize the solution to empty for i:=1 to n do

x := select (a);

if feasible (solution, x) then

solution := Union (Solution, x);

return solution;

OPTIMAL MERGE PATTERNS

Gi e so ted files, the e a e a a s to pai ise e ge the i to a si gle sorted file. As, different pairings
require different amounts of computing time, we want to determine an opti al i.e., o e e ui i g the fe
est o pa iso s a to pai ise e ge so ted files together. This type of merging is called as 2-way merge
patterns. To merge an n-record file and an m-record file requires possibly n + m record moves, the
obvious choice choice is, at each step merge the two smallest files together. The two-way merge
patterns can be represented by binary merge trees.
Page no: 1 V
 Algorithm to Generate Two-way Merge Tree:

struct treenode

treenode * lchild;

treenode * rchild;

};

Algorithm TREE (n)

// list is a global of n single node binary trees

for i := 1 to n – 1 do

pt = new treenode

(pt.lchild) = least (list); // merge two trees with smallest lengths

(pt.rchild) = least (list);

(pt.weight) = ((pt.lchild).weight) + ((pt.rchild).weight);

insert (list, pt); tree
}

return least (list);

Analysis:
T= O (n-1) * max (O (Least), O (Insert)).

- Case 1: L is not sorted.

O (Least)= O (n).

O (Insert)= O (1). T=
O (n2).

- Case 2: L is sorted.

Case 2.1

O (Least)= O (1)

O (Insert)= O (n)

T= O (n2)
Case 2.2

Page no: 2 V
 L is represented as a min-heap. Value in the root is <= the values of its children.
O (Least)= O (1)

O (Insert)= O (log n)
T= O (n log n).

Huffman Codes
Huffman coding is a lossless data compression algorithm. The idea is to assign variable-length codes to input
characters, lengths of the assigned codes are based on the frequencies of corresponding characters. The most
frequent character gets the smallest code and the least frequent character gets the largest code.

The variable-length codes assigned to input characters are Prefix Codes, means the codes (bit sequences) are
assigned in such a way that the code assigned to one character is not prefix of code assigned to any other
character. This is how Huffman Coding makes sure that there is no ambiguity when decoding the generated bit
stream.

Let us understand prefix codes with a counter example. Let there be four characters a, b, c and d, and their
corresponding variable length codes be 00, 01, 0 and 1. This coding leads to ambiguity because code assigned
to c is prefix of codes assigned to a and b. If the compressed bit stream is 0001, the de-compressed output a e
d o o a d o a figu e . .

Steps to build Huffman code

Input is array of unique characters along with their frequency of occurrences and output is Huffman Tree.

1. Create a leaf node for each unique character and build a min heap of all leaf nodes (Min Heap is used as a
priority queue. The value of frequency field is used to compare two nodes in min heap. Initially, the least
frequent character is at root)
2. Extract two nodes with the minimum frequency from the min heap.
3. Create a new internal node with frequency equal to the sum of the two nodes frequencies. Make the first
extracted node as its left child and the other extracted node as its right child. Add this node to the min heap.
4. Repeat steps#2 and #3 until the heap contains only one node. The remaining node is the root node and the
tree is complete. Example:

Letter A B C D E F

Frequency 10 20 30 40 50 60

Page no: 3 V
 V 210
0 1

Z 90 W 120

0 1 0 1

D 40 E 50 Y 60 F 60

0 1

X 30 C 30

0 1

A 10 B 20

Figure 2.1: Example of Huffman code

Output => A:1000, B: 10001, C: 101, D: 00, E: 01, F:11

Algorithm:
Huffman(A)

n = |A|;

Q = A;

for i = 1 to n-1

z = new node; left[z]

=Extract-Min(Q); right[z]
=Extract-Min(Q); f[z] =
f[left[z]] +f[right[z]];
Insert(Q, z);
}

return Extract-Min(Q);

Page no: 4 V
 Analysis of algorithm
Each priority queue operation (e.g. heap): O(log n) In
each iteration: one less subtree.

Initially: n subtrees.

Total: O(n log n) time.

Kruskal’s Algorith
This is a greedy algorithm. A greedy algorithm chooses some local optimum (i.e. picking an edge with the least
weight in a MST).

Kruskal's algorithm works as follows: Take a graph with 'n' vertices, keep on adding the shortest (least cost)
edge, while avoiding the creation of cycles, until (n - 1) edges have been added. Sometimes two or more edges
may have the same cost. The order in which the edges are chosen, in this case, does not matter. Different MSTs
may result, but they will all have the same total cost, which will always be the minimum cost.

Algorithm Kruskal (E, cost, n, t)

// E is the set of edges in G. G has n vertices. cost [u, v] is the

// ost of edge u, . t is the set of edges i the i i u -cost spanning tree.

// The final cost is returned.

Construct a heap out of the edge costs using heapify;

for i := 1 to n do parent [i] := -1; i

:= 0; mincost := 0.0;

// Each vertex is in a different set.

while ((i < n -1) and (heap not empty)) do

Delete a minimum cost edge (u, v) from the heap and re-heapify using Adjust;
j := Find (u); k := Find (v); if (j < k) then
{ i := i +
1; t [i, 1]
:= u; t [i,
2] := v;
mincost
:=minco
st + cost
[u, v];
Union
(j, k);
}

if (i >n-1) then write ("no spanning tree"); else

return mincost;

}
Page no: 5 V
 Running time:

• The number of finds is at most 2e, and the number of unions at most n-1. Including the initialization time
for the trees, this part of the algorithm has a complexity that is just slightly more than O (n + e).
• We can add at most n-1 edges to tree T. So, the total time for operations on T is O(n).
Summing up the various components of the computing times, we get O (n + e log e) as asymptotic complexity.

MINIMUM-COST SPANNING TREES: PRIM'S ALGORITHM

A given graph can have many spanning trees. From these many spanning trees, we have to select a cheapest
one. This tree is called as minimal cost spanning tree.

Minimal cost spanning tree is a connected undirected graph G in which each edge is labeled with a number
(edge labels may signify lengths, weights other than costs). Minimal cost spanning tree is a spanning tree for
which the sum of the edge labels is as small as possible

The slight modification of the spanning tree algorithm yields a very simple algorithm for finding an MST. In the
spanning tree algorithm, any vertex not in the tree but connected to it by an edge can be added. To find a
Minimal cost spanning tree, we must be selective - we must always add a new vertex for which the cost of the
new edge is as small as possible.

This simple modified algorithm of spanning tree is called prim's algorithm for finding an Minimal
cost spanning tree.

Prim's algorithm is an example of a greedy algorithm.

Algorithm Prim (E, cost, n, t)

// E is the set of edges in G. cost [1:n, 1:n] is the cost

// adjacency matrix of an n vertex graph such that cost [i, j] is //

either a positive real number or if no edge (i, j) exists.

// A minimum spanning tree is computed and stored as a set of

// edges in the array t [1:n-1, 1:2]. (t [i, 1], t [i, 2]) is an edge in //
the minimum-cost spanning tree. The final cost is returned.

Let (k, l) be an edge of minimum cost in E;

mincost := cost [k, l]; t

[1, 1] := k; t [1, 2] := l;

for i :=1 to n do // Initialize near if (cost [i, l] < cost [i, k]) then near
[i] := l; else near [i] := k; near [k] :=near [l] := 0; for i:=2 to n - 1 do //
Find n - 2 additional edges for t.
{

Let j be an index such that near [j] 0 and

cost [j, near [j]] is minimum; t [i, 1] := j; t
[i, 2] := near [j]; mincost := mincost + cost
[j, near [j]]; near [j] := 0 for k:= 1 to n
do // Update near[].

Page no: 6 V
 if ((near [k] > 0) and (cost [k, near [k]] > cost [k, j])) then
near [k] := j;

return mincost;

Running time:

We do the same set of operations with dist as in Dijkstra's algorithm (initialize structure, m times
decrease value, n - 1 times select minimum). Therefore, we get O (n2) time when we implement dist with
array, O (n + E.log n) when we implement it with a heap.

Co pariso of Kruskal’s a d Pri ’s MCST Algorith :

Kruskal’s Algorithm Prim’s algorithm

 Kruskal s algorithm always selects  Prim s algorithm always selects a
an edge (u, v) of minimum weight vertex (say, v) to find MCST. In
to find MCST.  Prim s algorithm for getting
 In kruskal s algorithm for getting MCST, it is necessary to select an
MCST, it is not necessary to adjacent vertex of already
choose adjacent vertices of selected vertices (in any
successive steps). At
already selected vertices (in any 
 successive steps). At intermediate step of algorithm,
there will be only one connected
intermediate step of algorithm, components
there are may be more than one are possible

 connected components are Time complexity: O (V2)
possible. Time complexity: O (|
E| log |V|)

KNAPSACK PROBLEM
Let us appl the g eed ethod to sol e the k apsa k p o le . We a e gi e o je ts a d a k apsa k. The o je t i has a eight
i a d the k apsa k has a apa it . If a f a tio i, < i < of object i is placed into the knapsack then a profit of pi xi is
earned. The objective is to fill the knapsack that maximizes the total profit earned.
“i e the k apsa k apa it is , e e ui e the total eight of all hose o je ts to e at ost .

Algorithm
If the objects are already been sorted into non-increasing order of p[i] / w[i] then the algorithm given below
obtains solutions corresponding to this strategy.

Greedy Fractional-Knapsack (P[1..n], W[1..n], X [1..n], M)

/* P[1..n] and W[1..n] contains the profit and weight of the n-objects ordered such
that

X[1..n] is a solution set and M is the capacity of KnapSack*/

{

Page no: 7 V
 1: For i ← to n do
2: X[i] ←
3: profit ← //Total profit of item filled in Knapsack
4: weight ← // Total weight of items packed in KnapSack
5: i←
6: While (Weight < M) // M is the Knapsack Capacity
{
7: if (weight + W[i] ≤ M)
8: X[i] = 1
9: weight = weight + W[i]
10: else

11: X[i] = (M-weight)/w[i]

12: weight = M

13: Profit = profit = profit + p [i]*X[i]

14: i++;

}//end of while

}//end of Algorithm

Running time:

The objects are to be sorted into non-decreasing order of pi / wi ratio. But if we disregard the time to initially
sort the objects, the algorithm requires O(nlogn) time.

JOB SEQUENCING WITH DEADLINES

When we are gi e a set of jo s. Asso iated ith ea h Jo i, deadli e di > a d p ofit Pi > . Fo a jo i the profit pi is
earned iff the job is completed by its deadline. Only one machine is available for processing jobs. An optimal
solution is the feasible solution with maximum profit.

“o t the jo s i j o de ed thei deadli es. The a a d [ : ] is used to sto e the deadli es of the o de of their p-alues.
The set of jo s j [ : k] su h that j [ ], ≤ ≤ k a e the jo s i j a d d j [ ] ≤ d j[ ] ≤ . . . ≤ d (j[k]). To test whether J U {i} is
feasible, we have just to insert i into J preserving the deadline ordering and the e if that d [J[ ]] ≤ , ≤ ≤ k+ .

Algorithm GreedyJob (d, J, n)

// J is a set of jobs that can be completed by their deadlines.

J := {1};

for i := 2 to n do

if (all jobs in J U {i} can be completed by their dead lines) then

J := J U {i};

Page no: 8 V
 We still have to discuss the running time of the algorithm. The initial sorting can be done in time O(n log n),
and the rest loop takes time O(n). It is not hard to implement each body of the second loop in time O(n), so the
total loop takes time O(n2). So the total algorithm runs in time O(n2). Using a more sophisticated data structure
one can reduce this running time to O(n log n), but in any case it is a polynomial-time algorithm.

The Single Source Shortest-Path Problem: DIJKSTRA'S ALGORITHMS

In the previously studied graphs, the edge labels are called as costs, but here we think them as lengths. In a
labeled graph, the length of the path is defined to be the sum of the lengths of its edges.

In the single source, all destinations, shortest path problem, we must find a shortest path from a given source
vertex to each of the vertices (called destinations) in the graph to which there is a path.

Dijkst a s algo ith is si ila to p i 's algo ith for finding minimal spanning trees.
Dijkst a s algo ith takes a la eled g aph a d a pai of e ti es P a d Q, a d fi ds the sho test path et ee then (or one
of the shortest paths) if there is more than one. The principle of optimality is the basis for Dijkst a s algo ith s.
Dijkst a s algo ith does ot o k fo egati e edges at all.

Algorithm Shortest-Paths (v, cost, dist, n)

// dist [j], 1 < j < n, is set to the length of the shortest
path // from vertex v to vertex j in the digraph G with n
vertices. // dist [v] is set to zero. G is represented by its //
cost adjacency matrix cost [1:n, 1:n].
{

for i :=1 to n do

S [i] := false; // Initialize S. dist [i] :=cost [v, i]; }

S[v] := true; dist[v] := 0.0; // Put v in S. for num := 2 to n – 1 do

Determine n - 1 paths from v.

Choose u from among those vertices not in S such that dist[u] is minimum; S[u] := true; // Put u is S.
for (each w adjacent to u with S [w] = false) do
if (dist [w] > (dist [u] + cost [u, w]) then // Update distances dist [w] := dist [u] + cost [u, w];

Running time:

For heap A = O (n); B = O (log n); C = O (log n) which gives O (n + m log n) total.

Page no: 9 V
 UNIT-II
REQUIREMENT ELICITATION ANALYSIS & SPECIFICATION
13. Requirement: -
The process to gather the software requirements from client, analyze and document them is known as requirement
engineering.

The goal of requirement engineering is to develop and mai tai sophisti ated a d des ipti e “ ste ‘e ui e e ts “pe
ifi atio do u e t.

14. Types of Requirements: -

• User Requirements: It is a collection of statement in natural language and description of the services the system
provides and its operational limitation. It is written for customer.
• System Requirement: It is a structured document that gives the detailed description of the system services. It is
written as a contract between client and contractor.

15. Software Requirement Specification: -

SRS is a document created by system analyst after the requirements are collected from various stakeholders. SRS defines
how the intended software will interact with hardware, external interfaces, speed of operation, response time of system,
portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality,
Limitations etc.

The requirements received from client are written in natural language. It is the responsibility of system analyst to
document the requirements in technical language so that they can be comprehended and useful by the software
development team.

SRS should come up with following features:

• User Requirements are expressed in natural language.
• Technical requirements are expressed in structured language, which is used inside the organization.  Design
description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.
16. 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:
1. Functional Requirement
2. Non Functional Requirement

FUNCTIONAL REQUIREMENTS:
It should describe all requirement functionality or system services. The customer should provide statement of service. it
should be clear how the system should be reacting to particular input and how a particular system should behave in
particular situation. Functional requirement is heavily depending upon he type of software expected users and the type
of system where the software is used. It describes system services in detail.

NON-FUNCTIONAL REQUIREMENTS:

Page no: 1
 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 are more critical than functional
requirement if the non-functional requirement do not meet then the complete system is of no use.

17. Some typical non-functional requirements are:  Product

requirement-
Specify how a livered product should behave in particular way.
o Eg: efficiency, Usability, Reliability, portability
 Organizational requirement- The requirements which are unwelcome effect of organizational policies and procedures
come under this category. o Eg: Delivery, implementation, standard  External requirement-

These requirements arise due to the factors that are external of the system and its developed process. o Eg:
Interoperability, ethical, safety.

REQUIREMENT SOURCES AND ELICITATION TECHNIQUES:

18. Requirements Sources:-
In a typical system, there will be many sources of requirements and it is essential that all potential sources are identified
and evaluated for their impact on the system. This subtopic is designed to promote awareness of different requirements
sources and frameworks for managing them.

The main points covered are:

• Goals: -The te Goal so eti es alled usi ess o e o iti al su ess fa to efe s to the o e all, high-level objectives of the system.
Goals provide the motivation for a. Requirements engineers need to pay particular attention to assessing the value
(relative to priority) and cost of goals. A feasibility study is a relatively low-cost way of doing this.
• Domain knowledge: - The requirements engineer needs to acquire or to have available knowledge about the
application domain. This enables them to infer tacit knowledge that the stakeholders do not articulate, assess the
trade-offs that will be necessary between conflicting requirements and sometimes to act as a use ha pio .
• System stakeholders: -Many systems have proven unsatisfactory because they have stressed the requirements for one
group of stakeholders at the expense of others. Hence, systems are delivered that are hard to use or which subvert
the cultural or political structures of the customer organization. The e ui e e ts e gi ee eeds to ide tif ep ese t a d a age
the ie poi ts of a different types of stakeholder.
• The operational environment: -Requirements will be derived from the environment in which the software will
execute. These may be, for example, timing constraints in a real-time system or interoperability constraints in an office
environment. These must be actively sought because they can greatly affect system feasibility, cost, and restrict design
choices.
• The organizational environment: -Many systems are required to support a business process and this may be
conditioned by the structure, culture and internal politics of the organization. The requirements engineer needs to be
sensitive to these since, in general, new software systems should not force unplanned change to the business process.

19. Elicitation techniques: -

When the requirements sources have been identified the requirements, engineer can start eliciting requirements from
them. It also means requirement discovery. This subtopic concentrates on techniques for getting human stakeholders to
articulate their requirements. This is a very difficult area and the requirements engineer needs to be sensitized to the
fact that (for example) users may have difficulty describing their tasks, may leave important information unstated, or may
be unwilling or unable to cooperate. It is particularly important to understand that elicitation is not a passive activity and
that even if cooperative and articulate stakeholders are available, the requirements engineer has to work hard to elicit
the right information. A number of techniques will be covered, but the principal ones are:
• Interviews:-I te ie s a e a t aditio al ea s of eli iti g e ui e e ts. It is i po ta t to u de sta d the advantages and limitations of
interviews and how they should be conducted.

Page no: 2
 • Scenarios: - Scenarios are alua le fo p o idi g o te t to the eli itatio of use s e ui e e ts. The allo the e ui e e ts e gi ee to p
o ide a f a e o k fo uestio s a out use s tasks pe itti g hat if? a d ho is this do e? uestio s to e asked. Conceptual
modeling) because recent modeling notations have attempted to integrate scenario notations with object-oriented
analysis techniques.
• Prototypes: -Prototypes are a valuable tool for clarifying unclear requirements. They can act in a similar way to
scenarios by providing a context within which users better understand what information they need to provide. There is
a wide range of prototyping techniques, which range from paper mock-ups of screen designs to beta-test versions of
software products. There is a strong overlap with the use of prototypes for requirements validation.
• Facilitated meetings: -The purpose of these is to try to achieve a summative effect whereby a group of people can
bring more insight to their requirements than by working individually. They can brainstorm and refine ideas that may
be difficult to surface using (e.g.) interviews.
• Observation: -The i po ta e of s ste s o te t ithi the o ga izatio al e i o e t has led to the adaptation of observational
techniques for requirements elicitation. The requirements engineer learns about use s tasks i e si g the sel es i the e i o
e t a d o se i g ho use s i te a t ith thei systems and each other. These techniques are relatively new and expensive but
are instructive because they illustrate that many user tasks and business processes are too subtle and complex for their
actors to describe easily.
1. Requirement
Discovery

2. Requirement
4. Requirement
Classification &
Specification
Organization

3. Requirement
Prioritization &
Negotiations

Figure 2.1 Requirement Prototype

ANALYSIS MODELING FOR FUNCTION ORIENTED AND OBJECT ORIENTED SOFTWARE DEVELOPMENT :
20. Analysis model: -
The analysis model must achieve three primary objectives:
• To describe what the customer requires(analysis)
• To establish a basis for the creation of software with a combination of text and design are used to represent the
software requirement.
• To define a set of requirements that can be validated once the software is built.
21. The elements of analysis model: -
At the core of the model lies the data dictionary—a repository that contains descriptions of all data objects consumed or
produced by the software. Three different diagrams surround the core. The entity relation diagram (ERD) depicts
relationships between data objects. The ERD is the notation that is used to conduct the data modeling activity. The
attributes of each data object noted in the ERD can be described using a data object description.

The data flow diagram (DFD) serves two purposes: (1) to provide an indication of how data are transformed as they move
through the system and (2) to depict the functions (and sub functions) that transform the data flow.

Page no: 3
 The DFD provides additional information that is used during the analysis of the information domain and serves as a basis
for the modeling of function. A description of each function presented in the DFD is contained in a process specification
(PSPEC).

The state transition diagram (STD) indicates how the system behaves as a consequence of external events. To accomplish
this, the STD represents the various modes of behavior (called states) of the system and the manner in which transitions
are made from state to state. The STD serves as the basis for behavioral modeling. Additional information about the
control flow in the control specification (CSPEC). Process specification describes each function in DFD. Data object
description of various data object used.

Data Flow
Data Object Diagram
description

Entity DFD
Relationship
Diagram
Data
Dictionary

State- transition Diagram

Control
Specification

Figure 2.2: State Transition Diagram

22. Analysis and Modeling: - Structured Approach
Data Modeling -> ERD

Functional Modeling -> DFD

Behavior Modeling -> State chart diagram

23. Object Oriented Approach (UML)

• Use case
• Class diagram
• Activity diagram
• Sequence diagram
• Deployment diagram
• Component diagram
24. The structured approach - plan the right way first
• plans to avoid crisis
• covers all eventualities
• useful for team working  shorter in the end
In SA data object are modeled in a way in which data attributes and their relationship is defined in structured approach.

Data Flow Diagram (DFD):

Page no: 4
 • The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the different
processing activities or functions that the system
• Performs and the data interchange among these functions. Each function is considered as a processing station
(or process) that consumes some input data and produces some output data. The system is represented in terms
of the input
• Data to the system, various processing carried out on these data, and the output
• Data generated by the system. A DFD model uses a very limited number of primitive symbols as shown in below
Figure to represent the functions performed by a system and the data flow among these functions.

25. Levels of DFD

 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire information system as one
diagram concealing all the underlying details. Level 0 DFDs are also known as context level DFDs.

User registration
(view the book detail)
Library
Administrator Management User/student

Read and write

System

Book request/return

Library Database

26. Figure 2.3: Level 0 DFD

Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1DFD depicts basic modules in the system
and flow of data among various modules. Level 1 DFD also mentions basic processes and sources of

information.
Account

Finance
Verification

Customer Order Store

Date Processing
Verif Issue
Proces Order
Sales

order Deliver

Customers

Page no: 5
 27. Figure 2.4: Level 1 DFD

Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.

Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of understanding unless the
desired level of specification is achieved.

28. Behavior Modeling: - Structure Charts: -

Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail than DFD. It breaks
down the entire system into lowest functional modules, describes functions and sub-functions of each module of the
system to a greater detail than DFD.

A structure chart represents the software architecture, i.e. the various modules making up the system, the dependency
(which module calls which other modules), and the parameters that are passed among the different modules. The basic
building blocks which are used to design structure charts are the following:
• Rectangular boxes: Represents a module.
• Module invocation arrows: Control is passed from one module to another module in the direction of the
connecting arrow.
• Data flow arrows: Arrows are annotated with data name; named data passes from one module to another
module in the direction of the arrow.
• Library modules: Represented by a rectangle with double edges.
• Selection: Represented by a diamond symbol.
• Repetition: Represented by a loop around the control flow arrow.

29. Transform Analysis: -

Transform analysis identifies the primary functional components (modules) and the high-level inputs and outputs for
these components. The first step in transform analysis is to divide the DFD into 3 types of parts:  Input
• Logical processing
• Output

The input portion of the DFD includes processes that transform input data from physical (e.g. character from terminal) to
logical forms (e.g. internal tables, lists etc.). Each input portion is called an afferent branch. The output portion of a DFD
transforms output data from logical to physical form. Each output portion is called an efferent branch. The remaining
portion of a DFD is called the central transform.

Example: Structure chart for the RMS software

For this example, the context diagram was drawn earlier.

30. Object-oriented Software Development: - Object-oriented

design: -
In the object-oriented design approach, the system is viewed as collection of objects (i.e. entities). The state is
decentralized among the objects and each object manages its own state information. For example, in a Library
Automation Software, each library member may be a separate object with its own data and functions to operate on
these data. In fact, the functions defined for one object cannot refer or change data of other objects. Objects have their
own internal data which define their state. Similar objects constitute a class. In other words, each object is a member of
some class. Classes may inherit features from super class. Conceptually, objects communicate by message passing.

Page no: 6
 31. What is a model: -
A model captures aspects important for some application while omitting (or abstracting) the rest. A model in the context
of software development can be graphical, textual, mathematical, or program code-based. Models are very useful in
documenting the design and analysis results. Models also facilitate the analysis and design procedures themselves.
Graphical models are very popular because they are easy to understand and construct. UML is primarily a graphical
modeling tool. However, it often requires text explanations to accompany the graphical models.

Need for a model:

An important reason behind constructing a model is that it helps manage complexity. Once models of a system have
been constructed, these can be used for a variety of purposes during software development, including the following:
• Analysis
• Specification
• Code generation
• Design
• Visualize and understand the problem and the working of a system  Testing, etc.
In all these applications, the UML models can not only be used to document the results but also to arrive at the results
themselves. Since a model can be used for a variety of purposes, it is reasonable to expect that the model would vary
depending on the purpose for which it is being constructed. For example, a model developed for initial analysis and
specification should be very different from the one used for design. A model that is being used for analysis and
specification would not show any of the design decisions that would be made later on during the design stage. On the
other hand, a model used for design purposes should capture all the design decisions. Therefore, it is a good idea to
explicitly mention the purpose for which a model has been developed, along with the model.

32. Unified Modeling Language (UML):-

UML, as the name implies, is a modeling language. It may be used to visualize, specify, construct, and document the
artifacts of a software system. It provides a set of notations (e.g. rectangles, lines, ellipses, etc.) to create a visual model
of the system. Like any other language, UML has its own syntax (symbols and sentence formation rules) and semantics
(meanings of symbols and sentences). Also, we should clearly understand that UML is not a system design or
development methodology, but can be used to document object-oriented and analysis results obtained using some
methodology.

UML Diagrams:
UML can be used to construct nine different types of diagrams to capture five different views of a system. Just as a
building can be modeled from several views (or perspectives) such as ventilation perspective, electrical perspective,
lighting perspective, heating perspective, etc.; the different UML diagrams provide different perspectives of the software
system to be developed and facilitate a comprehensive understanding of the system. Such models can be refined to get
the actual implementation of the system. The UML diagrams can capture the following five views of a system:
• Use s ie
• Structural view
• Behavioral view
• Implementation view
• Environmental view

User’s ie : This view defines the functionalities (facilities) made available by the system to its users. The use s ie aptu es
the e te al use s ie of the s ste i te s of the fu tio alities offe ed the s ste . The use s ie is a la k-box view of the system

Page no: 7
 where the internal structure, the dynamic behavior of different system components, the implementation etc. are not
visible.

Structural view: The structural view defines the kinds of objects (classes) important to the understanding of the working
of a system and to its implementation. It also captures the relationships among the classes (objects). The structural
model is also called the static model, since the structure of a system does not change with time.

Behavioral view: The behavioral view captures how objects interact with each other to realize the system behavior. The
system behavior captures the time-dependent (dynamic) behavior of the system.

Implementation view: This view captures the important components of the system and their dependencies.
Environmental view: This view models how the different components are implemented on different pieces of hardware.

USE-CASE MODELING:
Use case modeling was originally developed by Jacobson et al. (1993) in the 1990s and was incorporated into the first
release of the UML (Rumbaugh et al., 1999). Use case modeling is widely used to support requirements elicitation. A use
case can be taken as a simple scenario that describes what a user expects from a system.

33. Use-case Model: -

The use ase odel fo a s ste o sists of a set of use ases . I tuiti el , use ases ep ese t the diffe e t ways in which a system can
be used by the users. A simple way to find all the use cases of a system is to ask the uestio : What the use s a do usi g the
s ste ?
Thus, for the Library Information System (LIS), the use cases could be: 
issue-book

 query-book
 return-book Login
 create-member
 add-book etc
Renew
book

Search
book
Check
availability book
Figure 2.5

User Reserve Librarian

book
Update
Book_Recored

Check
account

Return_Book

Page no: 8
 Figure 2.5: Use Case Diagram
Use cases correspond to the high-level functional requirements. The use cases partition the system behavior into
transactions, such that each transaction performs so e useful a tio f o the use s poi t of ie . To complete each transaction
may involve either a single message or multiple message exchanges between the user and the system to complete.

Purpose of use cases: -

The purpose of a use case is to define a piece of coherent behavior without revealing the internal structure of the
system. The use cases do not mention any specific algorithm to be used or the internal data representation, internal
structure of the software, etc. A use case typically represents a sequence of interactions between the user and the
system. These interactions consist of one mainline sequence. The mainline sequence represents the normal interaction
between a user and the system. The mainline sequence is the most occurring sequence of interaction.

Representation of use cases: -

Use cases can be represented by drawing a use case diagram and writing an accompanying text elaborating the drawing.
In the use case diagram, each use case is represented by an ellipse with the name of the use case written inside the
ellipse. All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which represents the system boundary.
The name of the system being modeled (such as Library Information System) appears inside the rectangle.

Text Description: -
Each ellipse on the use case diagram should be accompanied by a text description. The text description should define the
details of the interaction between the user and the computer and other aspects of the use case. It should include all the
behavior associated with the use case in terms of the mainline sequence, different variations to the normal behavior, the
system responses associated with the use case, the exceptional conditions that may occur in the behavior, etc.

Contact persons: This section lists the personnel of the client organization with whom the use case was discussed, date
and time of the meeting, etc.

Actors: In addition to identifying the actors, some information about actors using this use case which may help the
implementation of the use case may be recorded.

Pre-condition: The preconditions would describe the state of the system before the use case execution starts.

Post-condition: This captures the state of the system after the use case has successfully completed.

Non-functional requirements: This could contain the important constraints for the design and implementation, such as
platform and environment conditions, qualitative statements, response time requirements, etc.

Exceptions, error situations: This contains only the domain- elated e o s su h as la k of use s a ess ights, invalid entry in
the input fields, etc. Obviously, errors that are not domain related, such as software errors, need not be discussed here.

Sample dialogs: These serve as examples illustrating the use case.

Specific user interface requirements: These contain specific requirements for the user interface of the use case. For
example, it may contain forms to be used, screen shots, interaction style, etc.

Document references: This part contains references to specific domain related documents which may be useful to
understand the system operation.

SYSTEM AND SOFTWARE REQUIREMENT SPECIFICATIONS:

Page no: 9
 Software Specification: -
Software Specification is an activity that is use to describe he thing you are trying to achieve to establish what services
are required from the system and limitation on the system operation and development. His activity is often called
Requirement Engineering. Requirement Engineering is a particularly critical stage of the software process as error at this
stage certain to happen lead to later problem in the system design and implementation.

There are four main phases in the Requirement Engineering process:

• Feasibility study: user satisfaction, cost estimation.
• Requirement elicitation analysis: meeting for description of development.
• Requirement Specification: is the activity of translating the information gathered during the analysis activity into a
document that defines a set of requirements. 2 types of requirements may be including in his document.
• User Requirements (b) System Requirement
• Requirements Validation: this activity checks the requirement for realism, consistency and completeness.

Software Requirement Specification [SRS]: -

A software requirements specification (SRS) is a document that captures complete description about how the system is
expected to perform. It is usually signed off at the end of requirements engineering phase.

The Software Requirements Specification is produced at the culmination of the analysis task. The function and
performance allocated to software as part of system engineering are refined by establishing a complete information
description, a detailed functional description, a representation of system behavior, an indication of performance
requirements and design constraints, appropriate validation criteria, and other information pertinent to requirements.
• A description of each function required to solve the problem is presented in the Functional Description. A
processing narrative is provided for each function, design constraints are stated and justified, performance
characteristics are stated, and one or more diagrams are included to graphically represent the overall structure
of the software and interplay among software functions and other system elements.
• The Behavioral Description section of the specification examines the operation of the software as a consequence
of external events and internally generated control characteristics.
• Validation Criteria is probably the most important and, ironically, the most often neglected section of the
Software Requirements Specification. How do we recognize a successful implementation? What classes of tests
must be conducted to validate function, performance, and constraints? We neglect this section because
completing it demands a thorough understanding of software requirements— something that we often do not
have at this stage. Yet, specification of validation criteria acts as an implicit review of all other requirements. It is
essential that time and attention be given to this section.
• Finally, the specification includes a Bibliography and Appendix. The bibliography contains references to all
documents that relate to the software. These include other software engineering documentation, technical
references, vendor literature, and standards. The appendix contains information that supplements the
specifications. Tabular data, detailed description of algorithms, charts, graphs, and other material are presented
as appendixes.
In many cases the Software Requirements Specification may be accompanied by an executable prototype (which in some
cases may replace the specification), a paper prototype or a Preliminary User s Manual. The Preliminary User s Manual
presents the software as a black box. That is, heavy emphasis is placed on user input and the resultant output. The
manual can serve as a valuable tool for uncovering problems at the human/machine interface.

Characteristics of SRS:
• Correct: Requirement must be correctly mentioned and realistic by nature.
• Unambiguous: Transparent and plain SRS must be written.

Page no: 10
 • Complete: To make the SRS complete I should be specified what a software designer wants to create on
software.
• Consistent: If there are not conflicts in the specified requirement then SRS is said to be consistent.
• Stability: The SRS must contain all the essential requirement. Each requirement must be clear and explicit.
• Verifiable: the SRS should be written in such a manner that the requirement that is specified within it must be
satisfied by the software.
• Modifiable: It can easily modify according to user requirement.
• Traceable: If origin of requirement is properly given of the requirement are correctly mentioned then such a
requirement is called as traceable requirement.

REQUIREMENTS VALIDATION:
The work products produced as a consequence of requirements engineering are assessed for quality during a validation
step. Requirements validation examines the specification to ensure that all system requirements have been stated
unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work
products conform to the standards established for the process, the project, and the product.

The primary requirements validation mechanism is the formal technical review. The review team includes system
engineers, customers, users, and other stakeholders who examine the system specification 5 looking for errors in content
or interpretation, areas where clarification may be required, missing information, inconsistencies , conflicting
requirements, or unrealistic (unachievable) requirements.

Although the requirements validation review can be conducted in any manner that results in the discovery of
requirements errors, it is useful to examine each requirement against a set of checklist questions. The following
questions represent a small subset of those that might be asked:
• Are requirements stated clearly? Can they be misinterpreted?
• Is the source (e.g., a person, a regulation, a document) of the requirement identified? Has the final statement of
the requirement been examined by or against the original source?
• Is the requirement bounded in quantitative terms?
• What other requirements relate to this requirement? Are they clearly noted via a cross-reference matrix or other
mechanism?
• Does the requirement violate any domain constraints?
• Is the requirement testable? If so, can we specify tests (sometimes called validation criteria) to exercise the
requirement?
• Is the requirement traceable to any system model that has been created?
• Is the requirement traceable to overall system/product objectives?
• Is the system specification structured in a way that leads to easy understanding, easy reference, and easy
translation into more technical work products?
• Has an index for the specification been created?
• Have requirements associated with system performance, behavior, and operational characteristics been clearly
stated? What requirements appear to be implicit?

Requirements Management: -
Requirements management is a set of activities that help the project team to identify, control, and track requirements
and changes to requirements at any time as the project proceeds

Once requirements have been identified, traceability tables are developed. Shown schematically in Figureure, each
traceability table relates identified requirements to one or more aspects of the system or its environment. Among many
possible traceability tables are the following:

Page no: 11
 • Features traceability table. Shows how requirements relate to important customer observable system/product
features.
• Source traceability table. Identifies the source of each requirement
• Dependency traceability table. Indicates how requirements are related to one another.
• Subsystem traceability table. Categorizes requirements by the subsystem(s) that they govern.
• Interface traceability table. Shows how requirements relate to both internal and external system interfaces.
In many cases, these traceability tables are maintained as part of a requirements database so that they may be quickly
searched to understand how a change in one requirement will affect different aspects of the system to be built.

TRACEABILITY:
Traceability is a property of an element of documentation or code that indicates the degree to which it can be traced to
its origin or "reason for being". Traceability also indicates the ability to establish a predecessorsuccessor relationship
between one work product and another.

A work product is said to be traceable if it can be proved that it complies with its specification. For example, a software
design is said to be traceable if it satisfies all the requirements stated in the software requirements specification.
Examples of traceability include:

• External source to system requirements

• System requirements to software requirements
• Software requirements to high level design
• High level design to detailed design  Detailed design to code
• Software requirement to test case.

Software Requirement Analysis (SRS) Forward to architecture

Backward from architecture

Software Architecture Design Description (SADD)

Forward from architecture

Backward to architecture
Software Detailed Design Description (SDDD)

Figure 2.6: Tracing a Software Architecture Design Description

Page no: 12
Page no: 13
 Concept of dynamic programming, problems based on this approach such as 0/1 knapsack, multistage graph,
reliability design, Floyd Warshall algorithm

34. Unit-3
Concept of Dynamic Programming
Dynamic programming is a name, coined by Richard Bellman in 1955. Dynamic programming, as greedy
method, is a powerful algorithm design technique that can be used when the solution to the problem may be
viewed as the result of a sequence of decisions. In the greedy method we make irrevocable decisions one at a
time, using a greedy criterion. However, in dynamic programming we examine the decision sequence to see
whether an optimal decision sequence contains optimal decision subsequence.

When optimal decision sequences contain optimal decision subsequences, we can establish recurrence
equations, called dynamic-programming recurrence equations, that enable us to solve the problem in an
efficient way.

Dynamic programming is based on the principle of optimality (also coined by Bellman). The principle of
optimality states that no matter whatever the initial state and initial decision are, the remaining decision
sequence must constitute an optimal decision sequence with regard to the state resulting from the first
decision. The principle implies that an optimal decision sequence is comprised of optimal decision
subsequences. Since the principle of optimality may not hold for some formulations of some problems, it is
necessary to verify that it does hold for the problem being solved. Dynamic programming cannot be applied
when this principle does not hold.

The steps in a dynamic programming solution are:

• Verify that the principle of optimality holds

• Set up the dynamic-programming recurrence equations

• Solve the dynamic-programming recurrence equations for the value of the optimal solution.
• Perform a trace back step in which the solution itself is constructed.
0/1 – KNAPSACK
Given weights and values of n items, put these items in a knapsack of capacity W to get the maximum total
value in the knapsack. In other words, given two integer arrays val[0..n-1] and wt[0..n-1] which represent
values and weights associated with n items respectively. Also given an integer W which represents knapsack
capacity, find out the maximum value subset of val[] such that sum of the weights of this subset is smaller than
or equal to W. You cannot break an item, either pick the complete item, or do’t pick it (0-1 property). Dynamic-
0-1-knapsack (v, w, n, W) for w = 0 to W do c[0, w] = 0 for i = 1 to n do c[i, 0] = 0

for w = 1 to W do

if i ≤ the
if vi + c[i-1, w-wi] then
c[i, w] = vi + c[i-1, w-wi] else
c[i, w] = c[i-1, w]

Page no: 1
 else

c[i, w] = c[i-1, w]

MULTI STAGE GRAPHS

A multistage graph is a graph o G=(V,E) with V partitioned into K >= 2 disjoint subsets such that if (a,b) is in E,
then a is in Vi , and b is in Vi+1 for some subsets in the partition;

o and | V1 | = | VK | = 1.

The vertex s in V1 is called the source; the vertex t in VK is called the sink.

G is usually assumed to be a weighted graph.

The cost of a path from node v to node w is sum of the costs of edges in the path. The
"multistage graph problem" is to find the minimum cost path from s to t.

Dynamic Programming solution:

Let path(i,j) be some specification of the minimal path from vertex j in set i to vertex t; C(i,j) is the cost of this
path; c(j,t) is the weight of the edge from j to t.

To write a simple algorithm, assign numbers to the vertices so those in stage Vi have lower number those in
stage Vi+1.

int[] MStageForward(Graph G)

// returns vector of vertices to follow through the graph //

let c[i][j] be the cost matrix of G

int n = G.n (number of nodes);

int k = G.k (number of stages);
float[] C = new float[n]; int[] D =
new int[n]; int[] P = new int[k];
for (i = 1 to n) C[i] = 0.0; for j = n-
1 to 1 by -1 {
r = vertex such that (j,r) in G.E and c(j,r)+C(r) is minimum C[j]
= c(j,r)+C(r);

D[j] = r;

P[1] = 1; P[k] = n;
for j = 2 to k-1
{ P[j] = D[P[j-1]];

return P;

Page no: 2
 }

Time complexity:
Complexity is O (|V| + |E|). Where the |V| is the number of vertices and |E| is the number of edges. Example
Consider the following example to understand the concept of multistage graph.

Figure 3.1 Multistage Graph

Step-1: Cost (K-2, j)

In this step, three nodes (node 4, 5. 6) are selected as j. Hence, we have three options to choose the minimum
cost at this step.

Cost(3, 4) = min {c(4, 7) + Cost(7, 9),c(4, 8) + Cost(8, 9)} = 7

Cost(3, 5) = min {c(5, 7) + Cost(7, 9),c(5, 8) + Cost(8, 9)} = 5

Cost(3, 6) = min {c(6, 7) + Cost(7, 9),c(6, 8) + Cost(8, 9)} = 5

Step-2: Cost (K-3, j)

Two nodes are selected as j because at stage k - 3 = 2 there are two nodes, 2 and 3. So, the value i = 2 and j = 2
and 3.

Cost(2, 2) = min {c(2, 4) + Cost(4, 8) + Cost(8, 9),c(2, 6) +

Cost(6, 8) + Cost(8, 9)} = 8

Cost(2, 3) = {c(3, 4) + Cost(4, 8) + Cost(8, 9), c(3, 5) + Cost(5, 8)+ Cost(8, 9), c(3, 6) + Cost(6, 8) + Cost(8, 9)} = 10

Step-3: Cost (K-4, j)

Cost (1, 1) = {c(1, 2) + Cost(2, 6) + Cost(6, 8) + Cost(8, 9), c(1, 3) + Cost(3, 5) + Cost(5, 8) + Cost(8, 9))} = 12 c(1,

3) + Cost(3, 6) + Cost(6, 8 + Cost(8, 9))} = 13

Hence, the path having the minimum cost is → → → →

RELIABILITY DESIGN

In reliability design, the problem is to design a system that is composed of several devices connected in series.

Page no: 3
 Figure 3.2 Reliability Design(Serial Connection)

If we imagine that r1 is the reliability of the device.Then the reliability of the function can be given by πr .If r1 =
0.99 and n = 10 that n devices are set in a series, 1 <= i <= 10, then reliability of the whole system πri can be
given as: Πri = .

So, if we duplicate the devices at each stage then the reliability of the system can be increased.

It can be said that multiple copies of the same device type are connected in parallel through the use of switching
circuits. Here, switching circuit determines which devices in any given group are functioning properly. Then they
make use of such devices at each stage, that result is increase in reliability at each stage. If at each stage, there
are mi similar types of devices Di, then the probability that all mi have a malfunction is (1 - ri)^mi, which is very
less.

And the reliability of the stage I becomes (1 – (1 - ri) ^mi). Thus, if ri = 0.99 and mi = 2, then the stage reliability
becomes 0.9999 which is almost equal to 1. Which is much better than that of the previous case or we can say
the reliability is little less than 1 - (1 - ri) ^mi because of less reliability of switching circuits.

Figure 3.3 Reliability Design(Parallel Connection)

In reliability design, we try to use device duplication to maximize reliability. But this maximization should be
considered along with the cost.

FLOYD WARSHALL ALGORITHM

The Floyd Warshall Algorithm is for solving the All Pairs Shortest Path problem. The problem is to find shortest
distances between every pair of vertices in a given edge weighted directed Graph.

All pairs shortest paths

Page no: 4
 In the all pairs shortest path problem, we are to find a shortest path between every pair of vertices in a
directed graph G. That is, for every pair of vertices (i, j), we are to find a shortest path from i to j as well as one
from j to i. These two paths are the same when G is undirected.

When no edge has a negative length, the all-pairs shortest path problem may be solved by using Dijkstra’s
greedy si gle source algorith ti es, o ce ith each of the ertices as the source vertex.

The all pairs shortest path problem is to determine a matrix A such that A (i, j) is the length of a shortest path
from i to j. The matrix A can be obtained by solving n single-source problems using the algorithm shortest
Paths. Since each application of this procedure requires O (n2) time, the matrix A can be obtained in O (n3)
time.

Algorithm All Paths (Cost, A, n)

// cost [1:n, 1:n] is the cost adjacency matrix of a graph which // n

vertices; A [I, j] is the cost of a shortest path from vertex // i to
vertex j. cost [i, i] = 0.0, for 1 < i < n.
{

for i := 1 to n do for
j:= 1 to n do

A [i, j] := cost [i, j]; // copy cost into A. for k := 1 to n do for

i := 1 to n do for j := 1 to n do
A [i, j] := min (A [i, j], A [i, k] + A [k, j]);

Complexity Analysis:
A Dynamic programming algorithm based on this recurrence involves in calculating n+1 matrices, each of size n
x n. Therefore, the algorithm has a complexity of O (n3).

Problem-
Consider the following directed weighted graph-

Figure 3.4 Floyd Warshall Example Solution-

Step-01:

 Remove all the self loops and parallel edges (keeping the edge with lowest weight) from the
graph if any.
 I our case, e do ’t ha e a y self edge a d parallel edge. Step-02:

Page no: 5
 Now, write the initial distance matrix representing the distance between every pair of vertices as mentioned in
the given graph in the form of weights.

 For diagonal elements (representing self-loops), value = 0

 For vertices having a direct edge between them, value = weight of that edge  For vertices
having no direct edges between them, value = ∞

Step-03:
The four matrices are-

The last matrix D4 represents the shortest path distance between every pair of vertices.

Page no: 6
 UNIT-III

SOFTWARE DESIGN PROCESS:

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.

The architectural design defines the relationship between major structural elements of the software, the desig patte s
that a e used to a hie e the e ui e e ts that ha e ee defi ed fo the s ste .

Data object specification Process Specification

Entity Data Flow Diagram

Relationship
Component
Diagram
Level design

Data
Dictionary Interface design

Architectural design

State Chart Diagram

Data design

Design Model
Control Specification
Figure 3.1: Software Design and Software Engineering
The Design Process:

Software design is an iterative pro ess th ough hi h e ui e e ts a e t a slated i to a luep i t fo constructing the software.
Initially, the blueprint depicts a holistic view of software. That is, the design is represented at a high level of abstraction
at level that can be directly traced to the specific system objective and more detailed data, functional, and behavioral
requirements. As design iterations occur, subsequent refinement leads to design representations at much lower level of
abstraction. These can still be trace or requirements, but the connection is subtler.
DESIGN CONCEPTS AND PRINCIPLES:
Design Principles: -
Software design is both a process and a model. The design process is a sequence of steps that enable the designer to
describe all aspects of the software to be built. It is important to note, however, that the design p o ess is ot si pl a ook
ook. C eati e skill, past e pe ie e, a se se of hat akes good soft a e, a d an overall commitment to quality are critical success
factors for a competent design.

Page no: 1
 The desig odel is the e ui ale t of a a hite t s pla s fo a house. It egi s ep ese ti g the totalit of the thing to be built (e.g., a
three-dimensional rendering of the house) and slowly refines the thing to provide guidance for constructing each detail
(e.g., the plumbing layout). Similarly, the design model that is created for software provides a variety of different views of
the computer software. Basic design principles enable the software engineer to navigate the design process.
Principles for software design, which have been adapted and extended in the following list:

• The desig p o ess should ot suffe f o tu el isio .

• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should i i ize the i telle tual dista e et ee the soft a e a d the p o le as it exists in the real world.
• That is, the structure of the software design should (whenever possible) mimic the structure of the problem
domain.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently.
• The design should be assessed for quality as it is being created, not after the fact.  The design should be
reviewed to minimize conceptual (semantic) errors. Design concepts:
Following issues are considered while designing the software.

• Abstraction: A st a tio pe its o e to o e t ate o a p o le at so e le el of a st a tio without regard to low level detail. At
the highest level of abstraction a solution is stated in broad terms using the language of the problem
environment. At lower level, a procedural orientation is taken. At the lowest level of abstraction the solution is
stated in a manner that can be directly implemented. Types of abstraction: 1. Procedural Abstraction 2. Data
Abstraction
• Refinement: Process of elaboration. Refinement function defined at the abstract level, decompose the statement
of function in a stepwise fashion until programming language statements are reached.
• Modularity: software is divided into separately named and addressable components called modules. Follo s di
ide a d o ue o ept, a o ple p o le is oke do i to se e al a agea le pieces.

SOFTWARE MODELING AND UML:

Software modeling:
Software models are ways of expressing a software design. Usually some sort of abstract language or pictures are used to
express the software design. For object-oriented software, an object modeling language such as UML is used to develop
and express the software design.
Unified Modeling Language (UML):

Over the past decade, Grady Booch, James Rumbaugh, and Ivar Jacobson have collaborated to combine the best features
of their individual object-oriented analysis and design methods into a unified method. The result, called the Unified
Modeling Language (UML), has become widely used throughout the industry. UML allows a software engineer to express
an analysis model using a modeling notation that is governed by a set of syntactic, semantic, and p ag ati ules. I UML, a s
ste is ep ese ted usi g fi e diffe e t ie s that describe the system from distinctly different perspectives. Each view is defined
by a set of diagrams. The following views are present in UML:
• User model view. This view rep ese ts the s ste p odu t f o the use s alled actors in UML) perspective. The use-
case is the modeling approach of choice for the user model view. This important analysis representation
describes a usage scenario from the end-user's perspective.
• Structural model view. Data and functionality are viewed from inside the system. That is, static structure (classes,
objects, and relationships) is modeled.

Page no: 2
 • Behavioral model view. This part of the analysis model represents the dynamic or behavioral aspects of the
system. It also depicts the inter actions or collaborations between various structural elements described in the
user model and structural model views.
• Implementation model view. The structural and behavioral aspects of the system are represented as they are to
be built.
• Environment model view. The structural and behavioral aspects of the environment in which the system is to be
implemented are represented.

UML Diagram Types:

There are several types of UML diagrams:

• User model view represent through:

Use-case Diagram: Shows actors, use-cases, and the relationships between them.
• Structural model view represents through
Class Diagram: Shows relationships between classes and pertinent information about classes themselves.
Object Diagram: Shows a configuration of objects at an instant in time.
• Behavioral model view represents through
Interaction Diagrams: Show an interaction between groups of collaborating objects.
Two types: Collaboration diagram and sequence diagram
Package Diagrams: Shows system structure at the library/package level.
State Diagram: Describes behavior of instances of a class in terms of states, stimuli, and transitions.
Activity Diagram: Very similar to a flowchart— shows actions and decision points, but with the ability to
accommodate concurrency.

• Environment model view represent through

Deployment Diagram: Shows configuration of hardware and software in a distributed system.
• Implementation model view represent through
Component Diagram: It shows code modules of a system. This code module includes application program,
ActiveX control, Java beans and back end databases. It representing interfaces and dependencies among
software architect.
ARCHITECTURAL DESIGN:
Establishing the overall structure of a software system.
Objectives:

• To introduce architectural design and to discuss its importance

• To explain why multiple models are required to document software architecture to describe types of architectural
model that may be used.
• A high-level model of a thing: -
• Describes critical aspects of the thing Understandable to many stakeholders
• Allo s e aluatio of the thi g s p ope ties efo e it is uilt
• Provides well understood tools and techniques for constructing the thing from its blueprint.

ARCHITECTURAL VIEWS AND STYLES:

Architectural Styles:

Page no: 3
 The builder has used an architectural style as a descriptive mechanism to differentiate the house from other styles (e.g.,
A-frame, raised ranch, Cape Cod). But more important, the architectural style is also a pattern for construction. Further
details of the house must be defined, its final dimensions must be specified, customized features may be added, building
materials are to be determined, but the pattern—a e te hall olo ial — guides the builder in his work.

The software that is built for computer-based systems also exhibits one of many architectural styles. Each style
describes a system category that encompasses

• A set of components (e.g., a database, computational modules) that perform a function required by a system;
• A set of connectors that enable o u i atio , o-o di atio s a d oope atio a o g o po e ts.
• Constraints that define how components can be integrated to form the system; and
• Semantic models that enable a designer to understand the overall properties of a system by analyzing the known
properties of its constituent parts. In the section that follows, we consider commonly use d architectural patterns
for software.
The commonly used architectural styles are:
• Data-centered Architectures: A data store (e.g., a file or database) resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or otherwise modify data within the store. A
typical Data-centered style. Clients of the are accesses a central repository. In some cases the data repository is
passive. That is, client software accesses the data independent of any changes to the data or the actions of other
client software. A variation on this app oa h t a sfo s the eposito i to a la k oa d that se ds otifi atio s to lie t
software when data of interest to the client change.
Data-centered architectures promote integrity. That is, existing components can be changed and new client
components can be added to the architecture without concern about other clients (because the client
components operate independently). In addition, data can be passed among clients using the blackboard
mechanism (i.e., the blackboard component serves to coordinate the transfer of information between clients).
Client components independently execute processes.

Client Client
Software Software

Client
Client Software
Software
Data Store
(Repository)
Client
Client Software
Software

Client Client
Software Software

35. Figure 3.2 Data centered architecture

 Data-flow Architectures: This architecture is applied when input data are to be transformed through a series of
computational or manipulative components into output data. A pipe and filter pattern (Figure 3.3 a) has a set of
components, called filters, connected by pipes that transmit data from one component to the next. Each filter
works independently of those components upstream and downstream, is designed to expect data input of a
certain form, and produces data output (to the next filter) of a specified form. However, the filter does not
require knowledge of the working of its neighboring filters.

If the data flow degenerates into a single line of transforms, it is termed batch sequential. This pattern Figure (3.3
b) accepts a batch of data and then applies a series of sequential components (filters) to transform it.

Page no: 4
 Piper
Filter Filter

Filter Filter Filter

Filter

Filter Filter Filter

Filter

36. (a) Pipes and Filters

Filter Filter Filter Filter

(b) Batch Sequential

37. Figure 3.3: Data flow architecture

 Call and return Architectures: The program structure can be easily modified or scaled. The program structure is
organized into modules within the program. In this architecture how modules call each other. The program
structure decomposes the function into control hierarchy where a main program invokes number of program
components.

Main Fan-out

a b c

d k m n
g

l
e h i o p q

f Fan -in
j r
38. Figure 3.4: Call and return architecture
 Object-oriented Architecture: The components of a system encapsulate data and the operations that must be
applied to manipulate the data. Communication and coordination between components is accomplished via
message passing.

Page no: 5
 Class Name A Class Name A
Messages
Attributes Attributes

Operations Operations

Messages Messages

Class Name A Messages Class Name A

Attributes Attributes

Operations Operations

39. Figure 3.5: Object-oriented Architecture

 Layered Architectures: The basic structure of a layered architecture is illustrated in Figure 3.6. A number of
different layers are defined, each accomplishing operation that progressively become closer to the machine
instruction set.

At the outer layer, components service user interface operations. At the inner layer, components perform
operating system interfacing. Intermediate layers provide utility services and application software functions.

These architectural styles are only a small subset of those available to the software designer. Once requirements
engineering uncovers the characteristics and constraints of the system to be built, the architectural pattern
(style) or combination of patterns (styles) that best fits those characteristics and

constraints can be chosen. In many cases, more than one pattern might be appropriate and alternative

architectural styles might be designed and evaluated.

User Interface Layer

Application Layer

Utility Layer

Core
Layer

Components

Figure 3.6: Layered Architecture Components Architectural Views:

4+1 is a architectural view model used for "describing the architecture of software-intensive systems, based on the use of
multiple, concurrent views . The ie s a e used to des i e the s ste f o the ie poi t of different stakeholders, such as end-

Page no: 6
 users, developers and project managers. The four views of the model are logical, development, process and physical
view. In addition selected use cases or scenarios are used to illustrate the architecture serving as the 'plus one' view.
Hence the model contains 4+1 views:
• Development view: The development view illustrates a system from a programmer's perspective and is
concerned with software management. This view is also known as the implementation view. It uses the UML
Component diagram to describe system components. UML Diagrams used to represent the development view
include the Package diagram.
• Logical view: The logical view is concerned with the functionality that the system provides to end-users. UML
diagrams used to represent the logical view include, class diagrams, and state diagrams.
• Physical view: The physical view depicts the system from a system engineer's point of view. It is concerned with
the topology of software components on the physical layer as well as the physical connections between these
components. This view is also known as the deployment view. UML diagrams used to represent the physical view
include the deployment diagram.
• Process view: The process view deals with the dynamic aspects of the system, explains the system processes and
how they communicate, and focuses on the runtime behavior of the system. The process view addresses
concurrency, distribution, integrators, performance, and scalability, etc. UML diagrams to represent process view
include the activity diagram.
• Scenarios: The description of architecture is illustrated using a small set of use cases, or scenarios, which become
a fifth view. The scenarios describe sequences of interactions between objects and between processes. They are
used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a
starting point for tests of an architecture prototype. This view is also known as the use case view.

Logical view Development

view

Scenarios

Process view Physical view

40. Figure 3.7: 4+1 Architectural View Model

USER INTERFACE DESIGN:

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. User interface provides fundamental platform for human-computer interaction.

User interface 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. The software becomes more popular if its user
interface is:  Attractive

• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interfacing screens

Page no: 7
 User interface is broadly divided into two categories:

• Command Line Interface

• Graphical User Interface

User Interface Design Principles:

The principles of user interface design are intended to improve the quality of user interface design.

• The structure principle: Design should organize the user interface purposefully, in meaningful and useful ways
based on clear, consistent models that are apparent and recognizable to users, putting related things together
and separating unrelated things, differentiating dissimilar things and making similar things resemble one another.
The structure principle is concerned with overall user interface architecture.
• The simplicity principle: The design should make simple, common tasks easy, communicating clearly and simply
in the user's own language, and providing good shortcuts that are meaningfully related to longer procedures.
• The visibility principle: The design should make all needed options and materials for a given task visible without
distracting the user with extraneous or redundant information. Good designs don't overwhelm users with
alternatives or confuse with unneeded information.
• The feedback principle: The design should keep users informed of actions or interpretations, changes of state or
condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and
unambiguous language familiar to users.
• The tolerance principle: The design should be flexible and tolerant, reducing the cost of mistakes and misuse by
allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and
sequences and by interpreting all reasonable actions.
• The reuse principle: The design should reuse internal and external components and behaviors, maintaining
consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink
and remember.

User Interface Analysis and Design:

User interface analysis and design can be done with the help of following steps:
• Create different models for the system functions.
• In order to perform these functions identify the human-computer interface tasks.
• Prepare all interface designs by solving various design issues.
• Apply modern tools and techniques to prototype the design.
• Implement design model.
• Evaluate the design from end user to bring quality in it.
These steps can be broadly categorized in two classes.
1. Interface analysis and design models
2. The process

Page no: 8
 Interface analysis and design models

User model Design model Mental model Implementation model

41. Figure 3.8: Interface Analysis and Design Model

Environment analysis
Interface validation and modelling

Start of process

Release
Release
Release
Interface design
Implementation

42. Figure 3.9: Interface Analysis and Design Process

FUNCTION-ORIENTED DESIGN:
In function-oriented design, the system is comprised of many smaller sub-systems known as functions. These functions
are capable of performing significant task in the system. The system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide and conquer methodology is used.

This design mechanism divides the whole system into smaller functions, which provides means of abstraction by
concealing the information and their operation. These functional modules can share information among themselves by
means of information passing and using information available globally.

Another characteristic of functions is that when a program calls a function, the function changes the state of the
program, which sometimes is not acceptable by other modules. Function oriented design works well where the system
state does not matter and program/functions work on input rather than on a state.

Functional design process:

• Data-flow design: Model the data processing in the system using data-flow diagrams.
• Structural decomposition: Model how functions are decomposed to sub-functions using graphical structure
charts.
• Detailed design: The entities in the design and their interfaces are described in detail. These may be recorded in
a data dictionary and the design expressed using a PDL.

Page no: 9
 SA/SD COMPONENT BASED DESIGN:
Structured Analysis and Structured Design: Structured analysis is a set of techniques and graphical tools that allow the
analyst to develop a new kind of system specification that are easily understandable to the user.

Goals of SASD
• Improve Quality and reduce the risk of system failure
• Establish concrete requirements specifications and complete requirements documentation  Focus on
Reliability, Flexibility, and Maintainability of system

Component Based Design:

Component-based architecture focuses on the decomposition of the design into individual functional or logical
components that represent well-defined communication interfaces containing methods, events, and properties. It
provides a higher level of abstraction and divides the problem into sub-problems, each associated with component
partitions.

The primary objective of component-based architecture is to ensure component reusability. A component encapsulates
functionality and behaviors of a software element into a reusable and self-deployable binary unit. Component-oriented
software design has many advantages over the traditional object-oriented approaches su h as −

• Reduced time in market and the development cost by reusing existing components.
• Increased reliability with the reuse of the existing components.

43. Pri ciples of Co po e t−Based Desig

A component-level design can be represented by using some intermediary representation (e.g. graphical, tabular, or text-
based) that can be translated into source code. The design of data structures, interfaces, and algorithms should conform
to well-established guidelines to help us avoid the introduction of errors.

It has following salient features −

• The software system is decomposed into reusable, cohesive, and encapsulated component units.
• Each component has its own interface that specifies required ports and provided ports; each component hides
its detailed implementation.
• A component should be extended without the need to make internal code or design modifications to the
existing parts of the component.
• Depend on abstractions component do not depend on other concrete components, which increase difficulty in
expendability.
• Connectors connected components, specifying and ruling the interaction among components. The interaction
type is specified by the interfaces of the components.
• Components interaction can take the form of method invocations, asynchronous invocations, broadcasting,
message driven interactions, data stream communications, and other protocol specific interactions.
• For a server class, specialized interfaces should be created to serve major categories of clients. Only those
operations that are relevant to a particular category of clients should be specified in the interface.
• A component can extend to other components and still offer its own extension points. It is the concept of plug-
in based architecture. This allows a plug-in to offer another plug-in API.

Component-Level Design Guidelines

It creates naming conventions for components that are specified as part of the architectural model and then refines or
elaborates as part of the component-level model.

Page no: 10
 • Attains architectural component names from the problem domain and ensures that they have meaning to all
stakeholders who view the architectural model.
• Extracts the business process entities that can exist independently without any associated dependency on other
entities.
• Recognizes and discover these independent entities as new components.
• Uses infrastructure component names that reflect their implementation-specific meaning.
• Models any dependencies from left to right and inheritance from top (base class) to bottom (derived classes).
• Model any component dependencies as interfaces rather than representing them as a direct component-to-
component dependency.

DESIGN METRICS
In software development, a metric is the measurement of a particular characteristic of a program's performance or
efficiency. Design metric measure the efficiency of design aspect of the software. Design model considering three
aspects:
• Architectural design
• Object oriented design
• User interface design Architectural Design Metrics:
Architectural design metrics focus on characteristics of the program architecture with an emphasis on the architectural
structure and the effectiveness of modules. These metrics are black box in the sense that they do not require any
knowledge of the inner workings of a particular software component.

Object Oriented Design Metrics:

There are nine measurable characteristics of object oriented design and those are:
• Size: It can be measured using following factors:
• Population: means total number of classes and operations.
• Volume: means total number of classes or operation that is collected dynamically.
• Length: means total number of interconnected design elements.
• Functionality: is a measure of output delivered to the customer.
• Complexity: It is measured representing the characteristics that how the classes are interrelated with each
other.
• Coupling: It is a measure stating the collaboration between classes or number of messages that can be passed
between the objects.
• Completeness: It is a measure representing all the requirements of the design component.
• Cohesion: It is a degree by which we can identified the set of properties that are working together to solve
particular problem.
• Sufficiency: It is a measure representing the necessary requirements of the design component.
• Primitiveness: The degree by which the operations are simple, i.e. number of operations independent from
other.
• Similarity: the degree by which we measure that two or more classes are similar with respect to their
functionality and behavior.
• Volatility: Is the measure that represents the probability of changes that will occur.

User Interface Design Metrics:

Although there is significant literature on the design of human/computer interfaces, relatively little information has been
published on metrics that would provide insight into the quality and usability of the interface.

Page no: 11
 • Layout appropriateness (LA) is a worthwhile design metric for human/computer interfaces. A typical GUI uses
layout entities—graphic icons, text, menus, windows, and the like—to assist the user in completing tasks. To
accomplish a given task using a GUI, the user must move from one layout entity to the next.
• Cohesion metrics can be defined as the relative connection of on screen content to other screen contents. UI
cohesion for screen is high.

Page no: 12
 Unit-4
Syllabus: Backtracking concept and its e a ples like 8 uee s p o le , Ha ilto ia le, G aph coloring problem etc.
Introduction to branch & bound method, examples of branch and bound method like traveling salesman
problem etc. Meaning of lower bound theory and its use in solving algebraic problem, introduction to parallel
algorithms.

BACKTRACKING:
Backtracking is used to solve problem in which a sequence of objects is chosen from a specified set so that the
sequence satisfies some criterion. The desired solution is expressed as an n-tuple (x1, . . . . , xn) where each i Є
S, S being a finite set.

The solution is based on finding one or more vectors that maximize, minimize, or satisfy a criterion function P
(x1, . . . . . , xn). Form a solution and check at every step if this has any chance of success. If the solution at any
point seems not promising, ignore it. All solutions requires a set of constraints divided into two categories:
explicit and implicit constraints.

Terminology:
• Problem state is each node in the depth first search tree.
• Solution states a e the p o le states “ fo hi h the path f o the oot ode to “ defines a tuple in the
solution space.
• Answer states are those solution states for which the path from root node to s defines a tuple that is a
member of the set of solutions.
• State space is the set of paths from root node to other nodes. State space tree is the tree organization
of the solution space. The state space trees are called static trees. This terminology follows from the
observation that the tree organizations are independent of the problem instance being solved. For
some problems it is advantageous to use different tree organizations for different problem instance. In
this case the tree organization is determined dynamically as the solution space is being searched. Tree
organizations that are problem instance dependent are called dynamic trees.
• Live node is a node that has been generated but whose children have not yet been generated.
• E-node is a live node whose children are currently being explored. In other words, an E-node is a node
currently being expanded.
• Dead node is a generated node that is not to be expanded or explored any further. All children of a
dead node have already been expanded.
• Depth first node generation with bounding functions is called backtracking. State generation methods
in which the E-node remains the E-node until it is dead, lead to branch and bound methods.

N-QUEENS PROBLEM:
The N queens puzzle is the problem of placing N chess queens on an N×N chessboard so that no two queens
threaten each other. Thus, a solution requires that no two queens share the same row, column, or diagonal.

Let us consider, N = 8. Then 8-Queens Problem is to place eight queens on an 8 x 8 chessboard so that o t o atta
k , that is, o t o of the a e o the sa e o , olu , o diago al.

All solutions to the 8-queens problem can be represented as 8-tuples (x1. . . x8), where xi is the column
of the ith row where the ith queen is placed.

The promising function must check whether two queens are in the same column or diagonal:

Page no: 1
 Suppose two queens are placed at positions (i, j) and (k, l) Then:
• Column Conflicts: Two queens conflict if their xi values are identical.
• Diagonal conflict: Two queens i and j are on the same diagonal if: i – j = k – l. This
implies, j – l = i – k
• Diagonal conflict: i + j = k + l. This implies, j – l = k – i Algorithm:
1) Start in the leftmost column
2) If all queens are placed return true
3) Try all rows in the current column. Do following for every tried row.
a) If the queen can be placed safely in this row then mark this [row, column] as part of the
Solution and recursively check if placing queen here leads to a solution. b) If placing queen in
[row, column] leads to a solution then return true.
c) If placing queen doesn't lead to a solution then unmark this [row, column] (Backtrack) and go to
step (a) to try other rows.

4) If all rows have been tried and nothing worked, return false to trigger backtracking.

8-QUEENS PROBLEM:
The eight uee s problem is the problem of placing eight queens on an 8×8 chessboard such that none of them
attack one another (no two are in the same row, column, or diagonal).

Algorithm for new queen be placed All solutions to the n·queens problem
Algorithm Place(k,i) Algorithm NQueens(k, n)
//Return true if a queen can be placed in // its prints all possible placements of
kth row & ith column nqueens on an n×n chessboard.
//Other wise return false {
{ for i:=1 to n do{
for j:=1 to k-1 do if Place(k,i) then
if(x[j]=i or Abs(x[j]-i)=Abs(j-k))) {
then return false X[k]:=I; if(k==n) then write
return true (x[1:n]);
} else NQueens(k+1, n);
}
}}

Figure-4.1: 8-Queens Solution

Page no: 2
 HAMILTONIAN CYCLES:
Let G = (V, E) be a connected graph with n vertices. A Hamiltonian cycle (suggested by William Hamilton) is a
round-trip path along n edges of G that visits every vertex once and returns to its starting position.

In graph G, Hamiltonian cycle begins at some vertiex v1 G and the vertices of G are visited in the order
v1,v2,---vn+1, then the edges (vi, vi+1 a e i E, ≤ i ≤ .

Figure-4.2: Example of Hamiltonian cycle

The above graph contains Hamiltonian cycle: 1,2,8,7,6,5,4,3,1

Figure-4.3: Graph

The above graph contains no Hamiltonian cycles.

• There is no known easy way to determine whether a given graph contains a Hamiltonian cycle.  By
using backtracking method, it can be possible
• Backtracking algorithm, that finds all the Hamiltonian cycles in a graph.
• The graph may be directed or undirected. Only distinct cycles are output.  From graph g1 backtracking
solution vector= {1, 2, 8, 7, 6, 5, 4, 3, 1}
• The backtracking solution vector (x1, x2, --- xn)  xi ith visited vertex of proposed cycle.
• By using backtracking we need to determine how to compute the set of possible vertices for x k if
x1,x2,x3---xk-1 have already been chosen.
 If k=1 then x1 can be any of the n-vertices.

B usi g Ne tValue algo ith the e u si e a kt a ki g s he e to fi d all Ha iltoman cycles.

st
This algorithm is started by 1 initializing the adjacency matrix G[1:n, 1:n] then setting x[2:n] to zero & x[1] to 1,
and then executing Hamiltonian (2)

Generating Next Vertex Finding all Hamiltonian Cycles

Page no: 3
 Algorithm NextValue(k) Algorithm Hamiltonian(k)
{ {
// x[1: k-1] is path of k-1 distinct vertices. Repeat{
// if x[k]=0, then no vertex has yet been NextValue(k); //assign a legal next value
assigned to x[k] to x[k]
Repeat{ If(x[k]=0) then return;
X[k]=(x[k]+1) mod (n+1); //Next vertex If(k=n) then write(x[1:n]);
If(x[k]=0) then return; Else Hamiltonian(k+1);
If(G[x[k- ], [k]]≠ the } until(false)
{ }
For j:=1 to k-1 do if(x[j]=x[k]) then break;
//Check for distinctness
If(j=k) then //if true , then vertex is distinct
If k< o k= a d G[ [ ], [ ]]≠
Then return ;
}
}
Until (false);
}

Complexity Analysis
In Hamiltonian cycle, in each recursive call one of the remaining vertices is selected in the worst case. In each
recursive call the branch factor decreases by 1. Recursion in this case can be thought of as n nested loops
where in each loop the number of iterations decreases by one. Hence the time complexity is given by:

T(N)=N*(T(N-1)+O(1))
T(N) = N*(N-1)*(N-2).. = O(N!)

GRAPH COLORING :
Let G be a graph and m be a given positive integer. We want to discover whether the nodes of G can be colored
in such a way that no two adjacent nodes have the same color, yet only m colors are used. This is termed the m-
colorabiltiy decision problem. The m-colorability optimization problem asks for the smallest integer m for which
the graph G can be colored.

Note that, if d is the deg ee of the gi e g aph the it a e olo ed ith d+ olo s.
The m- olo a ilit opti izatio p o le asks fo the s allest i tege fo hi h the graph G can be olo ed. This i tege is efe ed
as Ch o ati u e of the g aph.

Example:

Page no: 4
 Figure-4.4: Graph Coloring Example

Algorithm:
Finding all m-coloring of a graph Getting next color
Algorithm mColoring(k){ Algorithm NextValue(k){
// g(1:n, 1:n):boolean adjacency matrix. //x[1],x[2],---x[k-1] have been assigned
// k index (node) of the next vertex to color. integer values in the range [1, m]
repeat{ nextvalue(k); // assign to x[k] a repeat {
legal color. x[k]=(x[k]+1)mod (m+1); //next highest
if(x[k]=0) then return; // no new color color if(x[k]=0) then return; // all colors have
possible been used. for
if(k=n) then write(x[1: n]; j=1 to n do
else mcoloring(k+1); [k]= [j]
} }
until(false) if(j=n+1) then return; //new color found
} } until(false)
}

Complexity Analysis
1) 2-colorability
There is a simple algorithm for determining whether a graph is 2-colorable and assigning colors to its vertices:
do a breadth-first search, assigning "red" to the first layer, "blue" to the second layer, "red" to the third layer,
etc. Then go over all the edges and check whether the two endpoints of this edge have different colors. This
algorithm is O(|V|+|E|) and the last step ensures its correctness.

2) k-colorability for k>2

For k > 2 however, the problem is much more difficult. For those interested in complexity theory, it can be
shown that deciding whether a given graph is k-colorable for k > 2 is an NP-complete problem. The first
algorithm that can be thought of is brute-force search: consider every possible assignment of k colors to the
vertices, and check whether any of them are correct. This of course is very expensive, on the order of
O((n+1)!), and impractical. Therefore we have to think of a better algorithm.

INTRODUCTION TO BRANCH & BOUND METHOD:

Page no: 5
 Branch and Bound is another method to systematically search a solution space. Just like backtracking, we will
use bounding functions to avoid generating subtrees that do not contain an answer node. However branch and
Bound differs from backtracking in two important manners:

• It has a branching function, which can be a depth first search, breadth first search or based on
bounding function.
• It has a bounding function, which goes far beyond the feasibility test as a mean to prune efficiently the
search tree.
• Branch and Bound refers to all state space search methods in which all children of the E-node are
generated before any other live node becomes the E-node
• Branch and Bound is the generalization of graph search strategies, BFS and D- search. o A BFS like state
space search is called as FIFO (First in first out) search as the list of live nodes in a first in first out list
(or queue). o A D search like state space search is called as LIFO (Last in first out) search as the list of
live nodes in a last in first out (or stack).

EXAMPLES OF BRANCH AND BOUND METHOD

There are lots of problem which can be solve using branch and bound methods. Like: 
Travelling Salesperson Problem

• 0/1 knapsack
• Quadratic assignment problem
• Nearest neighbor search

TRAVELLING SALESPERSON PROBLEM

Definition: Find a tour of minimum cost starting from a node S going through other nodes only once and
returning to the starting point S.

A tree of nodes is generated where each node has specified constraints regarding edges connecting two cities in
a tour that must be present and edges connecting two cities in a tour that cannot be present. Based on the
constraints in a given node, a lower bound is formulated for the given node. This lower bound represents the
smallest solution that would be possible if a sub-tree of nodes leading eventually to leaf nodes containing legal
tours were generated below the given node. If this lower bound is higher than the best known solution to-date,
the node may be pruned. This pruning has the effect of sparing result in a significant saving if the pruned node
were relatively near the top of the tree.

Let us explore the mechanism for computing lower bounds for a node. Example:

Now find the reduced matrix by:

• Subtracting the smallest element from row i(for example r1), so one element will become 0
and rest element remain non negative.
• Then after subtracting the smallest element from col j(for example c1), so one element will

Page no: 6
 become 0 and rest element remain non negative.
• “et ele e t A[I,j] = ∞
So the total reduced cost T= r1 + c1.

Hence the reduced matrix is:

• Subtracted 3 from row 1
• Subtracted 7 from row 2
• Subtracted 1 from row 3
• Subtracted 2 from row 4
• Subtracted 1 from col 2
• Subtracted 2 from col 3

We e a i e i i u ost fo ea h ode ,….,4 usi g the fo ula-l(B)=l(A) + M(i,j) + T Here:- l(b) is the cost of
new node, l(A) is the cost of previous node, and T is the reduced cost So the state space tree is given
as:

Figure-4.5: State Space Tree for TSP

Here the path is using above state space tree is: 1->4->2->3->1

Algorithm for TSP

function CheckBounds(st,des,cost[n][n])
Global variable: cost[N ][N ] - the cost assignment.
pencost[0] = t fo i ← , − do fo j ← , − do
reduced[i][j] = cost[i][j] end
for end for

Page no: 7
 fo j ← , − do edu
ed[st][j] = ∞ end for
fo i ← , − do edu
ed[i][des] = ∞
e d fo edu ed[des][st] = ∞ ‘o ‘edu tio reduced) C olumnReduction(reduced) pencost[des] =
pencost[st] + row + col + cost[st][des] return pencost[des] end function

function RowMin(cost[n][n],i)
min = cost[i][0] fo j ← , − do
if cost[i][j] < min then min = cost[i][j] end if end for
return min end function
function ColMin(cost[n][n],i) min = cost[0][j] fo i ← , − do
if cost[i][j] < min then min =
cost[i][j] end if end for
return min end function
function Rowreduction(cost[n][n])
row = 0 fo i ← , − do rmin =
rowmin(cost, i) if i /= ∞ the row = row
+ rmin end if
fo j ← , − do if ost[i]
[j] /= ∞ the
ost[i][j] = ost[i][j] − i
end if end for end for end function
function Columnreduction(cost[n][n]) col
=0
fo j ← , − do cmin =
columnmin(cost, j) if i /= ∞
then

col = col + cmin end if

fo i ← , − do if ost[i]
[j] /= ∞ the
ost[i][j] = ost[i][j] − i
end if end for end for
end function function
Main fo i ← ,
− do

Page no: 8
 select[i] = 0 end for rowreduction(cost) columnreduction(cost) t = row + col while
all isited sele t != do fo i ← , − do if select[i] = 0 then

edgecost[i] = checkbounds(k, i, cost) e

d if e d fo i = ∞ fo i ← , − do

if select[i] = 0 then if
edgecost[i] < min then
min = edgecost[i]
k = i end if
end if end
for select[k]
=1
fo p ← , − do ost[j]
[p] = ∞ end for fo p
← , − do ost[p][k]
=∞

e d fo ost[k][j] = ∞ o edu tio ost olu edu tio ost end while end function
Complexity Analysis:
Traveling salesman problem is a NP-hard problem. Until now, researchers have not found a polynomial time
algorithm for traveling salesman problem. Among the existing algorithms, dynamic programming algorithm can
solve the problem in time O(n^2*2^n) where n is the number of nodes in the graph. The branch-and-cut
algorithm has been applied to solve the problem with a large number of nodes. However, branch-and-cut
algorithm also has an exponential worst-case running time.

LOWER AND UPPER BOUND THEORY:

Lower bound is the best case running time. Lower bound is determined by the easiest input. It provides a goal
for all input. Whereas upper bound is the worst case and is determined by the most difficult input for a given
algorithm. Upper bounds provide guarantees for all inputs i.e. Guarantees on performance of the algorithm
when run on different inputs will not perform any worse than over the most difficult input.

There are a number of lower bounds for problems related to sorting, for example elementdistinctness: are
there two identical elements in a set? These lower bounds are actually interesting because they generalize the
comparison-lower bound to more algebraic formulations: for example, you can show that solving element
distinctness in a model that allows algebraic operations has a lower bound via analyzing the betti numbers of
the space induced by different answers to the problem.

A very interesting example of an unconditional exponential deterministic lower bound (i.e not related to P vs
NP) is for estimating the volume of a polytope. There is a construction due to Furedi and Barany that shows
that the volume of a convex polytope cannot be approximated to within an even exponential factor in
polynomial time unconditionally. This is striking because there are randomized poly-time algorithms that yield
arbitrarily good approximations.

Page no: 9
 • Lower Bound, L(n), is a property of the specific problem, i.e. sorting problem, MST, matrix multiplication, not
of any particular algorithm solving that problem.
• Lo e ound theory says that no algorithm can do the job in fewer than L(n) time units for arbitrary inputs, i.e.,
that every comparison-based sorting algorithm must take at least L(n) time in the worst case.
• L is the i i u o e all possi le algo ith s, of the maximum complexity.
• Upper bound theory says that for any arbitrary inputs, we can always sort in time at most U(n). How long it
would take to solve a problem using one of the known Algorithms with worst-case input gives us a upper
bound.
• I p o i g an upper bound means finding an algorithm with better worst-case performance.
• U is the i i u o e all k o algo iths, of the ai u o ple it .
• Both uppe a d lo e ou ds a e ii a o e the ai u o ple it of i puts of size .
• The ultimate goal is to make these two functions coincide. When this is done, the optimal algorithm will have
L(n) = U(n).

There are few techniques for finding lower bounds

1) Trivial Lower Bounds:

For many problems it is possible to easily observe that a lower bound identical to n exists, where n is the
number of inputs (or possibly outputs) to the problem.

• The ethod o sists of si pl ou ti g the u e of i puts that ust e e a i ed a d the number of outputs that must be
produced, and note that any algorithm must, at least, read its inputs and write its outputs.

2) Information Theory:
The information theory method establishing lower bounds by computing the limitations on information gained
by a basic operation and then showing how much information is required before a given problem is solved.

• This is used to sho that a possi le algo ith fo sol i g a p o le ust do so e i i al amount of work.
• The ost useful p i iple of this ki d is that the out o e of a o pa iso et ee t o ite s contains one bit of
information.

3) Decision Tree Model

• This ethod a odel the e e utio of a o pa iso ased p o le . O e t ee fo ea h i put size n.
• Vie the algo ith as splitti g he e e it o pa es t o ele e ts.
• The t ee o tai s the comparisons along all possible instruction traces.
• The u i g ti e of the algo ith = the le gth of the path take .
• Wo st-case running time = the height of tree.

PARALLEL ALGORITHM:
A parallel algorithm can be executed simultaneously on many different processing devices and then combined
together to get the correct result. Parallel algorithms are highly useful in processing huge volumes of data in
quick time. This tutorial provides an introduction to the design and analysis of parallel algorithms. In addition,
it explains the models followed in parallel algorithms, their structures, and implementation.

Page no: 10
 An algorithm is a sequence of steps that take inputs from the user and after some computation, produces an
output. A parallel algorithm is an algorithm that can execute several instructions simultaneously on different
processing devices and then combine all the individual outputs to produce the final result.

Concurrent Processing
The easy availability of computers along with the growth of Internet has changed the way we store and process
data. We are living in a day and age where data is available in abundance. Every day we deal with huge
volumes of data that require complex computing and that too, in quick time. Sometimes, we need to fetch data
from similar or interrelated events that occur simultaneously. This is where we require concurrent processing
that can divide a complex task and process it multiple systems to produce the output in quick time.

Concurrent processing is essential where the task involves processing a huge bulk of complex data. E a ples i
lude − a essi g la ge data ases, ai aft testi g, ast o o i al al ulatio s, ato i a d nuclear physics, biomedical analysis,
economic planning, image processing, robotics, weather forecasting, web-based services, etc.

Parallelism is the process of processing several set of instructions simultaneously. It reduces the total
computational time. Parallelism can be implemented by using parallel computers, i.e. a computer with many
processors. Parallel computers require parallel algorithm, programming languages, compilers and operating
system that support multitasking.

Page no: 11
 UNIT-IV
SOFTWARE STATIC AND DYNAMIC ANALYSIS:
Static Analysis:
Static analysis involves no dynamic execution of the software under test and can detect possible defects in an early stage,
before running the program.

Static analysis is done after coding and before executing unit tests.

Static analysis can be done by a machine to automatically alk th ough the sou e ode a d dete t o complying rules. The
classic example is a compiler which finds lexical, syntactic and even some semantic mistakes.

Static analysis can also be performed by a person who would review the code to ensure proper coding standards and
conventions are used to construct the program. Static code analysis advantages:
• It can find weaknesses in the code at the exact location.
• It can be conducted by trained software assurance developers who fully understand the code.
• Source code can be easily understood by other or future developers
• It allows a quicker turn around for fixes
• Weaknesses are found earlier in the development life cycle, reducing the cost to fix.  Less defects in later
tests
• Unique defects are detected that cannot or hardly be detected using dynamic tests o Unreachable code
o Variable use (undeclared, unused) o
Uncalled functions o Boundary value violations
Static code analysis limitations:
• It is time consuming if conducted manually.
• Automated tools produce false positives and false negatives.
• There are not enough trained personnel to thoroughly conduct static code analysis.
• Automated tools can provide a false sense of security that everything is being addressed.
• Automated tools only as good as the rules they are using to scan with.
• It does not find vulnerabilities introduced in the runtime environment.

Dynamic Analysis:
Dynamic analysis is based on the system execution, often using tools.

Dynamic program analysis is the analysis of computer software that is performed with executing programs built from
that software on a real or virtual processor (analysis performed without executing programs is known as static code
analysis). Dynamic program analysis tools may require loading of special libraries or even recompilation of program code.

The most common dynamic analysis practice is executing Unit Tests against the code to find any errors in code. Dynamic
code analysis advantages:
• It identifies vulnerabilities in a runtime environment.
• It allows for analysis of applications in which you do not have access to the actual code.
• It identifies vulnerabilities that might have been false negatives in the static code analysis.  It permits you
to validate static code analysis findings.
• It can be conducted against any application. Dynamic code analysis limitations:
• Automated tools provide a false sense of security that everything is being addressed.
• Cannot guarantee the full test coverage of the source code
• Automated tools produce false positives and false negatives.
• Automated tools are only as good as the rules they are using to scan with.

Page no: 1
 • It is more difficult to trace the vulnerability back to the exact location in the code, taking longer to fix the
problem.

CODE INSPECTIONS:
Code Inspection is the most formal type of review, which is a kind of static testing to avoid the defect multiplication at a
later stage.
The main purpose of code inspection is to find defects and it can also spot any process improvement if any.
•
An inspection report lists the findings, which include metrics that can be used to aid improvements to the
•
process as well as correcting defects in the document under review.
• Preparation before the meeting is essential, which includes reading of any source documents to ensure
consistency.
• Inspections are often led by a trained moderator, who is not the author of the code.
• The inspection process is the most formal type of review based on rules and checklists and makes use of entry
and exit criteria.
• It usually involves peer examination of the code and each one has a defined set of roles.
• After the meeting, a formal follow-up process is used to ensure that corrective action is completed in a timely
manner.
SOFTWARE TESTING FUNDAMENTALS:
Software testing is an activity performed to uncover errors. It is a critical element of software quality assurance and
represents the ultimate review of specification, design and coding. The purpose of software testing is to ensure whether
the software functions appear to be working according to specification and performance requirements.
Testing objective:
• Testing is a process of executing a program with the intend of finding an error.
• A good test case is one that has high probability of finding an undiscovered error.
• A successful test is one that uncovers an as yet undiscovered error.
Testing principles:
The following basic principles and fundamentals are general guidelines applicable for all types of real-time testing:

• Testing proves the presence of defects. It is generally considered better when a test reveals defects than when it
is error-free.
• Testing the product should be accomplished considering the risk factor and priorities
• Early testing helps identify issues prior to the development stage, which eases error correction and helps reduce
cost
• Normally a defect is clustered around a set of modules or functionalities. Once they are identified, testing can be
focused on the defective areas, and yet continue to find defects in other modules simultaneously.
• Testing will not be as effective and efficient if the same kinds of tests are performed over a long duration.
• Testing has to be performed in different ways, and cannot be tested in a similar way for all modules. All testers
have their own individuality, likewise the system under test.
• Just identifying and fixing issues does not really help in setting user expectations. Even if testing is performed to
showcase the software's reliability, it is better to assume that none of the software products are bug-free.
SOFTWARE TEST PROCESS:
Testing is a process rather than a single activity. This process starts from test planning then designing test cases,
preparing for execution and evaluating status till the test closure. So, we can divide the activities within the fundamental
test process into the following basic steps:
• Planning and Control
• Analysis and Design
• Implementation and Execution

Page no: 2
  Evaluating exit criteria and Reporting
 Test Closure activities

Test cases Test data Test results

Test case Prepare test Test execution Compare

design data results

Test reports
figure 4.1: Testing Process

TETSING LEVELS: -
The testing can be typically carried out in levels. In software development process at each phase some faults may get
introduced. These faults are eliminated in the next software development phase but at the same time some new faults
may get introduced. Each level of testing performs some typical activity. Levels of testing include different methodologies
that can be used while conducting software testing. The main levels of software testing are:

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
Unit Testing: In this type of testing errors are detected from each software component individually.

Integration Testing: In this type of testing technique interacting component are verified and the interface errors are
detected.

System Testing: In this type of testing all the system elements forming the system is tested as a whole.

Acceptance Testing: Acceptance testing is a kind of testing conducted to ensure that the software works o e tl i use s o ki
g e i o e t.

Acceptance Testing Client Needs

System Testing Requirements

Integration Testing Design

Unit Testing Coding

Figure 4.2: Levels of Testing

TEST CRITERIA AND TEST CASE DESIGN:
• Test cases are used to determine the presence of fault in the program.
• Executing test cases require money because- 1)machine time is required to execute test cases

Page no: 3
 2) Human efforts are involved in executing test case. Hence in the project testing minimum number of test vases
should be there as far as possible.

• The testing activity should involve two goals-1) Maximize the number of errors detected. 2) Minimize the
number of test cases.
• The selection of test case should be such that faulty module or program segment must be exercised by at least
one test case.
• Test selection criterion can be defined as the set of conditions that must be satisfied by the set of test cases.
• Testing criterion is based on two fundamental properties – reliability and validity.
• A test criterion is reliable if all the test cases detect same set of errors.
• A test criterion is valid if, for any error in the program there is some test case which causes error in the program.
• Generating test cases to satisfy criteria is complex task.

TEST ORACLES:
Test Oracles is a mechanism for determining whether a test has passed or failed. The use of oracles involves comparing
the output(s) of the system under test, for a given test-case input, to the output(s) that the oracle determines that
product should have. Suppose we have written 2 test cases one test case is for the program which we want to test and
other for the test oracle. If the output of both is the same then that means program behaves correctly otherwise there is
some fault in the program.

Test case
Program under testing

Output

Test oracle
Test case

Figure 4.3: Testing with test oracle TEST

TECHNIQUES:

There are various testing techniques are available in which internal structure/design/implementation of the item being
tested. There are different methods that can be used for software testing.
• Black box testing
• White box testing
• Integration testing
• Unit testing
• System testing

BLACK BOX TESTING:

Black box testing is also called as behavioral testing. Black-box testing is a method of software testing that examines the
functionality of an application based on the specifications. It is also known as Specifications based testing. Independent
Testing Team usually performs this type of testing during the software testing life cycle. This method of test can be
applied to each and every level of software testing such as unit, integration, system and acceptance testing.
Black box testing uncovers following types of errors:

Page no: 4
 • Incorrect or missing functions
• Interface errors
• Errors in data structures
• Performance errors
• Initialization or termination errors
There are different techniques involved in Black Box testing.

• Equivalence partitioning  Boundary Value Analysis  Cause-Effect Graphing.  Error-Guessing.

Advantages Disadvantages
 Well suited and efficient for large code
 segments. • Limited coverage, since only a selected number
 Code access is not required. of test scenarios is actually performed.
Clearly separates user's perspective from the • Inefficient testing, due to the fact that the
developer's perspective through visibly defined tester only has limited knowledge about an

roles. application.
Large numbers of moderately skilled testers • Blind coverage, since the tester cannot target
can test the application with no knowledge of specific code segments or error-prone areas.
implementation, programming language, The test
or cases are difficult to design.
operating systems.

WHITE BOX TESTING:

White-box testing is the detailed investigation of internal logic and structure of the code. White-box testing is also called
glass testing or open-box testing. In order to perform white-box testing on an application, a tester needs to know the
internal workings of the code.
The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving
inappropriately.
White box testing techniques includes:
• Statement Coverage - This technique is aimed at exercising all programming statements with minimal tests.
• Branch Coverage - This technique is running a series of tests to ensure that all branches are tested at least once.
• Path Coverage - This technique corresponds to testing all possible paths which means that each statement and
branch is covered.

Advantages Disadvantages

 As the tester has knowledge of the source  Due to the fact that a skilled tester is needed to
code, it becomes very easy to find out which perform white-box testing, the costs are
type of data can help in testing the application increased.
effectively.  Sometimes it is impossible to look into every
 It helps in optimizing the code. nook and corner to find out hidden errors that
 Extra lines of code can be removed which can may create problems, as many paths will go
bring in hidden defects. untested.
 Due to the tester's knowledge about the code, It is difficult to maintain white-box testing, as it
maximum coverage is attained during test requires specialized tools like code analyzers
scenario writing. and debugging tools.


Page no: 5
 UNIT TESTING:
Unit testing, a testing technique using which individual modules are tested to determine if there are any issues by the
developer himself. It is concerned with functional correctness of the standalone modules.

The main aim is to isolate each unit of the system to identify, analyze and fix the defects.

Advantages:
• Reduces Defects in the newly developed features or reduces bugs when changing the existing functionality.
• Reduces Cost of Testing as defects are captured in very early phase.
• Improves design and allows better refactoring of code.
• Unit Tests, when integrated with build gives the quality of the build as well.

Module Interface
Local data structures
Boundary conditions
Independent paths
Error handling paths

Test Cases

Figure 4.4: Unit Testing

Unit Testing Techniques:
• Black Box Testing - Using which the user interface, input and output are tested.
• White Box Testing - used to test each one of those functions behavior is tested.  Gray Box
Testing - Used to execute tests, risks and assessment methods.

TESTING FRAMEWORKS:
Testing frameworks are an essential part of any successful automated testing process. They can reduce maintenance
costs and testing efforts and will provide a higher return on investment (ROI) for QA teams looking to optimize their agile
processes.

A testing framework is a set of guidelines or rules used for creating and designing test cases. A framework is comprised
of a combination of practices and tools that are designed to help QA professionals test more efficiently.

INTEGRATION TESTING:
In integration testing, individual software modules are integrated logically and tested as a group. A typical software
project consists of multiple software modules, coded by different programmers. Integration Testing focuses on checking
data communication amongst these modules.
Need of integration testing:
Although each software module is unit tested, defects still exist for various reasons like:

Page no: 6
 • A Module in general is designed by an individual software developer whose understanding and programming
logic may differ from other programmers. integration Testing becomes necessary to verify the software modules
work in unity
• At the time of module development, there are wide chances of change in requirements by the clients. These new
requirements may not be unit tested and hence system integration Testing becomes necessary.
• Interfaces of the software modules with the database could be erroneous  External Hardware interfaces, if any,
could be erroneous  Inadequate exception handling could cause issues.

Integration testing approach

Integration testing approach Integration testing approach

Top down testing

Big bang
Bottom up integration

Regression testing

Smoke testing

Figure 4.5: Integration testing approach

Bottom-up integration:
This testing begins with unit testing, followed by tests of progressively higher-level combinations of units called modules
or builds. Top-down integration:

In this testing, the highest-level modules are tested first and progressively, lower-level modules are tested thereafter.

In a comprehensive software development environment, bottom-up testing is usually done first, followed by top-down
testing. The process concludes with multiple tests of the complete application, preferably in scenarios designed to mimic
actual situations.

Regression Testing:
Regression testing is used to check for defects propagated to other modules by changes made to existing program. Thus
regression testing is used to reduce the side effects of the changes.

Smoke Testing:
Smoke testing is a type of software testing which ensures that the major functionalities of the application are o ki g fi e.
This testi g is also k o as Build Ve ifi atio testi g . It is a o -exhaustive testing with very

limited test cases to ensure that the important features are working fine and we are good to proceed with the detailed
testing.

SYSTEM TESTING:

Page no: 7
 System testing tests the system as a whole. Once all the components are integrated, the application as a whole is tested
rigorously to see that it meets the specified Quality Standards. This type of testing is performed by a specialized testing
team.
System testing is important because of the following reasons:

• System testing is the first step in the Software Development Life Cycle, where the application is tested as a whole.
• The application is tested thoroughly to verify that it meets the functional and technical specifications.
• The application is tested in an environment that is very close to the production environment where the
application will be deployed.
• System testing enables us to test, verify, and validate both the business requirements as well as the application
architecture.

OTHER SPECIALIZED TESTING:

There are lots of testing types. Below we have listed types of system testing a large software development company
would typically use:

Usability Testing: Usability Testing mainly focuses on the user's ease to use the application, flexibility in handling controls
and ability of the system to meet its objectives

Load Testing: Load Testing is necessary to know that a software solution will perform under real-life loads.

Regression Testing: Regression Testing involves testing done to make sure none of the changes made over the course of
the development process have caused new bugs. It also makes sure no old bugs appear from the addition of new
software modules over time.

Recovery Testing: Recovery testing is done to demonstrate a software solution is reliable, trustworthy and can
successfully recoup from possible crashes.

Migration Testing: Migration testing is done to ensure that the software can be moved from older system infrastructures
to current system infrastructures without any issues.

Functional Testing: Also known as functional completeness testing, Functional Testing involves trying to think of any
possible missing functions. Testers might make a list of additional functionalities that a product could have to improve it
during functional testing.

Hardware/Software Testing: IBM refers to Hardware/Software testing as "HW/SW Testing". This is when the tester
focuses his/her attention on the interactions between the hardware and software during system testing. Acceptance
Testing: The acceptance testing is a kind of testing to ensure that the software works correctly in the user work
environment. Acceptance testing, a testing technique performed to determine whether or not the software system has
met the requirement specifications. The main purpose of this test is to evaluate the system's compliance with the
business requirements and verify if it is has met the required criteria for delivery to end users.
There are various forms of acceptance testing:

• User acceptance Testing

• Business acceptance Testing
• Alpha Testing
• Beta Testing

Stress Testing: Stress testing is the process of determining the ability of a computer, network, program or device to
maintain a certain level of effectiveness under unfavorable conditions. It is used to test the stability & reliability of the
system. This test mainly determines the system on its robustness and error handling under extremely heavy load
conditions.

Page no: 8
 TEST PLAN:
Test planning, the most important activity to ensure that there is initially a list of tasks and milestones in a baseline plan
to track the progress of the project. It also defines the size of the test effort. It is the main document often called as
master test plan or a project test plan and usually developed during the early phase of the project.

S.No. Parameter Description

1. Test plan identifier Unique identifying reference.
2. Introduction A brief introduction about the project and to
the document.
3. Test items A test item is a software item that is the
application under test.
4. Features to be tested A feature that needs to tested on the test
ware.
5. Features not to be tested Identify the features and the reasons for not
including as part of testing.
6. Approach Details about the overall approach to
testing.
7. Item pass/fail criteria Documented whether a software item has
passed or failed its test.
8. Test deliverables The deliverables that are delivered as part of
the testing process, such as test plans, test
specifications and test summary reports.
9. Testing tasks All tasks for planning and executing the
testing.
10. Environmental needs Defining the environmental requirements
such as hardware, software, OS, network
configurations, tools required.
11. Responsibilities Lists the roles and responsibilities of the
team members.
12. Staffing and training needs Captures the actual staffing requirements
and any specific skills and training
requirements.
13. Schedule States the important project delivery dates
and key milestones.
14. Risks and Mitigation High-level project risks and assumptions and
a mitigating plan for each identified risk.
15. Approvals Captures all approvers of the document,
their titles and the sign off date.

Table 4.1 Test Plan Identifiers Test Planning Activities:

• To determine the scope and the risks that need to be tested and that are NOT to be tested.
• Documenting Test Strategy.
• Making sure that the testing activities have been included.

Page no: 9
 • Deciding Entry and Exit criteria.
• Evaluating the test estimate.
• Planning when and how to test and deciding how the test results will be evaluated, and defining test exit
criterion.
• The Test art facts delivered as part of test execution.
• Defining the management information, including the metrics required and defect resolution and risk issues.
• Ensuring that the test documentation generates repeatable test assets.

TEST METRICS:
In software testing, Metric is a quantitative measure of the degree to which a system, system component, or process
possesses a given attribute. Measurement is nothing but quantitative indication of size / dimension / capacity of an
attribute of a product / process. Software metric is defined as a quantitative measure of an attribute a software system
possesses with respect to Cost, Quality, Size and Schedule. Example-

Measure - No. of Errors

Metrics - No. of Errors found per person

The most commonly used metric is cyclomatic complexity and Hallstead complexity.

Cyclomatic complexity: Cyclomatic complexity is software metric used to measure the complexity of a program. These
metric, measures independent paths through program source code. Independent path is defined as a path that has at
least one edge which has not been traversed before in any other paths. Cyclomatic complexity can be calculated with
respect to functions, modules, methods or classes within a program.

In the graph, Nodes represent processing tasks while edges represent control flow between the nodes.

Nodes

edges

Figure 4.6: Nodes representation

Mathematically, it is set of independent paths through the graph diagram. The complexity of the program can be defined
as -

Where,

E - Number of edges

N - Number of Nodes

44. (G) = P + 1
Where P = Number of predicate nodes (node that contains condition)

Halstead complexity: Halstead complexity measurement was developed to measure a program module's complexity
directly from source code, with emphasis on computational complexity.

Page no: 10
 The Halstead effort can be defined as: e= V/PL

Where V is the program volume and Pl is the program level. The program level can be computed as:
PL=1/[(n1/2)*(N2/n2)]

Where n1 is total distinct operators, N2

is total distinct operands and N2 is all
the operand in the program.
The % of overall testing efforts = testing effort of specific module/testing efforts of all the modules

TESTING TOOLS:
Tools from a software testing context can be defined as a product that supports one or more test activities right from
planning, requirements, creating a build, test execution, defect logging and test analysis.

Classification of Tools
Tools can be classified based on several parameters. They include:

• The purpose of the tool

• The Activities that are supported within the tool
• The Type/level of testing it supports
• The Kind of licensing (open source, free ware, commercial) The technology used
S. No. Tool Type Used for Used by
Test Managing, scheduling, defect
1. Test Management Tool testers
logging, tracking and analysis.
Configuration For Implementation, execution,
2. All Team members
management tool tracking changes
3. Static Analysis Tools Static Testing Developers
Test data Preparation Analysis and Design,
4. Testers
Tools Test data generation
5. Test Execution Tools Implementation, Execution Testers
Comparing expected and
6. Test Comparators All Team members
actual results
Cover age measurement
7. Provides structural coverage Developers
tools
Monitoring the performance,
8. Performance Testing tools Testers
response time
Project planning and
9. For Planning Project Managers
Tracking Tools
Incident Management
10. Tools For managing the tests Testers
Table 4.2: Testing tool

Tools Implementation - process

Page no: 11
 • Analyze the problem carefully to identify strengths, weaknesses and opportunities.
• The Constraints such as budgets, time and other requirements are noted.
• Evaluating the options and Short listing the ones that are meets the requirement.
• Developing the Proof of Concept which captures the pros and cons.
• Create a Pilot Project using the selected tool within a specified team.
• Rolling out the tool phase wise across the organization.

INTRODUCTION TO OBJECT-ORIENTED ANALYSIS AND DESIGN:

Object-oriented analysis and design (OOAD) is a popular technical approach to analyzing, designing an application,
system, or business by applying the object-oriented paradigm and visual modeling throughout the development life
cycles for better stakeholder communication and product quality.

Object-Oriented Analysis:
Object–Oriented Analysis (OOA) is the procedure of identifying software engineering requirements and de elopi g soft a
e spe ifi atio s i te s of a soft a e s ste s o je t odel, hi h o p ises of interacting objects.

The primary tasks in object-o ie ted a al sis OOA a e −

• Identifying objects
• Organizing the objects by creating object model diagram  Defining the internals of the objects, or object
attributes
• Defining the behavior of the objects, i.e., object actions
• Describing how the objects interact
The common models used in OOA are use cases and object models.

Object-Oriented Design:
Object–Oriented Design (OOD) involves implementation of the conceptual model produced during objectoriented
analysis. In OOD, concepts in the a al sis odel, hi h a e te h olog −i depe de t, a e apped onto implementing classes,
constraints are identified and interfaces are designed, resulting in a model for the solution domain.

The i ple e tatio details ge e all i lude −

• Restructuring the class data (if necessary),
• Implementation of methods, i.e., internal data structures and algorithms,
• Implementation of control, and  Implementation of associations.

COMPARISON WITH STRUCTURED SOFTWARE ENGINEERING:

Key differences between structured and object oriented analysis and design are as follows:

Page no: 12
 Phase Structured Object Oriented
Analysis Structuring Requirements Requirement Engineering
• DFD s • Use Case Model(Find use
• Structured English cases, flow of events)
• Decision Table/Tree  • Object Model
ER Analysis – Find classes and class
relationship
– Object interaction:
Sequence and
collaboration diagram
,state machine
diagram
– Object to ER mapping
Design DB Design Physical DB design
• DB normalization Design elements
GUI Design • Design system architecture
• Forms and reports • Design classes
• Design components GUI
Design
Table 4.3: comparison table between structured and object oriented

Page no: 13
 Unit-5
Syllabus: Binary search trees, height balanced trees, 2-3 trees, B-trees, basic search and traversal
techniques for trees and graphs (In order, preorder, postorder, DFS, BFS), NP-completeness.

BINARY SEARCH TREES:

In a binary tree, every node can have maximum of two children but there is no order of nodes based on
their values. In binary tree, the elements are arranged as they arrive to the tree, from top to bottom
and left to right. To enhance the performance of binary tree, we use special type of binary tree known
as Binary Search Tree.
Binary search tree mainly focus on the search operation in binary tree. Binary search tree can be
defined as follows:-
Binary Search Tree is a binary tree in which every node contains only smaller values in its left subtree
and only larger values in its right subtree.

Example

The following tree is a Binary Search Tree. In this tree, left subtree of every node contains nodes with
smaller values and right subtree of every node contains larger values.

Figure 5.1 Binary Search Tree

The following operations are performed on a binary search tree:-1) Search 2) Insertion 3) Deletion

45. Search Operation in BST

In a binary search tree, the search operation is performed with O(log n) time complexity. The search
operation is performed as follows:-

 Step 1: Read the search element from the user

 Step 2: Compare, the search element with the value of root node in the tree.
 Step 3: If both are matching, then display "Given node found!!!" and terminate the function
 Step 4: If both are not matching, then check whether search element is smaller or larger than that node
value.
 Step 5: If search element is smaller, then continue the search process in left subtree.  Step 6: If search
element is larger, then continue the search process in right subtree.
 Step 7: Repeat the same until we found exact element or we completed with a leaf node

Page no: 1
  Step 8: If we reach to the node with search value, then display "Element is found" and terminate the
function.
 Step 9: If we reach to a leaf node and it is also not matching, then display "Element not found" and
terminate the function.

46. Insertion Operation in BST

In a binary search tree, the insertion operation is performed with O(log n) time complexity. In binary
search tree, new node is always inserted as a leaf node. The insertion operation is performed as follows:-
Step 1: Create a newNode with given value and set its left and right to NULL.
Step 2: Check whether tree is Empty.
Step 3: If the tree is Empty, then set set root to newNode.
Step 4: If the tree is Not Empty, then check whether value of newNode is smaller or larger than the
node (here it is root node).
Step 5: If newNode is smaller than or equal to the node, then move to its left child. If newNode is larger
than the node, then move to its right child.
Step 6: Repeat the above step until we reach to a leaf node (e.i., reach to NULL).
Step 7: After reaching a leaf node, then isert the newNode as left child if newNode is smaller or equal to
that leaf else insert it as right child.

47. Deletion Operation in BST

In a binary search tree, the deletion operation is performed with O(log n) time complexity. Deleting a
node from Binary search tree has following three cases:-

48. Case 1: Deleting a leaf node We use the following steps to delete a leaf node from BST:-
Step 1: Find the node to be deleted using search operation
Step 2: Delete the node using free function (If it is a leaf) and terminate the function.

49. Case 2: Deleting a node with one child We use the following steps to delete a node with one child
from BST:-
Step 1: Find the node to be deleted using search operation
Step 2: If it has only one child, then create a link between its parent and child
nodes. Step 3: Delete the node using free function and terminate the
function.

50. Case 3: Deleting a node with two children We use the following steps to delete a node with two
children from BST:- Step 1: Find the node to be deleted using search operation
Step 2: If it has two children, then find the largest node in its left subtree (OR) the smallest node in its
right subtree.
Step 3: Swap both deleting node and node which found in above step. Step 4:
Then, check whether deleting node came to case 1 or case 2 else goto steps 2
Step 5: If it comes to case 1, then delete using case 1 logic.
Step 6: If it comes to case 2, then delete using case 2 logic.
Step 7: Repeat the same process until node is deleted from the tree.
51. Binary Search Tree – Traversal
There are three types of binary search tree traversals.
1. In - Order Traversal

Page no: 2
 2. Pre - Order Traversal
3. Post - Order Traversal

Figure 5.2 Binary Search Tree

52. 1. In - Order Traversal ( leftChild - root - rightChild )

In In-Order traversal, the root node is visited between left child and right child. In this traversal, the
left child node is visited first, then the root node is visited and later we go for visiting right child node.
This in-order traversal is applicable for every root node of all subtrees in the tree. This is performed
recursively for all nodes in the tree.
53. Algorithm Inorder(tree)
1. Traverse the left subtree, i.e., call Inorder(left-subtree)
2. Visit the root.
3. Traverse the right subtree, i.e., call Inorder(right-subtree) Example: Inorder traversal for
the above-given figure is 4 2 5 1 3.

54. 2. Pre - Order Traversal ( root - leftChild - rightChild )

In Pre-Order traversal, the root node is visited before left child and right child nodes. In this traversal,
the root node is visited first, then its left child and later its right child. This pre-order traversal is
applicable for every root node of all subtrees in the tree. Algorithm Preorder(tree)
1. Visit the root.
2. Traverse the left subtree, i.e., call Preorder(left-subtree)
3. Traverse the right subtree, i.e., call Preorder(right-subtree) Example: Preorder traversal for the
above given figure is 1 2 4 5 3.

55. 3. Post - Order Traversal ( leftChild - rightChild - root )

In Post-Order traversal, the root node is visited after left child and right child. In this traversal, left
child node is visited first, then its right child and then its root node. This is recursively performed
until the right most node is visited.
56. Algorithm Postorder(tree)
1. Traverse the left subtree, i.e., call Postorder(left-subtree)
2. Traverse the right subtree, i.e., call Postorder(right-subtree)
3. Visit the root.
Example: Postorder traversal for the above given figure is 4 5 2 3 1.

HEIGHT BALANCED TREES:

AVL tree is a self-balancing Binary Search Tree (BST) where the difference between heights of left and
right subtrees cannot be more than one for all nodes.Most of the BST operations (e.g., search, max,

Page no: 3
 min, insert, delete.. etc) take O(h) time where h is the height of the BST. The cost of these operations
may become O(n) for a skewed Binary tree. If we make sure that height of the tree remains O(Logn)
after every insertion and deletion, then we can guarantee an upper bound of O(Logn) for all these
operations. The height of an AVL tree is always O(Logn) where n is the number of nodes in the tree.

An AVL tree is a balanced binary search tree. In an AVL tree, balance factor of every node is either -1, 0
or +1.

57. Balance factor = heightOfLeftSubtree – heightOfRightSubtree

AVL Tree Rotations: Rotation is the process of moving the nodes to either left or right to make tree
balanced.

There are four rotations and they are classified into two types.

58. 1) Single Rotation

• Left rotation
• Right rotation
2)Double Rotation
• Left-Right rotation
• Right-Left rotation

INSERTION AND DELETION IN AVL TREE:

So time complexity of AVL insert is O(Logn). The AVL tree and other self balancing search trees like Red
Black are useful to get all basic operations done in O(Log n) time. The AVL trees are more balanced
compared to Red Black Trees, but they may cause more rotations during insertion and deletion.

Insertion Operation:
1. Insert the new Node using recursion so while back tracking you will all the parents nodes to check
whether they are still balanced or not.
2. Every node has a field called height with default value as 1.
3. Whe e ode is added, its pare t s ode height get i reased y 1.
4. So as mentioned in step 1, every ancestors height will get updated while back tracking to the root.
5. At every node the balance factor will also be checked. balance factor = (height of left Subtree — height
of right Subtree).
6. If balance factor =1 means tree is balanced at that node.
7. If balance factor >1 means tree is not balanced at that node, left height is more that the right height so
that means we need rotation. (Either Left-Left Case or Left-Right Case).
8. Say the current node which we are checking is X and If new node is less than the X.left then it will be
Left-Left case, and if new node is greater than the X.left then it will be Left-Right case. see the pictures
above.
9. If balance factor <-1 means tree is not balanced at that node, right height is more that the left height so
that means we need rotation. (Either Right-Right Case or Right– Left Case)
10. Say the current node which we are checking is X and If new node is less than the X.right then it will be
Right-Right case, and if new node is greater than the X.right then it will be Right-Left case.

Page no: 4
 Examples:

An important example of AVL trees is the behavior on a worst-case add sequence for regular binary trees:

1, 2, 3, 4, 5, 6, 7
All insertions are right-right and so rotations are all single rotate from the right. All but two insertions require re-
balancing:

Figure:5.3 AVL Tree Insertion

Deletion in AVL Tree: If we want to delete any element from the AVL Tree we can delete same as BST
deletion. for example Delete 30 in the AVL tree from the figure Figure:5.4 .

Page no: 5
 Figure:5.4 AVL Tree

Figure:5.5 AVL Tree Deletion

A node with value 30 is being deleted in figure 5.5. After deleting 30, we travel up and find the first
unbalanced node which is 18. We apply rotation and shift 18 to up for balanced tree .Again we have to
move 18 up, so we perform left rotation.

2-3 TREES:
A 2-3 Tree is a specific form of a B tree. A 2-3 tree is a search tree. However, it is very different from a binary
search tree.
Here are the properties of a 2-3 tree:

• each node has either one value or two value

• a node with one value is either a leaf node or has exactly two children (non-null). Values in left subtree
< value in node < values in right subtree
• a node with two values is either a leaf node or has exactly three children (non-null). Values in left
subtree < first value in node < values in middle subtree < second value in node < value in right subtree.
 all leaf nodes are at the same level of the tree

Insertion algorithm
Into a two-three tree is quite different from the insertion algorithm into a binary search tree. In a two-three tree,
the algorithm will be as follows:
1. If the tree is empty, create a node and put value into the node
2. Otherwise find the leaf node where the value belongs.
3. If the leaf node has only one value, put the new value into the node
4. If the leaf node has more than two values, split the node and promote the median of the three values to
parent.
5. If the parent then has three values, continue to split and promote, forming a new root node if necessary

The lookup operation

Recall that the lookup operation needs to determine whether key value k is in a 2-3 tree T. The lookup
operation for a 2-3 tree is very similar to the lookup operation for a binary-search tree. There are 2 base cases:
1. T is empty: return false
2. T is a leaf node: return true iff the key value in T is k And there are 3 recursive
cases:
1. k <= T.leftMax: look up k in T's left subtree
2. T.leftMax < k <= T.middleMax: look up k in T's middle subtree

Page no: 6
 3. T.middleMax < k: look up k in T's right subtree
It should be clear that the time for lookup is proportional to the height of the tree. The height of the tree is
O(log N) for N = the number of nodes in the tree. You may think this is a problem, since the actual values are
only at the leaves. However, the number of leaves is always greater than N/2 (i.e., more than half the nodes in
the tree are leaves). So the time for lookup is also O(log M), where M is the number of key values stored in the
tree.

The delete operation

Deleting key k is similar to inserting: there is a special case when T is just a single (leaf) node containing k (T is
made empty); otherwise, the parent of the node to be deleted is found, then the tree is fixed up if necessary
so that it is still a 2-3 tree.
Once node n (the parent of the node to be deleted) is found, there are two cases, depending on how many
children n has: case 1: n has 3 children
• Remove the child with value k, then fix n.leftMax, n.middleMax, and n's ancestors' leftMax and
middleMax fields if necessary. case 2: n has only 2 children
• If n is the root of the tree, then remove the node containing k. Replace the root node with the other child
(so the final tree is just a single leaf node).  If n has a left or right sibling with 3 kids, then: o
remove the node containing k o "steal" one of the sibling's children o fix n.leftMax,
n.middleMax, and the leftMax and middleMax fields of n's sibling and ancestors as needed.
• If n's sibling(s) have only 2 children, then:
o remove the node containing k o make n's remaining child a child of n's sibling o fix leftMax and
middleMax fields of n's sibling as needed o remove n as a child of its parent, using essentially the same
two cases (depending on how many children n's parent has) as those just discussed
The time for delete is similar to insert; the worst case involves one traversal down the tree to find n, and
another "traversal" up the tree, fixing leftMax and middleMax fields along the way (the traversal up is really
actions that happen after the recursive call to delete has finished). So the total time is 2 * height-of-tree =
O(log N).

Complexity Analysis
• keys are stored only at leaves, ordered left-to-right  non-leaf nodes have 2 or 3 children (never
1)
• non-leaf nodes also have leftMax and middleMax values (as well as pointers to children)  all leaves
are at the same depth
• the height of the tree is O(log N), where N = # nodes in tree
• at least half the nodes are leaves, so the height of the tree is also O(log M) for M = # values stored in tree
• the lookup, insert, and delete methods can all be implemented to run in time O(log N), which is also
O(log M)

B-TREE:
B-Tree is a self-balancing search tree. In most of the other self-balancing search trees (like AVL and Red Black
Trees), it is assumed that everything is in main memory. To understand use of B-Trees, we must think of huge
amount of data that cannot fit in main memory. When the number of keys is high, the data is read from disk in
the form of blocks. Disk access time is very high compared to main memory access time. The main idea of
using B-Trees is to reduce the number of disk accesses. Most of the tree operations (search, insert, delete,
max, min, ..etc ) require O(h) disk accesses where h is height of the tree. B-tree is a fat tree. Height of B-Trees is
kept low by putting maximum possible keys in a B-Tree node. Generally, a B-Tree node size is kept equal to the
disk block size. Since h is low for B-Tree, total disk accesses for most of the operations are reduced significantly
compared to balanced Binary Search Trees like AVL Tree, Red Black Tree, ..etc.

Page no: 7
 Properties of B-Tree
1) All leaves are at same level.
2) A B-Tree is defined by the term minimum degree t . The alue of t depe ds upo disk lo k size.
3) Every node except root must contain at least t-1 keys. Root may contain minimum 1 key. 4) All nodes
(including root) may contain at most 2t – 1 keys.
5) Number of children of a node is equal to the number of keys in it plus 1.
6) All keys of a node are sorted in increasing order. The child between two keys k1 and k2 contains all keys in
range from k1 and k2.
7) B-Tree grows and shrinks from root which is unlike Binary Search Tree. Binary Search Trees grow downward
and also shrink from downward.
8) Like other balanced Binary Search Trees, time complexity to search, insert and delete is O(logn).

BASIC SEARCH AND TRAVERSAL TECHNIQUES FOR TREES AND GRAPHS:

Search
Search is similar to search in Binary Search Tree. Let the key to be searched be k. We start from root and
recursively traverse down. For every visited non-leaf node, if the node has key, we simply return the node.
Otherwise we recur down to the appropriate child (The child which is just before the first greater key) of the ode.
If e rea h a leaf ode a d do t fi d k i the leaf ode, e retur NULL.

59. Traversal
Tree traversal (also known as tree search) is a form of graph traversal and refers to the process of
visiting (checking and/or updating) each node in a tree data structure, exactly once. Such traversals are
classified by the order in which the nodes are visited.

Figure: 5.6 Binary Tree

Depth First Traversals:

(a) Inorder (Left, Root, Right): 4 2 5 1 3
(b) Preorder (Root, Left, Right): 1 2 4 5 3
(c) Postorder (Left, Right, Root) : 4 5 2 3 1 Breadth First or Level Order Traversal: 1 2 3 4 5

Graph Traversal Techniques:

Depth First Search (DFS)
The aim of DFS algorithm is to traverse the graph in such a way that it tries to go far from the root node. Stack is
used in the implementation of the depth first search.
Algorithmic Steps
Step 1: Push the root node in the Stack. Step 2: Loop until stack is empty.
Step 3: Peek the node of the stack.
Step 4: If the node has unvisited child nodes, get the unvisited child node, mark it as traversed and push it on
stack.
Step 5: If the node does not have any unvisited child nodes, pop the node from the stack.

Page no: 8
 Breadth First Search (BFS)
This is a very different approach for traversing the graph nodes. The aim of BFS algorithm is to traverse the graph
as close as possible to the root node. Queue is used in the implementation of the breadth first search.
Algorithmic Steps
Step 1: Push the root node in the Queue. Step 2: Loop until the queue is empty.
Step 3: Remove the node from the Queue.
Step 4: If the removed node has unvisited child nodes, mark them as visited and insert the unvisited children ithe
queue.
NP-COMPLETENESS:
We have been writing about efficient algorithms to solve complex problems, like shortest path, Euler graph,
minimum spanning tree, etc. Those were all success stories of algorithm designers. In this post, failure stories of
computer science are discussed.
Can all computational problems be solved by a computer? There are computational problems that cannot be
solved by algorithms even with unlimited time. For example Turing Halting problem (Given a program and an
input, whether the program will eventually halt when run with that input, or will run forever). Alan Turing proved
that general algorithm to solve the halting problem for all possible program-input pairs cannot exist. A key part of
the proof is, Turing machine was used as a mathematical definition of a computer and program (Source Halting
Problem).Status of NP Complete problems is another failure story, NP complete problems are problems whose
status is unknown. No polynomial time algorithm has yet been discovered for any NP complete problem, nor has
anybody yet been able to prove that no polynomial-time algorithm exist for any of them. The interesting part is,
if any one of the NP complete problems can be solved in polynomial time, then all of them can be solved.
What are NP, P, NP-complete and NP-Hard problems?
P is set of problems that can be solved by a deterministic Turing machine in Polynomial time.
NP is set of decision problems that can be solved by a Non-deterministic Turing Machine in Polynomial time. P is
subset of NP (any problem that can be solved by deterministic machine in polynomial time can also be solved by
non-deterministic machine in polynomial time) figure 5.1.
I for ally, NP is set of de isio pro le s hi h a e sol ed y a poly o ial ti e ia a Lu ky Algorith , a magical algorithm that
always makes a right guess among the given set of choices (Source Ref 1).
NP-complete problems are the hardest problems in NP set. A decision problem L is NP-complete if:
1) L is in NP (Any given solution for NP-complete problems can be verified quickly, but there is no efficient
known solution).
2) Every problem in NP is reducible to L in polynomial time (Reduction is defined below).
A problem is NP-Hard if it follo s property e tio ed a o e, does t eed to follo property . Therefore, NP-Complete set is
also a subset of NP-Hard set.

NP Hard

NP Complete

P=NP

NP

Figure: 5.7: Relationship between P,NP, NP Complete & NP Hard

Page no: 9
UNIT-V
NEED AND TYPES OF MAINTENANCE:
Software Maintenance: Software maintenance is an activity in which program is modified after it has been put i to use. I this
usuall it is ot p efe ed to appl ajo soft a e ha ges to s ste s a hite tu e. Maintenance is a process in which changes are
implemented by either modifying the existing systems architecture or by adding new components into the system.

Need for maintenance:

Software maintenance is widely accepted part of SDLC now a day. It stands for all the modifications and updating done after
the delivery of software product. There are number of reasons, why modifications are required, some of them are briefly
mentioned below:

• Market Conditions: Policies, which changes over the time, such as taxation and newly introduced constraints like,
how to maintain bookkeeping, may trigger need for modification.
• Client Requirements: Over the time, customer may ask for new features or functions in the software.
• Host Modifications: If any of the hardware and/or platform (such as operating system) of the target host
changes, software changes are needed to keep adaptability.
• Organization Changes: If there is any business level change at client end, such as reduction of organization
strength, acquiring another company, organization venturing into new business, need to modify in the original
software may arise.
Types of maintenance:
Various types of software maintenance are:

• Corrective Maintenance: Means the maintenance for correcting the software faults.
• Adaptive Maintenance: Means maintenance for adapting the change in environment (different system or
operating systems).
• Perfective Maintenance: Means modifying or enhancing the system to meet the new requirements.
• Preventive Maintenance: This includes modifications and updating to prevent future problems of the software.

Change Request

Change Impact analysis System release Change System release

management planning implementation

Corrective Adaptive Perfective maintenance

maintenance (fault maintenance (system enhancement)
repair) (platform adoption)

60. Figure 5.1: Maintenance Process

Issues in software maintenance:

Pa ge no: 1
 Issues in software maintenance

Technical Management Cost estimation Software maintenance measurement

61. Figure 5.2: Software Maintenance Issues

SOFTWARE CONFIGURATION MANAGEMENT (SCM):

Software configuration management is a set of activities carried out for identifying, organizing and controlling changes
throughout the life cycle of computer software.

Du i g the de elop e t of soft a e ha ge ust e a aged a d o t olled i o de to i p o e ualit and reduce error.

Hence software configuration management is a quality assurance activity that is applied throughout the software process.

SCM helps to eliminate the confusion often caused by miscommunication among team members. The SCM system controls
the basic components such as software objects, program code, test data, test output, design documents and user manuals.

The SCM system has the following advantages:

• Reduced redundant work.

• Effective management of simultaneous updates.
• Avoids configuration-related problems.
• Facilitates team coordination.
• Helps in building management; managing tools used in builds.
• Defect tracking: It ensures that every defect has traceability back to its source.

Software Configuration Items (SCIs): Information that is created as part of the software engineering process. Baselines: A
Baseline is a software configuration management concept that helps us to control change. Signals a point of departure from
one activity to the start of another activity. Helps control change without impeding justifiable change.

Elements of SCM
There are four elements of SCM:
1. Software Configuration Identification
2. Software Configuration Control
3. Software Configuration Auditing
4.Software Configuration Status Reporting
The SCM Process
The SCM process defines a series of tasks:
• Identification of objects in the software configuration
• Version Control
• Change Control
• Configuration Audit, and  Reporting

Pa ge no: 2
 Reporting

Configuration Audit

Change Control

Version Control

Identification

SCIs

62. Figure 5.3: SCM Process

SOFTWARE CHANGE MANAGEMENT:

Change control is function of configuration management, which ensures that all changes made to software system are
consistent and made as per organizational rules and regulations.

A change in the configuration of product goes through following steps –

• Identification: A change request arrives from either internal or external source. When change request is
identified formally, it is properly documented.
• Validation: Validity of the change request is checked and its handling procedure is confirmed.
• Analysis: The impact of change request is analyzed in terms of schedule, cost and required efforts. Overall impact
of the prospective change on system is analyzed.
• Control: It is decided that the changes are worth incorporation or not. If it is not, change request is refused
formally.
• Execution: If the previous phase determines to execute the change request, this phase takes appropriate actions
to execute the changes, through a thorough revision if necessary.
• Close request: The change is verified for correct implementation and merging with the rest of the system. This
newly incorporated change in the software is documented properly and the request is formally closed.

VERSION CONTROL:
Version Control is a system or tool that captures the changes to a source code element: file, folder, image or binary. This is
beneficial for many reasons, but the most fundamental reason is it allows you to track changes on a per file basis.

Version Control Benefits:

• Secure Access to your Source Code
• File History
• Facilitate Team Communication
• Baseline Trace Ability
• Automated Merge Capabilities
• Ensures no one Over-Writes Someone Else's Code
• Allows for Better Control for Parallel Development

Pa ge no: 3
 CHANGE CONTROL AND REPORTING:
Change control is a systematic approach to managing all changes made to a product or system. The purpose is to ensure that
no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted and that
resources are used efficiently. Change control is an essential step in software life cycle. The change control can be carried out
using following steps:  A change request initiates a changes

• The o figu atio o je t is he ked out of the data ase.

• The changes are applied to the object.
• The o je t is the he ked i to the data ase he e auto ati e sio o t ol is applied.

PROGRAM COMPREHENSION TECHNIQUES:

Program comprehension is a domain of computer science concerned with the ways software engineers maintain existing
source code.

Program comprehension tools only play a supporting role in other software engineering activities of design, development,
maintenance, and re-documentation. Software Engineering discipline which aims at understanding computer code written in
a high-level programming language. Program Comprehension is useful for reuse, maintenance, reverse engineering and many
other activities in the context of Software Engineering.

Program Comprehension Tool:

A program that aims at making the understanding of a software application easier, through the presentation of different
perspectives (views) of the overall system or its components. A PC Tool has modules to:
• Extract information by parsing the source code
• Store and handle the information extracted
• Visualize all the retrieved information

RE-ENGINEERING:
Software re-engineering means re-structuring or re-writing part or all of the software engineering system. It is needed for the
application which requires frequent maintenance.

Software re-engineering is a process of software development which is done to improve the maintainability of a software
system.

Re-engineering a software system has two key advantages:

• Reduced risk: As the software already exists, the risk is less as compared to developing new software.
• Reduced cost: The cost of re-engineering is significantly less than the costs of developing new software.

Re-engineering process activities:

• Source code translation: In this phase code is converted into new language.
• Reverse Engineering: Under this activity the program is analyzed and understood thoroughly.
• Program structure improvement: Restructure automatically for understandability.
• Program modularization: The program structure is reorganized.
• Data re-engineering: Finally clean-up and restructure system data.

Pa ge no: 4
 Original Program Modularized Original
Program documentation program data

Reverse
engineering
Program Data
Source code modularization reengineering
translation

Program
structure Structured Re-engineered
improvement program data

63. Figure 5.4: Re-engineering process activities

REVERSE ENGINEERING:
Reverse engineering is the process of design recovery. In reverse engineering the data, architectural and procedural
information is extracted from a source code.

The reverse engineering is required because using this technique the dirty, ambiguous code can be converted to clear and
unambiguous specification. This specification helps in understanding the source code.

There are 3 important issues in reverse engineering:

1. Abstraction Level: This level helps in obtaining the design information from the source code. It is expected that
abstraction level should be high in reverse engineering.
2. Completeness Level: The completeness means detailing of abstract level. The completeness decreases as
abstraction level increases.
3. Directionality Level: Directionality means extracting the information from source code and gives it to software
engineer. The directionality can be one way or two way. The one way directionality means extracting all the
information from source code and gives it to software engineer. The two way directionality means the
information taken from source code is fed to re-engineering tool that attempts to restructure or regenerate old
programs.

Dirty source code

Restructured code

Clean source code Process

Extract abstraction Interface

Initial documentation Database

Refine and simplicity

Final specification

Pa ge no: 5
 64. Figure 5.5: Reverse engineering process
Difference between reverse and forward and engineering:
S.No. Reverse Engineering Forward Engineering
1. It performs transformation from a lower The traditional process of moving from high-level
abstraction to higher one. abstractions and logical, implementation
independent designs to the physical implementation
of a system.
2. Usually done when docs are not appropriate or Modification of the system is done. E.g.
is missing. 1) Use of different programming language.
2 ) introduction of new DBMS
3) Transfer of s/w to new h/w platform.
3. Reverse engineering is a process in which the Forward-engineering is a process in which
dirty or unstructured code is taken, processed theories, methods and tools are applied to develop
and it is restructured. a professional software product.
4. Reverse Engineering is trying to recreate the Forward engineering is normal engineering. It builds
source code from the compiled code. That is devices that can do certain useful things for us:
trying to figure out how a piece of software
works given only the final system.
5. It is complex because cleaning the dirty or It is simple and straight forward approach.
unstructured code requires more efforts.
6. Documentation or specification of the product Documentation or specification of the product is
is useful to the developer. useful to the end user.
7. This process starts by understanding the This process starts by understanding user
existing unstructured code. requirements.
65. Table 5.1: Forward and Reverse Engineering

TOOL SUPPORT:
CASE Tool Support:
CASE tools are set of software application programs, which are used to automate SDLC activities. CASE tools are used by
software project managers, analysts and engineers to develop software system.

There are number of CASE tools available to simplify various stages of Software Development Life Cycle such as Analysis tools,
Design tools, Project management tools, Database Management tools, Documentation tools are to name a few.

Use of CASE tools accelerates the development of project to produce desired result and helps to uncover flaws before moving
ahead with next stage in software development.

Components of CASE Tools

CASE tools can be broadly divided into the following parts based on their use at a particular SDLC stage:

• Central Repository - CASE tools require a central repository, which can serve as a source of common, integrated
and consistent information. Central repository is a central place of storage where product specifications,
requirement documents, related reports and diagrams, other useful information regarding management are
stored. Central repository also serves as data dictionary.
• Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of SDLC.
• Lower Case Tools - Lower CASE tools are used in implementation, testing and maintenance.

Pa ge no: 6
 Design
Implementation
Planning
Analysis
Lower C
• Integrated Case Tools - Testing Integrated CASE
tools are helpful in all the stages ASE of SDLC, from
Requirement gathering to Testing and documentation.
Maintenance

66. Figure 5.6: CASE Component

Project management
tools

Programming tools
Prototyping and
simulation tools

Consistency and
completeness tools
Software configuration
Central repository management tools
Documentation tools
(Data Dictionary)

Analysis and design

tools
Requirement tracing
tools
Database management
Transferring tools for and report generation
exchanging data in tools
different formats

67. Figure 5.7: Block Diagram for CASE Environment

PROJECT MANAGEMENT CONCEPTS:

Software project management is an activity of organizing, planning and scheduling the software projects. The goal of software
project management is to deliver the software product in given time and within the budget. It is also necessary that the
software project should be developed in accordance with the requirements of the organization. The project management is
the application of knowledge, skill, tools and techniques to project activities to meet the project requirements.

Objectives of project management:

• The objective of the project planning and management is to provide a framework for the project.
• Using the project framework, the project manger decides the estimates for the schedule, cost and resources.
• Another objective of the project planning and management is that- it should be possible to get the best case and
worst case outcomes of the project.
• There should be sufficient information discovery through the project so that reasonable project estimate can be
made.

FEASIBILITY ANALYSIS:
When the client approaches the organization for getting the desired product developed, it comes up with a rough idea about
what all functions of the software must perform and which all features are expected from the software.

Pa ge no: 7
Referencing to this information, the analysts do a detailed study about whether the desired system and its functionality are
feasible to develop or not.

This feasibility study is focused towards goal of the organization. This study analyses whether the software product can be
practically materialized in terms of implementation, contribution of project to organization, cost constraints, and as per values
and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability,
productivity, and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations
for management about whether or not the project should be undertaken.

PROJECT AND PROCESS PLANNING:

Project planning is part of project management, in which project manager should recognize the future problems in advance
and should be ready with the tentative solution to those problems. A project plan must be prepared in advance from the
available information. The project planning is an iterative process and it gets completed only on the completion of the project.
This process is iterative because new information gets available at each phase of the project development. Hence the plan
needs to be modified on regular basis for accommodation new requirements of the project.

Project planning is inherently uncertain as it must be done before the project is actually started. Therefore the duration of the
tasks is often estimated through a weighted average of optimistic, normal, and pessimistic cases.

The main purpose of this phase is to plan time, cost, and resources adequately to estimate the work needed and to effectively
manage risk. Initial planning generally consists of:
• Developing the scope statement
• Selecting the planning team
• Identifying deliverables
• Creating the work breakdown structure
• Identifying the activities needed to complete those deliverables
• Sequencing the activities in a logical way
• Estimating the resources needed
• Estimating the time needed
• Estimating the costs
• Developing the schedule
• Developing the budget
• Gaining formal approval to begin

RESOURCE ALLOCATIONS:
Once the objectives of the project management are achieved, the project management is to estimate the resources for the
project. Various recourses of the project are:

• Human or people
• Reusable software components
• Hardware or software components
The resources are available in limited quantity and stay in the organization as a pool of assets. The shortage of resources
hampers development of the 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:

Pa ge no: 8
 • 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 EFFORTS:
Project Estimation
For an effective management, accurate estimation of various measures is a must. With the correct estimation, managers can
manage and control the project more efficiently and effectively.

Project estimation may involve the following:

• Software size estimation: Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon coding practices. Function
points vary according to the user or software requirement.
• Effort estimation: The manager estimates efforts in terms of personnel requirement and man-hour required to
produce the software. For effort estimation software size should be known. This can either e de i ed a age s e pe
ie e, histo i al data of o ga izatio , o software size can be converted into efforts by using some standard formula.
• Time estimation: Once size and efforts are estimated, the time required to produce the software can be
estimated. An effort required is segregated into sub categories as per the requirement specifications and
interdependency of various components of software. Software tasks are divided into smaller tasks, activities or
events by Work Breakthrough Structure (WBS). The tasks are scheduled on day-to-day basis or in calendar
months. The sum of time required to complete all tasks in hours or days is the total time invested to complete
the project.
• Cost estimation: This might be considered as the most difficult of all because it depends on more elements than
any of the previous ones. For estimating project cost, it is required to consider – o Size of the software o
Software quality o Hardware o Additional software or tools, licenses etc. o Skilled personnel with task-specific
skills
o Travel involved o Communication
o Training and support

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 then arrange them keeping various
factors in mind. They look for tasks like in critical path in the schedule, which are necessary to complete in specific manner
(because of task interdependency) and strictly within the time allocated. During the project scheduling the total work is
separated into various small activities.

Identify Identify Estimate Assign people Create activity

activities possible resources to conduct network and
dependencies activities bar charts

68. Figure 5.8: Project scheduling process

For scheduling a project, it is necessary to:

• Break down the project tasks into smaller, manageable form

Pa ge no: 9
 • 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

COST ESTIMATIONS:
Cost estimation can be defined as the approximate judgments of the costs for project. Cost estimation is usually measured in
terms of effort. The effort is the amount of time for one person to work for a certain period of time. COCOMO is one the most
widely used software estimation models in the world. The Constructive Cost Model (COCOMO) is a procedural software cost
estimation model .COCOMO is used to estimate size, effort and duration based on the cost of the software.

COCOMO predicts the effort and schedule for a software product development based on inputs relating to the size of the
software and a number of cost drivers that affect productivity.

COCOMO has three different models that reflect the complexities:

• Basic Model: this model would be applied early in a projects development. It will provide a rough estimate early
on that should be refined later on with one of the other models.
• Intermediate Model: this model would be used after you have more detailed requirements for a project.
• Detailed Model: when design of the project is complete you can apply this model to further refine your
estimate.
Within each of these models there are also three different modes. The mode you choose will depend on your work
environment, and the size and constraints of the project itself. The modes are:

• Organic: this mode is used fo elati it s all soft a e tea s de elopi g soft a e i a highl fa ilia , in-house e i o e t .
• Embedded: ope ati g ithi tight o st ai ts he e the p odu t is st o gl tied to a o ple of hardware, software, regulations
and operational po edu es .
• Semi-detached: an intermediate stage somewhere in between organic and embedded. Projects are usually of
moderate size of up to 300,000 lines of code.

Basic Model: The basic COCOMO model estimates the software development effort using only Lines Of Code (LOC). Various
equations in this model are:
Effort Applied (E) = ab(KLOC)bb [man-months]
Development Time (D) = cb(Effort Applied)db[months]
People required (P) = Effort Applied / Development Time [count]
Where, KLOC is the estimated number of delivered lines (expressed in thousands) of code for project. The coefficients ab, bb,
cb and db are given in the following table:

Software Projects ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Table 5.2: List of Constants Based on Mode for Basic COCOMO
Intermediate Model: This is an extension of basic COCOMO model. This estimation model makes use of set of ost d i e
att i utes to o pute the ost of soft a e.

Pa ge no: 10
The formula for effort calculation is:

E=ai(KLOC)(bi)(EAF)
Where E is the effort applied in person-months, KLOC is the estimated number of thousands of delivered lines of code for
the project, and EAF is the factor calculated above. The coefficient ai and the exponent bi are given in the next table.
Software Projects ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
Table 5.3: List of Constants Based on Mode for Intermediate Model
The Development time D calculation uses E in the same way as in the Basic COCOMO.

Detailed Model: Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of the cost
driver's impact on each step (analysis, design, etc.) of the software engineering process.

The detailed model uses different effort multipliers for each cost driver attribute. These Phase Sensitive effort multipliers are
each to determine the amount of effort required to complete each phase. In detailed COCOMO, the whole software is divided
into different modules and then we apply COCOMO in different modules to estimate effort and then sum the effort.

The effort is calculated as a function of program size and a set of cost drivers are given according to each phase of the
software life cycle.

PROJECT SCHEDULING AND TRACKING:

Project schedule is the most important factor for software project manager. It is the duty of project manager to decide the
project schedule and track the schedule.

Tracking the schedule means determine the tasks and milestone in the project as it proceeds. Following are the
various ways by which tracking of the project can be achieved:

• Conduct periodic meetings.

• Evaluate results of all the project reviews.
• Compare actual start date and scheduled start date of each of the project task.
• Determine if milestones of the project are achieved on scheduled date or not.
• Meet informally to the software practitioners.
• Assess the progress of the project quantitatively.

RISK ASSESSMENT AND MITIGATION:

Risk management involves all activities pertaining to identification, analyzing and making provision for predictable and non-
predictable risks in the project. Risk may include the following:

• Experienced staff leaving the project and new staff coming in.
• Change in organizational management.
• Requirement change or misinterpreting requirement.
• Under-estimation of required time and resources.
• Technological changes, environmental changes, business competition.

Process of Risk Management:

Risk management performed in following stages:
1. Risk identification: In this phase all possible risks are anticipated and a list of potential risks are prepared.

Pa ge no: 11
 2. Risk analysis: After risk identification, a list is prepared in which risks are prioritized.
3. Risk planning: The risk avoidance or risk minimization plan is prepared in this phase.
4. Risk monitoring: Identified risks must be mitigated. Hence risk mitigation plan must be prepared once the risks
are discovered.

Risk identification Risk analysis Risk planning Risk monitoring

List of identified risks Prioritized list of risk Risk avoidance Risk assessment
/minimization plan

Figure 5.9: Risk management process

Risk Mitigation, Monitoring and Management (RMMM):

Risk analysis supports the project team in constructing a strategy to deal with risks.

There are three important issues considered in developing an effective strategy:

• Risk avoidance or mitigation - It is the primary strategy which is fulfilled through a plan.
• Risk monitoring - The project manager monitors the factors and gives an indication whether the risk is becoming
more or less.
• Risk management and planning - It assumes that the mitigation effort failed and the risk is a reality.

RMMM Plan:
• It is a part of the software development plan or a separate document.
• The RMMM plan documents all work executed as a part of risk analysis and used by the project manager as a
part of the overall project plan.
• The risk mitigation and monitoring starts after the project is started and the documentation of RMMM is
completed.

SOFTWARE QUALITY ASSURANCE (SQA):

Software Quality:
In the context of software engineering, software quality measures how well software is designed (quality of design), and how
well the software conforms to that design (quality of conformance).

Quality Control:
Quality control (QC) is a procedure or set of procedures intended to ensure that a manufactured product or performed service
adheres to a defined set of quality criteria or meets the requirements of the client or customer.

Quality Assurance:

Pa ge no: 12
It is planned and systematic pattern of activities necessary to provide a high degree of confidence in the quality of a product.
It provides quality assessment of the quality control activities and determines the validity of the data or procedures for
determining quality.

SQA Activities to Assure the Software Quality

The Software Quality Assurance of the software is analyzed and ensured by performing a series of activities. The activities are
performed as step by step process and the result analysis is reported for the final evaluation process. The activities are
performed as step by step process and the result analysis is reported for the final evaluation process.
A Quality Management Plan is prepared
• Application of Technical Methods (Employing proper methods and tools for developing software)  Conduct of
Formal Technical Review (FTR)
• Testing of Software
• Enforcement of Standards (Customer imposed standards or management imposed standards)
• Control of Change (Assess the need for change, document the change)
• Measurement (Software Metrics to measure the quality, quantifiable)
• Records Keeping and Recording (Documentation, reviewed, change control etc. i.e. benefits of docs).

PROJECT PLAN:
A project plan is a formal document designed to guide the control and execution of a project. A project plan is the key to a
successful project and is the most important document that needs to be created when starting any business project.

A project plan is used for the following purposes:

• To document and communicate stakeholder products and project expectations  To control schedule and
delivery
• To calculate and manage associated risks

PROJECT METRICS:
Metrics is a quantitative measure of the degree to which a system, component, or process possesses a given attribute.

Project metrics are quantitative measures that enable software engineers to gain insight into the efficiency of the software
process and the projects conducted using the process framework. Project metrics are used by a project manager and a
software team to adapt project work flow and technical activities.

Size Oriented Metrics:

• Size oriented measure is derived by considering the size of software that has been produced.
• The organization builds a simple record of size measure for the software projects. It is built on past experiences
of organizations.
• It is a direct measure of software
• A simple set of size measure that can be developed is as given below:
o Size= KLOC o Effort = Person/month o Productivity=KLOC/ Person-month o Quality= number of
faults/KLOC
o Cost=$/KLOC
o Documentation= Pages of documentation/KLOC

Function Oriented Metrics:

• Use a measure of the functionality delivered by the application as a normalization value.
• Functionality cannot be measured directly; it must be derived indirectly using other direct measures.

Pa ge no: 13
 • A measure called the function point.
• Function points are derived using an empirical relationship based on countable (direct) measures of
software's information domain and assessments of software complexity. How to calculate Function Point?
Domain Characteristics Count Weighting factor Count

Simple Average Complex

Number of user input x 3 4 6
Number of user output x 4 5 7
Number of user x 3 4 6
inquiries
Number of files x 7 10 15
Number of external x 5 7 10
interfaces
Count Total
69. Table 5.4: Function Point calculation table

Number of user inputs. Each user input that provides distinct application oriented data to the software is counted. Inputs
should be distinguished from inquiries, which are counted separately.

Number of user outputs. Each user output that provides application oriented information to the user is counted. In this
context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted
separately.

Number of user inquiries. 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. Each distinct inquiry is counted.

Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate
file) is counted.

Number of external interfaces. All machine readable interfaces (e.g., data files on storage media) that are used to transmit
information to another system are counted.

To compute function points (FP), the following relationship is used:

FP = ou t total . +. Σ Fi he e ou t total is the su of all FP e t ies .

The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions:

1. Does the system require reliable backup and recovery?

2. Are data communications required?
3. Are there distributed processing functions?

Pa ge no: 14
 4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over
multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?

Object Oriented Metrics:

Following are the set of metrics for object oriented projects:
1. Weighted Methods per Class Number of methods defined in class
• Complex methods weigh more
• Higher numbers = more faults
• Classes are more specific = hard to reuse
• Changes have more impact on subclasses
2. Depth of Inheritance Tree
Number of super classes
•Measures depth of hierarchy
•Deep trees imply more complexity
•Inheritance should reduce complexity not increase it
•Deep trees promote reuse
•Bugs are found in middle of tree
3. Number of Children
Number of immediate subclasses
•Measures breadth of hierarchy
•Depth (DIT) implies reuse in a way breath (NOC) does not  Large numbers mean high reuse of base class;
test it!
• High NOC related to lower faults.
• BUT, perhaps improper use of base class
4. Coupling between Object Classes Number of classes to which I am coupled
• Coupli g → We use ea h othe s data o ethods
• High CBO is undesirable
• Prevents reuse
• Sensitivity to changes in others increases maintenance  > 14 is too high
5. Response For a Class
Total number of methods executed
• Large RFC = more faults
• If most methods have a small RFC but one method has a  Hugh RFC
o you have a structured (not OO) application

Pa ge no: 15
 6. Lack of Cohesion of Methods
How well the methods of a class are are related to each other?
• A cohesive class performs one function
• Highly cohesive classes promotes encapsulation
• but have highly coupled methods
• Low cohesion = more errors

Pa ge no: 16