Текущие тренды развития методологий разработки КИС

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

3.2. Спиральная модель ЖЦ
Рассмотрев водопадную модель жизненного цикла программного продукта, мы упомянули, что практически разработка большого числа приложений имеет циклический характер. Цикличность заключается в возврате к предыдущей стадии после выполнения некоторых последующих стадий. Выделим наиболее важные причины таких возвратов:
Ошибки разработчиков, допущенные на стадиях проектирования и кодирования. Подобные ошибки обычно выявляются на стадии тестирования, однако могут быть обнаружены и позднее в период эксплуатации.
Реформация требований заказчика, связанная с неточностью формулировок относительно конечного результата разработки. Сюда же относятся изменения в техническом задании, вызванные текущей ситуацией в процессе разработки.
Циклический характер разработки ПО нашел отражение в спиральной модели ЖЦ. Данная модель конкурирует с водопадной моделью, учитывая характер разработки, при котором происходят возвраты. Принципиальными отличиями спиральной модели от водопадной являются следующие [8]:
Разработка нескольких образцов программного продукта. При этом имеется возможность жонглировать вервиями, возвращаясь к более ранним вариантам.
Создание прототипов программного обеспечения для обеспечения взаимодействия с клиентом в процессе уточнения требований на раннем этапе разработки.
Планирование нескольких прототипов и разработка нескольких альтернативных решений. Сюда же относят анализ возможных рисков перехода.
Начало разработки следующего прототипа до завершения предыдущего, если риски, связанные с неудовлетворенностью очередным вариантом становятся слишком высокими.
В процессе разработки очередного прототипа используется каскадная модель.
Заказчик активным образом участвует в процессе разработки, в частности, при изменении требований, связанных с переходом к следующему прототипу и оценке рисков.
На рисунке 7 приведена принципиальная схема процесса разработки при использовании спиральной модели.

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

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

Заключение
Исследования процессов разработки корпоративных информационных систем показывает, что подавляющее большинство проектов не соответствуют заявленным требованиям качества, срокам и заложенной смете. Около 40% проектов завершаются, не будучи доведенными до конца. Причина подобных провалов кроется, как правило, в несовершенствах методов управления проектом.
Методология разработки корпоративных информационных систем находится на стадии своего становления как отдельной области исследований, о чем свидетельствует появление отдельной дисциплины, под названием программная инженерия. Существующие попытки стандартизировать подходы к разработке программных систем объединены в несколько успешных стандартов и регламентов, определяющих прядок работ на всех этапах ЖЦ. Данные стандарты различаются между собой по области применимости. Каждый подход имеет право на существование и содержит множество примеров, когда проект завершился успешно или неуспешно.
Выбор конкретной методологии в каждом случае исходит из адаптации ее к данному конкретному проекту. Стандарты позволяют представить перечень работ, проводимых на всех этапах жизненного цикла. Общим недостатком существующих стандартов является то, что изложение методов приводится на концептуальном уровне без детализации и привязки к конкретным средствам разработки. Возможность адаптации некоторой методологии подразумевает составление на ее основе полного перечня процессов и работ, необходимых для реализации конкретного проекта.
Ключевыми факторами, влияющими на выбор конкретной методологии, являются: масштаб и критичность проекта. Масштаб проекта позволяет судить о его сложности. В настоящее понятие «сложность проекта» является скорее эмпирическим, чем строго определенным. Другим фактором, влияющим на выбор методологии, служит возможность использования при разработке программного продукта готовых модулей.
Современная корпоративная информационная система разрабатывается людьми разных профессий. Каждый участник процесса вносит свой вклад в общее дело. Каждый работник имеет свой опыт, свое понимание процессов и свои методы решения задач. Качественное программное обеспечение появляется тогда, когда это менеджеру проекта удается наилучшим образом соединить в команде самые развитые качества работников и направить их на цели, заложенные в проекте. Умение руководителя организовать работу персонала и скоординировать труд всех участников процесса позволяет добиться высокого качества выпускаемого программного продукта, удовлетворяющие всем требованиям заказчика.
В реферате были рассмотрены современные методологии, применяемые в процессе разработки программного продукта. Основу всех методологий составляют модели жизненного цикла разработки. На базе данных моделей были рассмотрены корпоративные методологии (MSF, RUP), применяемые в больших и сложных проектах. В дополнении к ним были рассмотрены методологии гибкой разработки (Agile), ориентированные на команды с небольшим числом исполнителей и малым сроком исполнения работ.

Список литературы
Липаев В.В. Программная инженерия. Методологические основы. – М: ТЕИС, 2014.
Орлов С.А. Технологии разработки программного обеспечения. – СПб.: Питер, 2014.
Котляров В.П. Основы тестирования программного обеспечения. – М.: БИНОМ. Лаборатория знаний, 2016.
Шафер Д, Фатрел Р, Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. – М.: Вильямс, 2017.
Новикова Г.М. Основы разработки корпоративных инфокоммуникационных систем. – М.: РУДН, 2017.
Стеллман Э. Постигая Agile. – М.: Манн, Иванов и Фербер (МИФ), 2017.
Сазерленд Дж. Scrum. Революционный метод управления проектами. – М.: Манн, Иванов и Фербер (МИФ), 2016.
Пихлер Р. Управление продуктом в Scrum. Agile-методы для вашего бизнеса. – М.: МИФ, 2017.
Андерсон Д. Канбан. Альтернативный путь в Agile. – М.: МИФ, 2017.
Богданов В. Управление проектами. Корпоративная система – шаг за шагом. – М.: МИФ, 2014.











2