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

Размещено на http://www.allbest.ru/

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



1. Технології, моделі і процеси створення ПЗ

Програмне забезпечення (ПЗ) - комп'ютерні програми і відповідна документація. Розробляється за замовленням приватних осіб або для продажу на ринку ПЗ.

Інженерія ПЗ - інженерна дисципліна, яка охоплює всі аспекти розробки ПЗ.

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

Процес створення ПЗ - сукупність процесів, які приводять до створенню програмного продукту.

Фундаментальні процеси, властиві будь-якому проекту створення ПЗ:

Ш Розробка специфікації вимог на ПЗ (визначають функціональні характеристики системи і обов'язкові для виконання).

Ш Створення програмного забезпечення (створення ПЗ згідно специфікації).

Ш Атестація ПЗ (створене ПЗ повинно пройти атестацію для підтвердження відповідності вимогам замовника).

Ш Модернізація ПЗ (вдосконалення ПЗ згідно зміненим вимогам споживача).

Модель процесу створення ПЗ - послідовність етапів необхідних для розробки створюваного ПЗ.

Моделі процесу розробки ПЗ:

1. Каскадна модель

2. Еволюційна модель

3. Формальне перетворення

4. Збірка програмних продуктів з раніше створених компонентів (модель збірки)

5. Ітераційна (спіральна) модель

Методи створення ПЗ є структурним підходом до створення ПЗ, який сприяє виробництву ПЗ ефективним, з економічної точки зору, способом.

Всі методи базуються на використанні моделей системи у якості специфікації її структури:

1. Функціонально-орієнтовані (структурний аналіз, JSD, 70-і роки) базуються на визначенні основних функціональних компонент системи.

2. Об'єктно-орієнтовані (Booch, Rumbaugh) використовують підходи, які базуються на використанні уніфікованої мови моделювання UML.

Computer-aided Software Engineering - автоматизована розробка ПЗ.

Процеси створення ПЗ

Базові процеси створення ПЗ:

Ш Розробка специфікації.

Ш Проектування і реалізація.

Ш Атестація.

Ш Еволюція.

Життєвий цикл ПЗ - сукупність процесів, які протікають від моменту ухвалення рішення про створення ПЗ до його повного виводу з експлуатації.

Достоїнства:

Ш Документування кожного етапу.

Недоліки:

Ш «Негнучке» розбиття процесу створення на окремі етапи.

Застосування:

Ш Вимоги сформульовані достатньо чітко.

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



2. Основи створення ПЗ

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

Результат процесу визначення вимог - документація, яка формалізує вимоги, що пред'являються до системи.

Два рівні деталізації:

Ш Вимоги, які пред'являються кінцевими користувачами;

Ш Системна специфікація для розробників.

Реалізація ПЗ - процес переведення системної специфікації у працездатну систему. Включає процеси проектування і програмування.

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

Результат кожного етапу проектування - специфікація, потрібна для виконання наступного етапу.

Методи проектування - сукупність формалізованих нотацій і нормативних документів для проектування ПЗ.

Структурні методи підтримують моделі системи:

Ш Модель потоків даних;

Ш Модель «сутність-зв'язок»;

Ш Структурна модель;

Ш Об'єктно-орієнтована ієрархічна модель системи, модель відношень між об'єктами, модель взаємодії об'єктів;

Ш Діаграми переходів або сценарії життя сутностей.

Програмування і налагодження:

Тестування - процес встановлення програмних помилок.

Налагодження - встановлення місцеположення помилок і їх усунення.

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

3. Розробка вимог до ПЗ

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

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

Ш аналіз технічної здійсненності створення системи;

Ш формування і аналіз вимог;

Ш специфікація вимог і створення відповідної документація;

Ш атестація цих вимог.

Процес формування і аналізу вимог проходить через низку етапів:

Ш Аналіз предметної області. Аналітики повинні вивчити предметну область, де експлуатуватиметься система.

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

Ш Класифікація вимог. На цьому етапі безформний набір вимог перетвориться в логічно зв'язані групи вимог.

Ш Вирішення протиріч. Без сумніву, вимоги численних осіб, зайнятих у процесі формування вимог, будуть суперечливими. На цьому етапі визначаються і вирішуються суперечності такого роду.

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

Ш Перевірка вимог. На цьому етапі визначається їх повнота, послідовність і несуперечність.

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

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

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

Метод опорних точок зору

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

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

Різні методи пропонують різні трактування виразу "точка зору". Точки зору можна трактувати таким чином:

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

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

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

Цей тип точок зору має низку переваг:

1. Точки зору, зовнішні до системи, - природний спосіб структуризації процесу формування вимог.

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

3. Даний підхід корисний для створення нефункціональних вимог, з якими можна зв'язати який-небудь сервіс.

4. Реалізація ПЗ

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

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

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

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

Етапи, спільні для всіх процесів архітектурного проектування:

1. Структурування системи. Програмна система структурується у вигляді сукупності відносно незалежних підсистем. Також визначаються взаємодії між підсистемами.

2. Моделювання управління. Розробляється базова модель управління взаємовідносинами між частинами системи.

3. Модульна декомпозиція. Кожна визначена на першому етапі підсистема розбивається на окремі модулі. Тут визначаються типи модулів і типи їх взаємозв'язків.

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

Зазвичай, розробляється чотири архітектурні моделі:

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

2. Динамічна модель процесів, в якій представлена організація процесів під час роботи системи.

3. Інтерфейсна модель визначає сервіси, які надаються кожною підсистемою через спільний інтерфейс.

4. Моделі відношень, в яких показані взаємовідношення між частинами системи, наприклад потік даних між підсистемами.

Моделі архітектури можуть залежати від нефункціональних системних вимог:

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

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

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

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

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

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

5. Управління проектами зі створення і впровадження ПЗ

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

«Хороше управління не гарантує успішного завершення проекту, але погане управління обов'язково приведе до його провалу.»

Відмінності процесу розробки ПЗ від процесів реалізації технічних проектів:

Ш Програмний продукт нематеріальний.

Ш Не існує стандартних процесів розробки ПЗ.

Ш Великі програмні проекти - це часто "одноразові" проекти.

Процеси управління:

Ш Написання пропозицій по створенню ПЗ. Пропозиції повинні містити опис цілей проектів і способів їх досягнення. Вони також зазвичай включають оцінки фінансових і часових витрат на виконання проекту. При потребі тут можуть приводитися обґрунтування для передачі проекту на виконання сторонньою організацією або команді розробників.

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

Ш Оцінювання вартості проекту.

Ш Контроль за ходом виконання робіт. Менеджер повинен постійно відстежувати хід реалізації проекту і порівнювати фактичні і планові показники виконання робіт з їх вартістю.

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

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

6. Управління персоналом при реалізації проектів

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

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

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

Організація людської пам'яті

1. Короткочасна пам'ять з швидким доступом, але обмеженими можливостями. Доступна для обробки інформації, яка надходить.

2. Проміжна пам'ять з високими можливостями. Зберігання «короткострокової» інформації.

3. Довготривала пам'ять. Це пам'ять з найширшими можливостями, відносно важким доступом і вкрай ненадійними механізмами зберігання.

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

Синтаксичні знання. Це деталізовані знання (подробиці) про окремі об'єкти і явища, наприклад про те, як описати об'єкт у UML, які стандартні функції доступні в мові програмування, чи створюється оператор присвоєння за допомогою знака "=" чи знака ":=" і т. д. Ці знання зберігаються в неструктурованому вигляді.

програмний забезпечення комп'ютерний документація

7. Оцінка вартості програмного продукту

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

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

Ш Функціональний показник. Залежить від функціональних можливостей програмного продукту в цілому, наприклад, кількість функціональних і об'єктних точок.

Показник розміру

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

Функціональний показник

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

Ш Інтенсивності використання введення і виведення зовнішніх даних.

Ш Взаємодії системи з користувачем.

Ш Зовнішніх інтерфейсів.

Ш Файлів, які використовуються системою.

Нескорегований підрахунок функціональних точок (UFC) виконується шляхом обчислення суми добутків оцінки кожного чинника (число елементів, які складають даний чинник) на вибрану вагову величину цього чинника:

UFC = 2 (кількість елементів даного типу) Ч (вагова величина).

Для визначення можна скористатися методом об'єктних точок.

Число об'єктних точок у програмі можна отримати шляхом попереднього підрахунку низки елементів:

Ш Кількість зображень на дисплеї. Прості зображення беруться за 1 об'єктну точку, зображення помірної складнощі беруться за 2 точки, а дуже складні зображення прийнято рахувати за 3 точки.

Ш Кількість представлених звітів. Для простих звітів призначаються 2 точки, помірно складним звітам призначається 5 точок. Написання складних звітів оцінюється в 8 точок.

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

Продуктивність програміста

Найважливішим чинником є індивідуальні здібності.

8. Управління якістю створених програмних систем

Якість програмного продукту повинна відповідати деяким технічним вимогам. Тут виникає низка проблем:

1. Технічні вимоги. Повинні одночасно задовольняти інтересам і замовника і розробника (наприклад, зручність супроводу).

2. Складність у визначенні і вимірюванні показників якості. (наприклад, можливість перенесення (мобільність), зручність супроводу і ефективність).

3. Складність у створенні специфікації програмного продукту. Повнота специфікації не гарантує отримання високоякісного програмного продукту.

Управління якістю припускає можливість незалежного контролю за процесом розробки ПЗ. Сам же процес управління якістю складається з трьох основних видів діяльності:

1. Забезпечення якості. Визначення множини організаційних процедур і стандартів.

2. Планування якості. Виділення підмножини стандартів і процедур і їх адаптація до даного проекту.

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

Особливості процесу управління якістю:

Ш Контрольні проектні елементи в процесі розробки ПЗ є основою контролю якості. Це дає можливість своєчасного отримання інформації про проблеми і труднощі.

Ш Команда контролю за якістю не повинна бути зв'язана з групою розробників.

9. Створення проекту програмної системи з використанням елементів об'єктного проектування

Основна ідея об'єктно-орієнтованого аналізу і проектування (object-oriented analysis and design) полягає в розгляді предметної області і логічного рішення задачі з погляду об'єктів (понять і сутностей). У процесі об'єктно-орієнтованого аналізу основна увага приділяється визначенню і опису об'єктів (або понять) у термінах предметної області. У процесі об'єктно-орієнтованого проектування визначаються логічні програмні об'єкти, які будуть реалізовані засобами об'єктно-орієнтованої мови програмування. Ці програмні об'єкти включають атрибути і методи. І, нарешті, в процесі конструювання (construction) або об'єктно-орієнтованого програмування (object-oriented programming) забезпечується реалізація розроблених компонентів і класів.

Розглянемо коротко деякі основні принципи об'єктно-орієнтованого аналізу і проектування, надалі ми дамо точніші визначення і повніше розшифруємо всіх розглянутих термінів.

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

· Крок другий. Об'єктно-орієнтований аналіз предметної області (object-oriented domain analysis). Завдання цього кроку у визначенні видів діяльності учасників процесу і складанні концептуальної моделі (conceptual model), яка відображає різні категорії елементів предметної області. Причому не тільки види діяльності учасників, але і всі поняття, які відносяться до справи.

· Крок третій. Розбираємося, хто, чим займається. Ця діяльність і називається об'єктно-орієнтованим проектуванням (object-oriented design), при якому основна увага зосереджена на розподілі обов'язків. Розподіл обов'язків (responsibility assignment) означає виділення завдань і обов'язків різних програмних об'єктів у застосуванні.

Найбільш важливим моментом об'єктно-орієнтованого аналізу і проектування є кваліфікований розподіл обов'язків між компонентами програмної системи. Річ у тому, що це єдиний вид діяльності, без якого неможливо обійтися. До того ж він робить визначальний вплив на працездатність, масштабованість, розширюваність і можливість повторного використання компонентів. Обов'язки об'єктів і їх взаємодії зображуються з використанням діаграм класів (design class diagram) і діаграм взаємодій (collaboration diagram).



10. CASE-засоби автоматизації процесів створення ПЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Класичну модель розробки ПЗ, що базується на ДСТУ, RUP, що припускає послідовний перехід від попередньої стадії розробки до наступної і дозволяє кардинально знизити кількість ризиків проекту і зробити його більш прозорим;

* Гнучку модель розробки ПЗ (Agile), орієнтовану на мінімізацію ризиків, за рахунок використання механізмів зворотного зв'язку та регулярне безпосереднє спілкування між усіма учасниками проекту.

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

Залежно від обраної стратегії виділяються різні стадії розробки, які обов'язково включають в себе:

* Збір та аналіз вимог;

* Підготовку технічного завдання та проектної документації;

* Безпосередню розробку програмного забезпечення;

* Проведення тестування ПЗ;

* Розробку та підготовку документації;

* Впровадження ПЗ і його інтеграцію з іншими системами;

* Навчання користувачів;

* гарантійну та післягарантійну підтримку продукту / рішення.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель водоспаду (англ. waterfall model) - модель процесу розробки програмного забезпечення, в якій процес розробки виглядає як потік, що послідовно проходить фази аналізу вимог, проектування, реалізації, тестування, інтеграції та підтримки.

зміст моделі

Модель водоспаду (waterfall model або послідовна розробка) - напевно, найвідоміший, історично з'явився одним з перших процес розробки. Він був описаний у статті Ройса (WWRoyce) в 1970 році (насправді, Ройс критикував цей процес, пропонуючи як альтернативу ітеративну розробку).

Основна ідея полягає в тому, що процес розробки ділиться на чітко визначені фази, виконувані строго послідовно. Назва «водоспад» з'явилося за зовнішнього вигляду діаграми, яка зображує процес:

Оригінальна модель водоспаду Ройса, відображає фази в такому порядку:

1. Визначення вимог

2. Проектування

3. Конструювання (також «реалізація» або «кодування»)

4. Інтеграція

5. Тестування та налагодження (також «верифікація»)

6. Інсталяція

7. Підтримка

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

Тим самим, модель водоспаду увазі, що перехід від однієї фази розробки до іншої відбувається тільки після повного і успішного завершення попередньої фази, і що переходів назад або вперед або перекриття фаз - не відбувається.

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

Критика моделі Водоспаду та гібридні методологічні рішення

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

Размещено на Allbest.ru

...