К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Приклад. ЖЦ розробки ПС із задачами і діями процесу тестування. Головне призначення процесу тестування ЖЦ – виконання задач процесу на основі входів (вхідні дані для виконання задач процесу) і виходів при завершенні задач, а також ролей і дій виконавців цих задач. Відповідно до стандарту ISO/IEC 12207 задачі тестування розглянуті і розподілені за процесами ЖЦ ПС. Як результат, отримано єдиний безперервний процес тестування різних продуктів ПС, задачами якого є підготовка, проведення й оцінювання результатів тестування. Ці задачі розподілилися між 20 діями (кроками) процесу розроблення [7, 8]. Даний підхід до поглибленого тестування ПС доцільно застосовувати, наприклад, для систем реального часу. На кроці підготовки здійснюється аналіз робочих продуктів процесу розроблення ПС (вхідних для даного кроку процесу тестування) для визначення цілей, об'єктів, сценаріїв і ресурсів тестування, адекватних кроку тестування. Результати виконання кроків підготовки тестування повинні фіксуватися в планах тестування (рис. 2.3). Рис. 2.3. ЖЦ з конкретними задачами на підпроцесах тестування ПС На кроці виконання здійснюється фіксація результатів виконання тестів, їх порівняння з очікуваними результатами, визначення поточного стану робочого продукту ПС і прийняття рішення про достатність тестування. Кожен крок процесу розроблення складається з набору розв'язуваних задач, їх розподілу за процесами і підпроцесами ЖЦ. Кроки процесу й окремих задач можуть виконуватися циклічно для різних об'єктів ПС при їх тестуванні. Розділ 2 57 Опис семантики задач і кроків процесу тестування наведено в табл. 2.2. Таблиця 2.2. Зміст задач процесу тестування Крок процесу Задачі процесу тестування 1.1. Визначення учасників процесу тестування 1. Створення групи тестування Розподіл обов'язків у групі і формування плану тестування 2.1. Ідентифікація ризиків 2.2. Упорядкування ризиків 2. Аналіз ризику 2.3. Розподіл ресурсів 3.1. Ідентифікація цілей тестування 3.2. Визначення критеріїв проходження тестів 3. Визначення цілей тестування 3.3. Упорядкування цілей тестування за оцінками ризику 4.1. Розроблення плану тестування ПС 4.2. Розроблення плану інтеграційного тестування 4.3. Розроблення плану автономного тестування 4. Розроблення планів тестування 4.4. Розроблення плану комплексного тестування 5.1. Проектування і розроблення тестів 5.2. Підготовка тестових даних 5. Розроблення тестів 5.3. Перевірка тестових документів 6.1. Автономне тестування модулів і аналіз результатів 6.2. Інтеграційне тестування 6.3. Повторне тестування після усунення дефектів 6. Автономне й інтеграційне тестування 6.4. Аналіз результатів інтеграційного тестування 7.1. Затвердження середовища і ресурсів тестування 7.2. Тестування ПС 7.3. Повторне тестування ПС після усунення дефектів 7.4. Аналіз результатів завершення тестування ПС 7. Тестування ПС 7.5. Тестування інсталяції ПС 8.1. Збирання і аналіз даних про результати тестування 8.2. Підготовка розв’язків і рекомендацій з використання ПС 8.3. Підготовка кінцевого документа про результати тестування 8. Складання документа за тестуванням ПС і підготовка звіту 8.4. Перевірка рішень і підготовка документа звіту Для підключення задач тестування до всіх процесів ЖЦ проводиться: – розподіл обов'язків між учасниками процесу з урахуванням вимог щодо їх професійної підготовки; – визначення стандартів на подання остаточних документів, метрик процесу, критеріїв початку і завершення задач і переходу до наступного кроку процесу; – підбір методів тестування для вибраного класу ПС і перевірки правильності виконання задач тестування; – розроблення спеціальних шаблонів для документування процесу тестування щодо кожного його кроку. При завершенні тестування ПС з метою визначення часу тестування та вартості робіт враховуються результати і дані процесу розроблення, а також оформляється звітний документ на виготовлення ПС. Оцінювання ризику відмов проводиться на процесі підготовки тестування і на кроках аналізу, а оцінювання якості виконується після завершення тестування. 58 Розділ 2 2.3. Типи моделей життєвого циклу Розглянуті підходи щодо побудови різних видів моделей ЖЦ базуються на процесному підході до виконання програмних проектів. Вони використовувалися на практиці під час створення різних типів моделей ЖЦ, до яких належать такі моделі: каскадна, спіральна, інкрементна, еволюційна та ін. 2.3.1. Каскадна модель Однією з перших почала застосовуватися каскадна модель, де кожна робота виконується один раз і в такому порядку, який подано на рис.2.4. Рис. 2.4. Каскадна модель ЖЦ програмних систем Тобто вважається, що кожна робота має бути виконана настільки ретельно, що після її закінчення і переходу до наступного етапу, повертатися до попереднього не буде потреби. Розробник перевіряє проміжний результат відомими методами верифікації і фіксує його як готовий еталон для наступного процесу. Згідно з даною моделлю роботи і завдання процесу розроблення зазвичай виконуються послідовно, як це наведено у схемі. Проте допоміжні і організаційні процеси (контроль вимог, керування якістю і ін.), як правило, виконуються разом з процесами розробки ПЗ. У даній моделі повернення до початкового процесу передбачається після супроводження і виправлення помилок. Особливість такої моделі полягає у фіксації послідовних процесів розроблення програмного продукту. В її основу покладена модель фабрики, де продукт проходить стадії від задуму до виробництва, потім його передають замовнику у вигляді готового виробу, де заміна не передбачена, хоча можна подати інший подібний виріб. Недоліки цієї моделі такі: – процес створення ПС не завжди вкладається в таку жорстку форму і послідовність дій; – не враховуються змінювані потреби користувачів, нестабільні умови зовнішнього середовища, які впливають на зміни вимог до ПС під час ї розроблення; – значний розрив між часом внесення помилки (наприклад, на процесі проектування) і часом її виявлення (при супроводі), що призводить до суттєвої переробки ПС. Розділ 2 59 При застосуванні каскадної моделі можуть спостерігатися такі чинники ризику: – вимоги до ПС недостатньо чітко сформульовані, або не враховують перспективи розвитку ОС, середовищ і т.п.; – громіздка система, що не допускає компонентної декомпозиції, може викликати проблеми щодо розміщення її в пам'яті або на платформах, не передбачених у вимогах; – внесення швидких змін до технології і у вимоги може погіршити процес розроблення окремих частин системи або системи в цілому; – обмеження на ресурси (людські, програмні, технічні і ін.) в ході розробки можуть звузити окремі можливості реалізації системи; – отриманий продукт може виявитися не придатним для застосування внаслідок нерозуміння розробниками вимог або функцій системи або недостатньо проведеного тестування. Переваги реалізації системи за допомогою каскадної моделі такі: – всі завдання підсистем і системи реалізуються одночасно, завдяки чому не можна забути жодного завдання, а це сприяє встановленню стабільних зв'язків між ними; – повністю розроблену систему з документацією на неї легше супроводжувати, тестувати, фіксувати помилки і вносити зміни не хаотично, а цілеспрямовано, починаючи з вимог, наприклад, додавати або замінювати деякі функції і повторювати процес. Каскадну модель можна розглядати як модель ЖЦ, придатну для створення першої версії ПЗ з метою перевірки реалізованих в ній функцій. При супроводі і експлуатації можуть бути виявлені різного роду помилки, виправлення яких спричинить повторне виконання всіх процесів, починаючи з уточнення вимог. 2.3.2. Інкрементна модель Цю модель (incremental) ще називають моделлю з нарощуванням або з приростом. Її суть полягає в розробці продукту ітераціями, і кожна ітерація закінчується випуском працездатної версії. У кожній новій версії додаються деякі функціональні можливості. Розробка системи починається з визначення набору всіх вимог до ПС і ділення процесу розроблення на ітерації. Кожна ітерація реалізується послідовно з використанням процесів ЖЦ і фіксації робочої версії системи, системи, що поступово наближається до остаточної версії (рис. 2.5). Рис. 2.5. Інкрементна модель ЖЦ 60 Розділ 2 Перша проміжна версія системи, що створюється (випуск 1), реалізує частину вимог, у подальшу версію (випуск 2) додають додаткові вимоги до тих пір, поки не будуть остаточно виконані всі вимоги і розв’язані задачі розробки системи. Для кожної проміжної версії на процесах ЖЦ виконуються необхідні процеси, роботи і завдання, зокрема, аналіз вимог і створення нової архітектури, які можуть бути виконані одночасно. Процеси розроблення технічного проекту програмної системи, її програмування і тестування, збирання і кваліфікаційні випробування ПС виконуються при створенні кожної подальшої версії. Відповідно до даної моделі ЖЦ, процеси якої практично такі самі, як і в каскадній моделі, наголос робиться на побудову деякої закінченої проміжної версії, а завдання процесу розроблення виконуються послідовно або частково паралельно для ряду окремих проміжних структур версії. Роботи і завдання процесу розроблення наступної версії системи з додатковими вимогами або функціями можуть виконуватися неодноразово в одній тій же послідовності для всіх проміжних версій системи. Процеси супроводження і експлуатації можуть бути реалізовані разом з процесом розроблення версії шляхом перевірки частково реалізованих вимог в кожній проміжній версії і так до отримання кінцевого варіанта системи. Допоміжні і організаційні процеси ЖЦ зазвичай виконуються разом з процесом розроблення версії системи і до кінця розробки збираються дані, на підставі яких можна встановити рівень завершеності і якості виготовленої системи. При застосуванні даної моделі необхідно враховувати такі чинники ризику: – вимоги складені з урахуванням можливості їх зміни при реалізації продукту; – всі можливості системи потрібно реалізувати одразу; – швидка зміна технології і вимог до системи може призвести до порушення отриманої структури системи; – обмеження в ресурсному забезпеченні (виконавці, фінанси) можуть призвести до несвоєчасного введення системи в експлуатацію. Дану модель ЖЦ доцільно використовувати, у випадках, коли: – бажано реалізувати деякі можливості системи швидко за рахунок створення проміжної версії продукту; – система декомпозується на окремі складові частини, які можна реалізовувати як деякі самостійні проміжні або готові продукти; – можливе збільшення фінансування на розробку окремих частин системи. 2.3.3. Спіральна модель Виходячи з можливості внесення змін, як в процес, так і в проміжний продукт було створено спіральну модель ЖЦ (рис.2.6) [6]. Внесення змін орієнтоване на задоволення потреби користувачів одразу, як тільки буде встановлено, що створені артефакти або елементи документації не відповідають дійсному стану розробки. Дана модель ЖЦ допускає аналіз продукту на витку розробки, його перевірку, оцінку правильності та прийняття рішення про перехід на наступний виток або повернення на попередній виток для доопрацювання на ньому проміжного продукту. Розділ 2 61 Відмінність цієї моделі від каскадної полягає в можливості багато разів повертатися до процесу формулювання вимог і до повторної розробки версії системи з будь-якого процесу моделі. Рис.2.6. Спіральна модель ЖЦ розробки програмних систем Для програмного продукту така модель не дуже підходить з декількох причин. По-перше, висловлення вимог замовником носить суб'єктивний характер, вимоги можуть багаторазово уточнюватися протягом розробки ПС i навіть після завершення та випробовування, і часом може з'ясуватися, що замовник « хотів зовсім інше » . По-друге, змінюються обставини та умови використання системи, тому загальновизнаним законом програмної інженерії є закон еволюції, який сформулюємо так: кожна діюча ПС з часом потребує внесення змін або виводиться з експлуатації. При необхідності внесення змін до системи на кожному витку з метою отримання нової версії системи обов'язково вносяться зміни в заздалегідь зафіксовані вимоги, після чого повертаються на попередній виток спіралі для продовження реалізації нової версії системи з урахуванням усіх змін. 62 Розділ 2 2.3.4. Еволюційна модель У разі еволюційної моделі система послідовно розробляється з блоків конструкцій. На відміну від інкрементної моделі в еволюційній моделі вимоги встановлюються частково і уточнюються в кожному наступному проміжному блоці структури системи. Використання еволюційної моделі припускає проведення дослідження предметної області для вивчення потреб її замовника і аналізу можливості застосування цієї моделі для реалізації. Модель використовується для розробки нескладних і некритичних систем, де головною вимогою є реалізація функцій системи. При цьому вимоги не можуть бути визначені відразу і повністю. Тому розробка системи здійснюється ітераційним шляхом її еволюційного розвитку з отриманням деякого варіанта системи–прототипу, на якому перевіряється реалізація вимог. Іншими словами, такий процес за своєю суттю є ітераційним, з етапами розробки, що повторюються, починаючи від змінених вимог і закінчуючи отриманням готового продукту. В деякому розумінні до цього типу моделі можна віднести спіральну модель. Розвитком цієї моделі є модель еволюційного прототипування в рамках усього ЖЦ розробки ПС (рис.2.7). Рис.2.7. Модель еволюційного прототипування У літературі вона часто називається моделлю швидкої розробки програм RAD (Rapid Application Development). У даній моделі наведені дії, які пов'язані з аналізом її застосовності для конкретного виду системи, а також обстеженням замовника для визначення потреб користувача при розробці плану створення прототипу. У моделі є дві головні ітерації розробки функціонального прототипу, проектування і реалізації системи з метою перевірки, чи задовольняє вона всі функціональні і нефункціональні вимоги. Основною ідеєю цієї моделі є моделювання окремих функцій системи в прототипі і поступове еволюційне його доопрацювання до виконання всіх заданих функціональних вимог. Розділ 2 63 Ітерацій з отримання проміжних варіантів прототипу може бути декілька, в кожній з яких додається функція і повторно моделюється робота прототипу. І так до тих пір, поки не будуть промодельовані всі функції, задані у вимогах до системи. Після цього виконується ще одна ітерація – остаточне програмування для отримання готової системи. Ця модель застосовується для систем, в яких найбільш важливими є функціональні можливості, і які необхідно швидко продемонструвати на CASE- засобах. Оскільки проміжні прототипи системи відповідають реалізації деяких функціональних вимог, їх можна перевіряти і під час супроводу і експлуатації, тобто разом з процесом розробки чергових прототипів системи. При цьому допоміжні і організаційні процеси можуть виконуватися разом з процесом розроблення і накопичувати відомості за даними кількісних і якісних оцінок на процесах розроблення. При цьому враховуються такі чинники ризику: – реалізація всіх функцій системи одночасно може призвести до громіздкості; – обмежені людські ресурси зайняті розробкою протягом тривалого часу. Переваги застосування даної моделі ЖЦ такі: – швидка реалізація деяких функціональних можливостей системи і їх апробація; – використання проміжного продукту в наступному прототипі; – виділення окремих функціональних частин для реалізації їх у вигляді прототипу; – можливість збільшення фінансування системи; – зворотний зв'язок із замовником для уточнення функціональних вимог; – спрощення внесення змін у зв'язку із заміною окремих функції. Модель розвивається у напряму додавання нефункціональних вимог до системи, пов'язаних із захистом і безпекою даних, несанкціонованим доступом до них і ін. Висновки. Розглянуто стандарти ЖЦ, основоположні моделі ЖЦ і запропоновано шлях створення нової моделі ЖЦ, прийнятної для певної предметної області, використовуючи стандарт ISO/IEC 12207, який містить у собі описи процесів проектування, тестування, керування проектом, ризиками, якістю тощо. Контрольні питання і завдання 1. Назвіть три основні групи процесів життєвого циклу. 2. Назвіть організаційні процеси ЖЦ і перерахуйте їх. 3. Охарактеризуйте процес керування якістю ЖЦ. 4. Який стандарт визначає перелік і зміст процесів ЖЦ ПЗ? 5. Чи всі процеси стандарту повинні бути застосовані в розробці ПЗ? 6. Охарактеризуйте суть моделі ЖЦ і основні види моделей. 7. Опишіть каскадну і спіральну моделі ЖЦ. 8. Охарактеризуйте еволюційну модель ЖЦ. 9. Назвіть інші види моделей ЖЦ. 64 Розділ 2 Список літератури до розділу 2 1. ISO/IEC 12207: 1995–0801: Informational Technology – Software life cycle processes. // ГОСТ Р ИСО/МЭК 12207–99. Информационная технология. Процессы жизненного цикла программных средств. 2. Лаврищева Е.М., Грищенко В.Н. Области знаний программной инженерии – SWEBOK и подход к обучению этой дисциплины// Управляющие системы и машины.–2005. – №1.– С.38–54. 3. Васютович В., Самотохин С., Никифоров Г. Регламентация жизненного цикла программных средств // ifrsmov@gost.ru 4. Вендеров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2000. – 347 с. 5. Орлов С.А. Технологии разработки программного обеспечения. – Спб.: Питер, 2002. – 463 с. 6. Соммервил И. Инженерия программного обеспечения. 6-е издание. – М.– Спб.–Киев,– 2002. –623 с. 7. Лаврищева Е.М., Коротун Т.М. Построение процесса тестирования программных систем // Проблемы программирования. – 2002. – № 1–2. – С. 272–281. 8. Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем. – Киев: Академпериодика, 2007.– 680 с. |