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

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
 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


User interfaces are developed early



Input programs can be used to enter test data
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)


QA during Analysis phase:


Identifying gaps or inconsistencies in system
requirements
QA during Design phase:


Process of ensuring that an IS meets minimal
quality standards
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


Integration


Testing individual programs or modules
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
Direct (Big-Bang) Installation
Parallel Installation
Single Location Installation
Phased Installation
Installation

Each approach has strengths and
weaknesses related to:




Cost
Complexity
Risk
Which way is best?
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
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
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