Формальные спецификации в процессе разработки по

Определены три уровня спецификации программного обеспечения. Это пользовательские и системные требования и спецификация структуры программной системы. Пользовательские требования наиболее обобщенные, спецификация структуры наиболее детальна. Формальные математические спецификации находятся где-то между системными требованиями и спецификацией структуры. Они не содержат деталей реализации системы, но должны представлять ее полную математическую модель.

По мере разработки спецификации участие заказчика уменьшается, а участие подрядчиков и непосредственно разработчиков ПО возрастает. На ранних стадиях разработки спецификация должна быть ориентирована на заказчика и написана так, чтобы он мог ее понять. Однако на заключительной стадии процесса разработки должна быть получена спецификация, в основном предназначенная для подрядчиков и разработчиков ПО, поскольку она будет служить основой для реализации системы. Эта конечная спецификация может быть формальной.

На рис. 9.1 показаны этапы разработки спецификации ПО и их взаимосвязи с процессом проектирования. Этапы разработки спецификации, показанные на рис. 9.1, не являются независимыми и не обязательно разрабатываются в приведенной последовательности. На рис. 9.2 показано, что разработка, спецификация и проектирование могут выполняться параллельно, когда информация от этапов разработки спецификации передается к «этапам проектирования и наоборот.

Формальные спецификации в процессе разработки по

Рис. 9.1. Разработка спецификации и проектирование

Формальные спецификации в процессе разработки по

Рис. 9.2. Разработка формальной спецификации

Создание формальной спецификации требует детального анализа системы, который позволяет обнаружить ошибки и несоответствия в спецификации неформальных требований. Эта возможность обнаружения ошибок — наиболее важный аргумент для использования формальной спецификации. Проблемы в требованиях, которые остаются необнаруженными до последних стадий процесса разработки ПО, обычно требуют больших затрат на исправление.

Гибкая методология разработки программного обеспечения


Читать еще…

Понравилась статья? Поделиться с друзьями: