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

×


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

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


Сообщения - Denis Beskov

632
Несмотря на жаркую пору и период отпусков, мы, Школа системного анализа,
решили запустить новый долгожданный тренинг, успешно прошедший пилотирование —
«Основы разработки Use Case'ов».

Тренинг ведёт Сергей Мартыненко, эксперт по качеству ПО и бизнес-анализу,
автор блога «255 ступеней».

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

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

Участники узнают:
* О различных типах нотаций для описания требований
* О структуре типовых документов требований
* О применимости разных нотаций для разных типов проектов
* Для каких типов проектов юcкейсы подходят хорошо, для каких плохо
* О потребителях требований

Участники тренинга научатся:
* Писать юcкейсы
* Составлять документ требований на основе юcкейсов
* Верифицировать требования на полноту

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

Программу смотрите на странице тренинга:
http://school.system-analysis.ru/trainings/use-case-bas/

633
Наверное, стоит. Я, честно говоря, ещё даже не знаю, что такое требования к пригодности. Пригодность - это что-то из стандарта ISO9126? Если да, то как оно называется в оригинале?
Это я так перевожу usability. В русском ГОСТе переведено как Практичность: http://intexpro.ru/Doc/GOST_R_ISO_MEK_9126-93.pdf

634
Например, я выступаю на конференции и рассказываю о том, насколько важно удобство инструментов управления требованиями для разных участников разных процессов, а ко мне потом подходят и говорят: "ну так всё, о чём вы рассказывали, наша система умеет делать, в чём проблема?"
Может тебе тоже стоит начать с требований к пригодности? Ты, насколько я помню, тоже рассказывал про интерфейсные РЕШЕНИЯ, а не про требования к пригодности, которые они обеспечивают.

635
Elf, я обращался к darco, Nataly, greesha.

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

Цитировать
Или пригласить юзабилистов для участия в проектировании UI.
В проектировании-то да, но это опять про обеспечение. Мой опыт показывает, что большинство проектировщиков интерфейса не умеют разрабатывать НФТ по части пригодности.

637
Эксперты по этим дисциплинам вполне в состоянии выявлять и описывать соответствующие требования, исходя из теории и собственного опыта. В отличие от многих аналитиков, которых до сих пор учат, что нефункциональная сторона системы - это что-то второстепенное.
И что из этого следует?

638
Я вам всем завидую, что вы можете содержательно обсуждать подобные постановки. Для меня всё это выглядит как: «Есть Эгрегор, Гарфункель, Мана и Царапель. Царапель хочёт квёлы насуслить, бряквы немытив. Мана не против, но туже глядеши. Как стукузить грелку, если Эгрегор закатно зычит?»

639
Многие группы НФТ давно уже превратились в самостоятельные дисциплины, с собственными специалистами: информационная безопасность, производительность, юзабилити.
Гриша, эти дисциплины изучают методы обеспечения этих аспектов качества, а не задания требования к ним.

640
Илья, мы бы хотели сослаться на твою книгу в своём списке рекомендованной литературы. Какой магазин лучше указать?

641
Первый прогон курса завершился. Спасибо всем участникам!

Об опыте проведения курса расскажу на ЛАФе:
http://conf.uml2.ru/class/opyt-onlain-prepodavaniya-razrabotki-trebovanii.html

642
Некоторый обзор сертификаций с Analyst Days-2: http://www.slideshare.net/maieutic/ss-21996344

643
Большая часть лекций уникальная, нигде ранее не публиковавшаяся, так что у вас будет возможность получить материал первыми и из первых рук :)

644
Нужны волонтёры для расшифровки видео выступлений и лекций на аналитическую тематику.

Если вам интересно — пишите мне на denis.beskov@ gmail

645
1.Что именно фиксировать? Какие могут быть параметры (время поиска требуемой информации, удобство использования, трудозатраты на актуализацию, кол-во противоричивых требований..)
Вы хотите автоматизировать процесс или операции?
Если процесс, то у процесса можно определить его показатели.
У вас процесс УТ уже есть? Зачем он нужен?
Как вы меряете его эффективность сейчас?
Если не меряете, то зачем асфальтировать дороги, по которым ходят коровы?

Подсказки:
Время согласования требований — это показатель процесса разработки требований, а не управления.
Количество согласований — тоже.

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

Денежные потери, возникшие в результате ошибочных решений о рамках релизов и итераций — вполе себе показатель процесса управления требований.