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