1   2   3   4   5   6   7   8   9   ...   12
Ім'я файлу: ІС.docx
Розширення: docx
Розмір: 1239кб.
Дата: 07.02.2020
скачати

Діаграми компонентів та розгортання в UML


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

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

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



ДІАГРАМИ КОМПОНЕНТІВ – показують компоненти системи і залежності між ними.

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



  1. Фінансово-управлінські інформаційні системи.

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

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

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

Хоча загальна конфігурація систем може бути досить складною, практично всі фінансово-управлінські системи спроможні працювати на персональних комп’ютерах у звичайних мережах передачі даних Novell Netware або Windows NT. Вони спираються на технологію виділеного серверу бази даних (file server), що характеризується високою завантаженістю мережних каналів для передачі даних між сервером і робочими станціями. Тільки окремі із запропонованих систем такого класу були розроблені для промислових баз даних (Oracle, SYBASE, Progress, Informix, SQL Server). Використовувалися переважно більш прості засоби розробки Clipper, FoxPro, dBase, Paradox, що, як правило, дають збої на складних конфігураціях мережі і при збільшенні обсягів опрацьовуваних даних.


  1. Моделі життєвого циклу ІС.

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

Модель ЖЦ ІС включає в себе:

стадії;

результати виконання робіт на кожній стадії;

ключові події - точки завершення робіт і прийняття рішень.

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

В даний час відомі і використовуються наступні моделі життєвого циклу:

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

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

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

  1. Характеристика методологій структурного (функціонального) проектування і моделювання.


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

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

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

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

SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми; DFD (Data Flow Diagrams) діаграми потоків даних; ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок".

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

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

За допомогою SADT-методології вирішуються такі основні завдання (для систем будь-якої природи): аналіз функцій, виконуваних системою;

опис специфікацій вимог і функцій проектованої системи;

проектування системи.

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

Основні елементи діаграми потоків даних DFD такі:

- роботи (функції обробки інформації); - потоки даних (дуги вхідних й вихідних величин);ь- сховища даних; - зовнішні сутності.


  1. Діаграми Use Case UML

Діаграми варіантів використання, або прецендентів (Use-Case Diagrams) – це графічне представлення поведінки системи – варіантів її використання.

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

Діаграми варіантів використання, або прецендентів (Use-Case Diagrams) – це графічне представлення поведінки системи – варіантів її використання.

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

Кожний варіант може описуватися окремо, на окремій діаграмі, або ж ряд варіантів можуть бути зведені в єдину діаграму.

Діаграми варіантів використання можуть містити:

  • Акторів („ролі” зовні системи);

  • Варіанти використання (визначають можливості системи);

  • Границі системи

  • Відношення між акторами і варіантами використання в системі:

Між актором та варіантом використання може показуватися лише асоціація. Напрямок стрілки на асоціації вказує в даному випадку хто є ініціатором зв’язку (деколи ЩЕ генералізація)

Між варіантами використання вказується відношення залежності (підтипи include, extend).


  1. Характеристика інформаційних систем бухгалтерського обліку.


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

Інформаційна система бухгалтерського обліку традиційно охоплює такі підсистеми:

облік основних засобів та нематеріальних активів;

облік матеріальних цінностей;

облік праці та заробітної плати;

облік готової продукції та її реалізації;

облік фінансово-розрахункових операцій;

облік витрат на виробництво;

зведений облік та складання звітності.

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


  1. Методологія SCRUM

Scrum — підхід управління проектами для гнучкої розробки програмного забезпечення. Скрам чітко робить акцент на якісному контролі процесу розробки.

Основою Scrum є Sprint, в перебігу якого виконується робота над продуктом. По закінченню Sprint долу бути отримана нова робоча версія продукту. Sprint завжди обмежений по часу (1-4 тижні) і має однакову тривалість протягом все життя продукту.

Перед початком кожного Sprint проводиться Sprint Planning, на якому проводиться оцінка вмісту Product Backlog і формування Sprint Backlog, який містить завдання (Story, Bugs, Tasks), які повинні бути виконані в поточному спринті. Кожен спринт повинен мати мету, яка є мотивуючим фактором і досягається за допомогою виконання завдань з Sprint Backlog.

Кожен день проводиться Daily Scrum, на якому кожен член команди відповідає на питання «що я зробив вчора?», «Що я планую зробити сьогодні?», «Які перешкоди на своїй роботі я зустрів?». Завдання Daily Scrum - визначення статусу і прогресу роботи над Sprint, раннє виявлення перешкод, що виникли, вироблення рішень щодо зміни стратегії, необхідних для досягнення цілей Sprint'а.

По закінченню Sprint'а виробляються Sprint Review і Sprint Retrospective, завдання яких оцінити ефективність (продуктивність) команди в минулому Sprint'е, спрогнозувати очікувану ефективність (продуктивність) в наступному спринті, виявленні наявних проблем, оцінки ймовірності завершення всіх необхідних робіт по продукту і інше .

Переваги/недоліки

+ Scrum орієнтований на клієнта, адаптивен. Scrum дає клієнтові можливість робити зміни у вимогах в будь-який момент часу , привабливо для багатьох замовників ПО.

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

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

- Scrum задає низку жорстких правил. Однак це вступає в конфлікт з ідеєю клієнтоорієнтованості в принципі, т. К. Клієнтові не важливі внутрішні правила команди розробки, особливо якщо вони обмежують клієнта. Наприклад, в разі необхідності, за рішенням клієнта Sprint backlog може бути змінений, не дивлячись на явне протиріччя з правилами Scrum.

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


  1. Діаграми хореографії BPMN.

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

У хореографії не використовуються окремі області відповідальності.

Основним елементом діаграми хореографії є ​​завдання хореографії (рис. 4.1).

Завдання хореографії може бути як атомарної діяльністю, так і складовою. Завдання представляє обмін одним або декількома повідомленнями. Кожна атомарна хореографія включає двох учасників - відправника повідомлення і одержувача повідомлення.


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



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

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

Приклад проходження цьому правилу представлений


Приклад послідовності завдань хореографії

Складова хореографія або під-хореографія може відображати складну взаємодію учасників. Приклад складовою хореографії.



Під-хореографія може відображати взаємодію кількох учасників.

Для розробки моделі хореографії повинна використовуватися діаграма хореографії (Choreography Diagram).

Элементы диаграммы хореографии, используемые для разработки модели, представлены



Модель бизнес-процесса в виде потока работ должна разрабатываться в два этапа. Сначала разрабатывается модель, отображающая подпроцессы хореографии (верхний уровень хореографии), затем - модели, отображающие детали хореографии.

Пример конкретного процесса хореографии представлен




  1. Основні складові мови UML.

UML - це мова для візуалізації, специфицирования, конструювання та документування артефактів програмних систем.

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

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

Мова UML призначений насамперед для розробки програмних систем. Його використання особливо ефективно в наступних областях:

інформаційні системи масштабу підприємства;банківські та фінансові послуги; телекомунікації; транспорт; оборонна промисловість, авіація та космонавтика; роздрібна торгівля; медична електроніка; наука;розподілені Web-системи.

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

В рамках мови UML всі уявлення про моделі складної системи фіксуються у вигляді спеціальних графічних конструкцій, що одержали назву діаграм. У термінах мови UML визначені наступні види діаграм:
Діаграма варіантів використання (use case diagram)
Діаграма класів (class diagram)
Діаграми поведінки (behavior diagrams)
Діаграма станів (statechart diagram)
Діаграма діяльності (activity diagram)
Діаграми взаємодії (interaction diagrams)
Діаграма послідовності (sequence diagram)
Діаграма кооперації (collaboration diagram)
Діаграми реалізації (implementation diagrams)
Діаграма компонентів (component diagram)
Діаграма розгортання (deployment diagram)

В якості самостійних уявлень в мові UML використовуються наступні діаграми: Діаграма варіантів використання; діаграма класів; діаграма станів; діаграма діяльності; діаграма послідовності; діаграма кооперації; діаграма компонентів; діаграма розгортання


  1. Характеристика комплексів економічних задач з управління трудовими ресурсами.

Управління трудовими ресурсами визнається однією з найбільш важливих сфер життя організації будь-якого рівня ієрархії, здатного багаторазово підвищити її ефективність, а саме поняття «управління трудовими ресурсами» розглядається в досить широкому діапазоні: від економіко-статистичного до філософсько-психологічного

Найважливішою задачею в області УТР є розробка методик визначення поточної й перспективної потреби підприємства.

У світовій практиці укрупненому виді УТР передбачає рішення взаємозалежних функцій:- планування (що робити?); - організація (як робити?); - мотивація (як стимулювати?); - контроль (як оцінити?)

Управління персоналом здійснюється при допомозі науково розроблених методів. Методи — це спосіб впливу на колектив або окремого працівника для досягнення поставленої цілі, координації його діяльності в процесі виробництва. В теорії і практиці управління застосовують три групи методів: адміністративні, економічні і соціально-психологічні.

Адміністративні методи ґрунтуються на владі, дисципліні та покаранні, відомі в історії як «метод кнута». Адміністративні методи орієнтуються на такі мотиви поведінки, як усвідомлена необхідність трудової дисципліни, почуття обов'язку, бажання людини працювати в певній організації, культура трудової діяльності. Головні функції адміністративних методів — це забезпечення стабільного юридичного середовища для діяльності організації, захисту конкретного середовища, гарантування прав і свобод.

Економічні методи базуються на використанні економічних стимулів і відомі як «метод пряника». За їх допомогою здійснюється матеріальне стимулювання колективу, окремих працівників. В умовах пром. підприємств це — економічні нормативи діяльності, система матеріального заохочення, участь у прибутках і капіталі, премії тощо.

Соціально-психологічні методи засновані на використанні моральних стимулів до праці і впливають на персонал з допомогою психологічних механізмів з метою переведення адміністративного завдання в усвідомлений обов'язок, внутрішню потребу людини. Цього можна досягти через: — формування колективу, створення нормального психологічного клімату й творчої атмосфери;

— особистий приклад; — задоволення культурних і духовних потреб працівників; — встановлення соціальних норм поведінки і соціального стимулювання розвитку колективу;

— встановлення моральних санкцій і заохочення; — соціальний захист


  1. Структура опису постановки задачі.

Опис постановки задачi (ПОЗ) (комплексу задач) є елементом технiчного проекту. У разі машинної та автоматизованої обробки даних обсяг поняття «задача» охоплює:
1.процес машинної обробки даних, тобто безпосереднє розв’язування задачi машинними засобами;
2.метод розв’язування;
3.процедури пiдготовки даних до обробки;
4.використання даних, зокрема й для прийняття управлiнських рiшень.
Органiзовуючи автоматизоване розв’язування задачi, необхiдно прийняти певне i конкретне рiшення з перелічених питань, а отже, щоб реалiзувати автоматизоване розв’язування задачi, слід насамперед розробити постановку задачi, яка має містити про цю задачу всі необхiднi та достатнi вiдомостi.
Склад i змiст постановки задачi (комплексу задач) залежить вiд специфiки останньої та умов розв’язування. Загалом ПОЗ складається з таких основних роздiлів: 1) характеристика задачi; 2) вихiдна iнформацiя; 3) вхiдна iнформацiя. Окрiм того, виконується опис алгоритму автоматизованого розв’язування задачі, який може бути включений до ПОЗ як роздiл 4-й або викладений окремо. Іноді ПОЗ містить i роздiл «Розрахунок економiчної ефективностi», де обгрунтовується ефективність розв’язування задачi за допомогою ЕОМ.
Схарактеризуємо кожний розділ ПОЗ.
Роздiл 1-й мiстить інформацію про призначення задачі (комплексу задач); перелiк об’єктiв, у процесі управління якими розв’язується задача; перiодичнiсть i тривалiсть розв’язування; умови, за яких припиняється розв’язування автоматизованим способом; iнформацiйнi та технологiчнi зв’язки з iншими задачами (комплексами) АIС; посади осiб і (або) назви пiдроздiлiв, якi визначають умови та часовi характеристики конкретного розв’язання (рішення) та подiл обов’язкiв між персоналом i технiчними засобами в рiзних ситуацiях розв’язування задачі (комплексу задач).
Роздiл 2-й (вихiдна iнформацiя) складається з перелiку та опису вихiдних повiдомлень (тобто форм вiдомостей, вiдеограм, вiдеокадрiв тощо) та перелiку й опису структурних одиниць iнформацiї вихiдних повiдомлень, якi мають самостiйне змiстове навантаження. Опис вихiдних повiдомлень має вигляд таблицi, що містить назву кожного повiдомлення, його iдентифiкатор, форму подання (документ, вiдеокадр, сигнал тощо), перiодичнiсть i термiн видачi. Описуючи структурні одиниці вихiдних повiдомлень, зазначають назву одиницi, iдентифiкатор вихiдного повiдомлення, якому вона належить, вимоги до точностi обчислення цієї одиниці, її умовне позначення.
Роздiл 3-й (вхiдна iнформацiя) мiстить перелiк i опис вхiдних повiдомлень та перелiк i опис структурних одиниць iнформацiї вхiдних повiдомлень, якi мають самостiйне змiстове навантаження. Пiд вхiдною iнформацiєю розумiють данi, якi є необхiдними для розв’язування задачi й надходять у виглядi документiв i повiдомлень рiзної форми. Опис вхiдних повiдомлень також задається у виглядi таблицi i мiстить найменування повiдомлення, його iдентифiкатор, форму подання, строки й частоту надходження. Опис структурної одиницi вхiдного повiдомлення складається з її найменування, потрiбної точності числового значення та вказівки щодо джерела відповідної iнформацiї (повiдомлення, яке мiстить цю одиницю).
ПОЗ розробляється в такiй послiдовностi. Якщо технiко-економiчна суть задачi є зрозумiлою, то розробку починають iз визначення вихiдної iнформацiї розв’язуваної задачi, iз опису змiсту та форми вихiдних повiдомлень і способiв їх подання, визначення реквiзитiв та носiїв вихiдних даних.
Пiсля встановлення вихiдних даних визначають необхiднi вхiднi дані та розпочинають розробку алгоритму розв’язування задачi — послідовності правил отримання вихiдних даних на підставі вхiдних. Iз розробленого алгоритму визначається також iнформацiя для зберiгання та нагромадження. На закiнчення відпрацьовується система внесення змiн до iнформацiї задачi.
Для перевiрки правильностi алгоритму розробляють контрольний приклад, який слугує також для забезпечення вiдлагодження програм та їх тестування пiд час експлуатацiї.
Практика показує, що найкращий контрольний приклад — це приклад, побудований на реальних даних. Проте скористатися таким прикладом можна не завжди через відсутність потрiбних реальних даних або через те, що їх забагато (у такому разі відлагодження програми дуже ускладнюється й сповільнюється) чи наявні реальнi данi не повнiстю відбивають усi можливi варiанти розв’язування. ПОЗ істотно спрощується, коли для її розв’язання використовуються типовi проектнi рiшення (ТПР) та пакети прикладних програм (ППП). Тодi фактично розробляється лише роздiл 1-й, а в 2-му та 3-му роздiлах ПОЗ відбувається просте «прив’язування» (добiр) потрiбних повiдомлень ППП (ТПР) або зазначені роздiли не розробляються зовсім.
Зауважимо, що специфiчні особливостi ПОЗ виявляються під час розв’язування задач у дiалоговому режимi. Адже потрiбно розробляти сценарiй дiалогу, враховуючи зручнiсть роботи, типи дiалогу, форми їх реалiзацiї на ЕОМ i навiть притаманні користувачеві прийоми та привички.

  1. Призначення та приклади систем BPMS.

BPM (Business Process Management) системи - це клас програмних продуктів, які допомагають керувати бізнес процесами організації. За рахунок застосування BPM систем з'являється можливість визначити процеси в компанії, представити їх графічні схеми, виконувати управління, аналіз і подальше вдосконалення бізнес процесів.

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

На відміну від інших корпоративних інформаційних систем, які використовують процесний підхід (ERP, CRM, OLAP системи, DocFlow), BPM системи більш прості в освоєнні і швидше приносять віддачу від впровадження. Менеджерам вони дають більш простий спосіб контролювати ситуацію в організації, лінійному персоналу - чіткий розподіл відповідальності та ефективне управління своїм робочим часом, споживачам - більш швидкий і якісний продукт або сервіс.

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

До цих класів відносяться:

Системи управління документацією, які дають можливість контролювати рух документів по заданим правилам. Ці системи автоматизують рух документації;

Системи управління ресурсами, такі як ERP, CRM системи, які дозволяють управляти і контролювати матеріальні і людські ресурси. Ці системи автоматизують управління ресурсами;

CASE засоби, такі як ARIS, BPwin, ERwin, Rational Rose, які дозволяють моделювати і проводити аналіз процесів організації. Ці системи автоматизують моделювання та створення процесів.

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

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

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

Основні програмні модулі, що входять до складу BPM системи, такі:

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

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

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

 Модуль управління потоками робіт і бізнес правилами. Цей модуль реалізує управління потоками робіт, потоками інформації і документів, а також контролює виконання заданих бізнес правил. У цьому модулі здійснюється формування завдань персоналу, який бере участь в процесі і формування бізнес правил для взаємопов'язаних з BPM системою інформаційних систем.

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

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

 Модуль управління BPM системи. Цей модуль являє собою інструмент адміністратора системи. З його допомогою виконується конфігурування програмних засобів, призначення прав доступу, контроль роботи апаратних засобів та ін.


  1. Методологія RUP.

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

RUP заснований на наборі будівельних блоків, чи містить елементи, що описують те, що повинно бути зробленим, необхідні навички, та покрокове пояснення того, як досягаються конкретні цілі розробки. Основними будівельними блоками, чи елементами вмісту, є наступні:
-Ролі (хто). Роль визначає набір навичок, компетенції та відповідальності.
-Робочі продукти (що). Робочий продукт являє собою щось отримане з завдання, в тому числі всі документи і моделі, випущені під час роботи впродовж процесу.
-Завдання (як). Завдання описує одиницю роботи, яка доручена ролі, яка забезпечує значущий результат.
У кожній ітерації, завдання діляться на дев'ять дисциплін: шість «інженерних дисциплін» (бізнес-моделювання, вимоги, аналіз і проектування, реалізація, тестування, розгортання) і трьох допоміжних дисциплін (конфігурація і керування змінами, управління проектами, середовища).

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

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

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

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

1   2   3   4   5   6   7   8   9   ...   12

скачати

© Усі права захищені
написати до нас