Определение критериев приемлемости
При формальной приемке продукта существуют две типовые процедуры: демонстрация продукта Разработчиком на тестовых сценариях и проверка продукта Заказчиком. Далеко не каждого Заказчика можно убедить, что он не должен "тыкать кнопки", лежащие за пределами тестовых сценариев. Однако, в период стабилизации продукта, для Заказчика важнее даже не количество выявленных дефектов, а возможность проверки - годится ли разработанная АИС для решения поставленных им задач.
Чтобы не откладывать столь важный вопрос до момента приемки системы, крайне важно, наряду с формированием требований, вовлечь Заказчика на ранних стадиях создания продукта в процесс формирования критериев приемлемости. Критерии приемлемости (acceptance criteria) должны отразить точку зрения Заказчика на то, что он считает правильной системой.
Делегирование разработки тестов на приемлемость пользователям - эффективная стратегия разработки требований [12.1]. Это позволяет уже на этапе сбора информации перейти от формулировки вопроса с "Что вам нужно делать с помощью системы?" к "Как вы делаете вывод о том, что система удовлетворяет вашим потребностям?". Если клиент не может описать, как он оценит, что конкретное требование удовлетворено системой, значит, требование сформулировано недостаточно ясно.
Раннее формирование тестов для проверки приемлемости позволяет обнаружить дефекты в требованиях.
|
|
|
Проверка приемлемости базируется на ключевых (существенных) вариантах использования. При этом следует абстрагироваться от альтернативных сценариев и исключений и сосредоточить внимание на основном потоке событий. Необходимо учесть также и нефункциональные требования, такие, как производительность, легкость и простота использования.
Введение в управление требованиями
Пройдя этапы выявления, всестороннего анализа, формализации, спецификации, проверки, требования к АИС приобретают статус документа. Стороны ставят на документе свои подписи, тем самым, удостоверяя, что именно этот (представленный в SRS) набор требований представляет свод законов, по которому создается система. Затем осуществляется проектирование и реализация системы. Готовая АИС передается Заказчику, который, совместно с Разработчиком осуществляет ее приемку и ввод в эксплуатацию. Такая схема была заложена в подходе, который известен в литературе, как "каскадный" или "водопадный" 1 (см. рис. 13.1). В этой схеме нет места управлению требованиями, т.к. они статичны, сформулированы в начале проекта и неизменны во времени.
Рис. 13.1.
Каскадный подход представлял собой одну из первых систематизаций потоков работ программной инженерии и на момент своего появления представлял безусловную ценность. Однако практика выполнения проектов автоматизации в рамках данного подхода показала низкий (порядка 20%) процент успешных проектов. Первая причина - лавинообразное разрастание цены исправления ошибок, возникших на ранних этапах создания системы от этапа к этапу (схема не имела обратных связей и, соответственно, ошибки копились вплоть до этапа внедрения). Вторая - статичность схемы. Крупный проект автоматизации может длиться 2, 3 года, а требования, замороженные в SRS, перестают соответствовать бизнес-реалиям предприятия внедрения, которое за столь долгий период может существенно измениться.
|
|
|
Подавляющее большинство современных методологий управления проектами разработки программного обеспечения 2 при всем своем разнообразии сходятся в одном: требования могут меняться! Причем практически на любой фазе производства АИС. Эта новая парадигма работы с требованиями, безусловно, импонирует Заказчикам. Теперь они имеют право ошибиться и исправить свою ошибку. Они могут дать волю своему креативу и постоянно изобретать новые возможности и формы реализации продукта. Но каково Разработчику? Если "двусмысленность - страшилка любой спецификации требований 3 ", то неконтролируемое изменение и разрастание требований - ходячий кошмар Разработчика. Вопрос контроля процесса изменений требований и его влияния на другие рабочие потоки программной индустрии настолько серьезен, что породил отдельную инженерную дисциплину - управление требованиями. Подробно ознакомиться со всеми этапами, артефактами, приемами и методами данной дисциплины можно, изучив третью главу монографии [13.1], краткое изложение которой легло в основу этой лекции.
|
|
|
Согласно RUP 4, управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе. Данное соглашение, как и тексты исходных требований, подлежит документальному оформлению.
Согласно [13.1], к действиям по управлению требованиями относятся:
· определение основной версии требований (моментальный срез требований для конкретной версии продукта);
· просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
· включение одобренных изменений требований в проект установленным способом;
· согласование плана проекта с требованиями;
· обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;
· отслеживание отдельных требований до проектирования, исходного кода и вариантов тестирования;
· отслеживание статуса требований и действий по изменению на протяжении всего проекта.
Дата добавления: 2021-03-18; просмотров: 207; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!