Информационные системы. Два типа интеграционных свойств. Причины эволюции систем, страница 2

Метод реинжиниринга бизнес-процессов BPR требует построить и проанализировать диаграммы потоков работ для подсчета времени, ресурсов, финансовых средств, необходимых для этих видов деятельности. Подход сочетает эффективность от реорганизации бизнес-деятельности путем перехода от иерархических структур к горизонтальным связям и продуктивности от применения ИТ.

Отличие подхода ISA, состоит в применении унифицированной схемы для проектирования архитектуры информационных систем. Схема позволяет получить полное описание ИС в виде таблицы, имеющей 5 строк и 6 столбцов. Строки представляют точки зрения участников: планировщик (определяет границы системы), владелец (определяет концептуальную модель предприятия), проектировщик (задает физическую модель ИС), конструктор (представляет детализированное решение), субподрядчик (поставляет компоненты ИС). Столбцы являются описаниями: Что составляет сущность (данные); Как сущность функционирует (бизнес-процессы); Где сущность расположена (расположение обрабатывающих компонентов); Кто работает с сущностью (пользователи); Когда с сущностью что-то происходит (распределение событий и состояний во времени); Почему сущность существует (мотивация предприятия). Полученное описание можно использовать для адаптации ИС к будущим изменениям.

ИС строят для трех уровней управления: стратегического, тактического и оперативного. Для оперативного управления применяют типовые ИТ-решения: базы данных, обработка транзакций, генераторы приложений. Для тактического – хранилища данных, анализ данных. Для стратегического – добыча знаний, управление знаниями.

Базы данных бесперспективны с точки зрения обеспечения конкурентных преимуществ, они организуют надлежащее функционирование организации. Основная технология, применяемая для принятия стратегических и тактических решений, - хранилища данных.

Этапы жизненного цикла программного обеспечения

Жизненный цикл (ЖЦ) – набор видов деятельности, осуществляемый в рамках каждого проекта по разработке ПО. Укрупнено: Анализ (определение и специфицирование системных требований, фиксация нефункциональных требований, ограничений), Проектирование (разработка архитектуры системы, детальное описание подсистем), Реализация (написание программного кода).

Детализированное представление ЖЦ:

1. Установление требований.

2. Спецификация требований.

3. Проектирование архитектуры.

4. Детализированное проектирование.

5. Реализация.

6. Интеграция.

7. Сопровождение.

Иногда выделяют дополнительные этапы: планирование, тестирование.

1. Установление требований

Требование – формулировка сути системного сервиса или ограничения.

Формулировка сути сервиса характеризует поведение системы по отношению к пользователям. Служит определением бизнес-правила, может быть связана с некоторым вычислением.

Формулировка ограничения выражает ограничивающее условие на поведение системы или ее разработку.

На этапе осуществляется определение, анализ и обсуждение требований с заказчиками. Применяются различные методы сбора информации: интервью, анкеты, изучение документов и форм, видеозаписи и др. Чтобы прояснить требования, вызывающие затруднения, иногда применяется быстрая разработка прототипа. Переговоры между разработчиками и заказчиками позволяют исключить противоречивые и дублирующие требования, согласовать бюджет проекта и сроки.

Требования документируются в виде текстового документа, который может содержать диаграммы и таблицы. Описание требований на этом этапе носит неформализованный характер, чтобы упростить взаимопонимание разработчиков и заказчиков.

2. Специфицирование требований

Выполняется описание требование в рамках некоторой формальной модели, например, на языке UML. Для построения, анализа и документирования модели требований часто применяются CASE-средства.

Неформальное текстовое описание требований дополняется графическими моделями и отчетами, сгенерированными CASE-инструментом. Формализованный документ называют спецификацией требований.

В случае применения UML составляются диаграммы двух типов: диаграммы классов и диаграммы прецедентов. Они позволяют специфицировать данные и функции. Спецификация может содержать и другие виды требований. Рекомендуется не включать в спецификацию описание программной и аппаратной платформ, за исключением случаев, когда это предписано ограничениями.