1.3.3 Выбор и обоснование способа приобретения ИС для автоматизации комплекса задач

Способы приобретения ИС - это последующие действия от определения и формализации решения о необходимости ИС до момента пока ИС не будет внедрена на предприятия. Существуют следующие способы приобретения ИС [6]:

· разработка (самостоятельная и заказная);

· покупка ИС (покупка отечественной или зарубежной ИС);

· покупка + доработка (самостоятельная или заказная);

· аренда.

Приобретаемая информационная система нам не подходит из-за ряда недостатков, перечисленных в пункте 1.3.1, а также нехватки функциональности, хуже продумано направление будущего развития информационной системы, длительный срок адаптации под требования предприятий, так же требуется частое обращение в службу поддержки. Покупка и доработка возможна, если требует небольшой объем доработки, данная доработка часто возможна в рамках модели ядра ИС, что часто вызывает затруднения из-за отсутствия развернутой документации. У варианта аренды ИС можно выявить несколько недостатков: бизнес данные хранятся у третьего лица, часто минимальные возможности по настройки. Информационная система будет разрабатываться в компании собственными силами, так как компания располагает квалифицированными сотрудниками для разработки и внедрения данной информационной системы. Разрабатываемая информационная система будет включать весь необходимый функционал, и учитывать все особенность работы и пожелания сотрудников данной компании, так как будет являться индивидуальным (уникальным) продуктом, что позволяет быстро изменить функциональность в соответствии с требованием внутреннего заказчика.

1.4 Обоснование проектных решений

1.4.1 Обоснование проектных решений по техническому обеспечению

Техническое обеспечение - комплекс технических средств, предназначенных для работы информационной системы, а также соответствующая документация на эти средства и технологические процессы [9].

Комплекс технических средств составляют:

· компьютеры;

· устройства сбора, накопления, обработки, передачи и вывода информации - жесткие диски, устройства хранения данных, сканеры, принтеры, факсимильные аппараты;

· устройства передачи данных и линий связи - модемы;

· эксплуатационные материалы - бумага, CD (DVD) - диски и т.п.

При выборе компьютера необходимо руководствоваться рядом характеристик. К таким характеристикам относятся надежность, стоимостные затраты, производительность, простота использования и др. От значения указанных параметров зависит возможность работы с требуемыми программными средствами, а следовательно, и успех создания системы.

Для каждого из элементов данной схемы выделяется перечень критериев, наиболее важных при осуществлении выбора технического обеспечения. Эти критерии таковы:

· - тактовая частота процессора;

· - разрешение монитора;

· - объем оперативной памяти.

Для решения поставленной задачи необходимо использовать персональный компьютер с уровнем вычислительной мощности AMD 2000 Мгц, либо Intel 2000 Мгц, с объемом оперативной памяти от 2 Гб. Система оптимизирована для работы в экранном разрешении 1024х768 на мониторе с диагональю 17 дюймов. Все эти технические средства обладают достаточной для решения задачи конфигурацией.

В настоящее время разрозненный парк персональных компьютеров создает сложности с их техническим обслуживанием, ремонтом, поэтому необходимо его унифицировать и закупить одинаковые рабочие станции.

Технические характеристики подходящей рабочей станции приведены в таблице 1.5.:

Таблица 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 (мм)

Кроме того, для работы файл-сервера необходимо закупить специализированной серверное оборудование, например Team Server 3420P, характеристики которого приведены в таблице 1.6.

Таблица 1.8. Технические характеристики рекомендуемого сервера

типичное применение	интернет / интранет-службы, терминальные службы, контроллер домена, файловый сервер, универсальный сервер рабочей группы или небольшой компании
процессоры	Один четырехядерный процессор 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)

В данном виде информационная система будет готова в внедрению автоматизированной системы документооборота

1.4.2 Обоснование проектных решений по информационному обеспечению

Информационное обеспечение (ИО) подсистемы представляет собой информационную модель работы сотрудников предприятия. Различают внемашинное и внутримашинное обеспечение.

Информационное обеспечение включает в себя: систему классификации и кодирования; систему унифицированной документации, используемой в ИО, информационную базу, т.е. информацию из всех информационных массивов.

Внемашинное обеспечение - это вся совокупность информации, основную часть которой составляют документы. Различат первичные документы (входные) такие, как налоговые декларации и другая отчетность налогоплательщиков, и отчетные (выходные) документы, к которым относятся отчетность налогоплательщиков, обработанная и подготовленная для отдела по работе с налогоплательщиками и отдела камеральных проверок.

Внутримашинное ИО - это представление данных на машинных носителях в виде специальным образом организованных массивов (файлов), БД и их информационных связей. Внутримашинное информационное обеспечение подсистемы создает информационную среду, направленную на выполнение сотрудниками своих профессиональных обязанностей. Эта область характеризуется набором объектов, их свойств и взаимосвязей. Для каждого объекта выделяется набор его характеристик, свойств.

Информационные потоки внешне машинного ИО - это направленное регулярное движение документов от источников их формирования к ее получателям [10].

Для того чтобы приспособить экономическую информацию для эффективного поиска, обработки и передачи по каналам связи, ее необходимо представить в цифровом виде. С этой целью ее нужно сначала упорядочить (классифицировать), а затем формализовать (закодировать) с использованием классификатора.

Классификатор - это документ, с помощью которого осуществляется формализованное описание экономической информации в ЭИС, содержащей наименования объектов, наименования классификационных группировок и их кодовые обозначения. [13]

По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные (общесистемные), отраслевые и локальные классификаторы.

Основной компонентой внемашинного информационного обеспечения является система документации, применяемая в процессе управления экономическим объектом. Под документом понимается определенная совокупность сведений, используемая при решении экономических задач, расположенная на материальном носителе в соответствии с установленной формой.

Система документации - это совокупность взаимосвязанных форм документов, регулярно используемых в процессе управления экономическим объектом. Отличительной особенностью системы экономической документации является большое разнообразие видов документов. [13]

Существующие системы документации, характерные для неавтоматизированных ЭИС, отличаются большим количеством разных типов форм документов; большим объемом потоков документов и их запутанностью; дублированием информации в документах и работ по их обработке и, как следствие, низкой достоверностью получаемых результатов. Обработка документов в таких системах занимает почти половину времени работников. При необходимости упростить систему документации, используют следующие подходы:

· проведение унификации и стандартизации документов;

· введение безбумажной технологии, основанной на использовании электронных документов и новых информационных технологий их обработки.

Входные документы для решаемой задачи желательно получать через сеть, поэтому они должны быть представлены в файлах заранее согласованной структуры. Для упрощения использования таких файлов, они должны иметь табличную форму (что несложно осуществить, т. к. эти документы являются результатными в других задачах и выводятся программными средствами).

Классификаторы служат средством описания данных, обуславливают единство классификации и кодирования информации и предназначены для обеспечения машинной обработки и выдачи данных в удобной форме потребителям при решении различных задач.

В проектируемой задаче использовались следующие общероссийские классификаторы:

ОКУД - Общероссийский классификатор управленческой документации;

ОКОПФ - Общероссийский классификатор организационно-правовых форм [4].

К внутримашинному информационному обеспечению относится описание экранных форм.

При построении структуры экранных форм для ввода данных первичных документов с оперативной информацией целесообразно использовать комбинированную форму, максимально приближенную к той, которая была использована для построения самого документа. Расположение полей должно быть в последовательности, соответствующей логической структуре документа и файлов с оперативной информацией, сокращающей трудоемкость операции загрузки информации в информационную базу.

При построении экранных форм для документов с постоянной информацией следует иметь в виду, что эти макеты используются для ввода и актуализации записей информационной базы, поэтому для их проектирования целесообразно применить анкетную форму расположения реквизитов, удобную для выполнения этих операций.

В основе выбора экранных форм лежат принципы минимальной трудоемкости и стоимости ввода информации в ЭВМ, максимальной степени читабельности результатной информации, выводимой на экран, и максимальной надежности и достоверности выполнения этих операций.

При разработке системы использовалась реляционная модель базы данных. Реляционная модель данных некоторой предметной области представляет собой набор отношений изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области, моделировать связи между ними. При этом сами данные хранятся в таблицах [6]. Для удобства идентификации каждая таблица созданной базы данных обладает уникальным кодом.

В связи с этим содержание экранных форм должно включать следующие основные реквизиты:

- наименование;

- количество;

- дата ввода;

- дополнительные реквизиты.

Данные реквизиты должна содержать каждая форма, и кроме того, в зависимости от назначения конкретной формы должны учитываться свои, уникальные реквизиты.

1.4.3 Обоснование проектных решений по программному обеспечению

Программное обеспечение (ПО) включает совокупность программ, реализующих функции и задачи ИС и обеспечивающих устойчивую работу комплексов технических средств. В состав программного обеспечения входят общесистемные и специальные программы, а также инструктивно-методические материалы по применению средств программного обеспечения.

К общесистемному (общему) программному обеспечению относятся программы, рассчитанные на широкий круг пользователей и предназначенные для организации вычислительного процесса и выполнения часто встречающихся вариантов обработки информации. Они позволяют расширить функциональные возможности ЭВМ, автоматизировать планирование очередности вычислительных работ, а также автоматизировать работу программистов. Специальное (функциональное) программное обеспечение представляет собой совокупность программ, разрабатываемых при создании ИТ конкретного функционального назначения. Оно включает пакеты прикладных программ, осуществлявших организацию данных и их обработку при решении функциональных задач ИС [3].

При выборе комплекса технических средств для разработки системы, одним из важнейших критерием является выбор операционной системы. Операционная система управляет техническими средствами компьютера, поддерживает запуск и выполнение тех или иных программ и приложений, обеспечивает защиту данных, выполняет различные сервисные функции. Каждая программа пользуется средствами, предоставляемыми операционной системой. Таким образом, выбор операционной системы очень важен, так как он определяет набор программ и формат исполняемых файлов, а также их взаимодействие с операционной системой.

На компьютерах с архитектурой x86, используемых в качестве рабочих мест пользователей, чаще всего применяются следующие операционные системы:

- операционные системы семейства Windows от фирмы Microsoft (Windows 95/98/Me, Windows NT4.0/2000/XP),

- операционные системы Linux/BSD семейства (UNIX подобные) от различных фирм - разработчиков (Red Hat, Debian, Novel, Mandrake soft, Gentoo, Slackware, IBM, Oracle, NetBSD, OpenBSD, FreeBSD) [13].

Для разработки программного приложения автоматизированной обработки выбор той или иной операционной системы не повлияет на функциональность системы по причине того, что при реализации алгоритмов программного приложения не требуется использования каких-либо специфических функций операционной системы. Оба типа операционных систем позволяют разрабатывать программный продукт без потери его функциональности, по причине наличия программных сред (языков программирования) для обоих типов операционных систем [14].

Все из вышеперечисленных операционных систем содержат интерфейсы межсетевого взаимодействия, что позволяет использовать программное приложение в сети, для обмена данными и параллельной работы нескольких копий программного приложения с одними исходными данными. Оба типа операционных систем содержат в себе качественный интерфейс пользователя, что также позволяет производить разработку программного приложения для любой из этих операционных систем.

В качестве операционной среды для разработки и применения программы была выбрана операционная система семейства Windows, в частности операционная система Windows Vista. Этот выбор обусловлен тем, что на сегодняшний день Windows Vista является одной из наиболее распространенных операционных систем. Операционная система Windows Vista обеспечивает стабильность работы, предоставляя пользователям возможность сосредоточиться на выполняемой работе.

Одним из важных требований, предъявляемых к проектированию информационных систем, эксплуатируемых совместно на технологической базе весьма ограниченных возможностей, является большая их однородность, позволяющая обеспечить совместимость, мобильность, переносимость.

Выбор системы управления баз данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды.

Наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы. Более сложным и дорогостоящим вариантом является создание испытательного проекта на основе нескольких СУБД и последующий выбор наиболее подходящего из кандидатов. Но и в этом случае необходимо ограничивать круг возможных систем, опираясь на некие критерии отбора. В данном случае можно выделить несколько групп критериев:

· Моделирование данных

· Особенности архитектуры и функциональные возможности

· Контроль работы системы

· Особенности разработки приложений

· Производительность

· Надежность

· Требования к рабочей среде

· Смешанные критерии

Основным принципом выбора СУБД следует считать определение программного продукта, в наибольшей мере соответствующего предъявляемым требованиям. Эту задачу решить не очень просто. Во-первых, к СУБД предъявляется большое число требований, которые с течением времени изменяются, во-вторых, СУБД имеют большое число параметров, что затрудняет их сравнение. Кроме того, информация о СУБД часто носит рекламный характер, не позволяющий сделать правильное суждение.

Процедуру выбора СУБД следует проводить в три этапа:

· На качественном уровне оценить предлагаемые программные продукты на предмет пригодности;

· Оценка технических характеристик отобранных систем;

· Оценка производительности программных продуктов.

К числу основных показателей пригодности программных продуктов относятся:

· вид программного продукта;

· категории пользователей (профессиональные программисты, администраторы БД, квалифицированные пользователи, разрабатывающие приложения, конечные пользователи, различные комбинации перечисленных категорий);

· удобство и простота использования (понятные процедуры установки программных продуктов, удобный и унифицированный интерфейс конечного пользователя, простота выполнения обычных операций: создания БД, навигации, модификации, подготовки данных, выполнения запросов и отчетов и ряда других; наличие интеллектуальных подсистем подсказок, помощи в процессе работы и обучения, включая примеры);

· модель представления данных. Наиболее распространенной является реляционная модель данных. Перспективными являются модели с объектной ориентацией, поскольку они обладают большими возможностями отражения семантики предметной области;

· качество средств разработки. При оценке качества средств разработки учитывается следующее: возможности создания пользовательских интерфейсов, мощность языка создания программ, автоматизация разработки различных объектов: экранных форм, отчетов, запросов. Предпочтение отдается системам, имеющим полнофункциональные генераторы и обеспечивающим удобство работы пользователя;

· качество средств защиты и контроля корректности базы данных. Доступ к функциям защиты должен предусматриваться на уровне средств разработки программ и на уровне пользователя. К важнейшим функциям контроля корректности относятся: обеспечение уникальности записей БД по первичному ключу, автоматический контроль целостности связей между таблицами во время выполнения операций обновления, вставки и удаления записей, проверка корректности значений в БД;

· качество коммуникационных средств. При оценке качества коммуникационных средств обращают внимание на следующие свойства программных продуктов:

· поддержку сетевых протоколов,

· поддержку стандартных интерфейсов с БД,

· наличие средств групповой работы с информацией БД,

· способность использовать и модифицировать БД других форматов без импортирования или преобразования;

· фирма - разработчик. Солидность фирмы-разработчика пакета, как правило, дает следующие преимущества:

· высокое качество продукта,

· наличие документации и методических материалов

· наличие «горячей линии» для консультаций по возникающим проблемам

При выборе продукта следует обратить внимание на дату его появления. В качестве показателей «благополучия» можно использовать: твердое финансовое положение, перспективная динамика развития аппаратно-программных средств, годовой оборот, численность состава, объем продаж и т.д. - стоимость. На стоимость программных продуктов в основном влияют вид программного продукта и фирма - разработчик. Стоимость полнофункциональных СУБД обычно колеблется в пределах $ 500 - $ 1000. Общая стоимость включает в себя стоимость прикладного инструментария, средств настройки конфигурации системы, администрирования БД и сопровождения. Иногда общая стоимость крупных систем, построенных на базе реляционных БД, достигает миллионов долларов. Основным фактором, определяющим общую стоимость системы, чаще всего является число поддерживаемых пользователей.

На уровне технических характеристик разнообразие СУБД еще больше, чем на качественном уровне. К техническим характеристикам относятся:

· общие параметры (операционная среда, потребность в оперативной памяти, ограничения на максимальный объем БД и др.);

· ограничения на операции над данными;

· типы данных;

· возможности средств формулировки и выполнения запросов;

· работа в многопользовательских средах;

· инструментальные средства разработки приложений;

· импорт и экспорт.

Оценка производительности производится методом тестирования с помощью эталонных тестов из набора AS3AP (ANSI SQL Standard Scalable and Portable). В них контролируется широкий спектр часто встречающихся операций БД и моделируются однопользовательские и многопользователь-ские среды.

Ниже, в таблице 1.9. приведена сравнительная таблица трех распространенных систем управления базами данных, конкурирующих на рынке программного обеспечения по основным показателям.

Таблица 1.9. Сравнение СУБД

Показатели	Microsoft SQL Server 2008	MySQL 5.1	PostgreSQL 8.4
Поддерживаемые операционные системы	Windows Desktop/Server	Windows Desktop/Server, Linux, Unix, Mac	Windows1 Desktop/S22erver, Linux, Unix, 2Mac
Условии лицензирования	Коммерческий продукт с закрытым исходным кодом. Есть бесплатная версия с ограничением оперативной памяти до 4 Гб.	Коммерческая лицензия и GNU GPL.	Лицензия BSD Open Source.
Наличие предустановленных драйверов в ОС семейства Windows	Да	Нет	Нет
Поддержка репликации	Да, встроенная и разных типов. Но внесение тсруктурных изменений после начала репликаци - очень сложный процесс.	Да, включая mater-master репликацию.	Да, но с помощью сторонних продуктов с открытым исходным кодом. Репликация всех типов.
Возможность писать хранимые функции на разных языках программирования	Да, теоретически на любом языке, поддерживающим CLR, например VisualBasic.NET, C#, IronPython, но сначала надо скомпилировать код в бибилиотеку dll.	Нет (кроме C и Pl/SQL)	Да, наиболее полная поддержка из всех рассматриваемых.
Возможность создавать пользовательские аггрегированные функции	Да - любой.NET язык, кроме TRANSACT SQL.	Да, только на С	Да - на PL language и встроенных C, SQL, PLPgSQL.
Поддержка даты и времени	Да	Да (но без временной зоны)	Да
Аутентификация	Средставими БД и ActiveDirectory	Средствами БД	Много разных методов, включающих предыдущие
Разграничение доступа к столбцам	Да	Да	Да

Таким образом, для проекта, рассматриваемого в данном дипломном проекте наиболее приемлема СУБД MySQL.

Кроме того, данная СУБД обладает следующими преимуществами:

· многопоточность, поддержка нескольких одновременных запросов;

· оптимизация связей с присоединением многих данных за один проход;

· записи фиксированной и переменной длины;

· ODBC драйвер;

· гибкая система привилегий и паролей;

· гибкая поддержка форматов чисел, строк переменной длины и меток времени;

· интерфейс с языками C и Perl, PHP;

· быстрая работа, масштабируемость;

· совместимость с ANSI SQL;

· бесплатна в большинстве случаев;

· хорошая поддержка со стороны провайдеров услуг хостинга;

· быстрая поддержка транзакций через механизм InnoDB.

Кроме СУБД, необходимы выбрать и язык веб-программирования.

В случае WEB-приложений речь идёт, конечно же, об ASP.NET и его основном в настоящее время конкуренте - РНР.

Рассмотрим подробнее преимущества и недостатки обоих платформ.

Очевидные преимущества ASP.NET

Типизация. Языки программирования ASP.NET имеют строгую типизацию данных. Это безусловно выигрышный момент по сравнению с нетипизированным php: меньше будет логических ошибок, которые весьма трудно находить и исправлять. Некоторым утешением для сторонников php является возможность привести переменную к нужному типу - но увы, присвоение переменной, приведённой к целому типу, строкового значения не вызовет даже предупреждения со стороны интерпретатора.

Очевидные преимущества php

Доступность дистрибутивов. Дистрибутивы LAMP измеряются в десятках мегабайт (а не в DVD-дисках, как Windows/IIS/Visual studio/MS SQL Server) и доступны на сайтах разработчиков.

Open source (открытый код), представляющий возможность для аудита кода. Что особенно важно - аудитом кода занимаются программисты всего мира, способствуя устранению уязвимостей и прочих недостатков.

Поскольку обе технологии ограничены довольно простым протоколом HTTP и языком разметки HTML - их возможности примерно равны. Все задачи, решаемые в рамках одной технологии, столь же успешно решаются и в рамках другой. Можно спорить лишь о большем или меньшем удобстве предлагаемые технологиями решений - но мы воздержимся от споров о вкусах.

Таким образом, ни php, ни ASP.NET не дают технологического преимущества WEB-проекту. Различия проявляются в стоимости и трудоёмкости разработки и эксплуатации проекта. В этих показателях php значительно выгодней ASP.NET. А преимущества ASP.NET в области разработки и поддержки, провозглашаемые рекламой, в основном являются, увы, не более чем рекламой.

Кроссплатформенность. php портирован практически под все распространённые операционные системы, в то время как ASP.NET ориентирован на Windows, и то не всякую, а только 2000/XP/Vista.

Удачный набор функций. php предоставляет WEB-разработчику большое количество функций для решения типовых задач. Создатели php хорошо знают, какие задачи чаще всего решает разработчик WEB-приложений. В ASP.NET нет полезных функций, необходимых постоянно - при наличии огромного количества методов, которым и применения-то не придумать.

Прозрачная привязка проекта к файловой системе. И как следствие - нет необходимости в специальных средствах разработки (вроде Visual Studio). Иными словами, в php-проекте нет конструкций, для визуализации и редактирования которых требовался бы особый редактор.

Что же мы видим в ASP.NET? Не так уж просто сообразить, например, как связаны пространства имён (namespaces) и расположение файлов на диске. В итоге бывает, что классы не видят друг друга.

Простота настройки Apache, php, MySQL. Все настройки содержатся в тектовых ini-файлах. Все параметры откомментированы.

Совместимость «снизу вверх». Переход php-проекта на новую версию php возможен либо вообще без изменений (именно этим мне запомнился переход с php 4.x на php 5.x), либо с минимальными доработками, связанными, как правило, с изменениями настроек по умолчанию (не буду долго останавливаться на том, что полагаться на настройки по умолчанию - дурной тон в программировании). А случае с ASP.NET мы видим, что проект надо полностью переделать.

Поэтому для реализации проектируемой системы выберем язык программирования PHP.

2. Проектная часть

2.1 Разработка проекта автоматизации

2.1.1 Этапы жизненного цикла проекта автоматизации

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования. Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.

В настоящее время известны и используются следующие модели жизненного цикла:

· Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

· Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

· Цикличная модель. На каждом цикле выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего цикла. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.

Можно выделить следующие положительные стороны применения каскадного подхода:

· на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

· выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем.

Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям.

Цикличная модель ЖЦ была предложена для преодоления перечисленных проблем. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый цикл соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего цикла. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.

Итеративная разработка отражает объективно существующий цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем цикле и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.

Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения вводятся временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Распространены несколько стандартов, описывающих жизненный цикл информационной системы:

- ГОСТ 34.601-90 - стандарт распространяется на автоматизированные системы, используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях. Стандарт устанавливает стадии и этапы создания автоматизированной системы.

- ISO 12207 - стандарт применяется при приобретении систем, программных продуктов и оказании соответствующих услуг (внедрение, сопровождение). А также при поставке, разработке, эксплуатации и сопровождении программных продуктов и программных компонентов программно-аппаратных средств как в самой организации, так и вне нее.

- ISO 15288 - стандарт обеспечивает общие основы процессов, составляющих жизненной цикл систем, созданных человеком. Этот жизненный цикл охватывает концепции идей вплоть до снятия системы с эксплуатации. Он обеспечивает процессы для приобретения и поставки системы.

- RUP (Rational Unified Process - рациональный унифицированный процесс) - это методология разработки программного обеспечения, созданная и распространяемая корпорацией Rational Software (www.rational.com). Она описывает упорядоченный подход к распределению задач и обязанностей в организации-разработчике [12].

- XP (eXtreme Programming) - методология содержит совершенно иные базовые принципы, нежели RUP. Основными чертами являются определение точных кратковременных планов (как правило, недельных), постоянное перепланирование, тесное общение с заказчиком. Эта методология больше подходит для полуисследовательских и инновационных проектов [13].

- MSF (Microsoft Solutions Framework - методология создания программных решений) - В модели процессов приводится общее описание организации работ над проектом по разработке и внедрению ИТ-решений. Предлагаемая схема достаточно гибка и может применяться к самым разным проектам в области информационных технологий. В версии 3.1 концепция была расширена и теперь охватывает практически весь цикл создания решений - начиная с их обсуждения и заканчивая внедрением [11].

- COBIT (Control Objectives for Information and Related Technology - цели контроля для информационных и смежных технологий) - основная идея стандарта COBIT выражается следующим образом: все ресурсы информационной системы должны управляться набором естественно сгруппированных процессов для обеспечения компании необходимой и надежной информацией [14].

- Oracle CDM (Custom Development Method - методика разработки ИС под заказ) - позволяет стандартизировать процесс создания приложений. CDM охватывает полный жизненный цикл разработки приложений, описывая последовательность и взаимную зависимость задач, решаемых в процессе разработки.

В настоящем проекте необходимо и достаточно использовать методологию разработки и внедрения IT-решений - Microsoft Solution Framework (MSF).

Это решение было принято в связи с тем, что ФГУП уже некоторое время работает с продукцией корпорации Microsoft, работает с ее продукцией и использует ее технологии, в частности, рабочие станции предприятия и сервер работают под управлением операционных систем разработанных корпорацией Microsoft. Таким образом, у ФГУП есть большой опыт работы с продуктами Microsoft в том числе и непосредственно с методологией разработки и внедрения IT-решений MSF.

Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной и спиральной. Она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением.

В модели MSF выделяется 5 фаз жизненного цикла: Выработка концепции, Планирование, Разработка, Стабилизация, Внедрение.

Фаза выработки концепции - На фазе выработки концепции закладывается одна из фундаментальных основ успеха проекта - создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. В данном случае в роли заказчика выступает сам разработчик. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования. Она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования.

Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка документа общего описания и рамок проекта. Формирование видения проекта и специфицирование его рамок - не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение - это ничем не ограничиваемое представление о том, каким должно быть решение. Рамки же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.

Также во время фазы выработки концепции производится выявление и анализ бизнес требований. Более детально эти требования рассматриваются во время фазы планирования.

Веха «Концепция утверждена» - Проектная группа должна прийти к соглашению об общих задачах проекта, включаемой и не включаемой в решение функциональности и временных рамках.

Результаты:

- Общее описание и рамки проекта;

- Описание структуры проекта.

Фаза планирования - На фазе планирования производится основная работа по составлению планов проекта. Она включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта.

В начале фазы планирования проектная группа анализирует и документирует проектные требования. Они разделяются на четыре общих категории: бизнес-требования, потребительские требования, эксплуатационные требования и системные требования, относящиеся к решению в целом. В ходе проектирования решения и создания его функциональной спецификации необходимо следить за соответствием между имеющимися требованиями и проектируемой функциональностью. Это соответствие не обязательно будет взаимооднозначным. Оно служит одним из способов контроля корректности дизайна и его пригодности для достижения поставленных перед решением целей.

Процесс проектирования - это систематический способ продвижения от абстрактных концепций к конкретным техническим деталям. Он начинается с методичного анализа профилей пользователей, которые описывают различные типы пользователей (включая персонал сопровождения) и их рабочие функции. Значительная часть этой работы часто проводится во время фазы выработки концепции. Затем формируется набор сценариев использования, в каждом из которых моделируется выполнение какой-либо операции определенным типом пользователя. В конце концов, каждый сценарий использования разбивается на последовательность специфических действий, называемых примерами пользования, которые необходимо выполнить пользователю для осуществления операции.

Существует три уровня процесса проектирования: концептуальный дизайн, логический дизайн и физический дизайн. Работа над логическим дизайном начинается через некоторое время после начала концептуального дизайна, и работа над физическим дизайном стартует через некоторое время после начала работы над логическим.

Результаты процесса проектирования документируются в функциональной спецификации. Функциональные спецификации детально описывают вид и поведение каждой составляющей решения. Также для всех составляющих описывается их архитектура и дизайн.

Как только создана базовая версия функциональной спецификации, может быть начато детальное планирование. Руководитель проектной группы подготавливает план, и принимает участие в командных сессиях планирования. Примеры планов включают в себя план внедрения, план тестирования, план эксплуатации, план мер безопасности, план обучения.

Затем проектная группа коллективно анализирует планы и выявляет взаимозависимости между ними. Все планы синхронизируются и представляются вместе в виде сводного плана проекта.

Члены проектной группы, представляющие каждый из ролевых кластеров, оценивают необходимое для выполнения запланированных задач время и составляют календарный график сдачи результатов. Затем происходит синхронизация календарных графиков с последующей их интеграцией в сводный календарный график проекта.

Веха «Планы проекта утверждены» - Эта веха знаменует собой соглашение между проектной группой. Промежуточные вехи фазы планирования успешно пройдены, составленные календарные графики реалистичны, распределение ролей и ответственности в команде определено должным образом. Функциональные спецификации, сводный план и сводный календарный график проекта служат основой для принятия компромиссных решений в будущем.

Утвержденные спецификации, планы и календарные графики образуют базовую версию проекта. Она включает все соглашения, принятые на основе консенсуса с учетом трех плановых параметров проекта: ресурсов, времени и функциональности решения. После того, как базовая версия проекта создана и утверждена, проектная группа приступает к фазе разработки.

Изменения в созданной базовой версии проекта подвергаются строгому контролю. Это не означает, что все принятые во время фазы планирования решения окончательны - в ходе последующей фазы разработки проектная группа должна анализировать и формально утверждать (либо отвергать) все предлагаемые изменения базовой версии.

Результаты:

- Функциональная спецификация;

- Сводный план и сводный календарный график проекта.

На фазе разработки проектная группа фокусируется на создании компонент решения (включая как документацию, так и программный код). Однако некоторая часть этой работы может продолжаться также на фазе стабилизации, если такая необходимость выявлена в процессе тестирования. Данная фаза также включает в себя разработку инфраструктуры.

Веха «Разработка завершена» - эта веха является кульминацией фазы разработки. К моменту ее наступления создание всех составляющих завершено, и решение готово к тестированию и стабилизации. Компания получает возможность оценить решение и выявить все оставшиеся проблемы и неурегулированные вопросы, которые должны быть улажены до выпуска решения.

Результаты:

- Исходный и исполнимый код приложений;

- Скрипты установки и конфигурирования;

- Окончательная функциональная спецификация;

- Материалы поддержки решения;

- Спецификации и сценарии тестов.

Фаза стабилизации - во время фазы стабилизации производится тестирование разработанного решения. При этом внимание фокусируется на его эксплуатации в реалистичной модели производственной среды. Проектная группа занимается приоритезацией и устранением ошибок, а также подготовкой решения к выпуску.

Как только создана версия, достаточно стабильная для того, чтобы считаться кандидатом для выпуска, производится пилотное внедрение решения.

Фаза стабилизации завершается вехой «Готовность решения утверждена». В состоянии, достигнутом к этому моменту, решение уже готово к полному внедрению в производственную среду.

Веха «Готовность решения утверждена» - к моменту наступления этой вехи проектная группа завершает разрешение всех существенных проблем и производится внедрение решения. Ответственность за непрерывное управление и поддержку решения формально переходит от проектной группы к командам сопровождения.

Результаты:

- Окончательный продукт;

- Документация выпуска;

- Материалы поддержки решения;

- Результаты и инструментарий тестирования;

- Исходный и исполнимый код приложений;

- Проектная документация;

- Анализ пройденной фазы.

Фаза внедрения - во время этой фазы проектная группа внедряет технологии и компоненты решения, стабилизирует внедренное решение, передает работу персоналу поддержки и сопровождения. По завершению внедрения проектная группа производит анализ выполненной работы и удовлетворенности заказчика.

Во время этой фазы по ходу переноса компонент решения из среды тестирования в производственную среду могут продолжаться меры по стабилизации решения.

Веха «Внедрение завершено» - Это финал фазы внедрения. К этому времени решение должно начать давать заказчику ожидаемую бизнес-отдачу, а проектная группа - свернуть свою деятельность.

Решение должно быть стабильным и четко удовлетворять выработанным критериям успешности. Стабильность решения означает также готовность систем его эксплуатации и сопровождения.

Результаты:

- Информационные системы эксплуатации и поддержки;

- Процедуры и процессы;

- Базы знаний, отчеты, журналы протоколов;

- Версии проектных документов, массивы данных и программный код, разработанные во время проекта;

- Отчет о завершении проекта;

- Окончательные версии всех проектных документов;

- Показатели удовлетворенности заказчика и потребителей;

- Описание последующих шагов.

В процессе эксплуатации персонал компании должен следовать всем инструкциям относящейся к разработанной информационной системе. В случае проблем или вопросов, персонал должен обратиться в службу поддержки. Данная служба проанализирует сложившуюся ситуацию, и примет меры для скорейшего их устранения.

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

В ходе жизненного цикла информационной системы всегда могут возникнуть риски, могущие сорвать разработку. Для их избежания проводится оценка вероятных рисков и разрабатываются способы, позволяющие избегнуть эти риски или минимизировать их влияние.

Рассмотрим наиболее вероятные риски по фазам жизненного цикла информационной системы в соответсвии с выбранным стандартом.

Фаза выработки концепции - возможен риск сознания концепции, которую впоследствии будет сложно (не возможно) реализовать. В выработки концепции должны быть описаны основные (базовые) функции разрабатываемой информационной системы. Главное создать основу, и в дальнейшем развивать созданную систему.

Для предотвращения возникновения рисков на фазе выработки концепции, необходимо четко понимать свои возможности. Для предотвращения переоценки собственных сил, в первую очередь нужно создать общую концепцию, в которой будут включены только базовые функции будущей системы. И по мере углубления в тему разработки расширять дополнительными функциями.

Фаза планирования - на фазе планирования возможен риск неправильного планирования, разработка очень оптимистичных планов проекта, в которые компания не успеет уложиться, вследствие чего придется увеличивать время разработки, что повлечет за собой удорожание проекта в целом. К фазе планирования нужно отнестись очень важно, следить за каждым этапом и анализировать реалистичность результатов.

Для предотвращения риска на фазе планирования, нужно во время планирования заложить в график поправки на возможные задержки в выполнении тех или иных действий. Так нужно попытаться создать гибкий график который бы не ломался в связи задержки или опережения.

Фаза разработки - возможен рисок того что разработка определенного модуля будет сопряжен с большими трудностями, что какая-та функция будет мешать продвижению разработки. На данной фазе важно во время определить проблемный модуль или функцию и по возможности упростить ее, заменить другой или убрать из проекта полностью.

Для предотвращения риска разработки сложного модуля, можно принять несколько решений, либо разбить данный модуль на несколько и решить поставленные задачи по отдельности, либо упростить сложный модуль, если это единственный вариант преодоления риска.

Фаза стабилизации - на фазе стабилизации возможен риск выявления большого количества ошибок в программном коде, что потребует больших затрат на доработку и устранения всех выявленных ошибок. Невозможно предсказать, сколько ошибок будет найдено и как много времени понадобится на их устранение.

Для предотвращения рисков на фазе стабилизации, необходимо данной фазе отвести максимально возможное время, выделенное на разработку системы. Так как в зависимости от того на сколько качественным будет продукт, зависит примет ли заказчик данную разработку или нет.

Фаза внедрения - фаза внедрения может оказаться очень длительной, если заказчик по каким-либо причинам будет не доволен разработанным продуктом, персонал автоматизируемой компании может негативно относиться к внедрению нового программного обеспечения.

Для предотвращения рисков на данной фазе необходимо произвести качественное обучение персонала еще до начала внедрения, обучить службу сопровождения и поддержки. Понять какие проблемы могут возникнуть в процессе внедрения и уже быть готовым к их решению. Постоянно консультировать персонал по поводу возникших у них трудностей, создать горячую линию для решения данных проблем.

2.1.3 Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации

Комплекс мер по защите информации в разрабатываемой системе включает в себя следующие аспекты:

· защита информации непосредственно в информационной системе от внутренних угроз;

· защита информации от внешних угроз.

Для защиты от внутренних угроз в системе используется политика разделения прав доступа. Характеристика политики приведена в таблице 2.1.

автоматизация проект организационный экономический

Таблица 2.1. Разграничение прав пользователей

Группы пользова-телей	Модуль «Авторизация»	Модуль «Регистрация документа»	Модуль «Постановка на контроль»	Модуль «Резолюция»
Сотрудники ОД	Чтение	Полный	Чтение	Ограничен
Руководитель	Чтение	НЕт	Полный	Полный
Администратор системы	Полный	Полный	Полный	Полный

Защита от внешних угроз осуществляется путем применения следующих способов:

- использованием программно-аппаратных комплексов;

- разработкой и соблюдение политик безопасности;

- использованием защищенных каналов связи при передаче информации;

- использованием антивирусных средств;

- физической защитой помещений с наиболее ценной информацией.

Характеристика используемых средств от внешних угроз информационной безопасности приведена в таблице 2.2