1

Конференции Семинары и Тренинги / Re: [Конференция] Req Labs, Москва, 17 ноября

« : 20 Ноября 2009, 20:43:53 »

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

Григорий - огромное вам спасибо .

2

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 18 Ноября 2009, 23:55:11 »

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

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

3

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 18 Ноября 2009, 23:35:32 »

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

А по данному случаю это недоработка ПМа - он должен был после отказа пустить на другие объекты заставить закзачика подписать бумагу, что если на других объектах обнаружатся дополнительные  требования, то это будет расширение рамок договора и, следовательно, доп. соглашение по деньгам.

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

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

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

4

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 18 Ноября 2009, 14:32:54 »

По поводу запросов на изменение...
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший. На все наши доводы, что дайте нам хотя бы сделать экспресс анализ нескольких объектов для получения сравнительной оценки только отмахнулся.
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение. Но аналитик не виноват...
Если уж судить работу аналитика по количеству запросов на изменение, то надо брать каждый (запрос) и анализировать его природу. Трудоемкая работа.

5

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 14 Ноября 2009, 00:47:18 »

Вопрос действительно очень интересный. Кстати, Александр Байкин должен был докладывать по Оценке качества требований на конференции Req Labs 2009, но эту тему заменили. Жаль... Это был один из двух докладов, из-за которых я вообще иду на эту конференцию...

6

Проектирование / Re: Проектирование схемы взаимодействия подразделений

« : 08 Октября 2009, 13:57:57 »

Согласен. Но есть один вопрос: как в такой схеме отобразить взаимодействие типа "Взаимодействует", то есть когда подразделения равноправны? Если одно из них условно назначить "гл", а второе "подч", то по запросу 'все подразделения, которые "взаимодействуют" друг с другом' отберется только половина подразделений

ну это как запрос написать...
если руками, то проблем не будет :о))

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

7

Проектирование / Re: Проектирование схемы взаимодействия подразделений

« : 07 Октября 2009, 23:14:48 »

Если еще актуально  ...
Логическая модель БД в ErWin будет, по-моему, будет такой:



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

Если у документа нет уникального номера, думаю, целесообразно ввести ID.

8

Для всех / Re: Контроль доступа и учёт рабочего времени

« : 06 Октября 2009, 19:45:50 »

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

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

А предметные области по определению стандартные, а программные продукты конкурирующих компаний похожи?

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

9

Консалтинг и Внедрение / Re: Документы при приемке ПО

« : 06 Октября 2009, 18:38:21 »

Все зависит от системы. Если программный комплекс достаточно объемный и сложный, то div зрит в корень - вряд ли удастся восстановить или поддерживать его по переданным вам бумажкам...
С другой стороны, что мешает вашим подрядчикам написать в документации откровенную ерунду, или предоставить только часть информации. Формально они свои обязательства выполнят...
В любом случае документацию запросить необходимо (в крайнем случае поможет в новой разработке):
1. Доступ к БД - обязательно, если у по договору вы являетесь собственником программы и базы, то никаких отказов с их стороны быть не должно (мы все передавали по первому требованию).
2. Структкру БД - логическую и физическую модель.
3. Любые документы, описывающий требования к системе - в зависимости от того, какие у них стандарты (пояснительные записки, постановки задач...).
4. Методики расчетов - если ваша система что-то считает
5. Спецификации на отчеты.
По поводу ГОСТов и стандартов - в погоне за формой можно потерять суть. В идеале лучше пусть дадут те документы, которые они сами используют в работе (если это вам удастся), а не делают что-то специально для вас - все может обратиться в формализм и отписки.

10

Для всех / Re: Контроль доступа и учёт рабочего времени

« : 06 Октября 2009, 17:00:42 »

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

11

Идеи и мозговой штурм / Re: Специфика работы с госзаказчиком. Неужели, у всех так?

« : 16 Сентября 2009, 16:13:05 »

Христиан Бенедикт 
Готова подписаться под каждым Вашим словом, или по крайней мере, абзацем )))
Действительно, порой достаточно того, что сменилась где-то там высоко некое ответственное лицо, подул другой ветер, как тут же на местах специалисты и менеджеры ср. звена чувствуют это и меняется стиль работы (иногда в +, иногда в -). Т.е. все очень политизировано... Конечный результат никому не интересен (иногда попросту не нужен)... А если и нужен, то в виде каких-то отчетных документов. А какие деньги под это осваиваются!!! Это отдельный разговор...

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

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

ИМХО заставить работать спецов в таких организациях может ТОЛЬКО их вышестоящее руководство. Поэтому когда проект начинает работать, мы стараемся разработать регламенты, где четко разграничить сферы ответственности и объемы работ. Как правило, руководство трепетно относится к такого рода бумажкам, если они официально подписаны. Боремся с ними их же оружием - формализмом!

12

ПО Аналитика / Re: [Посчитаемся] Какие CASE средства с поддержкой UML вы используете?

« : 16 Сентября 2009, 01:07:31 »

Пользуемся Rational Rose, Visio. Для проектирования БД - Erwin. Выбор сделала фирма, другие продукты не приветствуются.

13

ПО Аналитика / Re: Танцы с бубном: диаграммы классов в SoDA

« : 16 Сентября 2009, 00:38:02 »

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