Как только детальное проектирование завершено, можно приступать к реализации. Естественно, если мы вспомним о тех моделях, которые мы рассматривали, в ряде случаев это можно делать чуть ранее, скажем в объектно-ориентированной модели возможно параллельно вести реализацию и проектирование. Но, тем не менее, если говорить о моделях в целом, это происходит именно таким образом. Целью реализации является кодирование модулей, т. е. изготовление программного кода, и тестирование этих модулей в отдельности, каждый из этих модулей в отдельности программистами-разработчиками, которые представляют, естественно, сторону заказчика. При этом опять-таки тестирование предполагает выполнение как требования соответствия внутренней корректности кода, так и требование соответствия тем функциональным задачам, которые были поставлены заказчиком и описаны в документах, которые описывают техническое задание и другие функциональные требования. Кроме того готовятся unit-тесты или тесты для модулей, сценарии тестирования, по которым можно проверить те самые характеристики эксплуатационные, которые должны соответствовать каждому из этих модулей, и план тестирования. Т. е. каким образом необходимо вести тестирование, какие ожидаемые результаты будут получены при тестировании каждого из модулей и что делать, если эти результаты не соответствуют ожиданиям. Кроме того что производится код модулей, производиться и построчная документация. Т. е. каждый файл, который описывает модуль, содержит данные о том, кто его создал, когда, с какой целью, с какими модулями он взаимодействует, каким образом он взаимодействует с этими модулями, т. е. какие интерфейсы используются, и ключевые комментарии, которые описывают самые важные особенности функционирования этого модуля: какие алгоритмы будут использованы, как используются те или иные структуры данных и так далее. Нужно отметить, что кодирование не является существенным с точки зрения вклада в стоимость. Это может быть 5 % от всех затрат на создание программного продукта. Тестирование, естественно, позволяет увеличить качество кода, и в этом смысле тестирование, безусловно, необходимо. Но имеет смысл соблюдать те границы качества, которые изначально заложены нашими ограничениями. Так что решение о прекращении тестирования каждый раз, особенно в кризисных условиях принимается человеком, который руководит группой тестирования или руководит проектом, необходимо эти границы, возможно, динамически корректировать с учетом кризиса. И, естественно, это решение должно приниматься на основе анализа метрик. Часто это относительно простые метрики. Сложность программного продукта или определенного модуля может определяться просто количеством строк кода. Но, тем не менее, в ряде случаев эти метрики достаточно эффективны. В любом случае по завершении реализации мы получаем программный код модулей, который индивидуально протестирован.