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

×


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

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


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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 »
91
Я бы добавил user stories в раздел Требования к Системе в подраздел Требования к функциональным характеристикам.

понятно, спасибо за помощь

92
Я чувствую, следующим Вашим топиком будет "Организация N желает подешевле "написать" проект Постановления Правительства. :)
Да, тенденция такая имеется :)

Оно Вам надо?
А куда деваться?  :(

Первый совет ...
Второй ...
Спасибо за дельные советы.
Буду искать указанную информацию и ... собирать грабли.

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


93
Вы знаете эти показатели? Если да, то почему бы не написать...

Как я понимаю, надо описать целую систему, не только показатели.
Например: 1) должностные лица, подразделения участвующие в контроле, их полномочия; 2) система регистрации показателей; 3) потоки информации о контролируемых показателях: кто, когда и кому передает; 4) кто проводит анализ показателей и принимает решения о необходимых мерах; 5) процедуры контроля: регулярность и т.д.

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

Помогите разобраться с написанием этого документа.

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

Может быть у кого-нибудь образец есть?

Поиском в интернете нашел много информации по внутреннему контролю.
Но он касается только финансовой деятельности организации.

В общем подскажите, пожалуйста, направление - куда двигаться, что искать, о чем писать?

95
...
В официальное ТЗ надо вставить нечто чужеродное, что имеет тенденцию часто меняться. Зачем надо -  я обсуждать не готов, вот такая забористая дурь в команде автора. Что реально могу - ответить автору на его вопрос "куда вставить последнюю..." так, чтобы потом не было мучительно больно. ...
спасибо за понимание :)

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

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

Что думаете?

97
ОК, я все понял, спасибо

98
По 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. Требования к системе".
Есть лучший вариант?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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