48
существует всего одна информационная конструкция, формализующая табличное
представление данных.
2. Наличие теоретически обоснованных методов нормализации
отношений позволяет получать базу данных с заданными характеристиками.
3. Независимость данных заключается в том, что при необходимости
внесения изменений в структуру реляционной базы данных, требуется внесение
минимальных изменений.
Помимо перечисленных достоинств, в организации уже используется
реляционная СУБД. Поэтому, с целью минимизации конфликтов в процессе
интеграции, для разработки информационной системы будет использована
реляционная база данных. Для управления реляционной базой данных
используется реляционная СУБД. На рынке широко представлены как
коммерческие, так и бесплатные СУБД. Наиболее востребованными на рынке
являются следующие СУБД:
Microsoft SQL Server;
PosgreSQL;
IBM DB2;
Oracle database.
СУБД IBM DB2 является кроссплатформенной, обеспечивает стабильную
работу базы данных. Недостатками системы являются высокая стоимость и
низкая производительность. СУБД Microsoft SQL Server обладает большим
пакетом инструментов, стабильностью работы и низкими затратами на
администрирование. Недостаток системы заключается в том, что она работает
только на платформе Windows [14].
СУБД Oracle обладает высокой производительностью, легкостью
интегрирования приложений и устойчивостью к большим потокам данных.
Недостатком является высокая стоимость, необходимость приобретения мощного
оборудования и персонала для поддержки СУБД. Ввиду перечисленных свойств
реляционных СУБД был сделан выбор в пользу СУБД Oracle, поскольку эта СУБД
уже используется в организации для функционирования системы «1С:
Предприятие».
Для разработки информационной системы будет использован
49
объектноориентированный подход, поскольку он позволяет осуществлять
конструирование из компонентов, обладающих простыми инструментами, что
дает возможность абстрагироваться от деталей реализации. При этом данные и
операции вместе образуют определенную сущность, и они не «размазываются» по
всей программе, как это нередко бывает в случае процедурного
программирования. Использование локализации программного кода и данных
улучшает наглядность и удобство сопровождения программного обеспечения.
В качестве языка программирования был выбран язык программирования
c#. Который поддерживает объектно-ориентированный подход и обладает
множеством встроенных библиотек.
Разработка информационной системы будет осуществляться в среде
программирования MS Visual Studio, которая является бесплатным
инструментом, поддерживающим выбранный язык программирования.
Проектируемая система должна функционировать в среде операционной
системы Windows 10, поскольку эта операционная система используется для
работы сотрудников организации.
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение – совокупность аппаратных средств, с помощью
которых осуществляется процесс функционирования АРМ [27]. Таким
обеспечением являются устройства отображения, обработки информации,
управления и передачи данных. Каждое из них характеризуется составом
элементов и структурой. Выбор типов элементов, их количества и взаимосвязей
связан с решением задачи разработки программного обеспечения (т.е.
информационной системы в нашем случае) [6].
Типы технических средств не могут выбираться отдельно друг от друга –
должна быть обеспечена их совместимость по входной и выходной информации
и по физическим параметрам сигналов. Для базового набора компонентов ПЭВМ
характерны [25, 20]:
системный блок, содержащий основную аппаратную часть
(микропроцессоры, контроллеры ввода-вывода, интерфейсы, ПЗУ,
ОЗУ, сетевые адаптеры);
внешние запоминающие устройства;
50
дисплей для отображения текстовой и графической информации;
клавиатура, предназначенная для ввода управляющих команд и
данных;
печатающее устройство (принтер), обеспечивающий получение
твердых печатных копий.
Для разработки данной АРМ необходимость приобретения
дополнительных технических средств отсутствует.
Обеспечение техническое – это объединение технических средств,
компьютерной техники, а также средств передачи информации с одного
компьютера на другие, используемых в автоматизированных системах
управления и в информационных системах. Для работы программы по приему
заявок на ремонт и модернизацию ПК достаточно тех компьютеров, которые
имеются в наличие у От АО ЮГУ ЦБ РФ.
Технические характеристики ПК От АО ЮГУ ЦБ РФ:
Процессор: 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 рабочих
станций, накопители, а также и другое компьютерное оборудование;
аварийные планы по обеспечению бесперебойной работы аппаратуры
(главным образом – сервера) и баз данных в условиях чрезвычайных
обстоятельств.
операционные и управляющие системы, утилиты и офисные
программные системы;
Все это в полой мере подходит для полного
функционирования
разрабатываемой базы данных «Прием заявок на ремонт и модернизацию ПК».
51
II Проектная часть
2.1.Разработка проекта автоматизации
2.1.1.Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла – это структура, содержащая процессы,
действия, а также задачи, которые происходят в процессе конкретной разработки,
функционирования и дальнейшее сопровождения разработанного программного
продукта в дальнейшем в течение всей жизни данной системы, от определения
определенных требований и затем до стадии завершения ее дальнейшего
применения.
На данном этапе развития имеются определенное количество моделей и
стандартов, в разной степени определяющих регламент жизненного цикла,
большую часть из них относят к заказному ПО (программному обеспеченью).
Так, например, ГОСТ 34.601-90 относят на автоматизированные системы
и он определяет стадии и этапы их создания. Также, в данном стандарте имеется
подробное описание содержания работ на каждом этапе. Стадии и этапы работы,
отраженные в данном стандарте, в довольно большой степени отражают
каскадную модель жизненного цикла.
Рекомендуемый состав стадий жизненного цикла программного
обеспечения регламентируют стандарты ISO, которые описывают
технологические процессы. Стандарт ГОСТ Р ИСО/МЭК 12207-2010
«Информационная технология. Системная и программная инженерия. Процессы
жизненного цикла программных средств» определяет общую структуру
жизненного цикла ПО в виде трехуровневой модели, элементами которой
являются процессы, виды деятельности, задачи [8]. Процессы объединены в
четыре группы: основные процессы, поддерживающие процессы,
организационные процессы, адаптация. Процессы состоят из отдельных видов
деятельности.
Стандарт ISO/IEC 15288:2015 «Разработка систем и программного
обеспечения – Процессы жизненного цикла систем» рассматривает программно
аппаратную систему как единое целое [6]. Стандарт предлагает рассматривать
структуру жизненного цикла ПО как набор групп процессов, каждый из которых
описывается набором результатов, и каждый из результатов достигается при
52
помощи набора различных видов деятельности. Эффективность разработки ПО в
целом зависит от точности и корректности формулировки требований к
программному продукту.
Custom Development Method (далее CDM) – это стандарт, который
отражает разработку различных прикладных информационных систем под заказ
потребителей данных систем – конкретный материал, детальный до уровня
различных заготовок проектных документов, направленных на применение в
проектах с использованием Oracle. Мера адаптации CDM имеет ограничение 3-
мя моделями жизненного цикла: «классическая» (заложены все необходимые
работы/задачи, а также этапы), «быстрая разработка» (Fast Track), «облегченный
подход», он рекомендуется, если в случае небольших проектов и возможности
довольно быстро прототипировать необходимые приложения.
Rational Unified Process (далее RUP) – это стандарт, который отражает
итеративную модель разработки проекта, которая включает 4-ре необходимые
фазы: начало, исследование, построение и затем внедрение. Любая из этих фаз
может быть при необходимости разбита на определенные этапы (итерации), в
использовании которых выдается версия либо для внутреннего, либо для
внешнего применения. Проход через 4-ре главные фазы именуется циклом
разработки, причем каждый цикл заканчивается генерацией полученной версии
проектируемой системы. Если после всего этого данная работа над заданным
проектом не завершается, то сделанный продукт в дальнейшем продолжают
развивать и заново проходя те же фазы разработки. Сущность работы в заданных
рамках RUP – это разработка и дальнейшее сопровождение моделей, а не простых
стандартных бумажных документов, посему данный процесс непосредственно
привязан к применению определенных средств моделирования (UML), а так же
определенной технологии при проектировании и дальнейшей разработки
(например, объектно-ориентированный анализ, object-oriented analysis, OOA,
объектно-ориентированное программирование, object-oriented programming,
OOP).
Microsoft Solution Framework (далее MSF) – это стандарт, который сходен
с RUP, он так же имеет 4-ре фазы: анализ, проектирование, разработка,
стабилизация, является итерационной, задает применение объектно-
53
ориентированного моделирования. MSF по сравнению с RUP в наиболее
значительной степени направлена на создания бизнес-приложений компаний.
Extreme Programming (далее XP) – это стандарт, который отражает
экстремальное программирование, которое на данный момент является одним из
самых новых среди исследуемых нами методологий, сформировалось в 1996 году.
Во главе методологии стоит слаженная командная работа, эффектная
коммуникация непосредственно между заказчиком программы и исполнителем в
течение всего времени проекта по разработке ИС, а разработка проводится
непосредственно с применением последовательно дорабатываемых различных
взаимодополняющих прототипов [3, c. 183].
Итак, главными критериями для выбора стандарта ЖЦ будут являться:
критерий актуальности и современности применяемых методик контроля
необходимой разработки;
критерий разработки с применением итерационного режима с
дальнейшей возможностью контролировать затем риски;
критерий выполнения необходимого проекта на определенных
контролируемых точках, полное отсутствие каких либо других дополнительных
требований к моделированию необходимого процесса разработки и также
внедрения.
Подытоживая сказанное об описании стандартов, можно сделать вывод,
что из них являются 4 стандарта: MSF, RUP, COBIT, XP .
Такой стандарт как COBIT нам для разработки не подходит, так как
главной его целью применения «является использование аудита и стратегии
поэтапного планирования ИС и IT инфраструктуры в целом».
Такой стандарт как XP также нам не годиться, так как он не имеет
полноценно разработанных этапов жизненного цикла, таких как выбор
концепции, поэтапное планирование, дальнейшая разработка, постепенная
стабилизация и наконец, процесс внедрения.
Отсюда следует, что перед нашим выбором стоит Rup и MSF. Оба данных
стандарта являются довольно молодыми и также поддерживающими все
новейшие технологии продуктивной разработки, а также и контроля их
дальнейшего выполнения [1, c. 175].
54
Rational Unified Process – есть отлично созданным решением для средних
по размерам коллективов разработчиков, которые работают с использованием
только продуктов, а также и технологий фирмы Rational. Поддержка разработки
системы, а также и самой системы отражается методикой RUP, но эта технология
в большей степени достаточно сильным образом направлена на внутри компании
различные инструментальные средства.
Что касаемо Extreme Programming, то эта концепция хорошо нам подходит
для проектных групп небольшого размера и для не великих систем с часто
преобразуемыми с течением времени работы требованиями. Главная проблема XP
– это дальнейшее сопровождение программы. В следствие частой текучки кадров
в коллективе разработчиков программ большая часть проектной информации
может быть с течение времени утеряно бесследно из-за практически в итоге
отсутствующей документации по определенному проекту.
Что касаемо Microsoft Solutions Framework, то эта концепция является
особо сбалансированной технологией, которая ориентирована на проектные
группы малых и средних размеров. MSF не делает вообще ограничений на
применяемый инструментарий и имеет также рекомендации довольно общего
характера. Но, данные рекомендации возможно использовать для создания
определенного процесса, соответствующего надобностям группы разработчиков.
Наш проект является по размерам небольшим, поэтому включает в себя 1-го
человека.
Помимо этого главным преимуществом MSF – это ее итерационная
модель с одномоментными уточняющими вехами (это является аналогом
каскадной модели). Поэтому, применение MSF попыталась вобрать в себя как
каскадную, так и итерационную модель дальнейшей разработки, а также и
внедрения ПО.
По рассмотренным нами ранее преимуществам, нами был избран стандарт
MSF как особо гибкий и наиболее удобный для последующей реализации моего
выбранного проекта.
Главным из преимуществ данного стандарта есть возможность такая, как
управлять параллельно и проектом разработкой нашего приложения, а также и
внедрением инфраструктуры.
55
Подводя итог, можно сказать, что в идеологии MSF имеются пять стадий
жизненного цикла ИС, которые в концепции MSF именуются фазами. Первым из
них является фаза выработки концепции [21, c. 173].
Цель этой фазы в создании и сплоченности проектной группы на базе
договоренности единого цельного видения. Проектная группа разработчиков
должна точно видеть, что данная группа хочет осуществить для заказчика и
определить свою цель. Заказчиком в нашем случае выступает От АО ЮГУ ЦБ РФ.
Вот какие задачи намечаются при фазе выработки концепций. Управление
проектируемым продуктом регулирует концептуальный и логический дизайн;
функциональная спецификация; а также и сводный план и сводный календарный
график данного проекта; бюджет. Кластер данного управления программой
намечает цели дизайна, концепцию решения, структуру данного проекта. Кластер
разработка в целом отвечает за оценку технологий; логический, а также и
физический дизайн проекта; план и календарный график разработки проекта;
смета разработки.
Кластер удовлетворения потребителя рассматривает сценарии/примеры
использования, пользовательские требования потребителя, требования
локализации, а также и общедоступности; пользовательская потребителя
документация/план обучения/график тестирования удобства эксплуатации;
обучение.
Кластер тестирования осуществляет оценку дизайна; необходимые
требования тестирования; план, а также и календарный график тестирования.
Кластер управление выпуском осуществляет функции оценки дизайна;
требования по эксплуатации; план и календарный график осуществления
пилотного и окончательного внедрения программы. В рамках реализации и
внедрения моего проекта своими силами и при помощи консультаций у
сотрудников От АО ЮГУ ЦБ РФ была разработана базы данных «Прием заявок
на ремонт и модернизацию ПК».
Сам процесс проектирования базы данных «Прием заявок на ремонт и
модернизацию ПК» – это системный способ постепенного продвижения от
абстрактных концепций к конкретным техническим деталям в данной программе.
56
Отмети также, что результатами фазы планирования работы по
проектированию базы данных «Прием заявок на ремонт и модернизацию ПК»
являются: функциональная спецификация. Рассмотрение предполагаемых рисков,
а также сводный план и сводный календарный график проекта «Прием заявок на
ремонт и модернизацию ПК», развернутые среды разработки и тестирования. От
меня на этом этапе необходим обзор и выбор языка программирования, на
котором в дальнейшем будет выполнено решение, календарный план по срокам,
а также и графикам разработки. На этом этапе просчитывается планирование всей
необходимой архитектуры ИС, работу пользователей фирмы От АО ЮГУ ЦБ РФ
в будущей системе. Дальнейшим этапом идет фаза разработки. На данной фазе
разработки делается акцент на создании компонента решения (вбирая в себя как
документацию, так и собственно программный код). Но определенная часть
данной работы может осуществляться также на фазе стабилизации в дальнейшем,
если данная нужда необходима в процессе тестирования базы данных «Прием
заявок на ремонт и модернизацию ПК». Эта фаза также включает в себя
разработку инфраструктуры программы.
Необходимо также обратить особое внимание на то, что активность
проектной команды на этом этапе не ограничена только написанием
программистами кода программы – все ролевые кластеры принимают деятельное
участие в создании, а также и тестировании решения.
Дальнейшим этапом жизненного цикла идет фаза стабилизации.
В течение данной фазы стабилизации происходит тестирование
разработанного нами решения. При этом внимание направлено на его
эксплуатацию в реалистичной модели производственной среды От АО ЮГУ ЦБ
РФ. Осуществляется устранение выявленных ошибок, а также дальнейшая
подготовка решения к выпуску для эксплуатации в От АО ЮГУ ЦБ РФ.
Нельзя предугадать, сколько ошибок будет выявлено и как много времени
в дальнейшем необходимо будет для устранения неполадок в программе. Но
имеются 2-ва статистических признака, которые помогают оценить уровень
стабилизации решения. Это точка конвергенции. В данной точке конвергенции
становится существенно виден ощутимый прогресс в дальнейшем устранении
ошибок, то есть скорость дальнейшего устранения ошибок начинает обгонять
57
скорость их обнаружения в программе. Так, как число найденных, но не
исправленных ошибок может существенно варьироваться даже и после того, как
оно начало со временем убывать, конвергенция может восприниматься скорее
всего как тенденция, нежели как определенный момент во времени. Вслед за этим
число активных ошибок должно постепенно уменьшаться, вплотную до точки
достижения нуля. Точка конвергенции дает проектной группе возможность
разобраться, что процесс тестирования близится к завершению.
Последующим этапом будет фаза внедрения. В течение данной фазы
происходит внедрение технологии и компоненты решения, стабилизируется
внедренное решение, происходит передача работы персоналу От АО ЮГУ ЦБ РФ,
который будет осуществлять поддержку и сопровождение программы, а также и
получение со стороны заказчика конечное одобрение результатов заданного
проекта. По окончанию внедрения проекта я делаю анализ проделанной работы и
удовлетворенности заказчика программы.
Параллельная стратегия – это когда синхронно работает старая (ручная) и
новая система – база данных «Прием заявок на ремонт и модернизацию ПК», и их
выходные документы в итоге сравниваются. Если они согласуются
продолжительное время, происходит в дальнейшем полный переход на новую
систему – базу данных «Прием заявок на ремонт и модернизацию ПК».
В данном проекте будет избрана стратегия «Пилотный проект». Мы будем
осуществлять полный переход к автоматизированной системе – базе данных
«Прием заявок на ремонт и модернизацию ПК» для процессов по приему
заявок на ремонт и модернизацию ПК в От АО ЮГУ ЦБ РФ.
Данный подход не вносит изменений в работу всей ИС От АО ЮГУ ЦБ
РФ, а лишь автоматизирует определенную рутинную часть. Надежность этого
внедрения заключена в четком соответствием порядка регистрации и обработки
заявки на ремонт и модернизацию ПК в От АО ЮГУ ЦБ РФ.
В дальнейшем наступает этап эксплуатации разработанного
программного продукта. В связи с написанной инструкцией к применению,
работу данной базы данных «Прием заявок на ремонт и модернизацию ПК» в От
АО ЮГУ ЦБ РФ необходимо отслеживать работу данной программы каждый
рабочий день.