Учебное пособие ТОАУ Ч.3 (1021725), страница 9

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

Текст из файла (страница 9)

требования обеспечивают качественную основу для проектирования и сборки ПО.

Некоторые типичные проблемные ситуации процесса формирования и оценки требований

Двусмысленность требований

В ряду проблем и недостатков требований двусмысленность, является, пожалуй, наиболее критичным фактором риска проекта, закладываемого в фазе формирования требований. Двусмысленность (несоответствие свойству ясности, определенности) закладывает под проект "бомбу замедленного действия". На практике требование, сформулированное двусмысленным образом, может привести к различным его интерпретациям представителями Разработчика и Заказчика. Разработчик, руководствуясь своей интерпретацией, определит на ее основе архитектурную основу, создаст аналитические и проектные модели и в конечном итоге создаст программный код. Как показывают исследования, цена исправления ошибки вырастает примерно на порядок при переходе между рабочими потоками (от анализа требований к проектированию, от проектирования к реализации и т.д.).

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

"Золочение" продукта

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

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

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

Минимальная спецификация

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

Однако, для работы "не по правилам", во-первых, должны быть объективные предпосылки, во-вторых - следует отдавать себе отчет в выгодах и рисках этого выбора.

Минимальная спецификация уместна, если имеет место наличие одновременно трех обстоятельств (объединение по "И"):

а) цена контракта и размеры проекта таковы, что разработка развернутого ТЗ экономически нецелесообразна;

б) коллектив Разработчика обладает достаточной степенью профессионализма и опыта выполнения проектов в смежных областях, чтобы уметь создавать по краткой спецификации продукт, который пройдет приемку Заказчиком;

в) между Заказчиком и Разработчиком существуют конструктивные отношения и обе стороны понимают и принимают риски мини-спецификации.

Другой вариант работы по мини-спецификации: Заказчик и Разработчик понимают, что создание развернутой спецификации оттягивает окончание выпуска готового продукта, что главная цель проекта - продукт, а не документация и готовы к плотному сотрудничеству в процессе его создания. Это - путь так называемых agile-методологий разработки ПО, подробнее см. в http://www.agile.org.

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

Пропуск типов пользователей

Корпоративные АИС создаются для того, чтобы быть использованными различными группами пользователей. Может сложиться ситуация, в которой в группу представителей Заказчика, участвующих в формировании требований, попадут наиболее инициативные персоны предприятия, которые, по всей видимости, смогут донести свой голос до представителей Разработчика. Те же категории пользователей, у которых не найдется активных представителей, могут оказаться "за бортом" автоматизации. Именно эта ошибка формирования требований называется "пропуск классов пользователей". Чтобы ее избежать, представитель Разработчика должен объективно оценить организационную структуру предприятия и его бизнес-процессы и вдумчиво подойти к выбору ключевых персон, проведение интервью с которыми поможет сформировать целостную картину требований к создаваемой АИС.

Методы и средства проверки требований

Наработано значительное количество методов и средств проверки требований [12.1-12.5]. Они разнятся по ряду параметров. Так, различают:

• по широте анализа - просмотр (выборочная проверка) и сквозной контроль (тотальная проверка);

• по степени формализации - неофициальные процедуры, процедуры, проводимые по формальным правилам (инспекции, экспертизы);

• по составу группы проверки - с (без) участием автора, с (без) участием менеджера проекта, с (без) участием представителей внешних организаций;

• по используемым средствам - тексты требований, тестовые сценарии, критерии приемлемости, прототипы.

Неофициальные просмотры требований

Различают [12.1] несколько способов неофициальных просмотров требований:

просмотр "за столом",

коллективная проверка,

критический анализ.

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

Неофициальные просмотры используют для знакомства с разработкой, сбора отзывов, формирования обратной связи. По статистике, приведенной в [12.4], неофициальные просмотры позволяют выявить до 60% ошибок в требованиях.

Инспекции

Понятие инспекции, применительно к IT-индустрии, впервые было сформулировано Майклом Фэганом (Michael Pagan) из IBM в середине 70-х гг. 1).

Согласно стандарту IEEE 2), проведение инспекций, в отличие от неформальных просмотров, базируется на своде формальных требований и правил. Представленный ниже обзор правил приведен, основываясь на работе [12.5]. Кроме того, слушателям следует порекомендовать ознакомиться с параграфом "Проведение экспертизы" главы 15 монографии [12.1], где представлено детальное описание процедуры экспертизы.

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

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

Инспектирование всегда вовлекает авторов промежуточного или конечного продукта.

В группу инспекции входят лидер, регистратор, рецензент и несколько (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества, прим. автора). Каждый член команды должен исследовать оцениваемый продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники к небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией и проверяет, что все подготовились к инспектированию. Общим инструментом, используемым при инспектировании, является проверочный лист (checklist), содержащий аномалии и вопросы, связанные с аспектами, вызывающими интерес. Результирующий лист часто классифицирует аномалии и оценивается командой с точки зрения его завершенности и точности. Решение о завершении инспекции принимается в соответствии с одним (любым) из трех критериев:

Принятие с отсутствием либо малой необходимостью переработки

Принятие с проверкой переработанных фрагментов

Необходимость повторной инспекции.

Разработка тестов

Механизм вариантов использования (uses cases), рассмотренный в лекции 8, позволяет ответить на вопрос: как будет использоваться система. Чтобы проверить систему, используется аналогичный механизм: тестовых сценариев (test cases).

Тестовые сценарии (ТС) рекомендуется создавать уже на ранних стадиях работы с требованиями, в идеале - после получения запросов совладельцев, параллельно с разработкой вариантов использования.

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

Как использовать тестовые сценарии для тестирования требований? В [12.1] предлагается следующая процедура.

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

Убедиться, что каждый из ТС осуществим на существующем наборе требований.

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

Прочертить "путь" каждого из ТС на карте диалогов. Это позволит: обнаружить некорректные или пропущенные требования, исправить ошибки на карте диалогов и отшлифовать варианты тестирования.

Как быть с тестированием нефункциональных требований? Согласно [12.6], процедура анализа требований считается выполненной только тогда, когда все требования, включенные в спецификацию, обладают методами оценки соответствия им создаваемого программного продукта.

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

Определение критериев приемлемости

При формальной приемке продукта существуют две типовые процедуры: демонстрация продукта Разработчиком на тестовых сценариях и проверка продукта Заказчиком. Далеко не каждого Заказчика можно убедить, что он не должен "тыкать кнопки", лежащие за пределами тестовых сценариев. Однако, в период стабилизации продукта, для Заказчика важнее даже не количество выявленных дефектов, а возможность проверки - годится ли разработанная АИС для решения поставленных им задач.

Чтобы не откладывать столь важный вопрос до момента приемки системы, крайне важно, наряду с формированием требований, вовлечь Заказчика на ранних стадиях создания продукта в процесс формирования критериев приемлемости. Критерии приемлемости (acceptance criteria) должны отразить точку зрения Заказчика на то, что он считает правильной системой.

Делегирование разработки тестов на приемлемость пользователям - эффективная стратегия разработки требований [12.1]. Это позволяет уже на этапе сбора информации перейти от формулировки вопроса с "Что вам нужно делать с помощью системы?" к "Как вы делаете вывод о том, что система удовлетворяет вашим потребностям?". Если клиент не может описать, как он оценит, что конкретное требование удовлетворено системой, значит, требование сформулировано недостаточно ясно.

Раннее формирование тестов для проверки приемлемости позволяет обнаружить дефекты в требованиях.

Характеристики

Список файлов книги