Credentialing System Implementation Essay

The previous two parts of this three-part assignment, the systems analysis and application architecture and process design aspect of the credentialing software project at TPI Health Systems (TPI) was explored. This last paper will explore the implementation stage of the systems development life cycle (SDLC) as it related to the credentialing project at TPI. There are six major steps to the implementation phase of the SDLC: (1) coding, (2) testing, (3) installation, (4) documentation, (5) training and (6) support. The text actually details five steps and breaks-out the last step, support, into its own phase (Satzinger, Jackson, & Burd, 2004, p. 626). The first phase, coding, is done in any of three development styles: (1) input, process, output, (2) top-down, (3) bottom up. The input, process, output (IPO) method is defined by first doing the activities that require external input followed by elements that process the input and concluded by programs that produce output (Zachman, 1987, p. 279). The IPO is effective in developing user interface first and simplifies testing. It does have a disadvantage of late output modules (Satzinger et al. p. 629). The top-down and bottom up methods produce the needed top or bottom modules, respectively. Top-down coding has the advantage of having a working version of the program. Poor utilization of programming personnel in the beginning of the project is disadvantage of the top-down development method. The bottom-up method puts programming personnel to work immediate, utilizing resources effectively. Unfortunately, this method also requires additional programming to test the modules, as well as an overall delay of testing by waiting for the top modules to be developed. The credentialing project at TPI used a weak IPO method of coding. The major attention was placed on converting the data in the existing Visual Fox format to Microsoft SQL 2000 compatible data. The company, SyMed, made no provision for any user interface changes. The process of how a credentialing application flowed through the TPI credentialing process was observed in the analysis phase of the project and the project team had wanted some user interface changes to accommodate TPI processes. These changes did not fit into the SyMed project plan, so the TPI process was changed to accommodate the pre-written user interface of the SyMed system. Testing is the next phase of the implementation phase. A comprehensive testing program includes a stepwise process starting with unit testing, followed by testing of group components called integration testing and concluded with entire systems test (Satzinger et al. , 2004, p. 640). Individual units or modules are tested prior to integration with more advanced modules, using driver modules. Once a set of modules are put together, integration testing can take place. These test include checking for interface compatibility, run-time exceptions, parameter values and unexpected state interactions (Satzinger et al. , p. 644-645). Jeff Theobald suggests that an effort should be made to concentrate not on just errors in a single application or module, but also the system as a whole and between systems (Theobald, 2007). After these tests are completed, the project goes on to system testing. System testing often involves daily â€Å"build and smoke† tests, where the system is set to run and is observed for â€Å"smoke† or errors (McConnell, 1996). The TPI credentialing system was tested in this manner. The project made it through the first two testing phases (unit and integration), but never made it out of systems testing. It â€Å"smoked† and never stopped due to a basic inability of the data store to handle the TPI method of placing multiple doctors in multiple entities. The SyMed development team called in the architect of the system and a step back to the analysis phase was made. Their entire development team, along with the architect, made a trip from Nashville to Louisville to redo the initial analysis. The team went back to Nashville with the new data and called back to say they could not do the project. The end of the project consumed uncounted person-hours, 7 months on the calendar and about $25,000 dollars. The next part of the implementation phase is installation. This phase is accomplished by several methods. The first is direct installation. This is where the new system is installed and implemented and the old system is â€Å"turned off. † This is a simple but risky way for a new system to be deployed. The next possible method of installation is parallel. This method is demonstrated by keeping both systems going for an extended amount of time. This is a low risk but high cost implementation scenario. Phased installation is the last method and is characterized by multiple possible pathways to final installation. Phased installation is also low risk, but can become quite complex due to the multiple pathways (Satzinger et al. , 2004). The TPI credentialing system, had it made it to this phase, was to be a parallel installation. Documentation is the next phase of implementation and usually consists of user documentation and systems documentation. User documentation is descriptions to users on how to work together with the system. It is typically how to startup and shutdown the system, the keystrokes necessary to do specific tasks, functions necessary to perform a specific procedure and troubleshooting tips (Satzinger et al. , 2004). System documentation usually consists of information necessary to maintain and re-implement the system in the event of a disaster. System documentation includes maintenance and upgrade procedures, analysis methods and in some cases, the source code and testing data (Satzinger et al. ). The TPI credentialing program had available pre-printed manuals of SyMed’s existing user interface and command sequences. The SyMed systems documentation was never provided. The next phase of implementation is training. Training can consist of formalized classes or presentations; self paced learning or group training. This training should be hands-on and emphasize actual applications that the system was created to perform. Timing of training is important. Training can be performed too early in the implementation progress, leading to unnecessary training that may need to be un-learned. Training is often seen as a luxury by some companies and is sometime omitted. This can be a costly mistake (Satzinger et al. , 2004). The TPI credentialing system was scheduled to have two days of formalized onsite training. The final phase of the implementation phase is support. As mention earlier, this phase s sometimes broken-out as its own stage. It is also often rolled into the training phase. Support is usually considered some form of help desk for most software development, though some companies offer only online documentation and troubleshooting. For this premise to work, the documentation needs to be robust and thorough. The TPI credentialing system never got to this phases and was unable to utilize either system. The failure of the TPI credentialing system software project had many contributors. Poor analysis and implementation of the SDLC was paramount, as well as budgetary issues. To sum it up, the failure was mostly due to TPI not knowing exactly what they wanted and needing more abilities than they had resources for, coupled with SyMed’s inability to recognize their limitations. The failure outlined above could have been mitigated by the knowledge and utilization of the capability maturity module (CMM). The CMM is a matrix that defines an organizations maturity of software processes Anderson, 2001). CMM is a process identification whose goal is to use defined and repeatable processes in software development. TPI would have scored a one and SyMed may have scored a two. Figure 1 illustrates the five modules of the CMM. Figure 1. Capability maturity module. This tool can be utilized by both software clients and vendors to identify potential success in a given software project. Additionally, IBM has developed the Rational Unified Process (RUP) for the object-oriented approach of software development. RUP is designed to make designed and repeatable processes easier. There are individuals who disagree with contention of repeatability for both CMM and RUP, claiming that like movies, software development success is not always repeatable.