ALL(PDF)

•9000-2 - настанови щодо застосування ISO -9001, ISO -9002 та ISO -9003

•9000-3 - настанови щодо застосування ISO -9001 до розроблення, поставляння та супроводження ПЗ.

•9000-4 - настанови щодо управління програмною надійністю.

ISO-9001- системи якості - є найбільш повним

•Це модель забезпечення якості в процесі проектування розроблення, виробництва, монтажу та обслуговування.

•Цей стандарт специфікує модель забезпечення якості на всіх етапах життєвого циклу товару/послуги.

ISO-9002 та ISO-9003

•ISO-9002 - системи якості - модель забезпечення якості в процесі виробництва, монтажу та обслуговування.

•ISO-9003 - системи якості - модель забезпечення якості в процесі контролю готової продукції та її випробування.

ISO-9004 має чотири частини:

•ISO-9004-1 - управління якістю та елементи системи якості: Частина 1: настанови

•ISO-9004-2 - управління якістю та елементи системи якості: Частина 2: настанови щодо послуг.

•ISO-9004-3 - управління якістю та елементи системи якості: Частина 3: настанови щодо перероблюваних матеріалів.

•ISO-9004-4 - управління якістю та елементи системи якості: Частина 4: настанови щодо поліпшення якості.

Для процесу розробки програм використовується стандарт ISO 9001, що передбачає проектування в процесі виробництва

Даний стандарт складно використовувати безпосередньо в управлінні якістю розробки програмного забезпечення, оскільки він орієнтований на розробку промислових виробів.

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

Отже, для оцінювання якості процесу розробки у власній організації або в організації підрядників можуть використовуватися вимоги керівництва ISO 9000-3.

Нині повсюдно вводиться у використання версія стандарту 2000 року, у якому в основу ставиться управління процесом, однак у даній версії стандарту специфіка, пов'язана з розробкою ПЗ відсутня.

Хоча стандарти ISO розроблялися за урядової підтримки, сертифікація за ISO 9000 — справа цілком добровільна

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

Основною причиною сертифікації є те що закордонні компанії вимагають наявності сертифіката від своїх постачальників.

Більш того, наявність сертифіката може бути обов’язковою умовою для участі підприємства в міжнародних тендерах, держзамовленнях, а також отримання пільгових кредитів та страховок.

Сертифікація підприємства за стандартом ISO-9000 включає такі три етапи:

•застосування стандартів на підприємстві, яке полягає в розробці та введенні в дію низки заходів, пропонованих стандартами

•проведення власне сертифікації акредитованими ISO – органами (спеціальна фірмареєстратор здійснює інспекцію компанії)

•періодичні (два рази на рік) перевірки підприємства на наслідування (відповідність) стандартів

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

В іншому випадку реєстрація може бути визнана недійсною.

2. Необхідність розробки системи управління по забезпеченню якості ПП

Програмні продукти стали визнавати як продукцію технічного призначення з середини 80-х років минулого століття

Але і дотепер, більшість програмістських фірм не спромоглися довести організацію процесу розробки програмних систем до рівня “індустріального”.

Для налагодження такого процесу недостатньо мати висококваліфікованих, талановитих фахівців,

необхідними є :

•Чітка організація спільної роботи команди розробників;

•Загальне управління проектом, яке включає не тільки розподіл обов’язків, а й розподіл відповідальності.

Система якості є організаційним стрижнем створення оптимальних умов для продуктивної праці фахівців.

Вона дозволяє перейти від кустарного рівня створення програм до наукового, організованого, масового виробництва програмного продукту, завдяки застосуванню особливих методів управління якістю.

Ці методи варіюються від компанії до компанії, але основні їх положення єдині для всіх і визначаються стандартом ISO-9001 і ISO-9000-3.

Останній включає усі положення загального стандарту ISO-9001, а також необхідні доповнення до них, що стосуються розробки, поставки й обслуговування ПЗ.

ISO-9001 встановлює вимоги до системи якості постачальника і дозволяє оцінити його можливості з проектування та постачання продукції, на відповідність цим вимогам.

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

3. Основні положення стандарту ISO-9000-3

Основні поняття, якими оперує стандарт ISO-9000-3:

Продукт – результат дії або процесів; Програмний продукт - набір комп’ютерних програм, процедур і , можливо, пов’язаних з ними

документів та даних;

Елемент програмного забезпечення - (software item) - будь-яка частина програмного продукту, що ідентифікована;

Основа (baseline) - формально узгоджена версія елемента конфігурації, зафіксована у певний момент

часу на протязі життєвого циклу елемента конфігурації;

Розробка (development) - процес життєвого циклу ПП, що охоплює аналіз вимог, проектування, кодування, інтеграцію, тестування, установку та підтримку;

Модель життєвого циклу - (life cycle model) - базова модель, яка включає процеси, дії та задачі, що мають місце у розробці, функціонуванні та супроводі ПП і охоплюють увесь життєвий цикл системи від визначення вимог до завершення;

Етап - певний сегмент роботи;

Регресійне тестування - (regression testing)- тестування , що дозволяє упевнитися в тому, що зміни, внесені з метою виправлення виявлених помилок , не породили нових;

Реплікація - (replication)- копіювання програмного продукту з одного носія на інший.

Стандарт впроваджується на добровільній основі і зобов’язує підприємства строго регламентувати такі аспекти виробничої діяльності:

•Відповідальність керівництва;

•Система якості;

•Аналіз контракту;

•Управління проектуванням;

•Управління документацією і даними;

•Закупки;

•Ідентифікація та відслідковування продукції;

•Управління процесами;

•Контроль і випробування;

•Управління продукцією, що не відповідає вимогам;

•Коригувальні та запобіжні дії;

•Завантажувально-розвантажувальні роботи, зберігання, упаковка, консервація та поставка;

•Управління реєстрацією даних про якість;

•Внутрішній аудит якості;

•Підготовка кадрів;

•Обслуговування.

1. Відповідальність керівництва

На керівництво компанії–постачальника покладається задача визначення політики та зобов’язань з

якості.

Політика повинна бути узгодженою як з цілями самої компанії, так і з очікуваннями і запитами

самого користувача.

Постачальник повинен забезпечити розуміння цієї політики службовцями компанії, її проведення та підтримку на усіх рівнях.

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

Керівництво призначає менеджера з якості з відповідними повноваженнями для забезпечення розробки, впровадження та підтримки в робочому стані системи якості та надання звітів про її

функціонування , які дозволяють проаналізувати та удосконалити систему якості.

2. Система якості

Компанія-постачальник повинна розробити, документально оформити та підтримати в робочому стані систему якості як засіб, що забезпечує відповідність продукції вимогам стандарту ISO-9001.

Система якості передбачає наявність:

•Інструкції з якості, яка включає методики системи якості компанії;

•Опис структури документації , що використовується в системі якості.

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

2. Система якості (закінчення)

Постачальник також визначає та документально оформляє дії, пов'язані з реалізацією вимог до якості, тобто планує якість –

•формулює вимоги до якості,

•описує модель ЖЦ,

•задає критерії початку і кінця кожного етапу проекту,

•визначає типи аналізу, тестування та інших дій з перевірки та затвердження ПП,

•визначає процедури управління конфігурацією.

Планування якості “настроює” систему якості на певний проект.

3. Аналіз контракту

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

ППможе розроблятись:

•За контрактом із замовником;

•Як комерційний продукт для певного сектора ринку;

•Як система, вмонтована в апаратне забезпечення;

•Як система підтримки бізнес-процесів постачальника.

Загальні положення аналізу контрактів, визначені в ISO 9000-3, прийнятні для будь-якої з цих ситуацій.

3. Аналіз контракту (продовження)

Постачальник повинен попередньо проаналізувати заявку на тендер, контракт чи замовлення (до надання заявки або укладання контракту).

Це дозволить гарантувати адекватне визначення вимог до проекту і можливість виконати контракт.

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

3. Аналіз контракту (закінчення)

Наприклад, можуть аналізуватися:

•узгоджені із замовником критерії прийняття або відмови від готової системи;

•термінологія;

•ступінь участі замовника у спільній роботі;

•відповідальність замовника за надання певних даних або обладнання;

•зобов'язання замовника перед постачальником із заміни на нові версії системи або зобов'язання постачальника підтримувати старі версії, тощо.

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

4. Управління проектуванням Це найбільший розділ стандарту, оскільки стосується базової складової загального процесу

створення ПП, яка найбільше впливає на його якість.

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

Цей розділ стандарту IS0 9000-3 містить вказівки з таких основних дій в процесі розробки:

•аналіз вимог до проекту;

•проектування архітектури систем;

•детальне проектування та кодування;

•планування розробки.

4.Управління проектуванням (продовження)

Проект розробки ПП організується за певною моделлю ЖЦ.

ISO 9000-3 не визначає, якою повинна бути модель ЖЦ, це залежить від специфіки задачі. Стандарт наводить лише визначення моделі ЖЦ як сукупності процесів.

Модель показує, коли ці процеси і як підключаються до реалізації проекту.

4. Управління проектуванням (продовження)

Відомо, що розробка системи – це процес встановлення початкових вимог до кінцевого продукту. Стандарт оговорює, що цей процес повинен проводитись у чітко визначеному порядку, що дозволить

попередити появу помилок та усуне залежність від процесів перевірки та затвердження як єдиних методів по виявленню проблемних ситуацій.

Вимога строго дотримуватись дисципліни процесу розробки означає наявність та підтримку в робочому стані документованих процедур, які і стануть гарантією того, що ПП створюється у відповідності

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

4.Управління проектуванням (продовження)

Управління проектом повинне враховувати такі аспекти як:

•метод проектування та його відповідність конкретній задачі;

•досвід попередніх проектів;

•вимоги таких процесів: тестування, установки, супроводу та використання;

•вимоги до захисту та безпеки;

•спеціальні вимоги до стійкості систем або до її зворотних дій на потенційні аварійні ситуації.

4. Управління проектуванням (продовження)

Для процесів кодування необхідно задавати правила використання мов програмування, принципи кодування та правила розробки відповідних коментарів.

Інструментальні засоби і методи, що використовуються при розробці ПП (системи аналізу та проектування, компілятори) повинні попередньо затверджуватись і контролюватися системою конфігураційного управління.

Область застосування інструментарію повинна бути задокументована, а його використання періодично аналізуватися, з метою встановлення необхідності удосконалення інструментальних систем або заміни на нові продукти.

4. Управління проектуванням (продовження)

Проектування та розробка повинні ретельно плануватись.

План розробки ПП повинен формулювати задокументовані дії з:

•аналізу вимог до систем;

•проектування;

•кодування;

•інтеграції;

•тестування;

•встановлення;

•підтримки.

4. Управління проектуванням (продовження)

План повинен включати також такі пов’язані з основним процесом плани :

•забезпечення якості;

•управління ризиками;

•управління конфігурацією;

•плани інтеграції;

•плани установки;

•плани навчання співробітників та ін.

4.Управління проектуванням (продовження)

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

Необхідно чітко встановити межі відповідальності кожного учасника і те як технічна інформація буде передаватися між учасниками.

Тут також оговорюється відповідальність замовника проекту, якщо він бере участь в розробці:

–необхідність брати участь в проекті,

–зобов'язання по своєчасному наданню потрібної інформації.

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

Цей аналіз торкається таких чинників, як хід розробки з боку постачальника, участь в розробці з боку замовника, відповідність системи вимогам замовника, результати перевірок, результати тестування.

4. Управління проектуванням (продовження)

Вхідні проектні вимоги до продукції.

Вимоги формулює замовник, а постачальник аналізує, наскільки вони адекватні.

Неповні, двозначні або суперечливі вимоги є предметом урегулювання з особами, відповідальними за їх висунення.

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

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

Вихідні дані проекту програмної системи можуть включати:

–специфікацію архітектури проекту,

–детальну специфікацію проекту,

–початкові коди,

–керівництво користувача.

4.Управління проектуванням (продовження)

Постачальник програмного продукту повинен планувати і провести офіційний, документально оформлений аналіз результатів проектування.

Міра формальності та строгість процесів аналізу відповідають складності системи, що розробляється і ступеню ризику, пов'язаного з її використанням.

Аналіз проектування стосується таких аспектів:

•можливість виконати проект,

•задоволення вимог захисту і безпеки системи,

•виконання правил програмування і

•можливість тестування.

4.Управління проектуванням (продовження)

На певних стадіях проектування проводиться перевірка відповідності вихідних даних вхідним вимогам. Така верифікація проекту може включати аналіз вихідних даних, демонстрації, в тому числі за

допомогою прототипів і моделювання, або тестування.

Тільки перевірені вихідні проектні дані затверджуються для остаточного прийому і подальшого використання.

Усі виявлені в процесі перевірки проблемні ситуації повинні адекватно розв'язуватися.

4. Управління проектуванням (закінчення)

Перш ніж система буде передана замовнику, постачальник повинен затвердити систему на відповідність заданому призначенню.

Замовнику може бути переданий тільки затверджений програмний продукт.

Всі зміни і модифікації проекту повинні бути ідентифіковані, документально оформлені, проаналізовані і затверджені до їх реалізації.

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

7. Ідентифікація і відслідковування продукції (продовження)

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

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

7.Ідентифікація і відслідковування продукції (закінчення)

Увизначенні конфігурації беруть участь:

•структура продукту і вибір елементів конфігурації,

•друкована документація і комп'ютерні файли,

•угоди по присвоєнню імен, встановленню конфігураційних основ.

8. Управління процесами

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

вимоги на програмний продукт (див. розділ стандарту "Управління проектуванням").

Даний розділ стандарту оговорює вимоги до реплікації, доставки й інсталяції програмних продуктів.

9. Контроль і випробування

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

Контроль і випробування, простіше кажучи, тестування програмного продукту може потребуватися на кількох рівнях, від окремих елементів ПЗ до закінченої системи.

Існує кілька підходів до тестування, які даним стандартом не оговорюються. Вибір підходу залежить від постачальника.

Обсяг тестування, міра контролю за середовищем випробувань, вхідні і вихідні дані тестів можуть варіюватися в залежності від вибраного підходу, складності системи і пов'язаних з нею ризиків.

9. Контроль і випробування (продовження)

Постачальник повинен визначити, задокументувати і періодично аналізувати план:

•тестування модулів,

•тестування інтеграційних процесів,

•системи загалом і

•тестування для остаточного приймання.

Упроцесі розробки постачальник повинен контролювати і випробовувати продукцію відповідно до програми якості.

9. Контроль і випробування (продовження)

Всі види остаточного контролю і тестування також потрібно провести відповідно до цієї програми, щоб пересвідчитися, що готовий продукт відповідає встановленим вимогам.

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

Будь-які відмінності між середовищем затвердження системи і фактичним середовищем її використання,