Тема: ОЦІНКА ЯКОСТІ ПРОЦЕСІВ СТВОРЕННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Лекція 4.
Контрольні питання і завдання
1. Що таке модуль життєвого циклу ПЗ? Які є типи моделей?
2. Порівняйте прогнозовані моделі і адаптивні. Коли вони приміняються?
3. Що таке прототип? В яких моделях він присутній?
4. Що таке CASE-технології? Що лежить в основі будь-якої CASE-технології?
5. Поясніть терміни: методологія, метод, нотація, засіб.
6. Поясніть якісні зміни процесу розробки ПЗ при переході до використання CASE-засобів.
Як вже згадувалося, сучасний період на ринку програмного забезпечення характеризується переходом від штучного ремісничого виробництва програмних продуктів до їх промислового створення. Відповідно зросли вимоги до якості розробки ПЗ, що вимагає вдосконалення процесів їх розробки. На даний момент існує декілька стандартів, пов'язаних з оцінкою якості цих процесів, яку забезпечує організація-розробник. До найбільш відомим відносять:
ü міжнародні стандарти серії ISO 9000 (ISO 9000 - ISO 9004) [3];
ü СММ - Capability Maturity Model - модель зрілості (вдосконалення) процесів створення програмного забезпечення, запропонована SEI (Software Engineering Institute – інститут програмування при університеті Карнеги-Меллон) [11];
ü робоча версія міжнародного стандарту ISO/IEC 15504 [18]: Information Technology – Software Process Assessment; ця версія відоміша під назвою SPICE - (Software Process Improvement and Capability dEtermination - визначення можливостей і поліпшення процесу створення програмного забезпечення).
Серія стандартів ISO 9000.У серії ISO 9000 сформульовані необхідні умови для досягнення деякого мінімального рівня організації процесу, але не даються ніяких рекомендацій по подальшому вдосконаленню процесів.
СММ.СММ являє собою сукупність критеріїв оцінки зрілості організації-розробника і рецептів поліпшення існуючих процесів.
Примітка. Спочатку СММ розроблялася і розвивалася як методика, що дозволяє крупним урядовим організаціям США вибирати якнайкращих постачальників програмного забезпечення. Для цього передбачалося створити вичерпний опис способів оцінки процесів розробки програмного забезпечення і методики їх подальшого удосконалення. У результаті автори змогли добитися такого ступеня подробиці і деталізації, що стандарт виявився придатним і для звичайних компаній-розробників, охочих якісно поліпшити існуючі процеси розробки, привести їх до певних стандартів.
СММ визначає п'ять рівнів зрілості організацій-розробників, причому кожен наступний рівень включає всі ключові характеристики попередніх.
1. Початковий рівень (initial level) - описаний в стандарті як основа для порівняння з наступними рівнями. На підприємстві такого рівня організації не існує стабільних умов для створення якісного програмного забезпечення. Результат будь-якого проекту цілком і повністю залежить від особистих якостей менеджера і досвіду програмістів, причому успіх в одному проекті може бути повторений тільки у разі призначення тих же менеджерів і програмістів на наступний проект. Більш того, якщо ці менеджери або програмісти йдуть з підприємства, то різко знижується якість розробки програмних продуктів. У стресових ситуаціях процес розробки зводиться до написання коду і його мінімального тестування.
2. Рівень повторення (repeatable level) - на підприємстві упроваджені технології управління проектами. При цьому планування і управління проектами грунтуються на накопиченому досвіді, існують стандарти на розробку програмного забезпечення (причому забезпечується дотримання цим стандартам) і спеціальна група забезпечення якості. У разі потреби організація може взаємодіяти з субпідрядниками. У критичних умовах процес має тенденцію скочуватися на початковий рівень.
3. Визначений рівень (defined level) - характеризується тим, що стандартний процес створення і супроводу програмного забезпечення повністю документований (включаючи і розробку ПЗ, і управління проектами). Мається на увазі, що в процесі стандартизації відбувається перехід на найбільш ефективні практики і технології. Для створення і підтримки подібного стандарту в організації повинна бути створена спеціальна група.
Нарешті, обов'язковою умовою для досягнення даного рівня є наявність на підприємстві програми постійного підвищення кваліфікації і навчання співробітників. Починаючи з цього рівня, організація перестає залежати від якостей конкретних розробників, і процес не має тенденції скочуватися на рівень нижче в стресових ситуаціях.
4. Керований рівень (managed level) - в організації встановлюються кількісні показники якості, як на програмні продукти, так і на процес в цілому. Таким чином, досконаліше управління проектами досягається за рахунок зменшення відхилень різних показників проекту. При цьому осмислені варіації в продуктивності процесу можна відрізнити від випадкових варіацій (шуму), особливо в добре освоєних областях.
5. Оптимізуючий рівень (optimizing level) - характеризується тим, що заходи щодо поліпшення застосовуються не тільки до існуючих процесів, але і для оцінки ефективності введення нових технологій. Основним завданням всієї організації на цьому рівні є постійне поліпшення існуючих процесів. При цьому поліпшення процесів в ідеалі повинне допомагати попереджати можливі помилки або дефекти. Крім того, повинні вестися роботи по зменшенню вартості розробки програмного забезпечення, наприклад за допомогою створення і повторного використання компонентів.
Сертифікаційна оцінка відповідності всіх ключових областей проводиться за 10-бальною шкалою. Для успішної кваліфікації даної ключової області необхідно набрати не менше 6 балів. Оцінка ключової області здійснюється за наступними показниками:
• зацікавленість керівництва в даній області, наприклад, чи планується практичне впровадження даної ключової області, чи існує розуміння у керівництва необхідності даної області і т. д.;
• наскільки широко дана область застосовується в організації, наприклад, оцінці в 4 бали відповідає фрагментарне застосування;
• успішність використання даної області на практиці, наприклад, оцінці в 0 балів відповідає повна відсутність якого-небудь ефекту, а оцінка в 8 балів виставляється за наявності систематичного і вимірного позитивного результату практично у всій організації.
В принципі, можна сертифікувати тільки один процес або підрозділ організації, наприклад, підрозділ розробки програмного забезпечення компанії IBM сертифікований на п'ятий рівень. До речі, в світі існує зовсім трохи компаній, які можуть похвалитися наявністю у них п'ятого рівня СММ хоч би в одному з підрозділів, - таких всього біля 50-ти. З іншого боку, налічується декілька тисяч компаній, сертифікованих по третьому або четвертому рівнях, тобто існує колосальний розрив між оптимізованим рівнем зрілості і попередніми рівнями. Проте ще більший розрив спостерігається між кількістю організацій початкового рівня і числом їх більш просунутих побратимів - по деяких оцінках, понад 70 % всіх компаній-розробників знаходиться на першому рівні СММ [3].
SPICE.Стандарт SPICE успадкував багато попередніх стандартів, у тому числі і ISO 9001 і СММ. Більше всього SPICE нагадує СММ. Точно так, як і в СММ, основним завданням організації є постійне поліпшення процесу розробки ПЗ. Крім того, в SPICE теж використовується схема з різними рівнями можливостей (у SPICE визначено 6 різних рівнів), але ці рівні застосовуються не тільки до організації в цілому, але і до окремо узятих процесів.
У основі стандарту лежить оцінка процесів. Ця оцінка виконується шляхом порівняння процесу розробки програмного забезпечення, що існує в даній організації, з описаною в стандарті моделлю. Аналіз результатів, отриманих на цьому етапі, допомагає визначити сильні і слабкі сторони процесу, а також внутрішні ризики, властиві даному процесу. Це допомагає оцінити ефективність процесів, визначити причини погіршення якості і пов'язані з цим витрати в часі або вартості.
Потім виконується визначення можливостей процесу, тобто можливостей його поліпшення. В результаті в організації може з'явитися розуміння необхідності поліпшення того або іншого процесу. До цього моменту мета вдосконалення процесу вже чітко сформульована і залишається тільки технічна реалізація поставлених завдань. Після цього весь цикл робіт починається спочатку.
Безумовно, вдосконалення процесів життєвого циклу програмного забезпечення абсолютно необхідне. Проте слід мати на увазі, що побудова «зрілішого» процесу розробки не обов'язково забезпечує створення якіснішого програмного забезпечення. Це хоча і зв'язані, але абсолютно різні процеси.
Використання формальних моделей і методів дозволяє створювати зрозумілі, несуперечливі специфікації на програмне забезпечення, що розробляється. Звичайно, впровадження таких методів має сенс, хоча воно вельми дороге і трудомістко, а можливості їх застосування вельми обмежені. Основна ж проблема - проблема складності програмного забезпечення, що розробляється, з вдосконаленням процесів розробки поки не вирішена.
Створення ПЗ як і раніше ставить підвищені вимоги до кваліфікації тих, хто цим займається: проектувальникам програмного забезпечення і безпосередньо програмістам.