59
Не менее 256 Мб оперативной памяти
1,5—2 Гб свободного места на жёстком диске
Разрешение экрана не менее 1024x768 точек
Операционная система Windows XP, Windows Server 2003 или более
новые версии.
Для печати отчетов и выходных документов необходим принтер,
совместимый с компьютером вышеперечисленной комплектации.
В случае варианта многопользовательской работы с системой
понадобится использование одного ПК в качестве сервера для доступа к базе.
Целесообразно разместить эту базу данных на серверном оборудовании, а с
клиентских компьютеров осуществлять подключение к ней через протокол smb
или через ODBC. В качестве серверного оборудования может использоваться
компьютер типа IBM PC серверного типа.
Так как клиентские компьютеры будут подключаться к серверной базе
данных, и сервер и клиентские машины должны функционировать в локальной
сети. Это может быть как одноранговая сеть, так и сеть с доменной
организацией.
Для работы данной информационной системы можно использовать
существующее техническое обеспечение, т.к. оно удовлетворяет всем
предъявляемым ИС требованиям.
60
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий
методологии проектирования информационных систем. Жизненный цикл
информационной системы представляет собой непрерывный процесс,
начинающийся с момента принятия решения о создании информационной
системы и заканчивается в момент полного изъятия ее из эксплуатации.
Жизненный цикл информационной системы охватывает все стадии и
этапы ее создания, сопровождения и развития:
исследование предметной области с последующим формированием
функциональной и информационной моделей объекта, для которого
предназначена информационная система;
проектирование системы, заключающееся в разработке проектных
решений, удовлетворяющих всем требованиям ТЗ;
разработку системы (в том числе программирование и тестирование
прикладных программ на основании проектных спецификаций подсистем,
выделенных на стадии проектирования);
тестирование информационной системы и выявление сбоев с
последующим их устранением;
эксплуатацию системы и ее сопровождение;
развитие системы.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в
некоторых случаях и процессы разработки.
Среди наиболее известных стандартов можно выделить следующие:
ГОСТ 34.601-90 - распространяется на автоматизированные
системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте
содержится описание содержания работ на каждом этапе. Стадии и этапы
61
работы, закрепленные в стандарте, в большей степени соответствуют каскадной
модели жизненного цикла .
ISO/IEC 12207:1995 - стандарт на процессы и организацию
жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не
содержит описания фаз, стадий и этапов .
Custom Development Method (методика Oracle) по разработке
прикладных информационных систем - технологический материал,
детализированный до уровня заготовок проектных документов, рассчитанных
на использование в проектах с применением Oracle. Применяется CDM для
классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также
для технологий "быстрой разработки" (Fast Track) или "облегченного подхода",
рекомендуемых в случае малых проектов.
Rational Unified Process (RUP) предлагает итеративную модель
разработки, включающую четыре фазы: начало, исследование, построение и
внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате
которых выпускается версия для внутреннего или внешнего использования.
Прохождение через четыре основные фазы называется циклом разработки,
каждый цикл завершается генерацией версии системы. Если после этого работа
над проектом не прекращается, то полученный продукт продолжает
развиваться и снова минует те же фазы. Суть работы в рамках RUP - это
создание и сопровождение моделей на базе UML.
Microsoft Solution Framework (MSF) сходна с RUP, так же включает
четыре фазы: анализ, проектирование, разработка, стабилизация, является
итерационной, предполагает использование объектно-ориентированного
моделирования. MSF в сравнении с RUP в большей степени ориентирована на
разработку бизнес-приложений.
Extreme Programming (XP). Экстремальное программирование
(самая новая среди рассматриваемых методологий) сформировалось в 1996
году. В основе методологии командная работа, эффективная коммуникация
между заказчиком и исполнителем в течение всего проекта по разработке ИС, а
62
разработка ведется с использованием последовательно дорабатываемых
прототипов.
Стандарт ISO/IEC серии 15288
В стандарте ISO/IEC 12207 не предлагается конкретной модели
жизненного цикла и методов разработки, его рекомендации являются общими
для любых моделей жизненного цикла. Под моделью обычно понимается
структура, определяющая последовательность выполнения и взаимосвязи
процессов, действий и задач на протяжении жизненного цикла.
Остановимся на модели Rational Unified Process (RUP), которая
предлагает итеративную модель разработки, включающую четыре фазы:
начало, исследование, построение и внедрение. Она полностью определяет
наши требования и реализует нужный подход.
Из всех имеющихся стандартов, наиболее оптимальным будет ISO
12207 -99. Выбор пал именно на этот стандарт, в связи со следующими
факторами: Во-первых, стандарт четкое не регламентирует
последовательность процессов в каждом этапе, что позволяет самостоятельно
выбирать подходящие для себя процессы. Во-вторых, стандарт охватывает все
этапы более полно, нежели остальные стандарты. В-третьих, ISO 12207-99 не
указывает на этапы, а лишь регламентирует их, что позволит разработчику
самостоятельно управлять жизненным циклом. В связи с небольшим объемом
проектных работ, а также характером проекта выберем каскадную модель для
описания жизненного цикла. В соответствии с этим в него будут входить
следующие этапы:
формирование требований;
проектирование;
реализация;
тестирование;
ввод в действие;
эксплуатация и сопровождение.
63
В качестве стратегии внедрения ИС в ООО «Итака» был выбран
«Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий убедиться
в применимости и эффективности предлагаемой системы до eѐ окончательного
внедрения, обучить сотрудников компании работе с системой, а также
определить и спланировать организационные и технические мероприятия на
этапе промышленного внедрения. Пилотный проект позволяет уменьшить
затраты и ускорить полномасштабное внедрение.
Данная стратегия внедрения информационной системы была выбрана,
потому что это наиболее часто используемая компаниями стратегия. Такой
подход снижает риск и наиболее надежен.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Проект разработки информационной системы автоматизации и
обеспечения информационной безопасности документооборота, как любой
другой проект разработки программного обеспечения, содержит в себе много
неопределенных моментов, которые влекут за собой риски реализации проекта.
Этап внедрения часто тоже бывает продолжителен, если заказчик не
может сразу остаться довольным продуктом, да и сами сотрудники компании-
заказчика могут с недоверием отнестись к новому ПО.
Для сокращения рисков в данной ситуации проводят качественное
обучение сотрудников еще до периода эксплуатации, готовят отдел
сопровождения и поддержки, понимают, что может произойти в процессе
эксплуатации и как можно найти верное решению. Иметь возможность
ответить на возникающие вопросы или открыть горячую линию для решения
поступающих проблем.
Среди явных проблем процесса создания проекта можно выделить
такие:
Корректировка требований относительно процесса создания;
Разделение ответственности за реализуемую работу и ее результат;
64
Доступность потока мелких, срочных, приходящих требований,
отвлекающих программистов и управленцев от базового направления работ.
Срыв срока, повышение расходов, потери качественного уровня.
Чтобы реализовать успешную организацию процесса создания,
подготовлена универсальная процедура создания проектов.
Модели, методики и подходы универсального управления проектами
имеют свое развитие в рамках сложных технических проектов, которые
заключаются в реализации больших программных комплексов. Универсальное
управление можно рассматривать как некую платформу, которая находится в
рамках нескольких методик контроля инновационными, а самое важно, ИТ
проектами. Базовая суть универсального управления проектами описана в
работах Дж. Хайсмита [1], Г. Аллемана [8], Г. Чина [11]. Сравнение разных
прикладных методологий универсального управления новейшими проектами
также есть в трудах К. Лармана [27] и П. Абрамсона и других [5]. Моментный
подход к определяю наилучшей методики универсального управления
проектами указан ив работе А.С.Коха [3].
Дж. Хайсмит выделяет базовое качество данного подхода так: «Гибкость
(аgility) - это возможность сразу и создавать, и отвечать на корректировки,
создавая прибыль в изменчивых условиях экономики. Гибкость становится
способностью держать баланс между стабильностью и хаосом» [16]. Также он
пишет, что: «Часто многие склонны верить, что подвижность говорит об
отсутствии структуры. Но такое отсутствие порождает хаос. Также, избыток
некой упорядоченности несет за собой жесткость. Теория сложности описывает
то, что процесс создания инновации методами, которые не определены заранее,
часто реализован в точке соприкосновения порядка и хаоса, гибкости и
стабильности. По словам ученых, реализация нового возможна на границе
хаоса [16]. Но на нахождение такого баланса между порядком и хаосом и будут
направлены все возможности универсального управления проектами. Причем
следует оно от упорядоченности процессов, инструментов и методик, которые
есть в традиционных школах проектного управления в рамках деконструкции,
65
деструктуризации множественных упорядоченных реализованных условий
протекания проектов, к выработке понятных и логичных (направленных на
персонал методов и инструментов, которые имеют возможность плавно
приспособиться к изменчивым условиям). Если классическими параметрами
управления проектами описывались планирование, улучшение и отслеживание,
то универсальное управление проектами основными усилиями будет считать
естественную эволюцию и приспособление.
В 2001 году основатели и последователи части близких по духу и сути
методик управления ИТ-проектами создали свод правил универсального
контроля проектами. Данный свод описал 4 базовые идеи и 12 параметров [17].
Создатели свода правил, почитатели методик экстремального
программирования, скрама, адаптивного создания проектов и т.п., сознательно
не стали сводить универсальное управление проектами к моделям,
инструментарию и средствам, но отразили его в виде неких адаптационных
идей и принципов, которые нужны для понятного творческого воплощения в
контексте отдельной ситуации. Суть и идеи универсального проектного
управления не нужно сводить к сложившимся законам и правилам.
Базовая основа универсального управления заключена в:
Персоналии и их работа важнее, чем инструмент и процесс;
Применяемое ПО (в общем случае - ценный для клиента продукт
или реализуемая услуга) важнее, чем собранное документальное
сопровождение (или контроль плана бюджета);
Работа с заказчиком важнее, чем обязательства по контракту;
Реакция на коррективы важнее, чем простое следование плану.
Суть универсального управления проектами состоит их:
Удовлетворенность клиента благодаря оперативной и надежной
разработки продукта, который имеет значение для клиента;
Позитивное отношение к корректировке требований к продукту,
даже на финальной стадии, если это имеет значимую ценность для клиента и
ведет к росту конкурентных качеств продукта;
66
Создание и поставка отдельно работающих модулей или
обновленных версий ПО (ежемесячно, еженедельно или чаще);
Полноценное общение с заказчика с разработчиками в рамках всего
проекта, выходящее за рамки только контрактных обязательств;
Повышенная мотивация участников проекта, имеющих все
требуемые материалы и средства, поддержку и доверие;
Персональный разговор, как базовый метод передачи данных в
рамках проекта;
Функционирующий и ценный для клиента продукт как лучший
индикатор успеха проекта;
Все участники проекта, в особенности создатели и вдохновители,
должны без проблем поддерживать конкретный темп работы на требуемый
срок;
Рост технического мастерства исполнителей и улучшение самого
продукта;
Переход к простоте, чтобы не реализовывать лишнюю работу;
Самоорганизация и автономия на уровне команды проекта,
оптимальные тех. требования, дизайн и архитектура реализуются у лучше
организованной команды;
Доступность изменений при смене обстоятельств.
Принцип схемы универсального управления проектами признается
циклическая модель ЖЦ проекта, которая разбивает проект на несколько
процедур. «Каждая процедура выглядит как некий программный файл в
миниатюре, и состоит из задач, которые нужны для реализации мини-прироста
по скорости работы: изучение требований, составление плана, проектирование,
написание кода, проверка, документирование. Каждая отдельная процедура
зачастую не так оправдана для реализации обновлённой версии продукта, тут
понимается, что сам по себе проект готов к реализации по факту каждой
процедуры. В рамках окончания каждой процедуры команда проводит
переоценку основных задач разработки» [14].
67
Модель из рис. 2 описывает, что проект проводится некое количество
циклов (процедур), и любой цикл имеет 4 фазы – определение требований,
подготовка проекта, реализация и оценивание. Любой следующий цикл ведет к
корректировке требований, изучению содержания, оптимизации продукта и
процессов создания проекта. В реальности процедурная природа
универсального проекта сложнее, и предполагает доступность перехода с этапа
на этап, что часто отмечается в виде названной хаотической модели ЖЦ
проекта.
Такие понятия о ЖЦ проекта предполагают сторонний взгляд на то, что
есть в проекте. Понятно, что в отличие от классического управления проектами
с неизменно утверждёнными требованиями к итогу и границам содержания,
универсальное управление включает требования и содержание к изменённым
динамически [10]. Сама суть универсального управления проектами
соответствуют концепциям развитых и доступных проектов [7;6]. Если
классические терминальные проекты включают неизменное определение
границ ЖЦ и сути проекта, при достижении которых проект завершается, то
развивающиеся проекты всегда открыты для дальнейших корректив и
изменений. Открытые проекты вообще отражают содержание лишь в рамках
общих направлений и индексов, которые корректируют принцип выполнения.
В нашем проекте можно выделить следующие основные риски на
каждом этапе разработки (таблица 2.1)
Таблица 2.1
Основные риски на этапах реализации системы
Этап
Риск
Мероприятия
Предпроектное
исследование
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия в
проекте
Неформализуемая задача
(невозможно
автоматизировать те или
иные бизнес-процессы или
стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область действия
проекта с целью выделения
отдельных задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и предложить
комплекс мероприятий по их
реорганизации.
68
Продолжение таблицы 2.2
Проектирование
базы данных и
приложения
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов
решения поставленных
задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям;
Разработка базы
данных и
приложения
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Увеличить количество
привлекаемых специалистов
Недостаточно опыта у
персонала заказчика,
который будет
эксплуатировать систему
Предоставить заказчику услуги
собственного специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность действий
персонала исполнителя и
сотрудников предметных
областей;
- трудности с обучением
персонала заказчика из-за
нежелания работать сновой
системой;
- отсутствие поддержки
внедрения ИС со стороны
отдельных
ключевыхучастников
проекта;
- неучастие руководителей
высшего звена в проекте.
- проведение обучения
персонала заказчика работы с
системой;
- составление плана внедрения
ИС;
- доведение до персонала
заказчика смысла внедрения
автоматизированной системы;
- активное вовлечение высшего
руководства в проект, активное
взаимодействие с ним в ходе
проекта и своевременное
принятие решений,
необходимых для нормальной
реализации проекта.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой ИС включает в
себя следующие аспекты: