puln

Для тех, кто пользует LinkedIn, есть интересная ветка обсуждения вэб ориентированных приложения для менеджеров проектов
http://www.linkedin.com/e/ava/10899390/37888/EML_anet_qa_ttle-dnhOon0JumNFomgJt7dBpSBA/

Перечитывая ISO 15288, обнаружил, что в приложении о связи с другими стандартами определенно четко говорится об IEEE 1233.
Анализ требований по 15288 выливается в техническую группу описания продукта, и руководство по составлению спецификации требований к системе очень в этом помогает. В ISO 29148, о котором я рассказывал ранее, не забыли, разумеется, этот момент и в документе этого стандарта есть ссылки на IEEE 1233. Итого, в 29148 говорится в общем о подходе к инжинирингу и управлению требованиями и при упоминании о спецификациях идут ссылки на частные стандарты и рекомендации. Надо сказать, что группа RWG
сейчас работает не только над REGAL, но и над гайдами по написанию требований, оценке требований и многими интересными вещами =).

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

Атомная энергия, нефтяной кризис и прочее. Быть или не быть.
neinuclearnotes.blogspot.com/2009/12/with-and-without-nuclear-energy-in.html

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

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

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

Требованиями к объектам (entity) могут быть требования к материалам, например, из которых изготовлены объекты.

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

Добавил требования защищенности и безопасности.
http://www.slideshare.net/Puln/requiremetns-types

Разбираясь с типизацией требований в материалах Donald'a, стал очевиден его подход к разделению этих двух понятий в процессе инжиниринга. Я попытался перевести и осмыслить разницу между двумя терминами. Вроде и ясно, а вроде и нет. Грань тонка в определениях. Он специально делает разделение до перехода к требованиям, чтобы потом сказать, что инжиниринг требований включает в себя защищенно- и безопасно - ориентированные требования.

Safety Eng
the engineering discipline within systems engineering concerned with lowering the risk of unintentional unauthorized harm to valuable assets to a level that is acceptable to the system‟s stakeholders by preventing, detecting, and reacting to accidental harm, mishaps (i.e., accidents and incidents), hazards, and safety risks

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

Security Eng
the engineering discipline within systems engineering concerned with lowering the risk of intentional unauthorized harm to valuable assets to a level that is acceptable to the system‟s stakeholders by preventing, detecting, and reacting to malicious harm, misuses (i.e., attacks and incidents), threats, and security risks

Инженерия защищенности
инженерная дисциплина, входящая в системную инженерию и занимающая снижением риска умышленного постороннего ущерба ценным активам до уровня, приемлемого для заинтересованных сторон, путем предупреждения, обнаружения и реагирования на такой умышленный вред, злоупотребления (например, атаки и инциденты), угрозы и риски для защищенности.

Что в итоге. Разница в терминах (+ если я правильно перевел):
Случайный - Умышленный
Происшествие - Злоупотребление
Опасности - Угрозы

Дальше - больше. Дональд говорит, что защищенность и безопасность выступают как факторы качества.

Запутанные дорожки от ailev навели меня на материалы Donald'а Firesmith'а из SEI (Software Engineering Institute) о подходах к инжинирингу требований. Сайт Donalda'а sites.google.com/site/donaldfiresmith/.
На сайте института очень много материалов в свободном доступе.
Плохие требования приведут к плохой архитектуре, а плохая архитектура....
Вот как себе представляет архитектуру типов требований Дональд, а, соответственно, и именитый институт:
www.slideshare.net/Puln/ss-2607646
чего я пока не понимаю, так это почему нет ветки от функциональных требований?
На всякий случай привожу оригинал:
www.slideshare.net/Puln/type-of-requirements
За все это время я видел очень много разных подходов к типизации требований и в итоге становится понятно, что можно использовать абсолютно любой, лишь бы выполнялись подходы к проверке требований. В конечном счете можно же разрабатывать один и тот же продукт разными путями. Дональд говорит примерно тоже самое и добавляет, что главное, чтобы соблюдался закон Конвея .

-----
общий подход разработки требований Дональд онтологически видит так:
www.opfro.org/Components/WorkUnits/Activities/RequirementsEngineering/RequirementsEngineering.html

Нашел документ IAEA TECDOC-1305, в котором рассказывается про безопасное и эффективное управление жизненным циклом АЭС вплоть до вывода из эксплуатации.
Вот структура ЖЦ по версии МАГАТЭ:
http://www.slideshare.net/Puln/lcm-ieae-2589031
Замысел там, как отдельная стадия, отсутствует, это то, что бросилось в глаза сразу.

Вчера, на выступлении INCOSE я потерпел поражение. И это признаю.
Поиски ответа на вопрос, ЧТО и КАК передается из СУТ в CAD, какая все - таки архитектура СУТ, модель не привели к должному ответу...Да, понятно, что можно данные из СУТ запихнуть в XML структурированный по RIF, но это НЕ ТО! Это вариант, когда взаимодействие осуществляется по запросу, а должна быть поточная обработка и соотнесение данных из СУТ с 3D моделью в CADе...
Забавно было обнаружить факт, который каждый раз мелькал у меня перед носом при прочтении презентации по IRqA. Как говорится, видел фигу.

Видно, да? Covered by IRqA только верхняя часть, которая Контракт Активитис! А где и как осуществляется работа с Design & Engineering??! Можно, конечно, сказать, что все, что внизу - это CADовская сторона и нефиг там делать IRqA, но как двигаться по
НАРИСОВАННОЙ стрелке сверху вниз?

Наконец-то я официально член INCOSE!!!
Кто знает, сколько длилась эпопея с включением в состав - меня поймут =)

Итак, статус - INCOSE Member.