1366

Вакансии / Re: Ищу тестировщика, аналитические способности и навыки приветствуются

« : 03 Марта 2012, 23:14:49 »

Имхо, требуется тестировщик-сопровожденец

1367

Для всех / Нужен специалист по T-SQL для консультации

« : 28 Февраля 2012, 23:21:39 »

Братья и сестры, сильно нужен человек понимающий в T-SQL на предмет консультаций по написанию триггеров.
Что-то мой опыт писания оных на firebird не шибко мне помогает

Лучше, если в личку. Дабы не докучать остальным. Спасибо.

1368

Сообщество Аналитиков / Re: Москвичи в Питере

« : 27 Февраля 2012, 20:59:54 »

Кстати анонс конференции, содержит массу опечаток, ошибок и белых квадратиков в тексте. Или это все происки Опера?
Да в FireFox выглядит пристойнее, правда буква Й явно нестандартная.

Максимально адекватно и ожидаемо отображается в Chrome.

1369

Обучение / Re: Требования и решения для системы управления конференциями

« : 25 Февраля 2012, 15:52:12 »

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

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

1370

Обучение / Требования и решения для системы управления конференциями

« : 24 Февраля 2012, 23:33:20 »

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

В преддверии нового ЛАФ это действительно актуально. Я помню прошлый сезон, в котором я играл не последнюю роль. У нас уже есть движок адаптированный под управление конференциями: http://conf.uml2.ru. В целом он достаточно прост, но далеко не всегда удобен, требует большого личного участия, большого ручного труда, чтобы обработать полученную информацию.

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

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

Это черновой набросок, надеюсь меня дополнят: Григорий как активный ит-разнорабочий, готовый помочь и обеспечить; Александр как организатор и вдохновитель первого ЛАФ; Денис как специалист по работе с требованиями самой высокой пробы

1371

Обсуждение статей / Re: IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаем

« : 23 Февраля 2012, 21:41:55 »

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

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

А можно поподробнее насчет конфликта? Что именно произошло?

Это слишком конфиденциально. Могу в личке кратко обсказать намеки. Но реально, наверное, они еще и переросли парное программирование, каждый захотел быть соло

1372

Обсуждение статей / Re: IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаем

« : 23 Февраля 2012, 13:12:31 »

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

То, что статья вызвала дискуссию, достаточно показательно: следовательно, тема, затронутая в статье, интересная, волнует многих. Эти самые многие , по-видимому, сами имеют, что сказать. И говорят. Правда в научном мире принято статьей отвечать на статью, исследованием на исследование. А не нравоучениями, рекомендациями как написать статью ПРАВИЛЬНО (это вообще авторское дело) или откровенными оскорблениями.

По поводу того, что в вузах не учат работать группами.
Это далеко не так, другое дело, что  этом нет системы и целенаправленности. Когда я еще учился, мы всегда работали на всех лабораторных занятиях парами. Сейчас, когда я преподаю у студентов ИТ-специальностей, то все практические занятия ориентированы как раз на пару, правда это скорее вынужденная мера была: компьютеров всегда раза в два меньше, чем студентов в группе. Однако я наоборот всегда настаивал на работе в паре. Но повторюсь, в этом не было системы, науки. А потому скорее всего и пользы не так много.

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

1373

Sparx / Re: Вопрос по Relationship Matrix

« : 22 Февраля 2012, 13:47:00 »

Спасибо, к сожалению сравнение в ЕА сделано очень не удобно, например в powerdesigner намного лучше продумано.

Согласен, но ЕА и дешевле существенно + имеет довольно развитые инструменты автоматизации

1374

Конференции Семинары и Тренинги / Re: ЛАФ-2012 будет?

« : 21 Февраля 2012, 20:33:48 »

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

Могу заметить, что многие участники предыдущих ЛАФ отмечали непринужденность обстановки располагающей к активному профессиональному общению.

Я призываю студентов и начинающих специалистов активнее использовать площадку ЛАФ для самовоспитания и саморазвития.

All You need is LAF

1375

Системный Анализ и Требования / Re: Управление требованиями на долгоживущем проекте

« : 21 Февраля 2012, 08:34:14 »

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

Второй момент - это огромное количество дублирующейся информациии соответственно источников одной и той же информации.

1376

Системный Анализ и Требования / Re: Управление требованиями на долгоживущем проекте

« : 20 Февраля 2012, 18:57:17 »

Поскольку у нас демократия, то 80% довольных побеждают 20% недовольных

а я слышал, что при демократии должно быть наоборот. Мол демократия должна защищать меньшество, а большинство и так себя защитит

1377

Методологии / Re: Обзор методологий

« : 17 Февраля 2012, 17:11:02 »

> Ретроспективный анализ.
Меня тренировали его просводить на тренингах по управлению в 1986 году. Скрама в  то время не то что в проекте не было...

Надо же, а я в это время в армии был. И тихо сопереживал товарищу из-за Чернобыльской катастрофы
Это, конечно, шутка.

Но нельзя ли приветси ссылку на блог, и еще лучше на статьи, статистику поддтверждающие твои слова, Сергей?

1378

Системный Анализ и Требования / Re: Управление требованиями на долгоживущем проекте

« : 17 Февраля 2012, 15:09:40 »

СУТ не используем, но есть идея произвести реверс-инжиниринг требований и загнать их в СУТ (Sparx EA). Но пока не пойму - нужно это или нет, какие плюсы и минусы.

У нас не прижилось, хотя сделали довольно обширную работу по фиксации требований.

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

будет интересно почитать.

И все равно отраслевое решение для каждого свое.

В нашем случае оно единое. У нас система как ДНК или РНК (биологам виднее). Заложены все возможности. В определенной среде проявляются нужные свойства

Мне кажется это довольно обширная тема. Надо как то сформулировать более точечно.
Например,
Проект срок 3 года, модификаций 20 (т.е решений которое было поставлено у 1 клиента , это минимум, дальше у других уже более улучшенные ).
Вспомнили, что ничего не документировано на 10 модификации.
Теперь задача - выяснить, а зачем разрабатывалась функция которая есть в 7 модификации, которая сейчас уже не нужна (т.е. в 20 модификации ее нет)? Какое было требование.
И вот как бы все учесть  - описать существующие и не упустить что-то что есть в старых модификациях?
И что же делать, когда ресурсов на описание старого нет, да и на новое не особо много ?

Да вы правы:
Проект: с 1997 года
Контролируемый процесс релизов с 2007 года.
Количество релизов 20 (угадали)
Контролируемый процесс работы с требованиями с 2008
ну и далее по тексту примерно так же

Это скорее вопрос ведения компетенции по проекту. Если хочется оторвать компетенцию от команды и участников проекта, то можно вводить дополнительные инструменты. Только надо учитывать, что накладные в таком случае на работу появляются  и достаточно большие, поскольку необходимо отслеживать связные требования, устанавливать связи и все такое прочее.

Да, конечно, мы это понимаем.

Из собственного опыта: мы ситуацию с противоречивыми требованиями решали введением итераций разработки (версий). Версия должна быть обозрима, но при этом достаточно длительна для удобства разработчиков. Длительность версии определяется исходя из набора требований-изменений, которые могут быть оценены на непротиворечивость и реализуемость.
Процедура планирования включала два этапа:
1. Выбор из всего набора нереализованных требований самых важных и необходимых. При этом все требования фиксировались в беспрерывном режиме, а отсечение дубликатов и откровенно лишних происходило на этом этапе.
2. Оценка для реализации на совместимость и возможность принципиальной реализации. Здесь же появлялись и оценивались сроки.

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

1379

Системный Анализ и Требования / Re: Управление требованиями на долгоживущем проекте

« : 17 Февраля 2012, 14:54:12 »

Эдуард, ты сильно затронул тему, которую я заявил на ЛАФ'12
Если есть желание, то можем обсудить или объединить усилия, я тебе вышлю свои наработки на выходных.

Извини, я не хотел Высылай было бы интересно обсудить.

1380

Системный Анализ и Требования / Управление требованиями на долгоживущем проекте

« : 16 Февраля 2012, 23:38:30 »

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

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

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

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

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