Software engineering

1. Module 4
SPM

2. Engineering Activities in Project Lifecycle:
Software requirement gathering-Inputs and start criteria, Dimensions,
Steps, Output and Quality records, skillsets, Challenges, Metrics for
Requirement Phase.
Estimation–Three Phases of Estimation, Methodology, Formal models for
size estimation, challenges, Metrics for Estimation Process.
Design and Development Phases–Features, Reusability, Testability and
Maintainability.
Project Management in Testing and Maintenance Phases.

3. 1. Software Requirements Gathering
INPUT & START CRITERIA
Identify stakeholders
Establish project goals
Elicit requirements
Analyze requirements
Prioritize requirements
Validate requirements

4. DIMENSIONS
Stakeholders
Interviewing
Use case Modelling
Facility Application Specification Technique (FAST)

6. STEPS

7. Techniques for
Requirements Gathering
• Document analysis
• Observation
• Interface Analysis
• Questionnaires
• Use Case scenarios
• Mind Mapping
• Prototyping

9. 9
Formal Specification
Mathematical techniques used
include:
• Logic-based
• set theoretic
• algebraic specification
• finite state machines, etc.

10. Functional specification using pre-condition and post
condition
e.g. Module Sort – Sort a list L of integers in ascending
order
Pre-Condt – non-null L
Post-Condt – for all ‘i’, 1<=i<= size {L}, L[i]<=L[i+1]
L=[1,8,7,6,5]
L=[3,4,5,6,8]
10

11. E – Initial State
E’ – Final State
Input : non null L
Output : for all i , 1<=i<size{L’} and L[i]<=l’[i+1] and
L’=permutation[L]
11

12. Axiomatic Specifications

13. Two major components:
1. Syntatic specifications
Header
Operation
Variable Declaration
2. Semantic specifications

14. Completeness & Consistency
Theoretically consistency is difficult to prove.
Completeness
- Constructors
- Extension Operators

15. Axiomatic Specification of a Stack
Operations:
Create:
Push:
Pop:
Top:

16. 1. Stack [integer] Header
Declare
2. Create() Stack; Constructors
3. Push(stack, integer)  Stack;
4. Pop(stack)  stack;
5. Top(stack)  integer or undefined; Extension Operators
Var
6. s: stack ; i: integer ; Variable declaration
For all
7. top(create())=undefined;
8. top(push(s,i))=I;
9. pop(create())=create(); Axioms
10. pop(push(s,i))=s;
end

17. Axiomatic Specification of a Queue
newq:
addq:
deleteq:
emptyq:
appendq:
frontq:

18. 1. queue[item]  header
declare
2. newq() queue;
3. addq(queue, item) queue;
4. deleteq(queue)  queue;
5. emptyq(queue) Boolean;
6. appendq(queue,queue) queue;
7. frontq(queue)  Item or undefined;

19. var
8. q,r: queue;
9. i: item;
10. emptyq(newq())=true;
11. emptyq(addq(q,i))=false;
12. frontq(newq())=undefined;
13. frontq(addq(q,i))=if emptyq(q) then i else frontq(q)
14. deleteq(newq())=newq()
15. deleteq(addq(q,i))= if emptyq(q) then newq() else
addq(delete(q),i);
16. appendq(q,new())=q;
17. appendq(r,addq(q,i))=addq(appendq(r,q),i);
end

20. OUTPUTS
SKILL SETS
CHALLENGES
METRICS
20

21. 2. Estimation–Three Phases of Estimation, Methodology,
Formal models for size estimation, challenges, Metrics for
Estimation Process.
21

22. THREE PHASES OF ESTIMATION
Effort estimation
Cost estimation
Resource estimate
INPUT – PROJECT SIZE
22

23. PROJECT SIZE
Who estimates?
Metrics/Techniques of estimation
23

24. Methods/Techniques
1. Top Down
2. Bottom Up
3. Three Point
4. Analogous
5. Function point
6. Use case points
7. Wide band Delphi
8. Expert Judgement
9. What if Analysis
10. Monte Carlo Simulation
11. Parametric
12. COCOMO
24

25. 25

26. 26

27. Weighting Factor
SIMPLE AVERAGE COMPLEX
3 4 6
4 5 7
3 4 6
7 10 15
5 7 10
27

28. FP=UFP*[0.65+0.01*46]
FP=50*1.11=55.5 => 56
1 FP=60 LOC
56 * 60 =3360 LOC
FP - Domain Count Weighting Factor Value
EI 3 3 9
EO 2 4 8
EQ 2 3 6
ILF 1 7 7
EIF 4 5 20
28

29. 29
COCOMO Model
 COCOMO (COnstructive COst MOdel) proposed by
Boehm.
 Divides software product developments into 3
categories:
• Organic
• Semidetached
• Embedded

30. 30
COCOMO Model(CONT.)
Software cost estimation is done
through three stages:
• Basic COCOMO,
• Intermediate COCOMO,
• Complete COCOMO.

31. 31
Basic COCOMO Model(CONT.)
Gives only an approximate estimation:
Effort = a1 (KLOC)a2
Tdev = b1 (Effort)b2
• KLOC is the estimated kilo lines of source code,
• a1,a2,b1,b2 are constants for different
categories of software products,
• Tdev is the estimated time to develop the
software in months,
• Effort estimation is obtained in terms of person
months (PMs).

32. 32
Development Effort Estimation
 Organic :
 Effort = 2.4 (KLOC)1.05
PM
 Semi-detached:
 Effort = 3.0(KLOC)1.12
PM
 Embedded:
 Effort = 3.6 (KLOC)1.20
PM

33. 33
Development Time Estimation
 Organic:
 Tdev = 2.5 (Effort)0.38
Months
 Semi-detached:
 Tdev = 2.5 (Effort)0.35
Months
 Embedded:
 Tdev = 2.5 (Effort)0.32
Months

34. 34
Basic COCOMO Model(CONT.)
 Effort is
somewhat
super-linear in
problem size.
Effort
Size
Em
bedded
Sem
idetached
Organic

35. 35
Example
The size of an organic software product has been estimated to be
32,000 lines of source code.

36. 36
Example
The size of an organic software product has been estimated to be
32,000 lines of source code.
Effort = 2.4*(32)1.05 = 91 PM
Nominal development time = 2.5*(91)0.38 = 14 months

37. 37
Intermediate COCOMO
Basic COCOMO model assumes effort and development
time depend on product size alone.
However, several parameters affect effort and
development time:
• Reliability requirements
• Availability of CASE tools and modern facilities to the developers
• Size of data to be handled

38. 38
Complete COCOMO

39. 39
Complete COCOMO Example
A Management Information System (MIS) for an
organization having offices at several places across
the country:
• Database part (semi-detached)
• Graphical User Interface (GUI) part (organic)
• Communication part (embedded)
Costs of the components are estimated separately:
• summed up to give the overall cost of the system.

40. 40

41. 41

42. 3. Design and Development Phases–Features, Reusability,
Testability and Maintainability.
42

43. Reusability
 Naming Convention
 Single responsibility
 Short sub flows
 Parameterization
 Speculative generality
43

44. 44

45. 45

46. 46

47. Best Practices - Reusability, Maintainability and Scalability
47

48. 4. Project Management in Testing and Maintenance
Phases.
48

51. For example

52. Testing
Functional
Unit System
Non-
Functional
Integratio
n

53. White-Box Testing
• Statement coverage
• Branch coverage
• Path coverage
• Condition coverage
• Mutation testing
• Data flow-based testing

54. Statement Coverage
• The principal idea:
– unless a statement is executed, we have no way of knowing if an
error exists in that statement

55. Example
• int f1(int x, int y){
1. while (x != y){
2. if (x>y) then
3. x=x-y;
4. else y=y-x;
5. }
6. return x; }

56. Euclid's GCD computation algorithm
• By choosing the test set
{(x=3,y=3),(x=4,y=3), (x=3,y=4)}
– all statements are executed at least once.

57. Branch Coverage

58. Example
• Test cases for branch coverage can be:
{(x=3,y=3), (x=4,y=3), (x=3,y=4)}

59. Condition coverage
• Consider a Boolean expression having n components:
– for condition coverage we require 2n
test cases.
• practical only if n (the number of component conditions) is
small.

60. Path Coverage

61. Control flow graph (CFG)

62. How to draw Control flow graph?
• Number all the statements of a program.
• Numbered statements:
– represent nodes of the control flow graph.
• An edge from one node to another node exists:
– if execution of the statement representing the first node can result in
transfer of control to the other node.

63. Example
• Cyclomatic complexity =
7 – 6 + 2 = 3.

64. Cyclomatic complexity
• Another way of computing cyclomatic complexity:
– determine number of bounded areas in the graph
• Any region enclosed by a nodes and edge sequence.
• V(G) = Total number of bounded areas + 1

65. Example
• From a visual examination of the CFG:
– the number of bounded areas is 2.
– cyclomatic complexity = 2+1=3.

66. Cyclomatic complexity
• McCabe's metric provides:
– a quantitative measure of estimating testing difficulty
– Amenable to automation
• Intuitively,
– number of bounded areas increases with the number of decision
nodes and loops.

67. Cyclomatic complexity
• The cyclomatic complexity of a program provides:
– a lower bound on the number of test cases to be designed
– to guarantee coverage of all linearly independent paths.

68. Cyclomatic complexity
• Defines the number of independent paths in a program.
• Provides a lower bound:
– for the number of test cases for path coverage.
• only gives an indication of the minimum number of test cases
required.

69. Path testing
• The tester proposes initial set of test data using his experience
and judgement.

70. An interesting application of cyclomatic complexity
• Relationship exists between:
– McCabe's metric
– the number of errors existing in the code,
– the time required to find and correct the errors.

71. Cyclomatic complexity
• Cyclomatic complexity of a program:
– also indicates the psychological complexity of a program.
– difficulty level of understanding the program.

72. Cyclomatic complexity
• From maintenance perspective,
– limit cyclomatic complexity
• of modules to some reasonable value.
– Good software development organizations:
• restrict cyclomatic complexity of functions to a maximum of ten or so.

73. Euclid’s GCD computation algorithm
• int f1(int x, int y){
1. while (x != y){
2. if (x>y) then
3. x=x-y;
4. else y=y-x;
5. }
6. return x; }

74. Control Flow Graph
Sequence
1 a=5;
2 b=a*2-1
1
2

75. Selection
1 if (a>b)
2 c=3;
3 else c=5;
4 c=c*c;
1
4
2
3

76. Iteration
1 while(a>b){
2 b=b-1;
3 b=b*a;}
4 c=a+b;
1
2
3
4

77. McCabe’s Cyclomatic Complexity
• int f1(int x, int y){
1. while (x != y){
2. if (x>y) then
3. x=x-y;
4. else y=y-x;
5. }
6. return x; }

78. Example
int f1(int x,int y){
1. while (x != y){
2. if (x>y) then
3. x=x-y;
4. else y=y-x;
5. }
6. return x; }

79. Example Control Flow Graph
1
2
3 4
5
6

80. McCabe's cyclomatic metric
• Given a control flow graph G,
cyclomatic complexity V(G):
– V(G)= E-N+2
• N is the number of nodes in G
• E is the number of edges in G

81. Control Flow Graph
1
2
3 4
5
6

82. Derivation of test cases
Number of independent paths: 3
–1, 6 test case (x=1, y=1)
–1, 2, 3, 5, 1, 6 test case(x=1, y=2)
–1, 2, 4, 5, 1, 6 test case(x=2, y=1)

83. Example-2 (Cyclomatic Complexity)

85. CFG

86. Example-3

89. Data Flow-Based Testing

90. Data Flow-Based Testing
• For a statement numbered S,
– DEF(S) = {X/statement S contains a definition of X}
– USES(S)= {X/statement S contains a use of X}
– Example: 1: a=b; DEF(1)={a}, USES(1)={b}.
– Example: 2: a=a+b; DEF(1)={a}, USES(1)={a,b}.

91.  Project Size Estimation Techniques - Software Engineeri
ng
– GeeksforGeeks
 6 Success
 What is an Estimation Method? 6 Project Planning Tips
[2024] • Asana
ful Project Estimation Techniques in 2024
92

92. Activity Time Estimate Dependency
1-2 5 -
1-3 6 -
1-4 3 -
2-5 5 1-2
3-6 7 1-3
3-7 10 1-3
4-7 4 1-4
5-8 2 2-5
6-8 5 3-6
7-9 6 1-3, 1-4
8-9 4 5-8, 6-8
93

93.  Globalization issues in project management by TANUJA
KAYARGA CS&E on
Prezi
 Globalization issues in project management | PPT
94