Обсуждение

А "в следующем сезоне в моде будет розовое" -- это какая модальность?

... Деквалификация ведёт, как известно, к деквантификации доходов ...

Никакой неопределённости IMHO нет, мы на практике применяем следующие модальности: - по умолчанию - система должна удовлетворять требование; - как только требование реализовано и проверено в определённом релизе, и об этом есть запись - определённый релиз системы удовлетворяет требование; - реже - для системы допустимо иметь ограничение. Причём даже если требования пишем в утвердительной форме Use Case или User Story - все договорились, что это "система должна", просто повторять в каждом пункте "система должна" никому не нужно. Точно так же, если требование выражается в форме моделей UML, mindmap, макета GUI - всё равно "система должна". "Спецификация требований" - IMHO оксюморон. Бизнес-требования описывают существенные потребности пользователей и других ЗЛ, системные требования описывают существенные предположения о свойствах и функциональности будущей системы. Абсолютно всех свойств и функций системы, и даже (!) проблем и потребностей пользователя заранее описать нельзя, по крайней мере, до того, как система будет готова. Да и не нужно, как бы ни хотели этого тестировщики. Потому что разработка ПО - это не дословный перевод с одного языка на другой, а перевод творческий, с доработкой, а то и с написанием своего собственного рассказа "по мотивам". И это нормально: нужно дать возможность думать и творить каждому. Если же кто-то хочет абсолютной определённости сразу - значит, боится, хочет прикрыть бумагой 5-ю точку, или даже устраивает итальянскую забастовку. В некоторых случаях это оправданно (медицина, вооружение, опасные производства), но чаще нет, и является совсем другой проблемой. Тем более, что всё описывать - очень долго и дорого, требования успевают устареть (опять же, где-то, наверное, не успевают, а у нас успевают). По крайней мере, это моё мнение и наш подход. Точно так же никакой проблемы с применением стандартов нет - по форме требования должны соответствовать принципу разумного минимализма, KISS и гибкости - как удобно конкретным читателям, так и опишем. А по принципам ведения - нужно, чтобы у каждого требования был источник, автор, статус, релиз, история и источники изменений. Концепция продукта - не более 30 страниц, раздел требований - не более 3, общий объём требований на проект - не более 300 страниц, если непременно нужно больше - нужно разбивать на подпроекты. Кроме того, мы выработали для себя некоторые семантические каркасы, планы того, что нужно не забыть описать, ну или понимать, почему не описываем: - для нефункциональных требований URPS+; - для функциональных: -- настройка (локальная, централизованная); -- работа (по событиям, по задачам); -- отчётность.

Мудреные вещи Вы описываете Анатолий. Текст ниасилил, увы, Ваш русский мне не по зубам. Существует аглицкий вариант? И если - то где? Однако диаграмки порадовали: примерно то же самое мы делаем со СмартПлантом. Отрадно видеть :)

Анатолий, если Вы против ката, то, может быть, посмотрите в сторону якорной ссылки? Типа в начале текста ссылка skip, чтобы сразу перескочить через ваш текст? Было бы удобно. Я с удовольствием читаю Ваши тексты, но когда возвращаешь во френдленту многократно проматывать тексты надоедает.

Я прошу прощения заранее за "не до конца"-компетентность - я только учусь :) но так, в качестве варианта понимания Анатолия Игоревича: А если вот такое "требование" от заказчика: "Продукт должен соответствовать требованиям законодательства РФ", и вам от заказчика дается сколько угодно сроков и ресурсов на обеспечение этого соответствия? Что будете делать? Переупакуете законодательство РФ в 300 страниц? И как потом докажете, что ваш продукт соответствует? А если бы вам это законодательство попало в виде непротиворечивой (онто-)логической модели (Да еще и с софтом, позволяющим с этой моделью работать), а "требования" заказчика попали бы к вам в виде маппинга (не всех) элементов этой большой модели на элементы вашей предполагаемой модели целевой системы? Вот это и были идеальные "требования", которые легко реализовать, добавив в целевую систему то, чего не хватает в ней для обеспечения требований (потянуть за "свои" объекты, а они через маппинг притянут все что в модели законодательства есть "на нашу тему"), и легко доказать их удовлетворение целевой системой. Мечты, мечты... - конечно, но "лучше медленно идти _туда_, чем быстро бежать _не туда_" же :) Главное направление выбрать, а Ватсоны АйБиЭмовичи наc туда на своих железных плечах донесут, не сегодня, так завтра :)

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

Я не очень понимаю, как тут помогла бы якорная ссылка (да и не видел таких ссылок внутри постингов в ЖЖ, и не нашел таких кнопочек в Семажике). Мне кажется, что клавиша PgDn и инерционное колёсико на мыши много более полезны, чем целиться в такую ссылку.

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

У меня в голове не софт, а большие "железные" проекты (которые гарантированно потом будут разбиты на подпроекты -- в составе будет порядка 400 систем, и все эти требования по 300 страниц к каждой из 400 систем в составе надсистемы как-то должны быть совместимы). Размер, увы, имеет значение.

Ваш вопрос очень хороший. Любые требования на железные системы содержат ссылки на конкретные стандарты, нормативные акты, законы, технические условия и другие документы. Даже если считать, что текст собственно "требований" 300 страниц, то при прохождении помянутых в них документов легко набирается 30000 этих страниц. И что делать: считать их все требованиями, или только начальные страницы? Это, конечно, не отменяет того, что в конце текста будет записано требование из вашего примера, а заодно и добавлено "и требования законодательство страны поставки". Еще хороший пример, когда вам дают 300 страниц требований, которые представляют собой "требования заказчика к требованиям, которые должен разработать проектант".

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

В такой ситуации самое важное - как будут проверять соответствие законодательству. Для бухгалтерской системы будут проверять одно, для сервера - другое. Для этого нужно каким-то образом выйти на тех, кто участвует (или участвовал) в проверке систем такого класса, и расспросить, что конкретно делают с системой при проверке. И написать требования не на основании 30 тыс. страниц стандарта, а на основании рассказа человека продолжительностью в несколько часов. Кстати, тут же может выясниться, что дело не [только] в системе. А также что обязательно должно быть, чтобы пройти проверку, на что могут закрыть глаза, если всё остальное хорошо, а что не проверяют совсем, потому что в стандарте написана абстракция или откровенная глупость. Если выйти на людей не получается, то сначала нужно постараться выделить самые важные аспекты из этого стандарта, а затем накопить необходимую информацию о проверке на своём опыте. Возможно, для этого придётся пройти проверку не с первого раза. Всё это очень долго и дорого. Но 30 тыс. страниц требований - это всё равно, что их полное отсутствие. В голове у человека, который их будет реализовывать руками, хорошо, если 30 страниц сразу поместятся.

В точку попали, SPF у нас заместо RIF. Написанием адаптеров "Engineering Tool <-> SPF" мы (интерграф) снижаем количество межаппликационных интерфейсов. Хотя до конца они еще не поумирали к сожалению. То тут то там клиент не хочет покупать/внедрять весь набор. Приходится дописывать и поддерживать всякую экзотику типа one-way SPI -> SAP или SPEL -> SAP. Что делать - деньги диктуют :( Внедрение у клиента (мой непосредственный джоб) - самый интересный участок. Действует правило - чем меньше предприятие размером (относительно) тем тяжелее идет процесс. У крупных фирм всегда существуют достаточно четкие требования к нумерациям, структуре предприятия, спискам и пр. Всегда есть место для толковых админов и инженеров способных схватить суть смартпланта. Причем нефтегазовые, горнодобавающие, судостроительные и энергетические фирмы - в лидерах такою позитивной тенденции. В связи с чем вопрос к Вам - как объяснить что машиностроение, оптика, электроника - обходятся без нас?

Анатолий Игоревич, кто же спорит, что имеет? Но IMHO проблема осознать и уложить в своей голове 12 тыс. страниц требований, правильно декомпозировать их с учётом орг. вопросов, и выстроить между ними связи с выстраиваем соотв. связей между людьми, которые будут отвечать за их реализацию - это в первую очередь проблема поиска человека с соответствующим, весьма редким талантом, или развития этого таланта в себе, а также обеспечения преемственности. Загрузить в голову 30 страниц можно заставить каждого (армейские уставы тому подтверждение), 1,5 тыс. страниц - можно научить, при наличии желания и потенциала, а дальше - только талант. Я считаю, что стандарт проблему целостного восприятия большого объёма информации не решает. И машинные инструменты тоже могут хранить, но не воспринимать. Если требования будут единообразно сформулированными и структурированными похожим образом, это несколько облегчит проблему их совместного использования. Но не кардинальным образом, в меньшей степени, чем принято считать. --- Действительно ли каждая из этих страниц требований по каждой системе имеет значение для разработчиков всех остальных систем? Или то общее, что действительно имеет значение для всех систем, всё же можно свернуть в концепцию на 30 страниц + 1-2 страницы на подсистему (уже получается больше, чем нужно), а остальное является частным для каждой подсистемы, создаётся для внутренних нужд разработчиков конкретной подсистемы, для остальных значения не имеет и... в некоторых случаях можно не писать?

Машиностроение обходится без вас в силу изначального выбора Интерграфа - это софт для проектировщиков. А софт для конструкторов писали другие фирмы. Только Дассо Системс попыталась расшириться на оба сектора.

? Не только Дассо. Многие фирмы пытались (и продолжают) войти в этот сектор - Микростейшн, Автокад ПИД, АВЕВА... Да, мы говорим об именно проектировании и life-cycle предприятий (сооружений, оффшор платформ и пр.) Конструировать собссно двигатель/микроскоп/турбину гораздо сподручней на SolidWorks - здесь спору нет.

Автокад без стратегии интеграции данных не котируется ни на рынке продуктов поддержки life-cycle изделия, ни на рынке продуктов поддержки life-cycle установки (сооружения, платформы). Отдельные приложения от Автокада входят в разные линейки. Авевы на рынке конструирования тоже нет.

Требование или не требование -- это деонтическая модальность высказывания. Инженерия требований и инженерия системной архитектуры -- разные дисциплины. Инженерия требований в основном работает с моделью черного ящика, получение каковой является задачей инженера по требованиям. Это социотехническая задача. Инженерия системной архитектуры -- с получением для системы модели белого ящика, в чем и заключается задача архитектора. Это уже техническая задача. Если от артефактов переходить к практикам, то я писал про инженерию требований подробней тут: http://ailev.livejournal.com/810548.html (и там ссылка на видео, если на слух лучше воспринимается). Есть и еще более подробные материалы, но они уже для клиентов.

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

Очень порадовал качественный и концентрированный обзор стандартов и подходов к представлению требований, таких материалов всегда не хватает. Если же по существу говорить о требованиях в ИТ, то главная проблема этого подхода в том, что требования в виде некоторого набора утверждений - они необозримы. А еще - по ним нельзя или сложно сказать нечто о системе за пределами сформулированных требований. Всегда существует некоторая вариативность процессов, и часто хочется понимать, насколько эта вариативность может быть поддержана. Более того, часто эта вариативность должна быть как-то заложена в требованиях, и не на уровне спектра поддерживаемых процессов, а на уровне вариантов mainstream-путей, поддерживаемых в эргономичном режиме. То есть, заказчик говорит: у нас этот процесс проходит 2 способами, и каждый - надо эффективно поддержать автоматизацией, а еще - мы хотим попробовать способ 3, и вообще бывает - еще штук 5, но их можно поддержать в полуручном режиме, однако хотелось бы представлять трудоемкость - вдруг мы захотим их использовать, а также стоимость реализации - если велика, мы лучше потом доработку закажем. На языке требований это не описывается, тут надо строить модели системы - через разные схемы - и доносить их до заказчика - тогда он сможет представить варианты. А как только модель построена - требования начинают представлять только исторический интерес, при чем только те, которые обосновывают конкретные не очевидные решения. Причем модель надо строить на ранних этапах, потому что заказчик еще заинтересован в деньгах и сроках и готов менять требования и свои процессы, если за счет этого систему можно получить сильно быстрее. Но готов менять, естественно, ограничено. Примерно так.