Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту. Етап формулювання вимог та побудова моделі
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Комп'ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2008
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Методичні вказівки
до лабораторної роботи № 1
“Розробка програмного продукту. Етап формулювання вимог та побудова моделі ”
з дисципліни
“Технологія програмування та створення програмних продуктів”
для студентів базового напрямку підготовки по спеціальності
“Комп’ютерні науки” (шифр 0804)
Львів-2008
Методичні вказівки до лабораторної роботи № 1 “Розробка програмного продукту. Етап формулювання вимог та побудова моделі” з дисципліни “Технологія програмування та створення програмних продуктів” для студентів спеціальності - шифр 0804 “Комп’ютерні науки”/ Укл. доц. Ковівчак Я.В.,
Львів: Національний університет “Львівська політехніка”, 2008.
Методичні вказівки обговорено та схвалено на засіданні кафедри АСУ Протокол № ___________ від «___»___________2008 р.
Завідувач кафедрою АСУ ______________ Рашкевич Ю. М.
Методичні вказівки обговорено та схвалено на засіданні методичної комісії базового напрямку підготовки
Протокол № ___________ від «___»___________2008 р.
Лабораторна робота № 1
Розробка програмного продукту.
Етап формулювання вимог та побудова моделі
Мета: Ознайомлення з основними задачами, які необхідно розв’язати під час виконання етапу формулювання вимог та побудови моделі
Завдання: Навчитись реалізовувати етап формулювання вимог та побудовати модель при розробці програмного продукту комп’ютерних систем
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 Вимоги підтримки 2.13 Вимоги захисту 4. Доповнення
2. Приклад реалізації етапу формулювання вимог та побудови моделі
Постановка задачі
З кожним роком все частіше магазини та супермаркети потребують точнішого контролю товару та роботи касира.
В 2004 році надійшло замовлення від магазину з проханням зробити систему для покращення роботи касирів, та полегшити їм роботу з пошуком товарів та готівковими операціями.
Етап формулювання вимог
Аналіз вимог є першим етапом розробки її ПЗ, на якому вимоги замовника уточнюються, формалізуються і документуються. Фактично від цього етапу залежить успіх і на ньому треба відповісти на запитання: "Що повинен робити майбутній програмний продукт?".
Завдання системи
Система повинна буде застосовуватися у великих магазинах, супермаркетах, а також при самообслуговуванні або у відділах магазину (супермаркету). Призначається для покращення операції продажу та роботи касира.
Особливості програмного продукту
Система повинна, на сам перед, бути зручною під час роботи. Тому цей програмний продукт повинен мати простий, зручний інтерфейс, швидко виконувати свої функції, та всю основну інформацію виводити для швидкого сприйняття, а виконана операції супроводжувати необхідними повідомленнями. Система повинна також передбачати ряд обмежень, які можуть призвести її до неправильної роботи, а саме:
Перевірка на правильність введених даних користувачем;
Обмеження в доступі до параметрів системи.
Загальні характеристики системи
Система повинна виконувати основні функції, що виконує касир у своїй роботі та влючити нові можливостями, а саме:
Формування товарного чеку (фіксування кількості та ціни проданого товару).
Можливість надання знижок на основі суми закупки або постійним клієнтам, використання карток клієнта.
Автоматична ідентифікація товару (в т.ч. вагового) за допомогою сканера штрих-кодів, пошук товару за назвою або кодом.
Друк фіскальних чеків та касових звітів на фіскальному принтері чеків.
Друк не фіскальних чеків на звичайному принтері чеків
Звичайний користувач не повинен мати доступ до всіх її функцій а лише використовувати ті, які йому дозволено.
Передбачити, що користувач не буде вводити інформацію в такому вигляді, в якому йому запропонує програма в певному діалозі.
Умови роботи
Програма, яка працює з певним фіскальним принтером повинна легко перена лаш товуватися на роботу з іншим ФП і використовувати всі його функціональні можливості. Операції з товарами можуть розширюватися а деякі з них повинні блокуватися в окремих випадках.
Програма повинна працювати автономно, не маючи доступу до бази товарів, які знаходяться на віддаленому сервері. В такому випадку база товарів повинна створюватися на тому самому комп’ютері що і програма.
Серед усіх функцій, які виконує система можна виділити загальні операції:
пошук необхідного товару
редагування чеку
додавання товар в чек
видалення одного (або всіх) товару з чеку
зміна кількості товару
надання і скасування знижки
закриття чеку
Функціональні вимоги
Вхід тільки під паролем
Касир має свій номер (логін) та пароль
Адміністратор має тільки свій пароль
Кожен касир повинен мати свій доступ до програми
Формування бази касирів
В системі повинно бути 7 касирів
Сервісний касир має доступ до функцій ФП та бази касирів
Властивості касирів та доступи до функціональних можливостей
Режим адміністратора
Механізми пошуку товару по коду, штрих-коду та назві
Можливість друку чеку на термальному принтері
Зберігання чеків
Редагування списку товарів в чекові
Видалення товару
Додавання товару
Зміна кількості.
Можливість автоматичного встановлення знижок залежно від кількості товару
Можливість реєстрації товару з фіскальним принтером
Зберігання рахунків
Для ресторану чи бару необхідно не повне закриття чеку а зберігати замовлений товар в пам’яті для доповнення його новими товарами.
Можливість задавати знижку чи надбавку
Формування інвентаризаційного чеку
Набір підказок та повідомлень в критичних випадках
Кожна дія з боку програми повинна супроводжуватися діалоговими повідомленнями
Можливість працювати з базою товарів через мережу
Використовувати всі функціональні можливості фіскального принтера
Нефункціональні вимоги
Для звичайної роботи програми достатньо комп’ютер з монітором та клавіатурою
В режимі адміністратора може знадобитися миша
Для видачі не фіскальних чеків до комп’ютера потрібно під’єднати термальний принтер на налаштувати його відповідно до його конфігурації та властивостей
Для видачі фіскальних чеків до комп’ютера потрібно під’єднати фіскальний принтер який зареєстрований в податковій та налаштований відповідно до його конфігурації та властивостей
Програма повинна без затримок шукати необхідний товар в базі товарів
Користувачі програми
Основними користувачами програми є особи, які виконують обов’язки касирів та відповідають за правильну реєстрацію товару в програмі.
Допоміжними користувачами програми є особи, які знають повністю програму і легко можуть її пере налаштовувати без допомоги розробників. Такі люди є адміністраторами програми і мають доступ до всіх функціональних можливостей.
Додаткові вимоги
Для функціонування системи необхідно встановити пакет Net Framework 2.0.
Словник
Термін
Визначення
Адміністратор
Особа, яка досконало знає досконало систему і в випадку стану аварії на касі може швидко усунути проблему.
Чек
Файл з записом продукції, яка була куплена покупцем. Включає в себе ціну, суму знижки, суму ПДВ та тип оплати.
Результат виконання операції продажу. Звіт для покупця.
Касир
Особа, котра використовує програму для його/її власних цілей, що не мають відношення до адміністрації та обслуговуючого персоналу
Фіскальний Принтер (ФП)
Пристрій, який зареєстрований в податковій, має фіскальний та податковий номер. Призначений для друку фіскальних чеків з списком товарів.
Термопринтер
Звичайний друкуючий пристрій. Призначений для друку інформації на термоплівці.
Інвентаризаційний чек
Це перелік усіх товарів, які є в наявності. Формується одним чеком.
. Модель функціонування системи
Ця модель показує взаємодію покупця з касиром. А також виконання операцій з обох сторін. Покупець не має зв’язку з самим ФП або термопринетром. Він тільки отримує результат виконання операції цього принтера.
Покупець
Потік повідомлень
Касир
Новий товар
Змінює кількість
Відмова від товару
Картка знижки
Оплата
Отримує товар
Отримує чек
Підтвердження
Нова кількість
Підтвердження
Знижка
Підтвердження
Сканує товар
Редагує вміст чеку
Видалення товару
Нова сума
Підсумок
Здача
В завершенні операції продажу товару касир взаємодіє з фіскальним бо термопринетром та виконує друк необхідної інформації.
Касир
Потік повідомлень
Фіскальний принтер
Формує документ з товаром.
Запит на виконання операції
Підтвердження.
Підтвердження.
Друк
Виконання операції
Касир не взаємодіє з ФП та самою системою. Він лише керує через касира роботою системи та отримує результат виконання, та результат фіскального принтера.
Також ФП взаємодіє з самою системою без допомоги касира. Це відбувається вже під час виконання друку або іншої операції.
Система
Потік повідомлень
Фіскальний принтер
Формує необхідні дані.
Аналіз відповіді.
Відправка даних.
Отримання даних.
Аналіз та виконання.
Відповідь.
Спрощена модель системи
Концептуальна модель системи
Представлена модель представляє усі взаємозв’язки системи з сутностями та зовнішніми пристроями. А також основні функції, які виконує система.
Якість
Точність виконання операцій з підрахунком суми має бути до 2ох знаків, а для кількості до 3ох.
Продуктивність
Продуктивність системи залежить від швидкості пошуку товару, який не повинен тривати довше 200-350мсек., швидкості внесенню змін до чека (100мсек.), та швидкості оброблення інформації під час закриття чека (300-1100мсек.).
У випадку використання фіскального принтера на продуктивність системи впливає драйвер пристрою. Для такого випадку потрібно реалізувати драйвер обміну даних системи з принтером який одночасно з запитом видає результат виконання операції. Допускається затримка на виконання операції фіскальним пристроєм не більше ніж 1сек.,а також збільшення затримки на вимогу ФП під час виконання довготривалої операції. Збільшення затримки на необхідну кількість часу береться з протоколу самого принтера. Результат операції принтера виводиться на екран або цифрове табло для користувача і показує. Якщо фіскальний принтер не відповів на запит користувача тод...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора