Systems Analysis and Design 11th Edition Chapter 11 PDF

Systems Analysis and Design 11th Edition Chapter 11 – Managing Systems Implementation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. Chapter Obje...

Systems Analysis and Design 11th Edition Chapter 11 – Managing Systems Implementation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. Chapter Objectives  Explain the importance of software quality assurance and software engineering  Describe application development using structured, object-oriented, and agile methods  Draw a structure chart showing top-down design, modular design, cohesion, and coupling  Explain the coding process  Explain unit, integration, and system testing Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2 Chapter Objectives (Cont.)  Differentiate between program, system, operations, and user documentation  List the main steps in system installation and evaluation  Develop training plans for various user groups, compare in-house and vendor training options, and describe effective training techniques  Describe data conversion and changeover methods  Explain post-implementation evaluation and the final report to management Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3 Software Quality Assurance  Companies are intensely concerned with the quality of their products and services  Objective ◦ To avoid problems or to identify them as soon as possible  Poor quality can result from: ◦ Inaccurate requirements ◦ Design problems and coding errors ◦ Faulty documentation and ineffective testing Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4 Software Quality Assurance (Cont. 1)  Software Engineering ◦ Disciplined application of engineering principles to the creation of complex, long-lived applications ◦ Software Engineering Institute (SEI) at Carnegie Melon University  Provides quality standards and suggested procedures for software developers and systems analysts  Designed the Capability Maturity Model (CMM), which aims to improve software quality, reduce development time, and cut costs Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5  Software Quality Assurance (Cont. 2)  Capability Maturity Model Integration (CMMI): Tracks an organization’s processes, using five maturity levels FIGURE 11-2 The CMM has five maturity levels, from Level 1 (Initial), which is essentially uncontrolled development, to Level 5 (Optimizing), in which process improvement strategies are defined and used. Source: Scott Tilley Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6 Software Quality Assurance (Cont. 3)  International Organization for Standardization (ISO) ◦ Establishes internationally recognized quality standards for products and services ◦ ISO 9000-3:2004  Provides a quality assurance framework for developing and maintaining software ◦ ISO standards can be:  Specified while purchasing software  Used to guide in-house software development efforts FIGURE 11-3 ISO standards include internationally recognized symbols. bytedust/Shutterstock.com Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 7 Overview of Application Development  Application development ◦ Process of constructing the programs and code modules that serve as the building blocks of the information system  Popular development options - Structured analysis, object-oriented (O-O) analysis, and agile methods ◦ Objective - To translate the design into program and code modules that will function properly Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 8 Overview of Application Development (Cont. 1)  Review the Systems Design ◦ Tasks involved in creating systems design  Break down complex business operations using functional decomposition diagrams (FDDs)  Create data flow diagrams (DFDs)  Develop an object-oriented model of the new system  Select a development strategy  Design the user interface  Construct entity-relationship diagrams (ERDs)  Consider an overall system architecture Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9 Overview of Application Development (Cont. 2)  Application Development Tasks ◦ Traditional methods  Overall strategy must be established  Individual modules must be designed, coded, tested, and documented FIGURE 11-4 The main steps in application development. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 10  Overview of Application Development (Cont. 3) ◦ Agile methods  Objective – To create a system through an iterative process of planning, designing, coding, and testing FIGURE 11-5 Simplified model of an Extreme Programming (XP) project. Note the emphasis on iteration and testing. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 11 Overview of Application Development (Cont. 4)  Systems Development Tools ◦ Entity-relationship diagrams - Show the interaction among system entities and objects ◦ Flowcharts: Represent logical rules and interaction graphically ◦ Pseudocode - Helps describe program actions that can be implemented in any programming language ◦ Decision tables and decision trees - Used to model business logic for an information system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 12 Overview of Application Development (Cont. 5) FIGURE 11-6 Sample of a sales promotion policy with logical rules (top) and a pseudocode version of the same policy (bottom). Notice the alignment and indentation of the logic statements in the pseudocode. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 13 Overview of Application Development (Cont. 6)  Project Management ◦ Helps monitor and control development efforts FIGURE 11-7 Sample decision tree that reflects the sales promotion policy in Figure 11-6. Like a decision table, a decision tree shows the action to be taken based on certain properties. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14 Structured Application Development  Structure Charts ◦ Display program modules and the relationships among them ◦ Module - Represented by a rectangle ◦ Types of modules  Control: Higher-level module  Subordinate: Lower-level modules  Library: Reusable code that can be invoked from more than one point in the chart FIGURE 11-8 An example of structure chart modules. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15 Structured Application Development (Cont. 1) ◦ Data couple: Represented by an arrow with an empty circle  Shows data that one module passes to another ◦ Control couple  Represented by an arrow FIGURE 11-9 An with a filled circle example of a  Shows a status flag structure chart data. FIGURE 11-10 An example of a structure chart control couple. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 16 Structured Application Development (Cont. 2) ◦ Condition: Indicates that a control module determines which subordinate modules will be invoked FIGURE 11-11 The diagram shows a control  Represented by a line module that triggers three subordinate modules. with a diamond on one end ◦ Loop: Indicates that one or more modules are repeated  Represented by a curved arrow FIGURE 11-12 The diagram shows a structure chart loop with two repeating modules. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17 Structured Application Development (Cont. 3)  Cohesion and Coupling ◦ Cohesion measures a module’s scope and processing characteristics  A module that performs a single function or task has a high degree of cohesion FIGURE 11-13 Two examples of cohesion. Notice that the single module on the left is less cohesive than the two modules on the right. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 18 Structured Application Development (Cont. 4) ◦ Coupling describes the degree of interdependence among modules  Modules that are independent are loosely coupled  Loosely coupled modules are easier to maintain and modify  In tightly coupled modules, one module is linked to internal logic contained in another module Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 19  Structured Application Development (Cont. 5) FIGURE 11-14 An example of tightly coupled and loosely coupled structure charts. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 20 Structured Application Development (Cont. 6)  Drawing a Structure Chart ◦ Step 1 - Review DFDs for accuracy and completeness ◦ Step 2 - Identify the program modules and determine control-subordinate relationships ◦ Step 3 - Add couples, loops, and conditions ◦ Step 4 - Analyze the structure chart and ensure that it is consistent with all previous documentation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 21  Structured Application Development (Cont. 7) FIGURE 11-15 A structure chart based on the order system DFDs in Chapter 5. The three-level structure chart relates to the three DFD levels. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 22 Object-Oriented Application Development  Characteristics of Object-Oriented Application Development ◦ Individual object instances belong to classes of objects with similar characteristics ◦ The relationship and interaction among classes are described using a class diagram  Class diagrams include class attributes and methods  Object relationship diagrams provide an overview of object interaction Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 23 Object-Oriented Application Development (Cont. 1) FIGURE 11-17 An object-relationship diagram for a fitness center. FIGURE 11-16 A simplified class diagram for a customer order processing system. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 24 Object-Oriented Application Development (Cont. 2)  Implementation of Object-Oriented Designs ◦ Objective - To translate object methods into program code modules and determine what event or message will trigger the execution of each module  Object-Oriented Cohesion and Coupling ◦ Classes should be as loosely coupled as possible ◦ An object’s methods should also be loosely coupled and highly cohesive Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25  Agile Application Development  Uses a highly iterative process  Development team is in constant communication with the primary user (customer)  Based on a quick and nimble development process that easily adapts to change  Focuses on small teams, intense communication, and rapid development iterations Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26  Agile Application Development (Cont. 1) FIGURE 11-19 The five core values of extreme programming (XP). Source: ©2009, Don Wells Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27 Agile Application Development (Cont. 2)  Extreme Programming (XP) ◦ Uses pair programming  Pair programming: Involves two programmers working on the same task on the same computer, where one programs while the other watches ◦ Test-driven development (TDD)  Focuses on end results from the beginning  Prevents programmers from straying from their goals  User Stories ◦ Short, simple requirements definitions  Programmers review user stories to determine the project’s requirements, priorities, and scope Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28 Agile Application Development (Cont. 3)  Iterations and Releases ◦ Release plans are to be developed by teams ◦ User stories are implemented in a series of iteration cycles  An iteration planning meeting is held at the beginning of each cycle  Iteration cycles continue until all user stories have been implemented, tested, and accepted Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29 Agile Application Development (Cont. 4)  The Future of Agile Development Agile methodology is becoming popular for software projects Supporters claim that it speeds up software development and delivers precisely what the customer wants Critics claim that it lacks discipline and produces systems of questionable quality Agile methodology does not work as well for larger projects because of their complexity and the lack of focus on a well-defined end product Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30 Coding  Programming Environments ◦ Examples of commonly used programming languages  Visual Basic, Python, and Java  Web-centric languages - HTML/XML, Java, and Swift ◦ Integrated development environment (IDE) makes it easier to program interactive software products  Generating Code ◦ Application generators and other CASE tools produce code directly from program design specifications ◦ Some commercial applications can generate Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or editable code duplicated, or posted to a publicly accessible website, in whole or in part. 31 Testing The System  Each program is tested to ensure that it functions correctly ◦ Program is compiled using a CASE tool or language compiler, which helps detect syntax errors ◦ Desk checking helps spot logic errors ◦ Organizations require a structured walkthrough or code review  Groups of three to five IT staff members participate  A design walkthrough is held to review the interface along with people who will work with the new system and ensure that all necessary features have been included Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32 Testing The System (Cont. 1)  Unit testing ◦ Testing of an individual program or module ◦ Aims to identify and eliminate:  Execution errors  Logic errors ◦ Test data should contain both accurate and erroneous data FIGURE 11-20 The first step in testing is unit testing, followed by integration testing, and then system testing. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 33 Testing The System (Cont. 2) ◦ Stub testing is required  The programmer:  Simulates each program outcome or result  Displays a message to indicate whether the program has executed successfully  A test plan is created during the systems design phase  Contains details regarding testing procedures  Integration Testing ◦ Testing two or more programs that depend on each other to make sure that the programs work together properly Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34 Testing The System (Cont. 3)  System Testing (Acceptance Tests) ◦ Objectives  Perform a final test of all programs  Verify that the system will handle all data properly  Ensure that the IT staff has the documentation and instructions needed to operate the system properly  Demonstrate that users can interact with the system successfully  Verify that all system components are integrated properly  Confirm that the information system can handle predicted volumes of data in a timely and efficient manner Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35 Documentation  Program Documentation ◦ Describes the inputs, outputs, and processing logic for all program modules ◦ Process starts in the systems analysis phase and continues during systems implementation ◦ Overall documentation is prepared early in the SDLC ◦ Defect tracking software or bug tracking software  Used to document and track program defects, code changes, and patches Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36 Documentation (Cont. 1)  System Documentation ◦ Describes the system’s functions and how they are implemented  Operations Documentation ◦ Contains the information needed for processing and distributing online and printed output  User Documentation ◦ Consists of instructions and information for users who will interact with the system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 37 Documentation (Cont. 2)  Online Documentation ◦ Provides immediate help when users have questions or encounter problems FIGURE 11-23 The Cisco Support Community invites users to contribute valuable experience and documentation using social media. Source: Cisco Support Community Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 38  Documentation (Cont. 3) FIGURE 11-24 A sample page from a user manual. The instructions explain how to add a new task to the system. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 39 Management Approval  After system testing is complete, the results are presented to the management ◦ Test results should be described ◦ Status of all required documentation should be updated ◦ Input from users who participated in system testing should be summarized ◦ Detailed time schedules, cost estimates, and staffing requirements for making the system fully operational should be provided Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 40 System Installation and Evaluation  Prepare a separate operational and test environment  Provide training for users, managers, and IT staff  Perform data conversion and system changeover  Carry out a post-implementation evaluation of the system  Present a final report to management Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 41 Operational and Test Environments  Operational or production environment ◦ Environment for the actual system operation  Test environment ◦ Environment that analysts and programmers use to develop and maintain programs ◦ A separate test environment is necessary to maintain system security and integrity and protect the operational environment Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 42 Operational and Test Environments (Cont.) FIGURE 11-25 The test environment versus the operational environment. Notice that access to the test environment is limited to IT staff, while the operational environment is restricted to users. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 43 Training  Training Plan ◦ Identify who should receive training and what training is required  Organization should be observed carefully to determine how the system will support business operations, and who will be involved or affected ◦ Main groups for training  Users  Managers  IT staff Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 44  Training (Cont. 1) FIGURE 11-26 Examples of training topics for three different groups. Users, managers, and IT staff members have different training needs. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 45 Training (Cont. 2)  Vendor Training ◦ Required if the system includes the purchase of hardware or software  Scope is limited to a standard version of the vendor’s software or hardware  Webinars, Podcasts, and Tutorials ◦ Web-based training options  Outside Training ◦ Viable alternative if vendor training is not practical Figure 11-27 Udemy is one of many sources of online training. Source: Udemy.com Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 46 Training (Cont. 3)  Training Tips ◦ Train people in groups, with separate training programs for distinct groups ◦ Select the most effective place to conduct the training ◦ Provide for learning by hearing, seeing, and doing ◦ Rely on previous trainees  Interactive Training ◦ Effective training is interactive, self-paced, and multimedia-based Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 47 Training (Cont. 4) ◦ Online training  Effective when it is more realistic  Sophisticated training systems offer interactive sessions  Training material should include a reference section that summarizes all options and commands, lists all possible error messages, and what actions the user should take when a problem arises  A full-scale test, or simulation must be conducted after the training is complete Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 48  Training (Cont. 5) FIGURE 11-29 A sample lesson on Android app development in an online tutorial from lynda.com. Source: lynda.com, Inc. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 49 Data Conversion  Process in which existing data is loaded on to a new system  Data Conversion Strategies ◦ Automate the data conversion process if possible ◦ Old systems may be able to export data in ASCII or ODBC (Open Database Connectivity) formats  ODBC drivers are a form of middleware ◦ If a standard format is not available, develop a program to extract the data and convert it to an acceptable format Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 50 Data Conversion (Cont.)  Data Conversion Security and Controls ◦ Maintain strict input controls during the conversion process ◦ Ensure that all system control measures are in place and operational to protect data from unauthorized access and to help prevent erroneous input ◦ Ensure that error-free data is fed into the new system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 51 System Changeover  Process of putting the new information system online and retiring the old system  Can be rapid or slow, depending on the method  Types ◦ Direct cutover ◦ Parallel operation ◦ Pilot operation ◦ Phased operation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 52 System Changeover (Cont. 1)  Direct Cutover ◦ Enables changeover when the new system becomes operational ◦ Least expensive changeover method  IT group has to operate and maintain only one system at a time FIGURE 11-30 The four system changeover methods. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 53 System Changeover (Cont. 2)  Parallel Operation ◦ Both the old and the new information systems operate fully for a specified period ◦ Advantage - Lower level of risk  The old system can be used as a backup ◦ Not practical if the old and new systems are incompatible FIGURE 11-30 The four system changeover methods. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 54 System Changeover (Cont. 3)  Pilot Operation ◦ Implements the complete new system at a selected location of the company ◦ Pilot site: Group that uses the new system first ◦ Reduces the risk of system failure ◦ Less expensive than a parallel operation FIGURE 11-30 The four system changeover methods. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 55 System Changeover (Cont. 4)  Phased Operation ◦ Implements the new system in stages, or modules ◦ Combines direct cutover and parallel operation to reduce risks and costs  Only a part of the system is given to all users ◦ Risk of errors or failures is limited to the implemented module only ◦ Less expensive than full parallel operation FIGURE 11-30 The four system changeover methods. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 56 System Changeover (Cont. 5) FIGURE 11-31 Relative risk and cost characteristics of the four changeover methods. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 57 Post Implementation Tasks  Post-Implementation Evaluation ◦ Assesses the overall quality of the information system ◦ Includes feedback for the following areas:  Accuracy, completeness, timeliness of information system output, and user satisfaction  System reliability and maintainability  Adequacy of system controls and security measures  Hardware efficiency and platform performance  Effectiveness of database implementation  Performance of the IT team  Completeness and quality of documentation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 58 Post Implementation Tasks (Cont. 1)  Quality and effectiveness of training  Accuracy of cost-benefit estimates and development schedules ◦ When evaluating a system:  Interview members of management and key users  Observe users and computer operations personnel actually working with the new information system  Read all documentation and training materials  Examine all source documents, output reports, and screen displays  Use questionnaires to gather information and opinions from a large number of users  Analyze maintenance and help desk logs Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 59  Post Implementation Tasks (Cont. 2) FIGURE 11-32 Sample user evaluation form. The numerical scale allows easy tabulation of results. Following this section, the form provides space for open- ended comments and suggestions. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 60 Post Implementation Tasks (Cont. 3)  Final Report to Management ◦ Submitted at the end of the SDLC phase ◦ Includes:  Final versions of all system documentation  Planned modifications and enhancements to the system that have been identified  Recap of all systems development costs and schedules  Comparison of actual costs and schedules to the original estimates  Post-implementation evaluation, if it has been performed Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 61 Chapter Summary  Systems implementation phase consists of application development, testing, installation, and evaluation of the new system  Each systems development approach has its own set of tools  System developers can use more generic tools to help them translate the system logic into properly functioning program modules Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 62 Chapter Summary (Cont. 1)  In agile development, the customer creates user stories describing required features and priority levels  Cohesion measures a module’s scope and processing characteristics  Coupling measures relationships and interdependence among modules  There are four steps used to create a structure chart Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 63 Chapter Summary (Cont. 2)  Programmers perform desk checking, code review, and unit testing tasks during application development  In addition to system documentation, analysts and technical writers also prepare operations documentation and user documentation  During the installation process, an operational environment for the new information system is established separate from the test environment Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 64 Chapter Summary (Cont. 3)  Everyone who interacts with the new information system should receive training appropriate to their skills  Data conversion often is necessary when installing a new information system  System changeover is the process of putting the new system into operation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 65 Chapter Summary (Cont. 4)  A post-implementation evaluation assesses and reports on the quality of the new system and the work done by the project team  The final report to management includes the final system documentation, describes any future system enhancements that already have been identified, and details the project costs Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 66