Проектирование бизнес-приложения: Процесс разработки ПО
Итак, архитектура системы создана. Теперь необходимо воплощать полученные идеи в жизнь. Но торопиться здесь тоже не стоит.
Первоначально необходимо определить последовательность реализации требований. Первыми пойдут требования для построения разработанной архитектуры – будем строить скелет системы. Далее должны идти требования от наиболее важных к наименее важным. Для каждого требования должны быть созданы задачи на реализацию, а для каждой задачи должна быть проставлена оценочная трудоемкость реализации.
При планировании реализации не следует убеждать себя в том, что мы реализуем все требования в первой версии системы. Часто бывает, что появляются неучтенные факторы, которые отодвигают выпуск системы. К тому же часто заказчик системы на этапе сбора требований не всегда четко представляет конечный результат, а проверка реализации дает коррективы в требования. Так же возникают ситуации, когда требования меняются, например, из-за изменений в законах.
Чтобы упростить процесс разработки следует разбить весь проект на итерации. При этом каждая итерация должна продолжаться от одной до четырех недель (в зависимости от сложности подлежащих реализации требований). По итогам каждой итерации должно выполняться тестирование, а для ключевых выпусков (beta, release candidate) осуществляться демонстрация заказчику в целях получения отзывов о системе.
Теперь вернемся к программированию. Каждый программист получает задачу и приступает к ее реализации. Первоначально программист должен еще раз проверить оценочную трудоемкость и при необходимости откорректировать ее. Далее он должен реализовывать задачу в максимально короткие сроки с наивысшим качеством.
Что значит «реализовывать задачу в максимально короткие сроки с наивысшим качеством»? А значит это следующее:
- Программист должен сосредоточиться на одной задаче и целиком посвятить себя ей до завершения работ. Редкие люди могут делать одновременно два дела, а частое переключение не позволяет работать эффективно.
- Программист не должен самостоятельно додумывать нечетко описанные требования или задачи – для этого есть аналитики и архитекторы, в обязанность которых входит получение однозначных, непротиворечивых и полных требований к системе.
- Если поставленная задача не является типовой, то ее следует обсудить в команде разработки (например, за чашкой чая) – часто кто-нибудь уже реализовывал подобную задачу в своей практике или знает уже частично или полностью реализованное решение (часто бывает проще купить какой-то компонент, чем изобретать велосипед и платить за это лишние деньги).
- Когда выбран вариант реализации, то его следует обсудить с архитектором и коллегами по команде, т.к. иногда решение может не вписываться в архитектуру или негативно влиять на соседние компоненты системы, разрабатываемые коллегами.
- Реализация задачи должна обязательно сопровождаться тестирование. Наиболее эффективном способом является автоматизированное юнит-тестирование (unit tests) и проверка покрытия кода (code coverage). Но и о ручной проверке так же не следует забывать, т.к. не всегда программист может учесть в юнит-тесте всю необходимую проверку.
Итак, задача реализована. Что дальше? Дальше наиболее оптимальным вариантом является проверка написанного кода тим-лидером или другим программистом (желательно, более опытным для проверки эффективности реализации, а менее опытному для повышения уровня). По результатам проверки задача может быть отправлена на доработку по замечаниям.
После реализации задачи она должна передаваться на документирование и функциональное тестирование.
Документирование подразумевает создание как минимум двух документов:
- инструкции пользователя – полное руководство по использованию системы с точки зрения пользователя.
- инструкции администратора – полное руководство по установке, настройке и поддержанию системы в работоспособном состоянии.
Функциональное тестирование состоит из:
- Создания тестов для проверки требований. Обычно создаются комплексные тесты, проверяющие несколько требований.
- Проверки инструкций на достаточность, легкую воспринимаемость и соответствие требованиям и тестам.
- Проведение тестов по установке, настройке и использованию системы.
По результатам проводимых тестов задачи могут отправляться на доработку или приниматься решение о выпуске стабильного или промежуточного дистрибутива системы.
Поделиться в соц. сетях
Похожие статьи: