У чому різниця між технічними характеристиками та проектними документами?

Що таке технічні характеристики? Чи вони такі самі, як проектні документи. Якщо ні, то в чому різниця та деякі приклади?

documentation specifications

— Іван V
джерело

Перший не вистачає дизайну, а останній втрачає технічні характеристики.

Відповіді:

Документ про розробку програмного забезпечення може бути на рівні системи або компонента і, як правило, включає:

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

Зауважте, що всі ці описи на абстрактному рівні. Мета - дати читачеві широке загальне розуміння системи чи компонента. Можливо, існує багато рівнів проектних документів (наприклад, на рівні системи чи компонентів).

Технічна специфікація описує хвилинну деталь або все , або конкретні частини конструкції, такі , як:

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

— miraculixx
джерело

Тож коли ми насправді повинні писати технічні умови. До розвитку? Разом з розвитком? чи Після ..?

— shashwat

@ShashwatTripathi, як правило, технічні характеристики написані перед розробкою, щоб хтось інший (або ви пізніше) міг реалізувати компоненти. Написання специфікації після розробки, робить її безглуздою (якщо ви не використовуєте її як технічну документацію щодо того, що було реалізовано).

— miraculixx

Я натрапив на цей точний сценарій, працюючи над величезним корпусом над багаторічним проектом. Ми працювали назад у створенні документа про вимоги бізнесу після того, як проект було перенесено на Тест, а потім на Прод! Ага, чудовий менеджмент проектів, я знаю!

— ThinkCode

Чи не створюються технічні характеристики після того, як деталі функціонально розклали специфікацію вимог до програмного забезпечення? Як архітектор може створити TS без SRS? Схоже, йому / їй потрібно буде взяти тонну.

— Oracular Людина

Погодьтеся, TS повинен дотримуватися SRS (специфікація системних вимог). Зверніть увагу, але такі терміни не стандартизовані, і TS може бути створений як деталізована форма SRS (типова для вбудованих систем), або вона може бути використана для доповнення SRS високого рівня, тобто проектного документа (типового для комерційних програм ). Ключовим моментом є те, що вимоги, документи на розробку та специфікації описують один конкретний погляд на систему та її компоненти. Важливіше, щоб команда погоджувала потрібні погляди та рівень деталізації, ніж дотримуватись певного формального визначення.

— miraculixx

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

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

— тдаммери
джерело

Дякую. Також в основному мені потрібна функціональна специфікація, щоб знати, що робити, а потім розробляти документи, щоб знати, як це зробити, чи правильно це? Лише невелике запитання, що таке функціональний дизайн, на який ви згадали (сподіваюся, що він не буде додавати плутанини моєму розумінню функціональних специфікацій)

— Іван V

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

— tdammers

Тож коли ми насправді повинні писати технічні умови. До розвитку? Разом з розвитком? чи Після ..?

— shashwat