Presentation is loading. Please wait.

Presentation is loading. Please wait.

CHAPTER 5 SYSTEM IMPLEMENTATION & SUPPORT

Similar presentations


Presentation on theme: "CHAPTER 5 SYSTEM IMPLEMENTATION & SUPPORT"— Presentation transcript:

1 CHAPTER 5 SYSTEM IMPLEMENTATION & SUPPORT
DFC4013 System Analysis & Design

2 SUMMARY This topic describes the tools used in system development, different types of testing that can be performed and the step involves in system installation. This topic also describes systems support and security tasks that continue throughout the useful life of the system. In addition to user support, this chapter discusses maintenance, security and backup.

3 COURSE LEARNING OUTCOME
CLO 1 Explain the concept of System Analysis and Design and project management relating to various model, tools and techniques. (C4, PLO1) CLO 3 Solve a wide range of problem related to analysis, design and construction of system development in a team. (A3, P4, PLO4, PLO9, PLO2)

4 TOPIC 5.1 System Development 5.2 Testing In A Project
5.3 System Implementation 5.4 System Support & Security

5 TOPIC 5.1 SYSTEM DEVELOPMENT

6 System Development Tools
Systems analysts must know how to use a variety of techniques such as modeling, prototyping, and computer-aided systems engineering tools to plan, design, and implement information systems. Systems analysts work with these tools in a team environment, where input from users, managers, and IT staff contributes to the system design.

7 System Development Tools
Modeling Modeling produces a graphical representation of a concept or process that system developers can analyze, test, and modify. Modeling Used to describe and simplify an information system: Business model or Requirements model Describes the information that a system must provide. Data model Describes the data structure and design.

8 System Development Tools
Modeling Object model Describes objects, which combine data and processes. Network model Describes the design and protocols of telecommunication links Process model Describes the logic that programmers use to write code modules

9 System Development Tools
Modeling Modeling techniques, including data flow diagrams and entity relationship diagrams, and unified modeling language diagrams.

10 System Development Tools
Prototyping Prototyping tests system concepts and provide an opportunity to examine input, output, and user interface before final decisions are made. Early working version of an information system PROS CONS Speeds up the development process significantly Important decisions might be made too early, before business or IT issues are thoroughly understood Users interact with Prototype very quickly Users can identify needed changes and refine real requirements

11 System Development Tools
CASE Tools Also called computer-aided software engineering, is a technique that uses powerful software, called CASE tools, to help systems analysts develop and maintain information systems. Framework for systems development and support a wide variety of design methodologies

12 Coding Process Coding is the process of turning program logic into specific instructions that the computer system can execute. Working from a specific design, a programmer uses a programming language to transform program logic into code statements. An individual programmer might create a small program, while larger programs typically are divided into modules that several individuals or groups can work on simultaneously.

13 Coding Process Programming Environment
Each IT department has its own programming environment and standards. Visual Basic, Python, Ruby, and SQL are examples of commonly used programming languages, and many commercial packages use a proprietary set of commands. As the trend toward Internet-based applications continues, HTML/XML, Java, and other Web-centric languages will be used extensively.

14 Coding Process Programming Environment
To simplify the integration of system components and reduce code development time, many programmers use an integrated development environment (IDE). IDEs can make it easier to program interactive software products by providing built-in tools and advanced features, such as real-time error detection, syntax hints, highlighted code, class browsers, and version control.

15 Coding Process Programming Environment
IBM WebSphere and Microsoft .NET are popular IDEs. In addition to these commercial packages, programmers can use open source IDEs such as Java-based NetBeans IDE and Eclipse.

16 Coding Process Generating Code
You learned in earlier chapters that systems analysts use application generators, report writers, screen generators, fourth-generation languages, and other CASE tools that produce code directly from program design specifications. Some commercial applications can generate editable program code directly from macros, keystrokes, or mouse actions.

17 TOPIC 5.2 TESTING IN A PROJECT

18 Software Quality Assurance
Importance of software quality assurance Knowing that the quality of your software is up to the mark is extremely important. Studies have shown that most installations are not done right just in the first time. This result to incurring of damage repair expenses. You can avoid this by hiring a professional testing company that will test your software and give your software quality assurance.

19 Software Quality Assurance
Importance of software quality assurance A software testing and quality assurance company specifications and give you a report detailing out the findings. Getting a software quality assurance test done before making your website live will help you in plugging in all the loopholes that could cause losses to your business.

20 Types Of Software Testing
Unit testing Integration testing System testing

21 Types Of Software Testing
Unit Testing The testing of an individual program or module is called unit testing. The objective is to identify and eliminate execution errors that could cause the program to terminate abnormally, and logic errors that could have been missed during desk checking. Test data should contain both correct data and erroneous data and should test all possible situations that could occur.

22 Types Of Software Testing
Unit Testing For example, for a field that allows a range of numeric values, the test data should contain minimum values, maximum values, values outside the acceptable range, and alphanumeric characters. During testing, programmers can use software tools to determine the location and potential causes of program errors.

23 Types Of Software Testing
Unit Testing During unit testing, programmers must test programs that interact with other programs and files individually, before they are integrated into the system. This requires a technique called stub testing. In stub testing, the programmer simulates each program outcome or result and displays a message to indicate whether or not the program executed successfully. Each stub represents an entry or exit point that will be linked later to another program or data file

24 Types Of Software Testing
Unit Testing To obtain an independent analysis, someone other than the programmer who wrote the program usually creates the test data and reviews the results. Systems analysts frequently create test data during the systems design phase as part of an overall test plan. A test plan consists of detailed procedures that specify how and when the testing will be performed, who will participate, and what test data will be used.

25 Types Of Software Testing
Unit Testing A comprehensive test plan should include scenarios for every possible situation the program could encounter. Regardless of who creates the test plan, the project manager or a designated analyst also reviews the final test results. Some organizations also require users to approve final unit test results.

26 Types Of Software Testing
Integration Testing Testing two or more programs that depend on each other is called integration testing, or link testing. For example, consider an information system with a program that checks and validates customer credit status, and a separate program that updates data in the customer master file. The output from the validation program becomes input to the master file update program.

27 Types Of Software Testing
Integration Testing Testing the programs independently does not guarantee that the data passed between them is correct. Only by performing integration testing for this pair of programs can you make sure that the programs work together properly.

28 Types Of Software Testing
Integration Testing Systems analysts usually develop the data they use in integration testing. As is the case with all forms of testing, integration test data must consider both normal and unusual situations. For example, integration testing might include passing typical records between two programs, followed by blank records, to simulate an unusual event or an operational problem.

29 Types Of Software Testing
Integration Testing You should use test data that simulates actual conditions because you are testing the interface that links the programs. A testing sequence should not move to the integration test stage unless it has performed properly in all unit tests.

30 Types Of Software Testing
System Testing After completing integration testing, you must perform system testing, which involves the entire information system. A system test includes all typical processing situations and is intended to assure users, developers, and managers that the program meets all specifications and that all necessary features have been included.

31 Types Of Software Testing
System Testing During a system test, users enter data, including samples of actual, or live, data, perform queries, and produce reports to simulate actual operating conditions. All processing options and outputs are verified by users and the IT project development team to ensure that the system functions correctly. Commercial software packages must undergo system testing similar to that of in-house developed systems, although unit and integration testing usually are not performed.

32 Types Of Software Testing
System Testing Regardless of how the system was developed, system testing has the following major objectives: Perform a final test of all programs Verify that the system will handle all input data properly, both valid and invalid Ensure that the IT staff has the documentation and instructions needed to operate the system properly and that backup and restart capabilities of the system are adequate

33 Types Of Software Testing
System Testing Regardless of how the system was developed, system testing has the following major objectives: Demonstrate that users can interact with the system successfully Verify that all system components are integrated properly and that actual processing situations will be handled correctly Confirm that the information system can handle predicted volumes of data in a timely and efficient manner

34 Types Of Software Testing
System Testing Successful completion of system testing is the key to user and management approval, which is why system tests sometimes are called acceptance tests. Final acceptance tests, however, are performed during systems installation and evaluation.

35 Types Of Software Testing

36 Documentation Documentation describes an information system and helps the users, managers, and IT staff who must interact with it. Accurate documentation can reduce system downtime, cut costs, and speed up maintenance tasks. Documentation is essential for successful system operation and maintenance. In addition to supporting a system’s users, accurate documentation is essential for IT staff members who must modify the system, add a new feature, or perform maintenance.

37 Documentation Documentation includes program documentation
system documentation operations documentation user documentation

38 Documentation Program documentation
Program documentation describes the inputs, outputs, and processing logic for all program modules. The program documentation process starts in the systems analysis phase and continues during systems implementation. Systems analysts prepare overall documentation, such as process descriptions and report layouts, early in the SDLC.

39 Documentation Program documentation
This documentation guides programmers, who construct modules that are well supported by internal and external comments and descriptions that can be understood and maintained easily. A systems analyst usually verifies that program documentation is complete and accurate. System developers also use defect tracking software, sometimes called bug tracking software, to document and track program defects, code changes, and replacement code, called patches.

40 Documentation System documentation
System documentation describes the system’s functions and how they are implemented. System documentation includes data dictionary entries, data flow diagrams, object models, screen layouts, source documents, and the systems request that initiated the project. System documentation is necessary reference material for the programmers and analysts who must support and maintain the system. Most of the system documentation is prepared during the systems analysis and design phases.

41 Documentation System documentation
During the systems implementation phase, an analyst must review prior documentation to verify that it is complete, accurate, and up to date, including any changes made during the implementation process. For example, if a screen or report has been modified, the analyst must update the documentation. Updates to the system documentation should be made in a timely manner to prevent oversights.

42 Documentation Operation documentation
If the information system environment involves a minicomputer, a mainframe, or centralized servers, the analyst must prepare documentation for the IT group that supports centralized operations. A mainframe installation might require the scheduling of batch jobs and the distribution of printed reports. In this type of environment, the IT operations staff serves as the first point of contact when users experience problems with the system.

43 Documentation Operation documentation
Operations documentation contains all the information needed for processing and distributing online and printed output. Typical operations documentation includes the following information: Program, systems analyst, programmer, and system identification Scheduling information for printed output, such as report run frequency and deadlines Input files and where they originate; and output files and destinations

44 Documentation Operation documentation
Typical operations documentation includes the following information: and report distribution lists Special forms required, including online forms Error and informational messages to operators and restart procedures Special instructions, such as security requirements

45 Documentation Operation documentation
Operations documentation should be clear, concise, and available online if possible. If the IT department has an operations group, you should review the documentation with them, early and often, to identify any problems. If you keep the operations group informed at every phase of the SDLC, you can develop operations documentation as you go along.

46 Documentation User documentation
User documentation consists of instructions and information to users who will interact with the system and includes user manuals, Help screens, and tutorials. The skill set required to develop documentation usually is not the same as that to develop a system. Technical writing requires specialized skills, and competent technical writers are valuable members of the IT team.

47 Documentation User documentation
Just as you cannot throw a system together in several days, you cannot add documentation at the end. That is a common misconception and often proves fatal to a project. While that has always been true of software user documentation, this is an even more critical issue now that online Help and context-sensitive Help so often are needed.

48 Documentation User documentation
Regardless of the delivery method, user documentation must be clear, understandable, and readily accessible to users at all levels. Context-sensitive Help is part of the program. You must put coded callouts in the text that link to the correct page of information in the documentation.

49 Documentation User documentation
Systems analysts usually are responsible for preparing documentation to help users learn the system. In larger companies, a technical support team that includes technical writers might assist in the preparation of user documentation and training materials. Regardless of the delivery method, user documentation must be clear, understandable, and readily accessible to users at all levels.

50 Documentation User documentation
User documentation includes the following: A system overview that clearly describes all major system features, capabilities, and limitations Description of source document content, preparation, processing, and samples Overview of menu and data entry screen options, contents, and processing instructions Examples of reports that are produced regularly or available at the user’s request, including samples Security and audit trail information

51 Documentation User documentation
User documentation includes the following: Explanation of responsibility for specific input, output, or processing requirements Procedures for requesting changes and reporting problems Examples of exceptions and error situations Frequently asked questions (FAQs) Explanation of how to get help and procedures for updating the user manual

52 Documentation User documentation
Most users prefer online documentation, which provides immediate Help when they have questions or encounter problems. Many users are accustomed to context-sensitive help screens, hints and tips, hypertext, on-screen demos, and other user-friendly features commonly found in popular software packages; they expect the same kind of support for in- house developed software.

53 Documentation User documentation
Effective online documentation is an important productivity tool because it empowers users and reduces the time that IT staff members must spend in providing telephone, , or face-to-face assistance. Although online documentation is essential, written documentation material also is valuable, especially in training users and for reference purposes.

54 Documentation User documentation
No matter what form of user documentation your system will require, you must keep in mind that it can take a good deal of time to develop. The time between finishing software coding and the time when a complete package — including documentation — can be released to users is entirely dependent on how well the documentation is thought out in advance.

55 SYSTEM IMPLEMENTATION
TOPIC 5.3 SYSTEM IMPLEMENTATION

56 System Implementation
Managing systems implementation involves application development, testing, documentation, training, data conversion, system changeover, and post-implementation evaluation of the results. During systems implementation, the system design specification serves as a blueprint for constructing the new system. The initial task is application development, which requires systems analysts and programmers to work together to construct the necessary programs and code modules.

57 System Implementation
Before a changeover, the system must be tested and documented carefully, users must be trained, and existing data must be converted. After the new system is operational, a formal evaluation of the results takes place as part of a final report to management

58 System Installation & Evaluation
The new system now is ready to go to work. Your earlier design activities produced the overall architecture and processing strategy, and you consulted users at every stage of development. You developed and tested programs individually, in groups, and as a complete system. You prepared the necessary documentation and checked it for accuracy, including support material for IT staff and users.

59 System Installation & Evaluation
Remaining steps in systems implementation: Prepare a separate operational and test environment Provide training for users, managers, and IT staff Perform data conversion and system changeover Carry out post-implementation evaluation of the system Present a final report to management

60 System Installation & Evaluation
Operational & test environment An environment, or platform, is a specific combination of hardware and software. The environment for the actual system operation is called the operational environment or production environment. The environment that analysts and programmers use to develop and maintain programs is called the test environment.

61 System Installation & Evaluation
Operational & test environment A separate test environment is necessary to maintain system security and integrity and protect the operational environment. Access to the operational environment is limited to users and must strictly be controlled. Systems analysts and programmers should not have access to the operational environment except to correct a system problem or to make authorized modifications or enhancements. IT department members have no reason to access the day-to-day operational system.

62 System Installation & Evaluation
Operational & test environment Access to the operational environment is limited to users and must strictly be controlled. Systems analysts and programmers should not have access to the operational environment except to correct a system problem or to make authorized modifications or enhancements. Otherwise, IT department members have no reason to access the day-to-day operational system.

63 System Installation & Evaluation
Operational & test environment The test environment for an information system contains copies of all programs, procedures, and test data files. Before making any changes to an operational system, you must verify them in the test environment and obtain user approval.

64 System Installation & Evaluation
Operational & test environment

65 System Installation & Evaluation
Operational & test environment The operational environment includes hardware and software configurations and settings, system utilities, telecommunications resources, and any other components that might affect system performance. If you have to build or upgrade network resources to support the new system, you must test the platform rigorously before system installation begins

66 System Installation & Evaluation
Training No system can be successful without proper training, whether it involves software, hardware, or manufacturing. A successful information system requires training for users, managers, and IT staff members. The entire systems development effort can depend on whether or not people understand the system and know how to use it effectively.

67 System Installation & Evaluation
Training Training plan The three main groups for training are users, managers, and IT staff You must determine how the company will provide training

68 System Installation & Evaluation
Training Vendor Training If the system includes the purchase of software or hardware, then vendor-supplied training is one of the features you should investigate in the RFPs (requests for proposal) and RFQs (requests for quotation) that you send to potential vendors Often gives the best return on your training dollars

69 System Installation & Evaluation
Training Webinars, Podcasts, and Tutorials Many vendors offer Web-based training options, including Webinars, podcasts, and tutorials A Webinar, which combines the words Web and seminar, is an Internet-based training session that provides an interactive experience. A podcast refers to a Web-based broadcast that allows a user to download multimedia files to a PC or portable device. A tutorial is a series of online interactive lessons that present material and provide a dialog with users.

70 System Installation & Evaluation
Training Outside Training Resources You also can look into an independent training firm to provide in-house hardware or software training. If vendor training is not practical and your organization does not have the internal resources to perform the training, you might find that outside training consultants. Many training consultants, institutes, and firms are available that provide either standardized or customized training packages

71 System Installation & Evaluation
Training Training Tips Train people in groups, with separate training programs for distinct groups Select the most effective place to conduct the training Provide for learning by hearing, seeing, and doing Prepare effective training materials, including interactive tutorials Rely on previous trainees

72 System Installation & Evaluation
Training Interactive Training Usually, a relationship exists between training methods and costs Online training Should include step-by-step instructions Video tutorials You don’t have to be a professional video developer to create effective training tutorials

73 System Installation & Evaluation
Data conversion During data conversion, existing data is loaded into the new system. Depending on the system, data conversion can be done before, during, or after the operational environment is complete. You should develop a data conversion plan as early as possible, and the conversion process should be tested when the test environment is developed.

74 System Installation & Evaluation
Data conversion The old system might be capable of exporting data in an acceptable format for the new system or in a standard format such as ASCII or ODBC If a standard format is not available, you must develop a program to extract the data and convert it Often requires additional data items, which might require manual entry

75 System Installation & Evaluation
Data conversion You must ensure that all system control measures are in place and operational to protect data from unauthorized access and to help prevent erroneous input Some errors will occur It is essential that the new system be loaded with accurate, error-free data

76 System Installation & Evaluation
System changeover System changeover is the process of putting the new information system online and retiring the old system. Changeover can be rapid or slow, depending on the method. The four changeover methods are direct cutover parallel operation pilot operation phased operation

77 System Installation & Evaluation
System changeover Direct cutover is similar to throwing a switch that instantly changes over from the old system to the new. Parallel operation requires that both systems run simultaneously for a specified period, which is the slowest method. The other methods, pilot and phased operation, fall somewhere between direct cutover and parallel operation.

78 System Installation & Evaluation
System changeover

79 System Installation & Evaluation
System changeover Direct Cutover Involves more risk than other changeover methods Companies often choose the direct cutover method for implementing commercial software packages Cyclical information systems usually are converted using the direct cutover method at the beginning of a quarter, calendar year, or fiscal year

80 System Installation & Evaluation
System changeover Parallel Operation Easier to verify that the new system is working properly under parallel operation than under direct cutover Running both systems might place a burden on the operating environment and cause processing delay Is not practical if the old and new systems are incompatible technically Also is inappropriate when the two systems perform different functions

81 System Installation & Evaluation
System changeover Pilot Operation The group that uses the new system first is called the pilot site The old system continues to operate for the entire organization After the system proves successful at the pilot site, it is implemented in the rest of the organization, usually using the direct cutover method Is a combination of parallel operation and direct cutover methods

82 System Installation & Evaluation
System changeover Phased Operation You give a part of the system to all users The risk of errors or failures is limited to the implemented module only Is less expensive than full parallel operation Is not possible, however, if the system cannot be separated easily into logical modules or segments

83 System Installation & Evaluation
System changeover

84 System Installation & Evaluation
Post-implementation task Once the new system is operational, you must perform two additional tasks: Prepare a post-implementation evaluation Deliver a final report to management.

85 System Installation & Evaluation
Post-implementation task Post-Implementation Evaluation A post-implementation evaluation should examine all aspects of the development effort and the end product — the developed information system You can apply the same fact-finding techniques in a post-implementation evaluation that you used to determine the system requirements during the systems analysis phase

86 System Installation & Evaluation
Post-implementation task Final Report to Management Your report should include the following: Final versions of all system documentation Planned modifications and enhancements to the system that have been identified Recap of all systems development costs and schedules Comparison of actual costs and schedules to the original estimates Post-implementation evaluation, if it has been performed Marks the end of systems development work

87 SYSTEM SUPPORT & SECURITY
TOPIC 5.4 SYSTEM SUPPORT & SECURITY

88 System Support & Security Phase
Managing systems support and security involves three main concerns: user expectations system performance security requirements . Successful, robust systems often need the most support In most organizations, more than half of all IT department effort goes into supporting existing systems

89 System Support & Security Phase
The systems support and security phase begins when a system becomes operational and continues until the system reaches the end of its useful life After delivering the system, the IT team focuses on support and maintenance tasks

90 User Support Companies provide user support in many forms, including user training and a help desk to provide technical support and assistance.

91 User Training User Training Package.
Depending on the nature of the changes, the package could include online support via , a special Web site, a revision to the user guide, a training manual supplement, or formal training sessions. Training users about system changes is similar to initial training. The main objective is to show users how the system can help them perform their jobs.

92 Help Desks A help desk is a centralized resource staffed by IT professionals who provide users with the support they need to do their jobs. A help desk has three main objectives: Show people how to use system resources more effectively, Provide answers to technical or operational questions Make users more productive by teaching them how to meet their own information needs. A help desk can boost its productivity by using remote control software, which allows IT staff to take over a user’s workstation and provide support and troubleshooting.

93 The help desk staff might have to perform the following tasks:
Show a user how to create a data query or report that displays specific business information Resolve network access or password problems Demonstrate an advanced feature of a system or a commercial package Help a user recover damaged data Offer tips for better operation Explain an undocumented software feature Show a user how to use Web conferencing Explain how to access the company’s intranet or the Internet Assist a user in developing a simple database to track time spent on various projects Answer questions about software licensing and upgrades Provide information about system specifications and the cost of new hardware or software Recommend a system solution that integrates data from different locations to solve a business problem Provide hardware support by installing or reconfiguring devices such as scanners, printers, network cards, wireless devices, optical drives, backup devices, and multimedia systems Show users how to maintain data consistency and integrity among a desktop computer, a notebook computer, and a handheld computer or smart phone Troubleshoot software issues via remote control utilities

94 Types Of Maintenance Maintenance activities include:
Changing programs, procedures, or documentation to ensure correct system performance. Adapting the system to changing requirements; and making the system operate more efficiently.

95

96 System Maintenance Tools
Many CASE tools include system evaluation and maintenance features, including the following examples: • Performance monitor that provides data on program execution times • Program analyzer that scans source code, provides data element cross-reference information, and helps evaluate the impact of a program change Interactive debugging analyzer that locates the source of a programming error Reengineering tools Automated documentation Network activity monitor Workload forecasting tool

97 System Security Concepts
Integrity prevents unauthorized users from creating, modifying, or deleting information. System Security Concepts Confidentiality protects information from unauthorized disclosure and safeguards privacy. Availability ensures that authorized users have timely and reliable access to necessary information.

98 BACKUP AND RECOVERY Backup refers to copying data at prescribed intervals, or continuously. Recovery involves restoring the data and restarting the system after an interruption.

99


Download ppt "CHAPTER 5 SYSTEM IMPLEMENTATION & SUPPORT"

Similar presentations


Ads by Google