implementation l.
Skip this Video
Loading SlideShow in 5 Seconds..
Implementation PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 35

Implementation - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


Week 14




Project Planning






delineating iv and v
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
managing implementation
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
managing implementation5
Managing Implementation
    • Order of program development
    • Source code control & versioning
    • Quality assurance and testing
    • Installation
    • Documentation and training
order of program development
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
order of program development7
Order of Program Development
    • 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
order of program development9
Order of Program Development
    • 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
order of program development10
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
source code control and versioning
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
  • 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)
  • 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
  • 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
source code control and versioning16
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:



Unit Testing


and Systems



qa and testing
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
qa and testing18
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
qa and testing19
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
qa and testing20
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
qa and testing21
QA and 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)
qa and testing22
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?
qa and testing23
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
qa and testing24
QA and 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
qa and testing25
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
qa and testing26
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
  • Four approaches:
    • Direct (big-bang) installation
    • Parallel installation
    • Single location
    • Phased installation
  • Each approach has strengths and weaknesses related to:
    • Cost
    • Complexity
    • Risk
  • Which way is best?
  • 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
  • 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
  • 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