Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2010
Тип роботи:
Методичні вказівки до виконання дипломних та магістерських кваліфікаційних робіт
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 6
“Розробка документації на програмне забезпечення”
з дисципліни
“Технологія програмування та створення програмних продуктів”
для студентів базового напрямку підготовки по спеціальності
“Комп’ютерні науки” (шифр 0804)
Львів 2010 – 20011
Методичні вказівки до лабораторної роботи № 6 “Розробка документації на програмне забезпечення” з дисципліни “Технологія програмування та створення програмних продуктів” для студентів спеціальності - шифр 0804 “Комп’ютерні науки”/ Укл. доц. Ковівчак Я.В.,
Львів: Національний університет “Львівська політехніка”, 2011.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2011 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2011 р.
Лабораторна робота № 6
Розробка документації на програмне забезпечення
Мета: Ознайомитись з етапом виготовлення документації на програмний продукт.
Завдання: Розробити необхідний повний перелік документації на програмне забезпечення.
Теоретична Частина
Документування - це важлива частина розробки програмного забезпечення, але часто їй приділяють недостатньо уваги.
Документація на програмне забезпечення - це документи, що супроводжують деяке програмне забезпечення (ПЗ) - програму чи програмний продукт. Ці документи описують те, як працює програма або те, як її використовувати.
Документація проекту
Протягом роботи над проектом створюють велику кількість документів, наприклад: документація виробничого процесу ПЗ, керівництво, яке описує завершений проект. Документація проекту містить:
Плани, оцінки, графіки роботи - документи, розроблені менеджерами.
Схвалені документи - це інструкції для виробників.
Звіти - документи, підготовлені супервізорами. Ці документи описують роботу і її результати.
Стандарти - документи, що описують необхідні стандарти.
Робочі документи - різноманітні документи з ідеями рішень. Автори можуть бути членами команди. Якщо їх схвалять, ці документи можуть стати стандартами.
Повідомлення - примітки, коментарі, які використовуються для комунікації між членами команди.
Стандарти документації повинні стосуватися всіх аспектів проекту. Підготовка документації ділиться на стадії: попередня документація, редагування, друк, компонування копій, внесення змін у документи. Форма і зміст повинні бути ретельно підібрані відповідальними особами. Обкладинка, зміст, структура тіла документа, індекс, словник і т.п. повинні бути встановлені згідно стандарту. Потрібно визначити механізм доступу до документації, тобто слід створити бібліотеку для документів. З удосконаленням програми буде удосконалюватися і документація. Проте старі версії документів все одно залишаться. Прикладом таких документів є:
інформація про всі версії,
інформація про клієнтів і версії, які вони придбали,
ПЗ і апаратні вимоги до версії,
інформація про компоненти (класи, об'єкти, модулі), потрібні для версії,
інформація про можливі зміни версії,
інформація про виявлені помилки.
Документація повинна супроводжуватися відповідною інфраструктурою, в межах якої ця документація створюється. Під інфраструктурою ми розуміємо межі, формат і управління документацією. Загублені документи, записи, коментарі і додаткові зауваження можуть стати загрозою для проекту. Крім того, управління інфраструктурою під час проекту є дуже витратним у фінансовому і часовому плані. Тому відповідна інфраструктура повинна бути схвалена на початку проекту.
До уваги повинні бути взяті наступні пункти:
унікальна ідентифікаційна структура із заголовком, автором і номером документа;
номери послідовності і опис повинні містити:
тип документа,
номер документа,
номер версії,
дата версії,
стан;
призначення відповідальності по виробництву документа, його схваленню, редагуванню і реєстрації;
процедури введення змін; призначення відповідальних;
гарантія якості документа і особа, відповідальна за процес.
Додаткові елементи можуть бути введені в інфраструктуру, наприклад, рівень конфіденційності документів.
Інфраструктура звіту
Управління проектом вимагає підготовки детальної документації і відповідності крайнім термінам. Керівники проекту підготовлюють звіти клієнтам - ініціаторам проекту і супервізорам вищого рангу. Звіти є дуже важливі для продуктивності проекту. Звіти обговорюються на зустрічах. Необхідно робити звіти про прогрес і навантаження працівників. Формальні звіти повинні супроводжуватися особистим спілкуванням з персоналом.
Звіти стану роботи
Регулярно (наприклад, щомісячно) керівництво повинно організовувати зустрічі, для яких повинні готуватися звіти на такі теми:
технічний стан,
стан ресурсів,
проходження графіку,
проблеми,
фінансовий стан.
Часові таблиці
Часові таблиці спрощують оцінку проекту. Вони повинні мати однакову структуру.
Технічна документація
Таку документацію часто включають безпосередньо у вихідний код або надають разом з ним.
Документація такого типу має сильно виражений технічний характер і загалом використовується для визначення й опису APІ, структур даних і алгоритмів.
Кількість і обсяг документації залежить від складності і компонентного складу документації (опис мови, опис застосування даного програмного забезпечення, інструкція для оператора і т.д.). Документація розробника насамперед призначається для персоналу, що здійснює розвиток і підтримку цього програмного забезпечення.
Часто при складанні технічної документації використовуються автоматизовані засоби - генератори документації.
Вони отримують інформацію зі спеціальним чином оформлених коментарів у вихідному коді і створюють довідку в будь-якому форматі , наприклад, у вигляді тексту або HTML. У більшості випадків мета генераторів - скласти щось подібне до енциклопедії всіх функцій, класів, об'єктів, ієрархій класів, зв'язків між файлами тощо.
Генератори можна умовно поділити на:
Універсальні
Doxygen для C, Java, Python, PHP. На виході - html, pdf, man, pdf, rtf.
NaturalDocs
AsciDoc
doc-o-matic для Matlab, ASPX, JSP, IDL, Delphi, C#, VB, Java, PHP
Специфічні
javadoc для Java
phpDocumentor для PHP
docutils NDoc, Sandcastle,
GhostDoc для .NET
pasdoc для Delphi
ZenDoc для ActionScript
Документація є частиною вихідного коду, тому одні й ті самі інструменти можуть використовуватися для складання програми та її документації. Це також спрощує підтримку документації в актуальному стані.
Технічна документація повинна бути перевірена перед тим, як ПЗ буде доставлене клієнтові.
Архітектурна / проектна документація
Проектна документація зазвичай описує продукт у загальних рисах. Вона відповідає на питання «чому саме так?» Наприклад, у проектному документі програміст може описати обґрунтування того, чому структури даних організовані саме таким чином. Описуються причини, чому певний клас сконструйований певним чином. Нічого із перерахованого не входить у технічну або користувацьку документацію, але тим неменше це все є важливою частиною проекту.
Користувацька документація
На відміну від технічної документації, сфокусованої на коді і тому, як він працює, користувацька документація описує лише те, як використовувати програму. У випадку, якщо продуктом є програмна бібліотека, користувацька документація та документація на код стають дуже близькими, майже еквівалентними поняттями. Але в загальному випадку це не так.
Зазвичай, користувацька документація представляє собою посібник користувача, який описує кожну функцію програми, а також кроки, які потрібно виконати для використання цієї функції.
Документація повинна бути написана простою, доступною мовою, особливо, якщо ця документація призначена для користувачів персональних комп’ютерів. Дуже важливо, щоб документація не вводила в оману і була актуальною. Інструкція повинна мати чітку структуру; логічна зв’язаність і простота також мають велике значення.
У багатьох випадках розробники програмного продукту обмежують набір спеціальної документації лише вбудованою системою допомоги (англ. online help), що містить довідкову інформацію по командах або пунктах меню. Навчання нових користувачів перекладається на приватних видавців.
Маркетингова документація
Для багатьох програм необхідно мати в розпорядженні ряд рекламних матеріалів для того, щоб зацікавити людей, звернувши їхню увагу на продукт. Така форма документації має на меті:
підвищити інтерес до продукту у потенційних користувачів
інформувати їх про те, що саме робить продукт, для того, щоб їхні очікування збігалися з тим, що вони отримають
пояснити місце продукту в порівнянні з конкуруючими рішеннями
Однією з гарних маркетингових практик є впровадження слогана - простої фрази, що запам'ятовується; вона ілюструє те, що ми прагнемо донести до користувача, характеризує відчуття, які створює продукт.
Часто буває так, що коробка продукту та інші маркетингові матеріали дають більш чітку інформацію про можливості та способи використання програми, ніж все інше.
Загалом, документація пишеться паралельно з ПЗ. Зазначимо, що написання документації починається одночасно з формулюванням вимог.
Документація на етапах розробки ПЗ
Етап визначення вимог
Системні вимоги повинні бути описані в документі, який є базою для контракту користувача з розробниками. Документ повинен бути прийнятий клієнтом та розробником і зрозумілий обом. Документ повинен бути підготований так, щоб підтримувалася перевірка задоволення вимог.
Приклад такого документа:
Таблиця 1. Приклад документа з вимогами.
План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення
Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії
1. Вступ 1.1 Ціль 1.2 Контекст 1.3 Визначення, скорочення, абревіатури 1.4 Посилання 1.5 Короткий огляд 2. Загальний опис 2.1 Зручність роботи з програмою 2.2 Загальні характеристики 2.3 Характеристики користувача 2.4 Умови роботи 2.5 Припущення та взаємозв'язки 3. Вимоги 3.1 Функціональні вимоги 3.2 Нефункціональні вимоги 4. Доповнення
Послідовність дій, необхідних для оформлення документу, повинна бути наступною:
якщо немає інформації, записати "не додається";
повинна бути описана причина виконання кожної з вимог. Призначення проекту може залежати від вимог, нестача цієї специфікації може спричинити недоліки у виконанні;
будь-який матеріал, що не увійшов до секції, повинен бути доданий в "Додаток".
Часто до документу додаються:
вимоги апаратного і програмного забезпечення;
модель системи (архітектура);
словник (термінологія, синоніми, абревіатури);
зміст.
Найбільш важливі чинники формулювання якісних вимог:
Стиль :
ясність - однозначне формулювання, зрозуміле для користувача і розробника;
структура документу;
відповідність - ніяких конфліктів у формуванні вимог;
змінність - формулювання по ключових моментах.
Гнучкість :
легке додавання нових вимог.
Специфікація ролей :
можливість пов'язати особу з вимогою, описувати дію вимоги.
Помірність :
паперовий або електронний варіант;
контроль версії документу.
Етап аналізу
Аналітична модель системи - модель, яка будується на етапі аналізу.
Аналітичну модель слід представляти у формі єдиного повного документу.
Приклад такого документу:
Таблиця 2.Форма представлення аналітичної моделі.
План Тіло документу Стандарт: ANSI/IEEE std 830-1993 Рекомендований порядок специфікації вимог програмного забезпечення
Резюме (не більше 200 слів) Зміст Статус документу: автори, компанії, дати і т.д. Зміни, зроблені після останньої версії
1. Вступ 1.1 Ціль 1.2 Контекст 1.3 Визначення, скорочення, абревіатури 1.4 Посилання 1.5 Короткий огляд 2. Загальний опис 2.1 Спільне з існуючими проектами 2.2 Спільне з минулими і майбутніми проектами 2.3 Функції та цілі 2.4 Параметри середовища 2.5 Відношення до зовнішніх програм 2.6 Загальні обмеження 2.7 Опис моделі 3. Вимоги: цей розділ може містити багато функцій, котрі вимагаються від функціональної декомпозиції 3.1 Функціональні вимоги 3.2 Вимоги продуктивності 3.3 Вимоги відношень з зовнішніми програмами 3.4 Вимоги щодо ресурсів 3.5 Вимоги перевірки 3.6 Вимоги тестування 3.7 Вимоги до документації 3.8 Вимоги до безпечності 3.9 Вимоги переносимості 3.10 Вимоги якості 3.11 Вимоги надійності 3.12 Вимоги підтримки 2.13 Вимоги захисту 4. Доповнення
Первинні ефекти аналізу:
Покращуються:
документ з вимогами;
словник даних;
Створюються:
документи, що описують створену модель:
діаграми класів
діаграма випадків використання
діаграма дій
діаграми станів
звіт, що описує визначення класів, ознак, відносин, методів і т.д.;
графік етапу проектування;
Етап проектування
Цей етап існує для детального опису реалізації системи. Опис після необхідних змін, зроблених на наступних етапах (реалізації і тестування), буде частиною технічної документації системи.
Серед основних результатів етапу проектування є:
виправлений документ формулювання вимог,
Наступні групи вимог, що повинні бути враховані:
Вимоги до робочих характеристик.
Вимоги до інтерфейсу (протоколи, формати файлів).
Експлуатаційні вимоги.
Вимоги до ресурсів (число процесорів, об'єм вінчестера).
Контрольні вимоги.
Тестові вимоги.
Вимоги документування.
Вимоги безпеки.
Вимоги портативності.
Вимоги якості.
підбір методу проектування
можливість повторного використання
підбір інструментів
можливість зовнішнього доступу
Вимоги надійності.
Інструкція з технічного обслуговування.
Можливість усунення відмов або несправностей.
виправлена модель,
детальна специфікація
документ, що описує проект:
діаграми класів,
діаграми взаємодій,
діаграми станів,
діаграми діяльності,
діаграми компонентів,
визначення ознак класів, складних і елементарних даних, методів.
Детальний документ проекту
Модель проекту повинна бути записана в документі з назвою «Детальний Документ Проекту» (ДДП).
Мета підготовки цього документу полягає в тому, щоб позначити всі деталі, сформульовані в документі з вимогами. У ДДП необхідно визначити всі вимоги, - це допоможе уникнути проблем в експлуатації. Стиль повинен бути систематичним і точним. Мова і діаграми повинні бути зрозумілими і підлягати змінам. Значення всіх термінів повинне бути чітко визначене.
Організація інформації
Короткий звіт
Зміст
Статус документу
Опис змін порівняно з минулою версією
ЧАСТИНА I - ЗАГАЛЬНИЙ ОПИС
Введення
Описується мета , визначаються терміни і таблиці посилань.
Мета - описується мета ДДП і визначається потенційний читач.
Можливості - визначається програмний продукт; описується, що створюється шляхом програмування (і що не створюється); визначаються переваги, цілі і ступені відповідальності.
Визначення, акроніми, абревіатури.
Посилання.
Основні положення.
2. СТАНДАРТИ, ПРАВИЛА І ПОРЯДОК ВИКОНАННЯ ДІЙ ПРОЕКТУ
Стандарти проекту
Стандарти документу
Термінологія
Стандарти програмування
Засоби розробки ПЗ
ЧАСТИНА II – ВИЗНАЧЕННЯ СКЛАДОВИХ
n [ІДЕНТИФІКАТОР СКЛАДОВОЇ]
n.1. Тип n.2. Ціль n.3. Функція n.4. Підкомпоненти n.5. Зв'язки n.6. Інтерфейси n.7. Ресурси n.8. Посилання n.9. Трансформація n.10. Дані
Додаток A. Початковий текст програми.
Додаток B. Матриця зв'язків вимог і компонентів програмного забезпечення.
Якість DPD
Модифікованість документа
Тексти, діаграми, графіки повинні бути створені у формі, що легко модифікується. Видалення і зміни, що повторюються в різних місцях, повинні піддаватися жорсткому контролю.
Еволюція документу
ДДП повинен бути об'єктом ретельного контролю, особливо якщо він створений командою програмістів. Повинна проводитися формальна верифікація документу. Версії мають бути позначені порядковими номерами і датами внесення останніх змін.
Відповідальність за документ
Міра відповідальності повинна бути однозначно визначена. Зазвичай відповідальний - програміст, який створює програмне забезпечення.
Середовище документу
Оригінал документу повинен бути добре захищений. Інші версії повинні бути похідними від оригіналу.
Інші рекомендації по ДДП
ДДП – це центральний документ, в якому міститься вся інформація про конструкцію програмного забезпечення. ДДП повинен бути завершеним і будь-яка допоміжна інформація повинна записуватися у вигляді додатку.
Етап реалізації
Серед основних результатів етапу реалізації є:
розширений документ з вимогами,
розширений проект, який в даний момент завершується документацією,
код з перевіреними модулями,
звіт про перевірені модулі.
Етап тестування
Серед основних результатів етапу тестування є:
покращені код, проект, модель і специфікація вимог,
звіт про тести з їхніми результатами.
Етап встановлення
Серед головних результатів етапу встановлення є:
покращені код, проект, модель і специфікація вимог.
Якість програмного забезпечення
Стандарти і система якості
Стандарти - загальні правила якості, яким продукт повинен відповідати.
Стандарти повинні бути визначені і задокументовані.
Гарантія якості програмного забезпечення (SQA, software quality assurance) визначає, чи задовольняють плани стандарти, чи відповідають процедури планам, чи реалізовуються продукти згідно планів.
Важливе завдання в SQA - підготовка і організація документації.
План гарантії якості ПЗ (SQAP)
План гарантії якості ПЗ (SQAP, Software Quality Assurance Plan) повинен змінюватися протягом життєвого циклу програми. Першу версію потрібно завершити до кінця формулювання вимог.
Цей план визначає, яким чином проект повинен досягти відповідності встановленому рівню якості. Відповідні секції повинні посилатися на певні фази життєвого циклу ПЗ.
Зміст плану гарантії якості ПЗ залежить від розміру проекту.
Секції ПГЯПЗ
ПГЯПЗ повинен бути зрозумілим, несуперечливим і підлягати змінам. Він повинен бути розглянутий і схвалений контролюючим органом. Цей документ може розповсюджуватися в електронній формі.
ПГЯПЗ повинен бути створений для наступної фази після завершення попередньої.
Зміст ПГЯПЗ
Номери послідовності не можна змінювати. Якщо в секції немає інформації, потрібно зробити позначку "не застосовується". Весь допоміжний матеріал надається в доповненнях.
Організаційна інформація
a - резюме (максимум - 200 слів)
b - зміст
c - стан документації
d - зміни, починаючи з останньої версії
Тіло документа
Ціль
Секція повинна бути описана стисло: завдання ПГЯПЗ, тип читача.
Довідкові документи
У цьому розділі повинен бути наведений повний перелік документів, на які існують посилання в тексті SQAP. У цей перелік повинні бути включені документи, що використовувалися при розробці SQAP, у тому числі постанови чи закони, які використовувались у даному та інших планах, або опису завдань, які конкретизують деталі цього плану. До списку слід включати версії та дати кожного документу.
Управління
Цей розділ описує структуру організації проекту, задачі, розподіл відповідальності та ролей без перерахування призначених працівників, робоче навантаження і графіки роботи. (див. IEEE Std 1058-1998.)
3.1. Організація
Цей розділ визначає, які ролі задіяні в процесі забезпечення якості. Фактичний розподіл обов'язків поданий в розділі 3.3.
Визначаються такі ролі як проектний менеджер, супервізор, інженер ПЗ, бібліотекар ПЗ. Між ролями повинен бути взаємозв'язок.
3.2. Завдання
Завдання з контролю якості.
3.3. Відповідальність
Закріплюється відповідальність конкретних ролей за визначеними завданнями.
3.4. Очікувані витрати ресурсів на забезпечення якості
Цей розділ повинен описувати очікувані витрати ресурсів та коштів, які планується витратити на забезпечення і контроль якості.
Документація
Ціль
Визначити документацію, що використовується для забезпечення якості
4.2 Вимоги до документації
Визначаються всі документи, які запроваджуються в проекті. В ідеалі повинні бути розроблені наступні документи:
SQAP: План контролю якості (даний документ).
SCMP: План управління конфігураціями. (для великих проектів)
SPMP: План управління програмним проектом.
SRS: Специфікація вимог до програмного забезпечення.
SDD: Проектна документація програмного забезпечення.
STD: Документація з тестування програмного забезпечення.
Посібник користувача.
План супроводу.
Крім цих документів у вихідному коді написаному на мові Java буде використовуватися Javadoc і завдяки цьому можна буде генерувати документацію на рівні пакетів, класів і функцій.
Інша документація
Тут перераховують інші документи, що можуть використовуватись для розробки програмного продукту. Інші документи можуть включати в себе наступні:
План процесу розробки.
Опис стандартів розробки програмного забезпечення.
Опис методів / процедур / інструментів програмної інженерії.
План управління програмним продуктом (див. IEEE Std 1058-1998).
План супроводу (див. IEEE Std 1219-1998).
План забезпечення безпеки (див. IEEE Std 1228-1994).
План інтеграції програмного забезпечення.
Стандарти
Ціль
Описати або дати посилання на джерела стандартів.
Опис
Повинна бути наведена інформація як мінімум про наступні стандарти (див. IEEE Std 982.1-1988 і IEEE Std 982.2-1988 ):
Стандарти документації.
Стандарти проектування.
Стандарти кодування.
Стандарти коментування.
Стандарти та методики тестування.
Аудити і огляди програмного забезпечення
6.1. Ціль
Ціль оглядів і аудитів полягає в тому, щоб привернути увагу розробників до якості продукту в ході розробки. Огляди проводяться на плановій регулярній основі. Об'єкти аудиту вибираються випадковим чином.
6.2 Мінімальні вимоги
Як мінімум, слід виконати наступні огляди програмного забезпечення.
6.2.1. Огляд специфікацій програмного забезпечення
SSR проводиться для забезпечення адекватності вимог.
6.2.2. Огляд архітектури проекту
ADR проводиться, щоб оцінити технічну адекватність проекту (відомого також як top-level design) програмного забезпечення, описаного в описі проекту програмного забезпечення.
6.2.3. Детальний огляд проекту
DDR проводиться, щоб визначити адекватність детального проекту програмного забезпечення, який знаходиться в описі детального проекту програмного забезпечення, в частині задоволення вимог SRD.
6.2.4. Огляд плану верифікації
Огляд плану верифікації здійснюється для того, щоб оцінити адекватність і повноту методик верифікації.
6.2.5. Функціональний аудит
Цей аудит проводиться перед постачанням програмного забезпечення, щоб переконатися, що всі вимоги виконані.
6.2.6. Фізичний аудит
Цей аудит здійснюється, щоб перевірити внутрішню узгодженість програмного забезпечення і його документації, а також їх готовність до випуску.
6.2.7. Робочі перевірки
Робочі перевірки фрагментів проекту проводять, аби перевірити узгодженість проекту, в тому числі:
узгодженість коду та проектної документації.
узгодженість специфікації.
відповідність реалізації проекту функціональним вимогам.
узгодженість функціональних вимог і описів тестів.
6.2.8. Огляди управління
Огляди управління проводяться періодично, щоб перевірити можливість доступу до всіх матеріалів, перелічених в SQAP. Огляди управління проводяться зазвичай керівним персоналом.
6.2.9. Огляд плану управління конфігураціями програмного забезпечення
Відповідальний за якість повинен проводити огляд стану управління конфігураціями не рідше ніж раз на місяць незалежно від процедур, встановлених у плані керування конфігураціями.
6.2.10. Заключний огляд
У заключний огляд включаються огляд закінченої фази і огляд самого процесу контролю якості. Відповідальний за якість зобов'язаний скласти звіт про вдосконалення процесу на кожній фазі.
6.3. Інші огляди та аудити
Інші огляди та аудити можуть включати в себе огляд користувацької документації (user documentation review, UDR). Цей огляд проводиться, щоб оцінити адекватність користувацької документації.
Тестування
Секція описує проведення контролю за перевіркою і затвердженням перевірки тестів.
Звіти про проблеми та дії щодо їх усунення.
Цей розділ стосується опису та усунення дефектів.
Інструменти, технології та методології
Цей розділ повинен перерахувати програмні інструменти, технології та методики, що використовуються для підтримки процесів SQA.
Контроль носіїв інформації
Цей розділ повинен встановити методи та засоби, які використовуються для:
визначення носіїв інформації для зберігання комп'ютерного продукту.
захисту фізичного носія комп'ютерної програми від неавторизованого доступу або ненавмисного пошкодження.
Контроль постачальників
Дії, які застосовуються до зовнішніх організацій або осіб. Зовнішні постачальники ПЗ повинні керуватися визначеними стандартами.
Збір, підтримка і зберігання записів
Цей розділ повинен визначати, яку документацію SQA слід зберігати, а також встановити методику та засоби для збору, об'єднання, забезпечення безпеки і підтримки цієї документації.
Навчання
В цьому розділі повинні бути перераховані всі базові навчальні курси на SQA - тематику, що проводяться для членів проекту.
Управління ризиками
Цей розділ повинен визначати методики, які використовуються для визначення, доступу та управління ризиками, що виникають у процесі розробки програмного забезпечення.
Словник термінів і акронімів.
Цей розділ повинен містити словник термінів, які використовувалися в SQAP.
Процедури зміни SQAP
Цей розділ повинен містити процедури модифікації SQAP та підтримки історії змін. Він повинен також містити методи контролю за змінами.
Приклад реалізації
Користувацька документація
Зміст
І. Інсталяція системи.
1. Інсталяція серверної частини системи;
2. Інсталяція клієнтських програм (Клієнт 1, Клієнт 2);
3. Налаштування клієнтських програм.
ІІ. Інструкція для користувачів:
Програма для управління (Клієнт 1):
Режим адміністратора;
Режим викладача;
Режим керівника проекту.
Програма для тестування (Клієнт 2):
Інструкція використання;
І. Інсталяція системи.
1. Інсталяція серверної частини системи.
Оскільки наша система ‘COCtrial’ працює за принципом клієнт-сервер, під сервер має бути виділений окремий комп’ютер з локальною мережею, або виходом в Інернет. Для налаштування сервера необхідно:
Встановити програму MS SQL Server;
Зупинити SQL Server використавши додаток Configuration Manager;
Скопіювати два файли бази даних (main_db.mdf, main_db_log.ldf) з каталогу DB (знаходиться у корінному каталогу ‘COCtrial’) у каталог C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data;
Запустити SQL Server використавши додаток Configuration Manager.
Після виконання вище наведених дій SQL-сервер автоматично розпочне обслуговувати базу даних системи!
2. Інсталяція клієнтських програм (Клієнт 1, Клієнт 2).
Процес інсталяції для всіх класів користувачів є однаковим. Клієнтські програми встановлюються на окремий комп’ютер з локальною мережею або з виходом в Інтернет. Програма ‘COCtrial’ не потребує особливої інсталяції на комп’ютер. Для роботи з нею достатньо скопіювати каталог ‘COCtrial’ на довільний фізичний диск комп’тера. Вміст даного каталогу зображений на рис. 1.
Рис. 1.
Він включає с себе 3 підкаталоги: DB (база даних), Management tools (клієнт для адміністрування та створення опитувань – Клієнт 1) і Survey client (клієнт для проведення опитувань – Клієнт 2).
Щоб активізувати Клієнт 1 необхідно зайти у каталог ‘Мanagement tools’ і відкрити exe-файл ‘Management Tools.exe’ (Рис. 1.1).
Рис. 1.1.
Для роботи з Клієнтом 2 необхідно відкрити каталог ‘Survey client’ і активізувати exe-файл ‘Survey Client.exe’ (Рис. 1.2).
Рис. 1.2
3. Налаштування клієнтських програм.
При першому запуску одного з клієнтів буде висвітлене вікно налаштування зв’язку з базою даних (рис. 2).
Рис. 2.
У закладці вибору провайдера вікна налаштування (Рис. 2) необхідно вибрати - Microsoft OLE DB for SQL Server, і натиснути кнопку ‘Next’ (Рис. 2).
Після цього відбудеться автоматичний перехід на закладку Connection (Рис. 3).
Рис. 3.
На цій закладці необхідно вказати назву сервера і вибрати базу даних з назвою ‘SurveyDB’ (яка має бути на цьому сервері). Після натиснення кнопки ‘OK’ можна приступати до робот из програмою.
ІІ. Інструкція використання.
Програма для управління (Клієнт 1).
Клієнт 1 призначений для контрою за системою, створення тестувань та опитувань, перегляду звітів і роботи з користувацькими записами системи. Використовувати Клієнт 1 можуть такі класи користувачів, як: викладачі, адміністратор і керівник проекту.
Головне вікно програми для управління складається з таких чотирьох части (Рис. 3): меню (1), менеджера користувачів (2), редактора тестувань та опитувань (3), і менеджера звітів (4).
Рис. 3.
Для початку роботи необхідно залогуватися, натиснувши на кнопку меню ‘Sign In’ (Рис. 3). Після натиснення цієї кнопки появиться діалогове вікно для логування (Рис. 4):
Рис. 4
Ввівши коректний логін і пароль, та натиснувши кнопку Enter можна приступати до роботи з системою. За логіном і паролем система ідентифікує користувача і визначає режим роботи клієнта.
Режим адміністратора.
Закладка менеджера користувачів (Account Manager).
За допомогою менеджера користувачів адміністратор може здійснювати різні дії з користувацькими записами і групами користувачів. Менеджер користувачів включає в себе дві закладки (Рис. 5): Users (1) і Groups (2). Розглянемо детальніше функції адміністратора з закладки Users (Рис. 5):
Рис. 5.
Додавання користувацького запису:
Щоб додати нового користувача адміністратору необхідно ввести дані у відповідні поля User Id, Login, Password, Full Name і вибрати тип користувача у комбобоксі Role після чого натиснути кнопку ‘Add / Edit’ (3) (Рис. 5) і підтвердити виконання операції.
Редагування користувацького запису:
Для редагування запису користувача адміністратору необхідно ввести Id користувача, інформацію якого потрібно відредагувати, у поле ‘User Id’, або вибрати його зі списку (6) (Рис. 5). Потім потрібно заповнити поля Login, Password, Full Name, Role, натиснути кнопку ‘Add / Edit’ (3) (Рис. 5) і підтвердити виконання операції.
Видалення користувацького запису:
Для видалення користувача з бази достатньо виділити його зі списку (6) (Рис. 5) і натиснути кнопку ‘Delete’ (4) (Рис. 5). Після вказаних дій необхідно підтвердити виконання операції.
Пошук користувачів:
Пошук користувачів адміністратор може здійснювати за допомогою динамічного фільтра (5) (Рис. 5). Для пошуку необхідно вибрати тип ключа за яким буде здійснюватися фільтрування у розділі ‘Applay to’ фільтра (5) (Рис. 5) (по замовчування це User Id), і ввести ключ пошуку у поле ‘Key’. Під-час вводу система буде відтворювати всі користувацькі записи, які задовольняють введений ключ.
Тепер перейдемо до функцій адміністратора з закладки Groups менеджера користувачів (Рис. 6):
Рис. 6.
Додавання групи:
Щоб додати нову групу адміністратору необхідно ввести дані у відповідні поля Name і Group ID (Рис. 6), і натиснути кнопку ‘Add / Edit’ (1) (Рис. 6) після чого група буде додана в базу.
Редагування групи:
Для редагування групи адміністратору необхідно ввести Id групи, назву якої потрібно відредагувати, у поле ‘Group Id’, або вибрати її зі списку (6) (Рис. 6). Потім потрібно змінити вміст поля Name і натиснути кнопку ‘Add / Edit’ (1) (Рис. 6), потім підтвердити виконання операції.
Видалення групи:
Для видалення групи з бази адміністратору достатньо виділити його зі списку (6) (Рис. 6) і натиснути кнопку ‘Delete’ (2) (Рис. 6). Після вказаних дій необхідно підтвердити виконання операції.
Пошук груп:
Пошук груп адміністратор може здійснювати за допомогою динамічного фільтра (7) (Рис. 6). Для пошуку необхідно вибрати тип ключа за яким буде здійснюватися фільтрування у розділі ‘Applay to’ фільтра (7) (Рис. 6) (по замовчування це Group Id), і ввести ключ пошуку у поле ‘Key’. Під - час вводу система буде відтворювати всі групи, які задовольняють введений ключ.
Генерація групи:
Для того, щоб згенерувати групу адміністратору необхідно ввести назву у полі ‘Name’, потім задати число користувачів у полі ‘Num of Stud’, і натиснути кнопку Generate group (3) (Рис. 6). Після підтвердження виконання операції буде створена група з заданою кількістю студентів.
Додавання студента до групи:
Щоб додати студента до групи необхідно ввести ім’я студента у полі ‘User Name’ і назву групи у полі ‘Group Name’ на панелі ‘User Groups Manipulator’ (Рис. 6), потім натиснути кнопку ‘Add User To Group’ (4) (Рис. 6).
Видалення студента з групи:
Щоб видалити студента з групи необхідно ввести ім’я студента у полі ‘User Name’ і назву групи у полі ‘Group Name’ на панелі ‘User Groups Manipulator’ (Рис. 6), потім натиснути кнопку ‘Delete User From Group’ (5) (Рис. 6).
Закладка редактора тестувань та опитувань (Survey Builder).
Редактор тестувань та опитувань (3) (Рис. 3) дає можливість адміністратору системи з легкістю створювати і редагувати тестування та опитування.
Закладка менеджера звітів (Report Builder).
За допомогою менеджера звітів (4) (Рис. 3) адміністратор може створювати різні звіти результатів тестувань та опитувань, які значно спрощують контроль за успішністю студентів.
Режим викладача.
У Клієнті 1 викладач
01.02.2013 02:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора