в облаке
Попробовать

Оценка рисков нефункциональных требований

21.01.2010 11:56

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

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

 

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

 

img1

 

Теперь у нас есть некоторое понимание того, какие технические особенности будут у этого приложения: необходимо обеспечить постоянное хранение данных пользователя, реализовать переносимое решение и обеспечить возможноть локализации приложения без привлечения программистов. Нам важно аккуратно подойти к выбору платформы, библиотек и организации внутренней архитектуры приложения, чтобы реализовать эти требования заказчика. Скорее всего нужно использовать портируемую библиотеку, наверно хорошо бы использовать C++ или .Net для реализации приложения, видимо понадобится какая-то база данных для постоянного хранения данных пользователя, или можно будет обойтись обычными файлами? Все эти вопросы необходимо решать до начала разработки и они формируют базу технических рисков, которые необходимо оценить всей команде.

 

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

 

img2

 

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

 

img3

 

Допустим, что у нашей команды есть опыт разработки на .Net и на чистом C++, но нет опыта написания переносимых приложений, которые бы запускались одновременно на Windows и Linux. Чтобы снизить риск "Обеспечение переносимости приложения" мы хотим разработать прототипы приложения на Qt и на .Net и "пощупать" их работу, условия разработки и сопровождения для каждого их этих вариантов. Для этого создаем соответствующие пожелания и назначаем их на участников комадны. Команда оценивает рабочие прототипы и приходит к выводу, что лучше реализовывать приложение на .Net, тем самым исходный риск оценен и добавлен новый риск, связанный с недостаточным знанием возможностей использования баз данных на Linux. Риск потери данных пользователем снижается за счет проектирования внутренней архитектуры приложения таким образом, чтобы любые изменения данных пользователем автоматически сохранялись во временных файлах и восстанавливались при падении приложения.

 

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

Еще интересные статьи на эту тему: