Способи забезпечення якості програмних продуктів.

Введення.

Всім, хто коли-небудь працював з програмним забезпеченням виробництва Microsoft, IBM, Novell або інший компанії, доводилося вирішувати проблеми різного ступеня складності, викликані збоями в роботі ПЗ. Виробництво сучасного ПО відбувається на тлі високих вимог, що пред'являються до якості створюваних програм і значною складності виконуваних ними функцій. Для забезпечення надійності програмних продуктів припадає виявляти помилки на всіх етапах проектування, починаючи з етапу аналізу вимог і закінчуючи усуненням помилок на стадії супроводу. І якщо на етапі аналізу вимог прагнуть виключити логічні помилки тієї діяльності, під яку пишеться ПЗ, то на інших етапах від цілого ряду помилок прагнуть позбутися комплексом заходів, починаючи від декомпозицій і закінчуючи "Ідеальною" технологією програмування -- технологія, яка по деякому досить неформального опису об'єкта програмування автоматично генерує текст синтаксично і семантично коректної програми.

Компанії-виробники намагаються підвищити якість програмних продуктів за допомогою тестування. Існують тестові методики, що використовують спеціальні драйвери, автоматично перевіряють проміжні версії розробляється продукту на різному апаратній забезпеченні. Інший спосіб перевірки - бета-тестування. У цьому випадку розробники програмного забезпечення дозволяють користувачам спробувати попередні версії продуктів.

Способи забезпечення якості програмних продуктів.

Стандартизація.

Безперервне зростання вимог до якості ПС стимулює створення і активне застосування міжнародних стандартів та регламентованих технологій, що автоматизують основні процеси їх життєвого циклу, починаючи з ініціювання проекту. Це призвело до істотного зміни в останні роки об'єктів, методології і культури в області створення та розвитку ПС і БД.

МС ІСО серії 9000 визначають і регламентують створення, розвиток, застосування і сертифікацію систем якості будь-яких підприємств, незалежно від їх призначення. Вони містять і розвивають основне положення, що "постачальник повинен розробити і підтримувати в робочому стані документально оформлену систему якості як засіб, забезпечує відповідність продукції встановленим вимогам замовника ". У них зафіксовано право замовника на інспекцію системи якості підприємства постачальника до укладання контракту на поставку продукції.

В останні роки сформувалася комплексна система управління якістю продукції TQM (Totaly Quality Management), яка концептуально близька до попередньої більш загальній системі на основі стандартів ІСО серії 9000. Система орієнтована на задоволення вимог споживача, на постійне поліпшення процесів виробництва або проектування, на управління процесами з боку керівництва підприємства на основі фактичного стану проекту. Основні досягнення TQM полягають у поглиблення і диференціації вимог споживачів по реалізації процесів, їх взаємодії та забезпечення якості продукції. Системний підхід підтриманий поруч спеціалізованих інструментальних засобів, орієнтованих на управління виробництвом продукції. Тому ця система поки не знаходить застосування в галузі забезпечення якості життєвого циклу програмних засобів.

Застосування цього комплексу може служити основою для систем забезпечення якості програмних засобів, однак потрібне коригування, адаптація або виключення деяких положень стандартів стосовно до принципових особливостей технологій та характеристик цього виду продукції. Крім того, при реалізації систем якості ПС необхідне залучення ряду стандартів, що формально не належать до цієї серії і регламентують показники якості, життєвий цикл, верифікацію та тестування, випробування, документування та інші особливості ЖЦ комплексів програм.

У Росії в галузі забезпечення життєвого циклу і якості складних комплексів програм існує і застосовується дуже невелика група застарілих стандартів серій ГОСТ 19.ХХХ і ГОСТ 34.ХХХ. Підприємства, що виконують державні замовлення при створенні ПС для внутрішнього застосування, змушені використовувати ці стандарти. Однак у експортних замовленнях зарубіжні клієнти вимагають відповідності технології проектування, виробництва та якості продукції сучасним міжнародним стандартам. Це протиріччя особливо загострилося у державні замовлення Міноборони Росії, результати яких одночасно використовуються і всередині, і поза країни.

За вимогами Міноборони Росії для застосування міжнародних стандартів у таких замовленнях їх необхідно перевести на російську мову, адаптувати, юридично затвердити і видати як ГОСТ Р, на що треба кілька років. Однак при поставках за кордон багато стандартів допускається практично застосовувати на мові оригіналу або у вигляді переказу до затвердження Держстандартом Росії, що цілком задовольняє зарубіжних замовників, але не допускається вітчизняними органами сертифікації для продукції всередині країни.

На цей момент ряд вітчизняних керівників переконався, що для забезпечення високої якості, надійності функціонування та безпеки застосування складних комплексів програм доцільно виділяти фахівців, відповідальних за дотримання технології створення і розвитку програм, за забезпечення та контроль якості, а також за надійність і безпека проекту ПС в цілому і його компонентів. Забезпечення якості повинно реалізовуватися фахівцями в ЖЦ програмних засобів на основі використання сучасної методології, технологічного інструментарію, стандартів і нормативних документів. Для систематичної координованої боротьби з погрозами якості необхідно проводити дослідження конкретних факторів, що впливають на якість функціонування та безпека застосування програм зі сторони, реально існуючих і потенційно можливих дефектів у створюваних комплексах програм.

Розробка та супровід складних ПС на базі сучасних технологій дозволяє попереджати й усувати найбільш небезпечні системні та алгоритмічні помилки на ранніх стадіях проектування, а також використовувати неодноразово перевірені в інших проектах програмні та інформаційні компоненти високої якості. Для виявлення і усунення помилок проектування всі етапи розробки та супроводження ПС повинні бути підтримані методами і засобами систематичних, автоматизованих верифікації, тестування і випробувань. При розробці ПС доцільно застосовувати різні методи, еталони і види тестування, кожен з яких орієнтований на виявлення, локалізацію або діагностику певних типів дефектів.

Посвідчення досягнутого якості функціонування складних критичних ПС і процесів їхнього життєвого циклу має базуватися на сертифікатах, виданих атестованими проблемно-орієнтованими випробувальними лабораторіями. Сертифікація систем якості підприємств - розробників ПС по МС ІСО серії 9000 - дозволяє замовникам і покупцям вибирати з них найбільш надійних партнерів для реалізації інформаційних систем, здатних гарантувати високу якість поставляються і використовуваних комплексів програм. Застосування сертифікованих систем якості підприємств не тільки гарантує високу, стійке якість проектування та забезпечення життєвого циклу ПС, але дозволяє в багатьох випадках не проводити чи скорочувати сертифікацію кінцевого продукту. Базою такої сертифікації підприємств, які розробляють програмні засоби, може служити комплекс стандартів, нормативних та інструктивних документів, представлених на схемою. Короткий зміст стандартів ІСО викладено в, а повні тексти в.

Необхідність аналізу та розвитку сертифікації програм як самостійної проблеми зумовлена специфічними стандартами і особливостями їх життєвого циклу. До них належать, з одного боку, об'єктивна необхідність посвідчення якості та споживчих властивостей продукції, активізація діяльності в цьому напрямі на міжнародному рівні. З іншого, відсутність у державних і міжнародних стандартах кількісних вимог до інформаційних систем, широке різноманіття класів і видів програм і баз даних, зумовлене різними функціями ІС, зумовлює формальні труднощі, пов'язані з процедурами докази відповідності ПС та БД умов контрактів і вимогам споживачів. Тому основою сертифікації повинні бути детальні та ефективні методики випробувань систем якості та конкретних ПС, спеціально розроблені тестові завдання та генератори для їх формування, а також кваліфікація і авторитет випробувачів. Для цього замовники повинні вибирати підрядників - виконавців своїх проектів, мають системи забезпечення якості програмних засобів для ІС та сертифікати, засвідчують реалізацію і застосування системи якості підприємством-розробником.

У вітчизняних ІС все більше застосовуються програмні компоненти зарубіжних фірм, які також не можуть бути абсолютно гарантовані від прояву дефектів проектування, програмування і документації. Для забезпечення необхідної якості функціонування комплексів програм з використанням імпортних компонентів слід закуповувати тільки ліцензійно-чисті продукти, які підтримуються гарантованим супроводом конкретних постачальників. Ці компоненти повинні супроводжуватися повної експлуатаційної і технологічною документацією, сертифікатом відповідності та комплектами тестів. У контрактах на закупівлю повинні спеціально фіксуватися зобов'язання постачальників з супроводу і заміні версій ПС при виявленні дефектів або вдосконалення функцій. Всі версії зарубіжних ПС слід перевіряти на якість функціонування в конкретному оточенні ІС шляхом повторних випробувань або окремими перевірками, що підтверджують закордонні сертифікат та експлуатаційну документацію.

Забезпечення надійності на етапі кодування та компіляції програмного забезпечення.

Розробка будь-якого програмного засобу може бути представлена як процес, що складається з ряду послідовних перетворень одного опису розв'язуваної задачі в інше, починаючи від постановки завдання і закінчуючи програмою, реалізованої в кодах конкретної ЕОМ.

Весь час існування програмного засобу від зародження ідеї по його створенню, до завершення його експлуатації, зазвичай визначають як життєвий цикл. Укрупнено можна виділити п'ять найбільш важливих етапів життєвого циклу програмного засобу (ЖЦ ПС): специфікацію (10%), проектування (10%), кодування (10%), налагодження (20%) та супровід (50%). У дужках записані відносні витрати ресурсів на створення ПС.

За витратами часу, людських і машинних ресурсів все це так само не однакові. Найбільш "Дорогими", в цьому сенсі, є етапи, пов'язані з пошуком помилок в програмах. Витрати ресурсів на них можуть бути рівними, або навіть перевершувати сукупні витрати ресурсів на інших етапах. У стандарті DOD-STD-2167-A близько 30% вимог, документів і відповідних їм процесів безпосередньо пов'язані з налагодженням, тестуванням і випробуваннями програм. Даний стандарт є обов'язковим при виконанні замовлень Міністерства оборони США.

Ці витрати швидко збільшуються при зростанні вимог до якості ПС. За оцінками, наведеними в роботі, на частку усунення помилок і супровід ПС припадає майже 75% всіх витрат. Слід враховувати, що значна частина робіт, що виконуються на етапі супроводу, пов'язана з пошуком і усуненням що залишилися в програмі помилок.

Ретроспектива розвитку методів і засобів автоматизації програмування в цьому відношенні говорить сама за себе. У модульному програмуванні акцент робиться на розбиття програми на модулі таким чином, щоб дані (оброблювані модулем) були заховані в ньому. Ця доктрина, відома як "принцип обмеження доступу до даних", значною ступеня підвищила модифікованості і ефективність породжуваного коду.

Еволюція техніки модульного програмування призвела до появи об'єктно-орієнтованого стилю програмування, який багато в чому уніфікував процес створення ПС. До переваг цього методу відноситься те, що в ньому більш повно реалізується технологія структурного програмування, полегшується процес створення складних ієрархічних систем, з'являється зручна можливість створення користувацьких бібліотек об'єктів в різних областях застосування.

У 80-х роках дослідження причин невдач при реалізації великих програмних проектів показало, що число помилок у специфікаціях на програми значно перевищує їх кількість у програмних кодах. Так близько 56% помилок допускаються на етапі формулювання вимог до програмі при цьому витрачається в середньому 82% всіх зусиль, витрачених колективом на усунення помилок проекту. У той час як на етапі кодування програм допускається відповідно до 7% помилок і витрачається 1% зусиль на їх ліквідацію. У цей час формулюється теза про те, що метою програмування є не породження програми як такої, а створення технологічних умов, коли розробляється програмне забезпечення легко адаптується до нових обставин і нового розуміння розв'язуваної задачі. Р. Хеммінга так формулює цю тезу: "Здорова обчислювальна практика вимагає постійного дослідження вивчається завдання не тільки перед організацією обчислень, але також в процесі його розвитку і особливо на тій стадії, коли отримані числа переводяться назад і тлумачаться на мові первісної завдання ".

Перераховані вище причини привели в середині 80-х років до усвідомлення необхідності реалізації інтегрованого оточення підтримки всього життєвого циклу ПС і, в першу чергу, етапу проектування ПС, що зумовило появу інструментальних засобів автоматизації проектування програмних систем (CASE-технологій).

Спочатку CASE-засоби були орієнтовані на вирішення завдань автоматизованого збору інформації з предметної області та проектування майбутнього ПС, що дозволяє заощаджувати час при створенні ПС за рахунок більш ретельного аналізу вихідних вимог і кращого початкового планування програми. Згодом у CASE-засобах 2-го покоління повністю або частково були автоматизовані такі важливі складові життєвого циклу ПС як моделювання інформації предметної області; програмування; тестування, налагодження ПС та вимірювання якості; підтримка документування; супровід.

Застосування CASE-інструментів дозволяє в значній мірі знизити трудомісткість створення ПС, а в окремих випадках замінити програмування автоматичним синтезом програм.

Таким чином, розвиток методів автоматизації розробки ПС відбувається на різних засадах (модульне програмування, об'єктно-орієнтований підхід, логічне програмування, CASE-технології), які так чи інакше розвивають концепції структуризації в програмуванні. Структуризація сприяє проведенню ефективної декомпозиції проекту, що дозволяє отримувати як цілісне уявлення про ПП, так і його деталях. Однак, незважаючи на численні розробки в цій області, в цілому проблема автоматизації розробки ПС залишається невирішеною по багатьох причин як методологічного, так і практичного характеру.

Останнім часом у зв'язку з вдосконаленням технічних засобів відображення інформації затверджується новий графічний підхід до вирішення проблеми автоматизації розробки ПС, заснований на ідеї залучення візуальних форм представлення програм, більшою ступеня відповідних образного способу мислення людини. Застосування графічних методів обіцяє кардинально підвищити продуктивність праці програміста. Крім того, графічна форма запису в порівнянні з текстовим поданням програм забезпечує більш високий рівень їх структуризації, дотримання технологічної культури програмування, пропонує більш надійний стиль програмування.

Одним з основних факторів підвищення ефективності та на?? НАДІЙНОСТІ програмування можна вважати надання образності формам специфікації даних та опису алгоритму. У цьому сенсі головний недолік існуючих технологій програмування полягає в переважно текстових формах представлення основних компонент програми, що робить програму невиразною і надзвичайно ускладнює її сприйняття людиною.

В даний час принципово змінилася роль інформаційних технологій в суспільстві. З одного боку, програмні продукти являють собою досить дорогий товар. З іншого боку, посилилися вимоги до якості ПС, оскільки останні широко використовуються в таких сферах діяльності людини, які традиційно відносять до групи ризику. Це аерокосмічні технології, енергетика, зв'язок, бізнес і т.д.

Сучасні інформаційні технології відіграють виключно важливу роль в інтелектуалізації суспільства, дозволяють активізувати й ефективно використовувати інформаційні ресурси суспільства. Це призводить до необхідності створення ефективних методів досягнення заданої якості розроблюваних ПС в умовах обмеженості ресурсів, що виділяються на розробку.

Висока якість ПС досягається або методами безпомилкового програмування ( "пасивними" методами), або шляхом виявлення та усунення помилок ( "активними" методами).

Сучасні методи безпомилкового програмування грунтуються на реалізації процесів автоматизації всіх етапів життєвого циклу ПС від проектування і кодування програм до документування та їх супроводу. До таких засобів відносяться: CASE-засоби, об'єктно-оріенірованное програмування, методи логічного програмування. Особливе місце займають методи візуального програмування, оскільки наближення форми представлення програми і способів її кодування до образного способу мислення людини в значній мірі скорочує число помилок, яких припускаються людиною при розробці програм і підвищує надійність програмування.

Активні методи підвищення надійності ПС удосконалюються за рахунок розвитку засобів автоматизації тестування програм. Складність ПС і високі вимоги щодо їх надійності вимагають вироблення принципів структурної побудови складних програмних засобів, що забезпечують гнучкість модифікації ПС та ефективність їх налагодження. До таким принципам в роботі відносять:

- модульна і строгу ієрархію в структурному побудові програм;

- уніфікацію правил проектування, структурної побудови та взаємодії компонент ПС;

- уніфікацію правил організації міжмодульних інтерфейсу;

- поетапний контроль повноти і якості вирішення функціональних завдань.

Тестування програмного забезпечення.

Багато організацій, що займаються створенням програмного забезпечення, до 50% коштів, виділених на розробку програм, витрачають на тестування, що становить мільярди доларів по всьому світу в цілому. І все ж, незважаючи на величезні капіталовкладення, знань про суть тестування явно не вистачає і більшість програмних продуктів неприйнятно ненадійно навіть після «грунтовного тестування».

Про стан справ найкраще свідчить той факт, що більшість людей, що працюють в галузі обробки даних, навіть не може правильно визначити слово «тестування», і це на самому справі головна причина невдач.

«Тестування - процес, підтверджує правильність програми і демонструє, що помилок в програмі прокуратури. "Основний недолік такого визначення полягає в тому, що воно абсолютно неправильно; фактично це майже визначення антоніма слова «Тестування». Людина з деяким досвідом програмування вже, ймовірно, розуміє, що неможливо продемонструвати відсутність помилок в програмі. Тому визначення описує нездійсненне завдання, а так як тестування найчастіше все ж виконується з успіхом, принаймні з деяким успіхом, то таке визначення логічно некоректно. Правильне визначення тестування таке: Тестування - процес виконання програми з наміром знайти помилки.

Неможливо гарантувати відсутність помилок у нетривіальною програмі; в кращому випадку можна спробувати показати наявність помилок. Якщо програма правильно поводиться для солідного набору тестів, немає підставі стверджувати, що в ній немає помилок; з усією певністю можна лише стверджувати, що не відомо, коли ця програма не працює. Звичайно, якщо є причини вважати даний набір тестів здатним з великою ймовірністю виявити всі можливі помилки, то можна говорити про деякому рівні впевненості в правильності програми, що встановлюється цими тестами.

Психологічні експерименти показують, що більшість людей, поставивши собі за мету (наприклад, показати, що помилок немає), орієнтується у своїй діяльності на досягнення цієї мети. Тестовік підсвідомо не дозволить собі діяти проти мети, тобто підготувати тест, який виявив би одну з залишилися в програмі помилок. Оскільки ми всі визнаємо, що досконалість у проектуванні та кодуванні будь-якої програми недосяжно і тому кожна програма містить деяку кількість помилок, найбільш плідним застосуванням тестування буде знайти деякі з них. Якщо ми хочемо добитися цього і уникнути психологічного бар'єру, що заважає нам діяти проти поставленої мети, наша мета повинна полягати в тому, щоб знайти як можна більше помилок. Сформулюємо основний висновок:

Якщо ваша мета - показати відсутність помилок, ви. їх знайдете не дуже багато. Якщо ж ваша мета - показати наявність помилок, ви знайдете значну їх частину.

Надійність неможливо внести в програму в результаті тестування, вона визначається правильністю етапів проектування. Найкраще рішення проблеми надійності - з самого початку не допускати помилок в програмі. Однак імовірність того, що вдасться бездоганно спроектувати велику програму, нескінченно мала. Роль тестування складається саме в тому, щоб визначити місцезнаходження нечисленних помилок, що залишилися в добре спроектованої програмі. Спроби за допомогою тестування досягти надійності погано спроектованої програми абсолютно безплідні.

Тестування виявляється досить незвичайним процесом (ось чому воно і вважається важким), так як цей руйнівний процес. Адже мета перевіряючого (тестовіка) - змусити програму збитися. Він задоволений, якщо це йому вдається, коли ж програма на його тесті не збивається, він не задоволений.

Ще одна причина, через яку важко говорити про тестування - це той факт, що про нього відомо дуже деяке. Якщо сьогодні ми маємо в своєму розпорядженні 5% тих знанні про проектування та власне програмуванні (кодуванні), які будуть у нас до 2000 р., то про тестуванні нам відомо менше 1%.

Хоча у тестуванні можна виділити кілька різних процесів, такі терміни, як тестування, налагодження, доказ, контроль та випробування, часто використовуються як синоніми і, на жаль, для різних людей мають різне значення. Хоча стандартних, загальноприйнятих визначень цих термінів немає, спроба сформулювати їх була зроблена на симпозіумі з тестування програм. Класифікацію різних форм тестування ми почнемо з того, що дамо ці визначення, злегка їх доповнивши і розширивши їх список.

Тестування (testing), як ми вже з'ясували,-процес виконання програми (або частини програми) з наміром (або метою) знайти помилки.

Доказ (proof) - спроба знайти помилки в програмі безвідносно до зовнішнього для програми середовищі. Більшість методів доказу припускає формулювання тверджень про поведінку програми і потім висновок і доказ математичних теорем про правильність програми. Докази можуть розглядатися як форма тестування, хоча вони й не передбачають прямого виконання програми. Багато дослідників вважають доказ альтернативою тестування - погляд багато в чому помилковий; більш докладно це обговорюється в гол. 17.

Контроль (verification) - спроба знайти помилки, виконуючи програму в тестовій, або моделюється, середовищі.

Випробування (validation) - спроба знайти помилки, виконуючи програму в заданій реальному середовищі.

Атестація (certification) - авторитетне підтвердження правильності програми, аналогічне атестації електротехнічного обладнання Underwriters Laboratories. При тестуванні з метою атестації виконується порівняння з деяким заздалегідь певним стандартом.

Налагодження (debugging) не є різновидом тестування. Хоча слова «Налагодження» і «тестування» часто використовуються як синоніми, під ними маються на увазі різні види діяльності. Тестування - діяльність, спрямована на виявлення помилок; налагодження спрямована на встановлення точної природи відомої помилки, а потім - на виправлення цієї помилки. Ці два види діяльності пов'язані - результати тестування є вихідними даними для налагодження.

Тестування модуля, або автономне тестування (module testing, unit testing) - контроль окремого програмного модуля, зазвичай у ізольованому середовищі (тобто ізольовано від усіх інших модулів). Тестування модуля іноді включає також математичне доказ.

Тестування сполученні (integration testing) - контроль сполученні між частинами системи (модулями, компонентами, підсистемами).

Тестування зовнішніх функцій (external function testing) - контроль зовнішнього поводження системи, визначеного зовнішніми специфікаціями.

Комплексне тестування (system testing) - контроль та/або випробування системи по відношенню до початкових цілей. Комплексне тестування є процесом контролю, якщо воно виконується в моделюється середовищі, і процесом випробування, якщо виконується в середовищі реальної, життєвої.

Тестування прийнятності (acceptance testing) - перевірка відповідності вимогам програми користувача.

Тестування налаштування (installation testing) - перевірка відповідності кожного конкретного варіанту установки системи з метою виявити будь-які помилки, що виникли в процесі налаштування

Бета - тестування програмного забезпечення.

Інший спосіб перевірки -- бета-тестування. У цьому випадку розробники програмного забезпечення дозволяють користувачам спробувати попередні версії продуктів. Однак більшість розробників, з стверджують, що зовнішні бета-тестери не виявляють такої великої кількості помилок.

Висновки.

Швидке збільшення складності і розмірів сучасних комплексів програм при одночасному підвищенні відповідальності виконуваних функцій різко підвищило вимоги з боку користувачів до їх якості, надійності функціонування та безпеки застосування. Для кожного проекту ПС, що виконує відповідальні функції, повинні розроблятися і застосовуватися система якості, спеціальні плани і програма, методологія та інструментальні засоби, що забезпечують необхідні якість, надійність і безпеку функціонування. Для задоволення високих вимог до функціонування необхідні виділення з ЖЦ ПС завдань і робіт з забезпечення якості програм, а також навчання і концентрація зусиль розробників на аналізі та обгрунтуванні рентабельності вибраної методології та методів розробки комплексів програм.

Широкий спектр вимог до якості, залежно від призначення й області застосування ПС, призводить до необхідність адаптації стандартів, що регламентують системи якості підприємств-розробників. Послідовна деталізація рекомендацій базових стандартів повинна доводиться до формування посадових інструкцій фахівцям, утворюючи в сукупності ієрархічний комплекс нормативних документів системи якості підприємства, що забезпечує життєвий цикл складних програмних засобів.

Тільки скоординоване, комплексне застосування в проектах ПС з початку проектування сучасних методів і стандартів дозволяє досягати високої якості, необхідного для використання ПС в розподілених критичних і складних системах обробки інформації. Необхідно переконати керівників проектів, замовників і розробників в тому, що ретельно регламентований і досить повне системне проектування ПС і БД на основі сучасних методів і міжнародних стандартів вигідно з позиції скорочення помилок і підвищення якості складних комплексів програм.

Список літератури

Крайер Е. Успішна сертифікація на відповідність нормам ISO серії 9000: Пер. с нем. - М.: Издат, 1999.

2. Збірник діючих міжнародних стандартів ISO серії 9000. Т. 1-3. - М.: ВНИИК, 1998.

3. Encyclopedia of Software Engineering. Vol.1 A-N; Vol. 2 O-Z. Editor -- In - Chief John J. Marciniak. John Wiley & Sons.Inc. 1995.

4. Глудкін О.П. та ін Загальне управління якістю: Підручник для вузів. - М.: Радіо і зв'язок, 1999.

5. Глічев А.В. Основи управління якістю продукції. - М.: МАИ, 1998.

6. Круглов М.Г., Шишков Г.М. Управління якістю TQM. - М.: МГТУ "Станкин", 1999.

7. Липа В.В. Сертифікація систем якості підприємств, що розробляють програмні засоби для інформаційних систем, на відповідність стандартам серії ISO 9000// Інформаційні технології. - 1999. -