CMIS 470 Structured Systems Design SDLC, DFD, ERD, Installation, Maintenance Review, Week 3

Plan for Tonight Quick review of SDLC Quick review of DFDs and ERDs Drill down on Implementation and Maintenance phases

Quick Review of SDLC I.??? II.??? III.??? IV.??? V.??? VI.??? VII.???

DFDs What do you remember? 4 parts of DFD What is DFD showing?

ERDs What do you remember? What part of the ERD must match with what part of the DFD? What is ERD showing?

Delineating VI and VII 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 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 Implementation MAJOR ISSUES: Order of program development Order of program development Source code control & versioning Source code control & versioning Quality assurance and testing Installation Documentation and training

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

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

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

Example of SCCS

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)

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

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

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

QA and Testing Quality Assurance (QA) Quality Assurance (QA) Process of ensuring that an IS meets minimal quality standards 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 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 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 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 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)

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

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

Installation Four approaches: Direct (big-bang) installation Parallel installation Single location Phased installation Each approach has strengths and weaknesses related to: Cost Complexity Risk

Documentation and Training 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

Documentation and Training 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

Documentation and Training 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

Documentation and Training User Training Need to consider the same 2 groups: End users Use the system to achieve the business purpose Creating, modifying, deleting records Generating reports Querying the data System operators Perform administrative functions and routine maintenance to keep the system operating Starting and stopping the system Running backup and recovery

Maintenance Phase Maintenance: Changes made to a system to fix or enhance its functionality Why is this needed? Corrective Perfective Adaptive Preventive

Maintenance Phase Start with “production copy” of modules to be changed Check out production version of source code Unit testing REGRESSION testing To ensure changes have not created new problems in the system Accomplished by running a subset of previously executed integration and system tests Smart IS shops keep a regression “test bucket” of selected test cases to run on a system when changes are made to any module in that system

For Next Class Meeting… Review pages in text as noted on syllabus Get ready for Object-Oriented Analysis and Design!