Главная | Обратная связь | Поможем написать вашу работу!

Взаимодействие с руководством

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

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

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

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

Глава 6. Разработка решений

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

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

Итак, каковы основные участники процесса разработки?

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

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

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

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

Документирование

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

Качество документации должно отвечать следующим критериям:

• правильность:

— соответствие (трассируемость) требований и спецификаций со-
ответствующей системе, и наоборот;

— последовательность в описании требований, спецификаций и фун-
кций;

• полнота:

— использование версий и дат документов для контроля изменений,
доступность всех версий документов (в том числе рабочих);

— функциональность системы должна быть максимально полно опи-
сана в системных требованиях;

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

• удобство и простота использования:

— использование оглавлений, алфавитных указателей, глоссариев
и кросс-ссылок;

— логическая последовательность и непротиворечивость в исполь-
зовании терминологии;

— уместный внешний вид документации (шрифты, формат).

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

Исходные коды

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

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

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

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

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

⇐ Предыдущая 34 35 36 37 383940 41 42 43 Следующая ⇒