976

Сообщество Аналитиков / Re: [Встреча] Сообщества 07 августа 2008г.

« : 06 Августа 2008, 23:51:43 »

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

Моё субъективное мнение такое.

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

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

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

Поскольку времени практически не осталось, во избежание растекания мюслями, предлагаю не устраивать голосований, а отдать решение о выборе места на откуп Тройке в составе: bas, Владислав Орликов, SALar. Пусть они договорятся и озвучат своё решение (желательно до обеда).

977

Сообщество Аналитиков / Re: [Встреча] Сообщества 07 августа 2008г.

« : 06 Августа 2008, 16:13:42 »

Мне, в принципе, всё равно где собираться. Мне просто название Артефак понравилось, раньше о нём не слышал. Интересно было бы посмотреть, что они там накреативили.

Но, с другой стороны, повестка дня намечена довольно серьёзная (imho, дай бог хотя бы один пункт обсудить), и уровень шума в заведении будет немаловажным фактором (всем читать Peopleware )

978

Сообщество Аналитиков / Re: [Встреча] Сообщества 07 августа 2008г.

« : 06 Августа 2008, 14:25:21 »

А не будет ли против Сообщество, если я на встречу ещё одного человека приглашу? Может, и Александр Лобач присоединится к моей рекомендации (они вместе работают).

Владимир Кромин, ИНПАС, с немалым опытом работы системным аналитиком. Мешать обсуждению он не будет , а вот ценный совет дать может. В общем, мы с ним больше по четвёртому пункту повестки, но пункты 1-2 нам тоже очень интересны.

979

Сообщество Аналитиков / Re: [Встреча] Сообщества 07 августа 2008г.

« : 05 Августа 2008, 15:54:22 »

Опа... а куда делась ссылочка на Артефак? А то Москва большая, до четверга, может, и не найду...

И чтобы два раза не вставать: никто не знает случайно, что случилось с it4business.ru ?

980

Сообщество Аналитиков / Re: [Встреча] Сообщества 07 или 14 августа 2008г.

« : 04 Августа 2008, 17:24:44 »

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

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

981

Сообщество Аналитиков / Re: [Встреча] Сообщества 07 или 14 августа 2008г.

« : 04 Августа 2008, 11:17:09 »

Я могу 7-го. Но польза от меня может быть, наверное, только по пункту 3 часть 2 повестки.

982

Тестирование / Re: Автоматизированное тестирование + и -

« : 24 Июля 2008, 12:19:50 »

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

И сейчас остаётся такое мнение. Предвзятое, но массовое.

К нам приезжал в прошлом году наш Главный Босс из Кореи - основатель и владелец компании. (Для справки: в Корее у нас целый Research and Development Center, в котором трудится человек сто. Причём он существует уже лет пятнадцать.) Так когда мы ему показали нашу организационную диаграмму (ну, это звучит слишком гордо для офиса из шести человек), он долго не мог понять, что такое TESTER. Чем этот человек занимается?

Вчера общался с бывшей коллегой. Она проработала восемь лет тестировщиком, а сейчас её типа повысили, руководить QA. Спрашиваю: кто, кроме тебя, занимается тестированием? Ответ: "еще есть студентка Аня, которая работает 30 часов в неделю, еще была Катя (не совсем вменяемая) и ее уволили".

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

Он, наверное, и не подозревает, что есть ещё идиоты, разрабатывающие embedded приложения на голом "С" для экзотических аппаратных архитектур.

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

А сколько возможных значений у каждого параметра? Без этого я не могу посчитать точное количество комбинаций.

Правда можно все-таки надеяться, что таких сочетаний все-таки меньше в реальной практике и их можно всести к 100 или меньше. Тогда работу можно сделать примерно за день, без учета разработки и отладки самого скрипта. Возможно на всю эту работу нужно отвести минимум неделю.

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

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

983

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

« : 22 Июля 2008, 12:09:50 »

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

Это не я высказал. Это цитата из книги Роберта Гласса.

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

Я сейчас один умный вещь скажу, только ты не обижайся. Это нужно в первую очередь не заказчику и даже не компании-разработчику, а команде, создающей продукт. Я имею в виду, конечно, не формализованное ТЗ "О необъятии необъятного", а реально собранные и документированные требования, которые просто необходимы всей проектной команде (или, по крайней мере, тем её членам, которые действительно работают). Без чётких требований работа над проектом очень быстро начинает вызывать отвращение (сегодня мы переделываем то, что сделали вчера, тестируем непонятно что с непонятной целью, юзеры тупят и вообще у них руки не оттуда растут - в общем, все поголовно чувствуют себя идиотами).

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

И вот в такой момент возникает некоторый суррогат таких требований, совмещенных с проектными решениями. В результате основной проектный Такой вопрос. Скажите у Вас такая же практика? Вы примерно также устраиваете свой процесс разработки? Это вполне нормально? Если ненормально, то как лучше строить процесс?

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

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

Все эти задачи не приносят дохода в краткосрочной перспективе. Но при этом требуют глубокой концентрации, а значит, много времени. И всё время оказываются оттеснёнными какими-то "более срочными" задачами.

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

Читаешь книги, статьи, слушаешь гуру - как много всего придумано и предложено. Однако на практике видишь совершенно собственные изобретения, которые совершенно противоречать написанному. Может дело в том, что идет это с Запада, а наша азеоповская душа устроена иначе?

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

984

Sparx / Re: Контекстная диаграмма в ЕА

« : 21 Июля 2008, 15:49:30 »

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

Новости приходят по RSS, прямая доставка на дом.

985

Sparx / Re: Контекстная диаграмма в ЕА

« : 21 Июля 2008, 11:56:56 »

А где этот архив? Не нашел, подскажите.

http://www.uml2.ru/index.php?option=com_remository&Itemid=28

Или, если зайти через главный вход (www.uml2.ru), четвёртая дверь по коридору налево. Просто мало кто ходит через главный вход.

986

Сообщество Аналитиков / Re: [Конференция] ИТ анализ и требования (подготовка)

« : 14 Июля 2008, 14:32:25 »

Как-то очень резво писать 11 июля, что последний срок подачи тем докладов - 15 июля :-)

Ефрейторский зазор?

И правда, о конференции ещё ничего не ясно, сайта нет, озвучена только голая идея, а доклады уже должны быть... Может, речь идёт об организации конференции для тех, у кого уже есть доклады?

987

Тестирование / Re: Организация и управление процессом тестирования

« : 08 Июля 2008, 11:36:31 »

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

Ира опередила.

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

И цитатку подкину подходящую.

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

988

Работа / Re: Работа для тех, кто только закончил ВУЗ (начало карьеры)

« : 07 Июля 2008, 18:18:53 »

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

989

Примеры / Re: Вариант использования с двумя actors

« : 07 Июля 2008, 11:00:42 »

Нужно определить что является условием перехода на другую ветвь сценария. Если это тип карты (а их может быть несколько), то в главный сценарий пишется утверждение (!) что клиент дает карту Visa (или другую, которая более "типичная" т.е. чаше всего бывает). А в альтернативном сценарии пишем другие утверждение, например "Клиент подал карту AmEx" и далее что происходит. Важно, что тут нужно будет в сценарии описать не разницу экранов, а разницу во воодимой информации например или дейсвиях кассира.

Необходимость подтверждения выбора приложения или ввода ПИН не зависит от платёжной системы, а определяется данными, считанными непосредственно с карты. Способ проверки определяет банк-эмитент. Мы же должны поддерживать в одном приложении все варианты, заявленные в нашем сертификате EMV. Если вдруг появляется новая платёжная система, основанная на EMV, она должна поддерживаться автоматически. (Пример совсем не надуманный, кстати, хотя конкретно к этому проекту не имеет отношения. Например, Иран не подключен к международным платёжным сетям, но иранские банки выпускают собственные чиповые карты, соответствующие стандартам EMV).

990

Примеры / Re: Вариант использования с двумя actors

« : 04 Июля 2008, 17:00:17 »

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

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

- нужно "прикрутить" поддержку чиповых карт к уже существующему функционалу работы с магнитыми картами. То есть взять и перепроектировать всю архитектуру заново не представляется возможным;

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

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

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

Но это всё трудности программистов (ну и мои тоже, конечно). Просто мне нужно получить подтверждение от заказчика на реализуемую схему, и я попытался изложить эту схему в удобоваримом виде. А в качестве "удобоваримого" вида решил попробовать (можно сказать, впервые) usecase и немножечко UML. И, в общем, пока не вижу никаких преимуществ перед простым текстовым описанием.

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