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

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

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

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

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

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

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

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

предприятия, и как они связаны с областями (бизнеса).

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

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

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

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

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

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

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

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

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

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

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

с разрабатываемой системой и выполняют определенные роли).
Овалами изображаются возможные взаимодействия (виды этих взаимодействий или прецедентов использования системы).

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

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

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

(1) интерфейсу с пользователем, (2) вводу, (3) функции и управлению системы, (4) выходу и (5) техническому обслуживанию (maintanance) и самопроверке (self–testing) (диагностический интерфейс).

роль программного обеспечения ЭВМ и установить его связи с другими частями вычислительной системы

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

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

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

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

При разработке диаграмм компонентов преследуются цель: спецификация исполнимого варианта системы.

в (зависимом) компоненте для создания соответствующих объектов,
связи модулей программы на этапе компиляции и генерации объектного кода.

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

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

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

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

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

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

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

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

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

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

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

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

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