Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Chapter 10 Systems Implementation and Operation This lecture is based on materials in Essentials of Systems Analysis and Design by Valacich, George, and Hoffer and the summary slides available on their website. However, some material herein also represents the perspective of Gregory Rose of Washington State University. Where materials are taken verbatim from the textbook slides, they represent the views of the book and are copyrighted by the authors and the publisher. Where the sequence or content differ, the content is considered the work of Gregory Rose with all copyrights reserved.
  2. 2. Implementation and Maintenance <ul><li>Eight major activities (in 4 groupings) </li></ul><ul><ul><li>1. Getting it built and loaded </li></ul></ul><ul><ul><ul><li>Coding </li></ul></ul></ul><ul><ul><ul><li>Testing </li></ul></ul></ul><ul><ul><ul><li>Installation </li></ul></ul></ul><ul><ul><li>2. Getting it usable </li></ul></ul><ul><ul><ul><li>Documentation </li></ul></ul></ul><ul><ul><ul><li>Training </li></ul></ul></ul><ul><ul><ul><li>Support </li></ul></ul></ul><ul><ul><li>3. At this point you deal with Project Closedown </li></ul></ul><ul><ul><li>4. Maintenance (basically is next SDLC) </li></ul></ul>
  3. 3. 1. The Process of Coding, Testing and Installation <ul><li>Getting it built and loaded </li></ul><ul><li>Coding </li></ul><ul><ul><li>Physical design specifications are turned into working computer code </li></ul></ul><ul><li>Testing </li></ul><ul><ul><li>Tests are performed using various strategies </li></ul></ul><ul><ul><li>Testing can be performed in parallel with coding </li></ul></ul><ul><li>Installation </li></ul><ul><ul><li>Process during which current system is replaced by new system </li></ul></ul>
  4. 4. The Process of Coding, Testing and Installation: Deliverables
  5. 5. 1.b. Software Application Testing <ul><li>A test plan is developed during analysis phase </li></ul><ul><li>During design phase, a unit test plan and a system test plan are developed </li></ul><ul><li>The actual testing is done during implementation </li></ul><ul><li>Test plans provide improved communication among all parties involved in testing </li></ul><ul><ul><li>Serve as checklists </li></ul></ul>
  6. 6. Software Application Testing The Testing Process <ul><li>The purpose of testing is confirming that system satisfies requirements </li></ul><ul><li>Testing must be planned </li></ul><ul><li>Needs Test Cases </li></ul><ul><ul><li>Specific scenario of transactions, queries or navigation paths that represent a typical, critical or abnormal use of system </li></ul></ul><ul><ul><li>Test cases and results should be thoroughly documented so they can be repeated for each revision of an application </li></ul></ul>
  7. 7. Software Application Testing Types of Testing <ul><li>Review Syntax Mistakes </li></ul><ul><ul><li>1. Syntax Checking (automated w/o code execution) </li></ul></ul><ul><ul><li>2. Inspection (manual w/o code execution) </li></ul></ul><ul><ul><ul><li>A testing technique in which participants examine program code for predictable language-specific errors </li></ul></ul></ul><ul><li>In both of these, the output and logic aren’t inspected. We are looking for common syntax errors </li></ul>
  8. 8. Software Application Testing Types of Testing <ul><li>Looking for outcome errors, not syntax </li></ul><ul><ul><li>3. Desk Checking (manual with code execution) </li></ul></ul><ul><ul><ul><li>Someone is manually figuring out what each line of code should generate as an outcome </li></ul></ul></ul><ul><ul><ul><li>Then each line of code is run and verified against manual output </li></ul></ul></ul><ul><ul><li>4. Walkthrough (manual with code execution) </li></ul></ul><ul><ul><ul><li>A peer group review of any product created during systems development process; also called a structured walkthrough </li></ul></ul></ul><ul><ul><ul><li>Programmer presents code to a group of experts to seek out problems </li></ul></ul></ul><ul><ul><ul><li>Various “test cases” are run to verify correct outcomes </li></ul></ul></ul>
  9. 9. Software Application Testing Types of Testing <ul><li>Automated tests with code execution (in increased order of integration) </li></ul><ul><ul><li>5. Unit Testing </li></ul></ul><ul><ul><ul><li>Each module is tested alone in an attempt to discover any errors in its code, also called module testing </li></ul></ul></ul><ul><ul><li>6. Integration Testing </li></ul></ul><ul><ul><ul><li>The process of bringing together all of modules that a program comprises for testing purposes. Modules are typically integrated in a top-down, incremental fashion </li></ul></ul></ul><ul><ul><li>7. System Testing </li></ul></ul><ul><ul><ul><li>The bringing together of all programs that a system comprises for testing purposes. Programs are typically integrated in a top-down, incremental fashion </li></ul></ul></ul><ul><ul><ul><li>Requires “stub testing”… </li></ul></ul></ul>
  10. 10. Software Application Testing Types of Testing <ul><li>Cont. </li></ul><ul><ul><li>Stub Testing </li></ul></ul><ul><ul><ul><li>A technique used in testing, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substitute for subordinate modules </li></ul></ul></ul><ul><ul><ul><li>Allows system and module testing as you go even if all modulates aren’t done at same time </li></ul></ul></ul>
  11. 11. Software Application Testing Acceptance Testing by Users <ul><li>Alpha and Beta tests: actual users test a completed information system, end result of which is users’ acceptance of it </li></ul><ul><li>Alpha Testing </li></ul><ul><ul><li>User testing of a completed information system using simulated data </li></ul></ul><ul><ul><ul><li>Recovery testing – break it and see if it recovers right </li></ul></ul></ul><ul><ul><ul><li>Security testing – test it vs. attacks </li></ul></ul></ul><ul><ul><ul><li>Stress testing – test to make it fail </li></ul></ul></ul><ul><ul><ul><li>Performance testing – stress it out and see if it bogs down </li></ul></ul></ul><ul><li>Beta Testing </li></ul><ul><ul><li>User testing of a completed information system using real data in real user environment </li></ul></ul>
  12. 12. 1.c. Installation <ul><li>Four install choices: </li></ul><ul><li>Firm-wide rollout vs. “single location installation” rollout </li></ul><ul><li>Entire application installation vs. “phased installation” </li></ul><ul><li>“ Direct installation” vs. “parallel installation” </li></ul><ul><li>Insource vs. Outsource (usually transitional) </li></ul>
  13. 13. 2. Process of Documenting System, Training Users and Supporting Users <ul><ul><li>Getting it usable </li></ul></ul><ul><ul><ul><li>Documentation </li></ul></ul></ul><ul><ul><ul><li>Training </li></ul></ul></ul><ul><ul><ul><li>Support </li></ul></ul></ul>
  14. 14. 2. Process of Documenting System, Training Users and Supporting Users <ul><li>Deliverables </li></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>User training </li></ul></ul><ul><ul><li>User support plan </li></ul></ul>
  15. 15. 2.a. Documenting The System <ul><li>System documentation- For the techies </li></ul><ul><ul><li>Detailed information about a system’s design specifications, its internal workings and its functionality </li></ul></ul><ul><ul><li>Internal documentation </li></ul></ul><ul><ul><ul><li>System documentation that is part of program source code or is generated at compile time </li></ul></ul></ul><ul><ul><li>External documentation </li></ul></ul><ul><ul><ul><li>System documentation that includes outcome of structured diagramming techniques such as data flow and entity relationship diagrams </li></ul></ul></ul><ul><li>User Documentation- For the non-techies </li></ul><ul><ul><li>Written or other visual information about an application system, how it works, and how to use it </li></ul></ul>
  16. 16. 2.b. Training <ul><li>Potential training topics (which ones included varies by type of system and skill set or knowledge of users) </li></ul><ul><ul><li>Use of system </li></ul></ul><ul><ul><li>General computer concepts </li></ul></ul><ul><ul><li>Information system concepts </li></ul></ul><ul><ul><li>Organizational concepts </li></ul></ul><ul><ul><li>System management </li></ul></ul><ul><ul><li>System installation </li></ul></ul>
  17. 17. 2.b. Training <ul><li>Training methods </li></ul><ul><ul><li>Resident expert </li></ul></ul><ul><ul><li>Computer-aided instruction </li></ul></ul><ul><ul><li>Formal courses </li></ul></ul><ul><ul><li>Software help components </li></ul></ul><ul><ul><li>Tutorials </li></ul></ul><ul><ul><li>Interactive training manuals </li></ul></ul><ul><ul><li>External sources, such as vendors </li></ul></ul>
  18. 18. 2.c. Support <ul><li>Two layers </li></ul><ul><ul><li>Information center </li></ul></ul><ul><ul><li>Help desk </li></ul></ul>
  19. 19. 2.c. Support Information Center <ul><li>An organizational unit whose mission is to support users in exploiting information technology </li></ul><ul><li>Staff might perform following tasks </li></ul><ul><ul><li>Install new hardware or software and set up user accounts </li></ul></ul><ul><ul><li>Consult with users writing programs in fourth-generation languages </li></ul></ul><ul><ul><li>Extract data from organizational databases onto personal computers </li></ul></ul><ul><ul><li>Answer basic on-demand questions </li></ul></ul><ul><ul><li>Provide a demonstration site for viewing hardware and software </li></ul></ul><ul><ul><li>Work with users to submit system change requests </li></ul></ul>
  20. 20. 2.c. Support Help Desk <ul><li>A single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department </li></ul>
  21. 21. 3. Project Close Down <ul><li>Evaluate team </li></ul><ul><ul><li>Reassign members to other projects </li></ul></ul><ul><li>Notify all affected parties that development project is ending and that you are switching to operation and maintenance mode </li></ul><ul><li>Conduct post-project reviews </li></ul><ul><li>Close out customer contract </li></ul><ul><ul><li>Formal signoff </li></ul></ul><ul><li>Reward team with celebration </li></ul>
  22. 22. 4. Maintenance <ul><li>Process of returning to beginning of SDLC and repeating development steps focusing on system change until change is implemented </li></ul><ul><li>Four major activities </li></ul><ul><ul><li>1. Obtaining maintenance requests </li></ul></ul><ul><ul><li>2. Transforming requests into changes </li></ul></ul><ul><ul><li>3. Designing changes </li></ul></ul><ul><ul><li>4. Implementing changes </li></ul></ul><ul><li>Is basically same as whole SDLC just a smaller scale version </li></ul>
  23. 23. 4. Maintenance <ul><li>Deliverables and Outcomes </li></ul><ul><ul><li>Development of an updated “version” of software and new versions of all design documents created or modified during maintenance effort </li></ul></ul><ul><ul><li>(e.g., version 1.1 & “what’s new” document, etc.) </li></ul></ul>
  24. 24. Conducting System Maintenance <ul><li>Often included in purchase price of software </li></ul><ul><ul><li>Corrective maintenance </li></ul></ul><ul><ul><ul><li>Changes made to a system to repair flaws in its design, coding, or implementation </li></ul></ul></ul><ul><ul><ul><li>Always important if work around cannot be found but timing of fixes based on severity </li></ul></ul></ul><ul><li>Usually only for a fee </li></ul><ul><ul><li>Adaptive maintenance </li></ul></ul><ul><ul><ul><li>Changes made to a system to evolve its functionality to changing business needs or technologies </li></ul></ul></ul><ul><ul><ul><li>If real, can be important. May be added as feature in next release if off the shelf software </li></ul></ul></ul><ul><ul><li>Enhancement maintenance </li></ul></ul><ul><ul><ul><li>Changes made to a system to add new features or to improve performance </li></ul></ul></ul><ul><ul><ul><li>Usually kicks off full SDLC evaluation process since adds $ for new needs </li></ul></ul></ul>
  25. 25. Configuration Management <ul><li>The process of assuring that only authorized changes are made to system </li></ul><ul><li>Baseline modules </li></ul><ul><ul><li>Software modules that have been tested, documented, and approved to be included in most recently created version of a system </li></ul></ul><ul><li>System librarian </li></ul><ul><ul><li>A person responsible for controlling checking out and checking in of baseline modules when a system is being developed or maintained </li></ul></ul><ul><li>Build routines </li></ul><ul><ul><li>Guidelines that list instructions to construct an executable system from baseline source code </li></ul></ul><ul><ul><li>Tells you how to rebuild each released version using various components in library in case you need to fall back a version or two </li></ul></ul>
  26. 26. That’s it folks! <ul><li>Congrats! </li></ul>