Цю статтю треба вікіфікувати для відповідності стандартам якості Вікіпедії Будь ласка допоможіть додаванням доречних вну

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

Дисципліни

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

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

Вимоги до програмного забезпечення

Докладніше: Аналіз вимог та Вимоги до програмного забезпечення

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

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

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

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

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

Керування конфігурацією — це ідентифікація компонентів системи, визначення функціональних, фізичних характеристик системи, апаратного і програмного забезпечення для контролю виконання, внесення змін і трасування конфігурації. Процес керування визначено як один з допоміжних процесів життєвого циклу (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) — керування роботами команди розробників ПЗ у процесі виконання плану проєкту, визначення критеріїв ефективності роботи цієї команди й оцінка процесів і продуктів проєкту з використанням загальних методів планування і контролю робіт.

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

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

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

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

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

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

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

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

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

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

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

— 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);

Рис. 5. Структура моделі

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.6. Життєвий цикл SSADM

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

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

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

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

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

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

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

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

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

Процеси, які виконуються у 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-метод моделювання

Докладніше: Unified Modeling Language

Освіта

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

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

Проєктування архітектури програмних систем

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

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

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

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

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

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

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

Примітки

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 .
Laplante, Phillip (2007). What Every Engineer Should Know about Software Engineering. Boca Raton: CRC. ISBN . Процитовано 21 січня 2011.
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. Процитовано 26 грудня 2008.
(10 серпня 2001). The 1968/69 NATO Software Engineering Reports. Brian Randell's University Homepage. The School of the Computer Sciences, Newcastle University. Архів оригіналу за 16 липня 2013. Процитовано 11 жовтня 2008. 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.
Лаврищева К. М. «Програмна інженерія» http://www.programsfactory.univ.kiev.ua/content/books/2/29 [ 26 лютого 2012 у Wayback Machine.]
Лаврищева К. М. «Програмна інженерія» http://www.programsfactory.univ.kiev.ua/content/books/2/30 [ 26 лютого 2012 у Wayback Machine.]

Література

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

[BoDu04-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 .

[2] Laplante, Phillip (2007). What Every Engineer Should Know about Software Engineering. Boca Raton: CRC. ISBN . Процитовано 21 січня 2011.

[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. Процитовано 26 грудня 2008.

[4] (10 серпня 2001). The 1968/69 NATO Software Engineering Reports. Brian Randell's University Homepage. The School of the Computer Sciences, Newcastle University. Архів оригіналу за 16 липня 2013. Процитовано 11 жовтня 2008. 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 [ 26 лютого 2012 у Wayback Machine.]

[6] Лаврищева К. М. «Програмна інженерія» http://www.programsfactory.univ.kiev.ua/content/books/2/30 [ 26 лютого 2012 у Wayback Machine.]