Home

Автор: К. Хенинджер

Heninger К. L. Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, vol. SE-5, № 1, January 1980, 2-13.

Эта статья посвящена новым методам, позволяющим сделать описания требований точными, краткими, однозначными и легко проверяемыми на полноту и непротиворечивость. Методы хорошо подходят для сложных программных систем реального времени; они были разработаны для документирования существующего полетного программного обеспечения самолета А-7 ВМС США. В статье приводится обзор информации, входящей в состав описания требований, и обсуждаются цели, поставленные при разработке методов. Описание каждого метода иллюстрируется примерами из документа, содержащего требования к программному обеспечению самолета А-7. Цель этой статьи состоит в том, чтобы представить указанный документ как модель дисциплинированного подхода к описанию требований, а сам документ может служить полностью проработанным примером применения этого подхода.

Резюме

Эта статья посвящена новым методам, позволяющим сделать описания требований точными, краткими, однозначными и легко проверяемыми на полноту и непротиворечивость. Методы хорошо подходят для сложных программных систем реального времени; они были разработаны для документирования существующего полетного программного обеспечения самолета А-7 ВМС США. В статье приводится обзор информации, входящей в состав описания требований, и обсуждаются цели, поставленные при разработке методов. Описание каждого метода иллюстрируется примерами из документа, содержащего требования к программному обеспечению самолета А-7. Цель этой статьи состоит в том, чтобы представить указанный документ как модель дисциплинированного подхода к описанию требований, а сам документ может служить полностью проработанным примером применения этого подхода.

I . ВВЕДЕНИЕ

Многие программные системы трудны, для понимания, изменения и сопровождения. Чтобы исправить это положение, был предложен ряд методов разработки программного обеспечения, и среди них такие, как модульность и упрятывание информации, формальные спецификации, абстрактные интерфейсы, взаимодействующие последовательные процессы, средства синхронизации процессов и мониторы управления ресурсами. Разработчики систем неохотно обращаются к этим методам, потому что их полезность еще не доказана для программ с жесткими ограничениями на ресурсы, а также из-за отсутствия для некоторых методов полностью проработанных примеров их применения. Чтобы продемонстрировать практиче­скую пригодность подобных методов и получить полезную модель, в Научно-исследовательской лаборатории ВМС и Центре по испытанию оружия ВМС с помощью вышеперечисленных методов осуществляется повторное проектирование и реализация действующего полетного программного обеспечения для самолета А-7. Новая программа должна пройти те же приемные испытания, что и существующая, а затем две программы будут сравниваться по использованию ресурсов и легкости модификации.

Новая программа должна быть функционально идентична существующей. Это означает, что новая программа должна удовлетворять тем же требованиям, что и старая. К сожалению, когда проект был начат, документации требований для старой программы не существовало: поставляемые с программой спецификации, которые с самого начала были неполными, теперь к тому же устарели. Первым нашим шагом стала выработка полного описания требований к программе для А-7 в такой форме, которая помогала бы в разработке новой про­граммы и легко подвергалась модификации по мере того, как продолжают изменяться требования.

Запись требований оказалась неожиданно сложным делом, несмотря на наличие работающей программы и опытного сопровождающего персонала. Ни один из имевшихся документов не был вполне точным; не было ни одного человека, знавшего ответы на все наши вопросы; на ряд вопросов разные люди давали различные ответы, а на некоторые вопросы нельзя было получить ответов, не проводя экспериментов с существующей системой. В этой ситуации мы сочли необходимым разработать новые методы организации и документирования требований к программному обеспечению, основанные на тех же принципах, что и перечисленные выше методы проектирования программ. Эти методы помогают задавать вопро­сы, вскрывают неоднозначности и поддерживают сквозной контроль полноты и непротиворечивости требований. С помощью этих методов нам удалось добиться достаточно сжатого представления информации и свести несколько книжных полок документации к одному документу объемом 500 страниц. В настоящей статье отражены некоторые из идей, возникших у нас в ходе разработки и применения описываемых методов. Наш подход может оказаться полезным в других проектах как для документирования требований к уже существующим системам, так и в качестве ориентира для поставщиков программного обеспечения, когда они определяют требования к новым системам. Статья дает представление о методах и иллюстрирует их на простых примерах. Тем, кто захочет ознакомиться с методами более детально, мы рекомендуем обратиться к упомянутому документу, кото рый может служить полным примером того, как эти методы работают применительно к достаточно серьезной системе.

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

II. ПОЛЕТНАЯ ПРОГРАММА САМОЛЕТА А-7

Полетная программа самолета А-7 ВМС США работает в условиях жестких ограничений на память и время. Ее объем — примерно 12 000 инструкций языка ассемблера, а исполняется она на ЭВМ системы IBM-PI (модель ТС-2) с объемом памяти 16 кбайт. Мы выбрали эту программу, желая продемонстрировать, что дополнительные затраты ресурсов, связанные с использованием перечисленных выше принципов разработки программных систем, допустимы для систем реального времени, а также потому, что существующую программу, по мнению сопровождающего персонала, трудно мо­дифицировать.

Рассматриваемая программа входит в состав системы навигации и управления оружием самолета А-7. Она получает входные данные от датчиков, переключателей, расположенных в кабине, а также от пилота, который вводит их c помощью специальной клавиатуры. Программа управляет несколькими устройствами отображения информации в кабине и производит установку положения нескольких датчиков. Всего к ЭВМ подключены 22 устройства; в качестве примеров можно указать инерционный измеритель скорости и пилотажно-проекционный индикатор. Последний проецирует символы в поле зрения пилота так, что тот видит их «поверх» панорамы, наблюдаемой через лобовое стекло кабины. Программа вычисляет навигационную информацию, такую, как текущее положение самолета, его скорость и курс; она управляет также применением оружия, подсказывая пилоту нужный курс и вычисляет подходящий момент для применения оружия.

III . ЦЕЛИ ДОКУМЕНТАЦИИ ТРЕБОВАНИИ

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

Ее содержание, организация и стиль зависят от решений, принятых по следующим вопросам:

1. На какие вопросы документация должна давать ответы?
2. Кто ее читатели?
3. Как ее будут использовать?
4. Какие предварительные знания нужны читателю?

Рассмотрев эти вопросы, мы выработали шесть пунктов, определяющих цели нашего документа.

1) Задавать только внешнее поведение.

Описание требований должно задавать лишь внешнее поведение системы и не навязывать какой-либо конкретной реализации. Пользователь или его представитель определяет требования на основе своих знаний об области применения (в данном случае — о навигации и бомбометании). Разработчик программного обеспечения осуществляет реализацию, используя свои знания в обла­сти создания программных систем. Когда требования выражены в терминах возможной реализации, они слишком сильно ограничивают разработчика, иногда не позволяя ему использовать наиболее эффективные алгоритмы и структуры данных. В нашем проекте документ, содержащий описание требований, должен быть в равной степени подходящим для двух совершенно различных реализаций: разрабатываемой нами программы и существующей. Для наших целей этот документ служит формулировкой задачи, которая указывает, что должна делать новая программа, чтобы пройти приемные испытания. А для тех, кто сопровождает существующую программу, он заполняет серьезный пробел в документации: у них нет другого документа, в котором было бы точно определено, что должна делать программа.

Существуют инструкции для пилота, которые содержат пользовательскую документацию по всей системе управления самолетом, в которой рассматриваемая программа составляет лишь малую часть. К сожалению, из этих инструкций трудно понять, какие действия выполняются программой, а какие другими устройствами, а также отличить рекомендации пилоту от ограничений, накладываемых программой. Кроме того, имеется документация по реализации существующей программы: математический анализ алгоритмов, блок-схемы и 12 000 строк на языке ассемблера с редкими комментариями. Однако в этих документах не делается различий между решениями, которые продиктованы требованиями, и решениями, которые разработчик программы вправе изменять.

2) Задавать ограничения на реализацию.

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

3) Быть легко изменяемым.

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

4) Служить справочным материалом.

Основное назначение рассматриваемого документа — быстро давать ответы на конкретные вопросы, а не объяснять в общих словах, что делает программа. Мы предполагаем, что им будут пользоваться опытные программисты. В этих условиях важны точность и краткость. Необходимо предусмотреть глоссарий, детальное оглавление и различного рода указатели. Поскольку учебным материалам свойственные иные черты, такие, как повествовательный стиль, их, если надо, следует разрабатывать отдельно.

5) Прогнозировать жизненный цикл системы.

Мы считаем, что на стадии определения требований разумно пытаться предвидеть дальнейший жизненный цикл программы. Какого рода изменения могут произойти? Какие функции специалисты по сопровождению могут захотеть легко исключать из состава системы? Для любого программного продукта одни изменения сделать легче, чем другие, и соответствующие указания в требованиях помогут разработчику добиться того, чтобы наиболее вероятные изменения были легко осуществимы.

6) Описывать допустимую реакцию на нежелательные со бытия.

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