моделирование и проектирование информационных процессов в технологических системах что это

Моделирование и визуализация при анализе и проектировании ИТ систем. И не только

Проблема

Нет, это не про визуализацию желаний и совсем не про психологию.

IT специалисты применяют моделирование и визуализацию, чтобы упростить анализ объектов. Объекты могут быть разными: корпорации, бизнес-процессы, требования клиентов или информационные системы любых размеров.

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

Разные ситуации + разный жизненный опыт = разные картинки в голове разных людей. Это мешает качественной передаче информации. Часто, мы и сами не имеем четкой картинки того, что хотим передать.

Современные исследования (например “Picture or Text First? Explaining Sequence Effects when Learning with Pictures and Text” K. Scheiter и A. Eitel) подтверждают, если дополнять текстовую информацию ее визуальной версией – её будет проще понимать и запоминать.

Что такое визуализация и моделирование

Визуализация — общее название приёмов представления числовой информации или физического явления в виде, удобном для зрительного наблюдения и анализа.

Модель — упрощенное представление реальности, созданное для передачи информации определенной аудитории для поддержки анализа, коммуникации и понимания (BABOK 3.0).

Модель — представление системы, процесса, услуги или другой сущности, которое используется для понимания и прогнозирования их поведения и взаимодействий (ITIL 4).

У меня было три повода писать это:

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

В команде интеграции важно использовать такие методы донесения информации, которые поймёт команда и специалисты со стороны. Иначе ни с кем не интегрируешься.

Кому и почему полезна статья:

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

Опытные: пополнят свой инструментарий, основываясь на практике других аналитиков.

Повысят качество и релевантность вакансий. В вакансиях больше не будет требований к навыкам, которые не используются.

Тем, кто хочет работать в IT или смежной сфере

Поймут, чем отличаются модели между собой, какие изучать сначала, а какие потом.

Как собирались данные и проводилось исследование

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

Основная часть

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

Изложение в виде изображений:

+ Проще читать и понимать текст.

+ Делает текст менее монотонным;

+ Может отражать связи и тренды, которые сложно уловить через текст или числа;

+ Создает единое информационное поле и контекст внутри него с разными уровнями абстракции;

+ Это просто красиво;

— Может терять часть передаваемой информации и излишне упрощать;

— Часто зависит от собственного контекста, того, кто создает модель или визуализацию;

— Для некоторых нотаций и моделей нужны специальные знания.

Вот, что Карл Вигерс пишет в части “Навыки, необходимые аналитику” (книга “Разработка требований к программному обеспечению”):

“Аналитик должен уметь работать с разнообразными средствами, начиная с древних блок-схем и структурированных моделей анализа (диаграммы потоков информации, диаграммы ≪сущность-связь≫ и т.д.) и заканчивая современным языком UML (Unified Modeling Language, унифицированный язык моделирования). Некоторые из этих средств полезны при общении с пользователями, другие — с разработчиками”

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

Cвод знаний по бизнес-анализу (BABOK) среди техник для анализа выделяет: моделирование понятий, данных, требований, решений, скоупа, процессов, состояний и организационное моделирование. Как инструменты предлагается использовать богатый зоопарк различных нотаций.

Об этом статистик Джордж Бокс сказал: «В сущности, все модели неверны, но некоторые — полезны».

Результаты опроса

Роли участников в команде

Как часто они используют модели

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

В каких областях работают

В опросе можно было выбрать несколько областей специализации.

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

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

Какими диаграммами и моделями пользуются

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

Где моделируют и рисуют

С полученной информацией каждый поступит по-своему. Лично для меня очевидно следующее:

Работа в ИТ сфере требует понимания и использования визуализаций и моделей;

Многие из нотаций и диаграммы, которые традиционно преподаются в ВУЗах и на курсах морально устарели;

Мои попытки заняться скетчингом нужно продолжать, т.к. часто рисуют абстрактно и от руки;

Требования в вакансиях и вопросы во время интервью часто различается с тем, что требуется в отрасли;

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

Источник

Проектирование информационных систем

Тематический план

Общее

Основные понятия технологии проектирования информационных систем (ИС)

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

Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации.

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

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

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

Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком.

В автоматических ИС все операции по переработке информации выполняются без участия человека.

Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль в выполнении рутинных операций обработки данных отводится компьютеру. Именно этот класс систем соответствует современному представлению понятия «информационная система».

В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие.

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

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

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

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

В зависимости от сферы применения различают следующие классы ИС.

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

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

Таблица 1.1. Функциональное назначение модулей корпоративной ИС.

Финансовые и учетные подсистемы

Подсистема кадров (человеческих ресурсов)

Прочие подсистемы (например, ИС руководства)

Исследование рынка и прогнозирование продаж

Планирование объемов работ и разработка календарных планов

Управление портфелем заказов

Анализ и прогнозирование потребности в трудовых ресурсах

Контроль за деятельностью фирмы

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

Управление кредитной политикой

Ведение архивов записей о персонале

Выявление оперативных проблем

Рекомендации по производству новой продукции

Разработка финансового плана

Анализ и планирование подготовки кадров

Анализ управленческих и стратегических ситуаций

Анализ и установление цены

Участие в формировании заказов поставщикам

Финансовый анализ и прогнозирование

Обеспечение процесса выработки стратегических решений

Контроль бюджета, бухгалтерский учет и расчет зарплаты

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

Существует классификация ИС в зависимости от уровня управления, на котором система используется.

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

С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.

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

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

Сама идея использования универсальной программы накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные «сверху» жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности.

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

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

Проектирование ИС охватывает три основные области:

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

Процесс создания ИС делится на ряд этапов (стадий [ 1.1 ] ), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

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

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

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

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

Конечными продуктами этапа проектирования являются:

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

Этап проектирования завершается разработкой технического проекта ИС.

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

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

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

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

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

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

Жизненный цикл программного обеспечения ИС

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

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

В настоящее время известны и используются следующие модели жизненного цикла:

На практике наибольшее распространение получили две основные модели жизненного цикла:

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в видепроцессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов.

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

Среди наиболее известных стандартов можно выделить следующие:

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

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

Таблица 2.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Источник