Менеджмент создания информационной системы

Размещено на http://www.allbest.ru

Лекция 7

Менеджмент создания информационной системы



Вступ

Менеджмент создания информационной системы зависит от подходов применяемых при проектировании. В настоящее время всё большее распространение получает объектно-ориентированный подход к анализу и проектированию экономических информационных систем. Данный подход к проектированию реализуется в рамках унифицированного процесса. Название унифицированный процесс (Unified Process) подходит к общему определению процесса: набор действий, который выполняет команда для преобразования набора требований клиента в экономическую информационную систему. Однако унифицированный процесс -- это еще и настраиваемая структура проекта, которую пользователи могут изменить, добавляя или устраняя виды деятельности, основываясь на индивидуальных потребностях и доступных ресурсах проекта.

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

Унифицированный процесс широко использует унифицированный язык моделирования (Unified Modeling Language-- UML). Основой UML является модель, способная в контексте процесса разработки информационной системы упростить реальность, что помогает команде проекта понять наиболее сложные аспекты создание информационной системы.

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



1. Процесс, управляемый прецедентами

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

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

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

* Прецеденты пишутся на родном языке пользователей. Если прецедент описан хорошо, то читатель понимает его на интуитивном уровне.

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

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

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



2. Процесс, основанный на архитектуре

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

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

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

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

Хорошая архитектура явно определяет отдельные части системы и связующие звенья между ними. В ней также эффективно используются одна или несколько архитектурных схем, чтобы обрисовать действия по разработке на разных уровнях. (Среди хорошо известных архитектурных схем можно назвать тип клиент/сервер, трехуровневый и N-уровневый типы. В других схемах делается акцент на брокерах объектных запросов (ORBs); они находятся в центре системы и используют распределенные компоненты и виртуальные машины наподобие тех, на которых работает Java.) Эффективно используя это свойство архитектуры, команда проекта может положительно влиять на общий ход работы.

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

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

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

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

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

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

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

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

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

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

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

* Технические риски связаны с различными технологиями, применяемыми в ходе процесса и с совершенствованием таких свойств, как производительность, а также читаемость, расширяемость и т.д. Например, если в системе в контексте Common Object Request Broker Architecture (CORBA -- обобщенная архитектура брокера объектных запросов) использовать технологию Enterprise Java Beans (EJB), команде проекта придется решить ряд потенциальных технических проблем, для того чтобы система могла приемлемо работать. Процесс не ориентирован специально на устранение технических рисков, но команда работает над их устранением на ранних этапах, еще до начала кодирования.

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

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

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

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

На рис. 4.1 показаны фаза и вехи унифицированного процесса. Как видите, каждая фаза содержит одну или более итераций.

Рис. 1.1 Фазы и вехи

унифицированный экономический база данные



2.1 Исследование - анализ и определение требований

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

Задачи, которые ставит перед командой разработчиков эта фаза, включают следующее:

* определение области действия системы (т.е. какие данные можно ввести и что из этого получится);

* определение потенциальной архитектуры, которая состоит из начальных версий шести разных моделей;

* выделение критических рисков и определение, когда и как можно их устранить;

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

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

* основные организаторы проекта достигли единого мнения относительно области действия предложенной системы;

* потенциальная архитектура явно устраняет ряд критических требований высокого уровня;

* бизнес-план проекта достаточно обоснован, чтобы оправдать дальнейшую продолжительную разработку.

2.2 Уточнение планов - проектирование системы

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

В ходе фазы уточнения планов команда разработчиков выполняет следующие задачи:

* охват необходимого большинства функциональных требований;

* расширение потенциальной архитектуры до уровня полной базовой линии архитектуры, которая представляет собой внутреннюю версию системы, основанную на описании архитектуры;

* устранение значительных рисков по мере их возникновения;

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

Базовая линия архитектуры состоит из расширенных версий шести моделей, созданных в ходе фазы исследований.

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

* эта модель прецедентов охватывает большинство функциональных требований новой системы;

* базовая линия архитектуры представляет собой небольшую и компактную систему, которая может служить надежной основой для непрерывной разработки;

* составлен успешный бизнес-план, и команда разработчиков имеет в наличии план проекта, который описывает развитие фазы построения.

2.3 Построение

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

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

Фаза построения завершается вехой первоначальной работоспособности. Проект считается достигшим этой вехи, если у клиентов на руках оказывается более-менее работоспособная система.

2.4 Развертывание - внедрение

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

В ходе фазы развертывания команда разработчиков сосредоточена на исправлении недостатков и на внесении поправок в систему с тем, чтобы откорректировать ранее не замеченные изъяны.



3. Пять технологических процессов

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

3.1 Управление требованиями

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

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

Охватить все требования обычно мешает ряд обстоятельств.

* Несмотря на все практические преимущества, клиенты и разработчики разговаривают на разных языках.

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

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

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

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

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

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

В унифицированном процессе термин бизнес-модель относится к двум моделям: модели бизнес-прецедентов и модели бизнес-объектов.

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

Бизнес-модель описывает производственные процессы в терминах клиентов, а также в виде концептуальных и конкретных производственных объектов. Эта модель может помочь команде разработчиков понять внутренний принцип действия той сферы бизнеса, для которой разрабатывается система.

Модель бизнес-объектов описывает, как бизнес-прецеденты "реализуются" командой исполнителей с помощью бизнес-категорий (которые могут быть как абстрактными понятиями, например счета, так и конкретными предметами, например бланки). Эта модель также описывает организационные блоки, которые представляют собой ряд бизнес-категорий. Бизнес-категории и организационные блоки часто представляют те же виды понятий и предметов, что и классы в модели предметной области; таким образом, модель бизнес-объектов обычно отображается на диаграммах классов уровня предметной области.

Глоссарий содержит различные ключевые термины, характерные для системы, которые используются в других артефактах проекта. Эти термины могут описывать как конкретные объекты, так и абстрактные понятия. Цель состоит в том, чтобы организаторы проекта использовали глоссарий, когда потребуется прийти к общему согласию относительно того, что именно имеется в виду. Глоссарий обычно составляется на основании модели предметной области, бизнес-модели или их обеих.

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

Актор может означать следующее:

* роль, которую может играть пользователь по отношению к системе;

* некий объект (например, другую систему или базу данных), который находится вне системы.

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

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

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

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

Пакет UML представляет собой группирование элементов модели. Пакет может сам состоять из пакетов. Модель прецедентов -- это, по существу, пакет пакетов прецедентов, каждый из которых состоит из акторов и прецедентов.

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

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

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

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

Диаграмма классов в UML -- наиболее действенный способ в полной мере представить содержание модели предметной области.

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

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

Системный аналитик акцентирует внимание на процессах извлечения требований и моделировании, а также связанных с ними прецедентах. Это включает следующее:

* управление разработкой модели предметной области и бизнес-модели;

* поиск акторов и прецедентов;

* гарантия полноты и непротиворечивости модели прецедентов в целом.

Системный аналитик также несет основную ответственность за составление глоссария.

Спецификатор прецедентов составляет подробные описания основного и особых потоков событий для одного или более прецедентов.

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

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

Модель прецедентов служит также базой для остальной работы по разработке системы. На рис. 4.2 показано, какое влияние имеет модель прецедентов на другие пять моделей.

Рис. 4.2 Шесть основных моделей унифицированного процесса

3.2 Анализ

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

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

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

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

* Анализ позволит команде разработчиков обратиться к решению таких задач, как распределение объектов, взаимосовместимость и производительность; как правило, на начальном этапе моделирования прецедентов этим не занимаются.

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

3.3 Построение

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

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

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

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

Модель проектирования и модель развертывания, взятые вместе, представляют собой усовершенствованную и расширенную модель анализа. Суть этого усовершенствования и расширения выражается в следующем.

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

* Модель проектирования обычно содержит намного больше деталей, чем модель анализа; в наибольшей степени это касается особенностей совместной работы объектов, направленной на обеспечение поведения, определенного моделью прецедентов.

* В то время как модель анализа отражает начальные идеи команды в отношении распределения объектов по ярусам или уровням, модель развертывания предоставляет окончательные решения, принятые командой по этим вопросам.

3.4 Реализация

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

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

3.5 Тестирование

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

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

3.6 Итерации и инкременты

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

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

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

На рис. 4.3 отображена суть итеративного и инкрементного подхода к разработке программного обеспечения.



Рис. 4.3 Итеративная и инкрементная разработка

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

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

2. Составление плана итерации с подходящим уровнем детализации.

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

4. Разработка постпрограммы для инкремента, который стал результатом итерации.

5. Составление обновленного списка рисков, не учитывая при этом риски, который были устранены в этом инкременте.

6. Оценка общего плана проекта в соответствии с относительным успехом или неудачей при выполнении итерации.

7. Переход к следующей итерации.

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

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

3.7 Артефакты

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

3.8 Исполнители

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

Исполнители создают артефакты как индивидуально, так и в составе подкоманд или команд. Единственное, что нужно запомнить: один человек в ходе процесса может выполнить больше действий, чем исполнитель. Например, аналитик может найти прецеденты и написать к ним текст.

3.9 Виды деятельности

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

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

Размещено на Allbest.ru

...