Обсуждение

обеспечиваемые специальным типом учетных систем -- IT-системами управления требований (DOORS, CaliberRM, IRQA, MKS Integrity, Rational RequisitePro и т.д.). DOORS - монструозная система с совершенно дурацким языком создания расширений. К тому же стоит дико. CaliberRM - достаточно ограниченная система IRQA - хороша и включает много чего, для DOORS доступного за очень отдельные деньги, но доля на рынке на порядок меньше чему у DOORS. Rational RequisitePro - эту я б вообще не советовал. Какое-то распространение есть только потому, что изделие входит в пакет Rational Suite. Не зря Rational купил Telelogic (производителя DOORS). У Telelogic новая маркетинговая фишка. V-Модель они переделали в W-Модель. (Та же фигня, но больше умных слов. Вот презентация вот статья http://www.manageware.co.il/downloads/RequirementsDrivenTesting.pdf Читать его будущим специалистам по управлению требованиями невозможно, ибо этот стандарт сделан программистами для программистов. Практически все стандарты создаются не для инженеров, а для производителей тулов. Инженеры книжек не читают, не то что стандарты. А, в принципе, важна человеческая дисциплина. Правильно структурированные и использующие стандартную грамматику и язык требования можно поднять и из "наиболее распространённого RE тула" Word+Excel. Хаос, запихнутый в самый передовой тул, будет хаосом помноженным на непонимание логики софта и поддерживаемых ей процессов. Ладно, не буду о грустном. Мне ещё два дня на крайний пример этого случая лбоваться.

Насчёт же доказательств, думаю будет то же, что с языками формальных спецификаций типа Z. То есть применят на паре мелких проектов в полунаучной области и забудут. Отдел QA смотрит на наличие требуемых разделов в бумажке и не лезет в то, что внутрях написано.

Я примерно так же и думаю про все эти системы. W-модель бьет в странную точку: с одной стороны, они говорят банальности, а с другой стороны, основной упор при проверках делается на требования ilities (формулируемые как "чтобы все у вас тут не развалилось и было зашибись 24 часа в сутки"), а их не оттестируешь и не оттрассируешь, их нужно как-то доказывать. Человеческая дисциплина важна, конечно. Меня сейчас очень интересует human-system integration в случае enterprise engineering (известная также в этой сфере под многими другими именами -- "постановка процессов", "управление изменениями" которое совсем не имеет отношения к configuration management, "управление знаниями", "обеспечение организационной зрелости" и т.д.). Интересно, что вы сами считаете "правильно структурированными" требованиями, которые вы отовсюду "поднимаете" и в какой-то форме затем складируете. Ну, и к чему вы (и какими отношениями) затем эти требования привязываете, в каких процессах (user stories) они потом используются.

Отделы бывают не только QA ("свои"), но и надзорные. Так, при производстве атомных станций и их лицензировании нужно читать присланное и проверять расчеты. Люди говорят, что иногда "надзор" смотрит на содержание разделов и только, а иногда и вправду проверяет. И я почему-то не думаю, что тут речь идет о языке формальных спецификаций. Это не более, чем "графы в документе", ибо совершенно сознательно говорится про "убеждение других людей" (прямые аналогии с "судебным делом", материалами для состязательного процесса судебного доказательства), а не про машинные доказательства и формальную семантику.

В формализации две проблемы: 1. Чем больше инструкций, тем меньшее количиество людей ими владеют. В результате в конце концов появляются мастера инструкций, которые нифига не понимают в предмете, но командуют инженерам где какую закорючку ставить. Причём, это вопреки здравому смыслу, качеству конечного продукта и экономической целесообразности 2. Чем больше формализации, тем более модульными получаются требования просто из-за объёма. И проверка идёт не системно, а мелких деталей. По той простой причине, что деревьям уделяется столько внимания, что леса обнаружить просто невозможно. В знаменитом случае с Ариан 5 именно на этом и пролетела жесточайшая система контроля качества.

W-модель - это маркетинговый инструмент продвижения дополнительных тулов. Но поразительно то, что для многих банальности эти являются откровениями свыше. Человеческая дисциплина не важна, она критична. Потому я всё больше склоняюсь к мнению строить процессы вокруг людей, а не пытаться ввести что-то замечательное, что будет неправильно интерпретировано, я уж не говорю о саботаже. Очень мало людей готовы читать книжки. Ещё меньше готовы их понимать. Про структурированность требований можно говорить долго. Минимально это должно быть: 1. Единый полный и непротиворечивый словарь 2. Единая грамматика в смысле структуры построения фраз. 3. Однозначность (по крайней мере стремление к ней) 4. Выводимость однозначных в рамках проекта идентификаторов 5. Выводимость однозначных связей Обычно я превращаю документ в ХML, потом пытаюсь перевести его в DSL (в смысле специфичного для для проекта XML с максимально возможным превращением свободного текста в XML теги) Потом всё это можно обработать в XSLT скриптами в то, что нужно. Хоть в полуфабрикаты для импорта в DOORS, хоть в статистику, хоть в отчёты, хоть в HTML (можно и в форматы OpenOffice, MS Office, XMI или RIF, правда это достаточно муторное дело из-за их громоздкости.) По сути дела XSLT - дальний потомок Лиспа, так что можно сделать достаточно много. Например Use Cases написанные в plan text, переводятся в XML, потом генерятся диаграммы по шагам. Диаграммы преводятся в приличный вид передвижением прямоугольничков, распечатываются и вешаются на стену. Потом на тот этап, который не функционирует, прикалывается жёлтый или красный пин. Всё. Готова простая и наглядная таблица оценки качества для всей системы.

Первое -- это появление формальных "юристов" вместо содержательных правоведов. Забота о форме с полной утерей мысли о содержании начальной интенции. Совершенно согласен. Когда-то Гена Лебедев заметил, что для того, чтобы законы выполнялись, нужно ограничить их общий объем 1Мб текста: хочешь новый закон вписать, сократи какие-нибудь предыдущие. Может, нужно что-то похожее делать с требованиями: повышать уровень языка, или еще что-то. Ибо если их писать, как "законы" (заодно сознательно уторговывая между стейкхолдерами двусмысленные формулировки), то результат известен: "требование что дышло, куда повернешь, туда и вышло". Второе -- так, вроде, assurance case именно для этого предназначены: попытаться хоть как-то обратить внимание на высокоуровневые требования. Но в этом есть огромная теоретическая проблема: "arguments" оказываются пропущеными и выбираются произвольно -- и в конечном итоге все оказывается непроверяемо и нерешаемо. Интересно, что было довольно много дебатов, как устроить проверку "верхнеуровневых" требований, проверку леса, оставляющую проверку деревьев глубоко внизу. И пришли к выводу, что другие методы, кроме assurance case не работают. Но мне кажется, что формализация в assurance case сильно преувеличена. Не более, чем формализация "дела" в обычном суде (где, по слухам, юристов профессионально логике учат -- только толку от этого в итоге немного). Ну, а дальше тоже как в суде: не пойман на нарушении требований -- не виноват. Т.е нужно не столько не нарушать, сколько не быть пойманным. Глобальный ответ на все это известен: вместо "требований-допусков" переход на процессы, проверяется не соблюдение требований к результату, сколько культура производства, дающая повод надеяться на соблюдение требований результата. Так что в консерватории с управлением требованиями нужно сильно подкручивать, выяснять, что же такое "требование" и чем оно отличается от произвольной "хотелки".

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

Компактность словаря -- это одно, а компактность всего набора текстов -- совсем уже другое. Два независимых параметра. Говорится, что при некомпактном словаре тексты не будут пониматься, а про некомпактном самом тексте не будут выполняться при полной понятности. Компактность не менее важна, чем все эти трассируемости. Assurance case не имеет отношения к компактности. Мне кажется, что там решается как раз задача леса и деревьев -- уж как умеют. Берут лучший опыт: как в суде миллионы каких-то улик и алиби складываются чудесным образом в одно "виновен" или "не виновен". Мне кажется, что assurance case больше имеет отношение к трассируемости для требований-лесов, нежели для требований-деревьев. Сертификация процессов меня сейчас волнует только с одной точки зрения: оказывается, что сертификация накладывает требования на способ описания процесса. И это интересно. Кроме того, есть разные виды сертификации, и лучше бы говорить об оценке, нежели "сертификации". Но это другая оценка, нежели оценка требований (так, оценка требований -- ISO 15026, а оценка процессов -- 15504). Оценка процессов связана с их жизненным циклом, когда процессы идут по уровням действенности. Я вот только что в частной переписке предложил process capability переводить как действенность процесса. У меня сейчас ход на то, что ежели сделать понятное людям описание процессов (требований, чего угодно), то шанс на понимание и выполнение будет сильно больше. Но "понятное" часто означает замену слов в якобы "общепринятых" переводах. Мы в PraxOS при переводе существенно меняем лексику. Думаю, что "обратный перевод" на английский через некоторое время может быть даже интересен англоязычным коллегам :)

Процессы, конечно, нужно ставить -- строить их вокруг людей, учитывая возможности обычного работника, а не супермена. Насчет чтения книжек или их понимания, это одно. Насчет дисциплины -- это другое. Достаточно поглядеть на разницу между российскими и многими (не всеми, конечно) западными предприятиями. Так что тут много можно обсуждать: уместность процесса, его понятность и краткость описания, потребность в обучении и переделке сознания, мотивация для следования процессу, общая культура (человек может вообще не понимать, что речь идет о "процессе"). Про структурированность требований я понял так, что вы ориентируетесь на парсинг текстов на (возможно, псевдо)естественном языке. А мне интересно, во что это в конечном итоге парсится (хотя подозреваю, что в ad hoc структуру для каждого отдельного проекта). Ибо когда уже распарсено, то можно делать что угодно. Мы говорим тут про датацентрическую учетную систему (система учета состояния требований), а все эти ваши "хоть отчеты, хоть в HTML" называем "выписками". Вы говорите, что требования храните в какой-то XML-базе, а выписки делаете с использованием XSLT в качестве "генератора отчетов". Понятно. Мне непонятно, как вы придумываете DSL (меня тут интересует не столько синтаксис -- это XML, тут все понятно, сколько семантика), специфичный для проекта. И как потом обучаете пользователей следовать этой семантике, когда они пишут plain text (который тем самым представляет собой альтернативное XML представление для того же самого DSL). Меня мало интересует наличие одного языка с пятком представлений (графическим, текстовым, табличным, XML и т.д.). Меня больше интересует, откуда берется семантика для этих языков, и что потом делается. Так, с вашими use cases непонятно, почему бы сразу не распечатывать plain text и не пинить те абзацы, где что-то не работает (или распечатывать каждый день новый текст, делая розовый фон для тех абзацев, где проблемы). Тут есть еще один момент: откуда мы знаем, как шаги use case стали вдруг требованиями. Чертеж/спецификация это ведь одно, а требования -- это часто другое. Может, мы говорим о разном?

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

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

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

Ну, вы говорите, что из моего списка неприменимости "лучшего опыта" первый пункт самый главный: все это не столько "лучший опыт", сколько маркетинг и реклама, а сама суть может быть даже вредна. Лекарства, которые одно лечат, другое калечат, а то и вовсе плацебо с вредными побочными эффектами. А вот насчет комиксов вам, наверное интересно поглядеть будет: http://thecroaker.livejournal.com/574834.html ;) Я давно о таком мечтаю, не о технических писателях, а о технических мультипликаторах.

Кстати, про "лучшие практики" мы уже писали вот тут: http://praxos.ru/index.php/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BC%D0%BE%D0%B4%D1%8B_%D0%B8_%D0%BF%D0%BE%D0%B2%D0%B5%D1%82%D1%80%D0%B8%D1%8F и еще немного вот тут: http://praxos.ru/index.php/%D0%A1%D0%B2%D0%B0%D0%BB%D0%BA%D0%B0_%D0%BE%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D1%85_%D0%BC%D0%BE%D0%B4_%D0%B8_%D0%BF%D0%BE%D0%B2%D0%B5%D1%82%D1%80%D0%B8%D0%B9 Это и есть наш главный проект (PraxOS), только до нормального ведения вебсайта руки не доходят -- проще черкнуть пару страниц у себя в блоге, нежели вписать кусочек информации в гипертекст вебсайта. Сапожники без сапог :)

Достаточно поглядеть на разницу между российскими и многими (не всеми, конечно) западными предприятиями. У меня подозрения, что сказки о западных предприятиях несколько преувеличены. По крайней мере у большинства корпораций, с которыми я имел дело, внутри тоже бардак, хотя и совсем другой по характеру. А всё идёт от мотивации. В Европе её ещё меньше. парсинг текстов на (возможно, псевдо)естественном языке Практически вся документация написана на псевдоестественном языке. Просто потому что формализация нужна даже тем, кто пишет. Хотя, в некоторых образцах находил по четыре нацепленных придаточных и вновьизобретённые слова, не встречающиеся в словаре. хотя подозреваю, что в ad hoc структуру для каждого отдельного проекта Вот пример одного из атрибутов требования. Вытаскивалось из текстового описания модулем на Perl. Причём ошибок было меньше десяти процентов в среднем документе и меньше тридцати в самом хреновом.

<!ELEMENT  Req          ( ... 
                          , ConfDocLst
                         ....)             >
<!ELEMENT  ConfDocLst  (ConfDoc)*       >
<!ELEMENT  ConfDoc     (PCDATA)         >
<!ATTLIST  ConfDoc
             type       (   CwUNKNOWN
                          | CwReview 
                          | CwAudit 
                          | CwDocumentation
                          | CwConcept 
                          | CwTest
                          ...
                          )             #REQUIRED
             inPhase    CDATA           #IMPLIED  >

Мне непонятно, как вы придумываете DSL Я нахожу закономерности в имеющемся тексте. Или (что случается гораздо реже) адаптирую "лучшие практики" И как потом обучаете пользователей следовать этой семантике, Обычно "Ни в коем случае не изобретайте ничего нового." А так, процесс работы идёт обычно через инженеров по сбору требований, которые и записывают результаты. Так, с вашими use cases непонятно, почему бы сразу не распечатывать plain text и не пинить те абзацы, где что-то не работает (или распечатывать каждый день новый текст, делая розовый фон для тех абзацев, где проблемы). Разные представления хороши для разных целей. UseCase - это линейное разложение графа. Когда граф представлен графом сразу видно отрубает ли ошибка боковую ветвь или блокирует основную функциональность. Тут есть еще один момент: откуда мы знаем, как шаги use case стали вдруг требованиями. Use Case и есть функциональные требования. На них накладываются нефункциональные. Но это уже другой список, элементы которого привязаны ко всему Use Case или к отдельному шагу.

Вот нечто подобное для софта. http://www.opfro.org/ Один из конкурентов UML (впрочем и RUP тоже), который, к сожалению, не стал стандартом OMG

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

Эх, боюсь, что понять в режиме комментов в ЖЖ не получится :( Одно понятно: если пустить инженеров заниматься требованиями, то они начинают порождать паттерны, на которые и можно потом опереться. Сначала пусть дорожки протопчут на ЕЯ, а уж потом софт их будет асфальтировать по потребности. Увы, те документы с требованиями, которые я видел, больше напоминают художественные произведения, нежели хоть как-то паттернированные тексты, которые можно распознать хоть чем-нибудь. Мне в связи с этим вспоминается Библиотека Мошкова: мне Мошков рассказывал, что у него 95% времени работы с библиотекой занимало программирование разных скриптов, которые переводили самые разные форматы, в которых ему присылали тексты в библиотеку, в публикуемый формат. И эта работа не останавливалась ни на секунду, а о том, чтобы унифицировать присылаемое не могло быть и речи. С требованиями, думаю, то же самое, только этот "формат" еще должен существовать, т.е. требования не должны писать в стихах. И тут мы опять упираемся в вопрос типа бардака на предприятиях. Этот бардак бывает абсолютно разных типов с разными последствиями для формата, в котором готовят требования и формата, в котором их ожидают увидеть :)

Интересно, раньше не видел. Они интересны хотя бы тем, что process model дают как синоним к method (у меня вчера на эту тему была переписка о пяти письмах с maksimotstavnov. У меня тем самым появился еще один аргумент :) Я всегда как о конкуренте UML думал в безатрибутную сторону -- типа тоже более мощного http://www.orm.net/