47
различных форматов, которые находятся на рабочих станциях или сетевом
сервере или крупных ЭВМ. Сотрудник фирмы, который решает некие задачи, не
обязан тратить много времени на то, чтобы разобраться, как собрать данные из
разных электронных источников, чтобы потом при помощи электронной
таблицы сделать диаграмму. Применяя MS Access, сотрудник довольно легко
получает прямой доступ к необходимым исходным данным, также осуществит
запрос для получения нужной информации и создаст потом отчет с вложенной в
него диаграммой или же графиком – и это все осуществляется с помощью одной
программной среды (MS Access). Поэтому данная способность брать данные из
различных источников в сочетании с легкостью применения дают возможность
MS Access быть довольно мощным средством для разработки систем обработки
информации в организации.
Для больших фирм особо важным является то, что MS Access надежно
адаптирован для создания различного программного обеспечения рабочих
станций в сетях «клиент-сервер». Отличительная особенность MS Access от
других систем разработки различных приложений в среде Windows заключается
в том, что облегчения разработки форм и отчетов в MS Access экономит много
времени разработчика базы данных. Разработанные в MS Access различные
приложения могут использоваться на различных уровнях корпорации [7, c. 542].
Отметим также, что в MS Access довольно просто спроектировать
приложение, на самом деле «дружественное пользователю» и полной мере
использующее возможности его компьютера.
Разрабатываемая нами база данных «Прием заявок на ремонт и
модернизацию ПК» в MS Access будет состоять из следующих таблиц: «Склад
компьютерных комплектующих»: «Материнские платы»; «Жесткий диск»;
«Видеоадаптер»; «Мониторы»; «Клавиатура»; «Манипулятор мышь»; «Модули
памяти»; «Покупатель». Создаваемые нами таблицы в окне «Конструктор» в MS
Access позволят значительно автоматизировать управление данными отдела по
приемке заявок на ремонт и модернизацию ПК в ООО «Джет» г. Гродно.
В базе данных «Прием заявок на ремонт и модернизацию ПК» все формы
будут разрабатываться в режиме «Конструктор форм».
48
Для всех элементов управления расположенных на формах базы данных
«Прием заявок на ремонт и модернизацию ПК» будет разработан код на языке
Visual Basic for Office для их автоматизации процесса приема заявок на ремонт и
модернизацию ПК в ООО «Джет» г. Гродно.
2.1.3. Обоснование проектных решений по техническому обеспечению
Обеспечение техническое – это объединение технических средств,
компьютерной техники, а также средств передачи информации с одного
компьютера на другие, используемых в автоматизированных системах
управления и в информационных системах.
Для работы программы по приему заявок на ремонт и модернизацию ПК
достаточно тех компьютеров, которые имеются в наличие у ООО «Джет» г.
Гродно.
Технические характеристики ПК ООО «Джет» г. Гродно:
Процессор: Intel Celeron Dual Core G530 (Sandy Bridge, 2.40ГГц,
LGA1155, L3 2048Kb)
Память: DDR3 2048 Mb (pc-10660) 1333MHz
Материнская плата: S1155, iH61, 2*DDR3, PCI-E16x, SVGA, DVI,
SATA, Lan, mATX, Retail
Видеокарта встроенная Intel® HD Graphics 512Мб
Сетевая карта есть (10/100 Ethernet).
Архитектура платформ ООО «Джет» г. Гродно включает в себя:
аппаратные средства вычислительной техники – 1 сервер, 12 рабочих
станций, накопители, а также и другое компьютерное оборудование;
аварийные планы по обеспечению бесперебойной работы аппаратуры
(главным образом – сервера) и баз данных в условиях чрезвычайных
обстоятельств.
операционные и управляющие системы, утилиты и офисные
программные системы;
Все это в полой мере подходит для полного функционирования
разрабатываемой базы данных «Прием заявок на ремонт и модернизацию ПК».
49
2.2. Разработка проекта автоматизации
2.2.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла – это структура, содержащая процессы,
действия, а также задачи, которые происходят в процессе конкретной
разработки, функционирования и дальнейшее сопровождения разработанного
программного продукта в дальнейшем в течение всей жизни данной системы, от
определения определенных требований и затем до стадии завершения ее
дальнейшего применения.
На данном этапе развития имеются определенное количество моделей и
стандартов, в разной степени определяющих регламент жизненного цикла,
большую часть из них относят к заказному ПО (программному обеспеченью).
Так, например, ГОСТ 34.601-90 относят на автоматизированные системы
и он определяет стадии и этапы их создания. Также, в данном стандарте имеется
подробное описание содержания работ на каждом этапе. Стадии и этапы работы,
отраженные в данном стандарте, в довольно большой степени отражают
каскадную модель жизненного цикла.
Например, ISO/IEC 12207:1995 – это стандарт, который отражает
процессы и организацию жизненного цикла. Его относят на все без исключения
виды заказного ПО. Данный стандарт не имеет описания фаз, а также и стадий
этапов.
Custom Development Method (далее CDM) – это стандарт, который
отражает разработку различных прикладных информационных систем под заказ
потребителей данных систем – конкретный материал, детальный до уровня
различных заготовок проектных документов, направленных на применение в
проектах с использованием Oracle. Мера адаптации CDM имеет ограничение 3-
мя моделями жизненного цикла: «классическая» (заложены все необходимые
работы/задачи, а также этапы), «быстрая разработка» (Fast Track), «облегченный
подход», он рекомендуется, если в случае небольших проектов и возможности
довольно быстро прототипировать необходимые приложения.
50
Rational Unified Process (далее RUP) – это стандарт, который отражает
итеративную модель разработки проекта, которая включает 4-ре необходимые
фазы: начало, исследование, построение и затем внедрение. Любая из этих фаз
может быть при необходимости разбита на определенные этапы (итерации), в
использовании которых выдается версия либо для внутреннего, либо для
внешнего применения. Проход через 4-ре главные фазы именуется циклом
разработки, причем каждый цикл заканчивается генерацией полученной версии
проектируемой системы. Если после всего этого данная работа над заданным
проектом не завершается, то сделанный продукт в дальнейшем продолжают
развивать и заново проходя те же фазы разработки. Сущность работы в заданных
рамках RUP – это разработка и дальнейшее сопровождение моделей, а не
простых стандартных бумажных документов, посему данный процесс
непосредственно привязан к применению определенных средств моделирования
(UML), а так же определенной технологии при проектировании и дальнейшей
разработки (например, объектно-ориентированный анализ, object-oriented
analysis, OOA, объектно-ориентированное программирование, object-oriented
programming, OOP).
Microsoft Solution Framework (далее MSF) – это стандарт, который сходен
с RUP, он так же имеет 4-ре фазы: анализ, проектирование, разработка,
стабилизация, является итерационной, задает применение объектно-
ориентированного моделирования. MSF по сравнению с RUP в наиболее
значительной степени направлена на создания бизнес-приложений компаний.
Extreme Programming (далее XP) – это стандарт, который отражает
экстремальное программирование, которое на данный момент является одним из
самых новых среди исследуемых нами методологий, сформировалось в 1996
году. Во главе методологии стоит слаженная командная работа, эффектная
коммуникация непосредственно между заказчиком программы и исполнителем в
течение всего времени проекта по разработке ИС, а разработка проводится
непосредственно с применением последовательно дорабатываемых различных
взаимодополняющих прототипов [3, c. 183].
Итак, главными критериями для выбора стандарта ЖЦ будут являться:
51
критерий актуальности и современности применяемых методик
контроля необходимой разработки;
критерий разработки с применением итерационного режима с
дальнейшей возможностью контролировать затем риски;
критерий выполнения необходимого проекта на определенных
контролируемых точках, полное отсутствие каких либо других дополнительных
требований к моделированию необходимого процесса разработки и также
внедрения.
Подытоживая сказанное об описании стандартов, можно сделать вывод,
что из них являются 4 стандарта: MSF, RUP, COBIT, XP .
Такой стандарт как COBIT нам для разработки не подходит, так как
главной его целью применения «является использование аудита и стратегии
поэтапного планирования ИС и IT инфраструктуры в целом».
Такой стандарт как XP также нам не годиться, так как он не имеет
полноценно разработанных этапов жизненного цикла, таких как выбор
концепции, поэтапное планирование, дальнейшая разработка, постепенная
стабилизация и наконец, процесс внедрения.
Отсюда следует, что перед нашим выбором стоит Rup и MSF. Оба данных
стандарта являются довольно молодыми и также поддерживающими все
новейшие технологии продуктивной разработки, а также и контроля их
дальнейшего выполнения [1, c. 175].
Rational Unified Process – есть отлично созданным решением для средних
по размерам коллективов разработчиков, которые работают с использованием
только продуктов, а также и технологий фирмы Rational. Поддержка разработки
системы, а также и самой системы отражается методикой RUP, но эта
технология в большей степени достаточно сильным образом направлена на
внутри компании различные инструментальные средства.
Что касаемо Extreme Programming, то эта концепция хорошо нам подходит
для проектных групп небольшого размера и для не великих систем с часто
преобразуемыми с течением времени работы требованиями. Главная проблема
XP – это дальнейшее сопровождение программы. В следствие частой текучки
кадров в коллективе разработчиков программ большая часть проектной
52
информации может быть с течение времени утеряно бесследно из-за
практически в итоге отсутствующей документации по определенному проекту.
Что касаемо Microsoft Solutions Framework, то эта концепция является
особо сбалансированной технологией, которая ориентирована на проектные
группы малых и средних размеров. MSF не делает вообще ограничений на
применяемый инструментарий и имеет также рекомендации довольно общего
характера. Но, данные рекомендации возможно использовать для создания
определенного процесса, соответствующего надобностям группы разработчиков.
Наш проект является по размерам небольшим, поэтому включает в себя 1-
го человека.
Помимо этого главным преимуществом MSF – это ее итерационная
модель с одномоментными уточняющими вехами (это является аналогом
каскадной модели). Поэтому, применение MSF попыталась вобрать в себя как
каскадную, так и итерационную модель дальнейшей разработки, а также и
внедрения ПО.
По рассмотренным нами ранее преимуществам, нами был избран стандарт
MSF как особо гибкий и наиболее удобный для последующей реализации моего
выбранного проекта.
Главным из преимуществ данного стандарта есть возможность такая, как
управлять параллельно и проектом разработкой нашего приложения, а также и
внедрением инфраструктуры.
Подводя итог, можно сказать, что в идеологии MSF имеются пять стадий
жизненного цикла ИС, которые в концепции MSF именуются фазами. Первым из
них является фаза выработки концепции [21, c. 173].
Цель этой фазы в создании и сплоченности проектной группы на базе
договоренности единого цельного видения. Проектная группа разработчиков
должна точно видеть, что данная группа хочет осуществить для заказчика и
определить свою цель. Заказчиком в нашем случае выступает ООО «Джет» г.
Гродно.
Вот какие задачи намечаются при фазе выработки концепций. Управление
проектируемым продуктом регулирует концептуальный и логический дизайн;
функциональная спецификация; а также и сводный план и сводный календарный
53
график данного проекта; бюджет. Кластер данного управления программой
намечает цели дизайна, концепцию решения, структуру данного проекта.
Кластер разработка в целом отвечает за оценку технологий; логический, а также
и физический дизайн проекта; план и календарный график разработки проекта;
смета разработки.
Кластер удовлетворения потребителя рассматривает сценарии/примеры
использования, пользовательские требования потребителя, требования
локализации, а также и общедоступности; пользовательская потребителя
документация/план обучения/график тестирования удобства эксплуатации;
обучение.
Кластер тестирования осуществляет оценку дизайна; необходимые
требования тестирования; план, а также и календарный график тестирования.
Кластер управление выпуском осуществляет функции оценки дизайна;
требования по эксплуатации; план и календарный график осуществления
пилотного и окончательного внедрения программы. В рамках реализации и
внедрения моего проекта своими силами и при помощи консультаций у
сотрудников ООО «Джет» г. Гродно была разработана базы данных «Прием
заявок на ремонт и модернизацию ПК».
Сам процесс проектирования базы данных «Прием заявок на ремонт и
модернизацию ПК» – это системный способ постепенного продвижения от
абстрактных концепций к конкретным техническим деталям в данной
программе.
Отмети также, что результатами фазы планирования работы по
проектированию базы данных «Прием заявок на ремонт и модернизацию ПК»
являются: функциональная спецификация. Рассмотрение предполагаемых
рисков, а также сводный план и сводный календарный график проекта «Прием
заявок на ремонт и модернизацию ПК», развернутые среды разработки и
тестирования. От меня на этом этапе необходим обзор и выбор языка
программирования, на котором в дальнейшем будет выполнено решение,
календарный план по срокам, а также и графикам разработки. На этом этапе
просчитывается планирование всей необходимой архитектуры ИС, работу
пользователей фирмы ООО «Джет» г. Гродно в будущей системе.
54
Дальнейшим этапом идет фаза разработки. На данной фазе разработки
делается акцент на создании компонента решения (вбирая в себя как
документацию, так и собственно программный код). Но определенная часть
данной работы может осуществляться также на фазе стабилизации в
дальнейшем, если данная нужда необходима в процессе тестирования базы
данных «Прием заявок на ремонт и модернизацию ПК». Эта фаза также
включает в себя разработку инфраструктуры программы.
Необходимо также обратить особое внимание на то, что активность
проектной команды на этом этапе не ограничена только написанием
программистами кода программы – все ролевые кластеры принимают
деятельное участие в создании, а также и тестировании решения.
Дальнейшим этапом жизненного цикла идет фаза стабилизации.
В течение данной фазы стабилизации происходит тестирование
разработанного нами решения. При этом внимание направлено на его
эксплуатацию в реалистичной модели производственной среды ООО «Джет» г.
Гродно. Осуществляется устранение выявленных ошибок, а также дальнейшая
подготовка решения к выпуску для эксплуатации в ООО «Джет» г. Гродно.
Нельзя предугадать, сколько ошибок будет выявлено и как много времени
в дальнейшем необходимо будет для устранения неполадок в программе. Но
имеются 2-ва статистических признака, которые помогают оценить уровень
стабилизации решения. Это точка конвергенции. В данной точке конвергенции
становится существенно виден ощутимый прогресс в дальнейшем устранении
ошибок, то есть скорость дальнейшего устранения ошибок начинает обгонять
скорость их обнаружения в программе. Так, как число найденных, но не
исправленных ошибок может существенно варьироваться даже и после того, как
оно начало со временем убывать, конвергенция может восприниматься скорее
всего как тенденция, нежели как определенный момент во времени. Вслед за
этим число активных ошибок должно постепенно уменьшаться, вплотную до
точки достижения нуля. Точка конвергенции дает проектной группе
возможность разобраться, что процесс тестирования близится к завершению.
Последующим этапом будет фаза внедрения.
55
В течение данной фазы происходит внедрение технологии и компоненты
решения, стабилизируется внедренное решение, происходит передача работы
персоналу ООО «Джет» г. Гродно, который будет осуществлять поддержку и
сопровождение программы, а также и получение со стороны заказчика конечное
одобрение результатов заданного проекта. По окончанию внедрения проекта я
делаю анализ проделанной работы и удовлетворенности заказчика программы.
Параллельная стратегия – это когда синхронно работает старая (ручная) и
новая система – база данных «Прием заявок на ремонт и модернизацию ПК», и
их выходные документы в итоге сравниваются. Если они согласуются
продолжительное время, происходит в дальнейшем полный переход на новую
систему – базу данных «Прием заявок на ремонт и модернизацию ПК».
В данном проекте будет избрана стратегия «Пилотный проект». Мы будем
осуществлять полный переход к автоматизированной системе – базе данных
«Прием заявок на ремонт и модернизацию ПК» для процессов по приему заявок
на ремонт и модернизацию ПК в ООО «Джет» г. Гродно.
Данный подход не вносит изменений в работу всей ИС ООО «Джет» г.
Гродно, а лишь автоматизирует определенную рутинную часть. Надежность
этого внедрения заключена в четком соответствием порядка регистрации и
обработки заявки на ремонт и модернизацию ПК в ООО «Джет» г. Гродно.
В дальнейшем наступает этап эксплуатации разработанного программного
продукта. В связи с написанной инструкцией к применению, работу данной базы
данных «Прием заявок на ремонт и модернизацию ПК» в ООО «Джет» г. Гродно
необходимо отслеживать работу данной программы каждый рабочий день.
Для осуществления данного проекта была нами предложена спиральная
модель жизненного цикла (рис. 2.1), которая делает упор на начальные этапы
жизненного цикла: анализ и проектирование.
На данных этапах течение технических решений подвергается проверке
путем создания прототипов. Каждый виток спирали сопоставим созданию
фрагмента или версии базы данных «Прием заявок на ремонт и модернизацию
ПК» в ООО «Джет» г. Гродно, на нем уточняются цели и характеристики
данного проекта, определяется также его качество и планируются работы
последующего витка спирали. Таким образом, углубляются и постепенно
56
конкретизируются детали данного проекта и в результате выбирается в конце
обоснованный вариант, который доводится в дальнейшем до реализации в ООО
«Джет» г. Гродно.
Рисунок 2.1. Спиральная модель жизненного цикла ИС [17, c. 113]
Отметим основную проблему спирального цикла – это определение
момента времени перехода на последующий этап. Для ее решения нужно ввести
временные ограничения на фактически каждый из этапов жизненного цикла.
Данный переход осуществляется в соответствии с планом, даже если не вся
запланированная работа по программному продукту закончена.
Наиболее оптимальной считаю спиральную модель, потому, что в ней
учитываются все недостатки, которые имеются в каскадной и задачной модели.
В рамках последующей доработки уже существующей ИС часто появляются
новые замечания от пользователей фирмы, которые можно реализовать на
проходе нового витка в спиральной модели.
2.2.2. Характеристика нормативно-справочной, входной и
оперативной информации
Входной информацией для проектируемой системы базы данных «Прием
заявок на ремонт и модернизацию ПК» в ООО «Джет» г. Гродно являются
заявки клиентов на ремонт и модернизацию ПК, сведения о сотрудниках
предприятия, содержащиеся в штатном расписании, сведения о кабинетах