· Представлення фізичних носіїв, на яких уводяться, виводяться і зберігаються дані.
· Виділення ключової обробки і крапок прийняття рішень.
Рис. 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.
Групи -учасники створення систем
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
