31

Для всех / Re: Анализ наполняемости системы

« : 03 Сентября 2013, 08:58:05 »

Есть ощущение, что задача не очень однозначно сформулирована.

Вот как заказчик узнает, что вы решили задачу? Что будет эпик фэйлом проекта?

По вашему описанию масса гипотез возникает:
- возможно вам что-то типа MDM нужно
- возможно у вас кол-во товара\деньги раэъехались в системах Х и У (ну или что-то в таком духе)
- возможно вам БД отчётов нужна какая-то
- возможно тупо в системе Х большой босс видит неправильную цифру

32

ПО Аналитика / Re: Помогите с выбором инструмента для описания БП

« : 02 Сентября 2013, 20:01:50 »

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

Вот скажите:
- Кто принимает решение, что вы ранжировали хотелки правильно? Вы сами? Владелец бизнеса? Аудиторы\консалтеры? Начальники отделов?
- Как вы видите описанные вами ситуации, после того как вы правильно описали БП в правильном инструменте? Начальник отдела приходит с хотелкой, а вы нажали кнопочку и говорите, эээ дружище чего-же ты меня с ROI то хочешь обмануть - приоритет 110 твоему проекту никак не больше. Или даже так, приходит к вам владелец бизнеса и говорит Антон, вот тут начальник транспортного цеха проект предлагает, что думаешь про ROI?
- Как вы думаете, ситуация, когда CIO принимает за бизнес решения чему развиваться, а у чего по хитрому описанию БП нет перспективы, она долго продлится? Думаю полгодика покряхтят все, а потом чего-нибудь и сделают с "оборзевшим" CIO. Благо повод будет - ИТ-отдел совсем перестал развивать собственно ИТ, а половину времени схему БП перерисовывает

33

Системный Анализ и Требования / Re: Применяются ли методы Goal modeling при разработке требований?

« : 02 Июля 2013, 15:56:13 »

ну из статьи следует что:

There are several notations for goal models in software development, including:
    i* (pronounced "eye-star") and a variant, GRL[6]
    KAOS [7]
    UML Use Case diagram[8]

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

34

Сообщество Аналитиков / Re: Какие проблемы вас волнуют больше всего?

« : 24 Июня 2013, 16:49:05 »

Хороший вопрос.

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

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

Волнует, как планировать сроки согласования документов.

Волнует, стоит ли пытаться развиваться в сторону англоязычных проектов (язык пока pre-Intermediate). Тут и  на русском то иногда призадумаешься правильно ли понял заказачика. А если ещё и чужой язык будет?

Иногда волнует, а не податься ли обратно в разработчики, после 7 лет аналитиком . 

35

ПО Аналитика / Re: Как оценить внедрение СУТ? ROI (Return on Investment)

« : 20 Июня 2013, 08:19:20 »

А если подсчитать частоту упоминания ЕА, Word и Excel, то наверное всех форумчан можно объявить как тайных агентов Sparx Systems или Microsoft

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

36

UML SysML и пр. / Re: Почему Вы используете или не используете UML?

« : 19 Июня 2013, 09:25:06 »

Я уважаю ваше мнение, но не могу согласиться.UML никогда не позиционировался как система для моделирования бизнеса. Вы пытаетесь усадить UML на чужой стул.
UML никогда не был языком программирования и не должен стать, иначе естественно он будет громоздким и неудобным. Однако UML - это язык МОДЕЛИРОВАНИЯ, разница ощущается?
Забавное у вас представление об архитектуре и архитекторах. Будто бы Главнй Конструктор (ну тот  что вселенные создает походя, чего ему тут UML как зубочистка)
Просто мало кто реально знает, понимает как использовать этот язык. Кто потратился на это, понимают преимущества. Однако ведь задачи задачам рознь. Это как единоборства, у кого-то получается, у кого-то нет. Но без тренировок само по себе ничего не происходит

Про моделирование бизнеса. Даже на этом сайте были статьи типа "Использование UML для моделирования БП". И в книжках есть на эту тему немало. Рад, что не я один считаю, что uml для этой цели не совсем подходит.

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

Про то что это не язык программирования. Помнится, когда вышел uml2 было много информации на тему, что теперь uml наконец-то стал (ну или почти стал) пригоден для однозначного определения кода программы. И всех нас неминуемо ждёт MDA. Так что, не вижу криминала в том чтобы смотреть на Uml, как на язык программирования.

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

37

UML SysML и пр. / Re: Почему Вы используете или не используете UML?

« : 17 Июня 2013, 20:39:56 »

Отдельные диаграммы из uml использую - восновном sequence и state-chart.

С моей точки зрения, uml сел между всех стульев:
- Для бизнеса - он слишком технический. Есть гораздо более простые способы донести свою мысль.
- Для разработчиков - он вроде бы и язык программирования, только очень громоздкий и неудобный. 
- Для архитекторов - он слишком детализированный что-ли. Архитектор размышляющий на уровне uml  - какой-то уж совсем наноархитектор получается.  Да и архитектурные вопросы, по моему,  в ООП парадигму не укладываются совсем.

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

38

Системный Анализ и Требования / Re: Образцы ТЗ по ГОСТу

« : 13 Июня 2013, 20:58:07 »

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

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

Ну и вообще, неужели портал МЭРТа беспрецендентен в мировой практике? Хотя бы ради этого вопроса интересно знать ответ.

39

Системный Анализ и Требования / Re: Образцы ТЗ по ГОСТу

« : 11 Июня 2013, 16:47:57 »

 

Учитывая, что Руководство по проектированию госуслуг на GOV.UK, например, рекомендует для описания потребностней пользователей использовать формат User Story и прототипы, не думаю, что таковая документация будет иметь для вас какую-либо ценность: https://www.gov.uk/service-manual/phases/discovery.html

Ну интересуют не только пользовательские требования. Во вторых, думаю, даже в Британии не на всех проектах применяются юзерстори. Ну и на Великобритании свет клином не сошёлся, в штатах вроде бы в public domain очень много чего находится.

40

Системный Анализ и Требования / Re: Образцы ТЗ по ГОСТу

« : 11 Июня 2013, 15:48:07 »

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

41

Конференции Семинары и Тренинги / Бесплатный семинар по CA ErWin 19 октября Москва

« : 15 Сентября 2010, 18:38:28 »

Более подробное описание по ссылке:
http://www.interface.ru/home.asp?artId=24318

Думаю многих может заинтересовать.

 

42

Для всех / Re: Соотношение количества аналитиков и разработчиков в команде.

« : 13 Февраля 2009, 19:23:38 »

А в чем проблема? Если ПО выходит с должным качеством, запросов на изменение одних и тех же требований не много, то м.б. так и надо?! Или Вам кажется, что Аналитики в потолок плюют и ничего не делают? Так займитесь учетом их времени.

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

Подозрения, судя по всему, подтверждаются. Судя по ответам коллег, соотношение близкое 1:1 упоминается скорее как исключение.

43

Для всех / Re: Соотношение количества аналитиков и разработчиков в команде.

« : 12 Февраля 2009, 19:34:09 »

Спасибо ida за подробный ответ!

Попробую переформулировать вопрос, чтобы избежать дальнейших упоминаний о "средней по больнице"

У одного моего знакомого, в ИТ-отделе, который тоже восновном занимается внутренними проектами по доработке самодельной ИС, за последний год вместо 3 аналитиков и 5 разработчиков стало 4 и 4. 

Как вы думаете, это перекос или близко к среднему для этого контекста?

44

Для всех / Re: Соотношение количества аналитиков и разработчиков в команде.

« : 09 Февраля 2009, 16:36:40 »

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

И всё таки, коллеги, сколько?

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

В силу моей специфики, был бы особо признателен за упоминания о внутренних проектах по доработкам корпоративных ИС.

45

Для всех / Re: Соотношение количества аналитиков и разработчиков в команде.

« : 09 Февраля 2009, 07:21:08 »

Понятно, что на разных этапах проекта это соотношение разное. Интересует конечное (после закрытия проекта) соотношение (Все трудозатраты людей с должностью "Разработчик")/(Все трудозатраты людей с должностью "Аналитик").

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

Вопрос был скорее - а сколько бывает у Вас? В среднем. Крайности тоже интересны.