Файл: Инфрам.pdf

175 сятся с кодом в программной системе. Интеграция требований в про- цесс управления изменениями даст уверенность, что требования не до- бавляются без тестирования и утверждения, а также, что любое измене- ние не будет добавлено в программный продукт, не пройдя стадию ана- лиза.
Тестирование должно основываться на требованиях точно так же, как дизайн разрабатывается в соответствии с ними. Данный процесс даст уверенность, что программная система обеспечивает всю необхо- димую заказчику функциональность.
Менеджеры проекта должны планировать работу по разработке сис- темы, опираясь на требования, так как они являются основой процесса разработки программного обеспечения. Менеджеры проекта должны иметь прямой доступ к требованиям, чтобы управлять проектом и сни- мать метрики с требований. Это позволит определить, насколько каче- ственны требования, как часто они меняются, в каком статусе находят- ся, какие есть риски по реализации данных требований и т.д.
Безусловно, такая плотная интеграция нужна в больших проектах и требует немалых затрат на закупку специальных средств по разработке программной системы на всех ее стадиях. И, безусловно, пальму пер- венства в инструментарии полного жизненного цикла программного обеспечения держат линейки IBM Rational и IBM Telelogic.

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

177
Возможность тестирования требований на всех стадиях разработки проекта является необходимым условием их подтверждения. Преобла- дающим подходом подтверждения является моделирование системы с учетом ее основных операционных характеристик. Путем моделирова- ния система подвергается экспериментальному тестированию с исполь- зованием строгого диапазона представления параметров, которые полу- чаются на основе различных наборов требований. Если результаты мо- делирования достаточно достоверны, то аналитик сможет сразу увидеть операционные последствия входных требований и точно выбрать луч- ший их набор для управления системой.
Возможны следующие подходы к проверке требований: количест- венное вычисление, моделирование известным способом, новое моде- лирование, разработка прототипов и двойной счет [22]. Количественные вычисления по аналитическим моделям или при использовании при- ближенных, выведенных на основе статистики математических выра- жений – самый дешевый и наименее надежный метод. Его используют в крайних случаях.
Разница между этими методами и имитационной моделью системы важна потому, что применение специально созданной для данной сис- темы модели ведет к снижению стоимостных и временных затрат. Од- нако создание модели, адекватной будущей системе, – процесс сложный и дорогой, сопоставимый по сложности и стоимости с самой системой.
Поэтому при недостатке средств и времени используются по возможно- сти уже разработанные методы и средства моделирования.
Большинство специалистов, работающих с требованиями, находят моделирование весьма удобным и полезным дополнением к текстовым требованиям. Причем в данном случае совершенно не принципиально, что именно подразумевается под термином «моделирование», – это мо- жет быть и рисунок, схема, алгоритм, нарисованные на доске или листке бумаги, и использование MS PowerPoint, и создание реальной модели
(программное приложение, мнемонический прототип и т.д.). Необходи- мо лишь соблюдать одно важное условие – эти модели и представле- ния должны существовать в тесной связи (параллели) с требованиями, чтобы гарантировать их общую совместимость, корректность, трасси- руемость и изменяемость (если последнее вдруг потребуется).
Визуальное представление требований привносит в работу над про- ектом огромные преимущества, поскольку является не только простым и в то же время мощным средством общения между всеми заинтересо- ванными лицами, но и обеспечивает дополнительные возможности по извлечению и формированию требований заказчиков и конечных поль- зователей, а также способствует более четкому и однозначному пони- манию этих требований всеми членами проектной команды. Следует заметить, что нет необходимости всегда, везде и полностью заменять ясные, четкие и однозначные текстовые требования на модели и визу- альные представления, но использование такого подхода там, где это уместно, дает организации дополнительную возможность значительно

178 повысить уровень общения с заказчиком и эффективность взаимодейст- вия в команде.
4.8. Цели программного продукта
Вторым процессом начального этапа проектирования программных систем является разработка (постановка) и описание целей для созда- ваемой программной системы. При правильной постановке целей не делается никаких предположений о конкретной реализации, но указыва- ется, каким образом на последующих этапах проектирования следует принимать компромиссные решения. Например, невероятно иметь в качестве целей конкретного проекта такую формулировку [11]: “Обес- печить максимальную надежность, эффективность, адаптируемость и безопасность системы, минимизируя стоимость и время разработки, требуемую память и время реакции терминала ”. Такого рода формули- ровки бессмысленны, поскольку многие из перечисленных факторов противоречат друг другу. Таким образом, назначение раздела проекта постановки целей программного продукта – не только сами цели, но и, если нужно, и компромиссы между этими целями.
К общим ошибкам, совершаемым в процессе разработки и описания целей, относятся следующие:
1) цели не формулируются явно;
2) противоречивость в описании сформулированных целей (конфликт целей);
3) наличие поверхностно выявленных целей, не отражающих специфи- ческих особенностей разрабатываемой программной системы;
4) цели программной системы с точки зрения пользователя (цели про- дукта) и цели проекта с точки зрения разработчика противоречивы.
Работы по созданию программной системы должны обеспечить вы- полнение двух различных множеств задач (целей): задач продукта раз- работки, определяющих его цели с точки зрения пользователя (цели продукта), и задач проекта, отображающих цели в рамках проекта (гра- фик выполнения работ, стоимость, степень тестирования, степень на- дежности и др.). В силу противоречивости целей ошибка, выражающая- ся в отсутствии необходимого уровня достижения компромисса на сис- темной основе, является достаточно распространенной. Для понимания путей нахождения компромисса между противоречивыми целями сле- дует рассмотреть отношения между различными категориями компро- миссов. Поскольку одной из важнейших задач разработки программных систем является достижение надежной работы системы, далее рассмот- рим компромиссы между надежностью и другими наиболее важными требованиями.
1. Универсальность (общность). Универсальность выступает в каче- стве меры количества, мощности и объема функций, запрашиваемых пользователем. Не следует ставить перед проектировщиком задачу дос- тижения максимальной универсальности, необходимо представить ему

179 перечень специфических функций применения продукта. Следует пом- нить, что универсальность т надежность работы ПС противоречат друг другу. Уже одно увеличение объема ПС при росте числа выполняемых функций приведет к росту числа ошибок при программировании. По- этому каждая функция должна быть взвешена в смысле ее реальной пользы для потребителя и сопоставлении с ее влиянием на надежность.
2. Человеческие (психологические) факторы. Эти факторы являются мерой легкости понимания результатов, легкости использования, защи- щенности от неправильного употребления и, как результат, частоты ошибок пользователя. Хотя интеллектуальность интерфейса пользова- теля может увеличить сложность системы и, таким образом, иметь от- рицательное влияние на надежность, психологические факторы и на- дежность обычно не вступают в конфликт. Хороший учет психологиче- ских факторов позволяет свести к минимуму возможность неожиданных действий пользователя, что уменьшает возможность проявления скры- тых ошибок в программном коде.
3. Адаптируемость. Адаптируемость ПС к различным условиям применения и классам пользователей является качественной мерой лег- кости использования и расширения за счет добавления новых функций.
Адаптируемость и надежность в общем случае могут рассматриваться как совместимые. Более того, реализация мер по повышению надежно- сти оказывает положительное влияние на адаптируемость и расширяе- мость системы в процессе ее сопровождения.
4. Удобство сопровождения. Сопровождаемость ПС характеризует меру затрат времени и средств на исправление ошибок в работающей системе. Это требование согласуется с требованиями надежности, по- скольку оно тесно связано с адаптируемостью. Кроме того, такие мето- ды обеспечения надежности, как обнаружение и изоляция ошибок спо- собствуют повышению надежности.
5. Безопасность. Безопасность определяется мерой вероятности того, что один пользователь может случайно или преднамеренно обратиться или уничтожить данные, являющиеся собственностью другого пользо- вателя, или препятствовать действию системы. Меры безопасности включают анализ ожидаемых угроз, тщательную взаимную изоляцию пользователей по данным и программам, обособление программ поль- зователей от операционной системы, разработку контрмер по противо- действию проникновения в систему. Разработка и внедрение мер безо- пасности положительно сказывается на надежности.
6. Документация. Задачи документации связаны с количеством и ка- чеством публикаций в интересах пользователей. Документация и чело- веческие факторы сходны в том, что они связаны с облегчением пони- мания и использования программной системы. В связи с этим решение проблем документирования не противоречит достижению заданного уровня надежности.
7. Стоимость ПС (продукта). Стоимость программной системы включает затраты, связанные с созданием и сопровождением системы.
Стоимость в значительной мере связана с количеством ошибок в про-