211

Обучение / Re: Системный аналитик курсы

« : 17 Февраля 2011, 14:42:24 »

спорить не буду, но на мой взгляд одно другому не мешает. я использовал. сейчас внедрением не занимаюсь.

212

Обучение / Re: Системный аналитик курсы

« : 17 Февраля 2011, 00:40:27 »

внедрение ERP систем это отдельный "мир" со своими правилами и методологией, где нет ни юзкейсов, ни ТЗ как такового ... и даже понятие бизнес-процесс, в условиях российской действительности отождествлено с реализацией в системе :-).

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

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

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

P.S. ну и потом, далеко не всегда разрабатывается коробочная система (программа), тем самым устраняя разработчика от процедуры внедрения. в большинстве случаев в том или ином варианте процесс внедрения имеет место быть.

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

213

Для всех / Re: Сколько у вас уходит время на сбор и оформление требований?

« : 16 Февраля 2011, 18:33:11 »

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

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

214

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 16 Февраля 2011, 11:47:53 »

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

215

Вакансии / Re: Ищем бизнес-аналитика со знанием испанского языка. Очень надо))

« : 12 Февраля 2011, 20:07:50 »

hasta la vista, baby, vaja con dios :о))

216

Управление Проектом / Re: Особенности работы с госзаказчиками

« : 11 Февраля 2011, 23:32:39 »

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

Ситуация такова:
1. формальная документация и реальное состояние продукта друг друг не соответствуют и соответствовать никогда не будут. В этом направлении проламывать стену лбом совершенно бесполезно, но можно сделать неофициальную документацию, для внутреннего использования. Это единственный способ зафиксировать состояние системы в виде "как на самом деле".

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

А "городить рядом" гору документов по сути бессмысленно, Вам ведь сдавать работу придется по ТЗ, а не по вашим писулькам, насколько бы правильные и верные они ни были бы...

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

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

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

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

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

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

217

Проектирование / Re: Проектирование ИИ бота

« : 11 Февраля 2011, 11:09:40 »

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

Я ведь предлагаю совместно работать.

жареные каштаны любите? ну-ну...

А как?

заведите ребенка и посмотрите лет 15 как он развивается :о)))

Собственно, с чего начать?

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

218

IDEF ARIS BPMN и пр. / Re: IDEF0: Как определиться со взглядом на модель?

« : 10 Февраля 2011, 19:57:03 »

Начала учить IDEF0. Столкнулась с проблемой при определении взгляда на модель.
Конкретнее: есть некая система документооборота.
Один и тот же документ рассматривается, корректируется и подписывается на различных уровнях.
Казалось бы, процесс пользователя определяется жизненным циклом документа:
1 Создание документа в отделе А
2 Согласование в отделе В
3 Согласование в отделе С
4 Утверждение в отделе Д
5 Окончательное визирование в отделе, который документ выпустил (отдел А).

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

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

Ваша схема в принципе неплоха. Пара штрихов и будет хорошо.

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

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

Насколько логична модель, где используется подход "отдельные функции":
1 создание документа
2 редактирование документа (декомпозиция на удаление, редактирование, добавление)
3 подписание документа.
4 передача документа между отделами ( + выход на вход п.2)

Вроде функции ясны, но ЖЦ сразу исчез! С другой стороны, в первом варианте куда запихать редактирование, удаление и т.д. (не дублировать же)
Описала конечно примерно, чтобы суть была ясна.

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

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

Или вообще не стоит в IDEF0 пытаться это описать?

Стоит-стоит, хорошая тренировка, немного сложновато поначалу, но польза в целом превалирует над затратами.

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

Да и пользователя не стоит рассматривать в первую очередь, рассматривать нужно заказчика (по идее заказчик и владелец процесса должны находиться близко-близко друг от друга или даже совпадать) - того, для кого делается система, его цели и интересы нужно учитывать в первую очередь! Хотя бывают разные варианты.

219

Управление Проектом / Re: Тестовое задание:Снять фильм

« : 10 Февраля 2011, 15:57:18 »

Где-то на просторах инета была статья со сравнением именно такой задачи - съемки фильма с IT-проектом с т.з. управления.

подобный пример приводится в книге Фергуса О'Коннела "Как успешно руководить проектами" (Серебряная пуля). В качестве примера приводится фильм "Ганди", точнее цитата из книги "My Indecision is Final" Джека Эбертса про подготовку производства фильма режиссером Ричардом Аттенборо.

220

Тестирование / Re: Соотношение "багов" и "фич"

« : 09 Февраля 2011, 15:15:59 »

стыдно, господа.

абсолютно нет. мы ведь даже не знаем, правду Вы сказали или нет... и о чём

221

Тестирование / Re: Соотношение "багов" и "фич"

« : 09 Февраля 2011, 13:33:04 »

Задумавшись над вопросом оптимизации процесса, собрала некоторую статистику из системы, в которой мы ставим задачи, и обнаружила, что количественно на каждую новую задачу (доработку = требование) приходится 4-5 ошибок. Количественно - т.е. ошибки не всегда порождаются именно новой доработкой, просто сравнила объемы того и другого.

напомнило анекдот: Петька, приборы? -- Пицот! -- Что "пицот"? -- А что "приборы"?
Для анализа нужна более детальная статистика.

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

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

Честно? Это может говорить обо всём и ни о чём конкретно.

Есть ли смысл улучшать документирование, подготовку людей или их количество, т.е. насколько затраты на эти действия оправдают полученный в результате эффект?

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

P.S. Судя по предыдущим Вашим сообщениям, Вы ведь вдумчиво и достаточно критично подходите к решению возникающих проблем. Так что я бы на Вашим месте сильно не волновался - всё получится, враг будет разбит, победа будет за нами (с)

222

Проектирование / Re: Проектирование ИИ бота

« : 09 Февраля 2011, 10:28:50 »

=( Потому как слишком велика "гордыня" среди нас

среди вас? а Вы, простите, кто?

223

Системный Анализ и Требования / Re: Вопросы по некоторым пунктам ТЗ (ГОСТ 34.602-89)

« : 08 Февраля 2011, 11:27:23 »

это, как говорится, зависит от...

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

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

что касается порядка контроля и приемки системы, ситуация в некотором смысле аналогична, точнее в том смысле что и заказчика нужно удовлетворить и исполнителю при штанах остаться. Хотя с другой стороны о какой государственной комиссии может идти речь в отношениях двух частных компаний? Все хорошо к месту: при сдаче работ для госзаказчика комиссия и будет государственная, а для частника (какое-нить ЗАО "Импекс Холдинг") такой статус не нужен, разве что щёки понадувать...

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

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

Вы бы написали чуть подробнее, что у Вас за случай? Или это учебное задание?

224

Управление Проектом / Re: Шпаргалка руководителю проекта

« : 04 Февраля 2011, 12:10:31 »

жЫрный плюсадин !!!
про то, собственно, и речь толкую...

225

Управление Проектом / Re: Шпаргалка руководителю проекта

« : 03 Февраля 2011, 22:56:30 »

2 Galogen:
Да неее, я не отрицаю шаблонизацию чего-либо, но что-то мне подсказывает (скромн.), что в разработке разных программных продуктов (по крайней мере для разных предметных областей) менеджерами проекта должны использоваться разные (т.е. наилучшим образом подходящие для этих областей) шаблоны. Более того, не все они будут относиться к планам-графикам. А то ведь действительно можно дойти до "управления проектами в MS Project"... :о))