Що таке архітектура програмного забезпечення?, Різне, Програмування, статті

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

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


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


Переважно-програмна система – це будь-яка система, в якій програмне забезпечення значно впливає на проект, конструкцію, розгортання і розвиток всієї системи. [З IEEE 1471. Див далі розділ “Архітектура визначає”.]


В даній статті термін “архітектура”, якщо немає особливих пояснень, – синонім терміна “архітектура програмного забезпечення”. Хоча у статті основний упор робиться на переважно-програмних системах, важливо мати на увазі, що така система не може працювати без апаратного забезпечення, тому деякі характеристики, такі як надійність або продуктивність, досягаються поєднанням програмного і апаратного забезпечення. Тому в загальному рішенні не можна ігнорувати апаратний аспект. Більш докладно це розглядається далі в цій статті.


Архітектура визначає


Коли мова заходить про “архітектурі”, зазвичай не виникає нестачі в визначеннях. Є навіть Web-сайти, які збирають такі визначення.1 У даній статті ми використовуємо визначення стандарту IEEE Std 1472000, і тIEEE 1471 Рекомендовані методи опису архітектури переважно-програмних систем IEEE.2 Ось це визначення, в якому жирним шрифтом виділено основні характеристики.


Архітектура – це базова організація системи, Втілена в її компонентах, Їх відносинах між собою і з оточенням, А також принципи, що визначають проектування та розвиток системи. [IEEE 1471]


У цьому стандарті також визначаються такі терміни. пов’язані з даним визначенням:


Система – Це набір компонентів, об’єднаних для виконання певної функції або набору функцій. Термін “система” охоплює окремі додатки, системи в традиційному сенсі, підсистеми, системи систем, лінійки продуктів, сімейства продуктів, цілі корпорації і інші агрегації, що мають відношення до даної теми. Система існує для виконання однієї або більше місій в своєму оточенні. [IEEE 1471]


Оточення, Або контекст, визначає хід і обставини економічних, експлуатаційних, політичних та інших впливів на систему. [IEEE 1471]


Місія – Це застосування або дія, для якого одне або кілька зацікавлених осіб планують використовувати систему відповідно до деяким набором умов. [IEEE 1471]


Зацікавлена ​​особа – Це фізична особа, група або організація (або її категорії), які зацікавлені в системі або мають пов’язані з нею завдання. [IEEE 1471]


Ми бачимо, що у визначеннях часто вживається термін “компонент”. Тим не менш, велика частина визначень архітектури не визначає терміну “компонент”, і IEEE 1471 – не виняток, оскільки навмисно залишає це поняття невизначеним, щоб воно відповідало безлічі тлумачень, можливих в галузі. Компонент може бути логічним або фізичним, технологічно-незалежним або технологічно-зв’язаним, крупно-або дрібногранульованою. У цій статті я використовую визначення компонента по специфікації UML 2.0 в досить широкому сенсі, що дозволяє охопити різні елементи архітектури, які можуть нам зустрітися, у тому числі об’єкти, технологічні компоненти (такі як корпоративні компоненти JavaBean), сервіси, програмні модулі, традиційні системи, архіви додатків і т. д. Ось визначення терміна “компонент” по специфікації UML 2.0:


[Компонентом називається] модульні частина системи, яка інкапсулює її вміст; втілення компонента є заміщаються в його оточенні. Поведінка компонента визначається в термінах наданого і необхідного інтерфейсів. Таким чином, компонент використовується в якості типу, відповідність якого описується цими двома інтерфейсами, що надаються і необхідним (об’єднуючи як статичну, так і динамічну їх семантику).3

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


Архітектура – це набір значущих рішень з приводу організації системи програмного забезпечення, набір структурних елементів та їх інтерфейсів, за допомогою яких компонується система, разом з їх поведінкою, Що визначаються у взаємодії між цими елементами, компоновка елементів в поступово укрупняющиеся підсистеми, а також стиль архітектури який направляє цю організацію – елементи та їх інтерфейси, взаємодії і компоновку. [Крачтен (Kruchten]4


Архітектура програми або комп’ютерної системи – це структура або структури системи, які включають елементи програми, видимі ззовні властивості цих елементів і зв’язку між ними. [Басс (Bass) і др.]5


[Архітектура – це] структура організації та пов’язане з нею поводження системи. Архітектуру можна рекурсивно розібрати на частини, які взаємодіють за допомогою інтерфейсів, зв’язку, які з’єднують частини, та умови складання частин. Частини, які взаємодіють через інтерфейси, включають класи, компоненти і підсистеми. [UML 1.5]6


Архітектура програмного забезпечення системи або набору систем складається з усіх важливих проектних рішень з приводу структур програми і взаємодій між цими структурами, які становлять системи. Проектні рішення забезпечують бажаний набір властивостей, які має підтримувати система, щоб бути успішною. Проектні рішення надають концептуальну основу для розробки системи, її підтримки та обслуговування. [Мак-Говерн (McGovern)]7


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


Архітектура визначає структуру


Якщо ви попросите описати “архітектуру”, то дев’ять чоловік з десяти обов’язково згадають про структуру. Це поняття в англійській мові часто пов’язується з будівництвом будівель або деяких інших інженерних споруд (engineering structure), наприклад, мостів. Хоча існують і інші характеристики цих елементів, такі як поведінка, відповідність мети і навіть естетика, але саме термін “структура (structure)” найбільш відомий і найчастіше згадується.


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


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


Приклад деяких структурних елементів показаний на малюнку 1. На малюнку зображена діаграма класів UML, що містить деякі структурні елементи, які представляють систему обробки замовлень. Ми бачимо три класи – OrderEntry, CustomerManagement і AccountManagement. Клас OrderEntry залежить від класу CustomerManagement і від класу AccountManagement.


Малюнок 1: діаграма класу UML class, що демонструє структурні елементи


Архітектура визначає поведінку


Поряд з визначенням структурних елементів будь архітектура визначає взаємодії між цими структурними елементами. Це такі взаємодії, які забезпечують бажану поведінку системи. На малюнку 2 представлена ​​діаграма сценарію UML, яка показує кілька взаємодій, які в сумі дають змогу системі підтримувати створення замовлення в системі обробки замовлень. Ми бачимо тут п’ять взаємодій. Спочатку, діяч Sales Clerk створює замовлення за допомогою екземпляра класу OrderEntry. Примірник класу OrderEntry отримує відомості про клієнта за допомогою екземпляра класу CustomerManagement. Потім екземпляр класу OrderEntry використовує примірник класу AccountManagement для того, щоб створити замовлення, внести в нього елементи замовлення, а потім розмістити замовлення.


Рисунок 2: діаграма сценарію UML, що показує елементи поведінки


Слід зазначити, що малюнок два узгоджується з малюнком 1 так, що ми можемо витягти залежності, показані на малюнку 1, з взаємодій, визначених на малюнку 2. Наприклад, екземпляр класу OrderEntry в процесі виконання залежить від екземлярах класу CustomerManagement, як показують взаємодії на малюнку 2. Ця залежність відбивається щодо залежності між відповідними класами OrderEntry і CustomerManagement, як показано на малюнку 1.


Архітектура концентрується на значущих елементах


Хоча архітектура визначає структуру і поведінку, вона визначає не все в структурі і не все в поведінці. Вона займається тільки такими елементами, які оцінюються як значущі. Значущі елементи – це елементи, які мають тривалий і стійкий дію, наприклад, головні структурні елементи, елементи, пов’язані з основним поведінкою і елементи, які визначають значимі властивості, такі як надійність і масштабованість. Як правило, архітектура не має відношення до гранулярним деталям цих елементів. Архітектурну значущість можна також назвати економічної значимістю, оскільки головний ознака, за якою деякі елементи оцінюються вище інших – це вартість створення і вартість зміни.


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


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


Архітектура врівноважує потреби зацікавлених осіб


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


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



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


Архітектура втілює рішення на основі логічного обгрунтування


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


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


Архітектура може відповідати деякому архітектурному стилю


Більшість архітектур побудовані на основі систем, які використовують подібні набори інтересів. Подібність може бути визначене як архітектурний стиль, який можна розглядати як особливий вид шаблону, хоча цей шаблон часто є складним і складовим (коли одночасно застосовуються декілька шаблонів). Як і шаблон, архітектурний стиль являє собою кодифікацію досвіду, і для розробників архітектур було б непогано чекати нагоди, щоб знову використовувати цей досвід. Приклади архітектурних стилів включають розподілений стиль, стиль “канали та фільтри”, стиль з централізованою обробкою даних, стиль, побудований на правилах і так далі. Конкретна система може демонструвати більш одного архітектурного стилю. Ось як описують архітектурний стиль Шоу і Гарлан (Show and Garlan):


[Архітектурний стиль] визначає сімейство систем в термінах шаблону організації структури. Точніше, архітектурний стиль визначає номенклатуру компонентів і типів з’єднувальних ланок, а також набір умов, відповідно до яких вони можуть з’єднуватися. 9

Ще одне визначення в термінах UML:


[Шаблон] – це загальне рішення загальної проблеми в даному контексті. 10

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


На архітектуру впливає її оточення


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


І навпаки, як це яскраво описано у Басса, Клементса і Кацмана (Bass, Clements і Kazman),11 архітектура теж впливає на своє оточення. Створення архітектури змінює оточення не тільки з технологічної точки зору – вона може, наприклад, привносити в організацію багаторазово використовувані активи – створення архітектури може також змінити середу в термінах навичок, доступних в межах організації.


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


Стандарт IEEE Std 12207-1995, IEEE Standard for Information Technology – Software Life Cycle Processes (Стандарт IEEE з інформаційних технологій – Процеси життєвого циклу програми) визначає систему інакше, ніж раніше згадане визначення стандарту IEE 1471 (яке концентрується на переважно-програмних системах), але при цьому узгоджується з визначенням системи в області системного проектування:


[Системою називається] інтегрований комплекс, що складається з одного або більше процесів, апаратних пристроїв, програм, засобів і людей, що надає можливість задовольнити цю потребу або умова. [IEEE 12207]12
Технічний опис “A configuration of the Rational Unified Process for Systems Engineering (RUP SE)” містить схоже визначення.
[Системою називається] набір ресурсів, що надає послуги, які використовуються підприємством для виконання мети або місії бізнесу. Компоненти системи зазвичай складаються з апаратного забезпечення, програмного забезпечення, інформаційних ресурсів та співробітників13.

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


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


Архітектура впливає на структуру колективу


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


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


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


Архітектура представлена ​​в кожній системі


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


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


Архітектура має особливу область застосування


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


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


Рисунок 3: області застосування різних термінів


Елементи, показані на малюнку 3:



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


І зараз, коли ми розглянули ці визначення, багато питань залишилися без відповіді. У чому полягає різниця між архітектурою корпорації і архітектурою системи? Чи є корпорація системою? Архітектура інформації та архітектура даних, яка зустрічається в деяких переважно-інформаційних програмах – це одне й те саме? На жаль, на ці питання немає узгоджених відповідей.


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


Висновок


У цій статті робиться наголос на визначенні основних характеристик архітектури програмного забезпечення. Проте на багато питань ми не відповіли. У чому полягає роль розробника архітектури програмного забезпечення? Які основні дії повинен виконувати розробник архітектури? У чому переваги “розробки архітектури”? На ці та інші питання ми відповімо в наступних статтях цього циклу.


Примітки


1 Web-сайт Інституту розробки програмного забезпечення (SEI), присвячений архітектурі – визначення архітектури, багато хороших прикладів. Cм. www.sei.cmu.edu/architecture/definitions.html


2 Комп’ютерне товариство IEEE, Рекомендовані IEEE методи опису архітектури переважно-програмних систем: стандарт IEEE 1472000. 2000.


3 Object Management Group Inc., UML 2.0 Infrastructure Specification: Document number 03-09-15 (Специфікація інфраструктури мови UML 2.0: Документ номер 03-09-15). Вересень 2003


4 Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition (Філіп Крачтен, Rational Unified Process: вступ, третє видання, видавництво Addison-Wesley Professional 2003).


5 Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice, Second Edition (Льон Басс, Пол Клементс і Рік Кацман, Практична архітектура програмного забезпечення, друге видання), видавництво Addison Wesley 2003 рік.


6 Object Management Group Inc., Специфікація уніфікованої мови моделювання OMG версія 1.5, Документ номер 03-03-01. Березень 2003


7 James McGovern, et al., A Practical Guide to Enterprise Architecture (Джеймс Мак-Говерн та інші, Практичний посібник з архітектури корпорацій). Видавництво Prentice Hall 2004


8 Роль, яка буде розглянута в наступній статті цього циклу.


9 Mary Shaw and David Garlan, Software Architecture – Perspectives on an Emerging Discipline (Мері Шоу і Девід Гарлан, Архітектура програмного забезпечення – перспективи народження предмета) Видавництво Prentice Hall 1996


10 Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide (Греді Буч, Джеймс Рамбаф і Івар Джекобсон (Керівництво користувача по уніфікованому мови моделювання (UML) видавництво Addison Wesley 1999 рік.


11 Bass et al. (Басс та інші), цитований твір.


12 Комп’ютерне товариство IEEE, Стандарт IEEE з інформаційних технологій – Процеси життєвого циклу програмного забезпечення. Стандарт IEEE 12207-1995.


13 Murray Cantor, “Rational Unified Process for Systems Engineering.” Журнал The Rational Edge, серпень 2003 р. (Мюррей Кантор, “Застосування Rational Unified Process в системному проектуванні”. download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*