Проектирование ИС

• бизнес-требования и
• требования пользователей.

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

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

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

      Поэтому другим важным источником информации, помимо выявления требований, являются артефакты, описывающие предметную область. Это могут быть документы с описанием бизнес-процессов предприятия, выполненные консалтинговым агентством, либо просто документы (должностные инструкции, распоряжения, своды бизнес-правил), принятые на предприятии. Одной из немногих методологий, в которой специально выделяется рабочий поток делового моделирования, является Rational Unified Process.

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

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

Приведем  стратегии выявления требований:

1. Интервью - ключевая стратегия выявления требований.
2. Анкетирование - самый малозатратный и наименее эффективный для аналитика способ извлечения информации. Обычно применяется как дополнение к другим стратегиям выявления требований.
3. Наблюдение за работой моделируемой организационной системы
4. Самостоятельное описание требований. По результатам анализа документов и собственных знаний аналитик может составить описание требований и предложить его представителям Заказчика в качестве информации к размышлению, либо - основы для формирования технического задания.
5. Совместные семинары 
6. Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий.

2.2. Формирование видения

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

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

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

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

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

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

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

      Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику  и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Все вышесказанное ничуть не исключает возможность работы без концепции: либо речь идет о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к ИС, имея "концепцию в голове" и время для консультирования Разработчика.

      Видение в RUP. Шаги, которые необходимо пройти для формирования документа "Видение":

• Формулировка проблем.
• Идентификация совладельцев
• Определение границ системы
• Идентификация ограничений
• Формулировка постановки задач
• Определение возможностей системы
• Оценка результатов

      Для описания проблем предлагается шаблон, показанный в Таблице 1.

Таблица 1. Шаблон

      Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта - представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр.

      Определение границ системы представляет собой  нетривиальный процесс. Для этого  используют контекстные диаграммы. RUP в поиске границ предлагает отталкиваться от акторов и вариантов использования.

      Среди источников ограничений обычно выделяют:

• Политические,
• Экономические,
• Среды,
• Технические,
• Выполнения,
• Системные.

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

      Шаблон  документа "Vision" RUP содержит следующие  основные разделы:

1. Введение
2. Позиционирование
3. Описания совладельцев и пользователей
4. Краткий обзор изделия
5. Возможности продукта
6. Ограничения
7. Показатели качества
8. Старшинство и приоритеты
9. Другие требования к изделию
10. Требования к документации
11. Приложение.

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

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

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

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

      В разделе, посвященном возможностям продукта, они описываются более подробно, каждая - в отдельном параграфе.

      В раздел "Ограничения" следует  выносить существующие технические, технологические  и др. обстоятельства, которые необходимо учитывать на данной стадии.

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

      Раздел "Старшинство и приоритеты" ранжирует сформулированные ранее  требования и возможности системы  по степени важности, очередности реализации и т.п.

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

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

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

2.3. Классификация и  специфицирование  требований

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

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