Що описує Технічний проект (тп)? з яких етапів складається розробка технічного проекту?
Технічний проект розробляється на основі матеріалів що пройняті в ТЗ.
Розробка ТП має 4 етапи:
Розробка проектних рішень (Склад технічних засобів алгоритмів, мови, класифікація, кодування, інформаційно-організаційні заходи);
Розробка документації (Розробка, оформлення, погодження, затвердження);
Складання і оформлення документації на поставку ПЗ або виробництво;
Розробка завдань на проектування (Розробка, оформлення, погодження, затвердження на проектуванні).
Види забезпечень.
Методичне забезпечення (Певна сукупність документів, що описує технічне функціонування ПЗ(деякі інструкції));
Інформаційне забезпечення (Форми документів, що використані в програмному засобі при його функціонуванні);
Організаційне забезпечення (Сукупність документів, в яких відображена структура, права та обов’язки користувачів);
Технічне забезпечення (Сукупність всіх технічних засобів, КТЗ(Комплекс Технічних Засобів));
Математичне забезпечення (Методи, моделі, алгоритми завдяки яким працює ПЗ);
Програмне забезпечення (Сукупність програм, з якими функціонує ПЗ. Складаються з системного, прикладного і документації);
Лінгвістичне забезпечення (Описують засоби і правила для формалізації мови);
Правове забезпечення (Сукупність правових норм, які регламентують правові відношення при функціонуванні ПЗ);
Ергономічне забезпечення (Сукупність рішень психологічних, психофізичних, антропологічних, фізіологічних характеристик).
Методи доведення, верифікації і тестування програмного забезпечення.
Формальні мови специфікації та їх класифікація.
Доведення. Базові методи доведення правильності програм.
Верифікація і валідація програм. Опис та мета процесів.
Верифікація-процес що перевіряє програму на вимоги
Валідація-процес визначення відповідності розроблювального ПЗ між очікуванням і потреби користувача
Мета процесів полягає в тому, щоб перевірити і підтвердити, що кінцевий ПП відповідає призначенню і задовольняє вимогам замовника.
Поняття тестування. Мета та історична довідка.
Тестування програмного забезпечення (англ. Software Testing) — це процес технічного дослідження, призначений для виявлення інформації про якість продукту відносно контексту, в якому він має використовуватись. Техніка тестування також включає як процес пошуку помилок або інших дефектів, так і випробування програмних складових з метою оцінки. Може оцінюватись:
відповідність вимогам, якими керувалися проектувальники та розробники
правильна відповідь для усіх можливих вхідних даних
виконання функцій за прийнятний час
практичність
сумісність з програмним забезпеченням та операційними системами
відповідність задачам замовника.
Оскільки число можливих тестів навіть для нескладних програмних компонент практично нескінченне, тому стратегія тестування полягає в тому, щоб провести всі можливі тести з урахуванням наявного часу та ресурсів. Як результат програмне забезпечення (ПЗ) тестується стандартним виконанням програми з метою виявлення баґів (помилок або інших дефектів).
Тестування ПЗ може надавати об'єктивну, незалежну інформацію про якість ПЗ, ризики відмови, як для користувачів так і для замовників.[1]
Тестування може проводитись, як тільки створено виконуваний код (навіть частково завершено). Процес розробки зазвичай передбачає коли та як буде відбуватися тестування. Наприклад, при поетапному процесі, більшість тестів відбувається після визначення системних вимог і тоді вони реалізуються в тестових програмах. На противагу цьому, відповідно до вимог гнучкої розробки ПЗ, програмування і тестування часто відбувається одночасно.
Історія
Перші програмні системи розроблялися в рамках програм наукових досліджень або програм для потреб міністерств оборони. Тестування таких продуктів проводилося строго формалізовано із записом всіх тестових процедур, тестових даних, отриманих результатів. Тестування виділялося в окремий процес, який починався після завершення кодування, але при цьому, як правило, виконувалося тим же персоналом.
У 1960-х багато уваги приділялося «вичерпному» тестуванню, яке повинно проводитися з використанням усіх шляхів у коді або всіх можливих вхідних даних. Було відзначено, що в цих умовах повне тестування ПЗ неможливе, тому що, по-перше, кількість можливих вхідних даних дуже велика, по-друге, існує безліч шляхів, по-третє, складно знайти проблеми в архітектурі та специфікаціях. З цих причин «вичерпне» тестування було відхилено й визнано теоретично неможливим.
На початку 1970-х тестування ПЗ розглядалося як «процес, спрямований на демонстрацію коректності продукту» або як «діяльність з підтвердження правильності роботи ПЗ». У програмній інженерії, яка в той час зароджувалася, верифікація ПЗ визначалася як «доказ правильності». Хоча концепція була теоретично перспективною, на практиці вона вимагала багато часу й не охоплювала всі аспекти тестування. Було вирішено, що доказ правильності — неефективний метод тестування ПЗ. Однак, у деяких випадках демонстрація правильної роботи використовується і в наші дні, наприклад, приймально-здавальні випробування. У другій половині 1970-х тестування представлялося як виконання програми з наміром знайти помилки, а не довести, що вона працює. Успішний тест — це тест, який виявляє раніше невідомі проблеми. Даний підхід цілком протилежний попередньому. Зазначені два визначення являють собою «парадокс тестування», в основі якого лежать два протилежних твердження: з одного боку, тестування дозволяє переконатися, що продукт працює добре, а з іншого — виявляє помилки у ПЗ, показуючи, що продукт не працює. Друга мета тестування є більш продуктивною з точки зору поліпшення якості, оскільки не дозволяє ігнорувати недоліки ПЗ.
У 1980-х тестування розширилося таким поняттям як запобіганням дефектам. Проектування тестів — найбільш ефективний з відомих методів запобігання помилок. В цей же час почали висловлюватися думки, що необхідна методологія тестування, зокрема, що тестування повинно включати перевірки впродовж усього циклу розроблення, при цьому це має бути керований процес. В ході тестування треба перевірити не тільки зібрану програму, але й вимоги, код, архітектуру, самі тести. «Традиційне» тестування, яке існувало до початку 1980-х, відносилося тільки до скомпілювати, готової системі (зараз це зазвичай називається системне тестування), але надалі тестувальники стали залучатися в усі аспекти життєвого циклу розроблення. Це дозволяло раніше знаходити проблеми у вимогах та архітектурі й тим самим скорочувати терміни та бюджет розроблення. У середині 1980-х з'явилися перші інструменти для автоматизованого тестування. Передбачалося, що комп'ютер зможе виконати більше тестів, ніж людина, причому зробить це більш надійно. Спочатку ці інструменти були вкрай простими й не мали можливості написання сценаріїв на скриптових мовах.
На початку 1990-х у поняття «тестування» стали включати планування, проектування, створення, підтримку й виконання тестів та тестових оточень, а це означало перехід від тестування до забезпечення якості, що охоплює весь цикл розроблення ПЗ. У цей час починають з'являтися різні програмні інструменти для підтримки процесу тестування: більш просунуті середовища для автоматизації з можливістю створення скриптів і генерації звітів, системи управління тестами, ПЗ для проведення навантажувального тестування. У середині 1990-х з розвитком Інтернету й розробленням великої кількості веб-застосунків особливої популярності стало набувати «гнучке тестування» (за аналогією з гнучкими методологіями програмування).
У 2000-х з'явилося ще більш широке визначення тестування, коли в нього було додано поняття «оптимізація бізнес-технологій». BTO направляє розвиток інформаційних технологій згідно з цілями бізнесу. Основний підхід полягає в оцінці та максимізації значущості всіх етапів життєвого циклу розроблення ПЗ для досягнення необхідного рівня якості, продуктивності, доступності.