46
потому, что обладает всеми возможности для разработки серверной части веб-
приложений. В частности, в нем поддерживается автоматический сборщик
мусора, полиморфизм, SQL-подобный язык запросов LINQ для удобного
создания запросов к базе данных вместо сложных SQL-запросов, лямбда-
выражения, сокращающие количество кода, анонимные типы и другие
возможности, облегчающие работу программиста [13].
1.4.3 Обоснование проектных решений по техническому обеспечению
Поскольку автоматизацию планируется осуществить на основе клиент-
сервера, то архитектура технической части будет делиться на серверную и
клиентскую части.
Для достижения наилучшего результата, серверную и клиентскую часть
необходимо объединить в единую локальную сеть, а для обеспечения
желаемого результата связь необходимо осуществить на основе технологии
Ethernet, пропускная способность сети должна быть не менее 100 Мб/сек.
Выбор технического обеспечения серверной части предлагается
произвести из серверов средней ценовой категории. Интересующие
характеристики [7]:
процессор Intel Core 2 2.2 GHz или выше (предоставляет нужную
вычислительную скорость для выполнения поставленной задачи);
оперативная память не менее 4.00 Гб (обеспечит стабильную работу
системы без зависаний и иных системных ошибок с нагрузкой поступающей
информации);
Жесткие диски не менее двух с объёмом от 500 Гб (позволяют
хранить достаточно большой архив информации);
Материнская плата с технологией RAID (для установки двух жестких
дисков в один массив);
Выбор сервера предложен в таблице 1.9.
47
Таблица 1.9
Выбор сервера
Фирма
Процессор
ОЗУ
Жесткий
диск
RAID
Цена(BYN)
ASUS
2.4
4.00
2*500Гб
+
2270
HP
2.2
4.00
2*1Тб
+
2490
Gigabyte
2.6
4.00
2*1Тб
+
2841
Был выбран сервер фирмы Gigabyte, так как он полностью отвечает
требованиям для внедрения системы обработки заявок.
Для организации рабочей станции понадобятся:
Процессор не ниже Pentium 4 1,2 Ghz (предоставляет нужную
вычислительную скорость для выполнения поставленной задачи);
Материнская плата со встроенной видеокартой и Lan;
Жесткий диск не менее 40 Гб (позволяет хранить достаточно
большой архив информации);
Оперативная память не менее 512 Мб (обеспечит стабильную
работу системы без зависаний и иных системных ошибок с нагрузкой
поступающей информации);
Монитор LCD с диагональю 19 дюймов (обеспечит отображение
выводимой информации в нужном соотношении);
Мышь (позволяет управлять диалоговыми формами);
Клавиатура (обеспечит ввод информации по заявкам).
Стоит отметить, что приобретать техническое обеспечение необходимо с
расчетом того, чтобы его можно было обновить, например, процессор. В таком
случае, надобность в полной замене сервера либо клиента отпадет.
Техническое обеспечение не должно подвергаться максимальным
климатическим условиям (жара, холод и т.д.) [8].
Все техническое обеспечение необходимо эксплуатировать с
соблюдением норм и техники безопасности, проветривать помещения, менять
устаревшее оборудование согласно рекомендациям производителя – это
обезопасит всю рабочую систему от различных технических сбоев.
48
Выводы по разделу: В разделе 1 была рассмотрена основная
аналитическая часть дипломного проекта. Была дана технико-экономическая
характеристика, как предметной области, так и предприятия ООО «Пилснаб».
Определены основные требования к разрабатываемому проекту, поставлены
задачи и обоснование в необходимости автоматизации информационной
системы учета заявок, описан выбор комплекса задач автоматизации и дана
характеристика существующих бизнес-процессов.
49
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Для реализации проектного решения, необходимо первоначально
выделить основные этапы жизненного цикла будущей системы. Из всех
имеющихся стандартов, наиболее оптимальным будет ISO ISO 1220. Выбор пал
именно на этот стандарт, в связи со следующими факторами:
1) стандарт четко не регламентирует последовательность процессов в
каждом этапе, что позволяет самостоятельно выбирать подходящие для себя
процессы.
2) стандарт охватывает все этапы более полно, нежели остальные
стандарты.
3) ISO 12207 не указывает на этапы, а лишь регламентирует их, что
позволит разработчику самостоятельно управлять жизненным циклом.
4) стандарт ISO 12207 2010 в равной степени ориентирован на
организацию действий каждой из двух сторон: поставщика (разработчика) и
покупателя (пользователя); он может быть применен и в том случае, когда обе
стороны - из одной организации.
Данный стандарт, используя устоявшуюся терминологию, устанавливает
общую структуру процессов жизненного цикла программных средств, на
которую можно ориентироваться в программной индустрии.
Стандарт группирует различные виды деятельности, которые могут
выполняться в течение жизненного цикла программных систем, в семь групп
процессов. Каждый из процессов жизненного цикла в пределах этих групп
описывается в терминах цели и желаемых выходов, списков действий и задач,
которые необходимо выполнять для достижения этих результатов [14].
процессы соглашения — два процесса;
процессы организационного обеспечения проекта — пять процессов;
процессы проекта — семь процессов;
технические процессы — одиннадцать процессов;
50
процессы реализации программных средств — семь процессов;
процессы поддержки программных средств — восемь процессов;
процессы повторного применения программных средств — три процесса.
Каждый процесс включает ряд действий. Каждое действие включает ряд
задач. Например, подготовка заявочных предложений должна предусматривать:
Формирование требований к системе;
Формирование списка программных продуктов;
Установление условий и соглашений.
Описание технических ограничений (среда функционирования системы и т. д.)
Рис. 2.1 Структура стандарта ISO 12207-2010
На первоначальном этапе после проведения анализа деятельности
организации, необходимо поставить цели и задачи автоматизации и разработать
51
план проекта. После документального оформления начинается
непосредственно сам процесс разработки. Создается база данных, отчетные
формы, пишется программный код по сбору, обработке и хранению
информации, создаются процедуры фильтрации. После разработки системы,
проходит этап тестирования. По завершению тестирования готовится план
эксплуатации и документация для внедрения, а также различная
пользовательская документация. Процесс будет происходить следующим
образом. Так как в организации уже существует ЛВС и стабильно
функционирует, в ее наладке нет необходимости. Первоначально
устанавливается серверная часть системы учета заявок, далее на рабочие места
проходит установка и настройка клиентских приложений системы учета заявок
и СУБД. Тестируется работоспособность, проводится демонстрация работы
системы для руководства и персонала. Последней стадией будет проведение
семинаров для сотрудников компании. Необходимо связать всех сотрудников,
отвечающих за обработку документов в единую информационную сеть. Для
этого клиентские приложения будут устанавливаться в четкой
последовательности по определенным отделам [3].
За эксплуатацию готовой системы, будет отвечать заместитель
начальника. В его задачу будет входить:
1. Разработка плана эксплуатации и определения набора стандартов
эксплуатации.
2. Получение и документирование сведений о возникающих проблемах,
их решение и контроль за возникновением, обеспечение обратной связи с
пользователями.
3. Тестирование системы в эксплуатационной среде, кооперация со
службой сопровождения для устранения возникших проблем и модернизации
системы.
4. Поддержка и консультация пользователей.
Далее выберем модель жизненного цикла информационной системы.
В настоящее время наиболее распространены следующие модели:
Каскадная;
52
Спиральная;
Итеративная.
Каскадный подход неплохо зарекомендовал себя при создании
относительно простых ИС, когда в самом начале проекта можно очень точно и
емко сформулировать нужные требования к системе. Главным недостатком
такого подхода можно назвать то, что процесс реального создания системы не
может полностью уложится в такую жесткую схему, постоянно есть
потребность в возвращении к предыдущим этапам и просмотре или изменении
ранее принятых решений. В итоге реальный процесс разработки ИС
оказывается похож на поэтапную модель с промежуточным контролем.
Выделяют следующие положительные стороны использования
каскадного подхода:
Каждый этап включает в себя законченный набор проектной
документации, отвечающий критериям согласованности и полноты;
Реализуемые в логической последовательности работы дают
возможность планировать сроки завершения всех работ и подсчитывать
затраты.
Цикличная модель ЖЦ создавалась для преодоления
вышеперечисленных проблем. На этапах анализа и проектирования степень
создания технических решений и удовлетворенность потребностей заказчика
оценивалась методикой создания прототипов. Каждый цикл характеризовал
создание работоспособного фрагмента или версии программы. Такой подход
позволял уточнить требования, цели и параметры проекта, оценить качество
разработки, выделить работы следующего цикла. Таким образом, углубляются и
оговариваются детали проекта, и в результате применяется обоснованный
вариант, удовлетворяющий всем требованиям заказчика, который затем уже
доводится до финальной реализации [6].
Но и такая схема не дает возможности оперативно учитывать
возникающие доработки и изменения требований к системе. Согласование
параметров разработки с пользователями делается только в отдельных точках,
планируемых после завершения некоторого объема работ, а общие требования к
53
ИС отражены в техническом задании на все время ее создания. Поэтому
пользователи часто получают систему, которая не полностью удовлетворяет их
реальным потребностям.
Итеративная разработка показывает объективно существующий цикл
разработки сложных систем. Она дает возможность переходить на следующий
этап, не дожидаясь окончательного завершения работы на текущем этапе и
решить главную задачу – оперативное и быстрее представить пользователям
работоспособный продукт, тем самым, заранее начиная процесс уточнения
корректировки требований.
Главная проблема спирального цикла в определении момента перехода на
другой этап. Для ее решения внедряются временные ограничения на все этапы
жизненного цикла, и переход производится в соответствии с планом, даже если
работы по прошлому этапу еще не завершены. Планирование производится на
базе статистических сведений, полученных при подготовке других проектов, а
также из личного опыта разработчиков [6].
Для разработки системы выбираем каскадную модель, так как она
последовательна и четко регламентирует все выполненные процедуры.
Ключевыми этапами проекта разработки, обеспечивающими
достижение поставленной цели, являются:
Проведение анализа существующей модели показателей деятельности
и бизнес процессов Предприятия. Разработка целевой модели показателей
деятельности, используя лучшие мировые практики построения моделей
данных, большой опыт и высокую квалификацию специалистов Исполнителя.
Формирование технического задания на проектирование, разработку и
внедрение системы.
Разработка организационных и технических регламентов по
информационному взаимодействию.
Разработка технического проекта (архитектуры) будущей Системы.
Разработка Системы в разрезе подсистем, указанных в технических
требованиях.
54
Проведение пуско-наладочных (внедрение, коррекция и модификация)
работ Системы.
Разработка документации и обучение пользователей Системы.
Проведение тестирования и приемо-сдаточных испытаний Системы.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация пилотного проекта.
Стратегия «Опытная эксплуатация пилотного проекта» не подходит, так
как компания не располагает достаточными ресурсами для длительной
эксплуатации проекта с целью выявления всех возможных ошибок. Стратегия
Скачек не позволяет плавно перейти на использование разработки, узкое место
больше подходит для использования в крупных компаниях. Поэтому в качестве
стратегии внедрения информационной системы выбираем параллельную
стратегию, то есть разработанная информационная система будет
использоваться параллельно с используемой технологией до полного
вытеснения последней. В нашей ситуации сотрудники будут какое-то время
продолжать создавать заявки вручную, переходя по кабинетам и подписывая их.
Одновременно будет внедряться автоматизированная система, изначально
дублируя заявки, созданные вручную. Со временем, когда параллельное
существование двух систем проявит свою трудоемкость, будет полностью
отменена ручное согласование.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Рассмотрим типы рисков, которые возможны при реализации проекта.
Проектный тип рисков. В него включены риски, которые связаны с
проблемами персонала организации; риски различных изменений в текущем
законодательстве. В первую очередь, изначально может быть проведен
недостаточно качественный анализ требований, в ходе которого будут учтены
55
не все потребности клиента, или же не выявлены детали реализации
требований. В связи с этим может произойти то, что в ходе разработки
значительно увеличиться время на функциональность, и сроки проекта будут
затянуты. Для рассматриваемого проекта был проведен достаточный анализ
осуществляемого процесса осуществления заявки на материалы, в ходе
которого установлены все действующие лица, все детали процесса. Это
уменьшает этот риск, так как система первоначально строится под потребности
организации.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений, а именно риски, связанные с
неспособностью разработчиков выполнить необходимую задачу. Данный
проект разрабатывается квалифицированным программистом, работающим на
предприятии, что исключает наличие данного риска. В случае необходимости
имеется возможность получить консультацию у других специалистов.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски
сокращения бюджета, приводящие не только к сокращению проекта и его
задач, но и к его полному провалу в случае не достижения основной цели; риск
потери интереса к задаче ведения и учета внутренних заказов материалов со
стороны конечных пользователей, риски при оценке рынка данного вида учета.
Данный тип рисков невозможно исключить, но его можно минимизировать.
Действительно, может случиться так, что конечный пользователь перестанет
пользоваться системой для заказа материалов и оборудования в первую очередь
потому, что в организацию данную процедуру просто отменят. В случае такого
необходимо провести повторный анализ предметной области и выявить те
отделы или области, где подобная процедура все же используется, пусть даже
для осуществления заказа других вещей (к примеру, канцелярских товаров,
офисного оборудования) [5].
Главные риски при создании проекта:
Риски, связанные с размерами проекта;
Риски, связанные с малым опытом в IT-сфере;