Оглавление

Введение

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

Глава 2: Исследование

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

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

3.2. Обзор ASP.NET

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

3.2.1 Логическое проектирование

3.2.2 Физическое проектирование

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

4.1 Borland Delphi 2005

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

4.3 HTML прототипы

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

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

Глава 5: Экономический эффект

5.1 План анализа экономической эффективности

5.2 Технико-экономическое обоснование разработки ПО

5.3 Расчет затрат на разработку ПО

5.4 Стоимость внедрения ПО Заказчиком

5.5 Расходы заказчика при эксплуатации ПО

5.6 Эффективность внедрения для Заказчика ПО

5.7 Правовые аспекты

Заключение

Список использованной литературы

 

Введение

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

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

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

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

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

Рисунок 1

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

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

·                    низкая актуальность данных – обновление данных происходит не чаще 1 раза в день;

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

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

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

Рисунок 2

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

Снижение затрат на сбор данных о движении товаров в розничных магазинах компании.

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

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

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

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

Также для компании немаловажным будет являться побочный эффект от проекта:

·                    Повышение имиджа компании как IT ориентированной.

В описанной модели под "АС Складского учета" понимается некая автоматизированная система, в которую заносятся данные о движении товара и из которой эти данные попадают в "1С: Предприятие" бухгалтерии головного офиса компании.

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

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

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

·                    высокие требования к каналам передачи данных;

·                    излишний функционал, приводящий к сложностям в восприятии системы рядовыми пользователями;

·                    отсутствие web-интерфейса.

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

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

Любой проект разработки программного обеспечения в своем развитии проходит определенный жизненный цикл – последовательность этапов и совокупность действий, в результате которых создается первая версия продукта. Реалистичная модель жизненного цикла упрощает выполнение проекта и гарантирует, что в проекте с каждым следующим этапом реализуется все больше запланированных задач. Прежде чем приступить к разработке системы необходимо иметь четкое описание методологии разработки, адаптированной к конкретному проекту. На основе выбранной методологии производится выбор конкретных проектных инструментов и программных средств.

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

RUP и XP исходят из различных философских основ. RUP - это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. RUP – это итеративная методология, основанная на шести признанных в отрасли лучших технологиях. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.

У RUP и XP множество различий, но решающим фактором при выборе методологии стал подход к архитектуре проектируемых систем. RUP советует уделять внимание архитектуре во избежание рисков, связанных с превышением времени на разработку, излишним объемом проекта и введением новых технологий. В XP предполагается либо наличие архитектуры, либо архитектура настолько проста и понятна, что может быть выведена непосредственно из кода. XP советует не проектировать на будущее, а реализовывать то, что нужно сегодня. Предполагается, что будущее сможет позаботиться о себе само, если вы будете сохранять проект настолько простым, насколько это возможно. Если даже система или ее часть будут переписываться в будущем, XP отмечает, что это все равно лучше, и зачастую дешевле, чем планировать такую возможность изначально. Для некоторых систем это действительно так, и при использовании RUP рассмотрение риска во время проработки проекта может привести вас к такому выводу. RUP не считает это истинным для всех систем и, как показывает опыт больших, более сложных систем, этот фактор может оказаться катастрофическим.

Учитывая сложность разрабатываемой системы, а также требования к адаптивности, мы выбрали в качестве методологии разработки RUP. Создатели RUP определяют его как итеративный, архитектурно-ориентированный и управляемый прецедентами использования процесс разработки программного обеспечения [9]. Основа RUP: разработка концепции; управление по плану; снижение рисков и отслеживание их последствий; тщательная проверка экономического обоснования; использование компонентной архитектуры; прототипирование, инкрементное создание и тестирование продукта; регулярные оценки результатов; управление изменениями; создание продукта, пригодного к употреблению; адаптация RUP под нужды своего проекта.

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

·                     определение требований (Requirements);

·                     проектирование и анализ (Design & Analysis);

·                     разработка (Development);

·                     тестирование (Testing);

·                     развертывание и сопровождение (Deployment & Operations).

Каждый из этих этапов должен тщательно отслеживаться и контролироваться. Правильно организованная ALM-система позволяет:

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

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

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

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

·                     уменьшить затраты на сопровождение, постоянно поддерживая соответствие между приложением и его проектной документацией;

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

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

Рис. 1.1 Этапы жизненного цикла ALM Borland

Реализация ALM-стратегии в исполнении Borland заключается в предоставлении комплекса взаимосвязанных инструментов для всех этапов жизненного цикла приложений, таких, как определение требований, анализ и проектирование, разработка, тестирование, развертывание и управление [13]. Этапы жизненного цикла изображены на рисунке 1.1. Данная стратегия компании Borland достаточно гибкая и адаптируются под любую методологию, в том числе и выбранную нами RUP. В рамках данной стратегии компания выпустила ряд продуктов, которые мы собираемся использовать в своей работе, главным преимуществом которых является тесная интеграция друг с другом:

·                   Borland CaliberRM 2005;

·                   Borland Together Designer 2005;

·                   Borland StartTeam 2005;

·                   Borland Delphi 2005.

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

1.                 Итерационный и инкрементный (наращиваемый) подход к созданию ПО.

2.                 Планирование и управление проектом на основе функциональных требований к системе - вариантов использования.

3.                 Построение системы на базе архитектуры ПО.

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

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

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

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

·                   Фаза Исследование (inception), предназначена для создания модели предметной области;

·                   Фаза Проработка (elaboration), предназначена для создания базовой архитектуры;

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

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

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

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

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

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

·                   роли;

·                   виды деятельности;

·                   рабочие продукты;

·                   дисциплины.

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

Под видом деятельности конкретного исполнителя понимается единица выполняемой им работы. Вид деятельности (activity) соответствует понятию технологической операции. Он имеет четко определенную цель, обычно выражаемую в терминах получения или модификации некоторых рабочих продуктов (artifacts), таких, как модель, элемент модели, документ, исходный код или план. Каждый вид деятельности связан с конкретной ролью. Продолжительность вида деятельности составляет от нескольких часов до нескольких дней, он обычно выполняется одним исполнителем и порождает только один или весьма небольшое количество рабочих продуктов. Любой вид деятельности должен являться элементом процесса планирования. Примерами видов деятельности могут быть планирование итерации, определение вариантов использования и действующих лиц, выполнение теста на производительность. Каждый вид деятельности сопровождается набором руководств (guidelines), представляющих собой методики выполнения технологических операций.

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

В рамках RUP определены шесть основных дисциплин:

·                   построение бизнес-моделей;

·                   определение требований;

·                   анализ и проектирование;

·                   реализация;

·                   тестирование;

·                   развертывание.

и три вспомогательных:

·                   управление конфигурацией и изменениями;

·                   управление проектом;

·                   создание инфраструктуры.

RUP основывается на шести лучших практиках (best practices):

·                     Итеративная разработка;

·                     Управление требованиями;

·                     Использование модульных архитектур;

·                     Визуальное моделирование;

·                     Проверка качества;

·                     Отслеживание изменений.

Они не являются непосредственной частью RUP, но их рекомендуется соблюдать при настройке процесса.

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

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

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

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

Качество продукта - одна из важнейших его характеристик. Заявляется, что RUP ориентирован на достижение приемлемого уровня качества, однако в процессе адаптации этой методологии с качеством могут возникать проблемы, если адаптация будет не совсем удачной.

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

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

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

В рамках применения объектно-ориентированного подхода мы собираемся использовать UML. UML представляет собой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Этот язык вобрал в себя наилучшие качества методов программной инженерии, которые с успехом использовались на протяжении последних лет при моделировании больших и сложных систем. Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования в частности. Выбор средств для построения моделей сложных систем предопределяет те задачи, которые могут быть решены с использованием данных моделей. При этом одним из основных принципов построения моделей сложных систем является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели [19].

Другим принципом построения моделей сложных систем является принцип многомодельности. Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к объектно-ориентированному подходу это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений, каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления. Феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех особенностей моделируемой системы.

 

Глава 2: Исследование

Число итераций этой фазы трудно предсказать заранее, однако обычно оно не превосходит двух, а основное внимание уделяется этапу сбор требований. Задачи фазы "Исследование" четко определены ее целями: описание основных характеристик Системы, снижение вероятности реализации основных рисков и подготовка обоснования проекта с точки зрения его связи с основными задачами бизнеса. На этой стадии:

·                    выделяется предметная область действия системы, то есть определяются границы применения приложения и его взаимоотношение с другими системами;

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

·                    выявляются основные риски;

Фаза завершается формулировкой целей проекта.

Подробный анализ требований заказчика позволил создать единую картину функциональности будущей системы. Прежде всего были определены 3 пользователя системы:

Продавец – лицо, работающее на контрольно-кассовом аппарате.

Администратор – лицо, ведущее количественный учет товаров.

Менеджер – управляющий компанией.

Затем были выделены функции каждого пользователя: