Как составить проектное решение

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

Источник

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

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

Дж. Коплиен

Поскольку на текущий момент на рынке труда в 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. Для всех списков, как правило, на ленте должны присутствовать четыре группы элементов управления:
   • действия с одной записью из списка — как правило, эти действия сводятся к аббревиатуре CRUD: добавление, просмотр, редактирование, удаление;
   • режимы просмотра (как правило, здесь располагаются элементы управления группировкой и фильтрацией списка);
   • групповые операции;
   • сервисные функции (вызов справки, пользовательская настройка списка, сбор предложений по доработке).

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-страничный технический проект за одну ночь. Расхлебывать результаты таких «проектных решений» приходится, как правило, совсем другим людям.

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

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

Послесловие 

С 12 февраля 2019 года стандарт «РД 50-34.698-90.Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов» является не действующим.

В настоящее время прямой замены РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов» не выявлено.
Содержание каждого документа, разрабатываемого при проектировании АС согласно ГОСТ 34.201-89, определяет разработчик в зависимости от объекта проектирования (системы, подсистема и т.д.).
Содержание документов, разрабатываемых на предпроектных стадиях по ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания», в том числе организационно-распорядительных, определяют разработчики в зависимости от объема информации, необходимой и достаточной для дальнейшего использования документов.
Письмо Росстандарта № 8262-ИК/03 от 08.05.2019

P.S. Эта статья входит в цикл статей под названием «Правила своевременного приготовления вкусного программного обеспечения», который я использую как неформальный регламент команды на заказных программных проектах, в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо. Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI. В блоге проекта SMART-UP вы можете ознакомится с актуальным содержанием этой серии статей, с учетом изменений и уточнений произошедших после публикации этой статьи на Habr.

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

Необходимо ли согласование?

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

Когда разрабатывают проектное решение?

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

На основании чего составляется?

Государственными органами создается специальная комиссия, которая в результате проведенного мониторинга и обследования подготавливает необходимые документы. Разработка проводится на основании нормативно-правовой базы, регулирующей данный процесс, и на основании ГОСТа Р 21.1101-2013 «Основные требования к проектной и рабочей документации».

Что включает в себя процесс разработки?

Процесс включает в себя несколько последовательных этапов. К ним относятся:

1. Экспертиза, в ходе которой определяется техническое состояние объекта.
2. Изучение строительной площадки.
3. Разработка проектного решения и передача его заказчику. При необходимости, доработка.
4. Согласование проектного решения с заинтересованными сторонами.
5. Производство работ.
6. Корректировка проекта (поправки, изменения) в процессе строительства, если нужно.

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

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

Сколько по времени годны результаты экспертизы?

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

Для кого разрабатываются проектные решения?

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

Смотрите также:

• Негосударственная экспертиза
• Экспертиза смет
• Негосударственная экспертиза инженерных изысканий
• Негосударственная экспертиза проектной документации

Что нужно для составления SD

Потребность в данном документе возникает, когда

доработке подвергается сразу несколько систем

.

Проектное решение (Solution Design) составляется на основе: Бизнес- и Пользовательских требований или Vision.

Цепочка аналитических артефактов и место Проектного решения в ней:

Памятка:

Шаблон проектного решения

Суть решения

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

Сценарии использования решения

Содержание раздела должно отвечать на вопросы:

• какие функциональные возможности реализует проектное решение?
• кто и как будет их использовать после внедрения?

Описывается:

• какие пользователи (Роли) будут работать с новым/измененным решением;
• сценарии использования (Use cases) решения (основной и важные альтернативные). Use cases разрабатываются на основе Бизнес-требований и модели “ToBe” Бизнес-процессов, приведенных в концепции;
• основные пользовательские и системные функции решения.

Например:

#	Acteur (Действующее лицо)	Verbe (Шаг, действие)	Objet (Объект воздействия)	Objectif (Целевой объект)
1	Клиент	подаёт	заявку на Продукт/Услугу	эксперту в офисе
2	Эксперт	регистрирует	заявку	Карточка Клиента в Системе
3	Система	присваивает	номер заявки	Карточка Клиента в Системе
N	…	…	…	…

Архитектура проектного решения

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

Могут быть приведены несколько вариантов проектного решения. В этом случае должны быть описаны достоинства и недостатки каждого варианта.

• Модель + Описание (если требуется). Описание может включать в себя:
  • cсылки на архитектурное описание существующих компонентов (н-р, “для реализации этого кейса мы используем существующий компонент Системы1”)
  • ссылки на раздел с описанием интеграционного слоя (н-р, если у нас новый интерфейс, либо старый изменился)
  • перечень необходимого оборудования
• Достоинства/Недостатки

Логическое представление

Для описания логической модели проектного решения может быть использован язык моделирования Archimate. Модель должна демонстрировать:

• все перечисленные use cases;
• какими компонентами слоя приложений будут реализованы use cases;
• возможные изменения в инфраструктуре.

Например:

(скачать модель в .archimate)

Физическое представление

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

Интеграционные потоки

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

Например:

Бизнес-логика	Инициатор.ИС	Данные из	Микросервис	Инициатор.Тип взаимодействия микросервиса с транспортом	Транспорт	Тип взаимодействия с конечной ИС	Конечная ИС
из	в
Запрос в систему2 для чего-нибудь	Система1	Система1	Система2	Какой-то там	Асинхронный Request-Response, MQ	шина.адаптер1 –> шина.адаптер2	Асинхронный Request-Response, MQ	Система2

Потребность в оборудовании и его лицензировании

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

Предназначение	кол-во	Характеристики	Окружение, ПО
Web сервер	2	CPU: 16vCPU; RAM: 32Gb SSD: 100Gb	Windows Server 2012 R2

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

Оценка решения

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

Например:

Функциональность (use case)	Система1	Система2	Система3
Печать заявки	+ (30 т.р.)
Фотографирование Клиента	+ (35 т.р.)
Отправка запроса в ПФР		+ (25 т.р.)
Выпуск дебетовой карты			+ (90 т.р.)
ИТОГО:	65 т.р.	25 т.р.	90 т.р.

ИЛИ

№	Состав работ	Трудоёмкость, ч/дн	Стоимость, руб. без НДС
1	Аналитика	220	0,000,000.00
2	Разработка	340	0,000,000.00
3	Тестирование	260	0,000,000.00
4	DevOps	60	0,000,000.00
5	Проектное управление	120	0,000,000.00
6	Риски (10%)	–	0,000,000.00
7	Командировочные расходы	–	0,000,000.00
ИТОГО:	1000	0,000,000.00

И/ИЛИ

Трудозатраты по Системе1	XXX
Трудозатраты по Системе2	XXX
Трудозатраты по Системе3	XXX
Трудозатраты по Системе4	XXX
Асинхронные развязки при обработке команд	+
Маршрутизация, брокер очередей	+
Гарантированная доставка информации по процессам в конечную систему	+
Главный плюс решения:	что-то там
Минусы решения	Добавляется ещё одна ИС (набор микросервисов), которую надо дорабатывать, тестировать и обслуживать. Потребуется закупать мощности для развёртывания и включения в текущие промышленные и тестовые контуры. …

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

Декомпозиция работ

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

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

Например:

ИС	# задачи в СУЗ	Сервис / Бизнес-функция (берётся из Archimate-модели решения)	Функциональность (берётся из разработанных use cases)
Учётная система	XXXX	веб-сервис проверки наличия у Клиента ИНН	отправка запроса к веб-сервису ПФР обработка данных ответа
Учётная система	YYYY	выпуск дебетовой карты и заполнение справочников	…

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

Требуется ли согласование?

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

Когда выполняется разработка проектного решения?

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

На каком основании составляется?

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

Что входит в процесс разработки?

В данный процесс входит несколько этапов:

• проведение экспертизы, для установления реального технического состояния объекта;
• изучение территории строительства;
• разработка решения, его передача клиенту (если требуется – выполняется доработка);
• согласование готового проектного решения со всеми заинтересованными сторонами;
• выполнение работ;
• внесение поправок, корректировок при выполнении работ (если необходимо).

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

Следует учесть, что официально рекомендованного перечня документации не имеется. В нее могут входить все требуемые для проведения работ документы – сметы, текстовые описания, графики, схемы и др.

Какое время результаты экспертизы остаются действительными?

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

Кому потребуются проектные решения?

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

Смотрите также:

• Аудит проектной документации
• Негосударственная экспертиза проектной документации
• Разработка Технологических решений

Оставьте заявку

Заполните небольшую заявку и мы свяжемся с вами сегодня

Пресс-центр компании СЕРКОНС.