ІПЗ

Лекція 1
Дисципліна та викладач
Слабінога Мар’ян Остапович, кандидат технічних наук, доцент

Дисципліна “Інженерія програмного забезпечення”:

- 14 пар лекцій
- 14 пара практичних
- 3 кредитів ECTS
- залік в кінці дисципліни

Основна література, по якій будуть вестися лекції

Ronald J. Leach - Introduction to sotware engineering

Навіщо потрібна інженерія програмного забезпечення?
- Термін вперше вжитий у 1968 році на конференції НАТО
- 1970-80 роки - кожен користувач по суті був програмістом
- Програмне забезпечення з кожним роком стає складнішим
- Велика кількість факторів, методологій, підходів до розробки, тому
потрібно знати, яку комбінацію вибрати
Чи потрібна робота в команді при розробці програмного
забезпечення?
В умовах, коли у нас є багато кваліфікацій, технологій, методологій, а
програмне забезпечення складне, якісно виконувати роботу над розробкою
ПЗ складно або неможливо.
Цілі інженерії програмного забезпечення
- ефективність
- надійність (reliability)
- зручність (usability)
- можливість внесення змін (modifiability)
- портативність (portability)
- можливість тестування (testability)
- повторне використання (reusability)
- можливість підтримки програмного забезпечення (maintainability)
- взаємодія з іншими продуктами (interoperability)
- коректність
Типові завдання, які вирішує інженерія програмного
забезпечення
- аналіз проблеми
- визначення технічних вимог
- проектування ПЗ
- розробка і реалізація ПЗ
- тестування та інтеграція коду
- встановлення та “доставка” програмного продукту
- документація
- підтримка
- QA
- навчання клієнтів
- оцінка ресурсів
- керування проектами
Software life cycles
- waterfall
- rapid prototyping
- spiral
- market-driven model
- open source development model
- agile development model
Waterfall (каскадна модель)
- всі етапи розробки здійснюються
послідовно;
- неприпустима, коли вимоги
можуть суттєво змінюватися
- якщо є чітка специфікація процесу
та вимоги, то може ефективно
застосовуватися
- може застосовуватися для малих
проектів
Rapid prototyping model
- спрямована на
якнайшвидше створення
робочого прототипу
- досягнення реального
результату в найшвидші
терміни
- перші версії не завжди
виправдовують очікування
Spiral model
- Еволюція RPM
- три визначені прототипи
- не циклічний процес, а
процес розвитку, що
описується спіраллю
Open source model
- основна ціль - долучити
спільноту розробників до
свого проекту
- є ряд розробників, що
приймають рішення
щодо змін у ПЗ
- основні повідомлення
про баги, проблеми та
запити на нові
можливості дає сама
спільнота
Market driven model
- модель направлена на
якомога тіснішу взаємодію із
клієнтом
- всі принципові етапи
узгоджуються в тій чи іншій
формі із цільовою
аудиторією
Agile
- ітеративна модель розробки
- клієнт і його задоволення
роботою - найвищий пріоритет
- зміни можуть вноситися на
будь-якому етапі
- велику роль грає команда
Розробка ПЗ як інженерна дисципліна
- застосування технічних засобів (апаратних та програмних)
- постійне створення чогось нового
- точні оцінки часу та людських ресурсів, що працюють над проектом
- етапи розробки
- визначені стандарти, типові рішення, інструкції та документація
- ви орієнтуєтесь на ефективне задіяння всіх наявних ресурсів
- ви ведете контроль якості
Хороші техніки інженерії програмного забезпечення
- систематизовані методи розробки, що дозволяють повторно
використовувати ПЗ
- систематизовані підходи до оцінки та вдосконалення якості ПЗ
- систематизований підхід до розгортання середовищ розробки та
функціонування ПЗ
- систематизований підхід до оцінки необхідних для розробки ресурсів
- систематизований підхід до опрацювання зауважень та відгуків (в тому
числі bug reports, feature requests)
Деякі стандарти для компаній з розробки ПЗ
- Capability Maturity Model
- Capability Maturity Model Integration
- ISO 9001