Какая модель процесса разработки программного обеспечения наиболее часто используется текущими компаниями?

Question

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

• Waterfall Model 
• Spiral Model 
• Iterative and Incremental Development 
• Agile Development [I don't know much about this] 

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

Answer 1

Agile - SCRUM широко используется в наши дни.

Answer 2

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

Конечно, лучшие компании .. и те, для которых вы хотите работать, должны иметь процесс на месте. Я нахожу методологии Agile & такие практики, как Scrum, Test Driven Development, Continuous Integration и Iterative development, которые наиболее широко используются этими компаниями.

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

Answer 3

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

Это лучший способ? Точно нет. Но вы просили наиболее широко использовать его.

Answer 4

Главным образом это модель водопада.

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

Я предпочитаю TDD.

Answer 5

Возможно, не то, что вы хотите услышать, но «Agile» - это не модель процесса, а набор установок, которые могут использоваться, например, даже с водопадом. Модель процесса разработки программного обеспечения была бы похожей на eXtreme Programming или Crystal Clear.

Проблема заключается в том, что, хотя термин «Agile» был создан для определения набора атрибутов (см. Гибкий манифест), он был переопределен сообществом для ссылки на методологии. Любая методология (например, Scrum или XP) может быть реализована как гибкая или непроницаемая.

Кроме того, методологии/процессы направлены на решение различных задач. Некоторые из них обеспечивают процессы для разработчиков программного обеспечения (например, XP задает парное программирование и TDD), в то время как другие обеспечивают процессы для управления проектами (например, Scrum и XP). Поэтому сравнение сложно, а иногда и бессмысленно.

До некоторой степени все являются водопадами, это зависит от уровня фокуса.

Рекомендую прочитать Алистер Кокберн. Различные команды и разные уровни «критичности» требуют разных решений. См. Набор задач Crystal. Алистер потратил почти 20 лет на изучение успешных и не очень успешных команд по всему миру. Он нашел, например, что в небольшой команде фактический процесс менее актуален, чем атрибуты, такие как частая доставка.

Надеюсь, это поможет.

Answer 6

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

Короче говоря, что это дизайн >> Сложение >> Тест >> Deploy >> Ведение

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

Answer 7

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