55
Жизненный цикл программного средства представлен каскадной моделью
и базируется на стандарте ГОСТ 34.601-90 Информационная технология.
Комплекс стандартов на автоматизированные системы. Автоматизированные
системы. Стадии создания:
– определение требований к разработке ИС, влияет пользователь
Заказчик и Проектировщик;
– разработка технического задания, влияет Проектировщик;
– проектный эскиз, влияет Проектировщик;
– программирование ИС, влияет Программист;
– отладка компонентов, влияет Программист и Заказчик;
– ввод в действие, влияет Программист и Заказчик.
Для каждой стадии построим соответствующую диаграмму. На рисунке
2.2 представлено описание «Определение требований к разработке ИС»
35
.
Рис. 2.2 Определение требований к разработке ИС
Диаграмма для следующей стадии представлена на рисунке 2.3.
разработка технического задания является одним из важнейших этапов
построения информационных систем, данный документ является руководством к
35
Избачков, Ю. Информационные системы / Ю. Избачков, В. Петров. - Москва: Наука, 2014. – С. 356.
56
действию и инструкцией для разработчиков информационных систем.
Тщательно, четко составленное техническое задание позволяет избегать
путаницы и дает возможность создания качественного программного продукта.
Рис. 2.3 Разработка технического задания
На рисунке 2.4 представлен процесс «Разработка проекта».
Рис. 2.4 Разработка проекта ИС
57
На рисунке 2.5 представлен процесс «Программирование ИС».
Рис. 2.5 Программирование ИС
На рисунке 2.6 представлен процесс «Отладка компонентов».
Рис. 2.6 Отладка компонентов
58
На рисунке 2.7 представлен процесс «Ввод в действие».
Рис. 2.7 Ввод в действие
Следование представленным стадиям, позволит создать качественный,
функциональный программный продукт.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Определим риски на каждом этапе жизненного цикла
36
.
Стадия 1. Определение требований к разработке ИС, на данной стадии
возможны следующие риски:
– риск несогласованности – возможно, что требования, которые
формулирует заказчик не учтены в полной мере разработчиком, реагирование на
данный риск, уточнение и дальнейшее согласование требований;
36
Андреева, В.И. Делопроизводство. Требования к документообороту фирмы (на основе ГОСТов РФ) /
В.И. Андреева. - М.: Бизнес-школа Интел-Синтез; Издание 2-е, перераб. и доп., 2016. – С. 77-81.
59
– риск не понимания – возможно, что заказчик и разработчик говорят об
одном и том, же, однако их формулировки значительно разнятся, что может
привести к неоднозначности интерпретации требований. Реагирование на
данный риск, уточнение, упрощение формулировок, переход к стандартным
определениям, которые не допускают двузначности;
Стадия 2. Разработка технического задания может содержать следующие
риски:
– некорректно составленное техническое задание – может привести к
тому, что разработчик выполнит не совсем тот функционал информационной
системы, который ожидает заказчик. Реагирование на данный вид риска будет
следующий – привлечение сторонних экспертов, которые позволяет разъяснить
заказчику пункты технического задания или самому скорректировать структуру
данного документа;
Стадия 3. Проектный эскиз может содержать следующие риски:
– непонятность составленных моделей, описаний проектных решений,
алгоритмов, по которым работает информационная система. Реагирование на
данный риск следующий – построение моделей с помощью CASE средств,
использование ГОСТа при обозначении основных узлов;
– проект может иметь необоснованные данные или сроки. Реагирование
на данный вид риска сводится к тому, что при формировании проекта помимо
проектировщика должен принимать участие и программист;
Стадия 4. Программирование ИС может содержать следующие риски:
– не выполнение в установленный срок. Реагирование на данный вид
риска – адекватное распределение между программистами задания, привлечение
в случае необходимости сторонних исполнителей;
Стадия 5. Отладка компонентов имеет следующий вид риска:
– не нахождения ошибок. Реагирование на данный вид риска –
привлечение сторонних тестировщиков, которые имеют опыт по тестированию
программного обеспечения;
Стадия 6. Ввод в действие имеет следующий вид риска:
60
– отсутствие возможности установки ИС на оборудование заказчика.
Реагирование на данный риск следующий – доработка информационной
системы, закупка новой компьютерной техники;
– персонал заказчика не принимает информационную систему.
Реагирование на данный вид риска сводится к тому, что проводится обучение и
инструктаж по работе с информационной системе, привлекаются
административные лица для стимуляции персонал.
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Представим средства ИБ и ЗИ, в соответствии с классификацией.
Для формирования прав доступа необходимо определить пользователей
разрабатываемой системы и функции, которые на них возлагаются. Представим
пользователей и их функции по отношению к разрабатываемой системе
37
.
1. Консультант (после контакта с клиентом) – тот, кто влияет на
содержимое карточки задания. Консультант проводит консультацию с клиентом
и выявляет что будет подлежать ремонту (какой тип техники), какие средства и
расходные материалы необходимо использовать, какие сроки сдачи работы и т.п.
На основании проведенной консультации будет формироваться договор на
оказание услуг.
2. Руководитель отдела – тот, кто принимает, анализирует, назначает и
контролирует выполнение задания. Инициация задания исходит от консультанта
при появлении нового договора на выполнение задания (или доработке уже
ранее сделанного). Руководитель на основании договора формирует задание с
указанием содержимого задачи, исполнителя, сроком завершения работы. На
этапе выполнения задания руководитель может отозвать задание для
корректировки или аннулирования. Руководитель проверяет исполнение задания
37
Даниленко А.Ю. Безопасность систем электронного документооборота. Технология защиты
электронных документов / А.Ю. Даниленко. - М.: Ленанд, 2015. – С. 65.
61
и может отправить задание на доработку или подтвердить выполнение задания.
На руководителя также возложена обязанность контроля. На этапе проверки
руководитель проверяет акт о выполнении задания и может отправить задание
на доработку.
3. Исполнитель задания (мастер, специалист технической поддержки и
т.п.) – тот, кто исполняет задание. Исполнитель принимает задание на
разработку, формирует в системе итоговый акт об исполнении задания.
Автором заданий для последующего исполнения является консультант,
который принимает обращения клиентов по тем или иным причинам, его
функции достаточно велики, начиная от рекламы предприятия, поиска
заказчика, заканчивая формированием договора и последующего задания (см.
рис.2.8).
начало
Ввести данные по
новому клиенту
Ввод данных
да
Справочник «Клиенты»
Выбрать клиента
Запрос данных
Составление
договора
Документ
«Договор»
Реестр
договоров
сохранить
Формирование
задания
Справочник «Вид
работы»
Данные для договора
Документ
«Задание»
Реестр заданийсохранить
Проанализировать
ситуацию с заданиями
Отчет по
заданиями
Вывод данных
Прием
выполненного
задания
Продемонстрировать работу
отремонтированной техники
Заказчика все
устраивает
доработка
да
Подписать акт
приема задания
Документ «Акт
приема»
Завершение
работы
Рис. 2.8 Алгоритм работы подсистемы консультанта
62
При работе с клиентами сервисного центра, консультант должен
выполнить его регистрацию в БД системы. При добавлении потенциального
клиента необходимо внести следующие данные:
наименование клиента (может быть физлицо или юридическое);
адрес;
телефон;
контактное лицо;
ИНН;
номер расчетного счета;
банк.
Эти данные затем отображаются в договоре. В договоре помимо данных
клиента должна быть указана следующая информация:
вид работ;
срок действия;
задача;
предполагаемая стоимость.
После заключения договора консультант формирует задание, указав в нем
следующую информацию:
указать заказчика;
дату выполнения;
описание задачи;
ответственное лицо (в большинстве случаев это руководитель
отдела)
38
.
После этого сообщение пересылается руководителю проекта. Для
дальнейшего мониторинга задания консультант может воспользоваться отчетами
системы, может просматривать, в каком статусе находится, созданная им задача:
рассматривается, завершена, не завершена, на подтверждении и т.п. (более
подробно о состояниях рассмотрим ниже).
38
Логинова, А.Ю. Правда об электронном документообороте / А.Ю. Логинова. - М.: Книга по
Требованию, 2015. – С. 108.
63
После выполнения задания из отдела по ремонту от исполнителя
приходит акт выполненных работ, с целью демонстрации заказчику полученных
результатов. Если клиента, что – то не устраивает, то он не подтверждает
выполнение этого задания, и оно отсылается для повторного выполнения
ремонтных работ.
Если клиента все устраивает и проблема была решена, то формируется
документ «Акт приема», который и подписывается клиентом.
На рисунке 2.9 представлен алгоритм работы подсистемы руководителя
отдела по ремонту.
Начало
Получить задание
на отдел
Техника была
ранее в
ремонте
Определить ранее
выполнявшего
задание
исполнителя
да
Реестр заданий
исполнителей
запрос
Организация
доработки
Проанализировать
задание
нет
Сформировать
новое задание
исполнителям
Документ
«Задание
исполнителям»
Контроль процесса
выполнения
задания
Есть
необходимости
вносить
изменение
Изменить данные
задания
да
Прием
выполненного
задания
нет
Передать технику
для демонстрации
клиенту
Завершение
работы
Рис. 2.9 Алгоритм работы подсистемы руководителя отдела
64
При работе с разрабатываемой информационной системой сервисного
обслуживания клиентов руководитель отдела должен будет выполнять
следующие действия:
получение сообщения о задании на свой отдел (при этом руководитель
видит данные о дате создания сообщения, авторе сообщения и описание
проблемы);
если это доработка то руководитель определяет кто ранее выполнял
ремонт и переназначает это задание указанному исполнителю (для этого будет
использоваться реестр заданий, в котором можно по запросу или по поиску
найти соответствующие данные);
если это новое задание, то руководитель осуществляет анализ
проблемы;
определив основные особенности ремонта, руководитель формирует
задание исполнителям;
при формировании нового задания руководителем указывается:
исполнитель задания, количество часов на задание, приоритет задания
(немедленно, в первую очередь, в очередь), сложность и краткая инструкция;
задание можно редактировать, изменяя исполнителя, количество часов,
приоритет, сложность и инструкцию;
задание, которое неактуально, можно удалить;
осуществлять контроль работы исполнителей отдела, анализируя
текущую работу, выполненные и невыполненные задания.
Отчеты системы позволяют осуществлять руководителю анализ и
принимать решения на основании выданной статистике:
степень загруженности отдела;
успешность исполнителя;
количество невыполненных заданий.