Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Розробка програмного продукту. Етап формулювання вимог та побудова моделі
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Інститут комп’ютерних наук та інформаційних технологій
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2012
Тип роботи:
Звіт до лабораторної роботи
Предмет:
Технологія програмування та створення програмних продуктів
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет «Львівська політехніка»
Інститут комп’ютерних наук та інформаційних технологій
Кафедра АСУ
Звіт
до лабораторної роботи №1,2
Розробка програмного продукту.
Етап формулювання вимог та побудова моделі
з дисципліни
“ Технологія програмування та створення програмних продуктів ”
Завдання: Навчитись реалізовувати етап формулювання вимог та побудови модель при розробці програмного продукту комп’ютерних систем
1. Порядок виконання роботи
Ознайомитися з теоретичною частиною.
Отримати конкретне завдання.
Виконати реалізацію етапу формування вимог та побудувати модель у відповідності з завданням.
4. Оформити звіт за результатами виконаної роботи
2. Теоретична частина
Оскільки довільне ПЗ по суті являє собою алгоритм, записаний мовою, зрозумілою для комп'ютера, то програма має всі властивості, характерні для алгоритмів. Але програма є конкретною реалізацією алгоритму, призначеною для практичного використання, і властивості програм розглядають саме з цієї точки зору.
Можна виділяти такі вимоги до програм:
1. Правильність.
Програма повинна видавати правильні результати для будь-яких даних зі заздалегідь визначеного допустимого діапазону. Якщо програма є достатньо складною, навіть найбільш кваліфікований програміст навряд чи зможе з першого разу написати її без помилок. Ці помилки можуть бути найрізноманітніші: від суто механічних (забув поставити крапку з комою) до неналежного використання програмних конструкцій або навіть помилок в самому алгоритмі.
Помилки повинні бути виявлені та виправлені (цей процес називається відлагодженням). Крім того, необхідно переконатися на деяких тестових прикладах що програма працює правильно (цей процес називається тестуванням). Відомо, що саме на відлагодження і тестування припадає левова частка роботи над програмою
2. Ефективність.
Програма повинна видавати результати за прийнятний час і не бути надто ресурсомісткою. Різні програми, які призначені для вирішення однієї й тієї самої задачі, можуть мати різну ефективність і за інших рівних умов природно надавати перевагу більш ефективній програмі.
3. Надійність.
Користувач повинен довіряти програмі і не боятися її використовувати. Надійна програма повинна бути правильною; якщо ж залишаються помилки, то вони не повинні призводити до серйозних проблем. Самої лише правильності програми замало. Якщо користувач вводить неправильні дані, програма повинна повідомити його про це. Якщо програма сприймає неправильні дані і видає неправильні результати - це набагато гірше, ніж якщо вона взагалі не працює. За будь-яких умов використання програми не повинно призводити до фатальних, невиправних або важко виправних наслідків.
4. Універсальність.
Програма повинна бути розрахована на широкий діапазон вхідних даних і при можливості - на широкий спектр задач.
5. Функціональність.
Програма повинна забезпечувати всі основні потреби користувача і не реалізовувати можливостей, що є для нього непотрібними.
6. Зручність у використанні.
Програма повинна бути зручною в засвоєнні і використанні, а програмний інтерфейс повинен бути інтуїтивно зрозумілим. Відомо, що за останні десять років був зроблений величезний крок у цьому напрямку.
7. Стандартизованість.
Різні програмні продукти повинні мати однотипні засоби керування і однотипний інтерфейс для того, щоб користувач, який має досвід роботи з однією програмою, мав якнайменше незручностей при переході до іншої.
8. Переносимість.
Повинна забезпечуватися можливість перенесення програм з однієї машини на іншу без змін або з мінімальними змінами.
9. Читабельність.
Тексти програм повинні бути максимально простими для сприйняття і розуміння людиною.
10. Модифікованість.
Програма повинна передбачати можливість для змін і доповнень.
11. Документованість.
Кожна програма повинна супроводжуватися інструкціями щодо її використання і ці інструкції повинні бути доступними і зрозумілими. В самій програмі повинні використовуватися коментарі, які пояснюють суть самої програми та основних її елементів.
Життєві цикли програмного забезпечення.
Вимоги.
Визначення вимог - це форма основної загальної мови, що використовується для підготовчого спілкування з клієнтами.
Задоволення вимог - це структурована форма ясності вимог, що використовує загальну мову і базові структури.
Специфікація ПЗ - формальний опис вимог.
Формальна специфікація передбачає деталізовану декомпозицію вимог (використовуючи якусь форму), які можна буде легко зрозуміти і які не викликатимуть невизначеності.
Аналіз вимог є першим етапом розробки ПЗ, на якому вимоги замовника уточнюються, формалізуються і документуються. Фактично від цього етапу залежить успіх і на ньому треба відповісти на запитання: "Що повинен робити майбутній програмний продукт?".
Першочерговими вимогами до розроблюваного ПЗ визначаються такі:
сукупність умов, в яких передбачається використовувати майбутню систему (апаратні і програмні ресурси, які надаються системі, зовнішні умови її функціонування, список користувачів, персоналу і робіт, які мають відношення до цієї системи);
обмеження в процесі розробки ПЗ (директивні терміни завершення окремих етапів, наявні ресурси, організаційні заходи і процедури, що забезпечують захист інформації).
У компанії, що створює ПЗ для клієнта, аналітики мають прямий контакт з представниками клієнта. Часті інтерв'ю з представниками клієнта, які є в більшості випадків користувачами системи, призводять до формулювання всіх деталей вимог. Рекомендується, щоб одна людина з боку клієнта була відповідальна за комунікацію представників клієнта з аналітиками.
Основна помилка на цьому етапі полягає в зосередженості на типових ситуаціях і зневага виключеннями. І користувачі, і аналітики мають таку схильність.
Вимоги до ПЗ можуть бути розділені на два типи:
Функціональні вимоги. Вони описують функції (операції, дії) виконувані системою;
Нефункціональні вимоги. Вони описують обмеження функціональності.
Функціональні вимоги.
Функціональні вимоги описують функції, що виконуються системою. Вони можуть передбачати вимоги до зовнішніх систем для виконання.
Формальна примітка може усунути двозначність, але це може бути важким для сприйняття клієнта. Таким чином, вона може тільки закінчити неспеціалізований опис.
Зазвичай функціональні вимоги даються у формі очікуваного результату, а не у формі алгоритму. Опис є декларативним, але в деяких специфічних випадках необхідним є алгоритм.
Функціональні вимоги сформульовані, щоб визначити зовнішні зв'язки. Функції повинні бути відомі користувачам і іншим взаємодіючим системам. Під функціями системи ми не повинні розуміти тільки функції програми.
Техніка сходження вниз передбачає, що найзагальніші функціональні вимоги сформульовані і розділені по назві функції.
На практиці, клієнти не завжди розуміють або цікавляться загальними функціональними можливостями системи, а обговорюють специфічні функції, які потім об’єднуються аналітиком системи. Таку техніку називають технікою сходження вверх.
Більшість підходів використовує обидва методи. Аналітик системи повинен розглянути загальні функції спочатку, але він повинен також ввести інформацію, зібрану від користувачів. Таким чином операції розділення-об’єднання застосовуються в процесі визначення вимог.
Нефункціональні вимоги.
Нефункціональні вимоги описують обмеження та залежності, в яких виконуються функції. Ці вимоги можуть бути поділені на:
вимоги продукту, наприклад "можуть використовуватися тільки клавіатура і миша";
вимоги процесу, наприклад "система повинна виконуватися за стандартом XXA/2002" ;
зовнішні вимоги, наприклад "система повинна працювати з базою даних, описаною в документі YYYB/2001 і ніякі зміни в базі даних недопустимі".
Атрофовані вимоги повинні бути кількісними, тобто повинен існувати метод перевірки виконання умов. Такі вимоги як: "зручний", "надійний", "ефективний" не можуть бути перевірені, отже, вони не відповідають формулюванню.
Вимоги повинні міститися в документі з описом вимог, який повинен охоплювати:
введення - цілі, можливості і контекст системи. Ця частина містить результати стратегічного етапу;
опис розвитку системи - опис можливих змін;
опис функціональних вимог;
опис атрофованих вимог;
модель системи;
словник.
Доступність системи.
Програма повинна мати систему безпеки, яка встановлює доступ до системи для кожного користувача.
Чинниками успіху для функціонального формулювання вимог є:
робота з відповідними представниками клієнта;
повне розуміння вимог, розрізняння спеціальних випадків і виключень (типова помилка для цього етапу - зосередження на типових ситуаціях);
перевірка завершеності і послідовності вимог;
невеликий опис нефункціональних вимог.
Якісний опис вимог повинен задовольняти наступні вимоги:
бути повним і послідовним;
описувати зовнішній режим роботи;
описувати обмеження системи;
бути легким для модифікування;
брати до уваги можливі майбутні зміни;
описувати швидкодію системи в екстремальних або небажаних ситуаціях.
Рекомендації до правильних визначень.
Вимоги повинні бути сформульовані критично у порівнянні до існуючого ПЗ і прототипів.
Вимоги користувача повинні бути:
зрозумілими;
унікальними;
такими, щоб їх можна було перевірити;
точними;
реалістичними;
досяжними.
Найбільш важливі методи ідентифікації вимог:
зустрічі і огляди (Зустрічі повинні бути підготовлені у формі списку питань від різних сторін, що відносяться до даного проекту. Вони повинні проходити серед презентабельної групи користувачів, прагнучих до схвалення проекту);
вивчення існуючого ПЗ (Часто нове ПЗ замінює старе. Вивчення повинне визначати слабкі і сильні сторони старого ПЗ і погоджувати нові вимоги, якщо система повинна бути частиною старої);
вивчення досяжності (Повинні бути визначені реалістичні цілі і методи);
прототипування (Побудова прототипів систем з меншим об'ємом і спрощеним інтерфейсом).
Системні вимоги можуть бути документовані декількома способами. Можливі методи документування:
звичайна мова. Найчастіше використовується (Незручності в її невизначеності і гнучкості, що дає можливість описувати одне і те ж декількома шляхами. Зв'язки між різними вимогами не можуть бути визначені, і виникають суперечності);
математичний формалізм (Вживається давно);
структурована звичайна мова (Звичайна мова з обмеженим словником і семантикою. Предмети і проблеми описані в секціях і підсекціях);
таблиці, форми (Вимоги задані в таблицях (зазвичай дворівневі), асоційовані різними зв'язками (наприклад, таблиця з зв'язками типів користувачів з сервісами));
блоки і діаграми (Графічні форми, що зображують процеси);
контекстні діаграми (Показують системи, оточення, входи і виходи);
використання діаграм випадків (Концептуальна презентація того що відбувається і функцій).
Використання діаграм випадків з асоціативними документами вважається одним з кращих методів документування вимог. Простота спілкування поєднується з точністю виразів, необхідною для майбутньої роботи над системою.
Основні вимоги розділені на дві групи:
функціональні вимоги;
нефункціональні вимоги.
Функціональний опис вимог здійснює:
ідентифікація всіх типів користувачів системи;
ідентифікація всіх типів користувачів підтримки (адміністратори, клерки);
визначення кожного типу користувачів всіх системних функцій і шляхів використання системи;
опис зовнішніх систем (бази даних, Інтернету, різних мереж), що будуть використовуватися системою;
визначення організаційних структур, законодавства, стратегій, статусу, інструкцій, що прямо або непрямо описують функції.
Функціональні вимоги можуть бути сформульовані, використовуючи шаблони вимог.
Шаблон гарантує стандартне формулювання і полегшує завершення формулювання.
Таблиця 1. Функціональні вимоги.
Назва функції
Майстер обробки прибутку
Опис
Функція дозволяє редагувати прибуток платника податків заданого року
Вхідні дані
Дані про доходи, отримані з різних джерел, витрати на отриманий прибуток, податки на різні внески. Інформація про квитанції. Інформація та документи платника податків.
Джерело вхідних даних
Інформація податкової служби
Результат
Початкова умова
Прибуток = весь прибуток - витрати на отриманий прибуток. Весь прибуток, прибуток і витрати на отримання прибутку - всі джерела прибутку.
Кінцева умова
Така ж, як зазначено вище
Побічні ефекти
Змінення бази оподаткування
Причина
Функція дозволяє робити розрахунки швидше і без помилок
Нефункціональні вимоги
Опис вимог включає об’єкти, над яким будуть виконуватись функції:
вимога продуктів, наприклад, повинна бути доступна клавіатура;
вимога процесів, наприклад, процес планувальника повинен виконаються за стандартом XXXA/06;
зовнішні вимоги, наприклад, система планування повинна використовувати маркетингове відділення баз даних описане в документі YYYB/95. Ніяких змін до бази даних не застосовано.
Складові нефункціональних вимог:
Системні функції (ієрархія функцій, що виконуються системою);
Об’єм (скільки користувачів працюватимуть одночасно? скільки терміналів буде встановлено? скільки інформації буде збережено?);
Швидкість (час для виконання операції (або черги операцій), кількість операцій за одиницю часу, максимальний час виконання операції);
Точність (вимірювання масштабування і продуктивності, точність результату, заміна кількісних показників якісними);
Обмеження (обмеження інтерфейсу, якості, часових інтервалів, устаткування, засобів програмування і т.п.);
Інтерфейс зв'язку (тип мережі, протоколи, представлення мережі, рівень абстракції, протоколів і т.п.);
Програмний інтерфейс (специфікація устаткування, фізичні обмеження, продуктивність (швидкість процесора, пам'ять), вимоги до офісу (вологість, температура, тиск));
Програмний інтерфейс (сумісність з іншим ПЗ, ОС, мова програмування, компілятори, редактори, система управління базами даних (СУБД));
Перевірка вимог.
Типова помилка формування нефункціональних вимог - брак критеріїв, необхідних для перевірки вимог. Кожна нефункціональна вимога повинна бути перевірена. Це вимагає вибір критеріїв.
Таблиця 3. Критерії перевірки вимог.
Характеристика
Міра
Продуктивність
Кількість транзакцій за секунду Час відгуку
Розмір
Кількість записів у базі даних Потрібний розмір пам'яті
Зручність для користувача
Час, потрібний для навчання Розмір документації
Надійність
Вірогідність помилки трансакції
Час між виконаннями Доступність (час, коли програма доступна для користувача) Час перезавантаження програми після помилки Вірогідність втрати даних після помилки
Переносимість
Розмір платформозалежного коду Кількість платформ Вартість перенесення
Словник.
Будь-які терміни повинні бути зрозумілими всіма сторонами. Всі специфічні терміни повинні бути додані в словник. Всі невизначеності повинні бути уточнені.
Таблиця 5. Приклад словника.
Термін
Визначення
Синоніми
Банківський рахунок
Послідовність номерів, записаних через дефіс, що визначають ресурси та операції клієнта
рахунок
Клієнт
Одиниця апаратури, котра використовується клієнтом в офісі
робоча станція
Користувач
Особа, котра використовує програму для його/її власних цілей, що не мають відношення до адміністрації та обслуговуючого персоналу
Клієнт
…
…
…
Ключові чинники успіху етапу формулювання вимог є :
приведення прикладів клієнтові для роз'яснення неоднозначностей;
повна ідентифікація вимог, виявлення специфічних і виняткових вимог.
Модель.
Модель - це представлення якоїсь концепції реальності. На практиці завжди будують моделі різного типу: математичні моделі, фізичні, і т.д.
Модель дає змогу експериментувати: вносити зміни, додавати і видаляти частини і елементи. Вносити зміни до моделі набагато простіше, ніж в систему. Наслідки неправильних рішень зменшуються і їх простіше виявити перед тим, як вони завдадуть шкоди самій системі.
Розробники інформаційних систем під час проектування використовують наступні моделі:
модель вимог - описує способи використання;
аналітична модель - статика і динаміка системи, описуються мовою UML (деталями реалізації нехтують);
модель дизайну - описується мовою UML більш деталізовано (наприклад, присутні фізичні діаграми).
Дії на етапі аналізу.
Основними діями на етапі аналізу є:
визначення, пояснення, моделювання, специфікація і документування частин і проблем проекту;
визначення контексту проекту;
визначення вимог користувача;
визначення організаційних вимог;
інші рішення, наприклад, апаратні настройки, настройки ПЗ, фінансові обмеження, обмеження часу і т.п.
Сам аналіз не повинен робити якісь зміни, наприклад, введення таких нових елементів, як комп'ютерні системи. Мета аналізу - ідентифікувати всі аспекти, які можуть вплинути на форму, організацію і результати проекту.
Основними діями в ході аналізу є:
побудова статичних моделей класів;
аналіз функцій і випадків застосування;
перевірка класів і об'єктів;
розпізнавання і визначення методів і повідомлень;
моделі станів і діаграми їх змін;
моделі процесів і діаграми потоків даних;
управління потоком.
Ключовими чинниками успіху на фазі аналізу є:
участь представників клієнта;
повний і загальний підхід, без загострення уваги на деталях;
розгляд складних аспектів (безпека, масштабованість, оцінка об'єму і т.п.);
відповідність стандартам;
перевірка коректності і послідовності;
прозорість, логічність і послідовність документа.
На фазі аналізу будується логічна модель. Модель відповідатиме детальному і конкретному опису того, як повинна бути побудована система, щоб задовольняти сформульовані вимоги.
При створенні аналітичної моделі використовують наступні методології:
1. Структурні методи. Структурні методи комбінують статичний опис процесів і статичні моделі даних.
До цього класу моделей належать наступні підходи:
методи Yourdon (DeMarco і Ward/Mellon);
методологія структурного системного аналізу і дизайну (Structured System Analysis and Design Methodology, SSADM);
техніка структурного аналізу і дизайну (Structured Analysis and Design Technique, SADT).
Згідно з DeMarco, структурний аналіз використовує наступні методи:
словник баз даних;
схеми потоків даних;
структурована англійська мова;
таблиці вирішень;
дерева вирішень.
2.Інші методи:
схема перетворення;
діаграма зміни станів;
список подій;
схема даних;
перед- і післяумови;
діаграми відносин "сутність-зв'язок";
історія життя об'єкту.
Недолік використання структурного підходу – труднощі в об'єднанні моделей.
Моделі об'єктів.
Об'єктно-орієнтована методологія використовує базовий компонент на етапах аналізу і дизайну, тобто діаграма відносин класів – це розширення діаграми відносин "сутність-зв'язок". У діаграмах класів описуються класи, їх атрибути, методи, узагальнення, асоціації, агрегації, кількісні характеристики відносин і обмеження. Як допоміжні діаграми модель показує діаграми взаємодії, функціональні діаграми і т.д. Випадки використання описують структуру системи з точки зору користувача.
Для будь-якої мови її синтаксис, семантика і прагматика повинні бути проаналізовані.
Синтаксис – визначає способи ведення запису.
Семантика – визначає значення запису.
Прагматика – визначає способи і цілі застосування запису і використання шаблонів. Вона визначає процеси отримання результатів аналізу і дизайну у формі, яку вибрали автори. Прагматика незвичайно важлива для будь-якої методології. Реальні приклади зазвичай дуже складні, а наші приклади дуже часто здаються тривіальними.
Варіант індивідуального завдання.
Автоматизована система довідки кінотеатрів Львова
Постановка задачі
У теперішній час Інтернет - це невідємна частина нашого життя.Зараз у ньому працюють більш ніж 300 мільйонів людей.Інтернет - це в першу чергу,інформація.А той хто володіє інформацією- володіє світом. Інтернет дає нам унікальну можливість купувати одяг та їжу не відходячи від монітора комп’юера, замовляти квитки на літак і в кіно та й не тільки це.
Сьогодні автоматизовано вже майже всі сфери нашого життя та побуту. Це дає нам змогу ефективніше та продуктивніше використовувати власний час. Автоматизація мережі кінотеатрів значно покращить життя кіноманам, оскільки сидячи в себе в дома можна,попередньо придбати квиток на прем’єру нового фільму,чи подивитися трейлер,чи
почитати рекомендації – це буде можливо зробити просто на сайті.
Етап формулювання вимог
Програма оперує даними мережі кінотеатрів, змінює та доповнює інформацію про кількість та наявність вільних квитків, код клієнта, номер замовлення. Система ж знаходить потрібну інформацію дуже швидко, адже на сайті є багато різної інформації та велика кількість користувачів, які очікують на відповідь. Також система дозволяє постачальникам завантажувати описи фільмів і співпрацювати з кінотеатрами.
Користувач може отримати потрібну інформацію лише відвідавши сайт системи довідки кінотеатрів Львова. Тут можна проглянути розклад сеансів, вибрати фільм і навіть забронювати квитки. Інтерфейс системи є зручним, доступним та легким у користуванні. Будь-яка дія користувача супроводжується підказками.
Завдання системи
Система буде застосовуватись для автоматизації мережі кінотеатрів, що дасть змогу любителям кіно отримати всю необхідну інформацію вдома, а також для автоматизації продажу квитків та обліку кількості замовлень,та автоматизації постачання фільмів в кінотеатри.
Особливості програмного продукту
Основна особливість цієї системи полягає в тому, що програма успішно синхронізується з мережею кінотеатрів, веде облік кількості зроблених замовлень та надає користувачам необхідну інформацію,та надає можливість купувати та бронювати квитки,і постачальникам продавати продукт(фільми). Програма є сумісною з усіма операційними системами, а також має зручний інтерфейс як для користувача, так і для адміністратора. Ще однією особливістю цієї системи є різні режими роботи: звичайний користувач, гість, адміністратор, дирекція системи,постачальник. Під час користування програмою можна використовувати складений пошук, який дозволяє здійснювати пошук по назві фільму, читати короткий опис фільму та перегляди трейлер. Система призначена для роботи у локальній мережі та через Internet.
У випадку неправильної роботи адміністратор може завантажити свій режим і виправити яку-небудь інформацію, додати нові дані або видалити,або редагувати інтерфейс.
Умови роботи
Програма повинна мати доступ до Інтернету, щоб тримати зв'язок з базою даних, яка знаходиться на віддаленому сервері.
Система може працювати на таких операційних системах як : Windows XP, Windows 7 , Windows vista.
Для нормального користування системою швидкодія Інтернету повинна бути не меншою 512 Кбіт/сек.
Серед усіх функцій, які виконує система можна виділити загальні операції:
отримання інформації;
реєстрація інтернет клієнтів системи;
формування замовлення;
редагування замовлення:
бронювання квитків;
відмова від замовлення;
зміна кількості квитків;
оплата рахунку через банківську систему розрахунку;
підтвердження замовлення;
збереження всіх замовлень на сервері;
Перегляд звітів
Реєстрація постачальників
Логування
підтвердження замовлення прокату
Отримання трейлеру
Функціональні вимоги
Система потребує виходу в Інтернет і співпрацює з мережею кінотеатрів .
Підтримує різні режими:
Режим адміністратора. Адміністратор має свій логін, пароль. Він перевіряє чи коректно працює система,редагує інтерфейс.
Режим Гостя. Гість – це незареєстрований користувач, він має менше можливостей порівняно з зареєстрованим.
Режим Користувача. Користувач має свій логін, пароль і порядковий код. В цьому режимі можна замовляти і бронювати квитки.
Режим дирекції. Дирекція має свій логін, пароль.Він може переглядати статистику і баланс системи.
Режим Замовника.Замовник має свій логін і пароль.Він може надсилати різну інформацію,трейлери і дивитися рейтинг замовників.
користувач системи має змогу шукати відповіді на свої запитання, переглядати детальну інформацію про фільм, короткі трейлери та читати відгуки інших.
Замовлення квитків не можливе лише в режимі Гостя.
Дирекція кінотеатру має право підтвержувати ліцензії замовників.
Всі замовлення зроблені на сайті зберігаються в базі, куди має доступ і каса кінотеатру. Тобто ризик виникнення суперечностей між автоматизованою системою замовлення квитків і касою є мінімальним.
Система передбачає певний набір підказок в разі несправностей в роботі програми.
Нефункціональні вимоги
Вимоги до продукту:
Для користування програмою необхідно комп’ютер з можливістю виходу в Інтернет.
Сумісність з усіма відомими інтернет браузерами.
Система працює на усіх операційних системах.
Обмежений доступ до бази даних мають користувачі та дирекція і постачальники, а повний доступ до бази даних має лише адміністратор.
Інтерфейс розроблений за допомогою HTML.
Можливість одночасної роботи в системі ~20000 клієнтів .
Можливість одночасної обробки ~1500 запитів.
Система повинна працювати на операційній системі MS Windows
Швидкодія Інтернету повинна бути не меншою 512 Кбіт/сек.
Вимоги до процесу:
Використання HTTP/HTTPS протоколу
Реалізовано на мові програмування Delphi.
Використання протоколу HTTP/HTTPS.
Можливість одночасної роботи в системі ~ 20000 клієнтів.
Можливість одночасної обробки ~ 15000 запитів.
Зовнішні вимоги:
Доступ до мережі інтернет(~100 Мбіт/с)
Мова інтерфейсу – англійська, українська, російська.
Локальна мережа, вихід в Інтернет.
Об’єм
Можливість одночасної роботи в системі ~20000 клієнтів .
Кількість записів у базі даних товарів обмежена дисковим простором.
Швидкість
Можливість одночасної обробки ~ 1500 запитів.
Час на обробку інформації повинен відбуватися мінімум як за 0.02 с.
Час на обробку інформації не повинен перевищувати 0.1 с.
Інтерфейс зв'язку
Використання HTTP/HTTPS протоколу.
Апаратні засоби
Апаратна частина серевера:
Процесор 2.4 GHz
Вінчестер 4Tb
Відео карта 1024 Mb
Оперативна память DDR 3 4Gb 1667 MHz
Вимоги до офісу:
Температура повітря,0С – 22-25
Вологість повітря, % – 40-60
Вимоги до клієнтського компютера:
Локальна мережа , вихід в Інтернет.
Процесор Intel Pentium II 800 MHz
Вінчестер 10GB
Відеокарта 64 Mb
Оперативна память DDR 128MB
Мережева карта: ASUS NX1101 10/100M
Монітор
Клавіатура
Мишка
Вимоги до мережі:
Швидкодія Інтернету повинна бути не меншою 512 Кбіт/сек.
Програмний інтерфейс
Сумісність з усіма браузерами.
Повинна бути незалежною від операційної системи.
Програмна чатина сервера:
Microsoft SQL server 2008 SP1
Java Virtual Machine.
Взаємодія людини з системою
Для роботи користувача з сайтом достатньо виходу в Інтернет.
Програма повинна швидко і без затримок шукати необхідний інформацію в базі даних.
Гнучкість
Внаслідок помилок з живленням уся система втратить тільки ті дані, які не завершили транзакції.
Ресурси
Обмеження строго по бюджету 100 000 грн.
Час
4 місяців на розробку системи :
1 тиждень планування.
2 місяці написання коду.
1 місяць тестування.
1 тиждень написання документації.
1 тиждень установка.
6 днів тренування.
Користувачі програми
Найчастіше цю програму використовують інтернет–клієнти, які бажають отримати інформацію стосовно розкладу сеансів, наявності квитків чи хочуть забронювати (замовити) квиток на той чи інший фільм або постачальники які хочуть продати фільм.
Дирекція має змогу переглядати інформацію, яка знаходиться на сайті, коректувати, вносити поправки і доповнення. Тобто є допоміжним користувачем програми.
Допоміжним користувачем програми є також особа, яка може налаштувати програму і виправити всі помилки в разі її неправильної роботи - адміністратор.
Словник термінів
Термін
Визначення
Кінотеатр
Це авторизоване місце продажу квитків та показу фільмів.
Інтернет користувач
Це користувач, який може отримати необхідну інформацію про фільм, розклад сеансів, наявність знижок та замовити квиток на сеанс за допомогою інтернету.
Дирекція кінотеатру
Особа, яка має доступ до всієї інформації на сайті, може вносити туди зміни (редагувати, видаляти, добавляти) та перевіряти коректність всіх даних.
Квиток
Результат операції продажу. Тут вказується назва фільму, № ряду та місце, ціна, дата продажу. Лише за наявності квитка можна потрапити на сеанс.
Замовлення
Інтернет користувач має змогу придбати квиток через інтернет. Для цього потрібно лише вказати системі всі необхідні дані та оплатити. Після чого система формує замовлення і вносить зміни в базу даних
Інтернет
Всесвітня організація комп’ютерних мереж.
Адміністратор
Особа, яка може налаштувати систему в разі необхідності і має доступ до всіх функцій системи.
Тре́йлер
В01040501000801ідеоролик, який складається з коротких і зазвичай найбільш видовищних фрагментів 0410180фільму для його анонсування або реклами. Відеоряд з незв'язаних фрагментів і сцен за принципом калейдоскопа іноді змінюються дуже швидко: більше справляють враження на глядача, ніж залишають осмислене уявлення про 0410180фільм.
Постачальник
Фірма або агент промислового підприємства, які здійснюють реалізацію продукції й виступають як торгівці за договором на основі угоди про право на продаж в окремому регіоні.
Прокат
масовий показ фільмів у мережі кінотеатрів.
Ліцензія
це документ, що демонструє певний дозвіл.
Статистика
збирання інформації, перевірка її якості, її інтерпретація, зображення статистичного матеріалу
Завантаження
Показник оцінки популярності
Модель функціонування системи
Модель функціонування системи показує взаємодію всіх класів користувачів (адміністратор, дирекція , постачальники, інтернет користувачі) із автоматизованою системою.
Ця модель показує взаємодію користувачів з автоматизованою системою довідки кінотеатрів.
Користувач
Потік повідомлень
Система
Запит інформації про фільми
Реєстрація в системі
Замовлення квитків
Зміна кількості квитків в замовленні
Оплата
Перегляд трейлера
Запит на логування
Ключові слова для пошуку
Логін, пароль
Критерії відбору
Нова кількість квитків
Номер кредитної картки
Ключові слова для пошуку
Логін, пароль
Пошук в базі даних
Перевіряє коректність даних
Перевірка наявності, фіксування замовлення в системі
Редагує вміст замовлення, фіксування в системі
Перевірка картки, формується рахунок
Пошук в базі даних
Перевірка логіну і паролю.
Ця модель показує взаємодію автоматизованої системи довідки кінотеатрів із користувачами.
Система
Потік повідомлень
Користувач
Інформація про фільми
Логінування/авторизація користувача
Квиток
Замовлення з потрібною кількістю квитків
Рахунок
Перегляд трейлеру
Підтвердження\відмова від реєстрації
Повідомлення
Повідомлення з підтвердженням
Повідомлення
Повідомлення
Повідомлення
файл
Повідомлення
Отримання інформації про фільми
Вхід в систему
Електронний квиток
Підтвердження зміни кількісті квитків, електронний квиток
Чек
Відображення трейлера
Дозвіл\відмова на реєстрацію в системі
Ця модель показує взаємодію мережі кінотеатрів із системою
Постачальник1…ПостачальникN
Потік повідомлень
Система
Реєстрація в системі
Надсилання інформації про фільми
Надсилання інформації про умови прокату
Надсилання трейлера
Реєстрація ліцензії
Запит на логування
Запит на рейтинг
Логін, пароль
Файл з даними
Файл з даними
файл
дані ліцензії
Логін, пароль
Критерій постачальників
Перевіряє коректність даних
Зберігання в базі даних
Зберігання в базі даних
Зберігання в базі даних
Перевіряє коректність даних
Перевірка логіну і паролю
Генерування рейтингу
Ця модель показує взаємодію системи з постачальниками.
Система
Потік повідомлень
Постачальник1…ПостачальникN
Підтвердження\відмова від реєстрації Логінування/авторизація користувача
Підтвердження\відмова
інформації про фільми
Підтвердження\відмова
інформації про умови прокату
Підтвердження\відмова
реєстрації ліцензії
Завантаження трейлера
Повідомлення
Повідомлення
Повідомлення
Повідомлення
Повідомлення
інформація
Повідомлення
Дозвіл\відмова на реєстрацію в системі
Дозвіл\відмова на вхід в систему
Отримання\ неотримання інформації про фільми
Отримання\ неотримання інформації про умови прокату
Дозвіл\відмова реєстрації ліцензії
Отримання рейтингу
Отримання\ неотримання трейлера
Ця модель показує взаємодію адміністратора з системою.
Адміністратор
Потік повідомлень
Система
Зміна інтерфейсу сайту
Редагування бази даних
Надання і зняття статусу користувачу
Запит на логування
Запит на створення опитування
Запит на перегляд статистики
Запит на створення групи
Внесення змін
Нові дані
Користувач, статус
Логін, пароль
Інформація опитування
Критерій статистики
Назва групи
Збереження внесених змін
Зміна в базі даних, збереження змін
Зміна статусу
Перевірка логіну і паролю
Перевірка інформації та створення опитування
Перевірка інформації та створення статистики
Перевірка назви та створення групи.
Ця модель показує взаємодію системи з адміністратором
Система
Потік повідомлень
Адміністратор
Новий інтерфейс системи
Оновлена база даних
Новий статус
Логінування/авторизація користувача
Підтвердження створення опитування або відмова.
Підтвердження створення
статистики або відмова
Підтвердження створення групи або відмова
Повідомлення
Повідомлення
Файл з даними
Повідомлення
Інформація
Інформація
Інформація
Підтвердження зміни інтерфейсу
Підтвердження зміни бази даних
Список користувачів
Дозвіл\відмова на вхід в систему
Створення опитування думки або відмова
Створення статистики думки або відмова
Створення групи або відмова
Ця модель показує взаємодію дирекції кінотеатру з системою.
Дирекція кінотеатру
Потік повідомлень
Система
Реєстрація в системі
Запит інформації про користувачів
Запит інформації про фільми
Запит на логування
Запит на перегляд ліцензії
Запит на перегляд статистики
Запит на перевірку балансу системи
Логін, пароль
Ключові слова для пошуку
Критерій пошуку
Логін, пароль
Вибір постачальника
Критерій статистики
Період
Перевіряє коректність даних
Пошук в базі даних
Пошук в базі даних
Перевірка логіну і паролю
Пошук в базі даних
Перевірка інформації та створення статистики
Створення балансу
Ця модель показує взаємодію системи з дирекцією кінотеатру
Система
Потік повідомлень
Дирекція кінотеатру
Логінування/авторизація користувача
Інформація про користувачів
Інформація про фільми
Підтвердження\відмова від реєстрації
Інформація про ліцензію
Статистика
Баланс системи
Повідомлення
Файл з даними
Файл з даними
Повідомлення
Файл з даними
Інформація
Файл з даними
Вхід в систему
Отримання інформації про користувачів
Отримання інформації про фільми
Дозвіл\відмова на реєстрацію в системі
Отримання інформації про ліцензію
Отримання статистики
Отримання балансу системи
Концептуальна модель системи
Спрощена модель системи
Якість
Порівняно з іншими програмними продуктами система виконує швидкий пошук по
назві фільму (показує користувачу коли і в яких кінотеатрах є сеанси), дає змогу робити замовлення чи відмовлятися від нього, дозволяє читати відгуки користувачів стосовно того чи іншого фільму. Також дає доступ постачальникам які можуть завантажувати різного роду інформацію про фільм і пропонувати свої послуги кінотеатрам. Ймовірність неправильної роботи програми є дуже маленькою, а вся інформація по квитках зберігається в базі даних і не може пошкодитись.
Продуктивність
Продуктивність системи залежить від швидкості пошуку необхідної користувачу інформації, який не повинен тривати довше 200-350 мс, швидкості процесу замовлення квитків (200 мс), швидкості внесення змін до замовлення (100 мс) та швидкості оброблення інформації під час закриття замовлення (300-1100 мс).
Відношення з іншими програмами
Система працює на всіх операційних системах.
Ресурси
Для нормальної роботи системи достатньо таких мінімальних засобів як:
Апаратні засоби комп’ютера:
Процесор 2.4 GHz
Вінчестер 4Tb
Відео карта 1024 Mb
Оперативна память DDR 3 4Gb 1667 MHz
Програмні засоби:
Microsoft SQL server 2008 SP1
Java Virtual Machine
Необхідною є можливість виходу в Інтернет (~100 Мбіт/с)
Підтримка
Досить часто з’являється необхідність вносити в систему нові дані, які система повинна відображати (новинки, прем’єри фільмів), інколи ж потрібно внести поправки до вже існуючої інформації . Це входить в обов’язки постачальника і дирекції.
Захист
Для того, щоб максимально захистити систему від необережних дій користувача потрібно передбачити вхід в систему під паролем. Кожен користувач зможе виконувати тільки ті функції, які передбачені для нього розробниками. Це забезпечить різні рівні доступу до системи. Якщо ж користувач виконає запит на виконання недозволеної йому функції, то система висвітлить вікно, де потрібно ввести пароль адміністратора.
13.02.2013 23:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора