361

Обучение / Re: CPRE и CBAP

« : 15 Октября 2014, 06:08:38 »

1) Откуда такая уверенность, что CBAP покрывает CPRE?  Насколько я понимаю, это все-таки разные предметные области. Управление требованиями в software engineering   и управление бизнес-требованиями - несколько разные вещи.

А почему вы говорите про УПРАВЛЕНИЕ требованиями? Это только часть деятельности.

362

Обучение / Re: CPRE и CBAP

« : 11 Октября 2014, 19:49:52 »

Насколько существенным подспорьем при трудоустройстве является сертификат CBAP?

При прочих равных рекрутёр при поиске не пушечного мяса и просмотре списка резюме скорее выберет кандидата с сертификатом. Это то, во что я точно верю

Все вменяемые работодатели смотрят прежде всего на опыт работы, отзывы и примеры документов. Сертификат влияет только на то, кого смотреть первым. Иногда этот фактор может стать решающим.

363

Обучение / Re: CPRE и CBAP

« : 11 Октября 2014, 19:46:38 »

Денис, спасибо за ответ. Правильно ли я понимаю, что CPRE в РФ пока никто не сертифицирует?

Почему, сертифицирует. Можно выбрать один из 10 центров в Москве, есть и в других городах: https://www6.pearsonvue.com/testtaker/registration/SelectExamPage/ISQI/33491

364

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 09:59:37 »

Я здесь не вижу ничего про «внутреннее поведение» и «прячем». Я вижу риторику про сдвиг от содержания деятельности к её результату, также, как в именовании юскейсов «Найти письмо» вместо «Искать письмо».

Я своим студентам рекомендую писать «Система убеждается, что ... и сообщает …», т.к. вижу 2 разных операции, также, как, например, в случае сохранения.

365

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 09:43:09 »

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

В юскейсах нет уровней представления и бизнес-логики, есть чёрный ящик или серый. И ещё я использую юскейсы для выявления ФТ.

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

Да, эту работу может делать аналитик, тут не нужны никакие архитектурные компетенции.

366

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 09:36:53 »

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

Это где он о таком пишет?

367

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 06:24:43 »

По расширениям:

Выбрана неудобная система идентификации расширений. Схема 1а1а1 кмк намного нагляднее.

Расширение 1.1. Условие входа в расширение — это условие-событие, которое ВЗАИМОИСКЛЮЧАЩЕЕ для событий того шага основного потока, в котором оно возникло. В данном случае события шага 5 основного потока и условие входа в расширение 1.1. вполне совместимы. Всё дело в пропущенном шаге контроля вводимых данных.

Обработка расширения — из условия входа неясно, каково всё-таки правило совпадения пользователей — должны совпадать имейлы, или имейлы+ФИО или ещё как-то? Если речь только об имейле, то очень глупо, если человек ошибся в одной букве имейла так, что это привело к совпадению с уже существующим пользователем, терять введённые им данные и просить заполнить всё заново.

Например, у вас уже есть smirnovaa@mstu.ru и вы пытаетесь добавить ещё одного однофамильца, у которого первая буква имени — A. Система должна подсказывать, что делать, а не тупо ругаться и сбрасывать форму.

368

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 10 Октября 2014, 06:16:06 »

Давай по шагам юскейса:

1. Чтобы Администратор мог сделать запрос, система должна сначала предоставить ему такую возможность. Хотя бы в виде курсора командной строки. Есть скрытый вариант типа горячих клавиш, но тут, как я понимаю, не тот случай. Не хватает этого шага.

2. Лучше разделить на 2-3 операции опять же (в одном шаге), например, «показывает список доступных ролей и предлагает выбрать одну из них». Если список ролей уже известен (и будет зашит в систему), лучше сразу написать его здесь.

4. Тут нужно указать состав полей или сослаться на структуру из Словаря данных. Юскейс может использоваться для проектирования и разработки без предварительного создания списка ФТ, поэтому в нём должно быть достаточно информации для проектирования.

5. Администратор не может ничего сохранять. Сохраняет система, пользователь только предоставляет данные и команды. См. заметку Сергея Нужненко: http://boatmanshome.ru/wiki/wacko/?page=Zametki/StopTheMagic&v=1c9h

6. Пропущен шаг по проверке корректности заполнения полей и уникальности пользователя.

8. Лучше этот шаг сделать шагом 0, а на 8-м шаге поставить «Сценарий продолжается с шага 0». Но таким образом возникнет бесконечный цикл, который придётся разрывать исключением 1а.

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

Из текущего сценария получается, что пользователь видит заполненную форму и предложение добавить другого пользователя. Это странно.

Если Админ чаще вводит несколько пользователей подряд, то лучше указать, что система показывает форму нового пользователя с последней ролью и возможностью её сменить.

Если Админ чаще вводит по одному пользователю, то логично, чтобы сценарий показывал список всех пользователей с выделением только что добавленного или предлагал какие-то другие шаги, которые обычно делает Админ после регистрации (например, настройка квот, включение в группы, что-то ещё).

369

Конференции Семинары и Тренинги / Re: МСК — Тренинг «Основы разработки Use Case'ов»

« : 08 Октября 2014, 07:33:25 »

Очередной тренинг пройдёт 26 октября, в воскресенье.

370

Обучение / Re: CPRE и CBAP

« : 03 Октября 2014, 20:07:12 »

А вы уверены, что CBAP покрывает CPRE? Я — нет.

371

Обучение / Re: CPRE и CBAP

« : 03 Октября 2014, 20:05:47 »

В США более известен CBAP. В Германии и Швейцарии — CPRE.

По России сказать сложно, т.к. 2 компании — это не рынок.

372

Конференции Семинары и Тренинги / МСК, Тренинг «Практика концептуального проектирования автоматизированных систем»

« : 02 Октября 2014, 13:42:59 »

13 октября, в понедельник, Сергей Нужненко проведёт в Москве тренинг
«Практика концептуального проектирования
автоматизированных систем»

Для кого этот тренинг

• Менеджеры проектов, ведущие и старшие системные и бизнес аналитики,
  задействованные в концептуальном проектировании
  автоматизированных систем и информационных систем.

Что получат участники

1. Понимание отличий и взаимосвязи автоматизируемой деятельности,
автоматизированной/информационной системы и программного обеспечения.

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

3. Освоят подходы к организации сбора информации и принятию концептуальных решений.

4. Освоят некоторые подходы к технико-экономическому обоснованию
с расходной точки зрения ТЭО (с точки зрения полной стоимости владения).

5. Получат минимально необходимый набор аналитических навыков
и практику концептуальной проработки системы.

Программа тренинга

1. Модели и взаимосвязи ключевых изучаемых и проектируемых объектов:
автоматизируемая деятельность (объект автоматизации),
автоматизированная система, информационная система, информационная технология,
программное обеспечение, другое обеспечение, состав работ по построению автоматизированной системы.

2. Карта объекта автоматизации и цели автоматизации.
Виды, взаимосвязь и техники измерения показателей, формирующих цели автоматизации.

3. Информационная технология, как скелет системы.
Состав решений, их взаимосвязь, методы моделирования и анализа.

4. Состав решений концепции. Объект и цели автоматизации,
привязка системы к окружению, функциональный/физический состав и структура,
нефункциональные требования, план создания, полная стоимость владения.

5. Стратегии выявления требований и формирования
концептуальной информационной технологии.
От требований заинтересованных лиц, от анализа проблемного поля,
«примерка стандарта/методологии/шаблонного процесса»,
«подгонка» под технические средства.

6. Проверки концепции на работоспособность.
Выявление ресурсоемкости владения технологиями.
Техники балансировки интересов и разрешения конфликтов в требованиях.

[ Регистрация на тренинг 13-го октября ]

373

Конференции Семинары и Тренинги / Re: Онлайн-курс «Как писать ТЗ»

« : 30 Сентября 2014, 11:45:21 »

Следующий курс пройдёт с 1 по 16 ноября.

374

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 29 Сентября 2014, 12:15:51 »

Как бы вы ростроили модель чтобы не использовать включение и расширение, но избежать дублирования одинакового поведения?

Если дублирование большое, то можно объединить несколько юскейсов в один, а варианты описывать расширениями. Можно описать блок вариаций.

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

375

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 29 Сентября 2014, 12:12:55 »

Денис, мне тоже нравится такой подход. Я обычно немного расширяю его с помощью CRUDL и задаю себе несколько вопросов:
C - Как информация должна попасть в систему чтобы её можно было использовать?
R - Раз уж мы вводим информацию в систему, значит она кому-то нужна и её будут использовать?
U - Действительно ли информация один раз вводится в систему и никогда больше не изменяется?
D - Нужно ли будет удалять введенную ранее информацию? Для чего?
L - Как введенная ранее информационная сущность будет выбираться среди других для просмотра, изменения или удаления? Будет ли таких сущностей настолько много, что нужна будет фильтрация/поиск в списке?

Проверка полноты функциональной модели про CRUDLS-матрице — это уже другой уровень контроля, более глубокий. Сначала бы разобраться с тем, что «замечательно входит и выходит» Тем более что входить могут одни структуры, а выходить совсем другие, и тут нам CRUDLS-матрицы не помощник.