CMIS 470Structured 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

1. 2. 3. 4.

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 developmentOrder of program development Source code control & versioningSource 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:

Developmentand

Unit Testing

Integrationand Systems

TestingProduction

QA and Testing Quality Assurance (QA)Quality Assurance (QA)

Process of ensuring that an IS meets minimal Process of ensuring that an IS meets minimal quality standardsquality 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!