Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

OIМ для моделеориентированной инженерии требований. Группы описания требований как product model.

Когда мы рассматриваем такой сложный продукт работы, как "требования", разным людям для работы с ним требуются разные группы описаний. Это означает, что информационная модель требований для работы с собой будет требовать разных языков представления, разного программного и методического. В частности, нужна классификация не только самих требований (функциональные, нефункциональные и т.д. -- см., например, http://ailev.livejournal.com/769827.html), но и групп описаний и адресуемых ими интересов.

Для требований в целом необходимо построить OIM (object information model -- из ISO 15926, метамодель -- из OMG, абстрактный синтаксис -- в language workbenches, "рабочую онтологию" -- из СМД-методологии), которая будет выражаться в разного сорта диаграммах (не обсуждается в ISO 15926, диаграммы -- в OMG, конкретный синтаксис -- в language workbenches, схемы в СМД-методологии), адресующих разные группы описаний. Эту метамодель нужно будет затем выразить в терминах объемлющей онтологии (онтологии интеграции данных) -- в нашем случае в ISO 15926.

Для этой работы выражения OIM требований в ISO 15926 нужно будет разобраться со специфически онтологическими вопросами: где мы говорим о создании экземпляра модели требований, согласно метамодели, а где речь идет только об уточнении требований, а где сами проектные решения или даже реализованная (т.е. реальная) по этим проектным решениям система (для случая системной инженерии требований эта работа выполняется прямо сейчас на базе находок стандарта ISO 24744 в проекте PraxOS -- http://praxos.livejournal.com/. Скорее всего, для требований придется делать аналогичный проект -- и решать абсолютно аналогичные задачи (ибо для требований, как и для методов могут быть использованы совершенно разные специфические предметные онтологии, зависящие от конкретной ситуации, к которой прилагаются "типовые" решения. Требования также могут быть повторноиспользуемыми и "типовыми", и т.д.).

Тут еще нужно подумать, как OIM собственно требований (в инженерии требований это OIM для product model) связано с OIM инженерии требований в целом как метода (где product model является только частью общей модели, а кроме того как минимум есть process model, project model, organizational model инженерии требований).

Поэтому я бы поставил в план работ по PraxOS переинтерпретирование моего позавчерашнего поста про моделе-ориентированную инженерию требований (http://ailev.livejournal.com/801113.html) в духе сказанного в данном тексте. Моделе-ориентированную инженерию требований нужно моделировать, сапожник должен быть в сапогах.

По итогам моделирования, конечно, нужно будет переопределено и уточнено содержание дисциплины "инженерия требований" (предыдущий немоделеориентированный вариант был собран тут: http://ailev.livejournal.com/769827.html) -- для современного варианта моделе-ориентированной инженерии требований (http://ailev.livejournal.com/801113.html, причем с учетом переинтерпретации из предыдущего абзаца. То есть работа будет весьма итеративной).

Затем все то же самое нужно будет проделать с OIM инженерии системной архитектуры -- с учетом того, что само понятие системной архитектуры как продукта работы намного хуже определено, чем понятие требований. Но глаза боятся, руки делают.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 2 comments