Общий процесс разработки программного обеспечения/обслуживания (например, эволюционирует ПО от версии 1.0 до версии 2.0)

Question

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

Итак, я задаюсь вопросом о РЕАЛЬНОМ процессе, который произошел во время разработки программного обеспечения.

Например, предположим, что успешный SW версии 1.3, и менеджеры решили разработать версию 2.0 с некоторыми новыми удивительными функциями. Затем, каков общий процесс, как правило, команда разработчиков? Как правило, требования-> архитектура-> подробный дизайн-> код? Или начать копирование кода версии 1.3 и найти повторно используемые части? Интересно, как компания разрабатывает следующую крупную версию своего успешного ПО.

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

Answer 1

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

1. Новый набор требования определяются - либо происходящее из запросов клиента или из-за другие внешние факторы (например, например, новая версию ОС, новые юридические требования или тому подобное ...). Они описаны в документе спецификации, который является единственным документом, который большинство программных проектов когда-либо видели - если вообще. И даже это довольно часто представляет собой бумажные отходы - слишком часто их реализация на практике распространяется на незарегистрированную ad-hoc основу.
2. Эти функции затем собираются с течением времени в новой ветке в исходном репозитории проекта. (Вы можете назвать этот новый филиал копией оригинального кода, если вы этого абсолютно не хотите. Но это не обычное явление, обычно это просто называется новая ветка.) Часто используется ветви на функцию, где каждый новая функция реализована в новом филиале, который затем будет объединен либо непосредственно в основную ветвь продукта, либо в основную ветвь новой версии. Первый «подход» (на самом деле, это скорее хаотический способ быстрого доступа к функциям из двери), что приводит к появлению новых функций на постоянной основе, часто используется для веб-сайтов и внутреннего программного обеспечения компании - оба легко обновить.
3. архитектура часть также в основном выполняется на разовой основе, после того как первая версия программного обеспечения отправлена, и большая часть кодовой базы уже существует. Как разработчик (особенно когда вы новичок в проекте), вы пытаетесь прикоснуться к исходной кодовой базе как можно меньше (чтобы избежать побочных эффектов) при реализации новой функции. Конечно, у вас есть план того, что делать, но у вас наверняка нет времени для создания документов «детального дизайна». -А почему ты? В любом случае их никто не интересует, также документы такого типа, как правило, устаревают через десять секунд после начала кодирования. Поэтому они обычно считаются бесполезной тратой времени. На практике код (и, возможно, сопутствующий набор тестов) является проектным документом.
4. Обычно в проекте есть определенный срок. На этом этапе ответственные лица рассматривают обзор недавно реализованных и одобренных функций, а затем определяют, какой номер версии может быть предоставлен новой версии. - Многие проекты, которые работают больше на постоянной основе, не имеют номеров версий вообще. Для этой цели они используют дату (а иногда и время!) RTM.

Некоторые больше очков:

• Там могут быть компании, где этот процесс более структурирован, и даже работает! Но это обычно сочетается с большим количеством администрирования, много документов и многих встреч - большинство компаний просто не могут себе этого позволить. По моему опыту, во многих небольших компаниях есть большая часть хаоса, которые значительно превосходят большие «профессиональные» в «реальной жизни».
• Большинство программ используется внутри компании. внутренние CRM, программное обеспечение для управления запасами или программное обеспечение для рулевого управления машиной. Когда это не требуется для внутренних целей компании, чаще всего программное обеспечение является частью более крупного продукта - например, программ рулевого управления двигателем в автомобиле или пользовательского интерфейса для какого-либо оборудования. Очень небольшая часть программного обеспечения на этой планете действительно предназначена для продажи в качестве автономного продукта. Я бы предположил, что процент составляет менее 5%.
• Большие перезаписи/рефакторинг уже существующего программного обеспечения происходят крайне редко. - Большинство разработчиков даже не увидит этого в своей профессиональной жизни.
• Около 75% своей жизни разработчик программного обеспечения вообще не работает над новыми проектами, но занимается некоторыми видами работ по техническому обслуживанию!
• Особенно подробно дизайн редко бывает на практике. Многие разработчики считают бессмысленными тратами, и в мире программирования есть мощное, очень популярное и хорошо известное движение (Agile software development), которое поддерживает это мнение.