1 / 42

Chapter 9 Systems Implementation

Chapter 9 Systems Implementation. Phase Description. Systems Implementation is the fourth of five phases in the systems development life cycle (SDLC)

sparksm
Download Presentation

Chapter 9 Systems Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 9Systems Implementation

  2. Phase Description • Systems Implementation is the fourth of five phases in the systems development life cycle (SDLC) • Includes application development, testing, documentation, training, data conversion, system changeover, and post-implementation evaluation of the results

  3. Introduction • The system design specification serves as a blueprint for constructing the new system • The initial task is application development • Before a changeover can occur, the system must be tested and documented carefully, users must be trained, and existing data must be converted • A formal evaluation of the results takes place as part of a final report to management

  4. Software Quality Assurance • Quality assurance • Software Engineering • Software Engineering Institute (SEI) at Carnegie Mellon University to find better, faster, and less expensive methods of software development • Capability Maturity Model (CMM ) (1991) A set of software development standards to improve software quality, reduce development time and cut costs • Capability Maturity Model Integration (CMMI) Process improvement: Integrates software and systems development into a much larger framework • CMMI tracks an organization's processes, using five maturity layers (p. 417, Fig. 9-3)

  5. Software Quality Assurance • International Organization for Standardization (ISO) • Many firms seek assurance that software systems will meet rigid quality standards • In 1991, ISO established a set of guidelines called ISO 9000-3 • ISO requires a specific development plan, which outlines a step-by-step process for transforming user requirements into a finished product

  6. Overview of Application Development • Application development • Objective is to translate the logical design into program and code modules that will function properly

  7. Overview of Application Development • Application Development Steps • Start by reviewing documentation from prior SDLC phases and creating a set of program designs • Planning(Ch.3-8) • Module: related program code organized into small units that are easy to understand and maintain. • After the design is created, coding can begin

  8. Overview of Application Development • Project Management • Even a modest-sized project might have hundreds or even thousands of modules • Important to set realistic schedules, meet project deadlines, control costs, and maintain quality • Should use project management tools and techniques

  9. Structured Application Development • Top-down approach • Partitioning • Modular design • Integration • Testing

  10. Structured Application Development • Structure Charts • Structure charts: a tool to show the program modules and the relationships among them • Control module: a higher-level module • Subordinate modules: lower-level modules • Library module: reusable code and can be invoked from more than one point in the chart • Example p. 421, Figure 9-7

  11. Structured Application Development • Structure Charts • Data and controls are passed between modules • Data Couple: an empty-circle arrow • Control Couple: a filled-circle arrow • Flag（旗標） • A module uses a flag to signal a specific condition or action to another module

  12. Structured Application Development • Structure Charts • Condition: a line with diamond on one end • A condition line indicates that a control module determines which subordinate modules will be invoked, depending on a specific condition • Loop • A loop indicates that one or more modules are repeated • Example: Figure 9-8, 9-10, 9-11

  13. Structured Application Development • General guidelines for good module design: more cohesive and loosely coupled • Cohesion（內聚） and Coupling（結合） • Cohesion: a module that performs a single function or task has a high degree of cohesion (good) • If you need to make a module more cohesive, you can split it into separate units, each of which performs a single function • Example: p. 422, Figure 9-12 • Coupling: Modules that are independent are loosely coupled (good) • Loosely coupled: easy to maintain • Tightly coupled: hard to maintain • Status flag: an indicator that allows one module to send a message to another module (poor design) Example: p. 423, Figure 9-13

  14. Structured Application Development • Drawing a Structure Chart • Step 1: Review the DFDs • Step 2: Identify Modules and Relationships • Step 3: Add Couples, Loops, and Conditions • Step 4: Analyze the Structure Chart and the Data Dictionary • Example: p. 425-426

  15. Structured Application Development • Other Structured Development Tools • Program Flowcharts • Pseudocode

  16. Coding • Coding • Programming Environments • Each IT department has its own programming environment and standards • Integrated development environments (IDEs): dotNET • Generating Code • CASE can generate editable program code directly from macros, keystrokes, or mouse actions

  17. Testing the System • After coding, a programmer must test each program to make sure that it functions correctly • Syntax errors and Semantic errors • Desk checking • Looking for logic errors • Structured walkthrough, or code review

  18. Testing the System • Unit Testing • The testing of an individual program or module • Programmers must test programs that interact with other programs and files individually • Test data: correct and erroneous data • Stub testing: simulation of each outcome by displaying a message so that it is easier to link with another program later • Regardless of who creates the test plan, the project manager or a designated analyst also reviews the final test results

  19. Testing the System • Integration Testing • Integration testing, or link testing • Testing the programs independently does not guarantee that the data passed between them is correct • A testing sequence should not move to the integration stage unless it has performed properly in all unit tests

  20. Testing the System • System Testing • Aka Acceptance tests • Major objectives: • Perform a final test of all programs • Verify that the system will handle all input data properly, both valid and invalid • Ensure that the IT staff has the documentation and instructions needed to operate the system properly and that backup and restart capabilities of the system are adequate

  21. Testing the System • System Testing • Major objectives: • Demonstrate that users can interact with the system successfully • Verify that all system components are integrated properly and that actual processing situations will be handled correctly • Confirm that the information system can handle predicted volumes of data in a timely and efficient manner

  22. Documentation • Documentation • Program Documentation • System Documentation: data dictionary, DFD,… • Operations Documentation: scheduling info for printed output, etc. • User Documentation • Online documentation, eg. FAQ’s

  23. Management Approval • After system testing is complete, you present the results to management • If system testing produced no technical, economical, or operational problems, management determines a schedule for system installation and evaluation

  24. System Installation and Evaluation • Remaining steps in systems implementation: • Prepare a separate operational and test environment • Provide training for users, managers, and IT staff • Perform data conversion and system changeover • Carry out post-implementation evaluation of the system • Present a final report to management

  25. Operational and Test Environments • The environment for the actual system operation is called the operational environment or production environment • The environment that analysts and programmers use to develop and maintain programs is called the test environment • A separate test environment is necessary to maintain system security and integrity and protect the operational environment

  26. Operational and Test Environments

  27. Training • Training Plan • The first step is to identify who should receive training and what training is needed • The three main groups for training are users, managers, and IT staff • You must determine how the company will provide training

  28. Training • Vendor Training • If the system includes the purchase of software or hardware, then vendor-supplied training is one of the features you should include in the RFPs (requests for proposal) and RFQs (requests for quotation) that you send to potential vendors

  29. Training • Outside Training Resources • Many training consultants, institutes, and firms are available that provide either standardized or customized training packages • You can contact a training provider and obtain references from clients

  30. Training • In-House Training • The IT staff and user departments often share responsibility • When developing a training program, you should keep the following guidelines in mind: • 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 • Prepare effective training materials, including interactive tutorials • Tutorial

  31. Training • In-House Training • When developing a training program, you should keep the following guidelines in mind: • Rely on previous trainees • Train-the-trainer strategy • When Training is complete, many organizations conduct a full-scale test, or simulation

  32. Data Conversion • Data Conversion Strategies • The old system might be capable of exporting data in an acceptable format for the new system or in a standard format such as ASCII or ODBC • If a standard format is not available, you must develop a program to extract the data and convert it • Often requires additional data items, which might require manual entry

  33. Data Conversion • Data Conversion Security and Controls • You must ensure that all system control measures are in place and operational to protect data from unauthorized access and to help prevent erroneous input • Some errors will occur • It is essential that the new system be loaded with accurate, error-free data

  34. System Changeover (p. 448, Fig. 9-37) • Direct Cutover • Involves more risk than other changeover methods • Companies often choose the direct cutover method for implementing commercial software packages • Cyclical(週期性) information systems usually are converted using the direct cutover method at the beginning of a quarter, calendar year, or fiscal year

  35. System Changeover • Parallel Operation • Easier to verify that the new system is working properly under parallel operation than under direct cutover • Running both systems might place a burden on the operating environment and cause processing delay • Is not practical if the old and new systems are incompatible technically • Also is inappropriate when the two systems perform different functions

  36. System Changeover • Pilot Operation • The group that uses the new system first is called the pilot site • The old system continues to operate for the entire organization • After the system proves successful at the pilot site, it is implemented in the rest of the organization, usually using the direct cutover method • Is a combination of parallel operation and direct cutover methods

  37. System Changeover • Phased Operation • You give a part of the system to all users • The risk of errors or failures is limited to the implemented module only • Is less expensive than full parallel operation • Is not possible, however, if the system cannot be separated easily into logical modules or segments

  38. Post-Implementation Tasks • Post-Implementation Evaluation • Includes feedback for the following areas: • Accuracy, completeness, and timeliness of information system output • User satisfaction • System reliability and maintainability • Adequacy of system controls and security measures • Hardware efficiency and platform performance

  39. Post-Implementation Tasks • Post-Implementation Evaluation • Includes feedback for the following areas: • Effectiveness of database implementation • Performance of the IT team • Completeness and quality of documentation • Quality and effectiveness of training • Accuracy of cost-benefit estimates and development schedules

  40. Post-Implementation Tasks • Post-Implementation Evaluation • When evaluating a system, you should: • 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 form a large number of users • Analyze maintenance and help desk logs

  41. Post-Implementation Tasks • Post-Implementation Evaluation • Users can forget details of the developmental effort if too much time elapses • Pressure to finish the project sooner usually results in an earlier evaluation in order to allow the IT department to move on to other tasks

  42. Post-Implementation Tasks • Final Report to Management • Your report should include the following: • 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 • A comparison of actual costs and schedules to the original estimates • Post-implementation evaluation, if it has been performed • Marks the end of systems development work

More Related