Технологія розробки програмного забезпечення

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

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

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

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

При використанні методологій структурного аналізу з'явився ряд обмежень (складність розуміння, велика трудомісткість і  вартість використання, незручність  внесення змін у проектні специфікації і т.д.) Із самого початку CASE-технології і розвивалися з метою подолання  цих обмежень шляхом автоматизації  процесів аналізу й інтеграції підтримуючих засобів. Вони мають достоїнства і можливостями, перерахованими нижче.  

 

 

 

 

 

Об’єктно-орієнтований аналіз та проектування

 

1. Стадії процесу розробки ПЗ.

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

Існує ряд моделей оптимізації  процесу розробки ПЗ, кожна з яких володіє своїми перевагами і недоліками. Для забезпечення найкращого результату, компанія БМС Cофт у своїй роботі застосовує адекватні конкретному  проекту сучасні моделі, зокрема: 

•   Класичну модель розробки ПЗ, що базується на ДСТУ, RUP, що припускає послідовний перехід від попередньої стадії розробки до наступної і дозволяє кардинально знизити кількість ризиків проекту і зробити його більш прозорим;  
•   Гнучку модель розробки ПЗ (Agile), орієнтовану на мінімізацію ризиків, за рахунок використання механізмів зворотного зв'язку та регулярне безпосереднє спілкування між усіма учасниками проекту. 

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

•      Збір та аналіз вимог;  
•      Підготовку технічного завдання та проектної документації;  
•      Безпосередню розробку програмного забезпечення;  
•      Проведення тестування ПЗ; 
•      Розробку та підготовку документації;  
•      Впровадження ПЗ і його інтеграцію з іншими системами;  
•      Навчання користувачів;  
•     гарантійну та післягарантійну підтримку продукту / рішення.

 

 

2. Основні моделі процесів розробки програмних систем.

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

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

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

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

Існують різні графічні моделі, використовувані при розробці ПЗ: блок-схеми, кінцеві автомати, синтаксичні діаграми, семантичні мережі. Загальна перевага графічних моделей - наочність.

Візуальне (графічне) моделювання - дозволяє описувати проблеми за допомогою  зримих абстракцій, відтворюючих поняття  та об'єкти реального миру. Моделювання  здійснюється за допомогою мови моделювання, яка включає: елементи моделі; нотацію (систему позначень); керівництво з використання.

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

1. Графічні моделі допомагають отримати загальне уявлення про систему, сказати про те, якого роду абстракції існують в системі і які її частини потребують подальшого уточнення.
2. Графічні моделі утворюють зовнішнє представлення системи і пояснюють, що ця система робитиме, тим самим полегшують спілкування із замовником.
3. Графічні моделі полегшують вивчення методів проектування, зокрема об'єктно-орієнтованих методів.

В процесі створення ПЗ використовуються наступні види моделей:

• моделі діяльності організації (або моделі бізнес-процесів):

о моделі "AS-IS" ("як є"), які відображають існуючий стан;

о моделі "AS-TO-BE" ("як повинно бути"), які відображають представлення про нові процеси і технології роботи організації;

• моделі ПЗ, яке проектується, які будуються на основі моделі "AS-TO-BE", уточнюються і деталізують до потрібного рівня.

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

Для полегшення праці розробників  і автоматизованого виконання деяких рутинних дій використовуються CASE-засоби (Computer Aided Software Engineering). В даний час CASE-засоби забезпечують підтримку більшості процесів життєвого циклу ПЗ, що дозволяє говорити про CASE-технології розробки ПЗ. CASE-технологія - це сукупність методів проектування ПЗ та інструментальних засобів для моделювання предметної області, аналізу моделей на всіх стадіях ЖЦ ПЗ і розробки ПЗ.

Об'єктна модель є концептуальною базою об'єктно-орієнтованого підходу (ООП).

 

 

3. Модель водопаду.

Модель водоспаду (англ. waterfall model) - модель процесу розробки програмного забезпечення, в якій процес розробки виглядає як потік, що послідовно проходить фази аналізу вимог, проектування, реалізації, тестування, інтеграції та підтримки. 
зміст моделі 
Модель водоспаду (waterfall model або послідовна розробка) - напевно, найвідоміший, історично з'явився одним з перших процес розробки. Він був описаний у статті Ройса (WWRoyce) в 1970 році (насправді, Ройс критикував цей процес, пропонуючи як альтернативу ітеративну розробку). 
Основна ідея полягає в тому, що процес розробки ділиться на чітко визначені фази, виконувані строго послідовно. Назва «водоспад» з'явилося за зовнішнього вигляду діаграми, яка зображує процес:

Оригінальна модель водоспаду  Ройса, відображає фази в такому порядку: 
 
 1. Визначення вимог 
 2. Проектування 
 3. Конструювання (також «реалізація» або «кодування») 
 4. Інтеграція 
 5. Тестування та налагодження (також «верифікація») 
 6. Інсталяція 
 7. Підтримка 
 
Слідуючи моделі водоспаду, розробник переходить від однієї стадії до іншої строго послідовно. Спочатку повністю завершується етап «визначення вимог», в результаті чого виходить список вимог до ПЗ. Після того як вимоги повністю визначені, відбувається перехід до проектування, в ході якого створюються документи, що детально описують для програмістів спосіб і план реалізації зазначених вимог. Після того як проектування повністю виконано, програмістами виконується реалізація отриманого проекту. На наступній стадії процесу відбувається інтеграція окремих компонентів, що розробляються різними командами програмістів. Після того як реалізація і інтеграція завершені, проводиться тестування і налагодження продукту; на цій стадії усуваються всі недоліки, що з'явилися на попередніх стадіях розробки. Після цього програмний продукт впроваджується і забезпечується його підтримка - внесення нової функціональності та усунення помилок. 
 
Тим самим, модель водоспаду увазі, що перехід від однієї фази розробки до іншої відбувається тільки після повного і успішного завершення попередньої фази, і що переходів назад або вперед або перекриття фаз - не відбувається. 
 
Тим не менше, існують модифіковані моделі водоспаду (включаючи модель самого Ройса), що мають невеликі або навіть значні варіації описаного процесу. 
 
Критика моделі Водоспаду та гібридні методологічні рішення 
 
Модель водоспаду є розумним вибором для типових, стандартних проектів або за наявності жорстких вимог до якості (наприклад, при створенні mission critical-систем). Тим не менше, її недоліки досить істотні, і для розробки комерційного ПЗ, як правило, існують значно більш ефективні альтернативи.