1. QUALITY ASSURANCE THROUGH SOFTWARE ENGINEERING
Systems Analysis and Design, 7e
Kendall & Kendall

2. Lecturer: Nguyễn Thanh Tùng
Team Member
Lecturer: Nguyễn Thanh Tùng
Nhữ Đình Toàn
Nguyễn Khánh Công
Huỳnh Thanh Phúc
Nguyễn Hồng Kỳ
Huỳnh Hồng Hiển
Nguyễn Thị Thùy Linh

3. Learning Objectives
Recognize the importance of users and analysts taking a total quality approach to the entire SDLC
Create structure charts to design modular, top-down systems
Use a variety of techniques to improve the quality of software design and maintenance
Understand the importance of running a variety of tests during systems development to identify unknown problems

4. Approaches to Quality Assurance
Securing total quality assurance through designing systems and software with a top-down and modular approach
Documenting software with appropriate tools
Testing, maintaining, and auditing software
Two thought guide quality assurance:
The user of the information system is the single most important factor in establishing and evaluating its quality.
It is far less costly to correct problems in their early stages than it is to wait until a problem is articulated through user complaints or crises.

5. 6. Data and control passing
Major Topics
8. Testing
6. Data and control passing
4. Structure charts
2. Quality Assurance
7. Documentation
5. Modules
3. Walkthroughs
1. Six Sigma

7. What is Six Sigma?
- Sigma is the Greek letter “” that represents the “standard deviation” . Six Sigma is a reference to a particular goal of reducing defects to near zero.
- Six Sigma's aim is to eliminate waste and inefficiency, thereby increasing customer satisfaction by delivering what the customer is expecting.
- Six Sigma follows a structured methodology, and has defined roles for the participants.

8. What Else is Six Sigma?
A concept that provides a relatively new way to measure how good a product is. It relates to a manufacturing or service failure rate of only 3.4 rejects per million operations, or a yield of %.
When a product is six sigma, it tells us that the quality level is excellent.
* Note: Six Sigma is different from ISO

9. Six Sigma A culture built on quality Uses a top-down approach
Project leader is called a Black Belt
Project members are called Green Belts
Master Black Belts have worked on many projects and are available as a resource to project teams
Total quality management (TQM) is essential throughout all the systems development steps.
(Top-down − This approach is generally tied to business strategy and is aligned with customer needs. The major weakness is they are too broad in scope to be completed in a timely manner (most six sigma projects are expected to be completed in 3-6 months).
The concept of quality has broadened over the years to reflect an organizational, rather than an exclusively production, approach.
The goal of six sigma is to eliminate all defects.
Six sigma is a methodology, a philosophy and a culture.

10. Improvement Efforts Required to Reach Six Sigma4 3
10 X Improvement
66,810 dpm
6,210 dpm 5
30 X Improvement
223 dpm 6
70 X Improvement
3.4 dpm
Dpm = defects per million

11. Six Sigma - Methodology
DMAIC − It refers to a data-driven quality strategy for improving processes. This methodology is used to improve an existing business process.
DMADV − It refers to a data-driven quality strategy for designing products & processes. This methodology is used to create new product designs or process designs in such a way that it results in a more predictable, mature and defect free performance.

12. Figure 1: DMAIC Methodology

13. DMAIC Methodology DMAIC consists of 5 steps:
Define --> Measure --> Analyze --> Improve -->Control
Define − Define the problem or project goal that needs to be addressed.
Measure − Measure the problem and process from which it was produced.
Analyze − Analyze data and process to determine root causes of defects and opportunities.
Improve − Improve the process by finding solutions to fix, diminish, and prevent future problems.
Control − Implement, control, and sustain the improvements solutions to keep the process on the new course.

14. Figure 1: DMADV Methodology

15. DMADV Methodology DMADV consists of 5 steps:
Define --> Measure --> Analyze --> Design -->Verify
Define − Define the Problem or Project Goal that needs to be addressed.
Measure − Measure and determine customers needs and specifications.
Analyze − Analyze the process to meet the customer needs.
Design − Design a process that will meet customers needs.
Verify − Verify the design performance and ability to meet customer needs.

16. Responsibility for Total Quality Management
Full organizational support of management must exist
Early commitment to quality from the analyst and business users
Full organizational support of management must exist – means establishing a context for management people to consider seriously how the quality of information systems and information itself affects their work.
achieved by providing on-the-job time for IS quality circles, which consist of six to eight organizational peers specifically charged with considering both how to improve information systems and how to implement improvements.
Early commitment to quality from the analyst and business users – results in an evenly paced effort toward quality throughout the systems development life cycle.
Getting the users involved in spelling out quality standards for information systems will help the analyst avoid expensive mistakes in unwanted or unnecessary systems development.

17. Structured Walkthroughs
One of the strongest quality management actions is to do structured walkthroughs routinely
Use peer reviewers to monitor the system's programming and overall development
Point out problems
Allow the programmer or analyst to make suitable changes
The point of the structured walkthrough is to evaluate the product systematically on an ongoing basis.

18. Involved in Structured Walkthroughs
The person responsible for the part of the system being reviewed
A walkthrough coordinator
A programmer or analyst peer
A peer who takes notes about suggestions
Structured walkthroughs involve at least four people.
Coordinator – ensures that the others adhere to any roles assigned to them and to ensure that any activities scheduled are accomplished.
Programmer or analyst – there to listen.
Programmer or analyst peer – present to point out errors or potential problems.
Notetaker – records what is said so that the others present can interact without encumbrance.

19. Systems Design and Development
Bottom-Up Design
The Top-Down Approach
Modular Development
Designed by freepik

20. Bottom-Up Design
Identifying the processes that need computerization as they arise
Analyzing them as systems
Either coding or purchasing packaged software to meet the immediate problem

21. Bottom-Up Design There is a duplication of effort in
Disadvantages
There is a duplication of effort in
purchasing software, and entering data
Designed by freepik
Worthless data are entered into the system
Overall organizational objectives are not
considered and hence cannot be met
Designed by freepik

22. The Top-Down Approach
Organizational Objectives Level
Top-down design allows the systems analyst to ascertain overall organizational objectives and how they are best met in an overall system
The system is divided into subsystems and their requirements
Functional Systems Level
Operational Systems Level
The top-down approach means looking at the large picture of the system and then exploding it into smaller parts or subsystems.
Allows the analyst to ascertain overall organizational objectives first, as well as to ascertain how they are best met in an overall system.
Program Module Level
Designed by freepik

23. The Top-Down Approach
Figure 16.3 Using the top-down approach to first ascertain overall organizational objectives
The top-down approach means looking at the large picture of the system and then exploding it into smaller parts or subsystems.
Allows the analyst to ascertain overall organizational objectives first, as well as to ascertain how they are best met in an overall system.

24. Advantages of the Top-Down Approach
Avoiding the chaos of attempting to design a system all at once
Enables separate systems analysis teams to work in parallel on different but necessary subsystems
Avoiding the chaos of attempting to design a system all at once – attempting to get all subsystems in place and running at once is agreeing to fail.
Enables separate systems analysis teams to work in parallel on different but necessary subsystems – can save time.
Prevents losing sight of what the system is suppose to do

25. Disadvantages of the Top-Down Approach
There is a danger that the system will be divided into the wrong subsystems
Once subsystem divisions are made, their interfaces may be neglected or ignored
There is a danger that the system will be divided into the wrong subsystems – each subsystem needs to address the correct problem.
Once subsystem divisions are made, their interfaces may be neglected or ignored – responsibility for interfaces needs to be detailed
The subsystems must be eventually reintegrated – mechanisms for reintegration need to be put in place at the beginning.
The subsystems must be eventually reintegrated

26. Modular Development
Breaking the programming into logical, manageable portions or modules
Works well with top-down design
This kind of programming works well with top-down design because it emphasizes the interfaces between modules and does not neglect them until later in systems development.
Each individual module should be functionally cohesive, accomplishing only one function

27. Advantages of Modular Programming
Modular Development
Advantages of Modular Programming
Designed by freepik
Modules are easier to write and debug
Modules are easier to maintain
Modules are easier to grasp because they are self-contained subsystems
Modules are easier to write and debug –
Tracing an error in a module is less complicated.
A problem in one module should not cause problems in others.
Modules are easier to maintain – modifications will usually be limited to a few modules and will not be spread over an entire program.
Modules are easier to grasp because they are self-contained subsystems – a reader can pick up a code listing and understand its function.

28. Modular Development Step I Step II Step III Step IV
Guidelines for Modular Programming
Keep each module to a manageable size
Step I
Pay particular attention to the critical interfaces
Step II
Minimize the number of modules the user must modify when making changes
Step III
Maintain the hierarchical relationships set up in the top-down phases
Step IV

29. Modularity in the Windows Environment
Modular Development
Modularity in the Windows Environment
There are two systems to link programs in Microsoft Windows:
Dynamic Data Exchange (DDE) shares code by using Dynamic Link Library (DLL) files
DDE uses a cut-and-paste approach to linking data and does not retain formatting.
The DDL link can be set up so that whenever the client opens the file, the data are automatically updated.
OLE retains all the properties of the originally created data. Allows the end user to remain in the client application and still edit the original data in the sever application.
Object Linking and Embedding (OLE) ties in application data and graphics
Designed by freepik

30. Using Structure Charts to Design Systems
The recommended tool for designing a modular, top-down system is a structure chart
A structure chart is simply a diagram consisting of rectangular boxes, representing the modules, and connecting lines

31. Figure 16.4 A structure diagram encourages top-down design using modules

32. Data Couples and Control Flags
The fewer control flags and data couples in the system, the easier it is to change the system
Control flags govern which portion of a module is to be executed and associated with IF…THEN…ELSE…and other similar statements
Data coupling is when only data required is passed through the data couple
Stamp coupling is when excessive data is passed through the data couple

33. Figure 16.8 Creating reusable modules

34. Figure 16.9 The loop and diamond are two symbols that indicate special action in a structure chart

35. Drawing a Structure Chart
A data flow diagram may be used to create a structure chart
Indicates the sequence of the modules
Indicates modules subordinate to a higher module

36. Type of modules There are 3 types of modules: Control modules
Transformational modules
Functional modules

37. Control Modules
Found near the top of the structure chart and contain the logic for performing the lower-level modules
May or may not be represented on the data flow diagram
Usually contains IF, Perform, and DO statements
Should not be very large in size

38. Transformational Modules
Created from a data flow diagram
Usually perform only one task
Have mixed statements, IF and PERFORM or DO statements and many detailed statements such as MOVE and ADD

39. Functional Modules Perform only one task
The easiest to code, debug, and maintain

40. Module Subordination
A subordinate module is one lower on the structure chart called by another module higher in the structure
Allowing a lower-level module to perform a task not required by the calling module is called improper subordination

42. Software Engineering and Documentation
The total quality assurance effort requires
that programs be documented properly
Documentation
Allows you to “see” the system without having to interact with it.
Provides an overview of the system itself.
Shortens time to perform maintenance.

43. Software Documentation
Pseudocode
Procedure manuals
The FOLKLORE method
There is no single standard design and documentation technique in use today. Each technique has its own advantages and disadvantages, because each one has unique properties.

44. Pseudocode Similar to structured English
It is not a particular type of programming code, but it can be used as an intermediate step for developing program code
Figure Using pseudocode to depict a subscription update service for a newspaper conglomerate

45. Procedure Manuals The English-language component of documentation
Key sections
Introduction
How to use the software
What to do if things go wrong
A technical reference section
An index
Information on how to contact the
manufacturer
Procedure Manuals – may also contain program codes, flowcharts, and so on.
intended to communicate to those who use them.

46. Procedure Manuals (Continued)
Procedure Manuals complaints
They are poorly organized
It is hard to find needed information
The specific case in question does not appear in the manual
The manual is not written in plain English

47. Web Documentation 1 2 3 4 5 FAQ (Frequently Asked Questions)
Help Desks 3
Technical Support 4
Fax-back Services 5
Downloading Updates

48. Collect information in the categories
The FOLKLORE Method
Collect information in the categories
Customs
Sayings C S F T
Created to supplement other document techniques.
FORKLORE gathers information that is often shared among users but is seldom written down.
Customs – tries to capture in writing what users are currently doing to get all programs to run without problems.
Tales – stories that users tell regarding how the system worked.
Sayings – brief statements representing generalizations or advice.
Art forms – flowcharts, diagrams, and tables that users draw sometimes may be more useful than flowcharts drawn by the original system author.
Art Forms
Tales

49. Figure Customs, tales, sayings, and art forms used in the FOLKLORE method of documentation apply to information systems
The danger of relying on FOLKLORE is that the information gathered from users may be correct, partially correct, or incorrect.

50. Choosing a Design and Documentation Technique
Is it suitable for the size of
the system you are working on
Is it compatible with existing documentation
Does it allow for
easy modification
Is it understood by others in the organization
Does it allow you to return to working on
the system after you have been away from
it for a period of time
Does it allow for a structured design approach
if that is considered to be more important
than other factors

51. Testing, Maintenance and Auditing
The testing process
Maintenance practices
Auditing

52. The Testing Process Program testing with test data
Link testing with test data
Full system testing with test data
Full system testing with live data

53. Programmers, analysts, operators and users all play different roles in testing software and systems.

54. Program Testing with Test Data
Desk check programs.
Test with both valid and invalid data.
Check output for error and make any needed corrections.

55. Link Testing with Test Data
Also referred to as string testing.
Checks to see if program that are interdependent actually work together as planned.
Test for normal transactions.
Test with invalid data.

56. Full System Testing with Test Data
Adequate documentation in procedure manuals.
Are procedure manuals clear enough.
Do work flows actually “flow”.
Is output correct and do users understand this output.

57. Full System Testing with Live Data
Comparison of the new system’s output with what you know to be correctly processed output.
Only small amounts of live data are used.

58. Maintenance Practices
Reduce maintenance costs.
Improve the existing software.
Update software in response to the changing organization.
Ensure channels for feedback.
Classification scheme.

59. Auditing
Having an expert who is not involved in setting up or using the system examine information in order to ascertain its reliability.
There are internal and external auditors.
Internal auditors study the controls used in the information system to make sure that they are adequate.
External auditors are used when the information system processes data that influences a company’s financial statements

60. Total Quality Management
Conclusion
Total Quality Management
Designing systems and software with a top-down, modular approach 01
Designing and documenting systems and software using systematic methods 02
Testing systems and software so that they can be easily maintained and audited 03

61. Conclusion Define the problem Study the results Observe the problem
Six Sigma 01
Define the problem 05
Study the results 02
Observe the problem 06
Standardize the changes 03
Analyze the causes
Draw conclusions 07 04
Act on the causes

62. Conclusion Structure charts Control Structure chart modules01
Structure charts 03
Control 02
Structure chart modules 04
Transformational 03
Documentation 04
Functional

63. Conclusion Structure charts Structure chart modules Pseudocode01
Structure charts 02
Structure chart modules 03
Pseudocode 03
Documentation 04
Procedure manuals 04
FOLKLORE

64. Conclusion 01
Testing 02
System Maintenance 03
Auditing

65. Thanks for your attention!
Have a nice day 65