Технологии инженерии программ

Пятнадцать свойств хороших требований

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

Требования должны быть обоснованными. Каждое индивидуальное требование должно иметь источником идентифицируемую и явно установленную потребность сопричастника.

Требования должны быть корректными *. Любая система, удовлетворяющая требованиям, должна отвечать потребностям сопричастников. Формально это невозможно гарантировать. Неформально нужно быть уверенными, что все сопричастники знакомы с требованиями и согласны с относящимися к ним требованиями.

Требования должны быть полными. Они должны покрывать все потребности сопричастников. В принципе, полнота не проверяема, так как возникает естественный вопрос — полнота по отношению к чему? Любой ответ будет ссылаться на некий более высокий уровень, новый документ, куда и переносится решение проблемы. На практике существуют полезные эвристики, основанные на концепциях, введенных ранее в этой книге.

Почувствуй методологию

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

"Достаточная полнота" - технический термин, введенный в 1978 году в статье Гутта-га и Хорнинга для характеристики свойств абстрактных типов данных, теоретической основы ОО-программирования.

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

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

Требования должны быть недвусмысленными. Задача трудновыполнимая, поскольку документы требований пишутся на естественном языке с присущей ему неоднозначностью. Рассмотрим пример:

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

Пример взят из "SoftwareRequirements", см. ссылку в пункте "Дальнейшее чтение".

Разработчики системы по-разному могут истолковать это требование, некоторые интерпретации могут не устраивать пользователей. Эксперт по требованиям, процитировавший этот фрагмент, предложил в качестве замены некоторые варианты (сделав некоторые предположения о намерениях, которые можно было бы проверить у пользователей).

1. Фоновый менеджер задач (ФМЗ) должен отображать сообщения о статусе в спроектированной области интерфейса пользователя.
2. Сообщения должны обновляться каждые 60 (плюс или минус 10) секунд после начала обработки фоновой задачи и должны постоянно оставаться видимыми.
3. Если обработка фоновой задачи выполняется нормально, то ФМЗ должен отображать процент выполненной части фоновой задачи.
4. ФМЗ должен отображать сообщение "Выполнено" по завершении фоновой задачи.
5. ФМЗ должен отображать сообщение об ошибке, если фоновая задача снята с выполнения.

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

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

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

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

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

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

Примером механизма прослеживания в EiffelStudio является средство, названное EIS (Eiffel Information System), поддерживающее определение связей между индивидуальными элементами документа требований и классами и компонентами программной системы. В принципе, каждый программный элемент должен быть прямым или косвенным следствием того или иного требования, а каждое требование должно иметь двойника в программной системе. Механизм EIS позволяет добавлять связи в документ PDF или MicrosoftWord, так что щелчок по связи приводит к открытию EiffelStudio на соответствующем участке кода — спроектированном классе или компоненте. Возможно и обратное действие: добавить связь в код, переход по которой приведет к соответствующему требованию. Механизм EIS является прямой реализацией принципа прослеживания, предназначенной, в частности, для облегчения процесса внесения изменений в требования.

Требования должны быть верифицируемыми*. Бесполезно задавать требование, если нет способа проверки его выполнения в программной системе. Экстремальным — но, к несчастью, распространённым — примером неверифицируемого требования является требование в форме "система должна работать в реальном времени, выполняя команды и запросы". Но что такое "реальное время", может оставаться загадкой. Для банковской системы ответ на запрос в течение 2-х секунд — это реальное время, для сетевых устройств реальным временем может быть 100 микросекунд. Документ должен указывать точные значения, задавая среднее значение и допустимые отклонения.

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

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

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

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

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

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

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

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

В&П - Верификация и проверка правильности

Первое правило В&П говорит, что было бы прекрасно, если бы этого не нужно было делать. Цель всех правил проектирования и методологии программирования, изучаемых в этой книге (а я верю, что вы будете применять каждое из них при каждом подходящем случае), состоит в том, чтобы создавать программный продукт, который будет работать с первого раза и каждый раз. Но все же нужно убедить в этом остальной мир, не исключая возможности, что ошибки могут встретиться и в вашей работе. Кроме того, иногда ведь приходится модифицировать продукт, написанный другим, менее просвещенным программистом. На практике В&П является главной частью усилий при разработке проекта, часто занимающей больше времени, чем само конструирование ПО.

Ограничим себя обзором некоторых базисных идей. Обсуждение главным образом коснется программ, хотя, как отмечалось, В&П применима и к непрограммным артефактам, таким как документация. Термин "страхование качества ПО" будет использоваться как синоним В&П.

Это некоторое насилие над языком, так как страхование качества включает методы построения качественного ПО и методы оценивания качества построенного ПО.

Разнообразие страхования качества

Многие люди под В&П понимают только тестирование и отладку. Фактически, область применения методов В&П значительно шире. Тестирование — главный вид динамических методов — заключается в выполнении системы (поэтому и динамический метод) на выбранных входах. Цель тестирования — обнаружение дефектов.

Статические методы анализируют текст программы без ее выполнения. Они включают осмотр кода, его статический анализ, доказательство корректности, проверку на соответствие модели.

Наше рассмотрение начнем с тестирования, а затем перейдём к статическим приемам. Следующие термины, полезные при обсуждении, идут от еще одного IEEE-стандарта по терминологии инженерии программ.

IEEEStd 610.12-1990, tinyurl.com/3w57pk (текст 1990 года, но во многом все еще полезен).

Выполнение программы, не функционирующее, как ожидалось (дает неверные результаты или приводит к аварийному завершению), называется отказом (failure).

Отказ (за исключением редких случаев отказа аппаратуры) — следствие дефекта (fault) ПО, свидетельствующее, что ПО работает не так, как должно. Заметьте, что дефект не обязательно является ошибкой реализации, он может возникать из-за ошибок на любом уровне, таких как спецификация или проектирование.

Дефект является следствием ошибки (mistake), сделанной разработчиком ПО. Термин "баг", или "жучок", не является частью официальной терминологии, хотя часто

используется для обозначения дефектов или ошибок чаще всего при отладке — задаче исправления ошибок, удаления дефектов и устранения отказов.