Книга: Программирование мобильных устройств на платформе .NET Compact Framework

Описание проекта

Описание проекта

Для всех проектов разработки программного обеспечения, кроме самых тривиальных, важно иметь единственный "руководящий документ", в котором определяются: 1) требования проекта и целевое назначение завершенного продукта; 2) философия проекта, 3) архитектура приложения; 4) текущее состояние работ в данном направлении; 5) план в соответствии с которым продукт будет переводиться из его текущего состояния в состояние успешного завершения. Для крупных проектов могут предусматриваться дополнительные документы, но всегда должен существовать один основной документ самого верхнего уровня, в котором определяются основные цели проекта, его нынешнее состояние и план работ. Этот документ должен быть реально действующим документом, который, по мнению всех участников группы, правильно определяет направления работы

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

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

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

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

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

Оглавление книги