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