Риски неполных или неверных требований к проектируемой ИС
Бизнес риски
Политические риски
Риск недостаточности профессиональных умений
Данный риск проявляется в снижении эффективности эксплуатации ИС из-за нехватки каких-либо профессиональных умений пользователей и администраторов ИС. В рассматриваемом проекте риск отсутствует, т.к. от пользователей не требуется никаких профессиональных знаний, а администратор владеет всеми необходимыми умениями.
Реализация риска может проявиться в изменениях нормативно правовой базы, регулирующей деятельность ломбардов. Влияние на проект критическое (например, могут появиться нормы исключающие возможность использования систем без обязательного ведения электронного журнала, в котором должны фиксироваться все операции чтения-записи данных)
Предлагается стратегия ослабления риска за счет гибкости и открытости кода ИС, обеспечиваемых средой MS Access.
Здесь рассматриваются риски ломбардного бизнеса, возникающие в результате приостановки проекта или полного отказа от его реализации.
Данные риски тесно связаны с бизнес причинами разработки проекта ИС.
Предлагается стандартная для этого типа риска стратегия его ослабления за счет рассмотренной ниже поэтапной разработки ИС, позволяющей в кратчайшие сроки выпускать версии, пригодные для практического использования.
Здесь рассматривается управление рисками, появляющихся в результате формулирования неполных или неверных требований к проектируемой ИС.
Стандартным подходом является составление списка требований к ИС, вероятность неполноты или искажения которых наиболее велика. В данном проекте к таким требованиям относятся прежде всего требования по структуре данных и по автоматизации обработки данных в объектах ИС.
Предлагается стратегия ослабленияза счетрассмотренного выше фактора успеха проекта – за счет подключения к проекту работника ломбарда, выполняющего одновременно функции администратора информационных систем и аналитика БП и Бпр.
2.1.5. Инкрементный план релизов проекта ИС «Ломбард»
Используя информацию о важности для бизнеса информационной поддержки отдельных Бпр (таблица 2.2.), а также о частоте применения отдельных Бпр (таблица 2.3.) реализацию проекта разделим на три этапа, каждый из которых завершается версией (релизом) ИС «Ломбард», включающей всю функциональность более ранних релизов.
Этап 1 (релиз1) включает информационную поддержку следующих Бпр:
1) Оформление залогового билета.
2) Расчет суммы займа.
3) Выкуп залога и Расчет процентов.
Этот этап самый емкий, поскольку первый релиз создается как версия ИС, пригодная для практической эксплуатации. В нем автоматизируется информационная поддержка наиболее важных и часто применяемых Бпр. Остальные Бпр поддерживаются самыми простыми средствами без глубокой автоматизации, или вовсе без нее. Такая стратегия разработки позволяет получить отдачу от проекта уже после создания первого релиза.
Этап 2 (релиз 2) включает автоматизированную информационную поддержку всех Бпр первого этапа, а также дополнительно следующих Бпр :
1) Оформление перезалога.
2) Передача смены.
3) Передача залога на реализацию.
4) Работа с клиентами – должниками.
Этап 3 (релиз 3) включает автоматизированную информационную поддержку всех Бпр первого и второго этапов, а также дополнительно следующих Бпр :
1) Передача залога на реализацию.
2) Изъятие залога.
3) Передача залогов в другой ломбард.
4) Прием залогов, переданных из другого ломбарда.
Диаграмма плана релизов показана на рис 2.5.
Рис.2.6 Диаграмма плана релизов
2.2. Фаза Elaboration - проработка проекта ИС «Ломбард»
Как показано на рис.2.1 фаза Elaboration разделяется на два подэтапа проектирования. На первом из них проводится детальный Use Case анализ проекта и создаются предварительные модели ИС в виде описаний маршрутов Use Case.
Второй подэтап состоит из трех частей. Сначала, на основе всей полученной к этому моменту информации о предметной области ИС и поведении ИС при реагировании на события, порождаемые акторами, создается диаграмма классов. Затем проектируется прототип пользовательского интерфейса, в котором создаются формы для экранного представления основных информационных объектов ИС. В третьей части создаются динамические модели ИС, включающие диаграммы состояний (объектов ИС) и диаграммы последовательностей (процедур ИС).
2.2.1. Use Case анализ ИС «Ломбард»
Отправной точкой Use Case анализа является Use Case диаграмма (рис.2.7.), построенная на основе информации, содержащейся в таблице событий 2.3.
Поведение разрабатываемой ИС (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases или варианты использования), системное окружение (действующих лиц или актеров - actors) и связи между прецедентами и актерами (диаграммы прецедентов - use cases diagrams). Основная задача модели прецедентов - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы [3].
Рис.2.7. Диаграмма вариантов использования (Use Case Diagram) ИС «Ломбард»
Диаграмма на рис.2.7. получена взаимно однозначным отображением каждого события, зафиксированного в табл. 2.3. в один вариант использования. Следующим шагом является проверка корректности такого отображения.
На протяжении многих лет велись дискуссии на тему правильности прецедентов. Одной из проблем является уровень их детализации. Насколько мал или велик он должен быть? Здесь нет однозначного ответа. Можно использовать следующее правило: "Прецедент обычно определяет основной элемент функциональности и совершается от начала до конца. Он должен приносить что-то значимое для актера"[3]. Анализируя варианты использования «включаемые» менеджером можно заметить, что они образуют исполняемые последовательно пары: «Искать КК» - «Создать КК»; «Искать КК» - «Редактировать КК»; «Искать КК» - «Создать ЗБ»; «Искать КК» - «Выбрать и открыть ЗБ». Подобную ситуацию отобрахают на диаграмме Use Case, используя связь типа «extend», направленную от вызываемого Use Case к вызывающему Use Case и читают как «Use Case Создать КК расширяет (extend) Use Case Искать КК». Потребности в слиянии или расщеплении Use Case нет. Измененная диаграмма приведена на рис.2.8.
Рис.2.8. Диаграмма Use Case ИС «Ломбард» с учетом связей между вариантами использования.
Завершив на этой фазе проектирования анализ общей диаграммы Use Case, перейдем к определению спецификации каждого Use Case, включенного в диаграмму.
По определению Use Case - это вызываемая событием непрерывная последовательность взаимодействий, выполняемых актором в диалоге с системой, с целью получения для актора некоторого измеримого результата (отклика или реакции системы)
Следствие: варианты использования (Use Cases) – это элементы модели, представляющие различные ЦЕЛИ использования ИС и РОЛИ акторов в процессах достижения этих целей. Фокусировка на ЦЕЛЯХ отличает Use Cases от функционального моделирования, которое документирует процесс и упускает из вида понимание того, зачем нужен этот процесс. Фокусировка на процессах скорее приведет к репродуцированию существующих процессов, чем к их реинжиниринг [1].
Для спецификации каждого Use Case воспользуемся следующим шаблоном, объединившим элементы спецификации Use Case, приведенные в [1],[3].
Шаблон варианта использования:
1) наименование;
2) акторы, взаимодействующие с Use Case;
3) описание с фокусировкой на целях и ролях;
4) авторы (authors) варианта использования;
5) географическое местоположение Use Case;
6) статус– текущая фаза детализации;
7) приоритет;
8) предположения (assumptions) – истинные и неистинные высказывания о варианте использования (то, что всегда верно и что всегда неверно для Use Case );
9) предусловия(preconditions); – факты, которые должны быть истинными перед инициализацией маршрутов варианта использования
10) постусловия(postconditions) - факты, которые должны быть истинными перед выходом из варианта использования или, другими словами, требуемые состояния системы перед завершением маршрута варианта использования;
11) приоритетный или счастливый маршрут (primary or happy pathway), т.е. главный поток событий, обрабатываемых в Use Case;
12) альтернативные маршруты (alternate pathways);
13) исключающие маршруты (exception pathways) – обработка ошибочных условий (т.е. исключений из основных правил поведения процессов) и состояний.
2.2.1.1. Спецификация Use Case «Искать КК»
1) наименование: «Искать КК»
2) акторы, взаимодействующие с Use Case: Менеджер
3) описание: Клиент хочет, чтобы менеджер выполнил один из трех Бпр: а) принял от клиента залог и рассчитал сумму займа; б) оформил выкуп всех залогов по предъявленному клиентом ЗБ; в) оформил выкуп некоторых из залогов по предъявленному клиентом ЗБ (т.е. провел Бпр перезалога). В последнем случае клиент хочет подобрать удобное для него подмножество выкупаемых залогов из всего множества залогов, оформленных в предъявленном им ЗБ (в ЗБ может быть не более 5 залогов одного типа). Во всех трех случаях менеджер использует номер паспорта клиента (имеется в виду серия паспорта + номер паспорта) для поиска электронной карты клиента в БД ИС. Цель – открыть карту клиента.
4) авторы Use Case:
Проектировщик ИС и аналитик БП и Бпр ломбарда.
5) географическое местоположение Use Case:
В здании ломбарда.
6) статус:
Elaboration
7) приоритет:
Высокий
8) предположения:
Верно - Если для клиента проводили залоговые операции не далее чем 24 месяца назад, то его карточка есть в БД.
Верно - Если есть карточка клиента, то в его карточке есть список залоговых билетов (>=1).
Неверно – Можно найти карту клиента без его номера паспорта.
Неверно – При изменении адреса клиента старый адрес сохраняется в ИС
9) предусловия:
Компьютер, выполняющий роль сервера БД должен быть включен; ЛВС должна работать; Клиентское приложение должно быть загружено; Актор должен иметь пароль для доступа к Use Case.
10) постусловия:
На экране должна появиться форма карточки клиента.
При открытии пустой карты клиента в БД создается соответствующая запись.
11) приоритетный или счастливый маршрут ppw:
Менеджер открывает форму поиска карты клиента
Менеджер вводит номер паспорта
Удаляются все пробелы во введенном выражении
Число оставшихся символов равно 10
Карта с таким номером паспорта найдена в БД
Открывается найденная карта клиента.
Данные карточки актуальны
Конец маршрута
12) альтернативные маршруты apw.
apw1:
Менеджер открывает форму поиска карты клиента
Менеджер вводит номер паспорта
Удаляются все пробелы во введенном выражении
Число оставшихся символов равно 10
Карта с таким номером паспорта НЕ найдена в БД
Автоматически вызывается Use Case «Создать новую карту клиента» в котором открывается пустая карта (это новый клиент или клиент не проводивший операций более 24 месяцев)
Менеджер заполняет созданную карту клиента
Конец маршрута
apw2:
Менеджер открывает форму поиска карты клиента
Менеджер вводит номер паспорта
Удаляются все пробелы во введенном выражении
Число оставшихся символов равно 10
Карта с таким номером паспорта найдена в БД
Открывается найденная карта клиента.
Данные карточки НЕ актуальны
Автоматически вызывается Use Case «Редактировать карту клиента»
Менеджер актуализирует данные карточки клиента
Значения полей карточки клиента в БД обновляются
apw3:
Других альтернативных маршрутов нет.
13) исключающие маршруты:
Менеджер открывает форму поиска карты клиента
Менеджер вводит номер паспорта
Удаляются все пробелы во введенном выражении
Число оставшихся символов равно НЕ равно 10
Выводится сообщение: «Номер паспорта введен неверно»
Форма поиска карты клиента приводится в исходное (пустое) состояние
Конец маршрута
На рис.2.9. изображена диаграмма действий, отражающая все маршруты Use Case «Искать КК».
Рис. 2.9. Диаграмма действий, отражающая маршруты Use Case «Искать КК».
2.2.1.2. Спецификация Use Case «Создать новый ЗБ»
1) наименование: Создать новый ЗБ
2) акторы, взаимодействующие с Use Case: Менеджер
3) описание: Цель – оформить прием залогов от клиента в новом залоговом билете. Менеджер сравнивает в карточке клиента залоги прежних операций (если они есть) с принесенными клиентом залогами. Если залоги сдаются повторно, то менеджер из карточки клиента открывает соответствующий ЗБ и переходит на создание его копии. Иначе менеджер из карточки клиента открывает пустую форму ЗБ, соответствующую типу залога. Менеджер заполняет поля формы, используя справочники ДЕФЕКТЫ, КАТЕГОРИИ, ОГРАНКИ, КОЭФФИЦИЕНТЫ_ОЦЕНКИ, ПРОБЫ, ПРИЗНАКИ. Автоматически рассчитывается сумма оценки и сумма займа. Если клиент согласен с ними, то печатается 2 экземпляра созданного ЗБ. Если клиент не согласен, созданный ЗБ удаляется.
В одном ЗБ не более 5 залогов. Для каждого из 4-х типов залогов: Бриллианты (А), Ювелирные изделия (ЮИ), Бытовая техника (БТ) и Одежда/Меха (МХ) имеется своя форма ЗБ.
4) авторы (authors) варианта использования:
Проектировщик ИС и аналитик БП и Бпр ломбарда.
5) географическое местоположение Use Case:
В здании ломбарда.
6) статус:
Elaboration
7) приоритет;
Высокий
8) предположения:
Верно – Для залога, сдаваемого повторно, можно его скопировать в новый ЗБ и затем отредактировать.
Верно – Можно несколько залогов из одного старого ЗБ скопировать в один новый ЗБ.
Неверно – Можно скопировать залоги из разных старых ЗБ в один новый.
9) предусловия:
Те же что и в Use Case «Искать КК»
Справочники системы должны быть акуальными.
10) постусловия:
В случае согласия клиента в БД сохраняется запись о новом ЗБ, в случае несогласия, запись, соответствующая новому ЗБ НЕ сохраняется в БД.
11) приоритетный или счастливый маршрут ppw:
Менеджер проверяет совпадение старых и новых залогов.
Найден старый ЗБ, в котором описаны принесенные клиентом залоги.
Менеджер создает копию этого ЗБ
Менеджер удаляет из копии ненужные залоги
Менеджер редактирует изменившиеся данные ЗБ (например, фиксирует новые поврежденияи, может, советуясь с товароведом).
Автоматически рассчитывается сумма оценки и сумма займа.
Клиент согласен с расчетами.
Печать двух копий ЗБ.
Конец маршрута.
12) альтернативные маршруты apw:
apw1:
Менеджер проверяет совпадение старых и новых залогов.
НЕ найден старый ЗБ, в котором описаны принесенные клиентом залоги.
Менеджер открывает соответствующую форму ЗБ
Менеджер заполняет поля формы ЗБ (возможно, советуясь с товароведом)
Автоматически рассчитывается сумма оценки и сумма займа.
Клиент согласен с расчетами.
Печать двух копий ЗБ.
Конец маршрута.
apw2:
……………………
Автоматически рассчитывается сумма оценки и сумма займа.
Клиент НЕ согласен с расчетами.
Менеджер удаляет созданный ЗБ из БД.
Конец маршрута.
apw3:
Других альтернативных маршрутов нет.
13) исключающие маршруты:
Исключающих маршрутов нет.
На рис.2.10. изображена диаграмма действий, отражающая все маршруты Use Case «Создать новый ЗБ».
Рис. 2.10. Диаграмма действий, отражающая маршруты Use Case
«Создать новый ЗБ».
Аналогично были созданы спецификации для остальных Use Cases.
2.2.2. Спецификация классов и инфологическая модель ИС «Ломбард»
Прежде чем формулировать спецификации классов поясним понятие класса, следуя [3].
Класс (class) - это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.
Каждый объект является экземпляром конкретного класса и не может быть экземпляром нескольких классов. Например, класс учебный курс может определяться следующими характеристиками:
•атрибуты - место занятий, время занятий;
•операции - получить место занятий, получить время занятий, добавить студента на курс.
Алгебра 101, секция 1 и Алгебра 101, секция 2 - это объекты, принадлежащие классу учебный курс. Каждый объект имеет значения атрибутов и доступ к операциям, определенным классом учебный курс.
"Хороший" класс представляет одну и только одну абстракцию, то есть должен отражать одну основную сущность. Например, класс, способный хранить информацию о студентах и данные о курсах, которые студент посещает в течение нескольких лет, не является "хорошим" классом, потому что не представляет одну сущность. Такой класс необходимо разделить на два связанных класса:- студент и история студента.
Названия классов выбираются в соответствии с понятиями предметной области. Имя должно быть существительным в единственном числе, наиболее точно характеризующим предмет. В качестве имени класса можно использовать акроним, если он имеет одинаковое значение для всех представляемых сущностей. При использовании акронима в описании класса желательно указать полное название.
В языке UML классы изображаются в виде разделенных прямоугольников. В верхней секции указывается имя класса, средняя секция содержит его структуру - атрибуты, а нижняя описывает его поведение - операции.
Проведенный Use Case анализ позволяет выделить следующие основные классы ИС «Ломбард»: КЛИЕНТ, ЗАЛОГОВЫЙ БИЛЕТ, СОТРУДНИК, ЗАЛОГ, ЗАЛОГ БТ, ЗАЛОГ ЮИ, ЗАЛОГ МХ, ЗАЛОГ БРИЛЛИАНТЫ.
Эти классы несут основную нагрузку по хранению и обработке данных. Чтобы отразить особенности расчета суммы оценки и суммы займа для каждого типа залога (А, ЮИ, БТ, МХ), удобно воспользоваться ассоциацией обобщения, связывающей так называемый «суперкласс» с более специфическими подклассами. В ИС «Ломбард» залоги всех 4- х типов имеют много одинаковых атрибутов.
Но есть атрибуты и операции, присущие только одному типу залога. Выделим общие атрибуты в суперкласс ЗАЛОГ. На рис. 2.11. представлена диаграмма классов ИС «Ломбард», одновременно являющаяся инфологической моделью этой информационной системы.
Рис.2.11 Диаграмма классов (инфологическая модель) ИС «Ломбард»
2.2.3. Проектирование прототипов пользовательского интерфейса
ИС «Ломбард»
После построения статических моделей проектируемой ИС, к которым относятся: диаграмма компонентов или предварительной архитектуры (рис.2.5); диаграммы Use Case (рис.2.7. и рис. 2.8.); диаграмма классов (рис. 2.11.) – можно переходить к построению динамических моделей ИС. Как правило начинают с создания прототипов пользовательского интерфейса – UI (user interface).
Сначала представим схемы диалоговых окон, поддерживающих взаимодействие акторов с ИС в рамках всех основных (с высшим приоритетом) вариантов использования. Для спецификации требований UI воспользуемся понятием артефакта, широко применяемого в теории проектирования ИС.
Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом.
Таблица 2.4.
| Use Case | Артефакты UI |
| Искать КК | Требует пароля и ввода номера паспорта Требуется быстрый переход к этой функции из любого места приложения. |
| Создать КК | Требует использования справочников улиц, районов, регионов. |
| Редактировать КК | Форма КК должна быть удобна для работы мышкой |
| Выбрать и открыть ЗБ | В карточке клиента должны быть все его ЗБ, созданные не далее 24 месяцев с текущего дня. |
| Создать новый ЗБ | Из карточки клиента можно открыть ЗБ для оформления залога любого типа. |
| Открыть и заполнить карту выкупа залога | Из ЗБ должен быть быстрый выход на карту выкупа. |
| Сделать пробный расчет выкупа | Менеджер должен иметь возможность пометить залоги, намеченные клиентом к выкупу (если он не может выкупить все залоги сразу) |
Для удовлетворения требований, приведенных в таблице 2.4., в клиентском приложении были разработаны диалоговые формы, представленные на рис.
рис.2.12 – Начальный вход в систему
рис.2.13 – Запрос пароля при вызове Use Case «Искать КК»
рис.2.14 – Диалоговое окно ввода номера паспорта
рис.2.15 – Карточка клиента
На рисунке 2.15 форма карточки клиента имеет поле, в котором размещается список залоговых билетов (на рисунке их два). При выделении мышкой элемента списка в поле справа появляется описание залогов, содержащихся в данном ЗБ.
В нижней части формы расположены кнопки для создания новых залоговых билетов разных типов данного клиента. При создании нового ЗБ он тут же добавляется в список ЗБ. На рисунке видно, что поле «Дата выкупа» - пустое. Значит для этих двух залоговых билетов можно провести операцию выкупа. Чтобы перейти в карточку выкупа достаточно выполнить двойной клик мышкой по соответствующему элементу списка ЗБ (рис. 2.16)
Рис.2.16. Карточка выкупа
Рис.2.17. Карточка нового залогового билета для залогов типа ЮИ.
2.2.4. Схема БД (даталогическая модель) ИС «Ломбард»
В результате выполненных шагов проектирования ИС «Ломбард» определились основные таблицы БД (рис. 2.18), их поля и связи (рис.2.19).
Рис.2.18. Список таблиц БД ИС «Ломбард».
Рис.2.19. Схема БД (даталогическая модель) ИС «Ломбард».