Учебное пособие: Інформаційні системи в економіці
Життєвий цикл систем.
Життєвий цикл систем самий старий метод створення інформаційних систем і усе ще сьогодн використовується для середніх або великих складних проектів систем.
Життєвий цикл систем - формальний підхід до створення систем, що припускає, що нформаційна система має життєвий цикл подібно будь-якому живому організмові: з початком, серединою і кінцем і розділяє процес розробки систем на різні стад формує інформаційну систему послідовно, стадія за стадією.
Методологія життєвого циклу також має формальний поділ праці між кінцевими користувачами фахівцями інформаційними систем.
Поділ відповідальності між розроблювачами і кінцевими користувачами:
Технічн фахівці: системні аналитики і програмісти відповідальні за проведення системного аналізу, проектування і робіт з реалізації;
Кінцев користувачі відповідальні за забезпечення інформаційних вимог і експертизу роботи технічного персоналу.
По завершенню кожного етапу потрібні формальні висновки або угоди між кінцевими користувачами і технічними фахівцями.
Рис. 1. показує результати кожної стадії життєвого циклу, що є підставами для формального висновку.
Рис. 1. Методологія життєвого циклу
У таблиці 3. представлено детальної опис кожної стадії життєвого циклу системи.
Таблиця 3.
Стадії життєвого циклу систем
| Стадія | Роботи | Опис |
| Опис проекту | Визначення проблеми | |
| Аналіз можливості рішення проблеми створенням ново нформаційної системи або зміною існуючої. | "Чому необхідний проект нової системи?" | |
| Визначення загальних цілей, області проекту. | "Що необхідно досягти?". | |
| Розробка плану проекту, що може бути показаний керуванню | Пропозиція на розробку нової системи. | |
| Аналіз систем | Аналіз проблеми існуючих систем (ручних або автоматизованих) |
"Что существующие системы делают?" "Які їхні достоїнства, недоліки, гарячі крапки проблеми?" |
| Ідентифікація цілей, що будуть досягнуті рішенням для цих проблем | ||
| Опис альтернативних рішень |
"Какие возможны альтернативные варианты решения?" "Їхні витрати і вигоди?" |
|
| Дослідження реализуемости кожного варіанта рішення для експертизи керуванням | ||
| Збір докладної інформації і глибоке дослідження | ||
| Докладний аналіз документів, звітів і робочих паперів, зроблених існуючими системами | ||
| Спостереження за роботою системи | ||
| Опитування користувачів за допомогою опитувальних аркушів | ||
| Проведення інтерв'ю. Определение требований к информационной системе | "Які інформаційні вимоги користувача повинн бути виконані цим рішенням?" | |
| Докладний опис інших дій життєвого циклу і задач кожної фази | ||
| Деталізований звіт за системною пропозицією, що виділяє альтернативні рішення й оцінку реализуемости запропонованих рішень. | ||
| Проектування | Створення логічних і фізичних проектних специфікацій рішення. | |
|
Використання інструментальних засобів проектування документування проектів: діаграми потоку даних, діаграми структури програми, блок-схеми системи, таблиці рішень або дерево рішень і т.д. Звіт по проектних специфікаціях системного рішення, що обрано. |
||
| Програмування | Переклад специфікацій проекту, створених на стад проектування в код програми: | |
| Підготовка специфікацій кожної програми системи системними аналітиками разом із програмістами |
Специфікації програми: опис задач програми, тип мови програмування, введення і висновки, логические схемы обработки информации, процеси обробки й оператори керування типу упорядочивания вхідних даних. |
|
|
Написання програмістами у відповідності з специфікаціями коду програм Фактичний код програмного забезпечення системи. |
Для створення великих систем, що мають багато програм із сотнями тисяч рядків програмного коду, можуть знадобитися ціл команди програмістів | |
| Установка | Фінальні кроки по введенню нової або модифіковано системи в роботу: | |
| Тестування | Перевірка правильності роботи з технічно функціональної точки зору бізнесу. | |
| Навчання | Фахівці в області бізнесу і технічних фахівців навчаються використовувати нову систему | |
| Перетворення | Формальний план перетворення містить деталізований розпорядок усіх дій, необхідних для установки нової системи, і перетворення старої системи в нову систему. | |
| Результати тестів для оцінки ефективності системи | ||
| Посада реалізація | Використання й оцінка системи користувачами технічними фахівцями після того, як вона була встановлена і знаходиться в експлуатації. | Формальна ревізія, що визначає, на скількох добре нових систем виконує первісні цілі, і потрібні чи виправлення або зміни |
| Модифікування для удосконалення системи | ||
| Настроювання системи | ||
| Супровід системи |
Виправлення помилок. Реализация новых требований. Поліпшення ефективності обробки. |
|
| Завершення корисного життєвого циклу | Система вимагає дуже багато витрат на супровід для підвищення ефективності і реалізації нових цілей користувача | |
| Як тільки життєвий цикл системи закінчується, потрібно цілком нова система, і цикл може початися знову. | ||
Достоїнства підходу життєвого циклу
Підхід життєвого циклу використовується:
Для формування великих систем обробки транзакций (TPS) і інформаційних систем керування (MIS), де вимоги сильно структуровані і гарне визначені.
Для складних технічних систем типу запуску космічних кораблів, керування повітряним рухом і переробкою нафти, де необхідний строгий і формальний аналіз вимог, визначені специфікації і тверді засоби керування над процесом створення систем.
Обмеження підходу життєвого циклу
Однак методологія життєвого циклу систем має серйозні обмеження і не дуже добре підходить для більшості маленьких настільних систем, що будуть переважати в двадцять перших сторіч. Основні обмеження підходу життєвого циклу представлен в таблиці 4. Деякі з цих обмежень можуть бути вирішені альтернативними стратегіями створення систем.
Таблиця 4.
Обмеження життєвого циклу
| Обмеження | Опис |
| Дуже дорогий і трудомісткий |
Дуже багато часу необхідно для нагромадження нформації і підготовки об'ємних специфікацій і документів приймання. Можуть пройти роки перш, ніж система буде остаточно встановлена. При занадто великому часі розробки інформаційн вимоги можуть змінитися перш, ніж система буде впроваджена. Система, що вимагає багато років і грошей для створення, може застаріти, поки вона буде ще на креслярській дошці. |
| Негнучкий і утрудняє зміни |
Передбачає перевірки системи для гарантії того, що вимога виконана. Коли вимоги неправильні або виникають помилки, повинна бути повторена послідовність дій життєвого циклу, що приводить до збільшення часу і витрат. Заохочує заморожування специфікацій на ранніх етапах процесу розробки, що виключає можливість змін. Користувачі утрудняються чітко представити фінальну систему по документах специфікації і ставлять підпису на документах специфікації без повного розуміння їхнього змісту, тільки протягом програмування тестування довідаються, що специфікації неповні, роблять не те, що вони мали на увазі. Коректні специфікації не завжди можуть бути визначені відразу і досить рано, коли вони легко можуть бути змінені |
| Погано підходить для додатків орієнтованих на рішення. |
Прийняття рішень може бути занадто неструктурованим нечітким. Вимоги можуть постійно мінятися, або рішення не можуть мати чітких моделей або процедур. Особи, що приймають рішення, часто не можуть заздалегідь визначити свої інформаційні потреби, і змушені експериментувати з конкретними системами, щоб роз'яснити види рішень, що вони бажають робити. Високий рівень невизначеності не може бути легко погоджений з підходом життєвого циклу. |
2.5. Структурний аналіз.
2.5.1. Традиційні методології розробки.
На зорі програмування існувало небагато методологій. Відсутність методологій приводило до створення складних, негнучких, ненадійних систем, супровід яких було майже неможливим. У 70-их з'явилися методології, що включають ряд методів або технік для виконання основних функцій розробки проекту. Таблиця 1 демонструє важливість використання методологій розробки.
Таблиця 1. Відсутність і використання методології розробки
| Етап розробки | Відсутність методології | Традиційні методології |
| Системний аналіз | Специфікації користувача формуються в неформальних обговореннях і супроводжуються непослідовними коментарями | Формальний і структурований процес формування ясних точних специфікацій |
| Програмування |
Мистецтво Програми неструктуровані, написані на складному заплутаному коді (спагеті коді) Спагеті код (Spaghetti code) - неструктурований, незрозумілий програмний код із заплутаною логікою, що метафорично нагаду горщик звареної спагеті. |
Технологія створення програм Якісні, структуровані, написані на зрозумілому код програми |
| Супровід | Негнучкі системи, супровід яких практично неможливо | Прості для розуміння і підтримки системи |
Концепція традиційних методологій розробки
Традиційн методології виходять з парадигми: інформаційна система містить два типи сутностей:
· деякий аналог програми - операційн сутності, що виконують деяку обробку;
· дані - пасивні сутності, що зберігають інформацію, доступну для пошуку, читання і заміни.
В основі традиційних методологій лежить структурний підхід, відповідно до якого при розробці системи виконується функціональна (алгоритмічна) декомпозиція по методу «зверху вниз» – системи розбиваються на складові частини, кожна з яких розглядається окремо від інших, декомпозиція виконується доти поки не буде досягнутий необхідний рівень деталізації.
Основні характеристики традиційних методологій розробки
Основн характеристики традиційних методологій представлені в таблиці 2.
Таблиця 2.
Характеристики традиційних методологій розробки
| Характеристика | Опис |
| Структурні | Методи є інструкціями, що ретельно складений, часто крок за кроком, причому кожен крок формується на підставі попередніх. |
| Підхід «зверху вниз» | Рухаються в напрямку від самого найбільш високого абстрактного рівня до найнижчого рівня деталізації. |
| Орієнтація на процес |
Більше орієнтовані на процес, чим на дані. Центр методологій – обробка даних, а не самі дані. Опису даних - частина методів |
| Лінійність | Кожна фаза повинна бути закінчена перш, ніж буде почата наступна. |
| Багаторічне використання |
Використовувалися для розробки великого числа систем у плині декількох десятиліть. Багато існуючих систем були розроблені з їх використанням. |
| Домінування | Незважаючи на зростаючий інтерес до інших методологій, сьогодні вони залишаються домінуючим методологічним підходом. |
Методологія структурної розробки або структурний підхід виділяють у традиційних методологіях:
· Структурний аналіз.
· Структурне проектування.
· Структурне програмування.
2.5.2. Структурний аналіз
Структурний аналіз (Structured analysis) - метод визначення введень, процесів і висновків системи і розподіли систем на підсистеми або модулі, що показують логічну графічну модель потоку інформації.
Структурний аналіз - широко використовуваний метод визначення введень, процесів і висновків системи і розчленовування систем на підсистеми. Структурний аналіз надзвичайно наочний метод, що покладається головним чином на діаграми, а не на описовий текст. Його основний інструмент діаграми, що формують графічне представлення складених процесів системи й нтерфейсів між ними.
Структурний аналіз пропонує логічну графічну модель потоку інформації, поділяючи системи на модулі, що показують рівні, що піддаються керуванню, деталізації.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
