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

×


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

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


Сообщения - Золотая рыбка

Страницы: « 1 2 3 4 5 6 »
16
Цитировать
"Что будет, если мы столкнемся с высокоразвитой цивилизацией"
"Решение проблемы голода на Земле"
Ну да, что-то в этом роде :)
Тут нужно, чтобы задача:
1. была понятна всем участникам
2. не имела очевидного решения
3. была более или менее нейтральной, чтобы не создать конфликта вокруг самой тестовой темы.
Вот тема перенаселения, пожалуй, в этом смысле уже рискованная.

Цитировать
"Фасилитатор" ...устоялось гораздо больше, чем аналитические термины
Да, конечно. Но не все его понимают.

17
Добрый день!
На ЛАФ 2013 Дмитрий Лазарев проводил интересный круглый стол, посвященный фасилитации совещаний. Хотелось бы проиллюстрировать некоторые мысли, там почерпнутые, на таких небольших тестовых примерах, возможно, неожиданных.
Скажем, мини-совещание (5 человек, 5 минут) на тему: "Решение проблемы остановки Гольфстрима".
Подкиньте еще темы :)

P.S. Кстати, на русском, пожалуй, можно передать смысл этого термина как "поддержка совещаний" или "сопровождение совещаний".

18
Трудно что-то посоветовать, поскольку неизвестно, с чем Вам придется года через три столкнуться. В любом случае умение читать код не помешает, так что если есть время и желание, можно этим заняться. Лишним не будет.
Вот с чем однозначно стоит ознакомиться, так это с проектированием БД и c SQL.
А из языков программирования можно для расширения кругозора брать любой, который больше приглянулся. C++, C#, Java... С++, конечно, классика жанра, но порог вхождения высоковат там, да и деталей много низкоуровневых, которые Вам, вероятно, не особо и нужны. Как будто в Бауманке неплохие курсы.
Цитата: Denis Beskov
Декларативным программированием (SQL, Prolog, Lisp)
Не сталкивалась с Lisp, но он вроде к функциональному программированию относится. Это не опечатка?

19
Да, на happy end не очень похоже... Но все равно полезный опыт :)

20
О Сайте и Форуме / Re: Рубрика: Люди
« : 29 Мая 2013, 11:00:35 »
В неформальной обстановке можно как угодно писать имя, хоть задом наперед, если душа просит. Вряд ли можно ожидать в ближайшем будущем принятия закона РФ, регламентирующего правила регистрации на интернет-ресурсах. Так что в этом вопросе имеется полная свобода действий, ну и хорошо. :)
Но следует отметить, что во всех официальных документах, начиная от классного журнала и заканчивая полисом ОСАГО, в списках физических лиц первой идет фамилия. Возможно, есть исключения, но мне они не встречались. На существующий порядок указывает сам факт наличия аббревиатуры ФИО. В некоторых видах деятельности, ну в сфере образования например, необходимость указывать в перечне физ. лиц ФИО в алфавитном порядке прописана явно в различных регламентирующих документах.
Да и нельзя сказать, что западный вариант (Имя Фамилия) удачнее, видимо, он сложился исторически, традиции - штука хорошая, но стоит ли повторять чужие ошибки? у нас своих хватает. Вот список. Удобно с ним работать, учитывая, что отсортирован-то он по фамилии, а имя стоит первым?

P.S. Вообще инстинкт самосохранения IT-специалиста подсказывает желательность сохранения статус-кво.  А то начнется:
 - а я хочу из имени анаграмму сделать!
 - а я отчество первым пишу, а имя вообще не указываю принципиально, Петрович я, так меня все зовут...
 - а я ощущаю себя исландцем и от фамилии отказываюсь.
... ну и т.д и т.п.
Очень занятно было бы посмотреть на автоматизацию этих идей в бизнес-приложениях... со стороны, конечно  ;D

21
О Сайте и Форуме / Re: Рубрика: Люди
« : 27 Мая 2013, 17:19:53 »
Ссылку на источник в студию.
Паспорт
Загранпаспорт
Страховое свидетельство обязательного пенсионного страхования
Карточка медицинского страхования
Трудовая книжка
Такая новомодная штука, как УЭК :)
......

22
Цитировать
сравнение ТЗ по ГОСТ 34.602
Да. Я еще подумала, что может быть было бы более правильно сравнивать с ГОСТ 19...

Юрий, пользуясь случаем, хотела бы уточнить - Вы в презентации сопоставляете Functional Requirements пункту ТЗ 2.6.2 (Требования к функциям (задачам)). Мне казалось, что этот пункт по уровню детализации ближе к User Requirements. Или я ошибаюсь?

23
Ну надо ж... :) Как раз любуюсь на картинку Вигерса, и думаю, можно ли так быстренько объяснить людям, которые не в теме, эти дважды функциональные требования - а тут Ваша статья все ставит на места. ЗдОрово, в общем.
Разницу в масштабе ФТ и НФТ, мне кажется, просто проиллюстрировать - не медиану рисовать, а увести разделяющую линию вправо, будет понятно.
А вот слово 'Системные' для нижнего уровня мне не очень нравится. Во-первых, слишком уж оно общеупотребительно и вызывает разные ассоциации для разных аудиторий. (Системные требования? Это которые объем ОЗУ и мощность процессора?)
Во-вторых, мне кажется, оно не точно отражает суть этого уровня. По моим представлениям, в идеальном мире эти самые требования нижнего уровня (Functional Requirements) должны непосредственно отображаться на функции и классы программного кода связью один-ко-многим, в смысле, одно_требование - много_мест_в_коде. Если это так, то данная концепция и должна быть выражена в их названии. Вот только слово удачное трудно подобрать. Ага, по-английски можно предложить Development Requirements, Programming Requirements. На русском точный ёмкий термин так сразу в голову не пришёл, подумать надо. "Требования для разработки"?

24
Если очень нужно, и если хорошие отношения с разработкой - тогда можно сократить до минимума документы и работать по этой задаче в непосредственном контакте с теми, кто код пишет, решая неясные вопросы по мере их возникновения у разработчика. Спецификации (или иные документы, предусматриваемые корпоративным стандартом) оформить уже ПОСЛЕ того, как код написан, поручив это упомянутому новому аналитику.
Как-то так...  :)

26
Цитировать
Как вы думаете, а есть ли отечественные практики за рамками ГОСТов?
Не думаю. Если и есть, то мне они неизвестны :)
А в рамках, наверно, были интересные решения - вот, например
Но это уже история.

27
Цитировать
А какую проблему вы решаете в разработке по ГОСТ? Как совместить лучшие мировые практики анализа с требованиями заказчика по формальности документации?
И это тоже, но не только. Я до недавнего времени воспринимала ГОСТ именно как набор формальных документов, но все чаще у меня появляется мысль, что за ним скрывается нечто бОльшее. Попутно мне попалось несколько хороших статей на эти темы:
http://gaperton.livejournal.com/49867.html
http://habrahabr.ru/post/122700/
http://boatmanshome.ru/cgi-bin/page.pl?21dev_002.page
Так что мысль у меня была несколько утопическая: как совместить лучшие мировые практики разработки ПО с лучшими отечественными практиками?

28
Что-то идей мало :) Ну тогда как-то так:

- ГОСТ 19, 34 как методология разработки ПО? Успешные практики применения. Соотнесение пирамиды Вигерса (Бизнес-требования, ВИ, ФТ) с документами ГОСТ. "Упаковка" в ГОСТ популярных методологий (RUP, MSF, Agile, et cetera...).
Вечная тема. Не знаю, насколько это интересно, да и обсуждалось многократно, просто я сейчас смотрю в эту сторону.

- Примеры успешных внедрений на базе Microsoft SharePoint.

29
Цитировать
ко мне приходит аналитик и говорит, что то не буду, это не знаю, этому не обучен, то я не хочу с таким работать
Да, это точно :)
Но вопрос же скорее об обязанностях, которые можно отнести к роли "системный аналитик", а не об обязанностях конкретного сотрудника, называемого в некой организации "системный аналитик". Сотрудник вполне может и несколько ролей исполнять. И роль может быть распределена между несколькими сотрудниками. Помню, когда-то мне понравилось, как это в методологии RUP было описано.

30
UML SysML и пр. / Re: В каких случаях UML вреден?
« : 19 Февраля 2013, 17:44:50 »
Цитировать
"UML - это вагон, которые отцепили от состава и оставили. Ну и он катится по инерции не замечая, что движется в тупик".
Интересная формулировка. И всё-таки не вполне ясно, что скрывается за этой метафорой. Изолированность UML-моделей от прочих артефактов проекта, несогласованность с ними? Или более глобально - некий грядущий кризис применения UML в IT-индустрии вообще, замену его другим стандартом? А каким?
Основная проблема UML, как мне сейчас представляется, это известная проблема семантического разрыва, то есть невозможность  гладкого, плавного перевода (можно сказать, компиляции) в язык программирования высокого уровня (а еще лучше, в машинный код :)).

Страницы: « 1 2 3 4 5 6 »