136

Примеры / Re: Uml-модель экономической системы общества.

« : 20 Ноября 2009, 11:46:37 »

      Сегодня с божьей помощью и RRE родил  упрощенную диаграмму "Вариантов использования." Не смог файл с этой диаграммой прикрепить к этому сообщению.

Наверное, Вы пытаетесь разбить предметную область на части?
Для этого лучше использовать пакеты или компоненты, если уж применять uml
Один из лучших способов для этой задачи - простая матрица функциональных областей и описание зависимостей.
Даже есть специальное средство от IBM - SOA IF (пример декомпозиции можно посмотреть в приложенном файле).
Если описывать экономику, то для начала лучше разделить ее по областям, а далее копать в глубь

137

О Сайте и Форуме / Re: А чем Вы можете помочь ресурсу uml2.ru?

« : 19 Ноября 2009, 23:23:17 »

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

Я еще пока не знаю, что такое журнал из пункта 7, может, принесу пользу ему?

Тебя нам и не хватало
Свяжись со мной - обсудим. Про журнал можно почитать на главной странице сайта в разделе Журнал AnalyzeIT

138

Конференции Семинары и Тренинги / [Спб] Круглые столы аналитиков

« : 19 Ноября 2009, 15:25:08 »

Питер, предлагаю собраться и обсудить за круглым столом в узком кругу интересную вам тему.
Формат круглого стола подразумевает:
1. Полное раскрепощение
2. Интересную тему
3. Участие всех присутствующих (скажем нет пассивному слушанию
4. Пиво, немецкие колбаски, соки, воды и т.п. (по желанию)
5. Минимальное количество человек - 3
6. Тихое место (без громкой музыки, шумной толпы...)

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

139

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

« : 16 Ноября 2009, 14:27:14 »

Ты бы ещё Макконнелла вспомнил.

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

Да никак они у нас не используются!
Сам не знаю как их применять нужно по правильному - не дорос еще.
Я их делал исключительно для себя.

140

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

« : 16 Ноября 2009, 13:47:17 »

Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента". Не верите мне, почитайте метров. Деминга почитайте (http://findbook.ru/redir/book?url=http%3A%2F%2Fwww.bolero.ru%2Fcgi-bin%2Fdsc.cgi%3F66641528%26partner%3Dfindbook%26new%3D1).
Или Генри Нива : http://findbook.ru/redir/book?url=http%3A%2F%2Fmy-shop.ru%2Fshop%2Fbooks%2F132831.html%3Fpartner%3D00519 (у него язык попроще)

Де Марко вроде бы по другому считает

141

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

« : 16 Ноября 2009, 13:41:12 »

Я поняла, что речь и идет об атрибутах, используемых в средстве управления требованиями.

Источник - это то, откуда у требования "растут ноги". Чаще всего это документ (нормативный или внутренний). Либо конкретный человек, предложивший это требование.

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

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

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

142

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

« : 16 Ноября 2009, 11:05:20 »

Думаю что следует задать главный вопрос:
Для какой цели Вы планируете использовать количественную оценку работы аналитика ?

Кому вопрос?
Если мне, как инициатору топика, то фраза "Кто-нибудь на практике  этим занимается?"
Имеет примерно следующий смысл - А нафига вся эта теория в жизни?

А если серьезно, то вещь нужная, просто до нее необходимо дорасти.

143

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

« : 16 Ноября 2009, 10:03:37 »

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

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

144

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

« : 16 Ноября 2009, 09:56:17 »

Качество -не есть соответствие чьим либо ожиданиям.

Ожидание - есть потребность в чем-то.
Джозеф Джуран:
«Качество есть степень удовлетворения потребителя и для реализации качества производитель должен изучить требования потребителя и произвести свою продукцию так, чтобы она удовлетворяла этим требованиям»

ISO 9001:2000:               
Качество – совокупность свойств и характеристик продукции, способных удовлетворить установленные и предполагаемые потребности заказчика.
   

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

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

145

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

« : 15 Ноября 2009, 20:58:30 »

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

146

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

« : 15 Ноября 2009, 20:49:46 »

Возвращаясь к отцу Вигерсу, находим следующие характеристики идеальных требований:
1. Полнота
2. Однозначность
3. Корректность
4. Тестируемость
5. Трассируемость
6. Согласованность
(необходимость и осуществимость я не включаю, т.к., на мой взгляд, не удовлетворяющие этим критериям требования вообще не должны попадать в документы).

Можно опираться на этот список для проверки качества требований.

Список хороший. Только он основан исключительно на экспертных оценках людей, проверяющих требования.
Основной риск в этом случае - насколько "эксперт" является экспертом
Можно посадить заказчика Васю и попросить его оценить полноту. Думаю вы мало чего полезного добьетесь
Каждый пункт этого списка к тому же проверяется отдельными людьми - экспертами предметной области, тестировщиками, разработчиками и сильно зависит от поставленного процесса (попробуйте например в ТЗ на 200 страниц, которая параллельно разрабатывается несколькими людьми, определить согласованность и трассируемость)
У меня был такой опыт, когда в НИИ ТЗ по частям писали несколько человек и потом склеивали в один документ.

И напоследок следует наверное заметить, что такое согласование займет не меньше нескольких недель (причем качество все равно никто не гарантирует), что в большинстве случаев не приемлемо для проектов

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

147

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

« : 15 Ноября 2009, 20:31:51 »

Тип, Состояние, Источник, Приоритет, все назначения (кому реализовывать, кому тестировать, кому проверять).. так из основного вроде все. Название, разумеется

Марина, как вы прописываете источник требований? Для каждого требования руками пишите Имя и Фамилию? и используете ли вы какое-либо инструментальное средство для этого?
По поводу назначения - а если человек уволился из команды или взяли нового для всех требований меняете ответственного? Это скорее всего деятельность руководителя проекта

Да в самом деле, на фига нам приоритет? Давайте все оптом реализуем!

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

Описательные:
* Тип
* Уровень.

Сергей, а вы не связываете эти два понятия? Обычно тип заключает в себе уровень абстракции

148

Системный Анализ и Требования / Управление требованиями. Атрибуты

« : 14 Ноября 2009, 02:38:40 »

Привет. Друзья, те из вас, кто управляет требованиями в проектах расскажите какие атрибуты вы используете и как они помогают вам управлять требованиями?
Я на текущий момент реально использовал только тип, стереотип, фазу, идентификатор, состояние и приоритет (в порядке убывания значимости) в основном для трех целей:
1. Cтруктуризация модели требований
2. Отслеживания состояний готовности
3. Документирования
Интересно узнать в рамках обмена опытом .

149

О Сайте и Форуме / Re: Какой должна быть рассылка?

« : 12 Ноября 2009, 17:09:38 »

однозначно...

+1

150

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

« : 12 Ноября 2009, 14:32:41 »

... количественным методам оценки эффективности:
- работы аналитика, как конкретного сотрудника;
[/quote]
Кто-нибудь на практике  этим занимается?