The programmer corrects the errors until the program executes properly. Next, the programmer desk checks the program. Desk checking is the process of reviewing the program code to spot logic errors , which produce incorrect results.
This process can be performed by the person who wrote the program or by other programmers. Many organizations require a more formal type of desk checking called a structured walkthrough , or code review. Typically, a group of three to five IT staff members participate in code review.
The group usually consists of project team members and might include other programmers and analysts who did not work on the project. The objective is to have a peer group identify errors, apply quality standards, and verify that the program meets the requirements of the system design specification.
Errors found during a structured walk-through are easier to fix while coding is still in the developmental stages. In addition to analyzing logic and program code, the project team usually holds a session with users called a design walkthrough , to review the interface with a cross-section of people who will work with the new system and ensure that all necessary features have been included.
This is a continuation of the modeling and prototyping effort that began early in the systems development process. The next step in application development is to initiate a sequence of unit testing, integration testing, and system testing, as shown in Figure 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. The company is in the final stages of developing a new inventory management system, and April wants you to handle the testing. Should you try to invent every possible data error?
Consider the problem, develop an approach, and write up your plan in a brief memo. Test data should contain both correct data and erroneous data and should test all possible situations that could occur. 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. 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.
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.
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. 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. 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. Figure shows integration testing for several groups of programs. Notice that a program can have membership in two or more groups. 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.
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. After completing integration testing, you must perform system testing , which involves the entire information system, as shown in Figure on page 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.
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.
Regardless of how the system was developed, system testing has the following major objectives:. 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, which is described later in this chapter. How much testing is necessary? The answer depends on the situation and requires good judgment and input from other IT staff members, users, and management, as shown in Figure Unfortunately, IT project managers often are pressured to finish testing quickly and hand the system over to users.
Common reasons for premature or rushed testing are demands from users, tight systems development budgets, and demands from top management to finish projects early. Those pressures hinder the testing process and often have detrimental effects on the final product.
You should regard thorough testing as a cost-effective means of providing a quality product. Every error caught during testing eliminates potential expenses and operational problems. Often, errors go undetected until the system becomes operational. Errors that affect the integrity or accuracy of data must be corrected immediately.
Minor errors, such as typographical errors in screen titles, can be corrected later. Some users want a system that is a completely finished product, while others realize that minor changes can be treated as maintenance items after the system is operational.
In the final analysis, you must decide whether or not to postpone system installation if problems are discovered. If conflicting views exist, management will decide whether or not to install the system after a full discussion of the options. As a new systems analyst, you suspect that testing Web-based systems probably involves a different set of tools and techniques, compared to testing traditional LAN-based systems.
Your idea is to identify and purchase various Web site testing tools that currently are available, then use these tools as a Web site testing consultant. No one in your area offers this type of consulting service, so you have high hopes. Now, you need to perform Internet research to learn more about Web testing software that is available.
For each product, write up a brief description of its overall purpose, its features and benefits, its cost, and how it would fit into your business game plan. 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. Figure on the next page shows an example of software that can automate the documentation process and help software developers generate accurate, comprehensive reference material.
Documentation is essential for successful system operation and maintenance. Documentation includes program documentation, system documentation, operations documentation, and user 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.
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.
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 systems design phases. 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. 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. Operations documentation contains all the information needed for processing and distributing online and printed output. Typical operations documentation includes the following information:.
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.
User documentation consists of instructions and information to users who will interact with the system and includes user manuals, Help screens, and tutorials. Programmers or systems analysts usually create program documentation and system documentation. To produce effective and clear user documentation — and hence have a successful project — you need someone with expert skills in this area doing the development, just as you need someone with expert skills developing the software. The skill set required to develop documentation usually is not the same as that to develop a system.
This is particularly true as you move into the world of online documentation, which needs to coordinate with print documentation and intranet and Internet information. Technical writing requires specialized skills, and competent technical writers are valuable members of the IT team. 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.
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. To try to go back and add this after the fact would take a great deal of time; depending on the project size, it could take months! Additionally, it could introduce other coding errors — and it all has to be tested as well.
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.
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. If the system will include online documentation, that fact needs to be identified as one of the system requirements.
If the documentation will be created by someone other than the analysts who are developing the system, that person or group needs to be involved as early as possible to become familiar with the software and begin developing the required documentation and support material. In addition, system developers must determine whether the documentation will be available from within the program, or as a separate entity in the form of a tutorial, slide presentation, reference manual, or Web site.
If necessary, links should be created within the program that will take the user to the appropriate 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, e-mail, or face-to-face assistance. Interactive tutorials are especially popular with users who like to learn by doing, and visual impact is very important.
The star of the series is Duane Nickulls. In addition to being an Adobe expert, he describes himself as a professional musician and an extreme athlete. The videos are an excellent example of cutting edge tutorial methods. In addition to program-based assistance, the Internet offers an entirely new level of comprehensive, immediate support. Many programs include links to Web sites, intranet sites, and Internet-based technical support. For example, the Cisco Systems site shown in Figure offers a wide range of support services and social media links that allow Cisco users to collaborate and share their knowledge.
Although online documentation is essential, written documentation material also is valuable, especially in training users and for reference purposes. A sample page from a user manual is shown in Figure on page Systems analysts or technical writers usually prepare the manual, but many companies invite users to review the material and participate in the development process.
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. If the completion of your project includes providing user documentation, this issue needs to be addressed from the very beginning of the project.
Determining what the user documentation requirements are and ascertaining who will complete the documents is critical to a timely release of the project. Neglecting user documentation issues until after all the program is complete often leads to one of two things: 1 The documentation will be thrown together quickly just to get it out the door on time, and it more than likely will be inadequate; or 2 it will be done correctly, and the product release will be delayed considerably.
The instructions explain bow to add a new task to the system. User training typically is scheduled when the system is installed; the training sessions offer an ideal opportunity to distribute the user manual and explain the procedures for updating it in the future.
Training for users, managers, and IT staff is described later in this chapter. After system testing is complete, you present the results to management. You should describe the test results, update the status of all required documentation, and summarize input from users who participated in system testing.
You also must provide detailed time schedules, cost estimates, and staffing requirements for making the system fully operational. If system testing produced no technical, economical, or operational problems, management determines a schedule for system installation and evaluation.
The following sections describe system installation and evaluation tasks that are performed for every information systems project, whether you develop the application in-house or purchase it as a commercial package. 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. Now, you will carry out the remaining steps in systems implementation:. You learned earlier that 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.
A separate test environment is necessary to maintain system security and integrity and protect the operational environment. Typically, the test environment resides on a limited-access workstation or server located in the IT department. 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. 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.
Figure shows the differences between test environments and operational environments. Notice that access to the test environment is limited to IT staff, while the operational environment is restricted to users.
An effective testing process is essential, whether you are examining an information system or a batch of computer chips. Every experienced systems analyst can tell you a story about an apparently innocent program change that was introduced without being tested properly.
In those stories, the innocent change invariably ends up causing some unexpected and unwanted changes to the program. After any modification, you should repeat the same acceptance tests you ran when the system was developed. By restricting access to the operational area and performing all tests in a separate environment, you can protect the system and avoid problems that could damage data or interrupt operations.
The operational environment includes hardware and software configurations and settings, system utilities, telecommunications resources, and any other components that might affect system performance. You should check all communications features in the test environment carefully, and then check them again after loading the applications into the operational environment. Your documentation should identify all network specifications and settings, including technical and operational requirements for communications hardware and software.
If you have to build or upgrade network resources to support the new system, you must test the platform rigorously before system installation begins. No system can be successful without proper training, whether it involves software, hardware, or manufacturing, as shown in Figure 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. You should start to consider a training plan early in the systems development process. As you create documentation, you should think about how to use the material in future training sessions.
When you implement the system, it is essential to provide the right training for the right people at the right time. The first step is to identify who should receive training and what training is needed. You must look carefully at the organization, how the system will support business operations, and who will be involved or affected. Figure shows specific training topics for users, managers, and IT staff. Notice that each group needs a mix of general background and detailed information to understand and use the system.
As shown in Figure , the three main groups for training are users, managers, and IT staff. A manager does not need to understand every submenu or feature, but he or she does need a system overview to ensure that users are being trained properly and are using the system correctly. Similarly, users need to know how to perform their day-to-day job functions, but do not need to know how the company allocates system operational charges among user departments.
IT staff people probably need the most information. To support the new system, they must have a clear understanding of how the system functions, how it supports business requirements, and the skills that users need to operate the system and perform their tasks. Users, managers, and IT staff members have different training needs.
After you identify the objectives, you must determine how the company will provide training. The main choices are to obtain training from vendors, outside training firms, or use IT staff and other in-house resources. If the system includes the purchase of software or hardware, then vendor-supplied training is one of the features you should include in the RFPs requests for proposal and RFQs requests for quotation that you send to potential vendors.
Many hardware and software vendors offer training programs free or at a nominal cost for the products they sell. In other cases, the company might negotiate the price for training, depending on their relationship with the vendor and the prospect of future purchases. If a large number of people need training, you might be able to arrange classes at your location.
Vendor training often gives the best return on your training dollars because it is focused on products that the vendor developed.
You might have to supplement the training in-house, especially if your IT staff customized the package. 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. Most Webinars are scheduled events with a group of preregistered users and an online presenter or instructor.
A pre-recorded Webinar session also can be delivered as a Webcast , which is a one-way transmission, whenever a user wants or needs training support. A podcast refers to a Web-based broadcast that allows a user to download multimedia files to a PC or portable device. An advantage of a podcast is that subscribers can access the recorded material anywhere, anytime. A tutorial is a series of online interactive lessons that present material and provide a dialog with users. A tutorial example is included in the in-house training section.
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 are a desirable alternative.
The rapid expansion of information technology has produced tremendous growth in the computer-training field.
Many training consultants, institutes, and firms are available that provide either standardized or customized training packages. If you decide to investigate outside training resources, you can contact a training provider and obtain references from clients. You also can seek assistance from nonprofit sources with an interest in training, including universities, industry associations, and information management organizations. The IT staff and user departments often share responsibility for developing and conducting training programs for internally developed software.
If your organization has a service desk, the staff might be able to handle user training. Multimedia is an effective training method. Presentation software, such as Microsoft PowerPoint, Apache OpenOffice Impress, or Corel Presentations, allows you to design training sessions that combine slides, animation, and sound.
You also can use programs that capture actual keystrokes and mouse actions, and then replay the screens as a demonstration for users. If your firm has a media or graphic arts group, they can help you prepare training aids such as videotapes, charts, and other instructional materials.
When developing a training program, you should keep the following guidelines in mind. Group training, as shown in Figure , makes the most efficient use of time and training facilities.
In addition, if the group is small, trainees can learn from the questions and problems of others. A training program must address the job interests and skills of a wide range of participants. For example, IT staff personnel and users require very different information. Problems often arise when some participants have technical backgrounds and others do not.
Employees incur no travel expense, they can respond to local emergencies that require immediate attention, and training can take place in the actual environment where the system will operate. You can encounter some disadvantages, however. Employees who are distracted by telephone calls and other duties will not get the full benefit of the training.
The testing team starts testing the functionality of the entire system. This is done to verify that the entire application works according to the customer requirement.
The development team fixes the bug and send back to QA for a re-test. This process continues until the software is bug-free, stable, and working according to the business needs of that system. Once the software testing phase is over and no bugs or errors left in the system then the final deployment process starts. Based on the feedback given by the project manager, the final software is released and checked for deployment issues if any. Once the system is deployed, and customers start using the developed system, following 3 activities occur.
The main focus of this SDLC phase is to ensure that needs continue to be met and that the system continues to perform as per the specification mentioned in the first phase. The waterfall is a widely accepted SDLC model. In this approach, the whole process of the software development is divided into various phases of SDLC. In this SDLC model, the outcome of one phase acts as the input for the next phase.
This SDLC model is documentation-intensive, with earlier phases documenting what need be performed in the subsequent phases. The incremental model is not a separate model. It is essentially a series of waterfall cycles. The requirements are divided into groups at the start of the project.
For each group, the SDLC model is followed to develop software. The SDLC life cycle process is repeated, with each release adding more functionality until all requirements are met. In this method, every cycle act as the maintenance phase for the previous software release.
Modification to the incremental model allows development cycles to overlap. Again the operations manager will have to work with the project manager to determine how the software will be rolled out.
This could be one big event for the company or a very slow process that could take months. When a program is rather big for the company the roll-out of the new software will be very slow as they are released phase by phase or the implementation will be conducted one department at a time.
This type of change will foster better adaptability since possible bugs will be fixed before everyone gets to use the software. There is also a possibility that change will be swift if the new software will just be small or everyone is already familiar with software navigation. The operations manager will have to ensure that operations will still continue even though there is a possible need for a downtime in the software.
Training the users should also be taken into consideration when and how will the software be rolled out to each department. But the implementation phase does not end there. When everyone have the software installed, it is time to create a report or feedback regarding the new update.
This is where developers have to sit with the operations manager to receive comments about the new software or if there are any suggested features users expect from the new software which is not present. Although suggestions might come in a little bit early for the developers, these will be treated as updates that they should work on instead of creating a whole new system. Since the new system is already in place, it is just logical to develop tools based on the available software.
Editorial Team — who has written posts on Online Learning. This work includes using a flow chart to ensure that the process of the system is properly organized. The development phase marks the end of the initial section of the process.
Additionally, this phase signifies the start of production. The development stage is also characterized by instillation and change. Focusing on training can be a huge benefit during this phase. Testing may be repeated, specifically to check for errors, bugs and interoperability. This testing will be performed until the end user finds it acceptable. Another part of this phase is verification and validation, both of which will help ensure the program"s successful completion. The sixth phase is when the majority of the code for the program is written.
Additionally, this phase involves the actual installation of the newly-developed system. This step puts the project into production by moving the data and components from the old system and placing them in the new system via a direct cutover. While this can be a risky and complicated move, the cutover typically happens during off-peak hours, thus minimizing the risk.
0コメント