Сравнительный аналіз каскадної і спіральної моделей розробки програмного обеспечения

року міністерство освіти РФ.

Воронезький Державний Университет.

Факультет Комп’ютерних Наук.

Порівняльний аналіз каскадної і спіральної моделей розробки програмного обеспечения.

Виконав: Шумлянський Михайло Сергеевич.

Воронеж 2003.

Содержание Введение …2.

Водопадная модель процесу розробки …3.

Спиральная модель процесу розробки …4 Ітерації спіраллю …4 Загальні характеристики етапів розробки програмного забезпечення …5.

Етап планування та якісного аналізу вимог …5.

Етап розробки …6.

Реалізація …10.

Впровадження …10 Супровід і Експлуатація …10 Укладання …11 Список джерел …11.

Нині проглядається тенденція у бік збільшення обсягів робіт, пов’язаних із розробкою програмного забезпечення проти роботами, виконання яких дасть змогу отримати апаратні кошти ЭВМ.

У основі діяльності з створенню й використанню програмного забезпечення лежить поняття життєвого циклу. У випадку розрізняють поняття життєвого циклу програмного забезпечення і технологічного процесу його розробки. Чіткіше різницю між даними поняттями виявляється у відношенні програмних засобів. Життєвий цикл є моделлю створення і його використання програмного забезпечення, що відбиває його різні стану, починаючи з виникнення потреби у даному ПЗ проведено та закінчуючи моментом його повного виходу з ужитку у пользователей.

Є кілька моделей життєвого циклу. Традиційно виокремлюють такі основні етапи життєвого циклу :

(стратегічне планування; аналіз требований;

(проектування (попереднє і детальное);

(кодування (программирование);

(тестування і отладка;

(експлуатація і сопровождение.

Під моделлю зазвичай розуміється структура, визначальна послідовність виконання і взаємозв'язку процесів, діянь П. Лазаренка та завдань протягом життєвого циклу. З що у час моделей найбільш поширені дві: каскадна і спиральная.

Кожному етапу відповідають певний результат й створили набір документації, що є вихідними для наступного етапу. На закінчення кожного етапу виробляється верифікація документів і майже рішень із єдиною метою перевірки їх відповідності початковою вимогам заказчика.

Водоспадна модель процесу разработки.

На середину 80-х найбільшого поширення отримав «водоспадний «(waterflow) чи «каскадний «процес створення програмного забезпечення. Схема «водоспадного «процесу приведено на рис. 1.1. Його основним характеристикою є розбивка всієї розробки на етапи, причому перехід з однієї етапу наступного року відбувається по тому, як буде повністю завершено роботу на поточному. Кожен етап завершується випуском повного комплекту документації, достатньої у тому, щоб розробка можна було продовжено інший командою разработчиков.

Рис 1.1. «Водоспадний «процесс.

Застосування «водоспадного «процесу ефективно для систем, котрим в на самому початку розробки можна досить саме і повно сформулювати все вимоги, аби надати розробникам свободу дати раду якнайкраще з погляду. У цю категорію потрапляють складні розрахункові системи, системи реального часу й решту завдання. Проте, у процесі використання цього підходу виявився ряд його недоліків, викликаних насамперед із тим, реальний процес створення програмних систем ніколи не повністю вкладався у таку жорстку схему. У процесі створення ПЗ постійно виникала потреба у повернення до попереднім етапах і уточненні чи перегляді раніше виданих рішень. У результаті реальний процес створення систем приймав такий вигляд (рис. 1.2):

Рис 1.2. Реальний процес «водоспадною «схемы.

Цей процес має низку суттєвих недоліків, основною з якого є, мабуть, те, що вимоги до створюваної системі «заморожені «як технічного завдання попри всі час її створення. Таким чином, користувачі можуть зробити свої зауваження тільки тоді, як робота над системою буде завершено. Що стосується неточного викладу вимог чи його зміни у протягом тривалого створення, користувачі отримують систему, не що б їх потребностям.

Спіральна модель процесу разработки.

У реальному житті виявляється, що у стадії формулювання вимог замовник неспроможна точно визначити всі вимоги до програмного продукту. Для подолання цієї проблеми у другій половині 80-х було запропоновано «спіральний «процес створення програм (рис. 1.3), робить упор зроблено на етапи аналізу та проектування. Розробка системи з даної методології відбувається итерациями, і після проходження кожного витка спіралі користувач отримує чергову версію системи. Після набуття замовником кожної версії уточнюються цілі й характеристики проекту, визначається її якість і плануються роботи наступного витка спирали.

Рис 1.3. Спіральна модель.

Ітерації по спирали.

Спіральна модель розробки ПО, у тих чи інших версіях використовувана у безлічі конкретних прикладних методик, побудовано наступному шаблоні. Насамперед у ході спілкування з замовником визначається набір найважливіших і критичних можливостей майбутньої системи. Далі спільні зусилля визначаються бажані терміни для реалізації цієї базової функціональності. Формується план, починаються праці та відстежується виконання .

У основу спіральної моделі закладено дві посилки. Численними дослідженнями підтверджено, як і замовник і виконавець зазвичай занадто оптимістично ставляться до різних строків та бюджетові, навіть за використанні хороших методик оцінки обсягу робіт (по функціональним точкам тощо. п.). Тому результати таких оцінок пропонується збільшувати (погіршувати) досить серйозно — приблизно 50%. З іншого боку, замовник зазвичай погано уявляють архітектуру майбутньої системи, тому її треба проектувати, закладываясь на відкриті технологій і максимально гнучкі можливості розширення й нарощування функціональності. Уточнення конкретних вимог виконується итерационно, у своїй кожному витку проектної спіралі створюється дедалі більше точна версія, відповідна побажанням заказчика.

Шість кроків спіральної модели.

1. У процесі спілкування з замовником формується спільної візії проекту, а також описуються функціональні можливості, які потрібно реалізовувати певний час із потрібною качеством.

2. Розставляються пріоритети, що задають порядок реалізації основних функціональних возможностей.

3. Погоджуються час проведення проекту. Часто при цьому застосовуються методики вартісного прогнозування. Далі виконавець вирішує, скільки функціональних можливостей у відповідність до їх пріоритетами вдасться реалізовувати обумовлений срок.

4. На цьому етапі визначаються архітектура і майбутньої системи. Це найвідповідальніший момент, оскільки тут слід врахувати поки що не деталізовані повністю вимоги нині проектом — що цілком може бути противоречивыми.

Ядро має становити собою цілковитий працюючий варіант системи з невеликою кількістю можливості. Ймовірно, що замовник бачить архітектуру як жорстку конструкцію і передбачає засоби її розширення задля забезпечення додаткової більш-менш пріоритетною функціональності. Тому далі визначається спосіб втілення вимог з нижчими пріоритетами — це робити, наприклад, з допомогою убудованого мови сценаріїв чи підключенням динамічних бібліотек, для чого слід визначити внутрішні інтерфейси ядра.

Цей крок пояснюють виконується, зазвичай, удвічі й більше число итерационных циклов.

5. Готується план робіт. Його орієнтовано на терміни, певні на етапі, і націлений на якнайшвидше реалізацію ядра системи. Взаємодіючи із працюючим прототипом, замовник швидше, і точніше виробляє і уточнює подальші вимоги, і коригує приоритеты.

6. Розробка системи відповідно до планом.

І тому етапу характерні три типових класу проблем:

— зміни у вимоги до проекту;

— зміни параметрів самого проекту (термінів, бюджету, качества);

— тимчасові затримки, пов’язані з поточними питаннями (технікою, персоналом).

Вони рішення доводиться позбуватися завдань із меншими пріоритетами і, можливо, змінювати критичний шлях проекту. Усі зміни вносяться з урахуванням основний критерій — збереження термінів проекта.

Цей підхід, звісно, не гарантує дотримання термінів — є підстави зірвані, наприклад, у разі різкого зниження бюджету чи серйозного зміни требований.

Загальні характеристики етапів розробки програмного обеспечения.

Етап планування та політичного аналізу требований.

Цель:

— отримання вимог ;

— вироблення похідних від нього вимог для етапу оцінки безопасности.

Входные данные:

— вимоги до системи, апаратний інтерфейс, архітектура системы;

— план розробки ПО;

— стандарти на вимоги до ПО.

Первинний результат — даних про требованиях.

Основные принципы:

— інтерфейсні і функціональні вимоги до системи, реалізовані з урахуванням ПО, мали бути зацікавленими проаналізовані щодо протиріч, невідповідності і неопределенности;

— неадекватні і некоректні вхідні дані мають бути спрямовані на що виробили їх подэтапы для роз’яснення чи исправления;

— кожне вимогу до системі, реалізоване з урахуванням ПО, має бути включено в требования;

— би мало бути особливо відзначені вимоги, відповідні системним вимогам для запобігання виходу системи з строя;

— вимоги повинні відповідати стандартам на вимоги до ПО;

— вимоги повинні формулюватися в кількісних терминах;

— вимоги нічого не винні описувати деталі розробки чи тестування, за винятком зазначених і перевірених обмежень конструкции;

— кожне системне вимога, реалізоване з урахуванням ПО, має бути зводиться одного чи більше требованиюУ до ПО;

— кожне вимога, крім похідних вимог, має бути зводиться одного або декільком системним требованиям;

— похідні вимоги мають бути спрямовані етапу оцінки безпеки системы.

На етапі планування розробки ПО створюються плани і вибираються стандарти, що спрямовують етап розробки та інтегрований етап. Його метою є визначення коштів у створення ПО, що буде відповідати вимогам, пред’явлені до нього забезпечуватиме достатній рівень надійності. Аналізуючи цей етап производиться:

определение дій на етапах розробки та інтегрованому етапі, які буде присвячено визначенню системних вимог, і рівня ПО;

определение ЖЦ ПО, включаючи взаємодія між етапами, механізм взаємного впливу етапів, критерії оцінки ПО під час переходу від однієї етапи до другому;

определение середовища ЖЦ, тобто. методи лікування й інструментальні кошти, використовувані кожному этапе;

формирование додаткових зауважень до ПО;

рассмотрение стандартів розробки ПО, співвідношення його з системними цілями безпеки, які стосуються розроблюваному ПО;

разработка плану створення ПО;

доработка і перевірка плану створення ПО.

Эффективность планування — визначальний чинник розробки ПО. Основні керівні принципи цього етапу следующие.

1. План розробки ПО необхідно розробити в момент ЖЦ, щоб забезпечити своєчасне управління конкретними діями на етапі розробки та інтегрованому этапе.

2. Стандарти розробки ПО, використовувані у проекті, повинні прагнути бути суворо визначеними й четкими.

3. Обрані методи лікування й інструментальні кошти треба передбачити такі, щоб забезпечили запобігання помилок на етапі розробки чи звели їх до минимуму.

4. Етап планування розробки ПО має забезпечити координацію між іншими етапами з єдиною метою узгодження їх стратегій у плані розробки ПО.

5. Етап планування розробки ПО має включати у собі кошти перевірки плану на етапі реалізації проекта.

6. На завершальній стадії етапу планування, план і стандарти розробки ПО би мало бути проаналізовані щодо повноти і непротиворечивости.

Другие етапи ЖЦ можуть бути розпочаті до закінчення етапу планування при умови, що є плани і складні процедури для дій цих этапах.

Этап разработки.

Цель:

— створення архітектури ПЗ проведено та вимог НУ;

— вироблення похідних від нього вимог для етапу оцінки безопасности.

Вхідні данные:

— даних про вимоги до ПО;

— план розробки ПО;

— стандарти проектування ПО.

Первинний результат — опис розробки, у тому числі архітектуру ПЗ проведено та вимоги НУ.

Основні принципы:

— створювані вимоги НУ і архітектура ПО повинні відповідати стандартам розробки ПО, бути несуперечливими і допускати трассировку і перевірку;- зумовлені похідні вимоги би мало бути проаналізовані України щодо відповідності ;

— на подэтапе проектування ПО слід також запровадити можливі типи збоїв ПЗ проведено та навпаки запобігти інші, що ІСД може змінити раніше призначений програмний рівень цін та визначити додаткові дані як похідних вимог, переданих етапу оцінки безпеки системы;

— потоки даних, і управління мають бути наблюдаемы відповідно до вимог безопасности;

— реакцію умови збоїв повинні відповідати вимогам безопасности;

— неадекватні чи некоректні вхідні дані мають бути передані або етапу оцінки життєвого циклу системи, або подэтапу розробки вимог, або етапу планування розробки ПО за принципом зворотний зв’язок для роз’яснення чи исправления.

Процес розробки містить дії і завдання розробника. Процес містить дії для аналізу вимог, проектування, програмування, інтеграції, тестування і інсталяції і приймання, що належить до програмному обеспечению.

Перечень дій: Цей процес відбувається складається з таких видів деятельности.

1. Інструментарій процес. Це складається з таких задач:

Если не обумовлено в контракті, розроблювач повинен визначити чи вибрати модель життєвого циклу програмного забезпечення у відповідність до призначенням, значимістю і складністю проекту. Дії і завдання цього процесу мали бути зацікавленими обрані і відбито в моделі життєвого циклу. Ці дії і завдання можуть перекриватися чи взаємодіяти і може бути виконані итеративно чи рекурсивно.

Разработчик має виконувати следующее:

документировать результати відповідно до процесом документирования;

разместить результати (виходи) у процесі конфігурації і контроль змін — у відповідність до этим;

документировать і розв’язати ж проблеми і невідповідності, характерні для програмному продукт і завдання у відповідність до процесом дозволу проблем ;

другие супровідні процеси, як склала контракте.

Разработчик мусить вибрати, довести і використовувати внутрішні стандарти, методології, процедури і мови програмування (якщо це обумовлено в контракті), що їх зареєстровані, відповідає дійсності та встановлено організацією виспівати дій процесу розробки та процесу поддержки.

Разработчик повинен мати плани управління діями у процесі розробки. Плани мають включати особливі стандарти, методи, кошти, дії й обов’язки, пов’язані із розробкою й кваліфікацією всіх вимог, включаючи надійність і безпека. Ці плани — мусять бути зареєстровано й исполнены.

Официально непоставляемые елементи можна використовувати з розробки чи супроводі програмного забезпечення. Проте мусить бути гарантія того, що експлуатація й підтримка поставленого програмного забезпечення після його замовнику залежить від таких елементів, інакше кажучи, ці елементи стають офіційно поставляемыми.

2. Аналіз системних вимог. Це складається з таких завдань, які розроблювач повинен виконати чи підтримувати, як потрібно по контракту.

Особое передбачене використання розроблюваних систем має бути проаналізоване визначення системних вимог. Специфікація системних вимог повинна описувати: функції й можливості системи; надійність, захист, розробку, інтерфейс вимогами з експлуатації і підтримці; обмеження проектування й відповідність кваліфікаційним вимогам. Специфікації системних вимог би мало бути зарегистрированы.

Системные вимоги слід оцінити з позицій наступних критеріїв: наявність потреб замовника, узгодженість до потреб замовника, тестируемость, виконання системного проектування, здійсненність експлуатації і поддержки.

3. Системне проектування. Це складається з таких завдань, які розроблювач повинен виконати чи підтримувати, як потрібно контрактом.

Должна бути представлена архітектура верхнього рівня системи. Архітектура повинна визначати елементи апаратного, програмного забезпечення і ручні операції. Має бути гарантія те, що все системні вимоги повністю розподілені серед елементів. Ці елементи повинні прагнути бути згодом визначено як елементи апаратної конфігурації (ЭАК), елементи конфігурації програмного забезпечення (ЭКПО) і ручні операції. Архітектура системи та системні вимоги, розподілені між елементами апаратної, конфігурації, конфігурації ПЗ проведено та ручними операціями, мали бути зацікавленими зарегистрированы.

Архитектура системи та вимоги до елементів конфігурації і ручних операцій слід оцінити відповідно до такими критериями:

различимость системних требований;

согласованность з системними требованиями;

соответствие стандартам і що використовуються методам проектирования;

осуществимость наповнення елементів конфігурації ПО розподіленими їм требованиями;

выполнимость експлуатації і поддержки.

4. Аналіз вимог до програмного забезпечення. До кожного ЭКПО це дію складається з таких завдань, які розроблювач повинен исполнить.

Разработчик має подати і зареєструвати вимоги до програмного забезпечення, включаючи специфікації характеристик якості, описаних ниже:

спецификации функцій й можливості, включаючи виконання, фізичні характеристики, умови довкілля, у яких виконується програмне обеспечение;

внешний інтерфейс ЭКПО;

квалификационные требования;

спецификации безпеки, включаючи які стосуються методами експлуатації і підтримки, впливу довкілля та пошкодження персоналом;

спецификации захисту, включаючи що стосуються особливої інформації та материалов;

человеческий чинник та специфікації человеко-машинного взаємодії, включаючи які стосуються ручним операціям, человеко-машинным взаємодіям, обмеженням на персонал й області, потребують концентрації людського уваги, чутливі з погляду помилок людини її опыта;

требования визначення даних, і вимоги до баз данных;

требования по інсталяції і приймання поставленого програмного забезпечення в експлуатацію й сопровождение;

документация пользователя;

требования по експлуатації користувача і исполнению;

требования по користувальницькому сопровождению.

Разработчик повинен оцінити вимоги до програмного забезпечення, керуючись наведеними нижче критериями:

прослеживаемость системних вимог, і системного проекта;

внешняя узгодженість з системними требованиями;

внутренняя согласованность;

тестовое покриття требований;

тестируемость;

выполнимость проектування програмного обеспечения;

осуществимость експлуатації і сопровождения.

После завершення огляду мусить бути представлена основа для вимог до ЭКПО.

5. Проектування програмного забезпечення. До кожного ЭКПО це дію складається з таких завдань, які розроблювач повинен бути выполнить.

Разработчик повинен перетворити вимоги до ЭКПО в архітектуру, описує структуру його верхнього (вищого) рівня життя та визначальну головні компоненти. Має бути гарантія те, що вимоги до ЭКПО повністю розподілені між його компонентами і далі уточнені для полегшення детального проектирования.

Разработчик має розробити і зарегистрировать:

проект вищого рівня для зовнішнього взаємодії з ЭКПО й між компонентами програмного обеспечения;

проект вищого рівня для баз данных;

предварительные версії керівництва для пользователя;

предварительные тестові вимоги, і план інтеграції програмного обеспечения.

Разработчик повинен оцінити архітектуру ЭКПО й молодіжні проекти інтерфейсу і баз даних, керуючись наведеними нижче критериями:

прослеживаемость вимог до ЭКПО;

внешняя узгодженість з вимогами до ЭКПО;

внутренняя узгодженість між компонентами;

соответствие методів проектування й стандартів, хто був использованы;

выполнимость деталізованого проектирования осуществимость експлуатації і сопровождения.

6. Детальний проектування програмного забезпечення. До кожного ЭКПО це дію складається з таких завдань, які розроблювач повинен выполнить.

Разработчик повинен мати детальний проект кожному за компонента програмного забезпечення ЭКПО. Компоненти програмного забезпечення повинні бути уточнені на нижніх рівнях, містять модулі програмного забезпечення, що потенційно можуть кодуватимуть, компілюватися і тестуватися. Має бути гарантія те, що вимоги до програмного забезпечення повністю локалізовано в модулях програмного забезпечення. Деталізований проект може бути зарегистрирован.

Разработчик має розробити і задокументувати детальний проект для зовнішнього інтерфейсу ЭКПО між компонентами програмного забезпечення і між модулями програмного забезпечення. Докладний проект інтерфейсу повинен дозволяти писати код програми без потреби у додаткової информации.

Разработчик має розробити і зареєструвати детальний проект бази данных.

Разработчик повинен оновити керівництво користувача наскільки це необходимо.

Разработчик має визначити і задокументувати тестові вимоги, і розклад тестування блоків програмного забезпечення. Тестові вимоги мають включати випробування програмного забезпечення напружені требований.

Разработчик повинен оновити тестові вимоги, і розклад інтеграції програмного обеспечения.

Разработчик повинен оцінити детальний проект програмного забезпечення і тестові вимоги з погляду критеріїв, наведених ниже:

прослеживаемость вимог ЭКПО;

внешняя узгодженість з архітектурою проекта;

внутренняя узгодженість між компонентами і модулями;

соответствие методів проектування й використовуваних стандартов;

выполнимость тестирования;

выполнимость експлуатації і сопровождения.

7. Програмування і налагодження. До кожного ЭКПО це дію складається з наступних завдань, що має виконати разработчик.

Разработчик має розробити і задокументувати следующее:

а) кожен модуль програмного забезпечення та фінансової бази данных;

б) процедури тестування і такі для тестування кожного модуля та фінансової бази данных.

Разработчик повинен тестувати кожен модуль ПЗ проведено та бази даних, переконуючись в тому, що вони задовольняють вимогам. Результати тестування би мало бути задокументированы.

Разработчик повинен оновити керівництво користувача, тестові вимоги, і розклад інтеграції ПО, оцінити код ПЗ проведено та результати тесту згідно з критеріями, наведеними ниже:

прослеживаемость вимог ЭКПО і проекта;

внешняя узгодженість з вимогами ЭКПО і архітектурою проекта;

внутренняя узгодженість між вимогами модулей;

тестирование модулей;

соответствие методів кодування і використовуваних стандартов;

выполнимость інтеграції ПЗ проведено та тестирования;

выполнимость експлуатації і сопровождения.

8. Інтеграція програмного забезпечення. До кожного ЭКПО це дію складається з таких завдань, що має виконати разработчик.

Разработчик повинен мати план інтеграції для об'єднання модулів ПЗ проведено та компонентів в ЭКПО. План має включати вимоги, процедури, дані, відповідальність і расписание.

Разработчик має об'єднати модулі ПЗ проведено та компоненти. Має бути гарантія те, що кожен компонент відповідає вимогам й цілком інтегрований як наслідок цієї бурхливої діяльності. Інтеграція й одержують результати тесту мали бути зацікавленими задокументированы.

Разработчик повинен оновити керівництво користувача, якщо це требуется.

Разработчик має розробити і задокументувати кожному за кваліфікаційного вимоги ЭКПО повний набір тестів, ситуацій (вхід, вихід, критерії тестування) і складні процедури тестування керувати кваліфікаційним тестуванням ПО.

Разработчик повинен оцінити план інтеграції, проект, код, тести, результати тестування і підприємливості керівництва користувача з погляду критеріїв, наведених ниже:

отслеживаемость системних требований;

внешняя узгодженість з системними требованиями;

внутренняя согласованность;

тестирование ЭКПО требований;

соответствие використовуваних стандартів, і методів тестирования;

соответствие з очікуваними результатами;

выполнимость кваліфікаційного тестування ПО;

выполнимость експлуатації і сопровождения.

9. Кваліфікаційне тестування програмного забезпечення. До кожного ЭКПО це дію складається з таких завдань, що має виконати разработчик:

Разработчик має скеровувати кваліфікаційним тестуванням згідно з кваліфікаційними вимогами, особливими для ЭКПО. Мабуть гарантовано, що реалізація кожного вимоги до ПО повністю протестирована. Результати кваліфікаційного тестування би мало бути зарегистрированы.

Разработчик повинен оцінити проект, код, тести, результатів тестування і керівництво користувача відповідно до наведеними нижче критериями:

тестирование вимог до ЭКПО;

согласованность з очікуваними результатами;

выполнимость системної інтеграції і тестирования;

выполнимость експлуатації і сопровождения.

Результаты аудиту би мало бути задокументовані. Якщо розробляються чи інтегруються ПЗ проведено та апаратне забезпечення, аудит то, можливо відкладений до кваліфікаційного тестування системы.

После завершення аудиту, якщо наказано, розробник должен:

а) оновити і до поставки ПО для системної інтеграції, кваліфікаційного тестування системи, інсталяції чи підтримки прийому ПО, як полагается;

б) уявити основну лінію проектування й кодування ЭКПО;

10. Системна інтеграція. Це складається з таких завдань, які має виконати разработчик.

ЭКПО може бути інтегрований з ЭАК, посібником з експлуатації та інші системами на єдину систему. Складові повинні прагнути бути протестовані на відповідність вимогам. Інтеграція і вивести результати тестування би мало бути задокументированы.

Для кожного кваліфікаційного вимоги до системи необхідно розробити і задокументовані повний набір тестів, ситуацій (вхідних, вихідних, критеріїв тестування), процедур тестування. Розробник повинен гарантувати, що інтегрована система готова для кваліфікаційного тестирования.

Интегрированная система мусить бути поцінована в час відповідність до наведеними нижче критериями:

зона тестування вимог до системе;

приемлемость використовуваних методів і стандартів тестирования;

согласованность з очікуваними результатами;

выполнимость кваліфікаційного тестування системы;

выполнимость експлуатації і сопровождения.

11. Кваліфікаційне тестування системи. Це складається з наступних завдань, виконуваних разработчиком.

Квалификационное тестування системи має керуватися в відповідність до кваліфікаційними вимогами, певними системі. Мабуть гарантовано, виконання кожного вимоги до системи протестировано цілком і система готова поставці. Результати кваліфікаційного тестування повинні прагнути бути задокументированы.

Система мусить бути поцінована в час відповідність до наведеними нижче критериями:

зона тестування вимог до системе;

подтверждение очікуваними результатами;

выполнимость експлуатації і сопровождения.

После завершення аудиту, якщо наказано, розробник должен:

обновить і до поставки ЭКПО для інсталяції ПЗ проведено та його приемки;

обосновать основних напрямів для проектування й кодування ЭКПО.

12. Інсталяція ПО. Це складається з таких завдань, виконуваних разработчиком.

Разработчик повинен мати план інсталяції ПО в намічену середу. Ресурси й інформація, необхідних установки ПО, слід визначити і доступні для. Розробник має допомагати постачальнику за умови встановлення. Після того, як ПО встановлено у існуючу систему їм, Розробник повинен підтримувати деякі паралельно що їх дії. План установки може бути задокументирован.

Разработчик повинен встановити ПО відповідно до планом установки. Повинно бути гарантовано, що ПЗ проведено та бази даних инициализируются, функціонують і припиняють роботу, як у контракті. Процес встановлення і результати мали бути зацікавленими задокументированы.

12. Підтримка приймання ПО. Це складається з таких завдань, виконуваних разработчиком.

Разработчик повинен підтримувати процес приймання постачальником і тестування ПО. Приймання і тестування мають грунтуватися спільною для огляді, аудит, кваліфікаційному тестуванні, кваліфікаційному тестуванні системи (якщо воно виконувалося). Результати приймання і тестування повинні прагнути бути задокументированы.

Реализация.

Метою є отримання вихідного коду, який має допускати трассировку, перевірку, бути несуперечливим і коректно реалізовувати вимоги НУ.

Входные данные:

— вимоги НУ;

— архітектура ПО;

— план розробки ПО;

— стандарти кодування ПО.

Первинний результат — вихідний код і об'єктний код.

Основные принципы:

— вихідний код повинен реалізовувати вимоги НУ і відповідати архітектурі ПО;

— вихідний код має відповідати стандартам кодування ПО;

— вихідний код повинен зводитися до опису проекта;

— неадекватні чи некоректні вхідні дані мають бути передані або подэтапу розробки вимог до ПО, або подэтапу проектування ПО, або етапу планування розробки ПО за принципом зворотний зв’язок для роз’яснення чи исправления.

Внедрение.

Метою є завантаження виконуваного об'єктного коду в апаратне чи программно-аппаратное обеспечение.

Входные данные:

— архітектура ПО;

— вихідний код;

— об'єктний код.

Результат — виконуваний об'єктний код, і навіть компонуемые і загружаемые данные.

Основные принципы:

— виконуваний об'єктний код може бути сгенерирован з вихідного коду і компонуемых і загружаемых данных;

— ПЗ має бути завантажене в цільової комп’ютер для програмно-апаратної интеграции;

— неадекватні чи некоректні вхідні дані мають бути передані або подэтапу розробки вимог до ПО, або подэтапу проектування ПО, або подэтапу кодування ПО, або етапу планування розробки ПО за принципом зворотний зв’язок для роз’яснення чи исправления.

Сопровождение і Эксплуатация.

Процес эксплуатации Процесс експлуатації складається з діянь П. Лазаренка та завдань того, хто експлуатує розроблене ПО. Процес включає експлуатацію ПЗ проведено та підтримку користувачів. Оскільки експлуатація ПО є інтеграційної складової експлуатації системи, дії і завдання цього процесу стосуються й системе.

Оператор управляє процесом експлуатації лише на рівні проекту, слідуючи процесу управління, що є прикладом; представляє інфраструктуру процесу, відповідно до процесу інфраструктура; підбудовує процес для проекту відповідно до процесу підгонки; керує процесом на організаційному рівні відповідно до процесу вдосконалення .

Перечень дій. Цей процес відбувається полягає наступних завдань: виконання процесу, тестування, експлуатація системи та підтримка пользователей.

Процес сопровождения Процесс підтримки складається з діянь П. Лазаренка та завдань особи, виконує супровід. Цей процес відбувається починається, коли необхідна модифікація через допущених помилок, неврахованих проблем, необхідності вдосконалення чи адаптації коду ПЗ проведено та відповідної документації. Його мета — модифікувати існуюче ПЗ, зберігши його цілісність. Цей процес відбувається включає поширення та заміну ПО. Процес завершується заміною ПО.

Действия, забезпечувані цим розділом, визначено як процес супроводу, проте процес може використовувати інших процесів цього стандарту. Якщо використовується процес розробки, термін розробник інтерпретується як який би супровід. Який Би супровід керує процесом супроводі лише на рівні проекту, слідуючи процесу управління .

Перечень дій. Процес складається з таких дій: процес реалізації, аналіз труднощів і модифікації, реалізація модифікації, приймання, поширення, заміна ПО.

Заключение

.

Порівнюючи каскадну і спіральну моделі, можна сказати, що каскадна модель більш універсальна, т. е. вона застосовна до виробництва різних виробів, чи це відбійний молоток чи графічний редактор. Для різних виробів просто будуть змінюватися кількість і назву етапів моделі. Спіральна ж модель більш орієнтована саме у інформаційні системи, особливо у програмні продукти, тому розробки інформаційних систем та його програмного забезпечення вона краще каскадной.

Список джерел: 1. internet 2. internet 3. internet 4. Дж. Фокс «Програмне забезпечення та її розробка» 1985 г.

SMS® internet.

internet.