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

Июль 27, 2022

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

Содержание

2. План изучения дисциплины Процессы программного обеспечения Анализ требований Проектирование Кодирование и Испытания Системная инженерия Управляющие и
3. Система – совокупность взаимодействующих компонентов, работающих совместно для достижения определенных целей. Целью создания системы может быть
5. Группы процессов жизненного цикла из «ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы
6. Технические процессы ИСО12207-2010 Каждый из процессов жизненного цикла описывается в терминах цели и желаемых выходов, списков
7. Стадии информационной технологии Усложнение деловых связей и рост объемов информации, которыми сопровождается деятельность современных организаций, привели
9. инженерия требований к системе Процесс установления услуг, которые должна обеспечить вычислительная система, и ограничений, с которыми
10. Стратегическое информационное планирование Процесс технологии систем начинается с уровня всей сферы деятельности (тщательно исследуется вся область
11. Стратегическое информационное планирование. Пример взаимодействия «областей» (учреждений) в отрасли:
12. Взаимодействие «областей» в учреждении ПСИ определяет объекты данных, которые видимы на уровне предприятия, и как они
13. Стратегическое информационное планирование На этой стадии появляется понятие "модель предметной области" (enterprise model); строятся: диаграмма иерархии
14. Анализ области «бизнеса» Вторая стадия — анализ предметной области или сферы бизнеса (business area analysis). АОБ
15. Анализ области бизнеса Системный аналитик определяет модели данных и процессов предметной области, строит логическую модель организации
17. Пример схемы задач Схема медицинских задач
18. Модель потоков работ
19. Системная инженерия. К концептуальному проектированию. «Третья стадия»: проектировщик и аналитик моделируют основные требования к конкретной информационной
20. Идентификация потребностей Процесс установления услуг, которые должна обеспечить вычислительная система, и ограничений, с которыми она должна
21. Идентификация потребностей Общение с заказчиком: Аналитик (разработчик системы) встречается с заказчиком и конечным пользователем (если он
22. Идентификация потребностей. Интервьюрирование. Вопросы. Первое множество вопросов фокусирует свое внимание на общих целях и выгодах. Следующее
23. Идентификация потребностей. Этнография. Люди обычно не могут полноценно описать свою работу. В этом им может помочь
24. Идентификация потребностей Варианты использования (use-cases, use case diagram) позволяют более точно представить разработчикам, что же должна
25. Нотация: Человечками (фигурками человека) обозначаются внешние сущности или актеры (которые взаимодействуют с разрабатываемой системой и выполняют
29. Проектирование системной архитектуры Данная работа состоит из следующих задач, которые разработчик должен выполнить или обеспечить их
30. Проектирование архитектуры системы – установление высокоуровневой архитектуры системы, идентифицирующей конкретные оборудование, ПО, “данные” (или базы данных)
31. Для графического представления всей организации системы используются модели системной архитектуры. Блоки обычно соответствуют основным подсистемам или
32. Разработчик системы назначает элементы системы каждой из пяти областей в шаблоне: (1) интерфейсу с пользователем, (2)
37. Важно ввести программное обеспечение в его окружение (контекст), чтобы точно определить роль программного обеспечения ЭВМ и
38. Пример концептуальной архитектуры Схема взаимодействия решателей медицинских задач
39. В общем случае следует попытаться разложить систему на части так, чтобы архитектура была как можно проще
40. Функциональные компоненты можно классифицировать по категориям: сенсорные, исполнительные, вычислительные, коммуникационные, координирующие, интерфейсные. Эта классификация помогает при
41. Проектирование архитектуры системы. Логическая декомпозиция Архитектура может соответствовать некоторому архитектурному стилю
45. Клиент-серверная архитектура Клиент-серверная архитектура
46. Трехуровневая модель Трехуровневая модель
48. Программный комплекс "Рубеж-менеджер" для управления техническими средствами охраны
49. Редактор базы знаний Схема обобщенной экспертной системы
51. Проектирование архитектуры системы. Физическая декомпозиция После декомпозиции на функциональные компоненты для программных систем (с учетом необходимости
52. Диаграммы реализации Для физического представления моделей систем используются диаграммы реализации (implementation diagrams), которые включают в себя
53. Диаграмма компонентов Зависимости могут отражать наличие в компоненте описаний классов, которые используются в (зависимом) компоненте для
55. диаграмма размещения (развертывания) Диаграмма размещения применяется для представления общей конфигурации и топологии распределенной информационной системы, содержит
57. Встроенная система «транспортная платформа» (предназначена для перемещения в агрессивных средах) оснащается собственным микропроцессором, цифровой видеокамерой, датчиками
58. Анализ реализуемости Все проекты является реализуемыми, если даются неограниченные ресурсы и бесконечное время. К сожалению, достаточно
59. реализуемость Для получения целостного представления о продукте, о влиянии приложения на бизнес и на пользователей «строится»
60. Технологическая модель Технологическая модель определяет технологии, способные решить поставленные задачи. Она используется для поиска, приобретения или
61. Экономическая реализуемость Экономическая реализуемость (economic feasibility). Оценивание стоимости разработки в сравнении с конечным доходом или пользой,
63. Скачать презентацию

Слайд 2

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

и поддерживающие процессы

Слайд 3

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

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

Слайд 4

Слайд 5

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

и программная инженерия. Процессы жизненного цикла программных средств»

Слайд 6

Технические процессы ИСО12207-2010
Каждый из процессов жизненного цикла описывается в терминах

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

Слайд 7

Стадии информационной технологии
Усложнение деловых связей и рост объемов информации, которыми сопровождается

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

Слайд 8

Слайд 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) (диагностический интерфейс).

Слайд 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

диаграмма размещения (развертывания)
Диаграмма размещения применяется для представления общей конфигурации и топологии

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

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

Слайд 56

Слайд 57

Встроенная система «транспортная платформа» (предназначена для перемещения в агрессивных средах) оснащается

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

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

Слайд 58

Анализ реализуемости
Все проекты является реализуемыми, если даются неограниченные ресурсы и бесконечное

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

Слайд 59

реализуемость
Для получения целостного представления о продукте, о влиянии приложения на бизнес

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

Слайд 60

Технологическая модель
Технологическая модель определяет технологии, способные решить поставленные задачи. Она используется

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

Техническая реализуемость (technical feasibility) - исследование функции, эксплуатационных характеристик и ограничений, которые могут влиять на возможность получения приемлемой системы.

Слайд 61

Экономическая реализуемость
Экономическая реализуемость (economic feasibility). Оценивание стоимости разработки в сравнении с

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

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

Содержание

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

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

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

Технические процессы ИСО12207-2010 Каждый из процессов жизненного цикла описывается в терминах

Стадии информационной технологииУсложнение деловых связей и рост объемов информации, которыми сопровождается

инженерия требований к системеПроцесс установления услуг, которые должна обеспечить вычислительная система,

Стратегическое информационное планированиеПроцесс технологии систем начинается с уровня всей сферы деятельности

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

Взаимодействие «областей» в учрежденииПСИ определяет объекты данных, которые видимы на уровне

Стратегическое информационное планированиеНа этой стадии появляется понятие "модель предметной области" (enterprise

Анализ области «бизнеса»Вторая стадия — анализ предметной области или сферы бизнеса

Анализ области бизнесаСистемный аналитик определяет модели данных и процессов предметной области,

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

Модель потоков работ

Системная инженерия. К концептуальному проектированию.«Третья стадия»: проектировщик и аналитик моделируют основные

Идентификация потребностейПроцесс установления услуг, которые должна обеспечить вычислительная система, и ограничений,

Идентификация потребностейОбщение с заказчиком:Аналитик (разработчик системы) встречается с заказчиком и конечным

Идентификация потребностей. Интервьюрирование. Вопросы.Первое множество вопросов фокусирует свое внимание на общих

Идентификация потребностей. Этнография. Люди обычно не могут полноценно описать свою работу.

Идентификация потребностейВарианты использования (use-cases, use case diagram) позволяют более точно представить

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

Проектирование системной архитектурыДанная работа состоит из следующих задач, которые разработчик должен

Проектирование архитектуры системы – установление высокоуровневой архитектуры системы, идентифицирующей конкретные оборудование,