Who is Bill Gaw?
And why should we
listen to him?


Lean Enterprise Articles
 

Your 3-Step, World Class, Lean Manufacturing Training Program
WCM Lean Manufacturing

 Increase the effectiveness of your
Lean Manufacturing Initiative

Manufacturing Simulation Game 

Pharmaceutical Manufacturing
Part 3 of 6


privacy policy

Contact Us

 To review our training 
 packages, click on 
  the links below: 

e-Training Packages:

Lean Manufacturing
Solutions

Balanced Scorecard
Training

ISO 9000:2000
Training

Supply Chain
Management
Training

Operations
Management
Training

Strategic Planning
Training

     Other Options:   

Lean Leadership

Thinking Outside 
the Box Principles 

Lean Enterprise Training

Performance
Management Training

Lean Kaizen Event

Lean Manufacturing Implementation

Lean Six Sigma
Basics

Supply Chain
Management
Solutions

Strategic Planning
Model

Total Quality
Management
Training

Lean Manufacturing Coach and Certification

Production Planning and Control
Solutions

Manufacturing Planning and
Control

Role of Independent and Qualified Reviewers

For the validation to be effective it must be reviewed by an independent and qualified third party, someone who is neither a developer nor a user of the system. This third-party review is analogous to the role of a QA department or that of a certified public accountant. Although the devel­opers and users of the system may do most of the actual validation work, a qualified third party should review the validation records and give objective assurance to manage­ment that the validation was carried out properly. This function can be performed by someone outside the company or it can be performed by someone within the company who has sufficient objectivity as well as sufficient expertise in system testing and validation methods.

Elements of a Successful Validation

Use of a Formal SDLC The most important question that can be asked during a system validation is, "Was a formal SDLC employed in the implementation of this system?" If the evidence indicates that a formal SDLC approach was not used, there is high probability that the system under study will have signifi­cant problems with its quality and reliability.
Figure 1 illustrates typical SDLC phases for development of custom software. Although MIS professionals may use different terms for each phase, the concepts are the same First, the users of the system formally define their require­ments (Requirements Definition). The system developers then prepare a functional or external description of the proposed system to meet those requirements (Functional Design). Based on this functional design, the system developers then prepare an internal or technical descrip­tion (Internal Design). The system is then actually built through the Program Code and Test phase. An Integrated System Test is then performed to ensure that all the pieces of the system work together and that the system meets its design and performance specifications. As the software is being developed, the various user documentation is writ­ten, including standard operating policies and procedures (SOPs), as well as various user guides and training mate­rials. These, along with the new system, are used to conduct a comprehensive Acceptance Test, according to a predefined test plan. The Acceptance Test is sometimes called a Validation Test because it tests the final system against the requirements definition. When the Acceptance Test is complete, the system can be cut over into live production. From this point, the system enters the Opera­tion and Maintenance phase.

Figure 2 illustrates the SDLC phases for implementation of a vendor-supplied software package. It is essentially the same as the SDLC for custom software at the front end and the back end. A requirements definition must still be performed. Based on the request for proposal (RFP) coming out of Requirements Definition, a software package will be selected. At this point, since the functional design of the package is already defined, what is needed is not a func­tional design but a phase that we call Software Prototyping. Here the software package is set up in a prototype mode, using company specific data, to determine in detail how the package will be used. Which business functions will be performed by the system and which will be performed manually? Which system features will be used and how will they be set up? How must company procedures be changed to work in the context of the new software? The output from this phase is a documented road map or description of how the software package will be used in the context of specific business scenarios.

Frequently the prototyping phase reveals that package modification is required. If so, internal design, program coding and testing, and an integrated system test, must be performed, just as if custom software were being devel­oped. In addition, an acceptance test is required, just as it is for custom software. It is important to note that for software packages, the entire package must be tested, not just the parts that were modified.

To Be Continued


STAY CONNECTED

To stay current on manufacturing competitive knowledge, please subscribe to our weekly bulletin, "Manufacturing. Basics and Best Practices (MBBP)."  Simply fill in the below form and click on the " subscribe button." 

We'll also send you our Special Report, "8-Basics of Kaizen Based Lean Manufacturing."  

All at no cost of course. 

First Name:
Your E-Mail:

 Your personal information will never 
be disclosed to any third party.

privacy policy

Here's what one of our subscribers said about the MBBP Bulletin:

"Great articles. Thanks for the insights. I often share portions of your articles with my staff and they too enjoy them and fine aspects where they can integrate points into their individual areas of responsibilities. Thanks again."

               Kerry B. Stephenson. President. KALCO Lighting, LLC


"Back to Basics" Training for anyone ... anywhere ... anytime

Business Basics, LLC
6003 Dassia Way, Oceanside, CA 92056
West Coast: 760-945-5596
 

© 2001-2007 Business Basics, LLC