Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Михаил Курбасов

Страницы: « 1 2 3 4 5 6
76
Лично мне "синенький" специалист был бы интереснее. С ним есть шанс, что этими всплесками можно научиться управлять, делая их выше и стабильнее. Это сложно, но это интересно попробовать. С красненьким все проще - надо просто сравнить: его стабильный уровень выше или ниже ваших потребностей, и исходя из этого принять решение - иметь с ним дело или как.

77
А я и не расстраиваюсь, я прикалываюсь ;D. Просто, на мой взгляд, вопросы составлены не вполне корректно. Многие двусмысленные, нечеткая терминология ("инструменты", которые на самом деле вовсе и не "инструментарий", а методы)... Т.е. когда мы беремся оценивать чьи-то способности, резонно задуматься "а судьи кто?"
Еще почему-то местами пользуется популярностью метод озадачивания людей головоломками (ну, вот типа про сыновей профессоров, лупцующих друг друга). Но, во-1х, способность решать логические головоломки, по моему мнению, не обязательно коррелирует с навыками профессионального аналитика. А во-2х, человеку это может быть просто неинтересно - ну вот нет такого хобби, решать олимпиадные задачки для школьников - и опять же это ничего не говорит о способностях к работе аналитиком.

А насчет предложения по разработке тестов... Я целиком и полностью разделяю мнение г-на Cless, ранее высказанное в этой ветке:
Насколько мне известно самый распространенный способ проверки именно Аналитических способностей ( А заодно и коммуникативных) это Case Interview.  [...] К сожалению _тесты_ достаточно топорная вещь и пригодны только для первичного отсева. ( Простые тесты имеют слабый отсев, сложные отсеивают всех нестандартно мыслящих ... )
Мой опыт применения тестов показывает именно это: сделать точный и однозначный вывод о наличии аналитических способностей _только_ на их основе невозможно.

78
Провел блиц-опрос наших аналитиков по вопросу "Какие инструменты анализа знаете?" С радостью убедился, что правильного (по мнению автора топика) ответа не назвал никто. Теперь я спокоен - эти ребята у нас никого не переманят; мы для них слишком необразованные.  ;D

79
Относительно критериев качества требований тоже существует большое многообразие вариантов перечислений.
Например, в статье Розенберг http://satc.gsfc.nasa.gov/support/PNSQC_OCT96/pnq.html приводится список из 9 критериев качества требований, которые суть:
  • Complete
  • Consistent
  • Correct
  • Modifiable
  • Ranked
  • Traceable
  • Unambiguous
  • Understandable
  • Verifiable


Этот же список критериев качества требований можно найти и в книжке Леффингуэлла.

Другой пример. Вигерс отдельно рассматривает характеристики "превосходных" требований как отдельных атомарных высказываний (requirement statements), и отдельно - критерии качества спецификаций требований (requirement specifications).
Для отдельных требований Вигерс выделяет такие критерии качества:
  • полнота
  • корректность
  • осуществимость
  • необходимость
  • назначение приоритетов
  • недвусмысленность
  • проверяемость
Для наборов требований Вигерс приводит следующие критерии качества:
  • полнота
  • согласованность
  • способность к модификации
  • трассируемость

В этих источниках можно найти не только определения этих понятий, но и рекомендации по тому, как достигать этих характеристик. Мне поэтому до сих пор не очень понятно: если мы выпишем из этих статей/книжек эти определения сюда, на сайт - для чего это нужно? Не лучше ли все-таки изучить первоисточники?

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

Ну, вот раз вы просите, то вот, например, определение требований из IEEE Standart Glossary of Software Engineering Technology, 1990. На данное определение ссылается Вигерс, это же определение приводится в SWEBOK (русские формулировки взяты из перевода Орлика):
  • Условие или возможность, требуемая пользователем для решения задач или достижения целей
  • Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должны обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующих документов
  • Документальная репрезентация (зафиксированное определение, описание) условий или возможностей, зафиксированных в предыдущих пунктах

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

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

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

83
Самый простенький тест - дайте кандидату в аналитики список предметов и попросите придумать как можно больше видов классификации этих предметов. Тест проверяет способность применять разные уровни абстрагирования информации.

Страницы: « 1 2 3 4 5 6