Как я уже сообщала (см. http://rusrim.blogspot.com/2010/07/moreq2010.html ), на сайте http://contribute2moreq.eu/portal/ начато публичное обсуждение – пока ещё не текста, а ряда концептуальных вопросов проекта MoReq2010.Первые впечатления следующие. Участники проекта вовсе не собираются ограничиться, как это первоначально предполагалось, технической реструктуризацией требований спецификаций MoReq2. Речь идёт о создании нового документа, в основе которого будет лежать существенно измененная концепция.
Главное, на мой взгляд, изменение заключается в отказе от идеи использования спецификаций MoReq в качестве типовых требований, которые заинтересованные организации могли модифицировать по мере необходимости – особенно при подготовке тендерной документации. Теперь же организациям будет предложено, вместо отбора и доработки отдельных требований, подбирать подходящие модули из числа имеющихся, а в случае отсутствия таковых – разрабатывать новые модули в сотрудничестве с DLM-форумом.
Следствием такого подхода является ряд других нововведений. Некоторые из них относительно мелкие – так, предлагается изменить название спецификаций с «Типовых требований к управлению электронными документами» (Model Requirements for the Management of Electronic Records) на «Модульные требования к электронному управлению документами» (Modular Requirements for the Electronic Management of Records). Спецификации более не будут распространяться в редактируемом формате (типа Word), при этом мастер-копией спецификаций станет их HTML-версия на специальном сайте.
Запланировано и более серьёзное, и, как мне кажется, потенциально вредное изменение: из спецификаций планируется выбросить все нефункциональны требования (касающиеся удобства использования, производительности, доступности, технических стандартов, законодательно-нормативных требований, аутсорсинга, технологического устаревания и обеспечения долговременной сохранности, а также деловых процессов).
Меняется представление о структуре спецификаций. Относительно простая схема MoReq2, предусматривающая наличие ядра обязательных требований, к которому могли добавляться опциональные дополнительные модули, заменяется на более сложную конструкцию, показанную на рис.:
Модули предполагается сделать максимально независимыми от ядра и друг от друга. Каждый модуль будет опубликован в виде отдельного виртуального «тома» - с собственным титульным листом, введением, глоссарием, теоретической частью, функциональными требованиями, моделью объектов и метаданных, моделью управления доступом и аудита, и сертификационными тестами.
Предполагается активно поддерживать работу переводчиков, поощряя их сразу же размещать на том же официальном сайте спецификаций готовые разделы и даже отдельные страницы.
В целом же можно сказать, что, к сожалению, начинают оправдываться опасения, высказанные Марком Фреско в публикации компании Inforesight (см. http://rusrim.blogspot.com/2010/07/moreq-2010.html ).
О следующем туре обсуждения проекта MoReq2 см.http://rusrim.blogspot.com/2010/07/moreq2010-i.html
«Теперь же организациям будет предложено, вместо отбора и доработки отдельных требований, подбирать подходящие модули из числа имеющихся». Так разве это плохо? В России были брошены значительные силы на позиционирование MoReq-ss как «стандарт». Вот и настало время от позиционирования перейти к практике «подбора». С учетом специфик регулирующих сред, конечно же…
ОтветитьУдалитьИ что же, каждый модуль будет располагать «собственным глоссарием»? Сколько же глоссариев будет то? В связи с этим, возможно, «спокойнее», если придерживаться ISA-Req? Все равно ни спецификации, ни стандарты, ни… в России обязательств за собой не несут.
Так разве это плохо?
ОтветитьУдалитьIMHO альтернативные подключаемые модули в ядре - плохо, модули расширения - нормально.
Вот приходит продавец и говорит, что его система сертифицирован возможности фокусов с альтернативными модулями, то он только потом может обнаружить, что ему этот продукт на самом деле не подходит, поскольку он ожидал совсем другого.
Например, продукт может быть сертифицирован с альтернативным модулем, предусматривающим использование вместо обычной иерархической классификационной схемы - неиерархической на ключевых словах. Она в специфических ситуациях очень полезна, но для большинства клиентов неудобна.
Я вообще впервые встречаю попытку сделать стандарт с такой нетрадиционной архитектурой, так что очень велик риск, что из этой затеи ничего хорошего не выйдет.
...«спокойнее», если придерживаться IСA-Req?
Пока нет "обязаловки", каждый может выбрать то, что ему по душе :) IMHO ICA-Req хотя и не лучший документ из имеющихся, но достаточно приличный, и им, при желании, вполне можно пользоваться (особенно если иметь под рукой MoReq1 и TNA/PRO).