Вступ

Вже згадана дипломна робота написана на базі Донецької ВАТ Донецька мануфактура для магазину 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 пропонує засіб, для збору всієї необхідної інформації про роботу підприємства і графічного зображення цієї інформації у вигляді цілісної і несуперечливої \u200b\u200bмоделі.

З точки зору функціональності системи. В рамках методології 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. Створення комплектів товарів

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

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 служить основою для модернізації. У цьому документі розглядається сам продукт, а не процес розробки проекту, тому на її підставі можна проводити розширення завершеного продукту.

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

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

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 використовується для презентацій і обговорення структури даних з експертами предметної області. Модель даних, заснована на ключах, - більш докладне уявлення даних. Вона включає опис всіх сутностей і первинних ключів і призначена для представлення структури даних і ключів, які відповідають предметної області.

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

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

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

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

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

FoxPro (Фокс-про?) - один з діалектів мови програмування xBase. Застосовується в основному для розробки реляційних СУБД, хоча можливо застосовувати для розробки та інших класів программ.Как вже зазначалося вище, мова VFP це сильно доповнений і розширений мову 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 WindowsXP.

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) \u003d 38000 рублів. Додаткова прибуток була спрогнозована експертами підприємства.

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

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

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

Додатковий прибуток від реалізації проекту (DP) \u003d 38000 рублів.

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

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

Річні грошові надходження (R 1) \u003d 23000 рублів.

Річні грошові надходження (R 2) \u003d 28000 рублів.

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

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

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

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

(4.2)

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

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

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

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

За розрахунками даної формули NPV \u003d 3460,67 руб.

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

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

(4.3)

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

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

= 1,84

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

Так як ROI \u003d\u003e 100% (а саме \u003d 108,78%) то проект вважається прибутковим.

(4.4)

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

Рис. 6.2.

(Інформаційна система підприємства)

Аутсорсинг корпоративних інформаційних систем

Аутсорсинг виробничих функцій і бізнес-процесів на основі корпоративних інформаційних систем дозволяє використовувати новітні досягнення і «кращі практики» сучасного менеджменту. Впровадження корпоративних інформаційних систем лежить в основі реінжинірингу бізнес-процесів (Business Process...
(Аутсорсинг і аутстаффінг: високі технології менеджменту)

Патерни інтеграції корпоративних інформаційних систем

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

ФУНКЦІОНАЛЬНІ ЗАВДАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ПІДПРИЄМСТВА ТА ОСНОВНІ МОДУЛІ СУЧАСНИХ ІНФОРМАЦІЙНИХ СИСТЕМ ПІДПРИЄМСТВА. ІНТЕГРАЦІЯ МОДУЛІВ

Змістовне значення поняття модуля передбачає зіставлення функціональних підсистем, функціональних завдань при функціонально-окремих завданнях підході з основними модулями совре- Рис. 6.2. Зіставлення функціональних завдань з основними модулями сучасних ІКІСП -сних інформаційних систем підприємства, ...
(Інформаційна система підприємства)

ПОНЯТТЯ, ІСТОРІЯ РОЗВИТКУ І КЛАСИФІКАЦІЯ ІНФОРМАЦІЙНИХ СИСТЕМ ПІДПРИЄМСТВА. ІНТЕГРОВАНІ КОРПОРАТИВНІ ІНФОРМАЦІЙНІ СИСТЕМИ ПІДПРИЄМСТВА

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

ОСОБЛИВОСТІ СУЧАСНИХ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ У інформаційних системах ПІДПРИЄМСТВА

Сучасні технології ОРГАНІЗАЦІЇ ВВЕДЕННЯ ДАНИХ В КОРПОРАТИВНИХ ІНФОРМАЦІЙНИХ СИСТЕМАХ Інформація про господарські операції повинна своєчасно надходити в оперативну базу даних з будь-яких джерел її виникнення. Це дозволить ефективно організувати подальшу обробку даних в інформаційних ...
(Інформаційна система підприємства)

Виходячи з призначення розробляється інформаційної системи, спроектуємо далі модульну структуру програми. Для визначення модульної структури скористаємося діаграмою компонентів нотації UML 2.0 (рис. 3.4).

Рис. 3.4

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

• 1. Інтерфейс. Реалізація взаємодії користувачів з інформаційною системою. Містить в собі наступні модулі:
  • · Введення / висновок - організація введення і виведення інформації при роботі з ІС;
  • · Звітність - організація ведення звітності відповідно до встановлених форм документації по різним областям діяльності кадрового агентства;
  • · Пошук - організація пошуку кандидатів і вакансій по заданих параметрах;
• 2. Обробка даних. Реалізація функцій обробки інформації: пошук даних в БД, математичної моделі для завдання первинного аналізу документів т.д .;
• 3. БД. Реалізація сховища даних, в якому міститься інформація про клієнтів.

Розробка структури бази даних

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

• · Визначення сутностей; визначення залежностей між сутностями;
• · Завдання первинних і альтернативних ключів;
• · Визначення атрибутів сутностей;
• · Приведення моделі до необхідному рівню нормальної форми;
• · Перехід до фізичного опису моделі: призначення відповідностей ім'я сутності - ім'я таблиці, атрибут сутності - атрибут таблиці;
• · Завдання тригерів, процедур і обмежень;
• · Генерація бази даних.

Діаграма сутність-зв'язок, що описує БД в термінах IDEF1.x, будується з трьох основних блоків - сутностей, атрибутів і зв'язків. Якщо розглядати діаграму як графічне представлення правил предметної області, то сутності й атрибути є іменниками, а зв'язку - дієсловами.

Оскільки майбутня ІС по даній БД буде здійснювати пошук, то в якості основних атрибутів для документа було обрано такі:

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

Результат запиту на вибірку всіх документів належать одному клієнту повинен виглядати наступним чином див. Малюнок 3.5. У представленому прикладі кількість документів мало намір обмежено 20.

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

Рис. 3.5

Рис. 3.6

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

Сутність «Співробітник», що є незалежною сутністю має атрибути:

• · Ідентифікаційний номер співробітника - є первинним ключем даної суті;
• · ПІБ співробітника;
• · Область спеціалізації;
• · Рейтинг;
• · Додаткова інформація.

Сутність «Клієнт», є залежною сутністю від сутності «Співробітник», що говорить про те, що кожен співробітник може обслуговувати безліч клієнтів. Сутність клієнт має атрибути:

• · Серія та номер паспорта - є первинним ключем даної суті;
• · Ідентифікаційний номер співробітника - є вторинним ключем даної суті;
• · ПІБ співробітника;
• · Область спеціалізації;
• · Рейтинг;
• · Додаткова інформація.

Сутність «Документ», є залежною сутністю від сутності «Клієнт», що говорить про те, що кожен клієнт може зберігати в архіві безліч різних документів. Сутність документ має атрибути:

• · Ідентифікатор документа - є первинним ключем даної суті;
• · Серія та номер паспорта - є вторинним ключем даної суті;
• · Назва документу;
• · Дата надходження;
• · Приналежність до групи;
• · Номер стовпця;
• · Номер полиці;
• · Номер санчата;
• · Присутність документа в осередку.

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

Відповідно до визначення функціональними елементами ІС є наступні групи (блоки) процесів:

введення інформації з зовнішніх чи внутрішніх джерел;

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

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

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

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

Окремі частини (блоки системи) називають підсистемами.

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

Структура ІС може бути представлена \u200b\u200bі як комплекс підсистем (рис.2).

Рис.1. Узагальнена функціональна блок-схема ІС.

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

Рис.2. Блок-схема САПР

Розглянемо інший тип структури ІС: як комплексу підсистем (рис.3).

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

Таким чином, структура будь-якої інформаційної системи може бути представлена \u200b\u200bсукупністю забезпечують підсистем.

Рис.3. Структура ІС по типу забезпечують підсистем.

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

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

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

до уніфікованих систем документації;

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

до складу та структури реквізитів і показників;

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

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

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

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

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

є показники, які створюються, але не використовуються, і ін.

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

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

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

виключення дублюючої і невикористаної інформації;

класифікацію і раціональне подання інформації.

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

Основні концепції методології:

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

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

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

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

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

створення масивів інформації на машинних носіях, що вимагає наявності сучасного технічного забезпечення.

Ця концепція практично реалізується в два етапи.

1-й етап - обстеження всіх функціональних підрозділів фірми з метою:

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

побудувати схему інформаційних потоків;

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

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

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

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

Комплекс технічних засобів становлять:

комп'ютери будь-яких моделей;

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

пристрою передачі даних і ліній зв'язку;

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

експлуатаційні матеріали та ін.

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

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

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

нормативно-довідкову, використовувану при виконанні розрахунків по технічному забезпеченню.

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

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

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

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

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

До засобів математичного забезпечення відносяться:

засоби моделювання процесів управління;

типові завдання управління;

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

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

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

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

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

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

Організаційне забезпечення реалізує наступні функції:

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

підготовку завдань до вирішення на комп'ютері, включаючи технічне завдання на проектування ІС і техніко-економічне обґрунтування її ефективності;

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

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

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

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

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

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

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

права, обов'язки і відповідальність персоналу;

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

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

Цілі створення і впровадження ІС.

Чого можна очікувати від впровадження інформаційних систем?

Впровадження інформаційних систем може сприяти:

1. звільнення працівників від рутинної роботи і її прискорення за рахунок автоматизації;

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

3. вдосконалення структури потоків інформації і системи документообігу в фірмі за рахунок ефекту системності: одноразовий введення даних - багаторазове і багатоцільове їх використання »;

4. отримання більш раціональних варіантів вирішення управлінських завдань (за рахунок впровадження математичних методів та інтелектуальних систем і т.д.):

відшукання нових ринкових ніш;

оптимізація витрат на виробництво продуктів і / або послуг;

оптимізація взаємовідносин з покупцями і постачальниками.

Етапи розвитку інформаційних систем

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

Таблиця 2. Етапи розвитку ІС.

Період часу	Концепція використання інформації	Вид інформаційних систем	Ціль використання
1950 - 1960 рр.	Паперовий потік розрахункових документів	Інформаційні системи обробки розрахункових документів на електромеханічних бухгалтерських машинах	Підвищення швидкості обробки документів Спрощення процедури обробки рахунків і розрахунку зарплати
1960 - 1970 рр.	Основна допомога у підготовці звітів	Управлінські інформаційні системи для виробничої інформації	Прискорення процесу підготовки звітності
1970 - 1980 рр.	Управлінський контроль реалізації (продажу)	Системи підтримки прийняття рішень Системи для вищої ланки управління	Вибірка найбільш раціонального рішення
1980 - 2000 рр.	Інформація - стратегічний ресурс, що забезпечує конкурентну перевагу	Стратегічні інформаційні системи автоматизовані офіси	Виживання і процвітання фірми

Перші інформаційні системи з'явилися в середині минулого століття. У 50-ті роки вони були призначені для обробки рахунків і розрахунку зарплати, а реалізовувалися на електромеханічних бухгалтерських рахункових машинах. Це призводило до деякого скорочення витрат і часу на підготовку паперових документів.

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

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

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

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