53
управлять базами данных при удобном доступе и эффективно управлять ходом
работы.
Обновленный конструктор макросов теперь упрощает значительно разработку
сложных логических выражений и делает это интуитивно понятным для любого
опытного разработчика, позволяет очень легко и быстро объединять данные и
повысить качество работы. Теперь непосредственно в разрабатываемые проекты
можно подключать данные веб-служб, а также SharePoint 2010 Business
Connectivity Services, появляется возможность для импорта данных из различных
внешних источников (Excel, Outlook, SQL Server и других приложений пакета
программ Microsoft) и создания связи с ними. При сборе или отправке данных по
электронной почте сервер теперь не понадобится.
Способы доступа к базам данных теперь выходят на качественно новый уровень,
благодаря интегрированию в Access приложения SharePoint Server 2010, что
отныне позволит размещать базы данных при помощи новой технологии веб-баз
данных. Эта функция будет очень кстати и для тех, кто занимается веб-
разработками, так как с помощью этого приложения опубликовать базу данных
на сайте не составит большого труда. Теперь удобнее будет использовать базы
данных совместно. Можно будет к ним не только обращаться, но и вносить
коррективы непосредственно через Интернет. А пользователи, у которых не
установлено приложение Access, все равно смогут открыть веб-формы или
отчеты через браузер. При этом вносимые изменения синхронизируются
автоматически. Access имеет характерный для всех приложений
MicrosoftWindows удобный графический интерфейс, ориентированный на
комфортную работу пользователя.
Проведем выбор СУБД методом экспертного оценивания. Мнение экспертов
оценивалось на информационном форуме, были привлечены ведущие
специалисты в своей области.
Необходимо выделить критерии оценки СУБД. Важность каждого из
представленных критериев была оценена экспертами по 100 бальной шкале.
Исходя из полученных данных, находится средний балл и коэффициент
относительной важности критерия. Результаты первого этапа экспертизы
представлены в таблице 1.6.
54
Таблица 1.6
Сравнение СУБД
Коэффициент относительной важности:
%100
баллСредний
К
. Величина
–
сумма усреднённых экспертных оценок первого этапа экспертизы. Результаты
второго этапа экспертизы представлены в таблице 1.7.
Таблица 1.7
Результаты второго этапа экспертизы
Наименование
критерия
Эксперт 1
Эксперт 2
Эксперт 3
Средний
балл по 100
бальной
шкале
Коэффициент
относительной
важности
Стоимость СУБД
85
90
79
85
13,5
Операционная
система
75
80
81
79
12,5
Простой
интерфейс
90
95
92
92
14,6
Широта
распространения
85
90
81
85
13,6
Качество
справочной
информации к
системе
95
90
85
90
14,4
Количество
пользователей
100
100
100
100
15,9
Простота
использования
95
100
96
97
15,5
Сумма
628
100,0%
Функция
Коэффициент
относительной
важности
InterBase
Paradox
Microsoft
Access
Стоимость СУБД
13,5
+
+
-
Операционная система
12,5
+
+
+
Простой интерфейс
14,6
+
+
+
Широта распространения
13,6
+
+
+
Качество справочной
информации к системе
14,4
+
+
+
Количество пользователей
15,9
+
-
+
Простота использования
15,5
+
+
-
Сумма
100,0%
100%
84%
71%
55
Из всего вышеперечисленного и учитывая анализ СУБД методом экспертного
оценивания, оптимальным средством проектирования базы данных выбрано
Microsoft Access 2010. В отличие от Paradox, которая является локальной базой
данных, Microsoft Access 2010 является сетевой, и с помощью нее можно без
проблем создать приложение, в котором будут работать несколько
пользователей. Тем более в дальнейшем планируется создавать большой
автоматизированный комплекс с разделением прав доступа пользователей.
Поэтому однозначно выбор стоит за Microsoft Access 2010. Inter Base пo методу
экспертных оценок и по объективным показателям программирования не
подходит. Microsoft Access 2010 же удовлетворяет всем потребностям
проектирования физической модели данных, поэтому выбираем эту базу данных.
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение определяет совокупность технических средств,
необходимых для работы ИС, а также необходимая документация на эти
средства и технологические процессы.
Развитие технического обеспечения, включающее в себя аппаратные
средства, средства связи, ПО, реализуется неравномерно, скачкообразно.
Становление компьютерной техники на современном этапе происходит в
геометрической прогрессии. Каждые 4 года наблюдается удвоение мощности
компьютеров.
Различие компьютерных технологий по типу пользовательского
интерфейса (каким образом происходит взаимодействие пользователя с
компьютером) - пакетные, диалоговые, сетевые. В первом варианте пользователь
имеет только результаты работы технологии, в остальных он взаимодействует с
ней на личном ПК или ПК, входящем в сеть.
Нынешние технические средства реализации управления
информационными ресурсами по своему составу и возможностям весьма
разнообразны. Средства ЭВМ, средства связи, средства организационной
техники.
56
Компьютерная техника зачастую предназначена для разработки
комплексных технологий анализа и хранения данных и становится основой для
объединения всех новейших технических средств реализации управления
информационными ресурсами.
Коммуникационная техника предназначена зачастую для возможности
передачи данных и включает в себя как автономную работу, так и работу в
комплексе со средствами компьютерной техники.
Организационная техника создана для разработки технологий хранения,
отображения и применения информации, а также для запуска разных
вспомогательных операций в рамках различных технологий информационной
поддержки процесса управления.
В исследуемой задаче автоматизации в качестве технического
обеспечения применяется следующие средства:
• ПК менеджеров;
• Доступные сервера;
• Проложенная ЛВС.
ПК оцениваются по нескольким критериям:
• Скорость работы процессора;
• Полезный объем диска;
• Размер ОЗУ;
• Производительность видеосистемы.
Поскольку разрабатываемый модуль работает на базе клиент-серверной
технологии, то все подсчеты производятся на стороне сервера, поэтому
системные требования к ПК минимальны.
Указанные в пункте 1.1.3 технические характеристики для ПК относятся к
системным блокам средней производительности, откуда делается вывод, что их
обновление или полная замена для выполнения поставленной задачи не нужно.
Технические характеристики серверов также не подлежат улучшению, так
как в настоящее время используемые модели серверов имеют возможность
нарастить свою производительность для выполнения автоматизируемой задачи
без ущерба для других выполняемых ими задач.
57
Соединительные линии ЛВС оцениваются по допустимой пропускной
способности. Так как во время работы разрабатываемого модуля и обмена
информацией с сервером не передается голосовой или видео трафик, или другие
большие по объему данные, то и особых требований к пропускной способности
не предъявляется. Так как пропускная способность линий связи в настоящее
время составляет до 100 мбит/сек, то они также не требуют модернизации или
замены.
Таким образом, для корректной работы разрабатываемой
информационной системы необходимо использовать следующие технические
средства:
персональный компьютер пользователя;
принтер или многофункциональное устройство;
сервер;
соединительные линии, составляющие локальную вычислительную
сеть.
58
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл определяется как непрерывный процесс, который
обычно начинается с момента принятия решения о важности его реализации и
заканчивается сразу же после его изъятия из эксплуатации.
Среди наиболее популярных стандартов обычно выделяют следующие:
• ГОСТ 34.601-90 – применим к автоматизированным системам и
устанавливает все стадии и этапы их разработки. Также в этом стандарте есть
описание содержания работ для каждого этапа. Этапы и стадии, которые
закреплены в данном стандарте, чаще всего соответствуют каскадной модели
жизненного цикла.
• ISO/IEC 12207 – стандарт, определяющий процессы и организацию
жизненного цикла. Применим к любому виду заказного ПО. В стандарте нет
описания стадий, фаз и этапов.
• Custom Development Method (Oracle) – технологический материал
по разработке прикладных ИС, который детализирован до уровня заготовок
проектных инструкций, которые будут использоваться в проектах с участием
Oracle. Используется CDM для классической модели ЖЦ (имеются все этапы и
задачи), а также при технологии быстрой разработки или облегченного прохода,
которые используются в случае малого проекта.
• Rational Unified Process (RUP) – использует некую интерактивную
модель разработки, которая включает 4 фазы: начало, исследование, построение
и внедрение. Любая из этих фаз может разбиваться на этапы, в результате
которых исполняется версия для внутреннего или внешнего использования.
Проход по всем 4 фазам – это цикл разработки, и каждый такой цикл
завершается генерацией версии системы. Если после этого проект продолжается,
то сам продукт также видоизменяется и проходит эти фазы еще раз. Суть работы
в рамках RUP - разработка и сопровождение моделей на базе UML.
• Microsoft Solution Framework (MSF) – похож на RUP, также имеет 4
фазы: анализ, проектирование, разработка и стабилизация, является
59
итерационным и предполагает применение объектно-ориентированных моделей.
MSF в сравнении с RUP в большей степени предназначен для создания бизнес-
приложений.
• Extreme Programming (XP) – экстремальное программирование
(новейшая методология, сформировалась в 96 году). Основу методологии
составляют командная работа, активная коммуникация с заказчиком в течение
всего проекта по созданию ИС, ведение разработки с применением
последовательно обрабатываемых прототипов.
Для выбора стандарта основным фактором будет являться более
подробное и полное описание работы на стадиях и этапах разработки АС.
Стандарт ISO/IEP 12207 не имеет подробного описания работы на разных
стадиях и этапах создания АС.
Стандарт CDM рассчитан на проекты с использованием Oracle-
технологий, которые не применяются в данном проекте.
Стандарт MSF, как было сказано выше, ориентирован на бизнес-сферу.
Стандарт XP больше рассчитан на команду. Поэтому в данном проекте
используется ГОСТ 34.601-90, поскольку именно у него есть описание работы на
каждом этапе разработки АС.
Базовыми стадиями создания АС являются:
1) Выведение требований к системе;
2) Создание концепции;
3) Написание ТЗ;
4) Составление технического проекта;
5) Подготовка документации;
6) Внедрение.
На стадии «Выведение требований к системе» делаются следующие
работы:
• Обследуется объект;
• Формируются требования пользователя;
• Обосновывается необходимость разработки.
В данном этапе задействованы следующие участники: IT-менеджер,
начальник отдела производства. После реализации всех задач составляется отчет
60
о проделанной работе – описание объекта автоматизации, требований к системе,
выражение затрат на создание, введение в эксплуатацию и поддержку,
ожидаемый эффект от внедрения и требуемые условия для нормальной работы
системы.
После выполнения этапа «Выведение требований к системе» создается
вариант концепции. Разрабатывают несколько вариантов концепции и плана
реализации, оценивают ресурсы, необходимые на реализацию ИС и ее
нормальную работу, оценивают недостатки и достоинства каждого метода,
сопоставляют требования пользователей и функциональности возможной
системы.
На этапе «Создание концепции» участвует только IT-менеджер. После
того, как работа выполнена, выбирается наиболее удачный из всех подходящих
вариантов, который полностью удовлетворяет всем требованиям.
После этапа «Создание концепции» составляется ТЗ проекта
автоматизации. По его завершению важно его утвердить и согласовать. На
данном этапе участвуют: IT-менеджер и начальник отдела делопроизводства. По
итогам данный пункт может определять - функции ИС и подсистем, состав
отдельных и комплексных задач, концепцию информационной базы, состав
системы управления БД, функции и параметры программных средств.
После утверждения ТЗ идет разработка проектного решения. IT менеджер
и программист разрабатывают логическую и физическую модель БД, а также
определяют общую организацию данных.
После завершения этапа «Составление технического проекта» IT-
менеджер и программист оформляют рабочую документацию, которая включает:
технические и программные требования, руководство пользователя. После
завершения всех работ и написания документации остаётся только внедрить
систему.
Этап внедрения включает в себя: подготовку объекта автоматизации,
обучение сотрудников, проведение строительно–монтажных работ,
пусконаладочных работ, проведение испытаний, опытная эксплуатация и
приемочные испытания. В этом этапе участвуют: IT-менеджер, системный
администратор, начальник делопроизводства. После этого происходит анализ
61
испытаний ИС, проверка на соответствие ТЗ, устраняются неполадки или
подписываются все акты.
Для внедрения системы выбираем стратегию Пилотный проект.
Работы, ожидаемые на этапе эксплуатации, можно разделить на две
группы: плановые и неплановые.
К плановым работам будут относятся такие работы, как:
инсталляция программного обеспечения;
базовая настройка и проверка работоспособности компонентов
устанавливаемой системы;
устранение недостатков в конфигурации системы;
проверка надежности работы системы;
окончательная донастройка.
Данные работы будут выполнять специалисты отдела ИТ.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект разработки информационной системы учета рабочего времени, как
любой другой проект разработки программного обеспечения, содержит в себе
много неопределенных моментов, которые влекут за собой риски реализации
проекта.
Управление рисками состоит в их раннем выявлении и принятии мер,
которые позволят либо 100% предотвратить их возникновение, либо
значительно уменьшат последствия.
Сегодня существует три общепринятых стратегии управления рисками:
• Избегание рисков – проект строится так, чтобы исключить
возможность появления любого риска;
• Делегирование рисков – проект строится так, чтобы передать все
риски третьей стороне (инвесторам, банкам, заказчикам и т.п.);
• Принятие рисков – риски считаются неизбежной составляющей
проекта, реализуется постоянный мониторинг симптомов их проявления, часто
дорабатывается план действий в случае возникновения рисков.
62
Модно рассмотреть две базовые категории рисков – прямые и косвенные.
На прямые риски проектная команда еще как-то можно повлиять, а вот
косвенные риски нельзя проконтролировать в принципе.
Риски делят на 2 основных вида:
1) Ресурсные риски:
• Организация (делала ли компания прежде проекты аналогичной
сложности, есть ли формальный процесс создания ПО и т.п.);
• Финансирование (обеспечено ли на 100% финансирование проекта,
утверждена ли стоимость проекта или она все еще предмет для обсуждений,
точно ли проведена оценка затрат и т.п.);
• Персонал (хватает ли людей для выполнения проекта, имеют ли они
нужные навыки и опыт, случалось ли им раньше работать вместе и т.п.);
• Время (актуален ли план проекта, как критична установленная дата
завершения проекта и т.п.);
• Бизнес (что будет, если конкурент выйдет на рынок быстрее,
выгода, полученная от осуществления проекта больше, чем затраты на него, что
случится, если ключевые поставщики в силах будут выполнить свои
обязательства и т.п.);
2) Технические риски:
• Область действия проекта (могут ли меняться критерии
правильного завершения проекта, требования понятны и стабильны, область
действия четко фиксирована или будет расширяться в будущем и т.п.);
• Технологии (применялась ли используемая технология раньше или
она только что разработана, есть ли необычные или инновационные технические
решения, с которыми проектная команда раньше не могла сталкиваться и т.п.);
• Внешние зависимости (зависит ли проект от выполнения других
проектов, зависит ли успех проекта от сторонних продуктов или поставщиков и
т.п.).
В нашем проекте можно выделить следующие основные риски на каждом
этапе разработки (таблица 2.1).
Таблица 2.1
Основные риски на этапах реализации системы