Інформаційні системи в економіці

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

Особливості структурного аналізу представлені в таблиці 3.

Таблиця 3.

Структурний аналіз

Поняття	Опис
Задачі	Аналіз системи зверху вниз. Визначення інтерфейсів між модулями. Точний опис процесів або перетворень, що відбуваються усередині кожного модуля.
Елементи	Діаграми системи: IDEF0 - діаграми бізнесу-процесу; IDEF3 (Workflow diagramming) - діаграми потоку робіт; DFD (Data flow diagramming, DFD) - діаграми потоку даних; ER (Entity-relation diagramming) -- діаграми сутність відношення. Словник даних Специфікації процесів таблиця рішень; дерево рішень; псевдокод.
Застосування	Системний аналіз Визначення специфікацій Проектування Відправна крапка структурного проектування.
Результат	Документ структурної специфікації: Діаграми системи Словники даних потоків даних і сховищ даних Специфікацій процесу Вхідні і вихідні документи Вимоги захисту, контролю, перетворення і продуктивності.

2.5.3. Діаграми структурного аналізу

Діаграми структурного аналізу представлені в таблиці 4.

Таблиця 4.

Діаграми структурного аналізу

Діаграма	Опис	Елементи
Бізнес-процес	Методологія IDEF0: існуюча модель бізнесу (AS-IS); оцінка моделі бізнесу; ідеальна моделі бізнесу (TO-BE)	Роботи - процеси, функції або задачі, що відбуваються в плині визначеного часу і мають розпізнавані результати. Входи - матеріали або інформація, що використовуються або перетворяться роботою для одержання результату (виходу). Виходи - матеріали або інформація, що виробляються роботою. Механізми - ресурси, що виконують роботу, наприклад персонал організації, верстати, пристрої і т.д. Керування - правила, стратегії, процедури або стандарти, якими керується робота.
Потік даних	Діаграма потоку даних (Data flow diagram (DFD)): рух даних у, з, і усередині інформаційної системи; процеси перетворення і збереження даних.	Потоки даних - рух даних між процесами, зовнішніми сутностями і сховищами. Процеси - представлення перетворення потоків вхідних даних у потоки вихідних даних. Сховища даних - ручні або автоматизовані сховища даних. Зовнішні сутності (зовнішні інтерфейси) - зовнішні джерела або одержувачі інформації за межами системи.

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

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

Рис. 1. Елемент IDEF0-діаграми

Діаграма потоку даних (Data flow diagram (DFD)) - основний інструмент структурного аналізу, що графічно ілюструє складені процеси системи і потік даних між ними.

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

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

Рис. 3. Позначення діаграми потоку даних

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

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

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

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

Рис. 4. Контекстна діаграма системи ведення обліку пенсій і виплат

.

Рис. 5. Діаграма потоку даних нульового рівня для системи ведення обліку пенсійних посібників і виплат

2.5.4. Засоби документування структурного аналізу

Засобу документування структурного аналізу представлені в таблиці 5.

Таблиця 5.

Засобу документування структурного аналізу

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

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

Наприклад, вхід словника даних для потоку даних "Вихідна допомога":

Вихідні допомога = Сума звичайної вихідної допомоги

+ Дата звичайної оплати

+ Передчасна вихідна допомога

+ Дата передчасної оплати

+ Опція з нагоди втрати годувальника

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

Формат таблиці рішень

· Заголовок, що ідентифікує таблицю.

· Стовпчики умов із входами для кожної можливої умови.

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

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

Рис. 6. Таблиця рішень для щомісячних виписок рахунка грошового ринку

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

Рис. 7. ілюструє дерево рішень для щомісячних виписок рахунка грошового ринку.

Рис. 7. Дерево рішень для щомісячних виписок рахунка грошового ринку

Таблиця 7.

Застосування дерева рішень і таблиці рішень

Дерево рішень	Таблиця рішень
Проста система Висвітлювання шляхів рішення і послідовності рішень	Складна система: численні послідовності кроків і комбінацій умов Представлення критеріїв вибору даного шляху

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

Псевдокод використовує ті ж самі логічні моделі як основні керуючі структури структурного програмування (див. мал. 8.):

· Послідовна структура - послідовні окремі кроки або дії в логіку програми, що не залежать від існування будь-якої умови.

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

· Ітеративна структура - логічна модель у програмуванні, де деякі дії повторюються, поки зазначена умова виконується або поки деяка умова не виконається.

Рис. 8. Керуючі структури псевдокоду

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

Рис. 9. Псевдокод для щомісячної виписки по рахунку грошового ринку

2.6. Структурне проектування і програмування

2.6.1. Структурне проектування

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

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

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

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

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

Структурна діаграма

Як тільки проект сформульований, він документується в структурній діаграмі.

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

Рис. 1. показує структурну діаграму верхнього рівня системи платіжної відомості.

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



Рис. 1. Структурна діаграма верхнього рівня системи платіжної відомості

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

Рис. 2. Детальна структурна діаграма системи платіжної відомості

2.6.2. Структурне програмування

Структурне програмування розширює керуючі принципи структурного проектування до написання програм.

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

Основне правило структурного програмування - спадна розробка програми і розбивка її на модулі.

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

Таблиця 1.

Вимоги до модулів програми

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

Основні керуючі конструкції

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

· конструкція послідовності - виконання інструкцій у порядку, у якому вони з'являються, з керуванням, безумовно, що переходить від однієї інструкції до наступної.

· конструкція вибору - перевірка умови і виконання однієї з двох альтернативних команд, заснованих на результатах перевірки.

· ітеративна конструкція - повторення сегмента коду, поки перевірка умови не поверне істину.

Керуючі конструкції представлені на мал. 3.

Рис. 3. Основні керуючі конструкції

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

Рис. 4. Вкладені керуючі конструкції

2.6.3. Блок-схеми

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

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

Блок-схеми системи

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

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

Задачі блок-схеми системи

· Представлення загальної структури системи.

· Відображення потік інформації і робіт.

· Представлення фізичних носіїв, на яких уводяться, виводяться і зберігаються дані.

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

Рис. 5. показує основні символи блок-схеми системи.

Рис. 5. Основні символи блок-схеми системи

Рівні деталізації

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

Рис. 6. Блок-схема системи для системи платіжної відомості

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

Рис. 7. Детальна блок-схема системи платіжної відомості

2.6.4. Обмеження традиційних методів

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

Були розроблені нові структурні методи, щоб вирішити багато хто з цих проблем.

Нові структурні підходи до розробки

· Спільний прикладний проект (Join application design (JAD)) - метод проектування, що збирає користувачів і професіоналів разом в одній кімнаті для інтерактивного проектування системи. Належним образом підготовленої і забезпечені, сесії JAD можуть значно прискорити фазу проектування при включенні користувачів у проект, на рівні попередньо не можливому.

· Макетування. Макетування прискорює проект при більшому залученні користувачів і збільшує гнучкість усього процесу.

Таблиця 3.

Обмеження традиційних методів

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

ТЕМА 8. УПРАВЛІННЯ ПРОЦЕСАМИ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

1. Інформаційна система, яка за планове організаційна зміна.

2. Перепроектування бізнес-процесів.

3. Учасники розробки систем.

4. Управління процесом розробки.

5. Проектний менеджмент.

6. Концепція методів планування, організації та контролю проектів.

1. Інформаційні системи як запланована організаційна зміна

Інформаційна система - социотехнический об'єкт, сукупність технічних і соціальних елементів.

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

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

2. Перепроектування бізнесів-процесів

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

Бізнес-процес - набір логічно зв'язаних задач, виконуваних, для досягнення визначеного ділового результату.

Мети перепроектування бізнесів-процесів:

Радикальне поліпшення швидкості і якості, обслуговування.

Підвищення віддачі інформаційних технологій.

Реорганізація трудових процесів об'єднання кроків по скороченню витрат і усуненню повторів, паперово-інтенсивних задач

Перепроектування бізнесу.

Завдяки перепроектуванню своєї системи обробки і процесу роботи з заявками на позичку, Banc One здатний обробити більша кількість документів. Замість щорічної обробки 55,000 позик Banc One щорічно обробляє 500,000 позик (див. Рис. 1.).

Рис. 1. Перепроектування обробки позички в Banc One

3. Учасники розробки систем

Таблиця 1. Групи - учасники створення систем

Групи	Роль
Організаційні групи
Головне керування	Стратегічна. Забезпечує фінансування і підтримку
Професійні експерти	Експертна. Забезпечують юридичну, контрактну й організаційну експертизу
Середнє керування	Бізнес процес. Забезпечує вхід і підтримку
Операційне керування	Інформаційна. Забезпечує вхід і розуміння критичних проблем
Виробничі і/або учрежденческие працівники	Іспит. Забезпечують інформацію, деталі по роботах і задачам
Інформаційні системи
Вище керування інформаційних систем	Координує розробку і планування систем
Керівництво проектом	Керує визначеним проектом
Старші аналитики	Координують системних аналітиків, проектувальників і набір персоналу.
Системні аналитики	Визначають нові системні вимоги, концепції і процедури
Програмісти	Відповідають за технічну реалізацію нової системи

Області відповідальності розроблювачів систем:

технічна якість інформаційної системи;

інтерфейс користувача.

облік загального впливу на організацію.

загальне керування процесом проектування і реалізації.

Джерела системних ідей

Вимоги кінцевого користувача.

Відділ інформаційних систем.

Головне керування.

4. Керування процесом розробки систем

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

Рис. 2. Управлінський контроль розробки систем

Таблиця 2.

Склад і функції груп керування процесом розробки

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

1. Характеристики проекту

Основні характеристики проекту представлені в таблиці 1.

Таблиця 1.

Характеристики проекту

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

Відмінність проекту від виробничої системи

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

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

2. Керування проектом

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

Методика керування діяльністю на основі проекту була розроблена на основі наслідку Лермана:

· Закон Лермана: "Будь-яку технічну проблему можна перебороти, маючи досить часу і грошей",

· Наслідок Лермана: "Вам ніколи не буде вистачати або часи, або грошей". Основні поняття, зв'язані з керуванням проектом представлені в таблиці 2.

Таблиця 2.

Керування проектом

Компонент	Опис	Характеристика
Головна задача менеджера проекту	Звичайний керівник	"Забезпечити виконання робіт".
	Досвідчений керівник	"Забезпечити виконання робіт у термін, у рамках виділених засобів, відповідно до технічного завдання".
Основні проектні обмеження	Час.	Наиболее критичны. Там, де терміни виконання проекту серйозно затягуються, досить ймовірними наслідками є перевитрата коштів і недостатньо висока якість робіт.
	Бюджет.
	Якість робіт.	Сутужніше всего контролювати. Завдання часто важко і формулювати, і контролювати.
Методики керування проектами	Час	Методи побудови і контролю календарних графіків робіт.
	Бюджет	Методи формування фінансового плану (бюджету) проекту і, у міру виконання робіт, дотримання бюджету відслідковується, для того, щоб не дати витратам вийти з під контролю.
	Якість робіт	Методи керування людськими і матеріальними ресурсами (наприклад, матриця відповідальності, діаграми завантаження ресурсів), методи керування якістю робіт.
Принцип керування проектами	Ефективне керування термінами робіт - ключ до успіху по всім трьох проектного обмеженням: часу, бюджетові, якості робіт.	У методах керування проектами основний акцент робиться на календарному плануванні робіт і контролі за дотриманням календарного графіка.

3. Життєвий цикл проекту

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

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

Основні стадії життєвого циклу проекту представлені в таблиці 3.

Таблиця 3.

Стадії життєвого циклу проекту

Стадія	Опис
Формулювання проекту	Ініціюється в силу виникнення потреб, які потрібно задовольнити. В умовах дефіциту ресурсів неможливо задовольнити всі потреби без винятку. Вибір проекту: рішення приймаються виходячи з наявності ресурсів, і в першу чергу фінансових можливостей, порівняльної важливості задоволення одних потреб і ігнорування інших, порівняльної ефективності проектів. рішення по доборі проектів до реалізації тим важливіше, ніж масштабніше передбачається проект, оскільки великі проекти визначають напрямок діяльності на майбутнє (іноді на роки) і зв'язують наявні фінансові і трудові ресурси. визначальним показником є альтернативна вартість інвестицій. для порівняльного аналізу проектів застосовуються методи проектного аналізу: фінансовий, економічний, комерційний, організаційний, екологічний, аналіз ризиків і інші види аналізу проекту. Системи для планування і керування проектами використовуються в обмеженому виді.
Планування	Виробляється в плині всього терміну реалізації проекту. На самому початку розробляється неофіційний попередній план - грубе представлення про те, що буде потрібно виконати у випадку реалізації проекту. Рішення про вибір проекту в значній мірі ґрунтується на оцінках попереднього плану. Формальне і детальне планування проекту починається після ухвалення рішення про реалізації проекту. Визначаються ключові крапки (віхи) проекту, формулюються задачі (роботи) і їхня взаємна залежність. Використовуються системи для керування проектами - набір засобів для розробки формального плану: засобу побудови ієрархічної структури робіт; сіткові графіки і діаграми Гантта; засобу призначення і гистограммы завантаження ресурсів. Твердження формального плану. План проекту в міру здійснення проекту піддається постійному коректуванню з урахуванням поточної ситуації.
Здійснення	В міру здійснення проекту керівники зобов'язані постійно контролювати хід робіт: збір фактичних даних про хід робіт і порівняння їх із плановими; аналіз можливого впливу відхилень у виконаних обсягах робіт на хід реалізації проекту в цілому і вироблення відповідних управлінських рішень.
Завершення	Проект закінчується коли досягнуті поставлені перед ним мети. Керівник повинний виконати ряд заходів, конкретний характер яких залежить від характеру самого проекту: при використанні в проекті устаткування, треба зробити його інвентаризацію і передати його для нового застосування; при підрядних проектах треба визначити, чи задовольняють результати умовам підряду або контракту. необхідно скласти остаточні звіти, а проміжні звіти по проекті організувати у виді архіву.

4. Концепція методів планування, організації і контролю проектів

Основні визначення і концепції методів планування представлені в таблиці 3.

Таблиця 3.

Концепція методів планування

Поняття	Визначення	Опис
Робота	Діяльність, необхідна для досягнення конкретних результатів (кінцевих продуктів нижнього рівня).	Основний елемент діяльності на самому нижньому рівні деталізації, на виконання якого потрібен час, і який може затримати початок виконання інших робіт. Основа для організації даних у системах керування проектами. Момент закінчення роботи означає факт одержання кінцевого продукту.
Віха (подія)	Подія або дата в ході здійснення проекту.	Не має тривалості Відображення стану завершенности робіт. Позначення важливих проміжних результатів, що повинні бути досягнуті в процесі реалізації проекту.
Зв'язку предшествования (логічні залежності)	Відображення природи залежностей між роботами.	Зв'язку "кінец-почало" - наступний робот мог поча_ тільки по завершенн попередн робот. Структура мережі. Послідовність виконання робіт.
Мережна діаграма	Графічне відображення робіт проекту і їхніх взаємозв'язків.	Логічні залежності між елементарними роботами. Не відображає входи, процеси і виходи Не допускає повторюваних циклів або петель. Основні види мереж: Мережа «вершина-робота»; Мережа «вершина-подія».
Критичний шлях	Максимальний по тривалості повний шлях у мережі. Роботи, що лежать на критичному шляху називаються критичними роботами.	Найменша загальна тривалість робіт. Тривалість проекту може бути скорочена за рахунок скорочення тривалості задач, що лежать на критичному шляху. Затримка виконання задач критичного шляху спричинить збільшення тривалості проекту.
Метод критичного шляху	Метод розрахунку можливих календарних графіків виконання комплексу робіт на основі описаної логічної структури мережі й оцінок тривалості виконання кожної роботи.	Концентрація уваги менеджера на критичних роботах. Можливість маніпулювання термінами виконання задач, що не лежать на критичному шляху.
Часовий резерв	Різниця між самим раннім можливим терміном завершення роботи і самим пізнім припустимим часом її виконання.	Дозволяє менеджерові затримати роботу, що має часовий резерв, без впливу на загальну тривалість проекту. Роботи, що лежать на критичному шляху, мають часовий резерв, дорівнює нулеві.
Діаграма Ганта	Горизонтальна лінійна діаграма, на якій задачі проекту представляються протяжними в часі відрізками, що характеризуються датами початку і закінчення, затримками і можливо іншими тимчасовими параметрами.
Ресурсна гистограмма	Гистограмма, що відображає потреби проекту в тім або іншому виді ресурсів у кожен момент часу.
Ресурси	Компоненти діяльності, що забезпечують, що включають виконавців, енергію, матеріали, устаткування і т.д.	З кожною роботою можна зв'язати функцію потреби в ресурсах.
Призначення і вирівнювання ресурсів.	Методика, що дозволяє менеджерові проаналізувати мережний план, побудований за допомогою методу критичного шляху для того, щоб забезпечити приступність і використання визначених ресурсів протягом усього часу виконання проекту.	Визначення потреби кожної роботи в різних типах ресурсів. Программно-реализованные евристичні алгоритми планування при обмежених ресурсах, що допомагають створити реальний розклад проекту, з урахуванням потреби проекту в ресурсах і фактично доступних у даний момент часу ресурсів.
Ресурсне календарне планування	Планування термінів початку робіт при обмежених наявних ресурсах.	Зіставлення функцій наявності і потреби в ресурсах проекту в цілому. Зрушуючи некритичні роботи аж до їхніх пізніх термінів початку (закінчення), можна видозмінити ресурсний профіль, забезпечуючи оптимальне використання ресурсів. Допомагає загострити увага менеджера і членів команди на тих моментах робіт, де ефективне керування ресурсами буде ключовим фактором успіху.
Вихідний план	План виконання робіт проекту, що містить вихідні зведення про основні тимчасові і вартісні параметри робіт, що прийнятий до виконання.	Обсяги робіт. Планові дати початку і закінчення задач проекту. Тривалості задач. Розрахункові вартості задач.

ТЕМА 9. АВТОМАТИЗАЦІЯ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

1. Проблема якості інформаційних систем.

2. Засоби CASE.

3. Достоїнства CASE.

4. Основі елементи CASE.

5. Класифікація засобів CASE.

6. Можливості та характеристики CASE.

1. Достоїнства CASE

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

Достоїнства використання CASE

Звільнення розроблювача для виконання більш творчих проблемних задач.

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

Організація спільної роботи групи.

Розробка більш надійного і потребуючого меншого ремонту систем.

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

Застосування структурних методологій.

Підтримка объектно-ориентированной розробки.

Збільшення продуктивність і якості.

Задачі CASE

Розпорядження стандартної методології розробки і проектної дисципліни:

ефективна координація великі групи і програмні проекти;

цілісність проекту і загальних проектно-конструкторських робіт.

Поліпшення зв'язку між користувачами і технічними фахівцями.

Організація і взаємозв'язок проектних компонентів і забезпечення швидкого доступу до них через репозитарий проектів.

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

Автоматизація перевірки і контролю відкоту.

2. Основні елементи CASE

Основні елементи CASE описані в таблиці 1.

Таблиця 1.

Основні елементи CASE

Елемент	Опис
Інструментальні засоби побудови діаграм	Графічні інструментальні засоби для малювання символів, зв'язаних з визначеною методологією: діаграми потоку даних; структурні схеми; діаграми сутність-зв'язок; інші типи діаграм.
Верификатор синтаксису	Перевірка точності і закінченості інформації, введеної в систему відповідно до правил визначеної структурної методології.
Інструментальні засоби макетування	Дозволяють намалювати необхідний макет екрана і звіту або шляхи меню в системі без складного форматування специфікацій або програмування: генератори екранів; генератори звітів; генератори меню.
Інформаційний репозитарий	Координує, інтегрують і стандартизують різні частини інформації для полегшення доступу, спільного і багаторазового використання в майбутній програмній роботі. Центральна інформаційна база даних для збереження всіх типів засобів програмного забезпечення: макети екранів і звітів; діаграми; визначення даних; код програми; розкладу проекту; інша документація.
Генератори коду	Генерують модулі коду, що виконується, зі специфікацій верхнього рівня.
Методологія розробки	Контроль і керування всім проектом розробки систем. Запитальники або коментарі, що деталізують усю методологію розробки.
Інструментальні засоби керування проектом	Планування проектів і оцінка ресурсів

3. Класифікація інструментальних засобів CASE

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

Таблиця 2.

Класифікація інструментальних засобів CASE

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

4. Можливості інструментальних засобів CASE

Що інструментальні засоби CASE можуть і не можуть робити представлені в таблиці 3.

Таблиця 3.

Що інструментальні засоби CASE можуть і не можуть робити

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

Застосування сучасних інструментальних засобів CASE

Вхідна робота з проектування й аналізу, що зменшує кількість помилок, який необхідно пізніше виправити.

Створення технічно правильних діаграм, обробка описів і введення словника даних за допомогою текстових і графічних редакторів CASE

Побудова діаграми за допомогою стандартного набору символів.

Автоматичний зв'язок елементів даних із процесами, де вони використовуються.

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

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

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

Спільне використання членами проектної групи й обмеження можливості зміни база даних CASE

Основні проблеми використання CASE представлені в таблиці 4.

Таблиця 4.

Проблеми використання CASE

Проблема	Опис
Потрібно більше організаційної дисципліни, чим при ручному підході	Кожен член проекту розробки повинний твердо притриматися загального зводу угод про імена, стандартів і методології розробки. Аналитики і проектувальники намагаються зберегти своїх старі способи розробки систем і будуть намагатися включати інструмент CASE у процес. Інструментальні засоби CASE пропонують загальні методи і стандарти, що не можуть використовуватися в ситуаціях, коли бракує організаційної дисципліни.
Фактична продуктивність, отримана від використання CASE важко визначна.	Продуктивність, отримана в програмній розробці, традиційно був важкий для виміру і кількісного визначення.
CASE - не чарівна панацея	Не може автоматично розробляти системи або гарантувати, що ділові вимоги будуть виконані. Проектувальники систем повинні розуміти ділові потреби фірми і як бізнес працює. Системний аналіз і проектування усе ще залежать від навичок аналітика / проектувальника. Деякі збільшення продуктивності - результат роботи системних розроблювачів, що поліпшили зв'язок, координацію і програмну цілісність, домовилися про стандартну методологію, а не результат використання CASE.
Недолік методології	Для автоматизації процес розробки програмного забезпечення, він повинний бути визначений відповідно до методології. При відсутності методології, CASE можуть використовуватися, щоб автоматизувати непорівнянні, і часто несумісні, дії скоріше, ніж інтегрувати або стандартизувати підхід розробки систем.