Kvalitetssystemstandarder Quality management and quality assurance Del 3: Riktlinjer för tillämpning av standards Part 3: Guidelines for the SS-ISO 9001 vid utveckling, leverans och application of ISO 9001 to the developunderhåll av programvara ment, supply and maintenance of software Innehåll Contents 0 Inledning 0 Introduction 1 Omfattning 1 Scope 2 Bindande referenser 2 Normative references 3 Definitioner 3 Definitions 4 Kvalitetssystem ramverk 4 Quality system Framework 4.1 Företagsledningens ansvar 4.1 Management responsibility 4.2 Kvalitetssystem 4.2 Quality system 4.3 Interna kvalitetssystemrevisioner 4.3 Internal quality system audits 4.4 Korrigerande åtgärder 4.4 Corrective action 5 Kvalitetssystem livscykelaktiviteter 5 Quality system Life-cycle activities 5.1 Allmänt 5.1 General 5.2 Kontraktsgenomgång 5.2 Contract review 5.3 Köparens kravspecifikation 5.3 Purchaser s requirements specification 5.4 Utvecklingsplanering 5.4 Development planning 5.5 Kvalitetsplanering 5.5 Quality planning 5.6 Konstruktion och genomförande 5.6 Design and implementation 5.7 Provning och validering 5.7 Testing and validation 5.8 Acceptans 5.8 Acceptance 5.9 Reproducering, leverans och installation 5.9 Replication, delivery and installation 5.10 Underhåll 5.10 Maintenance 6 Kvalitetssystem stödjande aktiviteter (inte fasberoend 6.1 Konfigurationsstyrning 6.2 Dokumentstyrning 6.3 Kvalitetsdokument 6.4 Mätning 6.5 Regler, rutiner och konventioner 6.6 Verktyg och teknik 6.7 Inköp 6.8 Inkluderad programvaruprodukt 6.9 Upplärning 6 6.1 6.2 6.3 6.4 6.5 6.6 6.8 6.9 Quality system Supporting activities (not phase dependent) Configuration management Document control Quality records Measurements Rules, practices and conventions Tools and techniques Purchasing Included software product Training Bilaga A Korsreferens mellan SS-ISO 9000-3 och Annex A Cross-reference between ISO 9000-3 and SS-ISO 9001 ISO 9001 Bilaga B Korsreferens mellan SS-ISO 9001 och Annex B Cross-reference between ISO 9001 and SS-ISO 9000-3 ISO 9000-3
0 Inledning Introduction Den svenska texten i denna standard är en översättning av ISO 9000:1991 Quality management and quality assurance standards Part 3, Guidelines for the application of ISO 9001 to the development, supply and maintenance of software, vars text också återges. De i ISO-standarden refererade internationella standarderna har i den svenska texten ersatts med svenska motsvarigheter. Genom informationsteknologins framsteg har mängden programvaruprodukter ökat och kvalitetsledningen av sådana är väsentlig. Ett av medlen för att upprätta ett kvalitetssystem är att ge vägledning för kvalitetssäkring av programvara. Kraven för ett allmänt kvalitetssystem vid avtalsförhållande mellan två parter har redan publicerats: SS-ISO 9001:1987, Kvalitetssystem Krav vid konstruktion, utveckling, produktion, installation och service. Processen för utveckling och underhåll av programvara skiljer sig emellertid från den som tillämpas för de flesta andra typer av industriprodukter. Inom ett teknikområde i så snabb utveckling är det därför nödvändigt att ge ytterligare riktlinjer för kvalitetssystem som berör programvaruprodukter och att därvid beakta den rådande tekniska nivån. Utvecklingen av programvara kännetecknas av att vissa aktiviteter relateras till specifika faser i utvecklingsprocessen, medan andra kan vara tillämpliga på hela processen. Dessa riktlinjer har därför strukturerats för att återspegla dessa skillnader. Denna standard har därför inte disponerats direkt enligt SS-ISO 9001, och register med korsreferenser (bilagorna A och B) ges som hjälp vid hänvisning till sistnämnda standard. Avtal mellan två parter avseende programvaruutveckling kan vara mycket olika utformade. I vissa tvåpartskontrakt är dessa riktlinjer kanske inte tillämpliga trots att de skräddarsytts. Det är därför viktigt att fastställa om det är lämpligt att tillämpa denna standard på ett kontrakt. Denna standard behandlar främst situationer där, såsom en del av ett kontrakt, specifik programvara utvecklas enligt köparens specifikationer. Den beskrivna grundsynen kan emellertid vara av lika stort värde i andra situationer. ANM 1 Bruk av maskulinum i denna standard utesluter inte femininum om tillämpbart på personer. Bruk av singularis utesluter inte tillämpning av pluralis (och vice vers om detta är meningsfullt. ANM 2 Genomgående gäller att denna standard återger relevanta delar av texten i SS-ISO 9000 med kursiv stil i de fall ytterligare vägledning inte ges. ANM 3 I denna standard återfinns ett antal uppräkningar, av vilka ingen förutsätts vara fullständig. De är avsedda som exempel. The Swedish text in this standard is a translation of ISO 9000:1991 Quality management and quality assurance standard Part 3, Guidelines for application of ISO 9001 to the development, supply and maintenance of software, the text of which is also given. The references in ISO 9000-3 to international standards have been replaced by references to corresponding Swedish standards. With the progress of information technology, the amount of software products has been increasing and the quality management of software products is essential. One of the means of establishing a quality management system is to provide guidance for software quality assurance. The requirements for a generic system for two-party contractual situations have already been published: ISO 9001:1987, Quality systems Model for quality assurance in design/development, production, installation and servicing. However, the process of development and maintenance of software is different from that of most types of industrial products. In such a rapidly evolving technology field it is therefore necessary to provide additional guidance for quality systems where software products are involved, taking into account the present status of this technology. The nature of software development is such that some activities are related to particular phases of the development process, while others may apply throughout the process. These guidelines have therefore been structured to reflect these differentes. This document thus does not correspond directly in format with ISO 9001 and cross-reference indexes (annex A and annex B) are provided to give assistance when referring to that standard. Contracts between two parties for software product development may occur in many variations. In certain cases of two-party contracts, these guidelines might not be applicable even if tailored. It is therefore important to determine the adequacy of the application of this part of ISO 9000 to the contract. This part of ISO 9000 deals primarily with situations where specific software is developed as part of a contract according to purchaser s specifications. However, the concepts described may be equally of value in other situations. NOTES 1 In English, use of the masculine gender in this part of ISO 9000 is not meant to exclude the feminine gender where applied to persons. Similarly, use of the singular does not exclude the plural (and vice vers when the sense allows. 2 Throughout this part of ISO 9000 where there is no further guidance, the text of the relevant ISO 9001 clause is given and printed in Italics. 3 In this part of ISO 9000 there are a number of lists; none of these is presumed to be exhaustive they are intended as examples.
1 Omfattning 1 Scope Denna standard ger riktlinjer för att underlätta tillämpning av SS-ISO 9001 inom organisationer som utvecklar, levererar och underhåller programvara. Den är avsedd att ge vägledning då ett avtal mellan två parter kräver att leverantörens förmåga att utveckla, leverera och underhålla programvaruprodukter skall visas. Riktlinjerna i denna standard syftar till att beskriva föreslagna styrmedel och metoder för att producera programvara som uppfyller köparens krav. Detta görs främst genom att avvikelser förebyggs under alla skeden från utveckling till underhåll. Riktlinjerna i denna standard kan tillämpas i avtalssituationer för programvara då avtalet uttryckligen kräver en utvecklingsinsats och produktkraven huvudsakligen uttrycks som krav på prestanda eller måste fastställas tilltro till produkten kan uppnås genom att leverantören på lämpligt sätt visar sin förmåga ifråga om utveckling, leverans och underhåll. This part of ISO 9000 sets out guidelines to facilitate the application of ISO 9001 to organizations developing, supplying and maintaining software. It is intended to provide guidance where a contract between two parties requires the demonstration of a supplier s capability to develop, supply and maintain software products. The guidelines in this part of ISO 9000 are intended to describe the suggested controls and methods for producing software which meet a purchaser s requirements. This is done primarily by preventing nonconformity at all stages from development through to maintenance. The guidelines in this part of ISO 9000 are applicable in contractual situations for software products when the contract specifically requires design effort and the product requirements are stated principally in performance terms, or they need to be established; confidence in the product can be attained by the adequate demonstration of a certain supplier s capabilities in development, supply and maintenance. 2 Bindande referenser Följande standarder innehåller krav som, genom hänvisning, även utgör krav i denna standard. Vid tiden för fastställelsen gällde den utgåva som anges. Alla standarder revideras fortlöpande, och parter som gör upp avtal baserade på denna standard uppmanas att undersöka möjligheterna att tillämpa den senaste utgåvan av nedan angivna standarder. IEC- och ISO-medlemmar tillhandahåller register över aktuella internationella standarder. I Sverige är SIS-Standardiseringskommissionen i Sverige, medlem i ISO och SEK, Svenska Elektriska Kommissionen, medlem i IEC. SS 01 16 01:1989, Informationsteknik Ordlista SS 02 01 04:1986, Kvalitet Terminologi SS-ISO 9001:1987, Kvalitetssystem Krav vid konstruktion, utveckling, produktion, installation och service SS-ISO 10 011:1992, Riktlinjer för revision av kvalitetssystem Del 1: Revision 2 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this part of ISO 9000. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this part of ISO 9000 are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid international Standards. ISO 2382-1:1984, Data processing Vocabulary Part 01: Fundamental terms. ISO 8402:1986, Quality Vocabulary. ISO 9001:1987, Quality systems Model for quality assurance in design/development, production, installation and servicing. ISO 10011-1:1990, Guidelines for auditing quality systems Part 1: Auditing. 3 Definitioner I denna standard gäller de definitioner som ges i SS 02 01 04 och SS 01 16 01 samt följande definitioner. 3 Definitions For the purposes of this part of ISO 9000, the definitions given in ISO 2382-1 and ISO 8402 apply, together with the following definitions.
3.1 programvara datorprogram, procedurer, regler och dokumentation avseende användningen av ett databehandlingssystem (SS 01 16 01:1989) ANM 4 Programvara är oberoende av det medium på vilket den är återgiven. 3.1 software: Intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a data processing system. [ISO 2382-1:1984, 01.04.04] NOTE 4 Software is independent of the medium on which it is recorded. 3.2 programvaruprodukt fullständig uppsättning av data- 3.2 software product: Complete set of computer program, rutiner och tillhörande dokumentation och data, programs, procedures and associated documenavsedd för leverans till en användare tation and data designated for delivery to a user. 3.3 programvaruenhet identifierbar del av en programvaruprodukt vid ett mellansteg eller vid slutsteget i utvecklingen 3.4 utveckling alla aktiviteter som utförs för att skapa en programvaruprodukt 3.5 fas definierad del av ett arbete ANM 5 En fas förutsätter inte användningen av någon specifik livscykelmodell, ej heller en viss tidsperiod i utvecklingen av programvaruprodukten. 3.6 verifiering (av programvar process för att utvärdera produkterna från en given fas för att säkerställa dessas riktighet och överensstämmelse med avseende på de produkter och standarder som givits som underlag till denna fas 3.7 validering (av programvar process att utvärdera programvara för att säkerställa överensstämmelse med specificerade krav 3.3 software item: Any identifiable part of a software product at an intermediate step or at the final step of development. 3.4 development: All activities to be carried out to create a software product. 3.5 phase: Defined segment of work. NOTE 5 A phase does not imply the use of any specific life-cycle model, nor does it imply a period of time in the development of a software product. 3.6 verification (for softwar: The process of evaluating the products of a given phase to ensure correctness and consistency with respect to the products and standards provided as input to that phase. 3.7 validation (for softwar: The process of evaluating software to ensure compliance with specified requirements. 4 Kvalitetssystem ramverk 4 Quality system Framework 4.1 Företagsledningens ansvar 4.1 Management responsibility 4.1.1 Leverantörens företagslednings ansvar 4.1.1.1 Kvalitetspolicy Leverantörens företagsledning skall definiera och dokumentera företagets policy och mål avseende kvalitet och ledningens förpliktelser i detta sammanhang. Leverantören skall säkerställa att denna policy är förstådd tillämpad och upprätthållen på alla nivåer i organisationen. [SS-ISO 9001:1987,4.1.1] 4.1.1 Supplier s management responsibility 4.1.1.1 Quality policy The supplier s management shall define and document its policy and objectives for, and commitment to, quality. The supplier shall ensure that this policy is understood, implemented and maintained at all levels in the organization. [ISO 9001:1987, 4.1.1] 4.1.1.2 Organisation 4.1.1.2 Organization 4.1.1.2.1 Ansvar och befogenheter 4.1.1.2.1 Responsibility and authority För all personal som leder, utför och verifierar arbete som påverkar kvaliteten skall ansvar, befogenheter och samarbetsförhållanden definieras. Speciellt gäller detta personal som måste ha organisatorisk frihet och befogenhet att initiera åtgärder för att förhindra uppkomst av avvikelser från produktkrav The responsibility, authority and the interrelation of all personnel who manage, perform and verify work affecting quality shall be defined; particularly for personnel who need the organizational freedom and authority to initiate action to prevent fhe occurrence of product nonconformity;
identifiera och registrera kvalitetsproblem av olika slag initiera, rekommendera eller sörja för lösningar på problem genom fastställda kanaler verifiera genomförandet av lösningar hålla vidare behandling, leverans eller installation av avvikande produkter under kontroll till dess att brister eller otillfredsställande förhållanden har korrigerats. [SS-ISO 9001:1987 4.1.2.1] 4.1.1.2.2 Resurser och personal för verifiering Leverantören skall identifiera krav på verifiering inom sin organisation, ställa erforderliga resurser till förfogande och tillsätta utbildad personal för att utföra verifiering. Verifiering skall innefatta kontroll, provning och övervakning såväl av konstruktions-, produktions-, installations- och serviceverksamhet som av produkter. Konstruktionsgenomgångar och revisioner av kvalitetssystem, processer och produkter skall göras av personal som är oberoende av dem som har direkt ansvarför det arbete som utförs. [SS-ISO 9001:1987, 4.1.2.2] 4.1.1.2.3 Företagsledningens representant Leverantören skall utse en representant för företagsledningen. Oavsett annat ansvar, skall representanten ha definierad befogenhet och ansvar för att säkerställa att kraven i [SS- ISO 9001] uppfylls och vidmakthålls. [SS-ISO 9001:1987,4.1.2.3] 4.1.1.3 Företagsledningens genomgång Det kvalitetssystem, som införts för att uppfylla kraven i [SS-ISO 900l], skall med lämpliga mellanrum gås igenom av leverantörens företagsledning för att säkerställa systemets fortsatta lämplighet och effektivitet. Dokumentation av sådana granskningar skall bevaras. ANM Genomgången omfattar normalt en värdering av resultaten från interna kvalitetsrevisioner. Den utförs av, eller på uppdrag av, leverantörens företagsledning (dvs den inom ledningen som har direkt ansvar för systemet). [SS-ISO 9001:1987,4.1.3] identify and record any product quality problems; initiate, recommend or provide solutions through designated channels; verify the implementation of solutions; control further processing, delivery or installation of nonconforming product until the deficiency or unsatisfactory condition has been corrected. [ISO 9001:1987, 4.1.2.1] 4.1.1.2.2 Verification resources and personnel The supplier shall identify in-house verification requirements, provide adequate resources and assign trained personnel for verification activities. Verification activities shall include inspection, test and monitoring of the design, production, installation and servicing processes and/or product; design reviews and audits of fhe quality system, processes and/or product shall be carried out by personnel independent of those having direct responsibility for the work being performed. [ISO 9001:1987, 4.1.2.2] 4.1.1.2.3 Management representative The supplier shall appoint a management representative who, irrespective of other responsibilities, shall have defined authority and responsibility for ensuring that the requiremenfs of [ISO 9001] are implemented and maintained. [ISO 9001:1987, 4.1.2.3] 4.1.1.3 Management review The quality system adopted to satisfy the requirements of [ISO 9001] shall be reviewed af appropriate intervals by the supplier s management to ensure its continuing suitability and effectiveness. Records of such reviews shall be maintained. NOTE Management reviews normally include assessment of the results of internal quality system audits, but are carried out by, or on behalf of, the supplier s management viz management personnel having direct responsibility for the system. [ISO 9001:1987, 4.1.3] 4.1.2 Köparens företagslednings ansvar 4.1.2 Purchaser s management responsibility Köparen bör samarbeta med leverantören för att få fram all nödvändig information i tid och lösa ouppklarade problem. The purchaser should cooperate with the supplier to provide all necessary information in a timely manner and resolve pending items.
Köparen bör utse en representant med ansvar för behandlingen av kontraktsfrågor med leverantören. Denna representant bör ha erforderlig befogenhet att handlägga kontraktsfrågor, som innefattar, men ej är begränsade till att definiera köparens krav för leverantören besvara frågor från leverantören godkänna leverantörens förslag träffa överenskommelser med leverantören säkerställa att köparens organisation uppmärksammar de överenskommelser som har gjorts med leverantören f) definiera acceptanskriterier och rutiner g) ta hand om programvaruenheter som tillhandahållits av köparen men som befunnits vara olämpliga för användning. 4.1.3 Gemensamma genomgångar Regelbundna gemensamma genomgångar med leverantör och köpare bör planeras för att i tillämplig utsträckning behandla följande punkter: programvarans överensstämmelse med den kravspecifikation som överenskommits med köparen resultat från verifieringar resultat från acceptanskontroll. Enighet bör nås om resultaten av dessa genomgångar och resultaten bör dokumenteras. The purchaser should assign a representative with the responsibility for dealing with the supplier on contractual matters. This representative should have the authority commensurate with the need to deal with contractual matters which include, but are not limited to, the following: defining the purchaser s requirements to the supplier; answering questions from the supplier; approving the supplier s proposals; concluding agreements with the supplier; ensuring the purchaser s organization observes the agreements made with the supplier; f) defining acceptance criteria and procedures; g) dealing with the purchaser-supplied software items that are found unsuitable for use. 4.1.3 Joint reviews Regular joint reviews involving the supplier and purchaser should be scheduled to cover the following aspects, as appropriate: conformance of the software to the purchaser s agreed requirements specification; verification results; acceptance test results; The results of such reviews should be agreed and documented. 4.2 Kvalitetssystem 4.2 Quality system 4.2.1 Allmänt 4.2.1 General Leverantören bör upprätta och vidmakthålla ett dokumenterat kvalitetssystem. Kvalitetssystemet bör vara en integrerad del genom hela livscykeln och på så sätt säkerställa att kvalitet byggs in under utvecklingens fortskridande i stället för att kontrolleras enbart vid processens slut. Förebyggande av problem bör betonas snarare än korrigering av fel i efterhand. Leverantören bör säkerställa effektiv tillämpning av det dokumenterade kvalitetssystemet. The supplier should establish and maintain a documented quality system. The quality system should be an integrated process throughout the entire Iife cycle, thus ensuring that quality is being built in as development progresses, rather than being discovered at the end of the process. Problem prevention should be emphasized rather than depending on correction after occurrence. The supplier should ensure the effective implementation of the documented quality system. 4.2.2 Kvalitetssystemdokumentation 4.2.2 Quality system documentation Alla kvalitetssystemelement, t ex krav och villkor, bör vara klart dokumenterade på ett systematiskt och metodiskt sätt. All the quality system elements, requirements and provisions should be clearly documented in a systematic and orderly manner.
4.2.3 Kvalitetsplan 4.2.3 Quality plan Leverantören bör utarbeta och dokumentera en kvalitetsplan för kvalitetsaktiviteternas genomförande vid varje programvaruutveckling på basis av kvalitetssystemet samt säkerställa att berörda organisationer förstår och iakttar denna plan. 4.3 Interna kvalitetssystemrevisioner Interna kvalitetsrevisioner Leverantören skall genomföra allsidiga, planerade och dokumenterade interna kvalitets[system]revisioner för att verifiera om kvalitetsaktiviteterna överensstämmer med vad som planerats och för att fastställa kvalitetssystemets effektivitet. Revisioner skall planeras utgående från berörda aktiviteters aktuella tillstånd och betydelse. Revisionerna och tillhörande uppföljningar skall utföras enligt dokumenterade rutiner. Resultaten av revisionerna skall dokumenteras och göras kända för de ansvariga inom det reviderade området. Den ansvariga ledningen för det reviderade området skall vidta lämpliga ågärder för att korrigera de brister som påträffats vid revisionen. [SS-ISO 9001:1987, 4.17] Se SS-ISO 10 011-1. The supplier should prepare and document a quality plan to implement quality activities for each software development on the basis of the quality system, and ensure that it is understood and observed by the organizations concerned. 4.3 Internal quality system audits Internal quality audits The supplier shall carry out a comprehensive system of planned and documented internal quality [system] audits to verify whether quality activities comply with planned arrangements and to determine the effectiveness of the quality system. Audits shall be scheduled on the basis of the status and importance of fhe activity. The audits and follow-up actions shall be carried out in accordance with documented procedures. The results of the audits shall be documented and brought to the attention of the personnel having responsibility in the area audited. The management personnel responsible for fhe area shall take timely corrective action on the deficiencies found by the audit. [ISO 9001:1987, 4.17] See ISO 10011-1. 4.4 Korrigerande åtgärder Leverantören skall upprätta, dokumentera och vidmakthålla rutiner för att undersöka orsaken till avvikande produkter och genomföra erforderliga korrigerande åtgärder för att förhindra upprepning analysera alla processer, arbetsoperationer, dispenser, kvalitetsdokument, servicerapporter och reklamationer för att upptäcka och eliminera potentiella orsaker till avvikande produkter initiera förebyggande åtgärder i den omfattning som motiveras av de konstaterade riskerna säkerställa att korrigerande åtgärder vidtas och att de är effektiva genomföra och dokumentera ändringar i rutinerna till följd av korrigerande åtgärder. [SS-ISO 9001:1987, 4.14] 4.4 Corrective action The supplier shall establish, document and maintain procedures for investigating the cause of nonconforming product and the corrective action needed to prevent recurrence; analysing all processes, work operations, concessions, quality records, service reports and customer complaints to detect and eliminate potential causes of nonconforming product; initiating preventive actions to lems fo a level corresponding countered: deal with probto the risks enapplying controls to ensure that corrective actions are taken and that they are effective; implementing and recording changes in procedures resulting from corrective action. [ISO 9001:1987, 4.14]
5 Kvalitetssystem livscykelaktiviteter 5.1 Allmänt Ett projekt för utveckling av programvara bör organiseras enligt en livscykelmodell. Kvalitetsrelaterade aktiviteter bör planeras och genomföras med hänsyn till karaktären hos den livscykelmodell som används. Denna standard är avsedd för tillämpning oberoende av vilken livscykelmodell som används. Skulle någon beskrivning, vägledning, krav eller struktur tolkas på annat sätt, är detta inte avsikten och bör inte tolkas som att kravet eller vägledningen är begränsad till endast en speciell livscykelmodell. 5.2 Kontraktsgenomgång 5.2.1 Allmänt Leverantören bör upprätta och vidmakthålla rutiner för kontraktsgenomgång och för samordning av tillhörande aktiviteter. Leverantören bör gå igenom varje kontrakt för att säkerställa att kontraktsomfattningen och kraven är definierade och dokumenterade möjliga oklarheter och risker är identifierade f) information som utgör enskild egendom är tillräckligt skyddad varje krav som avviker från uppgifter i anbudet klarläggs och behandlas leverantören har förmåga att uppfylla kontraktskraven leverantörens ansvar beträffande det arbete som läggs ut på underleverantörer är definierat g) parterna är ense om terminologin h) köparen kan uppfylla sina kontraktsåtaganden. Dokumentation från sådana kontraktsgenomgångar bör bevaras. 5 Quality system Life-cycle activities 5.1 General A software development project should be organized according to a Iife-cycle model. Quality-related activities should be planned and implemented with respect to the nature of the life-cycle model used. This part of ISO 9000 is intended for application irrespective of the life-cycle model used. Should any description, guidance, requirement or structure be read differently, this is unintended and should not be read as indicating that the requirement or guidance is restricted to a specific life-cycle model only. 5.2 Contract review 5.2.1 General The supplier should establish and maintain procedures for contract review and for the coordination of these activities. Each contract should be reviewed by the supplier to ensure that f) g) h) the scope of the contract defined and documented; and requirements are possible contingencies or risks are identified; proprietary information is adequately protected; any requirements differing from those in the tender are resolved; the supplier has the capability to meet contractual requirements; the supplier s responsibility with regard to subcontracted work is defined; the terminology is agreed by both parties; the purchaser has the capability to meet contractual obligations. Records of such contract reviews should be maintained. 5.2.2 Kontraktspunkter rörande kvalitet Bland annat följande punkter i kontraktet är ofta relevanta: acceptanskriterier hantering av ändringar i köparens krav under utvecklingen behandling av problem upptäckta efter acceptans innefattande både kvalitetsrelaterade krav och köparens klagomål 5.2.2 Contract items on quality Among others, the following items are frequently found to be relevant in the contract: acceptance criteria; handling of the changes in purchaser s requirements during the development; handling of problems detected after acceptance, including quality-related claims and purchaser complaints;
köparens aktiviteter, speciellt köparens roll vid specificering av krav, installation och acceptans lokaler och utrustning, verktyg och programvaruenheter som skall tillhandahållas av köparen f) standarder och rutiner som skall användas g) krav rörande reproducering (se 5.9). activities carried out by the purchaser, especially the purchaser s role in requirements specification, installation and acceptance; facilities, tools and software items to be provided by the purchaser; f) standards and procedures to be used; g) replication requirements (see 5.9). 5.3 Köparens kravspecifikation 5.3 Purchaser s requirements specification 5.3.1 Allmänt 5.3.1 General För att kunna påbörja utveckling av programvara, bör leverantören ha en fullständig och otvetydig sammanställning av funktionskraven. Dessutom bör dessa krav innehålla alla aspekter, som är nödvändiga för att tillfredsställa köparens behov. Dessa kan omfatta, men är inte begränsade till, följande: prestanda, säkerhet, tillförlitlighet, behörighetsfrågor och sekretess. Dessa krav bör vara tillräckligt definierade för att möjliggöra validering vid produktacceptans. Köparens kravspecifikation dokumenterar dessa krav. I vissa fall tillhandahålls detta dokument av köparen. Om så inte är fallet bör leverantören ta fram kraven i nära samarbete med köparen, och leverantören bör inhämta köparens godkännande innan utvecklingsarbetet påbörjas. Köparens kravspecifikation bör vara föremål för dokument- och konfigurationsstyrning i och med att den utgör en del av utvecklingsdokumentationen. Alla gränssnitt mellan programvaruprodukten och andra program- eller maskinvaror bör vara fullständigt definierade i köparens kravspecifikation, antingen direkt eller genom hänvisning. In order to proceed with software development, the supplier should have a complete, unambiguous set of functional requirements. In addition, these requirements should include all aspects necessary to satisfy the purchaser s need. These may include, but are not limited to, the following: performance, safety, reliability, security and privacy. These requirements should be stated precisely enough so as to allow validation during product acceptance. The purchaser s requirements specification records these requirements. In some cases, this document is provided by the purchaser. If not, the supplier should develop these requirements in close cooperation with the purchaser, and the supplier should obtain the purchaser s approval before entering the development stage. The purchaser s requirements specification should be subject to documentation control and configuration management as part of the development documentation. All interfaces between the software product and other software or hardware products should be fully specified, either directly or by reference, in the purchaser s requirements specification. 5.3.2 Samarbete Under framtagningen av köparens kravspecifikation bör följande punkter beaktas: nominering av personer (från båda parter) som ansvarar för upprättandet av köparens kravspecifkation metoder för fastställande av krav och godkännande av ändringar åtgärder för att förebygga missuppfattningar t ex genom att definiera termer och ge bakgrundsförklaringar till kraven dokumentering och genomgång av diskussionsresultat hos båda parter. 5.3.2 Mutual cooperation During the development of the purchaser s requirements specification, attention to the following issues is recommended: assignment of persons (on both sides) responsible for establishing the purchaser s requirements specification; methods for agreeing on requirements and approving changes; efforts to prevent misunderstandings such as definition of terms, explanations of background of requirements; recording and reviewing discussion results on both sides.
5.4 Utvecklingsplanering 5.4.1 Allmänt Utvecklingsplanen bör täcka följande: projektdefinition innefattande målformulering med referens till berörda projekt hos köparen eller leverantören organisation av projektets resurser inklusive projektgruppens struktur, ansvar, anlitande av underleverantörer och användning av materiella resurser utvecklingsfaser (definierade i 5.4.2.1) tidsplan för projektet med identifiering av uppgifter som bör utföras, resurser och tid som krävs för varje uppgift och eventuella samband mellan dessa identifiering av andra berörda planer t ex kvalitetsplan konfigurationsstyrningsplan integrationsplan provningsplan. Utvecklingsplanen bör uppdateras allt eftersom arbetet fortskrider, och varje fas bör defineras i enlighet med avsnitt 5.4.2.1 innan aktiviteter i denna fas påbörjas. Planen bör granskas och godkännas före verkställandet. 5.4 Development planning 5.4.1 General The development plan should cover the following: the definition of the project, including a statement of its objectives and with reference to related purchaser or supplier projects; the organization of the project resources, including the team structure, responsibilities, use of sub-contractors and material resources to be used; development phases (as defined in 5.4.2.1); the project schedule identifying the tasks to be performed, the resources and time required for each and any interrelationships between tasks; identification of related plans, such as quality plan, configuration management plan, integration plan, test plan. The development plan should be updated as development progresses and each phase should be defined as in 5.4.2.1 before activities in that phase are started. It should be reviewed and approved before execution. 5.4.2 Utvecklingsplan 5.4.2 Development plan 5.4.2.1 Faser 5.4.2.1 Phases Utvecklingsplanen bör definiera en styrd process eller en metodik för att överföra köparens kravspecifikation till en programvaruprodukt. Detta kan innebära uppdelning av arbetet i faser samt identifiering av utvecklingsfaser som skall genomföras erforderliga underlag för varje fas erforderliga resultat från varje fas verifieringsrutiner som skall genomföras i varje fas analys av potentiella problem som hör ihop med utvecklingsfaserna och med uppfyllandet av de specificerade kraven. The development plan should define a disciplined process or methodology for transforming the purchaser s requirements specification into a software product. This may involve dividing the work into phases, and the identification of development phases to be carried out; required inputs for each phase; required outputs from each phase; verification procedures to be carried out at each phase; analysis of the potential problems associated with the development phases and with the achievment of the specified requirements.
5.4.2.2 Ledning Utvecklingsplanen bör definiera hur projekt skall ledas samt innefatta identifiering av tidsplan för utveckling, genomförande och tillhörande leveranser projektuppföljning organisatoriskt ansvar, resurser och arbetsfördelning organisatoriska och tekniska gränssnitt mellan olika grupper. 5.1.2.2 Management The development plan should define how the project is to be managed, including the identification of schedule of development, implementation and associated deliveries; progress control; organizational responsibilities, resources and work assignment; organizational and technical interfaces between different groups. 5.4.2.3 Utvecklingsmetoder och verktyg Utvecklingsplanen bör identifiera metoder för att säkerställa att alla aktiviteter utförs korrekt. Detta kan innefatta regler, praxis och konventioner för utveckling verktyg och teknik för utveckling konfigurationsstyrning. 5.4.2.3 Development methods and tools The development plan should identify methods for ensuring that all activities are carried out correctly. This may include rules, practices and conventions for development; tools and techniques for development; configuration management 5.4.3 Projektuppföljning Projektuppföljningar bör planeras, genomföras och dokumenteras för att säkerställa att olösta resursfrågor blir lösta och säkerställa effektivt verkställande av utvecklingsplaner. 5.4.3 Progress control Progress reviews should be planned, held and documented to ensure that outstanding resource issues are resolved and to ensure effective execution of development plans. 5.4.4 Underlag till utvecklingsfaser 5.4.4 Input to development phases Underlag som krävs för varje utvecklingsfas bör vara definierade och dokumenterade. Varje krav bör vara definierat så att dess uppfyllelse kan verifieras. Ofullständiga, oklara eller motstridiga krav bör klargöras tillsammans med dem som ansvarar för kravformuleringen. 5.4.5 Resultat från utvecklingsfaser Resultat som krävs från varje utvecklingsfas bör vara definierade och dokumenterade. Resultat från varje utvecklingsfas bör verifieras och bör uppfylla specificerade krav innehålla eller hänvisa till acceptanskriterier för överföring till nästa fas överensstämma med gällande utvecklingspraxis och -konventioner oavsett om dessa har angivits i underlaget eller ej identifiera de egenskaper hos produkten som är avgörande för dennas säkra och riktiga funktion stå i överenstämmelse med tillämpliga myndighetskrav. The required input to each development phase should be defined and documented. Each requirement should be defined so that its achievement can be verified. Incomplete, ambiguous or conflicting requirements should be resolved with those responsible for drawing up the requirements. 5.4.5 Output from development phases The required output from each development phase should be defined and documented. The output from each development phase should be verified and should C) meet the relevant requirements; contain or reference acceptance criteria for forwarding to subsequent phases; conform to appropriate development practices and conventions, whether or not these have been stated in the input information; identify those characteristics of the product that are crucial to its safe and proper functioning; conform to applicable regulatory requirements.