МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів Контакти
Тлумачний словник |
|
|||||||
Лекція №10. Документування вимог у відповідності зі стандартамиСтандарти документування вимог до ПЗ: 1.міжнародний, ІЕЕЕ Std 830-1998 = у ньому містяться рекомендації до структури і методів опису програмних вимог (Recommended Practice for Software Requirements Specifications) 2.наш, ГОСТ 34.602-89 = технічне завдання на створення автоматизованої системи (Інформаційна технологія. Комплекс стандартів на автоматизовані системи) 3.наш, ГОСТ 19.201-78 = ТЗ, вимоги до вмісту та оформлення (Єдина система програмної документації) Документування вимог регламентується російським ГОСТ 19.201-78, 34.602-89. Другий документ, по суті, є більш проробленою версією першого, адаптованою до створення автоматизованих інформаційних систем (АІС). Використовуються на даний момент. Технічне завдання – це вихідний документ для розробки автоматизованої системи, створення програмного продукту або проведення науково-дослідних робіт, відповідно до якого проводиться виготовлення, приймання при введенні у дію та експлуатації відповідного об’єкту. Зміст ГОСТ 34.602-89: 1.загальні відомості = у цьому розділі крім юридичних реквізитів сторін ГОСТ рекомендує вказувати джерела і порядок фінансування робіт. 2.призначення і цілі створення або розвитку системи = тут необхідно вказати показники об’єкту автоматизації, які повинні бути досягнуті, і критерії оцінки досягнення цих показників. 3.характеристика об’єктів автоматизації = організаційна структура, структура управління, структура розміщення підприємства і його філіалів. Гарний опис об’єкту автоматизації дозволяє зекономити час на визначення класів користувачів. 4.вимоги до системи 4.1.вимоги до структури системи у цілому = режими функціонування системи, персоналу (чисельність, необхідна кваліфікація, режим роботи), вимоги до надійності, безпеки, стандартизацій та уніфікацій, та інші; 4.2.вимоги до функцій (задач, що виконуються системою) = перелік функціональних вимог у прив’язці до підсистем і чергам автоматизації, часовий регламент реалізації функціональних вимог, вимоги до якості реалізації кожного із функціональних вимог, перелік і критерії відмов (??) для кожної функціональної вимоги; 4.3.вимоги за видами забезпечення = вказуються види забезпечення, а саме: математичне, інформаційне, лінгвістичне, програмне, технічне, метрологічне, організаційне та методичне. 5.склад і супроводження робіт по створенню системи = описує процес створення системи, включаючи види методологій, що визначають зміст стадій, етапів і фаз та його конкретизацію для проекту (кількість етапів та ітерацій і їх основний зміст). 6.порядок контролю і прийому системи = розподіляє ролі замовника і розробника у підготовці системи до тестування і його проведення (формулювання основних тестових сценаріїв і критеріїв прийому). 7.вимоги до складу і змісту (вмісту) робіт по підготовці об’єкту автоматизації до вводу системи у дію = обумовлюється порядок проведення реінженерингу підприємства, який необхідно здійснити для того, щоб досягти від впровадження АІС належного ефекту. 8.вимоги до документування = перелік і форми документації, що підлягає розробці. 9.джерела розробки = перелік документів, що містять передумови розробки.
Документування вимог Rational Unified Process (RUP) RUP – методологія створення ПЗ, розроблена Rational Rose. Шаблон SRS, запропонований у RUP, по суті, представляє собою контейнер, у який необхідно упакувати артефакти, що отримані у процесі специфікування вимог. Крім того, SRS частково перекликається з документом бачення-концепції. Шаблон зручний своєю компактністю і лаконізмом. 1.Введення 1.1. Мета = документ повинен вичерпним чином описувати зовнішню поведінку системи, а також нефункціональні вимоги і обмеження 1.2. Коротке зведення можливостей 1.3. Визначення, акроніми і скорочення 1.4. Посилання 1.5. Короткий зміст 2.Огляд системи 2.1. Огляд прецедентів = містить список імен і коротких описів варіантів використання та акторів з ілюстраціями у вигляді діаграм прецедентів 2.2. Припущення і залежності = описує ключові технічні можливості, компоненти, підсистеми, зв’язані проекти, які можуть впливати на шви.. здатність (???) розроблюваної системи; припущення = положення, яке вважається істинним при відсутності доведення або визначаючої інформації; при визначенні залежностей проекту від зовнішніх факторів необхідно проаналізувати які нові ОС, регламенти бізнес-процесів, стандарти якості, інформаційні системи можуть з’явитися на підприємстві і як це може вплинути на функціонування виготовлюваної АІС 3.Опис вимог 3.1. Опис варіантів використання = містить опис варіантів використання і зв’язаних з ними нефункціональних вимог або посилання на відповідні артефакти 3.2. Спеціальні вимоги = містить опис функціональних вимог (не описаних як варіанти використання), а також опис нефункціональних вимог загального характеру (не співставлених жодному преценденту у попередньому розділі) або посилання на відповідні артефакти 4.Допоміжна інформація = сюди включається інформація, що полегшує розуміння документу, це може бути зміст і додатки, наприклад, що описують прототипи користувальницького інтерфейсу
Читайте також:
|
||||||||
|