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

×


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

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


Сообщения - Сергей()

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
106
По 34 ГОСТу перед ТЗ есть ещё 2 этапа:
1. Формирование требований к АС
2. Разработка концепции АС
http://standards.narod.ru/gosts/gost34/34-601-90.htm

имхо пользовательские истории более уместны в отчете по первому этапу (формирование требований), чем в ТЗ. Как вариант решения, если просто хочется "чтобы было по ГОСТу", создайте этот отчёт. Там много пересечений с ТЗ, требования к содержанию отчета есть здесь: http://standards.narod.ru/gosts/gost34/50-34698-90.htm, приложение 1.

Да, мы в курсе про этап формирования требований.
Но дело в том, что не просто " хочется чтобы было по ГОСТу", а чтобы было как я написал в исходном вопросе: чтобы ПИ были добавлены в ТЗ.

Мы все время уходим от моего главного вопроса, пытаемся его обойти.
Я попросил высказать свои мнения о том, в какое место ТЗ лучше всего вставить ПИ с учетом логики изложения ТЗ и особенностей ПИ.
Я предложил добавить новый раздел между разделом "3. Характеристика объекта автоматизации" и разделом "4. Требования к системе".
Есть лучший вариант?

Еще остался вопрос: могут ли пользовательские истории иметь отношение не к системе в целом, а к какой-то ее части?

Ну и еще появился вопрос чисто по формулировке ПИ - но это лучше в отдельной теме обсудить

107
Что, реально заказчик и ПМ будут садиться и сверять списки из 120 user stories и 50 ФТ между собой? Им больше заняться нечем?

А разве user stories и ФТ не должны быть согласованы между собой когда они находятся в разных документах?
Кто-то же их сверяет.
И какая тогда принципиальная разница с тем, если они находятся в одном документе?

А разве другие части ТЗ не должны быть согласованы между собой?
Да и не только ТЗ...
В проекте много документации, и все документы должны быть согласованы друг с другом.
Кто-то же сидит и читает все это и при обнаружении разногласий - исправляют.
Им - этим "читателям" проектной документации - получается тоже больше заняться нечем?

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

108
Я напомню один из важнейших принципов формулирования постановки задач.
Формулировка постановки задачи должна содержать критерии её приёмки.
Без критериев приёмки это не задача, а название содержания вашей деятельности.
Критерий простой - согласование с руководством проекта и заказчиком.
Если с точки зрения указанных лиц требования в ТЗ верны, а также пользовательские истории, которые будут добавлены в ТЗ, будут соответствовать этим требованиям, то моя задача будет считаться выполненной.

109
ТЗ — это юридический документ.
User Stories — это рабочий информационный артефакт.
Если вы хотите, чтобы с ними ознакомились, совсем не обязательно засовывать их в текстовый документ. Показать и, что важно, объяснить, можно и на реестре US — backlog'е.
Мы уже в который раз говорим о том, что "...совсем не обязательно засовывать их в текстовый документ...", а именно в ТЗ.
С этим вообще никто не спорит.

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

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

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

111
Разделю свой ответ на пункты в контексте своих вопросов...
Но всплыл еще и самый главный вопрос, который я обозначу пунктом 0.

0) Что хочет от меня руководство и зачем оно заставляет меня сделать такое "неправедное" действие

А в чём заключается задача? Вы выяснили, зачем засовывать user stories в ТЗ? Кому это и зачем

нужно?
Задача заключается в доработке ТЗ: добавление в него пользовательских историй (ПИ).
Нужно менеджеру проекта, видимо он знаком с гибкими методологиями.
Считается, что у нас опытный менеджер.
Нужно для того, чтобы участники проекта могли ознакомиться с ПИ.
Программисты кстати тоже выразили такое желание.

А вы вообще уверены, что руководство имело в виду именно user stories? А то терминология сейчас такая, что под этим могут иметься в виду и пользовательские сценарии и use

cases.
Да, именно так мне их и назвали - user stories.

Это решение чего? Как избежать повторного разговора с руководством, чтобы не выглядеть неграмотным специалистом, но всё-таки сделать то, «не знаю что», которого ОНО просит?
Это решение проблемы: куда в ТЗ поместить ПИ исходя из их сути.
Разговора с руководством действительно не хочется.
Да и почему "не знаю что"?
Я знаю "что" надо сделать, руководство это выразило вполне определенно.
Правильно и целесообразно ли это - это другой вопрос.

Выясните, в чём суть намерения включать в ТЗ по ГОСТу конструкции, которые для этого не предназначены.
Т.е. напишите хотя одну главную пользовательскую историю — «Я, как руководство (обло, стозевно и лаяй) специалиста, хочу, чтобы он разместил в ТЗ пользовательские истории, для

того, чтобы … »
Давайте ещё в папку с ТЗ вместо распечатанного текста будем просто вклеивать липкие жёлтые листочки Post It?
Нет, листочки не надо.
Я, как руководство ... специалиста, хочу, чтобы он разместил в ТЗ пользовательские истории, для того, чтобы ... (ну например) менеджер проекта и программисты ознакомились с ПИ

и таким образом получили более полное представление о будущей системе.

---

Еще добавлю.
На данный момент ПИ у нас не существует, как-то так мы перепрыгнули этот шаг.
Руководство хочет восполнить этот пробел, но вот таким необычным способом.
Можно, конечно, попытаться доказать, что они не правы.
Как вариант я предложу руководству оформить ПИ отдельным документом.
Но все-таки, хотелось бы найти наиболее подходящее место для ПИ в структуре ТЗ, исходя из всех условий данной ситуации.

1) Суть пользовательских историй.

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

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

Отличаются они тем, что дают наглядное представление о том, кому, что и зачем надо, но без понимания, как именно это будет работать. И отсутствие детализации — и плюс и минус.

Для детализации к истории могут прилагаться многочисленные приложения, которые выясняются по мере необходимости.
Угу

2.1) ПИ в ТЗ - не место

Выясните, в чём суть намерения включать в ТЗ по ГОСТу конструкции, которые для этого не предназначены.
Денис, исходя из этого ответа я делаю вывод, что по этому пункту у нас противоречий нет - ПИ не должны присутствовать в ТЗ.

2.2) В какое место ТЗ следует вставить ПИ.

Характеристика объекта автоматизации — это описание того, что как сейчас работает, модель AS-IS. А пользовательские истории совершенно точно относятся к целевой модели, как

должно быть, TO BE.
Здесь я согласен.
От размещения ПИ в разделе "Характеристика объекта автоматизации" отказываюсь.

Тогда предлагаю сделать новый раздел в ТЗ после раздела "3. Характеристика объекта автоматизации" и перед разделом "4. Требования к системе".
Так наверное будет логичнее.
Как раз получится что ПИ - это промежуточное звено между объектом автоматизации и требованиями к будущей системе.

3) В какое ТЗ следует включать ПИ: в ТЗ на систему в целом или в ТЗ на программную часть системы

Почему вы не согласны?
Потому что, как мне кажется,  ПИ относятся к системе в целом.
А включение ПИ в ТЗ для какой-то конкретной подсистемы уже накладывает какие-то ограничения на их реализацию.

Этот вопрос пока остается открытым

112
Пользовательские истории не предназначены для такого использования. Им нет места в ТЗ по ГОСТу. Зафискировав user stories в статическом документе, вы получите просто очень плохие требования.
В принципе согласен.
Пользовательские истории - это не требования. Это "заготовка", материал для разработки требований.
Но ведь я так их и обозначу в документе, я их не буду называть "требованиями".
В ТЗ будет два раздела: первый - пользовательские истории, второй - полноценные требования.
Хуже ведь не будет, если в документе появится еще один раздел, предшествующий требованиям.

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

113
Здравствуйте!

Я участвую в написании ТЗ на АС.
ТЗ пишем, ориентируясь на ГОСТ 34.
Недавно руководство проекта решило доработать ТЗ и добавить в него ... "пользовательские истории", и поручили мне сделать это.
До этого я, конечно, про пользовательские истории слышал, однако сам никогда их не писал и в ТЗ не использовал.
Приходится самому кое-что додумывать.

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

Вот что я надумал.
1) Самый важный вопрос. Правильно ли я понимаю суть пользовательских историй?
Пользовательские истории - это способ представления пользовательских требований (один из способов, есть и другие способы их представления, например сценарии использования).
Отличаются они тем, что написаны просто и кратко наиболее понятным для пользователей языком, без лишней детализации.
2) Вопрос о месте пользовательских историй в структуре ТЗ:
    2.1) Вообще пользовательские требования формируются еще до формирования ТЗ. И вообще говоря в ТЗ им не место.
    2.2) Ну раз уж их нужно добавить в ТЗ, то я думаю, что лучше это сделать в разделе "Характеристика объекта автоматизации". Для этого планирую сделать в этом разделе подраздел - так и назову его - "Пользовательские истории".
3) Вообще у нас не одно ТЗ, а целый комплект. Основное ТЗ - это ТЗ на систему в целом, и есть еще несколько ТЗ по подсистемам. Одна из подсистем - это программная часть системы. И руководство предлагает включить пользовательские истории не в ТЗ на систему, а в ТЗ на программный продукт, который реализует основную функциональность всей системы. Я с этим не согласен, но как переубедить руководство? Они считают: так как функциональность реализуется программно, то и написать пользовательские истории надо в ТЗ на программную подсистему.

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

114
Я так и не понял чем нам должно помочь описание ОА? Эти два человека должны договориться - зачем мы описываем ОА, чем нам поможет это описание в ТЗ? Если нам чем-то может помочь описание Организации, то ее описываем, если процесс, то его, если то и другое, то и описываем то и другое.

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

Согласен.
Конечно, цель не в терминах, а в написании конкретного ТЗ.

Только получается что в любом ТЗ мы каждый раз описываем некий конкретный реально существующий автоматизируемый объект.
Нельзя так ставить вопрос "чем нам должно помочь описание ОА".
Описание ОА - это необходимость, описание ОА есть в любом ТЗ.
Хотим мы этого или нет, осознаем мы это или нет.

Другое дело: нужно ли нам осознание того факта, что независимо от нашего желания, но мы в любом ТЗ всегда описываем объект автоматизации.
Я думаю, что это осознание нужно. И вот зачем.

Совокупность реально существующих и описываемых в ТЗ объектов, вернее их абстракция, разработчиками ГОСТ-а была названа "объект автоматизации".
То есть у всех этих конкретных реально существующих объектов, описываемых в технических заданиях, есть какие-то общие свойства и характеристики, важные с точки зрения автоматизации.
Перечисление существенных свойств, признаков и характеристик - это и есть понятие объекта автоматизации.
Знание этих общих свойств и характеристик, и их понимание помогает нам при написании очередного ТЗ.
Это знание - есть определенная теоретико-методическая база.

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

По этой причине создаются стандарты, ГОСТ-ы.
Что такое ГОСТ? Это набор понятий, терминов, методик, разделяемых(!) всеми пользователями этого ГОСТ-а. Это основа коллективного труда.
Если бы не было ГОСТ-а, согласитесь, всем нам писать ТЗ было бы сложнее.
Пришлось бы каждый раз что-то заново придумывать.
И скорее всего каждый для себя разработал бы свой "стандарт ТЗ", с логикой, понятной только ему самому, что затруднило бы понимание его ТЗ другими членами коллектива.

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

И данная дискуссия подтверждает это.
Я напомню почему мы заговорили об ОА.
Изначально вопрос был о назначении системы.
Что такое назначение автоматизируемой системы так никто четко не сформулировал.
Только Эдуард написал: "Назначение системы - это цель использования системы, ее основная функция.". Немного проясняет, но не очень убедительно.
По-моему, Юрий пытался объяснить свое понимание назначения АС через объект автоматизации.
Другие участники темы не согласились  с его пониманием объекта автоматизации.
Так и пошло-поехало...

115
... Если мы описываем его для галочки ...

Нет, не для галочки

... Зачем (для чего) мы описываем ОА? Вот от этого и нужно двигаться. ... 
... Если мы описываем для другой цели, то и нужно понимать эту цель!...

Я этот момент для себя понимаю так:

Наверное цель описания ОА - написать понятное другим людям задание на создание автоматизированной системы.

Ведь чтобы создать АС, нужно прежде всего самому понимать, что мы автоматизируем, и донести это понимание исполнителям.
Для этого и описывают ОА, а также область применения, а также назначение и цели создания системы, и много всего другого.

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

Наоборот, одинаковое понимание ОА будет способствовать однозначному описанию и толкованию задания.
Поэтому мы и стараемся выработать одинаковое понимание терминов ГОСТ-а

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

Хорошо.

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

Хотелось бы еще услышать мнение других участников насчет этого определения ОА.

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

117
Я считаю, что скорее объект автоматизации включает в себя АС, при этом сам видоизменяясь.

Если под объектом автоматизации (ОА) понимать описываемый процесс документооборота, то: как ОА не может включать в себя АС, так и АС не может включать в себя ОА.

Так как между ОА и АС совершенно другие отношения.
Эти отношения не являются отношениями включения.
Это отношения, как вы пишите, "видоизменения", т.е. реализации (как сказано в определении АС)

Грубо: АС реализует ОА.
Более полно: в деятельности АС реализуется ОА.


118
...Как я понимаю, es3000 заключает, что процесс - фактичически некоторое эмержентное свойство АС (?). ...

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

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

Можно ли считать автоматизированный процесс свойством АС?
Затрудняюсь ответить.
С первого взгляда, кажется, что можно.

Так мы уйдем в философию, причем очень глубоко.
Начнем разбираться что такое "свойство".
Я недавно как раз читал книгу: Цофнас А.Ю. Теория систем и теория познания. 1999. Все-таки осилил до конца :)
В ней говорится о том, что объект, свойство, отношение - это суть одно и то же. Все зависит от того, с какой точки зрения смотреть на обсуждаемое явление.

119
Т.е. включает процесс, как объект автоматизации?

Вы наверно хотите сказать, что система не может включать в себя процесс.
Правильно я понял?

Да, согласен. Процесс - это динамика. Процесс не может быть элементом системы.

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

120
Давайте попробуем оттолкнуться от того, с чем мы согласны - от определения АС. Если посмотреть как соотносятся объект автоматизации и собственно сама АС - включает ли АС в себя объект автоматизации? Или объект автоматизации находиться вне АС?

Да, действительно.
А то мы ушли в сторону от основного вопроса: что такое назначение системы.

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »