Семинары

Семинар 1

1. Пример "плохой" системы без цели. Камень - не имеет конкретной цели.

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

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

Пример "хорошего проекта" неавтоматизируемой системы: до конца дня поменять лампочку в левой передней фаре машины Ford Focus

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

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

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

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

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

Семинар 2

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

• Система - двигатель.
• Подсистема - топливо.
• Надсистема - автомобиль.

Хорошая система:

• Система - приём заявок по ремонту компьютеров.
• Подсистема - направление заявок сервисному инженеру компьютерной техники.
• Надсистема - компания по ремонту компьютеров.

Семинар 3

Пример цикла Деминга: Создание веб-сайта интернет-магазина.

• Plan (планирование): формирование целей разработки, функций, которые должны быть реализованы, составление технического задания для будущего сайта, выбор языков программирования и сред разработки, БД, CMS и т.д.
• Do (выполнение): написание программного кода, создание и верстка дизайна интерфейса сайта.
• Check (проверка): проведение тестирования сайта на работоспособность всех функций, на уязвимости, на дизайнерские недостатки или «баги».
• Act (улучшение): доведение функций, не соответствующих требованиям, до полной работоспособности. Исправление всех ошибок.

Задание 2:

Для предыдущего примера:

• Муда – повторная переработка дизайна веб-сайта в связи с неправильно и неточно разработанным ТЗ, приводящая к потере времени.
• Мура – отсутствие нужных специалистов по сложному вопросу при наличии множества специалистов по более легкому; внесение серьезных правок в ТЗ непосредственно перед окончанием срока завершения работ, что ведет к резкому возрастанию нагрузки в определенный момент.
• Мури – выбор серверов для БД, которые не отвечают по своей мощности требуемым характеристикам (объем хранимых данных, производительность и т.д.)

Семинар 4

1. Антипаттерн разработки - Жесткий код (Hard code) Избыточно сильная привязка программного кода к конкретной программной, аппаратной или системной конфигурации.
2. Архитектурный антипаттерн - Тупик (Dead End) Модификация повторно используемого программного компонента, поддержка которого уже была прекращена ранее, что влечет за собой необходимость возобновлять его сопровождение.
3. Организационный антипаттерн - Охота на ведьм (Witch Hunt) Попытка найти проблему неуспеха проекта только в некомпетентности конкретных руководителей либо исполнителей, и решить её исключительно сменой команды разработчиков, либо менеджеров.
4. Антипаттерн среды - Босые дети (Shoeless children) Суть данного антипаттерна состоит в игнорировании внутренних потребностей компании и распределении всех доступных ресурсов на реализацию текущих внешних проектов.