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

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