"Що необхідно досягти?".
Розробка плану проекту, що може бути показаний керуванню
Пропозиція на розробку нової системи.
Аналіз систем
Аналіз проблеми існуючих систем (ручних або автоматизованих)
"Что существующие системы делают?"
"Які їхні достоїнства, недоліки, гарячі крапки і проблеми?"
Ідентифікація цілей, що будуть досягнуті рішенням для цих проблем
Опис альтернативних рішень
"Какие возможны альтернативные варианты решения?"
"Їхні витрати і вигоди?"
Дослідження реализуемости кожного варіанта рішення для експертизи керуванням
Збір докладної інформації і глибоке дослідження
Докладний аналіз документів, звітів і робочих паперів, зроблених існуючими системами
Спостереження за роботою системи
Опитування користувачів за допомогою опитувальних аркушів
Проведення інтерв'ю. Определение требований к информационной системе
"Які інформаційні вимоги користувача повинні бути виконані цим рішенням?"
Докладний опис інших дій життєвого циклу і задач кожної фази
Деталізований звіт за системною пропозицією, що виділяє альтернативні рішення й оцінку реализуемости запропонованих рішень.
Проектування
Створення логічних і фізичних проектних специфікацій рішення.
Використання інструментальних засобів проектування і документування проектів:
діаграми потоку даних,
діаграми структури програми,
блок-схеми системи,
таблиці рішень або дерево рішень і т.д.
Звіт по проектних специфікаціях системного рішення, що обрано.
Програмування
Переклад специфікацій проекту, створених на стадії проектування в код програми:
Підготовка специфікацій кожної програми системи системними аналітиками разом із програмістами
Специфікації програми:
опис задач програми,
тип мови програмування,
введення і висновки,
логические схемы обработки информации,
процеси обробки й оператори керування типу упорядочивания вхідних даних.
Написання програмістами у відповідності зі специфікаціями коду програм
Фактичний код програмного забезпечення системи.
Для створення великих систем, що мають багато програм із сотнями тисяч рядків програмного коду, можуть знадобитися цілі команди програмістів
Установка
Фінальні кроки по введенню нової або модифікованої системи в роботу:
Тестування
Перевірка правильності роботи з технічної і функціональної точки зору бізнесу.
Навчання
Фахівці в області бізнесу і технічних фахівців навчаються використовувати нову систему
Перетворення
Формальний план перетворення містить деталізований розпорядок усіх дій, необхідних для установки нової системи, і перетворення старої системи в нову систему.
Результати тестів для оцінки ефективності системи
Посада реалізація
Використання й оцінка системи користувачами і технічними фахівцями після того, як вона була встановлена і знаходиться в експлуатації.
Формальна ревізія, що визначає, на скількох добре нових систем виконує первісні цілі, і потрібні чи виправлення або зміни
Модифікування для удосконалення системи
Настроювання системи
Супровід системи
Виправлення помилок.
Реализация новых требований.
Поліпшення ефективності обробки.
Завершення корисного життєвого циклу
Система вимагає дуже багато витрат на супровід для підвищення ефективності і реалізації нових цілей користувача
Як тільки життєвий цикл системи закінчується, потрібно цілком нова система, і цикл може початися знову.
Достоїнства підходу життєвого циклу
Підхід життєвого циклу використовується:
Для формування великих систем обробки транзакций (TPS) і інформаційних систем керування (MIS), де вимоги сильно структуровані і гарне визначені.
Для складних технічних систем типу запуску космічних кораблів, керування повітряним рухом і переробкою нафти, де необхідний строгий і формальний аналіз вимог, визначені специфікації і тверді засоби керування над процесом створення систем.
Обмеження підходу життєвого циклу
Однак методологія життєвого циклу систем має серйозні обмеження і не дуже добре підходить для більшості маленьких настільних систем, що будуть переважати в двадцять перших сторіч. Основні обмеження підходу життєвого циклу представлені в таблиці 4. Деякі з цих обмежень можуть бути вирішені альтернативними стратегіями створення систем.
Таблиця 4.
Обмеження життєвого циклу
Обмеження
Опис
Дуже дорогий і трудомісткий
Дуже багато часу необхідно для нагромадження інформації і підготовки об'ємних специфікацій і документів приймання.
Можуть пройти роки перш, ніж система буде остаточно встановлена.
При занадто великому часі розробки інформаційні вимоги можуть змінитися перш, ніж система буде впроваджена.
Система, що вимагає багато років і грошей для створення, може застаріти, поки вона буде ще на креслярській дошці.
Негнучкий і утрудняє зміни
Передбачає перевірки системи для гарантії того, що вимога виконана.
Коли вимоги неправильні або виникають помилки, повинна бути повторена послідовність дій життєвого циклу, що приводить до збільшення часу і витрат.
Заохочує заморожування специфікацій на ранніх етапах процесу розробки, що виключає можливість змін.
Користувачі утрудняються чітко представити фінальну систему по документах специфікації і ставлять підпису на документах специфікації без повного розуміння їхнього змісту, тільки протягом програмування і тестування довідаються, що специфікації неповні, роблять не те, що вони мали на увазі.
Коректні специфікації не завжди можуть бути визначені відразу і досить рано, коли вони легко можуть бути змінені
Погано підходить для додатків орієнтованих на рішення.
Прийняття рішень може бути занадто неструктурованим і нечітким.
Вимоги можуть постійно мінятися, або рішення не можуть мати чітких моделей або процедур.
Особи, що приймають рішення, часто не можуть заздалегідь визначити свої інформаційні потреби, і змушені експериментувати з конкретними системами, щоб роз'яснити види рішень, що вони бажають робити.
Високий рівень невизначеності не може бути легко погоджений з підходом життєвого циклу.
2.5. Структурний аналіз
2.5.1. Традиційні методології розробки
На зорі програмування існувало небагато методологій. Відсутність методологій приводило до створення складних, негнучких, ненадійних систем, супровід яких було майже неможливим. У 70-их з'явилися методології, що включають ряд методів або технік для виконання основних функцій розробки проекту. Таблиця 1 демонструє важливість використання методологій розробки.
Таблиця 1.
Відсутність і використання методології розробки
Етап розробки
Відсутність методології
Традиційні методології
Системний аналіз
Специфікації користувача формуються в неформальних обговореннях і супроводжуються непослідовними коментарями
Формальний і структурований процес формування ясних і точних специфікацій
Програмування
· Мистецтво
· Програми неструктуровані, написані на складному і заплутаному коді (спагеті коді)
· Спагеті код (Spaghetti code) - неструктурований, незрозумілий програмний код із заплутаною логікою, що метафорично нагадує горщик звареної спагеті.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
