Systems Analysis and Design in a Changing World

  • Slides: 50
Download presentation
Systems Analysis and Design in a Changing World, Fourth Edition 15

Systems Analysis and Design in a Changing World, Fourth Edition 15

Learning Objectives 15 u Describe implementation and support activities u Choose an appropriate approach

Learning Objectives 15 u Describe implementation and support activities u Choose an appropriate approach to program development u Describe various types of software tests, and explain how and why each is used u List various approaches to data conversion and system installation, and describe the advantages and disadvantages of each u Describe different types of documentation and the processes by which they are developed and maintained u Describe training and user support requirements for new and operational systems 2

15 Overview u This chapter focuses on activities of implementation and support phases of

15 Overview u This chapter focuses on activities of implementation and support phases of systems development life cycle (SDLC) u Implementation activities occur before system is turned over to users u Implementation consumes more time and resources than other phases of the SDLC u Support activities occur after system becomes operational and may continue for years Systems Analysis and Design in a Changing World, 4 th Edition 3

Activities of the Implementation and Support Phases Systems Analysis and Design in a Changing

Activities of the Implementation and Support Phases Systems Analysis and Design in a Changing World, 4 th Edition 15 4

15 Program Development u Developing a complex system is inherently difficult process. u Programming

15 Program Development u Developing a complex system is inherently difficult process. u Programming isn`t the only development phase activity, but it is clearly one of the most important. u v Required resources v Managerial complexity v System quality Program development is time consuming and consumes more resources than any other system development activity Systems Analysis and Design in a Changing World, 4 th Edition 5

15 Order of Implementation u Input, process, output (IPO) development: A development order that

15 Order of Implementation u Input, process, output (IPO) development: A development order that implement input modules or program first, process modules or program next and output modules or program last. l Is based on the data flow through a system or program l For structured design and program: IPO ordering can be determined by examining the system flow chart and structure chart. l For OO design: the key issues is to analyze is dependency ( which classes and methods capture or generate data that are needed by other classes and methods). Dependency information is documented in package, sequence and class diagram. Systems Analysis and Design in a Changing World, 4 th Edition 6

15 Order of Implementation (Cont. ) u u l Advantages: User interfaces developed early

15 Order of Implementation (Cont. ) u u l Advantages: User interfaces developed early to allow early testing and user evaluation. l Disadvantage is late implementation of outputs Top-down begins with module at top of structure chart l Advantages: Always a working version of program l Requires three or more iterations to complete Bottom-up begins with modules at lowest level of structure chart l Advantages: Many programmers can begin immediately l Disadvantages: Requires driver programs to test Systems Analysis and Design in a Changing World, 4 th Edition 7

Structure Chart for the Payroll Program 15 (Figure 15 -3) Systems Analysis and Design

Structure Chart for the Payroll Program 15 (Figure 15 -3) Systems Analysis and Design in a Changing World, 4 th Edition 8

Package Diagrams for RMO Subsystems Systems Analysis and Design in a Changing World, 4

Package Diagrams for RMO Subsystems Systems Analysis and Design in a Changing World, 4 th Edition 15 9

Package Diagram for a Three-Layer OO Design Systems Analysis and Design in a Changing

Package Diagram for a Three-Layer OO Design Systems Analysis and Design in a Changing World, 4 th Edition 15 10

15 Construction and Test Plan Construction and Testing are highly interdependent. Plan Construction and

15 Construction and Test Plan Construction and Testing are highly interdependent. Plan Construction and Testing activities early while considering the following: u The development order u The testing order u Data used to test modules, module groups, methods, classes, programs, and subsystems u Acceptance criteria u Relevant personnel assignments (construction and testing) Systems Analysis and Design in a Changing World, 4 th Edition 11

Framework Development u u 15 When developing large OO systems, object frameworks or( foundation

Framework Development u u 15 When developing large OO systems, object frameworks or( foundation classes) Foundation classes typically implemented first l Minimize impact of errors and changes l Reused in many parts of the system and across applications l Assigned to best programmers and thoroughly tested for bugs or other problems before other codes that depends on the foundation classes has been written. Later changes to foundation classes might require significant changes to other code that depends on them Systems Analysis and Design in a Changing World, 4 th Edition 12

Team-Based Program Development u A team of programmers normally works on program development by

Team-Based Program Development u A team of programmers normally works on program development by allowing many portions of the system to be developed simultaneously. u Introduced a set of management issues: u l Organization of programming teams l Task assignment to specific teams or members l Member and team communication and coordination 15 Variety of different models used for organizing teams l Cooperating peer, chief developer, collaborative specialist Systems Analysis and Design in a Changing World, 4 th Edition 13

Comparison and Summary of Development Team Types (Figure 15 -7) Systems Analysis and Design

Comparison and Summary of Development Team Types (Figure 15 -7) Systems Analysis and Design in a Changing World, 4 th Edition 15 14

15 Source Code Control u Development teams need tools to help coordinate their programming

15 Source Code Control u Development teams need tools to help coordinate their programming tasks. u Source code control system (SCCS) (Figure 15 -8 ) l u Automated tool for tracking source code files and controlling changes to those files Repository of code and programmer actions l Check out file in read-only mode l Check out file in read/write mode l Check in a modified file Systems Analysis and Design in a Changing World, 4 th Edition 15

15 Versioning u Mechanism to manage systems changes (rapidly during implementation and more slowly

15 Versioning u Mechanism to manage systems changes (rapidly during implementation and more slowly afterwards). u Complex systems developed, installed, and maintained in series of versions to simplify testing and support l Alpha version – a system that is incomplete but ready for some level of rigorous testing. Lifetime is short l Beta version – a system that is stable enough to be tested by the end-user. Created after a number of Alpha versions have been tested and corrected. l Production release version – a system that is formally distributed to users or made operational. (long-term) l Maintenance release – a system update that provides bug fixes, minor changes to existing features. 16

15 Quality Assurance u Process of ensuring information system meets minimum quality standards determined

15 Quality Assurance u Process of ensuring information system meets minimum quality standards determined by users, implementation staff, management. u QA activities during analysis concentrate on identification of gaps or inconsistencies in system requirements u QA activities during design concentrate on satisfying stated requirements that will lead to easily implemented u QA integrated into project throughout SDLC to build systems correctly form start and to detect and fix errors as soon as possible. u QA activities during implementation consists on testing u Cost of fixing errors rise as project progresses 17

Technical Reviews 15 u Formal or informal reviews of design or construction details by

Technical Reviews 15 u Formal or informal reviews of design or construction details by group of developers u Open design and construction process to input from other people u Other programmers can frequently see errors missed by original programmer ( misspelled keywords, if statement) u Walkthroughs: Are most often used during analysis and design (provide comments and suggestions). u Inspections: A formal review of design or construction details by a group of developers, where each person plays a specific role. u There are very important because they detect errors before code has been written. l Reduce number of errors by factor of 5 to 10 and 18

15 Testing u u u u Process of examining a product to determine if

15 Testing u u u u Process of examining a product to determine if any defects exist Developers can test products by reviewing their construction and composition or by exercising their function and examining the results. Components can be tested individually or in groups or the entire system. Unit testing: testing components individually. Integration testing: testing components in groups. System testing: testing entire system An important part of developing tests is specifying test cases and data. Systems Analysis and Design in a Changing World, 4 th Edition 19

Generic Model of Software Testing 15 (Figure 15 -12) Systems Analysis and Design in

Generic Model of Software Testing 15 (Figure 15 -12) Systems Analysis and Design in a Changing World, 4 th Edition 20

SDLC Phases and Testing Activities Performed Within Each Phase (Figure 15 -14) Systems Analysis

SDLC Phases and Testing Activities Performed Within Each Phase (Figure 15 -14) Systems Analysis and Design in a Changing World, 4 th Edition 15 21

15 Test Cases u Important part of testing is specifying test cases and test

15 Test Cases u Important part of testing is specifying test cases and test data u A test case is a formal description of l A Starting state l One or more events to which software responds l Expected response or ending state u Both starting state and events are represented by a set of test data. u Analysis phase documentation is useful in preparing test cases (use-case driven) u Test data is a set of starting states and events used to test a module, a group of module , or an entire system. 22

15 Unit Testing u Tests individual modules of code or methods before integrating with

15 Unit Testing u Tests individual modules of code or methods before integrating with other modules. u Driver module used for testing (Figure 15 -16) l Sets values of input parameters l Calls module to be tested and passes input parameters l Accepts return parameters from tested module u Stub testing – a module, developed for testing, that simulates the execution or behavior of a module that hasn`t yet been developed. Systems Analysis and Design in a Changing World, 4 th Edition 23

15 Integration Testing u Tests the behavior of a group of modules or methods

15 Integration Testing u Tests the behavior of a group of modules or methods u Used to identify errors that could not be detected by unittesting individual modules or methods. u Tests both normal processing and exceptions u Errors can include l Interface incompatibility: A caller module passes a variable of the wrong data type to a subordinate module. l Incorrect parameter values: A module is passed or returns a value that was unexpected (negative number for a price) l Run-time Exceptions: A module generates an error such as ‘out of memory’ or ‘file already in use’ l Unexpected state interactions 24

System Testing u Tests the behavior of the entire system or independent subsystem u

System Testing u Tests the behavior of the entire system or independent subsystem u Build and smoke test is performed daily to discover any problems with daily builds u l System is completely compiled and linked each day l Battery of tests are run to smoke out problems l Any errors must be from changes made the prior day 15 Complete system testing also performed before acceptance testing Systems Analysis and Design in a Changing World, 4 th Edition 25

Usability Testing u Usability test is a test to determine whether a module, method,

Usability Testing u Usability test is a test to determine whether a module, method, class, subsystem, or system meets user requirements l u u 15 Focus is usually on ease of use Performance test checks time-based requirements l Response time: specifically desired or maximum allowable time limits for software response to queries and updates. l Throughput : specify the desired or maximum number of queries and transactions that must be processed per minute or hour. Acceptance test is system test performed to determine whether system meets user requirements. Typically the last round of testing before a system is handed over to its users. Systems Analysis and Design in a Changing World, 4 th Edition 26

15 Data Conversion u Data needed at system startup and can be obtained from

15 Data Conversion u Data needed at system startup and can be obtained from the following sources: l Files or databases of system being replaced l Manual records l Files or databases of other systems l User feedback during normal system operation u Reuse of existing databases u Reloading u Creating database contents new databases Systems Analysis and Design in a Changing World, 4 th Edition 27

Two Approaches to Reloading Database Content After a Structural Modification Systems Analysis and Design

Two Approaches to Reloading Database Content After a Structural Modification Systems Analysis and Design in a Changing World, 4 th Edition 15 28

15 Installation u After development and testing, system must be put into operation u

15 Installation u After development and testing, system must be put into operation u Important planning considerations l Costs of operating both systems in parallel l Detecting and correcting errors in new system l Potentially disrupting the company and IS operations l Training personnel and customers with new procedures Systems Analysis and Design in a Changing World, 4 th Edition 29

15 Direct Installation u New system installed and quickly made operational u Overlapping u

15 Direct Installation u New system installed and quickly made operational u Overlapping u Both systems turned off systems concurrent for brief time u Advantage to manage – simplicity and fewer logistics issues u Disadvantage – risk due to no backup Systems Analysis and Design in a Changing World, 4 th Edition 30

15 Parallel Installation u Old and new systems operated together for extended period of

15 Parallel Installation u Old and new systems operated together for extended period of time u Advantages – low risk of system failure and continual backup u Disadvantage – cost to operate both systems l Hiring temporary personnel l Acquiring extra space l Increasing managerial and logistical complexity Systems Analysis and Design in a Changing World, 4 th Edition 31

15 Phased Installation u New system installed in series of steps or phases u

15 Phased Installation u New system installed in series of steps or phases u Each phase adds components to existing system u Advantage – reduces risk because phase failure is less serious than system failure u Disadvantage – multiple phases cause more activities, milestones, and management complexity for entire effort Systems Analysis and Design in a Changing World, 4 th Edition 32

Direct Installation and Cutover 15 (Figure 15 -20) Systems Analysis and Design in a

Direct Installation and Cutover 15 (Figure 15 -20) Systems Analysis and Design in a Changing World, 4 th Edition 33

Parallel Installation and Operation 15 (Figure 15 -21) Systems Analysis and Design in a

Parallel Installation and Operation 15 (Figure 15 -21) Systems Analysis and Design in a Changing World, 4 th Edition 34

Phased Installation with Direct Cutover and 15 Parallel Operation (Figure 15 -22) Systems Analysis

Phased Installation with Direct Cutover and 15 Parallel Operation (Figure 15 -22) Systems Analysis and Design in a Changing World, 4 th Edition 35

15 Personnel Issues u Installing new system places demands on personnel l Demanding schedules

15 Personnel Issues u Installing new system places demands on personnel l Demanding schedules l Rapid learning and adaptation l High stress u Planning should anticipate these risks and take measures to mitigate effects u Temporary and contract personnel may be hired during an installation Systems Analysis and Design in a Changing World, 4 th Edition 36

15 Documentation u Automated documentation is standard l Electronic manuals in MS Word or

15 Documentation u Automated documentation is standard l Electronic manuals in MS Word or Adobe PDF format l Hyperlinked documents – Web-browser formatted l Online documentation on vendor Web site l Embedded documentation on CD l Electronic system model stored in graphic formats l Tool-specific system models developed with IDEs, DBMSs, and CASE tools Systems Analysis and Design in a Changing World, 4 th Edition 37

15 System Documentation u Descriptions of system functions, architecture, and construction details u Used

15 System Documentation u Descriptions of system functions, architecture, and construction details u Used by maintenance personnel and future developers u Generated as a by-product of development l Includes source code l Includes analysis and design models u Failure to maintain system documentation compromises value of a system Systems Analysis and Design in a Changing World, 4 th Edition 38

Life Cycle Phases and System Documentation Generated in Each Phase 15 (Figure 15 -23)

Life Cycle Phases and System Documentation Generated in Each Phase 15 (Figure 15 -23) Systems Analysis and Design in a Changing World, 4 th Edition 39

15 User Documentation u Descriptions of how to interact with and maintain the system

15 User Documentation u Descriptions of how to interact with and maintain the system u Used by end users and system operators u Topics include u l Startup and shutdown l Keystrokes, mouse, or command functions to perform specific functions l Program function for specific business procedures l Common errors and correction techniques For ease of use, user documentation includes(table of contents, a general description of the function of the program or system, a glossary and an index. Systems Analysis and Design in a Changing World, 4 th Edition 40

15 Training and User Support u Good documentation can reduce training needs as well

15 Training and User Support u Good documentation can reduce training needs as well as the frequency of support requests. u Without training, user error rates will be high u Training considerations l Frequency and duration of system use l Need to understand system’s business context l Existing computer skills and proficiency l Number of users Systems Analysis and Design in a Changing World, 4 th Edition 41

Typical Activities of End Users and System Operators (Figure 15 -25) Systems Analysis and

Typical Activities of End Users and System Operators (Figure 15 -25) Systems Analysis and Design in a Changing World, 4 th Edition 15 42

15 Ongoing Training and User Support u User support covers training and user assistance

15 Ongoing Training and User Support u User support covers training and user assistance that occurs after installation l Online documentation and troubleshooting ( l Resident experts l Help desk l Technical support Systems Analysis and Design in a Changing World, 4 th Edition 43

15 Maintenance and System Enhancement u Software maintenance : Modification of software after delivery

15 Maintenance and System Enhancement u Software maintenance : Modification of software after delivery to correct faults, improve performance, or adapt the product to a changed environment. u Maintenance activities include the following: l Tracking modification requests and changes l Implementing changes l Monitoring system performance l Upgrading hardware and software l Updating documentation Systems Analysis and Design in a Changing World, 4 th Edition 44

Submitting Change Requests and Error Reports u 15 Most organizations adopt formal change control

Submitting Change Requests and Error Reports u 15 Most organizations adopt formal change control procedures to manage change risks: l Standard change request forms l Review of requests by change control committee l Extensive planning for design and implementation u Approved changes are added to list of pending changes for budgeting, scheduling, planning, and implementation u A separate process is used for error correction Systems Analysis and Design in a Changing World, 4 th Edition 45

Implementing a Change u 15 Planning for a change includes: l Identifying parts of

Implementing a Change u 15 Planning for a change includes: l Identifying parts of system to change or add l Securing resources such as personnel to implement change l Scheduling design and implementation activities l Developing test criteria and test plan for changed system u System documentation is reviewed to determine scope of change u The production system version of the system used day to day. u Test system: copy of the production system that is modified to test changes. 46

A Change Request Example 15 (Figure 15 -26) Systems Analysis and Design in a

A Change Request Example 15 (Figure 15 -26) Systems Analysis and Design in a Changing World, 4 th Edition 47

A Change Review Form (Figure 15 -27) Systems Analysis and Design in a Changing

A Change Review Form (Figure 15 -27) Systems Analysis and Design in a Changing World, 4 th Edition 15 48

15 Upgrading Computing Infrastructure u Infrastructure including Computer hardware, system software ( operating system

15 Upgrading Computing Infrastructure u Infrastructure including Computer hardware, system software ( operating system and DBMSs) and network requires periodic updates for many reasons: l Software maintenance releases l Software version upgrades l Declining system performance u System software updates are risky (application software that worked well with older version might fail when that software is updated. “ test “. u Operational system maintenance ( if it isn`t broken, don`t fix it) Systems Analysis and Design in a Changing World, 4 th Edition 49

Summary u u u u 15 Implementation activities occur after design and before system

Summary u u u u 15 Implementation activities occur after design and before system is turned over to users Implementation is complex l Interdependence of programming, quality assurance, hardware and software installation, documentation, and training Implementation is difficult to manage and is risky l Significant time and resources required l Often affects systems vital to daily operations Software components constructed to l Minimize development resources needed l Maximize ability to test system and control errors l These goals often conflict: trade-off among resources, time, and desire to correct errors Data conversion, installation, documentation, and training follow programming and testing Installed and documented system is prerequisite for complete training Fully populated database needed to begin operation Support activities occur after system becomes operational and might continue for years to support user requirements and reduce operational risk Systems Analysis and Design in a Changing World, 4 th Edition 50