Билет №23

1. Проблеми розробки ПО та шляхи їх розв’язання (Rational Unified Process - (RUP)

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

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

Rational Unified Process - это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

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

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

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

• итерационной разработке ПО;

• управлении требованиями;

• использовании компонентной архитектуры;

• визуальном моделировании;

• тестировании качества ПО;

• контроле за изменениями в ПО.

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

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

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

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

2. Ідентифікація ризиків.

1. Категории рисков:

• проэктные риски

• технические риски

• коммерческие риски

1. Источники проектного риска:

• Вывод бюджета,плана

• Формирование тренований кпрограммному продукту

• Выбор структуры програмного продукта

• Методика взаимодействия с заказчиком

2. Источники технических рисков

• Разработка проэктов

• Неточность спецификации

• Наличие неопределенностей + ожидаемые решения

• Отсутствие технических средств

3. Коммерческие риски:

• Создание програмного продукта которыйне относится к R-ном.риску

• Создание программнеого продукта,опрежающего требования работодатчика

• Потери проэктирования

3 Шляхи скорочення проблем, пов’язаних з ризиками

Способы снижения риска

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

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