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

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

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

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

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

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

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

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

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика» .

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

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

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

Процесс разработки заказного ПО

Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

Рисунок 1. Процесс разработки заказного программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

Процесс разработки инвестиционного ПО

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

Рисунок 2. Процесс разработки инвестиционного программного обеспечения.

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

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

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

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

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

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

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

Особое внимание нужно уделить стендам, на которых проводится тестирование: на них должны быть развёрнуты все версии продукта, которые были выпущены ранее (по меньшей мере, те версии, которые сопровождаются), и все версии, разработка которых ведётся в настоящий момент.

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

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

Процесс разработки встроенного ПО

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

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

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

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

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

Рисунок 3. Процесс разработки встроенного программного обеспечения.

Процесс разработки игр

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

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

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

Рисунок 4. Процесс разработки игрового программного обеспечения.

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

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

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

Заключение

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

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

Этапы разработки программного обеспечения

Процесс разработки программного обеспечения можно разбить на этапы (фазы):

– разработка модели и выбор метода решения;

– разработка алгоритма решения задачи;

– кодирование алгоритма;

– компиляция программы;

– тестирование программы;

– создание документации;

– сопровождение и эксплуатация.

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

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

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

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

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

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

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

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

Разработка модели и выбор метода решения . На этом этапе создается математическая или логиче­ская модель исследуемого явления реального мира. При этом нужно уметь сформулировать на языке математики конкретные задачи физики, экономики, технологии и т.д. После того как определена математическая модель задачи, надо выбрать метод ее решения. Если программируемая задача носит вычислительный характер, то приводится вывод всех используемых формул с подробными комментариями. Если же задача невычислительная, то приводится словесное описание логической модели, например, в виде плана действий.

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

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

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

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

Компиляция программы. После того как закончено кодирование (написание программы на языке программирования) и исходный текст программы введен в память компьютера, производят компилирование программы, т.е. перевод исходного текста в машинный код. Этот процесс осуществляется специальной программой – компилятором. На рисунке 1 представлена схема подготовки исполняемой программы.

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

Получившийся текст передается на вход компилятора (Compiler ) , который выделяет лексемы (отдельные слова), а затем на основе грамматики языка распознает выражения и операторы, построенные из этих лексем. При этом компилятор выявляет синтаксические ошибки и в случае их отсутствия строит объектный модуль.

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

Тестирование программы. Различается два вида тестирования: автономное и комплексное. При автономном тестированию подвергаются отдельные программные модули, из которых состоит программный комплекс. Комплексное тестирование заключается в проверке всего программного комплекса. Для тестирования подбираются такие исходные данные, для которых результат выполнения программы заранее известен.

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

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

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

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

Задание на разработку программного обеспечения (техническое зада­ние);

Спецификация;

Прокомментированные исходные тексты (листинги) модулей програм­мы и управляющего модуля;

Схема разбиения программного комплекса на программные модули;

Схема потоков данных программного комплекса;

Схема взаимодействия программных модулей;

Планы и данные для тестирования программного комплекса;

Другие материалы, иллюстрирующие проект, например: блок-схемы программного комплекса и программных модулей.

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

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

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

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

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

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

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

SCRUM - методология, предназначенная для небольших команд (до 10 человек). Весь проект делится на итерации (спринты) продолжительностью 30 дней каждый. Выбирается список функций системы, которые планируется реализовать в течение следующего спринта. Самые важные условия - неизменность выбранных функций во время выполнения одной итерации и строгое соблюдение сроков выпуска очередного релиза, даже если к его выпуску не удастся реализовать весь запланированный функционал. Руководитель разработки проводит ежедневные 20 минутные совещания, которые так и называют - scrum, результатом которых является определение функции системы, реализованных за предыдущий день, возникшие сложности и план на следующий день. Такие совещания позволяют постоянно отслеживать ход проекта, быстро выявлять возникшие проблемы и оперативно на них реагировать.

KANBAN – гибкая методология разработки программного обеспечения, ориентированная на задачи.

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

Преимущества KANBAN:

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

DYNAMIC SYSTEM DEVELOPMENT METHOD появился в результате работы консорциум из 17 английских компаний. Целая организация занимается разработкой пособий по этой методологии, организацией учебных курсов, программ аккредитации и т.п. Кроме того, ценность DSDM имеет денежный эквивалент.

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

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

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

MICROSOFT SOLUTIONS FRAMEWORK - методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.
Базовые концепции и принципы модели процессов MSF:

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

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

RATIONAL UNIFIED PROCESS - методология разработки программного обеспечения, созданная компанией Rational Software.
В основе методологии лежат 6 основных принципов:


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

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

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

Теги: методологии разработки, scrum, kanban, dsdm, msf, rup

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

Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия

- (англ. Software project management) особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по… … Википедия

- (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… … Википедия

Наиболее распространённый в настоящее время способ нумерации версий Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными от исправления ошибки до полного переписывания. В бол … Википедия

Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия

Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия

Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Книги

• , Кон Майк. В книге "Пользовательские истории: гибкая разработка программного обеспечения" Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…
• Пользовательские истории. Гибкая разработка программного обеспечения , Майк Кон. В книге`Пользовательские истории: гибкая разработка программного обеспечения` Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…

программное обеспечение управление

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

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

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

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

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

Рисунок 1- Модифицированная каскадная модель разработки программного обеспечения

Модифицированная каскадная модель предусматривала возможность возвращения к предыдущим этапам.

Спустя непродолжительное время после своего появления на свет каскадная модель была доработана Уинстом Ройсом с учетом взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания . В таком «обратимом» виде каскадная модель просуществовала долгое время и явилась основой для многих проектов (рисунок 1).

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

Для того, чтобы устранить недостатки каскадной модели была предложена V-образная, или шарнирная модель разработки программного обеспечения (рисунок 2).

Рисунок 2- V-образная модель разработки программного обеспечения

V-образная модель позволяет гораздо лучше контролировать результат на предмет его соответствия ожиданиям, поскольку сфокусирована на тестировании .

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

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

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

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

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

Предложенная Барри Боэмом в 1988 году спиральная модель стала существенным прорывом в понимании природы разработки программного обеспечения, хотя объединяет каскадный подход и итерационный процесс проектирования на основе создания прототипов (рисунок 3).

Рис. 3.

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

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

Впервые предложенная Филиппом Крачтеном в 1995 году, итеративная модель объединяет главные преимущества спиральной, инкрементной, каскадной моделей, а также методов разработки на основе создания прототипов и объектно-ориентированного подхода (рисунок 4). Она завоевала большую популярность и в том или ином виде используется во многих современных проектах .

Рисунок 4- Итеративная модель разработки программного обеспечения

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

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

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

Самым известным и авторитетным стандартом качества следует считать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 году, хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 голу. Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания программного обеспечения. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (таблица 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA) .

Таблица 1-Модель СММ

Название уровня	Ключевые области процесса
1 - Начальный	Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено
2 - Повторяющийся	Управление программными конфигурациями. Обеспечение качества программных продуктов. Управление контрактами подрядчиков. Контроль за ходом проектов. Планирование программных проектов. Управление требованиями
3 - Определенный	Экспертные оценки. Координация взаимодействий проектных групп. Инженерия программного продукта. Комплексный менеджмент ПО. Программа обучения персонала. Определение организационного процесса. Область действия организационного процесса
4 - Управляемый	Менеджмент качества ПО. Управление процессом на основе количественных методов
5 - Оптимизируемый	Управление изменением процесса. Управление технологическими изменениями. Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов, а он получил новое имя - SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI - Capability Maturity Model Integrated (CMMI) - интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления - классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA).

В таблице 2 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 2- Соответствие уровней зрелости стандартов CMM, CMMI

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

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

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

Модель зрелости процесса разработки программного обеспечения (CMM), разработанная Институтом программной инженерии в университете Carnegie Mellon, предлагает пять уровней зрелости (таблица 3). Она помогает организациям повысить зрелость своих процессов разработки программного обеспечения, и организации могут быть оценены и аккредитованы в соответствии с этими уровнями.

Таблица 3-Уровни зрелости разработки программного обеспечения

Уровень 1 - начальный уровень	Процесс разработки ПО спонтанен, и регламентированы лишь немногие процессы. Успех разработки может зависеть от отдельных сотрудников.
Уровень 2 - уровень повторяемости	Созданы основные процессы управления проектами для отслеживания затрат, календарного плана и функциональных возможностей.
Уровень 3 - уровень регламентируемости	Процесс разработки ПО документирован, стандартизирован и интегрирован со стандартным процессом разработки ПО организации как для операций управления, так и для операций разработки. Во всех проектах используется стандартизированный процесс.
Уровень 4 - уровень управляемости	Проводится сбор подробных показателей процесса разработки ПО и качества продукта, что позволяет понять процесс и продукты и управлять ими.
Уровень 5 - уровень оптимизируемости	Непрерывная оптимизация процесса обеспечивается количественной обратной связью от процесса и от пилотных инновационных идей и технологий.

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