121

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

« : 20 Ноября 2013, 15:21:52 »

Я напомню один из важнейших принципов формулирования постановки задач.
Формулировка постановки задачи должна содержать критерии её приёмки.
Без критериев приёмки это не задача, а название содержания вашей деятельности.

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

122

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

« : 20 Ноября 2013, 15:13:08 »

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

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

123

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

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

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

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

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

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

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

На этот вопрос попытался выше ответить.
Может быть не очень убедительно, но как есть.
А действовать надо.

124

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

« : 20 Ноября 2013, 01:51:59 »

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

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

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

нужно?

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

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

cases.

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

Это решение чего? Как избежать повторного разговора с руководством, чтобы не выглядеть неграмотным специалистом, но всё-таки сделать то, «не знаю что», которого ОНО просит?

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

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

того, чтобы … »
Давайте ещё в папку с ТЗ вместо распечатанного текста будем просто вклеивать липкие жёлтые листочки Post It?

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

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

---

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

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

Не требований, а пожеланий. Если более точно — это трассировка представлений о пользовательских задачах на пользовательские цели.

С тем что ПИ - это не требования - соглашусь.
А какое этому обоснование? Приведенная выше статья от Григория?

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

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

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

Угу

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

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

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

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

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

должно быть, TO BE.

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

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

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

Почему вы не согласны?

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

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

125

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

« : 19 Ноября 2013, 20:53:10 »

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

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

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

Статью читал позавчера, когда "вникал" в пользовательские истории

126

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

« : 19 Ноября 2013, 19:23:23 »

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

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

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

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

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

127

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 24 Августа 2013, 16:36:11 »

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

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

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

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

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

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

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

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

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

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

128

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 22 Августа 2013, 18:46:35 »

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

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

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

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

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

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

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

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

129

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 22 Августа 2013, 05:39:57 »

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

Хорошо.

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

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

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

130

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 12 Августа 2013, 04:48:46 »

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

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

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

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

131

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 12 Августа 2013, 04:12:45 »

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

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

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

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

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

132

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 08 Августа 2013, 03:07:06 »

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

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

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

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

133

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 07 Августа 2013, 16:09:25 »

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

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

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

134

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 04 Августа 2013, 04:52:29 »

Давайте таким образом порассуждаем ...

Тема про обсуждение того, что является объектом автоматизации (процесс или ) уже была: http://www.uml2.ru/forum/index.php?topic=1649
Там большинство участников, как мне показалось, склоняется к мнению, что объект автоматизации – это процесс, деятельность.
Плюс в самом конце темы приведено мнение разработчика ГОСТ, который явно говорит о том, что в ГОСТ-е имеется ввиду процесс.

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

Да, согласен.

Исходя из философских определений, для Лесоруба, его объектом деятельности будет не "процесс валки леса", а собственно сам лес на корню. Именно на него направлена его деятельность для достижения определенного результата.

Да, согласен.
Однако, замечу, что здесь вы говорите именно о деятельности лесоруба. И о том, на что направлена деятельность лесоруба. Да, для деятельности лесоруба, объектом его деятельности является лес. Ведь объект – это то, на что направлена деятельность.

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

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

Кроме этого, если смотрим в ГОСТ 34.602, видим, что в п 2.5. В разделе «Характеристики объекта автоматизации» приводят:
1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
П. 2 очень сложно применить к процессу как таковому.

Почему же..

Например:
1) Рубка леса выполняется лесорубом с 8-00 до 17-00, предусмотрен обеденный перерыв с 13-00 до 14-00, согласно должностной инструкции и т.д.
2) Рубка леса выполняется в лесу, при погоде от -5 до +25. В ненастную погоду рубка леса отменяется. Рубка леса выполняется трезвым лесорубом. Проверка здоровья лесоруба осуществляется в 7-45 медперсоналом лесозаготовительной конторы. Для рубки леса используется качественный исправный инструмент, которым является двухсторонняя пила с зубцами 1 см.

То есть процессу можно дать нормальную характеристику, так же как и статическому предмету. Даже для автоматизации это и нужно – охарактеризовать сам процесс.
И наоборот, описывать здесь характеристику самого лесоруба (если его принять за объект автоматизации): его рост, возраст, пол, длину и цвет волос – не имеет никакого смысла.


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

135

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 03 Августа 2013, 23:03:01 »

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

Когда мы говорим об автоматизации, мы говорим о нашей деятельности.
То есть наша деятельность, направленная на объект, - это автоматизация.
А автоматизировать можно только какой-то процесс.
Следовательно, объект автоматизации - это процесс.