19269

Понятие жизненного цикла и модели жизненного цикла. Каскадная модель ЖЦ. Поэтапная модель с промежуточным контролем

Лекция

Информатика, кибернетика и программирование

Лекция 2. Понятие жизненного цикла и модели жизненного цикла. Каскадная модель ЖЦ. Поэтапная модель с промежуточным контролем. Спиральная модель ЖЦ. Процессы ЖЦ ПО. Rapid Application DevelopmentRAD. Extreme Programming XP. Rational Unified Process RUP. Microsoft Solution Framework MSF. Custom Development Method методика Oracle. 2.1...

Русский

2013-07-11

311.49 KB

41 чел.

Лекция 2.

Понятие жизненного цикла и модели жизненного цикла. Каскадная модель ЖЦ. Поэтапная модель с промежуточным контролем. Спиральная модель ЖЦ. Процессы ЖЦ ПО. Rapid Application Development(RAD). Extreme Programming (XP). Rational Unified Process (RUP). Microsoft Solution Framework (MSF). Custom Development Method (методика Oracle).

2.1. Понятие жизненного цикла и модели жизненного цикла

Жизненный цикл ИС –период времени, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации. ЖЦ ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

Модель ЖЦ ПО включает в себя (слайд 3):стадии, результаты выполнения работ на каждой стадии, ключевые события - точки завершения работ и принятия решений.

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

Крайним случаем модели ЖЦ можно считать так называемую модель «черного ящика» (black box) или «code and fix» (кодирование и исправление), что фактически означает отсутствие какой-либо модели. В этом случае выделить какие-либо рациональные стадии в процессе разработки ПО не представляется возможным, поскольку отсутствует планирование и организации работ.

В настоящее время известны и используются следующие модели жизненного цикла:

  •  Каскадная модель (характерна для периода 1970-1980 гг.);
  •  Поэтапная модель с промежуточным контролем (характерна для периода 1980-1985 гг.); 
  •  Спиральная модель (характерна для периода после 1986 г.)

2.2. Каскадная модель ЖЦ

В1970 г. эксперт в области ПО Уинстон Ройс опубликовал получившую широкую известность статью, в которой он излагал свое мнение о методике, которая позднее получила название «модель водопада» (waterfall model), или «каскадная модель» (слайд 4).

Впоследствии эта модель была регламентирована множеством нормативных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34.

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

Принципиальными свойствами так называемой «чистой» каскадной модели являются следующие:

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

Преимущества применения каскадной модели заключаются в следующем:

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

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

Другими недостатками каскадного подхода являются:

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

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

2.3. Поэтапная модель с промежуточным контролем

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

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

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

2.4. Спиральная модель ЖЦ  

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

В середине 1980-х годов Барри Боэм предложил свой вариант итерационной модели под названием спиральная модель  (слайд 6).

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

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

Принципиальные свойства спиральной модели:

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

Достоинствами спиральной модели являются:

  •  ускорение разработки (раннее получение результата за счет прототипирования);
  •  постоянное участие заказчика в процессе разработки;
  •  разбиение большого объема работы на небольшие части;
  •  снижение риска (повышение вероятности предсказуемого поведения системы).

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

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

К недостаткам спиральной модели можно отнести:

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

2.5. Процессы ЖЦ ПО

Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Каждый процесс разделен на набор действий, каждое действие –на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения.

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является (слайд 7) международный стандарт ISO/IEC 12207: 1995 “Information TechnologySoftware Life Cycle Process”. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Российский аналог этого стандарта –ГОСТ Р ИСО/МЭК 12207-99, введен в действие в июле 2000 г.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы (слайд 8):

Основные процессы определяют основные действия и задачи, выполняемые в ходе ЖЦ ИС. 

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

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

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать указанные на слайде 9 группы процессов:

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше (слайд 10).

2.6. Rapid Application Development (RAD)

Rapid Application Development (RAD) –это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

Подход RAD предусматривает наличие трех составляющих:

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

Жизненный цикл ПО в соответствии с подходом RAD состоит из четырех стадий (слайд 11):

  •  анализ и планирование требований;
  •  проектирование;
  •  реализация;
  •  внедрение.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. Если требуется, для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Устанавливаются требования разграничения доступа к данным. На этой же фазе происходит определение необходимой документации.

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

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

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

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

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

  •  определяется необходимость распределения данных;
  •  осуществляется анализ использования данных;
  •  производится физическое проектирование базы данных;
  •  определяются требования к аппаратным ресурсам;
  •  определяются способы увеличения производительности;
  •  завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

Основные принципы подхода RAD:

  •  Работа ведется группами. Типичный состав группы - руководитель, аналитик, два программиста, технический писатель. Если проект сложный, то для него может быть выделено несколько RAD-групп.
  •  разработка приложений итерациями; Разработка системы и предъявление ее заказчику осуществляется в виде последовательности развиваемых прототипов. Число прототипов определяется на основе учета разных параметров –размера проекта, анализа рисков, пожеланий заказчика и т. д.
  •  необязательность полного завершения работ на каждой из стадий жизненного цикла ПО;
  •  Разработка проекта выполняется в условиях тесного взаимодействия между разработчиками и Заказчиком
  •  Разработка базируется на моделях. Моделирование позволяет оценить проект и выполнить его декомпозицию на составные части, каждая из которых может разрабатываться отдельной RAD-группой
  •  Обязательное использование инструментальных средств, автоматизирующих процесс разработки, и методик их использования, следствием чего является сокращение сроков разработки и повышение качества конечного продукта;
  •  тестирование и развитие проекта, осуществляемые одновременно с разработкой;
  •  грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ
  •  ведение разработки немногочисленной хорошо управляемой командой профессионалов;
  •  RAD группа всегда работает только над одним прототипом. Это обеспечивает единство целей, лучшую наблюдаемость и управляемость процессом разработки, что в итоге повышает качество конечного продукта.
  •  Если проект сложный, то для него может быть выделено несколько RAD групп. Большие системы разбиваются на подсистемы. Каждая подсистема разрабатывается независимой группой.

Применение технологии RAD целесообразно, когда:

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

2.7. Extreme Programming (XP)

Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. Экстремальное программирование было анонсировано Кентом Беком в 1995 году в компании Chrysler. Экстремальное программирование основывается на идее адаптации изменений в программном проекте вместе с отказом от детального планирования. XP отходит от традиционного процесса создания программной системы и вместо единоразового планирования, анализа и проектирования с расчетом на долгосрочную перспективу, в XP все эти операции реализуются постепенно в ходе разработки, добиваясь тем самым значительного сокращения времени разработки и стоимости изменений в программе.

XP годится для создания программ коллективом от 2-х до 10 программистов, –это оптимальное число людей, когда они могут свободно общаться друг с другом. Extreme Programming стремится, хоть и не явно, к специализации по выпуску кода высокого качества для оправдания постоянно меняющихся ожиданий пользователей. В отличие от RAD, Extreme Programming не стремится к выпуску всеобъемлющего продукта за 2-3 месяца, а, напротив, стремится к выпуску множества небольших продуктов за больший промежуток времени. Extreme Programming придает большое значение написанию тестов перед написанием самого кода программного продукта, чтобы гарантировать, что код, будучи уже выпущен, не будет иметь одних и тех многократно возникающих ошибок; это также позволяет программистам писать код программ, опираясь на созданные тесты, тем самым повышая его эффективность, поскольку цели написания написания кода уже ясны. В отличие от многих других процессов, XP не заставляет программистов писать кучу отчетов и строить множество моделей.

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

Практики XP.

  1.  Планирование процесса
  2.  Частые релизы
  3.  Метафора системы
  4.  Простая архитектура
  5.  Тестирование
  6.  Рефакторинг
  7.  Парное программирование
  8.  Коллективное владение кодом
  9.  Частая интеграция
  10.  40-часовая рабочая неделя
  11.  Стандарты кодирования
  12.  Тесное взаимодействие с заказчиком

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

Схема потоков работ в XP представлена на слайде 12.

Преимуществами XP являются:

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

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

Экстремальное программирование эффективно применяется:

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

2.8. Rational Unified Process (RUP)

Rational Unified Process (Rup) отличается от XP по некоторым основным направлениям. Это –меньшее количество привлеченных к работе над проектом основных разработчиков, подразумевающее более деятельное предварительное планирование и дизайн системы, разработку требований к программе, более интенсивный предварительный процесс, предшествующий началу работы разработчиков, и больше бюрократии. Также устраняется неэффективность некоторых ресурсов, в связи с отсутствием парного программирования и ротации позиций участников проекта.

RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта —анализу и моделированию. Эта методология направлена на снижение коммерческих рисков посредством обнаружения ошибок на ранних стадиях разработки. Технические риски оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми.

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

Процесс предполагает эволюционирование моделей; итерация цикла разработки однозначно соответствует определенной версии модели программного обеспечения. Каждая из итераций  содержит элементы управления жизненным циклом программного обеспечения: анализ и дизайн (моделирование), реализация, интегрирование, тестирование, внедрение.

Rational Unified Process поддерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), в качестве единого стандарта для организации взаимодействия участников проекта используют Unified Modelling Language (UML) —универсальный язык моделирования.

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

Структура жизненного цикла проекта

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание) (слайд 13). Целями каждой из данных фаз являются:

  •  Inception —понимание, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;
  •  Elaboration —понимание, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;
  •  Construction —создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);
  •  Transition —создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.

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

RUP определяет следующие основные процессы:

  •  моделирование бизнес-процессов;
  •  управление требованиями;
  •  анализ и проектирование;
  •  реализация;
  •  тестирование;
  •  развертывание;
  •  конфигурационное управление и управление изменениями;
  •  управление проектом;
  •  управление средой.

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

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

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

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

Реализация необходима для выявления порядка организации программного кода в терминах отдельных подсистем, преобразования исходного кода в выполняемые компоненты, тестирования созданных компонентов и интеграции отдельных компонентов в подсистемы и системы.

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

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

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

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

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

В RUP рекомендовано следовать шести практикам, позволяющим успешно разрабатывать проект:

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

Практики не являются непосредственно частью процесса RUP, но настоятельно рекомендованы к использованию.

Недостаток методологии RUP: Использование User Cases (вместо User Stories) делает возможным более точное определение ситуаций, с которыми придется иметь дело готовому программному продукту, по сравнению с User Stories у XP, которое более стандартно. В то время, как Cases ведут к более жестким требованиям к программному обеспечению, они могут иметь слишком узкую направленность и упускать из виду некоторые проблемы, которые могут возникнуть при использовании программного продукта.

2.9. Microsoft Solution Framework (MSF)

Microsoft Solutions Framework (MSF) - это комплект взаимосвязанных моделей, концепций и руководств по созданию и внедрению распределенных информационных систем уровня предприятия. Он содержит набор интегрированных ресурсов (практические руководства, аудиторные занятия, описания методик и методологий) и принципов, приводящих проектные группы к успеху. В основе Microsoft Solutions Framework лежат следующие идеи:

  •  управление рисками и их планирование;
  •  выпуск промежуточных версий;
  •  планирование активности;
  •  четко обозначенные контрольные точки (вехи);
  •  проектные группы небольшой численности.

MSF содержит следующие модели:

Team Model (Модель команды) —описывает коллектив, в котором работа одного сотрудника зависит от другого;

Proccess Model (Модель процесса) —позволяет определить принципы планирования и контроля проектов;

Application Model (Модель приложения) —помогает создавать приложения, максимально используя готовые компоненты;

Enterprise Architecture Model (Модель архитектуры корпорации) —обеспечивает принятие решения по технологиям; она очень важна для эффективного использования новых технологий;

Solution Desing Model (Модель проектирования решений) —показывает, каким должно быть приложение с точки зрения пользователя. Эта модель связывает приложение, команду разработчиков и процесс разработки;

Infrastructure Model (Модель управления инфраструктурой) —определяет принципы управления пользователями в больших сетях;

Total Cost of Ownership Model (Модель стоимости владения продуктом) — позволяет оценивать расходы на информационные технологии.

Модель процесса

Microsoft Solution Framework (MSF) сочетает водопадную и спиральную модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали (слайд 14).

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

Создание общей картины приложения

На этом этапе решаются следующие основные задачи: определение состава команды; определение структуры проекта; определение бизнес-целей; оценка существующей ситуации; создание документа общей картины и области действия проекта; определение требований и профилей пользователей; разработка концепции решения; оценка риска; закрытие этапа.

На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и "Создана общая картина решения".

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

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

Этап завершается контрольной точкой "Утверждение документа общей картины и области действия проекта".

Планирование

На этапе планирования команда решает, что нужно разработать, и формирует планы реализации продукта. Готовится функциональная спецификация, создается проект решения, детализируются планы работы, выполняется оценка стоимости и сроков получения результатов.

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

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

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

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

Разработка

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

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

Стабилизация

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

Тестирование подразумевает следующие основные виды работ: тестирование компонентов;  тестирование баз данных;  тестирование инфраструктуры;  тестирование защиты;  тестирование интеграции;  анализ удобства работы с продуктом; нагрузочное тестирование (включая анализ ресурсоемкости и производительности); регрессивное тестирование; ведение отчетности по тестированию.

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

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

Развертывание

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

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

2.10. Custom Development Method (методика Oracle)

Метод Oracle (Oracle Method) - комплекс методов, охватывающий большинство процессов ЖЦ ПО. В состав комплекса входят:

  •  CDM (Custom Development Method) - разработка прикладного ПО;
  •  PJM (Project Management Method) - управление проектом;
  •  AIM (Application Implementation Method) - внедрение прикладного ПО;
  •  BPR (Business Process Reengineering) - реинжиниринг бизнес-процессов;
  •  OCM (Organizational Change Management) - управление изменениями, и др.

Custom Development Method (методика Oracle) по разработке прикладных информационных систем —технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle.

В соответствии с этими факторами в CDM выделяются два основных подхода к разработке:

  •  Классический подход (Classic). Классический подход применяется для наиболее сложных и масштабных проектов, он предусматривает последовательный и детерминированный порядок выполнения задач. Для таких проектов характерно большое количество реализуемых бизнес-правил, распределенная архитектура, критичность приложения. Применение классического подхода также рекомендуется при нехватке опыта у разработчиков, неподготовленности пользователей, нечетко определенной задаче. Продолжительность таких проектов от 8 до 36 месяцев.
  •  Подход быстрой разработки (Fast Track). Данный подход, в отличие от каскадного классического, является итерационным и основан на методе DSDM (Dynamic Systems Development Method). В этом подходе четыре этапа - стратегия, моделирование требований, проектирование и генерация системы и внедрение в эксплуатацию. Подход используется для реализации небольших и средних проектов с несложной архитектурой системы, гибкими сроками и четкой постановкой задач. Продолжительность проекта от 4 до 16 месяцев.

Классический подход

В соответствии с классическим подходом CDM ЖЦ ПО формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов (слайд 15):

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

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

На этапе проектирования разрабатывается подробная архитектура системы, проектируются схема реляционной БД и программные модули, устанавливаются перекрестные ссылки между компонентами системы для анализа их взаимного влияния и контроля за изменениями.

На этапе реализации создается БД, строятся прикладные системы, производится их тестирование, проверка качества и соответствия требованиям пользователей. Создается системная документация, материалы для обучения и руководства пользователей.

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

Процессы CDM:

  •  определение бизнес-требований, или постановка задачи (Business Requirements Definition);
  •  исследование существующих систем (Existing Systems Examination). Выполнение этого процесса должно обеспечить понимание состояния существующего технического и программного обеспечения для планирования необходимых изменений;
  •  определение технической архитектуры (Technical Architecture);
  •  проектирование и реализация базы данных (Database Design and Build). Процесс предусматривает проектирование и реализацию реляционной базы данных, включая создание индексов и других объектов БД;
  •  проектирование и реализация модулей (Module Design and Build). Этот процесс является основным в проекте. Он включает непосредственное проектирование приложения и создание кода прикладной программы;
  •  конвертирование данных (Data Conversion). Цель этого процесса - преобразовывать, перенести и проверить согласованность и непротиворечивость данных, оставшихся в наследство от "старой" системы и необходимых для работы в новой системе;
  •  документирование (Documentation);
  •  тестирование (Testing);
  •  обучение (Training);
  •  внедрение, или переход к новой системе (Transition). Этот процесс включает решение задач установки, ввода новой системы в эксплуатацию, прекращения эксплуатации старых систем;
  •  поддержка и сопровождение (Post-System Support).

Процессы состоят из последовательностей взаимосвязанных задач.

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

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


 

А также другие работы, которые могут Вас заинтересовать

41474. Аудит финансового состояния предприятия 83.75 KB
  Независимое подтверждение информации о результатах деятельности предприятий и соблюдения ими законодательства необходимо государству для принятия решений в области экономики и налогообложения.
41475. Культура педагогического труда 131.65 KB
  Цель курсовой работы - изучение профессиональной компетентности и определение смысла педагогической культуры.
41476. Теория систем и системный анализ, учебное пособие 1.97 MB
  Системный анализ – это научная дисциплина, занимающаяся проблемами принятия решений в условиях анализа большого количества информации различной природы. Целью применения системного анализа к конкретной проблеме является повышение степени обоснованности принимаемого решения
41477. Нестандартні уроки як засіб підвищення якості знань учнів на уроках математики 111.46 KB
  Головним завданням педагога – є не тільки чітке усвідомлення мети кожного окремого уроку, а й розуміння важливості проведеного заняття як органічної ланки загального ланцюжка даної теми, розділу, курсу, циклу, всього навчально-виховного процесу.
41478. Жизнь первобытных людей 12.4 MB
  Животный мир пестрел удивительными видами осанки, которые находят во время раскопок. Климат был теплым и влажным. Исполинские папоротники покрывали землю.
41479. Уголовно-процессуальное право Республики Казахстан 601.01 KB
  Целью фундаментальной юридической дисциплины «Уголовное процессуальное право Республики Казахстан» является усвоение студентами сложной и многогранной деятельности государственных органов и должностных лиц по возбуждению, предварительному расследованию и судебному рассмотрению уголовных дел.
41480. ПСИХОЛОГИЯ ЧЕЛОВЕКА 948 KB
  Учебно-методическое пособие по дисциплине «Психология человека» является составной частью учебно-методических материалов по данной учебной дисциплине (УМК «Психологии человека. Часть I».) и составлено в соответствии с требованиями Федерального государственного образовательного стандарта высшего профессионального образования по направлению 050100 «Педагогическое образование».
41481. Входная информация формирования объема предложений по организации грузовых автомобильных перевозок 281 KB
  Оборотные средства включают в свой состав, как производственные запасы, так и денежные ресурсы, находящиеся в обращении. Стоимость оборотных средств определяем
41482. Методика формирования природоохранных знаний в процессе изучения общей биологии 114.5 KB
  В курсе общей биологии при изучении вопросов охраны природы целесообразно разграничивать проблемы охраны сообществ и видов. Так в курсе общей биологии IX класса более полно раскрыть понятие об охране природы можно на примере рационального использования популяций и сохранения видового многообразия биосферы. При изучении темы Эволюционное учение следует так спланировать уроки чтобы выделить в самостоятельные разделы вопросы об антропогенных факторах популяционновидовых систем и природоохранительных факторах. Линнея Понятие вид...