cmis 470 structured systems design sdlc, dfd, erd, installation, maintenance review, week 3
TRANSCRIPT
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!