48
Рисунок 9. Спиральная модель ЖЦ ИС
Я считаю спиральную модель наиболее оптимальной, поскольку она
учитывает все недостатки каскадных и целевых моделей. В рамках
уточнения существующего IP-адреса часто появляются новые
комментарии пользователей, которые могут быть реализованы на новом
витке спиральной модели.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Стандарт MSF дает определенную гарантию минимизации рисков,
поскольку весь жизненный цикл проекта разделен на этапы, на каждом
этапе есть роли, для которых существуют цели, которые должны быть
достигнуты, и, тем не менее, на каждом этапе существуют определенные
риски. На этапе разработки концепции могут возникнуть следующие
риски:
Детально не проработан план проекта, не все нюансы учтены
Чтобы устранить этот вид риска, необходимо более детально
проработать задачи и цели проекта, наметить больше этапов. На этапе
планирования могут возникнуть следующие риски:
Неправильно подобранный проектный состав исполнителей может
49
повлечь за собой полное отсутствие командной работы
Эти риски могут возникать из-за ошибки технического директора
или из-за неточных встреч с командой разработчиков, и, следовательно,
технический директор принял неправильное решение. На стадии
разработки возможны следующие риски:
Архитектура проекта неверна или неправильно сформирована
Эти риски могут возникать из-за ошибки технического директора
или из-за неточных встреч с командой разработчиков, и, следовательно,
технический директор принял неправильное решение. На стадии
разработки возможны следующие риски:
Ошибочное обьяснение ТЗ и как следствие ошибочное
программирование архитектуры и сдвиг сроков релиза.
Сокращение указанного риска служит более чёткое написание ТЗ,
понятного программисту
Другим важным риском в этом проекте является отсутствие
надлежащей квалификации программиста на языке, на котором
клиент решил внедрить программу, которая будет распределять
приложения между инженерами.
В случае, если программист не укладываться в указанные
временные рамки графика проекта, придется находить внешнего
разработчика, так называемый «фриланс».
На этапе тестирования могут возникнуть следующие риски:
Неоконченное тестирование.
Вероятно может произойти ситуация что программный продукт не
будет протестирован до конца. Решение производится путем повторного
тестирования на следующей итерации разработки.
На этапе внедрения могут возникнуть следующие риски:
50
Риски ошибочного принятия решения о завершонности части
проекта.
Рождение рисков ведет за собой проблемы недоделанности
решений и возможности несоответствий с другими частями
разрабатываемой ИС. Риск устраняется путем уточнения на следующей
итерации.
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Есть несколько реализаций информационной безопасности для
этого комплекса задач.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа, права пользователей описаны в таблице 13.
Таблица 13
Разграничение прав пользователей.
Группы
пользователе
й
Модуль
«Авториза
ция»
Модуль
«Начисление
билетов»
Работа с БД
Пользователь
Создание/Чт
ение/Редакт
ирование
Нет
Чтение/созда
ние/удаление
Служба
поддержки
пользователей
Полное
Нет
Полное
Администратор
системы
Полное
Есть
Полное
Защита от внешних угроз осуществляется с помощью следующих
методов:
Во-первых, на всех серверных системах в компании «Лектура
правого полушария интроверт» не установлены сторонние инструменты
удаленного администрирования. Доступ организован через Remote desktop
51
protocol, на нужный сервер, в том числе и СУБД. Вход в систему
осуществляется только путем авторизации домена в соответствии с
уровнем доступа.
Во-вторых: Компьютеры, серверы, аппаратно-программные
комплексы, пропускная система, система видеонаблюдения и АТС
должны быть подключены к источникам бесперебойного питания.
Техническим сопровождением ИБП должно заниматься специальное
подразделение УИС.
Компания «Лекция правого полушария интроверта» использует все
возможные методы защиты информации, поскольку не существует
единственного метода, который мог бы обеспечить полную
информационную безопасность, а сочетание всех методов позволяет
реализовать максимальную информационную безопасность.
2.2 Информационное обеспечение задачи
2.2.1 Характеристика нормативно-справочной, входной и
оперативной информации
К входному типу информации относиться информация, что
поступает в систему постоянно на протяжении всей жизни программного
продукта. Входной информацией для разрабатываемого программного
продукта будет является только входные данные и справочники
организации.
Нормативно-справочная информация - это информационный
ресурс компании, формируемый внутри и получаемый, как правило, извне.
Она содержит стандарты, требования, правила, положения и прочую
информацию, нормирующую и систематизирующую деятельность
компании.
Информация структурирована, имеется четкий набор справочников.
Соответственно, один входной документ содержит несколько
справочников. Описание справочников приведено в таблице 14.
52
Таблица 14
Таблица «Описание справочников»
Название справочника
Описание справочника
Токен транзакции
Уникальный номер транзакции
Uid пользователя
Уникальный номер пользователя
Дата покупки
День, когда произошла покупка
Сумма покупки
Изначальная сумма билетов
Скидка
Процент скидки
Количество
Количество билетов
Статус
Статус оплаты
На основе выше перечисленных справочников формируются
входные документы. Таблица формируется автоматически после начала
покупки билета. Пример входных документов изображен в таблице 15.
Таблица 15
Пример входного документа
Токен
транзакции
Uid
пользовате
ля
Дата покупки
Сумма
покупки
Скидк
а
Ко
ли
че
ст
во
Статус
267b0466-
000f-5000-
a000-
1bf3c16688f2
m1kuF8swT
DZipWOU5E
dV21yDg872
1592324241206
1741
10
3
success
266efc98-
000f-5000-
8000-
134064c1814
d
ut4va0ccWL
ZPcnPZRtBjs
cAZ4g32
1592326256853
645
0
1
success
2.2.2 Характеристика результатной информации
Результатная информация в основном будет отображаться на
мониторе компьютера.
Выходной информацией является информация о заказе и статусе
транзакции. В отчет входит следующая информация:
53
Дата покупки
Статус
Сумма
Количество
Наименование билетов
2.3 Программное обеспечение задачи
2.3.1. Сценарий диалога
В данном дипломном проекте я автоматизирую часть ИС, а именно
безотказную работы платежной системы. Сценарий диалога представлен
на рисунке 10.
Рисунок 10. Сценарий Диалога работы программы
Любой функционал программы можно сгруппировать как основной
и служебный. Основной – содержит основную логику программы, решает
54
основные функции, несет ключевую информацию. Служебный – содержит
функционал, в большей части для администраторов системы. Дерево
функций наглядно демонстрирует разделение этих функций. Дерево
функций изображено на рисунке 11.
Рисунок 11. Дерево функций
2.3.2. Характеристика базы данных
Базу данных ИС можно представить в виде следующей ER модели.
Данная модель отображена на рисунке 12.
55
Рисунок 12. ER модель базы данных
Таблица «user», имеет следующие поля – таблица 16.
Таблица 16
Таблица «user»
Наименование поля
Тип данных поля
Длина поля
abonement
Целое число
10
date
Строка
50
email
Строка
100
invitationCode
Строка
8
name
Строка
50
token
Строка
250
Таблица «my_payment», имеет следующие поля – таблица 17.
Таблица 17
Таблица «my_payment»
Наименование поля
Тип данных поля
Длина поля
apple_pay
Булевое
5
date
Целое число
50
percent
Целое число
10
price
Целое число
10000
56
Продолжение таблицы 17
Наименование поля
Тип данных поля
Длина поля
promocode
Строка
50
status
Строка
100
token
Строка
150
total
Целое число
20
type
Строка
50
uid
Строка
50
2.3.3 Структурная схема пакета (дерево вызова процедур и программ)
Поскольку основным программным продуктом разрабатываемым в
данном проекте является автоматизация продаж билетов и дерево функций
будет описано именно для неё на 13 рисунке.
Рисунок 13. Схема графических форм программы
В таблице 18 содержится описание всех модулей структурной
схемы пакетов, представленных на рисунке 13.
57
Таблица 18
Таблица модулей разрабатываемого программного продукта.
№
п/п
Наименование модуля
Функционал модуля
0
Модуль
«Авторизация»
Данный модуль содержит запрос
логина и пароля для входа в
программу.
1
Модуль «Вывода и
хранения билетов»
Модуль отправки запроса на сервер
для вывода данных в приложение
2
Модуль «Осуществление
транзакций»
Служебная часть модуля отвечающая
за проведение банковских транзакций
в соответствии с законом ст. 4.1 ФЗ №
54
3
Модуль «Службы
поддержки»
Модуль формирование и отправки
отчета в одну итерацию.
4
Модуль «Редактирование
билетов»
Служебная часть модуля отвечающая
за редактирование, создания и
удаления билетов
2.4 Испытания разработанного решения
В соответствии с ГОСТ 34-602-92, автоматизированные системы до
внедрения в эксплуатацию проходят предварительные испытания.
Испытания ИС могут быть двух видов: комплексные и автономные.
Автономные испытания предполагают проверку отдельных
составных частей (модулей, подпрограмм и т.п.) ИС.
Комплексные испытания предполагают совместную проверку всех
составных частей и видов обеспечения (программного,
технического и т.д.) ИС.
Для нашей системы наиболее подходящими являются автономные
испытания, так как система Яндекс.Касса состоит из множества связанных
между собой составных частей, в каждой из которых есть потенциал сбоя.