47
ИС;
– разработка методологии реализации функций
управления с помощью ИС и описанием регламента действий
аппарата управления.
– оформление и утверждение технического проекта.
– выбор или разработка математических методов или
алгоритмов программ;
– корректировка структур баз данных;
– разработка техно-рабочего проекта ИС.
– создание документации на доставку и установку
программных продуктов;
– описание реальных компонент ИС;
– выбор комплекса технических средств с
документацией на ее установку.
3)Разработка приложений, тестирование, написание
документации:
– подготовка учебных и текстовых материалов;
– получение и установка технических и программных
средств;
– тестирование позволяет выявить наличие ошибок
или.
4) Внедрение:
– подписание и сдача актов приемки-сдачи работ;
– обучение работников для который разрабатывался
этот модуль;
– ввод разработанного модуля.
5) Эксплуатация и сопровождение:
– повседневная эксплуатация;
48
– общее сопровождение всего проекта.
ГОСТ 34 «Единая автоматизированная система учета кадров
всех государственных предприятий» - регламентирует процесс
автоматизации учета кадров на всех стадиях.
Стандарт ISO/IEC 15288 «Информационная технология.
Системная инженерия. Процессы жизненного цикла имеют все шансы
применяться рекурсивно, однократно или многократно, как любым ее
элементам, так и к по отношению к системе в целом, адаптируемых к
требованиям заказчика, а также применяться для систем массового и
единичного производства. Первым международным стандартом,
являются процессы жизненного цикла систем, в котором
рассматриваются методологические принципы проектирования систем
с точки зрения организации процессов жизненного цикла. Реализация
общих процессов и основы моделирования, составляющих жизненного
цикла систем обеспечивает документ.
Стандарт Microsoft Solutions Framework (MSF) - это набор
правил деятельности и принципов, в определеной степени
ориентированный на развития информационной инфраструктуры и
проекты разработки ПО.
Стандарт RUP Rational Unified Process (RUP) – стандарт,
который был создан компанией Rational Software, методология
разработки программного обеспечения. В значительной степени
соответствует нормативным документам и стандартам, связанным с
оценкой технологической зрелости организаций-разработчиков (CMM,
ISO 12207, ISO 9000, и др.) и процессами жизненного цикла
программного обеспечения.[11]
Стандарт COBIT - определяет набор универсальных задач
49
управления ИТ. Основная идея COBIT заключается в том, что он
предлагает модель, дающую возможность взаимосвязывать ИТ-
процессы и бизнес-цели.
Международная ассоциация аудита и контроля за ИС
разработала методологию контроля, управления, и аудита
информационных систем и позволяет:
– Осуществить сравнение уровня развития ИТ с
другими предприятиями отрасли и ИТ-аудит;
– Организовать мониторинг работы службы ИТ,
привязанный к задачам и целям бизнеса;
– Построить работу службы ИТ на процессной основе.
Четыре последовательных этапа включается в себя процедура,
это такие как: оценка механизмов управления; детальное тестирование;
идентификация и документирование; тест соответствия.[31]
Идентификация и документирования является первым этапом,
который осуществляет идентификацию существующих механизмов
управления и документирования процедур путем расспрашивания
сотрудников и руководства с целью выяснения таких вопросов, как:
существующие механизмы управления; политики и процедуры;
требования нормативной базы; распределение ролей и ответственности;
требования бизнеса и ассоциированные с ними риски; организационная
структура.
Следующий этап, это оценки механизмов управления, в котором
при выполнении задач управления, с их критическими факторами
успеха и промышленными стандартами, их пригодность сравнивается с
установленными критериями и целесообразность осуществляется
оценка эффективности существующих механизмов. Механизмы
50
управления на следующем этапе могут быть протестированы в
соответствие установленным процедурам при помощи методов
экспертных оценок. Далее аудитору требуется убедиться в том, что
ответственность и подотчетность верно определены, существующие
ИТ-процессы документированы. А также там, где необходимо,
предусмотрены компенсирующие механизмы управления.
Для принятия гарантии пригодности существующих механизмов
управления и для решения задач управления потребуется тест
соответствия, или так называемый Этап аудита. Проверка производится
при получении косвенных и прямых свидетельств надлежащего
выполнения установленных процедур управления за оцениваемый
период. Также на этом этапе устанавливается объем дополнительной
работы и уровень детального тестирования, осуществляется
ограниченное исследование адекватности результатов процессов
управления, желательный для принятия гарантий адекватности ИТ-
процесса.
Заключительный этап, которого является обоснование и оценка
рисков невыполнения задач управления с помощью экспертных оценок
и применения аналитических методов- это детальный тест
(заключительный этап аудита). Стимулировать руководство к
реализации корректирующих действий для повышения качества
состоянии системы управления ИТ является его главной ролью или
целью. На этом этапе аудитор создает документирование недостатков
механизмов управления, уязвимостей и угроз, представляющие
результатом этих недостатков, потенциальных и реальных результатов
реализации угроз с помощью причинно-следственного анализа и
проведения сравнительного тестирования.[23]
Методика Oracle CDM является развитием CASE-технологий.
51
Протекающие в процессе жизненного цикла информационной
системы Методика Oracle CDM реализует следующие процессы:
– определение производственных требований;
– определение технической архитектуры;
– реализация и проектирование модулей;
– переход к новой системе;
– конвертирование данных;
– исследование существующих систем;
– обучение;
– определение технической архитектуры;
– построение и проектирование базы данных;
– тестирование;
– сопровождение и подтверждение.
Для разрабатываемого дополнительного программного модуля
больше подходит стандарт ISO/IEC 12207 и ГОСТ 34.601-90. Данные
стандарты содержат набор задач, процессов и действий, охватывающие
при максимальной адаптируемости, наиболее широкий спектр
возможных ситуаций. Стандарт имеет предельно мало описаний,
направленных на проектирование БД.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Процесс создания программного обеспечения связан с
определенными рисками, возникающими на всех этапах работ - от
этапа Управления требованиями и до внедрения готового продукта.
Процесс контроля, выявления и минимизации последствий
внезапных событий или устранения является процесс контроля
52
рисками.[17]
В большинство моментов риски вне зависимости от подходов к
управлению ими, от категорий и источников, можно разобрать с
нескольких различных позиций:
– Придельные и собственный риски.
– Статический и динамический риски
– Систематический и несистематический риски.
Оценка риска отдельной операции, финансового инструмента
отдельно от контекста выполнении портфеля или операции, в который
входит финансовое средство является собственным риском.
Величина, в которой изменится оценка риска деятельности,
портфеля в основном при дополнении в них оцениваемой операции или
финансового инструмента является предельном риском. Так же
предельный риск в некоторых моментах может быть отрицательной
величиной. При реализации некоторых процедур управления рисками, а
именно предельный риск показывает более высокий интерес, но для
получение его технически более затруднительно, чем получение
собственного риска.
Риски случайных колебаний результатов деятельности, как в
худшую, так и в лучшую строну не умеющие значимо подействовать на
жизнеспособность организации являются динамические риски. Чаще
всего, это спекулятивные риски, которые при утверждении их
организацией очень слабо взаимосвязываются друг с другом.
Риски, связанные с факторами, которые считаются значимыми в
рамках модели являются систематическими рисками. Данные риски не
должны быть существенно снижены в рамках большого портфеля или с
течением времени, в противном случае факторы, определяющие их,
53
должны быть проигнорированы, и данные риски могут быть
классифицированы как бессистемные. Так же систематические риски
являются основным предметом исследований в области оценки рисков
и управления ими.
Риски, источники и чувствительность к которым не
рассматриваются в рамках модели оценки и управления рисками
являются несистематическими рисками. При построении адекватной
модели несистематические риски не должны приводить к каким-либо
существенным потерям, а при большом их количестве не должны быть
связаны друг с другом. Применительно к данным рискам должен
применяться закон больших чисел - выявленные в ходе анализа
отдельных элементов деятельности организации, отдельных
составляющих определенного портфеля ценных бумаг, в течение
короткого промежутка времени в целом по организации, портфелю или
с течением времени их вклад в возможные потери будут стремиться к
нулю. Несистематические риски обычно игнорируются при решении
задач оценки рисков и управления ими.
На этапах внедрения системы и ручного проектирования
присутствует риск возникновения дефектов в программном продукте
из-за ошибок, допущенных управлением на различных этапах
разработки процедурной системы. Классификация результатов
дефектов приведена в таблице 2.2.
Таблица 1.5
Характеристики дефектов программного продукта
Планирование
procedure
работ
Дефекты, обусловленные
выездных
реальной сложностью проекта
Проектирование
нажатие
архитектуры
системы
Ошибки
then
планирования и
системного
должен
проектирования
программного
глобальном
средства
54
Детальное проектирование
инвентарного
программного обеспечения
Алгоритмические и
системные и дефекты и ошибки
оценка
проекта
Тестирование
учет
программного
обеспечения
Программные и
алгоритмические
begin
ошибки
программного
public
средства и
документации
Разработка
таблица
документации
Дефекты и ошибки
таким
обобщающих документов
Разработка требований
procedure
к
программному обеспечение
Дефекты исходных
поиска
требований заказчика
Этапы
обеспечения
возникновения ошибок или
дефектов
текущему
Типы ошибок
procedure
программного
средства, первичных
then
дефектов и
документации
Кодирование программного
обеспечения
ошибки
begin
компонентов и
документов
procedure
программного средства
и программные
поэтому
дефекты.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Создание систем информационной безопасности в ИС
базируется на следующих принципах: принцип непрерывного развития
системы, обеспечение всех видов средств борьбы с вредоносными
программами, обеспечение мониторинга функционирования системы
защиты системный подход, разделение и минимизация полномочий,
полнота контроля и регистрации попыток, обеспечение надежности
системы защиты, экономическая целесообразность.[9]
В результате решения задач информационной безопасности
разрабатываемая ИС должна обладать следующими основными
характеристиками:
55
– Иерархические полномочия субъектов доступа к
компонентам ИС.
– Обязательный контроль информационных потоков,
как в передаче по каналам связи на большие расстояния, так и
локальных сетях.
– Наличие информации различной степени
конфиденциальности.
– Наличие средств восстановления систем
информационной безопасности.
– Обеспечение криптографической защиты
информации различной степени конфиденциальности при
передаче данных.
– Наличие механизма предотвращения
несанкционированного доступа.
– Обязательная целостность информации и
программного обеспечения.
В основу правового обеспечения входят как нормативные акты,
так и правила компании, объекты и услуги, различного рода методики,
реализующие функции защиты информации, обеспечивающие
деятельность пользователей при выполнении ими своей работы в
условиях серьезных требований конфиденциальности.
Все информационные системы потенциально подвержены
рискам безопасности, например, такие как: сбою в работе системы или
краже данных и другие. Поэтому разработчики ИС своим
пользователям должны позаботиться о ее безопасности.[30]
В комплексной защите информации в компьютерных сетях
предполагается реализацию четырех уровней защиты:
– административно-организационная (определяется,
56
кто и какую информацию может собирать или хранить;
устанавливаются должностные инструкции; способы доступа к
ней и условия её распространения, обязанности и права
работников, их компетенция и ответственность);
– программное и аппаратное обеспечение (применяется
процедура идентификации пользователя, обеспечивающая доступ
к программному обеспечению и данным). Аппаратная защита
может быть выполнена в виде ключа, кодовой карты, и другие.
Самое уязвимое место в системе информационной безопасности-
это персонал. Персонал обычно отказываются от использования
каких-либо дополнительных защитных средств, которые создают
им в работе неудобства. Поэтому использование аппаратной
защиты нуждается в административной поддержке;
– правовые (незаконное использование секретных
сведений и данных, составляющих объект авторского права,
преследуется по закону; правовые законы, нормы);
– криптографические (шифрование данных для
сокрытия их смысла от злоумышленника). До тех пор, пока
пользователь не идентифицирован ключом, данные ему
недоступны.
2.2. Информационное обеспечение задачи
2.2.1. Характеристика нормативно-справочной, входной и оперативной
информации
Созданная структура базы данных предусматривает главные правила
целостности. Любой объект идентифицируется уникальным ключом и
разрабатывается система внешних ключей. База данных не содержит