Проектирование информационных систем. Технология программирования

Проектирование ИС

• Введение в проектирование ИС. Инженерия требований
• Проектирование ИС: поведение и структура. UML. Проектирование БД
• Сервис-ориентированный подход в проектировании ИС
• Итеративное проектирование ИС с использованием облачных вычислений

Технология программирования

• Понятие технологии программирования. Жизненный цикл программы
• Организация проектов разработки ПО. Организация групп разработчиков
• Разработка ПО. Организация групповой разработки. Контроль версий
• Разработка с использованием облачных сервисов. Сервисные контракты. Учет надежности и планирование мощностей. SLA
• Реляционные и нереляционные БД: особенности применения, информационное обеспечение
• Качество ПО. Тестирование. TDD, BDD, приёмочное тестирование
• Документирование разработки

• Цели дисциплины
• Основные понятия
• Введение в UC approach к проектированию ИС

Проектирование ИС как научная дисциплина занимается изучением процесса создания промышленных продуктов – сложных (больших) информационных систем

Процесс создания сложных ИС характеризуется:

• структурной сложностью организационных систем и предметной области
• сложностью определения требований к ИС
• отсутствием формальных средств описания требований к ИС
• коллективной разработкой
• неопходимостью повторного использования кода и модулей

Problem (Oxford Dictionary):

1 a matter or situation regarded as unwelcome or harmful and needing to be dealt with and overcome; a thing that is difficult to achieve

2 an inquiry starting from given conditions to investigate or demonstrate a fact, result, or law.

• (2) — Problem = Задача
• (1) — Problem = Проблема

Problem: a matter or situation regarded as unwelcome or harmful and needing to be dealt with and overcome. (Oxford English Dictionary)

• Объективный аспект (situation)+ Субъективный аспект (regarded — by whom?)

Проблема — субъективное отрицательное отношение субъекта к реальности. (Тарасенко, 2010)

• Описывает проблемы любого происхождения
• Указывает, что проблем не существует “в реальности” (без субъекта)

Предположение (допущение) (Assumption) — фиксируемый нами (исходя из наших представлений о ситуации) один из вариантов неопределнности.

Например, мы допускаем, что стейкхолдер склонен к риску, что исполнителю доступен определенный инструмент, что температура на улице близка к 6 градусам.

Предположения и ограничения необходимо описывать явно во всех случаях, когда они могут быть не очевидны для любой из сторон.

• Система. Открытые vs закрытые
• Проблема vs Цель
• Информационные системы как Социотехнические системы

• Функциональные и нефункциональные требования к ИС. Пирамида требований
• UC как способ фиксации функц. требований
• UC модель

UC описывает последовательность взаимодействия эктора и системы, приводящее к ценному для этого эктора результату

• Последовательность взаимодействия: Описывает набор атомарных взаимодействий (interactions) между пользователем и системой, инициируемую Эктором. Каждое действие в последовательности атомарно, то есть выполняется целиком или не выполняется совсем.
• Система: System under development
• Ценный результат:
  • Для кого?
  • В каком контексте?
  • Определяет детальность UC

• Список “Эктор – цель” составляет кракое описание ценности, приносимой системой пользователям и организации и составляет основу планирования проекта
• Основной сценарий UC является соглашением сторон о том, что система должна (и что не должна) делать, определяя контекст для каждого требования

• Условия расширения дают механизм исследования неочевидных ветвлений, потенциальных отказов, которые иногда поглощают до 80% времени проекта, позволяя заранее отмечать возможные трудности и неясности
• Сценарии UC повзоляют ответить на многие сложные вопросы о деталях бизнес-логики, используя традиционную систему (if…then…else), которой легко оперировать и разработчикам и аналитикам

• Полный набор (модель) UC показывает, что разработчики продумали все пользовательские потребности и цели по отношению к системе

UC описывает последовательность взаимодействия эктора и системы, приводящее к ценному для этого эктора результату

Эктор – кто-то или что-то взаимодействующее с системой извне

Классы:

• Users (Пользователи)
• Системы/Приложения
• Устройства

• Стейкхолдер vs эктор
• Экторы. Напоминание о границах системы

Типы (по отношению к системе: Кто кого пинает):

• Первичные
• Вторичные

• Выявление экторов
• Выявление целей
• Опять вполне социологическая задачка: анализ связей, соцсетей и источников
• (*) Планирование разработки: приоритет(заказчик) и трудоёмкость (разработчик)

Проект: ИС взаимодействия с клиентами банка

Включает сеть банкоматов, терминалы оплаты по картам, инфокиоски, интернет-банк.

• Клиент банка

  • Снять деньги со счёта.
  • Заплатить за телефон.

• Торговая точка

  • Принимать платежи от клиентов (через терминал).

• Заголовок
• Эктор
• Краткое описание
• Поток событий
  • Основной поток (Basic flow)
  • Альтернативные потоки (Alternative flows)
• Затрагиваемые стейкхолдеры
• Предусловия
• Гарантии успеха и минимальные гарантии
• Затрагиваемые сущности предметной области

• Заголовок – цель эктора в контексте системы
• Эктор
• Краткое описание

• Затрагиваемые стейкхолдеры
• Предусловия
• Гарантии успеха и минимальные гарантии

• Поток событий (Flow of events)
  • Основной поток (Basic flow)
  • Альтернативные потоки (Alternative flows)

• Поток событий (Flow of events)
  • Основной поток (Basic flow)
  • Альтернативные потоки (Alternative flows)

Пример: Оплата по карте в терминале. Basic flow

• Получаем с ККМ сумму
• Приглашаем пользователя вставить карту
• Подтверждаем работоспособность карты
• Подтверждаем правильность пин-кода
• Вызываем Процедуру Списания
• Просим забрать карту

Каких шагов не хватает?

• Поток событий (Flow of events)
  • Основной поток (Basic flow)
  • Альтернативные потоки (Alternative flows):
  • Условие расширения
  • Обработчик расширения

Пример: Оплата по карте в терминале. Alternative flows

Терминал не может связаться с сервером

1 Шаг обработки расширения 2 ….

Ещё примеры?

• Поток событий (Flow of events)
  • Основной поток (Basic flow)
  • Альтернативные потоки (Alternative flows):
  • Условие расширения
  • Обработчик расширения

Терминал не может связаться с сервером

1 Отобразить сообщение о невозможности оплаты 2 Предложить повторить операцию

Подумаем над примером

Банк вернул ответ “недостаточно средств”

1 …

• Счёт

  • Номер счёта
  • Имя клиента
  • Состояние: Активный/заблокированный

• Карта

  • Номер карты
  • Пин-код (и код безопасности)
  • Имя на карте
  • Срок действия

• Заголовок

  Снятие денег со счёта клиентом через банкомат

• Эктор

  Клиент банка

• Краткое описание

  Клиент снимает деньги со своего счёта в банке с использованием банковской карты

Предусловие:

• Вставлена банковская карта поддерживаемой системы (Visa, Mastecard)
  1. Клиент вводит пин-код
  2. Система подтвержает правильность введённого пин-кода
  3. Клиент вводит требуемую сумму
  4. Система подтверждает возможность выдачи введённой суммы
  5. Система учитывает выданную сумму
  6. Система выдаёт требуемую сумму
  7. Система возвращает клиенту банковскую карту
  8. Система выдаёт клиенту чек

На шаге Система подтвержает правильность введённого пин-кода

Условие: введён неправильный пин-код

1. Система сообщает клиенту об ошибке при проверке пин-кода
2. Система подтверждает возможность повторного введения пин-кода
3. Возврат к шагу Клиент вводит пин-код основного потока

• Банк
• Кредитный отдел банка
• Служба финансового мониторинга

• Гарантии успеха
  • Транзакция проведена по счёту клиента
  • Клиент получил запрошенную сумму денег и чек
  • Клиент получил свою карту назад
• Минимальные гарантии
  • Клиент получил свою карту назад
  • Деньги со счёт клиента не были списаны

• Банковская карта
• Счёт клиента

• Клиент
  • Снять деньги со счёта
  • Положить деньги на счёт
  • Заплатить
  • за телефон
  • коммунальные услуги
  • Заплатить за товар в торговой точке
• Торговая точка
  • Получить отчётность
  • Вернуть платёж клиенту
• Предприятие-работодатель
  • Начислить зарплату сотруднику

Будем мало говорить про проблемы, но это важно:

• http://www.wikihow.com/Define-a-Problem
• Расселл Л. Акофф, Джейсон Магидсон, Герберт Дж. Эддисон, Идеализированное проектирование. Как предотвратить завтрашний кризис сегодня. Создание будущего организации. (2007)
• Dean Leffingwell. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. (2011)
• Тарасенко Ф. П. Введение в системный анализ. Концептуальный подход. (2010)
• http://en.wikipedia.org/wiki/Problem_solving

• Лекцию читал: Илья Леонидович Мусабиров