Контекст системы

Работы этапа
предварительного анализа
Разработал Дубаков А.А.
Запрос информационного обслуживания

Проект начинается с запроса




Краткая формулировка проблемы,
возможности, директивы
Краткая формулировка ожидаемого решения
Результат рассмотрения (информационные
службы) – резолюция
По сути дела формируется идея проекта
(vision) размером не более половины
страницы
Пример идеи проекта



В фирме по аренде автомобилей резервирование, аренда
и оплата счетов должны быть автоматизированы с целью
увеличения дохода и повышения удобства
предоставления услуг клиентам и, следовательно,
рассматривается в контексте ИС
Новая система должна обеспечивать все функции,
непосредственно связанные с обработкой заказов, в том
числе, информацию о клиента (адрес, банк и т.п.),
резервирование и аренда автомобилей и оплата услуг.
Непрямые виды деятельности, непосредственно не
связанные с бизнесом, такие как внутренний учет,
планирование тарифов и услуг, перемещение
автомобилей и их местоположение не рассматриваются
как часть идеи системы.
Предварительный анализ
1.
2.
3.
4.
5.
6.
Отвечает на вопрос: «Стоит ли заниматься
проектом?» - Сложный вопрос (Технологии,
экономика, персонал, …)
Цель - идентифицировать проблему, определить
ее причины, охарактеризовать стратегию ее
разрешения.
Определяются границы проекта
Устанавливаются участники, бюджет проекта и план
проекта .
Выявление ограничений, налагаемых на решение
Основная задача обследования данного этапа оценка реального объема проекта, его целей и задач,
а также получение определений сущностей и
функций на высоком уровне.
Содержание работ предварительного анализа




Формируются вероятные технические подходы и ориентировочно
рассчитываются затраты на аппаратное обеспечение, закупаемое
программное обеспечение и разработку нового программного
обеспечения.
Если принимается решение о продолжении проекта, то для
проведения следующего этапа – анализа - уже имеются
представления об объеме проекта и смета затрат.
Всегда следует классифицировать планируемые функции системы
по степени важности. Один из возможных форматов
представления такой классификации - MuSCoW
Эта аббревиатура расшифровывается так: Must have необходимые функции; Should have - желательные функции; Could
have - возможные функции; Won't have - отсутствующие функции.
Варианты описания проблем

Проблемы могут быть текущими,
предполагаемыми или ожидаемыми и
формулирование проблемы включает
следующие элементы:



список наблюдаемых симптомов
установленных в измеряемой форме
список предполагаемых задач
предварительную оценку (понимания,
осуществимости, трудоемкости,…)
Формулировка проблемы





Проблема {Описание проблемы}
Воздействует на {указание лиц на которых
оказывает влияние данная проблема}
Результатом чего является {Описание
воздействия данной проблемы на
заинтересованных лиц и бизнес-процессы}
Выигрыш от {Указания предлагаемого
решения}
Может состоять в следующем {Список
основных предоставляемых решением
преимуществ}
Выявление причин проблемы

Семантический анализ причин –
факторов, влияющих на проблему диаграмма Ishikawa (Fishbone)
ельзя устранить все проблемы – необходимо вычленить корневые
Парето-диаграмма корневых причин
Примеры формулировки проблемы


Руководитель не может оперативно получить
информацию о финансовом положении
фирмы
Длительное ожидание в очереди заказчика
при выписке счета
Масштаб проблемы


Понимание масштаба проблемы, практически,
часто устанавливается как предварительная
ориентировочная стоимость системы
Примеры:


Ориентировочная стоимость системы составляет
500+/- 100 тыс. рублей
Предварительная оценка предполагает, что
коллективу из трех разработчиков будет
необходимо 6 месяцев для создания системы,
разрешающей проблему
Задачи


Предполагаемый процесс или процессы,
обычно установленные в терминах задач,
результаты действия которых, возможно,
будут способствовать решению проблемы
Примеры:



Автоматизировать выписку финансовых документов
и сократить время до 3-5 минут.
Оперативно обеспечить дозаказ продукции при
уменьшении запасов на 10% ниже порогового
уровня
Предоставлять руководству информацию о текущей
загрузке гостиничных номеров
Предварительный анализ бизнес-процессов



Таким образом, идентифицируются бизнес-процессы,
которые система должна поддерживать или которые
интегрируются, и формируется видение системы с
добавлением моделей вариантов использования - use
case diagram (для ООП) или контекстной диаграммы
потоков данных (для САП).
Идентифицированные бизнес-процессы следует
описать на данном этапе в абстрактных терминах,
используя диаграмму активности для каждого
варианта использования (для ООП) или транзакции (в
САП).
Также для каждого бизнес-процесса описываются, по
возможности, абстрактно, основные пользователи
системы.
Масштаб – границы системы

В результате выделяется система и
объекты/субъекты с ней взаимодействующие,
определяется контекст системы
взаимодействующие и определяется контекст
системы и принимаются другие решения, в том
числе:






Кто будет вести данные в системе
Кто будет администрировать систему
Кто будет сопровождать систему
Где будет использоваться система
Откуда система получает необходимые данные
С какими внешними системами взаимодействует
В терминах ООП



Идентифицировать варианты
использования.
Идентифицировать начало и конец
варианта использования с триггером и
полученными результатами.
Идентифицировать варианты бизнеспроцессов, которые исключаются (что не
делается системой).
Примеры вариантов использования





Обеспечение информации на
возможное резервирование
автомобиля.
Резервирование автомобиля.
Выполнение аренды (передача
автомобиля).
Прием автомобиля.
Оплата заказчика.
Вариант-Резервирование








Short description: Автомобиль резервируется для клиента на
определенный период
Actors: Сотрудник
Trigger: Клиент желает зарезервировать автомобиль
Preconditions: нет
Incoming information: Номер заказчика и другая информация,
желание зарезервировать автомобиль
Results: Резервирование, подтверждение резервирования
Postconditions: Автомобиль зарезервирован клиентом
Process
1. Идентифицировать клиента или создать нового
2. Регистрация намерения резервирования
3. Проверка возможности резервирования
4. Резервирование
5. Подтверждение резервирования
Для каждого варианта


Для какого пользователя создается вариант?
Риск. В какой степени воздействует этот use case на проект (
превышение стоимости, задержки, технические проблемы,
организационные проблемы, и др.)? Как велик риск?

Важность. Насколько важен это вариант (необходимый, важный,
полезный)? Какие преимущества вариант обеспечивает?



Стоимость. Насколько велика стоимость реализации варианта (в
человеко-днях)?
Стабильность. Как велика вероятность того, что вариант будет
предметом существенных изменений. (велика, средне, низко)?
Время , срочность. Желаемые сроки завершения реализации
варианта (на какой итерации или этапе)? Какое наиболее реальное
время реализации варианта (на какой итерации или этапе)? Шаги
должны быть сформулированы по возможности просто.
Use case - рекомендации





Короткое описание: делается короткое но достаточное описание,
для определения и отличия от других (например: кто (заказчик),
что (автомобиль, резерв), как (по телефону)).
Актор: например, “Звонок” определяется как актор, т.к. он
представляет заказчика.
Запуск: можно также добавить“... И выражает свое желание по
телефону,”.
Предварительные условия: здесь не определяется, т.к. может
произойти в любое время.
Предварительная информация: в абстрактном виде (“желание
резервирования”); это ничего если детали опускаются, поскольку
эта категория проектируется только для очерчивания основных
ситуаций
Use case-рекомендации




Постусловия: Просто описывается успешный желаемый вариант –
все остальное будет получено из последующих диаграмм (блоксхем, диаграмм последовательностей,…). Еще раз: на этом этапе
сохраняется краткость.
Идентифицировать заказчика: позвонивший становится
заказчиком. Постараться отличать тип одного заказчика от другого
(например резервирующего через интернет) . Конкретные
требования заказчика должны быть проверены техническими
специалистами.
Проверить возможность резервирования: Формулировка
должна быть расширена, т.к. не ясен результат. Положителен или
отрицателен? Существует один свободный автомобиль или список,
определенный тип или любой, критерии? Даже зная ответы на
эти вопросы следует оставить детали на следующий этап.
Резервирование автомобиля: Не опасаться давать имя для этого
шага такое же как варианту. Всегда существует фаза аналогичная
варианту, все другие шаги используются для подготовки,
установления границ контекста, проверки и оценки.
Система и ее окружение
Идентификация бизнес классов или сущностей



Идентифицировать наиболее важные объекты
предметной области и в зависимости от
методологии рассматривать их либо как
классы либо как сущности и моделировать
структурные связи в диаграмме.
Присвоить объектам/классам значимые
имена, имена связей, имена и роли связей, и
описать, если возможно, множественность.
На этот момент детали игнорируются
ОААD – модели спецификаций



Модели состояний – отображают
требования к данным
Модели поведения – представляют
функциональные требования
Модели изменения состояний – каким
образом действие приводит к
изменению данных.
Спецификация состояния




Состояние объекта определяется значением его
атрибутов и ассоциаций
Модель структуры данных является
спецификацией состояний и дает статический
взгляд
Задачей проектирования является
определение классов, атрибутов и
отношений с другими классами
Внимание на начальных стадиях уделяется
бизнес-объектам (на последующих этапах
появятся объекты реализации, такие как,
объекты взаимодействия, объекты доступа к
данным,…)
Моделирование классов




В основе ОО разработки система представляет
собой набор взаимодействующих объектов
Процесс выявления классов носит итеративный
пошаговый характер и успех зависит от уровня
квалификации и опыта аналитика: знание и
понимание предметной области, опыт
аналогичных проектов, способность предвидеть
и готовность к пересмотру модели
Говорят, что научить ООАП нельзя, но можно
научиться
Применение CASE-технологий для групповой
работы и для персональной эффективности
Выявление классов


Два разных аналитика не придут к
идентичным моделям классов одной и
той же проблемной области.
Способы выявления классов





Именные группы
Общие шаблоны классов
На основе прецедентов
CRC – class-responsibility-collaboration
Смешанный
Именные группы


Имя существительное в описании –
потенциальный класс
Три вида потенциальных класса




Подходящие - безусловно
Сомнительные – нет уверенности
Неподходящие– за рамками предметной
области
Естественно, предполагается, что
описанная спецификация требований
корректны и полны
Общие шаблоны для классов



Позволяет вывести кандидатов в классы на основе
теории классификации объектов
Один из возможных шаблонов
 Понятийный класс (идея) – резервирование
 Событийный класс – Прибытие
 Организационный класс – Бюро путешествий
 Люди (роль) – Пассажир
 Класс местоположений - Офис бюро путешествий
Существуют и другие классификации: физический
класс (самолет), бизнес-класс(резервирование),
логический класс (расписание), прикладной класс
(операция резервирования), компьютерный класс
(индекс), поведенческий класс (отмена
резервирования)
На использовании прецедентов




Подход снизу-вверх предполагает что:
 разработаны Use Case Diagram и возможно
несколько диаграмм последовательностей
 Существуют описания для каждого
прецедента
Представление о системе, полученное UCD
частично определено с помощью диаграмм
последовательностей, объекты приводят к
выявлению классов
Аналогично подходу именных групп - в обоих
прецеденты формируют требования
Приводит к функциональному подходу
CRC- class-responsibility-collaboration






CRC – это больше чем технология выявления классов –
интерпретация и изучение объектов во время
«мозгового шторма».
Живой процесс с карточками, в котором «игроки»
заполняют карточки.
На основе анализа взаимодействия во время
выполнения бизнес-функций идентифицируются
классы и их ответственность.
Если возникает потребность в услуге, не закрепленной
за классом, создается новый класс , которому
назначаются свойства, ответственности и кооперация.
Если класс слишком «занят» - разделяется
Всякий раз, когда сервис или данные предоставляются
одним объектом для другого, устанавливаются
отношения клиент - сервер
Пример CRC -карточки



Начнинается с выделения
классов, обязанностей и
сотрудничества, которые
необходимо поддерживать для
каждого варианта использования.
Для каждого нового класса на
пронумерованной карточке пишется
имя класса (существительное в
единственном числе)
Затем в части карточки запишите
обязанности класса в левой стороне и
требуемые сотрудничествущие классы
для выполнения ответственности
(сервер) в правой стороне.
Смешанный подход



Возможен с элементами всех четырех
подходов
Из середины вместо сверху вниз или снизу
вверх
Сценарий:




Начальные классы на основе знаний
проблемной области
Руководствоваться подходом на основе общих
шаблонов классов
Имена существительных и UCD
CRC «мозговой штурм»
Рекомендации для выявления классов





Формулируется назначение класса в системе
Класс - шаблон множества объектов
Класс должен содержать атрибуты,
идентифицирующие атрибуты (Key)
Решается вопрос: класс или атрибут
Класс должен содержать набор
операций, который является
логическим следствием назначения
класса
Объекты предметной области
Запись на курсы
Выявление ограничений системы


Ограничения уменьшают степень
свободы, которой мы располагаем
при разработке решения
Ограничения могут быть заданы до
начала работы, однако, их, как
правило, приходится и выявлять и в
процессе разработки системы
Источники ограничений






Экономический - финансы
Политический – отношения между
подразделениями
Технический – технологии, программы
Системный – операц. сист, совместимость
Эксплуатационный – инф. среда,
безопасность, стандарты, юр. огран.
График и ресурсы – ограничения ресурсов,
аутсорсинг, увеличение штата (врем. или
постоянно)
Объем работ (scope statement)


Объем работ связан с четырьмя стандартными блоками этой фазы:
 Объекты бизнеса определяет границы для данных. Это может
быть простой список объектов, о которых системе необходимо
знать информацию.
 Функции бизнеса определяет границы процессов. Это может
быть простой список выполняемых бизнес функций, которые
следует включать в систему или находящихся под влиянием
системы.
 Контекст системы определяет границы для интерфейсов.
Это могут быть список внешних людей, части организации,
организации или другие системы с которыми наша система
должна взаимодействовать.
 Размещение выполнения определяет область
распределения. Это может быть простой список размещения
по подразделениям бизнес-операций, которые будут включены в
масштаб проекта.
Отметим, что на данном этапе каждая формулировка границ
описывается как простой список. Нет необходимости определять
элементы списка, точно их формулировать, а также заботиться о
необходимом времени выполнения моделей и прототипирования.
Пример формулировки проблем
Планирование проекта
 Вне зависимости от методологии разработки, тем или иным
способом, выполняется планирование всего проекта и
следующей фазы.
 Начальный план должен состоять из:
• Чернового главного плана и графика для выполнения
всего проекта. Этот график будет модифицироваться
в конце каждой фазы проекта.
• Детального плана и графика выполнения следующей
фазы проекта (обследование и анализ системы). В
большинстве случаев этот график будет более
точный, но страдает отсутствием детальных знаний о
текущей системе и требованиях пользователей.
 В соответствии с графиком выполняется распределение
ресурсов.
Представление проекта
 Во многих организациях существует больше
потенциальных проектов чем финансовых
возможностей и исполнителей.
 Если для проекта не определен наивысший
приоритет (не входит в стратегический или
оперативный план), то он должен быть
представлен и защищен перед руководством с
целью одобрения. (НТП университета)
 Руководство изучает и ранжирует предложения
конкурирующих проектов с целью определения
проекта, который будет наиболее ценный для
организации и будет одобрен (читай выделено
финансирование) для дальнейшей разработки
системы.
Представление проекта
 Основной
результат – одобрение проекта
для продолжения на следующей фазе –
обследования и ангализа.
 Представление может принимать форму
совещания, устного выступления,
печатного документа (возможно
разрешение на разработку проекта или,
его резюме), служебная записка
руководству или любая комбинация этих
форматов.
Принятие решения о продолжении


Если проект одобряется, то готовится
предложение о проведении
анализа системы, ему назначается
приоритет, он попадает в главный
план, и группа разработчиков
начинает этап анализа.
В некоторых методологиях
осуществляется переход к разработке
очередной версии системы.