1 / 35

Implementation

Implementation. Week 14 CMIS570. SDLC. Project Planning. Analysis. Design. Implementation ***. Support. Delineating IV and V. Implementation Activities that occur before the system is turned over to its users Maintenance/Support

vui
Télécharger la présentation

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. Implementation Week 14 CMIS570

  2. SDLC Project Planning Analysis Design Implementation *** Support

  3. Delineating IV and V • Implementation • Activities that occur before the system is turned over to its users • Maintenance/Support • Activities that occur after the system becomes operational

  4. Managing Implementation • Analogy to building a house • Architecture (analysis/design) • Construction (implementation) • Large number of people • Myriad interdependent activities • Program development • Quality assurance • Physical installation • Documentation • Training

  5. Managing Implementation • MAJOR ISSUES: • Order of program development • Source code control & versioning • Quality assurance and testing • Installation • Documentation and training

  6. Order of Program Development • IPO (1-Input, 2-Process, 3-Output) • Advantages: • Simplifies testing • Input programs can be used to enter test data • User interfaces are developed early • Allows for early user evaluation of interfaces • Head start on user documentation and training materials • Disadvantages: • Late implementation of outputs • Outputs are helpful in testing process modules

  7. Order of Program Development • TOP-DOWN • Create “stub” versions of subordinate modules • Primary advantage: • Always a working version of a program • Primary disadvantage: • Use of programming personnel at beginning can be inefficient

  8. Order of Program Development • BOTTOM-UP • Create “driver” versions of calling programs • Advantages: • Efficient use of programmers from the get-go • Lower-level modules often most complex, so this allows more time for development and testing of them • Disadvantages: • Writing a large number of “driver” programs • Adds complexity to developing and testing process

  9. Order of Program Development • Is just one part of the overall development and test plan • Development and testing go hand-in-hand • Plan should be created before beginning program development, covering: • Development order • Testing order • Generation of test data • Test cases • Acceptance criteria • Personnel and other resource needs

  10. Source Code Control and Versioning • SCCS • Automated tool for tracking source code files and controlling changes to those files • Allows only 1 programmer to check out a file to update • Prevents multiple programmers from updating same file at same time

  11. Example of SCCS

  12. Versioning • For development, testing, and maintenance of large complex systems • Used in development: • Alpha version(s) • Test version that is incomplete but ready for some level of rigorous testing • Lifetime is usually short (days or weeks)

  13. Versioning • Used in testing: • Beta version(s) • Test version that is stable enough to be tested by end users (to do real work) • Produced after one or more alpha versions have been “perfected” • Typically evaluated over period of weeks or months

  14. Versioning • Used in production/maintenance: • Production version (or release) • Formally distributed to users • Considered the final product • Multiple production versions are used to add features and fix bugs discovered after releasing original production version

  15. Source Code Control and Versioning • Versioning control is a part of most sophisticated SCCS’s • New programs and system versions move along this general landscape: Development and Unit Testing Integration and Systems Testing Production

  16. QA and Testing • Quality Assurance (QA) • Process of ensuring that an IS meets minimal quality standards • QA during Analysis phase: • Identifying gaps or inconsistencies in system requirements • QA during Design phase: • Satisfying stated requirements and making appropriate design decisions • QA during Implementation phase: • Applying QA tools to program design and coding, and then Testing

  17. QA and Testing • QA tools used throughout SDLC: • Technical review • Formal or informal review of analysis, design, or development details by a group of analysts, developers, and/or users • Walkthough is one type of technical review • Two or more people review the accuracy and completeness of a model or program • Developer of model or program leads the walkthrough, describing assumptions, key decisions, and operation

  18. QA and Testing • QA tools used throughout SDLC: • Inspection • More formal version of a walkthrough • Participants review and analyze materials before they meet as a group • Participants play specific roles: • Presenter – usually the developer, summarizes the material being inspected • Critics – describe errors and concerns found • Recorder – records all errors/concerns and the agreed-upon solution strategies

  19. QA and Testing • Walkthroughs and inspections have been found to: • Reduce number of errors that reach testing by a factor of 5 to 10 • Reduce testing costs by approx. 50% • Goal is to catch as many errors as possible using these QA tools – prior to Testing

  20. QA and Testing • TESTING • Process of examining a product to determine what defects it contains • TESTING in Implementation phase: • Unit • Testing individual programs or modules • Integration • Testing groups of programs/modules • Systems • Testing an entire system (including interfaces between application components)

  21. QA and Testing • Test planning is not easy! • Should utilize QA tools (to ensure quality of test plan!) • Walkthrough test plans • Inspect test cases • Test plans and cases should be retained after Implementation • WHY?

  22. QA and Testing • UNIT Testing • Testing of individual modules before they are integrated with other modules • Examines internal design of program • The goal: Every instruction should be executed at least once • Path testing: Design test cases that focus on small segments of code; aim to exercise a high percentage of the internal paths • Called “white box” testing

  23. QA and Testing • INTEGRATION Testing • Testing of a group of modules • “Black box” testing – done without knowledge of programs’ internal design • Can elucidate problems such as: • Interface incompatibility • Incorrect data type or length being passed • Incorrect parameter values passed • Unexpected state interactions • States of 2 or more modules combine to create an unexpected situation

  24. QA and Testing • SYSTEM Testing • Test the entire application system • First performed by developers or test personnel • After passing system tests by developers and test personnel: • ACCEPTANCE testing • Performed by users • To determine whether system fulfills user requirements • Uses a beta version • Usually treated as a very formal activity

  25. QA and Testing • A common recommendation: “Separate Testing From Development” • Why? • Humans tend not to find own mistakes • But recommend keeping unit and integration testing with programmer • Why? • After unit and integration testing, transfer test responsibility to dedicated test group

  26. Installation • Four approaches: • Direct (big-bang) installation • Parallel installation • Single location • Phased installation

  27. Direct (Big-Bang) Installation

  28. Parallel Installation

  29. Single Location Installation

  30. Phased Installation

  31. Installation • Each approach has strengths and weaknesses related to: • Cost • Complexity • Risk • Which way is best?

  32. Documentation • Documentation • System Documentation • Descriptions of system functions, architecture, and development details • Used by maintenance personnel and developers of future systems • User Documentation • For end users: Descriptions of how to interact with and utilize the system • For system operators: Descriptions of how to maintain the system and keep it operable

  33. Documentation • System Documentation includes: • DFD, ERD, Process Models • System Flow Chart, Structure Chart • Function Hierarchy Diagrams, CRUD Matrices • Database Schema code (SQL statements) • Program source code • Test data and cases

  34. Documentation • User Documentation • Is task-based • Describes functionalities • Contains how-to’s • Keystrokes, mouse, and commands to perform specific functions • Contains FAQ’s • Explains error messages • Contains an index and “getting started” section

More Related