Розробка елементів автоматизованого робочого місця менеджера компанії "Віконда"

,(2.33)

де Р - точка замовлення (у натуральному виразі);

S - середній ритм попиту (середній добовий збут);

L - тривалість циклу (час доставки товару);

Y - страховий запас.

Ця формула описує роботу з фіксованим розміром замовлення.

Крім вищенаведених міркувань, метод статистичної точки замовлення має сенс застосовувати при відносно стабільному попиті на продукцію, запаси якої управляються за допомогою цього методу.

Метод періодичного огляду є іншою можливістю управління запасами продукції класу С. Відміна його від статистичної точки замовлення полягає в тому, що розміщення замовлення на поповнення запасу (виробничого або на закупівлю) проводиться не тоді, коли досягнутий певний рівень запасу (як у випадку із статистичною точкою замовлення), а при настанні певного моменту часу.

Обирається інтервал між перевірками величини складського залишку, і в кінці кожного такого інтервалу проводиться контроль рівня запасу. На підставі даних про цей рівень і встановлену величину максимального розміру замовлення виконується розрахунок розміру замовлення, яке слід розмістити.

Формули розрахунку розміру замовлення і максимального рівня запасу виглядають таким чином:

,(2.34)

, (2.35)

де, n - розмір замовлення;

М - максимальний рівень запасу;

І - величина запасу на момент огляду;

R - період часу між оглядами.

Решта позначень ті ж, що і у формулі розрахунку статистичної точки замовлення.

Як і метод статистичної точки замовлення, метод періодичного огляду має сенс застосовувати при відносно стабільному характері попиту на продукцію.

Нарешті, останніми у ряді методів планування поповнення запасів слід згадати найпростіші методики, засновані на візуальному контролі рівня запасів. Методи візуального огляду в основному доцільно застосовувати для управління запасами недорогих недефіцитних товарів, що легко піддаються візуальному контролю, для яких некритичний об'єм запасів, що перевищує мінімальну величину, з одного боку, і невеликі втрати від відсутності цієї продукції в необхідний момент часу.

Головною проблемою, яка повинна бути вирішена при встановленні політики управління запасами, є обчислення розміру страхового запасу. Якщо страховий запас дуже малий, то виникатиме часта недостача товару, якщо великий, то фірма матиме надмірні витрати.

Математичними методами було доведено, що страховий запас пов'язаний лише з математичним очікуванням і середнєквадратичним відхиленням, і визначається як

,

де - середнєквадратичне відхилення;

k - деякий коефіцієнт, що приймає значення при нормальному розподілі від 1 до 3, тобто:

1, попит перевищує Р лише на протязі 17% часу;

k= 2, попит перевищує Р лише на протязі 2,5% часу;

3, попит перевищує Р лише на протязі 0,5% часу.

Розмір страхового запасу Y встановлюється шляхом вибору такого коефіцієнта до, при якому вірогідність того, що попит перевищить точку замовлення Р, має задане фіксоване значення. В цьому випадку дефіцит може з'явитися лише протягом проміжку, на який затримується виконання замовлення.

Якщо подвоїти розмір замовлення n, то число замовлень скоротитися удвічі і зменшується час, протягом якого можлива поява дефіциту. Оскільки розмір страхового запасу Y встановлюється незалежно від розміру партії замовлення, фактичний рівень обслуговування змінюватиметься при зміні n.

Таким чином, формула розрахунку страхового запасу базується не на загальному рівні обслуговування, а на рівні обслуговування в проміжку часу, в якому можливо поява дефіциту. Наприклад, встановлюючи k=3 для товару, який замовляється лише три рази на рік і час доставки якого рівно двом тижням, одержуємо, що за рік дефіцит може з'явитися лише на протязі 3x2=6 тижнів. Повна вірогідність дефіциту дорівнює:

і фактичний рівень обслуговування складе 99,94%. (52 - число тижнів в році). Для інших розподілів вірогідність дефіциту матиме інші значення.

3. ОСОБЛИВОСТІ ВИКОРИСТАННЯ МОВИ SQL ПРИ РОЗРОБЦІ ІНФОРМАЦІЙНИХ СИСТЕМ

3.1 Історія розвитку і основні концепції мови SQL

Всі мови маніпулювання даними (ММД), створені до появи реляційних баз даних і розроблені для багатьох систем управління базами даних (СУБД) персональних комп'ютерів, були орієнтовані на операції з даними, представленими у вигляді логічних записів файлів. Це вимагало від користувачів детального знання організації зберігання даних і достатніх зусиль для вказівки не тільки того, які дані потрібні, але і того, де вони розміщені і як крок за кроком одержати їх.

Непроцедурна мова SQL (Structured Query Language - структурована мова запитів), що розглядається ж нижче, орієнтована на операції з даними, представленими у вигляді логічно взаємозв'язаних сукупностей таблиць. Особливість пропозицій цієї мови полягає в тому, що вони орієнтовані більшою мірою на кінцевий результат обробки даних, чим на процедуру цієї обробки. SQL сам визначає, де знаходяться дані, які індекси і навіть які найбільш ефективні послідовності операцій слід використовувати для їх отримання: не треба указувати ці деталі в запиті до бази даних.

Для ілюстрації відмінностей між ММД розглянемо наступну ситуацію. Хай, наприклад, ми збираємося подивитися кінофільм і хочемо скористатися для поїздки в кінотеатр послугами таксі. Одному шоферу таксі досить сказати назву фільму - і він сам знайде вам кінотеатр, в якому показують потрібний фільм. (Подібним же чином, самостійно, відшукує запитані дані SQL.)

Для іншого шофера таксі нам, можливо, буде потрібно самому дізнатися, де демонструється потрібний фільм і назвати кінотеатр. Тоді водій повинен знайти адресу цього кінотеатру.

Може трапитися і так, що нам доведеться самому дізнатися адресу кінотеатру і запропонувати водію проїхати до нього по таких-то і таких-то вулицях. У найгіршому випадку нам, можливо, навіть доведеться по дорозі давати вказівки: "Повернути наліво... проїхати п'ять кварталів... повернути направо...". (Аналогічно більший або менший рівень деталізації запиту доводиться створювати користувачу в різних СУБД, що не мають мови SQL.)

Поява теорії реляційних баз даних і запропонованої Коддом мови запитів "alpha", заснованої на реляційному численні, ініціювало розробку ряду мов запитів, які можна віднести до двох класів:

Мови, алгебри, що дозволяють виражати запити засобами спеціалізованих операторів, вживаних до відносин (JOIN - з'єднати, INTERSECT - перетнути, SUBTRACT - відняти і т.д.).

Мови числення предикатів є набором правил для запису виразу, що визначає нове відношення із заданої сукупності існуючих відносин. Іншими словами числення предикатів є метод визначення того відношення, яке нам бажано одержати (як відповідь на запит) з відносин, вже наявних в базі даних.

Розробка, в основному, йшла у відділеннях фірми IBM (мови ISBL, SQL, QBE) і університетах США (PIQUE, QUEL). Останній створювався для СУБД INGRES (Interactive Graphics and Retrieval System), яка була розроблена на початку 70-х років в Університеті шт. Каліфорнія і сьогодні входить в п'ятірку кращих професійних СУБД. Сьогодні зі всіх цих мов повністю збереглися і розвиваються QBE (Query-By-Example - запит за зразком) і SQL, а з інших узяті в розширення внутрішніх мов СУБД тільки найцікавіші конструкції.

На початку 80-х років SQL "переміг" інші мови запитів і став фактичним стандартом таких мов для професійних реляційних СУБД. У 1987 році він став міжнародним стандартом мови баз даних і почав упроваджуватися у всі поширені СУБД персональних комп'ютерів. Чому ж це відбулося?

Безперервне зростання швидкодії, а також зниження енергоспоживання, розмірів і вартості комп'ютерів привели до різкого розширення можливих ринків їх збуту, круга користувачів, різноманітності типів і цін. Природно, що розширився попит на різноманітне програмне забезпечення.

Борючись за покупця, фірми, що створюють програмне забезпечення, стали випускати на ринок все більш і більш інтелектуальні і, отже, об'ємні програмні комплекси. Багато організацій і окремі користувачі часто не могли розмістити їх на власних ЕОМ, проте не хотіли і відмовлятися від нового сервісу. Для обміну інформацією і її обміну були створені мережі ЕОМ, де програми і дані стали розміщувати на спеціальних обслуговуючих пристроях - файлових серверах.

СУБД, що працюють з файловими серверами, дозволяють безлічі користувачів різних ЕОМ (іноді розташованих достатньо далеко один від одного) діставати доступ до одних і тих же баз даних. При цьому спрощується розробка різних автоматизованих систем управління організаціями, учбових комплексів, інформаційних і інших систем, де безліч співробітників повинні використовувати загальні дані і обмінюватися створюваними в процесі роботи (навчання). Проте при такій ідеології вся обробка запитів з програм або з терміналів призначених для користувача ЕОМ виконується на цих же ЕОМ. Тому для реалізації навіть простого запиту ЕОМ часто повинна прочитувати з файлового сервера і (або) записувати на сервер цілі файли, що веде до конфліктних ситуацій і перевантаження мережі.

Для виключення вказаних і деяких інших недоліків була запропонована технологія клієнт-сервер, по якій запити призначених для користувача ЕОМ (Клієнт) обробляються на спеціальних серверах баз даних (Сервер), а на ЕОМ повертаються лише результати обробки запиту. При цьому, природно, потрібна єдина мова спілкування з Сервером і як така мова вибрана SQL. Тому всі сучасні версії професійних реляційних СУБД (DB2, Oracle, Ingres, Informix, Sybase, Progress, Rdb) і навіть нереляційних СУБД (наприклад, Adabas) використовують технологію клієнт-сервер і мову SQL.

Існує думка: Оскільки велика частина запитів формулюється на SQL, практично байдуже, що це за СУБД - був би SQL.

Реалізація в SQL концепції операцій, орієнтованих на табличне представлення даних, дозволило створити компактну мову з невеликим (менше 30) набором операторів. Мова SQL може використовуватися як інтерактивна (для виконання запитів) і як вбудована (для побудови прикладних програм).

На рис. 3.1 показана схема, що відображає принцип використання SQL. Користувач передає запит інтерпретатору, який, у свою чергу, повертає уявлення, таблицю або курсор. Ці об'єкти знаходяться на так званому віртуальному рівні і формуються тільки за запитом. Але вони взаємодіють з реальним рівнем, тобто з таблицями баз даних, на основі яких відбувається формування віртуальних об'єктів. Звичайно, дане розділення є умовним, але воно добре відображає ідеологію SQL.

Рис. 3.1 Схема взаємодії з базою даних за допомогою SQL

3.2 Структура запитів до окремих таблиць

Достатньо поширеним є завдання отримання даних з однієї або декількох таблиць і формування на їх основі яких-небудь звітів. У даному розділі будуть викладені базові поняття SQL і способи створення відповідних запитів.

3.2.1 Оператор SELECT

Оператор SELECT є виразом, що ініціює виконання запиту. В даному випадку запит є командою на отримання даних. Вираз SELECT має строго певний формат:

SELECT [[ALL] | DISTINCT]{ * | елемент_SELECT [.елемент _SELECT] ...}

FROM{ базова_таблиця | уявлення} [псевдонім]

[.{ базова_таблиця | уявлення} [псевдонім]]

[WHERE умова]

[GROUP BY назва поля (полів) [HAVING фраза]]:

3.2.2 Вибірка по умові

Вибірку по умові реалізує оператор WHERE. Оператор є частиною виразу SELECT і служить для завдання умов відбору записів в результуючий набір. В ході виконання запиту відбувається перевірка всіх записів на відповідність умові відбору. Як приклад можна привести досить простий запит:

SELECT State,City,Company FROM Customer

WHERE State = 'CA'

При обробці запиту був похідний відбір всіх записів, поле State яких має значення СА.

Можна провести вибірку по співпадаючих значеннях полів. Наприклад, необхідно знайти компанії, в яких телефон і факс мають один і той же номер. Умова запиту в цьому випадку буде досить простим:

SELECT Company,Phone,Fax FROM Customer

WHERE Phone = Fax

Виключення значень, що повторюються

Для отримання результатів без значень, що повторюються, використовується оператор DISTINCT. Наприклад:

SELECT DISTINCT Country FROM Customer

Обчислювані поля

Автоматичне обчислення значень полів досить часто застосовується в найрізноманітніших запитах. Приклад відповідного запиту виглядає досить просто:

SELECT OnHand,OnOrder,(OnHand*OnOrder) AS

Твір, (OnHand+OnOrder) AS Сума FROM Parts

У даному прикладі проводиться перемножування і підсумовування значень полів OnHand і OnOrder.

Ті ж дії з полями можуть бути проведені з використанням числових констант. Оператор AS привласнює даному полю інше ім'я, яке буде використане в результуючому наборі.

Запит SELECT може також включати числові і текстові константи. Як приклад можна привести наступний запит:

SELECT OnHand,OnOrder,'MUL',(OnHand + 1) AS Плюс,'SUB',(OnHand - 1) AS Мінус FROM Parts

У лапках вказані текстові константи, які будуть включені в результуючу таблицю як значення відповідних полів.

Оператори порівняння і логічні оператори

Реляційним оператором називають математичний символ, який указує на певний тип порівняння між двома значеннями. Реляційні оператори, або оператори порівняння, можуть використовуватися для визначення того, чи відповідає дане значення якому-небудь діапазону.

Логічні оператори дозволяють задати в запиті логічні умови. Оператор AND реалізує логічне “І”. Оператор OR реалізує логічне “АБО”. Вираз з його використанням, вважатиметься істинним, якщо хоч би одна з умов теж є істиною. Оператор NOT означає логічне заперечення. Його дія зводиться до того, що він інвертує логічну умову, перед якою його розташовують.

Як приклад можна привести запит, що дозволяє вибрати співробітників, одержуючих заробітну платню в певному чисельному проміжку. Дані витягуватимуться з таблиці Employee:

SELECT LastName, FirstName, Salary FROM Employee

WHERE Salary >= 25000 AND Salary <= 30000

В результаті виконання запиту повертаються імена співробітників із заробітною платнею від 25 до 30 тисяч включно. В даному випадку оператор AND використовується для завдання діапазону вибираних значень.

Тепер можна змінити даний запит. Можна відшукати всіх співробітників, для яких окрім приведених вище умов поле PhoneExt яких має значення 22:

SELECT LastName, FirstName, Salary, PhoneExt FROM Employee

WHERE Salary >= 25000 AND Salary <= 30000 and PhoneExt = '22'

Якщо ж потрібно буде відшукати співробітників, поле PhoneExt яких має значення, не рівне 22, запит буде трохи змінений:

SELECT LastName, FirstName, Salary, PhoneExt FROM Employee

WHERE Salary >= 25000 AND Salary <= 30000 and not PhoneExt = '22'

Як видно з тексту запиту, логічна умова NOT дозволила виключити непотрібні номери.

Тепер можна розглянути приклад запиту з використанням оператора OR. Припустимо, менеджеру знадобилося одержати списки всіх співробітників по прізвищу Johnson. Або тих співробітників, які одержують заробітну платню більше 45 000. Скласти запит буде неважко:

SELECT LastName, FirstName, Salary FROM Employee

WHERE LastName = 'Johnson' or Salary > 45000

Варто звернути увагу на дію оператора 0R. У набір даних були включені записи, значення поля Salary яких перевищувало 40 000, і ті записи, в яких поле LastName мало значення Johnson.

Використання оператора IN

Оператор IN визначає масив значень, в який може входити або не входити значення поля даного запису. Наприклад, необхідно вибрати співробітників із заробітною платнею 40 000, 55 500 і 25 000. Запит потрібно буде переробити:

SELECT LastName, FirstName, Salary FROM Employee

where Salary = 40000 or Salary = 55500 or Salary = 25000

Проте цей же запит можна написати в коротшій і красивішій формі за допомогою оператора IN:

SELECT LastName, FirstName, Salary FROM Employee

where Salary IN (40000, 55500, 25000)

Як аргументи оператору IN були передані значення полів, по яких проводився відбір записів.

Оператор IN може використовуватися і для пошуку символьних значень. Припустимо, нам необхідно з'ясувати назви компаній, що знаходяться в містах Christiansted, Grand Cayman і St. Thomas. Ці дані міститися в таблиці Customer. Запит знову знадобиться трохи змінити:

SELECT Company, City FROM Customer

WHERE City IN (`Christiansted','Grand Cayman','St.Thomas')

Використання оператора BETWEEN

Оператор BETWEEN використовується для вказівки діапазону значень, які використовуються для установки умови відбору записів. Цей оператор чутливий до порядку переліку параметрів, що визначають межі діапазону. Як приклад можна привести простий запит:

SELECT CustomerID, EmployeeID, ShipName FROM Orders

WHERE EmployeeID BETWEEN 3 AND 5

В результаті виконання запиту були вибрані записи, значення поля EmployeeID, яких знаходяться в проміжку від трьох до п'яти включно.

Наступний приклад показує, як можна вибрати номери замовлень, зроблених за певний проміжок часу від 04.07.1996 до 08.07.1996:

SELECT OrderlD, OrderDate, ShipName FROM Orders

WHERE OrderDate BETWEEN '07.04.1996' AND '07.08.1996'

Припустимо, вимоги змінилися. Тепер необхідно вибрати ті номери замовлень, які не потрапляють у вказаний проміжок часу і вага вантажу в яких складає більше ста одиниць. В цьому випадку запит виглядатиме наче:

SELECT OrderID, OrderDate, ShipName, Freight FROM Orders

WHERE OrderDate NOT BETWEEN '07.04.1996' AND '07.08.1996' AND Freight > 100

Використання оператора LIKE

Оператор LIKE використовується для вибору всіх записів, в які входить підрядок, вказаний як параметр. Як умову оператор також приймає спеціальні символи. Символ підкреслення замінює будь-який одиночний символ, а знак відсотка позначає будь-яку кількість символів.

Припустимо, необхідно вибрати компанію, в назві якої не вистачає декількох букв. В цьому випадку назву можна позначити як S?mons?bistro. Відповідний запит використовуватиме вказаний оператор LIKE:

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE 'S_rnons_bistro'

Можна скласти запит, в якому проводитиметься пошук якогось підрядка, що входить в запис. Припустимо, що необхідно знайти всі компанії, в назвах яких зустрічається послідовність символів “ric”.

Задачу вирішує нескладний запит

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE `%Ric%'

Можна розширити умови відбору даних. Припустимо, що необхідно знайти всі компанії, в назві яких зустрічається поєднання символів `г?с', тобто символ у середині підрядка невідомий.

SELECT CompanyName, ContactName FROM Customers

WHERE CompanyName LIKE `%R c%'

3.2.3 Агрегатні функції

В деяких випадках потрібно в самому запиті провести обчислення значень полів, одержати кількість знайдених записів, провести пошук максимального значення поля або виконати іншу обчислювальну роботу. Функції, що реалізують ці можливості, називаються агрегатними. Агрегатні функції повертають одне значення для всього поля таблиці. Список агрегатних функцій приведений нижче:

· Оператор COUNT повертає кількість записів, що задовольняють умові запиту.

· Оператор SUM підсумовує значення записів поля.

· Оператор AVG обчислює середнє значення записів поля.

· Оператор МАХ повертає найбільше значення даного поля.

· Оператор MIN повертає найменше значення даного нуля.

Агрегатні функції використовуються подібно до імен полів в запиті, а справжні імена полів передаються їм як аргументи. З операторами SUM і AVG можуть використовуватися тільки числові поля. З операторами COUNT, MAX і MIN можуть використовуватися числові і символьні поля. У разі застосування функцій МАХ і MIN до символьних полів їх значення будуть трансльовані в ASCII-код. Мінімальному значенню функції відповідатиме символ алфавіту, що знаходиться ближче до його початку, максимального, -- що знаходиться ближче до кінця.

Нижче приведений запит, що вибирає з таблиці Orders середнє значення ваги вантажу з поля Freight, мінімальне значення ваги вантажу, максимальне значення ваги вантажу, його сумарне значення і кількість вантажів, вага яких складає більше трьохсот одиниць.

SELECT AVG(Freight) AS Середнє, MIN(Freight) AS Мін, MAX(Freight) AS Макс, SUM(Freight) AS Сумарне, COUNT(Freight) AS Кількість FROM Orders

WHERE Freight >300

Функція COUNT робить підрахунок всіх записів. Для того, щоб виключити повтори, слід використовувати оператора DISTINCT. Цей оператор розташовується перед назвою поля, усередині функції COUNT. Запит, демонструючий цей механізм, показаний нижче:

SELECT COUNT(DISTINCT City) AS Кількість_міст FROM Customers

В ході виконання запиту з оператором DISTINCT було зафіксовано 69 записів. Без використання оператора -- 91. Для виключення повторів при використанні функцій AVG і SUM теж може бути використаний цей оператор.

Оператор GROUP BY використовується для визначення полів, до яких можуть застосовуватися агрегатні функції. У випадку, якщо цей оператор явно не вказаний, всі поля, вказані у виразі SELECT, трактуються як аргументи агрегатних функцій. Поля, вказані як параметри оператора GROUP BY, стають такими, що групуються. Всі записи результуючого набору, що мають однакові значення групуючих полів, утворюють єдину групу. Далі до кожної такій групі буде застосована агрегатна функція. Фактично, оператор GROUP BY дає можливість об'єднувати поля і агрегатні функції в єдиному запиті.

Ілюструє вищесказане запит, що відшукує міста, в яких розташовані фірми, кількість цих міст і максимальне значення поштового індексу для фірми, розташованої в даному місті:

SELECT City, COUNT(*) AS Кількість, MAX(PostalCode) AS Почтовий_індекс FROM Customers GROUP BY City

Легко відмітити, що поле City не входить в агрегатну функцію як параметр, тому його було оголошено з використанням оператора GROUP BY. В ході виконання запиту були вибрані міста, і для кожного міста була підрахована кількість входжень.

Цей приклад можна ускладнити. Можна створити запит, який одержує тільки ті міста, які повторюються в таблиці більше двох разів, і при цьому в кінцевий результат не повинне включатися місто Buenos Aires. Оператор WHERE в даному випадку використовувати не вийде, оскільки він працює тільки з окремими записами, а не з масивами. Доведеться використовувати оператора HAVING, який є аналогом оператора WHERE, але може працювати з агрегатними функціями. Сам запит буде досить сильно змінений:

SELECT City, COUNT(*) AS Кількість, MAX(PostaTCode) AS

Почтовый_индекс FROM Customers Where City <> 'Buenos Aires'

GROUP BY City HAVING COUNT (*) >=3

3.2.4 Сортування записів

Оператор ORDER BY використовується для впорядковування записів результуючого набору даних. Записи сортуються відповідно до порядку проходження полів і їх значень. Якщо сортування проводитиметься за збільшенням, то слід використовувати параметр ASC. Для сортування по убуванню використовується параметр DESC. Як приклад можна привести нескладний SQL- запит

SELECT CompanyName,ContactName,City FROM Customers

ORDER BY City

Сортування записів проводиться по полю City.

До створеного запиту можна додати сортування по кількості міст у порядку убування записів:

SELECT City, COUNT(*) AS Кількість, MAX(PostalCode) AS Почтовый_индекс FROM Customers Where City <> 'Buenos Aires'

GROUP BY City HAVING COUNT (*) >=3

ORDER BY Кількість DESC, City ASC

Потрібно звернути увагу на те, що як аргумент параметра ORDER BY була використана назва поля, оскільки його значення є результатом агрегатної функції COUNT. Для включення сортування по убуванню був вказаний параметр DESC, розташований після назви поля.

3.3 Багатотабличні запити

Як правило, при проектуванні таблиць в них прагнуть включати тільки ті поля, які однозначно пов'язані з даною суттю. Це робиться для того, щоб було простіше модифікувати базу даних і підтримувати її цілісність. У зв'язку з цим виникає необхідність створення багатотабличних запитів, тобто запитів, що використовують для формування результату даних з декількох таблиць.

3.3.1 Об'єднання таблиць

У багатьох випадках потрібно одержувати дані з декількох таблиць і зводити їх в одну результуючу таблицю. Така операція називається об'єднанням таблиць. При об'єднанні проводиться скріплення полів різних таблиць. При цьому між полями встановлюються зв'язки за рахунок використання відповідних довідкових значень.

Після оператора FROM таблиці перераховуються через кому. Повне ім'я поля фактично складається з імені таблиці і самого поля, розділених крапкою. Якщо всі стовпці об'єднуваних таблиць мають різні імена, то до них можна звертатися безпосередньо, не указуючи ім'я таблиці, якій вони належать.

Для розгляду принципів роботи багатотабличних запитів слід створити простий приклад. Припустимо, необхідно дізнатися назви судів з вантажем, які відправила кожна компанія, вагу відправленого вантажу, дату його відправки, контактну особу і його телефон

SELECT Orders.ShipName AS Судно, Orders.Freight AS

Вес_груза, Orders.OrderDate

AS Дата_Отправки, Customers.ContactName, Customers.Phone

FROM Customers, Orders

WHERE Customers.CustomerID=Orders.CustomerID

При виконанні запиту були вибрані поля тільки тих записів, у яких значення поля CustomerID співпадали. За допомогою цього поля були об'єднані і зв'язані дві таблиці.

Цей запит можна ускладнити. Припустимо, що необхідно одержати інформацію саме про ті судна, вантаж яких важив більше 500 тонн і був відправлений до періоду з 17.03.1998 по 17.07.1998:

SELECT Orders.ShipName AS Судно, Orders.Freight AS Вес_груза, Orders.OrderDate AS Дата_Отправки, Customers.ContactName, Customers.Phone

FROM Customers, Orders

WHERE Customers.CustomerID = Orders.CustomerID AND Freight > 500 AND

Orders.OrderDate BETWEEN '03.17.1998' AND '07.17.1998'

За допомогою цього механізму можна об'єднувати більше двох таблиць, указуючи пов'язуючі поля і умови відбору записів.

3.3.2 Вкладені підзапити

Вкладені запити можуть використовуватися як додаткові умови відбору записів. Для того, щоб зрозуміти механізм роботи цієї умови, слід розглянути простий запит, в якому виводиться список назв судів, які обслужив співробітник на ім'я Steven Buchanan і дат їх відправки:

SELECT ShipName AS Название_судна, OrderDate AS Дата_отправки FROM Orders WHERE EmployeeID IN

(SELECT EmployeeID FROM Employees

WHERE FirstName = 'Steven' AND LastName = 'Buchanan'):

У цьому запиті оператор IN може бути замінений оператором рівності. Проте слід враховувати, що оператор IN повертає масив значень, а скалярний оператор рівності -- тільки одне.

Виконання запитів з вкладеними підзапитами завжди починається з підзапиту, розташованого на самому нижньому рівні. У даному підзапиті відшукується індивідуальний номер співробітника EmployeelD по його імені і прізвищу. Основний запит приймає знайдене значення як параметр.

Можна ускладнити вкладений запит. У прикладі буде приведений запит, що відображає список співробітників, що обслужили більше дев'яноста суден:

SELECT TitleOfCourtesy, FirstName, LastName FROM Employees

WHERE EmployeeID IN

(SELECT EmployeeID FROM Orders GROUP BY EmployeeID

HAVING

COUNT (EmployeeID) > 100)

ORDER BY FirstName, LastName

У вкладеному запиті проводиться відбір ідентифікаторів працівників, що зустрічаються в таблиці більше 90 разів.

3.3.3 Використання оператора EXISTS

Логічні оператори EXIST і NOT EXIST повертають значення True або False залежно від наявності записів, що задовольняють умові пошуку. Як правило, оператор EXISTS використовується з вкладеними запитами. Для ілюстрації принципів його застосування можна використовувати досить простий запит

SELECT TitleOfCourtesy, FirstName, LastName FROM Employees

WHERE EXISTS

(SELECT * FROM Orders

WHERE Freight > 1000)

ORDER BY LastName

У підзапиті вибираються рядки, значення яких більше 1000. Оскільки подібні рядки існують, то оператору WHERE передається значення True і вираз SELECT вибирає відповідні записи.

Можна змінити умову, що накладається на полі Freight, і використовувати замість оператора EXISTS оператор NOT EXISTS

SELECT TitleOfCourtesy.FirstName.LastName FROM Employees

WHERE NOT EXISTS

(SELECT * FROM Orders

WHERE Freight > 2000)

ORDER BY LastName

Результат виконання запиту буде аналогічний попередньому. Потрібно розібратися, чому так відбулося. Оператор NOT EXISTS поверне значення True тільки в тому випадку, якщо жоден запис не задовольнятиме заданій умові. Оскільки жодне судно не перевезло більш ніж 2 тисячі тонн вантажу, то жоден запис не буде вибраний.

3.3.4 Використання об'єднання UNION

Оператор UNION використовується для об'єднання результатів двох і більш запитів в єдиний набір полів і записів. Коли результати запитів піддаються об'єднанню, їх стовпці висновку повинні бути сумісні. Це означає, що всі запити повинні указувати однакове число стовпців в одному і тому ж порядку. І всі співпадаючі поля повинні мати один і той же тип. Це ілюструється простим запитом

SELECT CustomerID FROM Customers

UNION

SELECT CustomerID FROM Orders

В ході виконання запиту в результуючу таблицю були включені записи з двох таблиць.

4. РОЗРОБКА СИСТЕМИ УПРАВЛІННЯ ЗАПАСАМИ МАТЕРІАЛЬНИХ РЕСУРСІВ ТОВ „ВІКОНДА”

4.1 Загальна характеристика технологічного процесу

Компанія «Віконда» займається збіркою металопластикових конструкцій з комплектуючих, одержуваних від різних постачальників. Після чого на фабриці проводиться збірка готових виробів, які через дилерську мережу реалізуються споживачам.

Завданнями розробленої нами системи є оптимізація управління закупівлями комплектуючих.

Рис. 4.1 Схема руху матеріальних ресурсів

4.2 Розробка схеми інформаційних потоків системи

Розроблена нами система складається з двох модулів. Перший з них реалізований в середовищі Delphi 7. Він призначений для збору статистичної інформації і формування початкових параметрів моделі.

Аналітичний модуль, побудований на основі багатопродуктової матричної ігрової моделі управління запасами, реалізований в середовищі MS Excel.

На даний момент в ТОВ „Віконда” упроваджена автоматизована система управління віконним підприємством. Система працює під управлінням клієнт-серверною СУБД Fire Bird. Завданням дипломної роботи є, використовуючи глобальну базу даних компанії, зібрати необхідні дані і експортувати їх в MS Excel для подальшого аналізу.

Рис. 4.2 Схема інформаційних потоків системи

4.3 Опис математичної моделі

Початковими параметрами ігрової моделі є:

K - розмір капіталу, який фірма має в своєму розпорядженні для вкладення в запаси;

Т - період планування, приймаємо рівним календарному місяцю;

p - витрати на зберігання продукції, виражені як відсоток від ціни одиниці продукції;

r - множник, що характеризує неодночасність поповнення запасів (0<r<1).

Місткість складу не є критичним чинником для компанії, тому даним параметром математичної моделі ми нехтуємо.

Відмітною особливістю роботи нашої компанії є те, що продукція реалізується в збірці, тому аналіз для кожної з груп тих, що комплектують проводиться окремо. Тому як початкові дані виступають наступні таблиці по кожній з груп комплектуючих.

Таблиця 4.1Таблиця початкових даних

№	Найменування комплектуючого	Ci	Ni	Si
1

Де:

C_i - ціна за одиницю і-го типу комплектуючого;

N_i - об'єм витрат і-го типу комплектуючого;

S_i - витрати на постачання комплектуючих на склад.

Список постачальників формується на основі вибірки з глобальної бази даних, значення коефіцієнтів ми вводимо уручну.

Таким чином, витрати на постачання комплектуючих на склад становить:

(4.1)

Як гравці в ігровій моделі виступають фірма і природа - попит на конкретні види продукції. Фірма зацікавлена в мінімізації загальних витрат на доставку і зберігання запасів, а природа зацікавлена в зворотному - в нанесенні фірмі найбільшого збитку, тобто в максимізації загальних витрат.

Число і періодичності закупівель повинні задовольняти певним вимогам. Вони повинні вибиратися з набору бажаних (переважних) чисел. Якщо період планування приймається рівним одному місяцю, тобто він дорівнює 24 робочим дням, то повний допустимий переважний набір числа закупівель може скласти l=(24, 12, 8, 6, 4, 3, 2, 1). Цьому набору числа закупівель відповідатимуть періодичності закупівель R=(1, 2, 3, 4, 6, 8, 12, 24), які визначають періоди часу, через які здійснюються закупівлі партій товарів.

З урахуванням цих вимог модель управління запасами матиме вигляд:

(4.2)

де:

(4.3)

Матрицю H можна розглядати як платіжну матрицю парної антагоністичної гри. Кількість рядків відповідає числу найменувань тих, що комплектують в групі, кількість стовпців - числу стратегій (можливому варіанту кількості закупівель).

В якості метода вирішення ігри оберемо мінімаксний критерій.

Мінімаксний критерій (мінімакс) -- один з критеріїв прийняття рішень в умовах невизначеності. Умовами невизначеності вважається ситуація, коли наслідки прийнятих рішень невідомі, і можна лише приблизно їх оцінити. Для ухвалення рішення використовуються різні критерії, завдання яких -- знайти якнайкраще рішення що максимізувало можливий прибуток і що мінімізує можливий збиток.

Для цього в кожному стовпчику отриманої матриці знаходимо максимальне значення, в кожному рядку - мінімальне.

Елемент, який є мінімальним в своєму рядку і одночасно максимальним в своєму стовпці називається сідловою точкою. Якщо матриця має сідлову точку (тобто нижня ціна гри дорівнює верхній), то гра має рішення в чистих стратегіях: це -- пара стратегій, пересічних в сідловій точці. Сама ж сідлова точка дає ціну гри.

Якщо рішення в чистих стратегіях не знайдене (сідлова точка відсутня), то здійснюється перехід до завдання лінійного програмування. Для цього використовується інструмент MS Excel „Пошук рішення”.

4.4 Модуль збору статистичної інформації

4.4.1 Програмна реалізація

На рис. 4.3 представлений фрагмент структури взаємозв'язку таблиць глобальної БД, які беруть участь в зборі інформації.

Рис. 4.3 Фрагмент структури взаємозв'язку таблиць глобальної БД

З таблиці довідника груп комплектуючих ми беремо найменування групи. З довідника номенклатури комплектуючих - найменування і ціну за одиницю. З таблиці „Витрати комплектуючих” ми можемо одержати дані про витрати за календарний місяць. Одним з важливих параметрів моделі є вартість доставки. Для цього нам потрібні відомості про постачальників, які ми одержуємо з таблиць „Надходження комплектуючих” і „Довідник постачальників”.

Оскільки вартість доставки залежить від місця розташування постачальника, для кожного з них ми введемо свій коефіцієнт нормування z_i. Ці дані зберігаються в створеній нами локальній таблиці БД, яка має наступну структуру полів.

Рис. 4.4 Структура довіднику норміровочних коефіцієнтів

На рис. 4.5 зображений фрагмент алгоритму формування платіжної матриці.

Перебираємо записи таблиці - “Довідника груп тих, що комплектують”. Далі відбувається динамічне створення закладки, назва якої відповідає назві групи. Після цього динамічно створюємо об'єкт cxGrid - сітку для виведення даних. Формуємо і виконуємо SQL-запит, на підставі якого проводиться вибірка, і відображаємо інформацію на екрані.

Після закінчення циклу перебираємо записи створеного набору і довідника коефіцієнтів, нормувань. І, якщо знайдений код постачальника, відсутній в довіднику коефіцієнтів, нормувань, заносимо ім'я і код постачальника в таблицю.



Рис. 4.5 Фрагмент алгоритму формування платіжної матриці

Наведемо фрагмент програмного коду, що ілюструє цей алгоритм.

try

// Підключення до локальної бази даних

IBDataBase1.DatabaseName := '127.0.0.1:' + ExtractFilePath(Application.ExeName) + '\data\F.fdb';

IBDataBase1.Params.Text := 'user_name=sysdba' + chr(13) +

'password=masterkey' + chr(13) +

'lc_ctype=WIN1252';

IBDataBase1.Connected := True;

// Таблиця довіднику норміровочних коефіцієнтів

IBTable.TableName:= 'SPNORM';

IBTable.Active:=true;

except

Application.Terminate;

end;

// Підключення до глобальної бази даних

try

IBDataBase2.DatabaseName := '127.0.0.1:' +

ExtractFilePath(Application.ExeName) + '\data\WCglobal.fdb';

IBDataBase2.Params.Text := 'user_name=sysdba' + chr(13) +

'password=masterkey' + chr(13) +

'lc_ctype=WIN1252';

IBDataBase2.Connected := True;

// Таблиця довідника комплектуючих

IBTable1.TableName:= 'KOMLCAT';

IBTable1.Active:=true;

// Довідник номенклатури комплектуючих

IBTable3.TableName:= 'KOMPL';

IBTable3.Active:=true;

// Витрати комплектуючих

IBTable4.TableName:= ' RASHOD ';

IBTable4.Active:=true;

// Надходження комплектуючих

IBTable4.TableName:= ' PRIHOD';

IBTable4.Active:=true;

// Довідник постачальників

IBTable4.TableName:= ' POSTAV ';

IBTable4.Active:=true;

except

end;

// Динамічне створення та настройка властивостей компоненту PageControl

PageControl := TsPageControl.Create(Self);

PageControl.Parent := Self;

PageControl.Align:=alClient;

i:=0; // лічильник груп товарів

IBTable1.First; // перехід на перший запис

Перебираємо записи таблиці - “Довідника груп комплектуючих”

while not IBTable1.Eof do

begin

i:=i+1;

IBQuery:= TIBQuery.Create(self); // динамічно створюємо компонент

IBQuery.Database:= IBDatabase2; // підключаємося до бази даних

IBQuery.SQL.Clear;

// Формуємо SQL-запит

IBQuery.SQL.Add(select kompl.name,kompl.cena,rashod.kol,postav.name from kompl,rashod,prihod,postav where (kompl.id=rashod.pidl) and (prihod.id=kompl.id) and (postav.id=prihod.pidp) and(kompl. pid='+inttostr(IBTable1.FieldValues['id'])+')');

IBquery.Active:=true; // виконуємо SQL-запит

Datasource:= TDatasource.Create(Self); // динамічно створюємо компонент - джерело даних

Datasource.DataSet:=IBquery;

if High(Grid) < 0 then

SetLength(Grid,1)

else

SetLength(Grid,High(Grid)+1);

TabSheet:= TsTabSheet.Create(Self); // динамічне створення закладки

TabSheet.Caption := IBTable1.FieldValues['name']; // ім'я закладки - назва групи комплектуючих

TabSheet.PageControl := PageControl;

// Динамічне створення об'єкту cxGrid - таблиці для відображення результатів запиту

Grid [High(Grid)]:= TcxGrid.Create(Self);

Grid[High(Grid)].Parent:=TabSheet;

Grid[High(Grid)].Align:=alClient;

// Настройка властивостей динамічно створеного компоненту

with grid[High(Grid)].Levels.Add do

begin

_view:=TcxGridDBTableView.Create(TCxGrid(grid[High(Grid)]));

_view.DataController.DataSource:=DataSource;

_View.OptionsView.GroupByBox:=false;

_View.OptionsView.Navigator:=true;

GridView:=_view;

end;

// Динамічне формування стовпців таблиці

col1:=_view.CreateColumn;

col1.DataBinding.FieldName:= 'NAME';

Col1.Caption:='Наименование';

Col1.Width:=250;

col2:=_view.CreateColumn;

col2.DataBinding.FieldName:= 'CENA';

Col2.Caption:='Цена';

col3:=_view.CreateColumn;

col3.DataBinding.FieldName:= 'KOL';

Col3.Caption:='Расход';

col4:=_view.CreateColumn;

col4.DataBinding.FieldName:= 'PNAME';

Col4.Caption:='Поставщик';

IBTable1.Next; // перехід до наступного запису

end; // кінець циклу

Розглянемо фрагмент процедури, за допомогою якої платіжна матриця експортується в MS Excel.

e:=createoleobject('excel.application'); // створення об'єкту

workbook:=e.workbooks.add; // додавання робочої книги

IBTable1.First; i:=0;

while not IBTable1.Eof do // перебираємо усі записи довідника груп комплектуючих

begin

i:=i+1;

if i<= workbook.sheets.count // якщо кількість існуючих в книзі аркушів не перевищує номер запису

then

begin

sheet:=workbook.sheets[i]; // посилання на аркуш

sheet.name:= IBTable1.FieldValues['name']; // ім'я аркушу - назва групи комплектуючих

end

else // якщо необхідно додати аркуш

begin

sheet:= workbook.sheets.add(after:=sheet); // створюємо новий аркуш

sheet.name:= IBTable1.FieldValues['name'];

end;

IBTable1.Next; // перехід до наступного запису

end;

Далі експортуємо в MS Excel вихідні дані.

// Формування заголовків

cell:=workbook.worksheets[1].cells[3,1]; // завдання робочого діапазону комірок

range:=workbook.worksheets[1].range[cell,cell];

range.horizontalalignment:=-4108; // вирівнювання по горизонталі по центру

range.verticalalignment:=-4108; // вирівнювання по вертикалі по центру

range.rowheight:=50; // установка товщини границь

range.font.size:=20; // розмір шрифту

range.font.bold:=true; // тип накреслення - «жирний»

range.font.color:=clRed; // колір шрифту - червоний

range.interior.color:=rgb(160,240,240); //визначення кольору заливки комірки

range.value:='Сі'; // вивід тексту заголовка

i:=4; //номер строки

for j:=1 to 3 do // вивід початкових даних

case j of // j - номер стовпця

1: for i:=0 to cxGrid1DBTableView1.DataController.RecordCount-1 do

// перебираємо в циклі усі записи поточного набору даних

begin cell:=workbook.worksheets[1].cells[i,j]; // встановлюємо діапазон виводу даних

// встановлюємо параметри форматування комірок

range:=workbook.worksheets[1].range[cell,cell];

range.horizontalalignment:=-4108;

range.verticalalignment:=-4108;

range.columnwidth:=75;

range.font.bold:=true;

range.borders.linestyle:=1;

range.borders.weight:=3;

// виводимо значення

range.value:= cxGrid1DBTableView1.DataController.Values[i,j];

end;

2: begin ...end; // аналогічним чином формуємо інші стовпці

end;

4.4.2 Опис інтерфейсу користувача

Після запуску на екрані з'являється вікно підключення до сервера, де необхідно ввести логін і пароль користувача (рис. 4.6). Після чого ми вибираємо із списку базу даних, на підставі якої формуватимемо початкові дані моделі. Це глобальна база даних, яка була зареєстрована в системі за допомогою IBExpert.

Рис. 4.6 Вікно підключення до серверу бази даних

Після цього ми приступаємо до процесу витягання даних. Натиснемо на кнопку «Сформировать таблицы». Як ми бачимо (рис. 4.7), на екрані з'явилися вкладки, кожна з яких відповідає групі комплектуючих.

Рис. 4.7 Робоче вікно системи на етапі формування таблиць

Також ми бачимо інформацію про ціну за одиницю, об'єм витрат комплектуючих і найменування постачальника. Натиснувши на кнопку «Ввод параметров» ми задаємо початкові дані моделі.



Рис. 4.8 Вікно вводу початкових даних

Також нам необхідно ввести коефіцієнти, нормувань, для кожного постачальника. Для цього необхідно натиснути кнопку «Ввод нормировочных коэффициентов». На екрані з'явиться наступне вікно (рис. 4.9).

Рис. 4.9 Вікно вводу коефіцієнтів

Після цього ми експортуємо платіжну матрицю в Excel.

4.5 Реалізація моделі управління запасами в середовищі MS Excel

Алгоритм реалізації багатопродуктової матричної ігрової моделі, засобами MS Excel полягає в наступному.

Платіжна матриця формується автоматично на основі вхідних даних моделі за допомогою модулю збору статистичної інформації і формування початкових параметрів моделі. При цьому кожній групі комплектуючих відповідає окремий аркуш. На рис. 4.10 наведений приклад автоматично сформованої робочої книги.

В наведеному на рис. 4.10 числовому прикладі платіжна матриця має особливий елемент 3578,31. Він є мінімальним в своєму рядку і одночасно максимальним в своєму стовпці. Такий елемент називається сідловой точкою.

Рис. 4.10 Робоча книга MS Excel зі сформованою платіжною матрицею

Якщо матриця має сідлову точку (тобто нижня ціна гри рівна верхньою), то гра має рішення в чистих стратегіях: це -- пара стратегій, пересічних в сідловій точці. Сама ж сідлова точка дає ціну гри -- в нашому прикладі вона рівна 3578,31.

З поданої інформації ми бачимо, що оптимальною стратегією буде закупівля комплектуючих партіями чотири рази на місяць. Гарантовані загальні витрати (сума стовпця оптимальної стратегії) становитимуть 9402,79 грн. Оптимальні об'єми закупівлі комплектуючих кожної групи ми бачимо в стовпці В. На окремому аркуші робочої книги ми маємо можливість здійснити контроль обмеження капіталу.

На основі отриманих результатів особа, що приймає рішення, може зробити висновок про те, чи треба збільшувати кількість коштів на придбання матеріальних запасів комплектуючих.

Рис. 4.11 Контроль обмеження капіталу

Якщо рішення в чистих стратегіях не знайдене, то здійснюється перехід до завдання лінійного програмування. Для цього в комірки вводяться додаткові змінні х, - початкові значення яких повинні бути рівні 1, а в строку 30 - добутки стовпця змінних і стовпців матриці Н. Таким чином, одержуємо початкову розрахункову таблицю для вирішення завдання лінійного програмування.

Рис. 4.12 Початкова розрахункова таблиця для завдання лінійного програмування

У меню „Сервис” вибирається пункт „Поиск решения” і у формі, що з'явилася (рис. 4.13), встановлюється напрям цільової функції, посилання на цільову комірку, посилання на комірки із змінними та задаються обмеження (рис. 4.14).

Рис. 4.13 Вікно „Поиск решения”

Натиснувши кнопку „Добавить” ми маємо в змозі додати обмеження значень комірок.

Рис. 4.14 Вікно „Добавление ограничения”

При цьому обмеження на позитивність значень змінних і умову лінійності моделі встановлюються формі, що з'являється при натисненні кнопки „Параметры” (рис. 4.15).

Рис. 4.15 Вікно „Параметры поиска решений”

Після натиснення кнопки „Выполнить” у формі „Поиск решения” MS Excel здійснює рішення задачі лінійного програмування і виводить повідомлення про результати.

Рис. 4.16 Вікно „Параметры поиска решений”

5. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ

Метою даної дипломної роботи є розробка елементів автоматизованого робочого місця менеджера компанії „Віконда”. Відмінною особливістю розробки є те, що розроблене програмне забезпечення є інтегрованим в існуючу інформаційну систему компанії. Впроваджена на підприємстві інформаційна система розроблена компанією VSGroup, яка займається розробкою програмного забезпечення в сфері автоматизації віконного виробництва. Результатом виконання дипломної роботи є створення модулів, які доповнюють існуючу систему деякими додатковими функціональними можливостями.

Економічна доцільність розробки полягає в економії витрат порівняно з оплатою компанії VSGroup за удосконалення розробленої системи.

В ході розробки програмного продукту було використане програмне забезпечення Turbo Delphi 2006 Explorer та СУБД Fire Bird 2.1, яке є безкоштовним.

Аналітичний модуль, побудований на основі багатопродуктової матричної ігрової моделі управління запасами, реалізований в середовищі MS Excel.

Визначення витрат на створення програмного продукту

Оскільки середа розробки є безкоштовною, витрати на створення програмного продукту складаються з витрат по оплаті праці розробника програми і витрат по оплаті машинного часу при відладці програми:

З_спп=З^зп_спп +З^мв_спп

де:

З_спп - витрати на створення програмного продукту;

З^зп_спп - витрати на оплату праці розробника програми;

З^мв_спп - витрати на оплату машинного часу.

Витрати на оплату праці розробника програми (З^зп_спп) визначаються шляхом множення трудомісткості створення програмного продукту на середню годинну оплату програміста (з урахуванням коефіцієнта відрахувань на соціальні потреби):

З^зп_спп=t*T_час

Розрахунок трудомісткості створення програмного продукту

Трудомісткість розробки програмного продукту можна визначити таким чином:

t= t_o+ t_а+ t_б+ t_п+ t_д+ t_від,

де:

t_o - витрати праці на підготовку опису завдання;

t_а - витрати праці на розробку алгоритму рішення задачі;

t_б - витрати праці на розробку блок-схеми алгоритму рішення задачі;

t_п - витрати праці на складання програми по готовій блок-схемі;

t_д - витрати праці на підготовку документації завдання;

t_від - витрати праці на відладку програми на ЕОМ при комплексній відладці завдання.

Складові витрат можна виразити через умовне число операторів Q. У нашому випадку число операторів у відлагодженій програмі Q=1050.

Розрахунок витрат праці на підготовку опису завдань

Оцінити витрати праці на підготовку опису завдання не можливо, оскільки це пов'язано з творчим характером роботи, натомість оцінимо витрати праці на вивчення опису завдання з урахуванням уточнення опису і кваліфікації програміста:

t_o= Q*B/(75…85*K),

де:

B - коефіцієнт збільшення витрат праці унаслідок недостатнього опису завдання, уточнень і деякої недоробки, B=1,2…5;

K - коефіцієнт кваліфікації розробника, для тих, що працюють до 2 років K=0.8;

Коефіцієнт В приймаємо рівним 3.

Таким чином отримаємо:

t_o= 1050*2/(78*0,8) = 33,65 (люд-год).

Розрахунок витрат праці на розробку алгоритму

Витрати праці на розробку алгоритму рішення задачі:

t_а = Q/(60…75*K)

t_а = 1050/(70*0,8)=18,75 (люд-год).

Розрахунок витрат праці на розробку блок-схеми

Витрати праці на розробку блок-схеми алгоритму рішення задачі обчислимо таким чином:

t_б= Q/(60…75*K)

t_б = 1050/(71*0,8)=18,48 (люд-год).

Розрахунок витрат праці на складання програми

Витрати праці на складання програми по готовій блок-схемі обчислимо таким чином:

tп= Q/(60…75*K)

tп = 1050/(72*0,8)=18,23 (люд-год).

Розрахунок витрат праці на відладку програми

Витрати праці на відладку програми на ЕОМ при комплексній відладці завдання:

t_від=1.5* t^Aвід,

де t^Aвід - витрати праці на відладку програми на ЕОМ при автономній відладці одного завдання;

t^Aвід= Q/(40…50*K)

t^Aвід = 1050/(48*0,8)=27,34 (люд-год).

Звідси tвід=1.5*27,34=41,01 (люд-год).

Розрахунок витрат праці на підготовку документації

Витрати праці на підготовку документації по завданню визначаються:

t_д= tдр+ tдо,

де:

tдр - витрати праці на підготовку матеріалів в рукопису;

tдо - витрати на редагування, друк і оформлення документації;

t_др= Q/(150…200*K)

tдр = 1050/(180*0.8) = 7,29 (люд-год)

tдо=0.75*tдр

tдо =0.75*7,29=5,47 (люд-год)

Звідси:

tд=7,29+5,47=12,76 (люд-год).

Отже, загальну трудомісткість розробки програмного продукту можна розрахувати:

t= t_o+ t_а+ t_б+ t_п+ t_д+ t_від,

t = 33,65 +18,75 +18,48+18,23 +41,01+12,76 =142,88 (люд-год).