Понятие архитектуры системы. Понятие прототипа системы.



Действующая архитектура – это частичная реализация системы, созданная с целью продемонстрировать, что подобная архитектура способна поддерживать ключевые функции. Но более важно то, что при этом демонстрируется способность архитектуры удовлетворить требованиям по быстродействию, пропускной способности, объёму данных, надёжности, масштабируемости и т. д. Создание действующей архитектуры позволяет на следующих фазах уверенно строить на прочном фундаменте все функциональные возможности системы. Действующая архитектура – это эволюционный прототип, который в ходе своей эволюции будет сохранять проверенные функции и те функции, которые с высокой вероятностью удовлетворят требованиям к системе, когда архитектура будет завершена. Говоря другими словами, эти функции станут частью завершенной системы. В отличие от функционального прототипа, который создаётся на шаге 1, эволюционный прототип полностью охватывает все вопросы архитектуры.

 

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

 

Но как придумать архитектуру эволюционного прототипа? Главное – сконцентрироваться на самых важных вариантах использования, примерно от 20% до 30% всех услуг, которые системы должна предоставлять конечным пользователям. Далее приведены некоторые способы для определения самых важных вариантов использования.

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

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

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

 

Особенности (преимущества) RUP как итеративной и управляемой технологии.

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

 

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

Итеративный подход имеет преимущества над каскадным подходом по ряду следующих причин.

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

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

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

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

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

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

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

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

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

 

Некоторые руководители проектов не хотят применять итеративный подход, потому что считают его формой бесконечной и неуправляемой возни. Но в процессе RUP весь проект полностью управляем. Количество итераций, их длительность и цели – всё это тщательно планируется, задачи и ответственности участников четко определены. Кроме того, регистрируются объективные показатели прогресса. И хотя группа переделывает некоторые вещи от одной итерации к другой, эта работа тщательной контролируется.

 


Дата добавления: 2018-02-15; просмотров: 539; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!