69
Спиральная модель.
Когда разработка ИС происходит «Снизу-Вверх» начиная с отдельной(-ых)
задач к целой системе, например, как в задачной модели, единообразный подход к
процессу разработки теряется, начинают возникать сложности при информационном
совмещении отдельных компонент. Обычно, при увеличении количества задач,
сложность пропорционально увеличивается что приводит к систематическому
изменению как существующих программ, так и используемых структур данных.
Замедляется работа системы и тормозится работа и развитие предприятия на котором
эта модель используется. Не смотря на свои недостатки, использование задачной
модели может быть оправдано в следующих случаях:
Наличие срочности;
Адаптация ПО под заказчика.
Можно сказать, что достаточно крупную и эффективную информационную
систему использую данную методику разработать не получится. Некоторое
время назад, в небольших информационных системах, каждая программа
представляла собой неделимое целое. Каждый тип приложений разрабатывался с
применением каскадной модели. Её отличительной особенностью является то, что
разработка разбивалась на этапы, и переход между этапами был возможен только по
завершении всех работ на том, с которого осуществляется переход (см. рисунок 2.2).
К положительным сторонам использования каскадной модели можно отнести:
Формирование полной комплектации проектной документации после
завершения каждой стадии работы над проектом;
70
Возможность планировать расходы на разработку устанавливая сроки
завершения каждого этапа.
Рисунок 2.2 – Каскадная модель
Каждая стадия разработки завершается подготовкой комплекта документации,
которой будет достаточно чтобы работа над проектом была продолжена другой
командой [14]. Хорошей рекомендацией каскадной модели служит то, что при
создании информационных систем можно в достаточной степени полным образом
сформулировать требования и предоставить программистам возможность
реализовать необходимый функционал наилучшим и подходящим способом. К
таким информационным системам можно отнести различного рода системы
расчетов, системы, работающие в режиме реального времени. Однако с этим
подходом связан ряд недостатков, поскольку процесс разработки в реальном мире в
большинстве случаев не укладывался в жесткую схему и возникала постоянная
необходимость возвращаться к предыдущим стадиям для того чтобы уточнить или
пересмотреть решения, которые были приняты ранее.
Анализ
Проектирование
Разработка
Тестирование
Сопровождение
71
Это привело к тому, что разработка с использованием каскадной модели
принимала вид как на рисунке 2.3.
Рисунок 2.3 Процесс разработки программного обеспечения в реальной ситуации
В список недостатков при применении каскадного подхода можно занести
также серьезную задержку при получении результатов. Поскольку на время
процесса согласования полученных результатов после каждого этапа, проект вместе
с техническими и функциональными сведениями не подлежит изменениям. Это
обстоятельство приводит к тому, что замечания и пожелания заказчика и
пользователя информационной системы не будут учтены до окончательного
завершения работы над ПО. В том случае, если начальные требования были
неточными или вносились правки на протяжении длительного срока, заказчик
получает результат, который не удовлетворяет потребностям. Функциональные и
информационные модели объекта автоматизации могут устареть еще на стадии их
утверждения. Суть системного подхода заключен в разбиении информационной
системы на функции. Например, происходит процесс декомпозиции целой системы
на функциональные части, которые затем разбиваются на подфункции, а они в свою
очередь на задачи и так далее. Декомпозиция может продолжаться практически до
уровня конкретной процедуры. Исходя из проведенного анализа, можно сделать
вывод что основным достоинством каскадной модели можно считать системный
подход к процессу разработки, а основными недостатками медленную скорость
Анализ
Проектирование
Разработка
Тестирование
Сопровождение
72
процесса разработки и дороговизну.
С целью преодолеть проблемы присущие каскадному подходу была
разработана спиральная модель ЖЦ [6] схема которой представлена на рисунке 2.4.
Рисунок 2.4 Спиральная модель ЖЦ
Она фокусируется на начальных этапах жизненного цикла – анализе и
проектировании. На каждом из этих этапов возможность реализации принятых
решений проверяется при помощи создания прототипа. Витки обозначают создание
части или выпуска ПО, на котором происходит уточнение цели и свойств проекта,
качества ПО и происходит планирование следующего витка. Таким способом
достигается углубление и последовательная конкретизация деталей и до реализации
доходит самый обоснованный вариант [6]. Итерационная разработка является
отражением существующей спиральной модели создания ИС. Спиральная модель
позволяет переходить на следующую ступень, вне зависимости от того были ли
завершены работы на предыдущем, поскольку остаток работ всегда можно будет
закончить на следующем этапе. Основной целью данного подхода можно считать то,
что разработчики стремятся как можно скорее продемонстрировать заказчикам или
пользователям рабочую программу, стимулируя тем самым процесс сбора
73
пожеланий и замечаний. К минусам можно отнести относительную сложность
определения точки перехода на следующую стадию. Чтобы решить эту проблему
возникает необходимость введения временных ограничений на каждый этап
жизненного цикла, согласно которым и происходит переход на следующий уровень
даже если работы не закончилась. График переходов зависит от статистики и личного
опыта каждого из команды проекта. Проведя анализ существующих моделей, их
достоинств и недостатков, принял решение использовать спиральную модель,
поскольку в рамках данной дипломной работы могут возникать дополнительные
замечания к функционалу, которые можно реализовать на каждом витке разработки.
74
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Подход MSF предполагает некоторую минимизацию рисков, обоснованную
тем, что жизненный цикл проекта разбит на этапы, на каждом этапе за каждым
членом команды закреплены задачи и цели, которые необходимо достигнуть [4].
Однако несмотря на это, можно столкнуться с некоторыми рисками:
Таблица 2.5
Риски и локализация
Этап ЖЦ
Риск
Решение
Анализ
Неточный анализ сроков
проекта, его этапов и
бюджета
Увеличение числа
контрольных точек и
более точное
планирование этапов
проекта
Неэффективная
командная работа
вследствие неправильно
подобранного состава
команды проекта
Тщательный подбор не
только по
профессиональным
качествам но так же и с
учетом личностных
характеристик
кандидатов
Проектирование
Использование не самой
оптимальной
архитектуры
разрабатываемого
программного
обеспечения
Тщательное
продумывание и анализ
существующих паттернов
используемых при
разработке конкретного
типа информационных
систем
75
Этап ЖЦ
Риск
Решение
Разработка
Ошибки в понимании ТЗ
ведущие к
использованию неверной
архитектуры и
используемого
инструментария
Четкое, ясное и понятное
техническое задание
Отсутствие необходимых
навыков и опыта работу у
программиста на том ЯП
который будет
использоваться в проекте
В случае срыва сроков,
замена программиста
члена команды на
стороннего разработчика
Стабилизация
Риски незавершенного
тестирования ПО
Повторение тестирование
на следуем витке спирали
Внедрение
Риски несвоевременного
решения о завершенности
фрагмента проекта
Доработка на следующем
этапе
76
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Для поставленных задач имеется несколько механизмов реализации ИБ.
Защита от внутренних угроз реализована при помощи разграничения доступа
к платформе «1С: Предприятие», физического и программного доступа к серверу
предприятия. Права для программных модулей и пользователей системы
представлены в таблице 2.5.
Таблица 2.5
Разграничение прав пользователей и программных модулей
Группа пользователей /
Программные модули
Тип защиты
Доступ к базам
HTTP-сервис
Логин/пароль
Бухгалтерия
Мобильное приложение
Сервисный ключ
Нет
Бухгалтер
Аппаратный ключ
Бухгалтерия, Торговля и
склад
Руководитель
Аппаратный ключ
Бухгалтерия, Торговля и
склад
Отделы продаж,
логистики
Логин/пароль
Торговля и склад
К механизмам защиты от внешних угроз можно отнести доступ к серверу
строго по RDP при использовании сертификата и протоколировании действий.
Помимо этого, предприятие использует другие всевозможные методы защиты как
сетевой экран, ограничение доступных ресурсов и пр., так как не существует
универсального защитного механизма от внешних угроз.
77
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Схема информационной модели дипломной работы представлена на рисунке
2.6:
Рисунок 2.6 Информационная модель
78
В нашей информационной модели задействовано одновременно несколько
источников входных данных. Основной ИС является платформа 1С: Предприятие
8.3.
Бухгалтерия формирует документ на оплату – счёт, разработанное мобильное
приложение обращается к разработанному программному модулю «1С:
Предприятие».
При первичном запуске мобильного приложения, контрагент вводит
реквизиты, название и регистрационный код полученный от бухгалтерии. Затем
мобильное приложение обращается к программному модулю 1С посредством сети
Интернет и запрашивает список документов, выставленных для оплаты данной
организацией. После оплаты счёта, контрагент для проведения подтверждения
нажимает на кнопку, соответствующую номеру оплаченного счета и мобильное
приложение отправляет запрос на программный модуль, который проводит поиск по
справочнику документов и изменяет его статус на оплачено, помещая в поле
комментарий дату получения подтверждения.