Что является сложной частью разработки программного обеспечения?

Question

Какая сложная часть разработки программного обеспечения оказывает существенное влияние на конечный продукт / выпуск? и как?

Что я ожидаю, так это то, в каких областях [например, технологии, требования ... и т. Д.) Я должен сконцентрироваться «больше» для разработки лучших приложений.

Answer 1

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

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

Answer 2

Самая сложная часть связана с людьми. Боже, я ненавижу их!

Answer 3

Я буду бесстыдно попугать линию Стива Макконнелла из Code Complete , главная трудность разработки программного обеспечения: Управление сложностью .

Управление функциями доставки по сравнению с расписанием и качеством кода.

Управление созданием правильных функций по сравнению с получением функций.

Управление требованиями, общение с клиентами в достаточной степени, чтобы обрести уверенность в том, что то, что вы строите, на самом деле то, что хочет клиент.

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

Управление командой и индивидуальная динамика.

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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