Загальні відомості про засіб інформатизації

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

Відомості про робочий процес (бізнес-процеси) та пов’язані з ними об’єкти інформатизації, умови їх експлуатації та характеристики

Посилання

Вимоги до засобу інформатизації

Посилання

Склад та зміст робіт із створення (модернізації, модифікації, розвитку) засобу інформатизації.

Опис функціональних вимог. Надається в кожному ТЗ окремо і містить детальний опис, який відповідає на питання "що ми робимо в цій розробці"

Порядок контролю та приймання робіт із створення (модернізації, модифікації, розвитку) засобу інформатизації.

Основні етапи порядку контролю та приймання:

  1. Планування робіт – Визначення тестових сценаріїв

  2. Документальне оформлення – написання тест-кейсів

  3. Контроль якості – Перевірка, що реалізація відповідає вимогам

  4. Демонстрація функціональності – проводиться демо за необхідності

  5. Фінальне затвердження – звітування щодо статусу тестування та прийняття рішення про введення в експлуатацію.

Тестові сценарії та тест-кейси описуються окремо до кожної розробки.

Вимоги до документування

Загальні вимоги

  • Всі документи мають бути структурованими та актуальними

  • Використання уніфікованого формату для всіх документів одного типу

  • Використання Confluence, Google Docs для створення документації

  • Оновлення документації разом зі змінами в коді або логіці системи.

  • Наявність версійності (збереження історії змін документів).

Види документації

Технічні вимоги - загальні бізнес-вимоги

Технічне завдання - детальна технічна специфікація (функціональні та нефункціональні вимоги)

Техно-робочий проект - схема архітектури (залежності, компоненти, API).

Документація коду

  • Коментарі у коді відповідно до стандартів (PEP-257 для Python)

  • README.md у кожному модулі (опис, як розгорнути, залежності).

  • Документація для розробників (Developer Guide).

Документація тестування

  • Тестові сценарії

  • Тест-кейси

Документація користувача

  • Інструкції (User Guide) – як користуватися системою (для внутрішніх клієнтів або майданчиків).

Контроль якості документації

  • Аудит документації з певною періодичністю

  • Відповідальність за оновлення (наприклад, аналітик оновлює технічні вимоги разом із аналізом змін по CR).

Джерела розробки


Порядок внесення змін і доповнень до технічного завдання

Загальні положення

  • Будь-які зміни та доповнення до ТЗ мають бути зафіксовані.

  • Зміни можуть ініціюватися продуктом, розробником або іншими зацікавленими сторонами.

  • Всі зміни мають бути оцінені з точки зору впливу на строки, бюджет і технічну реалізацію.

Ініціація змін

  1. Ініціатор змін формує запит на зміну (Change Request)

  2. Запит оформлюється у вигляді таски в системі управління проєктами Jira

Аналіз та оцінка змін

  1. Аналітик з командою розробки аналізують запит і готують висновок:

    • Оцінка трудовитрат

    • Вплив на інші частини системи

    • Потенційні ризики

  2. Оцінка передається на схвалення замовником або керівництвом проєкту.

Внесення змін до документації

  1. Після затвердження зміни вносяться в ТЗ та інші пов’язані документи

  2. Всі зацікавлені сторони отримують оновлену версію документа

Контроль виконання

  • Після внесення змін проводиться тестування

  • Якщо зміни не пройшли перевірку – проводиться повторне коригування або відкат до попередньої версії.

Висновки

Можуть бути вказані з ТЗ по розробці конкретного продукту.

  • No labels