Почему нужно анализировать требования?
Из сказанного выше следует, что не все работы и операции, известные в программной инженерии, используются в той или иной методологии и, тем более, конкретном проекте. Возникает вопрос: является ли рабочий поток АТ необходимым в цепочке рабочих потоков создания информационной системы, стоит ли тратить на него время? Каков требуемый объем результатов, ожидаемых от АТ?
Со всей очевидностью можно утверждать: да, АТ, как этап разработки ИС, невозможно пропустить: этот этап закладывает фундамент всего процесса проектирования и реализации системы. Степень проработки АТ может быть различной: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий, например, RUP. Она зависит от следующих основных факторов: размеров проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки приемлема для небольших проектов, характеризующихся небольшим ресурсом и невысокими рисками. Хорошо проработанные требования позволяют:
· выработать общее понимание между Заказчиком и Разработчиком;
· определить рамки проекта;
· более точно определить финансовые и временные характеристики проекта;
· обезопасить Заказчика от риска получить продукт, в котором он не сможет работать;
· обезопасить Разработчика от риска попасть в ситуацию "неконтролируемого размытия границ", которое может привести к непредвиденным затратам ресурсов сверх начальных ожиданий.
|
|
|
Анализ требований - это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению (см., например, [1]).
Один из ключевых вопросов, позволяющих оценить результативность процесса - что является выходом (результатом) процесса. В чем результат АТ? Результатом рабочего потока "анализ требований" является набор артефактов. Это могут быть текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.
Другой важный вопрос - какие цели преследует процесс.
RUP предлагает следующие цели для потока работ АТ:
· добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;
· дать разработчикам наилучшее понимание требований к системе;
· определить границы системы;
· определить интерфейс пользователя и системы.
Кто создает и использует требования
Как и кем используются требования?
· Специалист по АТ - постановка задачи, определение рамок проекта;
· Представитель заказчика - постановка задачи, определение рамок проекта, контроль работы исполнителя, приемка результатов работы;
|
|
|
· Архитектор системы - разработка архитектуры, проектирование подсистем;
· Программист - разработка программного кода;
· Тестировщик - составление тест-плана, тестовых сценариев;
· Менеджер проекта - планирование и контроль исполнения работ.
В рамках курса лекций для всех упомянутых выше лиц будем использовать обобщающий термин "Совладельцы (заинтересованные стороны)" (stakeholders). Совладельцами, вслед за разработчиками RUP и MSF (см., например, [4.4,4.8]), будем называть всех участников проекта создания программной системы, прямо или косвенно заинтересованных в его успехе. Авторы большинства современных методологий разработки программных систем сходятся в том, что в группе совладельцев ключевую роль играют две группы представителей Заказчика - те, кто ставит стратегические цели и выделяет финансирование и те, кто будет непосредственно использовать разработанный продукт. Причем, в отличие от каскадных методов, где Заказчик подключался в начальной фазе - составлении технического задания и конечной - приемке готовой работы, в современных методологиях Заказчик, действительно заинтересованный в успехе проекта автоматизации, должен участвовать в нем непрерывно.
|
|
|
Организация работы с требованиями на примере MSF
В MSF для обозначения роли участников команды софтверного проекта используется понятие ролевых кластеров [4.9].
MSF (Microsoft Solutions Framework – каркас решений Microsoft) – методология разработки программного обеспечения от Microsoft, http://msdn.microsoft.com/en-us/library/jj161047.aspx. В настоящее время доступна версия 4.0, которая состоит из описания теоретических основ методологии и двух прикладных реализаций. Теоретические основы содержат фундаментальные принципы, "кластерную" модель проектной группы и модель процессов (циклов и итераций). Прикладные реализации – MSF для гибкой разработки Agile, MSF для CMMI.
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением.
Шесть ролевых кластеров модели проектной группы - это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи.
|
|
|
MSF организован на базе комбинации каскадной и спиральной моделей. Отдельная стадия работы содержит в себе 5 фаз:
· Envisioning (выработка концепции),
· Planning (планирование),
· Developing (разработка),
· Stabilizing (стабилизация),
· Deploying (внедрение).
В фазе выработки концепции работа с требованиями наиболее интенсивна (см. табл. 4.1).
| Таблица 4.1. | |
| Ролевой кластер | Фокус |
| Управление продуктом | Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта. |
| Управление программой | Цели дизайна; концепция решения; структура проекта. |
| Разработка | Прототипирование; анализ технологических возможностей; анализ осуществимости. |
| Удовлетворение потребителя | Необходимые эксплуатационные характеристики решения и их влияние на его разработку. |
| Тестирование | Стратегии тестирования; критерии приемлемости, их влияние на разработку решения. |
| Управление выпуском | Требования внедрения и их влияние на разработку решения; требования сопровождения. |
Как видно из таблицы, все 6 кластеров работают со своими группами требований.
Продолжается плотная работа с требованиями и на следующей фазе - фазе планирования, см. табл. 4.2.
| Таблица 4.2. | |
| Ролевой кластер | Фокус |
| Управление продуктом | Анализ бизнес-требований |
| Управление программой | Функциональная спецификация |
| Удовлетворение потребителя | Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility). |
| Тестирование | Требования тестирования. |
| Управление выпуском | Эксплуатационные требования. |
В фазах разработки и внедрения работа с требованиями сосредотачивается в кластерах управления продуктом и программой, см., соответственно, табл. 4.3,4.4.
| Таблица 4.3. | |||
| Ролевой кластер | Фокус | ||
| Управление продуктом | Ожидания заказчика. | ||
| Управление программой | Управление функциональной спецификацией. | ||
| Таблица 4.4. | |||
| Ролевой кластер | Фокус | ||
| Управление продуктом | Получение отзывов и оценок заказчика; акт о приеме выполненной работы. | ||
| Управление программой | Сопоставление рамок проекта с поставленным решением; управление стабилизацией. | ||
Дата добавления: 2021-03-18; просмотров: 139; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!