176715 (685577), страница 11
Текст из файла (страница 11)
Рис. 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. Інформаційні системи як запланована організаційна зміна
Інформаційна система - социотехнический об'єкт, сукупність технічних і соціальних елементів.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
