Software engineering module 4 notes for btech and mca

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)

5. STEPS

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

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

8. 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

9. 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

10. Axiomatic Specifications

11. Two major components: Syntatic specifications Header Operation Variable Declaration Semantic specifications

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

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

14. 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

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

16. 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;

17. 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

18. OUTPUTS SKILL SETS CHALLENGES METRICS 20

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

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

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

22. Methods/Techniques Top Down Bottom Up Three Point Analogous Function point Use case points Wide band Delphi Expert Judgement What if Analysis Monte Carlo Simulation Parametric COCOMO 24

23. 25

24. 26

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

26. 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

27. 29 COCOMO Model COCOMO ( CO nstructive CO st MO del) proposed by Boehm. Divides software product developments into 3 categories: Organic Semidetached Embedded

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

29. 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).

30. 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

31. 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

32. 34 Basic COCOMO Model (CONT.) Effort is somewhat super-linear in problem size. Effort Size Embedded Semidetached Organic

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

34. 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

35. 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

36. 38 Complete COCOMO

37. 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.

38. 40

39. 41

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

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

42. 44

43. 45

44. 46

45. Best Practices - Reusability, Maintainability and Scalability 47

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

47. For example

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

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

50. Example int f1( int x, int y){ while (x != y){ if (x>y) then x=x-y; else y=y-x; } return x; } Euclid's GCD Algorithm

51. 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.

52. Branch Coverage

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

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

55. Path Coverage

56. Control flow graph (CFG)

57. 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.

58. Example Cyclomatic complexity = 7 – 6 + 2 = 3.

59. 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

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

61. 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.

62. 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.

63. 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.

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

65. 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.

66. Cyclomatic complexity Cyclomatic complexity of a program: also indicates the psychological complexity of a program. difficulty level of understanding the program.

67. 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.

68. Euclid’s GCD computation algorithm int f1(int x, int y){ while (x != y){ if (x>y) then x=x-y; else y=y-x; } return x; }

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

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

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

72. McCabe’s Cyclomatic Complexity int f1(int x, int y){ while (x != y){ if (x>y) then x=x-y; else y=y-x; } return x; }

73. Example int f1( int x,int y){ while (x != y){ if (x>y) then x=x-y; else y=y-x; } return x; }

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

75. 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

76. Control Flow Graph 1 2 3 4 5 6

77. 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)

78. Example-2 (Cyclomatic Complexity)

79. CFG

80. Example-3

81. Data Flow-Based Testing

82. 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}.

83. DU Chain Example 1 X(){ 2 a=5; /* Defines variable a */ 3 While(C1) { 4 if (C2) 5 b=a*a; /*Uses variable a */ 6 a=a-1; /* Defines variable a */ 7 } 8 print(a); } /*Uses variable a */

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

85. 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

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