Попытка моторизировать набор 8264

Грузовик Lego 8264 (Hauler)  сам по себе очень хорош: прост, изящен, интересный для детей механизм подъема кузова. Ниже о попытке улучшить этот набор с помощью дополнительных PF элементов.

Читать далее Попытка моторизировать набор 8264

Управление с помощью iPad

Давно горел желанием сделать управление машинкой, простроенной из лего, удобным и понятным. Ниже предлагаю описание проекта как я этого добился.

Читать далее Управление с помощью iPad

Lego колеса Rotacaster

Rotacaster Holonomic Robot Wheels

LEGO Rotacaster omni directional wheels — уникальные колеса от австралийской фирмы. Механизмы на этих колесах могут двигаться в двух направлениях — в привычном нам всем, и поперек.

Читать далее Lego колеса Rotacaster

Памятка: Принятие решений

0) Подумать, а на сколько критично вообще решение в данном вопросе.

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

SW:  решение о том на какой платформе стоит разрабатывать новый продукт — достойно формального анализа, а вот цвет кнопки  — может и не стоит анализировать, ее влияние на конечный результат минимально.

1) Определить критерии для оценки альтернатив

Обозначить величины и их приоритеты (если несколько критериев). Рекомендуется использовать опыт предыдущих анализов, очень вероятно что критерии повторятся.

SW: критерии для выбора платформы — доступность разработчиков под эту платформу, стоимость решений на этой платформе, потенциальная производительность, риски.

2) Обозначить альтернативы

Поиск альтернатив проводить как внутри команды, так и используя внешние знания (поиск, анализ конкурентов).

SW: кластерное решение системы управления базами данных: MS SQL server, Oracle, или как показал поиск по гуглу — то еще MySQL.

3) Выбрать способ оценки альтернатив

Совсем не стоит полностью строить решение на всех альтернативах что бы понять какие лучше. Может некий симулятор или проверка подмножества функций позволить уже оценить выбранные критерии в п2.

Понять во что обойдется (время, стоимость и пр) оценка альтернатив по выбранному способу.

SW: синтетические тесты, экспертная оценка, моделирование — первые пришедшие в голову примеры методик оценки.

4) Проанализировать альтернативы используя п1 и п2

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

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

SW: выполнить моделирование/тесты, выделить значния важных критериев, сохранить отчеты в репозиторий.

5) Выбрать из п2. базируясь на п1

Так как, часто анализ выполняется по моделям (то есть не полной информации), то при рекомендации одной из альтернатив не забыть указать в рисках, как было выбрана эта альтернатива.

SW: выбрали RAC Oracle, т.к. среди прочего показал больший рост производительности при добавлении ноды — риск: тестировали с ограничением на типы операций и объемы данных.

Резюме:

Звучит формально и надуманно, но забывать про первые три пункта не стоит. Опыт показывает, что все сразу приступают к п4 не обозначив, как будут выбирать,  по какому критерию и вообще не держа в голове все возможные альтернативы решений.