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

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

Для цього проекту я вирішив працювати зі стандартними документами IEEE: Документом щодо вимог до програмного забезпечення (SRS), Документами архітектури програмного забезпечення (САД) та Документом по розробці програмного забезпечення (SDD). Хоча в школі навчали інакше, для цього проекту я вирішив створити СДД після розробки (замість цього раніше). Мої міркування:

Компанія, в якій я проходжу стажування, дала мені інструкцію створити складний фрагмент програмного забезпечення, що відповідає певним наборам вимог, експериментальним чином. Через кількість свободи, яку вони мені дали у проекті, майже нічого заздалегідь не визначено, і найкраще їх можна зустріти під час експерименту в процесі розробки. Крім того, я створюю програмне забезпечення в індивідуальному порядку , не було б користі для когось іншого в компанії, щоб я заздалегідь робив цю Дизайн програмного забезпечення. Робити це заздалегідь, це просто коштуватиме мені багато часу, щоб згодом її змінити, оскільки я можу бути впевнений, що з огляду на невизначеності в проекті, дизайн, який я буду заздалегідь , доведеться значно змінити . Для мене це контрпродуктивно.

Це хороше виправдання для створення СДД після розробки? Якщо ні, чи було б для цього хорошого обґрунтування?

Редагувати: Причиною створювати СДД згодом було б, щоб майбутні розробники продовжували працювати над проектом. Я не зможу закінчити весь проект у моєму випускному періоді, тому іншим розробникам доведеться продовжувати діючу кодову базу.

У IEEE Std 1016 Розділ 3.1 Дизайн програмного забезпечення в контексті ви можете знайти цей параграф:

SDD може бути підготовлений та використаний у різних дизайнерських ситуаціях. Зазвичай SDD готується для підтримки розробки програмного продукту для вирішення проблеми, де ця проблема виражається в рамках набору вимог. Вміст SDD може бути простежено до цих вимог. В інших випадках SDD готовий зрозуміти існуючу систему, що не має проектної документації. У таких випадках СДД готується таким чином, що інформація, яка представляє інтерес, збирається, організовується, подається та поширюється всіма зацікавленими сторонами. Ця цікава інформація може бути використана для планування, аналізу, впровадження та розвитку програмної системи шляхом виявлення та вирішення суттєвих проблем дизайну.

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

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

Цей стандарт не передбачає конкретних методологій для проектування, управління конфігурацією чи забезпечення якості.

У контексті цих питань ключовими словами є "управління конфігурацією". Управління конфігурацією стосується не лише створеної програмної системи, але й будь-якої пов'язаної з нею документації.

У вашій особистій ситуації, а також у багатьох ситуаціях, створення СДД на передньому плані - марно. Відповідь Девіда Арно близька до того, що я вважаю правильною. Справжній дизайн вашої програмної системи - код. Однак ви "створюєте SDD раніше" або "створюєте SDD після" - не ваші єдині варіанти. У вас є третій варіант - розвивати SDD за допомогою програмної системи.

Якщо ви дотримуєтесь такого стандарту, як IEEE Std 1016, у вас є вимоги до SDD. Зокрема, розділ 4 цього стандарту визначає вміст, який ви маєте. Під час роботи над дизайнерськими рішеннями починайте створювати різні точки зору, погляди та накладки. Коли ви приймаєте рішення, дотримуйтесь обґрунтування дизайну для них.

Це дозволить зацікавленим сторонам стежити за розвитком програмного забезпечення без необхідності копатися в коді. Звичайно, у людей можуть бути зауваження чи пропозиції. Якщо ви оновлюєте SDD, вони можуть відстежувати ваш прогрес і давати відгуки про підхід рано, який ви зможете потім включити в продукт, а також SDD. Коли ви переходите з проекту, якщо програмний код і SDD синхронізуються, хтось повинен мати можливість легко взятися за роботу і забрати роботу.

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

Однак я хотів би зазначити, що SDD може слугувати і іншим цілям. Це також може допомогти вам задуматися про дизайн та переконатися, що ви «швидко провалюєтесь». Це добре, особливо якщо багато речей заздалегідь невідомі, тому що ви можете відкинути підходи, які не працювали б протягом усієї реалізації на початку. Це також може перешкодити вам зосередитися на технічних деталях, не кодуючи нічого, поки ви не з’ясували дизайн.

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

Єдиний справжній детальний проектний документ, який ви створите, - це код. Він точно розповідає компілятору, як скласти свою програму. Таким чином, ваш дизайн не може бути завершеним до тих пір, поки не буде зроблено остаточну конструкцію перед доставкою.

Будь-які інші створені вами документи, такі як SDD, потребуватимуть оновлення після завершення проекту (коду). Тому є вагома причина писати СДД після цього: робити це потрібно лише один раз.

Очевидною протилежністю цьому є: "як часто ви насправді пишете SDD після події"? Додаток поставляється, тому ви, швидше за все, не захочете витрачати час на документування на цьому етапі. Але це в рівній мірі стосується оновлення існуючого. Що гірше, немає SDD або SDD, які не є правильними і яким не можна довіряти?

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

Для мене це не було б гарною аргументацією.

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

Існує справа, щоб зробити це в будь-якому випадку . Тому що ви робите це, щоб дізнатися про написання таких документів. Пропуск цієї роботи, оскільки тут може бути не на 100%, це означає, що ви пропускаєте навчання.

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

Якщо згодом щось зміниться, ви оновлюєте документ.

Це має ряд переваг порівняно з написанням після факту:

• Ви навчитесь постійно оновлювати проектні документи, коли змінюються вимоги, корисна звичка

• Ви навчитесь думати про дизайн перед впровадженням

• Це не так розумно нудно, як написання дизайнерських документів після цього факту

• Якщо у вас не вистачає часу, у вас буде документ про дизайн, який описує те, що у вас є, доки інші можуть продовжити вашу роботу

• Це не так багато додаткової роботи

• Оскільки ваш проект триває, ви можете бути не зовсім впевнені в тому, чому ви самі зробили щось так два місяці тому, і у вас з’являться свої нотатки.

Документ про дизайн системи, запис основних вимог плюс (нові функції) оновлюється, коли проект рухається вперед з новими атрибутами дизайну та рішення. Зберігається до моменту доставки проекту / рішення. Корисно, воно повідомляє всім зацікавленим.