PHASE 4

1
SYSTEMS ANALYSIS DESIGN

• PHASE 4
• SYSTEMS IMPLEMENTATION
• Application Development

2
SDLC Phases

• Phase 4 Systems Implementation
• Objectives
• Learn about application development, including
  designing, writing, testing, and documenting
  programs and code modules
• Perform installation and evaluation tasks,
  including user training, file conversion, system
  changeover, and evaluation of the results

3
Chapter 10

• Application Development

4
Objectives

• Describe the major tasks and activitiesthat are
  completed during the systems implementation phase
• Discuss the role of the systems analyst during
  application development
• Explain the importance of quality assurance and
  the role of software engineering in software
  development

5
Objectives

• Describe the different types of documentation the
  systems analyst must prepare
• Explain the different phases of testing including
  unit testing, link testing, and system testing
• Describe top-down design and modular design and
  the advantages of these approaches

6
Introduction

• During the systems implementation phase, the
  development team uses the system design
  specification as a blueprint for constructing the
  new system
• Analysts and programmers have different roles
  during application development
• An analyst's main task is to deliver clear,
  accurate specifications to a programmer

7
Quality Assurance

• Quality assurance is vitally important in all
  business areas, including IS functions
• The main objective of quality assurance is to
  detect and avoid problems as early as possible
• Quality assurance can detect
• Inaccurate requirements
• Design or coding errors
• Faulty documentation
• Ineffective testing

8
Quality Assurance

• Software engineering
• Stresses quality in software design
• Solid design
• Effective structure
• Accurate documentation
• Careful testing

9
Quality Assurance

• Software engineering
• Stresses quality in software design
• Solid design
• Effective structure
• Accurate documentation
• Careful testing
• Software Engineering Institute (SEI)
• Mission is to improve quality of software-based
  systems
• Capability Maturity Model is designed to improve
  quality, reduce development time, and cut costs

10
Application Development

• Planning the overall design strategy
• Use top-down (modular) approach and partition the
  system into subsystems and modules
• Develop programs and modules
• Design, code, test, and document
• Test the system
• Link test
• System test
• Complete all documentation

11
Application Development

• Documentation review and application design
• Program designs are based on
• System design specification
• Prior phase documentation
• DFDs
• Process descriptions
• Screen layouts
• Report layouts
• Source documents
• Data dictionary entries

12
Application Development

• Documentation review and application design
• Structure (hierarchy) charts
• Show the organization of program modules and the
  functions they perform

13
Application Development

• Documentation review and application design
• Structure (hierarchy) charts
• Show the organization of program modules and the
  functions they perform
• Program flowcharts
• Show the internal logic needed to perform program
  tasks and provide output

14
Application Development

• Documentation review and application design
• Structure (hierarchy) charts
• Show the organization of program modules and the
  functions they perform
• Program flowcharts
• Show the internal logic needed to perform program
  tasks and provide output
• Pseudocode
• Documents the programs logical steps

15
Application Development

• Coding
• Process of turning program logic into specific
  instructions that can be executed by the computer
  system
• Many programming languages exist
• Visual C
• Access Basic
• Visual Basic
• SQL
• HTML
• Java

16
Application Development

• Testing the application
• Testing is necessary to ensure that all programs
  function correctly
• First step is to detect syntax errors and obtain
  a clean compilation
• Next step is to eliminate logic errors
• Techniques include desk checking, structured
  walkthrough, and code review
• Final step is testing
• Unit, link, and systems testing

17
Application Development

• Testing the application
• Unit testing
• Involves an individual program
• Objective is to identify and eliminate execution
  errors and any remaining logic errors
• Stub testing is a technique of using stubs to
  represent entry or exit points that will be
  linked later to another program or data file

18
Application Development

• Testing the application
• Link testing
• Involves two or more programs that depend on each
  other
• Also called string testing, series testing, or
  integration testing
• Link testing ensures that the job streams are
  correct
• Test data is necessary to simulate actual
  conditions and test the interface between programs

19
Application Development

• Testing the application
• System testing
• Involves the entire information system and
  includes all typical processing situations
• Requires users to verify all processing options
  and outputs
• Uses live data
• Involves a final test of all programs
• Ensures that proper documentation is ready
• Verifies that all system components work
  correctly
• Confirms that the system can handle predicted
  data volumes in a timely and efficient manner

20
TRADEOFF

• How far should you go with system testing?
• Tradeoff pressure for the new system from users
  and managers vs. the need to avoid major errors
• Typical issues to consider
• What is the judgment of analysts, programmers, IS
  management, and the project manager?
• Do potential problems exist that might affect the
  integrity or accuracy of data?
• Can minor changes be treated as future
  maintenance items?

21
A KEY QUESTION

• During the first two weeks of system testing, a
  number of minor problems were detected and fixed
• One department manager insists on a no-risk
  guarantee, while other users are clamoring for
  the new system to become operational
• How do you respond?

22
Documentation

• Explains the system and helps peopleinteract
  with it
• Types of documentation
• Program documentation
• System documentation
• Operations documentation
• User documentation

23
Documentation

• Program documentation
• Begins in the systems analysis phase and
  continues during systems implementation
• Includes process descriptions and report layouts
• Programmers provide documentation with comments
  that make it easier to understand and maintain
  the program
• An analyst must verify that program documentation
  is accurate and complete

24
Documentation

• System documentation
• System documentation describes the systems
  functions and how they are implemented
• Most system documentation is prepared during the
  systems analysis and systems design phases
• Documentation consists of
• Data dictionary entries
• Data flow diagrams
• Screen layouts
• Source documents
• Initial systems request

25
Documentation

• Operations documentation
• Typically used in a minicomputer or mainframe
  environment with centralized processing and batch
  job scheduling
• Documentation tells the IS operations group how
  and when to run programs
• Common example is a program run sheet, which
  contains information needed for processing and
  distributing output

26
Documentation

• User documentation
• Typically includes the following items
• System overview
• Source document description, with samples
• Menu and data entry screens
• Reports that are available, with samples
• Security and audit trail information
• Responsibility for input, output, processing
• Procedures for handling changes/problems
• Examples of exceptions and error situations
• Frequently asked questions (FAQ)
• Explanation of Help updating the manual

27
Documentation

• User documentation
• Written documentation material often is provided
  in a user manual
• Analysts prepare the material and users review it
  and participate in developing the manual

28
Documentation

• User documentation
• Written documentation material often is provided
  in a user manual
• Analysts prepare the material and users review it
  and participate in developing the manual
• Online documentation can empower users and reduce
  the need for direct IS support
• Context-sensitive Help
• Interactive tutorials
• Hints and tips
• Hypertext
• On-screen demos

29
Management Approval

• After system testing is complete, the results are
  presented to management
• Test results
• Status of all required documentation
• Input from users who participated
• Detailed time schedules, cost estimates, and
  staffing requirements
• If approved, a schedule for system installation
  and evaluation will be established

30
SOFTWEAR, LIMITED

• The ESIP development team reviewed True Blue
  Systems design recommendation

31
SOFTWEAR, LIMITED

• The ESIP development team reviewed True Blue
  Systems design recommendation
• The team then used a top-down approach to
  partition the system into a set of modules
• Each module represented a program or function to
  be performed by one or more macros or code
  procedures
• The team carefully reviewed all ESIP system tasks
  and prepared a structure chart

32
SOFTWEAR, LIMITED

• Mainframe interface
• Extract module tasks
• Prepare a design for the extract module
• Write the commands, using Visual Basic
• Unit test the ESIP program module with test data,
  using stubs to indicate inputs and outputs
• Verify the results
• Create a procedure for downloading the deduction
  file from the mainframe to the ESIP server
• Test the download procedure and update the
  documentation

33
SOFTWEAR, LIMITED

• ESIP server
• Database development tasks
• Finish switchboard and screen designs, with user
  input, including custom menus icons
• Design all necessary reports
• Verify ERDs record designs
• Define data tables, identify primary keys, and
  link tables into a relational structure
• Load test data
• Design and test queries
• Design and test macros and code modules
• Complete work on security features

34
SOFTWEAR, LIMITED

• Completing application development
• ESIP design and unit testing was completed in
  three weeks
• Link testing was performed successfully
• System testing revealed that several minor
  changes and corrections were necessary
• All changes received user approval and were
  documented carefully
• A user manual was developed, with substantial
  input and participation from users themselves