Проектирование: как выполнять декомпозицию задачи?

Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок:

• "Спроектируйте графический редактор".
• "Спроектируйте игру для девочек 4 – 8 лет".
• "Спроектируйте GPS-навигационную систему для мобильного телефона".

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

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

1. выполнить декомпозицию задачи на подзадачи;
2. оценить объём полученных подзадач;
3. составить план работы, упорядочив подзадачи во времени и распределив их между участниками команды.

Рассмотрим эту процедуру на примере проектирования графического редактора.

Литература

Решил систематизировать некоторые свои публикации по четырём темам:

1)      Ошибки в программировании

2)      Проектирование игр и программ

3)      Продвижение программ и услуг по их разработке

4)      Проектирование нового продукта (hard & soft)

Общение с заказчиком: переходим на язык задач и проблем

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

Мне часто приходилось слышать о том, что неправильный дизайн системы существенно увеличивает затраты на разработку. Это действительно так. Думаю, немногие попытаются опровергнуть данное утверждение. Согласно моему опыту неправильная архитектура может увеличить затраты на 50, 80 и даже 90 процентов.

Такой перерасход бюджета является серьёзной проблемой, но не катастрофой. Последствия плохой архитектуры могут быть частично скомпенсированы хорошим менеджментом (== грамотным распределением задач) и, наоборот, плохой менеджмент может быть частично скомпенсирован хорошим дизайном. Почему? Потому что хороший дизайн вызывает меньше проблем и, как следствие, уменьшает нагрузку на менеджера.

Более страшной – в плане затрат– является неправильная постановка задачи. Потому что она увеличивает расходы в разы. (Запросто может увеличить бюджет в 2, в 3 и даже в 4 раза.) Здесь я имею в виду ситуацию, когда разработчики делают не то, что клиенту нужно, а реализуют то, что клиент говорит.

Проектирование архитектуры программы: постановка задачи

Первоначально я хотел продемонстрировать, как следует ставить задачи проектирования, на другом примере. Но поскольку на RSDN.RU возникло обсуждение задачи из моего блога, я решил не увеличивать число сущностей сверх необходимого и использовать уже готовый пример. :)

В своём сообщении коллега Undying сформулировал такие требования к кандидату:

С виду в задаче нет ничего уникального. От кандидата требуется иметь опыт реализации высоконагруженных серверных приложений работающих в режиме 24 * 7. Сложность только в том как понять, что человек не просто участвовал в разработке такой системы, а играл в этом ключевую роль. По идее проще всего это выяснить в беседе о том какие проблемы были встречены при реализации, как их решали, как производилось расширение и добавление функциональности.

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

Собеседование с архитектором: методические рекомендации

Предположим, существует идеальная методика, которая позволяет эффективно решать задачи проектирования.

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

Тогда процедура проверки квалификации архитектора сводится к проверке следованию им методике:

(1) Если архитектор в процессе проектирования следует рекомендациям методики, то мы считаем его квалифицированным.

(2) Если архитектор в процессе проектирования не следует рекомендациям методики, то мы упрощаем себе жизнь и считаем его неквалифицированным.

Попробуем предположить, какой должна быть эта методика.

Как собеседовать архитектора?

Как-то раз ходил на собеседование в одну компанию на должность архитектора. По результатам - завёл обсуждение на RSDN. Будет интересно, к чему это обсуждение приведёт. Текст моего поста:


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

Суть проблемы: Система, которую придётся рефакторить, состоит из двух составляющих:

(1) картографические данные, хранящиеся в БД на сервере;
(2) визуализация этих картографических данных, хранящаяся на другом сервере.

Дело в том, что с частью (1) работает огромное число пользователей. А наша система относится к части (2), с которой работает лишь небольшое подмножество пользователей части (1).

Основная проблема заключается в том, что пользователи части (2) вынуждены синхронизировать вручную визуальную информацию с актуальной картографической. Ситуация осложняется тем, что подобная синхронизация (== создание растрового изображения) занимает длительное время — несколько часов.

Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.

Подходы к решению:

1) Система (2) автоматически следит за данными в системе (1) и, если они обновились, перегенерирует растровое изображения изменённых участков. Недостаток: система (2) должна хранить данные из системы (1) для того, чтобы узнать, что они обновились.

2) Встроиться каким-либо образом между пользователями системы (1) и конечной базой данных для системы (1), чтобы отлавливать запросы на изменение данных. Если данные изменяются, то посылать уведомление системе (2) для того, чтобы она перегенерировала растровые изображения для изменённых данных.

3) Поработать над сокращением времени генерации растрового изображения.

Ситуация осложняется тем, что система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать данные в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это. Доступ к СУБД системы (1) возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.

Как проводят собеседования кандидата:

1) Просят рассказать о предыдущем опыте проектирования систем.
2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов.
3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений.

По п.п. 1 и 2 формально время не ограничивают. Но если за 5 минут кандидат не нарисует на бумаге дизайн системы, быстро теряют интерес и перебивают.

Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).

Как следствие, не понимают:

(1) важность перевода задачи из формы, как она сформулирована заказчиком (например, "спроектируйте текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов") в форму, пригодную для выработки технического решения;
(2) важность написания юз-кейсов для выполнения п. (1).

Резюме: ИМХО, подобный вариант проведения собеседования с архитектором не является эффективным.

Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:

(1) на разработку нового проекта с нуля;
(2) на масштабный рефакторинг готового проекта.

Просьба высказывать свои варианты и свои точки зрения.


P.S.: Чуть позже расскажу, как бы я проводил собеседование с кандидатом в архитекторы. Но сначала будет интересно узнать мнения коллег.