![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalen1. Мне подумалось: Не миф ли CMM Level.
Ведь кадры-то решают всё.Потому что, как говорит один мой товарищ, если дать обезьяне автомат Калашникова, самое умное, что она сможет с ним делать — это колоть им орехи.
Каким бы хорошим не был процесс, работники должны понимать его цели и принципы, и подгонять процесс под нужды проекта.
А если даже не дать таким людям формальный процесс, то они всё равно составят документацию, которую требует проект.
С другой стороны, у Сергея был такой опыт: людям неудобно было вводить требования в систему [много-денег-RT], они попросили чего-то другого. Им разрешили вводить их в виде Word-овских документов, и тут-то всё и встало: они не знали, в какой форме, по какому шаблону вводить требования.
Вывод из этой истории сделали такой, что даже самым грамотным работникам нужно давать процедуру. И грамотные аналитики (те, которые ставят требования), не растут на деревьях, их нужно учить.
А начинать обучение хорошо именно с процедуры.
В технологии SSADM — той, которую я знаю лучше всего, — для каждой методики есть список документов, которые она создаёт, и для каждого документа подробно описаны:
- а) формат и содержание;
- б) критерии и методы проверки качества, как-то:
- чеклисты с проверочными вопросами;
- методы формальной проверки полноты и непротиворечивости. Например, специальная матрица проверяет, для каждого ли объекта БД есть задача, которая делает ему C,R,U,D.
2. "Domain-driven design" by Eric Evans
Я немного покритиковал Эванса, как оказалдось - потому что недочитал до второй половины.Показалось, что много воды, что одна и та же мысль повторяется на разные лады. Не, мысль очень правильная:
- выделяйте модель предметной области (domain model);
- ведите общий словарь в терминах домена;
- говорите на языке этого словаря друг с другом и заказчиками, пишите код на нём; (два замечания: для заказчика эти слова всё равно будут значить не то, что для вас. Для него пациент - это человек, у которого взяли анализ, плюс личная карточка. А для нас - запись в БД и кусок памяти, определённым образом заполненный байтами).
- создавайте business layer в виде модели домена, и изолируйте его от прочих слоёв.
Но мне объяснили, что дальше идёт несколько очень интересных глав.
Сергей получил от этой книги индульгенцию на классы с именем "*Service". До тех пор он подозревал, что это слово не означает ничего, примерно как "Common", "General", "Object", "Data" или вот более дискуссоинный пример - "Manager". ("Manager" - это м.б. паттерн "utility class"). Ну а теперь мы знаем, что "сервис" бывает не только внутрисистемный, тот, что в словосочетании "Service layer", но и как понятие слоя бизнес-логики ("utility class").
Диме Бочоришвили книга ответила на некие ещё несформулированные вопросы и этим очень понравилась.
Далее о модели предметной области и паттернах, характерных только для модели домена, но не для реализации.
Эванс выделяет такие полезые паттерны для моделей анализа:
- Entity (объект, имеющий identity)
- Value object;
- Composite. Это не GoF-овский Aggregate, он "жёстче". На его элементы нельзя ссылаться извне, их нельзя "вынимать" и без корневого объекта они не бывают. Связь с чёрным даймондом у него внутри навигабельна в обе стороны;
- 1-directional association;
- и что-то ещё;
Меня эта идея натолкнула на мысль, что бывают паттерны модели предметной области ("модели-задачи"), а бывают паттерны модели-решения. Например, такой вот "strong composite" (термин мой) - это паттерн анализа, а Observer - паттерн реализации.
Эту мысль надо развить.
Пообещал себе прочесть фаулеровские "Analysis patterns".
Об отличиях постановки задачи от модели-"постановки задачи" от модели-решения и от собственно решения.
Как вы сами понимаете, даже если мы говорим с заказчиком на одном языке, слово "пациент" значит для нас разные вещи.
Так вот, задача заказчика не эквивалентна модели этой задачи.
Модель-постановка задачи не эквивалентна модели решения; а та не эквивалентна самому решению — программе на языке, скажем, Java.
Потому что:
1) Ассоциация между классами на диаграмме UML, даже именованная, несет не такую семантическую нагрузку, как связь между накладной и товаром, или ссылка между классами в коде на Java. По ней не видно:
- навигабельна ли она в обе стороны или в одну;
- реализована ли она как ссылочное поле или как реестр;
- какие классы могут делать по ней навигацию - только владелец, все, или какоей-то подмножество;
- и ещё много чего по ней не видно, как из области задачи (бизнес-процесса), так и из решения (java-кода).
3) Ну и в SSADM выделяются "модель существующей системы" и "модель проектируемой системы". В терминах этой статьи, они равны понятиям "модель задачи" и "модель решения" соотв.
4) И чтобы модель точно соответствовала предметной области, вместо конструкторов и оператора new для пациента пришлось бы заводить объект-папу и объект-маму. Что есть нонсенс.
Из приколов:
(речь об отображении требований на языки со статической и динамической типизацией): "Сегодня я пассажир, а завтра пациент".
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
22/9/06 14:39 (UTC)(no subject)
22/9/06 14:46 (UTC)(no subject)
23/9/06 08:08 (UTC)насколько я понимаю, одна из целей CMM получить результат не смотря на качество кадров ... правда, тут из святой троицы, боюсь, получиться _только_ хорошо - точно не быстро и врядли дешево ...
(no subject)
23/9/06 10:56 (UTC)На мой взгляд цель СММ - предложить хоть что-то на случай если никакими имеющимися на рынке кадрами с задачей справиться не получается.
В Штатах CMM - это еще способ хоть как-то оценивать уровень конторы... Иначе говоря, если контора СПОСОБНА, ЕСЛИ ПРИКАЖУТ, функционировать на Level 4, значит она умеет справляться с трудностями :)
(no subject)
23/9/06 15:19 (UTC)1. При соблюдении процесса гарантируется качество
2. Метрики дают возможность контролировать процесс и бюджет не вникая глубоко в проект
3. Нарушения процесса видны сразу, и можно их ликвидировать минимальными усилиями
(no subject)
23/9/06 20:24 (UTC)
- Гарантируется ли? Что реально гарантируется? Как можно гарантировать обобщенное качество - удовлетворенность заказчика отдачей от продукта?
- Дают ли формальные метрики существенно более качественный и правдоподобный результат чем звонок менеджеру с вопросом "Эй, как там у вас, все в порядке? Сколько там примерно еще осталось?"
- Нарушения процесса сами по себе не являются признаком завала проекта. Может, как раз процесс неадекватен проекту.
Я не являюсь противником формальных процессов, как может показаться. Просто на мой взгляд формальный процесс нельзя "внедрить", его можно только вырастить из менее формального или неформального. Растет уровень зрелости очень медленно. Это в свою очередь требует стабильной во времени политики улучшения процесса, малой текучки кадров и большого времени жизни компании на рынке без смены владельца, высшего техничского руководства и курса.Подумайте, сколько человеку надо сделать проектов, прежде чем человек сможет назвать себя специалистом по управлению требованиями? Сколько это времени? Сколько понадобится специалисту времени, чтобы внедрить привычные ему практики на новом месте работы? Сколько времени вы согласны работать на одном месте? Сколько вам будет лет тогда когда вы это все внедрите? Какие у вас тогда будут интересы?
Все это обуславливает текущую ситуацию с CMM здесь. О СММ говорят ньюбы, а престарелым гуру уже вообще ничего не надо. Видимо, пора мне срываться с насиженного места и эмигрировать в "серьёзную контору" без бюрократии и людей сидящих не на своем месте и вставляющих палки в колеса. Такие бывают?
(no subject)
24/9/06 16:23 (UTC)Так ведь - не бывает разработки ради разработки. Бывает проект, о котором одно "лицо" договорилось с другим, и люди, которых эти двое считают авторитетными, и люди, которым нужны подряды в этом проекте, и те де и те пе.
Давайте искать рынок, где ценят в первую очередь качество, а не умение продать. И желательно, где не нужно работать на военных...
(no subject)
24/9/06 19:15 (UTC)(no subject)
18/10/06 13:06 (UTC)1. При соблюдении процесса гарантируется качество
В моём понимании, гарантируется не качественный результат, а одинаковый (возможно, одинаково безобразный) результат. Но это при 100% соблюдении процесса и прочих равных.
2. Метрики дают возможность контролировать процесс и бюджет не вникая глубоко в проект
Согласен. По крайней мере - создают у ни во что не вникающего Самого Генерального Директора иллюзию контроля :) .
3. Нарушения процесса видны сразу, и можно их ликвидировать минимальными усилиями
Да. Если видно - нарушение есть. Но если не видно - это не обязательно значит, что нарушений нет.
(no subject)
18/10/06 13:28 (UTC)(no subject)
18/10/06 14:29 (UTC)Объясняю. CMM относится к качеству описания и процесса развития бизнес-процессов. Не к качеству бизнес-процессов по своей сути. И уж точно не к качеству результатов.
Если бизнес-процессы плохие и неоптимальные, предприятие в долгах, продукцию никто не покупает, но при этом
...то контора великолепно соответствует CMM Level 5 - Optimizing.
Не верите? Вчитайтесь в буквы стандарта. Коммерческий стандарт - не закон важны буквы, а не дух :). Остальные пункты доказывать?
(no subject)
19/10/06 06:51 (UTC)(no subject)
19/10/06 16:10 (UTC)Я согласен, что метрики - штука полезная. Но что можно пользоваться метриками, не зная предметной области - IMHO неверно. Метрика по сути - способ свёртки критериев. Было 1000 показателей - стал один.
С финансовыми метриками ещё куда ни шло. Что такое ROI и ему подобные - более-менее понятно и хорошо описано. Да и то... ROI за 3год проекта =10%. Плохо или хорошо? Ну,если внедряется ERP-система на предприятии в 10000 рабочих - это очень даже хорошо. А если разрабатывается web-магазин - то очень плохо.
Но с количественными, например... Ну допустим, количество функциональных точек, высчитанных по IFPUG FPA, за 5 месяц проекта - 250. А за 4-й было 100. Когда эффект был больше? За 5-й месяц? Но на 5-м месяце мы делали пользовательский интерфейс на "толстом" клиенте с сетевым взаимодействием при помощи VB.Net. А на 4-м - многонитевое "ядро" в VI на ANSI C, которое "крутится" на Itanium'е под OpenVMS и в котором, собственно, ноу-хау нашей системы. А если мы посмотрим только на один показатель, не вдаваясь в тонкости проекта - выходит, что за низкую продуктивность в 4-м месяце кого-то нужно наказать. Не правда ли?
(no subject)
18/10/06 13:15 (UTC)Если все студенты сдали экзамен на "неуд.", виноваты не студенты.
(no subject)
18/10/06 13:30 (UTC)(no subject)
18/10/06 18:02 (UTC)(no subject)
19/10/06 06:49 (UTC)(no subject)
19/10/06 23:33 (UTC)(no subject)
19/10/06 16:27 (UTC)Если кто-то не соблюдает план, регламент (CMM) и качество работы (ISO) - значит, нужно найти того, кто соблюдает, а потом уволить первого.
Как быть с обучением и "выращиванием" специалистов - честно говоря, не знаю. Наверное, нужно давать "выращиваемым" чуть больше, чем они стоят на рынке, даже с учётом роста их "стоимости".
Вы опять не о том
19/10/06 17:21 (UTC)(no subject)
19/10/06 06:47 (UTC)(no subject)
19/10/06 16:32 (UTC)Формально выполнить требования CMM можно и без CMMI - см. пример про валенки :)...
(no subject)
19/10/06 23:28 (UTC)(no subject)
24/9/06 16:39 (UTC)Можно только помочь им немного лучше понять, как разрабатывается софт.