Release Notes

By Mark Gunn

The relationship between the Development team and the Quality Assurance team is extremely important to the development project. Having a good working relationship between these two groups can make the difference between the success or failure of a project meeting its’ deadlines. One of the most important channels of communications for these two groups is the Release Notes process.

Release notes identify the module information or the functionality of what will be contained in the application version being released to the QA group for testing. Although the overall release or build has been outlined in the project plan so that QA can develop their test cases and prepare for testing ahead of time, the release notes confirm that in fact the module and planned functionality is actually being released. Many things can cause a delay in the release of a module but for the most part QA has a good idea of what major functions/modules will be released. What the release notes confirm is to what extent the modules have been developed for the release. Release notes conversely also identify what functionality was left out and why it was not delivered.

The release notes also identify the defects corrected and released in this build. This is a major part of the work flow that surrounds the defect tracking system. The release notes detail which defects have been corrected and can be tested to ensure that they have been corrected. The QA manager will assign the corrected defects to QA Analysts for retesting. The defects will then be closed or sent back to development for further corrective action.

Without good release notes the QA team has no idea what to test in each build and it is a waste of time and resources to test modules that have not changed. Proper release notes allows QA to focus their attention on areas of the application that have changed and defects that have been corrected.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

FDA Watch . . . FDA 483 Warning Letters

By Mark Gunn
MGD Services

The FDA has performed a site inspection and they have issued your company a FDA 483 letter. Knowing how to deal with these legal documents (and these are legal documents) can mean the difference between eliminating potential problems or dealing with the agency in a seemingly unending stream of documentation and problems.

The response to a FDA 483 letter is your chance to tell your side of the story to possibly the only compassionate listener before Washington becomes involved. You must make certain the appropriate response will help your case and not hurt it!

The FDA investigator performing the site inspection and considering issuing a FDA 483 will attempt to verbally elicit your response to each concern, one by one. In cases where your responses can be made with certainty, you should make them. But if you are not sure, it would be better to explain to the investigator that you will supply a written response to the FDA-483 sent directly to the FDA office.

A Warning Letter differs from a 483 in several important respects. A 483 represents the observations of the inspection team (or lone investigator, if such is the case). A Warning Letter indicates that higher level FDA officials have reviewed the inspection findings and have concluded that the findings warrant further formal notification to the inspected company that FDA believes serious violations may exist.

Even if you respond verbally to the investigator on each concern, it is crucial for you to send in a written response immediately. This assures that your response is accurately provided to all interested parties, including the investigator’s supervisor and the compliance director - all of whom have a role in the decision process.

You should be aware that a Warning Letter is a FDA regulatory action. The FDA is now setting up a case against your company to take additional legal actions if the promised and proper corrective actions are not taken in an appropriate period of time.

Once the FDA 483 is issued, the only people to read it before additional legal actions against the company are recommended are the investigator's supervisor, the director of investigations and the compliance officer. If you and the investigator have a dispute during the inspection you cannot rely on the investigator to relay your position for you. It is your responsibility to state your position, and you must make the most of this opportunity in a rapid manner.

Your main objective, once you are issued a FDA 483 Letter, is to limit the financial and legal damage to the company and to get into compliance as soon as possible. If you show continued contempt for the agency and its policies, chances are you will be forced into compliance through further legal procedures, which will bring on increased expenses, the possible loss of business and harsh adverse publicity. Instead, if you show the FDA you are complying with the agency's policies without the need for further legal action; the chances are that the agency will continue to work with you to achieve compliance. Getting to this point can be attained by knowing your rights, operations, products and when to concede. The FDA's first indication that you know how to work with the agency is in your response to the FDA 483 letter.

Remember the FDA is looking to work with you to achieve compliance; you have to use this chance to let the FDA guide you and avoid additional problems.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

In the News . . . FDA Changes it’s Mind

Associated Press
09:33 AM Jul. 11, 2005 PT

WASHINGTON -- As the Food and Drug Administration considers whether to lift a voluntary ban on selling food from cloned animals, the agency is getting some resistance from an unusual source: the dairy industry.

Trade groups for farmers and companies that use dairy products are not enthusiastic about introducing milk from cloned cows into the marketplace, fearing consumers would be leery about the products.

"There's a strong general feeling among our members that consumers are not receptive to milk from cloned cows,'' said Susan Ruland, a spokeswoman for the International Dairy Foods Association, which represents food manufacturers that use dairy products.

"This seems to be one of the things where technology seems to drop something in the lap of the food companies,'' Ruland said in a recent interview. "It's not driven by the market or any benefit to the consumer.''

A 2002 Gallup poll found that 66 percent of American consumers said that cloning animals was "morally wrong.'' A March survey by the International Food Information Council, an industry trade group, reported that 63 percent of consumers would likely not buy food from cloned animals, even if the FDA determined the products were safe.

Last month, the National Milk Producers Federation, representing dairy farmers, approved a position statement that it "does not at this time support milk from cloned cows entering the marketplace until FDA determines that milk from cloned cows is the same as milk from conventionally bred animals.''

Because cloning a cow is expensive, about $20,000, selling meat from a clone wouldn't be financially viable. The main commercial benefit would be to sell milk from the clone of a prized cow, or for breeding purposes.

The dairy groups' position is at odds with the biotechnology industry and the small number of farmers who have invested in cloning cows.

Barb Glenn, director of animal biotechnology at the Biotechnology Industry Organization, predicted that cloning will benefit both consumers and producers. "With any new technology, you'll have groups concerned about it,'' she said.

Bob Schauf, a dairy farmer from Barron, Wisconsin, about 90 miles east of Minneapolis, cloned his prize-winning Holstein about four years ago, making four copies -- one of which died because of complications while calving earlier this year.

Schauf called the ban "ridiculous. It's a phobia more than anything scientific. We need to get FDA to come along and say it's fine. They're as normal as any other animal. Common sense has to take over soon.''

Because the FDA has asked farmers not to sell products from cloned animals, Schauf feeds the milk to his family and employees. He said he has other elite cows that he'd like to clone but has held off because of the government action.
In 2003, the FDA issued a summary of its draft risk assessment, which found that food from cloned animals was probably as safe as that from non-cloned animals. But it asked farmers to refrain from selling products from cloned animals until a final determination is made.

Earlier this year, a study by the Center for Regenerative Biology at the University of Connecticut found that meat and milk from cloned animals is essentially identical to that of non-cloned animals.

Aside from the health issues are questions about animal welfare, because cloned animals die in higher numbers during pregnancy and right after birth. A National Academy of Sciences panel looking at cloning raised the issue in a 2002 report.
The Humane Society of the United States urged the FDA to keep the ban in place. In a letter June 28, Wayne Pacelle, the Humane Society's president, wrote that cloning "carries too high a cost with regard to animal suffering, yet offers little benefit to humans and animals alike.''

Greg Wiles, a dairy farmer in Hagerstown, Maryland, has made two clones from a prolific Holstein. One is healthy, but the other suffers from health problems that Wiles declined to specify.

"I have said the FDA is more than welcome to get any blood or tissue samples,'' Wiles said. "I think it needs to be looked into.''

Wiles said he often thinks about disregarding the ban and selling the milk, which he now pours down the drain. "I think the FDA has taken too long to determine if it's safe or not."

The FDA declined an interview request for this story, saying in a statement that it would be "premature to discuss our findings or to make any final determinations due to the complexity of the issue.'' It added that the agency does not have a time frame for a final decision.

One of the cutting-edge animal cloning companies, Infigen of DeForest, ceased operations last year while waiting for the FDA to issue such a decision.

At the time, Infigen blamed delays in federal grants and funding cutbacks by a partner. But the company's co-founder and president, Michael Bishop, said the FDA delay was a fatal blow.
"It's hard to find people who want to do business with you when a government agency could possibly regulate against the food products entering the food chain,'' Bishop said. He predicted that cloning will never become viable for commercial livestock.

Developing Test Cases

By Mark Gunn

The test cases are written by the quality assurance analyst in exacting detail from the business requirements documents, functional specifications, design documents, and technical specification documents. They are organized based on the use cases. The test cases will ensure that each of the use case conditions is met by the system. These detailed test cases are written in a standardized way to ensure the tester can execute the test and know the expected results to validate whether the test passes or fails.

Each test case will have the following information:

1. A unique number and a description of the test case
   
2. The requirement, use case and module being tested
   
3. Any data preparation required to run the test case
   
4. Any test cases run prior to running the test case
   
5. The name of the person running the test case and date run
   
6. Each step contains the action/procedure being taken, expected results, and pass/fail
   

Different test cases will be written and used for unit, function, and system integration testing. The systems integration test cases can be used for User Acceptance Testing.

The users can use the use cases and test cases along with real data to test the system to make sure that system meets all of the agreed upon requirements and business needs. The test cases can be used later in the process as a springboard for developing a User’s Guide, training documents, and for future system enhancements.

Test cases should never be too long or too short. What we mean by that is, an individual test case should not test across modules or cover multiple parts of the system. If test cases are written in this manor then one change to any one part of the system could mean rewriting many, many test cases. With some system integration test cases, this must happen but should be limited. If your test cases are ‘modularized” then if a change is made to one part of the system then only the cases that cover that part of the application need to be rewritten. This holds true for manual test cases as well as automated test scripts.

The test plan will cover how the test cases will be developed and how they will be organized. Thought must be given prior to writing the test case so that they are usable by all those testing the application. Having similar test cases written by several QA Analyst is a waste of time and is not the best way to ensure complete system testing coverage.

You have written your test cases and you are now ready for the development team to release the first build. What might help with this are release notes. More on this next time.

-----------------------------------------------

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

FDA Watch . . .Does 21 CFR Part 11 still apply?

By Mark Gunn
MGD Services

We have had clients inform us that many on their staff believe that 21 CFR Part 11 is no longer in force. 21 CFR is still in force and in all likelihood will be for some time. Some of the confusion arose out of the adoption of the 21st Century cGMPs for the Pharmaceutical industry. This initiative allows the pharmaceutical industry to be smart about compliance while putting the burden of proof on the industry itself. It requires documentation of risk analysis (Risk Based Approach) and the impact on patient health, product quality and data integrity. While this does narrow the interpretation and scope of Part 11 it does not eliminate it.

The current interpretation of the Part 11 rule focuses on only those records required by predicate rules (GLPs, GMPs and GCPs) that are in electronic format. This means that fewer records are covered and that predicate rule requirements are still enforced. The FDA still expects systems to be validated based on the predicate rules. You should consider the impact on accuracy, reliability, integrity, availability, and authenticity of any documentation that has been identified based on the risk based approach. You should base the approach on a justified and documented risk assessment that evaluates the effect on product quality and safety and record integrity.

What is still being enforced for Part 11 compliance is comprised of the following areas:

• Security


• Accountability for e-signatures


• Electronic signatures


• Operational, device, and authority checks


• Record protection


• Training and experience


• Open systems

At a minimum the Validation Plan and Report, Requirements, System Acceptance Test, IQ/OQ/PQ, and Maintenance Procedures are required to be validated. But with only these minimum requirements there are liable to be gaps in compliance if the required documents are not comprehensive and issued in a timely manor. The risk based approach must not be looked at as a way around the regulations but as a more structured and fairer approach to 21 CFR Part 11 compliance.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

In the News . . .Band of Babes Finishes Revlon Run/Walk for Women

On April 30th, 2005 a determined and damp group known as the Band of Babes gathered with thousands of other fund raisers to walk or run in support of finding a cure for woman’s cancers. Our words of inspiration sounding similar to those imbedded in the stone of NYC’s General Post Office:

“Neither snow nor rain nor heat nor gloom of night stays these couriers from the swift completion of their appointed rounds.”
In the case of the Band of Babes, our mantra was:

“Neither rain nor wind nor water soaked sneakers stays these supporters from their trek from Times Square through Central Park in their search for a cure!”
As we waited for the race to begin, we listened as guest speakers, Julianna Moore and Mariska Hargitay exalted our fund raising efforts. The flashing neon of Times Square gave plenty for us to wonder over as well. Some huddled together for warmth, while others, no names mentioned (MARK) shook their water laden umbrellas over the shuddering masses, adding to their soggy plight. After a thirty minute stutter-step to the start line, we were on our way. Rain was still falling but we were moving and warming up. Our original plan was for some of the gang to act as ground crew and hold our luggage, and take action shots as we passed by. However, the weather being a deterrent, our sideline supporters opted to join the walk. Away we went, weaving our way through the throngs of people to the finish line where we gobbled potatoes chips washed down with Smart Water.

Our youngest member, nine year old Makenzie got a three mile piggy back ride from her very resilient mother, Bilynda. The Band of Babes raised $1,250.00 which will go to continued research for cures for woman’s cancers. Better weather has already been requested for next year’s event and we hope to see more new faces when we line up in Time’s Square next year!

For more information about race results or to make a contribution until
June 1, please visit: Revlon Run/Walk>Revlon Run/Walk

Use Cases

By Mark Gunn

In previous issues we have discussed solid business requirements, a master test plan, and a defect tracking system. The next step in the process, and one which is often overlooked, is to create use cases or test conditions.

Before you can begin to write test cases, you will need to understand how the system is going to be used. The system design documents will reflect how the system will be accessed and how data can be entered. This will be evident in the design or layout of the application. The application users will be able to explain how they intend to use the application. Of course, that has all been worked out and documented by the Business Analyst when the new SOP’s were written that reflect how the new application will impact the work flow. To best reflect how the work flow will affect the application, use cases should be written.

The use case should be a straight forward step by step process for how the users of the application will enter and use information. In its simplest form, they will cover how to Add, Change, and Delete information. Based on the type of application, this will require more detail but these are the basic constructs for a use case.

Without use cases, the test cases may be testing work flows that will never happen or more importantly, overlooking work flows that will happen.

For example; if you didn’t know that an end user will not have all of the information for an application module the first time they begin a new record, then you might construct a test case that was testing a first time completed module. Since a first time completed module initially can not happen, you may overlook in your testing that the system does not allow the user to save a partial record. The use case will cover this scenario and your test cases will accurately reflect these test conditions.

When you have completed your use cases, test cases can now be written so that they will completely test all of the applications requirements, designs and work flows.

Next time….writing good test cases!

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

FDA Watch: Thinking like the FDA

By Mark Gunn
MGD Services

Those of us in an FDA regulated industry sometimes get caught up in all of the regulations and documentation and forget why the FDA is requiring us to create what seems like never ending documentation. At its core, the FDA has a very simple job, to assure quality.

The FDA is charged with assuring the quality of the products of the pharmaceutical industry. This can be manufacturing (GMP), laboratory (GLP), clinical trials (GCP), medical devices, etc. The FDA requires you to prove you have a quality process in place. They need to know the public can be assured that the products produced are safe and do what they were intended to do. The only way the FDA can be assured that quality is being met, is to demand that we prove it. And if you think about it, the FDA should not really be located in Washington DC. They should be located in Missouri, the “Show Me” state.

Thinking like an FDA auditor, no matter how scary that thought might be to you, is really very basic. They are much like a very inquisitive 5 year old. I don’t mean this to be demeaning any way. If you have ever explained a very complicated process to a 5 year old you know what I mean. After every statement you make the child follows it with “but why?” You then have to back your last statement up with another explanation. The FDA works much the same way. They really don’t have any choice.

For example:

FDA auditor: How do you know the data I am looking at is accurate and correct?

Client: We know who entered the data and we know that they are qualified to enter it.

FDA auditor: How do you know that they are qualified?

Client: We have their latest CV on file and it shows the training they have taken.

FDA auditor: How do you know they attended the training?

Client: We have a signed record of the class attendance.

FDA auditor: So you know that the person who entered the data is qualified to enter it. How do I know they are the ones that entered the data?

Client: We have done our Risk Assessment for 21CFR Part11 and we know we have to be compliant and we are…

And so the line of questioning will continue. But you get the idea.

If you think along these lines, you should be able to embrace what the FDA requires rather than avoiding it. Ask yourself these types of questions for any risk assessed task and you will understand why the FDA has the regulations and guidelines that they do.

The next time you have to make a change to a regulated process you have to be able to back up that change with all of the documentation necessary to prove what affect it will or will not have on your current validated process. For an auditor to assure quality, they must be able to prove that what they are observing is accurate. That is why the regulations and guidelines are in place, so that you can show them that you have a quality process.

And the Validation Library is the place where the FDA auditor starts to look. More on that next time…

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

In the News: Revlon Run/Walk for Women

by Gretchen Gunn

Created in 1993 through the committed and collective efforts of the Entertainment Industry Foundation, Lilly Tartikoff, Ronald O. Perelman, and The Davis Group, the Revlon Run/Walk For Women has grown to become one of the nation's largest 5K fundraising events. To date, the Run/Walks (NY/LA) have raised over 30 million dollars for cancer research, counseling, and outreach programs. Thanks in part to these funds, new treatments are being developed and lives are being saved.

Some of MGD Services, Inc. employees and friends are participating in this worthy cause. Team captain, Gretchen Gunn shares some of her thoughts on the event and why she is participating. We welcome anyone interested in joining us! Click here to join the team.

Running has been my way to maintain both a healthy body and soul. And now it is a vehicle that will allow me to support others. On April 30, 2005, I will be participating in the Revlon Run/Walk for Women. I have also convinced a group of my friends to join me. Our team is called the Band of Babes. What started as a way to do something I enjoy and help others, has moved me in ways I did not expect. I have learned that many of my friends have either felt the sorrow of losing someone to cancer or they have lived the terror of having cancer themselves. Please donate and help support research to find a cure for women's cancers. A donation from you would be gratefully appreciated. Thank you for joining the Band of Babe's efforts to find a cure!

Save a Life, Make a Pledge

It is estimated that one in eight American women will develop breast cancer at some point in her life. In 2004, 272,000 women will have died from cancer. Behind this staggering statistic is the face of a woman who needs your help - a mother, a wife, a sister, a friend. The need is great and that is why I would like to ask for your help.

Click here to make a pledge.

Master Test Plans

By Mark Gunn

Prior to writing test cases for your project testing, you must create a master test plan that encompasses the complete range of testing tasks to be accomplished. To continue the construction analogy from my previous article (I just finished building a game room in our basement so forgive me) you can’t construct a building without a blue print and the same applies for testing a system.

The Master Test Plan is the blue print for how you will conduct your testing for the entire project life cycle. This is the vehicle that will communicate the testing scope and strategy to the rest of the project team. Development, project management, the test team and the user community will review the plan to ensure that all aspects of the application are being properly quality assured.

The information that encompasses the Master Test Plan must be detailed and well thought out. Putting together the plan requires many hours of reviewing the system design documents, project scope, business requirements, and the release schedule from development. Part of developing the test plan will be ascertaining the proper staffing needs for the testing the application, how those resources will be utilized and when.

The following are the major areas that all Master Test Plans must cover:

1. System Overview – a description of what the application is intended accomplish.


2. Purpose and Scope – the purpose for what QA will accomplish and the scope of the effort the QA team will be making.


3. Assumptions and Risk Assessment – what are the assumptions QA will be making on the nature of the project and what risks QA will be taking.


4. The Strategy – the overall approach QA will use for the testing. An explanation of testing methods to be used.


5. Data Preparation – what type of preparation will be required to prepare data for testing. This could require database refresh or data refresh scripts to be written.


6. The Build Matrix – each phase of the testing Unit, Functional, System Integration, Volume and Stress, Data Conversion (if necessary) and UAT will be outlined as to what will be tested in each phase and each build within each phase.


7. Work Plan – the Work Breakdown Structure (WBS) for what resources will be used and how they will be applied to each phase of the project. Also included will be milestone and target dates and any environmental requirements (PC’s, Networking, software, etc.) the team will have.


8. Testing Procedures – consists of version control, change control, and defect tracking procedures that will be used for all project participants.


9. Sample Forms – this will include a sample test case, sample defect tracking document and any other relative documents QA will be using for the project.

Once your test plan is approved, NOW you can start to write test cases. It is still not time to start testing yet, more on this in the next issue.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at mark@mgdservices.com

FDA Watch: Documented Training in a Qualified Network Environment

By Eric M. Stroud
GMPNetworks / Syvax Inc.

In order to complete the validation process for networks that require FDA Validation, one must provide evidence that training on network-related SOPs was conducted. A record of the training that was given for the network must be produced. This training record may be electronic or hardcopy.

Electronic training records are usually implemented at companies with a strong CBT program (computer-based training). After reading and possibly taking a short quiz, the electronic training record captures the name, date, topic, procedure #, score, employee ID #, and so on, as evidence of compliance.

More commonly, a training record is a simple form, which records the procedure title, trainer’s name, date, duration, and attendees.
Hint: Distribute the attendance list at the end of the training session!
The hardcopy training records must be maintained in a documentation repository.

If your company has a history of noncompliance with procedures (people not following SOPs consistently), taking attendance is not enough. It is good practice to implement a competency test following the training. This is typically a short quiz, not lasting more than 30 minutes. A threshold score is set, and all of the attendees meeting or exceeding the threshold score are allowed to perform a certain function. Those who fail the competency test must take the training again, and this highlights those colleagues that may need shadowing and observation.

In closing, “informal” training is not enough! Accurately record your training sessions, even if it is just one person in attendance. The creation of the training record is one of the key ingredients to show compliance with your own procedures.

Eric is an FDA Validation expert for GMPNetworks/Syvax Inc. Eric has over ten years experience with FDA validation for the pharmaceutical industry and has been specializing in validating IT data networks.
http://www.gmpnetworks.com

In the News: Firefox Web Browser

KEY BISCAYNE, Fla. Jan 24, 2005

By age 10, Blake Ross was designing Web pages on America Online. By 14, after mastering complex programming languages such as C++, he was fixing bugs in Netscape's Web browser from home, a hobby that landed him a job offer. "What, at the local store or something?" David Ross remembered thinking when his son told him. No, at Netscape Communications Corp.

Ross, now 19, a sophomore computer science major at Stanford University, has an even more impressive resume than most of his peers. Before graduating high school, he helped develop Firefox.

Colleagues who worked with Ross only online were surprised when they met him to find "a scrawny 15-year-old kid," recalled Chris Hofmann, engineering director at the Mozilla Foundation.

To take an internship at Netscape during the summer of 2001, Ross moved with his mother to a rented apartment near Netscape's offices in Mountain View, Calif. She drove him to work each morning.

He continued working on the browser on contract after returning to Florida to attend Gulliver Preparatory School. He breezed through computer classes, finishing projects in a day that took others two weeks, said Dean Morell, a former teacher and chairman of the school's computer science department.
Ross soon took on a much more demanding project.

America Online Inc., which bought Netscape in 1999, was trying to resurrect the once-mighty Netscape browser. AOL added features, but they bogged down the software and reduced performance, Ross said in recent interviews by e-mail and at his parents' condo in Key Biscayne, a Miami suburb.

At 17, Ross and another Netscape programmer, David Hyatt, started a side project that became Firefox. They wanted to strip down Netscape and the Mozilla suite on which it is based. By reducing the software to its browsing basics, they figured it would run more efficiently.

Ross and Hyatt created an early version of the browser. Because the project was open source, thousands of volunteers could examine the programming code and suggest ways to improve performance and fix bugs.

"I have fond memories of long nights spent at Netscape just poring over all the feedback people submitted about our programs," Ross said.

Hofmann, the Mozilla engineering director, said Ross dealt with the pressures of Silicon Valley quite well for his age.

"I don't think that he was intimidated or awe-struck at all," he said. "With open-source projects you rise to a level based on your skills. It is really a meritocracy. Anyone who has the skills rises quickly and Blake had all those skills."

AOL ultimately spun off the project and created the not-for-profit Mozilla Foundation to develop Firefox and related software.

Hyatt left to design Apple Computer Inc.'s Safari Web browser, but Ross stayed and helped fix Firefox bugs from college.

Firefox was officially released Nov. 9. It was used by 4.6 percent of Web surfers in early January, and that number could reach 10 percent by mid-2005, according to WebSideStory, which tracks browser use. Microsoft's Internet Explorer has dropped to 90.6 percent this month from 95.5 percent in June.
Security experts like Firefox, saying it isn't as vulnerable as Internet Explorer to viruses, spyware and other malicious programs.

Business Requirements – The Foundation

By Mark Gunn

Thorough, accurate, and well written business requirements are the foundation for software development projects. Many of those in the software development business would agree with this statement and would also agree they don’t follow it. Sometimes there is project pressure to “start coding now”. As if, that would get the project to market quicker. I have never quite understood this concept. Without a solid foundation on which to build your project, as with building a house, sooner or later the project will crumble. The time taken to produce solid business requirements will save the project time and expense by reducing the time and cost of having to redo code that does not meet our users/clients business needs. Coding without having solid, detailed business requirements means the developers will, in all likelihood, have to spend time re-coding to fix missed requirements. The QA team will have to write new test cases, new builds will have to be released and more testing will take place. So you can pay me now (pay the business analyst) or pay me later (pay for additional time for the Developers, DBA, QA).

The task of producing thorough, accurate, and well written business requirements is the other aspect that is often under estimated. Having subject matter experts (SME) write business requirements is not the best approach. SME’s are not trained in writing business requirements. They know their business, but do not necessarily know how to write solid business requirements. For example, I had this exchange once while reviewing business requirement written by a SME:

Analyst: “In this requirement you state that you always do this task.”

SME: “That is correct.”

Analyst: “So there are no circumstances under which you don’t do this task.”

SME: “That is right…….well there is the rare exception that we don’t but it hardly ever happens……… “

If this requirement had been given, as it was written, to development and QA this is how it would have been coded and tested. During User Acceptance Testing (UAT), at the end of the project timeline, the users would have discovered this oversight (at least we hope they would) and the project would now be behind schedule and additional person-hours (see also cost over-runs) would ensue to correct the over-sight.

In the end, having solid business requirements is the foundation for building a quality product. A quality product requires all project participants, during all phases of the project, to adhere to the constructs of Total Quality.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

FDA Watch . . .FDA expectations for your IT Data Network

By Eric M. Stroud
GMPNetworks / Syvax Inc.

In most pharmaceutical companies, the Information Technology (IT) department often has a number of regulated customers: Manufacturing sites, laboratories, clinical operations, etc., each with its’ own section of predicate rules from the Food & Drug Administration (FDA) to follow, collectively called the “GXPs”, or “Good….Practices”. Manufacturing sites must be in compliance with the “GMPs” (21 CFR Parts 11, 210-211, 820 for medical devices); for laboratories, the “GLPs” (21 CFR Parts 11 and 58); and for Clinical Operations, the “GCPs” (21 CFR Parts 11, 50, 56, 312, 812).

While no predicate rule specifically spells out what the FDA expects for a data network, it is good practice to adopt the regulations from the GMPs, and apply them to the network. Think about who potentially would get audited the most in your organization: Manufacturing. A manufacturing division is a good example of an IT customer that would require documentation about the network, showing control, in order to show that its’ manufacturing sites, which use that network, are in compliance with the GMPs.

“The FDA ‘raised the bar’ on what they expected regarding control of data networks when it issued Pharmacia two warning letters…”
The data network used by the manufacturing, clinical, and laboratory operations must be qualified. Sounds extreme? Consider this: The FDA “raised the bar” on what they expected regarding control of data networks when it issued Pharmacia two warning letters during two inspections in 2000. Since then, larger pharmaceutical companies have implemented network quality programs, including Pfizer, Merck, and Schering-Plough.

The responsibility of a network quality program usually falls to the IT management or a quality role in the IT organization, and quality assurance. A complete network qualification package typically has the following components:

A policy on what will be controlled in the data network, specifying boundaries, responsibilities, and “core” procedures;
Standard Operating Procedures, particularly for those activities that are used to show compliance (change control, periodic review, monitoring, testing, training, document management, disaster recovery, etc.);
Documented Training on Standard Operating Procedures, which is checked in a periodic review;
A means of controlling documentation: A physical repository, an electronic document management system, or both, for maintaining diagrams, qualification documents, procedures, etc.
A methodology to specify, design, and test new devices or functionality; and,
An objective Quality Assurance role within the department, to manage the above items.

In Part 1 of this article, let’s discuss the use of the policy.

The policy document may originate from the IT organization. It’s most important purposes are to communicate the scope and responsibilities for maintaining control of the data network across the organization. The policy document is usually approved by a representative of each area of the IT organization, such as operations, architecture, deployment, and planning. The policy document should be implemented across the entire organization, and elaborates on the following.

What equipment will be under change control and qualification, such as layer-2 devices, wireless devices, MVX, video, etc.;
Where sites and regional/corporate groups divide their responsibility, such as at an “edge” layer-3 switch;
If there are documents which are shared by multiple sites, who will maintain those documents;
How will network documentation be approved and maintained; and,
The qualification approach for equipment.

Usually, the most difficult part about preparing an organization-wide policy is getting consensus. Many people maintain a data network, and often, the network may spread across the globe. Well-coordinated meetings with agendas, support from upper management, and a project team to ensure that the policy becomes practice are the essentials for success.

Getting a network control policy in place is often the hardest part of getting a new network quality program off the ground. Don’t despair! You have a lot of support and help out there! (hint!)

Eric is an FDA Validation expert for GMPNetworks/Syvax Inc. Eric has over ten years experience with FDA validation for the pharmaceutical industry and has been specializing in validating IT data networks.
www.gmpnetworks.com

In the News . . .TV star helps launch new website opposed to exporting jobs

Site features exclusive short film

Washington DC--TV star Jason Alexander has joined the offshore outsourcing debate on the side of U.S. workers by helping launch a new website called Outsource Outrage. "The outsourcing of American manufacturing and technical jobs has become ‘business as usual’ over the past few years. In my own industry, we must constantly fight the trend of taking American film work out of the United States. ... Men and women that I have known for over 20 years, craftspeople and technicians, camera operators and production managers, have all seen their livelihoods disappear due to this devastating trend," said Alexander.

The star teamed up with the Communications Workers of America, WashTech's parent union, in launching the site. Alexander is best known for his role as George Costanza on the mega hit series Seinfeld.

The site features a short film where Alexander asks school children which countries they want to work in when they grow up. "Our film satire, while done for humor, accurately depicts the situation. To claim the creation of jobs while knowing full well those jobs have been created for American firms in foreign countries is a horrific lie. And unlike our film it’s not particularly funny."

Besides the film, the site features information and ways for individuals to take political action on the issue.

Microsoft Files Suits Against 'Bulletproof' Web Hosts

Sep 24, 2004

Microsoft filed nine lawsuits against individuals and companies alleged to be involved in the distribution of spam, the company said Wednesday.

The suits, all filed in the last month, include eight against individuals alleged to be behind spam campaigns that offered e-mail users a variety of products including generic online drugs, tee-shirts, software, pornography and dating services. The ninth lawsuit is against a Web hosting company that catered to the spammer community by claiming to be "bulletproof," or incapable of being shut down, Microsoft said in a statement.

The lawsuits are just the latest salvo in a legal war on spammers by Microsoft, as well as Internet service providers like America Online and EarthLink. In June, Microsoft filed eight lawsuits against alleged spammers who used accounts at the company's Hotmail e-mail service and compromised PCs running its Windows software to send spam.

In the latest suits, Microsoft has also extended its reach to companies that sell services to spammers, according to the statement.

Microsoft filed suit against Levon Gillespie, who is described as a principal of "bulletproof" Web hosting company cheapbphosting.com, as well as "various John Doe" defendants who use Gillespie's services, the company said.

According to text Microsoft said was taken from the cheapbphosting.com site, Gillespie "cater(s) for both established bulk email experts and companies that have not used bulk email before," using "China-based" servers "to ensure no problems arise from complaints generated by mail you send."

In its statement, Microsoft claimed that spam that originated on servers on the cheapbphosting.com was routed through compromised computers in Korea, Japan, Israel and the U.K., as well as Brazil, Germany, Switzerland, Canada and the U.S.

The e-mail messages contained forged or "spoofed" header information to make them look as if they came from Microsoft MSN and Hotmail accounts, the company said.
Microsoft said it has filed 70 lawsuits in the U.S., including the latest group, and is continuing to target spammers and those that support spamming.

In the News . . .Microsoft to Open Research Center in India

Dec 1, 2004

Microsoft Corp. is further expanding its presence in India with plans to open a research center in Bangalore.

The latest Microsoft Research campus will open in January 2005, the Redmond, Wash.-based software giant said Tuesday. The researchers in India will focus on ways to create, store and search information in multiple languages, as well as technology for use in emerging markets and other specialties.

Microsoft already operates research campuses in Beijing; Cambridge, England; Redmond; San Francisco and Silicon Valley.

The company decided to add an Indian campus to take advantage of promising computer science students coming out of universities there, said Rick Rashid, a vice president in charge of Microsoft Research. The company hopes to hire a couple dozen researchers over the next year, he said.

The Microsoft Research campuses, modeled after academic research facilities, do work that is relevant to Microsoft's product lineup, such as security or search technology. Products including the TabletPC have come out of the research arm.

But researchers also are encouraged to work on far-flung ideas that may never turn into profitable products, like tools for developing HIV vaccines.

The new center will be headed by P. Anandan, previously a senior researcher at Microsoft's Redmond campus. Anandan, a native of India, said in a statement that the country's many languages, plus the fact that most of its more than 1 billion residents have no Internet access, make it a good backdrop for researching some of computer science's most challenging problems.

The announcement comes just two weeks after Microsoft opened an office in Hyderabad, India, 340 miles north of Bangalore, and stepped up plans to hire more programmers in India. The new Hyderabad campus, its largest outside the United States, will eventually employ 3,000 programmers.

Microsoft already has offices in Bangalore for functions such as product support and sales, Rashid said.

Microsoft is one of dozens of American technology companies to set up facilities in India, taking advantage of its vast pool of skilled workers who can be hired for a fraction of the cost of those in the United States.

FDA Watch . . .Part 2: Network Standard Operating Procedures

By Eric M. Stroud
GMPNetworks, Syvax Inc.

In Part 1 of this article, we described the purpose of the Policy document and its role in setting network qualification into practice in an organization. But, the policy alone does not give complete evidence of control - Standard Operating Procedures (SOPs) are used as one way (a very good way!) to provide this evidence.

SOPs in the network realm can exist on two levels: The organization, and the devices.

Organization SOPs are often written for a regional center or a site, in order to align quality practices in that organization (consistency). These SOPs typically include:

Change Control - The process for managing changes to the network;
Monitoring - The workflow for monitoring network conditions and health, reporting metrics, and resolving problems;
Documentation - A workflow for new network documentation, edits, approvals, and how they are managed (electronically, hardcopy, or both);
Testing - The process of identifying, applying, and testing patches, upgrades, and hardware changes on a simulated network before deployment;
Periodic Review - The process of inspecting diagrams, documents, change controls, etc., over a period of time to ensure continued compliance; and,
Disaster Recovery - The activities to be followed during a disaster recovery exercise.

These SOPs should be prepared by the network organization. The approvals of these SOPs must have a quality assurance (QA) signatory, preferably, a QA role in the network organization. The training process on these SOPs (documenting, refreshers), would be the same as your other SOP processes. An admin or quality coordinator should be watching for new hires, and refresher training dates, new SOPs, and revisions to SOPs. Remember that last point - If you revise and re-issue the SOP, you need to retrain on it.

A common question is "why not just include the network in the scope of the site's regular change control". As long as there is a quality assurance role in the network's organization, it is a good practice for the network operations groups to maintain their own change control process. It is often streamlined, or may be an electronic tracking system, whereas a site's change control process may involve the use of review boards, or simply just more time for review. Network operations demand an efficient review and documentation process, sometimes, in the matter of hours, or during maintenance windows.

Data network devices warrant their own operational procedures once they are deployed. Device/Functional SOPs include: Startup/Shutdown - The specific process for the startup and shutdown of a network device Firmware Upgrades - Often model or series-specific, the process of applying and verifying an upgrade to a network device

The list of possibilities is endless here. You may wish to proceduralize the cascading of switches, 3rd party vendor management (fiber, long lines, etc.), and so on. The best practice in any SOP writing is to be concise and accurate. Always keep in mind the fast-paced nature of the business and the consequences of network outages and downtime, and the effects a procedure might have when resolving those problems.

Eric is an FDA Validation expert for GMPNetworks/Syvax Inc. Eric has over ten years experience with FDA validation for the pharmaceutical industry and has been specializing in validating IT data networks.
http://www.gmpnetworks.com

Defect Tracking – A must for IT Projects

By Mark Gunn

Ok, your IT project has a testing group and they have good solid requirements from which to work. That is a great start! When testing begins how are you going to communicate the problems (see also defects) to the system development team? Having a good defect tracking system for your IT projects is a must. Many good defect tracking applications are on the market today and most do the job needed. Ideally, a defect tracking system must have features which allow the ability to enter the following:

¨ a description of the defect
¨ the detailed steps by which the defect was created
¨ the application module(s) affected
¨ the build in which it was found
¨ a rating system for the defects and the severity of each defect
¨ a process by which to route the defect and track the defect status,
¨ and the ability to attach screen prints of the defect.

Your defect tracking system must have these capabilities and it should also have the capability to produce statistical results as well.

A defect is the vehicle which you are using to communicate found problems. A clear understanding of the defect is important for the developer for resolution and the QA team for retesting a corrected problem. The QA manager should review all defects for repeatability and to avoid duplication before routing them to the Development manager.

The Development manager, in turn, should review all defects, have a good understanding of the problem by communicating with the QA manager, and route the defect to the developers for resolution. The defect tracking application is an invaluable project tool, not only for QA and Development, but for the Project manager as well.
Defect tracking is a way to communicate to project management how the project is doing. The Project manager uses the statistical results, with defined measurements, from the defect tracking system to determine the status of the project. From a good defect tracking system, the Project manager can determine if the project is on schedule, if more resources are needed to meet the scheduled deadline, and how well development and QA are doing their jobs. By viewing the defects on a daily/weekly basis, the Project manager can determine where most defects are being found, how many are being entered, and the degree of difficulty or severity for these defects. The Project manager can then manage the project accordingly and the resources associated to the project.

Finally, the results associated with the defects can demonstrate what QA’s worth is to the project and to the organization. Many times the value that QA brings to the IT project is overlooked. Having a defect tracking system that has a reporting capability that shows a defined measurement of the testing status demonstrates the value of QA to the project.

You have solid business requirements and now you have selected a good defect tracking application. You are on your way to start testing…………well not just yet. More on this in the next article.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

MGDServices website has a New Look

MGDServices has an updated look and feel on the website. “The look of the website better reflects our technical position in the marketplace” said Donna Herman, of MGD Services.

Please visit www.mgdservices.com for more information.

In this Issue:

Defect Tracking - A must for all IT Projects
by Mark Gunn

FDA Watch - Part 2: Network Standard Operating Procedures
by Eric M. Stroud; GMPNetworks / Syvax Inc.

In the News -
Microsoft to Open Research Center in India

In the News: J.P. Morgan Cancels IBM Outsourcing Deal

Wed Sep 15, 2004 09:25 AM ET

WASHINGTON (Reuters) - J.P. Morgan Chase & Co. (JPM.N: Quote, Profile, Research) said on Wednesday it was canceling a $5 billion outsourcing deal with IBM Corp., (IBM.N: Quote, Profile, Research) and planned to rehire about 4,000 workers who had been transferred to IBM under the pact.

IBM said in a U.S. Securities and Exchange Commission filing that the cancellation of its biggest financial services outsourcing deal would help its 2005 earnings per share, and would have no impact on its full-year model.

J.P. Morgan, the No. 2 U.S. bank, said following its recent merger with Bank One, it could better manage its own technology and infrastructure. It also said there will be no material impact from the cancellation.

IBM said the cancellation would improve earnings because it was still in the early stages of deployment on the contract. It also said its backlog of services will be revised when it announces its third-quarter earnings. IBM estimated a $118 billion services backlog at the end of the second quarter.

Under the seven-year deal announced in December 2002, IBM was to take over the global computing operations for J.P Morgan in a wide range of areas including retail banking, trading and securities processing, offering the bank an opportunity to cut its own spending on technology.

The 4,000 workers transferred to IBM from J.P. Morgan in early 2003.

J.P. Morgan said IBM would remain one of the largest technology partners for J.P Morgan, but the companies did not elaborate on their relationship going forward. (With additional reporting by Chris Sanders)
© Reuters 2004. All Rights Reserved.

FDA Watch : Commissioning - A Risk-based Approach

An excerpt from Institute of Validation Technology.

The Institute of Validation Technology indicates that the Commissioning of systems and equipment within the pharmaceutical industry is quickly becoming a stable endeavor. While the intent of the practice was to cut the cost associated with validation, it has quickly become entangled in the web of Risk Assessment and Management.

Every system and piece of equipment utilized in the pharmaceutical and medical device industries is subject to a commissioning exercise. Commissioning using a risk assessment approach is best applied to new equipment and system installations.

Commissioning is now being viewed as an active part of the qualification process. It is imperative that it be performed in a structured, analytical and compliant way. Current FDA regulations do not mandate that commissioning or risk assessments be performed, but it is the trend and the latter may be the justification for the prior.

Many questions arise when one considers the application of risk assessment when conducting Commissioning. Among these are:

• When do we apply risk assessment?
• What thinking and planning are involved?
• What tools might be available to conduct this activity?
• Will the FDA care?
• What does it do for me or my project?
• How are risk assessment and commissioning related?
• What is the current thinking of the FDA regarding Commissioning and Risk Assessment?
• Where do we start with risk assessment?
• How do these concepts affect the final outcome of qualification and validation?

Let’s Begin with the Basics . . .

By Mark Gunn

The inherent philosophy of Quality Assurance for software systems development projects is to ensure that the system meets or exceeds the agreed upon requirements of the end-users; thus creating a high-quality, fully functional and user-friendly application. This philosophy applies to all system development projects and includes mainframe, client server, and web based applications.

“Quality Assurance is more than just testing”
Quality Assurance is more than just testing. Quality Assurance is involved throughout a project’s lifecycle.

• The Quality Assurance effort begins with the analysis phase of the project, continues through the design and execution phases and proceeds until the application is in production and beyond.

• Introducing solid quality assurance concepts and methods into the system development life cycle early on and maintaining them throughout the Software Development Life cycle (SDLC) is the key to the overall success and total quality of the project.

Quality Assurance is a commitment to the Total Quality of the Project

• This commitment to the philosophy of Total Quality requires all team members to adhere to the guidelines and methods that will ensure the excellence of the system being developed.

This philosophy is the backbone for the Software Development Life cycle. As our IT industry matures we find that having sound development and quality assurance methodologies ensures that applications or application enhancements are delivered to our customers on time and with no production problems. When this process breaks down, and this can be for many, many reasons, we find that the product we deliver can be less than what was agreed upon.


Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

Welcome to the MGDServices Quality Assurance Newsletter

Welcome to the first issue of the MGDServices Quality Assurance Methods and Practices Newsletter. Periodically we will be providing you with industry trends, developments and news that affect Quality Assurance, FDA Validation, and our IT family of professionals.

We are confident you will find this information a valuable resource for your day to day activities.

MGDServices Has a New LocationMGDServices has relocated to a new location in Hunterdon County, NJ. Gretchen Gunn states “Our new location keeps us close to our clients while adding the additional office space needed for our staff.” The new address and phone numbers are:

143 Rosemont-Ringoes Road
Stockton, NJ 08859
877-MGD-TEST
Fax 609-397-3967

About MGD Services

Product / Service Information

MGD Services, Inc. is a woman owned business that supplies consulting professionals to corporate IS departments in support of computer systems development projects. We supply well-trained, seasoned personnel to perform all tasks involved in the entire project life cycle for computer systems development.

MGD Services provides our clients with candidates that have been carefully screened, interviewed, references checked, and matched to our clients needs for their projects. MGD has many years of experience in IT systems development and we know how to separate the good candidates from the poor candidates.

We at MGD Services pride ourselves on the consistent quality of the candidates we present to our clients. We provide qualified candidates that do not waste our client’s time on unwarranted interviews. When we send a candidate to a client, they can be confident that the candidate meets or exceeds their project needs.

We supply our clients with candidates for all phases of the project life cycle development process.

Our personnel include:

§ Project Managers § Application Developers
§ FDA CSV Auditors § Testers
§ Business Analysts § Database Architects
§ QA Managers § Automation Test Specialists
§ System Designers § FDA Validation Analysts
§ QA Analysts § DBA’s
§ Network Specialists § Technical Writers

These personnel are involved in computer systems development projects from inception through the project lifecycle into production and on into system maintenance and enhancements. They work closely with both the system development staff and the end user community to provide a system that meets the client needs and the project requirements.
MGD Services understands the benefit of having the best in testing technology for today's enterprise needs. MGD Services partners with Mercury Interactive and Compuware. MGD Services has both Mercury and Compuware Certified QA analysts and test specialists who can provide quality assurance automated testing expertise for our client’s software development projects. We can support our clients in reviewing and understanding all automated testing products.