Systems Analysis & Design Systems Implementation & Support CSUN

advertisement
CSUN Information Systems
Systems Analysis & Design
http://www.csun.edu/~dn58412/IS431/IS431_SP16.htm
Systems
Implementation & Support
IS 431: Lecture 11
1
Systems Implementation
& Support in SDLC
IS 431 : Lecture 11
2
Systems
Implementation & Support
 Construction/Implementation and
Operation/Support in SDLC.
 System/applications and system acceptance tests.
 System installation/conversion strategies.
 System support: maintenance, recovery and
enhancement.
IS 431 : Lecture 11
3
System Construction
and Implementation
Systems Construction: the development,
installation, and testing of system components.
Systems Implementation: the delivery of that
system into production , up and running.
IS 431 : Lecture 11
4
System Construction
and Implementation
IS 431 : Lecture 11
5
Tasks in
Construction Phase
IS 431 : Lecture 11
6
Tasks in
Construction Phase
1.
2.
3.
4.
Build and Test Networks
Build and Test Databases
Install and Test New Software Package
Write and Test New Programs
IS 431 : Lecture 11
7
1. Build and Test Networks
 Often system build around existing networks.
 If system calls for new network functionality, must by
built and tested prior to programs that use that it.
 Roles
– Network designer
 Designs LAN and WAN connectivity
– Network administrator builds and tests
 Network architecture standards
 Security
– Systems analyst
 Facilitates
 Ensures that business requirements are not compromised
IS 431 : Lecture 11
8
2. Build and Test Databases
 Implement database schema
 Test with sample data
 Deliver unpopulated database structure
 Roles
– System Users
 Provide and/or approve test data
– Database Designer/Programmer
 Build tables, views, stored procedures (if relational database)
– Database Administrator
 “Tune” database for optimum performance
 Security
 Backup and recovery
– Systems Analyst
 Build non-corporate, applications-oriented database
 Ensures business requirements compliance
IS 431 : Lecture 11
9
3. Install and Test New
Software
 If system requires purchased or leased software, must be
installed and tested.
 Roles
– Systems Analyst
 Clarifies business requirements
– System Designer
 Clarifies integration requirements
– Network Administrator
 Install software package
– Software Vendor/Consultant
 Assist in installation and testing
– Applications Programmers
 Test according to integration requirements
IS 431 : Lecture 11
10
4. Write and Test New
Programs
 Develop in-house programs
–
–
–
–
Reuse available software components in library
Write new components
Test
Document
 Roles
– Systems Analyst
 Clarifies business requirements
– System Designer
 Clarifies program design and integration requirements
– Application Programmers
 Writes and tests in-house software
IS 431 : Lecture 11
11
Levels of Testing
Stub test - a test performed on a subset of a program.
– Individual events or modules of a program.
– Testing of an isolated subset of a program.
Unit or program test – a test performed on an entire
program.
– All the events and modules tested as an integrated unit.
Systems test – a test performed on an entire system
– Ensures that application programs written and tested in
isolation work properly when integrated into the total
system.
IS 431 : Lecture 11
12
Tasks in
Implementation Phase
IS 431 : Lecture 11
13
Tasks in
Implementation Phase
1.
2.
3.
4.
5.
Conduct System Test
Prepare Conversion Plan
Install Databases
Train Users
Convert to New System
IS 431 : Lecture 11
14
1. Conduct System Test
 Test network, databases, purchased software, new inhouse software, and existing software to make sure it
all works together.
 Roles
– Systems Analyst
 Develops system test data
 Communicates problems and issues
– System Builders (database, network, programmers)
 Resolve problems revealed during testing
– System Owners and users
 Verify whether or not system operates correctly
 May result in return to construction phase
– Iterate until successful system test
IS 431 : Lecture 11
15
Systems Acceptance Test
 Systems Acceptance Test – a test performed on the
final system wherein users conduct a verification,
validation, and audit test.
– Uses real data over an extended time period
– Extensive test that addresses: verification testing,
validation testing, and audit testing.
 Verification Testing runs the system in a simulated
environment using simulated data.
– Alpha testing
– Simulated environment using simulated data
– Checks for errors and omissions regarding end-use and
design specifications
IS 431 : Lecture 11
16
Systems Acceptance Test
 Validation testing runs the system in a live
environment using real data.
– Beta testing
– Live environment using real data
– Testing:
 Systems performance (throughput and response time)
 Peak workload performance
 Human engineering
 Methods and procedures
 Backup and recovery
 Audit testing certifies that the system is free of
errors and is ready to be placed into operation.
IS 431 : Lecture 11
17
2. Prepare Conversion Plan
 Plan for how to convert from old system to new
system.
–
–
–
–
How to install and populate databases
How to train users
Finalize documentation
Conversion issues
 Roles
– System analyst/Project manager
 Develop a detailed conversion plan
– Steering committee
 Approves plan and timetable
IS 431 : Lecture 11
18
3. Install Databases
 Populate new system databases with existing data
from old system
– Generally have to restructure data as it is populated
– Must confirm that data is translated correctly
 Roles
– Application programmers
 Write (or use) special programs to extract data from existing
databases and populate new databases
– Systems analyst/designer
 Calculate database sizes and estimate time for installation
IS 431 : Lecture 11
19
4. Train Users
 System users trained and provided with
documentation
 Roles
– System analyst




Plan trainings
Conduct trainings
Write documentation
Help users through the learning period
– System owners
 Approve release time for training
– System users
 Attend training
 Accept system
IS 431 : Lecture 11
20
5. Convert to New System
 Ownership transfers from analysts and builders to
end users.
 Roles
– Systems analyst/Project manager
 Carries out conversion plan
 Correct shortcomings
 Measure system acceptance
– System owners
 Provide feedback
– System users
 Provide feedback
IS 431 : Lecture 11
21
Installation/Conversion
Strategies
 Abrupt cutover
Old System
New System
 Parallel conversion
Old system
New System
 Location (Pilot) conversion
Old System
New System
 Staged (Phased) conversion
Old System
New System
IS 431 : Lecture 11
22
Installation/Conversion
Strategies …
Abrupt
Cutover
R
i
s
k
Location
Staged
Conversion Conversion
Parallel
Conversion
Cost
IS 431 : Lecture 11
23
Support vs. Operation
Systems support is the on-going technical support for
users, as well as the maintenance required to fix any
errors, omissions, or new requirements that may arise.
Systems operation is the day-to-day, week-to-week,
month-to-month, and year-to-year execution of an
information system’s business processes and application
programs.
An operational system is a system that has been placed
into operation. Also called a production system.
IS 431 : Lecture 11
24
The Context of Systems
Operation and Support
IS 431 : Lecture 11
25
Systems Development,
Operation, and Support
IS 431 : Lecture 11
26
Important Data Stores
of the System
 The repository is a data store(s) of accumulated
system knowledge—system models, detailed
specifications, and any other documentation
accumulated during systems development.
 The program library is a data store(s) of all
application programs.
 The business data is all those data stores of the
actual business data created and maintained by the
production application programs.
IS 431 : Lecture 11
27
Systems Support
Activities
IS 431 : Lecture 11
28
System Support
Activities
 Program Maintenance corrects “bugs” or errors
that slipped through the system development
process.
 System Recovery is the restoration of the system
and data after a system failure.
 Technical Support is any assistance provided to
users in response to inexperience or unanticipated
situations.
 System Enhancement is the improvement of the
system to handle new business problems, new
technical problems, or new technology
requirements.
IS 431 : Lecture 11
29
Causes of “Bugs”
 Poorly validated requirements.
 Poorly communicated requirements.
 Misinterpreted requirements.
 Incorrectly implemented requirements or designs.
 Simple misuse of the programs.
IS 431 : Lecture 11
30
System Maintenance
Objectives
 To make predictable changes to existing programs
to correct errors.
 To preserve those aspects of the programs that were
correct, and to avoid “ripple effects” of changes that
may adversely affect the correctly functioning
aspects.
 To avoid, as much as possible, the degradation of
system performance.
 To complete the task as quickly as possible without
sacrificing quality and reliability of the system.
IS 431 : Lecture 11
31
System Maintenance
Tasks
IS 431 : Lecture 11
32
System Maintenance
Tasks
• Validate the problem.
• Benchmark the program.
• A test script is a repository of test cases to be executed against all
program revisions.
• Study and debug the program to fix:
•
•
•
•
•
Poor program structure.
Unstructured (or poorly structured) logic.
Prior maintenance (so-called “ripple” effects.)
Dead code.
Poor or inadequate documentation.
• Test the program.
• Version control is a process whereby a librarian program keeps
track of changes made to programs to facilitate backtracking.
IS 431 : Lecture 11
33
Types of Testing
 Unit testing (essential) ensures that the stand-alone program
fixes the bug without undesirable side effects to the program.
 System testing (essential) ensures that the entire application,
of which the modified and unit tested program was a part,
still works as a complete system.
 Regression testing (recommended) extrapolates the impact
of the changes on system performance (throughput and
response time) by analyzing before-and-after performance
against the test script.
IS 431 : Lecture 11
34
System Recovery
Activities
 Direct: Client-side (end-user) recovery and/or instruction
directly from the systems analyst.
 Indirect: Server-side recovery through a system
administrator.
 Indirect: Database recovery and rollback through a database
administrator.
 Indirect: Network recovery or fix through a network
administrator.
 Indirect: Technical or vendor assistance to correct a
hardware problem.
 Direct: Detection of a software bug (which triggers systems
maintenance).
IS 431 : Lecture 11
35
Technical Support
 Being on call to assist users
 Typical tasks:
–
–
–
–
–
Routinely observing the use of system
Conducting user-satisfaction surveys and meetings
Changing business procedures for clarification
Providing additional training
Logging enhancement ideas and requests in repository
IS 431 : Lecture 11
36
System Enhancement
Triggers
 New business problems
 New business requirements
 New technology requirements (including hardware
and software upgrades)
 New design requirements
IS 431 : Lecture 11
37
System Enhancement
Activities
IS 431 : Lecture 11
38
System Enhancement
Tasks
• Analyze enhancement request.
• If appropriate, make the quick fix.
• e.g., report writing
• Recover the existing physical system.
• Database recovery and restructuring
• Program analysis, recovery, and restructuring
• Repeat appropriate phases and tasks of the original
development methodology.
IS 431 : Lecture 11
39
System Obsolescence
 All systems degrade over time (entropy)
 At some point, not cost-effective to support and
maintain
 Leads to a new systems development project
 New cycle of SDLC
IS 431 : Lecture 11
40
Download