Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп’ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2011
Тип роботи:
Методичні вказівки до виконання дипломних та магістерських кваліфікаційних робіт
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 1-2
“ Розробка програмного продукту. Етап формулювання”
з дисципліни
“ Технологія програмування та створення програмних продуктів ”
для студентів базового напрямку підготовки по спеціальності
“ Комп’ютерні науки ” (шифр 0804)
Львів-2011
Методичні вказівки до лабораторної роботи № 1-2 “Розробка програмного продукту. Етап формулювання вимог та побудова моделі” з дисципліни “Технологія програмування та створення програмних продуктів” для студентів спеціальності - шифр 0804 “Комп’ютерні науки”/ Укл. доц. Ковівчак Я.В., Львів: Національний університет “Львівська політехніка”, 2011.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2011 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2011 р.
Лабораторна робота № 1-2
Розробка програмного продукту.
Етап формулювання вимог та побудова моделі
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу формулювання вимог та побудови моделі
Завдання: Навчитись реалізовувати етап формулювання вимог та побудови моделі при розробці програмного продукту комп’ютерних систем
1. Теоретична частина
Оскільки довільне ПЗ по суті являє собою алгоритм, записаний мовою, зрозумілою для комп'ютера, то програма має всі властивості, характерні для алгоритмів. Але програма є конкретною реалізацією алгоритму, призначеною для практичного використання, і властивості програм розглядають саме з цієї точки зору.
Можна виділяти такі вимоги до програм:
1. Правильність.
Програма повинна видавати правильні результати для будь-яких даних зі заздалегідь визначеного допустимого діапазону. Якщо програма є достатньо складною, навіть найбільш кваліфікований програміст навряд чи зможе з першого разу написати її без помилок. Ці помилки можуть бути найрізноманітніші: від суто механічних (забув поставити крапку з комою) до неналежного використання програмних конструкцій або навіть помилок в самому алгоритмі.
Загальноприйнятою є така класифікація програмних помилок:
синтаксичні, які пов'язані з порушенням формальних граматичних правил написання програм. Синтаксичні помилки виявляються на етапі компіляції;
помилки часу виконання.
Ці помилки знову ж таки поділяються на такі категорії:
аварійні зупинки. Пов'язані з операціями, які неможливо виконати (ділення на нуль, звернення до неіснуючих файлів тощо). У таких випадках програма зупиняється;
програма не доходить до кінця. Вона працює нескінченно довго або зависає;
програма видає неправильні результати.
Помилки повинні бути виявлені та виправлені (цей процес називається відлагодженням). Крім того, необхідно переконатися на деяких тестових прикладах що програма працює правильно (цей процес називається тестуванням). Відомо, що саме на відлагодження і тестування припадає левова частка роботи над програмою. Деякі приховані помилки так і залишаються невиправленими і час від часу проявляють себе уже в процесі експлуатації програми. Це можуть бути несподівані повідомлення на екрані, зависання і т.п. Але наслідки програмних помилок можуть бути і значно серйознішими. Відповідальність за виявлення і знешкодження помилок повністю лежить на авторах розробки.
2. Ефективність.
Програма повинна видавати результати за прийнятний час і не бути надто ресурсомісткою. Різні програми, які призначені для вирішення однієї й тієї самої задачі, можуть мати різну ефективність і за інших рівних умов природно надавати перевагу більш ефективній програмі.
3. Надійність.
Користувач повинен довіряти програмі і не боятися її використовувати. Надійна програма повинна бути правильною; якщо ж залишаються помилки, то вони не повинні призводити до серйозних проблем. Самої лише правильності програми замало. Якщо користувач вводить неправильні дані, програма повинна повідомити його про це. Якщо програма сприймає неправильні дані і видає неправильні результати - це набагато гірше, ніж якщо вона взагалі не працює. За будь-яких умов використання програми не повинно призводити до фатальних, невиправних або важко виправних наслідків.
4. Універсальність.
Програма повинна бути розрахована на широкий діапазон вхідних даних і при можливості - на широкий спектр задач.
5. Функціональність.
Програма повинна забезпечувати всі основні потреби користувача і не реалізовувати можливостей, що є для нього непотрібними.
6. Зручність у використанні.
Програма повинна бути зручною в засвоєнні і використанні, а програмний інтерфейс повинен бути інтуїтивно зрозумілим. Відомо, що за останні десять років був зроблений величезний крок у цьому напрямку.
7. Стандартизованість.
Різні програмні продукти повинні мати однотипні засоби керування і однотипний інтерфейс для того, щоб користувач, який має досвід роботи з однією програмою, мав якнайменше незручностей при переході до іншої.
8. Переносимість.
Повинна забезпечуватися можливість перенесення програм з однієї машини на іншу без змін або з мінімальними змінами.
9. Читабельність.
Тексти програм повинні бути максимально простими для сприйняття і розуміння людиною.
10. Модифікованість.
Програма повинна передбачати можливість для змін і доповнень.
11. Документованість.
Кожна програма повинна супроводжуватися інструкціями щодо її використання і ці інструкції повинні бути доступними і зрозумілими. В самій програмі повинні використовуватися коментарі, які пояснюють суть самої програми та основних її елементів.
Життєві цикли програмного забезпечення.
Вимоги.
Визначення вимог - це форма основної загальної мови, що використовується для підготовчого спілкування з клієнтами.
Задоволення вимог - це структурована форма ясності вимог, що використовує загальну мову і базові структури.
Специфікація ПЗ - формальний опис вимог.
Формальна специфікація передбачає деталізовану декомпозицію вимог (використовуючи якусь форму), які можна буде легко зрозуміти і які не викликатимуть невизначеності.
Аналіз вимог є першим етапом розробки ПЗ, на якому вимоги замовника уточнюються, формалізуються і документуються. Фактично від цього етапу залежить успіх і на ньому треба відповісти на запитання: "Що повинен робити майбутній програмний продукт?".
Першочерговими вимогами до розроблюваного ПЗ визначаються такі:
сукупність умов, в яких передбачається використовувати майбутню систему (апаратні і програмні ресурси, які надаються системі, зовнішні умови її функціонування, список користувачів, персоналу і робіт, які мають відношення до цієї системи);
обмеження в процесі розробки ПЗ (директивні терміни завершення окремих етапів, наявні ресурси, організаційні заходи і процедури, що забезпечують захист інформації).
У компанії, що створює ПЗ для клієнта, аналітики мають прямий контакт з представниками клієнта. Часті інтерв'ю з представниками клієнта, які є в більшості випадків користувачами системи, призводять до формулювання всіх деталей вимог. Рекомендується, щоб одна людина з боку клієнта була відповідальна за комунікацію представників клієнта з аналітиками.
Хороший опис вимог повинен:
бути повним і послідовним;
описувати, як поводиться система, як вона побудована;
розглядати будь-які обмеження системи;
бути легким у розвитку;
брати до уваги можливі майбутні зміни;
описувати виключення.
Основна помилка на цьому етапі полягає в зосередженості на типових ситуаціях і зневага виключеннями. І користувачі, і аналітики мають таку схильність.
Вимоги до ПЗ можуть бути розділені на два типи:
Функціональні вимоги. Вони описують функції (операції, дії) виконувані системою;
Нефункціональні вимоги. Вони описують обмеження функціональності.
Функціональні вимоги.
Функціональні вимоги описують функції, що виконуються системою. Вони можуть передбачати вимоги до зовнішніх систем для виконання.
Неспеціалізована мова часто використовується для опису вимог, але при цьому є деякі незручності:
двозначність неспеціалізованої мови, яка робить опис важким і може привести до різного його розуміння людьми;
гнучкість неспеціалізованої мови, яка дозволяє виражати той же самий вміст в різних формах. Це може привести до упущення суперечливих вимог, сформульованих в різноманітних формах тих же самих функцій.
Формальна примітка може усунути двозначність, але це може бути важким для сприйняття клієнта. Таким чином, вона може тільки закінчити неспеціалізований опис.
Зазвичай функціональні вимоги даються у формі очікуваного результату, а не у формі алгоритму. Опис є декларативним, але в деяких специфічних випадках необхідним є алгоритм.
Функціональні вимоги сформульовані, щоб визначити зовнішні зв'язки. Функції повинні бути відомі користувачам і іншим взаємодіючим системам. Під функціями системи ми не повинні розуміти тільки функції програми.
Техніка сходження вниз передбачає, що найзагальніші функціональні вимоги сформульовані і розділені по назві функції.
На практиці, клієнти не завжди розуміють або цікавляться загальними функціональними можливостями системи, а обговорюють специфічні функції, які потім об’єднуються аналітиком системи. Таку техніку називають технікою сходження вверх.
Більшість підходів використовує обидва методи. Аналітик системи повинен розглянути загальні функції спочатку, але він повинен також ввести інформацію, зібрану від користувачів. Таким чином операції розділення-об’єднання застосовуються в процесі визначення вимог.
Нефункціональні вимоги.
Нефункціональні вимоги описують обмеження та залежності, в яких виконуються функції. Ці вимоги можуть бути поділені на:
вимоги продукту, наприклад "можуть використовуватися тільки клавіатура і миша";
вимоги процесу, наприклад "система повинна виконуватися за стандартом XXA/2002" ;
зовнішні вимоги, наприклад "система повинна працювати з базою даних, описаною в документі YYYB/2001 і ніякі зміни в базі даних недопустимі".
Атрофовані вимоги повинні бути кількісними, тобто повинен існувати метод перевірки виконання умов. Такі вимоги як: "зручний", "надійний", "ефективний" не можуть бути перевірені, отже, вони не відповідають формулюванню.
Труднощі з формулюванням вимог виникають через наступні причини:
клієнт не знає як цілі можуть бути досягнуті. З іншого боку є багато способів досягнення цілей;
великі системи використовуються багатьма користувачами. Можуть бути протиріччя в причинах їх використання. Різні користувачі можуть знати різну термінологію;
люди, що розміщують замовлення, і користувачі - різні люди. Думка замовників може бути критичною на цьому етапі, але вони, можливо, не враховують деяких потреб користувачів.
Можна описати вимоги клієнта на різних абстрактних рівнях:
визначення вимог. Загальний опис, який проводиться після інтерв'ю з представниками клієнта;
специфікація вимог. Опис, який використовує структуровану і природну мову і вводить деяку просту формальну примітку;
специфікація ПЗ - повністю формальний опис вимог.
Вимоги повинні міститися в документі з описом вимог, який повинен охоплювати:
введення - цілі, можливості і контекст системи. Ця частина містить результати стратегічного етапу;
опис розвитку системи - опис можливих змін;
опис функціональних вимог;
опис атрофованих вимог;
модель системи;
словник.
Цей документ може містити додаткову інформацію:
специфікація функціональних вимог;
специфікація нефункціональних вимог;
вимоги до устаткування;
вимоги до баз даних;
індекс;
плани тестування.
Доступність системи.
Програма повинна мати систему безпеки, яка встановлює доступ до системи для кожного користувача.
Чинниками успіху для функціонального формулювання вимог є:
робота з відповідними представниками клієнта;
повне розуміння вимог, розрізняння спеціальних випадків і виключень (типова помилка для цього етапу - зосередження на типових ситуаціях);
перевірка завершеності і послідовності вимог;
невеликий опис нефункціональних вимог.
Якісний опис вимог повинен задовольняти наступні вимоги:
бути повним і послідовним;
описувати зовнішній режим роботи;
описувати обмеження системи;
бути легким для модифікування;
брати до уваги можливі майбутні зміни;
описувати швидкодію системи в екстремальних або небажаних ситуаціях.
Рекомендації до правильних визначень.
Вимоги повинні бути сформульовані критично у порівнянні до існуючого ПЗ і прототипів.
Вимоги користувача повинні бути:
зрозумілими;
унікальними;
такими, щоб їх можна було перевірити;
точними;
реалістичними;
досяжними.
Найбільш важливі методи ідентифікації вимог:
зустрічі і огляди (Зустрічі повинні бути підготовлені у формі списку питань від різних сторін, що відносяться до даного проекту. Вони повинні проходити серед презентабельної групи користувачів, прагнучих до схвалення проекту);
вивчення існуючого ПЗ (Часто нове ПЗ замінює старе. Вивчення повинне визначати слабкі і сильні сторони старого ПЗ і погоджувати нові вимоги, якщо система повинна бути частиною старої);
вивчення досяжності (Повинні бути визначені реалістичні цілі і методи);
прототипування (Побудова прототипів систем з меншим об'ємом і спрощеним інтерфейсом).
Системні вимоги можуть бути документовані декількома способами. Можливі методи документування:
звичайна мова. Найчастіше використовується (Незручності в її невизначеності і гнучкості, що дає можливість описувати одне і те ж декількома шляхами. Зв'язки між різними вимогами не можуть бути визначені, і виникають суперечності);
математичний формалізм (Вживається давно);
структурована звичайна мова (Звичайна мова з обмеженим словником і семантикою. Предмети і проблеми описані в секціях і підсекціях);
таблиці, форми (Вимоги задані в таблицях (зазвичай дворівневі), асоційовані різними зв'язками (наприклад, таблиця з зв'язками типів користувачів з сервісами));
блоки і діаграми (Графічні форми, що зображують процеси);
контекстні діаграми (Показують системи, оточення, входи і виходи);
використання діаграм випадків (Концептуальна презентація того що відбувається і функцій).
Використання діаграм випадків з асоціативними документами вважається одним з кращих методів документування вимог. Простота спілкування поєднується з точністю виразів, необхідною для майбутньої роботи над системою.
Основні вимоги розділені на дві групи:
функціональні вимоги;
нефункціональні вимоги.
Функціональний опис вимог здійснює:
ідентифікація всіх типів користувачів системи;
ідентифікація всіх типів користувачів підтримки (адміністратори, клерки);
визначення кожного типу користувачів всіх системних функцій і шляхів використання системи;
опис зовнішніх систем (бази даних, Інтернету, різних мереж), що будуть використовуватися системою;
визначення організаційних структур, законодавства, стратегій, статусу, інструкцій, що прямо або непрямо описують функції.
Функціональні вимоги можуть бути сформульовані, використовуючи шаблони вимог.
Шаблон гарантує стандартне формулювання і полегшує завершення формулювання.
Таблиця 1. Функціональні вимоги.
Назва функції
Майстер обробки прибутку
Опис
Функція дозволяє редагувати прибуток платника податків заданого року
Вхідні дані
Дані про доходи, отримані з різних джерел, витрати на отриманий прибуток, податки на різні внески. Інформація про квитанції. Інформація та документи платника податків.
Джерело вхідних даних
Інформація податкової служби
Результат
Початкова умова
Прибуток = весь прибуток - витрати на отриманий прибуток. Весь прибуток, прибуток і витрати на отримання прибутку - всі джерела прибутку.
Кінцева умова
Така ж, як зазначено вище
Побічні ефекти
Змінення бази оподаткування
Причина
Функція дозволяє робити розрахунки швидше і без помилок
Нефункціональні вимоги
Опис вимог включає об’єкти, над яким будуть виконуватись функції:
вимога продуктів, наприклад, повинна бути доступна клавіатура;
вимога процесів, наприклад, процес планувальника повинен виконаються за стандартом XXXA/06;
зовнішні вимоги, наприклад, система планування повинна використовувати маркетингове відділення баз даних описане в документі YYYB/95. Ніяких змін до бази даних не застосовано.
Якісна форма представлення нефункціональних вимог - це таблиця, наприклад:
Таблиця 2. Нефункціональні вимоги.
№
Дата
Автор
Вимога
Причина
Примітки
1
99/04/14
A.Nowak, J.Pietrjak
Програма повинна видавати результат не більше, ніж через 5 секунд при роботі 100 користувачів одночасно
Програма не буде конкурентоспроможною
Може працювати нестабільно
2
00/02/05
K.Lubicz
Кожен клієнт повинен мати дуже коротку IP-адресу
Інші ідентифікатори (SIN, Pesel) нестабільні, довгі, можуть повторюватися у різних користувачів
3
...
...
...
...
...
Складові нефункціональних вимог:
Системні функції (ієрархія функцій, що виконуються системою);
Об’єм (скільки користувачів працюватимуть одночасно? скільки терміналів буде встановлено? скільки інформації буде збережено?);
Швидкість (час для виконання операції (або черги операцій), кількість операцій за одиницю часу, максимальний час виконання операції);
Точність (вимірювання масштабування і продуктивності, точність результату, заміна кількісних показників якісними);
Обмеження (обмеження інтерфейсу, якості, часових інтервалів, устаткування, засобів програмування і т.п.);
Інтерфейс зв'язку (тип мережі, протоколи, представлення мережі, рівень абстракції, протоколів і т.п.);
Програмний інтерфейс (специфікація устаткування, фізичні обмеження, продуктивність (швидкість процесора, пам'ять), вимоги до офісу (вологість, температура, тиск));
Програмний інтерфейс (сумісність з іншим ПЗ, ОС, мова програмування, компілятори, редактори, система управління базами даних (СУБД));
Взаємодія людини з системою (всі аспекти інтерфейсу, призначеного для користувача, мова програмування, апаратне забезпечення (монітор, миша, клавіатура), формати (звіти, їх зміст), визначення повідомлень (мова, форма), допомога, повідомлення помилок і т.п.);
Адаптивність (специфікація відповіді системи на зміни - нові команди, нове вікно і т.п.);
Безпека (конфіденційність, специфікація надійності і т.п.);
Гнучкість (невдачі, наслідки помилок ПЗ, помилка живлення, частота і т.п.);
Стандарти (специфікація стандартів документів, форматів файлів, розміри шрифтів, стандарти процесів і продуктів і т.п.);
Ресурси (бюджет, людський ресурс і обмеження матеріальних ресурсів);
Час (час, необхідний для побудови системи, тренування і установки).
Перевірка вимог.
Типова помилка формування нефункціональних вимог - брак критеріїв, необхідних для перевірки вимог. Кожна нефункціональна вимога повинна бути перевірена. Це вимагає вибір критеріїв.
Таблиця 3. Критерії перевірки вимог.
Характеристика
Міра
Продуктивність
Кількість транзакцій за секунду Час відгуку
Розмір
Кількість записів у базі даних Потрібний розмір пам'яті
Зручність для користувача
Час, потрібний для навчання Розмір документації
Надійність
Вірогідність помилки трансакції
Час між виконаннями Доступність (час, коли програма доступна для користувача) Час перезавантаження програми після помилки Вірогідність втрати даних після помилки
Переносимість
Розмір платформозалежного коду Кількість платформ Вартість перенесення
Документ з вимогами.
Системні вимоги повинні бути описані в документі, який є базою для контракту користувача з розробниками. Документ повинен бути прийнятий клієнтом та розробником і зрозумілий обом. Документ повинен бути підготовлений так, щоб підтримувалася перевірка задоволення вимог.
Таблиця 4. Приклад документа з вимогами.
План Тіло документу Стандарт: 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. Доповнення
Послідовність дій, необхідних для оформлення документа, повинна бути наступною:
якщо немає інформації, записати "не додається";
повинна бути описана причина виконання кожної з вимог. Призначення проекту може залежати від вимог, нестача цієї специфікації може спричинити неуспіх у виконанні;
будь-який матеріал, що не увійшов до секції, повинен бути доданий в "Додаток".
Часто до документа додаються:
вимоги апаратного і програмного забезпечення;
модель системи (архітектура);
словник (термінологія, синоніми, абревіатури);
зміст.
Найбільш важливі чинники формулювання якісних вимог:
Стиль :
ясність - однозначне формулювання, зрозуміле для користувача і розробника;
структура документа;
відповідність - ніяких конфліктів у формуванні вимог;
змінність - формулювання по ключових моментах.
Гнучкість :
легке додавання нових вимог.
Специфікація ролей :
можливість пов'язати персону з вимогою, описувати дію вимоги.
Помірність :
паперовий або електронний варіант;
контроль версії документа.
Словник.
Будь-які терміни повинні бути зрозумілими всіма сторонами. Всі специфічні терміни повинні бути додані в словник. Всі невизначеності повинні бути уточнені.
Таблиця 5. Приклад словника.
Термін
Визначення
Синоніми
Банківський рахунок
Послідовність номерів, записаних через дефіс, що визначають ресурси та операції клієнта
рахунок
Клієнт
Одиниця апаратури, котра використовується клієнтом в офісі
робоча станція
Користувач
Особа, котра використовує програму для його/її власних цілей, що не мають відношення до адміністрації та обслуговуючого персоналу
Клієнт
…
…
…
Ключові чинники успіху етапу формулювання вимог є :
приведення прикладів клієнтові для роз'яснення неоднозначностей;
повна ідентифікація вимог, виявлення специфічних і виняткових вимог.
Модель.
Модель - це представлення якоїсь концепції реальності. На практиці завжди будують моделі різного типу: математичні моделі, фізичні, і т.д.
Модель дає змогу експериментувати: вносити зміни, додавати і видаляти частини і елементи. Вносити зміни до моделі набагато простіше, ніж в систему. Наслідки неправильних рішень зменшуються і їх простіше виявити перед тим, як вони завдадуть шкоди самій системі.
Розробники інформаційних систем під час проектування використовують наступні моделі:
модель вимог - описує способи використання;
аналітична модель - статика і динаміка системи, описуються мовою UML (деталями реалізації нехтують);
модель дизайну - описується мовою UML більш деталізовано (наприклад, присутні фізичні діаграми).
Аналітична модель.
Аналітична модель найдетальнішим чином описує те, для чого призначена система. Модель не має відношення до самої реалізації.
Головна мета побудови такої моделі - надати повний, послідовний і зрозумілий опис системи з точки зору функцій, але не деталей реалізації. Модель використовується для кращого розуміння системи, виправлення помилок, додавання необхідних елементів і є основою моделі дизайну.
Аналітична модель - модель, яка будується на етапі аналізу. Мета етапу - розпізнавання всіх чинників або умов в даній області, в проектному оточенні, в існуючих і запланованих комп'ютерних системах, які можуть вплинути на ухвалення рішень, якості системи і реалізацію вимог. Результат - логічна модель системи, яка описує метод реалізації вимог але не зачіпає нічого, що стосується реалізації.
Наступний етап - етап дизайну. Він відповідає на питання, як система повинна реалізовуватися і описує цю реалізацію.
Причини побудови більшої моделі:
імпортування в модель елементів із зовнішніх систем робить систему більш загальною і всеосяжною;
протягом побудови ми можемо все ще не знати, які готові елементи будуть включені у фінальну версію продукту, а які будуть написані в ручну;
бюджет може не дозволити повної розробки системи "з нуля", і визначення способів побудови буде проведено під час аналізу.
Якісна аналітична модель повинна мати наступні характеристики:
вона повинна бути спрощеним описом системи;
функції повинні бути представлені ієрархічно;
логічна модель повинна відповідати певним правилам;
повинна будуватися за допомогою добре відомих методів і інструментів;
модель використовується для ухвалення рішень в подальшому дизайні.
Модель ПЗ повинна бути спрощеним описом, який представляє найважливіші особливості ПЗ на високому абстрактному рівні.
Логічна модель :
показує, що повинна робити система;
показує ієрархію системи;
уникає термінології реалізації;
дозволяє ухвалювати рішення "від причини до наслідків" і назад.
При побудові аналітичної моделі найчастіше роблять такі записи:
звичайна мова;
графічні записи;
специфікація - структурований текстовий і числовий опис.
Графічні записи дуже важливі при побудові аналітичної моделі. Розробка ПЗ використовує і інші способи запису, наприклад, методи з електроніки і механіки. Психологічний аналіз показує важливість використання графічного запису.
Функції запису:
інструмент аналітика і дизайнера;
зв'язок з користувачем;
зв'язок з іншими членами команди;
основа для реалізації ПЗ;
опис технічної документації.
Запис повинен бути простий, зрозумілий, конкретний, легкий для розуміння, дозволяючи моделювати складні зв'язки.
Дії на етапі аналізу.
Основними діями на етапі аналізу є:
визначення, пояснення, моделювання, специфікація і документування частин і проблем проекту;
визначення контексту проекту;
визначення вимог користувача;
визначення організаційних вимог;
інші рішення, наприклад, апаратні настройки, настройки ПЗ, фінансові обмеження, обмеження часу і т.п.
Сам аналіз не повинен робити якісь зміни, наприклад, введення таких нових елементів, як комп'ютерні системи. Мета аналізу - ідентифікувати всі аспекти, які можуть вплинути на форму, організацію і результати проекту.
Основними діями в ході аналізу є:
побудова статичних моделей класів;
аналіз функцій і випадків застосування;
перевірка класів і об'єктів;
розпізнавання і визначення методів і повідомлень;
моделі станів і діаграми їх змін;
моделі процесів і діаграми потоків даних;
управління потоком.
Ключовими чинниками успіху на фазі аналізу є:
участь представників клієнта;
повний і загальний підхід, без загострення уваги на деталях;
розгляд складних аспектів (безпека, масштабованість, оцінка об'єму і т.п.);
відповідність стандартам;
перевірка коректності і послідовності;
прозорість, логічність і послідовність документа.
На фазі аналізу будується логічна модель. Модель відповідатиме детальному і конкретному опису того, як повинна бути побудована система, щоб задовольняти сформульовані вимоги.
Результати цієї фази наступні:
покращені вимоги, описані в документі;
словник даних;
документація моделі, що містить :
діаграми класів;
діаграми випадків використання;
діаграми послідовності повідомлень;
діаграми станів;
визначення класів, атрибутів, відносин, методів і т.д. ;
графік етапу дизайну:
переднє визначення персоналу і строків.
Одним з підходів до побудови аналітичної моделі є функціональна декомпозиція, яка розбиває системні функції, які повинні відповідати наступним вимогам:
функції повинні мати унікальні визначені цілі;
функції повинні бути визначені ієрархічно (наприклад, проведення контролю з допомогою циклічного надмірного коду знаходиться нижчим, ніж протокол мережного рівня);
інтерфейси повинні бути мінімальні, що дозволить легше розділення функцій;
повинне дотримуватися правило виклику не більше семи функцій;
описи функцій не повинні відноситися до подробиць реалізації (наприклад, файл, завдання, запис, модуль, робоча станція);
характеристики якості роботи повинні бути описані, де це можливо (наприклад, швидкість, частота і т.п.);
слід визначити найважливіші функції;
імена функцій повинні описувати, що вони роблять, а не як вони це роблять;
імена функцій повинні бути декларативними (наприклад "обробка замовлення"), а не процедурними (наприклад "дії після того, як прийде замовлення").
При створенні аналітичної моделі використовують наступні методології:
1. Структурні методи. Структурні методи комбінують статичний опис процесів і статичні моделі даних.
До цього класу моделей належать наступні підходи:
методи Yourdon (DeMarco і Ward/Mellon);
методологія структурного системного аналізу і дизайну (Structured System Analysis and Design Methodology, SSADM);
техніка структурного аналізу і дизайну (Structured Analysis and Design Technique, SADT).
Згідно з DeMarco, структурний аналіз використовує наступні методи:
словник баз даних;
схеми потоків даних;
структурована англійська мова;
таблиці вирішень;
дерева вирішень.
2. Інші методи:
схема перетворення;
діаграма зміни станів;
список подій;
схема даних;
перед- і післяумови;
діаграми відносин "сутність-зв'язок";
історія життя об'єкту.
Недолік використання структурного підходу – труднощі в об'єднанні моделей.
Моделі об'єктів.
Об'єктно-орієнтована методологія використовує базовий компонент на етапах аналізу і дизайну, тобто діаграма відносин класів – це розширення діаграми відносин "сутність-зв'язок". У діаграмах класів описуються класи, їх атрибути, методи, узагальнення, асоціації, агрегації, кількісні характеристики відносин і обмеження. Як допоміжні діаграми модель показує діаграми взаємодії, функціональні діаграми і т.д. Випадки використання описують структуру системи з точки зору користувача.
Для будь-якої мови її синтаксис, семантика і прагматика повинні бути проаналізовані.
Синтаксис – визначає способи ведення запису.
Семантика – визначає значення запису.
Прагматика – визначає способи і цілі застосування запису і використання шаблонів. Вона визначає процеси отримання результатів аналізу і дизайну у формі, яку вибрали автори. Прагматика незвичайно важлива для будь-якої методології. Реальні приклади зазвичай дуже складні, а наші приклади дуже часто здаються тривіальними.
Документація вимог.
Аналітичну модель слід представляти у формі єдиного повного документа.
Таблиця 6. Форма представлення аналітичної моделі.
План Тіло документу
Стандарт:
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 Вимоги підтримки 3.13 Вимоги захисту
4. Доповнення
2. Постановка задачі
В сьогоднішні дні важко собі уявити життя без комп’ютерних технологій та Інтернету. З розвитком інформаційних технологій з’являються нові можливості, які значно полегшують виконання об`ємних рутинних задач, а також дають змогу здійснювати масштабні проекти, які було б неможливо реалізувати, або навіть уявити без Інтернету. Наприклад, інтернаціональні опитування, соціальні мережі, Інтернет магазини і т.д.. Таким чином виникає необхідність створення таких програмних засобів, за допомогою яких можна було б проводити інтерактивні оцінювання і опитування користувачів.
Одним із таких замовлень стала система «CОСtrial» , яка полегшить викладачам процес оцінювання і опитування студентів, спростить хід навчального процесу.
Замовниками системи є навчальні заклади, які намагаються використовувати новітні інформаційні технології у навчальному процесі і ставлять за мету надати можливість студентам проходити тестування та висловлювати свою думку відносно різних питань у вигляді соцопитувань в зручний для них час.
Етап формулювання вимог
Програма призначена для проведення тестувань та опитувань в on-line режимі і передбачає використання двох клієнтів: один для адміністрування, а другий для проведення тестувань та отримання думки користувачів по певних питаннях.
Викладачі і студенти мають попередньо отримати свій логін і пароль у адміністратора.
Перший клієнт призначений для адміністраторів та викладачів.
Для роботи з цим клієнтом необхідно попередньо встановити спеціальну програму на робочому місці.
Адміністратор працює тільки в режимі 1-го клієнта. До його функцій входить: адміністрування системи, створення та редагування користувацьких записів, слідкування за коректною роботою системи.
У випадку використання керівником проекту 1-го клієнту він отримує всі права адміністратора.
Викладачі при використанні 1-го клієнта можуть здійснювати: реєстрування студентів, редагування користувацьких записів студентів, створення груп, створення тестувань і формування питань для опитування думки користувачів.
Другий клієнт спеціально призначений для проходження тестувань або опитувань думки всіма класами користувачів. В основному цей клієнт буде використовуватись студентами. Для роботи з ним можна використовувати спеціальну попередньо встановлену програму, або web-браузер, у випадку не сумісності програми з операційною системою, проте не всі функції будуть доступними.
Після проходження тестування користувач, в режимі клієнт 2, безпосередньо отримає свій результат. Кожен користувач має можливість проходити лише визначені йому тестування та опитування думки.
Завдання системи
Система призначена для проведення тестувань та опитування думки студентів навчальних закладів.
Особливості програмного продукту
Основна особливість системи полягає в тому, що вона проводить як тестування, так і опитування думки студентів із збереженням результатів у загальній базі даних.
Система призначена для роботи у локальній мережі та через Internet.
Процес тестування та опитування думки може відбуватися як і з допомогою спеціальної програми (встановленої на ПК, або в локальній меражі), так і за допомогою web-браузера.
Умови роботи
Для роботи системи необхідно мати комп’ютер-сервер, на якому буде розміщена база даних, спроектована мовою SQL. До сервера через локальну мережу або Інтернет будуть надходити запити від інших комп’ютерів, на яких встановлена спеціальна програма , яка забезпечує роботу в режимі клієнт 1 і клієнт 2.
Система може працювати на таких операційних системах як : Windows XP, Windows 7 , Windows vista.
Для нормального користування системою швидкодія Інтернету повинна бути не меншою 512 Кбіт/сек.
Серед усіх функцій, які виконує система можна виділити загальні операції:
Реєстрація користувачів.
Редагування користувацьких записів.
Створення груп користувачів.
Генерування груп.
Редагування груп.
Створення тестувань по окремих дисциплінах.
Редагування тестувань.
Організація опитувань думки користувачів по певних питаннях.
Редагування питань опитування думки.
Відображення списків користувачів, груп,
01.02.2013 02:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора