Програмна інженерія: відмінності між версіями
[неперевірена версія] | [неперевірена версія] |
Вилучено вміст Додано вміст
м робот косметичні зміни |
Bunyk (обговорення | внесок) Немає опису редагування |
||
Рядок 45:
* [[Якість програмного забезпечення]]: відповідність [[Програмний продукт|програмного продукту]] вимогам.
=== Вимоги до програмного забезпечення ===▼
== Типи моделей життєвого циклу ==▼
{{main|Аналіз вимог}}
Розглянуті підходи щодо побудови різних видів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]] базуються на процесному підході до виконання програмних проектів. Вони використовувалися на практиці під час створення різних типів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]], до яких належать такі моделі: [[Водоспадна модель|каскадна]], спіральна, інкрементна, еволюційна та ін.▼
Дивіться детальніше в статті про [[життєвий цикл програмного забезпечення]].▼
Визначення вимог є нетривіальною задачею і проводиться, як правило, шляхом обговорення поглядів замовника на систему з майбутніми її розробниками.
{{section-stub}}
▲=== Типи моделей життєвого циклу ===
▲Розглянуті підходи щодо побудови різних видів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]] базуються на процесному підході до виконання програмних проектів. Вони використовувалися на практиці під час створення різних типів моделей [[Життєвий цикл програмного забезпечення|життєвого циклу програмного забезпечення]], до яких належать такі моделі: [[Водоспадна модель|каскадна]], спіральна, інкрементна, еволюційна та ін.
=== Керування конфігурацією ===
Рядок 70 ⟶ 66:
Область знань «Керування конфігурацією ПЗ (Software Configuration Management — SCM)» складається з таких розділів:
▲— облік статусу (поведінка або стани) конфігурації ПЗ (Software Configuration Status Accounting),
▲— аудит конфігурації ПЗ (Software Configuration Auditing),
▲— керування версіями ПЗ і доставкою (Software Release Management and Delivery).
Керування процесом конфігурації. Це діяльність з контролю еволюції і цілісності продукту при ідентифікації, змінах і забезпеченні звітною інформацією, що стосується конфігурації. Вона містить у собі:
▲— підтримку цілісності конфігурації, її аудит і забезпечення внесення змін в елементи конфігурації;
▲— ревізію конфігурації з метою перевірки наявності розроблених програмних або апаратних засобів і узгодження версії конфігурації з заданими вимогами;
▲— трасування змін у конфігурації на процесах супроводу й експлуатації ПЗ.
Ідентифікація конфігурації ПЗ полягає в документуванні функціональних і фізичних характеристик елементів конфігурації, а також в оформленні технічної документація на елементи конфігурації.
Рядок 97 ⟶ 85:
Облік статусу або стану конфігурації ПЗ — комплекс заходів для визначення ступеня зміни конфігурації, а також правильності внесених змін у систему при супроводі. Інформація і кількісні показники накопичуються у відповідній БД і використовуються при складанні звітності, оцінюванні якості і виконанні процесів ЖЦ.
'''
Аудит конфігурації''' — це діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи.▼
'''[[Керування версіями ПЗ]]''' — це відстеження наявної версії компонентів конфігурації; складання компонентів; створення нових версій системи на основі існуючих шляхом внесення змін у конфігурацію; узгодження версії продукту з вимогами і проведеними змінами на процесах ЖЦ; забезпечення оперативного доступу до інформації про елементи конфігурації і системи, до яких вони належать. Дане керування містить у собі такі основні поняття.▼
▲Аудит конфігурації — це діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи.
▲Керування версіями ПЗ — це відстеження наявної версії компонентів конфігурації; складання компонентів; створення нових версій системи на основі існуючих шляхом внесення змін у конфігурацію; узгодження версії продукту з вимогами і проведеними змінами на процесах ЖЦ; забезпечення оперативного доступу до інформації про елементи конфігурації і системи, до яких вони належать. Дане керування містить у собі такі основні поняття.
Базис (baseline) — формально позначений набір елементів ПЗ, зафіксований на процесах ЖЦ.
Рядок 117 ⟶ 105:
Область знань «Керування інженерією ПЗ (Software Engineering Management)» складається з таких розділів:
▲— керування процесом/проектом (Process/Project Management),
▲— інженерія вимірювання ПЗ (Software Engineering Measurement).
'''Організаційне керування''' — це планування і складання графіка робіт, підбір і керування персоналом, контроль виконання й оцінка вартості робіт згідно з прийнятими стандартами і договорами з замовником. Головним об'єктом організаційного керування проектом є персонал (навчання, мотивація й ін.), комунікації між співробітниками (зустрічі, презентації й ін.), а також попередження й усунення ризику невиконання проекту. Для керування проектом створюється спеціальна структура колективу. Фахівці розподіляються за видами робіт і розв'язують задачі проекту під керуванням менеджера з урахуванням заданої вартості і термінів розробки. Для реалізації задач проекту підбираються необхідні програмні, інструментальні й апаратні засоби.
'''Керування проектом/процесом''' — це складання плану проекту, побудова графіків робіт (мережних або часових діаграм) з урахуванням наявних ресурсів, розподіл персоналу за видами робіт у проекті, виходячи з заданих термінів і вартості їх виконання. Для ефективного керування проектом проводиться аналіз фінансової, технічної, операційної і соціальної політики організації-розробника для вибору правильної стратегії виконання робіт і контролю плану, а також проміжних продуктів (проектних рішень, діаграм UML, алгоритмів і ін.).
У задачі керування проектом входять також уточнення вимог, перевірка їх відповідності заданим специфікаціям характеристик якості, а також верифікація функцій проекту. Процес керування базується на планових термінах, що відображені мережними діаграмами PERT (Program Evaluation and Review Technique), СРМ (Critical Path Method). У них указуються роботи, зв'язки між ними і час виконання.
Рядок 135 ⟶ 121:
Під ризиком розуміють імовірність виникнення несприятливих обставин, що можуть негативно вплинути на керування розробкою (наприклад, звільнення співробітника і відсутність заміни для продовження робіт і ін.). При складанні плану проекту проводиться ідентифікація й аналіз ризику, планування непередбачених ситуацій щодо ризиків. Запобігання ризику полягає у виконанні дій, що знімають ризик (наприклад, збільшення часу розробки й ін.). Причиною появи ризику може бути реорганізація проекту, БД або транзакцій, а також помилки при виконанні ПЗ.
'''Інженерія вимірювання ПЗ''' проводиться з метою визначення окремих характеристик продуктів і процесів (наприклад, кількість рядків у продукті, помилок у специфікаціях тощо). Попередньо проводяться роботи з вибору метрик процесів і продуктів з урахуванням обставин, що впливають на вимірювання характеристик програмного продукту.
Інженерії вимірювання — удосконалювання процесів керування проектом; оцінювання часових витрат і вартості ПЗ, їх регулювання; визначення категорій ризиків і відстеження чинників для регулярного розрахунку ймовірностей їх виникнення; перевірка заданих у вимогах показників якості окремих продуктів і проекту в цілому
Проведення різного роду вимірювань — важливий принцип будь-якої інженерної діяльності. У програмному проекті результати вимірювань необхідні замовнику і споживачу для встановлення правильності реалізації проекта. Без вимірювань в інженерії ПЗ процес керування стає неефективним і перетворюється в самоціль.
▲== Вимоги до програмного забезпечення ==
▲Визначення вимог є нетривіальною задачею і проводиться, як правило, шляхом обговорення поглядів замовника на систему з майбутніми її розробниками.<br/>
== Прикладне (систематичне) програмування ==
Рядок 443 ⟶ 425:
== Література ==
▲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.
== Посилання ==
|