Этап «Проектирование информационных систем» (ИС) — один из ключевых в жизненном цикле разработки ИС, так как он определяет, какой будет система, как она будет устроена и как будет реализовывать требования пользователей, какие будут накладываться ограничения и прочее.
Для кого и для чего создавалась данная образовательная программа изложено в первой части курса.
Создание ландшафта/инфраструктуры для производства ИТ-продуктов.
Учитывая тот факт, что ошибки проектирования наиболее дорогие для бюджета проекта, а также то, что этап включает в себя множество активностей большого числа специалистов, особую важность приобретает необходимость создания комфортной среды, располагающей к плодотворной работе команды. Другими словами, для эффективной координации производственных взаимодействий важно организовать Ландшафт проекта, в рамках которого будет функционировать инфраструктура поддержки процесса разработки ПО, в том числе системы управления требованиями, документацией, задачами и проектами, а также инструменты для совместной работы и управления конфигурациями.
Создание качественной инфраструктуры проектных работ требует комплексного подхода и соблюдения стандартов для успешной реализации производственных задач. На безе полученного опыта стандарты могут трансформироваться с целью улучшения эффективности процессов.
Управление целями заинтересованных лиц.
Процесс формирования проектного решения обычно начинается с организации учета заинтересованных лиц и создания реестра стейкхолдеров, который позволит выявить и зафиксировать потребности всех участников проекта, а также установить параметры достижения их целей в реализуемом решении. Именно поэтому важно правильно организовать процесс управления целями заинтересованных лиц при проектировании ИС.
Помимо принятия во внимание контекста, ожиданий и ограничений заказчика при определении целей, критично обеспечить их гармоничность и совместимость для различных, разнотипных заинтересованных лиц. Поэтому цели должны быть структурированы по уровням (бизнес, продукт, технические) и приоритетам.
Регулярный контроль и адаптация целей обеспечивают успешную реализацию проекта.
Для определения целей используются различные методики, такие как SMART, OKR, GROW, Golden Circle и прочие.
Формализация потребностей заказчика.
Следующий ключевой этап в процессе проектирования является формализация Потребностей заказчика. Цель данного этапа - собрать максимально полные и точные сведения о потребностях заказчика.
Для этого используются различные методы фиксации информации о потребностях заинтересованных лиц, такие как описание прецедентов, пользовательские истории, макетирование и прототипирование, карта потребностей (Needs Canvas), Job Stories, карта пути пользователя (Customer Journey Map) и прочее.
Использование инструментов визуализации потребностей заказчика помогает привлечь внимание, упростить восприятие и повысить доверие к материалу.
Фиксация потребностей пользователя, в виду своей доступности для понимания широким кругом лиц, выступает основным инструментом влияния заказчика на разработку программного обеспечения и помогает пересматривать и актуализировать пользовательские требования.
Пожалуй, одной из базовых характеристик разрабатываемого продукта, является Функциональность ИС. Поэтому процесс выявления функции системы – критически важный шаг в цепочке производства ИТ-продуктов. Функциональное моделирование помогает понять структуру функционирования системы, определить последовательность выполнения функций, и выявить логические связи между ними в виде потоков ресурсов.
На базе формализованных функций можно разработать сервисную модель, включающую реестр доступных для использования сервисов и детальное представление каждого из них. Так же функции прекрасно подходят для разработки микросервисной архитектуры, основанной на принципах одиночной ответственности, децентрализации данных, умных сервисов, независимого развертывания и прочего.
Один из наиболее удобных инструментов формализации функций - IDEF0-диаграммы, позволяющий декомпозировать функции сверху вниз, трассируя потоки данных и ресурсов между уровнями. Так же его использование значительно упрощает задачи управления границами проекта. Разбиение на сервисы/функций системы помогает в структурировании решения и дроблении процесса реализации ИТ-продукта на этапы.
Полученный в результате активностей этой фазы набор функций/сервисов предоставляет возможность провести приблизительную оценку трудоемкости реализации решения и планировать ресурсы для производства ИС.
Инжиниринг бизнес-процессов заказчика.
Определив функции/сервисы, как статические характеристики системы, далее важно объяснит, как они используются в динамике. Моделирование бизнес-процессов помогает выявить сценарии использования функциональности продукта.
Моделирование бизнес-процессов может быть выполнено с использованием различных стандартов, таких как ГОСТ 19.003-80, ГОСТ 19.701-90, BPMN, ARIS и ISO 9001.
Для того, чтобы эффективно управлять большим количеством сложных, взаимосвязанных моделей бизнес-процессов, их принято классифицировать. Например, по типу использования: основные, сопутствующие, вспомогательные, обеспечивающие, бизнес-процессы управления и прочие. Каждый тип процесса чаще всего характеризуется своими специфическими характеристиками и аккомодацией соответствующего подхода проектирования для его формализации.
Применение делового моделирования помогает нормализовать представление команды о процессах. Выявить и решить такие проблемы, как дублирование функций, неэффективное распределение обязанностей, невостребованные результаты, "провисание" зон ответственности, пересечение полномочий и прочие.
Использование процессного моделирования позволяет также уточнить и детализировать произведенный ранее (на основе функций) предварительный расчет ресурсоемкости проекта, сгруппировать активности по бизнес-транзакциям, идентифицировать пользователей процессов, определить связи между процессами и хранилищами, при необходимости выполнить пересмотр границ проекта на основе уточненного расчета ресурсоемкости.
В современных средствах разработки нотации (BPMN) с описанием процессов могут использоваться совместно со специальным BPM-движком (engine), встроенным в различные ИТ-платформы. В этом случае бизнес-процессы, описанные с помощью BPMN, не просто визуализируются, а управляют логикой выполнения в реальных ИТ-системах, превращая нотацию в исполняемый код, который интерпретируется движком.
Модели бизнес-процессов также позволяют связать бизнес-слой архитектуры со слоем приложений, сопоставляя процессы и функции/сервисы с предоставляемыми программными компонентами.
Разработка логической структуры данных.
При описании бизнес-процессов, активности условно применяются к определенным бизнес-объектам, которые можно классифицировать и детализировать в виде сущностей предметной области. Результат этих работ ложится в основу проектирования моделей хранилищ данных.
Для моделирования структуры данных удобно использовать UML нотации Class diagram.
Чтобы качественно спроектировать структуру хранилищ и тем самым гарантировать достаточный баланс производительности, надежности, скорости отклика и прочих характеристик, необходимо обеспечить процесс Нормализации данных.
Для унификации и ускорения процесса разработки в проектировании баз данных на практике используется Шаблонный подход. При моделировании хранилищ данных применяются Паттерны проектирования, такие как Приспособленец (Flyweight), Компоновщик (Composite), Заместитель (Proxy), Фасад (Facade), Состояние (State), Прототип (Prototype) и прочие.
Моделирование систем, функционирующих в быстро изменяющихся условиях, требует применения Адаптивных моделей, которые позволяют снизить сложность системы, используя механизмы кастомизации решений в зависимости от текущих факторов.
Организация рефакторинга процессов моделирования, а также дизайна собственных паттернов проектирования помогают накапливать полезный опыт, тем самым улучшая качество проектирования, ускоряя и унифицируя процесс разработки.
После того как определена функциональность системы, и она увязана с сценариями в виде активностей, воздействующих на сущности предметной области, необходимо соотнести все эти артефакты друг с другом, распределив поведение системы по ее классам.
Моделирование поведения системы — это процесс создания упрощенного, формального или визуального представления динамики системы во времени, ее реакций на события и взаимодействий между компонентами.
Основные виды моделирования поведения: диаграммы поведения в UML, имитационное моделирование, агентное моделирование, системная динамика и прочее.
В частности, в UML используются диаграммы состояний для реализации требований событийно управляемых систем и являются реализацией идеи использования представления конечных автоматов для моделирования поведения.
Диаграммы последовательностей в UML предназначены для моделирования поведения в форме описания протокола сеанса обмена сообщениями между взаимодействующими экземплярами классов во время выполнения одного из возможных сценариев и позволяют моделировать ситуации, когда объект передает сообщение другому объекту и вынуждает его в свою очередь реагировать на это событие.
Резюмируя этот раздел можно констатировать, что моделирование поведения нужно для того, чтобы понять, предсказать и управлять системой без необходимости подвергать риску реальную систему.
Моделирование процессов управления
Для того, чтобы система не просто существовала, а функционировала целенаправленно, согласованно и устойчиво, чаще всего ею необходимо управлять.
Под Системой управления обычно подразумевают подсистему более крупной метасистемы, в которой протекают процессы управления, обеспечивающие согласованное функционирование элементов этого организованного целого, для достижения осознанных или неосознанных целей.
Основная цель задачи управления системой состоит в том, чтобы на основе механизмов обратной связи отделить ценную информацию от "шумов" (информацию возмущения) и выделить ту информацию (сигнал управления), которая позволяет этой системе существовать и развиваться.
Проектирование процессов управления системой – это исследовательский метод, применяемый в ходе разработки и реализации управляемых систем, отличающихся высоким уровнем сложности и представляющий собой создание модели или системы моделей для изучения того, как управление влияет на достижение целей.
Управление системой может быть организовано через различные типы моделей управления включая: управление по параметрам, управление по структуре, адаптивное управление, управление по целям, управление большими системами, управление при отсутствии информации о конечной цели и прочие.
Формирование требований и структурирование их в виде спецификаций
Полученные в процессе проектирования различные модели и прочие артефакты необходимо инкапсулировать в набор Требований. Требования — это формализованное описание того, что должна делать система, какими свойствами обладать и в каких условиях функционировать, чтобы удовлетворить потребности пользователей и заказчика. Полный набор Требований выступает единым представлением о предметной области.
С Требованиями удобнее работать, если они систематизированы в виде структуры. Для этого, например, может быть использовано классифицирование по различным категориям.
Качественные Требования должны соответствовать определенным критериям и правилам. Правила формулирования требований, например, регламентируются стандартом ISO/IEC/IEEE 29148:2018. Характеристики и правила стандарта помогают оценить качество требований и обеспечить их корректность.
Когда в процессе проектирования собраны и скомпонованы все Требования к целевой системе в виде описания, различных моделей и артефактов, их необходимо специфицировать в формат, максимально пригодный для использования командой разработки.
Требования, чаще всего, складываются в цельную и структурированную модель прототипа целевого продукта только в реальности проектировщиков. Для того же, чтобы результат проектирования соответствовал запросам команды, которой предстоит воплотить эту модель в коде, его необходимо трансформировать. Например, указать множество разъяснений, стыковок, последовательности исполнения, убрать лишние элементы, бесполезные для реализации и тому подобное. При этом важно учитывать ожидания различных заинтересованных лиц, таких как разработчики, менеджеры проектов, специалисты по качеству и прочие.
Для создания максимально пригодного формата спецификаций для конкретной команды, использующей определенный технологический стек, необходимо продумать и зафиксировать:
Состав документа;
Достаточный уровень детализации;
Форму и порядок представления информации в них.
Процесс передачи спецификаций требований на этап реализации должен быть четко регламентирован и по возможности соблюдаться.
Управление изменениями требований.
При разработке Требований важно учитывать тот факт, что после разработки продукта и передачи его в эксплуатацию, в результате его реального использования соберется множество замечаний пользователей и прочих данных о работе системы. На их основе необходимо будет формулировать новые или уточненные требования. В результате может быть инициирован новый цикл внесения изменений в спецификации, которые затем будут переданы для обновления дизайна, кода, проведения тестов и так прочих работ.
А потому, качественные требования должны быть сформированы так, чтобы в них легко было вносить изменения и поддерживать их версионность, а сама организация управления требований обеспечила устойчивость процесса разработки и сопровождения целевого продукта.
Критически важно учитывать, что любое изменение требований в отдельной части системы, с высокой долей вероятности повлечет необходимость изменений в условиях функционирования остальной части ИТ-продукта. Этот факт требует анализа влияний изменений на всю систему целиком и планирования комплекса связанных корректировок.