Задача синтезу опису архітектури інформаційної системи євланов М. В., 2014



Скачати 210.61 Kb.
Дата конвертації27.04.2016
Розмір210.61 Kb.
УДК 004.896

Євланов М. В.,

Харківський національний університет радіоелектроніки

задача синтезу ОПИСУ архітектури ІНФОРМАЦІЙНОЇ СИСТЕМИ

© Євланов М.В., 2014

This paper describes the modern approach to representation of the information system architecture. The author has developed mathematical models of the synthesis of information system architecture description, which are based on the definitions of the global objectives of Provider and User of IT-accommodations. The paper proposes a formal description of the problem of synthesis of architecture description as a game Provider and User of IT-accommodations.

Keywords – information system, architecture, requirement, IT-project, IT-accommodation.

У статті розглянутий сучасний підхід до представлення архітектури інформаційної системи. Виходячи із визначень глобальних цілей Постачальника та Споживача ІТ-послуг, розроблено математичні моделі синтезу опису архітектури інформаційної системи. Запропоновано формальний опис задачі синтезу опису архітектури як гри Постачальника та Споживача ІТ-послуг.

Ключові слова – інформаційна система, архітектура, вимога, ІТ-проект, ІТ-послуга.

Вступ


В основі сучасного представлення робіт з виконання процесів життєвого циклу інформаційних систем (ІС) та програмних продуктів знаходяться концепції управління проектами [1, 2]. Під проектом в [1] розуміється спроба дій з визначеними початковою та кінцевою датами, що здійснюється для створення продукту чи послуги у відповідності із заданими ресурсами та вимогами. Там же вказано, що проект може розглядатися як унікальний процес,який включає до себе координовані та контрольовані дії і може бути комбінацією дій з процесів проекту та технічних процесів. Виходячи з цього визначення, проект слід вважати ІТ-проектом, якщо його результатом є ІС, програмний продукт або якісь пов’язані з ними послуги. ІТ-проекти можуть розглядатися як окремі проекти, так і як елементи програм створення та розвитку ІТ-інфраструктури підприємства чи його окремих бізнес-процесів.

Якщо результатом ІТ-проекту є ІС або пов’язані з нею послуги, то цей проект в загальному випадку повинен складатися з таких процесів [1]:



  1. процес планування проекту;

  2. процес оцінювання проекту;

  3. процес контроля проекту;

  4. процес прийняття рішень;

  5. процес управління ризиками;

  6. процес управління конфігурацією;

  7. процес управління інформацією.

Якщо ж результатом ІТ-проекту є програмний продукт або пов’язані з ним послуги, то цей проект в загальному випадку повинен складатися з таких процесів [2]:

  1. процес планування проекту;

  2. процес управління та оцінювання проекту;

  3. процес менеджменту рішень;

  4. процес менеджменту ризиків;

  5. процес менеджменту конфігурації;

  6. процес менеджменту інформації;

  7. процес вимірювань.

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

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

Аналіз наведених процесів ІТ-проектів вказує, що основою для планування ІТ-проектів створення ІС є результати технічного процесу синтезу архітектури системи [1]. Під архітектурою слід розуміти фундаментальні поняття і властивості системи в оточуючому її середовищі, які втілено в її елементах, відношеннях, а також в принципах її проектування та розвитку [3]. Це визначення на думку авторів стандарту ISO/IEC 42010:2010 є максимально загальним визначенням, яке годиться для опису архітектур практично будь-яких систем. Зараз для опису архітектури ІС використовуються два основних механізми: архітектурний фреймворк та мови опису архітектури. Архітектурним фреймворком називають конвенції, принципи та методи опису архітектури, які встановлено в конкретній галузі використання та/або спільнотою зацікавлених сторін. Мовою опису архітектури називають будь-яку форму виразу, яка може бути використана в описі архітектури [3]. Але незалежно від механізму, який буде використовуватися під час планування ІТ-проекту створення ІС, виникає необхідність вирішення задачі синтезу такого опису архітектури системи, який вдовольняє як основним проектним обмеженням, так і вимогам, що висуваються до створюваної ІС. Тому дослідження моделей і методів, які дозволяють формалізувати цей процес та вирішувати задачу синтезу раціонального опису архітектури ІС, є актуальними як з теоретичної, так і з практичної точок зору.

Аналіз основних особливостей архітектури інформаційної системи


В теперішній час не існує єдиної точки зору на формальний опис архітектури ІС. Різні автори вживають цей термін із різним змістом, або ж виділяють в складі архітектури різну кількість складових компонентів – від двох до семи чи більше [4-8]. Так, наприклад, в [5] пропонується визначати термін «архітектура ІС» як концепцію, що визначає модель, структуру, виконувані функції та взаємозв’язок компонентів ІС. В [8] пропонується розглядати архітектуру ІС як сталу сукупність структурних, функціональних та споживацьких характеристик системи, що розробляється, наявність яких забезпечує у системи такі властивості або якості: задана продуктивність системи (system performance); надійність функціонування (reliability); захищеність / безпека експлуатації системи (safety / security); можливість її ефективного супроводження та розвитку (maintenance and evolution). Іноді під час визначення терміну «архітектура ІС» додатково говорять про конкрет ні естетичні вимоги до створюваної ІС [6, 7]: добре спроектована ІС повинна вдовольняти набору ознак привабливості для користувача (to be presentable for user). Важливим також є відміна терміну «архітектура ІС» від терміну «структура системи»: якщо структура системи описує тільки статичні аспекти її побудови, то архітектура ІС визначає також і динаміку поведінки (behaivor) відповідної ІС, а також визначає інтерфейси її взаємодії з навколишнім середовищем [8].

Між тим, аналіз сучасного визначення терміну «архітектура системи», який зафіксовано у стандарті ISO/IEC 42010:2010, дозволяє вказати на такі відмінні особливості того, що розуміється під цим терміном. Так, зазначений стандарт не накладає ніяких обмежень на визначення терміну «система» для користувачів даного стандарту. Розділення термінів «фундаментальні поняття або властивості» було зроблено для підтримки двох різних філософій архітектури без надання переваги будь-якій з них. Мова йде про наступні філософії [3]:



  • архітектура як сукупність фундаментальних понять (концепція) – абстрактне визначення системи;

  • архітектура як сприйняття – сприйняття властивостей системи.

З точки зору будь-якої з цих філософій архітектура є абстракцією, а не артефактом. Для визначення артефактів, які можуть використовуватися для вираження та опису архітектури, стандарт ISO/IEC 42010:2010 використовує інший термін – «опис архітектури». На жаль, широко розповсюджено використання терміну «архітектура», за яким абстрактна ідея змішується з артефактами, що використовують цю ідею – наприклад, в галузі архітектур підприємств [9].

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

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

Формулювання цілі статті


Розглянуті вище особливості сучасного визначення терміну «архітектура системи» дозволяють сформулювати підхід до використання архітектури ІС та її описів під час вирішення задачі синтезу архітектури створюваної ІС. За цим підходом для вирішення зазначених задач слід використовувати таку похідну інформацію:

  • сукупність вимог до ІС;

  • множину можливих архітектур ІС як сукупність знань та правил проектування системи.

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

Таке представлення задачі синтезу опису архітектури дозволяє поєднати цю задачу із типовими задачами планування ІТ-проекту створення ІС. Формальний опис ІТ-проектів базується на загальному для усіх проектів підході, який розглядає проект як залежність, що пов’язує разом такі характеристики:



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

  • вартість проекту;

  • час виконання проекту;

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

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

Ці відзнаки ІТ-проекту дозволяють виділити два основних типи задач, які вирішуються учасниками ІТ-проекту на стадіях його ініціації та планування:



  1. визначення змісту та/або якості виконання ІТ-проекту, що є раціональними для висунутих вимог до вартості та часу виконання даного ІТ-проекту;

  2. визначення вартості та/або часу виконання ІТ-проекту, що є раціональними для Постачальника ІТ-послуг та для висунутих Споживачем ІТ-послуг вимог до змісту та якості даного ІТ-проекту.

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

Під Споживачем та Постачальником ІТ-послуг тут і в подальшому слід розуміти зацікавлені сторони ІТ-проекту, зміст ролей яких розглянуто автором у [11, 12]. При цьому глобальною метою Постачальника ІТ-послуг слід вважати надання Споживачу ІТ-послуг такого набору ІТ-послуг, який найкращим чином відповідає комплексу вимог, визначених Споживачем ІТ-послуг та особливостями бізнес-процесів Споживача при обмеженнях на вартість, час виконання, якісь та зміст робіт з надання даного набору ІТ-послуг Споживачу. Глобальною метою Споживача ІТ-послуг слід вважати пошук та організацію взаємодії з таким Постачальником ІТ-послуг, який надає набір ІТ-послуг, що найкращим чином відповідає комплексу вимог, визначених Споживачем ІТ-послуг та особливостями бізнес-процесів Споживача при обмеженнях на вартість, час виконання, якісь та зміст робіт з надання даного набору ІТ-послуг, обраних Постачальником [11, 12].

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

Виклад основного матеріалу статті


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

, (1)

де – узагальнений опис i-ої вимоги до ІС, окремої ІТ-послуги ІС чи окремого ІТ-сервісу ІТ-послуги ІС;

– ідентифікатор узагальненого опису вимоги , ;

– кількість вимог, які було висунуто до ІС, її ІТ-послуг та ІТ-сервісів цих послуг.

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

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

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

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

Запропоновані узагальнені описи вимог та оператори дозволяють сформулювати узагальнений формалізований опис глобальної мети Постачальника ІТ-послуг як наступну задачу:

, (2)

(3)


де - позначення Постачальника ІТ-послуг та відповідних ІТ-сервісів;

– ступінь вдоволення вимоги до створюваної ІС з точки зору Постачальника ІТ-послуг;

– нормативний коефіцієнт вартості виконання вимоги , який враховує індивідуальні особливості Постачальника ІТ-послуг;

– мінімально припустима для Постачальника ІТ-послуг величина вартості виконання множини вимог до ІС із визнаним ступенем вдоволення;

– нормативний коефіцієнт тривалості виконання вимоги , який враховує індивідуальні особливості Постачальника ІТ-послуг;

– максимально припустима для Постачальника ІТ-послуг величина часу виконання множини вимог до ІС із визнаним ступенем вдоволення;

– нормативний коефіцієнт якості виконання вимоги , який враховує індивідуальні особливості Постачальника ІТ-послуг;

– максимально припустима для Постачальника ІТ-послуг величина показнику якості виконання множини вимог до ІС із визнаним ступенем вдоволення.

Узагальнений формалізований опис глобальної мети Споживача ІТ-послуг в процесі синтезу опису архітектури ІС може бути представлений як наступна задача:

, (4)

(5)

де – позначення Споживача ІТ-послуг та відповідних ІТ-сервісів;

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

– нормативний коефіцієнт вартості виконання вимоги , який враховує індивідуальні особливості Споживача ІТ-послуг;

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

– нормативний коефіцієнт тривалості виконання вимоги , який враховує індивідуальні особливості Споживача ІТ-послуг;

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

– нормативний коефіцієнт якості виконання вимоги , який враховує індивідуальні особливості Споживача ІТ-послуг;

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

Однак таке формальне представлення цілей Постачальника та Споживача ІТ-послуг має загальний характер. Виходячи з класифікації вимог до ІС, наведеної в [13], функції (2) та (4) мають вигляд:

(6)

(7)

де – бізнес-вимога, яка належить підмножині вимог ;

– вимога до ІС як до аспекту бізнесу, яка належить підмножині вимог ;

– вимога до ІС в цілому, яка належить підмножині ;

– функціональна вимога до ІТ-послуги, яка належить підмножині ;

– нефункціональна вимога до ІТ-послуги, яка належить підмножині ;

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

– нефункціональна вимога до ІТ-сервісу, яка належить підмножині .

Для будь-яких з виділених підмножин множини повинно виконуватися правило

. (8)

Це правило визначає неможливість розглядання опису будь-якої вимоги до ІС як такої, що належить до двох чи більше груп вимог одночасно [13].

Тоді опис глобальної мети Постачальника ІТ-послуг можна представити наступним чином:

, (9)

(10)

де – нормативний коефіцієнт повноти реалізації бізнес-вимоги , який враховує індивідуальні особливості Постачальника ІТ-послуг;



– мінімально припустимий для Постачальника ІТ-послуг рівень повноти реалізації підмножини бізнес-вимог до створюваної ІС

– нормативний коефіцієнт повноти реалізації вимоги до ІС як до аспекту бізнесу , який враховує індивідуальні особливості Постачальника ІТ-послуг;

– мінімально припустимий для Постачальника ІТ-послуг рівень повноти реалізації підмножини вимог до створюваної ІС як до аспекту бізнесу;

– нормативний коефіцієнт повноти реалізації вимоги до ІС в цілому , який враховує індивідуальні особливості Постачальника ІТ-послуг;

– мінімально припустимий для Постачальника ІТ-послуг рівень повноти реалізації підмножини вимог до створюваної ІС в цілому;

– нормативний коефіцієнт повноти реалізації нефункціональної вимоги до ІТ-послуги , який враховує індивідуальні особливості Постачальника ІТ-послуг;

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

– нормативний коефіцієнт повноти реалізації функціональної вимоги до ІТ-сервісу , який враховує індивідуальні особливості Постачальника ІТ-послуг;

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

– нормативний коефіцієнт повноти реалізації нефункціональної вимоги до ІТ-сервісу , який враховує індивідуальні особливості Постачальника ІТ-послуг;

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

Опис глобальної мети Споживача ІТ-послуг можна представити наступним чином:

, (11)

(12)

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

– мінімально припустимий для Споживача ІТ-послуг рівень повноти реалізації підмножини бізнес-вимог до створюваної ІС

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

– мінімально припустимий для Споживача ІТ-послуг рівень повноти реалізації підмножини вимог до створюваної ІС як до аспекту бізнесу;

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

– мінімально припустимий для Споживача ІТ-послуг рівень повноти реалізації підмножини вимог до створюваної ІС в цілому;

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

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

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

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

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

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

Такий підхід до опису вимог до ІС дозволяє розглядати задачу синтезу опису архітектури ІС згідно із визначеним вище підходом як наступні задачі одночасно:



  • задача синтезу раціонального опису функціональної структури ІС як сукупності ІТ послуг на основі описів функціональних вимог до ІТ-послуг створюваної ІС;

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

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

  • за кількістю гравців – гра двох осіб;

  • за кількістю стратегій – скінченна гра, число чистих стратегій якої визначається числом типових функціональних модулів ІС, що пропонуються Постачальником Споживачеві ІТ-послуг;

  • за типом взаємовідношень гравців – безкоаліційна гра, до закінчення якої Постачальник та Споживач ІТ-послуг не можуть діяти сумісно (наприклад, не можуть затверджувати документ «Технічне завдання на розробку інформаційної системи») [14];

  • за характером виграшів – гра з нульовою сумою (загальний капітал Постачальника та Споживача ІТ-послуг перерозподіляється між ними залежно від результатів гри);

  • за виглядом функції виграшу – біматрична гра, оскільки функції виграшів Постачальника (9) та Споживача ІТ-послуг (12) різні.

В загальному випадку така гра для Постачальника та Споживача ІТ-послуг має вигляд:

, (13)



де – позначення гри Постачальника та Споживача ІТ-послуг;

– множина гравців, які беруть участь у грі ;

– множина стратегій гри ;

– множина функцій виграшів гри , яка складається з виразів (9) та (11) при умовах виконання обмежень (10) та (12) відповідно.

Висновки


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

  • максимально відповідає вимогам, що висунуто Споживачем ІТ-послуг;

  • приносить Постачальнику ІТ-послуг бажаний прибуток від повторного використання ІТ-послуг та відповідних ІТ-сервісів;

  • забезпечує реалізацію безперервних технологічних ланцюжків збору, зберігання та обробки даних в межах єдиної цілісної ІС;

  • гарантує відсутність в створюваній ІС ІТ-послуг, які не є обов’язковими і не відповідають висунутим вимогам.

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

1. ГОСТ ИСО/МЭК 15288–2005. Системная инженерия. Процессы жизненного цикла систем. Введ. 01–01–2007. Стандартинформ, М., 2006. 2. ГОСТ ИСО/МЭК 12207–2010. Системная и программная инженерия. Процессы жизненного цикла программных средств. Введ. 01–03–2012. Стандартинформ, М., 2011. 3. Сайт «ISO/IEC/IEEE 42010 Website». – http://www.iso-architecture.org/ieee-1471/index.html. 4.  Захман Дж. Бизнес и информационные технологи: лекция / Дж. Захман. – http://www.intuit.ru/department/ itmngt/entarc/1/. 5. Информационная система // Сайт «Глоссарий.ru». – http://www.glossary.ru/cgi-bin/gl_sch2.cgi? RIt(uwsg.outt:l!xoxyls:. 6. Соммервил И. Инженерия программного обеспечения. Издательский дом «Вильямс», Москва, 2002. 7. Foegen, M. Die Rolle der Architektur in der Anwendungsentwicklung / M. Foegen, J. Batterfeld // Informatik-Spektrum. Springer. 2001. № 5(24). 8. Архитектуры, модели и технологии программного обеспечения информационно-управляющих систем: монография / Ткачук Н.В., Шеховцов В.А., Кукленко Д.В., Сокол В.Е. Под ред. М.Д. Годлевского. НТУ «ХПИ», Харьков, 2005. 9. Zachman, J.A. Architecture is Architecture is Architecture // Сайт «Zachman Intermational». – http://test.zachmaninternational.com/index.php/ea-articles/68-architecture-is-architecture-is-architecture. 10. COCOMO II Model Definition Manual // Сайт «Center for Systems and Software Engineering». –ftp://ftp.usc.edu/pub/soft_engineering/COCOMOII/cocomo99.0/modelman.pdf. 11. Евланов М.В. Глобальные цели поставщика и потребителя ИТ-услуг / М.В. Евланов, О.Е. Неумывакина, А.Ю. Карамышева // Восточно-европейский журнал передовых технологий. 2012. № 5/2 (59). 12. Левыкин В.М. Паттерны проектирования требований к информационным системам: моделирование и применение / В.М. Левыкин, М.В. Евланов, М.А. Керносов. ООО «Компанія СМІТ», Харьков, 2014. 13. Евланов М.В. Определение понятия «требование к информационной системе» // Вісник Академії митної служби України. Серія «Технічні науки», 2012, № 2. 14. Chase, R.B. Production and operations management: manufacturing and services / R.B. Chase, N.J. Aquilano, R.F. Jacobs. Irwin, Boston, 1998.


База даних захищена авторським правом ©shag.com.ua 2016
звернутися до адміністрації

    Головна сторінка