Организация процессов производства информационных систем. Часть 3. Реализация проектного решения

VII Разработка плана реализации и внедрения проектного решения

Блестящим планам везет на проектировщиков.
Скверным планам везет на исполнителей.
Веслав Брудзинский.

На этом этапе процесс вновь начинает крутиться вокруг руководителя проекта. Снова оценка трудоемкости, определение сроков, согласование объемов, утверждение порядка исполнения и т.п.

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

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

1. Уточнение и детализация плана-графика проекта

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


Рисунок 10. – Пример разделов спецификации требований

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

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

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


Рисунок 11. – Пример плана-графика проекта

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

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

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

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

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

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

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


Рисунок 12. – Формирование плана — графика проекта

2. Уточнение оценки затрат на производство информационной системы

По детальному плану-графику проекта, когда доступен полный перечень работ, их объем и определены исполнители, можно довольно таки точно просчитать их стоимость.

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

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


Рисунок 13. – Оценка соответствия плана проекта договору

3. Резюме раздела

Этап планирования и оценки реализации проектного решения включает следующие активности:

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

Рисунок 14. – Артефакты, порождаемые третьим этапом производства программного продукта

Пока то да се, а половина срока уже пролетела, и в пору уже начинать напрягаться по этому поводу…

VIII Реализация информационной системы

Выигрывает сражение не тот, кто придумал план битвы, а тот, кто взял на себя ответственность за его выполнение.
Наполеон

Когда план график сверстан и согласован со всеми заинтересованными лицами, можно приступать непосредственно к воплощению его в жизнь.

Существует множество методологий, описывающих и регламентирующих процесс создания программных продуктов. Мы не будем ограничиваться приверженностью к какой-либо одной методике, а воспользуемся разными подходами. Хотя процесс описанный на предыдущих этапах больше тяготеет к методологии RUP (2), за исключением отказа от возведения Вариантов использования, в ранг мессии процесса проектирования.

Большинство современных методик разработки ПО предполагает итерационный подход.

Итеративный подход (англ. iteration — «повторение») в разработке программного обеспечения — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл PDCA: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).

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

1. Процессы в итерациях по созданию программного продукта

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

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

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

1. Успешные проекты строятся мотивированными людьми. Дайте им подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работу;
2. Самый эффективный метод взаимодействия и обмена информацией – это личная беседа;
3. Гибкие процессы способствуют непрерывному развитию. Все участники проекта должны уметь выдерживать такой постоянный темп;
4. Постоянное внимание к техническому совершенству и качественной архитектуре способствуют гибкости;
5. Простота необходима, как искусство максимизации работы, которую не следует делать;
6. Команда постоянно ищет способы стать более эффективной, путем настройки и адаптации своих процессов.

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

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

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


Рисунок 15. – Выполнение основного тела итерации по разработке ПО

2. Подведение итогов итерации

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

По итогам оценки каждой итерации может потребоваться внесение изменений в план-график проекта, а возможно и в требования.


Рисунок 16. – Подведение итогов итерации по разработке ПО

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

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

3. Передача финального релиза заказчику

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

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


Рисунок 17. – Передача официального релиза заказчику

Этот этап очень интересен и имеет разные варианты решения.

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

Итого, еще 5 дней долой.

4. Резюме раздела

Этап реализации проектного решения, имеет следующие особенности:

1. Реализация проектного решения в больших проектах происходит чаще всего итерационно. Циклически выполняются процессы: Планирование — Реализация — Проверка — Оценка;
2. Каждая итерация заканчивается выпуском релиза, который сам по себе является прототипом целевого продукта с ограниченными функциональными возможностями. С каждой успешной итерацией наращивается функциональность, приближаясь к целевой (оговоренной в контракте);
3. По результатам каждой итерации должен быть выполнен анализ успешности ее проведения, с оценкой как самого продукта, так и процесса его реализации. Желательно, чтобы оценка продукта итерации производилась, совместно с представителями заказчика.

Рисунок 18. – Артефакты, порождаемые этапом реализации программного продукта

Содержание

Часть 1. Отправная точка

Часть 2. Формирование проектного решения

Часть 3. Реализация проектного решения

Часть 4. Внедрение информационной системы

1. Развертывание системы на площадке опытной эксплуатации
2. Обучение персонала заказчика работе с информационной системой
3. Выявление недостатков и дефектов информационной системы
4. Согласование изменений в процессе внедрения информационной системы
5. Доработка информационной системы по итогам опытной эксплуатации
6. Передача информационной системы в промышленную эксплуатацию

Более подробно ознакомиться с материалом можно на: моем Youtub канале, посвященном вопросам: проектирования программных продуктов, ИТ архитектуре и социальной инженерии.

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

1. Вольфсон Борис- «Гибкие методологии разработки»
2. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)
системы»