Skip to content

Seminars

Jump to bottom
Ружейников Михаил edited this page Oct 26, 2019 · 2 revisions

Семинары

Семинар 1

  1. Плохая система: молоток. Является инструментом, для достижения цели (забить гвозди), но сам по себе не имеет цели.

2.1 Пример "плохого проекта" неавтоматизируемой системы: сделать заказ.

  • Конкретность: не известно что нужно заказать и для чего.
  • Измеримость: не измерима.
  • Достижимость: неизвестно, так как не указано никаких условий и временных рамок.
  • Значимость: имеет значимость только при выполнении определенных условий.
  • Ограниченность во времени: ограниченность не указана.

2.2 Пример "плохого проекта" неавтоматизируемой системы: сделать заказ телефона со скидкой до 31.12.2019.

  • Конкретность: известно, нужно купить телефон со скидкой.
  • Измеримость: цена телефона.
  • Достижимость: цель достижима и может быть проверена на соответствие поставленной цели.
  • Значимость: без телефона ты никто.
  • Ограниченность во времени: цель ограничена (до 31.12.2019).

3.1 Пример "плохого проекта" автоматизируемой системы: автоматизация приема заявок

  • Конкретность: не известно каких заявок и каким образом автоматизировать.
  • Измеримость: отсутствуют критерии улучшения, а значит измеримость не обеспечивается
  • Достижимость: не достижима, в силу отсутствия корректных требований и ограничений.
  • Значимость: уменьшение "ручного труда", повышение производительности.
  • Ограниченность во времени: отсутствует.

3.2 Пример "хорошего проекта" автоматизируемой системы: автоматизация приема заявок на техническую поддержку с помощью разработки портала до 31.12.2019

  • Конкретность: указан вид заявок и способ достижения.
  • Измеримость: измерима, скорость обработки заявок.
  • Достижимость: достижима.
  • Значимость: повышение эффективности и увеличение скорости обработки заявок.
  • Ограниченность во времени: до 31.12.2019.

Семинар 2

Плохая система:

  • Система - Молоток
  • Подсистема - Гвоздодер молотка
  • Надсистема - Работник

Система с целью:

  • Система - Автоматизация приема заявок
  • Подсистема - Внутренняя Wiki по тикетам
  • Надсистема - Портал компании

Семинар 3

Задание 1: Пример цикла Деминга: разработка портала для приема заявок на техническую поддержку

  • Plan (планирование): постановка целей и задач, составление технического задания, определение необходимых модулей и взаимосвязей.

  • Do (выполнение): реализация портала в соответствие с тз.

  • Check (проверка): функциональное тестирование портала и проверка на отказоустойчивость при высоких нагрузках.

  • Update (улучшения): на основании полученных данных от клиентов внесение исправлений и повторное тестирование.

    Задание 2:

  • Муда - неоднократное тестирование продукта, необходимое для выявления ошибок, что, в свою очередь, затратно. Но без этого этапа портал не будет запущен.

  • Мура - реализацией технической части занимается 3-4, при этом разработкой бизнес-процесса 1-2.

  • Мури - некачественное тестирование на отказоустойчивость привело к падению портала во время пиковой нагрузки.

Семинар 4

  1. Антипаттерны разработки - Равиоли-код (Ravioli code, или «пельмени») - объекты настолько «склеены» между собой, что практически не допускают рефакторинга;
  2. Архитектурные антипаттерны - Раздувание ПО (Software bloat) - разрешение последующим версиям системы требовать все больше и больше ресурсов;
  3. Организационные антипаттерны - Замыкание на поставщике (Vendor lock-in) - исполнение системы таким образом, что она оказывается привязанной к её поставщику;
  4. Антипаттерны среды - Босые дети (Shoeless children) Суть данного антипаттерна состоит в игнорировании внутренних потребностей компании и распределении всех доступных ресурсов на реализацию текущих внешних проектов.
Clone this wiki locally