Implementation phase, and Transition to the New System (Turnitin Plagiarism enable by instructor)

ch12.pdf

Home >Architecture and Design homework help >Implementation phase, and Transition to the New System (Turnitin Plagiarism enable by instructor)

Moving into Implementation S Y S T E M S A N A LY S I S A N D D E S I G N , 6 T H E D I T I O N

D E N N I S , W I X O M , A N D R O T H

Learning Objectives  Be familiar with the system construction process.  Explain different types of tests and when to use them.  Describe how to develop user documentation.

Key Definitions  Implementation is the development of all parts of the

system: the software itself, documentation, and new operating procedures.

Managing the Programming Process P R O J E C T M A N A G E M E N T D U R I N G C O N S T R U C T I O N

Project Manager’s Tasks During Programming  Assigning the programmers  Coordinating the activities  Managing the schedule

The Programmer Paradox  More is not always better than less!  After the “right” number of people are assigned to a

programming task, adding more people slows down rather than speeds up completion of the project.

 Projects requiring a large team should be broken into a series of independent, smaller parts.

Assigning Programmers Minimize the number of programmers

Two communication channels

Twelve communication channels

o Match programming tasks with programmer capabilities o When skills are deficient, apply mentoring and training

Coordinating Activities  Weekly (hopefully brief) meetings  Create and follow standards  Organize programmers’ work areas o Development area o Testing area o Production area  Implement change control mechanisms  Use program log to monitor program changes

Managing the Schedule  Use initial time estimates as a baseline  Revise time estimates as construction proceeds  Fight against scope creep  Monitor “minor” slippage  Create risk assessment and track changing risks  Fight the temptation to lower quality to meet

unreasonable schedule demands

Avoid Classic Mistakes Research-oriented development If you use state-of-the art technology, lengthen planned time Using “low-cost” personnel

If using a significant number of entry level personnel, lengthen planned time

Lack of code control Use source code library to keep programmers from changing the same code at the same time

Inadequate testing Always allocate sufficient time for formal testing

Testing E N S U R I N G T H E S Y S T E M F U L F I L L S R E Q U I R E M E N T S

Testing Philosophy  Testing helps ensure that the system performs as outlined in the

specifications.  It is dangerous to test early modules without an overall testing

plan  It may be difficult to reproduce sequence of events causing an

error  Testing must be done systematically and results documented

carefully

Test Plan

Categories of Testing  Stub testing o Tests control structures before all modules are written

 Unit testing o Tests each module – Does it performs its function?

 Integration testing o Tests the interaction of modules - do they work together?

 System testing o Tests to assure that the software works well as part of the overall system

 Acceptance testing o Tests to assure that the system serves organizational needs

Stub Testing

Unit Testing Black Box Testing o Focuses on whether the unit meets requirements stated in

specification White-Box Testing o Looks inside the module at actual code

Integration Testing  User interface testing o Tests each interface function  Use-scenario testing o Ensures that each use scenario works correctly  Data flow testing o Tests each process in a step-by-step fashion

 System interface testing o Ensures data transfer between systems

System Testing  Requirements Testing o Ensures that integration did not cause new errors  Usability Testing o Tests how easy and error-free the system is in use  Security Testing o Assures that security functions are handled properly  Performance Testing o Assures that the system works under high volumes of

activity (e.g., simultaneous users, peak transaction volume)  Documentation Testing o Analysts check the accuracy of documentation

Acceptance Testing  Alpha Testing o Performed by users to assure they accept the system; frequently repeats

earlier tests  Beta Testing o Uses real data, not test data. Actual users monitor for errors or needed

improvements.  User sign-off following Acceptance Testing indicates the

system is ready to be placed into production.

Developing Documentation C R E AT I N G G O O D D O C U M E N TAT I O N

Types of Documentation  Documentation provides information to make the system

easier to use and repair.  System Documentation o Intended to help programmers and analysts understand and maintain the

system after it is installed  User Documentation o Intended to help users operate the system

Producing Documentation  High quality documentation takes about 3 hours per page or 2

hours per screen.  The task should not be left to the end of the project.  Time required to develop and test user documentation should

be built into project plan.  On-line documentation is predominant today.

Value of Online Documentation  Searching is simplified.  Information can be presented in multiple formats.  New methods of interacting with documentation are possible

(e.g., tool tips, animated demos, narrated demos).  Less costly than paper documentation.

Types of User Documentation  Reference documents (perform system functions).  Procedures manuals (perform business tasks – includes

manual procedures).  Tutorials (how to use system components).

Sources of Documentation Topics  Users’ business tasks (what they need to do)  The commands and menus in the user interface  Definitions of terms

Guidelines for Crafting Documentation Topics  Don’t omit any step because you “assume” the user knows

how to do that step  Use the active voice with direct instructions  Use consistent terms  Use simple, friendly language  Use parallel grammatical structure  Use steps correctly (as actions)  Use short paragraphs

Samples for Tune Source

Moving into Implementation
Learning Objectives
Key Definitions
Managing the Programming Process
Project Manager’s Tasks During Programming
The Programmer Paradox
Assigning Programmers
Coordinating Activities
Managing the Schedule
Avoid Classic Mistakes
Testing
Testing Philosophy
Test Plan
Categories of Testing
Stub Testing
Unit Testing
Integration Testing
System Testing
Acceptance Testing
Developing Documentation
Types of Documentation
Producing Documentation
Value of Online Documentation
Types of User Documentation
Sources of Documentation Topics
Guidelines for Crafting Documentation Topics
Samples for Tune Source