Пропуск типов пользователей
Корпоративные АИС создаются для того, чтобы быть использованными различными группами пользователей. Может сложиться ситуация, в которой в группу представителей Заказчика, участвующих в формировании требований, попадут наиболее инициативные персоны предприятия, которые, по всей видимости, смогут донести свой голос до представителей Разработчика. Те же категории пользователей, у которых не найдется активных представителей, могут оказаться "за бортом" автоматизации. Именно эта ошибка формирования требований называется "пропуск классов пользователей". Чтобы ее избежать, представитель Разработчика должен объективно оценить организационную структуру предприятия и его бизнес-процессы и вдумчиво подойти к выбору ключевых персон, проведение интервью с которыми поможет сформировать целостную картину требований к создаваемой АИС.
Методы и средства проверки требований
Наработано значительное количество методов и средств проверки требований [12.1-12.5]. Они разнятся по ряду параметров. Так, различают:
- по широте анализа - просмотр (выборочная проверка) и сквозной контроль (тотальная проверка);
- по степени формализации - неофициальные процедуры, процедуры, проводимые по формальным правилам (инспекции, экспертизы);
- по составу группы проверки - с (без) участием автора, с (без) участием менеджера проекта, с (без) участием представителей внешних организаций;
- по используемым средствам - тексты требований, тестовые сценарии, критерии приемлемости, прототипы.
Понятие и методы прототипирования были рассмотрены в лекции 10. Некоторые другие, наиболее важные из перечисленного выше, методы и средства, рассмотрены далее по тексту.
Неофициальные просмотры требований
Различают [12.1] несколько способов неофициальных просмотров требований:
- просмотр "за столом",
- коллективная проверка,
- критический анализ.
В первых двух случаях автор требований обращается за помощью к коллегам (соответственно, к одному, либо к нескольким) с целью выдачи практических рекомендаций по улучшению продукта. В третьем случае автор осуществляет презентацию разработанные им требования на совещании с последующим обсуждением.
Неофициальные просмотры используют для знакомства с разработкой, сбора отзывов, формирования обратной связи. По статистике, приведенной в [12.4], неофициальные просмотры позволяют выявить до 60% ошибок в требованиях.
Инспекции
Понятие инспекции, применительно к IT-индустрии, впервые было сформулировано Майклом Фэганом (Michael Pagan) из IBM в середине 70-х гг.1).
Согласно стандарту IEEE2), проведение инспекций, в отличие от неформальных просмотров, базируется на своде формальных требований и правил. Представленный ниже обзор правил приведен, основываясь на работе [12.5]. Кроме того, слушателям следует порекомендовать ознакомиться с параграфом "Проведение экспертизы" главы 15 монографии [12.1], где представлено детальное описание процедуры экспертизы.
Лица, занимающие управленческие позиции (менеджеры) в отношении к любым членам команды инспектирования, не должны участвовать в инспекциях.
Инспекция должна вестись под руководством непредвзятого (независимого от проекта и его целей) лидера, обученного техникам инспектирования.
Инспектирование всегда вовлекает авторов промежуточного или конечного продукта.
В группу инспекции входят лидер, регистратор, рецензент и несколько (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества, прим. автора). Каждый член команды должен исследовать оцениваемый продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники к небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией и проверяет, что все подготовились к инспектированию. Общим инструментом, используемым при инспектировании, является проверочный лист (checklist), содержащий аномалии и вопросы, связанные с аспектами, вызывающими интерес. Результирующий лист часто классифицирует аномалии и оценивается командой с точки зрения его завершенности и точности. Решение о завершении инспекции принимается в соответствии с одним (любым) из трех критериев:
- Принятие с отсутствием либо малой необходимостью переработки
- Принятие с проверкой переработанных фрагментов
- Необходимость повторной инспекции.
Разработка тестов
Механизм вариантов использования (uses cases), рассмотренный в лекции 8, позволяет ответить на вопрос: как будет использоваться система. Чтобы проверить систему, используется аналогичный механизм: тестовых сценариев (test cases).
Тестовые сценарии (ТС) рекомендуется создавать уже на ранних стадиях работы с требованиями, в идеале - после получения запросов совладельцев, параллельно с разработкой вариантов использования.
Тестовые сценарии, как и варианты использования, могут поддерживать разные уровни абстракции. Различаются концептуальные и детальные ТС. Концептуальный уровень предполагает проработку процедуры тестирования, инвариантную к конкретной реализации UI.
Как использовать тестовые сценарии для тестирования требований? В [12.1] предлагается следующая процедура.
- Построить матрицу, где по вертикали отмечены функциональные требования, а по горизонтали - тестовые сценарии.
- Убедиться, что каждый из ТС осуществим на существующем наборе требований.
- Убедиться, что для каждого требования представлен как минимум один ТС.
- Прочертить "путь" каждого из ТС на карте диалогов. Это позволит: обнаружить некорректные или пропущенные требования, исправить ошибки на карте диалогов и отшлифовать варианты тестирования.
Как быть с тестированием нефункциональных требований? Согласно [12.6], процедура анализа требований считается выполненной только тогда, когда все требования, включенные в спецификацию, обладают методами оценки соответствия им создаваемого программного продукта.
Для того, чтобы нефункциональные требования были измеримы, каждому из них в идеале необходимо сопоставить количественную метрику. Если это не удается - возможно, требование следует переформулировать, либо детализировать.
Дата добавления: 2020-11-18; просмотров: 390;