Сценарий 6. Реорганизация

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

ВЫВОД:

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

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

■ Программные требования определяются (большей частью) из моделей производства.

48. Технологический процесс управления требованиями.

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

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

■ Разработчики системы вместе с заказчиками и другими заинтересованными сторонами должны выработать единое мнение о том, что должна делать система. Что и зачем!

■ Разработчики должны полнее понять системные требования.

■ Должны быть определены границы системы.

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

■ Исходя из нужд и целей пользователей, должен быть определен пользователь­ский интерфейс системы

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

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

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

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

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

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

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

ВЫВОД:

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

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

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

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

 

 

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

 

49. Технологический процесс анализа и проектирования.

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

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

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

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