Реалізація

Завершивши проектування можна починати реалізацію системи. Однак на практиці фаза проектування та реалізації перекриваються. Таким чином, в міру здійснення ієрархічного процесу розбиття аналіз деяких елементів системи може бути визнаний достатньо повним для переходу до реалізації, в той час як інші елементи вимагають подальшого уточнення. У ході процесу реалізації необхідно встановлювати правильність програми. Сучасні процедури здебільшого засновані на тестуванні, хоча в останні роки розширилося використання методів наскрізного структурного контролю та атестації програм. У будь-якому випадку, тестування за допомогою виконання програми зазвичай здійснюється знизу вгору, на початку на блочному (модульному або процедурному рівні), потім функціонально, компонент за компонентом. У міру перевірки окремих компонентів вони об'єднуються в систему в процесі її компонування, після чого починаються системні випробування. У кінцевому підсумку, після того як незалежно буде засвідчено якість функціонування системи та оцінено її параметри, вона вважається готовою до випуску.

Обслуговування

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

Фази та роботи жцпо по Боемі

Каскадна модель була введена в 70 - 80 рр.. Вона зручна для однорідних ПП, коли кожен додаток являло собою єдине ціле. Основні характеристики моделі: - Життєвий цикл розбивається на етапи (фази); - Перехід з етапу на етап - тільки після повного завершення поточного етапу; - Етап завершується випуском повного комплекту документації, достатньої для того, щоб робота могла бути виконана іншою командою розробників. Головні характерні риси каскадної моделі наступні: завершення кожної фази верифікацією і підтвердженням, мета яких - усунути можливо більше число роблем, пов'язаних з розробкою вироби; циклічні повторення реалізованих фаз з можливо більш ранньої фази.

UML

Метод UML [1] (Unified Modeling Language — уніфікована мова моделювання) є рідкісним прикладом плідної кооперації групи (G. Booch, I. Jacobson, J. Rumbaugh) провідних спеціалістів з програмної інженерії і авторів відповідних методів інженерії вимог, що набули значного визнання і широко застосовуються. Дослідивши всі переваги власних пропозицій і широкий спектр конкуруючих, вони інтегрували свої зусилля, створивши новий метод моделювання, якому дали цитовану вище назву UML. UML став базовим для багатьох провідних розробників програмного забезпечення, і тепер експерти прогнозують, що він набуде статусу міжнародного стандарту як метод моделювання продуктів усіх стадій життєвого циклу розробки програмних систем.

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

В основу методу покладено парадигму об’єктного підходу, за якою концептуальне моделювання проблеми (дивись п. 3.2) відбувається в термінах взаємодії об’єктів:

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

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

- модель процесів визначає дії, які виконують об’єкти.

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

Кожний вид діаграм відображає різні перспективи бачення й розуміння моделі. У моделі може бути по кілька діаграм кожного з описаних видів.

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

Другий тип коментарю названо стереотипом. Стереотип (stereotype) - це засіб метакласифікації елементу в UML. Він є специфічним стандартизованим коментарем щодо категорії елементу, поданого на будь-якій діаграмі, своєрідним ярликом, який характеризує зміст елементу діаграми або його призначення.

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

Певні стереотипи є фіксованими в UML і мають стандартні назви, як-от: «актор», «система», «підсистема», «подія», «виняткова ситуація», «інтерфейс», «метаклас», «послуга» (утиліта) та ін.

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

характеристики інструментальних засобів ПЗ

Характеристики:

1.Функциональная ориентация инструментальных средств. Это одна из важнейших для пользователей характеристик, которая может иметь широкий диапазон по номенклатуре функций и по степени их детализации. В настоящем анализе принят укрупненный перечень функциональной ориентации, включающий следующие направления:

-    поддержка полного жизненного цикла ПО или значительной его части;

-    поддержка начальных стадий создания про граммного проекта;

-    реализация разработки и производства про граммного продукта;

-    обеспечение работ по управлению проекти рованием;

-    выполнение автономных задач и частных опе раций;

-    поддержка создания проблемно-ориентиро ванного прикладного ПО.

2. Уровень интегрированности. Эта характеристика определяет интеграцию инструментов с позиции объема выполняемых ими функций. В Перечне достаточно четко выделяются три уровня интегрированностн:

-    инструментальный комплекс (система), ориентированный на поддержку, как правило, нескольких стадий жизненного цикла ПО;

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

3. Характеристика организаций -разработчиков. При всем их разнообразии следует выделить два типа: организации, имеющие одну-две разработки, и те, которые создали определенную совокупность средств, причем их разработка приходится на большой отрезок времени. Фактически это характеристика профиля организации-разработчика: в первом случае это организации, занимающиеся прикладной тематикой, создавшие инструменты для собственных нужд; во втором — профессионалы в области технологии, создающие средства с расчетом на их распространение в тех или иных прикладных областях. На рис. 3 приведена гистограмма распределения количества организаций в зависимости от числа созданных ими средств; гистограммы позволяют сделать следующие выводы:

-    общее количество отмеченных организаций - около 50;

-    число профессиональных организаций в стра не явно недостаточно и не превышает пятн-де- сяти;

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