Управление требованиями

Что такое управление требованиями, как оно устроено, и почему приходится им заниматься? Уже давно стало ясно, что для преуспевания компании недостаточно просто иметь товар и продавать его. Продукт должен быть востребованным и удобным для потребителя. А позже появилось понимание, что продукт требует каких-то сервисов, что необходим переход к сервисной модели. Более того, потребитель хочет не владеть товаром, а пользоваться им. Отсюда арендные или подписочные модели.

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


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

Что такое требования и в чем суть проблемы?

Для начала определимся с понятием требований. Требование оправданный, утверждённый и документально изложенный критерий, которому должно быть обеспечено соответствие. Требования могут исходить как из внешней среды (от заказчика, регулирующих органов и пр.), так и из внутренней среды организации (технологические ограничения, требования маркетологов и т.д.). Распространяются такие требования, прежде всего, на функции изделия, на используемые в нём материалы, на применяемые интерфейсы, протоколы и прочие свойства изделия. Кроме того, требования могут накладываться и на процессы разработки изделия, и на производственные процессы, и на последующую эксплуатацию изделия.
В чем же проблема с требованиями? Прежде всего, это неспособность понять требования заказчиков. Кроме того, количество требований к концу разработки может на порядки превышать их количество в исходном ТЗ. Т.е. на входе в разработку изделия просто невозможно определить сразу все требования к нему. Серьезное изделие масштаба самолета это более миллиона требований.
В какой-то момент пришло осознание факта, что описать в виде требований инновационное изделие до начала его разработки просто невозможно, а все попытки ограничиться единожды составленным набором требований сводят на нет те самые инновационные свойства изделия. И, начиная, прежде всего, с разработки программного обеспечения, а сегодня всё шире и шире стали применяться принципы аджайл (Agile). Такие принципы принимают факт ущербности начальных требований и необходимости работы с ними на всем цикле разработки.
При ближайшем рассмотрении оказывается, что проблемы, связанные с ошибками разработки или производства, как правило, весьма несущественны по сравнению с тем, что заложено в требованиях. Прежде всего, это неполнота требований по составу и проработке. Не менее важно и то, в каком виде требования представляются заинтересованным лицам, которые, собственно говоря, и должны воплотить такие требования в разрабатываемом изделии. Да и заказчик далеко не всегда знает, что он хочет, не всегда готов выразить свои требования в пригодном для дальнейшего использования виде.
В результате требования могут совершенно не совпадать с ожиданиями, а участвующие стороны часто понимают их по-своему. В довершение всего, как мы уже знаем, требования будут по ходу разработки изделия меняться и дополняться. Если этим не заниматься системно, то есть не управлять требованиями, то и результат будет соответствующим.



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

Иерархия требований

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


Для организации процессов разработки сложных изделий Независимая Ассоциация системных инженеров рекомендует использование метода RFLP (Requirements Functional Logical Physical). В таком методе, опираясь на управление требованиями, в первую очередь определяют функциональный состав изделия, т.е. какие функции должно выполнять разрабатываемое изделие.

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

Имитационное моделирование

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



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

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

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

Для чего нужны инструменты работы с требованиями?

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

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

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

Растущая сложность изделий приводит к тому, что сегодня традиционная роль главных/генеральных конструкторов как отцов изделия уходит в прошлое. Человеку не под силу держать в голове всю картину изделия, обеспечить его целостность. Как уже отмечалось, требования могут быть внутренними и внешними, касаться не только самого изделия, но и материалов, из которых оно изготавливается, процесса его изготовления. Отдельно взятому человеку очень трудно разобраться во всём этом разнообразии. Требования наследуются в ходе разработки, они могут быть связаны друг с другом. Каждое требование необходимо выявить, сопоставить с другими и так далее. Нужны автоматизированные системы, которые помогают работать над таким сложным проектом.

Платформа 3DEXPERIENCE и другие средства

Платформа 3DEXPERIENCE позволяет совместно работать с требованиями и включает в себя инструменты их формализации, привязки требований к элементам состава изделия, состава проекта разработки и испытательных работ. Всё это дает возможность не просто вести учёт требований, а с целью принятия осознанных решений анализировать требования по затратам и результатам от их реализации.
Решение CATIA Magic позволяет выявить и проанализировать потребности заинтересованных сторон, участвующих в производстве, вводе в эксплуатацию, в самой эксплуатации изделия, и выводе из нее. Все это обеспечивает полноту и правильное представление требований с самого начала жизненного цикла изделия, а именно недостаточная полнота и представление требований, как мы уже знаем, являются источником 2/3 ошибок в проектировании изделия.
Решение Stimulus ещё на ранних стадиях разработки еще на уровне определения требований моделирует поведение системы и анализирует взаимозависимость и реализуемость требований. Однако для такого моделирования необходимо должным образом сформулировать требования.



Самый современный подход к разработке сложных изделий это основанный на моделировании моделей системный инжиниринг (MBSE, Model-based System Engineering). Требования один из трех китов, на которых базируется MBSЕ, без реализации которого невозможен системный инжиниринг.

Платформа 3DEXPERIENCE обеспечивает прозрачность требований в связке с методиками определения соответствия, прозрачность хода испытаний и их результатов. Система построена на рекомендуемом в системном инжиниринге подходе RFLP, что дает возможность на ранних стадиях провести имитационное моделирование и расчёты, выполнить анализ систем и внести необходимые изменения ещё в цифровой среде. А цифровые изменения, как известно, на порядок-другой дешевле натурных.
Функционал платформы 3DEXPERIENCE выходит далеко за рамки учёта требований, а именно:

• Составление спецификаций требований с ранжированием;
• Составление программы испытаний;
• Планирование и управление ходом работ по программе испытаний;
• Управление результатами испытаний с корреляцией результатов виртуальных и натурных испытаний;
• Наглядное отслеживание хода выполнения программы испытаний и результатов определения соответствия требованиям.

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

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

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

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

Подписывайтесь на новости Dassault Systmes и всегда будьте в курсе инноваций и современных технологий.

Dassault Systmes официальная страница

Facebook
Vkontakte
Linkedin
3DS Blog WordPress
3DS Blog on Render
3DS Blog on Habr

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

Источник

Рамки исследования

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

Дж. Коплиен

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

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

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

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

Однако конкретность желаний заказчика не является гарантией того, что ему понравится конечный результат. В ходе моих проектов была выявлена следующая закономерность: все функциональные замечания заказчика, зафиксированные в ходе всех видов испытаний (не путать с выявленными ошибками!), касались требований, по которым превентивно не было согласовано с заказчиком проектное решение. В этом отношении показательна статистика, которую приводит Наталья Руколь, когда при анализе результатов одного из проектов выяснилось, что почти 70% выявляемых на стадии сдачи ошибок вызваны непониманием исходных требований со стороны разработчиков.

Казалось бы, после того, как уточнены требования к программному продукту, нужно сформировать пакет проектной документации в соответствии с ГОСТ РД 50-34.698, согласовать ее с заказчиком и потом разработать ПО в полном соответствии с утвержденным проектом. Зачастую именно о такой последовательности действий приходится слышать от вчерашних студентов-отличников (троечники, как правило, вообще не знают о существовании таких документов) и многих опытных топ-чиновников, которые никогда не несли персональной ответственности за конечный результат разработки программного обеспечения.

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


Источник

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

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

Проектные решения VS проектной документации?

Как всё прекрасно на бумаге,
Как легко следовать словам.
Как просто сделать так, что ты непогрешим.

Б. Гребенщиков

Несмотря на то, что определение понятия проектное решение дано в ГОСТ 34.003-90, в моем случае значение этого понятия было открыто в ходе мучительных и безрезультатных попыток согласования с представителями заказчика нескольких взаимосвязанных, но неоднозначных требований, когда клиенты просто игнорировали предлагаемые нами описания постановки задач (ОПЗ), сформированных в строгом соответствии с РД 50-34.698-90. После осознания того, что решение со стороны заказчика не будет принято вплоть до начала испытаний, был предпринят следующий манёвр: в адрес заказчика было отправлено наше проектное решение (т.е. решение, которое формально он был не обязан согласовывать).

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

Получившийся коктейль одновременно по форме был похож на документ, оформленный в соответствии с требованиями РД 50-34.698-90, однако по факту он не соответствовал ни одному из форматов, приведенных в этом ГОСТ. При этом, то, что было в нем написано, понимал обычный, неподготовленный представитель заказчика. Требования, уточненные в этом документе, были совершенно понятны как для заказчика так и для исполнителя. Были определены границы требований, необходимый объем планируемых работ и чем собственно эти работы должны были завершиться.

В сопроводительном письме присутствовала примерно такая фраза:

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

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

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

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

Описание слона не по ГОСТ

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

Фредерик Брукс

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


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

1. Перечень требований заказчика (которые будут реализованы в рамках проектного решения).
2. Список определений и сокращений.
3. Перечень нормативных документов, регламентирующих автоматизируемый процесс.
4. Описание порядка применения программного обеспечения (use case), которое может включать:
   
   описание автоматизируемого процесса (как правило, в формате BPMN не забывайте отмечать, как выполняется то или иное действие: автоматически, автоматизировано или вообще без компьютера) и предполагаемого результата;
   перечень ролей и их полномочий;
   определение необходимости ведения истории изменения объектов учета (необходимость хранения и последующего анализа предыдущих значений атрибутов объекта) пренебрежение данным пунктом может увеличить время разработки в разы;
   определение необходимости протоколирования действий пользователей (определение таких действий, связь с историей изменения объекта).
5. Описание доработки:
   
   описание новых классификаторов и требования по доработке имеющихся, определение порядка их сопровождения;
   описание пользовательского интерфейса (UI) и правил его отображения (в случае, если в рамках проектного решения определяются схемы процессов, все экранные формы должны быть связаны с действиями на этих схемах);
   описание печатных отчетов и правил (алгоритмов) их формирования.
6. Электронный обмен данными:
   
   описание форматов и регламента взаимодействия через API;
   описание форматов и регламента (последовательности) загрузки внешних данных в ручном режиме (в виде файлов);
   описание форматов и регламента (последовательности) выгрузки данных в ручном режиме в виде файлов.
   
   В качестве примеров проектного решения по электронному обмену данными может здорово пригодиться пакет стандартов, разработанный некоммерческим партнерством Стандарты некоммерческого обмена информацией (партнерство распалось в 2011 г., в настоящее время эти стандарты продолжает сопровождать компания 1С). Также могут помочь нормативно-эксплуатационные документы, размещенные на техническом портале Системы межведомственного электронного взаимодействия (СМЭВ).
7. Определение полномочий доступа:
   
   определение атомарных действий, по которым должно (может) производиться ограничение доступа, определение иерархии этих действий;
   определение перечня атрибутов объекта, по которым должно (может) производиться ограничение доступа.
8. Сценарий (синопсис) проведения тестирования, который включает последовательность выполнения и названия отдельных тестовых заданий, а также ожидаемый результат выполнения этих тестовых заданий. При наличии времени на проектирование в этот раздел могут включаться описание тестовых заданий (по шагам) и краткое описание тестовых данных. Именно в этом разделе должны находить отражение пользовательские истории (собранные и запротоколированные во время проведения информационных обследований), начальные условия выполнения программы, условия (ограничений) успешного завершения, альтернативные варианты завершения процесса. Сценарий проведения тестирования в обязательном порядке должен быть узнаваем со стороны заказчика.

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

Лучше один раз увидеть

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

Виллард Британ

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

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

1. Прототипирование пользовательских интерфейсов позволяет более точно определить сроки реализации функционала. Согласно статистике, точность экспертной оценки сроков программного проекта, выполненной на основе утвержденных макетов UI, в несколько раз выше, чем точность оценки на основе концептуальных требований технического задания.
   
   
   
   Источник: Стив Макконел. Сколько стоит программный проект. ISBN: 978-5-91180-090-1
2. Грамотный UX-дизайн позволяет обеспечить формирование проектной и эксплуатационной документации еще до завершения кодирования. Сразу после согласования проектного решения, параллельно с разработкой, становится возможным формировать руководство пользователя (замена макетов интерфейса на скриншоты осуществляется во время выполнения задач тестирования).
3. Фиксация макетов пользовательского интерфейса облегчает нахождение решения спорных вопросов при определении новизны требований. Если на согласованном макете UI не было поля, значит, его добавление это новое требование, выходящее за рамки согласованного проектного решения (следующий пример раскроет последствия добавления всего лишь одного поля на форму).
4. Иногда, форма внезапно может оказать существенное влияние на содержание. Описанный далее случай произошел на четвертой неделе активного UX-проектирования и регулярного обсуждения с заказчиком макетов пользовательского интерфейса одной из подсистем АСУ. Заказчик охотно шел на общение, были уже предварительно согласованы схемы основных процессов и более 80% экранных форм. Мало того, чтобы ускорить разработку была уже создана база данных и по отдельным задачам в полную силу работали программисты. На одном из рабочих совещаний вдруг заместитель начальника управления (для которого собственно и создавалась подсистема) спросил: А где у вас тут поле даты?. Как выяснилось, он имел в виду, что программа должна иметь возможность отразить состояние дел (или сформировать отчет) на любую произвольную дату, и это при том, что ведение истории изменений ранее не обсуждалось. Все представители заказчика подразумевали, что это было совершенно очевидно и не требовало дополнительных пояснений. В результате небольшое замечание увеличило время разработки подсистемы почти в два раза. Надо отметить, что макеты форм практически не изменились, просто на некоторых добавилось поле По состоянию на дату Х.

Источник

Хотелось бы сказать несколько слов о принципах проектирования пользовательских интерфейсов для автоматизированных систем управления. Несмотря на лавинообразный рост использования мобильных устройств, для автоматизированных систем управления, применяемых в государственных учреждениях, настольные компьютеры и ноутбуки остаются вне конкуренции (так же, как и для решения задач программирования и системного администрирования). В настоящее время для прототипирования интерфейсов появилось множество разнообразных средств. Однако за разъяснением особенностей применения Figma или Axure в интересах мобильных устройств теряются 10% примитивных способов, которые позволяют проектировать 90% пользовательских интерфейсов АСУ.

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

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

Я не буду приводить здесь пример интерфейса IntelliJ IDEA или PhpStorm, однако попробую препарировать на составные части основные составляющие такого UI, с точки зрения аналитика автоматизированной системы управления.

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


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

В рамках описания любой списковой формы при проектировании должны быть определены:

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

При проектировании списковых форм хорошо зарекомендовали себя следующие правила:

1. Все элементы управления формой должны располагаться в верхней части в форме панели инструментов при этом вероятность того, что пользователь потеряет их, сводится практически к нулю. При этом практика показала целесообразность отказа от строки иерархического меню в пользу ленточного интерфейса (ribbon).
2. Для всех списков, как правило, на ленте должны присутствовать четыре группы элементов управления:
3. При формировании статистических отчетов (в т.ч. и для вывода на печать) желательно не создавать специализированные формы для предварительной настройки этих отчетов. Сама списковая форма с ее возможностями выборки, сортировки и отображения объектов должна обеспечивать предварительную настройку требуемых отчетов. Другими словами по возможности отчеты должны формироваться на основе выбранных критериев при формировании списков.

В рамках описания карточки объекта при проектировании должны быть определены:

• макет карточки просмотра;
• перечень действий, которые можно произвести с объектом учета (CRUD, изменение статуса, согласование и т.п.) и требуемые для этих действий полномочия доступа;
• описание правил валидации атрибутов при добавлении/редактировании;
• перечень возможных информационных сообщений;
• способы просмотра истории изменений объекта.

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

1. В случае, если в ходе разработки требуются изменения уже существующих интерфейсов, не стоит изобретать велосипед. Здесь лучше всего себя проявил Paint.NET (с помощью которого, кстати, подготовлены картинки к этой статье). Не имеет смысла заново перерисовывать формы, проще изменить готовый скриншот.
2. Если вы разрабатываете новый интерфейс пользователя, а ваш заказчик бумажная крыса, в таких случаях лучше всего себя зарекомендовал MS Visio со стандартным набором элементов управления. Не раз видел, как заказчик, который наотрез отказывался посмотреть разработанный интерактивный прототип, увлеченно обсуждал предлагаемые проектные решения, выполненные с использованием MS Visio, и рисовал очень интересные каракули на макетах, распечатанных на бумаге в цвете, выполненных в стиле привычного ему Windows.
3. Если вы разрабатываете новую подсистему, а ваш заказчик - продвинутый пользователь, то интерактивные прототипы вне конкуренции. При этом с наилучшей стороны показал себя подход, когда эти прототипы строятся на основании того же самого фреймворка, который используется для создания интерфейса пользователя. В случае одного из моих успешных проектов прототип программного обеспечения строился на основе инструментов DHTMLX. Вместо базы данных для имитации работоспособности использовались статичные XML-файлы, сформированные на основе примеров таблиц, которые предоставил заказчик. Представления (view), созданные аналитиками в ходе прототипирования, использовались как заготовки для работы программистов. За счет низкого порога вхождения по использованию данного фреймворка, трудозатраты аналитиков на создание прототипов пользовательского интерфейса были соизмеримы с трудозатратами, если бы те же макеты экранных форм создавались в MS Visio. Правда, при этом некоторые представители заказчика не понимали, что еще надо программировать после того, как им продемонстрировали рабочую программу.

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

Строительные леса и опалубка

Обычно люди очень много думают. Но беда в том, что они думают о проблемах, а не о решениях этих проблем.

Дэвид Аллен

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

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

Источник

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

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

• Анализ документов отчет по результатам анализа нормативных документов заказчика или проектной документации.
• Аналитический обзор отчет по результатам анализа путей решения возникшей проблемы (как правило, сравнительный анализ новых технологий или тенденций рынка).
• Информационное обследование отчет по результатам проведенного исследования существующих бизнес-процессов заказчика (формирование модели as is как есть).
• Системный анализ материалы, описывающие в терминах разработчиков способ реализации требований заказчика одного из вариантов использования программного обеспечения (use case). Этот же тип аналитической работы организуется в случае необходимости реинжиниринга legacy-кода.
• Анализ данных отчет по результатам исследования качества данных, загруженных в систему (выявление ошибок и противоречий).
• Учебные материалы материалы, подготовленные для проведения обучения сотрудников заказчика или членов проектной группы.

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


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

План для маэстро

Всё должно быть изложено так просто, как только возможно, но не проще.

Альберт Эйнштейн

Зачастую, когда речь заходит о планировании работ по анализу и программированию, возникает множество споров о том, как можно оценить сроки получения результатов в этом случае. Однако проведенный выше анализ этой творческой деятельности позволяет сделать предположение о том, что в рамках программного проекта это все-таки возможно. Первым шагом к этому становится разбиение работ по проектированию системы на части, которые можно проконтролировать с периодичностью не менее раза в неделю. Необходимо стремится к тому, чтобы трудозатраты аналитика на формирование одного проектного решения не превышали 5 рабочих дней (в терминах объема такое проектное решение должно состоять примерно из 20-30 страниц согласно ГОСТ Р ИСО/МЭК 15910-2002). Соответственно по тем же нормативам на рецензирование того же проектного решения у программиста должно уходить максимум 3 часа.

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

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

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

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


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

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

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

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

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

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

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

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

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

4.После согласования с заказчиком (письмо, подтверждающее этот факт, сохраняется в JIRA), задачу по подготовке проектного решения можно переводить в статус выполнено.

Продолжение следует

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

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

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