176715 (685577), страница 9
Текст из файла (страница 9)
Поділ відповідальності між розроблювачами і кінцевими користувачами:
Технічні фахівці: системні аналитики і програмісти відповідальні за проведення системного аналізу, проектування і робіт з реалізації;
Кінцеві користувачі відповідальні за забезпечення інформаційних вимог і експертизу роботи технічного персоналу.
По завершенню кожного етапу потрібні формальні висновки або угоди між кінцевими користувачами і технічними фахівцями.
Рис. 1. показує результати кожної стадії життєвого циклу, що є підставами для формального висновку.
Рис. 1. Методологія життєвого циклу
У таблиці 3. представлено детальної опис кожної стадії життєвого циклу системи.
Таблиця 3.
Стадії життєвого циклу систем
| Стадія | Роботи | Опис |
| Опис проекту | Визначення проблеми | |
| Аналіз можливості рішення проблеми створенням нової інформаційної системи або зміною існуючої. | "Чому необхідний проект нової системи?" | |
| Визначення загальних цілей, області проекту. | "Що необхідно досягти?". | |
| Розробка плану проекту, що може бути показаний керуванню | Пропозиція на розробку нової системи. | |
| Аналіз систем | Аналіз проблеми існуючих систем (ручних або автоматизованих) | "Что существующие системы делают?" "Які їхні достоїнства, недоліки, гарячі крапки і проблеми?" |
| Ідентифікація цілей, що будуть досягнуті рішенням для цих проблем | ||
| Опис альтернативних рішень | "Какие возможны альтернативные варианты решения?" "Їхні витрати і вигоди?" | |
| Дослідження реализуемости кожного варіанта рішення для експертизи керуванням | ||
| Збір докладної інформації і глибоке дослідження | ||
| Докладний аналіз документів, звітів і робочих паперів, зроблених існуючими системами | ||
| Спостереження за роботою системи | ||
| Опитування користувачів за допомогою опитувальних аркушів | ||
| Проведення інтерв'ю. Определение требований к информационной системе | "Які інформаційні вимоги користувача повинні бути виконані цим рішенням?" | |
| Докладний опис інших дій життєвого циклу і задач кожної фази | ||
| Деталізований звіт за системною пропозицією, що виділяє альтернативні рішення й оцінку реализуемости запропонованих рішень. | ||
| Проектування | Створення логічних і фізичних проектних специфікацій рішення. | |
| Використання інструментальних засобів проектування і документування проектів: діаграми потоку даних, діаграми структури програми, блок-схеми системи, таблиці рішень або дерево рішень і т.д. Звіт по проектних специфікаціях системного рішення, що обрано. | ||
| Програмування | Переклад специфікацій проекту, створених на стадії проектування в код програми: | |
| Підготовка специфікацій кожної програми системи системними аналітиками разом із програмістами | Специфікації програми: опис задач програми, тип мови програмування, введення і висновки, логические схемы обработки информации, процеси обробки й оператори керування типу упорядочивания вхідних даних. | |
| Написання програмістами у відповідності зі специфікаціями коду програм Фактичний код програмного забезпечення системи. | Для створення великих систем, що мають багато програм із сотнями тисяч рядків програмного коду, можуть знадобитися цілі команди програмістів | |
| Установка | Фінальні кроки по введенню нової або модифікованої системи в роботу: | |
| Тестування | Перевірка правильності роботи з технічної і функціональної точки зору бізнесу. | |
| Навчання | Фахівці в області бізнесу і технічних фахівців навчаються використовувати нову систему | |
| Перетворення | Формальний план перетворення містить деталізований розпорядок усіх дій, необхідних для установки нової системи, і перетворення старої системи в нову систему. | |
| Результати тестів для оцінки ефективності системи | ||
| Посада реалізація | Використання й оцінка системи користувачами і технічними фахівцями після того, як вона була встановлена і знаходиться в експлуатації. | Формальна ревізія, що визначає, на скількох добре нових систем виконує первісні цілі, і потрібні чи виправлення або зміни |
| Модифікування для удосконалення системи | ||
| Настроювання системи | ||
| Супровід системи | Виправлення помилок. Реализация новых требований. Поліпшення ефективності обробки. | |
| Завершення корисного життєвого циклу | Система вимагає дуже багато витрат на супровід для підвищення ефективності і реалізації нових цілей користувача | |
| Як тільки життєвий цикл системи закінчується, потрібно цілком нова система, і цикл може початися знову. | ||
Достоїнства підходу життєвого циклу
Підхід життєвого циклу використовується:
Для формування великих систем обробки транзакций (TPS) і інформаційних систем керування (MIS), де вимоги сильно структуровані і гарне визначені.
Для складних технічних систем типу запуску космічних кораблів, керування повітряним рухом і переробкою нафти, де необхідний строгий і формальний аналіз вимог, визначені специфікації і тверді засоби керування над процесом створення систем.
Обмеження підходу життєвого циклу
Однак методологія життєвого циклу систем має серйозні обмеження і не дуже добре підходить для більшості маленьких настільних систем, що будуть переважати в двадцять перших сторіч. Основні обмеження підходу життєвого циклу представлені в таблиці 4. Деякі з цих обмежень можуть бути вирішені альтернативними стратегіями створення систем.
Таблиця 4.
Обмеження життєвого циклу
| Обмеження | Опис |
| Дуже дорогий і трудомісткий | Дуже багато часу необхідно для нагромадження інформації і підготовки об'ємних специфікацій і документів приймання. Можуть пройти роки перш, ніж система буде остаточно встановлена. При занадто великому часі розробки інформаційні вимоги можуть змінитися перш, ніж система буде впроваджена. Система, що вимагає багато років і грошей для створення, може застаріти, поки вона буде ще на креслярській дошці. |
| Негнучкий і утрудняє зміни | Передбачає перевірки системи для гарантії того, що вимога виконана. Коли вимоги неправильні або виникають помилки, повинна бути повторена послідовність дій життєвого циклу, що приводить до збільшення часу і витрат. Заохочує заморожування специфікацій на ранніх етапах процесу розробки, що виключає можливість змін. Користувачі утрудняються чітко представити фінальну систему по документах специфікації і ставлять підпису на документах специфікації без повного розуміння їхнього змісту, тільки протягом програмування і тестування довідаються, що специфікації неповні, роблять не те, що вони мали на увазі. Коректні специфікації не завжди можуть бути визначені відразу і досить рано, коли вони легко можуть бути змінені |
| Погано підходить для додатків орієнтованих на рішення. | Прийняття рішень може бути занадто неструктурованим і нечітким. Вимоги можуть постійно мінятися, або рішення не можуть мати чітких моделей або процедур. Особи, що приймають рішення, часто не можуть заздалегідь визначити свої інформаційні потреби, і змушені експериментувати з конкретними системами, щоб роз'яснити види рішень, що вони бажають робити. Високий рівень невизначеності не може бути легко погоджений з підходом життєвого циклу. |
2.5. Структурний аналіз.
2.5.1. Традиційні методології розробки.
На зорі програмування існувало небагато методологій. Відсутність методологій приводило до створення складних, негнучких, ненадійних систем, супровід яких було майже неможливим. У 70-их з'явилися методології, що включають ряд методів або технік для виконання основних функцій розробки проекту. Таблиця 1 демонструє важливість використання методологій розробки.
Таблиця 1. Відсутність і використання методології розробки
| Етап розробки | Відсутність методології | Традиційні методології |
| Системний аналіз | Специфікації користувача формуються в неформальних обговореннях і супроводжуються непослідовними коментарями | Формальний і структурований процес формування ясних і точних специфікацій |
| Програмування | Мистецтво Програми неструктуровані, написані на складному і заплутаному коді (спагеті коді) Спагеті код (Spaghetti code) - неструктурований, незрозумілий програмний код із заплутаною логікою, що метафорично нагадує горщик звареної спагеті. | Технологія створення програм Якісні, структуровані, написані на зрозумілому коді програми |
| Супровід | Негнучкі системи, супровід яких практично неможливо | Прості для розуміння і підтримки системи |
Концепція традиційних методологій розробки
Традиційні методології виходять з парадигми: інформаційна система містить два типи сутностей:
-
деякий аналог програми - операційні сутності, що виконують деяку обробку;
-
дані - пасивні сутності, що зберігають інформацію, доступну для пошуку, читання і заміни.
В основі традиційних методологій лежить структурний підхід, відповідно до якого при розробці системи виконується функціональна (алгоритмічна) декомпозиція по методу «зверху вниз» – системи розбиваються на складові частини, кожна з яких розглядається окремо від інших, декомпозиція виконується доти поки не буде досягнутий необхідний рівень деталізації.
Основні характеристики традиційних методологій розробки
Основні характеристики традиційних методологій представлені в таблиці 2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
