Какой хороший план разработки программного обеспечения?

Ответ 1

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

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

Я обновляю это 10 апреля 2010 года. Источник DOD-STD-2167A, который я ранее перечислял, потемнел, поэтому имеет смысл указать вам на MIL-STD-498. К сожалению, MIL-STD-498 был отменен в 1998 году, и теперь DoD ожидает, что подрядчики будут использовать IEEE/EIA-12207 вместо этого. Однако стандарты IEEE не являются бесплатными, как в пиве.

См. DI-IPSC-81427A для плана плана разработки программного обеспечения.

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

См. также http://sepo.spawar.navy.mil/SW_Standards.html: вы можете загрузить .zip со стандартным и всеми описаниями элементов данных (спецификации для отдельных документов).

(Да, я знаю, что Министерство обороны отклонилось от DOD-STD-2167A в пользу коммерческих стандартов IEEE. Однако IEEE взимает с рук левую почку за руку, ногу и права на трансплантацию Стандарты DOD бесплатны, как в пиве.)

Edit: Исправлено 1-е звено

Ответ 2

"[разработка программного обеспечения] - это достаточно подробное описание всех действий, которые необходимо предпринять".

Что, вообще говоря, не может существовать.

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

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

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

Это не может быть так сложно - люди делают это все время.

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

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

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

Действительно, план часто является основной причиной отмены. Зачем? С "достаточно подробным" списком видов деятельности любое обучение означает, что план неверен. Поскольку план расходится с фактическим исполнением, что-то должно быть неправильным. Бросить монету. Если вы считаете, что выполнение неверно, отмените проект, чтобы он не выполнил план. Если вы считаете, что план неверен, исправьте план, соответствующий реальному миру. Чем более подробный план, тем больше он кажется "правильным" и тем более вероятным считается исполнение ошибочным.

Нижняя строка.

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

ИЛИ

План разработки программного обеспечения - это Agile burndown chart, который просто показывает завершение спринтов. "Разумный" уровень детализации на самом деле довольно низок - это просто сводка. И он изменяется во время каждой ретроспективы спринта.

Ответ 3

Артефакт: План разработки программного обеспечения

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

План разработки программного обеспечения содержит

• План разрешения проблем
• План принятия продукта
• План измерения
• План управления рисками
• План обеспечения качества

Рекомендации: план разработки программного обеспечения

Ответ 4

План разработки программного обеспечения - это конкретный тип плана проекта. Хотя WBS важен, он только царапает поверхность.

Комплексный план проекта должен иметь:

• План области (содержит WBS)
• План расписания
• План затрат
• План качества
• План кадрового обеспечения
• План связи
• План рисков
• План закупок.

Более подробную информацию о каждом из этих планов можно найти в

Модуль знаний по управлению проектами.

Более подробные указания приведены в Code Complete 2.

Ответ 5

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

• Управление программным обеспечением
• Разработка программного обеспечения

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

В проекте Developement проект жизненного цикла будет поддерживаться как полный водопад