57
Microsoft Excel — табличный процессор. Поддерживает все необходимые
функции для создания электронных таблиц любой сложности. Занимает ведущее
положение на рынке. Последняя версия использует формат OOXML с
расширением «.xlsx», более ранние версии использовали двоичный формат с
расширением «.xls». Доступен для использования в семействе ОС MS Windows.
Альтернативы: OpenOffice.org Calc, StarOffice, Gnumeric и Corel Quattro Pro.
В соответствии с принятыми решениями для обеспечения
функционирования разрабатываемой системы необходима установка веб-сервера
IIS и операционной системы Windows Server 2008 R2, Кроме того, обязательна
поддержка языка программирования PHP. Также дополнительно
устанавливается СУБД MySQL. В таком виде информационная систем
предприятия полностью готова к внедрению разрабатываемой системы.
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение определяет совокупность технических средств,
необходимых для работы ИС, а также необходимая документация на эти
средства и технологические процессы.
Развитие технического обеспечения, включающее в себя аппаратные
средства, средства связи, ПО, реализуется неравномерно, скачкообразно.
Становление компьютерной техники на современном этапе происходит в
геометрической прогрессии. Каждые 4 года наблюдается удвоение мощности
компьютеров.
Различие компьютерных технологий по типу пользовательского
интерфейса (каким образом происходит взаимодействие пользователя с
компьютером) - пакетные, диалоговые, сетевые. В первом варианте пользователь
имеет только результаты работы технологии, в остальных он взаимодействует с
ней на личном ПК или ПК, входящем в сеть.
Нынешние технические средства реализации управления
информационными ресурсами по своему составу и возможностям весьма
разнообразны. Средства ЭВМ, средства связи, средства организационной
техники.
58
Компьютерная техника зачастую предназначена для разработки
комплексных технологий анализа и хранения данных и становится основой для
объединения всех новейших технических средств реализации управления
информационными ресурсами.
Коммуникационная техника предназначена зачастую для возможности
передачи данных и включает в себя как автономную работу, так и работу в
комплексе со средствами компьютерной техники.
Организационная техника создана для разработки технологий хранения,
отображения и применения информации, а также для запуска разных
вспомогательных операций в рамках различных технологий информационной
поддержки процесса управления.
В исследуемой задаче автоматизации в качестве технического
обеспечения применяется следующие средства:
• ПК менеджеров;
• Доступные сервера;
• Проложенная ЛВС.
ПК оцениваются по нескольким критериям:
• Скорость работы процессора;
• Полезный объем диска;
• Размер ОЗУ;
• Производительность видеосистемы.
Поскольку разрабатываемый модуль работает на базе клиент-серверной
технологии, то все подсчеты производятся на стороне сервера, поэтому
системные требования к ПК минимальны.
Технические характеристики подходящей рабочей станции приведены в
таблице 1.14.
Таблица 1.14
Характеристики рабочей станции
Характеристика
Значение
Модель процессора
Intel Atom Single Core N270 - 1.66GHz
Оперативная память
2048Mb
Жесткий диск
160 Gb
Оптический привод
DVD-RW
Видеоадаптер
Интегрирован в чипсет
59
Разъемы на материнской плате
7 USB, выход S/PDIF, 2xCOM, D-Sub,
DVI, Ethernet, PS/2 (клавиатура), LPT
Корпус
mATX 250W
Операционная система
Не установлена
Размеры (ШхГхВ)
283 х 282 х 95 (мм)
Кроме того, для работы файл-сервера необходимо закупить
специализированной серверное оборудование, например Team Server 3420P ,
характеристики которого приведены в таблице 1.15.
Таблица 1.15
Технические характеристики рекомендуемого сервера
типичное применение
интернет/интранет-службы, терминальные службы,
контроллер домена, файловый сервер, универсальный
сервер рабочей группы или небольшой компании
процессоры
Один четырехядерный процессор Intel Xeon 3400
кэш-память процессора
64KB кэш-памяти 1-го уровня для каждого ядра
256KB кэш-памяти 2-го уровня для каждого ядра
8 МБ общей для всех ядер кэш-памяти 3-го уровня
серверная платформа
Intel S3420GP
набор микросхем
чипсет Intel 3420
оперативная память
до 32 ГБ ECC Registered DIMM DDR3 800/1066/1333
сетевой контроллер
два интегрированных однопортовых Intel Gigabit
Ethernet
дисковый контроллер/
RAID-контроллер
интегрированный 6-ти портовый Serial ATA II RAID
контроллер (уровни 0, 1, 10)
дисковод/оптический
привод
привод SATA DVD-RW
максимальное
количество внутренних
дисковых отсеков
6 Serial ATA II или SAS
возможность "горячей"
замены дисков
Да
максимальная емкость
внутренних накопителей
6 ТБ SATA (6x1000 ГБ)
6 ТБ SAS (6x1000 ГБ)
интерфейсы
6 портов USB 2.0, Serial port, монитор
графический адаптер
интегрированный видеоконтроллер LLC Pilot II с 64
MB видеопамяти (VGA DB-15)
В данном виде информационная система будет готова к внедрению
разрабатываемого веб-представительства.
60
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Определение жизненного цикла становится одним из главных понятий
методологии проектирования ИС. Жизненный цикл любой ИС можно
отобразить как непрерывный процесс, который начинается в момент принятия
решения о разработке ИС и заканчивается в момент завершения ее
эксплуатации.
Жизненный цикл ИС включает в себя все стадии и этапы ее создания,
сопровождения и развития:
• Анализ предметной, формирование функциональной и
информационной моделей объекта, для которого предназначается ИС;
• Проектирование ИС, основанное на разработке проектных решений,
которые отвечают всем требованиям ТЗ;
• Создание системы (в т. ч. программирование и тестирование ПО на
базе проектных спецификаций подсистем, утвержденных на стадии
проектирования);
• Тестирование ИС и отслеживание сбоев для их последующего
устранения;
• Внедрение и эксплуатация системы;
• Модернизация системы.
Жизненный цикл идет в соответствии с выбранной моделью ЖЦ.
Имеется целый ряд стандартов, определяющих ЖЦ ПО, а иногда и
процессы разработки.
Среди самых известных стандартов выделяют следующие:
• ГОСТ 34.601-90 - распространяется на АИС и указывает в себе
стадии и этапы их создания. Также в нем имеется описание содержания работ на
всех этапах. Стадии и этапы работы, отраженные в стандарте, зачастую
соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 - стандарт на процессы и реализацию
жизненного цикла. Применяется ко всем видам заказного ПО. Стандарт не имеет
описания стадий, фаз и этапов.
61
• Custom Development Method по созданию прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных
документов, которые рассчитаны на применение в проектах совместно с Oracle.
Используется CDM для типовой модели ЖЦ (имеются все работы/задачи и
этапы), а также для случаев "быстрой разработки" (Fast Track) или
"облегченного подхода", которые будут оптимальны в малых проектах.
• Rational Unified Process (RUP) включает в себя итеративную модель
разработки, имеющую четыре фазы: старт, анализ, создание и использование.
Все эти фазы могут быть разделены на этапы (итерации), по итогу которых
имеется версия для внутреннего или внешнего использования. Реализация
четырех основных фазы считается циклом разработки, и любой такой цикл
завершается созданием версии системы. В случае, если работа над проектом не
прекращается и после этого, полученный продукт продолжает оптимизироваться
и снова проходит те же фазы. Суть реализации в рамках RUP - это разработка и
сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) похож на RUP, так же имеет
четыре фазы: исследование, построение, создание, стабилизация, является
итерационным, включает в себя применение объектно-ориентированного
моделирования. MSF в отличии от RUP в сильнее ориентирован на создание
бизнес-приложений.
• Extreme Programming (XP). Экстремальное программирование
(самая молодая среди остальных методологий) было реализовано в 1996 году. В
основе методологии лежит командная работа, четкая коммуникация между
исполнителем и заказчиком в течение всего срока проекта, а сама разработка
реализуется методом последовательной доработки прототипов.
Стандарт ISO/IEC серии 15288.
В стандарте ISO/IEC 12207 нет конкретной модели жизненного цикла и
методик разработки, его характеристики становятся общими для любых моделей
жизненного цикла. Моделью обычно называется структура, позволяющая
выразить последовательность реализации и взаимосвязи процессов, задач и
действий в процессе всего жизненного цикла.
62
Стандартом, который используется для создания ЖЦ задачи, является
ГОСТ ISO/IEC 12207 [31]. Он выбран на основании того, что.:
данный стандарт является более ориентированным на совершенно
любые виды ПО и типы проектов автоматизированных систем (АС).
стадии и этапы работы по этому стандарту соответствуют
каскадной модели.
Первый этап отражает то, как аналитик проводит планирование и анализ
требований задачи учета и обработки заявок и формирует документацию. Он
состоит из следующих задач: «Исследование и анализ задачи», «Определение
требований к задаче» и «Оформление технико-экономического обоснования
(ТЭО) и технического задания (ТЗ) задачи. В этом этапе участвует начальник
отдела, который контролирует процесс выполнения этапа в целом. После
завершения первого этапа ЖЦ происходит переход на второй этап, где
проектировщик на основании документации аналитика проводит
проектирование задачи и формирует документацию. Он состоит из следующих
задач: «Разработка функциональной архитектуры (ФА) и системной
архитектуры (СА) задачи» и «Оформление технического проекта задачи».в этом
этапе участвует начальник отдела, который контролирует процесс выполнения
этапа в целом. По окончании данного второго этапа наступает черед следующего
этапа, т.е. третьего этапа, а именно реализации задачи, который подразумевает
разработку (программирование) программы учета и обработки заявок. Данный
этап проводится на основании той документации, которую дал ему
проектировщик. Он состоит из таких задач, как «Разработка и настройка СУ»,
«Создание рабочей инструкции по СУ» и «Оформление рабочей СУ». Также в
этом этапе участвует начальник отдела, который контролирует процесс
выполнения этапа в целом.
После завершения третьего этапа осуществляется переход к четвертому
этапу внедрения той задачи, которую разработал программист (внедрение задачи
учета и обработки заявок). Внедрение автоматизированного решения – процесс
ввода в практическую эксплуатацию этого решения на различных сферах
деятельности предприятиях. Четвертый этап состоит таких задач, как [1]:
установка программы;
63
обучение работе с программой;
тестовая эксплуатация программы;
оформление акта о приемо-сдаточных испытаний (ПСИ);
Первая задача этапа - установка программы - выполняется системным и
сетевым администратором. Второй задачей является задача обучения работе с
программой менеджера. Она проводится тем, кто проектировал данную задачу,
т.е. проектировщиком. Далее, выполняется третья задача – тестовая
эксплуатация программы. Она проводится менеджером, который ведет и будет
вести учет заявок. После выполнения третьей задачи начинается выполнение
четвертой, т.е. оформления акта о ПСИ, где менеджер демонстрирует программу
начальнику отдела и директору компании, чтобы они все вместе оценили
данную разработку, которое в последующем будет официально принято как
программа по учету и обработке заявок. В целом, срок выполнения данных
этапов ЖЦ составляет полгода.
После того, как была разработана и установлена программа по учету
внутренних заказов оборудования, начинается пятый этап ЖЦ – эксплуатация
задачи учет заявок. Эксплуатация автоматизированного решения – практическое
использование автоматизированного решения в разных сферах деятельности
предприятиях. Этап эксплуатации состоит из следующих задач:
проведение учета заявок;
администрирование учета заявок;
проверка программной и технической документации;
выявление недостатков задачи учета и обработки заявок и
формирования технического задания (ТЗ);
создание новой версии ПОк задаче учета и обработки заявок.
Проведение учета заявок – задача менеджера, который участвует в этой
задаче на 100%, его функции регулируются должностной инструкцией.
Администрирование учета и обработки заявок – задача контроля и
устранения возникших программных, информационных и технических проблем
в данной предметной области. Данная задача выполняется системным и сетевым
администратором, который участвует в ней на 100% и регулируется
должностной инструкцией.
64
Проверка программной и технической документации - задача проверки в
реальных условиях теоретического построения схем, методов, моделей,
описанных для задачи. В конкретном случае, она подразумевает проверку
соответствия документарных и практических данных, как в общем случае, так и
проведя детальный анализ задачи. Она выполняется аналитиком, который
участвует в этой задаче на 100%, и регулируется должностной инструкцией.
Выявление недостатков задачи учета и обработки заявок и формирование
ТЗ - задача выявления недостатков (нарушений работы) ПО задачи, по которым
формируется ТЗ к модифицированному решению, которые выявляются при
проверке программной и технической документации. Все эти недостатки
проявляют себя в течение срока эксплуатации. После этого заканчивается
процесс выявления недостатков и начинается внедрение модифицированного
решения. Он выполняется аналитиком, который участвует в этой задаче на
100%, и регулируется должностной инструкцией.
Создание новой версии ПО для учета и обработки заявок – задача
переработки технологии задачи: добавление новых методов, действий и
функций, а также, вероятно, изменение всей структуры ПО и его интерфейса. Ее
выполнение происходит в конце этапа эксплуатации ЖЦ, и после окончания
работы над новой версией, она будет использовано как программа по учету
внутренних заказов оборудования. Эта задача реализуется программистом.
Степень его участия в этом виде задач равна 100%, регулируется задача
должностной инструкцией. Все этапы ЖЦ регулируются его регламентом ЖЦ
задачи.
Каждый этап ЖЦ задачи имеет свои цели достижения и результаты,
которые должны быть получены в конце каждого его этапа. Целью первого этапа
(планирование и анализ требований задачи учета и обработки заявок) является
изучение и исследование предметной области данной задачи, и составление к
ней требований, а его результатом является список функций учета, т.е. принятия
к рассмотрению заказа, проверка наличия оборудования в резерве, поиск
поставщиков, отмена заказа, приостановление/восстановление заказа,
согласование заказа и отправка заказа.
65
Целью второго этапа (проектирование задачи учета и обработки заявок)
является разработка концепции технологии задачи и программы по учету
внутренних заказов оборудования, а его результатами служат [31]:
информационная модель задачи;
функциональные модели программы в целом и подсистем,
реализуемых отдельными командами разработчиков;
точно определенные с помощью CASE-средства интерфейсы между
автономно разрабатываемыми подсистемами;
построенные прототипы экранов, отчетов и диалогов.
Целью третьего этапа (реализация задачи учет заявок) является разработка
автоматизированного решения программы по учету внутренних заказов
оборудования и ввод ее в эксплуатацию, а его результатом является полностью
законченное ПО, готовое к его использованию.
Целью четвертого этапа (внедрение задачи учета и обработки заявок)
является замена ПО на автоматизированное, а его результатом является
официально-зарегистрированное внедрение ПО.
Целью последнего пятого этапа (эксплуатация задачи учета и обработки
заявок) является сам непосредственный учет и обновление версии данной
программы, а его результатом является обновленная версия ПО.
Типичная каскадная модель, несмотря на негативную оценку за последние
несколько лет, исправно служила специалистам по программному инжинирингу
долгое время. Понимание ее сильных сторон и недостатков значительно
улучшает оценочный анализ других, даже более эффективных моделей ЖЦ,
базирующихся на данной модели.
Каскадная модель включает в себя много преимуществ, если ее применять
в проекте, для которого она предназначена и приемлема. Далее указаны эти
преимущества:
• Модель отлично известна потребителям, не относящимся к
разработке и обслуживанию программ, и конечным пользователям (зачастую она
используется другими компаниями для отслеживания проектов, не связанных с
созданием ПО);
66
• Она логичнее справляется со сложностями и отлично показывает
себя в тех проектах, где все достаточно понятно, но все равно трудно
разрешимо;
• Она вполне доступна для понимания, поскольку преследует
простую цель — реализовать нужные действия;
• Она удобна и проста в использовании, поскольку сам процесс
разработки реализован поэтапно;
Но в случае применения каскадной модели для проекта, который нельзя
назвать подходящим для нее, выявляются некоторые недостатки:
• Модель основана на последовательной линейной структуре,
поэтому каждая попытка возврата на одну или две фазы назад для исправления
какой-либо проблемы или недостатка приводит к серьезному увеличению затрат
и сбою в графике;
• Модель не предотвращает возникновение итераций между фазами,
часто встречающиеся в процессе создания ПО, т.к. сама модель разрабатывается
согласно обычному циклу аппаратного инжиниринга;
• Модель не показывает главное свойство создания ПО, направленное
на решение задач. Отдельные фазы жестко связаны с конкретными действиями,
что входит в разрез с реальной работой персонала или коллективов;
• Модель создает ошибочное впечатление о работе над проектом.
Понятие типа "25% выполнено" не имеет никакого смысла и не может являться
показателем для менеджера проекта.
Ввиду недостатков каскадной модели ее использование ограничено
ситуациями, в которых требования и их реализация максимально четко
прописаны и понятны.
Каскадная модель замечательно функционирует при ее использовании в
циклах разработки ПО, в которых применяется неизменяемое определение
продукта и четко понятны технические методики.
V-образная модель создается для поддержки работающей над проектом
команды в планировании с реализацией дальнейшей возможности проверки
системы. В этой модели главное значение придается действиям, направленным
на подтверждение и проверку продукта. Она отражает, что проверка продукта