Автоматизовані робочі місця

Вимоги до функціональних характеристик

Перелік формованих звітів

4.4.2. Вимоги до системи планування та управління виробництвом

Інформаційна система має забезпечити планування ресурсів підприємства та управління позамовним виробництвом.

Вимоги до функціональності ІС:

1. Управління конфігурацією готової продукції (ДП):

Ведення нормативно-довідкової інформації про склад ДП із можливістю зазначення періоду актуальності специфікації та з можливістю знаходження у виробництві ДП з декількома різними специфікаціями;

Ведення нормативно-довідкової інформації щодо технології виготовлення виробів, що входять до складу ДП з можливістю вказівки періоду актуальності технологій та з можливістю знаходження у виробництві ДП з декількома різними технологіями;

2. Управління продажами:

Перегляд історії взаємин із клієнтами;

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

Перегляд актуальних економічних показників (калькуляції) ДП, що замовляється;

3. Планування виробництва:

Формування графіка доступності обладнання із зазначенням кількості доступних нормо-годин на кожен день планового періоду;

Формування плану виробництва із зазначенням виробу, його кількості, використовуваного обладнання, підрозділу на кожен день планового періоду;

Формування плану потреби виробництва у матеріалах та комплектуючих;

Контролювання та управління завантаженням обладнання за сформованим виробничим планом;

Внесення коригувань до плану виробництва під час його виконання;

план-фактний аналіз плану виробництва;

4. Управління виробництвом:

формування змінних завдань (нарядів) на виготовлення виробів;

Призначення/перепризначення нарядів виконавців та фіксація виконання нарядів із зазначенням кількості випущених виробів, кількості бракованих виробів та причин виникнення шлюбу;

Управління зберіганням та переміщенням товарно-матеріальних цінностей (ТМЦ) у виробництві;

5. Управління постачанням:

Формування на підставі плану потреби в матеріалах та комплектуючих заявки на покупку із зазначенням постачальника, номенклатури ТМЦ, кількості та строків постачання;

формування заявок на купівлю на підставі разових замовлень на ТМЦ від підрозділів;

Контролювання та відстеження процесу виконання заявок на купівлю;

Оперативний контроль залишків;

План-фактний аналіз постачання;

6. Управління витратами:

Формування планової (нормативної) собівартості ДП;

Фіксація фактичних витрат за виробництво;

Розрахунок фактичної собівартості ДП;

План-фактний аналіз витрат.

Вимоги до розрахунку нормативної собівартості замовлення

Нормативна собівартість виробу та всього замовлення розраховується за такою методикою:

1. Пряма матеріальна складова нормативної собівартості виробу формується на підставі інформації про нормативний склад цього виробу (специфікації) та встановлені облікові ціни на входять до цієї специфікації ТМЦ. Для специфікації допускається використання кількох статей матеріальних витрат.

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

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

Для здійснення цього розрахунку потрібна наявність в Інформаційній системі наступних даних:

1. Специфікація виготовлення виробу (а також специфікації виготовлення всіх напівфабрикатів власного виробництва, що входять у цей виріб);

2. Технологія виготовлення виробу та напівфабрикатів, які входять до нього: які операції мають бути виконані і за який час. Крім того, для кожної операції задаються професія та розряд робітника, необхідні для її виконання (для випуску цього конкретного виробу);

3. Протокол облікових цін на використовувані ТМЦ;

4. Грошові розцінки нормо-годин для професій та розрядів.

Вимоги до розрахунку фактичної собівартості замовлення

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

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

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

3. Амортизація прямого виробничого обладнання входить до складу прямих витрат у разі, якщо для кожного переділу вказується обладнання (верстат), що використовується на цьому переділі.

4. Прямі витрати, що підлягають розподілу:

Основні матеріали, що витрачаються рідше, ніж на кожен переділ (наприклад, хімікати, норма яких на одиницю продукції настільки мала, що не має сенсу враховувати їх попередню витрату навіть за цією нормою);

Заробітна плата робітників у разі відсутності інформації про її попереднє розподілення;

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

Такі витрати розподіляються на вироби відповідно до обраної бази розподілу (наприклад, пропорційно прямим матеріальним витратам).

1. Загальновиробничі витрати (25 рахунок БО): розподіляються на вироби, що випускаються, пропорційно обраній базі розподілу. Частка таких витрат може залишатися чи ні у складі незавершеного виробництва згідно з прийнятою на підприємстві Обліковою політикою.

2. Загальногосподарські витрати та витрати на продаж (26 та 44 рахунки БО) визнаються витратами поточного періоду та відносяться до витрат на реалізацію. Розподіл таких витрат за собівартість готової продукції можна побачити з допомогою спеціального звіту.

Вимоги до продуктивності інформаційної системи

<Раздел должен содержать требования к производительности Информационной системы. Вводится в шаблон>.

Вимоги до надійності

<Раздел должен содержать требования к надежности Информационной системы. Например:>

Вимоги щодо забезпечення надійного (стійкого) функціонування Інформаційної системи

Надійне (стійке) функціонування Інформаційної системи має бути забезпечене виконанням Замовником сукупності організаційно-технічних заходів, перелік яких наведено нижче:

1. Організація безперебійного живлення технічних засобів;

2. Використання ліцензійного програмного забезпечення;

3. Регулярне виконання рекомендацій Міністерства праці та соціального розвитку РФ, викладених у Постанові від 23 липня 1998 «Про затвердження міжгалузевих типових норм часу на роботи з сервісного обслуговування ПЕОМ та оргтехніки та супроводу програмних засобів»;

4. Регулярне виконання вимог ГОСТ 51188-98. "Захист інформації. Випробування програмних засобів на наявність комп'ютерних вірусів»;

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

1. Актуальність та необхідність проведення дослідження

З появою з недавнього часу в РФ нової форми управління нерухомістю у вигляді товариства власників житла (ТСЖ), асоціації власників житла (HOA - homeowners assotiations) та кондомініумів (надалі – організації з управління нерухомості) у орендарів (власників) житла з'явилася можливість впливати на якість технічне обслуговуваннянерухомості, на благоустрій прилеглої території та деякою мірою на вартість комунальних послуг.

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

б) освітньому процесі

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

	Назва курсу/ матеріалу	Короткий опискурсу/ матеріалу
Науково-освітні курси	Навчальний посібник «Інформаційні системи управління багатоквартирними будинками»	Наводяться функціональні можливості інформаційних систем з управління нерухомістю, що використовуються в РФ та за кордоном. Порівнюються функціональні можливості видаються рекомендації щодо вибору інформаційної системи. Призначено для навчання студентів за напрямками 080100.62 «Економіка» та 080500.62 «Бізнес-інформатика»
Лабораторний практикум "Система управління бізнес-правилами організації з управління МКД"	Наведено покрокові інструкції щодо формування модуля управління бізнес-правилами за допомогою IBM ILog. Наводиться алгоритм управління бізнес-правилами ТСЖ. Призначений для навчання студентів за напрямом 080500.62 «Бізнес-інформатика»
Лабораторний практикум «Мультіагентне моделювання діяльності організації з управління нерухомістю»	Наводяться покрокові інструкції щодо формування агентів та формування моделі діяльності організації з управління нерухомістю за допомогою AnyLogic. Призначений для навчання студентів за напрямом 080500.62 «Бізнес-інформатика»
Навчальний посібник Розробка бази даних багатоквартирного будинку з використанням СУБД MS Access 2010	Наводяться покрокові інструкції щодо формування таблиць бази даних, встановлення зв'язків між ними, побудови форм, запитів, звітів та макросів з використанням можливостей СУБД MS Access 2010.
Лабораторний практикум «Аналіз бізнес-процесів організації з управління нерухомістю»	Наведено діаграми, розроблені з використанням об'єктно-орієнтованої мови моделювання UML. Призначено для навчання студентів за напрямками 080100.62 «Економіка» та 080500.62 «Бізнес-інформатика»
Науково-популярні матеріали	Монографія «Факторний та кластерний аналіз організацій регіону у сфері управління нерухомістю»	Наводяться рекомендації щодо факторного та кластерного аналізу параметрів, що характеризують ТСЖ обраного регіону. Наводяться відомості про організації з управління нерухомістю з однаковими наборами бізнес-процесів та визначення основних факторів, що впливають на їхню діяльність.
Монографія "Алгоритми інформаційного обміну в організації з управління нерухомістю"	Наводяться загальний алгоритм роботи ІС, алгоритми роботи програмних модулів ІС, що реалізують інформаційні послуги для абонентів, алгоритми взаємодії програмних модулів. Інтерфейси користувача інформаційної системи. Особливості розробки програмного коду модулів за допомогою середовища розробки MS Visual 2010
Стаття «Класифікація абонентів та інформаційних систем в організаціях з управління МКД»	Визначаються закономірності інформаційного обміну всередині організації з управління нерухомістю, передбачуваний склад та обсяг даних при інформаційному обміні, передбачувані перетворення даних при інформаційному обміні, форми подання вхідних та вихідних даних
Стаття "Розробка мультиагентної імітаційної моделі для моделювання діяльності ТВЖ"	Наводяться підходи до формування агентів для предметної області, а також розробка імітаційної моделі. Наводяться результати моделювання діяльності ТСЖ за різних наборів вихідних даних.
Стаття Формування набору бізнес-правил для ТВЖ	Наводяться підходи формування набору бізнес-правил. Розглянуто можливості реалізації системи управління бізнес-правилами із використанням IBM ILog. Наводиться приклад використання бізнес-правил для ухвалення рішення
Стаття "Формування алгоритмів роботи інформаційної системи організації з управління нерухомістю"	Розглядається структура алгоритму роботи інформаційної системи, структура алгоритмів програмних модулів, що реалізують інформаційні послуги та інформаційний обмін з базою даних організації.
	Стаття «Застосування цілісного підходу на формування комплексу ключових показників ефективності діяльності ТСЖ»	Розглядається застосування положень цілісного підходу на формування комплексу показників, дозволяють створення системи оцінки досягнення стратегічних і тактичних (операційних) цілей організації з управління нерухомістю, оцінки стану організації та контролю ділової активності абонентів інформаційної системи у часі.
Стаття «Інформаційні послуги для управління багатоквартирними будинками»	Розглядаються інформаційні послуги, що надаються закордонними інформаційними системами власникам (орендарам) нерухомості у багатоквартирних будинках.
Стаття Формування бази даних для інформаційної системи ТСЖ	Розглядаються моделі даних, технологія зберігання та обробки даних, склад даних, формати даних для відображення в інтерфейсах і вихідних документах, типи даних, передбачуваний склад таблиць, а також схема зв'язків між таблицями
Стаття «Організаційний аналіз та модель бізнес-процесів ТСЖ»	Розглядається розробка комплексу моделей: стратегічної моделі цілепокладання, організаційно-функціональної моделі, функціонально-технологічної моделі, процесно-рольової моделі кількісної моделі, моделі структури даних (у якому вигляді описуються регламенти ТСЖ та об'єкти зовнішнього оточення), моделі бізнес-процесів

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму, розташовану нижче

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

Розміщено на http://www.allbest.ru/

Кафедра автоматизації та інформаційних систем

ПОЯСНЮВАЛЬНА ЗАПИСКА

до курсового проекту

Тема: Проектування модуля ІС управління підприємством

Дисципліна: «Проектування ІВ»

Вступ

1 Інформаційне забезпечення комплексу завдань

1.1.1 Інфологічна чи інформаційна модель (схема даних) та її опис

1.2.1. Формалізація розрахунків (алгоритми розрахунку та розв'язання задач)

2 Технологічне забезпечення

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

3 Програмне забезпечення комплексу завдань

3.1 Загальні положення

Висновок

Список використаної літератури

ВСТУП

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

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

Існують три шляхи створення ІВ:

1 Побудова ІС на основі систем ERP.

2 Розробка власних ІС.

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

Модуль ІС "Управління підприємством", призначений для автоматизації роботи праці співробітників торгових підприємств. Система має базу даних, що містить відомості про підприємства-постачальники, співробітників та покупців.

автоматизована система позамашинний внутрішньомашинний

1 ІНФОРМАЦІЙНЕ ЗАБЕЗПЕЧЕННЯ КОМПЛЕКСУ ЗАВДАНЬ

1.1 Позашляхове інформаційне забезпечення

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

Позашляхове інформаційне забезпечення (рисунок 1) включає позамашину інформаційну базу (ІБ) та засоби її ведення.

Розміщено на http://www.allbest.ru/

Рисунок 1 Позашляхове інформаційне забезпечення

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

Немашинна інформаційна база включає нормативно-довідкову, планову (тобто умовно-постійну) інформацію та оперативну (облікову) інформацію деякої предметної галузі. Зразковий типовий склад інформації одного та іншого виду представлений на рисунок 2.

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

Розміщено на http://www.allbest.ru/

Рисунок 2 Склад позамашинної інформаційної бази

1.1.1 Інфологічна чи інформаційна модель (схема даних) та її опис.

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

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

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

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

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

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

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

В результаті вивчення вхідних документів створено інфологічну модель даних (ІЛМ), графічне зображення ІЛМ у канонічній формі, що наочно показує ієрархічні відносини підпорядкованості інформаційних об'єктів (рисунок 3).

Розміщено на http://www.allbest.ru/

Рисунок 3 Інфологічна модель модуля ІС «Управління підприємством»

1.1.2. Характеристика вхідної інформації

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

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

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

Інформація про тип матеріалу;

Інформація про колір матеріалу;

Інформація про фактуру матеріалу;

Інформація про виробника;

Інформація про працівників підприємства;

Інформація про посади;

Інформація про кількість матеріалу;

Інформація про ціну матеріалу;

Інформація про ширину полотна;

База даних складається з 7 таблиць та 5 довідників. Таблиця «Матеріали» (рисунок 4) служить зберігання даних матеріалі. Інформація в цю таблицювводиться під час здійснення приходу матеріалу складу.

Малюнок 4 Таблиця "Матеріали"

Таблиця "Клієнти" (рисунок 5) служить для зберігання інформації про клієнтів.

Малюнок 5 Таблиця «Клієнти»

Таблиця «Співробітники» (рисунок 6) служить зберігання інформації про співробітників цього підприємства. Інформація в таблиці «Співробітники» вводиться пристрої на роботу нового працівника.

Малюнок 6 Таблиця «Співробітники»

Таблиця «Замовлення» (рис. 7) служить для зберігання інформації про замовлення на встановлення натяжних стель.

Малюнок 7 Таблиця "Замовлення"

Таблиця "Виробник" (рисунок 8) служить для зберігання інформації про постачальників матеріалів.

Малюнок 8 Таблиця "Виробник"

Таблиця «Прихід» (рис. 9) та таблиця «Витрата» (рис. 10) служить для зберігання інформації про прихід та витрату матеріалу.

Рисунок 9 «Прихід»

Рисунок 10 «Витрата»

Довідники «Тип матеріалу» (рис. 11), «Колір» (рис. 12), «Фактура» (рис. 13), «Посада» (рис. 14), «Статус» (рис. 15) служать для уточнення даних у таблицях, представлених у вигляді кодів.

Малюнок 11 Довідник «Тип матеріалу»

Малюнок 12 Довідник «Колір»

Малюнок 13 Довідник «Фактура»

Малюнок 14 Довідник «Посада»

Малюнок 15 Довідник «Статус»

1.1.3. Характеристика результатної інформації

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

1.2 Внутрішньомашина реалізація комплексу завдань

Інформація, якою оперуватиме інформаційна система, організована як бази даних, створеної засобами MySQL (рисунок 16).

Схема бази даних, створеної засобами MySQL

1.2.1 Формалізація розрахунків (алгоритми розрахунку та розв'язання задач)

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

При розрахунку вартості установки натяжної стелі потрібно заповнити форму «Вартість», яка містить три поля та введення інформації: ширина стелі, довжина стелі, фактура матеріалу. Після заповнення даних полів програма вимагає з бази даних MySQL, дані про вартість матеріалу з цією фактурою Вартість розраховується шляхом множення площі стельового покриття вартість матеріалу за 1 м 2 .

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

1.2.2 Структурна схема використання комплексу програм (дерево діалогу)

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

Розроблений додаток має інтуїтивно зрозуміле меню. Для роботи з таблицями бази даних модуля ІС «Управління підприємством» складається з:

форм перегляду та редагування;

форми розрахунку вартості стелі;

форми подання графічної інформації.

2 ТЕХНОЛОГІЧНЕ ЗАБЕЗПЕЧЕННЯ

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

3 ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ КОМПЛЕКСУ ЗАВДАНЬ

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

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

3.1 Загальні положення

Модуль ІС «Управління підприємством» виконаний за технологією, яка базує свої послуги на Windows-системах, з доступом до MySQL.

MySQL, в даний час є одним з найпопулярніших СУБД. Серед причин такої популярності слід зазначити:

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

Глибоко розвинені можливості інтеграції коїться з іншими програмними продуктами;

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

3.2 Опис програмних модулів

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

При відкритті сторінки "Продукція", потрапляємо на форму, де знаходяться 6 основних модулів програми: "Замовлення", "Матеріали", "Витрата", "Прихід", "Клієнти", "Співробітники".

При натисканні кнопок "Замовлення", "Матеріали", "Витрата", "Прихід", "Клієнти", "Співробітники", потрапляємо на відповідну форму, в якій можна здійснити додавання, видалення, сортування, пошук інформації в базі даних. При натисканні на одну з цих кнопок автоматично потрапляємо на форму з рядками заповнення інформації для видалення, сортування, додавання або пошуку після заповнення, яких виводиться підсумкова інформація.

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

У формі "Витрата" при натисканні на кнопку "Графік витрат" виводиться зображення діаграми з графічною інформацією про витрати відносно тимчасового періоду.

ВИСНОВОК

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

Використання засобів PHP, HTML і MySQL для створення програм, що працюють в операційній системі Windows і зокрема програм баз даних, дозволило створити програмний продукт максимально орієнтований на кінцевого користувача.

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

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

СПИСОК ЛІТЕРАТУРИ

1. Веллінг Л. Розробка Web-додатків за допомогою PHP та MySQL. Видавничий дім «Вільямс», 2003. – 288 с.: іл.

2. Довідники з РНР та MySQL. http://www.php.su/books/.

3. Файли довідок з phpMySQL_Admin

4. http://www.php.ru

5. http://www.mysql.ru

Розміщено на Allbest.ru

Подібні документи

Розкриття понять "інформація", "дані", "знання". Опис позамашинного та внутрішньомашинного інформаційного забезпечення, систем показників, класифікації та кодування. Вивчення складу інформаційного забезпечення управління конкретному прикладі.

курсова робота , доданий 26.09.2012


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

дипломна робота, доданий 30.05.2013


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

контрольна робота , доданий 25.07.2012


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

дипломна робота , доданий 03.01.2012


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

курсова робота , доданий 22.11.2013


Еволюція технічного забезпечення. Основні вимоги, застосування та характеристики сучасних технічних засобів автоматизованих інформаційних систем. Комплексні технології обробки та зберігання інформації. Створення бази даних обліку та продажу.

курсова робота , доданий 01.12.2010


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

дипломна робота , доданий 22.11.2015


Технологічний процес збору, передачі, обробки та видачі інформації. Призначення програмного продукту Аналіз економічних показників застосування автоматизованого робочого місця касира-операціоніста. Організація робочого місця оператора ЕОМ.

дипломна робота , доданий 08.12.2014


Правові основи оренди Республіка Казахстан. Огляд існуючого програмного забезпечення роботи агентств нерухомості. Вибір та проектування інфологічної моделі бази даних. Організація технології збору, передачі, обробки та видачі інформації.

дипломна робота , доданий 02.11.2015


Організація вантажоперевезень на підприємстві ЗАТ "Паллада-Торг". Особливості управління перевезеннями: організаційна структура та функції Відділу інформаційних систем; оцінка рівня автоматизації та інформатизації процесу обробки та передачі інформації.

Створена з безлічі модулів інформаційна системадозволила нижегородському автомобільному заводу «Чайка-Сервіс» реалізувати ідею виробництва, що максимально повно враховує побажання клієнтів, які розмістили на підприємстві свої замовлення

Створена з безлічі модулів інформаційна система дозволила нижчеміському автомобільному заводу «Чайка-Сервіс» реалізувати ідею виробництва, що максимально повно враховує побажання клієнтів, які розмістили на підприємстві свої замовлення

Головне завдання ІТ-служби компанії, яка веде бізнес у нинішній непростий час, - скоротити витрати на ІТ та надати керівництву інструменти, які допоможуть успішно подолати випробування кризою. Так вважає Олексій Ганін, керівник ІТ-відділу нижегородського автомобільного заводу «Чайка-Сервіс», що спеціалізується на випуску серійної та унікальної автоспецтехніки.

Підприємство бурхливо зростало у 2006 році, коли було придбано у власність частину старого заводу та почалося освоєння другої території. Звичайно, постало завдання об'єднати обидві території в єдине інформаційне поле. Почали зі створення мережі VPN, але коли кількість користувачів зросла, пропускну здатність каналу стало не вистачати. Тоді між двома територіями було прокладено волоконно-оптичний кабель.

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

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

З інструментів, які найближчим часом буде надано керівництву, Ганін назвав насамперед систему розрахунку собівартості. Вона вже розроблена і буде спільної глобальної мети - скорочення витрат. Уточнений розрахунок собівартості виробів планується проводити з урахуванням системи управління інженерними даними. Це забезпечить детальні та оперативні дані про собівартість (раніше вони розраховувалися на основі бухгалтерських даних). Підприємство випускає досить складні вироби, лише кінцевих варіантів автомобілів з різними модифікаціями налічується близько півтори тисячі. Звичайно, деталей, з яких вони збираються, на два порядки більше.

Від бухгалтерії – до виробництва

Першим кроком на шляху автоматизації стало придбання у 2002 році продукту "1С: Бухгалтерія 6.0" та САПР-системи "Компас" компанії "Аскон". Наступним кроком стала автоматизація виробничої діяльності. Компанія «Рарус ПН» на замовлення підприємства розпочала адаптацію ERP-системи «1С: Управління виробничим підприємством 8» («1С: УПП 8») до потреб та особливостей підприємства. Метою проекту була побудова єдиної бази даних та реалізація управління усіма бізнес-процесами на основі єдиної інформаційної системи. Вирішальним фактором успіху її впровадження стала безпосередня підтримка вищим керівництвом підприємства – генеральним директором, який ініціював та підтримував проект на всіх його етапах.

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

Фахівці ІТ-відділу разом із технологами розробили блок специфікацій виробничих та технологічних карт. На їх основі та на базі місячного плану випуску готової продукції визначалася потреба у матеріалах на певний період з урахуванням поточних залишків. Усе це дозволяло грамотно спланувати роботу відділу постачання.

Співробітники ІТ-відділу розробили модуль для "1С: УПП 8" для імпортування "дерева" виробу із системи "Компас", яку використовують конструктори підприємства. Алгоритм роботи вийшов наступний: конструкторське бюро засобами «Компаса» розробляє креслення та створює 3D-модель об'єкта, потім структура виробу за допомогою розробленого модуля імпортується в ERP-систему, після чого на основі даних, що імпортуються, будується специфікація виробів. Якщо конструктори вносять зміни у будь-який вузол, ці зміни автоматично відображаються у всіх системах.

Спочатку, як зізнався Ганін, він і його фахівці хотіли самотужки зробити систему управління інженерними даними, але незабаром з'ясували, що група компаній Appius, партнер «1С», розробляє власне тиражоване PDM-рішення (воно отримало назву «1С: PDM Управління інженерними даними »).

Зворотній зв'язок

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

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

Наступним кроком стало використання модуля виробничого планування. Раніше планування здійснювалось засобами Excel, Нерідко виникали нестиковки, помилки. Після того як запрацював ERP-модуль виробничого планування, менеджери отримали в своє розпорядження фактичні дані, що формуються на основі технічних завдань, що надійшли. Це дозволило оперативно відстежувати завантаження кожної ділянки. В результаті підвищилася точність та ефективність планування виробництва.

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

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

«Це універсальне рішення, до того ж воно не вимагає від робітників комп'ютерної грамотності, – зазначає Ганін. - Автомобіль – основна та найдорожча складова нашого виробництва, скорочення простоїв дозволило різко прискорити виконання замовлень». На підприємстві з'явився зручний і простий інструмент аналізу втрат: у системі автоматично генеруються діаграми робіт по кожному автомобілю, що дозволяють відстежувати, коли почалася робота з даного автомобіля, коли закінчилася, скільки часу машина просто стояла в очікуванні чергової операції. При перевищенні допустимого часу починається з'ясування причин та пошук винуватців настільки тривалого простою. Через війну підвищилася персональна відповідальність виконавців.

На основі «1С: УВП 8» спеціалісти підприємства реалізували блок планування роботи конструкторського бюро. Технічні завдання, створені у системі, надходять до головного конструктора, той їх аналізує, розподіляє опрацювання їх за своїми конструкторами та визначає час на кожне завдання. Така організація робіт дає головному конструктору і менеджерам, які формують основу замовлень, можливість відстежувати ступінь завантаженості конструкторського бюро, але це, своєю чергою, дозволяє зіставляти завантаженість виробництва та конструкторів і оптимально розподіляти наявні людські та виробничі ресурси.

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

Важливо підкреслити, що на підприємстві пішли шляхом розширення

Базової конфігурації ERP-системи є додатковими блоками, не змінюючи її внутрішню структуру. Стало можливим, зокрема, без проблем проводити оновлення.

Для управління архівом конструкторської документації на підприємстві впровадили систему "1С: PDM Управління інженерними даними" (розробку ГК Appius) та інтегрували її з "1C: УПП 8". Крім робіт із створення нових виробів, систему управління інженерними даними планується використовуватиме більш точного розрахунку собівартості виробів.

Багатолика інтеграція

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

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

«Ми плануємо також запровадити рішення на базі "1C: УПП 8" для взаємодії з ДІБДР, підготовки та роздруківки ПТС, транзитних номерів, – зазначає Ганін. - Всі дані будуть згруповані в єдиному місці зберігання інформації - картці автомобіля, куди будуть заноситись усі його ідентифікаційні номери, колір, номер кузова і т. д., потім ці дані будуть використані в технічному завданні при роздруківці ПТС, номерів, довідок-рахунків ». Така інтеграція дасть клієнтам підприємства можливість отримувати разом із автомобілем готові ПТС та транзитні номери, завдяки чому можна буде швидше ставити автомобілі на облік у ДІБДР.

Вступ

Ця дипломна робота написана на базі Донецької ВАТ Донецька мануфактура для магазину Cleonelly.

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

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

Підприємства, що займаються проектуванням та розробкою пристроїв різного призначення, нині широко використовують різноманітні засоби як автоматизованого проектування – САПР (CAD), так і моніторингу виробничих процесів – АСУТП (SCADA/DCS). Однак для пристроїв власної розробки необхідно розробляти власні засоби контролю їхньої працездатності та аналізу якості продукції.

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

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

Для досягнення вищевказаної мети необхідно вирішити наступні завдання:

¾ провести аналіз бізнес-процесів магазину;

¾ досліджувати інформаційні потоки, що виникають на етапі здачі виробу, що розробляється;

¾ розробити концептуальну та логічну моделі даних;

¾ розробити програмне забезпечення для АРМ обліку продукції

¾ провести оцінку економічної ефективності інформаційної системи.

1 Розробка вимог до програмного забезпечення

1.1 Аналіз існуючих рішень

В даний час існує широкий спектр компаній, що поєднують як безпосередню розробку виробів, так і розробку систем управління цими виробами. Подібні системирозробляються як такими широко відомими компаніями як 1:С підприємство та “Зірка”. У таких системах здійснюється контроль та облік матеріалів, та обробка отриманої інформації.

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

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

До основних переваг моєї системи Оптова База можна віднести відносну низьку вартість впровадження даної системи, а також ряд переваг:

¾ Надійність програм, що створюються. Програмний комплекс (ПК) повинен бути стійким не тільки до помилок користувачів, але і до збоїв у системі комунікацій.

¾ Зручність користування інтерфейсом;

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

1.2 Аналіз предметної галузі

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

Для проведення аналізу та реорганізації бізнес-процесів призначено CASE – засіб верхнього рівня All Fusion Process Modeler (BPwin), що підтримують методології IDEF0 (функціональна модель), DFD (Dataflow Diagram) та IDEF3 (Workflow Diagram). BPwin є потужним програмним продуктом для створення моделей, що дозволяють аналізувати, документувати та планувати зміни складних бізнес-процесів. BPwin пропонує засіб для збирання всієї необхідної інформації про роботу підприємства та графічного зображенняцієї інформації у вигляді цілісної та несуперечливої ​​моделі.

З погляду функціональності системи. У рамках методології IDEF0 (Integration Definition for Function Modeling) бізнес-процес представляється як набору елементів-робіт, які взаємодіють між собою, і навіть показується інформаційні, людські та виробничі ресурси, споживані кожною роботою. Функціональна модель призначена для опису існуючих бізнес-процесів на підприємстві (так звана модель AS-IS) та ідеального стану речей – того, чого потрібно прагнути (модель TO-BE). Методологія IDEF0 наказує побудову ієрархічної системи діаграм, тобто. одиничних описів фрагментів системи. Спочатку проводиться опис системи в цілому та її взаємодія з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція. – система розбивається на підсистеми та кожна система описується окремо (діаграми декомпозиції). Потім кожна підсистема розбивається більш дрібні і так далі для досягнення потрібного ступеня подробиці.

Якщо в процесі моделювання потрібно висвітлити специфічні сторони технології підприємства, BPwin дозволяє переключитися на будь-якій галузі моделі на нотацію DFD або IDEF3. Діаграми DFD (Data Flow Diagramming) можуть доповнити те, що відображено в моделі IDEF3, оскільки вони описують потоки даних, дозволяючи простежити, як відбувається обмін інформацією між бізнес-функціями всередині системи. У той же час діаграми DFD залишають поза увагою взаємодію між бізнес-функціями.

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

Для розгляду бізнес – процесів, що виконуються на складі магазину, необхідно використовувати лише дві методології IDEF0 та DFD. Процес моделювання будь-якої системи IDEF0 починається з визначення контексту, тобто. найбільш абстрактного рівня опису системи або бізнес-процесів загалом.

Модель IDEF0. Для вивчення бізнес-процесів "Формування замовлення постачальника", "Отримання товару", "Відпустка товару", розглянемо діаграми які представлені у вигляді IDEF0 діаграмі. IDEF0 система представляється як сукупність взаємодіючих робіт чи функцій.

В основі методології IDEF0 лежать чотири основні поняття.

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

Кожна із чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:

Верхня сторона має значення "Управління" (Control);

Ліва сторона має значення "Вхід" (Input);

Права сторона має значення "Вихід" (Output);

Нижня сторона має значення "Механізм" (Mechanism).

Другим "китом" методології IDEF0 є поняття інтерфейсної дуги (Arrow). Графічним відображенням інтерфейсної дуги є однонаправлена ​​стрілка. Кожна інтерфейсна дуга повинна мати свою назву (Arrow Label). За допомогою інтерфейсних дуг відображають різні об'єкти, що в тій чи іншій мірі визначають процеси, що відбуваються в системі. При цьому стрілки, залежно від того, в яку грань прямокутника роботи вони входять або з якої грані виходять, діляться на:

Стрілки входу (входять у ліву грань функціонального блоку) – зображають дані або об'єкти, що змінюються в ході виконання роботи;

Стрілки управління (входять у верхню грань функціонального блоку) – зображають правила та обмеження, завдяки яким виконується робота;

Стрілки виходу (виходять із правої грані функціонального блоку) – зображають дані чи об'єкти, які у результаті виконання роботи;

Стрілки механізму (входять у нижню грань функціонального блоку) – зображують ресурси (наприклад, устаткування, людські ресурси).

Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу складові його функції.

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

Останнім із понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт має на увазі створення та підтримання набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений цим елементом. Цей набір називається глосарієм та є описом сутності даного елемента.

Розглянемо діаграми бізнес-процесів, що протікають на складі магазину ВАТ ДММ, «Cleonelly»:

Для загальної видимості системи необхідно побудувати контекст «Діяльність складу підприємства» (див. рисунок 1.1).

Рисунок 1.1 – Діаграма «Діяльність складу підприємства»

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

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

Рисунок 1.2 – Діаграми декомпозиції першого рівня

Рисунок 1.3 – Діаграма "Оформлення товару"

Рисунок 1.4 – Діаграма "Відпустка товару"

Рисунок 1.5 – Діаграма «Оприбуткування товару»

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

Основними компонентами діаграми потоків даних є:

Зовнішні сутності (графічно зображені квадратом) – позначають матеріальний предмет або фізична особа, що є джерелом або приймачем інформації. Наприклад: замовники, персонал, постачальники, клієнти, склад;

Системи/підсистеми (графічно виглядає як прямокутник із заокругленими кутами) – роботи, що позначають функції або процеси, які обробляють та змінюють інформацію;

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

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

Розглянемо діаграму потоків даних (DFD) «Відпустка товару» 1.6. На цій діаграмі показано рух документів на час вступу в організацію «заявки на товар».

Рисунок 1.6 – Діаграма DFD «Відпустка товару»

Розглянемо наступну діаграму потоків даних «Оформлення товару» (див. рисунок 1.7). Тут показано процес виконання робіт та рух документів при «відпустці товару».

Рисунок 1.7 – Діаграма DFD «Оформлення товару»

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

Організаційна структурапідприємства, що займається продажем махрових виробів, розглянуто на прикладі компанії ВАТ "Донецька Мануфактура М" магазину Cleonelly:

У напрямку розробки систем контролю та обліку матеріалів можуть успішно вирішувати проблеми:

1. Це контроль за товарами, що поставляються і зберігаються на складі.

2. Інформацію про постачальників та споживачів

3. Також міститься інформація про інформацію та операції з товару

4. Містить журнал звіту про відпущений товар

5. Міститься довідник товарів

6. Автоматизація складських функцій (прихід, витрати, списання, резервування товару)

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

8. Створення накладних та облік виданого товару

9. Проведення інвентаризації складів зі створенням порівнювальної відомості, акта недостачі та надлишок

10. Створення комплектів товарів

Як зазначено основною сферою діяльності цього підприємства є продаж бавовняних виробів. p align="justify"> Процес проектування включає безліч етапів ретельно відпрацьованих управлінськими структурами проектних підприємств протягом усього часу життя даного підприємства. Цей процес може бути одноразово змінено, оскільки у ньому задіяно безліч підрозділів самого підприємства, зовнішніх субпідрядників і клієнтів проектного підприємства. Тому підприємства з обережністю ставляться до впровадження інформаційних систем, пов'язаних із процесами управління проектування та розробки. Як правило, російські підприємства використовують власні напрацювання у цій галузі.

1.3 Збір вимог

При проектуванні інформаційної системи (ІВ) «АРМ Оптового Магазину» було необхідно зібрати вимоги, які допомогли б створити інтерфейс таким чином, що кінцевому користувачеві (працівнику магазину) було зручно працювати з розробленою ІВ.

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

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

¾ документування результатів.

¾ Інформаційна система має бути реалізована як програма на базі інтегрованого середовища Visual Fox Pro.

Робота програми здійснюється в операційній системі Windows 2000/NT/XP.

Розрізняють чотири основні етапи процесу розробки вимог (рис. 1.8):

Аналіз технічної здійсненності створення системи;

Формування та аналіз вимог;

Специфікування вимог та створення відповідної документації;

Атестація вимог.

Збір вимог є важливим етапом проектування ПЗ, оскільки саме тут усі вимоги замовника мають бути правильно та коректно сформульовані.

1.4 Специфікація вимог

Визначення коректних вимог - це, мабуть, найвідповідальніший етап програмного проекту. Дуже важливо, щоб формат проекту відповідав вимогам до ПЗ, зібраним командою розробників, інакше ці вимоги не можуть бути підтримані та представлені в програмному продукті. Специфікація вимог до ПЗ - Software Requirements Specification (SRS) має ключове значення для всього життєвого циклурозробка програмного продукту. Це не тільки похідний документ, в якому визначено специфікації програмного проекту, а й основний документ, який застосовується для проведення атестаційних та приймальних випробувань. Атестація – це оцінка якості роботи менеджерів проекту. Вона визначає рівень відповідності програмного продукту встановленим вимогам. Специфікація SRS виступає у ролі якогось механізму фіксування системних вимог, що використовуються як критерії при атестації.

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

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

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

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

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

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

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

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

Специфікація вимог до програмного проекту має бути представлена ​​у додатку А.

1.5 Атестація вимог

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

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

1. Перевірка правильності вимог.

2. Перевірка на несуперечність.

3. Перевірка на повноту.

4. Перевірка на здійсненність.

Існує ряд методів атестації вимог, які можна використовувати спільно або кожний окремо:

1. Огляд вимог.

2. Прототипування.

3. Генерація тестових сценаріїв.

4. Автоматизований аналіз несуперечності.

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

Перед початком створення прототипів можна створити діаграму потоків інтерфейсу користувача. Така діаграма використовується для вивчення взаємозв'язків між основними елементами інтерфейсу користувача.

Наступним кроком атестації вимог є безпосереднє створення прототипів.

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

Прототип основного меню даного модуля представлено малюнку 1.9.

1.6 Вибір методології проектування інформаційної системи

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

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

Принцип "розділяй і володарюй" – принцип вирішення складних проблемшляхом їх розбиття на безліч менших незалежних завдань, легких для розуміння та вирішення;

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

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

SADT (Structured Analysis and Design Technique) моделі та відповідні функціональні діаграми;

DFD (Data Flow Diagrams) діаграми потоків даних;

ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок".

На стадії проектування ІС моделі розширюються, уточнюються та доповнюються діаграмами, що відображають структуру програмного забезпечення: архітектуру ПЗ, структурні схемипрограм та діаграми екранних форм.

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

2 ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

2.1 Архітектурне проектування

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

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

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

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

Вивчення зарубіжного досвіду показує, що у розвинених країн розробки архітектури інформаційної системи потрібно дотримання таких умов:

¾ спрямованість на місії організації;

¾ спрямованість на вимоги;

¾ спрямованість на розробку;

¾ можливість до адаптації;

¾ необхідність гнучкості.

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

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

¾ файл-серверна;

¾ клієнт-серверна;

¾ багаторівнева.

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

Клієнт-сервер. В основі цієї концепції лежить ідея про те, що, крім зберігання файлів бази даних, центральний сервер повинен виконувати основну частину обробки даних. Користувачі звертаються до центрального сервера за допомогою спеціальної мови структурованих запитів (SQL, Structured Query Language), де описується список завдань, що виконуються сервером. Запити користувачів приймаються сервером і породжують у ньому процеси обробки даних. У відповідь користувач отримує оброблений набір даних. Між клієнтом та сервером передається не весь набір даних, як це відбувається у технології файл-сервер, а лише дані, які необхідні клієнту. Запит користувача довжиною всього кілька рядків здатний породити процес обробки даних, що зачіпає безліч таблиць і мільйони рядків. У відповідь клієнт може отримати лише кілька чисел. Технологія клієнт-сервер дозволяє уникнути передачі величезних обсягів інформації, переклавши всю обробку даних на центральний сервер. Крім того, підхід дозволяє уникнути конфліктів змін одних і тих же даних безліччю користувачів, які характерні для технології файл-сервер. Технологія клієнт-сервер реалізує узгоджену зміну даних безліччю клієнтів, забезпечуючи автоматичне дотримання цілісності даних. Ці та деякі інші переваги зробили технологію клієнт-сервер дуже популярною. До вад цієї технології можна віднести високі вимоги до продуктивності центрального сервера. Чим більше клієнтів звертається до сервера, і що більше обсяг оброблюваних даних, то потужнішим має бути центральний сервер.

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

2.2 Проектування інтерфейсу інформаційної системи

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

набір завдань користувача, що він вирішує з допомогою системи;

елементи керування системою;

навігація між блоками системи;

візуальний дизайн екранів програми.

Виділимо кілька найбільш істотних переваг хорошого інтерфейсу користувача з точки зору бізнесу:

зниження кількості помилок користувача;

зниження вартості підтримки системи;

зменшення втрат продуктивності працівників при впровадженні системи та більше швидке відновленнявтраченої продуктивності;

покращення морального стану персоналу;

зменшення витрат на зміну інтерфейсу користувача на вимогу користувачів;

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

АРМ оптова база розробляється як додаток, що використовує технологію клієнт-сервер.

2.2.1 Інтерфейс користувача керуючої програми

Основним модулем "АРМ Оптова База" є модуль Luck.exe, що забезпечує реалізацію основної функціональності діаграми варіантів використання, представленої на малюнку 1.9 розділу 1.4.

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

Інтерфейс програми, адміністраторська частина:

1. Початкова форма програми. Ця формазапускається при запуску програмного продукту, утворюючи, таким чином, початок діалогу користувача з системою (рисунок 2.3);

2. форма адміністратора. У цій формі здійснюється повне управлінняінформаційною системою, тобто. додавання, видалення, зміна даних у базі даних, а також при необхідності перегляд та друк звітів (рис. 2.4);

3. форма «Замовники» завдяки цій формі можна бачити повну інформаціюпро замовників підприємства (рисунок 2.7);

4. форма «Постачальники», завдяки цій формі, можна бачити повну інформацію про замовників підприємства (рисунок 2.8).

Інтерфейс програми користувача частина:

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

У меню витрата там тут відбуваються операції співробітника складу з відпустки та продажу товару.

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

У меню каса тут зберігаються інформація по прибутковим ордерам і видатковим касовим ордерам.

2.2.2 Інтерфейси компонентів управління

Рис 2.0 Головне меню програми

Головне вікно програми показано на мал. 1.9. Як видно з малюнка, крім головного меню, вже описаного вище, воно також міститиме панель управління (кнопки "Прихід", "Витрата", "Доступ", "Залишки", "Каса", "Переоцінка", "Аналітика", " Довідники», «Службові» та «Вихід із програми»).

Рисунок 2.1 Вікно меню приходу чи надходження складу.

Рисунок 2.2 Вікно меню витрати

Рисунок 2.2 Вікно меню, що регулює права доступу до програми.

Малюнок 2.3. Вікно меню залишку товару.

Малюнок 2.4. Вікно меню каса.

Рисунок 2.4 Вікно меню переоцінки.

2.3 Проектування баз даних

Для проектування бази даних використано ERwin 4.0 від Computer Associates Int.

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

ERwin – не тільки найкращий інструментдля проектування баз даних, а й засіб їх швидкого створення. ERwin оптимізує модель відповідно до фізичних характеристик цільової бази даних. На відміну від інших інструментальних засобів, ERwin автоматично підтримує узгодженість логічної та фізичної схем та здійснює перетворення логічних конструкцій, таких як відносини багато-багатьом, у їх реалізацію на фізичному рівні. Полегшує проектування бази даних. Для цього достатньо створити графічну E-R модель(об'єкт-відношення), що відповідає всім вимогам до даних і ввести бізнес-правила для створення логічної моделі, яка відображає всі елементи, атрибути, відносини та угруповання. Erwin має два рівні представлення моделі – логічний та фізичний. Логічний рівень – це абстрактний погляд на дані, на ньому дані подаються, тому що виглядають у реальному світі, і можуть називатися так, як називаються у реальному світі, наприклад, «Постійний клієнт», «Відділ» або «Прізвище співробітника». Об'єкти моделі, представлені на логічному рівні, називаються сутностями та атрибутами. Логічний рівень моделі даних є універсальним і не пов'язаний з конкретною реалізацією СУБД. Розрізняють три рівні логічного рівня моделі даних, що відрізняються за глибиною уявлення інформації про дані:

Діаграма сутність – зв'язок (Entity Relationships Diagram (ERD));

Модель даних, що базується на ключах (Key Based model (KB));

Повна модель атрибутів (Fully Attributed model (FA)).

Діаграма сутність – зв'язок включає сутності та взаємозв'язки, що відображають основні бізнес – правила предметної галузі. Така діаграма не надто деталізована, до неї включаються основні сутності та зв'язки між ними, які задовольняють основним вимогам. Діаграма сутність – зв'язок може включати зв'язки «багато хто до багатьох» і не включати опис ключів. Як правило, ERD використовується для презентацій та обговорення структури даних з експертами предметної галузі. Модель даних, заснована на ключах, - докладніше представлення даних. Вона включає опис всіх сутностей та первинних ключів та призначена для представлення структури даних та ключів, які відповідають предметній області.

Логічна модель – найбільш детальне уявлення структури даних: представляє дані у третій нормальній формі та включає всі сутності, атрибути та зв'язки (дивись додаток Б).

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

Фізична модель даних представлена ​​у додатку Ст.

2.4 Обґрунтування вибору платформи створення інформаційної системи

Visual FoxPro - візуальне середовище розробки систем керування реляційними базами даних, що випускається корпорацією Майкрософт. Останньою версією 9.0. Використовує мову програмування FoxPro. Версія системи 7.0 може працювати в операційних системах Windows 9x і ядра NT, версії 8.0 та 9.0 - тільки в Windows XP, 2000, 2003.

FoxPro (Фокс-про?) – один із діалектів мови програмування xBase. Застосовується в основному для розробки реляційних СУБД, хоча можна застосовувати для розробки та інших класів програм. У Visual FoxPro мова програмування, тобто базової конструкцією мови, є поняття класу. Вихідний варіант xBase - це чиста структурна мова, з базовим поняттям процедур і функцій. Таким чином, сучасну мову програмування Visual FoxPro допускає поєднувати як і програмування "стародавньо" описом маси процедур, так і в стилі ООП, створюючи складну ієрархію класів.

Вибрав я цю мову програмування тому що вона містить низку наступних переваг:

¾ Широко відомий формат таблиць баз даних, що дозволяє легко організувати обмін інформацією з іншими програмами Microsoft Windows.

Сучасна організація реляційних баз даних, що дозволяє зберігати інформацію про таблиці бази, їх властивості, індекси та зв'язки, задавати умови дотримання посилальної цілісності, створювати локальні та віддалені уявлення (Views), зв'язки з серверами, збережені процедури, що виконуються при настанні більше 50 різних видівподій (VFP 7.0-9.0).

Висока швидкість роботи з великими базами даних.

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

Висока швидкість розробки програм з використанням Майстерів (Wizard), Конструкторів (Designer), Побудовників (Builder), режим підказок IntelliSense при написанні тексту програм, системи налагодження та тестування програм.

Можливість розробки додатків, що працюють за технологією "клієнт-сервер" з даними, розміщеними на серверах баз даних Oracle та Microsoft SQL Serverта з іншими програмами Microsoft Windows з використанням ODBC та OLE

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

2.5 Проектування модулів

Зупинимося докладніше на проектуванні одного з модулів програми та розглянемо на його прикладі кроки, необхідні для створення проекту.

Як приклад, мною буде розглянуто проектування модуля, що реалізує варіант використання «Оформляє заявку на вступ».

Спочатку опишемо потоки подій, що відбуваються в даному варіанті використання.

Передумовою варіанта використання є надходження заявки від клієнта.

5. Варіант використання починається, коли клієнт надсилає заявку.

6. Менеджер відкриває форму Приходу.

7. Менеджер ставить дату заявки.

8. Менеджер ставить найменування товару.

9. Менеджер вносить кількість товару, що надходить.

10. Менеджер вносить суму заявки.

11. Менеджер закриває форму.

12. Варіант використання закінчується.

Постумовою до варіанта використання є оформлення заявки в системі та поява нового клієнта в журналі головної форми.

Розглянемо діаграму послідовності цього варіанта використання. Як очевидно з цієї діаграми менеджер, відкриваючи форму Прихід, викликає виконання кількох дій – автоматично (з погляду менеджера) заповнюється дата заявки. Список клієнтів під час оформлення заявки заповнюється з бази з первинною інформацією. Після цього менеджер вносить усі необхідні дані та натискає кнопку «Прийняти». У цьому виконуються такі дії. Всі дані передаються в процедуру, що зберігається.

3 Реалізація та атестація інформаційної системи

3.1 Реалізація програми

Реалізація програми за своєю сутністю є одним з трудомістких етапів для розробника інформаційної системи, тому що ті вимоги, які висуває замовник, повинні бути чітко і коректно інтегровані в систему. Поки що немає таких програмних продуктів, які б «підлаштовуватися» під вимоги так званого замовника і видавати певний набір функцій для реалізації системи, які відповідатимуть цим вимогам. Тому кожен розробник повинен вибрати для себе оптимальне середовище для розробки системи, але слід зазначити, що при реалізації програми не обійтися без написання програмного коду. Саме при написанні програмного коду будуть реалізовуватися деякі функції, які повинна виконувати система. Залежно від обраного середовища реалізації системи, програмний код буде виглядати по-різному, в такому середовищі як Microsoft Visual FoxPro буде один програмний код, Visual Basic інший і т.д.

В даному випадкуреалізація програми виконувалася Microsoft Visual FoxPro.

Нижче будуть описані основні функції системи:

1. Стартова форма системи. Ця форма є кнопковою формою і кожна кнопка виконує свою функцію. Кнопка реєстрація адміністратора зображена на малюнку 3.1. Дана кнопка виконає функцію, яка відкриває панель адміністратора, якщо користувач має такі права до даної системи

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

3. У кнопці меню витрата ведеться облік відпущеного товару зі складу рис 3.3.

4. У кнопці меню доступу регулюються права користування програмою рис 3.4.

5. У кнопці меню залишки зберігається інформація про матеріали, що зберігаються на складі магазину рис 3.5.

6. У кнопці меню каса зберігатиметься інформація про прибуткові касові ордери та видаткові касові ордери рис 3.6.

7. У кнопці меню переоцінка відбувається зміни ціни на нову ціну товару рис.3.7.

Рисунок 3.1 – Стартова форма системи

Рисунок 3.2 – Форма обліку надходжень матеріалу складу.

Рисунок 3.3 - Форма обліку відпущеного товару.

Рисунок 3.4 – Форма, що регулює права доступу до програми.

Рисунок 3.5 - Форма залишків товару на складі.

Малюнок 3.5 – Форма про прибуткові касові ордери та видаткові касові ордери.

Малюнок 3.6-Форма операцій з товару.

Тестування програми

Тестування – процес виконання програми з метою виявлення помилок. Тестування забезпечує:

Виявлення помилок;

демонстрацію відповідності функцій програми до її призначення;

демонстрацію реалізації вимог до характеристик програми;

Відображає надійність як індикатор якості програми.

На малюнку 3.2 подано інформаційні потоки процесу тестування.

На вході процесу тестування три потоки:

Текст програми;

Вихідні дані для запуску програми;

Очікувані результати.

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

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

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

Існують 2 принципи тестування програми:

Функціональне тестування (тестування «чорної скриньки»);

Структурне тестування (тестування «білої скриньки»).

При тестуванні методом "білого ящика" відома внутрішня структура програми. Об'єктом тестування тут не зовнішня, а внутрішня поведінка програми. Перевіряється коректність побудови всіх елементів програми та правильність їхньої взаємодії один з одним.

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

Принцип «чорної скриньки» не є альтернативним принципом «білої скриньки». Швидше це доповнює підхід, який виявляє інший клас помилок.

Тестування «чорної скриньки» забезпечує пошук наступних категорій помилок:

Некоректних чи відсутніх функцій;

Помилок інтерфейсу;

Помилок у зовнішніх структурах даних або доступу до зовнішньої бази даних;

Помилок параметрів (необхідна ємність пам'яті тощо);

Помилок ініціалізації та завершення.

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

На етапі тестування вирішують два основні завдання:

Тестування рішення - виконуються плани тестування, створені на етапі планування та розширені та випробувані на етапі розробки;

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

Мета етапу тестування - зниження ризику, що виникає під час введення рішення в промислову експлуатацію.

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

На цій стадії розробки інформаційної системи необхідно провести такі типи тестування:

Базове тестування – низькорівневе технічне тестування. Проводиться самим розробником у процесі написання програмного коду. Застосовується метод «білої скриньки», високий ризик помилок.

Тестування на придатність до використання – високорівневе тестування, що виконується тестувальником та майбутніми користувачами продукту. Застосовується метод «чорної скриньки».

Альфа- та бета-тестування – у термінах MSF альфа-код – це в основному все вихідні тексти, Створені на етапі розробки моделі процесів MSF, а бета-код – код, що пройшов тестування на етапі тестування. Тому на етапі розробки моделі процесу MSF тестується альфа-код, а на етапі тестування – бета-код.

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

Тестування продуктивності – орієнтоване на перевірку того, чи задовольняє додаток вимогам щодо продуктивності та рівня комфортності роботи за швидкістю.

Тестування документації та довідкової системи – тестуються всі розроблені супроводжуючі документи та довідкові системи.

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

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

Таблиця 3.2 - План пілотної експлуатації

Дія		Опис
1. Вибір критеріїв успіху		Розробник та учасники дослідного тестування визначають критерії успішності та узгоджують їх
2. Вибір користувачів та місця встановлення		Формується команда учасників досвідченого тестування з боку користувачів та розробників. Визначається місце розгортання пілотного процесу.
3. Підготовка користувачів та місця встановлення		Проводиться навчання користувачів – учасників випробування. Підготується місце встановлення.
4. Розгортання дослідної версії		Встановлюється досвідчена версія та входить у роботу.
5. Підтримка та моніторинг дослідної версії		Контроль роботи користувачів та системи, надання допомоги в експлуатації, збирання відомостей про роботу системи
6. Зворотній зв'язок з користувачами та оцінка результатів		Користувачі висловлюють свою думку про роботу системи, вказують на недоліки та помилки.
7. Внесення змін та доповнень	Виправляються виявлені помилки, вносяться зміни у дизайн чи процес. Виправлені результати надаються для роботи та оцінки користувачам.
8. Рішення про розгортання	Якщо результати роботи досвідченого тестування задовольняють користувачів, приймається рішення про розгортання системи.

3.2 Методика розгортання програми

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

Цілі етапу розгортання:

¾  перенести рішення у промислове середовище;

¾ визнання замовником факту завершення проекту.

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

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

Для розгортання розроблюваної системи було складено план дій, що у таблиці 3.1.

Таблиця 3.1 – План розгортання програми

Дія	Опис дії
1. Резервне копіювання	Виконується резервне копіювання даних користувача за його участі та погодження шляхом перенесення інформації на змінні носії(СD, DVD)
2. Встановлення базових компонентів рішення	Застосування технологій, які забезпечують роботу рішення. В даному випадку – установка компонента Visual FoxPro
3. Встановлення клієнтської програми	Перенесення на комп'ютер користувача та встановлення остаточного варіанта розробленої ІС та бази даних
4. Навчання	Виробляється навчання користувачів по роботі з системою, розробник переконується у правильності та розумінні роботи ІС клієнтами
5. Передача бази знань проекту клієнту	Замовнику передається вся проектна документація
6. Закриття проекту	Складається звіт про закриття проекту. Замовник підписує акт приймання.

Для нормального функціонування АРМ потрібно операційна система Microsoft Windows XP.

4 Управління інформаційним проектом

4.1 Вибір життєвого циклу розробки

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

Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Міжнародна організація зі стандартизації, IEC – International Electro technical Commission – Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії та завдання, які мають бути виконані під час створення ПЗ.

Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ та методи розробки програмного забезпечення. Під моделлю ЖЦ можна розуміти структуру, що визначає послідовність виконання та взаємозв'язку процесів, дій та завдань, що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ІВ та специфіки умов, у яких створюється та функціонує.

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

Спіральна модель (див. рисунок 4.1);

Ітераційна модель.

Рисунок 4.1 – Спіральна модель ЖЦ ПЗ

До створення інформаційної системи, тобто. "Автоматизоване робоче місце співробітника складу оптова база", була обрана ітераційна. Відмінною властивістю ітераційної моделі можна назвати те, що вона є формальним методом, вона складається з незалежних фаз, що виконуються послідовно, і схильна до частого огляду (рисунок 4.2). Ітераційний підхід добре зарекомендував себе при побудові ІВ, для яких на самому початку розробки можна досить точно і повно сформулювати всі вимоги, щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору.

Переваги ітераційної моделі:

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

Зручність та простота застосування, т.к. всі роботи виконуються поетапно (за фазами моделі);

Стабільність вимог;

Модель доступна для розуміння;

Структурою моделі може керуватися навіть слабко підготовлений у технічному плані персонал (недосвідчений користувач);

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

Модель сприяє здійсненню суворого контролю за менеджментом проекту;

Полегшує роботу менеджеру проекту зі складання плану та комплектації команди розробників.

Рисунок 4.2 – Ітераційна модель ЖЦ ПЗ

Фази моделі:

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

На стадії проектування докладніше розглядаються процеси системи. Аналізується та, за необхідності, коригується функціональна модель. Будуються прототипи системи;

На стадії реалізації розробка системи;

На стадії застосування, готовий товар впроваджується у діючу систему організації. Проводиться навчання користувачів;

На стадії супроводу відбувається обслуговування програмного продукту (будь-яке додавання або зміна, для більш функціональної роботи продукту).

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

Аналіз відмітних категорій проекту, розміщених у таблицях.

Відповісти на запитання, наведені для кожної категорії, підкресливши слова так і ні.

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

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

Колектив користувачів. На початкових стадіях проекту можна отримати повне уявлення про колектив користувачів (дивись додаток І таблиця І.1), які будуть працювати з розробленим програмним забезпеченням, та його майбутній взаємозв'язку з командою розробників протягом усього проекту. Таке уявлення допомагає при виборі підходящої моделі, оскільки деякі моделі вимагають посиленої участі користувачів у процесі розробки та вивчення проекту, оскільки вимоги можуть незначно змінюватися користувачем у процесі розробки, то розробнику необхідно знати ці зміни та як ці зміни у програмному забезпеченні.

4.2 Визначення мети та області дії програмного проекту

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

Цілями програмного проекту будуть – створення та розгортання системи з обліку товару. Ця системапризначена для внутрішнього використання персоналом «Cleonelly», переважно співробітниками складу підприємства.

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

Програмний проект має бути:

Для внутрішнього використання організації;

Проектом для здійснення розрахованого на багато користувачів доступу;

Проектом, який має можливість занесення, зміну та зберігання відомостей про товар підприємства;

Проектом, який має можливість занесення, зміну та зберігання відомостей про користувачів системи;

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

Проектом, який здійснюватиме формування зовнішньої звітності.

4.3 Створення структури поопераційного переліку робіт

Для створення унікального продукту чи послуги (результату проекту) необхідно здійснити певну послідовність робіт. Завдання планування проекту полягає в тому, щоб достатньо точно оцінити термін виконання та вартість цих робіт. Чим точніше дано оцінку, тим вище якість плану проекту. Щоб дати точну оцінку, потрібно добре уявляти склад робіт проекту, тобто знати, які саме роботи потрібно виконати для отримання результату. Тільки після того, як складено список проектних робіт, оцінюється тривалість кожної з них і виділяються ресурси, необхідні для їх виконання. І лише потім можна оцінити вартість та терміни виконання кожного завдання і, в результаті додавання, загальну вартість та термін проекту. Ось чому визначення складу робіт є першим кроком під час планування проекту. Визначення складу проектних робіт починається із визначення етапів (або фаз) проекту. Наприклад, у проекті створення системи «Облік товару на складі» можуть бути виділені фази:

Розробка вимог до програмного забезпечення;

Проектування інформаційної системи;

Реалізація та атестація інформаційної системи;

Впровадження системи.

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

Поопераційний перелік робіт (рис. 4.3) був спроектований за допомогою програмного продукту такого, як MS Project 2003.

Рисунок 4.3 – Поопераційний перелік робіт

4.4 Оцінка тривалості та вартості розробки ПЗ

Оцінка тривалості.Вона визначається після побудови поопераційного переліку робіт (рис. 4.3, пункт 4.3). Цю оцінку тривалості можна побачити за допомогою діаграми Ганта (додаток К).

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

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

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

На діаграмі Ганта поруч із відрізками може відображатися додаткова інформація (поруч із завданнями відображаються назви задіяних у яких ресурсів та його завантаження під час виконання завдання).

Оцінка витрат

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

Важлива властивість ресурсів – вартість (Cost (Витрати)) їх використання у проекті. У MS Project є два типи вартості ресурсів: погодинна ставка та вартість за використання.

Погодинна ставка (Rate) виявляється у вартості використання ресурсу за одиницю часу, наприклад 100 рублів на годину чи 1000 рублів на день. У такому разі вартість участі ресурсу в проекті становитиме час, протягом якого він працює у проекті, помножений на погодинну ставку.

У разі використовувалася погодинна ставка (рисунок 4.4) Загальні витрати використання ресурсів можна малюнку 4.5.

Рисунок 4.4 - Погодинна ставка у використанні ресурсу

На цьому малюнку можна побачити, що розробник системи при виконанні проекту отримує 50 рублів на годину; бізнес-аналітик отримує 45 рублів за годину, тестер 38 рублів за годину. Ставка понаднормових не враховується.

Рисунок 4.5 – Загальні витрати на використання ресурсів проекту

4.5 Розподіл ресурсів проекту

Фрагмент розподілу ресурсів системи «Обліку товару складі» можна побачити малюнку 4.6

Рисунок 4.6 – Фрагмент розподілу ресурсів проекту

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

4.6 Оцінка економічної ефективності проекту

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

Вхідні дані.

Додатковий прибуток від проекту (DP) = 38000 рублів. Додатковий прибуток був спрогнозований експертами підприємства.

Стартові інвестиції (IC) = 39 396,47 рублів. Стартові інвестиції відповідають загальним витратам використання ресурсів проекту (рисунок 4.5 пункту 4.6)

Ставка дисконтування (i) = 12%.

Термін, який розрахований проект (n) = 2 року.

Додатковий прибуток від проекту (DP) = 38000 рублів.

Щорічні витрати на реалізацію проекту (Z 1) = 15000 рублів.

Щорічні витрати на реалізацію проекту (Z 2) = 10000 рублів.

Річні фінансові надходження (R 1) = 23000 рублів.

Річні фінансові надходження (R 2) = 28000 рублів.

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

Центральним показником у аналізованому методі є показник NPV (net present value) – поточна вартість грошових потоків. Це узагальнений кінцевий результат інвестиційної діяльності у абсолютному вимірі.

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

Чистий наведений дохід (NPV) розраховується за формулою 4.2

(4.2)

R k - Річні грошові надходження протягом n років.

k – кількість років, на скільки розрахований проект.

IC – стартові інвестиції.

i - Ставка дисконтування.

За розрахунками цієї формули NPV = 3460,67 руб.

Показник NPV є абсолютним приростом, оскільки оцінює, наскільки наведений дохід перекриває наведені витрати. Оскільки NPV > 0, то проект слід ухвалити.

Коефіцієнт повернення інвестицій (ROI) розраховується за формулою 4.3

(4.3)

За розрахунками (ROI) = 108,78%

Таблиця 4.1 - Допоміжна таблиця розрахунку терміну окупності проекту

= 1,84

Термін окупності n ok = 1,84 року (1 рік та 11 місяців)

Оскільки ROI = > 100% (зокрема = 108,78%), то проект вважається прибутковим.

(4.4)

Таким чином, індекс прибутковості дорівнює (PI) = 1,2