?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Вторник утро [07 May 2008|09:13am]

Китайцы построили за $1.5млрд. 36-километровый мост через залив -- самый длинный мост в мире. Начали строить в 2003г. (http://www.roadtraffic-technology.com/projects/hangzhou/), запустят в июне (http://www.abc.net.au/news/stories/2007/06/27/1962952.htm). 29% капитала -- частные, возврат денег от платы за проезд.

В последнее время меня очень интересует, как строят самые длинные, самые высокие, самые сложные сооружения -- так, чтобы уложиться в бюджет и сроки. Увы, вся видимая часть (собственно строительство) проходит на виду. Меня же интересует подводная часть: замысел, утверждение, проектирование. Это же какое окаянство нужно иметь, чтобы такие сооружения замысливать, а затем планировать -- чтобы потом эти планы оказывались реалистичными!

Также интересно, почему такая разница в ценах: 36км через океан стоят $1.5млрд, а вот чуть больше 1км coetunnel 2 в Амстердаме -- аж 500млн. евро.
* * *
Самое тонкое место сейчас для меня -- это техники выполнения проектных работ в системном инжиниринге. Вот мои вопросы:
а) как бы найти способ говорить о технических процессах жизненного цикла системной инженерии против стадий жизненного цикла без путаницы?
б) описание процессов agile при проектировании. Business rules по принятию отдельных проектных решений (как образуются частные baselines по частям проекта, как они собираются). Это, конечно, похоже на софт (кодирование, интеграция, тестирование, написание юнит-тестов и т.д.), но терминология-то другая и инструментарий другой.
в) проектность против agile: роль и место issue tracker в проектировании, роль и место встроенной в используемые инструменты проектирования (типа SmartPlant Enterprise) процессной машинки, роль и место средств проектного управления (PERT, Gantt, etc.).
г) чем отличаются системы поддержки системной инженерии типа приведенных в конкурсе INCOSE http://www.incose.org/symp2008/index.php?option=com_content&task=view&id=137&Itemid=123 и системы проектирования типа SmartPlant от Intergraph, OpenPlant от Bentley, продукты от Dassault Systemes и т.д.
* * *
Ключевой вопрос -- это понимание того, как действие "проектировщик принял решение о диаметре трубы и нажал кнопочку Publish" отражается в парадигмах (онтологиях, нотациях):
1. Процессной (ISO 15288, ISO 9000 и т.д.)
2. DEMO (перспектива речевых актов)
3. Проекты PMI PMBoK, PRINCE2 и т.д. (и, может быть, P2M)
4. Проекты Lean Project Management (Last Planner)
5. Проекты CCPM
6. Agile с issue tracking
7. Business Rules (процессный engine в системах типа того же SmartPlant Enterprise)

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

Намек на выход из ситуации дает текст Koskela, Howell, Vrjhoef "Undertanding construction supply chain: alternative interpretations" (http://cic.vtt.fi/lean/singapore/Vrijhoef.pdf). Там говорится, что перспектива речевых актов (DEMO) вполне совместима с LastPlanner. А в самом LastPlanner говорится о его совместимости с CCPM.

Будем думать над этим, и так прорвемся.

5 comments|post comment

ГОСТ Р ИСО/МЭК 15288-2005 [07 May 2008|11:19am]
На вебсайте http://gost.ru удалось поглядеть на специально испоганенный, чтобы нельзя было нормально воспользоваться (вот тут -- http://www.gost.ru/wps/portal/pages.Resource) стандарт ГОСТ Р ИСО/МЭК 15288-2005.

Перевод читать невозможно, stakeholders они перевели как правообладатели, а интеграция -- комплексирование. Интерес правообладателей к системе определен, как законный. Я, конечно, понимаю все про трудности перевода английского канцелярита, но нельзя же так! К тому же это стандарт 2005, а не 2008 года. Тем не менее, вот тамошняя суть:

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
СИСТЕМНАЯ ИНЖЕНЕРИЯ
Процессы жизненного цикла систем

Information technology. System engineering. System life cycle processes

Предисловие
 Сведения о стандарте

1 Область применения
   1.1 Назначение
   1.2 Область распространения
   1.3 Ограничения
2 Соответствие
   2.1 Предполагаемое использование
   2.2 Полное соответствие
   2.3 Адаптированное соответствие
3 Нормативные ссылки
4 Термины и определения
    приобретающая сторона
    деятельность
    соглашение
    базовая линия
    обеспечивающая система
    предприятие
    основные средства
    модель жизненного цикла
    оператор
    организация
    процесс
    проект
    ресурс
    стадия
    правообладатель
    поставщик
    система
    элемент системы
    рассматриваемая система
    жизненный цикл системы
    компромисс
    пользователь
    валидация
    верификация
5 Процессы жизненного цикла системы
5.1 Введение
5.2 Процессы соглашения
    5.2.1 Введение
    5.2.2 Процесс приобретения
    5.2.3 Процесс поставки
5.3 Процессы предприятия
    5.3.1 Введение
    5.3.2 Процесс управления средой предприятия
    5.3.3 Процесс управления инвестициями
    5.3.4 Процесс управления процессами жизненного цикла системы
    5.3.5 Процесс управления ресурсами
    5.3.6 Процесс управления качеством
5.4 Процессы проекта
    5.4.1 Введение
    5.4.2 Процесс планирования проекта
    5.4.3 Процесс оценки проекта
    5.4.4 Процесс контроля проекта
    5.4.5 Процесс принятия решений
    5.4.6 Процесс управления рисками
    5.4.7 Процесс управления конфигурацией
    5.4.8 Процесс управления информацией
5.5 Технические процессы
    5.5.1 Введение
    5.5.2 Процесс определения требований правообладателей
    5.5.3 Процесс анализа требований
    5.5.4 Процесс проектирования архитектуры
    5.5.5 Процесс реализации элементов системы
    5.5.6 Процесс комплексирования
    5.5.7 Процесс верификации
    5.5.8 Процесс передачи
    5.5.9 Процесс валидации
    5.5.10 Процесс функционирования
    5.5.11 Процесс обслуживания
    5.5.12 Процесс изъятия и списания
6 Стадии жизненного цикла системы
6.1 Введение
6.2 Модели жизненного цикла
6.3 Стадии жизненного цикла
Процесс адаптации
    А.1 Введение
    А.2 Процесс адаптации
    А.2.1 Цель процесса адаптации
    А.2.2 Результаты процесса адаптации
    А.2.3 Деятельность в процессе адаптации
Стадии жизненного цикла
В.1 Введение
В.2 Стадия замысла
    В.2.1 Краткий обзор
    В.2.2 Цель стадии замысла
    В.2.3 Результаты стадии замысла
В.3 Стадия разработки
    В.3.1 Краткий обзор
    В.3.2 Цель стадии разработки
    В.3.3 Результаты стадии разработки
В.4 Стадия производства
    В.4.1 Краткий обзор
    В.4.2 Цель стадии производства
    В.4.3 Результаты стадии производства
В.5 Стадия применения
    В.5.1 Краткий обзор
    В.5.2 Цель стадии применения
    В.5.3 Результаты стадии применения
В.6 Стадия поддержки применения
    В.6.1 Краткий обзор
    В.6.2 Цель стадии поддержки применения
    В.6.3 Результаты стадии поддержки применения
В.7 Стадия изъятия и списания
    В.7.1 Краткий обзор
    В.7.2 Цель стадии изъятия и списания
    В.7.3 Результаты стадии изъятия и списания
Взаимосвязь между ИСО/МЭК 15288 и Изменением N 1 к ИСО/МЭК 12207
    С.1 Представление в виде диаграммы
    С.2 Представление в виде таблицы
Концепции
D.1 Системные концепции
    D.1.1 Введение
    D.1.2 Системы
    D.1.3 Структура системы
    D.1.4 Иерархия систем и проектов
    D.1.5 Обеспечивающие системы
D.2 Концепции жизненного цикла системы
    D.2.1 Модель жизненного цикла
    D.2.2 Стадии жизненного цикла
    D.2.3 Стадии рассматриваемой системы и обеспечивающих ее систем
D.3 Концепции процесса
    D.3.1 Процессы жизненного цикла
    D.3.2 Ответственность и соглашения внутри и между организациями
    D.3.3 Применение процессов
Библиография
* * *
Для стандарта ISO 15288:2002 был разработан структурированный чеклист из помянутых в нем 475+ physical evidence -- чтобы облегчить доказательство соответствия следования стандарту: http://www.techstreet.com/cgi-bin/detail?product_id=1040221
* * *
А ведь я где-то видел табличку с разницей между версиями ISO 15288 2005 года и 2008года -- а теперь вдруг не смог ее найти. Если кто найдет раньше, чем я -- отметьтесь, плиз, в комментах.
1 comment|post comment

ISO 15026, системная инженерия -- assurance софта и систем [07 May 2008|12:03pm]

Тамошнего семейства стандартов прибывает. Вот про ISO 15026, "System Engineering -- Software and systems assurance": http://www.itaa.org/upload/es/docs/07N3785%20W07N1028_ISO-IEC_15026_CD%201.pdf.

Пояснения по истории появления: http://standards.computer.org/sesc/s2esc_excom/minutes/2007-07/Moore-Florida-2007-07.ppt (более ранняя и красочная презентация на ту же тему -- http://standards.computer.org/sesc/s2esc_conferences/SSTC-2006/SSTC-2006-Croll.pdf). Суть мне напомнила карту действий и результатов -- и нужно бы это предположение проверить поподробней. Ибо читаю одни слова, а мерещатся совсем-совсем другие:


Опять головная боль переводчика. К quality assurance только-только привыкли как к "обеспечению качества" (http://www.i-teco.ru/dictionary/330.htm), а вот к "просто assurance" (и даже "quality or assurance" как на картинке вверху) непонятно даже как и привыкать. Гарантирование систем и софта? А основной термин -- assurance case. Все понятно, только по-русски одним словом сказать очень затруднительно (A documented body of evidence that provides a convincing and valid argument that a specified set of critical claims about a system’s properties are adequately justified for a given application in a given environment).

Подробности (не по тексту стандарта, но для знакомства с терминологией): http://www.sei.cmu.edu/pcs/acprep.html, https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance.html, какие-то начальные объяснения даны в http://www.asq509.org/ht/action/GetDocumentAction/id/476 

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

Цитатки:
-- Most guidance is strong on excruciating detail for format, weak on gathering, merging, and reviewing technical evidence
-- Software is Brittle: As forgiving of Mistakes as Dialing a Phone Number. The one thing more brittle than software: the associated assurance case
-- Assurance case frameworks are rarely “1st class objects”, the subject of study per se
-- фермеры разговаривают: "Эй, они будут сегодня учить новому способу пахать -- пойдешь? -- Нет, не пойду! Я и так пашу хуже, чем знаю как надо!"

5 comments|post comment

Какие у нас есть "языки моделирования" [07 May 2008|04:05pm]
Вот списочек языков моделирования (то бишь языков, на которых можно описывать онтологии, таксономии и так далее -- до конкретных данных):

  • UML -- это наше всё. Не комментирую, ибо будет религиозная война.

  • ORM2 -- одновременно проще и круче UML. Например, именно он выбран для методологии DEMO. Чаще всего используется для проектирования баз данных. Подробности и софт -- http://www.ormfoundation.org/, теория и сравнение с UML -- http://www.orm.net/

  • EXPRESS -- принят в промышленности, закреплен стандартом (http://en.wikipedia.org/wiki/ISO_10303-11). Основа всей системы STEP (семейства ISO 10303), базис для ISO 15926-2.

  • OWL/RDF -- это semantic web, но он стремительно захватывает лидерство в промышленности (в том же ISO 15926-7), перешибая EXPRESS. Резон простой: делает то же самое, но бесплатного софта для него будет больше, и программистов будет найти легче.

  • Gellish - http://gellish.wiki.sourceforge.net/ -- хвастается, что может переписать в себя то, что сказано на UML, и ORM2, и EXPRESS, ибо содержит в себе более базовые концепты, позволяющие описывать на нем концепты из UML, ORM2 и EXPRESS. Он же и сам себе язык запросов.
Пока задачу переписки "в себя" знаний, представленных на других языках (по схеме "переписываем сначала концепты языка, а затем с их использованием -- автоматом конвертируем тексты на этих языках") ставила только команда Геллиша.

Для полноты картины не удержусь привести язык классификаторов и проекций ОргМастера (http://big.spb.ru/bigmaster/), но этот язык никак не специфицирован и разработчики не любят разговоры на эту тему. Хотя язык там вполне полноценный и рабочий, не хуже прочих и внутри более всего похож на Gellish.

Сюда же можно отнести СYCL из www.cyc.com и так далее -- до бесконечности.

И еще куча языков моделирования отдельных аспектов жизни -- типа IDEF0 для описания функций (ибо для описания процессов нужен IDEF3).
12 comments|post comment

navigation
[ viewing | May 7th, 2008 ]
[ go | previous day|next day ]