подробнее остановимся на том, каким образом идет разработка с точки зрения проектирования продукта, в том числе и корпоративного, если разработчик придерживается инкрементальной модели. Продукт делится на подсистемы, структура и функции каждой из них оговариваются в ТЗ или более простом документе со спецификацией требований и ограничений в системе, и продукт поставляется заказчику в полнофункциональном виде в релизах. При этом каждый релиз подразумевает возможность реальной работы заказчика (всех его видов пользователей и администраторов) с этой системой. Если речь идет о корпоративной системе, то существует достаточно большое количество различных типов пользователей: связанных с составлением отчетов (консолидацией данных), занятых вводом и анализом данных (бизнес-аналитики, извлекающие данные из системы и затем применяющие OLAP-системы для их анализа и выявления трендов), это руководители, которые анализируют консолидированные отчеты по ряду предприятий, производственному кластеру, персоналу, имеется также достаточно большое количество различных администраторов: администратор базы данных, администратор системы, администратор сети, администратор безопасности, все они имеют свои руководства и получают их на каждом релизе в обновленном виде с учетом всех изменений, которые внесены в систему.
Естественно, если путь развития системы предсказуем и соответствует варианту, согласованному с заказчиком, то новая подсистема естественным образом входит в предыдущий релиз. При этом выпускается специальный документ – заметки к релизу (документация к релизу), который включает список всех корректив, внесенных в прежний релиз. В ряде случаев это бывает полезным как важная дополнительная информация о программном продукте, чтобы заказчик или его представители, которые занимаются сопровождением ошибок, их выявлением, локализацией и ликвидацией, консультацией пользователей, смогли корректно перейти от предыдущего релиза к последующему.
На рис. 3.6 представлен вариант инкрементальной модели жизненного цикла, и видно, что каждый релиз включает в себя требования к предыдущему релизу, т. е. функциональность нарастает плавно и таким образом, что следующий релиз в смысле функциональности поглощает предыдущий, добавляя к нему новые возможности. Кроме того, каждый этап наращиваемой разработки продукта, производства нового релиза включает в себя все стадии жизненного цикла программного продукта: это и анализ и спецификация требований, и верификация (сопоставление документации и других элементов проекта с теми требованиями, которые изначально заявлены, проверка их внутренней корректности – полноты, непротиворечивости, ясности), и проектирование (первичное и детальное – детализация до диаграмм классов, атрибутов, переменных, методов, структур классов и, конечно, динамики проекта с помощью диаграмм переходов состояний UML или других нотаций – сетей Петри и т. д.).
Рис. 3.6.
