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

Обсуждения => Обсуждение статей => Тема начата: SALar от 27 Февраля 2016, 11:21:47

Название: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 27 Февраля 2016, 11:21:47
http://blog.shumoos.com/archives/308

Материал готовился для аналитического онлайн-марафона «Проектные истории» http://school.system-analysis.ru/project-stories/, но не вписался по времени. В итоге после доклада все равно возник вопрос о трассировке требований разного уровня.

PS. Предвижу следующий вопрос: "Про танки просто, а вот в реальном проекте..." Коллеги, эта матрица относительно легко читается, а вот ее составление - довольно сложный процесс. Если кто-то возьмется строить такую схему на своем проекте - готов помочь.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Galogen от 27 Февраля 2016, 22:38:23
Сергей, в статье представлен результат применения модели. Какова модель трассировки?

Да и матрица обычно выглядит как-то иначе, а у тебя скорее граф, причем ориентированный.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 28 Февраля 2016, 15:18:54
Какова модель трассировки?
Вероятно, я не понимаю вопроса. Попробую ответить как понял. Это модель перехода от требования бизнеса (государства, ...) к требованиям конкретного Конструкторского Бюро. Ну, или к проектной команде.

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

То что предыдущие исследователи использовали термин "матрица" - это их проблемы.
Точно также устаревшая модель управления по риск оптимумам является частным случаем "особой причины вариаций" карт Шухарта.
RUP предложил термин матрица. Но это не соответствует практике. Давайте двигаться дальше.
"Матрица трассировки"  такая же неполная модель, как диаграмма Исикавы (Дерево Текущей Реальности гораздо полнее).

Цитировать
Был этот мир глубокой тьмой окутан.
Да будет свет! И вот явился Ньютон.

Но сатана недолго ждал реванша.
Пришел Эйнштейн - и стало все, как раньше.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Galogen от 28 Февраля 2016, 22:33:06
Вероятно, я не понимаю вопроса.
Модель трассировки - это основные сущности или элементы такой модели и типы связей (направления и их смысл).

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

Вот, что я имел в виду.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: pmle от 28 Февраля 2016, 22:40:32
сообщение устарело
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 29 Февраля 2016, 13:40:34
Например, дерево целей типично задает модель выражаемую строгим иерархическим деревом.
Голдратт полагает, что все таки двунаправленный граф. Или я его неправильно понял.

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

"Танк должен иметь возможность сопровождения мотопехоты на марше, так как он должен соответствовать теории глубокой операции."
"Танк должен иметь скорость по шоссе 40-50 км/ч, так как он должен иметь возможность сопровождения мотопехоты на марше [и скорость передвижения мотопехоты по большинству современных дорог - 40-50 км/ч]"

Замечу, что при изменении дорожной инфраструктуры более низкоуровневое требование о скорости подлежит изменению, а более высокоуровневое о сопровождении на марше не изменится.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 29 Февраля 2016, 13:43:50
Связей, наверное, должно быть больше.

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

Или связь между калибром орудия и массой.

Ну а в целом - нормальная такая трассировка. В таком (графическом) виде применима при очень небольшом количестве требований и взаимосвязей, оптимально - на уровне презентации. При детализации превращается в нечитаемую паутину.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 29 Февраля 2016, 18:07:28
Связей, наверное, должно быть больше.

Например, между удельной мощностью двигателя и дешевизной производства/обслуживания (ибо экстремально высокие значения для текущего уровня производства явно не удешевят изделия).
И связей больше и квадратиков больше.
1. Для иллюстрации подхода "правильная схема" была не нужна.
2. Для иллюстрации подхода "правильная схема" была вредна. То,  что Леонид нашел ошибку в схеме как раз и показывает, зачем она нужна. Вот если бы никто не нашел ошибки, то это означало бы, что она не нужна.

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

Для анализа нужно работать с полной схемой. И проблема тут не в том, что она нечитаема. Читаема, просто времени нужно несколько больше.
Проблема в отрицательной обратной связи в нашей индустрии. За нахождение ошибок в таких схемах "тестировщику" создавали неприемлемые условия и он уходил. Теперь никто такие схемы не анализирует.
Итог: "Даже если вам повезет, и среди тысячи сотрудников вашей фирмы найдется кто-то, способный такую схему нарисовать, то прочитать ее будет некому. Второго сотрудника такой квалификации ваша фирма себе позволить не может." Если нужен пример, он есть у меня. Фирма 5000+ сотрудников.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: pmle от 29 Февраля 2016, 18:45:06
сообщение устарело
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 29 Февраля 2016, 23:27:50
… Поэтому не вижу никакой проблемы кроме наличия под рукой, как тут правильно написали, соответствующего инструмента .…
Кто писал про соответствующий инструмент, коллеги? Я не вижу что-то.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 29 Февраля 2016, 23:40:01
И да, рисовать ориентированный граф и писать, что он неориентированный, как-то не очень хорошо :-)
Сергей этого не говорил.
У него было 2 утверждения:
1.  "Я нарисовал матрицу трассировок."
2.  "Трассировка требований - это очевидно граф. Причем неориентированный."
"Я нарисовал неориентированный граф" — он не говорил.
Граф у него получился ориентированный граф лишь потому, что Flying Logic не даёт создавать других. Так что стрелками можно пренебречь.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 29 Февраля 2016, 23:44:50
И я скажу еще больше: те, кто грамотно используют IDEF0 имеют даже лучшую трассировку, чем та, что нарисована на Вашей схеме и как-то проблем с чтением IDEF0 чаще всего не возникает у людей самой разной специализации.
А по сведениям организационных консультантов, которые работают с собственниками и руководителями малого и среднего бизнеса — вполне так себе возникают: http://www.mrybakov.ru/order/business/business_processes/more_info/index.php?sphrase_id=81681

Собственники и руководители — не самая последняя аудитория, на которую стоит ориентироваться, не правда ли?
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Humbert от 01 Марта 2016, 00:23:01
У организационных консультантов, которые работают с собственниками и руководителями малого и среднего бизнеса основная проблема в том, что собственники и руководители малого и среднего бизнеса не особо то с ними и работают.

В принципе. А не потому, что они пользуются или не пользуются какой-то там нотацией
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 01 Марта 2016, 00:26:32
А при чём тут проблемы консультантов?

Речь была о применимости IDEF0 моделей.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Humbert от 01 Марта 2016, 00:47:55
Я о том, что ко мнению оргконсультантов в части неприменимости IDEF0 надо относится крайне осторожно. Если обычные бизнес-аналитики еще выполняют техническую функцию посредника между бизнесом и IT , то у  оргконсультантов вообще чистая политика. Им просто не до нотаций...

Если брать мое мнение, то IDEF0 вполне может вернуться. Сейчас его практически вытеснил BPMN.  BPMN  отличная нотация и для as is, и для to be, и прототипирование на BPMS возможно, но в качестве нотации для выявления и фиксации функциональных и нефункциональных требований не подходит так, как IDEF0.

С другой стороны вклинивание  IDEF0 между описанием БП as is в BPMN и моделированием поведения системы в UML - это серьезное усложнение технологии.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: pmle от 01 Марта 2016, 11:20:07
сообщение устарело
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 01 Марта 2016, 11:23:47
Цитирую:
"В таком (графическом) виде применима при очень небольшом количестве требований и взаимосвязей, оптимально - на уровне презентации. При детализации превращается в нечитаемую паутину."
"Для анализа нужно работать с полной схемой. "

Денис, Вы предлагаете людям работать с полной схемой на ватмане?
Естественно, для работы с трассировкой нужен нормальный инструмент, потому что связей много и нужно работать со срезами - фильтрами, представлениями, чтобы иметь возможность провести качественный анализ. "Рисовать" каждое представление отдельно просто не реально. Эти представления должны генерироваться автоматически.
Я ничего не предлагаю. У вас какие-то галлюцинации. Я лишь спрашивал, где было упоминание необходимости инструментов. Нигде выше упоминания не было.

Учите матчасть.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 01 Марта 2016, 11:25:15
1. Сергей НЕ рисовал матрицу трассировки. Денис, Вы не в состоянии отличить граф от матрицы?
Перечитайте ещё раз, что я написал. Я не говорил, что он нарисовал. Я говорил, что он сказал, что нарисовал.

Учите матчасть.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 01 Марта 2016, 11:28:30
3. "Так что стрелками можно пренебречь."
Учите матчасть, там так пытают :-)  Вас не смущают стрелки на всех матрицах трассировки во всех известных инструментах?
У Сергея похоже есть тезис про то, что трассировки всегда двусторонние. Я подожду, пока он сам раскроет.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 01 Марта 2016, 11:30:34
В общем желание встать плечом за друга защитывается. Знание теории и практики трассировки требований - нет.
Я лишь пользовался анализом текста и логикой высказываний. Их достаточно, чтобы понять, что вы утверждаете то, чего не было.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 01 Марта 2016, 11:34:24
Насчет того, что IDEF0 устарел или там его вытеснили - это все сказки.
Никто этого не утверждал (по крайней мере тут и пока), я ссылался на то, что с ним трудно работать, он требует специальных знаний.

Хватит перевирать.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 01 Марта 2016, 12:35:31
На уровне слайда такую схему хорошо делать, если вы собираетесь кому-то что-то втюхать. Ибо для "улучшения" восприятия, вы уберете все неприятные моменты.

Да, если цель втюхать. Или нет, если цель противоположная - попытаться отговорить от опрометчивого шага.

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

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

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

Проблема в отрицательной обратной связи в нашей индустрии. За нахождение ошибок в таких схемах "тестировщику" создавали неприемлемые условия и он уходил. Теперь никто такие схемы не анализирует.

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

Итог: "Даже если вам повезет, и среди тысячи сотрудников вашей фирмы найдется кто-то, способный такую схему нарисовать, то прочитать ее будет некому.

Так точно. Ибо никто не хочет не только читать, но и системно заставлять читать других.

Второго сотрудника такой квалификации ваша фирма себе позволить не может." Если нужен пример, он есть у меня. Фирма 5000+ сотрудников.

Да тут даже квалификация не особо важна. Для работы с подобными схемами в качестве исполнителя нужна хорошая попа. Неплохие результаты дает поиск нужных людей среди вчерашних девочек-отличниц. Недорого и достаточно эффективно.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Humbert от 01 Марта 2016, 22:43:15
Сравнивать BPMN c точки зрения трассировки требований IDEF0 бесмысленно. Одна из ключевых задач трассировки - это трассировка нефункциональных требований к функциональном, у BPMN, насколько я знаю, просто нет выразительных средств для этого, в то время как для IDEF0 это просто "нативное" состояние.

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

Безусловно BPMN не является средством конфигурационного управления, как IDEF0. Тем не менее ровно настолько BPMN является процессной нотацией и позволяет зафиксировать в процессе контекст взаимодействия пользователя с системой, настолько мы можем осуществить трассировку.

И IDEF0 и BPMN требуют зафиксировать границы процесса и цель моделирования. Управление viewpoint в BPMN не такое явное, как в IDEF0, но тем не менее свои критерии детализации описания тоже присутствуют.

Для каждой activity на BPMN диаграмме можно указать исполнителя, для процесса целиком желательно выделить его владельца. На схемке во вложении мы зафисировали активность , ассоциированную с Системой.

Смысл стрелок в BPMN и IDEF0 разный (в BPMN это поток управления, а в IDEF все определяется тем , куда пришла стрелка). То , для чего в IDEF0 отведено три типа входящих стрелок и один исходящий в BPMN отражается только направленной и ненаправленной ассоциацией.

Тем не менее связь системы как с активностью, ее ассоциациями, так и с процессом в целом устанавливается. А если есть связь, значит возможна и  трассировка. 

Несомненным преимуществом IDEF0 является жесткость декомпозиции. Все связи декомпозируемого процесса необходимо пробросить вниз (или наоборот вытащить наверх из декомпозиции) или осуществить туннелирование.
Естественно BPMN не заставляет так строго работать с ассоциативными связями - декомпозиция осуществляется только относительно потока управления.

Поэтому как только мы зафиксировали факт взаимодействия с системой в BPMN мы тут же вынуждены менять нотацию и само это взаимодействие описывать через use case или другими видами поведенческих диаграмм.

В IDEF0 необходимости менять нотацию нет .

В общем то это и определяет применимость нотаций: нужна глубокая декомпозиция - используем IDEF0, нужны события, оркестровки , хореографии или интуитивно понятное отображение БП - тогда BPMN. Но и ту, и другую нотацию можно использовать для трассировки.

Вышесказанное является моей сугубо личной точкой зрения, ни на научность подхода, ни на методологическую чистоту не претендую :)
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Григорий Печенкин от 01 Марта 2016, 23:14:43
Я таки прошу посторонних вещей в форуме не писать под угрозой расстрела всякого товарища с лишением прав.

Пожалуйста, не переходите на личности и не опускайтесь до оскорблений.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 02 Марта 2016, 12:07:15
Григорий, Humbert, Леонид, спасибо за конструктивное обсуждение.

Некий итог.
1. Я кажется понял, где мы с Григорием разошлись в терминологии. Я имел ввиду, что зависимости могут быть и в другую сторону. И тогда возможно появление петель положительной обратной связи.
2. Данная диаграмма призвана ответить на вопрос "Why" (почему, зачем), причем, скорее, "Почему". В этом смысле она не конкурирует за место под солнцем с диаграммами отвечающими на вопрос "Как".
3. Теоретически она полезна.
4. Практическое ее применение сильно ограничено причинами, указанными Humbert и Леонидом. Даже не знаю чьи формулировки мне нравятся больше.

Есть ли от нее польза. Да есть. С помощью нее можно демонстрировать студентам зависимость изменчивости требований от их уровня.  Предупредить их:
1. Если вы вынуждены использовать ТЗ как контракт, то постарайтесь не писать туда требования третьего уровня. Пишите второго уровня и как можно более высокого. Кстати. Показывать это ТЗ программистам совершенно необязательно.
2. Для программистов лучше писать на третьем уровне.

PS. Другие диаграммы предлагаю обсуждать в других ветках.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 02 Марта 2016, 12:46:34
1. Если вы вынуждены использовать ТЗ как контракт, то постарайтесь не писать туда требования третьего уровня. Пишите второго уровня и как можно более высокого. Кстати. Показывать это ТЗ программистам совершенно необязательно.
2. Для программистов лучше писать на третьем уровне.

Об этом же, кстати, ГОСТ 34.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 02 Марта 2016, 15:16:54
Об этом же, кстати, ГОСТ 34.
А вот это предлагаю внести в методические рекомендации по использованию ГОСТ от <придумайте от кого>:

Не рекомендуется включать ВИ в ТЗ по ГОСТ 34. ... и 19. ...
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 02 Марта 2016, 15:39:07
А вот это предлагаю внести в методические рекомендации по использованию ГОСТ от <придумайте от кого>:

Да вроде нет у нас таких. Была тема, в которой собирались сформировать ЧАВО, да так и не собрались, помнится.

Не рекомендуется включать ВИ в ТЗ по ГОСТ 34. ... и 19. ...

Совершенно верно. Неоднократно в разных темах обсуждалось.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Григорий Печенкин от 02 Марта 2016, 15:54:42
Да вроде нет у нас таких. Была тема, в которой собирались сформировать ЧАВО, да так и не собрались, помнится.

Однако у меня все ходы записаны. :) Вопросы есть, ответов только нет.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: ekaterinalog от 03 Марта 2016, 08:46:17
Есть ли от нее польза. Да есть. С помощью нее можно демонстрировать студентам зависимость изменчивости требований от их уровня.  Предупредить их:
1. Если вы вынуждены использовать ТЗ как контракт, то постарайтесь не писать туда требования третьего уровня. Пишите второго уровня и как можно более высокого. Кстати. Показывать это ТЗ программистам совершенно необязательно.
2. Для программистов лучше писать на третьем уровне.
Добрый день. Слушала ваш доклад на аналитическом фестивале, и вот какой вопрос меня беспокоит. Вы настоятельно не рекомендуете писать требования третьего уровня в ТЗ. если оно идет приложением к Договору с Заказчиком. При этом почему вы не рассматриваете ТЗ как инструмент сдерживания "буйной фантазии" заказчика? Конечно, ТЗ не должно становится дубиной, при помощи которой за шаг влево или шаг в право расстрел. Должна быть возможность обсуждать требования, вносить изменения в соответствии с изменениями требований, но на взаимовыгодных условиях. Но всегда есть риск. что заказчику захочется большего, а формулировка второго уровня вполне позволяет это большее подогнать под требование.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 03 Марта 2016, 09:11:41
Если уж беретесь о чем-то рассказывать на широкую аудиторию, хоть разберитесь в теме, вы же не студенты - позиционируете себя, как профессионалы, преподающие другим. Вас же читают подрастающие поколения, должна быть ответственность за качество информации, которую вы выдаете и пример, который показываете.
Поскольку я подвёргся цензуре, повторю в социально приемлемой форме:

Засуньте свои непрошеные советы подальше.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 03 Марта 2016, 12:20:50
При этом почему вы не рассматриваете ТЗ как инструмент сдерживания "буйной фантазии" заказчика? 
Это имеет смысл, если нет более простых способов сдерживания буйной фантазии. Но эта тема за пределами доклада.


Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 03 Марта 2016, 12:21:54
Ссылка на доклад: https://www.youtube.com/watch?v=zVtTrXcHH2M
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 03 Марта 2016, 13:04:12
Однако у меня все ходы записаны. :) Вопросы есть, ответов только нет.

Ну, тогда на правах свирепого оффтопа... (может, перенесет кто куда надо?)

1. Является ли ГОСТ методологией разработки?

Зависит от того, как определить "методологию". Мое мнение - да, является. Рамочной. Поскольку определяет:
1. Что должно быть сделано.
2. В какой последовательности.
3. Как должно сдаваться.
4. Как должны выстраиваться формальные отношения между сторонами разработки.

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

2. Когда следует применять ГОСТ 34?
Когда:
а) это прямо предписано контрактом,
б) нужно подстелить соломки ввиду невнятных перспектив проекта,
в) умеете это делать,
г) в иных случаях.

3. Когда не следует применять ГОСТ 34

В целом - не следует, когда без него получается лучше, чем с ним.

Например, относительным противопоказанием применения ГОСТ 34 являются проекты итерационного характера. Но не все, а те, для которых характерно появление совершенно новых требований от итерации к итерации (не то, что нельзя, а просто сильно неудобно).

4. В каких случаях ГОСТ 34 обязателен к исполнению?

См. п.2.а.
Также он становится обязательным, если в документе уровня ТЗ прописали нечто вроде "документы должны быть разработаны с применением ГОСТ 34".

5. На каких этапах жизненного цикла разрабатываются требования по ГОСТ 34?

О каких именно требованиях идет речь? Если в широкой трактовке, то на всех.

С 1 по 6 стадии по ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ" - достаточно очевидно.
http://rugost.com/index.php?option=com_content&view=article&id=95:gost-34-601-90-avtomatizirovannye-sistemy-stadii-sozdaniya&catid=22&Itemid=53 (http://rugost.com/index.php?option=com_content&view=article&id=95:gost-34-601-90-avtomatizirovannye-sistemy-stadii-sozdaniya&catid=22&Itemid=53)

На 7 стадии:
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний,
могут возникнуть требования, которые необходимо реализовать в системе или документации для ее приемки.

На последней стадии "Сопровождение АС" появляются требования на последующее развитие.

6. В каких документах по ГОСТ 34 содержатся требования?

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

Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: SALar от 03 Марта 2016, 13:12:42
Полагаю обсуждение содержательной части более - менее закончено. Можно перейти к оформительской части.

-- Построение ------------------------------------------
Как и Леонид я часто строю такие схемы в голове.
При повышенной сложности - стикеры или тетрадь в клетку А4.
Изредка доску или флипчарт.

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

Что касается пользы от специализированных инструментов, то она сомнительна. Продавцы гербалайфа пакета Rational много лет утверждали, что только покупка их продуктов сделает ваши волосы длинными и шелковистыми проекты успешными. Типа, если аналитик не использует Rational Rose, то он и не аналитик вовсе. "Господа, его вообще сюда пустил?".

По этой теме у Григория есть несколько отличных статей:
"Убийцы времени" https://www.greesha.ru/articles/%D1%83%D0%B1%D0%B8%D0%B9%D1%86%D1%8B-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8/
"Простые инструменты" https://www.greesha.ru/articles/%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%8B%D0%B5-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B/
И особенно: "Семь смертных грехов аналитика. Gula" https://www.greesha.ru/livejournal/%D1%81%D0%B5%D0%BC%D1%8C-%D1%81%D0%BC%D0%B5%D1%80%D1%82%D0%BD%D1%8B%D1%85-%D0%B3%D1%80%D0%B5%D1%85%D0%BE%D0%B2-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0-gula/


-- Презентация ------------------------------------------
Что касается совместного обсуждения большой диаграммы (100+ элементов 200+ связей).
* Лист ватмана.
* Напечатать множество листов и склеить в лист А2 - А0, если нет большого принтера.
* Возможно, когда нибудь в переговорке станет нормой монитор (телевизор) 60+ дюймов, с сенсорным экраном, развернутый вертикально.

Есть еще неплохой вариант продемонстрированный Эли Шрагенхаймом в книге "Управленческие дилеммы"

-- Сложности восприятия ------------------------------------------
Дюжину лет назад тестировщики моего отдела достаточно свободно работали со схемой БД склеенной из 20 листов А4. Это примерно 150-200 таблиц. Про программистов и говорить нечего. Они ее читали "на лету".

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.
Я прочитал это так: "Для меня, Леонида, работа с такими диаграммами не представляет труда, для программистов представляет."

Не хочу говорить, что "народец измельчал", все сложнее. Но я тоже заметил, за последние десяток лет восприятие больших диаграмм ухудшилось.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 03 Марта 2016, 13:45:57
7. Какие документы ГОСТ 34 являются самыми важными?

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

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

8. Какие документы из ГОСТ 34 являются самыми полезными?

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

9. Что нужно изучить, прежде чем браться за разработку ТЗ по ГОСТ 34?

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

10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

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

11. Обязательно ли заполнять все разделы ТЗ, перечисленные  в ГОСТ 34?

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

12. Какие ошибки чаще всего совершают аналитики, использующие ГОСТ 34?

Я в растерянности. Меня только что попросили рассказать самые смешные анекдоты, которые я знаю. А в голову ничего не идет, хоть тресни.

Ну, например, из любимого. Каждый второй путается с "объектом автоматизации". Немудрено, поскольку явного определения, что это такое, ГОСТ 34 не содержит. Отсюда у многих получается, что объект автоматизации - это процессы, которые надлежит автоматизировать.
Однако, если посмотреть внимательнее, можно заметить:
а) в том же ТЗ "3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;"
б) в Пояснительной записке "7) решения по комплексу технических средств, его размещению на объекте;" или "4) мероприятия по изменению объекта автоматизации;"
в) в Общем описании системы "4) описание взаимосвязей АС с подразделениями объекта автоматизации."

Помятую о том, что АС - это не только ПО, но также и ИТ-инфраструктура, которая должна быть где-то развернута, и люди, которые должны быть где-то рассажены, напрашивается единственный вывод:

Объект автоматизации - это ГДЕ происходит автоматизация.

Чаще всего объект автоматизации представляют в одном из двух вариантов (или их комбинацией):
а) Перечень орг.подразделений заказчика: "в подразделениях, ведущих архивную работу"
б) Перечень адресов: "в здании Мособл... по адресу г.Москва, ул...,"


Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 03 Марта 2016, 13:56:05
Что касается пользы от специализированных инструментов, то она сомнительна.

Аминь.

Дюжину лет назад тестировщики моего отдела достаточно свободно работали со схемой БД склеенной из 20 листов А4. Это примерно 150-200 таблиц. Про программистов и говорить нечего. Они ее читали "на лету".

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

Я прочитал это так: "Для меня, Леонида, работа с такими диаграммами не представляет труда, для программистов представляет."

Правильнее будет "не представляет сложности, требует только заметного количества труда"

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

Как и больших документов.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Galogen от 03 Марта 2016, 16:50:24
Что касается пользы от специализированных инструментов, то она сомнительна. Продавцы гербалайфа пакета Rational много лет утверждали, что только покупка их продуктов сделает ваши волосы длинными и шелковистыми проекты успешными. Типа, если аналитик не использует Rational Rose, то он и не аналитик вовсе. "Господа, его вообще сюда пустил?".

Ну я бы не бы столь категоричен. Эпоха системного анализа началась исключительно благодаря развитию компьютерных систем и технологий. Rational и им подобные штуки делают упор на визуальные модели. Возможно в этом их промах.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Григорий Печенкин от 03 Марта 2016, 20:12:34
10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

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


Коротко она пересказывается, например, здесь: http://foranalysts.blogspot.ru/2011/08/blog-post_17.html
Картинка в статье - из книги Вигерса "Разработка требований к программному обеспечению".
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Humbert от 04 Марта 2016, 09:08:49

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

Правильно делают, что не читают. Вместе с тем 200+ элементов - это фактически учебная задача. ER простенькой системы  - это 500-700 сущностей, более-менее детальное описание логистического процесса 500 и более активностей. В САП около 100 000 таблиц
 
Больших слонов едят по частям - сделать что-то полезное с таким количеством элементов и их связей человек с нормальной психикой просто не в состоянии. Поэтому у аналитика и есть инструментарий с репозитарием , который позволяет работать не со всей моделей на ватмане, а с отдельной проекцией, помещая в фокус именно ту часть модели, которая необходима для принятия решения.
 

Цитировать
Да тут даже квалификация не особо важна. Для работы с подобными схемами в качестве исполнителя нужна хорошая попа. Неплохие результаты дает поиск нужных людей среди вчерашних девочек-отличниц. Недорого и достаточно эффективно.

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

Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 04 Марта 2016, 12:11:54
Коротко она пересказывается, например, здесь: http://foranalysts.blogspot.ru/2011/08/blog-post_17.html
Картинка в статье - из книги Вигерса "Разработка требований к программному обеспечению".

Значит, будем плясать от этой ссылки.

10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

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

* Отчеты обычно не содержат требующих формулировок, но являются источником требований. Это когда их делают, что бывает относительно нечасто.

Что касается ТЗ, то хоть п.1.4 ГОСТ 34.602 провозглашает "Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений", но как правило, искать решения нужно в отведенных границах. Или вокруг неких констант, забитых гвоздями низкоуровневых требований. Например, если одна из основных задач создаваемой системы - служить источников данных для другой системы, которая умеет переваривать только csv-файлы, то самые замечательные и современные xml-технологии будут неактуальны.

В целом, в предпроектной документации акцент смещен в сторону высокоуровневых требований.

б) Проектная документация.
А в проектной наоборот: хоть она и касается высокоуровневых требований и задач, основной акцент делается на том, КАК (за счет каких своих свойств) разрабатываемая система будет их выполнять, и что для этого потребуется.

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

Безотносительно артефактов. В ГОСТе довольно большое внимание уделяется организации нужной для функционирования системы инфраструктуры, а этого я в вигерс-лайк документах не видел (с другой стороны, я их видел немного). Начиная с ТЗ (далее техпроект, далее рабочая документация) прямо прописывается, что техника должна быть установлена, данные должны быть смигрированы, люди должны соответствовать таки-то требованиям и должны выполнять свои задачи определенным образом, рабочие процессы организованы. С Вигерсом тут, насколько я понимаю, общего мало.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 04 Марта 2016, 12:13:50
Артефакты ГОСТ 34 соотносятся с артефактами Вигерса приблизительно так же, как соотносятся АС и ПО.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 04 Марта 2016, 12:18:09
Правильно делают, что не читают. Вместе с тем 200+ элементов - это фактически учебная задача. ...
 
Больших слонов едят по частям - сделать что-то полезное с таким количеством элементов и их связей человек с нормальной психикой просто не в состоянии.

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

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

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

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

Ничего не имею против осознанности. А вот попа все-таки нужна. Без попы нет усидчивости, а без усидчивости никакая осознанность не поможет съесть кусок слона на 200+ элементов.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 04 Марта 2016, 12:33:50
Артефакты ГОСТ 34 соотносятся с артефактами Вигерса приблизительно так же, как соотносятся АС и ПО.

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

Дисклеймер: вывод о вигерсовом подходе сделан на основании предоставленный выше ссылки и может не соответствовать фактическому положению вещей.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 04 Марта 2016, 13:00:29
Артефакты же ГОСТа перпендикулярны вигерсовским, поскольку ГОСТ иначе смотрит на предстоящие работы, применяет другую классификацию и, как следствие,  рекомендует иную расстановку акцентов.
Можно попунктно сравнить состав ГОСТ 19.201-78, IEEE 830-1998 и SRS Вигерса чтобы увидеть, что разница между ними чисто эволюционная, а не "перпендикулярная", что бы это ни значило.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 04 Марта 2016, 13:19:23
Можно попунктно сравнить состав ГОСТ 19.201-78, IEEE 830-1998 и SRS Вигерса чтобы увидеть, что разница между ними чисто эволюционная, а не "перпендикулярная", что бы это ни значило.

Было бы неплохо. Только почему 19-й, когда мы про 34-й?
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Denis Beskov от 04 Марта 2016, 13:21:36
Потому что вы писали "Артефакты же ГОСТа перпендикулярны вигерсовским, поскольку ГОСТ иначе смотрит на ".

Ну вот я и говорю, какой именно ГОСТ соотносить.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: Леонид от 04 Марта 2016, 13:41:48
Потому что вы писали "Артефакты же ГОСТа перпендикулярны вигерсовским, поскольку ГОСТ иначе смотрит на ".

Ну вот я и говорю, какой именно ГОСТ соотносить.

Про 19-й не скажу, очень редко приходится использовать. И таки да, поскольку он про ПО, к Вигерсу должен быть ближе. Но я отвечал на вопросы по 34-му.
Название: Re: Статья "Трассировка требований разных уровней"
Отправлено: log от 05 Марта 2016, 17:31:50
Столько умных и полезных мыслей.
А чем не тема для нового Аналитический онлайн-марафон «34 Гост практика использования и подводные камни »
Думаю интересно может получится.