• формирование требований к поставщику;
• организация презентаций поставщиков;
• выбор поставщиков;
• определение форм сотрудничества и заключение контрактов с поставщиками;
• создание КИУС;
• разработка и утверждение плана-графика создания КИУС;
• формирование и обучение рабочей группы;
• разработка системного проекта;
• настройка и тестирование тиражируемых компонентов;
• разработка уникальных компонентов;
• интеграция компонентов в опытную версию КИУС;
• опытная эксплуатация КИУС;
• разработка методик работы с КИУС;
• обучение и сертификация пользователей и администраторов;
• переход к промышленной эксплуатации КИУС.
Формирование, документирование и анализ требований позволяет реализовать следующие цели:
• достижение взаимопонимания между всеми участниками разработки относительно функций и характеристик КИУС;
• обеспечение возможности «видения» и корректировки будущей системы до того, как она будет реализована физически;
• уменьшение затрат на разработку и внедрение системы;
• обеспечение базиса для планирования, оценки стоимости и времени создания системы.
Фактически на данном этапе дается ответ на вопрос «Что будет делать перспективная система?». Именно здесь лежит ключ к успеху всего проекта по созданию КИУС, в практике известно немало примеров провала подобных проектов именно из-за неполноты или нечеткости определения системных требований.
Задача формирования требований является наиболее трудной частью процесса создания КИУС, при их определении возникают следующие проблемы:
• сложно получить исчерпывающую информацию от заказчика для оценки требований;
• требования от различных заинтересованных лиц могут быть противоречивыми;
• требования не всегда ясны и имеют много источников происхождения;
• заказчик, как правило, не является ИТ-специалистом и может формулировать требования вне возможностей информационных технологий;
• число требований может быть огромным (и разной степени детализации) и вследствие этого неуправляемым;
• требования изменяются и т. д.
Требования к КИУС разбиваются на две самостоятельные группы – требования к функциям и нефункциональные требования. Основой выявления требований первой группы является модель бизнес-процессов предприятия, на базе которой, собственно, и формируется иерархия требований. К числу нефункциональных требований относятся:
• правовые и законодательные требования;
• качественные характеристики создаваемой системы, включая требования к ее практичности, надежности, производительности и возможностям поддержки;
