< Попередня  Змiст  Наступна >

Терміни та поняття


Аналіз — елемент процесу розробки ІС, що відповідає за формулювання задачі в проблемній області. Аналіз указує, що слід зробити, а проектування — як це зробити. Див. Проектування.

Апплет (англ. applet від application — додаток і let — зменшувальний суфікс) — це несамостійний компонент програмного забезпечення, що працює в контексті іншого, самостійного додатка, призначений для однієї вузької задачі і не має цінності окремо від базового додатка.

Артефакт — матеріальний робочий продукт, що має такі характеристики: 1) створюється, змінюється або використовується завданням; 2) визначає ділянку відповідальності; 3) підлягає керуванню версіями. Див. Робочий продукт, Завдання.

Архітектура — найвищий рівень концептуалізації системи у середовищі. Див. Архітектура програмної системи.

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

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

Бізнесмоделювання — загальний термін для всіх методик візуального моделювання бізнеспроцесів, що входять до складу більш загальних методик розробки бізнеспроцесів. Див. Інжиніринг бізнеспроцесів.

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

Дисципліна — набір взаємопов’язаних задач, що утворюють конкретну область діяльності. У розробленні ІС розрізняють такі дисципліни (див. відповідні терміни): бізнесмоделювання, керування вимогами, аналіз і проектування, реалізація, тестування, розгортання, керування конфігурацією і змінами, управління проектом, керування середовищем.

Елемент — атомарна складова моделі.

 

Елемент моделі — базовий об’єкт моделі системи на тому рівні абстракції, на якому вона моделюється.

Елемент наповнення — всі елементи, що змодельовані в UMA і входять до наповнення методу. Елементи наповнення являють собою покрокові інструкції з вирішення конкретних завдань при розробленні продукту незалежно від розташування цих завдань у життєвому циклі розробки. Екземпляри цих елементів створюються і налаштовуються у структурах процесів. Див. Життєвий цикл, Продукт, Процес, Структура, UMA.

Елемент структури — будьякий елемент моделі UMA, що входить до структури процесу. Див. Елемент моделі, UMA.

Життєвий цикл (RUP) — повний цикл, що включає чотири етапи — початковий етап, уточнення, побудову й упровадження. Проміжок часу між початковим етапом та етапом упровадження.

Завдання — мінімальний обсяг роботи, що його можна доручити ролі. Див. Роль.

Зацікавлена особа — особа, безпосередньо зацікавлена в завершенні процесу, наприклад у результатах виконання процесу.

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

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

Інжиніринг бізнеспроцесів — набір методик, за якими компанія розвиває свої бізнеспроцеси для досягнення поставлених цілей. Розроблення бізнеспроцесів є підґрунтям їх оптимізації, поліпшення та створення.

Керування змінами — дисципліна розробки ІС, що відповідає за керування змінами артефактів. Див. Дисципліна.

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

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

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

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

Плагін (від англ. plugin) — програмний модуль, який незалежно компілюється і динамічно підключається до основної програми з метою розширення та/або використання її можливостей. Також перекладається як «модуль». Плагіни зазвичай виконуються у вигляді спільно використовуваних бібліотек.

Процес — 1) загальна структура для певних типів проектів розробки ІС. Процеси являють собою впорядковані послідовності елементів наповнення, що налаштовуються для конкретних типів проектів. Таким чином процес — це набір частково впорядкованих описів роботи, завдання якого полягає у досягненні чергової цілі при розроблення ІС (програмного забезпечення). Ці описи впорядковані в ієрархічну структуру. Основна увага у процесах приділяється життєвому циклу і впорядкуванню роботи. 2) Елемент UMA, що застосовується для моделювання процесів. Див. Елемент наповнення, UMA.

Реалізація дисципліна розробки ІС, метою якої є створення компонентів відповідно до заданих вимог якості. Див. Дисципліна.

Робочий продукт (продукт роботи) — елемент наповнення, який відповідає будьякому об’єкту, що використовується, створюється або змінюється під час виконання завдання. Див.: Елемент наповнення, Завдання.

Розгортання — дисципліна розробки ІС, призначенням якої є доставка працездатної системи користувачам. У це поняття входять також артефакти, такі як навчальні матеріали і керівництва з установки. Див. Дисципліна.

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

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

Структура конструктивний елемент UMA, що подає процес як ієрархічну систему елементів структури. Див. Елемент, Елемент структури, Процес, UMA.

Схема (MOF) — аналог пакета, тобто контейнеру елементів моделі.

Тест — дисципліна розробки ІС, призначенням якої є перевірка цілісності та працездатності системи. Див. Дисципліна.

Управління проектом — дисципліна розробки ІС, що відповідає за планування проекту розробки та керування ним. Див. Дисципліна.

Шаблон — 1) спосіб вирішення типової задачі, корисний у певному контексті. Добрі шаблони враховують конфліктаційні чинники, що становлять сутність проблеми, і вибір шаблона ґрунтується на тому, наскільки успішно він вирішує ці конфлікти. Справжній шаблон може бути застосований щонайменше у трьох практичних додатках. Екземпляр шаблона програмного забезпечення створюється при конкретизації параметрів. Шаблони існують на різних рівнях абстракції та охоплення, наприклад, як архітектурні шаблони, шаблони аналізу, шаблони проектування (див. відповідні терміни), шаблони тестування та шаблони реалізації (див. Ідіома); 2) структура для артефакту, стандартна або така, що поставляється.

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

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

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

Шаблон реалізації — див. Ідіома, Шаблон.

Eclipse вільне інтегроване середовище розробки модульних кроссплатформових додатків, що розвивається і підтримується некомерційною організацією Eclipse Foundation. Серед підпроектів можна назвати Eclipse Modeling Framework (EMF) — засіб моделювання і генерування коду для побудови інструментів та інших додатків, основаних на структурованій моделі даних, зі специфікації моделі, описаній в XMI; Business Intelligence and Reporting Tools (BIRT) — засіб бізнесаналітики і звітування у форматах Web і pdf; Graphical Modeling Framework (GMF) — фреймворк, призначений для автоматичного генерування коду для повнофункціонального графічного редактора моделей за довільною метамоделлю, створеною за допомогою технології EMF.

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

SPEM (Software & Systems Process Engineering MetaModel Specification, специфікація метамоделі програмної і системної інженерії процесів) — стандарт OMG для визначення процесів розробки програмних систем. SPEM обмежується мінімумом складових, необхідних для визначення будьякого процесу, не містить риси, специфічні для певних ділянок або дисциплін. Метою SPEM є не створення узагальненої мови моделювання процесів, а можливість вибрати найбільш підхожий узагальнений підхід до моделювання поведінки.

UMA (Unified Method Architecture, архітектура уніфікованого методу) — новітня архітектура розроблення, створення і зберігання метаданих про процеси і методи.

 

Література

 

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем : Учебник. — М.: Финансы и статистика, 2000.

2. Вендров А. М. CASEтехнологии. Современные методы и средства проектирования информационных систем. — http://www.citforum.ru/ database/case/index.shtml

3. Закис А. RUP и другие методологии разработки ПО. — http:// www.cmcons.com/articles/obshhie_stati_rup/rup_i_drugie_metodologii_razr abotki_po/

4. Колесов А. Введение в методологию Microsoft Solutions Framework // BYTE. — Июль 2004.— № 7 (71).

5. Коллективная разработка с использованием Visual Studio Team Foundation Server // Мейер Дж. Д., Тейлор Дж., Макман А., Бансод П., Джонс К. — http://www.cmcons.com/articles/microsoft/tfsguide/

6. Матеріали сайтів: www.eclipse.org, http://www.ibm.com/, http:// www.itil.org.uk/, http://www.itlibrary.org/, http://www.itsmportal.ru/, http:// www.microsoft.com/msf, http://msdn2.microsoft.com/enus/library/, http:// www.omg.org/, http://www.silverrun.com/

7. Новичков А. Rational Unified Process. Методология и технология. — http://www.cmcons.com/articles/obshhie_stati_rup/rational_unified_process _metodologija_i_tekhnologija/

8. Панащук С. Методология DATARUN и CASEсистема SILVERRUN. — http://www.citforum.ru/database/kbd96/611.shtml

9. Путеводитель по разработке методов. — http://www.cmcons.com/ articles/obshhie_stati_rup/putevoditel_po_razrabotke_metodov/

10. Шамрай А. Адаптируем процессы TFS под свои потребности. — http://www.cmcons.com/articles/microsoft/tfs_custom_process/

11. Comparative Experiences with Software Process Modeling Tools for the Incremental Commitment Model / Koolmanojwong S., Phongpaibul M., Laoteppitak N., Boehm B. — http://sunset.usc.edu/csse/TECHRPTS/2007/ usccsse2007724/usccsse2007724.pdf

12. Haumer P. Eclipse Process Framework Composer. — http://www. eclipse.org/epf/general/EPFComposerOverviewPart1.pdf

13. Haumer P. IBM Rational Method Composer: Part 1: Key concepts. — http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html


< Попередня  Змiст  Наступна >
Iншi роздiли:
3.2. АВТОМАТИЗОВАНА РОЗРОБКА ВИМОГ
3.3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ЗМІНАМИ ВИМОГ
3.4. ХАРАКТЕРИСТИКА СУЧАСНИХ ЗАСОБІВ АВТОМАТИЗОВАНОГО КЕРУВАННЯ ВИМОГАМИ
3.5. КЕРУВАННЯ ВИМОГАМИ ЗА ДОПОМОГОЮ IBM RATIONAL REQUISITEPRO
Тема 4. АВТОМАТИЗОВАНА ПІДТРИМКА ПРИЙНЯТТЯ ПРОЕКТНИХ РІШЕНЬ
Дисциплiни

Англійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki