541

Системный Анализ и Требования / Re: А есть ли специализация у Аналитика по типам ИС?

« : 26 Августа 2009, 11:19:52 »

Дело не в том, что хороший Аналитик должен уметь ...
Берем в пример начинающего Аналитика, у которого есть опыт по работе с бизнес ИС. Теперь он переходит в отдел по созданию веб-приложений, какие навыки\подходы ему следует изучить?

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

И вопрос сводится к тому - какие навыки\подходы нужны начинающему Аналитику для работы по созданию того или иного вида ИС.

на это есть другая тема, насколько я помню :о))

только уверяю Вас, что от вида ИС знания и навыки аналитика зависеть не должны. Это как для столяра/плотника. Неважно, что он делает: полку, буфет, стул или что-нибудь еще. Он должен в достаточной мере владеть своими инструментами, чтобы смочь сделать нужный предмет.

Может Вы хотели выяснить, какой путь должен пройти аналитик (полку-то определенно сделать легче, чем буфет)? с чего лучше начать? где набить руку?
Вот это, на мой взгляд, более интересный вопрос.

542

Системный Анализ и Требования / Re: А есть ли специализация у Аналитика по типам ИС?

« : 26 Августа 2009, 10:19:57 »

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

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

а насчет ЗЛ - это еще вопрос, кого больше в каждом случае?

543

Системный Анализ и Требования / Re: А есть ли специализация у Аналитика по типам ИС?

« : 25 Августа 2009, 21:43:08 »

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

может и да, может и нет. хотя исходный пост выглядит вполне понятным - нет повода сомневаться в постановке.

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

544

Системный Анализ и Требования / Re: А есть ли специализация у Аналитика по типам ИС?

« : 25 Августа 2009, 19:57:37 »

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

другое дело знание предметной области.

545

Идеи и мозговой штурм / Re: Специфика работы с госзаказчиком. Неужели, у всех так?

« : 22 Августа 2009, 14:16:42 »

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

Потому что мои наблюдения что-то совсем неутешительные:

1. Преобладание формы над содержанием. При составлении любого рода документов нужно очень большое внимание уделять именно оформлению: правильности сокращений, терминологии, названий, естественно. Никто не спорит, конечно это важно, но не до такой же степени... Негодующий крик: "Это же полный бред!" - просто ставит в ступор, а причиной ему было всего лишь неправильное сокращение.
 
2. Обтекаемость формулировок. Очень часто, по крайней мере, в моей практике, категорический отказ в приеме работ, подписании протоколов и т.п. можно побороть изменением формулировки в утверждаемом документе на более "мягкую", в идеале, без прямого определения ответственности.

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

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

1. Вы ведь профессионал? Что-то Вам мешает поддерживать одновременно и содержание, и форму? Или стоит с этим поработать?
А насчет крика... Почитайте Йордона Deathmarch. Там дано много подходящих рецептов и для подобной ситуации тоже.
Хотя и для реальной жизни подобная ситуация не является редкостью (уже даже не говорю про мир животных): кому-то надо ответить мягко и настойчиво, кому-то просто твёрдо, а кому-то...

2. Вы ведь работаете ДЛЯ КЛИЕНТОВ, которые платят Вам деньги, так дайте им за их деньги то что они хотят. А с другой стороны, может Вы не с тем лицом контактируете? Или просто надо больше с ним работать?

3. Попробуйте давать два-три варианта, из которых нужно обязательно выбрать один - как ребенку. Тем самым подмените необходимость "брания ответственности за формирование и проработку вариантов" на "выбор из предложенного (в явном или неявном виде перекладывая ответственность на исполнителя)". Хотя тут есть подводные камни, которые никакие уставы проекта решить не помогут. Вы ведь работаете с людьми, а они такие разные.

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

А вообще я сталкивался и с откровенно враждебными заказчиками (и не только гос), и с позитивно настроенными. От формы собственности и тп. это, поверьте, не зависит. В первом случае конечно сложнее, но ведь Вы сами выбрали свой путь. Можно конечно отказываться от работы и денег, лишь бы собственный внутренний мир не нарушить, только тогда не надо удивляться, что кто-то другой успешно обойдет тебя на повороте.

Впрочем для квалифицированного специалиста заказчиков всегда хватит. Работайте над собой и все у Вас получится.

546

Обсуждение статей / Re: Класс системного аналитика. Разработка проекта системы на UML, Москва, 14 сентября

« : 20 Августа 2009, 17:27:07 »

перефразируя то, что говорилось в книжке Кернигана-Ритчи:
для того чтобы научиться быть хорошим аналитиком, нужно работать аналитиком

547

Sparx / Re: проектирование БД в Enterprise Architect

« : 20 Августа 2009, 17:15:21 »

А можно вопрос - почему неприменно нужно чтобы SEQ стоял впереди?

видимо, потому, что у него не только SEQ'и имеются

548

Системный Анализ и Требования / Re: Требования и критерии приемки к творческим продуктам (например, дизайн сайта)

« : 18 Августа 2009, 01:22:56 »

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

Один фиг всё делают ручками, потому и цена зашкаливает. У дизайнеров ведь нет технологий, типа RUP/MSF/Agile/Scrum :о)) они ведь в большинстве своём творческие личности, сами с усами.
А то что любой проект требует управления: требованиями, рисками, коммуникациями, поставками, наконец, -  это в их дизайнерских учебных заведениях, видимо не проходят :о)) вот и мыкаются горемычные.
Между прочим, более перспективным будет обычное повышение эффективности - выдавать больше вариантов в единицу времени.

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

Дизайнерское решение разрабатывается соотвествующей творческой студией, возможно среди работников ИТ-компании есть свои штатные дизайнеры и верстальщики в одном лице.

Ну разве что это будут отшень-отшень продвинутые специалисты, что и качественный дизайн сварганить, и реализовать его не менее качественно. Обычно ведь инструментарий и навыки дизайнеров и верстальщиков не пересекается. Такие спецы идут фрилансить.

P.S. Коллеги, а из Вас разве никто не заказывал дизайна для дома, для семьи? Вот бы где аналогии поискать. Причем архитектурный дизайн посложнее интернет-дизайна сайтов будет. Те хоть позволяют что угодно сделать, а тут пойди найди какие-нибудь специфические аксессуары, не всё же в конце концов в Икее продаётся...

:о))

549

Системный Анализ и Требования / Re: Требования и критерии приемки к творческим продуктам (например, дизайн сайта)

« : 14 Августа 2009, 12:27:06 »

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

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

В общем-то согласен с 474. Реставратор мог договориться, что а) общая площадь пятен будет составлять не более x% картины, при этом б) площать пятен на произвольно выбранной области в n кв.см. будет не более m кв.см. С дизайном так не сделаешь. Т.е. иначе говоря, реставратор все-таки мог найти критерии приемки, а по сайту что выбрать?
Дело не только в затратах, но и в сроках. Стадия дизайна зачастую держит дальнейшие этапы...

любят же ИТ-ишники фигнёй заниматься :о)))
конечно есть критерии, только их нужно уметь выявить.

что значит "держит"? у вас фиксированные сроки проекта? а почему на дизайн сроки не фиксируются тогда. ограничение сроков - вполне себе критерий: вы должны за час выбрать любой из представленных 10 вариантов или любую их комбинацию.
читайте кирсанова (если не спутал фамилию автора)

550

Системный Анализ и Требования / Re: Требования и критерии приемки к творческим продуктам (например, дизайн сайта)

« : 13 Августа 2009, 19:53:20 »

to AlexTheRaven:
какие два из трёх? :о)))

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

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

чтобы не занимать Ваше время, сразу скажу, что сделал это реставратор. Он выбрал 10-20 самых больших и мешающих восприятию пятен и удалил их. После чего администрация музея осталась довольна. И хотя в окончании этой истории умалчивается о вознаграждении, думаю, основной ответ на Ваш вопрос в ней есть. Более того, компании других профилей давно пользуются подобными вещами.

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

551

Системный Анализ и Требования / Re: Как подготовить детальные требования в случае нескольких систем?

« : 10 Августа 2009, 16:14:37 »

периодически приходится.

вот так принципиально, чтобы была "методология", такого нет. всегда существует конкретный частный случай. иногда (но довольно редко) такие случаи похожи друг на друга. даже в случае одинакового набора систем ситуации могут сильно отличаться. кстати, AlexTheRaven вполне понятно всё описал.

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

далее нужно четко представлять, что при переходе от состояния AS IS к состоянию TO BE:
 - сложившаяся конфигурация бизнес-процессов будет меняться, и это потребует изменения рабочих процедур
 - набор данных будет меняться как в сторону расширения, так и в сторону сокращения (и это потребует определенных телодвижений на уровне бизнеса)
 - будут добавляться (как впрочем и убираться) какие-то технологические операции для поддержки работоспособности конфигурации TO BE
 - необходим контроль целостности и полноты информации в системе TO BE

поэтому нужно:
 - иметь схему информационного потока в вариантах AS IS и TO BE (обязательно), это контрольные требования, которые позволят проверить, что нужная цель достигнута
 - схему бизнес-процесса (по числу бизнес-процессов) (обязательно), это позволит разработать рабочие и работающие регламенты как для бизнеса, так и для технологического обеспечения
 - маппинг системы AS IS на систему TO BE (обязательно), это позволит определить подцели уровня реализации и план работ
остальное у Вас вроде было перечислено, если не вдаваться в чрезмерное критиканство.

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

основная проблема тем не менее как раз в самих системах А и Б - могут ли они быть интегрированы с минимумом затрат или нет. В случае "нет" ответ на мой взгляд очевиден - старую систему нужно выбрасывать, а то ТСО будет зашкаливать.
Вопрос: как это сделать при заданных критериях оптимальности, имеющихся ресурсах и сжатых сроках?

552

Системный Анализ и Требования / Re: Как подготовить детальные требования в случае нескольких систем?

« : 10 Августа 2009, 13:43:43 »

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

IMHO это иллюзия. Тем более, что Вы забываете про такую штуку как бизнес-процесс (на которые, кстати, была указание в исходном сообщении), для бизнес-процесса наличие интеграционной системы должно быть абсолютно прозрачно. Но по Вашей схеме к бизнес-процессу добавляется ряд технологических операций (по большому счету не имеющих к нему прямого отношения), связанных:
 - с выгрузкой нужных (возможных) данных из системы Б куда-то в район системы А
 - с импортом данных в систему А и его подтверждением, чтобы стало возможно продолжение процесса (а ведь тем временем процесс "стоит и ждёт")
и это не считая какой бы то ни было многовариантности и (хотя бы!) согласования справочников. а ведь еще и пользовательские интерфейсы не согласованы между собой.

P.S. хотя это всё, действительно, довольно умозрительно, т.к. о системах нам сейчас ничего неизвестно, кроме кодовых названий (А и Б).

553

Системный Анализ и Требования / Re: Как подготовить детальные требования в случае нескольких систем?

« : 08 Августа 2009, 01:19:51 »

IMHO профессионал отличается от просто специалиста тем, что не делает лишних движений и соразмеряет масштаб своей деятельности со своими возможностями.

Альтруизм? А где тут вызов? Или есть сомнения, что тусующиеся здесь люди способны сделать это? У меня нет. Просто оно не коррелирует с их целями.

Признаться, мне на работе хватает масштабных задач, чтобы еще и в нерабочее время работать :о))

554

Системный Анализ и Требования / Re: Как подготовить детальные требования в случае нескольких систем?

« : 08 Августа 2009, 00:10:03 »

к сожалению, такие вещи на слабо не делаются :о))
это продажа квалификации либо за деньги, либо за признание (но всё равно продажа)

555

Обучение / Re: Совместная разработка лекционных курсов

« : 06 Августа 2009, 20:31:32 »

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

Поэтому констатирую, что некачественное образование - это не проблема Вузов, а беда. В том числе потому, что таким макаром они никогда не перейдут в категорию зарабатывать деньги на подготовке квалифицированных выпусников, соответственно, всегда будут прозябать...
Для отрасли и предприятий/организаций - это проблема, которая в конечном счете означает необходимость вкладывать деньги в доводку квалификации специлистов до нужного уровня. Т.к. деньги на это тратить жалко (ведь рано или поздно подготовленный специалист уйдёт к конкуренту), то этот "нужный уровень" постоянно снижается или даже падает. Много лет имею возможность это наблюдать. Это и по форуму видно, хотя в последнее время меньше - лето, каникулы.
Следствием является приход бизнеса в вузы, в частности, во многих вузах открываются кафедры, на которых преподают представители ведущих компаний. Конечно на все вузы таких компаний не хватит. Поэтому, действительно, цветёт альтернативное обучение (т.е. курсы). Вот бы еще все они были качественными, но думаю это болезни роста.