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

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

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

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.

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

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.

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 99.99 99 99 8%. When a product is six sigma, it tells us that the quality level is excellent. * Note: Six Sigma is different from ISO

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.

Improvement Efforts Required to Reach Six Sigma 4 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

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.

Figure 1: DMAIC Methodology

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.

Figure 1: DMADV Methodology

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.

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.

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.

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.

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

Figure 16.8 Creating reusable modules

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

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

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

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

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

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

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

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.

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.

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 16.16 Using pseudocode to depict a subscription update service for a newspaper conglomerate

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.

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

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

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

Figure 16.18 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.

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

Testing, Maintenance and Auditing The testing process Maintenance practices Auditing

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

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

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

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.

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.

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.

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

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

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

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

Conclusion Structure charts Control Structure chart modules 01 Structure charts 03 Control 02 Structure chart modules 04 Transformational 03 Documentation 04 Functional

Conclusion Structure charts Structure chart modules Pseudocode 01 Structure charts 02 Structure chart modules 03 Pseudocode 03 Documentation 04 Procedure manuals 04 FOLKLORE

Conclusion 01 Testing 02 System Maintenance 03 Auditing

Thanks for your attention! Have a nice day 65