Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - SALar

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
181
Будьте проще. Нет в нотации UML инструмента "все и сразу", зато он есть за ее пределами  )
Отличная диаграмма!

Один из вариантов использования:

При работе с господрядчиками часто встречается ситуация, когда надо еще до обследования написать документ требований/архитектуры и изменять его потом нельзя. В результате вставляется диаграмма одновременно "обо всем" и "ни о чем". Под эту диаграмму можно подтянуть массу проектов и сказать что они ей соответствуют. Главное не сопровождать пояснениями!!!

* сделать надпись ESB, но не расписывать как и какие будут реализованы интервейсы
* нарисовать облако, написать интернет, но ни в коем случае не расписывать используемые протоколы
* нарисовать молнию, но не писать, то ли это Зевс поражающий титанов, то ли прогноз погоды

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

182
Примеры / Re: Полный комплект UML диаграмм
« : 22 Января 2014, 17:50:18 »
...
Без чего из этого списка можно обойтись, а что нужно обязательно?
P.S. Подскажите, пожалуйста, простенькую книжку для начинающих актуальную для UML 2.2.
У моих коллег будут другие мнения, я выскажу свое:
Обойтись можно безо всех. Но некоторые удобны для каких то иллюстраций.
  • * Чаще других я использовал диаграмму состояний.
  • * В том или ином виде использовал диаграмму размещения.
  • * Диаграмму юзкейсов не использую, хотя юзкекйсы пишу очень часто. Может быть это связано с тем, что я обычно работаю с довольно большими проектами. Предпоследний продукт, с которым я работал это около 12 000 юзкейсов уровня моря, а для такого числа диаграмма получится несколько большой. Да и структурирование с использованием оглавления и обобщенных вариантов мне кажется более наглядным.
  • По "Диаграмме классов" согласен с мнением одного классного программиста: "можно использовать для анализа кода после написания такового. Создание до написания кода - бессмысленно".
  • Вместо диаграммы активности предпочитаю EPC.
В Visio  UML реализован "не очень". Лучше использовать что-то специализированное. Мне нравилась visual paradigm, но на вкус и цвет все фломастеры разные.

183
Как я понимаю, ты считаешь, что студент должен понимать последствия архитектурной ошибки, различать архитектурные ошибки и уметь их не осуществлять (предвидеть)?
Предлагаю добавить еще:
* уметь классифицировать
* знать типовые ошибки разных классов систем

Итак мы ставим еще одну компетенцию: знать что такое UDDI и уметь что? описывать расположение веб-служб? каков контекст компетенции?
Я не говорю, что нужно знать конкретно эту тему. Но я полагаю, что знание большего числа проблем делает инженера более квалифицированным.
Что касается приоритетности изучения конкретных классов архитектурных ошибок, то я пока возьму паузу и послушаю остальных.
Согласен с тобой, что UDDI имеет смысл изучать, когда мы имеем дело с конкретным классом систем. И Вполне может быть, что инженер с этим классом за свою карьеру не столкнется.

Кроме знания архитектурных ошибок есть, видимо, и другие компетенции.
* Стоит знать нотации, для описания архитектуры.

184
Мне не нравится определение ieee 1471. Из него непонятно, что относить к архитектурным решениям.

Рассмотрим решение об [не]использовании UDDI. Архитектурное оно или нет?

-- определение ieee 1471 ----------------------
Ничего непонятно
--------------------------------------------------------

-- мое определение  -----------------------------
Да, вопрос об использовании UDDI относится к архитектурным.
1. Я регулярно наблюдал проблемы гетерогенных средств связанные с отсутствием UDDI.
2. Стоимость исправления растет со временем. Конечно не так, как jra-1330, но растет.
--------------------------------------------------------

185
Угу, согласен. Довольно сложно определить, какие вещи относятся к архитектуре, а какие нет. В умах, к несчастью, разруха и хаос.
Определение из википедии "Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними." Выглядит красиво, но совершенно бесполезно.

Я попробовал станцевать с другой стороны:
Цитировать
Сначала определим термин "архитектурная ошибка". Архитектурная ошибка - это реализация в коде, которая обладает следующими качествами:
1. удорожает изменение системы и/или делает невозможным удовлетворение потребностей заинтересованных лиц.
2. стоимость изменения этого решения сильно растет со временем.
Описанием архитектуры назовем такое описание, где возможно совершить архитектурную ошибку.[/i]

Пример. Выбор платформы реализации позволяет допустить архитектурную ошибку. Т.к.:
1. выбор аксесса сильно ограничивает  масштабирование по числу пользователей
2. Смена платформы сильно растет со временем.
Если такое определение годится, то готов показать причины, по которым я отнес вопросы к архитектурным.
Но сначала давай придем к соглашению по определению.

186
Согласна с тем, что "при помощи пряника можно и убить" энтузиазм. НО. Рекомендую Вам почитать внимательнее про наше KPI-решение. Так как Вы ошибочно предполагаете, что оно основано на банальной схеме с премированием персонала. Хотя истинная цель ELMA KPI не материальное вознаграждение сотрудников, а воспитание сильных кадров, профессионалов внутри коллектива.
1. Каким образом ваше KPI отделяет общие причины вариаций от особых? Это вопрос принципиальнейший. Т.к. путать общую и особую причины вариаций - один из самых страшных грехов менеджмента. А разнообразные KPI, как правило их путают и, в результате, имеет место попытка компенсации общей причины вариации с неизбежным как восход солнца печальным результатом (смотри правила воронки Деминга).

Возможно, ваши KPI их не путают. Но уточнить надо.

2. Величайшие менеджеры XX века Эдвард Деминг и Эли Голдратт очень негативно отзывались о KPI. Причем Голдратт наглядно показал, что использование KPI напрямую противоречит управлению по ТОС. Иными словами "Отмена KPI является необходимым, но недостаточном условием перехода к управлению по ТОС."

Далее гипотезы:
1.  Я неверно понял этих великих.
2. Деминг и Голдратт не правы.
3. Использование KPI может дать положительный эффект при переходе от полного хаоса к минимальному упорядочиванию, но очень быстро они станут тормозом на пути улучшения. Дополнительным обязательным условием будет: "в системе есть особая причина вариации и KPI нацелены на ее компенсацию"
4. Использование KPI не дает положительного эффекта ни в одном из случаев.
Вроде все перечислил.


Вероятность гипотезы "2" стремится к нулю.
Из остальных, я бы поставил на "3"
Если что, верифицировать "1" можно обратившись к эксперту по ТОС. Например, к Андрею Степенко.

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

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

А вот что нужно знать для высокоуровневой...
* В каких случаях нужно использовать UDDI? А для чего?
* Как версионируется система из десятка компонент? (в частности, по версиям протоколов обмена)
* Почему не стоит хранить в БД ни пароли, ни хеши паролей? И где их хранить?
* Почему автоинкремент идентификаторов must die?
* Во сколько раз увеличивается стоимость разработки при переходе от централизованной БД к распределенке?

188
Интересно можно ли реализовать алгоритм Голдрата (описанный им в книге Цель) или иную модель управления?
Эд, в книге "Цель" нет алгоритмов. Ни одного. Там изложены принципы. А прикладные решения (алгоритмы) следует выбирать в зависимости от типа производства.
* Для стабильной А-цепочки подойдет решение Форда.
* Для стабильной Т-цепочки модель производства Тойота.
К сожалению, производство софта это производство с высочайшей вариативностью. Для маленьких, простых проектов с единственным рабочим центром некие прикладные решения есть. Но как только у тебя хотя бы два рабочих центра, все становится сильно хуже. Именно ввиду сложности разработки прикладных алгоритмов TOC такие методологии, как XP, SCRUM, разработаны для одного РЦ (маленькие простые проекты).

И, да, канбан для разработки ПО не применим в принципе. От слова никак.
Подробнее смотри: http://habrahabr.ru/post/139194/

Взять хотя бы KPI. У нас очень интересная система мотивации, которая также предполагает возможность выбора механизма оценки.
"Если производительность труда программиста можно поднять при помощи зарплаты, то этого программиста нужно немедленно уволить."
(с) Андрей Орлов.
Как то Орлову я верю больше. Как никак опытнейший менеджер. Да и Деминг высказывался по этому поводу достаточно определенно.
Т.е. ваш KPI, это, скорее минус, а не плюс системы.

189
Как, разве специалист по маркетингу компании ELMA не поздравит нас с Рождеством ????
Не по маркетингу, а по продажам. Принципиально разные вещи.

190
Для всех / Re: Тема дипломной работы
« : 07 Декабря 2013, 19:32:33 »
И посоветуйте какую нибудь стоящую книгу по Теории принятии решений.
Их много. И хороших много.

1. "Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию" http://www.ozon.ru/context/detail/id/5288956/ - зубодробительный учебник по работе с мыслесхемами
2. "Thinking with Flying Logic" http://flyinglogic.com/docs/Thinking%20with%20Flying%20Logic.pdf - тоже, что и [1], но сильно проще
3. "Фрикономика" - http://www.ozon.ru/context/detail/id/18819292/ - неплохая книга о том, как люди принимают решения неправильно. Читается легко, но, на мой взгляд, книга легковесна.

Настоятельно рекомендую:
4. http://lesswrong.ru/ - одна из любимых http://lesswrong.ru/w/%D0%91%D0%B0%D0%B9%D0%B5%D1%81%D0%B8%D0%B0%D0%BD%D1%81%D0%BA%D0%BE%D0%B5_%D0%B4%D0%B7%D1%8E%D0%B4%D0%BE
5. http://hpmor.ru/ - в этой книге очень кстати есть список очень неплохих книг и куча ссылок по рациональному мышлению

Ну и хватит пока.

191
Мой подход:
1. выделить два уровня. Уровень моря и уровень змея.
2. Разделить на множество юзкейсов.

Почему так:
* Текущий ВИ "Создать меню" не проходит проверку на уровень моря
* Текущий ВИ не проходит проверку на полноту по методу "объект-действие"
* При моем подходе SRS будет более устойчива к изменениям

-- Вариант А. Реестр ВИ. (Может быть не самый лучший подход, но достаточно понятный)
1. Управление Меню. Уровень змея [включает в себя все нижеследующие].
2. Создание меню. Уровень моря.
3. Копирование меню. Уровень моря.
4. Просмотр меню. Уровень моря.
5. Редактирование меню. Уровень моря.
6. Просмотр списка меню. Уровень моря.
7. Удаление меню. Уровень моря.

Далее. <<5. Редактирование меню.>> можно оставить как есть, а можно сказать, что включает все операции, кроме операций с блюдами и все пять операций CRUDL с блюдами выписать отдельно. Последнее, на мой взгляд, лучше.

Итого моя рекомендация: Вместо одного ВИ напишите дюжину двух уровней.

192
Так, как например отличается группа сценариев «Купить товар» от «Заказать товар» — первая предполагает описание всех видов деятельности, необходимых для приобретения товара — как автоматизируемых, так и не автоматизируемых, а вторая — только автоматизируемые.
+1.

Если брать подход Коберна, то «Купить товар» это ВИ уровня змея, в контексте которого выполняются ВИ уровня моря такие как «Заказать товар» и другие.

193
Эд, а посмотри: http://blog.shumoos.com/archives/288
Это гипотеза, но довольно вероятная.

<Если это верно>, Тогда ВИ действительно лучше отнести на следующие стадии.

PS. Я согласен с коллегами. Знания о правилах работы с ГОСТ-ами похоже остались в глубоком прошлом. Сейчас попытка с ними работать и спецам то сносит голову, так что говорить о студентах?

194
Вот как бы нам хоть какую классификацию составить? Это там применимо, это здесь...
Далее чистая гипотеза, не рассматривайте как руководство.
-- -----------------------------------
Для анализа бизнес-процессов на разных стадиях удобны:
* Диаграмма  VSM. (http://thelean.ru/vsm/  http://en.wikipedia.org/wiki/Value_stream_mapping). Хорошо показывает потери процесса. Средства ... [вроде в визио я ее рисовал].
* Диаграмма разрешения конфликтов "грозовая туча". (http://cartmendum.livejournal.com/138630.html). Мощнейший инструмент для разрешения конфликтов при изменении процессов. Средства: естественно http://flyinglogic.com/


Для описания бизнес-процессов на разных стадиях удобны:
* Активити диаграмма
* EPC
* IDEF
* что-то еще
-- -----------------------------------
Ну и т.д.

195
С днем учителя поздравляю всех, кто занимается преподаванием.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »