226

Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34

« : 20 Ноября 2013, 16:25:19 »

А какой документ для требований создается " ... в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований ..."?
Если "...это будет уже не ТЗ"?

В том-то и дело, что "документ" в привычном виде не создаётся. Для таких условий Agile и придумали.

User stories обычно пишут на отдельных листочках. Можно загнать их в какой-то инструмент для представления в электронном виде (сейчас таких всё больше благодаря росту популярности распределённой разработки). Например, в devprom. Оттуда их даже можно, наверное, экспортировать в .doc файл. Но при правильном использовании user stories этот "документ" будет изменяться постоянно: еженедельно или ежедневно. Его создание оказывается бессмысленным: работать с историями в онлайн-инструменте намного удобнее (можно искать, группировать, обсуждать, просматривать историю изменений и т. п.)

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

Мы поэтому и не можем дать ответа на "главный вопрос": как втиснуть user stories в ТЗ по ГОСТу. Там для них просто нет места.

Но если руководство требует, то вставляйте в любое. А лучше оформите в виде приложения.

227

Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34

« : 19 Ноября 2013, 21:22:42 »

Хуже ведь не будет, если в документе появится еще один раздел, предшествующий требованиям.

Только если вы готовы менять ТЗ на каждом спринте, добавляя, уточняя и выбрасывая пользовательские истории. Но это будет уже не ТЗ.

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

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

Денис начал с самого главного вопроса: "Кому это и зачем нужно?" У руководства проекта ведь были какие-то соображения, чтобы принять такое решение.

228

Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34

« : 19 Ноября 2013, 19:38:05 »

Вот, совсем недавно делился своими соображениями по этому поводу:
https://www.webursitet.ru/article/polzovatelskie-istorii--trebovaniya-ili-net.html

229

Системный Анализ и Требования / Re: Пользовательские истории и ГОСТ 34

« : 19 Ноября 2013, 19:36:08 »

Что скажете, что посоветуете?

Пользовательские истории не предназначены для такого использования. Им нет места в ТЗ по ГОСТу. Зафискировав user stories в статическом документе, вы получите просто очень плохие требования.

230

Вакансии / Re: off, ВАКАНСИЯ- Администрирование / helpdesk банковского АПК.

« : 13 Ноября 2013, 22:18:43 »

А что такое АПК?

231

Примеры / Re: Нужна помощь, нужньо созжать бизнес процесс в программе Business Studio

« : 11 Ноября 2013, 14:23:03 »

Ну это же сезонное обострение у студентов: очередной семестр заканчивается.

232

Варианты Использования (Use Case) / Re: Место вариантов использования в ГОСТ 34

« : 11 Ноября 2013, 14:20:06 »

Я искренне не понимаю, зачем в ГОСТе искать место тому, что там не предусмотрено. Но, imho, на этапе 1, до разработки концепции, использование ВИ бессмысленно. Что имели в виду авторы пункта под "требованиями пользователя", сейчас трудно сказать, но это явно не user requirements. На этом этапе никто ещё даже не представляет, чью деятельность эта АС будет автоматизировать.

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

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

233

Примеры / Re: Bizagi модель деятельности операциониста

« : 02 Ноября 2013, 18:41:16 »

Если коротко, то я придрался к тому, что в вашей текущей модели, клиент не может подать документы без доп. проверки, независимо ни от чего.
Вот представляете, приходите вы в банк, который работает по вашей модели, хотите вкладик открыть.
Операционист берет ваш паспорт, ляляля и говорит: подождите пару часиков, пока наш другой отдел вас проверит!
Будете с таким банком работать? Вот и я бы не стал:)

В теории примерно так и должно происходить. Банки должны следовать принципу "знай своего клиента". В РФ пока ещё банки готовы принимать в клиенты практически кого угодно, но и здесь постепенно осознают, что риски слишком высоки.

234

ПО Аналитика / Re: Оптимальный инструмент для описания безнес-процессов и разработки требований

« : 24 Октября 2013, 01:06:27 »

Ага, он совсем бесплатный
тут вовсю вот пропагандируют lucidchart.com

draw.io симпатичнее, на мой вкус

235

Конференции Семинары и Тренинги / Дискуссионные вебинары Сообщества Аналитиков

« : 21 Октября 2013, 18:24:51 »

Во вторник, 22 октября, в 21:00 МСК Александр Байкин проводит вебинар на тему «Требования не нужны Аналитики (поставь запятую, где хочешь)».

Тезисы:

Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».

Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.

Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.

Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:

    Задача Джоэля Спольски
    Зачем нужны аналитики?
    Кто такой хороший аналитик?
    Как бороться с извечными проблемами?
    Как быть с Agile?

Ссылка для регистрации:
https://www4.gotomeeting.com/register/638055151


-----------------------------------------------------------------
Активисты Сообщества аналитиков uml2.ru, эксперты Вебурситета и участники других профессиональных сообществ, связанных с разработкой ПО, периодически проводят бесплатные вебинары, на которых делятся своим опытом и поднимают актуальные дискуссионные темы.

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

236

UML SysML и пр. / Re: По каким критериям стоит разбивать 1 большую use case диаграмму на несколько

« : 25 Сентября 2013, 00:14:16 »

Критерии нужно выяснять у тех, кто эту диаграмму будет использовать. Если доступа к ним нет, то попробовать поставить себя на их место.

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

Эта диаграмма, кстати, не такая уж большая: её можно охватить одним взглядом и понять контекст. Только непонятны связи между ролями, и человечков лучше расположить вокруг системы, а не внутри.

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

Ну и у вас там, кажется, CRUD внизу притаился.

237

Обучение / Re: Помогить с выбором темы диссертации в IT

« : 23 Сентября 2013, 23:03:27 »

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

А кто-то ещё помнит про экспертные системы? Не говоря уже о системах интеллектуального поиска. Боюсь, профессор остался в прошлом веке, как это часто у нас бывает.
Статья в русской википедии про ИИС просто мхом и грибами поросла, хотя переписана, судя по всему, из учебника 2012 года.

238

Обучение / Re: Помогить с выбором темы диссертации в IT

« : 22 Сентября 2013, 22:26:54 »

Нейросети как таковые к искусственному интеллекту не относятся

Эд, а что сейчас принято относить к искусственному интеллекту? Я без иронии спрашиваю, просто не в курсе, и очень странно это слышать.

239

Идеи и мозговой штурм / Re: Тестовое задание на написание ТЗ

« : 01 Сентября 2013, 16:34:26 »

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

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

240

Управление Проектом / Re: Скрытые интересы

« : 23 Августа 2013, 17:05:40 »

Расскажу, как ситуация сложилась: стажер нашел новую работу и  уволился с ревом и со скандалом. По версии начальника "мы ее учили , учили, а она нас всех предала. Позвоню туда куда идет, все про нее расскажу."

Старый аналитик объявил "итальянскую забастовку". Делает только задачи анализа.  Ищет работу.

То есть всё идёт по моему плану.