Реферат

“КОМПАНИЯ-РАЗРАБОТЧИК
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Разработка и внедрение собственного
программного продукта

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

В данной работе будут показаны преимущества

разработки и внедрения собственного программного
продукта в дополнение к имеющемуся типовому
решению "1С Предприятие: Торговля и склад".

ЗАО "Белгородский бройлер" было основано в 2000

году. Цель деятельности компании – производство и
реализация мяса птицы и сопутствующих товаров. В
процессе своего роста, компания стала больше
внимания уделять сбыту продукции конечному
потребителю. Для этого за несколько лет была
создана розничная сеть магазинов,
специализирующихся на продаже продукции ЗАО
"Белгородский бройлер" и сторонних компаний.
Ассортимент продукции компании постоянно
расширялся, поэтому и управлять товарно-
материальными потоками становилось все сложнее и
сложнее. Среди прочих проблем все острее вставал
вопрос складского учёта – от производства продукции
до ее реализации конечному потребителю.

В отделе сбыта и розничных продаж ЗАО

"Белгородский бройлер" используется пакет
программ "1С Предприятие". Пока количество
филиалов (розничных магазинов) ограничивалось
двумя и ассортимент продукции состоял из
нескольких наименований особых проблем не было.
Но с развитием филиальной сети магазинов (сейчас
их семь) появились новые требования к ПО
складского учета.
Рисунок 1

На рисунке 1 изображена существующая модель

ведения складского учета компании. Её суть
заключается в том, что учет ведется в головном офисе
и каждый магазин лишь регулярно предоставляет
соответствующие данные о продажах. Она обладает
рядом недостатков:

высокий человеческий фактор – так как передача

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

низкая актуальность данных – обновление данных

происходит не чаще 1 раза в день;
двойной ввод данных – первый раз – при
продаже\поступлении товара, второй раз – при учете
этой же операции в системе "1С: Предприятие";

низкая доступность отчетной информации для

пользователей – руководство компании настаивает на
создании такой системы, которая бы позволила
пользователю получать различную отчетную
информацию в любой момент времени при наличии
подключения к Интернет.

Новая модель позволит достигнуть основной бизнес

цели, сформулированной менеджментом компании:

Снижение затрат на сбор данных о движении товаров

в розничных магазинах компании.

Для достижения этой цели необходимо:

Минимизировать человеческий фактор при сборе
данных о товарообороте;

Увеличить скорость сбора данных о товарообороте;

Создать единую картину товарооборота всех

филиалов.

Также для компании немаловажным будет являться

побочный эффект от проекта:

Повышение имиджа компании как 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-система позволяет:
сократить сроки вывода продуктов на рынок
(разработчикам приходится заботиться лишь о
соответствии их программ сформулированным
требованиям);

повысить качество, гарантируя при этом, что

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

повысить производительность труда (разработчики

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

ускорить разработку благодаря интеграции

инструментов;

уменьшить затраты на сопровождение, постоянно

поддерживая соответствие между приложением и его
проектной документацией;
получить максимальную отдачу от инвестиций в
навыки, процессы и технологии.

Разработка программ имеет ту особенность, что, с

одной стороны, это процесс итерационный, а с другой
- он не всегда последовательно переходит от одного
этапа к другому. Зачастую от тестирования
разработчики переходят назад к проектированию,
затем - к развертыванию, а потом, возможно, вновь
возвращаются на этап определения требований по
мере изменения производственных потребностей.
Кроме того, нужно отметить, что внутренняя
организация процесса, в частности, распределение
функций и ролей его участников, может сильно
варьироваться в зависимости от корпоративных
регламентов и специфики конкретных проектов.
Платформа .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 с двумя видимыми
отличиями: в них используются иерархическая
система имен объектов и иной порядок объединения
программных компонентов в приложении.

Проектирование базы данных

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.

Итак, нормализуем отношения логической модели

данных, установив характер связей в
разрабатываемой схеме базе данных:

"Приход" – "Товар": данная связь носит характер

"многие ко многим", так как одной приходной
накладной могут соответствовать несколько товаров
и, в то же время, одному товару могут соответствовать
несколько приходных накладных. Связь "многие ко
многим" предполагает физическую реализацию в
виде двух связей "один ко многим" (таблица
"Приход_ Товар").

"Приход" – "Поставщик": данная связь носит характер

"один ко многим", так как одной приходной
накладной может соответствовать только один
поставщик, но одному поставщику могут
соответствовать несколько приходных накладных.

"Приход" – "Склад": данная связь носит характер

"один ко многим", так как одной приходной
накладной может соответствовать только один склад,
но одному складу могут соответствовать несколько
приходных накладных.

"Расход" – "Склад": данная связь носит характер

"один ко многим", так как одной расходной
накладной может соответствовать только один склад,
но одному складу могут соответствовать несколько
расходных накладных.

В результате более детальной проработки диаграммы

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

Таким образом, агрегируя все результаты анализа

диаграммы сущность-связь получаем следующую
физическую схему БД:
HTML прототипы
HTML прототипы – один из методов демонстрации
возможностей будущей системы. Этот способ
позволяет детально согласовать параметры Системы с
заказчиком, избежав тех ошибок, окторые бы
возникли, будь Система разработана полностью.

Для данной Системы прототипы разрабатывались в

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

На данном рисунке представлен прототип окна входа

в систему (авторизации):

На данном рисунке представлен прототип окна

просмотра Приходных накладных:

Для конечного пользователя прототипы

компилировались в HTML страницы:

Разработка интерфейса пользователя

При проектировании экранных форм необходимо
реализовать доступность и простоту общения
пользователя с информационной системой, нельзя
забывать, что система проектируется с целью помочь
уменьшить нагрузку на сотрудников компании.
Поэтому экранные формы должны отвечать
требованиям простоты и доступности:
Заключение
В результате всей проделанной работы был получен
готовый к работе программный комплекс торгово-
складской автоматизации, предназначенный для
розничных предприятий заказчика – ЗАО
"Белгородский бройлер". В процессе разработки и
поиска технологий удалось сохранить главную
отличительную особенность программы - её простоту
для конечного пользователя. Понятный и стильный
интерфейс создает приятную и удобную атмосферу
работы с программой.

Функции сетевой работы построены с учетом

минимизации затрат на трафик, нестабильности и
невысокой скорости каналов. Выходные документы
стандартизированы, но поддаются гибкому
изменению пользователем. Быстродействие
механизмов работы с данными находится на
должном уровне. В экономической части рассчитан
рост эффективности работы предприятия и период
окупаемости затрат на внедрение Системы, равный
одному году.

Значительная экономия на обучении пользователей и

экономия рабочего времени делает использование
программы не только экономически обоснованным,
но крайне желательным и благотворно влияющим на
общий ход бизнеса заказчика.

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

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