1. Software Engineering Trilogy: Process, Method, Management
Eldon Y. Li
University Chair Professor
Department of MIS
National Chengchi University
*** All right reserved. Video or audio recording is prohibited. Reference to this document should be made as follows: Li, E.Y. “Software Engineering Trilogy: Process, Method, Management,” unpublished lecture, National Chengchi University, ***
2018/11/16

2. About me Abstract Process Method Management Summary Q & A
Agenda
About me
Abstract
Process
Method
Management
Summary
Q & A
2018/11/16

3. About Me
Eldon Y. Li is a university chair professor and former department chair of MIS at National Chengchi University, an adjunct chair professor of Asia University in Taiwan, and a former professor and coordinator of the MIS program at College of Business, California Polytechnic State University, San Luis Obispo, California, USA. He was the dean of College of Informatics and the director of Graduate Institute of Social Informatics at Yuan Ze University in Taiwan, as well as professor and founding director at the Graduate Institute of Information Management at the National Chung Cheng University in Chia-Yi, Taiwan. He received his PhD from Texas Tech University in He is the editor-in-chief of several international journals. He has published more than 250 papers in various topics related to innovation and technology management, human factors in information technology (IT), strategic IT planning, software quality management, and information systems management. His papers appear in Journal of Management Information Systems, Research Policy, Communications of the ACM, Internet Research, Expert Systems with Applications, Computers & Education, Decision Support Systems, Information & Management, International Journal of Medical Informatics, Organization, among others.
2018/11/16

4. Software Engineering Trilogy: Process, Method, Management
Abstract
Software Engineering is the application of engineering discipline to the development of software in a systematic method. The lecture begins with an introduction to information systems evolution and software development processes, discussion of structured programming and testing methods, and ends with complexity metrics and software process management. A disciplined software engineer must equipped with these knowledge and skills to achieve outstanding performance.
2018/11/16

5. Process
2018/11/16

6. Evolution Process of Information Systems
Initiation
Control
Contagion
Reposition
Integration
Maturity
2018/11/16

7. Software Development Process Models
The waterfall model
Plan-driven model. Separate and distinct phases of specification and development.
Incremental development
Specification, development and validation are interleaved. May be plan-driven or agile.
Reuse-oriented software engineering
The system is assembled from existing components. May be plan-driven or agile.
In practice, most large systems are developed using a mixed process that incorporates elements from all of these models.
2018/11/16

8. The waterfall model
Source: Ian Sommerville (2010) Software Engineering, 9th ed.
2018/11/16

9. Incremental development
2018/11/16

10. Reuse-oriented software engineering process
2018/11/16

11. The requirements engineering process
2018/11/16

12. A general model of the design process
2018/11/16

13. Testing phases in a plan-driven software process
2018/11/16

14. System evolution / maintenance process
2018/11/16

15. Prototype development process
2018/11/16

16. Incremental delivery process
2018/11/16

17. Boehm’s spiral model of the software process
2018/11/16

18. Method
2018/11/16

19. Software Design Methods
Top-down design/ stepwise refinement/ functional decomposition
Data flow-oriented design
Data structure-oriented design/ structured design
Object oriented design
2018/11/16

20. Structure chart
2018/11/16

21. Final structure chart
2018/11/16

22. Programming Methods
Procedural Programming generally flows from one statement to the next, with occasional jumps and loops handled with GOTO statements. As the amount of code and complexity increases, the end result is code that is extremely difficult to read and maintain, known as spaghetti code. Assembly language and the resultant machine code are both examples of procedural languages..
2018/11/16

23. Programming Methods Structured Programming Principles:
Single entry and single exit
Disciplined GOTO branch (procedure call)
The use of structured constructs
Modularization (procedure call)
2018/11/16

24. Programming Methods
Structured Programming introduced by Edsger W. Dijkstra in 1968 uses selection (if/then/else) and repetition (for, while, do…while), block structures, and subroutines with orderly breaks, and procedure calls which allow code to branch and return to the caller, rather than simply jump to arbitrary code never to return. There is much less need for GOTO statements which ultimately makes code that much easier to read and easier to maintain. It is also known as modular programming.
2018/11/16

25. Programming Methods
Object-oriented Programming extends structured programming by combining data and the methods that operate upon that data into a single entity, known as an object. The object fully encapsulates all the functionality required to manipulate its data and exposes a clearly defined interface, hiding the implementation from the programmer. Thus it is only necessary to know what an object does, not how it does it. New objects can be derived from existing objects, reducing the need to duplicate code. It requires much less effort than structured programming.
2018/11/16

26. Functional Testing Techniques
Also known as the "black-box" techniques. Do not require the tester to know the internal logic of a program or system.
Derive the test cases from the requirements definition or the external (design) specification.
Focus on the functions of the program or system being tested.
Available techniques:
Boundary value coverage
Error guessing
Cause-effect graphing
Input equivalence partitioning
Design-based equivalence partitioning
2018/11/16

27. Structural Testing Techniques
Also known as the "white-box" techniques. Require the tester to know the internal logic of a program or system.
Derive the test cases from the program logic in the source code or internal design specification
Focus on the structure of the program or system being tested.
Available techniques:
Statement coverage
Decision coverage (or Branch coverage)
Condition coverage
Decision-and-condition coverage
Multiple-condition coverage
Complexity-based coverage
2018/11/16

28. Management
2018/11/16

29. Function Point?
2018/11/16

30. Cyclomatic Complexity Metric
Cyclomatic complexity metric measures the control-flow complexity of a program.
V(G) = (# edges - # nodes + 2) = (# conditions +1)
If the cyclomatic complexity of a program is N, then at least N distinct independent paths which traverse every edge in the program graph should be tested. Each test path represents a test case.
The program under test must have a single entry and exit.
Essential complexity metric E(G) measures the "unstructuredness" of a program.
E(G) = V(G) - # of proper subgraphs with unique entry & exit
2018/11/16

31. Cyclomatic Complexity Metric
Every structured program has an "essential complexity" of one; it can be reduced to a program of unit complexity. A nonstructured program has an essential complexity of 3 or more.
Actual complexity metric indicates the number of independent paths actually executed by a program running on a test dataset. It should be maintained as close to the cyclomatic complexity as possible.
To maintain the testability of a program, the cyclomatic complexity of a program should be no more than 10.
2018/11/16

32. Your Turn
Given the following control-flow graph, what are the basic test paths based on the complexity-based coverage? 1
V(G) = ? 4 2 3 5
2018/11/16

33. Figure 1: A Control-Flow Graph for the Triangle Program
Accept integers A, B, C
IF A>0 & B>0 & C>0 1 N Y
IF A+B>C & B+C>A & A+C>B 2 N Y
IF A=B N 3 Y 4 5
IF B=C
IF B=C N N Y Y
IF A=C 6 N Y
Not a
triangle
Invalid
input
Scalene
Equilateral
Isosceles
Accept flag R N 7
Repeat until R“Y” Y
2018/11/16

34. Figure 2: Two Other Examples1 1 4 2 2 3 3
V(G1) = 5
V(G2) = 4
2018/11/16

35. Figure 3: A Control-Flow Graph for the Interchange Sort Program
ACCEPT filename
IF not EXIST filename 1 Y N
DO WHILE not EOF 2
EOF
DO CASE n
Read the
entire file 3
FOR i = 2 TO n 4
FOR j = 1 TO i -1
FOR k
= 1 TO n 5 7
File is
empty
File
contains
one
number
IF x(i) <x(j)
Print
a sorted
number 6
File does
not exist Y N
Swap
2018/11/16
END

36. SE Capability Maturity Model
Initial
Defined
Repeatable
Managed
Optimized
Maturity
Software Engineering
2018/11/16

37. Capability Maturity Model (CMM)
CMM is framework of transforming software engineering from an ad hoc and error-prone process to a discipline that is well managed and supported by technology.
The 5-Stage model:
Initial stage
Repeatable stage
Defined stage
Managed stage
Optimizing stage
2018/11/16

38. The CMM Levels
CMM Level
Characteristics
Key process areas
Key challenges
1. Initial
(Ad hoc)
Project chaotic
Ad hoc processes
Project management
Project planning
Configuration management
Software quality assurance
2. Repeatable
(Intuitive)
Process dependent on individuals
Requirements management
Software subcontract management
Software project tracking & oversight
Software project planning
Software configuration management
Training
Technical practices
Process focus
3. Defined
(Qualitative)
Process defined and institutionalized
Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus
Process measurement
Process analysis
Quantitative quality plans
4. Managed
(Quantitative) Measured process
Software quality management
Quantitative process management
Changing technology
Problem analysis
Problem prevention
5. Optimizing
Improvement fed back into process
Process change management
Technology change management
Defect prevention
Still human intensive process
Maintain organization at optimizing level
Source: Adapted from Humphrey, Snyder, and Willis [1991].

39. Maturity Profile of Taiwan Top 1000 Firms
2018/11/16

40. Most and Least Performed Key Practices
Question I.D. and Description
1996 (N=138)
2000 (N=102)
This Study
(N=93)
Most implemented practices
Q1.2.1.
Does each software developer have a private computer-supported workstation/terminal?
92.3%
90.1%
79.57%
-10.53%
Q1.1.2.
Does the project software manager report directly to the project (or project development) manager?
63.8%
51.5%
65.59%
14.11% 2
Q1.1.1.
For each project involving software development, is there a designated software manager?
52.5%
59.14%
6.66%
Q2.1.1.
Does the software organization use a standardized and documented software development process on each project?
72.3%
77.2%
54.84%
-22.39% 3
Q2.1.6.
Are standards used for the content of software development files/folders?
63.1%
63.4%
53.76%*
-9.60%
Least implemented practices:
Q2.2.2.m.
Are profiles of software metrics (size or complexity) maintained over time for each software configuration item?
16.2%
24.8%
25.81% *
1.05% 4
Q2.2.5.
Are design errors projected and compared to actuals?
23.8%
38.6%
26.88% *
-11.73%
Q2.3.8.
Is review efficiency analyzed for each project?
17.7%
17.8%
26.88%
9.06%
Q s.
Are code errors projected and compared to actuals?
19.2%
34.7%
27.96% *
-6.70%
Q2.3.9.
Is software productivity analyzed for major process steps?
30.7%
29.03% *
-1.66%
Level
Difference
Most and Least Performed Key Practices
* This practice was not in the previous list.
2018/11/16

41. Conclusion & Recommendations
Taiwan's business industries have made great strides in the SPM practices since 1996.
Realized the importance of software process in assuring quality and improving productivity. The average percent of achievement has risen from 35.4% to 43.4%, now it is 38.9%. While there were only 21.7% of these companies implemented half or more of the 89 key practices in 1996, 43.6% in 2000, today this percentage is 35.5%.
The effort of Software Industry Productivity Task Force has paid off.
2018/11/16

42. Conclusion & Recommendations
Software engineering curricula of Taiwanese universities should be improved to emphasize software quality and processes management techniques.
Need to institutionalize software complexity metric. Could start with McCabe’s control-flow complexity metric.
Software process management and TQM are two sides of a coin. These are the heart and the soul of a software organization.
2018/11/16

43. Summary
2018/11/16

44. Key Points
Software engineering is an engineering discipline that is concerned with all aspects of software production.
Essential software product attributes are maintainability, dependability and security, efficiency and acceptability.
The high-level activities of specification, development, validation and evolution are part of all software processes.
2018/11/16

45. Key Points
There are many different types of system and each requires appropriate software engineering tools and techniques for their development.
The fundamental ideas of software engineering are applicable to all types of software system.
Source: Ian Sommerville (2010) Software Engineering, 9th ed.
2018/11/16

46. Q & A
2018/11/16

47. Thank you for listening
2018/11/16