Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

Требовательный вторник

blogstas заметил, что Gellish (gellish_ru) по-русски будет аццкий.

Я сам рассматриваю Gellish как очень и очень интересный и перспективный набор идей: связанной с пониманием денормализации, факт-ориентированного моделирования (http://ailev.livejournal.com/699549.html), онтологического мэппинга a la ISO 15926, становления "независимого" стандарта частной группы людей, куча идей в его онтологии (например, прихваченная от Dietz закопанная туда онтология хореографии, основанная на теории речевых актов) и т.д.

Хотя это только набор идей, не более. Для использования Gellish на практике, как всегда, не хватает инструментария. Побеждают ведь не идеи, побеждает инструментарий. Есть деньги на разработку инструментария -- идея будет жить. Нет денег -- будет только "красивая идея", а жизни не будет.
* * *
Слово service в описании требований к системе очень сложно переводить. Чаще всего его нужно переводить как "функция" (ибо "сервис" -- это не перевод, "служба" -- совсем не то имеется ввиду, "услуга" -- сильно сказано, а "функция" -- самое то, и тоже словарное значение). Хуже всего то, что service обычно используется во всем многообразии его омонимии (равно как и process и прочие общие слова). Service-1 of service-A of system-B.

Management process of requirement definition process of hardware process. Я так думаю, что если есть software process, должен быть и hardware process. А если requirement definition называют process, то и к management можно смело добавлять process. Процесс на процессе и практикой погоняет.

Все это большая и не всегда осмысленная игра словами, и очень хочется плюнуть на оригинал и пересказать все своими словами. Сделать не "гармонизированный перевод", а "гармонизированный пересказ" всех этих стандартов -- было бы точно более общественно-полезным делом для траты цветов моей селезенки.

Но кроме меня (который внимательно этот стандарт читал и в нем разбирался) есть много других людей, которые имеют свое представление об общественной пользе. Сначала нужно удовлетворить их.
* * *
Через час на недельку до второго дитенку увезет тёща в Комарово. Ага, это тот самый курорт из песни.

Вечером в четверг я сам отправлюсь на денек в нижегородский тыдыкс (TEDx, http://icamp2009.ru/rus/pages/66/). Давненько я не бывал на интернет-тусовках. С другой стороны, "интернет" сейчас настолько неспецифичен, что ехать туда все равно как на телефон-тусовку, или телерадио-тусовку. Хотя отличие некоторое есть: в условиях засилья Web 2.0 по факту это "тусовка тусователей", мета-тусовка, делаемая широкопрофильными тусователями для узкопрофильных тусователей методами творческого тусования.

Кстати, свое (негативное) отношение к профессиональному "тусованию тусовок" я высказал тут: http://users.livejournal.com/_lothar_/166671.html. Если хочешь тусовать -- начинай что-то делать, и тусовка вокруг тебя появится, и даже пойдет за тобой, если ты лидер. А если ты тусователь, то тусовка потусуется на твоей площадке, определит на развлекательно-завлекательном материале лидеров и дальше пойдет за лидерами в их проекты.
* * *
Еще раз про требования: ISO 15288 рекомендует выделять:

а) источники потребности заинтересованных сторон (sources of stakeholder need). Говорится, что время жизненного цикла системы идет -- и потребности заинтересованных сторон могут поменяться. Поэтому нужно поддерживать отнесение требований заинтересованных сторон к источникам их потребностей, чтобы не прозевать момент изменений этих потребностей и соответствующий пересмотр записанных требований.

б) требования заинтересованных сторон (stakeholder requirements) -- включая все вопросы их формулирования, полноты выявления, устранения в них противоречий, выкидывания нереализуемых или непрактичных требований.

Это все практика определения требований заинтересованных сторон (Stakeholder Requirements Definition Process). Один из пяти результатов выполнения этой практики -- "выявлены требования заинтересованных сторон для валидации".

в) системные требования. Цитата: "Назначение практики анализа требований – переработать основанную на требованиях заинтересованных сторон группу описаний желательных функций в техническую группу описаний требуемого продукта, который может предоставить эти функции. В ходе данной практики строится представление удовлетворяющей требованиям заинтересованных лиц будущей системы, и которое, насколько то позволяют ограничения, не предполагает никакой определенной реализации. Практика приводит к измеримым системным требованиям, которые с точки зрения поставщика специфицируют, какими характеристиками и в какой степени должна обладать [система], чтобы отвечать требованиям заинтересованных сторон".

Это уже практика анализа требований (Requirements Analysis Process). Один из четырех результатов выполнения этой практики -- "определена основа для верификации соблюдения требований к системе".

Поддержка и регулярная демонстрация соотнесения (tracability) всех элементов слоев этого блинчатого пирога: заинтересованные лица <--> их потребности <--> их требования <--> системные требования <--> проект-design <--> система. Для этого используется правильное хранилище данных (data repository).
* * *
У американцев очередная беда -- Knowledge-intensive professional services such as accounting and legal support are starting to move offshore in the same way that software services did a decade ago (это из июльского Communications of ACM). Айтишники потирают руки: для них это новый рынок сбыта, новые классы софта -- отладят бухгалтерские и юридические процессы, порубят их на более мелкие кусочки и часть кусочков вместе с частью обеспечивающей эти процессы системой сможет отъехать в оффшор.

Производство ушло в Китай, софтвер ушел в Индию. Бухучет и юридическая поддержка тоже ожидается, что уйдут в Индию.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 17 comments