Об’єктно-орієнтована модель

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

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

Об’єктно-орієнтований підхід використовує наступні базові поняття:

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

властивість об’єкта- характеристика об’єкта, його параметр;

метод обробки- програма дій над об’єктом чи його властивостями;

подія- зміна стану об’єкта;

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

Існують різні ОО технології та методики проектування програмних продуктів,

які повинні забезпечити принципи ОО підходу:

Інкапсуляція- поєднання структур даних з методами їх обробки в абстрактних типах даних - класах об'єктів;

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

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

Для ОО-проектування характерні наступні риси:

Ø об'єкт описується як модель деякої сутності реального світу;

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

Виділено чотири етапи ООП:

1. розробка діаграми апаратних засобів системи обробки даних (процесори, зовнішні пристрої, обчислювальні мережі та їх зв'язки);

2. розробка структури класів, яка описує зв'язок між класами та об'єктами;

3. розробка діаграм об'єктів, що показують взаємозв'язки з іншими об'єктами;

4. розробка внутрішньої структури програмного продукту.

Ітеративна модель (Rational Unified Process)

Ø дозволяє враховувати вимоги, що змінюються;

Ø перші ітерації виявляють ризики;

Ø керівництво може вносити в продукт тактичні зміни;

Ø спощується виявлення загальних ділянок коду;

Ø за декілька ітерацій можна знайти та видалити дефекти;

Ø процес розробки можна покращувати протягом всього проекту.

Модель швидкої розробки

(Rapid Application Development, RAD)

Ø Бізнес-моделювання. Моделюється інформаційний потік між бізнес-функціями. Отримання відповідей на питання:

Яка інформація керує бізнес-процесом?

Яка інформація генерується?

Хто її генерує? Де застосовується інформація? Хто її обробляє?

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

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

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

Ø Генерація програми. Передбачається використання методів, які орієнтовані на мови програмування 4-го покоління. Замість створення ПЗ за допомогою мов програмування третього покоління, RAD-процес працює з повторно використовуваними програмними компонентами або створює повторно-використовувані компоненти. Для забезпечення конструювання використовуються утиліти автоматизації;

Ø Тестування й об'єднання. Оскільки застосовуються повторно використовувані компоненти, багато програмних елементів вже протестовано. Це зменшує час тестування (хоча всі нові елементи повинні бути протестовані).

Коли застосовують RAD!

Ø Потрібне виконання проекту за короткий термін (90 днів). Швидке виконання проекту дозволяє створити систему, яка відповідає вимогам сьогодення. (Якщо система проектується довго, то висока імовірність того, що за час проектування система морально застаріє ще до завершення її проектування).

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

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

Ø Інтерфейс користувача – головний фактор. RAD технологія надає можливість продемонструвати інтерфейс у прототипі.

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

Ø ПЗ не властива велика обчислювальна складність.

Застосування RAD можливо в тому випадку, коли кожна головна функція може бути завершена за 3 місяці.

RAD має свої недоліки та обмеження:

Ø Для великих проектів необхідні суттєві людські ресурси (необхідно створити достатню кількість груп).

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

Ø RAD не може бути застосована в умовах високих технічних ризиків (тобто при використанні нової технології).

5. Адаптовані моделі (швидке відстежування, паралельний інжиніринг, «win-win», еволюційний/інкрементний принцип, принцип V-подібної інкрементної моделі).

Ø Швидке відстежування;

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

Ø Паралельний інжиніринг;

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

Ø Спіральна модель “win-win”;

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

Фази спіральної моделі win-win:

1. Визначення учасників наступного рівня.

2. Визначення умов, необхідних для одержания учасниками перемоги.

3. Узгодження переможних вимог.

4. Формулювання цілей, обмежень та альтернативних варіантів наступного рівня.

5. Оцінка алтернативних варіантів на рівні продукту та процесу, разрешение рисков.

6. Визначення наступного рівня продукту та процесу, включая сегментацию

7. Обоснование определений продукта и процесса.

8. Обзор и комментарии.

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

Эволюционно-инкрементный принцип:

1. Является ли решение о разработке текущих функциональных свойств хорошей идеей с учетом текущего обьема финансирования.

2. Наступило ли уже время рассматривать функциональные возможности системы.

3. Стоят ли добавленные функциональные возможности потраченных на них средств.

4. Хватит ли у нас объема денежных средств на разработку требуемой системы в полном объеме.

15. Фіксування. Трасування.

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

Вимоги повинні бути перевірені на коректність, відповідність та повноту.

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

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

Верифікація вимог – процес перевірки специфікації вимог на відповідність, несуперечність, повноту та здійснимість, а також на відповідність стандартам.

Результат – узгоджений вихідний документ, що встановлює повноту та коректність вимог до ПЗ, та дає можливість продовжити проектування ПЗ

Трасування – інструмент встановлення залежності між сформульованими вимогами та їх змінами.

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

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

Основу трасування утворюють:

Ø вимоги, що змінюються при їх формуванні

Ø деталі виконання функцій в ПЗ, які не передбачалися, проте виникли при реалізації

Ø зв’язки між різними моделями процесу проектування системи

Ø інформація про узгодженість атрибутів вимог на різних рівнях наведеної схеми трасування

Ø спеціальні системні вимоги, що стосуються повторного використання готових компонентів

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

Процедура трасування:

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

Ø складається список питань, згідно з яким на кожному етапі перевіряються зв’язки при реалізації вимог в ПЗ

16. Технічна документація.

Технічне завдання – документ, що визначає порядок і умови проведення робіт з розробки ПЗ, містить мету, завдання, принципи виконання, очікувані результати та строки виконання робіт.

Чому так важливо вести докуметацію:

Ø Комплексні проекти вимагають участі колективу виконавців та Замовника

Ø Розриви робочого процесу (організаційні, функціональні і т.п)

Ø Неформальні канали комунікацій - фактор ризику (8-37-55%)

Ø “Людський фактор”: амбіції, приховування інформації, культурні відмінності, неформальні домовленості порушуються і т.п.

Формування вимог до автоматизованої системи (АС)

Неформальні задачі стадії:

Ø Аналіз “вторинних даних” – опитування замовника

Ø З мінімальними витратами виявити та офіційно зафіксувати існуючі недоліки та необхідність виконання робіт

Ø Або нестачу необхідних відомостей

Етапи:

1. Дослідження об’єкту та обґрунтування необхідності створення АС

2. Формування вимог користувача до АС

3. Розробка “Звіту про дослідження” та заявки на розробку АС

Зміст “Звіту про дослідження”:

Ø Характеристика об’єкту та результатів його функціювання

Ø Опис існуючої ІС

Ø Опис недоліків існуючої ІС

Ø Обгрунтування необхідності вдосконалення ІС об’єкту

Ø Цілі, критерії та обмеження створення ІС

Ø Функції та задачі створюваної АС

Ø Висновки та пропозиції

Склад робіт:

Ø Сбір даних про об’єкт та видах діяльності

Ø Оцінка якості функціонування об’єкту та видів діяльності

Ø Виявлення проблем, які розв’язуватимуться за допомогою автоматизації

Ø Оцінка доцільності створення АС

Ø Підготовка початкових даних для формування вимог

Ø Розробка звітних документів - “Звіт про дослідження” та заявки на розробку АС

Розробка концепції АС Неформальні задачі стадії:

1. Зібрати “первинні” дані, якщо це необхідно

2. Обрати правильний шлях реалізації

3. Затвердити невірність інших шляхів для того, аби в майбутньому не витрачати на них час

4. Позбавитися від нереалізованих бажань.

Етапи:

1. Детальне вивчення об’єкту.

2. Проведення необхідних науково-дослідницьких робіт

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

4. Оформлення звітних документів.

Технічне завдання

Етапи:

1. Розробка та затвердження ТЗ на створення АС

Склад робіт:

1. Розробка та оформлення проекту ТЗ

2. Узгодження та виправлення ТЗ

3. Затвердження ТЗ

Ескізний проект

Задачі:

1. Обгрунтувати вибір вендора

2. Додатково звузити простір вибору

3. Отримати інформацію, яку не надали раніше

Етапи:

1. Розробка попередніх проектних рішень на АС та її частин

2. Розробка документації на АС та її частини

Примітка: Інколи допускається виключати стадію ескізного проекту

Зміст “Пояснювальної записки”:

Ø Загальні положення

Ø Опис процесу діяльності

Ø Основні технічні рішення, включаючи відомості про забезпечення заданих в ТЗ користувацьких характеристик системи (підсистем), визначаючих її якість

Ø заходи про підготовку об’єкту автоматизації у введення системи в дію

Технічний проект

Задачі:

1. Деталізувати та затвердити проектні рішення.

2. Уточнити вартість рішення

Етапи:

1. Розробка проектних рішень по АС та її частинам

2. Розробка документації на АС та її частини

3. Розробка та оформлення документації на доставку засобів для комплектування АС

4. Розробка завдань на проектування в суміжних частинах проекту об’єкта автоматизації

Робоча документація

Задачі:

1. Деталізувати процедури експлуатації розроблених рішень

Етапи:

1. Розробка робочої документації на систему та її частини

2. Розробка та адаптація програм

Допускається об’єднувати стадії “технічний проект” та “робоча документація” зі стадію “Техноробочий проект”

17. Технічне завдання. Рівні деталізації.

Технічне завдання – документ, що визначає порядок і умови проведення робіт з розробки ПЗ, містить мету, завдання, принципи виконання, очікувані результати та строки виконання робіт.

ЕТАПИ СТВОРЕННЯ ТЕХНІЧНОГО ЗАВДАННЯ

Ø Постановка задачі проекту;

Ø Формування та конкретизація вимог до технічної реалізації;

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

Ø Вибір та встановлення мов та кодів програмування;

Ø Складання, корегування та затвердження у замовника технічного завдання.

Повинне містити розділи, що відображають відомості про:

Ø Що треба зробити;

Ø Навіщо це потрібно;

Ø Де це повинно працювати;

Ø Яким вимогам повинно задовольняти;

Ø Що необхідно виконати, щоб зробити це;

Ø Який порядок приймання-отримання робіт Замовником;

Ø Яким чином має бути задокументовано проведення робіт;

Ø На підставі яких нормативно-технічних документів повинні проводитися роботи?

ЗНАЧЕННЯ ТЕХНІЧНОГО ЗАВДАННЯ

• Замовник

• Розуміння потреб

• Деталізація вимог

• Опис приймальної перевірки

• Обмеження переліку вимог

• Розробник

• Розуміння задачі

• Опис системи

• Планування робіт

• Управління змінами

• Обмеження переліку вимог

Як сполучна ланка між замовником та виконавцем дозволяє:

Ø Для обох сторін - уявити готовий проект до початку роботи;

Ø Виконати за кожним пунктом перевірку готового продукту;

Ø Зменшити кількість помилок, пов'язаних із зміною вимог внаслідок їх неповноти або хибності;

Ø Замовнику: усвідомити, що саме йому потрібно, чітко це сформулювати;

Ø Вимагати від виконавця відповідності продукту всім обумовленим і затвердженим пунктам ТЗ;

Ø Виконавцю: зрозуміти зміст поставленої задачі;

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

Ø Відмовитися від виконання робіт, не зазначених у ТЗ.

Чому, як правило, розробникам вигідна відсутність ТЗ?

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

Ø Це дає можливість затягнути розробку і збільшити бюджет;

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

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

Ø Відсутність технічного завдання у взаєминах замовника і виконавця - беззаконня.

Як аргументують відмову від оформлення ТЗ?

Ø Завдання таке складне і таке "творче", що його неможливо загнати в рамки ТЗ!

Ø Написання ТЗ займе багато часу і ресурсів. Краще одразу перейти до роботи, а там - визначимося!

Ø ТЗ не потрібно, оскільки задача дуже очевидна та проста!

Хто повинен написати технічне завдання?

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

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

Є категорії виконавців, нездатних писати технічні завдання:

Дизайнери;

Web-програмісти;

Програмісти.

Технічне завдання - закон для розробника. Він покликаний:

Ø описати мету роботи. І розробник, і замовник повинні чітко розуміти, до чого вони прагнуть, за що один платить гроші, а інший - витрачає час і напружує голову;

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

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

Вимоги, яким повинно задовольняти технічне завдання:

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

Логічність - опис не повинний бути суперечливим

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

Зв'язність - структура документа повинна бути підпорядкована одній меті.

Наповнення розділів розробник повинен розробити сам. Але в будь-якому випадку повинні бути відображені основні розділи ТЗ:

Ø Технічні вимоги і стандарти;

Ø структура;

Ø Функціональний зміст окремих структурних елементів;

Ø Склад робіт та терміни виконання;

Ø Вартість робіт.

Для кого потрібно технічне завдання?

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

Технічне завдання на розробку програм має дати виконавцю інформацію і про фірму, і про цілі, і про завдання.

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

Ø Організація

Ø Інформація

Ø Комунікація

Ø Юрисдикція

Ø ОРГАНІЗАЦІЯ

Організація повинна бути спрямована на сам процес. Структура технічного завдання на розробку програм повинна бути чіткою і лаконічною.

Ø ІНФОРМАЦІЯ

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

Ø КОМУНІКАЦІЯ

Може бути декілька мов, точніше – кількість мов залежить від кількості учасників (клієнт, менеджер проекта, програмісти).

Технічне завдання – універсальна мова для всіх.

Ø ЮРИСДИКЦІЯ

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

РІВЕНЬ ДЕТАЛІЗАЦІЇ №1

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

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

Таке ТЗ можна передати на виконання групі розробників в будь-якому середовищі.

Переваги:

Ø Готову роботу (ТЗ) можна передати будь-який інший групі виконавців, порівняти з пропозиції та оцінку. Тобто влаштувати «тендер». Оцінка готового ТЗ такого рівня іншими командами не проводитиметься довго і дорого.

Ø Якщо таке ТЗ написано якісно, ​​воно містить рекомендації щодо зміни бізнес-процесів на підприємстві з метою впровадження системи автоматизації. Це вже дозволить оцінити і зробити необхідний реінжиніринг бізнес-процесів.

Недоліки:

Ø Існує великий ризик того, що компетенції фахівців не вистачить для такого ТЗ. Адже група повинна складатися не тільки з досвідчених аналітиків і програмістів, - а й фахівців тієї області, яку збираються автоматизувати;

Ø Складання такого ТЗ буде коштувати дорого;

Ø Складання такого ТЗ потребуватиме відносно багато часу;

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

РІВЕНЬ ДЕТАЛІЗАЦІЇ №2

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

Переваги:

Ø Якщо таке ТЗ складено якісно, ​​воно містить рекомендації щодо зміни бізнес-процесів на підприємстві з метою впровадження системи автоматизації. Що вже дозволить оцінити і зробити необхідний реінжиніринг БП.

Ø У такому ТЗ вже є результати зіставлення функціоналу готового типового рішення і завдань замовника.

Недоліки:

Ø Складання такого ТЗ буде коштувати дорого.

Ø Складання такого ТЗ займе відносно багато часу.

Ø В даному ТЗ дуже ймовірніми будуть елементи, які ніхто не читатиме і не будет використовувати. Необхідність дотримування стандартів складання ТЗ дуже сумнівна при складанні для виконання в конкретному програмному середовищі.

РІВЕНЬ ДЕТАЛІЗАЦІЇ №3

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

Переваги:

Ø Якщо таке ТЗ складено якісно, ​​воно містить рекомендації щодо зміни бізнес-процесів на підприємстві з метою впровадження системи автоматизації. Що вже дозволить оцінити і зробити необхідний реінжиніринг БП.

У такому ТЗ вже є результати зіставлення функціоналу готового типового рішення і завдань замовника.

Недоліки:

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

РІВЕНЬ ДЕТАЛІЗАЦІЇ №4

Опис всього кола завдань. ТЗ тільки для ділянок, де виявлено завдання розробникам при порівнянні готового функціоналу типового рішення і БП замовника. Але і ці ділянки описані тільки як детальне завдання та архітектура рішення. Такий варіант ТЗ найбільш прийнятний, коли автоматизація проводиться «власними силами» - штатними співробітниками.