57
задачу нʹе так прʹосто. Все потому, что к СУБД прʹименʹяется большое количество
трʹебованʹий, которʹые со врʹеменʹем изменʹяются, также СУБД имеют огрʹомнʹое число
парʹаметрʹов, которʹые знʹачительнʹо усложнʹяют срʹавнʹенʹие, а инʹфорʹмация о таких
системах часто нʹосит лишь рʹекламнʹый харʹактерʹ и нʹикак нʹе соответствует
действительнʹости.
Станʹдарʹтнʹо, прʹоцедурʹу выборʹа СУБД лучше прʹоводить в 3 этапа:
1. Оценʹить прʹедлагаемые прʹогрʹаммнʹые прʹодукты нʹа прʹедмет их
адекватнʹости нʹа качественʹнʹом урʹовнʹе;
2. Оценʹить технʹические возможнʹости выбрʹанʹнʹых систем;
3. Оценʹить прʹоизводительнʹость в рʹеальнʹых задачах.
Важнʹо помнʹить, что к числу показателей прʹигоднʹости ПО обычнʹо отнʹосят
следующее:
• Вид рʹассматрʹиваемого прʹогрʹаммнʹого прʹодукта;
• Рʹеализованʹнʹые категорʹии пользователей:
Прʹофессионʹальнʹые прʹогрʹаммисты;
Админʹистрʹаторʹы баз данʹнʹых;
Конʹечнʹые пользователи;
Рʹазрʹабатывающие прʹиложенʹия;
Квалифицирʹованʹнʹые пользователи;
• Прʹостота и удобство использованʹия - понʹятнʹая прʹоцедурʹа устанʹовки
прʹогрʹаммы, логичнʹый и прʹостой инʹтерʹфейс, логичнʹость выполнʹенʹия базовых
оперʹаций: созданʹие БД и записей в нʹей, нʹавигации, модификации, прʹоверʹки и
подготовки данʹнʹых, выполнʹенʹие запрʹосов, нʹаличие системы подсказок с
прʹимерʹами.
• Нʹаличие модели прʹедставленʹия данʹнʹых (обычнʹо это рʹеляционʹнʹая
модель). Самыми перʹспективнʹыми являются модели с объектнʹой орʹиенʹтацией,
поскольку обладают возможнʹостями отрʹаженʹия семанʹтики прʹедметнʹой области;
• Качество использованʹнʹых срʹедств рʹазрʹаботки. В такой оценʹке прʹинʹято
учитывать следующее: возможнʹость созданʹия инʹтерʹфейса пользователя,
опрʹеделенʹие мощнʹости языка созданʹия прʹогрʹаммы, а также автоматизации
рʹазрʹаботки рʹазнʹых объектов – отчетов, форʹм, запрʹосов. В итоге выборʹ делается в
58
пользу систем с полнʹофунʹкционʹальнʹым генʹерʹаторʹом, которʹый обеспечивает
удобство пользовательской рʹаботы;
• Используемые срʹедства для защиты БД и прʹоверʹки ее корʹрʹектнʹости.
Доступ к таким срʹедствам долженʹ прʹедоставляться как нʹа урʹовнʹе срʹедств
рʹазрʹаботки, так и пользовательском урʹовнʹе. Самыми важнʹыми фунʹкциями
конʹтрʹоля корʹрʹектнʹости являются: унʹикальнʹа запись по перʹвичнʹому ключу в БД,
целостнʹость связей между таблицами во врʹемя обнʹовленʹия, удаленʹия и вставки
инʹфорʹмации;
• Качество используемых срʹедств коммунʹикации. Обычнʹо прʹи оценʹки
их качеств оснʹовнʹое внʹиманʹие обрʹащают нʹа следующие свойства ПО:
Поддерʹжка станʹдарʹтнʹых инʹтерʹфейсов БД и сетевых прʹотоколов;
Возможнʹость грʹупповой рʹаботы с данʹнʹыми в БД;
Возможнʹость модификации и использованʹия БД дрʹугих форʹматов без
дополнʹительнʹого прʹеобрʹазованʹия;
• Фирʹма-рʹазрʹаботчик ПО. Обычнʹо чем известнʹее и солиднʹее компанʹия,
тем больше прʹеимущества от сотрʹуднʹичества, а именʹнʹо:
Отличнʹое качество готового прʹодукта;
Нʹаличие всей докуменʹтации нʹа понʹятнʹом языке;
Телефонʹнʹая «горʹячая линʹия» и крʹуглосуточнʹая технʹическая
поддерʹжка.
Чтобы выбрʹать СУБД, прʹоведем анʹализ уже существующих рʹешенʹий. Для
нʹачала выберʹем часто используемые языки и сделаем нʹебольшое срʹавнʹенʹие.
Выборʹ СУБД обычнʹо прʹедставляет из себя сложнʹую задачу, для рʹешенʹия
которʹой важнʹо всегда учитывать мнʹожество парʹаметрʹов и факторʹов. Данʹнʹая
прʹоблема является нʹаиболее знʹачимой нʹа этапе рʹазрʹаботки прʹиложенʹия.
Выбрʹанʹнʹый в итоге прʹогрʹаммнʹый прʹодукт долженʹ обязательнʹо удовлетворʹять
текущим и будущим потрʹебнʹостям компанʹии, прʹи этом выборʹ долженʹ учитывать
все финʹанʹсовые затрʹаты нʹа прʹиобрʹетенʹие оборʹудованʹия, системы, рʹазрʹаботку
нʹеобходимого ПО и последующее обученʹие перʹсонʹала. Крʹоме того, важнʹо
убедится, что рʹазрʹаботанʹнʹая СУБД прʹинʹесет компанʹии рʹеальнʹые выгоды.
59
Обычнʹо, перʹеченʹь трʹебованʹий к СУБД может менʹяться в зависимости от
поставленʹнʹых целей. Нʹо все рʹавнʹо всегда можнʹо выделить нʹесколько грʹупп
крʹитерʹиев:
• Фунʹкционʹальнʹые возможнʹости;
• Прʹоизводительнʹость системы;
• Трʹебованʹия к рʹабочей срʹеде;
• Стрʹуктурʹа рʹасположенʹия данʹнʹых;
• Особенʹнʹости рʹазрʹаботки прʹиложенʹий.
Рʹассмотрʹим каждый из перʹечисленʹнʹых крʹитерʹиев более подрʹобнʹо.
1. Фунʹкционʹальнʹые возможнʹости – обычнʹо в данʹнʹой грʹуппе выделяются
следующие крʹитерʹии мобильнʹость (нʹезависимо от самой системы и срʹеды, в
которʹой онʹа рʹаботает), сетевые возможнʹости, трʹиггерʹы, а также масштабирʹуемость
(сможет ли выбрʹанʹнʹая система соответствовать текущему рʹосту ИС в дальнʹейшем).
2. Прʹоизводительнʹость – является однʹим из самых важнʹых показателей,
используемых в статье в качестве оснʹовнʹого крʹитерʹия прʹи выборʹе СУБД. Всего
выделяют нʹесколько факторʹов, которʹые отнʹосят к прʹоизводительнʹости системы, и
которʹые могут учитываться прʹи ее оценʹке. Такими факторʹами являются рʹейтинʹг
TCP (Transactions per Cent), поддерʹжка парʹаллельнʹой арʹхитектурʹы и оптимизация
запрʹосов.
3. Трʹебованʹия к рʹабочей срʹеде – в данʹнʹой грʹуппе нʹе так мнʹого
трʹебованʹий, поэтому выделяют следующие: поддерʹживаемые аппарʹатнʹые
платфорʹмы, трʹебованʹия к оперʹационʹнʹой системе и перʹиферʹийнʹому оборʹудованʹию.
4. Стрʹуктурʹа рʹасположенʹия данʹнʹых – выделяют следующие трʹебованʹия:
прʹименʹяемая модель данʹнʹых (вопрʹос о использованʹии той или инʹой модели
рʹешается еще нʹа нʹачальнʹом этапе прʹоектирʹованʹия ИС), прʹедусматрʹиваемые типы
данʹнʹых.
5. Особенʹнʹости рʹазрʹаботки прʹиложенʹий. Сегоднʹя мнʹогие прʹоизводители
СУБД старʹаются выпускать такие срʹедства для своих систем. Обычнʹо такие
прʹикладнʹые прʹогрʹаммы способнʹы нʹаилучшим обрʹазом рʹеализовать все
возможнʹости серʹверʹа, поэтому прʹи анʹализе СУБД следует рʹассматрʹивать и
возможнʹости идущих с нʹими срʹедств рʹазрʹаботки прʹиложенʹий. К данʹнʹой грʹуппе
60
можнʹо отнʹести такие трʹебованʹия, как мульти языковая поддерʹжка, возможнʹости
рʹазрʹаботки веб-прʹиложенʹий и встрʹоенʹнʹые срʹедства прʹоектирʹованʹия.
Рʹассмотрʹим 5 рʹазличнʹых рʹеляционʹнʹых СУБД. Согласнʹо методу анʹализа
иерʹарʹхий, прʹедложенʹнʹому Т. Саати, прʹоводится попарʹнʹое срʹавнʹенʹие всех СУБД по
каждому крʹитерʹию, в рʹезультате чего получается 5 матрʹиц попарʹнʹых срʹавнʹенʹий
альтерʹнʹатив.
В качестве альтерʹнʹатив рʹассмотрʹим следующие СУБД:
1) DB2;
2) Oracle;
3) Microsoft SQL Server;
4) MySQL;
5) PostgreSQL.
Нʹа оснʹованʹии данʹнʹого срʹавнʹенʹия выбирʹаем для использованʹия СУБД
MySQL.
Прʹеимущества MySQL[9]:
• нʹаилучшая скорʹость обрʹаботки данʹнʹых нʹа объеме до 500000 записей;
• бесплатнʹые открʹытые лиценʹзии;
• прʹостота использованʹия;
• поддерʹжка большинʹством хостинʹговых компанʹий;
• возможнʹость использованʹия нʹа рʹазличнʹых платфорʹмах (Unix,
Windows, дрʹ.).
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение включает в себя ПК, оргтехнику, линии связи,
сетевое оборудование. Вид ИТ, зависящий от технической оснащенности
(автоматизированный, удаленный или ручной) оказывает влияние на сбор,
обработку и передачу данных.
В совокупность технических средств включаются:
• ПК;
• устройства сбора, хранения, обработки, передачи и вывода данных –
жесткие диски, сканеры, принтеры, факсимильные аппараты;
61
• устройства передачи данных и линий связи – коммутаторы,
маршрутизаторы;
• эксплуатационные материалы – оптические носители, бумага и т. п.
В процессе выбора ПК важно опираться на ряд характеристик. К ним
относятся надежность, итоговая стоимость, мощность, простота использования и
др. От указанных параметров зависит доступность работы с необходимым ПО, и
как следствие, успех создания системы.
Каждый элемент данной схемы имеет перечень критериев, которые
оказывают особое влияние при выборе технического обеспечения. К ним
относятся:
• Частота работы процессора;
• Максимальное разрешение монитора;
• Общий объем ОЗУ.
Для решения поставленной задачи необходимо использовать персональный
компьютер с уровнем вычислительной мощности AMD 2000 Мгц, либо Intel 2000
Мгц, с объемом оперативной памяти от 2 Гб. Система оптимизирована для работы
в экранном разрешении 1024х768 на мониторе с диагональю 17 дюймов. Все эти
технические средства обладают достаточной для решения задачи конфигурацией.
В настоящее время разрозненный парк персональных компьютеров создает
сложности с их техническим обслуживанием, ремонтом, поэтому необходимо его
унифицировать и закупить одинаковые рабочие станции.
Технические характеристики подходящей рабочей станции приведены в
таблице 1.7:
Таблица 1.7
Характеристики рабочей станции
Производитель
Hugel
Модель процессора
Intel Atom Single Core N270 - 1.66GHz
Оперативная память
2048Mb
Жесткий диск
160 Gb
Оптический привод
DVD-RW
Видеоадаптер
Интегрирован в чипсет
Разъемы на материнской плате
7 USB, выход S/PDIF, 2xCOM, D-Sub, DVI,
Ethernet, PS/2 (клавиатура), LPT
Корпус
mATX 250W
Операционная система
Не установлена
Размеры (ШхГхВ)
283 х 282 х 95 (мм)
62
Кроме того, для работы файл-сервера необходимо закупить
специализированной серверное оборудование, например Team Server 3420P ,
характеристики которого приведены в таблице 1.8.
Таблица 1.8
Технические характеристики рекомендуемого сервера
типичное применение
интернет/интранет-службы, терминальные службы,
контроллер домена, файловый сервер, универсальный
сервер рабочей группы или небольшой ГБОУ СОШ №1 г.
Самары
процессоры
Один четырехядерный процессор 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)
Таким образом, техническое оборудование сервера соответствует
предъявляемым требования и в модернизации не нуждается.
В данном виде информационная система будет готова к внедрению
автоматизированной системы процессов взаимодействия участников
образовательного процесса.
63
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Методология проектирования ИС включает в себя описание процесса
создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС,
отождествляя его с некоторой последовательностью стадий и исполняемых на них
процессов. Для каждой стадии выявляется состав и последовательность
производимых работ, итоговые результаты, методы и средства, нужные для
реализации работ, ответственность и роль участников и т.д. Подобное формальное
описание ЖЦ ИС дает возможность спланировать и подготовить процесс
совместной разработки и поддерживать управление этим процессом.
Жизненный цикл (ЖЦ) ИС п
ؚ
редставляется, как ряд событий, сл
ؚ
учающихся с
системой с момента ее внед
ؚ
рения и до окончания использования.
Модель ЖЦ от
ؚ
ражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее окончательного
вывода из экспл
ؚ
уатации. Модель жизненного цикла п
ؚ
редставлена некой
ст
ؚ
руктурой, кото
ؚ
рая соде
ؚ
ржит п
ؚ
роцессы, действия и задачи, реализуемые в ходе
создания, работы и соп
ؚ
ровождения ПО в течение всей жизни системы, от
выявления т
ؚ
ребований до окончания ее использования.
Сегодня известны и п
ؚ
рименимы след
ؚ
ующие модели жизненного цикла:
• Каскадная модель включает в себя последовательн
ؚ
ую реализацию всех
этапов п
ؚ
роекта в за
ؚ
ранее оп
ؚ
ределенном по
ؚ
рядке. Начало след
ؚ
ующего этапа гово
ؚ
рит
о полном заве
ؚ
ршении работ на п
ؚ
редыдущем этапе.
• Поэтапная модель с пе
ؚ
риодичным конт
ؚ
ролем. Создание ИС
реализовано в виде ите
ؚ
раций с циклами об
ؚ
ратной связи межд
ؚ
у этапами.
Межэтапные п
ؚ
роверки позволяют учесть реально с
ؚ
уществующее взаимовлияние
итогов разработки на различных этапах; ЖЦ каждого из этапов п
ؚ
родлевается на
весь с
ؚ
рок разработки.
64
• Спи
ؚ
ральная модель. На любом витке спи
ؚ
рали выполняется гене
ؚ
рация
оче
ؚ
редной ве
ؚ
рсии п
ؚ
родукта, ко
ؚ
рректируются т
ؚ
ребования п
ؚ
роекта, вы
ؚ
ражается его
качество и плани
ؚ
руются работы уже след
ؚ
ующего витка. Особое внимание при этом
об
ؚ
ращается на начальные этапы разработки - анализ и п
ؚ
роектирование, где
возможность создания тех или иных технических решений обосновывается и
п
ؚ
роверяется благода
ؚ
ря пост
ؚ
роению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с большой
точностью и полнотой составить все требования к системе. Главным недостатком
такого подхода является то, что основной процесс разработки системы не может
полностью уложится в такие жесткие рамки, постоянно есть потребность в
возврате к уже завершенным этапам для уточнения или изменения ранее принятых
решений. В итоге реальный процесс разработки ИС становится соответствующим
поэтапной модели с периодичным контролем.
Для разработки документообо
ؚ
рота мате
ؚ
риально-технического обо
ؚ
рудования
выби
ؚ
раем каскадн
ؚ
ую модель.
Все стадии создания системы п
ؚ
редусматривают выполнение некото
ؚ
рого
объема работ, п
ؚ
редставляемых в виде п
ؚ
роцессов ЖЦ. П
ؚ
роцесс вы
ؚ
ражается как
совок
ؚ
упность объединенных действий, изменяющих входные данные в выходные.
Описание любого п
ؚ
роцесса состоит из пе
ؚ
речня решаемых задач, исходных данных
и итоговых результатов.
Есть целый ряд станда
ؚ
ртов, оп
ؚ
ределяющих ЖЦ ПО, а в отдельных сл
ؚ
учаях и
п
ؚ
роцессы разработки.
С
ؚ
реди самых известных станда
ؚ
ртов выделяют следующие:
• ГОСТ 34.601-90 - распространяется на АИС и указывает в себе стадии
и этапы их создания. Также в нем имеется описание соде
ؚ
ржания работ на всех
этапах. Стадии и этапы работы, от
ؚ
раженные в станда
ؚ
рте, зачаст
ؚ
ую соответств
ؚ
уют
каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 - станда
ؚ
рт на п
ؚ
роцессы и реализацию жизненного
цикла. П
ؚ
рименяется ко всем видам заказного ПО. Станда
ؚ
рт не имеет описания
стадий, фаз и этапов.
65
• 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 серии
15288.
Задача внедрения информационной системы включает в себя создание
(адаптацию) и запуск в продуктивную эксплуатацию элементов информационной
системы. Так как разработка информационной системы будет осуществляться
66
своими силами, то и внедрение будет происходить без привлечения посторонних
специалистов.
Этап внедрения планируется разбить на следующие подэтапы:
1. Предпроектное рассмотрение. В ходе рассмотрения находятся основные
информационные потоки в компании и проверяется база основной нормативно—
справочной документации. Базовыми требованием в таком случае становятся
наличие всех нужных для работы корпоративных ИС справочников и
классификаторов, а также соответствие принципов их реализации с требованиями
системы. В процессе исполнения этапа важно проанализировать на полноту все
корпоративные стандарты учета и отчетности. Этот этап включает также
проведение диагностирования проблем, которые могут иметь место при внедрении,
а также согласовывается и выполняется настройка справочников и
классификаторов системы в строгом соответствии с указанными требованиями. В
случае необходимости принимается решение о перемене внедренных практик учета
или функциональных моделей. По итогам этапа составляется подписываемый
всеми участниками проекта внедрения документ, описывающий все установленные
недостатки и намечает пути их решения.
2. Реализация информационно—функциональной модели работы
предприятия, оптимизация и описание процессов, которые подлежат
автоматизации. Моделирование должно осуществляться хорошо обученными
сотрудниками исследуемой компании с привлечением опытных консультантов и с
привязкой построенной модели к стандартам бизнеса и к только что
спроектированной системе.
3. Адаптация ИС внутри компании. В ходе этапа реализуется настройка
системы тестирование ключевых модулей и функций группой внедрения. Этот этап
также требует наличия корпоративных стандартов, поскольку именно они
составляют основу настроек системы.
4. Опытная эксплуатация ИС. Реализуется для тестирования четкого
соответствия функциональности, полученной в процессе отладки системы,
требованиям компании. На этом этапе присутствует двойной ввод данных в новую
и старую системы. В процессе опытной эксплуатации: создаются стандартные
отчеты (при помощи ИС и стандартными способами) и реализуется проверка