Системный анализ и проектирование системы автоматизации

1. Системный анализ предметной области и требований

и концептуальное
проектирование системы
автоматизации

2. План изучения дисциплины

• Процессы программного
обеспечения
Анализ требований
Проектирование
Кодирование и Испытания
Системная инженерия
Управляющие и
поддерживающие процессы

3.

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

4.

5.

Группы
процессов
жизненного
цикла
из «ГОСТ Р
ИСО/МЭК 122072010
Информационная
технология.
Системная и
программная
инженерия.
Процессы
жизненного цикла
программных
средств»

6. Технические процессы ИСО12207-2010

Каждый из процессов жизненного цикла описывается в
терминах цели и желаемых выходов, списков действий и
задач, которые необходимо выполнять для достижения
этих результатов.
Технические процессы
• Процесс определения требований правообладателей
• Процесс анализа системных требований
• Процесс проектирования архитектуры системы
• Процесс реализации
Цель процесса реализации заключается в создании заданных элементов системы.
Примечание - Пользователи настоящего стандарта могут иметь намерение работать с
программными продуктами или программными элементами больших систем. Процесс
реализации программных средств (см. 7.1.1) является соответствующим примером
процесса реализации в [18], приспособленного к частным потребностям реализации
программного продукта или услуги.
• Процесс комплексирования системы
•…

7. Стадии информационной технологии

Усложнение деловых связей и
рост объемов информации,
которыми сопровождается
деятельность современных
организаций, привели к
широкому распространению
информационных систем и
информационных технологий –
информационной инженерии.

8.

Анализ требований к ПС
Инже
нерия
требова
ний к
системе
Функции
пользо
вателей;
бизнесправила
Функции ПС; сценарии
Оценивание и
уточнение
требований
Моделирование
Функции ПС; требований
сценарии
ДСО, ДПСС и др.
модели ПС
Документ (со
спецификацией
требований и
Проектирование
моделями ПС)
Специи
-фици
рова
ние
требо
ваний
Документ (со
спецификацией
требований и
моделями ПС)
(design)
Подготовка
тестовых наборов
Подготовка
документации для
пользователя
коди
ров-е
тести
рова
ние

9. инженерия требований к системе

Процесс установления услуг, которые должна обеспечить
вычислительная система, и ограничений, с которыми она должна
функционировать, называется инженерия требований к
системе \ системный анализ \ системная инженерия \
системно-стратегическое исследование и планирование.
Инженерия требований к системе выполняется со следующими
целями:
(1) идентифицировать потребности заказчика;
(2) ввести программное обеспечение в его окружение (контекст),
чтобы точно определить роль программного обеспечения ЭВМ в
некотором контексте и установить связи программного обеспечения с
другими частями вычислительной системы;
(3) оценить концепцию системы на осуществимость и выполнить
экономический и технический анализ;
(4) распределить функции между аппаратурой, программным
обеспечением, людьми, базой данных и другими элементами системы.

10. Стратегическое информационное планирование

Процесс технологии систем начинается с уровня всей
сферы деятельности (тщательно исследуется вся
область бизнеса или продуктов, чтобы обеспечить
установление надлежащего коммерческого или
технологического контекста).
Первая стадия — это планирование
информационной стратегии (information strategy
planning).
ПСИ рассматривает полный бизнес как некоторую
сущность и выделяет области этого бизнеса
(например: инженерия, производство, маркетинг,
финансы, продажи), которые являются важными для
всего предприятия.

11. Стратегическое информационное планирование. Пример взаимодействия «областей» (учреждений) в отрасли:

12. Взаимодействие «областей» в учреждении

ПСИ определяет объекты данных, которые видимы на уровне
предприятия, и как они связаны с областями (бизнеса).

13. Стратегическое информационное планирование

На этой стадии появляется понятие "модель предметной
области" (enterprise model);
строятся:
диаграмма иерархии организации,
информационная модель предметной области,
диаграммы иерархии функций и
диаграммы зависимости этих функций.
Важно (для организации) создать структуру, которая
обеспечивала бы достаточные инфо-ресурсы для
возникновения и исследования новых идей.

14. Анализ области «бизнеса»

Вторая стадия — анализ предметной области
или сферы бизнеса (business area analysis).
АОБ занимается идентификацией деталей данных
и процессов выбранных областей бизнеса,
идентифицированных при ПСИ.
«Фокус сужается» до конкретной области бизнеса,
рассматриваемой как сущность, и выделяются функции
и процедуры бизнеса, которые дают возможность
решать соответствующие профессиональные задачи.
АОБ, подобно ПСИ, определяет объекты данных,
их связи, и как «текут» данные; специфицирует то, что
требуется в области бизнеса.

15. Анализ области бизнеса

Системный аналитик определяет модели данных и
процессов предметной области, строит логическую
модель организации и порядка использования в ней
данных.
Используются различные средства изображения
диаграмм: диаграммы действия, структурные диаграммы,
диаграммы потоков, диаграммы сущность — связь, HIPO —
диаграммы и др.
Модель предметной области объединяет структуру
организации с ее целями (стратегической программой) и
позволяет изучать возможные варианты
информационного обслуживания.
Т.о. «начальное» моделирование показывает функциональные
зависимости и связи данных, и на базе иерархической модели
организации определяет всю необходимую информацию для
достижения целей этой организации.

16.

Паспортные
данные
Деятельность
регистратора
Постоянные
признаки
жалобы
Список признаков
Ре
цеп
ты
Аптека
карта
сохраненные
записи
рецепты
Деятельность
лаборантов по
измерению
показателей
пациента
записи
паспортных
данных
новые записи
Деятельность
специалиста по
управлению
здоровьем
пациента
Измеренные
значения
признаков
Деятельность
специалиста’ по
Направить
управлению
к другому
здоровьем
специалисту
пациента
врачебные
записи
Пациент здоров
Пациент
выздоровел
Деятельность
по документированию
Отчет о
затратах
Бухгалтерия
ФОМС

17. Пример схемы задач

Схема медицинских задач

18.

Регистратор
Врач
мед сестра
Лаборатория
заполнить
Карту
пациента
обследовать
пациента
Модель
потоков
работ
заполнять ИБ
в карте
пациента
диагностировать
пациента
недостаточно
проведено
наблюдение
для точного
диагноза
достаточно для
точного
диагноза
назначить лечение
пациенту
проверить эффект
от лечения
наблюдается
процесс
выздоровления
нет
положительной
динамики
дополнять ИБ,
выписывать
рецепты и
назначения
произошло
выздоровление
оформить выписной
документ
провести
лабораторное
обследование

19. Системная инженерия. К концептуальному проектированию.

«Третья стадия»: проектировщик и аналитик
моделируют основные требования к конкретной
информационной системе и разрабатывают
концептуальные модели программной системы.
Цель концептуального проектирования:
• изучить требования бизнеса и пользователей в
соответствующем контексте;
• учесть реальные требования пользователей;
• узнать о влиянии приложения на бизнес и на пользователей;
• исключить ненужные и лучше исследовать необходимые
требования.
В процессе системного анализа выясняется, насколько
целесообразно и реализуемо "заказываемое" ПС, как
повлияет такое ПС на деятельность пользователей и
какими особенностями оно должно обладать.

20. Идентификация потребностей

Процесс установления услуг, которые должна
обеспечить вычислительная система, и ограничений, с
которыми она должна функционировать, называется
инженерия требований к системе \ системный анализ \
системно-стратегическое исследование и планирование.
Идентификация потребностей (и их анализ) –
выведение требований к системе через анализ
существующих систем, анализ планирующегося использования
создаваемой системы и обсуждение с заказчиком и
пользователями общих требований к продукту.
Источники требований (Requirement Sources):
• Цели организации (деятельности)
• Заинтересованные лица
• Знания предметной области
• Модель деятельности и операционное окружение
• Организационная среда

21. Идентификация потребностей

Общение с заказчиком:
• Аналитик (разработчик системы) встречается с заказчиком и
конечным пользователем (если он отличен от заказчика).
• Резyльтатом деятельности «анализ и обсуждение с заказчиком и
пользователями общих требований к продукту» должно быть
ясное понимание того, что тpебyет пользователь, и что он хочет.
• Это деятельность сводит вместе пользователей и разработчиков
системы, объединяя их написанием общего документа (в т.ч.
словаря предметной области).
Интервьюрирование – традиционный подход извлечения
требований; это может быть интеpактивный пpоцесс с целью
выяснить, что же пользователи хотят полyчить от пpогpаммного
пpодyкта.

22. Идентификация потребностей. Интервьюрирование. Вопросы.

Первое множество вопросов фокусирует свое внимание на
общих целях и выгодах.
Следующее множество вопросов позволяет понять
проблемы заказчика (его «ощущение решения»). Эти требования
охватывают:
необходимую информацию и управление,
функции продукта и
его поведение,
возможности системы, требования к эксплуатации,
ограничения.
Важно описать среду, в которой будет использоваться этот
пpодyкт (физическая, рыночная, организационная и культурная)
Уточнить о пользователях:
кто будет пользоваться приложением;
какова квалификация пользователей; требования
пользователей к обучению;
общие характеристики работы продукта,
требования к безопасности, защищенности; к взаимодействию с

23. Идентификация потребностей. Этнография.

Люди обычно не могут полноценно описать свою работу.
В этом им может помочь сторонний независимый наблюдатель.
Например, исследование офисной работы показало, что
реальные процедуры, используемые людьми, значительно
богаче, сложнее и динамичнее, чем процессы, навязываемые
им системами автоматизации.
Наблюдение (observation) – подразумевает
непосредственное присутствие аналитиков и инженеров рядом
с пользователем в процессе выполнения последним его работ
по обеспечению функционирования бизнес-процессов; данная
техника является достаточно затратной, но, в то же время,
очень эффективной, а иногда – просто незаменимой, особенно,
если речь идет о достаточно сложных и взаимосвязанных
бизнес-процессах.
Системный аналитик «внедряется» в будущее окружение
системы и наблюдает повседневную работу. Общая задача
этого подхода - понять социальное и организационное
окружение; при этом очень часто удается выявить неявные
требования к системе, отражающие реальные, а не
формальные процессы в системе.

24. Идентификация потребностей

Варианты использования (use-cases, use case diagram) позволяют более точно
представить разработчикам, что же должна делать система.
Они разрабатываются при активном участии потенциальных пользователей
системы.
• Часто удается выявить варианты использования, попросив клиентов описать их
рабочий процесс. Другой способ — выяснить у заказчиков, какие цели они
ставят перед собой, усаживаясь за работу. В итоге получают описание
конкретных примеров взаимодействия системы и элементов внешней среды
Модель содержит: внешние сущности или актеров или действующих лиц и
варианты (случаи) использования.
В состав диаграммы use case diagram входят:
• вариант использования (use case) - типичное взаимодействие пользователя и
системы. Оно охватывает некоторую очевидную для пользователя функцию,
решаемую дискретную задачу; определенное взаимодействие с системой.
• актер (actor) - любая внешняя по отношению к моделируемой системе
сущность, которая взаимодействует с системой и использует ее функции и
возможности; Актеры взаимодействуют с разрабатываемой системой и
выполняют определенные роли. Актерами могут быть как пользователи
(люди), так и части самой системы, которые функционируют самостоятельно,
а также машины, другие системы.

25.

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

26.

27.

28.

Внешний
пользователь
(клиент)
Устройство
чтения
считывания
карточек
запросы; вывод
ответы;
информации
выбор
клиента
Номер
сумма к
карточки Банковская
выдаче
система
информация
оператору
отчет о
транзакции
ввод от оператора
Оператор
Мед
Персонал
Результаты
Информация о
диагностике и помощь в лаб исслед-й
лечении диагностике
Врач
и лечении
Карточка
пациента
Медицинская
система
Информация поддержки
О пациенте деятельности
Направления,
рецепты
Информация о
диагностике и
лечении
Устройство
печати
направлений
и рецептов
Карточка
пациента
Устройство
Выдачи
наличных
Устройство
Печати
чеков

29. Проектирование системной архитектуры

Данная работа состоит из следующих задач, которые разработчик
должен выполнить или обеспечить их выполнение:
5.3.3.1 Должна быть определена общая архитектуры системы
(архитектура верхнего уровня). В архитектуре должны быть указаны
объекты технических и программных средств и ручных операций- Должно
быть обеспечено распределение всех требований к системе между
объектами архитектуры. Затем должны быть определены объекты
конфигурации технических и программных средств и ручных операций на
основе объектов архитектуры. Должна быть документально оформлена
привязка системной архитектуры и требований к системе относительно
установленных объектов.
5.3.3.2 Системная архитектура и требования к объектам архитектуры
должны быть оценены с учетом следующих критериев (при этом
результаты оценок должны быть документально оформлены):
• a) учет требований к системе;
• b) соответствие требованиям к системе;
• c) соответствие используемых стандартов и методов проектирования;
• d) возможность программных объектов архитектуры выполнять
установленные для них требования;
• e) возможности эксплуатации и сопровождения.

30. Проектирование архитектуры системы

– установление высокоуровневой архитектуры системы,
идентифицирующей конкретные оборудование, ПО, “данные” (или
базы данных) и “людей”, в которой все требования к системе
распределены между этими компонентами вычислительной
системы.
Цель: распределить функции между аппаратурой, программным
обеспечением, людьми, базой данных и другими элементами
системы.
Компоненты конфигурации оборудования, компоненты конфигурации
ПО и ручные операции последовательно идентифицируются из этих
компонентов.
Архитектура системы и системные требования, определенные для
этих компонентов должны документироваться.
Классы целевых систем: информационные системы (управляемые
данными) и системы реального времени (управляемые событиями).
экспертныеСистемы
Информационные системы работают с большим объемом входных
данных сложной структуры.
Системы реального времени работают с малым количеством входных
данных простой структуры.

31.

• Для графического представления всей организации системы
используются модели системной архитектуры. Блоки обычно
соответствуют основным подсистемам или компонентам, а
связи обычно соответствуют потокам данных.
• Технология систем предусматривает единый подход к
разработке моделей системы и ее компонентов (прежде
всего, для описания логической структуры) в форме
преобразования информации с использованием архитектуры
“ввод-обработка-вывод”, либо дополненного обработкой
взаимодействия с пользователем и техническим обслуживанием
и выполнением самопроверки.
• Для разработки такой модели системы используется шаблон
архитектуры (architecture template).

32.

Разработчик системы назначает элементы системы каждой
из пяти областей в шаблоне: (1) интерфейсу с пользователем,
(2) вводу, (3) функции и управлению системы, (4) выходу и (5)
техническому обслуживанию (maintanance) и самопроверке
(self–testing) (диагностический интерфейс).
Обработка интерфейса с пользователем
Обработка
входа
Функции
обработки и
управления
Обработка
выхода
Техническое
обслуживание и
самопроверка
Шаблон архитектуры [Pressman-97].

33.

Внешний
пользователь
(клиент)
Устройство
чтения
считывания
карточек
ответы;
выбор клиента
Номер
карточки
запросы; вывод информации
Банковская
система
информация
оператору
сумма к
выдаче
отчет о
транзакции
ввод от оператора
Устройство
Выдачи
наличных
Устройство
Печати
чеков
Оператор
Рис. Архитектурная контекстная диаграмма для Банковской системы

34.

Интерфейс с
клиентом
запросы;
вывод
информации
ответы;
выбор клиента
Обработка и
управление
Сумма к выдаче
Подсистема
банкомата
Ответы
банка
Номер карточки
Транзакции
банкомата
Интерфейс с
получения данных
ввод от оператора
отчет о транзакции
Подсистема
банковского
сервера
Диагностический
интерфейс
информация
оператору
Интерфейс с
выходными
устройствами

35.

Оператор
сортировочной
станции
Запрос
Устройство
чтения
штрихового
кода
Конвейерная
линия
Штриховой
код
Индикатор
скорости
линии
Вопросы и ответы
Система
сортировки
конвейерной
линии
Команды на
перемещение
Сортирующий
механизм
Сформатированные
отчетные
данные
Центральный
Диагностические
процессор
данные
Оператор
сортировочной
станции
Архитектурная контекстная диаграмма длясистемы сортировки
конвейерной линии.

36.

Интерфейс с
оператором
Подсистема
интерфейса с
оператором
Запрос оператора
Отчеты, высвечиваемая
информация
Состояние управления
перемещением
Обработка и
Запрос отчета
управление ССКЛ
Отчеты
Подсистема декодирования
штрихового кода
Контроллер
перемещения
Номер ящика
Штриховой код
"место ящика"
Команды на
перемещение
Скорость конвейера
Подсистема
получения
данных от
датчиков
Подсистема
доступа к БД
ключ
Подсистема
формирования
отчетов
Информация от датчиков
прикосновения
Интерфейс с Данные о штрих-коде Подсистема
диагностики
получения данных
Состояние устройства перемещения
Состояние датчиков
Диагностический
интерфейс
Интерфейс с
выходными
устройствами

37.

Мед
Персонал
Результаты
Информация о
диагностике и помощь в лаб исслед-й
лечении диагностике
Врач
и лечении
Карточка
пациента
Медицинская
система
Информация поддержки
О пациенте деятельности
Направления,
рецепты
Информация о
диагностике и
лечении
Устройство
печати
направлений
и рецептов
Карточка
пациента
Важно ввести программное обеспечение в его окружение
(контекст), чтобы точно определить роль программного
обеспечения ЭВМ и установить его связи с другими
частями вычислительной системы

38. Пример концептуальной архитектуры

врач
Обоснование списка
важных признаков
Решатель
обследования
объяснение
диагноза
Признаки
и значения
диагноз
Решатель
диагностики
объяснение
лечения
Метод
лечения
рекомендации по
необходимости коррекции
объяснение
прогноза
изменения
признаков
Направления на
обследования
Направления и
рецепты
Решатель
лечения
Редактор истории болезни
Решатель прогноза
выздоровления
Направления на обследования
прогноз изменения
признаков
ИБ
пациента
Знания о воздействиях
лечебных
мероприятий
Решатель мониторинга
и контроля состояния
Паспортные данные,
постоянные признаки,
Знания о
клинических
проявлениях
особенности,
результаты обследований
Мед персонал
Схема взаимодействия решателей медицинских задач

39.

В общем случае следует попытаться разложить
систему на части так, чтобы архитектура была как
можно проще (не более 7 основных объектов).
Структурный элемент может быть подсистемой,
процессом, библиотекой, базой данных, системой в
традиционном смысле, вычислительным узлом,
готовым продуктом и так далее.
Обычно, выделяя подсистему, акцентируют внимание на
выполняемых функциях, а позже решается вопрос, будет
ли она реализована аппаратно или программно (на основе
таких факторов как время, наличие на рынке подходящих
готовых устройств).

40.

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

41. Проектирование архитектуры системы. Логическая декомпозиция

Архитектура может соответствовать некоторому
архитектурному стилю

42.

43.

44.

45.

Клиент-серверная архитектура

46.

Трехуровневая модель

47.

48.

Программный комплекс "Рубежменеджер" для управления
техническими средствами охраны

49.

Решатель
Схема обобщенной
экспертной системы
Интерфейс
пользователя
База
знаний
Редактор базы
знаний
Подсистема
объяснений
Пользовательь
Инженер/Эксперт

50.

51. Проектирование архитектуры системы. Физическая декомпозиция

После декомпозиции на функциональные компоненты
для программных систем (с учетом необходимости
создания хранилищ информации)
важно учесть или продумать необходимость
и возможность использования ресурсов
<одной или нескольких> ЭВМ (<множества
процессоров>), периферийных устройств,
централизации или распределения
ресурсов; необходимость одного или многих
рабочих мест пользователей…

52. Диаграммы реализации

Для физического представления моделей
систем используются диаграммы
реализации (implementation diagrams),
которые включают в себя диаграмму
компонентов и диаграмму
развертывания.
При разработке диаграмм компонентов
преследуются цель: спецификация
исполнимого варианта системы.

53. Диаграмма компонентов

Диаграмма компонентов — это модульное представление
компьютерной системы. Компоненты определяют
функциональность программной системы.
На диаграмму компонентов наносятся взаимосвязи между
компонентами. Для этой цели можно использовать различные виды
графического изображения компонентов.
Зависимости могут
отражать наличие в
компоненте описаний
классов, которые
используются в (зависимом)
компоненте для создания
соответствующих объектов,
связи модулей
программы на этапе
компиляции и генерации
объектного кода.

54.

55. диаграмма размещения (развертывания)

• Диаграмма размещения применяется для представления
общей конфигурации и топологии распределенной
информационной системы, содержит сведения о
распределении компонентов, существующих на этапе ее
исполнения (исполнимые файлы, динамические библиотеки,
таблицы БД и т.д.) по отдельным узлам системы и «каналы
связи» между аппаратными средствами (соединения).
• Диаграмма развертывания отражает физические
взаимосвязи между программными и аппаратными
компонентами разрабатываемой системы.
• Узел представляет собой некоторый
тип вычислительного устройства, как
правило, самостоятельную часть
аппаратуры.
• Процессор - часть аппаратуры,
способная выполнять программы.
Защищенная
линия связи
"процессор"
:Сервер банка
main.exe
"процессор"
Удаленный терминал
dialog.exe
"база данных"
:Клиенты
банка
IAuthorise

56.

57.

Встроенная система «транспортная платформа»
(предназначена для перемещения в агрессивных средах)
оснащается собственным микропроцессором, цифровой
видеокамерой, датчиками температуры и местоположения, а
также управляющими приводами для перемещения платформы.
Управляющая и телеметрическая информация от платформы по
радиолинии передается в центр управления, оснащенный
управляющим компьютером, манипуляторами управления и
большим информационным табло.
"приемопередатчик"
Радиолиния
УКВ диапазона
"процессор"
:Микропроцессор
"приемопередатчик"
Датчики
Цифровая Управляющие
видеокамера приводы
Информационное
табло
"процессор"
:Контроллер
Манипуляторы управления
На микропроцессоре
платформы развернуты
программные компоненты для
реализации простейших
управляющих воздействий на
приводы, что позволяет дискретно
изменять направление и скорость
перемещения платформы.
На компьютере центра
управления развернуты
программные компоненты
анализа телеметрической
информации.

58. Анализ реализуемости

Все проекты является реализуемыми, если даются
неограниченные ресурсы и бесконечное время. К сожалению,
достаточно часто при разработке вычислительной системы или
продукта ресурсы бывают недостаточными, а сроки поставки
весьма сжаты (если не нереалистичны). Так что и необходимо, и
благоразумно оценивать реализуемость проекта как можно
раньше.
Цель: оценить концепцию системы на осуществимость
и выполнить экономический и технический анализ.
Важной составной частью анализа является оценка риска,
которая облегчит будущие стратегические и тактические
компромиссы.
Исследование реализуемости (осуществимости и
целесообразности) – деятельность, направленная на
выяснение: могут ли нужды пользователя быть удовлетворены
существующими технологиями и в существующих бюджетных
ограничениях.

59. реализуемость

Для получения целостного представления о продукте, о влиянии
приложения на бизнес и на пользователей «строится» бизнес-модель.
Бизнес-модель описывает цели организации и причины инвестиций
в разработку проекта.
Ниже перечислены вопросы, обсуждаемые на этом этапе.
Какие бизнес-требования предъявляются к проекту?
Какие бизнес-задачи он решает?
Какие инвестиции обеспечат максимальную отдачу?
Насколько быстро будет выполнен проект?
Каковы затраты на развертывание приложения?
Какие платформы оно должно поддерживать?
Сколько пользователей будут одновременно работать с
приложением?
Насколько важна зашита данных?
Насколько надежным должно быть приложение?
Когда потребуется замена или модернизация приложения?
Как быстро должны учитываться новые бизнес-правила и
требования пользователей?

60. Технологическая модель

Техническая реализуемость (technical feasibility)
- исследование функции, эксплуатационных
характеристик и ограничений, которые могут влиять на
возможность получения приемлемой системы.
Технологическая модель определяет технологии, способные решить
поставленные задачи. Она используется для поиска, приобретения или
создания необходимых технических ресурсов, удовлетворяющих
требованиям проекта.
Вопросы, на которые дает ответ технологическая модель:
• Под управлением каких операционных систем работают рабочие
станции, серверы и СУБД?
• Какая технология доступа к удаленным базам данных потребуется?
(выбирая способ взаимодействия компонентов с хранилищами данных,
изучите особенности производительности, стандартизации и
перспектив метода; учтите разнообразие поддерживаемых хранилищ
данных и управление доступом к ним, принимайте решение, учитывая
структуру и местонахождение информации)
• Какие технологии защиты данных необходимы?
• Какой метод реализации пользовательского интерфейса оптимален?
• Какая технология обеспечения масштабируемости будет
применяться?

61. Экономическая реализуемость

Экономическая реализуемость
(economic feasibility). Оценивание стоимости
разработки в сравнении с конечным доходом
или пользой, получаемой от разработанной
системы или продукта.
Может ли эта конфигурация быть создана в рамках
установленных границ стоимости и сроков?
Как следует вести работу над продуктом, принимая во внимание
потребности бизнеса (графики, квалификация персонала и затраты на
проект) и возможности имеющейся технологии (объекты и компоненты,
доступ к данным, пользовательский интерфейс, распределенные транзакции, зашита
данных). В каких границах должны быть заданы стоимость и сроки
разработки системы?
Задача этого этапа - произвести отчет по анализу
выполнимости, содержащий:
ответ на вопрос «отвечает ли создаваемая система общим целям
организации (бизнеса)» и
рекомендации по продолжению или отмене проекта.
Возможно, что отчет по анализу выполнимости будет
рекомендовать изменение объемов работ, срока или бюджета.

62. Правовая реализуемость

Правовая реализуемость (legal feasibility).
Определение любых нарушений или обязательств,
которые могут произойти в результате разработки
системы.
Правовое рассмотрение.
• Вводит ли эта конфигурация чрезмерный риск
обязательств?
• Могут ли быть надлежащим образом защищены
патентные аспекты?
• Есть ли потенциальные нарушения?
Персонал, занимающийся юридической стороной
проекта, проверяет, соответствуют ли требования к
продукту существующим законам и постановлениям.