Некоторые организации приобретают и адаптируют приобретенные пакетные решения (также называемые коммерческими готовыми продуктами или COTS) для удовлетворения своих потребностей в программном обеспечении вместо создания новых систем с нуля. Программное обеспечение как услуга (SaaS) или облачные решения становятся все более доступными для удовлетворения потребностей в программном обеспечении. Независимо от того, покупаете ли вы пакет как часть или все решение для нового проекта или реализуете решение в облаке, вам все равно нужны требования. Требования позволяют оценить варианты решений, чтобы выбрать наиболее подходящий пакет, а затем адаптировать пакет в соответствии с вашими потребностями.
Некоторые продукты COTS могут быть развернуты сразу после установки без дополнительной работы, чтобы сделать их пригодными для использования. Однако большинство из них требуют некоторой настройки. Это может принимать форму настройки продукта по умолчанию, создания интеграции с другими системами или разработки расширений для предоставления дополнительных функций, не включенных в пакет COTS. Все эти действия требуют требований.
Если вы ищете коммерческий пакет для предоставления готового решения для некоторой части ваших корпоративных потребностей в обработке информации, сначала задокументируйте свои требования. Вам не нужно указывать все мельчайшие детали функциональности, но рассмотрите области вариантов использования или пользовательских историй, бизнес-правил, потребностей в данных и требований к атрибутам качества. Затем проведите начальное исследование рынка, чтобы определить, какие пакеты являются жизнеспособными кандидатами, заслуживающими дальнейшего рассмотрения. Затем вы можете использовать требования, которые вы определили, в качестве критериев оценки в информированном процессе выбора программного обеспечения COTS.
Один подход к оценке включает следующую последовательность действий:
- Оцените свои требования по шкале от 1 до 10, чтобы определить их важность.
- Оцените каждый пакет-кандидат, насколько хорошо он удовлетворяет каждому требованию. Используйте рейтинг 1 для полного удовлетворения, 0,5 для частичного удовлетворения и 0 для отсутствия покрытия. Вы можете найти информацию для проведения этой оценки в литературе по продукту, ответе поставщика на запрос предложения (RFP) или при непосредственном изучении продукта. Имейте в виду, что RFP — это приглашение принять участие в торгах по проекту и может не содержать информации, отражающей то, как вы собираетесь использовать продукт. Прямая проверка необходима для высокоприоритетных требований.
- Подсчитайте балл для каждого кандидата на основе веса, который вы присвоили каждому фактору, чтобы увидеть, какие продукты лучше всего соответствуют вашим потребностям.
- Оцените стоимость продукта, опыт и жизнеспособность поставщика, поддержку продукта поставщиком, внешние интерфейсы, которые обеспечат расширение и интеграцию, а также соответствие любым технологическим требованиям или ограничениям для вашей среды. Стоимость будет фактором отбора, но сначала оценивайте кандидатов без учета их стоимости.
Вы можете рассмотреть, какие требования не удовлетворяются ни одним из пакетов-кандидатов и потребуют от вас разработки расширений. Это может привести к значительным затратам на внедрение COTS и должно учитываться в процессе оценки.
Недавно моя организация хотела выбрать инструмент управления требованиями, который, помимо других возможностей, позволял пользователям работать в автономном режиме и синхронизироваться с основной версией требований, когда пользователи снова подключались к сети. Мы подозревали, что никакие инструменты на рынке не предлагают хорошего решения для этого. Мы включили эту возможность в нашу оценку, чтобы убедиться, что мы обнаружили все решения, которые ее предлагали. Если бы мы его не нашли, мы бы знали, что это возможность, которую нам нужно реализовать как расширение для выбранного пакета. В качестве альтернативы нам нужно изменить наш процесс редактирования требований.
Другой подход к оценке заключается в том, чтобы определить, позволит ли пакет пользователям выполнять свои задачи и насколько хорошо, путем проведения тестов из высокоприоритетных вариантов использования. Включите тесты, которые исследуют, как система обрабатывает существенные исключительные ситуации, которые могут возникнуть. Пройдите эти тесты, чтобы увидеть, как пакеты-кандидаты справляются с ними. Аналогичный подход заключается в запуске продукта COTS через набор сценариев, представляющих ожидаемые шаблоны использования, который называется рабочим профилем. Убедитесь, что у вас есть хотя бы один человек, чье участие распространяется на все оценки, которые вы проводите. В противном случае нет гарантии, что использовались сопоставимые интерпретации характеристик и показателей.
Результатом процесса оценки обычно является оценочная матрица с требованиями выбора в строках и баллами различных решений для каждого из этих требований в столбцах. На рис. 1 показана часть образца матрицы оценки инструмента управления требованиями.
Рис. 1. Пример матрицы оценки комплексного решения для инструмента управления требованиями.
Когда у вас есть много потенциальных пакетов на выбор, запланируйте проведение многоэтапного процесса оценки. Когда я писал требования для выбора инструмента управления требованиями для использования нашими консультантами, я работал с командами, чтобы определить классы пользователей и варианты использования инструмента. Хотя основными пользователями были бизнес-аналитики, было также несколько вариантов использования для менеджеров, разработчиков и клиентов. Я определил варианты использования по имени и использовал свое знакомство с вариантами использования, чтобы определить желаемые функции. Я создал матрицу прослеживаемости, чтобы свести к минимуму вероятность того, что какие-либо варианты использования или функции будут упущены.
Мы начали с 200 функций и 60 вариантов выбора поставщиков, что было слишком много для нашего графика оценки. Мы провели предварительную оценку, чтобы исключить большинство инструментов-кандидатов. В нашем первом проходе учитывались только 30 функций, которые мы считали наиболее важными или наиболее подходящими для того, чтобы отличать инструменты друг от друга. Эта первоначальная оценка сузила наш поиск до 16 вариантов инструментов. Затем мы сравнили эти 16 с полным набором из 200 функций. Результатом этой детальной оценки второго уровня стал список из пяти близко ранжированных инструментов, каждый из которых явно соответствовал нашим потребностям.
В дополнение к объективному анализу рекомендуется оценить пакеты-кандидаты, используя реальный проект, а не только учебный проект, поставляемый с продуктом. В итоге мы добавили третий уровень оценки, чтобы фактически опробовать каждый из этих пяти инструментов на реальных проектах, чтобы увидеть, какой из них наиболее точно отражает результаты оценки на практике. Третий этап оценки позволил нам выбрать наш любимый инструмент из числа набравших высокие баллы.
Слишком часто выбираемые нами коммерческие программные пакеты разочаровывают, потому что они не отвечают потребностям нашего бизнеса так, как пользователи считают это приемлемым. Это может привести к дорогостоящей индивидуальной разработке, необходимой для того, чтобы решение работало на вас. Чтобы избежать таких неприятных сюрпризов, проведите тщательную оценку, прежде чем выписать продавцу большой чек.
Авторы: Карл Вигерс и Джой Битти
Карл Вигерс — главный консультант компании Process Impact, www.processimpact.com. Джой Битти — вице-президент Seilevel, www.seilevel.com. Карл и Джой — соавторы отмеченной наградами книги. Требования к программному обеспечению, 3-е издание, из которого эта статья адаптирована. Последняя книга Карла Консультации по успешному бизнес-анализу: стратегии и советы, как действовать в одиночку.
