Програмна інженерія

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

Програмна інженерія — це застосування системного, вимірюваного підходу до розробки, використання та супроводу програмного забезпечення, та дослідження цих підходів, тобто застосування принципів інженерії до програмного забезпечення. [1][2] Вперше термін «програмна інженерія (англ. software engineering)» був використаний в 1968 році на конференції з програмної інженерії, що була організована NATO.[3][4]

Дисципліни[ред.ред. код]

Програмна інженерія може бути розділена на такі дисципліни:

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

Типи моделей життєвого циклу[ред.ред. код]

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




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

Об'єктно-орієнтована інженерія вимог[ред.ред. код]

В об'єктно-орієнтованих підходах і методах розробки програмних систем головним є об'єкт. Для нього задаються вимоги за допомогою варіантів використання (use case), сценаріїв або прецедентів.

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

Керування конфігурацією[ред.ред. код]

Керування конфігурацією[5] — це ідентифікація компонентів системи, визначення функціональних, фізичних характеристик системи, апаратного і програмного забезпечення для контролю виконання, внесення змін і трасування конфігурації. Процес керування визначено як один з допоміжних процесів ЖЦ (ISO/IEC 12207), виконуваний технічним і адміністративним менеджментом проекту. При цьому складаються звіти про зміни, внесені у конфігурацію, і ступінь їхньої реалізації, а також проводиться перевірка відповідності внесених змін заданим вимогам.

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

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

Область знань «Керування конфігурацією ПЗ (Software Configuration Management — SCM)» складається з таких розділів:

— керування процесом конфігурації (Management of SMC Process),

— ідентифікація конфігурації ПЗ (Software Configuration Identification),

— контроль конфігурації ПЗ (Software Configuration Control),

— облік статусу (поведінка або стани) конфігурації ПЗ (Software Configuration Status Accounting),

— аудит конфігурації ПЗ (Software Configuration Auditing),

— керування версіями ПЗ і доставкою (Software Release Management and Delivery).

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

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

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

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

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

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

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

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

Аудит конфігурації — це діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи.

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

Базис (baseline) — формально позначений набір елементів ПЗ, зафіксований на процесах ЖЦ.

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

Складання ПЗ — об'єднання коректних елементів і конфігураційних даних у єдину виконувану програму.

ПОМИЛКОВИЙ ФОРМАТПомилка виразу: неочікуваний оператор >=== Керування інженерією програмного забезпечення === Керування інженерією ПЗ (Software Engineering Management)[6] — керування роботами команди розробників ПЗ у процесі виконання плану проекту, визначення критеріїв ефективності роботи цієї команди й оцінка процесів і продуктів проекту з використанням загальних методів планування і контролю робіт.

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

Загальні питання керування проектом містяться в ядрі знань PMBOK [12], а також у стандарті ISO/IEC 12207 — Software life cycle processes, де керування проектом розглядається як організаційний процес ЖЦ.

Область знань «Керування інженерією ПЗ (Software Engineering Management)» складається з таких розділів:

— організаційне керування (Organizational Management),

— керування процесом/проектом (Process/Project Management),

— інженерія вимірювання ПЗ (Software Engineering Measurement).

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

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

У задачі керування проектом входять також уточнення вимог, перевірка їх відповідності заданим специфікаціям характеристик якості, а також верифікація функцій проекту. Процес керування базується на планових термінах, що відображені мережними діаграмами PERT (Program Evaluation and Review Technique), СРМ (Critical Path Method). У них указуються роботи, зв'язки між ними і час виконання.

На сьогоднішній день найбільш поширена мережна діаграма PERT — граф, у вершинах якого розміщуються роботи, а дуги задають взаємні зв'язки між цими роботами. Інший тип мережної діаграми — СРМ — є становим. У його вершинах указують події, а роботи задають лініями між двома вузлами-подіями. Очікуваний час виконання робіт за допомогою мережних діаграм оцінюється середнім ваговим значенням трьох оцінок: оптимістичної, песимістичної й очікуваної, тобто імовірнісної. Ці оцінки надають експерти, що враховують обсяги виконаної роботи і відведений на неї час.

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

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

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

Інженерії вимірювання — удосконалювання процесів керування проектом; оцінювання часових витрат і вартості ПЗ, їх регулювання; визначення категорій ризиків і відстеження чинників для регулярного розрахунку ймовірностей їх виникнення; перевірка заданих у вимогах показників якості окремих продуктів і проекту в цілому [9].

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

Вимоги до програмного забезпечення[ред.ред. код]

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

Повну статтю щодо вимог до програмного забезпечення Ви можете переглянути тут — вимоги до програмного забезпечення

Прикладне (систематичне) програмування[ред.ред. код]

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

— структурний;

— об'єктно-орієнтований;

— UML-метод;

— компонентний;

— аспектно-орієнтований;

— генерувальний;

— сервісний;

— агентний й ін.

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

Структурне програмування[ред.ред. код]

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

Основу структурного програмування становлять:

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

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

До головних принципів належать:

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

— формалізація, тобто загальне методологічне вирішення проблеми;

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

— утворення ієрархічної структури даних.

При структурному аналізі застосовуються три найпоширеніші моделі структурного проектування ПС:

SADT (Structured Analysis and Design Technique) — метод структурного аналізу й техніка проектування моделі системи за допомогою функціональних діаграм ; SSADM (Structured Systems Analysis and Design Method) — метод структурного аналізу й проектування систем ; IDEF (Integrated Definition Functions) — метод визначення функціональної моделі, IDEF1 — інформаційної моделі, IDEF2 — динамічної моделі й ін. Розглянемо ці методи детальніше.

Метод функціонального моделювання SADT. Цей метод запропоновано Д.Россом і покладено в основу методології IDEF0 (Icam DEFinition), що є головною частиною програми ICAM (Інтеграція комп'ютерних і промислових технологій), проведеної з ініціативи ВПС США.

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

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

Метод SADT базується на наступних концепціях:

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

— блоків може бути від 3 до 6 на кожному рівні декомпозиції;

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

— унікальність позначок і найменувань;

— незалежність функціональної моделі від організаційної структури колективу розробників.

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

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

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

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

Загальна діаграма системи згідно з цим методом має ієрархічну структуру і містить у собі: список компонентів модельованого об'єкта; ідентифіковані групи вибраних і повторюваних компонентів; послідовність використовуваних компонентів.

Таке програмування передбачає наявність моделі ЖЦ із послідовними процесами розроблення програмного проекту, починаючи з аналізу і формування вимог для ПрО (рис. 6).

До процесів ЖЦ належать:

— стратегічне проектування та вивчення можливості виконання проекту;

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

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

— фізичне проектування структур даних відповідно до вибраної структури БД (реляційної, об'єктно-орієнтованої й ін.) та конструювання окремих компонентів, їх тестування і тестування системи в цілому;

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

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

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

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

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

Фізична специфікація містить у собі:

— специфікацію функцій і схеми реалізації компонентів функцій,

— опис процедурних і непроцедурних компонентів й інтерфейсів,

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

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

Процеси, які виконуються у SSADM, пов'язані з роботами, що керують потоками інформації трьох типів: потік робіт; санкціоновані потоки за контролем або керуванням; звіти про хід розроблення.

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

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

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

Модель потоків даних (Data Flow Model — DFM) використовується для опису процесів обробки даних у системі й містить у собі:

— ієрархічний набір діаграм потоків даних (Data Flow Diagram — DFD);

— опис елементарних процесів, потоків даних, сховищ даних і зовнішніх сутностей.

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

До об'єктів моделювання системи в SSADM належать:

1. Функції, які створюються на основі DFM і моделювання взаємозв'язків подій і сутностей для дослідження обробки даних у системі;

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

3. Дані зображаються спочатку логічною моделлю, потім фізичною, яка відображається у реляційну або об'єктно-орієнтовану БД, залежно від вибраної для проекту СКБД.

Найпоширеніші засоби моделювання даних — діаграми «сутність-зв'язок» (ER-діаграми), запропоновані Баркером, як застосування класичної ER-моделі Чена. В ER-діаграмах визначаються сутності (множини однотипних об'єктів) ПрО, їхні властивості (атрибути) і залежності (зв'язки). Сутність (Entity) — реальний або уявлюваний об'єкт, що має істотне значення для області. Кожна сутність й її екземпляр мають унікальні імена. Сутність має такі властивості:

— один або кілька атрибутів, які або належать сутності, або успадковуються через зв'язок (Relationship);

— довільну кількість зв'язків з іншими сутностями моделі.

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

Метод IDEF1 базується на концепції ER-моделювання і призначений для побудови інформаційної моделі подібно до реляційної моделі. Даний метод постійно розвивається й удосконалюється (наприклад, методологія IDEF1X-проектування, орієнтована на автоматизацію — ERwin, Design/IDEF). Основна особливість полягає в тому, що кожен екземпляр сутності може бути однозначно ідентифікований без визначення відношення з іншими сутностями. Якщо ідентифікація екземпляра сутності залежить від його відношення до іншої сутності, то сутність є залежною. Кожній сутності присвоюється унікальне ім'я і номер, які розділяють косою рискою «/» і розміщують над блоком, який позначає сутність. Обмеження на множинність зв'язку можуть означати, що для кожного екземпляра сутності-батька існує:

— нуль, один або більше пов'язаних з ним екземплярів сутності-нащадка;

— не менше ніж один або не більше ніж один пов'язаний з ним екземпляр сутності-нащадка;

— зв'язок з деяким фіксованим числом екземплярів сутності-нащадка.

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

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

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

— інформації й структури потоків, що властиві діяльності підприємства;

— правил і законів руху інформаційних потоків і принципів керування ними;

— взаємозв'язків між існуючими інформаційними потоками на підприємстві;

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

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

Інструментальна підтримка SSADM. Головний інструмент структурного проектування відповідно до процесів ЖЦ — комплекс програмних, методичних й організаційних засобів системи SSADM. Ця система прийнята державними органами Великобританії як основний системний засіб і використовується багатьма державними організаціями і в межах, і за межами країни. SSADM містить у собі п'ять головних модулів підтримки, як процесів ЖЦ з проектування ПП :

1) вивчення можливості виконання проекту (Feasibility Study Module);

2) аналіз вимог (Requirements Analysis Module);

3) специфікація вимог (Requirements Specification Module);

4) логічна специфікація системи (Logical System Specification Module);

5) фізичне проектування (Physical Design Module).

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

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

— керування розробкою проекту.

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

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

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

Проблема якості стосується двох основних аспектів:

1) сукупності функцій, що повинні задовольняти задані вимоги до функцій, надійності й продуктивності;

2) способу реалізації системи.

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

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

Ідеологія структурного проектування втілена в ряді CASE-засобів (SilverRun, Oracle Disigner, ErWin й ін.), що активно використовується на практиці.

UML-метод моделювання[ред.ред. код]

Загальна характеристика UML (Unified Modeling Language), як підход до проектування різних систем, була дана у п. 4.2.1. Тут UML розглядається детальніше, як мова візуального моделювання систем, шляхом подання у вигляді діаграм їхніх статичних і динамічних моделей на всіх процесах ЖЦ .

В основу методу покладено парадигму об'єктного підходу, при якій концептуальне моделювання проблеми полягає у побудові:

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

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

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

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

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

Діаграма класів (Class diagram) відображає онтологію домену, за змістом еквівалентна структурі інформаційної моделі методу С.Шлєєра і С.Мелора, визначає склад класів об'єктів і їх зв'язків. Діаграма задається зображенням, на якому класи позначаються поділеними на три частини прямокутниками, а зв'язки — лініями, що з'єднують прямокутники. Це відповідає візуальному зображенню понять і зв'язків між ними. Верхня частина прямокутника — обов'язкова, в ній записується ім'я класу. Друга і третя частини прямокутника визначають відповідно список операцій і атрибутів класу, що можуть мати такі специфікатори доступу:

— public (загальний) позначає операцію або атрибут, доступ до яких здійснюється з будь-якої частини програми будь-яким об'єктом системи;

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

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

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

Класи можна перебудувати в наступних відношеннях або зв'язках.

Асоціація — взаємна залежність між об'єктами різних класів, кожний з яких це рівноправний її член. Вона може позначати кількість екземплярів об'єктів кожного класу, які беруть участь у зв'язку (0 — якщо жодного, 1 — якщо один, N — якщо багато).

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

Екземпляризація — залежність між параметризованим абстрактним класом-шаблоном (template) і реальним класом, який ініціює параметри шаблону (наприклад, контейнерні класи мови С++).

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

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

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

Діаграма діяльності задає поведінку системи у вигляді певних робіт, які може виконувати система або актор і ці роботи можуть залежати або від заданих умов, або від обмежень. Ця діаграма відображає функціональну структуру системи і принципи поведінки її окремих елементів під час виконання відповідної діяльності. Приклад використання діаграми діяльності UML наведено у структурі програми «Сплата послуг» (рис. 7.).

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

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

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

Діаграма реалізації — це діаграма компонентів і розміщення. Діаграма компонентів слугує відображенню структури системи як композиції компонентів і зв'язків між ними.

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

Побудова ПС методом UML здійснюється у наступні етапи ЖЦ (рис 8.).

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

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

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

Матеріал був представлений з підручника Лаврищеовї «Програмна інженерія»

Освіта[ред.ред. код]

У 2004 році IEEE запропонувало спільноті проект SWEBOK, цей проект визначає набір знань, які повинен мати інженер з програмного забезпечення, що вчився 4 роки. Багато інженерів попадають в професію, отримавши профільну вищу освіту, або освіту в різних навчальних центрах (наприклад, «Комп'ютерна академія Шаг»). Окрім університетських програм, студенти мають можливість потрапити на практику та навчання до багатьох IT-компаній. Під час таких практик студенти отримують досвід роботи з реальними завданнями.

Методи об'єктного аналізу і моделювання[ред.ред. код]

Проектування архітектури програмних систем[ред.ред. код]

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

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

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

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

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

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

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

Примітки[ред.ред. код]

  1. SWEBOK executive editors, Alain Abran, James W. Moore ; editors, Pierre Bourque, Robert Dupuis. (2004). У Pierre Bourque and Robert Dupuis. Guide to the Software Engineering Body of Knowledge - 2004 Version. IEEE Computer Society. с. 1–1. ISBN 0-7695-2330-7. 
  2. Laplante, Phillip (2007). What Every Engineer Should Know about Software Engineering. Boca Raton: CRC. ISBN 9780849372285. Процитовано 2011-01-21. 
  3. Peter, Naur; Brian Randell(7–11 October 1968). "Software Engineering: Report of a conference sponsored by the NATO Science Committee"(PDF). {{{назва_книги}}}, Garmisch, Germany:Scientific Affairs Division, NATO. Retrieved on 2008-12-26.
  4. Randell, Brian (2001-08-10). «The 1968/69 NATO Software Engineering Reports». Brian Randell's University Homepage. The School of the Computer Sciences, Newcastle University. Архів оригіналу за 2013-07-16. Процитовано 2008-10-11. «The idea for the first NATO Software Engineering Conference, and in particular that of adopting the then practically unknown term "software engineering" as its (deliberately provocative) title, I believe came originally from Professor Fritz Bauer.» 
  5. Лаврищева К. М. «Програмна інженерія» http://www.programsfactory.univ.kiev.ua/content/books/2/29
  6. Лаврищева К. М. «Програмна інженерія» http://www.programsfactory.univ.kiev.ua/content/books/2/30

Література[ред.ред. код]

1. Методы программирования. Теория, практика, инженерия.-/Лаврищева Е. М.-Наукова думка.-2006.-471с.-(рус).
2. Методы и средства инженерии программного обеспечения.-/Лаврищева Е. М., Петрухин В. А. Москва, МФТИ.-2007.-415 с.-(рус.).
3. Основы инженерии качества программных систем.-Андон Ф. И., Коваль Г. И., Коротун Т. М., Лаврищева Е. М., Суслов В. Ю.-Киев: Академпериодика, 2007.-680 с.-(рус.).
4. Становление и развитие модульно -компонентной инженерии програм -мирования в Украине /Лаврищева Е. М.-Препринт 2008-1.-Ин-т кибернетики им. В. М. Глушкова, 33 с.-(рус.).
5. Визначення предмету-програмна інженерія.-/Лавріщева К. М.-Проблеми програмування.-Спецвипуск.-2008.-№ 2-3.-с.191-204.
6. Програмна інженерія.-/Лавріщева К. М.-Підручник.-К.: Академперіодика, 2008.-319 с.
7. Инженерия программного обеспечения. 6 издание. Соммервилл И.: Москва, Вильямс 2002.

Посилання[ред.ред. код]