Файл: Проектирование реализации операций бизнес-процесса Складской учет (Выбор комплекса задач автоматизации.).pdf

ВВЕДЕНИЕ

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

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

Поставленная цель достигается путем решения следующих задач:

1. Показать преимущества разработки и внедрения программного продукта.
2. Разобрать возможные трудности, которые могут возникнуть при реализации.

Глава 1. Аналитическая часть.

1.1 Выбор комплекса задач автоматизации.

Начнём с анализа того какие проблемы мы должны вывести на передний план на примере предприятия «Монди» чья деятельность заключается в производство и реализация бумаги, целлюлозы и упаковки из возобновляемого древесного волокна, а именно российского сегмента. И так первая, и самая важная задача в начале это - формулирование чёткой системы управления, ведь правильно спроектированная система обеспечить большую часть успеха всего проекта автоматизации. Поэтому прежде чем создавать информационную систему следует пересмотреть систему управления в организации. Изменение бизнес процессов называют реинжинирингом и для начала нужно упорядочить схему бизнес процессов и систему управления организации в целом:

- определиться c организационной структурой;

- произвести выделение основных технологических процессов;

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

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

1.2 Характеристика существующих бизнес – процессов.

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

1.3 Характеристика документооборота, возникающего при решении задачи.

Даже несмотря, что документооборот довольно-таки невелик, используется линейная и не рациональная схема Рисунок 1.,Что добавляет необходимость выполнения следующих целей:

-Введение полного электронного документооборот;

- Обучении более широкого круга персонала;

-Изменение существующей формы управления и обработки экономической информации.

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

1.4 Обоснование проектных решений по информационному обеспечению.

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

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

-Совместная разработке системы с пользователями, в том числе и в рахработке программного обеспечения;

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

Такой подход позволил в определенной степени решить проблему адаптации системы управления и в динамике, поскольку работники предприятия в ходе создания прототипа приобретали навыки работы со средствами проектирования и модификации системы.

1.5 Обоснование проектных решений по программному обеспечению.

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

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

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

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

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

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

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

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

- Разработка (Development);

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

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

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

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

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

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

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

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

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

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

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

Также мы будем использовать в реализации приложения пользователя язык программирования ASP.

ASP (англ. Active Server Pages — «активные серверные страницы») — технология, предложенная компанией Microsoft в 1996 году для создания Web-приложений, эта технология основана на внедрении в обыкновенные веб-страницы специальных элементов управления, допускающих программное управления. технология ASP получила своё развитие в виде ASP.NET — новой технологии создания веб-приложений, основанной на платформе Microsoft .NET.

ASP.NET — технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.NET 4.0b.