Модульну контрольну роботу No2 з дисципліни
“Технологія створення програмних продуктів”
Варіант No4
Виконала студентка УС-401бз
Ільїнська Валерія Анатоліївна
Перевирів: Райчев Ігор Едуардович
Життєвий цикл програмного забезпечення
Життєвий цикл програмного забезпечення - період часу, який починається з моменту прийняття рішення про необхідність створення програмного продукту і закінчується в момент його повного вилучення з експлуатації. (Стандарт IEEE Std 610.12)
Необхідність визначення етапів життєвого циклу (ЖЦ) ПО обумовлена \u200b\u200bпрагненням розробників до підвищення якості ПЗ за рахунок оптимального управління розробкою та використання різноманітних механізмів контролю якості на кожному етапі, починаючи від постановки задачі і закінчуючи авторським супроводом ПЗ. Найбільш загальним уявленням життєвого циклу ПО є модель у вигляді базових етапів - процесів, до яких відносяться:
Системний аналіз і обгрунтування вимог до ПЗ;
Попереднє (ескізне) і детальне (технічне) проектування ПО;
Розробка програмних компонент, їх комплексування і налагодження ПО в цілому;
Випробування, дослідна експлуатація та тиражування ПО;
Регулярна експлуатація ПО, підтримка експлуатації та аналіз результатів;
Супровід ПО, його модифікація і вдосконалення, створення нових версій.
Дана модель є загальноприйнятою і відповідає як вітчизняним нормативним документам в області розробки програмного забезпечення, так і закордонним. З точки зору забезпечення технологічної безпеки доцільно розглянути більш детально особливості подання етапів ЖЦ в зарубіжних моделях, так як саме зарубіжні програмні засоби є найбільш вірогідним носієм програмних дефектів диверсійного типу.
Стандарти життєвого циклу ПО
ГОСТ 34.601-90
ISO / IEC 12207: 1995 (російський аналог - ГОСТ Р ISO / IEC 12207-99)
Графічне представлення моделей ЖЦ дозволяє наочно виділити їх особливості і деякі властивості процесів.
Спочатку була створена каскадна модель ЖЦ, в якій великі етапи починалися один за одним з використанням результатів попередніх робіт. Вона передбачає послідовне виконання всіх етапів проекту в строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, визначені на стадії формування вимог, строго документуються у вигляді технічного завдання і фіксуються на весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників. Неточність будь-якого вимоги або некоректна його інтерпретація в результаті призводить до того, що доводиться «відкочуватися» до ранньої фазі проекту і необхідна переробка не просто вибиває проектну команду з графіка, але призводить часто до якісного зростання витрат і, не виключено, до припинення проекту в тій формі, в якій він спочатку замислювався. Основна помилка авторів Водоспадної моделі полягає в припущеннях, що проект проходить через весь процес один раз, спроектована архітектура хороша і проста у використанні, проект здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені в реалізації, а тому їх усунення відбувається рівномірно під час тестування компонентів і системи. Таким чином, водоспадна модель для великих проектів мало реалістична і може бути ефективно використана тільки для створення невеликих систем.
Найбільш специфічною є спиралевидная модель ЖЦ. У цій моделі увага концентрується на ітераційне процесі початкових етапів проектування. На цих етапах послідовно створюються концепції, специфікації вимог, попередній і детальний проект. На кожному витку уточнюється зміст робіт і концентрується вигляд створюваного ПО, оцінюється якість отриманих результатів та плануються роботи наступної ітерації. На кожній ітерації оцінюються:
Ризик перевищення термінів і вартості проекту;
Необхідність виконання ще однієї ітерації;
Ступінь повноти і точності розуміння вимог до системи;
Доцільність припинення проекту.
Стандартизація ЖЦ ПО проводиться за трьома напрямками. Перший напрямок організовується і стимулюється Міжнародною організацією зі стандартизації (ISO - International Standard Organization) і Міжнародною комісією з електротехніки (IEC - International Electro-technical Commission). На цьому рівні здійснюється стандартизація найбільш загальних технологічних процесів, що мають значення для міжнародної кооперації. Другий напрямок активно розвивається в США Інститутом інженерів електротехніки та радіоелектроніки (IEEE - Institute of Electrotechnical and Electronics Engineers) спільно з Американським національним інститутом стандартизації (American Na-tional Standards Institute-ANSI). Стандарти ISO / IEC і ANSI / IEEE в основному мають рекомендаційний характер. Третій напрям стимулюється Міністерством оборони США (Department of Defense-DOD). Стандарти DOD мають обов'язковий характер для фірм, що працюють на замовлення Міністерства оборони США.
Для проектування ПО складної системи, особливо системи реального часу, доцільно використовувати загальносистемну модель ЖЦ, засновану на об'єднанні всіх відомих робіт в рамках розглянутих базових процесів. Ця модель призначена для використання при плануванні, складанні робочих графіків, управлінні різними програмними проектами.
Сукупність етапів даної моделі ЖЦ доцільно ділити на дві частини, що істотно розрізняються особливостями процесів, техніко-економічними характеристиками і впливають на них чинниками.
У першій частині ЖЦ проводиться системний аналіз, проектування, розробка, тестування і випробування ПО. Номенклатура робіт, їх трудомісткість, тривалість і інші характеристики на цих етапах істотно залежать від об'єкта і середовища розробки. Вивчення подібних залежностей для різних класів ПО дозволяє прогнозувати склад і основні характеристики графіків робіт для нових версій програмного забезпечення.
Друга частина ЖЦ, що відображає підтримку експлуатації та супроводу ПО, відносно слабко пов'язана з характеристиками об'єкта і середовища розробки. Номенклатура робіт на цих етапах стабільніша, а їх трудомісткість і тривалість можуть істотно змінюватися, і залежать від масовості застосування ПЗ. Для будь-якої моделі ЖЦ забезпечення високої якості програмних комплексів можливо лише при використанні регламентованого технологічного процесу на кожному з цих етапів. Такий процес підтримується засобами автоматизації розробки, які доцільно вибирати з наявних або створювати з урахуванням об'єкта розробки та адекватного йому переліку робіт.
Життєвий цикл програмного забезпечення (ПО) - період часу, який починається з моменту прийняття рішення про необхідність створення програмного продукту і закінчується в момент його повного вилучення з експлуатації. Цей цикл - процес побудови і розвитку ПЗ.
Етапи життєвого циклу:
2. Проектування
3. Реалізація
4. Складання, тестування, випробування
5. Впровадження (випуск)
6. Супровід
Розрізняють 2 випадки виробництва ПО: 1) ПО робиться для конкретного замовника. В цьому випадку потрібно прикладну задачу преврашается в програмістську. Потрібно зрозуміти як функціонує те середовище, яку потрібно автоматизувати (аналіз бізнес-процесів). В результаті з'являється документація-специфікація вимоги, де вказані які саме завдання д.б.н. вирішені і за яких умов. Цю роботу виконує системний аналітик (аналітик бізнес-процесів).
2) ПО розробляється для ринку. Потрібно проводити маркетингові дослідження і знайти якогось продукту на ринку немає. Це пов'язано з великим ризиком. Мета - розробка специфікації вимог.
проектування
Мета - визначення загальної структури (архітектури) ПО. Результат - специфікація ПЗ. Цю роботу виконує системний програміст.
Реалізація
Написання програмного коду. Реалізація включає і розробку, і тестування, і документацію.
Збірка, тестування, іспитніе
Збірка всього, що зроблено різними програмістами. Тестування за все програмного комплексу. Налагодження - пошук і усунення причин помилок. Випробування - уточнення технічних характеристик. В результаті - гарантія работоспособносіт програми.
Впровадження (випуск)
Впровадження - коли працюють на одного замовника. Включає постановку програми у замовника, навчання замовника, консультації, усунення помилок і явних недоліків. Повинно відбутися відчуження ПО - користувач може працювати з ПО без участі автора.
Випуск - коли ПО розробляється на ринок. Починається з етапу бета-тестування. Соотв. версія - бета-версіяю. Альфа-тестування - тестування людьми з тієї ж організації, які не брали участі в розробці програм. Бета-тестування - виготовлення декількох екземплярів ПЗ і відправка потенційним замовникам. Мета - ще раз перевірити розробку ПО.
Якщо на ринок випускається принципово новий ПО, то можливо кілька бета-тестувань. Після бета-тестування - випуск комерційної версії.
супровід
Усунення виявлених в ході експлуатації помилок. Внесення непринципових удосконалень. Накопичення пропозицій для розробки наступної версії.
Моделі життєвого циклу
1. Waterfall ( «водоспад», каскадна модель)
2. Прототипування
Спочатку розробляється не сам програмний продукт, а його прототип, що містить рішення головних проблем, що стоять перед розробниками. Після успішного завершення розробки прототипу за тими ж принципами розробляється і справжній програмний продукт. Прототип дозволяє краще розуміти вимоги до розроблюваної програми. Використовуючи прототип замовник також може точніше сформулювати свої вимоги. Розробник має можливість за допомогою прототипу пред'явити замовнику попередні результати своєї роботи.
3. Ітераційна модель
Завдання поділяється на підзадачі і визначається черговість їх реалізації таким чином, щоб кожна наступна підзадачі розширювала можливості ПО. Успіх істотно залежить від того наскільки вдало розділені завдання на підзадачі і як обрана черговість. Переваги: \u200b\u200b1) можливість активної участі замовника в розробці, він має можливість уточнити свої вимоги в ході розробки; 2) можливість тестування розроблених нових частин спільно з раніше розробленими, це зменшить витрати на комплексне налагодження; 3) під час розробки можна починати впровадження по частинах.
з електротехніки). Цей стандарт визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПС.
В даному стандарті ПС (або програмний продукт) Визначається як набір комп'ютерних програм, процедур і, можливо, пов'язаної з ними документації і даних. Процес визначається як сукупність взаємопов'язаних дій, що перетворюють деякі вхідні дані у вихідні (Г. Майерс називає це трансляцією даних). Кожен процес характеризується певними завданнями і методами їх вирішення. У свою чергу, кожен процес розділений на набір дій, а кожна дія - на набір завдань. Кожен процес, дія або завдання ініціюється і виконується іншим процесом в міру необхідності, причому не існує заздалегідь визначених послідовностей виконання (природно, при збереженні зв'язків за вхідними даними).
Слід зазначити, що в Радянському Союзі, а потім в Росії створення програмного забезпечення (ПО) спочатку, в 70-і роки минулого століття, регламентувалося стандартами ГОСТ ЕСПД (Єдиної системи програмної документації - серії ГОСТ 19.ХХХ), які були орієнтовані на клас щодо простих програм невеликого обсягу, створюваних окремими програмістами. В даний час ці стандарти застаріли концептуально і за формою, їх терміни дії закінчилися і використання недоцільне.
Процеси створення автоматизованих систем (АС), до складу яких входить і ПО, регламентовані стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартів на автоматизовані системи. Стадії створення", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи "і ГОСТ 34.603-92" Информационная технология. Види випробувань автоматизованих систем ". Однак багато положень цих стандартів застаріли, а інші відображені недостатньо, щоб їх можна було застосовувати для серйозних проектів створення ПС. Тому у вітчизняних розробках доцільно використовувати сучасні міжнародні стандарти.
Відповідно до стандарту ISO / IEC 12207 всі процеси ЖЦ ПО розділені на три групи (рис.5.1).
Мал. 5.1.
У групах визначено п'ять основних процесів: придбання, постачання, розробка, експлуатація та супровід. Вісім допоміжних процесів забезпечують виконання основних процесів, а саме документування, управління конфігурацією, Забезпечення якості, верифікація, атестація, спільна оцінка, аудит, дозвіл проблем. Чотири організаційних процесу забезпечують управління, створення інфраструктури, удосконалення та навчання.
Одним з базових понять технології програмування є поняття життєвого циклу програмного продукту (ЖЦ ПП).
Життєвий цикл програмного продукту (ПП) визначається як сукупність послідовних станів програмного продукту і всіх дій по його перетворенню, починаючи з аналізу існуючої потреби в автоматизації певних функцій обробки даних до їх програмної реалізації і включення в програмне забезпечення (ПО) конкретного застосування.
Моделлю життєвого циклу програмної системи називають структуру, визначальну послідовність здійснення процесів, дій і завдань, що виконуються протягом ЖЦ ПП, а також взаємодія між цими процесами, діями та завданнями.
Модель ЖЦ ПП визначає перелік етапів перетворення: програма -> програмний засіб -> програмний продукт, порядок виконання етапів, а також критерії переходу від етапу до етапу.
Традиційна модель ЖЦ ПО будується за каскадним принципом, суть якого в тому, що перехід на наступний етап відбувається після закінчення попереднього. Якщо по осі ординат відкласти етапи ЖЦ, а по осі абсцис - час, то каскадну модель ЖЦ можна проілюструвати малюнком.
Ця модель має ряд позитивних якостей, завдяки яким вона добре себе зарекомендувала і отримала широке поширення:
- На кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості. На заключних етапах розробляється призначена для користувача документація, що охоплює всі передбачені стандартами види забезпечення інформаційної системи: організаційне, методичне, інформаційне, програмне, технічне;
V-модель (v-model)
V-модель – це покращена версія класичної каскадної моделі. Тут на кожному етапі відбувається контроль поточного процесу, для того, щоб переконатися в можливості переходу на наступний рівень. У цій моделі тестування починається ще зі стадії написання вимог, причому для кожного наступного етапу передбачений свій рівень тестового покриття.
Для кожного рівня тестування розробляється окремий тест-план, тобто під час тестування поточного рівня, ми також займаємося розробкою стратегії тестування наступного. Створюючи тест-плани, ми також визначаємо очікувані результати тестування і вказуємо критерії входу і виходу для кожного етапу.
У V-моделі кожному етапу проектування і розробки системи відповідає окремий рівень тестування. Тут процес розробки представлений низхідною послідовністю в лівій частині умовної літери V, а стадії тестування – на її правому ребрі. Відповідність етапів розробки і тестування показано горизонтальними лініями.
Плюси і мінуси V-моделі:
+ Строга етапність;
+ Планування тестування і верифікація системи виробляються на ранніх етапах;
+ Покращений, в порівнянні з каскадної моделлю, тайм-менеджмент;
+ Проміжне тестування.
– Недостатня гнучкість моделі;
– Власне створення програми відбувається на етапі написання коду, тобто вже в середині процесу розробки;
– Недостатній аналіз ризиків;
– Немає роботи з паралельними подіями і можливості динамічного внесення змін.
Коли використовувати V-модель:
– У проектах, в яких існують часові та фінансові обмеження;
– Для завдань, які передбачають більш широке, порівняно з каскадної моделлю, тестове покриття.
Тестування на різних рівнях проводиться протягом усього життєвого циклу розробки і супроводу ПЗ. Рівень тестування визначає те, над чим виробляються тести: над окремим модулем, групою модулів або системою в цілому. Проведення тестування на всіх рівнях системи – це запорука успішної реалізації та здачі проекту.
Рівні тестування (Testing levels):
Компонентне або Модульне тестування (Component testing or Unit testing)
Інтеграційне тестування (Integration testing)
Системне тестування (System testing)
Приймальне тестування (Acceptance testing)
Компонентне тестування перевіряє функціональність і шукає дефекти в частинах програми, які доступні і можуть бути протестовані окремо (модулі програми, об’єкти, функції і т.д.)
Зазвичай компонентне (модульне) тестування проводиться викликаючи код, який необхідно перевірити чи за підтримки середовищ розробки, таких як фреймовки (каркаси) для модульного тестування або інструменти для дебагу. Всі знайдені дефекти, як правило виправляються в коді без формального їх опису в системі багів (Bug Tracking System)
Один з найбільш ефективних підходів до компонентного (модульного) тестування – це підготовка автоматизованих тестів до початку основного кодування ПЗ. Це називається розробка від тестування (test-driven development) або підхід тестування спочатку (test first approach). При цьому підході створюються і інтегруються невеликі шматки коду, навпроти яких запускаються тести, написані до початку кодування. Розробка ведеться до тих пір поки всі тести не будуть успішними.
Інтеграційне тестування призначено для перевірки зв’язку між компонентами, а також взаємодії з різними частинами системи (операційної системи, обладнанням небудь зв’язку між різними системами).
Рівні інтеграційного тестування:
Компонентний інтеграційний рівень (Component Integration testing) перевіряє взаємодія між різними системами після проведення компонентного тестування.
Системний інтеграційний рівень (System Integration testing) перевіряє взаємодію між різними системами після проведення системного тестування.
Системне тестування – основним завданням є перевірка як функціональних так і не функціональних вимог у системі в цілому. При цьому виявляються дефекти, такі як невірне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або невірна функціональність, незручність використання і т.д. Для мінімізації ризиків, пов’язаних з особливостями поведінки системи в тому чи іншому середовищі, під час тестування рекомендується використовувати оточення максимально наближене до того, на яке буде встановлений продукт після релізу. Існує два підходи до системного тестування:
На базі вимог (requirements based) – Для кожної вимоги пишуться тестові випадки (test cases), перевіряючі виконання даної вимоги.
На базі випадків використання (use case based) – На основі уявлення про способи використання продукту створюються випадки використання системи (Use Cases). По конкретному випадку використання можна визначити один або більше сценаріїв. На перевірку кожного сценарію пишуться тест кейси (test cases), які повинні бути протестовані.
Приймальне тестування проводиться з метою: визначення чи задовольняє система приймальні критерії там винесення рішення замовником або іншою уповноваженою особою приймається програма чи ні.
Приймальне тестування виконується відповідно до Плану приймальних Робіт.
Рішення про проведення приймального тестування приймається, коли: продукт досяг необхідного рівня якості та замовник ознайомлений з Планом приймальних Робіт (Product Acceptance Plan) або іншим документом, де описаний набір дій, пов’язаних з проведенням приймального тестування, дата проведення, відповідальні і т.д.
Методи приймального тестування:
Тестування замовником самостійно. Це ризиковано в тому плані що у замовника може не бути творчих ресурсів, а завантаження по поточним завданням може розтягти процес приймання.
Тестування (Аудит) третьою стороною. Наймається спеціалізована компанія на тестуванні або підписується договір з конкурентом постачальника на надання послуг аудиту. Оптимально.
Спільне тестування за сценаріями із замовником. Постачальник допомагає готувати пакет матеріалів для приймального тестування, готує команду замовника до методичного приймального тестування, контролює хід приймального тестування і терміни його виконання. Присутність інженера з тестування з боку виконавця допоможе краще зафіксувати розбіжності, зауваження та виявлені дефекти.
Фаза приймального тестування триває до тих пір, поки замовник не виносить рішення про відправлення програми на доопрацювання або реліз програми.
Незважаючи на те, що приймання знаходиться в кінці етапу (а в невеликих проектах і в кінці проекту) – готуватися до неї потрібно заздалегідь і перший прогін потрібно робити трохи раніше – щоб визначитися з повнотою і якістю робочого набору артефактів приймання, привчити до нього замовника, заздалегідь виявити можливі проблеми в приймальних тестах або в продукті.