Lesson 1: System Implementation Phase Overview

Lesson Objectives:

After reading this lesson, you should be able to: As with the other phases of the system development life cycle, the system implementation phase has multiple components or sub-phases. Up to now in the life cycle, the system has been planned, it has been analyzed, and the system has been designed. Now, the system needs to be developed, which is known as coding and is the first sub-phase. The second sub-phase is to test the newly coded system on multiple levels. The third-phase is the planning and implementation of the new system. Finally, post-implementation is the final sub-phase of system implementation.

Once the system has been coded, the system goes through different degrees of testing. It is important to make sure the system works and performs the duties the system was intended to perform. The rest of this section deals with the quality assurance process. Based upon Kendal and Kendal, quality should be tested on internal and external factors (2005). The internal factors deals with the duties the systems should perform. The external factors are the perceptions of the customers or other external parties such as suppliers.

Having a quality product will either make or break a company. For example, if someone asked a mechanic what brand of tools they use, the mechanic might reply that they use either Snap-On or Craftsman. These two tool manufactures created a name and reputation for themselves on producing tools that people know and trust.

Overall, the main goal of the quality assurance process is to detect any problems or errors as early as possible in the implementation process. For example, the quality assurance process can detect inaccurate requirements. If a customer wants a microwave oven built and a toaster oven is mistakenly built, this inaccuracy could have been avoided. One way of avoiding an issue like this is to perform documentation reviews. In the microwave versus toaster oven issue, reviewing the system design specification would have been a good starting area for researching the issue.

After the documentation review has been completed, other quality assurance duties can be completed to detect/prevent any other issues. One duty is to review the coding process. Some software companies might want their programmers to code a certain way. For example:

  1. Take the design and break the design to different components
  2. Start on a component 1 and complete that component
  3. Test component 1
  4. Start component 2
  5. Test component 2
  6. Test any interaction between component 1 and component 2
  7. Repeat process as needed
These steps need to be reviewed before the start of a new program to see if there are any additions or subtractions from the steps.

Reviewing the testing checklist is another important quality assurance task. A testing checklist is a list of tests the newly developed system will go through before the planning and implementation processes start. For example, a tester would want to test to see if there is Internet access at a workstation before testing an application that requires Internet access. Testing the test procedures is always a good idea to make sure every component is being checked.

Throughout the system implementation phase, documentation is very important. In a later lesson, the importance of documentation will be covered. Stated above, reviewing documentation was discussed as a way of assuring the quality of developing the system. Reviewing documentation can be a very time consuming process. Reviewing data flow diagrams, which was covered in a previous topic, may involve the individual or individuals that performed that analysis if an issue arises. If the documentation is not reviewed and an issue arises in the development of the system, the amount of time might be ten times greater to recover from that issue.

After testing and receiving the "green light" from the testers, installation of the newly developed system can commence.