1 / 75

CHAPTER 8 System implementation

CHAPTER 8 System implementation. Phase Description. Systems Implementation is the fourth of five phases in the systems development life cycle Includes application development, documentation, testing, training, data conversion, and system changeover

amartinez
Download Presentation

CHAPTER 8 System 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 8System implementation

  2. Phase Description • Systems Implementation is the fourth of five phases in the systems development life cycle • Includes application development, documentation, testing, training, data conversion, and system changeover • The deliverable for this phase is a completely functioning information system

  3. Chapter Objectives • Explain the importance of software quality assurance and software engineering • Describe the application development process for structured, object-oriented, and agile methods • Draw a structure chart showing top-down design, modular design, cohesion, and coupling

  4. Chapter Objectives • Explain the coding process • Explain unit, integration, and system testing • Differentiate between program, system, operations, and user documentation • List the main steps in system installation and evaluation

  5. Chapter Objectives • Develop a training plan for each group of participants, compare in-house and outside training, and describe effective training techniques • Describe data conversion and changeover methods • Explain post-implementation evaluation and the final report to management

  6. 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

  7. 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 • Quality assurance

  8. Software Quality Assurance • Software Engineering • Capability Maturity Model (CMM) • Capability Maturity Model Integration (CMMI) • Process improvement • CMMI tracks an organization's processes, using five maturity layers

  9. 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

  10. Overview of Application Development • Application development • Objective is to translate the design into program and code modules that will function properly • Review the System Design • Tasks produced an overall design and a plan for physical implementation

  11. Overview of Application Development • Application Development Tasks • Tradition methods • Module • Start by reviewing documentation from prior SDLC phases and creating a set of program designs • At this point, coding and testing tasks begin

  12. Overview of Application Development • Application Development Tasks • Agile Methods • Intense communication and collaboration will now begin between the IT team and the users or customers • Objective is to create the system through an iterative process • Agile projects use various models

  13. Overview of Application Development • System Development Tools • Entity-relationship diagrams • Flowcharts • Pseudocode • Decision tables and decision trees

  14. 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

  15. Structured Application Development • Top-down approach • Partitioning • Modular design • Must proceed carefully, with constant input from programmers and IT management to achieve a sound, well-integrated structure • Must ensure that integration capability is built into each design and thoroughly tested

  16. Structured Application Development • Structure Charts • Structure charts show the program modules and the relationships among them • Control module • Subordinate modules

  17. Structured Application Development • Structure Charts • Module • library module • Data Couple • Control Couple • Status Flag • A module uses a flag to signal a specific condition or action to another module

  18. Structured 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

  19. Structured Application Development • Cohesion and Coupling • If you need to make a module more cohesive, you can split it into separate units, each with a single function • Loosely coupled • Tightly coupled

  20. Structured Application Development • Drawing a Structure Chart • Step 1: Review the DFDs • Review all DFDs for accuracy and completeness • Step 2: Identify Modules and Relationships • Transform functional primitives or object methods into program modules • Three-level structure charts relates to the three DFD levels

  21. Structured Application Development • Steps in Drawing a Structure Chart • Step 3: Add Couples, Loops, and Conditions • Identify the data elements that pass from one module to another • Step 4: Analyze the Structure Chart and the Data Dictionary • Ensure that the chart reflects all previous documentation and that the logic is correct

  22. Object-Oriented Application Development • Object-oriented development (OOD) • Characteristics of Object-Oriented Application Development • The application's structure is represented by the object model itself • Attributes • Methods

  23. Object-Oriented Application Development • Implementation of Object-Oriented Designs • Main objective is 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 – loosely coupled • Methods – loosely coupled and highly cohesive

  24. Agile Application Development • Is a distinctly different systems development • Development team is in constant communication with the customer • Focuses on small teams, intense communication, and rapid development iterations • Extreme Programming (XP) is one of the newest agile methods

  25. Agile Application Development • An extreme programming (XP) Example • User story • Release plan • Iteration cycle • Iteration planning meeting • Parallel programming • Test-driven design

  26. Agile Application Development • The Future of Agile Development • Critics claim it lacks discipline and produces systems of questionable quality • before implementing agile development, the proposed system and development methods should be examined carefully • A one-size-fits-all solution does not exist

  27. Coding • Coding • Programming Environments • Each IT departments has its own programming environment and standards • Integrated development environment (IDE) • Generating Code • Can generate editable program code directly from macros, keystrokes, or mouse actions

  28. Testing the System • After coding, a programmer must test each program to make sure that it functions correctly • Syntax errors • Desk checking • Logic errors • Structured walkthrough, or code review • Design walkthrough

  29. Testing the System • Unit Testing • Required test data • 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

  30. 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

  31. Testing the System • System Testing • 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

  32. 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

  33. Testing the System • System Testing • Acceptance tests/User Acceptance Test (UAT) • 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

  34. Documentation • Documentation • [1] Program Documentation • Systems analyst usually verifies that program documentation is complete and accurate • Defect tracking software/bug tracking software • Patches

  35. Documentation • [2] System Documentation • Includes data dictionary entries, data flow diagrams, object models, screen layouts, source documents, and the systems request that initiated the project • An analyst must review prior documentation to verify that it is complete, accurate, and up-to-date, including any changes made during the implementation process

  36. Documentation • [3] Operations Documentation • Includes the following information: • Program, systems analyst, programmer, and system identification • Scheduling information for printed output, such as report run frequency and deadlines • Input files and where they originate; and output files and destinations • E-mail and report distribution lists

  37. Documentation • [3] Operations Documentation • Includes the following information: • Special forms required, including online forms • 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

  38. Documentation • [4] 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 • Systems analysts usually are responsible for preparing documentation to help users learn the system

  39. Documentation • [4] 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

  40. Documentation • [4] 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

  41. Documentation • [4] 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

  42. Documentation • [4] User Documentation • Written documentation material also is valuable • The time between finishing software coding and the time when a complete package – including documentation – can be released to users is entirely dependent on how well the documentation is thought out in advance

  43. Documentation • [4] 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

  44. 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

  45. 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

  46. System Installation and Evaluation • Remaining steps in systems implementation: • Carry out post-implementation evaluation of the system • Present a final report to management

  47. 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

  48. 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

  49. 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

  50. Training • A successful information system requires training for users, managers, and IT staff members • The entire systems development effort can depend on whether or not people understand the system and know how to use it effectively

More Related