Главная Иностранные языки Информатика Искусство и культура Исторические личности Матметоды в эк-ке Метрология Неопределено Режущий инструмент Реклама и PR Ресторанно-гостиничный бизнес бытовое обслуживан Государственное регулирование и налогообложение Гражданское право Гражданское процессуальное право САПР Стратегический менеджмент Схемотехника Уголовное право Уголовный процесс Управление персоналом Физика Эктеория Электротехника Этика эстетика Юридпсихология Карта сайта	Рефераты. Інформаційні системи в економіці
Модифікування для удосконалення системи
Настроювання системи
Супровід системи	Виправлення помилок. Реализация новых требований. Поліпшення ефективності обробки.
Завершення корисного життєвого циклу	Система вимагає дуже багато витрат на супровід для підвищення ефективності і реалізації нових цілей користувача
Як тільки життєвий цикл системи закінчується, потрібно цілком нова система, і цикл може початися знову.

Достоїнства підходу життєвого циклу

Підхід життєвого циклу використовується:

Для формування великих систем обробки транзакций (TPS) і інформаційних систем керування (MIS), де вимоги сильно структуровані і гарне визначені.

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

Обмеження підходу життєвого циклу

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

Таблиця 4.

Обмеження життєвого циклу

Обмеження

Опис

Дуже дорогий і трудомісткий

Дуже багато часу необхідно для нагромадження інформації і підготовки об'ємних специфікацій і документів приймання.

Можуть пройти роки перш, ніж система буде остаточно встановлена.

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

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

Негнучкий і утрудняє зміни

Передбачає перевірки системи для гарантії того, що вимога виконана.

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

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

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

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

Погано підходить для додатків орієнтованих на рішення.

Прийняття рішень може бути занадто неструктурованим і нечітким.

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

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

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

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

2.5.1. Традиційні методології розробки

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

Таблиця 1.

Відсутність і використання методології розробки

Етап розробки

Відсутність методології

Традиційні методології

Системний аналіз

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

Формальний і структурований процес формування ясних і точних специфікацій

Програмування

·                     Мистецтво

·                     Програми неструктуровані, написані на складному і заплутаному коді (спагеті коді)

·                     Спагеті код (Spaghetti code) - неструктурований, незрозумілий програмний код із заплутаною логікою, що метафорично нагадує горщик звареної спагеті.

·                     Технологія створення програм

·                     Якісні, структуровані, написані на зрозумілому коді програми

Супровід

Негнучкі системи, супровід яких практично неможливо

Прості для розуміння і підтримки системи

Концепція традиційних методологій розробки

Традиційні методології виходять з парадигми: інформаційна система містить два типи сутностей:

·                   деякий аналог програми - операційні сутності, що виконують деяку обробку;

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

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

Основні характеристики традиційних методологій розробки

Основні характеристики традиційних методологій представлені в таблиці 2.

Таблиця 2.

Характеристики традиційних методологій розробки

Характеристика

Опис

Структурні

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

Підхід «зверху вниз»

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

Орієнтація на процес

·                     Більше орієнтовані на процес, чим на дані.

·                     Центр методологій – обробка даних, а не самі дані.

·                     Опису даних - частина методів

Лінійність

Кожна фаза повинна бути закінчена перш, ніж буде почата наступна.

Багаторічне використання

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

·                     Багато існуючих систем були розроблені з їх використанням.

Домінування

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

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

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

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

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

 

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

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

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

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

Особливості структурного аналізу представлені в таблиці 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)) - основний інструмент структурного аналізу, що графічно ілюструє складені процеси системи і потік даних між ними.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12