лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки
 Скачать 4.41 Mb.
|
Почему нужно анализировать требования?Из сказанного выше следует, что не все работы и операции, известные в программной инженерии, используются в той или иной методологии и, тем более, конкретном проекте. Возникает вопрос: является ли рабочий поток АТ необходимым в цепочке рабочих потоков создания информационной системы, стоит ли тратить на него время? Каков требуемый объем результатов, ожидаемых от АТ? Со всей очевидностью можно утверждать: да, АТ, как этап разработки ИС, невозможно пропустить: этот этап закладывает фундамент всего процесса проектирования и реализации системы. Степень проработки АТ может быть различной: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий, например, 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).
Как видно из таблицы, все 6 кластеров работают со своими группами требований. Продолжается плотная работа с требованиями и на следующей фазе - фазе планирования, см. табл. 4.2.
В фазах разработки и внедрения работа с требованиями сосредотачивается в кластерах управления продуктом и программой, см., соответственно, табл. 4.3,4.4.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||