Оглавление
Введение
Глава 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 LifecycleManagement, ALM) рассматривает процесс выпуска программных средств какпостоянно повторяющийся цикл взаимосвязанных этапов:
· определениетребований (Requirements);
· проектирование ианализ (Design & Analysis);
· разработка(Development);
· тестирование(Testing);
· развертывание исопровождение (Deployment & Operations).
Каждый изэтих этапов должен тщательно отслеживаться и контролироваться. Правильноорганизованная ALM-система позволяет:
· сократить срокивывода продуктов на рынок (разработчикам приходится заботиться лишь осоответствии их программ сформулированным требованиям);
· повыситькачество, гарантируя при этом, что приложение будет соответствоватьпотребностям и ожиданиям пользователей;
· повыситьпроизводительность труда (разработчики получают возможность делиться передовымопытом разработки и внедрения);
· ускоритьразработку благодаря интеграции инструментов;
· уменьшить затратына сопровождение, постоянно поддерживая соответствие между приложением и егопроектной документацией;
· получитьмаксимальную отдачу от инвестиций в навыки, процессы и технологии.
Разработкапрограмм имеет ту особенность, что, с одной стороны, это процесс итерационный,а с другой — он не всегда последовательно переходит от одного этапа к другому.Зачастую от тестирования разработчики переходят назад к проектированию, затем — к развертыванию, а потом, возможно, вновь возвращаются на этап определениятребований по мере изменения производственных потребностей. Кроме того, нужноотметить, что внутренняя организация процесса, в частности, распределениефункций и ролей его участников, может сильно варьироваться в зависимости откорпоративных регламентов и специфики конкретных проектов.
/>
Рис. 1.1Этапы жизненного цикла ALM Borland
РеализацияALM-стратегии в исполнении Borland заключается в предоставлении комплексавзаимосвязанных инструментов для всех этапов жизненного цикла приложений,таких, как определение требований, анализ и проектирование, разработка,тестирование, развертывание и управление [13]. Этапы жизненного циклаизображены на рисунке 1.1. Данная стратегия компании Borland достаточно гибкая и адаптируются под любуюметодологию, в том числе и выбранную нами RUP. В рамках данной стратегии компания выпустила рядпродуктов, которые мы собираемся использовать в своей работе, главнымпреимуществом которых является тесная интеграция друг с другом:
· BorlandCaliberRM 2005;
· BorlandTogether Designer 2005;
· BorlandStartTeam 2005;
· BorlandDelphi 2005.
RationalUnified 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.
.NETFramework состоит из двух главных компонентов: библиотеки базовых классов и 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 изначально), но самое важное заключаетсясовсем в другом: все независимые инструменты будут только в среде .NETFramework.
Библиотекабазовых классов
.NETFramework 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 ClassClass0 ‘объект нулевого уровня
‘код класса
EndClass
NamespaceName1 ‘объекты первогоуровня
PublicClass Class1
EndClass
PublicClass Class2
EndClass
NamespaceName2 ‘объекты второгоуровня
PublicClass Class2
EndClass
EndNamespace
End Namespace
Соответственнополные имена объектов для этого модуля, включенного в MyClass.dll, будутвыглядеть следующим образом:
MyClass.Class0
MyClass.Name1.Class1
MyClass.Name1.Class2
MyClass.Name1.Name2.Class2
Дляиспользования сокращенных имен объектов допускается импорт пространств имен:
Imports MyClass
Imports MyClass.Name1
Тогда впрограмме к объектам можно обращаться с такими именами: Class0, Class1, Class2,Name2.Class2. Понятно, что использовать импорт пространств имен нужно оченьаккуратно, чтобы не возникло противоречий идентификаторов классов.
В приведенномвыше примере мы не можем импортировать MyClass.Name1.Name2, так как возникнетнеопределенность для имени Class2 (оно встречается дважды в разныхпространствах имен).
Объединениеотдельных .NET-компонентов в одно приложение непосредственно связано с новымпонятием «сборка» (Assembly). Как известно, с контролем версий в COMдело обстояло, мягко говоря, не самым лучшим образом. Фактически поддержкасовместимости версий была полностью возложена на разработчика COM-объектов.
Технология.NET Assembly призвана решить все эти проблемы, известные под названием DLLHell (ад DLL). В упрощенном виде идея заключается в переносе процедуррегистрации объектов из системного Реестра на уровень отдельных приложений.
В сущности,сборка — это и есть .NET-приложение, она реализуется в виде расширенного вариантатрадиционного исполняемого модуля. Сборка может состоять из одного илинескольких файлов, причем они могут содержать не только исполняемый код, нотакже и графические изображения, исходные данные и прочие ресурсы.
/>
В архитектуре.NET сборки являются минимальным блоком, на уровне которого решаются вопросывнедрения, контроля версий, повторного использования и безопасности. Описаниесборки содержится в секции метаданных (она называется манифестом) исполняемогомодуля приложения.
Что касаетсярешения проблем DLL Hell, то, помимо жесткого контроля за используемымиверсиями, оно включает также простое создание локальных копий внешнихкомпонентов внутри каталога с данным приложением (т. е. сборка будет включатьне ссылку на компонент, а сам компонент).
CommonLanguage Runtime
Средаисполнения .NET-программ CLR — это краеугольный камень в фундаменте организациивычислительных процессов всей концепции .NET. Именно здесь решаются основныезадачи повышения надежности и безопасности программ, а также платформнойнезависимости.
ФактическиCLR исполняет программы, написанные только на одном стандартном языке MicrosoftIntermediate 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!
Что впереди
Сегодня .NETFramework — это некая дополнительная операционная среда, устанавливаемая вWindows в качестве автономного программного компонента. Нет сомнений, что онастанет неотъемлемой частью будущей версии Windows. Тем не менее еще нескольколет пользователи Windows будут иметь возможность работать как в режиме «WinAPI + COM», так и .NET. Но потом им придется забыть о «старом, добромWindows» и работать исключительно в режиме «управляемого кода» всреде CLR. Это произойдет гораздо быстрее, чем в период «от DOS к Windows».3.2. Обзор ASP.NET
Летом 2001го годаMicrosoft представила новую прогрессивную платформу .NET, а с ней несколькоочень привлекательных технологий, в том числе ASP.NET, также называемую ASP+.Данная статья посвящена обзору этой серверной технологии Microsoft. ВозможностиASP.NET настолько впечатляют, что ее сложно назвать следующей версией ASP. ASP3.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 позволяет стандартизировать обращение к системным вызовам ипредоставляет среду для более быстрой и удобной разработки.
В новую платформувстроены такие необходимые возможности, как контроль версий и важная длясетевых решений повышенная безопасность. Среда выполнения кода включает в себясборщик мусора и набор библиотек, готовых к использованию.Код для .NETFramework компилируется в общий промежуточный язык (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). Теперь на смену им пришел новый пакет Delphi2005, объединивший оба средства (для .NET) с возможностями Delphi 7 (Win32).
По мнению представителейBorland, нынешний вариант инструмента — это самое значительное обновлениеDelphi за последние годы, выполненное в полном соответствии со стратегиейоптимизации процесса создания программного обеспечения Software DeliveryOptimization, разработанной корпорацией.
Среда 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 — JBuilder.
Существует три выпуска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 2. Проработка анализ требований и проектирование системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна; 23 25 3. Создание низкоуровневая разработка и кодирование 51 55 4. Переходный период создание бета-версии продукта, поставка продукта конкретному пользователю, создание документации 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 (руб.)
1ый 724 920 2ой 481 512 3ий 598 610 4ый 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 рублей в месяц, а значит около 332400 тысяч в год. Дополнительная прибыльпредприятия за счет внедрения системы составит 273400 рублей. Внедреннаясистема уже в первый год эксплуатации окупит себя.
Как было сказано, многоезависит от политики руководства при внедрении данной Системы. Можно рассчитатьеще один показатель, который будет точкой безубыточности проекта. Стоимостьвнедрения составляет 59000 рублей, прибыль предприятия в год составляет 3324000рублей. Рассчитаем необходимый прирост прибыли для самоокупаемости (таблица6.7).
Таблица № 6.7Затраты на внедрение 59000 Прибыль предприятия 3324000 Прирост прибыли 0,0177497
Отсюда видно, что приростприбыли должен быть на уровне 1.7 процента, чтобы внедрение было безубыточным:
/>5.7 Правовые аспекты
Легальностьинструментария
При разработке Системыстрого соблюдались все условия лицензионных соглашений продуктов ALM и сопутствующих компонентов.Большинство из них позволяют бесплатно разрабатывать некоммерческие приложения.Затраты на коммерческое использование инструментов разработчика были посчитанывыше.
Лицензионное соглашение
Понятие лицензионногосоглашения пришло с Запада. End user license agreement (EULA) – документ как правило существующий в электроннойформе, подписание которого является необходимым условием использованияпрограммы на ЭВМ. EULA разработаннойсистемы содержит следующие пункты:
· общие положения
· авторские правана программу
· права нараспространение программы
· защитаответственности разработчика (принцип «как есть»)
· защитацелостности и тиражирования (копирование, дизассемблирование, декомпилированиеи т.п.)
Защита авторских прав
При создании Системыразработчики руководствовались Федеральным Законом РФ от 23 сентября 1992 г. N3523-I (в ред. Федерального закона от 24.12.2002 N 177-ФЗ) «О правовойохране программ для электронных вычислительных машин и баз данных». Статья4 Закона содержит описание условий признания авторского права. Согласно статье,«для признания и осуществления авторского права на программу для ЭВМ илибазу данных не требуется депонирования, регистрации или соблюдения иныхформальностей. Правообладатель для оповещения о своих правах может, начиная спервого выпуска в свет программы для ЭВМ или базы данных, использовать знакохраны авторского права, состоящий из трех элементов:
— буквы С в окружностиили в круглых скобках;
— наименования (имени)правообладателя;
— года первого выпускапрограммы для ЭВМ или базы данных в свет.
Заключение
В результате всей проделанной работы был получен готовый к работепрограммный комплекс торгово-складской автоматизации, предназначенный длярозничных предприятий заказчика – ЗАО „Белгородский бройлер“. Впроцессе разработки и поиска технологий удалось сохранить главную отличительнуюособенность программы — её простоту для конечного пользователя. Понятный истильный интерфейс создает приятную и удобную атмосферу работы с программой.
Функции сетевой работы построены с учетом минимизации затрат натрафик, нестабильности и невысокой скорости каналов. Выходные документыстандартизированы, но поддаются гибкому изменению пользователем. Быстродействиемеханизмов работы с данными находится на должном уровне. В экономической частирассчитан рост эффективности работы предприятия и период окупаемости затрат навнедрение Системы, равный одному году.
Значительная экономия на обучении пользователей и экономиярабочего времени делает использование программы не только экономическиобоснованным, но крайне желательным и благотворно влияющим на общий ход бизнесазаказчика.
Система отвечает всем поставленным перед ней задачам, такимобразом, попытка создать простой продукт, удовлетворяющий требованиям заказчика,удалась.
Список использованной литературы
1. Федеральный ЗаконРФ от 23.09.1992 г. № 3523-I (в редакции от 24.12.2002 № 177-ФЗ) О правовойохране программ для электронных вычислительных машин и баз данных.
2. Delphi7 в подлиннике. А. Хомоненко. СПб: BHV, 2003– 1216 стр.
3. Delphi.Советы программистов (2-е издание): В.Озеров. – СПб: Символ-Плюс, 2002. – 976стр.
4. BorlandDelphi 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. Калифорнийский Университет (Universityof California, Los Angeles, UCLA). WWW: www.ucla.edu
12. BorlandAML Portal. WWW: www.almportal.ru
13. Компания Borland.WWW: www.borland.com
14. Компания Harris Interactive. WWW:www.harrisinteractive.com
15. Компания IDC. WWW: www.idc.com
16. Международнаяорганизация по стандартизации объектных технологий OMG. WWW: www.omg.com
17. Онлайн газета PC Week. WWW: www.pcweek.ru
18. Русскоязычныйсайт компании Borland. WWW: www.borland.ru