Життєвий цикл систем самий старий метод створення інформаційних систем і усе ще сьогодні використовується для середніх або великих складних проектів систем.
Життєвий цикл систем - формальний підхід до створення систем, що припускає, що інформаційна система має життєвий цикл подібно будь-якому живому організмові: з початком, серединою і кінцем і розділяє процес розробки систем на різні стадії і формує інформаційну систему послідовно, стадія за стадією.
Методологія життєвого циклу також має формальний поділ праці між кінцевими користувачами і фахівцями інформаційними систем.
Поділ відповідальності між розроблювачами і кінцевими користувачами:
Технічні фахівці: системні аналитики і програмісти відповідальні за проведення системного аналізу, проектування і робіт з реалізації;
Кінцеві користувачі відповідальні за забезпечення інформаційних вимог і експертизу роботи технічного персоналу.
По завершенню кожного етапу потрібні формальні висновки або угоди між кінцевими користувачами і технічними фахівцями.
Рис. 1. показує результати кожної стадії життєвого циклу, що є підставами для формального висновку.
Рис. 1. Методологія життєвого циклу
У таблиці 3. представлено детальної опис кожної стадії життєвого циклу системи.
Таблиця 3.
Стадії життєвого циклу систем
Стадія | Роботи | Опис |
Опис проекту | Визначення проблеми | |
Аналіз можливості рішення проблеми створенням нової інформаційної системи або зміною існуючої. | "Чому необхідний проект нової системи?" | |
Визначення загальних цілей, області проекту. | "Що необхідно досягти?". | |
Розробка плану проекту, що може бути показаний керуванню | Пропозиція на розробку нової системи. | |
Аналіз систем | Аналіз проблеми існуючих систем (ручних або автоматизованих) | "Что существующие системы делают?" "Які їхні достоїнства, недоліки, гарячі крапки і проблеми?" |
Ідентифікація цілей, що будуть досягнуті рішенням для цих проблем | ||
Опис альтернативних рішень | "Какие возможны альтернативные варианты решения?" "Їхні витрати і вигоди?" | |
Дослідження реализуемости кожного варіанта рішення для експертизи керуванням | ||
Збір докладної інформації і глибоке дослідження | ||
Докладний аналіз документів, звітів і робочих паперів, зроблених існуючими системами | ||
Спостереження за роботою системи | ||
Опитування користувачів за допомогою опитувальних аркушів | ||
Проведення інтерв'ю. Определение требований к информационной системе | "Які інформаційні вимоги користувача повинні бути виконані цим рішенням?" | |
Докладний опис інших дій життєвого циклу і задач кожної фази | ||
Деталізований звіт за системною пропозицією, що виділяє альтернативні рішення й оцінку реализуемости запропонованих рішень. | ||
Проектування | Створення логічних і фізичних проектних специфікацій рішення. | |
Використання інструментальних засобів проектування і документування проектів: діаграми потоку даних, діаграми структури програми, блок-схеми системи, таблиці рішень або дерево рішень і т.д. Звіт по проектних специфікаціях системного рішення, що обрано. | ||
Програмування | Переклад специфікацій проекту, створених на стадії проектування в код програми: | |
Підготовка специфікацій кожної програми системи системними аналітиками разом із програмістами | Специфікації програми: опис задач програми, тип мови програмування, введення і висновки, логические схемы обработки информации, процеси обробки й оператори керування типу упорядочивания вхідних даних. | |
Написання програмістами у відповідності зі специфікаціями коду програм Фактичний код програмного забезпечення системи. | Для створення великих систем, що мають багато програм із сотнями тисяч рядків програмного коду, можуть знадобитися цілі команди програмістів | |
Установка | Фінальні кроки по введенню нової або модифікованої системи в роботу: | |
Тестування | Перевірка правильності роботи з технічної і функціональної точки зору бізнесу. | |
Навчання | Фахівці в області бізнесу і технічних фахівців навчаються використовувати нову систему | |
Перетворення | Формальний план перетворення містить деталізований розпорядок усіх дій, необхідних для установки нової системи, і перетворення старої системи в нову систему. | |
Результати тестів для оцінки ефективності системи | ||
Посада реалізація | Використання й оцінка системи користувачами і технічними фахівцями після того, як вона була встановлена і знаходиться в експлуатації. | Формальна ревізія, що визначає, на скількох добре нових систем виконує первісні цілі, і потрібні чи виправлення або зміни |
Модифікування для удосконалення системи | ||
Настроювання системи | ||
Супровід системи | Виправлення помилок. Реализация новых требований. Поліпшення ефективності обробки. | |
Завершення корисного життєвого циклу | Система вимагає дуже багато витрат на супровід для підвищення ефективності і реалізації нових цілей користувача | |
Як тільки життєвий цикл системи закінчується, потрібно цілком нова система, і цикл може початися знову. |
Достоїнства підходу життєвого циклу
Підхід життєвого циклу використовується:
Для формування великих систем обробки транзакций (TPS) і інформаційних систем керування (MIS), де вимоги сильно структуровані і гарне визначені.
Для складних технічних систем типу запуску космічних кораблів, керування повітряним рухом і переробкою нафти, де необхідний строгий і формальний аналіз вимог, визначені специфікації і тверді засоби керування над процесом створення систем.
Обмеження підходу життєвого циклу
Однак методологія життєвого циклу систем має серйозні обмеження і не дуже добре підходить для більшості маленьких настільних систем, що будуть переважати в двадцять перших сторіч. Основні обмеження підходу життєвого циклу представлені в таблиці 4. Деякі з цих обмежень можуть бути вирішені альтернативними стратегіями створення систем.
Таблиця 4.
Обмеження життєвого циклу
Обмеження | Опис |
Дуже дорогий і трудомісткий | Дуже багато часу необхідно для нагромадження інформації і підготовки об'ємних специфікацій і документів приймання. Можуть пройти роки перш, ніж система буде остаточно встановлена. При занадто великому часі розробки інформаційні вимоги можуть змінитися перш, ніж система буде впроваджена. Система, що вимагає багато років і грошей для створення, може застаріти, поки вона буде ще на креслярській дошці. |
Негнучкий і утрудняє зміни | Передбачає перевірки системи для гарантії того, що вимога виконана. Коли вимоги неправильні або виникають помилки, повинна бути повторена послідовність дій життєвого циклу, що приводить до збільшення часу і витрат. Заохочує заморожування специфікацій на ранніх етапах процесу розробки, що виключає можливість змін. Користувачі утрудняються чітко представити фінальну систему по документах специфікації і ставлять підпису на документах специфікації без повного розуміння їхнього змісту, тільки протягом програмування і тестування довідаються, що специфікації неповні, роблять не те, що вони мали на увазі. Коректні специфікації не завжди можуть бути визначені відразу і досить рано, коли вони легко можуть бути змінені |
Погано підходить для додатків орієнтованих на рішення. | Прийняття рішень може бути занадто неструктурованим і нечітким. Вимоги можуть постійно мінятися, або рішення не можуть мати чітких моделей або процедур. Особи, що приймають рішення, часто не можуть заздалегідь визначити свої інформаційні потреби, і змушені експериментувати з конкретними системами, щоб роз'яснити види рішень, що вони бажають робити. Високий рівень невизначеності не може бути легко погоджений з підходом життєвого циклу. |
2.5. Структурний аналіз.