Проектування програмного забезпечення

спільне проектування

Описуючи користь, замовник часто не розуміє тонкощів реалізації і тому не може пропонувати шляхи вирішення завдання. Максимально ефективний двоступеневий процес, на першій стадії якого замовник перераховує вимоги до того, як софт повинен виглядати; інженер же додає алгоритмічні опису. Так враховуються думки обох зацікавлених сторін. Втім, архітектори компанії EDISON в стані і самостійно спроектувати програму, керуючись відповідями на поставлені запитання.

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

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

техзавдання

ГОСТ пропонує деякі стадії проектування і одержувані на виході артефакти. Обсяг документа майже завжди свідчить про детальності опису завдання. Не варто писати текст маленької завдання в 1 людино-день на 20 сторінках в доскональному відповідно до ГОСТ. На великому проекті недостатньо опису на 1-2 сторінках «великими мазками».

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

Схожі статті