8+-+Implementation


 * System Implementation**

__**Def**.__-The activities associated with ensuring that the new system is fully functional and operational, as well as the activities associated with turning control over to end users.

Two Views of Implementation:


 * End User**: believes implementation is the day the system is activated and put into use.


 * Analyst**: implementation is all of the activities that lead to the activation of the system and for the end users to be able to use it.

Implementation Processes:

1.) Coding 2.) Testing 3.) Installation
 * Coding
 * Documenting
 * Make sure code is error free
 * Conversion
 * Training and support



Documentation

User Documentation: System Documentation:
 * Supposed to provide end users with detailed and organized descriptionof how to interact with the system.
 * Supposed to provide support to maintenance personnel

As-built vs. Modeled

Software Testing
 * Applications must be checked for errors in the system. It is rare that 100% of the errors will be detected in this process. to minimize errors in the system there is a structured process to final testing.

Software Testing Process: White Box (Structural Tests)-testing done with knowledge of source code Black box (Functional Tests)-testing doen without knowledge of source code

Mosley's Classification of Software Tests:

-- **Manual Test Automated Test** -Desk Check--Integration Test -System Test Steps in his process: 1. Code Inspection In this step programmers and analysts scan the source code for errors in how the program was written. Typically each individual inspects roughly 70 to 120 lines of code an hour and there is usually a team of 5 to 7 members inspecting the code. Fagan estimated that a code inspection can detect roughly 50 to 70 percent of the errors in an application. 2. Structured Walk Through This is where the analysts check whether the application performs the way the designers intended. Analysts closely examine the logic embedded in the code. There is no actual changes made to the code, the code is only examined for erros, if erros are found then programmers must go in and fix the problem. After the problem has been fixed analysts must conduct another walk through test. 3. The Desk Check One or more programmers work through a hard copy of source code, stimulating the control flow. They execute each instruction and evaluate the accuracy of the results. This is no longer a common practice due to the increase of technology. 4. Module Testing This focuses on making sure the execution of each application module is successful before it is integrated with other testing modules.
 * Static**-InspectionSyntax Check
 * Dynamic**--Walk-through--Unit Test

Bottom-Up Method-tests lowest level module first, then works its way up, integrating each module into the next highest level. Top-Down Approach (Stub-Testing)-tests highest level module first, lower level modules are simulated by a program stub. Once the high level module is tested, the module below it is then tested. (For both of these tests a **Test Driver** simulates the control environment by sending input or recieving output from the modules.) 5. Integration Testing Focuses on testing an entire group of modules to find errors undetected at the unit level. Typical Types: User Interface Testing, Use Scenario Testing, Data Flow Testing, System-Interface Testing
 * Integration Strategy** is when integration is performed by using all at once(big bang), top-down, bottom-up, or critical piece first strategies.


 * System Testing**

The entire system is under scrutiny with the goal of having no errors. This testing is different from Integration testing in that the system tests goes after the bugs and problems that are properties of the entire system. Focuses on requirements testing, usability testing, security testing, performance testing, documentation testing.

Build-and-Smoke-Test

This test excercises the entire system and exposes any major problems. The test can reveal any code changes from the the integration that was effective by itself but causes problems when it is fully integrated at the system level.

Acceptance Testing

The process by which the end user verifies that the delivered and installed product is ready to use.

Types: -done by the client at the developer's site -really focuses on testing limits and ranges and expected errors -done in live environment -an audit of the test is usually conducted
 * Alpha/Verification (test data)
 * Beta/Validation (user data)
 * Audits

Script This is a fancy name for the acceptance test. A test has 3 possible results: 1. Pass 2. Reservation (the test is passed except for minor problems that do not affect functionality) 3. Fail


 * System Installation**

This is the final step of the process in which systems are turned to end users. This stage can be one of the most chaotic and mission-critical stages of the process. At this stage, we are involved with system conversion, final documentation, and end user training.

1. **System Conversion**

System conversion consists of activities associated with replacing the old system with the new system. End users have to give up the old system which they are familiar with, so it can be challenging and stressful for some of them. Four basic strategies exist for system conversion as follows.


 * **Direct Conversion** The old system is turned off, and the new system is turned on.
 * **Parallel Conversion** The old system and the new systems are turned on until end users are satisfied with the new one.
 * **Pilot Conversion** The new system is installed in multiple places and evaluated before it replaces the old system.
 * **Phased Conversion** The new system is gradually installed.
 * **Data Conversion** deals with transferring data from the old system to the new system.

2. **Final Documentation**

The final documentation is to provide the end users and the system administrators with the information needed to successfully implement the new system. Online documentation is now the standard that includes electronic user's manuals, hypertext-based help systems, electronic system models, and interactive knowledge bases. The documentation can be categorized into two types, user documentation and system documentation.


 * User Documentation** provides the users of the system with detailed and highly organized instructions of how to use the system in as many scenarios as possible. One of the most important feature about online documentation is the ability to use **context-sensitive help**. It provides the end users with topics related to activities being performed. Procedures offer instructions in sequence. General reference is used more like a dictionary where users can access for a quick reference. Tutorial guide users through a set of typical tasks.


 * System Documentation** details the design specifications, the internals of the system, the as-built program code and other important information related to maintaining the system.

3. **End User Training**


 * User Training Design and Content** Users need to be trained in how to interact with the system to perform their tasks,not what the system can do


 * User Training Method and Delivery** Which training method to use and what training schedule must be considered.
 * traditional classroom approach
 * one-on-one training
 * self-paced training
 * computer-based training

Postimplementation and maintenance cycle can be the most expensive and time consuming stage. This stage involves in activities to correct errors, provide changed for improvement, and adapt the system to the changes of in business environment.
 * Postimplementation Activities**


 * Change requests** are reviewed by a change control **steering committee**.


 * Categories of System Maintenance**
 * **Corrective maintenance** Fixing bugs or logic errors not detected during the implementation testing period.
 * **Adaptive maintenance** Evolve the software to meet chaning needs of business
 * **Perfective maintenance** Improve the quality and effectiveness of the system performance.
 * **Preventive** **maintenance** Ensure the continued operation of the system.


 * Cost Elimination of Downtime**


 * Productivity losses** are those that have negative impact on individuals or workgroup productivies.

= number of affected users * (Percentage effect on productivity/100) * average burdened salary per hour * hours of downtime


 * Business losses** affect transactions or result in customer losses.

= number of affected users * (Percentage effect on productivity/100) * average profit per employee hour * hours of downtime

or

= number of transactions per hour * (Percentage of affected transactions/100) * average profit per transaction * hours of downtime



Helpful & Interesting Websites:

http://www.personal.psu.edu/bxb11/CBTGuide/CBTGuide.htm

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

http://www.openpr.com/news/56184/Convergence-Training-Releases-Revolutionary-Platform-for-Computer-Based-Training-Distribution-and-Viewing.html

http://en.wikipedia.org/wiki/Top-down

http://www.buzzle.com/editorials/4-10-2005-68350.asp

http://csob.berry.edu/faculty/lleblanc/newpage9.htm

http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/13.25.SWEng4/html/text.html