Дисципліна: Інженерія програмного забезпечення
Модуль №1 " Області знань програмної інженерії. Моделі життєвого циклу для розробки програмних систем "
Тема: Програмна інженерія як фах. Базові поняття програмної інженерії.
Мета
1. Познайомити студентів з досягненнями в галузі програмної інженерії.
2. Вивчити сучасні методи інженерії та використовувати їх на практиці.
3. Освоєння підходів до поведінки менеджерів колективів при виконанні замовлення на розробку комп’ютерних програмних систем.
Зміст
Загальні відомості про дисципліну.
Поняття складності.
Системотехніка обчислювальних систем.
Проектування, конструювання ПЗ.
Супровід, управління інженерією ПЗ.
Домашнє завдання та контрольні питання.
Література
Соммервил И. Инженерия программного обеспечения. – М.: И.Д. «Вильямс», 2002. – 624 с.
Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений. – М.: ООО «И.Д. Вильямс», 2008. – 720 с.
Бабенко Л.П. Основи програмної інженерії. – К.: Т-во «Знання», КОО, 2001. – 269 с.
Загальні відомості про дисципліну.
Курс – 2 Семестр – 3, 4
Семестр - 3
2 модулі
Модуль №1 "Області знань програмної інженерії. Моделі життєвого циклу для розробки програмних систем"
Модуль №2 "Методи об'єктного аналізу та побудови моделей предметних областей. Прикладні та теоретичні методи програмування"
Лекції – 4(2+3(2= 14 год
Лабораторні заняття – (3(4+6)+(4+6+8)= 36 год
Домашнє завдання – 8 год
МКР - 2+2=4 год
Самостійна робота – 35 год
Ітого: - 97 год
Звітність: диференційований залік
Поняття складності.
Лікар, будівельник і програміст посперечалися про те, чия професія древнє. Лікар помітив: "У Біблії сказано, що Бог створив Еву з ребра Адама. Це міг зробити тільки хірург, тому моя професія сама древня у світі". Його перебив будівельник: "Однак, як сказано в Книзі Буття, ще раніше Бог створив з хаосу спочатку небо, а потім - землю. Це було перше й, безсумнівно, найбільш вражаюче будівництво. Отже, дорогий доктор, ви помиляєтеся. Саме моя професія сама древня у світі". Почувши це, програміст відкинувся на спинку крісла, посміхнувся й запитав довірчим тоном: "Ну а хто ж, по-вашому, створив хаос?"
"Чим складніше система, тим вона уязвимее" [5]. Важко собі представити будівельника, що міркує, а чи не вирити ще один підвальний поверх під уже побудованим стоэтажным будинком. Такий захід було б занадто дорогим і небезпечним. Як не дивно, користувачі програмного забезпечення, не замислюючись, просять робити аналогічні зміни в програмах. Більше того, він уважають, що для програміста це завдання не представляє ніяких труднощів.
Наша нездатність упоратися зі складністю, характерна до програмного забезпечення, приведе до затримок, додаткових витрат і порушень технічного завдання. Таку ситуацію часто називають кризою програмного забезпечення, але, відверто говорячи, хворобу, що триває настільки довго, варто називати нормальним станом. На жаль, ця криза вже привела до марнотратних витрат трудових ресурсів - найдорожчого товару, - і багато можливостей виявилися упущеними. Для того щоб створити нове програмне забезпечення, необхідне користувачам, зовсім не досить просто зібрати команду гарних програмістів. Крім того, у багатьох організаціях велика кількість персоналу змушена відволікатися на підтримку морально застарілих програм. З огляду на прямій і непрямий внесок, що вносить програмне забезпечення в економіку найбільш розвинених країн, а також величезні можливості, що з'являються завдяки інформатизації, варто визнати, що миритися з такою ситуацією більше не можна.
Приклади складних систем
Структура персонального комп'ютера
Персональний комп'ютер - це пристрій середньої складності. Більшість персональних комп'ютерів складається з тих самих основних елементів: центрального процесора (central processor unit - CPU), монітора, клавіатури й зовнішнього запам'ятовувального пристрою, як правило, CD- або DVD-дисководу й жорсткого диска. Кожної із цих компонентів можна, у свою чергу, розкласти на більше дрібні складові частини. Наприклад, центральний процесор звичайно складається з первинної пам'яті, арифметико-логічного пристрою (arithmetic/ logic unit - ALU) і шини, до якої приєднані периферійні пристрої. Кожну із цих частин також можна розкласти на компоненти: арифметико- логічний пристрій складається з регістрів і схем довільного керування (random control logic), які у свою чергу складаються із ще більш простих деталей: вентилів, інверторів і т.д.
Цей приклад демонструє ієрархічну природу складної системи. Нормальна робота персонального комп'ютера забезпечується тільки взаємодією всіх його складових частин. Разом узяті, ці окремі частини утворять логічне ціле. Дійсно, щоб зрозуміти, як працює комп'ютер, необхідно розділити його на компоненти й розглянути їх окремо. Отже, роботу монітора й жорсткого диска можна вивчати незалежно друг від друга. Точно так само можна вивчати арифметико-логічний пристрій, не обертаючи уваги на підсистему первинної пам'яті.
Ієрархія характерна не тільки для складних систем, але й для абстракцій. У розглянутому вище прикладі компонентам персонального комп'ютера відповідають певні поняття, що утворять рівні абстракції. Кожному із цих рівнів відповідає сукупність пристроїв, взаємодія яких забезпечує функціонування компонентів більше високого рівня. Конкретний рівень абстракції можна вибирати, виходячи з певних заздалегідь потреб. Наприклад, для дослідження синхронізації первинної пам'яті доцільно розглянути комп'ютер на рівні вентилів. У той же час цей рівень абстракції неприйнятний, якщо потрібно знайти помилку в електронній таблиці.
Структура рослин і тварин
Ботаніки прагнуть зрозуміти подібність і розходження між рослинами, вивчаючи їхню морфологію, тобто форму й структуру. Рослини - це складні багатоклітинні організми, поводження яких, наприклад, фотосинтез і випар вологи, забезпечується взаємодією різних органів.
Рослини складаються із трьох основних частин - корінь, стебел і листів. Кожна із цих частин має особливу структуру. Наприклад, корінь складається з відростків, волосків, верхівки й чехлика. Аналогічно, вивчаючи зріз аркуша, можна виявити эпидермис, мезофилл і судинну тканину. Кожна із цих структур, у свою чергу, являє собою сукупність кліток. Усередині кожної клітки можна виявити новий рівень складності, що охоплює хлоропласти, ядро й т.д. Як і комп'ютер, рослина являє собою ієрархію певних компонентів, кожний рівень якої характеризується власною складністю.
Всі частини, що ставляться до тому самому рівня абстракції, взаємодіють цілком певним чином. Розглядаючи рослину на вищому рівні абстракції, можна виявити наступну картину. Корінь поглинають із ґрунту воду й мінеральні речовини й передають їхнім стеблам. Стебла доставляють ці речовини листам, які, у свою чергу, за допомогою фотосинтезу роблять із них необхідні живильні елементи.
Між різними рівнями абстракції завжди існує чітка границя. Наприклад, компоненти аркуша спільно забезпечують його функціонування як єдиного цілого й майже не взаємодіють із елементами корінь. Простіше говорячи, між частинами, що ставляться до різних рівнів абстракції, існує чіткий поділ функцій.
У комп'ютері вентилі є елементами як центрального процесора, так і жорсткого диска. У різних частинах рослини також можна знайти загальні структурні елементи. Так Бог заощаджує засобу вираження. Наприклад, клітки служать основними будівельними блоками всіх структур рослини. Зрештою, корінь, стебла й листи рослини складаються саме із кліток. Однак існує безліч різновидів кліток. Наприклад, одні клітки містять хлоропласти, а інших - ні, оболонки одних кліток пропускають воду, а інших - ні, крім того, клітка може бути живий або мертвої.
Вивчаючи морфологію рослини, неможливо виділити окремі частини, відповідальні за якусь одну невелику фазу єдиного великого процесу, наприклад, фотосинтезу. У рослині не існує централізованих частин, що безпосередньо координують діяльність компонентів, що ставляться до більше низьких рівнів. Замість цього в ньому існують окремі частини, що діють як незалежні агенти, кожна з яких має досить складне поводження, що є частиною функцій більше високого рівня. Більше високий рівень функціонування рослини забезпечується тільки завдяки цілеспрямованій взаємодії незалежних агентів. У теорії складності це явище називається похідним поводженням (emergent behaviour): поводження цілого складніше, ніж поводження суми його складових [6].
Звернувшись до зоології, можна з'ясувати, що багатоклітинні тварини, як і рослини, мають ієрархічну структуру: сукупності кліток формують тканини, що утворять органи, групи яких визначають систему (наприклад, травну) і т.д. Тут також проявляється економія засобів вираження, характерна для Бога. Основними цеглинками, з яких складаються як тварини, так і рослини, є клітки. Зрозуміло, клітки рослин і тварин відрізняються друг від друга. Наприклад, клітки рослин укладені у тверду целюлозну оболонку, а клітки тварин - немає. Незважаючи на ці розходження, обидві ці структури, безсумнівно, є клітками. Це явище являє собою приклад спільності різних організмів.
Крім того, у рослинах і тваринах існує величезна кількість механізмів надклітинного рівня. І рослини, і тварини використають судинну систему для транспортування живильних речовин усередині організму, а між індивідуумами того самого виду існують полові розходження.
Структура матерії
Дослідження в таких різних областях, як астрономія і ядерна фізика, дають багато інших прикладів неймовірно складних систем. Ці наукові дисципліни демонструють приклади ієрархічних систем нового типу. Астрономи вивчають галактики, які об'єднані в скупчення. У свою чергу, галактики складаються із зірок, планет і інші небесних тел. Фахівці з ядерної фізики зіштовхуються зі структурною ієрархією фізичних тіл зовсім іншого масштабу. Атоми складаються з електронів, протонів і нейтронів; електрони є елементарними частками, а протони й нейтрони діляться на ще більш дрібні компоненти - кварки.
У цих складних ієрархіях знову виявляються універсальні механізми. Зокрема, у Всесвіті діють усього чотири типи сил: гравітаційна, електромагнітна, сильна й слабка взаємодії. Багато законів фізики, що стосуються цих взаємодій, наприклад, закон збереження енергії й імпульсу, носять універсальний характер, поширюючись як на галактики, так і на кварки.
Структура суспільних інститутів
Як останній приклад складних систем звернемося до суспільних інститутів. Люди поєднуються в групи для рішення завдань, які не можуть бути вирішені індивідуумами. Одні організації є тимчасовими, інші існують протягом декількох поколінь. Ніж крупніше організація, тим отчетливее проявляється її ієрархічна структура. Наприклад, транснаціональні корпорації складаються з компаній, які у свою чергу утворяться підрозділами, що включають у себе філії, якою належать місцеві офіси й т.д. Якщо організація проходить випробування часом, то границі між її частинами можуть змінитися, а потім може виникнути нова, більше стійка ієрархія.
Отношения між різними частинами великої організації нагадують відносини між компонентами комп'ютера, рослини або галактики. У той же час, ступінь взаємодії між співробітниками одного офісу вище, ніж між співробітниками двох різних офісів. Поштовий службовець, наприклад, як правило, не спілкується з виконавчим директором компанії, а в основному контактує зі своїми колегами по поштовій відділення. Однак при цьому різні рівні організації об'єднані загальними механізмами. Так, робота службовця й директора оплачується однієї й тією же фінансовою організацією, причому вони обоє використають загальне встаткування, зокрема, телефонну систему компанії.
Визначення складності програмного забезпечення
Як відомо, не всі системи програмного забезпечення є складними. Існує добре забутий клас додатків, проектованих, розроблювальною, супроводжуваною й використовуваних тим самим людиною, - або починаючим програмістом, або професіоналом, що працює поодинці. Це не виходить, що такі системи погано спроектовані й неелегантні. Тим більше, ніхто не ставить під сумнів кваліфікацію їхніх творців. Просто такі системи, як правило, мають дуже обмежену область застосування й дуже недовго використаються. Як правило, їх простіше замінити новими програмами, чим намагатися повторно використати, переробляти або вдосконалювати. Розробка таких додатків скоріше стомлююча, чим складна, тому вони не представляють для нас інтересу.
Предметом нашого дослідження є проблеми розробки промислового програмного забезпечення. У цій області можна знайти програми, що демонструють самі різні види поводження, наприклад, системи зі зворотним зв'язком, які управляють або управляються подіями фізичного миру при обмежених ресурсах часу й пам'яті; програми, що підтримують цілісність баз даних, що містять сотні тисяч записів і обеспечивающих паралельне відновлення й запити; системи керування й контролю за реальними об'єктами, наприклад, системи керування повітряними або залізничними перевезеннями. Такі системи звичайно використаються досить довго, і згодом від їхнього нормального функціонування починають залежати багато користувачів. У галузі промислового програмування також існують засобу, що спрощують створення додатків у конкретних предметних областях, а також програми, що імітують деякі аспекти людського інтелекту.
Найважливішою особливістю промислової програми є її висока складність. Одному програмістові не під силу вирішити всі проблеми, пов'язані із проектуванням такої системи. Грубо говорячи, складність промислових програм перевищує інтелектуальні можливості окремої людини. На жаль, ця властивість є істотною характеристикою всіх великих систем програмного забезпечення. Слово "істотна" означає, що зі складністю промислових програм можна впоратися, але ігнорувати її не можна.
Чому програмному забезпеченню властива складність?
Брукс затверджує: "Складність програмного забезпечення є істотним, а не випадковою властивістю" [3]. Це пояснюється чотирма причинами: складністю предметної області, труднощами керування розробкою програмного забезпечення, необхідністю забезпечити гнучкість програм, а також складністю опису функціонування дискретних систем.
Складність предметної області
Намагаючись вирішити проблеми за допомогою програмного забезпечення, ми неминуче зіштовхуємося з необхідністю задовольнити безліч різних, іноді взаємовиключних вимог. Розглянемо вимоги, пропоновані до електронної системи багатомоторного літака, комутатору стільникового телефону й автономного робота. Механізми функціонування таких систем уже самі по собі досить складні для розуміння, а якщо додати до цьому додаткові вимоги (часто неявні), такі як зручність, продуктивність, вартість, стійкість і надійність, то складність завдання може стати довільної, про що й попереджав Брукс.
Ця зовнішня складність звичайно породжується "недорозумінням", що існує між користувачами системи і її розробниками, оскільки користувачам дуже важко виразити свої потреби у формі, зрозумілої розроблювач. Іноді користувач дуже смутно уявляє собі, що йому потрібно від майбутньої системи програмного забезпечення. Це не можна назвати провиною користувачів або розробників; просто кожна із цих груп випробовує недолік знань у предметній області іншої групи. Користувачі й розробникі часто по-різному бачать сутність проблеми й пропонують різні способи її рішення. Насправді, навіть якщо користувач точно знає, що йому потрібно, його вимоги дуже важко формалізувати. Як правило, вони описуються в багатотомних документах, проілюстрованих декількома малюнками. Такі документи важко зрозуміти, вони допускають неоднозначну інтерпретацію й дуже часто містять інформацію, що ставиться скоріше до проектування, а не виражають основні вимоги замовника.
Вимоги, пропоновані до системи програмного забезпечення, у процесі розробки часто змінюються. Це ще більше підвищує її складність. Як правило, технічне завдання коректується через те, що в процесі проектування системи постановка завдання поступово уточнюється. Знайомлячи з першими результатами, описаними в проектній документації й реалізованими в прототипах, а також використовуючи систему після її інсталяції, користувачі починають краще розуміти й чіткіше формулювати свої реальні потреби. У той же час, цей процес дозволяють розроблювачам вникнути в предметну область і ставити більше точні питання, що проясняють темні місця проектованої системи.
Оскільки велика система програмного забезпечення завжди пов'язана з інвестуванням засобів, ми не можемо дозволити собі викидати існуючу систему при кожній зміні технічного завдання. Системи згодом еволюціонують, за планом або спонтанно. Іноді цей процес помилково називають супроводом програмного забезпечення. Точніше кажучи, супроводом (maintenance) називається виправлення виявлених помилок, еволюцією (evolution) — реакція на зміну технічних вимог, а збереженням (preservation) — спроба всіма можливими продовжити способами функціонування застарілих і частин, що розпадаються, програмного забезпечення. На жаль, як показує досвід, значна частка ресурсів, виділених на розробку програмних систем, витрачається саме на збереження.
//
Завдання групи проектувальників - створити ілюзію простоти
Труднощі керування проектуванням
Основне завдання розроблювачів програмного забезпечення — створити ілюзію простоти, щоб захистити користувачів від величезної й часто довільної складності проекту. Очевидно, що великий масштаб системи програмного забезпечення не ставиться до її основних достоїнств. Для зменшення розмірів програм винаходяться хитромудрі й потужні методи, що створюють ілюзію простоти й дозволяють повторно використати існуючі коди й проектні рішення. Проте вимоги, пропоновані до системи, часто змушують проектувальників або створювати заново велика кількість програм, або використати існуючий код, адаптуючи його до нових умов. Усього кілька десятиліть назад програми обсягом у кілька тисяч рядків, написані на асемблері, вражали уяву. У цей час нікого не дивують системи програмного забезпечення, розмір яких обчислюється десятками тисяч або навіть мільйонів рядків (причому на мовах високого рівня). Жодна людина ніколи не зможе повністю зрозуміти таку систему. Навіть якщо розкласти її на складові частини, прийде аналізувати сотні, а іноді й тисячі окремих модулів. Такий обсяг робіт під силу лише команді розроблювачів, состав якої в ідеалі повинен бути мінімальним. Незалежно від кількості розроблювачів, перед ними постійно виникають складні проблеми, пов'язані з колективним проектуванням. Чим більше розроблювачів, тим складніше зв'язку між ними й тем сутужніше координувати їхня взаємодія, особливо якщо учасники робіт географічно вилучений друг від друга, що відбувається досить часто. Таким чином, при колективній розробці програмного забезпечення головним завданням керівництва є забезпечення єдності й цілісності проекту.
Необхідність забезпечення гнучкості програм
Будівельні компанії звичайно не мають власного лісового господарства, що поставляло б їм ліс для виробництва пиломатеріалів, і не володіють металургійними заводами, що виготовляють сталеві балки для майбутніх будинків. Однак у програмній індустрії така практика одержала широке поширення. Програмування має граничну гнучкість і дозволяє проектувальникові виражати абстракції будь-якого рівня. Ця гнучкість досить приваблива, оскільки вона спонукує розроблювача самостійно створювати практично всі базові конструкції, з яких складаються абстракції більше високих рівнів. На відміну від будівельної промисловості, у якій існують загальноприйняті вимоги до якості матеріалів, у програмній індустрії таких стандартів майже немає. У результаті проектування програмного забезпечення залишається трудомісткою справою.
Складність опису дискретних систем
Кидаючи м'яч у повітря, ми можемо точно пророчити його траєкторію, тому що в нормальних умовах діють певні фізичні закони. Ми б дуже зачудувалися, якби, кинувши м'яч ледве сильніше, виявили, що на середині шляху він зненацька зупинився й полетів вертикально нагору . У недостатньо налагодженій програмі моделювання польоту м'яча така ситуація цілком можлива.
Усередині великого додатка можуть існувати сотні й навіть тисячі змінних, а також кілька потоків керування. Стан прикладної програми в кожний момент часу описується сукупністю всіх змінних, їхніх поточних значень, адрес і стеків виклику для кожного процесу. Тому що програма виконується на цифрових комп'ютерах, виникає система з дискретними станами. Аналогові системи, такі як рух кинутого м'яча, навпаки, є безперервними. Парнас (Ратаї) затверджує: "Коли ми говоримо, що система описується безперервною функцією, ми маємо на увазі, що в ній немає схованих сюрпризів. Невеликі зміни вхідних параметрів завжди викликають невеликі зміни результатів" [4]. З іншого боку, дискретні системи мають кінцеве число можливих станів. У великих системах спостерігається так званий комбінаторний вибух, що робить це число дуже більшим. Проектуючи системи, розроблювачі, як правило, розділяють їх на компоненти так, щоб одна частина якнайменше впливала на іншу. Однак переходи між дискретними станами неможливо моделювати за допомогою безперервних функцій. Кожна подія, зовнішнє стосовно системи, може перевести її в новий стан, і, більше того, перехід з одного стану в інше не завжди є детермінованим. У найгіршому разі зовнішня подія може ушкодити систему через те, що її творці не передбачили всі можливі варіанти. Якщо в програмному забезпеченні рухової установки корабля виникне переповнення пам'яті, викликане некоректними вхідними даними (як це відбулося один раз у дійсності), наслідки можуть виявитися дуже серйозними. Ще недавно в програмному забезпеченні систем керування метрополітеном, автомобілями, супутниками, повітряним рухом, складами й т.д. спостерігався різкий ріст кількості збоїв. У безперервних системах таке поводження було б малоймовірним, але в дискретних системах будь-яка зовнішня подія може вплинути на будь-яку частину внутрішнього стану системи. Очевидно, це є основним стимулом для інтенсивного тестування систем програмного забезпечення. Проте, за винятком найпростіших систем, що вичерпує тестування провести неможливо. У цей час немає ні математичних інструментів, ні інтелектуальних можливостей для повноцінного моделювання поводження більших дискретних систем. Отже, ми повинні задовольнитися прийнятним рівнем впевненості в їхній правильній роботі.
1.3 П'ять ознак складної системи
Вивчаючи природу складності, ми виділили п'ять ознак, властивих будь-які складній системі.
Ієрархічна структура
Випливаючи роботі Саймона (Simon) і Эндо (Ando), Куртуа (Courtois) затверджує наступне.
Часто складність проявляється у вигляді ієрархії, при цьому складні системи складаються із взаємозалежних підсистем, що мають, у свою чергу, власні підсистеми, і т.д., аж до найнижчого рівня, утвореного елементарними компонентами. [7]
Саймон відзначає: "Той факт, що багато складних систем мають майже розкладену, ієрархічну структуру, є головним чинником, що дозволяє нам зрозуміти, описати й навіть "побачити" такі системи і їхні частини" [8]. Дійсно, схоже на те, що можна зрозуміти лише системи, що мають ієрархічну структуру
Важливо відзначити, що архітектура складних систем залежить як від компонентів, так і від ієрархічних відносин між ними. "Всі системи мають підсистеми, і всі системи є частинами більших систем... Сутність системи визначається відносинами між її частинами, а не частинами як такими" [9].

Архітектура складної системи залежить як від її компонентів, так і від ієрархічних відносин між ними
Відносність вибору елементарних компонентів
Досвід дослідження природи елементарних компонентів складних систем показує наступне.
Як правило, спостерігач довільно вирішує, які компоненти в даній системі вважати елементарними.
Елементарний компонент із погляду одного спостерігача може виявитися на набагато більше високому рівні абстракції з погляду іншого.
Поділ функцій
Саймон називає ієрархічні системи розкладеними (decomposable), оскільки їх можна розділити на идентифицируемые частини, і майже розкладеними (nearly decomposable), тому що їхні складові не є абсолютно незалежними друг від друга. Це приводить нас до наступної загальної властивості всіх складних систем:
Зв'язку усередині компонентів звичайно сильніше, ніж зв'язку між компонентами. Ця обставина дозволяє відокремити "високочастотну" динаміку компонентів, - стосовну до їхньої внутрішньої структури, - від "низькочастотної" динаміки, - стосовної до взаємодії між компонентами" [10].
Це розходження між усередині- і межкомпонентными взаємодіями дозволяє провести поділ функцій (separation of concerns) між частинами системи й вивчати їх окремо.
Загальна структура
Як ми вже відзначали, багато складних систем реалізуються за допомогою ощадливих засобів вираження. Це дозволило Саймону затверджувати наступне.
"Ієрархічні системи звичайно складаються з деяких типів підсистем, по-різному скомбінованих і організованих" [11].
Інакше кажучи, складні системи мають загальну структуру. Це може проявлятися у вигляді повторного використання як дрібних компонентів, наприклад, кліток організму, так і більших структур, таких як судинні системи, наявні й у рослин, і у тварин.
Стійкі проміжні форми
Як відзначалося вище, складні системи еволюціонують у часі. Зокрема, уважається, що "складні системи розвиваються із простих набагато швидше, якщо вони мають стійкі проміжні форми" [12]. Цю думку можна виразити більш ефектно.
"Будь-яка працездатна складна система є підсумком еволюції більше простої працездатної системи... Складна система, розроблена "з нуля", ніколи не працює тому що треба, і ніякі "заплатки" не змусять її працювати правильно. Проектування варто починати із простої працездатної системи" [13].
У процесі еволюції системи об'єкти, що спочатку вважалися складними, стають елементарними компонентами, з яких створюються ще більш складні системи. Більше того, правильні елементарні об'єкти неможливо створити відразу: спочатку з ними необхідно попрацювати, получше вивчити реальне поводження системи й лише потім удосконалити.
2. Системотехніка обчислювальних систем
Ціль дійсної глави - дати введення в і пояснити, чому знання в цій області важливі для фахівців але програмному забезпеченню. Прочитавши цю главу, ви повинні:
розуміти, чому програмне забезпечення все тире застосовується в розробках системотехніки;
знати основні інтеграційні характеристики систем: безвідмовність, продуктивність, надійність і безпека;
розуміти, чому в процесі розробки систем необхідно враховувати оточення, у якому буде працювати система;
мати подання про процеси створення систем і системного забезпечення.
Інтеграційні властивості систем
Система і її оточення
Моделювання систем
Процеси створення систем
Придбання систем
Системотехніка, як технологія створення систем, охоплює процеси створення специфікацій, проектування, розробки, тестування, впровадження й супроводи систем як єдиного цілого. Системотехнік, що займається розробкою обчислювальних систем, не зосереджений тільки на програмному забезпеченні, він приділяє рівну увагу програмному забезпеченню, апаратним засобам і засобам взаємодії з користувачами й системним оточенням. Він повинен думати про ті функції, які буде виконувати система й, властиво, заради яких будується система, а також про взаємодію системи з її оточенням. Фахівець зі створення програмного забезпечення повинен розуміти завдання системотехніки, оскільки виникаючі проблеми часто є результатом рішень, прийнятих системотехніками.
Існує безліч найрізноманітніших визначень поняття "система4, від дуже абстрактних до надзвичайно конкретних. З мого погляду, найбільш удалим визначенням системи буде наступне.
Система - це сукупність взаємодіючих компонентів, що працюють спільно для досягнення певних цілей.
Це визначення охоплює дуже широке коло систем. Наприклад, така проста система, як олівець, складається із двох або декількох "апаратних" компонентів, у той час як система керування польотами може складатися з тисяч апаратних і програмних компонентів плюс оператори, які приймають рішення на основі даних, надаваних інформаційними підсистемами.
Визначальною ознакою системи є те, що властивості й поводження системних компонентів впливають один на одного надзвичайно складним і заплутаним образом. Коректне функціонування кожного системного компонента залежить від функціонування багатьох інших компонентів. Так, операційне забезпечення може виконувати свої функції, якщо тільки працює процесор і відповідні апаратні засоби. Процесор може виконувати обчислення, якщо тільки коректно інстальовані програмні системи, що задають ці обчислення.
Системи часто мають ієрархічну структуру, тобто як компоненти містять інші системи. Наприклад, комп'ютерна система поліції містить географічну інформаційну систему, що пропонує інформацію про місце, де трапилося або може трапитися яку-небудь подію. Системи, які є компонентами інших систем, називаються підсистемами. Визначальна властивість підсистем полягає в тім, що вони можуть функціонувати самостійно, незалежно від тих систем, до складу яких входять. Тому географічну інформаційну систему можна використати також в інших системах. Разом з тим їхнє поводження в складі якої-небудь конкретної системи залежить, звичайно, від взаємодії з іншими підсистемами.
Схибність взаємодії між системними компонентами означає, що система не зводиться просто до суми її складових частин. Вона має певні властивості, які властиві їй саме як цілісній системі. Такі інтеграційні властивості не можуть бути властивостями якої-небудь окремої частини системи. Більше того, вони проявляються тоді, коли система розглядається як єдине ціле. Деякі із цих властивостей можна вивести з аналогічних властивостей окремих підсистем, але частіше вони є комплексним результатом взаємодії всіх підсистем і їх неможливо оцінити, виходячи з аналізу окремих системних компонентів.
Приведемо приклади інтеграційних властивостей.
1. Сумарний розмір системи. Це приклад інтеграційного показника системи, якому можна обчислити, виходячи тільки із властивостей окремих компонентів.
Безвідмовність системи. Ця властивість залежить від безвідмовності окремих компонентів і взаємозв'язку між ними.
Зручність експлуатації системи. Це дуже складне многопараметрическое властивість, що залежить не тільки від програмного забезпечення й апаратних засобів системи, але також від оточення, у якому експлуатується система, і від системних операторів.
У цій книзі основна увага приділяється обчислювальним системам, які складаються з апаратних і програмних компонентів і, як правило, мають підсистеми для взаємодії з людиною. Фахівець із програмного забезпечення повинен знати системотехніку обчислювальних систем, оскільки тут програмний компонент грає дуже важливу роль. Наприклад, в 1969 році для здійснення посадки людини на Місяць у програмі "Аполлон" використалося ПО, що займає всього 10 Мбайт, а ПО космічній станції- 100 Мбайт. Таким чином, технології інженерії програмного забезпечення часто є критичним чинником при розробці складних обчислювальних систем.
2.1. Інтеграційні властивості систем
Як відзначалося вище, інтеграційні властивості систем проявляються тільки тоді, коли система розглядається як єдине ціле. У цьому складається складність прогнозування й оцінки таких властивостей, оскільки іноді можна виміряти показники тільки підсистем, з яких складається комплексна система.
Існує два типи інтеграційних властивостей.
Функціональні властивості, які проявляються тільки тоді, коли система працює як єдине ціле. Наприклад, велосипед має функціональні властивості транспортного засобу тільки тоді, коли зібраний зі своїх компонентів.
Нефункціональні властивості: безвідмовність, продуктивність, безпека й захищеність (обмеження несанкціонованого доступу до системи), які залежать від поводження системи в операційному оточенні. Такі властивості часто критичні для обчислювальних систем, оскільки якщо вони не досягають певного мінімального рівня, то система не буде працездатною. Деякі функції й можливості системи можуть бути не затребувані всіма користувачами, так що система може бути працездатної й без них. Разом з тим система, не надійна або не ефективна у своїх окремих функціях, однаково вважається бракованою.
Щоб проілюструвати складність у визначенні інтеграційних властивостей, розглянемо такий показник системи, як безвідмовність. Це комплексні показники, що завжди варто розглядати на рівні системи, а не її окремих компонентів. Компоненти в системі взаємозалежні, так що збій в одному компоненті може поширитися по всій системі й викликати відповідну реакцію в інших компонентах. Проектувальники систем часто не можуть угадати послідовність поширення збоїв у системі, тому важко оцінити безвідмовність системи тільки на підставі даних про безвідмовність її окремих компонентів.
Існує три тісно зв'язаних між собою фактора, які впливають на загальну безвідмовність системи.
1. Безвідмовність апаратних засобів. Ці показники визначається ймовірністю виходу з ладу окремих апаратних компонентів і часом, необхідним па їхню заміну.
Безвідмовність програмного забезпечення. Це показники роботи компонента ПО без збоїв і помилок. Програмні помилки звичайно не роблять впливу на апаратні засоби системи. Тому система може продовжувати функціонувати навіть тоді, коли ПО видає некоректні результати. Безвідмовність програмного забезпечення докладно розглядається в главах 16 і 17.
Помилки операторів. Оператори, що експлуатують систему, також можуть допускати помилки у своїй діяльності.
Всі перераховані фактори тісно зв'язані між собою. Збої в апаратних засобах можуть породити помилкові сигнали, які потім надходять на вхід програмних компонентів, що, у свою чергу, може привести до непередбаченого поводження програмного забезпечення. Оператори звичайно допускають помилки в позаштатних ситуаціях, коли система поводиться незвичайним образом. Такі ситуації часто породжуються якими-небудь збоями в системі. Неправильних дій оператора, у свою чергу, можуть спровокувати збої й помилки в роботі апаратних засобів, що також може привести до подальшого поширення збійних і помилкових сигналів по системних ланцюгах. Таким чином, невелика помилка, що виникла в одній підсистемі й у принципі легко переборна, може привести до ситуації, що вимагає повного відключення системи.
Безвідмовність системи також залежить від оточення, у якому вона експлуатується. Як вказувалося вище, важко передбачати системне оточення, у якому буде експлуатуватися система. Інакше кажучи, складно описати оточення у вигляді обмежень, які повинні враховуватися при розробці системи. Підсистеми, що становлять цілісну систему, можуть по-різному реагувати на зміни в системному оточенні, тим самим впливаючи на загальну безвідмовність системи самим непередбаченим образом. Внаслідок цього, навіть якщо система є єдиним цілим, буває важко або зовсім неможливо виміряти рівень її безвідмовності.
Допустимо, система призначена для експлуатації при нормальній кімнатній температурі. Для того щоб система могла функціонувати при інших температурних режимах, рє електронні компоненти повинні бути розраховані для роботи в певному температурному інтервалі, скажемо, від 0 до 45°. При виході із цього температурного інтервалу компонента можуть поводитися непередбаченим образом. Тепер припустимо, що система є внутрішньою складовою частиною повітряного кондиціонера. Якщо кондиціонер несправний і жене гаряче повітря через електронні компоненти, то вони, а отже, і вся система можуть вийти з ладу. Якщо кондиціонер працює нормально, то система також повинна працювати нормально. Але внаслідок фізичної замкнутості кондиціонера можуть виникнути непередбачені впливи різних компонентів пристрою один на одного, що також може привести до різних збоїв.
Подібно безвідмовності, інші інтеграційні характеристики (такі, як продуктивність і зручність експлуатації) також важкі для визначення, але можуть бути оцінені в процесі експлуатації системи. Оцінка інших властивостей, наприклад безпеки системи і її захищеності, породжує більші складності. Ці властивості не просто властиві працюючій системі, вони відбивають ті характеристики, які вона не показує. Наприклад, при розробці мір захищеності, де одним з показників є неможливість несанкціонованого доступу до даних, порівняно легко прорахувати всі можливі режими доступу до даних і виключити небажані. Тому оцінити рівень захищеності можна тільки через характеристики системи, властиві їй за замовчуванням. Більше того, система буде вважатися захищеності, що володіє властивістю, доти, поки хто-небудь не зламає її засобу захисту.
2.2. Система і її оточення
Будь-яка система залежить від сигналів, даних або іншої інформації, що надходить на її входи; іншими словами, система функціонує в певному оточенні, що впливає на її функціонування й продуктивність. Іноді оточення можна розглядати як самостійну систему, що складається з безлічі інших систем, які впливають один на одного.
На мал. 2.1 показано кілька систем, об'єднаних у систему життєзабезпечення офісного будинку. Система опалення, електроенергетична система, система висвітлення, системи водопостачання й каналізації й система безпеки є підсистемами будови, що, у свою чергу, також можна розглядати як систему. Будинок розташований на вулиці, що також є системою більше високого рівня. Вулиця буде підсистемою системи міста й т.д. Таким чином, оточення якої-небудь системи саме є системою більше високого рівня. У загальному випадку оточення якої-небудь системи - це композиція її локального оточення й оточення системи більше високого рівня.

Рис. 2.1. Ієрархія систем
Розглянемо систему безпеки, що входить у систему життєзабезпечення будинку (див. мал. 2.1). Її локальне оточення складається з інших систем цього будинку. До оточення системи також необхідно віднести системи, що не входять у систему будинки, але стосовні до системи вулиці й системі міста, включаючи природні природні системи, у тому числі погодну (тобто вплив погодних факторів па систему безпеки).
Приведемо дві основні причини, якими викликана необхідність ураховувати при розробці систем їхнє оточення.
У багатьох випадках система призначена саме для реагування на зміну певних параметрів оточення. Так, система опалення реагує па зміни в навколишнім середовищі, підвищуючи або знижуючи температуру своїх опалювальних приладів. Тут правильне функціонування системи проявляється саме як реакція на зміни параметрів оточення.
Часто якість функціонування системи може залежати від параметрів оточення самим непередбаченим образом. Так, система електропостачання прямо залежить від вуличного оточення будинку. Наприклад роботи, проведені по благоустрої вулиці, по недогляду можуть ушкодити силовий кабель і, отже, вивести з ладу всю систему електропостачання будинку. Або грозовий розряд може індуцировати велики струми в електричній системі, що може порушити її нормальне функціонування.
Крім фізичного оточення (навколишнього середовища), показаного на мал. 2.1, системи можуть перебувати в певних відносинах з організаційним оточенням, що містить у собі правила й процедури, засновані на політичних, економічних і екологічних пріоритетах суспільства. Якщо система побудована без обліку організаційного оточення, вона може не знайти попиту на ринку системних продуктів і буде відкинута користувачами й потенційними споживачами.
На розробку систем впливають як людські, так і організаційні фактори, що входять в оточення системи.
Експлуатаційний фактор. Чи вимагає система внесення змін у робочий процес її експлуатації, залежно від зміни параметрів оточення? Якщо відповідь на це питання позитивний, отже, необхідне навчання персоналу, що експлуатує цю систему. Якщо навчання тривале або персонал може втратити в заробітку, існує ймовірність, що така система буде відкинута підлога ьзовател ями.
Фактор персоналу. Чи може впровадження системи привести до зниження вимог до кваліфікації персоналу або докорінно змінити способи його роботи? Якщо це так, тоді персонал може спробувати протистояти впровадженню системи в їхню організацію. Менеджери середньої ланки, що керують проектами, часто підозрюють, що їхній статус в організації понизиться після впровадження комп'ютерних систем.
Організаційний фактор. Іноді впровадження системи може змінити структуру владних повноважень в організації. Наприклад, якщо діяльність організації прямо залежить від правильного функціонування складної системи, оператори цієї системи можуть мати значна вага у владній структурі організації.
*
Ці людські, соціальні й організаційні фактори часто виявляються критичними при ухваленні рішення про те, буде або ні впроваджуватися система. На жаль, передбачити ці фактори дуже складно, особливо якщо розроблювачі системи не мають достатній соціальний і культурний досвід. Щоб допомогти передбачити різні ефекти від впровадження систем в організацію, розроблені спеціальні методології, такі як социотехника Мамфорда (Мишрогс!) [243], методологія програмних систем Чекланда (Сьеск!апс1) [69, 70]. Поглиблене соціологічне дослідження ефектів впровадження обчислювальних систем наведено в роботі [3].
В ідеалі всі відомості про системне оточення варто включити в специфікацію системи для того, щоб розроблювачі могли їх урахувати при її проектуванні. Але в реальній дійсності це неможливо. Звичайно розроблювачі систем роблять припущення про системне оточення або на основі досвіду експлуатації інших подібних систем, або виходячи зі здорового глузду. Якщо вони помиляться, то система може в деяких ситуаціях функціонувати некоректно. Наприклад, якщо розроблювачі не врахують можливі електромагнітні наведення на систему, то вона може вийти з ладу, якщо поблизу її розташовуються інші системи з більшим електромагнітним випромінюванням.
2.3. Моделювання систем
У процесі формалізації вимог до системи й на етапі проектування система розглядається як сукупність компонентів і взаємозв'язків між ними. Для цього використаються моделі системної архітектури, які в графічному виді надають всю організацію системи, тобто її компоненти й взаємозв'язки між ними.
Архітектура системи звичайно представляється у вигляді блокової діаграми (блок-схеми), де блоки відповідають основним підсистемам, а існуючі зв'язки між підсистемами позначаються лініями зі стрілками, що з'єднують окремі блоки діаграми. Зв'язку можуть відповідати потокам даних, послідовності включення підсистем у роботу або які-небудь інші типи залежності.
На мал. 2.2 представлена блок-схема основних компонентів системи сигналізації, що попереджає про несанкціоноване проникнення в житло. У табл. 2.1 наведене короткий опис підсистем, яким відповідають певні блоки на мал. 2.2.

Рис. 2.2. Проста система сигналізації
Таблиця 2.1. Функціональні підсистеми системи сигналізації
Підсистема
Опис

Датчики руху
Реагують на рух у кімнатах, які контролює система

Дверні датчики
Визначають, чи відкриті зовнішні двері будинку

Контролер
Управляє діями всієї системи

Сирена
Видає потужний звуковий сигнал при незаконному проникненні в житло

Синтезатор голосу
Синтезує голосове повідомлення про проникнення в будинок

Телефонний інформатор
Робить зовнішній телефонний дзвінок для повідомлення служби безпеки (наприклад, поліції) про проникнення в будинок


На цьому рівні деталізації система розбивається на окремі підсистеми. Кожна підсистема, у свою чергу, може бути представлена як декомпозиція своїх функціональних компонентів. Це такі компоненти підсистеми, які, виходячи із призначення підсистеми, виконують яку-небудь одну функцію. На противагу цьому підсистема звичайно виконує кілька функцій. Звичайно, декомпозицію підсистем (і самої системи) можна проводити по інших ознаках, наприклад конструктивним або технологічним.
Історично зложилося так, що модель системної архітектури використається для вичленовування апаратних і програмних компонентів системи, які звичайно розробляються паралельно. Разом з тим протиставлення "апаратні засоби — програмне забезпечення" у сучасних системах найчастіше недоречно й несуттєво, оскільки практично всі системні компоненти мають певні обчислювальні можливості. Наприклад, машини, що зв'язують безліч комп'ютерів у єдину мережу, складаються з репитеров , мережних шлюзів і сполучних кабелів. Репитеры й шлюзи мають процесори й програми, що управляють цими пристроями, і, звичайно ж, інші електронні компоненти.
На рівні системної архітектури більш раціонально класифікувати підсистеми відповідно до виконуваними їх функціями, не акцентуючи спеціально увагу на тім, чи є вони апаратними або програмними компонентами. Питання про те, чи буде дана функція реалізована апаратно або програмно, часто зважується на основі нетехнічних факторів, таких як час, необхідне для створення компонента, або виходячи з наявності на ринку промислових виробів підходящих готових пристроїв.
Блок-схеми можна використати для подання систем будь-якого розміру. На мал. 2.3 показана архітектура значно більше складної системи керування польотами. Ця система містить кілька основних підсистем, які самі є системами великого розміру. Напрямок інформаційних потоків між підсистемами показано з'єднуючими їхніми лініями зі стрілками.

Рис. 2.3. Архітектура системи керування польотами
2.3.1. Функціональні компоненти систем
Як відзначалося в попередньому розділі, системна архітектура описується в термінах функціональних підсистем, незалежно від того, чи є ці підсистеми апаратними або програмними. Разом з тим функціональні компоненти в системі можна класифікувати по цілому ряді категорій, деякі з них наведені нижче.
Сенсорні компоненти збирають інформацію про системне оточення. Прикладами можуть служити радіолокатори в системі керування польотами, датчик положення паперу в лазерному принтері або термопара в топковій камері казана.
Виконавчі компоненти роблять деякі дії в оточенні системи. Прикладами можуть служити регулювальний клапан, що закриває або відриває заслінку в трубопроводі для зменшення або збільшення швидкості потоку рідини в ньому, закрилки крил літака, які управляють кутом нахилу літака, механізм подачі паперу в лазерному принтері.
Обчислювальні компоненти — на їхній вхід надходять певні дані, відповідно до яких вони виконують обчислення, потім на виході одержують нові дані. Прикладом обчислювального компонента є математичний співпроцесор, що виконує обчислення із числами в експонентному форматі,
Комунікаційні компоненти надають можливість іншим системним компонентам обмінюватися інформацією. Як приклад назвемо мережні интерфейсные плати комп'ютерів, об'єднаних у локальну мережу.
Координуючі компоненти погодять роботу інших компонентів. Прикладом є планувальник завдань у системах реального часу. Планувальник визначає, який процес у цей момент часу може оброблятися процесором.
Інтерфейсні компоненти перетворять систему подань, якими оперує один системний компонент, у систему подань, застосовуваних іншим компонентом. Прикладом "людського" інтерфейсні компоненти може служити модель якої-небудь системи й подання її у вигляді, назадньому іншій людині. Іншим прикладом є аналогово-цифровий перетворювач, що перетворить аналоговий сигнал у послідовність чисел.
У табл. 2.2 описаний тип функціональних компонентів архітектури системи сигналізації, представленої на мал. 2.2.
Таблиця 2-2- Типи компонентів системи сигналізації
Тип компонента
Компонент
Функції компонента

Сенсорний
Датчик руху, дверний датчик
Реєструє рух у захищеному приміщенні, визначає, чи відкрита зовнішні двері

Виконавчий
Сирена
Видає звуковий сигнал при незаконному проникненні в житло

Комунікаційний
Телефонний інформатор
Робить телефонний дзвінок у центр управління при проникненні в будинок. Одержує відповідну команду із центра керування

Координуючий
Контролер
Координує всі системні компоненти. Діє по командах панелі керування й центра керування

Интерфейсный
Синтезатор голосу
Синтезує повідомлення про проникнення в будинок


Звичайно, нескладно віднести системні компоненти до одному з перерахованих типів. Разом з тим, якщо в системі використається програмне забезпечення, те, як правило, програмні елементи вбудовуються в більшість системних компонентів. Програмне забезпечення звичайно використається для керування всією системою.
Наведена класифікація компонентів допомагає при проектуванні систем. Більшість систем містять компоненти всіх типів, і завдання розроблювача полягає в точному визначенні типу компонента виходячи зі специфікації системи. Якщо кілька компонентів містять ознаки різних типів, це може привести до того, що при проектуванні системи можуть виникнути певні проблеми.
2.4. Процес створення систем
Етапи процесу створення системи показані на мал. 2.4. Ці етапи дуже впливають на процес розробки програмного забезпечення відповідно до каскадної моделі, що описується в главі 3.

Рис. 2.4. Процес створення системи
Опишемо основні відмінності між процесом створення систем і процесом розробки програмного забезпечення.
Залучення в процес розробки систем різноманітних інженерних дисциплін. Процес створення систем звичайно вимагає залучення різноманітних інженерних дисциплін. Це може привести до значних утруднень у розробці систем, оскільки кожна дисципліна використає свою термінологію.
Невеликий масштаб повторних робіт при розробці систем. Після прийняття рішень у процесі розробки систем (наприклад, про установку певних типів радіолокаторів у системі керування польотами) внесення змін у систему може виявитися досить дорогим. Перепроектування системи часто просто неможливо. Це одна із причин широкого використання ПО при створенні найрізноманітніших систем - програмні компоненти роблять системи більше гнучкими й дозволяють внести зміни в розроблювальну систему у відповідь на нові вимоги, пропоновані до неї.
У команду розроблювачів систем неминуче включаються фахівці різних профілів. Команда розроблювачів повинна мати широке коло знань, щоб всебічно розглянути всі системні можливості при прийнятті яких-небудь рішень. Розглянемо систему керування польотом (СУП), у якій використається радіолокаційна або яка-небудь інша сенсорна система для визначення місцезнаходження літаків (див. мал. 2.3). На мал. 2.5 схематично показані ті інженерні дисципліни, якими повинні володіти члени команди розроблювачів системи.

Рис. 2.5. Інженерні дисципліни, що утягуються в процес системотехніки
Для багатьох систем існує практично нескінченна кількість способів декомпозиції (розбивки) системи на підсистеми. При цьому фахівці різних профілів можуть пропонувати різні варіанти структурної моделі системи, які будуть містити різні функціональні компоненти. Тим самим можливий найширший діапазон альтернативних моделей. Вибір певної моделі не обов'язково ґрунтується тільки на технічних аргументах. Нехай, наприклад, однієї з альтернатив у розробці СУП є установка нової радіолокаційної системи замість модернізації існуючої. Якщо в команду розроблювачів входять будівельники, то вони можуть наполягти саме на цьому варіанті створення СУП, тому що він забезпечить роботою і їх, і будівельні підрозділи, які вони представляють. При цьому для обґрунтування потрібного варіанта можуть, звичайно, залучатися й технічні аргументи.
Оскільки ПО за своєю природою є гнучким і порівняно набудовува_ легко, часте рішення багатьох несподіване виниклих проблем перекладається на плечі фахівців із програмного забезпечення. Нехай, наприклад, при створенні СУП невдало обраний місце розташування однієї радарної установки - на екрані локатора іноді відбувається роздвоєння зображень. Для видалення цього ефекту необхідно пересунути радарну установку, що практично не здійсненно. Рішенням цієї проблеми може бути створення спеціального ПО, що допоможе видалити роздвоєння зображень. Але в цьому випадку може знадобитися могутніша обчислювальна техніка, чим та, котра споконвічно запланована, і це, у свою чергу, також може стати певною проблемою.
Перед фахівцями із програмного забезпечення часто ставляться завдання, які необхідно вирішувати без збільшення вартості апаратних засобів. Тому багато хто так звані програмні помилки не є наслідком яких-небудь "уроджених" рис або властивостей ПО. Вони можуть бути результатом спроби модернізувати програмне забезпечення відповідно до змін вимог, пропонованих до створюваної системи. Гарним прикладом такої помилки може служити збій у системі керування багажем в аеропорті Денвера [329].
2.4.1. Визначення системних вимог
На етапі визначення системних вимог формуються й формалізуються вимоги до системи, розглянутої як єдине ціле. Як і при аналізі вимог до програмного забезпечення, тут також необхідні консультації із замовниками системи і її кінцевих користувачів. На етапі визначення вимог звичайно формуються вимоги трьох типів.
Загальні функціональні вимоги. Основні функції, виконувані системою, визначаються на самому вищому (абстрактному) рівні подання системи. Деталізація функціональних вимог відбувається вже на рівні підсистем. Наприклад, при розробці СУП обов'язково буде передбачена вимога мати базу даних польотів, зроблених у контрольованому системою повітряному просторі. Однак структура цієї бази даних не буде визначена доти, поки не будуть відпрацьовані вимоги до інших підсистем.
Системні властивості. Це ті інтегровані властивості системи, які обговорювалися вище. Вони можуть включати такі властивості, як продуктивність, безвідмовність, захищеність і т.п. Ці нефункціональні властивості впливають на всі вимоги, обумовлені для підсистем.
Властивості, які повинні отсутствовать у системи. Часом набагато важливіше вказати, що система не повинна робити, чим те, що вона повинна виконувати. Наприклад, у СУП необхідно зажадати, щоб система не надавала операторам занадто багато інформації, тільки саму необхідну, не відволікаюча їхня увага.
Важливою частиною етапу визначення вимог є опис безлічі цілей, до виконання яких повинна прагнути система. Вони не обов'язково повинні бути виражені в термінах функціональних властивостей системи, але повинні показати, як вона буде поводитися у своєму оточенні.
Щоб проілюструвати опис безлічі цілей, розглянемо об'єднану систему протипожежної безпеки й захисту від несанкціонованого вторгнення, призначену для установки в офісному будинку. Мети, які ґрунтуються на функціональних можливостях системи, можна сформулювати в такий спосіб.
Система повинна забезпечити попередження про загоряння, що виникли усередині або поблизу будинку, і несанкціонованому проникненні в цей будинок.
Ця мета точно описує призначення системи, що повинна попереджати про якісь небажані події. Таке формулювання підходить для системи безпеки, що вже існують і яка повинна бути замінена. На противагу цьому можна сформулювати більше "широку" мету.
Система повинна гарантувати отсупигтвие серйозних порушень у нормальному функціонуванні й експлуатації будинку внаслідок загорянь і нeзаконных вторгнень.
Перше формулювання мети обмежує можливості проектування системи. Відповідно до неї від несанкціонованих проникнень можна застосувати складні захисні засоби навіть без внутрішньої системи сигналізації, а дли захисту від вогню можна використати автоматичну систему пожежогасіння з разбрызгивателями води. Але такі засоби можуть вивести з ладу електричну систему й заподіяти серйозні незручності працюючої в будинку.
Подчас основні труднощі у визначенні системних вимог полягають у тому, що система будується для того, щоб допомогти в рішенні "злісної" проблеми (wicked problem) [294]. "Злісна" проблема - це проблема такої великої складності й имеющая стільки взаємозалежних вхідних впливів, що її неможливо точно описати. Щира природа такої проблеми може виявитися тільки в процесі її рішення. Як екстремальний приклад "злісної" проблеми можна привести завдання пророкування землетрусів. У цей час не існує точних способів пророкування ні епіцентру землетрусу, ні його часу, ні сили, ні впливу на навколишнє середовище. Тому неможливо заздалегідь повністю спланувати всі дії на випадок великого землетрусу - це можна зробити тільки тоді, коли воно відбудеться.
2.4.2. Проектування систем
Проектування системи (мал. 2.6) полягає у визначенні системних компонентів на основі функціональних вимог до системи. Процес проектування складається з декількох етапів.

Рис. 2.6. Етапи проектування системи
Розбивка вимог на групи. Вимоги аналізуються й розбиваються на окремі групи. Звичайна безліч вимог можна розбити на групи багатьма способами, на цьому етапі зберігаються всі "життєздатні" розбивки.
Визначення підсистем. Визначаються підсистеми, які індивідуально або спільно реалізують системні вимоги. Група вимог звичайно проектується на кілька підсистем, тому можна об'єднати кілька вимог в одне. Разом з тим на визначення систем впливають не тільки системні вимоги, але й організаційні або виробничі фактори.
Розподіл вимог по підсистемах. У принципі ця операція повинна бути виконана на попередньому етапі визначення підсистем. Але на практиці не завжди можна чітко погодити розбивку вимог і визначення підсистем. Або, наприклад, обмежений асортименти підсистем, що здобуваються в зовнішніх постачальників (див. розділ 2.4.3), може привести до перегляду вимог до системи.
Спеціфуванння функціональних характеристик підсистем Визначаються функціональні характеристики кожної підсистеми. Якщо підсистема є програмної, цей етап буде частиною етапу створення специфікації для даної підсистеми. На цьому етапі також формалізуються взаємини між підсистемами.
Визначення інтерфейсів підсистем. Для кожної підсистеми визначається свій інтерфейс. Тільки після цього можливо почати розробку самих підсистем.
На мал. 2.6 лінії, що з'єднують етапи, мають стрілки на обох кінцях. Це означає наявність зворотного зв'язка між етапами й можливість вертатися до попереднього етапу в процесі проектування системи. Дуже часто доводиться вертатися до попереднього етапу для рішення виниклих на даному етапі проблем.
Для більшості систем можна розробити кілька проектів. Це припускає широкий діапазон можливих рішень, що складаються з різних комбінацій апаратних і програмних компонентів і людського фактора. Для подальшої розробки вибирається рішення, найбільш повне задовольняючим системним вимогам. Разом з тим на вибір проекту часто впливають організаційні й політичні фактори. Наприклад, якщо система розробляється за замовленням уряду, звичайно вибираються національні постачальники комплектуючих, навіть якщо по певних параметрах вони (комплектуючі) уступають закордонним; це, природно, впливає на вибір проекту системи.
Розробка підсистем
На цьому етапі реалізуються тс підсистеми, які були визначені на етапі проектування системи. Для окремих підсистем етап розробки може зажадати включення різних процесів системотехніки. Так, якщо підсистема є програмною системою, етап розробки буде включати процеси формалізації вимог, проектування, створення й т.д.
Іноді розробка всіх підсистем починається "з нуля". Але частіше буває так, що деякі підсистеми можна придбати на ринку промислових виробів і потім інтегрувати в створювану систему. Звичайно буває дешевше купити готовий виріб, чим розробляти власну підсистему. На цьому етапі може виникнути необхідність повернутися до етапу проектування для того, щоб на рівні вимог "підігнати" куплений виріб до системи. Цей виріб може не задовольняти всім вимогам, пропонованим до компонента, що воно заміщає, але якщо асортименти комерційних продуктів досить широкий, витрати на повторне проектування невеликі.
Всі підсистеми, як правило, розробляються паралельно. Якщо виникають внутрішні проблеми, що переривають процес розробки підсистем, може знадобитися модифікація всієї системи. Коли система в значній мірі складається з апаратних компонентів, проведення модифікації системи після початку виробництва її компонентів може виявитися досить витратним. Доводиться знаходити якесь "обхідне" рішення для виходу з подібних ситуацій. Часто таким рішенням є включення в систему програмних компонентів, оскільки вони досить гнучкі й порівняно легко піддаються модифікаціям. У свою чергу, це веде до зміни вимог, пропонованих до програмного забезпечення, і, як підкреслювалося в главі 1, до змін у проекті ПО.
Зборка системи
Зборка являє собою інтеграцію незалежно розроблених підсистем у єдину закінчену систему. У процесі зборки може використатися метод "великого вибуху", коли всі підсистеми інтегруються одночасно. Але по технічних і організаційних причинах набагато переважніше послідовна зборка, коли окремі підсистеми інтегруються в систему по черзі, одна заіншої.
Процес послідовної зборки вважається більше підходящим для системної інтеграції по двох причинах.
1. Звичайно неможливо скласти такий графік робіт, при якому у всіх підсистем етап розробки закінчується одночасно.
2. Послідовна зборка зменшує кількість помилок, пов'язаних з неправильною інтеграцією системи. Якщо одночасно інтегрується кілька підсистем, то причиною виявленої в процесі тестування помилки може бути кожна з них. Якщо інтегрується одна підсистема у вже працюючу систему, то причиною виявленої помилки, найімовірніше, буде остання інтегрована підсистема або знову встановлені зв'язки між нею й існуючими підсистемами.
Помилки й дефекти окремих підсистем і системи в цілому часто проявляються саме на етапі зборки. Це може викликати полеміку й конфлікти між розроблювачами різних підсистем через того, чию підсистему визнати "винної" у цьому. Саме неприємне в даній ситуації те, що на рішення виниклих проблем може знадобитися кілька тижнів, а те й місяців роботи.
2.4.5. Інсталяція системи
При інсталяції система "поринає" у те оточення, у якому вона повинна працювати. У процесі інсталяції складних систем можуть виявитися різні проблеми, на рішення яких часом іде кілька місяців, а те й років. Серед них можуть бути проблеми, описані нижче.
Оточення, у якому інсталюється ристема, не збігається з тим, для якого вона спроектована. Це загальна проблема, що часто виникає при інсталяції ПО. Наприклад, програмна система може використати функції, які надає тільки певна версія операційної системи. Однак версія, що визначає поточне оточення инсталлируемой програмної системи, може не мати ці функції. У цьому випадку після інсталяції система може не працювати зовсім або деякі її функції виявляться не реалізованими.
Потенційні користувачі можуть ставитися вороже до впровадження цієї системи у своїй організації. Це може зменшити відповідальність і кількість робіт, необхідних для впровадження системи в даній організації. Люди можуть усвідомлено відмовлятися від співробітництва з фахівцями, які інсталюють систему. Наприклад, вони можуть відмовлятися від навчання роботі із цією системою або не надавати інформацію, необхідну для інсталяції системи.
Нова система може співіснувати зі старої доти, поки в організації, де вона інсталюється, не переконаються, що нова система працює так, як потрібно. Це може привести до певних проблем при інсталяції системи, особливо якщо нова й стара системи не є повністю незалежними, а мають деякі загальні компоненти. Трапляються ситуації, коли нову систему взагалі неможливо впровадити без деінсталяції старої системи. При цьому випробування нової системи можна провести тільки тоді, коли стара система не функціонує.
При інсталяції можливі також чисто фізичні проблеми. Можуть виникнути складності при припасуванні системи до того будинку, де вона інсталюється. Цей будинок може не мати достатньої кількості приміщень із каналами для мережних кабелів, можуть знадобитися додаткові повітряні кондиціонери илн інші вбудовуються в здаиие прилади й т.п. А якщо це пам'ятник історії, охоронюваний законом, то при інсталяції системи зміни в будинку взагалі неможливі.
Уведення системи в експлуатацію
Після того як система інстальована, її необхідно ввести в експлуатацію. Це має на увазі проведення навчання системних операторів і зміна їх звичайного робочого процесу для того, щоб більш ефективно використати нову систему. На цьому етапі можуть виникнути непередбачені проблеми, якщо системна специфікація містить помилки або недогляди. Поки система функціонує у відповідності зі специфікацією, ці дефекти можуть не виявитися, і тому розроблювачі можуть не передбачити відповідних режимів експлуатації системи.
Наприклад, проблемою, що може виявитися тільки після уведення системи в експлуатацію, є сумісність нової й існуючої систем. Це може бути чисто фізична проблема сумісності. Можливі проблеми при передачі даних від однієї системи до іншої. Більше "хитрою" проблемою може стати розходження інтерфейсів різних систем. Тоді уведення в експлуатацію поспівай системи може привести до зростання помилок системних операторів внаслідок неправильного використання интерфейсных команд нової системи.
Еволюція систем
Більші й складні системи мають дуже тривалий строк життя. Протягом свого життя вони вдосконалюються шляхом виправлення помилок у вихідних системних вимогах, а також для обліку нових вимог, пропонованих до них. Обчислювальні компоненти систем заміняються новими, більше продуктивними компонентами. Організації, що експлуатують систему, можуть бути реорганізовані й, отже, використати систему іншим способом, чим передбачалося спочатку. Може змінитися зовнішнє оточення системи, що також вимагає внесення в неї змін.
Необхідність еволюції систем, як і програмного забезпечення (ця тема обговорюється в частині VII), викликана рядом причин.
Передбачувані зміни в технічній і діловій областях, отримані па основі ретельного аналізу перспектив розвитку цих областей. Тут необхідно враховувати думку широкого кола фахівців, перш ніж приймати які- або рішення.
Оскільки системи ніколи не є повністю не залежними друг від друга, зміни в одній підсистемі обов'язково вплинуть на продуктивність або поводження інших підсистем. Отже, при внесенні змін в одну підсистему необхідні зміни практично у всіх підсистемах.
Причини, що приводять до прийняття певних рішень на первісному етапі проектування вихідної системи, рідко протоколюються або взагалі фіксуються. Це може викликати перегляд деяких рішень, прийнятих на первісному етапі проектування, а отже, зміни в самій системі.
По мерс збільшення "віку" системи її структура внаслідок зроблених раніше змін порушується, що, у свою чергу, приводить до зростання витрат на її модифікацію.
Внаслідок всі зростаючої залежності нашого суспільства від систем найрізноманітніших типів значно більше зусиль додається для вдосконалювання існуючих систем, чим для розробки нових. Такі раніше створені системи, які необхідно зберегти (шляхом їхньої модернізації), іноді називають нааи'дуемыми систтлми (1е£а5в 5в51ст5). Ці системи обговорюються в главі 26.
2.4.8. Вивід систем з експлуатації
Вивід з експлуатації означає добування системи з її оточення після закінчення терміну служби. Часто це не припускає яких-небудь складностей. Але деякі системи можуть містити матеріали, потенційно небезпечні для навколишнього середовища. Системотехніки повинні передбачити процедуру виводу такої системи з експлуатації ще на етапі її проектування. Наприклад, використовувані в системі токсичні хімічні сполуки повинні бути укладені в герметичні контейнери, кожний з яких можна видалити із системи як єдиний елемент для наступної утилізації.
При деінсталяції програмного забезпечення звичайно не виникає фізичних проблем. Разом з тим деякі програмні компоненти можуть бути інкорпорованими в системи, необхідні для деінсталяції ПО; наприклад, якщо ПО використалося для моніторингу стану інших системних компонентів.
Після виводу системи з експлуатації деякі її компоненти можуть використатися в інших системах. Якщо дані з деинсталлируемой системи повинні повернутися в організацію, для цього можуть бути застосовані які-небудь інші системи. Ці дані часто мають значну вартість. Тема повторного використання даних розглядається в главі 28.
2.5. Придбання систем
Замовниками складних обчислювальних систем звичайно є великі організації, наприклад військове відомство, уряд або аварійні служби. Такі системи можна купити як єдине ціле, можна купити окремі частини, які потім інтегруються в створювану систему, можна спроектувати систему й розробити по окремому замовленню "з нуля". Для більших систем процес вибору одного із цих варіантів може розтягтися на кілька місяців або навіть років. Процес придбання системи - це визначення найбільш оптимального для організації шляху її придбання й вибір найкращого постачальника системи.
Процес придбання системи повністю підкоряється процесу системотехніки. До початку самого процесу придбання необхідно розробити системну специфікацію й архітектуру системи, що обумовлено двома основними причинами.
Для покупки або висновку контракту на розробку й побудову системи необхідна повністю закінчена системна специфікація.
Практично завжди дешевше купити систему, чим розробити її (як окремий проект). Архітектура системи необхідна для того, щоб визначити, які її підсистеми можна купити, а які необхідно розробляти.
Більші складні системи звичайно складаються із придбаних компонентів і компонентів, спеціально створених для даної системи. Це одна з передумов, що вимагає включення програмних компонентів до складу систем- програмне забезпечення повинне "склеїти" у єдине ціле (причому ефективно працююче) окремі існуючі апаратні компоненти. У необхідності розробки програмного "клею" криється причина того, що економія від застосування придбаних компонентів не така більша, як очікується. Докладно тема придбаних систем обговорюється в главі 14.
На мал. 2.7 показані етапи процесу придбання як готових систем, гак і розроблювальних за замовленням. Перелічимо деякі важливі моменти процесу придбання.
Компоненти, що здобуваються, як правило, не задовольняють у точності всім системним вимогам, внаслідок чого необхідне припасування вимог відповідно до цих компонентів. Більше того, звичайно коштує нелегка дилема вибору між системними вимогами й властивостями придбаної системи. Найчастіше "у жертву" приносяться системні вимоги. Це, у свою чергу, впливає па інші підсистеми.
Якщо система розробляється за замовленням, специфікація вимог є основою контракту на здобувається систему, що. Таким чином, специфікація має таку ж правову силу, як і інша технічна документація.
Після вибору розроблювача системи в контракті з ним необхідно обмовити можливості внесення змін у вимоги, хоча це може привести до зміни вартості системи.

Рис. 2.7. Процес придбання системи
Більшість апаратних підсистем і багато програмних підсистем (такі, як системи керування базами даних) не розробляються спеціально для включення до складу більших систем. Часто в них вбудовуються вже готові системи.
Далеко не всі організації мають можливості для проектування, виробництва й тестування всіх компонентів складних більших систем. Організація - розроблювач системи, що звичайно називають провідним або генеральним підрядником, може містити контракти на розробку окремих підсистем з іншими субпідрядниками (мал. 2.8). Для створення більших систем, таких як системи керування польотами, група організацій-розроблювачів може створити консорціум для виконання контракту. У консорціум повинні входити розроблювачі й постачальники всіх компонентів системи, наприклад розроблювачі обчислювальних пристроїв і програмного забезпечення, постачальники периферійного встаткування й спеціального устаткування (скажемо, радарів).
Модель "підрядчик-субпідрядник" мінімізує кількість організацій, що беруть участь у реалізації контракту. Субпідрядники розробляють і роблять частини системи у відповідності зі специфікацією, надаваної провідним підрядником. Після завершення робіт субпідрядниками система збирається з окремих частин провідним підрядником. Готова система поставляється замовникові (покупцеві). Залежно від умов контракту, замовник може надати провідному підрядникові вільний вибір субпідрядників або зажадати, щоб субпідрядники вибиралися із заздалегідь застереженого списку.

Рис. 2.8. Модель иподрядчик-субподрядчик'
ПОНЯТТЯ* " - -
: Сйстемотёхйика ~ 'це комплексна технологія створення ^систем, котор^ дребуёт залучення
|^Щ Иктефирова1нные властивості система^-це властивості, які властиві системі як єдиному ціле- Щ^му. а не її отдельнымкомпонентам.До інтегрованим системних свойствамотносятся безог- :^^^^шно(^; производительж)сть; удоб<лш експлуатації, безпека й захищеність системи. ¦¦^^'А^^пектура представляється звичайно у веде блок-схеми. поки^ывает основні подсис-
;; Фуни^ональйые хомпоненты систем діляться на наступні типи: сенсорні, виконавчі, § : ^ вычислительны?, що координують, комунікаційні й интерфейсные.. ^|Ш;Процесссо;даия систем включає наступні этагш:сШавление специфікації, проешрова- ^Жние, розробку, інтеграцію (зборку) і тестування. Найбільш відповідальним етапом є рЩсборка-системы, коли різні подристемы, часом від різних виробників, інтегруються ' вДОНуЮ систему. .. . '. -
ф Процес придбання системи включає етапи специфищфования систшы. формування заявки на щЩ".-'приобр^Н^|в^Р постачальника й потім висновок контракту на покупку або розробку системи. ' Часто жштррыё^ систем прио^е^т;^ у сторонніх пррювсд^лий. V ... . !
Вправи
Поясните, чому системне оточення може зробити непередбачений вплив на функціонування системи.
Зміните схему на мал. 2.6 таким чином, щоб включити в неї етап придбання підсистем після етапу їхньої ідентифікації. Покажіть на новій схемі зворотний зв'язок від включеного етапу придбання до інших етапів процесу проектування системи.
Поясните, чому процес специфицирования систем, використовуваних аварійними службами для керування в надзвичайних ситуаціях, є "злісною" проблемою.
Поясните важливість одержання повного опису системної архітектури на самій ранній стадії процесу розробки системної специфікації.
На мал. 2.1 показана ієрархія систем окремого будинку. Система безпеки, що включає систему захисту від несанкціонованого проникнення в будинок і протипожежну систему, є розширенням системи, представленої на мал. 2.2. Вона містить датчики диму, датчики руху й дверні датчики, відеокамери, керовані комп'ютером, розташовані в різних місцях будови, пульт керування, де збирається вся інформація від системи безпеки, засобу зовнішніх комунікацій для зв'язку з відповідними службами, такими як поліція й пожежна охорона. Намалюйте блок-схему архітектури такої системи.
Розробляється система попередження повеней для міста, якому загрожують часті повені. Система включає безліч датчиків рівня води в ріці, зв'язок з метеослужбою, що надає прогноз погоди, зв'язок зі службами безпеки (поліцією, береговою охороною й т.д.), відеомонітори, установлені в різних місцях, і кімнату керування, обладнану пультом керування й моніторами.
Чергові оператори мають доступ до бази даних і можуть перемикати відеомонітори. База даних містить інформацію з датчиків, розташованих в інших містах, також підданих ризику повені, про ситуацію в цих містах (рівень води, сила й напрямок вітру й т.п.), таблицю висот прибережних міст, місце розташування встаткування, що контролює рівень води, контактні телефони служб безпеки, частоти місцевих радіостанцій і т.д.
Намалюйте блок-схему можливої архітектури такої системи. Також визначите основні підсистеми й взаємозв'язки між ними.
Назвіть три проблеми, які можуть виникнути при інсталяції системи в сторонній організації.
Розглянете системотехнікові як професію й зрівняєте її із професією инженера-электронщика й фахівця із програмного забезпечення.
Допустимо, ви інженер, включений у фуппу розроблювачів фінансової системи. У процесі інсталяції системи ви виявляєте, що її впровадження в організації може привести до звільнення великої кількості людей. Персонал організації не надає вам інформацію, необхідну для завершення інсталяції системи. Що ви будете робити в цій ситуації як інженер- системотехнік? Чи будете ви з почуттям професійної відповідальності прагнути до завершення її впровадження системи, що потрібно від вас контрактом? Або ж просто припините роботу доти, поки організація не розбереться зі своїми проблемами?
Сучасний мир усе більше залежить від систем, побудованих на основі обчислювальної техніки. Усе більше технічних пристроїв містять у собі елементи обчислювальної техніки й відповідного керуючого програмного забезпечення (ПО) у тій або іншій формі. У таких системах вартість ПО часом становить більшу частину загальної вартості. Більше того, вартісні показники галузей, що займаються виробництвом ПО, стають визначальними для економіки - як національної, так і міжнародної.
Целыо інженерії програмного забезпечення є ефективне створення програмних систем. Програмне забезпечення абстрактно й нематеріально. Воно не має фізичної природи, відкидає фізичні закони й не піддається обробці виробничими процесами. Такий спрощений погляд на ПО показує, що не існує фізичних обмежень на потенційні можливості програмних систем. З іншого боку, відсутність матеріального наповнення часом робить ПО надзвичайно складним і, отже, важким для розумінні "об'єктом".
Інженерія програмного забезпечення — порівняно молода наукова дисципліна. Термін software engineering був уперше запропонований в 1968 році на конференції, присвяченої так званій кризі програмного забезпечення. Ця криза була викликана появою потужної (але міркам того часу) обчислювальної техніки третього покоління. Нова техніка дозволяла втілити в життя не реалізовані раніше програмні додатки. У результаті програмне забезпечення досягло розмірів і рівня складності, що набагато перевищує аналогічні показники в програмних систем, реалізованих на обчислювальній техніці попередніх поколінь.
Виявилося, що неформальний підхід, що застосовувався раніше до побудови програмних систем, недостатній для розробки більших систем. На реалізацію великих програмних проектів іноді йшли багато років. Вартість таких проектів багаторазово зростала в порівнянні з первісними розрахунками, самі програмні системи виходили ненадійними, складним^ в експлуатації й супроводі. Розробка програмного забезпечення виявилася в кризі. Вартість апаратних засобів поступово знижувалася, тоді як вартість ПО стрімко зростала. Виникла необхідність у нових технологіях і методах керування комплексними складними проектами розробки більших програмних систем.
Такі методи склали частину інженерії програмного забезпечення й у цей час широке використаються, хоча, звичайно ж, не є універсальними. Зберігається багато проблем у процесі розробки складних програмних систем, на рішення яких затрачається багато часу й засобів. Реалізація багатьох програмних проектів зіштовхується з подібними проблемами, це надає право деяким фахівцям затверджувати, що сучасна технологія створення програмного забезпечення перебуває в стані хронічної недуги [287].
З іншого боку, зростає як обсяг виробництва програмного забезпечення, так і його складність. Крім того, зближення обчислювальної й комунікаційної техніки ставить нові вимоги перед фахівцями із програмного забезпечення. Це також є однією із причин виникнення проблем при розробці програмних систем, як і те, що багато компаній, що займаються виробництвом ПО, не приділяють належну увагу ефективному застосуванню сучасних методів, розроблених у рамках інженерії програмного забезпечення. Справа не так погано, як затверджують скептики, завдяки критиці яких высвечиваются болючі крапки, здатні стати крапками росту інженерії програмного забезпечення.
1 Саме цей термін у даній книзі ми переводимо як інженерія програмного забезпечення. Інші існуючі переклади (наприклад, программотехника або програмна інженерія) нам здаються не зовсім що точно відображають сутність цього поняття. - Прим. ред.
Я думаю, у порівнянні з 1968 роком зроблені величезний стрибок і розвиток інженерії програмного забезпечення значно поліпшило сучасне ПО. Тепер ми краще розуміємо ті процеси, які визначають розвиток програмних систем. Розроблено ефективні методи специфікації ПО, його розробки й впровадження. Нові засоби й технології дозволяють значно зменшити зусилля й витрати на створення більших і складних програмних систем.
Фахівці із програмного забезпечення можуть пишатися такими досягненнями. Без сучасного складного ПО було б неможливо освоєння космічного простору, не існувало б Internet і сучасних телекомунікацій, а всі транспортні засоби й види транспортування були б більше небезпечними й дорогими. Інженерія програмного забезпечення досягла багато чого за свою поки ще коротке життя, і я впевнений, що її значення як зрілої наукової дисципліни ще більше зросте в XXI сторіччі.
1.1. Питання й відповіді про інженерію програмного забезпечення
Цей розділ побудований у вигляді відповідей на деякі основні питання, що стосуються інженерії програмного забезпечення й отображающие мій власний погляд на цю дисципліну. Я використав формат "списку FAQ" (Frequently Asked Questions - питання, що задаються часто). Такий формат звичайно застосовується в групах новин Internet, пропонуючи новачкам відповіді на питання, що задаються часто. Сподіваюся, що подібний підхід буде ефективне як коротке введення в предмет інженерії програмного забезпечення.
Питання й відповіді, докладно розглянуті в цьому розділі, компактно представлені в табл. I.I.
Таблиця 1.1. питання, що задаються Часто, про інженерію програмного забезпечення
Питання
Відповідь

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

Що таке інженерія програмного забезпечення?
Це інженерна дисципліна, що охоплює всі аспекти розробки програмного забезпечення

У чому розходження між інженерією програмного забезпечення й комп'ютерною наукою?
Комп'ютерна наука — це теоретична дисципліна, що охоплює всі сторони обчислювальних систем, включаючи апаратні засоби й програмне забезпечення; інженерія програмного забезпечення — практична дисципліна створення й супроводи програмних систем

У чому розходження між інженерією програмного забезпечення й системотехнікою?
Системотехніка охоплює всі аспекти розробки ви числівників систем (включаючи створення апаратних засобів і ПО) і відповідні технологічні процеси. Технології інженерії програмного забезпечення є частиною цих процесів

Що таке технологічний процес створення ПО?
Це сукупність процесів, що ведуть до створення або розвитку програмного забезпечення


Закінчення табл. 1.1
Питання
Відповідь

Що таке модель технологічного процесу створення ПО?
Формалізоване спрощене подання технологічного процесу створення ПО

Яка структура витрат на створення ПО?
Приблизно 60% від загальних витрат на створення ПО займають витрати безпосередньо на розробку ПО й 40% — на його тестування й налагодження. Для програмних продуктів, розроблювальних за замовленням, вартість тестування й налагодження часто перевищує вартість розробки продукту

Що таке методи інженерії програмного забезпечення?
Це структурні рішення, призначені для розробки ПО й системні моделі, що включають, формалізовану нотацію й правила проектування, а також способи керування процесом створення ПО

Що таке CASE (Computer- Aided Software Engineering — автоматизоване проектування й створення ПО)?
Це програмні системи, призначені для автоматизації процесу створення ПО. СА5Е-средства часто використаються як основу методів інженерії програмного забезпечення

Які ознаки якостей венного ПО?
Програмні продукти повинні задовольняти вимогам функціональності й ефективності (з погляду користувача), а також бути надійними, зручними в експлуатації й мати можливості для модернізації

Які основні проблеми коштують перед фахівцями із програмного забезпечення?
Проблема спадкування раніше створеного ПО, проблема всі зростаючої різнорідності програмних систем і проблема, породжена вимогою зменшення часу на створення ПО


1.1.1. Що таке програмне забезпечення
Багато хто ототожнюють термін програмне забезпечення з комп'ютерними програмами. Це досить обмежене подання. Програмне забезпечення - це не тільки програми, але й вся супутня документація, а також конфігураційні дані, необхідні для коректної роботи програм. Програмні системи складаються із сукупності програм, файлів конфігурації, необхідних для установки цих програм, і документації, що описує структуру системи, а також містить інструкції для користувачів, що пояснюють роботу із системою, і часто адреса Шеь-узла, де користувач може знайти саму останню інформацію про даний програмний продукт.
Фахівці із програмного забезпечення розробляють програмні продукти, тобто таке ПО, яких можна продати споживачеві. Програмні продукти діляться на два типи.
1. Загальні програмні продукти. Це автономні програмні системи, які створені компанією по виробництву ПО й продаються на відкритому ринку програмних продуктів будь-якому споживачеві, здатному їх купити. Іноді їх називають "коробковим ПО". Прикладами цього типу програмних продуктів можуть служити системи керування базами даних, текстові процесори, графічні пакети й засоби керування проектами.
2. Програмні продукти, створені на замовлення. Це програмні системи, які створюються за замовленням певного споживача. Таке ПО розробляється спеціально для даного споживача згідно з укладеним контрактом. Програмні продукти цього типу включають системи керування для електронних пристроїв, системи підтримки певних виробничих або бізнесів-процесів, системи керування повітряним транспортом і т.п.
Важлива відмінність між цими типами програмних продуктів полягає в тім, що при створенні загальних програмних продуктів специфікація вимог на них розробляється компанією-виробником. Для замовлених програмних продуктів специфікація звичайно розробляється організацією, що купує даний продукт. Специфікація необхідна розроблювачам ПО для створення будь-якого програмного продукту.
Що таке інженерія програмного забезпечення
Інженерія програмного забезпечення - це інженерна дисципліна, що охоплює всі аспекти створення ПО від початкової стадії розробки системних вимог через створення ПО до його використання. У цьому визначенні присутнє дві ключові фрази.
"Інженерна дисципліна". Інженери - це ті фахівці, які виконують практичну роботу. Вони застосовують теоретичні побудови, методи й засоби там, де це необхідно, але роблять це вибірково й завжди намагаються знайти рішення завдання, навіть якщо не існує підходящої теорії або методів рішення. Фахівці-інженери також завжди розуміють, що вони повинні працювати в організаційних і фінансових рамках укладених контрактів, тобто шукають рішення поставленої перед иими завдання з урахуванням умов контракту.
"Всі аспекти створення програмного забезпечення". Інженерія програмного забезпечення ие розглядає технічні аспекти створення ПО — у її веденні такі питання, як керування проектом створення ПО й розробка засобів, методів і теорій, необхідних для створення програмних систем.
Можна сказати, що фахівці (інженери) по програмному забезпеченню адаптують існуючі методи інженерії ПО до рішення своїх завдань, і найчастіше це виявляється найбільш ефективним способом побудови високоякісних програмних систем. Інженерія програмного забезпечення надає всю необхідну інформацію для вибору найбільш підходящого методу для безлічі практичних завдань. Разом з тим творчий неформальний підхід у певних обставинах також може бути ефективним. Наприклад, при розробці програмних систем електронної комерції в Internet потрібен неформальний підхід у сполученні ПО й графічного ескізного проектування.
Розходження між інженерією програмного забезпечення й комп'ютерною наукою
Істотне розходження полягає в тім, що комп'ютерна наука (computer sciencc) охоплює теорію й методи побудови обчислювальних і програмних систем, тоді як інженерія програмного забезпечення акцентує увагу на практичних проблемах розробки ПО. Знання комп'ютерної науки необхідно фахівцям із програмного забезпечення так само, як знання фізики - инженерам-электронщикам.
В ідеалі вся інженерія програмного забезпечення повинна ґрунтуватися на фундаменті комп'ютерної науки, але насправді це не так. Часто фахівці із програмного забезпечення використають підходи, застосовні для рішення тільки конкретного завдання (без узагальнення на клас подібних завдань). Елегантні методи комп'ютерної науки не завжди можна застосувати до реальних складних завдань, що вимагають програмного рішення.
Розходження між інженерією програмного забезпечення й системотехникои
Системотехніка (system engineering) або, точніше, технологія створення обчислювальних систем охоплює всі аспекти створення й модернізації складних обчислювальних систем, де програмне забезпечення відіграє провідну роль. Сюди можна віднести технологію розробки апаратних засобів, внутрішніх обчислювальних процесів і розгортання всієї системи, а також технологію створення ПО. Інженера-системотехніки на основі специфікації системи (технічних вимог) визначають її архітектуру й потім, зібравши воєдино її окремі частини, створюють закінчену систему. Вони розглядають систему переважно як складений об'єкт із заданими компонентами й приділяють порівняно мало уваги самим системним компонентам (конкретним апаратним засобам, що відповідає програмному забезпеченню й т.д.).
Системотехніка більше стара дисципліна, чим інженерія програмного забезпечення. Людство створює складні індустріальні системи (такі, як залізниці й хімічні заводи) уже більше 100 років. Разом з тим у міру збільшення в системах ролі програмного компонента методи інженерії програмного забезпечення, наприклад автоматизоване моделювання систем, керування розробкою специфікацій і т.п., усе ширше використаються в процесі створення найрізноманітніших систем. Більш докладно питання системотехніки розглядаються в главі 2.
Процес створення програмного забезпечення
Створення ПО - це сукупність процесів, що приводять до створення програмного продукту. Ці процеси ґрунтуються головним чином на технологіях інженерії програмного забезпечення. Існує чотири фундаментальних процеси (більш докладно описаних далі в книзі), які властиві будь-якому проекту створення ПО.
Розробка специфікації вимог на програмне забезпечення. Вимоги визначають функціональні характеристики системи й обов'язкові для виконання.
Створення програмного забезпечення. Розробка й створення ПО згідно специфікації на нього.
Атестація програмного забезпечення. Створене ПО повинне пройти атестацію для підтвердження відповідності вимогам замовника.
Удосконалювання (модернізація) програмного забезпечення. ПО повинне бути таким, щоб його можна було модернізувати відповідно до змінених вимог споживача.
При виконанні різноманітних програмних проектів ці процеси можуть бути організовані різними способами й описані на різних рівнях деталізації. Тривалість реалізації цих процесів також далеко не завжди однакова. І взагалі, різні організації, що займаються виробництвом ПО, найчастіше використають різні процеси для створення програмних продуктів навіть одного типу. З іншого боку, певні процеси більше підходять для створення програмних продуктів одного типу й менш - для іншого типу програмних додатків. Якщо використати невідповідний процес, це може привести до зниження якості й функціональності розроблювального програмного продукту.
Процеси створення ПО докладно описані в главі 3, а вкрай важлива тема вдосконалення технології створення програмних продуктів розглядається в главі 25.
1.1.6. Модель процесу створення ПО
Така модель являє собою спрощений опис процесу створення ПО - послідовність практичних етапів, необхідних для розробки створюваного програмного продукту. Подібні моделі, незважаючи на їхню розмаїтість, служать абстрактним поданням реального процесу створення ПО, Моделі можуть відображати процеси, які є частиною технологічного процесу створення ПО, компоненти програмних продуктів і дії людей, що беруть участь у створенні ПО. Опишемо коротко типи моделей технологічного процесу створення програмного забезпечення.
Модель послідовності робіт. Показує послідовність етапів, виконуваних у процесі створення ПО, включаючи початок і завершення кожного етапу, а також залежність між виконанням етапів. Етапи в цій моделі відповідають певним роботам, виконуваним розроблювачами ПО.
Моделі потоків даних і процесів. У них процес створення ПО представляється у вигляді безлічі активностей (процесів), у ході реалізації яких виконуються перетворення певних даних. Наприклад, на вхід активності (процесу) створення специфікації ПО надходять певні дані, на виході цієї активності одержують дані, які надходять на вхід активності, що відповідає проектуванню ПО, і т.д. Активність у такій моделі часто є процесом більше низького порядку, чим етапи робіт у моделі попереднього типу. Перетворення даних при реалізації активностей можуть виконувати як розроблювачі ПО, так і комп'ютери.
Рольова модель. Модель цього типу представляє ролі людей, включених у процес створення ПО, і дії, виконувані ними в цих ролях.
Існує також велика кількість різноманітних моделей процесу розробки програмного забезпечення (тобто підходів до процесу розробки).
Каскадний підхід. Весь процес створення ПО розбивається на окремі етапи: формування вимог до ПО, проектування й розробка програмного продукту, його тестування й т.д. Перехід до наступного етапу здійснюється тільки після того, як повністю завершуються роботи на попередньому.
Еволюційний підхід. Тут послідовно перемежовуються етапи формування вимог, розробки ПО і його атестації. Первісна програмна система швидко розробляється на основі деяких абстрактних (загальних) вимог. Потім вони уточнюються й деталізуються відповідно до вимог замовника. Далі система допрацьовується й атестується відповідно до нових уточнених вимог. Така послідовність дій може повторитися кілька разів.
Формальні перетворення. Заснований на розробці формальної математичної специфікації програмної системи й перетворенні цієї специфікації за допомогою спеціальних математичних методів у програми. Таке перетворення задовольняє умові "збереження коректності". Це означає, що отримана програма буде в точності відповідати розробленій специфікації.
4. Зборка програмного продукту з раніше створених компонентів. Передбачається, що окремі складові частини програмної системи вже існують, тобто створені раніше. У цьому випадку технологічний процес створення ПО основну увагу приділяє інтеграції окремих компонентів у загальне ціле, а не створенню цих компонентів. Ця технологія більш докладно розглядається в главі 14.
У главі 3 ми повернемося до моделей технологічного процесу створення програмного забезпечення.
1.1.7. Структура витрат на створення ПО

Рис. 1.2. Структура витрат при використанні еволюційного підходах розробці ПО
У вартість створення ПО також можуть включатися витрати на його модернізацію після початку експлуатації програмного продукту. Для багатьох програмних систем витрати на вдосконалювання системи можуть перевищувати вартість розробки в 3 або 4 рази (мал. 1.3).
Точна структура витрат на створення програмного забезпечення істотно залежить від процесів, використовуваних при розробці ПО, а також від типу розроблювального програмного продукту. Якщо прийняти загальну вартість створення ПО за 100 одиниць, то розподіл стоимостей окремих етапів виробництва може мати такий вид, як на мал. 1.1.

Рис. 1.1. Розподіл стоимостей окремих етапів виробництва ПО
Приблизно така структура витрат можлива тоді, коли витрати на створення специфікації, проектування ПО, його розробку й зборку підраховуються окремо. Відзначимо, що часто вартість етапу зборки й тестування перевищує вартість етапу безпосередньо розробки ПО. Наприклад, на мал. 1.1 показана структура витрат, при якій на тестування програмної системи доводиться приблизно 40% загальної вартості витрат. Разом з тим для деяких критичних систем ця стаття витрат може перевищувати 50%.
При використанні еволюційного підходу до розробки ПО практично неможливо провести чітке розмежування між етапами створення специфікації, проектування й розробки ПО. Тому структуру витрат, представлену на мал. 1.1, варто змінити так, як показано на мал. 1.2. Тут залишений окремий етап розробки специфікації, оскільки загальна специфікація вищого рівня створюється ще до початку створення програмного продукту. Створення специфікації нижнього рівня, проектування, реалізація, зборка й тестування ПО при такому підході виконуються паралельно на етапі розробки програмної системи. Разом з тим цей підхід вимагає виконання окремого етапу тестування системи після закінчення початкового етапу її розробки.

Рис. 1.3. Витрати на розробку й удосконалювання ПО
Структура витрат на створення замовленого програмного забезпечення (тобто коли вимоги до системи встановлюються замовником і розробка ПО виконується за контрактом) приблизно така ж, як показано вище, але вартість різних етапів створення програмного продукту може значно відрізнятися. Це ставиться, зокрема, до програм, розроблювальним для персональних комп'ютерів. Як правило, таке програмне забезпечення розробляється на основі еволюційного підходу з використанням уже готового ескізу специфікації. Тому вартість розробки вимог до ПО відносно низька. Разом з тим такі програмні продукти призначені для роботи на різних комп'ютерних платформах, що істотно підвищує витрати на тестування систем. На мал. 1.4 показана типова структура витрат на створення такого ПО.

Рис. 1.4. Структура затратна створення замовленого ПО
Вартість модернізації загальних програмних продуктів (тобто тих, які продаються на відкритому ринку програм) із працею піддається оцінці. У багатьох випадках здійснюється невелика формальна модернізація. Звичайно з початком реалізації створеного програмного продукту починається робота з його наступною версією. Але виходячи з вимог маркетингу переважніше представити нову версію як новий (але сумісний зі старою версією) програмний продукт, а не як модифіковану версію того продукту, що користувач уже купив. Тому вартість модернізації ПО звичайно не підраховується окремо, як це робиться при модернізації замовлених програмних продуктів, а просто входить у вартість розробки наступної версії програмної системи.
Структура витрат на створення систем для електронної комерції в Internet звичайно відрізняється від того, що описано вище. У таких системах замість створення програмних модулів, керуючих інформацією, звичайно використають готове програмне забезпечення, а основні витрати доводяться на розробку користувальницьких інтерфейсів. На момент написання даної книги такі системи тільки почали розроблятися й використатися, тому я, на жаль, не маю у своєму розпорядженні підходящу схему, що ілюструє структуру витрат на створення такого типу програмного забезпечення.
1.1.8. Методи інженерії програмного забезпечення
Ці методи являють собою структурний підхід до створення ПО, що сприяє виробництву високоякісного програмного продукту ефективним, в економічному аспекті, способом. Такі методи, як структурний аналіз [91] і JSD (метод Джексона розробки систем) [181], уперше були представлені ще в 1970-х роках. Ці методи, названі функціонально-модульними або функционально-ориентированными, пов'язані з визначенням основних функціональних компонентів програмної системи й у свій час широко використалися. В 80-90-х роках до цих методів додалися объектно-ориентированные методи, запропоновані Бучем (Booch) [54] і Рамбо (Rumbaugh) [302]. Ці методи, що використають різні підходи, нині інтегровані в єдиний уніфікований метод, побудований на основі уніфікованої мови моделювання UML (Unified Modeling Language) [55, 117, 303, 304, 17*, 30*] .
Всі згадані методи засновані на ідеї створення моделей системи, які можна представити графічно, і на використанні цих моделей як специфікація системи або її структур. Методи інженерії ПО звичайно включають перераховані в табл. 1.2 компоненти.
Таблиця 1.2. Компоненти методів інженерії ПО
Компонент
Опис
Приклад

Опис моделі системи
Опису моделей створюваних систем і нотація, використовувана для розробки цих моделей
Моделі об'єктів, моделі потоків даних, моделі кінцевих автоматів і т.п.

Правила
Правила й обмеження, які необхідно виконувати при розробці моделей систем
Кожний елемент моделі повинен мати унікальне ім'я

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

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


Не існує ідеального й універсального методу - кожний метод має свою область застосовності. Наприклад, объектно-ориентированные методи часто застосовуються для створення інтерактивних (діалогових) програмних систем, але практично не використаються при розробці систем, що працюють у режимі реального часу.
1.1.9. CASE-технологія
Абревіатура CASE позначає Computer-Aided Software Engineering - автоматизована розробка програмного забезпечення. Під цим розуміється широкий спектр програм, застосовуваних для підтримки й супроводу різних етапів створення ПО: аналізу системних вимог, моделювання системи, її налагодження й тестування й ін. Всі сучасні методи створення ПО використають відповідні Кошт-засіб-CASE-засоби: редактори нотацій, застосовуваних для опису моделей, модулі аналізу, що перевіряють відповідність моделі правилам методу, і генератори звітів, що допомагають при створенні документації на розроблювальне ПО. Крім того, Кошт-засіб-CASE-засобу можуть включати генератор коду, що автоматично генерує вихідний код програм на основі моделі системи, а також посібник користувача.
Кошт-засіб-CASE-засоби, призначені для аналізу специфікацій і проектування ПО, іноді називають Кошт-засіб-CASE-засобами верхнього рівня, оскільки вони застосовуються на початковій стадії розробки програмних систем. У той же час Кошт-засіб-CASE-засобу, націлені на підтримку розробки й тестування ПО, тобто отладчики, системи аналізу програм, генератори тестів і редактори програм, часом називають Кошт-засіб-CASE-засобами нижнього рівні.
1.1.10. Характеристики якісного програмного забезпечення
Крім функціональних можливостей, властивим програмним продуктам по опред.- лению, ці продукти володіють і іншими показниками, що характеризують їхніх якостей Дані показники не випливають безпосередньо з того, які дії може выпо нять програмний продукт. Вони характеризують поводження програми під час выпо нения нею своїх дій, структуру й організацію вихідного коду програми, її доі ментированность. Прикладом таких показників (іноді називаних нефункціональна мі показниками) може служити час очікування користувачем відповіді на свій запре або зрозумілість програмного коду.
Звичайно, безліч тих показників або характеристик, які можна чекати про і ПО, залежить від типу програмної системи. Наприклад, банківська система повинна бути захищеної, інтерактивна гра повинна бути чутливої до дій користувача- гравця, систему телефонних перемикань насамперед характеризує її надійність і т.. Але ці специфічні показники, як і безліч інших подібних характеристик, можіи : узагальнити у вигляді показників якісних програмних систем, наведених у табл. 1.3.
Таблиця 1.3. Основні показники якісного програмного забезпечення
Показник
Опис

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

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

Ефективність
Робота ЗД не повинна приводити до марнотратної витрати таких системних ресурсів, як пам'ять або час зайнятості процесора. Тому ефективність ПО описується наступними характеристиками: швидкість виконання, використовуване процесорний час, обсяг необхідної пам'яті й т.п.

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


1.1.11. Основні проблеми, що коштують перед фахівцями із програмного забезпечення
В XXI сторіччі фахівці із програмного забезпечення зштовхнуться з описаними нижче проблемами.
Проблема спадкування раніше створеного ПО. Багато більших програмних систем, експлуатовані в цей час, створені миого років тому, але дотепер виконують свої функції належним чином. Проблема спадкування означає підтримку й модернізацію таких систем, причому при мінімальних фінансових і тимчасових витратах.
Проблема всі зростаючої різнорідності програмних систем. У цей час програмне забезпечення повинне бути здатне працювати як системи, розподілених у комп'ютерних мережах, що складаються з комп'ютерів різних типів і операційних систем, що використають різні. Проблема зростаючої різнорідності програмних систем полягає в тому, що необхідно розробляти надійні програмні системи, здатні працювати разом з ПО різних типів.
Проблема, породжена вимогою зменшення часу на створення ПО. Багато традиційних технологій створення якісного програмного забезпечення вимагають більших тимчасових витрат. Разом з тим сьогодні запити ринку ПО й вимоги до програмних систем міняються дуже швидко. Тому й ПО повинне мінятися з відповідною швидкістю. Проблема, породжена вимогою зменшення часу на створення ПО, полягає в тім, щоб скоротити час на розробку більших і складних програмних систем без зниження їхньої якості.
Звичайно, перераховані проблеми зв'язані один з одним. Наприклад, можлива така ситуація, коли необхідно швидко розробити на основі існуючої системи її мережний варіант. Для рішення таких проблем необхідні нові засоби й технології, які увібрали б у себе всі кращі методи сучасної інженерії програмного забезпечення.
1.2. Професійні й етичні вимоги до фахівців із програмного забезпечення
Подібно будь-яким іншим професіоналам, фахівці із програмного забезпечення повинні погодитися, що до них пред'являється більше широке коло вимог, чим проста необхідність мати той або інший професійний рівень. Вони працюють у певному правовому й соціальному оточенні. Область інженерії програмного забезпечення, як і будь-яка інша сфера людської діяльності, має обмеження у вигляді місцевих, національних і міжнародних законодавств. Тому фахівці із програмного забезпечення повинні прийняти на себе певні етичні й моральні зобов'язання, щоб стати дійсними професіоналами.
Не вимагає зайвих пояснень твердження, що фахівці повинні бути чесними й чималими людьми. Вони не повинні використати свої професійні навички й можливості для діяльності, що дискредитує професію фахівця із програмного забезпечення. Разом з тим вимоги до фахівців не обмежуються тільки моральними або юридичними приписаннями, у їхнє коло також входять значно більше тонкі професійні зобов'язання.
Конфіденційність. Фахівець повинен дотримувати конфіденційності, тобто не розголошувати ніяких відомостей про роботодавця й клієнтів, незалежно від того, підписував він чи ні яка-небудь угода про дотримання конфіденційності.
Компетентність. Фахівець не повинен приховувати (або ложно представляти) свій рівень компетенції й не повинен братися за роботу, що цьому рівню не відповідає.
Захист прав інтелектуальної власності. Фахівець не повинен порушувати відповідне законодавство про захист авторських прав при використанні чужої інтелектуальної власності (патентів і т.п.). Він також повинен захищати інтелектуальну власність роботодавця й клієнтів.
Зловживання комп'ютером. Фахівець не повинен, використовуючи свій професійний рівень, завдавати шкоди комп'ютерам інших людей. Зловживання комп'ютером можуть бути як відносно тривіальними (скажемо, гра в комп'ютерні ігри на машині, що належить роботодавцеві), так і дуже серйозними (наприклад, поширення комп'ютерних вірусів).
У розробці подібних етичних зобов'язань більша роль належить професійним суспільствам і інститутам. Такі організації, як ACM (Association for Computing Machinery- Асоціація по обчислювальній техніці), IEEE (Institute of Electrical and Electronics Engineers - Інститут інженерів по електротехніці й електроніці) і British Computer Society (Британське комп'ютерне суспільство), опублікували кодекс професійного поводження, або етичний кодекс. Члени цих організацій приймають на себе зобов'язання додержуватися даного кодексу. Правила поведінки із цього кодексу засновані на загальнолюдських етичних нормах.
АСМ і IEEE спільно створили кодекс, що з'єднує етичні норми й професійну практику. Цей кодекс існує у двох версіях: короткої, наведеної в урізанні, і повної [134], що розкриває, розширювальної й дополняющей основні положення короткої версії кодексу. Обґрунтування необхідності такого кодексу наведено в перших двох абзацах повної версії.
Обчислювальна техніка в цей час грає всі зростаючу роль у діловій сфері, промисловості, медицині, утворенні, сфері розваг і суспільстві в цілому. Інженерія програмного забезпечення безпосередньо або за допомогою своїх технологій вносить вклад в аналіз і створення специфікації, проектування, розробку, сертифікацію, підтримку й тестування програмних систем. У відповідності зі своєю роллю в створенні програмних систем фахівці із програмного забезпечення мають значні можливості творити добро або робити зло, дозволяти іншим творити добро або робити зло або впливати на інших так, щоб вони творили добро або робили зло. Щоб бути по можливості впевненим у тім, що їхнє зусилля спрямовані тільки на добро, фахівці із програмного забезпечення повинні прийняти на себе зобов'язання ставитися до інженерії програмного забезпечення як до суспільно корисної й шановної професії. У зв'язку із цим зобов'язанням фахівці із програмного забезпечення повинні твердо дотримуватися наступного Кодексу етики й професійної діяльності.
Кодекс містить вісім принципів поводження й прийняття рішень спецштитпами-професашналами по програмному забезпеченню, пов'язаних із практичною діяльністю, самонавчанням, керуванням, керівництвом, а також навчанням студентів даної професії. Принципи визначають етику відносин між окремими особистостями, а також у групах і організаціях, що розділяють і приймають ці принципи. Статті кожного принципу описують конкретні зобов'язання, що визначають ці відносини. Джерела цих зобов'язань - людські якості фахівців із програмного забезпечення, особлива моральна педантичність, властивим людям, що займаються інженерією ПО, і унікальної складової практичної діяльності фахівців, що реалізують методи й технології інженерії програмного забезпечення. Кодекс пропонує зобов'язання як приписання, що припускають неодмінне виконання, і як високі цілі, до яких повинен прагнути фахівець із програмного забезпечення.
, .«»^w. JÉMACM/IEEE (©IEEE/ACM 1999» * ** rt
f Кодекс »тики й практтеск6й,]шггельности инженериипрограммного забезпечення :-.::..
|ACM/IEEE-CS огоедмилинйбй]^^ 'Діяльності инже-
.... ,, .^„ща-^ш^^И^i
! t Л „ «гу a un |,||р|^:яерс1т>Кзденса ДО0£рфывдаодгося.у повної
^ве|х^Шюг.ресимренное,'и' цглей як путо^яким Повинні .следо-
^вать професіонали.в області й^ті^й?прог(йммного забезпечення. Без 'обліку^ледве^ тлумачення бу*
а™м^олкованад;<нб(йзуют^елостный^^кс. «Р >, 'і , , ,„, t - ^Фахівці: по<профашно^гобеспеч»ио преобразуютвыполяемуюимиработу по аналізі исозданию ^специфиющий^^ро^тро!»^ сапррес^внш забезпечення в]
л0бц*е<пренн0п0лезну10 иу^иаа^!про<йссию;_У соотгётствиисэп^крмЦоб^ зобов'язань ^щодо здоров'я, безпеки « благополуччя суспільства, фахівці із програмного забезпечення повинні взяти на себе зобов'язання випливати восьми перерахованим принципам; ( .
» ,it"si. г j «»і й _ , <~ Червоні* » » *
^Суспільні інтереси — діяльність фахівців із програмного, забезпеченню повинна виникати а відповідності із суспільними інтересами й запитами.* i f
^2. Г1Клієнти^і роботодавці г; діяльність фахівців з профаммному забезпеченн-належна ^.^фбыть, спрямована,на ^1{Юнтов. до работоуцатапей .у відповідності; с.общвг.^
»Wft ственными ^^^^^^^^^^^^ ,ч _ , ^ т ^
/щЗ.; Виробництво — фахівець із програмного: забезпеченню должен. гарантувати, .що произ- 1 веденные або модифіковані їм профаммные продукти відповідають найвищим, ка- «кие тільки можливі, професійним стандартам л. -у- » fAj» ^ > < ^4*Професіонали«ые'.(^ждения^фахівець^^те профаммному обеспечеНиюдолжен підтримай-: №м^>вать .честностьрнепредвзятость44 незалежність своїх професійних суджень і оцінок. Ей'б.УП^ проектів Д0Л9№Ы підкорятися високим этиче-
№i^rf$icm» нормам при ихруководстверазработкой і сопровоадениш^профаммногоюбеспечения; ^ М^*6^Професія -гспециапист.по'профаммномуобеспечению повинен,підтримувати на високому
й> ^рівні репутацію своєї професії відповідно до суспільних інтересів, w * ч V-? f£k7.< Колегіальність -фахівець по програмному забезпеченню повинен поддерживатьколлег і < бути ГІДНИМ членом свого колективу^ ^4 _ W "А,
8:^Особистість5-фахівець по програмному ^забезпеченню повинен постійно вчитися, (Чтобысоотг ветствовать рівню своєї професії; ? а також повинен керуватися високими етичними ті нормами в повсякденній практичній професійній діяльності й ^
Звичайно, в одній і тій же ситуації різні люди мають різні погляди й принципи рішення вартих перед ними етичних проблем. Наприклад, як ви надійдете, якщо не згодні з політикою, що проводить керівництво компанії? Очевидно, це залежить від конкретної людини й суті розбіжностей. Що краще - дистанціюватися від позиції компанії або переглянути свої принципи? Якщо ви вважаєте, що ці розбіжності можуть породити проблеми у виконанні програмного проекту, чи будете ви відкрито відстоювати свою позицію перед керівництвом? Якщо ви розраховуєте працювати в цій компанії далі, необхідно рано або пізно вирішувати цю моральну проблему.
Такі етичні дилеми встають перед всіма фахівцями в процесі їхньої професійної діяльності. На щастя, у більшості випадків вони не мають істотного принципового підґрунтя й дозволяються порівняно просто. Якщо ж не дозволяються, виходить, фахівець зштовхнувся, швидше за все, з великою етичною проблемою. У принципі її завжди можна вирішити, просто звільнившись із роботи, але в цьому випадку можливе виникнення інших проблем, наприклад з матеріальним забезпеченням родини.
Особливо важка ситуація для фахівця виникає тоді, коли роботодавець поводиться неетичним образом. Скажемо, компанія розробляє програмну систему, критичну відносно безпеки. Але внаслідок дефіциту часу були підроблені протоколи перевірки системи на захищеність. Чи належний фахівець у цій ситуації підтримувати конфіденційність, тобто нерозголошення інформації про роботодавця, або все-таки варто попередити замовника ПО або додати гласності той факт, що система може бути незахищеної?
Складність цієї проблеми полягає в тому, що не існує критеріїв абсолютної захищеності систем. Фактична захищеність системи може бути перевірена тільки в процесі її тривалої експлуатації. Навіть якщо система задовольняє заздалегідь певним критеріям захищеності, це ще не означає, що вона позбавлена помилок і не може виникнути яких-небудь збоїв у її роботі.
Рання постановка розглянутої етичної проблеми може привести до напруженості між роботодавцем і що служать, а несприятливий результат її рішення може завдати шкоди іншим співробітникам. Ви повинні мати власну точку зору на рішення виниклої проблеми. Але ця точка зору обов'язково повинна враховувати можливі неприємності й збиток, заподіюваний іншим людям. Якщо ситуація дуже серйозна, можна, наприклад, звернутися за підтримкою до засобів масової інформації. Але в кожному разі потрібно намагатися вирішити проблему без завдання збитків правам роботодавця.
Інша етична проблема виникає, якщо ви берете участь у розробці військових або атомних систем. Багато хто відмовляються брати участь у будь-яких розробках, що мають хоч яке-небудь відношення до військової тематики. Деякі згодні працювати над військовою тематикою, не пов'язаної з виробництвом озброєння, а хтось уважає, що національна безпека - достатня підстава, щоб не мати етичних проблем при роботі над системами озброєнь. Тут відповідна етична позиція повністю залежить від поглядів і світогляду конкретної людини.
У цій ситуації важливо, щоб як роботодавець, так і працівники завчасно довідалися погляди один одного. Коли організація включається у військові або атомні проекти, керівництво повинне повідомити колективу, що вони повинні бути готовими прийняти будь-яку роботу відповідного профілю. З іншого боку, якщо штатні співробітники не хочуть брати участь у розробці військових систем, керівництво не повинне робити на них тиск, примушуючи до виконання таких робіт.
До питань професійних етичних норм і відносин інтерес зростає протягом ряду останнього років. Їх можна розглядати виходячи з філософських категорій, що описують базові принципи етики, і на основі етики інженерії програмного забезпечення, що також посилаються иа ці принципи. Такий підхід представлений у роботі [210] і в меншому ступені в 1164].
Однак я знаходжу такий підхід занадто абстрактним і важким для "прив'язки" до моєї повсякденної практики. Я віддаю перевагу більше практичному підхід)', реалізованому в кодексах поводження й професійної діяльності. Я думаю, що етичні проблеми краще обговорювати в практичному контексті інженерії програмного забезпечення, а не як суб'єкти абстрактних загальних прав людини. Тому в даній книзі я не касаюсь абстрактних етичних дискусій, але там, де це можливо, привожу приклади з реального життя, які можуть бути основою для подальшого обговорення.
Л:,. ключові поняття '' "Л'.."
, % гф^зн^М* ^ так} ( н т
Інженерові прогр^мм^ого^забезпечення—.це інженерна дисципліна, котораяоттываетвсеас-- пекты виробництва програмних продуктов. в , "" * ( ( ^
Програмний продукт сострит.изпрограмм і супутньої документації,
Технологічний процес створення ПО складається з окремих процесів, необхідних для созда-« ^ 5 ния програмного продукту Основними^ процесами є створення спецификащ требова-'
' ний, розробка, атестація й совершенствова^прогр^ммного продукту ' * 1« ^ „ ' ' Методи інженерії ПО — це структурні й організаційні ~дешения,*предна^ч"ейные для созда- ; ния програмних продуктів. Вони містять вказівки, випливаючи яким створюється ПО, нотації й пра- -г вила опису програмної системи; необхідні для розробки техническбЙ"документації.
САБЕ-средства — це програмні системи, призначені для підтримки процесів створення ПО, таких як редагування діаграм моделей, перевірка їхньої несуперечності й відстеження процесу тестування програм 1 "
Фахівці із програмного забезпечення мають зобов'язання*перед своєю професією и' суспільством, які не ЗВОДЯТЬСЯ ТІЛЬКИ до"технічних питань ' ч» >-
'' Професійні "співтовариства, опублікували Кодекс" етики й: професійної діяльності,
який установлює правила поведінки для фахівців із програмного забезпечення. -г,м
Вправи
На основі схем структури витрат на створення ПО, представлених у розділі 1.1.7, поясните, чому витрати на первісне обмірковування й обговорення створюваної програмної системи можуть перевершувати вартість продаваних програм.
Назвіть чотири основні характеристики, якими повинен володіти будь-який програмний продукт. Запропонуєте чотири інші характеристики, які також істотні для програмних систем.
Яке розходження між моделлю процесу створення ПО й самим процесом? Приведіть дві ситуації, коли модель процесу створення ПО може бути корисної у визначенні можливих етапів удосконалювання програмного продукту.
Методи інженерії програмного забезпечення широко використають Сабе-технологии для подцержки процесу створення ПО. Назвіть п'ять етапів процесу розробки ПО, де знаходять застосування Сабе-средства.
Крім проблем спадкування раніше створеного ПО, що зростає різнорідності програмних систем і проблеми, породженої вимогою зменшення часу на створення ПО, назвіть інші проблеми, що також коштують перед інженерією ПО.
Обговорите питання про те, чи належні фахівці із програмного забезпечення мати відповідні сертифікати, як, наприклад, лікарі і юристи.
Для кожної статті Кодексу етики й професійної діяльності приведіть відповідні приклади, що ілюструють ці статті.