Процесс, управляемый прецедентами
Прецедент— это последовательность действий, которые выполняются одним или более актором(некто или нечто вне системы) либо самой системой и приводят к результату, возвращаемому для одного или нескольких акторов. Одним из ключевых аспектов унифицированного процесса можно назвать использование прецедентов в качестве движущей силы разработки. Характеризуя процесс как управляемый прецедентами, мы имеем в виду, что команда проекта использует прецеденты для выполнения всей разработки — от начального сбора информации и обсуждения требований до написания кода.
Прецеденты очень удобны для уточнения требований, анализа, разработки и реализации, и тому есть ряд причин.
• Прецеденты выражаются с точки зрения пользователей системы, что более удобно для клиентов, так как они видят отражение своих требований в тексте описания прецедентов. Ведь клиенту иногда трудно увидеть воплощение собственных условий в контексте требований.
• Прецеденты пишутся на родном языке пользователей. Если прецедент описан хорошо, то читатель понимает его на интуитивном уровне.
• Прецеденты предоставляют гораздо больше возможностей для понимания действительных требований к системе, чем стандартные документы с требованиями, которые обычно написаны неясно, многословно и противоречиво. В идеале организаторам стоит рассматривать прецеденты как обязательные контракты между клиентами и разработчиками, где согласуются все детали относительно будущей системы.
|
|
|
• Прецеденты позволяют достичь высокого уровня оперативного контроля трансформации требований в модели в процессе разработки. Если команда разработки постоянно сверяет выполненную работу с описанием прецедентов, она всегда будет в курсе требований клиента.
• Прецеденты позволяют легко преобразовать требования на задачи, которые можно распределить между командами, упростив таким образом организацию выполнения проекта.
Процесс, основанный на архитектуре
В контексте информационной системы термин архитектура имеет разные значения. Все зависит от того, кого вы спросите. В идеологии UML архитектура представляет собой базовую организацию системы. Аспектами архитектуры являются статические элементы, динамические элементы, их совместная работа, а также общий архитектурный стиль, который определяет организацию системы. Архитектура также имеет отношение к вопросам производительности, масштабируемости, повторного использования, экономических и технологических ограничений.
Один из принципов унифицированного процесса состоит в том, что архитектура разрабатываемой системы является фундаментом, на котором будет базироваться система, и потому нужно сосредоточить на ней все усилия команды проекта, чтобы придать форму системе. В то же время архитектура в сочетании с прецедентами должна управлять исследованием всех аспектов системы. Можно представить архитектуру, как нечто, отражающее общее видение всех членов команды, необходимое для того, чтобы созданная система была надежной, гибкой, масштабируемой и рентабельной.
|
|
|
Архитектура в первую очередь определяется терминами представления шести моделей. Эти представления отражают "архитектурно значимые" элементы моделей; все представления вместе взятые образуют архитектурное описание. Команда проекта создает архитектурное описание на ранних стадиях разработки, а затем в ходе всех видов деятельности, связанных с проектом, расширяет и совершенствует его.
Инструменты и технологии, доступные разработчикам для создания информационных систем, становятся все более мощными. Программное обеспечение информационных систем, ориентированное на распределенную обработку данных становится все более сложным. К тому же внимание клиентов снижается, в то время как их требования к командам разработчиков становятся все сложнее. В результате этого программное обеспечение информационных систем становится доступными для понимания лишь ограниченному кругу высококвалифицированных специалистов. Описание архитектуры призвано в первую очередь облегчить понимание того, как строится архитектура системы. Чтобы описание архитектуры могло служить более глубокому пониманию "полной картины" новой системы, потребуется длительное тщательное моделирование и повышенное внимание к читабельности связанных диаграмм UML и вспомогательного текста.
|
|
|
Хорошая архитектура явно определяет отдельные части системы и связующие звенья между ними. В ней также эффективно используются одна или несколько архитектурных схем, чтобы обрисовать действия по разработке на разных уровнях. (Среди хорошо известных архитектурных схем можно назвать тип клиент/сервер, трехуровневый и N-уровневый типы. В других схемах делается акцент на брокерах объектных запросов (ORBs); они находятся в центре системы и используют распределенные компоненты и виртуальные машины наподобие тех, на которых работает Java.) Эффективно используя это свойство архитектуры, команда проекта может положительно влиять на общий ход работы.
|
|
|
Один из базовых принципов разработки, основанной на использовании компонентных объектов, заключается в том, чтобы применять компоненты практически без изменений в контексте разных разработок. Хорошо сконструированная архитектура предоставляет надежную основу для компонентов и их постоянного взаимодействия. Это позволяет командам, разрабатывающим другие системы, определить возможности повторного использования любого из них или всех вместе. Практический результат этих действий в том, что, чем меньше времени команда затратит на построение новых компонентов, тем больше времени она сможет уделить рассмотрению проблем заказчика и моделированию решений.
Поддержка и совершенствование системы обычно занимает больше времени, чем первоначальное создание. В то время когда проекты работают в мифическую эру Internet, когда технологии развиваются все быстрее, а бизнес-модели меняются все чаще, не остается сомнений в том, что система любого размера и сложности подвергнется эволюционным изменениям в необходимом масштабе. При наличии надежной архитектуры можно выделить ряд необходимых контрольных точек и опираться на них при дальнейшей разработке. Если архитектура построена так, что изменения в одной части системы почти никогда не будут неблагоприятно влиять на остальные части системы, существенно повышается возможность членов команды эффективно развертывать систему.
С одной стороны, прецеденты управляют архитектурой информационной системы, поскольку они управляют всеми действиями при разработке. А с другой стороны, архитектура управляет выбором и исследованием прецедентов. Решения, которые архитекторы принимают относительно промежуточного программного обеспечения, системного программного обеспечения, унаследованных систем и т.д., оказывают существенное влияние на выбор прецедентов, на которых будет сосредоточена команда на разных этапах проекта. Цель состоит в том, чтобы сконцентрировать внимание на тех прецедентах, которые способствуют разработке хорошей архитектуры, определяющей, в свою очередь, содержание этих прецедентов и природу работы, необходимой для построения из них системы.
Унифицированный процесс характеризуется итеративностью и инкрементностью природа. Итерация представляет собой мини-проект, результатом которого является версия системы и, который завершается внешним либо внутренним выпуском. Считается, что эта версия является улучшенным (инкрементным) вариантом предыдущей версии, поэтому результат итерации называется инкрементом.
На этапе ранних итераций команда создает начальную архитектуру, которая предлагает исходные принципы надежной основы; в ходе последующих итераций команда расширяет свое видение полной архитектуры, что, в свою очередь, влияет практически на все, а в некоторых случаях абсолютно на все задачи разработки, которые необходимо выполнить как часть данной итерации. Построение архитектуры по итеративно-инкрементному принципу позволяет команде внести основные изменения на ранней стадии процесса, что принесет меньше убытков, чем при выполнении этого на более поздних этапах.
Процессы, основанные на водопадном подходе, при котором все требования должны быть собраны и проанализированы перед началом разработки, сталкиваются с неизбежной проблемой: требования не остаются неизменными. К тому же заказчики с трудом представляют себе систему, если все, что у них есть, — это документация. Унифицированный процесс поддерживает необходимость разбивки системы на конструкции, каждая из которых представляет собой рабочую версию определенной значимой части целой системы. Сосредоточив внимание на связанных наборах прецедентов и эффективно используя прототипы, команда проекта сможет взаимодействовать с заказчиком на протяжении всей работы, таким образом уменьшая (часто очень большой) риск, связанный с попытками определить все требования наперед. Некоторые компания используют принцип "безжалостного установления приоритетов", согласно которому при работе с изменяющимися требованиями довольно агрессивно определяются приоритеты, а элементы с низким приоритетом исключаются из рассмотрения.
Поскольку каждая итерация представляет собой мини-проект, то каждый раз при создании инкремента системы команда разработчиков в той или иной мере сталкивается со всеми рисками, связанными с проектом. Когда риск увеличивается, возникают задержки и среда становится нестабильной, команда может внести необходимые поправки на уровне одной итерации, а затем распространить их по всей системе. В ходе выполнения постпрограммы для каждой итерации руководители проекта, прежде чем приступать к работе над следующей итерацией, могут решить, была ли итерация успешной и подходит ли данная схема итерации. Цель состоит в том, чтобы изолировать проблемы в пределах отдельной итерации и решить их в небольшом формате, вместо того чтобы позволить распространиться на весь проект.
Каждая итерация привносит комбинацию новых свойств и улучшает функциональность системы. Это позволяет организаторам проекта ограничить его развитие достижением конкретных целей, а не более абстрактных и общих требований. Постоянно интегрируя новые инкременты, команда разработчиков получает возможность также изолировать проблемы, которые итерация может внести в систему, и исправляет их так, чтобы они не могли нарушить целостности работающей системы. Такое формирование задания упрощает работу команды, которая может пойти на то, чтобы отбросить отдельный инкремент и начать все сначала, потому что ход развития проекта позволяет определить, какую из итераций можно выполнить быстрее.
Каждый вид деятельности команды в ходе итерации, строго определен как последовательность действий, принадлежащая одному технологическому процессу или нескольким одновременно. Процесс построен таким образом, чтобы можно было полагаться на постоянный инструктаж непосредственно в ходе работы как на альтернативу предварительному всестороннему обучению сотрудников, которые лишь после его окончания становятся полноценными членами команды. Хорошо определенные итерации не оставляют места для экспериментов и ошибок, поскольку эти ошибки могут быть изолированы так, что их влияние на расписание работ и бюджет будет минимальным. В ходе работы команда может расширить представление о том, что она пытается разработать, и о связанных с этим рисках, т.е. получить представление о движущей силе проекта, что, в свою очередь, позволит команде непрерывно вносить изменения, совершенствуя свою деятельность по выполнению задач.
Наверное, наиболее важное преимущество итеративной и инкрементной разработки состоит в том, что она позволяет команде сосредоточить усилия на устранении наиболее опасных моментов в ранний период жизненного цикла. Команда может организовать итерации так, чтобы постоянно работать над устранением рисков; целью является максимально возможное снижение риска в ходе каждой итерации, чтобы каждая новая итерация сопровождалась меньшим количеством рисков (к тому же менее важных), чем предыдущие.
Предлагаются различные подходы к организации категорий рисков в проектах разработки программного обеспечения. При обсуждении унифицированного процесса небесполезным будет описание трех категорий рисков, приведенное ниже.
• Технические риски связаны с различными технологиями, применяемыми в ходе процесса и с совершенствованием таких свойств, как производительность, а также читаемость, расширяемость и т.д. Например, если в системе в контексте Common Object Request Broker Architecture (CORBA — обобщенная архитектура брокера объектных запросов) использовать технологию Enterprise Java Beans (EJB), команде проекта придется решить ряд потенциальных технических проблем, для того чтобы система могла приемлемо работать. Процесс не ориентирован специально на устранение технических рисков, но команда работает над их устранением на ранних этапах, еще до начала кодирования.
• Архитектурные риски связаны со способностью архитектуры служить прочным фундаментом системы, а также быть гибкой и легкоадаптируемой к добавлению новых свойств в будущих версиях системы. К этой категории также относятся риски, связанные с такими решениями, как "создание в сравнении с окупаемостью". Процесс устраняет архитектурные риски при определении видов деятельности, которые включают анализ, разработку и реализацию архитектуры, а также при определении некоторых других видов деятельности, в число которых входит постоянное обновление описания архитектуры с тем, чтобы она могла занять ведущее место в ходе разработки.
• Риск при работе с требованиями — это риск разработать не ту систему, за которую платят клиенты, ввиду непонимания требований или из-за того, что в процессе разработки были использованы не те прецеденты. Процесс устраняет этот риск с помощью видов деятельности, специально предназначенных для того, чтобы упростить обсуждение и уточнение требований, а также исходного условия, согласно которому прецеденты управляют всеми аспектами разработки.
Жизненный цикл разработки программного обеспечения информационной системы может быть представлен в виде ряда циклов. Цикл завершается выпуском версии системы клиентам.
Каждый цикл унифицированного процесса состоит из четырех фаз. Фаза представляет собой промежуток времени между двумя вехами, т.е. точками, в которых менеджеры принимают важные решения относительно продолжения разработки и в случае положительного решения определяют границы проекта, бюджет и расписание.
На рис. 4.1 показаны фаза и вехи унифицированного процесса. Как видите, каждая фаза содержит одну или более итераций.
Рис. 1.1. Фазы и вехи
Дата добавления: 2018-11-24; просмотров: 262; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!