empty pages

Обзора этого набора на русском я не нашел, поэтому решил сделать его сам.

Артикул Lego: 8269

Год выпуска: 1999

Количество деталей: 329

Кол-во минифигурок: 1 (зато какая)

Описание: Bricker, Brickset, BrickLink, Peeron

Набор относится к соревновательной серии техник (Technic Competition), что подразумевает что набор позволит "соревноваться" двум игрокам.

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

Передняя вид коробки, что досталась мне, был очень печальный: порванная полоза по краю коробки.

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

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

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

Внимательно посмотрев на изображение стрекоз становится понятно что бирюзовая стрекоза интереснее – в ней есть летчик и в эту же коробку вложены мяч и конусы. Именно с этой стрекозы я и начал собирать:

Отдельно собирается хвост с кабиной, "жало" и крылья. Так же резиновые стяги ставятся в последний момент.

Стрекоза в сборе, летчик готовится к посадке в кабину.

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

К бою, летчик изучает мяч которым приодеться сражаться.

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

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

С закрытой пастью, готова к бою.

Встреча перед боем.

Насекомые спорят у кого жало больше.

А теперь самое интересное, механизм работы "жала": черно-желтый рычага на верху стрекозы толкает жало вперед, а оно уже в свою очередь ударяет по мячу.

Возвращается жало в исходное состояние с помощью двух резинок растяжек.

Резюме: Отличный набор, жаль человечек только в одной стрекозе. Детали неожиданного цвета (в рамках текущих техник наборов).

и еще пару фотографий:

Полевой ремонт спускового механизма.

Мяч действительно большой.

I’m spent this long weekend for study RXP protocol which IBM recommend to communicate with IBM Rational RequisitePro. (далее…)

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 не обозначив, как будут выбирать,  по какому критерию и вообще не держа в голове все возможные альтернативы решений.