Автоматизована система складського обліку в ЗАТ Бєлгородський бройлер

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати


Зміст

Введення

Глава 1: Вибір методології розробки

Глава 2: Дослідження

Глава 3: Проектування

3.1 Платформа. NET

3.2. Огляд ASP.NET

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

3.2.1 Логічне проектування

3.2.2 Фізичне проектування

Глава 4: Розробка

4.1 Borland Delphi 2005

4.2 Архітектура

4.3 HTML прототипи

4.4 Бізнес логіка

4.5 Розробка інтерфейсу користувача

Глава 5: Економічний ефект

5.1 План аналізу економічної ефективності

5.2 Техніко-економічне обгрунтування розробки ПЗ

5.3 Розрахунок витрат на розробку ПЗ

5.4 Вартість впровадження ПЗ Замовником

5.5 Витрати замовника при експлуатації ПЗ

5.6 Ефективність впровадження для Замовника ПЗ

5.7 Правові аспекти

Висновок

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

Введення

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

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

У даній роботі будуть показані переваги розробки та впровадження власного програмного продукту на додаток до наявного типовим рішенням "1С Підприємство: Торгівля і склад".

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

У відділі збуту і роздрібних продажів ЗАТ "Бєлгородський бройлер" використовується пакет програм "1С Підприємство". Поки кількість філій (роздрібних магазинів) обмежувалося двома і асортимент продукції складався з декількох найменувань особливих проблем не було. Але з розвитком філіальної мережі магазинів (зараз їх сім) з'явилися нові вимоги до ПЗ складського обліку.

Малюнок 1

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

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

  • низька актуальність даних - оновлення даних відбувається не частіше 1 разу на день;

  • подвійне введення даних - перший раз - при продажу \ надходженні товару, другий раз - при обліку цієї ж операції в системі "1С: Підприємство";

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

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

Малюнок 2

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

Зниження витрат на збір даних про рух товарів у роздрібних магазинах компанії.

Для досягнення цієї мети необхідно:

  • Мінімізувати людський фактор при зборі даних про товарообіг;

  • Збільшити швидкість збору даних про товарообіг;

  • Створити єдину картину товарообігу всіх філій.

Також для компанії важливим буде побічний ефект від проекту:

  • Підвищення іміджу компанії як IT орієнтованою.

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

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

По ряду причин для вирішення поставлених завдань замовнику не підійшло клієнт-серверне рішення у форматі "1С: Підприємство":

  • висока вартість рішення при зростанні числа магазинів;

  • високі вимоги до каналів передачі даних;

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

  • відсутність web-інтерфейсу.

Було вирішено, що розробка такого собі простого (з точки зору користувача інтерфейсу) і легені (з точки зору системних вимог та вимог до каналів зв'язку) web-орієнтованого додатки з функцією конвертації даних в "1С: Підприємство" буде кращим рішенням ситуації, що склалася.

Глава 1: Вибір методології розробки

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

Існує безліч різних методологій. Серед них виділяють великовагові та гнучкі методології. Для великовагових методологій необхідне детальне планування великого обсягу розробок, великий обсяг документації, і такий підхід працює - проте до тих пір, поки не почнуться зміни. Отже, для цих методологій чинити опір всяким змінам абсолютно природно. Гнучкі ж методології, навпаки, зміни вітають. На відміну від великовагових, вони були задумані як процеси, які адаптують зміни і тільки виграють від них, навіть у тому випадку, коли зміни відбуваються в них самих. Найбільш відомими і популярними гнучкими методологіями в даний час є RUP (Rational Unified Process) і XP (eXtreme Programming).

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

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

Враховуючи складність системи, що розробляється, а також вимоги до адаптивності, ми вибрали як методології розробки RUP. Творці RUP визначають його як ітеративний, архітектурно-орієнтований та керований прецедентами використання процес розробки програмного забезпечення [9]. Основа RUP: розробка концепції; управління за планом; зниження ризиків і відстеження їх наслідків; ретельна перевірка економічного обгрунтування; використання компонентної архітектури; Прототипування, інкрементне створення і тестування продукту; регулярні оцінки результатів; управління змінами; створення продукту, придатного до вживання; адаптація RUP під потреби свого проекту.

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

  • визначення вимог (Requirements);

  • проектування та аналіз (Design & Analysis);

  • розробка (Development);

  • тестування (Testing);

  • розгортання і супровід (Deployment & Operations).

Кожен з цих етапів повинен ретельно відстежуватися і контролюватися. Правильно організована ALM-система дозволяє:

  • скоротити терміни виведення продуктів на ринок (розробникам доводиться дбати лише про відповідність їх програм сформульованим вимогам);

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

  • підвищити продуктивність праці (розробники отримують можливість ділитися передовим досвідом розробки та впровадження);

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

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

  • отримати максимальну віддачу від інвестицій в навички, процеси та технології.

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

Рис. 1.1 Етапи життєвого циклу ALM Borland

Реалізація ALM-стратегії у виконанні Borland полягає у наданні комплексу взаємопов'язаних інструментів для всіх етапів життєвого циклу програм, таких, як визначення вимог, аналіз та проектування, розробка, тестування, розгортання і керування [13]. Етапи життєвого циклу зображені на малюнку 1.1. Дана стратегія компанії Borland досить гнучка і адаптуються під будь-яку методологію, в тому числі і обрану нами RUP. У рамках даної стратегії компанія випустила ряд продуктів, які ми збираємося використовувати в своїй роботі, головною перевагою яких є тісна інтеграція один з одним:

  • Borland CaliberRM 2005;

  • Borland Together Designer 2005;

  • Borland StartTeam 2005;

  • Borland Delphi 2005.

Rational Unified Process (RUP) - одна з найбільш досконалих технологій, що претендують на роль світового корпоративного стандарту. RUP в значній мірі відповідає стандартам і нормативним документам, пов'язаним з процесами життєвого циклу ПЗ і оцінкою технологічної зрілості організацій-розробників (ISO 12207, ISO 9000, CMM і ін.) Її основними принципами є:

    1. Ітераційний і інкрементний (нарощуваний) підхід до створення ПЗ.

    2. Планування і управління проектом на основі функціональних вимог до системи - варіантів використання.

    3. Побудова системи на базі архітектури ПЗ.

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

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

На малюнку 1.2 показано загальне уявлення RUP у двох вимірах. Горизонтальне вимірювання являє час, відбиває динамічні аспекти процесів і оперує такими поняттями, як стадії, ітерації і контрольні точки. Вертикальний вимір відбиває статичні аспекти процесів і оперує такими поняттями, як види діяльності (технологічні операції), робочі продукти, виконавці та дисципліни (технологічні процеси).

Згідно RUP, життєвий цикл ПО розбивається на окремі цикли, в кожному з яких створюється нове покоління продукту [5]. Кожний цикл, у свою чергу, розбивається на чотири послідовні фази, кожна з яких переслідує свої цілі:

  • Фаза Дослідження (inception), призначена для створення моделі предметної області;

  • Фаза Опрацювання (elaboration), призначена для створення базової архітектури;

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

  • Фаза Перехідний період (transition), необхідна для перевірки готовності продукту до експлуатації;

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

Рис. 1.2 Представлення стадій і робіт RUP

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

Статичний аспект RUP представлений чотирма основними елементами:

  • ролі;

  • види діяльності;

  • робочі продукти;

  • дисципліни.

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

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

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

У рамках RUP визначено шість основних дисциплін:

  • побудова бізнес-моделей;

  • визначення вимог;

  • аналіз та проектування;

  • реалізація;

  • тестування;

  • розгортання.

і три допоміжних:

  • управління конфігурацією і змінами;

  • управління проектом;

  • створення інфраструктури.

RUP грунтується на шести кращих практиках (best practices):

  • Ітеративна розробка;

  • Управління вимогами;

  • Використання модульних архітектур;

  • Візуальне моделювання;

  • Перевірка якості;

  • Відстеження змін.

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

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

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

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

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

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

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

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

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

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

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

Глава 2: Дослідження

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

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

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

  • виявляються основні ризики;

Фаза завершується формулюванням цілей проекту.

Докладний аналіз вимог замовника дозволив створити єдину картину функціональності майбутньої системи. Перш за все було визначено 3 користувача системи:

Продавець - особа, яка працює на контрольно-касовому апараті.

Адміністратор - особа, що веде кількісний облік товарів.

Менеджер - керуючий компанією.

Потім були виділені функції кожного користувача:

Користувач

Функція

Опис

Продавець

Авторизація

Вхід в Систему за своїм логіном і паролем


Запит допомоги

Звернення до адміністратора у разі технічних неполадок


Витрата

Створення та зміна видаткової накладної

Адміністратор

Авторизація

Вхід в Систему за своїм логіном і паролем


Запит допомоги

Звернення до адміністратора у разі технічних неполадок


Прихід

Створення та редагування прибуткової накладної


Редагування накладних

Управління вже збереженими витратними і прибутковими накладинмі


Редагування списку "Постачальники"



Редагування списку "Каталог"



Редагування списку "Магазини"


Менеджер

Авторизація

Вхід в Систему за своїм логіном і паролем


Запит допомоги

Звернення до адміністратора у разі технічних неполадок


Створення звіту про залишки

Перегляд кількісної інформації по залишках на складах


Створення звіту про обороти

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

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

Глава 3: Проектування

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

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

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

  • збір схем використання, що покривають мінімум 80% функціональних можливостей системи;

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

Принципова відмінність RUP від багатьох інших ітеративних підходів полягає великої уваги до розробки архітектури системи. Архітектура в RUP включає в себе тип організації системи та використовуються типові рішення. Крім того, архітектура в RUP - це ще й ключова частина коду (зазвичай, до 20% загального обсягу), яка дозволяє продемонструвати відповідність системи основним функціональним і нефункціональним вимогам. Тому в RUP часто говориться про поняття "архітектурний каркас" [10]. Орієнтація на архітектуру означає, що розробку програмного забезпечення починають з розробки архітектурного каркаса, а потім нарощують додаткову функціональність, максимально використовуючи відпрацьовані при створенні каркасу типові рішення. Це дає можливість використовувати RUP для вирішення таких завідомо складних завдань, як розробка систем з використанням нових технологій (наприклад, мов програмування або платформ), а також знижує трудомісткість розробки, що дозволяє уникати багаторазового рішення схожих завдань.

Основним інструментом розробника на даному етапі виступає Together Designer 2005. Проектування ведеться на мові UML з використанням мінімально необхідного набору діаграм для спрощення подальшого процесу розробки, а саме: діаграм класів, діаграм послідовностей, діаграм компонентів і діаграм розгортання.

3.1 Платформа. NET

13 лютого 2002 відбувся офіційний старт нової платформи Microsoft. NET - на грандіозній презентації в Сан-Франциско, були представлені робочі версії двох головних її елементів: операційного середовища. NET Framework та інструментального набору Visual Studio. NET. Що нового пропонують ці кошти, що вони обіцяють розробникам і користувачам?

На жаль, незважаючи на велику кількість публікацій про дані продуктах, багато чого залишається вельми туманним. Найдивовижніше, що "димову завісу" активно підтримує і сама Microsoft. Наприклад, в офіційному прес-релізі з приводу виходу новинок написано, що це "наріжні камені в реалізації стратегії Microsoft відносно XML Web Services". Хоча навіть при поверхневому погляді видно, що. NET Framework і VS.NET ніяк явно не пов'язані з цими сервісами.

Не кажучи вже про те, що технологія XML Web Services базується на відритих стандартах і є платформно-незалежною. У зв'язку з цим представляється корисним уважніше розібратися з архітектурними рішеннями, що лежать в основі одного з базових елементів Microsoft. NET, - операційного середовища. NET Framework.

Нова операційна середовище

Структура. NET Framework показана на рис. 1, з якого видно, що це середовище являє собою додатковий операційний шар, що розділяє додатки користувача і базові сервіси Windows. Таким чином,. NET Framework - це фактично нова платформа розробки і виконання прикладних програм.

Хотілося б відзначити, що термін "платформа" ми зазвичай застосовуємо в двох різних значеннях. З одного боку, це "концепція" (ідеї, специфікації і т. д.), з іншого - набір цілком конкретних об'єктів (файлів, документації тощо). Ця двоїстість повною мірою відноситься до. NET Framework.

Рис. 1. Структурна схема. NET Framework

В даний час поставляється програмний набір. NET Framework SDK 1.0, в який крім власне модулів операційного середовища входять документація, а також ряд автономних компіляторів - VB, C # (тобто розробку простих. NET-додатків можна вести і без візуального середовища Visual Studio . NET). Пакет встановлюється поверх Windows NT 4.0, 2000 або XP в підкаталог WINNT \ Microsoft.NET \ Framework \ v1.0.XXX. Він розповсюджується безкоштовно (його можна завантажити з Web-сайту Microsoft) або в складі VS.NET.

. NET Framework складається з двох головних компонентів: бібліотеки базових класів і CLR (Common Language Runtime - загальна для мов середовище виконання NET-додатків), які відповідно призначені для вирішення наступних завдань:

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

  • підвищення керованості додатків з точки зору безпеки та ефективного використання ресурсів.

У цьому середовищі ведеться розробка і виконання програм. Головним інструментом створення додатків є звичайно ж Visual Studio. NET, в якому кожна з мов програмування взаємодіє з. NET Framework через загальний інтерфейс. До складу VS.NET входить декілька мов Microsoft, серед яких найважливіша роль відводиться C / C + +, C # і VB.

У саму середовище розробки увійшли кошти, раніше реалізовані у вигляді пакету Visual InterDev. VS.NET дозволяє створювати. NET-додатки різних типів, але всі вони є тими чи іншими модифікаціями трьох базових варіантів - Console Application, Windows Application і Class Library.

Створення універсального середовища розробки і загальних базових функцій зумовило те, що відтепер всі мови програмування Microsoft поставляються у вигляді єдиного пакету (наприклад, окремого продукту VB.NET вже немає). Крім того, це сильно спрощує підключення до неї (у вигляді додаткових модулів Add-Ins) інших мов програмування. В даний час про створення таких коштів (Cobol, Fortran, Perl та ін) оголосили багато розробників. Крім того, деякі постачальники (зокрема, Borland) пропонують власні інтегровані засоби програмування для. NET.

Представники Microsoft, порівнюючи. NET з конкуруючої Java 2 Platform, часто підкреслюють, що корпорація зовсім не прагне домінувати в області мов програмування, надаючи всім розробникам рівні можливості (прозорий натяк на Sun). У якійсь мірі це справедливо (хоча "пільгові" умови для Microsoft закладені в. NET спочатку), але найважливіше полягає зовсім в іншому: всі незалежні інструменти будуть тільки в середовищі. NET Framework.

Бібліотека базових класів

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

Втім, говорити про різні наборах функцій для різних мов в "до. NET-івські" часи можна з великою часткою умовності. Та ж Microsoft для QuickBasic і QuickC використовувала єдині внутрішні конструкції та бібліотеки підпрограм ще наприкінці 80-х років. А компілятори VB спочатку були реалізовані за допомогою проміжного коду на Сі.

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

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

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

Наприклад, бібліотеки MFC VC + + - це набір статичних об'єктних модулів, які підключаються до додатка на етапі компонування виконуваного модуля програми і стають при цьому його складовою частиною. А. NET Class Library - динамічні бібліотеки класів, які є компонентом. NET Framework.

Рис. 2. Склад бібліотек базових класів

Про достоїнства застосування об'єктних бібліотек (LIB) і бібліотек класів (DLL) відтепер можна говорити лише з точки зору академічного інтересу. Адже розробники. NET позбавлені можливості вибору (за винятком тих, хто пише на C / C + +, які займають особливе становище в засобах розробки. NET). Очевидно, що прив'язка прикладної програми до платформи. NET істотно зросла в порівнянні з традиційною Windows.

Бібліотека класів. NET реалізована у вигляді набору DLL (зараз їх 20), імена яких починаються з ідентифікатора System (мал. 2). До речі, з малюнка добре видно, що за підтримку технології Web Services відповідає лише одна з DLL.

Відразу потрібно підкреслити, що хоча дані файли мають розширення DLL, - мова йде про новий тип бібліотек, відмінному від звичайних DLL і ActiveX (COM) DLL (незрозуміло, навіщо потрібно використовувати одне розширення для файлів різних типів - це призводить до плутанини).

. NET і COM-об'єкти

Class Library - лише базовий набір функцій, який можна розширювати за рахунок додаткових бібліотек. NET-об'єктів, створюваних незалежними розробниками. У кілька спрощеній формі відмінність між системними і додатковими бібліотеками полягає в тому, що перші автоматично доступні для додатків (як частина ОС!), А другі потрібно підключати індивідуально.

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

На відміну від плоского ідентифікатора типу "ІмяПріложенія.ІмяКласса" в COM, тепер можна використовувати "ІмяПріложенія.Імя1.Імя2 .... ІмяКласса". Якщо раніше, наприклад в VB 6.0, модуль класу міг містити лише один клас, то тепер (VB.NET) один модуль може включати ієрархію класів:

Public Class Class0 'об'єкт нульового рівня

'Код класу

End Class

Namespace Name1 'об'єкти перший рівня

Public Class Class1

End Class

Public Class Class2

End Class

Namespace Name2 'об'єкти друга рівня

Public Class Class2

End Class

End Namespace

End Namespace

Відповідно повні імена об'єктів для цього модуля, включеного до MyClass.dll, будуть виглядати наступним чином:

MyClass.Class0

MyClass.Name1.Class1

MyClass.Name1.Class2

MyClass. Name 1. Name 2. Class 2

Для використання скорочених імен об'єктів допускається імпорт просторів імен:

Imports MyClass

Imports MyClass. Name 1

Тоді в програмі до об'єктів можна звертатися з такими іменами: Class0, Class1, Class2, Name2.Class2. Зрозуміло, що використовувати імпорт просторів імен потрібно дуже акуратно, щоб не виникло протиріч ідентифікаторів класів.

У наведеному вище прикладі ми не можемо імпортувати MyClass.Name1.Name2, так як виникне невизначеність для імені Class2 (воно зустрічається двічі в різних просторах імен).

Об'єднання окремих. NET-компонентів у один додаток безпосередньо пов'язано з новим поняттям "збірка" (Assembly). Як відомо, з контролем версій в COM справа йшла, м'яко кажучи, не найкращим чином. Фактично підтримка сумісності версій була повністю покладена на розробника COM-об'єктів.

Технологія. NET Assembly покликана вирішити всі ці проблеми, відомі під назвою DLL Hell (пекло DLL). У спрощеному вигляді ідея полягає в перенесенні процедур реєстрації об'єктів з системного Реєстру на рівень окремих додатків.

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

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

Що стосується рішення проблем DLL Hell, то, крім жорсткого контролю за використовуваними версіями, воно включає також просте створення локальних копій зовнішніх компонентів всередині каталогу з даними додатком (тобто складання буде включати не посилання на компонент, а сам компонент).

Common Language Runtime

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

Фактично CLR виконує програми, написані тільки на одному стандартному мовою Microsoft Intermediate Language (MSIL), який у свою чергу відповідає специфікаціям Common Language Specification. До речі, MSIL - це цілком реальний мова програмування (з використанням синтаксису в стилі "Сі"), на ньому можна писати вихідні модулі і транслювати їх за допомогою автономного компілятора, який входить до складу. NET Framework SDK *.

* Насправді точним аналогом Java (з точки зору його ролі для платформи) є саме MSIL - мова платформи. NET нижнього рівня, ". NET-Assembler".

Всі ж інші мови, в тому числі і C #, - це мови верхнього рівня, платформно-незалежні. Можна було б легко включити MSIL у візуальну середовище Visual Studio. NET, але, мабуть, Microsoft вирішила не дражнити гусей, щоб мати можливість говорити про "рівні права для всіх постачальників засобів програмування".

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

Однак, на відміну від класичної схеми інтерпретатора, використовуваної в тому числі і в Java, CLR виконує байт-код шляхом попередньої компіляції в машинний код окремих фрагментів програми або програми цілком (рис. 3).

Перший варіант є основним, при цьому застосовується так званий Just-In-Time - компілятор, який виконує перетворення MSIL в машинний код по мірі звернення до відповідних процедур (тобто невживані фрагменти програми зовсім не компілюються). Даний підхід теж достатньо відомий, він, зокрема, вже кілька років використовується в платформі "1С: Підприємство".

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

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

Програми на мові MSIL створюють так званий "керований код" (managed code). Це означає, що CLR не просто перетворює MSIL в машинні інструкції, а виконує ці дії з урахуванням зовнішніх установок.

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

Microsoft пропонує три мови програмування в складі Visual Studio. NET для формування "керованого коду" (створення. NET-додатків) - VB, C # і спеціальний варіант С + + With Managed Extensions. Як видно з цього списку, Visual C + займає абсолютно особливу позицію в засобах розробки Microsoft: з його допомогою можна писати як традиційні Windows-програми з "некерованим кодом" (unmanaged code), так і. NET-додатки, що виконують у середовищі CLR.

Що стосується платформну незалежності, то начебто CLR має всі передумови для цього, адже потрібен лише JIT-компілятор (як це робиться для Java). Але я не поділяю оптимізму деяких експертів, які вважають можливим поява найближчим часом подібних засобів, наприклад, для Linux. По-перше, в CLR спочатку задіяні базові служби Windows.

По-друге, Microsoft зовсім інакше, ніж Java-спільнота, трактує поняття многоплатформная: JIT-компілятори з'являться для різних типів апаратури (кишенькові ПК, мобільні телефони тощо), але працювати вони будуть тільки в середовищі Windows. NET!

Що попереду

Сегодня. NET Framework - це якась додаткова операційне середовище, що встановлюється в Windows в якості автономного програмного компонента. Немає сумнівів, що вона стане невід'ємною частиною майбутньої версії Windows. Проте ще кілька років користувачі Windows будуть мати можливість працювати як в режимі "Win API + COM", так і. NET. Але потім їм доведеться забути про "старому, доброму Windows" і працювати виключно в режимі "керованого коду" в середовищі CLR. Це відбудеться набагато швидше, ніж у період "від DOS до Windows".

3.2. Огляд ASP. NET

Влітку 2001го року Microsoft представила нову прогресивну платформу. NET, а з нею кілька дуже привабливих технологій, у тому числі ASP.NET, також звану ASP +. Дана стаття присвячена огляду цієї серверної технології Microsoft. Можливості ASP.NET настільки вражають, що її важко назвати наступною версією ASP. ASP 3.0 було випущено не дуже давно, але ASP.NET побудована на інших принципах. В її основі лежить інша платформа, і основними мовами програмування для неї обрані C # і VB, замість колишніх скриптінг мов. У той же час, нова технологія дозволяє писати ASP сторінки на вашому улюбленому мовою. Ми будемо дотримуватися C # в прикладах. На нашому сайті ви можете знайти статті та підручники, присвячені цій мові програмування.

У ASP.NET закладено все, для того, щоб зробити весь цикл розробки веб-додатки більш швидким, а підтримку простіше. Отже, докладніше.

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

Можливості.

Компілювання коду.

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

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

Бібліотеки

Тепер при написанні коду ви можете використовувати набір компонентів, що поставляються з. NET, а він, треба зауважити, не малий. Ну ось, наприклад, використання System.Web.Util. Правда, милий приклад? А використання Common Language Runtime бібліотеки класів, API якої специфікована, тягне за собою зменшення коду, який потрібно писати розробнику, прискорення процесу розробки, спрощується встановлення та перенесення програми.

ADO +

У ASP.NET коді, як і в будь-якому іншому коді під. NET, ви можете використовувати ADO +. Тут можна згадати, наприклад, можливість збереження датасета в XML і завантаження його з XML, що спрощує розробку розподілених додатків на основі ASP.NET, зокрема корисно при передачі даних між веб-сервісами ASP.NET.

Підтримка засобів розробки

Visual Studio.NET надає можливість WYSWYG створення і редагування, включає в себе засоби, що спрощують створення і портування програм. Також спрощує налагодження скриптів. Але безсумнівно, ніхто не відбере від вас можливість написання коду в улюбленому редакторі, будь то CodeWright, EditPlus або NotePad.

Мовна незалежність

ASP.NET працює в рамках Common Language Runtime, що дозволяє писати ваш код на будь-якій мові, для якого написаний компілятор, що підтримує цю технологію. Вже в preview версії була підтримка VB і С #, зараз працює підтримка JScript.

Можливості розширення рішення

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

Обробка помилок.

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

Об'єктно-орієнтована розробка.

Використання C # дозволяє повною мірою використовувати концепції, методи і патерни об'єктно-орієнтованої розробки.

Повторне використання.

Крім можливостей об'єктно-орієнтованого програмування, ASP.NET представляє нові технології, такі як пейджлети (pagelets), нову концепцію установки (bin) та інші можливості.

Набір серверних ASP.NET компонент.

У комплект ASP.NET оболонки входять серверні компоненти. Це такі компоненти, як валідатори, листові компоненти, rich контроли (наприклад, календар).

Огляд ASP.NET Framework

Як відображення глобальних змін у технології, не могла не змінитися і внутрішня структура ASP. Якщо ASP представляла з себе ISAPI DLL, з набором компонент і декількома системними файлами, то ASP.NET - частина глобальної платформи. NET. Ця платформа - частина нової стратегії Microsoft і відповідає всім сучасним стандартам розробки як розподілених систем, так і настільних додатків.

Мова. NET - C # зараз стандартизуется, як і його середовище виконання, що дасть можливість перенести платформу на різні системи.

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

У нову платформу вбудовані такі необхідні можливості, як контроль версій і важлива для мережевих рішень підвищена безпека. Середовище виконання коду включає в себе збирач сміття і набір бібліотек, готових до іспользованію.Код для. NET Framework компілюється в загальний проміжний мова (Intermediate Language-IL). У разі ASP.NET код компілюється при першому зверненні до сторінки і зберігається для подальших викликів. При виконанні оболонка компілює проміжний код в бінарний і виконує його. Кешування готового бінарного коду дозволяє поліпшити ефективність.

Intermediate Language дозволяє створювати ваші системи на будь-якому зручному для вас мовою. І незалежно від того, використовуєте ви C #, VB.NET, JScript.NET або Perl.NET, ви отримуєте код, готовий до виконання.

. NET Framework надає вам і загальний інтерфейс звернення до баз даних - ADO +. Він тісно інтегрований з XML, що дає вам додаткові переваги при розробці розподілених додатків.

Резюме

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

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

3.2.1 Логічне проектування

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

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

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

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

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

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

Товар - безпосередньо сам переміщуваний об'єкт. Ця сутність має такими атрибутами:

Назва (Name) - коротке найменування товару

Опис (Description) - повне наіменвоаніе товару

Одиниця виміру (Edizm) - одиниця виміру товару: шука, упаковка, кілограм і т.д.

Ціна (Price) - кінцева роздрібна ціна. Дана ціна позначається на відповідному ціннику.

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

Назва (Name) - коротке найменування постачальника

Опис (Description) - повне найменування постачальника

ПІБ (FIO_contact) - ПІБ контактної особи даного постачальника

Телефон (Tel) - номер контактного телефону постачальника

Факс (Fax) - номер контактного факсу постачальника

Адреса (Address) - юридична адреса постачальника

Магазин - характеризує конкретний магазин роздрібної мережі. Ця сутність має такими атрибутами:

Назва (Name) - офіційне юридична назва магазину

Телефон (Tel) - номер контактного телефону магазину

Факс (Fax) - номер контактного факсу магазину

Адреса (Address) - юридична адреса магазину

ПІБ (FIO_contact) - ПІБ контактної особи даного магазину

Склад - місце зберігання товару. Ця сутність має такими атрибутами:

Назва (Name) - загальноприйнята назва складу

Телефон (Tel) - номер контактного телефону складу

Адреса (Address) - адреса складу

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

Для опису руху товару необхідно виробити такі сутності, як Приходная накладна і Видаткова накладна:

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

Дата (Date) - дата проведення документа.

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

Список відповідних кількостей товарів - кожному товару у відповідність ставиться його кількість.

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

Постачальник - в даному випадку "продавець" товару.

Склад - склад, до якого фізично поставляється товар.

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

Дата (Date) - дата проведення документа.

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

Список відповідних кількостей товарів - кожному товару у відповідність ставиться його кількість.

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

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

Склад - склад, з якого фізично поставляється товар.

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

При обробці перерахованих сутностей отримуємо діаграму "сутність-зв'язок":

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

3.2.2 Фізичне проектування

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

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

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

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

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

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

"Витрата" - "Склад": дана зв'язок носить характер "один до багатьох", так як однієї видаткової накладної може відповідати тільки один склад, але одному складу можуть відповідати кілька видаткових накладних.

"Витрата" - "Магазин": дана зв'язок носить характер "один до багатьох", так як однієї видаткової накладної може відповідати тільки один магазин, але одному магазину можуть відповідати кілька видаткових накладних.

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

Таким чином, агрегируя всі результати аналізу діаграми сутність-зв'язок отримуємо наступну фізичну схему БД:

Глава 4: Розробка

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

На фазі "Розробка":

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

  • завершується виконання перших трьох етапів

  • починається тестування (зазвичай на цій фазі виконується приблизно 15% етапу "Тестування")

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

  • ведеться управління ризиками, виявленими на попередніх стадіях

    Фаза "Розробка" завершується етапом "Готовність до дослідної експлуатації".

    4.1 Borland Delphi 2005

    Delphi 2005, як і вся лінійка ALM інструментів є новітнім рішенням Borland у своєму сегменті.

    Серед головних нововведень цього продукту (раніше дана версія носила кодову назву Diamondback) потрібно зазначити два: у ньому вперше реалізована можливість використання двох мов - власне Delphi (діалект Pascal) і C #, а також можливість створення додатків для Win32 (на Delphi) і. NET (Delphi і C #).

    Поява Delphi 2005 здало важливим кроком в еволюційному процесі розвитку інструментальних засобів Borland для архітектури Win32 і. NET.

    Як відомо, корпорація Borland ще в 2001 році однією з перших серед незалежних постачальників підключалася до програми Visual Studio. NET Integration Partner і, більше того, першою отримала ліцензію на SDK. NET Framework, оголосивши про намір створення власних засобів розробки для нової на той час платформи Microsoft. NET.

    У 2003 р. Borland представила C # Builder і Delphi 8 - перші два інструменти для створення. NET-додатків, реалізовані на базі нового ядра IDE для Windows, що підтримує кілька різних систем розробки для Win32 і. NET (проект з кодовою назвою Gallileo). Тепер на зміну їм прийшов новий пакет Delphi 2005, що об'єднав обидва засоби (для. NET) з можливостями Delphi 7 (Win32).

    На думку представників Borland, нинішній варіант інструменту - це найбільш значне оновлення Delphi за останні роки, виконане в повній відповідності зі стратегією оптимізації процесу створення програмного забезпечення Software Delivery Optimization, розробленої корпорацією.

    Середовище Delphi 2005 не тільки підтримує декілька мов, SDK Win32 і. NET, але і володіє цілим рядом принципово нових удосконалень. До її складу входить велика кількість принципово нових функціональних можливостей IDE, покликаних спростити виконання розробниками своїх повсякденних завдань, підвищити продуктивність їх праці та оптимізувати роботу з вихідними текстами програм.

    У числі цих можливостей - прогресивні засоби рефакторінгу текстів програм, розвинена довідкова система, детальні повідомлення про помилки (Help Insights і Error Insights), SyncEdit, History Management і нові розширення мови Delphi.

    Особливо потрібно виділити нову платформу ECO II (Enterprise Core Objects), призначену для створення програмних засобів корпоративного класу для. NET з використанням архітектури Model Driven Architecture (MDA), що дозволяє прискорити розробку та підвищити якість складних додатків, а також поліпшити можливості їх супроводу.

    ECO II - це повнофункціональна система автоматичного створення діаграм і об'єктів, що володіє відмінно масштабованим кешем об'єктів. NET і розширеними можливостями об'єктів корпоративного класу, такими, як відкат / повернення, постійні властивості, контроль версій і проведення транзакцій.

    Крім того, Delphi 2005 допомагає групам розробників здійснювати супровід і доопрацювання вже випущених ними програм для Windows з використанням нових технологій і можливостей.

    Продукт дозволяє працювати з мовами програмування для Windows із застосуванням Win32 і. NET SDK, інтегрується з іншими рішеннями Borland, що забезпечують керування життєвим циклом додатків, в першу чергу StarTeam і Optimizeit.

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

    За оцінками експертів, Delphi 2005 в його нинішньому вигляді вже наздогнав за функціональним можливостям створення рішень корпоративного рівня Java-інструмент Borland - J B uilder.

    Існує три випуски Delphi 2005:

    • Architect для розробки додатків на основі моделей;

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

    • Professional для окремих програмістів, зайнятих побудовою додатків для Web і написанням програм з графічним інтерфейсом.

    Розробник Системи використав версію Delphi 2005 Professional. Її можливостей цілком вистачає для реалізації всіх поставлених завдань. Розробник Системи має досвід роботи в середовищі Delphi починаючи з версії 5. Перехід на 2005ую версію не викликав практично ніяких проблем. Більш того, порадувала інтеграція з StarTeam 2005. В іншому все залишилося колишнім: відмінний об'єктно-орієнтований підхід, найпотужніша підтримка бібліотек компонентів, прекрасна довідкова система.

    Слід окремо зазначити, яку неоціненну допомогу при створенні Системи надали літературні джерела 2, 3, 4, 6.

    4.2 Архітектура

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

    Переваги триланкової архітектури

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

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

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

    4.3 HTML прототипи

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

    Для даної Системи прототипи розроблялися в середовищі інтегрованої розробки Delphi 2006. Справа в тому, що до моменту реалізації Системи вийшла нова версія Delphi, трохи більш зручна попередньої щодо проектування ASP. NET сторінок.

    На даному малюнку представлений прототип вікна входу в систему (авторизації):

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

    Для кінцевого користувача прототипи компілювалися в HTML сторінки:

    4.4 Бізнес логіка

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

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

    Бізнес логіка реалізовувалася на мові Delphi в однойменній середовищі розробки. Для з'єднання з базою даних використовувалися компоненти SqlConnection, SqlDataAdapter, DataSet, SqlCommand:

    4.5 Розробка інтерфейсу користувача

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

    Глава 5: Економічний ефект

    5.1 План аналізу економічної ефективності

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

    1. Техніко-економічне обгрунтування розробки ПЗ;

    2. Розрахунок витрат на розробку ПЗ;

    3. Вартість впровадження ПЗ Замовником;

    4. Витрати замовника при експлуатації ПЗ;

    5. Ефективність впровадження для Замовника ПЗ;

    6. Правові аспекти.

    5.2 Техніко-економічне обгрунтування розробки ПЗ.

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

    Вибір припав саме на розробку, а не придбання відповідного ПЗ з ряду причин:

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

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

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

    5.3 Розрахунок витрат на розробку ПЗ

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

    Витрати на розробку

    Оскільки Система розроблялася повністю за методологією RUP, було вирішено відмовитися від традиційної системи оцінки витрат (ТЗ, ескізний проект, технічний проект, робочий проект, впровадження) на користь більш прийнятною методики. Фази і зміст робіт представлені в таблиці 6.1:

    Таблиця № 6.1

    Фаза RUP

    Зміст робіт

    Трудомісткість



    дні

    %

    1. Дослідження

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

    9

    10

    1. Опрацювання

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

    23

    25

    1. Створення

    низькорівнева розробка та кодування

    51

    55

    1. Перехідний період

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

    9

    10

    Разом


    92

    100

    На створення Системи було витрачено 92 робочих дні або 4 повних місяці.

    Оцінка витрат включає 3 основні пункти:

    • фонд оплати праці

    • придбання інструментарію

    • використання Інтернет

    Витрати на електроенергію, амортизацію комп'ютерної техніки та інші витрати настільки малі, що ними можна знехтувати.

    Фонд оплати праці

    У проекті був задіяний 2 розробника. Місячна зарплата встановлена ​​в розмірі 10 тисяч рублів. До їхніх обов'язків входили всі фази розробки: від дослідження до документації. Витрати на оплату праці склали:

    2 * 4мес. * 10000руб. = 80000руб.

    Придбання інструментарію

    Згідно з методологією Borland ALM використовувався програмний пакет, що складається з наступних програм, представлених у таблиці 6.2:

    Таблиця 6.2

    Продукт

    Вартість (у.о.)

    Вартість (грн.)

    Borland CaliberRM 2005

    800 (*)

    22400

    Borland Estimate 2005

    500 (*)

    14000

    Borland Together Solo 2005

    900 (*)

    25200

    Borland Delphi 2005

    1090

    30520

    Borland StarTeam 2005

    1000 (*)

    28000

    Разом

    4290

    120120

    (*) Приблизна ціна, т.к.офіціально продукт ще не продається

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

    Використання Інтернет

    Місячна абонентська плата за використання Інтернет склала (таблиця 6.3):

    Таблиця № 6.3

    Місяць

    Комп'ютер 1 (руб.)

    Комп'ютер 2 (грн.)

    Перша

    724

    920

    Другий

    481

    512

    Третя

    598

    610

    Четверта

    146

    205

    Разом

    1949

    2247

    Сумарні витрати обох розробників на Інтернет - 4196 рублів.

    Агрегація

    Тепер об'єднаємо одноразові витрати на розробку (таблиця 6.4):

    Таблиця № 6.4

    Вид витрат

    Витрати (крб.)

    Фонд оплати праці

    80000

    Придбання інструментарію

    120120

    Використання Інтернет

    4196

    Разом

    204316

    Таким чином, у випадку комерційного використання Системи сукупні витрати на розробку складуть 204316 Рубель.

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

    5.4 Вартість впровадження ПЗ Замовником

    Статті витрат організації при впровадженні Системи складаються з таких основних складових:

    1. Вартість програмного забезпечення спеціально розробленого для замовника. У цьому випадку вартість дорівнює собівартості плюс прибуток розробника (на практиці зазвичай становить 20-30% від собівартості), а також податок на додану вартість 20%. Для розрахунку можна використовувати наступну формулу , Де - Собівартість ПЗ, - Прибуток розробника, - Податок на додану вартість. Вартість, розрахована за такою формулою ставати занадто висока, тому було прийнято рішення поширювати створену систем як тиражується ПЗ. Після розрахунків, зроблених іншим розробником було визначено, що вартість ліцензії на один комп'ютер буде складати 2000 рублів. Разом за 18 комп'ютерів вартість купівлі програмного забезпечення становитиме 36000.

    2. Вартість інструментальних засобів, необхідних для функціонування системи. У їх склад зазвичай входять операційні системи, а також прикладне програмне забезпечення. Розроблена нами система працює на операційних системах сімейства Windows (починаючи з Windows 2000). На підприємства замовника вже встановлені і використовуються ці операційні системи. Також система не пред'являє вимог до додаткового платного прикладного програмного забезпечення. Тому при впровадженні не передбачається витрат за цими статтями.

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

    4. Вартість навчання персоналу організації на освоєння ПЗ та навчання персоналу роботі з програмою. Розрахунок проводитися за такою формулою: , Де - Чисельність персоналу на навчання, - Вартість навчання однієї особи в день, - Час навчання. Передбачається, що в організації замовника системою будуть користуватися 4 людини: 3 менеджера і 1 адміністратор. Час необхідний для навчання імовірно оцінюється в два робочих дні. Вартість навчання однієї особи в день 500 рублів. Разом виходить витрати на навчання персоналу 4000 рублів.

    5. Вартість початкового налаштування Системи. Для цього потрібен один робочий день адміністратора. Виходячи з його одноденного заробітку витрати будуть оцінюватися в 320 рублів.

    5.5 Витрати замовника при експлуатації ПЗ

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

    1. Витрати, пов'язані з заробітною платою менеджерам і адміністраторам за додаткове навантаження, пов'язану з експлуатацією Системи. Будемо вважати, що менеджер буде витрачати на роботу 1 годину в тиждень, адміністратор - 3 години на тиждень. Заробітна плата менеджера на годину оцінюється 80 рублів, адміністратора - 45 рублів. Після розрахунків експлуатація Системи в рік буде обходитися в 13680 рублів.

    2. Витрати, пов'язані з супроводом системи. Вартість супроводу оцінюється в 5000 рублів на рік.

    Дані по витратах експлуатації ПЗ представлені в таблиці 6.5:

    Таблиця № 6.5

    Вид витрат

    Кол. людина

    Вартість

    Всього на рік

    Додаткове навантаження на персонал:




    - Менеджер

    3

    80 р / год

    11520

    - Адміністратор

    1

    45 р / год

    2160

    Супровід




    - Працівник групи супроводу

    1

    5000 р / р

    5000

    Разом



    18680

    5.6 Ефективність впровадження для Замовника ПЗ

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

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

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

    3. Підвищення якості обслуговування клієнтів за рахунок збільшення швидкості роботи.

    4. Підвищення рівня маркетингових заходів

    5. Загальне підвищення організації праці в колективі.

    Сумарні витрати для замовника представлені в таблиці 6.6

    Таблиця 6.6

    Витрати

    Вартість

    Вартість ПЗ (разова)

    36000

    Вартість впровадження (разова):


    навчання персоналу

    4000

    первісне настроювання

    320

    Вартість експлуатації (на рік)


    зарплата персоналу

    13680

    супровід

    5000

    Разом

    59000

    Будемо умовно вважати, що за рахунок досягнення результатів по всім вищевказаним напрямкам приріст прибутку підприємства оцінюється на рівні 5-10 відсотків. Їли брати в розрахунок середній прибуток підприємства в 277000 рублів на місяць приріст дасть додатково 27700 рублів на місяць, а значить близько 332 400 000 на рік. Додатковий прибуток підприємства за рахунок впровадження системи становитиме 273400 рублів. Запроваджена система вже в перший рік експлуатації окупить себе.

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

    Таблиця № 6.7

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

    59000

    Прибуток підприємства

    3324000

    Приріст прибутку

    0,0177497

    Звідси видно, що приріст прибутку повинен бути на рівні 1.7 відсотка, щоб впровадження було беззбитковим:

    5.7 Правові аспекти

    Легальність інструментарію

    При розробці Системи суворо дотримувалися всі умови ліцензійних угод продуктів ALM і супутніх компонентів. Більшість з них дозволяють безкоштовно розробляти некомерційні програми. Витрати на комерційне використання інструментів розробника були пораховані вище.

    Ліцензійна угода

    Поняття ліцензійної угоди прийшло з Заходу. End user license agreement (EULA) - документ як правило існує в електронній формі, підписання якого є необхідною умовою використання програми на ЕОМ. EULA розробленої системи містить наступні пункти:

    • загальні положення

    • авторські права на програму

    • права на розповсюдження програми

    • захист відповідальності розробника (принцип "як є")

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

    Захист авторських прав

    При створенні Системи розробники керувалися Федеральним Законом РФ від 23 вересня 1992 р. N 3523-I (в ред. Федерального закону від 24.12.2002 N 177-ФЗ) "Про правову охорону програм для електронних обчислювальних машин і баз даних". Стаття 4 Закону містить опис умов визнання авторського права. Згідно статті, "для визнання і здійснення авторського права на програму для ЕОМ чи базу даних не потрібно депонування, реєстрації чи дотримання інших формальностей. Правовласник для сповіщення про свої права може, починаючи з першого випуску в світ програми для ЕОМ чи бази даних, використовувати знак охорони авторського права, що складається з трьох елементів:

    - Букви С в колі або в круглих дужках;

    - Найменування (імені) правоволодільця;

    - Року першого випуску програми для ЕОМ чи бази даних у світ.

    Висновок

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

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

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

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

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

    1. Федеральний Закон РФ від 23.09.1992 р. № 3523-I (в редакції від 24.12.2002 № 177-ФЗ) Про правову охорону програм для електронних обчислювальних машин і баз даних.

    2. Delphi 7 у оригіналі. А. Хомоненко. СПб: BHV, 2003 - 1216 стор

    3. Delphi. Поради програмістів (2-е видання): В. Озеров. - СПб: Символ-Плюс, 2002. - 976 стор

    4. Borland Delphi 6. Керівництво розробника: С. Тейксейра, К. Пачеко. - М: Вільямс, 2002. - 1120 стор

    5. Принципи проектування та розробки програмного забезпечення. Навчальний курс MCSD: Скотт Ф. Уілсон, Брюс Мейплс, Тім Лендгрейв. - М: Російська редакція, 2002. - 736стр.

    6. Проектування економічних інформаційних систем: Підручник / Г.Н.Смірнова, А. А. Сорокін, Ю. Ф. Тельнов. - М: Фінанси і статистика, 2003. - 512стр.

    7. Теорія і практика побудови баз даних: Д. Кренке. - Пітер, 2003. - 800стр.

    8. Самовчитель UML. Ефективний інструмент моделювання інформаційних систем: А. Леоненков. - СПб: BHV, 2001. - 304стр.

    9. Уніфікований процес розробки програмного забезпечення: А. Якобсон, Г. Буч, Дж. Рембо. - СПб.: Пітер, 2002. - 496стр.

    10. Відкриті системи (№ 10). Як домогтися успіху в безнадійних проектах.: К. Берлінський. - М:, 2002.

    11. Каліфорнійський Університет (University of California, Los Angeles, UCLA). WWW: http://www.ucla.edu

    12. Borland AML Portal. WWW: http://www.almportal.ru

    13. Компанія Borland. WWW: http://www.borland.com

    14. Компанія Harris Interactive. WWW: http://www.harrisinteractive. Com

    15. Компанія IDC. WWW: http://www.idc.com

    16. Міжнародна організація по стандартизації об'єктних технологій OMG. WWW: http://www.omg.com

    17. Онлайн газета PC Week. WWW: http: / / www. Pcweek. Ru

    18. Російськомовний сайт компанії Borland. WWW: http://www.borland.ru

    Додати в блог або на сайт

    Цей текст може містити помилки.

    Програмування, комп'ютери, інформатика і кібернетика | Диплом
    252.8кб. | скачати


    Схожі роботи:
    Автоматизована система обліку виробничого процесу металоцентру на прикладі ЗАТ Сибірський
    Автоматизована система комерційного обліку електроенергії
    Автоматизована система обліку кадрів на підприємстві 2
    Автоматизована система обліку кадрів на підприємстві
    Автоматизована система обліку праці та зарплати
    Автоматизована система обліку договорів страхування підприємницьких ризиків
    Автоматизована система обліку обороту товарів в телекомунікаційній фірмі
    Автоматизована система обліку конкурентоспроможності регіону на основі діяльності підприємств
    Автоматизована система обліку з підключення Інтернет-мережі в РУП Белтелеком
    © Усі права захищені
    написати до нас