М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

• Название: ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
• Автор: М. Сидоров
• Жанр: Программирование
• ISBN: 978-966-598-626-3

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ Національний авіаційний університет

М. О. Сидоров

ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Курс лекцій Київ

Видавництво Національного авіаційного університету «НАУ-друк» 2010

УДК 004.4(042.4) ББК з 973.20-018.2я7 С 347

Рецензент: S. А. Резніченко- канд.фіз.-мат.наук (Інститут програмних систем HAH України); В, А. Дерецький - канд.фіз.-мат.наук (Інститут програмних систем HAH України); В. А. Хоменко - канд.техн. наук, доц. (Національний авіаційний університет)

Затверджено методично-редакційною радою Національного авіаційного університету (протокол № 14 від 03.07.2008p.).

Сидоров М. О.

С 347 Вступ до інженерії програмного забезпечення : курс лекцій / М.О.Сидоров. - К.: Вид-во Нац. авіац. ун-ту «НАУ-друк», 2010. -112 с.

ISBN 978-966-598-626-3

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

Для студентів напряму 6.050103 "Програмна інженерія".

УДК 004.4(042.4) ББК з 973.20-018.2я7

ISBN 978-966-598-266-3 © Сидоров М.О.. 2010

---

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

- Менеджмент - менеджери і лідери, керівники груп з розробки ПО, зобов'язані дотримуватися стичних норм у процесі розробки і супроводу програм;

- професіоналізм - програмісти зобов'язані бути чесними і підтримувати репутацію професіоналів, не забуваючи про дотримання суспільних інтересів;

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

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

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

На ринку праці використовуються різні методи і моделі, які можна розділити на дві групи:

- підбору персоналу;

- розвитку персоналу.

До моделей підбору персоналу належать такі:

- індикатор типів (модель) Майерса-Брігтса (МВТІ) - застосовується для ідентифікації чотирьох біполярних видів поведінки на основі 16 різних описів персональних властивостей особи;

- модель функціональних міжособових відносин орієнтації поведінки (FIRO-B) - застосовується для ідентифікації типів міжособових відносин шляхом вимірювання трьох аспектів, які позначаються як «залучення», «контроль» і «прихильність»;

- модель сортування темпераментів Кейрси - застосовується для тестування осіб (шляхом опитування) на основі чотирьох типів темпераментів;

- модель міжпроцесорної взаємодії Келера (РСМ) - застосовується для ідентифікації типу особи на основі шести тилів осіб з використанням транзакційного аналізу. Транзакції - це «мінісценарії» поведінки. Застосування здійснюється шляхом спостереження. Модель враховує результати змін характеристик особи впродовж життя.

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

Моделі розвитку персоналу застосовуються для підвищення кваліфікації фахівців.

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

Існують такі визначення організацій:

- система, яка обмінюється матеріалами, кадрами, робочого си­ лою і енергією з навколишнім середовищем;

- група людей, що мають певну формальну мету;

- група людей, що координують свої дії для досягнення організаційних цілей.

Структура сучасних організацій визначена в XVIII ст., у роботах французького гірського інженера Генрі Файола. Він запропонував ряд принципів менеджменту, які лежать і сьогодні в основі функціонування більшості організацій. Наприклад, розподіл праці; централізація; управління; дисципліна; ієрархічна структура; функціональне орієнтування; «стартова ніша» спеціальності; шлях рішень і просувань, який спрямований вертикально вгору зі «стартової ніші», нарівні з діями в рамках проекту, розподіленим на категорії відповідно до дисциплін і спеціальностей,

Основною характеристикою організації є її зрілість. Незрілу організацію характеризують такі аспекти:

- спеціальні процеси, імпровізовані їх виконавцями і керівництвом;

- процеси і правила, строго не дотримувані або не обов'язкові;

- високий ступінь залежності від розробників;

- можливість виникнення проблем, пов'язаних з цінами і графіками;

- невідповідність графіків функціональним властивостям, якості продукту або послуги;

- непередбачувана якість продукту. Характеристики зрілої організації такі:

- визначені, документовані і постійно удосконалювані процеси;

- документовані процеси, які є сумісними з фактичним способом виробництва;

- видима підтримка з боку керівництва і розробників;

- добре контрольована поведінка, що перевіряється;

- виконувані і використовувані вимірювання продуктів і процесів;

- виконувані технології.

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

Функціональна структура - припускає розділення співробітників за функціональними обов'язками.

Проектна структура - припускає розподіл структури за функціональними підрозділами, орієнтованими на виконання проекту.

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

4.4. Продукти

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

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

4.4.1. Комплекти розробки

В уніфікованому процесі продукти як результати виконання процесів називаються робочими продуктами і утворюють комплек­ти. Розрізняються такі комплекти: вимог, проектування, реалізації, впровадження, управління (планування та експлуатації).

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

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

Робочі продукти з комплекту вимог оцінюються і вимірюються такими комбінаціями:

- несуперечність до специфікацій версій з комплекту управління;

- несуперечність між загальною концепцією і моделями вимог;

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

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

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

Робочі продукти проектування оцінюються і вимірюються комбінацією таких чинників:

- внутрішня несуперечність і якість проектної моделі;

- несуперечність до моделей вимог;

- перехід у комплект реалізації і впровадження у відповідні нотації (наприклад, трасування, генерація початкового коду, компіляція, редагування зв'язків);

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

- зміни в поточній версії проектної моделі порівняно з попередніми версіями (тенденції до зменшення кількості дефектів і доопрацювань).

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

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