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

Методологии разработки ПО:

• Тяжеловесные

• Гибкие

Тяжеловесные методологии разработки ПО - прогнозирующие (predictive) или тяжеловесные (heavyweight) процессы.

 

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

Переход с одной стадии на следующую происходит только после того, как будет полностью завершена работа на текущей.

 

В качестве примера можно рассмотреть каскадную модель ЖЦ ИС Марри Кантора, предложенную в 2002 году. По мнению М. Кантора, на каждом этапе ЖЦИС происходят следующие операции:

• Составление плана действий

• Планирование работ для каждого действия

• Применение операции отслеживания хода выполнения действия (включая контрольные этапы)

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

 

 

Достоинства модели:

Недостатки модели:

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

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

 

Рациональный унифицированный процесс (Rational Unified Process, RUP) также является примером «тяжелого» процесса, детально описанного и предполагающего поддержку разработки исходного кода ПО большим количеством вспомогательных действий. Примерами подобных действий являются разработка планов, технических заданий, многочисленных проектных моделей, проектной документации и пр.

Акцент данная методология делает на том, чтобы гарантировать выполнение проекта

– точно в срок

– с соблюдением установленного бюджета,

– с заданным качеством обеспечения требований заказчика.

Основные принципы RUP

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

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

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

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

Визуальное моделирование на основе UML.

Контроль качества.

 

Критерии применимости:

• прогнозируется весь объем работ,

• большой объем документации,

• строгий порядок разработки,

• фиксированные требования,

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

 

Плюсы «тяжеловесных» технологий	Минусы «тяжеловесных» технологий
•Процессы рассчитаны на среднюю квалификацию исполнителей. •Большая специализация исполнителей. •Ниже требования к стабильности команды. •Отсутствуют ограничения по объему и сложности выполняемых проектов.	•Требуют существенной управленческой надстройки. •Более длительные стадии анализа и проектирования. •Более формализованные коммуникации.

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

 

Раскройте функциональные возможности и тенденции развития Unified Modeling Language (UML), сформулируйте критерии практической применимости UML для проектирования информационных систем различной сложности.

 

Статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо. В то же время аббревиатура UML, как и некоторые другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев.

UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.

UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

 

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

UML — это язык конструирования.

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

UML предоставляет возможности прямого (существующая модель ® новый код) и обратного (существующий код ® новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk.

 

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

 

б) - показывает изменение ситуации после появления UML

 

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

 

 

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

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

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

Кроме основных процессов в организации выделяют:

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

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

- процессы непрерывного улучшения – систематическое улучшение отдальных параметров процесса на основе цикла Эдвардса Деминга «планируй – делай – проверяй – корректируй».

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

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