1-software_engineering_requirements (1133541), страница 8
Текст из файла (страница 8)
Уверенность в соответствии модели заданным требованиям может быть закрепленаформально со стороны пользователей/заказчика. В то же время, проверка и аттестация модели,например, объектно-ориентированного представления бизнес-сущностей и связей между нимиможет быть проверена с той или иной степенью использования формальных методов, например,статического анализа (поиск связей и путей взаимодействия между описанными объектами ивыделение различного рода несоответствий). Это – другая сторона утверждения модели.6.4 Приемочные тесты (Acceptance Tests)Требования должны быть верифицируемы. Требования, которые не могут быть проверены иаттестованы (утверждены) – это всего лишь “пожелания”.
Именно так они буду восприниматьсяразработчиками, даже в случае их высокой значимости для пользователей. Если описанноетребование не сопровождается процедурами проверки – в большинстве случаев говорят онедостаточной детализации или неполном описании требования и, соответственно, спецификациятребований должна быть отправлена на доработку и если необходимо, должны быть предпринятыдополнительные усилия, направленные на сбор требований.Можно говорить о том, что процедура анализа требований считается выполненной только тогда,когда все требования, включенные в спецификацию, обладают методами оценки соответствия имсоздаваемого программного продукта.
Чаще всего столь строгое ограничение на степеньзаконченности спецификации накладывается на функциональные требования и атрибуты качества(например, время отклика системы).Идентификация и разработка приемочных тестов для нефункциональных требований частооказывается наиболее трудоемкой задачей. Для ее решения обычно “ищут точку опоры”, то естьвозможность взгляда на описываемые требования с количественной точки зрения, в плоть допереформулирования и большей степени детализации описания таких требований.Дополнительная информация, связанная с приемочными тестами представлена в области знанийSWEBOK “Тестирование программного обеспечения” (Software Testing) в описании 2.2.4 “Тестысоответствия” (Conformance testing).7.
Практические соображения (Practical Considerations)Первый уровень декомпозиции секций данной области знаний напоминает описаниепоследовательности действий. Это, безусловно, упрощенный взгляд на процесс работы стребованиями. Данный процесс, точнее, комплекс процессов, охватывает весь жизненный циклпрограммного обеспечения.
Управление изменениями и сопровождение, поддержка актуальноститребований и их реализации – ключ к успешным процессам программной инженерии.Далеко не каждая организация обладает культурой документирования и управления требованиями.Особенно часто это встречается в молодых небольших компаниях, выводящих на рынок новыепродукты и обладающие “сильным вижином”, четким пониманием целей, для которых создаетсяпродукт, но не имеющих достаточно ресурсов и, во многом поэтому считающих, что динамизм –залог успеха.
Постепенно такие компании вырастают, проекты – усложняются и, как следствиескладывается ситуация, когда отследить все необходимые требования в неформальной форме ужепросто невозможно. Эта тема практически неисчерпаема. Многие средние по масштабам компании18Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ruОсновы программной инженерии (по SWEBOK)Программная инженерия. Программные требования.пытаются сохранить тот же вровень гибкости и динамизма, который применялся во временарождения компании, когда она еще была “стартапом” (start-up – название молодых компаний,которые раскручивали свои проекты во времена интернет-бума конца 90-х и которое прижилось длявновь образующихся малых бизнесов, растущих не столько на внешних инвестициях, сколько наидеях и упорстве ее создателей). Так или иначе, динамизм присущ не только компаниям, но ипродуктам, самим требованиям к ним. Управление изменениями, концепцией, видением продукта неможет быть хаотическим – история индустрии однозначно это показывает.
Поэтому отношение куправлению требованиями как к постоянно действующему бизнес-процессу – абсолютнообоснованный подход, требующий применения определенных практик. В противном случае, мыпрактически гарантировано столкнемся с темни негативными последствиями, которые не разописывались и упоминались выше.7.1 Итеративная природа процесса работы с требованиями (Iterative Nature of the RequirementsProcess)В большинстве случаев, понимание и интерпретация требований продолжает эволюционировать впроцессе проектирования и разработки программного обеспечения. Кроме того, требования частоменяются в силу изменений бизнес-контекста для которого создается и в котором эксплуатируетсяпрограммное обеспечение.
Необходимо понимать неизбежность изменений и планировать шаги поуменьшению проблем, связанных с изменениями. В то же самое время, современные практикигибкой разработки говорят о том, что необходимо концентрироваться только на том, что требуетвнимания “прямо сейчас”, не закладываясь на предупреждение всех возможных рисков, в том числесвязанных с изменениями, включая изменения требований. Говорить о том, какой подход –предупреждение или реагирование является гарантировано приводит к успеху – сложно сказать.Более того, если кто-то однозначно настаивает только на одной из идей и полностью отвергаетдругую – это профанация.
Восприятие изменений и возможность их своевременной обработки вопрос способности проектной команды работать в условиях постоянно меняющихся условий,принимаемых архитектурных решений и многих других культурных, технологических иорганизационных факторов. Так или иначе, понимание меняющейся природы требований – один изфакторов адекватного реагирования на сами изменения, а, следовательно, и возможностиуспешного завершения проекта.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru19Основы программной инженерии (по SWEBOK)Программная инженерия.
Программные требования.7.2 Управление изменениями (Change Management)Управление изменениями – одна из ключевых тем управления требованиями. Необходимостьопределения процедур для обработки изменений совсем не то же самое, что и их детальнаяформализация. Такие процедуры необходимы. Им посвящена тема управления изменениями вприложении к требованиям. В то же время, рассматривать изменение требований в отрыве от другихпроцессов, по меньшей мере, кажется странным. Соответственно, данный вопрос являетсясоставной частью управления изменениями и конфигурациями программного обеспечения (SoftwareConfiguration and Change Management, SCCM), которое сегодня принято называть простоконфигурационным управлением (Software Configuration Management, SCM), подразумевая, что этоне только вопросы контроля версий, но управление всеми активами проекта, включая код,требования, запросы на изменения – change requests (в том числе, отчеты об ошибках – defect илиbug reports), задачи (в терминах проектного менеджмента) и т.п.Общий комплекс вопросов конфигурационного управления рассматривается в области знанийSWEBOK “Управление конфигурациями программного обеспечения” (Software ConfigurationManagement).7.3 Атрибуты требований (Requirements Attributes)Требования должны состоять не только из описания того, что необходимо сделать, но и содержатьинформацию, необходимую для интерпретации требований и управления ими.
Например, спользовательскими требованиями часто ассоциируют сценарии Use Case (как в текстовом, так играфическом представлении) и, в то же время, функциональные требования частотрансформируются в задачи в терминах проектного управления, с которыми связаны параметрызаконченности (например, в процентах), ответственности (например, кто является “владельцем”требования, кто из инженеров назначается исполнителем или принимает на себя обязанности,связанные с реализацией заданной функциональности, как это принято, например, в XP или FDD).Примеров существует множество и, в зависимости от применяемых практик и методов, сложившейсяпроектной и организационной культуры, спектр атрибутов может меняться достаточно широко,практически, неограниченно.Необходимо также помнить, что к обсуждаемым атрибутам также относятся параметры, связанные склассификацией требований (см.
выше тему 4.1 “Классификация требований”). В свою очередь,принадлежность к тому или иному классу (категории, типу, виду) требований означает не толькосемантику того, “чему посвящены” требования (функциональности, параметрам качества и т.п.), но икомплекс атрибутов, общий для всех требований данного класса.По мнению авторов, можно провести параллель между требованиями и записями (строками) вреляционной базе данных, где каждая запись обладает набором атрибутов (столбцов).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
