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). Айтишники потирают руки: для них это новый рынок сбыта, новые классы софта -- отладят бухгалтерские и юридические процессы, порубят их на более мелкие кусочки и часть кусочков вместе с частью обеспечивающей эти процессы системой сможет отъехать в оффшор.
Производство ушло в Китай, софтвер ушел в Индию. Бухучет и юридическая поддержка тоже ожидается, что уйдут в Индию.