К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Концепції якості ПЗ – це зовнішні і внутрішні характеристики якості, їхні метрики, а також моделі якості, визначені на множині цих характеристик, що наведені в стандартах з якості і в [8, 9] – це шість характеристик і кожна з них має кілька атрибутів. До характеристик якості належать: – функціональність (functionality); – надійність (realibility); – зручність застосування (usability); – ефективність (efficiency); – супровід (maitainnability); – переносність (portability). Базова модель якості містить у собі ці характеристики і вони притаманні будь-якому типу програмних продуктів. При розробці вимог замовник формулює Розділ 1 47 такі вимоги до якості, які найбільшою мірою підходять для програмного продукту, який замовляється. Визначення і планування якості ПЗ ґрунтується на положеннях стандартів у цій області, складанні планів і графіків робіт, процедурах перевірки і ін. План забезпечення якості містить у собі набір дій для перевірки процесів забезпечення якості (верифікація, валідація і ін.) і формування документа з керування якістю. Планування якості призначено для підтримки керування процесами досягнення якості продуктів проекту (зокрема проміжних робочих) і ресурсів – програмних, технічних, виконавських і ін. Воно також передбачає керування вимогами до процесів і продуктів і полягає в наступному: – визначення продукту термінами заданими характеристиками якості; – планування процесів для гарантії одержання необхідної якості; – вибір методів оцінки запланованих характеристик якості і встановлення відповідності продукту сформульованим вимогам. У стандарті ISO/IEC 12207 визначені спеціальні процеси забезпечення якості – верифікація, валідація (атестація), спільний аналіз і аудит. Види діяльності і техніки гарантії якості містять у собі, зокрема: інспекцію, верифікацію і валідацію ПЗ. Інспекція ПЗ – аналіз і перевірка різних видів подання системи і ПЗ (специфікації, архітектурної схеми, діаграм, початкового коду тощо). Виконується на всіх процесах ЖЦ розробки ПЗ. Верифікація ПЗ – процес забезпечення правильної реалізації ПЗ відповідно до специфікацій, виконується протягом усього життєвого циклу. Верифікація дає відповідь на питання, чи правильно створюється система. Валідація – процес перевірки відповідності ПЗ функціональним і нефункціональним вимог і очікуваним потребам замовника. Верифікація і валідація (V&V) можуть виконуватися, починаючи з ранніх стадій ЖЦ. Вони орієнтовані на отримання правильних функцій ПЗ, плануються і забезпечуються визначеними ресурсами з чітким розподілом ролей. Перевірка ґрунтується на використанні відповідних технік тестування для виявлення тих або інших дефектів і збирання статистики. Після зібрання даних оцінюється правильність реалізації вимог і роботи ПЗ у заданих умовах. Вимірювання при аналізі якості ПЗ ґрунтується на метриках продукту і даних, зібраних у процесі створення продукту при заданих ресурсах: оцінок процесів, ПЗ і його моделей, і передбачає документування вимірів. Оцінювання якості продукту полягає у вимірюванні і оцінюванні якісних показників за допомогою даних про різні типи помилок і відмов під час тестування ПЗ і виконання коду на тестових даних. Ці дані аналізуються, перевіряються і використовуються при якісній і кількісній оцінки ПЗ. Для імітації роботи системи в режимі тестування розробляються тести з реальними вхідними даними для перевірки правильності роботи ПЗ на різних фрагментах програми і шляхах проходження в них операторів. У процесі тестування ПЗ виявляються різного роду помилки (відмови, дефекти, помилки тощо), кількість яких значною мірою може вплинути на одержання правильного і якісного результату. З урахуванням типів виявлених помилок можна встановити наявність (або відсутність) відповідності реалізованих і нереалізованих функцій, заданих у 48 Розділ 1 вимогах до системи, а також оцінити способи реалізації нефункціональних вимог (продуктивності, надійності та ін.). Оцінюються процеси керування планами, інспекціями, прогонами і т.п. За цими оцінками приймаються рішення про завершення розробки продукту проекту і передачі його замовнику в експлуатацію, під час якої можуть бути внесені зміни щодо усунення помилок, визначення адекватності планів і вимог, оцінки ризиків перероблення ПЗ тощо. Мета інспекцій – виявлення різних аномальних станів у ПЗ незалежними фахівцями команди експертів із залученням авторів проміжного або кінцевого продукту. Експерти інспектують виконання вимог, інтерфейси, вхідні дані і т.п., а потім документують виявлені відхилення в проекті. Призначення аудита – незалежна оцінка продуктів і процесів на відповідність регулюючим і регламентуючим документам (планам, стандартам і ін.), формулювання звіту про випадки невідповідності і пропозицій для їх коригування. Таким чином, розгляд розділів SWEBOK свідчить по те, що це ядро містить весь необхідний набір знань з програмної інженерії, який повинні мати фахівці різних профілів (аналітики, інженери, програмісти, оцінювачі, контролери тощо), що виробляють програмний продукт. Зазначимо, що ядро знань SWEBOK не позбавлено недоліків тактичного характеру. Так, між областями знань у цьому ядрі існують перетини за методами, концепціями і стратегіями, а деякі важливі напрями програмної інженерії взагалі не відбиті у ньому наявними областями знань. Це стосується, наприклад, методів доведення правильності програм, еволюції програм, розподілених і неоднорідних середовищ, взаємодії систем, таких методів програмування, як аспектне, агентне, сервісне й інші, а також аспектів захисту, безпеки тощо. Висновки. Запропоновано нове тлумачення програмної інженерії з точки зору науки, інженерії, економіки і керування виробництвом ПП. Наведено дефініцію програмної інженерії як спадкоємиці програмування і комп’ютерної науки, розглянуто її головний аспект – керування роботами і колективом. Обґрунтовано теоретичні і прикладні ознаки та атрибути програмної інженерії і її дисциплін. Визначено їхню структуру, зміст та концепції, а також їхні базові елементи. Встановлено зв’язки основних елементів ПІ через SWEBOK, стандарт ISO/IEC 12207 і PMBOK. Разом вони забезпечують дисципліни вироблення програмних продуктів на процесах розроблення, керування і регулювання діяльності розробників програмних продуктів. Контрольні питання і завдання 1. Назвіть мету і задачі програмної інженерії. 2. Назвіть основні складові наукової дисципліни. 3. Назвіть області знань SWEBOK інженерії розроблення ПЗ. 4. Назвіть основні задачі області інженерії вимог. 5. Назвіть основні задачі області знань «Проектування ПЗ» 6. Визначте мету і задачі області знань «Методи і інструменти» 7. Наведіть базові поняття області знань «Тестування ПЗ». 8. Визначте мету і задачі області знань «Керування проектом». 9. Наведить приклади інструментів програмної інженерії. 10. Визначте мету і задачі області знань «Інженерія якості ПЗ». 11. Вкажіть, який зв'язок існує між ядром знань SWEBOK і стандартом ЖЦ. Розділ 1 49 12. Охарактеризуйте інфраструктуру програмної інженерії. Список літератури до розділу 1 1. Рекомендации по преподаванию программной инженерии и информатики в университетах.–Computing Curricula-2001: Computer Science.–Пер. с англ. – Интернет– Ун. информац. технологий, М.: 2007.–462с. 2. Бабенко Л.П., Лавріщева К.М. Основи програмної інженерії.– Навч. посібник.–К.: Знання, 2001. –269 с. 3. Лаврищева Е.М., Грищенко В.Н. Области знаний программной инженерии – SWEBOK и подход к обучению этой дисциплине// Управляющие системы и машины.–2005. – №1.– С.38–54. 4. Pfleeger S.L. Software Engineering. Theory and practice. – Printice Hall: Upper Saddenle River, New Jersey, 1998. – 576 p. 5. Jacobson I. Object-Oriented Software Engineering. A use Case Driven Approach, Revised Printing. – New York: Addison-Wesley Publ. Co., 1994. – 529 p. 6. Иан Соммервил. Инженерия программного обеспечения. 6-е издание. – М.; Спб. – Киев, 2002. – 623 с. 7. Лавріщева К.М. Основні напрямки досліджень в програмній інженерії і шляхи їхнього розвитку // Проблеми програмування. – 2003. – № 3–4. – С. 44–58. 8. Лаврищева Е.М. Методы программирования. Теория, инженерия, практика. – К.: Наук. думка, 2006.–450с. 9. Основы инженерии качества программных систем / Ф.И.Андон, Г.И.Коваль, Т.М. Коротун, Е.М.Лаврищева, В.Ю. Суслов – К.: Академпериодика.– 2007. – 678 с. 10. Лаврищева Е.М., Коваль Г.И., Коротун Т.М. Подход к управлению качеством программных систем обработки данных // Кибернетика и системный анализ.– 2006.–№ 5.–С.174–185. 11. Capability Maturity Model for Software, Version 1.1 / M.Paulk, B.Curtis et al. // CMU–SEI–TR–024, Soft. Engin. Institute, Pittsburg PA 15213, Feb. – Pittsburg, 1993. – 82 p. 12. Thayer R.H., ed. Software Engineering Project Management, 2 nd. ed., IEEE CS Press, Los Alamitos, Calif., 1997. – 391 p., http://petukhov.zaklad.ru/rmbok2004_rus.pdf 13. Кендалл С. Унифицированный процесс. Основные концепции.–М.;–СПб.– Киев.–2002.– 157с. 50 Розділ 2. СТАНДАРТ І МОДЕЛІ ЖИТТЄВОГО ЦИКЛУ За десятки років розробки програмного забезпечення і програмних систем створено низку типових схем упорядкування виконання робіт з проектування і розроблення. Такі схеми одержали назву життєвого циклу і узагальнені в стандарті ISO/IEC 12207 і основоположних моделях ЖЦ, що застосовуються на практиці. 2.1 Характеристика життєвого циклу стандарта ISO/IEC 12207 Стандарт ISO/IEC 12207:2002 визначає загальну структуру і зміст ЖЦ ПС, починаючи з розробки концепції до утилізації системи. Структурно він складається з опису багатьох процесів, взаємозв'язків між ними, а також сформульованих дій і задач, виконуваних у цих процесах. Іншими словами, стандартний життєвий цикл визначає лише схему робіт за процесами розробки ПС, а не те, як саме виконувати ті або інші процеси (табл.2.1). Таблиця 2.1. Процеси життєвого циклу в стандарті ISO/IEC 12207 № п/п Процес (підпроцес) 1. Категорія «Основні процеси» 1.1 Замовлення (договір) 1.1.1 Підготовка замовлення, вибір постачальника 1.1.2 Моніторинг діяльності постачальника, приймання споживачем 1.2 Постачання (придбання) 1.3 Розроблення 1.3.1 Виявлення вимог 1.3.2 Аналіз вимог до системи 1.3.3 Проектування архітектури системи 1.3.4 Аналіз вимог до ПЗ системи 1.3.5 Проектування ПЗ 1.3.6 Конструювання (кодування) ПЗ 1.3.7 Інтеграція ПЗ 1.3.8 Тестування ПЗ 1.3.9 Системна інтеграція 1.3.10 Системне тестування 1.3.11 Інсталяція ПЗ 1.4 Експлуатація 1.4.1 Функціональне використання 1.4.2 Підтримка споживача 1.5 Супроводження 2. Категорія «Процеси підтримки» 2.1 Документування 2.2 Керування конфігурацією 2.3 Забезпечення гарантії якості 2.4 Верифікація 2.5 Валідація 2.6 Загальний огляд 2.7 Аудит 2.8 Вирішення проблем 2.9 Забезпечення застосовності продукту Розділ 2 51 № п/п Процес (підпроцес) 2.10 Оцінювання продукту 3. Категорія «Організаційні процеси» 3.1 Керування 3.1.1 Керування на рівні організації 3.1.2 Керування проектом 3.1.3 Керування якістю 3.1.4 Керування ризиком 3.1.5 Організаційне забезпечення 3.1.6 Вимірювання 3.1.7 Керування знаннями 3.2 Удосконалення 3.2.1 Упровадження процесів 3.2.2 Оцінювання процесів 3.2.3 Удосконалення процесів Стандарт не зобов'язує використовувати всі процеси ЖЦ одночасно і не ставить особливих вимог до формату і змісту розроблених документів. Тому організація-користувач стандарту під час розроблення конкретного програмного продукту може створити стандарти підприємства, методики і процедури, що деталізуватимуть вибрані для конкретних потреб процеси ЖЦ. Міжнародна організація зі стандартизації ISO (International Organization for Standardization) випускає також посібники і настанови, що доповнюють стандарт ISO/IEC 12207. Як видно з табл. 2.1, усі процеси в даному стандарті поділяються на три категорії: – основні процеси; – процеси підтримки; – організаційні процеси. Для кожного з процесів визначені види діяльності (дії – activity), задачі, сукупність результатів (виходів) діяльності і розв’язання задач, а також деякі специфічні вимоги. У стандарті наведено перелік робіт для основних, організаційних процесів і процесів підтримки, але не спосіб їх виконання і не форма подання результатів. В стандарті до основних процесів належать: – процес придбання, який ініціює ЖЦ ПС і визначає дії організації-покупця (або замовника), що отримує автоматизовану систему, програмний продукт або сервіс. Цей процес містить у собі такі види діяльності: ініціювання і підготовка запиту, оформлення контракту і його актуалізація; моніторинг користувачів, приймання і завершення; – процес постачання, який визначає дії з передачі покупцю програмного продукту або сервісу і містить у собі такі види діяльності: підготовку пропозицій (відповідей на запити); оформлення контракту; планування, виконання і контроль продукту, що постачається; аналіз і оцінку продукту; постачання і завершення робіт з постачання. Процес постачання починається тоді, коли встановлені договірні відношення між замовником і постачальником. Залежно від умов договору процес постачання може містити у собі процес розроблення ПЗ, процес експлуатації і супроводження для виправлення і поліпшення ПС; 52 Розділ 2 – процес розроблення, який визначає дії підприємства-розробника програмного продукту: аналіз вимог до системи; проектування архітектури системи, детальне проектування компонентів ПС, кодування і тестування ПС, інтеграцію системи, кваліфікаційне тестування, установку ПС і забезпечення приймання ПС (рис.2.1); Рис. 2.1. Схема основних процесів ЖЦ ПС – процес експлуатації, який визначає дії підприємства-оператора, що забезпечує обслуговування системи в ході її експлуатації користувачами (консультування користувачів, вивчення потреб операторів, задоволеності споживачів системою тощо). Цей процес регламентує задачі і дії з функціонального тестування, перевірки правильності експлуатації системи; дотримання інструкцій і настанов з її запуску; – процес супроводження, який визначає дії організації, що виконує супровід програмного продукту (керування модифікаціями, підтримку поточного стану і функціональної придатності, інсталяцію програмного продукту на обчислювальній системі користувача та її вилучення при списанні). Даний процес містить у собі завдання і дії щодо аналізу питань супроводження і модифікації, розробки планів і реалізації модифікації системи, аналізу результатів супроводження після змін системи, міграції ПС в інше середовище або її виведення з експлуатації. До категорії основних процесів належать також «первинні» процеси, що визначають порядок підготовки договору на розробку ПС, моніторинг діяльності постачальників ПС тощо (див. табл.2.1). Стандарт містить у собі опис допоміжних процесів, що регламентують додаткові дії з перевірки продукту, керування проектом та його якістю (рис.2.2). До процесів підтримки розроблення ПС належать: документування, керування версіями, верифікація і валідація, перегляди, аудити, оцінювання продукту та ін. Процес керування версіями за змістом відповідає керуванню конфігурацією системи, що так само, як і продукти процесів, повинні перевірятися на правильність реалізації цілей проекту і відповідність вимогам замовника. Завдання з перевірки рекомендується виконувати спеціальним контролерам, які знаються на методах і процесах проектування ПС. До організаційних процесів належать: керування проектом (менеджмент розробки), якістю, ризиками тощо. Розділ 2 53 Рис. 2.2. Схема допоміжних процесів ЖЦ ПС Ці процеси виконуються спеціальними службами, що здійснюють планування робіт у проекті, контроль процесів, визначення метрик для вимірювання продуктів, перевірку показників якості, дотримання стандартних положень та ін. Процеси, дії і задачі наведені в стандарті в найбільш загальній природній послідовності. Залежно від цілей конкретного проекту головний розробник і менеджер вибирають процеси, дії і задачі, вибудовують визначену схему ЖЦ для застосування в цьому проекті. Процеси керування в стандарті структуровані за рівнями і напрямами, вони жодним чином не зв’язані з існуючими методами і засобами програмної інженерії з розроблення ПС. Це дає можливість при їх виборі для застосування у ЖЦ зіставляти з ними звичні парадигми і методи розроблення (об'єктні, компонентні, сервісні й ін.) та засоби ядра знань SWEBOK. Таким чином, між стандартом ISO/IEC 12207 і ядром знань SWEBOK існує зв'язок: вони взаємодоповнюють та збагачують один одного, більше у розробці відповідних документів брали участь одні ті самі висококваліфіковані фахівці в галузі програмування й інформатики. Інженерна дисципліна проектування ПС використовує теоретичні, прикладні методи і засоби розробки ПС і стандарти (ISO/IEC 12207, ISO/IEC 15404, ISO/IEC 9126 та ін.), а також рекомендації і методики керування розробкою, до яких відносять методи оцінки на процесах ЖЦ, якості ПС, витрачених ресурсів і вартості виконаних робіт. При цьому ядро знань SWEBOK, а також численні монографії і статті рекомендують до застосування методи і засоби програмної інженерії, а стандарт дає настанови до побудови процесів на стандартизованій інженерній основі. Природно, що в невеликих програмних проектах завжди можна буде застосовувати творчі і неформальні підходи, запропоновані фахівцями для створення різного роду унікальних продуктів, процес розроблення яких не завжди відповідає загальному стандарту. 2.2. Формування прикладних моделей життєвого циклу Кожна ПС протягом свого існування проходить визначену послідовність процесів (процесів), починаючи від постановки задачі до її втілення в готову 54 Розділ 2 програму, наступної експлуатації і остаточного виведення з експлуатації та списання. Така послідовність процесів називається життєвим циклом розробки ПС. На кожному процесі ЖЦ виконується визначена сукупність процесів і/або підпроцесів, кожний з яких породжує відповідний проміжний продукт, використовуючи при цьому результати попереднього процесу і доробок. Модель життєвого циклу – це схема виконання робіт і задач у рамках процесів, що забезпечують розробку, експлуатацію і супровід програмного продукту. Ця схема відображає еволюцію ПС, починаючи від формулювання вимог і закінчуючи припиненням користування нею [1– 6]. Історично така схема робіт містить у собі: – розробку вимог або технічного завдання; – розробку ескізного або технічного проекту; – програмування або робоче проектування; – пробну експлуатацію; – супровід і поліпшення; – зняття з експлуатації. Основне призначення моделей ЖЦ є таким: – планування і розподіл робіт і ресурсів між розробниками, а також керування програмним проектом; – забезпечення взаємодії між розробниками проекту і замовником; – спостереження і контроль робіт, оцінка проміжних продуктів ЖЦ на дотримання специфікацій вимог, правильне їх виконання, оцінка продукту і реальних витрат, у тому числі і щодо застосовуваних програмних засобів і інструментів; – узгодження проміжних результатів із замовником; – перевірка правильності кінцевого продукту шляхом його тестування на запланованих і погоджених із замовником наборах тестів; – оцінка відповідності характеристик якості отриманого продукту заданим вимогам; – обговорення використовуваних процесів ЖЦ з метою оцінки їх потенційних можливостей і недоліків, що виявлялися при їх застосуванні, а також визначення напрямів удосконалення або модернізації ЖЦ. Отже, для побудови конкретної моделі ЖЦ ПС, що задовольняє концептуальній ідеї проектованої системи з урахуванням її складності і масштабу робіт, необхідно зробити правильний вибір процесів, їх завдань і дій відповідно до стандарту. На сьогодні основою формування нової моделі ЖЦ для конкретної прикладної системи є стандарт ISO/IEC 12207, що задає повний набір процесів (більш 40), охоплює всі можливі види робіт і завдань, пов'язаних з побудовою ПС, починаючи з аналізу предметної області і закінчуючи виготовленням відповідного продукту. Стандарт ISO/IEC 12207 надає загальний опис процесів на найвищому рівні, проте він не покликаний деталізувати виконання дій або задач, з яких складаються процеси. Він також не ставить вимоги до формату і змісту документів, що випускаються на різних процесах. Процеси, дії і задачі наведені в стандарті в найбільш загальній природній послідовності, але це не означає, що в такій самій послідовності вони повинні бути застосовані в конкретній моделі ЖЦ ПС. Залежно від проекту процеси, дії і задачі стандарту вибираються, упорядковуються і включаються в модель ЖЦ. При Розділ 2 55 застосуванні вони можуть перекривати, переривати один одного, виконуватися ітераційне або рекурсивно. Це визначає «динамічний» характер стандарту і дозволяє реалізувати з його допомогою довільну модель ЖЦ ПС. Тому організаціям, що будуть застосовувати стандарт у своїй роботі, знадобляться додаткові внутрішні стандарти або процедури, які визначатимуть різні деталі застосування вибраних елементів ЖЦ залежно від типу ПС. Крім цього, існують міжнародні стандарти з керування конфігурацією ПЗ, супроводу, документування, оцінювання якості, верифікації і валідації, тестування тощо. Зі стандарту ISO/IEC 12207 можна вибирати тільки ті процеси, що найбільше підходять для реалізації конкретної ПС. Обов'язковими є основні процеси, що є у всіх відомих моделях ЖЦ. Залежно від цілей і задач предметної області вони можуть бути поповнені процесами з категорії організаційних процесів даного стандарту. Розробник приймає рішення щодо необхідності вміщення в нову модель ЖЦ засобів забезпечення якості компонентів, системи керування проектом або визначення набору процедур перевірки для забезпечення правильності продукту і відповідності його заданим вимогам. Процеси, що включені в модель ЖЦ, призначені для реалізації стандартних задач процесів ЖЦ, вони можуть залучати інші процеси, що пов'язані із забезпеченням захисту даних. Інтерфейси (входи і виходи) будь-яких двох процесів ЖЦ повинні бути мінімальними і кожний з них повинен відповідати таким правилам: – якщо процес А викликається процесом В і тільки процесом В, то А належить В; – якщо функція викликається більше ніж одним процесом, то вона стає окремим процесом; – перевірка будь-якої функції в ЖЦ є обов'язковою. Іншими словами, якщо вирішення певної задачі потребує більше ніж один процес, то вона може сама набути статусу процесу, що використовується одно- або багаторазово протягом ЖЦ конкретної системи. Кожен процес повинен мати внутрішню структуру, встановлену відповідно до особливостей його виконання. Процеси конкретної моделі ЖЦ орієнтовані безпосередньо на розробника даної системи. Розробник може виконувати один або кілька процесів і процес, у свою чергу, може бути виконаний одним або кількома розробниками. При цьому один з розробників має відповідати за один процес або за всі процеси моделі, навіть якщо окремі роботи виконує інший розробник. Створювана модель ЖЦ узгоджується з конкретними методиками розробки систем і відповідними стандартами в області програмної інженерії, які існують або розробляються самостійно для проекту з урахуванням можливостей і особливостей ПС. Іншими словами, кожен процес ЖЦ підкріплюється вибраними для реалізації ПС засобами і методами програмування, а також методикою їх застосування і виконання. При формуванні моделі ЖЦ важливу роль відіграють організаційні аспекти: – структура колективу і зв’язків між ними; – планування послідовності робіт і термінів їх виконання; – підбір і підготовка ресурсів (людських, програмних і технічних) для виконання робіт; – оцінка можливостей реалізації проекту в заданий термін, вартість і ресурси. |