Дипломная работа: Автоматизация обработки заявок ООО «Пилснаб»

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
51
план проекта. После документального оформления начинается
непосредственно сам процесс разработки. Создается база данных, отчетные
формы, пишется программный код по сбору, обработке и хранению
информации, создаются процедуры фильтрации. После разработки системы,
проходит этап тестирования. По завершению тестирования готовится план
эксплуатации и документация для внедрения, а также различная
пользовательская документация. Процесс будет происходить следующим
образом. Так как в организации уже существует ЛВС и стабильно
функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета заявок, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета заявок
и СУБД. Тестируется работоспособность, проводится демонстрация работы
системы для руководства и персонала. Последней стадией будет проведение
семинаров для сотрудников компании. Необходимо связать всех сотрудников,
отвечающих за обработку документов в единую информационную сеть. Для
этого клиентские приложения будут устанавливаться в четкой
последовательности по определенным отделам [3].
За эксплуатацию готовой системы, будет отвечать заместитель
начальника. В его задачу будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.
2. Получение и документирование сведений о возникающих проблемах,
их решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
3. Тестирование системы в эксплуатационной среде, кооперация со
службой сопровождения для устранения возникших проблем и модернизации
системы.
4. Поддержка и консультация пользователей.
Далее выберем модель жизненного цикла информационной системы.
В настоящее время наиболее распространены следующие модели:
Каскадная;
52
Спиральная;
Итеративная.
Каскадный подход неплохо зарекомендовал себя при создании
относительно простых ИС, когда в самом начале проекта можно очень точно и
емко сформулировать нужные требования к системе. Главным недостатком
такого подхода можно назвать то, что процесс реального создания системы не
может полностью уложится в такую жесткую схему, постоянно есть
потребность в возвращении к предыдущим этапам и просмотре или изменении
ранее принятых решений. В итоге реальный процесс разработки ИС
оказывается похож на поэтапную модель с промежуточным контролем.
Выделяют следующие положительные стороны использования
каскадного подхода:
Каждый этап включает в себя законченный набор проектной
документации, отвечающий критериям согласованности и полноты;
Реализуемые в логической последовательности работы дают
возможность планировать сроки завершения всех работ и подсчитывать
затраты.
Цикличная модель ЖЦ создавалась для преодоления
вышеперечисленных проблем. На этапах анализа и проектирования степень
создания технических решений и удовлетворенность потребностей заказчика
оценивалась методикой создания прототипов. Каждый цикл характеризовал
создание работоспособного фрагмента или версии программы. Такой подход
позволял уточнить требования, цели и параметры проекта, оценить качество
разработки, выделить работы следующего цикла. Таким образом, углубляются и
оговариваются детали проекта, и в результате применяется обоснованный
вариант, удовлетворяющий всем требованиям заказчика, который затем уже
доводится до финальной реализации [6].
Но и такая схема не дает возможности оперативно учитывать
возникающие доработки и изменения требований к системе. Согласование
параметров разработки с пользователями делается только в отдельных точках,
планируемых после завершения некоторого объема работ, а общие требования к
53
ИС отражены в техническом задании на все время ее создания. Поэтому
пользователи часто получают систему, которая не полностью удовлетворяет их
реальным потребностям.
Итеративная разработка показывает объективно существующий цикл
разработки сложных систем. Она дает возможность переходить на следующий
этап, не дожидаясь окончательного завершения работы на текущем этапе и
решить главную задачу оперативное и быстрее представить пользователям
работоспособный продукт, тем самым, заранее начиная процесс уточнения
корректировки требований.
Главная проблема спирального цикла в определении момента перехода на
другой этап. Для ее решения внедряются временные ограничения на все этапы
жизненного цикла, и переход производится в соответствии с планом, даже если
работы по прошлому этапу еще не завершены. Планирование производится на
базе статистических сведений, полученных при подготовке других проектов, а
также из личного опыта разработчиков [6].
Для разработки системы выбираем каскадную модель, так как она
последовательна и четко регламентирует все выполненные процедуры.
Ключевыми этапами проекта разработки, обеспечивающими
достижение поставленной цели, являются:
Проведение анализа существующей модели показателей деятельности
и бизнес процессов Предприятия. Разработка целевой модели показателей
деятельности, используя лучшие мировые практики построения моделей
данных, большой опыт и высокую квалификацию специалистов Исполнителя.
Формирование технического задания на проектирование, разработку и
внедрение системы.
Разработка организационных и технических регламентов по
информационному взаимодействию.
Разработка технического проекта (архитектуры) будущей Системы.
Разработка Системы в разрезе подсистем, указанных в технических
требованиях.
54
Проведение пуско-наладочных (внедрение, коррекция и модификация)
работ Системы.
Разработка документации и обучение пользователей Системы.
Проведение тестирования и приемо-сдаточных испытаний Системы.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация пилотного проекта.
Стратегия «Опытная эксплуатация пилотного проекта» не подходит, так
как компания не располагает достаточными ресурсами для длительной
эксплуатации проекта с целью выявления всех возможных ошибок. Стратегия
Скачек не позволяет плавно перейти на использование разработки, узкое место
больше подходит для использования в крупных компаниях. Поэтому в качестве
стратегии внедрения информационной системы выбираем параллельную
стратегию, то есть разработанная информационная система будет
использоваться параллельно с используемой технологией до полного
вытеснения последней. В нашей ситуации сотрудники будут какое-то время
продолжать создавать заявки вручную, переходя по кабинетам и подписывая их.
Одновременно будет внедряться автоматизированная система, изначально
дублируя заявки, созданные вручную. Со временем, когда параллельное
существование двух систем проявит свою трудоемкость, будет полностью
отменена ручное согласование.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Рассмотрим типы рисков, которые возможны при реализации проекта.
Проектный тип рисков. В него включены риски, которые связаны с
проблемами персонала организации; риски различных изменений в текущем
законодательстве. В первую очередь, изначально может быть проведен
недостаточно качественный анализ требований, в ходе которого будут учтены
55
не все потребности клиента, или же не выявлены детали реализации
требований. В связи с этим может произойти то, что в ходе разработки
значительно увеличиться время на функциональность, и сроки проекта будут
затянуты. Для рассматриваемого проекта был проведен достаточный анализ
осуществляемого процесса осуществления заявки на материалы, в ходе
которого установлены все действующие лица, все детали процесса. Это
уменьшает этот риск, так как система первоначально строится под потребности
организации.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений, а именно риски, связанные с
неспособностью разработчиков выполнить необходимую задачу. Данный
проект разрабатывается квалифицированным программистом, работающим на
предприятии, что исключает наличие данного риска. В случае необходимости
имеется возможность получить консультацию у других специалистов.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски
сокращения бюджета, приводящие не только к сокращению проекта и его
задач, но и к его полному провалу в случае не достижения основной цели; риск
потери интереса к задаче ведения и учета внутренних заказов материалов со
стороны конечных пользователей, риски при оценке рынка данного вида учета.
Данный тип рисков невозможно исключить, но его можно минимизировать.
Действительно, может случиться так, что конечный пользователь перестанет
пользоваться системой для заказа материалов и оборудования в первую очередь
потому, что в организацию данную процедуру просто отменят. В случае такого
необходимо провести повторный анализ предметной области и выявить те
отделы или области, где подобная процедура все же используется, пусть даже
для осуществления заказа других вещей примеру, канцелярских товаров,
офисного оборудования) [5].
Главные риски при создании проекта:
Риски, связанные с размерами проекта;
Риски, связанные с малым опытом в IT-сфере;
Источник: https://baza.diplomsite.ru/previewfile/1897