16

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

« : 18 Мая 2009, 03:18:02 »

А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
В данном случае: М - модель, описанная требованиями, S - предметная область, A - оценка трудоемкости реализации, например.

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

Вторая цитата: Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Вот Вам и критерий.

Как нам понять, что мы достигли заданного уровня точности?
Моделью для разрабатываемой системы являются классы требований (бизнес-требования, пользовательские, функциональные и т.п.) и их представление (диаграммы), точность характеризуется собираемостью требований того или иного класса и написанием тех или иных диаграмм, их детализацией. Формально, требование о нагрузочном тестировании написано, считается, что мы построили модель необходимого качества, так? Hо реально, требование не отражает действительность.
Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?

17

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

« : 15 Мая 2009, 11:46:44 »

Проблема — это разница между Существующим и Желаемым.
Что происходит сейчас?
Что Вы хотите, чтобы происходило?
Нет критериев оценки качества выявления? А зачем они нужны? Сделайте RCA, пожалуйста.

Не совсем понял, RCA - ...?

Аналитик требований, пообщавшись с заказчиком, приносит следующее требование:
"Проверить нагрузки, например привести пример одновременного сеанса работы на 20 АРМ, или как вариант запустить по несколько АРМ на одном ПК".
Что из него видно? У аналитика отсутствует понимание нагрузочного тестирования, у заказчика этого понимания тоже не видно, в результате появляется требование, которое совсем не отражает действительность, которой должна соответствовать система. Понятно, что на этапе анализа это несоответствие будет выявлено, Старший аналитик сделает замечание, будет проведена повторная беседа с заказчиком и требование будет отражать действительность.
Но, что хотелось бы увидеть - аналитик на этапе сбора информации, сразу, даже не обладая знаниями процесса нагрузочного тестирования, сможет отразить действительность, например:
1. Сформулирует с заказчиком цели/средства/методы проведения нагрузочного тестирования и определит необходимость этого требования;
2. Уточнит почему только 20 пользователей, а не максимальное возможное количество + %;
3. Уточнит выполнение каких действий подразумевать под работой;
4. ...

Можно ли под это подвести теоретическую модель, я не знаю.

18

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

« : 15 Мая 2009, 00:59:02 »

Что-то я не понял, какую проблему решаем и почему она важна.
Алексей, можно Problem Statement? А то мне видится, что вместо проблемы обсуждается организация одного из множества возможных решений, со всеми вытекающими.

Это не то, что бы проблема.
Существуют некоторые рекомендации по выявлению, высказанные не мной, например:
Аналитик обязан, попытаться вытащить на «поверхность» все предположения (знания) пользователей и разрешить конфликты между требованиями.
Учитывая, что модель пользователей может не полностью отражать действительность - «читайте между строк», чтобы определить те возможности или характеристики, которые пользователи полагают само собой разумеющимися и даже не считают нужным обрисовать.
Различные специалисты предлагают использовать бесконтекстные вопросы, узкоспециализированные вопросы и вопросы, допускающие разные толкования, чтобы выявить информацию о проблемах и их возможных решениях.
В процессе сбора информации и осмысления работающий творчески аналитик не только фиксирует слова пользователей, но и подкидывает им новые идеи и предлагает альтернативы.

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

19

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

« : 14 Мая 2009, 14:34:44 »

ИМХО говорить просто про выявление (сбор) требований, не имеет смысла. Имеет смысл, как минимум, говорить об этапах Сбора и Анализа требований, т.к. они очень сильно переплетены.

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

Критерии тобой приведенные будет сложно измерить...

А другие измеряемые критерии есть?

20

Системный Анализ и Требования / Критерии качества работы с требованиями

« : 14 Мая 2009, 12:55:36 »

Здравствуйте!
Помогите, пожалуйста, с ответами на вопросы.
1. Можно ли говорить о критериях этапа выявления требований и нужно ли? Под критерием понимается некий признак, на основании которого производится оценка этапа выявления (сбора информации).
2. Покрывает ли этап анализа требований оценку этапа выявления?
3. Что вы скажете, если использовать следующие критерии:
- внутренняя согласованность и непротиворечивость;
- системность;
- объективность;
- историзм.
 ?
4. Внутренняя согласованность и непротиворечивость. В собранной информации, фактах, требованиях достигнуты единство, стройность, гармония, они недиффузны, отсутствуют формулировки, при которых одно требование исключает другое, несовместимое с ним, противоположное ему. Установлены синтаксические связи между зависимыми словами. Учтены оттенки модальности, такие как: пользователь знает, что ...; пользователь думает, что ...; пользователь хочет, чтобы...; пользователь считает, что ... Учтены границы сбора информации. Разрешены все противоречия предметной области и интересы пользователей при формулировании требований.
Системность. На основе собранной информации рассмотрены все уровни многоуровневой иерархической организации любых объектов. На каждом уровне определены специфические свойства объектов, выявлены необходимые связи между ними.
Объективность. Собранная информация, сформулированные факты, требования не истолкованы с точки зрения субъекта – аналитика по требованиям и/или пользователя/эксперта, а отражают настоящую действительность, проблему. Достигнута необходимая глубина понимания - осознаны смысл, сущность, значение.
Историзм. Этот критерий связан с развитием. В собранной информации присутствует история возникновения проблем, которые необходимо решать. Автоматизируемые процессы рассмотрены с учетом временных изменений - присутствует связь как с прошлым, так и с будущим. Структура собираемых требований и сами требования допускают подстройку и коррекцию, как в период разработки, так и во время эксплуатации разработанной системы.
?
5. Каким образом вы проводите оценку этапа выявления требований? Есть ли какие-либо практические примеры, какие критерии при этом используются?

21

Бизнес-анализ и Целеполагание / Re: Первый вопрос при интервьюировании. Анкетирование

« : 12 Апреля 2009, 02:24:52 »

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

Коммерческая логистика говорит о трех основных потоках на предприятиях:
- материальный поток;
- финансовый поток;
- информационный поток.
 Информационный поток сопровождает материальный и финансовый. Сквозные бизнес-процессы на предприятии заключаются в преобразовании материальных, финансовых и информационных потоков. Я бы не стал рассматривать так узко бизнес-процесс, как  Вы, тем более, что "преобразование" - это не "просто" движение.

22

Бизнес-анализ и Целеполагание / Re: Подпроцесс или процесс

« : 16 Февраля 2009, 13:33:51 »

Алексей, я использую диаграмму Activity - UML.

UML позволяет описывать подпроцессы на основной диаграмме деятельности, для этого предлагается использовать элемент "Structured Activity Node" (UML Superstructure Specification, v2.1.2, subsection 12).
В зависимости о задачи, возможно использование нескольких типов элементов:
- Structured Activity Node - описывает обычный, исполняемый вид деятельности, операции которого не используются в других видах деятельности;
- Loop Node - циклический вид деятельности, состоящий из нескольких секций: настройки, проверки условий и тела (настройка осуществляется каждый раз при входе в цикл);
- Sequential Node - последовательный вид деятельности, в котором все действия выполняются по порядку;
- Conditional Node - вид деятельности выполнение которого варьируется в зависимости от входных условий (состоит из двух секций: проверки условий и тела);
что позволяет довольно гибко подходить к описанию подпроцесса и встраивать его в различные бизнес-процессы.

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

23

Бизнес-анализ и Целеполагание / Re: Подпроцесс или процесс

« : 16 Февраля 2009, 11:23:14 »

А вы какие диаграммы используете для описания и в какой нотации?

24

Системный Анализ и Требования / Re: Документирование и классификация требований

« : 01 Декабря 2008, 13:31:12 »

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

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

25

Конференции Семинары и Тренинги / Re: [Семинар] Классификация требований, 29 ноября, СПб

« : 27 Ноября 2008, 22:07:47 »

План доклада на семинар:
1. Классификация требований
2. Документирование требований
3. Аспекты классификации унифицированного процесса
4. Методы выявления

26

Примеры / Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму

« : 06 Октября 2008, 13:36:13 »

Можете написать конструктивную критику?

Такие технологические вещи, как "JSON", "НТМL", "XML" на диаграммах ВИ вообще не показываются. Их целесообразно отображать на диаграммах компонентов.

27

Конференции Семинары и Тренинги / Re: [Семинар] Техники Вариантов Использования, 11 октября, Спб

« : 29 Сентября 2008, 09:15:04 »

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

Итересная, как мне кажется, всем известная, всеми зачитанная статья размещена на RSDN "Варианты использования 10 лет спустя": http://www.rsdn.ru//article/Methodologies/usecases.xml.
В этой статье дана небольшая историческая справка и базовые понятия ВИ.

28

Термины и Определения / Re: [Термин] Vision

« : 11 Сентября 2008, 21:44:13 »

Проголосовал за "Концепция", хотя мне больше нравится "Образ" - красиво и литературно 

29

Конференции Семинары и Тренинги / Re: [Семинар] Техника Вариантов Использования, 4 или 11 октября, Спб

« : 08 Сентября 2008, 16:27:20 »

т.е. не будет носить никакой юр. силы

а о какой силе идёт речь?

30

Конференции Семинары и Тренинги / Re: [Семинар] Техника Вариантов Использования, 4 или 11 октября, Спб

« : 08 Сентября 2008, 15:56:03 »

Здравствуйте!
Запишите меня пожалуйста на семинар.
Согласен с высказанными пожеланиями:

Потому задачей семинара я вижу рассмотрение ВИ именно в практической плоскости:
1. Где и когда целесообразно использовать ВИ, а где нецелесообразно. Категории задач
2. Как ВИ используется на стадиях разработки и в разных дисциплинах
3. Разработка рабочей документации по ВИ - минимизация затрат
4. Проектирование на основе ВИ - реальность или блажь
5. и примеры примеры примеры

и хотелось бы ещё услышать об установлении связей между ВИ и другими требованиями. Спасибо.