Програмна інженерія: відмінності між версіями

[неперевірена версія][неперевірена версія]
Вилучено вміст Додано вміст
м робот косметичні зміни
Немає опису редагування
Рядок 45:
* [[Якість програмного забезпечення]]: відповідність [[Програмний продукт|програмного продукту]] вимогам.
 
=== Вимоги до програмного забезпечення ===
== Типи моделей життєвого циклу ==
{{main|Аналіз вимог}}
Розглянуті підходи щодо побудови різних видів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]] базуються на процесному підході до виконання програмних проектів. Вони використовувалися на практиці під час створення різних типів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]], до яких належать такі моделі: [[Водоспадна модель|каскадна]], спіральна, інкрементна, еволюційна та ін.
<br/>
<br/>
<br/>
<br/>
<br/>
Дивіться детальніше в статті про [[життєвий цикл програмного забезпечення]].
 
Визначення вимог є нетривіальною задачею і проводиться, як правило, шляхом обговорення поглядів замовника на систему з майбутніми її розробниками.<br/>
== Об'єктно-орієнтована інженерія вимог ==
В об'єктно-орієнтованих підходах і методах розробки програмних систем головним є об'єкт. Для нього задаються вимоги за допомогою варіантів використання (use case), сценаріїв або прецедентів.
<br/>
<br/>
 
{{section-stub}}
Повну статтю щодо Об'єктно-орієнтована інженерія вимог і візуального підходу Ви можете також переглянути тут&nbsp;— [[життєвий цикл програмного забезпечення]]. За пунктом плану «визначення вимог до програмних систем».
 
=== Типи моделей життєвого циклу ===
Дивіться детальніше в статті про [[{{main|життєвий цикл програмного забезпечення]].}}
 
Розглянуті підходи щодо побудови різних видів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]] базуються на процесному підході до виконання програмних проектів. Вони використовувалися на практиці під час створення різних типів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]], до яких належать такі моделі: [[Водоспадна модель|каскадна]], спіральна, інкрементна, еволюційна та ін.
 
=== Керування конфігурацією ===
Рядок 70 ⟶ 66:
Область знань «Керування конфігурацією ПЗ (Software Configuration Management&nbsp;— SCM)» складається з таких розділів:
 
* керування процесом конфігурації (Management of SMC Process),
* аудитідентифікація конфігурації ПЗ (Software Configuration AuditingIdentification),
 
* ідентифікаціяконтроль конфігурації ПЗ (Software Configuration IdentificationControl),
* облік статусу (поведінка або стани) конфігурації ПЗ (Software Configuration Status Accounting),
 
* контрольаудит конфігурації ПЗ (Software Configuration ControlAuditing),
* керування версіями ПЗ і доставкою (Software Release Management and Delivery).
 
— облік статусу (поведінка або стани) конфігурації ПЗ (Software Configuration Status Accounting),
 
— аудит конфігурації ПЗ (Software Configuration Auditing),
 
— керування версіями ПЗ і доставкою (Software Release Management and Delivery).
 
Керування процесом конфігурації. Це діяльність з контролю еволюції і цілісності продукту при ідентифікації, змінах і забезпеченні звітною інформацією, що стосується конфігурації. Вона містить у собі:
 
* систематичне відстеження внесених змін в окремі складові частини конфігурації, виконання аудита змін і автоматизованого контролю за внесенням змін у конфігурацію системи або в ПЗ;
* підтримку цілісності конфігурації, її аудит і забезпечення внесення змін в елементи конфігурації;
 
* ревізію конфігурації з метою перевірки наявності розроблених програмних або апаратних засобів і узгодження версії конфігурації з заданими вимогами;
— підтримку цілісності конфігурації, її аудит і забезпечення внесення змін в елементи конфігурації;
* трасування змін у конфігурації на процесах супроводу й експлуатації ПЗ.
 
— ревізію конфігурації з метою перевірки наявності розроблених програмних або апаратних засобів і узгодження версії конфігурації з заданими вимогами;
 
— трасування змін у конфігурації на процесах супроводу й експлуатації ПЗ.
 
Ідентифікація конфігурації ПЗ полягає в документуванні функціональних і фізичних характеристик елементів конфігурації, а також в оформленні технічної документація на елементи конфігурації.
Рядок 97 ⟶ 85:
 
Облік статусу або стану конфігурації ПЗ&nbsp;— комплекс заходів для визначення ступеня зміни конфігурації, а також правильності внесених змін у систему при супроводі. Інформація і кількісні показники накопичуються у відповідній БД і використовуються при складанні звітності, оцінюванні якості і виконанні процесів ЖЦ.
'''
Аудит конфігурації'''&nbsp;— це діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи.
 
'''[[Керування версіями ПЗ]]'''&nbsp;— це відстеження наявної версії компонентів конфігурації; складання компонентів; створення нових версій системи на основі існуючих шляхом внесення змін у конфігурацію; узгодження версії продукту з вимогами і проведеними змінами на процесах ЖЦ; забезпечення оперативного доступу до інформації про елементи конфігурації і системи, до яких вони належать. Дане керування містить у собі такі основні поняття.
Аудит конфігурації&nbsp;— це діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи.
 
Керування версіями ПЗ&nbsp;— це відстеження наявної версії компонентів конфігурації; складання компонентів; створення нових версій системи на основі існуючих шляхом внесення змін у конфігурацію; узгодження версії продукту з вимогами і проведеними змінами на процесах ЖЦ; забезпечення оперативного доступу до інформації про елементи конфігурації і системи, до яких вони належать. Дане керування містить у собі такі основні поняття.
 
Базис (baseline)&nbsp;— формально позначений набір елементів ПЗ, зафіксований на процесах ЖЦ.
Рядок 117 ⟶ 105:
Область знань «Керування інженерією ПЗ (Software Engineering Management)» складається з таких розділів:
 
* організаційне керування (Organizational Management),
* керування процесом/проектом (Process/Project Management),
 
* інженерія вимірювання ПЗ (Software Engineering Measurement).
— керування процесом/проектом (Process/Project Management),
 
— інженерія вимірювання ПЗ (Software Engineering Measurement).
 
'''Організаційне керування'''&nbsp;— це планування і складання графіка робіт, підбір і керування персоналом, контроль виконання й оцінка вартості робіт згідно з прийнятими стандартами і договорами з замовником. Головним об'єктом організаційного керування проектом є персонал (навчання, мотивація й ін.), комунікації між співробітниками (зустрічі, презентації й ін.), а також попередження й усунення ризику невиконання проекту. Для керування проектом створюється спеціальна структура колективу. Фахівці розподіляються за видами робіт і розв'язують задачі проекту під керуванням менеджера з урахуванням заданої вартості і термінів розробки. Для реалізації задач проекту підбираються необхідні програмні, інструментальні й апаратні засоби.
 
'''Керування проектом/процесом'''&nbsp;— це складання плану проекту, побудова графіків робіт (мережних або часових діаграм) з урахуванням наявних ресурсів, розподіл персоналу за видами робіт у проекті, виходячи з заданих термінів і вартості їх виконання. Для ефективного керування проектом проводиться аналіз фінансової, технічної, операційної і соціальної політики організації-розробника для вибору правильної стратегії виконання робіт і контролю плану, а також проміжних продуктів (проектних рішень, діаграм UML, алгоритмів і ін.).
 
У задачі керування проектом входять також уточнення вимог, перевірка їх відповідності заданим специфікаціям характеристик якості, а також верифікація функцій проекту. Процес керування базується на планових термінах, що відображені мережними діаграмами PERT (Program Evaluation and Review Technique), СРМ (Critical Path Method). У них указуються роботи, зв'язки між ними і час виконання.
Рядок 135 ⟶ 121:
Під ризиком розуміють імовірність виникнення несприятливих обставин, що можуть негативно вплинути на керування розробкою (наприклад, звільнення співробітника і відсутність заміни для продовження робіт і ін.). При складанні плану проекту проводиться ідентифікація й аналіз ризику, планування непередбачених ситуацій щодо ризиків. Запобігання ризику полягає у виконанні дій, що знімають ризик (наприклад, збільшення часу розробки й ін.). Причиною появи ризику може бути реорганізація проекту, БД або транзакцій, а також помилки при виконанні ПЗ.
 
'''Інженерія вимірювання ПЗ''' проводиться з метою визначення окремих характеристик продуктів і процесів (наприклад, кількість рядків у продукті, помилок у специфікаціях тощо). Попередньо проводяться роботи з вибору метрик процесів і продуктів з урахуванням обставин, що впливають на вимірювання характеристик програмного продукту.
 
Інженерії вимірювання&nbsp;— удосконалювання процесів керування проектом; оцінювання часових витрат і вартості ПЗ, їх регулювання; визначення категорій ризиків і відстеження чинників для регулярного розрахунку ймовірностей їх виникнення; перевірка заданих у вимогах показників якості окремих продуктів і проекту в цілому [9].
 
Проведення різного роду вимірювань&nbsp;— важливий принцип будь-якої інженерної діяльності. У програмному проекті результати вимірювань необхідні замовнику і споживачу для встановлення правильності реалізації проекта. Без вимірювань в інженерії ПЗ процес керування стає неефективним і перетворюється в самоціль.
 
== Вимоги до програмного забезпечення ==
Визначення вимог є нетривіальною задачею і проводиться, як правило, шляхом обговорення поглядів замовника на систему з майбутніми її розробниками.<br/>
<br/>
Повну статтю щодо вимог до програмного забезпечення Ви можете переглянути тут&nbsp;— [[вимоги до програмного забезпечення]]
 
== Прикладне (систематичне) програмування ==
Рядок 443 ⟶ 425:
 
== Література ==
1.# Методы программирования. Теория, практика, инженерия.-/Лаврищева Е. М.-Наукова
 
1. Методы программирования. Теория, практика, инженерия.-/Лаврищева Е. М.-Наукова
думка.-2006.-471с.-(рус).
2.# Методы и средства инженерии программного обеспечения.-/Лаврищева Е. М., Петрухин
<br/>
2. Методы и средства инженерии программного обеспечения.-/Лаврищева Е. М., Петрухин
В.&nbsp;А.&nbsp;Москва, МФТИ.-2007.-415 с.-(рус.).
3.# Основы инженерии качества программных систем.-Андон Ф. И., Коваль Г. И., Коротун
<br/>
3. Основы инженерии качества программных систем.-Андон Ф. И., Коваль Г. И., Коротун
Т. М., Лаврищева Е. М., Суслов В. Ю.-Киев: Академпериодика, 2007.-680 с.-(рус.).
4.# Становление и развитие модульно -компонентной инженерии програм -мирования в
<br/>
4. Становление и развитие модульно -компонентной инженерии програм -мирования в
Украине /Лаврищева Е. М.-Препринт 2008-1.-Ин-т кибернетики им. В.&nbsp;М.&nbsp;Глушкова, 33
с.-(рус.).
5.# Визначення предмету-програмна інженерія.-/Лавріщева К. М.-Проблеми
<br/>
5. Визначення предмету-програмна інженерія.-/Лавріщева К. М.-Проблеми
програмування.-Спецвипуск.-2008.-№&nbsp;2-3.-с.191-204.
6.# Програмна інженерія.-/Лавріщева К. М.-Підручник.-К.: Академперіодика, 2008.-319 с.
<br/>
7.# Инженерия программного обеспечения. 6 издание. Соммервилл И.: Москва, Вильямс 2002.
6. Програмна інженерія.-/Лавріщева К. М.-Підручник.-К.: Академперіодика, 2008.-319 с.
<br/>
7. Инженерия программного обеспечения. 6 издание. Соммервилл И.: Москва, Вильямс 2002.
 
== Посилання ==