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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перечисленные вище причини викликали появу середині 1980;х років до усвідомлення потреби реалізації інтегрованого оточення підтримки всього життєвого циклу ПС й у першу чергу, етапу проектування ПС, що зумовили створення інструментальних коштів автоматизації проектування програмних систем (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) — перевірка відповідності кожної конкретної варіанта установки системи із єдиною метою виявити будь-які помилки, які виникли у процесі настройки.

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

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

Выводы..

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

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

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

Крайер Еге. Успішна сертифікація щодо відповідності нормам ИСО серії 9000: Пер. з ньому. — М.: ИздАТ, 1999.

2. Збірник діючих міжнародних стандартів ИСО серії 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. Липаев В. В. Сертифікація систем якості підприємств, котрі розробляють програмні кошти на інформаційних систем, щодо відповідності стандартам серії ИСО 9000 // Інформаційні технології. — 1999. —? 12.

Для підготовки даної роботи було використано матеріали із сайту internet.

11 квітня 2002 г.