52
Объектно-ориентированные модели жизненного цикла
Объектно-ориентированная модель ЖЦ имеет отличительную
особенность от ранее перечисленных. Если до этого на каждой из итераций
правились ошибки, то в данном случае каждая итерация дополняет предыдущую
и развивает ее, не отменяя результат на предыдущем шаге.
Среди основных принципов ООП можно выделить:
Итеративность развития;
Увеличение функциональности в соответствии со сценариями;
Повторяемость действий;
Операции на размноженных фазах схожи.
Несмотря на специфику, при ООП проходят все те же этапы, что в ранее
упомянутых моделях.
Модификация модели фазы - функции
Благодаря тому, что при моделировании ЖЦ при ООП используются
традиционные этапы в рамках одной итерации, в качестве модификации уже
существующих моделей ЖЦ назначается задача смоделировать процесс
итеративного наращивания. В этом разделе указанная модификация применяется
для модели фазы-функции Гантера
Тем не менее, есть и отличия. Например, в случае сравнения с моделью
Гантера измерение фазы ЖЦ при ООП почти не имеет изменений, но
появляется дополнительный этап «Моделирование пользовательского
интерфейса». Этот этап в устаревшей схеме представлен как часть этапов
анализа и/или конструирования. Но именно это характеризует подход
моделирования ЖЦ при ООП.
Можно выделить следующие особенности, определяющие мотив
сравнения с моделью Гантера.
Распределение реализуемых требований по итерациям.
Особый стиль наращивания возможностей системы и ее развития.
При таком подходе основой декомпозиции проекта служит представление
системы в качестве набора классов, взаимосвязанных различными отношениями.
Эти классы добавляются к предыдущей итерации с каждой новой. Для
грамотного выстраивания отношений между ними создают модель уровня
53
конструирования. Такая модель позволяет понять способы реализации
проектируемой системы.
Можно обозначить еще одну особенность при моделировании ЖЦ при
ООП. Она связана с тем, что пользователю демонстрируется каждая версия
системы. При этом пользователь, разумеется, не имеет никакого отношения к
конструированию.
В обновленной схеме ЖЦ можно заметить расщепление (которое строго
регламентировано), единственное для всей последовательности работ (рис.2.7).
Этот маршрут показывает запланированный акт. Этот акт фиксирует
информацию, что происходит наращивание возможностей изделия.
Рис. 2.7 Фазовое измерение модели жизненного цикла при объектно-
ориентированном развитии проекта
На рисунке 2.7 присутствует еще одна модификация схемы Гантера. На
этапе оценки существует вложенный этап - этап пополнения базового
окружения проекта. Он содержит в себе следующий смысл - планирование и
реализация повторного использования ПО. Каждый проект ООП развивается,
54
исходя из ресурсов, а именно из среды классов и компонентов. Базовое
окружение проекта активно используется, пополняется средствами, возникшими
при итеративном наращивании. Безусловно, такой подход будет полезен для
дальнейших проектов.
Модель ЖЦ при ООП проекта имеет нестандартные работы.
По вполне понятным причинам в объектно-ориентированном
проектировании несколько изменяется содержание ряда этапов, что нашло свое
отражение в количестве и наименованиях событий на рисунке. Это начальные и
завершительная фазы проектов. Первая выполняется на старте работ в ходе
анализа исследования и уязвимости. Вторая - на ней заканчиваются работы над
проектом.
Начальная фаза состоит из общего планирования, позволяющего
определить дальнейшее развитие проекта. Они составляют основу разработки,
проявляясь в следующем:
Определять первостепенную задачу (на первой итерации) и
перспективы других задач, которые могут корректироваться в будущем;
Выбор критериев оценки результата каждой итерации.
Завершающая фаза схожа с традиционной фазой эксплуатацией и
сопровождения. Однако, можно отметить такие различия, связанные с тем, что
ООП взаимодействует с иерархиями версий системы, которые отражают
наращивание мощностей.
Рассмотрим модифицированную матрицу фаз-функций при ООП. Логично
расширить перечень технологических функций, прибегнув к моделированию,
т.е. необходимо обозначить строку интенсивностей в матрице Ганта для этой
функции.
Рассмотрим, как распределяются интенсивности технологических
функций. Примем их за “среднестатистическую” интеграцию тенденцию по
итерациям. От рассмотрения функционального измерения можно извлечь
пользу: ЛПР проекта задумываются о распределении сил среди разработчиков и
кадровых ресурсов.
Параллельное выполнение итераций
55
Учитывая, что требования постоянно меняются, и с ними работают
несколько человек, вполне логично, что в модели жизненного цикла должна
быть отражена одновременная деятельность команды/коллектива. Это служит
одной из составляющих мотивов разработки моделей.
В модели, соответствующей схеме фазы-функции Гантера, именно
функциональное измерение отражает качество процесса разработки
программного изделия. Оно показывает одновременные действия с
технологическими функциями. В ООП (объектно-ориентированном подходе)
можно выделить еще один вид технологического параллелизма, а именно
разработка сразу нескольких итераций различными группами исполнителей в
одно и то же время. Итерации все же зависят друг от друга, поэтому нельзя
допускать их механического слияния. В качестве примера можно привести факт,
что в случае непостроенной системы отсутствует возможность наращивания ее
классов. Таким образом, всегда необходимо помнить про схожие кейсы и другие
зависимости. Выделим следующие области:
область недопустимого значения (выполнение одной работы
находится в прямой зависимости от результатов другой);
область возможного совмещения (работы находятся в прямой
зависимости друг от друга, но имеют более слабую связь в связи с тем, что
результаты предшествующей работы хорошо описаны;
область рационального совмещения (зависимость одной работ от
другой экранирована).
Благодаря четкому разделению областей повышается гибкость
распределения времени для исполнения проекта. Подчеркнем, при
планировании работ во время проекта лучше не совмещать итерации, оставляя
эту возможность в качестве резерва временного ресурса проекта. Так,
итеративность ООП позволяет иметь дополнительную устойчивость к рискам,
когда не выполняется проектное задание.
Моделирование итеративного наращивания возможностей системы
В рассмотренных ранее моделях ЖЦ ООП не было явного выделения
такого аспекта как постепенное наращивание возможностей системы в
зависимости от развития проекта.
56
Как и раньше, горизонтальные отрезки с пометками – итерации. Они
находятся в пространстве возможностей системы в зависимости от времени.
Параллельно временной оси проходят линии, отражающие уровни возможностей
пользователей, которые реализуются на итерациях (итерации отмечены
римскими цифрами справа). Стрелки-переходы между итерациями учитывают
условия совмещения работ, рассмотренных ранее. Данная модель демонстрирует
факт ООП развития проекта, при котором возможности, которые
предоставляются каждой следующей итерацией никак не отменяют уровня,
достигнутого на более ранних итерациях.
Модель показывает, что ООП приводит к расширению прикладной
области, при которой используют конструируемые рабочие продукты.
Про объектно-ориентированное развитие проектов часто говорят, что оно
предполагает, что традиционные этапы жизненного цикла разработки
программной системы никогда не кончаются. Модель раскручивающейся
спирали наглядно показывает смысл этого тезиса.
В данной модели можно усмотреть еще один аспект конструирования
программных систем — типичную схему развития коллектива разработчиков,
который, начиная от первого своего проекта, постепенно пополняет
накапливаемый багаж переиспользуемых в разных системах компонентов.
В отличие от предыдущих моделей, обе спиралевидные модели никак не
отражают тот факт, что у проекта есть фаза завершения. Как следствие, они
предполагают, что все модификации какой-либо версии программной системы,
которые требуются после ее выпуска, будут относиться к одной из следующих
версий. На практике очень часто это положение нарушается: приходится
поддерживать (и в частности, модифицировать) сразу несколько версий
системы.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Любой проект по созданию информационной системы предприятия всегда
включает множество задач, связанных с общим управлением проектом,
разработкой ПО, проектированием ИС, внедрением, каждая из которых сама по
57
себе является проектом с присущими ему особенностями. Поэтому в ходе
разработки существуют различные риски.
При разработке концепции возможны следующие риски:
Недолгосрочный анализ дедлайнов проекта, а также его бюджета.
Степень риска можно снизить детальной проработкой задач и целей проекта, а
также выделения большего количества контрольных точек;
Некорректно сформированный состав проектной команды может
оказать влияние на командную работу. Для решения этой проблемы подбору
специалистов уделяется большое внимание не только квалификационным
навыкам, но личностным качествам.
Фаза планирования также может быть подвержена рискам, а именно:
Неправильно или не совсем корректно сформированное архитектура
выбираемого решения. Возможность появления этого риска зависит от
компетенции руководителя проекта, на котором лежит принятие решение о
выборе архитектуры разрабатываемого решения.
В фазе разработки возможны следующие риски:
Неправильная интерпретация технического задания и как следствие
неправильная программирование архитектуры и сдвиг сроков. Минимизацией
данного риска служит более чёткое написание технического задания, понятного
программисту
Еще одним немаловажным риском в данном проекте является
отсутствие должной квалификации у программиста в том языке, на котором
решено реализовывать программу клиент, которая будет распределять заявки
между инженерами. В случае, если программист не будет укладываться в
заданные временные рамки календарного плана проекта, продеться использовать
внешнего разработчика, так называемый “аутсорсинг” или “фриланс”.
В фазе тестирования могут возникнуть следующие риски:
Риски неоконченного тестирования. Может произойти ситуация что
программный продукт будет протестирован не до конца.
Решается путем повторного тестирования на следующей итерации
разработки.
В фазе внедрения могут возникнуть следующие риски:
58
Риски неправильного принятия решения о законченности части
проекта.
Возникновение данных рисков ведет за собой проблему незаконченности
решения и возможность возникновения нестыковок с другими частями
разрабатываемой ИС
Устраняется путем доработки при следующей итерации.
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
В системе реализованы механизмы доступа к данным через полномочия. В
таблице ниже приведены основные полномочия системы и их соответствие
ролям пользователей (см. приложение 1)
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Рассмотрим типовую модель взаимодействия клиента и банка ПАО
«БИНБАНК» на примере самого распространенного продукта –
потребительского кредита (рис. 2.8).
Анализ бизнес-процесса или подготовка оформления банковского
продукта заключается в проверке предоставленных клиентом документов и
информации о требуемом продукте.
Скоринг данных клиента выполняется с целью определения
платежеспособности заемщика по перечню аналитических метрик, состав
которых определяет для себя кредитор. Период анализируемых данных обычно
не превышает 3-5 лет.
Рассмотрение кредитной заявки обычно включает еще и фазы
верификации и валидации предоставленных данных.
Если заявка была одобрена, далее следует формирование пакета
документов на этапе проведения сделки.
59
После подписания договора и прочих документов сделки ведется
обслуживание клиента на период финансовых взаимоотношений между банком
и клиентом.
Рисунок 2.8 Взаимодействие банка и клиента
Когда этап обслуживание по тем или иным причинам заканчивается, отношения
между клиентом и банком разрываются и происходит закрытие договора.
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
В реализуемой системе операционного CRM планируется автоматизировать
процессы:
Хранения клиентских данных с целью обслуживания и
идентификация клиента
Оформление заявок на кредитные продукты Банка и их рассмотрение
Выполнение операций по обслуживанию клиентов физлиц
Рассмотрим основные процессы и их оперативную информацию в разрезе
протекания процесса в ит-ландшафте систем Банка.
Заведение заявки на кредит или кредитную карту – весь процесс можно увидеть в
приложении 2. Описание основных элементов бизнес-процессов можно увидеть в
таблицах 2.1 – 2.11.
Таблица 2.1
Описание элементов бизнес-процесса. Роль - ESB
Наименование
Комментарии
S03 Выполнение запросов в
системы, участвующих в
одобрении заявки (Фактор,
FICO, Credit Registry, Hunter,
Expertise)
При получении очередного блока заявки:
- ESB в online-режиме передает данные этого блока в FICO.
- FICO в ответ может вернуть признак, что данные заявки нужно передать в
другую систему. Тогда ESB формирует сообщение и передает его в указанную
FICO систему.
- Ответ от системы ESB транслирует обратно в FICO. В ответе от FICO может
быть признак, что данные заявки нужно передать в другую систему, и тогда
описанный цикл повторяется.
S04 Фиксация ответов от
систем в промежуточной базе
данных
ESB в отдельной БД должен сохранять:
- блоки информации, поступившие из WebApp,
- историю запросов и ответов FICO,
- историю запросов и ответов других систем.
S05 Получение от FICO
решения по заявке
(положительное,
отрицательное, на
После получения окончательных ответов от всех систем, участвовавших в
одобрении заявки, FICO должно вернуть в шину данных решение по заявке:
Положительное, Отрицательное или На верификатора
60
Наименование
Комментарии
верификатора)
S06 Передача в Siebel данных
по заявке, решении, ссылок на
отчеты БКИ и других данные
для работы верификаторов
Спецификация передаваемых данных согласована в виде отдельного документа.
S07 Формирование SMS и/или
Email c уведомлением клиента
об отрицательном решении по
заявке
Шаблоны SMS и Email сообщений хранятся в Siebel.
- шина передает в Siebel тип сообщения (SMS, Email), номер шаблона и значения
переменных, которые нужно подставить в шаблон
- Siebel формирует текст сообщения и возвращает его в шину,
- шина отправляет сформированное сообщение на нужный канал через шлюз
SMSTraffic.
S09 Передача в Way4 данных
для формирования реальной
карты, Welcome Pack и
(опционально) виртуальной
карты
Набор передаваемых данных описан и согласован в отдельном документе.
Решение о возможности предоставления клиенту виртуальной карты принимает
FICO.
S10 Формирование SMS и/или
Email с информацией о том, что
заявка принята на рассмотрение
Шаблоны SMS и Email сообщений хранятся в Siebel.
Для отправки сообщения:
- шина передает в Siebel тип сообщения (SMS, Email), номер шаблона и значения
переменных, которые нужно подставить в шаблон
- Siebel формирует текст сообщения и возвращает его в шину,
- шина отправляет сформированное сообщение на нужный канал
S14 Получение от FICO
решения по заявке
После поулчения от Siebel результатов работы верификатора FICO должна
принять окончательное решение по заявке: Положитльное или Отрицательное.
S15 Передача в Way4 данных
для формирования реальной
карты, Welcome Pack и
(опционально) виртуальной
карты
Набор передаваемых данных описан и согласован в отдельном документе.
S20 Передача в Siebel
реквизитов контракта/карты для
реальной и (опционально)
виртуальной карты
Передача реквизитов карты между системами должна осуществляться по
протоколу https с серверным сертификатом.
S21 Формирование SMS и/или
Email c уведомлением клиента
об отрицательном решении по
заявке
Шаблоны SMS и Email сообщений хранятся в Siebel.
Для отправки сообщения:
- шина передает в Siebel тип сообщения (SMS, Email), номер шаблона и значения
переменных, которые нужно подставить в шаблон
- Siebel формирует текст сообщения и возвращает его в шину,
- шина отправляет сформированное сообщение на нужный канал через шлюз
Таблица 2.2
Описание элементов бизнес-процесса. Роль - Siebel
Наименование
Комментарии
S08 Сохранение клиента и
заявки
На стороне Siebel должен быть разработан web-сервис для приема от шины
данных по заявке и клиенту в online-режиме.
В результате работы сервиса в Siebel создается новый клиент и заявка. Id
созданного в Siebel клиента возвращается в ответном сообщении в шину.
S13 Передача в FICO (через
шину) ответов на вопросы и
истории звонков
После того как верификатор ответил на все вопросы по заявке, Siebel в online-
режиме должен передать ответы на вопросы в шину, которая в свою очередь
транслирует их в FICO.
S22 Сохранение реквизитов
контракта/карты для реальной и
(опционально) вииртуальной
карты
В базе данных Siebel номер карты должен храниться в зашифрованном виде. При
просмотре информации по карте в пользовательском интерфейсе Siebel должны
быть видны только последние 4 цифры номера карты.
S23 Обновление статуса заявки
В случае положительного решения статус заявки меняется на "Одобрена", в
случае отказа верификатора - на "Отрицательное решение".
Таблица 2.3
Описание элементов бизнес-процесса. Роль - Way4
61
Наименование
Комментарии
S16 Формирование новой
реальной и (опционально)
виртуальной карты
В Way4 должны создаваться новый клиент, счетовой контракт и карта, а также
(опционально) отдельный счетовой контракт для виртуальной карты и сама
виртуальная карта.
S17 Регистрация нового
клиента, счетового контракта и
карты в Интернет Банк
После регистрации клиент может зайти в Интернет Банк, используя номер своего
мобильного телефона в качестве временного логина.
S18 Отправка на мобильный
телефон клиента SMS-
сообщения с ссылкой для входа
в Интернет Банк
Формирование текста SMS-сообщения и отправку этого сообщения Way4
осуществляет своими средствами, без обращения в Siebel.
S19 Возврат в шину реквизитов
карты (номер, имя на карте,
срок действия) и счетового
контракта (номер)
CVV/CVC карты не должен передаваться из Way4 во внешние системы.
Таблица 2.4
Описание элементов бизнес-процесса. Роль - WebApplication
Наименование
Комментарии
S01 Поблочная передача заявки
в шину данных
По мере заполнения каждого блока полей заявки в WebApplication, значения
полей этого блока должны в online-режиме передаваться в шину данных (ESB).
Блоки одной заявки при передаче в шину должны быть связаны одним
идентификатором.
Необходимо определить состав полей каждого блока в отдельном документе.
S02 Запросы в Фактор для
осуществления проверок
формата и корректности данных
(адреса, телефоны, ...)
При вводе значений в некоторые поля заявки, WebApplication должен в online-
режиме вызывать систему Фактор для проверки правильности и обогащения
значения этого поля. Например, когда в заявку вводится адрес проживания,
Фактор проверяет правильность введенного адреса по КЛАДР, добавляет к
адресу индекс и т.д.
Таблица 2.5
Описание элементов бизнес-процесса. Роль - Верификатор
Наименование
Комментарии
S11 Захват в Siebel заявки из
пула нераспределенных заявок
FICO может запросить рассмотрение заявки младшим или старшим
верификатором.
В Siebel верификаторы двух типов должны иметь разные роли, с возможностью
раздельной настройки доступов к экранам и полям заявки.
S12 Просмотр данных по
заявке, инвестигация заявки в
Hunter, осуществление звонков,
фиксация в Siebel ответов на
вопросы
Если по заявке принято решение "На верификатора", FICO дополнительно к
решению должен сообщить:
- тип верификатора, который должен рассмотреть заявку,
- набор кодов вопросов, на которые должен ответить верификатор,
- признак инвестигации.
С бизнес-процессом по выпуску и доставке карт моно ознакомиться в
приложении 3.
Таблица 2.6
Описание элементов бизнес-процесса. Роль -
Наименование
Комментарии
S22 Идентификация клиента
См. разделы "Идентификация клиента в отделении" и "Идентификация клиента
курьером"
Таблица 2.7