#инженерия_требований — Public Fediverse posts

[Перевод] Внедрение гибких методологий в сложные системы. Фреймворк пользовательских историй, дополненный принципом JTBD

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

https://habr.com/ru/companies/otus/articles/988408/

#пользовательские_истории #jtbd #требования #инженерия_требований #управление_требованиями #бэклог_продукта #декомпозиция_требований #нефункциональные_требования

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.1. Теория систем часть 2

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

https://habr.com/ru/articles/919454/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #системный_аналитик #промышленная_автоматизация #поведенческий_анализ #ингерентность #эмерджентность

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.1. Теория систем часть 2

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

https://habr.com/ru/articles/919454/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #системный_аналитик #промышленная_автоматизация #поведенческий_анализ #ингерентность #эмерджентность

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.1. Теория систем часть 2

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

https://habr.com/ru/articles/919454/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #системный_аналитик #промышленная_автоматизация #поведенческий_анализ #ингерентность #эмерджентность

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.1. Теория систем часть 2

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

https://habr.com/ru/articles/919454/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #системный_аналитик #промышленная_автоматизация #поведенческий_анализ #ингерентность #эмерджентность

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.2. Поведенческие диаграммы UML

Моделирование поведения системы — это процесс создания упрощённого, формального или визуального представления динамики системы во времени, ее реакций на события и взаимодействий между компонентами. Основные виды моделирования поведения: 1) Диаграммы поведения в UML

https://habr.com/ru/articles/919956/

#проектирование_систем #проектирование_систем_управления #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #uml #sequence_diagram #state_machine

Проектирование Информационных систем. Итоги, краткое изложение курса

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

https://habr.com/ru/articles/941672/

#проектирование_систем #анализ #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #требования_к_системе #спецификации #стандартизация #стандартизация_разработки

Проектирование Информационных систем. Часть 11. Управление изменениями требований

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

https://habr.com/ru/articles/931652/

#проектирование_систем #анализ #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #требования_к_системе #спецификации #стандартизация #стандартизация_разработки

Проектирование Информационных систем. Часть 10. Разработка требований 10.2. Формирование спецификаций требований

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

https://habr.com/ru/articles/922458/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #требования_к_системе #спецификации #стандартизация

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.2. Моделирование процессов управления

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

https://habr.com/ru/articles/920838/

#проектирование_систем_управления #проектирование_по #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #управление_продуктом #управляемые_сервисы

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.1. UML Class diagram

Одним из важнейших этапов в проектировании Информационной системы является выявление бизнес-объектов и их детализация на сущности Предметной области. По результатам этих активностей можно спроектировать модель хранилищ данных. Чаще всего такие работы выполняют параллельно с этапом описания бизнес-процессов. Как всегда, объявим цели текущего шага: определить и задокументировать сущности Предметной области и способы их взаимодействия. Спроектировать модель хранилищ данных. Таким образом мы расширяем наш домен решений, добавляя в него – модель данных. Чтобы сложить картинку о бизнес-объектах области автоматизации, необходимо уметь описывать бесконечное разнообразие сущностей мира - конечными фразами. Это можно сделать огрублено, приблизительно, упрощенно. 1) Первый шаг упрощения основан на том, что все объекты различны, но одни отличаются друг от друга «слабо», «мало», «незначительно», другие — «сильно», «существенно». 2) Второй шаг состоит в том, чтобы объединить все мало различающиеся объекты в одну группу, оставив вне ее все сильно различающиеся. В итоге бесконечно разнообразный мир описывается конечным множеством отличающихся друг от друга классов. Похожий прием мы уже использовали на каждом этапе, классифицируя рассматриваемы элементы, определяя для них простейшую абстрактную модель разнообразия действительности. Для выражения различий между классами им присваиваются различные имена (названия, обозначения, символы, номера и т.п.). Классифицировать можно не только объекты, но и свойства (цвета, звуки, силы, размеры и т.д.), и процессы (ходить, бегать, тянуть, есть, пить и т.д.). Таким образом, классификация сущностей исследуемой предметной области идентифицируется в виде названия некоторых классов.

https://habr.com/ru/articles/917654/

#проектирование_систем #проектирование_по #проектирование_баз_данных #анализ_и_проектирование_систем #системный_анализ #бизнесмодель #сущность #инженерия_требований #нормализация_данных

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов заказчика 7.1. Применение UML Activity

В качестве следующего шага на пути формирования проектного решения определим процессы, которые должны проистекать внутри разрабатываемой системы и окружать ее из вне. Поддерживая непрерывность процесса проектирования, будем отталкиваться от функций, которые мы выявили на предыдущем этапе. Как всегда, обозначим цели текущего шага: на основании выявленных функций, определить сценарии использования/применения, разрабатываемого целевого продукта . На текущем этапе проектирования воспользуемся Алгоритмизацией , еще одним приемом дисциплины «Системный Анализ». Рассмотренные нами ранее модели в большей степени отражали статику, ведь в итоге формализованные функции воплощают свойства системы, которые можно использовать. Теперь внесем немного динамики, моделируя действия. Важное отличие алгоритмов от используемых нами ранее диаграмм IDEF0, это возможность организовывать условные переходы, то есть в зависимости от выполнения некоего условия на определенном шаге сценария, предпринимать далее те или иные варианты действий. Концепция инжиниринга бизнес-процессов подразумевает осмысление различных моделей текущего состояния системы и прогнозирования будущих с целью достижения существенных улучшений по ключевым показателям: стоимость, качество, скорость, ресурсоемкость и прочее. В зависимости от актуальных условий может использоваться: 1) Экстраполяционная модель

https://habr.com/ru/articles/916676/

#проектирование_систем #проектирование_по #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #промышленная_автоматизация #activity #uml #umlпроектирование

Проектирование Информационных систем. Часть 6. Выявление функции системы. 6.1. Теория систем

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

https://habr.com/ru/articles/915546/

#проектирование_систем #проектирование_по #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #системотехника

Проектирование Информационных систем. Часть 5. Формализация потребностей заказчика

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

https://habr.com/ru/articles/915090/

#проектирование_систем #проектирование_по #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #проектирование_взаимодействия

Проектирование Информационных систем. Часть 4. Управление целями заинтересованных лиц

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

https://habr.com/ru/articles/914794/

#проектирование_систем #проектирование_по #проектирование_взаимодействия #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация

Проектирование Информационных систем. Часть 3. Инфраструктура (ландшафт) для организации проектной деятельности

Разработка проектного решения и документирование активностей по его воплощению на производстве больших ИТ-продуктов, процесс длительный, поэтапный, к тому же очень кропотливый и требующий слаженной работы разношерстного коллектива. Поэтому с самого начала необходимо продумать и подготовить ландшафт (среду обитания), в которой это процесс будет проистекать. Из моего опыта, если команда обеспечена комфортной средой для работы с артефактами проекта, а также для коммуникации участников между собой, то она уже на 50% обеспечила успешное развитие проекта. Цель данной группы работ : подготовить условия для качественного и эффективного взаимодействия команды проекта в рамках разработки и реализаций требований к целевому продукту. Чтобы глубже познать принципы организации такого ландшафта давайте рассмотрим модель того, как обычно происходит взаимодействие в команде.

https://habr.com/ru/articles/914296/

#проектирование_систем #проектирование_по #проектирование_взаимодействия #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация

Проектирование Информационных систем. Часть 10. Разработка требований 10.1. Правила формирования требований

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

https://habr.com/ru/articles/921622/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #спецификации #iso #ISO_29148

«Генералы», «Цезари» и «Псевдоэксперты»: как договориться со сложным заказчиком

Практическое руководство по работе со сложными клиентами — с примерами из нефтегаза, госсектора, бизнеса и стартапов Эта статья — концентрированный опыт нашей команды аналитиков из компании Rubius, накопленный за годы работы в заказной разработке. Здесь нет теории из учебников — только проверенные на практике методы общения с «Генералами», «Истериками», «Цезарями» и другими сложными типами заказчиков.

https://habr.com/ru/articles/937644/

#бизнесанализ #системный_анализ #заказчики #заказная_разработка #сбор_требований #инженерия_требований #переговоры_с_заказчиком