Можно ли обосновать создание Документа по разработке программного обеспечения после разработки?

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

Для этого проекта я выбрал работу со стандартными документами IEEE: Документ о требованиях к программному обеспечению (SRS), Документы об архитектуре программного обеспечения (SAD) и Документ о разработке программного обеспечения (SDD). Хотя в школе этому учили иначе, я решил создать SDD после разработки (а не до). Я рассуждаю так:

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

Это хорошее обоснование для создания SDD после разработки? Если нет, было бы какое-нибудь хорошее оправдание для этого?

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

В IEEE Std 1016 Раздел 3.1 Проектирование программного обеспечения в контексте вы можете найти этот параграф:

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

Авторы IEEE Std 1016 признают, что SDD не может быть создан заранее. Один может быть создан после того, как система программного обеспечения существует для сбора информации для заинтересованных сторон.

Раздел 1.1 Область также предоставляет некоторую интересную информацию:

Этот стандарт не предписывает конкретные методологии для проектирования, управления конфигурацией или обеспечения качества.

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

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

Если вы следуете стандарту, такому как IEEE Std 1016, у вас есть требования для SDD. В частности, раздел 4 этого стандарта определяет содержание, которое вы имеете. По мере работы с проектными решениями начинайте создавать различные точки обзора, представления и наложения. Принимая решения, запишите обоснование дизайна для них.

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

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

Тем не менее, я хотел бы отметить, что SDD может служить и другой цели. Это также поможет вам рассуждать о дизайне и убедиться, что вы «быстро провалились». Это хорошо, особенно если многое заранее неясно, потому что вы можете отбросить подходы, которые не сработали бы в начале всей реализации. Это также может помешать вам сосредоточиться на технических деталях в ближайшее время, не кодируя что-либо, пока вы не выясните дизайн.

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

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

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

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

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

Для меня это не будет хорошей аргументацией.

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

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

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

Если что-то изменится позже, вы обновите документ.

Это имеет несколько преимуществ по сравнению с написанием после факта:

• Вы научитесь обновлять проектную документацию при изменении требований - полезная привычка

• Вы научитесь думать о дизайне до реализации

• Это не так скучно, как написание проектных документов после того, как факт

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

• Это не так много дополнительной работы

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

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