│Крупный │ 6-8 │ 4-5 месяцев │ 350-500 │
└────────────┴────────────────────┴───────────────────┴─────────────────┘
Вне зависимости от модели организации работы на проекте и степени вовлеченности внешних консультантов в проект с самого начала необходимо организовать регулярное и эффективное взаимодействие проекта с высшим руководством организации. Это позволит облегчить принятие требуемых решений, будет способствовать повышению статуса проекта, явится источником дополнительной мотивации и повышения ответственности участников проекта. Реализация такого взаимодействия обычно происходит в следующих формах.
Проектный комитет - орган управления проекта, который должен состоять из представителей высшего менеджмента организации, бизнес-менеджмента и менеджера проекта. Он должен периодически собираться для принятия и утверждения самых важных решений по ходу проекта. Периодичность зависит от фазы проекта, но в целом это не должно происходить реже, чем раз в месяц. Менеджер проекта докладывает комитету об основных результатах работы, текущем состоянии проекта, основных проблемах, принятых решениях, ситуациях, требующих решения комитета и выходящих за компетенцию менеджера. В процессе заседания комитета ведется протокол, который затем предоставляется всем участникам и заинтересованным лицам и является официальным документом для банка, проекта и подрядчиков.
Спонсорство - важный элемент проекта. Для проекта должен быть назначен спонсор (куратор), лицо из высшего руководства, один из членов проектного комитета, обычно близкий бизнес-подразделениям, который будет более активно взаимодействовать с менеджером проекта для помощи и консультирования. Он должен быть представителем руководства, уполномоченным принимать любые решения, который будет больше всех других высших менеджеров организации в курсе хода проекта и его проблем. Обычно это человек, который выступал инициатором проекта среди руководства или поддерживал его с самого начала.
Периодическая отчетность. Руководитель проекта должен готовить для информирования всех заинтересованных сторон о ходе работ специальные отчетные формы. Периодичность их зависит также от состояния проекта, но в общем должна быть чаще, чем заседания проектного комитета. Может быть рекомендована следующая схема. Если проект испытывает сложности, имеет место срыв сроков, недостаток бюджета и т.п., то отчетность должна предоставляться еженедельно. Если проблемы у проекта есть, но не очень значительные, отчетность составляется раз в две недели. И если у проекта нет каких-либо проблем, способных повлиять на срок, бюджет, то раз в месяц. В отчетах должен быть в удобной форме отражен текущий статус проекта, этап и его фаза, основные ближайшие контрольные точки, выполненный по сравнению с предыдущим отчетом объем работ, достижения проекта за период, основные риски, проблемы, действия по их минимизации и решения, открытые вопросы, прогноз по выполнению сроков и бюджета.
Задачей разработки программного обеспечения является построение систем, отвечающих требованиям бизнеса и обеспечивающих максимум преимуществ от их использования. В то же время эти системы должны создаваться с учетом их дальнейшего сопровождения, требований к производительности и качеству. Организация, осознавая всю важность использования информационных технологий, ставит перед собой цель создать базу для разработки и внедрения программного обеспечения, отвечающего вышеуказанным задачам.
Данная глава описывает основные требования к разработке программного обеспечения как собственными разработчиками, так и с использованием сторонних организаций. Кроме того, в ней определены обязательные этапы при создании и внедрении программных продуктов, требования к документированию каждой стадии и контролю качества продукта. Тестирование и внедрение, являясь составными частями разработки, будут рассмотрены в специально выделенных для этого главах. В настоящей главе мы не будем делать различий между разработкой программного обеспечения, его модификацией, доработкой и настройкой. Мы будем считать, что все перечисленные подходы входят в понятие разработки, являясь методами ее технического осуществления.
Итак, каковы основные участники процесса разработки?
Заказчик - подразделение организации, у которого возникла необходимость в разработке нового или изменении существующего программного обеспечения. Также в качестве заказчика может выступать организация в целом.
Разработчик - проектная команда, сформированная на основе службы ИТ или сторонней организации, непосредственно работающая над разработкой, изменением и внедрением программного обеспечения.
Контролеры - сотрудники организации (кроме непосредственно разработчиков), осуществляющие наблюдение за созданием продукта. Контролерами могут выступать начальники подразделений или назначаемые ими сотрудники подразделения. Если заказчиком является организация, то контролеры назначаются руководством. Для больших проектов, важных для бизнеса, возможно привлечение в качестве контролеров сторонних консультантов.
Аналитики - специалисты в области банковских технологий, участвующие в постановке задачи и консультировании всех сторон в ходе проекта.
Одним из первых важнейших требований является документирование всех этапов процесса разработки программного обеспечения, начиная с постановки первоначальных требований и заканчивая вводом в эксплуатацию и дальнейшим сопровождением. Документы, возникающие в процессе разработки, такие, как спецификации, планы разработки, руководство пользователя, являются неотъемлемой частью программного продукта. Заказчик вместе с программным продуктом должен по возможности получать всю документацию, связанную с разработкой продукта. Документирование процесса разработки ведется с целью облегчения процесса сопровождения, доработки и контроля качества продукта. В случае смены разработчика проектная документация должна обеспечить дальнейшую эффективную работу с программным продуктом.
Качество документации должно отвечать следующим критериям:
* правильность:
- соответствие (трассируемость) требований и спецификаций соответствующей системе, и наоборот;
- последовательность в описании требований, спецификаций и функций;
* полнота:
- использование версий и дат документов для контроля изменений, доступность всех версий документов (в том числе рабочих);
- функциональность системы должна быть максимально полно описана в системных требованиях;
- документация должна предоставлять информацию для всех категорий пользователей, операторов системы и разработчиков;
* удобство и простота использования:
- использование оглавлений, алфавитных указателей, глоссариев и кросс-ссылок;
- логическая последовательность и непротиворечивость в использовании терминологии;
- уместный внешний вид документации (шрифты, формат).
В то же время необходимо, как уже отмечалось, избегать излишней бюрократизации, другими словами - в зависимости от цели проекта набор, состав и объем документов должен меняться.
Применительно к исходным кодам программ, которые по сути являются документацией к системе, также должны во многом выполняться вышеуказанные требования. Исходные коды разработанных для банка систем (как силами собственных программистов, так и сторонними организациями) должны по возможности предоставляться вместе с системой и документацией к ней. Это условие необходимо включать в договора на разработку программного обеспечения и в служебные инструкции разработчиков. Исходные коды должны содержать комментарии в количестве, необходимом для понимания структуры исходного кода и функциональности каждого модуля, подпрограммы или класса. Код программы должен писаться с учетом дальнейшего сопровождения и возможного расширения функциональности системы.
Программный код должен быть отформатирован в едином стиле. В общем случае утвержденные и используемыми всеми разработчиками стандарты кодирования содержат следующие составляющие:
* принципы форматирования программного кода, включая использование структурированного расположения текста и отступов между строками кода для удобства считывания. Комментарии в коде должны давать краткое описание функциональности программ, модулей, классов, методов класса и т.п., а также описывать формат и назначение входных и выходных данных;
* соглашения о стиле программирования должны, в частности, описывать стандарты именования переменных, констант, классов и т.д. Должен применяться общий подход к использованию внутренних переменных, констант и структур данных (таких, как массивы). Все это поможет созданию предсказуемого и легко читаемого кода, с которым было бы несложно работать как на этапе разработки, так и в ходе модификации и дальнейшего сопровождения; приемы написания эффективного кода. Эти правила могут быть связаны с использованием эффективных структур данных и алгоритмов, созданием максимально производительных запросов к базам данных и т.п.
Представители заказчика обязаны принимать участие и контролировать процесс разработки на всех этапах. Должны быть назначены представители заказчика (подразделения организации или выделенные эксперты), отвечающие за разработку, - контролеры. Это могут быть сотрудники банка, знающие в деталях бизнес-процессы, для поддержки которых создается система, сотрудники службы информационных технологий или сторонние консультанты. Для максимальной отдачи от внедрения разрабатываемых систем крайне необходимо тесное взаимодействие с разработчиками.