One of the most important aspects of implementation, I think, is user acceptance testing. At the end of the day, systems are made to be used by users. They’re the ones who will be doing work or utilizing the system on a regular basis. When the users can actually get their hands on the system and start working with it, they can decide whether or not their requirements have been met. As the book describes, acceptance testing can be split into two types: alpha and beta. Alpha testing comes first and involves simulated data in a test environment. There are different types of tests that get run during this process, including stress tests, performance tests, recovery testing, and security testing. The goal is to identify bugs and the ways a system will react to different situations. Beta testing is where the actual users get involved. The system is put into their environment with real data and they get to try it out. As the book points out, it’s like a rehearsal. The system, training, documentation, etc. are all evaluated by real users.
I’m sure that user acceptance testing and actually getting users to accept a system can be a challenging, long process. But systems that skip it entirely are at great risk of a disastrous implementation. In those situations, the acceptance testing essentially comes when the system is put in place in production. It’s much harder to fix bugs and keep users happy then.
Based on this reading, I agree that one of the important aspects of implementation is user acceptance testing since it’s the users who will be using the systems. UAT is a process of verifying that a solution works for the user. The goal of UAT is to assess if the system can support day to day business and ensure the system is sufficient for business usage. Acceptance refers to the fact that users typically sign off on the system and accept it once they are satisfied with it. A complete acceptance testing will include alpha and beta testing. Alpha testing is where simulated data is used for system testing. Whereas, Beta testing is where live data is used in the users real working environment.
I also agree that UAT is on the most important aspects of implementation. The UAT should not be completed by the developers as this will skew the objectivity. The UAT user should make sure that they are following the guidelines created to help ensure that the system is designed and functioning the way that the guidelines describe. If the procedures are not tested, then when the production system is live it may cause confusion and not work as intended.
The other issue with developers doing the UAT is that they already know how the system should work. You probably want someone who is mostly unfamiliar with how the system works and what exactly everything is supposed to do.
I also agree that it’s not just system functionality being tested. The documentation and training all need to be tested as well. Defined procedures are useless if they include the wrong directions.
Testing is an important port of UAT as it helps in validating if all the business requirement are met before releasing the software. The cost of fixing the defects after release is comparatively high than fixing it before the release. Developers are technical people who validate the software against the functional specifications. Only the users can know if there are some missing business requirements and processes.
The implementation phase of the systems development life cycle (SDLC) is the most expensive and time-consuming phase of the entire life cycle. The implementation comes from the output of the design specifications. The chapter talks about the six major activities of the implementation phase which are coding, testing, installation, documentation, training, and support. The purpose of these steps is to convert the physical system specifications into working and reliable software and hardware, document the work that has been done, and provide help for current and future users and caretakers of the system. At the end of the implementation phase, the result is evaluated according to the list of requirements that was created in the definition phase. It is also evaluated according to the designs. In the coding, testing and installation processes, the output are code, program documentation, test scenarios (test plan) and test data, results of program and system testing, user guides, user training plan, installation and conversion plan, software and hardware installation schedule, data conversion plan, and site and facility remodeling plan. The deliverables for documenting the system, training, and supporting users are system documentation, user documentation, user training plan, actual training of uses in the form of classes, tutorials on how to use the system, user training modules, training materials, computer-based training aids, user support plan, help desk, online help, bulletin boards, and other support mechanisms.
In unit 12 an important takeaway that I thought was important to discuss was that there are 6 major activities of system implementation. The six major activities according to the chapter are coding, testing, installation, documentation, training, and support. The main reason for these 6 steps is to convert the physical system specifications into working and reliable software. The coding and testing phase may have already been completed by this point if agile methodologies have been followed. Using a plan-driven methodology such as coding and testing are often done by other project team members besides analysts, although analysts may do some programming. For example in my organization, analysts are responsible for ensuring that all of these phases and activities are correctly planned and executed during system implementation.
As articulated above UAT is absolutely critical in releasing systems into production. However, I would like to highlight 2 other areas of testing that can be overlooked – scale/performance testing and audit/control validation. It can happen in the frenzy to launch a system and meet a deployment date that there is almost too much focus on UAT (to the detriment of the 2 areas I mentioned above). In this scenario I have seen systems go live that did all the functions the end users wanted (i.e. it passed UAT), but it was not validated to operate at large scale or with many many users. As a result when the system was heavily loaded (or used) – it crashed! Similarly I saw a system get put into production and begin being used that did not have adequate auditability and the team was forced to retrofit many controls into a system that was in production and being used heavily. Both of these scenarios came from being overly focused on UAT and not maintaining a balanced view across all the individual facets identified for testing.
Hi Jonathan, I completely agree with the statement that user acceptance testing is one of the most important steps of implementation. Specifically, I think the components of alpha testing, such as recovery, security, stress, and performance testing, are essential. These forms of testing are key to ensure that the eventual installation, whether that be direct, parallel, or phased, goes as smoothly and efficiently as possible. From a systems development perspective, ensuring that a system is tested as thoroughly as possible before any type of implementation can reduce the risk of the system completely failing. This, in turn, could be extremely costly for the implementers, and may even result in the development process needed to revert back several steps. Therefore, it is in the developers best interest to emphasize user acceptance testing.
The one of key points in Chapter 13 that I am interested in the procedures of implementation. Organizations need experts to complete technical processes, including coding, testing, and installation, when they develop from planning to implementing a new system. The programing team uses some codes to test the system’s capability. After the new system passes the testing, the team will convert the exited data into the new one. While they are replacing the old system with the new system in progress, they should record any issues if they find any. Although the programming team works on most of the implementation of the new system, the administration departments should cooperate with the process of the implementation. They need to develop a training program to teach the users and ensure that they can run the new system without any major issues. The organization also needs to have a support team to help them solve any problem meanwhile the new system is operating. Thus, the implementation of the new system does not rely on only one side, but the internals should be cooperative complete and mitigate the process of implementation.