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

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.


Нажми чтобы узнать.
скачати

Введення.

Всім, хто коли-небудь працював з програмним забезпеченням виробництва 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 AN; Vol. 2 OZ. Editor - In - Chief John J. Marciniak. John Wiley & Sons.Inc. 1995.

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

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

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

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

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
56.6кб. | скачати


Схожі роботи:
Розробка програмних продуктів
Тестування програмних продуктів
Поняття про інсталювання програмних продуктів
Програмні продукти та їх характеристики Основна характеристика програмних продуктів
Ознаки якості і не якості харчових продуктів і міри їх попередження
Оцінка якості програмних комплексів
Характеристика якості програмних засобів
Види програмного забезпечення Загальні вимоги до програмних систем
Показники якості продуктів харчування
© Усі права захищені
написати до нас
Рейтинг@Mail.ru