14-1 © Prentice Hall, 2004 Chapter 14: OOSAD Implementation and Operation Object-Oriented Systems...
-
Upload
david-sneed -
Category
Documents
-
view
213 -
download
0
Transcript of 14-1 © Prentice Hall, 2004 Chapter 14: OOSAD Implementation and Operation Object-Oriented Systems...
14-1 © Prentice Hall, 2004
Chapter 14:Chapter 14:OOSAD Implementation and OOSAD Implementation and
OperationOperation
Object-Oriented Systems Analysis and Design
Joey F. George, Dinesh Batra,
Joseph S. Valacich, Jeffrey A. Hoffer
14-2Chapter 14 © Prentice Hall, 2004
Chapter ObjectivesChapter Objectives
After studying this chapter you should be able to: Describe the process of coding, testing, and
converting an organizational information system.
Apply four installation strategies: direct, parallel, single-location, and phased.
14-3Chapter 14 © Prentice Hall, 2004
Chapter Objectives Chapter Objectives (Continued)(Continued)
After studying this chapter you should be able to: List the deliverables for documenting the
system and providing user training and support. Compare various training modes. Discuss the issues of providing support to end
users.
14-4Chapter 14 © Prentice Hall, 2004
Chapter Objectives Chapter Objectives (Continued)(Continued)
After studying this chapter you should be able to: Explain why systems implementation
sometimes fails. Explain and contrast four types of maintenance. Describe factors that influence system
maintenance costs.
14-5Chapter 14 © Prentice Hall, 2004
14-6Chapter 14 © Prentice Hall, 2004
14-7Chapter 14 © Prentice Hall, 2004
14-8Chapter 14 © Prentice Hall, 2004
What Is Coding?What Is Coding?
Translation of physical design specifications into working computer code
Coding involves use of programming languages such as Java or Visual Basic
eXtreme programming – an intensive coding and testing approach involving two-person teams and customer involvement
14-9Chapter 14 © Prentice Hall, 2004
ReuseReuse
The use of previously written software resources, especially objects and components, in new applications
Results in great savings of system development time
Object-oriented systems are very conducive to reuse.
14-10Chapter 14 © Prentice Hall, 2004
Approaches to ReuseApproaches to Reuse Ad hoc – individual, unplanned use (Developers do not
receive incentives, developers keep track of their own s/w assets)
Facilitated – use informally managed and disseminated by expert guru evangelists (Developers are encouraged to reuse by a promoter, some special tools/techniques)
Managed – organizationally enforced reuse policies and practices (Reuse is practiced and results measured. Sources from utility asset libraries, companies that sell assets, Open Source community)
Designed – reusable components developed and maintained in-house (Focus on developing reusable assets inhouse rather than buying/finding.)
Cos
t an
d c
omm
itm
ent
low
high
14-11Chapter 14 © Prentice Hall, 2004
What Is Software Application What Is Software Application Testing?Testing?
Manual and automated procedures for validating correctness of program code, including syntactical and execution issues
Testing Syntax – grammatical rules applied to programming languages
Testing Execution – logic and performance of the software during operation
14-12Chapter 14 © Prentice Hall, 2004
Tests can be manual or automated, and may or may not involve code execution.
14-13Chapter 14 © Prentice Hall, 2004
Tests Without Program ExecutionTests Without Program Execution
Inspections (manual) Participants examine program code for
predictable, language-specific errors
Syntax checking (automated) Compiler or interpreter tests source code for
grammatical errors while translating to executable format
14-14Chapter 14 © Prentice Hall, 2004
Manual Tests With Program Manual Tests With Program ExecutionExecution
Desk checking Trace through the logic of the code, identifying
possible logical errors (paper and pencil)
Walkthroughs Like desk-checking, but in a group-oriented,
more structured process
14-15Chapter 14 © Prentice Hall, 2004
Code walkthrough is one of many types of structured walkthroughs.
14-16Chapter 14 © Prentice Hall, 2004
Automated Tests With Program Automated Tests With Program ExecutionExecution
Unit tests – a module tested in isolation for internal consistency
Integration tests – testing all modules and components of the application together for interaction compatibilities
System tests – testing all programs and applications together to ensure performance and reliability
Acceptance tests – user-satisfaction tests
14-17Chapter 14 © Prentice Hall, 2004
A test case is a specific scenario of transactions, queries, or navigation paths that represent a typical, abnormal, or critical use of the system.
Allows repeated testing with each application change
14-18Chapter 14 © Prentice Hall, 2004
What Is Installation?What Is Installation? The organizational process of turning over
from the old information system to the new Types:
Direct Parallel Single location Phased
14-19Chapter 14 © Prentice Hall, 2004
Direct – Cold turkey, low cost, greater impact of errors
14-20Chapter 14 © Prentice Hall, 2004
Parallel – old and new coexist, minimize error impact, high cost in system resources
14-21Chapter 14 © Prentice Hall, 2004
Single Location – Pilot approach, allows learning and minimizes error impact, lower resource demand than parallel, difficult to coordinate and maintain
14-22Chapter 14 © Prentice Hall, 2004
Phased – Staged and incremental, supports phased system development, minimize error impact, difficult to coordinate old components and new components
14-23Chapter 14 © Prentice Hall, 2004
Types of DocumentationTypes of Documentation
System – detailed information about a system’s design specifications, its inner workings, and its functionality
User – written or other visual information about an application system, how it works, and how to use it.
14-24Chapter 14 © Prentice Hall, 2004
Types of System DocumentationTypes of System Documentation
Internal – comments in source code, generated during the coding process or automatically by software compilers or documenters
External – outcomes of all structured diagrams, including use cases, design classes, activity and sequence diagrams, etc.
14-25Chapter 14 © Prentice Hall, 2004
User documentation is often in the form of online help, sometimes with Web connections for further information.
14-26Chapter 14 © Prentice Hall, 2004
What Is Training and Support?What Is Training and Support?
Providing on-going educational and problem-solving assistance to information systems users
Training and support material and jobs must be designed along with the associated information systems
14-27Chapter 14 © Prentice Hall, 2004
Training methods can be interpersonal, manual, or automated.
14-28Chapter 14 © Prentice Hall, 2004
Electronic Performance Support Systems (EPSS), like Microsoft Office Assistant, are components of software applications that embed training and information for the user, in the form of tutorials, expert systems, and hyperlink jumps to reference topics.
14-29Chapter 14 © Prentice Hall, 2004
Help Desks and Information Help Desks and Information CentersCenters
Help desk – a single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department
Information center – an organizational unit whose mission is to support users in exploiting information technology
14-30Chapter 14 © Prentice Hall, 2004
Project Close-DownProject Close-Down
Evaluate team members and reassign Notify affected parties that project has
ended and is in operation mode Conduct post-project reviews with
management and customers Close out customer contract – get sign-off System audit
14-31Chapter 14 © Prentice Hall, 2004
What Is System Maintenance?What Is System Maintenance?
Changes made to a system to fix or enhance its functionality
14-32Chapter 14 © Prentice Hall, 2004
System maintenance operates as repeated, miniaturized systems development cycles.
14-33Chapter 14 © Prentice Hall, 2004
Maintenance requests can be frequent.
Priorities among requests should be made based on the type and urgency of the request.
14-34Chapter 14 © Prentice Hall, 2004
Maintenance Cost FactorsMaintenance Cost Factors
Latent defects (Unknown errors after install)
Number of customers for the system Quality of system documentation Quality of maintenance personnel Availability of automated tools Quality of program code and system design
14-35Chapter 14 © Prentice Hall, 2004
RecapRecap After studying this chapter we learned to:
Describe coding, testing, and converting. Apply four installation strategies. Generate system and user documentation. Compare training modes. Discuss techniques of user support. Discuss maintenance types. Discuss maintenance cost factors.
14-36Chapter 14 © Prentice Hall, 2004
Any Questions?