ISO 9001 Twenty Quality Elements


Support translation:
ISO 9001 Twenty Quality Elements

A look will be taken at the requirements from the viewpoint of companies developing software. ISO 9001 standard was intended for the manufacturing industry. The requirements are interpreted for software development in accordance with ISO 9000-3 and TickIT.

There are 20 main elements. Each concept is well known in the quality management community.

1. Management Responsibility

1.1 Quality policy

The standard requires the supplier management to issue a quality policy, where it says the company shall produce quality products.

The quality policy shall:
– Define the management’s commitment to quality
– Define the company’s objectives regarding quality, that is, what management means by quality
– Be relevant to the customer’s needs
– Be understood in the organization
– Be implemented


– Statement too vague or policy is not understood by staff
– Quality policy is not implemented.

E.g. of Quality policy

“We achieve quality through motivated and skilled staff, defined work procedures, and intensive review and testing activities.”

1.2 Organization

The standard requires documentation of responsibility, authority and interrelation of all personnel affecting quality. This means that if a person has a responsibility, it shall be formally assigned by the appropriate manager. The person should have the authority to fulfil the responsibility.

According to ISO, responsibility means:

“a duty to act on one’s own accord when something has to be done without being told”.


– Existing of a responsibility that cannot be fulfilled.


– Project-line
– Project-customer
– Project-maintenance organisation
– Software development-hardware development
– Maintenance organisation-help desk
– Sales-development

Resources require that the supplier:
– Identify the requirements for resources
– Assign trained personnel.

Management representative requires appointment of manager representative with authority and responsibility to:
– Ensure that the company fulfils the requirements in ISO 9001
– Report the performance of the quality system to company management

1.3 Management Review

Quality manager should periodically present the results of
– Quality audits
– Statistics of quality complaints
– Records of corrective action

The results should be presented at a recorded management meeting with notes on who attended, what was presented and what decisions were taken and made.

2. Quality System

Quality system – “the organizational structure, responsibilities, procedures, processes and resources for implementing quality management.”

Procedures, rules, decisions shall be put into writing. If you have a rule or procedure that is not required by ISO 9001, the standard still requires that it is written.

A quality manual shall contain reference and documentation of the quality system.


– An audit is a sample, therefore if in a sample, there are minor non-conformances, and they are fixed, it can still be a non-conformance because the auditor can suspect that there are many more minor non-conformances.
– Existing written procedures are not adhered to.

3. Contract Review

The supplier checks before signing contract that the organisation be able to perform what is required by the contract.

Questions that should be asked include:
– Are the requirements documented and understood?
– Are acceptance criteria included?
– Have requirements differing from the tender been resolved?
– Can the supplier muster enough resources for the contract?
– Can the supplier muster the competence needed for the contract?
– Can the task be completed in time?

The standard requires that a documented procedure with reviews be included. The supplier should identify how contract amendments and handling of requirements specification between customer and supplier be defined.

4. Design Control

4.1. General
ISO requires that you plan before doing and specify before designing.

4.2. Design and Development Planning

Design plan should contain:
– Definition of methodology to be used in development of product
– Time schedules, responsibilities, work assignments and progress control
– Phases project will be divided. This includes input, output and verification of output.
– Description of methods and tools to be used

Quality plan should contain:
– Quality targets
– Criteria for acceptability
– Identification of planning, validation and verification.
– Responsibilities for quality activities.

If a company wants to gain ISO qualification the plans must be held in all projects, since ISO certification is for the whole company and not for specific projects.

4.3 Organizational and Technical Interfaces

If there is group-work, the interfaces between them should be identified, documented and transmitted to those needing the information. The documentation shall be reviewed regularly.

4.4 Design Input

Requirements specifications contain the design input in software development. This may be done by the purchaser or prepared by the supplier using laws and regulations. Another design input includes design coding which is used as input to coding.

The standard wants to ensure that the work product of each step meets the requirements.

In software development, requirement changes are common so a procedure for handling new and changed requirements from the purchaser be created.

4.5 Design Output

Design Output: the design documentation and the source code. ISO requires that design documents and coding be reviewed before release.

A procedure for acceptance of the design output and criteria of acceptance should be created.

4.6 Design Review

Project functions like coding and testing shall be presented at the review. A common method for ensuring reviews are checklists.

4.7 Design Verification

This consists of reviews, module testing and integration testing.

4.8 Design Validation

Final system test, of the complete software product together with the reviewing of user documentation. There should be planned and documented validation. Beta testing is in conformance with ISO as long as the beta testing is covered by a clear agreement between supplier and beta-testing customer.

4.9 Design Changes

ISO 9001 requires that after release of design documentation or source, all changes shall go through a formal process where changes are documented, reviewed and approved before implementation.

Uncontrolled changes to complex technical documents or programs are extremely dangerous and as such the standard does not allow it.
5. Document and Data Control

Information that controls the development/maintenance of software. The standard requires that those who need some document/data shall have access to it. Changes to documents and data shall be controlled.

5.1 General

External documents and data shall be stored. It can be stored on any form (hard copy, electronic media).

5.2 Document and Data Approval and Issue

Before issue documents and data shall be reviewed and approved before each issue. A document list in which one shall find out the current version of a document. Invalid or obsolete documents should be removed or clearly marked.

5.3 Document and Data Changes

The person/s in charge of the review and approval process shall be specified.

6. Purchasing

In the case of subcontractor, you are still responsible. I.e. if you apply for a contract and subcontract the work, ISO standards is still under your responsibility and ISO requirements do not have to be imposed on the subcontractor.

6.1 General

If manpower is purchased, the standard requires you to follow a procedure that you get the right people. The people will be controlled by supplier and not subcontractor.
To ensure that purchased software conforms to requirements:
– Contract requirements on the subcontractors procedures
– Audit of the subcontractor quality system
– Check subcontractor past performance
– Survey the subcontractor during contract
– Witness review and testing
– Test and review product of subcontractor.

6.2 Evaluation of Subcontractors

Person with necessary authority and competence shall judge each subcontractor and decide whether to use. The decisions shall be documented.

The supplier shall decide what control over subcontractor it will have. The standard does not mention how much control you should have. It just mentions that a decision should be made by using facts.

A special case is when software is purchased through retail. In this case subcontractor is organization with which the purchase is conducted, not the original developer of the software.

If purchasing is done through retail ISO 9001 requires that you define to what extent you put requirements on the retailer to control its supplier.

6.3 Purchasing Data

Requirements on development process shall be documented in the contract along with supplier requirements to approve work results and procedures.

6.4 Verification of Purchased Product

Documentation of decisions about the verification of each purchased development tool or included product.

– No list of approved suppliers
– Inappropriate control of subcontractor
– No document verification of purchased items
– Inappropriate contract with subcontractor.

7 Control of Customer-supplied Product

The supplier shall have procedures for verification, storage and maintenance of customer supplied software. However, the quality is the responsibility of the software.

A non-conformance happens due to unclear responsibility of responsibility between customer and supplier.

8 Product Specification and Traceability

The software supplier should keep control on:
– On what preceding document and issue it is based
– On which specification it is based
– What corrections and amendments have been included in which source programs
– What happened to each problem report
– From what source was a specific module generated.

9 Process Control

Documented procedure for the replication process in the operation and procedure for handling of master PROM’s/libraries. To ensure that correct versioning is used.

– No documented procedure for replication
– Improper handling of master PROM’s or diskettes.

10 Inspection and Testing

Written procedures for the inspection and testing to be done in connection with replication.

– Function of automatically checking PROM’s has not been inspected
– No documented procedure for testing PROM’s.

11 Control of Inspection, Measuring and Test Equipment

The supplier should select the appropriate measuring equipment and follow a documented procedure for control of equipment. Each new software version should be tested for sufficiency.

12 Inspection and Test Status

Specifications and programs should verified through reviews and testing. The supplier shall have procedures that prohibit use of unverified specifications or programs.

13 Control of Non-conforming Product

Non-conforming products should not be used unintentionally. A procedure for handling quick modifications in case of critical errors should be created.

– Clear identification of controlled items that contain uncorrected errors
– Method to elicit customer acceptance upon delivery
– In case of quick modifications, it must be documented
– Reviewing so modified items will be elevated to same status as rest of software.

14 Corrective and Preventive Action

– Effective handling of reports that do not conform to requirements
– Effective handling of reports indicating short-comings in the development process
– Active collection and analysis of available information about product and process non-conformance and preventive actions.

Information about problems encountered should drive improvements of the development process.

– Customer complaint has not been properly handled
– Deficiency has been found but not corrected
– No procedure to ensure that problems are analyzed and acted upon
– No procedure for reporting difficulties with applying rules and procedures.

15 Handling, Storage, Packaging, Preservation and Delivery

Applies to software replicated on PROM, disk or other medium.
Media shall be labelled and packaged correctly. Data shall be backed up. There should also be the ability to provide protection from unintentional damage.

16 Control of Quality Records

Quality documents show which actions have been taken to ensure or check quality. The standard requires that there be a procedure for handling of quality records. The records should be stored in an appropriate manner so they are easily accessible.
– No rules for retention of quality records
– Review records are not kept
– Test records are not kept
– Period of keeping quality records is not defined

17 Internal Quality Audits

There should be an independent entity that regularly audits all operations that may affect product or service quality. These are conducted on behalf of company management. There should be an audit plan.

– No audit plan
– Audit plan not up to date

18 Training

Company should ensure that staff is trained for tasks required. A procedure to:
– Identify training needs for each staff position
– Provide such training
– Keep records of the training of all staff members.

Training should be documented and sufficient. By sufficient we mean that the person be capable of performing his/her work to a high enough standard.

– No procedures for planning or training
– No training records
– Not received proper training for his or her task.

19 Servicing

Supplier shall have documented procedures for servicing if this is mentioned in the contract. In software it is about error corrections and enhancements to delivered software.

Procedures for handling complaints and requests for modifications. The supplier is not obliged to provide maintenance if it is not mentioned in contract. Maintenance procedures for old software should be made.

– Maintenance work for a customer without a contract
– Specific methods for maintenance of old product is not documented
– No procedure for testing after maintenance.

20 Statistical Techniques

There should be collection and analysis of data about number of errors found in the different phases. Information about inability to meet deadlines and milestones should be analyzed.

“————————————————– ————————————————– ————————————————–

Appoġġ traduzzjoni:
————————————————– ————————————————– ————————————————–
ISO 9001 Għoxrin Kwalità Elementi

Ħarsa se jittieħdu fuq il-ħtiġiet minn perspettiva ta ‘kumpaniji li jiżviluppaw softwer. ISO 9001 istandard kien intiż għall-industrija tal-manifattura. Ir-rekwiżiti huma interpretati għall-iżvilupp tas-softwer skond ISO 9000-3 u TickIT.

Hemm 20-elementi ewlenin. Kull kunċett huwa magħruf sew fil-komunità ġestjoni tal-kwalità.

Responsabbiltà 1. Ġestjoni

1.1 Politika ta ‘kwalità

L-istandard jeħtieġ li l-ġestjoni fornitur biex joħroġ politika ta ‘kwalità, fejn jgħid il-kumpanija għandha tipproduċi prodotti ta’ kwalità.

Il-politika tal-kwalità għandu:
– Tiddefinixxi l managementâ € ™ s impenn għall-kwalità
– Tiddefinixxi l-companyâ € ™ s għanijiet dwar il-kwalità, jiġifieri, dak immaniġġjar mezzi skond il-kwalità
– Ikunu rilevanti għall-customerâ € ™ s bżonnijiet
– Ikun mifhum fl-organizzazzjoni
– Ikun implimentat


– Dikjarazzjoni vagi jew il-politika wisq mhix mifhuma mill-persunal
– Politika ta ‘kwalità mhix implimentata.

Eż tal-politika tal-Kwalità

â € œWe jinkisbu kwalità permezz tal-persunal motivati u mħarrġa, proċeduri tax-xogħol definiti, u reviżjoni intensiva u ttestjar activities.â €

1.2 Organizzazzjoni

L-istandard ma teħtiġx dokumentazzjoni ta ‘responsabbiltà, l-awtorità u l-interrelazzjoni tal-persunal kollu jaffettwaw il-kwalità. Dan ifisser li jekk persuna għandha responsabbiltà, din għandha tiġi assenjata b’mod formali mill-maniġer xierqa. Il-persuna għandu jkollha l-awtorità li tissodisfa r-responsabbiltà.

Skond l-ISO, ir-responsabbiltà tfisser:

dmir œa € jaġixxu fuq oneâ € ™ s qbil stess meta xi ħaġa trid issir mingħajr ma jkunu toldâ €.


– Eżistenti ta ‘responsabbiltà li ma jistgħux jiġu sodisfatti.


– Proġett linja
–Klijent Proġett
– Organizzazzjoni ta ‘manutenzjoni tal-Proġett
– Żvilupp ta ‘softwer iżvilupp hardware
– Manutenzjoni organizzazzjoni help desk
– Bejgħ-iżvilupp

Riżorsi jeħtieġu li l-fornitur:
– Identifika l-ħtiġijiet għar-riżorsi
– Jassenja persunal imħarreġ.

rappreżentant ġestjoni tirrikjedi ħatra tar-rappreżentant maniġer bl-awtorità u r-responsabbiltà li:
– Tiżgura li l-kumpanija tissodisfa r-rekwiżiti fl-ISO 9001
– Rapport tal-prestazzjoni tas-sistema ta ‘kwalità għall-ġestjoni kumpanija

1.3 Reviżjoni Ġestjoni

maniġer tal-kwalità għandha perjodikament jippreżentaw ir-riżultati ta ‘
– Verifiki Kwalità
– Statistika ta ‘l-ilmenti ta’ kwalità
– Rekords ta ‘azzjoni korrettiva

Ir-riżultati għandhom jiġu ppreżentati f’laqgħa ġestjoni irreġistrat man-noti dwar min attenda, dak li kien ippreżentat u dak deċiżjonijiet kienu ttieħdu u saru.

2. Sistema ta ‘Kwalità

Sistema ta ‘kwalità â € “”â € œthe istruttura organizzattiva, ir-responsabbiltajiet, il-proċeduri, il-proċessi u r-riżorsi għall-implimentazzjoni management.â € kwalità

Proċeduri, regoli, deċiżjonijiet għandhom jiddaħħlu fis-miktub. Jekk ikollok xi regola jew proċedura li mhix meħtieġa mill-ISO 9001, l-istandard għadu jeħtieġ li biha jkun inkiteb.

Manwal tal-kwalità għandu jkun fihom referenza u d-dokumentazzjoni tas-sistema ta ‘kwalità.


– Verifika huwa kampjun, għalhekk jekk f’kampjun, hemm minuri non-konformità, u huma ffissati, xorta tista ‘tkun mhux konformità minħabba li l-awditur jista jissuspettaw li hemm ħafna aktar minuri non-konformità.
– Il-proċeduri bil-miktub eżistenti ma jiġux rispettati.

Reviżjoni 3. Kuntratt

Il-kontrolli fornitur qabel kuntratt iffirmar li l-organizzazzjoni tkun tista ‘twettaq dak li hu mitlub mill-kuntratt.

Mistoqsijiet li għandhom jiġu mistoqsija jinkludu:
– Ir-rekwiżiti dokumentati u mifhuma?
– Il-kriterji ta ‘aċċettazzjoni inklużi?
– Ikollhom rekwiżiti differenti mill-offerta ġiet solvuta?
– Jista ‘l-fornitur ġemgħa biżżejjed riżorsi għall-kuntratt?
– Jista ‘l-fornitur ġemgħa il-kompetenza meħtieġa għall-kuntratt?
– Jista ‘l-kompitu titlesta fil-ħin?

L-istandard jeħtieġ li tiġi inkluża proċedura dokumentata ma ‘reviżjonijiet. Il-fornitur għandu jidentifika kif l-emendi tal-kuntratt u l-immaniġġjar tar-rekwiżiti l-ispeċifikazzjoni bejn klijent u l-fornitur għandhom jiġu definiti.

4. Disinn Kontroll

4.1. ġenerali
ISO teħtieġ li inti tippjana qabel ma tagħmel u jispeċifika qabel tfassil.

4.2. Disinn u l-Iżvilupp Ippjanar

pjan disinn għandu jkun fiha:
– Definizzjoni tal-metodoloġija li għandha tintuża fl-iżvilupp tal-prodott
– Skedi ta ‘żmien, ir-responsabbiltajiet, għotja ta’ xogħol u l-kontroll progress
– Fażijiet Proġett se jinqasam. Dan jinkludi input, l-output u l-verifika tal-produzzjoni.
– Deskrizzjoni tal-metodi u l-għodod li għandhom jintużaw

pjan għall-kwalità għandu jkun fiha:
– miri ta ‘kwalità
– Kriterji għall-aċċettabbilità
– L-identifikazzjoni ta ‘ppjanar, il-validazzjoni u l-verifika.
– Ir-responsabbiltajiet għall-attivitajiet ta ‘kwalità.

Jekk kumpanija trid biex jiksbu kwalifika ISO-pjanijiet għandu jiġi kkunsidrat fil-proġetti kollha, peress ċertifikazzjoni ISO hija l-kumpannija sħiħa u mhux għal proġetti speċifiċi.

4.3 Interfaces organizzattivi u tekniċi

Jekk ikun hemm grupp ta ‘xogħol, l-interfaces ta’ bejniethom għandhom jiġu identifikati, dokumentati u trażmessa lil dawk li għandhom bżonn l-informazzjoni. Id-dokumentazzjoni għandha tiġi riveduta regolarment.

4.4 Disinn Input

Speċifikazzjonijiet rekwiżiti jinkludu l-input tad-disinn fl-iżvilupp ta ‘softwer. Dan jista ‘jsir mix-xerrej jew imħejji mill-fornitur juża liġijiet u r-regolamenti. input ieħor disinn jinkludi kodifikazzjoni tad-disinn li hija użata bħala input għall-kodifikazzjoni.

L-istandard irid jiżgura li l-prodott xogħol ta ‘kull pass jissodisfa r-rekwiżiti.

Fl-iżvilupp tas-softwer, bidliet rekwiżit huma komuni tant proċedura għall-immaniġġjar rekwiżiti ġodda u mibdula mid-xerrej jiġu maħluqa.

4.5 Disinn Produzzjoni

Disinn Riżultat:-dokumentazzjoni tad-disinn u l-kodiċi tas-sors. ISO jirrikjedi li d-dokumenti tad-disinn u l-Kodifikar jiġu riveduti qabel ir-rilaxx.

għandhom jinħolqu Proċedura għall-aċċettazzjoni tal-produzzjoni tad-disinn u l-kriterji ta ‘aċċettazzjoni.

4.6 Reviżjoni tad-Disinn

funzjonijiet Proġett bħal kodifikazzjoni u l-ittestjar għandhom jiġu ppreżentati fir-reviżjoni. Metodu komuni sabiex jiżgura reviżjonijiet huma listi ta ‘kontroll.

4.7 Disinn Verifika

Dan jikkonsisti reviżjonijiet, ittestjar modulu u l-ittestjar integrazzjoni.

4.8 Disinn Validazzjoni

test finali sistema, tal-prodott tas-softwer komplut flimkien mad-reviżjoni ta ‘dokumentazzjoni għall-utent. Għandu jkun hemm ppjanati u l-validazzjoni ddokumentati. Beta ittestjar jkun konformi mal-ISO sakemm l-ittestjar beta huwa kopert minn ftehim ċar bejn il-fornitur u l-klijent l-ittestjar beta.

4.9 Bidliet Disinn

ISO 9001 teħtieġ li wara r-rilaxx tad-dokumentazzjoni tad-disinn jew sors, il-bidliet kollha għandhom jgħaddu minn proċess formali fejn il-bidliet huma dokumentati, revista u approvata qabel l-implimentazzjoni.

bidliet mhux ikkontrollat għal dokumenti tekniċi kumplessi jew programmi huma estremament perikolużi u bħala tali l-istandard ma tippermettix dan.
5. Dokument u l-Kontroll tad-Dejta

Informazzjoni li jikkontrolla l-iżvilupp / manutenzjoni ta ‘softwer. L-istandard jeħtieġ li dawk li jeħtieġu xi dokument /-data għandu jkollu aċċess għalih. Bidliet fid-dokumenti u d-dejta għandha tiġi kkontrollata.

5.1 Ġenerali

dokumenti u dejta esterna għandhom jinħażnu. Hija tista ‘tkun maħżuna fuq kwalunkwe forma (f’forma stampata, medja elettronika).

5.2 Dokument u Approvazzjoni tad-Data u Ħruġ

Qabel toħroġ dokumenti u data għandhom jiġu riveduti u approvati qabel kull ħruġ. Lista dokument li fih wieħed għandu jsib l-verżjoni attwali ta ‘dokument. dokumenti invalidi jew skaduti għandhom jitneħħew jew jiġu mmarkati b’mod ċar.

5.3 Dokument u Tibdil Dejta

Il-persuna / i responsabbli mill-proċess ta ‘reviżjoni u l-approvazzjoni għandhom jiġu speċifikati.

6. Xiri

Fil-każ ta ‘sottokuntrattur, inti għadek responsabbli. Jiġifieri jekk inti tapplika għal kuntratt u jissottokuntratta l-ħidma, l-istandards ISO għadu taħt ir-responsabbiltà tiegħek u rekwiżiti ISO m’għandhomx għalfejn jiġu imposti fuq is-subkuntrattur.

6.1 Ġenerali

Jekk manpower jinxtara, l-istandard teħtieġ li ssegwi proċedura li tikseb l-aħjar nies. Il-poplu se jkunu kkontrollati minn fornitur u mhux subkuntrattur.
Biex jiġi żgurat li s-softwer mixtri jikkonforma mal-ħtiġiet:
– Rekwiżiti Kuntratt dwar il-proċeduri sottokuntratturi
– Verifika tas-sistema ta ‘kwalità sottokuntrattur
– Sottokuntrattur Iċċekkja passat prestazzjoni
– Stħarriġ tal-sottokuntrattur waqt kuntratt
– Reviżjoni Xhud u ttestjar
– Test u reviżjoni tal-prodott ta ‘subkuntrattur.

6.2 Evalwazzjoni ta ‘sottokuntratturi

Persuna b’awtorità u l-kompetenza meħtieġa għandha jiġġudikaw kull sottokuntrattur u jiddeċiedi jekk għall-użu. Id-deċiżjonijiet għandhom jiġu dokumentati.

Il-fornitur għandu jiddeċiedi liema kontroll fuq subkuntrattur li se jkollu. L-istandard ma jsemmix kemm kontroll għandu jkollok. Hija biss issemmi li deċiżjoni għandha ssir bl-użu fatti.

Każ speċjali huwa meta softwer jinxtara permezz imnut. F’dan il-każ subkuntrattur organizzazzjoni li magħha x-xiri titwettaq, mhux l-iżviluppatur oriġinali tas-software.

Jekk xiri isir permezz ISO imnut 9001 teħtieġ li inti tiddefinixxi sa liema punt inti tpoġġi rekwiżiti fuq il-bejjiegħ bl-imnut għall-kontroll fornitur tagħha.

6.3 Purchasing Dejta

Rekwiżiti dwar proċess ta ‘żvilupp għandhom jiġu dokumentati fil-kuntratt flimkien ma’ rekwiżiti fornitur li tapprova r-riżultati tax-xogħol u l-proċeduri.

6.4 Verifika tal-Prodott mixtri

Dokumentazzjoni ta ‘deċiżjonijiet dwar il-verifika ta’ kull mixtri għodda ta ‘żvilupp jew prodott inklużi.

– L-ebda lista ta ‘fornituri approvati
– Il-kontroll mhux xierqa tal subkuntrattur
– L-ebda verifika dokument ta ‘oġġetti mixtrija
– Kuntratt Inappropriate ma subkuntrattur.

7 Kontroll ta ‘forniti Customer Prodott

Il-fornitur għandu jkollu proċeduri għall-verifika, il-ħażna u l-manutenzjoni ta ‘softwer tal-klijent fornuti. Madankollu, il-kwalità hija r-responsabbiltà tas-software.

Persuna mhux konformità jiġri minħabba responsabbiltà mhux ċara tar-responsabbiltà bejn klijent u l-fornitur.

8 Speċifikazzjoni tal-Prodott u Traċċabilità

Il-fornitur tas-software għandu jżomm kontroll fuq:
– Fuq liema dokument ta ‘qabel u toħorġu hija bbażata
– Fuq liema speċifikazzjoni hija bbażata
– Liema korrezzjonijiet u emendi ġew inklużi fil liema programmi ta ‘sors
– Dak li ġara ma ‘kull rapport problema
– Minn dak sors kien modulu speċifiku iġġenerat.

Kontroll 9 Proċess

proċedura ddokumentata sabiex il-proċess replikazzjoni fl-operazzjoni u l-proċedura għall-immaniġġjar ta ‘kaptan PROMA € ™ s / libreriji. Biex jiġi żgurat li versioning korretta hija użata.

– L-ebda proċedura ddokumentata sabiex replikazzjoni
– Immaniġġjar mhux xieraq tal-kaptan PROMA € ™ s jew disketti.

10 Spezzjoni u Ttestjar

proċeduri bil-miktub għall-ispezzjoni u l-ittestjar li jsir b’konnessjoni ma ‘replikazzjoni.

– Funzjoni ta ‘awtomatikament iċċekkjar PROMA € ™ s ma kienx spezzjonat
– L-ebda proċedura dokumentata biex jiġu ttestjati PROMA € ™ s.

11 Kontroll ta ‘Spezzjoni, kejl u Tagħmir tat-Test

Il-fornitur għandu jagħżel l-apparat tal-kejl xieraq u jsegwu proċedura dokumentata għall-kontroll tat-tagħmir. Kull verżjoni tas-software ġdid għandhom jiġu ttestjati għall suffiċjenza.

12 Spezzjoni u Status tat-test

Speċifikazzjonijiet u programmi għandhom ivverifikata permezz ta ‘reviżjonijiet u l-ittestjar. Il-fornitur għandu jkollu proċeduri li jipprojbixxu l-użu ta ‘speċifikazzjonijiet mhux ivverifikati jew programmi.

13 Kontroll ta ‘mhux konformi Prodott

prodotti mhux konformi m’għandux jintuża involontarjament. għandhom jinħolqu Proċedura għall-immaniġġjar modifiki malajr fil-każ ta ‘żbalji kritiċi.

– L-identifikazzjoni ċara ta ‘oġġetti kontrollati li fihom żbalji mhux ikkoreġuti
– Metodu li wieħed jislet klijent aċċettazzjoni mal-kunsinna
– Fil-każ ta ‘modifiki malajr, għandu jiġi dokumentat
– Ir-reviżjoni entrati hekk modifikati se jkunu elevati għal istess status bħal bqija ta ‘softwer.

14 azzjoni korrettiva u preventiva

– Ġestjonir effettiva ta ‘rapporti li ma jikkonformawx mal-ħtiġiet
– Ġestjonir effettiva ta ‘rapporti li jindikaw’ nuqqasijiet fil-proċess ta ‘żvilupp
– Il-ġbir u l-analiżi ta ‘informazzjoni disponibbli dwar il-prodott u l-proċess mhux konformità u azzjonijiet preventivi Attiva.

Informazzjoni dwar problemi li ltaqgħu magħhom għandhom imexxu t-titjib tal-proċess ta ‘żvilupp.

– Ilment Klijent ma ġiex immaniġġjat kif xieraq
– Nuqqas instabet iżda mhux ikkoreġuti
– L-ebda proċedura sabiex jiġi żgurat li l-problemi jiġu analizzati u tittieħed azzjoni fuqhom
– L-ebda proċedura għall-diffikultajiet bil japplikaw ir-regoli u l-proċeduri ta ‘rappurtar.

15 Immaniġġjar, ħażna, ippakkjar, Preservazzjoni u t-Tqassim

Japplika għal softwer replikat fuq Prom, disk jew mezz ieħor.
Midja għandhom ikunu ttikkettati u ppakkjati b’mod korrett. Id-dejta għandha tiġi appoġġjata. Għandu jkun hemm ukoll il-ħila li jipprovdi protezzjoni minn ħsara mhux intenzjonata.

16 Kontroll tar-reġistri ta ‘kwalità

dokumenti ta ‘kwalità juri li ttieħdu azzjonijiet biex ikun żgurat jew kontroll tal-kwalità. L-istandard jeħtieġ li jkun hemm proċedura għall-immaniġġjar ta ‘rekords ta’ kwalità. Ir-rekords għandhom jinħażnu b’mod xieraq sabiex huma jkunu faċilment aċċessibbli.
– L-ebda regoli għaż-żamma ta ‘rekords ta’ kwalità
– Ir-rekords Reviżjoni ma jinżammux
– Ir-rekords tat-test ma jinżammux
– Perjodu ta ‘żamma tar-rekords ta’ kwalità mhix definita

Verifiki 17 Kwalità Intern

Għandu jkun hemm entità indipendenti li regolarment verifiki operazzjonijiet kollha li jistgħu jaffettwaw prodott jew servizz ta ‘kwalità. Dawn huma kondotti f’isem kumpanija tal-ġestjoni. Għandu jkun hemm pjan ta ‘verifika.

– L-ebda pjan ta ‘verifika
– Pjan ta ‘verifika ma aġġornat

18 Taħriġ

Kumpannija għandha tassigura li l-persunal ikun imħarreġ għall-kompiti meħtieġa. Proċedura għal:
– Identifikazzjoni tal-ħtiġijiet ta ‘taħriġ għal kull pożizzjoni persunal
– Tipprovdi taħriġ bħal dan
– Żomm ir-rekords tat-taħriġ tal-membri kollha tal-persunal.

It-taħriġ għandu jkun dokumentat u suffiċjenti. B’biżżejjed rridu nfissru li l-persuna jkun kapaċi jwettaq xogħol tiegħu / tagħha għal standard għoli biżżejjed.

– L-ebda proċeduri għall-ippjanar jew taħriġ
– L-ebda rekords tat-taħriġ
– Mhux rċevew taħriġ xieraq għall-ħidma tiegħu jew tagħha.

19 Servicing

Fornitur għandu jkollu proċeduri dokumentati għall-manutenzjoni, jekk dan ikun imsemmi fil-kuntratt. Fis-software huwa dwar korrezzjonijiet ta ‘żbalji u titjib għall-software mogħtija.

Proċeduri biex jiġu trattati ilmenti u talbiet għal modifiki. Il-fornitur mhuwiex obbligat li jipprovdi manteniment jekk ma jkunx imsemmi fil-kuntratt. Għandu jkun hemm proċeduri ta ‘manutenzjoni għal softwer qodma.

– Xogħol ta ‘manutenzjoni għal klijent mingħajr kuntratt
– Metodi speċifiċi għall-manutenzjoni tal-prodott antik m’hemm xejn dokumentat
– L-ebda proċedura għall-ittestjar wara l-manutenzjoni.

20 Tekniki Istatistika

Għandu jkun hemm ġbir u l-analiżi tad-dejta dwar in-numru ta ‘żbalji misjuba fil-fażijiet differenti. Informazzjoni dwar inabbiltà li jilħqu l-iskadenzi u tragwardi għandhom jiġu analizzati.

“————————————————– ————————————————– ————————————————–

Ondersteuning vertaling:
————————————————– ————————————————– ————————————————–
ISO 9001 Twintig Kwaliteit elemente

‘N Kykie geneem sal word by die vereistes van die oogpunt van maatskappye die ontwikkeling van sagteware. ISO 9001 standaard is bedoel vir die vervaardigingsbedryf. Die vereistes is geïnterpreteer vir sagteware-ontwikkeling in ooreenstemming met ISO 9000-3 en TickIT.

Daar is 20 hoofelemente. Elke konsep is goed bekend in die kwaliteit beheer gemeenskap.

1. bestuursverantwoordelikheid

1.1 Kwaliteit beleid

Die standaard vereis dat die verskaffer bestuur om ‘n kwaliteit beleid, waar dit sê die maatskappy sal produseer kwaliteit produkte uit te reik.

Die kwaliteit van die beleid sal:
– Definieer die managementâ € ™ se verbintenis tot kwaliteit
– Die companyâ € ™ s doelwitte definieer met betrekking tot kwaliteit, dit wil sê wat bestuur beteken deur gehalte
– Om die behoeftes van die customerâ € ™ s relevante Wees
– Verstaan word in die organisasie
– Geïmplementeer


– Verklaring te vaag of beleid nie verstaan word deur personeel
– Kwaliteit beleid is nie geïmplementeer word.

Bv van kwaliteit beleid

â € œWe bereik gehalte deur gemotiveerde en opgeleide personeel, gedefinieer werksprosedures en intensiewe hersiening en toetsing activities.â €

1.2 Organisasie

Die standaard vereis dokumentasie van verantwoordelikheid, gesag en onderlinge van alle personeel wat kwaliteit. Dit beteken dat indien ‘n persoon het ‘n verantwoordelikheid, dit sal formeel toegeken deur die toepaslike bestuurder. Die persoon moet die gesag om die verantwoordelikheid na te kom nie.

Volgens ISO, verantwoordelikheid beteken:

â € OAS plig om op te tree op oneâ € ™ s vanself wanneer iets gedoen moet word sonder om toldâ €.


– Bestaande van ‘n verantwoordelikheid wat nie vervul kan word.


– Projek-lyn
– Projek-kliënt
– Projek-onderhoud organisasie
– Sagteware ontwikkeling hardeware ontwikkeling
– Onderhoud organisasie-hulptoonbank
– Verkope-ontwikkeling

Hulpbronne vereis dat die data:
– Identifiseer die vereistes vir hulpbronne
– Ken opgeleide personeel.

Bestuursverteenwoordiger vereis aanstelling van bestuurder verteenwoordiger met gesag en verantwoordelikheid om:
– Maak seker dat die maatskappy voldoen aan die vereistes in ISO 9001
– Rapporteer die prestasie van die kwaliteit stelsel aan korporatiewe beheer

1.3 Management Review

Kwaliteit bestuurder moet van tyd tot tyd die resultate van aan te bied
– Kwaliteit oudits
– Statistieke van gehalte klagtes
– Rekords van regstellende stappe

Die resultate word op ‘n aangeteken bestuursvergadering met notas oor wat dit bygewoon het, wat aangebied is en watter besluite geneem en gemaak.

2. Kwaliteit System

Kwaliteit stelsel â € “”â € œDe organisatoriese struktuur, verantwoordelikhede, prosedures, prosesse en hulpbronne vir die implementering van kwaliteit management.â €

Prosedures, reëls, besluite moet in skrif te stel. As jy ‘n reël of prosedure wat nie vereis word deur die ISO 9001 het die standaard vereis steeds dat daar geskrywe.

‘N kwaliteit handleiding sal verwys en dokumentasie van die kwaliteit stelsel bevat.


– ‘N Oudit is ‘n voorbeeld, dus as ‘n voorbeeld, daar is klein non-conformances, en hulle is vas, dit kan nog ‘n nie-nakoming, want die ouditeur kan vermoed dat daar baie meer klein non-conformances.
– Bestaande geskryf prosedures nie nagekom word.

3. Contract Review

Die verskaffer tjeks voor die ondertekening van kontrak wat die organisasie in staat wees om uit te voer wat nodig is deur die kontrak.

Vrae wat gevra moet word, sluit in:
– Is die vereistes gedokumenteer en verstaan?
– Is die aanvaarding kriteria ingesluit?
– Het vereistes verskil van die tender is opgelos?
– Kan die verskaffer monster genoeg hulpbronne vir die kontrak?
– Kan die verskaffer monster die bevoegdheid wat nodig is vir die kontrak?
– Kan die taak betyds voltooi?

Die standaard vereis dat ‘n gedokumenteerde prosedure met resensies ingesluit word. Die verskaffer moet identifiseer hoe kontrak wysigings en hantering van vereistes spesifikasie tussen kliënt en verskaffer gedefinieer.

4. Ontwerp beheer

4.1. algemene
ISO vereis dat jy van plan is voor doen en spesifiseer voordat die ontwerp.

4.2. Ontwerp en Ontwikkelingsbeplanning

Ontwerp plan moet die volgende bevat:
– Definisie van metodologie wat gebruik moet word in die ontwikkeling van die produk
– Tydskedules, verantwoordelikhede, werkopdragte en vordering beheer
– Fase projek sal verdeel word. Dit sluit in insette, uitset en verifiëring van uitset.
– Beskrywing van metodes en gereedskap wat gebruik gaan word

Kwaliteit plan moet die volgende bevat:
– Kwaliteit teikens
– Kriteria vir aanvaarding
– Identifisering van beplanning, validering en verifikasie.
– Verantwoordelikhede vir kwaliteit aktiwiteite.

Indien ‘n maatskappy wil ISO kwalifikasie die planne moet in alle projekte gehou word verkry, aangesien ISO sertifisering is vir die hele maatskappy en nie vir spesifieke projekte.

4.3 Organisasie en tegniese koppel

As daar ‘n groep-werk, moet die koppelvlakke tussen hulle geïdentifiseer word, gedokumenteer en aan diegene wat ‘die inligting. Die dokumentasie moet gereeld hersien word.

4.4 Ontwerp Input

Vereistes spesifikasies bevat die ontwerp insette in die ontwikkeling van sagteware. Dit kan gedoen word deur die koper of wat voorberei is deur die verskaffer met behulp van wette en regulasies. Nog ‘n ontwerp insette sluit ontwerp kodering wat gebruik word as insette tot kodering.

Die standaard wil om te verseker dat die werk die produk van elke stap aan die vereistes.

In die ontwikkeling van sagteware, vereiste veranderinge is algemeen so ‘n prosedure vir die hantering van nuwe en veranderde vereistes van die koper geskep.

4.5 Ontwerp Uitgawe

Ontwerp Uitgawe: die ontwerp dokumentasie en die bronkode. ISO vereis dat ontwerp dokumente en kodering hersien voordat release.

‘N Prosedure vir die aanvaarding van die ontwerp uitset en kriteria van aanvaarding moet geskep word.

4.6 Ontwerp Review

Projek funksies soos kodering en toetsing sal aangebied word by die hersiening. ‘N Algemene metode om te verseker resensies is kontrolelyste.

4.7 Ontwerp verifikasie

Dit bestaan uit resensies, module toets en integrasie toets.

4.8 Ontwerp Validation

Finale stelsel toets, van die volledige sagteware produk saam met die hersiening van dokumentasie gebruiker. Daar moet beplan en gedokumenteer bekragtiging. Beta-toets is in ooreenstemming met ISO solank die beta toets word gedek deur ‘n duidelike ooreenkoms tussen verskaffer en beta-toets kliënt.

4.9 Ontwerp Wysigings

ISO 9001 vereis dat nadat vrystelling van ontwerp dokumentasie of bron, sal alle veranderings gaan deur ‘n formele proses waar veranderinge gedokumenteer, hersien en voor implementering goedgekeur.

Onbeheerde veranderinge aan komplekse tegniese dokumente of programme is uiters gevaarlik en as sodanig die standaard nie toelaat nie.
5. Document en Data Control

Inligting wat die ontwikkeling / instandhouding van sagteware beheer. Die standaard vereis dat diegene wat ‘n dokument moet / data sal toegang daartoe het. Veranderinge aan dokumente en data sal beheer word.

5.1 Algemene

Eksterne dokumente en data sal gestoor word. Dit kan gestoor word op enige vorm (harde kopie, elektroniese media).

5.2 Dokument en Data Goedkeuring en Uitgawe

Voordat kwessie dokumente en data sal hersien word en voor elke probleem goedgekeur. ‘N Dokument lys waarin sal een uit te vind die huidige weergawe van ‘n dokument. Ongeldig of verouderde dokumente moet verwyder of duidelik gemerk.

5.3 Dokument en Data Wysigings

Die persoon / persone in beheer van die hersiening en goedkeuring-proses sal gespesifiseer word.

6. Aankope

In die geval van subkontrakteur, jy bly steeds verantwoordelik. Maw As jy aansoek doen vir ‘n kontrak en subkontrakteer die werk, ISO standaarde is steeds onder jou verantwoordelikheid en ISO vereistes hoef nie te word opgelê op die subkontrakteur.

6.1 Algemene

As mannekrag is gekoop, die standaard vereis dat jy ‘n proses wat jy die regte mense te kry volg. Die mense sal beheer word deur verskaffer en nie subkontrakteur.
Om te verseker dat gekoop sagteware voldoen aan vereistes:
– Contract vereistes op die subkontrakteurs prosedures
– Oudit van die subkontrakteur kwaliteit stelsel
– Check subkontrakteur vorige prestasie
– Ondersoek die subkontrakteur tydens kontrak
– Getuie hersiening en toetsing
– Toets en hersiening produk van subkontrakteur.

6.2 Evaluering van Subkontrakteurs

Persoon met die nodige gesag en bevoegdheid sal elke subkontrakteur oordeel en besluit of om te gebruik. Die besluite sal gedokumenteer word.

Die verskaffer moet besluit wat beheer oor subkontrakteur dit sal hê. Die standaard maak geen melding van hoeveel beheer jy moet hê. Dit noem net dat ‘n besluit geneem moet word deur die gebruik van feite.

‘N Spesiale geval is wanneer sagteware aangekoop deur die kleinhandel. In hierdie geval subkontrakteur is organisasie waarmee die aankoop gedoen word, nie die oorspronklike ontwikkelaar van die sagteware.

As aankope gedoen word deur middel van kleinhandel ISO 9001 vereis dat jy definieer in watter mate jy vereistes op die handelaar om sy verskaffer te beheer.

6.3 Aankope Data

Vereistes op ontwikkelingsproses sal gedokumenteer word in die kontrak saam met verskaffer vereistes te werk resultate en prosedures goedkeur.

6.4 Ondersoek van aangekoopte produk

Dokumentasie van besluite oor die verifikasie van elke gekoop instrument vir ontwikkeling of ingesluit produk.

– Geen lys van goedgekeurde verskaffers
– Ontoepaslike beheer van subkontrakteur
– Geen dokument verifikasie van aangekoop items
– Ontoepaslike kontrak met subkontrakteur.

7 Beheer van die kliënt verskaf Produk

Die verskaffer moet prosedures vir verifikasie, stoor en instandhouding van die kliënt verskaf sagteware te hê. Maar die kwaliteit is die verantwoordelikheid van die sagteware.

‘N Nie-conformance gebeur as gevolg van onduidelik verantwoordelikheid van verantwoordelikheid tussen die kliënt en verskaffer.

8 Produk spesifikasie en naspeurbaarheid

Die sagteware verskaffer moet beheer te hou oor:
– Op watter voorafgaande dokument en reik dit gebaseer
– Op watter spesifikasie dit gebaseer
– Wat regstellings en wysigings is ingesluit in watter bron programme
– Wat het gebeur met elke probleem verslag
– Van watter bron is ‘n spesifieke module gegenereer.

9 Prosesbeheer

Gedokumenteerde prosedure vir die replikasie proses in die werking en prosedure vir die hantering van meester PROMâ € ™ s / biblioteke. Om te verseker dat die korrekte weergawes gebruik.

– Geen gedokumenteerde prosedure vir replisering
– Onbehoorlike hantering van meester PROMâ € ™ s of diskette.

10 Inspeksie en toetsing

Geskrewe prosedures vir die inspeksie en toetsing gedoen moet word in verband met replikasie.

– Funksie van outomaties nagaan PROMâ € ™ s nog nie geïnspekteer
– Geen gedokumenteerde prosedure vir die toets van PROMâ € ™ s.

11 Beheer van inspeksie, meet en toets toerusting

Die verskaffer moet die toepaslike meting toerusting te kies en volg ‘n gedokumenteerde prosedure vir die beheer van toerusting. Elke nuwe sagteware weergawe moet getoets word vir bekwaamheid.

12 inspeksie en toets Status

Spesifikasies en programme moet geverifieer deur resensies en toetse. Die verskaffer moet prosedures wat gebruik maak van geverifieerde spesifikasies of programme verbied het.

13 Beheer van Nie-konformerende Produk

Nie-konformerende produkte moet nie per ongeluk gebruik word. ‘N Prosedure vir die hantering van vinnige veranderinge in die geval van kritieke foute moet geskep word.

– Duidelike identifisering van beheerde items wat reggestelde foute bevat
– Metode om die kliënt die aanvaarding met lewering ontlok
– In die geval van ‘n vinnige veranderinge, moet dit gedokumenteer
– Hersiening van so verander items sal verhef tot dieselfde status as ander sagteware.

14 Regstellende en voorkomende optrede

– Doeltreffende hantering van verslae wat nie voldoen aan vereistes
– Doeltreffende hantering van verslae aandui tekortkominge in die ontwikkelingsproses
– Aktiewe versameling en ontleding van die beskikbare inligting oor die produk en proses nie-nakoming en voorkomende optrede.

Inligting oor probleme moet verbeterings van die ontwikkelingsproses ry.

– Customer klagte nie behoorlik hanteer
– Tekort gevind, maar nie reggestel
– Geen prosedure te verseker dat probleme ontleed en op opgetree
– Geen prosedure vir die aanmelding van probleme met die toepassing van reëls en prosedures.

15 hantering, berging, verpakking, Bewaring en aflewering

Geld vir sagteware herhaal op PROM, skyf of ander medium.
Media sal gemerk word en korrek verpak. Data word gerugsteun. Daar moet ook die vermoë om beskerming te bied van onbedoelde skade.

16 Beheer van kwaliteit Records

Kwaliteit dokumente wys watter aksies geneem om te verseker of tjek gehalte. Die standaard vereis dat daar ‘n prosedure vir die hantering van kwaliteit rekords wees. Die rekords moet gestoor word in ‘n gepaste wyse, sodat hulle is maklik toeganklik.
– Geen reëls vir die behoud van kwaliteit rekords
– Review rekords word nie gehou
– Toets rekords word nie gehou
– Tydperk van die behoud van kwaliteit rekords is nie gedefinieer

17 Interne kwaliteitoudits

Daar moet ‘n onafhanklike entiteit wat gereeld oudits alle bedrywighede wat produk of diens gehalte kan beïnvloed word. Dit is gedoen namens maatskappy bestuur. Daar moet ‘n oudit plan te wees.

– Geen ouditplan
– Oudit plan nie up to date

18 Opleiding

Maatskappy moet verseker dat personeel is opgelei vir take wat nodig is. ‘N prosedure om:
– Identifiseer opleidingsbehoeftes vir elke personeellid posisie
– Voorsien sodanige opleiding
– Hou rekords van die opleiding van alle personeellede.

Opleiding moet gedokumenteer word en voldoende. Deur voldoende bedoel ons dat die persoon in staat is om die uitvoering van sy / haar werk op ‘n hoë genoeg standaard wees.

– Geen prosedures vir die beplanning en opleiding
– Geen opleiding rekords
– Nie ontvang behoorlike opleiding vir sy of haar taak.

19 Versiening

Verskaffer sal prosedures gedokumenteer vir diens as dit in die kontrak genoem word. In sagteware dit gaan oor fout regstellings en verbeterings aan afgelewer sagteware.

Prosedures vir die hantering van klagtes en versoeke vir veranderinge. Die verskaffer is nie verplig om onderhoud te voorsien indien dit nie in die kontrak genoem word. prosedures onderhoud vir ou sagteware moet word.

– Onderhoud werk vir ‘n kliënt sonder ‘n kontrak
– Spesifieke metodes vir die instandhouding van die ou produk is nie gedokumenteer
– Geen prosedure vir die toets ná onderhoud.

20 Statistiese Tegnieke

Daar moet insameling en ontleding van data oor aantal foute wat in die verskillende fases wees. Inligting oor die onvermoë om spertye en mylpale voldoen moet word ontleed.

“————————————————– ————————————————– ————————————————–

përkthim Support:
————————————————– ————————————————– ————————————————–
ISO 9001 Quality Twenty Elements

Një vështrim do të merren në kërkesat nga pikëpamja e shoqërive në zhvillim software. standarde ISO 9001 ishte destinuar për industrinë e prodhimit. Kërkesat janë interpretuar për zhvillimin e softuerit në përputhje me ISO 9000-3 dhe TickIT.

Ka 20 elementet kryesore. Çdo koncept është i njohur edhe në komunitetin e menaxhimit të cilësisë.

Përgjegjësia 1. Menaxhimi

1.1 Politika e kualitetit

Standardi kërkon menaxhimin e furnizuesit të nxjerrë një politikë të cilësisë, ku ai thotë se kompania do të prodhojë produkte të cilësisë.

Politika e kualitetit do të:
– Definimi i managementâ € ™ s angazhim për të cilësisë
– Definimi companyâ € ™ s objektivat lidhur me cilësinë, që është, ajo që menaxhimi do të thotë nga cilësia
– Të jenë të rëndësishme për nevojat e customerâ € ™ s
– Të jetë i kuptuar në organizimin
– Të jetë i zbatuar


– Deklaratë shumë i paqartë ose i politikave nuk është kuptuar nga stafi
– Politika e cilësisë nuk është zbatuar.

Psh i politikës Cilësisë

â € œwe arritur cilësinë përmes staf të motivuar dhe të aftë, procedurat e përcaktuara të punës, dhe rishikim intensiv dhe testimin activities.â €

1.2 Organizata

Standardi kërkon dokumentacionin e përgjegjësisë, autoritetit dhe ndërlidhjen e të gjithë personelit që ndikojnë në cilësinë. Kjo do të thotë se në qoftë se një person ka një përgjegjësi, do të caktohet zyrtarisht nga menaxheri përkatës. Personi duhet të ketë autoritetin për të përmbushur përgjegjësinë.

Sipas ISO, përgjegjësia do të thotë:

â € detyrë œa për të vepruar në oneâ € ™ s marrëveshjes së vet kur diçka duhet të bëhet pa u toldâ €.


– Ekzistues i një përgjegjësi që nuk mund të përmbushen.


– Projekt-line
– Projekt-klient
– Organizimi i projektit të mirëmbajtjes
– Zhvillimi i Software zhvillimit-hardware
– Tavolinë Maintenance organizatë-ndihmë
– Sales-zhvillimit

Burimet kërkojnë që furnizuesit:
– Identifikimi i kërkesave për burime
– Caktimi i personelit të trajnuar.

përfaqësues të menaxhimit kërkon emërimin e përfaqësuesit të menaxherit me autoritet dhe përgjegjësi për:
– Sigurohuni që kompania plotëson kërkesat në ISO 9001
– Raporti i performancës së sistemit të cilësisë në menaxhimin e kompanisë

1.3 Shqyrtimi i Menaxhimit

menaxheri i cilësisë duhet periodikisht të paraqesë rezultatet e
– Auditimet Quality
– Statistikat e ankesave të cilësisë
– Të dhënat e veprimeve korrigjuese

Rezultatet duhet të paraqitet në një takim regjistruar menaxhimit me shënimet mbi të cilët kanë marrë pjesë, ajo që u prezantua dhe cilat vendime janë marrë dhe bërë.

2. Sistemi i Cilësisë

Sistemi i cilësisë â € “”â € œThe strukturën organizative, përgjegjësitë, procedurat, proceset dhe burimet për zbatimin e cilësisë management.â €

Procedurat, rregullat, vendimet do të vënë në shkrim. Nëse ju keni një rregull ose procedurë që nuk është e nevojshme nga ISO 9001, standardi ende kërkon që është shkruar.

Një manual i cilësisë duhet të përmbajë referencën dhe dokumentacionin e sistemit të cilësisë.


– Auditimi është një mostër, pra në qoftë se në një mostër, nuk janë të vogla jo-conformances, dhe ata janë të fiksuara, ajo ende mund të jetë një jo-konformitetit, sepse auditori mund të dyshojnë se ka shumë më tepër të vogla jo-conformances.
– Procedurat ekzistuese të shkruara nuk janë të respektohen.

Rishikimi 3. Kontrata

Kontrollet furnizuesit para nënshkrimit të kontratës që organizata të jetë në gjendje për të kryer atë që kërkohet në kontratë.

Pyetjet që duhet të kërkohet të përfshijnë:
– A janë dokumentuar dhe kuptuar kërkesat?
– A janë përfshirë kriteret e pranimit?
– A janë zgjidhur kërkesat e ndryshme nga tenderi?
– A mund të furnizuesit të grumbullojë burime të mjaftueshme për kontratën?
– A mund furnizuesi grumbullojë kompetencën e nevojshme për kontratën?
– A mund detyra të përfundojë në kohë?

Standardi kërkon që të përfshihet një procedurë të dokumentuar me komente. Furnizuesi duhet të identifikojë se si të përcaktohen ndryshimet e kontratës dhe trajtimin e karakteristikave të kërkesave në mes të klientit dhe furnizuesit.

4. Projektimi i Kontrollit

4.1. i përgjithshëm
ISO kërkon që ju planifikoni para se të bëjnë dhe të përcaktojë para dizajnimin.

4.2. Design and Development Planning

Plani i dizajnit duhet të përmbajë:
– Përcaktimi i metodologjisë që do të përdoret në zhvillimin e produktit
– Oraret Koha, përgjegjësitë, detyrat e punës dhe kontrollit progres
– Projekti Fazat do të ndahet. Kjo përfshin të dhëna, prodhimit dhe verifikimin e prodhimit.
– Përshkrimi i metodave dhe mjeteve që do të përdoren

Plani i cilësisë duhet të përmbajë:
– Objektivat e Cilësisë
– Kriteret për pranimin
– Identifikimi i planifikimit, miratimit dhe verifikimit.
– Përgjegjësitë për aktivitete të cilësisë.

Nëse një kompani dëshiron për të fituar ISO kualifikimin planet duhet të mbahet në të gjitha projektet, që nga certifikimit ISO është për të gjithë kompaninë dhe jo për projekte specifike.

4.3 Interfaces organizative dhe teknike

Nëse ka grup të punës, interfaces mes tyre duhet të identifikohen, dokumentuar dhe transmetuar për ata që kanë nevojë për informacionin. Dokumentacioni duhet të rishikohet rregullisht.

4.4 Projektimi Input

Kërkesat Specifikimet përmbajnë të dhëna projektimit në zhvillimin e softuerit. Kjo mund të bëhet nga blerësi ose të përgatitura nga furnizuesi duke përdorur ligjet dhe rregulloret. Një input dizajn përfshin projektimin kodim e cila është përdorur si input për kodim.

Standardi kërkon të siguruar që produkti puna e çdo hap i plotëson kërkesat.

Në zhvillimin e programeve, ndryshimet Kërkesat janë të zakonshme në mënyrë të krijohet një procedurë për trajtimin e kërkesave të reja dhe ndryshuar nga blerësi.

4.5 Projektimi Output

Dizajni Output: dokumentacioni i projektimit dhe kodin burim. ISO kërkon që dokumentet e projektimit dhe kodim të rishikohen para lirimit.

duhet të krijohet një procedurë për pranimin e prodhimit të projektimit dhe kriteret e pranimit.

4.6 Design Review

Funksionet e projektit si kodim dhe testimin do të paraqitet në shqyrtim. Një metodë e zakonshme për të siguruar komente janë listat kontrolluese.

4.7 Projektimi Verifikimi

Kjo përbëhet nga kritikat, testim modul dhe testimin e integrimit.

4.8 Projektimi Validation

sistemi Testi final, të produktit të plotë software së bashku me shqyrtimin e dokumentacionit të përdoruesit. Nuk duhet të planifikohet dhe të dokumentuar validation. Testimi Beta është në përputhje me ISO sa kohë që testimi beta është i mbuluar nga një marrëveshje të qartë ndërmjet furnizuesit dhe konsumatorit beta-testimin.

4.9 Ndryshimet Dizajn

ISO 9001 kërkon që pas lëshimit të dokumentacionit të projektimit ose burimi, të gjitha ndryshimet do të kalojnë nëpër një proces formal, ku ndryshimet janë të dokumentuara, shqyrtuar dhe miratuar para zbatimit.

ndryshimet e pakontrolluara në dokumente komplekse teknike apo programeve janë jashtëzakonisht të rrezikshme dhe si i tillë standardin nuk e lejon atë.
5. Dokument dhe Kontrollit të dhënave

Informacioni që kontrollon zhvillimit / mirëmbajtjen e softuerit. Standardi kërkon që ata të cilët kanë nevojë për një dokument / të dhënave duhet të kenë qasje në të. Ndryshimet në dokumentet dhe të dhënat do të kontrollohet.

5.1 Të përgjithshme

Dokumentet e jashtëm dhe të dhënat do të ruhen. Ajo mund të ruhet në ndonjë formë (kopje e vështirë, media elektronike).

5.2 Dokumenti dhe miratimi i të dhënave dhe Issue

Para çështje dokumentet dhe të dhënat do të shqyrtohen dhe miratohen para çdo çështje. Një listë dokument në të cilën do të gjeni versionin e tanishëm të një dokumenti. Dokumentet e pavlefshme ose të vjetëruara duhet të hiqet ose të shënohet në mënyrë të qartë.

5.3 Dokumenti dhe të dhënave Ndryshimet

Personi / s në krye të procesit të shqyrtimit dhe miratimit do të specifikohen.

6. Blerja

Në rastin e nënkontraktorit, ju jeni ende përgjegjës. Dmth në qoftë se ju aplikoni për një kontratë dhe nënkontratë punën, standardet ISO është ende nën përgjegjësinë tuaj dhe kërkesat e ISO nuk duhet të imponohet nënkontraktorit.

6.1 Të përgjithshme

Nëse fuqia punëtore është blerë, standardi kërkon që ju të ndjekin një procedurë që ju të merrni njerëzit e duhur. Njerëzit do të kontrollohet nga furnizuesit dhe jo nënkontraktorit.
Për të siguruar që software blerë në përputhje me kërkesat:
– Kërkesat e kontratës për procedurat e nënkontraktorët
– Auditimi i sistemit të cilësisë nënkontraktor
– Nënkontraktor Kontrolloni kaluara performancës
– Anketa e nënkontraktor gjatë kontratës
– Shqyrtimi Dëshmitari dhe testimi
– Test dhe produkt rishikimin e nënkontraktorit.

6.2 Vlerësimi i Nënkontraktorët

Person me autoritet dhe kompetenca të nevojshme do të gjykojë secilin nënkontraktor dhe të vendosë nëse për të përdorur. Vendimet duhet të dokumentohen.

Furnizuesi duhet të vendosë se çfarë kontrolli mbi nënkontraktor ajo do të ketë. Standardi nuk përmend se sa kontrolli ju duhet të keni. Ajo vetëm përmend se një vendim duhet të bëhet duke përdorur fakte.

Një rast i veçantë është kur software është blerë me anë të shitjes me pakicë. Në këtë rast nënkontraktor është organizatë me të cilën është kryer blerja, nuk zhvilluesi origjinale e software.

Nëse blerja është bërë përmes ISO pakicë 9001 kërkon që ju të përcaktojë deri në çfarë mase ju vënë kërkesat në shitje me pakicë për të kontrolluar furnizuesit e saj.

6.3 Blerja e të dhënave

Kërkesat për proceset e zhvillimit duhet të dokumentohen në kontratë së bashku me kërkesat e furnizuesit të miratojë rezultatet e punës dhe procedurat.

6.4 Verifikimi i produktit të blerë

Dokumentimi i vendimeve në lidhje me verifikimin e secilit blerë mjet i zhvillimit apo produkt të përfshira.

– Nuk ka listë të furnizuesve të miratuara
– Kontrolli i papërshtatshëm i nënkontraktor
– Asnjë dokument verifikimi i artikujve të blerë
– Kontrata e papërshtatshme me nënkontraktor.

7 Kontrolli i Klientit-furnizuar Produkt

Furnizuesi duhet të ketë procedura për verifikimin, ruajtjen dhe mirëmbajtjen e klientit furnizuar software. Megjithatë, cilësia është përgjegjësi e softuerit.

Një jo-konformitetit ndodh për shkak të përgjegjësisë së paqartë të përgjegjësive në mes të klientit dhe furnizuesit.

8 Specifikimet e produktit dhe të Gjurmimi

Furnizuesi software duhet të mbajë nën kontroll në:
– Në çfarë paraprirë dokument dhe të nxjerrë atë është i bazuar
– Në cilën specifikimi ajo është e bazuar
– Çfarë korrigjimet dhe ndryshimet janë përfshirë në të cilat programet e burim
– Çfarë ka ndodhur me çdo raport problemit
– Nga ajo që burimi është gjeneruar një modul të veçantë.

Kontrolli 9 Procesi i

procedura të dokumentuara për procesin e replikimit në operimin dhe procedura për trajtimin e mjeshtrit Proma € ™ s / biblioteka. Për të siguruar që versioning saktë është përdorur.

– Nuk ka procedura të dokumentuara për përsëritje
– Trajtimi jo i duhur i mjeshtrit Proma € ™ s ose disk.

10 Inspektimi dhe Testimi

procedurat e shkruara për inspektimin dhe testimin për të bërë në lidhje me përsëritje.

– Funksioni i kontrolluar automatikisht Proma € ™ s nuk është inspektuar
– Nuk ka procedura të dokumentuara për testimin Proma € ™ s.

11 Kontrolli i Inspektimit, Matja dhe testimi

Furnizuesi duhet të zgjidhni pajisje të përshtatshme e matjes dhe të ndjekin një procedurë të dokumentuar për kontrollin e pajisjeve. Çdo version i ri software duhet të testohen për mjaftueshmërinë.

12 Inspektimi dhe Test Status

Specifikimet dhe programet duhet të verifikohet përmes komente dhe testimit. Furnizuesi duhet të ketë procedura që ndalojnë përdorimin e specifikimeve ose programeve të paverifikuara.

13 Kontrolli i jo-të përshtatshme Produktit

Produktet jo-të përshtatshme nuk duhet të përdoren pa qëllim. duhet të krijohet një procedurë për trajtimin ndryshime të shpejta në rast të gabimeve kritike.

– Identifikimi i qartë i artikujve të kontrolluar që përmbajnë gabime të pakorrigjuara
– Metoda për të nxjerrë pranimin e konsumatorëve mbi shpërndarjen
– Në rast të modifikimeve të shpejtë, ajo duhet të dokumentohet
– Shqyrtimin artikuj në mënyrë të modifikuar do të ngrihet në statusin njëjtë si pjesa tjetër e softuerit.

14 veprime korrigjuese dhe parandaluese

– Trajtimin efektiv të raporteve të cilat nuk janë në përputhje me kërkesat e
– Trajtimin efektiv të raporteve që tregojnë mangësive në procesin e zhvillimit
– Mbledhja dhe analizimi i informatave në dispozicion në lidhje me produktin dhe procesin e mos-përputhje dhe veprimet parandaluese Active.

Informacion në lidhje me problemet e hasura duhet të përzënë përmirësime të procesit të zhvillimit.

– Ankesa Customer nuk është trajtuar siç duhet
– Mangësi është gjetur, por nuk korrigjohen
– Nuk ka procedura për të siguruar që problemet janë analizuar dhe vepruar mbi
– Nuk ka procedura për raportimin vështirësi me aplikimin e rregullave dhe procedurave.

15 Trajtimi, Storage, Packaging, Ruajtja dhe dorëzimit

Zbatohet për software përsëriten në PROM, disk ose medium tjetër.
Media duhet të etiketohen dhe të paketuara në mënyrë korrekte. Të dhënat duhet të jenë të mbështetura. Nuk duhet të jetë aftësia për të siguruar mbrojtje nga dëmtimi paqëllimshme.

16 Kontrolli i Cilësisë Records

Dokumentet tregojnë cilësi të cilat janë ndërmarrë veprime për të siguruar ose të kontrolluar cilësinë. Standardi kërkon që të ketë një procedurë për trajtimin e të dhënave të cilësisë. Të dhënat duhet të ruhen në mënyrë të duhur në mënyrë që ata janë lehtësisht të arritshme.
– Nuk ka rregulla për ruajtjen e të dhënave të cilësisë
– Të rishikojë shënimet nuk mbahen
– Të dhënat e testit nuk mbahen
– Periudha e mbajtjes së të dhënave cilësore nuk është përcaktuar

Auditimet 17 Cilësia e brendshme

Nuk duhet të jetë një subjekt i pavarur që rregullisht kontrollon të gjitha operacionet që mund të ndikojnë në produkt apo shërbim të cilësisë. Këto janë kryer në emër të menaxhimit të kompanisë. Duhet të ketë një plan të auditimit.

– Nuk ka plan auditimi
– Plani i auditit të mos deri në datën

18 Training

Kompania duhet të sigurojë që personeli është trajnuar për detyrat e kërkuara. Një procedurë për:
– Identifikimi i nevojave për trajnim për secilën pozitë të stafit
– Ofrimi i trajnimeve të tilla
– Mbani shënime për trajnimin e të gjithë anëtarëve të stafit.

Trajnimi duhet të dokumentohet dhe të mjaftueshme. Me mjaftueshme ne do të thotë që personi të jetë në gjendje të kryejë punën e tij / saj për një standard të lartë të mjaftueshme.

– Nuk ka procedurat për planifikim ose trajnim
– Nuk ka të dhëna të trajnimit
– Nuk ka marrë trajnimin e duhur për detyrën e tij ose të saj.

19 Servicing

Furnizuesi duhet të ketë procedura të dokumentuara për servisin nëse kjo është përmendur në kontratë. Në software është rreth korrigjimeve të gabimit dhe përmirësimeve në software dorëzuar.

Procedurat për trajtimin e ankesave dhe kërkesave për ndryshime. Furnizuesi nuk është i detyruar të jap mbajtje në qoftë se ajo nuk është përmendur në kontratë. duhet të bëhen procedurat e mirëmbajtjes për softuer të vjetër.

– Mirëmbajtja e punës për një klient pa kontratë
– Metodat specifike për mirëmbajtjen e produktit të vjetër nuk është e dokumentuar
– Nuk ka procedura e testimit pas mirëmbajtje.

20 Teknikat statistikore

Nuk duhet të jetë mbledhja dhe analiza e të dhënave në lidhje me numrin e gabimeve që gjenden në faza të ndryshme. Informacion në lidhje me pamundësinë për të përmbushur afatet dhe piketa duhet të analizohet.

“————————————————– ————————————————– ————————————————–

ድጋፍ ትርጉም:
————————————————– ————————————————– ————————————————–
የ ISO 9001 ሃያ ጥራት አባሎች

አንድ መልክ ሶፍትዌር በማደግ ላይ ኩባንያዎች አመለካከት መስፈርቶች ላይ ይወሰዳል. የ ISO 9001 መደበኛ በማኑፋክቸሪንግ ኢንዱስትሪ የታሰበ ነበር. መስፈርቶችን የ ISO 9000-3 እና TickIT መሠረት ሶፍትዌር ልማት መተርጎም ነው.

20 ዋና ዋና ነገሮች አሉ. እያንዳንዱ ጽንሰ-ሐሳብ በሚገባ የጥራት ሥራ አመራር ማህበረሰብ ውስጥ የሚታወቅ ነገር የለም.

1. አስተዳደር ኃላፊነት

1.1 የጥራት መመሪያ

ወደ መደበኛ ይህ ኩባንያ ጥራት ምርቶች ለማምረት ይሆናል ይላል ቦታ የጥራት መመሪያ, ለመስጠት አቅራቢው አስተዳደር ይጠይቃል.

ጥራት መመሪያ ይሆናል:
– ጥራት ወደ managementâ € ™ s ቁርጠኝነት በይን
– ማለት ምን አስተዳደር ጥራት ላይ ማለት ነው, ጥራት በተመለከተ companyâ € ™ s ዓላማዎች በይን
– የ customerâ € ™ s ፍላጎት ተገቢ ሁን
– በድርጅቱ ውስጥ መረዳት ሁኑ
– ተግባራዊ መሆን

ያልሆነ conformances

– በጣም ግልጽ ያልሆነ ወይም የፖሊሲ መግለጫ ሰራተኞች የተረዱት ነው
– የጥራት መመሪያ አልተተገበረም ነው.

ለምሳሌ: ጥራት መመሪያ

€ œWe ያነሳሳው እና ችሎታ ያላቸው ሠራተኞች በኩል ጥራት, የተገለጹ የሥራ ሂደቶች, እና ከፍተኛ ግምገማ እና activities.â € ለመፈተን ማሳካት â

1.2 ድርጅት

መስፈርት ኃላፊነት, ሥልጣን እና ጥራት ላይ ተጽዕኖ ሁሉ ባለሙያዎችን interrelation ሰነዶችን ይፈልጋል. ይህ አንድ ሰው ኃላፊነት አለበት ከሆነ, ይህ በይፋ ተገቢውን አስተዳዳሪ የተመደበ ይሆናል ማለት ነው. ሰው ኃላፊነት ለመወጣት የሚያስችል ሥልጣን ሊኖረው ይገባል.

የ ISO መሠረት, ኃላፊነት ማለት ነው:

â ነገር toldâ € ሳይሆኑ መደረግ አለበት ጊዜ € œa ግዴታ oneâ € ™ s በራሱ ላይ እርምጃ ለመውሰድ.

ያልሆነ conformance

– ይፈጸም ዘንድ አይችልም አንድ ኃላፊነት አሁን.


– ፕሮጀክት-መስመር
– ፕሮጀክት-ደንበኛ
– ፕሮጀክት-ጥገና ድርጅት
– ሶፍትዌር ልማት-የሃርድዌር ልማት
– ጥገና ድርጅት-እገዛ ዴስክ
– ሽያጭ-ልማት

መርጃዎች አቅራቢው እንጠይቃለን:
– ሀብት ለማግኘት መስፈርት መለየት
– የሰለጠነ የሰው መድብ.

አስተዳደር ተወካይ ወደ ሥልጣን እና ኃላፊነት ጋር አስተዳዳሪ ተወካይ ቀጠሮ ያስፈልገዋል:
– ኩባንያው የ ISO 9001 ውስጥ መስፈርቶች ማሟላቱን ማረጋገጥ
– ኩባንያ አስተዳደር የጥራት ሥርዓት አፈጻጸም ሪፖርት

1.3 አስተዳደር ክለሳ

የጥራት አስተዳዳሪ በየጊዜው ውጤቶች ማቅረብ ይኖርባቸዋል
– ጥራት ኦዲቶች
– ጥራት ቅሬታዎች ስታትስቲክስ
– የማስተካከያ እርምጃ መረጃዎች

ውጤት የቀረበው ነበር ምን ውሳኔ ወስዶ ነበር ያደረገው ምን ላይ የተገኙ ላይ ማስታወሻዎችን, ጋር ተመዝግቦ አስተዳደር ስብሰባ ላይ መቅረብ ይኖርበታል.

2. ጥራት ስርዓት

የጥራት ሥርዓት ጥራት management.â € ተግባራዊ ለማድረግ € “”â € œthe ድርጅታዊ መዋቅር, ሃላፊነት, ሂደቶች, ሂደቶች እና ሀብቶች

ሂደቶች, መመሪያዎች, ውሳኔዎች በጽሑፍ ይገደል. አንድ ደንብ ወይም ISO 9001 በ አያስፈልግም ነው ሂደት ያላቸው ከሆነ, መደበኛ አሁንም ተብሎ እንደ ተጻፈ ይፈልጋል.

አንድ ጥራት መመሪያ ጥራት ሥርዓት ማጣቀሻ እና ሰነድ መያዝ አለበት.

ያልሆነ conformance

– አንድ ኦዲት በ ኦዲተር ብዙ ተጨማሪ ጥቃቅን ያልሆኑ conformances እንዳሉ እገምታለሁ ምክንያቱም አሁንም ያልሆነ-conformance ሊሆን ይችላል, የናሙና ውስጥ: በዚያ ጥቃቅን ያልሆኑ conformances ናቸው, እና ቋሚ ናቸው እንግዲህ ከሆነ, ናሙና ነው.
– ተጻፈ ነባር ሥርዓቶች ባለመከተላቸው ነው.

3. ኮንትራት ክለሳ

በመግባት ውል በፊት አቅራቢው ቼኮች ድርጅት ውሉን ያስፈልጋል ምን ማከናወን ይችሉ ዘንድ.

ሊጠየቁ ይገባል ጥያቄዎች ያካትታሉ:
– መስፈርቶችን ሰነዶች እና መረዳት ነው?
– ተቀባይነት መስፈርት ተካተዋል ነው?
– የጨረታ ጀምሮ የተለያዩ መስፈርቶች መፍትሔ ያውቃሉ?
– አቅራቢው ውሉን በቂ ሀብት እንደምንም የምችለው እንዴት ነው?
– አቅራቢው ውሉን የሚያስፈልገውን ብቃት እንደምንም የምችለው እንዴት ነው?
– ሥራ ጊዜ ውስጥ ይጠናቀቃል የምችለው እንዴት ነው?

መስፈርት ግምገማዎች ጋር በሰነድ አሰራር መካተት ይፈልጋል. አቅራቢው የኮንትራት ማሻሻያ እና የደንበኛ እና አቅራቢዎች መካከል መስፈርቶች ዝርዝር ውስጥ አያያዝ የማይተረጎሙ እንዴት መለየት አለበት.

4. ንድፍ ቁጥጥር

4.1. ጠቅላላ
የ ISO እያደረጉ በፊት እቅድ መንደፍ በፊት መግለጽ ይጠይቃል.

4.2. ዲዛይንና ልማት ዕቅድ

ንድፍ ዕቅድ መያዝ አለበት:
– ዘዴን ፍቺ ምርት ልማት ላይ ጥቅም ላይ እንዲውል
– የጊዜ መርሐግብር, ሃላፊነት, የስራ ምድብ እና እድገት ቁጥጥር
– ደረጃዎች ፕሮጀክት ይከፈላል. ይህ ግቤት, ውጽዓት እና ውጤት ማረጋገጫ ያካትታል.
– ዘዴዎች እና መሳሪያዎች መግለጫ ጥቅም ላይ እንዲውል

ጥራት ዕቅድ መያዝ አለበት:
– የጥራት ዒላማዎች
– ተቀባይነት ለማግኘት መስፈርት
– ምጣኔ, ማረጋገጫ እና የማረጋገጫ መለየት.
– ጥራት እንቅስቃሴዎች ኃላፊነት.

አንድ ኩባንያ ኦ ማረጋገጫ የተወሰኑ ፕሮጀክቶች ሁሉ ኩባንያ ነው እንጂ ጀምሮ, ፕላን በሁሉም ፕሮጀክቶች ላይ ይካሄዳል አለበት ISO ብቃት ለማግኘት የሚፈልግ ከሆነ.

4.3 ድርጅታዊ እና የቴክኒክ በየነገጾች

ቡድን-ሥራ የለም ከሆነ, በእነሱ መካከል በይነ, ተለይተው መረጃ የሚያስፈልጋቸው ሰዎች በሰነድ እና ሊተላለፍ ይገባል. ወደ ሰነድ በየጊዜው ይገመገማል ይሆናል.

4.4 ንድፍ ግቤት

መስፈርቶች መግለጫዎች ሶፍትዌር ልማት ንድፍ ግብዓት ይዘዋል. ይህም በገዢው የሚደረገው ወይም ህጎች እና ደንቦች በመጠቀም አቅራቢው ዝግጁ ሊሆን ይችላል. ሌላው ንድፍ ግቤት ኮድ ላይ እንደ ግብዓት የሚያገለግል ነው ንድፍ ኮድ ያካትታል.

መደበኛ እያንዳንዱን እርምጃ ሥራ ውጤት መስፈርቶች የሚያሟላ መሆኑን ለማረጋገጥ ይፈልጋል.

ሶፍትዌር ልማት, መስፈርት ለውጦች እንዲሁ በገዢው አዲስ እና ለውጥ መስፈርቶች አያያዝ ስርአት መፍጠር የተለመደ ነው.

4.5 ንድፍ ውፅዓት

ንድፍ ውፅዓት: ንድፍ ሰነድ እና ምንጭ ኮድ. የ ISO ንድፍ ሰነዶች እና ከእስር በፊት ሊገመገሙ ኮድ ይጠይቃል.

ንድፍ ውፅዓት ተቀባይነት መስፈርት ተቀባይነት ያለው አሠራር ሊፈጠር ይገባል.

4.6 ንድፍ ክለሳ

ኮድ እና ለሙከራ እንደ የፕሮጀክት ተግባራት ናቸው ግምገማ ላይ የሚቀርበውን ይሆናል. ግምገማዎችን ለማረጋገጥ አንድ የተለመደ ዘዴ እንደማመሳከሪያ ናቸው.

4.7 ንድፍ ማረጋገጫ

ይህ ግምገማዎች, ሞጁል ምርመራ እና ለውህደት ሙከራ ያካትታል.

4.8 ንድፍ ማረጋገጥ

ተጠቃሚ ሰነዱ ላይ መገምገም ጋር አብረው የተሟላ የሶፍትዌር ምርት የመጨረሻ ሥርዓት ፈተና,. አለ ዕቅድ እና ማረጋገጫ መመዝገብ አለበት. ይሁንታ ሙከራ እስካለ ድረስ ይሁንታ ሙከራ አቅራቢዎች እና የቅድመ-ይሁንታ-የሙከራ ደንበኛ መካከል ግልጽ የሆነ ስምምነት የተሸፈነ ነው እንደ ISO መሠረት ነው ነው.

4.9 ንድፍ ለውጦች

የ ISO 9001 ንድፍ ሰነድ ወይም ምንጭ መለቀቅ በኋላ, ሁሉም ለውጦች ለውጦች, ሰነዶች ይገመገማሉ እና ትግበራ ፊት ተቀባይነት ቦታ መደበኛ ሂደት ውስጥ ማለፍ አለበት ይጠይቃል.

ውስብስብ የቴክኒክ ሰነዶች ወይም ፕሮግራሞች ከቁጥጥር ለውጦች በጣም አደገኛ ነው እና እንደ መስፈርት አድርጎ አይፈቅድም.
5. ሰነድ እና ውሂብ ቁጥጥር

ሶፍትዌር ልማት / የጥገና ይቆጣጠራል መረጃ. መስፈርት አንዳንድ ሰነድ የሚያስፈልጋቸውን ሰዎች / ውሂብ የእሱ መዳረሻ ይሆናል አላቸው ይጠይቃል. ሰነዶች እና ውሂብ ላይ የተደረጉ ለውጦች በቁጥጥር ይሆናል.

5.1 አጠቃላይ

ውጫዊ ሰነዶች እና ውሂብ መቀመጥ አለበት. በማንኛውም መልክ (የደረቅ ቅጂ, የኤሌክትሮኒክ ሚዲያ) ላይ ሊቀመጥ ይችላል.

5.2 ሰነድ እና ውሂብ ማፅደቂያ እና እትም

ችግር ሰነዶች እና ውሂብ በፊት ተገምግሟል ይሆናል እያንዳንዱ እትም በፊት ጸድቋል. አንድ ሰነድ ዝርዝር ውስጥ አንድ ሰው አንድ ሰነድ የአሁኑ ስሪት ውጭ ታገኛላችሁ. ልክ ያልሆነ ወይም ያለፈበት ሰነዶችን ሊወገድ ወይም በግልጽ ምልክት ሊደረግባቸው ይገባል.

5.3 ሰነድ እና ውሂብ ለውጦች

ግምገማው እና ሞገስ ሂደት ኃላፊ ሰው / ዎች መገለጽ አለበት.

6. የግዥ

subcontractor ሁኔታ ውስጥ, አሁንም ኃላፊነት አለባቸው. ማለትም አንድ ውል አረጋግጦ ሥራ ለማስጀመር እና ሥራ በሰብ ከሆነ, ISO የአቋም በእርስዎ ኃላፊነት ሥር አሁንም እና ISO መስፈርቶች በ subcontractor ላይ የሚጣሉ መሆን የለብዎትም.

6.1 አጠቃላይ

የሰው መግዛት ነው ከሆነ, መደበኛ ከትክክለኛ ሰዎች ለማግኘት አንድ አሰራር መከተል ይፈልጋል. ሰዎች አቅራቢ ሳይሆን subcontractor ቁጥጥር ይደረጋል.
ይህ የተገዛ ሶፍትዌር ለማረጋገጥ መስፈርቶች ጋር በሚስማማ:
– ተቋራጩ ሂደቶች ላይ ውሌ መስፈርቶች
– የ subcontractor ጥራት ሥርዓት ኦዲት
– አፈጻጸም ያለፈው ፈትሽ subcontractor
– ውል ወቅት subcontractor ጥናት
– የይሖዋ ምሥክር ግምገማ እና ምርመራ
– ፈተና እና subcontractor ግምገማ ውጤት.

ንዐስ 6.2 ግምገማ

አስፈላጊ ሥልጣን እና ብቃት ጋር ሰው እያንዳንዱ subcontractor ሊፈርድ እና ለመጠቀም መወሰን አለበት. ውሳኔ በሰነድ ይሆናል.

አቅራቢው ይኖረናል subcontractor ላይ ምን ዓይነት ቁጥጥር ይወስናል. ወደ መደበኛ እርስዎ ይገባል ምን ያህል ቁጥጥር መጥቀስ ነው. ይህ ብቻ ውሳኔ እውነታዎች በመጠቀም መደረግ እንዳለበት ይጠቅሳል.

ሶፍትዌር በችርቻሮ በኩል የተገዙ ጊዜ አንድ ልዩ ሁኔታ ነው. በዚህ ሁኔታ subcontractor ውስጥ ግዢ ይካሄዳል ይህም ጋር ድርጅት, ሶፍትዌር አይደለም የመጀመሪያው ገንቢ ነው.

ግዢ የችርቻሮ የ ISO በኩል ነው የሚደረገው ከሆነ 9001 ምን ያህል እርስዎ በውስጡ አቅራቢዎች ለመቆጣጠር ቸርቻሪው ላይ መስፈርቶች ማስቀደም መግለጽ ይጠይቃል.

6.3 የግዥ ውሂብ

የልማት ሂደት ላይ መስፈርቶች የሥራ ውጤቶች እና ሂደቶችን ለማጽደቅ አቅራቢዎች መስፈርቶች ጋር ውል ውስጥ መመዝገብ አለበት.

የተገዙ ምርት 6.4 ማረጋገጫ

እያንዳንዱ የማረጋገጫ በተመለከተ ውሳኔ ሰነድ ልማት መሣሪያ ወይም የተካተቱ ምርት መግዛት.
ያልሆነ conformance

– ተቀባይነት አቅራቢዎች ምንም ዝርዝር
– Subcontractor ላይ ተገቢ ያልሆነ ቁጥጥር
– የተገዙ ንጥሎች ምንም ሰነድ ማረጋገጫ
– Subcontractor ጋር ተገቢ ያልሆነ ውል.

የደንበኛ-የቀረበው ምርት 7 መቆጣጠር

አቅራቢው ማረጋገጫ, ማከማቻ እና የደንበኛ ማስገኘት ሶፍትዌር ጥገና አሠራር አላቸው. ይሁን እንጂ ጥራት ሶፍትዌር ኃላፊነት ነው.

አንድ ያልሆኑ conformance ምክንያት የደንበኛ እና አቅራቢዎች መካከል ኃላፊነት ግልጽ ያልሆኑ ኃላፊነት ምን ይሆናል.

8 የምርት ዝርዝር እና Traceability

ሶፍትዌሩ አቅራቢ ላይ ቁጥጥር ጠብቁ:
– ሰነድ ቀደም ባለው እና ሊያወጣ በምን ላይ የተመሠረተ ነው
– ይህም ዝርዝር ላይ የተመሠረተ ነው
– ምን እርማቶች እና ማሻሻያዎች ይህም ምንጭ ፕሮግራሞች ውስጥ እንዲካተት ተደርጓል
– ለእያንዳንዱ ችግር ሪፖርት ምን ደረሰበት
– ምን ምንጭ አንስቶ እስከ አንድ የተወሰነ ሞዱል የመነጨ ነበር.

9 ሂደት ቁጥጥር

ዋና PROMâ € ™ s / ቤተ አያያዝ አሠራር እና ሥነ ሥርዓት ላይ መባዛት ሂደት አሠራር በሰነድ. ትክክለኛ ስሪት መስጠት ጥቅም ላይ መሆኑን ማረጋገጥ.

ያልሆነ conformance
– መባዛት ምንም በሰነድ ቅደም ተከተል
– ዋና PROMâ € ™ s ወይም diskettes ተገቢ ያልሆነ አያያዝ.

10 ኢንስፔክሽን እና ሙከራ

ፍተሻው እና ለሙከራ ተጻፈ ሂደቶች መባዛት ጋር በተያያዘ መደረግ አለበት.

ያልሆነ conformance
– በራስ-ሰር PROMâ € ™ s በመፈተሽ ላይ ተግባር ለመመርመር አልተደረገም
– ምንም PROMâ € ™ ን ለመሞከር አሠራር በሰነድ.

የምርመራው, መለካት እና የሙከራ ዕቃዎች 11 መቆጣጠር

አቅራቢው ተገቢውን የመለኪያ መሣሪያዎችን መምረጥ እና መሳሪያዎችን ለመቆጣጠር የተመዘገበ አሰራር መከተል አለባቸው. እያንዳንዱ አዲስ የሶፍትዌር ስሪት ብቃትን መመርመር አለባቸው.

12 ምርመራ እና የሙከራ ሁኔታ

መግለጫዎች እና ፕሮግራሞች ግምገማዎችን እና ለሙከራ በኩል ሊረጋገጥ ይገባል. አቅራቢው ያልተረጋገጠ ዝርዝር ወይም ፕሮግራሞች መጠቀም ቢከለክሉም አሠራር አላቸው.

ያልሆኑ አለመጣጣም ምርት 13 መቆጣጠር

ያልሆነ በመኖራችን ምርቶች ባለማወቅ ጥቅም ላይ መዋል የለበትም. ወሳኝ ስህተቶች ጉዳይ ላይ ፈጣን ማሻሻያዎችን አያያዝ አንድ አሠራር ሊፈጠር ይገባል.

– አቅቶት ስህተቶችን የያዙ ቁጥጥር ንጥሎች አጽዳ መለያ
– ስልት አሰጣጥ ላይ የደንበኛ ተቀባይነት መፈናፈኛ
– ፈጣን ማሻሻያዎችን ሁኔታ ውስጥ, በሰነድ አለበት
– ስለዚህ የተቀየረ ንጥሎችን መገምገም ሶፍትዌር እንደ ሌሎቹ ተመሳሳይ ሁኔታ ከፍ ይደረጋል.

14 አስተካካይ እና የመከላከያ እርምጃ

– መሥፈርቶች ጋር ተስማምቶ አይደለም ሪፖርቶች ውጤታማ አያያዝ
– በልማት ሂደት ውስጥ ለአጭር ጊዜ ስለመምጣቱ የሚጠቁሙ ሪፖርቶች ውጤታማ አያያዝ
– ገባሪ ስብስብ እና ምርት እና ሂደት ያልሆኑ conformance እና የመከላከያ እርምጃዎች በተመለከተ የሚገኝ መረጃ መተንተን.

የልማት ሂደት ማሻሻያዎችን መንዳት አለበት አጋጥሞታል ችግሮች መረጃ.

ያልሆነ conformance
– የደንበኞች ቅሬታ በአግባቡ አልተደረገም
– ጉድለት አልተገኘም ነገር ግን ማስተካከያ ተደርጓል
– ምንም ሂደት ለማረጋገጥ ችግሮች የተተነተነ እና እየተከወኑ መሆናቸውን
– ደንቦች እና ሂደቶች ተግባራዊ ጋር ችግር ሪፖርት ምንም አሠራር.

15 አያያዝ, ማከማቻ, ማሸግ, የማቆያ እና መላኪያ

ፕሮም, ዲስክ ወይም ሌላ መካከለኛ ላይ የመስፋፋት ሶፍትዌር ይሠራል.
ሚዲያ የተለጠፈባቸው በትክክል መታሸግ አለበት. ውሂብ ምትኬ ይሆናል. ሆን ብሎ ጉዳት ጥበቃ የመስጠት ችሎታ መኖር አለበት.

የጥራት መዛግብት 16 መቆጣጠር

የጥራት ሰነዶች እርምጃዎች ለማረጋገጥ ወይም ጥራትን ለማረጋገጥ መወሰድ ከተደረጉ ያሳያሉ. መደበኛ ጥራት መረጃዎች አያያዝ ስርአት አለ እንዲሆን ይፈልጋል. በቀላሉ ተደራሽ ናቸው እንዲሁ መዝገቦች በተገቢው መንገድ መቀመጥ አለበት.
ያልሆነ conformances:
– ጥራት መረጃዎች ማቆየት ምንም ደንቦች
– ግምገማ መረጃዎች ተጠብቀው አይደለም
– የሙከራ መዛግብት ተጠብቀው አይደለም
– ጥራት መዛግብት መጠበቅ ክፍለ ጊዜ ፍቺ አይደለም

17 የውስጥ ጥራት ኦዲት

በየጊዜው ምርት ወይም አገልግሎት ጥራት ላይ ተጽዕኖ ሊኖረው ይችላል ሁሉ ክወናዎች ኦዲቶች ይህ ራሱን የቻለ አካል መኖር አለበት. እነዚህ ኩባንያ አስተዳደር በመወከል በማስተማር ነው. አንድ የኦዲት ዕቅድ አለ መሆን አለበት.

ያልሆነ conformance
– ምንም ኦዲት ዕቅድ
– አይደለም ወቅታዊ ኦዲት ዕቅድ

18 ስልጠና

ይህ ሠራተኞች ማረጋገጥ አለባቸው ኩባንያ ያስፈልጋል ተግባራት ሥልጠና ነው. አንድ ሂደት:
– እያንዳንዱ ሰራተኞች ቦታ ስልጠና ፍላጎት መለየት
– እንዲህ ዓይነት ሥልጠና መስጠት,
– ሁሉም ሰራተኞች አባላት ሥልጠና መዛግብት ያስቀምጡ.

ስልጠና በሰነድ እና በቂ መሆን አለበት. በቂ እኛ ሰው ከፍተኛ በቂ መለኪያ / ዋ ሥራ የሚሠራ የሚችል መሆን ማለት ነው.

ያልሆነ conformance
– እቅድ ወይም ስልጠና ምንም ሂደቶች
– ምንም ሥልጠና የለም መዛግብት
– እሱ ወይም እሷ ሥራ ተገቢውን ሥልጠና ተሰጥቷቸዋል አይደለም.

19 በመጠገን

አቅራቢው በዚህ ውል ውስጥ የተጠቀሱት ከሆነ ለማገልገል ሂደቶች በሰነድ ሊሆን ይሆናል. ሶፍትዌር ውስጥ የስህተት እርማቶች እና ነፃ ሶፍትዌር ላይ ማሻሻያዎች ነው.

ማሻሻያዎች ለ ቅሬታዎች እና ጥያቄዎች አያያዝ ሂደቶች. አቅራቢው ውል ውስጥ የተጠቀሰው አይደለም ከሆነ ጥገና ለማቅረብ አይገደድም. የቆየ ሶፍትዌር ጥገና ቅደም መደረግ አለበት.

ያልሆነ conformance
– ውል ያለ አንድ ደንበኛ ጥገና ሥራ
– የድሮ ምርት ጥገና የተወሰኑ ዘዴዎች በሰነድ አይደለም
– ጥገና በኋላ ለሙከራ ምንም አሠራር.

20 ስታስቲክስ ቴክኒኮች

ስብስብ እና በተለያዩ ደረጃዎች ውስጥ የሚገኙ ስህተቶች ቁጥር ስለ ውሂብ ትንተና መሆን የለባቸውም. የጊዜ ገደብና ወደ ደረጃዎቹን ማሟላት አለመቻል መረጃ መተንተን አለበት.

“————————————————– ————————————————– ————————————————–

ترجمة الدعم:
————————————————– ————————————————– ————————————————–
ISO 9001 عشرون عناصر الجودة

سيتم اتخاذ نظرة على متطلبات من وجهة نظر الشركات تطوير البرمجيات. وكان القصد ISO 9001 لصناعة و. يتم تفسير متطلبات تطوير البرمجيات وفقا ISO 9000-3 وTickIT.

هناك 20 العناصر الرئيسية. كل مفهوم معروف في المجتمع إدارة الجودة.

المسؤولية 1. إدارة

1.1 سياسة الجودة

يتطلب معيار إدارة المورد لإصدار سياسة الجودة، حيث تقول يجب أن تنتج الشركة منتجات ذات جودة عالية.

سياسة الجودة بما يلي:
– لتحديد managementâ € ™ ق الالتزام بالجودة
– تحديد أهداف الشركة إلى € ™ ق بشأن جودة، وهذا هو، ما يعني إدارة بالجودة
– كن صلة customerâ € ™ ق الاحتياجات
– أن يفهم في المنظمة
– أن تنفذ

غير conformances-

– بيان مبهم أو السياسة أيضا ليست مفهومة من قبل الموظفين
– لم يتم تنفيذ سياسة الجودة.

مثلا سياسة الجودة

â € œWe تحقيق الجودة من خلال حفز الموظفين والعمال المهرة، وإجراءات العمل المحددة، ومراجعة مكثفة واختبار activities.â €

1.2 منظمة

يتطلب معيار التوثيق من المسؤولية والسلطة والترابط بين جميع أفراد تؤثر على نوعية. هذا يعني أنه إذا كان الشخص لديه المسؤولية، ولا يكلف رسميا من قبل مدير المناسب. يجب أن يكون الشخص على السلطة لتحقيق المسؤولية.

وفقا للايزو والمسؤولية تعني:

â € اجب أويا للعمل على oneâ € ™ ق تلقاء نفسه عندما ما ينبغي القيام به دون أن toldâ € شيء.

غير مطابقة

– القائمة على المسؤولية التي لا يمكن الوفاء بها.


– خط مشروع
– مشروع على العملاء
– تنظيم الصيانة مشروع
– تطوير البرمجيات تطوير الأجهزة
– مكاتب الصيانة منظمة مساعدة
– إنماء المبيعات

تتطلب موارد أن المورد:
– تحديد الاحتياجات من الموارد
– تعيين الموظفين المدربين.

يتطلب ممثل الإدارة تعيين ممثل مدير مع السلطة والمسؤولية إلى:
– التأكد من أن الشركة تلبي متطلبات في 9001
– عن أداء نظام الجودة لإدارة الشركة

1.3 المراجعة الادارية

مدير الجودة أن يقدم دوريا نتائج
– تدقيق الجودة
– الاحصائيات الشكاوى جودة
– سجلات الإجراءات التصحيحية

وينبغي تقديم النتائج في اجتماع إدارة تسجيلها مع الملاحظات على الذين حضروا، ما قدمت وما قرارات اتخذت وقدم.

2. نظام الجودة

نظام الجودة â € “”â € œthe الهيكل التنظيمي والمسؤوليات والإجراءات والعمليات والموارد اللازمة لتنفيذ الجودة management.â €

الإجراءات والقواعد، توضع القرارات في الكتابة. إذا كان لديك قاعدة أو إجراء غير مطلوب من قبل ISO 9001، والمعيار لا يزال يحتاج إلى ما هو مكتوب فيه.

يجب أن يتضمن دليل الجودة إشارة وتوثيق نظام الجودة.

غير مطابقة

– التدقيق هي عينة، لذلك إذا كان في عينة، وهناك غير conformances-طفيفة، وأنها ثابتة، يمكن أن يكون لا يزال غير المطابقة لمدقق الحسابات يمكن أن تظن أن هناك العديد من طفيفة غير conformances.
– لا يتم الالتزام إجراءات مكتوبة القائمة ل.

مراجعة 3. عقد

الشيكات المورد قبل توقيع العقد أن المنظمة تكون قادرة على أداء ما هو مطلوب بموجب العقد.

الأسئلة التي ينبغي أن يطلب ما يلي:
– هل متطلبات موثقة ومفهومة؟
– هل معايير القبول شملت؟
– لديها متطلبات مختلفة من العطاء تم حلها؟
– هل المورد حشد ما يكفي من الموارد للحصول على العقد؟
– هل المورد حشد الكفاءة المطلوبة للحصول على العقد؟
– يمكن الانتهاء من المهمة في الوقت المناسب؟

يتطلب المعيار الذي يتم تضمين إجراءات موثقة مع الاستعراضات. المورد ينبغي أن تحدد كيف يمكن تعريف إدخال تعديلات على العقود والتعامل مع متطلبات المواصفات بين العملاء والموردين.

4. مراقبة التصميم

4.1. جنرال لواء
يتطلب ISO التي تخطط قبل القيام وتحديد قبل تصميم.

4.2. تصميم وتخطيط التنموي

وينبغي أن تتضمن خطة التصميم:
– تعريف المنهجية التي سيتم استخدامها في تطوير المنتج
– الجداول الزمنية والمسؤوليات ومهام العمل ومراقبة التقدم
– سيتم تقسيم المشروع مراحل. وهذا يشمل المدخلات والمخرجات والتحقق من الانتاج.
– وصف الأساليب والأدوات التي تستخدم

وينبغي أن تتضمن خطة الجودة:
– أهداف الجودة
– معايير القبول
– تحديد التخطيط والمصادقة والتحقق.
– المسؤوليات لأنشطة الجودة.

إذا كانت الشركة تريد الحصول على المؤهل ISO يجب أن تعقد خطط في جميع المشاريع، منذ شهادة ISO هي للشركة بأكملها وليس لمشاريع محددة.

4.3 واجهات التنظيمية والفنية

إذا كان هناك مجموعة العمل، وينبغي تحديد الواجهات بينهما وتوثيقها ونقلها إلى أولئك الذين يحتاجون المعلومات. ويعاد النظر في وثائق بانتظام.

4.4 تصميم المدخلات

متطلبات المواصفات تحتوي على مدخلات التصميم في مجال تطوير البرمجيات. ويمكن القيام بذلك من قبل المشتري أو من قبل المورد باستخدام القوانين واللوائح التي أعدت. يتضمن إدخال آخر تصميم الترميز التصميم الذي يستخدم كمدخل إلى الترميز.

المعيار يريد ضمان أن المنتج عمل كل خطوة يلبي المتطلبات.

في مجال تطوير البرمجيات، والتغيرات شرط شائعة لدرجة أن إنشاء إجراء للتعامل مع المتطلبات الجديدة والمتغيرة من المشتري.

4.5 تصميم الناتج

تصميم الإخراج: وثائق التصميم وشفرة المصدر. يتطلب ISO وثائق التصميم والترميز إعادة النظر قبل الافراج عنهم.

يجب إنشاء إجراء لقبول إخراج تصميم ومعايير القبول.

4.6 مراجعة التصميم

يتم تقديم وظائف المشروع مثل الترميز والاختبار في الاستعراض. وهناك طريقة شائعة لضمان الاستعراضات وقوائم المراجعة.

4.7 تصميم التأكيد

وهذا يتكون من الاستعراضات واختبار وحدة واختبار التكامل.

4.8 تصميم التحقق من صحة

الاختبار النهائي نظام، من منتج البرنامج الكامل مع مراجعة وثائق المستخدم. ينبغي أن يكون هناك مخطط وموثقة التحقق من الصحة. اختبار بيتا هو في التوافق مع ISO طالما يتم تغطية اختبار بيتا من اتفاق واضح بين المورد وبيتا اختبار العملاء.

4.9 التغييرات التصميم

ISO 9001 يتطلب أن بعد الافراج عن وثائق التصميم أو المصدر، جميع التغييرات يجب أن تذهب من خلال عملية رسمية حيث يتم توثيق التغييرات، مراجعتها والموافقة عليها قبل تنفيذها.

التغييرات غير المنضبط على المستندات أو البرامج التقنية المعقدة خطيرة للغاية وعلى هذا النحو معيار لا تسمح بذلك.
5. توثيق ومراقبة البيانات

المعلومات التي تسيطر على تنمية / صيانة البرمجيات. يتطلب المعيار أن أولئك الذين بحاجة الى بعض ثيقة / يكون الوصول إلى البيانات إليها. يتم التحكم التغييرات على المستندات والبيانات.

5.1 العامة

يجب تخزين الوثائق والبيانات الخارجية. ويمكن تخزينها على أي شكل (نسخة ورقية، وسائل الإعلام الإلكترونية).

5.2 الوثيقة والموافقة البيانات والعدد

قبل وثائق القضية والبيانات يتم مراجعتها والموافقة عليها قبل كل قضية. قائمة الوثيقة التي لا يجوز لأحد معرفة الإصدار الحالي من المستند. يجب إزالة وثائق غير صحيحة أو بالية أو وضع علامات واضحة.

5.3 الوثيقة وتغييرات البيانات

يجب تحديد شخص / ق المسؤول عن عملية المراجعة والموافقة عليها.

6. المشتريات

في حالة الباطن، وأنت لا تزال مسؤولة. أي. إذا كنت التقدم بطلب للحصول على العقد والتعاقد من الباطن العمل، ومعايير ISO لا تزال تحت مسؤوليتك ومتطلبات ISO لا يجب أن تفرض على المقاول من الباطن.

6.1 العامة

إذا تم شراؤها من القوى العاملة، والمعيار يتطلب منك اتباع الإجراء أن تحصل على الأشخاص المناسبين. وسوف تسيطر على الناس من قبل المورد وليس من الباطن.
للتأكد من أن البرنامج الذي تم شراؤه يتوافق مع متطلبات:
– متطلبات العقد على إجراءات الباطن
– مراجعة نظام الجودة الباطن
– التحقق من الباطن الأداء السابق
– مسح الباطن خلال عقد
– مراجعة الشهود واختبار
– اختبار والمنتج مراجعة الباطن.

6.2 تقييم من الباطن

يجب شخص مع السلطة والكفاءة اللازمة يحكم كل من الباطن ويقرر ما إذا كان استخدام. يجب توثيق القرارات.

يلتزم المورد يقرر ما السيطرة على الباطن سيكون لديها. لا يذكر المعيار مدى السيطرة التي ينبغي أن يكون. ويذكر فقط أن القرار يجب أن تتم باستخدام الحقائق.

وهناك حالة خاصة هي عندما يتم شراء البرنامج من خلال التجزئة. في هذه الحالة الباطن هو المنظمة التي يجري شراء، وليس المطور الأصلي للبرمجيات.

إذا تم الشراء من خلال ISO التجزئة 9001 يتطلب أن تحدد إلى أي مدى يمكنك وضع شروط على متاجر التجزئة للسيطرة على موردها.

6.3 بيانات المشتريات

يجب أن تكون موثقة شروطا على عملية التنمية في العقد مع متطلبات المورد للموافقة على النتائج وإجراءات العمل.

6.4 التحقق من صحة شراؤها المنتج

وثائق من القرارات بشأن التحقق من كل اشترت أداة للتنمية أو منتج المدرجة.
غير مطابقة

– لا قائمة الموردين المعتمدين
– مراقبة غير لائقة من الباطن
– لا تحقق ثيقة من وثائق البنود التي تم شراؤها
– عقد غير لائق مع الباطن.

7 مراقبة التي يتم توفيرها من العملاء المنتج

يلتزم المورد لديها إجراءات التحقق والتخزين والحفاظ على تزويد العملاء البرمجيات. ومع ذلك، فإن الجودة هي مسؤولية البرنامج.

وغير المطابقة يحدث نتيجة لمسؤولية واضحة للمسؤولية بين العملاء والموردين.

8 مواصفات المنتج والتتبع

المورد البرمجيات يجب أن تبقي سيطرة على:
– على ما سبقت وثيقة وإصدار أنه يقوم
– على أي مواصفات لأنه يقوم
– ما التصحيحات والتعديلات التي تم تضمينها في البرامج التي المصدر
– ماذا حدث كل تقرير المشكلة
– من خلال ما المصدر ان وحدة نمطية محددة ولدت.

مراقبة 9 عملية

توثيق إجراءات عملية النسخ المتماثل في عملية وإجراءات التعامل مع سيد PROMA € ™ ق / المكتبات. لضمان أن يتم استخدام الإصدارات الصحيح.

غير مطابقة
– لا إجراءات موثقة للنسخ المتماثل
– التعامل غير السليم للسيد PROMA € ™ ق أو الأقراص.

10 التفتيش والاختبار

إجراءات مكتوبة لفحص واختبار الذي يتعين القيام به في اتصال مع النسخ المتماثل.

غير مطابقة
– لم تفقد وظيفة للتحقق تلقائيا PROMA € ™ ق
– لا موثقة الإجراء لاختبار PROMA € ™ ق.

11 مراقبة التفتيش، ومعدات القياس والاختبار

المورد يجب اختيار معدات القياس المناسبة ومتابعة إجراءات موثقة من أجل السيطرة على المعدات. يجب اختبار كل إصدار برنامج جديد لتحقيق الاكتفاء.

12 التفتيش واختبار الحالة

المواصفات والبرامج ينبغي التحقق من خلال استعراض واختبار. يلتزم المورد يكون الإجراءات التي تحظر استخدام المواصفات أو البرامج لم يتم التحقق منها.

13 مراقبة غير مطابقة للمواصفات المنتج

لا ينبغي أن تستخدم منتجات غير مطابقة للمواصفات عن غير قصد. يجب إنشاء إجراء للتعامل مع تعديلات سريعة في حالة وجود أخطاء حرجة.

– تحديد واضح من المواد الخاضعة للرقابة التي تحتوي على أخطاء غير المصححة
– طريقة لتثير قبول العملاء عند تسليم
– في حالة وجود تعديلات سريعة، فإنه يجب أن تكون موثقة
– مناقشة بنود ذلك المعدلة سوف تكون مرتفعة للنفس وضعية بقية البرامج.

14 الإجراءات التصحيحية والوقائية

– التعامل الفعال للتقارير التي لا تتوافق مع متطلبات
– التعامل الفعال للتقارير تشير-النواقص في عملية التنمية
– جمع وتحليل المعلومات المتوفرة حول المنتج وعملية عدم المطابقة والإجراءات الوقائية نشط.

معلومات عن المشاكل التي ينبغي أن تقود التحسينات في عملية التنمية.

غير مطابقة
– لم يتم التعامل مع شكوى العملاء بشكل صحيح
– وقد وجد نقص ولكن ليس تصحيح
– لا إجراءات لضمان أن يتم تحليل المشكلات واتخاذ إجراءات بشأنها
– لا إجراءات صعوبات في تطبيق قواعد وإجراءات تقديم التقارير.

15 المناولة والتخزين والتغليف والحفظ وتسليم

ينطبق على البرامج تكرارها على حفلة موسيقية، والقرص أو وسيلة أخرى.
يجب أن يكون المسمى وسائل الإعلام وتعبئتها بشكل صحيح. يجب أن البيانات احتياطيا. يجب أن يكون هناك أيضا القدرة على توفير الحماية من الضرر غير مقصود.

16 مراقبة سجلات الجودة

وتظهر وثائق الجودة التي اتخذت إجراءات لضمان أو التحقق من جودة. يتطلب المعيار أن يكون هناك إجراء لمعالجة سجلات الجودة. يجب أن يتم تخزين السجلات بطريقة مناسبة بحيث يمكن الوصول إليها بسهولة.
غير conformances:
– لا توجد قواعد لاستبقاء سجلات الجودة
– لا يتم الاحتفاظ بسجلات مراجعة
– لا يتم الاحتفاظ بسجلات اختبار
– لم يتم تعريف الفترة من حفظ سجلات الجودة

التدقيق 17 الجودة الداخلية

يجب أن يكون هناك كيان مستقل أن تدقق بانتظام جميع العمليات التي قد تؤثر على المنتج أو جودة الخدمة. وتجرى هذه نيابة عن إدارة الشركة. يجب أن تكون هناك خطة التدقيق.

غير مطابقة
– لا خطة التدقيق
– خطة التدقيق لم يصل حتى الآن

18 التدريب

يتم تدريب الشركة يجب التأكد من أن الموظفين للمهام المطلوبة. إجراء ما يلي:
– تحديد الاحتياجات التدريبية لكل موقف الموظفين
– توفير مثل هذا التدريب
– الاحتفاظ بسجلات لتدريب جميع الموظفين.

يجب توثيق التدريب وكافية. بواسطة كافية نعني أن يكون الشخص قادرا على أداء له / لها العمل على مستوى عال بما فيه الكفاية.

غير مطابقة
– لا إجراءات التخطيط أو التدريب
– لا سجلات التدريب
– لا تلقى التدريب المناسب لمهمته.

19 خدمات

يجب المورد وإجراءات موثقة لخدمة إذا تم ذكر هذا في العقد. في البرنامج فهو يقع في حوالي تصحيح الأخطاء والتحسينات على البرامج المقدمة.

إجراءات التعامل مع الشكاوى وطلبات التعديلات. لا يلتزم المورد لتوفير الصيانة إذا لم يتم ذكر ذلك في العقد. وينبغي بذل إجراءات الصيانة للبرمجيات القديم.

غير مطابقة
– عمل صيانة لعميل من دون عقد
– لم يتم توثيقها أساليب محددة لصيانة المنتج القديم
– لا إجراءات الاختبار بعد الصيانة.

20 تقنيات الإحصائية

يجب أن يكون هناك جمع وتحليل البيانات حول عدد من الأخطاء وجدت في مراحل مختلفة. وينبغي تحليل المعلومات حول عدم القدرة على الوفاء بالمواعيد النهائية والمعالم.

“————————————————– ————————————————– ————————————————–

Support թարգմանությունը:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty Որակի Elements

Հայացք կձեռնարկվեն ժամը պահանջների տեսանկյունից ընկերությունների զարգացող ծրագրային ապահովման. ISO 9001 ստանդարտը նախատեսված է արտադրական ոլորտում. Ներկայացվող պահանջները մեկնաբանվում են ծրագրային ապահովման զարգացման համաձայն ԻՍՕ 9000-3 եւ TickIT:

Կան 20 հիմնական տարրեր. Յուրաքանչյուր հայեցակարգը, որը հայտնի է որակի կառավարման համայնքում:

1. Կառավարման պատասխանատվություն

1.1 Որակի քաղաքականությունը

The ստանդարտ պահանջում է մատակարարի կառավարման թողարկել որակյալ քաղաքականություն, որտեղ ասվում է, որ ընկերությունը պետք է արտադրել բարձրորակ արտադրանք:

Որակը քաղաքականությունը պետք:
– Սահմանել managementâ € ™ s նվիրվածությունը որակի
– Սահմանել companyâ € ™ s նպատակները որակի, այսինքն, այն, ինչ կառավարում է նշանակում որակի
– Կարեւոր լինել հաճախորդի € ™ s կարիքների
– Է հասկանալ կազմակերպության
– Կիրականացվի

Ոչ conformances

– Հայտարարություն շատ մշուշոտ կամ քաղաքականությունը չի հասկացել, անձնակազմի
– Որակի քաղաքականությունը չի իրականացվում:

Օրինակ Որակի քաղաքականության

â € œWe հասնել որակը միջոցով մոտիվացված եւ հմուտ անձնակազմի սահմանված աշխատանքային ընթացակարգերի, եւ ինտենսիվ վերանայման եւ փորձարկող activities.â €

1.2 կազմակերպությունը

The ստանդարտ պահանջում է փաստաթղթեր պատասխանատվության, իշխանության եւ փոխհարաբերությունների բոլոր անձնակազմի վրա ազդող որակը: Դա նշանակում է, որ եթե անձը ունի պատասխանատվություն, ապա այն պետք է պաշտոնապես նշանակվել է համապատասխան մենեջերի մեջ. Անձը պետք է ունենա իշխանություն է կատարել պատասխանատվություն:

Ըստ ISO, պատասխանատվություն նշանակում է

â € OEA պարտքն է գործել oneâ € ™ s սեփական ցանկությամբ, երբ ինչ-որ բան պետք է արվի, առանց toldâ €.

Ոչ համապատասխան

– Առկա է պատասխանատվության, որը չի կարող կատարվել:


– Ծրագրի-line
– Ծրագրի պատվիրատուն
– Ծրագրի սպասարկում կազմակերպություն
– Ծրագրերի մշակում-ապարատային զարգացում
– Maintenance կազմակերպության օգնության նստարան
– Sales զարգացման

Ռեսուրսներ պահանջում են, որ մատակարարի:
– Որոշել պահանջները ռեսուրսների
– Վերագրելը կադրերի:

Management ներկայացուցիչը պահանջում է նշանակել կառավարիչ ներկայացուցչի հետ իշխանություն եւ պատասխանատվություն:
– Ապահովել, որ ընկերությունը կատարում է պահանջները ISO 9001
– Հաղորդել կատարման որակի համակարգի ընկերության կառավարման

1.3 Management Review

Որակի մենեջեր պետք է պարբերաբար ներկայացնեն արդյունքները
– Որակի աուդիտ
– Վիճակագրական որակի բողոքների
– Records ուղղիչ գործողությունների

Արդյունքները պետք է ներկայացվեն ժամը արձանագրված կառավարման հետ հանդիպման նշումներ, որոնք ներկա էին, թե ինչ էր ներկայացված եւ ինչ որոշում է կայացվել եւ պատրաստված:

2. Որակի համակարգ

Որակի համակարգ â € “”â € œthe կազմակերպչական կառուցվածքի, պարտականությունները, ընթացակարգերը, գործընթացները եւ ռեսուրսներ իրականացման որակի management.â €

Ընթացակարգերը, կանոնները, որոշումները պետք է դրվել գրավոր: Եթե դուք ունեք մի կանոն կամ ընթացակարգ, որը չի պահանջվում է ISO 9001 ստանդարտ դեռ պահանջում է, որ այն գրված է.

Որակյալ մեխանիկական պետք է պարունակի հղում եւ փաստաթղթերի որակի համակարգի:

Ոչ համապատասխան

– Աուդիտորական նմուշ, հետեւաբար եթե մի նմուշ, կան մանր ոչ-conformances, եւ նրանք ամրագրված է, որ դեռ կարող է անհամապատասխանության պատճառով, որ աուդիտորը կարող է կասկածում, որ կան շատ ավելի մանր ոչ-conformances:
– Առկա գրված ընթացակարգերը չեն ձգտել է:

3. Պայմանագրի Review

Ապա մատակարարը ստուգումները նախքան ստորագրելը պայմանագրով, որ կազմակերպությունը պետք է կարողանա կատարել այն, ինչ պահանջվում է պայմանագրով:

Հարցեր, որ պետք է խնդրել ներառում են `
– Արդյոք պահանջները փաստաթղթավորվեն եւ հասկացել:
– Արդյոք թույլատրելի չափանիշները ընդգրկված.
– Իսկ պահանջները տարբերվող, որ մրցույթի լուծվել:
– Կարող մատակարարը զորակոչ բավարար ռեսուրսներ պայմանագրով:
– Կարող մատակարարը զորակոչ իրավասություն համար անհրաժեշտ պայմանագրի:
– Կարող խնդիրը պետք է ավարտվեն ժամանակին.

The ստանդարտ պահանջում է, որ փաստագրված կարգը ակնարկներ է ներառվեն: Մատակարարը պետք է պարզեն, թե ինչպես պայմանագրի փոփոխությունները եւ բեռնաթափման պահանջների հստակեցում միջեւ հաճախորդի եւ մատակարարների է սահմանվում:

4. Դիզայն Control

4.1. ընդհանուր
ISO պահանջում է, որ դուք կարող եք պլանավորել մինչեւ անում, եւ նշեք առաջ նախագծման.

4.2. Դիզայն եւ զարգացման պլանավորում

Դիզայն պլանը պետք է պարունակի `
– Սահմանում մեթոդաբանության կարող է օգտագործվել զարգացման արտադրանքի
– Ժամկետացանկը, պարտականությունները, աշխատանքային հանձնարարություններ եւ առաջընթաց հսկողություն
– Փուլեր նախագիծը կբաժանվի: Սա ներառում է մուտքագրման, արտադրանքի եւ ստուգման արտադրանքի.
– Բնութագիրը մեթոդների եւ գործիքների պետք է օգտագործել

Որակի ծրագիրը պետք է պարունակի:
– Որակի թիրախները
– չափանիշները ընդունելիության
– Բացահայտում պլանավորման, վավերացման եւ ստուգման.
– համար պատասխանատվությունը որակի գործունեության

Եթե ընկերությունը ցանկանում է ձեռք բերել ISO որակավորման ծրագրերը պետք է կայանան բոլոր նախագծերին, քանի որ ISO հավաստագրման է ամբողջ ընկերության համար եւ ոչ թե կոնկրետ նախագծերի.

4.3 կազմակերպչական եւ տեխնիկական Ինտերֆեյս

Եթե կա խմբային աշխատանքը, ինտերֆեյս նրանց միջեւ պետք է նույնացնել, փաստաթղթավորվեն եւ փոխանցվում է նրանց, ովքեր կարիք այդ տեղեկատվությունը: Փաստաթղթերն պետք է պարբերաբար վերանայվեն:

4.4 Դիզայն Input

Պահանջներ առանձնահատկությունները պարունակում են դիզայնի ներդրումն է ծրագրային ապահովման զարգացման համար: Սա կարող է կատարվել գնորդի կամ պատրաստվել են մատակարարի օգտագործելով օրենքները եւ կանոնակարգերը: Մեկ այլ դիզայն մուտքագրում ներառում դիզայն կոդավորման որն օգտագործվում է որպես մուտքային կոդավորման.

Որ ստանդարտ ցանկանում է ապահովել, որ աշխատանքը արտադրանքը յուրաքանչյուր քայլ համապատասխանում պահանջներին:

Պատվերով ծրագրային ապահովման զարգացման, պահանջների փոփոխություններ են տարածված, այնպես որ մի կարգը բեռնաթափման նոր եւ փոփոխված պահանջներ են գնորդին է ստեղծվել:

4.5 Դիզայն Արդյունք

Դիզայն Արդյունք: դիզայնը փաստաթղթերը եւ աղբյուրը կոդը: ISO պահանջում է, որ նախագծային փաստաթղթերը եւ կոդավորման է վերանայվի, նախքան հաղորդագրության մեջ:

A կարգը ընդունման նախագծային արտադրանքի եւ չափորոշիչների ընդունման պետք է ստեղծվի:

4.6 Դիզայն Review

Ծրագրի գործառույթները նման կոդավորման եւ թեստավորման պետք է ներկայացվել վերանայման: A տարածված մեթոդը ապահովման համար ակնարկներ են checklists:

4.7 Դիզայն Ստուգման

Սա ներառում է ակնարկներ, մոդուլի փորձարկման եւ ինտեգրման փորձարկման.

4.8 Դիզայն Վավերացում

Վերջնական համակարգը փորձարկում, ամբողջական ծրագրային արտադրանքի հետ միասին վերանայման անձնագիրը փաստաթղթերի: Այնտեղ պետք է պլանավորվի եւ փաստաթղթավորվեն վավերացման: Beta Testing է համապատասխան ISO քանի դեռ բետա փորձարկման, որը ծածկված է հստակ պայմանավորվածություն միջեւ մատակարարի եւ բետա-թեստավորման հաճախորդի.

4.9 Դիզայն փոփոխությունները

ISO 9001 պահանջում է, որ այն բանից հետո, ազատ արձակել նախագծային փաստաթղթերի կամ աղբյուրի, բոլոր փոփոխությունները պետք է գնալ միջոցով ձեւական գործընթացի, որտեղ փոփոխություններ են փաստագրված, վերանայվում եւ հաստատվում է մինչեւ իրականացումը.

Անվերահսկելի փոփոխություններ բարդ տեխնիկական փաստաթղթերի կամ ծրագրերի չափազանց վտանգավոր են եւ որպես այդպիսին ստանդարտ դա թույլ չի տալիս:
5. Փաստաթուղթը եւ տվյալների Վերահսկիչ

Տեղեկությունները, որոնք վերահսկում է զարգացման / պահպանումը ծրագրային ապահովման. The ստանդարտ պահանջում է, որ նրանք, ովքեր պետք է ինչ-որ փաստաթուղթ / տվյալները պետք է ունենա մուտք դեպի այն: Փոփոխություններ փաստաթղթերի եւ տվյալների պիտի վերահսկվում:

5.1 Ընդհանուր

Արտաքին փաստաթղթերը եւ տվյալները պետք է պահվեն: Այն կարող է պահվել ցանկացած ձեւի (թղթային, էլեկտրոնային ԶԼՄ-ների):

5.2 Փաստաթուղթը տվյալների հաստատումը եւ Issue

Նախքան հարցը փաստաթղթերի եւ տվյալների պետք է քննարկվեն եւ հաստատվեն մինչեւ յուրաքանչյուր հարցի: Մի փաստաթուղթ ցուցակը, որը մէկը պիտի պարզել ընթացիկ տարբերակը փաստաթղթի. Անվավեր կամ հնացած փաստաթղթերը պետք է հեռացվի, կամ հստակ նշված.

5.3 Փաստաթուղթը եւ տվյալների փոփոխությունները

Անձը, / վ պատասխանատու վերանայման եւ հաստատման գործընթացի նշվում է.

6. Purchasing

Այն դեպքում, ենթակապալառու, դուք դեռեւս պատասխանատու: Այսինքն, եթե դուք դիմել է պայմանագրի եւ ենթապայմանագիր աշխատանքը, ԻՍՕ ստանդարտները դեռ տակ ձեր պատասխանատվության եւ ISO պահանջները չեն պետք է պարտադրել է ենթակապալառուի:

6.1 Ընդհանուր

Եթե աշխատուժի է ձեռք բերել, ստանդարտ պահանջում ենք հետեւել կարգը, որը դուք կարող եք ստանալ ճիշտ մարդկանց: Այն մարդիկ կլինեն վերահսկվում է մատակարարների եւ ոչ թե ենթակապալառու:
Ապահովել, որ ձեռք բերել ծրագրային համապատասխանում պահանջներին:
– Contract պահանջները ենթակապալառուների ընթացակարգերի
– Աուդիտ ենթակապալառուն որակի համակարգի
– Ստուգել ենթակապալառու անցյալը կատարումը
– Հարցումների ենթակապալառուն ընթացքում պայմանագրով
– Վկա վերանայում եւ թեստավորման
– Test եւ վերանայման արդյունք է ենթակապալառու:

6.2 Գնահատման Ենթակապալառուների

Անձ անհրաժեշտ լիազորություններ եւ իմացություն պետք է դատել յուրաքանչյուր ենթակապալառու եւ որոշել, թե արդյոք կարելի է օգտագործել: Ընդունված որոշումները պետք է փաստաթղթավորվեն:

Մատակարարը պետք է որոշի, թե ինչ վերահսկողությունն ենթակապալառու, այն կունենա: Ստանդարտը չի նշել, թե ինչպես ավելի վերահսկողություն պետք է ունենա. Դա պարզապես նշում է, որ որոշում պետք է կայացվի օգտագործելով փաստերը:

Հատուկ դեպք է, երբ ծրագրային է ձեռք բերել միջոցով մանրածախ. Այս դեպքում ենթակապալառուն է կազմակերպություն, որի գնման անցկացվում, այլ ոչ թե բնօրինակը մշակողը ծրագրային ապահովման.

Եթե գնման կատարվում մանրածախ ISO 9001 պահանջում է, որ դուք սահմանել, թե որքանով եք տեղադրել պահանջներ է մանրածախ վաճառակետից է վերահսկել իր մատակարարին:

6.3 Purchasing Data

Պահանջներ զարգացման գործընթացում պետք է փաստաթղթավորվեն պայմանագրով հետ մատակարարման պահանջներին հաստատում աշխատանքի արդյունքների եւ ընթացակարգերը:

6.4 ստուգում գնված ապրանքը

Փաստաթղթավորումը որոշումների շուրջ ստուգման յուրաքանչյուր գնվել զարգացման գործիք կամ ընդգրկված արտադրանքը.
Ոչ համապատասխան

– Ոչ ցանկը հաստատված մատակարարների
– Պատշաճ վերահսկողությունը ենթակապալառու
– Ոչ մի փաստաթուղթ ստուգման գնված ապրանքների
– Անպարկեշտ հետ պայմանագիրը ենթակապալառու:

7 Վերահսկում Հաճախորդների մատակարարված Ապրանքի համար

Մատակարարը պարտավոր է ունենալ ընթացակարգեր ստուգման, պահպանման եւ սպասարկման հաճախորդի մատակարարվում ծրագրային ապահովման. Սակայն, որակը պատասխանատվությունն է ծրագրային ապահովման.

A անհամապատասխանության տեղի է ունենում շնորհիվ հստակ պատասխանատվության պատասխանատվության միջեւ հաճախորդի եւ մատակարարների.

8 Ապրանքի ճշգրտում եւ հետագծելիության

Ծրագրային ապահովման մատակարարն պետք է վերահսկի է:
– Իսկ ինչ նախորդող փաստաթուղթը եւ թողարկել այն հիմնված
– Ին, որը հստակեցում այն հիմնված
– Ինչ ուղղումներ եւ փոփոխություններ են ընդգրկվել որին ծրագրերի
– Ինչ է պատահել յուրաքանչյուր խնդրի զեկույցի
– Ից, թե ինչ աղբյուրի էր կոնկրետ մոդուլ գեներացվել.

9 Process Control

Փաստագրված կարգը replication գործընթացի շահագործման եւ կարգը բեռնաթափման վարպետ Proma € ™ s / գրադարաններին: Ապահովելու համար, որ ճիշտ versioning օգտագործվում.

Ոչ համապատասխան
– Ոչ փաստագրված կարգը վերարտադրությունը
– Սխալ քննության վարպետ Proma € ™ s կամ սկավառակների.

10 զննում եւ հսկում

Գրավոր ընթացակարգերը ստուգման եւ փորձարկման է արվի կապակցությամբ վերարտադրությունը:

Ոչ համապատասխան
– Գործառույթը ինքնաբերաբար ստուգում Proma € ™ s չի ստուգվել
– Ոչ փաստագրված կարգը փորձարկման Proma € ™ s.

11 Վերահսկում տեսչության, չափման եւ փորձարկման սարքավորումները

Մատակարարը պետք է ընտրել համապատասխան չափման սարքավորումները եւ հետեւել փաստաթղթավորված ընթացակարգ վերահսկողության սարքավորումների. Յուրաքանչյուր նոր ծրագրային տարբերակը պետք է փորձարկվել է բավարար:

12 տեսչությունը եւ Test կարգավիճակը

Տեխնիկական եւ ծրագրերը պետք է ստուգված միջոցով ակնարկներ եւ փորձարկման. Մատակարարը պետք է ունենա ընթացակարգեր, որոնք արգելելու օգտագործումը չստուգված բնութագրերի կամ ծրագրերի:

13 Վերահսկում Non-համապատասխանող Ապրանք

Ոչ Սույն օրենքին արտադրանքը չպետք է օգտագործվի ակամա: A կարգը բեռնաթափման արագ փոփոխություններ դեպքում կրիտիկական սխալների պետք է ստեղծվի:

– Մաքրել նույնականացում հսկվող ապրանքների, որոնք պարունակում չճշտված սխալներ
– Մեթոդ է առաջացնել հաճախորդների ընդունման փաստը վրա առաքում
– Եթե արագ փոփոխություններով, ապա այն պետք է փաստաթղթավորվեն,
– Վերանայում, որպեսզի ձեւափոխված իրեր կլինի վերերկրյա նույն կարգավիճակը որպես հանգստի ծրագրային ապահովման.

14 Ուղղիչ եւ կանխարգելիչ գործողությունների

– Արդյունավետ քննության տեղեկացնում է, որ չեն համապատասխանում պահանջներին
– Արդյունավետ քննության հաշվետվությունները կարճ comings զարգացման գործընթացում
– Ակտիվ հավաքագրում եւ վերլուծություն առկա տեղեկատվության մասին արտադրանքի եւ գործընթացի անհամապատասխանության եւ կանխարգելիչ գործողությունների:

Տեղեկություն խնդիրների մասին առաջացած պետք է քշել բարելավումներ զարգացման գործընթացում:

Ոչ համապատասխան
– Հաճախորդների բողոք է պատշաճ կերպով չեն վարվել
– Պակասը արդեն հայտնաբերվել է, բայց ոչ ուղղել
– Ոչ ընթացակարգ է ապահովել, որ խնդիրներ են վերլուծվում եւ գործել վրա
– Ոչ ընթացակարգը հաշվետվությունների դժվարությունները կիրառման կանոնները եւ ընթացակարգերը:

15 բեռնաթափման, պահման, փաթեթավորման, պահպանման եւ հետագա առաքմամբ

Վերաբերում է ծրագրային ապահովման replicated է Prom, սկավառակի կամ այլ կրիչի.
ԶԼՄ-ները պետք է լինեն պիտակավորված եւ փաթեթավորված ճիշտ. Տվյալների պիտի ապահովված են: Այնտեղ պետք է լինի նաեւ կարողությունը տրամադրել պաշտպանություն unintentional վնասի.

16 Վերահսկում որակի ռեկորդների

Որակի փաստաթղթերը ցույց են տալիս, որոնք գործողություններ են ձեռնարկվել է ապահովել կամ ստուգել որակը: The ստանդարտ պահանջում է, որ լինի կարգը բեռնաթափման որակի գրառումների. Գրառումները պետք է պահվում համապատասխան ձեւով, որպեսզի նրանք հեշտ հասանելի է.
Ոչ conformances:
– Ոչ կանոնները պահպանման որակի գրառումների
– Review գրառումները չեն պահպանվում
– Test գրառումները չեն պահպանվում
– Ժամկետը պահելու որակի գրառումները սահմանված չէ

17 Ներքին որակի ստուգումների

Այնտեղ պետք է լինի անկախ կազմակերպությունը, որը պարբերաբար ստուգումների բոլոր գործառնությունները, որոնք կարող են ազդել արտադրանքի կամ սպասարկման որակը: Դրանք անցկացվում են անունից ընկերության կառավարման. Այնտեղ պետք է լինի աուդիտի պլանը:

Ոչ համապատասխան
– Ոչ աուդիտի պլանը
– Աուդիտի պլանը, թե մինչեւ օրս

18 Ուսուցում

Ընկերությունը պետք է ապահովի, որ անձնակազմին, որը վերապատրաստվել խնդիրների անհրաժեշտ. A կարգը:
– Որոշել վերապատրաստման կարիքները յուրաքանչյուր հաստիքի
– Ապահովել նման ուսուցում
– Պահպանեք գրառումները վերապատրաստման բոլոր անձնակազմի անդամների:

Վերապատրաստումը պետք է փաստաթղթավորվեն եւ բավարար: Բավարար ենք նշանակում է, որ տվյալ անձը պետք է ի վիճակի է կատարել իր / իր աշխատանքը բարձր բավարար ստանդարտի:

Ոչ համապատասխան
– Ոչ ընթացակարգերը պլանավորման կամ ուսուցման
– Ոչ վերապատրաստման գրառումները
– Ոչ ստացել պատշաճ վերապատրաստում է իր խնդիրը.

19 սպասարկում

Մատակարարը պարտավոր են փաստագրված ընթացակարգերը սպասարկման եթե այս նշված է պայմանագրում: Ծրագրային այն մասին սխալ ուղղումներ եւ սարքերի մատուցված ծրագրային ապահովման.

Ընթացակարգերը բեռնաթափման բողոքներ եւ խնդրանքները փոփոխություններով: Մատակարարը պարտավոր չէ տրամադրել պահպանումը, եթե այն նշված չէ պայմանագրով: Ընթացակարգերի պահպանման համար հին ծրագրային ապահովման պետք է կատարվեն:

Ոչ համապատասխան
– Maintenance աշխատանքներ հաճախորդի առանց պայմանագրի
– Հատուկ մեթոդներ պահպանման հին ապրանքը չէ, փաստագրված
– Ոչ կարգը փորձարկման անվան պահպանման.

20 Վիճակագրական մեթոդները

Այնտեղ պետք է լինի հավաքագրման եւ տվյալների վերլուծություն մոտ թվի սխալների հայտնաբերված տարբեր փուլերում: Տեղեկություն մասին անկարողության հանդիպելու ժամկետներ եւ Milestones պետք է վերլուծել:

“————————————————– ————————————————– ————————————————–

Support tərcümə:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty Quality Elements

Nəzər proqram inkişaf şirkətləri baxımından tələbləri alınacaq. ISO 9001 standartı istehsal sənayesi üçün nəzərdə tutulmuşdur. tələblər ISO 9000-3 və TickIT uyğun olaraq proqram inkişaf üçün şərh olunur.

20 əsas elementləri var. Hər anlayış yaxşı keyfiyyət idarəetmə icma tanınır.

1. Management məsuliyyət

1.1 Keyfiyyət siyasəti

standart bu şirkət keyfiyyətli məhsul istehsal edilir deyir keyfiyyətli siyasət vermək təchizatçı tələb edir.

keyfiyyət siyasəti edilir:
– Keyfiyyətli idarəetmədə € ™ s öhdəliyini müəyyən
– Ki, nə idarə keyfiyyəti deməkdir ki, keyfiyyəti ilə bağlı şirkətin € ™ s məqsədləri müəyyən
– Customerâ € ™ s ehtiyacları üçün müvafiq olun
– Təşkilat başa düşülməlidir
– Tətbiq olunacaq


– Çox qeyri-müəyyən və ya siyasət Statement heyəti tərəfindən aydın deyil
– Keyfiyyət siyasəti həyata deyil.

Məsələn Quality siyasəti

€ œWe əsaslandırılmış və ixtisaslı kadrların vasitəsilə keyfiyyətli, müəyyən iş prosedurları və intensiv araşdırma və activities.â € test nail â

1.2 Organization

standart məsuliyyət, səlahiyyət və keyfiyyətinə təsir bütün personalın qarşılıqlı sənədləşdirilməsini tələb edirsə. Bu şəxs məsuliyyət varsa, bu formal müvafiq meneceri tərəfindən təyin edilir deməkdir. şəxs məsuliyyət yerinə yetirmək səlahiyyəti olmalıdır.

ISO görə, məsuliyyət deməkdir:

bir şey Tolda € olmadan ediləcək zaman € OEA vəzifə oneâ € ™ s öz-özümdən hərəkət etmək.


– Yerinə bilməz məsuliyyət Mövcud.


– Project-line
– Project-müştəri
– Project-xidmət təşkilatı
– Software inkişaf hardware inkişaf
– Maintenance təşkilat-help desk
– Sales inkişaf

Resources təchizatçı tələb:
– Resursları üçün tələblər müəyyən
– Təlim kadr atayın.

Management nümayəndəsi səlahiyyət və məsuliyyəti ilə meneceri nümayəndəsinin təyin tələb edir:
– Şirkət ISO 9001 tələbləri yerinə yetirir təmin
– Şirkət rəhbərliyi keyfiyyətli sistemin performansını hesabat

1.3 Management Review

Quality Manager vaxtaşırı nəticələrini təqdim etməlidir
– Quality audit
– Keyfiyyət şikayətlərin Statistika
– Islah fəaliyyət Records

nəticələr təqdim edildi və nə qərarlar qəbul olunub və qəbul nə qatılan qeyd ilə qeyd idarə iclasında təqdim olunmalıdır.

2. Quality System

Quality sistemi keyfiyyətli management.â € həyata keçirilməsi üçün € “”â € œMəhkəmələrdən təşkilati strukturu, vəzifələri, prosedurlar, proseslər və resursları

Prosedurlar, qaydalar, qərarlar yazılı daxil edilir. Bir qayda və ya ISO 9001 tələb olunmur proseduru varsa, standart hələ də yazılıb ki, tələb edir.

Keyfiyyətli manual keyfiyyət sisteminin arayış və sənədlərin göstərilməlidir.


– Audit auditor daha çox kiçik Uyğunsuzluq var ki, şübhəli bilər, çünki hələ də qeyri-uyğunluq ola bilər, bir nümunə var kiçik Uyğunsuzluq və onlar müəyyən edilir, buna görə də, bir nümunəsidir.
– Yazılı Mövcud prosedurlar riayət olunmur.

3. Müqavilə Review

İmza müqavilə əvvəl təchizatçı çek təşkilat müqavilə tərəfindən tələb olunur nə çıxış edə bilər.

soruşulması lazım suallar daxildir:
– Tələblər sənədləşdirilmiş və başa edirsiniz?
– Qəbul meyarları daxil edilir?
– Tenderdə fərqli tələblər həll olunubmu?
– Təchizatçı müqavilə üçün kifayət qədər resursları yığma edə bilərəmmi?
– Təchizatçı müqavilə üçün lazım olan səlahiyyət yığma edə bilərəmmi?
– Task vaxtında başa bilər?

standart Yorumlari ilə sənədləşdirilmiş proseduru daxil tələb edir. təchizatçı müqavilə dəyişikliklər və müştəri və təchizatçı arasında tələbləri dəqiqləşdirilməsi user müəyyən necə müəyyən etməlidir.

4. Design Control

4.1. general
ISO siz bunu əvvəl plan və dizayn əvvəl müəyyən tələb edir.

4.2. Design və İnkişaf Planlaşdırma

Design plan olmalıdır:
– Metodologiyasının Definition məhsulun inkişafında istifadə ediləcək
– Time proqramları, vəzifələri, iş tapşırıqları və tərəqqi nəzarət
– Mərhələləri layihə bölünəcək. Bu giriş, çıxış və çıxış yoxlama daxildir.
– Metod və alətləri təsviri istifadə ediləcək

Quality plan olmalıdır:
– Quality hədəfləri
– Əlverişliliyi meyarları
– Planlaşdırma, qiymətləndirmə və yoxlama müəyyənləşdirilməsi.
– Keyfiyyətli fəaliyyəti üçün vəzifələri.

şirkət ISO sertifikatlaşdırma xüsusi layihələr üçün bütün şirkət üçün deyil, ildən, planları bütün layihələrdə keçirilməlidir ISO ixtisas qazanmaq istəyir.

4.3 Təşkilati və texniki İnterfeys

qrup iş varsa, onların arasında interfeys, müəyyən məlumatları ehtiyacı olanlar üçün sənədləşdirilmiş və ötürülən olmalıdır. sənədlər müntəzəm olaraq nəzərdən keçirilir.

4.4 Design Input

Tələblər spesifikasiyası proqram inkişaf dizayn daxil edir. Bu alıcı tərəfindən həyata və ya qanun və qaydaların istifadə təchizatçı tərəfindən hazırlana bilər. Başqa bir dizayn daxil kodlaşdırma üçün giriş kimi istifadə olunur dizayn kodlaşdırma daxildir.

Standart hər bir addım iş məhsul tələblərinə cavab təmin etmək istəyir.

proqram inkişaf, tələb dəyişikliklər belə alıcı yeni və dəyişdirilmiş tələblərinə baxılması üçün prosedur yaradılacaq eynidir.

4.5 Design Çıxış

Design Çıxış: dizayn sənədləri və mənbə kodu. ISO dizayn sənədləri və azad əvvəl nəzərdən kodlaşdırma tələb edir.

dizayn çıxış və qəbul meyarları qəbul üçün proseduru yaradılmalıdır.

4.6 Design Review

kodlaşdırma və sınaq kimi Project funksiyaları nəzərdən təqdim edilir. təhlil təmin etmək üçün bir ümumi metodu siyahıları var.

4.7 Design Verification

Bu icmallar, modul test və inteqrasiya testi ibarətdir.

4.8 Design Qiymətləndirmə

istifadəçi sənədlərin nəzərdən ilə birlikdə tam proqram məhsulun Final sistemi test. Orada planlı və qiymətləndirmə sənədləşdirilməlidir. Beta test kimi uzun beta test təchizatçı və beta-test müştəri arasında aydın razılığı ilə əhatə olunur kimi ISO uyğun deyil.

4.9 Design dəyişikliklər

ISO 9001 dizayn sənədlərin və ya mənbə azad sonra, bütün dəyişikliklər dəyişikliklər sənədləşdirilmiş nəzərdən və həyata əvvəl təsdiq edilir rəsmi prosesi vasitəsilə getmək edilir ki, tələb edir.

mürəkkəb texniki sənədlər və ya proqramları Nəzarətsiz dəyişikliklər son dərəcə təhlükəli və standart kimi imkan vermir.
5. Document və Data Control

proqram inkişaf / texniki nəzarət məlumat. standart bir sənəd lazım olanlar / data istifadə etmək imkanına malikdir ki, tələb edir. sənəd və məlumatların dəyişikliklər nəzarət edilir.

5.1 Ümumi

Xarici sənədlər və məlumatlar saxlanılır. Hər hansı bir formada (çap, elektron media) saxlanıla bilər.

5.2 Document və Data Təsdiq və Issue

məsələ sənəd və məlumatların əvvəl baxılır və hər bir məsələ əvvəl təsdiq. A sənəd siyahısı olan bir sənədin cari versiyasını tapa bilməzsən. Yanlış və ya köhnəlmiş sənədlər silindi və ya aydın qeyd olunmalıdır.

5.3 Document və Data dəyişikliklər

baxış və təsdiq prosesi məsul şəxs / s müəyyən edilir.

6. Purchasing

taşeron halda, siz hələ məsuliyyət daşıyırlar. İ.E. Bir müqavilə üçün müraciət və iş subpodrat əgər ISO standartları məsuliyyət davam edir və ISO tələblərinə subpodratçı tətbiq etmək yoxdur.

6.1 Ümumi

manpower satın varsa, standart doğru insanlar bir prosedura əməl tələb edir. insanlar təchizatçı və subpodratçı tərəfindən nəzarət olunacaq.
ki, alınmış proqram təmin etmək tələblərinə uyğun:
– Taşeron prosedurları haqqında Müqavilə tələbləri
– Taşeron keyfiyyətli sisteminin Audit
– Performans keçmiş Check taşeron
– Müqavilə zamanı taşeron Survey
– Şahid baxış və sınaq
– Test və subpodratçı nəzərdən məhsul.

Subpodratçıların 6.2 qiymətləndirilməsi

zəruri hakimiyyəti və səlahiyyətləri ilə Person hər taşeron hökm və istifadə üçün qərar qəbul edir. qərarlar protokol tərtib edilir.

təchizatçı bu olacaq subpodratçı üzərində nə nəzarət həll edir. standart var nə qədər nəzarət qeyd etmir. Bu, sadəcə bir qərar faktlar istifadə edilməsi lazım olduğunu xatırladır.

proqram pərakəndə vasitəsilə satın zaman xüsusi haldır. Bu halda subpodratçı alınması aparılır olan təşkilat proqram orijinal geliştiricisi.

alış pərakəndə ISO vasitəsilə həyata Əgər 9001 siz nə dərəcədə onun təchizatçı nəzarət pərakəndə barədə tələblər qoymaq müəyyən tələb edir.

6.3 Purchasing Data

inkişaf prosesi tələblər iş nəticələri və prosedurları təsdiq etmək təchizatçı tələblərinə birlikdə müqavilədə protokol tərtib edilir.

Alınmış məhsulun 6.4 yoxlanılması

Hər yoxlanılması haqqında qərarların Documentation inkişaf aracı və ya daxil məhsulu satın.

– Təsdiq təchizatçıları No siyahısı
– Taşeron Inappropriate nəzarət
– Alınmış maddələr heç bir sənəd yoxlama
– Subpodratçı ilə uzlaşmayan müqavilə.

Müştəri təchiz Məhsulun 7 Control

təchizatçı yoxlama, saxlanması və müştəri təchiz proqram saxlanılması üçün prosedurlar vardır. Lakin, keyfiyyət proqram məsuliyyət daşıyır.

Qeyri-uyğunluq səbəbiylə müştəri və təchizatçı arasında məsuliyyət aydın məsuliyyət olur.

8 Product Specification və İzlenebilirlik

proqram təchizatçı nəzarət saxlamaq lazımdır:
– Sənəd əvvəlki və vermək nə əsaslanır
– Hansı dəqiqləşdirilməsi-də əsaslanır
– Nə düzəlişlər və dəyişikliklər olan mənbə proqramları daxil edilmişdir
– Hər bir problem hesabat nə oldu
– Nə mənbədən xüsusi modul istehsal edilmişdir.

9 Process Control

master Proma € ™ s / kitabxana user üçün əməliyyat və proseduru yankı prosesi üçün proseduru Sənədləşdirilmiş. Düzgün buraxılış istifadə olunur ki, təmin etmək üçün.

– Təkrarlanması üçün sənədləşdirilmiş qaydası
– Master Proma € ™ s və ya disket düzgün rəftar.

10 Inspection və Test

yoxlama və test üçün yazılı prosedurları təkrarlanması ilə bağlı ediləcək.

– Avtomatik Proma € ™ s yoxlanılması funksiyası ilə tanış deyil
– No Proma € ™ s test üçün proseduru sənədləşdirilmiş.

Yoxlama, ölçülməsi və Test Equipment 11 Control

təchizatçı müvafiq ölçü avadanlıq seçin və avadanlıq nəzarət üçün sənədləşdirilmiş proseduru olmalıdır. Hər bir yeni proqram versiyası kifayət üçün test olmalıdır.

12 Təftiş və Test Status

Features və proqramları baxır və test vasitəsilə təsdiq etməlidir. təchizatçı yoxlanılmamış spesifikasiyası və ya proqramları istifadə qadağan prosedurları vardır.

Qeyri-uyğun Məhsulun 13 Control

Qeyri-uyğun məhsullar bilmədən istifadə edilməməlidir. tənqidi səhvlərin halda tez dəyişikliklər baxılması üçün prosedur yaradılmalıdır.

– Düzeltilmemiş səhvlər ehtiva nəzarət maddələrin Clear eyniləşdirmə
– Method çatdırılması ilə müştəri qəbul çıxartmaq
– Tez dəyişikliklər halda, sənədləşdirilmiş olmalıdır
– Belə redaktə maddələr nəzərdən proqram qalan kimi eyni statusu yüksək olacaq.

14 Düzəldici və profilaktik Fəaliyyət

– Tələblərinə uyğun olmayan hesabat Effektiv user
– Inkişaf prosesində qısa comings ifadə hesabat Effektiv user
– Aktiv toplanması və məhsul və proses qeyri-uyğunluq və profilaktik tədbirlər haqqında məlumat təhlili.

inkişaf prosesinin təkmilləşdirilməsi çəkmək lazımdır qarşılaşılan problemlər haqqında məlumat.

– Müştəri şikayət düzgün ele deyil
– Çatışmazlığı aşkar, lakin korrektə deyil edilmişdir
– No proseduru təmin etmək üçün problemlər təhlil və sonra çıxış ki,
– Qaydaları və prosedurları tətbiq çətinlik hesabat üçün No qaydası.

15 Handling, saxlanması, qablaşdırılması, mühafizəsi və Çatdırılma

Balo, disk və ya digər orta təkrar proqram aiddir.
Media etiketli və düzgün paketlenmiş edilir. Data yedeklenir edilir. də təsadüfi zərər qorunması təmin etmək imkanı olmalıdır.

Quality Records 16 Control

Quality sənədlər tədbirlər təmin etmək və ya keyfiyyətini yoxlamaq üçün qəbul edilmiş göstərir. standart keyfiyyət yazan baxılması üçün prosedur var olmasını tələb edir. onlar asanlıqla əlçatan belə qeydlər müvafiq qaydada saxlanılmalıdır.
– Keyfiyyət yazan tutma üçün qaydaları
– Review qeydlər saxlanılır deyil
– Test qeydlər saxlanılır deyil
– Keyfiyyət uçotunun saxlanılması müddəti müəyyən deyil

17 Daxili Quality auditi

müntəzəm məhsul və ya xidmət keyfiyyətinə təsir edə bilər bütün əməliyyatlar audit müstəqil şəxs olmalıdır. Bu şirkət rəhbərliyi adından aparılır. Audit plan olmalıdır.

– No audit plan
– Biz bu günə qədər Audit plan

18 Training

ki, heyəti təmin etməlidir Company tələb vəzifələri üçün təlim. A proseduru:
– Hər bir heyət mövqe üçün təlim ehtiyaclarının müəyyən edilməsi
– Belə təlim təmin
– Bütün heyət üzvlərinin təlim kayıtları saxlayın.

Training sənədləşdirilmiş və kifayət qədər olmalıdır. kifayət qədər biz şəxs kifayət qədər yüksək standart onun / onun iş yerinə qadir olmaq deməkdir.

– Planlaşdırma və ya təlim üçün prosedurlar
– No təlim qeydlər
– Onun vəzifə üçün müvafiq təhsil aldı deyil.

19 Servicing

Təchizatçı bu müqavilədə göstərilən əgər xidmət prosedurları sənədləşdirilmiş vardır. proqram bu səhv düzəlişlər təslim proqram aksesuarların edir.

dəyişikliklər üçün şikayət və sorğuların baxılması qaydaları. təchizatçı bu müqavilədə göstərilən halda xidmət təmin etmək məcburiyyətində deyil. köhnə proqram Maintenance prosedurları edilməlidir.

– Müqavilə olmadan müştəri üçün Maintenance iş
– Köhnə məhsulun saxlanılması üçün xüsusi metodları sənədləşdirilmiş deyil
– Istismar sonra test üçün proseduru.

20 Statistika Texnikaları

toplanması və müxtəlif mərhələlərində aşkar səhvlərin sayı barədə məlumatların təhlili olmalıdır. son və mərhələləri cavab bilməməsi haqqında məlumat təhlil edilməlidir.

“————————————————– ————————————————– ————————————————–

Itzulpengintza euskarria:
————————————————– ————————————————– ————————————————–
ISO 9001 Kalitatearen Hogeita Elements

Begirada bat software garatzeko enpresen ikuspuntutik baldintzak hartu beharko dira. ISO 9001 estandarra zen fabrikazio industria zuzendua. baldintzak ez dira software garapenerako interpretatu ISO 9000-3 eta TickIT jarraiki.

Badira 20 elementu nagusia. Kontzeptu bakoitza ondo kalitatea kudeatzeko komunitateak ere ezaguna.

1. Kudeaketa Erantzukizun

1.1 Kalitate politika

estandarra hornitzaile ibili behar da kalitate politika bat, non esaten enpresak kalitatezko produktuak ekoizteko jarriko emateko.

Kalitate politika honako hauek hartuko ditu:
– The managementâ € ™ s kalitatearen aldeko apustua zehaztu
– Kalitateen gaineko companyâ € ™ s helburuak definitzea, hau da, zer esan nahi du kudeaketa kalitatearen arabera
– Be the customerâ € ™ s beharrak garrantzitsuak
– Be erakundearen ere ulertu
– Be inplementatu


– Aitorpena too vague edo politika ez da langileek ulertu
– Kalitate politika garatu gabe dago.

Adibidez Kalitate politikaren

â € œWe lortzeko kalitate motibatuta eta kualifikatua langileen bidez, definitzen lan prozedurak, eta berrikuspena intentsiboa eta € activities.â probatzen

1.2 Antolaketa

estandarra erantzukizuna, agintaritza eta kalitatea eragiten dioten langile guztien harreman-dokumentazioa eskatzen. Horrek esan nahi du pertsona bat ardura bat badu, berehala emango dio formalki dagokion manager esleitutako. Pertsona autoridad ardura betetzeko izan behar du.

ISO arabera, erantzukizuna esan nahi du:

â € OEA betebeharra oneâ € ™ s kabuz jarduteko zerbait toldâ € izan gabe egin behar du.


– Hori ezin dela bete erantzukizuna baten Existitzen.


– Proiektu-line
– Proiektu-bezero
– Proiektu-mantentze-erakundea
– Software garapen-ekipoen garapena
– Mantentze antolakuntza-laguntza mahaian
– Salmenta-garapena

Baliabideak hornitzaile hori eskatzen:
–Baliabideen eskakizunak identifikatzea
– Langile esleitu.

Management ordezkari agintea eta erantzukizuna batera manager ordezkariaren izendapena eskatzen du:
– Ziurtatu enpresaren baldintzak betetzen dituen ISO 9001
– Kalitate-sistemaren errendimendua enpresaren kudeaketarekin Salatu

1.3 Management Review

Kalitatea kudeatzailea, aldian-aldian aurkeztu behar emaitzak
– Kalitate-auditoretzak
– Kalitate kexak Estatistikak
– Ekintza zuzentzaileak Records

Emaitzek kudeaketa grabatu bertaratutako buruzko oharrak, zer aurkeztu zen eta zer erabakiak hartu ziren eta egin duen bilera batean aurkeztu behar dira.

2. Kalitate Sistema

Kalitate sistema â € “”â € antolamendu egitura œthe, erantzukizunak, prozedurak, prozesuak eta baliabideak kalitate management.â € ezartzeari buruz

Prozedurak, arauak, erabakiak idatziz jarri beharko da. arau bat edo ez da ISO 9001 eskatutako prozedura badaukazu, estandarra oraindik behar duten scribatua da.

kalitate eskuliburu bat erreferentzia eta dokumentazioa kalitate-sistemaren bat eduki beharko du.


– Batzorde batek lagin bat da, beraz, bada lagin batean, txikiak ez-conformances dira, eta finkoak dira, oraindik ere ez conformidad bat izan ikuskariaren susmoa daitekeelako ez direla asko gehiago minor ez-conformances.
– Idatzizko Existitzen prozedurak ez dira bete behar.

3. Kontratua Review

hornitzaile txekeak sinatzea kontratua aurretik duten erakundearen zer da beharrezkoa kontratua gauzatzeko gai ez izatea.

Galdera hori galdetuko besteak beste:
– Are baldintzak dokumentatu eta ulertu?
– Are onarpen irizpideak sartuta?
– Izan baldintzak lizitazio diferentea konpondu?
– Ezin hornitzaile muster nahikoa baliabide kontratua egiteko?
– Ezin hornitzaile muster kontratua egiteko behar den gaitasuna?
– Ezin zeregina izango denbora bukatu?

estandarra dokumentatu berrikuspen prozedura bat dagoela lirateke agertu behar da. hornitzaile kontratu zuzenketak eta bezero eta hornitzaile arteko eskakizun zehaztapen manipulazioa nola definitzen den identifikatu behar.

4. Design Kontrol

4.1. General
ISO egin aurretik planifikatu behar duzu, eta diseinatu aurretik zehaztu behar da.

4.2. Diseinu eta garapena Plangintza

Diseinu plan bat eduki behar du:
– Metodologia definizioa den produktu baten garapenean erabiliko dira
– Denbora ordutegiak, ardurak, lan zereginak eta aurrerapen kontrola
– Faseak proiektu banatuko dira. Horretan sartzen sarrera, irteera eta irteera egiaztatzeko.
– Metodoak eta tresnak deskribapena erabili ahal izateko

Kalitate plan bat eduki behar du:
– Kalitatearen helburuak
– Onargarritasuna egiteko irizpideak
– Plangintza, baliozkotze eta egiaztapena identifikatzea.
– Kalitate-jarduerak egiteko erantzukizuna.

enpresa batean ISO sailkatuek planak den proiektu guztietan ospatu behar irabazteko, ISO ziurtagiria enpresa osoarentzat da geroztik eta ez proiektu espezifikoak nahi badu.

4.3 Antolakuntza eta teknikoa Interfazeak

ez bada talde-lana da, haien arteko interfazeak identifikatu behar dira, dokumentatu eta transmititu dutenei informazioa beharrik. dokumentazioa berrikusiko ditu aldizka.

4.4 Design Input

Baldintzak zehaztapenak eduki diseinua software garapenean sarrera. Hau erosleak arabera egin daiteke edo hornitzaile lege eta arauak erabiliz prestatu. Beste diseinu sarrera diseinua, kodifikazioa bertan sarrera gisa erabiltzen da kodeketaren dira.

standard nahi du lan Urrats bakoitzaren produktua baldintzak betetzen dituela ziurtatzeko.

software garapenean, baldintza aldaketak ohikoak dira, beraz, erosleak batetik eskakizun berriak eta aldatutako lantzeko prozedura bat sortu behar da.

4.5 Design irteera

Diseinu Irteera: diseinu dokumentazio eta iturri-kodea. ISO eskatzen diseinu dokumentuak eta kodeketa izango oharra aurretik berrikusi.

Diseinu irteera eta onarpen irizpideak onartzea prozedura bat sortu beharko litzateke.

4.6 Design Review

Project kodetze eta azterketa bezalako funtzio berrikuspena aurkeztuko dira. berrikuspen bermatuz metodo komun A zerrendak dira.

4.7 Design egiaztatzean

Hau berrikuspen, modulu probak eta integrazio probak osatzen dute.

4.8 Design Validation

Final-sistema proba, osoa software produktua elkarrekin Erabiltzaile dokumentazioa berrikusteko batera. Ez dago aurreikusita egon behar eta dokumentatu baliozkotzea. Beta probak ISO conformidad da, betiere beta testing da hornitzaile eta beta-probak bezeroaren arteko hitzarmen argi bat estalita.

4.9 Design aldaketak

ISO 9001 eskatzen duen diseinua dokumentazioa edo iturria oharra ondoren, aldaketa guztiak jarriko prozesu formal bat non aldaketak dokumentatu dira, berrikusi eta ezartzeko aurretik onartutako bidez joan.

Kontrolik gabeko dokumenturik edo programa tekniko konplexuak aldaketak oso arriskutsuak dira eta estandarra esaterako, ez du onartzen.
5. Dokumentu eta Datu Kontrola

Informazioa software garapena / mantentze kontrolatzen duen. estandarra eskatzen duen dokumentu batzuk behar dutenek / data da zein den zehazteko. dokumentu eta datuen aldaketak kontrolatuko ditu.

5.1 General

Kanpoko dokumentuak eta datuak bilduko dira. Bat inprimakia (paperean, euskarri elektronikoen) an gordeko daiteke.

5.2 Dokumentu eta Datu onespena eta Issue

agiriak eta datuak aurretik berrikusiko dira eta ale bakoitzaren aurretik onartu. Dokumentu zerrenda horretan jakin dizkiote agiriaren bertsioan. dokumentu baliogabea edo zaharkitua kendu beharko dira edo garbi markatuta.

5.3 Dokumentu eta Datu-aldaketak

The pertsona / berrikuspena eta onartzeko prozesuan arduratzen s adierazi beharko dira.

6. Erosketak

azpikontratista kasuan, erantzule dira oraindik duzu. Adibidez kontratu bat eskatu duzu eta lana azpikontratatzen bada, ISO estandarrak da oraindik zure ardurapean eta ISO baldintzak ez dute azpikontratista inposatutako.

6.1 General

eskulan erosi bada, estandarra prozedura bat dela eskuineko jendea deritzozunari dezazun behar du. Jendea egon hornitzaile eta ez azpikontrata bidez kontrolatzen dira.
erositako software hori ziurtatzeko baldintzak betetzen ditu:
– Kontratua azpikontratatuen prozedurei buruzko baldintzak
– Subcontractor kalitate sistemaren Ikuskaritza
– Check subcontractor performance iragana
– Kontratu zehar azpikontratista inkesta
– Lekuko berrikuspena eta azterketa
– Test eta berrikuspena subcontractor produktua.

6.2 Azpikontratistak ebaluazioa

beharrezkoa agintaritza eta gaitasuna duen pertsona azpikontratista bakoitzak iugeaturen eta erabakitzeko erabili ala ez. erabakiak, dokumentatu beharko dira.

Hornitzaile zer subcontractor gaineko kontrola izango dute erabakiko du. standard ez du aipatu zenbat kontrola izan behar duzu. aipatzen besterik ez da erabaki bat behar hechos erabiliz egina egon.

Kasu berezi bat da, software txikizkako bidez erositako da. Kasu honetan subcontractor erakundearen erosketa egiten da, ez jatorrizko softwarea sustatzailearen da.

erosketa txikizkako ISO bidez egiten bada 9001 zein neurritan baldintzak jarri duzu dendara bere hornitzaile kontrolatzeko definitzeko eskatzen dizu.

6.3 Erosketa datuak

garapen-prozesuari buruzko betekizunak hornitzaile baldintzak lanaren emaitzak eta prozedurak onestea batera kontratuaren dokumentatu beharko da.

6.4 erositako produktua egiaztatzea

bakoitzaren egiaztapen buruzko erabakiak Dokumentazio garapen tresna edo barne produktu erosi.

– Ez homologatuen zerrenda
– Subcontractor kontrola desegokia
– Dokumentu No erositako elementuak egiaztatzea
– Azpikontratista batekin desegokia kontratua.

7 Bezeroaren emandako Produktuen kontrola

Hornitzaile egiaztapen, biltegiratze eta bezeroari emandako software mantentze prozedurak izango dituzte. Hala ere, kalitatea software eskumena da.

ez-ados egoteko A gertatzen dela eta bezero eta hornitzaile arteko erantzukizunaren ardura unclear.

8 Produktuen zehaztapena eta Trazabilitatea

software hornitzaile kontrola mantendu behar orrian:
– Zer aurreko dokumentu eta igorriko da oinarrituta dago
– Zein zehaztapen oinarri den
– Zer zuzenketak eta aldaketak izan dira, bertan iturburu-programetan sartuta
– Zer arazo txosten bakoitzean gertatu
– Zer iturburua zen modulu jakin bat sortzen.

9 Prozesuen Kontrola

Dokumentatuen prozedura erreplikazioa funtzionamendua eta prozedura maisu PROMA € ™ s / liburutegiak manipulazioa prozesua da. zuzena versioning erabiltzen dela ziurtatzeko.

– Ez dago dokumentatuta erreplikazioa egiteko prozedura
– Master PROMA € ™ s edo diskete horiek gaizki.

10 Ikuskaritza eta saiakuntza

Idatzizko ikuskapena eta azterketa prozedurak erreplikazioa lotuta egin behar.

– PROMA € ™ s automatikoki egiaztatzen funtzioa ez ditu ikuskatu
– Ez dago dokumentatuta prozedura PROMA € ™ s probatzeko.

11 Ikuskaritza, Neurketa eta Test Ekipamendua kontrola

Hornitzaile dagokion neurketa-ekipoa hautatu behar eta dokumentatu prozedura bat jarraitu ekipoen kontrola da. software bertsio berri bakoitzak nahikotasun probatu behar.

12 Ikuskaritza eta Test Status

Zehaztapenak eta programak berrikuspen eta azterketa bidez egiaztatu behar da. Hornitzaile zehaztapenak egiaztatu gabeko edo programak erabiltzea debekatzen duten prozedurak izango dituzte.

13 Non-KONFORME Produktuen kontrola

Ez-konformismoaren produktuak ez dira nahi gabe erabili behar. aldaketak azkar manipulazioa Erroreak kasuan prozedura bat sortu beharko litzateke.

– Garbitu Zuzendu gabeko erroreak izan duten elementu kontrolatu identifikazioa
– Metodo bezeroaren onarpena ematean elicit
– Aldaketak azkar kasuan, dokumentatu behar da
– Beraz aldatutako elementuak a berrikusi beharreko estatus bera software gainerako bezala altxatutako izango.

14 zuzentzaile eta Prebentzio Ekintza

– Hori ez eskakizunak betetzen txostenak manipulazioa eraginkorra
– Txostenak labur-etorriak garapen prozesuan adieraziz manipulazioa eraginkorra
– Bilketa aktiboa eta produktu eta prozesu ez-ados egoteko eta prebentzio-ekintzak buruzko informazioa eskuragarri azterketa.

topatu garapen prozesuaren hobekuntza gidatzeko behar arazo buruzko informazioa.

– Bezeroaren kexa bezala ez da kudeatu
– Gabealdia aurkitu dutela, baina ez zuzendu
– No prozedura bermatzeko arazoak aztertu eta jardun gainean daude
– No prozedura arauak eta prozedurak aplikatuz zailtasunak salatzeagatik.

15 Handling, biltegiratzeko, ontziratzeko, kontserbatzea eta erak

PROM, disko edo beste euskarri batean erreplika software aplikatzen.
Media etiketatu beharko dira, eta behar bezala paketatuta. Datu kopiatuko diren. Badira babesa emateko nahigabe kalteak gaitasuna ere izan behar.

16 Quality Records kontrola

Quality dokumentuak zein ekintza hartu dira ziurtatzeko edo egiaztatu kalitatea erakusteko. estandarra eskatzen ez dagoela kalitate erregistroak lantzeko prozedura bat izan. erregistroak modu egokian gorde behar dira erraz eskuragarriak beraz.
– No arauak kalitate erregistroen atxikipen
– Iritzia erregistroak ez dira mantendu
– Test erregistroak ez dira mantendu
– Kalitatea mantenduz Erregistro epea zehaztu gabe dago

17 Kalitatea Ikuskaritzak

Ez dago entitate independente Aldizka eragina izan dezaketen produktu edo zerbitzuaren kalitatea eragiketa guztiak ikuskaritzak izan behar du. Hauek dira enpresa kudeaketa izenean egindako. Ez dago auditoria plan bat izan beharko luke.

– Ez auditoria plan
– Ikuskaritza plan eguneratuta ez

18 Prestakuntza

Enpresaren langileek bermatu behar da eskatutako lanak egiteko prestatuak. Prozedura bat egiteko:
– Prestakuntza-beharrak identifikatu langileak postu bakoitzerako
– Hala nola, prestakuntza eskaintzea
– Jarrai taldekideak guztien prestakuntza-erregistroak.

Prestakuntza dokumentatu behar da eta baita nahikoa. nahikoa By pertsona hori izan da bere / bere lana egitean nahikoa altua estandar bat gai esan nahi dugu.

– Ez prozedurak plangintza edo prestakuntza
– No prestakuntza erregistro
– Ez jaso prestakuntza egokia bere zeregina da.

19 Zerbitzuak

Hornitzailea dokumentatu zaio izapide hau da kontratuan aipatzen bada mantenimendua egiteko. Software error zuzenketak eta entregatu software hobekuntzak buruz da.

kexak eta -eskaerarik aldaketak egiteko prozedurak. Hornitzaile ez dago behartuta mantentze eskaintzeko ez bada kontratua aipatu. Mantentze software zaharra prozedurak egin behar dira.

– Mantentze bezero bat lan kontraturik gabe
– Produktu zaharren mantentze-metodoak Berariazko ez da dokumentatu
– No prozedura mantentze ondoren, probak egiteko.

20 teknika estatistikoak

Ez dago bilduma eta fase desberdinak aurki akats kopurua buruzko datuen azterketa izan behar du. imposibilidad epeak eta mugarriak erantzuteko buruzko informazioa aztertu behar dira.

“————————————————– ————————————————– ————————————————–

пераклад Падтрымка:
————————————————– ————————————————– ————————————————–
ISO 9001 Элементы якасці Дваццаць

Погляд будзе прынята на патрабаванні з пункту гледжання кампаній, якія займаюцца распрацоўкай праграмнага забеспячэння. Стандарт ISO 9001 быў прызначаны для апрацоўчай прамысловасці. Патрабаванні інтэрпрэтуюцца для распрацоўкі праграмнага забеспячэння ў адпаведнасці з ІСО 9000-3 і TickIT.

Ёсць 20 асноўных элементаў. Кожная канцэпцыя добра вядомая ў супольнасці кіравання якасцю.

Адказнасць 1. Упраўленне

1.1 Палітыка ў галіне якасці

Стандарт патрабуе ад кіраўніцтва пастаўшчыка аформіць палітыку ў галіне якасці, дзе ён кажа, што кампанія павінна выпускаць якасную прадукцыю.

Палітыка ў галіне якасці павінна:
– Вызначыць прыхільнасць managementâ € ™ з да якасці
– Вызначыць мэты кампаніі яшчэ € ™ з адносна якасці, гэта значыць, што кіраванне якасцю азначае
– Мець стаўленне да патрэбаў customerâ € ™ з
– Трэба разумець у арганізацыі
– Быць рэалізаваны


– Заява занадта расплывістым ці палітыкі не разумеюць супрацоўнікаў
– Палітыка ў галіне якасці не рэалізаваны.

напрыклад палітыкі ў галіне якасці

â € œWe дасягнуць якасці шляхам матываванага і кваліфікаванага персаналу, вызначаны працэдуры працы, а інтэнсіўны агляд і тэставанне activities.â €

1.2 Арганізацыя

Стандарт патрабуе дакументавання адказнасці, паўнамоцтваў і ўзаемасувязі ўсяго персаналу, якія ўплываюць на якасць. Гэта азначае, што калі ў чалавека ёсць адказнасць, то ён павінен быць афіцыйна прысвоены адпаведнага мэнэджэра. Чалавек павінен мець права выконваць абавязкі.

У адпаведнасці з ISO, адказнасць азначае:

â € œa абавязак дзейнічаць на oneâ € ™ з уласнага згоды, калі што-то павінна быць зроблена без toldâ €.


– Існуючыя з адказнасці, якія не могуць быць выкананы.


– Праект лініі
– Праект-кліент
– Праектная арганізацыя-абслугоўванне
– Распрацоўка праграмнага забеспячэння на развіццё апаратных сродкаў
– Забеспячэнне арганізацыйна-даведачная служба
– Продаж-распрацоўка

Рэсурсы патрабуюць, каб пастаўшчык:
– Вызначэнне патрабаванняў да рэсурсаў
– Прызначаюць навучаны персанал.

Прадстаўнік кіраўніцтва патрабуе прызначэнне мэнэджара прадстаўніка з паўнамоцтвамі і адказнасцю:
– Пераканайцеся ў тым, што кампанія адпавядае патрабаванням ІСО 9001
– Справаздача аб выкананні сістэмы якасці менеджменту кампаніі

1.3 Аналіз з боку кіраўніцтва

Менеджэр па якасці павінен перыядычна прадстаўляць вынікі
– Праверка якасці
– Статыстыка якасці скаргаў
– Справаздачы карэктуюць дзеянняў

Вынікі павінны быць прадстаўлены на зарэгістраваным нарадзе кіравання з нотамі аб тым, хто прысутнічаў, што было прадстаўлена і якія рашэнні былі прынятыя і зробленыя.

2. Сістэма кантролю якасці

Сістэма кантролю якасці â € “”€ œthe арганізацыйная структура, абавязкі, працэдуры, працэсы і рэсурсы для рэалізацыі якасці management.â €

Працэдуры, правілы, рашэнні павінны быць уведзеныя ў пісьмовай форме. Калі ў вас ёсць правіла або працэдуру, якая не патрабуецца па стандарце ISO 9001, стандарт патрабуе, каб па-ранейшаму напісана.

Кіраўніцтва па якасці павінна ўтрымліваць спасылкі і дакументацыю сістэмы якасці.


– Аўдыт ўяўляе сабой узор, таму, калі ва ўзоры, ёсць нязначныя неадпаведнасці, і яны фіксуюцца, ён усё яшчэ можа быць неадпаведнасці, таму што аўдытар можа падазраваць, што ёсць яшчэ шмат нязначныя неадпаведнасці.
– Існуючыя пісьмовыя працэдуры не выконваюцца.

Агляд 3. Дагавор

Праверкі пастаўшчыка да падпісання кантракту, што арганізацыя зможа выканаць тое, што патрабуецца дамовай.

Пытанні, якія варта задаць, ўключаюць:
– Задакументаваць патрабаванні і разумець?
– Уключаны Ці крытэрыі прыёмкі?
– Ці былі патрабаванні, адрозныя ад тэндэру былі вырашаны?
– Ці можа пастаўшчык сабраць дастатковую колькасць рэсурсаў для кантракту?
– Ці можа пастаўшчык набрацца навыкаў, неабходных для заключэння дамовы?
– Ці можа задача быць завершана своечасова?

Стандарт патрабуе, каб дакументальна працэдура з дапамогай аглядаў быць уключаны. Пастаўшчык павінен вызначыць, якім чынам кантрактныя змяненні і апрацоўка спецыфікацыі патрабаванняў паміж заказчыкам і пастаўшчыком вызначаецца.

4. Кантроль Праектаванне

4.1. агульны
ISO патрабуе, каб вы плануеце, перш чым рабіць і паказаць перад праектаваннем.

4.2. Праектаванне і планаванне развіцця

План Дызайн павінен змяшчаць:
– Вызначэнне метадалогіі для выкарыстання ў распрацоўцы прадукту
– Часовыя раскладу, размеркаванне адказнасці, працоўныя заданні і кантроль прагрэсу
– Праект Фазы будзе падзелены. Гэта ўключае ў сябе ўвод, вывад і праверку прадукцыі.
– Апісанне метадаў і інструментаў, якія будуць выкарыстоўвацца

План якасці павінен змяшчаць:
– Мэтавыя паказчыкі якасці
– Крытэрыі прымальнасці
– Вызначэнне планавання, валідацыю і верыфікацыі.
– Адказнасць за якасць дзейнасці.

Калі кампанія жадае атрымаць кваліфікацыю ISO планы павінны быць праведзены ва ўсіх праектах, так як сертыфікацыя ISO для ўсёй кампаніі, а не для канкрэтных праектаў.

4.3 Арганізацыйныя і тэхнічныя інтэрфейсы

Калі ёсць групавая праца, інтэрфейсы паміж імі павінны быць вызначаны, задакументаваныя і перададзеныя тым, хто мае патрэбу ў інфармацыі. Дакументацыя павінна рэгулярна пераглядацца.

4.4 Канструкцыя Уваходны

Тэхнічныя патрабаванні ўтрымліваюць ўваходныя дадзеныя праектавання ў распрацоўцы праграмнага забеспячэння. Гэта можа быць зроблена за кошт пакупніка або падрыхтаваныя пастаўшчыком з выкарыстаннем законаў і нарматыўных актаў. Іншы ўваход дызайн ўключае ў сябе дызайн кадавання, які выкарыстоўваецца ў якасці ўваходных дадзеных для кадавання.

Стандарт хоча, каб гарантаваць, што прадукт працы кожнай прыступкі адпавядае патрабаванням.

Пры распрацоўцы праграмнага забеспячэння, змены патрабаванняў з’яўляюцца агульнымі, так быць створана працэдура для апрацоўкі новых і змененых патрабаванняў ад пакупніка.

4.5 Канструкцыя Выхадны

Дызайн Выснова: праектная дакументацыя і зыходны код. ISO патрабуе, каб праектная дакументацыя і кадаваньне будуць разгледжаныя да выпуску.

Неабходна стварыць парадак прыняцця прадукцыі праектавання і крытэрыі прыёмкі.

4.6 Design Review

Функцыі праекта, такія як кадаваньне і тэставанне павінны быць прадстаўлены ў аглядзе. Агульны метад для забеспячэння аглядаў кантрольных пералікаў.

4.7 Праверка праекта

Яна складаецца з аглядаў, модуль праверкі і тэставання інтэграцыі.

4.8 Design Validation

Канчатковы тэст сістэмы, поўнага праграмнага прадукту разам з нагляднымі карыстацкай дакументацыі. Там павінна быць спланавана і дакументальна праверкі. Бэта-тэставанне ў адпаведнасці з ISO да тых часоў, як бэта-тэставанне пакрываецца выразным пагадненнем паміж пастаўшчыком і бэта-тэставанні кліента.

4.9 Канструктыўныя змены

ISO 9001 патрабуе, каб пасля выпуску праектнай дакументацыі або крыніцы, усё змены павінны прайсці праз фармальны працэс, у якім змены дакументальна, разгледжаны і зацверджаны да яго рэалізацыі.

Некантралюемыя змены ў складаных тэхнічных дакументаў або праграм, надзвычай небяспечныя і ў якасці такога стандарту не дазваляе.
5. Дакумент і кіравання дадзенымі

Інфармацыя, якая кантралюе распрацоўку / абслугоўванне праграмнага забеспячэння. Стандарт патрабуе, каб тыя, хто мае патрэбу ў якой-небудзь дакумент / дадзеныя павінны мець доступ да яго. Змены дакументаў і дадзеных павінны кантралявацца.

5.1 Агульныя палажэнні

Знешнія дакументы і дадзеныя павінны быць захаваны. Ён можа захоўвацца ў любой форме (папяровай копіі, электронных СМІ).

5.2 Дакумент і зацвярджэнне дадзеных і выпуск

Перад эмісійнымі дакументамі і дадзенымі, павінны быць разгледжаны і зацверджаны перад кожным пытаннем. Пералік дакументаў, у якіх адзін павінен даведацца актуальную версію дакумента. Несапраўдныя або састарэлыя дакументы павінны быць выдаленыя або выразна пазначаныя.

5.3 Дакумент і змены дадзеных

Чалавек / с адказным за працэс разгляду і зацвярджэння павінны быць пазначаныя.

6. Купля

У выпадку субпадрадчыка, вы несяце адказнасць. гэта значыць калі вы падаеце заяву на кантракт і субпадраду працы, стандарты ISO па-ранейшаму пад сваю адказнасць і патрабаванні ISO не павінны быць накладзеныя на субпадрадчыка.

6.1 Агульныя палажэнні

Калі рабочая сіла купляецца, стандарт патрабуе, каб вы прытрымлівацца працэдуры, якую вы атрымаеце патрэбных людзей. Людзі будуць кантралявацца пастаўшчыком, а не субпадрадчыкам.
Для таго, каб пераканацца, што набытая праграмнае забеспячэнне адпавядае патрабаванням:
– Патрабаванні дамовы аб працэдурах субпадрадчыка
– Аўдыт сістэмы якасці субпадрадчыкам
– Праверыць субпадрадчыкам мінулае прадукцыйнасці
– Абследаванне субпадрадчыка падчас кантракту
– Агляд і тэставанне сведак
– Тэст і агляд прадукту субпадрадчыка.

6.2 Ацэнка субпадрадчыкаў

Чалавек з неабходнымі паўнамоцтвамі і кампетэнцыяй будзе судзіць кожнага субпадрадчыка і вырашыць, ці варта выкарыстоўваць. Рашэнні павінны быць дакументальна аформленыя.

Пастаўшчык павінен вырашыць, што кантроль над субпадрадчыкам ў яго будзе. Стандарт не кажучы ўжо пра тое, колькі кантролю вы павінны мець. Ён проста згадвае, што рашэнне павінна быць зроблена з дапамогай фактаў.

Асаблівы выпадак, калі праграмнае забеспячэнне было набыта ў рознічным гандлі. У гэтым выпадку субпадрадчыка з’яўляецца арганізацыяй, з якой закупка праводзіцца, ня арыгінальны распрацоўшчык праграмнага забеспячэння.

Калі закупачная ажыццяўляецца праз рознічную ISO 9001 патрабуе, каб вы вызначылі, у якой ступені вы кладзеце патрабаванні да прадаўца, каб кантраляваць свайго пастаўшчыка.

6.3 Набыццё дадзеных

Патрабаванні да працэсу распрацоўкі павінны быць дакументальна аформленыя ў дамове нароўні з патрабаваннямі пастаўшчыка зацвердзіць вынікі працы і працэдуры.

6.4 Праверка закупленай прадукцыі

Дакументацыя рашэнняў аб праверцы кожны набыты інструмент развіцця або уключаны прадукт.

– Не пералік зацверджаных пастаўшчыкоў
– Недапушчальна кантроль субпадрадчыка
– Няма дакументаў праверка набытых тавараў
– Недапушчальна кантракт з субпадрадчыкам.

7 Кантроль давальніцкай прадукту

Пастаўшчык павінен мець працэдуры для праверкі, захоўвання і абслугоўвання кліентаў прыкладаемага праграмнага забеспячэння. Тым не менш, якасць нясе адказнасць за праграмнае забеспячэнне.

Неадпаведнасць адбываецца з-за невыразнага адказнасці адказнасці паміж заказчыкам і пастаўшчыком.

8 Спецыфікацыя прадукцыі і нагляду за

Пастаўшчык праграмнага забеспячэння павінен захаваць кантроль за:
– На што папярэдні дакумент і аформіць яго аснове
– На якой спецыфікацыі яна заснавана
– Якія карэктывы і папраўкі былі ўключаныя ў якія праграмы крыніцы
– Што здарылася з кожным паведамленнем пра памылку,
– З якой крыніцы быў канкрэтны модуль, спароджаны.

Кантроль працэсу 9

Дакументаваную працэдуру для працэсу рэплікацыі ў аперацыі і працэдуры абыходжання з майстар Прома € ™ S / бібліятэк. Для таго, каб пераканацца, што выкарыстоўваецца правільная кіравання версіямі.

– Не дакументаваная працэдура для рэплікацыі
– Няправільнае абыходжанне з майстар-Прома € ™ з або дыскетах.

10 Кантроль і выпрабаванні

Пісьмовыя працэдуры праверкі і тэставання павінна быць зроблена ў сувязі з рэплікацыяй.

– Функцыя аўтаматычнай праверкі Прома € ™ з не былі правераныя
– Не дакументаваная працэдура для тэставання Прома € ™ s.

11 Кантроль інспекцыі, вымяральнага і выпрабавальнага абсталявання

Пастаўшчык павінен выбраць адпаведную вымяральную апаратуру і вынікайце дакументаваную працэдуру для кіравання абсталяваннем. Кожная новая версія праграмнага забеспячэння павінна быць праверана на дастатковасць.

12 Праверка і выпрабаванні Статус

Тэхнічныя характарыстыкі і праграмы павінны праверыць з дапамогай аглядаў і тэставання. Пастаўшчык павінен мець працэдуры, якія забараняюць выкарыстанне неправераных спецыфікацый або праграм.

13 Кантроль неадпавядалых прадукту

Некандыцыйнай прадукцыі не павінна выкарыстоўвацца ненаўмысна. Неабходна стварыць працэдуру для апрацоўкі хуткіх зменаў у выпадку крытычных памылак.

– Дакладнае вызначэнне кантраляваных тавараў, якія ўтрымліваюць невыпраўленыя памылкі
– Метад, каб выклікаць прызнанне кліентаў пасля дастаўкі
– У выпадку хуткіх мадыфікацый, яно павінна быць дакументальна
– Прагляд таму змененыя дэталі будуць павышаны да такой жа статус, як астатняй часткі праграмнага забеспячэння.

14 карэкціруючых і папераджальных дзеянняў

– Эфектыўная апрацоўка справаздач, якія не адпавядаюць патрабаванням
– Эфектыўная апрацоўка паведамленняў, якія паказваюць на кароткіх прыездаў у працэсе распрацоўкі
– Актыўны збор і аналіз існуючай інфармацыі аб прадукце і працэсе неадпаведнасці і прафілактычных мерапрыемстваў.

Інфармацыя аб праблемах, з якімі сутыкаюцца павінны весці ўдасканалення працэсу распрацоўкі.

– Скарга кліента не была належным чынам апрацаваны
– Дэфіцыту было выяўлена, але не выпраўлена
– Ні адна працэдура не для таго, каб праблемы аналізуюцца і дзейнічала
– Не працэдура цяжкасці з прымяненнем правілаў і працэдур справаздачнасці.

15 Апрацоўка, захоўванне, ўпакоўка, кансервацыя і пастаўка

Ставіцца да праграмнага забеспячэння реплицируется на PROM, дыску або іншым носьбіце.
СМІ павінны быць маркіраваныя і спакаваныя правільна. Дадзеныя павінны быць падмацаваныя. Там таксама павінны быць магчымасць забяспечыць абарону ад выпадковага пашкоджанні.

16 Кантроль якасці запісаў

Якасныя дакументы паказваюць, якія дзеянні былі зроблены для забеспячэння або праверкі якасці. Стандарт патрабуе, каб існавала працэдура апрацоўкі якасных запісаў. Запісы павінны захоўвацца належным чынам, каб яны былі лёгка даступныя.
– Няма правіл для ўтрымання якасных запісаў
– Запісы Агляд не захоўваюцца
– Пратаколы выпрабаванняў не захоўваюцца
– Перыяд захавання якасці запісу не вызначаны

17 Унутраны аўдыт якасці

Там павінна быць незалежным органам, які рэгулярна праводзіць аўдыт ўсіх аперацый, якія могуць паўплываць на прадукт ці паслугу якасці. Яны праводзяцца па даручэнні кіраўніцтва кампаніі. Там павінна быць план аўдыту.

– Не План аўдыту
– План аўдыту не актуальна

18 Навучанне

Кампанія павінна забяспечыць, каб персанал навучаны для выканання задач, неабходных. Працэдура для:
– Вызначэнне патрэбнасці ў падрыхтоўцы кадраў для кожнай пазіцыі персаналу
– Забяспечыць такую падрыхтоўку
– Весці ўлік падрыхтоўкі ўсіх супрацоўнікаў.

Навучанне павінна быць дакументавана і досыць. Пры дастатковай мы маем на ўвазе, што чалавек будзе здольны выконваць яго / яе працу на досыць высокім узроўні.

– Не працэдур планавання або падрыхтоўкі
– Ніякіх навучальных запісаў
– Не атрымаў належную падрыхтоўку для сваёй задачы.

19 Тэхнічнае абслугоўванне

Пастаўшчык павінен мець дакументаваныя працэдуры для абслугоўвання, калі гэта паказваецца ў дамове. У праграмным забеспячэнні гаворка ідзе пра выпраўлення памылак і паляпшэнняў пастаўляецца праграмнага забеспячэння.

Працэдуры разгляду скаргаў і запытаў на ўнясенне зменаў. Пастаўшчык не абавязаны прадастаўляць абслугоўванне, калі ён не згадваецца ў дамове. Працэдуры тэхнічнага абслугоўвання для старога праграмнага забеспячэння павінны быць зробленыя.

– Работы па тэхнічным абслугоўванні для кліента без кантракту
– Спецыфічныя метады падтрымання старога прадукта не дакументавана
– Не Працэдура тэставання пасля тэхнічнага абслугоўвання.

20 Статыстычныя метады

Там павінна быць збор і аналіз дадзеных аб колькасці памылак, выяўленых у розных фазах. Інфармацыя аб немагчымасці захавання тэрмінаў і асноўных этапаў павінны быць прааналізаваны.

“————————————————– ————————————————– ————————————————–

সাপোর্ট অনুবাদ:
————————————————– ————————————————– ————————————————–
ISO-9001 কুড়ি কোয়ালিটির উপাদানসমূহ

একটি বর্ণন সফ্টওয়্যার উন্নয়নশীল কোম্পানি দৃষ্টিকোণ থেকে প্রয়োজনীয়তা এ নিয়ে যাওয়া হবে. ISO-9001 মান উত্পাদন শিল্পের জন্য অভিপ্রেত ছিল. প্রয়োজনীয়তা আইএসও 9000-3 এবং TickIT অনুযায়ী সফটওয়্যার উন্নয়নের জন্য ব্যাখ্যা করা হয়.

সেখানে 20 প্রধান উপাদান. প্রতিটি ধারণা ভাল মানের ব্যবস্থাপনা কমিউনিটি পরিচিত.

1. ম্যানেজমেন্ট দায়িত্ব

1.1 কোয়ালিটির নীতি

মান একটি মানের নীতি, এটা বলছেন যেখানে কোম্পানী মানের পণ্য উৎপাদন করবে জারির সরবরাহকারী পরিচালনার প্রয়োজন.

মানের নীতি হইবে:
– নির্ধারণ managementâ € ™ গুলি মান অঙ্গীকার
– মানের সংক্রান্ত নির্ধারণ companyâ € ™ গুলি উদ্দেশ্য, অর্থাৎ কি ব্যবস্থাপনা মানের দ্বারা অর্থ
– Customerâ € ™ গুলি চাহিদা প্রাসঙ্গিক হতে
– প্রতিষ্ঠানের মধ্যে বোঝা যাবে
– বাস্তবায়ন করা

অ conformances

– খুব অস্পষ্ট বা নীতি বিবৃতি কর্মীদের দ্বারা বোঝা যায় না
– কোয়ালিটি নীতি বাস্তবায়িত হয়নি.

উদাহরণস্বরূপ কোয়ালিটির নীতি

একটি ¢ একটি € œWe উদ্দেশ্যমূলক এবং দক্ষ কর্মীদের মাধ্যমে মানের, সংজ্ঞায়িত কাজ পদ্ধতি, এবং নিবিড় পর্যালোচনা এবং activities.â € পরীক্ষামূলক অর্জন

1.2 অর্গানাইজেশন

মান দায়িত্ব, ক্ষমতা ও মান প্রভাবিত সব ব্যক্তিদেরকে পরস্পর সম্পর্ক ডকুমেন্টেশন প্রয়োজন. এর মানে হল যে যদি কোন ব্যক্তি একটি দায়িত্ব রয়েছে, তা আনুষ্ঠানিকভাবে উপযুক্ত ব্যবস্থাপক দ্বারা নির্ধারিত হইবে. ব্যক্তি দায়িত্ব পালন করার জন্য কর্তৃপক্ষ থাকা উচিত.

আইএসও মতে, দায়িত্ব মানে:

একটি ¢ একটি যখন কিছু toldâ € ছাড়াই কাজ করতে হবে € œa দায়িত্ব oneâ € ™ গুলি নিজের ইচ্ছায় কাজ করার জন্য.

অ অনুরূপ

– একটি দায়িত্ব যে পূরণ করা যায় না বিদ্যমান.


– প্রকল্প-লাইন
– প্রকল্প গ্রাহক
– প্রকল্প রক্ষণাবেক্ষণ সংগঠন
– সফটওয়্যার উন্নয়ন-হার্ডওয়্যার উন্নয়ন
– রক্ষণাবেক্ষণ প্রতিষ্ঠানের হেল্প ডেস্ক
– বিক্রয় উন্নয়ন

সম্পদের প্রয়োজন হয় সরবরাহকারী যে:
– সম্পদের জন্য প্রয়োজনীয়তা চিহ্নিত করুন
– প্রশিক্ষণপ্রাপ্ত ধার্য করুন.

ম্যানেজমেন্ট প্রতিনিধি কর্তৃত্ব ও দায়িত্ব ম্যানেজারের প্রতিনিধি নিয়োগের প্রয়োজন:
– নিশ্চিত করুন যে কোম্পানী ISO-9001 প্রয়োজনীয়তা পূরণ করে
– কোম্পানির ব্যবস্থাপনার মান সিস্টেমের কর্মক্ষমতা রিপোর্ট

1.3 ম্যানেজমেন্ট পর্যালোচনা

কোয়ালিটির ম্যানেজার নির্দিষ্ট সময় পর পর ফল উপস্থাপন করা উচিত
– কোয়ালিটির অডিট
– মানের অভিযোগের পরিসংখ্যান
– সংশোধনমূলক কর্মের রেকর্ডস

ফলাফল যারা উপস্থিত ছিলেন উপর নোট, তা উপস্থাপন করা হয় এবং কি সিদ্ধান্ত নেয়া হয়েছে এবং তৈরি সঙ্গে একটি রেকর্ড ব্যবস্থাপনা সভায় উপস্থাপন করা উচিত.

2. গুণ সিস্টেম

কোয়ালিটির সিস্টেম € “”একটি € œthe সাংগঠনিক কাঠামোর বিবরণ, দায়িত্ব, পদ্ধতি, প্রক্রিয়া এবং মান management.â € বাস্তবায়নের জন্য সম্পদ

পদ্ধতি, বিধি, সিদ্ধান্ত লেখা পুরা হইবে. আপনি একটি নিয়ম বা পদ্ধতি যে ISO-9001 দ্বারা প্রয়োজন হয় না ব্যবহার করে থাকেন তাহলে, মান এখনো প্রয়োজন যে শাস্ত্রে লেখা আছে.

একটি মান ম্যানুয়াল রেফারেন্স এবং মান সিস্টেম ডকুমেন্টেশন থাকিতে হইবে.

অ অনুরূপ

– একটি নিরীক্ষার একটি নমুনা হল, তাই যদি একটি নমুনা এ, সেখানে ছোটখাট অ conformances হয়, এবং তারা ঠিক করা হয়েছে, এটি এখনও একটি অ অনুরূপ হতে পারে, কারণ নিরীক্ষক সন্দেহ করতে আরো অনেক ছোটখাট অ conformances আছে.
– বিদ্যমান লিখিত পদ্ধতি অনুসরণ করা হয় না.

3. চুক্তি পর্যালোচনা

স্বাক্ষর চুক্তি করার আগে সরবরাহকারী চেক প্রতিষ্ঠানের সঞ্চালনের জন্য কি চুক্তি দ্বারা প্রয়োজন বোধ করা হয় পাবে.

প্রশ্ন জিজ্ঞাসা করা উচিত অন্তর্ভুক্ত:
– প্রয়োজনীয় তথ্যসমৃদ্ধ এবং বোঝা যায়?
– স্বীকৃতি মানদণ্ড অন্তর্ভুক্ত করা হয়?
– স্নেহপূর্ণ থেকে বিভিন্নমুখী প্রয়োজনীয় সংশোধন করা হয়েছে?
– সরবরাহকারী চুক্তি জন্য যথেষ্ট সম্পদ জড় করা যাবে?
– সরবরাহকারী কর্মদক্ষতা চুক্তির জন্য প্রয়োজন জড় করা যাবে?
– কাজের সময় সম্পন্ন করা যাবে না?

মান প্রয়োজন যে রিভিউ সঙ্গে একটি তথ্যসমৃদ্ধ পদ্ধতি অন্তর্ভুক্ত করা. সরবরাহকারী চিহ্নিত করা কিভাবে চুক্তি সংশোধনী এবং ক্রেতা ও সরবরাহকারী মধ্যে প্রয়োজনীয়তা স্পেসিফিকেশন সামলাচ্ছে সংজ্ঞায়িত করা.

4. ডিজাইন কন্ট্রোল

4.1. সাধারণ
আইএসও প্রয়োজন যে আপনি কাজ করার আগে পরিকল্পনা এবং নকশা আগে উল্লেখ করুন.

4.2. ডিজাইন এবং ডেভেলপমেন্ট প্ল্যানিং

ডিজাইন পরিকল্পনা থাকা উচিত:
– পদ্ধতি সংজ্ঞা পণ্য উন্নয়নে ব্যবহার করা হবে
– টাইম শিডিউল, দায়িত্ব, কাজ বরাদ্দকরণ এবং অগ্রগতি নিয়ন্ত্রণ
– দশা প্রকল্প বিভক্ত করা হবে. এই ইনপুট, আউটপুট এবং আউটপুট যাচাই অন্তর্ভুক্ত.
– পদ্ধতি এবং সরঞ্জামের বর্ণনা ব্যবহৃত হবে

কোয়ালিটির পরিকল্পনা থাকা উচিত:
– কোয়ালিটির লক্ষ্যমাত্রা
– গ্রহণযোগ্যতা জন্য নির্ণায়ক
– পরিকল্পনা, বৈধতা এবং যাচাই সনাক্তকারী.
– মানের কার্যকলাপের জন্য দায়িত্ব.

একটি কোম্পানী, আইএসও যোগ্যতা পরিকল্পনা সব প্রকল্পে অনুষ্ঠিত হবে নাফা থেকে আইএসও সনদ নির্দিষ্ট প্রকল্পের জন্য পুরো কোম্পানিতে এবং না চায়.

4.3 সাংগঠনিক এবং কারিগরি ইন্টারফেস

যদি সেখানে গ্রুপ-কাজ, তাদের মধ্যে ইন্টারফেস, চিহ্নিত করতে হবে নথিভুক্ত এবং তথ্য প্রয়োজন সেই প্রেরিত. ডকুমেন্টেশন নিয়মিত পর্যালোচনা করা হবে.

4.4 ডিজাইন ইনপুট

আবশ্যকতা স্পেসিফিকেশনের সফটওয়্যার উন্নয়ন নকশা ইনপুট থাকে. এই ক্রেতা দ্বারা সম্পন্ন বা সরবরাহকারী আইন এবং প্রবিধান ব্যবহার দ্বারা প্রস্তুত করা যেতে পারে. আরেকটি নকশা ইনপুট নকশা কোডিং যা কোডিং ইনপুট হিসেবে ব্যবহার করা হয় অন্তর্ভুক্ত.

মান নিশ্চিত করার জন্য প্রতিটি ধাপে কাজ পণ্যের প্রয়োজনীয়তা পূরণ চায়.

সফটওয়্যার উন্নয়ন, প্রয়োজনীয় পরিবর্তন সাধারণ তাই ক্রেতা থেকে নতুন এবং পরিবর্তিত প্রয়োজনীয়তা পরিচালনা করার জন্য একটি পদ্ধতি তৈরি করা.

4.5 ডিজাইন আউটপুট

ডিজাইন আউটপুট: নকশা ডকুমেন্টেশন এবং সোর্স কোড. আইএসও প্রয়োজন কোডিং যে নকশা নথি এবং মুক্তির আগে পর্যালোচনা করা.

নকশা আউটপুট এবং স্বীকৃতি মানদণ্ড কবুলের একটি পদ্ধতি তৈরি করা উচিত.

4.6 ডিজাইন পর্যালোচনা

কোডিং এবং পরীক্ষার মত প্রকল্প ফাংশন পর্যালোচনা উপস্থাপিত হইবে. রিভিউ নিশ্চিত করার জন্য একটি সাধারণ পদ্ধতি checklists হয়.

4.7 ডিজাইন যাচাই

এই রিভিউ, মডিউল পরীক্ষণ ইন্টিগ্রেশন পরীক্ষার নিয়ে গঠিত.

4.8 ডিজাইন ভ্যালিডেশন

ফাইনাল সিস্টেম পরীক্ষা, সম্পূর্ণ সফ্টওয়্যার পণ্য একসঙ্গে ব্যবহারকারী ডকুমেন্টেশন পর্যালোচনা সঙ্গে. সেখানে পরিকল্পনা এবং নথিভুক্ত বৈধতা দিতে হবে. বিটা টেস্টিং যতদিন বিটা টেস্টিং সরবরাহকারী এবং বিটা টেস্টিং গ্রাহকের মধ্যে একটি স্পষ্ট চুক্তি দ্বারা আচ্ছাদিত করা হয় আইএসও সঙ্গে conformance মধ্যে হয়.

4.9 নকশা পরিবর্তন

ISO-9001 প্রয়োজন যে নকশা ডকুমেন্টেশন এবং সোর্স মুক্তির পর, সমস্ত পরিবর্তন একটি আনুষ্ঠানিক প্রক্রিয়া যেখানে পরিবর্তন নথিভুক্ত করা হয় পর্যালোচনা এবং বাস্তবায়নের আগে অনুমোদন মাধ্যমে যেতে হবে.

জটিল প্রযুক্তিগত নথি বা প্রোগ্রাম অনিয়ন্ত্রিত পরিবর্তন অত্যন্ত বিপজ্জনক এবং যেমন সাধারণ হিসাবে এটা করার অনুমতি দেয় না.
5. ডকুমেন্ট এবং ডেটা কন্ট্রোল

তথ্য যে সফটওয়্যারের উন্নয়ন / রক্ষণাবেক্ষণ নিয়ন্ত্রণ করে. মান প্রয়োজন যে, যারা কিছু নথির প্রয়োজন / ডেটা অ্যাক্সেস থাকবে. নথি এবং তথ্য পরিবর্তনসমূহ নিয়ন্ত্রিত হইবে.

5.1 সাধারণ

বাহ্যিক দলিল ও তথ্য সংরক্ষণ করা হইবে. এটা কোন ফর্ম (হার্ড কপি, ইলেকট্রনিক মিডিয়া) উপর সংরক্ষণ করা যেতে পারে.

5.2 ডকুমেন্ট এবং তথ্য অনুমোদন এবং ইস্যু

ইস্যু নথি এবং তথ্য আগে পর্যালোচনা করা এবং প্রতিটি সংখ্যার আগে অনুমোদিত হইবে. একটি নথি তালিকা, যা এক একটি নথির বর্তমান সংস্করণ জানতে হইবে. অবৈধ বা অপ্রচলিত নথি সরানো উচিত বা পরিষ্কারভাবে চিহ্নিত.

5.3 ডকুমেন্ট এবং ডেটা পরিবর্তন

পর্যালোচনা ও অনুমোদনের প্রক্রিয়ার দায়িত্বপ্রাপ্ত ব্যক্তি / গুলি উল্লেখ করা হইবে.

6. ক্রয়

সাব কন্ট্রাকটরের ক্ষেত্রে, আপনি এখনও দায়ী. অর্থাত যদি আপনি একটি চুক্তি জন্য আবেদন এবং কাজ ঠিকা, আইএসও মান আপনার দায়িত্ব অধীন এখনও এবং ISO প্রয়োজনীয়তা সাব কন্ট্রাকটরের উপর আরোপ করা হবে না.

6.1 সাধারণ

জনশক্তি ক্রয় করা হয়, তাহলে মান একটি পদ্ধতি যে আপনি সঠিক ব্যক্তির পেতে অনুসরণ করা প্রয়োজন. মানুষ সরবরাহকারী এবং সাব কন্ট্রাকটরের দ্বারা নিয়ন্ত্রিত হবে.
যে ক্রয় সফ্টওয়্যার নিশ্চিত করার প্রয়োজনীয়তা কে কনর্ফাম করে
– সাবকন্ট্রাকটারের পদ্ধতি চুক্তি প্রয়োজনীয়তা
– সাব কন্ট্রাকটরের মানের সিস্টেম অডিট
– চেক গত কর্মক্ষমতা সাব কন্ট্রাকটরের
– চুক্তি সময় সাব কন্ট্রাকটরের সার্ভে
– উত্তর পর্যালোচনা এবং টেস্টিং
– টেস্ট এবং সাব কন্ট্রাকটরের পর্যালোচনা পণ্য.

Subcontractors 6.2 মূল্যায়ন

প্রয়োজনীয় ক্ষমতা ও যোগ্যতা দিয়ে ব্যক্তি প্রতিটি সাব কন্ট্রাকটরের বিচার এবং সিদ্ধান্ত ব্যবহার করতে হইবে. সিদ্ধান্ত নথিভুক্ত করা হবে.

সরবরাহকারী সিদ্ধান্ত প্রদান করিবে সাব কন্ট্রাকটরের উপর কি নিয়ন্ত্রণ এটা থাকবে. প্রমিত তোমার উচিত ছিল কত নিয়ন্ত্রণ উল্লেখ নেই. এটা শুধু উল্লেখ করেন যে একটি সিদ্ধান্ত তথ্য ব্যবহার করে তৈরি করা হবে.

একটি বিশেষ ক্ষেত্র যখন সফ্টওয়্যার খুচরো মাধ্যমে ক্রয় করা হয়. এই ক্ষেত্রে সাব কন্ট্রাকটরের সংগঠনের যা দিয়ে ক্রয় পরিচালিত হয়, না সফটওয়্যার এর মূল ডেভেলপার.

ক্রয় খুচরো আইএসও মাধ্যমে সম্পন্ন করা হয় তাহলে 9001 প্রয়োজন যে আপনি কতটুকু আপনি তার সরবরাহকারী নিয়ন্ত্রণ করতে রিটেইলার উপর প্রয়োজনীয়তা করা সংজ্ঞায়িত.

6.3 ক্রয় তথ্য

উন্নয়ন প্রক্রিয়া আবশ্যকতা কাজের ফলাফল এবং পদ্ধতি অনুমোদন করার জন্য সরবরাহকারী প্রয়োজনীয়তা সহ চুক্তি মধ্যে নথিভুক্ত করা হবে.

পণ্য ক্রয়ের 6.4 যাচাই

প্রতিটি যাচাই সম্পর্কে সিদ্ধান্তসমূহের ডকুমেন্টেশন উন্নয়ন টুল বা অন্তর্ভুক্ত পণ্য ক্রয়.
অ অনুরূপ

– অনুমোদিত সরবরাহকারী কোন তালিকা
– সাব কন্ট্রাকটরের অনুপযুক্ত নিয়ন্ত্রণ
– ক্রয় আইটেম এর কোন দস্তাবেজ যাচাইকরণ
– সাব কন্ট্রাকটরের সঙ্গে অনুপযুক্ত চুক্তি.

ক্রেতা-সরবরাহকৃত পণ্যের 7 কন্ট্রোল

সরবরাহকারী যাচাইকরণ, স্টোরেজ এবং গ্রাহকের সরবরাহকৃত সফ্টওয়্যার রক্ষণাবেক্ষণের জন্য পদ্ধতি থাকবে. তবে মানের সফ্টওয়্যার দায়িত্ব.

একটি অ অনুরূপ ক্রেতা ও সরবরাহকারী মধ্যে দায়িত্ব অস্পষ্ট দায়িত্ব কারণে ঘটে.

8 প্রোডাক্ট স্পেসিফিকেশন এবং traceability

সফটওয়্যার সরবরাহকারী উপর নিয়ন্ত্রণ রাখা উচিত:
– কি নথিতে পূর্ববর্তী এবং এটি জারি উপর ভিত্তি করে
– যা স্পেসিফিকেশন উপর ভিত্তি করে করা হয়
– কি সংশোধন এবং সংশোধনী যা সোর্স প্রোগ্রাম অন্তর্ভুক্ত করা হয়েছে
– প্রতিটি সমস্যা রিপোর্ট কি ঘটেছে
– কি উৎস থেকে একটি নির্দিষ্ট মডিউল উত্পন্ন হয়.

9 প্রক্রিয়া নিয়ন্ত্রণ

মাস্টার PROMâ € ™ গুলি / লাইব্রেরি পরিচালনার জন্য অপারেশন এবং পদ্ধতি অনুলিপিকরণ প্রক্রিয়া পদ্ধতি নথিভুক্ত. তা নিশ্চিত করার জন্য সঠিক ভার্সন ব্যবহার করা হয়.

অ অনুরূপ
– প্রতিলিপি জন্য কোন তথ্যসমৃদ্ধ পদ্ধতি
– মাস্টার PROMâ € ™ গুলি বা ডিস্কেট এর অপ্রকৃত হ্যান্ডলিং.

10 ইন্সপেকশন অ্যান্ড টেস্টিং

পরিদর্শন এবং পরীক্ষার জন্য লিখিত পদ্ধতি প্রতিরূপন সাথে কাজ করতে হবে.

অ অনুরূপ
– স্বয়ংক্রিয়ভাবে চেক PROMâ € ™ গুলি ফাংশন পরিদর্শন করা হয়েছে
– কোন পরীক্ষামূলক PROMâ € ™ গুলি পদ্ধতি নথিভুক্ত.

ইন্সপেকশন, পরিমাপ এবং টেস্ট যন্ত্রপাতি 11 কন্ট্রোল

সরবরাহকারী উপযুক্ত পরিমাপ সরঞ্জাম নির্বাচন এবং সরঞ্জাম নিয়ন্ত্রণের জন্য একটি তথ্যসমৃদ্ধ পদ্ধতি অনুসরণ করা উচিত. প্রতিটি নতুন সফ্টওয়্যার সংস্করণ পর্যাপ্ততা জন্য পরীক্ষা করা উচিত.

12 পরিদর্শন ও টেস্ট স্ট্যাটাস

বিশেষ উল্লেখ এবং প্রোগ্রাম পর্যালোচনা এবং পরীক্ষার মাধ্যমে যাচাই করা উচিত. সরবরাহকারী পদ্ধতি যাচাই না নির্দিষ্টকরণের বা প্রোগ্রাম ব্যবহার নিষিদ্ধ থাকবে.

অ অনুগ পণ্য 13 কন্ট্রোল

অ অনুগ পণ্য অনিচ্ছাকৃতভাবে ব্যবহার করা উচিত নয়. গুরুতর ত্রুটি ক্ষেত্রে দ্রুত পরিবর্তন পরিচালনা করার জন্য একটা পদ্ধতি তৈরি করা উচিত.

– নিয়ন্ত্রিত আইটেম যে অসংশোধিত ত্রুটি থাকতে চিহ্নিতকরণের পরিষ্কার
– পদ্ধতি প্রসবের পরে গ্রাহকের স্বীকৃতি প্রকাশ করা
– দ্রুত পরিবর্তন ক্ষেত্রে, এটা উল্লেখ করতে হবে
– তাই পরিবর্তিত আইটেম পর্যালোচনা সফ্টওয়্যার বাকি সমান মর্যাদা উন্নীত করা হবে.

14 কারেক্টিভ এবং প্রিভেন্টিভ অ্যাকশন

– রিপোর্ট যে প্রয়োজনীয়তা সাথে সামঞ্জস্য না কার্যকর হ্যান্ডলিং
– উন্নয়ন প্রক্রিয়ায় স্বল্প আসা ইঙ্গিত রিপোর্ট কার্যকর হ্যান্ডলিং
– সক্রিয় সংগ্রহ এবং প্রোডাক্ট ও প্রক্রিয়া অ অনুরূপ এবং প্রতিষেধক কর্ম সম্পর্কে পাওয়া তথ্য বিশ্লেষণ.

উন্নয়ন প্রক্রিয়ায় উন্নতি চালনা করা উচিত সম্মুখীন সমস্যা সম্পর্কে তথ্য.

অ অনুরূপ
– গ্রাহক অভিযোগ সঠিকভাবে না ঘাঁটা হয়েছে
– ডেফিসিয়েন্সি পাওয়া গেছে কিন্তু সংশোধিত না
– কোন পদ্ধতি নিশ্চিত করার সমস্যার বিশ্লেষণ ও সে অনুযায়ী কাজ করা হয় যে
– রিপোর্ট নিয়ম ও পদ্ধতি প্রয়োগের সঙ্গে সমস্যার জন্য কোন পদ্ধতি.

15 হ্যান্ডলিং, সংগ্রহস্থল, প্যাকেজিং, সংরক্ষণ ও বিতরণ

পিআরওএম, ডিস্ক বা অন্যান্য মাধ্যম নেভিগেশন প্রতিলিপি সফ্টওয়্যার প্রয়োগ হয়.
মিডিয়া লেবেল এবং সঠিকভাবে প্যাকেটজাত হইবে. ডেটা ব্যাক আপ করা হবে. এছাড়া অনিচ্ছাকৃত ক্ষতি থেকে সুরক্ষা প্রদান করার ক্ষমতা থাকতে হবে.

কোয়ালিটির রেকর্ডস 16 কন্ট্রোল

কোয়ালিটির কাগজপত্র দেখানোর কর্ম নিশ্চিত বা মান পরীক্ষা করার উদ্যোগ নেয়া হয়েছে. প্রমিত মানের রেকর্ডের হ্যান্ডলিং জন্য একটি পদ্ধতি আছে যে প্রয়োজন. রেকর্ড যাথাযথভাবে সংরক্ষণ করা উচিত, যাতে তারা সহজে প্রবেশযোগ্য.
অ conformances:
– মানের রেকর্ড ধরে রাখার জন্য কোন নিয়ম
– পর্যালোচনা রেকর্ড রাখা হয়
– টেস্ট রেকর্ড রাখা হয়
– মানের রেকর্ড রাখার সময়কাল সংজ্ঞায়িত করা হয় না

17 অভ্যন্তরীণ কোয়ালিটির অডিট

সেখানে একটি স্বাধীন সত্তা যে নিয়মিত সব অপারেশন যে পণ্য বা সেবার মান প্রভাবিত হতে পারে অডিট করা উচিত. এই কোম্পানির ব্যবস্থাপনা পক্ষে পরিচালিত হয়. সেখানে একটি নিরীক্ষা পরিকল্পনা করা উচিত.

অ অনুরূপ
– কোনো অডিট পরিকল্পনা
– অডিট আপ টু ডেট না পরিকল্পনা

18 প্রশিক্ষণ

কোম্পানির যে কর্মীদের নিশ্চিত করতে হবে প্রয়োজনীয় কাজের জন্য প্রশিক্ষণ দেওয়া হয়. একটা পদ্ধতি:
– প্রতিটি কর্মীরা মুখোমুখি অবস্থান নেয় জন্য প্রশিক্ষণের প্রয়োজনীয়তা চিহ্নিত
– এই ধরনের প্রশিক্ষণ প্রদান
– সব কর্মীদের প্রশিক্ষণ রেকর্ড রাখুন.

প্রশিক্ষণ নথিভুক্ত এবং যথেষ্ট হবে. যথেষ্ট দ্বারা আমরা বলতে চাচ্ছি যে ব্যক্তি একটি উচ্চ যথেষ্ট মান তার / তার কাজ সম্পাদন করতে সক্ষম হবে.

অ অনুরূপ
– পরিকল্পনা বা প্রশিক্ষণের জন্য কোন পদ্ধতি
– কোন প্রশিক্ষণ রেকর্ড
– তার কাজের জন্য সঠিক প্রশিক্ষণ গ্রহণ না.

19 পরিসেবা

সরবরাহকারী সার্ভিসিং যদি এই চুক্তিতে উল্লেখ করা হয় পদ্ধতি নথিভুক্ত থাকিবে. সফটওয়ারে এটা ত্রুটি সংশোধন ও বিতরণ সফ্টওয়্যার উন্নত হয়.

পরিবর্তন অভিযোগ এবং অনুরোধ পরিচালনা করার জন্য পদ্ধতি. সরবরাহকারী যদি এটা চুক্তিতে উল্লেখ করা হয় রক্ষণাবেক্ষণ প্রদান করতে বাধ্য নয়. পুরানো সফ্টওয়্যার জন্য রক্ষণাবেক্ষণ পদ্ধতি তৈরি করা উচিত.

অ অনুরূপ
– একটি চুক্তি ছাড়া কোনো গ্রাহকের জন্য রক্ষণাবেক্ষণ কাজ
– পুরাতন পণ্য রক্ষণাবেক্ষণের জন্য নির্দিষ্ট পদ্ধতি নথিভুক্ত করা হয় না
– রক্ষণাবেক্ষণ পর পরীক্ষার জন্য কোন পদ্ধতি.

20 পরিসংখ্যানগত প্রযুক্তি

সেখানে সংগ্রহ এবং বিভিন্ন পর্যায়ক্রমে পাওয়া যায় নি ত্রুটি সংখ্যা সম্পর্কে তথ্য বিশ্লেষণের হওয়া উচিত. সময়সীমা এবং মাইলস্টোন পূরণ করতে না পারা সম্পর্কে তথ্য বিশ্লেষণ করা উচিত.

“————————————————– ————————————————– ————————————————–

prijevod podrška:
————————————————– ————————————————– ————————————————–
ISO 9001 Dvadeset Elementi Kvaliteta

Pogled će se uzeti na zahtjeve iz ugla kompanija u razvoju softvera. ISO 9001 standard je namijenjen za prerađivačku industriju. Zahtjevi se tumače za razvoj softvera u skladu s ISO 9000-3 i TickIT.

Postoji 20 glavnih elemenata. Svaki koncept je dobro poznat u upravljanja kvalitetom zajednice.

1. Upravljanje Odgovornost

1.1 Politika kvalitete

Standard zahtijeva upravljanje dobavljača da izda politiku kvaliteta, gdje se kaže da je kompanija će proizvoditi kvalitetne proizvode.

Politika kvaliteta će:
– Odredite managementa € ™ s opredjeljenje za kvalitetu
– Odredite companyâ € ™ e ciljeve u pogledu kvalitete, to jest, ono što upravljanje znači po kvalitetu
– Budite relevantni za customerâ € ™ s potrebama
– Shvatiti u organizaciji
– Biti implementiran


– Izjava previše nejasni ili politika nije shvaćena od strane osoblja
– Politika kvaliteta se ne provodi.

Na primjer politike kvaliteta

â € œWe postizanje kvalitete kroz motivirani i stručnog kadra, definisanim procedurama rada, i intenzivne pregled i testiranje activities.â €

1.2 Organizacija

Standard zahtijeva dokumentaciju odgovornosti, autoritet i povezanost svih kadrova koji utiču na kvalitet. To znači da ako osoba ima odgovornost, ona će se formalno dodjeljuje odgovarajući menadžer. Osoba treba imati autoritet da ispuni odgovornosti.

Prema ISO, odgovornost znači:

â € OEA dužnost da djeluje na Onea € ™ s voljom kada se nešto mora da se uradi bez Tolda €.


– Postojeći od odgovornosti koja se ne može ispuniti.


– Projekt-line
– Projekt-kupac
– Organizacija projekta-održavanje
– Razvoj softvera za razvoj hardvera
– Održavanje organizacija-help desk
– Prodaja-razvoj

Resursa zahtijevaju da dobavljač:
– Identificirati zahtjeve za resursima
– Dodijeliti obučeno osoblje.

predstavnika uprave zahtijeva imenovanje predstavnika menadžer s vlasti i odgovornost da:
– Osigurati da je kompanija ispunjava uslove u ISO 9001
– Prijavi performanse sistema kvaliteta za upravljanje

1.3 Upravljanje Review

menadžer kvaliteta treba periodično predstaviti rezultate
– Kvaliteta revizije
– Statistika kvaliteta žalbi
– Evidencija korektivnih mjera

Rezultati bi trebali biti predstavljeni na snimljene upravljanje sastanak sa notama na koji je prisustvovao, što je predstavljen i šta odluke su uzeti i napravio.

2. Sistem kvaliteta

Sistem kvaliteta â € “”â € œthe organizacijske strukture, odgovornosti, postupke, procese i resurse za provođenje kvalitetne management.â €

Procedure, pravila, odluke će se staviti u pisanom obliku. Ako imate pravilo ili postupak koji se ne traži od ISO 9001, standard i dalje zahtijeva da se piše.

A kvalitetu mora sadržavati referentne i dokumentacije sistema kvaliteta.


– Revizija je uzorak, dakle ako u uzorku, postoje manji neusklađenosti, a oni su fiksne, i dalje može biti neusklađenosti jer revizor može sumnjaju da postoji još mnogo manjih neusklađenosti.
– Postojeći pisane procedure se ne poštuju.

Pregled 3. Ugovor

Provjere dobavljač prije potpisivanja ugovora da organizacija bude u stanju da izvrši ono što je potrebno ugovorom.

Pitanja koja treba postaviti su:
– Da li su zahtjevi dokumentirana i jasno?
– Da li su kriteriji prihvatljivosti uključen?
– Da li zahtjevi razlikuju od tendera riješen?
– Može li dobavljač skupiti dovoljno sredstava za ugovor?
– Može li dobavljač skupiti nadležnosti potrebne za ugovor?
– Može li se zadatak biti završen na vrijeme?

Standard zahtijeva da se dokumentirani postupak sa komentarima biti uključen. U dobavljač treba identificirati kako se definirati izmjene i dopune ugovora i rukovanje zahtjevima specifikacije između kupca i dobavljača.

4. Dizajn Control

4.1. general
ISO zahtijeva da planirate pre nego što to i odrediti prije dizajniranje.

4.2. Dizajn i planiranje razvoja

Plan dizajn treba da sadrži:
– Definicija metodologije koja će se koristiti u razvoju proizvoda
– Time rasporeda, odgovornosti, radnih zadataka i kontrola napretka
– Faze projekta će biti podijeljena. To uključuje ulaz, izlaz i verifikaciju izlaza.
– Opis metoda i alata koji se koriste

Plan kvalitete treba da sadrži:
– Kvaliteta ciljevi
– Kriteriji za prihvatljivost
– Identifikacija planiranja, validaciju i verifikaciju.
– Odgovornost za kvalitetu aktivnosti.

Ako kompanija želi da stekne ISO kvalifikacije planova mora se održati u svim projektima, jer certifikat ISO je za cijelu kompaniju, a ne za konkretne projekte.

4.3 organizacijskih i tehničkih sučelja

Ako postoji grupa-rad, interfejsi između njih treba utvrditi, dokumentirani i prenose onima kojima je potrebna informacija. Dokumentacija se redovno revidirati.

4.4 Design Ulaz

Zahtjevi specifikacije sadrže ulaz dizajn u razvoju softvera. To može biti učinjeno od strane kupca ili pripremljeni od strane dobavljača koristeći zakonima i propisima. Još jedan ulazni dizajn uključuje dizajn kodiranje koji se koristi kao ulaz za kodiranje.

Standardni želi da osigura da rad proizvod svakog koraka ispunjava uslove.

U razvoj softvera, uslov promjene su česte, tako da se stvorio postupak za rukovanje novim i promijenjenim zahtjevima iz kupca.

4.5 Dizajn izlaz

Dizajn Izlaz: projektnu dokumentaciju i izvorni kod. ISO zahtijeva da projektne dokumentacije i kodiranje se razmatrati prije puštanja na slobodu.

Treba stvoriti Postupak za prihvatanje izlaza dizajna i kriteriji prihvaćanja.

4.6 Design Review

funkcije projekta kao što su kodiranje i testiranje će biti predstavljen na pregled. Uobičajeni način za osiguravanje mišljenja su kontrolne liste.

4.7 Dizajn Verifikacija

To se sastoji od mišljenja, ispitivanja modula i testiranje integracije.

4.8 Dizajn Validacija

Završni test sistem, kompletnog softverskog proizvoda, zajedno sa razmatranje korisničke dokumentacije. Tu treba planirati i dokumentovano validaciju. Beta testiranje je u skladu sa ISO dok testiranje beta pokriven je jasan dogovor između dobavljača i kupca beta-testiranja.

4.9 Dizajn Promjene

ISO 9001 zahtijeva da nakon oslobađanja projektne dokumentacije ili izvor, sve promjene moraju proći kroz formalni proces u kojem su dokumentovani, pregledani i odobreni prije implementaciju promjena.

Nekontrolirano promjene do složenih tehničkih dokumenata ili programa su izuzetno opasni i kao takav je standard ne dozvoljava.
5. Dokument i kontrola podataka

Informacije koje kontrolira razvoj / održavanje softvera. Standard zahtijeva da oni koji trebaju neki dokument / podaci imaju pristup. Promjene dokumentima i podaci će biti pod kontrolom.

5.1 Opći

Vanjska dokumenti i podaci će biti pohranjeni. To mogu biti pohranjeni na bilo kojem obliku (na papiru, elektronski mediji).

5.2 dokumenata i usvajanje podataka i izdanje

Prije izdavanja dokumenata i podataka mora biti pregledan i odobren prije svakog pitanja. A lista dokument u kojem niko neće saznati trenutnu verziju dokumenta. Nevažeća ili zastarjele dokumente treba ukloniti ili jasno označen.

5.3 dokumenata i promjene podataka

Osoba / e zadužene za proces razmatranja i odobravanja mora biti naveden.

6. Nabava

U slučaju podizvođača, vi ste i dalje odgovorni. I.e. Ako ste se prijavili za ugovor i podugovor rad, ISO standardima je i dalje pod vaša odgovornost i ISO zahtjevi ne moraju biti nametnuta podizvođača.

6.1 Opći

Ako je radna snaga kupili, standard zahtijeva da pratite proceduru da se prave ljude. Ljudi će biti pod kontrolom dobavljača, a ne podizvođač.
Kako bi se osiguralo da kupio softver u skladu sa zahtjevima:
– Zahtjevi Ugovor o postupcima podizvođačima
– Revizija sistema kvaliteta podizvođač
– Provjerite podizvođač prošlosti performanse
– Istraživanje podizvođača tijekom ugovora
– Pregled svjedoka i testiranje
– Ispitivanja i pregled proizvoda od podizvođača.

6.2 Evaluacija podizvođača

Osoba sa potrebno ovlaštenje i nadležnost će suditi svaki podizvođača i odlučiti da li će se koristiti. Odluke moraju biti dokumentirani.

Isporučilac će odlučiti šta kontrolu nad podizvođača da će imati. Standardni ne spominje koliko kontrola bi trebalo da imate. To samo govori da je odluka treba pomoću činjenice.

Poseban slučaj je kada je softver kupljen kroz maloprodaju. U ovom slučaju podizvođača je organizacija sa kojima se vrši otkup, ne originalni developer softvera.

Ako kupuje vrši preko maloprodajnih ISO 9001 zahtijeva da odredite koliko ste stavili zahtjeve na maloprodajnom da kontroliše svoje dobavljača.

6.3 Nabava podataka

Zahtjevi na proces razvoja moraju biti dokumentovani u ugovoru, zajedno sa zahtjevima dobavljača da odobri rezultate rada i procedure.

6.4 Provjera kupljenih proizvoda

Dokumentacija odluka o verifikaciji svaku kupljenu razvojni alat ili uključeni proizvoda.

– Ne listu odobrenih dobavljača
– Neodgovarajuća kontrola podizvođača
– Ne verifikacija dokumenata kupljenih artikala
– Neodgovarajuća ugovor sa podizvođača.

7 Kontrola kupca isporučuje proizvoda

Isporučilac će imati postupke za verifikaciju, skladištenje i održavanje kupaca isporučenog softvera. Međutim, kvaliteta je odgovornost softvera.

A neusklađenosti događa zbog nejasne odgovornosti odgovornosti između kupca i dobavljača.

8 Specifikacija proizvoda i Sljedivost

Softver dobavljač treba zadržati kontrolu na:
– Na šta prethodi dokument izdaje se temelji
– Na kojem specifikacija se zasniva
– Šta ispravke i dopune su uključeni u kojem izvor programa
– Ono što se dogodilo u svakom izvještaju problem
– Iz onoga što izvor je određeni modul generira.

Kontrola 9 Process

Dokumentovana procedura za proces replikacije u radu i postupak za rukovanje master Proma € ™ s / biblioteke. Kako bi se osiguralo da se ispravna verzija se koristi.

– Ne dokumentirani postupak za replikaciju
– Nepravilno rukovanje master Proma € ™ e ili diskete.

10 inspekciju i testiranje

Pisane procedure za inspekciju i testiranje da se uradi u vezi sa replikaciju.

– Funkcija automatskog provjeru Proma € ™ s ne može biti pregledan
– Ne dokumentirani postupak za testiranje Proma € ™ s.

11 Kontrola inspekcije, za mjerenje i ispitivanje

U dobavljač treba izabrati odgovarajuće mjerne opreme i prate dokumentirani postupak za kontrolu opreme. Svaka nova verzija softvera treba testirati za dovoljnosti.

12 inspekciju i testiranje Status

Specifikacije i programi treba provjeriti kroz recenzije i testiranja. Isporučilac će imati procedure koje zabranjuju korištenje neprovjerenih specifikacijama ili programa.

13 Kontrola nesukladnih proizvoda

Neusaglašeni proizvoda ne bi trebalo koristiti nenamjerno. Treba stvoriti Postupak za rukovanje brze izmjene u slučaju kritičnih grešaka.

– Jasnu identifikaciju kontrolisanih stavke koje sadrže nekorigovane greške
– Način da dobijete prijem kupca po isporuci
– U slučaju brzih izmjena, ona mora biti dokumentovan
– Pregled tako modificirani proizvodi će biti uzdignut na isti status kao i ostali softver.

14 korektivne i preventivne akcije

– Efikasno rukovanje izvještaja koji nisu u skladu sa zahtjevima
– Efikasno rukovanje izvještaja ukazuju na kratkim dolascima u procesu razvoja
– Aktivno prikupljanje i analizu raspoloživih informacija o proizvodu i procesu neusklađenosti i preventivno djelovanje.

Informacije o probleme treba voziti poboljšanja procesa razvoja.

– Žalba potrošača nije pravilno rukuje
– Nedostatak je pronađena, ali ne i ispraviti
– Ne postupak kako bi se osiguralo da se problemi su analizirani i postupio po
– Nema procedura za prijavu poteškoća s primjenom pravila i procedure.

15 Rukovanje, skladištenje, pakovanje, očuvanje i isporuke

Odnosi se na softver kopirati na PROM, disk ili drugi medij.
Mediji moraju biti označeni i pravilno upakovane. Podaci se kopije. Tu treba biti sposobnost da pružaju zaštitu od nenamjernih oštećenja.

16 Kontrola kvalitete Records

Kvaliteta dokumenti pokazuju koje su poduzete radnje kako bi se osigurala ili provjeriti kvalitetu. Standard zahtijeva da se postupak za rukovanje kvaliteta zapisa. Zapisi treba čuvati na odgovarajući način, tako da su lako dostupni.
– Nema pravila za zadržavanje kvaliteta zapisa
– Pregled evidencije ne vode
– Evidencija Test se ne čuvaju
– Period vođenja zapisa o kvalitetu nije definiran

17 Interna kvaliteta revizije

Tu bi trebao biti nezavisni entitet koji redovno vrši reviziju svih operacija koje mogu uticati na kvalitet proizvoda ili usluge. Ove se vode u ime društva za upravljanje. Trebalo bi da postoji plan revizije.

– Nema revizije plana
– Plan revizije ne do datuma

18 Training

Kompanija treba osigurati da osoblje je obučeno za poslove potrebne. A postupak:
– Identificirati potrebe obuke za svaku poziciju osoblje
– Osigurati takvu obuku
– Vodi evidenciju o obuci svih zaposlenih.

Obuka treba dokumentovati i dovoljno. Dovoljnim mislimo da je osoba bude u stanju da obavlja njegove / njene rad na dovoljno visok standard.

– Nema procedure za planiranje i obuku
– Nema podataka za obuku
– Nije dobila odgovarajuću obuku za svoju zadatak.

19 Servisiranje

Dobavljač mora imati dokumentirane postupke za servisiranje ako je to spominje u ugovoru. U softver je o ispravci grešaka i poboljšanja isporučuje softver.

Postupci za rukovanje pritužbe i zahtjeve za izmjene. Ovaj dobavljač nije dužan osigurati održavanje ako se ne spominje u ugovoru. Procedure za održavanje starih softver treba.

– Radovi održavanja za kupca bez ugovora
– Posebni metode za održavanje starih proizvoda nije dokumentovan
– Ne postupak za testiranje nakon održavanja.

20 statističke tehnike

Ne bi trebalo biti prikupljanje i analizu podataka o broju grešaka naći u različitim fazama. Informacije o nemogućnosti da ispuni rokove i prekretnice treba analizirati.

“————————————————– ————————————————– ————————————————–

Подкрепа превод:
————————————————– ————————————————– ————————————————–
ISO 9001 Двадесет и качествени елементи

Един поглед ще бъде взето на изискванията от гледна точка на компании, разработващи софтуер. ISO 9001 стандарт е предназначен за преработващата промишленост. Изискванията са интерпретирани за разработка на софтуер в съответствие с ISO 9000-3 и TickIT.

Има 20 основни елемента. Всяка концепция е добре познат в общността за управление на качеството.

1. Управление Отговорност

1.1 Качество политика

Стандартът изисква управлението на доставчика да издаде политика на качеството, където тя казва, че компанията се произвеждат качествени продукти.

Политиката по качеството трябва да:
– Дефиниране на managementâ € ™ е ангажимент за качество
– Дефиниране на companyâ € ™ е цели по отношение на качеството, това е, какво управление означава по качество
– Да съответстват на customerâ € ™ е нужди
– Да се разбира в организацията
– Да се реализира


– Изявление твърде неясни или политика не се разбира от персонала
– Политиката за качество не се изпълнява.

Например на политиката за качество

â € œWe постигне качество чрез мотивиран и квалифициран персонал, определени процедури за работа, и интензивно преглед и тестване activities.â €

1.2 Организация

Стандартът изисква документиране на отговорност, власт и взаимодействие на всички служители, които влияят на качеството. Това означава, че ако човек има отговорност, той трябва да бъде официално назначен от съответния мениджър. Лицето трябва да има правото да изпълни отговорността.

Според ISO, отговорност означава:

â € œÃ задължение за действие на oneâ € ™ е собствено желание, когато нещо трябва да се направи, без да е toldâ €.


– Съществуващи на отговорност, която не може да бъде изпълнено.


– Проект-лайн
– Проект-клиент
– Организация на проекта за поддръжка
– Разработване на софтуер за развитие-хардуер
– Поддръжка на организацията-хелп деск
– Продажбите-развитие

Ресурси изискват, че доставчикът:
– Определяне на изискванията за ресурси
– Присвояване на обучен персонал.

Представител на ръководството изисква назначаване на мениджър представител с власт и отговорност, за да:
– Уверете се, че компанията отговаря на изискванията на ISO 9001
– Доклад за изпълнението на системата за качество на управляващо дружество,

1.3 Управление на преглед

мениджър по качеството трябва периодично да представя резултатите от
– Одити на качеството
– Статистика на жалби за качество
– записите на коригиращи действия

Резултатите трябва да бъдат представени на записана среща управление с бележки на които присъстваха, какво беше представен и какви решения са взети и направени.

2. Система за качество

Система за качество â € “”â € œthe организационната структура, отговорностите, процедурите, процесите и ресурсите за изпълнение на качеството management.â €

Процедури, правила, решения трябва да бъдат пуснати в писмена форма. Ако имате едно правило или процедура, която не се изисква от ISO 9001, стандартът изисква още, че е писано.

Наръчник по качеството трябва да съдържа препратка и документация на системата за качество.


– Одитът е проба, следователно, ако в дадена проба, има малки несъответствия, и те са фиксирани, тя все още може да бъде несъответствие, тъй като одиторът може да подозирам, че има много повече незначителни несъответствия.
– Съществуващи писмени процедури, не са спазени.

Преглед 3. Договор

Проверките на доставчика преди подписване на договора, че организацията да са в състояние да изпълняват това, което се изисква от договора.

Въпроси, които трябва да бъдат помолени да включват:
– Възможно ли е изискванията документирани и разбрани?
– Включени ли са критериите за приемане?
– Са били решени изисквания, различаващи се от офертата?
– Може ли доставчикът да събере достатъчно средства за договора?
– Може ли доставчикът да събере необходимата компетентност за договора?
– Може ли задачата да приключи навреме?

Стандартът изисква да бъдат включени документирана процедура с коментари. Доставчикът трябва да определи как да се дефинира договорни изменения и манипулиране на спецификацията на изискванията между клиент и доставчик.

4. Проектиране Control

4.1. Общ
ISO изисква да планират преди да се прави и уточни преди проектиране.

4.2. Проектиране и планиране на развитието

Дизайн план трябва да съдържа:
– Определяне на методология за използване в развитието на продукт
– Графици, отговорности, работни задачи и контрол на напредъка
– Проект фази ще бъдат разделени. Това включва вход, изход и проверка на изхода.
– Описание на методи и средства, за да бъде използвана

план за качество трябва да съдържа:
– целите за качество
– Критерии за приемливост
– Идентификация на планиране, утвърждаване и проверка.
– Отговорности за качество дейности.

Ако една компания иска да получи ISO квалификация плановете трябва да бъдат проведени във всички проекти, тъй като сертифициране по ISO е за цялата компания, а не за конкретни проекти.

4.3 организационни и технически интерфейси

Ако има група-работа, трябва да се идентифицират връзките между тях, документирани и предадени на тези, които се нуждаят от информация. Документацията трябва да се преразглежда редовно.

4.4 Design Input

Изисквания спецификации съдържат входа дизайн в разработването на софтуер. Това може да бъде направено от купувача или приготвени от доставчика, използвайки закони и разпоредби. Друг вход дизайн включва проектиране кодиране, който се използва като вход за кодиране.

Стандартът иска да гарантира, че работата продукт на всяка стъпка отговаря на изискванията.

В разработката на софтуер, промени изискване са общи, така да се създаде процедура за разглеждане на нови и променени изисквания от страна на купувача.

4.5 Design Output

Дизайн Output: проектната документация и на изходния код. ISO изисква проектни документи и кодиране да бъдат преразгледани преди освобождаването.

Следва да се създаде процедура за приемане на изхода на проектиране и критериите за приемане.

4.6 Design Review

функции проект като кодиране и тестване трябва да бъдат представени в прегледа. Един общ метод за осигуряване на мнения са контролни листове.

4.7 Design Проверка

Той се състои от ревюта, тестване модул и интеграция тестване.

4.8 Проектиране на утвърждаване

тест Final система, на пълен софтуерен продукт заедно с преразглеждането на потребителска документация. Там трябва да бъдат планирани и документирани валидиране. Бета тестване е в съответствие с ISO толкова дълго, колкото бета тестване е обхваната от ясно споразумение между доставчика и бета-тестване на клиентите.

4.9 Дизайн Промени

ISO 9001 изисква, че след освобождаването на проектна документация или източник, всички промени трябва да минават през формален процес, където са документирани, прегледани и одобрени преди прилагане на промените.

Неконтролирани промени в сложни технически документи или програми са изключително опасни и като такъв стандарт не го позволяват.
5. Документ и Control Data

Информация, която контролира развитието / поддръжка на софтуер. Стандартът изисква, че тези, които имат нужда от някакъв документ / данни трябва да имат достъп до нея. Промени в документи и данни могат да бъдат контролирани.

5.1 Обща

Външни документи и данни се съхраняват. Той може да се съхранява на всякаква форма (хартиен носител, електронен носител).

5.2 Документ и Одобряване на данни и Issue

Преди да издава документи и данни се прегледани и одобрени преди всеки въпрос. списък документ, в който един ще намери текущата версия на документа. Невалидни или остарели документи трябва да бъдат отстранени или са ясно обозначени.

5.3 Документ и промени на данните

трябва да се определи лице / а, отговарящ за процеса на преглед и одобрение.

6. Закупуване

В случай на подизпълнител, че все още сме отговорни. Т.е. ако кандидатствате за договор и да сключи договор за работа, стандарти ISO все още е под ваша отговорност и изисквания на ISO не трябва да бъдат наложени на подизпълнителя.

6.1 Обща

Ако е закупен работна ръка, стандарта изисква от вас да следват процедура, която можете да получите правилните хора. Хората ще бъдат контролирани от доставчика, а не подизпълнител.
За да се гарантира, че закупен софтуер отговаря на изискванията за:
– Изисквания Договор за процедурите за подизпълнители
– Одит на системата за качество подизпълнител
– Проверете подизпълнител минало изпълнение
– Изследване на подизпълнителя по време на договор
– Преглед на свидетелите и тестване
– Тест и преглед продукт на подизпълнител.

6.2 Оценка на Подизпълнителите

Лице с необходимата власт и компетентност ще съди всеки подизпълнител и да реши дали да се използва. Решенията трябва да бъдат документирани.

Доставчикът реши какво контрол над подизпълнител, тя ще има. Стандартът не се споменава какъв контрол трябва да има. Тя просто се споменава, че решението трябва да се направи с помощта на факти.

Специален случай е, когато софтуерът е закупен чрез търговия на дребно. В този случай подизпълнител е организация, с която се провежда покупка, не оригиналния разработчик на софтуера.

Ако покупателната се осъществява чрез ISO дребно 9001 изисква да се определи до каква степен ще ви постави изисквания за търговеца на дребно, за да контролира своя доставчик.

6.3 Закупуване на данни

Изисквания относно процеса на развитие трябва да бъдат документирани в договора, заедно с изискванията на доставчика, за да одобри резултатите от работата и процедури.

6.4 Проверка на закупения продукт

Документация на решения за проверката на всеки закупен развитие инструмент или включени продукт.

– Не списък на одобрените доставчици
– Неподходящо контрол на подизпълнител
– Не проверка на документи на закупените предмети
– Неподходящо договор с подизпълнител.

7 Контрол на Клиент-доставения продукт

Доставчикът трябва да има процедури за проверка, съхранение и поддръжка на клиентите доставя софтуер. Въпреки това, качеството е отговорност на софтуера.

Несъответствие се случва поради неясна отговорност на отговорност между клиент и доставчик.

8 Спецификация и проследяването

Доставчикът на софтуер трябва да запази контрол върху:
– На какво предходния документ и да го издаде, се основава
– На коя спецификация се основава
– Какво корекции и изменения са включени в програмите, които изходните
– Какво се случи с всеки доклад за проблем
– От кой източник е генерирана специфичен модул.

Control 9 Процес

Документирана процедура за процеса на репликация в операцията и процедурата за обработка на майстор PROMA € ™ е / библиотеки. За да се гарантира, че се използва правилно версии.

– Не документирана процедура за репликация
– Неправилното боравене с майстор PROMA € ™ е или дискети.

10 прегледи

Писмени процедури за проверка и тестване, за да се направи във връзка с репликация.

– Функция на автоматично проверка PROMA € ™ и не е бил проверяван
– Не документирана процедура за тестване PROMA € ™ ите.

11 Контрол на инспекция, измервания и изпитвания на оборудване

Доставчикът трябва да изберете подходящата измервателната апаратура и следвайте документирана процедура за контрол на оборудване. Всяка нова версия на софтуера трябва да бъдат тествани за достатъчност.

12 Проверка и изпитване Status

Спецификации и програми трябва да проверяват чрез прегледи и тестове. Доставчикът трябва да има процедури, които забраняват използването на непроверени спецификации или програми.

13 Контрол на продукти несъответстващи

Неотговарящи на изискванията продукти не трябва да се използват неволно. Следва да се създаде процедура за работа с бързи промени в случай на критични грешки.

– Ясно идентифициране на контролираните изделия, които съдържат некоригирани грешки
– Метод за предизвикване на приемане от клиент при доставката
– В случай на бързи промени, то трябва да бъде документирано
– Преглед така модифицирани елементи ще бъдат повишени до същия статут като останалата част от софтуера.

14 коригиращи и превантивни действия

– Ефективна обработка на съобщенията, че не отговарят на изискванията
– Ефективна обработка на съобщения, показващи кратки идвания в процеса на развитие
– Активно събиране и анализ на наличната информация за продукти и процеси несъответствие и превантивни действия.

Информация за възникнали проблеми трябва да шофирате подобрения на процеса на развитие.

– Жалба на клиенти, не е правилно обработени
– Увреждането е установено, но не се коригират
– Не процедура, за да се гарантира, че проблемите са анализирани и предприети действия
– Не процедура за докладване на трудности при прилагането на правила и процедури.

15 работа, съхранение, опаковане, съхраняване и Доставка

Отнася се за софтуер репликира на бала, диск или друг носител.
Media, се етикетират и опаковат правилно. Данните трябва да бъдат подкрепени. Там също трябва да бъде в състояние да осигури защита от непреднамерено увреждане.

16 Контрол на качеството Records

документи за качество показват, които са били предприети действия, за да се гарантира, или проверете качество. Стандартът изисква да е налице процедура за обработка на записи на качеството. Записите трябва да се съхраняват по подходящ начин, така че те са лесно достъпни.
– Не са правила за задържане на качествени записи
– Преглед на записите, които не се поддържат
– Записи от изпитване не се съхраняват
– Период на поддържане на качествени записи не е определена

17 Вътрешен одитите

Трябва да има независим орган, който редовно прави одит на всички операции, които могат да повлияят на качеството на продукта или услугата. Те се провеждат от името на управляващото дружество. Не трябва да има план за одит.

– Не план за одит
– Одитен план не се актуализира

18 обучение

Фирмата трябва да гарантира, че персоналът е обучен за изпълнение на задачите, необходими. Процедура за:
– Идентифициране на нуждите от обучение за всяка позиция на персонала
– Осигуряване на такова обучение
– Да се съхранява записи на обучението на всички членове на персонала.

Обучението следва да се документира и достатъчно. С достатъчно имаме предвид, че лицето да бъде в състояние да изпълнява неговата / нейната работа с достатъчно висок стандарт.

– Не са процедури за планиране или обучение
– Не са записите за обучение
– Не е получил подходящо обучение за неговата или нейната задача.

19 обслужване

Доставчикът трябва да са документирани процедури за обслужване, ако това е упоменато в договора. В софтуера е за корекции на грешки и подобрения в доставя софтуер.

Процедури за разглеждане на жалби и искания за промени. Доставчикът не е длъжен да осигури поддръжка, ако не е упоменато в договора. трябва да се правят процедури за поддръжка на стария софтуер.

– Ремонтни работи за клиенти без договор
– Специфични методи за поддържане на стария продукт не се документират
– Не процедура за тестване след поддръжка.

20 статистически техники

Не трябва да има събиране и анализ на данни за броя на грешките, открити в различните фази. Информация за невъзможността да бъдат спазени сроковете и постижения трябва да се анализира.

“————————————————– ————————————————– ————————————————–

traducció de suport:
————————————————– ————————————————– ————————————————–
ISO 9001 Elements de Qualitat Vint

Una mirada serà presa en els requisits del punt de vista de les empreses de desenvolupament de programari. norma ISO 9001 va ser destinat a la indústria manufacturera. Les qualificacions són interpretades pel desenvolupament de programari de conformitat amb la norma ISO 9000-3 i TickIT.

Hi ha 20 elements principals. Cada concepte és ben conegut en la comunitat de gestió de qualitat.

Responsabilitat 1. Gestió

1.1 Política de qualitat

La norma requereix la gestió de proveïdors per emetre una política de qualitat, on es diu que l’empresa s’haurà de produir productes de qualitat.

La política de qualitat ha de:
– Definir el compromís € ™ s managementâ a la qualitat
– Definir els objectius de la company € ™ s pel que fa a qualitat, és a dir, el que significa que la gestió de la qualitat
– Correspondre a les necessitats del € ™ s Customerâ
– S’ha d’entendre en l’organització
– Estar en pràctica

no conformitats

– Declaració massa vagues o la política no és entès pel personal
– La política de qualitat no s’ha implementat.

Per exemple. de la política de qualitat

â € œWe aconseguir qualitat a través d’un personal motivat i capacitat, procediments de treball definits, i la revisió intensiva i proves activities.â €

1.2 Organització

La norma requereix la documentació de la responsabilitat, autoritat i interrelació de tot el personal que afecten a la qualitat. Això vol dir que si una persona té una responsabilitat, que serà assignat formalment pel director apropiat. La persona ha de tenir l’autoritat per complir amb la responsabilitat.

D’acord amb la norma ISO, la responsabilitat vol dir:

â € OEA el deure d’actuar en pròpia Onea € ™ s quan alguna cosa s’ha de fer sense ser tolda €.

No conformitat

– Existent d’una responsabilitat que no pot ser complerta.


– Projecte de línia
– Projecte-client
– Organització de manteniment del projecte
– El desenvolupament de programari de desenvolupament en maquinari
– Manteniment organització-help desk
– Vendes-desenvolupament

Recursos requereixen que el proveïdor:
– Identificar les necessitats de recursos
– Assignar personal capacitat.

Representant de la direcció requereix designació de representant encarregat amb autoritat i responsabilitat de:
– Assegureu-vos que l’empresa compleix amb els requisits de la norma ISO 9001
– Informar del funcionament del sistema de qualitat de gestió de l’empresa

1.3 Revisió per la direcció

gerent de qualitat ha de presentar periòdicament els resultats de
– Auditories de qualitat
– Estadístiques de les reclamacions de qualitat
– Els registres d’accions correctives

Els resultats es presentaran en una reunió de gestió gravat amb notes sobre la qual va assistir, el que va ser presentat i quines decisions es van prendre i es va fer.

2. Sistema de Qualitat

Sistema de qualitat â € “”â € œEl estructura organitzativa, responsabilitats, procediments, processos i recursos per implementar la qualitat management.â €

Procediments, regles, les decisions seran posades per escrit. Si vostè té una regla o procediment que no és requerit per la norma ISO 9001, la norma encara requereix que està escrit.

Un manual de qualitat contindrà referència i documentació del sistema de qualitat.

No conformitat

– Una auditoria és una mostra, per tant, si en una mostra, hi ha menors no conformitats, i ells són fixos, que encara pot ser una no conformitat perquè l’auditor pot sospitar que hi ha molts més no conformitats menors.
– Els procediments existents escrita no es compleixen.

3. Revisió de Contracte

Els xecs proveïdor abans de la signatura del contracte que l’organització sigui capaç de realitzar el que es requereix en el contracte.

Les preguntes que han de plantejar-són:
– ¿Són els requisits documentats i compresos?
– ¿S’inclouen els criteris d’acceptació?
– ¿S’han resolt els requisits que difereixen de l’oferta?
– Pot el proveïdor reunir suficients recursos per al contracte?
– Pot el proveïdor de reunir les competències necessàries per al contracte?
– Pot la tasca es completarà en el temps?

La norma requereix que s’inclogui un procediment documentat amb comentaris. El proveïdor ha de determinar com es definiran les modificacions del contracte i el maneig d’especificació de requisits entre client i proveïdor.

4. Control de Disseny

4.1. General
ISO requereix que va abans de fer-ho i s’especifica abans de dissenyar.

4.2. Disseny i Desenvolupament de Planificació

pla de disseny ha de contenir:
– Definició de la metodologia a utilitzar en el desenvolupament de productes
– Els horaris, les responsabilitats, les assignacions de treball i control d’avanç
– Es dividirà projecte Fases. Això inclou l’entrada, la sortida i la verificació de la producció.
– Descripció dels mètodes i eines que s’utilitzaran

pla de qualitat ha de contenir:
– Objectius de qualitat
– Criteris d’acceptabilitat
– Identificació de la planificació, validació i verificació.
– Les responsabilitats de les activitats de qualitat.

Si una empresa vol obtenir la qualificació ISO els plans s’han de mantenir en tots els projectes, ja que la certificació ISO és per a tota l’empresa i no per a projectes específics.

4.3 Interfícies institucionals i tècnics

Si hi ha treball en grup, les interfícies entre ells han de ser identificats, documentats i es transmeten a les persones que necessiten la informació. La documentació serà revisada periòdicament.

4.4 Disseny d’entrada

especificacions de requisits contenen l’entrada per al disseny en el desenvolupament de programari. Això es pot fer pel comprador o preparada pel proveïdor mitjançant lleis i reglaments. Una altra entrada per al disseny inclou la codificació de disseny que s’utilitza com a entrada per a la codificació.

La norma vol assegurar-se que el producte de treball de cada pas compleix amb els requisits.

En el desenvolupament de programari, canvis de requisits són comuns pel que es va crear un procediment per al maneig dels nous i les noves exigències del comprador.

4.5 Disseny de sortida

Disseny de la sortida: la documentació de disseny i el codi font. ISO requereix que els documents de disseny i codificació seran revisats abans del seu alliberament.

Un procediment per a l’acceptació de la producció de disseny i criteris d’acceptació ha de ser creat.

4.6 Revisió de Disseny

Les funcions de projecte com codificació i les proves es presentaran a la revisió. Un mètode comú per assegurar crítiques són llistes de comprovació.

4.7 Verificació del disseny

Aquest consisteix en una revisió, prova de mòduls i proves d’integració.

4.8 Validació del Disseny

prova final del sistema, del producte de programari completa juntament amb la revisió de la documentació de l’usuari. No s’han de planificar i validació documentada. Les proves beta està en conformitat amb la norma ISO sempre que la prova beta està cobert per un acord clar entre el proveïdor i el client de proves beta.

4.9 Canvis de disseny

ISO 9001 requereix que després de l’alliberament de documents de projecte o de la font, tots els canvis han de passar per un procés formal on es documenten els canvis, revisats i aprovats abans de la seva implementació.

canvis no controlats als documents o programes tècnics complexos són extremadament perillós i, com a tal, la norma no ho permet.
5. Control de documents i dades

Informació que controla el desenvolupament / manteniment de programari. La norma requereix que els que necessiten algun document / dades tindrà accés. Els canvis als documents i dades han de ser controlats.

5.1 Generalitats

Els documents externs i les dades s’emmagatzemaran. Es pot emmagatzemar en qualsevol forma (en paper, mitjans electrònics).

5.2 i aprovació de documents i dades d’emissió

Abans d’emetre els documents i dades han de ser revisats i aprovats abans de cada tema. Una llista de documents en els quals un haurà esbrinar la versió actual d’un document. Els documents no vàlids o obsolets han de ser remoguts o clarament marcats.

5.3 Documents i canvis de dades

La persona / es responsable del procés de revisió i aprovació s’especificarà.

6. Compres

En el cas del subcontractista, vostè segueix sent responsable. és a dir si s’aplica per a un contracte i subcontractar la feina, les normes ISO és encara sota la seva responsabilitat i els requisits de la ISO no han de ser imposades al subcontractista.

6.1 Generalitats

Si es compra la mà d’obra, la norma requereix que se segueixi un procediment que s’obté a la gent adequada. Les persones han de ser controlats pel proveïdor i no subcontractista.
Per assegurar que el programari adquirit compleix els requisits:
– Requisits contractuals en els procediments de subcontractistes
– Auditoria del sistema de qualitat de subcontractista
– Comprovar subcontractista rendiment passat
– Enquesta de la subcontractista durant el contracte
– Opinió del testimoni i proves
– Prova i revisió del producte del subcontractista.

6.2 Avaluació de subcontractistes

Persona amb autoritat i competència necessària jutjarà cada subcontractista i decidir si s’ha d’utilitzar. Les decisions han de ser documentats.

El proveïdor ha de decidir el que el control sobre els subcontractistes que tindrà. La norma no esmentar la quantitat de control que ha de tenir. Simplement esmenta que una decisió s’ha de fer mitjançant l’ús de fets.

Un cas especial és quan el programari s’adquireix a través de venda al detall. En aquest cas és subcontractista organització amb la qual es porta a terme la compra, no el desenvolupador original del programari.

Si la compra es realitza a través de la norma ISO 9001 requereix menor que defineixi en quina mesura es posa requisits sobre el minorista per controlar el seu proveïdor.

6.3 Dades de compres

Requisits en procés de desenvolupament han de ser documentats en el contracte juntament amb els requisits del proveïdor per aprovar els resultats i procediments de treball.

6.4 Verificació del producte comprat

La documentació de les decisions sobre la verificació de cadascun va comprar eina de desenvolupament o producte inclòs.
No conformitat

– No hi ha una llista de proveïdors aprovats
– El control inadequat del subcontractista
– No hi ha verificació de documents dels articles comprats
– Contracte inadequada amb subcontractista.

7 Control del Producte subministrat pel client

El proveïdor ha de tenir procediments per a la verificació, emmagatzematge i manteniment de programari subministrat pel client. No obstant això, la qualitat és responsabilitat del programari.

Una no conformitat ocorre a causa de la responsabilitat poc clara de les responsabilitats entre client i proveïdor.

8 Especificació de producte i traçabilitat

El proveïdor de programari de mantenir el control sobre:
– Pel que precedeix document i emetre que es basa
– En què especificació es basa
– Què correccions i modificacions s’han inclòs en els programes de codi que
– Què va passar amb cada informe de problemes
– ¿De quina font es va generar un mòdul específic.

Control de procés setembre

procediment documentat per al procés de replicació en l’operació i el procediment per a la tramitació de € ™ s Proma mestre / biblioteques. Per assegurar que s’utilitza el control de versions correctes.

No conformitat
– No existeix un procediment documentat per a la replicació
– El maneig inadequat dels disquets ™ € s Proma mestre o.

10 Inspecció i proves

Els procediments escrits per a la inspecció i proves a realitzar en relació amb la replicació.

No conformitat
– Funció de control automàtic de Proma € ™ s no ha estat inspeccionada
– No existeix un procediment documentat per provar Proma € ™ s.

11 El control d’inspecció, mesurament i assaig

El proveïdor ha de seleccionar l’equip de mesurament apropiat i segueixi un procediment documentat per al control de l’equip. Cada nova versió del programari ha de ser provat per suficiència.

12 Inspecció i estat de la prova

Les especificacions i els programes han de verificat mitjançant exàmens i proves. El proveïdor ha de tenir procediments que prohibeixen l’ús de les especificacions o els programes no verificades.

13 Control del producte no conforme

Els productes no conformes no han de ser utilitzats sense voler. Un procediment per al maneig de modificacions ràpides en cas d’errors crítics ha de ser creat.

– Identificació clara dels articles controlats que contenen errors no corregits
– Mètode per provocar l’acceptació del client al lliurament
– En cas de modificacions ràpides, ha de ser documentada
– Revisió dels articles modificats de manera serà elevat a mateix estatus que la resta del programari.

14 accions correctives i preventives

– El maneig eficaç de les denúncies que no s’ajusten als requisits
– El maneig eficaç dels informes que indiquen curt-anades en el procés de desenvolupament
– Recollida i anàlisi de la informació disponible sobre el producte i el procés de no conformitat i les mesures preventives actiu.

Informació sobre els problemes trobats han d’impulsar les millores del procés de desenvolupament.

No conformitat
– Indicació de l’usuari no ha estat manejat adequadament
– La deficiència s’ha trobat però no corregit
– No existeix un procediment per garantir que els problemes s’analitzen i actuar en conseqüència
– No existeix un procediment per informar dificultats amb l’aplicació de normes i procediments.

15 Manipulació, emmagatzematge, embalatge, conservació i lliurament

S’aplica al programari replicat a PROM, disc o un altre mitjà.
Els mitjans de comunicació han d’estar etiquetats i envasats correctament. Les dades han de ser recolzats. Hauria d’estar també la capacitat de proporcionar protecció contra el dany no intencionat.

16 El control dels registres de Qualitat

Documents de qualitat mostren la qual s’han pres mesures per a garantir o verificar la qualitat. La norma requereix que hi hagi un procediment per al maneig de registres de qualitat. Els registres han de ser emmagatzemats de manera adequada pel que són fàcilment accessibles.
No conformitats:
– No hi ha regles per a la retenció de registres de qualitat
– Revisar els registres no es mantenen
– Els registres de prova no es mantenen
– Període de mantenir registres de la qualitat no està definit

Les auditories de qualitat intern 17

No ha d’haver una entitat independent que audita regularment totes les operacions que puguin afectar la qualitat del producte o servei. Aquests es duen a terme en nom de la gestió de l’empresa. Hi ha d’haver un pla d’auditoria.

No conformitat
– No hi ha un pla d’auditoria
– Pla d’auditoria no estan al dia

18 Formació

Companyia s’ha d’assegurar que el personal està capacitat per a les tasques requerides. Un procediment per a:
– Identificar les necessitats de formació per a cada lloc
– Proporcionar aquesta formació
– Mantenir registres de la formació de tots els membres del personal.

La capacitació ha de ser documentada i suficient. Per suficient volem dir que la persona sigui capaç de realitzar la seva / la seva tasca a un nivell prou alt.

No conformitat
– No hi ha procediments per a la planificació o la formació
– No hi ha registres de formació
– No s’ha rebut una formació adequada per a la seva tasca.

19 Prestació de serveis

Proveïdor ha de tenir procediments documentats per al servei si això s’esmenta en el contracte. En el programari es tracta de correccions d’errors i millores de programari lliurat.

Procediments per al maneig de queixes i sol·licituds de modificacions. El proveïdor no està obligat a proporcionar manteniment si no s’esmenta en el contracte. s’han de fer procediments de manteniment de programari antic.

No conformitat
– Els treballs de manteniment per a un client sense contracte
– Els mètodes específics per al manteniment del producte vell no està documentada
– No existeix un procediment per a les proves després del manteniment.

20 Tècniques Estadístiques

No ha d’haver recopilació i l’anàlisi de les dades sobre el nombre d’errors trobats en les diferents fases. Informació sobre la incapacitat de complir amb els terminis i fites ha ser analitzat.

“————————————————– ————————————————– ————————————————–

Support hubad:
————————————————– ————————————————– ————————————————–
ISO 9001 Kawhaag Quality elemento

Ang usa ka tan-aw nga gikuha sa mga kinahanglanon gikan sa panglantaw sa mga kompanya pagpalambo sa software. ISO 9001 nga sumbanan gituyo alang sa industriya sa manufacturing. Ang mga kinahanglanon nga hubaron alang sa software development sumala sa ISO 9000-3 ug TickIT.

Adunay 20 nag-unang mga elemento. Ang matag konsepto maayo ang nailhan sa komunidad nga kalidad sa pagdumala.

1. Management Responsibilidad

1.1 Kalidad palisiya

Ang sumbanan nagkinahanglan sa supplier sa pagdumala sa isyu sa usa ka kalidad nga palisiya, diin kini nag-ingon sa mga panon sa nga og kalidad nga mga produkto.

Ang kalidad palisiya ang:
– Nagpaila ang managementâ € ™ sa pasalig ngadto sa kalidad nga
– Nagpaila ang companyâ € ™ s tumong bahin sa kalidad, nga mao, unsa ang pagdumala sa nagpasabot sa kalidad nga
– Mahimong may kalabutan sa customerâ € ™ s panginahanglan
– Pag-nakasabut sa organisasyon
– Mag-implementar


– Pamahayag kaayo klaro o palisiya dili masabtan sa sungkod
– Quality palisiya dili implementar.

E.g. sa Quality palisiya

â € œWe makab-ot sa kalidad nga pinaagi sa nadasig ug hanas nga sungkod, gihubit pamaagi sa trabaho, ug sa intensive review ug pagsulay activities.â €

1.2 Organization

Ang sumbanan nagkinahanglan dokumentasyon sa responsibilidad, awtoridad ug sa relasyon sa sa tanan nga mga personahe nga naka-apekto sa kalidad nga. Kini nagpasabot nga kon ang usa ka tawo adunay usa ka responsibilidad, kini pormal nga gitudlo sa tukma nga manager. Ang tawo kinahanglan nga adunay awtoridad sa pagtuman sa responsibilidad.

Sumala sa ISO, responsibilidad nagpasabot:

â € œa katungdanan sa pagbuhat sa oneâ € ™ s kaugalingon sa diha nga ang usa ka butang ang kinahanglan nga pagabuhaton nga walay toldâ €.


– Ang kasamtangan nga sa usa ka responsibilidad nga dili matuman.


– Project-linya
– Project-customer
– Project-maintenance organisasyon
– Software development-hardware development
– Maintenance organisasyon-tabang desk
– Sales-development

Resources nagkinahanglan nga ang supplier:
– Ilha ang mga kinahanglanon alang sa mga kapanguhaan
– Sanguni nabansay sa mga personahe.

Management representante nagkinahanglan sa appointment sa manager representante uban sa awtoridad ug responsibilidad sa:
– Pagsiguro nga ang kompaniya nagtuman sa mga kinahanglanon sa ISO 9001
– Isumbong ang performance sa sistema sa kalidad nga sa pagdumala sa panon sa

1.3 Management Review

Quality manager kinahanglan matag pagpresentar sa resulta sa
– Quality awdit
– Statistics sa kalidad nga mga reklamo
– Records corrective aksyon

Ang resulta sa kinahanglan nga gipresentar sa usa ka narekord nga miting sa pagdumala sa uban sa mubo nga mga sulat sa ibabaw sa nga mitambong, ang gipresentar ug unsa nga mga desisyon gikuha ug gihimo.

2. Quality System

Quality sistema â € “”â € œthe organisasyonal nga gambalay, mga responsibilidad, mga pamaagi, mga proseso ug mga kapanguhaan alang sa pagpatuman sa kalidad nga management.â €

Pamaagi, mga lagda, mga desisyon nga gibutang sa pagsulat. Kon ikaw adunay usa ka lagda o pamaagi nga dili gikinahanglan sa ISO 9001, ang bandila sa gihapon nagkinahanglan nga kini nahisulat.

Usa ka manwal sa kalidad nga naglakip pakisayran ug dokumentasyon sa sistema sa kalidad nga.


– Ang usa ka audit mao ang usa ka sample, busa kon usa ka sample, may mga menor de edad nga non-conformances, ug sila malig-on, mahimo gihapon kini nga usa ka non-conformance tungod kay ang auditor mahimo nagduda nga adunay daghan pa nga menor de edad nga dili-conformances.
– Kasamtangan nga sinulat nga pamaagi dili gisunod.

3. Contract Review

Ang supplier tseke sa atubangan sa pagpirma kontrata nga ang organisasyon nga makahimo sa pagbuhat sa unsay gikinahanglan sa kontrata.

Mga pangutana nga kinahanglan nga nangutana naglakip sa:
– Ang mga kinahanglanon documented ug nasabtan?
– Ang naglakip sa pagdawat criteria?
– Wala mga kinahanglanon nga nagkalainlain gikan sa malumo nga masulbad?
– Ang mga supplier madasig igo nga mga kapanguhaan alang sa mga kontrata?
– Ang mga supplier makabaton sa katakus nga gikinahanglan alang sa kontrata?
– Mahimo nga ang buluhaton nga mahuman sa panahon?

Ang sumbanan nagkinahanglan nga ang usa ka documented pamaagi uban sa mga reviews nga naglakip. supplier kinahanglan sa pag-ila kon sa unsang paagi nga kontrata amendments ug pagdumala sa mga kinahanglanon sa paghingalan sa taliwala sa customer ug sa supplier nga gihubit.

4. Design Control

4.1. Kinatibuk-ang
ISO nagkinahanglan nga magplano kamo sa atubangan sa pagbuhat ug hingalan sa atubangan pagdesinyo.

4.2. Design ug Development Planning

Design nga plano kinahanglan nga naglakip sa:
– Sa kahulogan sa pamaagi nga gigamit sa pagpalambo sa produkto
– Oras iskedyul, mga responsibilidad, nga buhat sa mga buluhaton ug pag-uswag sa pagpugong
– Guya sang proyekto mabahin. Kini naglakip sa input, output ug verification sa output.
– Description sa mga pamaagi ug mga himan nga gamiton

Quality plano kinahanglan nga naglakip sa:
– Quality target
– Criteria alang sa madawat
– Pag-ila sa pagplano, validation ug verification.
– Responsibilidad alang sa kalidad nga mga kalihokan.

Kon ang usa ka kompanya nga gusto nga sa pag-angkon ISO kwalipikasyon sa mga plano kinahanglan nga gihimo sa tanan nga mga proyekto, kay ISO certification alang sa tibuok panon, ug dili alang sa piho nga mga proyekto.

4.3 organisasyon ug Technical interface

Kon adunay grupo-trabaho, ang interface sa taliwala kanila kinahanglan nga giila, documented ug transmitted ngadto sa mga nagkinahanglan sa impormasyon. dokumentasyon ang nga review sa kanunay.

4.4 Design Input

Kinahanglanon specifications naglangkob sa mga disenyo input sa software development. Kini mahimo pinaagi sa mamalitay o giandam sa supplier sa paggamit sa mga balaod ug regulasyon. Laing design input naglakip sa design coding nga gigamit ingon nga input sa coding.

Ang sumbanan nga gusto aron sa pagsiguro nga ang buhat produkto sa matag lakang magtigum sa mga kinahanglanon.

Sa software development, kinahanglanon mga kausaban komon sa ingon sa usa ka pamaagi alang sa pagdumala sa bag-o ug nausab nga mga kinahanglanon gikan sa mamalitay nga gibuhat.

4.5 Design Output

Design Output: sa disenyo dokumento ug sa source code. ISO nagkinahanglan nga disenyo mga dokumento ug mga pagyawi nga review sa atubangan sa pagpagawas.

Usa ka pamaagi alang sa pagdawat sa mga disenyo output ug criteria sa pagdawat kinahanglan nga gibuhat.

4.6 Desinyo Review

Project gimbuhaton sama sa coding ug pagsulay nga gipresentar sa review. Usa ka komon nga paagi sa pagsiguro reviews mga checklist.

4.7 Desinyo Verification

Kini naglangkob sa mga reviews, module testing ug integration testing.

4.8 Desinyo validation

Final sistema sa pagsulay, sa bug-os nga produkto software uban sa pagribyu sa user dokumento. Adunay kinahanglan nga giplano ug dokumentado validation. Beta testing anaa sa conformance sa ISO samtang sa beta testing gitabonan sa usa ka tin-aw nga kasabutan tali sa supplier ug beta-testing customer.

4.9 Desinyo mga Kausaban

ISO 9001 nagkinahanglan nga human sa pagpagawas sa disenyo dokumento o tinubdan, ang tanan nga mga kausaban moadto pinaagi sa usa ka pormal nga proseso diin ang mga kausaban sa mga documented, review ug aprobahan sa atubangan sa pagpatuman.

Walay pugong nga kausaban sa komplikado teknikal nga mga dokumento o mga programa mao ang hilabihan delikado nga ug sa ingon ang bandila dili motugot niini.
5. Document ug Data Control

Impormasyon nga nagkontrolar sa kalamboan / maintenance sa software. Ang sumbanan nagkinahanglan nga ang mga tawo nga nagkinahanglan sa pipila ka mga dokumento / data sa adunay access sa niini. Kausaban sa mga dokumento ug mga data nga kontrolado.

5.1 Kinatibuk-ang

Gawas nga dokumento ug mga data nga gitipigan. Kini mahimong gitipigan sa bisan unsa nga matang (malisud nga kopya, electronic media).

5.2 Document ug Data Pag-uyon ug sa Isyu

Sa wala pa nga isyu dokumento ug mga data nga review ug aprobahan sa atubangan sa matag isyu. Usa ka listahan sa dokumento nga usa sa pagsusi sa kasamtangan nga bersyon sa usa ka dokumento. Balido o obsolete mga dokumento kinahanglan nga gikuha o tin-aw nga gimarkahan.

5.3 Dokumento ug data mga Kausaban

Ang tawo / s sa katungdanan sa pagbantay sa mga proseso sa pagtuon ug sa pag-uyon nga bungat.

6. pagpalit

Sa kaso sa mga puli sa kontraktor nga, ikaw sa gihapon responsable. Pananglitan kon imong ipadapat ang alang sa usa ka kontrata ug subcontract sa buhat, ISO nga mga sumbanan mao ang pa sa ilalum sa imong responsibilidad ug ISO mga kinahanglanon dili nga ipahamtang sa puli sa kontraktor nga.

6.1 Kinatibuk-ang

Kon manpower gipalit, ang sumbanan nga nagkinahanglan kanimo sa pagsunod sa usa ka pamaagi nga imong makuha sa matarung nga mga tawo. Ang mga tawo nga kontrolado sa supplier ug dili puli sa kontraktor nga.
Aron sa pagsiguro nga gipalit software nahiuyon sa mga kinahanglanon:
– Contract mga kinahanglanon sa mga pamaagi subcontractors
– Audit sa sistema sa puli sa kontraktor nga kalidad nga
– Check puli sa kontraktor nga nangagi nga performance
– Ang survey puli sa kontraktor nga sa panahon sa kontrata
– Saksi review ug testing
– Test ug review produkto sa puli sa kontraktor nga.

6.2 Evaluation sa subcontractors

Persona uban sa gikinahanglan nga awtoridad ug katakus magahukom sa matag puli sa kontraktor nga ug modesisyon kon sa paggamit sa. Ang mga desisyon nga documented.

supplier Ang ang mohukom kon unsa ang kontrol sa puli sa kontraktor nga kini adunay. Ang sumbanan wala maghisgot kon sa unsang paagi sa daghan nga pagkontrolar sa kinahanglan nga kamo adunay. Kini lang naghisgot nga ang usa ka desisyon nga kinahanglan nga pagahimoon pinaagi sa paggamit sa kamatuoran.

Usa ka espesyal nga kaso mao ang sa diha nga ang software gipalit pinaagi sa retail. Sa kini nga kaso puli sa kontraktor nga mao ang organisasyon nga sa pagpalit nga gipahigayon, dili ang orihinal nga developer sa software.

Kon pagpalit ang gibuhat pinaagi sa retail ISO 9001 nagkinahanglan nga nagpaila kaninyo sa unsa nga gidak-on mo sa mga kinahanglanon sa mga mamaligyaay sa pagpugong sa iyang supplier.

6.3 pagpalit og Data

Kinahanglanon sa proseso development nga dokumentado sa kontrata uban sa mga kinahanglanon sa supplier nga mouyon sa mga resulta sa trabaho ug mga pamaagi.

6.4 Verification sa gipalit Product

Dokumentasyon sa mga desisyon mahitungod sa verification sa matag gipalit development himan o naglakip sa produkto.

– Walay listahan sa aprobahan suppliers
– Ang dili angay nga kontrol sa puli sa kontraktor nga
– Walay dokumento verification sa gipalit nga mga butang
– Ang dili angay nga kontrata sa puli sa kontraktor nga.

7 Control sa Customer-supplied Product

supplier Ang adunay mga pamaagi alang sa verification, storage ug maintenance sa customer supplied software. Apan, ang kalidad mao ang responsibilidad sa mga software.

Ang usa ka dili-conformance mahitabo tungod sa klaro nga responsibilidad sa responsibilidad tali sa customer ug sa supplier.

8 Product paghingalan ug Traceability

Ang software supplier unta sa pagpugong sa sa:
– Sa unsa nag-unang dokumento ug isyu kini base
– Sa nga paghingalan kini base
– Unsa nga mga koreksyon ug kausaban nga naglakip sa nga tinubdan sa mga programa
– Unsa ang nahitabo sa matag report nga problema
– Gikan sa unsa nga tinubdan sa usa ka piho nga module nga namugna.

9 Process Control

Documented pamaagi alang sa proseso sa pagsubli-subli sa operasyon ug pamaagi alang sa pagdumala sa agalon PROMâ € ™ s / librarya. Aron sa pagsiguro nga husto nga versioning gigamit.

– Walay documented pamaagi alang sa pagkopya
– Sayop nga pagdumala sa agalon PROMâ € ™ o diskettes.

10 Inspection ug Pagsulay

Sinulat nga mga pamaagi alang sa pagsusi ug testing nga pagabuhaton labot sa pagkopya.

– Function sa awtomatikong pagsusi PROMâ € ™ s wala inspeksyon
– Dili documented pamaagi alang sa pagsulay PROMâ € ™ s.

11 Control sa Inspection, Pagsukod ug Test ekipo

supplier kinahanglan pagpili sa angay nga igsusukod nga mga ekipo ug mosunod sa usa ka documented pamaagi alang sa pagkontrolar sa mga ekipo. Ang matag bag-o nga bersyon software kinahanglan nga gisulayan sa sufficiency.

12 Inspection ug Test Status

Specifications ug mga programa kinahanglan nga matuoron ang pinaagi sa mga reviews ug sa testing. supplier Ang adunay mga pamaagi nga nagdili sa paggamit sa wala mapamatud-i specifications o programa.

13 Control sa Non-pagpahiuyon Product

Non-pagpahiuyon mga produkto kinahanglan nga dili gamiton nga wala tuyoa. Usa ka pamaagi sa pagdumala dali kausaban sa kaso sa kritikal nga mga sayop kinahanglan nga gibuhat.

– Tin-aw nga pag-ila sa mga kontrolado nga mga butang nga naglakip sa indi husto nga mga sayop
– Pamaagi aron ipagawas sa customer nga pagdawat sa ibabaw sa delivery
– Sa kaso sa dali kausaban, kini kinahanglan nga documented
– Ang pagribyu sa ingon giusab butang nga taas ngadto sa sama nga kahimtang sa ingon nga uban sa software.

14 corrective ug preventive Action

– Epektibo pagdumala sa mga taho nga dili mahiuyon sa mga kinahanglanon
– Epektibo pagdumala sa mga taho nga nagpakita mubo-pagsulod sa development sa proseso
– Aktibo nga koleksyon ug pagtuki sa impormasyon mahitungod sa produkto ug proseso non-conformance ug preventive nga mga lihok.

Impormasyon mahitungod sa mga problema nga nasinati kinahanglan magapapahawa kalamboan sa proseso sa kalamboan.

– Customer reklamo wala sa tukma nga paagi sa pagdumala
– Kakulangan nga nakit apan dili id
– Walay pamaagi aron sa pagsiguro nga ang mga problema sa mga analisar ug milihok diha sa ibabaw
– Walay pamaagi alang sa pagtaho sa mga kalisdanan uban sa pagpadapat sa mga lagda ug mga pamaagi.

15 Pagdumala sa, Pagtipig, Packaging, Preservation ug Delivery

Mapadapat sa software maawat sa saad, disk o sa uban nga medium.
Media nga gimarkahan ug packaged sa husto nga paagi. Data nga gipaluyohan sa. Kinahanglan usab nga ang abilidad sa paghatag og panalipod gikan sa wala tuyoa nga kadaot.

16 Control sa Quality Records

Quality dokumento sa pagpakita nga mga buhat nga gikuha aron sa pagsiguro o check sa kalidad nga. Ang sumbanan nagkinahanglan nga adunay usa ka pamaagi sa pagdumala sa kalidad nga mga rekord. Ang mga talaan kinahanglan nga gitipigan sa usa ka angay nga paagi mao nga sila sayon nga accessible.
– Walay lagda alang sa paghawid sa kalidad nga mga rekord
– Ribyuha mga rekord sa mga wala magbantay sa
– Test mga rekord sa mga wala magbantay sa
– Panahon sa pagtuman sa kalidad nga mga rekord wala gihubit

17 Internal Quality awdit

Adunay kinahanglan nga usa ka independenteng kompaniya nga regular nga pag-audit sa tanan nga mga operasyon nga makaapekto produkto o sa pag-alagad nga kalidad. Kini nga gipahigayon alang sa pagdumala sa panon. Adunay kinahanglan nga usa ka audit nga plano.

– Walay audit nga plano
– Audit nga plano dili sa petsa

18 Training

Company kinahanglan sa pagsiguro nga ang sungkod nga gibansay alang sa mga buluhaton nga gikinahanglan. Usa ka pamaagi sa:
– Pag-ila sa mga panginahanglan sa pagbansay alang sa matag posisyon sa staff
– Paghatag og sa maong pagbansay-bansay
– Padayon sa mga rekord sa mga pagbansay-bansay sa tanang mga sakop sa staff.

Pagbansay sa kinahanglan nga dokumentado ug igo. Pinaagi sa igo kita nagpasabot nga ang tawo nga makahimo sa pagbuhat sa iyang / sa iyang buhat ngadto sa usa ka igo nga taas nga sumbanan.

– Walay pamaagi alang sa pagplano o pagbansay
– Walay rekord sa pagbansay sa
– Dili nakadawat hustong training alang sa iyang tahas.

19 Servicing

Supplier na documented nga mga pamaagi alang sa serbisyo kon kini gihisgotan sa kontrata. Sa software kini mao ang bahin sa mga koreksyon sa sayop ug mga enhancements sa gitugyan software.

Mga pamaagi sa pagdumala sa mga reklamo ug mga hangyo alang sa mga kausaban. supplier wala obligado sa paghatag og maintenance kon kini dili nga gihisgotan diha sa kontrata. Maintenance mga pamaagi alang sa daan nga software kinahanglan nga gihimo.

– Maintenance nga buhat alang sa usa ka customer nga walay usa ka kontrata
– Piho nga mga pamaagi alang sa maintenance sa mga daan nga produkto dili dokumentado
– Walay pamaagi alang sa pagsulay human sa maintenance.

20 Statistical Techniques

Adunay kinahanglan nga koleksyon ug pagtuki sa mga impormasyon mahitungod sa gidaghanon sa mga sayop nga makita diha sa lain-laing mga hugna. Impormasyon mahitungod sa kawalay katakos sa pagsugat deadlines ug mga milestones kinahanglan nga analisar.

“————————————————– ————————————————– ————————————————–

Support kumasulira:
————————————————– ————————————————– ————————————————–
ISO 9001 makumi Quality Zochitika

Kuyang’ana A adzatengedwa pa zofunika kuti anthu a makampani osauka software. ISO 9001 muyezo chinali choti makampani opanga. zofunika amatha kumasulidwa kwa mapulogalamu chitukuko malinga ndi ISO 9000-3 ndi TickIT.

Pali 20 pali mfundo. Aliyense mfundo ziri zodziwika bwino mu dera khalidwe kasamalidwe.

Udindo 1. Management

1.1 policy Quality

muyezo amafuna kasamalidwe katundu kukhazikitsa ndondomeko quality, kumene akuti kampani adzakhala kupanga mankhwala khalidwe.

The ndondomeko khalidwe mudzazichita:
– Chimatanthauza managementâ mâ € ™ kudzipereka kwa khalidwe
– Kutanthauzira zolinga companyâ mâ € ™ nkhani quality, kuti zimene kasamalidwe zikutanthauza ndi khalidwe
– Khalani zogwirizana zosowa customerâ mâ € ™
– Kuzindikiridwa gulu
– Khalani akuyendera


– Statement kwambiri chabe kapena ndondomeko ndi sanamvetsetse ndi ndodo
– Policy Quality si akuyendera.

Mwachitsanzo la ndondomeko Quality

â € œWe kukwaniritsa khalidwe kudzera ndodo chinachititsa ndi waluso, kumatanthauza njira ntchito, ndi review kwambiri ndi zosowa activities.â €

1.2 Organization

muyezo amafuna zolembedwa za udindo, ulamuliro ndi interrelation wa onse zikukhudza khalidwe. Izi zikutanthauza kuti ngati munthu ali ndi udindo, chidzapatsidwa yokhala anatumidwa ndi bwana yoyenera. munthu akhale ndi ulamuliro kukwaniritsa udindo.

Malinga ndi ISO, udindo zikutanthauza:

â € œa ntchito kuchita oneâ mâ € ™ mtima kwanga pamene chinachake chiyenera kuti chichitike popanda toldâ €.


– Ilipo a udindo amene sangathe kukwaniritsidwa.


– Project Intaneti
– Project-kasitomala
– Project-yokonza gulu
– Mapulogalamu chitukuko-hardware chitukuko
– Kukonzanso gulu thandizo desiki
– Sales-chitukuko

Resources amafuna kuti katundu ndi:
– Kupeza zofunika kuti chuma
– Perekani ogwira ophunzitsidwa.

woimira Management amafuna poika woimira bwana ndi ulamuliro ndi udindo:
– Kuonetsetsa kuti kampani akukwaniritsa ziyeneretso mu ISO 9001
– Nenani ntchito a dongosolo khalidwe kasamalidwe kampani

1.3 Management Review

bwana Quality ayenera nthawi mupereke zotsatira za
– Quality audits
– Kafukufuku wa madandaulo khalidwe
– Records kanthu kukonza

Zotsatira ziziperekedwa pa analemba kasamalidwe msonkhano ndi zolemba pa amene anapezeka, zimene anapereka ndi mfundo zanji anatengedwa ndipo anapanga.

2. System Quality

dongosolo Quality â € “”â € œthe dongosolo la gulu, ntchito, ndondomeko, njira ndi zipangizo kuti atsatire khalidwe management.â €

Ndondomeko, malamulo, zigamulo adzakhala polemba. Ngati muli ndi ulamuliro kapena ndondomeko amene safunika ndi ISO 9001, muyezo amafuna kuti kwalembedwa.

A Buku khalidwe adzakhala ali Buku ndi zolembedwa za dongosolo khalidwe.


– Kafukufuku An ndi chitsanzo chake ngati chitsanzo, pali zazing’ono sanali conformances, ndipo anakakonza, komabe kungakhale sanali conformance chifukwa Auditor akhoza akuganiza kuti pali zambiri zazing’ono sanali conformances.
– Ilipo olembedwa njira si Pamilunguyo.

3. mgwilizano Review

The macheke katundu pamaso kusaina mgwirizano bungwe la athe kuchita zimene amafuna mgwirizano.

Mafunso ayenera anafunsa monga:
– Kodi zofunika zalembedwa ndi zomveka bwino?
– Kodi i kuvomereza m’gulu?
– Kodi malamulo kusiyana aang’ono ndiyakuti?
– Kodi katundu wolimba chuma chokwanira mgwirizano?
– Kodi katundu anasonkhanitsa yamtunduwu zofunika mgwirizano?
– Kodi ntchito ithe pa nthawi?

muyezo amafuna kuti zalembedwa ndondomeko ndemanga m’gulu. The katundu ayenera kudziwa mmene kusinthidwa mgwirizano ndi kusamalira zofunika mfundo pakati makasitomala ndi katundu amawamasulira.

4. Design Control

4.1. General
ISO amafuna kuti mukufuna kuti achite ndi mwachindunji pamaso angagwiritse.

4.2. Design ndi Development Planning

Design dongosolo ayenera muli:
– Tanthauzo la njira kuti ntchito zachitukuko cha mankhwala
– Time ndandanda, udindo, ntchito ndi ulamuliro patsogolo
– Magawo ntchito adzagawanika. Izi zikuphatikizapo athandizira, linanena bungwe ndi kutsimikizira linanena bungwe.
– Kufotokozera za njira ndi chipangizo

dongosolo Quality ayenera muli:
– Mipherezero Quality
– I kusinthidwa
– Kudziwa mapulani, kutsimikiza ndi yachinsinsi.
– Udindo ntchito khalidwe.

Ngati kampani akufuna kupeza ISO choyenereza madongosolo chiyenela kuchitika mu ntchito yonse, kuyambira ISO chitsimikizo ndi kampani lonse osati ntchito yeniyeni.

4.3 Gulu ndi luso polumikizira

Ngati pali gulu ntchito, polumikizira pakati pa iwo ayenera kuzindikiridwa, zalembedwa ndi kuwapereka kwa anthu ofunikira mfundo. zolembedwa The zidzafunika kuwonapo zonse.

4.4 Design Malangizo

Zofunika specifications ali ndi mamangidwe athandizira ku mapulogalamu chitukuko. Izi zikhoza kuchitika ndi wogula kapena anawakonzera katundu ntchito malamulo. Wina kapangidwe athandizira zikuphatikizapo kapangidwe ‘kala’ ikusonyeza amene ntchito ngati ndani kuti wolemba pulogalamu.

muyezo amafuna kuonetsetsa kuti ntchito mankhwala a sitepe iliyonse amakumana zofunika.

Mu mapulogalamu chitukuko, kusintha lamulo sizachilendo choncho ndondomeko othetsera malamulo atsopano wosinthika kwa wogula ndi kulengedwa.

4.5 Design linanena bungwe

Design linanena bungwe: kamangidwe zolembedwa ndi malamulo gwero. ISO amafuna kuti luso zikalata ndi wolemba pulogalamu kuwonapo isanatuluke.

A Ndondomeko kuvomereza kapangidwe linanena bungwe ndi muyezo wa kuvomereza ayenera analenga.

4.6 Design Review

ntchito Project ngati ‘kala’ ikusonyeza ndi kuyezetsa lidzakhala ndi pa review lapansi. A njira ambiri kuonetsetsa ndemanga ndi checklists.

4.7 Design Yotsimikiza

Tichipeza ndemanga, kuyezetsa gawo ndi kusakanikirana kuyezetsa.

4.8 Design kutsimikiza

Final dongosolo mayeso a wathunthu mankhwala mapulogalamu pamodzi ndi kupenda za zolembedwa wosuta. Payenera kukonzekera ndi zalembedwa kutsimikiza. Beta kuyezetsa ali conformance ndi ISO bola chiyesedwe beta aphimbidwa ndi pangano pakati pa katundu ndi beta-kuyezetsa makasitomala.

4.9 Design Kusintha

ISO 9001 amafuna kuti atamasulidwa ya kapangidwe zolembedwa kapena gwero, kusintha onse adzapita mwa ndondomeko yantchito kumene n’kusintha zalembedwa, kuwunikira ndi wovomerezeka pamaso kukhazikitsa.

kusintha kusalankhula kuti zikalata zovuta luso kapena mapulogalamu ndi woopsa kwambiri ndipo monga muyezo amenewa salola izo.
5. choyenera ndi Control Data

Information kuti akulamulira chitukuko / kukonza mapulogalamu. muyezo amafuna kuti amene timafunika chikalata / deta adzakhala ndi mwayi izo. Kusintha zikalata ndi deta adzakhala kapolo.

5.1 General

zikalata kunja ndi deta adzakhala kusungidwa. Iwo akhoza kusungidwa pa mtundu uliwonse (buku zovuta pakomputer media).

5.2 choyenera ndi Data Ovomerezeka ndi Issue

Pamaso nkhani zolembedwa ndi deta zidzafunika kuwonapo ndi wovomerezeka pamaso magazini iliyonse. A mndandanda chikalata chimene aliyense tikupeza Baibulo panopa chikalata. zikalata opanda pake kapena lotha ayenera kuchotsedwa kapena olemba bwino.

5.3 choyenera ndi Data Kusintha

Munthu / s kuyang’anira review ndi chiyanjo ndondomeko adzakhala mwachindunji.

6. Yogula

Pankhani ya subcontractor, muli ndi udindo. I.e. ngati inu ntchito kwa mgwirizano ndi subcontract ntchito, mfundo ISO likupitirirabe udindo wanu ndi ISO amafuna alibe kuti oletsa subcontractor lapansi.

6.1 General

Ngati anthu oti ali anagula, muyezo amafuna kuti kutsatira njira kuti apeze anthu pomwe. anthu lizilamuliridwa ndi katundu osati subcontractor.
Kuonetsetsa kuti mapulogalamu Nagula umagwirizana ndi zofunika:
– Zofuna mgwilizano pa njira subcontractors
– Kafukufuku wa dongosolo subcontractor khalidwe
– Fufuzani subcontractor kale ntchito
– Kafukufukuyu subcontractor pa mgwirizano
– Mboni review ndi kuyezetsa
– Mayeso ndi review mankhwala a subcontractor.

6.2 lowunikira la Subcontractors

Munthu waudindo zofunika ndiponso wokhoza adzaweruza aliyense subcontractor ndi kusankha ntchito. zochita ati chovomerezeka.

The katundu adzakhala nkuganiza kulamulira subcontractor adzakula. muyezo silitchula kuchuluka ulamuliro muyenera. Izo basi ananena kuti zochita ikhale pogwiritsa ntchito mfundo.

A nkhani yapadera ndi pamene mapulogalamu Nagula kudzera ritelo. Mu izi subcontractor mlandu ndi chipembedzo chimene kugula wochititsidwa, osati original mapulogalamu a mapulogalamu.

Ngati kugula zimachitika ISO ritelo 9001 amafuna kuti chimatanthauza kuti pati inu kuika zofunika pa wogulitsa kulamulira katundu wake.

6.3 Yogula Data

Zofunikira pa citukuko adzakhala zalembedwa mu mgwirizano pamodzi ndi zofunika katundu kuvomereza zotsatira ntchito ndi ndondomeko.

6.4 Yotsimikiza cha Mankhwala Nagula

Kulemba zochita za kutsimikizira aliyense Nagula chitukuko chida kapena m’gulu mankhwala.

– No mndandanda wa sapulaya wovomerezeka
– Zosayenera kulamulira subcontractor
– No yachinsinsi chikalata cha zinthu Nagula
– Zosayenera pangano ndi subcontractor.

7 Control wa Makasitomala alirenji Mankhwala

The katundu adzakhala ndi ndondomeko yachinsinsi, kusunga ndi kusamalira makasitomala amaperekedwa software. Komabe, khalidwe ndi udindo mapulogalamu.

A sanali conformance zimachitika chifukwa udindo bwinobwino udindo pakati makasitomala ndi katundu.

8 Mankhwala mfundo ndi Traceability

Mapulogalamu katundu ayenera kulamulira on:
– Kodi yapitayi chikalata nkhani akuchokera
– On amene mfundo akuchokera
– Kodi kuwongolera ndi kusinthidwa akhala m’gulu limene mapulogalamu gwero
– Kodi chinachitika aliyense lipoti vuto
– Unachokera ndi gawo enieni kwaiye.

9 Njira Control

Zalembedwa Ndondomeko ndondomeko kugawanika mu ntchito ndi njila yabwino ya mbuye PROMâ € ™ s / malaibulale. Kuonetsetsa kuti versioning olondola ntchito.

– No zalembedwa Ndondomeko kugawanika
– Kusagwiritsa anathetsera mbuye PROMâ mâ € ™ kapena diskettes.

10 kasamalidwe ndi kuyezetsa magazi

njira zinalembedwa kuti anayendera ndi kuyezetsa kuchitika mogwirizana ndi kugawanika.

– Mchitidwe wa basi kuona PROMâ mâ € ™ sichinayambe anayendera
– No zalembedwa Ndondomeko kudziyesa PROMâ mâ € ™.

11 Control wa kasamalidwe, Kuyeza ndi Zida Mayeso

The katundu ayenera kusankha yoyenera zipangizo chingwe ndi kutsatira njira zalembedwa ulamuliro wa zida. Lililonse latsopano mapulogalamu Baibulo ayenera kuyezedwa chifukwa chokwanira.

12 kasamalidwe ndi Udindo Mayeso

Zofunika ndi ndondomeko kutsimikizika kudzera ndemanga ndi kuyezetsa. The katundu adzakhala ndi ndondomeko amene amaletsa kugwiritsa ntchito specifications yopanda umboni kapena mapulogalamu.

13 Control wa Non-kutsatira Mankhwala

Non-kugwirizana mankhwala sayenera kugwiritsidwa ntchito mwangozi. A ndondomeko othetsera zosintha mwamsanga ngati zolakwa yovuta ayenera analenga.

– Chomveka chizindikiritso cha zinthu ankalamulira kuti zili ndi zolakwika uncorrected
– Njira kuyamba kukumverani kasitomala kuvomereza pa yobereka
– Ngati zosintha mwamsanga, ziyenera zalembedwa
– Kuwerenga nkhani zinthu zimenezi kusinthidwa adzakhala anakwezedwa udindo womwewo monga ena mapulogalamu.

14 amakonza ndipo zodzitetezera Action

– Kugwiritsa anathetsera malipoti amene sagwirizana ndi zofuna
– Kugwiritsa anathetsera malipoti osonyeza yochepa kubwera mu citukuko
– Amalalikira deta ndi kusanthula mfundo zokhudza mankhwala ndi ndondomeko sanali conformance ndi zochita zodzitetezera.

Information za mavuto anakumana ayenera kuyendetsa patsogolo za citukuko.

– Makasitomala dandaulo sichinayambe bwino
– Chakuchepa wapezeka koma sitisintha
– No ndondomeko kuonetsetsa kuti mavuto ndi kusanthula ndi chinachake
– No Ndondomeko malipoti mavuto ndi kutsatira malamulo ndi ndondomeko.

15 akuchitira, yosungirako, Kenaka, kusunga ndi Kutumiza

Imakhudzanso mapulogalamu chitidwe pa gule, litayamba kapena sing’anga ena.
Media adzakhala olembedwa ndi mmatumba molondola. Data adzakhala kuonetsa. Palinso ayenera amatha kuteteza munthu ku kuwonongeka mwangozi.

16 Control wa Quality Records

zikalata Quality kusonyeza amene zochita Atengedwa kuonetsetsa kapena funsani khalidwe. muyezo amafuna kuti pali ndondomeko othetsera kulembamo khalidwe. kulembamo ziyenera kusungidwa yoyenerera kotero iwo mosavuta.
– No malamulo posungira za mbiri ndi khalidwe
– Mbiri Review si anapitiriza
– Mbiri Mayeso amene sanasunge
– M’nyengo kusunga mbiri khalidwe si kumatanthauza

17 Internal Quality Audits

Payenera kukhala gulu paokha nthawi zonse audits zonse ntchito imene ingakhudze mankhwala kapena utumiki khalidwe. Izi zimachitika kaamba ntchito kampani. Payenera kukhala dongosolo kafukufuku.

– No dongosolo kafukufuku
– Kafukufuku ndondomeko osati kwa tsiku

18 Training

Company awonetsetse ndodo amene anaphunzitsidwa ntchito chofunika. A ndondomeko kuti:
– Kupeza zofunika maphunziro aliyense udindo ndodo
– Kupereka maphunziro amenewa
– Kusunga mbiri ya maphunziro a anthu onse ogwira.

Maphunziro ayenera zalembedwa wokwanira. Ndi okwanira tikutanthauza kuti munthu akhale wokhoza kuchita wake / ntchito yake ndi wapamwamba mokwanira.

– No ndondomeko kukonzekera kapena maphunziro
– Mbiri maphunziro No
– Osati anaphunzira bwino ntchito yake.

19 yokonza

Katundu adzakhala apeza ndondomeko yokonza ngati umenewu ikutchulidwa mu mgwirizano. Mu mapulogalamu ndi za kusintha mphulupulu ndi zowonjezera kwa mapulogalamu anakamba.

Ndondomeko wolunjika madandaulo ndi mapemphero zosintha. katundu si unkayenera kupereka yokonza ngati sanatchulidwe mgwirizano. Kukonza ndondomeko mapulogalamu wakale ikhale.

– Kukonzanso ntchito wogula wopanda mgwirizano
– Njira Enieni kwa yokonza mankhwala akale si zalembedwa
– No ndondomeko kukayezetsa pambuyo yokonza.

20 Yosagwiritsa Statistical

Payenera kukhala deta ndi kusanthula deta za chiwerengero cha zolakwa amapezeka mbali zosiyanasiyana. Information za kulephera kukumana deadlines ndi yachitika ayenera kusanthula.

“————————————————– ————————————————– ————————————————–

————————————————– ————————————————– ————————————————–
ISO 9001质量二十元

一看就会从公司软件开发的角度来看的要求服用。 ISO 9001标准的目的是为制造业。的要求在根据ISO 9000-3和TickIT审核解释软件开发。





– 定义management’的质量承诺
– 定义了该公司€™的目标有关质量,即由质量意味着什么管理
– 是相关的customer’的需求
– 可以理解在组织
– 实施


– 语句太含糊或政策不被理解的工作人员
– 质量政策不落实。








– 不能履行责任的存在。


– 项目线
– 项目 – 客户
– 项目 – 维护组织
– 软件开发,硬件开发
– 维护组织帮助台
– 销售 – 研发

– 确定对资源的需求
– 分配经过培训的人员。

– 确保公司符合ISO在9001要求
– 报告的质量体系,公司经营管理业绩


– 质量审核
– 质量投诉统计
– 纠正措施的记录




程序,规则,决定应投入写作。如果你有一个规则或不是由ISO 9001所需要的程序,标准还要求它被写入。



– 审计是一个样本,因此,如果样品中,有轻微不符合项,它们是固定的,它仍然是一个不符合,因为审计师可以怀疑还有更多的轻微不符合项。
– 现有写程序不遵守。



– 是要求证明和认识?
– 是否包含验收标准?
– 有从招标不同的要求得到了解决?
– 供应商是否能鼓起足够的资源为合同?
– 供应商是否能鼓起所需合同的能力?
– 可以将任务按时完成?





– 在产品开发中使用的方法的定义
– 时间安排,职责,工作任务和进度控制
– 阶段项目将分。这包括输入,输出和输出的验证。
– 要使用的方法和工具介绍

– 质量目标
– 标准可接受
– 计划,确认和验证的鉴定。
– 责任质量活动。









设计输出:设计文档和源代码。 ISO要求的设计文件和编码发布前进行审查。







最后的系统测试,完整的软件产品连同用户文档的审查。应该有规划和记录验证。 Beta测试是在符合ISO只要beta测试是由供应商和Beta测试客户之间达成明确的协议覆盖。


ISO 9001要求,设计文档和源释放后,所有的更改应通过正式程序改变被记录在案,审查和实施前得到批准去。








负责审查和批准过程的人/ s款规定。




– 对分包合同的程序要求
– 分包商的质量体系审核
– 检查分包商过往业绩
– 调查中的合同分包商
– 见证评审和测试
– 测试分包商进行审查的产品。





如果采购是通过零售ISO 9001做需要您定义要你把什么程度上零售商的要求来控制它的供应商。





– 批准的供应商的名单没有
– 分包商的控制不当
– 购买的物品的任何文档验证
– 与分包商不当的合同。





– 在前面的是什么文件,并发出它是基于
– 在这规范是基于
– 已被纳入其中源程序什么更正和修正
– 发生了什么事每个问题报告
– 从什么来源是一个特定的模块生成。



– 复制任何文件的程序
– 处理不当主PROMA€™的或软盘中。



– 自动检查PROMA€™的功能还没有被检查
– 无文件的程序,用来测试PROMA€™的。







– 中包含纠正错误管制物品清除标识
– 方法引起在交付客户验收
– 在快速修改的情况下,必须记录
– 回顾如此修改的项目将被提升到为其他软件同等的地位。


– 那不符合要求的报告,有效地处理
– 指示在发展过程中的缺憾报告有效的处理
– 积极收集和有关产品和工艺不符合和预防措施的资料分析。


– 客户投诉未能妥善处理
– 缺乏已被发现,但没有得到纠正
– 无程序,确保问题进行了分析,并采取行动
– 报告与应用的规则和程序方面遇到困难的程序。




– 质量记录保留没有规矩
– 审查记录不被保存
– 测试记录不被保存
– 保持质量记录的期间是没有定义



– 未审计计划
– 审计计划不是最新的


– 确定每个员工岗位培训需求
– 提供这种培训
– 将所有工作人员的培训记录。


– 无程序规划或培训
– 无培训记录
– 不接受适当的训练为他或她的任务。




– 为客户维护工作,而合同
– 维护老产品的具体方法未记录
– 维修后测试的程序。



“————————————————– ————————————————– ————————————————–

————————————————– ————————————————– ————————————————–
ISO 9001質量二十元

一看就會從公司軟件開發的角度來看的要求服用。 ISO 9001標準的目的是為製造業。的要求在根據ISO 9000-3和TickIT審核解釋軟件開發。





– 定義management’的質量承諾
– 定義了該公司€™的目標有關質量,即由質量意味著什麼管理
– 是相關的customer’的需求
– 可以理解在組織
– 實施


– 語句太含糊或政策不被理解的工作人員
– 質量政策不落實。








– 不能履行責任的存在。


– 項目線
– 項目 – 客戶
– 項目 – 維護組織
– 軟件開發,硬件開發
– 維護組織幫助台
– 銷售 – 研發

– 確定對資源的需求
– 分配經過培訓的人員。

– 確保公司符合ISO在9001要求
– 報告的質量體系,公司經營管理業績


– 質量審核
– 質量投訴統計
– 糾正措施的記錄




程序,規則,決定應投入寫作。如果你有一個規則或不是由ISO 9001所需要的程序,標準還要求它被寫入。



– 審計是一個樣本,因此,如果樣品中,有輕微不符合項,它們是固定的,它仍然是一個不符合,因為審計師可以懷疑還有更多的輕微不符合項。
– 現有寫程序不遵守。



– 是要求證明和認識?
– 是否包含驗收標準?
– 有從招標不同的要求得到了解決?
– 供應商是否能鼓起足夠的資源為合同?
– 供應商是否能鼓起所需合同的能力?
– 可以將任務按時完成?





– 在產品開發中使用的方法的定義
– 時間安排,職責,工作任務和進度控制
– 階段項目將分。這包括輸入,輸出和輸出的驗證。
– 要使用的方法和工具介紹

– 質量目標
– 標準可接受
– 計劃,確認和驗證的鑑定。
– 責任質量活動。









設計輸出:設計文檔和源代碼。 ISO要求的設計文件和編碼發布前進行審查。







最後的系統測試,完整的軟件產品連同用戶文檔的審查。應該有規劃和記錄驗證。 Beta測試是在符合ISO只要beta測試是由供應商和Beta測試客戶之間達成明確的協議覆蓋。


ISO 9001要求,設計文檔和源釋放後,所有的更改應通過正式程序改變被記錄在案,審查和實施前得到批准去。








負責審查和批准過程的人/ s款規定。




– 對分包合同的程序要求
– 分包商的質量體系審核
– 檢查分包商過往業績
– 調查中的合同分包商
– 見證評審和測試
– 測試分包商進行審查的產品。





如果採購是通過零售ISO 9001做需要您定義要你把什麼程度上零售商的要求來控制它的供應商。





– 批准的供應商的名單沒有
– 分包商的控制不當
– 購買的物品的任何文檔驗證
– 與分包商不當的合同。





– 在前面的是什麼文件,並發出它是基於
– 在這規範是基於
– 已被納入其中源程序什麼更正和修正
– 發生了什麼事每個問題報告
– 從什麼來源是一個特定的模塊生成。



– 複製任何文件的程序
– 處理不當主PROMA€™的或軟盤中。



– 自動檢查PROMA€™的功能還沒有被檢查
– 無文件的程序,用來測試PROMA€™的。







– 中包含糾正錯誤管制物品清除標識
– 方法引起在交付客戶驗收
– 在快速修改的情況下,必須記錄
– 回顧如此修改的項目將被提升到為其他軟件同等的地位。


– 那不符合要求的報告,有效地處理
– 指示在發展過程中的缺憾報告有效的處理
– 積極收集和有關產品和工藝不符合和預防措施的資料分析。


– 客戶投訴未能妥善處理
– 缺乏已被發現,但沒有得到糾正
– 無程序,確保問題進行了分析,並採取行動
– 報告與應用的規則和程序方面遇到困難的程序。




– 質量記錄保留沒有規矩
– 審查記錄不被保存
– 測試記錄不被保存
– 保持質量記錄的期間是沒有定義



– 未審計計劃
– 審計計劃不是最新的


– 確定每個員工崗位培訓需求
– 提供這種培訓
– 將所有工作人員的培訓記錄。


– 無程序規劃或培訓
– 無培訓記錄
– 不接受適當的訓練為他或她的任務。




– 為客戶維護工作,而合同
– 維護老產品的具體方法未記錄
– 維修後測試的程序。



“————————————————– ————————————————– ————————————————–

Traduction: Support:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty elementi è Artigiani

A ‘ochju sarà pigliata à i vostri bisogni da u puntu di vista di l’impresi di sviluppà un prugrammu. ISO mudellu di 9001 fu fatta la nnustria manifatturiera. U esigenze sò interpretati di sviluppu dû software in cunfurmità cù ISO 9000-3 e TickIT.

Ci sò 20 elementi principali. Ogni cuncettu hè ancu cunnisciutu in u cullettivu gestione di qualità.

Rispunsabilità: Hè rispunsèvule 1. Management

1.1 dimarchje è Artigiani

U mudellu hè ubligatoriu di a ghjestione Sec.XV jumbo una pulitica di qualità, unni si dici la cumpagnia sarà elaburazione di i prudutti di qualità.

A pulitica di a qualità sarà:
– Definisce u managementâ € ™ indiatura di a qualità
– Definisce ogettivi u companyâ € ™ l tucchendu a qualità, chì hè, ciò chì gestisce i mezi di a qualità
– Be Bandera di a disgrazia li customerâ € ™ l
– Be caputu in u mutore
– Stà realizatu


– Affirmazioni troppu jardinier o pulitica ùn hè capitu da bastone
– Dimarchje è Artigiani ùn hè micca messu in opera.

P.e. di e dimarchje è Artigiani

â € œWe ghjugna à a qualità à traversu lu vastuni mutivatu e abili, prucedure travagliu difiniti bè, è revue de scentifiche è u alessandria activities.â €

1.2 Urganizazione

U mudellu hè ubligatoriu di ducumentazione di respunsabilità più altu, autorità è interrelation di tutti agenti onniprisenti qualità. Chistu significa ca si na pirsuna havi na rispunsabilità, si devi esse cunsideratu furmalmenti da u capu di degne. A persona du deppi ‘tenni l’ auturitati pi rializzari lu rispunsabilità.

Sicondu a ISO, rispunsèvule significheghja:

â € sacrusantu Œã à agisce nantu à a so accordu oneâ € ™ l quannu quarchi cosa hà à essa fatta senza esse toldâ €.


– Industrial di una respunsabilità chì ùn pò esse ghjuntu à cumpiimentu.


– Project-line
– Project-lingua lingua
– Urganizazione Project-de maintenance
– U sviluppu Software sviluppu di-muratura
– Garifuna urganizazione-Conoscenza
– Sales-di sviluppu

Risorse bisognu chi lu Sec.XV:
– Identificà i bisogni di e risorse
– Stabilisce agenti di furmazioni.

riprisentante Management abbisogna appuntamentu di i ripresentanti di capu cun autorità è a respunsabilità à:
– Pigliinu in contu chì i so cumpagni fulfills i vostri bisogni in ISO 9001
– Segnala u funziunamentu di u sistema di a qualità di l’établissement cumpagnia

1,3 recensione Management

capu di a qualità deve prisentà periodically i risultati di
– Cuntrolli è Artigiani
– Statistiche di lagnanza qualità
– A Scrittura di l ‘azzioni currettive

I risultati duvia esse prisentatu à un cunvegnu établissement arriggistratu cu note, su chi friquintau lu, ciò chì era prisentatu è ciò chì e decisioni èranu pigghiati e fatti.

2. System Artigiani

sistema di qualità â € “”â € œthe struttura urganizazione, e rispunsabilità, e prucedure, azzione è e risorse di rispettendu e qualità management.â €

Prucedure, un regulamentu, e decisioni sarà messu in scrittura. Sè vo avete un magistratu o prucedura chì ùn hè ubligatoria par ISO 9001, la lingua standard abbisogna sempre chì ciò chì hè scrittu.

A manuali di qualità chì cuntene un rifirimentu e Ducumentazione in corsu di u sistema di qualità.


– An cuntrollu hè un santu cacadiavuli, dunque sè in un asempiu, ùn sò non-conformances anticchia, e iddi sunnu fissati, si pò sempre esse un non-conformance perchè u senior pò vidimi ca cci nni sunnu tanti non-conformances più minorenni.
– E prucedure Industrial scritti ùn sò micca inghjenghi.

Recensione 3. Cuntrattu

U chèques Sec.XV prima cuntrattu di vulè chi u mutore esse in gradu di fà ciò chì hè tenutu da u cuntrattu.

Dumande chì duvia esse dumandatu incrudunu:
– Paulu l ‘esigenze studiata è capitu?
– Paulu criterii accettazione facía?
– Ti statu risolta esigenze differing da a prufundezza?
– Canta u Sec.XV Sott’à abbastanza risorse di u cuntrattu?
– Canta u Sec.XV anzianu Sott’à lu cumpetenza bisognu di u cuntrattu?
– Canta u compitu compia in tempu?

U mudellu hè ubligatoriu chì una prucedura di studiata cù avis include. U Sec.XV deve identificà comu èssiri difinutu vàlidi e manutenzione di bisogni spicifichi trà lingua è Sec.XV cuntrattu.

4. Control Design

4.1. General
ISO esige chì ti piglià a prima di fà e specificà a prima di i dicori.

4.2. Cuncezzione è di Sviluppu di pianificazioni

pianu Design deve superà:
– À prupositu di mituduluggìa à esse usatu in u sviluppu di un pruduttu
– Quando Time, e rispunsabilità, ASSIGNIEZ travagliu è di cuntrollu di u prugressu
– Prugettu Fasi sarà spartutu. Stu cumprenni un numeru, pruduzzioni litteraria è verification di pruduzzioni litteraria.
– Discrizzioni di i metudi è i mezi à esse adupratu

pianu di a qualità deve superà:
– Pròssimu è Artigiani
– Criterii di acceptability
– Identificazione di a pianificazioni, a cunvalidazione e verification.
– E rispunsabilità di attività di qualità.

Si ‘na cumpagnia di pagliacci pi farisi a qualifica ISO i piani deve esse messa in tutti i prughjetta, dipoi certificazione ISO è di tutta a cumpagnia, è micca di prughjetti specifichi.

4,3 interfaccia Urganizazione è tecnica

S’è ùn ci hè gruppu-di travagliu, u interfaccia trà elli deve esse identificatu, studiata è trasmesse à quelli needing la nfurmazzioni. Parlendu di i fori, sarà hat di modu rigulari.

4.4 Design Input

quaternu di Cunfigurazione cuntena u numeru design in lu sviluppu dû software. Chissu pò èssiri fattu pi la canadese purchaser o accunciata da u Sec.XV cù e lege è rigulamenti. N’àutra Poloniana disignu de mengianu scrittura disignu unni veni usatu comu entrée a scrittura.

U mudellu voli à ricunnoscia chì u pruduttu di u travagliu di ogni passu ritrova à l ‘esigenze.

In u sviluppu dû software, cambiamenti esigenza sò cumuni cusì una prucedura per assicurà esigenze nove è canciatu da u canadese purchaser esse creati.

4.5 pruduzzioni litteraria Design

Radicali avrìanu pututu Design: Parlendu di i fori generu è u còdice. ISO esige chì i ducumenti disignu e di scrittura esse hat prima di libbirtati.

deve esse creatu A prucedura di accettazione di i radicali è criteri di accettazione generu.

4.6 Design recensione

funzioni Prugettu comu scrittura e essai serà prisentatu à u avis. A lu mètudu cumuna per assicurà a avis sò checklists.

4,7 Design Verification

Chistu si componi di recensioni, essai Modulo e essai integrazione.

4,8 Design cunvalidazione

test di Final sistema, di u pruduttu dû software cumpletu nzemi cu la reviewing di Ducumentazione in corsu utilizatori. Ci duvia esse appruntatu è a cunvalidazione ducumentatu. essai Beta hè in conformance cu ISO comu longhi cum’è u essai raghji hè cupartu par un chjaru accordu trà Sec.XV e clienti raghji-essai.

4,9 mi pigliu u linguaghju

ISO 9001 esige chì dopu à libbirtati di Ducumentazione in corsu so generu oa so surghjenti, tutti i cambiamenti di marchjarà voltu à traversu un prucessu furmali, unni sunnu ducumintati, hat è accunsentitu davanti à e matematiche cambiamenti.

canciamenti Uncontrolled à i ducumenti tecnicu cumplessa o li prugrammi sò assai periculosa e comu tali la lingua standard nun si volsi.
5. Document e Control Data

La nfurmazzioni chi vuluntà u sviluppu / mantenimentu di software lìbbiru. U mudellu hè ubligatoriu chì quelli chì hanu bisognu di quarchi ducumentu / data, u nemicu un accessu à lu. Mi pigliu a ducumenti è infurmazioni, serà cuntrullata.

5.1 generale

ducumenti External è dati chì si ferà. Si pò trove cullucate nantu à ogni forma (copia dura, di cumunicazione ilittronica).

5,2 Document e Data accunsentu è alba

Prima di i ducumenti questione, è di dati sarà hat è assicurati nanzu ogni emissione. A lista documentu in cui unu ti scummigghiari la virsioni currenti di un documentu. ducumenti scunnusciutu o abbuccari avissi a èssiri cacciatu o chjaramente u marcatu.

5,3 Document e mi pigliu Dati

A persona / s in rispunsevule di u prucessu revue et accunsentu sarà pricisatu.

6. Dolciumi

Nta lu casu di subcontractor, tu si ancora a so rispunsabilità. I.e. s’è tù dumandà un cuntrattu e subcontract lu travagghiu, li standard ISO hè ancora sutta li vostri responsabilità e esigenze ISO nun hannu a èssiri mposta li subcontractor.

6.1 generale

S’è travagghiu hè acquistatu, u mudellu di voi ci hè bisognu à seguità una prucedura chi ti cuntu lu pòpulu diritta. U populu devi esse cuntrullata da Sec.XV è ùn subcontractor.
Per assicurà chì un prugrammu accattatu conforms à esigenze:
– Esigenze Cuntrattu nant’à un antra strada subcontractors
– Audit di u sistema di qualità subcontractor
– Segat subcontractor passatu spettaculu
– Log u subcontractor durante u cuntrattu
– Revue de tistimuniatu e essai
– Test e revue de pruduttu di subcontractor.

6,2 Valutazione di Subcontractors

Person cu nicissariu autorità è a cumpetenza ghjudicherà ogni subcontractor esaminà siasi à aduprà. A dicisioni sarà studiata.

U Sec.XV sarà dicidiri quali cuntrollu supra subcontractor si ponnu aviri. A lingua standard nun pinzari a quantu ammaistratu vo ‘ndannu i tenunu. Si ricorda sulu ca na dicisioni deve esse fatta aduprendu i custatti.

Un casu particulare è quandu un prugrammu hè acquistatu in mezu impieghi. In stu casu, subcontractor hè strutturatu cu cui veni fatta la accidente, ùn la documentaliste urighjinariu di u prugrammu.

Sè u pudere hè fattu à traversu ISO impieghi 9001 esige chì vo definisce a chiddu ca ‘n quantu si mette esigenze nantu à u minutu a cuntrullà a so Sec.XV.

6,3 Dolciumi Dati

Cunfigurazione nantu à prucessu di sviluppu, serà studiata in u cuntrattu di rilazione cù esigenze Sec.XV di appruvazioni di u travagliu i risultati è e prucedure.

6,4 Verification di Product accattatu

Documentation di e decisioni di u verification di ogni accattatu strumentu sviluppu o pruduttu facía.

– No lista di Suppliers accunsentitu
– U cuntrollu Camera di subcontractor
– No verification ducumentu di dispacci accattatu
– Cuntrattu Camera con subcontractor.

7 di Cuntrollu di Customer-tenute Specialista

U Sec.XV u nemicu, e prucedure di verification, a pruvista è u mantenimentu di massa tenute software lìbbiru. A ogni modu, a qualità hè u rispunsèvule di u prugrammu.

A non-conformance chi succèri a causa di a respunsabilità craru di respunsabilità più altu trà lingua è Sec.XV.

8 spicifichi Product e Traceability

U Sec.XV prugrammu avissi a mantèniri lu cuntrollu nantu à:
– On chiddu di prima ducumentu è jumbo hè basatu
– Su chi pruvisoria hè stata fundata
– Cosa currezzione è vàlidi hè stata inclusa in u quali programmi surgenti
– Cosa hè accadutu à ogni rapportu di u prublema
– Da u ciò chì fù surghjente caricate un Modulo specifichi.

Control 9 Caduta

prucedura ducumentatu per u prucessu euphorbia in u funziunamentu è a prucedura di a mugnera di signore PROMâ € ™ s / Biblioteche. Per assicurà chì currettu versioning veni usatu.

– No prucedura ducumentatu per euphorbia
– A mugnera di Santa Lucia di diskettes signore PROMâ € ™ l o.

10 ispezione e essai

prucedure scritti di u biancu pirmittennu, è essai à essa fattu a cunnessione incù euphorbia.

– Funzioni di cuntrollà in autumàticu PROMâ € ™ hè micca has been rigulari
– No prucedura ducumentatu per alessandria PROMâ € ™ s.

11 di Cuntrollu di ispezione, misurazzioni e Agriculture Test

U Sec.XV deve sceglie u usato misurari degne di e seguità una prucedura di scrittore di lu cuntrollu d ‘apparicchiaturi. Ogni nova versione prugrammu deve esse pruvatu di autunumia.

12 ispezione e Test Status

Spicìfichi e li prugrammi deve liste à traversu avis e essai. U Sec.XV resterà un antra strada chì drammaturgu usu di un quaternu o prugrammi verificata.

13 di Cuntrollu di Non-conforming Specialista

i prudutti Non-conforming nun avissi a ièssiri usatu unintentionally. deve esse creatu A prucedura per assicurà e so mudìfiche, prestu, in casu di sbagghi critica.

– Và identificazione di dispacci cuntrullata chì cuntene errori uncorrected
– Method ànimu accettazione di clientella nantu à dénonce
– In casu di mudìfica di prescia, si deve esse studiata
– Reviewing voci tantu scambiatu sarà elevatu à listessu statutu di u restu di software lìbbiru.

14 azzione currettive e Preventive

– Assicurà care di raporti ca nun conform à esigenze
– Assicurà care di raporti mintuvendu cortu-comings in u prucessu di sviluppu
– Cullezzione e anàlisi dâ nfurmazzioni dispunibbili su prodottu e prucessu non-conformance è n’azzioni preventive Active.

Information sur prublemi scontru deve purtà riformi di lu prucessu di sviluppu.

– DMCA Customer ùn hè statu dunca handled
– Eu hè statu trovu, ma ùn corrigée
– No prucedura à assicurà chì prublemi sò verra è mette nantu à
– No prucedura di cantu difficultà incù entrata in règuli e prucedure.

15 feeding, Storage, Packaging, Linee e domicilio

Vali à contu replicated nantu à PROM, u discu, o altri media.
Media sarà tichittatu e drogherie cum’ellu ci vole. Data sarà Tau. Ci duvia esse ancu a capacità di furniscia pruteghji da i danni era fatta cu ntinzioni.

16 di Cuntrollu di qualitati Records

ducumenti di qualità mostranu chì hè stata pigliata azzione pè assicurà o cuntrolla a qualità. U mudellu hè bisognu ch’ellu ci sia un prucessu per assicurà di i cartulari di qualità. Lu ricordiu di fassi trove in una manera degne di e accussi si sò podit sodigai.
– No regule di a ciumi di i cartulari di qualità
– Ricordi recensione ùn sò firmati
– Ricordi Test ùn sò firmati
– Epoca di stà in vinili a qualità ùn hè definita

Cuntrolli 17 Ore Irreversible

Ci deve esse un enti indipindenti chì cuntrolli di modu rigulari tutti li tudischi ca po ‘aviri un pruduttu o sirviziu di qualità. Quessi sò cundotte in nomi di l’établissement cumpagnia. Ci deve esse un pianu di cuntrollu.

– No pianu cuntrollu
– Plan Audit micca fin’à a data

18 Training

Company duvia ricunnoscia chì stu bastone hè una furmazioni di gestisce un plugin. A prucedura di a:
– Identificà bisogni di furmazione per ogni postu lu vastuni
– Ch’ellu ci sia tali amparera
– Tena i cartulari di a furmazione di tutti i membri di bastone.

Training deve esse studiata è bastatu. Par bastò cuntribbuti putemu diri ca la pirsuna si fida di davanu u so / a so travagliu à un mudellu abbastanza altu.

– No prucedure di pianificazione o amparera
– No records amparera
– Non ricivutu n’aducazzioni di furmazione di u so o di u so compitu.

19 impact

Leonardi ti aghju studiata e prucedure di impact s’ellu hè mintuatu in u cuntrattu. In u prugrammu hè circa currezzione errore è enhancements à contu pruposta.

Prucedure per assicurà lagnanza è richiesti per e so mudìfiche. U Sec.XV ùn hè custrettu à purtà un mantenimentu s’ella ùn hè mintuatu in un cuntrattu. prucedure mantinimentu di vechji prugrammu deve esse fatta.

– Travagliu, andate per un clienti senza un cuntrattu di
– I metudi Specific di mantinimentu di vechji pruduttu ùn hè studiata
– No prucedura di essai dopu à mantene.

20 techniques statìstica

Ci duvia esse cullezzione è analisi di data, su nùmeru de errori, trovu in i sfarenti fasi. Information sur incapaci à scuntrà COCCINELLIN e Milestones deve esse analizzatu.

“————————————————– ————————————————– ————————————————–

Podrška prijevod:
————————————————– ————————————————– ————————————————–
ISO 9001 Dvadeset elementi kakvoće

Pogled će se na zahtjeve sa stajališta tvrtki u razvoju softvera. ISO 9001 je namijenjen za prerađivačkoj industriji. Zahtjevi se tumače za razvoj softvera u skladu s ISO 9000-3 i TickIT.

Postoji 20 glavnih elemenata. Svaki koncept dobro poznat u upravljanja kvalitetom zajednice.

Odgovornost 1. Upravljanje

1.1 Politika kvalitete

Standard zahtijeva upravljanje dobavljača za izdavanje politiku kvalitete, gdje se kaže da je tvrtka će proizvoditi kvalitetne proizvode.

Politika kvalitete mora:
– Definirati managementa € ™ s opredjeljenje za kvalitetu
– Definiranje tvrtke ¡ť s ciljevima u pogledu kvalitete, to jest, ono što menadžment znači po kvaliteti
– Biti relevantni za customerâ € ™ s potrebama
– Treba shvatiti u organizaciji
– Biti proveden


– Izjava previše nejasan ili politika ne razumije osoblja
– Politika kvalitete nije provedena.

Na primjer politike kvalitete

â € œWe postići kvalitetu kroz motiviranog i stručnog osoblja, definirane procedure rada, a intenzivno pregled i testiranje activities.â €

1.2 Organizacija

Standard zahtijeva dokumentaciju o odgovornosti, ovlasti i međuodnosa svih kadrova koji utječu na kvalitetu. To znači da ako osoba ima odgovornost, on mora biti formalno dodjeljuje odgovarajući upravitelja. Osoba bi trebala imati ovlasti da ispuni odgovornost.

Prema ISO, odgovornost znači:

â € OEA dužnost djelovati na oneâ € ™ s voljom kada se nešto mora biti učinjeno bez toldâ €.


– Postojeći od odgovornosti koja se ne može ispuniti.


– Projekt linija
– Projekt-kupac
– Organizacija projekta-održavanje
– Razvoj softvera Razvoj-hardvera
– Održavanje organizacija-help desk
– Razvoj prometa

Resursi zahtijevaju da dobavljač:
– Utvrditi zahtjeve za resursima
– Dodjela osposobljeno osoblje.

Predstavnik uprave zahtijeva imenovanje predstavnika upravitelja s vlasti i odgovornosti da:
– Osigurati da tvrtka ispunjava uvjete u ISO 9001
– Izvješće o izvedbi sustava kvalitete za upravljanje tvrtkom

1.3 Upravljanje pregled

Voditelj kvalitete trebaju povremeno predstaviti rezultate
– Revizija kvalitete
– Statistika kvalitetnih pritužbi
– Evidencija o korektivnim mjerama

Rezultati će biti predstavljeni na snimljenom za upravljanje sastanku s bilješkama na koji su sudjelovali, što je predstavljena i što su odluke provedene i napravio.

2. Sustav kvalitete

Sustav kvalitete â € “”â € œthe organizacijsku strukturu, odgovornosti, postupke, procese i resurse za provođenje kvalitetnog management.â €

Procedura, pravila, odluke će se staviti u pisanom obliku. Ako imate pravilo ili postupak koji ne zahtijeva prema ISO 9001, standard i dalje zahtijeva da se što je pisano.

Kvalitetan priručnik mora sadržavati uputu i dokumentaciju sustava kvalitete.


– Revizija je uzorak, pa ako je u uzorku, postoje manje nesukladnosti, a oni su fiksne, još uvijek može biti nesukladnost jer revizor može sumnjati da postoji mnogo više manje nesukladnosti.
– Postojeći pisani postupci ne poštuje.

3. Ugovor Pregled

Opskrbljivač provjere prije potpisivanja ugovora da organizacija bude u mogućnosti to obaviti što je potrebno u ugovoru.

Pitanja koja valja postaviti uključuju:
– Jesu li zahtjevi dokumentirano i jasno?
– Da li su kriteriji prihvatljivosti uključeno?
– Jeste zahtjevi razlikuju od natječaja riješen?
– Može li dobavljač skupiti dovoljno sredstava za ugovor?
– Može li dobavljač skupiti nadležnost potrebnu za ugovor?
– Može li se zadatak biti završen na vrijeme?

Standard zahtijeva da dokumentirani postupak s osvrta biti uključeni. Dobavljač treba utvrditi kako se definira ugovor izmjene i rukovanje zahtjevima specifikacije između kupca i dobavljača.

4. Kontrola Dizajn

4.1. General
ISO zahtijeva da mislite prije nego što i odrediti prije izrade.

4.2. Dizajn i razvoj planiranje

Dizajn plan treba sadržavati:
– Definicija metodologije koje se koriste u izradi proizvoda
– Vrijeme rasporedi, odgovornosti, radnih zadataka i kontrola napretka
– Faze projekta će biti podijeljena. To uključuje ulaz, izlaz i provjeru izlaza.
– Opis metoda i alata koji se koriste

Plan kvalitete treba sadržavati:
– ciljevi kvalitete
– Kriteriji za prihvatljivost
– Identifikacija planiranja, validaciju i verifikaciju.
– Odgovornost za kvalitetu aktivnosti.

Ako tvrtka želi dobiti ISO kvalifikaciju planovi se moraju održati u svim projektima, jer ISO certifikat je za cijelu tvrtku, a ne za određene projekte.

4.3 organizacijskih i tehničkih sučelja

Ako postoji grupa-djelo, sučelja između njih treba biti identificirani, dokumentirani i prenose na one koji trebaju informacije. Dokumentacija mora biti redovito pregledavaju.

4.4 Dizajn Ulaz

Zahtjevi specifikacije sadrže ulaz dizajn u razvoju softvera. To može biti učinjeno od strane kupca ili pripremljeni od strane dobavljača, koristeći zakone i propise. Još jedan ulazni dizajn uključuje dizajn kodiranje koji se koristi kao ulaz za kodiranje.

Standardna želi osigurati da rad produkt svakom koraku ispunjava zahtjeve.

U razvoju softvera, promjene zahtjeva su uobičajene, tako postupak za rukovanje nove i promijenjene uvjete iz kupac biti kreirana.

4.5 Dizajn izlaz

Dizajn izlaz: projektna dokumentacija i izvorni kod. ISO zahtijeva da se dokumenti o dizajnu i kodiranje se prije puštanja na slobodu.

Postupak za prihvaćanje izlaz dizajna i kriterijima prihvatljivosti bi trebao biti stvoren.

4.6 Design Review

Projekt funkcije kao što su kodiranje i testiranje bit će predstavljen na pregled. Uobičajena metoda za osiguravanje mišljenja su provjeru.

4.7 Dizajn Provjera

Sastoji se od mišljenja, ispitivanja modula i testiranje integracije.

4.8 Dizajn Validacija

Završni test sustav, kompletnog softverskog proizvoda, zajedno s razmatranja korisničke dokumentacije. Tu treba planirati i dokumentirati valjanosti. Beta testiranje je u skladu sa ISO dok je beta testiranje pokrivena jasnim sporazuma između dobavljača i beta-testiranje kupca.

4.9 Dizajn Promjene

ISO 9001 zahtijeva da se nakon puštanja projektne dokumentacije ili izvor, sve promjene će proći kroz formalni proces u kojem su dokumentirani promjene, pregledan i odobren prije provedbe.

Nekontrolirano promjene složenih tehničkih dokumenata ili programa su izuzetno opasni i kao takav standard ne dopušta.
5. Dokument i kontrola podataka

Informacije koje kontrolira razvoj / održavanje softvera. Standard zahtijeva da oni koji trebaju neki dokument / podaci moraju imati pristup do njega. Izmjene dokumenata i podataka mora biti pod kontrolom.

5.1 Općenito

Vanjski dokumenti i podaci će biti pohranjeni. To se može pohraniti na bilo kojem obliku (hard copy, elektronskih medija).

5.2 dokumenata i odobravanje podataka i izdavanja

Prije izdavanja dokumenata i podataka mora biti pregledan i odobren prije svakog izdanja. Popis dokumenata u kojima je jedna mora saznati trenutne verzije dokumenta. Nevažeću ili zastarjelih dokumenata treba ukloniti ili jasno označena.

5.3 dokumenata i podataka Izmjene

Osoba / e zadužena za postupak pregleda i odobrenja mora biti naveden.

6. Nabava

U slučaju podizvođača, vi ste i dalje odgovorni. Tj Ako ste se prijavili za ugovor i podugovor rad, ISO standardi još uvijek je u vašoj odgovornosti i ISO zahtjevi ne moraju se nametnuti na podizvođača.

6.1 Općenito

Ako radne snage je kupljen, standard zahtijeva od vas da slijedite postupak koji ste dobili prave ljude. Ljudi će biti pod kontrolom dobavljača, a ne podizvođač.
Kako bi se osiguralo da su kupili softver u skladu s uvjetima:
– Zahtjevi Ugovor o postupcima kooperantima
– Revizija sustava kvalitete podizvođač
– Provjerite podizvođač prošlosti izvedbe
– Istraživanje podizvođač za vrijeme ugovora
– Pregled svjedoka i ispitivanje
– Ispitivanje i pregled proizvoda od kooperanta.

6.2 Procjena kooperanata

Osoba s potrebnim ovlastima i nadležnosti suditi svakog podizvođača i odlučiti hoće li koristiti. Odluke moraju biti dokumentirani.

Dobavljač mora odlučiti što kontrola podizvođača da će imati. Standard ne navodi koliko je kontrola trebali imati. To samo spominje da je odluka trebala biti izrađene pomoću činjenice.

Poseban slučaj je kada je softver je kupljen preko maloprodaji. U tom slučaju podizvođača je organizacija s kojima se obavlja kupnja, nije izvorni razvijen od softvera.

Ako kupnja se obavlja putem maloprodajne ISO 9001 zahtijeva da definirati u kojoj mjeri ste stavili zahtjeve o prodavaču da kontrolira svoje dobavljača.

6.3 Nabava podataka

Zahtjevi na razvojni proces mora biti dokumentiran u ugovoru uz zahtjeve dobavljača za odobrenje radne rezultate i procedure.

6.4 Provjera kupljeni proizvod

Dokumentacija odluke o verifikaciji svaki kupljeni alat za razvoj ili uključenog proizvod.

– Ne popis odobrenih dobavljača
– Neodgovarajuća kontrola podizvođača
– Ne verifikacija dokumenata kupljenih predmeta
– Neodgovarajuća ugovor s podizvođača.

7. Kontrola korisnike opskrbljene proizvodu

Dobavljač mora imati postupke za verifikaciju, čuvanja i održavanja kupaca opskrbljuje softvera. No, kvaliteta je odgovornost softvera.

Ne-Sukladnost se događa zbog nejasnog odgovornosti odgovornosti između kupca i dobavljača.

8 Specifikacija proizvoda i sljedivost

Softver dobavljač treba zadržati kontrolu na:
– Na što prethodi dokument i izdati ga temelji
– Na kojem specifikacije se temelji
– Što korekcije i izmjene su uključene u koji izvor programa
– Što se dogodilo svakom izvješću problema
– Iz kojeg izvora je generirana određeni modul.

Kontrola 9 Process

Dokumentirana procedura za proces replikacije u radu i postupku za rukovanje majstorski PROMâ € ™ s / knjižnicama. Kako bi se osiguralo da su točne verzije koristi.

– Ne dokumentirani postupak za replikaciju
– Nepravilno rukovanje majstorski PROMâ € ™ s ili diskete.

10 pregleda i ispitivanja

Pisane procedure za kontrolu i ispitivanje treba obaviti u vezi s replikacije.

– Funkcija automatski provjeravati PROMâ € ™ s nije pregledana
– Ne dokumentirani postupak za ispitivanje PROMâ € ™ s.

11 Kontrola inspekcije, mjernu i ispitnu opremu

Dobavljač treba odabrati odgovarajuću opremu za mjerenje i praćenje dokumentirani postupak za kontrolu opreme. Svaka nova verzija softvera treba testirati na dostatnost.

12 Pregled i status Test

Specifikacije i programi trebaju potvrditi putem mišljenja i ispitivanja. Dobavljač mora imati postupke koji zabranjuju upotrebu nepotvrđenim specifikacija ili programa.

13 Kontrola nesukladnih proizvoda

Nesukladnih proizvoda ne smiju se koristiti nenamjerno. Postupak za rukovanje brze promjene u slučaju kritičnih pogrešaka treba stvoriti.

– Jasno identifikacija kontroliranim stavkama koje sadrže neispravljene pogreške
– Način da se izazove prihvaćanje nakon poroda
– U slučaju brze izmjene, mora biti dokumentiran
– Pregled tako modificirane stavke će biti uzdignut na isti način kao ostatak softvera.

14 korektivne i preventivne mjere

– Učinkovito rukovanje izvješća koja nisu u skladu sa zahtjevima
– Učinkovito rukovanje izvješća ukazuju na kratke dolaske u procesu razvoja
– Aktivno prikupljanje i analiza dostupnih informacija o proizvodu i procesu nesukladnosti i preventivnim akcijama.

Informacije o problemima s kojima se susreću treba voziti poboljšanja razvojnog procesa.

– Tužba Kupac nije pravilno rukovati
– Nedostatak je pronađen ali ne i ispravljen
– Ne postupak kako bi se osiguralo da se problemi analiziraju i djelovao na
– Ne postupak prijavljivanja problema s primjenom pravila i procedure.

15 Rukovanje, skladištenje, pakiranje, čuvanje i dostava

Odnosi se na softver replicirati na PROM, disk ili drugi medij.
Mediji moraju biti označeni i ispravno zapakirani. Podaci će biti podupirač gore. Također bi trebao biti sposobnost da pružaju zaštitu od nehotičnog oštećenja.

16. Kontrola kvalitete Records

Kvaliteta dokumenti pokazuju radnjama koje su poduzete kako bi se osiguralo ili provjeriti kvalitetu. Standard zahtijeva da se postupak za obradu kvalitete zapisa. Evidencija treba čuvati na odgovarajući način, tako da su lako dostupni.
– Nema pravila za zadržavanje kvalitetnih zapisa
– Pregled evidencije ne vode
– Zapisnik o provjeri ne čuvaju
– Razdoblje vođenja zapisa o kvaliteti nije definiran

17 Unutarnje kvalitete revizije

Ima bi trebao biti neovisan entitet koji se redovito revidira sve operacije koje mogu utjecati na proizvod ili uslugu kvalitetu. To se provodi u ime vodstva tvrtke. Ima bi trebao biti plan revizije.

– Ne plan revizije
– Plan za reviziju nije do danas

18 trening

Društvo treba osigurati da osoblje bude osposobljeno za poslove potrebne. Postupak na:
– Identificirati potrebe obuke za svaku poziciju osoblja
– Osigurati takvu obuku
– Voditi evidenciju o izobrazbi svih djelatnika.

Trening bi trebao biti dokumentirani i dovoljno. Do dovoljna mislimo da je ta osoba biti u stanju obavljati njegov / njezin rad na dovoljno visokoj razini.

– Nema postupke za planiranje i obuku
– Nema zapisa za obuku
– Ne primio pravilan trening za svoju zadaću.

19 Servis

Dobavljač mora imati dokumentirane postupke za servisiranje, ako je to spomenuto u ugovoru. U softveru je riječ o ispravcima pogrešaka i poboljšanja isporučeni softver.

Postupci za rješavanje pritužbi i zahtjeva za izmjenama. Dobavljač nije dužan osigurati održavanje ako se ne spominje u ugovoru. Postupci za održavanje starog softvera treba.

– Radovi na održavanju za kupca bez ugovora
– Posebne metode za održavanje starog proizvoda nije dokumentirana
– Ne postupak za ispitivanje nakon održavanja.

20 statističkih tehnika

Ima bi trebao biti prikupljanje i analiza podataka o broju grešaka u različitim fazama. treba analizirati Informacije o nemogućnosti da ispuni rokove i događaje.

“————————————————– ————————————————– ————————————————–

Support oversættelse:
————————————————– ————————————————– ————————————————–
ISO 9001 Tyve kvalitetselementer

Et kig vil blive truffet på kravene fra det synspunkt af virksomheder, der udvikler software. ISO 9001 standarden var beregnet til fremstillingsindustrien. Kravene er fortolket for softwareudvikling i overensstemmelse med ISO 9000-3 og TickIT.

Der er 20 hovedelementer. Hvert koncept er velkendt i kvalitetsstyring samfund.

1. Ledelsens ansvar

1.1 Kvalitet politik

Standarden kræver, at ledelsen leverandør til at udstede en kvalitetspolitik, hvor der står virksomheden skal producere kvalitetsprodukter.

Kvaliteten politik skal:
– Definer managementâ € ™ s engagement i kvalitet
– Definer companyâ € ™ s mål med hensyn til kvalitet, det vil sige, hvad ledelsen mener med kvalitet
– Være relevante for customerâ € ™ s behov
– Forstås i organisationen
– Gennemføres


– Redegørelse for vag eller politik er ikke forstået af personale
– Kvalitet politik er ikke implementeret.

F.eks. af Kvalitetspolitik

â € œWe opnå kvalitet gennem motiverede og dygtige medarbejdere, definerede arbejdsgange, og intensiv gennemgang og afprøvning activities.â €

1.2 Organisation

Standarden kræver dokumentation af ansvar, beføjelser og indbyrdes relationer for alt personel, der påvirker kvaliteten. Det betyder, at hvis en person har et ansvar, det skal være formelt tildelt af den relevante manager. Personen skal have myndighed til at opfylde ansvar.

I henhold til ISO, ansvarlighed betyder:

â € OAS pligt til at handle på oneâ € ™ s egen overenskomst, når noget skal gøres uden at være Tolda €.


– Eksisterende af et ansvar, der ikke kan opfyldes.


– Projekt-line
– Projekt-kunde
– Projekt-vedligeholdelsesorganisation
– Udvikling Softwareudvikling-hardware
– Vedligeholdelse organisation-helpdesk
– Salg-udvikling

Ressourcer kræver, at leverandøren:
– Identificere krav til ressourcerne
– Tildel uddannet personale.

Management repræsentant kræver ansættelse af leder repræsentant med myndighed og ansvar til:
– Sørg for, at virksomheden opfylder kravene i ISO 9001
– Rapporter udførelsen af kvalitetsstyringssystemet til virksomhedens ledelse

1.3 Ledelsesberetning

Kvalitetschef bør med jævne fremlægge resultaterne af
– Kvalitet audits
– Statistik over klager kvalitet
– Registreringer af korrigerende foranstaltninger

Resultaterne skal præsenteres på en indspillet ledelse møde med noter om der deltog, hvad der blev præsenteret, og hvilke beslutninger blev taget og gjort.

2. Quality System

Kvalitetssystem â € “”â € œThe organisationsstruktur, ansvar, procedurer, processer og ressourcer til at gennemføre kvalitet management.â €

Procedurer, regler, beslutninger skal sættes i skriftligt. Hvis du har en regel eller procedure, der ikke er påkrævet af ISO 9001, kræver standarden stadig, at det er skrevet.

En kvalitetshåndbog skal indeholde henvisning og dokumentation af kvalitetssystemet.


– En revision er en prøve, derfor hvis i en prøve, der er mindre afvigelser, og de er faste, kan det stadig være en afvigelse, fordi revisor kan mistanke om, at der er mange flere mindre afvigelser.
– Eksisterende skriftlige procedurer ikke overholdes.

3. Contract Review

Den kontrol leverandør før underskrivelse kontrakt, at organisationen kunne udføre, hvad der kræves i henhold til kontrakten.

Spørgsmål, der bør stilles omfatte:
– Er de krav dokumenteret og forstået?
– Er acceptkriterier inkluderet?
– Har krav afviger fra udbuddet blevet løst?
– Kan leverandøren mønstre nok ressourcer til kontrakten?
– Kan leverandøren mønstre kompetence nødvendig for kontrakten?
– Kan opgaven være afsluttet i tide?

Standarden kræver, at en dokumenteret procedure med anmeldelser medtages. Leverandøren bør identificere, hvordan kontrakt ændringer og håndtering af kravspecifikation mellem kunde og leverandør defineres.

4. Design Kontrol

4.1. Generel
ISO kræver, at du har planer før gør og angiv før designe.

4.2. Design og Udvikling Planlægning

Design Planen skal indeholde:
– Definition af metode, der skal anvendes i udvikling af produkt
– Køreplaner, ansvar, arbejdsopgaver og fremskridt kontrol
– Faser projektet vil blive delt. Dette omfatter input, output og verifikation af output.
– Beskrivelse af metoder og værktøjer, der skal bruges

Kvalitet plan skal indeholde:
– Kvalitet mål
– Kriterier for accept
– Identificering af planlægning, validering og verificering.
– Ansvar for kvalitet aktiviteter.

Hvis en virksomhed ønsker at opnå ISO-kvalifikation planerne skal afholdes i alle projekter, da ISO-certificering er for hele virksomheden og ikke til specifikke projekter.

4.3 Organisatoriske og tekniske grænseflader

Hvis der er gruppe-arbejde, bør grænsefladerne mellem dem skal identificeres, dokumenteres og sendes til dem, der kræver oplysningerne. Dokumentationen skal revideres regelmæssigt.

4.4 Design Indgang

Kravspecifikationer indeholder design input i softwareudvikling. Dette kan gøres af køberen eller forberedt af leverandøren hjælp love og regler. En anden design input omfatter design kodning, der bruges som input til kodning.

Standarden ønsker at sikre, at arbejdet produktet fra hvert trin opfylder kravene.

I softwareudvikling ændringer krav er fælles så en procedure for håndtering af nye og ændrede krav fra køberen blive oprettet.

4.5 Design Output

Design Output: design dokumentation og kildekode. ISO kræver, at design dokumenter og kodning gennemgås før udgivelse.

Der bør skabes en procedure for accept af designet output og godkendelseskriterier.

4.6 Design anmeldelse

Projekt funktioner som kodning og test skal forevises på revisionen. En almindelig metode til at sikre anmeldelser er tjeklister.

4.7 Design Verification

Denne består af anmeldelser, modul test og integrationstest.

4.8 Design Validering

Final systemtest af hele softwareprodukt sammen med gennemgang af brugerdokumentation. Der skal planlægges og dokumenteres validering. Beta test er i overensstemmelse med ISO så længe beta test er dækket af en klar aftale mellem leverandøren og beta-testing kunde.

4.9 Design Ændringer

ISO 9001 kræver, at efter frigivelse af design dokumentation eller kilde, skal alle ændringer gå gennem en formel proces, hvor er dokumenteret, revideret og godkendt inden gennemførelsen ændringer.

Ukontrolleret ændringer komplekse tekniske dokumenter eller programmer er ekstremt farlige, og som sådan standard ikke tillader det.
5. Dokument og Data Control

Oplysninger, der styrer udviklingen / vedligeholdelse af software. Standarden kræver, at de, der har brug for nogle dokument / data skal have adgang til det. Ændringer i dokumenter og data skal kontrolleres.

5.1 Generelt

Eksterne dokumenter og data skal opbevares. Det kan lagres på enhver form (papirudgave, elektroniske medier).

5.2 Dokument og Data Godkendelse og Issue

Før udstede dokumenter og data skal gennemgås og godkendes, før hvert nummer. Et dokument liste, hvor man skal finde ud af den aktuelle version af et dokument. Ugyldige eller forældede dokumenter bør fjernes eller tydeligt mærket.

5.3 Dokument og Data ændringer

Den person / s med ansvar for gennemgang og godkendelse proces skal specificeres.

6. Indkøb

I tilfælde af underleverandør, er du stadig ansvarlig. Det vil sige hvis du ansøge om en kontrakt og udlicitere arbejdet, ISO-standarder er stadig under dit ansvar og ISO krav behøver ikke at blive pålagt underleverandøren.

6.1 Generelt

Hvis arbejdskraft er købt, standarden kræver, at du følger en procedure, at du får de rigtige mennesker. Folket vil blive kontrolleret af leverandør og ikke underleverandør.
For at sikre, at købt software i overensstemmelse med kravene:
– Kontrakt krav til underleverandører procedurer
– Revision af underleverandøren kvalitetssystem
– Check underleverandør tidligere resultater
– Opmål underleverandør under kontrakt
– Vidne gennemgang og test
– Test og gennemgang produkt af underleverandør.

6.2 Evaluering af Underleverandører

Person med nødvendige beføjelser og kompetence skal dømme hver underleverandør og beslutte, om at bruge. Afgørelserne skal dokumenteres.

Leverandøren skal beslutte, hvad kontrol over underleverandør det vil have. Standarden nævner ikke hvor meget kontrol du skal have. Det nævnes blot, at en afgørelse bør foretages ved hjælp af fakta.

Et særligt tilfælde er, når softwaren er købt gennem detailhandelen. I dette tilfælde underleverandør er organisation, som købet gennemføres, ikke den oprindelige udvikler af softwaren.

Hvis indkøb sker gennem detail ISO 9001 kræver, at du definerer i hvilken grad du sætter krav til detailhandleren til at kontrollere sin leverandør.

6.3 Indkøb af data

Krav til udviklingsprocessen skal dokumenteres i kontrakten sammen med leverandørkrav at godkende arbejdsresultater og procedurer.

6.4 Verifikation af indkøbte produkter

Dokumentation af beslutninger om kontrol af hver købte udviklingsværktøj tariferet produkt.

– Ingen liste over godkendte leverandører
– Uhensigtsmæssig styring af underleverandør
– Ingen dokument verifikation af købte varer
– Uhensigtsmæssig kontrakt med underleverandør.

7 Kontrol af Customer-leverede produkt

Leverandøren skal have procedurer for verifikation, opbevaring og vedligeholdelse af kunde medfølgende software. Men kvaliteten er ansvarlig for softwaren.

En ikke-overensstemmelse sker på grund af uklare ansvar ansvar mellem kunde og leverandør.

8 Produktspecifikation og sporbarhed

Den software leverandør bør holde kontrol på:
– På hvilket forudgående dokument, og udstede den er baseret
– På hvilken specifikation den er baseret
– Hvilke rettelser og ændringer er medtaget i hvilken source programmer
– Hvad skete der med hvert enkelt problem rapport
– Fra hvilken kilde var et særligt modul genereret.

9 Process Control

Dokumenteret procedure for replikering proces i drift og proceduren for håndtering af mester PROMA € ™ s / biblioteker. At sikre, at korrekt versionering anvendes.

– Ingen dokumenteret procedure for replikation
– Forkert håndtering af mester PROMA € ™ s eller disketter.

10 Inspektion og Prøvning

Skriftlige procedurer for kontrol og prøvning, der skal gøres i forbindelse med replikering.

– Funktion til automatisk kontrol PROMA € ™ s ikke er inspiceret
– Ingen dokumenteret procedure for at teste PROMA € ™ s.

11 Kontrol af Inspektion, Måling og testudstyr

Leverandøren skal vælge den relevante måleudstyr og følge en dokumenteret procedure for kontrol af udstyr. Hver ny softwareversion bør testes for tilstrækkelighed.

12 Inspektion og Test status

Specifikationer og programmer bør verificeres gennem anmeldelser og test. Leverandøren skal have procedurer, der forbyder brug af ubekræftede specifikationer eller programmer.

13 Kontrol af ikke-overensstemmende produkt

Ikke-overensstemmende produkter bør ikke anvendes utilsigtet. Der bør skabes en procedure for håndtering af hurtige ændringer i tilfælde af kritiske fejl.

– Klar identifikation af kontrollerede emner, som indeholder ikke-korrigerede fejl
– Metode til at fremkalde kundens accept ved levering
– I tilfælde af hurtige ændringer, skal det dokumenteres
– Gennemgang så modificerede elementer vil blive ophøjet til samme status som resten af software.

14 Korrigerende og forebyggende handlinger

– Effektiv håndtering af rapporter, der ikke opfylder kravene
– Effektiv håndtering af rapporter indikerer mangler i udviklingsprocessen
– Aktiv indsamling og analyse af tilgængelige oplysninger om produkt og proces afvigelse og forebyggende handlinger.

Information om problemer skal køre forbedringer i udviklingsprocessen.

– Kunden klage ikke er blevet korrekt håndteret
– Mangel er fundet, men ikke korrigeret
– Ingen procedure for at sikre, at problemerne analyseres og reageres på
– Ingen proceduren for indberetning af problemer med at anvende regler og procedurer.

15 Håndtering, opbevaring, emballering, Bevarelse og Levering

Gælder for software replikeres på PROM, disk eller et andet medium.
Medier skal mærkes og pakkes korrekt. Data skal sikkerhedskopieres. Der bør også være mulighed for at yde beskyttelse mod utilsigtet skade.

16 Kontrol af kvalitet Records

Kvalitet dokumenter viser, hvilke handlinger der er truffet for at sikre eller kontrollere kvaliteten. Standarden kræver, at der fastsættes en procedure for håndtering af kvalitetsregistreringer. Optegnelserne skal opbevares på en hensigtsmæssig måde, så de er let tilgængelige.
– Ingen regler for opbevaring af kvalitetsregistreringer
– Anmeldelse poster ikke holdes
– Test poster ikke holdes
– Periode holde kvalitetsregistreringer er ikke defineret

17 intern kvalitetskontrol

Der bør være en uafhængig enhed, der regelmæssigt revision alle operationer, der kan påvirke produkt eller service kvalitet. Disse er udført på vegne af virksomhedens ledelse. Der bør være en revisionsplan.

– Ingen revisionsplan
– Revision planen ikke ajour

18 Uddannelse

Selskabet skal sikre, at personalet er uddannet til opgaver, der kræves. En procedure til:
– Identificere uddannelsesbehov for hver personale position
– Give en sådan uddannelse
– Hold optegnelser over uddannelse af alle medarbejdere.

Uddannelse skal dokumenteres og tilstrækkelig. Ved tilstrækkelig mener vi, at personen være i stand til at udføre hans / hendes arbejde til en høj nok standard.

– Ingen procedurer til planlægning eller uddannelse
– Ingen uddannelse optegnelser
– Ikke modtaget ordentlig uddannelse for hans eller hendes opgave.

19 Servicering

Leverandøren skal have dokumenterede procedurer for service, hvis dette er nævnt i kontrakten. I software handler det om fejlretninger og forbedringer leveret software.

Procedurer for behandling af klager og anmodninger om ændringer. Leverandøren er ikke forpligtet til at yde vedligeholdelse, hvis det ikke er nævnt i kontrakten. Vedligeholdelse procedurer for gammel software bør gøres.

– Vedligeholdelsesarbejde for en kunde uden en kontrakt
– Specifikke metoder til vedligehold af gamle produkt er ikke dokumenteret
– Ingen procedure til test efter vedligeholdelse.

20 statistiske teknikker

Der bør være indsamling og analyse af data om antallet af fejl i de forskellige faser. bør analyseres Information om manglende evne til at overholde deadlines og milepæle.

“————————————————– ————————————————– ————————————————–

Ondersteuning vertaling:
————————————————– ————————————————– ————————————————–
ISO 9001 Twintig kwaliteitselementen

Een blik vindt om de eisen vanuit het oogpunt van bedrijven ontwikkelen van software. ISO 9001 norm is bestemd voor de verwerkende industrie. De eisen worden geïnterpreteerd voor de ontwikkeling van software in overeenstemming met ISO 9000-3 en TickIT.

Er zijn 20 belangrijkste elementen. Elk concept is welbekend in de kwaliteitsborging gemeenschap.

1. Beheer Verantwoordelijkheid

1.1 Kwaliteitsbeleid

De standaard vereist dat de leverancier management om een kwaliteitsbeleid, waar het zegt dat het bedrijf zal de productie van hoogwaardige producten af te geven.

Het kwaliteitsbeleid moet:
– Definieer de managementâ € ™ s toewijding aan kwaliteit
– De companyâ € ™ s doelstellingen definiëren met betrekking tot kwaliteit, dat wil zeggen, wat het management bedoelt met kwaliteit
– Aan de behoeften van de customerâ € ™ s relevant Be
– Worden begrepen in de organisatie
– Worden uitgevoerd


– Verklaring te vaag of het beleid wordt niet begrepen door het personeel
– Kwaliteit beleid is niet geïmplementeerd.

Bijv. Kwaliteit beleid

â € œWe bereiken kwaliteit door gemotiveerde en geschoolde medewerkers, omschreven werkprocedures en intensieve evaluatie en het testen van activities.â €

1.2 Organisatie

De standaard vereist documentatie van verantwoordelijkheid, het gezag en de onderlinge verhoudingen van het personeel van invloed zijn kwaliteit. Dit betekent dat als een persoon heeft een verantwoordelijkheid, het zal formeel worden toegewezen door de juiste manager. De persoon moet de bevoegdheid om de verantwoordelijkheid te vervullen.

Volgens ISO, verantwoordelijkheid betekent:

â € OEA plicht om te handelen op oneâ € ™ s uit eigen beweging als er iets moet gebeuren zonder Tolda €.


– Bestaande van een verantwoordelijkheid die niet kan worden voldaan.


– Project-lijn
– Project-klant
– Project-onderhoudsorganisatie
– Software ontwikkeling hardware-ontwikkeling
– Onderhoud organisatie-helpdesk
– Verkoop ontwikkeling

Middelen nodig dat de leverancier:
– Identificeer de eisen voor de middelen
– Wijs opgeleid personeel.

Directievertegenwoordiger vereist benoeming van manager vertegenwoordiger met gezag en verantwoordelijkheid om:
– Zorg ervoor dat het bedrijf voldoet aan de eisen van ISO 9001
– Verslag van de prestaties van het kwaliteitssysteem aan de bedrijfsleiding

1.3 Management Review

Quality manager moet regelmatig de resultaten van presenteren
– Kwaliteit audits
– Statistieken van de kwaliteit van de klachten
– Verslagen van corrigerende maatregelen

De resultaten moeten worden gepresenteerd op een opgenomen directievergadering met een toelichting op die aanwezig waren, wat werd gepresenteerd en welke beslissingen werden genomen en gemaakt.

2. Quality System

Kwaliteitssysteem â € “”â € œDe organisatiestructuur, verantwoordelijkheden, procedures, processen en middelen voor de uitvoering van de kwaliteit management.â €

Procedures, regels, besluiten worden op schrift gesteld. Als u een regel of procedure die niet is vereist door ISO 9001 hebben, de standaard vereist nog steeds dat het is geschreven.

Een kwaliteitshandboek dient verwijzing en documentatie van het kwaliteitssysteem bevatten.


– Een audit is een monster, dus als in een steekproef, zijn er kleine tekortkomingen, en ze zijn bevestigd, kan het nog steeds een niet-conformiteit omdat de auditor kan vermoeden dat er veel meer kleine non-conformiteiten.
– Bestaande schriftelijke procedures niet worden nageleefd.

3. Contract Beoordeling

De leverancier controles vóór ondertekening van het contract dat de organisatie in staat zijn om uit te voeren wat nodig is in het contract.

Vragen die moeten worden gesteld zijn onder meer:
– Zijn de eisen gedocumenteerd en begrepen?
– Zijn acceptatiecriteria opgenomen?
– Heb eisen die verschillen van de tender is opgelost?
– Kan de leverancier opbrengen voldoende middelen voor het contract?
– Kan de leverancier opbrengen van de competenties die nodig zijn voor het contract?
– Kan de taak op tijd worden afgerond?

De standaard vereist dat een gedocumenteerde procedure met beoordelingen worden opgenomen. De leverancier moet worden aangegeven hoe contract wijzigingen en behandeling van de eisen specificatie tussen klant en leverancier worden gedefinieerd.

4. Ontwerp Controle

4,1. Algemeen
ISO vereist dat je van plan bent voor het doen en opgeven voordat het ontwerpen.

4,2. Design and Development Planning

Ontwerp plan moet bevatten:
– Definitie van de methodologie te worden gebruikt in de ontwikkeling van het product
– Tijdschema’s, verantwoordelijkheden, werkopdrachten en voortgangscontrole
– Fasen project zal worden verdeeld. Dit omvat input, output en outputcontrole.
– Beschrijving van de methoden en instrumenten te gebruiken

Kwaliteit plan moet bevatten:
– Kwaliteit doelen
– Criteria voor de aanvaardbaarheid
– Identificatie van de planning, validatie en verificatie.
– De verantwoordelijkheden voor kwaliteit activiteiten.

Als een bedrijf wil ISO kwalificatie van de plannen moeten in alle projecten worden gehouden krijgen, omdat ISO-certificering is voor het hele bedrijf en niet voor specifieke projecten.

4.3 Organisatorische en technische interfaces

Als er groepswerk, moet de raakvlakken tussen hen worden geïdentificeerd, vastgelegd en doorgegeven aan hen die dit nodig de informatie. De documentatie wordt regelmatig beoordeeld.

4.4 Ontwerp Input

Eisen specificaties bevat het ontwerp inbreng in de ontwikkeling van software. Dit kan worden gedaan door de koper of voorbereid door de leverancier met behulp van wet- en regelgeving. Een ander ontwerp ingang omvat het ontwerp codering die wordt gebruikt als input voor het coderen.

De standaard wil waardoor het werk product van elke stap aan de eisen voldoet.

In de ontwikkeling van software, vereiste veranderingen zijn vaak zo een procedure voor de behandeling van nieuwe en gewijzigde eisen van de koper worden gemaakt.

4.5 Ontwerp Output

Ontwerp Output: het ontwerp documentatie en de broncode. ISO vereist dat ontwerpdocumenten en codering worden beoordeeld voor de release.

Een procedure voor de aanvaarding van het ontwerp-uitgang en acceptatiecriteria moeten worden gecreëerd.

4.6 Design Review

Project functies zoals codering en testen zullen worden gepresenteerd op de beoordeling. Een veelgebruikte methode voor het waarborgen van recensies zijn checklists.

4.7 Design Verification

Deze bestaat uit beoordelingen, module testen en integratie testen.

4.8 Ontwerp Validation

Uiteindelijke systeem test, van de complete software product samen met de herziening van gebruikersdocumentatie. Er moet worden gepland en gedocumenteerd validatie. Beta-testen is in overeenstemming met ISO, zolang de beta testing wordt gedekt door een duidelijke overeenkomst tussen de leverancier en beta-testen van de klant.

4.9 Ontwerp Veranderingen

ISO 9001 schrijft voor dat na de release van het ontwerp documentatie of source, worden alle veranderingen gaan door middel van een formeel proces waarbij veranderingen worden gedocumenteerd, beoordeeld en vóór de tenuitvoerlegging goedgekeurd.

Ongecontroleerde wijzigingen in complexe technische documenten of programma’s zijn zeer gevaarlijk en als zodanig de standaard niet mogelijk is.
5. Document en Data Control

Informatie die de ontwikkeling / onderhoud van software controleert. De standaard vereist dat degenen die een document nodig / data zal er toegang toe hebben. Wijzigingen in documenten en gegevens worden gecontroleerd.

5.1 Algemeen

Externe documenten en gegevens worden opgeslagen. Het kan worden opgeslagen op een formulier (hard copy, elektronische media).

5.2 Document en Data Goedkeuring en Issue

Vóór uitgifte van documenten en gegevens worden beoordeeld en vóór elke uitgifte goedgekeurd. Een lijst met documenten waarin zal er een te vinden uit de huidige versie van een document. Ongeldige of verouderde documenten moeten worden verwijderd of duidelijk aangegeven.

5.3 Document en Data Wijzigingen

De persoon / s die verantwoordelijk is voor de beoordeling en goedkeuring proces moet worden gespecificeerd.

6. Inkoop

In het geval van onderaannemer, je bent nog steeds verantwoordelijk. D.w.z. Als u een aanvraag voor een contract en besteden het werk, ISO-normen is nog steeds onder uw verantwoordelijkheid en ISO eisen hoeven niet te worden opgelegd aan de onderaannemer.

6.1 Algemeen

Als mankracht wordt gekocht, de standaard moet u een procedure dat u de juiste mensen te volgen. Het volk zal worden gecontroleerd door de leverancier en niet onderaannemer.
Om ervoor te zorgen dat de aangekochte software voldoet aan de eisen:
– Contract eisen aan de onderaannemers procedures
– Controle van de onderaannemer kwaliteitssysteem
– Controleer onderaannemer prestaties uit het verleden
– Onderzoek naar de onderaannemer tijdens contract
– Witness beoordeling en testen
– Testen en beoordelen van product van onderaannemer.

6.2 Evaluatie van Onderaannemers

Persoon met de nodige autoriteit en vakbekwaamheid wordt elke onderaannemer te beoordelen en beslissen of te gebruiken. De besluiten worden gedocumenteerd.

De leverancier zal beslissen wat controle over onderaannemer zal hebben. De standaard vermeldt niet hoeveel controle je moet hebben. Het vermeldt enkel dat een besluit moet worden gemaakt met behulp van feiten.

Een speciaal geval is wanneer de software wordt aangeschaft via de detailhandel. In dit geval is onderaannemer organisatie waarmee de aankoop wordt verricht, niet de oorspronkelijke ontwikkelaar van de software.

Als de aankoop wordt gedaan door middel van retail ISO 9001 vereist dat u bepalen in welke mate u zet eisen aan de retailer om zijn leverancier te controleren.

6.3 Inkoop Gegevens

Eisen op de ontwikkeling worden schriftelijk vastgelegd in het contract, samen met leverancier vereisten om werkresultaten en procedures goed te keuren.

6.4 Verificatie van ingekochte product

Documentatie van beslissingen over de verificatie van elk gekocht development tool of opgenomen product.

– Geen lijst van erkende leveranciers
– Ongepast controle van de onderaannemer
– Geen document verificatie van de gekochte artikelen
– Ongepast contract met onderaannemer.

7 Controle van de door de klant geleverde product

De leverancier moet procedures voor de verificatie, de opslag en het onderhoud van de klant geleverde software. Echter, de kwaliteit is de verantwoordelijkheid van de software.

Een non-conformiteit gebeurt als gevolg van onduidelijke verantwoordelijkheid van de verantwoordelijkheid tussen klant en leverancier.

8 productspecificatie en traceerbaarheid

De software leverancier moet controle te houden op:
– Op welke voorafgaand document en de afgifte van het gebaseerd is
– Op welke specificatie het is gebaseerd
– Welke correcties en wijzigingen zijn opgenomen in welke bron programma’s
– Wat is er gebeurd om elk probleem rapport
– Uit welke bron werd een specifieke module gegenereerd.

9 Process Control

Gedocumenteerde procedure voor de replicatie proces in de werking en de procedure voor de behandeling van de kapitein Proma € ™ s / bibliotheken. Om ervoor te zorgen dat de juiste versiebeheer wordt gebruikt.

– Geen gedocumenteerde procedure voor replicatie
– Een onjuiste behandeling van meester Proma € ™ s of diskettes.

10 Inspectie en Testen

Schriftelijke procedures voor de inspectie en het testen worden gedaan in verband met replicatie.

– Functie van het automatisch controleren Proma € ™ s niet is geïnspecteerd
– Geen gedocumenteerde procedure voor het testen van Proma € ™ s.

11 Controle van de Inspectie, meet-en testapparatuur

De leverancier moet de juiste meetapparatuur te selecteren en volgen een gedocumenteerde procedure voor de controle van de apparatuur. Elke nieuwe versie van de software moeten worden getest op toereikendheid.

12 Inspectie en Test Status

Specificaties en programma’s moeten gecontroleerd door middel van reviews en testen. De leverancier stelt procedures die gebruik maken van niet-geverifieerde specificaties of programma’s te verbieden.

13 Controle van niet-conforme Product

Niet-conforme producten mogen niet onbedoeld worden gebruikt. Een procedure voor de behandeling snelle wijzigingen bij kritische fouten worden gemaakt.

– Duidelijke identificatie van de gecontroleerde producten die niet-gecorrigeerde fouten bevatten
– Methode om aanvaarding door de klant bij aflevering te lokken
– Bij snelle wijzigingen moet worden gedocumenteerd
– Herziening dus gewijzigde items worden verheven tot dezelfde status als rest van software.

14 corrigerende en preventieve maatregelen

– Effectieve behandeling van rapporten die niet voldoen aan de eisen
– Effectieve behandeling van rapporten waaruit blijkt tekortkomingen in het ontwikkelingsproces
– Actief verzamelen en analyseren van de beschikbare informatie over product en proces non-conformiteit en preventieve maatregelen.

Informatie over problemen moeten verbeteringen van het ontwikkelingsproces te rijden.

– Customer klacht niet juist is behandeld
– Een tekort is gevonden, maar niet gecorrigeerd
– Nr procedure zodat problemen worden geanalyseerd en op handelde
– Geen procedure voor het melden van problemen met het toepassen van regels en procedures.

15 behandeling, opslag, verpakking, Behoud en Levering

Geldt voor software gerepliceerd op PROM, schijf of een ander medium.
Media worden geëtiketteerd en correct verpakt. De gegevens worden gesteund. Er moet ook in staat om bescherming tegen onopzettelijke schade.

16 Controle van Quality Records

Kwaliteit documenten laten zien welke acties zijn ondernomen om ervoor te zorgen of kijk op kwaliteit. De standaard vereist dat er een procedure voor de behandeling van kwaliteitsgegevens zijn. De gegevens moeten worden bewaard in een passende wijze, zodat ze gemakkelijk toegankelijk zijn.
– Geen regels voor het bewaren van kwaliteitsgegevens
– Beoordeling records worden niet bewaard
– Test records worden niet bewaard
– Periode van het houden van de kwaliteit platen is niet gedefinieerd

17 Interne kwaliteitsaudits

Er moet een onafhankelijke entiteit die regelmatig controleert alle handelingen dat product of dienst kwaliteit van invloed kunnen zijn. Deze worden uitgevoerd in opdracht van het management. Er moet een audit plan.

– Geen auditplan
– Auditplan niet up-to-date

18 Training

Rederij moet ervoor zorgen dat het personeel wordt opgeleid voor taken vereist. Een procedure voor:
– Identificeren van opleidingsbehoeften voor elk personeelslid positie
– Zorg voor een dergelijke opleiding
– Houd verslagen van de opleiding van alle medewerkers.

Opleiding moet worden gedocumenteerd en voldoende. Met voldoende wordt bedoeld dat de persoon in staat is om zijn / haar werk voldoende hoog zijn.

– Geen procedures voor de planning en training
– Geen training dossiers
– Niet ontvangen een goede opleiding voor zijn of haar taak.

19 Onderhoud

Leverancier zal procedures hebben gedocumenteerd voor onderhoud als dit in het contract wordt genoemd. In de software is het ongeveer foutcorrecties en verbeteringen aan geleverde software.

Procedures voor de behandeling van klachten en verzoeken om wijzigingen. De leverancier is niet verplicht om het onderhoud te voorzien als het niet in het contract wordt genoemd. onderhoudsprocedures voor oude software moet worden gemaakt.

– Onderhoudswerkzaamheden voor een klant zonder contract
– Specifieke methoden voor het onderhoud van het oude product is niet gedocumenteerd
– Geen procedure voor het testen na onderhoud.

20 Statistische Technieken

Er moet verzamelen en analyseren van gegevens over aantal fouten gevonden in de verschillende fasen. Informatie over het onvermogen om deadlines en mijlpalen te voldoen moeten worden geanalyseerd.

“————————————————– ————————————————– ————————————————–

Podpora překladu:
————————————————– ————————————————– ————————————————–
ISO 9001 Dvacet Elements Quality

Pohled bude přijato na základě požadavků z hlediska podniků vývoj software. Norma ISO 9001 byla určena pro zpracovatelský průmysl. Tyto požadavky jsou interpretovány pro vývoj softwaru v souladu s normou ISO 9000-3 a TickIT.

Tam jsou 20 hlavní prvky. Každý pojem je dobře známý v komunitě řízení kvality.

Odpovědnost 1. Vedení

1.1 Politika jakosti

Norma vyžaduje, aby řízení dodavatelů vydat politiku jakosti, kde se říká, že společnost musí vyrábět kvalitní výrobky.

Politika kvality musí:
– Stanovit závazek managementâ € ™ s ke kvalitě
– Definovat cíle companyĂ € ™ s co se týče kvality, to znamená, že to, co vedení znamená podle kvality
– Odpovídat potřebám customerâ € ™ s
– Chápat v organizaci
– Být realizován


– Prohlášení o příliš vágní či politika není znám zaměstnanci
– Politika jakosti není implementována.

Např. politiky jakosti

â € œWe dosáhnout kvality prostřednictvím motivované a kvalifikované zaměstnance, definovaných pracovních postupů a intenzivní revize a zkoušky activities.â €

1.2 Organizace

Standard vyžaduje dokumentaci odpovědnost, pravomoci a vzájemné vztahy všech pracovníků ovlivňujících kvalitu. To znamená, že pokud osoba má odpovědnost, musí být formálně přiděleny příslušným správcem. Osoba by měla mít pravomoc k výkonu zodpovědnost.

Podle normy ISO, odpovědnost znamená:

â € OEA povinnost jednat Jednaa € ™ s vlastní vůle, když je něco, co je třeba udělat, aniž by byl Tolda €.


– Stávající o odpovědnosti, které nemohou být splněny.


– Projekt linie
– Projekt-zákazník
– Organizace projektu na údržbu
– Vývoj softwaru rozvojové hardware
– Organizace údržby-help desk
– Prodej-vývoj

Zdroje vyžadují, aby dodavatel:
– Identifikovat požadavky na zdroje
– Přiřazení vyškolený personál.

Představitel managementu vyžaduje jmenování správce zástupce s pravomocí a odpovědností:
– Ujistěte se, že společnost splňuje požadavky normy ISO 9001
– Zpráva o výkonu systému jakosti pro řízení firmy

1.3 Vedení Review

Manažer kvality by měl pravidelně prezentovat výsledky
– Audity kvality
– Statistiky kvalitních stížností
– Záznamy o nápravných opatřeních

Výsledky by měly být prezentovány na nahraném poradě vedení s poznámkami ohledně toho, kdo se zúčastnili, co byl předložen a jaká rozhodnutí byla přijata a vyrobené.

2. Systém jakosti

Systém kvality â € “”â € œthe organizační struktura, odpovědnosti, postupy, procesy a zdroje k provádění kvalitní management.â €

Postupy, pravidla, rozhodnutí musí být uveden do psaní. Máte-li pravidlo nebo postup, který není požadované podle ISO 9001, standard nadále vyžaduje, aby je psáno.

Kvalitní ruční musí obsahovat odkaz a dokumentaci systému jakosti.


– Audit je ukázka, a proto pokud ve vzorku, existují drobné neshody, a oni jsou pevné, může to být ještě neshody, protože může auditor podezření, že existuje mnoho dalších menších neshody.
– Stávající písemné postupy nejsou dodržovány.

3. Přezkoumání smlouvy

Dodavatel zkontroluje před podepsáním smlouvy, že organizace bude schopen provést to, co je požadováno ve smlouvě.

Otázky, které by měly být požádáni, patří:
– Jsou požadavky zdokumentovány a pochopeny?
– Jsou zahrnuty kritéria přijatelnosti?
– Už požadavky lišící se od výběrového řízení vyřešena?
– Může dodavatel shromáždit dostatek prostředků na zakázku?
– Může dodavatel sebrat kompetence potřebné pro smlouvu?
– Může úkol být dokončen včas?

Norma požaduje, aby dokumentovaný postup s recenzemi být zahrnuty. Dodavatel by měl stanovit, jak bude definován smluvní dodatky a manipulace s specifikace požadavků mezi zákazníkem a dodavatelem.

4. Ovládací design

4.1. Generál
ISO vyžaduje, že máte v plánu před tím a určete před navrhování.

4.2. Design and Development Planning

Design Plán by měl obsahovat:
– Definice metodiky, které mají být používány při vývoji výrobku
– Časové plány, odpovědnosti, pracovní úkoly a kontroly pokroku
– Projekt Fáze se rozdělí. To zahrnuje vstup, výstup a ověření výstupu.
– Popis metod a nástrojů, které mají být použity

Plán jakosti by měl obsahovat:
– cíle jakosti
– Kritéria přijatelnosti
– Identifikace plánování, validace a verifikace.
– Odpovědnost za kvalitní činnosti.

Pokud firma chce získat ISO kvalifikaci plány se musí konat ve všech projektech, neboť certifikace ISO je pro celou společnost, a nikoliv pro konkrétní projekty.

4.3 organizačních a technických Rozhraní

Pokud existuje skupina-práce, rozhraní mezi nimi by se měly určit, zdokumentovat a předávat ty, kteří potřebují informace. Dokumentace musí být pravidelně přezkoumávána.

4.4 Konstrukce Input

Požadavky specifikace obsahovat vstup designu ve vývoji softwaru. To lze provést kupujícím nebo připravené dodavatelem pomocí zákonů a předpisů. Další konstrukce vstup zahrnuje návrh kódování, který se používá jako vstup pro kódování.

Standardní chce zajistit, aby výsledný produkt z každého stupně splňuje požadavky.

Ve vývoji softwaru, změny požadavku jsou časté, takže se vytvoří postup pro zacházení nové a změněné požadavky od kupujícího.

4.5 Provedení Výstup

Provedení Výstup: projektovou dokumentaci a zdrojový kód. ISO vyžaduje, aby projektová dokumentace a kódování být přezkoumány před propuštěním.

by měl být vytvořen postup pro přijetí výstupu designu a kritéria přijetí.

4,6 Design Review

Projekt funkce jako kódování a testování musí být předložena na přezkoumání. Běžnou metodou pro zajištění hodnocení jsou kontrolní seznamy.

4.7 Provedení ověřování

Ta se skládá z recenzí, testování modulu a testování integrace.

4,8 design Validation

Závěrečný test systému, kompletního softwarového produktu spolu s přezkoumávání návodu k obsluze. Tam by měla být plánována a zdokumentovány validaci. Beta testování je v souladu s normou ISO, pokud testování beta je kryta jasné dohody mezi dodavatelem a beta-testování zákazníka.

4.9 Změny designu

ISO 9001 vyžaduje, aby po uvolnění projektové dokumentace nebo zdroje, všechny změny musí projít formálním procesem, kde jsou změny zdokumentován, zkontrolovány a schváleny před zavedením.

Nekontrolované změny složitých technických dokumentů nebo programů jsou extrémně nebezpečné a jako takový standard to nedovoluje.
5. Dokument dat a řízení

Informace, které řídí vývoj / údržbu softwaru. Norma požaduje, aby ti, kteří potřebují nějaký dokument / data musí mít přístup k němu. Změny dokumentů a dat musí být řízena.

5.1 Všeobecně

Externí dokumenty a údaje musí být skladovány. To může být uloženy na jakékoliv podobě (tištěná kopie, elektronických médiích).

5.2 Dokument a data schválení a vydání

Před vydávat dokumenty a údaje musí být zkontrolovány a schváleny před každým vydání. Seznam dokumentů, v nichž jedna musí zjistit aktuální verzi dokumentu. Neplatné nebo zastaralé dokumenty by měly být odstraněny nebo jasně označeny.

5.3 Dokument a změny dat

musí být specifikovány Osoba / y na starosti procesu kontroly a schvalování.

6. Nákup

V případě subdodavatele, jste stále zodpovědný. Tj. pokud budete žádat o smlouvy a zadat práci, normy ISO je stále pod vaší zodpovědnosti a požadavky ISO nemusejí být uložena na subdodavatele.

6.1 Všeobecně

Pokud je pracovní síla zakoupen, standard vyžaduje, abyste sledovat postup, který dostanete ty správné lidi. Lidé budou řízeny dodavatele a nikoliv subdodavatele.
Aby bylo zajištěno, že zakoupený software ve shodě s požadavky:
– Požadavky smlouva o postupech subdodavatelů
– Audit systému jakosti subdodavatele
– Zkontrolujte, zda subdodavatel minulé výkonnosti
– Průzkum subdodavatele v průběhu zakázky
– Revize a zkoušky Witness
– Test a kontrola produkt subdodavatele.

6.2 Vyhodnocení subdodavatelů

Osoba s potřebnou pravomocí a kompetencí bude soudit každého subdodavatele a rozhodnout, zda se má použít. Rozhodnutí musí být dokumentována.

Dodavatel musí rozhodnout, co kontrolu nad subdodavateli to bude mít. Norma neuvádí, jak velkou kontrolu byste měli mít. Je to prostě uvádí, že rozhodnutí by mělo být provedeno pomocí faktů.

Zvláštním případem je, když je software zakoupit prostřednictvím maloobchodu. V tomto případě subdodavatelem je organizace, s nimiž se jedná o nákup proveden, není původní vývojář softwaru.

Je-li kupní provádí prostřednictvím maloobchodní ISO 9001 vyžaduje, aby definovat, do jaké míry vznést požadavky na prodejce ke kontrole svého dodavatele.

6.3 Nákup dat

Požadavky na vývojovém procesu musí být dokumentována ve smlouvě spolu s požadavky dodavatelů na schválení pracovní výsledky a postupy.

6.4 Ověření zakoupeného výrobku

Dokumentace rozhodování o ověření každé zakoupené vývojový nástroj nebo součástí produktu.

– Žádný seznam schválených dodavatelů
– Nevhodné řízení subdodavatele
– Bez ověření dokumentů vydražených položek
– Nevhodný smlouva s subdodavatele.

7 Kontrola dodaných zákazníkem Produkt

Dodavatel musí mít zavedeny postupy pro ověřování, skladování a údržby zákaznického dodaného softwaru. Nicméně, kvalita je odpovědností softwaru.

Non-shoda se stane kvůli nejasnému odpovědnosti odpovědnosti mezi zákazníkem a dodavatelem.

8 Specifikace výrobku a sledovatelnost

Dodavatel software by měl udržet kontrolu na:
– Na co předchází dokument a vydávat jej vychází
– Na kterém specifikace je založena
– Jaké opravy a změny byly zahrnuty do jakého zdroje programů
– Co se stalo s každou zprávu problému
– Z jakého zdroje byl specifický modul generována.

9 Process Control

Dokumentovaný postup pro procesu replikace na operaci a postup pro nakládání s master Proma € ™ s / knihoven. Aby bylo zajištěno, že správná správa verzí je použita.

– Ne dokumentovaný postup pro replikaci
– Nesprávná manipulace mistra Proma € ™ s nebo diskety.

10 Kontrola a testování

Písemné postupy pro kontrolu a zkoušky musí být prováděny v souvislosti s replikací.

– Funkce automatické kontroly Proma € ™ s nebyla podrobena inspekci
– Ne dokumentovaný postup pro testování Proma € ™ s.

11 Kontrola inspekce, měřicí a zkušební zařízení

Dodavatel by měl zvolit odpovídající měřicí zařízení a dodržovat dokumentovaný postup pro kontrolu zařízení. Každá nová verze softwaru by měly být testovány na dostatku.

12 prohlídka a zkouška Status

Zadávací dokumentaci a programy by měly ověřena pomocí recenzí a testování. Dodavatel musí mít postupy, které zakazují používání neověřených specifikací nebo programy.

13 Kontrola nevyhovujících Produkt

Nevyhovujících výrobků by neměly být používány neúmyslně. by měl být vytvořen postup pro manipulaci rychlé změny v případě kritické chyby.

– Jasná identifikace kontrolovaných položek, které obsahují neopravené chyby
– Metoda vyvolat převzetí zákazníkem při dodání
– V případě rychlých úprav, musí být doložena
– Revize takže modifikované položky bude povýšena na stejné postavení jako ostatní software.

14 nápravná a preventivní opatření

– Efektivní nakládání zpráv, které nesplňují požadavky
– Efektivní nakládání zprávy ukazují, že krátké-příchody v procesu vývoje
– Aktivní sběr a analýza dostupných informací o produktu a procesu neshody a preventivních opatření.

Informace o problémech by měl řídit zlepšení procesu vývoje.

– Stížnost Zákazník nebyl správně zacházet
– Nedostatek bylo zjištěno, ale ne opravit
– Žádný postup, aby zajistily, že problémy jsou analyzovány a jednal
– Žádný postup pro hlášení potíže s uplatňováním pravidel a postupů.

15 Manipulace, skladování, balení, ochrana a dodávání

Platí pro software replikovány na PROM, disku nebo jiném médiu.
Média musí být označeny a správně zabalené. Data musí být zálohována. Mělo by být také schopnost poskytovat ochranu před neúmyslným poškozením.

16 kontrola kvality Records

Kvalitní dokumenty ukazují, které byly podniknuty kroky k zajištění nebo kontrolovat kvalitu. Norma požaduje, aby existovat postup pro zacházení s záznamů o jakosti. Záznamy by měly být skladovány vhodným způsobem tak, aby byly snadno přístupné.
– Žádná pravidla pro uchovávání záznamů o jakosti
– Review záznamy nejsou uchovávány
– Zkušební záznamy nejsou uchovávány
– Doba evidence kvality není definováno

17 Vnitřní kontrola jakosti

Tam by měl být nezávislý subjekt, který pravidelně prověřuje všechny operace, které by mohly ovlivnit kvalitu produktu nebo služby. Ty jsou řízeny jménem vedení společnosti. Tam by měl být plán auditu.

– Žádný plán auditu
– Plán auditu není aktuální

18 Training

Společnost by měla zajistit, aby pracovníci jsou vyškoleni pro úkoly, které požadují. Postup na:
– Identifikovat potřeby školení pro každou pozici zaměstnanců
– Poskytnout takový výcvik
– Vést záznamy o školení všech zaměstnanců.

Školení by mělo být zdokumentováno a dostatečné. Dostatečnou máme na mysli, že osoba, byly schopny vykonávat jeho / její práci na dostatečně vysoké úrovni.

– Žádné postupy pro plánování nebo školení
– Žádné záznamy o výcviku
– Ne obdržel řádný výcvik pro jeho úkol.

19 Servis

Dodavatel musí mít dokumentované postupy pro provádění servisu, pokud je to uvedeno ve smlouvě. V softwaru je o opravách chyb a vylepšení dodávaného softwaru.

Postupy pro vyřizování stížností a žádostí o změny. Dodavatel není povinen poskytovat výživné, pokud není uvedeno ve smlouvě. Měl by být uveden postupy údržby, pro starý software.

– Údržbové práce pro zákazníka bez smlouvy
– Specifické metody pro údržbu starého výrobku není popsána
– Ne postup pro zkoušení po údržbě.

20 statistických technik

Tam by měl být sběr a analýza dat o počtu chyb zjištěných v různých fázích. Je nutno analyzovat informace o neschopnosti plnit termíny a milníky.


Support translation:
ISO 9001 Twenty Quality Elements

A look will be taken at the requirements from the viewpoint of companies developing software. ISO 9001 standard was intended for the manufacturing industry. The requirements are interpreted for software development in accordance with ISO 9000-3 and TickIT.

There are 20 main elements. Each concept is well known in the quality management community.

1. Management Responsibility

1.1 Quality policy

The standard requires the supplier management to issue a quality policy, where it says the company shall produce quality products.

The quality policy shall:
– Define the management’s commitment to quality
– Define the company’s objectives regarding quality, that is, what management means by quality
– Be relevant to the customer’s needs
– Be understood in the organization
– Be implemented


– Statement too vague or policy is not understood by staff
– Quality policy is not implemented.

E.g. of Quality policy

“We achieve quality through motivated and skilled staff, defined work procedures, and intensive review and testing activities.”

1.2 Organization

The standard requires documentation of responsibility, authority and interrelation of all personnel affecting quality. This means that if a person has a responsibility, it shall be formally assigned by the appropriate manager. The person should have the authority to fulfil the responsibility.

According to ISO, responsibility means:

“a duty to act on one’s own accord when something has to be done without being told”.


– Existing of a responsibility that cannot be fulfilled.


– Project-line
– Project-customer
– Project-maintenance organisation
– Software development-hardware development
– Maintenance organisation-help desk
– Sales-development

Resources require that the supplier:
– Identify the requirements for resources
– Assign trained personnel.

Management representative requires appointment of manager representative with authority and responsibility to:
– Ensure that the company fulfils the requirements in ISO 9001
– Report the performance of the quality system to company management

1.3 Management Review

Quality manager should periodically present the results of
– Quality audits
– Statistics of quality complaints
– Records of corrective action

The results should be presented at a recorded management meeting with notes on who attended, what was presented and what decisions were taken and made.

2. Quality System

Quality system – “the organizational structure, responsibilities, procedures, processes and resources for implementing quality management.”

Procedures, rules, decisions shall be put into writing. If you have a rule or procedure that is not required by ISO 9001, the standard still requires that it is written.

A quality manual shall contain reference and documentation of the quality system.


– An audit is a sample, therefore if in a sample, there are minor non-conformances, and they are fixed, it can still be a non-conformance because the auditor can suspect that there are many more minor non-conformances.
– Existing written procedures are not adhered to.

3. Contract Review

The supplier checks before signing contract that the organisation be able to perform what is required by the contract.

Questions that should be asked include:
– Are the requirements documented and understood?
– Are acceptance criteria included?
– Have requirements differing from the tender been resolved?
– Can the supplier muster enough resources for the contract?
– Can the supplier muster the competence needed for the contract?
– Can the task be completed in time?

The standard requires that a documented procedure with reviews be included. The supplier should identify how contract amendments and handling of requirements specification between customer and supplier be defined.

4. Design Control

4.1. General
ISO requires that you plan before doing and specify before designing.

4.2. Design and Development Planning

Design plan should contain:
– Definition of methodology to be used in development of product
– Time schedules, responsibilities, work assignments and progress control
– Phases project will be divided. This includes input, output and verification of output.
– Description of methods and tools to be used

Quality plan should contain:
– Quality targets
– Criteria for acceptability
– Identification of planning, validation and verification.
– Responsibilities for quality activities.

If a company wants to gain ISO qualification the plans must be held in all projects, since ISO certification is for the whole company and not for specific projects.

4.3 Organizational and Technical Interfaces

If there is group-work, the interfaces between them should be identified, documented and transmitted to those needing the information. The documentation shall be reviewed regularly.

4.4 Design Input

Requirements specifications contain the design input in software development. This may be done by the purchaser or prepared by the supplier using laws and regulations. Another design input includes design coding which is used as input to coding.

The standard wants to ensure that the work product of each step meets the requirements.

In software development, requirement changes are common so a procedure for handling new and changed requirements from the purchaser be created.

4.5 Design Output

Design Output: the design documentation and the source code. ISO requires that design documents and coding be reviewed before release.

A procedure for acceptance of the design output and criteria of acceptance should be created.

4.6 Design Review

Project functions like coding and testing shall be presented at the review. A common method for ensuring reviews are checklists.

4.7 Design Verification

This consists of reviews, module testing and integration testing.

4.8 Design Validation

Final system test, of the complete software product together with the reviewing of user documentation. There should be planned and documented validation. Beta testing is in conformance with ISO as long as the beta testing is covered by a clear agreement between supplier and beta-testing customer.

4.9 Design Changes

ISO 9001 requires that after release of design documentation or source, all changes shall go through a formal process where changes are documented, reviewed and approved before implementation.

Uncontrolled changes to complex technical documents or programs are extremely dangerous and as such the standard does not allow it.
5. Document and Data Control

Information that controls the development/maintenance of software. The standard requires that those who need some document/data shall have access to it. Changes to documents and data shall be controlled.

5.1 General

External documents and data shall be stored. It can be stored on any form (hard copy, electronic media).

5.2 Document and Data Approval and Issue

Before issue documents and data shall be reviewed and approved before each issue. A document list in which one shall find out the current version of a document. Invalid or obsolete documents should be removed or clearly marked.

5.3 Document and Data Changes

The person/s in charge of the review and approval process shall be specified.

6. Purchasing

In the case of subcontractor, you are still responsible. I.e. if you apply for a contract and subcontract the work, ISO standards is still under your responsibility and ISO requirements do not have to be imposed on the subcontractor.

6.1 General

If manpower is purchased, the standard requires you to follow a procedure that you get the right people. The people will be controlled by supplier and not subcontractor.
To ensure that purchased software conforms to requirements:
– Contract requirements on the subcontractors procedures
– Audit of the subcontractor quality system
– Check subcontractor past performance
– Survey the subcontractor during contract
– Witness review and testing
– Test and review product of subcontractor.

6.2 Evaluation of Subcontractors

Person with necessary authority and competence shall judge each subcontractor and decide whether to use. The decisions shall be documented.

The supplier shall decide what control over subcontractor it will have. The standard does not mention how much control you should have. It just mentions that a decision should be made by using facts.

A special case is when software is purchased through retail. In this case subcontractor is organization with which the purchase is conducted, not the original developer of the software.

If purchasing is done through retail ISO 9001 requires that you define to what extent you put requirements on the retailer to control its supplier.

6.3 Purchasing Data

Requirements on development process shall be documented in the contract along with supplier requirements to approve work results and procedures.

6.4 Verification of Purchased Product

Documentation of decisions about the verification of each purchased development tool or included product.

– No list of approved suppliers
– Inappropriate control of subcontractor
– No document verification of purchased items
– Inappropriate contract with subcontractor.

7 Control of Customer-supplied Product

The supplier shall have procedures for verification, storage and maintenance of customer supplied software. However, the quality is the responsibility of the software.

A non-conformance happens due to unclear responsibility of responsibility between customer and supplier.

8 Product Specification and Traceability

The software supplier should keep control on:
– On what preceding document and issue it is based
– On which specification it is based
– What corrections and amendments have been included in which source programs
– What happened to each problem report
– From what source was a specific module generated.

9 Process Control

Documented procedure for the replication process in the operation and procedure for handling of master PROM’s/libraries. To ensure that correct versioning is used.

– No documented procedure for replication
– Improper handling of master PROM’s or diskettes.

10 Inspection and Testing

Written procedures for the inspection and testing to be done in connection with replication.

– Function of automatically checking PROM’s has not been inspected
– No documented procedure for testing PROM’s.

11 Control of Inspection, Measuring and Test Equipment

The supplier should select the appropriate measuring equipment and follow a documented procedure for control of equipment. Each new software version should be tested for sufficiency.

12 Inspection and Test Status

Specifications and programs should verified through reviews and testing. The supplier shall have procedures that prohibit use of unverified specifications or programs.

13 Control of Non-conforming Product

Non-conforming products should not be used unintentionally. A procedure for handling quick modifications in case of critical errors should be created.

– Clear identification of controlled items that contain uncorrected errors
– Method to elicit customer acceptance upon delivery
– In case of quick modifications, it must be documented
– Reviewing so modified items will be elevated to same status as rest of software.

14 Corrective and Preventive Action

– Effective handling of reports that do not conform to requirements
– Effective handling of reports indicating short-comings in the development process
– Active collection and analysis of available information about product and process non-conformance and preventive actions.

Information about problems encountered should drive improvements of the development process.

– Customer complaint has not been properly handled
– Deficiency has been found but not corrected
– No procedure to ensure that problems are analyzed and acted upon
– No procedure for reporting difficulties with applying rules and procedures.

15 Handling, Storage, Packaging, Preservation and Delivery

Applies to software replicated on PROM, disk or other medium.
Media shall be labelled and packaged correctly. Data shall be backed up. There should also be the ability to provide protection from unintentional damage.

16 Control of Quality Records

Quality documents show which actions have been taken to ensure or check quality. The standard requires that there be a procedure for handling of quality records. The records should be stored in an appropriate manner so they are easily accessible.
– No rules for retention of quality records
– Review records are not kept
– Test records are not kept
– Period of keeping quality records is not defined

17 Internal Quality Audits

There should be an independent entity that regularly audits all operations that may affect product or service quality. These are conducted on behalf of company management. There should be an audit plan.

– No audit plan
– Audit plan not up to date

18 Training

Company should ensure that staff is trained for tasks required. A procedure to:
– Identify training needs for each staff position
– Provide such training
– Keep records of the training of all staff members.

Training should be documented and sufficient. By sufficient we mean that the person be capable of performing his/her work to a high enough standard.

– No procedures for planning or training
– No training records
– Not received proper training for his or her task.

19 Servicing

Supplier shall have documented procedures for servicing if this is mentioned in the contract. In software it is about error corrections and enhancements to delivered software.

Procedures for handling complaints and requests for modifications. The supplier is not obliged to provide maintenance if it is not mentioned in contract. Maintenance procedures for old software should be made.

– Maintenance work for a customer without a contract
– Specific methods for maintenance of old product is not documented
– No procedure for testing after maintenance.

20 Statistical Techniques

There should be collection and analysis of data about number of errors found in the different phases. Information about inability to meet deadlines and milestones should be analyzed.

“————————————————– ————————————————– ————————————————–

Subteno traduko:
————————————————– ————————————————– ————————————————–
ISO 9001 Dudek Kvalito Elementoj

Rigardo estos prenita ĉe la postuloj de la vidpunkto de kompanioj disvolvi programaron. ISO 9001 normo estis celita por la fabrikado industrio. La postuloj estas interpretitaj por softvarigo laŭ ISO 9000-3 kaj TickIT.

Ekzistas 20 ĉefaj elementoj. Ĉiu koncepto estas bone konata en la kvalito mastrumado komunumo.

1. Administrado Respondeco

1.1 Kvalito privateco

La normo postulas la provizanto demarŝo eldoni kvalito politikon, kie diras la amaso ili produktas kvalito produktoj.

La kvalito politiko estos:
– Difini la managementâ € ™ s devontigo al kvalito
– Difini la companyâ € ™ s celojn rilate kvalito, tio estas, kion mastrumado signifas por kvalito
– Estu rilata al la customerâ € ™ s bezonoj
– Estu komprenita en la organizo
– Estu implementado

Ne- conformances

– Komunikaĵo tro pigraj aŭ politiko ne komprenata de kunlaborantaro
– Kvalito politiko ne efektivigitaj.

Ekz-e de Kvalito privateco

â € œWe atingi kvaliton per motivita kaj sperta personaro, difinita laboro proceduroj kaj intensa revizio kaj elprovanta activities.â €

1.2 Organizo

La normo postulas dokumentadon de respondeco, aŭtoritato kaj interrilato de ĉiuj dungitaro influanta kvaliton. Tio signifas ke se persono havas respondecon, ĝi estos formale atribuita de la konvena direktisto. La persono devus havi la aŭtoritaton plenumi la respondecon.

Laŭ ISO, respondeco signifas:

â € OEA devon agi sur oneâ € ™ s propravole kiam io devas esti farita sen toldâ €.

Ne- conformidad

– Ekzistantaj de respondeco kiu ne povas esti plenumita.


– Projekto-linio
– Projekto-kliento
– Projekto-bontenado organizo
– Programaro evoluo-aparataro disvolviĝo
– Bontenado organizo-helpo skribtablo
– Sales-disvolviĝo

Rimedoj postulas ke la provizanto:
– Identigi la postuloj por rimedoj
– Asigni trejnita personaro.

Demarŝo reprezentanto postulas nomumon de manaĝero reprezentanto kun aŭtoritato kaj respondeco por:
– Certigi ke la entrepreno plenumas la postulojn en ISO 9001
– Raportu al la rendimento de la sistemo de kvalito por entrepreno mastrumado

1.3 Administrado Revizio

Kvalito manaĝero devus periode prezenti la rezultojn de
– Kvalito auditorías
– Statistiko de kvalito plendoj
– Rekordoj de korekto ago

La rezultoj devus esti prezentitaj ĉe registrita demarŝo renkontiĝo kun notoj sur kiuj ĉeestis, kio estis prezentita kaj kion decidoj prenitaj kaj farita.

2. Kvalito Sistemon

Kvalito sistemo â € “”â € œthe organizan strukturon, respondecoj, proceduroj, procezoj kaj resursoj por efektivigado kvalito management.â €

Proceduroj, reguloj, decidoj estos metita en skribo. Se vi havas regulon aŭ proceduro kiu ne postulas ISO 9001, la normo ankoraŭ postulas ke ĝi estas skribita.

Al kvalito manlibro devas enhavi referencon kaj dokumentado de la kvalito sistemo.

Ne- conformidad

– An auditoría estas specimeno, do se en specimeno, estas malgranda ne-conformances kaj ili riparas, ĝi povas ankoraŭ esti ne- conformidad ĉar la aŭditoro povas suspekti ke ekzistas multaj pli malgrandaj ne-conformances.
– Ekzistanta skribita proceduroj ne aliĝis al.

3. Kontrakto Revizio

La provizanto kontroloj antaŭ subskribo kontrakto ke la organizo povos plenumi kion estas postulita de la kontrakto.

Demandoj kiuj devus esti demandita inkludas:
– Ĉu la postuloj dokumentita kaj komprenis?
– Ĉu akcepto kriterioj inkludas?
– Ĉu postuloj diferencante de la mola estis solvita?
– Ne la provizanto kunveni sufiĉajn rimedojn por la kontrakto?
– Ne la provizanto kunveni la kompetenteco bezonata por la kontrakto?
– Ĉu la tasko estos finita ĝustatempe?

La normo postulas ke dokumentita procedo kun recenzoj estos inkluzivita. La provizanto devus identigi kiel kontrakto amendoj kaj uzado de postuloj specifo inter kliento kaj provizanto esti difinita.

4. Dezajno Kontrolo

4.1. ĝenerala
ISO postulas ke vi planas antaŭ fari kaj specifi antaŭ desegni.

4.2. Dezajno kaj Disvolviĝo Planado

Dezajno plano devus enhavi:
– Difino de metodiko por esti uzita en la disvolviĝo de produktoj
– Tempo horaroj, respondecoj, laboro taskoj kaj progreso kontrolo
– Fazo projekto estos dividita. Tio inkluzivas enigo, eligo kaj konfirmo de eligo.
– Priskribo de metodoj kaj iloj por uzi

Kvalito plano devus enhavi:
– Kvalito celoj
– Kriterioj por akcepteblo
– Identigo de planado, validumado kaj konfirmo.
– Respondecoj por kvalito aktivecoj.

Se entrepreno volas gajni ISO kvalifiko la planoj devas kateni cxiujn projektojn, ekde ISO atestado estas por la tuta kompanio kaj ne por specifaj projektoj.

4.3 Organiza kaj teknika Interfacoj

Se ekzistas grupo-laboro, la interfacoj inter ili devus esti identigitaj, dokumentita kaj transdonita al tiuj bezonante la informo. La dokumentado estos reviziitaj regule.

4.4 Dezajno Importa

Postuloj especificaciones enhavas la dezajnon enigo en softvarigo. Tio povas esti farita de la aĉetanto aŭ preparita de la provizanto uzante leĝoj kaj regularoj. Alia dezajno enigo inkludas dezajnon kodigo kiu estas uzata kiel enigo al kodigo.

La normo volas certigi ke la laboro produkto de ĉiu paŝo renkontas la postulojn.

En softvarigo, postulo ŝanĝoj estas oftaj tiel proceduro por manipuli novaj kaj ŝanĝita postuloj de la aĉetanto rekreita.

4.5 Dezajno Eligo

Dezajno Eligo: la dezajno dokumentado kaj la kodo fonto. ISO postulas ke dezajno dokumentoj kaj kodigo reviziita antaŭ liberigo.

A proceduro por akcepto de la dezajno eligo kaj kriterioj de akcepto devas esti kreitaj.

4.6 Dezajno Review

Projekto funkcioj kiel kodigon kaj testado estos prezentita en la recenzo. Komuna maniero por certigi recenzoj estas checklists.

4.7 Dezajno Verification

Tiu konsistas recenzoj, modulo testado kaj integriĝo testado.

4.8 Dezajno Validigo

Fina sistemo provo, de la kompleta programaro produkto kune kun la revizianta de uzanto dokumentado. Tie devus esti planita kaj dokumentita validación. Beta testado estas en conformidad kun ISO dum la beta testado estas kovrita per klara interkonsento inter provizanto kaj beta-testado kliento.

4.9 Dezajno Ŝanĝoj

ISO 9001 postulas ke post liberigo de dezajno dokumentado aŭ fonto, ĉiuj ŝanĝoj estos iri tra formala procezo kie ŝanĝoj estas dokumentitaj, reviziita kaj aprobita antaŭ efektivigo.

Descontrolada ŝanĝoj kompleksajn teknikajn dokumentojn aŭ programoj estas ekstreme danĝera kaj kiel tia la normo ne permesas.
5. Dokumento kaj Datumoj Kontrolo

Informo kiu kontrolas la disvolviĝon / bontenado de programaro. La normo postulas ke tiuj kiuj bezonas iun dokumenton / datumoj havos aliron al ĝi. Ŝanĝoj al dokumentoj kaj datumoj estos kontrolita.

5.1 Ĝenerala

Eksteraj dokumentoj kaj datumoj estos stokitaj. Ĝi povas esti stokita en ajna formo (papere, elektronikaj komunikiloj).

5.2 Dokumento kaj Datumoj Aprobo kaj Issue

Antaŭ afero dokumentoj kaj datumoj devas esti reviziita kaj aprobita antaŭ ĉiu temo. Dokumento lerta en kiu trovos la nuna versio de dokumento. Nevalida aŭ malaktualaj dokumentoj devus esti forigita aŭ klare markita.

5.3 Dokumento kaj Datumoj Ŝanĝoj

La persono / s zorge de la revizio kaj aprobo procezo estos specifita.

6. Purchasing

En la kazo de subkontraktisto, vi ankoraŭ respondecas. Tio estas: se vi kandidatiĝas por kontrakto kaj subcontratan la verkon, ISO normoj estas ankoraŭ sub via respondeco kaj ISO postuloj ne devas esti trudita sur la subkontraktisto.

6.1 Ĝenerala

Se laborforto estas aĉetitaj, la normo postulas vin sekvi proceduron ke vi akiras la ĝustajn homojn. La homoj estos kontrolita de provizanto kaj ne subkontraktisto.
Certigi ke aĉetis programaron laŭigas al postuloj:
– Kontrakto postulojn sur la subkontraktistoj proceduroj
– Audit de la subkontraktisto kvalito sistemo
– Kontroli subkontraktisto pasinteco agado
– Enketo la subkontraktisto dum kontrakto
– Atestanto revizio kaj testado
– Testo kaj revizio produkto de subkontraktisto.

6.2 Taksado de Subcontratistas

Persono kun necesa aŭtoritato kaj kompetenteco juĝos ĉiun subkontraktisto kaj decidi ĉu uzi. La decidoj estu dokumentitaj.

La provizanto devas decidi kion kontrolon super subkontraktisto havos. La normo ne mencii kiom kontrolo vi devus havi. Ĝi nur mencias ke decido estu farita uzante faktojn.

Speciala kazo estas kiam programaro estas aĉetita tra detalisto. Tiukaze subkontraktisto estas organizo kun kiu la aĉeto estas farita, ne la origina evoluiganto de la programaro.

Se aĉetado estas farita tra podetalaj ISO 9001 postulas ke vi difinas al kiu grado vi metis postulojn sur la komercisto kontroli lia provizanto.

6.3 Aĉetado Datumoj

Postulojn sur disvolviĝo procezo estos dokumentitaj en la kontrakto kune kun provizanto postuloj aprobi laboron rezultoj kaj proceduroj.

6.4 Konfirmo de aĉetita produkto

Dokumentado de decidoj pri la konfirmo de ĉiu aĉetita disvolviĝo ilo aŭ inkluzivita produkto.
Ne- conformidad

– Neniu listo de aprobita provizantoj
– Netaŭga kontrolo de subkontraktisto
– Neniu dokumento comprobación aĉetis erojn
– Netaŭga kontrakton kun subkontraktisto.

7 Kontrolo de Kliento-provizitaj Produkto

La provizanto havos procedurojn por konfirmo, stokado kaj konservado de kliento liveris programaron. Tamen, la kvalito estas la respondeco de la programaro.

Ne-conformidad okazas pro neklaraj respondeco de respondeco inter kliento kaj provizanto.

8 Produkto Specifo kaj trazabilidad

La softvaro provizanto devus teni kontrolon sur:
– Sur kio antaŭan dokumenton kaj emisii ĝi baziĝas
– Sur kiu specifo ĝi baziĝas
– Kio korektojn kaj amendoj estis inkluditaj en kiu fonto programoj
– Kio okazis al ĉiu problemo raporto
– De kio fonto estis specifa modulo generita.

9 Process Control

Dokumentita proceduro por la replicación procezo en la operacio kaj procedo por uzado de mastro PROMâ € ™ s / bibliotekoj. Certigi ke korekta versionado estas uzata.

Ne- conformidad
– Neniu dokumentita proceduro por replicación
– Nepropra uzado de mastro PROMâ € ™ s aŭ disketojn.

10 Inspekto kaj Testado

Skribita proceduroj por la inspektado kaj testado farenda lige kun replicación.

Ne- conformidad
– Funkcio de aŭtomata kontrolanta PROMâ € ™ s ne estis inspektita
– Neniu dokumentita proceduro por elprovanta PROMâ € ™ s.

11 Kontrolo de Inspección, Mezurado kaj Testo Ekipaĵo

La provizanto devus elekti la taŭgajn mezura ekipaĵo kaj sekvi dokumentita procedo por kontrolo de teamo. Ĉiu nova programaro versio devus esti testita por sufiĉeco.

12 Inspekto kaj Testo Statuso

Specifoj kaj programoj devus kontroli per recenzoj kaj testado. La provizanto havos procedurojn kiuj malpermesas uzon de nekonfirmita especificaciones aŭ programoj.

13 Kontrolo de Ne-laŭigante Produkto

Ne-laŭigante produktoj devus esti uzata senintence. Proceduro por manipuli rapida modifoj en kazo de kritiko eraroj devus esti kreita.

– Klara identigo de kontrolitaj celoj kiuj enhavas uncorrected eraroj
– Metodo por ellogi kliento akcepto sur transdono
– En kazo de rapida modifoj, ĝi devas esti dokumentita
– Reviziante tiel modifita eroj estos levita al sama statuso kiel cetera programaro.

14 Korekta kaj Preventive Action

– Efika uzado de raportoj kiuj ne konformas al postuloj
– Efika uzado de raportoj indikante mallonga venitaj en la procezo de disvolviĝo
– Aktiva kolekto kaj analizo de uzeblaj informoj pri produkto kaj procezo ne conformidad kaj preventaj agoj.

Informo pri problemoj renkontita elpelu plibonigoj de la procezo de disvolviĝo.

Ne- conformidad
– Kliento plendo ne estis konvene pritraktita
– Deficiencia estis trovita sed ne korektis
– Neniu proceduro por certigi ke problemoj estas analizitaj kaj agis sur
– Neniu proceduro por informi malfacilaĵojn kun aplikanta reguloj kaj proceduroj.

15 Handling, Tenado, Prezentanta, Preservation kaj Delivery

Koncernas programaro reproduktita sur PROM, disko aŭ alia rimedo.
Komunikiloj estos labeled kaj pakita korekte. Datumoj estos subtenita supre. Tie ankaŭ devus esti la kapablon provizi protekton de intenca damaĝo.

16 Kontrolo de Kvalito Records

Kvalito dokumentoj montras ke agoj estis prenitaj por certigi aŭ kontroli kvaliton. La normo postulas ke estu proceduron por uzado de kvalito rekordojn. La registroj devus esti stokita en taŭga maniero por ili estas facile alirebla.
Ne- conformances:
– Neniu reguloj por reteno de kvalito rekordojn
– Revizio registroj ne tenis
– Testo registroj ne tenis
– Periodo de tenanta kvalito registroj ne estas difinita

17 Interna Kvalito auditorías

Tie devus esti sendependa ento kiu regule auditorías ĉiuj operacioj kiuj povas tuŝi produkto aŭ servo kvalito. Tiuj efektivigatajn nome de entrepreno mastrumado. Malaperis auditoría planon.

Ne- conformidad
– Neniu auditoría planon
– Audit plano ne ĝisdata

18 Trejnado

Kompanio devus certigi ke kunlaborantaro estas trejnita por taskoj postulitaj. Proceduro por:
– Identigi trejnado bezonoj por ĉiu kunlaborantaro pozicio
– Provizi tia trejnado
– Daŭrigu notoj pri la trejnado de ĉiuj laborantaranoj.

Trejnado devus esti dokumentitaj kaj sufiĉa. Per sufiĉa ni signifi ke la persono esti kapabla de realigi lia / ŝia laboro al alta sufiĉa normo.

Ne- conformidad
– Neniu proceduroj por planado aŭ trejnado
– Neniu trejnado rekordojn
– Ne ricevis konvenan trejnadon por lia aŭ ŝia tasko.

19 Servicing

Provizanto estos dokumentitaj procedoj por Servon se tio estas menciita en la kontrakto. En programaro temas pri eraro korektoj kaj plibonigoj al transdonis programaro.

Proceduroj por manipuli plendoj kaj petoj por modifoj. La provizanto ne estas devigita provizi bontenado se ĝi ne estas menciita en kontrakto. Bontenado proceduroj por malnova programaro estu.

Ne- conformidad
– Bontenado laboro por kliento sen kontrakto
– Specifaj metodoj por bontenado de malnova produkto ne dokumentita
– Neniu proceduro por testado post bontenado.

20 Statistikaj Teknikoj

Malaperis kolekto kaj analizo de datumoj pri kelkaj eraroj trovitaj en la malsamaj fazoj. Informo pri malkapablo renkonti templimojn kaj mejloŝtonoj devus esti analizita.

“————————————————– ————————————————– ————————————————–

Tõlkimise toetamise:
————————————————– ————————————————– ————————————————–
ISO 9001 Kakskümmend kvaliteet Elements

Pilk on võetud nõuete seisukohalt ettevõtted arendada tarkvara. ISO 9001 standardile oli mõeldud töötlev tööstus. Nõuded on tõlgendatud tarkvaraarenduse vastavalt ISO 9000-3 ja TickIT.

Seal on 20 põhielementi. Iga mõiste on tuntud kvaliteedijuhtimise kogukonnas.

1. juhtimiskohustusega

1.1 Kvaliteedi poliitika

Standard nõuab tarnija juhtimise väljastada kvaliteedi poliitika, kus ta ütleb, et firma peab tootma kvaliteetseid tooteid.

Kvaliteedi poliitika:
– Määrake managementâ € ™ s pühendumust kvaliteedile
– Määrake companyâ € ™ s eesmärgid kvaliteet, see tähendab, mida juhtkond tähendab kvaliteet
– Olema seotud customerâ € ™ s vajadustele
– Mõista organisatsiooni
– Rakendada


– Avaldus liiga ebamäärane või poliitika ei mõista töötajad
– Kvaliteedi poliitika ei rakendata.

Näiteks Kvaliteedi poliitika

ā € œWe saavutada kvaliteeti läbi motiveeritud ja kvalifitseeritud personal määratletud tööprotseduuride ja intensiivne läbivaatamise ja katsetamise activities.â €

1.2 Organisatsioon

Standard nõuab dokumentatsiooni vastutuse, võimupiirid ja vastastikused kõik töötajad mõjutavad kvaliteeti. See tähendab, et kui inimene on kohustus, tuleb formaalselt määratud sobiv juht. Inimene peaks olema õigus täita kohustust.

Vastavalt ISO, vastutus tähendab:

ā € kristallides kohustus tegutseda oneâ € ™ s omal soovil, kui midagi on vaja teha, ilma et toldâ €.


– Olemasolevad on kohustus, mida ei saa täita.


– Project-line
– Project-kliendile
– Project-hooldus organisatsioon
– Tarkvaraarendus-riistvara arendamine
– Hooldus organisatsiooni Tehnoabi
– Müük-areng

Vahendid nõuda, et pakkuja:
– Nimetage nõuded ressursse
– Määra koolitatud personal.

Juhtimine vajab esindaja nimetamine juht esindaja, kellel õigus ja kohustus:
– Tagada, et ettevõte vastab ISO 9001
– Raport täitmise kvaliteedisüsteemi, et ettevõtte juhtkond

1.3 Management Review

Kvaliteedijuht peab perioodiliselt esitama tulemused
– Kvaliteediauditid
– Statistika kvaliteeti kaebusi
– Andmed parandusmeetmeid

Tulemused tuleks esitada salvestatud juhtimise kohtumine märkmeid, kes osalesid, mida esitati ja mida võeti vastu otsused ja tehtud.

2. kvaliteedisüsteemi

Kvaliteedisüsteem ā € “”ā € œthe organisatsiooniline struktuur, vastutus, protseduurid, protsessid ja vahendid kvaliteedijuhtimise rakendamiseks management.â €

Protseduurid, eeskirjade, otsuste pannakse kirjalikult. Kui teil on reeglina või protseduur, mis ei nõua ISO 9001, standard nõuab veel, et see on kirjutatud.

Kvaliteedijuhendit peab sisaldama viidet ja dokumentatsiooni kvaliteedisüsteemi.


– Audit on proov, seega, kui proovis on väiksema mittevastavuse ja need on kinnitatud, on see siiski mittevastavus, sest audiitor võib arvata, et seal on palju rohkem väiksema mittevastavuse.
– Olemasolevad kirjalikud protseduurid ei järgita.

3. Leping Review

Tarnija kontrolli enne lepingu allkirjastamist, et organisatsioon oleks võimeline täitma, mida on vaja lepingus.

Küsimused, mida tuleks lisada:
– On nõuded dokumenteeritud ja arusaadav?
– Kas aktsepteerimise kriteeriumid olid?
– Kas erinevaid nõudeid pakkumine on lahendatud?
– Kas tarnija koondada piisavalt ressursse leping?
– Kas tarnija koondada vajaliku pädevuse leping?
– Kas ülesande olla valmis õigeaegselt?

Standard nõuab, et dokumenteeritud protseduuri kommentaare lisada. Tarnija peaks kindlaks lepingu muudatused ja käitlemise nõuete spetsifikatsiooni vahel kliendi ja tarnija määratleda.

4. projekteerimise kontroll

4.1. üld-
ISO eeldab, et sa planeerida enne teeme ja täpsustada enne projekteerimisel.

4.2. Design ja Development Planning

Design plaan peaks sisaldama:
– Mõiste kasutatav metoodika väljatöötamisel toote
– Sõiduplaanid, vastutus, tööülesanded ja edu kontroll
– Faasid Projekt jagatakse. See hõlmab sisend, väljund ja kontroll väljund.
– Kirjeldus meetodeid ja vahendeid, mida kasutatakse

Kvaliteedi plaan peaks sisaldama:
– Kvaliteet eesmärgid
– Kriteeriumid vastuvõetavuse
– Identifitseerimine planeerimine, valideerimise ja kontrollimise.
– Vastutus kvaliteedi tegevust.

Kui ettevõte soovib saada ISO kvalifikatsiooni plaanid tuleb hoida kõiki projekte, sest ISO sertifitseerimine on kogu firma ja mitte konkreetseid projekte.

4.3 organisatsiooniliste ja tehniliste liideste

Kui on grupitöö, nendevaheliste liidestega tuleks määratleda, dokumenteerida ja edastada need vajavad teavet. Dokumentatsioon tuleb regulaarselt üle vaadata.

4.4 Design sisend

Nõuded spetsifikatsioonid sisaldavad disain sisend tarkvara arendamiseks. Seda võib teha kas ostja või koostatud tarnija kasutades seaduste ja määrustega. Teine disain sisend sisaldab disaini kodeerimine mida kasutatakse sisendina kodeerimine.

Standard soovib tagada, et töö toote iga samm vastab nõuetele.

Tarkvaraarenduse, nõude muudatused on ühised nii menetlemise uued ja muutunud nõuded ostjalt luua.

4.5 Design väljund

Design Output: tehnilist dokumentatsiooni ja lähtekoodi. ISO eeldab, et disain dokumendid ja kodeerimine vaadatakse enne vabastamist.

Protseduur vastuvõtmise disaini väljund ja kinnitamise nõuded tuleks luua.

4.6 Design Review

Projekti funktsioone nagu kodeerimine ja testimine tuleb esitada läbivaatamiseks. Levinud meetod, millega tagatakse ülevaateid on kontrollnimekirjad.

4.7 Design kontrollimine

See koosneb ülevaateid, mooduli testimine ja integratsiooni testimine.

4.8 projekteerimise valideerimise

Lõplik süsteemi test, täieliku tarkvara toode koos läbivaatamisel kasutaja dokumentatsiooni. Seal peaks olema planeeritud ja dokumenteeritud valideerimine. Beta testimine on vastavus ISO niikaua Beta testimine on hõlmatud selge kokkuleppel tarnija ja beeta-testimise kliendile.

4.9 projekti muudatused

ISO 9001 nõuab, et pärast vabanemist projektdokumentatsiooni või allikas kõik muudatused läbida ametlik protsess, kus muutused on dokumenteeritud, vaadatakse läbi ja kinnitatakse enne rakendamist.

Kontrollimatu muudatusi keerulisi tehnilisi dokumente ja programme, on äärmiselt ohtlik ja sellisena standard seda ei võimalda.
5. dokumentide ja andmete kontrollimise

Teave, mis kontrollib areng / hooldus tarkvara. Standard nõuab, et need, kes vajavad dokumenti / andmed on juurdepääs. Muudatused dokumendid ja andmed peavad olema kontrollitud.

5.1 Üldine

Väline dokumente ja andmeid säilitatakse. See saab salvestada mistahes vormis (paberkandjal, elektroonilises meedias).

5.2 Dokument ja andmed kinnitamine ja väljastamine

Enne teema dokumentide ja andmete vaadatakse ja heaks kiidetud, enne iga teema. Dokument nimekirja, kus üks peab teada praeguse versiooni dokument. Vigane või vananenud dokumentide tuleks eemaldada või selgelt tähistatud.

5.3 Dokument ja andmete muutused

Isik / s vastutav läbivaatamise ja kinnitamise protsessi tuleb täpsustada.

6. ostmine

Juhul alltöövõtja, siis on ikka vastutab. St kui te taotleda lepingu ja allhankeid, ISO standardid on alles oma vastutust ja ISO nõuded ei pea olema kehtestatud alltöövõtja.

6.1 Üldine

Kui tööjõudu ostetakse, standard nõuab teilt kord, et sa saad õiged inimesed. Inimesed on reguleeritud tarnija ja mitte alltöövõtja.
Selleks, et tagada ostetud tarkvara vastab nõuetele:
– Leping nõuded alltöövõtjatele protseduurid
– Audit alltöövõtja kvaliteedisüsteemi
– Vaata alltöövõtja varasemaid tulemusi
– Kaardistada alltöövõtja ajal lepingu
– Witness läbi ja testimine
– Katsetamine ja läbivaatamine toote alltöövõtja.

6.2 Hindamine alltöövõtjate

Isik vajalikud volitused ja pädevus peab otsustama iga alltöövõtja ja otsustada, kas kasutada. Otsused peavad olema dokumenteeritud.

Tarnija peab otsustama, mida kontrolli alltöövõtja see on. Standard ei maini, kui palju kontrolli te ei tohiks olla. See lihtsalt mainib, et otsus tuleks abil fakte.

Erijuhtum on see, kui tarkvara on ostetud jaemüük. Sel juhul alltöövõtja on organisatsioon, kellega ostu toimub, ei ole algne arendaja tarkvara.

Kui ostu on teinud läbi jaemüük ISO 9001 nõuab, et saab määrata, millises ulatuses paned nõuded jaemüüja kontrollida oma tarnija.

6.3 ostmisega seotud andmete

Nõuded arendamise protsessi tuleb dokumenteerida lepingu koos pakkuja nõuded kinnitab töötulemuste ja protseduure.

6.4 Kontrollimine ostetud toote

Dokumenteerimine otsuseid kontrolli iga ostetud arengu vahend või nimetamata toode.

– Ei nimekirja heakskiidetud tarnijate
– Sobimatu kontrolli alltöövõtja
– No dokumendi kontrollimise ostetud esemed
– Sobimatu lepingu alltöövõtja.

7 kontroll tarbijainfo Toode

Tarnija peab olema kontrollimise kord, ladustamine ja säilitamine kliendi tarnitud tarkvara. Kuid kvaliteedi eest vastutab tarkvara.

Mittevastavus juhtub tõttu ebaselge vastutuse vastutuse vahel kliendi ja tarnija.

8 Toote spetsifikatsioon ja jälgitavus

Tarkvara tarnija peaks hoidma kontrolli:
– On mida eelneva dokumendi ning annab see põhineb
– On mida spetsifikatsioon see põhineb
– Mis parandused ja muudatused on kantud mis allikast programmid
– Mis juhtus iga probleemi aruande
– Millisest allikast see oli konkreetne moodul loodud.

9 Process Control

Dokumenteeritud korra replikatsiooni protsessi toimimise ja käitlemise korra master Proma € ™ s / raamatukogud. Selleks, et tagada õige versioonideks kasutatakse.

– No dokumenteeritud korra replikatsiooni
– Väär ümberkäimine master Proma € ™ s või disketid.

10 Kontroll ja katsetamine

Kirjalik menetlus ülevaatuse ja katsetamise teha seoses replikatsiooni.

– Funktsioon automaatselt kontrollida Proma € ™ s ei ole kontrollitud
– No dokumenteeritud katsetamise Proma € ™ s.

11 Kontroll Kontroll, mõõtmine ja katseseadmed

Tarnija tuleb valida sobiv mõõteseadmed ning järgige dokumenteeritud korra kontrolli seadmeid. Iga uus tarkvara versioon tuleks testida piisavust.

12 Kontroll ja Test staatus

Tehnilisi kirjeldusi ja programmid peaksid abil kontrollida ülevaateid ja testimine. Tarnija peab olema kord, mis keelavad kasutada kontrollimata kirjelduste või programme.

13 Kontroll Nõuetele mittevastava toote

Mittevastavaid tooteid ei tohi kasutada tahtmatult. Protseduur käitlemise kiire muudatuste puhul kriitiline vigu tuleks luua.

– Selgelt kindlaks kontrollitavaid objekte, mis sisaldavad parandamata vead
– Meetod, et tekitada kliendi heakskiidu üleandmisel
– Juhul quick modifikatsioone tuleb dokumenteerida
– Vaadates seda muuta teemad on tõusnud sama staatus nagu ülejäänud tarkvara.

14 korrigeeriv ja ennetav tegevus

– Tõhus käitlemine aruanded, mis ei vasta nõuetele
– Tõhus käitlemine aruanded näitab puudustelt väljatöötamise protsessi
– Aktiivne kogumine ja analüüs kättesaadava informatsiooni toote ja protsessi mittevastavusi ja ennetavaid meetmeid.

Teave probleemid peaks sõitma parandusi arengus.

– Kliendi kaebus ei ole nõuetekohaselt käidelda
– Puudus on leitud, kuid ei parane
– No menetlus tagamaks, et probleemid on analüüsitud ja tegutseda
– No aruandmise kord raskusi kohaldades eeskirju ja menetlusi.

15 käitlemine, ladustamine, pakendamine, säilitamine ja kohaletoimetamine

Kehtib tarkvara kordama PROM, kettale või muule andmekandjale.
Meedia peab olema märgistatud ja pakendatud korralikult. Andmed tuleb varundada. Samuti tuleks võime pakkuda kaitset tahtmatu kahju.

16 kvaliteedi kontrolli Records

Kvaliteet dokumendid näitavad, millised toimingud on tehtud, et tagada või kontrollida kvaliteeti. Standard nõuab, et seal olla menetlemise kvaliteedi arvestust. Kirjed tuleb hoida sobival viisil, et nad on kergesti kättesaadavad.
– Puuduvad reeglid, mille puhul säilib kvaliteeti tõendavad dokumendid
– Review arvestust ei peeta
– Katseandmed ei hoita
– Periood säilivust arvestust ei ole määratletud

17. Sisemine kvaliteediauditites

Seal peaks olema sõltumatu üksus, mis kontrollib korrapäraselt kõik toimingud, mis võivad mõjutada toote või teenuse kvaliteet. Need toimuvad nimel ettevõtte juhtimine. Seal peaks olema auditi plaani.

– No auditi kava
– Audit plaani ei ole ajakohane

18 koolitus

Ettevõte peab tagama, et töötajad on koolitatud vajalikud ülesanded. Protseduur:
– Nimetage koolitusvajadus iga töötaja positsiooni
– Sellist koolitust
– Pidama arvestust kogu personali koolitust kohal.

Koolitus peab olema dokumenteeritud ja piisav. Piisav me mõtleme, et inimene oleks võimeline täitma oma / tema tööd piisavalt kõrge kvaliteediga.

– No kord planeerimise või koolituse
– No koolitusdokumendid
– Ei saanud korraliku väljaõppe tema ülesanne.

19 teenindamine

Tarnija peab olema dokumenteeritud menetlused teenindamiseks, kui see on lepingus nimetatud. Tarkvara on umbes vigade parandamise ja lisaseadmed tarnitud tarkvara.

Kaebuste käsitlemisel ja taotlusi muudatuste tegemiseks. Tarnija on kohustatud esitama hoolduse, kui see ei ole mainitud lepingu. Hooldus kord vana tarkvara tuleks.

– Hooldustööd kliendi jaoks ilma lepinguta
– Konkreetsed säilitamise meetodid vana toode ei ole dokumenteeritud
– No kord testimise pärast hooldust.

20 statistilisi meetodeid

Seal peaks olema kogumise ja analüüsi andmed vigade arv erinevatel etappidel. Teave võimetust tähtaegadest ja vahe tuleb analüüsida.

“————————————————– ————————————————– ————————————————–

Support translation:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty Kalidad Elements

Ang isang pagtingin ay kinunan sa mga iniaatas mula sa viewpoint ng mga kompanya ng pagbuo ng software. ISO 9001 standard ay inilaan para sa industriya ng manufacturing. Ang mga kinakailangan ay interpreted para sa software development alinsunod sa ISO 9000-3 at TickIT.

May mga 20 mga pangunahing elemento. Ang bawat konsepto ay mahusay na kilala sa komunidad pamamahala ng kalidad.

1. Management Responsibility

1.1 Kalidad policy

karaniwang ay nangangailangan ng tagapagtustos management sa isyu ng isang kalidad ng patakaran, kung saan ito says ang pulutong na magsisibalik makabuo ng kalidad ng mga produkto.

Ang kalidad ng patakaran ay dapat:
– Tukuyin ang managementâ € ™ s pangako sa kalidad
– Tukuyin ang companyâ € ™ s layunin patungkol kalidad, iyon ay, kung ano ang pamamahala ay nangangahulugan sa pamamagitan ng kalidad
– Maging may-katuturan sa customerâ € ™ s mga pangangailangan
– Ma-naiintindihan sa organisasyon
– Ma-ipinatupad


– Statement masyadong malabo o patakaran ay hindi maintindihan ng staff
– Marka ng patakaran ay hindi isinasagawa.

Halimbawa ng Marka ng patakaran

â € œWe makamit kalidad sa pamamagitan ng motivated at nangangailangan ng kasanayan tauhan, na tinukoy na mga pamamaraan ng trabaho, at intensive pagsusuri at pagsubok activities.â €

1.2 Organization

karaniwang ay nangangailangan ng mga babasahin ng responsibilidad, kapangyarihan at pakikipag-ugnayan ng lahat ng mga tauhan na nakakaapekto kalidad. Ito ay nangangahulugan na kung ang isang tao ay may pananagutan, ito ay pormal na itinalaga ng ang naaangkop na manager. Ang tao ay dapat magkaroon ng awtoridad na matupad ang mga responsibilidad.

Ayon sa ISO, responsibilidad ay nangangahulugang:

â € œa tungkulin upang kumilos sa oneâ € ™ s sariling kasunduan kapag ang isang bagay ay dapat gawin nang hindi pagiging toldâ €.


– Umiiral ng isang responsibilidad na hindi maaaring natupad.


– Project-line
– Project-customer
– Project-maintenance organisasyon
– Software development-hardware-unlad
– Pagpapanatili organisasyon-help desk
– Sales-unlad

Resources ay nangangailangan na ang supplier:
– Kilalanin ang mga kinakailangan para sa mga mapagkukunan
– Magtalaga ng sinanay na mga tauhan.

Management kinatawan ay nangangailangan ng appointment ng manager representative na may kapamahalaan at pananagutan upang:
– Tiyakin na ang kumpanya fulfills ang mga kinakailangan sa ISO 9001
– Mag-ulat ng pagganap ng sistema ng kalidad sa pamamahala ng kumpanya

1.3 Management Review

Quality manager ay dapat na panaka-nakang ipakita ang mga resulta ng
– Marka ng pag-audit
– Mga istatistika ng kalidad ng mga reklamo
– Records ng pagbabago o parusa

Ang mga resulta ay dapat na iniharap sa isang record na pulong ng pamamahala na may mga tala sa taong nag-aral, kung ano ang ipinakita at kung ano ang desisyon ay kinuha at ginawa.

2. Marka ng System

Kalidad na sistema ng â € “”â € œthe istraktura ng organisasyon, mga responsibilidad, mga pamamaraan, mga proseso at mga mapagkukunan para sa pagpapatupad ng kalidad management.â €

Pamamaraan, mga patakaran, mga desisyon isusuot sa pagsusulat. Kung ikaw ay may isang patakaran o pamamaraan na ito ay hindi kinakailangan sa pamamagitan ng ISO 9001, ang standard na pa rin ay nangangailangan na ito ay nakasulat.

Ang mano-manong kalidad ay dapat magtaglay reference at dokumentasyon ng sistema ng kalidad.


– Isang audit ay isang sample, kaya kung sa isang sample, may mga menor de edad non-conformances, at sila ay maayos, maaari pa rin itong maging isang non-conformance dahil ang auditor ay maaaring maghinala na may mga maraming iba pang mga menor de edad non-conformances.
– Umiiral nakasulat na mga pamamaraan ay hindi adhered sa.

3. Kontrata Review

Ang supplier tseke bago signing contract na ang organisasyon magawa kung ano ang kinakailangan sa pamamagitan ng mga kontrata.

Mga katanungan na dapat na itinatanong ay kinabibilangan ng:
– Sigurado ang mga kinakailangan dokumentado at naiintindihan?
– Sigurado kasama pagtanggap pamantayan?
– Nakarating na kinakailangan magkakaibang mula sa magiliw na nalutas?
– Maaari ba ang supplier ipon ng sapat na resources para sa mga kontrata?
– Maaari ba ang supplier ipon ng kakayahan na kinakailangan para sa kontrata?
– Maaari ang gawain ay natapos sa oras?

Ang standard na nangangailangan na ang isang dokumentado pamamaraan na may mga review ay isasama. supplier ay dapat makilala kung paano kontrata susog at paghawak ng mga kinakailangan na detalye sa pagitan ng customer at supplier tinukoy.

4. Design Control

4.1. pangkalahatan
ISO ay nangangailangan na ang plano mo bago gawin at tukuyin bago pagdidisenyo.

4.2. Design and Development Planning

Design plano ay dapat maglaman ng:
– Kahulugan ng pamamaraan na gagamitin sa pag-unlad ng produkto
– Time iskedyul, responsibilidad, trabaho takdang-aralin at pag-unlad control
– Phases proyekto ay hinati. Kabilang dito ang input, output at pag-verify ng output.
– Paglalarawan ng mga pamamaraan at mga kasangkapan na gagamitin

Kalidad plano ay dapat maglaman ng:
– Marka ng mga target
– Pamantayan para acceptability
– Identification ng pagpaplano, pagpapatunay at pagpapatunay.
– Pananagutan para sa kalidad na mga gawain.

Kung ang isang kumpanya ay nagnanais na makakuha ng ISO qualification ang mga plano ay dapat na gaganapin sa lahat ng mga proyekto, dahil ISO sertipikasyon ay para sa buong kumpanya at hindi para sa mga tiyak na mga proyekto.

4.3 Organizational at Technical Interface

Kung may group-trabaho, ang interface sa pagitan ng mga ito ay dapat na kinilala, dokumentado at naililipat sa mga nangangailangan ng mga impormasyon. dokumentasyon ay dapat masuri nang regular.

4.4 Design Input

Kinakailangan pagtutukoy naglalaman ng disenyo input sa software development. Ito ay maaaring gawin sa pamamagitan ng bumibili o inihanda ng supplier gamit batas at regulasyon. Ang isa pang disenyo input kabilang ang disenyo coding na ginagamit bilang input sa coding.

karaniwang ay nais upang matiyak na ang trabaho produkto ng bawat hakbang ay nakakatugon sa mga kinakailangan.

Sa software development, kinakailangan pagbabago ay karaniwang kaya isang pamamaraan para sa paghawak ng mga bago at binagong mga kinakailangan mula sa bumibili malikha.

4.5 Design Output

Design Output: ang disenyo ng mga babasahin at ang source code. ISO ay nangangailangan na disenyo ng mga dokumento at coding ay susuriin bago release.

Ang isang pamamaraan para sa pagtanggap ng disenyo output at pamantayan ng pagtanggap ay dapat na nilikha.

4.6 Design Review

Project function tulad ng coding at pagsubok ay dapat iharap sa pagsusuri. Ang isang karaniwang pamamaraan para sa pagtiyak review ay checklists.

4.7 Design Verification

Ito ay binubuo ng mga review, mga module testing at integration testing.

4.8 Design Validation

Final sistema ng pagsubok, ng kumpletong produkto software kasama ang pagsusuri ng user babasahin. May ay dapat na binalak at dokumentado pagpapatunay. Beta testing ay sa conformance sa ISO hangga’t ang beta testing ay sakop ng isang malinaw na kasunduan sa pagitan ng supplier at beta-testing customer.

4.9 Design Pagbabago

ISO 9001 ay nangangailangan na pagkatapos ng paglabas ng disenyo ng mga babasahin o source, lahat ng mga pagbabago ay dapat pumunta sa pamamagitan ng isang pormal na proseso kung saan ang mga pagbabago ay dokumentado, masuri at maaprubahan bago pagpapatupad.

Walang pigil pagbabago sa kumplikadong teknikal na mga dokumento o mga programa ay lubhang mapanganib at bilang tulad ang standard ay hindi payagan ito.
5. Dokumento at Data Control

Impormasyon na kumokontrol sa pag-unlad / pagpapanatili ng software. karaniwang ay nangangailangan na ang mga taong kailangan ng ilang dokumento / data ay magkakaroon ng access dito. Mga pagbabago sa mga dokumento at data ay kontrolado.

5.1 General

Panlabas na mga dokumento at data ay naka-imbak. Maaari itong ma-imbak sa anumang form (hard copy, electronic media).

5.2 Dokumento at Data Approval at Issue

Bago isyu dokumento at data ay masuri at maaprubahan bago ang bawat isyu. Ang isang listahan dokumento na kung saan ay magkakaroon ng isang malaman kung ang kasalukuyang bersyon ng isang dokumento. Hindi wastong o hindi na ginagamit mga dokumento ay dapat na alisin o malinaw na marka.

5.3 Dokumento at Data Pagbabago

Ang taong / s sa singil ng proseso ng pagsusuri at pag-apruba ay dapat na tinukoy.

6. Purchasing

Sa kaso ng subcontractor, ikaw pa rin ang mananagot. Ibig sabihin, kung mag-apply ka para sa isang kontrata at subcontract ang trabaho, ISO pamantayan ay pa rin sa ilalim ng iyong responsibilidad at ISO kinakailangan ay hindi na ipapataw sa subcontractor.

6.1 General

Kung manpower ay binili, ang standard na nangangailangan sa iyo upang sundin ang isang procedure na makuha mo ang tamang tao. Ang mga tao ay kontrolado ng supplier at hindi subcontractor.
Para masiguro na binili software conforms sa mga kinakailangan:
– Contract kinakailangan sa pamamaraan subcontractors
– Audit ng sistema subcontractor kalidad
– Suriin ang subcontractor nakaraang pagganap
– Survey ang subcontractor sa panahon ng kontrata
– Witness pagsusuri at testing
– Test at isang pagsusuri ng produkto ng subcontractor.

6.2 Pagsusuri ng Subcontractors

Taong may mga kinakailangang kapangyarihan at kagalingan hahatol bawat subcontractor at magpasya kung upang gamitin. Ang mga desisyon ay dapat dokumentado.

supplier ay dapat magpasya kung ano ang kontrol sa subcontractor magkakaroon ito. karaniwang ay hindi banggitin kung magkano ang control dapat mong magkaroon ng. Ito lamang mentions na ang isang desisyon ay dapat na ginawa sa pamamagitan ng paggamit katotohanan.

Ang isang espesyal na kaso ay kapag software na ito ay binili sa pamamagitan ng tingi. Sa kasong ito subcontractor ay organisasyon na kung saan ang pagbili ay isinasagawa, hindi ang orihinal na developer ng software.

Kung pagbili ay tapos na sa pamamagitan ng tingi ISO 9001 ay nangangailangan na iyong tinukoy kung hanggang saan mo inilagay ang mga kinakailangan sa retailer upang makontrol ang supplier.

6.3 Purchasing Data

Kinakailangan sa proseso ng pagbuo ay dapat dokumentado sa kontrata kasama ang mga kinakailangan supplier upang aprubahan resulta trabaho at mga pamamaraan.

6.4 Pag-verify ng biniling produkto

Documentation ng mga desisyon tungkol sa pag-verify ng bawat binili unlad na kasangkapan o kasama ng produkto.

– Walang listahan ng mga aprubadong mga supplier
– Hindi naaangkop na kontrol ng subcontractor
– Walang dokumento pag-verify ng mga nabiling item
– Hindi naaangkop na kontrata sa subcontractor.

7 Control ng Customer-itinustos Product

supplier ay dapat magkaroon ng mga pamamaraan para sa pag-verify, imbakan at pagpapanatili ng customer itinustos software. Gayunpaman, ang kalidad ay ang responsibilidad ng ang software.

A non-conformance mangyayari dahil sa hindi maliwanag responsibilidad ng responsibilidad sa pagitan ng customer at supplier.

8 Product Specification at Traceability

Ang software supplier ay dapat na panatilihin kontrol sa:
– Sa kung ano ang naunang dokumento at mag-isyu ito ay batay
– Kung saan specification ito ay batay
– Ano pagwawasto at mga susog ay kasama sa na source mga programa
– Ano ang nangyari sa bawat ulat problema
– Ano ang pinagmumulan ay isang tiyak na module na nabuo.

9 Process Control

Dokumentado procedure para sa proseso ng pagtitiklop sa operasyon at pamamaraan para sa paghawak ng mga master proma € ™ s / aklatan. Para masiguro na tama versioning ay ginagamit.

– Walang dokumentado pamamaraan para sa pagtitiklop
– Hindi tamang paghawak ng master proma € ™ s o diskettes.

10 Inspection at Pagsubok

Nakasulat na mga pamamaraan para sa inspeksyon at pagsubok upang gawin na may kaugnayan sa pagtitiklop.

– Function ng awtomatikong pag-check proma € ™ s ay hindi pa siniyasat
– Walang dokumentado pamamaraan para sa pagsubok ng proma € ™ s.

11 Control ng Inspection, Pagsukat at Test Equipment

supplier ay dapat piliin ang naaangkop na pagsukat kagamitan at sundin ang isang dokumentado pamamaraan para sa kontrol ng mga kagamitan. Ang bawat bagong bersyon ng software ay dapat na masuri para sa kasarinlan.

12 Inspection at Pagsubok Katayuan

Pagtutukoy at mga programa ay dapat na-verify sa pamamagitan ng mga review at testing. supplier ay dapat magkaroon ng mga pamamaraan na nagbabawal ng paggamit ng hindi na-verify pagtutukoy o mga programa.

13 Control ng Non-matularin produkto

Non-matularin produkto ay hindi dapat gamitin ng hindi sinasadya. Ang isang pamamaraan para sa paghawak ng mabilis na pagbabago sa kaso ng kritikal na mga error ay dapat na nilikha.

– I-clear identification ng mga kinokontrol na mga item na naglalaman ng uncorrected error
– Pamamaraan upang magtamo customer pagtanggap sa paghahatid
– Sa kaso ng mabilis na pagbabago, dapat itong dokumentado
– Ang pagrerepaso kaya binago item ay mataas sa parehong katayuan bilang natitirang bahagi ng software.

14 Corrective at Preventive Action

Mga kailangan:
– Ang mabisang paghawak ng mga ulat na hindi sumasangayon sa mga iniaatas
– Ang mabisang paghawak ng mga ulat na nagpapahiwatig short-comings sa proseso ng pagbuo
– Aktibo koleksyon at pagtatasa ng mga magagamit na impormasyon tungkol sa produkto at proseso ng non-conformance at preventive aksyon.

Impormasyon tungkol sa mga problema nakatagpo dapat drive pagpapabuti ng proseso ng pag-unlad.

– Customer reklamo ay hindi pa maayos na paghawak
– Deficiency ay natagpuan ngunit hindi naitama
– No pamamaraan upang matiyak na ang mga problema ay nasuri at acted upon
– Walang mga pamamaraan para sa pag-uulat kahirapan sa pag-aaplay patakaran at mga pamamaraan.

15 Paghawak, Storage, Packaging, pangangalaga at Delivery

Nalalapat sa software replicated sa PROM, disk o iba pang mga medium.
Media ay may label na at naka-package ng maayos. Data ay naka-back up. May ay dapat ding maging ang kakayahan upang magbigay ng proteksyon mula sa hindi sinasadya pinsala.

16 Control ng Marka Records

Kalidad na mga dokumento ipakita kung aling mga aksyon ay kinuha upang matiyak o tingnan kalidad. karaniwang nag-aatas na ba ng isang pamamaraan para sa paghawak ng mga kalidad na mga talaan. Ang mga tala ay dapat na naka-imbak sa isang angkop na paraan upang sila ay madaling-access.
– Walang mga panuntunan para sa pagpapanatili ng kalidad records
– Suriin ang mga talaan ay hindi iningatan
– Test mga talaan ay hindi iningatan
– Panahon ng pag-iingat ng kalidad records ay hindi tinukoy

17 Internal Quality audit

May ay dapat na isang malayang entidad na regular audit lahat ng mga operasyon na maaaring makaapekto sa produkto o serbisyo kalidad. Ang mga ito ay isinasagawa sa ngalan ng pamamahala ng kumpanya. May ay dapat na isang audit plan.

– Walang audit plan
– Audit plano ay hindi hanggang sa petsa

18 Pagsasanay

Company ay dapat na matiyak na ang mga kawani ay nagsanay para sa mga gawain na kinakailangan. Ang isang pamamaraan upang:
– Kilalanin pangangailangan ng pagsasanay para sa bawat posisyon staff
– Magbigay ng naturang pagsasanay
– Panatilihin ang mga talaan ng mga pagsasanay ng lahat ng miyembro ng kawani.

Pagsasanay ay dapat na dokumentado at sapat. Sa pamamagitan ng sapat na ang ibig sabihin namin na ang tao ay kaya ng gumaganap ang kanyang / kanyang trabaho sa isang sapat na mataas na pamantayan.

– Walang mga pamamaraan para sa pagpaplano o pagsasanay
– Walang mga talaan training
– Hindi natanggap tamang pagsasanay para sa kanyang gawain.

19 Servicing

Supplier ay dapat na dokumentado pamamaraan para sa servicing kung ito ay nabanggit sa kontrata. Sa software na ito ay tungkol sa pagwawasto ng error at mga pagpapahusay sa naihatid software.

Pamamaraan para sa paghawak ng mga reklamo at mga kahilingan para sa mga pagbabago. supplier ay hindi nagpapasalamat upang magbigay ng maintenance kung ito ay hindi nabanggit sa kontrata. Pagpapanatili ng mga pamamaraan para sa mga lumang software ay dapat gawin.

– Pagpapanatili trabaho para sa isang customer na walang kontrata
– Tiyak na pamamaraan para sa pagpapanatili ng lumang produkto ay hindi dokumentado
– No procedure para sa pagsubok matapos maintenance.

20 Statistical Techniques

May ay dapat na koleksyon at pagtatasa ng data tungkol sa bilang ng mga error na natagpuan sa iba’t ibang phases. Impormasyon tungkol sa kawalan ng kakayahan upang matugunan ang mga deadlines at milestones dapat na nasuri.

“————————————————– ————————————————– ————————————————–

Tuki käännös:
————————————————– ————————————————– ————————————————–
ISO 9001 Kaksikymmentä laatutekijöiden

Katsaus toimitetaan klo vaatimusten näkökulmasta yritysten kehittää ohjelmistoja. ISO 9001 -standardi oli tarkoitettu teollisuuteen. Vaatimukset tulkitaan ohjelmistokehitykseen ISO 9000-3 ja TickIT.

On 20 pääkohdat. Jokainen käsite on hyvin tunnettu laadunhallinnan yhteisöä.

1. Johdon vastuu

1.1 Laatupolitiikka

Standardi edellyttää toimittajan johto antaa laatupolitiikkaa, jossa sanotaan yritys on tuottaa laadukkaita tuotteita.

Laatupolitiikka on:
– Määritä managementâ € ™ s sitoutumista laatuun
– Määritä companyâ € ™ s tavoitteet koskevat laatua, eli mitä hallinta tarkoittaa laatua
– Olla merkitystä ASIAKKAAN € ™ s tarpeisiin
– Ymmärrettävä organisaatiossa
– Toteutetaan


– Statement liian epäselvä tai politiikan ei ymmärrä henkilöstö
– Laatupolitiikka ei ole toteutettu.

Esim. Laatu politiikka

â € œWe saavuttaa laadun kautta motivoitunut ja ammattitaitoinen henkilökunta, määritellään työmenetelmät, ja intensiivinen tarkastelu ja testaus activities.â €

1.2 Organisaatio

Standardi edellyttää dokumentointia vastuu, määräysvalta ja keskinäiset suhteet henkilökunnan vaikuttavat laatuun. Tämä tarkoittaa sitä, että jos henkilö on vastuussa, se on muodollisesti määrittämä sopiva johtaja. Henkilön tulisi olla valta täyttää vastuu.

ISO vastuullisuus tarkoittaa:

â € Œã velvollisuus toimia oneâ € ™ s itsestään kun jotain on tehtävä ilman toldâ €.


– Olemassa on vastuu, joka ei voida täyttää.


– Project-line
– Project-asiakas
– Projekti-huolto-organisaatio
– Ohjelmistojen kehittäminen-laitteistojen kehittämistä
– Huolto-organisaation-help desk
– Myynnin kehittämiseen

Resurssit edellyttävät, että toimittaja:
– Tunnista vaatimukset resurssit
– Määritä koulutettu henkilöstö.

Johdon edustaja vaatii nimeäminen johtaja edustajalle valtuudet ja vastuu:
– Varmista, että yhtiö täyttää ISO 9001
– Ilmoita suorituskykyä laatujärjestelmä yhtiön johto

1.3 Johdon katsaus

Laatupäällikkö olisi esitettävä säännöllisin väliajoin tuloksista
– Laatuauditoinnit
– Tilastot laadun valituksia
– Records korjaavien toimien

Tulokset olisi esitettävä äänitetty johdon tapaaminen muistiinpanoja, jotka osallistuivat, mitä esitettiin ja mitä päätöksiä tehtiin ja tehdään.

2. Laatujärjestelmä

Laatujärjestelmä â € “”â € œthe organisaatiorakenne, vastuut, menettelyt, prosessit ja resurssit toteuttamiseen laadun management.â €

Menettelyt, säännöt, päätökset pannaan kirjallisesti. Jos sinulla on sääntö tai menetelmä, joka ei edellytä ISO 9001, standardin edellyttää edelleen, että se on kirjoitettu.

Laatukäsikirja on sisällettävä viittaus ja dokumentointi laatujärjestelmän.


– Tarkastuksen on näyte, joten jos näytteessä, on pieniä poikkeamia, ja ne ovat kiinteitä, se voi silti olla poikkeama koska tarkastaja voi epäillä, että on paljon enemmän pieniä poikkeamia.
– Olemassa olevat kirjalliset menettelyt ei noudateta.

3. Sopimus Review

Toimittajan tarkastukset ennen sopimuksen allekirjoittamista, että organisaatio pystyy suorittamaan mitä edellytetään sopimuksessa.

Kysymykset, jotka pitäisi esittää muun muassa:
– Ovatko vaatimukset dokumentoidaan ja ymmärretty?
– Onko hyväksymiskriteerit mukana?
– Onko vaatimukset poikkeavat tarjouksensa ratkaistu?
– Voiko toimittaja koota riittävästi resursseja sopimuksen?
– Voiko toimittaja kokoamaan tarvittavaa osaamista sopimusta varten?
– Voidaanko tehtävä saada ajoissa?

Standardi edellyttää, että dokumentoitu menettely arvostelua sisällytetään. Toimittajan olisi löydettävä keinot sopimusmuutokset ja käsittely vaatimusmäärittelyn asiakkaan ja toimittajan määriteltävä.

4. Muotoilu Ohjaus

4.1. yleinen
ISO edellyttää, että aiot sitä ennen ja määritä ennen suunnittelussa.

4.2. Suunnittelu ja Kehitystoimisto

Suunnittelu suunnitelman tulisi sisältää:
– Määritelmä käytettävä menetelmä kehittämiseen tuotteen
– Aikataulut, vastuut, työtehtävät ja edistymisen valvontaa
– Vaiheet hanke jaetaan. Tämä sisältää tulo, lähtö ja todentaminen lähdön.
– Kuvaus menetelmiä ja välineitä, joita käytetään

Laatu suunnitelma tulisi sisältää:
– Laatutavoitteet
– Kriteerit hyväksyttävyyden
– Tunnistaminen suunnittelu, validointi ja todentaminen.
– Vastuu laadusta toimintaan.

Jos yritys haluaa saada ISO pätevyys suunnitelmia on pidettävä kaikissa projekteissa, koska sertifiointi on koko yrityksen eikä yksittäisiin hankkeisiin.

4.3 Organisaation ja Tekniset rajapinnat

Jos ryhmä-työ, niiden väliset rajapinnat on tunnistettava, dokumentoidaan ja lähetetään niille tietoa tarvitseville. Asiakirjoissa tarkastellaan säännöllisesti.

4.4 Suunnittelu Input

Määrittelydokumentaation sisältävät suunnittelun panos ohjelmistokehityksessä. Tämä voidaan tehdä ostajan tai valmistaa toimittajan käyttämällä lakeja ja asetuksia. Toinen muotoilu tulo sisältää suunnittelun koodausta, jota käytetään tulona koodausta.

Standardi haluaa varmistaa, että työ tuote kunkin vaiheen täyttää vaatimukset.

Ohjelmistokehityksen vaatimus muutokset ovat yleisiä niin käsittelymenettely uusien ja muuttuneiden vaatimusten ostajalta luodaan.

4.5 Suunnittelu Output

Suunnittelu Output: suunnittelun asiakirjat ja lähdekoodi. ISO edellyttää suunnittelu asiakirjat ja koodausta tarkistetaan ennen julkaisua.

Menetelmä hyväksymisen suunnitellulla teholla ja hyväksyntäkriteerit olisi luotava.

4.6 Design Review

Hanke toimii kuten koodaus ja testaus on esitettävä uudelleen. Yleinen tapa on varmistaa arviot ovat tarkistuslistoja.

4.7 Suunnittelu Verification

Se koostuu katsauksissa, moduulin testauksen ja integroinnin testaus.

4.8 Suunnittelu Validation

Lopullinen järjestelmä testi, täydellisen ohjelmistotuotteen yhdessä tarkastelemalla käyttöohjeissa. Siellä tulee suunnitella ja dokumentoida validointi. Beta-testaus on mukaisin ISO kunhan betatestauksesta kuuluu välinen selkeä sopimus toimittajan ja beta-testaus asiakkaalle.

4.9 Suunnittelu Muutokset

ISO 9001 edellyttää, että luovutuksen jälkeen suunnitteludokumentaation tai lähde, kaikki muutokset menevät läpi virallisen prosessi, jossa muutoksia dokumentoidaan, tarkistetaan ja hyväksytään ennen toteuttamista.

Hallitsematon muutokset monimutkaisia teknisiä asiakirjoja tai ohjelmat ovat erittäin vaarallisia ja sellaisenaan standardi ei salli sitä.
5. Asiakirjojen ja Data Control

Tiedot joka ohjaa kehitys / ylläpito-ohjelmisto. Standardi edellyttää, että ne, jotka tarvitsevat joitakin asiakirjan / data on oikeus saada se. Muutokset asiakirjojen ja tietojen tulee hallita.

5.1 Yleistä

Ulkoiset asiakirjat ja tiedot on tallennettu. Se voidaan tallentaa missään muodossa (paperituloste, sähköinen media).

5.2 Asiakirjojen ja tietojen hyväksyminen ja Issue

Ennen asian asiakirjat ja tiedot on tarkistettava ja hyväksyttävä ennen kutakin asiaa. Asiakirja lista, jossa yksi on selvittää nykyisen version asiakirjasta. Virheellinen tai vanhentuneet asiakirjat tulisi poistaa tai selkeästi merkitty.

5.3 Asiakirjojen ja tietojen muutokset

Henkilö / s vastaa arvioinnin ja hyväksymisen prosessi on täsmennettävä.

6. Osto

Kun kyseessä on alihankkijan, olet edelleen vastuussa. Toisin sanoen jos haet sopimuksen ja teettää työtä, ISO-standardit on edelleen asiakkaan vastuulla ja ISO vaatimukset eivät tarvitse määrätä alihankkija.

6.1 Yleistä

Jos työvoimaa ostetaan, standardin vaatii noudattamaan menettelyä, että saat oikeat ihmiset. Ihmiset ohjata toimittaja eikä alihankkija.
Sen varmistamiseksi, että ostettu ohjelmisto täyttää vaatimukset:
– Sopimus vaatimuksia alihankkijat menettelyistä
– Tarkastus alihankkijan laatujärjestelmän
– Tarkista alihankkija tuottohistoria
– Katsaus alihankkija aikana sopimuksen
– Todistaja tarkastelu ja testaus
– Testaus ja katsaus tuote alihankkija.

6.2 arviointi Alihankkijat

Henkilö, jolla tarvittavat valtuudet ja pätevyys on tuomitseva kunkin alihankkijan ja päättää käyttää. Päätökset on dokumentoitava.

Toimittajan on päättää, mitä valvonta alihankkija sillä on. Standardi ei mainita, miten paljon valvontaa pitäisi olla. Se vain mainitsee, että päätös olisi tehtävä käyttäen tosiasioita.

Erityinen tapaus on, kun ohjelmisto on ostettu vähittäiskaupan. Tässä tapauksessa alihankkija on organisaatio, joilla osto toteutetaan, ei alkuperäinen kehittäjä ohjelmiston.

Jos hankinta tapahtuu vähittäiskaupan ISO 9001 edellyttää, että määritellään, missä määrin laitat vaatimuksia vähittäismyyjä kontrolloimaan toimittaja.

6.3 Ostotiedot

Vaatimukset kehitysprosessin on dokumentoitava sopimuksessa mukana toimittajavaatimusten hyväksyä työn tuloksia ja menettelyjä.

6.4 tarkastaminen ostetun tuotteen

Dokumentointi päätöksiä tarkastuksen jokaisen ostetun kehityksen väline kuulumattomat tuote.

– Ei luettelo hyväksytyistä palveluntarjoajista
– Sopimaton valvonta alihankkijan
– Ei asiakirja todentaminen ostettujen tuotteiden
– Sopimaton sopimuksen alihankkijana.

7 Ohjaus Asiakkaan toimittamia Product

Toimittajan on oltava varmennusmenettelyt, varastointi ja ylläpito asiakas toimittaa ohjelmistoja. Kuitenkin laatu on vastuussa ohjelmiston.

Ei-mukaisuudesta sattuu epäselvän vastuuta vastuun asiakkaan ja toimittajan.

8 Tekniset tiedot ja jäljitettävyys

Ohjelmisto toimittajan pitäisi pitää valvonnan:
– Millä edellisen asiakirjan ja antaa sen perustana
– Millä erittely se perustuu
– Mitä korjaukset ja muutokset on sisällytetty joka lähdekoodin ohjelmat
– Mitä tapahtui kunkin -ongelmaraporttisi
– Mistä lähteestä oli erityisen moduulin syntyy.

9 Process Control

Dokumentoitu menettely replikaatiota prosessin toiminnassa ja menettely käsittelyyn master Proma € ™ s / kirjastoissa. Sen varmistamiseksi, että oikea versiointi on käytössä.

– Ei dokumentoitu menettely replikointi
– Virheellinen käsittely master Proma € ™ s tai levykkeitä.

10 tarkastus ja testaus

Kirjalliset menettelyt tarkastus ja testaus tehtävä yhteydessä lisääntymään.

– Toiminta automaattisesti tarkistaa Proma € ™ s ei ole tarkastettu
– Ei dokumentoitu menettely testaamiseen Proma € ™ s.

11 valvonta tarkastus, mittaus-ja testauslaitteet

Toimittajan tulisi valita sopiva mittauslaitteet ja seuraa dokumentoitu menettely hallinnan laitteiden. Jokainen uusi ohjelmistoversio pitäisi testata riittävyydestä.

12 Tarkastuksen ja testauksen tila

Tekniset ja ohjelmissa olisi todennettu arvioita ja testaus. Toimittajan on oltava menettelyt, jotka kieltävät käytön vahvistamattomien määräysten tai ohjelmia.

13 valvonta Epäyhdenmukaiset Product

Puutteelliset tuotteet ei saa käyttää tahattomasti. Menettely käsittelyyn nopeasti muutoksia tapauksessa kriittisten virheiden olisi luotava.

– Selvä määrittely ohjataan kohteita, jotka sisältävät korjaamattomia virheitä
– Menetelmä saada luovutuksen toimituksen
– Jos nopeasti muutoksia, se on dokumentoitava
– Tarkistaminen niin modifioitu kohteet kohonnut sama asema kuin muualla ohjelmistoja.

14 korjaavat ja ehkäisevät toimenpiteet

– Tehokas käsittely raporteissa, jotka eivät täytä vaatimuksia
– Tehokas käsittely kertomuksia puutteita kehitysprosessissa
– Aktiivinen kerääminen ja analysointi saatavilla tietoa tuotteiden ja prosessien poikkeamien ja ennaltaehkäiseviä toimia.

Tietoa ongelmat pitäisi ajaa parannuksia kehitysprosessia.

– Asiakas valitus ei ole kunnolla käsitelty
– Puutos on todettu, mutta ei korjattu
– Ei menettely, jolla varmistetaan, että ongelmat analysoidaan ja ryhdytään
– Ei menettely ilmoittamisesta vaikeuksia soveltamalla sääntöjä ja menettelyjä.

15 Käsittely, varastointi, Packaging, säilyttäminen ja Toimitus

Koskee ohjelmisto replikoidaan PROM, levyn tai muun väliaineen.
Media on merkittävä ja pakattava oikein. Tiedot on varmuuskopioida. Olisi myös oltava kyky tarjota suojaa tahatonta vahinkoa.

16 laadun valvonnan Records

Laatu asiakirjat osoittavat, mitkä toiminnot on toteutettu sen varmistamiseksi tai tarkistaa laatu. Standardi edellyttää, että on käsittelymenettely laadun kirjaa. Tietueet on säilytettävä sopivalla tavalla niin, että ne ovat helposti saatavilla.
– Ei säännöt säilyttämisestä laatupöytäkirjoista
– Review tietoja ei pidetty
– Testi tietoja ei pidetty
– Toimenpiteen säilyvyyteen kirjaa ei ole määritelty

17 Sisäinen Laatuauditoinnit

Pitäisi olla itsenäinen kokonaisuus, joka tarkastaa säännöllisesti kaikki toiminnot, jotka voivat vaikuttaa tuotteen tai palvelun laatua. Nämä tehdään puolesta yrityksen johdon. Siellä pitäisi olla tarkastuksen suunnitelma.

– Ei tarkastussuunnitelma
– Audit suunnitelma ei ole ajan tasalla

18 Training

Yhtiön olisi varmistettava, että henkilöstöä koulutetaan tehtäviin tarvitaan. Menettely on:
– Tunnista koulutustarpeet jokaisen henkilöstön asema
– Antaa tällaista koulutusta
– Pidä kirjaa koulutusta koko henkilökunta.

Koulutus tulisi dokumentoida ja riittävä. Riittävillä tarkoitamme, että henkilö kykenee suorittamaan hänen / hänen työtä riittävän korkea taso.

– Ei menettelyistä suunnittelua tai koulutusta
– Ei koulutuskirjanpito
– Ei saanut asianmukaista koulutusta hänen tehtävänsä.

19 Huolto

Toimittaja on dokumentoidut menettelyt huoltoa, jos tämä on mainittu sopimuksessa. Sen ohjelmisto on noin virheiden korjauksia ja parannuksia toimitti ohjelmistoja.

Menettelyt valitusten käsittelyä ja pyynnöt muutoksia. Toimittajan ei tarvitse huoltoa koskevasta jos sitä ei mainita sopimuksessa. Kunnossapitomenettelyt vanhaa ohjelmistoa olisi tehtävä.

– Huoltotyöt asiakkaalle ilman sopimusta
– Erityiset menetelmät huolto- vanhojen tuotetta ei ole dokumentoitu
– Ei menettely testaus huollon jälkeen.

20 Tilastolliset menetelmät

Olisi kerääminen ja analysointi noin virheiden määrä eri vaiheissa. Tietoja kyvyttömyys määräaikojen ja välitavoitteet olisi analysoitava.

“————————————————– ————————————————– ————————————————–

Traduction de soutien:
————————————————– ————————————————– ————————————————–
ISO 9001 Vingt éléments de qualité

Un regard sera prise aux exigences du point de vue des sociétés en développement logiciel. norme ISO 9001 a été conçu pour l’industrie manufacturière. Les exigences sont interprétées pour le développement logiciel selon la norme ISO 9000-3 et TickIT.

Il y a 20 éléments principaux. Chaque concept est bien connu dans la communauté de gestion de la qualité.

Responsabilité 1. Gestion

1.1 Politique qualité

La norme exige la gestion des fournisseurs de délivrer une politique de qualité, où il affirme que la compagnie doit produire des produits de qualité.

La politique de qualité doit:
– Définir l’engagement de la managementâ € ™ à la qualité
– Définir les objectifs de la companyâ € ™ en matière de qualité, qui est, ce que la direction entend par qualité
– Soyez pertinent pour les besoins de la Customerâ € ™
– Être compris dans l’organisation
– Être implémenté

Les non-conformités

– Déclaration trop vague ou la politique ne soit pas compris par le personnel
– La politique de qualité ne sont pas mis en œuvre.

Par exemple. de la politique de qualité

â € œWe atteindre la qualité grâce à un personnel motivé et compétent, les procédures de travail définis, et un examen intensif et tester activities.â €

1.2 Organisation

La norme exige la documentation de la responsabilité, l’autorité et l’interrelation de tout le personnel qui affectent la qualité. Cela signifie que si une personne a une responsabilité, elle doit être officiellement attribué par le gestionnaire compétent. La personne doit avoir le pouvoir d’assumer la responsabilité.

Selon l’ISO, signifie la responsabilité:

â € devoir œâ d’agir pour son propre accord de ONEA € ™ quand quelque chose doit être fait sans être Tolda €.


– Existant d’une responsabilité qui ne peut être remplie.


– Projet de ligne
– Projet-client
– Organisation du projet d’entretien
– Développement de logiciels développement matériel
– Maintenance organisation help desk
– Développement des ventes

Ressources exigent que le fournisseur:
– Identifier les besoins en ressources
– Attribuer un personnel qualifié.

Représentant de la direction exige la nomination du gestionnaire représentant l’autorité et la responsabilité de:
– Veiller à ce que l’entreprise satisfait aux exigences de la norme ISO 9001
– Rapport de la performance du système de qualité pour la gestion de l’entreprise

1.3 Examen de la gestion

Responsable qualité doit périodiquement présenter les résultats de
– Audits de qualité
– Statistiques des plaintes de qualité
– Dossiers de mesures correctives

Les résultats devraient être présentés lors d’une réunion de gestion enregistrée avec des notes sur les personnes qui ont assisté, ce qui a été présenté et quelles décisions ont été prises et fait.

2. Système qualité

Système de qualité â € â “”€ œ sur la structure organisationnelle, les responsabilités, les procédures, les processus et les ressources pour la mise en œuvre de qualité management.â €

Procédures, règles, les décisions sont consignées par écrit. Si vous avez une règle ou une procédure qui ne sont pas requis par la norme ISO 9001, la norme exige encore qu’il est écrit.

Un manuel qualité doit contenir des références et la documentation du système de qualité.


– Un audit est un échantillon, par conséquent, si dans un échantillon, il y a des non-conformités mineures, et ils sont fixés, il peut encore être une non-conformité parce que le vérificateur peut soupçonner qu’il ya beaucoup plus de non-conformités mineures.
– Les procédures existantes écrites ne sont pas respectées.

Examen 3. Contrat

Les contrôles des fournisseurs avant la signature du contrat que l’organisation soit en mesure d’effectuer ce qui est requis par le contrat.

Les questions qui doivent être posées comprennent:
– Sont les exigences documentées et comprises?
– Sont inclus les critères d’acceptation?
– Des exigences différentes de l’appel d’offres ont été résolus?
– Le fournisseur peut rassembler suffisamment de ressources pour le contrat?
– Le fournisseur peut rassembler les compétences nécessaires pour le contrat?
– La tâche peut être terminée à temps?

La norme exige qu’une procédure documentée avec des critiques inclus. Le fournisseur doit déterminer comment les modifications de contrat et la manipulation de la spécification des exigences entre le client et le fournisseur être définis.

4. Control Design

4.1. Général
ISO exige que vous envisagez avant de le faire et de spécifier avant de concevoir.

4.2. Conception et planification du développement

plan de conception doit contenir:
– Définition de la méthodologie à utiliser dans le développement du produit
– Les horaires, les responsabilités, les affectations de travail et le contrôle des progrès
– Phases projet sera divisé. Cela comprend l’entrée, la sortie et la vérification de la production.
– Description des méthodes et des outils à utiliser

Plan de qualité doit contenir:
– des objectifs de qualité
– Critères d’acceptabilité
– Identification de la planification, de validation et de vérification.
– Responsabilités des activités de qualité.

Si une entreprise veut obtenir la qualification ISO les plans doivent être tenus dans tous les projets, depuis la certification ISO est pour l’ensemble de l’entreprise et non pas pour des projets spécifiques.

4.3 Interfaces organisationnels et techniques

S’il y a un groupe de travail, les interfaces entre elles doivent être identifiés, documentés et transmis à ceux qui ont besoin de l’information. La documentation sera réexaminée régulièrement.

4.4 Conception d’entrée

Exigences spécifications contiennent l’entrée de conception dans le développement de logiciels. Cela peut être fait par l’acheteur ou préparé par le fournisseur en utilisant les lois et règlements. Une autre entrée de conception comprend la conception de codage qui est utilisé comme entrée pour le codage.

La norme veut faire en sorte que le produit du travail de chaque étape répond aux exigences.

Dans le développement de logiciels, les changements d’exigences sont communes afin d’une procédure de traitement des exigences nouvelles et modifiées de l’acheteur sera créé.

4.5 Conception de sortie

Conception sortie: la documentation de conception et le code source. ISO exige que les documents de conception et de codage être examinés avant la libération.

Une procédure d’acceptation de la sortie et les critères d’acceptation de conception doit être créé.

4.6 Design Review

Les fonctions de projet comme le codage et les tests doivent être présentés lors de l’examen. Une méthode commune pour assurer commentaires sont des listes de contrôle.

4.7 Vérification de la conception

Il est composé de commentaires, de test de modules et les tests d’intégration.

4.8 Validation de la conception

Test final du système, du produit logiciel complet ainsi que la révision de la documentation de l’utilisateur. Il devrait être planifiée et validation documentée. Beta test est conforme à la norme ISO tant que le bêta-test est couvert par un accord clair entre le fournisseur et le bêta-test client.

4.9 Modifications de la conception

ISO 9001 exige que, après la libération de la documentation de conception ou de la source, toutes les modifications doivent passer par un processus formel où les changements sont documentés, examinés et approuvés avant la mise en œuvre.

modifications incontrôlées à des documents ou des programmes techniques complexes sont extrêmement dangereux et en tant que telle la norme ne le permet pas.
5. Contrôle des documents et des données

L’information qui contrôle le développement / maintenance de logiciels. La norme exige que ceux qui ont besoin un document / données doivent y avoir accès. Les modifications des documents et des données doivent être contrôlées.

5.1 Généralités

Les documents externes et les données doivent être stockées. Il peut être stocké sur un formulaire (papier, médias électroniques).

5.2 document et approbation des données et édition

Avant que les documents d’émission et les données doivent être examinées et approuvées avant chaque émission. Une liste de documents dans laquelle on doit trouver la version actuelle d’un document. Les documents invalides ou obsolètes doivent être enlevés ou clairement marqués.

5.3 documents et modifications de données

La personne / s en charge du processus d’examen et d’approbation doit être spécifiée.

6. Achats

Dans le cas du sous-traitant, vous êtes toujours responsable. C’est à dire. si vous postulez pour un contrat et sous-traiter le travail, les normes ISO est toujours sous votre responsabilité et les exigences ISO ne doivent pas être imposées sur le sous-traitant.

6.1 Généralités

Si la main-d’œuvre est acheté, la norme vous oblige à suivre une procédure que vous obtenez les bonnes personnes. Les gens seront contrôlés par le fournisseur et non sous-traitant.
Pour veiller à ce que le logiciel acheté est conforme aux exigences:
– Exigences du contrat sur les procédures de sous-traitants
– Audit du système de qualité de sous-traitant
– Vérifier la performance passée sous-traitant
– Enquête sur le sous-traitant pendant contrat
– Examen et essais Témoin
– Test et avis produit de sous-traitant.

6.2 Évaluation des sous-traitants

Personne avec autorité et compétence nécessaire doit juger chaque sous-traitant et décider d’utiliser. Les décisions doivent être documentées.

Le fournisseur doit décider de ce contrôle sur un sous-traitant qu’elle aura. La norme ne mentionne pas à quel point le contrôle, vous devriez avoir. Il mentionne simplement qu’une décision devrait être prise à l’aide de faits.

Un cas particulier est lorsque le logiciel est acheté par le biais de détail. Dans ce cas, le sous-traitant est une organisation avec laquelle l’achat est effectué, pas le développeur original du logiciel.

Si l’achat se fait par l’ISO 9001 de détail exige que vous définissez dans quelle mesure vous mettez les exigences sur le détaillant pour contrôler son fournisseur.

6.3 Données Achats

Exigences sur le processus de développement doivent être consignés dans le contrat ainsi que les exigences des fournisseurs pour approuver les résultats et les procédures de travail.

6.4 Vérification des produits achetés

Documentation des décisions au sujet de la vérification de chaque acheté outil de développement ou d’un produit inclus.

– Pas de liste des fournisseurs approuvés
– Le contrôle des sous-traitants inappropriée
– Aucun document de vérification des articles achetés
– Contrat inapproprié avec le sous-traitant.

7 Commande fourni par le client produit

Le fournisseur doit avoir des procédures de vérification, le stockage et la maintenance du logiciel fourni par le client. Cependant, la qualité est la responsabilité du logiciel.

Une non-conformité se produit en raison de la responsabilité claire de la responsabilité entre le client et le fournisseur.

8 Spécifications du produit et traçabilité

Le fournisseur de logiciels devrait garder le contrôle sur:
– Sur ce qui précède document et délivrer est basé
– Sur quelle spécification, il est basé
– Quelles sont les corrections et amendements ont été inclus dans quels programmes sources
– Ce qui est arrivé à chaque rapport de problème
– De quelle source a été un module spécifique généré.

Commande de processus 9

procédure documentée pour le processus de réplication dans le fonctionnement et la procédure de traitement des bibliothèques / master Proma € ™. Pour veiller à ce que correct versioning est utilisé.

– Aucune procédure documentée pour la réplication
– Une mauvaise manipulation des disquettes s ou maître Proma € ™.

10 inspection et d’essais

Des procédures écrites pour l’inspection et des tests à faire dans le cadre de la réplication.

– Fonction de contrôle automatique Proma € ™ est n’a pas été inspecté
– Aucune procédure documentée pour tester Proma € ™ est.

11 Contrôle de l’inspection, de mesure et de test

Le fournisseur doit sélectionner l’équipement de mesure approprié et suivre une procédure documentée pour le contrôle de l’équipement. Chaque nouvelle version du logiciel doit être testé pour la suffisance.

12 Inspection et état de test

Les spécifications et les programmes devraient vérifié grâce à des examens et des tests. Le fournisseur doit avoir des procédures qui interdisent l’utilisation des spécifications ou des programmes non vérifiés.

13 Contrôle des produits non conformes

les produits non conformes ne doivent pas être utilisés sans le vouloir. Une procédure de traitement des modifications rapides en cas d’erreurs critiques devrait être créé.

– L’identification claire des articles contrôlés qui contiennent des erreurs non corrigées
– Méthode de susciter l’acceptation du client lors de la livraison
– En cas de modifications rapides, il doit être documenté
– Revoir les articles ainsi modifiées sera élevé au même statut que reste du logiciel.

14 mesures correctives et préventives

– Gestion efficace des rapports qui ne sont pas conformes aux exigences
– Gestion efficace des rapports indiquant insuffisances dans le processus de développement
– Collecte et analyse des informations disponibles sur le produit et le processus de non-conformité et les actions de prévention active.

Information sur les problèmes rencontrés devraient favoriser l’amélioration du processus de développement.

– La plainte du client n’a pas été correctement traitée
– La carence a été trouvé mais non corrigée
– Aucune procédure pour assurer que les problèmes sont analysés et pris en compte
– Aucune procédure de déclaration des difficultés avec l’application des règles et procédures.

15 Manutention, stockage, emballage, conservation et livraison

Valable pour un logiciel répliquées sur PROM, disque ou autre support.
Médias doivent être étiquetés et emballés correctement. Les données sont sauvegardées. Il devrait également être en mesure de fournir une protection contre les dommages involontaires.

16 Contrôle des enregistrements qualité

documents de qualité montrent quelles actions ont été prises pour assurer ou vérifier la qualité. La norme exige qu’il y ait une procédure de traitement des dossiers de qualité. Les dossiers doivent être stockés de manière appropriée afin qu’ils soient facilement accessibles.
Les non-conformités:
– Pas de règles pour la conservation des dossiers de qualité
– Les dossiers d’examen ne sont pas conservés
– Les dossiers de test ne sont pas conservés
– Période de tenir des registres de qualité ne se définit pas

Audits 17 Qualité interne

Il devrait y avoir une entité indépendante qui vérifie régulièrement toutes les opérations qui peuvent affecter le produit ou service de qualité. Celles-ci sont menées pour le compte de la gestion de l’entreprise. Il devrait y avoir un plan d’audit.

– Aucun plan d’audit
– Plan de vérification pas à jour

18 formation

Société doit veiller à ce que le personnel est formé pour les tâches requises. Une procédure pour:
– Identifier les besoins de formation pour chaque poste
– Fournir une telle formation
– Tenir des registres de la formation de tous les membres du personnel.

La formation doit être documentée et suffisante. En suffisante, nous entendons que la personne soit capable d’effectuer sa / son travail à un niveau assez élevé.

– Pas de procédures de planification ou de formation
– Pas de dossiers de formation
– Non reçu une formation adéquate pour sa tâche.

19 entretien

Fournisseur doit disposer de procédures documentées pour l’entretien si cela est mentionné dans le contrat. Dans le logiciel, il est à propos de corrections d’erreurs et des améliorations au logiciel fourni.

Procédures de traitement des plaintes et des demandes de modifications. Le fournisseur n’a pas l’obligation d’assurer l’entretien si elle ne figure pas dans le contrat. Les procédures de maintenance pour de vieux logiciels devraient être faits.

– Les travaux de maintenance pour un client sans contrat
– Des méthodes spécifiques pour l’entretien des vieux produits ne sont pas documentés
– Aucune procédure de test après l’entretien.

20 Techniques statistiques

Il devrait y avoir la collecte et l’analyse des données sur le nombre d’erreurs trouvées dans les différentes phases. Informations sur l’incapacité de respecter les délais et les étapes doivent être analysées.

“————————————————– ————————————————– ————————————————–

Stipe oersetting:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty Quality Elements

In blik wurde nommen by de easken fan it eachpunt fan bedriuwen ûntwikkeljen software. ISO 9001 standert wie bedoeld foar de makyndustry. De easken binne útlein foar sêftguod ûntwikkeling yn oerienstimming mei ISO 9000-3 en TickIT.

Der binne 20 wichtichste eleminten. Elke konsept is goed bekend yn de kwaliteit behear mienskip.

1. Management Ferantwurdlikens

1.1 Kwaliteit belied

De standert freget de leveransier behear om in kwaliteit belied, dêr’t it seit it bedriuw sil produsearje kwaliteit produkten.

De kwaliteit belied sil:
– Definiearje it managementâ € ™ s ynset foar kwaliteit
– Definiearje it companyâ € ™ s doelen oangeande kwaliteit, dat is, wat behear betsjut by kwaliteit
– Wês relevant foar de customerâ € ™ s behoeften
– Be begrepen yn de organisaasje
– Be útfierd


– Ferklearring te ûndúdlik of belied wurdt net begrepen troch personiel
– Kwaliteit belied wurdt net útfierd.

Bgl fan Quality belied

â € œWe berikken kwaliteit troch motivearre en betûft personiel, definiearre wurk prosedueres, en yntinsive resinsje en testen activities.â €

1.2 Organisaasje

De standert freget dokumintaasje fan ferantwurdlikens, gesach en interrelation fan alle personiel dy’t kwaliteit. Dat hâldt yn dat as in persoan hat in ferantwurdlikheid, it sil wurde formeel tawiisd troch de geskikte manager. De persoan moat it foech om foltôge wirde mocht it ferantwurdlikheid.

Neffens ISO, ferantwurdlikheid hâldt yn:

â € œa plicht te hanneljen op oneâ € ™ s eigen oerienstimming as wat hat om dien wurde sûnder wêzen Tolda €.


– Besteande fan in ferantwurdlikheid dy’t net folbrocht wirde.


– Project-line
– Project-klant
– Project-ûnderhâld organisaasje
– Software ûntwikkeling-Hardware ûntwikkeling
– Underhâld organisaasje-help desk
– Sales-ûntwikkeling

Middels fereaskje dat de leveransier:
– Ynventarisaasje de easken foar middels
– Tawize oplaat personiel.

Management represintatyf freget beneaming fan manager fertsjintwurdiger mei gesach en ferantwurdlikheid nei:
– Soargje dat it bedriuw oan de easken yn ISO 9001
– Rapportearje de prestaasjes fan ‘e kwaliteit systeem ta bedriuw behear

1.3 Management Review

Kwaliteit manager moatte periodyk presintearje de resultaten fan
– Quality audits
– Statistiken fan kwaliteit klachten
– Records fan korrektyf aksje

De resultaten moatte wurde presintearre op in opnommen behear gearkomste mei oantekeningen op, dy’t oanwêzich, wat waard presintearre en wat besluten waarden naam en makke.

2. Quality System

Kwaliteit systeem â € “”â € œthe organisaasjestruktuer, ferantwurdlikheden, prosedueres, prosessen en middels foar de útfiering kwaliteit management.â €

Prosedueres, regels, besluten scil deade yn skriuwen. As jo in regel of proseduere dat is net nedich by ISO 9001, de standert noch nedich dat it is skreaun.

In kwaliteit hânlieding sil befetsje referinsje en dokumintaasje fan de kwaliteit systeem.


– In rekkenkeamer is in stekproef, dêrom as yn in stekproef, binne der lytse net-conformances, en hja binne fêst, it kin noch wol in net-conformance omdat de akkountant kin tinke dat der folle mear lytse net-conformances.
– Besteande skreaun prosedueres wurde net adhered oan.

3. Contract Review

De leveransier kontrolearret foar ûndertekening kontrakt dat de organisaasje kinne om te fieren wat is nedich troch it kontrakt.

Fragen moatte wurde frege ûnder oaren:
– Binne de easken dokumintearre en begrepen?
– Binne akseptaasje kritearia opnaam?
– Haw easken ûngelikense út de oanbesteging is oplost?
– Kin de leveransier opbringe genôch middels foar it kontrakt?
– Kin de leveransier opbringe it foech nedich foar it kontrakt?
– Kin de opjefte wurde klear yn tiid?

De standert freget dat in dokumintearre proseduere mei resinsjes wurde opnommen. De leveransier moat identifisearje hoe’t kontrakt amendeminten en ôfhanneling fan easken spesifikaasje tusken klant en leveransier wurde definiearre.

4. Design Control

4.1. Algemien
ISO fereasket dat jo plan foar dwaan en opjaan foar it ûntwerpen.

4.2. Design en Development Planning

Design plan moat befetsje:
– Definition of metodyk wurde brûkt by de ûntwikkeling fan produkt
– Tiid tsjinstregelings, ferantwurdlikheden, wurk opdrachten en foarútgong kontrôle
– Moannestânnen projekt sil wurde ferdield. Dit is ynklusyf input, output en kinne de útfier.
– Beskriuwing fan metoaden en ynstruminten om brûkt wurde

Kwaliteit plan moat befetsje:
– Kwaliteit doelen
– Kritearia foar artikel
– Identifikaasje fan romtlike oardering, falidaasje en ferifikaasje.
– Ferantwurdlikheden foar kwaliteit aktiviteiten.

As in bedriuw wol te krijen ISO kwalifikaasje de plannen moatte wurde hâlden yn alle projekten, sûnt ISO sertifisearring is foar it hiele bedriuw en net foar spesifike projekten.

4.3 Organizational en Technical Interfaces

As der groep-wurk, de Schnittstellen tusken harren moat sinjalearre wurde, dokumintearre en oerdroegen oan dyjingen noaten de ynformaasje. De dokumintaasje sil wurde geregeldwei.

4.4 Design Ynfier

Easken spesifikaasjes befetsje it ûntwerp ynput yn software ûntwikkeling. Dit kin dien wurde troch de purchaser of taret troch de leveransier mei help fan wet- en regeljouwing. In oar ûntwerp input befettet design taalkodearjen yn dy’t brûkt wurdt as ynfier foar taalkodearjen yn.

De standert wol te soargjen dat it wurk produkt fan elke stap foldocht oan de easken.

Yn software ûntwikkeling, eask feroarings binne mienskiplik sa in proseduere foar it ôfhanneljen fan nije en feroare easken út de purchaser oanmakke wurde.

4.5 Design Utfier

Design Output: it ûntwerp dokumintaasje en de boarne koade. ISO freget dat ûntwerp dokuminten en Coding wurde foar frijlitting.

In proseduere foar akseptaasje fan it ûntwerp útfier en kritearia fan akseptaasje moatte wurde makke.

4.6 Design Review

Project funksjes lykas taalkodearjen yn en testen wurde presintearre op it resinsje. In mienskiplike metoade foar it garandearjen resinsjes binne checklists.

4.7 Design Ferifikaasje

Dit bestiet út resinsjes, module testen en yntegraasje testen.

4.8 Design Validation

Final systeem test, fan ‘e folsleine software produkt tegearre mei de resinsearje fan brûker dokumintaasje. Der moatte wurde plande en dokumintearre falidaasje. Beta hifkjen is yn conformance mei ISO salang’t de beta testen wurdt dekt troch in dúdlike oerienkomst tusken leveransier en beta-test klant.

4.9 Design Feroarings

ISO 9001 freget dat nei release fan design dokumentaasje of boarne, alle feroarings sille gean troch in formele proses dêr’t feroarings wurde dokumintearre, beoardiele en goedkard foar útfiering.

Uncontrolled feroarings oan komplekse technyske dokuminten of programma binne tige gefaarlik en as sadanich de standert net tastean is.
5. Dokumint en Data Control

Ynformaasje dat hat ynfloed op de ûntjouwing / ûnderhâld fan software. De standert fereasket dat dyjingen dy’t nedich wat dokumint / gegevens sille hawwe tagong ta it. Feroarings oan dokuminten en gegevens wurde regele.

5.1 Algemien

Boarnen, noaten en dokuminten en gegevens wurde bewarre. It kin wurde opslein op in formulier (hurde kopy, elektroanyske media).

5.2 Dokumint en Data Approval en Issue

Foar dei fan dokuminten en gegevens sil wurde en goedkard foar eltse dei. In dokumint list dêr’t men scil fine út de aktuele ferzje fan in dokumint. Unjildich of ferâldere dokuminten moat fuortsmiten of dúdlik markearre.

5.3 Dokumint en Data Feroarings

De persoan / s yn lieding oer de resinsje en goedkarring proses scil oantsjutte.

6. ynkeap

Yn it gefal fan subcontractor, jimme binne noch ferantwurdlik. I.e. as jo jilde foar in kontrakt en subcontract it wurk, ISO noarmen is noch ûnder jo ferantwurdlikens en ISO easken net te oplein wurde op de subcontractor.

6.1 Algemien

As Manpower wurdt kocht, de standert freget jo om te folgjen in proseduere dy’t jo krije it rjocht minsken. De minsken sille wurde regele troch leveransier en net subcontractor.
Om derfoar te soargjen dat kocht software conforms oan easken:
– Contract easken op it subcontractors prosedueres
– Audit fan de subcontractor kwaliteit systeem
– Check subcontractor ferline prestaasjes
– Enkête de subcontractor ûnder kontrakt
– Tjsûge review en testen
– Test en review produkt fan subcontractor.

6.2 Evaluaasje fan Subcontractors

Persoan mei nedich gesach en foegen rjochtsje sille eltse subcontractor en beslute oft te brûken. De besluten wurde dokumintearre.

De leveransier sil bepale wat kontrôle oer subcontractor it sil hawwe. De standert net hawwen hoefolle kontrôle jo moatte hawwe. It krekt neamt dat in beslút moat wurde makke troch mei help fan feiten.

In spesjale gefal is as software is oankocht troch detailhannel. Yn dit gefal subcontractor is organisaasje dêr’t de oankeap is útfierd, net de oarspronklike ûntwikkelder fan de software.

As ynkeap wurdt dien troch retail ISO 9001 fereasket dat jo bepale yn hoefier’t jo sette easken op de elektroanikasaak te kontrolearjen syn leveransier.

6.3 ynkeap Data

Easken op ûntwikkeling proses wurdt dokumintearre yn it kontrakt tegearre mei leveransier easken te goedkarre wurk resultaten en prosedueres.

6.4 Ferifikaasje fan kocht Product

Dokumintaasje fan besluten oer de ferifikaasje fan elk kocht ûntwikkeling ark of opnommen produkt.

– Gjin list fan goedkard leveransiers
– Inappropriate kontrôle fan subcontractor
– Gjin dokumint kinne de oankocht items
– Inappropriate kontrakt mei subcontractor.

7 Control fan Customer-levere Product

De leveransier sil hawwe prosedueres foar ferifikaasje, opslach en ûnderhâld fan de klant levere software. Lykwols, de kwaliteit is de ferantwurdlikheid fan ‘e software.

In net-conformance bart troch ûndúdlik ferantwurdlikheid fan ferantwurdlikens tusken klant en leveransier.

8 Product Specification en Traceability

De software leveransier moat hâlden kontrôle op:
– Op wat foargeande dokumint en dêrby it is basearre
– Op hokker spesifikaasje it is basearre
– Wat korreksjes en amendeminten binne opnaam yn hokker boarne programma
– Wat barde nei eltse probleem rapport
– Fan wat boarne wie in spesifike module oanmakke.

9 Process Control

Dokumintearre proseduere foar it witten proses yn ‘e operaasje en proseduere foar ôfhanneljen fan master PROMâ € ™ s / bibleteken. Om derfoar te soargjen dat korrekt versioning wurdt brûkt.

– Gjin dokumintearre proseduere foar witten
– Ferkearde ôfhanneljen fan master PROMâ € ™ s of diskettes.

10 Ynspeksje en Testen

Skreaun prosedueres foar de ynspeksje en testen wurde dien yn ferbân mei witten.

– Funksje fan automatysk kontrolearjen PROMâ € ™ s is net ynspektearre
– Gjin dokumintearre proseduere foar it testen fan PROMâ € ™ s.

11 Control fan Ynspeksje, Measuring en Test Board

De leveransier moat selektearje it passend measuring apparatuer en folgje in dokumintearre proseduere foar kontrôle fan apparatuer. Elke nije software ferzje moat hifke wurde foar genôch wêzen.

12 Ynspeksje en Test Status

Spesifikaasjes en programma moatte ferifiearre troch resinsjes en teste. De leveransier sil hawwe prosedueres dy’t ferbiede gebrûk fan net ferifiearre spesifikaasjes of programma.

13 Control fan Non-conforming Product

Non-conforming produkten moatte net brûkt wurde unintentionally. In proseduere foar it ôfhanneljen fan flugge oanpassings yn gefal fan krityske flaters moatte wurde makke.

– Clear identifikaasje fan kontrolearren items dy’t befetsje Net oerbettere fouten
– Metoade om elicit klant akseptaasje op levering
– Yn gefal fan flugge wizigings, dan moat wurde dokumintearre
– Resinsearje sa kear bewurke items wurdt ferheft ta deselde status as rest fan software.

14 Korrektive en Previntyf Action

– Effektive ôfhanneljen fan de rapporten dy’t net bart op basis easken
– Effektive ôfhanneljen fan rapporten oanjout koarte-comings yn de ûntwikkeling proses
– Aktive kolleksje en analyze fan de beskikbere ynformaasje oer produkt en proses net-conformance en previntive aksjes.

Ynformaasje oer problemen tsjinkaam moatte ride ferbetterings fan de ûntwikkeling proses.

– Customer klacht is net goed ôfhannele
– Deficiency is fûn, mar net ferbettere
– Gjin proseduere om derfoar te soargjen dat problemen wurde analysearre en reagearre
– Gjin proseduere foar it melden fan swierrichheden mei it tapassen fan regels en prosedueres.

15 Handling, Storage, Parts, Ynstânhâlding en Delivery

Jildt foar software replicated op PROM, skiif of oar medium.
Media wurde bestimpele en ferpakt korrekt. Gegevens wurde stipe op. Der moat ek de mooglikheid te bieden beskerming fan ûnfrijwillige skea.

16 Control fan Quality Records

Kwaliteit dokuminten sjen hokker aksjes nommen te garandearjen of kontrolearje kwaliteit. De standert fereasket dat der in proseduere foar it ôfhanneljen fan kwaliteit records. De registers wurde opslein yn in passende wize sa se binne maklik tagonklik.
– Gjin regels foar behâld fan kwaliteit records
– Review records wurde net hâlden
– Test records wurde net hâlden
– Perioade fan hâlden kwaliteit records is net definiearre

17 Ynterne Quality Audits

Der moat in ûnôfhinklik entiteit dy’t geregeld audits alle operaasjes dy’t gefolgen hawwe produkt of tsjinst kwaliteit. Dy wurde útfierd yn opdracht fan bedriuw behear. Der moat in rekkenkeamer plan.

– Gjin kontrôle plan
– Audit plan net up to date

18 Training

Bedriuw moat derfoar soargje dat personiel is oplaat foar taken nedich. In proseduere nei:
– Identify oplieding moat foar eltse personiel posysje
– Soargje foar sa’n oplieding
– Hâld registers fan de oplieding fan alle personiel leden.

Opliedings moatte wurde dokumintearre en foldwaande. By genôch bedoele wy dat de persoan wêze steat fan performing syn / har wurk oan in heech genôch standert.

– Gjin prosedueres foar romtlike oardering of oplieding
– Gjin oplieding records
– Net krige goede oplieding foar syn of har taak.

19 de meer

Leveransier sil hawwe dokumintearre prosedueres foar ûnderhâld oan as dit wurdt neamd yn it kontrakt. Yn software is it oer fersin korreksjes en enhancements nei ôflevere software.

Prosedueres foar it ôfhanneljen fan klachten en fersiken foar oanpassings. De leveransier is net ferplichte om ûnderhâld as it wurdt net neamd yn kontrakt. Ûnderhâld prosedueres foar âlde software moatte makke wurde.

– Underhâld wurk foar in klant sûnder in kontrakt
– Spesifike metoaden foar ûnderhâld fan âlde produkt is net oerlevere
– Gjin proseduere foar testen nei ûnderhâld.

20 Statistical Techniques

Der moatte samling en analyze fan de gegevens oer tal flaters fûn yn de ferskillende fazen. Ynformaasje oer ûnfermogen om te foldwaan terminen en mylpealen moatte wurde analysearre.

“————————————————– ————————————————– ————————————————–

Tradución Apoio:
————————————————– ————————————————– ————————————————–
ISO 9001 Vinte elementos de calidade

Un ollar será levado para os requisitos do punto de vista das empresas de desenvolvemento de software. ISO 9001 foi destinado á industria de transformación. Os requisitos son interpretados para desenvolvemento de software, de acordo coa norma ISO 9000-3 e TickIT.

Hai 20 principais elementos. Cada concepto é ben coñecido na comunidade de xestión da calidade.

Responsabilidade 1. Xestión

1.1 Política de calidade

A norma esixe que a xestión de provedores para emitir unha política de calidade, onde se di que a empresa debe producir produtos de calidade.

A política de calidade debe:
– Permite axustar o compromiso managementâ € ™ s coa calidade
– Establecer os obxectivos do company € ™ s en relación á calidade, é dicir, o que a administración entende por calidade
– Sexa relevante para as necesidades do Custom € ™ s
– Ser entendido na organización
– Ser aplicado

Non conformidades

– Declaración demasiado vagos ou política non é entendida polo persoal
– Política de calidade non está implementada.

por exemplo da política de calidade

â € œWe alcanzar a calidade a través de persoal motivado e cualificado, procedementos de traballo establecidos e intensa revisión e probas activities.â €

1.2 Organización

A norma esixe documentación da responsabilidade, autoridade e interrelación de todas as persoas que afectan a calidade. Isto significa que se unha persoa ten unha responsabilidade, que debe ser formalmente asignado polo director apropiado. A persoa debe ter a autoridade para cumprir a responsabilidade.

Segundo a ISO, a responsabilidade significa

â € OEA deber de actuar no propio acordo oneâ € ™ s cando algo ten que ser feito sen ser tolda €.


– Existente dunha responsabilidade que non pode ser cumprida.


– Proxecto liña
– Proxecto para o cliente
– Organización do proxecto de mantemento
– O desenvolvemento de software desenvolvemento do hardware
– Mantemento organización help desk
– As vendas para o desenvolvemento

Recursos esixir que o provedor:
– Identificar as necesidades de recursos
– Asignar persoal adestrado.

representante da administración esixe nomeamento de representante director con autoridade e responsabilidade de:
– Asegúrese de que a empresa cumpre os requisitos da norma ISO 9001
– Reportar o rendemento do sistema de calidade para a xestión da empresa

1.3 Management Review

director de calidade debe presentar periodicamente os resultados
– Auditorías de Calidade
– Estatísticas de reclamacións de calidade
– Os rexistros de acción corretiva

Os resultados deben ser presentados nunha reunión de xestión gravado con notas en que participou, o que se presentou e que decisións foron tomadas e feitas.

2. Sistema de Calidade

sistema de calidade â € “”un € œThe estrutura organizativa, responsabilidades, procedementos, procesos e recursos para aplicar calidade management.â €

Procedementos, regras, decisións deben ser feitas por escrito. Se vostede ten unha regra ou procedemento que non se esixe pola ISO 9001, norma aínda esixe que está escrito.

Un manual de calidade debe conter referencia e documentación do sistema de calidade.


– Unha auditoría é un exemplo, xa se nunha mostra, hai non conformidades menores, e son fixos, aínda pode ser unha non-conformidade porque o auditor pode sospeitar que hai moitos máis non conformidades menores.
– Os procedementos existentes escrita non son respectadas.

Revisión 3. Contrato

As comprobacións provedor antes sinatura do contrato que a organización sexa capaz de realizar o que se esixe polo contrato.

Preguntas que deben ser feitas inclúen:
– Son os requisitos documentados e comprendidos?
– San criterios de aceptación incluído?
– Xa diferentes esixencias do concurso foi resolto?
– O provedor pode reunir recursos suficientes para o contrato?
– O provedor pode reunir a competencia necesaria para o contrato?
– Pode a tarefa ser rematada no tempo?

A norma esixe que un procedemento documentado con comentarios incluírse. O provedor debe identificar como cambios contractuais e manipulación de especificación de requisitos entre cliente e provedor pode definir.

4. Control de Proxecto

4.1. xeral
ISO require que planificar antes de facer e indicar antes de proxectar.

4.2. Deseño e Desenvolvemento de Planificación

Proxecto plan conterá:
– Definición da metodoloxía que emprega no desenvolvemento de produtos
– As programacións de tempo, responsabilidades, asignacións de traballo e control de progreso
– Proxecto Fases será dividido. Isto inclúe entrada, saída e verificación de saída.
– Descrición dos métodos e ferramentas que se empregan

plan de calidade debe conter:
– Os obxectivos de calidade
– Criterios de aceptación
– Identificación de planificación, validación e verificación.
– Responsabilidades para actividades de calidade.

Se unha empresa quere gañar cualificación ISO os plans deben ser realizadas en todos os proxectos, xa que a certificación ISO é para toda a empresa e non para proxectos específicos.

4.3 Interfaces técnicas e organizativas

Se non o houbera traballo de grupo, as interfaces entre elas deben ser identificadas, documentadas e transmitidas para os que necesitan de información. A documentación debe ser revista regularmente.

4.4 Proxecto de Entrada

especificacións de requirimentos conter a entrada de deseño no desenvolvemento de software. Isto pode ser feito polo comprador ou preparado polo provedor empregando as leis e regulamentos. Outra entrada proxecto inclúe codificación de deseño que se usa como entrada para a codificación.

O patrón quere para garantir que o produto de traballo de cada paso cumpre os requisitos.

No desenvolvemento de software, cambios de requisitos son comúns así un procedemento para xestionar novos e modificados os requisitos do comprador ser creado.

4.5 Proxecto de saída

Proxecto de saída: a referida documentación eo código fonte. ISO esixe que os documentos de deseño e codificación ser revista antes do lanzamento.

Un procedemento para aceptación do produto e criterios de aceptación de proxecto debe ser creado.

4.6 Deseño Review

proxecto funciona como codificación e probas deben ser presentadas no marco da revisión. Un método común para garantir opinións son listas de verificación.

4.7 Deseño Verification

Este está composto por valoración, probas do módulo e probas de integración.

4.8 Proxecto de Validación

proba final do sistema, do produto de software completa, xunto coa revisión da documentación do usuario. Non deben ser planificadas e documentadas de validación. A proba beta está de acordo coa norma ISO, sempre que a proba beta é cuberto por un acordo claro entre provedor e cliente de probas beta.

4.9 cambios de deseño

ISO 9001 esixe que tras a liberación da documentación do proxecto ou da fonte, todos os cambios deben pasar por un proceso formal onde os cambios son documentadas, revisadas e aprobadas antes da implantación.

Os cambios non controladas para documentos ou programas técnicos complexos son moi perigosas e, como tal, a norma non permite isto.
5. Documento de datos e control

A información que controla o desenvolvemento / mantemento de software. A norma esixe que os que precisan dalgún documento / datos pode acceder a el. As modificacións dos documentos e datos deben ser controlados.

5.1 Xeral

documentos externos e datos deben ser almacenados. Pode ser almacenado en calquera formulario (copia impresa, medios electrónica).

5,2 e aprobación de documentos de Datos e Edición

Antes de emitir documentos e datos deben ser analizados e aprobados antes de cada emisión. A lista de documentos en que se debe descubrir a versión actual dun documento. documentos válidos ou obsoletos deben ser eliminadas ou claramente marcadas.

5.3 Documentos e datos Cambios

A persoa / s encargada do proceso de revisión e certificación deben ser especificados.

6. Compras

No caso de subcontratado, aínda é responsable. Isto é, se aplicar a un contrato e subcontratas o traballo, as normas ISO aínda está baixo a súa responsabilidade e os requisitos da ISO non ten que ser imposta ao subcontratante.

6.1 Xeral

Se man de obra é adquirido, o estándar require que siga un procedemento que ten a xente certas. As persoas van ser controlada por provedor e non subcontratante.
Para garantir que o software adquirido cumpre cos requisitos:
– Requisitos do contrato sobre os procedementos subcontratas
– Auditoría do sistema de calidade subcontratante
– Comproba subcontratante desempeño pasado
– Levantamento do subcontratado durante contrato
– Avaliación Witness e proba
– Proba e revisión do produto de subcontratante.

6.2 Avaliación de subcontratas

Persoa con autoridade e competencia necesaria xulgará cada subcontratante e decidir se quere usar. As decisións deben ser documentados.

O provedor debe decidir o control sobre subcontratante que terá. A norma non menciona como control ten que ter. El só menciona que unha decisión debe ser feita a través de feitos.

Un caso especial é cando o software é adquirido a través do polo miúdo. Neste caso subcontratante é organización coa que a compra se realiza, e non o creador orixinal do software.

A compra é feita a través de ISO miúdo 9001 require que definir ata que punto se pon esixencias sobre a venda polo miúdo a controlar o seu provedor.

6.3 Datos de Compras

Requisitos no proceso de desenvolvemento debe ser documentada no contrato, xunto con requisitos para provedores para aprobar os resultados e procedementos de traballo.

6.4 Comprobación do produto adquirido

Documentación de decisións sobre a verificación de cada compra ferramenta de desenvolvemento ou produto incluído.

– Ningunha lista de provedores aprobados
– Control inadecuado de subcontratante
– Ningunha verificación de documentos de elementos compras
– Contrato impropio con subcontratante.

7 Control de subministrado polo cliente Produto

O provedor debe procedementos para verificar, almacenamento e mantemento do cliente proporcionada software. Con todo, a calidade é responsabilidade do software.

A non-conformidade acontece debido á responsabilidade pouco clara de responsabilidades entre o cliente eo provedor.

8 Especificacións do produto e Trazabilidade

O provedor de software debe manter o control sobre:
– Sobre o que precede documento e emitir basea-se
– En que especificación baséase
– Que correccións e modificacións foron incluídas na que os programas de fonte
– Que pasou con cada informe de problema
– De que fonte foi xerado un módulo específico.

Control 9 Proceso

procedemento documentado para o proceso de replicación en funcionamento e procedemento para a manipulación de mestre Proma € ™ s / bibliotecas. Para garantir que o control de versión correcta é usada.

– No procedemento documentado para a replicación
– O manexo inadecuado de disquetes mestre Proma € ™ s ou.

10 Inspección e proba

procedementos escritos para a inspección e proba a ser feito en relación a replicación.

– Función de comprobar automaticamente Proma € ™ s non fosen inspeccionados
– No procedemento documentado para probar Proma € ™ s.

11 Control de inspección, medida e equipos de proba

O provedor debe seleccionar o equipo de medida axeitado e seguir un procedemento documentado para control de equipos. Cada nova versión do software debe ser probado para suficiencia.

12 Inspección e proba de Estado

Especificacións e programas debe ser revisada mediante análises e probas. O provedor debe procedementos que prohiben a utilización de especificacións ou programas non verificados.

13 Control de non-conformidade do produto

produtos non conformes non deben ser usados de forma non intencionada. Un procedemento para xestionar modificacións rápidas en caso de erros críticos deben ser creados.

– A identificación clara dos produtos controlados que conteñen erros non corrixidos
– Método para provocar a aceptación do cliente no momento da entrega
– En caso de cambios rápidos, debe ser documentada
– Revisando elementos para modificados serán elevados ao mesmo estado que resto do software.

14 Acción correcta e Preventiva

– Tratamento eficaz dos informes que non estean en conformidade cos requisitos
– Tratamento eficaz dos informes indicando curto-vindas no proceso de desenvolvemento
– Recollida e análise de información dispoñible sobre o produto e non-conformidade de procesos e accións preventivas actividade.

Información sobre os problemas encontrados deben conducir melloras do proceso de desenvolvemento.

– Reclamación do cliente non foi debidamente tratada
– Discapacidade se atopou, pero non corrixido
– Non hai procedemento para garantir que os problemas son analizados e posta en práctica
– No proceso de comunicación das dificultades coa aplicación de normas e procedementos.

15 Manipulación, almacenamento, envasado, conservación e entrega

Aplícase a software replicada en PROM, disco ou outro medio.
Medios deben ser rotulado e embalados correctamente. Os datos deben ser incluídos no backup. Tamén debe haber a posibilidade de ofrecer protección contra danos non intencionais.

16 Control de rexistros da calidade

documentos de calidade amosar que accións foron tomadas para garantir ou comprobar a calidade. A norma esixe que haxa un procedemento para o tratamento de rexistros de calidade. Os rexistros deben ser almacenados de forma adecuada para que son facilmente accesibles.
Non conformidades:
– Non hai regras para a retención de rexistros da calidade
– Rexistros de comentarios non son mantidos
– Rexistros de proba non son mantidos
– Período de manter rexistros de calidade non está definido

Auditorías 17 Calidade Interno

Debe haber unha entidade independente que Audita regularmente todas as operacións que poden afectar a produto ou servizo de calidade. Estes son conducidas en nome da xestión da empresa. Debe haber un plan de auditoría.

– No plan de auditoría
– Plan de auditoría non ata a data

18 Training

Empresa debe asegurar que o persoal é adestrado para tarefas necesarias. Un procedemento para:
– Identificar as necesidades de formación para cada posición persoal
– Proporcionar esa formación
– Manter rexistros de formación de todos os membros do equipo.

O adestramento debe ser documentado e suficiente. Por suficiente, queremos dicir que a persoa sexa capaz de realizar a súa / seu traballo a un nivel suficientemente elevado.

– Non hai procedementos de planificación ou de formación
– Non hai rexistros de formación
– Non recibir adestramento axeitado para a súa tarefa.

19 Servicing

O provedor debe procedementos documentados para mantemento se iso é mencionado no contrato. En software é sobre correccións de erros e melloras para o software entregado.

Procedementos para xestionar queixas e peticións de modificacións. O provedor non está obrigado a facilitar o mantemento se non é mencionado no contrato. Os procedementos de mantemento para software de idade debe ser feita.

– Os traballos de mantemento para un cliente sen contrato
– Métodos específicos para mantemento do produto antigo non está documentada
– Non hai procedemento para probas tras o mantemento.

20 Técnicas Estadísticas

Debe haber recollida e análise de datos sobre o número de erros atopados nas distintas fases. Información sobre a incapacidade de cumprir os prazos e obxectivos deben ser analizadas.

“————————————————– ————————————————– ————————————————–

მხარდაჭერა თარგმანი:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty ხარისხის ელემენტები

შევხედოთ იქნება მიღებული მოთხოვნების თვალსაზრისით კომპანიების პროგრამული უზრუნველყოფა. ISO 9001 სტანდარტის განკუთვნილი წარმოების ინდუსტრიაში. მოთხოვნები ინტერპრეტაცია პროგრამული უზრუნველყოფის დამუშავება შესაბამისად ISO 9000-3 და TickIT.

არსებობს 20 ძირითადი ელემენტები. თითოეული კონცეფცია კარგად არის ცნობილი, რომ ხარისხის მართვის საზოგადოებას.

1. მართვის პასუხისმგებლობა

1.1 პოლიტიკა ხარისხის სფეროში

სტანდარტი მოითხოვს მომწოდებლის მართვის გასცეს ხარისხის პოლიტიკის, სადაც ნათქვამია, კომპანია ვალდებულია აწარმოოს ხარისხის პროდუქცია.

პოლიტიკა ხარისხის ვალდებულია:
– დააზუსტეთ managementâ € ™ s ვალდებულება ხარისხი
– დააზუსტეთ companyâ € ™ s მიზნების დაკავშირებით ხარისხის, რომ არის ის, რაც მართვის ნიშნავს ხარისხის
– იყოს შესაბამისი მომხმარებელთა € ™ s საჭიროებებს
– გაგებული ორგანიზაციის
– განხორციელდება


– განცხადება ძალიან ბუნდოვანი და პოლიტიკა არ არის გაგებული პერსონალი
– პოლიტიკა ხარისხის სფეროში ხორციელდება.

მაგალითად. ხარისხის პოლიტიკის

â € œWe მისაღწევად ხარისხის მეშვეობით მოტივირებული და კვალიფიციური პერსონალი, განსაზღვრული სამუშაო პროცედურები და ინტენსიური მიმოხილვა და ტესტირება activities.â €

1.2 ორგანიზაცია

სტანდარტი მოითხოვს დოკუმენტაცია პასუხისმგებლობა, უფლებამოსილება და ურთიერთმიმართების პერსონალის ახდენს ხარისხის. ეს იმას ნიშნავს, რომ თუ ადამიანს აქვს პასუხისმგებლობა, უნდა ფორმალურად მიერ დანიშნული შესაბამისი მენეჯერი. პირი უნდა ჰქონდეს უფლებამოსილება, შეასრულოს პასუხისმგებლობა.

მისი თქმით, ISO, პასუხისმგებლობა ნიშნავს:

â € OEA მოვალეობა იმოქმედოს à ხშირად € ™ s საკუთარი სურვილით, როდესაც რაღაც უნდა გაკეთდეს ისე, რომ toldâ €.


– არსებული პასუხისმგებლობა, რომელიც ვერ შესრულდება.


– პროექტი-line
– პროექტის მომხმარებელს
– პროექტის შენარჩუნების ორგანიზაციის
– პროგრამული უზრუნველყოფის დამუშავების ტექნიკის განვითარების
– სარემონტო ორგანიზაციის დახმარების
– გაყიდვების განვითარების

რესურსები მოითხოვს, რომ მიმწოდებელი:
– განსაზღვრა მოთხოვნები რესურსები
– მიანიჭეთ მომზადებული პერსონალი.

ხელმძღვანელობის წარმომადგენელი მოითხოვს დანიშვნა მენეჯერი წარმომადგენლის უფლებამოსილება და პასუხისმგებლობა:
– დარწმუნდით, რომ კომპანია აკმაყოფილებს ISO 9001
– Report შესრულების ხარისხის სისტემა, რათა კომპანიის მენეჯმენტი

1.3 მართვის მიმოხილვა

ხარისხის მენეჯერი უნდა პერიოდულად შედეგებს წარადგენს
– ხარისხის აუდიტი
– სტატისტიკის ხარისხის საჩივრების
– ჩანაწერები კორექტულობისკენ მოუწოდა

შედეგები წარმოდგენილი უნდა იყოს ჩაწერილი მართვის შეხვედრა შენიშვნები, რომლებიც ესწრებოდნენ, რაც იყო წარმოდგენილი და რა გადაწყვეტილება იქნა მიღებული და გააკეთა.

2. ხარისხის სისტემის

ხარისხის სისტემის â € “”â € œthe ორგანიზაციული სტრუქტურა, ვალდებულებები და პროცედურები, პროცესები და რესურსების ახორციელებს ხარისხის management.â €

პროცედურები, წესი, გადაწყვეტილება უნდა დააყენოს წერილობით. თუ თქვენ გაქვთ წესი და პროცედურა, რომ არ არის საჭირო ISO 9001 სტანდარტი კვლავ მოითხოვს, რომ წერია.

ხარისხის სახელმძღვანელო უნდა შეიცავდეს მითითება და დოკუმენტაცია ხარისხის სისტემის.


– აუდიტის არის ნიმუში, ამიტომ, თუ ნიმუში, არსებობს უმნიშვნელო შეუსაბამობების და ისინი დაფიქსირდა, მას შეუძლია კვლავ იყოს შეუსაბამობის გამო, რომ აუდიტორის შეიძლება ეჭვი, რომ არსებობს მრავალი უფრო მცირე შეუსაბამობების.
– არსებული წერილობითი პროცედურები არ მიუერთდა.

3. ხელშეკრულების მიმოხილვა

მიმწოდებელი ამოწმებს ადრე ხელშეკრულების გაფორმების, რომ ორგანიზაცია შეძლებს შეასრულოს, რა არის საჭირო ხელშეკრულებით.

კითხვა, რომელიც უნდა სთხოვა მოიცავს:
– მოთხოვნებს დოკუმენტირებული და შესწავლილი?
– თქვენ მიღების კრიტერიუმები შედის?
– არ მოთხოვნები სხვადასხვა ტენდერში უკვე გადაწყვეტილია?
– ვერ მიმწოდებლის დაიმსახურებს საკმარისი რესურსი ხელშეკრულება?
– ვერ მიმწოდებლის დაიმსახურებს კომპეტენციის საჭირო ხელშეკრულება?
– ვერ ამოცანა უნდა დასრულდეს დროს?

სტანდარტი მოითხოვს, რომ დოკუმენტირებული პროცედურა მიმოხილვა შედის. მიმწოდებელმა უნდა განსაზღვროს, თუ როგორ ხელშეკრულების ცვლილებების და დამუშავება მოთხოვნების ჩამოყალიბების შორის მომხმარებელს და მიმწოდებელი განისაზღვრება.

4. დიზაინი Control

4.1. ზოგადი
ISO მოითხოვს, რომ თქვენ აპირებთ ადრე აკეთებს და მიუთითოთ ადრე შექმნა.

4.2. დიზაინი და განვითარების დაგეგმვა

დიზაინი გეგმა უნდა შეიცავდეს:
– განმარტება მეთოდოლოგიის განვითარების პროდუქტი
– ახლა გრაფიკით, პასუხისმგებლობა, სამუშაო დავალებები და პროგრესის კონტროლი
– ფაზები პროექტის გაიყოფა. ეს მოიცავს შემავალი, გამომავალი და გადამოწმების გამომავალი.
– აღწერა მეთოდები და ინსტრუმენტები, უნდა იყოს გამოყენებული

ხარისხის გეგმა უნდა შეიცავდეს:
– ხარისხის სამიზნეების
– კრიტერიუმები მისაღებია
– საიდენტიფიკაციო დაგეგმვის, დადასტურება და გადამოწმების.
– პასუხისმგებლობა ხარისხის საქმიანობას.

თუ კომპანია სურს მოიპოვოს ISO საკვალიფიკაციო გეგმები უნდა ჩატარდეს ყველა პროექტი, რადგან ISO სერტიფიცირების მთელი კომპანია და არა კონკრეტული პროექტები.

4.3 ორგანიზაციული და ტექნიკური ინტერფეისები

თუ არ არის ჯგუფში მუშაობის, ინტერფეისები მათ შორის უნდა იყოს განსაზღვრული, დოკუმენტირებული და გადაეცეს იმ სჭირდება ინფორმაცია. დოკუმენტაცია უნდა რეგულარულად გადაიხედოს.

4.4 დიზაინი შეყვანის

მოთხოვნები სპეციფიკაციები შეიცავდეს დიზაინი შეყვანის პროგრამული უზრუნველყოფის დამუშავება. ეს შეიძლება გაკეთდეს, შემსყიდველის მიერ ან მომზადებული მიმწოდებელი გამოყენებით კანონები და წესები. კიდევ ერთი დიზაინი შეყვანის მოიცავს დიზაინი კოდირება, რომელიც გამოიყენება, როგორც შეყვანის კოდირების.

სტანდარტული სურს, რათა უზრუნველყოს, რომ მუშაობა პროდუქტის ყოველი ნაბიჯი აკმაყოფილებს.

პროგრამული უზრუნველყოფის დამუშავება, მოთხოვნა ცვლილებები საერთო, პროცედურა გატარება ახალი და შეცვლილი მოთხოვნები მყიდველი შეიქმნება.

4.5 დიზაინი გამოყვანის

დიზაინი გამომავალი: საპროექტო დოკუმენტაცია და კოდის. ISO მოითხოვს, რომ დიზაინის დოკუმენტები და კოდირების გადაიხედება გათავისუფლებას.

პროცედურა მიღების დიზაინი გამომავალი და კრიტერიუმების მიღების უნდა შეიქმნას.

4.6 დიზაინი მიმოხილვა

პროექტის ფუნქციები, როგორიცაა კოდირების და ტესტირება უნდა წარმოდგენილი მიმოხილვა. საერთო მეთოდი უზრუნველყოფის მიმოხილვა სიების.

4.7 დიზაინი გადამოწმების

ეს შედგება მიმოხილვა, მოდული ტესტირებისა და ინტეგრაციის ტესტირება.

4.8 დიზაინი Validation

Final სისტემის გამოცდა, სრული პროგრამული პროდუქტის ერთად განხილვას შესახებ დოკუმენტაცია. არ უნდა იყოს დაგეგმილი და დოკუმენტურად დადასტურება. Beta ტესტირება შესაბამისად ISO რადგან ბეტა ტესტირება არის დაფარული ნათელი შორის შეთანხმების მიმწოდებელი და ბეტა-ტესტირება მომხმარებელს.

4.9 დიზაინი ცვლილებები

ISO 9001 მოითხოვს, რომ გათავისუფლების შემდეგ საპროექტო დოკუმენტაციის ან წყარო, ყველა ცვლილება უნდა გაიაროს ფორმალური პროცესი, სადაც ცვლილებები დოკუმენტირებული, განხილული და დამტკიცებული ადრე განხორციელება.

უკონტროლო ცვლილებების კომპლექსური ტექნიკური დოკუმენტები ან პროგრამების უკიდურესად სახიფათო და, როგორც ასეთი სტანდარტი არ დაუშვებს.
5. დოკუმენტი და მონაცემთა კონტროლი

ინფორმაციას, რომელიც აკონტროლებს განვითარების / ტექნიკური უზრუნველყოფა. სტანდარტი მოითხოვს, რომ ვინც უნდა გარკვეული დოკუმენტი / მონაცემები უნდა ჰქონდეს მას. ცვლილებები დოკუმენტები და მონაცემები უნდა გაკონტროლდეს.

5.1 ზოგადი

გარე დოკუმენტები და მონაცემები ინახება. ეს შეიძლება იყოს შენახული ნებისმიერი ფორმით (ნაბეჭდი, ელექტრონული მედია).

5.2 დოკუმენტი და მონაცემთა დამტკიცება და გამოცემა

სანამ საკითხი დოკუმენტები და მონაცემები უნდა იყოს განხილული და დამტკიცებული ადრე თითოეული საკითხი. დოკუმენტი სია, რომელიც ერთი უნდა გაირკვეს მიმდინარე ვერსია დოკუმენტი. არასწორი ან მოძველებული დოკუმენტები უნდა მოიხსნას ან ნათლად აღინიშნება.

5.3 დოკუმენტი და მონაცემთა ცვლილებები

პირი / s პასუხისმგებელი განხილვისა და დამტკიცების პროცესი უნდა მითითებული.

6. შესყიდვების

იმ შემთხვევაში, ქვე ისევ თქვენ ხართ პასუხისმგებელი. ანუ თუ თქვენ მოგვმართავთ ხელშეკრულება და subcontract მუშაობა, ISO სტანდარტების ჯერ კიდევ თქვენი პასუხისმგებლობა და ISO მოთხოვნები არ უნდა დაეკისროს სუბკონტრაქტორის.

6.1 ზოგადი

თუ ცოცხალი ძალა შეიძინა, სტანდარტი მოითხოვს, რომ დაიცვას პროცედურა, რომელიც თქვენ გაქვთ უფლება. ხალხი აკონტროლებს მიმწოდებელი და არ სუბკონტრაქტორის.
იმისათვის, რომ შეძენილი პროგრამული შეესაბამება მოთხოვნებს:
– ხელშეკრულების მოთხოვნების ქვეკონტრაქტორების პროცედურები
– აუდიტის ქვეკონტრაქტორის ხარისხის სისტემა
– Check სუბკონტრაქტორმა წარსული შესრულება
– კვლევის სუბკონტრაქტორის დროს ხელშეკრულების
– მოწმე მიმოხილვა და ტესტირება
– ტესტი და მიმოხილვა პროდუქტის სუბკონტრაქტორის.

6.2 შეფასების ქვეკონტრაქტორების

პირი, რომელსაც საჭირო ძალაუფლება და უფლებამოსილება განსჯის ყოველ სუბკონტრაქტორმა და გადაწყვეტს გამოიყენოს. გადაწყვეტილებები უნდა იყოს დოკუმენტირებული.

მიმწოდებელმა უნდა გადაწყვიტოს თუ კონტროლი სუბკონტრაქტორმა მას მოუწევს. სტანდარტული არ არის ნახსენები, თუ რამდენად კონტროლი უნდა ჰქონდეს. ეს უბრალოდ აღნიშნავს, რომ გადაწყვეტილება უნდა გამოყენებით ფაქტები.

გამორჩეულები, როდესაც პროგრამა შეძენილი საცალო. ამ შემთხვევაში სუბკონტრაქტორმა ორგანიზაცია, რომლის შეძენა ტარდება, არ არის ორიგინალური დეველოპერი პროგრამული უზრუნველყოფა.

თუ შეძენა კეთდება საცალო ISO 9001 მოითხოვს, რომ თქვენ განსაზღვრა, თუ რამდენად დააყენა მოთხოვნები საცალო გააკონტროლოს მისი მიმწოდებელი.

6.3 შესყიდვების მონაცემთა

მოთხოვნები განვითარების პროცესში უნდა იყოს დოკუმენტირებული ხელშეკრულების ერთად მიმწოდებელი მოთხოვნები დაამტკიცებს მუშაობის შედეგები და პროცედურები.

6.4 შემოწმება შეძენილი პროდუქტის

დოკუმენტაცია გადაწყვეტილებების გადამოწმება შეიძინა განვითარების ინსტრუმენტი ან შედის პროდუქტი.

– არ სია დაამტკიცა მომწოდებლები
– შეუსაბამო მართვის კონტრაქტორის
– არ დოკუმენტი შემოწმების შეძენილი ნივთები
– შეუსაბამო ხელშეკრულების სუბკონტრაქტორის.

7 კონტროლის მომხმარებელზე მიწოდებული პროდუქტის

მიმწოდებელმა უნდა ჰქონდეს პროცედურების შემოწმების, შენახვისა და შენარჩუნების მომხმარებელს მიეწოდება პროგრამული უზრუნველყოფა. თუმცა, ხარისხის არის პასუხისმგებლობა პროგრამული უზრუნველყოფა.

არასამთავრობო შესაბამისად ხდება იმის გამო, რომ გაუგებარია, პასუხისმგებლობის პასუხისმგებლობას მომხმარებელს და მიმწოდებელი.

8 პროდუქტის სპეციფიკაცია და მიკვლევადობა

პროგრამული მიმწოდებელი უნდა შევინარჩუნოთ კონტროლი:
– რა წინა დოკუმენტი და გასცეს იგი ეფუძნება
– რომელ დაზუსტება ის ეფუძნება
– რა სასჯელაღსრულების, პრობაციისა და ცვლილებები იქნა შეტანილი, რომელიც წყაროს პროგრამები
– რა მოხდა ყოველი პრობლემა ანგარიში
– რა იწვევს იქნა კონკრეტული მოდულის გამომუშავებული.

9 პროცესის კონტროლი

დოკუმენტირებული პროცედურა რეპლიკაცია პროცესში ოპერაცია და პროცედურა გატარება სამაგისტრო Proma € ™ s / ბიბლიოთეკები. იმისათვის, რომ სწორი ვერსიების გამოიყენება.

– არ დოკუმენტირებული პროცედურა რეპლიკაცია
– არასათანადო მოპყრობა სამაგისტრო Proma € ™ s ან diskettes.

10 ინსპექტირება და ტესტირება

წერილობითი პროცედურები ინსპექციის და ტესტირება უნდა გაკეთდეს დაკავშირებით რეპლიკაცია.

– ფუნქცია ავტომატურად შემოწმების Proma € ™ s არ შემოწმებულა
– არ დოკუმენტირებული პროცედურა ტესტირების Proma € ™ s.

11 კონტროლის ინსპექციის, საზომი და ტესტი ტექნიკა

მიმწოდებელმა უნდა შეარჩიოს შესაბამისი საზომი აღჭურვილობა და დაიცვას დოკუმენტირებული პროცედურა კონტროლის აღჭურვილობა. ყოველი ახალი პროგრამული ვერსია უნდა ტესტირება გაქვს.

12 ინსპექტირება და ტესტირება სტატუსი

სპეციფიკაციები და პროგრამების დამოწმებული მიმოხილვა და ტესტირება. მიმწოდებელმა უნდა ჰქონდეს პროცედურები, რომელიც კრძალავს გამოყენება გადაუმოწმებელი სპეციფიკაციები ან პროგრამებს.

13 კონტროლის არაკონფორმულ პროდუქტის

არაკონფორმულ პროდუქცია არ უნდა იქნას გამოყენებული უნებლიეთ. პროცედურა გატარება სწრაფი ცვლილებები შემთხვევაში კრიტიკული შეცდომები უნდა შეიქმნას.

– წმინდა პირადობის კონტროლირებადი საკითხი, რომელიც შეიცავს გაუსწორებელი შეცდომები
– მეთოდი, რომ გამოიწვიოს მომხმარებელს მიღების საფუძველზე მიწოდება
– იმ შემთხვევაში, სწრაფი ცვლილებები, ეს უნდა იყოს დოკუმენტირებული
– მიმოხილვა ასე შეიცვალა ნივთები იქნება აყვანილი იგივე სტატუსი, როგორც დანარჩენი პროგრამა.

14 მაკორექტირებელი და პრევენციული აქცია

– ეფექტური გატარება ინფორმაციით, რომელიც არ შეესაბამება მოთხოვნებს
– ეფექტური გატარება ანგარიშების მიუთითებს მოკლე comings განვითარების პროცესში
– აქტიური შეგროვება და ანალიზი ხელმისაწვდომი ინფორმაცია პროდუქტის და პროცესის შეუსაბამობის და პრევენციული ქმედებები.

ინფორმაცია პრობლემები შეექმნა უნდა მართოს გაუმჯობესების განვითარების პროცესში.

– კლიენტების საჩივარი არ იქნა სათანადოდ სიფრთხილით
– დეფიციტია უკვე იპოვეს, მაგრამ არ გამოსწორდა
– არ პროცედურა, რათა უზრუნველყოს, რომ პრობლემები გაანალიზება და რეაგირება
– არ ანგარიშგების პროცედურებს სირთულეები გამოყენების წესები და პროცედურები.

15, დამუშავება, შენახვა, შეფუთვის, დაცვის და მიწოდების

ვრცელდება პროგრამული ტირაჟირებული PROM, დისკზე ან სხვა საშუალო.
მედია უნდა შეაფასა და შეფუთული სწორად. მონაცემები უნდა იყოს გამყარებული. იქ უნდა იყოს შესაძლებლობა, უზრუნველყოს დაცვა შემთხვევით დაზიანება.

16 კონტროლის ხარისხის ჩანაწერები

ხარისხის დოკუმენტები აჩვენებს, რომელშიც მოქმედებები არ იქნა მიღებული, რათა უზრუნველყოს, ან შეამოწმოს ხარისხის. სტანდარტი მოითხოვს, რომ იყოს პროცედურა გატარება ხარისხის ჩანაწერი. ჩანაწერები უნდა ინახებოდეს სათანადო წესით, ასე რომ ისინი ადვილად ხელმისაწვდომი.
– წესები შენახვისათვის ხარისხის ჩანაწერები
– მიმოხილვა ჩანაწერი არ ინახება
– ტესტი ჩანაწერები არ არის დაცული
– პერიოდი შენახვის ხარისხის ჩანაწერები არ არის განსაზღვრული

17 ხარისხის შიდა აუდიტის

არ უნდა იყოს დამოუკიდებელი იურიდიული პირი, რომელიც რეგულარულად ატარებს ყველა ოპერაცია, რომ შეიძლება გავლენა პროდუქციისა და მომსახურების ხარისხის. ეს ტარდება სახელით კომპანიის მენეჯმენტი. არ უნდა იყოს აუდიტის გეგმა.

– არ აუდიტის გეგმა
– აუდიტის გეგმა არ დღემდე

18 სასწავლო

კომპანია უნდა უზრუნველყოს, რომ თანამშრომლები მომზადდებიან ამოცანები საჭირო. პროცედურა:
– იდენტიფიცირება სასწავლო საჭიროებების თითოეული თანამშრომელი პოზიცია
– უზრუნველყოს ასეთი სწავლება
– შეინახეთ ჩანაწერი მომზადება ყველა თანამშრომლები.

სასწავლო უნდა იყოს დოკუმენტირებული და საკმარისი. საკმარისი ჩვენ ნიშნავს, რომ პირი, რომელსაც შეუძლია ასრულებენ მისი / მისი მუშაობა, რომ საკმაოდ მაღალი სტანდარტი.

– არ პროცედურების დაგეგმვა და სასწავლო
– არ სასწავლო ჩანაწერი
– არ მიიღო სათანადო მომზადების მისი ამოცანა.

19 მომსახურება

მიმწოდებელი ვალდებულია არ დოკუმენტირებული პროცედურა მომსახურების თუ ეს აღნიშნული ხელშეკრულებით. პროგრამული უზრუნველყოფა, ეს არის შეცდომა, პრობაციისა და გაუმჯობესებებს მიწოდება პროგრამული უზრუნველყოფა.

პროცედურები საჩივრების და თხოვნას ცვლილებები. მიმწოდებელი არ არის ვალდებული უზრუნველყოს ტექნიკური, თუ ეს არ არის ნახსენები ხელშეკრულებით. სარემონტო პროცედურების ძველი პროგრამული უნდა მოხდეს.

– სარემონტო სამუშაოები მომხმარებელს ხელშეკრულების გარეშე
– სპეციფიკური მეთოდების ტექნიკური ძველი პროდუქტი არ არის დოკუმენტირებული
– არ პროცედურა ტესტირების შემდეგ შენარჩუნება.

20 სტატისტიკური ტექნიკა

არ უნდა იყოს შეგროვება და ანალიზი მონაცემების რაოდენობის შეცდომები ნაპოვნი სხვადასხვა ფაზის. ინფორმაცია უუნარობა ვადები და ეტაპები უნდა გაანალიზდეს.

“————————————————– ————————————————– ————————————————–

Unterstützung Übersetzung:
————————————————– ————————————————– ————————————————–
ISO 9001 Zwanzig Qualitätskomponenten

Ein Blick wird auf die Anforderungen aus der Sicht der Unternehmen, die Entwicklung von Software getroffen werden. ISO 9001-Standard wurde für die Fertigungsindustrie bestimmt sind. Die Anforderungen sind für die Softwareentwicklung gemäß ISO 9000-3 und TickIT interpretiert.

Es gibt 20 Hauptelemente. Jedes Konzept wird in der Qualitätsmanagement-Community bekannt.

1. Management Verantwortung

1.1 Qualitätspolitik

Der Standard verlangt die Lieferantenmanagement eine Qualitätspolitik zu erteilen, wo es heißt, das Unternehmen wird hochwertige Produkte produzieren.

Die Qualitätspolitik hat folgende Aufgaben:
Definieren Sie die managementâ € ™ s Engagement für Qualität –
Definieren Sie die CompanyA € ™ s Ziele in Bezug auf Qualität, das heißt, welche Managementmittel durch Qualität –
Seien Sie relevant ist für die Customerâ € ™ s Bedürfnisse –
– In der Organisation zu verstehen,
– Umgesetzt werden


– Erklärung zu vage oder Politik wird nicht von Personal verstanden
– Qualitätspolitik ist nicht implementiert.

Z.B. der Qualitätspolitik

â € žWir Qualität durch motivierte und qualifizierte Mitarbeiter, definierte Arbeitsabläufe zu erreichen, und eine intensive Prüfung und Prüfung activities.â €

1.2 Organisation

Die Norm fordert Dokumentation von Verantwortung, Autorität und die Zusammenarbeit aller Mitarbeiter Qualität zu beeinträchtigen. Das bedeutet, dass, wenn eine Person eine Verantwortung hat, wird sie offiziell vom zuständigen Manager zugewiesen werden. Die Person sollte die Befugnis haben, die Verantwortung zu erfüllen.

Nach ISO, Verantwortung bedeutet:

â € œa Pflicht zu handeln zustellen? € ™ s selbst, wenn etwas getan werden muss, ohne Tolda € zu sein.


– Bestehende einer Verantwortung, die nicht erfüllt werden können.


– Projektleitung
– Projekt Kunde
– Projektinstandhaltungsbetrieb
– Software-Entwicklung-Hardware-Entwicklung
– Wartung Organisation-Help-Desk
– Umsatzentwicklung

Ressourcen verlangen, dass der Lieferant:
Identifizieren Sie die Anforderungen an Ressourcen –
– Geschultes Personal zuordnen.

Managementmitarbeiter erfordert Ernennung des Managers Vertreter mit Autorität und Verantwortung zu:
– Stellen Sie sicher, dass das Unternehmen die Anforderungen nach ISO 9001 erfüllt
– Melden Sie die Leistung des Qualitätssicherungssystems zu Unternehmensführung

1.3 Management Review

Qualitätsmanager sollten in regelmäßigen Abständen die Ergebnisse präsentieren von
– Qualitätsprüfungen
– Statistik der Qualität Beschwerden
– Aufzeichnungen über Korrekturmaßnahmen

Die Ergebnisse sollten mit Hinweisen auf die teilnahmen an einem aufgezeichneten Management-Meeting präsentiert werden, was präsentiert wurde und welche Entscheidungen wurden getroffen und machte.

2. Qualitätsmanagementsystem

Qualitätssystem â € “”â € žDie Organisationsstruktur, Verantwortlichkeiten, Verfahren, Prozesse und Ressourcen für die Umsetzung von Qualitäts management.â €

Verfahren, Regeln werden Entscheidungen setzen in das Schreiben werden. Wenn Sie eine Regel oder Verfahren, die nicht nach ISO 9001 erforderlich ist, verlangt der Standard immer noch, dass es geschrieben wird.

Ein Qualitätshandbuch muss Referenz und Dokumentation des Qualitätssicherungssystems enthalten.


– Ein Audit ist eine Probe, wenn also in einer Probe, gibt es geringfügige Abweichungen, und sie sind fest vorgegeben, es immer noch eine Nichtkonformität sein kann, weil der Prüfer vermuten kann, dass es viele weitere kleinere Nonkonformitäten sind.
– Bestehende schriftliche Verfahren werden nicht eingehalten.

3. Vertragsprüfung

Der Lieferant prüft vor Unterzeichnung des Vertrags, dass die Organisation in der Lage sein, zu erfüllen, was durch den Vertrag erforderlich ist.

Fragen, die gestellt werden sollten, umfassen:
– Sind die Anforderungen dokumentiert und verstanden?
– Sind Akzeptanzkriterien enthalten?
– Wurden die Anforderungen aus der Ausschreibung gelöst unterscheiden?
– Kann der Lieferant genügend Ressourcen für den Auftrag aufbringen?
– Können aufbieten der Lieferant die Kompetenz für den Auftrag benötigt?
– Kann die Aufgabe rechtzeitig abgeschlossen werden?

Der Standard verlangt, dass ein dokumentiertes Verfahren mit Bewertungen enthalten sein. Der Lieferant zu ermitteln, wie Vertragsänderungen und die Handhabung von Anforderungen Spezifikation zwischen Kunden und Lieferanten definiert werden.

4. Design-Steuerung

4.1. General
ISO erfordert, dass Sie planen, bevor Sie und geben Sie vor der Gestaltung.

4.2. Entwicklungsplanung

Design-Plan sollte enthalten:
– Definition der Methodik werden in der Entwicklung von Produkt verwendet
– Zeitpläne, Verantwortlichkeiten, Arbeitsaufträge und Terminkontrolle
– Phasen Projekt wird geteilt. Dazu gehören Eingabe, Ausgabe und Überprüfung der Ausgabe.
– Beschreibung der Methoden und Werkzeuge verwendet werden

Qualitätsplan sollte enthalten:
– Qualitätsziele
– Kriterien für die Akzeptanz
– Identifizierung der Planung, Validierung und Verifikation.
– Verantwortung für die Qualitäts Aktivitäten.

Will ein Unternehmen ISO-Qualifikation die Pläne zu gewinnen, muss in allen Projekten gehalten werden, da die ISO-Zertifizierung für das gesamte Unternehmen und nicht für bestimmte Projekte.

4.3 Organisatorische und technische Schnittstellen

Wenn es Gruppenarbeit ist, sind die Schnittstellen zwischen ihnen zu denen die Informationen benötigen identifiziert, dokumentiert und übertragen werden. Die Dokumentation wird regelmäßig überprüft.

4.4 Design-Eingang

Anforderungen Spezifikationen enthalten, die Design-Input in der Softwareentwicklung. Dies kann durch den Käufer oder hergestellt durch den Lieferanten mit Gesetzen und Vorschriften erfolgen. Ein weiteres Design-Eingang umfasst Design-Codierung, die als Eingabe für Codierung verwendet wird.

Die Norm will sicherstellen, dass die Arbeitsergebnisse der einzelnen Schritte die Anforderungen erfüllt.

In der Software-Entwicklung sind, Anforderungsänderungen gemeinsam so ein Verfahren für den Umgang mit neuen und geänderten Anforderungen des Käufers erstellt werden.

4.5 Design-Output

Design-Output: die Design-Dokumentation und der Quellcode. ISO erfordert, dass Design-Dokumente und die Codierung vor der Veröffentlichung überprüft werden.

Ein Verfahren für die Annahme der Auslegungsleistung und Kriterien der Annahme geschaffen werden.

4.6 Design Review

Projektfunktionen wie Kodierung und Prüfung sind bei der Überprüfung vorgelegt werden. Ein übliches Verfahren zur Sicherstellung Bewertungen sind Checklisten.

4.7 Design Verification

Diese besteht aus Bewertungen, Modultests und Integrationstests.

4.8 Designvalidierung

Abschließende Systemtest der kompletten Software-Produkt zusammen mit der Überprüfung der Benutzerdokumentation. Es sollte Validierung geplant und dokumentiert werden. Beta-Tests ist in Übereinstimmung mit ISO, solange die Beta-Tests durch eine klare Vereinbarung zwischen Lieferant und Beta-Tests Kunden abgedeckt ist.

4.9 Design-Änderungen

ISO 9001 erfordert nach der Freigabe der Konstruktionsunterlagen oder Quelle, dass alle Änderungen durch einen formalen Prozess gehen wird, wo Änderungen dokumentiert, überprüft und vor der Umsetzung genehmigt.

Unkontrollierte Änderungen an komplexen technischen Dokumente oder Programme sind extrem gefährlich und als solche dem Standard erlaubt es nicht.
5. Dokumenten- und Datenkontrolle

Informationen, die die Entwicklung / Wartung von Software steuert. Der Standard verlangt, dass diejenigen, die ein Dokument benötigen / Daten Zugriff haben soll. Änderungen an Dokumenten und Daten werden kontrolliert.

5.1 Allgemeines

Externe Dokumente und Daten werden gespeichert. Es kann auf jedem Formular (Hardcopy, elektronische Medien) gespeichert werden.

5.2 Dokumenten- und Daten Zulassung und Ausgabe

Vor Ausgabe von Dokumenten und Daten müssen überprüft und vor jeder Ausgabe genehmigt werden. Eine Dokumentenliste, in der eine wird die aktuelle Version eines Dokuments erfahren. Ungültige oder veralteter Dokumente sollten entfernt oder deutlich gekennzeichnet sein.

5.3 Dokumenten- und Datenänderungen

Die Person / s verantwortlich für die Überprüfung und Genehmigungsverfahren soll festgelegt werden.

6. Einkauf

Im Falle der Subunternehmer, sind Sie noch verantwortlich. D. h wenn Sie für einen Vertrag gelten und vergeben die Arbeit, ist ISO-Normen noch unter Ihrer Verantwortung und ISO Anforderungen nicht dem Zulieferer auferlegte werden.

6.1 Allgemeines

Wenn Arbeitskräfte gekauft wird, verlangt der Standard eine Prozedur zu folgen, dass Sie die richtigen Leute zu bekommen. Die Menschen werden durch Lieferanten und nicht Subunternehmer gesteuert werden.
Um diese gekaufte Software gewährleisten entspricht den Anforderungen:
– Vertragsanforderungen an die Subunternehmer Verfahren
– Prüfung des Subunternehmers Qualitätsmanagementsystem
– Überprüfen Sie Subunternehmer historische Performance
Umfrage der Subunternehmer bei der Vertrags –
– Witness Überprüfen und Testen
– Prüfung und Bewertung Produkt von Subunternehmer.

6.2 Bewertung von Subunternehmern

Person mit der notwendigen Autorität und Kompetenz stellt jedem Subunternehmer beurteilen und entscheiden, ob sie zu verwenden. Die Entscheidungen sind zu dokumentieren.

Der Lieferant muss entscheiden, welche die Kontrolle über Subunternehmer wird es haben. Die Norm nicht erwähnt, wie viel Kontrolle Sie haben sollten. Er erwähnt nur, dass eine Entscheidung sollte durch Tatsachen gestellt werden.

Ein Sonderfall ist, wenn die Software über den Einzelhandel gekauft wird. In diesem Fall ist Subunternehmer Organisation mit dem der Kauf erfolgt, nicht der ursprüngliche Entwickler der Software.

Wenn der Kauf über den Einzelhandel ISO getan erfordert 9001, dass Sie definieren, in welchem Umfang Sie Anforderungen an die Händler setzen ihre Zulieferer zu kontrollieren.

6.3 Einkaufsdaten

Die Anforderungen an Entwicklungsprozess wird zusammen mit Lieferantenanforderungen im Vertrag dokumentiert werden Arbeitsergebnisse und Verfahren zu genehmigen.

6.4 Verifizierung von beschafften Produkten

Dokumentation von Entscheidungen über die Überprüfung jeder erworbenen Entwicklungswerkzeug oder enthalten Produkt.

– Keine Liste der zugelassenen Lieferanten
– Unangemessene Kontrolle der Subunternehmer
– Kein Dokument Überprüfung der gekauften Artikel
– Unangemessene Vertrag mit Subunternehmer.

7 Steuerung von Kunden bereitgestellte Produkt

Der Lieferant muss über Verfahren für die Kontrolle, Lagerung und Pflege der Kunden gelieferten Software. Allerdings ist die Qualität in der Verantwortung der Software.

Eine Nichteinhaltung geschieht aufgrund unklarer Verantwortung der Verantwortung zwischen Kunden und Lieferanten.

8 Produktspezifikation und Rückverfolgbarkeit

Der Software-Anbieter sollte die Kontrolle behalten:
– Auf was Dokument vor und geben es basiert
– Auf welcher Spezifikation basiert es
– Welche Korrekturen und Ergänzungen haben, in der Source-Programme aufgenommen worden
– Was geschah mit jedem Problembericht
– Aus welcher Quelle ein bestimmtes Modul generiert wurde.

9 Prozesssteuerung

Dokumentiertes Verfahren für den Replikationsprozess in den Betrieb und die Verfahren für den Umgang mit Master Proma € ™ s / Bibliotheken. Um sicherzustellen, dass die korrekte Versionierung verwendet wird.

– Keine dokumentiertes Verfahren für die Replikation
– Unsachgemäßer Umgang mit Master Proma € ™ s oder Disketten.

10 Inspektion und Test

Schriftliche Verfahren für die Inspektion und Prüfung, die im Zusammenhang mit der Replikation erfolgen.

– Funktion der automatisch Proma € ™ s Überprüfung nicht inspiziert worden
– Kein Verfahren dokumentiert für die Prüfung Proma € ™ s.

11 Steuerung der Inspektion, Mess- und Prüfgeräte

Der Lieferant sollte die geeignete Messmittel auszuwählen und ein dokumentiertes Verfahren für die Steuerung der Ausrüstung folgen. Jede neue Software-Version sollte für Versorgung getestet werden.

12 Inspektion und Test-Status

Technische Daten und Programme sollten durch Bewertungen und Tests verifiziert. Der Lieferant muss über Verfahren verfügen, die Verwendung von nicht verifizierten Daten oder Programme zu verbieten.

13 Steuern von Nicht konforme Produkt

Nichtkonforme Produkte sollten nicht unbeabsichtigt verwendet werden. Ein Verfahren für den Umgang mit schnellen Änderungen bei kritischen Fehlern geschaffen werden.

– Eindeutige Identifizierung der kontrollierten Elemente, die nicht korrigierten Fehler enthalten
– Verfahren zu entlocken Kundenakzeptanz bei Lieferung
– Bei schnellen Änderungen, muss sie dokumentiert werden
– So geänderte Objekte Überprüfung wird auf denselben Status wie Rest-Software erhöht werden.

14 Korrektur- und Vorbeugungsmaßnahmen

– Effektiver Umgang mit Berichten, die nicht den Anforderungen
– Effektiver Umgang mit Meldungen Schwachstellen bei den Entwicklungsprozess angibt,
– Aktive Sammlung und Analyse der verfügbaren Informationen über Produkt- und Prozessnichtkonformität und Vorbeugungsmaßnahmen.

Informationen über Probleme sollten Verbesserungen des Entwicklungsprozesses fahren angetroffen.

– Kundenbeschwerde wurde nicht richtig behandelt
– Mangel wurde gefunden, jedoch nicht korrigiert
– Kein Verfahren, um sicherzustellen, dass die Probleme analysiert und beaufschlagten
– Kein Verfahren für die Schwierigkeiten bei der Anwendung von Regeln und Verfahren berichten.

15 Handhabung, Lagerung, Verpackung, Konservierung und Versand

Gilt für Software auf PROM, Platte oder einem anderen Medium repliziert.
Medien müssen korrekt gekennzeichnet und verpackt werden. Die Daten werden gesichert. Es sollte auch die Fähigkeit sein, den Schutz vor unbeabsichtigten Schäden zu sorgen.

16 Lenkung von Qualitätsaufzeichnungen

Qualitätsdokumente zeigen, welche Maßnahmen getroffen wurden, um sicherzustellen, oder die Qualität prüfen. Der Standard verlangt, dass es für die Handhabung von Qualitätsaufzeichnungen ein Verfahren sein. Die Aufzeichnungen sollten in geeigneter Weise gespeichert werden, so dass sie leicht zugänglich sind.
– Keine Regeln für die Aufbewahrung von Qualitätsaufzeichnungen
– Überprüfung Datensätze werden nicht gehalten
– Testdatensätze werden nicht gehalten
– Zeitraum der Qualitätsaufzeichnungen zu halten ist nicht definiert

17 Interne Qualitätsaudits

Es sollte eine unabhängige Einheit sein, die regelmäßig alle Operationen Audits, die Produkt- oder Servicequalität beeinträchtigen können. Diese werden im Auftrag der Unternehmensführung durchgeführt. Es sollte ein Auditplan sein.

– Keine Prüfungsplan
– Auditplan nicht auf dem neuesten Stand

18 Trainings

Unternehmen sollten, dass die Mitarbeiter sicherzustellen, dass für Aufgaben geschult erforderlich. Ein Verfahren:
– Schulungsbedarf für die einzelnen Mitarbeiter Position identifizieren
– Geben Sie eine solche Ausbildung
Aufzeichnungen über die Schulung aller Mitarbeiter -.

Die Ausbildung sollte dokumentiert und ausreichend sein. Durch ausreichend meinen wir, dass die Person, von der Durchführung seiner / ihrer Arbeit auf eine ausreichend hohe Standard möglich ist.

– Keine Verfahren für die Planung oder Ausbildung
– Keine Trainingsaufzeichnungen
– Erhielt nicht die richtige Ausbildung für seine Aufgabe.

19 Servicing

Der Lieferant wird über dokumentierte Verfahren für die Wartung, wenn dies im Vertrag erwähnt wird. In der Software handelt es sich um Fehlerkorrekturen und Verbesserungen gelieferte Software.

Verfahren für Beschwerden und Anträge auf Änderungen der Handhabung. Der Lieferant ist nicht verpflichtet, die Wartung zur Verfügung zu stellen, wenn sie nicht in den Auftrags erwähnt wird. Wartungsverfahren für alte Software gemacht werden sollte.

– Wartungsarbeiten für einen Kunden ohne Vertrag
– Spezielle Verfahren zur Wartung des alten Produkts ist nicht dokumentiert
– Kein Verfahren für die Prüfung nach der Wartung.

20 statistische Techniken

Es sollte in den verschiedenen Phasen gefunden Sammlung und Analyse von Daten über die Anzahl der Fehler sein. Informationen über die Unfähigkeit Termine und Meilensteine erreichen sollten analysiert werden.

“————————————————– ————————————————– ————————————————–

μετάφραση Υποστήριξη:
————————————————– ————————————————– ————————————————–
ISO 9001 Είκοσι ποιότητα Στοιχεία

Μια ματιά θα ληφθούν στις απαιτήσεις από την άποψη των εταιρειών ανάπτυξης λογισμικού. πρότυπο ISO 9001 προοριζόταν για τη μεταποιητική βιομηχανία. Οι απαιτήσεις ερμηνείας για την ανάπτυξη λογισμικού, σύμφωνα με το πρότυπο ISO 9000-3 και TickIT.

Υπάρχουν 20 κύρια στοιχεία. Κάθε έννοια είναι καλά γνωστή στην διαχείριση της ποιότητας κοινότητα.

Ευθύνη 1. Διαχείριση

1.1 Πολιτική ποιότητας

Το πρότυπο απαιτεί από τη διοίκηση τον προμηθευτή να εκδώσει μια πολιτική ποιότητας, όπου λέει ότι η εταιρεία θα παράγει ποιοτικά προϊόντα.

Η πολιτική ποιότητας θα πρέπει:
– Ορίστε τη δέσμευση της managementâ € ™ s στην ποιότητα
– Καθορισμός των στόχων της companyâ € ™ s σχετικά με την ποιότητα, δηλαδή, αυτό της διαχείρισης μέσα από την ποιότητα
– Να σχετική με τις ανάγκες του customerâ € ™ s
– Να γίνει κατανοητό στην οργάνωση
– Να εφαρμοστεί


– Δήλωση υπερβολικά ασαφής ή της πολιτικής δεν είναι κατανοητή από το προσωπικό
– Πολιτική για την ποιότητα δεν έχει υλοποιηθεί.

Π.χ. της πολιτικής ποιότητας

â € œWe επίτευξη ποιότητας μέσω κίνητρα και εξειδικευμένο προσωπικό, καθορισμένες διαδικασίες εργασίας και εντατική εξέταση και δοκιμή activities.â €

1.2 Οργάνωση

Το πρότυπο απαιτεί την τεκμηρίωση της ευθύνης, αρμοδιότητα και διασύνδεση όλου του προσωπικού που επηρεάζουν την ποιότητα. Αυτό σημαίνει ότι αν ένα άτομο έχει την ευθύνη, θα πρέπει να ανατεθεί επισήμως από την αρμόδια διαχειριστή. Το άτομο πρέπει να έχει την εξουσία να εκπληρώσει την ευθύνη.

Σύμφωνα με το πρότυπο ISO, ευθύνη σημαίνει:

â € καθήκον OEA να ενεργεί για oneâ € ™ s δική του συμφωνία όταν κάτι πρέπει να γίνει χωρίς να Tolda €.

Μη συμμόρφωση

– Υφιστάμενες μιας ευθύνης που δεν μπορεί να εκπληρωθεί.


– Έργο-line
– Πρόγραμμα-πελάτη
– Οργάνωση του έργου συντήρησης
– Ανάπτυξη λογισμικού ανάπτυξη υλικού
– Γραφείο Συντήρηση οργάνωση-βοήθεια
– Πωλήσεις-ανάπτυξη

Πόροι απαιτούν ότι ο προμηθευτής:
– Προσδιορισμός των απαιτήσεων για τους πόρους
– Εκχώρηση εκπαιδευμένο προσωπικό.

Εκπρόσωπος της διοίκησης απαιτεί διορισμό του εκπροσώπου διευθυντής με την εξουσία και την ευθύνη να:
– Βεβαιωθείτε ότι η εταιρεία πληροί τις απαιτήσεις του προτύπου ISO 9001
– Αναφορά της απόδοσης του συστήματος ποιότητας για τη διαχείριση της εταιρείας

1.3 Ανασκόπηση Διαχείρισης

διαχειριστής της ποιότητας θα πρέπει να υποβάλλει περιοδικά τα αποτελέσματα της
– Ελέγχους ποιότητας
– Στατιστικά στοιχεία των καταγγελιών ποιότητας
– Εγγραφές των διορθωτικών ενεργειών

Τα αποτελέσματα πρέπει να παρουσιάζονται σε καταγράφονται συνάντησης διαχείρισης με σημειώσεις σχετικά με το ποιος παρευρέθηκε, τι παρουσιάστηκε και τι αποφάσεις ελήφθησαν και έκανε.

2. Σύστημα Ποιότητας

σύστημα ποιότητας â € “”â € œThe οργανωτική δομή, τις αρμοδιότητες, τις διαδικασίες, τις διεργασίες και τους πόρους για την εφαρμογή της ποιότητας management.â €

Διαδικασίες, τους κανόνες, οι αποφάσεις θα πρέπει να τεθεί στο γράψιμο. Εάν έχετε έναν κανόνα ή διαδικασία που δεν απαιτείται από το πρότυπο ISO 9001, το πρότυπο εξακολουθεί να απαιτεί ότι είναι γραμμένο.

Ένα εγχειρίδιο για την ποιότητα πρέπει να περιλαμβάνει αναφορά και τεκμηρίωση του συστήματος ποιότητας.

Μη συμμόρφωση

– Ο έλεγχος είναι ένα δείγμα, ως εκ τούτου, αν σε ένα δείγμα, υπάρχουν μικρές μη-συμμορφώσεις, και είναι σταθερό, μπορεί ακόμα να είναι μια μη-συμμόρφωση, επειδή ο ελεγκτής μπορεί να υποψιάζονται ότι υπάρχουν πολλά περισσότερα ανήλικα μη συμμορφώσεων.
– Οι υπάρχουσες γραπτές διαδικασίες δεν τηρούνται.

Επανεξέταση 3. Συμβόλαιο

Οι έλεγχοι προμηθευτή πριν από την υπογραφή της σύμβασης που ο οργανισμός είναι σε θέση να εκτελέσει αυτό που απαιτείται από τη σύμβαση.

Οι ερωτήσεις που πρέπει να ζητηθεί να περιλαμβάνουν:
– Οι απαιτήσεις τεκμηριωμένη και κατανοητή;
– Περιλαμβάνονται κριτήρια αποδοχής;
– Οι απαιτήσεις που διαφέρουν από το διαγωνισμό έχουν επιλυθεί;
– Μπορεί ο προμηθευτής να συγκεντρώσει αρκετούς πόρους για τη σύμβαση;
– Μπορεί ο προμηθευτής να συγκεντρώσει την αρμοδιότητα που απαιτείται για τη σύμβαση;
– Μπορεί το έργο να ολοκληρωθεί σε χρονικό διάστημα;

Το πρότυπο απαιτεί να συμπεριληφθεί μια τεκμηριωμένη διαδικασία με σχόλια. Ο προμηθευτής πρέπει να προσδιορίσει πώς να ορίζεται τροποποιήσεις της σύμβασης και το χειρισμό των απαιτήσεων προδιαγραφών μεταξύ πελάτη και προμηθευτή.

4. Έλεγχος Σχεδιασμού

4.1. Γενικός
ISO απαιτεί να σχεδιάζετε πριν κάνετε και να καθορίσετε πριν από το σχεδιασμό.

4.2. Σχεδιασμός και Ανάπτυξη Σχεδιασμός

σχέδιο σχεδιασμός θα πρέπει να περιλαμβάνει:
– Ορισμός της μεθοδολογίας που θα χρησιμοποιηθεί για την ανάπτυξη του προϊόντος
– Ωράριο, τις ευθύνες, τις αναθέσεις εργασίας και τον έλεγχο της προόδου
– Φάσεις του έργου θα χωριστούν. Αυτό περιλαμβάνει εισόδου, εξόδου και την επαλήθευση της εξόδου.
– Περιγραφή των μεθόδων και των εργαλείων που θα χρησιμοποιηθούν

σχέδιο ποιότητας πρέπει να περιλαμβάνει:
– Στόχους ποιότητας
– Κριτήρια αποδοχής
– Προσδιορισμός του σχεδιασμού, πιστοποίησης και της επαλήθευσης.
– Ευθύνες για τις δραστηριότητες ποιότητας.

Αν μια εταιρεία θέλει να αποκτήσει ISO προσόντα τα σχέδια θα πρέπει να πραγματοποιηθεί σε όλα τα έργα, αφού πιστοποίηση ISO είναι για το σύνολο της επιχείρησης και όχι για συγκεκριμένα έργα.

4.3 Οργανωτική και Τεχνικές διεπαφές

Αν υπάρχει ομάδα εργασίας, οι διασυνδέσεις μεταξύ τους πρέπει να προσδιορίζονται, να τεκμηριώνονται και διαβιβάζονται σε εκείνους που χρειάζονται τις πληροφορίες. Η τεκμηρίωση θα πρέπει να επανεξετάζονται τακτικά.

4.4 Σχεδιασμός Είσοδος

Απαιτήσεις προδιαγραφές περιλαμβάνουν την είσοδο του σχεδιασμού στην ανάπτυξη λογισμικού. Αυτό μπορεί να γίνει από τον αγοραστή ή καταρτίζεται από τον προμηθευτή, χρησιμοποιώντας τους νόμους και τους κανονισμούς. Μια άλλη είσοδος του σχεδιασμού περιλαμβάνει το σχεδιασμό κωδικοποίησης που χρησιμοποιείται ως είσοδος για την κωδικοποίηση.

Το πρότυπο θέλει να διασφαλίσει ότι το προϊόν εργασίας κάθε βήμα πληροί τις απαιτήσεις.

Στην ανάπτυξη λογισμικού, οι αλλαγές απαίτηση είναι κοινά τόσο να δημιουργηθεί μια διαδικασία για το χειρισμό των νέων και διαφορετικές απαιτήσεις από τον αγοραστή.

4.5 Σχεδιασμός εξόδου

Σχεδιασμός εξόδου: η τεκμηρίωση του σχεδιασμού και τον πηγαίο κώδικα. ISO απαιτεί ότι τα έγγραφα σχεδιασμού και κωδικοποίησης να αναθεωρηθεί πριν από την απελευθέρωση.

Πρέπει να δημιουργηθεί μια διαδικασία για την αποδοχή της εξόδου σχεδιασμό και τα κριτήρια αποδοχής.

4.6 Design Review

λειτουργίες του έργου, όπως κωδικοποίηση και τις δοκιμές πρέπει να προσκομίζονται κατά την επανεξέταση. Μια κοινή μέθοδος για την εξασφάλιση αξιολογήσεις είναι λίστες ελέγχου.

4.7 Έλεγχος Σχεδιασμού

Αυτή αποτελείται από σχόλια, δοκιμές μονάδα και δοκιμές ολοκλήρωσης.

4.8 Σχεδιασμός Επικύρωση

Τελική δοκιμή του συστήματος, από το πλήρες προϊόν λογισμικού σε συνδυασμό με την αναθεώρηση της τεκμηρίωσης χρήστη. Εκεί θα πρέπει να σχεδιάζονται και να τεκμηριώνεται η επικύρωση. Βήτα δοκιμή είναι σε συμμόρφωση με το πρότυπο ISO εφ ‘όσον η δοκιμή beta καλύπτεται από μια σαφή συμφωνία μεταξύ προμηθευτή και πελάτη beta-testing.

4.9 Αλλαγές Σχεδιασμός

ISO 9001 ορίζει ότι μετά την απελευθέρωση της τεκμηρίωσης του σχεδίου ή της πηγής, όλες οι αλλαγές πρέπει να περάσουν από μια τυπική διαδικασία, όπου οι αλλαγές τεκμηριώνονται, αναθεωρούνται και εγκρίνονται πριν από την εφαρμογή.

Ανεξέλεγκτη αλλαγές σε πολύπλοκα τεχνικά έγγραφα ή προγράμματα είναι εξαιρετικά επικίνδυνη και ως τέτοια το πρότυπο δεν το επιτρέπει.
5. Έγγραφο και Ελέγχου Δεδομένων

Πληροφορίες που ελέγχει την ανάπτυξη / συντήρηση του λογισμικού. Το πρότυπο απαιτεί ότι όσοι χρειάζονται κάποιο έγγραφο / στοιχεία πρέπει να έχουν πρόσβαση σε αυτό. Αλλαγές στα έγγραφα και τα στοιχεία που πρέπει να ελέγχονται.

5.1 Γενικά

Εξωτερικά έγγραφα και στοιχεία θα πρέπει να αποθηκεύονται. Μπορεί να αποθηκευτεί σε οποιαδήποτε μορφή (έντυπη, ηλεκτρονικά μέσα).

5.2 Έγγραφο και Έγκριση των δεδομένων και Έκδοσης

Πριν την έκδοση εγγράφων και δεδομένων θα πρέπει να αναθεωρηθεί και εγκριθεί πριν από κάθε θέμα. Μια λίστα με έγγραφο στο οποίο ένας από αυτούς πρέπει να μάθετε την τρέχουσα έκδοση ενός εγγράφου. Άκυρο ή παρωχημένες έγγραφα θα πρέπει να αφαιρεθούν ή να επισημαίνονται σαφώς.

5.3 Έγγραφο και τις αλλαγές των δεδομένων

Το πρόσωπο / s υπεύθυνος της διαδικασίας αναθεώρησης και έγκρισης προσδιορίζονται.

6. Προμηθειών

Στην περίπτωση του υπεργολάβου, είστε ακόμα υπεύθυνοι. Δηλ αν κάνετε αίτηση για μια σύμβαση υπεργολαβίας και την εργασία, τα πρότυπα ISO είναι ακόμα υπό την ευθύνη σας και τις απαιτήσεις του ISO δεν πρέπει να επιβληθούν στον υπεργολάβο.

6.1 Γενικά

Αν το ανθρώπινο δυναμικό έχει αγοραστεί, το πρότυπο απαιτεί από εσάς να ακολουθήσετε μια διαδικασία που θα πάρει τους σωστούς ανθρώπους. Οι άνθρωποι θα πρέπει να ελέγχεται από τον προμηθευτή και όχι υπεργολάβου.
Για να εξασφαλιστεί ότι αγόρασε το λογισμικό συμμορφώνεται με τις απαιτήσεις:
– Τις απαιτήσεις της σύμβασης σχετικά με τις διαδικασίες υπεργολάβους
– Έλεγχος των συστημάτων ποιότητας υπεργολάβος
– Ελέγξτε υπεργολάβος επιδόσεις κατά το παρελθόν
– Έρευνα για τον υπεργολάβο κατά τη διάρκεια της σύμβασης
– Επανεξέταση Μάρτυρας και δοκιμές
– Δοκιμή και αναθεώρηση του προϊόντος του υπεργολάβου.

6.2 Αξιολόγηση των Υπεργολάβων

Άτομο με απαραίτητη εξουσία και αρμοδιότητα θα κρίνει κάθε υπεργολάβου και να αποφασίσει αν θα χρησιμοποιήσει. Οι αποφάσεις πρέπει να τεκμηριώνεται.

Ο προμηθευτής θα πρέπει να αποφασίσει τι τον έλεγχο υπεργολάβος θα έχει. Το πρότυπο δεν αναφέρει πόσο έλεγχο θα πρέπει να έχετε. Απλώς αναφέρει ότι η απόφαση θα πρέπει να γίνει με τη χρήση γεγονότα.

Μια ειδική περίπτωση είναι όταν το λογισμικό που αγοράζονται μέσω λιανικής. Στην περίπτωση αυτή ο υπεργολάβος είναι οργανισμός με τον οποίο διεξάγεται η αγορά, όχι το αρχικό προγραμματιστή του λογισμικού.

Αν αγοραστική γίνεται μέσω λιανικής ISO 9001 απαιτεί να καθορίσει σε ποιο βαθμό βάζετε απαιτήσεις για τον λιανοπωλητή να ελέγξει τον προμηθευτή του.

6.3 Προμηθειών Δεδομένων

Απαιτήσεις για την αναπτυξιακή διαδικασία πρέπει να τεκμηριώνεται στη σύμβαση μαζί με τις απαιτήσεις του προμηθευτή να εγκρίνει τα αποτελέσματα και τις διαδικασίες εργασίας.

6.4 Έλεγχος των αγορασθέντων προϊόντων

Τεκμηρίωση των αποφάσεων σχετικά με την επαλήθευση της κάθε αγόρασε εργαλείο ανάπτυξης ούτε περιλαμβάνονται προϊόντος.
Μη συμμόρφωση

– Δεν λίστα των εγκεκριμένων προμηθευτών
– Ακατάλληλος έλεγχος της υπεργολάβου
– Καμία επαλήθευση έγγραφο των αγορασθέντων ειδών
– Ακατάλληλο σύμβασης με υπεργολάβο.

7 Έλεγχος των πελατών που παρέχονται Προϊόν

Ο προμηθευτής πρέπει να διαθέτει διαδικασίες για την επαλήθευση, την αποθήκευση και τη συντήρηση των πελατών παρεχόμενο λογισμικό. Ωστόσο, η ποιότητα είναι η ευθύνη του λογισμικού.

Μία μη-συμμόρφωση συμβαίνει λόγω της ασαφούς ευθύνη των ευθυνών μεταξύ πελάτη και προμηθευτή.

8 Προδιαγραφές προϊόντος και ιχνηλασιμότητα

Ο προμηθευτής του λογισμικού θα πρέπει να διατηρήσει τον έλεγχο στα ακόλουθα:
– Σε ό, τι τις προηγούμενες έγγραφο και να εκδώσει βασίζεται
– Σε ποια προδιαγραφή βασίζεται
– Τι διορθώσεις και τροποποιήσεις έχουν συμπεριληφθεί σε ποια προγράμματα πηγή
– Τι συνέβη με κάθε αναφορά προβλήματος
– Από ποια πηγή ήταν μια ειδική ενότητα που δημιουργείται.

Έλεγχος 9 Διαδικασία

Τεκμηριωμένη διαδικασία για τη διαδικασία αντιγραφής κατά τη λειτουργία και τη διαδικασία για το χειρισμό του πλοιάρχου Proma € ™ s / βιβλιοθήκες. Για να εξασφαλιστεί ότι χρησιμοποιείται σωστό εκδόσεων.

Μη συμμόρφωση
– Δεν τεκμηριωμένη διαδικασία για την αντιγραφή
– Ακατάλληλη χειρισμό του πλοιάρχου Proma € ™ s ή δισκέτες.

10 Επιθεώρηση και δοκιμή

Γραπτές διαδικασίες για την επιθεώρηση και τις δοκιμές που πρέπει να γίνουν σε σχέση με την αναπαραγωγή.

Μη συμμόρφωση
– Λειτουργία ελέγχει αυτόματα Proma € ™ s δεν έχει επιθεωρηθεί
– Δεν τεκμηριωμένη διαδικασία για τη δοκιμή Proma € ™ s.

11 Έλεγχος της Επιθεώρησης, εξοπλισμού μετρήσεων και δοκιμών

Ο προμηθευτής θα πρέπει να επιλέξετε τον κατάλληλο εξοπλισμό μέτρησης και ακολουθεί μία τεκμηριωμένη διαδικασία για τον έλεγχο του εξοπλισμού. Κάθε νέα έκδοση του λογισμικού πρέπει να ελέγχονται για επάρκεια.

12 Επιθεώρηση και της κατάστασης των δοκιμών

Προδιαγραφές και τα προγράμματα θα πρέπει να επαληθεύονται μέσω κριτικές και δοκιμές. Ο προμηθευτής πρέπει να διαθέτει διαδικασίες που να απαγορεύει τη χρήση του ανεπιβεβαίωτες προδιαγραφών ή των προγραμμάτων.

13 Έλεγχος των μη συμμορφούμενων προϊόντων

προϊόντα μη συμμορφούμενα δεν πρέπει να χρησιμοποιείται κατά λάθος. Πρέπει να δημιουργηθεί μια διαδικασία για το χειρισμό γρήγορη τροποποιήσεις σε περίπτωση κρίσιμα λάθη.

– Σαφής προσδιορισμός των ελεγχόμενων ειδών που περιέχουν μη διορθωμένα σφάλματα
– Μέθοδος για να αποσπάσει αποδοχή από τον πελάτη κατά την παράδοση
– Σε περίπτωση γρήγορο τροποποιήσεις, θα πρέπει να τεκμηριώνονται
– Επανεξέταση έτσι τροποποιημένα στοιχεία θα είναι αυξημένα σε καθεστώς ίδιο υπόλοιπο του λογισμικού.

14 διορθωτική και προληπτική δράση

– Αποτελεσματική διαχείριση των εκθέσεων που δεν συμμορφώνονται με τις απαιτήσεις
– Αποτελεσματική διαχείριση των εκθέσεων που δείχνει μικρή αδυναμίες στην αναπτυξιακή διαδικασία
– Ενεργός συλλογή και ανάλυση των διαθέσιμων πληροφοριών σχετικά με το προϊόν και τη διαδικασία μη συμμόρφωσης και προληπτικές ενέργειες.

Πληροφορίες σχετικά με τα προβλήματα που αντιμετωπίζουν πρέπει να οδηγήσει σε βελτίωση της διαδικασίας ανάπτυξης.

Μη συμμόρφωση
– Καταγγελία Πελάτης δεν έχει σωστά χειρισμός
– Ανεπάρκεια έχει βρεθεί αλλά δεν διορθώθηκαν
– Καμία διαδικασία για να εξασφαλιστεί ότι τα προβλήματα αναλύονται και ενήργησε κατά
– Καμία διαδικασία για την υποβολή εκθέσεων δυσκολίες με την εφαρμογή των κανόνων και των διαδικασιών.

15 Χειρισμός, αποθήκευση, τη συσκευασία, τη διατήρηση και Παράδοση

Ισχύει για το λογισμικό αναπαραχθεί σε PROM, δίσκο ή άλλο μέσο.
Media πρέπει να επισημαίνονται και να συσκευάζονται σωστά. Τα δεδομένα πρέπει να υποστηρίζονται. Θα πρέπει επίσης να υπάρχει η δυνατότητα να παρέχει προστασία από ακούσια ζημιά.

16 Έλεγχος των φακέλων ποιότητας

έγγραφα ποιότητας δείχνουν ποιες ενέργειες έχουν ληφθεί για να διασφαλιστεί ή να ελέγξετε την ποιότητα. Το πρότυπο απαιτεί να υπάρχει μια διαδικασία για το χειρισμό των αρχείων ποιότητας. Τα αρχεία πρέπει να αποθηκεύονται με κατάλληλο τρόπο ώστε να είναι εύκολα προσβάσιμα.
– Δεν υπάρχουν κανόνες για τη διατήρηση των φακέλων ποιότητας
– Αρχεία κριτική δεν τηρούνται
– Τα αρχεία δοκιμής δεν τηρούνται
– Περίοδος τήρησης αρχείων ποιότητας δεν ορίζεται

17 εσωτερικούς ποιοτικούς ελέγχους

Θα πρέπει να υπάρχει μια ανεξάρτητη οντότητα που ελέγχει τακτικά όλες τις ενέργειες που μπορεί να επηρεάσουν την ποιότητα του προϊόντος ή της υπηρεσίας. Αυτά είναι που διεξήχθη για λογαριασμό της διοίκησης της εταιρείας. Θα πρέπει να υπάρχει ένα σχέδιο ελέγχου.

Μη συμμόρφωση
– Δεν σχέδιο ελέγχου
– Σχέδιο ελέγχου δεν είναι μέχρι σήμερα

18 Εκπαίδευση

Η εταιρεία θα πρέπει να διασφαλίσει ότι το προσωπικό έχει εκπαιδευτεί για τα καθήκοντα που απαιτούνται. Μια διαδικασία για:
– Προσδιορισμός των αναγκών κατάρτισης για κάθε θέση του προσωπικού
– Παροχή τέτοια εκπαίδευση
– Διατηρήστε τα αρχεία της εκπαίδευσης όλων των μελών του προσωπικού.

Εκπαίδευση θα πρέπει να τεκμηριώνεται και επαρκής. Με επαρκή εννοούμε ότι το άτομο είναι σε θέση να εκτελέσουν την εργασία του / της σε ένα αρκετά υψηλό επίπεδο.

Μη συμμόρφωση
– Δεν διαδικασίες για το σχεδιασμό ή την κατάρτιση
– Δεν αρχεία εκπαίδευσης
– Δεν λαμβάνονται την κατάλληλη εκπαίδευση για την εργασία του.

19 Συντήρηση

Προμηθευτής διαθέτει τεκμηριωμένες διαδικασίες για την εξυπηρέτηση αν αυτό αναφέρεται στη σύμβαση. Στο λογισμικό που είναι σχετικά με τις διορθώσεις σφαλμάτων και βελτιώσεις για να παραδοθεί το λογισμικό.

Διαδικασίες για το χειρισμό παραπόνων και αιτημάτων για τροποποιήσεις. Ο προμηθευτής δεν υποχρεούται να παρέχει συντήρηση και αν δεν αναφέρεται στη σύμβαση. θα πρέπει να γίνει διαδικασίες συντήρησης για το παλιό λογισμικό.

Μη συμμόρφωση
– Εργασίες συντήρησης για έναν πελάτη χωρίς σύμβαση
– Ειδικές μέθοδοι για τη συντήρηση του παλιού προϊόντος δεν έχει τεκμηριωθεί
– Καμία διαδικασία για τη δοκιμή μετά τη συντήρηση.

20 Στατιστικές Τεχνικές

Θα πρέπει να υπάρχει συλλογή και ανάλυση των δεδομένων σχετικά με τον αριθμό των σφαλμάτων που διαπιστώθηκαν στις διάφορες φάσεις. πρέπει να αναλύονται πληροφορίες σχετικά με την αδυναμία να τηρήσει τις προθεσμίες και τα ορόσημα.

“————————————————– ————————————————– ————————————————–

અનુવાદ આધાર:
————————————————– ————————————————– ————————————————–
ISO 9001 ટ્વેન્ટી ગુણવત્તા તત્વો

એક નજર સોફ્ટવેર વિકસાવવા કંપનીઓ દ્રષ્ટિબિંદુ માંથી જરૂરિયાતો પર લેવામાં આવશે. ISO 9001 પ્રમાણભૂત ઉત્પાદન ઉદ્યોગ માટે કરવાનો ઈરાદો હતો. જરૂરીયાતો ISO 9000-3 અને TickIT અનુસાર સોફ્ટવેર વિકાસ માટે અર્થઘટન કરવામાં આવે છે.

20 મુખ્ય ઘટકો હોય છે. દરેક ખ્યાલ સારી રીતે ગુણવત્તા વ્યવસ્થાપન સમુદાય ઓળખાય છે.

1. મેનેજમેન્ટ જવાબદારી

1.1 જાત નીતિ

પ્રમાણભૂત ગુણવત્તા નીતિ છે, જ્યાં તે કહે છે કે કંપની ગુણવત્તા ઉત્પાદનો ઉત્પાદન રહેશે અદા કરવા માટે સપ્લાયર મેનેજમેન્ટ જરૂરી છે.

જાત નીતિ રહેશે:
– વ્યાખ્યાયિત managementâ € ™ ઓ ગુણવત્તા માટે પ્રતિબદ્ધતા
– ગુણવત્તા સંબંધિત વ્યાખ્યાયિત companyâ € ™ ઓ હેતુઓ છે, કે જે, શું સંચાલન ગુણવત્તા અર્થ
– Customerâ € ™ ઓ જરૂરિયાતો સાથે સુસંગત હોવાનું
– સંસ્થા સમજી શકાય
– અમલ કરી શકાય


– ખૂબ અસ્પષ્ટ અથવા નીતિ નિવેદન સ્ટાફ દ્વારા સમજી નથી
– જાત નીતિ અમલમાં નથી.

ઉ.દા. ગુણવત્તા નીતિ

â € œWe પ્રેરિત અને કુશળ સ્ટાફ દ્વારા ગુણવત્તા, વ્યાખ્યાયિત કામ પ્રક્રિયાઓ, અને સઘન સમીક્ષા અને activities.â € પરીક્ષણ હાંસલ

1.2 સંસ્થા

પ્રમાણભૂત જવાબદારી, સત્તા અને ગુણવત્તા અસર તમામ કર્મચારીઓ interrelation દસ્તાવેજીકરણ આવશ્યક છે. આનો અર્થ એ થાય કે જો કોઈ વ્યક્તિ એક જવાબદારી છે, તે ઔપચારિક યોગ્ય મેનેજર દ્વારા સોંપાયેલ આવશે. વ્યક્તિ જવાબદારી પૂરી કરવા માટે સત્તા હોવી જોઇએ.

ISO અનુસાર, જવાબદારી અર્થ છે:

કરો ત્યારે કંઈક toldâ € વિના કરવામાં આવે છે € œa ફરજ oneâ € ™ ઓ પોતાના સમજૂતી પર કામ કરવા માટે.

અનુરૂપ ન હોવું

– એક જવાબદારી છે કે નથી પરિપૂર્ણ કરી શકે છે અસ્તિત્વ ધરાવે છે.


– પ્રોજેક્ટ લાઇન
– પ્રોજેક્ટ ગ્રાહક
– પ્રોજેક્ટ જાળવણી સંસ્થા
– સોફ્ટવેર વિકાસ-હાર્ડવેર વિકાસ
– જાળવણી સંસ્થા-સહાયતા ડેસ્ક
– વેચાણ વિકાસ

સ્રોતો જરૂર સપ્લાયર છે:
– સંપત્તિ માટે જરૂરીયાતો ઓળખો
– તાલીમ પામેલા કર્મચારીઓ સોંપો.

મેનેજમેન્ટ પ્રતિનિધિ સત્તા અને જવાબદારી સાથે મેનેજર પ્રતિનિધિ નિમણૂક જરૂરી છે:
– ખાતરી કરો કે કંપની ISO 9001 જરૂરીયાતો નિભાવે
– કંપની મેનેજમેન્ટ ગુણવત્તા સિસ્ટમ પરફોર્મન્સ રિપોર્ટ

1.3 વ્યવસ્થાપન સમીક્ષા

ગુણવત્તા મેનેજર સમયાંતરે પરિણામો રજૂ કરીશું
– ગુણવત્તા ઓડિટમાં
– ગુણવત્તા ફરિયાદો આંકડા
– સુધારાત્મક પગલાં રેકોર્ડ

પરિણામો જે હાજરી આપી પર નોંધો, શું રજૂ કરવામાં આવ્યો હતો અને શું નિર્ણયો લેવામાં આવ્યા હતા અને સાથે કરવામાં એક રેકોર્ડ મેનેજમેન્ટ બેઠકમાં રજૂ કરવી જોઈએ.

2. ગુણવત્તા સિસ્ટમ

ગુણવત્તા સિસ્ટમ € “”â € ધ સંસ્થાકીય માળખું, જવાબદારીઓ, પ્રક્રિયાઓ, પ્રક્રિયાઓ અને ગુણવત્તા management.â € અમલીકરણ માટે સંસાધનો

પ્રક્રિયા, નિયમો, નિર્ણયો લેખન માં મૂકી શકાય નહિ. તમે એક નિયમ અથવા પ્રક્રિયા કે જે ISO 9001 દ્વારા જરૂરી નથી છે તો, મૂળભૂત હજુ પણ જરૂરી છે કે તે લખવામાં આવે છે.

એક જાત માર્ગદર્શિકા સંદર્ભ અને ગુણવત્તા સિસ્ટમ દસ્તાવેજીકરણ સમાવી રહેશે.

અનુરૂપ ન હોવું

– એક ઓડિટ એક નમૂનો છે, તેથી જો એક નમૂનો, ત્યાં નાના બિન-conformances છે, અને તેઓ નિશ્ચિત હોય છે, તે હજુ પણ એક બિન-સિદ્ધાંતો હોઈ શકે છે કારણ કે ઓડિટર શંકા કરી શકો છો ઘણા વધુ નાના બિન-conformances હોય છે.
– હાલની લખવામાં કાર્યવાહી વળગી રહેવું નથી.

3. કરારની સમીક્ષા

હસ્તાક્ષર કરાર પહેલાં સપ્લાયર તપાસે છે કે સંસ્થા કરવા માટે શું કરાર દ્વારા જરૂરી છે કરવાનો પ્રયત્ન.

પ્રશ્નો કે પૂછવામાં જોઈએ સમાવેશ થાય છે:
– જરૂરીયાતો દસ્તાવેજીકરણ અને સમજવામાં આવે છે?
– સ્વીકૃતિ માપદંડ સમાવેશ થાય છે?
– ટેન્ડર અલગ જરૂરિયાતો ઉકેલાઈ ગયેલ છે?
– સપ્લાયર કરાર માટે પૂરતાં સંસાધનો હાજરી કરી શકો છો?
– સપ્લાયર યોગ્યતા કરાર માટે જરૂરી હાજરી કરી શકો છો?
– કાર્ય સમય માં પૂર્ણ કરી શકાય?

પ્રમાણભૂત જરૂરી છે કે સમીક્ષાઓ સાથે દસ્તાવેજીકરણ પ્રક્રિયા સમાવેશ થાય છે કરી શકાય છે. સપ્લાયર ઓળખવા જોઈએ કેવી રીતે કરાર સુધારા અને ગ્રાહક અને સપ્લાયર વચ્ચે જરૂરિયાતો સ્પષ્ટીકરણ હેન્ડલિંગ વ્યાખ્યાયિત કરી શકાય છે.

4. ડિઝાઇન નિયંત્રણ

4.1. જનરલ
ISO જરૂરી છે કે તમે શું કરી રહ્યા છે તે પહેલાં યોજના અને ડિઝાઇન પહેલાં સ્પષ્ટ કરો.

4.2. ડિઝાઇન અને વિકાસ આયોજન

ડિઝાઇન યોજના ધરાવતી હોવી જોઈએ:
– પદ્ધતિ વ્યાખ્યા ઉત્પાદન વિકાસ કરવા માટે વાપરી શકાય
– સમય સમયપત્રક, જવાબદારીઓ, કામ સોંપણીઓ અને પ્રગતિ નિયંત્રણ
– ચાલુ સમય અને તારીખ પ્રોજેક્ટ વિભાજિત કરવામાં આવશે. આ ઇનપુટ, આઉટપુટ અને આઉટપુટ ચકાસણી સમાવેશ થાય છે.
– પદ્ધતિઓ અને સાધનો વર્ણન વાપરી શકાય

ગુણવત્તા યોજના ધરાવતી હોવી જોઈએ:
– ગુણવત્તા લક્ષ્યો
– સ્વીકાર્યતા માટે માપદંડ
– આયોજન, માન્યતા અને ચકાસણી ઓળખ.
– ગુણવત્તા પ્રવૃત્તિઓ માટે જવાબદારી.

એક કંપની, ISO લાયકાત યોજના તમામ પ્રોજેક્ટમાં રાખવામાં હોવી જ જોઈએ મેળવવા માટે, કારણ કે ISO પ્રમાણપત્ર ચોક્કસ પ્રોજેક્ટ માટે સમગ્ર કંપની માટે છે અને માંગે છે.

4.3 સંસ્થાકીય અને ટેકનિકલ ઈન્ટરફેસો

જો ત્યાં જૂથ કાર્ય, તેમની વચ્ચે ઇન્ટરફેસો, ઓળખી શકાય જોઈએ દસ્તાવેજીકરણ અને માહિતી જરૂર છે તે માટે ફેલાય. દસ્તાવેજીકરણ નિયમિત સમીક્ષા કરવામાં આવશે.

4.4 ડિઝાઇન ઇનપુટ

જરૂરીયાતો સ્પષ્ટીકરણો સોફ્ટવેર વિકાસ ડિઝાઇન ઇનપુટ છે. આ ખરીદનાર દ્વારા કરવામાં અથવા સપ્લાયર કાયદાઓ અને નિયમો ઉપયોગ કરીને તૈયાર કરી શકે છે. અન્ય ડિઝાઇન ઇનપુટ ડિઝાઇન કોડિંગ જે કોડિંગ માટે ઇનપુટ તરીકે ઉપયોગ થાય છે સમાવેશ થાય છે.

પ્રમાણભૂત તેની ખાતરી કરવા માટે કે દરેક પગલું કામ ઉત્પાદન જરૂરિયાતો મળે માંગે છે.

સોફ્ટવેર વિકાસ, જરૂરિયાત ફેરફારો સામાન્ય હોય છે, જેથી ખરીદનાર ના નવા અને બદલાયેલ જરૂરિયાતો સંભાળવા માટે એક પ્રક્રિયા બનાવી શકાય.

4.5 ડિઝાઇન આઉટપુટ

ડિઝાઇન આઉટપુટ: ડિઝાઇન દસ્તાવેજીકરણ અને સ્રોત કોડ. ISO જરૂરી કોડિંગ ડિઝાઇન દસ્તાવેજો અને પ્રકાશન પહેલાં સમીક્ષા કરવામાં.

ડિઝાઇન ઉત્પાદન અને સ્વીકૃતિ માપદંડ સ્વીકાર માટે કાર્યવાહી બનાવાયેલ હોવી જોઈએ.

4.6 ડિઝાઇન સમીક્ષા

કોડિંગ અને પરીક્ષણ જેવા પ્રોજેક્ટ કાર્યો સમીક્ષા અંતે પ્રસ્તુત કરવામાં આવશે. સમીક્ષાઓ ખાતરી કરવા માટે એક સામાન્ય પદ્ધતિ checklists છે.

4.7 ડિઝાઇન ચકાસણી

આ સમીક્ષા, કરેલ મોડ્યુલમાં કરેલ પરીક્ષણ અને સંકલન પરીક્ષણ સમાવેશ થાય છે.

4.8 ડિઝાઈન માન્યતા

અંતિમ સિસ્ટમ પરીક્ષણ, સંપૂર્ણ સોફ્ટવેર ઉત્પાદન સાથે વપરાશકર્તા દસ્તાવેજીકરણ સમીક્ષા સાથે. ત્યાં આયોજન અને દસ્તાવેજીકરણ માન્યતા હોવી જોઈએ. બીટા પરીક્ષણ તરીકે લાંબા સમય સુધી બીટા પરીક્ષણ સપ્લાયર અને બીટા પરીક્ષણ ગ્રાહક વચ્ચે સ્પષ્ટ કરાર દ્વારા આવરી લેવામાં આવે છે ISO સિદ્ધાંતો છે.

4.9 ડિઝાઇન ફેરફારો

ISO 9001 માટે જરૂરી છે કે ડિઝાઇન કરી દસ્તાવેજો અથવા સ્રોતની ના પ્રકાશન પછી, બધા ફેરફારો ઔપચારિક પ્રક્રિયા જ્યાં ફેરફારો, દસ્તાવેજીકરણ કરવામાં આવે છે સમીક્ષા અને અમલીકરણ પહેલાં મંજૂર થવા દઈશ નહિ.

જટિલ દસ્તાવેજો અથવા કાર્યક્રમો અનિયંત્રિત ફેરફારો અત્યંત ખતરનાક છે અને જેમ કે પ્રમાણભૂત કારણ કે તે માટે પરવાનગી આપતું નથી.
5. દસ્તાવેજ અને ડેટા નિયંત્રણ

માહિતી કે જે સોફ્ટવેર વિકાસ / જાળવણી નિયંત્રિત કરે છે. પ્રમાણભૂત જરૂરી છે કે જેઓ કેટલાક દસ્તાવેજ જરૂર / માહિતી તે વપરાશ હોય છે રહેશે. દસ્તાવેજો અને માહિતી ફેરફારો નિયંત્રિત કરવામાં આવશે.

5.1 સામાન્ય

બાહ્ય દસ્તાવેજો અને માહિતી સંગ્રહિત કરવામાં આવશે. તે કોઇ પણ ફોર્મ (હાર્ડ કોપી, ઇલેક્ટ્રોનિક મીડિયા) પર સંગ્રહિત કરી શકાય છે.

5.2 દસ્તાવેજ અને ડેટા મંજૂરી અને મુદ્દો

મુદ્દો દસ્તાવેજો અને માહિતી પહેલાં સમીક્ષા અને દરેક મુદ્દા પહેલાં મંજૂર કરવામાં આવશે. દસ્તાવેજ યાદી જેમાં એક દસ્તાવેજ ની હાલની આવૃત્તિ શોધવા કરશે. અમાન્ય અથવા અપ્રચલિત દસ્તાવેજો દૂર કરવા જોઇએ અથવા સ્પષ્ટ રીતે ચિહ્નિત થયેલ.

5.3 દસ્તાવેજ અને ડેટા ફેરફારો

સમીક્ષા અને મંજૂરી પ્રક્રિયા ચાર્જ વ્યક્તિ / ઓ સ્પષ્ટ થશે.

6. ખરીદી

પેટાકોન્ટ્રાક્ટર કિસ્સામાં, તમે હજુ પણ જવાબદાર છે. એટલે જો તમે કરાર માટે લાગુ પડે છે અને કામ subcontract, ISO ધોરણો તમારા જવાબદારી હેઠળ હજુ પણ છે અને ISO જરૂરિયાતો પેટાકોન્ટ્રાક્ટર પર લાદવામાં આવી ન હોય.

6.1 સામાન્ય

માનવશક્તિ ખરીદી છે તો, મૂળભૂત એક પ્રક્રિયા કે જે તમે યોગ્ય લોકો વિચાર અનુસરો કરવા માટે જરૂરી છે. લોકો સપ્લાયર અને પેટાકોન્ટ્રાક્ટર દ્વારા નિયંત્રિત કરવામાં આવશે.
ખરીદી સોફ્ટવેર તેની ખાતરી કરવા માટે જરૂરીયાતો પાલન:
– પેટા કાર્યવાહી પર કરાર જરૂરીયાતો
– પેટાકોન્ટ્રાક્ટર ગુણવત્તા સિસ્ટમ ઓડિટ
– ચેક ભૂતકાળ કામગીરી પેટાકોન્ટ્રાક્ટર
– કરાર દરમિયાન પેટાકોન્ટ્રાક્ટર સર્વે
– સાક્ષી સમીક્ષા અને પરીક્ષણ
– ટેસ્ટ અને પેટાકોન્ટ્રાક્ટર સમીક્ષા ઉત્પાદન.

પેટા 6.2 મૂલ્યાંકન

જરૂરી સત્તા અને યોગ્યતા સાથે વ્યક્તિ દરેક પેટાકોન્ટ્રાક્ટર ફરીવાર અને નક્કી કરો કે શું ઉપયોગ કરશે. નિર્ણયો દસ્તાવેજીકરણ આવશે.

સપ્લાયર નક્કી કરશે પેટાકોન્ટ્રાક્ટર પર શું નિયંત્રણ તે હશે. પ્રમાણભૂત તમે હોવા જોઈએ કેટલી નિયંત્રણ ઉલ્લેખ કર્યો નથી. તે માત્ર ઉલ્લેખ કર્યો છે કે નિર્ણય હકીકતો ઉપયોગ કરીને થવી જોઈએ.

એક ખાસ કેસ છે જ્યારે સોફ્ટવેર રિટેલ મારફતે ખરીદી છે. આ કિસ્સામાં પેટાકોન્ટ્રાક્ટર સંસ્થા છે, જે સાથે ખરીદી કરવામાં આવે છે, નથી સોફ્ટવેરના મૂળ ડેવલપર છે.

ખરીદ રિટેલ ISO દ્વારા કરવામાં આવે છે, તો 9001 માટે જરૂરી છે કે તમે કેટલી હદ સુધી તમે તેના સપ્લાયર નિયંત્રિત કરવા માટે રિટેલર પર જરૂરિયાતો મૂકવામાં વ્યાખ્યાયિત કરે છે.

6.3 પરચેઝિંગ ડેટા

વિકાસ પ્રક્રિયા પર જરૂરીયાતો કામ પરિણામો અને કાર્યવાહી મંજૂર સપ્લાયર જરૂરીયાતો સાથે સાથે કરાર દસ્તાવેજીકૃત કરવામાં આવશે.

ખરીદી ઉત્પાદન 6.4 ચકાસણી

દરેક ચકાસણી વિશે નિર્ણયો દસ્તાવેજીકરણ વિકાસ સાધન અથવા સમાવેશ થાય છે ઉત્પાદન ખરીદી હતી.
અનુરૂપ ન હોવું

– મંજૂર સપ્લાયર્સ કોઈ યાદી
– પેટાકોન્ટ્રાક્ટર અયોગ્ય નિયંત્રણ
– ખરીદી વસ્તુઓ કોઈ દસ્તાવેજ ચકાસણી
– પેટાકોન્ટ્રાક્ટર સાથે અયોગ્ય કરાર.

ગ્રાહક પૂરી પાડવામાં ઉત્પાદન 7 નિયંત્રણ

સપ્લાયર ચકાસણી, સંગ્રહ અને ગ્રાહક પૂરી પાડવામાં સોફ્ટવેર જાળવણી માટે કાર્યવાહી રહેશે. જો કે, ગુણવત્તા સોફ્ટવેર ની જવાબદારી છે.

બિન-સિદ્ધાંતો ગ્રાહક અને સપ્લાયર વચ્ચે જવાબદારી અસ્પષ્ટ જવાબદારી કારણે થાય છે.

8 ઉત્પાદન સ્પષ્ટીકરણ અને Traceability

સોફ્ટવેર સપ્લાયર પર નિયંત્રણ રાખવા જોઈએ:
– શું દસ્તાવેજ અગાઉના અને તે મુદ્દા પર આધારિત છે
– જે સ્પષ્ટીકરણ પર તે આધારિત છે
– શું સુધારા અને સુધારા જે સોર્સ કાર્યક્રમો સમાવેશ કરવામાં આવ્યો છે
– દરેક સમસ્યાની જાણ કરવા માટે શું થયું
– શું સ્ત્રોત માંથી ચોક્કસ મોડ્યુલ પેદા કરવામાં આવી હતી.

9 પ્રક્રિયા નિયંત્રણ

માસ્ટર Proma € ™ ઓ / લાઈબ્રેરીઓ નિયંત્રણ માટે કામગીરી અને પ્રક્રિયા નકલ પ્રક્રિયા માટે પ્રક્રિયા દસ્તાવેજીકરણ. ખાતરી કરો કે જે યોગ્ય વર્શનિંગ ઉપયોગ થાય છે.

અનુરૂપ ન હોવું
– નકલ માટે આ બોલ પર કોઈ દસ્તાવેજીકરણ પ્રક્રિયા
– માસ્ટર Proma € ™ ઓ અથવા ડિસ્ક અયોગ્ય હેન્ડલિંગ.

10 નિરીક્ષણ અને પરીક્ષણ

નિરીક્ષણ અને પરીક્ષણ માટે લખાયેલી કાર્યવાહી નકલ સાથે જોડાણ કરવામાં આવશે.

અનુરૂપ ન હોવું
– આપમેળે ચકાસણી Proma € ™ ઓ કાર્ય પરીક્ષણ કરવામાં આવ્યું નથી
– કોઈ પરીક્ષણ Proma € ™ ઓ માટે પ્રક્રિયા દસ્તાવેજીકરણ.

નિરીક્ષણ, માપન અને પરીક્ષણ સાધનો 11 નિયંત્રણ

સપ્લાયર યોગ્ય માપદંડ સાધનો પસંદ કરો અને સાધનો નિયંત્રણ માટે એક દસ્તાવેજી પ્રક્રિયા અનુસરો જોઈએ. દરેક નવા સોફ્ટવેર આવૃત્તિ પર્યાપ્તતા માટે પરીક્ષણ જોઇએ.

12 નિરીક્ષણ અને ટેસ્ટ સ્થિતિ

વિશિષ્ટતાઓ અને કાર્યક્રમો સમીક્ષાઓ અને પરીક્ષણ મારફતે ચકાસણી કરીશું. સપ્લાયર કાર્યવાહી કે અપ્રમાણિત તરફથી અથવા કાર્યક્રમો ઉપયોગ પર પ્રતિબંધ રહેશે.

બિન અનુકૂળ ઉત્પાદન 13 નિયંત્રણ

બિન-ઉત્પાદનોને અનુકૂળ અજાણતા ઉપયોગ ન કરવો જોઇએ. જટિલ ભૂલો કિસ્સામાં ઝડપી ફેરફારો સંભાળવા માટે એક પ્રક્રિયા બનાવાયેલ હોવી જોઈએ.

– નિયંત્રિત વસ્તુઓ છે કે જે માન્ય થયેલ ભૂલો સમાવી ઓળખ સ્પષ્ટ
– પદ્ધતિ બોલ પર ગ્રાહક સ્વીકાર બહાર
– ઝડપી ફેરફારો કિસ્સામાં, તે દસ્તાવેજ હોવું જ જોઈએ
– તેથી ફેરફાર વસ્તુઓ સમીક્ષા સોફ્ટવેર બાકીના તરીકે જ સ્થિતિ મૂલ્યાંકિત કરવામાં આવશે.

14 સુધારાત્મક અને નિવારક કાર્યવાહી

– અહેવાલો છે કે જરૂરિયાતો માટે અનુકૂળ નથી અસરકારક નિયંત્રણ
– વિકાસ પ્રક્રિયામાં ટૂંકા comings સૂચવે અહેવાલો અસરકારક નિયંત્રણ
– સક્રિય સંગ્રહ અને ઉત્પાદન અને પ્રક્રિયા બિન-સિદ્ધાંતો અને નિવારક ક્રિયાઓ વિશે ઉપલબ્ધ માહિતી વિશ્લેષણ.

વિકાસ પ્રક્રિયા સુધારાઓ વાહન જોઈએ આવી સમસ્યાઓ વિશે માહિતી.

અનુરૂપ ન હોવું
– ગ્રાહક ફરિયાદ યોગ્ય રીતે હાથ ધરવામાં આવી છે
– ઉણપ જોવા મળે છે આવી છે પરંતુ સુધારાઈ
– કોઈ પ્રક્રિયા ખાતરી કરવા માટે સમસ્યાઓ વિશ્લેષણ અને તેના પર અમલ કરવામાં આવે છે કે
– જાણ નિયમો અને પ્રક્રિયાઓ અરજી સાથે મુશ્કેલીઓ માટે આ બોલ પર કોઈ પ્રક્રિયા.

15 હેન્ડલિંગ, સંગ્રહ, પેકેજીંગ, જાળવણી અને ડ લવર

પ્રમોટર્સ, ડિસ્ક અથવા અન્ય માધ્યમ પર નકલ સોફ્ટવેર લાગુ પડે છે.
મીડિયા લેબલ અને યોગ્ય રીતે પેકેજ આવશે. ડેટા બેકઅપ આવશે. ત્યાં પણ અજાણતાં નુકસાન સામે રક્ષણ પૂરું પાડે ક્ષમતા હોવી જોઈએ.

ગુણવત્તા રેકોર્ડ 16 નિયંત્રણ

ગુણવત્તા દસ્તાવેજો દર્શાવે છે કે જે ક્રિયાઓ ખાતરી અથવા ગુણવત્તા ચકાસવા માટે લેવામાં આવ્યા છે. પ્રમાણભૂત ગુણવત્તા રેકોર્ડ સંભાળવા માટે એક પ્રક્રિયા હોઇ કે જરૂરી છે. રેકોર્ડ યોગ્ય રીતે સંગ્રહાયેલ હોવી જોઈએ જેથી તેઓ સરળતાથી સુલભ છે.
– ગુણવત્તા રેકોર્ડ રીટેન્શન માટે આ બોલ પર કોઈ નિયમો
– સમીક્ષા રેકોર્ડ રાખવામાં આવે છે
– ટેસ્ટ રેકોર્ડ રાખવામાં આવે છે
– ગુણવત્તા રેકોર્ડ રાખવા વ્યાખ્યાયિત સમય નથી

17 આંતરિક ગુણવત્તાની ઓડિટમાં

એક સ્વતંત્ર અસ્તિત્વ છે જે નિયમિત તમામ કામગીરી તે ઉત્પાદન અથવા સેવાની ગુણવત્તા પર અસર કરી શકે ઓડિટમાં પ્રયત્ન કરીશું. આ કંપની મેનેજમેન્ટ વતી હાથ ધરવામાં આવે છે. ત્યાં એક ઓડિટ યોજના હોવી જોઈએ.

અનુરૂપ ન હોવું
– કોઈ ઓડિટ યોજના
– ઓડિટ તારીખ સુધી નથી યોજના

18 તાલીમ

કંપની કે સ્ટાફ ખાતરી કરવી જોઈએ જરૂરી કાર્યો માટે તાલીમ આપવામાં આવે છે. માટે કાર્યવાહી:
– દરેક સ્ટાફ પદ માટે તાલીમ જરૂરિયાતો ઓળખવા
– જેમ કે તાલીમ પૂરી પાડે છે
– બધા સ્ટાફ સભ્યો તાલીમ રેકોર્ડ રાખે છે.

તાલીમ દસ્તાવેજીકરણ અને પૂરતી પ્રયત્ન કરીશું. પૂરતી આપણે અર્થ એ છે કે વ્યક્તિ ઊંચી પ્રમાણભૂત તેના / તેણીના વર્ક હાથ ધરવા સક્ષમ હોય છે.

અનુરૂપ ન હોવું
– આયોજન અથવા તાલીમ માટે કોઈ કાર્યવાહી
– કોઈ તાલીમ રેકોર્ડ
– તેના અથવા તેણીના કાર્ય માટે યોગ્ય તાલીમ પ્રાપ્ત નથી.

19 સેવા

પુરવઠોકર્તા સર્વિસ જો આ કરાર ઉલ્લેખ કર્યો છે માટે કાર્યવાહી દસ્તાવેજીકરણ રહેશે. સોફ્ટવેર તે ભૂલ સુધારા અને વિતરિત સોફ્ટવેર ઉન્નત્તિકરણો છે.

ફેરફારો માટે ફરિયાદો અને અરજીઓ સંભાળવા માટે કાર્યવાહી. સપ્લાયર જો તે કરાર માં ઉલ્લેખ નથી જાળવણી પૂરી પાડવા માટે જવાબદાર નથી. જૂના સોફ્ટવેર માટે જાળવણી કાર્યવાહી થવી જોઈએ.

અનુરૂપ ન હોવું
– એક કરાર વગર એક ગ્રાહક માટે જાળવણી કામ
– જૂના ઉત્પાદન જાળવણી માટે ચોક્કસ પદ્ધતિ દસ્તાવેજીકૃત થયેલ નથી
– જાળવણી પછી પરીક્ષણ માટે આ બોલ પર કોઈ પ્રક્રિયા.

20 આંકડાકીય તકનીકને

ત્યાં સંગ્રહ અને વિવિધ તબક્કાઓ મળી ભૂલો સંખ્યા વિશે માહિતી વિશ્લેષણ પ્રયત્ન કરીશું. મુદતો અને લક્ષ્યો મળવા અક્ષમતા વિશે માહિતી વિશ્લેષણ કરી જોઈએ.

“————————————————– ————————————————– ————————————————–

tradiksyon sipò:
————————————————– ————————————————– ————————————————–
ISO 9001 Ven Kalite Eleman

Y ap fè yon gade dwe pran nan kondisyon yo ki soti nan opinyon an nan konpayi devlope lojisyèl. ISO 9001 estanda te gen entansyon pou endistri a manifakti. Kondisyon pou yo yo entèprete pou devlopman lojisyèl an akò avèk ISO 9000-3 ak TickIT.

Genyen 20 eleman prensipal la. Chak konsèp byen li te ye nan kominote a jesyon bon jan kalite.

1. Jesyon Responsablite

1.1 Kalite politik

estanda a mande jesyon nan founisè ba ou yon politik bon jan kalite, kote li di konpayi an va pwodwi bon jan kalite pwodwi yo.

Politik la bon jan kalite dwe:
– Defini managementâ € ™ a nan angajman nan bon jan kalite
– Defini objektif companyâ € ™ an la konsènan bon jan kalite, se sa ki, ki sa jesyon vle di pa bon jan kalite
– Fè ki gen rapò ak customerâ € ™ a nan bezwen
– Dwe konprann nan òganizasyon an
– Kapab aplike

Ki pa Peye-konformite

– Deklarasyon twò vag oswa politik se pa sa konprann pa anplwaye
– Politik Kalite se pa sa aplike.

E.g. nan politik Kalite

â € œWe reyalize bon jan kalite a anplwaye motive ak kalifye, pwosedi travay defini, ak revizyon entansif ak tès activities.â €

1.2 Òganizasyon

estanda a mande dokiman de responsabilite, otorite ak entèraksyon nan tout pèsonèl ki afekte bon jan kalite. Sa vle di ke si yon moun gen yon responsablite, y’a fòmèlman plase nan manadjè a ki apwopriye yo. Moun nan ta dwe gen otorite pou li kapab akonpli responsablite a.

Dapre ISO, responsablite vle di:

â € OEA devwa yo aji sou pwòp akò oneâ € ™ s lè yon bagay gen yo dwe fè san ke yo te toldâ €.

Ki pa Peye-konfòmeman

– Ki deja egziste nan yon responsablite ki pa ka rive vre.


– Pwojè-liy
– Pwojè-kliyan
– Òganizasyon Pwojè-antretyen
– Devlopman Software devlopman-pyès ki nan konpitè
– Antretyen òganizasyon-èd biwo
– Komèsyal-devlopman

Resous ki egzije pou founisè a:
– Idantifye egzijans yo fè pou resous
– Bay manm pèsonèl ki fòme.

Jesyon reprezantan mande pou randevou nan reprezantan manadjè ki gen otorite ak responsablite a:
– Asire w ke konpayi an satisfè kondisyon yo ki nan ISO 9001
– Rapòte pèfòmans nan nan sistèm nan bon jan kalite nan jesyon konpayi

1.3 Jesyon Revizyon

manadjè Kalite ta dwe detanzantan prezante rezilta yo nan
– Kalite verifikasyon
– Estatistik nan plent bon jan kalite
– Albòm nan aksyon korektif

Rezilta yo ta dwe prezante nan yon reyinyon jesyon anrejistre ak nòt sou ki te asiste, sa ki te prezante ak sa desizyon yo te pran yo e te fè.

2. Kalite Sistèm

sistèm Kalite â € “”â € estrikti œThe òganizasyonèl, responsablite, pwosedi, pwosesis ak resous pou mete ann aplikasyon bon jan kalite management.â €

Pwosedi, règ, desizyon va dwe mete nan ekri. Si ou gen yon règ oswa pwosedi ki pa egzije sa ISO 9001, estanda sa a toujou mande pou ke li se ekri.

Yon bon jan kalite manyèl dwe genyen referans ak dokiman nan sistèm lan bon jan kalite.

Ki pa Peye-konfòmeman

– Yon kontwòl kontab se yon echantiyon, Se poutèt sa si nan yon echantiyon, gen minè ki pa konformite, epi yo ap fiks, li ka toujou yon moun ki pa konfòmeman paske oditè a ka sispèk ke gen anpil plis minè ki pa konformite.
– Ki deja egziste ekri pwosedi yo pa respekte a.

3. Kontra Revizyon

Chèk yo founisè anvan kontra siyen ke òganizasyon an kapab fè ki sa yo mande nan kontra a.

Kesyon ki ta dwe mande yo enkli:
– Èske kondisyon yo ki dokimante ak konprann?
– Èske kritè aksepte enkli?
– Eske kondisyon diferan soti nan pèman an te rezoud?
– Èske founisè a reinyon resous ase pou kontra a?
– Èske founisè a reinyon konpetans ki nesesè pou kontra a?
– Èske yo kapab travay la fini nan tan?

Estanda a mande pou yo yon pwosedi dokimante ak revize enkli ladan li. Founisè a ta dwe idantifye ki jan amannman kontra ak manyen nan kondisyon spesifikasyon ant kliyan ak founisè dwe defini.

4. Design Kontwòl

4.1. Jeneral
ISO mande pou ke ou fè plan anvan yo fè ak presize anvan desine.

4.2. Design ak Devlopman Planifikasyon

plan Design ta dwe gen ladan:
– Definisyon nan metodoloji yo dwe itilize nan devlopman nan pwodwi
– Orè Tan, responsablite, devwa travay ak kontwòl pwogrè
– Yo p ap Faz pwojè ap divize. Sa a gen ladan D ‘, pwodiksyon ak verifikasyon nan pwodiksyon.
– Deskripsyon nan metòd ak zouti yo dwe itilize

plan Kalite ta dwe gen ladan:
– Kalite objektif
– Kritè pou akseptasyon
– Idantifikasyon nan planifikasyon, validation ak verifikasyon.
– Responsablite pou aktivite bon jan kalite.

Si yon konpayi vle jwenn ISO kalifikasyon plan yo dwe gen pou fèt nan tout pwojè, depi ISO sètifikasyon se pou konpayi an antye epi yo pa pou pwojè espesifik.

4.3 entèrfas òganizasyon ak teknik

Si gen gwoup-travay, interfaces ki genyen ant yo ta dwe idantifye, dokimante epi ki transmèt bay moun ki bezwen enfòmasyon an. va dokiman an dwe revize regilyèman.

4.4 Design Antre

Kondisyon espesifikasyon gen D ‘a konsepsyon nan devlopman lojisyèl. Sa ka fè pa achtè a oswa prepare pa founisè a lè l sèvi avèk lwa ak règleman. Yon lòt opinyon konsepsyon an gen ladan kodaj konsepsyon ki te itilize kòm D ‘kodaj.

Estanda a vle asire ke pwodwi a travay nan chak etap satisfè kondisyon ki.

Nan devlopman lojisyèl, chanjman kondisyon yo komen se konsa dwe yon pwosedi pou manyen nouvo ak chanje kondisyon soti nan achtè a kreye.

4.5 Design Sòti

Design Sòti: dokiman an konsepsyon ak kòd la sous. ISO mande pou dokiman konsepsyon ak kodaj dwe revize anvan liberasyon.

Yon pwosedi pou akseptasyon nan pwodiksyon an konsepsyon ak kritè yo aksepte yo ta dwe kreye.

4.6 Design Revizyon

fonksyon Pwojè tankou kodaj ak tès pral prezante nan revizyon an. Yon metòd komen pou asire revize yo lis.

4.7 Design Verifikasyon

Sa a konsiste de revize, tès modil ak tès entegrasyon.

4.8 Design Validasyon

Final tès sistèm, nan pwodwi a lojisyèl konplè ansanm ak revize nan dokiman itilizatè. Ta dwe dwe planifye ak dokimante validation. tès beta se nan konfòmeman ak ISO osi lontan ke se tès la beta kouvri pa yon akò klè ant founisè ak kliyan beta-tès yo.

4.9 Design Chanjman

ISO 9001 egzije pou apre yo fin lage nan dokiman konsepsyon oswa sous, tout chanjman va ale nan yon pwosesis fòmèl kote chanjman yo dokimante, revize ak apwouve anvan aplikasyon.

chanjman San kontwòl nan dokiman konplèks teknik oswa pwogram gen anpil danje ak jan sa yo estanda nan pa pèmèt li.
5. Dokiman ak Done Kontwòl

Enfòmasyon ki kontwole devlopman / antretyen an nan lojisyèl. estanda a mande pou moun ki bezwen kèk dokiman / done va gen aksè a li. Chanjman nan dokiman ak done yo dwe kontwole.

5.1 Jeneral

dokiman Eksteryè ak done yo dwe estoke. Li kapab ki estoke sou nenpòt ki fòm (rèd kopi, elektwonik medya).

5.2 Dokiman ak Done Apwobasyon ak Nimewo

Anvan pwoblèm dokiman ak done yo dwe revize ak apwouve anvan chak pwoblèm. Yon lis dokiman ki youn nan yo va chèche konnen vèsyon aktyèl la nan yon dokiman. dokiman valab oswa demode yo ta dwe retire oswa make aklè.

5.3 Dokiman ak Done Chanjman

va moun / s nan an chaj nan revizyon ak apwobasyon pwosesis la ap espesifye.

6. Achte

Nan ka a nan tretan, se ou ki toujou responsab. Dir si ou aplike pou yon kontra ak tretans travay la, ISO estanda se toujou anba responsablite w ak ISO kondisyon pa gen yo dwe enpoze sou tretan an.

6.1 Jeneral

Si MANPOWER se achte, estanda sa a egzije pou ou yo swiv yon pwosedi ke ou jwenn moun yo dwa. Foul moun yo yo pral kontwole pa founisè epi yo pa tretan.
Pou asire ke lojisyèl achte konfòm nan kondisyon:
– Kondisyon Kontra sou pwosedi yo lòt kontraktè
– Odit nan sistèm nan bon jan kalite tretan
– Tcheke tretan sot pase pèfòmans
– Sondaj tretan an pandan kontra
– Temwen revizyon ak tès
– Egzamen ak revizyon pwodwi nan tretan.

6.2 Evalyasyon nan lòt kontraktè

Moun ki gen otorite ki nesesè yo ak konpetans pral jije chak tretan ak deside si yo sèvi ak. desizyon yo pral dokimante.

founisè a dwe deside ki sa kontwòl sou tretan li pral gen. Estanda a pa mansyone konbyen lajan kontwòl ou ta dwe gen. Li jis mansyone ke yo ta dwe yon desizyon dwe fèt pa lè l sèvi avèk reyalite.

Yon ka espesyal se moun ki lè lojisyèl se achte nan an detay. Nan ka sa tretan a se òganizasyon ki gen ki se achte nan fèt, pa pwomotè a orijinal la nan lojisyèl an.

Si achte se fè nan ISO Yo Vann an Detay 9001 mande ke ou defini nan ki nivo ou mete kondisyon sou magazen an kontwole founisè li yo.

6.3 Achte Done

Kondisyon sou pwosesis devlopman pral dokimante nan kontra a ansanm ak egzijans founisè yo apwouve rezilta travay ak pwosedi yo.

6.4 Verifikasyon achte pwodwi

Dokimantasyon nan desizyon sou verifikasyon an nan chak achte zouti devlopman oswa pwodwi enkli ladan li.
Ki pa Peye-konfòmeman

– Pa gen lis nan Swèd apwouve
– Apwopriye kontwòl nan tretan
– Pa gen verifikasyon dokiman nan achte atik
– Apwopriye kontra ak tretan.

7 Kontwòl nan Kliyan-apwovizyone pwodwi

Founisè a ap gen pwosedi pou verifikasyon, depo ak antretyen nan kliyan apwovizyone lojisyèl. Sepandan, bon jan kalite a se responsablite a nan lojisyèl an.

Yon ki pa konfòmeman k ap pase akòz responsablite klè nan responsablite ant kliyan ak founisè.

8 Pwodwi Specification ak traçabilité

Founisè a lojisyèl ta dwe kenbe kontwòl sou:
– Sou ki sa ki vin anvan dokiman ak bay li se ki baze
– Sou ki spesifikasyon li se ki baze
– Ki sa ki koreksyon ak amannman yo te enkli nan ki pwogram sous
– Kisa ki te pase nan chak rapò pwoblèm
– Soti nan ki sous te yon modil espesifik pwodwi.

Kontwòl 9 Pwosesis

Dokimante pwosedi pou pwosesis la replikasyon nan operasyon an ak pwosedi pou manyen nan mèt promÄ € ™ s / bibliyotèk yo. Pou asire ke se kòrèk vèrsyonin itilize.

Ki pa Peye-konfòmeman
– Pa gen pwosedi dokimante pou replikasyon
– Move manyen nan mèt promÄ € ™ s oswa diskèt.

10 Enspeksyon ak Tès

pwosedi Ekri pou enspeksyon an ak tès yo dwe fè an koneksyon avèk replikasyon.

Ki pa Peye-konfòmeman
– Fonksyon nan otomatikman tcheke promÄ € ™ s pa te enspekte
– Pa gen dokimante pwosedi pou fè tès promÄ € ™ s.

11 Kontwòl nan Enspeksyon, Mezire ak ekipman Tès

Founisè a ta dwe chwazi ekipman an mezire apwopriye epi swiv yon pwosedi dokimante pou kontwòl nan ekipman yo. Chak vèsyon lojisyèl nouvo yo ta dwe fè tès pou sifizans.

12 Enspeksyon ak Tès Ki dènye nouvèl

Espesifikasyon ak pwogram ta dwe verifye nan revi ak tès. Founisè a ap gen pwosedi ki entèdi pou sèvi ak espesifikasyon verifye oswa pwogram.

13 Kontwòl nan ki pa Peye-konfòme Pwodwi

pwodwi ki pa konfòme pa ta dwe itilize san. Yon pwosedi pou manyen modifikasyon rapid nan ka ta gen erè kritik yo ta dwe kreye.

– Klè idantifikasyon nan atik kontwole ki gen erè uncorrected
– Metòd nan provoke aksepte kliyan sou livrezon
– Nan ka ta gen modifikasyon rapid, li dwe dokimante
– Revize se konsa modifye atik yo pral elve nan sitiyasyon menm jan ak rès nan lojisyèl.

14 korektif ak Prevantif Aksyon

– Efektif manyen nan rapò ke pa konfòme yo ak kondisyon
– Efektif manyen nan rapò ki endike kout-retou nan pwosesis la devlopman
– Aktif koleksyon ak analiz de enfòmasyon ki disponib sou pwodwi ak pwosesis ki pa konfòmeman ak aksyon prevansyon.

Enfòmasyon sou pwoblèm rankontre ta dwe kondwi amelyorasyon nan pwosesis la devlopman.

Ki pa Peye-konfòmeman
– Plent Kliyan pa te byen okipe
– Defisyans te jwenn men se pa korije
– Pa gen pwosedi asire ke pwoblèm yo analize ak aji sou
– Pa gen pwosedi pou rapòte difikilte ak aplike règ ak pwosedi yo.

15 Aksyon, Depo, Emballage, Prezèvasyon ak akouchman

Aplike nan lojisyèl repwodui sou PROM, ki gen kapasite oswa lòt mwayen.
Media va pou yo make ak pake kòrèkteman. Done pral apiye moute. Gen ta dwe tou ap kapasite nan bay pwoteksyon kont domaj envolontè.

16 Kontwòl nan Kalite Albòm

dokiman Kalite montre ki aksyon ki te pran asire oswa tcheke bon jan kalite. estanda a mande pou gen yon pwosedi pou manyen nan dosye bon jan kalite. Dosye yo ta dwe estoke nan yon fason ki apwopriye pou yo yo se fasil pou jwenn.
Ki pa Peye-konformite:
– Pa gen règ pou retansyon nan dosye bon jan kalite
– Dosye Revizyon pa yo kenbe
– Dosye Tès yo pa kenbe
– Peryòd pou kenbe dosye bon jan kalite se pa sa defini

17 Entèn Kalite Verifikasyon

Ta dwe gen yon antite endepandan ki regilyèman verifikasyon tout operasyon ki kapab afekte pwodui oswa sèvis bon jan kalite. Sa yo yo fèt sou non nan jesyon konpayi. Ta dwe gen yon plan kontwòl kontab.

Ki pa Peye-konfòmeman
– Pa gen plan kontwòl kontab
– Plan Odit pa jiska dat

18 Fòmasyon

se konpayi yo ta dwe asire ke anplwaye ki resevwa fòmasyon pou travay yo mande yo. Yon pwosedi a:
– Idantifye bezwen fòmasyon pou chak pozisyon anplwaye
– Bay estaj fòmasyon sa yo
– Kenbe dosye sou fòmasyon an nan tout manm anplwaye yo.

Fòmasyon ta dwe dokimante ak ase. Pa ase nou vle di ke moun nan gen kapasite pou fè / travay li li nan yon estanda ki wo ase.

Ki pa Peye-konfòmeman
– Pa gen pwosedi pou planifikasyon oswa fòmasyon
– Pa gen dosye fòmasyon
– Pa te resevwa fòmasyon apwopriye pou travay li.

19 Servicing

va Supplier te dokimante pwosedi pou sèvis si sa a se mansyone nan kontra a. Nan lojisyèl li se sou koreksyon erè ak amelyorasyon yo lage lojisyèl.

Pwosedi pou manyen plent ak demann pou modifikasyon. Founisè a pa oblije bay antretyen si li pa mansyone nan kontra. pwosedi Antretyen pou lojisyèl fin vye granmoun ta dwe fè fè yo.

Ki pa Peye-konfòmeman
– Antretyen travay pou yon kliyan san yon kontra
– Metòd espesifik pou antretyen nan pwodwi fin vye granmoun se pa sa dokimante
– Pa gen pwosedi pou fè tès apre antretyen.

20 Teknik estatistik

Ta dwe gen koleksyon ak analiz de done sou kantite erè yo te jwenn nan faz yo diferan. ta dwe analize Enfòmasyon sou enkapasite al kontre dat limit ak jalons.

“————————————————– ————————————————– ————————————————–

Support translation:
————————————————– ————————————————– ————————————————–
ISO 9001 Ashirin Quality Abubuwa

A look za a dauka a bukatun daga mahangar kamfanoni masu tasowa software. ISO 9001 misali aka yi nufi ga masana’antu. The bukatun da ake fassara for software ci gaba a daidai da ISO 9000-3 da TickIT.

Akwai 20 main abubuwa. Kowane ra’ayi ne da aka sani a cikin quality management al’umma.

1. Management Nauyi

1.1 Quality siyasa

A misali na bukatar maroki management bayar da quality manufofin, inda ya ce kamfanin zai samar da quality kayayyakin.

The quality manufofin za:
– Ƙayyade managementâ € ™ s sadaukar da quality
– Ƙayyade companyâ € ™ s manufofin game quality, wato, abin da management nufin da quality
– Be dace da customerâ € ™ s bukatun
– A fahimci a cikin kungiyar
– A aiwatar


– Sirri kuma m, ko manufofin da aka ba su gane da ma’aikatan
– Quality siyasa ba aiwatar.

Msl na Quality siyasa

â € œWe cimma quality ta motsa da gwani ma’aikatan, a tsare aikin hanyoyin, kuma m review da kuma gwajin activities.â €

1.2 Organization

A misali na bukatar takardun da alhakin, iko da interrelation dukan ma’aikata shafi quality. Wannan yana nufin cewa idan mutum yana da alhakin, shi za a ƙa’ida sanya ta dace sarrafa. Mutumin da ya kamata suna da ikon cika da alhakin.

A cewar ISO, alhakin yana nufin:

â € œa wajibi a yi aiki a kan oneâ € ™ s kansa bisa lokacin da wani abu ya da za a yi, ba tare da kasancewa toldâ €.


– Data kasance wani alhaki da ba a iya cika.


– Project-line
– Project-abokin ciniki
– Project-tabbatarwa kungiyar
– Software ci-hardware ci gaba
– Maintenance kungiyar taimakon tebur
– Sales-raya

Resources bukatar cewa maroki:
– Gane da bukatun ga albarkatun
– Sanya horar ma’aikata.

Management wakilin bukatar nada kocin wakilin da iko da alhakin zuwa:
– Tabbatar da cewa kamfanin ya cika bukatun a ISO 9001
– Rahoto wasan kwaikwayon da ingancin tsarin kamfanin management

1.3 Management Review

Quality sarrafa kamata lokaci-lokaci gabatar da sakamakon
– Quality audits
– Statistics na quality gunaguni
– Records na daidaituwa mataki

Sakamakon ya kamata a gabatar a rubuce management gamuwa da bayanin kula a kan wanda ya halarci, da abin da aka gabatar, da abin da yanke shawara da aka dauka, kuma ya sanya.

2. Quality System

Quality tsarin â € “”â € œthe kungiya tsarin, nauyi, hanyoyin, tafiyar matakai da kuma albarkatun da aiwatar quality management.â €

Hanyoyin, dokoki, yanke shawara za a saka a cikin rubuce-rubuce. Idan kana da wani mulki ko hanya da aka ba da ake bukata da ISO 9001, da misali har yanzu na bukatar a rubuce yake cewa.

A quality manual za dauke da tunani da kuma abubuwan da aka rubuta da ingancin tsarin.


– An duba ne a sample, sabili da haka idan a wani samfurin, akwai qananan ba conformances, kuma suna gyarawa, zai iya har yanzu ya kasance maras conformance saboda binciken iya zargin cewa akwai mutane da yawa more qananan ba conformances.
– Data kasance rubuta hanyoyin ba su da bin.

3. kwangila Review

The maroki cak da yarjejeniyar kwangila da cewa kungiyar su iya yi da abin da ake bukata da kwangila.

Tambayoyi da ya kamata a tambayi sun hada da:
– Shin da bukatun rubuce da kuma gane?
– Shin yarda sharudda hada?
– Shin da bukatun iri dabam-dabam daga m aka warware?
– Za a iya maroki tãra isa albarkatun domin kwangila?
– Za a iya maroki tãra da iyawa da ake bukata domin kwangila?
– Za a iya aiki a kammala a lokacin?

A misali na bukatar cewa a rubuce hanya da reviews a hada da. The maroki ya kamata gane yadda kwangila gyara da kuma tarbiyyar da bukatun jaddadawa tsakanin abokin ciniki da kuma maroki a iya bayyana.

4. Design Control

4.1. Janar
ISO bukatar cewa ka shirya da yin da kuma saka da zayyana.

4.2. Design and Development Planning

Design shirin kamata dauke:
– Definition na hanya da za a yi amfani a ci gaba da samfurin
– Time jadawalai, nauyi, aikin ayyukan da ci gaba da iko
– Nan shiri za a raba. Wannan ya hada da labari, fitarwa da kuma tabbaci daga fitarwa.
– Description of hanyoyi da kayayyakin aiki, to za a yi amfani

Quality shirin kamata dauke:
– Quality hari
– Sharudda ga karbar
– Identification na shiryawa, Ingancin da tabbaci.
– Nauyi for quality ayyukan.

Idan wani kamfani yana so ya sami ISO cancantar da tsare-tsaren dole ne a gudanar a cikin dukan ayyukan, tun ISO takardar shaida ne ga dukan kamfanin da ba ga takamaiman ayyuka.

4.3 Kungiya kuma Technical musaya

Idan akwai tara-aiki, da musaya a tsakanin su ya kamata a gano, rubuce da kuma daukar kwayar cutar ga waɗanda bukatan da bayanai. The takardun za a sake nazari a kai a kai.

4.4 Design Input

Bukatun bayani dalla-dalla dauke da zane labari a software ci gaba. Wannan za a iya yi da mai saya ko ta shirya da maroki amfani da dokokin. Wani zane labari hada zane coding wanda aka yi amfani a matsayin labari to coding.

A misali yana so ya tabbatar da cewa aiki samfur kowane mataki hadu da bukatun.

A software ci gaba, da ake bukata da canje-canje ne na kowa haka a hanya domin tanadin sabon da sauya bukatun daga saya a halitta.

4.5 Design Output

Design Output: zane takardun da source code. ISO bukatar zane takardun da coding a duba kafin release.

A hanya domin yarda da zane fitarwa da sharudda na yarda ya kamata a halitta.

4.6 Design Review

Project ayyuka kamar coding da gwaji za a gabatar a review. A na kowa hanya domin tabbatar reviews ne checklists.

4.7 Design Verification

Wannan kunshi reviews, module gwaji da kuma hadewa gwaji.

4.8 Design Ingancin

Final tsarin gwajin, na gama software samfurin tare da bita na mai amfani da takardun. Akwai ya kamata a shirya da kuma rubuce Ingancin. Beta gwaji ne a conformance da ISO muddin beta gwaji an rufe ta a bayyana yarjejeniyar tsakanin maroki da beta-gwaji abokin ciniki.

4.9 Design Canje-canje

ISO 9001 bukatar cewa bayan saki zane takardun ko source, duk da canje-canje zai tafi, ta hanyar wani m tsari inda canje-canje suna rubuce, duba da kuma yarda da aiwatar.

Uncontrolled canje-canje ga hadaddun fasaha takardun ko shirye-shirye ne musamman m da kuma irin wannan misali ba da damar da shi.
5. Document da Data Control

Bayani da iko da ci gaban / kiyaye software. A misali na bukatar cewa wadanda suka bukatar wasu daftarin aiki / data su da damar yin amfani da shi. Canje-canje ga takardun da data za a sarrafawa.

5.1 Gaba

External takardun da data za a adana. Ba za a iya adana a kan duk wani nau’i (m kwafin, kafofin watsa labaru).

5.2 Document da Data amincewa da Issue

Kafin fitowar takardun da data za a sake nazari da kuma amince da kowane batu. A daftarin aiki list a cikin abin da wanda za a gano halin yanzu version of wani daftarin aiki. Mara inganci ko wanda aka rabu amfani da takardun da ya kamata a cire ko fili alama.

5.3 Document da Data Canje-canje

Mutumin da / s lura da review da yarda tsari za a kayyade.

6. sayen

A cikin hali na subcontractor, kai ne har yanzu m. Ina nufin idan ka nemi wata kwangila da subcontract aikin, ISO matsayin shi ne har yanzu a karkashin your nauyin da ISO bukatun ba su da za a sanya a kan subcontractor.

6.1 Gaba

Idan manpower da aka saya, da misali na bukatar ka bi wata hanya da ka samu dama mutane. Mutane za su iya sarrafawa da maroki, kuma ba subcontractor.
Don tabbatar da cewa sayi software dace to bukatun:
– Kwangila bukatun kan subcontractors hanyoyin
– Duba da subcontractor quality tsarin
– Duba subcontractor da yi
– Duba da subcontractor lokacin kwangila
– Shaida review da gwaji
– Test kuma review samfurin subcontractor.

6.2 Evaluation na subcontractors

Mutum da ya cancanta iko da iyawa yi hukunci kowane subcontractor da kuma yanke shawara ko don amfani. The yanke shawara za a rubuce.

The maroki za hukunci da abin da iko a kan subcontractor shi zai yi. A misali ba ya ambaci nawa iko ya kamata ka yi. Shi kawai ambaci cewa a yanke shawara ya kamata a yi ta amfani da facts.

A musamman harka ne a lokacin da software da aka saya, ta hanyar kiri. A wannan yanayin subcontractor ne kungiyar da abin da sayan aka gudanar, ba ainihin developer da software.

Idan sayen ne yake aikata ta kiri ISO 9001 bukatar ka ayyana abin da har ka saka bukatun kan retailer don sarrafa ta maroki.

6.3 sayen Data

Bukatun a ci gaba tsari za a rubuce a cikin kwangila tare da maroki bukatun amince aikin sakamakon da hanyoyin.

6.4 Verification na sayi samfur

Takardun na yanke shawara game da tabbaci kowane sayi ci kayan aiki ko hada samfurin.

– Ba jerin amince kaya
– Bai dace iko da subcontractor
– Ba daftarin aiki tabbaci na sayi abubuwa
– Bai dace kwangila tare subcontractor.

7 Control na Abokin ciniki-kawota Product

The maroki sunã da hanyoyin da tabbaci, ajiya da kuma goyon baya na abokin ciniki kawota software. Duk da haka, da ingancin shi ne nauyin da software.

A wadanda ba conformance faru saboda m nauyin alhakin tsakanin abokin ciniki da kuma maroki.

8 Product Musammantawa da Traceability

The software maroki ya kamata ci gaba da iko a kan:
– A kan abin da gabanin daftarin aiki kuma ya kunshi al’amuranda shi dogara ne
– A wace jaddadawa shi ne tushen
– Abin da gyare-gyare da kuma gyara da aka hada da shirye-shirye source
– Abin da ya faru da kowane matsala rahoton
– Daga abin da source aka takamaiman module generated.

9 Tsari Control

Rubuce hanya don kwafi tsari a cikin aiki da kuma hanya domin handling na master PROMâ € ™ s / dakunan karatu. Don tabbatar da cewa daidai versioning da ake amfani.

– Ba rubuce hanya don kwafi
– Rashin handling na master PROMâ € ™ s ko diskettes.

10 dubawa da Testing

Written hanyoyin domin dubawa da gwaji da za a yi dangane da kwafi.

– Aiki na atomatik dubawa PROMâ € ™ s ba a binciki
– Ba rubuce hanya don gwada PROMâ € ™ s.

11 Control na dubawa, Aunawa da Test Boats

The maroki ya kamata zaži da ya dace ma’auni kayan aiki da kuma bi a rubuce hanya domin iko da kayan aiki. Kowane sabon software version ya kamata a gwada wa isar.

12 dubawa da Test Status

Bayani dalla-dalla da kuma shirye-shirye ya kamata tabbatar ta hanyar reviews da gwaji. The maroki sunã da hanyoyin da hana yin amfani da tantance ba bayani dalla-dalla ko shirye-shirye.

13 Control na Non-conforming Product

Non-conforming kayayyakin ya kamata ba a yi amfani da niyya. A hanya domin tanadin m gyare-gyare a cikin akwati na m kurakurai da ya kamata a halitta.

– Sunny ganewa na sarrafawa abubuwa dake dauke da uncorrected kurakurai
– Hanyar to jawo abokin ciniki yarda a gare delivery
– A yanayin da sauri gyare-gyare, shi dole ne a rubuce
– Yin bita haka modified abubuwa za a dagagge zuwa wannan matsayi a matsayin sauran software.

14 daidaituwa da M Action

– Inganci handling rahotanni da bai dace ba to bukatun
– Inganci handling rahotanni na nuna short-comings a ci gaba tsari
– Active tarin da kuma bincike na samuwa da bayani game da samfur da tsari ba conformance da m ayyuka.

Bayani game da matsalolin ci karo kamata fitar inganta da raya tsari.

– Abokin ciniki kuka ba a yadda ya kamata abar kulawa
– Rashi da aka samu amma ba gyara
– Babu hanya don tabbatar da cewa matsaloli da ake bincikar da amsa a kan
– Babu hanya domin bayar da rahoton matsaloli da ake ji dokoki da kuma hanyoyin.

15 Handling, Storage, Marufi, Tanadin da Bayarwa

Ya shafi software replicated kan rawa, faifai ko wasu matsakaici.
Media za a labeled da kunsasshen daidai. Data za a iya goyon baya up. Akwai rika zama da ikon samar da kariya daga yãsassa lalacewa.

16 Control na Quality Records

Quality takardun nuna abin da ayyuka da aka dauka don tabbatar da ko duba quality. A misali na bukatar cewa akwai wata hanya a gare handling na quality records. The records ya kamata a adana a cikin ta dace sabõda haka sũ mãsu sauƙi m.
– Ba sharudda riƙe quality records
– Review records ba su kiyaye
– Test records ba su kiyaye
– Period ajiye quality records ba a tsare

17 Ciki Quality Audits

Akwai ya zama wani m mahaluži cewa a kai a kai audits duk yadda ake gudanar da za su iya shafar samfurin ko sabis quality. Wadannan suna gudanar a madadin kamfanin management. Akwai ya zama wani duba shirin.

– Babu duba shirin
– Duba shirin ba har zuwa ranar

18 Training

Company ya kamata a tabbatar da cewa ma’aikata ne horar for ayyuka da ake bukata. A hanya zuwa:
– Gane horo bukatun ga kowane ma’aikatan matsayi
– Samar da irin wannan horo
– Ka records na horar da dukan ma’aikatan members.

Training ya kamata a rubuce da kuma isa. By isa muna nufin cewa mutumin da ya tabbata a iya yin ya / ta aiki zuwa high isa misali.

– Ba hanyoyin shiryawa ko horo
– Babu horo records
– Ba samu dace horo domin ko ta aiki.

19 Aikin

Maroki za yi rubuce hanyoyin Aikin idan wannan ne aka ambata a cikin kwangila. A software shi ne game da kuskure gyare-gyare da kuma kayan haɓɓaka aikinta zuwa tsĩrar software.

Hanyoyin tanadin gunaguni da kuma buƙatun for gyare-gyare. The maroki ba zamar masa dole ya samar da goyon baya idan aka ba da aka ambata a kwangila. Maintenance hanyoyin da tsohon software ya kamata a yi.

– Maintenance aiki ga wani abokin ciniki tare da wata kwangila
– Specific hanyoyin don tabbatarwa da tsohon samfurin ba rubuce
– Babu hanya ga gwaji bayan tabbatarwa.

20 ilimin kididdiga Dabarun

Akwai ya kamata tarin da kuma bincike na bayanai game da yawan kurakurai samu a cikin daban-daban bulan. Bayani game da rashin iyawa don ya tarye deadlines da turakun ya kamata a duba.

“————————————————– ————————————————– ————————————————–

Kākoʻo unuhi:
————————————————– ————————————————– ————————————————–
ISO 9001 He iwakālua nā Animal oihana mua

A e nānā nō e lawe i na koi, mai ka viewpoint o na poe ulu lako polokalamu. ISO 9001 hae i manao ia no ka manufacturing mau hana mau; Na koi ua hoohalike ana no ka lako polokalamu hooulu ana e like me ka ISO 9000-3 a me ka TickIT.

He nui 20 ka papa kuhikuhi hehee wale. Kela manaʻo mea maopopo loa ma ka kbps hooponopono kaiāulu.

1. Management kuleana

1.1 Animalʻikepili

Ka hae pono ka wale mai ana hooponopono ana, e hoopuka aku i kekahi mea e like ai pili, kahi e olelo i ka poe e paka e like ai nā huahana.

Ka mea e like ai pilikino E pili e:
– Hoakaka i ka managementâ € ™ ka hoʻokô ‘ana i kona mea e like
– Hoakaka i ka companyâ € ™ ka Pahuhopu e pili ana i quality,ʻo ia hoʻi, ka hooponopono ana o ia hoʻi, ma ka mea e like ai
– E pili ana i ka customerâ € ™ ka pono
– E hoʻomaopopo ma loko o ka hui
– E hoʻokō


– Hoakaka he vague paha pilikino E pili ka mea, aole i maopopo ia e kookoo
– Animal pilikino E pili ua i hoʻokō.

E laʻa me o ka Animal kulekele

â € œWe loaʻa ai mea e like ai ma ohohia a me ka mākaukau nā limahana, i ho’ākāka ‘hana ke kaʻina hana, a me ka intensive manual, a hoao activities.â €

1,2 o ka hui

Ka hae pono ai nā moʻolelo no ka kuleana, mana a me ka interrelation o na limahana ka hoohuoi ana e like ai. Keia ‘o ia hoʻi ka mea, ina he kanaka i ke kuleana, ka mea e Iwi ia e ka manakia kūpono. Ka mea e loaa ka mana e hooko i ke kuleana.

E like me ISO, kuleana ‘o ia hoʻi:

â € œa dute e hana i Onea € ™ ka manao iho, i ka wa i kekahi mea e hana me ka toldâ €.


– Kākoʻo o kekahi kuleana i hiki ole ke hookoia.


– Hana Hoʻolohe-laina
– Hana Hoʻolohe-Customer
– Hana Hoʻolohe-malama hui
– Nokia ulu-lako paʻa ulu
– Malama hui-kōkua päkaukau
– Sales-ulu

Resources noi aku i ka wale mai ana;
– E kuhikuhi i na koi no ka waiwai
– E hoʻomana aku hoʻomaʻamaʻa nā limahana.

Management ‘elele pono hookohu o ka manakia’ elele me ka mana a me ke kuleana i:
– Komo kēia mau mea i ka poe hoʻokōʻana i nā koi o ka ISO 9001
– Hoʻokaʻaʻike i ka hana o ka mea e like ai nenoaiu i poe hooponopono ana

1,3 Management Review

E like ai manakia e ke kamepiula haawi i ka hopena o
– Animal audits
– LIKE o kona mea e like hoopii
– Records o corrective hana

Nā hualoaʻa e imua ma ka palapala hooponopono halawai me ka memo ma luna o ka mea hele, ka mea i hōʻike mai iā ia, a me ka hoʻoholo ua laweʻia a hana.

2. Animal System

E like ai nenoaiu â € “”â € œtheʻaha hui ‘ole, kuleana, ke kaʻina hana, keʻano o ka hanaʻana a me na kumu waiwai no ka hoʻokō’ ia e like ai management.â €

Kaʻina hana, lula, e i hoʻoholo i loko o ke kākau ‘ana. Ina oe i kekahi rula a hana i ka mea i koi ‘ia ma ISO 9001, i ka hae malie koi i ka mea i palapalaia.

A e like ai Manual i loko o olua, a me nā moʻolelo o ka mea e like ai ma Hawaiʻi nei.


– An Hooia he hāpana, nolaila, ina ma ka hāpana, ma laila ua Nā hana ole-conformances, a ua hoʻoponopono lākou, he hiki nō ia i nā conformance no ka mea, o ka Luna Hooia ke hāʻupu aʻe ka mea, ua nui loa Nā hana ole-conformances.
– Kākoʻo i kākauʻia ke kaʻina hana a pau aole i hahai ma hope.

3. aelike Review

i ka wale mai ana E kaha makau i mua o hōʻailona aelike o ka hui e hiki ia oukou ke hana i ka mea a ka mea i koi ‘ia ma ka aelike.

Nīnau i e ninau puke:
– Ua loaa anei na koi o nä waihona palapala a hoomaopopo?
– Ua ae koi a komo?
– Ua olelo pu ole, mai ka opiopio hoʻonā ‘?
– E hiki anei i ka wale mai ana i alakaʻi i lawa waiwai no ka aelike?
– E hiki anei i ka wale mai ana i alakaʻi i ka mākaukau e pono ai no ka aelike?
– E hiki anei i ka hana e ana i ka manawa?

Ka hae pono i kekahi o nä waihona palapala ina hana me hōʻike manaʻo e komo pu. Ka wale mai ana e kuhikuhi i aelike hou, a me ka hoʻohanaʻana o nā koi hoakaka ma waena o Customer a wale mai ana e ho’ākāka ‘.

4. Design Na Makuahine

4,1. Nui
ISO pono ia oukou manao mamua o hana, ae hōʻike i mua o ke hoʻololi i.

4.2. Design, a me ka hoʻolālā ‘Development

Design kuka e komo;
– Definition of methodology, e lilo ia i loko o ka ulu huahana
– Time ka hoʻopaʻa ‘ana, kuleana, hana paha a me ka holomua hooponopono
– Kūlana papahana e puʻunaueʻia e. Keia nā hoʻokomo o, ia auoiaea a me ka hōʻoia i ka auaiaea.
– Description of epekema a me na mea paahana e hoohana

Animal kuka e komo;
– Animal pale
– ‘Oihana no ka mea, acceptability
– ‘Ike no ka hoʻolālā, validation a me ka hōʻoia.
– Kuleana no ka mea, e like ai hanana.

Ina he poe manao e loaa ISO makahiki paha i na mea kuka pono e mālama ‘ia i loko o nā papahana, no ka ISO palapala hoʻomaikaʻi oia no ka mea a pau lehulehu, a aole no kekahi pāhana.

4,3ʻaha hui a me ka Kōmike Interfaces

Ina he hui-hana, e hōʻike i nā Interfaces ma waena o lakou, o nä waihona palapala ae pū i hiki i ka poʻe i kiaʻi i ka ike. Ka palapala kuhikuhi, e nānā mau.

4,4 Design hoʻokomo o

Olelo hoakaka no i ka manao o nā manaʻo kōkua ma ka lako polokalamu ulu ana. Keia e hana ma ka purchaser, a hoomakaukau e ka wale mai ana me na kanawai a me na rula. Kekahi manao hoʻokomo o nā mea i manao ai coding i ka mea i hoʻohana like me ka manaʻo kōkua i coding.

Ka hae makemake e komo kēia mau mea i ka hana huina hoonui o kela a me keia anu u ua kō nā koi.

Me ka lako polokalamu? Acaeoey, koi loli, ua pono ole i ke kaʻina hana no ka lawelawe ana hou a me ka wehewehe ana oia i koi mai ka purchaser e hana.

4.5 Design ia auoiaea

Design auaiaea: ke manao nā moʻolelo a me ke kumu kivila. ISO pono ia manao palapala, a me coding e nānā i mua o kala.

A kaʻina hana no ka ae ana o ka manao, a me ia auoiaea ana hoʻohālike o ka ae e hana.

4,6 Design Review

Hana Hoʻolohe hana e like me coding a me ka ho’āʻo e imua e ma ka hōʻike. A e like me ka hana, no ka hōʻoia ‘hōʻike manaʻo, he checklists.

4.7 Design ka hōʻoia ‘

Keia ninoieo ec hōʻike manaʻo, Module ikea ai a me ka hoʻohui ‘ikea ai.

4.8 Design Validation

Hope loa nenoaiu hōʻike, no ka piha lako polokalamu huina hoonui pu me ka nānā ‘o ka mea hoʻohana i nā moʻolelo. Malaila e? Oaony a me nä waihona palapala validation. Mana ikea ai ka mea i loko o conformance me ISO e like me ka loihi e like me ka mana ho’āʻo ua uhiia e ka maopopo like ma waena wale mai ana, a mana-ho’āʻo Customer.

4,9 Design Hoʻololi

ISO 9001 Pono ia mahope aku o ka manao nā moʻolelo paha kumu, e hele i na mea hou ma ka hoʻohana kaʻina kahi loli i nä waihona palapala, nānā ‘a aponoia mua manaʻo.

Kipi hoʻololi i luna ‘palapala oaoieei-a me nā papahana he loa pilikia, a like ia me ka hae, aole ia i ae aku.
5. Document aʻIkepili Na Makuahine

Information ka mea hoʻi i ka ulu ana / mālama ‘ana i ka lako polokalamu. Ka hae pono i ka poe pono kekahi palapala / ‘ikepili e ia e nānā i ia mea. Hoʻololi i na palapala a me na aeaiiuo e lāʻau.

5.1 Nui

na palapala mawaho, a me kaʻikepili e waiho waho. He hiki ke waiho ia ma kekahi ano (ikaika kope, lolouila Media).

5.2 Document, a me Ikepili apono a me ka hoopuka

Ma mua o hilo nā palapala a me nā ikepili e nānā ‘a ua apono ia imua o kela a me keia hihia. A palapala papa inoa o ka mea hookahi e loaa mai ka he mana o ka palapala. Hana ‘ole obsolete palapala e wehe’ ia a maopopo ia.

5,3 Document a me Ka Ikepili ai i ka loli

Ka mea / s ma luna o ka hōʻike a me ka apono kaʻina e hoakaka.

6. ae kūʻaiʻia

Ma ka hihia o subcontractor, e noho malie ke kuleana. I.e. ina oe pili i ka aelike, a subcontract i ka hana, ISO mau hae, he manawa malalo iho o ko oukou kuleana, a me ISO koi loaa ole ia oukou ke e kau ma luna o ka subcontractor.

6,1 Nui

Ina Manpower ua kuai, o ka hae koi ia oukou e hahai i ka hana ana ia oukou e na kanaka pono. Na kanaka e, e hoi malalo o ko wale mai ana, a aole subcontractor.
E komo kēia mau mea kuai lako polokalamu ke malama i ka pono;
– Aelike olelo ma ka subcontractors kaʻina hana
– Hooia o ke subcontractor e like ai System
– Check subcontractor i hala hana
– Ana i ka subcontractor i aelike
– Hoike manual a me ka ho’āʻo
– Hoao, a me ka loiloi ‘ia huahana o ka subcontractor.

6,2 ka loiloi ‘o Subcontractors

Kanaka, me na mana a me ka mākaukau, e hookolokolo kela subcontractor, ae hooholo ina paha e hoʻohana. Nā manaʻo hoʻoholo, e nä waihona palapala.

Ka wale mai ana e hoʻoholo i ka mana hoʻomalu ma luna o subcontractor ia mea, e loaa. Ka hae, aole ia e hōʻike i ka nui o ka mana hoʻomalu ma oukou e loaa. It pololei Shoes i ka hoʻoholo e hana ma ka hoʻohana ‘ana i nā kūʻiʻo pū.

A kūikawā hihia oia ka wa lako polokalamu, ua kuai ma kalepa. Ma keia hihia subcontractor ka hui, me ka mea a ke kuai me ka mākaʻi, aole ka mua nā mea haku polokalamu o ka lako polokalamu.

Ina ke kūʻaiʻana, ua hanaʻia ma liʻiliʻio ISO 9001 koi nō ia oukou i hoakaka mai ai ka mea nui a oukou i olelo i ka retailer e ka pāʻana i kona wale mai ana.

6,3 ke kūʻaiʻanaʻIkepili

Olelo ma? Acaeoey kaʻina hana, e nä waihona palapala ma ka palapala ma ka wale mai ana koi e hoapono hana hualoaʻa a me nā kaʻina hana.

6,4 ka hōʻoia ‘o ka ho’ōla pānaʻi ai Huahana

Ka moʻolelo no ka manaʻo hoʻoholo no ka hōʻoiaʻana o kela a me keia i kuai? Acaeoey mea paahana ai komo huahana.

– No papa inoa o ka apono ia mai ana
– Kūpono ‘mana o ke subcontractor
– No palapala hōʻoia o ka ho’ōla pānaʻi ai ‘ikamu
– Kūpono ‘aelike me subcontractor.

7 Na Makuahine o Customer-lako Huahana

Ka wale mai ana e loaa kaʻina hana no ka hōʻoia, pūnaewele a me ka hoomau o ka Customer hakahaka lako polokalamu. Eia naʻe,ʻo ka mea e like ai no ke kuleana o ka lako polokalamu.

A ole-conformanceʻia ana ma muli o ka unclear kuleana o ke kuleana ma waena o Customer a wale mai ana.

8 Product hoakaka a me ka Traceability

Ka lako polokalamu wale mai ana e malama i ka mana hoʻomalu ma luna o:
– Ma ka mea mua iho palapala, ae hoopuka ia ua hoʻokumu ‘
– Ma ka hoakaka ia, ua hoʻokumu ‘
– He aha corrections a me na hoololi i komo i loko o ka papahana kumu
– He aha ka hana i kela a me keia pilikia hoike
– Mai ke kumu i kekahi māhele Module ua loaʻa.

Hihia ‘9 Na Makuahine

O nä waihona palapala kaʻina hana no ka mea, o ka replication kaʻina hana i ka hana a me ka kaʻina hana no ka lawelaweʻana i nā o ka haku PROMâ € ™ ka / hale waihona puke. E komo kēia mau mea pololei versioning mea i hoʻohana.

– No nä waihona palapala kaʻina hana no ka replication
– Kūpono ka hoʻohanaʻana o ka haku PROMâ € ™ mau a diskettes.

10 nana, a ikea ai

Kakauia kaʻina hana no ka mea, i ka nana a me ka ho’āʻo e hana e pili ana i replication.

– Launch o nōna iho o kéu PROMâ € ™ ka mea,ʻaʻole i nānā ‘
– No nä waihona palapala kaʻina hana no ka hoao PROMâ € ™ mau.

11 Na Makuahine o nana, Ana a me ka ho’āʻo pono

Ka wale mai ana e koho i ka kūpono ana ipu ae hahai i nä waihona palapala kaʻina hana no ka hooponopono ana o ka lako a pan. Kela hou lako polokalamu mana e ikea ai no ka mea.

12 nana, a me ho’āʻo kūlana

Hoakaka a me na papahana e hōʻoiaʻiʻo ma hōʻike a me ka ho’āʻo. Ka wale mai ana e loaa ke kaʻina hana i papa aku hoʻohanaʻana o unverified hoakaka a me nā papahana.

13 Na Makuahine o ka ole, a hoohalike me ko Huahana

Ole-a hoohalike me ko huahana e ole e hoʻohana unintentionally. A kaʻina hana no ka lawelawe ana ka poe ola, ka hoʻololi ‘ana i ka hihia o ka noho pilikia hewa e hana.

– Mea ‘ike o kekahi lāʻau’ ikamu i pihaʻi me uncorrected hewa
– Kiʻina e elicit Customer ae maluna o haawi
– Ina o ka poe ola, ka hoʻololi ‘ana, he mea pono e nä waihona palapala
– Nānā ‘pela mau ala’ ikamu e kiʻekiʻe i ia kūlana e like me ka poe i koe o ka lako polokalamu.

14 Corrective a Preventive hana

– Haʻi’ōlelo ka hoʻohanaʻana o ka hōʻike, i ole ke malama lakou i koi
– Haʻi’ōlelo ka hoʻohanaʻana o nā hōʻike e hoike ana pōkole, e hele mai i loko o ka ulu ana kaʻina
-ʻeleu Ohi, a me Ka Ikepili o ka loaʻa ‘ike e pili ana i huahana a me ka hoʻolohe manaʻo kaʻina ole-conformance a me preventive hana.

Information about pilikia pilikia e kipaku hou o ka ulu ana kaʻina.

– Customer hoʻopiʻi i, aole i pono lawelawe
– Deficiency Ua loaa aka, aole ee
– No ke kaʻina hana no e hōʻoia i ua ua kālailai pilikia, a hanaia mai
– No kaʻina hana no ka hoike pilikia me ka ana rula a me na kaʻina hana.

15 e hamohamo ana, pūnaewele,’ōpala, Preservation a me ka Delivery

Pili i ka lako polokalamu replicated ma New, pā hōkū a me kekahi meakino.
Media e ‘ae’ ia, a me ~ IA pololei. e makani hoʻi i aeaiiuo. Malaila e no hoi e hiki i ka e hoʻolako palekana mai unintentional poino.

16 Na Makuahine o Animal Records

E like ai nā palapala hōʻike i hana i lawe ia e hamama ai ‘ole ka huli e like ai. Ka hae pono i mea e ke kaʻina hana no ka lawelawe ana i ka mea e like ai moʻolelo. Nā moʻolelo e waiho ia ma ke ano i kūpono no ka mea, ua hoopuni ho’āmana.
– No lula no ka mālama o ka mea e like ai moʻolelo
– Review mooolelo, ua mālamaʻole i
– Hōʻike mooolelo, ua mālamaʻole i
– Wā no ka malama ana i kona mea e like mooolelo mea, aole i ho’ākāka ‘

17 Kūloko Animal Audits

La oia e kuokoa iʻahahui i mau audits i na hana a pau i aloha ia huahana a hana e like ai. Keia, ua mālama ‘ia ma ka aoao o ka poe hooponopono. Aole e lilo ka Hooia kumumanao.

– No Hooia map
– Hooia papahana, aole i ka la

18 aʻo

Poe e komo kēia mau mea kookoo, ua hoʻomaʻamaʻa no ka hana pono. A ina hana i:
– E kuhikuhi i aʻo pono ai no kela a me keia kookoo wahi
– Hoʻolako i ia mau aʻo
– E malama buke o ke aʻoʻiaʻana o nā mea a pau kookoo lālā.

Aʻo e nä waihona palapala a lawa. Ma lawa makou manao i ka mea e hiki ke hana i kana / ia hana i ke kiʻekiʻe lawa hae.

– No kaʻina hana no ka hoʻolālā ‘ole aʻo
– No aʻo mooolelo
– Aole loaa kupono aʻo no kona, a me kona hana.

19 Servicing

Wale mai ana e ua o nä waihona palapala kaʻina hana no ka mea, servicing, ina o keia ka mea i oleloia ma ka aelike. I ka lako polokalamu ka mea e pili ana i kuhihewa corrections a me na enhancements i haawi lako polokalamu.

Kaʻina hana no ka lawelawe hoopii a me na noi no ka hoʻololi ‘ana. Ka wale mai ana, aole nae e hoʻolako i hoomau ina ka mea, aole i oleloia ma ka aelike. Malama kaʻina hana no ka mea, kahiko lako polokalamu e hana.

– Malama hana no ka Customer me ka aelike
– Kekahi Mau ano no ka mālama ‘ana i ka wa kahiko huahana, aole o nä waihona palapala
– No kaʻina hana no ka ho’āʻo ma hope o ka hoʻoponopono.

20 ana helu ‘ana i kūpono

Aole e ohi a me Ka Ikepili o kaʻikepili e pili ana i ka helu o na hewa i loaa iloko o kaʻokoʻa kūlana. Information about hikiʻole e hālāwai lā palena pau, a me milestones e ua kālailai.

“————————————————– ————————————————– ————————————————–

תרגום תמיכה:
————————————————– ————————————————– ————————————————–
אלמנטי איכות העשרים ISO 9001

מבט יילקח על הדרישות מנקודת המבט של חברות פיתוח תוכנה. תקן ISO 9001 נועד לתעשיית הייצור. הדרישות מתפרשות לפיתוח תוכנה בהתאם ל- ISO 9000-3 ו TickIT.

ישנם 20 מרכיבים עיקריים. כל מושג ידוע היטב בקהילת ניהול איכות.

אחריות ניהולית 1.

1.1 מדיניות איכות

ההתקן מחייב ניהול הספקים להוציא פוליסת איכות, שבו כתוב על החברה לייצר מוצרים באיכות.

מדיניות האיכות תהיה:
– הגדר את מחויבותה של € ™ managementâ לאיכות
– הגדירו את היעדים של ™ € companyâ לגבי איכות, כלומר, מה וניהול מתכוון איכות
– להיות רלוונטי לצורכי s ™ € customerâ
– להיות מובן בארגון
– תיושם

ללא התאמות

– הצהרה מעורפלת מדי או מדיניות אינה מובנת על ידי צוות
– מדיניות האיכות אינה מיושמת.

לְמָשָׁל. מדיניות איכות

â œWe € להשיג איכות באמצעות צוות מוטיבציה ומיומן, נהלי עבודה מוגדרים, וסקירה אינטנסיבי ובדיקה ופעילויות.א €

1.2 ארגון

ההתקן דורש תיעוד של אחריות, סמכות גומלין של כל האדם להשפיע על איכות. משמעות דבר הוא שאם אדם יש אחריות, זה ישובץ באופן רשמי על ידי המנהל המתאים. האדם צריך את הסמכות לקיים את האחריות.

על פי ISO, אחריות פירושה:

חובה OEA € לפעול oneâ בהסכמה עצמו s € ™ כשמשהו צריך להיעשות מבלי להיות € toldâ.

ללא התאמה

– קיים של אחריות כי לא ניתן להשלים.


– אונליין הפרויקט
– לקוח הפרויקט
– ארגון פרויקט תחזוקה
פיתוח פיתוח חומרה ותוכנה –
– שולחן ארגון עזרת תחזוקה
– מכירה-פיתוח

משאבים דורשים כי הספק:
– זהה את דרישות משאבים
– הקצאת כוח אדם מיומן.

נציג ניהול דורש מינוי של נציג מנהל עם סמכות ואחריות ל:
– דאגו לכך שהחברה מקיימת את דרישות ISO 9001
– דווח את הביצועים של מערכת איכות הנהלת החברה

1.3 סקירת הנהלה

מנהל איכות צריך להציג את התוצאות באופן תקופתי של
– מבדקי איכות
סטטיסטיקות של תלונות איכות –
הרשום של פעולה מתקנת –

התוצאות יש להציג בישיבת ההנהלה רשמה עם הערות על שנכחו, מה שהוצג ומה החלטות נלקחו ועשה.

2. מערכת איכות

מערכת איכות € “”â € œThe מבנה ארגוני, אחריות, נהלים, תהליכים ומשאבים ליישום € איכות management.â

נהלים, כללים, החלטות תהא יתועד בכתב. אם יש לך כלל או נוהל זה אינו נדרש על ידי ISO 9001, תקן עדיין דורש שכתוב.

מדריך איכות תכלול התייחסות ותיעוד של מערכת האיכות.

ללא התאמה

– ביקורת הוא מדגם, ולכן אם במדגם, יש-התאמות הלא קלות, והם קבועים, הוא עדיין יכול להיות התאמה אי כי המבקר יכול לחשוד שיש אי-התאמות רבות יותר קלות.
– נהלים כתובים קיימים לא ימולאו.

3. סקר חוזה

בדוק הספק לפני חוזה לחתימה שהארגון יוכל לבצע את מה שנדרש על פי החוזה.

שאלות שצריכות להישאל כוללות:
– מתועדות והבנת הדרישות?
– כלולים בקריטריונים לקבלה?
– דרישות שונות מהמכרז נפתרו?
– יכול לגייס ההספק מספיק משאבים על החוזה?
– האם הספק לגייס את סמכותה דרושי החוזה?
– ניתן להשלים את המשימה בזמן?

התקן דורש כי נוהל מתועד עם ביקורות להיכלל. הספק צריך לזהות כמה תיקונים בחוזה וטיפול מפרט דרישות בין לקוחות וספקים להיות מוגדרים.

4. בקרת עיצוב

4.1. כללי
ISO דורש כי אתה מתכנן לפני שאני עושה ולציין לפני בעיצוב.

4.2. תכנון עיצוב ופיתוח

תכנית עיצוב צריכה להכיל:
– הגדרה של מתודולוגיה לשמש בפיתוח של מוצר
– לוחות זמנים, אחריות, מטלות עבודה ובקרה התקדמות
– שלבים בפרויקט יחולק. זה כולל קלט, פלט ואימות של פלט.
– תיאור של שיטות וכלים כדי לשמש

תכנית איכות צריכה לכלול:
– מטרות איכות
קריטריונים קבילים –
– זיהוי של תכנון, אימות ואישור.
אחריות לפעילויות איכות -.

אם חברה רוצה לקבל הסמכת ISO התוכניות תוחזקנה כל הפרויקטים, מאז תקן ISO מסתכל על החברה כולה ולא לפרויקטים ספציפיים.

4.3 ממשקים ארגוניים וטכניים

אם יש קבוצה-עבודה, הממשקים ביניהם צריכים להיות מזוהים, מתועדים ומשודר לאלה זקוקים המידע. התיעוד ייבדק באופן קבוע.

4.4 קלט עיצוב

דרישות מפרט להכיל את קלט העיצוב בפיתוח תוכנה. ניתן לעשות זאת על ידי הקונה או הוכן על ידי הספק באמצעות חוקים ותקנות. עוד קלט עיצוב כולל קידוד עיצוב אשר משמש כקלט קידוד.

ההתקן רוצה להבטיח שמוצר העבודה של כל שלב עונה על הדרישות.

בפיתוח תוכנה, שינויי דרישה נפוצים כל כך נוהל לטיפול דרישות חדשות ותוכן שהשתנו מהקונה להיוצר.

4.5 פלט עיצוב

פלט עיצוב: תיעוד עיצובים ואת קוד המקור. ISO דורש כי מסמכי תכנון וקידוד להיבדק לפני השחרור.

הליך הקבלה של פלט עיצוב וקריטריונים של קבלה צריך להיווצר.

4.6 סקירת עיצוב

פונקציות פרויקט כמו קידוד ובדיקה יוצגו על הסקירה. שיטה נפוצה הבטחת ביקורות הן רשימות.

4.7 אימות עיצוב

זה מורכב ביקורות, בדיקות מודול בדיקות אינטגרציה.

4.8 אימות עיצוב

מערכת בדיקה סופית, של מוצר תוכנה המלא יחד עם בדיקת תיעוד למשתמש. לא צריך להיות מתוכנן ומתועד אימות. בדיקות בטא הוא התאמה עם ISO כל עוד בדיקות בטא מכוסה הסכמה ברורה בין הספק ללקוח בדיקות בטא.

4.9 שינויי עיצוב

ISO 9001 דורשת כי לאחר שחרורו של תיעוד עיצובים או מקור, כל השינוי יקבל לעבור תהליך פורמלי שבו שינויים מתועדים, נבדקו ואושרו לפני היישום.

שינויים בלתי מבוקרים למסמכים טכניים מורכבים או תוכניות מסוכנים מאוד כתקן כזה אינו מאפשרים זאת.
5. מסמך ובקרת נתונים

מידע השולט פיתוח / תחזוקה של תוכנה. ההתקן דורש כי מי צריך קצת מסמך / נתונים יהיו גישה אליו. שינויים במסמכים יהיו נשלטו נתונים.

5.1 כללים

יאוחסנו מסמכים ונתונים חיצוניים. זה יכול להיות מאוחסן על כל צורה (עותק קשיח, תקשורת אלקטרונית).

5.2 מסמך ואישור נתונים והנפקת

לפני מסמכי הנפקה ונתונים יהיה נבדקה ואושרה לפני כל בעיה. רשימת המסמך שבו ייאסר האדם לברר את הגרסה הנוכחית של מסמך. מסמכים לא חוקיים או מיושנים יש להסיר או מסומנים בבירור.

5.3 מסמך ושינויי נתונים

האדם / s אחראי על תהליך הבדיקה והאישור יפורט.

6. רכש

במקרה של קבלן משנה, אתה עדיין אחראי. כְּלוֹמַר. אם החלה עבור חוזה בקבלנות משנה את העבודה, תקני ISO הם עדיין תחת האחריות שלך ודרישות ISO לא צריכים להיות מוטלות על קבלן המשנה.

6.1 כללים

אם כוח האדם נרכש, התקן מחייב אותך פי נוהל שאתה מקבל את האנשים הנכונים. האנשים יהיו בשליטת קבלן משנה הספק ולא.
כדי להבטיח כי תוכנות שנרכשו עומד בדרישות:
– דרישות חוזה על נהלי קבלני משנה
– ביקורת של מערכת איכות קבלן משנה
– קבלן המשנה בדוק בעבר ביצועים
– סקר קבלן המשנה במהלך החוזה
– סקירת עד ובדיקה
– בדיקה וסקירת מוצר של קבלן משנה.

6.2 הערכת קבלני המשנה

אדם, בעלי סמכויות ויכולת צורך ישפוט כל קבלן משנה ולהחליט אם להשתמש. ההחלטות יתועדו.

הספק יחליט מה שליטת קבלן משנה זה יהיה. התקן אינו מזכיר כמה שליטה אתה צריך. זה פשוט מזכיר כי החלטה צריכה להיעשות על ידי שימוש בעובדות.

מקרה מיוחד הוא כאשר תוכנה נרכשה דרך הקמעונאי. בשנת קבלן משנה במקרה זה הוא ארגון שאליו הרכישה מתנהלת, לא המפתח המקורי של התוכנה.

אם הקנייה מתבצעת באמצעות ISO הקמעונאי 9001 מחייבים אותך להגדיר באיזו מידה אתה העלית דרישות על קמעונאי לשלוט הספק שלה.

6.3 רכש נתונים

דרישות על תהליך הפיתוח יתועדו בחוזה לצד דרישות הספק לאשר תוצאות עבודה ונהלים.

6.4 אימות של המוצר הנרכש

תיעוד החלטות בנוגע לאימות של כל רכשו כלי פיתוח או מוצר הכלול.
ללא התאמה

– אין רשימה של ספקים מאושרים
– שליטה בלתי הולמת של קבלן משנה
– אין אימות מסמכים של פריטים שנרכשו
– חוזה לא ראוי עם קבלן משנה.

בקרת 7 של מוצרים המסופקים על-ידי הלקוח

על הספק יש נהלי אימות, אחסון ותחזוקה של תוכנה המסופק ללקוח. עם זאת, האיכות היא באחריות של התוכנה.

מי שאינו התאמה קורה בשל אחריות ברורה של אחריות בין הלקוח לבין הספק.

מפרט מוצר 8 ו עקיב

ספק התוכנה צריך לשמור על שליטה על:
– על מה שקדם מסמך ולהנפיק היא מבוססת
– באיזה מפרט זה מבוסס
– תיקוני תיקונים מה נכלל בתוכניות אשר מקור
– מה קרה כל דוח בעיה
– לפי מה מקור נוצר מודול ספציפי.

בקרת תהליכים 9

תיעד נוהל תהליך השכפול בתפעול נוהל הטיפול של המאסטר Proma € ™ s / ספריות. כדי להבטיח כי הגירסות נכונות משמשות.

ללא התאמה
– אין נוהל מתועד לשכפול
– טיפול לא נכון של דיסקטים מאסטר Proma € ™ s או.

10 בדיקה וניסוי

נהלים כתובים עבור בדיקה וניסוי להיעשות בקשר עם שכפול.

ללא התאמה
– הפונקציה של בדיקה אוטומטית Proma € ™ s לא נבדקה
– מתועד הליך אין לבדיקת Proma € ™ s.

שליטת 11 של פיקוח, מדידת ציוד בדיקה

הספק צריך לבחור את ציוד המדידה המתאים ובצע נוהל מתועד וכלים לניהול של ציוד. צריכה להיבדק כל גרסת תוכנה חדשה עבור הסתפקות.

בדיקת 12 ומצב מבחן

מפרט ותוכניות צריכים לאימות דרך ביקורות ובדיקות. על הספק להיות נהלים האוסרים שימוש מפרטים מאומתים או תוכניות.

13 פיקוח על מוצרים חורגים

מוצרי חורג לא אמורים לשמש במתכוון. נוהל לטיפול שינויים מהירים במקרה של טעויות קריטיות צריכים להיוצר.

– זיהוי ברור של פריטים מבוקרים המכילים טעויות שלא תוקנו
– שיטה לעורר הקבלה בקרב לקוחותינו עם מסירת
– במקרה של שינויים מהירים, חייב להיות מתועד זה
– סקירת פריטים שונים כך יהיה מורם לאותו מעמד כמו שאר תוכנה.

פעולה מתקנת ומונעת 14

– טיפול אפקטיבי של דוחות שאינם תואמים לדרישות
– טיפול אפקטיבי של דיווחי מצביעים קצרים באות בתהליך הפיתוח
– איסוף וניתוח פעילות של מידע זמין על המוצר ותהליך הלא התאמה ופעולות מניעה.

מידע על בעיות נתקלו צריך לנהוג שיפורים של תהליך הפיתוח.

ללא התאמה
– תלונת לקוח לא טופלה כראוי
– מחסור כבר נמצא אבל לא תיקן
– אין תהליך על מנת להבטיח כי בעיות מנותחות ותינקטנה
– אין נוהל דיווח קשיים עם החלת כללים ונהלים.

15 שינוע, אחסנה, אריזה, שימור והפצה

חל על תוכנות משוכפלות על PROM, דיסק או מדיום אחר.
מדיה תהיה שהכותרת וארוזה כראוי. יהיה מגובה נתונים. שם צריך להיות גם את היכולת לספק הגנה מפני פגיעה לא מכוונת.

שליטת 16 רשומות איכות

מסמכים באיכות להראות אילו פעולות ננקטו כדי להבטיח או לבדוק את האיכות. התקן דורש כי יתקיים הליך הטיפול של רשומות איכות. הרשומות יש לאחסן באופן הולם כך שהם נגישים בקלות.
ללא התאמות:
– אין כללים לשמירה רשומה איכות
– רשומות סקירה לא נשמרים
– רשום מבחן אינם נשמרים
– תקופת ניהול פנקס איכות אינה מוגדרת

מבדקי איכות פנימית 17

לא צריך להיות גוף חיצוני אשר באופן קבוע עובר על כל הפעולות שעלולות להשפיע על איכות מוצר או שירות. אלו מבוצעות מטעם הנהלת החברה. הרשימה אמורה להיות תכנית ביקורת.

ללא התאמה
– אין תוכנית הביקורת
– תוכנית הביקורת לא מעודכן

18 הדרכה

החברה צריכה להבטיח הצוות כי הוא אימן עבור המשימות הנדרשות. נוהל:
– לזהות את הצרכים הדרכות עבור כל עמדת סגל
– לספק הכשרה כזו
– שמור תיעוד של הכשרה של כל חברי הצוות.

אימון צריך להיות מתועד מספיק. על ידי מספיק שאנחנו אומרים שהאדם להיות מסוגל לבצע עבודתו / הוא ברמה גבוהה מספיק.

ללא התאמה
– נהלים אין לתכנון או הכשרה
– אין רשומות הדרכה
– לא קיבלו הכשרה מתאימה למשימה שלו או שלה.

19 ולשירות

ספק יהיה תעד נהלים לשירות אם זה מוזכר בחוזה. בתוכנה זה על תיקוני שגיאות ושיפורים לתוכנת נמסר.

נהלים לטיפול בתלונות ובבקשות שינויים. הספק אינו מחויב לספק תחזוקה אם זה אינו מוזכר בחוזה. נהלי תחזוקה עבור תוכנה ישנה צריכים להיעשות.

ללא התאמה
– עבודת תחזוקה עבור לקוח ללא חוזה
– שיטות ספציפיות עבור תחזוקה של מוצר ישן אינה מתועדות
– אין תהליך לבדיקה לאחר תחזוקה.

20 טכניקות סטטיסטיות

לא צריכים להיות איסוף וניתוח של נתונים על מספר השגיאות שנמצאו בשלבים השונים. מידע על חוסר יכולת לעמוד בלוחות זמנים ואבני דרך יש לנתח.

“————————————————– ————————————————– ————————————————–

समर्थन अनुवाद:
————————————————– ————————————————– ————————————————–
आईएसओ 9001 बीस गुणवत्ता तत्वों

एक नज़र सॉफ्टवेयर को विकसित करने के लिए कंपनियों की दृष्टि से आवश्यकताओं पर ले जाया जाएगा। आईएसओ 9001 मानक विनिर्माण उद्योग के लिए करना था। आवश्यकताओं को आईएसओ 9000-3 और TickIT के अनुसार सॉफ्टवेयर विकास के लिए व्याख्या कर रहे हैं।

वहाँ 20 मुख्य तत्व हैं। प्रत्येक अवधारणा अच्छी तरह से गुणवत्ता प्रबंधन समुदाय में जाना जाता है।

1. प्रबंधन जिम्मेदारी

1.1 गुणवत्ता की नीति

मानक एक गुणवत्ता नीति है, जहां यह कहना है कि कंपनी गुणवत्ता के उत्पादों का उत्पादन करेगा जारी करने के लिए आपूर्तिकर्ता प्रबंधन की आवश्यकता है।

गुणवत्ता नीति करेगा:
– परिभाषित managementâ € ™ की गुणवत्ता के प्रति प्रतिबद्धता
– गुणवत्ता के संबंध में परिभाषित कंपनी € ™ के उद्देश्यों, वह यह है कि क्या प्रबंधन गुणवत्ता से मतलब है
– Customerâ € ™ के जरूरतों के लिए प्रासंगिक बनें
– संगठन में समझा जा
– कार्यान्वित किया गया


– बहुत अस्पष्ट या नीति वक्तव्य के कर्मचारियों द्वारा नहीं समझा गया है
– गुणवत्ता नीति लागू नहीं है।

जैसे गुणवत्ता नीति के

एक € œWe प्रेरित और कुशल कर्मचारियों के माध्यम से गुणवत्ता, परिभाषित काम प्रक्रियाओं, और गहन समीक्षा और activities.â € परीक्षण के लक्ष्य को हासिल

1.2 संगठन

मानक जिम्मेदारी, अधिकार और गुणवत्ता प्रभावित करने वाले सभी कर्मियों के आपसी संबंध के दस्तावेज की आवश्यकता है। इसका मतलब यह है कि यदि एक व्यक्ति एक जिम्मेदारी है, यह औपचारिक रूप से उचित प्रबंधक द्वारा आवंटित किया जाएगा। व्यक्ति जिम्मेदारी को पूरा करने का अधिकार होना चाहिए।

आईएसओ के अनुसार, जिम्मेदारी का मतलब:

एक जब कुछ toldâ € होने के बिना किया जा सकता है € œa कर्तव्य oneâ € ™ के स्वयं के समझौते पर कार्य करने के लिए।

गैर अनुरूपता

– एक जिम्मेदारी है कि पूरा नहीं किया जा सकता है की मौजूदा।


– परियोजना लाइन
– परियोजना ग्राहक
– परियोजना रखरखाव संगठन
– सॉफ्टवेयर विकास-विकास हार्डवेयर
– रखरखाव संगठन-हेल्प डेस्क
– विक्रय विकास

संसाधनों की आवश्यकता आपूर्तिकर्ता है कि:
– संसाधनों के लिए आवश्यकताओं को पहचानें
– प्रशिक्षित कर्मियों निरुपित।

प्रबंधन प्रतिनिधि के अधिकार और जिम्मेदारी के साथ करने के लिए प्रबंधक प्रतिनिधि की नियुक्ति की आवश्यकता है:
– सुनिश्चित करें कि कंपनी 9001 में आवश्यकताओं को पूरा
– कंपनी के प्रबंधन के लिए गुणवत्ता प्रणाली के प्रदर्शन रिपोर्ट

1.3 प्रबंधन की समीक्षा

गुणवत्ता प्रबंधक समय समय के परिणाम पेश करना चाहिए
– गुणवत्ता आडिट
– गुणवत्ता की शिकायतों की सांख्यिकी
– सुधारात्मक कार्रवाई के रिकार्ड

परिणाम जो भाग लिया पर नोट्स, क्या पेश किया गया और क्या निर्णय लिया गया था और बनाया के साथ एक रिकॉर्ड प्रबंधन की बैठक में प्रस्तुत किया जाना चाहिए।

2. गुणवत्ता प्रणाली

गुणवत्ता प्रणाली â € “”एक € œthe संगठनात्मक संरचना, जिम्मेदारियों, प्रक्रियाओं, प्रक्रियाओं और गुणवत्ता management.â € लागू करने के लिए संसाधनों

प्रक्रियाओं, नियमों, निर्णय लेखन में डाला जाए। आप किसी नियम या प्रक्रिया है कि आईएसओ 9001 द्वारा जरूरी नहीं है है, तो मानक अभी भी आवश्यकता है कि यह लिखा है।

एक गुणवत्ता मैनुअल संदर्भ और गुणवत्ता प्रणाली के दस्तावेज शामिल होगा।

गैर अनुरूपता

– एक लेखा परीक्षा एक नमूना है, इसलिए यदि एक नमूने में, वहाँ मामूली गैर conformances हैं, और वे तय कर रहे हैं, यह अभी भी एक गैर-अनुरूपता हो सकता है क्योंकि लेखा परीक्षक शक कर सकते हैं कई और अधिक नाबालिग गैर conformances देखते हैं कि।
– मौजूदा लिखा प्रक्रियाओं का पालन नहीं कर रहे हैं।

3. अनुबंध की समीक्षा

अनुबंध पर हस्ताक्षर करने से पहले आपूर्तिकर्ता की जाँच करता है कि संगठन के प्रदर्शन करने के लिए क्या अनुबंध के लिए आवश्यक है में सक्षम हो।

सवाल पूछा जाना चाहिए शामिल हैं:
– आवश्यकताओं दस्तावेज और समझ रहे हैं?
– स्वीकृति मानदंडों शामिल किए गए हैं?
– निविदा से भिन्न आवश्यकताओं को सुलझा लिया गया है?
– आपूर्तिकर्ता अनुबंध के लिए पर्याप्त संसाधन जुटा सकते हैं?
– आपूर्तिकर्ता क्षमता अनुबंध के लिए आवश्यक जुटा सकते हैं?
– कार्य समय में पूरा किया जा सकता है?

मानक की आवश्यकता है कि समीक्षा के साथ एक दस्तावेज प्रक्रिया में शामिल किया जाना। आपूर्तिकर्ता की पहचान करनी चाहिए कि कैसे अनुबंध संशोधन और ग्राहक और आपूर्तिकर्ता के बीच आवश्यकताओं विनिर्देश की हैंडलिंग में परिभाषित किया जा सकता है।

4. डिजाइन नियंत्रण

4.1। सामान्य
आईएसओ आवश्यकता है कि आप ऐसा करने से पहले की योजना और डिजाइन करने से पहले निर्दिष्ट करें।

4.2। डिजाइन और विकास योजना

डिजाइन की योजना को शामिल करना चाहिए:
– कार्यप्रणाली की परिभाषा उत्पाद के विकास में इस्तेमाल किया जाएगा
– समय कार्यक्रम, जिम्मेदारियों, काम के कार्य और प्रगति नियंत्रण
– चरण परियोजना विभाजित किया जाएगा। इस इनपुट, आउटपुट और उत्पादन का सत्यापन भी शामिल है।
– तरीकों और उपकरणों का विवरण इस्तेमाल किया जाएगा

गुणवत्ता की योजना को शामिल करना चाहिए:
– गुणवत्ता लक्ष्यों
– स्वीकार्यता के लिए मानदंड
– योजना, सत्यापन और सत्यापन की पहचान।
– गुणवत्ता गतिविधियों के लिए जिम्मेदारियों।

एक कंपनी, आईएसओ योग्यता की योजना सभी परियोजनाओं में आयोजित किया जाना चाहिए हासिल करने के बाद से आईएसओ प्रमाणीकरण विशिष्ट परियोजनाओं के लिए पूरी कंपनी के लिए है और नहीं चाहता है।

4.3 संगठनात्मक और तकनीकी इंटरफेस

अगर वहाँ समूह का काम, उन दोनों के बीच इंटरफेस, पहचान की जानी चाहिए दस्तावेज और जानकारी की जरूरत उन लोगों के लिए प्रेषित किया। प्रलेखन नियमित रूप से समीक्षा की जाएगी।

4.4 डिजाइन इनपुट

आवश्यकताओं विनिर्देशों सॉफ्टवेयर के विकास में डिजाइन इनपुट होते हैं। इस क्रेता द्वारा किया या सप्लायर कानूनों और नियमों का उपयोग करके तैयार किया जा सकता है। एक और डिजाइन इनपुट डिजाइन कोडिंग जो कोडिंग के लिए इनपुट के रूप में प्रयोग किया जाता है शामिल हैं।

मानक सुनिश्चित करने के लिए कि प्रत्येक चरण के काम उत्पाद आवश्यकताओं को पूरा करना चाहती है।

सॉफ्टवेयर के विकास में, आवश्यकता परिवर्तन आम कर रहे हैं तो क्रेता से नए और परिवर्तित आवश्यकताओं से निपटने के लिए एक प्रक्रिया बनाया जा।

4.5 डिजाइन आउटपुट

डिजाइन उत्पादन: डिजाइन प्रलेखन और स्रोत कोड। आईएसओ की आवश्यकता है कोडन कि डिजाइन दस्तावेजों और रिलीज से पहले समीक्षा की।

डिजाइन उत्पादन और स्वीकृति के मानदंडों की स्वीकृति के लिए एक प्रक्रिया बनाया जाना चाहिए।

4.6 डिजाइन की समीक्षा

कोडिंग और परीक्षण की तरह परियोजना के कार्यों की समीक्षा में प्रस्तुत किया जाएगा। समीक्षा सुनिश्चित करने के लिए एक आम तरीका जाँच कर रहे हैं।

4.7 डिजाइन सत्यापन

इस समीक्षा, मॉड्यूल का परीक्षण और एकीकरण के परीक्षण के होते हैं।

4.8 डिजाइन के प्रमाणीकरण

अंतिम प्रणाली परीक्षण, पूरा सॉफ्टवेयर उत्पाद के साथ उपयोगकर्ता दस्तावेज की समीक्षा के साथ। वहाँ की योजना बनाई और दस्तावेज सत्यापन किया जाना चाहिए। बीटा परीक्षण के रूप में लंबे समय के रूप में बीटा परीक्षण आपूर्तिकर्ता और बीटा परीक्षण ग्राहक के बीच एक स्पष्ट समझौते के द्वारा कवर किया जाता है आईएसओ के साथ conformance में है।

4.9 डिजाइन परिवर्तन

आईएसओ 9001 की आवश्यकता है कि डिजाइन दस्तावेज़ या स्रोत की रिहाई के बाद, सभी परिवर्तनों को एक औपचारिक प्रक्रिया जहां परिवर्तन, दस्तावेज हैं की समीक्षा की और कार्यान्वयन से पहले मंजूरी दे दी है के माध्यम से जाना जाएगा।

जटिल तकनीकी दस्तावेज या कार्यक्रमों के लिए अनियंत्रित परिवर्तन बेहद खतरनाक हैं और इस तरह के मानक के रूप में यह अनुमति नहीं है।
5. दस्तावेज़ और डेटा नियंत्रण

सूचना है कि सॉफ्टवेयर के विकास / रखरखाव नियंत्रित करता है। मानक की आवश्यकता है कि जिन लोगों ने कुछ दस्तावेज की जरूरत है / डेटा के लिए उपयोग किया जाएगा। दस्तावेजों और डेटा में परिवर्तन नियंत्रित किया जाएगा।

5.1 जनरल

बाहरी दस्तावेजों और डेटा संग्रहीत किया जाएगा। यह किसी भी रूप (हार्ड कॉपी, इलेक्ट्रॉनिक मीडिया) पर संग्रहीत किया जा सकता है।

5.2 दस्तावेज़ और डेटा स्वीकृति और मुद्दा

मुद्दा दस्तावेजों और डेटा से पहले की समीक्षा की और हर मुद्दे से पहले अनुमोदित किया जाएगा। एक दस्तावेज़ सूची, जिनमें से एक एक दस्तावेज़ के वर्तमान संस्करण का पता लगाना होगा। अमान्य या अप्रचलित दस्तावेजों हटाया जाना चाहिए या स्पष्ट रूप से चिह्नित।

5.3 दस्तावेज़ और डेटा परिवर्तन

समीक्षा और अनुमोदन प्रक्रिया के आरोप में व्यक्ति / s निर्दिष्ट किया जाएगा।

6. खरीद

उपठेकेदार के मामले में, आप अभी भी जिम्मेदार हैं। अर्थात। यदि आप एक अनुबंध के लिए लागू करते हैं और काम उपपट्टा, आईएसओ मानकों को अपनी जिम्मेदारी के तहत अब भी है और आईएसओ आवश्यकताओं उपठेकेदार पर लगाया जा करने के लिए नहीं है।

6.1 सामान्य

जनशक्ति खरीदा जाता है, तो मानक के लिए एक प्रक्रिया है कि आप सही लोगों को मिल का पालन करने की आवश्यकता है। लोगों सप्लायर और न उपठेकेदार द्वारा नियंत्रित किया जाएगा।
कि खरीदी सॉफ्टवेयर सुनिश्चित करने के लिए आवश्यकताओं के अनुरूप है:
– Subcontractors प्रक्रियाओं पर अनुबंध आवश्यकताओं
– उपठेकेदार गुणवत्ता प्रणाली की लेखा परीक्षा
– चेक पिछले प्रदर्शन उपठेकेदार
– अनुबंध के दौरान उपठेकेदार सर्वेक्षण
– गवाह समीक्षा और परीक्षण
– टेस्ट और उपठेकेदार की समीक्षा के उत्पाद।

उप 6.2 मूल्यांकन

आवश्यक अधिकार और क्षमता के साथ व्यक्ति को प्रत्येक उपठेकेदार न्यायाधीश और तय करते हैं कि उपयोग करने करेगा। फैसलों प्रलेखित किया जाएगा।

आपूर्तिकर्ता फैसला करेगा उपठेकेदार के ऊपर क्या यह नियंत्रण होगा। मानक आप होना चाहिए कितना नियंत्रण का उल्लेख नहीं है। यह सिर्फ उल्लेख है कि एक निर्णय तथ्यों का उपयोग करके किया जाना चाहिए।

एक विशेष मामला है जब सॉफ्टवेयर खुदरा के माध्यम से खरीदा जाता है। इस मामले में उपठेकेदार संगठन के साथ जो खरीद आयोजित किया जाता है, न कि सॉफ्टवेयर के मूल निर्माता है।

क्रय खुदरा आईएसओ के माध्यम से किया जाता है तो 9001 की आवश्यकता है कि आप किस हद तक आप अपने आपूर्तिकर्ता को नियंत्रित करने के फुटकर बिक्री पर आवश्यकताओं डाल परिभाषित करते हैं।

6.3 क्रय डेटा

विकास की प्रक्रिया पर काम आवश्यकताओं के परिणाम और प्रक्रियाओं को मंजूरी के लिए आपूर्तिकर्ता आवश्यकताओं के साथ अनुबंध में दर्ज हो जाएगा।

खरीदा उत्पाद का 6.4 सत्यापन

प्रत्येक के सत्यापन के बारे में निर्णय के प्रलेखन विकास उपकरण या शामिल उत्पाद खरीदा है।
गैर अनुरूपता

– अनुमोदित आपूर्तिकर्ताओं की कोई सूची
– उपठेकेदार के अनुचित नियंत्रण
– खरीदी गई वस्तुओं की कोई दस्तावेज सत्यापन
– उपठेकेदार के साथ अनुचित अनुबंध।

ग्राहक की आपूर्ति उत्पाद का 7 नियंत्रण

आपूर्तिकर्ता सत्यापन, भंडारण और ग्राहक की आपूर्ति सॉफ्टवेयर के रखरखाव के लिए प्रक्रियाओं की नहीं होगी। हालांकि, गुणवत्ता सॉफ्टवेयर की जिम्मेदारी है।

एक गैर-अनुरूपता ग्राहक और आपूर्तिकर्ता के बीच जिम्मेदारी का स्पष्ट नहीं जिम्मेदारी के कारण होता है।

8 उत्पाद विशिष्टता और traceability

सॉफ्टवेयर आपूर्तिकर्ता पर नियंत्रण रखना चाहिए:
– क्या दस्तावेज़ पूर्ववर्ती और वह इस मुद्दे पर आधारित है
– जो विनिर्देश पर यह आधारित है
– क्या सुधार और संशोधन जो स्रोत कार्यक्रमों में शामिल किया गया है
– प्रत्येक समस्या की रिपोर्ट का क्या हुआ
– क्या स्रोत से एक विशिष्ट मॉड्यूल तैयार की गई थी।

9 प्रक्रिया नियंत्रण

मास्टर PROMA € ™ s / पुस्तकालयों से निपटने के लिए संचालन और प्रक्रिया में प्रतिकृति प्रक्रिया के लिए प्रक्रिया प्रलेखित। सुनिश्चित करें कि सही संस्करण प्रयोग किया जाता है।

गैर अनुरूपता
– प्रतिकृति के लिए कोई दस्तावेज प्रक्रिया
– मास्टर PROMA € ™ के या डिस्केट के अनुचित हैंडलिंग।

10 निरीक्षण और परीक्षण

निरीक्षण और परीक्षण के लिए लिखित प्रक्रियाओं प्रतिकृति के संबंध में किया जाना है।

गैर अनुरूपता
– स्वचालित रूप से जाँच PROMA € ™ के समारोह का निरीक्षण नहीं किया गया है
– कोई परीक्षण PROMA € ™ के लिए प्रक्रिया दस्तावेज।

निरीक्षण, माप और परीक्षण उपकरणों के 11 नियंत्रण

आपूर्तिकर्ता उचित माप उपकरण का चयन करें और उपकरणों के नियंत्रण के लिए एक दस्तावेज प्रक्रिया का पालन करना चाहिए। प्रत्येक नया सॉफ्टवेयर संस्करण प्रचुरता के लिए परीक्षण किया जाना चाहिए।

12 निरीक्षण और परीक्षण स्थिति

विनिर्देशों और कार्यक्रमों की समीक्षा और परीक्षण के माध्यम से सत्यापित करना चाहिए। आपूर्तिकर्ता प्रक्रियाओं है कि असत्यापित विनिर्देशों या कार्यक्रमों के उपयोग के निषेध होगा।

गैर अनुरूप उत्पाद के 13 नियंत्रण

गैर अनुरूप उत्पादों अनजाने में नहीं किया जाना चाहिए। गंभीर त्रुटि के मामले में त्वरित संशोधनों से निपटने के लिए एक प्रक्रिया बनाया जाना चाहिए।

– नियंत्रित वस्तुओं है कि uncorrected त्रुटियों के होते हैं की पहचान साफ
– विधि वितरण पर ग्राहक स्वीकृति बटोर
– त्वरित संशोधनों के मामले में, यह प्रलेखित किया जाना चाहिए
– तो संशोधित आइटम की समीक्षा सॉफ्टवेयर के बाकी के रूप में एक ही स्थिति को ऊपर उठाया जा जाएगा।

14 सुधारात्मक और निवारक कार्रवाई

– रिपोर्ट है कि आवश्यकताओं के अनुरूप नहीं है के प्रभावी हैंडलिंग
– विकास की प्रक्रिया में कम आने का संकेत रिपोर्टों के प्रभावी हैंडलिंग
– सक्रिय संग्रह और उत्पाद और प्रक्रिया गैर अनुरूपता और निवारक कार्रवाई के बारे में उपलब्ध जानकारी का विश्लेषण।

विकास की प्रक्रिया के सुधार ड्राइव करना चाहिए का सामना करना पड़ा समस्याओं के बारे में जानकारी।

गैर अनुरूपता
– ग्राहक की शिकायत को ठीक से नहीं संभाला कर दिया गया है
– कमी से पाया गया है, लेकिन सही नहीं
– कोई प्रक्रिया सुनिश्चित करने के लिए समस्याओं का विश्लेषण किया और इस पर काम किया जाता है कि
– रिपोर्टिंग नियमों और प्रक्रियाओं को लागू करने के साथ कठिनाइयों के लिए कोई प्रक्रिया।

15 हैंडलिंग, भंडारण, पैकेजिंग, संरक्षण और वितरण

सालाना जलसे, डिस्क या अन्य माध्यम पर दोहराया सॉफ्टवेयर करने के लिए लागू होता है।
मीडिया लेबल और सही ढंग से पैक किया जाएगा। डेटा का बैकअप किया जाएगा। वहाँ भी अनजाने में नुकसान से सुरक्षा प्रदान करने की क्षमता होनी चाहिए।

गुणवत्ता रिकॉर्ड्स में 16 नियंत्रण

गुणवत्ता दस्तावेज बताते हैं, जो कार्रवाई सुनिश्चित या गुणवत्ता की जांच के लिए ले जाया गया है। मानक गुणवत्ता के रिकॉर्ड से निपटने के लिए एक प्रक्रिया है कि वहाँ की आवश्यकता है। रिकॉर्ड एक उचित तरीके से संग्रहित किया जाना चाहिए ताकि वे आसानी से सुलभ हैं।
– गुणवत्ता रिकॉर्ड की अवधारण के लिए कोई नियम नहीं
– समीक्षा रिकॉर्ड नहीं रखा जाता है
– टेस्ट रिकॉर्ड नहीं रखा जाता है
– गुणवत्ता रिकॉर्ड रखने की अवधि को परिभाषित नहीं किया गया है

17 आंतरिक गुणवत्ता ऑडिट

वहाँ एक स्वतंत्र इकाई है कि नियमित रूप से सभी आपरेशनों कि उत्पाद या सेवा की गुणवत्ता को प्रभावित कर सकता ऑडिट होना चाहिए। ये कंपनी प्रबंधन की ओर से आयोजित की जाती हैं। वहाँ एक लेखा परीक्षा योजना होनी चाहिए।

गैर अनुरूपता
– कोई लेखा परीक्षा योजना
– लेखा परीक्षा की तारीख तक नहीं की योजना

18 प्रशिक्षण

कंपनी है कि कर्मचारियों को यह सुनिश्चित करना चाहिए आवश्यक कार्यों के लिए प्रशिक्षित किया जाता है। करने के लिए एक प्रक्रिया है:
– प्रत्येक कर्मचारी की स्थिति के लिए प्रशिक्षण की जरूरत को पहचानें
– इस तरह के प्रशिक्षण प्रदान करें
– सभी स्टाफ सदस्यों के प्रशिक्षण का रिकॉर्ड रखें।

प्रशिक्षण दस्तावेज और पर्याप्त होना चाहिए। पर्याप्त रूप से हम मतलब है कि व्यक्ति को एक पर्याप्त उच्च मानक के लिए उसकी / उसके काम प्रदर्शन करने में सक्षम हो।

गैर अनुरूपता
– योजना या प्रशिक्षण के लिए कोई प्रक्रियाओं
– कोई प्रशिक्षण रिकॉर्ड
– अपने या अपने काम के लिए उचित प्रशिक्षण प्राप्त नहीं है।

19 सर्विसिंग

प्रदायक सर्विसिंग अगर इस अनुबंध में उल्लेख किया गया है के लिए प्रक्रियाओं प्रलेखित है जाएगा। सॉफ्टवेयर में यह त्रुटि सुधार और दिया सॉफ्टवेयर करने के संवर्द्धन के बारे में है।

संशोधन के लिए शिकायतों और अनुरोधों निपटने के लिए प्रक्रियाओं। आपूर्तिकर्ता यदि यह अनुबंध में उल्लेख नहीं किया है रखरखाव प्रदान करने के लिए बाध्य नहीं है। पुराने सॉफ्टवेयर के लिए रखरखाव प्रक्रियाओं बनाया जाना चाहिए।

गैर अनुरूपता
– एक अनुबंध के बिना एक ग्राहक के लिए रखरखाव का काम
– पुराने उत्पाद के रखरखाव के लिए विशिष्ट तरीके दर्ज़ नहीं है
– रखरखाव के बाद परीक्षण के लिए कोई प्रक्रिया।

20 सांख्यिकीय तकनीक

वहाँ संग्रह और विभिन्न चरणों में पाया त्रुटियों की संख्या के बारे में डेटा का विश्लेषण किया जाना चाहिए। समय सीमा और मील के पत्थर को पूरा करने में असमर्थता के बारे में जानकारी का विश्लेषण किया जाना चाहिए।

“————————————————– ————————————————– ————————————————–

Kev them nyiaj yug translation:
————————————————– ————————————————– ————————————————–
ISO 9001 Nees nkaum Zoo Hais

Ib tug saib yuav tsum tau noj thaum uas yuav tsum tau los ntawm qhov seem yus pom ntawm tuam txhab uas muag tsim software. ISO 9001 qauv twb npaj rau tus raug kev lag luam. Cov kev cai no yog txhais rau software txoj kev loj hlob nyob rau hauv raws li ISO 9000-3 thiab TickIT.

Muaj 20 lub ntsiab ntsiab. Txhua lub tswvyim yog zoo dua lub npe hu nyob rau hauv qhov zoo tshaj tswj lub zej lub zos.

1. Management lub luag hauj lwm

1.1 Zoo txoj cai

Tus txheem yuav tsum tau tsum tswj kom muab ib tug zoo txoj cai, qhov chaw uas nws hais tias lub tuam txhab yuav tsum ua cov khoom zoo.

Qhov zoo tshaj txoj cai yuav tsum:
– Txhais cov managementâ € ™ s kev cog lus kom zoo
– Txhais cov companyâ € ™ s hom phiaj hais txog zoo, uas yog, dab tsi kev tswj txhais tau tias los ntawm zoo
– Yuav tsum ceeb rau lub customerâ € ™ s xav tau kev pab
– Yuav to taub nyob rau hauv lub koom haum
– Yuav siv

Uas tsis yog-conformances

– Statement heev vague los yog txoj cai yog tsis to taub los ntawm cov neeg ua haujlwm
– Zoo txoj cai yog tsis siv.

E.g. of Quality txoj cai

â € œWe tau zoo los ntawm kev mob siab thiab cov neeg txawj neeg ua hauj lwm, txhais ua hauj lwm cov txheej txheem, thiab intensive saib xyuas thiab kev soj ntsuam activities.â €

1.2 Organization

Tus txheem yuav tsum tau cov ntaub ntawv ntawm lub luag hauj lwm, txoj cai thiab interrelation ntawm tag nrho cov neeg rau zoo. Qhov no txhais tau tias yog ib tug neeg muaj ib tug luag hauj lwm, nws yuav tsum tau kev lig kev cai muab los ntawm qhov kev tsim nyog saib xyuas. Tus neeg yuav tsum muaj txoj cai los ua kom tiav lub luag hauj lwm.

Raws li ISO, lub luag hauj lwm txhais tau tias:

â € œa lub luag hauj lwm ua nyob rau hauv oneâ € ™ s tus kheej accord thaum ib yam dab tsi yuav tsum tau ua tsis tau toldâ €.

Uas tsis yog-conformance

– Twb muaj lawm ntawm ib tug luag hauj lwm uas yuav tsis raug ua kom tiav.


– Project-line
– Project-neeg
– Project-txij nkawm koom haum
– Software kev loj hlob-kho vajtse txoj kev loj hlob
– Tu lub koom haum pab rooj
– Muag-txoj kev loj hlob

Resources yuav tsum tau hais tias tus neeg muag khoom:
– Qhia cov uas yuav tsum tau kev pab
– Muab kawm neeg.

Management tus neeg sawv cev yuav tsum tau lub sij hawm ntawm tus neeg saib xyuas tus neeg sawv cev uas muaj cai thiab lub luag hauj lwm rau:
– Xyuas kom meej tias lub tuam txhab ua lub uas yuav tsum tau nyob rau hauv ISO 9001
– Qhia cov kev ua tau zoo ntawm qhov zoo tshaj system rau lub tuam txhab tswj

1.3 Management Review

Zoo saib xyuas yuav tsum tsis tseg tuaj rau tau ntawm
– Zoo audits
– Statistics zoo tsis txaus siab
– Cov ntaub ntawv ntawm kev txhim kho kom txiav txim

Cov kev tshwm sim yuav tsum tau hais ntawm ib tug kaw tswj lub rooj sib tham nrog sau ntawv rau leej twg tau mus kawm, dab tsi twb hais thiab ua li cas txiav txim siab raug coj thiab ua.

2. Zoo System

Zoo system â € “”â € œthe quas qauv, cov dej num, cov txheej txheem, dab thiab cov kev pab rau kev siv zoo management.â €

Cov txheej txheem, kev cai, kev txiav txim siab yuav tsum raug muab tso rau hauv sau ntawv. Yog hais tias koj muaj ib txoj cai tswj los yog txoj kev uas tsis yog yuav tsum tau los ntawm ISO 9001, tus qauv tseem yuav tsum tau hais tias nws yog sau.

Ib tug zoo phau ntawv yuav tsum muaj reference thiab cov ntaub ntawv ntawm qhov zoo tshaj system.

Uas tsis yog-conformance

– Ib tug tshawb yog ib tug qauv, yog li ntawd yog hais tias nyob ib tug qauv, muaj me uas tsis yog-conformances, thiab lawv yog tsau, nws yuav tseem yuav muaj ib tug uas tsis yog-conformance vim hais tias cov auditor yuav xav tias muaj ntau ntau tus menyuam yaus uas tsis yog-conformances.
– Twb muaj lawm sau cov txheej txheem yog tsis adhered mus rau.

3. Daim ntawv cog lus Review

Cov neeg muag khoom tshev ua ntej kos npe rau daim ntawv cog lus hais tias cov koom haum yuav tau ua li cas yog yuav tsum tau los ntawm daim ntawv cog lus.

Cov lus nug uas yuav tsum tau nug muaj xws li:
– Yog yuav tsum sau thiab to taub?
– Yog txaus kev muaj?
– Muaj yuav tsum differing los ntawm cov kev sib tw tau daws?
– Cov neeg muag khoom muster txaus pab rau daim ntawv cog lus?
– Cov neeg muag khoom muster lub tsis txawj txaus uas yuav tsum tau rau daim ntawv cog lus?
– Cov neeg ua hauj lwm tau ua kom tiav nyob rau hauv lub sij hawm?

Tus txheem yuav tsum tau hais tias ib tug sau txoj kev nrog xyuas yuav muaj. Cov neeg muag khoom yuav tsum qhia hais tias yuav ua li cas daim ntawv cog lus hloov thiab tuav uas yuav tsum tau specification ntawm cov neeg thiab tsum tau txhais.

4. Tsim Control

4.1. General
ISO yuav tsum tau hais tias koj npaj ua ntej ua thiab qhia kom meej ua ntej tsim.

4.2. Tsim thiab kev loj hlob Planning

Tsim lub tswv yim yuav tsum muaj:
– Lus Txhais ntawm vib this yuav tsum tau siv nyob rau hauv txoj kev loj hlob ntawm cov khoom
– Lub sij hawm lub sij hawm, cov dej num, kev ua hauj lwm ntawv thiab kev kawm tswj
– Theem project yuav muab faib. Qhov no muaj xws li kev tawm tswv yim, tso zis thiab pov thawj ntawm cov zis.
– Hauj lwm ntawm txoj kev thiab cov cuab yeej yuav tsum tau siv

Zoo tswv yim yuav tsum muaj:
– Zoo lub hom phaj
– Kev Cai rau ibqho
– Qhia txog kev npaj, kev validation thiab pov thawj.
– Luag Hauj Lwm kom zoo kev ua ub no.

Yog hais tias ib lub tuam txhab xav mus nce ISO peev xwm cov kev npaj yuav tsum tau muaj nyob rau hauv tag nrho cov tej yaam num, txij li thaum ISO ntawv pov thawj yog rau tag nrho lub tuam txhab thiab tsis yog rau tej yaam num.

4.3 Organizational thiab Kev Interfaces

Yog hais tias muaj yog pab pawg neeg ua hauj lwm, lub interfaces nruab nrab ntawm lawv yuav tsum tau qhia, sau ua ntaub ntawv thiab kis tau mus rau cov neeg hu ua deductible cov ntaub ntawv. Cov ntaub ntawv yuav tsum muab saib tsis tu ncua.

4.4 Tsim tawm tswv yim

Yuav tsum muaj specifications muaj tus tsim cov tswv yim nyob rau hauv software txoj kev loj hlob. Qhov no tej zaum yuav ua tau los ntawm tus neeg yuav los yog npaj los ntawm tus neeg muag khoom siv cov cai thiab cov kev tswj cai. Lwm tsim cov tswv yim muaj xws li tsim coding uas yog siv raws li cov tswv yim rau coding.

Tus txheem xav los xyuas kom meej tias cov ua hauj lwm cov khoom ntawm txhua kauj ruam raws li.

Nyob rau hauv software txoj kev loj hlob, yuav tsum tau hloov cov kev li ntawd ib tug txheej txheem rau tuav tshiab thiab hloov uas yuav tsum tau los ntawm tus neeg yuav tsum tau tsim.

4.5 Tsim cov zis

Tsim cov zis: tus tsim cov ntaub ntawv thiab rau qhov chaws. ISO yuav tsum tau hais tias tsim ntaub ntawv thiab coding tau saib ua ntej tso.

Ib txoj kev rau kev txaus sab ntawm cov qauv tso zis thiab txheej xwm ntawm kev txaus yuav tsum tau tsim.

4.6 Tsim Review

Project zog zoo li coding thiab kev soj ntsuam yuav tsum tau hais ntawm qhov kev soj ntsuam. Ib tug ntau txoj kev rau kom ntseeg tau xyuas yog checklists.

4.7 Tsim Verification

Qhov no muaj xyuas, module soj ntsuam thiab kev koom ua ke soj ntsuam.

4.8 Tsim Validation

Kawg system xeem, ntawm tag nrho software khoom ua ke nrog rau cov saib neeg cov ntaub ntawv. Muaj yuav tsum tau npaj thiab sau validation. Beta xeem yog nyob rau hauv conformance nrog ISO li ntev raws li lub beta xeem yog them los ntawm ib tug ntshiab daim ntawv cog lus ntawm chaw muag khoom thiab beta-xeem neeg muas zaub.

4.9 Tsim kev hloov

ISO 9001 yuav tsum tau hais tias tom qab tso tawm ntawm tsim ntaub ntawv los yog qhov twg los, tag nrho cov kev hloov yuav tsum mus los ntawm ib tug formal kev uas hloov muaj ntaub ntawv, saib thiab pom zoo ua ntej siv.

Tsis ceev faj kev hloov mus rau txoj kev cov ntaub ntawv los yog cov kev pab cuam yog cov tsis tshua txaus ntshai thiab raws li xws li tus qauv tsis pub nws.
5. ntawv thiab ntaub ntawv Control

Cov ntaub ntawv uas lwm yam uas txoj kev loj hlob / txij nkawm ntawm software. Tus txheem yuav tsum tau hais tias cov neeg uas xav tau ib co ntaub ntawv / cov ntaub ntawv yuav tsum muaj kev nkag tau mus rau nws. Kev hloov rau cov ntaub ntawv thiab cov ntaub ntawv yuav tsum raug tswj.

5.1 General

Sab nraud cov ntaub ntawv thiab cov ntaub ntawv yuav tsum tau khaws cia. Nws yuav muab cia rau hauv tej daim ntawv (daim qauv, electronic media).

5.2 ntawv thiab ntaub ntawv pom zoo thiab qhov teeb meem

Ua ntej qhov teeb meem cov ntaub ntawv thiab cov ntaub ntawv yuav tsum tau saib thiab pom zoo ua ntej txhua teeb meem. Ib daim ntawv daim ntawv teev nyob rau hauv uas ib tug yuav tsum paub lub tam sim no version ntawm ib daim ntawv. Invalid los yog dhau caij nyoog cov ntaub ntawv yuav tsum tau muab tshem tawm los yog kom meej meej cim.

5.3 ntawv thiab ntaub ntawv hloov

Tus neeg / s nyob rau hauv them nyiaj ntawm cov kev ntsuam xyuas thiab kev tso cai yuav tsum tau teev.

6. yuav khoom

Nyob rau hauv cov ntaub ntawv ntawm subcontractor, koj tseem luag hauj lwm. I.e. Yog hais tias koj thov rau ib tug daim ntawv cog lus thiab kevpab lub chaw ua hauj lwm, ISO qauv yog tseem nyob rau hauv koj lub luag hauj lwm thiab ISO uas yuav tsum tau tsis muaj yuav tsum tau yuam rau tus subcontractor.

6.1 General

Yog hais tias manpower yog yuav, tus qauv yuav tsum tau koj ua raws li ib txoj kev uas koj tau txais txoj cai neeg. Cov neeg yuav raug tswj los ntawm khoom thiab tsis subcontractor.
Yuav kom paub meej tias muas software conforms rau yuav tsum:
– Daim ntawv cog lus uas yuav tsum tau nyob rau hauv cov subcontractors cov txheej txheem
– Audit ntawm lub subcontractor zoo system
– Kos subcontractor yav tag los kev kawm
– Daim ntawv ntsuam xyuas cov subcontractor thaum lub sij hawm daim ntawv cog lus
– Tus Tim Khawv xyuas thiab kev soj ntsuam
– Test thiab saib xyuas cov khoom ntawm subcontractor.

6.2 Kev luj xyuas ntawm Subcontractors

Tus Neeg muaj tsim nyog txoj cai thiab tsis txawj txaus yuav txiav txim rau txhua subcontractor thiab txiav txim siab seb puas yuav siv tau. Qhov kev txiav txim yuav tsum tau sau tseg.

Cov neeg muag khoom yuav tsum txiav txim siab li cas tswj subcontractor nws yuav muaj. Tus txheem tsis hais ntau npaum li cas tswj koj yuav tsum tau muaj. Nws cia li hais tias ib tug txiav txim yuav tsum tau ua los ntawm kev siv cov lus tseeb.

Ib tug tshwj xeeb cov ntaub ntawv yog thaum software yog yuav los ntawm lub khw muag khoom. Nyob rau hauv cov ntaub ntawv no subcontractor yog lub koom haum uas cov purchase yog ua, tsis yog lub thawj tsim tawm ntawm qhov software.

Yog hais tias yuav khoom yog ua los ntawm lub khw muag khoom ISO 9001 yuav tsum tau hais tias koj txhais mus li cas raws li koj muab tso rau yuav tsum nyob rau hauv lub retailer los tswj nws tsum.

6.3 kev yuav khoom cov ntaub ntawv

Yuav tsum rau txoj kev loj hlob yuav tsum tau muab sau nyob rau hauv daim ntawv cog lus nrog rau khoom yuav tsum pom zoo ua hauj lwm tau thiab cov txheej txheem.

6.4 Verification of muas khoom

Cov ntaub ntawv ntawm kev txiav txim siab txog lub pov thawj ntawm txhua muas txoj kev loj hlob lub cuab tam los yog muaj khoom.
Uas tsis yog-conformance

– Tsis muaj daim ntawv teev cov kev pom zoo lwm
– Lam tswj ntawm subcontractor
– Tsis muaj daim ntawv pov thawj ntawm muas khoom
– Lam daim ntawv cog lus nrog subcontractor.

7 Control ntawm Neeg-nkag khoom

Cov neeg muag khoom yuav tsum muaj cov txheej txheem rau pov thawj, cia thiab txij nkawm ntawm cov neeg nkag software. Txawm li cas los, qhov zoo yog lub luag hauj lwm ntawm lub software.

Ib tug uas tsis yog-conformance tshwm sim vim tsis meej luag hauj lwm ntawm lub luag hauj lwm ntawm cov neeg thiab tsum.

8 Khoom Specification thiab Traceability

Lub software tsum yuav tsum kom tswj rau:
– Nyob rau dab tsi ua ntej daim ntawv thiab muab nws raws li
– Nyob rau uas specification nws yog raws li
– Yuav ua li cas kho thiab hloov tau muaj nyob rau hauv uas qhov chaw cov kev pab cuam
– Yuav ua li cas tshwm sim rau txhua teeb meem tsab ntawv ceeb toom
– Los ntawm dab tsi qhov twg los tau ib lub module generated.

9 txheej txheem Control

Sau ua ntaub ntawv txheej txheem rau cov replication txheej txheem nyob rau hauv lub lag luam thiab cov txheej txheem rau tuav ntawm tswv PROMâ € ™ s / cov tsev qiv ntawv. Yuav kom paub meej tias muaj tseeb versioning siv.

Uas tsis yog-conformance
– Tsis muaj ntaub ntawv teev txheej txheem rau replication
– Improper tuav ntawm tswv PROMâ € ™ s los yog diskettes.

10 soj ntsuam thiab kuaj cov

Sau cov txheej txheem rau cov kev soj ntsuam xyuas thiab kev soj ntsuam yuav tsum tau ua nyob rau hauv kev twb kev txuas nrog replication.

Uas tsis yog-conformance
– Muaj nuj nqi ntawm txiav xyuas PROMâ € ™ s tsis tau ntsuam xyuas
– Tsis muaj ntaub ntawv teev txheej txheem rau kev soj ntsuam PROMâ € ™ s.

11 Control ntawm soj ntsuam, Xab thiab Kuaj Cov Khoom

Cov neeg muag khoom yuav tsum xaiv lub uas tsim nyog ntsuas cov cuab yeej siv thiab ua raws li ib tug sau txoj kev tswj cov khoom. Txhua tshiab software version yuav tsum tau mus soj ntsuam rau sufficiency.

12 soj ntsuam thiab Test raws li txoj cai

Specifications thiab cov kev pab cuam yuav tsum qhia tau tseeb los ntawm kev txheeb xyuas thiab kev soj ntsuam. Cov neeg muag khoom yuav tsum muaj cov txheej txheem uas txwv tsis pub siv cov unverified specifications los yog cov kev pab cuam.

13 Control ntawm Non-conforming khoom

Uas tsis yog-conforming khoom yuav tsum tsis txhob siv unintentionally. Ib txoj kev rau tuav ceev kev hloov kho nyob rau hauv cov ntaub ntawv ntawm ib qho tseem ceeb uas tsis yuav tsum tau tsim.

– Clear qhia kom paub txog tej tshuaj yam khoom uas muaj uncorrected uas tsis
– Txoj kev niamtxiv txojkev neeg txais raws li qhov tus me nyuam
– Nyob rau hauv cov ntaub ntawv ceev modifications, nws yuav tsum tau muab sau
– Rov li hloov khoom yuav tsum tsa mus rau tib raws li txoj cai raws li so ntawm software.

14 Corrective thiab Tiv Thaiv Action

yuav tsum muaj:
– Pib tuav ntawm cov ntawv qhia uas tsis hloov mus uas yuav tsum tau
– Pib tuav ntawm cov ntawv qhia qhia luv luv-comings nyob rau hauv txoj kev loj hlob txheej txheem
– Active sau thiab tsom xam ntawm muaj ntaub ntawv hais txog cov khoom thiab cov txheej txheem uas tsis yog-conformance thiab tiv thaiv ua.

Ntaub ntawv hais txog cov teeb meem ces yuav tsum yuav tsum tsav kev txhim kho ntawm txoj kev loj hlob txheej txheem.

Uas tsis yog-conformance
– Neeg tsis txaus siab tsis tau zoo licas
– Deficiency tau pom tab sis tsis kho
– Tsis muaj txoj kev los xyuas kom meej tias cov teeb meem no yog analyzed thiab ua raws li
– Tsis muaj txoj kev qhia txog teeb meem nrog thov kev cai thiab cov txheej txheem.

15 Tuav, Cia, Ntim, Preservation thiab me nyuam

Siv rau software replicated rau Prom uake, disk los yog lwm yam nruab nrab.
Media yuav tsum uas sau tias thiab fej kom raug. Cov ntaub ntawv yuav tsum tau phwj. Muaj yuav tsum yog tus muaj peev xwm mus muab kev tiv thaiv los ntawm nce kev puas tsuaj.

16 Control of Quality Cov ntaub ntawv

Zoo ntaub ntawv qhia uas nqis tes ua tau npaum li cas los xyuas kom meej los yog mus saib zoo. Tus txheem yuav tsum tau kom muaj ib txoj kev tuav ntawm zoo cov ntaub ntawv. Cov ntaub ntawv yuav tsum tau muab cia rau hauv ib tug tsim nyog yam li lawv yog yooj yim mus siv cuag.
Uas tsis yog-conformances:
– Tsis muaj cai rau tuav zoo cov ntaub ntawv
– Review cov ntaub ntawv yog tsis khaws cia
– Test cov ntaub ntawv yog tsis khaws cia
– Sij hawm ntawm kom zoo cov ntaub ntawv tsis txhais

17 Internal Zoo Audits

Yuav tsum muaj kev ywj siab chaw uas tsis tu ncua audits tag nrho cov ua hauj lwm uas yuav cuam tshuam khoom los yog kev pab cuam zoo. Cov no yog ua sawv cev ntawm lub tuam txhab kev tswj. Yuav tsum muaj ib tug txheeb txoj kev npaj.

Uas tsis yog-conformance
– Tsis muaj tshawb txoj kev npaj
– Audit txoj kev npaj tsis mus txog rau hnub tim

18 Kev Cob Qhia

Lub tuam txhab yuav tsum xyuas kom meej tias cov neeg ua haujlwm yog kev kawm rau kev pab raws qib yuav tsum tau. Ib txoj kev mus rau:
– Qhia kev kawm xav tau kev pab rau txhua tus neeg ua hauj lwm txoj hauj lwm
– Muab cov kev kawm
– Khaws cov ntaub ntawv ntawm cov kev cob qhia ntawm tag nrho cov neeg ua hauj lwm.

Kev kawm yuav tsum tau muab sau thiab txaus. By txaus peb txhais hais tias tus neeg muaj peev xwm sawv ntawm kev ua tau zoo nws / nws ua hauj lwm rau ib tug high txaus txheem.

Uas tsis yog-conformance
– Tsis muaj cov txheej txheem rau kev npaj los yog kev kawm
– Tsis muaj kev kawm ntaub ntawv
– Tsis tau txais kev cob qhia rau nws los yog nws ua hauj lwm.

19 kev pab

Tsum yuav tsum sau ntaub ntawv cov txheej txheem rau nyiaj yog tias qhov no yog hais nyob rau hauv daim ntawv cog lus. Nyob rau hauv software nws yog hais txog kev ua yuam kev kho thiab enhancements mus tauj software.

Cov txheej txheem rau tuav kev tsis txaus siab thiab kev thov rau kev hloov kho. Cov neeg muag khoom yuav tsis yuam ua hauj lwm kom muab cov txij nkawm, yog hais tias nws yog tsis hais nyob rau hauv daim ntawv cog lus. Tu cov txheej txheem rau cov laus software yuav tsum tau ua.

Uas tsis yog-conformance
– Tu ua hauj lwm rau ib tug neeg tsis muaj ib tug daim ntawv cog lus
– Kev txoj kev txij nkawm ntawm cov laus cov khoom tsis sau
– Tsis muaj txoj kev rau kev soj ntsuam tom qab txij nkawm.

20 Statistical kev

Yuav tsum muaj sau thiab tsom xam ntawm cov ntaub ntawv hais txog cov xov tooj ntawm uas tsis pom nyob rau hauv qhov sib txawv theem. Ntaub ntawv hais txog tsis muaj peev xwm mus ntsib deadlines thiab milestones yuav tsum tau analyzed.

“————————————————– ————————————————– ————————————————–

Support fordítás:
————————————————– ————————————————– ————————————————–
ISO 9001 Húsz minőségi elemei

A megjelenés kerül sor a követelmények szempontjából fejlesztő vállalatok szoftver. ISO 9001 szabvány célja az volt, hogy a feldolgozóipar. A követelmények értelmezni szoftverfejlesztési ISO 9000-3 és TickIT.

Jelenleg 20 fő elemei. Minden fogalom jól ismert a minőségi menedzsment közösség.

1. A vezetőség felelőssége

1.1 Minőségpolitika

A szabvány előírja, hogy a beszállítók kezelése, hogy adjanak ki minőségi politika, ahol azt mondja a társaság minőségi termékeket.

A minőségpolitika köteles:
– Határozza meg a managementâ € ™ s minőség iránti elkötelezettség
– Határozza meg a Vállalat € ™ s célok minőségét illetően, hogy van, hogy mit jelent a minőség menedzsment
– Releváns a customerâ € ™ s igények
– Kell érteni a szervezet
– Végre kell hajtani


– Nyilatkozat túl homályos vagy politika nem érti személyzet
– Minőségi politika nem hajtották végre.

Például. Minőség politika

â € œWe elérni minőség a motivált és képzett személyzet, meghatározott munkafolyamatok, és intenzív vizsgálat és tesztelés activities.â €

1.2 Szervezet

A szabvány előírja, dokumentálása felelősségét, hatáskörét és kölcsönös személyzet minőségét befolyásoló. Ez azt jelenti, hogy ha egy személy felelőssége, akkor hivatalosan jelöli a megfelelő menedzser. Az a személy, meg kell adni a hatóságnak, hogy teljesítik a felelősséget.

Az ISO, a felelősség azt jelenti:

â € OEA kötelessége fellépni ONEA € ™ s magától, ha valamit meg kell tenni, anélkül, hogy toldâ €.


– Meglévő a felelősség, hogy nem lehet teljesíteni.


– Projekt-line
– Projekt-ügyfél
– Projekt-karbantartó szervezet
– Szoftverfejlesztés-hardver fejlesztés
– A karbantartó szervezet help desk
– Értékesítési-fejlesztés

Erőforrások megkövetelik, hogy a szállító:
– Határozza meg a követelményeknek források
– Rendeljen képzett személyzet.

Management képviselője igényli kijelölését menedzser képviselőt joga és felelőssége:
– Biztosítani kell, hogy a vállalat megfelel a követelményeknek az ISO 9001
– Jelentés a teljesítményt a minőségi rendszer vállalati menedzsment

1.3 Management Review

Quality manager rendszeresen eredményeinek bemutatása
– Minőségi ellenőrzések
– Statisztika minőségi panaszok
– Rekordok a korrekciós intézkedés

Az eredményeket meg kell mutatni a rögzített vezérlő találkozó jegyzeteket, aki részt vett, mi került bemutatásra, és milyen döntések születtek, és készült.

2. Quality System

Minőségi rendszer â € “”â € œThe szervezeti felépítés, felelősségi körök, eljárások, folyamatok és erőforrások minőségirányítás végrehajtásához management.â €

Eljárásokat, szabályokat, döntéseket kell írásba. Ha van egy szabály vagy eljárás, amely nem szükséges az ISO 9001, a standard továbbra is megköveteli, hogy meg van írva.

A minőségi kézikönyv tartalmazza referencia és dokumentálása a minőségbiztosítási rendszert.


– Az ellenőrzés egy példa, tehát ha egy mintában, vannak kisebb eltéréseire, és ezek fix, akkor még egy nem-megfelelőség, mert a könyvvizsgáló azt gyanítják, hogy van még sok kisebb eltéréseire.
– Meglévő írásos eljárásokat nem tartják be.

3. A szerződés felülvizsgálata

A szállító előtti ellenőrzések aláírása szerződés, hogy a szervezet képes legyen elvégezni, mire van szükség a szerződés.

Kérdés, hogy meg kell kérni a következők:
– A követelmények dokumentált és érteni?
– Az elfogadás kritériumai szerepelnek?
– Van követelmények különböznek a tender megoldódott?
– Tud-e a szállító gyülekező elég erőforrás a szerződést?
– Tud-e a szállító gyülekező hatáskörébe szükséges a szerződést?
– Tud-e a feladat befejeződik az időben?

A szabvány előírja, hogy dokumentált eljárás vélemény tartalmazza. A szolgáltatónak meg kell azonosítani, hogy szerződés módosítását és kezelése követelmények meghatározása az ügyfél és a szállító határozza meg.

4. Tervezési vezérlés

4.1. Tábornok
ISO megköveteli, hogy azt tervezi, mielőtt csinál, és adja tervezése előtt.

4.2. Tervezés és fejlesztés tervezése

Tervezés tervnek tartalmaznia kell:
– Meghatározása használandó módszertan fejlesztésében termék
– A határidők, felelősségi körök, munkahelyi feladatok és haladás ellenőrzése
– Fázisai projekt lesz osztva. Ez magában foglalja a bemeneti, kimeneti és ellenőrzése kimenet.
– Leírás módszereket és eszközöket kell használni

Minőségi tervnek tartalmaznia kell:
– Minőségi célok
– Szempontok az elfogadhatóság
– Azonosítása tervezés, validálás.
– Kötelezettségek minőségi tevékenységét.

Ha egy cég meg akarja szerezni ISO minősítés a terveket meg kell tartani az összes projekt, hiszen az ISO minősítés az egész társaság, és nem az egyes projektek.

4.3 Szervezeti és műszaki interfészek

Ha van csoportos munka, a felületek között meg kell határozni, dokumentálni és továbbítják azokat igénylő az adatokat. A dokumentáció rendszeresen felül kell vizsgálni.

4.4 Tervezés Input

Követelmények előírásokat tartalmaz a tervezési input a szoftverfejlesztés. Ez történhet a vásárló vagy készített a szállító által a törvények és rendeletek. Egy másik tervezési input: a tervezés kódolást használnak bemeneti kódolás.

A szabvány azt akarja, hogy biztosítsa, hogy a munka termék minden egyes lépés megfelel a követelményeknek.

Szoftverfejlesztés, beálló változások gyakoriak, így a kezelési eljárását az új és megváltozott követelmények a vásárló létre.

4.5 Tervezés kimenet

Tervezés Output: a tervdokumentációt és a forráskódot. ISO megköveteli, hogy a tervezési dokumentumok és kódolás előtt felül kell vizsgálni kiadás.

Eljárást elfogadásának tervezett teljesítményen és átvételi kritériumok kell létrehozni.

4.6 Design Review

Project funkciók, mint a kódolás és tesztelés be kell mutatni a felülvizsgálat. A közös módszer annak biztosítására értékelések listák.

4.7 Tervellenőrzés

Ez áll véleménye, modul tesztelés és integrációs tesztelés.

4.8 tervelemző

Végső rendszer teszt, a teljes szoftver termék együtt átnézését felhasználói dokumentáció. Ott kell tervezni és dokumentálni érvényesítés. Béta tesztelés összhangban legyen az ISO, amíg a béta tesztelés borítja egyértelmű megállapodás a szállító és a béta-tesztelés ügyfél.

4.9 Tervezési változtatások

ISO 9001 megköveteli, hogy a kiadása után tervdokumentáció vagy forrás, minden változtatás kell átmenni a hivatalos eljárás, ahol a változások dokumentálása, áttekintette és jóváhagyta a végrehajtás előtt.

Ellenőrizetlen módosítások a komplex műszaki dokumentumok vagy programok rendkívül veszélyes, és mint ilyen, a szabvány nem teszi lehetővé.
5. Dokumentum és Data Control

Információ, amely ellenőrzi a fejlesztés / karbantartása. A szabvány előírja, hogy azok, akik szükség van néhány dokumentum / adatok férhetnek hozzá. Változások a dokumentumokat és adatokat kell ellenőrizni.

5.1 Általános

Külső dokumentumok és adatok kell tárolni. Meg lehet tárolni bármilyen formában (nyomtatott, elektronikus média).

5.2 A dokumentum és adat jóváhagyása és a probléma

Mielőtt kérdés dokumentumok és adatok felül kell vizsgálni és jóvá, mielőtt minden probléma. A dokumentumok listája, amelyekben az egyik kell kideríteni az aktuális verzió a dokumentumot. Érvénytelen vagy elavult dokumentumokat kell távolítani, vagy egyértelműen jelölni kell.

5.3 A dokumentum és az adatok változása

Az a személy / ek felelős a felülvizsgálati és jóváhagyási eljárás meg kell határozni.

6. Purchasing

Abban az esetben, alvállalkozó, akkor még felelős. Azaz. Ha Ön egy szerződést, és alvállalkozói munkát, ISO szabványok még az Ön felelőssége és az ISO követelmények nem kell kiszabni az alvállalkozó.

6.1 Általános

Ha munkaerőt vásárol, a szabvány előírja, hogy olyan eljárást kövessen, hogy a megfelelő embereket. Az emberek fogják ellenőrizni a szállító és nem alvállalkozója.
Annak biztosítása érdekében, hogy a megvásárolt szoftver megfelel a követelményeknek:
– A szerződés követelményeinek az alvállalkozók eljárások
– Audit az alvállalkozó minőségbiztosítási rendszer
– Ellenőrizze alvállalkozó múltbeli teljesítmény
– Felmérés az alvállalkozó alatt szerződést
– Tanú felülvizsgálata és tesztelése
– Test és felülvizsgálata terméke alvállalkozó.

6.2 Értékelés alvállalkozók

Személy szükséges hatáskörrel és illetékességgel ítéljen egyes alvállalkozó, és eldönti, hogy használja-e. A döntéseket dokumentálni kell.

A szállító köteles eldönteni, hogy mi felett alvállalkozó ez lesz. A szabvány nem beszélve, hogy mennyi ellenőrzés akkor kellett volna. Ez csak megemlíti, hogy döntést kell hozni felhasználásával tényeket.

Egy speciális eset, amikor szoftvert vásárolt kiskereskedelem. Ebben az esetben az alvállalkozó szervezet, ahol a vásárlást végzik, nem az eredeti fejlesztő a szoftver.

Ha beszerzési keresztül történik kiskereskedelmi ISO 9001 megköveteli, hogy meghatározzák, hogy milyen mértékben tesz követelményeket a kiskereskedő, hogy ellenőrizzék a szállító.

6.3 Beszerzési adatok

Követelmények a fejlesztési folyamat dokumentálni kell a szerződésben, valamint a szállító követelményeknek jóváhagyására munka eredményeit és eljárásokat.

6.4 Vásárolt termék jóváhagyása

Dokumentálása döntések ellenőrzésének minden megvásárolt fejlesztő eszköz vagy benne termék.

– Nem listát a jóváhagyott szállítók
– Nem megfelelő ellenőrzése alvállalkozó
– Nem dokumentum ellenőrzése vásárolt tételek
– Nem megfelelő szerződést alvállalkozót.

7 vezérlése Ügyfél által szállított termék

A szállító eljárásokkal kell rendelkeznie az ellenőrzés, tárolása és kezelése az ügyfél mellékelt szoftver segítségével. Azonban a minőség a felelőssége a szoftver.

A nem-megfelelőség történik miatt tisztázatlan felelősségi felelősség az ügyfél és a szolgáltató.

8. A termék műszaki és nyomonkövetés

A szoftver szállítója kell kontrollálni:
– Milyen megelőző dokumentum és kiadja az alapjául
– Melyik leírás annak alapjául
– Mi korrekciók és módosításokat tartalmazza, amelyben forráskódú programok
– Mi történt az egyes probléma-jelentést
– Abból, amit forrás egy adott modul által generált.

9 Process Control

Dokumentált eljárás a replikációs folyamat működésének és eljárásának kezelése mester Proma € ™ s / könyvtárakban. Annak érdekében, hogy a helyes verzióképzés használják.

– Nem dokumentált eljárást replikáció
– Nem megfelelő kezelése mester Proma € ™ s vagy lemezeket.

10. Ellenőrzés és tesztelés

Írásbeli eljárások vizsgálata és vizsgálatot kell végezni kapcsolatban replikáció.

– Funkciója automatikusan ellenőrzi Proma € ™ s nem estek át ellenőrzésen
– Nem dokumentált vizsgálati eljárása Proma € ™ s.

11 vezérlése Ellenőrzés, mérő és vizsgáló berendezések

A szállító válassza ki a megfelelő mérőberendezést és kövesse dokumentált eljárást ellenőrző berendezések. Minden új szoftver verzió kell vizsgálni elégséges.

12. Ellenőrzés és teszt állapota

A műszaki adatok és programok ellenőrizhetők vélemény és a tesztelés. A szállító eljárásokkal kell rendelkeznie, hogy megtiltsa ellenőrizetlen leírások vagy programokat.

13 vezérlése nem megfelelő termék

A nem megfelelő termékek nem használhatók véletlenül. A kezelési eljárását gyors változtatások esetén kritikus hibák kell létrehozni.

– Pontos meghatározása az ellenőrzött termékek, amelyek nem javított hibák
– A módszer kiváltására ügyfél elfogadási átvételkor
– Abban az esetben, gyors módosítások azt kell dokumentálni
– Áttekintve így módosított elem kerül emelkedett jogállása megegyezik többi szoftver.

14 helyesbítő és megelőző tevékenység

– Hatékony kezelése jelentések nem felel meg a követelményeknek
– Hatékony kezelése készített jelentések hiányosságai a fejlesztési folyamatban
– Aktív gyűjtése és elemzése a rendelkezésre álló információkat a termék és folyamat nem megfelelőség és a megelőző intézkedéseket.

Információ felmerült problémák kellene vezetni javulást a fejlesztési folyamatot.

– Reklamáció nem megfelelően kezelik
– Hiányosságot észleltek, de nem javított
– Nem eljárást, amely biztosítja, hogy a problémák azok alapján
– Nem bejelentésére irányuló eljárást nehézségek alkalmazása szabályokat és eljárásokat.

15 Kezelés, tárolás, csomagolás, megőrzés és szállítás

Vonatkozik szoftver megismétlődik PROM, lemezen vagy más adathordozón.
Média kell címkézni és csomagolni rendesen. Adatokat kell alátámasztani. Ott is kell a képességét, hogy védelmet nyújtson a véletlen sérülésektől.

16. minőségének ellenőrzése Records

Minőségi dokumentumok azt mutatják, hogy mely intézkedéseket hoztak annak biztosítására, vagy a minőség ellenőrzése. A szabvány előírja, hogy van-e olyan kezelési eljárását a minőségi nyilvántartás. A feljegyzések kell tárolni a megfelelő módon, így azok könnyen hozzáférhetők.
– Nem szabályok megtartását minőségi nyilvántartás
– Felül feljegyzéseket nem
– Teszt feljegyzéseket nem
– Időszak vezetése minőségi nyilvántartás nincs meghatározva

17 Belső minőségügyi auditok

Ott kell lennie egy független szervezet, amely rendszeresen auditálja az összes műveletet, amely hatással lehet a termék vagy szolgáltatás minőségét. Ezek nevében végzett vállalat irányítását. Ott kell lennie egy ellenőrzési tervet.

– Nem ellenőrzési terv
– Ellenőrzési terv nem naprakész

18 Képzés

Társaságnak biztosítania kell, hogy a személyzet képzett előírt feladatokat. Olyan eljárás:
– A képzési szükségletek meghatározására az egyes alkalmazottak helyzetét
– Ilyen oktatást
– Nyilvántartást vezet a képzés valamennyi alkalmazott.

Képzési dokumentálni kell, és elegendő. Azáltal, elegendő azt értjük, hogy az a személy, képesnek kell lenniük a saját / munkáját, hogy elég magas szabvány.

– Nem tervezésére szolgáló eljárások vagy képzési
– Nem képzési nyilvántartást
– Nem kapott megfelelő képzést ő feladata.

19 szerviz

Szállító köteles dokumentált karbantartási eljárások, amennyiben ez szerepel a szerződésben. Ezen szoftver van szó hibajavítások és fejlesztések leszállított szoftver.

Eljárások a panaszok kezelése és kérelmek módosításokat. A szállító nem köteles a karbantartás, ha nem említi szerződést. Karbantartási műveleteket régi szoftvert kell tenni.

– Karbantartási munkák egy ügyfél szerződés nélkül
– Speciális fenntartásának módszerei régi termék nem dokumentált
– Nincs eljárás után végzett karbantartás.

20 Statisztikai módszerek

Ott kell lennie gyűjtését és elemzését adatokat talált hibák száma a különböző fázisokban. Információ képtelen határidők és mérföldkövek elemezni kell.

“————————————————– ————————————————– ————————————————–

Stuðningur þýðing:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty Quality Elements

A líta verður tekin á kröfum frá sjónarhóli fyrirtækja þróa hugbúnað. ISO 9001 staðallinn var ætlað fyrir framleiðsluiðnaði. Kröfurnar eru túlkuð fyrir þróun hugbúnaðar í samræmi við ISO 9000-3 og TickIT.

Það eru 20 helstu atriði. Hver hugtak er vel þekkt í gæðastjórnun samfélaginu.

1. Stjórn Ábyrgð

1.1 Gæðastefna

The staðall krefst birgir stjórnun að gefa út góða stefnu, þar sem það segir að félagið skuli framleiða gæðavöru.

The gæði stefnu skal:
– Skilgreina skuldbindingu stjórnenda € ™ s við gæði
– Skilgreina markmið fà © lagsins um gæði, það er, hvað stjórnun þýðir af gæðum
– Vertu viðeigandi að þörfum ° vià ° s
– Að skilja í skipulagningu
– Koma til framkvæmda


– Yfirlýsing of óljós eða stefna er ekki skilið eftir starfsfólki
– Gæðastefna er ekki útfærð.

T.d. af Quality stefnu

â € œVià ná gæðum í gegnum áhugasama og hæft starfsfólk, sem skilgreind verkferlana og ákafur endurskoðun og prófa Starfshættir €

1.2 Skipulag

Staðallinn kröfu gögn um ábyrgð, vald og samspili allra starfsmanna sem hafa áhrif á gæði. Þetta þýðir að ef maður hefur ábyrgð, skal formlega úthlutað með viðeigandi stjórnanda. Sá sem ætti að hafa vald til að uppfylla ábyrgð.

Samkvæmt ISO, ábyrgð þýðir:

â € OEA skylda til að bregðast við oneâ € ™ s eigin hvötum þegar eitthvað þarf að gera án þess að vera toldâ €.


– Núverandi á ábyrgð sem ekki er hægt fullnægt.


– Project-lína
– Project-viðskiptavina
– Project-viðhaldsfyrirtæki
– Hugbúnaðarþróun-vélbúnaður þróun
– Viðhald organization-Help Desk
– Sölu-þróun

Resources krefjast þess að birgir:
– Þekkja kröfur um auðlindir
– Velja þjálfað starfsfólk.

Stjórn fulltrúi krefst skipun stjórnanda fulltrúa með valdi og ábyrgð til:
– Tryggja að fyrirtækið uppfylli kröfur í ISO 9001
– Tilkynna árangur gæðakerfisins til stjórnenda fyrirtækisins

1.3 Stjórnun Review

Gæðastjóri skal reglulega kynna niðurstöður
– Gæði úttektir
– Tölfræði um gæði kvartanir
– Skrár yfir úrbætur

Niðurstöðurnar skulu settar fram á skrá stjórnun fundi með skýringum á sem sóttu, hvað var kynnt og hvaða ákvarðanir voru teknar og gerðar.

2. Quality System

Gæðakerfi â € “”â € Å skipulagi, ábyrgð, verklag, aðferðir og úrræði fyrir framkvæmd gæði management.â €

Verklagsreglur, reglur, ákvarðanir skal setja í að skrifa. Ef þú ert með reglu eða aðferð sem er ekki krafist af ISO 9001 staðallinn kröfu samt að það er skrifað.

Gæðahandbók skal innihalda tilvísun og gögn um gæðakerfið.


– Endurskoðun er sýnishorn, því ef í sýni, eru minniháttar non-conformances, og þeir eru fastir, það geta enn vera a non-Samræmi því endurskoðandi getur grunar að það eru margir fleiri minniháttar non-conformances.
– Núverandi skrifað aðferðir eru ekki heiðrað.

3. Samningur Review

Birgir eftirlit áður en að undirrita samning um að stofnunin geti sinnt hvað er krafist af samningi.

Spurningar sem við ættum að spyrja eru:
– Eru kröfurnar skjalfest og skilið?
– Eru staðfestingu viðmið innifalið?
– Hefur kröfur ólíkar útboðs verið leyst?
– Getur birgir stefna nóg fjármagn til samningsins?
– Getur birgir stefna færni sem þarf fyrir samningnum?
– Getur verkefni að vera lokið í tíma?

Staðallinn krefst þess að skjalfesta aðferð með umsögnum vera með. Þjónustuveitandi skal skilgreina hvernig samning breytingar og meðhöndlun kröfur forskrift milli viðskiptavinar og söluaðila að vera skilgreind.

4. Hönnun Control

4,1. almennt
ISO krefst þess að þú ætlar áður að gera og tilgreina áður en að hanna.

4.2. Hönnun og þróun Planning

Hönnun áætlun ætti að innihalda:
– Skilgreining á aðferðafræði sem notuð er í þróun vöru
– Tími báta, ábyrgð, vinna verkefni og framfarir eftirlit
– Stig verkefnið verður skipt. Þetta felur í sér inntak, úttak og sannprófun á framleiðslu.
– Lýsing á aðferðum og tækjum til að nota

Gæði áætlun ætti að innihalda:
– Gæði markmið
– Viðmið fyrir viðurkenningu
– Greining á áætlanagerð, fullgildingu og sannprófun.
– Ábyrgð starfsemi gæða.

Ef fyrirtæki vill fá ISO hæfi áætlanir verður haldin í öllum verkefnum, þar ISO vottun er fyrir alla fyrirtæki og ekki fyrir ákveðin verkefni.

4.3 skipulags- og tæknilegra Tengi

Ef það er hópur að vinna, en tengi á milli þeirra ætti að vera skilgreind, skjalfest og send til þeirra sem þarfnast upplýsingarnar. Skjölin skulu endurskoðaðar reglulega.

4.4 Hönnun Input

Kröfur upplýsingar innihalda hönnun inntak í þróun hugbúnaðar. Þetta má gera með því að kaupanda eða unnin af birgi með lögum og reglugerðum. Annar hönnun inntak felur í sér hönnun kóðun sem er notað sem inntak í erfðaskrá.

Hið staðlaða vill tryggja að vinna afurð hverju skrefi uppfylli kröfur.

Í hugbúnaðarþróun, eru krafa breytingar algeng svo aðferð til að meðhöndla nýjar og breyttar kröfur frá kaupanda verða búið.

4.5 Hönnun Output

Hönnun Output: hönnunargögn og kóðinn. ISO krefst þess að hönnun skjöl og kóðun endurskoðuð fyrir útgáfu.

A aðferð til staðfestingar á hönnun framleiðslu og viðmiðunum staðfestingu ætti að vera búið.

4.6 Hönnun Review

Project virka eins forritun og prófun skal kynnt á endurskoðun. Algeng aðferð til að tryggja dóma eru gátlistar.

4.7 Hönnun Staðfesting

Þetta samanstendur af umsögnum, mát prófanir og sameining próf.

4.8 Hönnun Validation

Final kerfi próf, af heill hugbúnaður vara ásamt endurskoðun á notendabæklingnum. Það ætti að vera skipulögð og skjalfest staðfesting. Beta prófanir eru í samræmi við ISO svo lengi sem beta prófun er fjallað með skýrum samkomulagi birgis og beta-prófun viðskiptavini.

4.9 Hönnun Breytingar

ISO 9001 krefst þess að eftir útgáfu gagna hönnun eða uppruna, allar breytingar skulu fara í gegnum formlegt ferli þar sem breytingar eru skjalfest, yfirfarin og samþykkt áður en framkvæmd.

Ósjálfráðar breytingar á flóknum tæknilegum skjölum eða forrit er mjög hættulegt og sem slík the staðall leyfir það ekki.
5. Document og Data Control

Upplýsingar sem stýrir þróun / viðhald hugbúnaðar. Staðallinn krefst þess að þeir sem þurfa sumir skjal / gögn skulu hafa aðgang að henni. Breytingar á skjölum og gögnum skal stjórnað.

5.1 Almennt

Ytri skjöl og gögn skulu geymd. Það er hægt að geyma á hvaða formi (útskrift, rafræn fjölmiðla).

5.2 Skjal og Data Samþykki og Issue

Áður gefa út skjöl og gögn skulu yfirfarnar og samþykktar fyrir hverja útgáfu. Skjal Listi þar sem einn skal finna út núverandi útgáfu af skjalinu. Ógildur eða úrelt skjöl ætti að fjarlægja eða greinilega merkt.

5.3 Skjal og Data Breytingar

Sá sem / s í umsjá endurskoðun og samþykki aðferð skal tilgreint.

6. Purchasing

Í tilviki undirverktaka, þú ert enn ábyrgur. Þ.e.a.s. ef þú sækir um samning og undirverktaka vinna, ISO staðla er enn undir þinni ábyrgð og ISO kröfur þurfa ekki að vera lögð á undirverktaka.

6.1 Almennt

Ef mannafla er keypt, staðall krefst þess að þú að fylgja aðferð sem þú færð rétta fólkið. Fólkið verður stjórnað af birgir og ekki undirverktaka.
Til að tryggja að keypt hugbúnað í samræmi við kröfur:
– Samningur kröfur um undirverktaka málsmeðferð
– Endurskoðun á undirverktaki gæðakerfisins
– Athuga undirverktaki framhjá frammistöðu
– Könnun á undirverktaka meðan samningur
– Witness endurskoðun og prófanir
– Próf og endurskoðun vara undirverktaka.

6.2 Mat á undirverktaka

Einstaklingur með nauðsynlegum valdi og hæfni skal dæma hvert undirverktaka og ákveða hvort að nota. Ákvarðanirnar skulu skjalfestar.

Þjónustuveitandi skal ákveða hvaða stjórn yfir undirverktaka það mun hafa. Í staðlinum er ekki minnst á hversu mikla stjórn þú ættir að hafa. Það nefnir bara að ákvörðun ætti að vera gert með því að nota staðreyndir.

Sérstök tilfelli er þegar hugbúnaður er keyptur í gegnum smásölu. Í þessu tilfelli undirverktaki er stofnun sem kaupin fara fram, ekki upprunalega verktaki af the hugbúnaður.

Ef innkaup er gert í gegnum smásölu ISO 9001 krefst þess að þú skilgreinir að hve miklu leyti þú setur kröfur á söluaðila til að stjórna birgir hennar.

6.3 Innkaup Gögn

Kröfur á þróunarferli skal skjalfesta á samningnum ásamt kröfum birgir að samþykkja vinnu niðurstöður og aðferðir.

6.4 Staðfesting á keypta vöru

Gögn um ákvarðanir um sannprófun hvert keypt þróun tól eða innifalinn vöru.

– Nei lista yfir viðurkenndar birgja
– Óviðeigandi stjórn undirverktaka
– Nei skjal staðfesta innkaup items
– Óviðeigandi samning við undirverktaka.

7 Control Viðskiptavinur-staðar Vara

Birgir skal hafa aðferðir við sannprófun, geymslu og viðhald viðskiptavina fylgir hugbúnaði. Hins vegar er gæði er ábyrgð á hugbúnaði.

A non-Samræmi gerist vegna óljós ábyrgð ábyrgð milli viðskiptavinar og birgi.

8 Vara Specification og Rekjanleiki

Hugbúnaðurinn birgir skal halda stjórn á:
– Á hvaða undan skjali og gefa það byggir
– Á hvaða forskrift og það er byggt
– Hvað leiðréttingar og breytingar hafa verið með í sem fengið forrit
– Hvað varð um hvert vandamál skýrslu
– Frá því uppspretta var sérstakur mát mynda.

9 Process Control

Skjalfest aðferð til afritunar aðferð í rekstri og málsmeðferð fyrir meðferð húsbónda PROMA € ™ s / bókasöfnum. Til að tryggja að réttar versioning er notað.

– Nei skjalfest aðferð til afritunar
– Röng meðhöndlun húsbónda PROMA € ™ s eða disklingum.

10 Skoðun og prófun

Skriflegar verklagsreglur um skoðun og prófun að vera í tengslum við eftirmyndun.

– Virkni stöðva sjálfkrafa PROMA € ™ s hefur ekki verið skoðaður
– Nei skjalfest aðferð til að prófa PROMA € ™ s.

11 Eftirlit með Skoðun, mæla og Test Equipment

Þjónustuveitandi skal velja viðeigandi mælitækjum og fylgja skjalfestum verklagsreglum um eftirlit búnaðar. Hver nýr hugbúnaður ætti að prófa fyrir sjálfbærni.

12 Skoðun og Próf Status

Forskriftir og forrit ætti staðfest í gegnum dóma og prófanir. Birgir skal hafa aðferðir sem banna notkun óstaðfest upplýsingar eða forrit.

13 Eftirlit með ekki samræmast Vara

Ekki samræmast vörur ætti ekki að nota í ógáti. Aðferð til að meðhöndla fljótur breytingar ef mikilvægum villur ætti að vera búið.

– Hreinsa auðkenning stjórnað hlutum sem innihalda óleiðréttar villur
– Aðferð til að framkalla móttöku viðskiptavina við afhendingu
– Í tilviki fljótur breytingar, verður það að vera skjalfest
– Skoðun svo breytt atriði verður upphækkaður til sömu stöðu og restina af hugbúnaði.

14 úrbætur og fyrirbyggjandi aðgerðir

– Árangursrík meðhöndlun skýrslur sem eru ekki í samræmi við kröfur
– Árangursrík meðhöndlun tilkynninga til kynna stutt-comings í þróunarferli
– Virk söfnun og greining fyrirliggjandi upplýsingar um vöru og ferli non-samræmi og fyrirbyggjandi aðgerðir.

Upplýsingar um vandamál sem upp koma ætti að reka endurbætur á þróunarferli.

– Viðskiptavinur kvörtun hafi ekki verið rétt meðhöndluð
– Skortur hefur fundist en ekki leiðrétt
– Nei aðferð til að tryggja að vandamál eru greind og brugðist við
– Nei aðferð til að tilkynna erfiðleikum með að beita reglum og málsmeðferð.

15 Meðhöndlun, geymsla, pökkun, varðveisla og afhending

Gildir til hugbúnaður endurtaka á PROM, disk eða öðrum miðli.
Media skal merkt og pakkað rétt. Gögn skulu studdur. Það ætti einnig að vera hæfni til að veita vörn gegn óviljandi skaða.

16 Eftirlit með Gæði Records

Gæði skjöl sýna hvaða aðgerðir hafa verið gerðar til að tryggja eða athuga gæði. Staðallinn krefst þess að það að vera aðferð til að meðhöndla á gæðum gagna. Skrárnar skal geyma á viðeigandi hátt þannig að þeir eru auðveldlega aðgengileg.
– Engar reglur um varðveislu á gæðum gagna
– Review færslur eru ekki haldið
– Próf færslur eru ekki haldið
– Gildistími halda um gæði er ekki skilgreint

17 Innri gæðaúttektir

Það ætti að vera sjálfstæð eining, sem reglulega úttektir allar aðgerðir sem geta haft áhrif á vöru eða þjónustu gæði. Þetta eru unnin var á vegum stjórnenda fyrirtækisins. Það ætti að vera endurskoðun áætlun.

– Nei endurskoðun áætlun
– Endurskoðun áætlun ekki upp til dagsetning

18 Þjálfun

Félaginu ber að sjá til þess að starfsfólk er þjálfað fyrir verkefni sem þarf. A aðferð til:
– Greina þörf fyrir hvers starfsmanns stöðu
– Veita slíka þjálfun
– Halda skrár yfir þjálfun allra starfsmanna.

Þjálfun ætti að vera skjalfest og fullnægjandi. Með nóg er átt við að einstaklingur að vera fær um að framkvæma hans / verk hennar til nógu hátt staðli.

– Engar verklagsreglur skipulagningu eða þjálfun
– Engin þjálfun skrár
– Ekki fékk rétta þjálfun fyrir verkefni sitt.

19 Viðhald

Birgir skal hafa skjalfestar verklagsreglur fyrir þjónustu ef hún er getið í samningnum. Í hugbúnaði það er um villu leiðréttingar og viðbætur við afhent hugbúnaði.

Verklagsreglur um meðhöndlun kvartana og beiðnir um breytingar. Birgir er ekki skylt að veita viðhald ef það er ekki getið í samningi. Viðhald málsmeðferð fyrir gamla hugbúnaður skal.

– Viðhald vinna fyrir viðskiptavin án samnings
– Sértækar aðferðir til að viðhalda gamla vöru er ekki skráð
– Nei aðferð til að prófa eftir viðhald.

20 Tölfræðilegar aðferðir

Það ætti að vera söfnun og greining gagna um fjölda villur finnast í mismunandi áföngum. Upplýsingar um vanhæfni til að mæta tímamörkum og áfangar skal greina.

“————————————————– ————————————————– ————————————————–

Nkwado translation:
————————————————– ————————————————– ————————————————–
ISO 9001 iri abụọ Quality Ihe

A anya ga-anara na ihe ndị a chọrọ si ele ihe anya nke ụlọ ọrụ ndị na-emepe emepe software. ISO 9001 ọkọlọtọ e zubere maka n’ichepụta ụlọ ọrụ. Ndị a chọrọ na-kọrọ isi nrọ software mmepe dị na ISO 9000-3 na TickIT.

E nwere 20 Isi ọcha. Onye ọ bụla echiche a maara nke ọma na àgwà management obodo.

1. Management Ibu Ọrụ

1.1 Quality iwu

Ọkọlọtọ na-achọ na soplaya management inye a mma iwu, ebe ọ na-ekwu na ụlọ ọrụ ga na-emepụta àgwà ngwaahịa.

The àgwà iwu ga-:
– Kọwaa ihe managementâ € ™ s nkwa na-edu
– Kọwaa ihe companyâ € ™ s ebumnobi banyere àgwà, ya bụ, ihe management pụtara site àgwà
– Nwee mkpa ka customerâ € ™ s mkpa
– Ike Ịghọta na nzukọ
–Emejuputa atumatu


– Nkwupụta kwa-edochaghị anya ma ọ bụ iwu na-adịghị aghọta site mkpara
– Quality iwu na-adịghị emejuputa atumatu.

E.g. nke Quality iwu

a € œWe nweta àgwà site mkpali, ọkà mkpara, kọwaa ọrụ usoro, na ọzụzụ kpụ ọkụ n’ọnụ review na-anwale activities.â €

1.2 Organization

Ọkọlọtọ na-achọ akwụkwọ nke ibu ọrụ, ikike na interrelation niile pesonel na-emetụta àgwà. Nke a pụtara na ọ bụrụ na mmadụ nwere ibu ọrụ, ọ ga-chie kenyere ọrụ kwesịrị ekwesị faili. Onye kwesịrị inwe ikike nke imezu ibu ọrụ.

Dị ka ISO, ibu ọrụ pụtara:

a € œa ọrụ iji mee oneâ € ™ s aka mgbe ihe a ga-eme n’achọghị toldâ €.


– Dịnụ nke a ibu ọrụ a na-apụghị imezu.


– Project-akara
– Project-ahịa
– Project-arụzi nzukọ
– Software development-ngwaike development
– Mmezi nzukọ-enyemaka Oche
– Sales-development

Resources ịchọ ka ndị soplaya:
– Chọpụta ndị a chọrọ maka ego
– Kenye zụrụ azụ pesonel.

Management nnọchiteanya na-achọ nhọpụta nke manager nnọchiteanya ji ikike na ibu ọrụ nke:
– Gbaa mbọ hụ na ụlọ ọrụ na-emezu ihe ndị a chọrọ na akanye 9001
– Kọọrọnụ arụmọrụ nke àgwà usoro ụlọ ọrụ management

1.3 Management Review

Quality manager kwesịrị oge chee na ihe
– Quality audits
– Statistics nke àgwà mkpesa
– Records nke edozi edinam

The results kwesịrị isi na-na a dere management nzukọ na ndetu on onye gara, ihe e gosiri na ihe mkpebi e weere na mere.

2. Quality System

Quality usoro a € “”a € œthe nzukọ Ọdịdị, ibu ọrụ, na usoro, Filiks na ego maka mmejuputa àgwà management.â €

Usoro, iwu, mkpebi a ga-dee ede. Ọ bụrụ na ị nwere a na-achị ma ọ bụ usoro na-adịghị achọrọ site akanye 9001, ọkọlọtọ ka na-achọ ka e dere.

A àgwà ntuziaka ga-ebu akwụkwọ na akwụkwọ nke àgwà usoro.


– An oditi bụ a sample, ya mere ọ bụrụ na a sample, e nwere obere ihe na-abụghị conformances, ha na ofu, ọ ka nwere ike ịbụ ndị na-abụghị conformance n’ihi na auditor nwere ike ichewe na e nwere ọtụtụ ihe obere na-abụghị conformances.
– Existing dere usoro na-agbasoghị.

3. nsuko Review

The soplaya ndenye ego tupu bịanyere aka n’akwụkwọ nkwado nkwekọrịta na nzukọ-enwe ike ịrụ ihe ndị achọrọ site nkwekọrịta.

Ajụjụ na a ga-jụrụ na-agụnye:
– Ndi ihe ndị a chọrọ akwukwo na-aghọta?
– Ndi nabata ibiere gụnyere?
– Ndi chọrọ dị iche iche si dị nro e kpebiri?
– Nwere ike na soplaya ịkata zuru ezu ego maka nkwekọrịta?
– Nwere ike na soplaya ịkata ndị ma arụ ọrụ dị mkpa maka nkwekọrịta?
– Nwere ike ọrụ ga-agwụ agwụ n’ime oge?

Ọkọlọtọ na-achọ na a akwukwo usoro na reviews-gụnyere. The soplaya kwesịrị ịmata otú nkwekọrịta mmegharị na njikwa nke chọrọ nkọwapụta n’etiti ndị ahịa na soplaya ike kọwaa.

4. Design Control

4.1. General
ISO na-achọ ka ị na-ahazi tupu eme na-dee tupu emebe.

4.2. Kere na Development Planning

Design plan kwesịrị ịnwe:
– Akowa nke ụkpụrụ a ga-eji mmepe nke ngwaahịa
– Time schedules, ibu ọrụ, ọrụ e kenyere na ọganihu akara
– N’ụzọ oru ngo a ga-ekewa. Nke a na-agụnye ndenye, mmepụta na nkwenye nke mmepụta.
– Nkowasi ụzọ na ngwaọrụ na-eji

Quality plan kwesịrị ịnwe:
– Quality zaa
– Ibiere maka anabata na
– Identification nke atụmatụ, nkwado na nkwenye.
– Ibu Ọrụ maka àgwà eme ihe.

Ọ bụrụ na a ụlọ ọrụ chọrọ iji nweta ISO asambodo o atụmatụ a ga-enwe na ihe niile oru ngo, ebe ọ bụ na ISO asambodo bụ maka dum ụlọ ọrụ na-adịghị maka ụfọdụ oru ngo.

4.3 Nhazi na nka na ụzụ ihu

Ọ bụrụ na e ìgwè ahụ-arụ ọrụ, ndị ihu n’etiti ha ga-amata, akwukwo-ebute site ná ndị nwere mkpa ndị ọmụma. The akwụkwọ a ga-enyocha mgbe niile.

4.4 Design Input

Chọrọ nkọwa nwere imewe input na software mmepe. Enwere ike ịme site purchaser ma ọ kwadebere site soplaya iji iwu na ụkpụrụ. Ọzọ imewe input agụnye imewe nzuzo nke a na-eji dị ka ọsọ ọsọ ka nzuzo.

The ọkọlọtọ chọrọ iji hụ na ọrụ ngwaahịa nke onye ọ bụla nzọụkwụ-emezu ihe ndị a chọrọ.

Na software mmepe, chọrọ mgbanwe ndị nkịtị otú a usoro maka na-ejizi ọhụrụ na gbanwere agbanwe chọrọ si purchaser-kere.

4.5 Design Mmepụta

Design mmepụta: imewe akwụkwọ na ndị isi koodu. ISO na-achọ ka imewe akwụkwọ na nzuzo-enyocha n’ihu tọhapụ.

A usoro maka nnabata nke imewe mmepụta na ibiere nke nabata ga-kere.

4.6 Design Review

Project ọrụ dị ka nzuzo na ule a ga-adade ke nyochaa. A usoro maka huu reviews bụ checklists.

4.7 Design nkwenye

Nke a mejupụtara reviews, modul ule na mwekota ule.

4.8 Design ọnọdụ Office

Final usoro ule, nke zuru ezu software ngwaahịa ọnụ na akafiakde ese nke onye ọrụ akwụkwọ. E kwesịrị zubere na akwukwo nkwado. Beta ule dị conformance na ISO ka anya dị ka beta ule kpuchiri a doro anya na nkwekọrịta n’etiti soplaya na beta-ule ahịa.

4.9 Design Mgbanwe

ISO 9001 achọ ka mgbe ntọhapụ nke imewe akwụkwọ ma ọ bụ isi iyi, mgbanwe nile ga-aga site a iwu usoro ebe mgbanwe na-akwukwo, enyocha na mma tupu mmejuputa iwu.

Achịkwaghị achịkwa mgbanwe mgbagwoju oru akwụkwọ ma ọ bụ omume na-nnọọ ize ndụ, dị ka ndị dị otú ahụ ọkọlọtọ adịghị ekwe ka ya.
5. Document na Data Control

Ozi na akara mmepe / mmezi nke software. The ọkọlọtọ iwu na ndị mkpa ụfọdụ akwụkwọ / data ga-enwe ohere ya. Mgbanwe akwụkwọ na data ga-achịkwa.

5.1 General

Mpụga akwụkwọ na data ga-echekwara. Ọ nwere ike ịchekwa na ihe ọ bụla n’ụdị (nke mbipụta, electronic media).

5.2 Document na Data Ihu na Issue

Tupu nke akwụkwọ na data ga-enyocha ma mma tupu onye ọ bụla nke. A akwụkwọ ndepụta nke otu onye ga-achọpụta na nke ugbu a version nke a akwụkwọ. Ghara ịdị irè ma ọ bụ gharazie ịba uru akwụkwọ a ga-ewepụ ma ọ bụ doro anya na akara.

5.3 Document na Data Mgbanwe

Onye / s na-elekọta nyochaa na ihu ọma usoro a ga-kpọmkwem.

6. ịzụta

Na ihe banyere subcontractor, ị ka bụ ọrụ dịịrị. I.e. ọ bụrụ na ị ide maka a nkwekọrịta na subcontract ọrụ, ISO ụkpụrụ bụ ka n’okpuru ọrụ gị na ISO chọrọ na-enweghị ka a ga-amanye na subcontractor.

6.1 General

Ọ bụrụ na manpower bụ zụrụ, ọkọlọtọ na-achọ na ị na-eso a usoro na ị ga-esi nri ndị mmadụ. The ndị mmadụ ga na-achị soplaya na-adịghị subcontractor.
Iji hụ na zụrụ software kwekọrọ n’ụzọ chọrọ:
– Nsuko chọrọ na subcontractors usoro
– Oditi nke subcontractor àgwà usoro
– Tulee subcontractor gara aga arụmọrụ
– Nnyocha e mere na subcontractor n’oge nkwekọrịta
– Onyeàmà nyochaa na ule
– Test ma nyochaa ngwaahịa nke subcontractor.

6.2 Evaluation nke subcontractors

Onye na mkpa ikike a na-akọ ga-ekpe ikpe ọ bụla subcontractor na-ekpebi ma hà iji. The mkpebi ga-akwukwo.

The soplaya ga-ekpebi ihe achịkwa subcontractor ọ ga-enwe. The ọkọlọtọ ekwugh ole akara ị kwesịrị ị na-enwe. Ọ dị ya nnọọ na-ekwu na a mkpebi a ga-mere site na iji eziokwu.

A pụrụ iche ikpe bụ mgbe software na-zụrụ site na-ere ahịa. Na nke a subcontractor bụ nzukọ ya nke na Ịzụ Ẹnịm, ọ bụghị mbụ Mmepụta nke software.

Ọ bụrụ na ịzụta na-eme site retail ISO 9001 achọ ka i kọwaa na ihe ndị ị na-etinye chọrọ na-ere ahịa ịchịkwa ya soplaya.

6.3 ịzụta Data

Chọrọ on mmepe usoro a ga-akwukwo na nkwekọrịta na soplaya chọrọ ka mma ọrụ pụta na usoro.

6.4 nkwenye nke zụrụ Product

Documentation nke mkpebi banyere nkwenye nke ọ bụla zụrụ mmepe ngwá ọrụ ma ọ bụ gụnyere ngwaahịa.

– No ndepụta nke mma suppliers
– Ekwesịghị Ekwesị akara nke subcontractor
– Ọ dịghị akwụkwọ nkwenye nke zụrụ ihe
– Ekwesịghị Ekwesị nkwekọrịta na subcontractor.

7 Control nke Ahịa-ọnọ Product

The soplaya ga usoro nkwenye, nchekwa na mmezi nke ndị ahịa na-ọnọ software. Otú ọ dị, àgwà bụ ibu ọrụ nke software.

A na-abụghị conformance eme n’ihi ihe edoghị na ibu ọrụ nke ibu ọrụ n’etiti ndị ahịa na soplaya.

8 Product nkọwapụta na Traceability

The software soplaya ga na-akara na:
– On ihe bu ụzọ akwụkwọ ma N’ỤLỌ NCHE ọ dabeere
– On nke nkọwapụta ọ dabeere
– Gịnị degharịa na mmegharị ẹkesịnede nke isi iyi mmemme
– Gịnị mere onye ọ bụla nsogbu akụkọ
– Olee ebe e a kpọmkwem modul eme.

9 Process Control

Akwukwo usoro maka imepụtaghachi na ime ihe na usoro maka njikwa nke nwe-PROMâ € ™ s / ọba akwụkwọ. Iji hụ na ezi kọmpụtà na-eji.

– No akwukwo usoro maka replication
– Ezighị ezi njikwa nke nwe-PROMâ € ™ s ma ọ bụ diskettes.

10 Nnyocha na Ule

Dere na usoro maka nnyocha na nwale a ga-eme na njikọ na replication.

– Function nke na-akpaghị aka ịlele PROMâ € ™ s bụghị e nyochara
– No akwukwo usoro maka enyocha PROMâ € ™ s.

11 Control nke Inspection, Atụ na Test Equipment

The soplaya kwesịrị họrọ ihe kwesịrị ekwesị e ji atụ ngwá na-eso a akwukwo usoro maka akara ngwa. Ọhụrụ ọ bụla software version ga-anwale maka ojuju.

12 Nnyocha na Test Status

Nkọwa na mmemme kwesịrị kwupụtara site reviews na ule. The soplaya ga usoro na gbochie ojiji nke unverified nkọwa ma ọ bụ mmemme.

13 Control nke Non-sụgharịa Product

Non-ime ihe kwekọrọ na ngwaahịa kwesịghị iji ihe n’amaghị ama. A usoro maka na-ejizi ngwa mgbanwe bụrụ na nke dị oké egwu na njehie a ga-kere.

– Doro Anya njirimara nke na-achịkwa ihe ndị na-ebu uncorrected njehie
– Method ka mmeghachi ahịa nabata n’elu nnyefe
– Bụrụ na nke ngwa mgbanwe, ọ ga-akwukwo
– Ịtụleghachi otú gbanwetụrụ ihe a ga-elu otu ọnọdụ dị ka ike nke software.

14 Edozi na Mgbochi Action

– Irè njikwa nke akụkọ ahụ na-anaghị eme ihe a chọrọ
– Irè njikwa nke akụkọ na-egosi mkpụmkpụ-ọpụpụ na mmepe usoro
– Active collection na analysis nke dị ọmụma banyere ngwaahịa na usoro na-abụghị conformance na mgbochi omume.

Ozi banyere nsogbu okosobode kwesịrị ụgbọala ndozi nke mmepe usoro.

– Ahịa mkpesa ka e kwesịrị ekwesị edozi
– Erughi a chọpụtara na ma ọ bụghị gbazie
– No usoro iji hụ na nsogbu na-atụle ihe mere n’elu
– No usoro maka akuko ihe isi ike na itinye iwu na usoro.

15 njikwa, Nchekwa, Packaging, Preservation na nzipu

-Emetụta software replicated na prom, disk ma ọ bụ ndị ọzọ na ọkara.
Media a ga-kpọrọ na packaged n’ụzọ ziri ezi. Data ga-kwadoo elu. E kwesịkwara inwe ike inye nchebe site elezighị mebiri.

16 Control nke Quality Records

Quality akwụkwọ na-egosi nke omume e weere iji hụ ma ọ bụ chọpụta àgwà. Ọkọlọtọ na-achọ na-enwe usoro maka na-ejizi nke àgwà ndia. The ndekọ a ga-echekwara na kwesịrị ekwesị n’ụzọ otú ha na-esi ike ịbanye.
– Ọ dịghị iwu maka njigide nke àgwà ndekọ
– Review ndekọ na-adịghị na-
– Test ndekọ na-adịghị na-
– Oge nke na-edebe mma ndia na-adịghị kọwaa

17 Internal Quality audits

E kwesịrị otu nọọrọ onwe ha kwadoro na mgbe nile audits niile arụmọrụ nke ahụ nwere ike imetụta ngwaahịa ma ọ bụ ọrụ mma. Ndị a na-eduzi na nnọchite nke ụlọ ọrụ management. Unu ga na-oditi plan.

– No oditi plan
– Oditi plan bụghị ruo ụbọchị

18 Training

Company kwesịrị ịgba mbọ hụ na-arụ ọrụ na-azụ ihe aga-eme chọrọ. A usoro:
– Chọpụta ọzụzụ mkpa ka onye ọ bụla na-arụ ọrụ ọnọdụ
– Nye ọzụzụ dị otú ahụ
– Nọgidenụ ndekọ nke ọzụzụ niile bụ ndị ọrụ.

Ọzụzụ kwesịrị akwukwo na zuru ezu. Site zuru ezu anyị pụtara na onye ahụ na-pụrụ ime nke ya / ya ọrụ ka a dị elu ezuru ọkọlọtọ.

– No usoro maka atụmatụ ma ọ bụ ọzụzụ
– Ọ dịghị ọzụzụ ndekọ
– Ọ bụghị natara ọzụzụ kwesịrị ekwesị maka ya ma ọ bụ ya ọrụ.

19 arụ ọrụ

Supplier ga-akwukwo usoro-arụ ọrụ ma ọ bụrụ na a kwuru na nsuko. Na software ọ bụ banyere njehie mgbazi na nkwalite ka anapụta software.

Usoro na-ejizi mkpesa na-arịọ maka mgbanwe. The soplaya na-adịghị ụgwọ nye mmezi ma ọ bụrụ na ọ na-adịghị kwuru na nsuko. Mmezi usoro ochie software ka.

– Mmezi ọrụ maka a ahịa na-enweghị a nkwekọrịta
– Specific ụzọ maka mmezi nke ochie ngwaahịa na-adịghị akwukwo
– No usoro maka ule mgbe mmezi.

20 Statistical Usoro

E kwesịrị collection na analysis nke data banyere ọnụ ọgụgụ nke njehie ndị dị na iche iche n’ụzọ. Ozi banyere enweghi ike izute deadlines na milestones kwesịrị-nyochaa.

“————————————————– ————————————————– ————————————————–

translation dukungan:
————————————————– ————————————————– ————————————————–
ISO 9001 Dua puluh Unsur Kualitas

Sebuah tampilan akan diambil pada persyaratan dari sudut pandang perusahaan mengembangkan perangkat lunak. Standar ISO 9001 itu dimaksudkan untuk industri manufaktur. Persyaratan diinterpretasikan untuk pengembangan perangkat lunak sesuai dengan ISO 9000-3 dan TickIT.

Ada 20 unsur utama. Setiap konsep terkenal di komunitas manajemen mutu.

1. Tanggung Jawab Manajemen

1.1 Kebijakan mutu

Standar ini mengharuskan manajemen pemasok untuk mengeluarkan kebijakan mutu, di mana ia mengatakan perusahaan akan menghasilkan produk berkualitas.

Kualitas kebijakan harus:
– Tentukan managementâ € ™ s komitmen terhadap kualitas
– Tentukan tujuan companyâ € ™ s mengenai kualitas, yaitu, apa yang manajemen berarti dengan kualitas
– Jadilah relevan dengan kebutuhan pelanggan; € ™ s
– Jadilah dipahami dalam organisasi
– Diimplementasikan


– Pernyataan terlalu samar atau kebijakan tidak dipahami oleh staf
– Kebijakan Mutu tidak dilaksanakan.

Misalnya. kebijakan Kualitas

â € œKami mencapai kualitas melalui staf termotivasi dan terampil, prosedur kerja yang ditetapkan, dan kajian intensif dan pengujian € activities.â

1.2 Organisasi

Standar ini membutuhkan dokumentasi tanggung jawab, wewenang dan interelasi dari semua personil yang mempengaruhi kualitas. Ini berarti bahwa jika seseorang memiliki tanggung jawab, itu akan secara resmi ditugaskan oleh manajer yang tepat. orang harus memiliki kewenangan untuk memenuhi tanggung jawab tersebut.

Menurut ISO, tanggung jawab berarti:

â € OEA kewajiban untuk bertindak atas oneâ € ™ s dengan sendirinya ketika sesuatu harus dilakukan tanpa toldâ €.


– Ada sebuah tanggung jawab yang tidak dapat dipenuhi.


– Proyek-line
– Proyek-pelanggan
– Organisasi Proyek pemeliharaan
– Pengembangan perangkat lunak pengembangan-hardware
– Pemeliharaan organisasi-help desk
– Perkembangan penjualan

Sumber mengharuskan pemasok:
– Mengidentifikasi persyaratan untuk sumber daya
– Menetapkan petugas terlatih.

perwakilan manajemen membutuhkan penunjukan perwakilan manajer dengan wewenang dan tanggung jawab untuk:
– Pastikan bahwa perusahaan memenuhi persyaratan dalam ISO 9001
– Laporkan kinerja sistem mutu manajemen perusahaan

1.3 Tinjauan Manajemen

manajer mutu harus secara berkala menyampaikan hasil
– Kualitas audit
– Statistik keluhan kualitas
– Rekaman tindakan korektif

Hasilnya harus dipresentasikan pada pertemuan manajemen direkam dengan catatan pada yang hadir, apa yang disajikan dan apa keputusan yang diambil dan dibuat.

2. Sistem Mutu

sistem mutu â € “”â € œyang struktur organisasi, tanggung jawab, prosedur, proses dan sumber daya untuk menerapkan kualitas PENGELOLAAN €

Prosedur, aturan, keputusan harus dimasukkan ke dalam tulisan. Jika Anda memiliki aturan atau prosedur yang tidak diperlukan oleh ISO 9001, standar masih mensyaratkan bahwa ada tertulis.

Sebuah manual mutu harus berisi referensi dan dokumentasi dari sistem mutu.


– Audit adalah contoh, oleh karena itu jika dalam sampel, ada yang kecil ketidaksesuaian, dan mereka tetap, masih bisa menjadi ketidaksesuaian karena auditor dapat menduga bahwa ada banyak lagi minor ketidaksesuaian.
– Ada prosedur tertulis tidak ditaati.

3. Kontrak Ulasan

Pemeriksaan pemasok sebelum penandatanganan kontrak bahwa organisasi dapat melakukan apa yang dibutuhkan oleh kontrak.

Pertanyaan yang harus ditanyakan meliputi:
– Apakah persyaratan didokumentasikan dan dipahami?
– Apakah kriteria penerimaan disertakan?
– Apakah kebutuhan yang berbeda dari tender diselesaikan?
– Bisa pemasok mengumpulkan cukup sumber daya untuk kontrak?
– Bisa pemasok mengumpulkan kompetensi yang dibutuhkan untuk kontrak?
– Dapat tugas akan selesai dalam waktu?

Standar ini mensyaratkan bahwa prosedur terdokumentasi dengan ulasan dimasukkan. pemasok harus mengidentifikasi bagaimana amandemen kontrak dan penanganan persyaratan spesifikasi antara pelanggan dan pemasok didefinisikan.

4. Kontrol Desain

4.1. Umum
ISO mengharuskan Anda berencana sebelum melakukan dan menentukan sebelum merancang.

4.2. Desain dan Pengembangan Perencanaan

rencana desain harus berisi:
– Definisi metodologi yang akan digunakan dalam pengembangan produk
– Jadwal waktu, tanggung jawab, tugas kerja dan kontrol kemajuan
– Proyek Tahapan akan dibagi. Ini termasuk input, output dan verifikasi output.
– Deskripsi metode dan alat yang akan digunakan

rencana mutu harus berisi:
– Target Kualitas
– Kriteria untuk penerimaan
– Identifikasi perencanaan, validasi dan verifikasi.
– Tanggung jawab untuk kegiatan kualitas.

Jika sebuah perusahaan ingin memperoleh kualifikasi ISO rencana harus diadakan di semua proyek, karena sertifikasi ISO adalah untuk seluruh perusahaan dan bukan untuk proyek-proyek tertentu.

4.3 Antarmuka Organisasi dan Teknis

Jika ada kelompok-kerja, antarmuka antara mereka harus diidentifikasi, didokumentasikan dan dikirimkan ke mereka yang membutuhkan informasi. dokumentasi harus ditinjau secara teratur.

4.4 Desain Masukan

Persyaratan spesifikasi berisi masukan desain dalam pengembangan perangkat lunak. Hal ini dapat dilakukan oleh pembeli atau disiapkan oleh pemasok menggunakan hukum dan peraturan. masukan desain lain mencakup desain coding yang digunakan sebagai masukan untuk coding.

Standar ingin memastikan bahwa produk kerja dari setiap langkah memenuhi persyaratan.

Dalam pengembangan perangkat lunak, perubahan persyaratan yang umum sehingga prosedur untuk menangani persyaratan baru dan berubah dari pembeli dibuat.

4.5 Desain Keluaran

Desain Output: dokumentasi desain dan kode sumber. ISO mensyaratkan bahwa dokumen desain dan coding ditinjau sebelum rilis.

Sebuah prosedur untuk penerimaan output desain dan kriteria penerimaan harus dibuat.

4.6 Desain Ulasan

fungsi proyek seperti coding dan testing harus disajikan di review. Sebuah metode umum untuk memastikan ulasan yang checklist.

4.7 Desain Verifikasi

Ini terdiri dari ulasan, pengujian modul dan pengujian integrasi.

4.8 Desain Validasi

tes akhir sistem, produk perangkat lunak yang lengkap bersama dengan meninjau dokumentasi pengguna. Ada harus direncanakan dan didokumentasikan validasi. pengujian beta sesuai dengan ISO selama pengujian beta tertutup oleh kesepakatan yang jelas antara pemasok dan beta-testing pelanggan.

4.9 Desain Perubahan

ISO 9001 mensyaratkan bahwa setelah rilis dari dokumentasi desain atau sumber, semua perubahan harus melalui proses formal di mana perubahan didokumentasikan, dan disetujui sebelum diterapkan.

perubahan yang tidak terkendali untuk dokumen teknis yang rumit atau program yang sangat berbahaya dan sebagai standar seperti tidak mengizinkannya.
5. Dokumen dan Data Control

Informasi yang mengontrol perkembangan / pemeliharaan perangkat lunak. Standar ini mensyaratkan bahwa mereka yang membutuhkan beberapa dokumen / data harus memiliki akses ke sana. Perubahan dokumen dan data harus dikendalikan.

5.1 Umum

dokumen eksternal dan data akan disimpan. Hal ini dapat disimpan pada bentuk apapun (hard copy, media elektronik).

5.2 Dokumen dan Persetujuan Data dan Isu

Sebelum dokumen masalah dan data harus ditinjau dan disetujui sebelum setiap masalah. Sebuah daftar dokumen mana yang akan mencari tahu versi dokumen. dokumen yang tidak valid atau usang harus dihapus atau ditandai dengan jelas.

5.3 Dokumen dan Data Perubahan

Orang / s jawab dari tinjauan dan persetujuan proses harus ditentukan.

6. Pembelian

Dalam kasus subkontraktor, Anda masih bertanggung jawab. Yaitu. jika Anda menerapkan untuk kontrak dan mensubkontrakkan pekerjaan, standar ISO masih dalam tanggung jawab dan persyaratan ISO tidak harus dikenakan pada subkontraktor.

6.1 Umum

Jika tenaga kerja yang dibeli, standar mengharuskan Anda untuk mengikuti prosedur yang Anda mendapatkan orang yang tepat. Orang-orang akan dikendalikan oleh pemasok dan tidak subkontraktor.
Untuk memastikan bahwa perangkat lunak yang dibeli sesuai dengan persyaratan:
– Persyaratan Kontrak pada prosedur subkontraktor
– Audit sistem mutu subkontraktor
– Periksa subkontraktor masa lalu kinerja
– Survey subkontraktor selama kontrak
– Ulasan Saksi dan pengujian
– Test dan produk review subkontraktor.

6.2 Evaluasi Subkontraktor

Orang dengan wewenang dan kompetensi yang diperlukan akan menghakimi setiap subkontraktor dan memutuskan apakah akan menggunakan. Keputusan harus didokumentasikan.

pemasok harus memutuskan apa kontrol atas subkontraktor akan memiliki. Standar ini tidak menyebutkan berapa banyak kontrol Anda harus memiliki. Itu hanya menyebutkan bahwa keputusan harus dibuat dengan menggunakan fakta-fakta.

Sebuah kasus khusus adalah ketika perangkat lunak dibeli melalui ritel. Dalam hal ini subkontraktor adalah organisasi dengan yang pembelian dilakukan, tidak pengembang asli dari perangkat lunak.

Jika pembelian dilakukan melalui ISO ritel 9001 mengharuskan Anda menentukan sejauh mana Anda meletakkan persyaratan pada pengecer untuk mengontrol pemasoknya.

6.3 data Purchasing

Persyaratan pada proses pembangunan harus didokumentasikan dalam kontrak bersama dengan persyaratan pemasok untuk menyetujui hasil kerja dan prosedur.

6.4 Verifikasi Produk yang dibeli

Dokumentasi keputusan tentang verifikasi setiap dibeli alat pengembangan atau produk disertakan.

– Tidak ada daftar pemasok yang telah disetujui
– Kontrol pantas subkontraktor
– Tidak ada verifikasi dokumen barang yang dibeli
– Kontrak pantas dengan subkontraktor.

7 Pengendalian Produk Pelanggan yang disediakan

pemasok harus memiliki prosedur untuk verifikasi, penyimpanan dan pemeliharaan pelanggan disediakan software. Namun, kualitas adalah tanggung jawab dari perangkat lunak.

Sebuah ketidaksesuaian terjadi karena tanggung jawab yang tidak jelas tanggung jawab antara pelanggan dan pemasok.

8 Spesifikasi Produk dan Lacak

Pemasok perangkat lunak harus tetap kontrol pada:
– Pada apa sebelumnya dokumen dan mengeluarkan didasarkan
– Pada yang spesifikasi didasarkan
– Apa koreksi dan perubahan ini sudah termasuk dalam program mana sumber
– Apa yang terjadi dengan setiap laporan masalah
– Dari sumber yang modul tertentu yang dihasilkan.

9 Process Control

Didokumentasikan prosedur untuk proses replikasi dalam operasi dan prosedur untuk penanganan induk Proma € ™ s / perpustakaan. Untuk memastikan bahwa versi yang benar digunakan.

– Tidak ada didokumentasikan prosedur untuk replikasi
– Penanganan yang tidak tepat master Proma € ™ s atau disket.

10 Inspeksi dan Pengujian

prosedur tertulis untuk pemeriksaan dan pengujian dilakukan sehubungan dengan replikasi.

– Fungsi otomatis memeriksa Proma € ™ s belum diperiksa
– Tidak ada didokumentasikan prosedur untuk menguji Proma € ™ s.

11 Pengendalian Inspeksi, Pengukuran dan Alat Uji

Pemasok harus memilih peralatan pengukuran yang tepat dan mengikuti prosedur terdokumentasi untuk kontrol peralatan. Setiap versi software baru harus diuji untuk kecukupan.

12 Inspeksi dan Status Uji

Spesifikasi dan program harus diverifikasi melalui ulasan dan pengujian. pemasok harus memiliki prosedur yang melarang penggunaan spesifikasi atau program yang belum diverifikasi.

13 Pengendalian Non-sesuai Produk

produk non-penurut tidak boleh digunakan tidak sengaja. Prosedur untuk menangani modifikasi cepat jika terjadi kesalahan kritis harus dibuat.

– Identifikasi yang jelas dari item terkontrol yang mengandung kesalahan dikoreksi
– Cara untuk memperoleh penerimaan pelanggan pada saat pengiriman
– Dalam kasus modifikasi cepat, harus didokumentasikan
– Meninjau item sehingga dimodifikasi akan diangkat ke status yang sama dengan sisa software.

14 Tindakan Perbaikan dan Pencegahan

– Penanganan yang efektif dari laporan yang tidak sesuai dengan persyaratan
– Penanganan yang efektif dari laporan yang menunjukkan kedatangan pendek dalam proses pembangunan
– Koleksi Aktif dan analisis informasi yang tersedia tentang produk dan proses ketidaksesuaian dan tindakan pencegahan.

Informasi tentang masalah yang dihadapi harus mendorong perbaikan dari proses pembangunan.

– Keluhan Pelanggan belum ditangani dengan baik
– Defisiensi telah ditemukan tetapi tidak diperbaiki
– Tidak ada prosedur untuk memastikan bahwa masalah dianalisis dan ditindaklanjuti
– Tidak ada prosedur untuk melaporkan kesulitan dengan menerapkan aturan dan prosedur.

15 Penanganan, Penyimpanan, Pengemasan, Pelestarian dan Pengiriman

Berlaku untuk software direplikasi pada PROM, disk atau media lainnya.
Media harus diberi label dan dikemas dengan benar. Data harus didukung. Ada juga harus kemampuan untuk memberikan perlindungan dari kerusakan yang tidak disengaja.

16 Pengendalian Mutu Rekaman

dokumen berkualitas menunjukkan yang tindakan telah diambil untuk memastikan atau memeriksa kualitas. Standar ini mensyaratkan bahwa ada prosedur untuk penanganan catatan mutu. Catatan harus disimpan dengan cara yang tepat sehingga mereka mudah diakses.
– Tidak ada aturan untuk retensi catatan mutu
– Catatan Ulasan tidak disimpan
– Catatan Uji tidak disimpan
– Periode menyimpan catatan kualitas tidak didefinisikan

17 Kualitas Audit Internal

Harus ada badan independen yang secara teratur mengaudit semua operasi yang dapat mempengaruhi kualitas produk atau layanan. Ini dilakukan atas nama manajemen perusahaan. Harus ada rencana audit.

– Tidak ada rencana audit
– Rencana Audit tidak up to date

18 Pelatihan

Perusahaan harus memastikan staf yang dilatih untuk tugas-tugas yang diperlukan. Suatu prosedur untuk:
– Mengidentifikasi kebutuhan pelatihan untuk setiap posisi staf
– Memberikan pelatihan tersebut
– Jauhkan catatan pelatihan semua anggota staf.

Pelatihan harus didokumentasikan dan memadai. Dengan cukup kita berarti bahwa orang tersebut mampu melakukan / karyanya untuk standar cukup tinggi.

– Tidak ada prosedur untuk perencanaan atau pelatihan
– Tidak ada catatan pelatihan
– Tidak menerima pelatihan yang tepat untuk tugas nya.

19 Pelayanan

Pemasok harus memiliki prosedur terdokumentasi untuk melayani jika ini disebutkan dalam kontrak. Dalam perangkat lunak ini adalah tentang koreksi kesalahan dan perangkat tambahan untuk perangkat lunak yang dikirimkan.

Prosedur penanganan keluhan dan permintaan untuk modifikasi. pemasok tidak berkewajiban untuk memberikan perawatan jika tidak disebutkan dalam kontrak. prosedur perawatan untuk perangkat lunak lama harus dilakukan.

– Pekerjaan Pemeliharaan untuk pelanggan tanpa kontrak
– Metode khusus untuk pemeliharaan produk lama tidak didokumentasikan
– Tidak ada prosedur untuk pengujian setelah perawatan.

20 Teknik statistik

Harus ada pengumpulan dan analisis data tentang jumlah kesalahan yang ditemukan dalam fase yang berbeda. Informasi tentang ketidakmampuan untuk memenuhi tenggat waktu dan tonggak harus dianalisis.

“————————————————– ————————————————– ————————————————–

Aistriúchán Tacaíocht:
————————————————– ————————————————– ————————————————–
ISO 9001 Fiche Cáilíochta Eilimintí

Beidh Súil a ghlacadh ar na ceanglais ó thaobh na gcuideachtaí a fhorbairt bogearraí. Bhí sé i gceist caighdeán ISO 9001 do thionscal na déantúsaíochta. Tá na riachtanais a léirmhíniú le haghaidh forbairt bogearraí de réir ISO 9000-3 agus TickIT.

Tá 20 phríomhghné. Tá gach coincheap eolas go maith i measc an phobail bainistíochta cáilíochta.

Freagracht 1. Bainistíocht

1.1 Beartas Cáilíochta

Éilíonn an caighdeán a bhainistiú soláthraí beartas cáilíochta, nuair a deir sé déanfaidh an chuideachta a tháirgeadh táirgí ardchaighdeáin a eisiúint.

An beartas cáilíochta seo a leanas:
– Sainmhínigh tiomantas na managementâ € ™ s le cáilíocht
– Cuspóirí an € ™ s Sainmhínigh maidir le cáilíocht, is é sin, cén bainistíochta a chiallaíonn ag cáilíochta
– A bheith ábhartha do riachtanais customerâ € ™ s
– A bheith thuiscint san eagraíocht
– A bheith i bhfeidhm


– Níl Ráiteas ródhoiléir nó polasaí tuigeann an fhoireann
– Níl polasaí Cáilíochta i bhfeidhm. an bheartais Cáilíochta

â € Œwe cáilíochta trí foireann dhíograiseach, chumasach, nósanna imeachta oibre sainithe, agus athbhreithniú dian agus tástáil activities.â € bhaint

1.2 Eagraíocht

Éilíonn an caighdeán doiciméadú freagrachta, údaráis agus idirchaidreamh na gach pearsanra cur isteach ar cháilíocht. Ciallaíonn sé seo má tá freagracht ag duine, sannfar go foirmiúil ag an mbainisteoir iomchuí. Ba cheart go mbeadh údarás ag an duine chun an fhreagracht sin a chomhlíonadh.

De réir ISO, ciallaíonn freagracht:

â € dualgas œa gníomhú ar amháin ar € ™ s stuaim féin nuair a bhfuil rud éigin a dhéanamh gan a bheith toldâ €.


– Atá ann cheana de freagracht nach féidir a chomhlíonadh.


– Tionscadal-líne
– Tionscadal-do chustaiméirí
– Eagraíocht Tionscadal-cothabhála
– Forbairt bogearraí forbartha-crua-earraí
– Deasc Maintenance eagraíocht-help
– Sales-Forbairt

cheangal Acmhainní bhfuil an soláthróir:
– Na ceanglais maidir le hacmhainní
– Sann pearsanra oilte.

Éilíonn ionadaíoch Bainistiú cheapadh ionadaí bhainisteora le húdarás agus freagracht:
– A chinntiú go gcomhlíonann an chuideachta na ceanglais in ISO 9001
– Tuarascáil ar fheidhmíocht an chórais cáilíochta le bainistíocht cuideachta

1.3 Athbhreithniú Bainistíochta

Ba chóir bainisteoir cáilíochta a chur i láthair go tréimhsiúil ar thorthaí na
– Trí iniúchtaí cáilíochta déantar
– Staidreamh ar ghearáin cáilíochta
– Taifid ar ghníomhaíocht cheartaitheach

Ba cheart na torthaí a chur i láthair ag cruinniú bainistíochta taifeadta le nótaí ar a bhí i láthair, cad a bhí i láthair agus na cinntí a rinneadh agus a rinneadh.

2. Córas Cáilíochta

Córas Cáilíochta â € “”â € œthe struchtúr eagraíochtúil, freagrachtaí, nósanna imeachta, próisis agus acmhainní chun feidhme management.â cáilíochta €

Nósanna Imeachta, rialacha, cinntí a chur i scríbhinn. Má tá tú riail nó nós imeachta nach bhfuil ag teastáil ag ISO 9001, éilíonn an caighdeán go fóill go bhfuil sé scríofa.

Bunófar lámhleabhar cáilíochta go bhfuil tagairt agus doiciméadú an chórais cáilíochta.


– Is iniúchadh ar shampla, dá bhrí sin, más rud é i sampla, tá mion neamhchomhlíonadh, agus tá siad socraithe, is féidir é a bheith fós ina neamhchomhlíonadh toisc nach féidir an t-iniúchóir amhras go bhfuil go leor níos mion neamhchomhlíonadh.
– Ní nósanna imeachta scríofa ann cheana chloígh.

Athbhreithniú 3. Conarthaí

Na seiceálacha soláthróir roimh an conradh a shíniú go bhfuil an eagraíocht in ann a dhéanamh an méid is gá do réir an chonartha.

I measc na gceisteanna a bheidh le cur:
– An bhfuil na ceanglais doiciméadaithe agus a thuiscint?
– An bhfuil critéir inghlacthachta áireamh?
– An bhfuil riachtanais éagsúla ón tairiscint a réiteach?
– An féidir leis an soláthraí coimhéirghe go leor acmhainní don chonradh?
– An féidir leis an soláthraí coimhéirghe inniúlacht is gá chun an conradh a?
– An féidir leis an tasc a chur i gcrích in am?

Éilíonn an caighdeán gur nós imeachta doiciméadaithe le hathbhreithnithe a chur san áireamh. Ba cheart don soláthraí aithint conas leasuithe conartha agus láimhseáil ceanglais a shonrú idir an custaiméir agus an soláthróir a shainiú.

4. Rialú Dearadh

4.1. General
Éilíonn ISO bhfuil ar intinn agat sula ndéanfaidh sé agus ar roimhe a dhearadh.

4.2. Dearadh agus Forbairt

Ba chóir go mbeadh plean dearaidh go bhfuil:
– Sainmhíniú ar mhodheolaíocht atá le húsáid i bhforbairt táirge
– Amchláir, freagrachtaí, tascanna oibre agus rialú ar dhul chun cinn
– Beidh Céimeanna tionscadail a roinnt. Áirítear leis seo ionchur, aschur agus fíorú aschur.
– Cur síos ar na modhanna agus na huirlisí a úsáidfear

Ba chóir go mbeadh plean Cáilíochta go bhfuil:
– Spriocanna Cáilíochta
– Critéir maidir le inghlacthacht
– A aithint le pleanáil, bailíochtú agus fíorú.
– Freagrachtaí do ghníomhaíochtaí cáilíochta.

Más mian le cuideachta a fháil cáilíocht ISO mór na pleananna ar siúl i ngach tionscadal, ós rud é go ISO deimhniú don chuideachta ar fad, agus ní do thionscadail ar leith.

4.3 Comhéadain eagrúcháin agus Teicniúil

Má tá obair ghrúpa, ba chóir na Comhéadain eatarthu a aithint, a dhoiciméadú agus a tharchur chuig siúd de dhíth orthu ar an eolas. Áireofar sa doiciméadacht a athbhreithniú go rialta.

4.4 Dearadh Ionchur

Go bhfuil an t-ionchur a dhearadh i bhforbairt bogearraí Riachtanais sonraíochtaí. Féadfar é seo a dhéanamh ag an gceannaitheoir nó a d’ullmhaigh an soláthraí ag baint úsáide as dlíthe agus rialacháin. Áirítear ionchur dearadh eile códú dearadh a úsáidtear mar ionchur códaithe.

Is mian leis an caighdeán a chinntiú go gcomhlíonann an táirge obair gach céim na ceanglais.

I bhforbairt bogearraí, athruithe ceanglas coiteann sin nós imeachta chun déileáil le riachtanais nua agus athraithe ón gceannaitheoir a chruthú.

4.5 Aschur Dearadh

Aschur Dearadh: dhoiciméadacht an cheaptha agus an cód foinse. Éilíonn ISO go códaithe cáipéisí deartha agus athbhreithniú roimh scaoileadh.

Ba cheart nós imeachta chun glacadh leis an t-aschur a dhearadh agus na critéir glactha a chruthú.

4.6 Athbhreithniú Dearadh

Comhlíonfar feidhmeanna den thionscadal mar códú agus tástáil a chur i láthair ag an t-athbhreithniú. Tá modha chomhchoitinn chun athbhreithnithe a áirithiú seicliostaí.

4.7 Fíorú Dearadh

Is éard atá athbhreithnithe, tástáil modúl agus tástáil comhtháthú.

4.8 Dearadh Bailíochtú

Tástáil Deiridh Córas, an táirge bogearraí iomlán mar aon leis an athbhreithniú doiciméadú úsáideora. ba cheart go dtabharfaí ann pleanáilte agus bailíochtú doiciméadaithe. Tá tástáil Beta i comhlíonta le ISO chomh fada is atá an tástáil béite a chumhdaítear le comhaontú soiléir idir soláthróir agus béite-thástáil do chustaiméirí.

4.9 Athruithe Deartha

Éilíonn ISO 9001 gur tar éis scaoileadh dhoiciméadacht an cheaptha nó foinse, déanfaidh gach athrú dul trí phróiseas foirmiúil ina bhfuil athruithe dhoiciméadú, a athbhreithniú agus a fhormheas sula gcuirfear chun feidhme.

Tá athruithe neamhrialaithe ar dhoiciméid nó cláir teicniúla casta thar a bheith contúirteach agus cosúil leis an caighdeán a cheadú dó.
5. Doiciméad agus Rialú sonraí

Eolas a rialaíonn forbairt / cothabháil bogearraí. Éilíonn an caighdeán go siúd a bhfuil gá acu le roinnt doiciméad / beidh rochtain ag a bheith aige sonraí. Déanfar athruithe ar doiciméid agus sonraí a rialú.

5.1 Ginearálta

Déanfar doiciméid seachtracha agus sonraí a stóráil. Is féidir é a stóráil ar aon fhoirm (cóip chrua, meáin leictreonacha).

5.2 Doiciméad agus Sonraí Ceadú agus Eisiúint

Déanfar Sula doiciméid agus sonraí a eisiúint a athbhreithniú agus a fhormheas faoi bhráid gach saincheist. Tá liosta doiciméad ina ndéanfaidh duine a fháil amach an leagan reatha de dhoiciméad. Ba chóir doiciméid neamhbhailí nó imithe i léig a bhaint nó a mharcáil go soiléir.

5.3 Doiciméad agus Sonraí Athruithe

Tabharfaidh an duine / s atá i bhfeighil an phróisis athbhreithnithe agus fhormheasa.

6. Ceannaigh

I gcás fhochonraitheora, tá tú fós freagrach. I.e. má dhéanann tú iarratas ar conradh agus an obair a fhochonrú, tá caighdeáin ISO fós faoi do fhreagracht agus ní gá na ceanglais ISO mór a bheidh le forchur ar an bhfochonraitheoir.

6.1 Ginearálta

Má tá daonchumhachta ceannaíodh, éilíonn an caighdeán duit a leanúint le nós imeachta go bhfaigheann tú na daoine cearta. Beidh na daoine a rialú ag soláthraí agus ní fochonraitheoir.
A chinntiú go mbogearraí a ceannaíodh chloíonn le riachtanais:
– Ceanglais Conradh ar na nósanna imeachta fochonraitheoirí
– Iniúchadh ar an gcóras cáilíochta fochonraitheoir
– Seiceáil fochonraitheoir atá caite feidhmíochta
– Suirbhé ar an bhfochonraitheoir leathbhealach tríd
– Athbhreithniú Fhinné agus tástáil
– Tástáil agus a táirge athbhreithnithe ar fhochonraitheora.

6.2 Meastóireacht ar Fochonraitheoirí

beidh an duine a bhfuil údarás agus inniúlacht riachtanach breitheamh gach fochonraitheoir agus cinneadh a dhéanamh chun úsáid. Ní bheidh na cinntí a dhoiciméadú.

ní mór don soláthraí cinneadh a dhéanamh smacht fochonraitheoir bheidh aige. Ní dhéanann an caighdeán lua cé mhéad a rialú chóir go mbeadh ort. luann sé gur cóir cinneadh a dhéanamh trí úsáid a bhaint fíricí.

Tá cás speisialta nuair a bogearraí a ceannaíodh trí miondíola. Sa chás seo fochonraitheoir Is eagraíocht lena ndéantar an ceannach a rinneadh, nach bhfuil an bhforbróir bunaidh de na bogearraí.

Má tá ceannach dhéanamh trí ISO miondíola Éilíonn 9001 a shainmhíníonn tú a mhéid a chuir tú riachtanais ar an miondíoltóir a rialú a sholáthraí.

6.3 Ceannaigh Sonraí

Tabharfar aird ar cheanglais maidir le próiseas forbartha a dhoiciméadú sa chonradh chomh maith le riachtanais soláthraí torthaí agus nósanna imeachta oibre a cheadú.

6.4 Fíorú Táirge Ceannaithe

Doiciméadú na cinntí a dhéanamh maidir le fíorú gach ceannaíodh uirlis forbartha nó táirgí díobh.

– Uimh liosta de na soláthróirí ceadaithe
– Rialú Míchuí de fhochonraitheora
– Níl aon cháipéis a fhíorú míreanna a ceannaíodh
– Conradh Míchuí le fochonraitheoir.

7 Rialú do Chustaiméirí-sholáthraítear Táirge

Beidh nósanna imeachta maidir le fíorú, stóráil agus cothabháil bogearraí arna soláthar do chustaiméirí ag an soláthraí. Mar sin féin, is é an fhreagracht ar an bogearraí ar chaighdeán.

Tarlaíonn A neamhchomhlíonadh de bharr fhreagracht doiléir freagrachta idir an custaiméir agus an soláthraí.

8 Sonraíocht Táirge agus Inrianaitheacht

Ba chóir don soláthróir bogearraí a choinneáil smacht ar:
– Tá Cén roimhe doiciméad agus eiseoidh sé bunaithe
– Ar a sonraíocht bhfuil sé bunaithe
– Cad iad na ceartúcháin agus na leasuithe seo curtha san áireamh ina gcláir foinse
– Cad a tharla do gach tuarascáil fadhb
– Ó cad fhoinse a bhí modúl sonrach ghintear.

Rialú 9 Próiseas

Doiciméadaithe Nós imeachta don phróiseas replication in oibriú agus nós imeachta maidir le láimhseáil máistir PROMâ € ™ s / leabharlanna. A chinntiú go bhfuil versioning cheart úsáid.

– Uimh nós imeachta doiciméadaithe macasamhlaithe
– Láimhseáil míchuí máistir PROMâ € ™ s nó diskettes.

10 Iniúchadh agus Tástáil

nósanna imeachta scríofa chun iniúchadh agus a thástáil a dhéanamh i dtaca le macasamhlú.

– Nach bhfuil Feidhm sheiceáil go huathoibríoch PROMâ € ™ s rinneadh cigireacht
– Uimh doiciméadaithe nós imeachta le haghaidh tástála PROMâ € ™ s.

11 Rialú Cigireachta, tomhais agus Trealamh Tástáil

Ba chóir don soláthróir a roghnú an trealamh tomhais chuí agus lean nós imeachta doiciméadaithe maidir le rialú an trealaimh. Ba chóir do gach leagan bogearraí nua a thástáil le haghaidh sufficiency.

12 Iniúchadh agus Tástáil Stádas

Ba cheart sonraíochtaí agus cláir fíoraithe trí athbhreithnithe agus tástáil. Beidh nósanna imeachta a thoirmeasc úsáid sonraíochtaí nó cláir unverified ag an soláthraí.

13 Rialú Neamh gcomhréir-Táirge

Níor cheart tháirgí neamh-chomhréireacha a úsáid neamhbheartaithe. Ba cheart nós imeachta a láimhseáil modhnuithe tapa i gcás earráidí criticiúla a chruthú.

– Sainaithint Clear na n-ítimí rialaithe a bhfuil earráidí neamhcheartaithe
– Modh a mhealladh a ghlacadh do chustaiméirí ar sheachadadh
– I gcás modhnuithe tapa, ní mór é a dhoiciméadú
– Beidh Athbhreithniú nithe modhnaithe amhlaidh a ardaithe go stádas céanna le gcuid eile de bhogearraí.

14 Gníomh Ceartaithe agus Coisctheach

– Láimhseáil éifeachtach tuarascálacha nach bhfuil ag luí leis na ceanglais
– Láimhseáil éifeachtach tuarascálacha a léiríonn gearr-comings sa phróiseas forbartha
– Bailiú agus anailísiú faisnéise atá ar fáil maidir tháirgí agus ar phróisis neamh-chomhlíonadh agus gníomhartha coisctheacha Gníomhacha.

Eolas faoi fhadhbanna a bhí ba cheart feabhas ar an bpróiseas forbartha a thiomáint.

– Nach bhfuil gearán Chustaiméirí curtha láimhseáil i gceart
– Tá Easnamh faighte ach nach bhfuil a cheartú
– Uimh nós imeachta chun a chinntiú go bhfuil fadhbanna anailís agus ina ndéantar beart
– Uimh nós imeachta maidir le deacrachtaí le rialacha agus nósanna imeachta a chur i bhfeidhm tuairiscithe.

15 Láimhseáil, Stóráil, Pacáistiú, Caomhnú agus Seachadadh

Baineann sé seo le bogearraí mhacasamhlú ar PROM, diosca nó meán eile.
Déanfar na Meáin a lipéadú agus a phacáistiú de gceart. dhéanfar sonraí a tacaíocht suas. Ba chóir go mbeadh ar an gcumas cosaint a sholáthar ó dhamáiste neamhbheartaithe.

16 Rialú Taifead Cáilíochta

Léiríonn cáipéisí Cáilíochta a gníomhaíochtaí déanta chun a chinntiú nó seiceáil cáilíochta. Éilíonn an caighdeán go mbeadh nós imeachta chun déileáil le taifid cháilíochta. Ba cheart na taifid a stóráil ar bhealach cuí ionas go bhfuil siad inrochtana go héasca.
– Uimh rialacha maidir le coinneáil taifead cáilíochta
– Ní taifid Athbhreithniú gcoimeádtar
– Ní taifid tástála gcoimeádtar
– Ní Tréimhse taifid cháilíochta a choimeád sainithe

Iniúchtaí 17 Quality Inmheánach

Ba chóir go mbeadh aonán neamhspleách a dhéanann iniúchadh ar na hoibríochtaí go rialta d’fhéadfadh difear táirge nó seirbhís ar ardchaighdeán. Tá siad seo a rinneadh ar son na bainistíochta cuideachta. Ba chóir go mbeadh plean iniúchóireachta.

– Gan plean iniúchta
– Plean Iniúchta nach suas chun dáta

18 Oiliúint

Tá Cuideachta a chinntiú go bhfoireann oilte do tascanna riachtanacha. Tá nós imeachta seo a leanas:
– A aithint riachtanais oiliúna do gach suíomh foirne
– Oiliúint sórt
– Taifid ar oiliúint a chur ar gach ball foirne Coinnigh.

Ba cheart oiliúint a dhoiciméadú agus leordhóthanach. De réir leor i gceist againn go bhfuil an duine a bheith in ann na aige / aici ar chaighdeán ard go leor.

– Uimh nósanna imeachta maidir le pleanáil nó oiliúna
– Gan taifid oiliúna
– Gan fuair oiliúint chuí chun é nó í tasc.

19 Seirbhísiú

Déanfar soláthróir nósanna imeachta doiciméadaithe seirbhísiú má tá sé seo luaite sa chonradh. I bogearraí bhfuil sé ar tí ceartúcháin earráid agus feabhsúcháin bogearraí ar fáil.

Nósanna imeachta maidir le gearáin agus iarrataí a láimhseáil le haghaidh modhnuithe. Níl oibleagáid ar an soláthróir cothabhála a chur ar fáil más rud é nach bhfuil sé luaite sa chonradh. Ba cheart nósanna imeachta a chothabháil chun bogearraí d’aois a dhéanamh.

– Obair chothabhála do chustaiméir gan conradh
– Ní Modhanna sonracha maidir le cothabháil táirge d’aois doiciméadaithe
– Uimh nós imeachta le haghaidh tástála tar éis cothabháil.

20 Teicnící Staidrimh

Ba chóir go mbeadh bailiú agus anailís sonraí faoi líon na n-earráidí le fáil i gcéimeanna éagsúla. Ba chóir faisnéis faoi éagumas chun spriocdhátaí a chomhlíonadh agus na clocha míle a anailísiú.

“————————————————– ————————————————– ————————————————–

traduzione Supporto:
————————————————– ————————————————– ————————————————–
ISO 9001 Venti elementi di qualità

Uno sguardo sarà presa a requisiti dal punto di vista delle aziende che sviluppano software. ISO 9001 è stato destinato per l’industria manifatturiera. I requisiti sono interpretati per lo sviluppo software in conformità con ISO 9000-3 e TickIT.

Ci sono 20 elementi principali. Ogni concetto è ben noto nella comunità di gestione della qualità.

Responsabilità 1. Gestione

1.1 La politica della qualità

La norma richiede la gestione dei fornitori di emettere una politica di qualità, dove si dice che l’azienda deve produrre prodotti di qualità.

La politica di qualità deve:
– Definire il managementâ € ™ s impegno per la qualità
– Definire gli obiettivi companyâ € ™ s per quanto riguarda la qualità, che è, ciò che significa gestione per la qualità
– Essere adeguati alle esigenze della Customerâ € ™ s
– Essere compreso nell’organizzazione
– Essere attuate

Non conformità

– Dichiarazione troppo vago o la politica non è compreso da personale
– La politica della qualità non è implementata.

Per esempio. della politica di qualità

â € œWe ottenere qualità attraverso personale motivato e qualificato, procedure di lavoro definite, e la revisione intensiva e testare activities.â €

1.2 Organizzazione

Lo standard richiede la documentazione di responsabilità, l’autorità e le funzioni del personale che influenzano la qualità. Questo significa che se una persona ha una responsabilità, deve essere assegnato formalmente dal gestore appropriato. La persona deve avere l’autorità per soddisfare la responsabilità.

Secondo la norma ISO, responsabilità significa:

â € œUna il dovere di agire per proprio accordo oneâ € ™ s quando qualcosa deve essere fatto senza essere Tolda €.

Non conformità

– Esistente di una responsabilità che non può essere soddisfatta.


– Progetto-line
– Project-cliente
– Organizzazione del progetto di manutenzione
– Lo sviluppo di software di sviluppo hardware
– Manutenzione organizzazione-help desk
– Sviluppo delle vendite

Risorse richiedono che il fornitore:
– Identificare i requisiti per le risorse
– Assegnare personale qualificato.

Rappresentante della direzione richiede nomina del rappresentante responsabile con l’autorità e la responsabilità di:
– Assicurarsi che l’azienda soddisfa i requisiti di ISO 9001
– Relazione le prestazioni del sistema di qualità per la gestione aziendale

1.3 Management Review

responsabile qualità dovrebbe presentare periodicamente i risultati di
– Controlli di qualità
– Le statistiche di reclami di qualità
– Registrazioni di azioni correttive

I risultati dovrebbero essere presentati in una riunione della direzione registrata con le note su che ha partecipato, ciò che è stato presentato e quali decisioni sono state prese e fatto.

2. Sistema di Qualità

Sistema di qualità â € “”â € œThe struttura organizzativa, le responsabilità, le procedure, i processi e le risorse per l’attuazione di qualità management.â €

Procedure, regole, le decisioni devono essere messe in scrittura. Se si dispone di una regola o una procedura che non è richiesto dalla norma ISO 9001, lo standard richiede ancora che è scritto.

Un manuale della qualità deve contenere riferimento e documentazione del sistema di qualità.

Non conformità

– Un audit è un campione, quindi, se in un campione, ci sono non conformità minori, e sono fissati, può ancora essere una non conformità, perché il sindaco può sospettare che ci sono molti non conformità più minori.
– Le procedure esistenti scritto non sono rispettati.

Recensione 3. Contratto

I controlli fornitore prima della firma del contratto che l’organizzazione in grado di eseguire quanto richiesto dal contratto.

Domande che dovrebbero essere poste includono:
– Sono i requisiti documentati e compresi?
– Sono inclusi criteri di accettazione?
– Sono stati risolti diversi requisiti dalla gara?
– Può il fornitore di raccogliere risorse sufficienti per il contratto?
– Può il fornitore di radunare le competenze necessarie per il contratto?
– Può il compito essere completato in tempo?

La norma richiede che una procedura documentata con recensioni essere incluso. Il fornitore deve identificare come definire modifiche e gestione dei requisiti di specifica tra cliente e fornitore di contratto.

4. Control Design

4.1. Generale
ISO richiede che si pensa prima di fare e di specificare prima di progettare.

4.2. Progettazione e sviluppo di pianificazione

piano di progetto deve contenere:
– Definizione di metodologia da utilizzare nello sviluppo di Prodotto
– Orari, le responsabilità, gli incarichi di lavoro e controllo avanzamento
– Progetto Fasi sarà diviso. Questo include ingresso, uscita e la verifica di uscita.
– Descrizione dei metodi e degli strumenti da utilizzare

piano di qualità deve contenere:
– gli obiettivi di qualità
– Criteri di accettabilità
– Identificazione di pianificazione, validazione e verifica.
– Le responsabilità per le attività di qualità.

Se una società vuole guadagnare la qualificazione ISO i piani devono essere tenute in tutti i progetti, dal momento che la certificazione ISO è per tutta la società e non per progetti specifici.

4.3 Interfacce organizzativo e tecnico

Se non c’è lavoro di gruppo, le interfacce tra di esse devono essere identificati, documentati e trasmessi a coloro che necessitano di informazioni. La documentazione deve essere riesaminata periodicamente.

4.4 Progettazione di ingresso

Specifiche Requisiti contengono l’input di progettazione nello sviluppo di software. Questo può essere fatto da parte dell’acquirente o preparato dal fornitore con leggi e regolamenti. Un altro input di progettazione comprende codifica disegno che viene usato come input per la codifica.

La norma vuole garantire che il prodotto di lavoro di ogni passo soddisfi i requisiti.

Nello sviluppo di software, modifiche dei requisiti sono comuni quindi una procedura per la gestione dei requisiti nuovi e modificati da parte dell’acquirente essere creato.

4.5 Uscita design

Uscita Design: la documentazione di progetto e il codice sorgente. ISO richiede che i documenti di progettazione e di codificazione essere rivisti prima del rilascio.

dovrebbe essere creato una procedura per l’accettazione della produzione e criteri di accettazione di progettazione.

4.6 Design Review

funzioni di progetto come la codifica e test devono essere presentati alla rassegna. Un metodo comune per assicurare le recensioni sono liste di controllo.

4.7 Design Verification

Si tratta di recensioni, test di modulo e test di integrazione.

4.8 Progettazione di convalida

Prova finale del sistema, del prodotto software completo unitamente alla revisione della documentazione per l’utente. Ci dovrebbe essere pianificato e convalida documentate. Beta testing è in conformità con ISO finché il test beta è coperto da un accordo chiaro tra fornitore e cliente beta-testing.

4.9 Modifiche di progettazione

ISO 9001 prevede che dopo il rilascio dei documenti di progettazione o di sorgente, tutti i cambiamenti devono passare attraverso un processo formale in cui sono documentati, esaminati e approvati prima della loro attuazione modifiche.

modifiche incontrollate ai documenti tecnici complessi o programmi sono estremamente pericolosi e come tali la norma non lo consentano.
5. Documento di dati e controllo

Le informazioni che controlla lo sviluppo / manutenzione di software. La norma richiede che coloro che hanno bisogno di qualche documento / dati ha accesso ad esso. Modifiche a documenti e dati devono essere controllati.

5.1 Generale

documenti esterni ei dati devono essere memorizzati. Può essere conservato in qualsiasi forma (cartaceo, media elettronici).

5.2 documenti e dati di omologazione e di emissione

Prima di rilasciare documenti e dati devono essere esaminati e approvati prima di ogni problema. Un elenco dei documenti in cui si deve scoprire la versione corrente di un documento. documenti non validi o obsoleti devono essere rimossi o chiaramente indicate.

5.3 documenti e le modifiche dei dati

La persona / s responsabile del processo di revisione e approvazione devono essere specificati.

6. acquisto

Nel caso del subappaltatore, non si è ancora responsabile. Cioè se si applica per un contratto e subappaltare i lavori, standard ISO è ancora sotto la vostra responsabilità e requisiti ISO non devono essere imposte al subfornitore.

6.1 Generale

Se la manodopera è stato acquistato, lo standard richiede di seguire una procedura che si ottiene le persone giuste. Le persone saranno controllati da fornitore e non subappaltatore.
Per garantire che il software acquistato sia conforme ai requisiti:
– Requisiti del contratto sulle procedure subappaltatori
– Audit del sistema di qualità subappaltatore
– Controllare subappaltatore rendimento passato
– Indagine il subappaltatore nel corso del contratto
– Revisione e collaudo Witness
– Test e recensione del prodotto di subappaltatore.

6.2 La valutazione dei subappaltatori

Persona con necessaria autorità e competenza giudicherà ogni subappaltatore e decidere se utilizzare. Le decisioni devono essere documentati.

Il fornitore deve decidere che cosa il controllo su subappaltatore avrà. La norma non parlare di quanto controllo si dovrebbe avere. Esso menziona solo che una decisione deve essere effettuato utilizzando i fatti.

Un caso particolare è quando il software viene acquistato tramite vendita al dettaglio. In questo caso subappaltatore è l’organizzazione con cui viene condotta l’acquisto, non lo sviluppatore originale del software.

Se l’acquisto viene fatto attraverso ISO di vendita al dettaglio 9001 richiede che si definisce fino a che punto si mette requisiti sul rivenditore per controllare il suo fornitore.

6.3 Acquisto Data

Requisiti per il processo di sviluppo devono essere documentate nel contratto con i requisiti dei fornitori per l’approvazione di lavoro i risultati e le procedure.

6.4 Verifica del prodotto acquistato

La documentazione delle decisioni circa la verifica di ogni acquistato strumento di sviluppo o di un prodotto incluso.
Non conformità

– Nessun elenco di fornitori approvati
– Controllo inappropriato di subappaltatore
– Nessuna verifica del documento di articoli acquistati
– Contratto di moderatore con subappaltatore.

7 Controllo di fornito dal cliente del prodotto

Il fornitore deve disporre di procedure per la verifica, la conservazione e la manutenzione del software fornito dal cliente. Tuttavia, la qualità è la responsabilità del software.

Un non-conformità accade a causa di responsabilità chiara delle responsabilità tra cliente e fornitore.

8 Specifiche di prodotto e rintracciabilità

Il fornitore del software dovrebbe mantenere il controllo su:
– Su quali precedente documento ed emettere Si basa
– Su quale specifica si basa
– Cosa le correzioni e le modifiche sono state incluse in cui i programmi di origine
– Cosa è successo a ogni rapporto problema
– Da quale fonte è stato generato un modulo specifico.

Controllo di processo 9

procedura documentata per il processo di replica per il funzionamento e la procedura per la movimentazione di maestro Proma € ™ s / librerie. Per garantire che corretto versioni viene utilizzato.

Non conformità
– No procedura documentata per la replica
– Un uso improprio di dischetti maestro Proma € ™ s o.

10 controlli e prove

Le procedure scritte per l’ispezione e il collaudo da fare in relazione con la replica.

Non conformità
– Funzione di controllo automatico Proma € ™ s non è stata ispezionata
– No procedura documentata per testare Proma € ™ s.

11 Controllo di ispezione, di misura e di prova

Il fornitore deve selezionare il dispositivo di misura appropriata e seguire una procedura documentata per il controllo delle apparecchiature. Ogni nuova versione del software dovrebbe essere testato per la sufficienza.

12 Ispezione e test di stato

Specifiche e programmi dovrebbero verificata attraverso recensioni e test. Il fornitore deve disporre di procedure che vietano l’utilizzo di specifiche o programmi non verificati.

13 Controllo dei prodotti non conformi

prodotti non conformi non dovrebbero essere usati inavvertitamente. deve essere creata una procedura di gestione delle modifiche rapide in caso di errori critici.

– Una chiara identificazione dei prodotti controllati che contengono errori non corretti
– Metodo di suscitare l’accettazione del cliente al momento della consegna
– In caso di modifiche rapide, occorre documentare
– Rivedere gli elementi in modo modificati sarà elevata al medesimo status resto del software.

14 azioni correttive e preventive

– La gestione efficace dei rapporti non conformi ai requisiti di
– La gestione efficace dei rapporti che indicano carenze nel processo di sviluppo
– La raccolta e l’analisi delle informazioni disponibili sul prodotto e di processo non conformità e azioni di prevenzione attiva.

Informazioni su problemi incontrati dovrebbe guidare il miglioramento del processo di sviluppo.

Non conformità
– Denuncia Cliente non è stato correttamente gestito
– La carenza è stata trovata, ma non corretto
– No procedura per garantire che i problemi vengono analizzati e si concentrano su
– No procedura per segnalare le difficoltà con l’applicazione di regole e procedure.

15 movimentazione, stoccaggio, imballaggio, conservazione e consegna

Si applica a software replicati su PROM, disco o altro supporto.
Supporti devono essere etichettate e imballate in modo corretto. I dati devono essere eseguito il backup. Ci dovrebbe essere anche in grado di fornire protezione da danni accidentali.

16 Controllo di Qualità Records

documenti di qualità dimostrano che sono state realizzate azioni per garantire o controllare la qualità. Lo standard richiede che ci sia una procedura per la gestione delle registrazioni di qualità. Le registrazioni devono essere conservati in modo appropriato in modo che siano facilmente accessibili.
Non conformità:
– Non ci sono regole per la conservazione delle registrazioni di qualità
– Record Review non vengono conservati
– Certificato di prova non vengono conservati
– Periodo di tenuta della documentazione di qualità non è definito

Verifiche 17 interni di qualità

Ci dovrebbe essere un’entità indipendente che le verifiche regolarmente tutte le operazioni che possono influenzare prodotto o un servizio di qualità. Questi sono condotte per conto della gestione aziendale. Ci dovrebbe essere un piano di audit.

Non conformità
– Nessun piano di revisione
– Piano di Audit non aggiornati

18 Training

Società dovrebbe assicurare che il personale è addestrato per compiti richiesti. Una procedura per:
– Identificare le necessità di formazione per ogni posizione personale
– Fornire tale formazione
– Tenere un registro della formazione di tutto il personale.

La formazione dovrebbe essere documentato e sufficiente. Con sufficiente intendiamo che la persona sia in grado di svolgere la sua / suo lavoro ad un livello sufficientemente elevato.

Non conformità
– Non ci sono procedure per la pianificazione o di formazione
– No records di formazione
– Non ha ricevuto una formazione adeguata per il suo compito.

19 Manutenzione

Il fornitore deve disporre di procedure documentate per la manutenzione, se questo è menzionato nel contratto. Nel software si tratta di correzioni di errori e miglioramenti al software fornito.

Procedure per la gestione dei reclami e delle richieste di modifiche. Il fornitore non è tenuto a fornire la manutenzione se non è menzionato nel contratto. Le procedure di manutenzione per i vecchi software devono essere effettuate.

Non conformità
– Lavori di manutenzione per un cliente senza contratto
– Metodi specifici per la manutenzione del vecchio prodotto non è documentata
– No procedura per il test dopo la manutenzione.

20 Tecniche statistiche

Ci dovrebbe essere raccolta e l’analisi dei dati relativi a numero di errori rilevati nelle diverse fasi. Informazioni su incapacità di rispettare le scadenze e le tappe dovrebbe essere analizzato.

“————————————————– ————————————————– ————————————————–

————————————————– ————————————————– ————————————————–
ISO 9001二十品質要素

外観はソフトウェアを開発する企業の観点から要件で撮影されます。 ISO 9001規格は、製造業を対象としました。要件は、ISO 9000から3とTickITに基づいてソフトウェア開発のために解釈されます。





– 品質へのmanagement’sのコミットメントを定義します。
– つまり、どのような管理は品質手段により、品質に関するA社€™sの目標を定義
– customerâの€の™sのニーズに関連して
– 組織内で理解されます
– 実装されます


– あまりにも漠然とまたはポリシーステートメントは、スタッフによって理解されていません
– 品質方針は実装されていません。








– 満たすことができない責任の既存の。


– プロジェクト・ライン
– プロジェクト – 顧客
– プロジェクト・保守団体
– ソフトウェア開発 – ハードウェア開発
– メンテナンス組織ヘルプデスク
– 販売開発

– リソースの要件を特定します
– 訓練された人材を割り当てます。

– 同社は、ISO 9001での要件を満たしていることを確認してください
– 企業経営への品質システムのパフォーマンスを報告


– 品質監査
– 品質苦情の統計
– 是正処置の記録



品質を実現するためのœthe組織構造、責任、手順、プロセス及び資源€€ “”ââ品質システムmanagement.â€

手順、ルール、意思決定は、書面に入れなければなりません。あなたは、ISO 9001によって必要とされていないルールや手順を使用している場合、標準はまだそれが書かれている必要があります。



– 監査は、試料中の、そこにマイナーな不適合があり、それらが固定されている場合、監査人は、より多くのマイナーな不適合があることを疑うことができるので、したがって、それはまだ非適合することができ、サンプルです。
– 既存の手順書はに付着されていません。



– 要求事項は文書化され、理解されていますか?
– 合格基準は含まれていますか?
– 入札とは異なる要件が解決されていますか?
– サプライヤーは、契約のための十分なリソースを集めることができますか?
– サプライヤーは、契約に必要な力量を集めることができますか?
– タスクが時間内に完了することができますか?





– 製品の開発に使用される方法論の定義
– タイムスケジュール、責任、作業割り当てと進捗管理
– フェーズプロジェクトが分割されます。これは、入力、出力および出力の確認を含みます。
– 使用する手法やツールの説明

– 品質目標
– 受容性の基準
– 計画、妥当性確認及び検証の同定。
– 品質活動のための責任。









デザイン出力:設計ドキュメントやソースコード。 ISOは、その設計文書を必要とし、コーディングはリリース前に見直されます。









ISO 9001は、設計文書またはソースのリリース後、すべての変更は、変更は、文書化検討し、実施する前に承認され、正式なプロセスを通過しなければならないことが必要です。








レビューおよび承認プロセスの担当者/ sが指定されなければなりません。




– 下請業者の手続きに関する契約要件
– 下請けの品質システムの監査
– パフォーマンス過去チェック下請け
– 契約時の下請けを調査
– 証人のレビューとテスト
– 下請けのテストとレビュー製品。










– 承認されたサプライヤーのいかなるリストはありません
– 下請けの不適切な制御
– 購入したアイテムのいかなる文書検証ません
– 外注先との不適切な契約。





– ドキュメントを先行し、それを発行するものに基づいています
– それが基づいている仕様に
– どのような修正と改正ソースプログラムに含まれています
– 各問題レポートに何が起こりました
– どのようなソースから特定のモジュールが生成されました。



– レプリケーション用ませ文書化された手順はありません
– マスターPROMA€™sのまたはフロッピーディスクの不適切な取り扱い。



– 自動的にPROMA€™sのをチェックする機能が検査されていません
– いいえPROMA€™sのをテストするための手順を文書化していません。







– 未修正のエラーを含む制御項目のクリア識別
– 配送時に顧客の検収を誘発する方法
– 迅速な修正の場合には、文書化されなければなりません
– レビューので、変更された項目は、ソフトウェアの他の部分と同じステータスに昇格されます。


– 要求事項に適合していないレポートの効果的な取り扱い
– 開発プロセスの短期歳入を示す報告書の効果的な取り扱い
– 製品やプロセスの不適合処置及び予防処置に関する入手可能な情報の積極的な収集と分析。


– 顧客の苦情が適切に処理されていません
– 欠乏が見つかりましたが修正されていないされています
– 問題を分析し、作用していることを確実にするん手順はありません
– 規則と手順を適用することで問題を報告するための無手順。




– 品質記録の保持のためにはルールはありません
– レビューレコードは保持されません
– テストの記録は保持されません
– 品質記録を維持する期間が定義されていません



– いいえ、監査計画はありません
– ない日までの監査計画


– 各スタッフの位置のためのトレーニングニーズを特定
– そのようなトレーニングを提供
– すべてのスタッフの訓練の記録を保管してください。


– 計画や訓練のための無手順はありません
– いいえ、トレーニングレコードはありません
– 彼または彼女のタスクのための適切な訓練を受けていません。




– 契約なしの顧客のためのメンテナンス作業
– 古い製品のメンテナンスのための具体的な方法が記載されていません
– メンテナンス後のテストのための無手順。



“————————————————– ————————————————– ————————————————–

translation Support:
————————————————– ————————————————– ————————————————–
ISO 9001 Twenty Quality Unsur

A dipikir bakal dijupuk ing syarat saka viewpoint perusahaan ngembangaken lunak. ISO standard 9001 iki dimaksudaké kanggo industri Manufaktur. Syarat sing Juru kanggo pembangunan lunak sesuai karo ISO 9000-3 lan TickIT.

Ana 20 unsur utama. Saben konsèp iki uga dikenal ing masyarakat Manajemen kualitas.

1. Management Responsibility

1.1 privasi Quality

Standar mbutuhake Manajemen supplier kanggo ngetokake kawicaksanan kualitas, ing ngendi iku ngandika perusahaan bakal ngasilaké produk kualitas.

Kualitas privasi bakal:
– Netepake managementâ € ™ s prasetya kualitas
– Netepake dislametaké ing companyâ € ™ s babagan kualitas, sing, apa Manajemen tegese dening kualitas
– Aja cocog kanggo kabutuhan customerâ € ™ s
– Bisa mangertos ing organisasi
– Bisa ginakaken


– Statement banget samar utawa privasi wis ora dimangertèni Staff
– Privasi Quality ora ginakaken.

Contone privasi Quality

â € œWe entuk kualitas liwat Staff motivasi lan trampil, tata cara karya ditetepake, lan review intensif lan Testing € activities.â

1.2 Organisasi

Standar mbutuhake dokumentasi tanggung jawab, panguwasa lan interrelation kabeh personel nggowo pengaruh kualitas. Iki tegese yen wong wis tanggung jawab, iku bakal resmi diutus dening manager cocok. wong sing duwe wewenang kanggo nepaki tanggung jawab.

Miturut ISO, tanggung jawab tegese:

â € œa tugas kanggo tumindak ing oneâ € ™ s kasepakatan dhewe yen soko wis bisa rampung tanpa toldâ €.


– Ana kang tanggung jawab sing ora bisa kawujud.


– Project-line
– Project-customer
– Organisasi Project-maintenance
– Pembangunan Software pembangunan-hardware
– Maintenance organisasi-bantuan mejo
– Sales-pembangunan

Resources mbutuhake sing Supplier:
– Ngenali syarat kanggo sumber
– Nemtokake personel dilatih.

wakil Management mbutuhake janjian saka wakil manager karo panguwasa lan tanggung jawab kanggo:
– Njamin sing perusahaan nerak syarat ing ISO 9001
– Report kinerja saka sistem kualitas kanggo management company

1.3 Review Management

manager Quality kudu periodik saiki asil
– Audit Quality
– Statistik keluhan kualitas
– Records saka tumindak mbenakake

Asil kudu presented ing rapat Manajemen direkam karo cathetan ing sing dirawuhi, apa iki presented lan apa pancasan dijupuk lan digawe.

2. System Quality

sistem Quality â € “”â € œthe struktur organisasi, Responsibilities, tata cara, pangolahan lan sumber daya kanggo nindakaken kualitas management.â €

Tata cara, aturan, pancasan bakal sijine menyang nulis. Yen sampeyan duwe aturan utawa prosedur sing ora dibutuhaké déning ISO 9001, standar isih mbutuhake sing ditulis.

A manual kualitas bakal ngemot referensi lan dokumentasi sistem kualitas.


– Lan audit punika sampel, mulane yen ing sampel, ana suntingan non-conformances, lan padha sing tetep, isih bisa dadi non-kataatan amarga auditor bisa Suspect sing ana akeh liyane suntingan non-conformances.
– Ana ditulis tata cara sing ora nganut.

3. Contract Review

Kir supplier sadurunge contract tondo asto sing organisasi bisa nindakake apa dibutuhake dening kontrak.

Pitakonan sing kudu takon kalebu:
– Apa syarat nyathet lan mangertos?
– Apa kritéria acceptance klebu?
– Wis syarat bedo saka tender ing sampun mantun?
– Bisa Supplier muster cukup sumber daya kanggo kontrak?
– Bisa Supplier muster kepinteran needed kanggo kontrak?
– Bisa tugas rampung ing wektu?

Standar mbutuhake prosedur nyathet karo reviews kalebu. Supplier kudu ngenali carane amandemen kontrak lan penanganan syarat specification antarane customer lan supplier ditetepake.

4. Control Design

4.1. Umum
ISO mbutuhake rencana sadurunge dilakoni lan nemtokake sadurunge ngrancang.

4.2. Desain lan Development Planning

rencana Design kudu ngemot:
– Definition of Tata kanggo digunakake ing pangembangan prodhuk
– Jadwal Time, Responsibilities, assignments karya lan kontrol proses
– Project Wulan bakal dibagi. Iki kalebu input, output lan verifikasi saka output.
– Katrangan cara lan pribadi kanggo digunakake

rencana Quality kudu ngemot:
– Target Quality
– Kriteria ditrimané
– Identification planning, Validation verifikasi.
– Lowongan Kerja for aktivitas kualitas.

Yen perusahaan kepengin kanggo gain kualifikasi ISO plans kudu dianakaké ing kabèh proyèk-proyèk, wiwit sertifikat ISO iku kanggo kabèh lan ora kanggo proyek tartamtu.

4.3 Interfaces Organizational lan Technical

Yen ana grup-karya, antar muka antarane wong-wong mau kudu dikenali, nyathet lan ditularaké wong perlu informasi. Dokumentasi bakal dideleng ajeg.

4.4 Design Input

Requirements specifications ngemot input desain ing Software. Iki bisa rampung dening bakul utawa disiapake dening Supplier nggunakake hukum lan angger. input desain liyane kalebu desain werna kang digunakake minangka input kanggo werna.

Standar kepengin kanggo mesthekake yen produk karya saben langkah meets syarat.

Ing Software, owah-owahan requirement sing umum supaya prosedur kanggo nangani syarat anyar lan diganti saka bakul digawe.

4.5 Design Output

Desain Output: direksa desain lan kode sumber. ISO mbutuhake dokumen desain lan werna dideleng sadurunge release.

A prosedur kanggo nampi output desain lan kriteria acceptance kudu digawe.

4.6 Design Review

fungsi Project kaya werna lan testing bakal presented ing review ing. A cara umum kanggo njupuk review checklists.

4,7 Design Verifikasi

Iki dumadi saka reviews, testing modul lan testing integrasi.

4.8 Design Validation

test Final sistem, prodhuk software lengkap bebarengan karo Reviewing dokumentasi user. Ana kudu ngrancang lan nyathet Validation. testing Beta ing kataatan karo ISO anggere minangka testing beta dijamin dening persetujuan cetha antarane supplier lan beta-testing customer.

4,9 Design Éwah

ISO 9001 mbutuhake sawise release dokumentasi desain utawa sumber, kabeh owah-owahan bakal lunga liwat proses formal ngendi owah-owahan sing nyathet, dideleng lan disetujoni sadurunge implementasine.

owah-owahan Uncontrolled dokumen technical Komplek utawa program iku arang banget mbebayani lan minangka standar kuwi ora ngidini.
5. Document lan Control Data

Informasi sing kontrol ing pembangunan / pangopènan lunak. Standar mbutuhake sing perlu sawetara document / data bakal duwe akses kanggo iku. Pangowahan dokumen lan data bakal kontrol.

5.1 Umum

dokumen njaba lan data bakal disimpen. Bisa disimpen ing wangun (hard copy, media elektronik).

5.2 Document lan persetujuan Data lan ngetokake

Sadurunge dokumen Jeksa Agung bisa ngetokake lan data bakal dideleng lan disetujoni sadurunge saben masalah. A dhaftar document kang siji bakal mangerteni versi saiki document. dokumen salah utawa lungse kudu dibusak utawa cetha ditandhani.

5.3 Document lan Data Éwah

Wong / ing pangisian daya saka review lan disetujoni proses bakal kasebut.

6. Purchasing

Ing cilik saka subcontractor, sampeyan isih tanggung jawab. I.e. yen aplikasi kanggo kontrak lan subcontract karya, standar ISO isih ing tanggung jawab lan syarat ISO ora kudu dileksanakake ing subcontractor.

6.1 Umum

Yen Cacahing anggota wis dituku, standar mbutuhake sampeyan tindakake prosedur sing njaluk wong tengen. Wong bakal kontrol kanthi Supplier lan ora subcontractor.
Kanggo mesthekake yen software dituku sesuai kanggo syarat:
– Syarat Contract ing tata cara subcontractors
– Audit saka sistem kualitas subcontractor
– Priksa subcontractor kepungkur kinerja
– Survey subcontractor sak kontrak
– Review Seksi lan testing
– Test lan produk review saka subcontractor.

6.2 Evaluasi subcontractors

Wong karo panguwasa lan kepinteran perlu bakal ngadili saben subcontractor lan mutusaké apa kanggo nggunakake. Pancasan bakal nyathet.

Supplier bakal arep apa kontrol liwat subcontractor bakal duwe. Standar ora sebutno pinten kontrol sampeyan kudu duwe. Iku mung nyebataken sing kaputusan kudu digawe dening nggunakake bukti.

A mliginipun nalika lunak wis dituku liwat toko. Ing kasus iki subcontractor organisasi kang tuku wis conducted, ora pangembang asli saka piranti lunak.

Yen purchasing wis rampung liwat ISO toko 9001 mbutuhake sing netepake kanggo apa ombone sijine syarat ing toko kanggo ngontrol supplier sawijining.

6.3 Data Purchasing

Requirements ing proses pembangunan bakal nyathet ing kontrak bebarengan karo syarat supplier sarujuk asil karya lan tata cara.

6.4 Verifikasi Product dituku

Dokumentasi pancasan bab verifikasi saben dituku alat pembangunan utawa produk klebu.

– Ora dhaftar penyedia disetujoni
– Kontrol Inappropriate saka subcontractor
– Ora verifikasi document item dituku
– Contract Inappropriate karo subcontractor.

7 Kontrol Product Customer-diwenehake

Supplier bakal duwe tata cara kanggo verifikasi, panyimpenan lan pangopènan customer diwenehake lunak. Nanging, kualitas tanggung jawab saka piranti lunak.

A non-kataatan mengkono amarga tanggung jawab cetho saka tanggung jawab antarane customer lan supplier.

8 Keterangan Product lan Traceability

Supplier lunak kudu njaga kontrol ing:
– Apa sadurunge document lan ngetokake iku adhedhasar
– On kang specification iku adhedhasar
– Apa mbenerake lan amandemen wis klebu ing kang program sumber
– Apa kedaden kanggo saben laporan masalah
– Saka apa sumber iki modul tartamtu kui.

9 Process Control

Nyathet prosedur kanggo proses replikasi ing operasi lan prosedur kanggo jawab master PROMâ € ™ s / Pustaka. Kanggo mesthekake yen versioning bener digunakake.

– Ora nyathet prosedur kanggo réplikasi
– Jawab wajar saka master PROMâ € ™ s utawa diskettes.

10 pengawasan lan Testing

tata cara kang ditulis ing pengawasan lan testing rampung karo réplikasi.

– Fungsi saka otomatis mriksa PROMâ € ™ s durung periksa
– Ora nyathet prosedur kanggo Testing PROMâ € ™ s.

11 Kontrol pengawasan, Measuring & Peralatan Test

Supplier kudu milih peralatan ukur cocok lan tindakake prosedur nyathet kanggo kontrol saka peralatan. Saben versi piranti lunak anyar kudu dites kanggo dosané.

12 pengawasan lan Status Test

Specifications lan program kudu diverifikasi liwat reviews lan testing. Supplier bakal duwe tata cara sing nglarang nggunakake specifications utawa program unverified.

13 Kontrol Non-kontek Product

produk non-kontek ngirim ora digunakake sengaja. A prosedur kanggo nangani modifikasi cepet ing cilik saka kasalahan kritis kudu digawe.

– Clear identifikasi item kontrol sing ngemot kasalahan uncorrected
– Cara kanggo elicit acceptance customer marang layang
– Ing cilik saka modifikasi cepet, iku kudu nyathet
– Reviewing item supaya dipunéwahi bakal munggah pangkat kanggo status padha liyane lunak.

14 Tindakan Mbenakake lan Nyegah

– Jawab Efektif laporan sing ora salaras kanggo syarat
– Jawab Efektif laporan nuduhake short-comings ing proses pembangunan
– Koleksi Active lan analisis informasi ngenani produk lan proses non-kataatan lan tumindak nyegah.

Informasi bab masalah pinanggih ngirim drive dandan saka proses pembangunan.

– Complaint Customer durung ditangani mlaku
– Kurang wis ketemu nanging ora didandani
– Ora prosedur kanggo mesthekake yen masalah sing analisa lan tumindhak marang
– Ora prosedur kanggo nglaporake kangelan karo nglamar aturan lan tata cara.

15 Penanganan, Storage, Packaging, Preservation lan Delivery

Ditrapake kanggo software replicated ing nari, disk utawa medium liyane.
Media bakal cap lan rangkep bener. Data bakal digawe serep. Ana uga kudu kemampuan kanggo nyedhiyani pangayoman saka karusakan unintentional.

16 Kontrol Quality Records

dokumen Quality nuduhake tumindak wis dijupuk kanggo mesthekake utawa mriksa kualitas. Standar mbutuhake ana prosedur kanggo nangani saka cathetan kualitas. Cathetan kudu disimpen ing proses cocok supaya padha gampang diakses.
– Ana aturan kanggo penylametan cathetan kualitas
– Cathetan Review ora katahan
– Cathetan Test ora katahan
– Periode tetep cathetan kualitas ora ditetepake

17 Quality Internal audit

Ana sing arep entitas sawijining sing ajeg audit kabeh operasi sing uga mengaruhi kualitas produk utawa layanan. Iki sing conducted atas jenenge management company. Ana sing arep rencana audit.

– Ora rencana audit
– Rencana Audit ora gaul

18 Training

Company kudu mesthekake Staff sing dilatih kanggo tugas dibutuhake. A prosedur kanggo:
– Ngenali kabutuhan training kanggo saben posisi Staff
– Nyedhiyani latihan kasebut
– Tansah cathetan saka latihan saka kabeh anggota Staff.

Training kudu nyathet lan cekap. Miturut cekap kita nedya sing wong saged Performing / kang karya dheweke kanggo standar dhuwur.

– Ora tata cara kanggo planning utawa training
– Ora cathetan training
– Ora nampa latihan suwene kanggo tugas utawa dheweke.

19 Servicing

Supplier bakal wis nyathet tata cara kanggo pelayanan yen iki kasebut ing kontrak. Ing lunak iku bab mbenerake kesalahan lan dandan kanggo lunak dikirim.

Tata cara kanggo nangani keluhan lan panjalukan kanggo modifikasi. Supplier ora kapekso kanggo nyedhiyani maintenance yen ora kasebut ing kontrak. tata cara Maintenance kanggo software lawas kudu digawe.

– Karya Maintenance kanggo customer tanpa kontrak
– Cara spesifik kanggo pangopènan produk lawas wis ora nyathet
– Ora prosedur kanggo testing sawisé pangopènan.

20 Techniques Statistical

Ana sing arep koleksi lan analisis data sawetara kasalahan ditemokaké ing fase beda. Information about kasekengan ketemu wates lan tondo kudu analisa.

“————————————————– ————————————————– ————————————————–

ಅನುವಾದ ಬೆಂಬಲ:
————————————————– ————————————————– ————————————————–
ಐಎಸ್ಒ 9001 ಟ್ವೆಂಟಿ ಗುಣಮಟ್ಟದ ಅಂಶಗಳನ್ನು

ಒಂದು ನೋಟ ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ ಕಂಪನಿಗಳು ದೃಷ್ಟಿಕೋನದಿಂದ ಅವಶ್ಯಕತೆಗಳನ್ನು ನಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗುವುದು. ಐಎಸ್ಒ 9001 ಪ್ರಮಾಣಿತ ತಯಾರಿಕಾ ಉದ್ಯಮದಲ್ಲಿ ಉದ್ದೇಶಿಸಲಾಗಿತ್ತು. ಅವಶ್ಯಕತೆಗಳನ್ನು ಐಎಸ್ಒ 9000-3 ಮತ್ತು TickIT ಅನುಗುಣವಾಗಿ ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದಾರೆ.

20 ಮುಖ್ಯ ಅಂಶಗಳಿವೆ. ಪ್ರತಿ ಪರಿಕಲ್ಪನೆಯ ಜೊತೆಗೆ ಗುಣಮಟ್ಟ ನಿರ್ವಹಣಾ ಸಮುದಾಯದಲ್ಲಿ ಕರೆಯಲಾಗುತ್ತದೆ.

1. ನಿರ್ವಹಣಾ ಜವಾಬ್ದಾರಿ

1.1 ಗುಣಮಟ್ಟ ನಿಯಮ

ಪ್ರಮಾಣಿತ ಕಂಪೆನಿಯು ಗುಣಮಟ್ಟದ ಉತ್ಪನ್ನಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಹಾಗಿಲ್ಲ ಹೇಳುತ್ತಾರೆ ಅಲ್ಲಿ ಒಂದು ಗುಣಮಟ್ಟ ನಿಯಮ, ವಿತರಿಸುವ ಪೂರೈಕೆದಾರ ನಿರ್ವಹಣೆ ಅಗತ್ಯವಿದೆ.

ಗುಣಮಟ್ಟ ನಿಯಮ ಶಲ್:
– ಗುಣಮಟ್ಟದ managementâ € ™ ರು ಬದ್ಧತೆ ವಿವರಿಸಿ
– ಎಂದು, ಏನು ನಿರ್ವಹಣಾ ಗುಣಮಟ್ಟವನ್ನು ಮೂಲಕ ಎಂದರೆ, ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ಒಂದು companyà € ™ ರು ಉದ್ದೇಶಗಳನ್ನು ವಿವರಿಸಿ
– Customerâ € ™ ರು ಅಗತ್ಯಗಳಿಗೆ ಪ್ರಸ್ತುತವಾಗಿರಿ
– ಸಂಸ್ಥೆಯ ತಿಳಿಯಬಹುದು
– ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು

ಅಲ್ಲದ conformances

– ಹೇಳಿಕೆ ಸಂದಿಗ್ಧ ಅಥವಾ ನೀತಿ ಸಿಬ್ಬಂದಿ ಇರುವುದು
– ಗುಣಮಟ್ಟ ನಿಯಮ ಅಳವಡಿಸಲಾಗಿಲ್ಲ.

ಉದಾಹರಣೆಗೆ ಗುಣಮಟ್ಟದ ನಿಯಮದ

ಒಂದು € ನಾವು ಪ್ರೇರೇಪಣೆ ಮತ್ತು ನುರಿತ ಸಿಬ್ಬಂದಿ ಮೂಲಕ ಗುಣಮಟ್ಟ, ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಕೆಲಸ ಕಾರ್ಯವಿಧಾನಗಳು, ಮತ್ತು ತೀವ್ರ ವಿಮರ್ಶೆ ಮತ್ತು activities.â € ಪರೀಕ್ಷೆ ಸಾಧಿಸಲು

1.2 ಸಂಸ್ಥೆ

ಪ್ರಮಾಣಿತ ಜವಾಬ್ದಾರಿ, ಅಧಿಕಾರ ಮತ್ತು ಗುಣಮಟ್ಟದ ಮೇಲೆ ಪರಿಣಾಮ ಎಲ್ಲಾ ಸಿಬ್ಬಂದಿ ಪರಸ್ಪರ ಸಂಬಂಧವನ್ನು ದಾಖಲೆಯು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಈ ವ್ಯಕ್ತಿಯ ಜವಾಬ್ದಾರಿ ವೇಳೆ, ಇದು ವಿಧ್ಯುಕ್ತವಾಗಿ ಸೂಕ್ತ ಮ್ಯಾನೇಜರ್ ಅದಕ್ಕೆ ಹಾಗಿಲ್ಲ ಎಂದು ಅರ್ಥ. ವ್ಯಕ್ತಿ ಜವಾಬ್ದಾರಿ ಪೂರೈಸಲು ಅಧಿಕಾರ ಇರಬೇಕು.

ಐಎಸ್ಒ ಪ್ರಕಾರ, ಜವಾಬ್ದಾರಿ ಅರ್ಥ:

ಒಂದು ಏನೋ toldâ € ಇಲ್ಲದೆ ಮಾಡಬೇಕು ಮಾಡಿದಾಗ € œa ಕರ್ತವ್ಯ oneâ € ™ ರು ಆದ ಒಪ್ಪಂದದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು.

ಅಲ್ಲದ ಅನುಸರಣೆಗೆ

– ಎಂದು ಮುಗಿಸಲಾಗುತ್ತದೆ ಒಂದು ಜವಾಬ್ದಾರಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ.


– ಪ್ರಾಜೆಕ್ಟ್ ಲೈನ್
– ಪ್ರಾಜೆಕ್ಟ್ ಗ್ರಾಹಕ
– ಪ್ರಾಜೆಕ್ಟ್ ನಿರ್ವಹಣಾ ಸಂಸ್ಥೆ
– ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿ-ಯಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ
– ಮೇಂಟೆನೆನ್ಸ್ ಸಂಸ್ಥೆ ಸಹಾಯಕ
– ಮಾರಾಟದ ಅಭಿವೃದ್ಧಿ

ಸಂಪನ್ಮೂಲಗಳು ಪೂರೈಕೆದಾರ ಅನಿವಾರ್ಯವಾಗುತ್ತದೆ:
– ಸಂಪನ್ಮೂಲಗಳು ಅವಶ್ಯಕತೆಗಳನ್ನು ಗುರುತಿಸಿ
– ತರಬೇತಿ ಸಿಬ್ಬಂದಿ ನಿಗದಿಪಡಿಸಿ.

ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಪ್ರತಿನಿಧಿ ಅಧಿಕಾರ ಮತ್ತು ಜವಾಬ್ದಾರಿ ಮ್ಯಾನೇಜರ್ ಪ್ರತಿನಿಧಿ ನೇಮಕ ಅಗತ್ಯವಿದೆ:
– ಕಂಪನಿ ISO 9001 ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ
– ಕಂಪನಿ ನಿರ್ವಹಣೆಗೆ ಗುಣಮಟ್ಟ ವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯನಿರ್ವಹಣಾ ವರದಿಗಳು

1.3 ನಿರ್ವಹಣಾ ಅವಲೋಕನ

ಗುಣಮಟ್ಟ ಮ್ಯಾನೇಜರ್ ನಿಯತಕಾಲಿಕವಾಗಿ ಫಲಿತಾಂಶಗಳು ಪ್ರಸ್ತುತ ಬೇಕು
– ಗುಣಮಟ್ಟದ ಲೆಕ್ಕ ಪರಿಶೋಧನೆ
– ಗುಣಮಟ್ಟದ ದೂರುಗಳನ್ನು ಅಂಕಿಅಂಶ
– ಸೂಕ್ತ ಕ್ರಮಗಳನ್ನು ದಾಖಲೆಗಳು

ಫಲಿತಾಂಶಗಳು ಪ್ರಸ್ತುತ ಮತ್ತು ಯಾವ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಮತ್ತು ಮಾಡಿದ ಯಾವ ಹಾಜರಾಗಿದ್ದ ಟಿಪ್ಪಣಿಗಳು, ರೆಕಾರ್ಡ್ ನಿರ್ವಹಣೆ ಸಭೆಯಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಮಾಡಬೇಕು.

2. ಗುಣಮಟ್ಟದ ವ್ಯವಸ್ಥೆಯ

ಗುಣಮಟ್ಟ ವ್ಯವಸ್ಥೆಯ € “”ಒಂದು € œThe ಸಾಂಸ್ಥಿಕ ರಚನೆ, ಹೊಣೆಗಾರಿಕೆಗಳು, ವಿಧಾನಗಳು, ಗುಣಮಟ್ಟದ management.â € ಅನುಷ್ಠಾನಕ್ಕೆ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು

ವಿಧಾನಗಳು, ನಿಯಮಗಳು, ನಿರ್ಧಾರಗಳನ್ನು ಬರವಣಿಗೆ ಆರಂಭವಾಯಿತು ಹಾಗಿಲ್ಲ. ನೀವು ಒಂದು ನಿಯಮ ಅಥವಾ ISO 9001 ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ವಿಧಾನ ಹೊಂದಿದ್ದರೆ, ಪ್ರಮಾಣಿತ ಇನ್ನೂ ಇದು ಬರೆಯಲಾಗುತ್ತದೆ ಅಗತ್ಯವಿದೆ.

ಒಂದು ಗುಣಮಟ್ಟದ ಕೈಪಿಡಿ ಗುಣಮಟ್ಟ ವ್ಯವಸ್ಥೆಯ ಉಲ್ಲೇಖ ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಹಾಗಿಲ್ಲ.

ಅಲ್ಲದ ಅನುಸರಣೆಗೆ

– ಒಂದು ಆಡಿಟ್ ಮಾದರಿಯನ್ನು, ಆದ್ದರಿಂದ ಒಂದು ಮಾದರಿ, ಅಲ್ಲಿ ಸಣ್ಣ conformances ಅಲ್ಲದ, ಮತ್ತು ಅವರು ಪರಿಹರಿಸಲಾಗಿದೆ, ಆಡಿಟರ್ ಹೆಚ್ಚು ಅನೇಕ ಸಣ್ಣ conformances ಅಲ್ಲದ ಇವೆ ಸಂಶಯಗಳಿಗೆ ಏಕೆಂದರೆ ಇದು ಇನ್ನೂ ಒಂದು ಅನುಸರಣೆಗೆ ಅಲ್ಲದ ಮಾಡಬಹುದು.
– ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬರೆದ ವಿಧಾನಗಳು ಅಂಟಿಕೊಂಡಿದ್ದರು ಇಲ್ಲ.

3. ಕಾಂಟ್ರಾಕ್ಟ್ ರಿವ್ಯೂ

ಸಹಿ ಒಪ್ಪಂದ ಮೊದಲು ಪೂರೈಕೆದಾರ ಚೆಕ್ ಸಂಸ್ಥೆಯ ಒಪ್ಪಂದದ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು.

ಮಾಡಬೇಕು ಕೇಳಲಾಗುತ್ತದೆ ಪ್ರಶ್ನೆಗಳು ಸೇರಿವೆ:
– ಅವಶ್ಯಕತೆಗಳನ್ನು ದಾಖಲಿಸಲಾಗಿದೆ ಮತ್ತು ತಿಳಿಯಬಹುದು?
– ಮಾನದಂಡವನ್ನು ಒಳಗೊಂಡಿದೆ?
– ಕೋಮಲ ಭಿನ್ನವಾಗಿರುವ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ ಮಾಡಲಾಗಿದೆ?
– ಪೂರೈಕೆದಾರ ಒಪ್ಪಂದಕ್ಕೆ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವಲ್ಲಿ ಮಾಡಬಹುದು?
– ಪೂರೈಕೆದಾರ ಒಪ್ಪಂದ ಬೇಕಾದ ಸಾಮರ್ಥ್ಯವನ್ನು ಗೋ ಮಾಡಬಹುದು?
– ಕಾರ್ಯ ಸಮಯದಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಿದ ಮಾಡಬಹುದು?

ಪ್ರಮಾಣಿತ ವಿಮರ್ಶೆಗಳನ್ನು ಒಂದು ದಾಖಲಿತ ವಿಧಾನ ಸೇರಿಸಲಾಗುವುದು ಅಗತ್ಯವಿದೆ. ಪೂರೈಕೆದಾರ ಒಪ್ಪಂದ ತಿದ್ದುಪಡಿಗಳನ್ನು ಮತ್ತು ಗ್ರಾಹಕ ಹಾಗೂ ಸರಬರಾಜುದಾರ ಅವಶ್ಯಕತೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟತೆಯ ನಿರ್ವಹಣೆ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು ಹೇಗೆ ಗುರುತಿಸಲು ಮಾಡಬೇಕು.

4. ಡಿಸೈನ್ ಕಂಟ್ರೋಲ್

4.1. ಜನರಲ್
ಐಎಸ್ಒ ನೀವು ಮಾಡುವ ಮೊದಲು ಯೋಜನೆ ಮತ್ತು ವಿನ್ಯಾಸ ಮೊದಲು ಸೂಚಿಸಲು ಅಗತ್ಯವಿದೆ.

4.2. ವಿನ್ಯಾಸ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಯೋಜನಾ

ವಿನ್ಯಾಸ ಯೋಜನೆ ಹೊಂದಿರಬೇಕು:
– ವಿಧಾನ ವ್ಯಾಖ್ಯಾನ ಉತ್ಪನ್ನದ ಅಭಿವೃದ್ಧಿ ಬಳಸಲಾಗುತ್ತದೆ
– ಟೈಮ್ ಶೆಡ್ಯೂಲ್, ಹೊಣೆಗಾರಿಕೆಗಳು, ಕೆಲಸ ಕಾರ್ಯಯೋಜನೆಯು ಮತ್ತು ಪ್ರಗತಿ ನಿಯಂತ್ರಣ
– ಹಂತಗಳು ಯೋಜನೆಯ ವಿಂಗಡಿಸಬಹುದು. ಈ ಇನ್ಪುಟ್, ಉತ್ಪಾದನೆ ಮತ್ತು ಉತ್ಪಾದನೆಯ ಪರಿಶೀಲನೆ ಒಳಗೊಂಡಿದೆ.
– ವಿಧಾನಗಳು ಮತ್ತು ಸಲಕರಣೆಗಳ ವಿವರಣೆ ಬಳಸಬೇಕಾದ

ಗುಣಮಟ್ಟ ಯೋಜನೆ ಹೊಂದಿರಬೇಕು:
– ಗುಣಮಟ್ಟ ಗುರಿಗಳನ್ನು
– ಸ್ವೀಕಾರಕ್ಕೆ ಮಾನದಂಡ
– ಯೋಜನೆ, ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಪರಿಶೀಲನೆ ಪತ್ತೆಹಚ್ಚುವಿಕೆ.
– ಗುಣಮಟ್ಟದ ಚಟುವಟಿಕೆಗಳಿಗೆ ಜವಾಬ್ದಾರಿಗಳನ್ನು.

ಒಂದು ಕಂಪನಿ ಐಎಸ್ಒ ಪ್ರಮಾಣೀಕರಣ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಯೋಜನೆಗಳಿಗೆ ಸಂಪೂರ್ಣ ಕಂಪನಿಗೆ ಅಲ್ಲ ರಿಂದ ಐಎಸ್ಒ ಅರ್ಹತಾ ಯೋಜನೆಗಳನ್ನು ಮಾಡಬೇಕು ಎಲ್ಲಾ ಯೋಜನೆಗಳು ನಡೆಯಲಿರುವ ಪಡೆಯಲು ಬಯಸಿದರೆ.

4.3 ಸಾಂಸ್ಥಿಕ ಮತ್ತು ತಾಂತ್ರಿಕ ಇಂಟರ್ಫೇಸ್ಗಳು

ಗುಂಪು ಕೆಲಸ ಇದ್ದರೆ, ಅವುಗಳ ನಡುವೆ ಸಂಪರ್ಕಸಾಧನಗಳನ್ನು, ಗುರುತಿಸಲ್ಪಡಬಹುದು ದಾಖಲಿಸಲಾಗಿದೆ ಮತ್ತು ಮಾಹಿತಿ ಬೇಕಾಗಿದ್ದ ಆ ರವಾನಿಸಲಾಗಿದೆ. ದಸ್ತಾವೇಜನ್ನು ನಿಯಮಿತವಾಗಿ ಪರಿಶೀಲಿಸಿದ ಹಾಗಿಲ್ಲ.

4.4 ವಿನ್ಯಾಸ ಇನ್ಪುಟ್

ಅವಶ್ಯಕತೆಗಳು ವಿಶೇಷಣಗಳು ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ ವಿನ್ಯಾಸ ಇನ್ಪುಟ್ ಹೊಂದಿರುತ್ತವೆ. ಈ ಖರೀದಿದಾರ ಮಾಡಲಾಗುತ್ತದೆ ಅಥವಾ ಕಾನೂನುಗಳು ಮತ್ತು ನಿಯಮಗಳು ಬಳಸಿಕೊಂಡು ಪೂರೈಕೆದಾರರಿಂದ ಸಜ್ಜುಗೊಳಿಸಬಹುದು. ಮತ್ತೊಂದು ವಿನ್ಯಾಸ ಇನ್ಪುಟ್ ಕೋಡಿಂಗ್ ಇನ್ಪುಟ್ ಬಳಸಲಾಗುತ್ತದೆ ವಿನ್ಯಾಸ ಕೋಡಿಂಗ್ ಒಳಗೊಂಡಿದೆ.

ಪ್ರಮಾಣಿತ ಪ್ರತಿ ಹಂತದ ಕೆಲಸದ ಉತ್ಪನ್ನವನ್ನು ಅಗತ್ಯಗಳಿಗೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಯಸಿದೆ.

ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ ಅಗತ್ಯ ಬದಲಾವಣೆಗಳನ್ನು ಆದ್ದರಿಂದ ಖರೀದಿದಾರ ಹೊಸ ಮತ್ತು ಬದಲಾದ ಅಗತ್ಯಗಳ ನಿರ್ವಹಣೆ ಒಂದು ವಿಧಾನ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ ಸಾಮಾನ್ಯ.

4.5 ವಿನ್ಯಾಸ ಔಟ್ಪುಟ್

ಡಿಸೈನ್ ಔಟ್ಪುಟ್: ವಿನ್ಯಾಸ ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಮೂಲ ಕೋಡ್. ಐಎಸ್ಒ ಕೋಡಿಂಗ್ ವಿನ್ಯಾಸ ದಸ್ತಾವೇಜುಗಳನ್ನು ಮತ್ತು ಮೊದಲು ಬಿಡುಗಡೆ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ ಅಗತ್ಯವಿದೆ.

ವಿನ್ಯಾಸ ಉತ್ಪಾದನೆ ಮತ್ತು ಸ್ವೀಕರಣೆಯ ಮಾನದಂಡಗಳನ್ನು ಸ್ವೀಕಾರ ಒಂದು ವಿಧಾನ ದಾಖಲಿಸಿದವರು ಮಾಡಬೇಕು.

4.6 ವಿನ್ಯಾಸ ರಿವ್ಯೂ

ಕೋಡಿಂಗ್ ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ಪ್ರಾಜೆಕ್ಟ್ ಕಾರ್ಯಗಳನ್ನು ವಿಮರ್ಶೆ ಪರಿಚಯಿಸುವ ಹಾಗಿಲ್ಲ. ವಿಮರ್ಶೆಗಳು ಖಾತರಿ ಸಾಮಾನ್ಯ ವಿಧಾನವಾಗಿತ್ತು ತಾಳೆಪಟ್ಟಿಗಳು ಇವೆ.

4.7 ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆ

ಈ ವಿಮರ್ಶೆಗಳು, ಘಟಕ ಪರೀಕ್ಷೆ ಮತ್ತು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಯ ಒಳಗೊಂಡಿದೆ.

4.8 ವಿನ್ಯಾಸ ಕ್ರಮಬದ್ಧಗೊಳಿಸುವಿಕೆ

ಬಳಕೆದಾರ ದಸ್ತಾವೇಜನ್ನು ಪರಾಮರ್ಶೆ ಒಟ್ಟಾಗಿ ಫೈನಲ್ ಪಧ್ಧತಿಯ ಪರೀಕ್ಷೆಯ ಸಂಪೂರ್ಣ ತಂತ್ರಾಂಶ ಉತ್ಪನ್ನದ. ಇಲ್ಲ ಯೋಜಿಸಿ ದಾಖಲಿಸಲಾಗಿದೆ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಯ ಮಾಡಬೇಕು. ಬೀಟಾ ಪರೀಕ್ಷೆ ಎಲ್ಲಿಯವರೆಗೆ ಬೀಟಾ ಪರೀಕ್ಷೆ ಪೂರೈಕೆದಾರ ಮತ್ತು ಬೀಟಾ ಪರೀಕ್ಷೆ ಗ್ರಾಹಕ ನಡುವೆ ಸ್ಪಷ್ಟ ಒಪ್ಪಂದ ಆವರಿಸಿಕೊಂಡಿದೆ ಐಎಸ್ಓ ಅನುಸರಣೆಗೆ ಆಗಿದೆ.

4.9 ವಿನ್ಯಾಸ ಬದಲಾವಣೆಗಳು

ಐಎಸ್ಒ 9001 ವಿನ್ಯಾಸ ದಸ್ತಾವೇಜನ್ನು ಅಥವಾ ಮೂಲ ಬಿಡುಗಡೆಯ ನಂತರ, ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಬದಲಾವಣೆಗಳು, ಅಲ್ಲಿ ದಾಖಲಿಸಲಾಗಿದೆ ಪರಿಶೀಲಿಸಿದ್ದೇವೆ ಮತ್ತು ಅನುಷ್ಠಾನ ಮೊದಲು ಅನುಮೋದಿಸಲಾಗಿದೆ ಔಪಚಾರಿಕ ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ಹೋಗಿ ಹಾಗಿಲ್ಲ ಅಗತ್ಯವಿದೆ.

ಸಂಕೀರ್ಣ ತಾಂತ್ರಿಕ ಡಾಕ್ಯುಮೆಂಟ್ಗಳು ಅಥವಾ ಕಾರ್ಯಕ್ರಮಗಳು ಅನಿಯಂತ್ರಿತ ಬದಲಾವಣೆಗಳನ್ನು ಅತ್ಯಂತ ಅಪಾಯಕಾರಿ ಮತ್ತು ಗುಣಮಟ್ಟದ ಇದು ಅನುಮತಿಸುವುದಿಲ್ಲ.
5. ಡಾಕ್ಯುಮೆಂಟ್ ಮತ್ತು ದತ್ತಾಂಶ ಕಂಟ್ರೋಲ್

ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ / ನಿರ್ವಹಣೆ ನಿಯಂತ್ರಿಸುವ ಮಾಹಿತಿ. ಪ್ರಮಾಣಿತ ಕೆಲವು ದಾಖಲಿಸುವ ಅಗತ್ಯವಿದೆ ಯಾರು / ದಶಮಾಂಶ ಅದು ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಅಗತ್ಯವಿದೆ. ದಾಖಲೆಗಳನ್ನು ಮತ್ತು ದತ್ತಾಂಶವನ್ನು ಬದಲಾವಣೆಗಳು ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ.

5.1 ಜನರಲ್

ಬಾಹ್ಯ ದಾಖಲೆಗಳನ್ನು ಮತ್ತು ದತ್ತಾಂಶದ ಹಾಗಿಲ್ಲ. ಇದು ಯಾವುದೇ ರೂಪ (ಹಾರ್ಡ್ ಕಾಪಿ, ವಿದ್ಯುನ್ಮಾನ ಮಾಧ್ಯಮ) ಶೇಖರಿಸಿಡಬಹುದು.

5.2 ಡಾಕ್ಯುಮೆಂಟ್ ಮತ್ತು ದತ್ತಾಂಶ ಅನುಮೋದನೆ ಮತ್ತು ಸಂಚಿಕೆ

ಸಮಸ್ಯೆಯನ್ನು ದಾಖಲೆಗಳನ್ನು ಮತ್ತು ದತ್ತಾಂಶವನ್ನು ಮೊದಲು ಪರಿಶೀಲಿಸಿದ ವಿಚಾರವೊಂದರ ಮೊದಲು ಅನುಮೋದನೆ ಹಾಗಿಲ್ಲ. ದಾಖಲೆ ಪಟ್ಟಿ ಇದರಲ್ಲಿ ಒಂದು ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ಹಾಗಿಲ್ಲ. ಅಮಾನ್ಯ ಅಥವಾ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ದಾಖಲೆಗಳ ತೆಗೆದು ಅಥವಾ ಸ್ಪಷ್ಟವಾಗಿ ಗುರುತಿಸಬೇಕಾಗಿದೆ.

5.3 ಡಾಕ್ಯುಮೆಂಟ್ ಮತ್ತು ದತ್ತಾಂಶ ಬದಲಾವಣೆಗಳು

ವಿಮರ್ಶೆ ಮತ್ತು ಅನುಮೋದನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉಸ್ತುವಾರಿ ವ್ಯಕ್ತಿ / ರು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಹಾಗಿಲ್ಲ.

6. ಖರೀದಿ

ಉಪಗುತ್ತಿಗೆದಾರನು ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಇನ್ನೂ ಹೊಣೆ. ಅಂದರೆ ನೀವು ಒಪ್ಪಂದದ ಅರ್ಜಿ ಮತ್ತು ಕೆಲಸ subcontract ವೇಳೆ, ISO ಮಾನದಂಡಗಳು ನಿಮ್ಮ ಜವಾಬ್ದಾರಿ ಹಂತದಲ್ಲಿದ್ದು ಮತ್ತು ISO ಅವಶ್ಯಕತೆಗಳನ್ನು ಉಪಗುತ್ತಿಗೆದಾರನು ಮೇಲೆ ಹೇರಿದ ಎಂದು ಹೊಂದಿಲ್ಲ.

6.1 ಸಾಮಾನ್ಯ

ಮಾನವಶಕ್ತಿಯನ್ನು ಖರೀದಿಸಿದ ವೇಳೆ, ಪ್ರಮಾಣಿತ ನೀವು ಬಲ ಜನರು ಪಡೆಯಲು ಒಂದು ವಿಧಾನವನ್ನು ಅನುಸರಿಸಿ ಅಗತ್ಯವಿದೆ. ಜನರು ಪೂರೈಕೆದಾರ ಮತ್ತು ಉಪಗುತ್ತಿಗೆದಾರನು ನಿಯಂತ್ರಿಸಬಹುದು ಕಾಣಿಸುತ್ತದೆ.
ಅಗತ್ಯಗಳಿಗನುಗುಣವಾಗಿದೆ ಎಂಬುದನ್ನು ಖರೀದಿಸಿದ ತಂತ್ರಾಂಶ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು:
– ಉಪಗುತ್ತಿಗೆದಾರರ ವಿಧಾನಗಳ ಬಗ್ಗೆ ಕಾಂಟ್ರಾಕ್ಟ್ ಅವಶ್ಯಕತೆಗಳನ್ನು
– ಉಪಗುತ್ತಿಗೆದಾರನು ಗುಣಮಟ್ಟ ವ್ಯವಸ್ಥೆಯ ಆಡಿಟ್
– ಉಪಗುತ್ತಿಗೆದಾರನು ಪ್ರದರ್ಶನ ಕಳೆದ ಪರಿಶೀಲಿಸಿ
– ಒಪ್ಪಂದ ಸಮಯದಲ್ಲಿ ಉಪಗುತ್ತಿಗೆದಾರನು ಸಮೀಕ್ಷೆ
– ವಿಟ್ನೆಸ್ ಪುನರ್ವಿಮರ್ಶೆ ಮತ್ತು ಪರೀಕ್ಷೆಯ
– ಟೆಸ್ಟ್ ಮತ್ತು ಉಪಗುತ್ತಿಗೆದಾರನು ವಿಮರ್ಶೆ ಉತ್ಪನ್ನ.

ಉಪಗುತ್ತಿಗೆದಾರರ 6.2 ಮೌಲ್ಯಮಾಪನ

ಅಗತ್ಯ ಅಧಿಕಾರ ಮತ್ತು ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ವ್ಯಕ್ತಿ ಪ್ರತಿ ಉಪಗುತ್ತಿಗೆದಾರನು ನಿರ್ಣಯ ಮತ್ತು ಬಳಸಲು ನಿರ್ಧರಿಸಿದರು ಹಾಗಿಲ್ಲ. ನಿರ್ಧಾರಗಳನ್ನು ದಾಖಲಿಸಲಾಗಿದೆ ಹಾಗಿಲ್ಲ.

ಪೂರೈಕೆದಾರ ಹೊಂದಿರುತ್ತದೆ ಉಪಗುತ್ತಿಗೆದಾರನು ಮೇಲೆ ಯಾವ ನಿಯಂತ್ರಣ ನಿರ್ಧರಿಸಲು ಹಾಗಿಲ್ಲ. ಪ್ರಮಾಣಿತ ನೀವು ಇರಬೇಕು ನಿಯಂತ್ರಿಸಲು ನೀಡಿಲ್ಲ. ಇದು ಕೇವಲ ಒಂದು ನಿರ್ಧಾರ ಸತ್ಯ ಬಳಸಿಕೊಂಡು ನೋಡಬೇಕು ಎಂದು ತಿಳಿಸುತ್ತದೆ.

ತಂತ್ರಾಂಶ ಚಿಲ್ಲರೆ ಮೂಲಕ ಖರೀದಿಸಿದ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದು ವಿಶೇಷ ಸಂದರ್ಭದಲ್ಲಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಉಪಗುತ್ತಿಗೆದಾರನು ಖರೀದಿ ನಡೆಸಲಾಗುತ್ತದೆ ಇದು ಸಂಸ್ಥೆಯ ತಂತ್ರಾಂಶ ಮೂಲ ಡೆವೆಲಪರ್.

ಖರೀದಿ ಚಿಲ್ಲರೆ ಐಎಸ್ಒ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ ವೇಳೆ 9001 ನೀವು ತನ್ನ ಪೂರೈಕೆದಾರ ನಿಯಂತ್ರಿಸಲು ಚಿಲ್ಲರೆ ಅಗತ್ಯಗಳನ್ನು ಹಾಕಲು ಯಾವ ಮಟ್ಟಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲು ಅಗತ್ಯವಿದೆ.

6.3 ಖರೀದಿ ಡೇಟಾ

ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಕೆಲಸ ಫಲಿತಾಂಶಗಳು ಮತ್ತು ಕಾರ್ಯವಿಧಾನಗಳು ಅನುಮೋದಿಸಲು ಪೂರೈಕೆದಾರ ಅಗತ್ಯಗಳ ಜೊತೆಗೆ ಒಪ್ಪಂದ ದಾಖಲಿಸಲಾಗಿದೆ ಹಾಗಿಲ್ಲ.

ಖರೀದಿಸಿದ ಉತ್ಪನ್ನದ 6.4 ಪರಿಶೀಲನೆ

ಪ್ರತಿ ಪರಿಶೀಲನೆ ಬಗ್ಗೆ ನಿರ್ಧಾರಗಳನ್ನು ದಾಖಲೆ ಅಭಿವೃದ್ಧಿ ತಂತ್ರಾಂಶ ಅಥವ ಉತ್ಪನ್ನ ಖರೀದಿಸಿ.
ಅಲ್ಲದ ಅನುಸರಣೆಗೆ

– ಅನುಮೋದಿತ ಪೂರೈಕೆದಾರರ ಪಟ್ಟಿಯು
– ಉಪಗುತ್ತಿಗೆದಾರನು ಸೂಕ್ತವಲ್ಲದ ನಿಯಂತ್ರಣ
– ಖರೀದಿಸಿದ ವಸ್ತುಗಳ ಡಾಕ್ಯುಮೆಂಟ್ ಪರಿಶೀಲನೆ
– ಉಪಗುತ್ತಿಗೆದಾರನು ಆಕ್ಷೇಪಾರ್ಹ ಒಪ್ಪಂದ.

ಗ್ರಾಹಕ ಸರಬರಾಜು ಉತ್ಪನ್ನ 7 ಕಂಟ್ರೋಲ್

ಪೂರೈಕೆದಾರ ಪರಿಶೀಲನೆ, ಸಂಗ್ರಹಣೆ ಮತ್ತು ಗ್ರಾಹಕ ಸರಬರಾಜು ಸಾಫ್ಟವೇರ್ ನಿರ್ವಹಣೆಗೆ ವಿಧಾನಗಳನ್ನು ಹಾಗಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಗುಣಮಟ್ಟದ ಸಾಫ್ಟ್ವೇರ್ ಜವಾಬ್ದಾರಿ.

ನಾನ್ ಅನುಸರಣೆಗೆ ಕಾರಣ ಗ್ರಾಹಕ ಹಾಗೂ ಸರಬರಾಜುದಾರ ಜವಾಬ್ದಾರಿ ಅಸ್ಪಷ್ಟವಾಗಿದೆ ಜವಾಬ್ದಾರಿ ಸಂಭವಿಸುತ್ತದೆ.

8 ಉತ್ಪನ್ನ ವಿವರಣೆ ಹಾಗೂ ಪತ್ತೆ ಹಚ್ಚುವಿಕೆ

ತಂತ್ರಾಂಶ ಸರಬರಾಜು ನಿಯಂತ್ರಣ ಇಟ್ಟುಕೊಳ್ಳುತ್ತಾರೆ:
– ಡಾಕ್ಯುಮೆಂಟ್ ಹಿಂದಿನ ಮತ್ತು ಬಿಡುಗಡೆಗೊಳಿಸಲು ಯಾವ ಆಧರಿಸಿದೆ
– ಇದು ವಿವರಣೆಯನ್ನು ಇದು ಆಧರಿಸಿದೆ
– ಏನು ತಿದ್ದುಪಡಿಗಳು ಮತ್ತು ತಿದ್ದುಪಡಿಗಳನ್ನು ಮೂಲ ಕಾರ್ಯಕ್ರಮಗಳು ಅಳವಡಿಸಿದ್ದಾರೆ
– ಏನು ಪ್ರತಿ ಸಮಸ್ಯೆಯು ವರದಿಯ ಸಂಭವಿಸಿದ
– ಒಂದು ನಿರ್ದಿಷ್ಟ ಭಾಗದಲ್ಲಿ ರಚಿಸಿದ್ದಾರೆ ಏನು ಮೂಲದಿಂದ.

9 ಪ್ರಾಸೆಸ್ ಕಂಟ್ರೋಲ್

ಮಾಸ್ಟರ್ Proma € ™ ರು / ಗ್ರಂಥಾಲಯಗಳು ನಿರ್ವಹಿಸುವುದು ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ಕಾರ್ಯವಿಧಾನದಲ್ಲಿ ಪ್ರತಿಕೃತಿ ಪ್ರಕ್ರಿಯೆಗೆ ದಾಖಲಿಸಲಾಗಿದೆ ವಿಧಾನ. ಸರಿಯಾದ ವರ್ಶನಿಂಗ್ ಬಳಸಲಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು.

ಅಲ್ಲದ ಅನುಸರಣೆಗೆ
– ಪ್ರತಿಕೃತಿ ಯಾವುದೇ ದಾಖಲಿತ ವಿಧಾನ
– ಮಾಸ್ಟರ್ Proma € ™ ರು ಅಥವಾ ಡಿಸ್ಕೆಟ್ಟುಗಳ ಅನುಚಿತ ನಿರ್ವಹಣೆ.

10 ಇನ್ಸ್ಪೆಕ್ಷನ್ ಮತ್ತು ಪರೀಕ್ಷೆ

ತಪಾಸಣೆ ಮತ್ತು ಪರೀಕ್ಷೆ ಬರೆದ ವಿಧಾನಗಳು ಪ್ರತಿಕೃತಿ ಸಂಬಂಧಿಸಿದಂತೆ ಮಾಡಬೇಕಾಗಿದೆ.

ಅಲ್ಲದ ಅನುಸರಣೆಗೆ
– ಸ್ವಯಂಚಾಲಿತವಾಗಿ Proma € ™ ರು ಪರಿಶೀಲಿಸುವ ಫಂಕ್ಷನ್ ಪರಿಶೀಲನೆ ಮಾಡಿಲ್ಲ
– ಯಾವುದೇ ಪರೀಕ್ಷೆ P