Раскройте современные подходы к стандартизации и моделированию жизненного цикла информационных систем.

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

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

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

• Гибкие

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

Обзор и сравнительный анализ гибких методологий разработки ПО:

Канбан (организация поддержки);

Lean (оптимизация производства);

Экстремальное программирование ХР (инженерные практики);

Scrum (управленческий фреймворк).

 

В основе Канбан лежат три базисных принципа:

•   Визуализация (иероглиф "кан"). При иллюстрировании и моделировании процесса он разбивается на отдельные стадии (анализ, проектирование, разработка, тестирование и т. д.), упрощая таким образом его восприятие.

•   Ограничение максимального количества задач на определенном этапе. Этот принцип позволяет свести потери к минимуму - максимальное сосредоточение на своих задачах.

•   Оптимизация существующего процесса. Время на выполнение задачи отслеживается, анализируется, и вырабатываются предложения о том, как можно выполнить работу более совершенно. В процессе не должно быть простоев, равно как и не должна выполняться ненужная работа. Kanban характеризуется утверждением: "Уменьшение выполняющейся в данный момент работы". Данный тип методологии является, пожалуй, самым гибким. Это значит, что она является наиболее требовательной к условиям и ресурсам, в рамках которых предполагается ее эксплуатировать. Сотрудники, работающие по Канбан n, должны быть готовы к экстремальной гибкости и при этом не должны ломаться.

Уникальность методологии Канбан

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

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

•   Размере задач, которые необходимо реализовать. В сравнении с аналогами задач меньше, но их объем и трудоемкость значительно больше.

•   Отсутствии активности оценки и планирования. Оценки сроков на задачу: опциональные или вообще их нет.

Канбан ориентирована на задачи. Сотрудники работают над задачами с самого начала и до завершения. Рабочая команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале. Если менеджер верит команде, то зачем иметь оценку времени?

 

Lean

Этот тип методологии подразумевает создание продукта в условиях максимальной экономии ресурсов с целью устранения всех возможных потерь. Изначальный функционал продукта ограничивается до минимально полезного. Таким образом, функционал реализуется путем поэтапного наращивания функционала небольшими порциями, сродни инкрементальному принципу реализации информационных систем. Корни этого подхода относятся к принципам бережливого производства (Lean Manufacturing). Мэри и Том Поппендик, о которых было упомянуто в "Введение в Agile" курса, адаптировали эти принципы для разработки программного обеспечения:

•   устранение потерь;

•   повышение качества;

•   создание знаний;

•   отсроченные обязательства;

•   быстрая поставка;

•   уважение людей;

•   полная оптимизация.

Lean постулирует отказ от всего, что не добавляет ценности создаваемой информационной системе. Разрабатывать необходимо только то, в чем есть абсолютная уверенность, что это нужно делать сейчас. Устранение потерь во всех аспектах работы (бесполезные собрания, избыточные задачи, документация, неэффективные способы работы и т. д.). Акцент на то, что называется "системным подходом", то есть сотрудники работают как единое целое, как команда. Необходимо верхнеуровневое осознание того, что выполняемая работа помогает повышать ценность создаваемого продукта, в сравнении с аналогами. Не нужно заставлять людей работать на 150% их рабочего времени. Не нужно кодировать то, что не нужно. Дополнительный функционал создает дополнительные обязательства для пользователей и руководства. Сотрудники нуждаются в уважении как личностном, так и профессиональном. Нужно давать им ту работу, которую они лучше всего знают, как надо сделать. Смысл программной разработки в постоянном обучении. Принятие управленческих решений нужно выполнять в последний возможный момент. К моменту реализации необходимого функционала сотрудники будут знать уже больше и лучше ориентироваться не только в создаваемой системе, но и в бизнес-процессах и данных организации.

 

Scrum

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

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

 

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

 

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

 

 

Раскройте функциональные возможности и тенденции развития 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 модель сложной системы создается в виде совокупности логически связанных диаграмм.

 

 

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

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

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

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

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

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

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

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

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

 

 

Варианты организации процессного офиса

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

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

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

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

 

Раскройте современные подходы к стандартизации и моделированию жизненного цикла информационных систем.

 

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

 

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

Классическими являются следующие стандарты:

· ГОСТ 34.201-89. "Виды, комплектность и обозначение документов при создании автоматизированных систем";

· ГОСТ 34.003-90 "Термины и определения";

· ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы";

· ГОСТ 34.603-92 "Виды испытаний автоматизированных систем";

· ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания";

· Руководящий документ РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов".

 

В области управления ИТ в части программного обеспечения основополагающим является ГОСТ Р ИСО/МЭК 12207-99 " Процессы жизненного цикла программных систем"

Наиболее полным на сегодняшний день методическим руководством по программной инженерии следует признать появившийся в 2004 г. документ SWEBOK, полное английское название которого - Guide to the Software Engineering Body of Knowledge (SWEBOK), что можно перевести как "Руководство к методическому справочнику по программной инженерии" (IEEE Computer Society, 2004).

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

Одно из приложений к руководству (Приложение С) целиком посвящено стандартам.

Содержание Приложения С - таблица, показывающая степень покрытия стандартами (их приведено свыше пятидесяти) десяти разделов SWEBOK.

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

 

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

В общем виде жизненный цикл ИС включает в себя следующие этапы:

– Планирование проекта

– Анализ и постановка задачи

– Проектирование

– Разработка

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

– Эксплуатация

– Поддержка

– Модернизация

– Утилизация

Модель жизненного цикла - форма взаимосвязи и взаимозависимости работ и этапов жизненного цикла.

 

Фундаментальные модели жизненного цикла:

• Каскадная

• Инкрементная

• Спиральная

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

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

 

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

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

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

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

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

 

 

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

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

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

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

 

 

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

 

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

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

 

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

 

В 1988 году Барри Боэмом была предложена спиральная модель ЖЦ ИС, которая частично устраняла недостатки каскадной модели ЖЦИС.

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

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

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

Спиральная модель Б. Боэма и другие версии спиральных моделей оптимально подходят для разработки крупных и дорогостоящих проектов. Спиральная модель позволяет вносить серьезные изменения в ИС на всех этапах ее ЖЦ.

 

 

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

 

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

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

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

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