610 likes | 739 Views
Systems Implementation. Chapter 9. Phase Description. Systems Implementation is the fourth of five phases in the systems development life cycle (SDLC) Includes application development, testing, installation, and evaluation
E N D
Systems Implementation Chapter 9
Phase Description • Systems Implementation is the fourth of five phases in the systems development life cycle (SDLC) • Includes application development, testing, installation, and evaluation • Users will be working with the system on a day-to-day basis, and you will focus on system operation and support, which is the final phase in the SDLC
Chapter Objectives • Explain the importance of software quality assurance and software engineering • Describe the application development process • Draw a structure chart showing top-down design, modular design, cohesion, and coupling • Explain the coding process and how code is generated • Explain unit testing, integration testing, and system testing
Chapter Objectives • Differentiate between program, system, operations, and user documentation • List the main steps in system installation and evaluation • Develop an overall training plan with specific objectives for each group of participants, compare in-house and outside training providers, and describe effective training techniques
Chapter Objectives • Describe the data conversion process • Identify and describe changeover methods • Explain post-implementation evaluation • Describe the final report to management
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
Software Quality Assurance • In today’s competitive business environment, companies are intensely concerned with the quality of their products and services • Rigorous testing catches errors in the implementation stage, but it is much less expensive to correct mistakes earlier in the development process • The main objective of quality assurance is to avoid problems or to detect them as soon as possible
Software Quality Assurance • Software Engineering • The Software Engineering Institute (SEI) at Carnegie Mellon University is a leader in software engineering • SEI designed a Capability Maturity Model (CMM) • International Organization for Standardization (ISO) • 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
Application Development • Application development is the process of constructing the programs and code modules that are the building blocks of the information system • Your first step in application development is to review carefully all existing documentation
Application Development • Documentation Review • You will need solid documentation from prior SDLC phases to design programs and code modules • Using the system documentation as a blueprint, you will develop structure charts that break the system into smaller pieces that programmers can translate into programs and modules
Application Development • Program Design • Must view the system as a series of interactive modules • Top-down design – partitioning – modular design • Use project management software • Structure Charts • Structure charts show the program modules and the relationships among them • Control module • Subordinate modules
Application Development • Structure Charts • Module • Library module • Data Couple • Control Couple • Flag • A module uses a flag to signal a specific condition or action to another module
Application Development • Structure Charts • Condition • 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
Application Development • Cohesion and Coupling • If you need to make a module more cohesive, you can split it into separate units, each of which performs a single function • Loosely coupled • Tightly coupled • Passing status flags down from a control module generally is regarded as poor design
Application Development • Structure Chart Examples
Application Development • Steps in Drawing a Structure Chart • Step 1: Review the DFDs and Object Models • Check for accuracy and completeness • Step 2: Identify Modules and Relationships • You work your way down from the context diagram to the lower-level diagrams, identifying control modules and subordinate modules, until you reach functional primitives • Step 3: Add Couples, Loops, and Conditions • Identify the data elements that pass from one module to another • Step 4: Analyze the Structure Chart, the DFDs, and the Data Dictionary • Ensure that the chart reflects all previous documentation and that the logic is correct
Application Development • Other Application Development Tools • Program Flowcharts • Program flowcharts graphically represent the logic and interaction between program modules • Pseudocode • Is not language-specific, so you can use it to describe a software module in plain English without requiring strict syntax rules
Coding • Programming Environments • Each IT departments has its own programming environment and standards • Generating Code • Use application generators, report writers, screen generators, fourth-generation languages, and other CASE tools • Can generate editable program code directly from macros, keystrokes, or mouse actions
Testing the System • After coding, a programmer must test each program to make sure that it functions correctly • Syntax errors • Desk checking • Structured walkthrough, or code review • Design walkthrough
Testing the System • Unit Testing • Test data should contain both correct data and erroneous data and should test all possible situations that could occur • Programmers must test programs that interact with other programs and files individually • Stub testing • Regardless of who creates the test plan, the project manager or a designated analyst also reviews the final test results
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 • Integration test data must consider both normal and unusual situations • A testing sequence should not move to the integration stage unless it has performed properly in all unit tests
Testing the System • System Testing • Major objectives: • Perform a final test of all programs • 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 • 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
Testing the System • System Testing • Acceptance tests • You should regard thorough testing as a cost-effective means of providing a quality product • If conflicting views exist, management will decide whether or not to install the system after a full discussion of the options
Documentation • Program Documentation • This documentation guides programmers, who construct modules that are well supported by internal and external comments and descriptions that can be understood and maintained easily
Documentation • System Documentation • Includes data dictionary entries, data flow diagrams, object models, screen layouts, source documents, and the systems request that initiated the project • During systems implementation, an analyst must review system documentation to verify that it is complete, accurate, and up-to-date, including any changes made during the implementation process
Documentation • Operations Documentation • Includes the following information: • Program, systems analyst, programmer, and system identification • Scheduling information, such as report run frequency and deadlines • Input files and where they originate; and output files and destinations • Report distribution
Documentation • Operations Documentation • Includes the following information: • Special forms required • Error and informational messages to operators and restart procedures • Special instructions, such as security requirements • Operations documentation should be clear, concise, and available online if possible
Documentation • User Documentation • Programmers or systems analysts usually create program and system documentation • You need someone with expert skills in this area doing the development, just as you need someone with expert skills developing the software • User documentation must be clear, understandable, and readily accessible to users at all levels
Documentation • User Documentation • Includes the following: • A system overview that clearly describes all major system features, capabilities, and limitations • Description of source document content, preparation, processing, and samples • Overview of menu and data entry screen options, contents, and processing instructions • Examples of reports that are produced regularly or available at the user’s request, including samples
Documentation • User Documentation • Includes the following: • Security and audit trail information • Explanation of responsibility for specific input, output, or processing requirements • Procedures for requesting changes and reporting problems • Examples of exceptions and error situations • Frequently asked questions (FAQs) • Explanation of how to get help and procedures for updating the user manual
Documentation • User Documentation • Online documentation • Must determine whether the documentation will be available from within the program, or as a separate entity in the form of a tutorial, slide presentation, reference manual, or Web site • Effective online documentation is an important productivity tool
Documentation • User Documentation • Written documentation material also is valuable • The time between finishing software coding and the time when a complete package can be released to users is entirely dependent on how well the documentation is thought out in advance
Documentation • User Documentation • Neglecting user documentation issues until after all the program is complete often leads to one of two things: 1) the documentation will be thrown together as quickly as possible just to get it out the door on time, and it more than likely will be inadequate; or 2) it will be done correctly, and the product release will be delayed considerably
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
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
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 area is necessary to maintain system security and integrity and protect the operational environment
Operational and Test Environments • Access to the operational environment is limited to users and must be strictly controlled • The test environment for an information system contains copies of all programs, procedures, and test data files • After any modification, you should repeat the same acceptance tests you ran when the system was developed
Operational and Test Environments • The operational environment includes hardware and software configurations and settings, system utilities, telecommunications resources, and any other components that might affect system performance • If you have to build or upgrade network resources to support the new system, you must test the platform rigorously before system installation begins
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
Training • Vendor Training • If the system includes the purchase of software or hardware, then vendor-supplied training is one of the features you should investigate in the RFPs (requests for proposal) and RFQs (requests for quotation) that you send to potential vendors • Vendor training often gives the best return on your training dollars
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 • Center for the Application of Information Technologies (CAIT)
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
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
Data Conversion • Data Conversion • During data conversion, existing data is loaded into the new system • You should develop a data conversion plan as early as possible, and the conversion process should be tested when the test environment is developed
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
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
System Changeover • 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
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
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 they 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
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