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

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

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

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

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

      Выполнимость  требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами. Так, если стоимость  контракта на разработку информационной системы составляет $10000, а затраты на выполнение нового требования, возникшее в момент, когда проект выполнен наполовину, оценивается в $4000, является ли оно невыполнимым? Скорее всего, да, если Исполнитель докажет Заказчику новизну требования (требование не входило в согласованные спецификации) и сложность его исполнения. Но, если требование является критически важным, необходимым, но выпало из поля зрения при подписании контракта Заказчик готов выделить дополнительно финансирование, а Исполнитель - трудовые ресурсы - значит, требование выполнимо. Таким образом, требование осуществимости в ряде случаев также следует считать субъективным, а критерии его оценки лежат в области договоренностей между Заказчиком и Исполнителем.

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

 
Рис. 1. Треугольник компромиссов

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

      Необходимо  обеспечить возможность переработки  требований, если понадобится, и поддерживать историю изменений для каждого положения. Для этого все они должны быть уникально помечены и обозначены, чтобы вы могли ссылаться на них однозначно. Каждое требование должно быть записано в спецификации только единожды. Иначе вы легко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные утверждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования.

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

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

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

      Упорядоченность по важности и стабильности. Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.

Стабильность требования характеризует прогнозную оценку неизменности требований во времени.

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

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

Глава 2. Анализ требований заказчика в процессе проектирования ИС

      Анализ  требований - один из основных рабочих потоков (workflow) программной инженерии, наряду, допустим, с такими, как проектирование интерфейса пользователя, либо программирование.

      Для его обозначения в англоязычной литературе, как правило, используется понятие "Requirement Process". В отечественной практике, наряду с обобщающим термином "анализ требований", принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как "поток работ", "требования", "работа с требованиями", "определение требований" и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK, и введем терминологию, которой будем придерживаться на протяжении лекционного курса.

      SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:

• Requirements Elicitation (Извлечение требований),
• Requirements Analysis (Анализ требований в узком смысле),
• Requirements Specification (Специфицирование требований),
• Requirements Validation (Проверка требований).

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

• Analyze the Problem (Анализ проблемы),
• Understand Stakeholder Needs (Понимание потребностей совладельцев),
• Define the System (Определение системы),
• Manage the Scope of the System (Управление контекстом системы),
• Refine the System Definition (Уточнение определения системы).

      Обобщая указанные выше декомпозиции, будем  придерживаться следующей, более удобной  в методическом плане схемой декомпозиции потока работ "Работа с требованиями":

• Формирование видения;
• Выявление требований;
• Классификация и спецификация требований;
• Расширенный анализ требований (моделирование и прототип-ие);
• Документирование требований;
• Проверка требований;
• Управление требованиями;
• Совершенствование процесса работы с требованиями.

      Первые 6 работ в дальнейшем рассматриваются, как компоненты процесса анализа  требований.

      Анализ требований (АТ), как этап разработки ИС, невозможно пропустить: этот этап закладывает фундамент всего процесса проектирования и реализации системы. Степень проработки АТ может быть различной: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий. Она зависит от следующих основных факторов: размеров проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки приемлема для небольших проектов, характеризующихся небольшим ресурсом и невысокими рисками. Хорошо проработанные требования позволяют:

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

      Анализ  требований - это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению.

Результатом рабочего потока "анализ требований" является набор артефактов. Это могут  быть текстовые документы, модели UML, либо других языков моделирования, прототипы  программного обеспечения.

      RUP предлагает следующие цели для потока работ АТ:

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

Кто создает и использует требования

• Специалист по АТ - постановка задачи, определение рамок проекта;
• Представитель заказчика - постановка задачи, определение рамок проекта, контроль работы исполнителя, приемка результатов работы;
• Архитектор системы - разработка архитектуры, проектирование подсистем;
• Программист - разработка программного кода;
• Тестировщик - составление тест-плана, тестовых сценариев;
• Менеджер проекта - планирование и контроль исполнения работ.

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

2.1. Выявление требований

      Источники требований. Основным источником требований к информационной системе, безусловно, являются соображения, высказанные представителями Заказчика. В соответствии с иерархической моделью требований данная информация структурируется как минимум на 2 уровня: