Міністерство освіти РФ
Воронезький Державний Університет
Факультет Комп'ютерних Наук
Порівняльний аналіз каскадної і спіральної моделей розробки програмного забезпечення
Виконав : Шумлянський Михайло Сергійович
Воронеж 2003
Зміст
Введення ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 2
Водопадна модель процесу розробки ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 3
Спіральна модель процесу розробки ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 4
Ітерації по спіралі ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 4
Загальні характеристики етапів розробки програмного забезпечення
... ... ... ... ... ... ... ... ... ... .. 5
Етап планування та аналізу вимог
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .5
Етап розробки ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 6
Реалізація ... ... ... ... ... ... .... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 10
Впровадження ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 10
Супровід і Експлуатація ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 10
Висновок ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .. 11
Список джерел ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... .11
Введення < p> В даний час проглядається тенденція у бік збільшення обсягуробіт, пов'язаних з розробкою програмного забезпечення в порівнянні зроботами, виконання яких дозволить отримати апаратні засоби ЕОМ.
В основі діяльності щодо створення і використання програмногозабезпечення лежить поняття життєвого циклу. У загальному випадку розрізняютьпоняття життєвого циклу програмного забезпечення та технологічногопроцесу його розробки. Більш чітко відмінності між даними поняттямипроглядається стосовно програмних засобів. Життєвий цикл ємоделлю створення та використання програмного забезпечення, що відбиває йогорізні стани, починаючи з моменту виникнення необхідності в даному
ПЗ і закінчуючи моментом його повного виходу з вживання укористувачів.
Існує кілька моделей життєвого циклу. Традиційно виділяютьнаступні основні етапи життєвого циклу:
(стратегічне планування; аналіз вимог;
(проектування (попереднє та детальне);
(кодування (програмування);
(тестування та налагодження;
(експлуатація і супровід.
Під моделлю зазвичай мається на увазі структура, яка визначає послідовністьвиконання та взаємозв'язку процесів, дій і завдань протягомжиттєвого циклу. З існуючих нині моделей найбільшпоширені два: каскадна і галактика.
Кожному етапу відповідають певний результат і набір документації,що є вихідними даними для наступного етапу. На закінчення кожногоетапи проводиться верифікація документів і рішень з метою перевірки їхвідповідності початковим вимогам замовника.
Водопадна модель процесу розробки
До середини 80-х років найбільше поширення отримав "Водопадна"
(waterflow) або "каскадний" процес створення програмного забезпечення.
Схема "Водопадна" процесу наведена на рис. 1.1. Його основнийхарактеристикою є розбиття всієї розробки на етапи, причому перехідз одного етапу на наступний відбувається тільки після того, як будеповністю завершена робота на поточному. Кожен етап завершується випускомповного комплекту документації, достатньої для того, щоб розробкамогла бути продовжена іншою командою розробників.
Рис 1.1. "Водопадна" процес
Застосування "Водопадна" процесу ефективно для систем, для яких усамому початку розробки можна досить точно і повно сформулювати всівимоги, з тим щоб надати розробникам свободу реалізувати їхяк можна краще з технічної точки зору. У цю категорію потрапляютьскладні розрахункові системи, системи реального часу та інші подібнізавдання. Проте, в процесі використання цього підходу виявився ряд йогонедоліків, викликаних перш за все тим, що реальний процес створенняпрограмних систем ніколи повністю не вкладався в таку жорстку схему.
У процесі створення ПЗ постійно виникала потреба у поверненні допопереднім етапам і уточнення або перегляд раніше прийнятих рішень. Урезультаті реальний процес створення систем брав такий вигляд (рис.
1.2):
Рис 1.2. Реальний процес "Водопадна" схеми
Даний процес має низку істотних недоліків, основним зяких є, мабуть, те, що вимоги до створюваної системи
"заморожені" у вигляді технічного завдання на весь час її створення. Такимчином, користувачі можуть внести свої зауваження тільки після того, якробота над системою буде повністю завершена. У разі неточного викладувимог або їх зміни протягом тривалого періоду створення системи,користувачі отримують систему, не задовольняє їхнім потребам.
Спіральна модель процесу розробки
У реальному житті виявляється, що на стадії формулювання вимогзамовник не може точно визначити всі вимоги до програмного продукту.
Для подолання цієї проблеми в другій половині 80-х років був запропонований
"спіральний" процес створення програм (рис. 1.3), що робить наголос на етапианалізу і проектування. Розробка системи з даної методологіївідбувається ітерації, і після проходження кожного витка спіралікористувач отримує чергову версію системи. Після отримання замовникомкожній версії уточнюються цілі і характеристики проекту, визначається йогоякість і плануються роботи наступного витка спіралі.
Рис 1.3. Спіральна модель
Ітерації по спіралі
Спіральна модель розробки ПЗ, в тих чи інших версіях використовується вбезлічі конкретних прикладних методик, побудована на наступному шаблону.
Перш за все під час спілкування з замовником визначається набір найбільш важливихі критичних можливостей майбутньої системи. Далі спільними зусиллямивизначаються бажані терміни для реалізації цієї базової функціональності.
Формується план, починаються роботи і відстежується їх виконання.
В основу спіральної моделі закладено дві посилки. Численнимидослідженнями підтверджено, що і замовник і виконавець звичайно занадтооптимістично ставляться до термінів і бюджету, навіть при використанні хорошихметодик оцінки обсягу робіт (за функціональним точках і т. п.). Томурезультати таких оцінок пропонується збільшувати (погіршувати) доситьсерйозно - приблизно на 50%. Крім того, замовник зазвичай слабо уявляєархітектуру майбутньої системи, тому її слід проектувати, закладаючина відкриті технології і максимально гнучкі можливості розширення інарощування функціональності. Уточнення конкретних вимог виконуєтьсяітераційно, при цьому на кожному витку спіралі проектної створюється все більшеточна версія, що відповідає побажанням замовника.
Шість кроків спіральної моделі
1. У процесі спілкування з замовником формується спільне бачення проекту, атакож описуються функціональні можливості, які необхіднореалізувати в певні терміни з потрібною якістю.
2. Розставляти пріоритети, які визначають порядок реалізації основнихфункціональних можливостей.
3. Узгоджуються часові рамки проекту. Часто для цього застосовуютьсяметодики вартісного прогнозування. Далі виконавець вирішує, скількифункціональних можливостей відповідно до їх пріоритетами вдастьсяреалізувати в обумовлений термін.
4. На даному етапі визначаються архітектура і ядро майбутньої системи. Ценайбільш відповідальний момент, тому що тут необхідно врахувати поки що недеталізовані повністю вимоги до проекту - а вони цілком можуть бутисуперечливими.
Ядро має представляти собою закінчений працюючий варіант системи зневеликим набором необхідних можливостей. Не виключено, що замовникбачить архітектуру як жорстку конструкцію і не передбачає коштів їїрозширення для забезпечення додаткової або менш пріоритетноюфункціональності. Тому далі визначається спосіб реалізації вимог збільш низькими пріоритетами - це можна робити, наприклад, за допомогоювбудованої мови сценаріїв або підключенням динамічних бібліотек, длячого необхідно визначити внутрішні інтерфейси ядра.
Цей крок виконується, як правило, у два і більше число ітераційнихциклів.
5. Готується план робіт. Він орієнтований на строки, визначені натретьому етапі, і націлений на якнайшвидшу реалізацію ядра системи.
Взаємодіючи з працюючим прототипом, замовник швидше і точнішевиробляє і уточнює подальші вимоги і коректує пріоритети.
6. Розробка системи відповідно до плану.
Для цього етапу характерні три типові класу проблем:
- зміни у вимогах до проекту;
- зміни параметрів самого проекту ( термінів, бюджету, якості);
- тимчасові затримки, пов'язані з поточними питаннями (технікою,персоналом).
У ході їх вирішення доводиться позбуватися від завдань з меншими пріоритетамиі, можливо, змінювати критичний шлях проекту. Всі зміни вносяться зурахуванням головного критерію - збереження термінів проекту.
Даний підхід, звичайно, не гарантує дотримання термінів - вони можуть бутизірвані, наприклад, у випадку різкого скорочення бюджету або серйозногозміни вимог.
Загальні характеристики етапів розробки програмного забезпечення
Етап планування та аналізу вимог
Мета:
- отримання вимог;
- вироблення похідних від них вимог для етапу оцінки безпеки.
Вхідні дані:
- вимоги до системи, апаратний інтерфейс, архітектура системи;
- план розробки ПЗ;
- стандарти на вимоги до ПЗ.
Первинний результат - дані про вимоги.
Основні принципи:
- інтерфейсні та функціональні вимоги до системи, що реалізуються на базі
ПЗ, повинні бути проаналізовані на предмет протиріч, невідповідності йневизначеності;
- неадекватні і некоректні вхідні дані повинні бути спрямовані навиробили їх підетапів для роз'яснення або виправлення;
- кожну вимогу до системи, що реалізовується на базі ПЗ, повинно бути включеноу вимоги;
- повинні бути особливо відзначені вимоги, що відповідають системнимвимогам щодо запобігання виходу системи з ладу;
- вимоги повинні відповідати стандартам на вимоги до ПЗ;
- вимоги повинні формулюватися в кількісних термінах;
- вимоги не повинні описувати деталі розробки або тестування, завинятком зазначених і перевірених обмежень конструкції;
- кожне системне вимога, що реалізовується на базі ПЗ, повинно бути зводитьсядо одного або більше требованіюУ до ПЗ;
- кожну вимогу, за винятком похідних вимог, повинно бутизводиться до одного чи декількох системним вимогам;
- похідні вимоги повинні бути спрямовані етапу оцінки безпекисистеми.
На етапі планування розробки ПЗ створюються плани і вибираютьсястандарти, які направляють етап розробки та інтегрований етап. Йогометою є визначення засобів для створення ПЗ, яке будезадовольняти вимоги, що пред'являються до нього і забезпечувати достатнійрівень надійності. На цьому етапі проводитися:
визначення дій на етапах розробки та інтегрованому етапі, якібудуть присвячені визначення системних вимог і рівня ПЗ;
визначення ЖЦ ПЗ, включаючи взаємодію між етапами, механізм взаємноговпливу етапів, критерії оцінки ПО при переході від одного етапу до іншого;
визначення середовища ЖЦ, тобто методи та інструментальні засоби, що використовуютьсяна кожному етапі;
формування додаткових зауважень до ПЗ;
розгляд стандартів розробки програмного забезпечення, співвідношення їх з системними цілямибезпеки, що відносяться до розробляється ПЗ;
розробка плану створення ПЗ;
доробка і перевірка плану створення ПЗ.
Ефективність планування - визначальний фактор при розробці ПЗ. < br>Основні керівні принципи цього етапу наступні.
1. План розробки ПЗ повинен бути розроблений в такий момент ЖЦ, щобзабезпечити своєчасне управління конкретними діями на етапірозробки та інтегрованому етапі.
2. Стандарти розробки ПЗ, що використовуються в проекті, мають бути суворовизначеними та чіткими.
3. Вибрані методи та інструментальні засоби повинні бути такі, щобзабезпечили запобігання помилкам на етапі розробки або звели їх домінімуму.
4. Етап планування розробки ПО повинен забезпечити координацію міжіншими етапами з метою узгодження їх стратегій в плані розробки ПЗ.
5. Етап планування розробки ПЗ повинен включати в себе засоби перевіркиплану на етапі реалізації проекту.
6. На завершальній стадії етапу планування, план і стандарти розробки ПЗповинні бути проаналізовані на предмет повноти та несуперечності.
Інші етапи ЖЦ можуть бути розпочаті до закінчення етапу планування приумови, що є плани і процедури для дій на цих етапах.
Етап розробки
Мета:
- створення архітектури ПЗ та вимог НУ;
- вироблення похідних від них вимог для етапу оцінки безпеки.
Вхідні дані:
- дані про вимоги до ПЗ;
- план розробки ПЗ;
- стандарти проектування ПЗ.
Первинний результат - опис розробки, що включає архітектуру ПЗ та вимоги НУ.
Основні принципи:
-- створювані вимоги НУ та архітектура ПО повинні відповідати стандартам розробки ПЗ, бути несуперечність і допускати трасування і перевірку; - визначаються похідні вимоги повинні бути проаналізовані на предмет відповідності;
- на підетапів проектування ПО слід ввести можливі типи збоїв ПЗ та навпаки запобігти інші, що може змінити раніше призначений програмний рівень і визначити додаткові дані як похідних вимог, які передаються етапу оцінки безпеки системи;
- потоки даних і управління повинні бути наблюдаеми відповідно до вимог безпеки; < p> - реакції на умови збоїв повинні відповідати вимогам безпеки;
- неадекватні або некоректні вхідні дані повинні бути передані або етапу оцінки життєвого циклу системи, або підетапів розробки вимог, або етапу планування розробки ПЗ за принципом зворотного зв'язку для роз'яснення або виправлення.
Процес розробки містить дії і завдання розробника. Процесмістить дії для аналізу вимог, проектування, програмування,інтеграції, тестування і інсталяції і приймання, що відноситься допрограмного забезпечення.
Перелік дій: Цей процес складається з наступних видів діяльності.
1. Інструментарій процес. Ця дія складається з наступних завдань:
Якщо не обумовлено в контракті, розробник повинен визначити чи вибратимодель життєвого циклу програмного забезпечення відповідно допризначенням, значимістю і складністю проекту. Дії та завдання цьогопроцесу повинні бути вибрані і відображені в моделі життєвого циклу. Цідії і завдання можуть перекриватися або взаємодіяти і можуть бутивиконані Ітеративний або рекурсивно.
Розробник повинен виконувати наступне:
документувати результати відповідно до процесом документування;
розмістити результати (виходи) у процесі конфігурації і виконатиконтроль змін відповідно до цього;
документувати і вирішити проблеми і невідповідності, знайдені впрограмному продукті та завдання відповідно до процесом дозволупроблем;
інші супровідні процеси, як визначено у контракті.
Розробник повинен вибрати, довести та будуть використані внутрішні стандарти,методології, процедури і мови програмування (якщо це не обумовлено вконтракті), які повинні бути зареєстровані, відповідають івстановлені організацією для виконання дій процесу розробки тапроцесу підтримки.
Розробник повинен розробити плани управління діями в процесірозробки. Плани повинні включати особливі стандарти, методи, засоби,дії та обов'язки, пов'язані з розробкою і кваліфікацією всіхвимог, включаючи надійність і безпеку. Ці плани повинні бутизареєстровані і виконані.
Офіційно непоставляемие елементи можуть бути використані в розробці абосупроводі програмного забезпечення. Проте має бути гарантія того,що експлуатація та підтримка поставляється програмного пробеспеченія післяйого поставки замовнику не залежить від таких елементів, іншими словами, ціелементи стають офіційно поставляються.
2. Аналіз системних вимог. Ця дія складається з наступних завдань,які розробник повинен виконати або підтримувати, як потрібно законтрактом.
Особлива передбачуване використання розроблюваних систем повинно бутипроаналізовано для визначення системних вимог. Специфікаціясистемних вимог повинна описувати: функції і можливості системи;надійність, захист, розробку, інтерфейс вимоги з експлуатації тапідтримці; обмеження проектування та кваліфікаційні вимоги.
Специфікації системних вимог повинні бути зареєстровані.
Системні вимоги повинні бути оцінені з позицій наступних критеріїв:простежуваність потреб замовника, узгодженість з потребамизамовника, тестованого, здійснимість системного проектування,здійсненність експлуатації та підтримки.
3. Системне проектування. Ця дія складається з наступних завдань,які розробник повинен виконати або підтримувати, як потрібноконтрактом.
Повинна бути представлена архітектура верхнього рівня системи. Архітектураповинна визначати елементи апаратного, програмного забезпечення і ручніоперації. Повинна бути гарантія того, що всі системні вимоги повністюрозподілені серед елементів. Ці елементи повинні бути згодомвизначені як елементи апаратної конфігурації (Еак), елементиконфігурації програмного забезпечення (ЕКПО) і відповідно ручніоперації. Архітектура системи та системні вимоги, розподілені міжелементами апаратної, конфігурації, конфігурації ПЗ і ручними операціями,повинні бути зареєстровані.
Архітектура системи та вимоги для елементів конфігурації і ручнихоперацій повинні бути оцінені у відповідності з наступними критеріями:
помітне системних вимог;
узгодженість із системними вимогами;
відповідність стандартам і використовуваним методам проектування;
здійсненність наповнення елементів конфігурації ПО розподіленими для нихвимогами;
здійснимість експлуатації та підтримки.
4. Аналіз вимог до програмного забезпечення. Для кожного ЕКПО цедію складається з наступних завдань, які розробник повинен виконати.
Розробник повинен представити і зареєструвати вимоги до програмногозабезпечення, включаючи специфікації характеристик якості, описаних нижче:
специфікації функцій і можливості, включаючи виконання, фізичніхарактеристики, умови навколишнього середовища, при яких виконуєтьсяпрограмне забезпечення;
зовнішній інтерфейс ЕКПО;
кваліфікаційні вимоги;
специфікації безпеки, включаючи пов'язані з методами експлуатації іпідтримки, впливу навколишнього середовища і пошкодження персоналом;
специфікації захисту, включаючи стосуються особливої інформації та матеріалів;
людський фактор і специфікації людино-машинного взаємодії,включаючи пов'язані з ручним операціях, людино-машинних взаємодій,обмежень на персонал і області, що вимагають концентрації людськогоуваги, чутливі з точки зору помилок людини та її досвіду;
вимоги визначення даних і вимоги до баз даних;
вимоги щодо інсталяції та приймання програмного забезпечення, щов експлуатацію та супровід;
документація користувача;
вимоги по експлуатації користувачів та виконання;
вимоги за призначеною для користувача супроводу.
Розробник повинен оцінити вимоги до програмного забезпечення,керуючись наведеними нижче критеріями:
простежуваність системних вимог та системного проекту;
зовнішня узгодженість із системними вимогами;
внутрішня узгодженість;
тестове покриття вимог;
тестуємого;
здійснимість проектування програмного забезпечення;
здійсненність експлуатації і супроводу.
Після успішного завершення огляду повинна бути представлена основа длявимог до ЕКПО.
5. Проектування програмного забезпечення. Для кожного ЕКПО цю діюскладається з наступних завдань, які розробник повинен бути виконати.
Розробник повинен перетворити вимоги для ЕКПО в архітектуру,описує структуру його верхнього (вищого) рівня і визначає головнікомпоненти. Повинна бути гарантія того, що вимоги до ЕКПО повністюрозподілені між її компонентами і далі уточнені для полегшеннядетального проектування.
Розробник повинен розробити і зареєструвати:
проект вищого рівня для зовнішньої взаємодії з ЕКПО і міжкомпонентами програмного забезпечення;
проект вищого рівня для баз даних;
попередні версії керівництва для користувача;
попередні тестові вимоги і план інтеграції програмногозабезпечення.
Розробник повинен оцінити архітектуру ЕКПО і проекти інтерфейсу і базданих, керуючись наведеними нижче критеріями:
простежуваність вимог до ЕКПО;
зовнішня узгодженість з вимогами до ЕКПО;
внутрішня узгодженість між компонентами; < p> відповідність методів проектування і стандартів, які буливикористані;
здійснимість деталізованого проектування
здійсненність експлуатації і супроводу.
6. Детальне проектування програмного забезпечення. Для кожного ЕКПО цедію складається з наступних завдань, які розробник повинен виконати.
Розробник повинен розробити детальний проект для кожного компонентапрограмного забезпечення ЕКПО. Компоненти програмного забезпечення повиннібути уточнені на нижніх рівнях, що містять модулі програмногозабезпечення, які можуть кодуватися, компілюватися і тестуватися.
Повинна бути гарантія того, що вимоги до програмного забезпеченняповністю локалізовані в модулях програмного забезпечення. Деталізованийпроект має бути зареєстрований.
Розробник повинен розробити і задокументувати детальний проект длязовнішнього інтерфейсу ЕКПО між компонентами програмного забезпечення таміж модулями програмного забезпечення. Детальний проект інтерфейсу повинендозволяти писати код програми без необхідності в додатковійінформації.
Розробник повинен розробити і зареєструвати детальний проект базиданих.
Розробник повинен оновити керівництво користувача наскільки ценеобхідно.
Розробник повинен визначити та задокументувати тестові вимоги ірозклад тестування блоків програмного забезпечення. Тестовівимоги повинні включати випробування програмного забезпечення на межівимог.
Розробник повинен оновити тестові вимоги та розклад інтеграціїпрограмного забезпечення.
Розробник повинен оцінити детальний проект програмного забезпечення татестові вимоги з точки зору критеріїв, наведених нижче:
простежуваність вимог ЕКПО;
зовнішня узгодженість з архітектурою проекту;
внутрішня узгодженість між компонентами і модулями;
відповідність методів проектування і використовуваних стандартів;
здійснимість тестування;
здійснимість експлуатації і супроводу.
7. Програмування та налагодження. Для кожного ЕКПО ця дія складається знаступних завдань, які повинен виконати розробник.
Розробник повинен розробити і задокументувати наступне:
а) кожен модуль програмного забезпечення та бази даних;
б) процедури тестування і дані для тестування кожного модуля і базиданих.
Розробник повинен тестувати кожен модуль ПЗ та бази даних, переконуючись вте, що вони задовольняють вимогам. Результати тестування повинні бутизадокументовані.
Розробник повинен оновити керівництво користувача, тестові вимоги ірозклад інтеграції ПЗ, оцінити код ПЗ та результати тесту відповіднодо критеріїв, що наведені нижче:
простежуваність вимог ЕКПО та проекту;
зовнішня узгодженість з вимогами ЕКПО та архітектурою проекту;
внутрішня узгодженість між вимогами модулів;
тестування модулів;
відповідність методів кодування і використовуваних стандартів;
здійснимість інтеграції ПЗ та тестування;
здійснимість експлуатації і супроводу.
8. Інтеграція програмного забезпечення. Для кожного ЕКПО цю діюскладається з наступних завдань, які повинен виконати розробник.
Розробник повинен розробити план інтеграції для об'єднання модулів ПЗ ікомпонентів у ЕКПО. План має включати вимоги, процедури, дані,відповідальність і розклад.
Розробник повинен об'єднати модулі ПЗ та компоненти. Повинна бути гарантіятого, що кожен компонент відповідає вимогам і повністюінтегрований як результат цієї діяльності. Інтеграція та результати теступовинні бути задокументовані.
Розробник повинен оновити керівництво користувача, якщо це потрібно.
Розробник повинен розробити і задокументувати для кожногокваліфікаційного вимоги ЕКПО повний набір тестів, ситуацій (вхід,вихід, критерії тестування) та процедури тестування для управліннякваліфікаційним тестуванням ПЗ.
Розробник повинен оцінити план інтеграції, проект, код, тести, результатитестування та керівництва користувача з точки зору критеріїв,наведених нижче:
отслеживаемость системних вимог;
зовнішня узгодженість із системними вимогами;
внутрішня узгодженість;
тестування ЕКПО вимог;
відповідність використовуваних стандартів і методів тестування;
відповідність з очікуваними результатами;
здійснимість кваліфікаційного тестування ПЗ;
здійснимість експлуатації і супроводу.
9. Кваліфікаційне тестування програмного забезпечення. Для кожного ЕКПОця дія складається з наступних завдань, які повинен виконатирозробник:
Розробник повинен керувати кваліфікаційним тестуванням відповідноз кваліфікаційних вимог, особливими для ЕКПО. Повинно бутигарантовано, що реалізація кожного вимоги до ПЗ повністюпротестована. Результати кваліфікаційного тестування повинні бутизареєстровані.
Розробник повинен оцінити проект, код, тести, результати тестування ікерівництво користувача у відповідності з наведеними нижче критеріями:
тестування вимог до ЕКПО;
узгодженість з очікуваними результатами;
здійснимість системної інтеграції та тестування;
здійснимість експлуатації і супроводу.
Результати аудиту повинні бути задокументовані. Якщо розробляються абоінтегруються ПЗ та апаратне забезпечення, аудит може бути відкладений докваліфікаційного тестування системи.
Після успішного завершення аудиту, якщо написано, розробник повинен:
а) оновити та підготувати до постачання ПЗ для системної інтеграції,кваліфікаційного тестування системи, інсталяції або підтримки прийому
ПЗ, як належить;
б) представити основну лінію проектування та кодування ЕКПО;
10. Системна інтеграція. Ця дія складається з наступних завдань, якіповинен виконати розробник.
ЕКПО повинен бути інтегрований з Еак, керівництвом з експлуатації та іншимисистемами в єдину систему. Складові повинні бути протестовані навідповідність вимогам. Інтеграція та результати тестування повинні бутизадокументовані.
Для кожного кваліфікаційного вимоги до системи повинні бути розробленіі задокументовані повний набір тестів, ситуацій (вхідних, вихідних,критеріїв тестування), процедур тестування. Розробник повиненгарантувати, що інтегрована система готова для кваліфікаційноготестування.
Інтегрована система повинна бути оцінена відповідно до наведенихнижче критеріями:
зона тестування вимог до системи;
прийнятність використовуваних методів і стандартів тестування;
узгодженість з очікуваними результатами;
здійснимість кваліфікаційного тестування системи;
здійснимість експлуатації і супроводу.
11. Кваліфікаційне тестування системи. Ця дія складається знаступних завдань, що виконуються розробником.
Кваліфікаційне тестування системи повинно керуватися увідповідно до кваліфікаційних вимог, визначених для системи.
Має бути гарантовано, що виконання кожного вимоги до системипротестовано повністю і система готова до постачання. Результатикваліфікаційного тестування повинні бути задокументовані.
Система повинна бути оцінена відповідно до наведених нижче критеріями:
зона тестування вимог до системи;
підтвердження очікуваними результатами;
здійснимість експлуатації і супроводу.
Після успішного завершення аудиту, якщо написано, розробник повинен:
оновити та підготувати до постачання ЕКПО для інсталяції ПЗ і його прийняття;
обгрунтувати основні напрямки для проектування та кодування ЕКПО.
12. Інсталяція ПЗ. Ця дія складається з наступних завдань, що виконуютьсярозробником.
Розробник повинен розробити план інсталяції ПЗ в намічену середу.
Ресурси та інформація, необхідні для встановлення ПЗ, повинні бути визначеніі доступні. Розробник повинен допомагати постачальнику при установці. Післятого, як ВО встановлений в існуючу систему, Розробник повиненпідтримувати деякі паралельно їх дії. План установкиповинен бути задокументований.
Розробник повинен встановити ПО відповідно до плану установки. Повиннобути гарантовано, що ПЗ і бази даних не започатковано, функціонують іприпиняють роботу, як зазначено в контракті. Процес встановлення і результатиповинні бути задокументовані.
12. Підтримка приймання ПЗ. Ця дія складається з наступних завдань,виконуваних розробником.
Розробник повинен підтримувати процес приймання постачальником і тестування
ПЗ. Приймання і тестування повинні грунтуватися на загальному огляді, аудиті,кваліфікаційному тестуванні, кваліфікаційному тестуванні системи (якщовоно виконувалося). Результати приймання і тестування повинні бутизадокументовані.
Реалізація
Мета полягає в отриманні вихідного коду, який повинен допускатитрасування, перевірку, бути несуперечливим і коректно реалізовувативимоги НУ.
Вхідні дані:
- вимоги НУ;
- архітектура ПЗ;
- план розробки ПЗ;
- стандарти кодування ПЗ
Первинний результат - вихідний код і об'єктний код.
Основні принципи:
- вихідний код повинен реалізовувати вимоги НУ і відповідатиархітектурі ПЗ;
- вихідний код повинен відповідати стандартам кодування ПЗ;
- вихідний код повинен зводитися до опису проекту;
- неадекватні або некоректні вхідні дані повинні бути передані абопідетапів розробки вимог до ПЗ, або підетапів проектування ПЗ, абоетапу планування розробки ПЗ за принципом зворотного зв'язку для роз'ясненняабо виправлення.
Впровадження
Метою є завантаження виконуваного об'єктного коду в апаратне абопрограмно-апаратне забезпечення.
Вхідні дані:
- архітектура ПЗ;
- вихідний код;
- об'єктний код.
Результат - виконуваний об'єктний код, а також компонуемие та файлидані.
Основні принципи:
- виконуваний об'єктний код повинен бути згенерований з вихідного коду такомпонуемих і завантаження даних;
- ПЗ повинно бути додано до цільового комп'ютер для програмно-апаратноїінтеграції;
- неадекватні або некоректні вхідні дані повинні бути передані абопідетапів розробки вимог до ПЗ, або підетапів проектування ПЗ, абопідетапів кодування ПЗ, або етапу планування розробки ПЗ за принципомзворотного зв'язку для роз'яснення або виправлення.
Супровід і Експлуатація
Процес експлуатації
Процес експлуатації складається з дій і завдань того, хто експлуатуєрозроблене ПЗ. Процес включає експлуатацію ПЗ і підтримкукористувачів. Оскільки експлуатація ПЗ є інтеграційноїскладовою експлуатації системи, дії і завдання цього процесувідносяться і до системи.
Оператор управляє процесом експлуатації на рівні проекту, слідуючипроцесу управління, що є прикладом; представляє інфраструктурупроцесу, відповідно до процесу інфраструктура; підлаштовує процес дляпроекту згідно процесу підгонки; ру?? оводів процесом на організаційномурівні відповідно до процесу вдосконалення.
Перелік дій. Цей процес складається наступних завдань: виконанняпроцесу, тестування, експлуатація системи та підтримка користувачів.
Процес супроводу
Процес підтримки складається з дій і завдань особи, що виконуєсупроводження. Цей процес починається, коли необхідна модифікація черездопущених помилок, неврахованих проблем, необхідності удосконалення абоадаптації коду ПЗ і відповідної документації. Його мета - модифікованііснуюче ПЗ, зберігши його цілісність. Цей процес включаєпоширення та заміну програмного забезпечення. Процес завершується заміною ПЗ.
Дії, що забезпечуються цим розділом, визначені як процессупроводу, проте процес може використовувати інші процеси цьогостандарту. Якщо використовується процес розробки, термін розробникінтерпретується як забезпечує супровід. Забезпечуєсупроводження керує процесом супроводі на рівні проекту, слідуючипроцесу управління.
Перелік дій. Процес складається з наступних дій: процесреалізації, аналіз проблем та модифікації, реалізація модифікації, приймання,поширення, заміна ПЗ.
Висновок
Порівнюючи каскадну і спіральну моделі, можна сказати, що каскаднамодель більш універсальна, тобто вона може бути застосовна до виробництва різнихвиробів, будь то відбійний молоток чи графічний редактор. Для різнихвиробів просто будуть змінюватися кількість і назва етапів моделі.
Спіральна ж модель більше орієнтована саме на інформаційні системи,особливо на програмні продукти, тому при розробці інформаційнихсистем та їх програмного забезпечення вона переважно каскадної.
Список джерел:
1. www.aanet.ru
2. www.interface.com
3. www.setevoi.ru
4. Дж. Фокс "Програмне забезпечення та його розробка" 1985 г.
SMS ® www.shms @ box.vsi.ru
www.cs.vsu.ru/ ~ shumlyansky
