Технології розробки корпоративних вимог
30. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем інтелектуальної обробки даних (Data Mining).
- технології інтелектуальної обробки даних, орієнтовані на область закономірностей. Інтелектуальна обробка проводиться методами інтелектуального аналізу даних (Data Mining). За допомогою цих технологій 23 вирішуються задачі пошуку функціональних і логічних закономірностей у накопиченій інформації, пояснення аномалій у даних.
41. Нотація стандарту DFD (Data Flow Diagram).
- функції (роботи, бізнес-процеси) системи (Activity) - відображають процеси обробки і зміни інформації. Activity являють собою функції системи, що перетворять входну інформацію на вихідну. Незважаючи на то, що функції зображуються прямокутниками з округленими кутами, зміст їх збігається зі змістом функцій IDEF0. Вони (Activity) мають входи і виходи, але не підтримують «Управління» і «Механізм», як в нотації IDEF0. Стрілка (Arrow) може заходити в блок з будь-якої сторони Activity; Функція (робота) системи, яка перетворює або використовує потік даних Ім'я зовнішнього об'єкту Ім'я зовнішнього об'єкту Ім'я об'єкта № Ім'я об'єкта Ім'я об'єкта Поняття управляючого потоку відсутнє Ім'я об'єкта - дуги або стрілки (Arrow) - відображають інформаційні потоки . На відміну від стрілок (Arrow) IDEF0, які являють собою жорсткі взаємозв'язки, стрілки DFD показують, як об'єкти (включаючи дані) рухаються від однієї функції (роботи) до іншої. Ця представлення потоків разом зі сховищами даних і зовнішніми сутностями робить моделі DFD більш схожими на фізичні характеристики системи - рух об'єктів даних, їх зберігання, постачання і розповсюдження; - сховища даних (Data Store) - відображають дані (таблиці бази даних, інформація документів, сховища даних, накопичувачі даних і т.д.), до яких здійснюється доступ. Ці дані використовуються, створюються або змінюються функціями (Activity) системи (рис. 7.7); -зовнішні сутності (External References) - відображають об'єкти даних, з якими відбувається взаємодія (діючі особи, що надають інформацію; джерела даних, сховища даних, дані документів і т.д.).
38. Визначення цілісності зв'язків у відповідності зі стандартом IDEF1X (Integration Definition for Information Modeling eXtended), реалізованим в CASE-засобі All Fusion Data Modeler (ErWin).
. RESTRICT (ограничить, запретить) - запретить выполнение операции, приводящей к нарушению ссылочной целостности. 2. CASCADE (каскадировать) - разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других сущностях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. 3. SET NULL (установить в Null) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на неопределенные (Null) значения. 4. SET DEFAULT (установить по умолчанию) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию. 5. NO ACTION (игнорировать) - выполнять операции, не обращая внимания на нарушения ссылочной целостности. 6. NONE - обеспечение ссылочной целостности не требуется.
9. Зміст робіт на етапі визначення (аналізу) вимог до розроблюваного проекту корпоративної інформаційної системи
2. Аналіз системних і програмних вимог. Системний аналіз задає роль кожного елементу в комп'ютерній системі, взаємодію елементів один з одним. Аналіз вимог відноситься до програмного елементу - програмного забезпечення. Уточнюються і деталізуються його функції, характеристики і інтерфейс.
5. Процеси підприємства, що розробляє проект корпоративної інформаційної системи, згідно стандарту ISO/IEC 15288:2002 System Engineering - System Life Cycle Processes.
2. Процеси підприємства: - управління навколишнім середовищем; - інвестиційне управління; - управління життєвим циклом ІС; -управління ресурсами; -управління якістю.
57. Призначення діаграми діяльності (Activity Diagram). Нотація Activity Diagram.
Activity diagram - это специальная разновидность диаграммы состояний, которая была рассмотрена выше. В этом типе диаграмм большинство используемых представлений - это нотации активности, переходы между которыми вызваны завершением одних действий и началом других. Общее представление Activity diagram напоминает описание алгоритма программы. Главное отличие между Activity и Statechart diagram в том, что первая описывает действия, а вторая - статичные состояния. При этом Activity diagram используется для моделирования последовательности действий, a Statechart для моделирования дискретных состояний объекта. Для представления Activity diagram применяются нотации, указанные в табл.
21. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем управління взаємовідносинами з клієнтами (CRM, Customer Relationship Management).
CRM (Customer Relationship Management) - система керування взаєминами із клієнтами. Модель взаємодії, заснована на тому, що центром усієї філософії бізнесу є клієнт, а головними напрямками діяльності компанії - заходи щодо забезпечення ефективного маркетингу, продажів і обслуговування клієнтів. Підтримка бізнес-цілей включає збір, зберігання й аналіз інформації про споживачів, постачальників, партнерів, а також про внутрішні процеси компанії. Функції для підтримки бізнес-цілей включають продажі, маркетинг, підтримку споживачів. Рішення класу CRM являють собою додатки для автоматизації, оптимізації й підвищення ефективності бізнес-процесів, спрямованих на взаємодію із клієнтами за рахунок персоналізації взаємостосунків у сферах продажу, маркетингу й обслуговування. Це дозволяє компанії звертатися до клієнтів із цікавими пропозиціями в найбільш зручний момент часу, користуючись найбільш високою якістю зв'язку. На технологічному рівні CRM-система є набором додатків, зв'язаних єдиною бізнес-логікою й інтегрованих у корпоративне інформаційне середовище на основі єдиної бази даних, у якій щодня фіксуються: • усі контакти зі справжніми й потенційними клієнтами; • будь-яка нова інформація про покупців; • причини лояльності й джерела інформації покупців; • результати маркетингових впливів і кількість нових покупців; • заявлені претензії й рекламації; • замовлення й контроль їх виконання; • рахунки на оплату й контроль оплати; 18 • інформація про конкурентів; • незадоволений попит.Системи категорії CRM різняться по функціональності, і їх можна класифікувати за декількома ознаками. Найпоширеніший спосіб класифікації по цільовім використанню: оперативні й аналітичні (CRM-система може включати й оперативні, і аналітичні модулі). Оперативні CRM містять функції маркетингу, продажу й сервісу, тобто відповідають стадіям залучення клієнта, самого акту здійснення угоди й післяпродажного обслуговування. Системи цього класу здійснюють взаємодію підприємство — клієнт, забезпечуючи безпосередній доступ до інформації при роботі із клієнтом у ході продажів і обслуговування. Основним компонентом такої системи є додаток, який дозволяє співробітникам вносити накопичену інформацію з окремих клієнтів у базу даних і потім ефективно її використовувати. Аналітичні CRM починають використовувати в тих випадках, коли компанія має більшу базу даних про клієнтів. Такі системи дозволяють реалізувати спільний аналіз даних, що характеризують діяльність як клієнта, так і фірми, отримати нові знання, висновки й рекомендації. Для цього використовуються складні математичні моделі, тривимірна візуалізація, здійснюється пошук статистичних закономірностей для вироблення найбільш ефективної стратегії маркетингу, продажів і обслуговування клієнта.
16.Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем планування потреб у потужностях (CRP, Capacity Requirements Planning).
Capacity Requirements Planning, CRP - Планування потреби в потужностях. Mrp-Система націлена в першу чергу на вироблення оптимальних розв'язків про замовлення нових поставок. Однак при цьому не враховуються виробничі потужності, людські й фінансові ресурси. У концепції методології систем CRP методи MRP перенесені на управління виробничими потужностями. Основні етапи реалізації методології CRP в корпоративних інформаційних системах можна представити в наступному виді. 1. Розробляється план розподілу виробничих потужностей для обробки кожного конкретного циклу виробництва протягом планованого періоду. 2. Установлюється технологічний план послідовності виробничих процедур і відповідно до пробної програми виробництва визначається ступінь завантаження кожної виробничої одиниці на строк планування. 3. Якщо після циклу роботи CRP-Методології програма виробництва визнається реально здійсненної, то вона стає основною для MRP-Системи. 4. А якщо ні, то в неї вносяться зміни, і вона підпадає_під повторному тестуванню за допомогою CRP-Методології. MRP-системи фактично просто формували на основі затвердженої виробничої програми план замовлень на певний період. Це не могло задовольнити потреби виробництва, що ускладнюється.
15.Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем планування потреб у матеріалах у замкненому циклі виробництва (CL MRP, Closed Loop Material Requirements Planning).
Closed Loop MRP - методологія планування потреби в матеріалах у замкненому циклі. Ця методологія з'явилася як удосконалена версія MRP, що дозволила динамічно коректувати плани закупівель при виникненні непередбачених (позаштатних) відхилень від них
25. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем управління документами й/або електронним документообігом, (DMS/EDMS, Electronic Document Management Systems).
EDMS, DMS (Electronic Document Management Systems) - система автоматизації документообігу, система електронного документообігу (СЕДО) — автоматизована багатокористувацька система, що супроводжує процес управління роботою ієрархічної організації з метою забезпечення виконання її функцій. При цьому передбачається, що процес управління спирається на документи, що містять інструкції для співробітників організації, необхідні до виконання.
18. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем планування ресурсів підприємства (ERP, Enterprise Resource Planning).
ERP (Enterprise Resource Planning) - планування ресурсів підприємства. Стратегія ERP уважається розвитком MRP II. Організаційна стратегія: інтеграції виробництва й операцій, управління трудовими ресурсами, фінансового менеджменту й керування активами, орієнтована на безперервне балансування й оптимізацію ресурсів підприємства за допомогою спеціалізованого інтегрованого пакета прикладного програмного забезпечення, що забезпечує загальну модель даних і процесів для всіх сфер діяльності. 16 Задача ERP-системи - інтегрувати всі підрозділи й функції корпорації в єдиній інформаційній системі. Усі сторони виробничої й комерційної діяльності охоплюються ERP: виробництво, планування, управління договорами, матеріально-технічне постачання, фінанси, бухгалтерія, управління кадрами, збут, управління запасами. Таким чином, головна задача ERP -поширити принципи MRP II на управління сучасними корпораціями. Основа ERP - єдина база даних, якою користуються рівною мірою бухгалтерія, виробництво, служба маркетингу, відділ кадрів, склади. Уведена в цю базу даних інформація миттєво стає доступною всіляким підрозділам корпорації. Виникає інфраструктура електронного обміну даними як між підрозділами й підприємствами корпорації, так і між корпорацією і її постачальниками й споживачами. Відмінні риси ERP-систем: - в ERP на відміну від MRP II значно більша увага приділяється фінансовим підсистемам; - системи ERP із самого початку їх виникнення були орієнтовані на управління «віртуальним» підприємством, що й визначило широке використання інфраструктури Internet/ Intranet; - для ERP-систем характерна висока масштабованість (для транснаціональних корпорацій - до декількох тисяч користувачів); - ERP-система не може вирішувати абсолютно всі задачі управління підприємством, однак вимога забезпечення інтеграції з іншими системами (системи проектування, системи керування технологічними процесами) виконується неухильно; - ERP-системи універсальні з погляду типів виробництв.
20. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем управління складом профільного підприємства (WMS, Warehouse Management System).
MES (Manufacturing execution system) - система керування виробничими процесами. Спеціалізоване прикладне програмне забезпечення, призначене для розв'язку задач синхронізації, координації, аналізу й оптимізації випуску продукції в рамках якого-небудь виробництва. MES-системи ставляться до класу систем управління рівня цеху, але можуть використовуватися й для інтегрованого управління виробництвом на підприємстві в цілому.
17.Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем планування виробничих ресурсів (MRP II, Manufacturing Resource Planning).
MRP II (Manufacturing resource planning) - планування виробничих ресурсів. 15 MRP II - це система виробничого планування, що забезпечує як операційне, так і фінансове планування виробництва, що забезпечує більш широкий облік ресурсів підприємства, ніж MRP. Подальший розвиток інформаційних систем привів до об'єднання принципів MRP, Closed Loop MRP, CRP у рамках єдиної концепції, що призвело до створення методології MRP II, що дозволяє управляти всім виробничим процесом, а не тільки окремими його частинами. До базових функцій планування виробничих потужностей і планування потреб у матеріалах були додані ряд додаткових, таких, як контроль відповідності кількості зробленої продукції кількості використаних у процесі складання комплектуючих, складання регулярних звітів про затримки замовлень, про об'єми й динаміку продажів продукції. Для MRP II характерні зворотні зв'язки, оскільки створені в процесі її роботи звіти враховуються на подальших етапах планування. Якщо буде потреба може бути змінена програма виробництва. Ці додаткові функції забезпечують гнучкість планування стосовно зовнішніх факторів - рівню попиту, надійності поставок матеріалів і комплектуючих. Система MRP II здатна адаптуватися до зовнішньої ситуації. Результати роботи кожного модуля аналізуються всією системою в цілому, що, власне, і забезпечує її гнучкість стосовно зміни зовнішніх факторів. Це особливо важливо для підприємств, що виробляють продукцію з коротким життєвим циклом, що вимагає частих доробок. Кращі зразки систем MRP ІІ - це автоматизовані програмні комплекси, що дозволяють оптимізувати об'єми випуску й споживчі характеристики продукції, що випускається, на основі аналізу ситуації на ринку. Системи MRP II орієнтовані на виробництво, причому в більшості випадків саме на промислове виробництво.
29. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем інтерактивної аналітичної обробки даних (OLAP, On-Line Analytical Processing).
OLАP (On-Line Analytical Processing) - системи забезпечують вибірку інформації з OLTP-систем, яке в подальшому може використовуватись для вироблення управлінських рішень. Суть роботи OLAP-системи полягає в наданні користувачеві багатомірної таблиці, що автоматично підсумує дані в різних розрізах, що й дозволяє інтерактивно управляти обчисленнями й формою звіту. В основі OLAP лежить наочна модель даних, що розроблюється користувачем у вигляді багатомірних кубів (гіперкубів). Осями багатомірної системи координат служать атрибути аналізованого бізнес-процесу (виміру).
46. Призначення й характеристика програмного CASE-засобу візуального моделювання Rational Rose.
Rational Rose - это CASE-средство фирмы Rational Software Corporation (США), предназначенное для автоматизации этапов анализа и проектирования программного обеспечения, для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. В качестве визуального инструмента моделирования используется нотация UML (Unified Modeling Language). Rational Rose поддерживает различные языки объектно-ориентированного программирования, на котором генерируются коды программ (Visual Basic, Visual C, Smalltalk, PowerBuilder, Ada, SQLWindows, ObjectPro). Rational Rose позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на выбранном языке. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах. В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов. В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий (словарь данных); графический редактор диаграмм (интерфейс) в нотации UML; средства просмотра проекта (browser); средства контроля проекта; средства сбора статистики; генератор документов; генератор кодов (индивидуальный для каждого языка).
43. Характеристика (мета, задачі, аспекти) методології розробки програмного забезпечення RUP (Rational Unified Process).
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software. RUP обеспечивает строгий подход к распределению задач и ответственности внутри организации-разработчика. Его предназначение - гарантировать создание точно в срок и в рамках установленного бюджета качественного ПО, отвечающего нуждам конечных пользователей. В качестве языка моделирования в методологии RUP используется язык UML. RUP опирается на разработку и развитие семантически обогащенных моделей, всесторонне представляющих разрабатываемую систему. RUP организует работу над проектом в терминах последовательности действий (workflows), продуктов деятельности, исполнителей и других статических аспектов процесса с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО (milestones), т.е. в терминах динамических аспектов процесса, с другой.
19. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем управління ланцюгами поставок (SCM, Supply Chain Management)
SCM (Supply chain management) - керування ланцюгами поставок. SCM - це стратегія, що полягає в інтегрованому підході до планування й управлінню всім потоком інформації про сировину, матеріали, продукти, послугах, що виникають, що й перетворяться в логістичних і виробничих процесах підприємства, націленому на вимірний сукупний економічний ефект (зниження витрат, задоволення попиту на кінцеву продукцію).
23. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем управління взаємовідносинами з постачальниками (SRM, Supplier Relationship Management)
Supplier Relationship Management (SRM) — система керування взаєминами з постачальниками Рішення даного класу націлені на задачі стратегічного вибору постачальників, вибір нових видів розроблювальної продукції з можливих альтернатив, реалізацію всього циклу закупівель, включаючи електронний торговельний майданчик, а також оперативний моніторинг і оцінку діяльності постачальників. Характерні проблеми підприємств при відсутності систем по управлінню взаємостосунками з постачальниками: - відсутність аналізу витрат при виборі конкурентних постачальників - відсутність взаємозв'язків між бізнес-процесами кінцевих споживачів і процесами закупівлі централізованого відділу закупівель - низька ефективність і величезні витрати часу, пов'язані із процесом аналізу розцінок по телефону або пошті - наявність великої кількості не інтегрованих один з одним рішень для автоматизації вибору постачальників, кожне з яких вимагає своєї ліцензії, додаткових витрат часу для синхронізації даних, спричиняє конфліктні ситуації при взаємодії один з одним. Вигоди від впровадження систем по управлінню взаєминами з постачальниками: - зниження вартості закуповуваного сировини й матеріалів за рахунок конкурсів і зворотних аукціонів - скорочення витрат часу на закупівельні процедури й збільшення прибутку за рахунок скорочення разових закупівель, зниження закупівельних цін, одержання додаткових бонусів 20 - збільшення прозорості процесу вибору постачальників і витрат на закупівлю за рахунок повного документування всього закупівельного процесу - виключення випадків роботи з єдиним постачальником за завищеними цінами; - оперативне виявлення акційних пропозицій і істотних знижок -впровадження інтуїтивне-зрозумілих on-line сервісів самореєстрації постачальників, які дозволяють передоручити управління інформацією про постачальників самим постачальникам, знизивши рутинне навантаження відділу постачання - вибудовування пріоритетних відносин у роботі зі стратегічно важливими постачальниками, що забезпечують найкращі умови і якість.
24. Порівняльна характеристика реалізованих бізнес-процесів CRM- і SRMсистем (CRM, Customer Relationship Management; SRM, Supplier Relationship Management).
Бізнес-Процес Crm-Компонента Srm-Компонента Маркетинг маркетинг збуту маркетинг закупівлі Аналіз і класифікація аналіз і класифікація клієнтів аналіз і класифікація постачальників Планування планування збутової діяльності планування закупівельної діяльності Управління переговорами планування й проведення переговорів із клієнтами планування й проведення переговорів з постачальниками Управління контактами управління контактами із клієнтами управління контактами з постачальниками Управління договорами висновок і моніторинг виконання договорів із клієнтами висновок і моніторинг виконання договорів з постачальниками Управління замовленнями ведення замовлень на поставку продукції ведення замовлень на закупівлю продукції Фінансові розрахунки фінансові розрахунки із клієнтами фінансові розрахунки з постачальниками Ведення бази даних ведення бази даних клієнтів ведення бази даних постачальників Управління інформацією управління інформацією про клієнтів і контакти управління інформацією про постачальників Управління якістю управління якістю продажів управління якістю закупівель
47. Модель розроблювальної системи у вигляді UML-діаграм Rational Rose.
В результате разработки проекта с помощью CASE-средства Rational Rose создается интегрированная модель системы в нотации UML, которая включает в себя: диаграммы классов; диаграммы состояний; диаграммы деятельности; диаграммы развертывания; диаграммы последовательности; диаграммы вариантов использования, диаграммы кооперации, диаграммы компонентов.
12.Зміст робіт на етапах верифікації й валідації розробленої корпоративної інформаційної системи.
Верифікація - це процес визначення того, чи відповідає поточний стан розробки, досягнутий на цьому етапі, вимогам цього етапу. Перевірка дозволяє оцінити відповідність параметрів розробки з початковими вимогами. На кожному етапі слід переконуватися, що зробили саме те, що планували, і це відповідає загальній логіці розробці - «Ми створюємо систему правильно». Валідація (перевірка правильності) - процес перевірки того, що реализованая система задовольняє пред'явленим вимогам і працює так, як передбачалося - «Ми створюємо (створили) правильну систему».
28. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем, орієнтованих на оперативну (транзакційну) обробку даних (OLTP, On-Line Transaction Processing).
Виділяють три основні технології підтримки прийняття управлінських рішень на основі накопиченої інформації: - технології, орієнтовані на оперативну (транзакційну) обробку даних і реалізовані в більшості транзакційних систем (OLTP). Сфера дії таких технологій - галузь деталізованих даних. Класичні реляційні СУБД нормально справляються з подібними задачами, тому в докладному їхньому розгляді немає необхідності; - технології OLAP (On-Line Analytical Processing - інтерактивна аналітична обробка даних), орієнтовані на область агрегованих показників; - технології інтелектуальної обробки даних, орієнтовані на область закономірностей. Інтелектуальна обробка проводиться методами інтелектуального аналізу даних (Data Mining). За допомогою цих технологій 23 вирішуються задачі пошуку функціональних і логічних закономірностей у накопиченій інформації, пояснення аномалій у даних. В області створення інформаційних систем завжди існувало два взаємодоповнюючі один одного напрямку розвитку: - системи, орієнтовані на оперативну транзакційну або операційну обробку даних; - системи, орієнтовані на аналіз даних (системи підтримки прийняття рішень). Основна задача OLТP-системи (On-Line Transaction Processing) - забезпечити реєстрацію деяких фактів, їх нетривале зберігання з наступним розміщенням в архівах. Інформаційну основу таких систем забезпечують реляційні бази даних. Саме для цього класу систем орієнтовані реляційні СУБД, які стали основним засобом побудови інформаційних систем великого масштабу й призначення. Але, будучи високоефективним засобом реалізації систем оперативної обробки даних, реляційні СУБД виявилися менш ефективними в задачах аналітичної обробки.
4. Визначення стадій життєвого циклу розроблювальної корпоративної інформаційної системи згідно стандарту ISO/IEC 15288:2002 System Engineering - System Life Cycle Processes
Головні етапи робіт (стадії) відповідно до ГОСТ 34.601 і додаткових пояснень, виглядають так: 1. Формування вимог до інформаційної системи Має за мету виконання таких дій: - обстеження об'єкту та обґрунтування необхідності створення ІС; - формування вимог користувача до ІС; - оформлення звіту щодо виконаної роботи й заявки на розроблення ІС. 2. Розроблення концепції ІС. Ця стадія складається з таких етапів: - вивчення об'єкта; - проведення науково-дослідних робіт (за необхідністю); - розроблення варіантів концепції ІС відповідно до вимог користувачів; - оформлення звіту щодо виконаної роботи. 3. Технічне завдання. Підготовчим етапом для формування технічного завдання є техніко-економічне обґрунтування проекту. Це спеціальний документ, що фіксує результати визначення стратегії впровадження ІС. У цьому документі має бути чітко визначено результати виконання проекту для замовника, а також вказані графіки проведення робіт і графік фінансування на 37 різних стадіях виконання проекту. Додатково у такому документі вказують терміни, період окупності, очікувані зиски та економічний ефект від реалізації проекту. Зазвичай, у техніко-економічному обґрунтуванні вказують: - усі ризики та обмеження, що впливають на успішність проекту; - умови експлуатації майбутньої системи: архітектурні, програмні, вимоги до апаратних засобів та до компонентів ПО і СУБД; - користувачів системи (можливо, за категоріями); - функції, що виконуються системою; - інтерфейси та розподіл функцій між людиною та системою; - терміни завершення етапів, форма прийому/передачі робіт; - горизонт проекту; - можливості подальшого розвитку системи. За результатами обстежень формується технічне завдання на інформаційну систему
50. Призначення діаграми класів (Class Diagram). Нотація піктограм (позначок) видимості атрибутів класів.
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Эта диаграмма показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования - чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет иерархию объектов системы и различные статистические связи, которые существует между ними.
51. Призначення діаграми класів (Class Diagram). Нотація відносин асоціації (ненаправлена й спрямована бінарна асоціація) між класами
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Эта диаграмма показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования - чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет иерархию объектов системы и различные статистические связи, которые существует между ними. 5.4 Ненаправленная бинарная ассоциация Изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения классов с использованием значка в форме треугольника рядом с именем данной ассоциации. Направленная бинарная ассоциация изображается сплошной линией с простой стрелкой на одном из ее концевых точек. Направление этой стрелки указывает на то, какой из классов является первым, а какой — вторым (на него указывает стрелка ассоциации). Значения кратности из интервала следуют в монотонно возрастающем порядке без пропуска отдельных чисел, лежащих между нижней и верхней границами. При этом придерживаются следующего правила: соответствующие нижние и верхние границы интервалов включаются в значение кратности. Если в качестве кратности указывается единственное число, то кратность атрибута принимается равной данному числу. Если же указывается единственный знак "*", то это означает, что кратность атрибута может быть произвольным положительным целым числом или нулем.
52. Призначення діаграми класів (Class Diagram). Нотація відносин узагальнення (generalization relationship) між класами.
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Эта диаграмма показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования - чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет иерархию объектов системы и различные статистические связи, которые существует между ними. Данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. Класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые могут отсутствовать у класса-предка. На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов. Стрелка указывает на более общий класс (класс-предок или суперкласс), а ее противоположный конец — на более специальный класс (класс-потомок или подкласс).
53. Призначення діаграми класів (Class Diagram). Нотація відносин агрегації (Aggregation Relationship) між класами.
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Эта диаграмма показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования - чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет иерархию объектов системы и различные статистические связи, которые существует между ними. Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Данное отношение используется для описания структуры сложных систем, поскольку применяется для представления системных взаимосвязей типа "часть-целое". Раскрывая внутреннюю структуру системы отношение агрегации показывает, из каких элементов состоит система и как они связаны между собой. С точки зрения модели отдельные части системы могут выступать как в виде элементов, так и в виде подсистем, которые, в свою очередь, тоже могут состоять из подсистем или элементов. Таким образом, данное отношение по своей сути описывает декомпозицию или разбиение сложной системы на более простые составные части, которые также могут быть подвергнуты декомпозиции, если в этом возникнет необходимость в последующем.
55. Призначення діаграми класів (Class Diagram). Нотація відносин залежності (dependency relationship) між класами.
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Эта диаграмма показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования - чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет иерархию объектов системы и различные статистические связи, которые существует между ними. Отношение зависимости графически изображается пунктирной линией со стрелкой на одном из ее концов. На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости или зависимого класса к классу-источнику или независимому классу. Отношение зависимости в общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации. Оно касается только самих элементов модели и не требует множества отдельных примеров для пояснения своего смысла. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.
54. Призначення діаграми класів (Class Diagram). Нотація відносин композиції (composition relationship) між класами.
Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Эта диаграмма показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования - чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет иерархию объектов системы и различные статистические связи, которые существует между ними. Отношение композиции является частным случаем отношения агрегации. Это отношение служит для спецификации более сильной формы отношения "часть-целое", при которой составляющие части тесно взаимосвязаны с целым. Специфика этой взаимосвязи заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части. Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композит. Остальные классы являются его "частями".
58. Призначення діаграми послідовності дій (Sequence Diagram). Нотація Sequence Diagram.
Диаграммы последовательности определяют временную последовательность передаваемых сообщений, порядок, вид и тип сообщения, происходящих в рамках варианта использования. На диаграмме последовательности взаимодействие изображается в виде двумерной схемы: вертикальное (время) и горизонтальное (объекты, участвующие во взаимодействии). Существенна только последовательность сообщений, однако временная ось может служить реальной метрикой измерения активности объекта. На диаграмме Sequence отображаются: -действующие лица из варианта использования; -объекты, требуемые системе для выполнения варианта использования; -линии жизни, представляющие фрагмент жизненного цикла объекта в процессе взаимодействия, где течение времени идет сверху вниз, идут сверху; -активный период линии жизни; -сообщение, передающееся от одного объекта к другому в порядке следования жизненного цикла; -самоделегирование (рекурсивное сообщение) - сообщение самому себе.
56. Призначення діаграми станів (Statechart Diagram). Нотація Statechart Diagram.
Диаграммы состояния (Statechart) являются средством описания поведения (статических состояний) систем. Они определяют все известные состояния, в которых может находиться объект, а также процесс смены состояния объекта в результате влияния некоторых событий. Существуют два специальных состояния - начальное (start) и конечное (stop). Начальное состояние - состояние объекта, когда он только что создан, конечное - перед его уничтожением. Начальное состояние может быть только одно, а конечных - сколько необходимо. Процесс начинается с начальной точки (start), а затем переходит в состояние. В поведении объекта в системе можно выделить действия, отображаемые переходами, и деятельности, отображаемые состояниями. Действия связаны с переходами и рассматриваются как мгновенные и непрерываемые. Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события. Событие - это то, что вызывает переход из одного состояния в другое. Для представления Statechart diagram применяются нотации, указанные в табл.
3. Класифікація корпоративних інформаційних систем.
За ступенем автоматизації: а) системи початкового рівня: - лімітовані функціональні можливості; - для невеликої кількості користувачів; б) системи середнього рівня (існує можливість роботи за кількома напрямками: бухгалтерський облік, логістика, управління персоналом тощо); в) системи вищого рівня (повнофункціональні системи, наявність засобів підтримки корпоративного управління). За сферою використання: - екологічні; - медичні; - нафтовидобувна галузь; - енергетика тощо. За рівнями управління: а) оперативний рівень (система обробки транзакційних даних); б) тактичний рівень (інформаційна система управління); в) стратегічний рівень (система підтримки прийняття рішень).
2. Визначення терміну «корпоративна інформаційна система». Класифікація корпоративних інформаційних систем за рівнями управління.
Корпоративна інформаційна система (КІС) - це система управління бізнес-процесами підприємства, яка підтримує функціонування підрозділів, забезпечуючи розподілену обробку інформаційних потоків протягом усієї технологічної ланки процедур управління.За рівнями управління: а) оперативний рівень (система обробки транзакційних даних); б) тактичний рівень (інформаційна система управління); в) стратегічний рівень (система підтримки прийняття рішень).
1. Визначення терміну «корпоративна інформаційна система». Класифікація корпоративних інформаційних систем за ступенем автоматизації.
Корпоративна інформаційна система (КІС) - це система управління бізнес-процесами підприємства, яка підтримує функціонування підрозділів, забезпечуючи розподілену обробку інформаційних потоків протягом усієї технологічної ланки процедур управління.За ступенем автоматизації: а) системи початкового рівня: - лімітовані функціональні можливості; - для невеликої кількості користувачів; б) системи середнього рівня (існує можливість роботи за кількома напрямками: бухгалтерський облік, логістика, управління персоналом тощо); в) системи вищого рівня (повнофункціональні системи, наявність засобів підтримки корпоративного управління).
35. Нотація стандарту IDEF1X (Integration Definition for Information Modeling eXtended) для ER-діаграм логічної моделі бази даних.
Логічною моделлю називається універсальне уявлення структури даних, незалежне від кінцевої реалізації бази даних і апаратної платформи. На підставі отриманої логічної моделі переходять до фізичної моделі даних
45. Характеристика дисциплін методології розробки програмного забезпечення RUP (Rational Unified Process).
Моделирование предметной области (бизнес-моделирование, Business Modeling). Задачи этой дисциплины (деятельности) - понять предметную область или бизнес-контекст, в которых должна будет работать система и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы). Эта модель служит основой модели анализа. Определение требований (Requirements). Задачи этой дисциплины - понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нем. Требования принято фиксировать в виде модели вариантов использования. Анализ и проектирование (Analysis and Design). Задачи этой дисциплины - выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов, и диаграммы развертывания. Реализация (Implementation). Задачи этой дисциплины - определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое. Тестирование (Test). Задачи этой дисциплины - найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить выполнены или нет гипотезы, лежащих в основе проектирования, оценить степень соответствия системы требованиям. Развертывание (Deployment). Задачи этой дисциплины - установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать. Управление конфигурациями и изменениями (Configuration and Change Management). Задачи — определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. Управление проектом (Project Management). Задачи — планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. Управление средой проекта (Environment). Задачи — подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте. Таким образом, положительными аспектами унифицированного процесса являются: • итеративная разработка ПО КИС; • допустимость внесения изменений в ПО; • адаптивность; • оценка рисков; • построение базовой архитектуры ПО КИС на ранних итерациях; • разработка базируется на требованиях пользователей, заданных прецедентами; • постоянная обратная связь и учет пожеланий пользователей; • ориентация на объектно-ориентированные технологии программирования.
59. Призначення діаграми співробітництва (Collaboration Diagram). Нотація Collaboration Diagrams.
На диаграмме сотрудничества экземпляры объектов представляются в виде пиктограмм. Линии между ними обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Также, в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта, и типы этих сообщений. Данная диаграмма строится ПП Rational Rose автоматически, если уже построена диаграмма последовательности.
33. Нотація стандарту IDEF0 (Integration Definition for Function Modeling).
Нотація IDEF0 включає наступні елементи. Елемент «Activity» - функціональний блок, що зображується на діаграмах прямокутником. Призначення функціонального блоку - дати визначення функції, що виконує система або її частина, тому найменуваннями блоків (функцій) служать дієслова або дієслівні звороти (рис. 7.1). Елемент Arrow (рис. 7.2) - дуга (зв'язок), що описує взаємодію функцій (блоків) із зовнішнім миром і між собою. Елементи Arrow представляються на діаграмах у вигляді ліній зі стрілками. Оскільки дуги позначають об'єкти даних, то вони описуються (позначаються) іменниками або іменниками з визначеннями. В нотації IDEF0 (рис. 7.2) розрізняють наступні типи дуг; - дуга, що визначає «Вхід» (Input) - матеріал або інформація, які використовуються або перетворяться блоком для одержання результату (виходу). Блок може не мати вхідної дуги. Даний вид дуги надходить на ліву сторону блоку. - дуга, що визначає «Управління» (Сontrol) - умови, правила, стратегії, стандарти, які впливають на виконання функції. Кожний блок повинен мати 56 хоча б одну дугу управління. Даний вид дуг надходить на верхню сторону блоку. - дуга, що визначає «Вихід» (Output) - результат виконання функції (матеріал або інформація). Кожна функція повинна мати хоча б одну вихідну дугу. Даний вид дуг виходить із правої сторони блоку. - дуга, що визначає «Механізм» (Mechanism) - ресурси, за допомогою яких виконується робота (персонал підприємства, програмне забезпечення, обладнання). Даний вид дуг з'єднується з нижньою стороною блоку.
27. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем електронної комерції типу В2В (Business-To-Business).
Основні обороти електронної комерції припадають на системи типу «Business-to-Business» (В2В), які є не просто засобом укладання угод між фірмами, а реалізують технологію підтримки межкорпоративных відносин. Їхнє основне завдання полягає в підвищенні ефективності роботи компаній за рахунок зниження витрат на підготовку торговельних процедур і розширення географії бізнесу до масштабу всього миру. Система електронної комерції В2В — це апаратно-програмний комплекс, що дозволяє підтримувати бізнес-відносини між підприємствами. Умовно ці комплекси діляться на наступні типи: - корпоративний сайт компанії призначений для спілкування даної фірми з партнерами й контрагентами — постачальниками й споживачами, що діють і потенційними інвесторами. Сайт, як правило, містить інформацію про компанію, її персонал, керівництво, а також каталоги продукції й опис послуг; - інтернет- магазин призначений для збуту продукції, може бути вбудований у корпоративний сайт. Він дозволяє розміщати замовлення, проводити електронні платежі, забезпечувати доставку; - служба закупівель шукає постачальників, одержує комерційні пропозиції, здійснює електронні платежі, контролює виконання замовлень; - інформаційні сайти й вертикальні портали призначені для розміщення інформації про галузь вхідних у неї компаній, параметрів стану ринку, галузевих стандартів; - брокерські сайти відіграють роль посередників між покупцем і продавцем. Їхня задача — одержати через інтернет-сайт замовлення від одного підприємства, а потім помістити його виконання на іншому;
31. Загальний підхід до поняття «методології проектування», що використовується в CASE-засобах розробки.
Практично жоден проект зі створення КІС не здійснюється без використання САSЕ-засобів. САSЕ (Computer Aided Software / System Engineering) являє собою сукупність методологій аналізу, проектування, розробки і супроводження складних програмних систем, підтриману комплексом взаємопов'язаних засобів автоматизації. САSЕ — це інструментарій для системних аналітиків, розробників і програмістів, що замінює їм папір і олівець комп'ютером для автоматизації процесу проектування і розробки програмного забезпечення. Основна мета САSЕ полягає в тому, щоб відокремити початкові етапи (аналіз і проектування) від подальших етапів розробки, а також не обтяжувати розробників усіма деталями середовища розробки і функціонування системи. Чим більший обсяг робіт буде винесений на етапи аналізу й проектування, тим краще. Під час використання САSЕ трансформуються всі етапи життєвого циклу КІС, при цьому найбільші зміни стосуються етапів аналізу і проектування. Крім автоматизації методологій і, як наслідок, можливості застосування сучасних методів системної і програмної інженерії САSЕ мають такі основні переваги: 1) поліпшують якість системи, що створюється, за допо- могою засобів автоматичного контролю (передусім контролю проекту); 2) дозволяють за короткий час створювати прототип майбутньої системи, що дає змогу на ранніх етапах оцінити очікуваний результат; 3) прискорюють процес проектування і розробки; 4) звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки; 5) підтримують розвиток і супровід розробки; 51 6) підтримують технології повторного використання компонентів розробки.
6. Процеси розроблюваного проекту корпоративної інформаційної системи згідно стандарту ISO/IEC 15288:2002 System engineering - System Life Cycle Processes.
Проектні процеси: - планування проекту; - оцінка проекту; - контроль проекту; - управління ризиками; - управління конфігурацією; - управління інформаційними потоками; -прийняття рішень.
10. Зміст робіт на етапі проектування архітектури розроблюваного проекту корпоративної інформаційної системи
Проектування алгоритмів, структур цих і програмних структур. Проектування полягає в створенні представлень: - архітектури ПЗ і модульної структури ПЗ; - алгоритмічної структури ПЗ і структури даних; - вхідного і вихідного інтерфейсу (вхідних/вихідних форм даних).
11. Зміст робіт на етапі розробки й реалізації елементів корпоративної інформаційної системи.
Реалізація (кодування) полягає в перекладі результатів проектування в текст на мові програмування. 5. Тестування відповідає за виконання програми для виявлення дефектів у функціях, логіці і формі реалізації програмного продукту. 6. Введення в дію (супровід) - це внесення змін до експлуатованої КІС. Цілі змін: - виправлення помилок; - адаптація до змін зовнішньої для ІС середовища; - удосконалення ІС за вимогами замовника.
14.Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем планування потреб у матеріалах (MRP, Material Requirements Planning).
Система MRP (Material Requirements Planning) - система планування потреб у матеріалах (без фінансів). В основі MRP-Системи лежить об'єкт матеріального обліку (item). Це можуть бути сировина, матеріали, складальні одиниці, напівфабрикати - будьякі компоненти, з яких можна зібрати кінцевий продукт. MRP-програма постійно відслідковує стан кожного матеріалу. Як правило, опис статусу матеріалу - це такі параметри, як наявність матеріалу на складі, його ціна, дані про постачальників, а також інформація про регулярність поставок матеріалів. Друге базисне поняття MRP-системи - відомість матеріалів, або специфікація (bills of materials). Таким чином, MRP-програма, одержуючи на вході дані про наявність матеріалів на складі, їх властивостях і «знаючи», що саме потрібно для виробництва кінцевого продукту, а також маючи можливість співвіднести виробничий цикл із тимчасовою шкалою, здатна надати в руки менеджера інформацію, яка дозволить оптимально (щодо строків закупівлі й виробництва) спланувати процес виробництва (мал. 1.3). 14 MRP-програма, з одного боку, відслідковує рух матеріалів для того, щоб оптимізувати процес прийняття рішень про замовлення нових поставок, автоматизує цей процес, автоматично генеруючи замовлення.
26. Призначення, характеристика, склад функціональних компонентів корпоративних інформаційних систем електронної комерції типу В2С (Business-To- Consumer).
Системи електронної комерції типу В2С (Business-to-Consumer) забезпечують комерційні взаємини між організацією (Business), звичайно в особі інтернет-магазину, і часткам, так званим кінцевим споживачем (Consumer).
22. Класифікація корпоративних інформаційних систем управління взаємовідносинами з клієнтами (CRM, Customer Relationship Management).
Системи категорії CRM різняться по функціональності, і їх можна класифікувати за декількома ознаками. Найпоширеніший спосіб класифікації по цільовім використанню: оперативні й аналітичні (CRM-система може включати й оперативні, і аналітичні модулі). Оперативні CRM містять функції маркетингу, продажу й сервісу, тобто відповідають стадіям залучення клієнта, самого акту здійснення угоди й післяпродажного обслуговування. Системи цього класу здійснюють взаємодію підприємство — клієнт, забезпечуючи безпосередній доступ до інформації при роботі із клієнтом у ході продажів і обслуговування. Основним компонентом такої системи є додаток, який дозволяє співробітникам вносити накопичену інформацію з окремих клієнтів у базу даних і потім ефективно її використовувати. Аналітичні CRM починають використовувати в тих випадках, коли компанія має більшу базу даних про клієнтів. Такі системи дозволяють реалізувати спільний аналіз даних, що характеризують діяльність як клієнта, так і фірми, отримати нові знання, висновки й рекомендації. Для цього використовуються складні математичні моделі, тривимірна візуалізація, здійснюється пошук статистичних закономірностей для вироблення найбільш ефективної стратегії маркетингу, продажів і обслуговування клієнта. Існує ще одна класифікація CRM-систем, заснована на розмірі підприємства, яка містить три групи. 1. Системи для офісної роботи із клієнтами й організації документообігу. 2. Системи для дистанційної роботи із клієнтами й приймання замовлень на послуги й товари через Internet. 3. CALL-центри, що дозволяють автоматизувати й зберігати інформацію про телефонні переговори із клієнтами. Перший тип систем розроблений для невеликих фірм, щоб нормалізувати роботу із клієнтами, підвищити її продуктивність. У них звичайно використовуються стандартні розв'язки, що мають невеликий діапазон настроювань, які можуть регулюватися самим користувачем. Системи для дистанційної роботи іноді називають інтернет-замовленням, вони орієнтовані на середні й великі організації й розраховані на замовлення товарів постійними клієнтами безпосередньо через Інтернет. У цьому випадку попередньо відбуваються необхідні перевірки рівня доступу до бази даних, під час діалогу із клієнтом автоматично перевіряється наявність товару, 19 доступність його даному клієнтові, призначаються відповідні знижки. Клієнт може також переглянути історію своїх попередніх замовлень, відомості про запитаних їм раніше товарах і т.д. CALL-центри призначені для середніх і великих підприємств. Вони забезпечують в автоматичному й напівавтоматичному режимах збір відомостей про телефонні контакти. Системи для дистанційної роботи мають свою базу знань, що дозволяє давати відповіді на типові питання. Вона може бути настроєна на автоматичну генерацію відповідей. Забезпечується прослуховування всієї історії переговорів із клієнтом, документальне обґрунтування тих або інших дій.
32. Призначення й характеристика стандарту IDEF0 (Integration Definition for Function Modeling).
Стандарт IDEF0 використовується для створення функціональних моделей, що відображають структуроване зображення функцій виробничої системи або середовища, а також інформації і об'єктів, що зв'язують ці функції. З погляду розроблювача IDEF0 - це методологія функціонального моделювання, що дозволяє описати бізнес-процеси системи у вигляді ієрархічної системи взаємозалежних функцій. Функціональна модель системи, що створюється за допомогою стандарту IDEF0, може бути використана: - для визначення функціональних вимог до розроблювальної системи; - для аналізу функцій існуючої системи та визначення вимог до її доробки
34. Призначення й характеристика стандарту IDEF1X (Integration Definition for Information Modeling extended).
Стандарт IDEF1X определяет методологию разработки реляционных баз данных и использует условный синтаксис, специально разработанный для построения концептуальной схемы структуры данных, независимой от конечной реализации базы данных и аппаратной платформы. Хотя терминология IDEF1X практически совпадает с терминологией IDEF1, существует ряд фундаментальных отличий в теоретических концепциях этих методологий. Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира.
8. Зв'язки між системою й програмними засобами, що входять до її складу, згідно зі стандартом ISO/IEC 15288:2002 System engineering - System life cycle processes.
Стандарт встановлює строгий зв'язок між системою й застосовуваними в ній програмними засобами. Програмний засіб трактується як єдина частина загальної системи, що виконує певні функції в даній системі, що здійснюється за допомогою виділення вимог до програмних засобів з вимог до системи, проектування, виробництва програмних засобів і об'єднання їх у систему. Цей принцип є фундаментальною передумовою для стандарту, у якому програмні засоби завжди існують у контексті системи, навіть якщо система складається з єдиного процесора, що виконує програми. У такому випадку програмний продукт або послуга завжди розглядаються як одна зі складових частин системи. Наприклад, у стандарті проводиться відмінність між аналізом системних вимог і аналізом вимог до програмних засобів, тому що в загальному випадку побудова системної архітектури визначає системні вимоги для різних складових частин системи, а аналіз вимог до програмних засобів визначає вимоги до них, виходячи із системних вимог, призначених кожної програмної складовій частини.
40. Призначення й характеристика стандарту DFD (Data Flow Diagram).
Стандарт методології моделювання потоків даних DFD включає: - нотацію моделювання (умовні позначки), що складається з елементів, за допомогою яких будується модель потоків даних; - метод моделювання (спосіб аналізу), що включає опис порядку та правил використання елементів нотації DFD. Діаграми потоків даних системи, що створюється за допомогою стандарту DFD, може бути використані: - для аналізу функцій існуючої системи та визначення вимог до її доробки, у тому числі структури даних (бази даних); - для визначення функціональних вимог до розроблювальної системи; - для визначення вимог до структури даних (бази даних), видів та типів даних, що потрібні для виконання функцій системою, що розробляється.
13.Визначення технічних процесів розробки корпоративної інформаційної системи згідно зі стандартом ISO/IEC 15288:2002 System Engineering - System Life Cycle Processes.
Технічні процеси: - визначення вимог; - аналіз вимог; - розробка архітектури; - впровадження; - інтеграція; - верифікація; - перехід; - атестація; -експлуатація; -супроводження; -утилізація.
7. Технічні процеси розроблюваного проекту корпоративної інформаційної системи (етапи розробки) згідно стандарту ISO/IEC 15288:2002 System Engineering - System Life Cycle Processes.
Технічні процеси: - визначення вимог; - аналіз вимог; - розробка архітектури; - впровадження; - інтеграція; - верифікація; - перехід; - атестація; -експлуатація; -супроводження; -утилізація.
42. Призначення й загальна характеристика мови UML (Unified Modeling Language).
Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования объектно-ориентированных программных систем. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
44. Життєвий цикл програмного забезпечення згідно з методологією RUP (Rational Unified Process).
Фазы получили следующие названия: начало, развитие, конструирование и передача. 1. Начало (inception). На этой стадии осуществляется первичная оценка проекта. Обычно именно здесь вы решаете, стоит ли вкладывать средства в фазу уточнения. 2. Уточнение (elaboration). На этой стадии идентифицируются основные прецеденты проекта и в итеративном процессе создается программное обеспечение, для того чтобы развернуть архитектуру системы. В конце фазы уточнения у вас должно быть достаточно полное понимание требований и скелет работающей системы, которую можно взять за основу разработки. В частности, необходимо обнаружить и разрешить основные риски проекта. 3. Построение (construction). На стадии построения продолжается процесс создания и разрабатывается функциональность, достаточная для выпуска продукта. 4. Внедрение или передача (transition) состоит из различных стадий работы, выполняемых в конце и в неитеративном режиме. Они могут включать развертывание в информационном центре, обучение пользователей и тому подобное.
36. Нотація стандарту IDEF1X (Integration Definition for Information Modeling eXtended) для ER-діаграм фізичної моделі бази даних.
Фізична модель являє собою діаграму, що містить всю необхідну інформацію для генерації БД для конкретної СУБД або навіть конкретної версії СУБД. Якщо в логічній моделі не має значення, які ідентифікатори носять таблиці і атрибути, тип даних атрибутів, то у фізичній моделі повинно бути повний опис БД відповідно до прийнятого в ній синтаксисом, з зазначенням типів атрибутів, тригерів, збережених процедур і т. д. За однією і тією ж логічної моделі можна створити кілька фізичних.
48. Призначення діаграми варіантів використання (Use Case Diagram). Нотація Use Case Diagram.
Цель варианта использования заключается в том, чтобы определить законченный аспект или фрагмент поведения некоторой сущности без раскрытия внутренней структуры этой сущности. В качестве такой сущности может выступать исходная система или любой другой элемент модели, который обладает собственным поведением, подобно подсистеме или классу в модели системы. Каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемую сущность или систему по запросу пользователя (актера), т. е. определяет способ применения этой сущности. Сервис, который инициализируется по запросу пользователя, представляет собой законченную последовательность действий. Это означает, что после того как система закончит обработку запроса пользователя, она должна возвратиться в исходное состояние, в котором готова к выполнению следующих запросов. Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры. Отношение ассоциации (association relationship) Отношение расширения (extend relationship) Отношение обобщения (generalization relationship) Отношение включения (include relationship)
49. Призначення діаграми топології (Deployment Diagram). Нотація Deployment Diagram
Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Для каждой модели создается только одна такая диаграмма, отображающая процессоры, устройства и их соединения. Для представления применяются нотации, указанные в табл.
60. Призначення діаграми компонент (Component Diagram). Нотація Component Diagram.
Этот тип диаграмм предназначен для распределения классов и объектов по компонентам (будущим подпрограммам, модулям) при генерации программного кода проектируемой системы. Часто данный тип диаграмм называют диаграммами модулей. При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей Специальный термин компонент (component) применяется в языке UML для представления физических сущностей. То есть компонент - физически существующая часть системы, которая обеспечивает реализацию классов и отношений, а также функционального поведения моделируемой программной системы. Компонент служит для общего обозначения элементов физического представления модели и может реализовывать некоторый набор интерфейсов. Виды интерфейсов, которые реализует компонент и их представления представлены в табл.