13. Структура модели бизнес – процесса в руп, пример

В процессе можно выделить две структуры.

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

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

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

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

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

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

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

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

14. Требования в руп, формирование и анализ, примеры

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

Требование - это условие или возможность, которой должна соответствовать

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

• Требования не всегда очевидны и могут исходить из разных источников.

• Требования не всегда удается ясно выразить словами.

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

• Число требований может стать неуправляемым, если ими не управлять.

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

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

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

• Требования изменяются

Функциональные требования

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

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

Нефункциональные требования

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

Нефункциональные требования к параметрам качества можно разделить на кате­гории FURPS.

• Практичность

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

• Надежность

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

• Производительность

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

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

• Возможность поддержки

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