Обсуждение

То есть получается, что если задумали делать актуальное навека надолго описание, то нужно "заглянуть" в будущее и предложить свой ЖЦ объекта описания и корректировать, корректировать, корректировать если изменения того требуют (а они того потребуют)? Это очень крутой писарь нужен.

Форма жизненного цикла (водопад, спираль, варианты agile, прототипирование и т.д.) по норме должна быть предложена из расчёта профиля рисков проекта. Так что буду я эти описания делать итерациями, или сначала сделаю полномасштабные требования, затем полномасштабную архитектуру (все эти начальные виды описаний, которые предложены в этом посте + beyond) и только затем начну описывать -- да, нужно определиться с этим. Насчёт "писаря", так не писарь нужен, а творец -- я, вроде, ясно об этом написал? Мне эти все эти описания (требования, архитектуру, дизайн -- я не претендую на изготовление собственно учебных материалов, их уже написано немало. Но и это придётся затронуть в какой-то мере) нужно сначала сочинить (это синтез), а уж только потомзаписать в какой-то форме и проверить на консистентность (анализ).

Да, написали, просто я диву дался какой это объем работы как с точки зрения сочинения, так и переведения на манускрипт. Для быстрой работы отдельно писарь еще понадобится, да еще и разумеющий в предмете.

Конечно, это огромная работа. Но: -- многое уже написано (и даже в этом блоге), а кое-что и опробовано. Я же не первый год в этом направлении долблю, так что я не с нуля начинаю. -- по поводу многого не нужно изобретать велосипед, оно уже придумано. Проблема главным образом в том, как сочетать все это уже понапридуманное. Но это легче, чем выдумывать всё с нуля "заранее согласованное друг с другом" и непрерывно ошибаться в этом. -- если использовать правильные инструменты для автоматизации, то это ещё облегчает работу, иногда в разы. -- я надеюсь, что буду работать над этим продуктом не один.

Систематизация зоопарка из 30 томов будет на годы отставать по времени от мутаций самой предметной области. Их в любом случае изучать как есть, примечать нужное, выкидывать лишнее, если навык восприятия есть. Основная проблема в отсутствии этого навыка. Вот знания системной инженерии, вот списки методов, а как оценить возможности применения и последствия применения этих методов в рабочей ситуации? Специалисту надо оценивать хорошо/плохо и осуществлять выбор, не только по материалам вчерашнего учебника, но и работая с практиками завтрашнего дня. Откуда это взять? Работать-работать-работать, а там как-то складывается... или не складывается. Нет примеров для подражания. Здесь был бы хорош деятельностный букварь, история системного инженера на проекте. Возможно, полухудожественная в стиле Голдратта или Демарко. А потом те 30 томов, как (потенциальные) справочные данные.

Я, вроде так и написал: консистентные 30 томов составить невозможно, нужно федерировать (а не интегрировать и не объединять). Так что заниматься нужно 800 страницами (два тома) информации по федерированию прежде всего, это обозримо. Эти 800 страниц будут содержать весьма и весьма разнородные описания, нельзя ожидать какой-то сквозной структуры для этих страниц -- и актуализация этих 800 страниц уже обозрима. Кстати, BKCaSE проект запустил "песочницу", чтобы актуализацию их 800 страниц делало комьюнити (там и авторов-то было ой-ой сколько). А вот собственно изучение -- это про то, как яблоки из задачи (из 30 томов) отождествить с яблоками из жизни (уникальными в каждом проекте). Это к тьютору и трудолюбию курсанта. Плюс "творчество" (как изобрести что-то новое, интересное и полезное на основе знаний в 30 томах), это вообще редко обсуждается -- одна из немногих методологий тут ТРИЗ, а больше полномасштабных и нетути.

Вообще-то CMMI - это не методология, а модель, т.е. систематизированный набор рекомендуемых практик. Которая ни в коей мере не "требует использования в каждом проекте одного и того же способа работы (метода)". Про другое упомянутое обсуждать не буду, в силу того, что про CMMI у меня есть все-таки моральное и реальное право что-либо утверждать.

Я следую терминологии и идеям ситуационной инженерии методов. Там CMMI (наряду со многими другими аналогичными) рассматривается именно как методология (т.е. метод, т.е. систематизированный набор рекомендуемых практик). Затем ходят специально обученные люди, и проверяют -- правда ли, что эти рекомендуемые практики выполняются. Если обсуждать все эти бесчисленные фреймворки в их собственной терминологии, то такое обсуждение будет бессмысленным: в них всех слова method, methodology, acivity, practice и т.д. имеют разный смысл. Так что я беру терминологию и способ рассуждения той школы мысли, для которой все эти CMMI, ISO 12207, RUP и т.д. сами являются объектами рассмотрения. Гляньте на http://ailev.livejournal.com/1082573.html и древнюю презентацию Ивара Якобсона, из которой всё это выросло: http://fr.slideshare.net/siouxhotornot/sioux-essential-unified-process-ivar-jacobson (там метод называется software process и начиная со второго слайда CMMI поминается как software process из лагеря process maturity).

Опять-таки, в праве говорить о CMMI только, тем более зная многих "отцов-основателей" этой модели лично. "На заре" модели CMM (без буквы I в конце) действительно, взгляд был больше методологический. Однако появление буквы I было не просто "украшательством", а реальным поворотом в сторону создания набора практик, которые можно комбинировать на свое усмотрение. Это реальная позиция создателей CMMI от начала существования модели. И что не очень нравилось "отцам-основателям" CMM (которые были почти отстранены от активного участия в CMMI и которые - в приватных беседах, конечно, поэтому имен не называю, кстати они приезжали и в Россию - всячески "поливают" CMMI). Что касается Якобсона... Так он "продает" своё... :) И в разное время по-разному. :)

Якобсон, конечно, продаёт своё, а вы -- своё. Но есть традиция, в которой даже не требуется обсуждать "с буквой I, или без буквы I", чтобы говорить о "сборно-разборных" методах. Это ситуационная инженерия методов, и в этой традиции кроме Якобсона довольно много людей работает, и вышло довольно много стандартов (OPF, ISO 24744, SPEM 2.0 и самый свежий OMG Essence -- на который я сейчас и опираюсь). Я тоже, наверное, вправе что-то говорить от лица этой традиции, ибо тоже лично знаю многих тамошних отцов-основателей, да и сам кое-какие делаю в неё вклады. Конечно, во всех этих RUP, CMMI и ISO 12207 (да их тысячи!) есть ремарки по "адаптации" и заложенная в них вариативность, как же без этого. Но всё одно они существенно отличаются от подхода ситуационной инженерии методов хотя бы тем, что в этом подходе нет заранее известного набора практик. Но можно брать, например, практики из CMMI, если кому-то очень-очень нужно. Или из agile. Или комбинировать их из CMMI и Scrum. Или взять практики работы с хардвером (ракетами, подводными лодками, АЭС) и скомбинировать их с практиками программной инженерии. Или описать вновь придуманную практику так, чтобы скомбинировать её в новом проекте с уже известными. У меня, кстати, ровно такая задача: курс системной инженерии, организационной инженерии, инженерного менеджмента -- и CMMI тут оказывается не у дел.

Немножко разобравшись понял, что немного на разных языках говорим, поэтому спор ни о чем. :) Поэтому пока лучше, видимо, приостановиться с надеждой на очное (живое) обсуждение в будущем. :)

Анатолий Игоревич, Вам нужен доброволец в это дело? Давайте лучше по-другому - возьмите добровольца в это дело.

ОК! Договорились практики TOC оформить по Essence и поглядеть, что из этого получится.