PHP.EE FOORUM   
Nimi:   Pass:   Mäleta mind! 
   Teemad | php.ee esilehele | registreeri | Märgi kõik teemad loetuks | #php.ee Skype vestlus | RSS
UUS TEEMA  OTSI  Lehekülgi: 1
valideerimine
Postitaja: valideerija 2017-05-27 22:48:34
tere, kas keegi oskab selgitada või viidet anda, mis on "tarkvara valideerimine", tarkvara all mõtlen ma konkreetsemalt veebipõhist infosüsteemi

olgu lihtsaks näiteks arve, arvel on read, milles on kogus, hind ja käibemaks
arve summa on sum(kogus x hind + käibemaks)

selline on ka tarkvara algoritm ja tulemused on ootuspärased, st. ridade maksumuste summa võrdub arve summaga

---

kui nüüd audiitor küsib, kas tarkvara on valideeritud, mida peaks talle esitama tõendamaks, et tarvara on valideeritud?


tänud ette!
RE: valideerimine
Postitaja: blaa 2017-05-28 00:06:29
Aga sa küsi audiitorilt, mis asi see valideerimine on. Võibolla ta ei tea ise ka täpselt, kuid lihtsalt on kuulnud sellist sõna. Sama hästi võib ta ju ka küsida, kas tarkvara vastab standarditele.
RE: valideerimine
Postitaja: valideerija 2017-05-28 00:32:55
leidsin midagi sellist googledades, tundub, et peab projekti tegema, spcid juurde jms :-/

Software validation con rms that certain speci cations coincide with user needs, the software is meeting intended use, and requires objective evidence that the requirements can be consistently ful lled. This is required for any company covered by the Food, Drug and Cosmetic Act and 21 CFR Parts 210 and 211. Also,
if a company is keeping current Good Manufacturing Practice (cGMP) data electronically and relying on that information to make cGMP decisions, they are required to perform software validation. Manufacturers who continue to see increased enforcement of these regulations include pharmaceutical, nutritional supplement, and cosmetic companies.
For small to mid-sized manufacturing companies, software validation can seem like an overwhelming task. However, the bene ts of validating prove to be well worth the cost. Some of the reasons for software validation include:
Saving money by discovering weaknesses or aws in processes prior to production.
Providing management with a clear understanding of risks so that appropriate decisions can be made Increasing the likelihood projects will be completed on time and within budget
Increasing product and system quality
Meeting regulatory compliance
Creating a software validation plan before commencement will save you time and money and make the undertaking manageable. It’s important to nd a validation team that has the time and decision making authority to follow through each phase.

1. User Requirements Document
Create a user requirements document that contains a quick list of one or two-line sentences identifying the functionality that is required for your business. This is not to be confused with a Request for Proposal (RFP). Typically, RFP documents are all inclusive and geared toward larger companies. Gather your validation team together and brainstorm what functionality you require. Examples of user requirements include: “System must be able to track lot numbers for raw materials and manufactured product” or “An item needs to be able to be tracked with different quality control status.” Preparing the user requirements document prior to your software selection process will help to ensure that you select a product that will best t your needs.

2. Project Plan
In creation of the project plan you will identify who, what, where, and when the validation will occur. A validation team will oversee the entire process, and typically includes the project manager, technical lead, quality assurance lead, validation lead, and a support lead. Responsibilities of each team position should be explained in the project plan. The project plan should also include a system description, purpose, environment speci cations, assumptions, exclusions, limitations, testing, and acceptance criteria, error resolution and system documentation. There are various websites with samples and templates available to get you started.


3. Functional Speci cations Document
Create a functional speci cations document that is an extension of the user requirements, but contains slightly more information. Each requirement now expands to three or four sentences. Let’s refer to the user requirements example of “System must be able to track lot numbers for raw materials and manufactured product.” The system will assign the internal lot number automatically upon receipt of a raw material. Manufactured item lot numbers will be assigned automatically based on the batch ticket number. A link is desired between the user and functional requirements as it will certify the testing prerequisites. The end result is an accountability matrix that will allow you to trace your tests back to the requirements.

4. Gap Analysis
A review of the functional speci cations occurs and a gap analysis is created. The gap analysis is used to determine risk, or the difference between the desired performance and the existing performance. These risks should be documented and prioritized. If a gap is identi ed as a high risk, it becomes important to ensure that your procedures or software will mitigate the risk.

5. Installation Protocol
The installation protocol document outlines how the software should be installed. This would customarily be provided by your vendor. The document may also include hardware speci cations and installation instructions. Typically, it will include areas to document veri cation of speci cations for the hardware and software.

6. Installation Report
This document serves as evidence that the software was installed correctly according to the vendor recommendations and design. If your vendor performed the installation, they will provide you with this information.

7. Testing Protocol
The testing protocol document outlines the speci c objectives, procedures, data sets, test scenarios, expected results, and acceptance criteria for the system testing process. These protocols should test the software components your company will utilize. It is not necessary to test every setting available. The software vendor should have already tested the various setting combinations. The testing protocol should simply include evidence that a test was performed. Evidence might include screen shots and report print outs documenting the projected result. This information will be used to generate the testing report.

8. Testing Report
The testing report is an outline of the testing that has occurred. Typically, it will include an executive summary of the test execution that addresses adherence to test procedures, acceptability of results, as well as any unexpected results.

9. System Release/Go-Live
The system release allows the software to be used in production. By this time, the users have been trained, data has been entered, and business scenarios have been completed. The users can now begin using
the software.

10. Validation Complete
Once the validation is complete, the system must be maintained in a validated state. Maintaining this state requires that standard operating procedures are in place for addressing problematic concerns and resolution, change control, record retirement, etc. If changes are required within the system, the changes should be reviewed and assessed for risk. Necessary changes should be authorized, documented, tested, and approved before implementation occurs.


Conclusion
A key component in a validated system is documented evidence that the validation plan has been accomplished. When approached in an organized manner, software validation does not have to be an overwhelming task. By preparing a plan and following through its steps from beginning to end, software validation is manageable. For more information about creating a software validation plan, please contact ProcessPro at info@processproerp.com.
RE: valideerimine
Postitaja: putukas_seinal 2017-05-28 02:49:23

Verifitseerimine:
kontrollimine, kas tehtu vastab spetsifikatsioonile.

Valideerimine:
kontrollimine, kas spetsifikatsioon vastab tegelikele vajadustele.


Võib juhtuda, et spetsifikatsioonile mitte-vastav asi
vastab praktilistele vajadustele ja seega verifikatsioon põrub,
aga valideerimine läbitakse edukalt. Võib juhtuda ka nii,
et tehtu vastab perfektselt spetsifikatsioonile, aga see,
mis tehtud sai, on inimeste reaalsete vajaduste seisukohalt
vaadates totaalne lollus, sest spetsifikatsiooni sai lollusi kirjutatud.
Sellisel juhul läbitakse verifikatsioon edukalt aga valideerimine põrub.

Teemaga seondub ka testimine ja formaalsete meetoditega vigade otsimine.
Seal on lugu nii, et formaalsete meetoditega ehk matemaatiliste vahenditega
otsitakse konkreetset tüüpi vigu ja saab öelda, et
MATEMAATILISELT ON GARANTEERITUD, ET OTSITAVAT TÜÜPI VIGA süsteemis ei leidu.

Testimise eelis formaalsete meetoditega uurimise ees seisneb selles,
et kuigi testide läbimise korral ei saa kindlalt öelda, et
vead puuduvad, saab testide käigus mõnikord avastada veatüüpe,
mida EI TAIBANUD ÜLDSE ISE OTSIDA. Formaalsete meetodite korral
tuleb ju süsteemile ette öelda, et mis tüüpi viga otsitakse ja
kui inimene ei tea, et mingi veatüüp üldse eksisteerib, siis...

Kui teemast natukene veel kaugemale triivida, siis saab
viidata ka sellisele ajaveebipostitusele:

"The Future of Security Audits, Episode 0"
https://martin.softf1.com/g/yellow_soap_opera_blog/the-future-of-security-audits-episode-0


Leheküljed: 1

©2002-2013 Martin Rebane & PHP.ee kaasautorid
  0.403536081314