601
Обучение / Re: Спецификация требований к системе
« : 30 Сентября 2007, 23:37:01 »
Есть но в оригинале .... зашли мылом запрос на меня, я в ответ вышлю.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
602
Работа / Re: Организация работы отдела анализа
« : 24 Сентября 2007, 23:03:40 »
... как раз недавно этим занимались, что оргструктуру их ИТ-центра рисовали с одним моим заказчиком. И описывали кто что будет делать. А вообще, что значит "правильно"? ... в моем понимании "правильно" этого когда отдел может решать поставленные задачи. А тут в первую очередь встает вопрос квалификации. Учить людей нужно ...
603
Сообщество Аналитиков / Re: Неформальная сентябрьская встреча
« : 24 Сентября 2007, 22:56:51 »
вобщем-то мы встретились ... так что встречу никто не переносил. Речь идет о назначении новой встречи.
604
Системный Анализ и Требования / Re: Проблемы согласования документа с Заказчиком
« : 24 Сентября 2007, 22:54:26 »Согласна, среди руководства много умных людей.
Умных -- много, толковых мало (с) ...
605
Обучение / Re: Обучение по курсу IBM Rational системный аналитик
« : 22 Сентября 2007, 20:35:22 »У меня знания по этому вопросу либо по книгам и статьям, либо по информации с краткого курса от г-жи Золотухиной. Интуиция мне подсказывает, что то, что рассказывала уважаемая г-жа Золотухина, во многом может не коррелировать с официальным мнением IBM Rational.
Вас интуиция не подводит ...
Хочу получить от этого курса связную системную модель процесса управления требованиями (от создания требований и usecase до использования и т.д.). Все-таки курс читает доктор наук и сертифицированный инструктор, у него-то должно быть все в порядке с системным анализом и мышлением. А то пока у меня цельная и самое главное непротиворечивая картина в голове не складывается.
Ну и получить сертификат IBM Certified Specialist for Rational Requirements Management w/Use Cases или хотя бы опыт сдачи тестов хочется.
Если собираетесь за свои деньги -- то не стоит. А если контора платит ... то можно и послушать. А картина по RUP вобщем-то ясна и из смого RUP, плюс книга Лефингвелла. Я бы не стал тратить деньги на этот курс. А если пойдете, то поинтересуйтесь, сколько проектов лично сделал лектор как аналитик, где использовал тот самый RUPовский подход. Кстати, он же читает тренинги в Люксофте. И можете его послушать для начала на халяву на Softool. Если напишите мне, я вам форвардану письмо от Люксофта, где есть расписание этих бесплатных рекламных тренингов.
606
Сообщество Аналитиков / Re: Ваше базовое образование
« : 22 Сентября 2007, 01:36:10 »
блин, а у меня просто сломался калькулятор на 1 курсе, а т.к. это 1-й семестр, то стипендию еще получал не повышенную ..., а расчетов по матстатистике давали много ... посему пришлось чертыхаясь потратиться на пачку 5" дискет ...
кстати, компьютер я впервые увидел уже в универе на 1-м курсе ... нам фортран читали на ДВК-3М.
кстати, компьютер я впервые увидел уже в универе на 1-м курсе ... нам фортран читали на ДВК-3М.
607
Сообщество Аналитиков / Re: Неформальная сентябрьская встреча
« : 22 Сентября 2007, 01:28:04 »
Теперь понятно почему в России проблемы ТСЖ организовать ...
608
Сообщество Аналитиков / Re: Ваши проблемы и задачи
« : 22 Сентября 2007, 01:23:30 »Читаю Карла Вигерса про требования. 550стр. Долго, читать могу только в транспорте, процесс идет медленно. Что делать: 1. бросать это дело, 2. просить кого нибудь пересказать, 3. дочитывать.
PS.опыт дочитывания длинных и неинтересных книг получен в школе, но тогда это мотивировалось отличными оценками..
возможно вам нужно поработать над мотивацией :-), ну например не есть сладкого пока не дочитаете книгу :-)
На правах шутки (с)
609
IDEF ARIS BPMN и пр. / Re: BPMN: gateway, event или conditional sequence flow?
« : 22 Сентября 2007, 01:18:19 »Честно говоря, мне сложно понять, как обсуждение темы бизнес-процессы vs функции приближает нас к сути поставленного вопроса. Вы хотите сказать, что функции системы не могут входить в описание бизнес-процесса? Или что они не могут связываться логикой событий и ветвлений?
Как раз более сложно понять в данном случае что понимается под бизнес-процессом, и являются ли все функции системы частью какого-либо бизнес-процесса, или же нет ...
А почитав ваш вопрос "Так какой же вариант моделирования будет правильным?" я так и не понял что вы таки хотите спросить ... толи какую нотацию лучше использовать при моделировании БП, толи ветвление vs events... проблема-то в чем? и "лучше" это по какому критерию?
610
IDEF ARIS BPMN и пр. / Re: BPMN: gateway, event или conditional sequence flow?
« : 20 Сентября 2007, 19:59:57 »<<Поиск документа как БИЗНЕС-ПРОЦЕСС .... как-то не очень укладывается, если это только не архив какой-нить, в котором клерк ищет документы ...
Вообще-то речь шла о поиске документа, как действии в рамках некоего бизнес-процесса. Т.е. есть сервис, который получает сообщение и по полученным параметрам ищет в документоориентированной базе документ и возвращает результат. Но это частности, дело не в том, как смоделировать этот конкретный процесс. Конечно, я могу сделать это так, как считаю нужным, и как мне позволяет инструментарий. Но хотелось бы понять общую методику выбора конкретного варианта моделирования.
Вот это то и самое интересное .... то что вы описали действие в СИСТЕМЕ ... это функция поиска в системе. Является ли "поиск по базе данных" бизнес-процессом?
611
Бизнес-анализ и Целеполагание / Re: Модель потребностей в малых проектах по созданию публичных веб-систем
« : 19 Сентября 2007, 22:33:05 »
Денис, в такой ситуации очень многое зависит от того насколько ты "угадаешь" предпочтения этих самых масс ... интуиция рулит. А если нужно просто "прикрыть заднюю полусферу" перед спонсором проекта, то можно "слабать" фокус-группу из студентов и домохозяек :-) ... и на основании этих данных "сделать вывод"
При этом если у проекта классный vision, но реализация не ахти (пример -- неудобства сайта одноклассник.ру, но возможно с приходом туда Дениса Танаева ситуация измениться ...) это одна ситуация, и другая, если вы делаете очередной бесплатный почтовый сервер :-).
При этом если у проекта классный vision, но реализация не ахти (пример -- неудобства сайта одноклассник.ру, но возможно с приходом туда Дениса Танаева ситуация измениться ...) это одна ситуация, и другая, если вы делаете очередной бесплатный почтовый сервер :-).
612
IDEF ARIS BPMN и пр. / Re: BPMN: gateway, event или conditional sequence flow?
« : 19 Сентября 2007, 22:25:58 »
Поиск документа как БИЗНЕС-ПРОЦЕСС .... как-то не очень укладывается, если это только не архив какой-нить, в котором клерк ищет документы ...
Вот все-таки как-то смешано получается, даже в таком примере ... где бизнес-процесс, а где функции системы?
Вот все-таки как-то смешано получается, даже в таком примере ... где бизнес-процесс, а где функции системы?
613
Системный Анализ и Требования / Re: Проблемы согласования документа с Заказчиком
« : 19 Сентября 2007, 22:12:41 »
1. Даже качественный документ не отменяет личных коммуникаций. Как уже говорил Денис, действительно нужно "разжевывать" документ заказчику, некоторые положения требований и например те же юзкейсы/сценарии нужно в комиксах показывать (при необходимости) ... это я о storyboarding в расширенном понимании. Вам, как аналитику, нужно нарисовать в воображении заказчика КАРТИНКУ ... тогда у заказчика и появиться понимание. И если сначала показать в комиксах, а потом написать формальным языком (и приложить комиксы :-)), то как правило это позволяет улучшить ситуацию с пониманием.
2. Не согласен с утверждением что юзкейсы малопонятны нетехническому человеку. Скорее всего вопросе КАК их писать и как иллюстрировать.
3. Не следует подменять ТРЕБОВАНИЯ описанием бизнес-процессов. БП в данном случае больше нужны чтобы понять КАК РАБОТАЕТ организация (для того чтобы эти процессы автоматизировать, а не реинженирить). Если конечно вы понимаете под БП то же что и я, а не ERP-шный подход с их "функциональной архитектурой" и т.п. ... где под БП они запросто понимают то, что описывается collaboration диаграммами в модели дизайна по, тому же классическому RUP.
4. Проблему "длинных" проектов с изменяющимися людьми/потребностями/процессами и соответственно требованиями на декларативном (и практическом) уровне методологи уже решили. Именно ответом на них было появление а) итерационной модели ЖЦ б) соответствующих методологий (тот же RUP и гибкие (agile) методологии). Вопрос только в том КАК вы с заказчиком договорились работать. Идеальный вариант при таких условиях -- time & materials ... но наша реальность -- это fixed price. Но при этом, чего греха таить, эта price как правило включает риски связанные с переделкой софта, на так ли ;-) (иначе откуда такие гигантские бюджеты на создание не слишком сложных систем в госсекторе ... даже с учетом откатов).
4. Ни одна методология или классный документ не сможет ни чем помочь, если со стороны заказчика нет драйвера этого проекта ... тот кому этот проект действительно нужен и поможет решить массу очевидных проблем. Или попросту если заказчик слабо заинтересован в результатах.
5. greesha, я был рад вас увидеть на семинаре по Scrum в Люксофте. Вы таки им заинтересовались по следам моих рекомендаций :-). Отвечая на вашу ситуацию и как вы сами слышали на семинаре ... должен быть тот самый Product Owner ... и не важно внутри он вас (ваш маркетниг -- т.е. то что вы пишите как "мы сами себе заказчики") или на стороне заказчика. Проблемы с английским - это частная проблема, которая при готовности инвестировать в это деньги со стороны вашего менеджмента -- решаема, а не проблема методологии :-). Тендеры, и их требования, не означают того, что вы не будете общаться с заказчиком в процессе разработки если его таки выиграете. Если при таком тендере заказчик не желает с вами общаться вообще, значит можно быть уверенном в том, что победитель уже известен (с ним уже пообщались), а всем остальным отведена роль статистов.
2. Не согласен с утверждением что юзкейсы малопонятны нетехническому человеку. Скорее всего вопросе КАК их писать и как иллюстрировать.
3. Не следует подменять ТРЕБОВАНИЯ описанием бизнес-процессов. БП в данном случае больше нужны чтобы понять КАК РАБОТАЕТ организация (для того чтобы эти процессы автоматизировать, а не реинженирить). Если конечно вы понимаете под БП то же что и я, а не ERP-шный подход с их "функциональной архитектурой" и т.п. ... где под БП они запросто понимают то, что описывается collaboration диаграммами в модели дизайна по, тому же классическому RUP.
4. Проблему "длинных" проектов с изменяющимися людьми/потребностями/процессами и соответственно требованиями на декларативном (и практическом) уровне методологи уже решили. Именно ответом на них было появление а) итерационной модели ЖЦ б) соответствующих методологий (тот же RUP и гибкие (agile) методологии). Вопрос только в том КАК вы с заказчиком договорились работать. Идеальный вариант при таких условиях -- time & materials ... но наша реальность -- это fixed price. Но при этом, чего греха таить, эта price как правило включает риски связанные с переделкой софта, на так ли ;-) (иначе откуда такие гигантские бюджеты на создание не слишком сложных систем в госсекторе ... даже с учетом откатов).
4. Ни одна методология или классный документ не сможет ни чем помочь, если со стороны заказчика нет драйвера этого проекта ... тот кому этот проект действительно нужен и поможет решить массу очевидных проблем. Или попросту если заказчик слабо заинтересован в результатах.
5. greesha, я был рад вас увидеть на семинаре по Scrum в Люксофте. Вы таки им заинтересовались по следам моих рекомендаций :-). Отвечая на вашу ситуацию и как вы сами слышали на семинаре ... должен быть тот самый Product Owner ... и не важно внутри он вас (ваш маркетниг -- т.е. то что вы пишите как "мы сами себе заказчики") или на стороне заказчика. Проблемы с английским - это частная проблема, которая при готовности инвестировать в это деньги со стороны вашего менеджмента -- решаема, а не проблема методологии :-). Тендеры, и их требования, не означают того, что вы не будете общаться с заказчиком в процессе разработки если его таки выиграете. Если при таком тендере заказчик не желает с вами общаться вообще, значит можно быть уверенном в том, что победитель уже известен (с ним уже пообщались), а всем остальным отведена роль статистов.
614
Вакансии / Re: Системный архитектор .Net (СПб)
« : 19 Сентября 2007, 00:06:16 »
о ... Терехову-старшему мой .... э, "привет" как-то не удобно сказать, из-за разнице в возрасте, "поклон" ... как-то тоже не ложиться ...
... вобщем нечто позитивное :-). Он участвовал в круглом столе по требованиям на SEXR 2006 в качестве приглашенного эксперта, который я вел.
... вобщем нечто позитивное :-). Он участвовал в круглом столе по требованиям на SEXR 2006 в качестве приглашенного эксперта, который я вел.
615
Системный Анализ и Требования / Re: Управление рационализаторской деятельностью
« : 16 Сентября 2007, 21:53:58 »
1. В документе Vision (я обычно называю его "Концепция" или по Вигерсу "...об образе и границах", если у заказчика аллергия на Концепции) не следует использовать термин "функции системы", т.к. фичи это строго говоря не эквивалентны функциям системы (в классическом виде). Фича это скорее "возможность, особенность, отличительное свойство" системы -- использовать в зависимости от контекста.
2. Юзкейс написан вполне нормально. Единственно я бы добавил конечно расширения, чтобы понимать где и что может отрубиться.
3. В обоих документах IMHO не хватает иллюстраций. В частности в описание предметки и процессов -- я бы нарисовал общую схему процесса в виде, например, activity диаграммы с object flow. А в Vision обязательно нужно добавить контекстную диаграмму.
Фича, она же feature, она же характеристика, свойство, особенность, признак (Добавлено модератором)
2. Юзкейс написан вполне нормально. Единственно я бы добавил конечно расширения, чтобы понимать где и что может отрубиться.
3. В обоих документах IMHO не хватает иллюстраций. В частности в описание предметки и процессов -- я бы нарисовал общую схему процесса в виде, например, activity диаграммы с object flow. А в Vision обязательно нужно добавить контекстную диаграмму.
Фича, она же feature, она же характеристика, свойство, особенность, признак (Добавлено модератором)