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

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

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

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

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

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

• полнота:

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

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

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

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

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

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

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

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

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

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

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

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

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

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