48
4. Поддержка и консультация пользователей.
После того, как мы определились со стандартом ЖЦ, пора приступать к
выбору его модели.
Рассмотрим наиболее популярные модели ЖЦ:
- Каскадная модель ЖЦ. Подходит при разработке небольших и простых
ИС, когда есть возможность точно и кратко сформировать все необходимые
требования к ИС. Самым важным недостатком данной модели жизненного цикла
является то, что реальный процесс разработки невозможно полностью уложить
в подобную жёсткую схему, время от времени появляется потребность в возврате
к предыдущим этапам разработки ИС, чтобы пересмотреть и изменить
предыдущие решения. В итоге реальный процесс разработки ИС оказывается
похож на поэтапную модель с промежуточным контролем. Однако выделяют
следующие положительные стороны использования каскадного подхода:
Каждый этап включает в себя законченный набор проектной
документации, отвечающий критериям согласованности и полноты;
Реализуемые в логической последовательности работы дают
возможность планировать сроки завершения всех работ и
подсчитывать затраты.
- Цикличная модель ЖЦ создавалась для преодоления вышеперечисленных
проблем. На этапах анализа и проектирования степень создания технических
решений и удовлетворенность потребностей заказчика оценивалась методикой
создания прототипов. Каждый цикл характеризовал создание работоспособного
фрагмента или версии программы. Такой подход позволял уточнить требования,
цели и параметры проекта, оценить качество разработки, выделить работы
следующего цикла. Таким образом, углубляются и оговариваются детали
проекта, и в результате применяется обоснованный вариант, удовлетворяющий
всем требованиям заказчика, который затем уже доводится до финальной
реализации, но и такая схема не дает возможности оперативно учитывать
возникающие доработки и изменения требований к системе. Согласование
параметров разработки с пользователями делается только в отдельных точках,
49
планируемых после завершения некоторого объема работ, а общие требования к
ИС отражены в техническом задании на все время ее создания. Поэтому
пользователи часто получают систему, которая не полностью удовлетворяет их
реальным потребностям.
- Спиральная. Главная проблема спирального цикла в определении
момента перехода на другой этап. Для ее решения внедряются временные
ограничения на все этапы жизненного цикла, и переход производится в
соответствии с планом, даже если работы по прошлому этапу еще не завершены.
Планирование производится на базе статистических сведений, полученных при
подготовке других проектов, а также из личного опыта разработчиков.;
- Итеративная модель показывает объективно существующий цикл
разработки сложных систем. Она дает возможность переходить на следующий
этап, не дожидаясь окончательного завершения работы на текущем этапе и
решить главную задачу – оперативное и быстрее представить пользователям
работоспособный продукт, тем самым, заранее начиная процесс уточнения
корректировки требований.
Для разработки системы выбираем каскадную модель, так как она
позволяет работать над несколькими этапами разработки одновременно.
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация пилотного проекта.
Стратегия «Опытная эксплуатация пилотного проекта» не подходит, так
как отдел не располагает достаточными ресурсами для длительной эксплуатации
проекта с целью выявления всех возможных ошибок. Стратегия Скачек не
позволяет плавно перейти на использование разработки, узкое место больше
подходит для использования в крупных компаниях. Поэтому в качестве
стратегии внедрения информационной системы выбираем параллельную
50
стратегию, то есть разработанная информационная система будет
использоваться параллельно с используемой технологией до полного
вытеснения последней.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их
описание
Во время разработки и внедрения программного обеспечения могут
возникнуть ситуации, что может привести к появлению рисков. К ряду таких
ситуаций относятся: ошибка в выборе стратегии реализации проекта, не
правильно поставленные цели и задачи, которые могли быть определены
некорректно, смена наружных и внутренних условий, недостаточная
квалификация персонала и тп.
Одна из важных особенностей предлагаемой модели - управление рисками
такого проекта, которое во многом строится на управлении конфигурацией ИС и
процессами проекта.
Существуют следующие типы рисков:
Проектный тип рисков, в него включены риски, которые могут быть
связаны с:
- ошибки в бюджете;
- ошибки в графике работ;
- проблемы с персоналом организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков, к нему относятся риски, связанные с
проблемами реализации технических решений и человеческим
фактором, а именно связанные с неспособностью специалистов
выполнять необходимую задачу.
Тип бизнес-рисков. Этот тип содержит в себе риски, которые связаны
с финансовой поддержкой:
- сокращения бюджета, приводящие не только к сокращению проекта
и его задач, но и к его полному провалу в случае не достижения
основной цели;
51
- риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области и при этом взаимозаменяемых
на сотрудников, не менее соответствующих данным характеристикам.
Основные риски и способы их снижения приведены в таблице 4.
Таблица 4
Главные риски при создании проекта и способы их минимизации:
Вид риска
Снижение риска
Распределение риска
Минимизация
вероятности
возникновения
риска
Технический
Детальный отбор
проектной команды по
уровню квалификации.
Обучение участников
проекта базовым
технологиям проектных
работ, инструментальным
средствам
Зафиксированная
документально
персональная
ответственность
участников проекта, а
также фиксирование всех
изменений в процессе
работы над проектом.
Применение
стандартов
организации на
проектные работы,
подготовка
стандартов проекта.
Организационный
Проведение обучения
участников проекта (курс
"управление проектом"),
тренинги команды,
максимально полная
формализация работы.
Присутствие
представителей заказчика
в рабочих группах.
Присутствие к
команде
администратора
проекта, подробное
распределение
ролей в проекте.
Операционный
Подробное тестирование
разработанного ПО.
Отражение отсутствия
претензий заказчика по
всем этапам работы.
Четкое следование
процедурам
программы качества.
Зависящий от
Подробный анализ всех
Деление проекта на
Проработанная
52
размера проекта
этапов работ,
взаимодействия
участников, организации
работ
несколько частей,
выделение пилотного
проекта по подсистемам
программа качества,
четкое управление
конфигурацией
проекта.
Зависящий от
опыта в ИТ-сфере
Обучение пользователей
и руководства, контроль
следования технологиям
работы.
Утверждение большинства
проектных документов и
всех изменений в
функциональной части
системы.
Создание и
согласование
концепции проекта
на самой ранней его
стадии.
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
В качестве основных направлений обеспечения информационной
безопасности (ИБ) организации применяются:
Обеспечение ИБ при осуществлении документооборота (как
бумажного, так и электронного);
Обеспечение ИБ при осуществлении внутренних видео-конференций
на государственном уровне;
Обеспечение ИБ при проведении работ по модернизации
информационных систем организации;
Обеспечение ИБ при соблюдении правовых и договорных
требований;
К активам учреждениям и отделам, нуждающимся в обеспечении
информационной безопасности относятся следующие:
информационные – персональные данные сотрудников компании,
финансовая документация, данные о коммерческой деятельности
компании, данные о клиентах.
программные – программные средства и комплексы, средства
автоматизации деятельности отделов, операционные системы,
программное обеспечение серверов.
53
материальные архивы - персональные компьютеры, телефоны, АТС,
серверы, мебель, ЛВС.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 5.
Таблица 5
Разграничение прав пользователей
Группа
Модуль «Заявки»
Модуль «База знаний»
Пользователи
Иные сотрудники
Добавление
Чтение
Нет
Сотрудник 1
линии
технической
поддержки
Чтение
Добавление
Изменение
Полный
Чтение
Сотрудники 2
линии
технической
поддержки
Чтение
Полный
Чтение
Системный
администратор
Полный
Полный
Полный
Существуют установленные нормы и процедуры, которым должен строго
следовать каждый сотрудник для поддержания режима безопасности при
подборе и использовании паролей. Для этого есть ряд рекомендаций:
1. Необходимо создавать персональные пароли для обеспечения
подотчетности;
2. Не разглашать и не передавать свои пароли;
3. Не хранить пароли на бумажных носителях, в случае такой
необходимости, хранить бумажные носители в недоступном для иных
сотрудников месте;
4. Необходимо производить смену пароля каждый раз, когда есть
подозрения на доступ к системе или паролям;
54
5. Пароль должен содержать не менее шести символов;
6. Необходимо менять пароль через равные промежутки времени (не
более, чем через 6 месяцев), категорически запрещено использовать
свои старые пароли;
7. Для наиболее важных ресурсов системы необходимо чаще, чем обычно
изменять пароли к определенным системным утилитам;
8. При первом входе в систему рекомендуется изменять изначально
установленный пароль;
9. Избегать попадания пароля в открытые сценарии при входе в систему
с использованием функциональных клавиш или дополнительных
макросов;
При выборе паролей не рекомендуется использовать:
1. Месяцы, года, дни недели и т.д.;
2. ФИО, регистрационные номера автотранспортных средств;
3. ID структурных подразделений;
4. Цифровые обозначения или телефонные номера;
5. Идентификаторы и имена пользователей, групп и системных
ресурсов;
6. Больше двух одинаковых символов, стоящих рядом;
7. Только буквенные обозначения.
Ко всему прочему, эксплуатация антивирусной защиты является одним из
лучших средств, предотвращающих кражу персональных, регистрационных
данных.
2.2. Информационное обеспечение задачи
2.2.1. Характеристика нормативно-справочной, входной и
оперативной информации
Информационная модель включает в себя схему движения входных,
промежуточных и итоговых потоков и функций предметной области.
Под информационной моделью предполагается использовать схему
55
данных (ГОСТ 19.701-90).
Информационная модель изображена на рисунке 10.
Рисунок 10. Информационная модель
Информационная модель отображает схему движения входных,
промежуточных и итоговых потоков и функций предметной области. Также она
объясняет, на базе каких входных документов и какой нормативно-справочной
информации выполняются функции обработки данных и происходит
56
составление конкретных выходных документов. Основываясь на
представленной информационной модели, клиент описывает суть заявки в
приведенной форме. Заявка автоматически определяется в системе, ей дается
статус «Новая заявка». Специалист первой линии при просмотре этой формы
обнаруживает заявку, передаёт специалисту или сам выполняет все нужные
действия для решения указанной проблемы и при успешном исходе обновляет её
статус на «Закрыта».
2.2.2. Характеристика результатной информации
Входной информацией для проектируемой системы являются заявки от
сотрудников, сведения о сотрудниках, сведения об оборудовании, сведения о
служебных записках, а также сведения о наиболее часто происходящих
инцидентах, формируемые на основании опытной эксплуатации. Эти данные
поступают как в цифровом, так и в печатном виде.
Данные из входных документов вносятся в систему путём ручного ввода
данных через специальную форму на сайте организации.
В систему вносятся следующие данные о сотрудниках:
Фамилия, имя, отдел;
Название организации;
Электронная почта;
Номер телефона.
В качестве данных об оборудовании в систему вносятся следующие
данные;
Инвентарный номер оборудования;
Наименование оборудования;
Модель оборудования;
Тип оборудования.
Сведения об инцидентах, а также сведения об отделах содержат только
наименования данных реквизитов.
Основным документом, вносимым в систему, является заявка от
57
сотрудников.
Данный документ содержит следующие реквизиты:
Заголовок заявки;
Описание заявки;
Данные об источнике заявки (ФИО заявителя, название организации
и отдела);
Контактные данные заявителя.
Для обеспечения работы системы предусмотрены справочники,
приведенные в таблице 6.
Таблица 6
Перечень используемых справочников
№
Название
Ответственный
Средний
объём
справочника
(кол-во
записей)
Средняя
частота
актуализации
Средний объём
актуализации
в %
1
Сотрудники
Администратор
80
4 раза в год
20
2
оборудование
Администратор
60
3 раза в год
33
3
Служебные
записки
Администратор
60
Ежедневно
100
2.3 Программное обеспечение задачи
2.3.1. Сценарий диалога
В созданной системе есть 4 вида пользователей:
Администратор системы, имеющий полные полномочия при работе
с системой;
Специалист первой линии – его роль выполняет сотрудник отдела
технической поддержки. Главная обязанность такого сотрудника –