В предыдущей части «Часть 1» Краткое содержание:
I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем
III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам
Сперва сосредоточимся на проблеме, как может быть организована работа, касающаяся требований к создаваемому продукту. Ее исполнители и авторы скорее всего так или иначе завязаны на функции по сбору и анализу информации. Люди неординарные и немного консервативные, под них и будем подстраиваться.
Возможная модель данных представлена на рис.3.
Рисунок 3. – Модель организации задач по требованию
Сами требования по своей природе очень изменчивы, а их авторы зачастую капризны. Для борьбы с этим вызовом, вынесем большую часть свойств «Требования» в отдельный класс – «Содержание требования». Собственно отделив таким образом часто меняемые реквизиты от условно постоянных, мы сможем хранить и просматривать всю эволюцию формирования контекста требования, не затрагивая прочие стационарные реквизиты. Для того, чтобы понимать, а какой же набор «Содержания требования» сейчас актуален (один из всего множества) можно использовать обратную ссылка на таблицу «Требования», как показано на рис.3. Противники использования обратных ссылок могут организовать слабую связь, указывающая в требовании актуальную версию содержания (просто строку), или, например, хранить дату/время создания актуального содержания. В общем, кому как нравится.
Следующий момент, требования чаще всего возникают в рамках какого-либо проекта. Но может статься так, что замысел или большая его часть подходит как одному, так и другому проекту и дублировать требования попросту нецелесообразно. А посему соотнесем требование с проектом, через связку многие ко многим: «Требование в проекте». Ну и естественно статус требования в разных проектах может быть разный. Например, в одном проекте оно уже давно реализовано, а в другом еще только обсуждаться. Поэтому статус мы замкнем не на само «Требование», а на связку «Требование в проекте».
Чтобы не резать крылья фантазии пользователей системы, при логическом увязывании самих требований между собой, свяжем их множественной ссылкой. Таким образом предоставим возможность скоординировать два требования не одной, а множеством связей, характеризующих разные стороны интерактивности. А вот иерархическую подчиненность требований, тем не менее оставим в стороне. Такое представление все же привычнее. Ведь навигация в древовидной структуре, детализирующей вниз и абстрагирующей вверх, проще воспринимается, чем блуждания в паутине графа.
Конечно «Требование» должно быть снабжено возможностью обсуждения, через комментарии. Тем же у кого регламент обсуждения и согласования нетривиальный, можно взглянуть на сюжеты из документооборота и взять за основу более сложный бизнес процесс.
А еще должна быть возможность цеплять к требованию файлы вложения, и хорошо бы делить их по типам. Вообще именно для требований, вложения интересно организовать в виде учета артефактов, поддержав их версионированием, типизацией представления, «захватом» для записи и т.п.
Нашел у себя в архиве требований, подходящий UseCase по работе с артефактами. Приведу его на рис. 4, без изменений как он был зафиксирован.
Рисунок 4. – Варианты использования управления Артефактом
Для борьбы со сложностью и во благо обеспечения удобства управления требованиями, стоит предусмотреть их деление по типам. Например:
И уж коль мы разбили их на части, то имеет смысл, каждый сегмент дополнительно наделить своими специфическими атрибутами.
Это минимальный набор, позволяющий смоделировать сущность «Требование». Возможно в ходе дальнейшего рассмотрения мы его расширим.
Разобравшись с Требованиями, перейдем к следующему шагу – обработке Спецификаций. Сами спецификации в системе появляются в ходе процесса проектирования, на основании требования. Не лишне заметить, что возникают они, как раз в результате выполнения задач, связанных этим самым требованием. Например, задача может звучать так: «Разработать спецификацию требования». При этом, возможно даже стоит связать «Отчет о выполнении» этой задачи с ее решением — «Спецификацией», явленной миру в результате исполнения.
Подобные спецификации, в отличие от требований, должны учитывать конкретные инструменты, платформы, практики, которые будут использовать программисты в проекте, и поэтому в их формировании самое непосредственно участие принимают Team Lead, Solution архитекторы или Software Engineering Manager. Соответственно именно их предпочтения должны быть учтены в данном контексте.
Фактически спецификация транслирует требования пользователя на уровень разработчика, нормализуя их, детализируя, приводя к понятиям, которыми оперируют программисты: Формы, Таблицы, Кнопки, Процедуры и т.п.
Возможная модель данных представлена на рис.5.
Рисунок 5. – Модель организации задач по спецификации
В отличие, от требования, которое может повторяться из проекта в проект, спецификация весьма уникальна для каждой реализации, в каждом конкретном случае. Ведь это воплощение требования в определенных условиях, определенного ИТ-проекта. Поэтому в спецификацию добавлен атрибут «Проект», в рамках которого и происходит это воплощение. Также свяжем ее ссылкой с «Требованием».
Связь между спецификациями обустроим подобно тому, как это было организовано в требованиях.
Как и требования, спецификация снабжена возможностью обсуждения, через комментарии и шансом прикрепить к ней файлы вложений.
Для удобства, спецификации также поделим на типы. Например:
И типы задач будут соответственно расширены по сравнению с заданиями для требований:
Давайте еще раз остановимся на определении места спецификации в общей цепочке производства ПО. С одной стороны, мы установили связь с требованием, которое и явилось причиной появления спецификации. С другой, в качестве консеквенции, завяжем на сборку продукта, в которой эта спецификация реализована. А поскольку реализация одной и той же спецификации может появиться в разных сборках, то связываем их не напрямую, а через развязку “многие ко многим” — «Спецификация в сборке».
Теперь можно отследить, не только те спецификации, которые необходимо протестировать в новой сборке, но и, например, в каких сборках появлялись решения по спецификации, а еще, в каких версиях продукта реализовано требование и т.п.
По хорошему сами спецификации должны различаться между собой, в зависимости от области их применения, как минимум набором атрибутов. Например, шаблоны для описания форм, отчетов, процедур, матриц доступа и т.п. могу значительно разниться по составу. Большое влияние на этот дефферанс также могут оказать и используемые платформы, библиотеки, сервисы и прочие инструменты.
Когда функциональность целевого продукта реализована в коде, она должна как-то сложиться в некий нематериальный актив, работу которого можно каким-то образом использовать. К примеру, для начала — протестировать.
Таким образом, реализовав некоторый набор спецификаций, например, выбранных для итерации, команде необходимо выполнить сборку продукта, которая получит свою уникальную версию и может быть передана на следующую стадию производства.
Введем в модель сущность «Сборка». Возможная модель данных представлена на рис.6.
Рисунок 6. – Модель организации сборок
Каждая сборка выполняется для конкретного проекта и в модели имеет ссылку на него. Про организацию спецификаций в сборке, мы уже говорили в предыдущем разделе.
Задачи, выставляемые для объекта «Сборка», могут обладать следующими типами:
По отчетам к задачам, мы можем определить на каких площадках, когда и кем была развернута каждая конкретная сборка.
При необходимости запустить новый круг разработки, или же для исправления ошибки, либо для устранения неточностей, можно создать новые задачи по спецификации. При этом несложно определить, в какой сборке был реализован ее последний вариант.
В результате выполненного проектирования почти неизбежно возникли вопросы и нестыковки.
Дилемма курицы и яйца. Получается новое «требование» может быть создано на основании «задачи по требованию», другому и уже существующему. Например, при необходимости его детализировать, прямо из этого требования создаем задачу: «Детализировать текущее требование». В результате ее исполнения складывается следующая цепочка: во-первых, сама эта задача создана на основании требования. Во-вторых, по задаче, во исполнение ее же самой, создается новое требование. Далее, аналогично через задачу по требованию рождается «спецификация».
И вот тут возникает резонный вопрос: а должно же где-то было быть самое первое требование, как же его создали без задачи? Ну и даже если окажется, что «так было можно», а как отметить работу по созданию требования «номер один»? Выкрутиться тут конечно возможно. Например, создать требование безо всяких оснований (в системе), а уже после навесить на нее задачу в которую и списывать время на его создание, обработку и т.д.
Чуть менее заметна проблема в решении с созданием сборки. Ведь она тоже в системе регистрируется еще до создания первой «задачи по сборке». А нужна она хотя бы для того, чтобы к сборке (вернее ее проекту) присоединить новые реализации спецификаций. Но в этом случае, можно организовать например, работу службы, которая по команде будет регистрировать в системе новую сборку, присваивать ей номер версии и т.п. Как бы самой работы для сотрудника нет, а сборка вот она уже в системе. И время списывать вроде бы и не на что. Тоже выкрутились.
И еще. В многослойных проектах частенько возникает необходимость делить продукт на взаимодействующие модули, сервисы и прочие интеграции. В этом случае сам продукт приходится компоновать из множества сборок, как бы более мелких продуктиков. И необязательно они все выпускаться одновременно скопом. Какой-то продуктик еще актуален, а какой-то возможно долен быть пересобран наново. Соответственно необходимо установить сочетаемость (или переносимость) подсистем друг с другом и рекомендуемые совокупности сборок. Но к этому вопросу давайте вернемся позже, когда будем рассматривать проектные работы в процессе производства ПО. см. «Часть 3»
I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем
III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам
2. Требования и задачи для них
Сперва сосредоточимся на проблеме, как может быть организована работа, касающаяся требований к создаваемому продукту. Ее исполнители и авторы скорее всего так или иначе завязаны на функции по сбору и анализу информации. Люди неординарные и немного консервативные, под них и будем подстраиваться.
Возможная модель данных представлена на рис.3.
Рисунок 3. – Модель организации задач по требованию
Сами требования по своей природе очень изменчивы, а их авторы зачастую капризны. Для борьбы с этим вызовом, вынесем большую часть свойств «Требования» в отдельный класс – «Содержание требования». Собственно отделив таким образом часто меняемые реквизиты от условно постоянных, мы сможем хранить и просматривать всю эволюцию формирования контекста требования, не затрагивая прочие стационарные реквизиты. Для того, чтобы понимать, а какой же набор «Содержания требования» сейчас актуален (один из всего множества) можно использовать обратную ссылка на таблицу «Требования», как показано на рис.3. Противники использования обратных ссылок могут организовать слабую связь, указывающая в требовании актуальную версию содержания (просто строку), или, например, хранить дату/время создания актуального содержания. В общем, кому как нравится.
Следующий момент, требования чаще всего возникают в рамках какого-либо проекта. Но может статься так, что замысел или большая его часть подходит как одному, так и другому проекту и дублировать требования попросту нецелесообразно. А посему соотнесем требование с проектом, через связку многие ко многим: «Требование в проекте». Ну и естественно статус требования в разных проектах может быть разный. Например, в одном проекте оно уже давно реализовано, а в другом еще только обсуждаться. Поэтому статус мы замкнем не на само «Требование», а на связку «Требование в проекте».
Чтобы не резать крылья фантазии пользователей системы, при логическом увязывании самих требований между собой, свяжем их множественной ссылкой. Таким образом предоставим возможность скоординировать два требования не одной, а множеством связей, характеризующих разные стороны интерактивности. А вот иерархическую подчиненность требований, тем не менее оставим в стороне. Такое представление все же привычнее. Ведь навигация в древовидной структуре, детализирующей вниз и абстрагирующей вверх, проще воспринимается, чем блуждания в паутине графа.
Конечно «Требование» должно быть снабжено возможностью обсуждения, через комментарии. Тем же у кого регламент обсуждения и согласования нетривиальный, можно взглянуть на сюжеты из документооборота и взять за основу более сложный бизнес процесс.
А еще должна быть возможность цеплять к требованию файлы вложения, и хорошо бы делить их по типам. Вообще именно для требований, вложения интересно организовать в виде учета артефактов, поддержав их версионированием, типизацией представления, «захватом» для записи и т.п.
Нашел у себя в архиве требований, подходящий UseCase по работе с артефактами. Приведу его на рис. 4, без изменений как он был зафиксирован.
Рисунок 4. – Варианты использования управления Артефактом
Для борьбы со сложностью и во благо обеспечения удобства управления требованиями, стоит предусмотреть их деление по типам. Например:
- Архитектура;
- Функциональность;
- Бизнес-процессы;
- Дизайн и юзабилити;
- Безопасность и надёжность;
- Показатели назначения;
- Документирование;
И уж коль мы разбили их на части, то имеет смысл, каждый сегмент дополнительно наделить своими специфическими атрибутами.
Это минимальный набор, позволяющий смоделировать сущность «Требование». Возможно в ходе дальнейшего рассмотрения мы его расширим.
3. Спецификации и задачи для них
Разобравшись с Требованиями, перейдем к следующему шагу – обработке Спецификаций. Сами спецификации в системе появляются в ходе процесса проектирования, на основании требования. Не лишне заметить, что возникают они, как раз в результате выполнения задач, связанных этим самым требованием. Например, задача может звучать так: «Разработать спецификацию требования». При этом, возможно даже стоит связать «Отчет о выполнении» этой задачи с ее решением — «Спецификацией», явленной миру в результате исполнения.
Подобные спецификации, в отличие от требований, должны учитывать конкретные инструменты, платформы, практики, которые будут использовать программисты в проекте, и поэтому в их формировании самое непосредственно участие принимают Team Lead, Solution архитекторы или Software Engineering Manager. Соответственно именно их предпочтения должны быть учтены в данном контексте.
Фактически спецификация транслирует требования пользователя на уровень разработчика, нормализуя их, детализируя, приводя к понятиям, которыми оперируют программисты: Формы, Таблицы, Кнопки, Процедуры и т.п.
Возможная модель данных представлена на рис.5.
Рисунок 5. – Модель организации задач по спецификации
В отличие, от требования, которое может повторяться из проекта в проект, спецификация весьма уникальна для каждой реализации, в каждом конкретном случае. Ведь это воплощение требования в определенных условиях, определенного ИТ-проекта. Поэтому в спецификацию добавлен атрибут «Проект», в рамках которого и происходит это воплощение. Также свяжем ее ссылкой с «Требованием».
Связь между спецификациями обустроим подобно тому, как это было организовано в требованиях.
Как и требования, спецификация снабжена возможностью обсуждения, через комментарии и шансом прикрепить к ней файлы вложений.
Для удобства, спецификации также поделим на типы. Например:
- Функционал;
- Дизайн и юзабилити;
- Безопасность и надёжность;
- Показатели назначения;
И типы задач будут соответственно расширены по сравнению с заданиями для требований:
- Оценка;
- Реализация;
- Тестирование;
- Исправление ошибки;
- Документирование;
Давайте еще раз остановимся на определении места спецификации в общей цепочке производства ПО. С одной стороны, мы установили связь с требованием, которое и явилось причиной появления спецификации. С другой, в качестве консеквенции, завяжем на сборку продукта, в которой эта спецификация реализована. А поскольку реализация одной и той же спецификации может появиться в разных сборках, то связываем их не напрямую, а через развязку “многие ко многим” — «Спецификация в сборке».
Теперь можно отследить, не только те спецификации, которые необходимо протестировать в новой сборке, но и, например, в каких сборках появлялись решения по спецификации, а еще, в каких версиях продукта реализовано требование и т.п.
По хорошему сами спецификации должны различаться между собой, в зависимости от области их применения, как минимум набором атрибутов. Например, шаблоны для описания форм, отчетов, процедур, матриц доступа и т.п. могу значительно разниться по составу. Большое влияние на этот дефферанс также могут оказать и используемые платформы, библиотеки, сервисы и прочие инструменты.
4. Сборки и задачи для них
Когда функциональность целевого продукта реализована в коде, она должна как-то сложиться в некий нематериальный актив, работу которого можно каким-то образом использовать. К примеру, для начала — протестировать.
Таким образом, реализовав некоторый набор спецификаций, например, выбранных для итерации, команде необходимо выполнить сборку продукта, которая получит свою уникальную версию и может быть передана на следующую стадию производства.
Введем в модель сущность «Сборка». Возможная модель данных представлена на рис.6.
Рисунок 6. – Модель организации сборок
Каждая сборка выполняется для конкретного проекта и в модели имеет ссылку на него. Про организацию спецификаций в сборке, мы уже говорили в предыдущем разделе.
Задачи, выставляемые для объекта «Сборка», могут обладать следующими типами:
- выпуск сборки;
- интеграционное тестирование сборки;
- установка сборки на стенд;
По отчетам к задачам, мы можем определить на каких площадках, когда и кем была развернута каждая конкретная сборка.
При необходимости запустить новый круг разработки, или же для исправления ошибки, либо для устранения неточностей, можно создать новые задачи по спецификации. При этом несложно определить, в какой сборке был реализован ее последний вариант.
5. Анализ текущей фазы проектирования
В результате выполненного проектирования почти неизбежно возникли вопросы и нестыковки.
Дилемма курицы и яйца. Получается новое «требование» может быть создано на основании «задачи по требованию», другому и уже существующему. Например, при необходимости его детализировать, прямо из этого требования создаем задачу: «Детализировать текущее требование». В результате ее исполнения складывается следующая цепочка: во-первых, сама эта задача создана на основании требования. Во-вторых, по задаче, во исполнение ее же самой, создается новое требование. Далее, аналогично через задачу по требованию рождается «спецификация».
И вот тут возникает резонный вопрос: а должно же где-то было быть самое первое требование, как же его создали без задачи? Ну и даже если окажется, что «так было можно», а как отметить работу по созданию требования «номер один»? Выкрутиться тут конечно возможно. Например, создать требование безо всяких оснований (в системе), а уже после навесить на нее задачу в которую и списывать время на его создание, обработку и т.д.
Чуть менее заметна проблема в решении с созданием сборки. Ведь она тоже в системе регистрируется еще до создания первой «задачи по сборке». А нужна она хотя бы для того, чтобы к сборке (вернее ее проекту) присоединить новые реализации спецификаций. Но в этом случае, можно организовать например, работу службы, которая по команде будет регистрировать в системе новую сборку, присваивать ей номер версии и т.п. Как бы самой работы для сотрудника нет, а сборка вот она уже в системе. И время списывать вроде бы и не на что. Тоже выкрутились.
И еще. В многослойных проектах частенько возникает необходимость делить продукт на взаимодействующие модули, сервисы и прочие интеграции. В этом случае сам продукт приходится компоновать из множества сборок, как бы более мелких продуктиков. И необязательно они все выпускаться одновременно скопом. Какой-то продуктик еще актуален, а какой-то возможно долен быть пересобран наново. Соответственно необходимо установить сочетаемость (или переносимость) подсистем друг с другом и рекомендуемые совокупности сборок. Но к этому вопросу давайте вернемся позже, когда будем рассматривать проектные работы в процессе производства ПО. см. «Часть 3»