Bài giảng Systems Analysis and Design - Chapter 16: Quality Assurance Through Software Engineering

Quality AssuranceThrough Software EngineeringSystems Analysis and Design, 7eKendall & Kendall16© 2008 Pearson Prentice HallLearning ObjectivesRecognize the importance of users and analysts taking a total quality approach to the entire SDLCCreate structure charts to design modular, top-down systemsUse a variety of techniques to improve the quality of software design and maintenanceUnderstand the importance of running a variety of tests during systems development to identify unknown problems2Approaches to Quality AssuranceSecuring total quality assurance through designing systems and software with a top-down and modular approachDocumenting software with appropriate toolsTesting, maintaining, and auditing software3Major TopicsSix SigmaQuality assuranceWalkthroughsStructure chartsModulesData and control passingDocumentationTesting4Six SigmaA culture built on qualityUses a top-down approachProject leader is called a Black BeltProject members are called Green BeltsMaster Black Belts have worked on many projects and are available as a resource to project teams5Figure 16.1 Every systems analyst should understand the methodology and philosophy of Six Sigma6Responsibility for Total Quality ManagementFull organizational support of management must existEarly commitment to quality from the analyst and business users7Structured WalkthroughsOne of the strongest quality management actions is to do structured walkthroughs routinelyUse peer reviewers to monitor the system's programming and overall developmentPoint out problemsAllow the programmer or analyst to make suitable changes8Involved in Structured WalkthroughsThe person responsible for the part of the system being reviewedA walkthrough coordinatorA programmer or analyst peerA peer who takes notes about suggestions9Systems Design and DevelopmentBottom-upTop-downModular10Bottom-Up DesignIdentifying the processes that need computerization as they ariseAnalyzing them as systemsEither coding or purchasing packaged software to meet the immediate problem11Disadvantages of a Bottom-Up ApproachThere is a duplication of effort in purchasing software, and entering dataWorthless data are entered into the systemOverall organizational objectives are not considered and hence cannot be met12The Top-Down ApproachTop-down design allows the systems analyst to ascertain overall organizational objectives and how they are best met in an overall systemThe system is divided into subsystems and their requirements13Figure 16.3 Using the top-down approach to first ascertain overall organizational objectives14Advantages of the Top-Down ApproachAvoiding the chaos of attempting to design a system all at onceEnables separate systems analysis teams to work in parallel on different but necessary subsystemsPrevents losing sight of what the system is suppose to do15Disadvantages of the Top-Down ApproachThere is a danger that the system will be divided into the wrong subsystemsOnce subsystem divisions are made, their interfaces may be neglected or ignoredThe subsystems must be eventually reintegrated 16Modular DevelopmentBreaking the programming into logical, manageable portions or modulesWorks well with top-down designEach individual module should be functionally cohesive, accomplishing only one function17Advantages of Modular ProgrammingModules are easier to write and debugModules are easier to maintainModules are easier to grasp because they are self-contained subsystems18Guidelines for Modular ProgrammingKeep each module to a manageable sizePay particular attention to the critical interfacesMinimize the number of modules the user must modify when making changesMaintain the hierarchical relationships set up in the top-down phases19Modularity 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) filesObject Linking and Embedding (OLE) ties in application data and graphics20Using Structure Charts to Design SystemsThe recommended tool for designing a modular, top-down system is a structure chartA structure chart is simply a diagram consisting of rectangular boxes, representing the modules, and connecting lines21Figure 16.4 A structure diagram encourages top-down design using modules22Data Couples and Control FlagsThe fewer control flags and data couples in the system, the easier it is to change the systemControl flags govern which portion of a module is to be executed and associated with IFTHENELSEand other similar statementsData coupling is when only data required is passed through the data coupleStamp coupling is when excessive data is passed through the data couple23Figure 16.8 Creating reusable modules24Figure 16.9 The loop and diamond are two symbols that indicate special action in a structure chart25Drawing a Structure ChartA data flow diagram may be used to create a structure chart Indicates the sequence of the modulesIndicates modules subordinate to a higher module26Types of ModulesControl modules Transformational modulesFunctional modules27Control ModulesFound near the top of the structure chart and contain the logic for performing the lower-level modulesMay or may not be represented on the data flow diagramUsually contains IF, Perform, and DO statementsShould not be very large in size28Transformational ModulesCreated from a data flow diagramUsually perform only one taskHave mixed statements, IF and PERFORM or DO statements and many detailed statements such as MOVE and ADD29Functional ModulesPerform only one taskThe easiest to code, debug, and maintain30Figure 16-13 A structure chart for adding hotel guest reservations online31Module SubordinationA subordinate module is one lower on the structure chart called by another module higher in the structureAllowing a lower-level module to perform a task not required by the calling module is called improper subordination32Software Engineering and DocumentationThe total quality assurance effort requires that programs be documented properlyDocumentationAllows you to “see” the system without having to interact with itProvides an overview of the system itselfShortens time to perform maintenance33System DocumentationPseudocodeProcedure manualsThe FOLKLORE method34PseudocodeSimilar to structured EnglishIt is not a particular type of programming code, but it can be used as an intermediate step for developing program code35Figure 16.16 Using pseudocode to depict a subscription update service for a newspaper conglomerate36Procedure ManualsThe English-language component of documentationKey sectionsIntroductionHow to use the softwareWhat to do if things go wrongA technical reference sectionAn indexInformation on how to contact the manufacturer37Procedure Manuals (Continued)Procedure manual complaints They are poorly organizedIt is hard to find needed informationThe specific case in question does not appear in the manualThe manual is not written in plain English38Web DocumentationFAQ (Frequently Asked Questions)Help desksTechnical supportFax-back servicesDownloading updates39The FOLKLORE MethodCollects information in the categoriesCustomsTalesSayingsArt forms40Figure 16.18 Customs, tales, sayings, and art forms used in the FOLKLORE method of documentation apply to information systems41Choosing a Design and Documentation TechniqueIs it compatible with existing documentationIs it understood by others in the organizationDoes it allow you to return to working on the system after you have been away from it for a period of time42Choosing a Design and Documentation Technique (Continued)Is it suitable for the size of the system you are working onDoes it allow for a structured design approach if that is considered to be more important than other factorsDoes it allow for easy modification43Testing, Maintenance, and AuditingThe testing processMaintenance practicesAuditing44The Testing ProcessProgram testing with test dataLink testing with test dataFull system testing with test dataFull system testing with live data45Figure 16.19 Programmers, analysts, operators, and users all play different roles in testing software and systems46Program Testing with Test DataDesk check programsTest with both valid and invalid dataCheck output for errors and make any needed corrections47Link Testing with Test DataAlso referred to as string testingChecks to see if programs that are interdependent actually work together as plannedTest for normal transactionsTest with invalid data48Full System Testing with Test DataAdequate documentation in procedure manualsAre procedure manuals clear enoughDo work flows actually “flow”Is output correct and do users understand this output49Full System Testing with Live DataComparison of the new system’s output with what you know to be correctly processed outputOnly small amounts of live data are used50Maintenance PracticesReduce maintenance costsImprove the existing softwareUpdate software in response to the changing organizationEnsure channels for feedbackClassification scheme51AuditingHaving an expert who is not involved in setting up or using the system examine information in order to ascertain its reliabilityThere are internal and external auditorsInternal auditors study the controls used in the information system to make sure that they are adequateExternal auditors are used when the information system processes data that influences a company’s financial statements52SummaryTQMDesigning systems and software with a top-down, modular approachDesigning and documenting systems and software using systematic methodsTesting systems and software so that they can be easily maintained and audited53Summary (Continued)Six Sigma Define the problemObserve the problemAnalyze the causesAct on the causesStudy the resultsStandardize the changesDraw conclusions 54Summary (Continued)Structure chartsStructure chart modulesControlTransformationalFunctionalDocumentationPseudocodeProcedure manualsFOLKLORE55Summary (Continued)TestingSystem MaintenanceAuditing56