Основы проектирования корпоративных систем. Сергей Зыков
Читать онлайн книгу.
видно, что каждый релиз включает в себя требования к предыдущему релизу, т. е. функциональность нарастает плавно и таким образом, что следующий релиз в смысле функциональности поглощает предыдущий, добавляя к нему новые возможности. Кроме того, каждый этап наращиваемой разработки продукта, производства нового релиза включает в себя все стадии жизненного цикла программного продукта: это и анализ и спецификация требований, и верификация (сопоставление документации и других элементов проекта с теми требованиями, которые изначально заявлены, проверка их внутренней корректности – полноты, непротиворечивости, ясности), и проектирование (первичное и детальное – детализация до диаграмм классов, атрибутов, переменных, методов, структур классов и, конечно, динамики проекта с помощью диаграмм переходов состояний UML или других нотаций – сетей Петри и т. д.).
Рис. 3.6. Инкрементальная модель жизненного цикла ПО
По завершении проектирования опять осуществляется верификация: происходит проверка и документации – произведенных диаграмм, и других артефактов проекта на соответствие требованиям, которые они должны реализовать на данном этапе этого релиза. Кроме того, производится проверка внутренней корректности документации: все классы, обозначенные на диаграммах первичного проектирования, должны появиться и на диаграммах детального проектирования либо должны существовать какие-то мотивированные изменения в проекте, которые необходимо соответствующим образом задокументировать. По сути, на этой стадии мы уже приходим к заданию на кодирование – стадии реализации. Она, естественно, также полномасштабно осуществляется для каждого релиза программного продукта при этом подходе. Она включает в себя план тестирования (это и модульное тестирование – проверка индивидуального модуля проекта на соответствие спецификациям, и тестирование модулей попарно и в совокупности; так мы приходим к тестированию продукта и, наконец, к той стадии, когда по количеству остаточных ошибок релиз становится достаточно чистым и в соответствии с установленными метриками мы можем передать его заказчику). Дальше производится интеграция, приемочное тестирование и передача на сопровождение. Интеграция производится, естественно, на стадии реализации. Перед передачей осуществляется финальная верификация. Если приемочные тесты заказчика не вполне устраивают, то нужно переработать продукт.
Таким образом, основные стадии жизненного цикла ПО здесь выдерживаются полностью для каждого релиза. Если говорить об эволюционном наращивании функциональности и заказчик требует в определенные сроки пусть и не полностью, но реализованный продукт, то инкрементальная модель – это то что нужно. При этом в ее рамках могут реализовываться продукты как среднего размера (для малых достаточно одного этапа Build-and-fix), так и большие для корпоративных информационных систем.
На рис. 3.7 представлена своеобразная форма