Пересмотренный план проекта

План проекта также надо пересмотреть с учетом различий между проектом приложения и тем, что удалось реализовать, Хотя план проекта Стадий «Разработка» и ее результаты и не используется в каждодневном управлении, он отражает общие тенденции проекта.

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

Пересмотренный график проекта

Основной график проекта включает сроки выполнения следующих этапов:

• разработка;

• выпуск внутренних и внешних версий продукта;

• тестирование;

• подготовка пользователей;

• сопровождение;

• информирование участников проекта;

• развертывание.

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

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

Пересмотренный сводный документ оценки рисков

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

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

Код и исполняемые модули

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

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

Избежать снижения качества кода помогают стандарты; они:

• вынуждают разработчиков придерживаться единого подхода к кодированию в любых условиях;

• постоянно напоминают разработчикам о важности качества кода.

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

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

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

• именование;

• структура;

• комментарии;

• конкретные требования и запреты.

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

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