Переход к реализации

Реализация

Итак, начата реализация модулей. Означает ли это, что работа проектировщиков на этом завершена полностью? На практике это далеко не так. Довольно часто разработчик сталкивается с медленно работающими или не реализуемыми в данной схеме запросами. Подобные ситуации инициируют изменение модели данных, а значит, и информационной модели. Однако изменение информационной модели производится не только по этой причине. Хорошему проектировщику необходим практический опыт работы с аппаратным и программным обеспечением — вот одна из причин участия проектировщиков в составе групп разработчиков. Нередко ведущие сотрудники групп разработчиков одновременно являются проектировщиками. Как можно использовать проектировщиков на этапе разработки? Приведем некоторые примеры:

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

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

· Для крупных проектов характерно поэтапное выполнение работ, так что вполне вероятно, что после завершения реализации группы модулей и сдачи очередного этапа процесс проектирования будет продолжен для новой группы модулей.

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

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

На этапе разработки осуществляется тесное взаимодействие проектировщиков, разработчиков и групп тестеров. В случае интенсивной разработки тестер буквально «пристегивается» к разработчику, фактически являясь членом группы разработки.

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

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

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

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

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

Дата добавления: 2014-01-11