48
Среди наиболее известных технических регламентов можно выделить
следующие регламенты, представленные на рисунке 2.2 [21].
Рисунок 2.2 - Технические регламенты
В стандарте ISO/IEC 12207 не предлагается конкретной модели
жизненного цикла и методов разработки, его рекомендации являются общими
для любых моделей жизненного цикла. При этом, модель — это структура,
которая определяет последовательность выполнения и взаимосвязи процессов,
действий и задач на протяжении всего жизненного цикла [21].
Для реализации настоящего проекта выбран стандарт ISO/IEC 12207, так
как он не регламентирует и не содержит описания содержаний работ на каждом
этапе.
В настоящее время обычно говорят о двух основных моделях жизненного
цикла – это каскадная и спиральная модели. В каскадной модели жизненного
цикла процесс разработки осуществляется поэтапно, шаг за шагом. Переход к
следующему этапу может произойти только после завершения предыдущего
этапа. В спиральной модели жизненного цикла разработка проходит по
нарастающей. На начальном этапе разработанная система имеет высокий
уровень абстракции, а на следующих витках спирали эта разработка все больше
и больше конкретизируется. На каждом витке создается прототип системы [21].
Для жизненного цикла данного проекта была выбрана каскадная модель,
так как для разрабатываемой программной системы больше подходит поэтапная
разработка.
Как видно из рисунка 2.3, переход к следующему этапу разработки
выполняется только после завершения всех работ на предыдущем этапе,
49
включая подготовку полного пакета документации, которая будет достаточна
для того, чтобы работа могла быть продолжена другой группой разработчиков.
Кроме того, в соответствии с выбранной схемой есть возможность планирования
сроков завершения работ и затрат на их выполнение [19].
Рисунок 2.3 - Каскадная схема разработки ПО
Каскадный метод разработки хорошо подходит для построения таких
систем, в которых в самом начале разработки можно с достаточной степенью
точности и полноты сформулировать все требования, с целью предоставления
разработчикам свободы реализации проектируемых систем как можно лучше с
технической точки зрения. Однако, если в середине разработки обнаруживаются
ошибки, допущенные в начале проектирования, то необходимо прибегать к
энтраверсии проекта и фактическая схема каскадной модели приобретает
несколько другой вид, который представлен на рисунке 2.4 [19].
Рисунок 2.4 - Реальный процесс разработки ПО по каскадной модели
Таким образом, можно сделать вывод, что каскадный метод наиболее
подходит к конкретной разработке.
50
Существуют следующие основные стратегии внедрения системы [21]:
1. Параллельная стратегия - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
2. Скачок. Эта стратегия привлекательна, но не рекомендуется.
3. Пилотный проект. Это наиболее часто используемая стратегия.
«Пилотный проекта» — это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически все
предприятия применяют эту тактику сегодня.
4. Узкое место. «Узкое место» — это малая часть производственного
процесса. При использовании похода «узкое место» план внедрения
выполняется только для «узкого места» и для людей, работающих в нем.
Точность данных повышается только для изделий в этом «узком месте»;
переподготовка- только для людей, работающих в нем; анализ эффект-затрат
делается только для него и т.д.
При внедрении данного проекта будет использована стратегия «Пилотный
проект», как наиболее оптимальная стратегия в данной ситуации.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Каждый проект по проектированию информационной системы
предприятия включает всегда множество задач, которые связаны с общим
управлением проектом, разработкой программного обеспечения, внедрением,
причем каждая из перечисленных задач сама по себе является проектом с
присущими ему особенностями. Поэтому в ходе разработки информационной
системы существуют различные риски нескольких категорий [16].
Риски заказчика могут быть связаны с неполным достижением
поставленной цели проекта и недостаточно эффективно израсходованными
средствами. В свою очередь, риски исполнителя сопряжены с возможностью
резкого превышения итоговой себестоимости работ по сравнению с планом. При
51
необходимости ведения параллельных и часто принципиально отличающихся по
своему характеру работ приводит к тому, что во много раз возрастает уровень
риска проекта [16].
Наиболее характерные риски проектов и методы из минимизации
приведены в таблице 2.1.
Таблица 2.1
Возможные риски проекта и способы их минимизации
Виды рисков /
варианты
менеджмента
рисков
Снижение видов риска
Снижение вероятности
возникновения риска
1
2
3
Риски, которые
связаны с
масштабом
проекта
Следует проводить детальный
анализ каждого этапа работ и
организации работ,
координировать взаимодействия
участников
Детально проработанная
программа качества,
отлаженное управление
конфигурацией проекта,
специально разработанные
процедуры взаимодействия
участников
Риски, связанные
с недостаточным
опытом в сфере
информационных
технологий
Организация обучения всех
групп пользователей, включая
руководство, соблюдение
технологий работы.
Разработка и утверждение
концепции проекта на самой
ранней его стадии.
Технические
риски проекта
Строгий отбор сотрудников в
проектную команду по
квалификационным критериям.
Разработка стандартов проекта
на основе используемых
52
Продолжение таблицы 2.1
1
2
3
Обучение участников
применяемым технологиям
проектных работ,
инструментальным средствам.
стандартов предприятия на
проектные работы
Организационные
риски проекта
Обучение участников проекта по
курсу «Управление проектами»",
тренинги команды, полная
формализация деятельности
команды
Детальное распределение
ролей в проекте, включение в
команду администратора
проекта
Операционные
риски проекта
Многократное и многошаговое
тестирование созданных
программных продуктов,
тщательная экспертиза
подготовленных документов
Строгое выполнение процедур
программы качества,
разработка системы
менеджмента качества
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для обеспечения организационно-правовых и программно-аппаратных
средств компании ООО «ДанАвто» необходимо дать полную и обоснованную
характеристику проектируемым для решения задач средствам обеспечения
информационной безопасности и защиты информации [14]:
1. Защита от внутренних угроз (разработка внутренней политики
безопасности, разграничение прав доступа к информации и так далее). Для этого
необходимо определить группы пользователей разрабатываемой системы и
назначить им соответствующие права доступа к папкам и модулям системы,
определить требования к паролям и частоте их смены, а также другие параметры
использования информационной системы. Подробные права пользователей
описаны в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы пользователей/Действия
Администратор
Менеджер продаж
1
2
3
Редактирование справочников
Чтение/Создание/
Удаление
Чтение/Создание/
Удаление
53
Продолжение таблицы 2.2
1
2
3
Оформление поставок запчастей
Чтение/Создание/
Удаление
Чтение/Создание/
Удаление
Обработка заявок клиентов
Чтение/Создание/
Удаление
Чтение/Создание/
Удаление
Оформление выдачи заказов клиентам
Чтение/Создание/
Удаление
Чтение/Создание/
Удаление
Формирование сопроводительных
документов
Формирование,
экспорт
Формирование,
экспорт
Формирование отчетов
Формирование,
экспорт
Формирование,
экспорт
Учет пользователей и их прав
Чтение/Создание/Уда
ление
Запрет доступа
2. Защита от внешних угроз (безопасность каналов, протоколы,
аутентификация, шифрование, безопасная пересылку ключей и т.д.).
Состав проектируемых программных и аппаратных средств может быть
оформлен в виде таблицы с содержанием граф:
нормативно-правовые акты организации, стандарты (международные
и отечественные);
антивирусные и антишпионские средства;
проактивная защита от внешних угроз и защита внешнего периметра
защита от сетевых угроз
защита от инсайдерских угроз и защита информационных ресурсов;
физическая защита информации.
3. Обоснование выбора политики безопасности, а также тех или иных
программных и аппаратных средств, где должно быть:
- обоснование организационно-правовым методам и программно-
аппаратным средствам (средства должны быть конкретные,
лицензионные, с требованиями соответствующих стандартов);
- обоснование различным аспектам защиты системы: защита базы,
резервное копирование, защита от хищения данных, защита от порчи
данных, защита от инсайдерских угроз, уровни или сферы защиты.
54
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
На рисунке 2.5 представлена информационная модель задачи. Входные
данные:
сведения о заявках клиентов на поставку запчастей;
сведения о клиентах;
справочная информация: категории запчастей, марка и модель
автомобиля, отделы, должности;
сведения о запчастях;
сведения о продаже запчастей;
ценовая политика магазина (сведения о накопленной сумме продаж,
которая дает право на получение скидки);
сведения о сотрудниках магазина;
идентификационные данные пользователей.
Все входные данные будут введены в специальные формы ввода данных.
Выходные формы:
- реестр клиентов;
- сведения о накопленных скидках по каждому клиенту;
- сведения о покупках клиентов;
- статистика работы с клиентами;
- список выполненных предварительных заказов;
- список невыполненных предварительных заказов.
Основные формы редактирования данных представлены на
информационной модели.
Выходные данные также представлены на информационной модели и
включают отчетные формы. Все отчеты будут формироваться с помощью
информационной системы. Входными данными для формирования отчетов
являются все таблицы базы данных.
55
Рисунок 2.5 – Информационная модель
56
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Классификаторы представляют собой систематический свод, перечень
каких-либо объектов, позволяющий находить каждому из них свое место, и имеют
определенное (обычно числовое) обозначение [5].
В информационной системе обработки заявок ООО «ДанАвто»
используются локальные классификаторы, представленные в таблице 2.3.
Таблица 2.3
Классификаторы и системы кодирования
Наименование кодируемого
множества объектов
Система
кодирования
Система
классификации
Вид
классификатора
Отделы
Порядковая
Отсутствует
Локальный
Должности
Порядковая
Отсутствует
Локальный
Марки и модели автомобилей
Порядковая
Отсутствует
Локальный
Категории товаров
Порядковая
Отсутствует
Локальный
2.2.3. Характеристика результатной информации
В ГОСТ 34.003-90 дано определение выходной информации – это
информация, получаемая в результате выполнения функций автоматизированной
системы и выдаваемая на объект ее деятельности, пользователю или в другие
системы.
Информационная система обработки заявок в магазине по продаже
автомобильных запчастей ООО «ДанАвто» должна позволять формировать
следующую результатную информацию:
1. Реестр клиентов.
2. Сведения о накопленных скидках по каждому клиенту.
3. Сведения о покупках клиентов.
4. Статистика работы с клиентами.
5. Список выполненных предварительных заказов.
6. Список невыполненных предварительных заказов.
На рисунках 2.6-2.9 представлены макеты отчетов.
57
Реестр клиентов
ФИО
Адрес
доставки
Телефон
Электронный
адрес
Наименование
Год
выпуска
Тип
кузова
Объем
двигателя
Номер
диск
онтной
карты
Количество
покупок
Количество
заказов
Рисунок 2.6 - Макет отчета «Реестр клиентов»
Сведения о накопленных скидках по каждому клиенту
Номер дисконтной карты
ФИО
Скидка
Рисунок 2.7 - Макет отчета «Сведения о накопленных скидках по каждому
клиенту»
Сведения о покупках клиентов
ФИО
Телефон
Электронный
адрес
Дата
продажи
Наименовани
е запчасти
Артикул
Количество
Единица
измерения
Цена
Сумма
Рисунок 2.8 - Макет отчета «Сведения о покупках клиентов»
Статистика работы с клиентами
ФИО
Адрес
доставки
Телефон
Электронный
адрес
Номер
диск
онтной
карты
Количество
покупок
Количество
заказов
Сумма
покупок
Сумма
предв
аритель
ных з
аказов
Рисунок 2.9 - Макет отчета «Статистика работы с клиентами»
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
На рисунке 2.10 представлено дерево функций, которое отражает основные и
служебные функции информационной системы обработки заявок ООО «ДанАвто».