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

С чего все начиналось

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

В античные времена проектирование связывали с «наукой архитектора» и связывали данную науку не только с возведением зданий, но и созданием строительных и военных машин.Римский инженер и архитектор Марк Витрувий в 1 в. до нашей эры в своем трактате «10 книг об архитектуре» дал проектированию следующее определение:
В теории — показать и обосновать исполнение в соответствии с требованиями искусства и целесообразности.
В практическом смысле — выполнение руками человека работ из любого материала по данному чертежу.

Однако, история развития проектного менеджмента как дисциплины относительно молода: ее относят к 30-м годам XX века и связывают с разработкой специальных методов координации инжиниринга крупных проектов в США — авиационных в «US Air Corporation» и нефтегазовых в фирме «Exon». В СССР в этот же период начала развиваться теория и практика поточной организации работ по реализации крупных строительных проектов.

Появление новой дисциплины

Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х — начале 70-х годов прошлого века, когда произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость ПО стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-х годов все человечество будет заниматься разработкой ПО для компьютера. Развитие микроэлектроники привело к резкому увеличению производительности ЭВМ при значительном снижении стоимости. Начали уходить ограничения для аппаратных средств, оставшиеся ограничения приходятся на долю ПО. Это приводило к тому, что умение строить новые программы отставало от требований к новым программам.
Другая тенденция развития зародилась внутри самой отрасли и была основана на усилении взгляда на разработку программ, как на более чем простое «кодирование». Вместо этого программное обеспечение рассматривается как имеющее полный жизненный цикл, начинающийся с появления концепции и проходящий стадии проектирования, разработки, ввода в действие, сопровождения и развития. Смещение фокуса внимания с кодирования породил разработку методологий и развитого инструментария, вооруживших команды инженеров, занятых на всех этапах жизненного цикла программного обеспечения.
Тогда и заговорили о программной инженерии( технологии промышленного программирования) как о некоторой дисциплине, целью которой является сокращение стоимости программ. Такая проблема должна решаться более грамотной организацией процесса разработки. Это и привело к развитию методологий проектирования ПО и возведения его в главенствующие составляющие разработки.

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

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

Методологии в программной инженерии

С этого момента программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.). Разработка программного кода предваряется анализом и проектированием (первое означает создание функциональной модели будущей системы без учета реализации, для осознания программистами требований и ожиданий заказчика; второе означает предварительный макет, эскиз, план системы на бумаге).
Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов и будем называть программной инженерией. Получается, что так мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых, специальную область знания. Или другими словами, научную дисциплину. Ведь для облегчения выполнения каждого отдельного проекта, для возможности использовать разнообразный положительный опыт, достигнутый другими командами и разработчиками, этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так появляются различные методы и практики (best practices) – тестирования, проектирования, работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и методологии, касающиеся всего процесса в целом. Вот эти-то обобщения и входят в программную инженерию как в область знания.
Таким образом методологии в программной инженерии являются одной из самых динамично развивающихся составляющих области знаний, т.к. несут в себе практическую составляющую.
Современная классификация методологий управление проектом или моделей жизненного цикла проекта согласно SWEBOK выглядит следующим образом.
Методологии управления проектами:

• традиционная(каскадная, водопадная) модель;
• cпиральная модель;
• итеративная и инкрементная модель(эволюционный подход).

Подробнее о методологиях

Как видно из названия традиционные методологии построены на последовательном выполнении всех фаз проекта и конечный продукт будет получен только после выполнения всех этапов. Возвращение на предыдущий этап не предусмотрено и при появлении критических ошибок весь проект начинается сначала. Основным примером таких методологий разработки является каскадная модель или модель Водопад. Источником данной модели принято считать статью Уинстона Ройса вышедшею в 1970 году. Однако, сам Ройс описывал эту модель как пример противопоставленный итеративной модели, применимый только для очень простых проектов и сам пользовался итеративными методологиями. Так же Ройс писал, что в особо сложных местах проекта и при применении новых, ранее не используемых технологий, промежуточные этапы можно повторить дважды и заказчик по окончанию проекта получает вторую версию продукта. Такой подход нельзя назвать итеративным, но и однозначно последовательным тоже. На начальном периоде она сыграла ведущую роль как метод регулярной разработки сложного ПО. В 70x — 80x годах XX века модель была принята как стандарт министерства обороны США.
По мере развития методологий каскадная модель подвергалась жесткой критики со стороны всех исследователей, предлагавших свои методологии. Последовательное выполнение этапов разработки не дает изменить требования к программному продукту до самого релиза. Чем больше проект тем больше накапливается проблем в процессе проектирования. И реализация изменений в следующей версии продукта иногда становится не целесообразной. Продукт необходимо писать с 0. Таким образом стоимость работоспособной версии не оправдано сильно растет. А процент успешно завершенных проектов ничтожно мал. Однако, можно ли назвать традиционные методологии разработки отжившими свой век? Не совсем. Для проектов затрагивающих безопасность жизнедеятельности строго поставленные требования и высокая степень формализации является основополагающим и необходимым фактором.
Кроме того, несмотря, на модную сейчас критику традиционной модели, она играет важную роль, потому что налагает на процесс разработки требование крайне необходимой для него дисциплинированности, с помощью которой удается благополучно обходить неструктурированные процессы типа «пишем и правим». Данная модель внесла фундаментальный вклад в понимание процессов разработки ПО следующими утверждениями:

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

Спиральная модель ЖЦ стала следующим (после водопадной) этапом развития методологий разработки, поскольку она решает основную проблему каскадной модели. Каждая фаза водопадного процесса разработки в спиральной методологии завершается этапом прототипирования и управления рисками. Этап прототипирования после каждой фазы проекта позволяет определить, насколько текущее состояние проекта соответствует первоначальному плану. По итогам прототипирования выполняется либо переход к следующей фазе, либо возвращение на одну из предыдущих фаз. Однако фазы и последовательность фаз остаются линейными. Автором данной модели является Барри Боэм, опубликовавший в 1988 году статью «A Spiral Model of Software Development and Enhancement». Не смотря на то, что в SWEBOK данная модель выделена отдельно от итеративной, при описании моделей напрашивается вывод об отнесении спиральной методологии к семейству итеративных. Это обуславливается и возможностью изменения требований между этапами и выпуска прототипов продукта после каждого цикла. Возможно такое разделение связано с авторской принадлежностью методологий.

Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Упоминания о данной методологии начали появляться задолго до статьи У. Ройса и появления самой программной инженерии. Истоки концепции итеративной разработки прослеживаются в относящихся к 30-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из Bell Labs. Важной вехой в истории является осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15. По мнению участников этих работ, применение данной методологии в значительной степени определило успех проекта.
Наиболее обсуждаемые сейчас гибкие методологии разработки (Agile методологии) относятся именно к итеративным моделям ЖЦ. При описании любой из гибких методологий упоминается принцип разделения на итерации. Однако, особенность данных методологий это упор на человеческий фактор, а не на документацию проекта, что никак не обозначается в описании итеративной и инкрементной методологии.

Гибкие методологии разработки начали появляться на фоне быстрорастущего усложнения технологий и всеобщей информатизации. Теперь заказчиком в большинстве случаев является лицо далекое от информационных технологий. Для такого заказчика главным является готовый продукт, а не фолианты документации. При экспоненциально растущем темпе развития информационных технологий сроки на разработку ПО сократились и стали жестче. Теперь нет времени на долгое планирование, написание документации и полновесное тестирование. Программный продукт может устареть еще до релиза. В противовес традиционным методологиям разработки итеративные методологии делят выполнение проекта на короткие итерации, ограниченные по времени. После каждой итерации заказчику продукта предоставляется результат. Предусмотрен откат на предыдущие итерации. Появление гибких методологий не привязано к конкретной дате, так как начиная с середины 90х годов начали появляться и внедряться практически параллельно. Это были методологии разработки такие как: Scrum (1995), экстремальное программирование (1996), Crystal Clear, Lean, Kanban и другие. Созданный в феврале 2001 года, Agile-манифест, провозгласил философию гибких методологий разработки и задал вектор развития данных методологий.

Современный этап развития методологий

Сейчас выбор методологии проектирования как никогда подвержен влиянию маркетинга. Все больше появляется консультантов по внедрению agile, коучеров, проводящих бесконечные тренинги, семинары, вэбинары, бесконечные встречи, конференции, круглые столы. Все эти мероприятия направлены на продажу внедрения в ИТ-компаниях за большие деньги приглашенными специалистами или повышения рейтинга компаний, которые уже внедрили гибкие методологии.
Гибкие методологии сейчас — это в большей степени свод знаний по организации работы людей с психологической точки зрения. Такие методологии помогают команде проявлять творческую составляющую, умение работать в команде, навыки коммуникации и прочее. Техническая сторона организации работ все больше уходит на второй план. Только ХР(Экстремальное программирование) имеет в своем арсенале такие инженерные практики как разработка через тестирование, метафоры и рефакторинг. Эти практики с успехом применяются в сочетании с другими методологиями. При некачественном внедрении Agile мы получаем то, что сейчас происходит на рынке IT продуктов. Рынок перенасыщен некачественными, нестабильными продуктами, не отвечающими требованиям не к функционалу, ни к интерфейсу. При этом, что скорость выпуска таких продуктов, благодаря пропагандируемому Agile принципу непрерывной интеграции, постоянно растет.

с набирающим обороты снижением качества выпускаемых IT продуктов стали появляться методологии, стремящиеся это качество повысить. Такой методологией стал DEvOps.
Термин «devops» был популяризирован на конференции «Дни DevOps» («DevOps Days») в 2009 году в Бельгии. С тех пор такая методология все больше набирает популярность.Это отчасти связано с тем, что принципы DevOPs пропагандируют не отказ от действующей в организации методологии, а сочетание с ней. Общая концепция DevOps заключается в усилении кооперации между группами разработки(DEVelopments) и эксплуатации(OPerations) в рамках одной организации, несущими ответственность за разработку ПО. Данная методология это без преувеличения новый виток эволюции методологий разработки поскольку ориентирована не только на удовлетворение требований заказчика в жестко определенные сроки, но и повышение качества и стабильности продукта.

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

Источники

Управление проектами разработки ПО. Дисциплина «Гибкие технологии разработки программного обеспечения» автор: Д.Г. Шопырин
devopswiki.net/index.php/DevOps
ivanpesin.info/blog/2012/02/building-a-devops-team/Перевод статьи Брайна Генри. Создание DevOps команды.
«Гибкие методологии разработки. версия 1.2» автор: Вольфсон Борис
www.ibm.com/developerworks/ru/library/a-devops1 перевод статьи Пола Дюваля. «Agile DevOps ― гибкая разработка и эксплуатация ПО: Выравнивание процесса выпуска программного обеспечения»
www.sibinfo.ru/archive/news/03_10_14/iid_history.html Итеративная и инкрементная разработка: Краткая история. Автор: Крейг Ларман
swebok.sorlik.ru/software_engineering.html SWEBOK. Перевод Сергея Орлика при участии Юрия Булуя.
www.cossa.ru/articles/234/33622 статистика успешных ИТ проектов.
ndo.sibsutis.ru/magistr/courses_work/tspo_work/lectures_index.htm конспекты лекций: Технология создания программного обеспечения
«Проектирование информационных систем» Автор: Сапожкова Т.Е.
«Управление проектами: Учебное пособие» Автор: Дульзон A.A.
devopshub.net/top-3-mifa-o-devops-chem-vse-taki-devops-ne-yavlyaetsya Три мифа о DevOps
«Введение в программную инженерию.» Автор: С.Н. Карпенко
«Scrum и XP: заметки с передовой.» Автор: Хенрик Книберг
«Технологии разработки программного обеспечения: Учебник.» Автор: С. Орлов.
habrahabr.ru/company/scrumtrek/blog/166039 DevOPs
Википедия. Куда без нее.