Програмна інженерія (лекції). Введення у програмну інженерію

Транскрипт

1 Вступ до програмної інженерії Зміст Лекція 1. Про предмет вивчення... 3 Програмна інженерія... 3 Програмне забезпечення... 5 Література... 6 Лекція 2. Процес розробки програмного забезпечення... 7 Процес... 7 Удосконалення процесу... 8 Класичні моделі процесу... 9 Література Лекція 3. Робочий продукт, дисципліна зобов'язань, проект Робочий продукт Дисципліна зобов'язань Проект Література Лекція 4. Архітектура ПЗ Обговорення Визначення Множинність точок зору Мова UML Література Лекція 5. Керування вимогами Проблема Види та властивості вимог Варіанти формалізації вимог Цикл роботи з вимогами Література Лекція 6. Конфігураційне управління Проблема Одиниці конфігураційного управління Управління версіями Управління збірками Поняття baseline Література Лекція 7. Тестування Управління якістю Тестування Робота з помилками Література

2 Лекція 8. Діаграмна техніка в роботі зі знаннями Метод випадки використання Ітеративний цикл автор/рецензент Карти пам'яті Література Лекція 9. MSF Історія та поточний статус Основні принципи Модель команди Інші особливості Література Лекція 10. CMMI Що таке CMMI? Література Лекція 11. «Гнучкі» (agile) методи розробки Загальне Extreme Programming Scrum Література Лекція 12. Огляд технології Microsoft Visual Studio Team System (VSTS) Огляд Склад продукту Правила інсталяції Пакет Team Explorer Лекція 13. VSTS: керування елементами робіт (Work Items) Визначення, властивості, життєвий цикл Засоби використання Лекція 14. VSTS: конфігураційне керування Система контролю версій Автоматичні збирання Лекція 15 V тестування Система відстеження помилок Модульні тести Пакети тестів Автоматичне тестування Web-додатків Лекція 16. VSTS: підтримка різних моделей процесу Підтримка шаблонів процесу існуючих шаблонів MSF for Agile Software Development Scrum

3 Лекція 1. Про предмет вивчення Програмна інженерія Чим програмування відрізняється від програми інженерії? Тим, що перше є деякою абстрактною діяльністю і може відбуватися у різних контекстах. Можна програмувати для задоволення, щоб навчитися (наприклад, на уроках, на семінарах в університеті), можна програмувати в рамках наукових розробок. А можна займатися промисловим програмуванням. Як правило, це відбувається в команді, і абсолютно точно для замовника, який платить за роботу гроші. При цьому необхідно точно розуміти, що потрібно замовнику, виконати роботу у визначені терміни і результат має бути потрібної якості того, що задовольнить замовника і за яке він заплатить. Щоб задовольнити цим додатковим вимогам, програмування «обростає» різними додатковими видами діяльності: розробкою вимог, плануванням, тестуванням, конфігураційним управлінням, проектним менеджментом, створенням різної документації (проектної, користувальницької та ін.). Розробка програмного коду передується аналізом та проектуванням (перше означає створення функціональної моделі майбутньої системибез урахування реалізації, для усвідомлення програмістами вимог та очікувань замовника; другий означає попередній макет, ескіз, план системи на папері). Трудовитрати на аналіз та проектування, а також форма представлення їх результатів сильно варіюються від видів проектів та переваг розробників та замовників. Потрібні також спеціальні зусилля щодо організації процесу розробки. Загалом це ітеративно-інкрементальна модель, коли необхідна функціональність створюється порціями, які менеджери і замовник можуть оцінити, і цим є можливість управління ходом розробки. Однак ця загальна модель має безліч модифікацій та варіантів. Розробку системи також необхідно виконувати з урахуванням зручностей її подальшого супроводу, повторного використання та інтеграції з іншими системами. Це означає, що система розбивається на компоненти, зручні у розробці, придатні повторного використання та інтеграції. А також мають необхідні характеристикипо швидкодії. Для цих компонентів ретельно проробляються інтерфейси. Сама ж система документується на багатьох рівнях, створюються правила оформлення програмного коду, тобто залишаються численні семантичні сліди, що допомагають створити і зберегти, підтримувати єдину, струнку архітектуру, одноманітний стиль, порядок. Всі ці та інші додаткові види діяльності, що виконуються в процесі промислового програмуванняі необхідні для успішного виконання замовлень і називатимемо програмною інженерією (software engineering) 1. Виходить, що так ми позначаємо, по-перше, деяку практичну діяльність, а по-друге, спеціальну галузь знання. Або іншими словами наукову дисципліну. Адже для полегшення виконання кожного окремого проекту, для можливості використовувати різноманітний позитивний досвід, досягнутий іншими командами і 1 У 70-х роках академіком А.П.Єршовим термін software engineering перекладався російською мовою як «технологія програмування». Програмна інженерія більш сучасний, але менш традиційний переклад цього терміна, запропонований наприкінці 90-х И.В.Поттосиным. У рамках даного курсукористуватимемося саме цим варіантом перекладу. 3

4 розробниками, цей самий досвід піддається осмисленню, узагальненню та належному оформленню. Так з'являються різні методи та практики (best practices) тестування, проектування, роботи над вимогами та ін., архітектурних шаблонів та ін. А також стандарти та методології, що стосуються всього процесу загалом (наприклад, MSF, RUP, CMMI, Scrum). Ось ці узагальнення і входять до програмної інженерії як до галузі знання. Необхідність у програмній інженерії як у спеціальній галузі знань були усвідомлені світовим співтовариством наприкінці 60-х років минулого століття, більш ніж на 20 років після народження самого програмування, якщо вважати таким знаменитий звіт фон Неймана "First Draft of a Report on the EDVAC", оприлюднений ним 1945 року. Народженням програмної інженерії є 1968 конференція NATO Software Engineering, м. Гарміш (ФРН), яка цілком була присвячена розгляду цих питань. У сферу програмної інженерії потрапляють усі питання та теми, пов'язані з організацією та покращенням процесу розробки ПЗ, управлінням колективу розробників, розробкою та впровадженням програмних засобів підтримки життєвого циклурозробки ПЗ. Програмна інженерія використовує досягнення інформатики, тісно пов'язана із системотехнікою, часто випереджається бізнес-реінжинірингом. Дещо докладніше про цей контекст програмної інженерії. Інформатика (computer science) це зведення теоретичних наук, заснованих на математиці та присвячених формальним основам обчислюваності. Сюди належать математичну логіку, теорію граматик, методи побудови компіляторів, математичні формальні методи, що використовуються у верифікації та модельному тестуванні тощо. Важко суворо відокремити програмну інженерію від інформатики, але загалом спрямованість цих дисциплін різна. Програмна інженерія має на меті вирішення проблем виробництва, інформатика на розробку формальних, математизованих підходів до програмування. Системотехніка (system engineering) поєднує різні інженерні дисципліни з розробки різноманітних штучних системенергоустановок, телекомунікаційних систем, вбудованих систем реального часу та ін. Дуже часто програмне забезпечення виявляється частиною таких систем, виконуючи завдання управління відповідного обладнання. Такі системи називаються програмно-апаратними, і беручи участь у їх створенні, програмісти змушені глибоко розумітися на особливостях відповідної апаратури. Бізнес-реінжиніринг (business reengineering) у широкому розумінні означає модернізацію бізнесу у певній компанії, впровадження нових практик, що підтримуються відповідними, новими інформаційними системами. При цьому акцент можливо як на внутрішньому перебудові компанії так і на розробці нового клієнтського сервісу (як правило, ці питання взаємопов'язані). Бізнесреінжиніринг часто передує розробку та впровадження інформаційних систем на підприємстві, оскільки потрібно спочатку навести певний порядок у діловодстві, а потім закріпити його інформаційною системою. Зв'язок програмної інженерії (як галузі практичної діяльності) з інформатикою, системотехнікою та бізнес-реінжинірингом показаний на рис

5 Мал. 1.1 Програмне забезпечення Визначення. Будемо розуміти під програмним забезпеченням (ПЗ) безліч логічних розпоряджень, що розвиваються в часі, за допомогою яких деякий колектив людей управляє і використовує багатопроцесорну і розподілену системуобчислювальних пристроїв. Це визначення, дане Харальдом Мілсом, відомим фахівцем у галузі програмної інженерії з компанії IBM, містить у собі таке. 1. Логічні приписи це як самі програми, а й різна документація (наприклад, з експлуатації програм) і ширше певна система відносин для людей, використовують ці програми у межах деякого процесу діяльності. 2. Сучасне ПЗ призначене, як правило, для одночасної роботи з багатьма користувачами, які можуть бути значно віддалені один від одного у фізичному просторі. Таким чином, обчислювальне середовище (персональні комп'ютери, сервери і т.д.), в якому функціонує, виявляється розподіленою. 3. Завдання розв'язувані сучасним ПЗ, часто вимагають різних обчислювальних ресурсів у силу різної спеціалізації цих завдань, через великий обсяг виконуваної роботи, і навіть з міркувань безпеки. Наприклад, з'являється сервер бази даних, сервер додатків тощо. Таким чином, обчислювальне середовище, в якому функціонує, виявляється багатопроцесорною. 4. ПЗ розвивається у часі виправляються помилки, додаються нові функції, випускаються нові версії, змінюється його апаратна база. Властивості. Таким чином, ПЗ є складною динамічною системою, що включає технічні, психологічні та соціальні аспекти. ПО помітно відрізняється з інших видів систем, створюваних (створених) людиною механічних, соціальних, наукових та інших., і має такі особливості, виділені Фредериком Бруксом у його знаменитої статті «Срібної кулі немає». 1. Складність програмних об'єктів, яка залежить від їх розмірів. Як правило, більше ПЗ (більша кількість користувачів, більший обсяг оброблюваних даних, більш жорсткі вимоги щодо швидкодії тощо) з аналогічною функціональністю це інше ПЗ. Класична наука будувала прості моделіскладних явищ, і це вдавалося, оскільки складність була характеристичною рисою аналізованих явищ. (Порівняння програмування саме з наукою, а не з театром, кінематографом, спортом та іншими галузями людської діяльності виправдано, оскільки воно виникло, 5

6 головним чином з математики, а перші його плоди комп'ютери, мови програми призначалися для використання при наукових розрахунках. Крім того, більшість програмістів мають природничо, математичну або технічну освіту. Таким чином, парадигми наукового мислення широко використовуються при програмуванні явно або неявно. з якими згодом воно має взаємодіяти. Ці інтерфейси погано піддаються стандартизації, оскільки ґрунтуються на численних і погано формалізованих людських угодах. 3. Змінність ПЗ легко змінити і, як наслідок, вимоги до нього постійно змінюються у процесі розробки. Це створює багато додаткових труднощів при його розробці та еволюції. 4. Нематеріальність 2 ПЗ неможливо побачити, воно віртуальне. Тому, наприклад, важко скористатися технологіями, заснованими на попередньому створенні креслень, які успішно використовуються в інших промислових галузях (наприклад, у будівництві, машинобудуванні). Там на кресленнях у схематичному вигляді відтворюються геометричні форми об'єктів, що створюються. Коли об'єкт створено, ці форми можна побачити. А на чому ми ґрунтуємося, коли зображаємо ПЗ? Література 1. H. Mills. Management of software engineering Part I: Principles of software engineering. // IBM System Journal, Vol. 38, No 2&3, 1999, pp F. Brooks. No Silver Bullet. Information Proceeding of the IFIP 10 th World Computing Conference pp / Українська переклад: Ф. Брукс. Міфічний людиномісяць або як створюються програмні системи. СПб Символ, с. 3. I.Sommerville Software Engineering. 6 th edition. Addison-Wesley, p. / Російський переклад: І.Соммервілл. Інженерія програмного забезпечення. Видавничий дім Вільямс, с. 4. А.П.Єршов. Технологія розроблення систем програмування. // А.П.Єршов. Вибрані праці. ВО Наука. Новосибірськ C Поттосін І.В. Програмна інженерія: зміст, думки та тенденції. // Програмування N 4. З Д.В.Кознов. Введення у програмну інженерію. Частина I. Вид-во Санкт-Петербурзького ун-ту, 2005, 43 с. 2 Тут ми трохи поправили класика, у нього була незримість.

7 Лекція 2. Процес розробки програмного забезпечення Без процесу не зрозуміти. З ділової листування менеджера програмного проекту. Процес Як ми працюємо, яка послідовність наших кроків, які норми та правила у поведінці та роботі, який регламент відносин між членами команди, як проект взаємодіє із зовнішнім світом тощо? Все це разом ми схильні називати процесом. Його усвідомлення, вибудовування та покращення - основа будь-якої ефективної групової діяльності. Невипадково тому, що виявився однією з основних понять програмної інженерії. Центральним об'єктом вивчення програмної інженерії є процес створення ПЗ безліч різних видівдіяльності, методів, методик і кроків, що використовуються для розробки та еволюції ПЗ та пов'язаних з ним продуктів (проектних планів, документації, програмного коду, тестів, документації користувача тощо). Однак на сьогоднішній день не існує універсального процесу розробки програмного забезпечення набору методик, правил і приписів, що підходять для програмного забезпечення будь-якого виду, для будь-яких компаній, для команд будь-якої національності. Кожен поточний процес розробки, який здійснюється деякою командою в рамках певного проекту, має велику кількість особливостей та індивідуальностей. Однак доцільно перед початком проекту спланувати процес роботи, визначивши ролі та обов'язки у команді, робочі продукти (проміжні та фінальні), порядок участі у їх розробці членів команди тощо. Будемо називати цей попередній опис конкретним процесом, відрізняючи його від плану робіт, проектних специфікацій тощо. Наприклад, у системі Microsoft Visual Tem System виявляється шаблон процесу, який створюється або адаптується (у разі використання стандартного) перед початком розробки. У VSTS існують заготівлі для конкретних процесів на базі CMMI, Scrum та ін. У рамках компанії можлива та корисна об'єднання та стандартизація всіх поточних процесів, яку називатимемо стандартним процесом. Останній, таким чином, виявляється деякою базою даних, що містить наступне: інформацію, правила використання, документацію та інсталяційні пакети засобів розробки, що використовуються в проектах компанії (систем версійного контролю, засобів контролю помилок, засобів програмування різних IDE, СУБД тощо) ; опис практик розробки проектного менеджменту, правил роботи із замовником тощо; шаблонів проектних документів технічних завдань, проектних специфікацій, тестових планів тощо. та ін. Також можлива стандартизація процедури розробки конкретного процесу як «вирізки» зі стандартного. Основна ідея стандартного процесукурсування всередині компанії передового досвіду, і навіть уніфікація засобів розробки. Дуже часто в компаніях різні департаменти та проекти сильно відрізняються за зрілістю процесу розробки, а також утруднене повторне використання передового досвіду. Крім того, трапляються, що компанія використовує кілька засобів паралельних інструментів розробки, наприклад, СУБД засобу версійного контролю. Іноді це буває виправдано (наприклад, такі вимоги замовника), часто це необхідно.

8 Java.NET (велика компетентність офшорної компанії дозволяє їй купувати ширший спектр замовлень). Але часто це довільний вибір самих розробників. У будь-якому випадку, така множинність суттєво ускладнює міграцію фахівців із проекту до проекту, використання результатів одного проекту до іншого тощо. Однак при організації стандартного процесу необхідно стежити, щоб стандартний процес не виявився лише формальним, бюрократичним апаратом. Поняття стандартного процесу введено та докладно описано у підході CMMI. Слід зазначити, що наявність стандартного процесу свідчить про наявність «єдиної волі» в організації, що існує саме на рівні процесу. На рівні продажу, бухгалтерії та інших. звичних всім підприємств процесів і активів єдність здійснити не складно. А ось на рівні процесів розробки дуже часто кожен проект виявляється сам по собі (особливо в офшорних проектах) «плинність» захоплює та ізолює проекти один від одного дуже міцно. Вдосконалення процесу Визначення. Удосконалення процесу (software process improvement) це діяльність зі зміни існуючого процесу (як поточного, в рамках одного проекту, так і стандартного, для всієї компанії) з метою покращення якості продуктів та/або зниження ціни та часу їх розробки. Причини актуальності цієї діяльності для компаній-виробників ПЗ ось у чому. 1. Відбувається швидка зміна технологій розробки ПЗ вимагає вивчення та впровадження нових засобів розробки. 2. Спостерігається швидке зростання компаній та їх вихід на нові ринки, що вимагає нової організаціїробіт. 3. Має місце висока конкуренція, яка потребує пошуку ефективніших, економічніших способів розробки. Що і як можна покращувати. 1. Перехід нові засоби розробки, мови програмування тощо. 2. Покращення окремих управлінських та інженерних практик тестування, управління вимогами та ін. 3. Повна, комплексна перебудова всіх процесів у проекті, департаменті, компанії (відповідно, наприклад, з CMMI). 4. Сертифікація компанії (CMM/CMMI, ISO 9000 та ін.). Ми відокремили п. 3 від п. 4 тому, що на практиці 4 далеко не завжди означає дійсну творчу роботу з поліпшення процесів розробки програмного забезпечення, а часто зводиться до підтримки відповідного документообігу, необхідного для отримання сертифікації. Сертифікат потім використовується як засіб, козир у боротьбі за замовлення. Головна складність реального вдосконалення процесів у компанії полягає в тому, що вона при цьому повинна працювати і створювати програмне забезпечення, її не можна «закрити на облік». Звідси випливає ідея безперервного покращення процесу, так би мовити, малими порціями, щоб не так болісно. Це розумніше, що нові технології розробки, що з'являються на ринку, а також розвиток вже існуючих потрібно постійно відстежувати. Ця стратегія, зокрема, відображена у стандарті вдосконалення процесів розробки CMMI. 8

9 Pull/Push стратегії. У контексті впровадження інновацій у виробничі процеси бізнес-компаній (не обов'язково компаній зі створення програмного забезпечення) існують дві наступні парадигми. 1. Organization pull інновації спрямовані на вирішення конкретних проблем компанії. 2. Technology push – широкомасштабне впровадження інновацій зі стратегічних міркувань. Замість конкретних проблем, які будуть вирішені після впровадження інновації, у цьому випадку розглядаються показники компанії (ефективність, продуктивність, річний обіг коштів, збільшення вартості акцій публічної компанії ), які будуть збільшені, покращені після впровадження інновації. При цьому передбачається, що будуть автоматично вирішені численні приватні проблеми організації, у тому числі й ті, про які зараз нічого не відомо. Приклад використання стратегії organization pull впровадження нових засобів тестування у ситуації, коли високі вимоги щодо якості у проекті, або коли якість програмної системи не задовольняє замовника. Приклад використання стратегії технології перемикання компанії з засобів структурної розробки на об'єктно-орієнтовані. Ще один приклад використання тієї ж стратегії запровадження стандартів якості ISO 9000 або CMMI. В обох цих випадках компанія не вирішує якусь одну проблему чи низку проблем вона хоче радикально змінити ситуацію, вийти на нові рубежі тощо. Проблеми застосування стратегії technology push у тому, що потрібна глобальна перебудова процесу. Але компанію не можна закрити на реконструкцію за цей час становище на ринку може виявитися зайнятим конкурентами, акції компанії можуть впасти і т.д. Таким чином, впровадження інновацій, як правило, відбувається паралельно із звичайною діяльністю компанії, поетапно, що у випадку з технологією push пов'язане з великими труднощами та ризиками. Використання стратегії organization pull менш ризиковано, внесені нею зміни у процес менш глобальні, локальніші. Але й вигод такі інновації приносять менше, ніж вдалі впровадження відповідно до стратегії technology push. Необхідно також відзначити, що існують проблеми, які неможливо усунути точковими переробками процесу, тобто необхідно застосовувати стратегію technology push. Наведемо як приклад процес супроводу та розвитку сімейства програмних продуктів, що зайшов у глухий кут, компанія зазнає великих збитків, супроводжуючи вже поставлені продукти, інструментальні засоби проекту безнадійно застаріли і перебувають у жалюгідному стані, менеджмент засмучений, всі спроби керівництва змінити процес наштовхуються на нерозуміння колективу, сварки та Конфлікти. Можливо, що в такому разі без революції не обійтись. Ще одна відмінність обох стратегій: у випадку з організацією пуль, як правило, повернення інвестицій від впровадження відбувається швидше, ніж у випадку з технологією push. Класичні моделі процесу Визначення моделі процесу. Процес створення програмного забезпечення не є однорідним. Той чи інший метод розробки, зазвичай, визначає деяку динаміку розгортання тих чи інших видів діяльності, тобто, визначає модель процесу (process model). я

10 Модель є гарною абстракцією різних методів розробки ПЗ, дозволяючи лаконічно, стисло та інформативно їх уявити. Проте, сама ідея моделі процесу є однією з ранніх програмної інженерії, коли вважалося, що вдала модель найголовніше, що сприяє успіху розробки. Пізніше прийшло усвідомлення, що існує безліч інших аспектів (принципи управління та розробки, структура команди тощо), які повинні бути визначені узгоджено один з одним. І почали розвиватися інтегральні методології розробки. Тим не менш, існує кілька класичних моделей процесу, які корисні на практиці і які будуть розглянуті нижче. Фази та види діяльності. Говорячи про моделі процесів, необхідно розрізняти фази та види діяльності. Фаза (phase) це певний етап процесу, що має початок, кінець та вихідний результат. Наприклад, фаза перевірки здійсненності проекту, здавання проекту тощо. Фази слідують один за одним у лінійному порядку, характеризуються наданням звітності замовнику та, часто, виплатою грошей за виконану частину роботи. Рідко який замовник погодиться вперше побачити результати тільки після завершення проекту. З іншого боку, підрядники вважають за краще отримувати гроші поступово, у міру того, як виконуються окремі частини роботи. Таким чином, з'являються фази, що дозволяють створювати та пред'являти проміжні результати проекту. Фази корисні також щодо взаємодії із замовником з їх допомогою можна синхронізувати діяльність різних робочих груп, а також відстежувати просування проекту. Прикладами фаз може бути узгодження із замовником технічного завдання, реалізація певної функціональності, етап розробки, що закінчується здаванням системи на тестування або випуском альфаверсії. Вид діяльності (activity) це певний тип роботи, що виконується у процесі розробки програмного забезпечення. Різні види діяльності часто вимагають різних професійних навичок і виконуються різними фахівцями. Наприклад, управління проектом виконується менеджером проекту, кодування програмістом, тестування тестувальником. Є види діяльності, які можуть виконуватися одними і тими ж фахівцями, наприклад, кодування та проектування (особливо в невеликому проекті) часто виконують одні й ті ж люди. У межах однієї фази може виконуватися багато різних видів діяльності. Крім того, один вид діяльності може виконуватися на різних фазах наприклад, тестування: на фазі аналізу та проектування можна писати тести та налагоджувати тестове оточення, при розробці та перед здаванням проводити, власне, саме тестування. На даний момент для складного програмного забезпечення використовуються багатовимірні моделі процесу, в яких відокремлення фаз від видів діяльності суттєво полегшує управління розробкою програмного забезпечення. Види діяльності, власне, присутні, під різними назвами, у кожному методі розробки ПЗ. У RUP вони називаються робочими процесами (work flow), CMM ключовими областями процесу (key process area). Ми зберігатимемо традиційні назви, прийняті в тому чи іншому методі, щоб не створювати плутанини. Водоспадну модель було запропоновано у 1970 році Вінстоном Ройсом. Фактично, вперше в процесі розробки ПЗ були виділені різні кроки розробки та похитнулися примітивні уявлення про розробку ПЗ у вигляді аналізу системи та її кодування. 10

11 Були визначені наступні кроки: розробка системних вимог, розробка вимог до ПЗ, аналіз, проектування, кодування, тестування, використання див. рис Ще однією перевагою цієї моделі стало обмеження можливості повернення на довільний крок назад, наприклад, від тестування до аналізу, від розробки роботу над вимогами тощо. Наголошувалося, що такі повернення можуть катастрофічно збільшити вартість проекту та терміни його виконання. Наприклад, якщо при тестуванні виявляються помилки проектування або аналізу, їх виправлення часто призводить до повної переробки системи. Цією моделлю допускалися повернення тільки попередній крок, наприклад, від тестування до кодування, від кодування до проектування тощо. Розробка системних вимог Розробка вимог до ПЗ Аналіз Проектування Кодування Тестування Використання Рис Нарешті, в рамках цієї моделі було введено прототипування, тобто пропонувалося розробляти систему двічі, щоб зменшити ризики розробки. Перша версія прототипу дозволяє побачити основні ризики та обґрунтовано прийняти головні архітектурні рішення. На створення прототипу відводилося до третини часу всієї розробки. У роках минулого століття ця модель міцно вкоренилася в розробці ПЗ через свою простоту і подібність до моделей розробки інших, не програмних систем. Надалі, у зв'язку з розвитком програмної інженерії та усвідомленням ітеративного характеру процесу розробки ПЗ ця модель активно критикувалася практично кожним автором відповідних статей та підручників. Стало загальноприйнятою думка, що вона не відображає особливостей розробки програмного забезпечення. Недоліками водоспадної моделі є: ототожнення фаз та видів діяльності, що тягне за собою втрату гнучкості розробки, зокрема, труднощі підтримки ітеративного процесу розробки; вимога повного закінчення фази-діяльності, закріплення результатів як докладного вихідного документа (технічного завдання, проектної специфікації); однак досвід розробки програмного забезпечення показує, що неможливо 11

12 повністю завершити розробку вимог, дизайн системи та ін. все це схильне до змін; і причини тут у тому, що рухоме оточення проекту, а й у тому, що заздалегідь не вдається точно визначити і сформулювати багато рішень, вони прояснюються і уточнюються лише згодом; інтеграція всіх результатів розробки відбувається наприкінці, внаслідок чого інтеграційні проблеми дають себе знати занадто пізно; користувачі та замовник не можуть ознайомитися з варіантами системою під час розробки, і бачать результат лише наприкінці; тим самим вони не можуть вплинути на процес створення системи, і тому збільшуються ризики нерозуміння між розробниками та користувачами/замовником; модель нестійка до збоїв у фінансуванні проекту або перерозподілу коштів, розпочата розробка фактично не має альтернатив по ходу справи. Однак дана модель продовжує використовуватися на практиці для невеликих проектів або розробки типових систем, де ітеративність негаразд затребувана. З її допомогою зручно відстежувати розробку та здійснювати поетапний контроль за проектом. Ця модель також часто використовується в офшорних проектах3 з погодинною оплатою праці. Водоспадна модель увійшла як складова частина в іншій моделі та методології, наприклад, в MSF. Спіральна модель була запропонована Бері Боємом у 1988 році для подолання недоліків водоспадної моделі, насамперед для кращого управлінняризиками. Згідно з цією моделлю розробка продукту здійснюється по спіралі, кожен виток якої є певною фазою розробки. На відміну від водопадної моделі в спіральній немає зумовленого та обов'язкового набору витків, кожен виток може стати останнім при розробці системи, при його завершенні складаються плани наступного витка. Нарешті, виток є саме фазою, а чи не видом діяльності, як і водопадної моделі, у його рамках може здійснюватися багато різних видів діяльності, тобто модель є двовимірною. Послідовність витків може бути такою: на першому витку приймається рішення про доцільність створення ПЗ, на наступному визначаються системні вимогипотім здійснюється проектування системи і т.д. Витки можуть мати інші значення. Кожен виток має таку структуру (сектори): визначення цілей, обмежень та альтернатив проекту; оцінка альтернатив, оцінка та дозвіл ризиків; можливе використання прототипування (у тому числі створення серії прототипів), симуляція системи, візуальне моделювання та аналіз специфікацій; фокусування на ризикових частинах проекту; розробка та тестування тут можлива водоспадна модель або використання інших моделей та методів розробки ПЗ; планування наступних ітерацій аналізуються результати, плани та ресурси на подальшу розробку, приймається (або не приймається) рішення про новий виток; аналізується, чи є сенс продовжувати розробляти систему чи ні; розробку можна призупинити, наприклад, через збоїв у фінансуванні; спіральна модель дозволяє це зробити коректно. 3 Від англійської offshore поза берегом, у розширеному тлумаченні поза однією країною. 12

13 Окрема спіраль може відповідати розробці деякої програмної компоненти або внесення чергових зміну продукт. Таким чином, у моделі може з'явитися третій вимір. Спіральну модель недоцільно застосовувати у проектах із невеликим ступенем ризику, з обмеженим бюджетом, для невеликих проектів. Крім того, відсутність хороших засобів прототипування може зробити незручним використання спіральної моделі. Спіральна модель не знайшла широкого застосування в індустрії і важлива, скоріше в історико-методологічному плані: вона є першою ітеративною моделлю, має гарну метафору спіраль, і, подібно до водоспадної моделі, використовувалася надалі при створенні інших моделей процесу та методологій розробки ПЗ. Література 1. I.Sommerville Software Engineering. 6th edition. Addison-Wesley, p. / Російський переклад: І.Соммервілл. Інженерія програмного забезпечення. Видавничий дім "Вільямс", c. 2. W.Humphrey. Managing the Software Process. Addison-Wesley, p. 3. R. W. Zmud. An Examination of «Push-Pull» Theory пристосований до Process Innovation in Knowledge Work, Management Science, Vol. 30 (6), 1984, pp B. Boehm. A Spiral Model of Software Development and Enhancement. // IEEE Computer, vol.21, # 5, May P W. W. Royce. Managed the Development of Large Software Systems. Proceedings of IEEE WESCON, August P Перевидана: Proceedings of the 9th International Software Engineering Conference, Computer Society Press, Р. Т. Фатрепп, Д. Ф. Шафер, Л. І. Шафер. Управління програмними проектами: досягнення оптимальної якостіпри мінімумі витрат. Вид. будинок «Вільямс» с. 7. Д.В.Кознов. Мови візуального моделювання: проектування та візуалізація програмного забезпечення. Вид. СПбГУ, с. 8. Д.В.Кознов. Введення у програмну інженерію. Частина I. Вид-во Санкт-Петербурзького ун-ту, 2005, 43 с. 9. Д. Ахен, А. Клауз, Р. Тернер. CMMI: комплексний підхід до вдосконалення процесів. Пер з англ. М.: МФК с. 10. CMMI для розвитку, Version 1.2. CMMI-DEV (Version 1.2, August 2006). Carnegie Mellon University Software Engineering Institute (2006). Retrieved on 22 August

14 Лекція 3. Робочий продукт, дисципліна зобов'язань, проект У силу творчого характеру програмування, суттєвої молодості учасників розробки ПЗ виявляються актуальними деякі питання звичайного промислового виробництва, що стали давно спільним місцем. Насамперед, це дисципліна зобов'язань та робочий продукт. Дані знання, будучи освоєними на практиці, надзвичайно корисні в командної роботи. Крім того, широко застосовувані зараз на практиці методології розробки програмного забезпечення, підтримані відповідним програмним інструментарієм, активно використовують ці поняття, уточнюючи та конкретизуючи їх. Робочий продукт Однією із суттєвих умов для керованості промислового процесу є наявність окремо оформлених результатів роботи як в остаточному постачанні так і проміжних. Ці окремі результати у складі загальних результатівробіт допомагають ідентифікувати, планувати та оцінювати різні частини результату Проміжні результати допомагають менеджерам різних рівнів відстежувати процес втілення проекту, замовник отримує можливість ознайомитись з результатами задовго до закінчення проекту. Більше того, самі учасники проекту у своїй щоденній роботі отримують простий та ефективний спосіб обміну робочою інформацією обмін результатами. Таким результатом є робочий продукт (work product) будь-який артефакт, вироблений процесі розробки ПЗ, наприклад, файл чи набір файлів, документи, складові продукту, сервіси, процеси, специфікації, рахунки тощо. Частина підсумкової поставки Проміжний Буває Робочий продукт Напрмієр Користувальницька документація Компоненти програмного забезпечення

15 Ключова різниця між робочим продуктом і компонентом ПЗ полягає в тому, що перший необов'язково матеріал і відчутний (not to be engineered), хоча може бути таким. Нематеріальний робочий продукт це, як правило, деякий налагоджений процес, промисловий процес виробництва якої-небудь продукції, навчальний процес в університеті (на факультеті, на кафедрі) тощо. Робочий продукт зовсім не обов'язково є складовоюпідсумкового постачання. Наприклад, налагоджений процес тестування системи не поставляється замовнику разом із самою системою. Уміння управляти проектами (у сфері програмування) багато в чому пов'язані з мистецтвом визначати необхідні робочі продукти, наполягати з їхньої створенні й у термінах вести приймання проміжних етапів роботи, організовувати синхронізацію різних робочих груп і окремих фахівців. Багато методологій включають опис специфічних робочих продуктів, що використовуються в процесі CMMI, MSF, RUP та ін. Наприклад, в MSF це програмний код, діаграми додатків і класів (application diagrams і class diagrams), план ітерацій (iteration plan), модульний тест (unit test) та ін. Для кожного з них точно описано зміст, відповідальні за розробку, місце у процесі та ін. Зупинимося трохи докладніше на проміжних робочих продуктах. Компонента ПЗ, створена у проекті одним розробником і надана використання іншого розробнику, виявляється робочим продуктом. Її треба мінімально протестувати, поправити імена інтерфейсних класів і методів, можливо, прибрати зайве, що не має відношення до функціональності даної компоненти, краще розділити public і private, і т.д. Тобто зробити деяку додаткову роботу, яку, можливо, розробник і став робити, якби продовжував використовувати компоненту лише сам. Обсяг цих додаткових робіт істотно зростає, якщо компонент повинен бути представлений для використання в розробці, наприклад, в інший центр розробки (наприклад, іноземним партнерам, що є частою ситуацією в офшорній розробці). Отже, виготовлення хороших проміжних робочих продуктів дуже важливе для успішності проекту, але потребує додаткової роботи від їхніх авторів. Працювати одному, не надаючи робочих продуктів, легше і для багатьох краще. Але робота у команді вимагає накладних витрат, зокрема у вигляді витрат за створення проміжних робочих товарів. Звичайно, якість цих продуктів і трудовитрати на їхнє виготовлення сильно варіюються залежно від ситуації, але тут важливо розуміти сам принцип. Отже, підсумуємо, що проміжний робочий продукт повинен обов'язково мати ясну мету і конкретних користувачів, щоб мінімізувати витрати на його створення. 15

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

17 навчання тощо. Існують окремі люди, яким ця дисципліна внутрішньо чужа незалежно від їхньої діяльності. З іншого боку, люди, які освоїли цю дисципліну, часто прагнуть застосовувати її в інших сферах життя та людських відносин, що виявляється не завжди виправданим. Наголосимо, що ця дисципліна є далеко не єдиною моделлю відносин між людьми. Як приклад можна розглянути відносини у сім'ї чи дружбу, що, очевидно, неможливо знайти виражені дисципліною зобов'язань. Так, замість точності та пунктуальності у цих відносинах важливе емоційно-чуттєве співпереживання, без якого вони неможливі. Дисципліні зобов'язань приділяється багато уваги у рамках MSF, оскільки там у моделі команди немає лідера, начальника. Ця дисципліна реалізована також у Scrum: Scrum-команда має багато свобод, і тому велику відповідальність. Регламентуються також правила дій, коли зобов'язання не можуть бути виконані такою командою. Проект Класичне операційне розподіл праці йде від Адама Сміта і є суттю масового індустріального виробництва. Тобто існує чітко налагоджений процес роботи і є галузі спеціалізації один цех точить, інший стругає, третій збирає, четвертий фарбує і т.д. Пропускна здатність такого виробництва набагато перевершує виконання всієї роботи однією людиною чи однією групою. Таким чином, у XIX столітті операційний поділ праці став основою мануфактур, що витіснили індивідуальне, ремісниче виробництво. На початку XX століття цю структуру робіт перенесли і на управління, тобто численні менеджери контролювали. окремі ділянкиробіт. Проте високий рівень складності низки завдань у промисловості та бізнесі не дозволяє (на щастя!) так працювати скрізь. Існує багато творчих, нових завдань, де, можливо, в майбутньому і вдасться створити конвеєри, але в даний момент для їх вирішення потрібна суттєва концентрація сил і енергії людей. несподівані рішення, а також удача та легка рука. Це і є сфера проектів. Це унікальна (на відміну від традиційної поопераційної промислового виробництва) діяльність, що має початок і кінець у часі, спрямована на досягнення певного результату/ціль, створення певного, унікального продукту або послуги, при заданих обмеженнях за ресурсами та термінами, а також вимогам до якості і допустимого рівняризику. Зокрема, розробка програмного забезпечення є переважно проектною областю. Необхідно розрізняти проекти промислові та творчі. У них різні принципиуправління. Складність промислових проектів у великій кількості різних організацій, підприємств та відносної унікальності самих робіт. Приклад будівництва багатоповерхового будинку. Сюди ж відносяться різні міжнародні проекти і не тільки промислові освітні, культурні та ін. Завдання в управлінні такими проектами це все охопити, все проконтролювати, нічого не забути, все звести докупи, домогтися руху, причому руху узгодженого. Творчі проекти характеризуються абсолютною новизною ідеї новий сервісабсолютно новий програмний продукт, якого ще не було на ринку, проекти в галузі мистецтва та науки. Будь-який бізнес-початківець, як правило, є таким ось творчим проектом. Причому новизна у подібних проектах не тільки абсолютна такого ще не було. Таке, може, вже й було, але не снами, командою проекту. Тобто є величезний обсяг відносної новизни для самих людей, які втілюють цей проект. 17

18 Проекти з розробки програмного забезпечення знаходяться між цими двома полюсами, займаючи в цьому просторі різне положення. Часто вони складні тому, що об'ємні і знаходяться на стику різних дисциплін. цільового бізнесу, куди має вбудуватися програмний продукт, та складного, нетривіального програмування. Часто сюди додається ще розробка унікального електронно-механічного обладнання. З іншого боку, оскільки програмування активно просувається в різні сферилюдської діяльності, то відбувається це шляхом створення абсолютно нових, унікальних продуктів, і їх розробка та просування мають всі риси творчих проектів. Управління проектами (project management) сфера діяльності, в ході якої, в рамках певних проектів, визначаються і досягаються чіткі цілі при знаходженні компромісу між обсягом робіт, ресурсами (такими як час, гроші, праця, матеріали, енергія, простір та ін.), часом, якістю та ризиками. Зауважимо кілька важливих аспектів управління проектами. Stakeholedrs це люди/сторони, які не беруть участь безпосередньо в проекті, але впливають на нього та зацікавлені в його результатах. Це можуть бути майбутні користувачі системи (наприклад, у ситуації, коли вони і замовник це не те саме), вище керівництво компанії-розробника і т.д. Ідентифікація всіх stakeholders та грамотна робота з ними важлива складова успішного проектного менеджменту Project scope це межі проекту. Це дуже важливе поняття для програмних проектів через мінливість вимог. Часто буває, що розробники починають створювати одну систему, а потім поступово вона перетворюється на іншу. Причому для менеджерів з продажу, а також замовника нічого радикально не сталося, а з погляду внутрішнього пристрою ПЗ, технологій, алгоритмів реалізації, архітектури все радикально змінюється. За подібними тенденціями має стежити та грамотно з ними розбиратися проектний менеджмент. Компроміси найважливіший аспект управління програмними проектами через узгодженість ПЗ. Важливо не втратити всі узгоджені параметри та сторони та знайти прийнятний компроміс. Одна з технік управління компромісами буде розказана в контексті вивчення методології MSF. Під час розробки програмних проектів, слідуючи MSF 3.1, важливі такі області управління. Область управління проектами Опис Планування та моніторинг проекту, контроль за змінами в проекті (Project planning / Tracking / Change Control) Управління рамками проекту (Scope Management) Управління календарним графіком проекту (Schedule Management) Інтеграція та синхронізація планів проекту; організація процедур та систем управління та моніторингу проектних змін Визначення та розподіл обсягу роботи (рамок проекту); управління компромісними рішеннями у проекті Складання календарного графіка виходячи з оцінок трудовитрат, упорядкування завдань, співвідношення доступних ресурсів із завданнями, 18

19 Управління вартістю (Cost Management) Управління персоналом (Staff Resource Management) Управління комунікацією (Communications Management) Управління ризиками (Risk Management) Управління (Procurement) постачанням Управління якістю (Quality Management) застосування статистичних методів, підтримка календарного графіка Оцінки вартості виходячи з оцінок витрат; звітність про хід проекту та його аналіз; аналіз витратних ризиків; функціонально-вартісний аналіз (value analysis) Планування ресурсів; формування проектної команди; вирішення конфліктів; планування та управління підготовкою Комунікаційне планування (між проектною групою, замовником/спонсором, споживачами/користувачами, ін. зацікавленими особами); звітність про хід проекту Організація процесу управління ризиками у команді та сприяння йому; забезпечення документообігу управління ризиками Аналіз цін постачальників послуг та/або апаратного/програмного забезпечення; підготовка документів про ініціювання пропозицій (requests for proposals RFPs), вибір постачальників та субпідрядників; складання контрактів та переговори про їх умови; договору; замовлення на поставку та платіжні вимоги Планування якості, визначення стандартів, що застосовуються, документування критеріїв якості та процесів його вимірювання Література 1. W.Humphrey. Managing the Software Process. Addison-Wesley, p. 2. Д. Ахен, А. Клауз, Р. Тернер. CMMI: комплексний підхід до вдосконалення процесів. Пер з англ. М.: МФК с. 3. Carnegie Mellon University Software Engineering Institute (2006). Retrieved on 22 August

20 Лекція 4. Архітектура ПЗ Обговорення Якось один менеджер пояснював основні ідеї одного досить великого проекту, яким він керував. Він накреслив на дошці три кубики: frontend, backend, tools. І сказав, що це і є головною будовою проекту. І в сенсі внутрішнього устрою продукту, і в сенсі розподілу робіт у команді по трьох дистанційно рознесених центрах розробки. Завдання backend складні, ресурсомісткі, виконуються пакетно. Вони відокремлені від графічного інтерфейсу продукту (frontend), який також складно влаштований. Frontend це інтерфейс користувача: складний, параметризований, з рядом вбудованих сервісів (зокрема, браузер інформації), а також налаштований. Обидві ці підсистеми взаємодіють один з одним через добре визначений та детально описаний програмний інтерфейс: алгоритми backend розбиті на методи, які frontend може викликати за особливими правилами, з параметрами, вибудовуючи в ланцюжок для досягнення своїх завдань. «Збоку» від цього знаходяться додаткові інструменти. Вони інтегруються у frontend, але не користуються методами backend, а реалізують свої завдання самостійно. Ці завдання не вимагають складної пакетної обробкиа націлені на інтерактивну взаємодію з користувачем. При їх реалізації особливо багато уваги приділялося можливості. Кожна із трьох підсистем вимагала від розробників особливих навичок. У випадку backend це було вміння і досвід з реалізації такого роду пакетних алгоритмів, у випадку з frontend вміння створювати складний інтерфейс користувача, у випадку з tools вимагалося мистецтво в проектуванні та реалізації «легковагових» інструментів, що надають користувачам системи додаткові сервісні можливості. У тому, щоб розділити роботи таким чином, була ще й низка політичних аспектів. Зокрема, керівництво проекту хотіло мати процес розробки інтерфейсу користувача поруч із собою, в одному з трьох центрів розробки, який збігався зі штаб-квартирою. Вважалося, що зовнішній вигляд продукту дуже важливий для його успішного продажу та вимагає особливої уваги. В результаті виконання проекту (а він розвивався понад 15 років, досягаючи в апогеї до 150 осіб, одночасно зайнятих у ньому) така чітка структура дещо змістилася, так географічно інтерфейс майже «переїхав» у той центр, де розроблявся backend. Але в цілому такий наскрізний поділ проекту на частини залишався багато років і був основним скелетом усієї розробки. Це і є прикладом архітектури програмного проекту. Визначення Будемо розуміти під архітектурою ПЗ внутрішню структуру продукту (компоненти та їх зв'язки), основи інтерфейсу користувача продукту, а також квінтесенцію знань і рішень, що є інструментом розробки та управління проектом. Тобто архітектура це наскрізна концепція або набір таких для подолання ентропії та хаосу, які прагнуть «проковтнути» розробку через складність, нематеріальність, узгоджуваність і мінливість ПЗ. При цьому ми не поділяємо продукт і проект, оскільки на практиці це зазвичай одне ціле, причому ця «наскрізність», якщо вона є, є «сильною» стороною даної розробки. Часто під архітектурою розуміють, наприклад, тільки внутрішній пристрій, виражений в UML-діаграмах. Ось жарт на тему, що архітектуру не можна розуміти односторонньо. Одного відомого трансляторника запитали, чому в його знаменитому трансляторі 21 перегляд. Чекали почути перелік про алгоритмічні проблеми, які в такий спосіб вдалося подолати, щось про 20

Частина 2. Розуміння потреб користувачів Додаток Г Принципи управління вимогами стандартів SEI-CMM та ISO 9000 Принципи управління вимогами стандарту SEI-CMM У листопаді 1986 року в Інституті

ГОСТ Р ИСО/МЕК ТО 9294-93 ДЕРЖАВНИЙ СТАНДАРТ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ Інформаційна технологія КЕРІВНИЦТВО З УПРАВЛІННЯ ДОКУМЕНТУВАННЯМ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ГОСТ Р ИСО/МЕК ТО 9294-93 Група Т55 ДЕРЖАВНИЙ СТАНДАРТ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ Інформаційна технологія КЕРІВНИЦТВО З УПРАВЛІННЯ ДОКУМЕНТУВАННЯМ ПРОГРАМНОГО ОБЕСПЕЧЕННЯ

Планування Виконання /Контроль та аналіз Прийняття рішення Управління проектами Інформаційні технології «1С:Підприємство» ТЕХНОЛОГІЯ КОРПОРАТИВНОГО ВПРОВАДЖЕННЯ: АКСІОМИ, МОДЕЛЬ ЖИТТЯВОГО ЦИКЛУ І ОБЛАСТЬ

ОСНОВИ СИСТЕМНОЇ ІНЖЕНЕРІЇ ЛЕКЦІЯ 1. ОСНОВНІ ПОНЯТТЯ СИСТЕМНОЇ ІНЖЕНЕРІЇ 1.1. Виникнення системної інженерії Зростання масштабів та ускладнення способів організації діяльності щодо створення систем, підвищення

Назва: "Управління якістю у процесах розробки програмного забезпечення." (Quality management in software development processes.)

Â.À. Êîïíîâ ÌÅÒÎÄÈ ÅÑÊÈÅ ÓÊÀÇÀÍÈß ISO 9001 Ñèñòåìû Ìåíåäæìåíòà Êà åñòâà Ñåìèíàð äëÿ âûñøåãî ðóêîâîäñòíà òîâ ISO9000 Ïðèíöèïû ìåíåäæìåíòà êà åñòâà òî òàêîå Ñèñòåìà Ìåíåäæìåíòà

Програмне забезпечення Проектування ПЗ Фаза проектування ПЗ Життєвий цикл ПЗ Програмний продукт Іциксон В.М. ТРПО (С) 2011 2 Аналіз та планування Проектування Реалізація Тестування Документування

БАЛТІЙСЬКИЙ ДЕРЖАВНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ «ВОЄНМЕХ» імені Д. Ф. Устинова Огляд стандарту ГОСТ Р ИСО/МЭК 12207-99.

МІНІСТЕРСТВО ОСВІТИ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ Санкт-Петербурзький державний інститут точної механіки та оптики (технічний університет) СТВЕРДЖУЮ Ректор СПбГІТМО(ТУ) В.М.Васильєв 200 р. РОБОЧА

Логотип ISO Документ: ISO/TC 176/SC 2/N 544R3 Наш номер Секретаріат ISO/TC 176/SC 2 Дата: 15 жовтня 2008

Колективна діяльність у масштабі групи Продукт Rational Team Concert for Power істотно спрощує спільну діяльність, яка має критично важливе значення. Квітень 2010 р. Дон Яньцзі (Don Yantzi)

УДК 004.55 ОСОБЛИВОСТІ УПРАВЛІННЯ РОЗРОБКОВОГО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ В IT-КОМПАНІЯХ 2013 О.С. Кулакова* Ключові слова: розробка програмного забезпечення, управління розробкою програмного забезпечення,

Scientific and Practical Results in 2014. Prospects for Their Development Толепберген С. О., к. е. н. Бермухамедова Г. Б. Казахстан, Актау, Казахський державний університет технології та інжинірингу

Мережні технології-2 Технології інтернет Лекція Методології розробки ПЗ Штогрина Олена Сергіївна Методологія Методологія це система принципів, а також сукупність ідей, понять, методів, способів

266 Є. І. Пластиніна Вятська державна сільськогосподарська академія, м. Кіров Інноваційний менеджмент у кадровій роботі підприємства Поняття «інновація» в даний час закріплено в російській

Фред Брукс і «Міфічний людино-місяць» Фредерік Філліпс Брукс Молодший Народився 19 квітня 1931 року в місті Дарем, Північна Кароліна 1953 закінчив Університет Дьюка 1956 отримав титул Ph.D. за прикладною

УДК 338.24.01 РОЗРОБКА ТА ВПРОВАДЖЕННЯ ІНТЕГРОВАНОЇ СИСТЕМИ МЕНЕДЖМЕНТУ Т.О. Салімова, доктор екон. наук, професор, зав. кафедрою управління якістю ГОУ ВПО «Мордівський державний університет

Вступна лекція Мета лекції: 1. Показати значущість та актуальність інформаційних технологій в управлінні організацією (підприємством) 2. Визначити вимоги до вивчення дисципліни. 3. Дати характеристику

SWorld 17-28 June 2014 http://www.sworld.com.ua/index.php/ru/conference/the-content-of-conferences/archives-of-individual-conferences/june-2014 MODERN PROBLEMS AND WAYS OF THEIR SOLUTION IN SCIENCE, TRANSPORT,

УДК 654-34 УПРАВЛІННЯ ІНВЕСТИЦІЯМИ В ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ НА ОСНОВІ СТАНДАРТУ ISO/IEC 15288 І МОДЕЛІ ЗРЕЛОСТИ ПІДПРИЄМСТВА Годунова Анастасія Олегівна, Студент 4 курсу

ПЛАН ТЕСТУВАННЯ КЛІЄНТ-СЕРВЕРНОЇ СИСТЕМИ 1 ЗМІСТ 1. ВСТУП... 3 1.1. Цілі тестування... 3 1.2. Стратегії тестування... 3 1.3. Види тестування... 3 1.4. Документування... 5 2. ЦИКЛ ТЕСТУВАННЯ...

СЕКРЕТИ УСПІШНИХ БАНКІВ Р.А. ІСАЄВ СЕКРЕТИ УСПІШНИХ БАНКІВ: менеджмент якості та ISO 9000 ЕЛЕКТРОННА КНИГА-ОРГАНАЙЗЕР Москва ІНФРА М 2012 УДК 650 ББК 65.290 І85 І85 Ісаєв Р.А. Секрети успішних банків:

Технологія розроблення програмного забезпечення 2015-2016 років. Лекції 3-4: гнучкі технологіїПудов Сергій Григорович Складання ТЗ та плану робіт Технічне завдання (ТЗ) документ, що містить набір вимог

Вишняков Олег Леонідович, Директор з бізнес-консалтингу ТОВ «Логіка бізнесу», Тулінців Костянтин Геннадійович, консультант ТОВ «Логіка бізнесу» Процесний підхід в управлінні організацією

Реалізація якості розробки для платформи Atom/MeeGo В. І. Кияєв 1 Лекція13 Реалізація якості Найважливішою складовою філософії підприємництва є філософія якості, яка має гостру

ISSN 2079-8490 Електронне наукове видання «Вчені нотатки ТОГУ» 2014, Том 5, 4, С. 20 24 Свідоцтво Ел ФС 77-39676 від 05.05.2010 http://pnu.edu.ru/ru/ejournal/ab [email protected]УДК 338.242.2

Ââåäåíèå В даний час у більшості організацій різного профілю відчувається потреба у фахівцях, які професійно володіють різноманітними сучасними інформаційними технологіями. При

Жеребіна О.Г., [email protected]Фірма «1С», Москва Використання професійного стандарту «Спеціаліст з інформаційних систем» у вищій та середній професійній освіті Проект розробки професійних

ДЕРЖАВНА ТЕХНІЧНА КОМІСІЯ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ Керівний документ ЗАСОБИ ВИЧИСЛЮВАЛЬНОЇ ТЕХНІКИ. МІЖМЕРЕЖНІ ЕКРАНИ. ЗАХИСТ ВІД НЕСАНКЦІОНОВАНОГО ДОСТУПУ ДО ІНФОРМАЦІЇ. ПОКАЗНИКИ ЗАХИЩЕНОСТІ

ЕЛЕКТРОННИЙ НАУКОВИЙ ЖУРНАЛ «APRIORI. СЕРІЯ: ПРИРОДНІ ТА ТЕХНІЧНІ НАУКИ» 6 2015 УДК 004 АВТОМАТИЗАЦІЯ ВІДДІЛУ ОХОРОНИ ПРАЦІ Баулін Станіслав Сергійович магістрант Мордівський державний університет

НОУ ВПО Приватна освітня установа вищої освіти «ЄСЕНТУКСЬКИЙ ІНСТИТУТ УПРАВЛІННЯ, БІЗНЕСУ І ПРАВА» кафедра Вищої математики та інформатики ЕІУБіП ЧОУ У ЄІУБП РОБОЧА ПРОГРАМА З ДИСЦИПЛІНИ

ОСВОЇВ САМ ДОПОМОГИ ІНШИМ Маріанна Матюкова, заст. директора з якості, компанія «Альтер Лого» Стабільно високий успіх може забезпечити чітко функціонуюча та результативна система менеджменту якості

1 2 3 4 5 6 7 80 9 0 Лекція 6 Елементи технологічного шару. Моделювання технологічної архітектури сервіс інтерфейс Артефакт функціонал Вузол Мережа 90 / 142 реалізує Copyright Рубенчик А.В. 2016. Усі

Тема 3 Фази проекту та його життєвий шлях. Розвиток та оцінка проекту Кожен проект незалежно від його складності, галузі застосування чи обсягів робіт, необхідних для його виконання, проходить у своєму розвитку

УДК 002:658.516+658.562 П.В. СТРІЛЬНИКІВ ПРО СЕРТИФІКАЦІЮ СИСТЕМ МЕНЕДЖМЕНТУ ЯКОСТІ Abstract: The basic stimulus for creation of quality management systems at the enterprises are created. Some advantages

ВИКОРИСТАННЯ ЛОГІСТИЧНОГО ПІДХОДУ В ДІЯЛЬНОСТІ ПІДПРИЄМСТВА ПРИ СТВОРЕННІ ІННОВАЦІЙНИХ ПРОДУКТІВ Левкін Г.Г. к. вет. н., доцент кафедри економіка транспорту, логістика та управління якістю, Омський

ВСТУП Цей посібник складено відповідно до вимог Державного освітнього стандарту спеціальності «Прикладна інформатика в економіці» та відображає такі розділи дисципліни «Розробка

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

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

BUSINESS ASSURANCE ISO 9001:2015 огляд ключових змін 2016-02-22 1 SAFER, SMARTER, GREENER Зміст Основні напрямки еволюції стандарту ISO 9001 Уніфікована структура верхнього рівняГармонізація

Система менеджменту якості компанії Fastwel: досвід впровадження та сертифікації Олексій Маклаков Розробка та впровадження системи менеджменту якості на підприємстві завдання складне і для кожного окремого

Інтеграція та зовнішніх систем «Керуємо підприємством» 12 (47), 2014 ІТ-інфраструктура Михайло Кірєєв Керівник відділу розробки департаменту 1С ДК «КОРУС Консалтинг». Керував проектами розробки та

СИБІРСЬКИЙ УНІВЕРСИТЕТ СПОЖИВЧОЇ КООПЕРАЦІЇ ПРОГРАМА ВСТУПНИХ ВИПРОБУВАНЬ ЗА НАПРЯМКОМ 230700.62 Прикладна інформатика Новосибірськ ВСТУП Програма вступних випробувань за напрямком

СИСТЕМА ЕЛЕКТРОННОГО ДОКУМЕНТООБІГУ СХЕМУ ДИСТРИБ'ЮЦІЇ ТА ВИРОБНИЧИЙ ЦИКЛ Листів 9 2016 ЗМІСТ 1. ТЕРМІНИ, СКОРОЧЕННЯ І ВИЗНАЧЕННЯ... 3 2. ВВ. Призначення документа... 4 2.2.

АЮСооляте Моделі офісів управління проектами, програмами, портфелями проектів Даний матеріал є витримкою з книги Андрія Сооляте «Управління проектами в компанії: методологія, технології, практика»

Документування на етапах проектування ІС 1 Етап 1. Системний аналіз проекту ПС 1.1. Дослідження та визначення концепції версії ПС Результати обстеження та опис об'єкта та цілей його інформатизації

38 Вісник РЕА 2007 6 К. М. Марченкова ЗАДАЧІ ТА ФУНКЦІЇ ФІНАНСОВОГО КОНТРОЛІНГУ Викладено концепцію фінансового контролінгу як ефективного інструментууправління корпоративними фінансами. Актуальність

Табельний облік (Russian Time Management) Модуль Табель призначений для планування та обліку використання робочого часу працівників підприємства. Модуль Табель інтегрований до програми Oracle HRMS.

Тема роботи: «ІНФОРМАЦІЙНІ АСПЕКТИ СИСТЕМНОГО АНАЛІЗУ У СТВОРЕННІ СИСТЕМ УПРАВЛІННЯ АВТОТРАНСПОРТНИМ ПІДПРИЄМСТВОМ» Тема реферату: «СИСТЕМА УПРАВЛІННЯ АВТОТРАНСПОРТНИМ ПІДПРИЄМСТВАМ»

Принципи та проблеми розробки складних програмних систем Кафедра дискретної математики та інформаційних технологій Синельников Євген Олександрович [email protected] 12 Вересень, 2011 TIOBE Programming

Майбутнє серії стандартів ISO 9000 Іван Чайка, президент Міжнародної Гільдії професіоналів якості, к.е.н., академік Академії проблем якості Стандарти серії ISO сьогодні застосовують понад мільйон підприємств,

МЕНЕДЖМЕНТ І МАРКЕТИНГ Соціальна відповідальність бізнесу як елемент корпоративного управління Л.НУГУМАНОВА Сутність та принципи корпоративного управління. Сьогодні у багатьох країнах світу, у тому числі в

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

Міністерство освіти Республіки Білорусь Установа освіти «Білоруський державний університет інформатики та радіоелектроніки» В. В. Бахтізін, Л. А. Глухова Технологія розробки програмного забезпечення

Альперін М.І., Самсонова Е.Р., Решетніков Р.С. Альперін М.І., Самсонова Е.Р., Решетников Р.С. ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ДЛЯ НАВЧАННЯ У МАЛІХ ГРУПАХ SOFTWARE FOR TRAINING IN SMALL GROUPS [email protected]

НАДІЙНІСТЬ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. ВИДИ І КРИТИЧНІСТЬ ПОМИЛОК. Дроботун Є. Б. Військова академія повітряно-космічної оборони, м.тверь [email protected]У роботі розглядаються якість та надійність програмного

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

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

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

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

Модульне програмування. Головний принцип модульного програмування полягав у виділенні таких фрагментів та оформленні їх у вигляді модулів. Кожен модуль мав опис, у якому встановлювалися правила його використання – інтерфейс модуля. Інтерфейс задавав зв'язки модуля з основною програмою - зв'язки за даними та зв'язки з управління. При цьому можливість повторного використання модулів визначалася кількістю та складністю цих зв'язків, або наскільки ці зв'язки вдалося погоджувати з організацією даних та управління основною програмою. Найбільш простими у цьому відношенні виявилися модулі розв'язання математичних завдань: розв'язування рівнянь, систем рівнянь, задач оптимізації. На сьогодні накопичені та успішно використовуються великі бібліотеки таких модулів.

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

Зростання складності програм (структурне програмування)

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

Великий обсяг коду (мільйони рядків)

Велика кількість зв'язків між елементами коду

Велика кількість розробників (сотні людей)

Велика кількість користувачів (сотні та тисячі)

Тривалий час використання

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

Структурне програмування. Етап супроводу програмного комплексу включав дії з виправлення помилок у роботі програми та внесення змін відповідно до вимог користувачів, що змінилися. Основна причина високої вартості (а часом і неможливості виконання) етапу супроводу полягала в тому, що програми були погано спроектовані - документація була не зрозуміла і не відповідала програмному коду, а програмний код був дуже складний і заплутаний. Потрібна технологія, яка забезпечить «правильне» проектування та кодування. Основні принципи технології структурного проектування та кодування:

Низхідне функціональне проектування, у якому у системі виділяються основні функціональні підсистеми, які потім розбиваються на підсистеми тощо. (Принцип «розділяй і володарю»)

Застосування спеціальних мов проектування та засобів автоматизації використання цих мов

Дисципліна проектування та розробки: планування та документування проекту, підтримка відповідність коду проектної документації

Структурне кодування без goto

Головна > Документ

Введення у програмну інженерію

Програмна інженерія: призначення, основні принципи та поняття

1.1Передумови та історія

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

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

Зростання складності програм (структурне програмування)

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

Великий обсяг коду (мільйони рядків)

Велика кількість зв'язків між елементами коду

Велика кількість розробників (сотні людей)

Велика кількість користувачів (сотні та тисячі)

Тривалий час використання

Застосування спеціальних мов проектування та засобів автоматизації використання цих мов

Структурне кодування без goto

Модифікація програм (ООП)

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

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

Інкапсуляція - об'єднання в класі даних (властивостей) та методів (процедур обробки).

Спадкування – можливість виведення нового класу зі старого з частковою зміною властивостей та методів

Поліморфізм – визначення властивостей та методів об'єкта за контекстом

Проілюструвати можливості принципів ОВП можна на прикладі. В організації, що складається з трьох відділів, треба нараховувати заробітну плату. У програмі кожен відділ представлений своїм модулем – об'єктом, а нарахування зарплати – об'єктом "Зарплата". За потреби розрахунку зарплати об'єкту «Відділ» передається екземпляр об'єкту «Зарплата». Об'єкт «Відділ» передає об'єкту «Зарплата» необхідні дані, а потім за допомогою методів об'єкта «Зарплата» виконує необхідні розрахунки.

У відділі 3 частково змінилися правила нарахування зарплати. У цій ситуації при об'єктно-орієнтованому підході з класу «Зарплата» виводиться клас «Зарплата 1», який успадковує правила нарахування зарплати, що змінилися, і перевизначає зміни. Тут при розрахунку зарплати об'єктам «Відділ 1» та «Відділ 2» передаватиметься об'єкт «Зарплата», а об'єкту «Відділ 3» – об'єкт «Зарплата 1». За таких змін:

Спрацьовує принцип успадкування: код «Зарплата», «Відділ 1» та «Відділ 2» залишаються без зміни, а код «Зарплата 1» змінюється рівно настільки, наскільки це необхідно.

Спрацьовує принцип поліморфізму: код "Відділ 3" також не змінюється - він продовжує вважати, що працює з об'єктом "Зарплата"

Деякі підсумки

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

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

Продовження кризи програмування

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

Ціна успіху – криза програмування набуває хронічних форм:

США витрачає щорічно понад $200 млрд на більш ніж 170 тис. проектів розробки ПЗ у сфері IT; 31,1% із них закриваються, так і не завершившись; 52,7% проектів завершуються з перевищенням початкових оцінок бюджету/термінів та обмеженою функціональністю; втрати від недоотриманого ефекту застосування ПЗ вимірюються трильйонами.

Статистика по 30,000 проектів з розробки програмного забезпечення в американських компаніях показує наступний розподіл між:

Упоспішними – вчасно та в рамках бюджету було виконано весь намічений фронт робіт

Проблемними – порушення термінів, перевитрата бюджету та/або зробили не все, що потрібно

Провалені - не були доведені до кінця через перевитрати коштів, бюджету, якості.

Джерело: The Standish Group International The Standish Group International, Inc., Extreme Chaos, 2000 -//sample_research/PDFpages/extreme_chaos.pdf

1.2 Програмна інженерія – що це таке?

Почнемо з визначень

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

Сам термін – software engineering (програмна інженерія) – вперше був озвучений у жовтні 1968 року на конференції підкомітету НАТО з науки та техніки (м. Гарміш, Німеччина). Було присутні 50 професійних розробників програмного забезпечення з 11 країн. Розглядалися проблеми проектування, розробки, розповсюдження та підтримки програм. Там уперше й прозвучав термін «програмна інженерія» як певна дисципліна, яку треба створювати і якою треба керуватися у вирішенні цих проблем.

Незабаром після цього в Лондоні відбулася зустріч 22 керівників проектів з розробки ПЗ. На зустрічі аналізувалися проблеми та перспективи розвитку ПЗ. Відзначалася зростаюча дія ПЗ на життя людей. Вперше серйозно заговорили про кризу ПЗ, що насувається. Застосовні принципи та методи розробки програмного забезпечення вимагали постійного вдосконалення. Саме на цій зустрічі було запропоновано концепцію життєвого циклу ПЗ (SLC – Software Lifetime Cycle) як послідовності кроків-стадій, які необхідно виконати у процесі створення та експлуатації ПЗ. Навколо цієї концепції було багато суперечок. У 1970 р. У.У. Ройс (W.W. Royce) зробив ідентифікацію кількох стадій у типовому циклі і було висловлено припущення, що контроль виконання стадій призведе до підвищення якості програмного забезпечення та скорочення вартості розробки.

Розберемося у питаннях

Для того, щоб отримати уявлення про те, що таке програмна інженерія, спробуємо розібратися у таких питаннях:

Що таке програмне забезпечення? Що таке програмна інженерія? У чому різниця між програмною інженерією (software engineering) та інформатикою (computer science)? У чому різниця між програмною інженерією та системною інженерією (systems engineering)? У чому відмінність програмної інженерії з інших інженерій?

Що таке програмне забезпечення?

Програмне забезпечення це набір комп'ютерних програм, процедур та пов'язаної з ними документації та даних (ISO/IEC 12207). Погляд на ПЗ як тільки на програму, що сидить у комп'ютері, занадто вузький. Справа в тому, що продається (постачається) не тільки програма, але ще й документація, в якій можна прочитати як встановити програму і як їй користуватися дані для встановлення програми в різних умовах (конфігураційні файли). Тому інколи називають програмним продуктом. Тобто. програмний продукт (програмне забезпечення) – це не лише програми, а також вся пов'язана з ними документація та конфігураційні дані, необхідні для коректної роботипрограми. А спеціалісти із програмного забезпечення розробляють програмні продукти, тобто. таке програмне забезпечення, яке може бути продано споживачеві.

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

коробочні продукти (generic products – загальні продукти або shrink-wrapped software – упаковане ПЗ) замовні продукти (bespoke – зроблений на замовлення або customized products – налаштований продукт). Важлива різниця між ними полягає в тому, хто ставить завдання (визначає чи специфікує вимоги). У першому випадку це роблять самі розробники з урахуванням аналізу ринку (маркетингу) – і навіть ризикують самі. У другому – замовник і при цьому ризикує, що розробник не зможе реально виконати всі вимоги у строк та за виділеного бюджету.

Що таке програмна інженерія?

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

Інженерна дисципліна

Усі аспекти виробництва ПЗ

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

Для вирішення завдання інженери застосовують теорії, методи та засоби, придатні для вирішення даного завдання, але вони застосовують їх вибірково і завжди намагаються знайти рішення, навіть у тих випадках, коли теорій чи методів, що відповідають даному завданню, ще не існує. У цьому випадку інженер шукає метод чи засіб для вирішення завдання, застосовує його та несе відповідальність за результат – адже метод чи засіб ще не перевірено. Набір таких інженерних методів або способів, які теоретично можливо не обґрунтовані, але отримали неодноразове підтвердження на практиці, відіграє велику практичну роль. У програмній інженерії вони отримали назву найкращих практик (best practices).

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

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

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

У чому різниця від інформатики?

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

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

У чому на відміну від інших інженерій?

Відмінність програмної інженерії від інших інженерій цікава насамперед із погляду двох питань:

Чому частка провальних проектів у програмній інженерії така велика в порівнянні з іншими інженеріями?

Чи можна у програмній інженерії застосовувати досвід інших інженерій?

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

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

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

Звідси випливають такі висновки:

Вартість програми – це вартість лише її проектування

Вартість проектування коробкових продуктів «розмазується» за копіями

Вартість замовлених продуктів (масово не копіюваних) залишається високою

У чому ще відмінність від інших інженерій?

Друга істотна відмінність у тому, що програма – штучний об'єкт. Тобто. для програми немає об'єктивних законів, яким би підкорялася її поведінка. Наприклад, інженер – будівельник має об'єктивні закони будівельної механіки: рівноваги моментів і сил, стійкості механічних систем тощо. Інженер-будівельник може перевірити свої архітектурні рішення на відповідність цим законам і тим самим забезпечити удачу проекту. Ці закони об'єктивні, вони діятимуть завжди. Програмний інженер на перший погляд також має типові, перевірені часом архітектурні рішення (наприклад, клієнт-серверна архітектура). Але це рішення визначаються рівнем розвитку обчислювальної техніки (і адекватним їм рівнем вимог). З появою техніки з новими можливостями програмному інженеру доведеться шукати нові рішення.

Прямим наслідком відсутності можливості «теоретичного» контролю проекту і те, що тестування продукту – це єдиний спосібпереконатися у його якості. Саме тому вартість тестування складає значну вартість ПЗ. До речі, будівельний інженер, як правило, позбавлений можливості такого тестування свого продукту перед здаванням його в експлуатацію.

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

Докладніше про проблеми проектування ПЗ можна переглянути у неоднозначній статті Коні Бюрера «Від ремесла до науки: пошук основних принципів розробки ПЗ» /fset.asp?Url=/rational/science.htm

З чого складається вартість?

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

Типовий розподіл вартості між основними етапами (без супроводу) має такий вигляд:

15% - специфікація – формулювання вимог та умов розробки

25% - проектування – розробка та верифікація проекту

20% - розробка – кодування та тестування компонентів

40% - інтеграція та тестування – об'єднання та складальне тестування продукту

Відхилення від цієї схеми в залежності від типу ПЗ виглядають наступним чином:

Для коробкового ПЗ характерна більш висока частка тестування за рахунок скорочення насамперед частки специфікації (до 5%)

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

Застосування випробуваних рішень та готових компонентів при створенні коробкових продуктів дозволяє підвищити якість та скоротити терміни розробки.

Ще питання

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

Що таке програмний процес?

Що таке модель програмного процесу?

Що таке методи програмної інженерії?

Що таке CASE (Computer-Aided Software Engineering)?

Які властивості має хороша програма?

Які основні проблеми стоять перед програмною інженерією?

Програмний процес?

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

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

Процес – сукупність процесів і завдань, що мають на меті досягнення значного результату. Основними процесами (іноді називають етапами чи фазами) життєвого циклу є:

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

Розробка проекту програми (результат – опис того, як програма працюватиме)

Кодування (результат – вихідний кодта файли конфігурації)

Тестування програми (результат – контроль відповідності програми вимогам)

Документування (результат – документація до програми)

Крім основних, існує багато додаткових та допоміжних процесів, пов'язаних не створенням продукту, а з організацією робіт (нефункціональні процеси): створення інфраструктури, управління конфігурацією, управління якістю, навчання, вирішення протиріч, …

Процес має бути встановлений. Повне встановлення процесу передбачає:

Опис процесу – детальний опис дій та операцій процесу Навчання процесу – проведення занять з персоналом з освоєння процесу Введення метрик – встановлення кількісних показників ходу виконання Контроль виконання – вимірювання метричних показників та оцінка ходу виконання Удосконалення – зміна процесу за мінливих умов застосування

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

Розмір: 821 Кб
Кількість слайдів: 61

Опис презентації Введення в програмну інженерію ПОНЯТТЯ ПРОГРАМНОЇ ІНЖЕНЕРІЇ зі слайдів

ПОНЯТТЯ ПРОГРАМНОЇ ІНЖЕНЕРІЇ Чим програмування відрізняється від програми інженерії? Програмування є деякою абстрактною діяльністю та може відбуватися у багатьох різних контекстах. Промислове програмування, як правило, відбувається у команді, і абсолютно точно – для замовника, який платить за роботу гроші. Необхідно точно розуміти, що потрібно замовнику, виконати роботу у певні терміни і результат повинен бути потрібної якості – тієї, яка задовольнить замовника і за яку він заплатить. Щоб задовольнити цим додатковим вимогам, програмування «обростає» різними додатковими видами діяльності: розробкою вимог, плануванням, тестуванням, конфігураційним управлінням, проектним менеджментом, створенням різної документації (проектної, користувальницької та ін.).

Розробка програмного коду передується аналізом та проектуванням (перше означає створення функціональної моделі майбутньої системи без урахування реалізації, для усвідомлення програмістами вимог та очікувань замовника; друге означає попередній макет, ескіз, план системи на папері). Потрібні спеціальні зусилля щодо організації процесу розробки. Розробку системи необхідно виконувати з урахуванням зручностей та її подальшого супроводу, повторного використання та інтеграції з іншими системами. Це означає, що система розбивається на компоненти, зручні в розробці, придатні для повторного використання та інтеграції. Для цих компонент ретельно опрацьовуються інтерфейси. Сама ж система документується на багатьох рівнях, створюються правила оформлення програмного коду – тобто залишаються численні семантичні сліди, що допомагають створити та зберегти, підтримувати єдину, струнку архітектуру, одноманітний стиль, порядок… Усі ці та інші додаткові види діяльності, які виконуються у процесі промислового програмування та необхідні для успішного виконання замовлень та називатимемо програмною інженерією (software engineering)

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

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

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

Продовження кризи програмування Незважаючи на те, що програмна інженерія досягла певних успіхів, перманентна криза програмування продовжується. Пов'язано це з тим, що рубіж 80-90-х років відзначається як початок інформаційно-технологічної революції, викликаної вибуховим зростанням використання інформаційних засобів: персональний комп'ютер, локальні та глобальні обчислювальні мережі, мобільний зв'язок, електронна пошта, Internet і т.д. успіху – криза програмування набуває хронічних форм. Standish Group, проаналізувавши роботу сотень американських корпорацій та підсумки виконання кількох десятків тисяч проектів, пов'язаних з розробкою ПЗ, у своїй доповіді з промовистою назвою «Хаос» дійшла таких висновків: – Тільки 35 % проектів завершилися вчасно, не перевищили запланований бюджет та реалізували всі необхідні функції та можливості. - 46% проектів завершилися із запізненням, витрати перевищили запланований бюджет, необхідні функції не були реалізовані в повному обсязі. Середнє перевищення термінів становило 120%, середнє перевищення витрат 100%, зазвичай виключалося значної частини функцій.

19% проектів повністю провалилися та були анульовані до завершення. Результати аналізу успішності програмних проектів за 2006 рік

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

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

Процес розробки ПЗ - сукупність процесів, що забезпечують створення та розвиток програмного забезпечення. Модель процесу розробки ПЗ - формалізоване уявлення процесу розробки ПЗ. Часто в описах процесів замість слова модель використовується термін методологія. На сьогоднішній день немає єдиного визначення поняття «програмна інженерія». Нижче наведено кілька таких Визначення, дані великими фахівцями у цій галузі, або зафіксовані в документах провідних організацій: – встановлення та використання обґрунтованих інженерних принципів (методів) для ощадливого отримання ПЗ, яке надійне та працює на реальних машинах. ; – та форма інженерії, яка застосовує принципи інформатики (computer science) та математики для рентабельного вирішення проблем програмного забезпечення. - Застосування систематичного, дисциплінованого, вимірюваного підходу до розробки, використання та супроводу ПЗ. – дисципліна, метою якої є створення якісного ПЗ, яке завершується вчасно, не перевищує виділених бюджетних коштів та задовольняє вимогам, що висуваються .

Хронологія розвитку програмної інженерії 1958 - всесвітньо відомий статистик Джон Тьюкей (John Tukey) вперше ввів термін software - програмне забезпечення. 1968 р. — Термін software engineering (програмна інженерія) вперше з'явився у назві конференції НАТО, що відбулася в Німеччині, присвяченій так званій кризі програмного забезпечення. 1970 р. - У. У. Ройс (W. W. Royce) зробив ідентифікацію кількох стадій у типовому циклі і було висловлено припущення, що контроль виконання стадій призведе до підвищення якості ПЗ та скорочення вартості розробки. Було запропоновано концепцію життєвого циклу (SLC – Software Lifetime Cycle). 1990 - 1995 р. - велася робота над міжнародним стандартом, який повинен був дати єдине уявлення про процеси розробки програмного забезпечення. В результаті було випущено стандарт ISO/IEC 12207 Software Lifecycle Processes. – Відповідний національний стандарт Росії – ГОСТ Р ИСО/МЭК 12207 -99 [ГОСТ 12207, 1999] містить повний автентичний переклад міжнародного стандарту ISO/IEC 12207 —

1. Guide to the Software Engineering Body of Knowledge (SWEе. K), IEEE 2004 Version - Посібник до Зводу Знань з Програмної Інженерії, надалі просто SWEе. K; Однією з найважливіших цілей SWEе. K є саме визначення тих аспектів діяльності, які становлять суть професії інженера-програміста. 2. Software Engineering 2004. - Навчальний План для Викладання Програмної Інженерії у ВНЗ [SE, 2004]. 2004 р - ACM/IEEE-CS сформулювали два ключові описи того, що сьогодні ми і називаємо основами програмної інженерії - Software Engineering:

Структура та зміст SWEBOK Відповідно до SWEBOK 2004, програмна інженерія включає 10 основних і 7 додаткових областей знань, на яких базуються процеси розробки ПЗ. До основних областей знань відносяться такі області: Software requirements – програмні вимоги. Software design – дизайн (архітектура). Software construction – конструювання програмного забезпечення. Software testing – тестування. Software maintenance – експлуатація (підтримка) програмного забезпечення. Software configuration management – конфігураційне управління. Software engineering management – управління у програмній інженерії. Software engineering process – процеси програмної інженерії. Software engineering tools and methods - інструменти та методи. Software quality – якість програмного забезпечення. Опис областей знань у SWEе. K побудовано за ієрархічним принципом, як наслідок структурної декомпозиції.

Пов'язані дисципліни Додаткові галузі знань включають: Computer engineering - розробка комп'ютерів. Computer science – інформатика. Management – загальний менеджмент. Mathematics - математика. Project management – управління проектами. Quality management – управління якістю. Systems engineering – системне проектування.

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

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

ЖИТТЄВИЙ ЦИКЛ ПРОГРАМНОГО ПРОДУКТУ Методологічну основу будь-якої інженерії становить поняття життєвого циклу (ЖЦ) виробу (продукту) як сукупності всіх дій, які треба виконати протягом усього життя виробу. Сенс життєвого циклу полягає у взаємопов'язаності всіх цих процесів. Життєвий цикл промислового виробу визначається як послідовність етапів (фаз, стадій), що складаються з технологічних процесів, дій та операцій. . Розподіл понять ЖЦ ПЗ та моделі ЖЦ ПЗ. - ЖЦ ПЗ - повна сукупність всіх процесів і дій зі створення та застосування ПЗ; – модель ЖЦ – конкретний варіант організації ЖЦ, обгрунтовано (розумно) обраний кожному за конкретного випадку.

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

Класичний життєвий цикл Класичний життєвий цикл розробки ПЗ - найстаріша парадигма процесу розробки ПЗ (автор Уїнстон Ройс, 1970) Класичний життєвий цикл називають каскадною або водоспадною моделлю; Розробка розглядається як послідовність етапів, причому перехід на наступний, ієрархічно нижній етап відбувається лише після повного завершення робіт на поточному етапі

Зміст основних етапів. Системний аналіз - задає роль кожного елемента в комп'ютерній системі, взаємодія елементів один з одним. На цьому етапі розпочинається вирішення задачі планування проекту ПЗ. Визначаються: обсяг проектних робіт; - Ризик; – необхідні трудовитрати; - Формуються робочі завдання; - План-графік робіт. Аналіз вимог - відноситься до програмного елемента - програмного забезпечення. Уточнюються та деталізуються – Функції; - Характеристики; - Інтерфейс. Усі визначення документуються у специфікації аналізу. Тут же завершується вирішення задачі планування проекту.

Проектування полягає у створенні уявлень: - архітектури ПЗ; – модульної структури; - Алгоритмічної структури ПЗ; - Структури даних; – вхідного та вихідного інтерфейсу (вхідних та вихідних форм даних). Вихідні дані для проектування містяться у специфікації аналізу. Під час вирішення завдань проектування основну увагу приділяється якості майбутнього програмного продукту. Кодування полягає у перекладі результатів проектування в текст мовою програмування. Тестування - виконання програми виявлення дефектів у функціях, логіці і формі реалізації програмного продукту. Супровід - це внесення змін до ПЗ, що експлуатується. Цілі змін: - Виправлення помилок; – адаптація до змін зовнішнього ПО середовища; - Удосконалення ПЗ за вимогами замовника.

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

Макетування Проблеми Замовник не може сформулювати докладні вимоги щодо введення, обробки або виведення даних для майбутнього програмного продукту. Розробник може сумніватися: - у пристосованості продукту під операційну систему; - Формі діалогу з користувачем; - В ефективності реалізованого алгоритму. У таких випадках доцільно використовувати макетування. Основна мета макетування – зняти невизначеність у вимогах замовника. Макетування (прототипування) – це процес створення моделі необхідного програмного продукту. Модель може набувати однієї з трьох форм: 1) паперовий макет або макет на основі ПК (зображує або малює людино-машинний діалог); 2) працюючий макет (виконує деяку частину необхідних функцій); 3) існуюча програма (характеристики якої потім мають бути покращені).

Збір та уточнення вимог до створюваного ПЗ. Розробник і замовник зустрічаються і визначають всі цілі ПЗ, встановлюють, які вимоги відомі, а які належить довизначити. Швидке проектування. Увага зосереджується тих характеристиках ПЗ, які мають бути видимі користувачеві. Швидке проектування призводить до побудови макета. Макетування. Оцінюється макет замовником — використовується для уточнення вимог до ПЗ. Уточнення макету. Ітерації повторюються доти, доки макет не виявить всі вимоги замовника і, тим самим, не дасть змоги розробнику зрозуміти, що має бути зроблено. Гідність макетування: забезпечує визначення повних вимогдо ПЗ. Недоліки макетування: Замовник може прийняти макет за продукт; розробник може прийняти макет продукту.

Для швидкого отримання макету розробник часто йде на певні компроміси: – використовуються не самі відповідні мовипрограмування або операційна система; – для простої демонстрації можливостей можна застосовувати неефективний алгоритм.

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

Характеристики стратегій конструювання ПЗ відповідно до вимог стандарту IEEE/EIA 12207. 2 Стратегія конструювання На початку процесу визначено всі вимоги? Чимало циклів конструювання? Проміжне ПЗ поширюється? Одноразовий прохід Інкрементна (заплановане поліпшення продукту) Еволюційна Так Так Ні Можливо Так

Інкрементна модель Інкрементна модель є класичним прикладом інкрементної стратегії конструювання. Вона поєднує елементи послідовної водоспадної моделі з ітераційною філософією макетування.

Кожна лінійна послідовність тут виробляє інкремент ПЗ, що поставляється. приклад. ПЗ для обробки слів в 1-му інкременті реалізує функції базової обробки файлів, функції редагування та документування; у 2-му інкременті - більше складні можливостіредагування та документування; у 3-му інкременті - перевірку орфографії та граматики; у 4-му інкременті - можливості компонування сторінки. Перший інкремент призводить до отримання базового продукту, що реалізує базові вимоги (щоправда, багато допоміжних вимог залишаються нереалізованими). План наступного інкременту передбачає модифікацію базового продукту, що забезпечує додаткові характеристики та функціональність. За своєю інкрементний процес ітеративний, але, на відміну макетування, інкрементна модель забезпечує кожному інкременті працюючий продукт. Сучасна реалізація інкрементного підходу - екстремальне програмування ХР. (Кент Бек, 1999)

Швидка розробка програм Модель швидкої розробки програм (Rapid Application Development) - другий приклад застосування інкрементної стратегії конструювання

RAD-модель забезпечує екстремально короткий цикл розробки. RAD - високошвидкісна адаптація лінійної послідовної моделі, у якій швидка розробкадосягається за рахунок використання компонентно-орієнтованого конструювання. Якщо вимоги повністю визначені, а проектна область обмежена, RAD-процес дозволяє групі створити повністю функціональну системуза дуже короткий час (60-90 днів). RAD-підхід орієнтований на розробку інформаційних систем та виділяє такі етапи: – бізнес-моделювання. Моделюється інформаційний потік між бізнес-функціями. Шукається відповідь на такі питання: Яка інформація керує бізнес-процесом? Яка інформація генерується? Хто її генерує? Де інформація застосовується? Хто її обробляє? – моделювання даних. Інформаційний потік, визначений на етапі бізнес-моделювання, відображається в наборі об'єктів даних, потрібних для підтримки бізнесу. Ідентифікуються характеристики (властивості, атрибути) кожного об'єкта; визначаються відносини між об'єктами;

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

Застосування RAD має свої недоліки та обмеження. 1. Для великих проектів у RAD потрібні істотні людські ресурси (необхідно створити достатню кількість груп). 2. RAD застосовується тільки для таких додатків, які можуть декомпозуватися на окремі модулі та в яких продуктивність не є критичною величиною. 3. RAD не застосовується за умов високих технічних ризиків (тобто під час використання нової технології).

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

Спіральна модель: 1 - початковий збір вимог та планування проекту; 2 - та ж робота, але на основі рекомендацій замовника; 3 – аналіз ризику на основі початкових вимог; 4 – аналіз ризику на основі реакції замовника; 5 - перехід до комплексної системи; 6 – початковий макет системи; 7 – наступний рівень макета; 8 – сконструйована система; 9 – оцінювання замовником. Модель визначає чотири дії, що подаються чотирма квадрантами спіралі. 1. Планування - визначення цілей, варіантів та обмежень. 2. Аналіз ризику - аналіз варіантів та розпізнавання/вибір ризику. 3. Конструювання – розробка продукту наступного рівня. 4. Оцінювання – оцінка замовником поточних результатів конструювання.

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

Переваги спіральної моделі: 1) найбільш реально (як еволюції) відображає розробку програмного забезпечення; 2) дозволяє явно враховувати ризик кожному витку еволюції розробки; 3) включає крок системного підходу до ітераційної структури розробки; 4) використовує моделювання для зменшення ризику та вдосконалення програмного виробу. Недоліки спіральної моделі: 1) новизна (відсутня достатня статистика ефективності моделі); 2) підвищені вимоги до замовника; 3) Проблеми контролю та управління часом розробки.

Компонентно-орієнтована модель є розвитком спіральної моделі і також ґрунтується на еволюційній стратегії конструювання. У моделі конкретизується зміст квадранта конструювання - воно відбиває той факт, що в сучасних умовах нова розробка має ґрунтуватися на повторному використанні існуючих програмних компонентів. - Програмні компоненти, створені у реалізованих програмних проектах, зберігаються у бібліотеці. – У новому програмному проекті, виходячи із вимог замовника, виявляються кандидати у компоненти. – Далі перевіряється наявність цих кандидатів у бібліотеці. – Якщо кандидатів знайдено, то компоненти витягуються з бібліотеки та використовуються повторно. – Інакше створюються нові компоненти, вони застосовуються у проекті та включаються до бібліотеки. Переваги компонентно-орієнтованої моделі: 1) зменшує на 30% час розробки програмного продукту; 2) зменшує вартість програмної розробкидо 70%; 3) збільшує у півтора рази продуктивність розробки.

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

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

ХР-процес Екстремальне програмування (e. Xtreme Programming, XP) - полегшений (рухливий) процес (або методологія), (Кент Бек, 1999). ХР-процес орієнтований на групи малого та середнього розміру, що будують програмне забезпечення в умовах невизначених або швидко змінюються вимог. ХР-групу утворюють до 10 співробітників, які розміщуються в одному приміщенні. Основна ідея ХР – усунути високу вартість зміни, характерну для додатків з використанням об'єктів, патернів та реляційних баз даних. ХР-процес має бути високодинамічним процесом. ХР-група має справу зі змінами вимог протягом усього ітераційного циклу розробки, причому цикл складається з дуже коротких ітерацій. Чотирьма базовими діями у ХР-циклі є: кодування, тестування, вислуховування замовника та проектування. Динамізм забезпечується за допомогою чотирьох характеристик: безперервного зв'язку із замовником (і в межах групи), простоти (завжди вибирається мінімальне рішення), швидкої зворотнього зв'язку(за допомогою модульного та функціонального тестування), сміливості у проведенні профілактики можливих проблем.

Більшість принципів, що підтримуються в ХР (мінімальність, простота, еволюційний цикл розробки, мала тривалість ітерації, участь користувача, оптимальні стандарти кодування тощо), продиктовані здоровим глуздом і застосовуються у будь-якому впорядкованому процесі. У ХР ці принципи досягають «екстремальних значень». Більшість принципів, що підтримуються в ХР (мінімальність, простота, еволюційний цикл розробки, мала тривалість ітерації, участь користувача, оптимальні стандарти кодування тощо), продиктовані здоровим глуздом і застосовуються у будь-якому впорядкованому процесі. У ХР ці принципи досягають «екстремальних значень». Розглянемо структуру «ідеального» ХР-процесу. Основним структурним елементом процесу є ХР-реалізація, в яку багаторазово вкладається базовий елемент – ХР-ітерація. До складу ХР-реалізації та ХР-ітерації входять три фази - дослідження, блокування, регулювання.

Дослідження (exploration) – це пошук нових вимог (історій, завдань), які має виконувати система. Блокування (commitment) - вибір реалізації конкретного підмножини з усіх можливих вимог (іншими словами, планування). Регулювання (steering) - проведення розробки, здійснення плану життя. ХР рекомендує: – перша реалізація повинна мати тривалість 2 -6 місяців – тривалість інших реалізацій - близько двох місяців – кожна ітерація триває приблизно два тижні, – чисельність групи розробників вбирається у 10 людина. Приклад ХР-процесу для проекту з сімома реалізаціями, який здійснюється за 15 місяців - Процес ініціюється початковою дослідницькою фазою. – Фаза дослідження, з якої починається будь-яка реалізація та ітерація, має клапан «перепустки», на цій фазі приймається рішення щодо доцільності подальшого продовження роботи. – Передбачається: тривалість першої реалізації складає 3 місяці, тривалість другої – сьомий реалізацій – 2 місяці.

Друга – сьома реалізації утворюють період супроводу, що характеризує природу ХР-проекту. Кожна ітерація триває два тижні, крім тих, які відносять до пізньої стадії реалізації - «запуску у виробництво» (у цей час темп ітерації прискорюється). Найважча перша реалізація – пройти за три місяці від звичайного старту (скажімо, окремий співробітник не зафіксував жодних вимог, не визначено обмеження) до постачання замовнику системи промислової якості дуже складно.

Моделі якості процесів конструювання В умовах жорсткої конкуренції дуже важливо гарантувати висока якістьпроцесу конструювання ПЗ. Гарантію дає сертифікат якості процесу, що підтверджує його відповідність прийнятим міжнародним стандартам. Кожен стандарт фіксує свою модель забезпечення якості. Найбільш авторитетними є моделі стандартів: - ISO 9001: 2000; - ISO / IEC 15504; – Модель зрілості процесу конструювання ПЗ (Capability Maturity Model – СММ) Інституту програмної інженерії при американському університеті Карнегі-Меллон. Модель стандарту ISO 9001:2000 орієнтована процеси розробки з будь-яких сфер людської діяльності. Стандарт ISO/IEC 15504 спеціалізується на процесах програмної розробки та відрізняється вищим рівнем деталізації. Базовим поняттям моделі СММ вважається зрілість компанії – Незрілою називають компанію, де процес конструювання ПЗ та прийняті рішення залежать тільки від таланту конкретних розробників. Як наслідок, тут є висока ймовірність перевищення бюджету або зриву термінів закінчення проекту.

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

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

Рівень 4 (Керований). З переходом на керований рівень у компанії приймаються кількісні показники якості програмних продуктів, і процесу. Це забезпечує більш точне планування проекту та контроль якості його результатів. Основна відмінність від рівня 3 полягає у більш об'єктивній, кількісній оцінці продукту та процесу. Рівень 5 (оптимізуючий). Вищий рівеньмає на увазі, що головним завданнямкомпанії стає постійне покращення та підвищення ефективності існуючих процесів, введення нових технологій. Основна відмінність від рівня 4 полягає в тому, що технологія створення та супроводу програмних продуктів планомірно та послідовно вдосконалюється. Кожен рівень СММ характеризується областю ключових процесів(ОКП), причому вважається, кожен наступний рівень включає у собі всі характеристики попередніх рівнів. Область ключових процесів утворюють процеси, які при спільному виконанні призводять до досягнення певного набору цілей. Наприклад, ОКП 5-го рівня утворюють процеси: – запобігання дефектам; - Управління змінами технології; - Управління змінами процесу. Якщо всіх цілей ОКП досягнуто, компанії надається сертифікат цього рівня зрілості. Якщо хоча б жодної мети не досягнуто, то компанія не може відповідати даному рівню СММ

Управління проектами. Визначення та концепції Управління проектами, лише одна з 17 областей знань програмної інженерії, та й то допоміжна. Однак основною причиною більшості провалів програмних проектів є застосування неадекватних методів управління розробкою. Проект – це комплекс зусиль, що робляться з метою отримання конкретних унікальних результатів у межах відведеного часу та в межах затвердженого бюджету, що виділяється на оплату ресурсів, які використовуються чи споживаються під час проекту. [Арчібальд Р.]. Проект є комплекс дій, спрямованих на отримання унікального результату, будь то продукт або послуга. Мета проекту описує, які завдання мають бути вирішені в результаті проекту. Зміст проекту — що є результатом проекту. Для інформаційної системи – її функціональність. Управління проектом визначає “як”, за допомогою яких дій, буде досягнуто мети проекту та створено необхідний результат. У цьому, управління проектами може і має застосовуватися всіх етапах життєвого циклу проекту, т. е. управління проектом є стала діяльність.

З огляду на масштабності змісту проекту чи, наприклад, різнорідності його складових частин (наприклад, програмно-апаратний комплекс шифрування даних) проект може бути розбитий кілька більш дрібних проектів. Так як з будь-яким проектом асоційовані цілі, ресурси, час, ми можемо сформулювати, що управління проектами – є дисципліна застосування методів, практик та досвіду до проектної діяльності для досягнення цілей проектів за умови задоволення обмежень, що визначають їх рамки. Обмеження (constraints) у проектах. Найчастіше говорять про три основні обмеження або "залізний трикутник" 1. Зміст проекту 2. Часу 3. Вартість

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

У додатку до індустрії програмного забезпечення зазвичай додають четверте обмеження – якість (quality), прийнятне якість. Залежно від контексту та критеріїв якості, що обговорюються в конкретному випадку, “прийнятна” якість може розглядатися як необхідна, наприклад, задана вимогами якості та внутрішньокорпоративними стандартами.