В DDD одним из главных подходов в проектировании модели является ubiquitous language (общеупотребительный язык). Под общеупотребительным языком понимается набор терминов, которые являются базовыми в предметной области, и часто напрямую транслируются в сущности проектируемой модели. Общеупотребительный язык, как и следует из термина, должен являться общим для всех: для группы разработчиков, для группы экспертов предметной области, для заказчика.
Но в языках отличных от английского это ведет к проблеме. Термины для модели, используемые разработчиками, будут отличатся от терминов экспертов предметной области и заказчика. Разработчики должны будут иметь список соответствия (вида Б = B) терминов и объектов модели. При этом все разработчики, участвующие в проектировании модели, а в идеале все участвующие в разработке, должны иметь единый список. То есть простой перевод терминов не поможет, так как многие слова могут иметь различное значение, и могут по разному быть интерпретированы разными членами команды. А это уже нарушение принципа ubiquitous language, так как язык становится уже не общим.
Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области.
Как правильно решаются эти проблемы я не знаю. Я столкнулся с этим вопросом во время чтения книги Эрика Эванса (Eric Evans) “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
В нашей компании существует посредник между разработчиками и специалистами по предметной области. В своей книге, Эванс, говорит о том, что использование посредника-аналитика, как в водопаде, ведет к отсутствие обратной связи. По сути аналитик, общаясь с экспертами, один отвечает за проектирование модели, при этом упуская сторону разработчиков в проектирование. Модель сильно отличается от реальности, и зачастую требуется корректировка модели с учетом возможности разработки этой модели, представлении в виде кода.
У нас аналитик, после обсуждения со специалистами по предметной области, заново все обсуждает с разработчиками. Это значительно увеличивает время проектирования модели, а так же сводит четкое понимание к узкому кругу лиц, которые напрямую участвуют в проектировании. Простые разработчики увеличивают свое понимание лишь в момент преступления к разработке определенного функционала. Замечу, что мы используем DDD, но не domain-driven design, а data-driven design.
В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
Здравствуйте, Saddo, Вы писали:
S>В DDD одним из главных подходов в проектировании модели является ubiquitous language (общеупотребительный язык). Под общеупотребительным языком понимается набор терминов, которые являются базовыми в предметной области, и часто напрямую транслируются в сущности проектируемой модели. Общеупотребительный язык, как и следует из термина, должен являться общим для всех: для группы разработчиков, для группы экспертов предметной области, для заказчика.
S>Но в языках отличных от английского это ведет к проблеме. Термины для модели, используемые разработчиками, будут отличатся от терминов экспертов предметной области и заказчика. Разработчики должны будут иметь список соответствия (вида Б = B) терминов и объектов модели. При этом все разработчики, участвующие в проектировании модели, а в идеале все участвующие в разработке, должны иметь единый список. То есть простой перевод терминов не поможет, так как многие слова могут иметь различное значение, и могут по разному быть интерпретированы разными членами команды. А это уже нарушение принципа ubiquitous language, так как язык становится уже не общим.
Вообще-то подобная проблема решается словарем — грубо говоря, текстовыми заметками, прикрепляемыми к блокам модели и однозначно интерпретирующими короткое название блока в понятном для всех виде. Можно иметь несколько интерпретаций, понятных для заказчика и исполнителей, но писать эти интерепретации должен один человек — аналитик. Это хуже, но если иначе нельзя...
S>Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области.
Это как??? Хочется спросить "тогда зачем нужна такая модель?", но вероятно, все сложнее. Приведите пример такого несоответствия.
S>Как правильно решаются эти проблемы я не знаю. Я столкнулся с этим вопросом во время чтения книги Эрика Эванса (Eric Evans) “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
S>В нашей компании существует посредник между разработчиками и специалистами по предметной области. В своей книге, Эванс, говорит о том, что использование посредника-аналитика, как в водопаде, ведет к отсутствие обратной связи. По сути аналитик, общаясь с экспертами, один отвечает за проектирование модели, при этом упуская сторону разработчиков в проектирование. Модель сильно отличается от реальности, и зачастую требуется корректировка модели с учетом возможности разработки этой модели, представлении в виде кода.
Стоп! В последнем предложении две фразы:
"Модель сильно отличается от реальности" — так приблизьте до необходимого уровня, что мешает? Все модели не идеальны.
"Зачастую требуется корректировка модели с учетом возможности разработки этой модели, представлении в виде кода" — коректировка или дальнейшая декомпозиция?
Вообще, похоже, есть проблемы с аналитиком, раз сказана такая фраза. У него времени не хватает или он просто не в состоянии это сделать?
S>У нас аналитик, после обсуждения со специалистами по предметной области, заново все обсуждает с разработчиками. Это значительно увеличивает время проектирования модели, а так же сводит четкое понимание к узкому кругу лиц, которые напрямую участвуют в проектировании. Простые разработчики увеличивают свое понимание лишь в момент преступления к разработке определенного функционала. Замечу, что мы используем DDD, но не domain-driven design, а data-driven design.
S>В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
S>Как эти проблемы решается в других компаниях?
Правильно ли я понял, что основная проблема состоит в различном понимании терминов заказчиком и разработчиками? И что переходным звеном между ними является аналитик(и), который переводит все с языка заказчика на язык разработчиков и наоборот? Так это нормально, так и должно быть. Аналитик — бутылочное горлышко. Как и РМ, как и ведущий программист, как и ведущий тестер и все прочие специалисты высокого уровня.
И почему разработчики не участвуют в проектировании? Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили?
А вообще-то я немного не понимаю, в чем проблема. Если в работе над моделью принимают участие лишь несколько аналитиков, то именно они и будут являться носителями ключевых знаний. Если Вас не устраивает такое состояние дел, то можно организовать регулярные семинары для разработчиков, на которых будет объясняться модель — что там есть и зачем. Но, по опыту, большинству разработчиков это настолько по барабану, что такой семинар — пустая трата времени и денег. Лучше уделять время на объяснение модели на проектных совещаниях — по 10-15 минут, хотя бы на верхних уровнях.
Здравствуйте, nvb, Вы писали:
nvb>Здравствуйте, Saddo, Вы писали:
>Вообще-то подобная проблема решается словарем — грубо говоря, текстовыми заметками, прикрепляемыми к блокам модели и однозначно интерпретирующими короткое название блока в понятном для всех виде. Можно иметь несколько интерпретаций, понятных для заказчика и исполнителей, но писать эти интерепретации должен один человек — аналитик. Это хуже, но если иначе нельзя... >>Разработчики должны будут иметь список соответствия (вида Б = B) терминов и объектов модели.
Я примерно о том же и говорил.
>>Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области. >Это как??? Хочется спросить "тогда зачем нужна такая модель?", но вероятно, все сложнее. Приведите пример такого несоответствия.
Прямой пример я навскидку не смогу привести. Но наверное есть термины специфичные исключительно для русского языка (язык предметной области) и не имеющие аналогов в английском (язык модели). Хотя в популярных предметных облостях это не бывает.
nvb>Стоп! В последнем предложении две фразы: nvb>"Модель сильно отличается от реальности" — так приблизьте до необходимого уровня, что мешает? Все модели не идеальны. nvb>"Зачастую требуется корректировка модели с учетом возможности разработки этой модели, представлении в виде кода" — коректировка или дальнейшая декомпозиция?
Аналитик, который занимается анализом предметной области, может не всегда идеально представить свое знание ввиде модели. И не всегда его модель будет хорошей, если не будет учитываться мнение тех кто будет разрабатывать эту модель.
nvb>Вообще, похоже, есть проблемы с аналитиком, раз сказана такая фраза. У него времени не хватает или он просто не в состоянии это сделать?
"In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback. The analysts have full responsibility for creating the model, based only on input from the business experts. They have no opportunity to learn from the programmers or gain experience with early versions of software. Knowledge trickles in one direction, but does not accumulate." (c) Evans
nvb>Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили? nvb>И почему разработчики не участвуют в проектировании? Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили?
Просто подобный слой приносит сильные задержки по времени. Эксперт <-> Аналитик(и) <-> ТимЛид/Проектировщики. К тому же, как и любая прослойка вносит свой уровень шума и сломанного телефона.
nvb>А вообще-то я немного не понимаю, в чем проблема. Если в работе над моделью принимают участие лишь несколько аналитиков, то именно они и будут являться носителями ключевых знаний. Если Вас не устраивает такое состояние дел, то можно организовать регулярные семинары для разработчиков, на которых будет объясняться модель — что там есть и зачем. Но, по опыту, большинству разработчиков это настолько по барабану, что такой семинар — пустая трата времени и денег. Лучше уделять время на объяснение модели на проектных совещаниях — по 10-15 минут, хотя бы на верхних уровнях.
В том-то и проблема, что у нас это единственное похоже решение.
Здравствуйте, Saddo, Вы писали:
nvb>>Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили? nvb>>И почему разработчики не участвуют в проектировании? Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили? S>Просто подобный слой приносит сильные задержки по времени. Эксперт <-> Аналитик(и) <-> ТимЛид/Проектировщики. К тому же, как и любая прослойка вносит свой уровень шума и сломанного телефона.
Уже много всего мы написали. Попробую избежать ухода в мультитопиковость
Давайте создадим модель проблемы, которую Вы хотите решить Для начала, в виде декомпозированного списка, в котором элементы не связаны друг с другом (будем есть слона по кусочкам).
1. Аналитики не всегда могут корректно перевести англоязычные термины
2. Аналитики не могут создать модель, с достаточной степенью приближения отображающую реальность
3. Время, затрачиваемое на реализацию бизнес-требований заказчика, увеличивается вследствие трех-четырех этапного процесса реализации (эксперт-аналитики-тимлид-проектировщики)
4. Вследствие того, что программисты-исполнители не участвуют и не хотят участвовать в создании модели, есть риск возникновения проблем с реализацией этой модели.
Это все? Можно дополнить.
Теперь давайте попробуем реализовать эту модель в виде стандартных решений для каждого пункта
1. Зачем переводить одно английское слово одним русским словом? Переведите десятью, поставьте гипертекстовые ссылки на термины и т.п. В общем, создайте словарь.
2. Пусть аналитики проведут несколько этапов анализа и синтеза необходимых элементов модели для получения достаточной степени приближения.
3. С этим ничего не поделаешь. Рядовые программисты не могут по умолчанию работать системными аналитиками. Но попробуйте подойти к проблеме с противоположной стороны. Представьте, что все программисты смогли бы это делать. Тогда бы они предпочли только этим и заниматься, откладывая написание кода на потом, пока не нашли бы действительно идеальное решение (к тому же еще и устраивающее их всех). Это ведет к срыву сроков и претензиям заказчика. Сравните с существующей сейчас у Вас и работающей трехступенчатой схемой. Вы все еще уверены, что хотите поменять ее? Как сказали в соседней ветке — посадите рядом десять Линусов Торвальдсов и получите такую массу проблем, что Вам и не снилась
4. Вот тут уже труднее. Посоветовать ничего не могу – сильно зависит от конкретных людей и организации. Можно тянуть за уши к свету всех на тренингах и совещаниях, можно не всех, а только тимлидов или старших программистов. Можно декомпозировать модель до уровня, касающегося непосредственно исполнителей и предложить им самим декомпозировать дальше. Можно хотя бы попросить документировать проблемы, которые они видят при реализации этой модели (охаять чужое творение всякий рад ) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3,
Конечно, я не верю в то, что это все — в яблочко, и поможет вот прямо завтра решить все проблемы Это всего лишь иллюстрация того, каким путем можно пойти.
Собственно, так и поступают приглашенные консультанты — раскладывают проблемы на доступные их пониманию независимые кусочки и фиксят эти кусочки стандартными, известными им методами. Затем проводится следующая итерация. Попробуйте сделать то же сами — Вы ведь лучше их знаете свою специфику
Здравствуйте, Saddo, Вы писали:
S>В DDD одним из главных подходов в проектировании модели является ubiquitous language (общеупотребительный язык)..... S>..... Замечу, что мы используем DDD, но не domain-driven design, а data-driven design. ...... S>В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. S>Как эти проблемы решается в других компаниях?
Так что же это за "DDD" на которое Вы ссылаетесь названии темы?
И если это "data-driven design", то:
1. что именно Вы назывете этим термином? давайте ссылку
2. а пока не прояснено №1, то и нафик непонятно какое место там имеет ubiquitous language (общеупотребительный язык), и соответственно как чей-либо опыт к Вам вообще относится.
Здравствуйте, ilya.buchkin, Вы писали:
IB>Так что же это за "DDD" на которое Вы ссылаетесь названии темы?
Domain Driven Design. Простите, забыл поставить ссылку. В оригинальном посте, в моем блоге, я поставил ссылку. Но там мало кто читает, поэтому я скопировал вопрос сюда, а ссылку не поправил.
Здравствуйте, nvb, Вы писали:
nvb>Давайте создадим модель проблемы, которую Вы хотите решить Для начала, в виде декомпозированного списка, в котором элементы не связаны друг с другом (будем есть слона по кусочкам).
nvb>1. Аналитики не всегда могут корректно перевести англоязычные термины nvb>2. Аналитики не могут создать модель, с достаточной степенью приближения отображающую реальность nvb>3. Время, затрачиваемое на реализацию бизнес-требований заказчика, увеличивается вследствие трех-четырех этапного процесса реализации (эксперт-аналитики-тимлид-проектировщики) nvb>4. Вследствие того, что программисты-исполнители не участвуют и не хотят участвовать в создании модели, есть риск возникновения проблем с реализацией этой модели.
nvb>Это все? Можно дополнить.
2) —
1)Нет, проблема не в переводе аналитика. Все таки дело в том что аналитик один не может полностью спроектировать модель без участи разработчиков (в частиности проэктировщиков, тимлидов, etс)
3)Да, самое прискорбное
4)Да, но чаще рядовые программисты исполнители редко имеют большое значение. Скорее речь о сеньер девелоперах, которые реализуют базовую часть приложения: модель, инфраструктуру.
nvb>Теперь давайте попробуем реализовать эту модель в виде стандартных решений для каждого пункта
nvb>1. Зачем переводить одно английское слово одним русским словом? Переведите десятью, поставьте гипертекстовые ссылки на термины и т.п. В общем, создайте словарь.
На данный момент словарь единственный выход. Так фактически у нас сейчас и есть. nvb>2. Пусть аналитики проведут несколько этапов анализа и синтеза необходимых элементов модели для получения достаточной степени приближения. nvb>3. С этим ничего не поделаешь. Рядовые программисты не могут по умолчанию работать системными аналитиками. Но попробуйте подойти к проблеме с противоположной стороны. Представьте, что все программисты смогли бы это делать. Тогда бы они предпочли только этим и заниматься, откладывая написание кода на потом, пока не нашли бы действительно идеальное решение (к тому же еще и устраивающее их всех). Это ведет к срыву сроков и претензиям заказчика. Сравните с существующей сейчас у Вас и работающей трехступенчатой схемой. Вы все еще уверены, что хотите поменять ее? Как сказали в соседней ветке — посадите рядом десять Линусов Торвальдсов и получите такую массу проблем, что Вам и не снилась
Нет, я не говорю о всех программистах ) В этом естественно нет смысла
Речь о тех кто реализуют базовую часть приложения: модель, инфраструктуру. А рядовые программисты иногда активно против вникания в это все.
nvb>4. Вот тут уже труднее. Посоветовать ничего не могу – сильно зависит от конкретных людей и организации. Можно тянуть за уши к свету всех на тренингах и совещаниях, можно не всех, а только тимлидов или старших программистов. Можно декомпозировать модель до уровня, касающегося непосредственно исполнителей и предложить им самим декомпозировать дальше. Можно хотя бы попросить документировать проблемы, которые они видят при реализации этой модели (охаять чужое творение всякий рад ) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3,
На данный момент наверное это первый более или менее командный проект у нас. Командная сплоченность проблема, и скорее всего мы прибегаем к плотной декомпозиции. Каждый знает только о том что пишет.
nvb>Конечно, я не верю в то, что это все — в яблочко, и поможет вот прямо завтра решить все проблемы Это всего лишь иллюстрация того, каким путем можно пойти.
=^__^=
На данный момент, так как мы не используем Domain Driven Design как таковой, вышеприведенные решения которые приняты у нас работают. Просто, в связи изучением книг по данной практике разработки и дизайна, хотелось знать что делают те кто придерживаются этой практики
Сейчас, используя Data Driven Design, модель имеет более 100 сущностей (исключительно анемичных, использующихся для передачи данных). При этом модель постоянно совершенствуется. Используется словарь терминов (в виде двух человек у который можно уточнить соответсвие терминов в ТЗ, с моделью %)), а так всего один человек как связка между разработчиками и бизнес экспертами заказчика. Плюсом у нас то что, аналитик занимается так же проектированием, и не далек от кода. Минус — он не один проектирует, и это все ведет к "эксперт-аналитики-проектировщики".
Здравствуйте, Saddo, Вы писали:
S>На данный момент, так как мы не используем Domain Driven Design как таковой, вышеприведенные решения которые приняты у нас работают. Просто, в связи изучением книг по данной практике разработки и дизайна, хотелось знать что делают те кто придерживаются этой практики
S>Сейчас, используя Data Driven Design, модель имеет более 100 сущностей (исключительно анемичных, использующихся для передачи данных). При этом модель постоянно совершенствуется. Используется словарь терминов (в виде двух человек у который можно уточнить соответсвие терминов в ТЗ, с моделью %)), а так всего один человек как связка между разработчиками и бизнес экспертами заказчика. Плюсом у нас то что, аналитик занимается так же проектированием, и не далек от кода. Минус — он не один проектирует, и это все ведет к "эксперт-аналитики-проектировщики".
Я все пытаюсь убрать лишнюю сущность, а Вы опять пытаетесь ее добавить
Да, проблема вполне понятна. В Вашей компании хотят перейти от DataDD к DomainDD. Для этого необходимо перенести фокус внимания возможно большего числа членов команды с уровня реализации хотя бы на уровень модели, потому что это — ключевая точка для перехода. В первую очередь это касается сеньоров и тимлидов, потому что без них переход не удастся осуществить в принципе. Так?
Вы в первоначальном посте изложили проблемы, которые встали перед компанией или проектом при этом переходе. Эти проблемы не являются особенностью DomainDD. Любой руководитель проекта, если у него есть голова на плечах, заботится о том, чтобы команда проекта видела задачу (в Вашем случае — модель) в целом и согласовывала свою работу с этим видением. При необходимости его корректируя. Это повышает мотивацию на результат, снижает риски — в общем, сплошные плюсы, откуда не взгляни. Если же в проекте таких людей мало — то эти люди становятся перегружены со всеми вытекающими, что ведет к необходимости введения дополнительных уровней иерархии.. ну и так далее.
А теперь скажите — решение перечисленных и поправленных Вами 4-х пунктов реально приблизит Вашу компанию к переходу на DomainDD?
И что с того, что они являются общими для всех проектов? Или Вы ищете "Пятый элемент", специфичный для DomainDD, с помощью которого удастся обойтись без решения этих пунктов? Или хотя бы имеющий большее значение, чем эти четыре?
nvb>Да, проблема вполне понятна. В Вашей компании хотят перейти от DataDD к DomainDD. Для этого необходимо перенести фокус внимания возможно большего числа членов команды с уровня реализации хотя бы на уровень модели, потому что это — ключевая точка для перехода. ... nvb>... Эти проблемы не являются особенностью DomainDD. ... nvb>А теперь скажите — решение перечисленных и поправленных Вами 4-х пунктов реально приблизит Вашу компанию к переходу на DomainDD? nvb>И что с того, что они являются общими для всех проектов? Или Вы ищете "Пятый элемент", специфичный для DomainDD, с помощью которого удастся обойтись без решения этих пунктов? Или хотя бы имеющий большее значение, чем эти четыре?
Разве в "management" общаются на религиозные темы?
Здравствуйте, nvb, Вы писали:
nvb> В Вашей компании хотят перейти от DataDD к DomainDD.
Каша какая-то... Причем здесь DDD?
По описанию Agile vs RUP-какой-нибудь, что ортогонально тому, какая архитектура у проекта.
В случае Agile заказчик сам вовлекается в процесс разработки, что, по идее, убирает завязанность на аналитика. С другой стороны, с точки зрения здравого смысла — это полная фигня, так как пока нет одного человека, который четко скажет "заказчик на самом деле имел ввиду вот это", будет полный бардак. И не важно кто этим человеком будет — аналитик или представитель заказчика.
И, еще раз — это все имеет весьма опосредованное отношение к архитектуре, хотите писать в терминах заказчика — создавайте соответсвующий DSL и вперед. Никакая объектная модель, будь она хоть сто раз Domain Driven, не уберет разницу между реальной предметной областью и вашим представлением о ней.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, nvb, Вы писали:
nvb>> В Вашей компании хотят перейти от DataDD к DomainDD. IB>Каша какая-то... Причем здесь DDD? IB>По описанию Agile vs RUP-какой-нибудь, что ортогонально тому, какая архитектура у проекта.
Фраза вроде бы правильная, даже возразить нечего... и что?
IB>В случае Agile заказчик сам вовлекается в процесс разработки, что, по идее, убирает завязанность на аналитика. С другой стороны, с точки зрения здравого смысла — это полная фигня, так как пока нет одного человека, который четко скажет "заказчик на самом деле имел ввиду вот это", будет полный бардак. И не важно кто этим человеком будет — аналитик или представитель заказчика.
Даже отвечать не буду на это утверждение — ответят и без меня Что сейчас начнется — подумать страшно...
IB>И, еще раз — это все имеет весьма опосредованное отношение к архитектуре, хотите писать в терминах заказчика — создавайте соответсвующий DSL и вперед. Никакая объектная модель, будь она хоть сто раз Domain Driven, не уберет разницу между реальной предметной областью и вашим представлением о ней.
А вот эту фразу лучше было написать в ответ на первоначальный вопрос Ибо здесь уже идет разговор о том, что проблема кроется, как всегда, в людях, а не в процессах.
Здравствуйте, Saddo, Вы писали:
S>Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области.
Я сейчас ужасную крамолу скажу. В общем случае, представления разных людей об одной и той же предметной области не совпадают. Для любой сложной системы, предметная область зависит от точки зрения. Возьмем, к примеру, морской порт. Логистики воспринимают его в теринах грузопотоков и хранилищ. Инженеры, воспринимают его в терминах сооружений и механизмов. Бухгалтера -- в терминах прихода и расхода. Служба безопасности, юридическая служба, профсоюз грузчиков, экологи, даже портовые крысы -- все они воспринимают одни и те же объекты с разных точек зрения.
У программистов ровно то же самое. Чем сложнее проект, тем больше различие в точках зрения.
S>Как эти проблемы решается в других компаниях?
Я знаю два варианта.
1. Программисты становятся экспертами в предметной области. По крайней мере те, которые занимаются проектированием. Решается посредством обучения. Дорого, эффективно, распространено.
2. Составляется онтология предметной области, сводящая воедино разные точки зрения. Т.е. явно показывающая, что кран бухгалтера и кран инженера это один и тот же объект, но их точки зрения на него отличаются такими-то аспектами. Сложно, дорого, нераспространено.
Здравствуйте, nvb, Вы писали:
nvb>Фраза вроде бы правильная, даже возразить нечего... и что?
И все. Вы разберитесь сначала о чем речь, об Agile или о DDD.
Здравствуйте, IB, Вы писали:
nvb>>Фраза вроде бы правильная, даже возразить нечего... и что? IB>И все. Вы разберитесь сначала о чем речь, об Agile или о DDD.
Других вариантов нет? "Вы подпишете это договор сейчас или вечером?"
Мне-то это зачем? Я писал, что проблемы общие, независимо от названия процесса. И Вы, кстати, тоже, хотя и про другие проблемы.
А доказывать тут, что это ни разу не Agile и Agile не станет — мне время жалко, бодяга на десять постов растянется
Здравствуйте, nvb, Вы писали:
nvb>Других вариантов нет? "Вы подпишете это договор сейчас или вечером?"
Других нет, если конечно хочется до чего-то договориться, а не просто так потрындеть. В последнем случае действительно пофиг о чем.
nvb>Мне-то это зачем?
То есть, тебе все равно о чем речь, все равно про свое напишешь? Нормальный подход =)
nvb>Я писал, что проблемы общие, независимо от названия процесса.
А я писал, что DDD к этим проблемам не имеет никакого отношения.
Здравствуйте, IB, Вы писали:
nvb>>Других вариантов нет? "Вы подпишете это договор сейчас или вечером?" IB>Других нет, если конечно хочется до чего-то договориться, а не просто так потрындеть. В последнем случае действительно пофиг о чем.
Договориться до чего? Заставить тебя признать мою точку зрения на название процесса? Учитывая твой опыт, у меня это займет очень много времени и усилий, с совершенно негарантированным результатом А если учесть, что топикстартер наверняка описал свой процесс не исчерпывающе, то и вовсе смешно получается.
nvb>>Мне-то это зачем? IB>То есть, тебе все равно о чем речь, все равно про свое напишешь? Нормальный подход =)
Я дал совет, исходя из вопросов. Если человек пошел на красный свет и его сбила машина, то причина этого — в неправильном переходе улицы, а не в марке машины. Марка тоже, конечно имеет значение, но она вторична. Процесс разработки вторичен в данной ситуации. Ну хорошо, я заявляю, что считаю процесс тяжелым, типа RUP. Что изменилось? Ничего. Теперь примем твою (?)точку зрения — это Agile. Что изменилось? Пока тимлиды с сеньорами будут класть на архитектуру (модель), в разработке по обоим процессам будут проблемы. Пока нет единой терминологии (словаря) для заказчиков и исполнителей — будут проблемы.
nvb>>Я писал, что проблемы общие, независимо от названия процесса. IB>А я писал, что DDD к этим проблемам не имеет никакого отношения.
Иван, я читал твои статьи и осознаю, что в процессах разработки ПО ты разбираешься лучше меня, но, похоже, ты сегодня не с той ноги встал
nvb>Теперь примем твою (?)точку зрения — это Agile. Что изменилось? Пока тимлиды с сеньорами будут класть на архитектуру (модель), в разработке по обоим процессам будут проблемы. Пока нет единой терминологии (словаря) для заказчиков и исполнителей — будут проблемы.
nvb>>>Я писал, что проблемы общие, независимо от названия процесса. IB>>А я писал, что DDD к этим проблемам не имеет никакого отношения.
В проектной группе обычно не только разработчики. А всем остальным, кроме разработчиков, на архитектуру совершенно обоснованно насрать.
Архитектура с процессом очень мало связаны.
Ты в этом форуме, потому что тебя интересует управление, а значит архитектура приплетена совершенно зря. Иначе все дружно перемещаемся в DESIGN.
Здравствуйте, VGn, Вы писали:
nvb>>Теперь примем твою (?)точку зрения — это Agile. Что изменилось? Пока тимлиды с сеньорами будут класть на архитектуру (модель), в разработке по обоим процессам будут проблемы. Пока нет единой терминологии (словаря) для заказчиков и исполнителей — будут проблемы.
nvb>>>>Я писал, что проблемы общие, независимо от названия процесса. IB>>>А я писал, что DDD к этим проблемам не имеет никакого отношения.
VGn>В проектной группе обычно не только разработчики. А всем остальным, кроме разработчиков, на архитектуру совершенно обоснованно насрать.
Угу. Всем. Включая РMа с аналитиками. И тестлида А вообще, это печально, потому что в большинстве проектов это действительно так.
VGn>Архитектура с процессом очень мало связаны. VGn>Ты в этом форуме, потому что тебя интересует управление, а значит архитектура приплетена совершенно зря. Иначе все дружно перемещаемся в DESIGN.
А можно мы сами решим? Ну пожаааалуйста...
Архитектура тут совершенно не при чем, непонятно, почему ты решил, что я на ней фокусируюсь. Я писал про отношение лидов к принятию архитектурных решений, какие бы ни были эти решения и какой бы не был процесс разработки.
А вообще я заканчиваю с этой веткой, поскольку мы ушли далеко в сторону и дальнейшее топикстартеру, думаю, уже неинтересно, а меряться, у кого интеллект длиннее — времени жаль.
Здравствуйте, Saddo, Вы писали:
S>Как эти проблемы решается в других компаниях?
Есть сложная методика, которая применяется во многих компаниях уже десятки лет, и неплохо себя зарекомендовала. Она состоит в соблюдении двух сложных правил.
1) Программист берет книгу о предметной области, и внимательно ее читает. Например. Если программист занимается автоматизацией бухгалтерии — он должен знать основы бухучета. Если он пишет софт для трейдеров — он изучает пару учебников для трейдеров. Если он занимается колл-центрами — он читает книгу про коллцентры. Это очень необычный и смелый ход — вот так просто взять, и изучить терминологию предметной области, я понимаю, однако во всех компаниях, где я работал, люди поступали именно так.
2) Очень важно делать пункт (1), читая книги по предметной области ВМЕСТО книг по DDD. Это очень сложно, но совершенно необходимо. В сочетании с первым пунктом, это правило практически гарантирует а) огромную экономию времени, б) полное отсутствие указанных проблем, и в) отсутствие потребности в переводчиках с русского на русский.
> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.
Здравствуйте, Gaperton, Вы писали:
S>>Как эти проблемы решается в других компаниях?
G>Есть сложная методика, которая применяется во многих компаниях уже десятки лет, и неплохо себя зарекомендовала. Она состоит в соблюдении двух сложных правил. G>1) Программист берет книгу о предметной области, и внимательно ее читает. Например. Если программист занимается автоматизацией бухгалтерии — он должен знать основы бухучета. Если он пишет софт для трейдеров — он изучает пару учебников для трейдеров. Если он занимается колл-центрами — он читает книгу про коллцентры. Это очень необычный и смелый ход — вот так просто взять, и изучить терминологию предметной области, я понимаю, однако во всех компаниях, где я работал, люди поступали именно так. G>2) Очень важно делать пункт (1), читая книги по предметной области ВМЕСТО книг по DDD. Это очень сложно, но совершенно необходимо. В сочетании с первым пунктом, это правило практически гарантирует а) огромную экономию времени, б) полное отсутствие указанных проблем, и в) отсутствие потребности в переводчиках с русского на русский.
А еще надо программеров научить вначале строить модели, а потом писать код. А еще надо их научить сообщать о проблемах, когда они еще риски, а не проблемы. А еще... ну, понятно, я думаю.
И ведь пользы от предложенных вариантов будет не меньше, чем от изучения предметной области... хотя кто измерит
Но ведь суть-то в том, что программисты — люди, и поддаются изменениям, навязываемым извне, с большим трудом. Это будет действительно здорово, когда программер начинает читать книги по предметной области, ибо он делает первый шаг к тому, чтобы стать аналитиком. Почти любая компания, в которой что-то понимают в управлении, готова вбухать немало денег в этот процесс, потому что это — очень выгодные вложения. Увы, бить по площадям (всем программерам) — слишком дорого, вследствие малого КПД, поэтому обычно ограничиваются лидами — у них КПД выше. Такова жизнь. Большинство программистов в гробу видели эту предметную область, и если их неосторожно пинать на ее изучение — а равно на изучение DDD — они просто уйдут.
>> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
G>Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.
Переводчик с большой охотой сложит с себя полномочия, особенно на время закрытия этапов, когда он работает по 12 часов в день. Конечно, здесь могут присутствовать элементы шантажа, ибо единственному и незаменимому легче просить о повышении зарплаты, но, в общем, переводчики обычно бывают сыты по горло объяснениями по 10 раз каждому программеру, что имеется в виду под той или иной фразой. От конкретного человека зависит, как бы затасканно это не звучало.
В необходимости переводчика присутствуют риски, связанные с его незаменимостью, и, как следствие, перегруженностью. Именно эти риски следует убирать в первую очередь, переводя его работу хотя бы на лидов. Что и пытается сделать автор темы. Не спорю, перенести сразу на программеров — во много раз лучше, но во столько же раз дольше, дороже и рискованнее.
А от DDD зачем избавляться? Он здесь совершенно не при чем. Ну хочется человеку поиграться с новым процессом — пускай, если условия позволяют. Уже в третий раз пишу: возьмите любой другой процесс — проблемы останутся те же.
Здравствуйте, nvb, Вы писали:
G>>Есть сложная методика, которая применяется во многих компаниях уже десятки лет, и неплохо себя зарекомендовала. Она состоит в соблюдении двух сложных правил. G>>1) Программист берет книгу о предметной области, и внимательно ее читает. Например. Если программист занимается автоматизацией бухгалтерии — он должен знать основы бухучета. Если он пишет софт для трейдеров — он изучает пару учебников для трейдеров. Если он занимается колл-центрами — он читает книгу про коллцентры. Это очень необычный и смелый ход — вот так просто взять, и изучить терминологию предметной области, я понимаю, однако во всех компаниях, где я работал, люди поступали именно так. G>>2) Очень важно делать пункт (1), читая книги по предметной области ВМЕСТО книг по DDD. Это очень сложно, но совершенно необходимо. В сочетании с первым пунктом, это правило практически гарантирует а) огромную экономию времени, б) полное отсутствие указанных проблем, и в) отсутствие потребности в переводчиках с русского на русский.
nvb>А еще надо программеров научить вначале строить модели, а потом писать код. А еще надо их научить сообщать о проблемах, когда они еще риски, а не проблемы. А еще... ну, понятно, я думаю.
nvb>И ведь пользы от предложенных вариантов будет не меньше, чем от изучения предметной области... хотя кто измерит
Разумеется меньше, если их противопоставлять изучению предметной области. От одного изучения оной + сокращения цепочки коммуникации будет заметный и быстрый, качественный эффект. Существенно превышающий эффект от перечисленного, если оно будет делаться _вместо_ изучения предметной области. Ибо понимание предметной области — the must, оно фундаментально, а остальное на самом деле рюшечки и оборочки. Можно, скажем, вовсе не строить моделей, а грамотно двигаться короткими итерациями. При адекватном инструменте и задаче может получиться не хуже, а лучше.
Меня вообще изумляет, что сейчас это является предметом дискуссий. Раньше, лет 10 назад, до появления дикого хайпа вокруг "методик", это как-то всем казалось очевидным.
nvb>Но ведь суть-то в том, что программисты — люди, и поддаются изменениям, навязываемым извне, с большим трудом. Это будет действительно здорово, когда программер начинает читать книги по предметной области, ибо он делает первый шаг к тому, чтобы стать аналитиком.
Правда? Это теперь так называется? "Изменения, навязанные извне"? "первый шаг к тому, чтобы стать аналитиком"? Это ничего, что, скажем, у нас в CQG не было аналитиков, и каждый инженер первым делом _сам_, без понуканий, разбирался в основах биржевой торговли без цели стать каким-то дебильным "аналитиком"? Это что, становится сейчас нормальным — работать программистом над, скажем, софтом для трейдеров, не имея элементарного понятия о том, что такое "фьючерс" или "опцион"? А программисту работающему над бухгалтерским пакетом — теперь стало нормально не знать, как сводится балланс, да? Две недели влом потратить на чтение книги после найма, рассчитанной на первокурсника, я не пойму?
nvb>Почти любая компания, в которой что-то понимают в управлении, готова вбухать немало денег в этот процесс, потому что это — очень выгодные вложения. Увы, бить по площадям (всем программерам) — слишком дорого, вследствие малого КПД, поэтому обычно ограничиваются лидами — у них КПД выше. Такова жизнь.
"Жизнь такова"? Вы меня изумляете. Я не знаю, в каком бизнесе вы работаете, если элементарное ознакомление программистов с предметной областью для вас "дорого", а внедрять процессы — "дешево". Вот честно.
nvb>Большинство программистов в гробу видели эту предметную область, и если их неосторожно пинать на ее изучение — а равно на изучение DDD — они просто уйдут.
Большинство тех программистов, кого я знаю — не видели это в гробу, а напротив — весьма живо этим интересуются. С точки зрения _всего_ моего опыта — вы рассказываете про какое-то зазеркалье.
>>> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
G>>Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.
nvb>Переводчик с большой охотой сложит с себя полномочия, особенно на время закрытия этапов, когда он работает по 12 часов в день. nvb>Конечно, здесь могут присутствовать элементы шантажа, ибо единственному и незаменимому легче просить о повышении зарплаты, но, в общем, переводчики обычно бывают сыты по горло объяснениями по 10 раз каждому программеру, что имеется в виду под той или иной фразой. От конкретного человека зависит, как бы затасканно это не звучало.
Переводчик, разумеется, не будет складывать с себя полномочий. Все стремятся сохранить статус кво, и достаточно редко бывает такое, что человек согласен на ликвидацию должности которую занимает.
И, кстати, мне не вполне понятно, откуда у него возьмется нагрузка по 12 часов в день на закрытии этапов. Это весьма расслабленный период, ибо требования обычно идентифицируются в начале работы, а не в конце. Или мы говорим об особом типе проектов, в которых все наоборот?
nvb>В необходимости переводчика присутствуют риски, связанные с его незаменимостью, и, как следствие, перегруженностью. Именно эти риски следует убирать в первую очередь, переводя его работу хотя бы на лидов. Что и пытается сделать автор темы. Не спорю, перенести сразу на программеров — во много раз лучше, но во столько же раз дольше, дороже и рискованнее.
Риски тут вторичны. Корень проблемы не в рисках. Лишнее звено в коммуникации способствует искажению информации, и замедлению обмена этой информацией. И все. Особенно, если звено перегружено — искажений будет гораздо больше, причем, это незаметно и трудноуловимо, выяснять вы это будете именно на сдаче. Причем, вместо того, чтобы устранить звено вместе с проблемой, во многих аналогичных случаях принимаются дорогие и неэффективные меры по "налаживанию процесса", которые еще больше понизят КПД.
А лиды они на то и лиды, чтобы очень хорошо разбираться в предметной области.
nvb>А от DDD зачем избавляться? Он здесь совершенно не при чем. Ну хочется человеку поиграться с новым процессом — пускай, если условия позволяют. Уже в третий раз пишу: возьмите любой другой процесс — проблемы останутся те же.
Процесс здесь очень даже причем. Человек сместил фокус с проблемы, и непосредственного восприятия действительности, на "процесс", глядя на реальность через его "призму", существенно снизив собственные шансы докопаться до природы проблемы, и ее исправления. Все потому, что придает ему слишком большое значение. Тут я, разумеется, догадываюсь, может быть, он на самом деле вовсе не придает ему большого значения. Но мне пока кажется так.
Здравствуйте, Gaperton, Вы писали:
nvb>>А еще надо программеров научить вначале строить модели, а потом писать код. А еще надо их научить сообщать о проблемах, когда они еще риски, а не проблемы. А еще... ну, понятно, я думаю.
nvb>>И ведь пользы от предложенных вариантов будет не меньше, чем от изучения предметной области... хотя кто измерит
G>Разумеется меньше, если их противопоставлять изучению предметной области. От одного изучения оной + сокращения цепочки коммуникации будет заметный и быстрый, качественный эффект. Существенно превышающий эффект от перечисленного, если оно будет делаться _вместо_ изучения предметной области. Ибо понимание предметной области — the must, оно фундаментально, а остальное на самом деле рюшечки и оборочки.
А мы по определению все противопоставляем. Потому что программер либо кодит, либо изучает предметную область, либо что-то еще. И надо выбирать, какая комбинация и в какой пропорции даст лучший эффект. Это и есть мастерство руководителя — не все, но немалая его часть.
G>Можно, скажем, вовсе не строить моделей, а грамотно двигаться короткими итерациями. При адекватном инструменте и задаче может получиться не хуже, а лучше.
Это только на малых проектах, преимущественно продуктовых. Возьмем заказной проект в 50 человеко-лет — в продвинутых компаниях понимают, что нельзя сразу начинать итерации, там вначале модель строят, согласуют ее с заказчиком — не начинающие программеры, разумеется — и только после этого приступают к ее реализации. Лучше, действительно, итерациями.
nvb>>Но ведь суть-то в том, что программисты — люди, и поддаются изменениям, навязываемым извне, с большим трудом. Это будет действительно здорово, когда программер начинает читать книги по предметной области, ибо он делает первый шаг к тому, чтобы стать аналитиком.
G>Правда? Это теперь так называется? "Изменения, навязанные извне"? "первый шаг к тому, чтобы стать аналитиком"? Это ничего, что, скажем, у нас в CQG не было аналитиков, и каждый инженер первым делом _сам_, без понуканий, разбирался в основах биржевой торговли без цели стать каким-то дебильным "аналитиком"? Это что, становится сейчас нормальным — работать программистом над, скажем, софтом для трейдеров, не имея элементарного понятия о том, что такое "фьючерс" или "опцион"? А программисту работающему над бухгалтерским пакетом — теперь стало нормально не знать, как сводится балланс, да?
Если разработка идет по тяжелым процессам — вполне. Аналитики пишут частные ТЗ и после этого обезьяны начинают кодить. Правильно это, или нет — вопрос второй. Наверное, нет, но множество крупных компаний пока идут по этому пути.
У вас в CQG был свой процесс, в котором упор делался на индивидуальные компетенции. Он доказал свою жизнеспособность, но, наверное, что-то было в нем особенное, что помешало всем остальным компаниям пойти за вами вслед. Полагаю, это были люди, которые ставили этот процесс
G>Две недели влом потратить на чтение книги после найма, рассчитанной на первокурсника, я не пойму?
Не надо добавлять дополнительные условия. Сразу после найма, разумеется, свежеиспеченный выпускник-программер будет читать книжки по предметной области — куда ж ему деваться, бедняге. А вот через пару лет после найма — тут бабушка надвое сказала.
nvb>>Почти любая компания, в которой что-то понимают в управлении, готова вбухать немало денег в этот процесс, потому что это — очень выгодные вложения. Увы, бить по площадям (всем программерам) — слишком дорого, вследствие малого КПД, поэтому обычно ограничиваются лидами — у них КПД выше. Такова жизнь.
G>"Жизнь такова"? Вы меня изумляете. Я не знаю, в каком бизнесе вы работаете, если элементарное ознакомление программистов с предметной областью для вас "дорого", а внедрять процессы — "дешево". Вот честно.
Из каких моих слов сделан вывод про дешевизну внедрения процессов?
Мне кажется, разногласия между нами состоят не в ознакомлении программеров с предметной областью, а в степени ознакомления. Полюса здесь — прочитать трехстраничную статью или прочитать трехтомник, вот и все. Я склоняюсь к статье для программеров и трехтомнику для аналитиков, а Вы — к трехтомнику для всех.
Хотя, повторяю, если программер возьмет в руки трехтомник — это будет очень, очень хорошо.
nvb>>Большинство программистов в гробу видели эту предметную область, и если их неосторожно пинать на ее изучение — а равно на изучение DDD — они просто уйдут.
G>Большинство тех программистов, кого я знаю — не видели это в гробу, а напротив — весьма живо этим интересуются. С точки зрения _всего_ моего опыта — вы рассказываете про какое-то зазеркалье.
Насчет _всего_ — не надо. Мы оба работали в ИТМ, отлично знаем, что там — не так, и вбито это на уровне официально декларированных процессов. Впрочем, это вырожденный случай
>>>> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
G>>>Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.
G>Переводчик, разумеется, не будет складывать с себя полномочий. Все стремятся сохранить статус кво, и достаточно редко бывает такое, что человек согласен на ликвидацию должности которую занимает.
Нет такой должности — переводчик. Эту роль выполняют аналитики, а у них и так работы хватает.
G>И, кстати, мне не вполне понятно, откуда у него возьмется нагрузка по 12 часов в день на закрытии этапов. Это весьма расслабленный период, ибо требования обычно идентифицируются в начале работы, а не в конце. Или мы говорим об особом типе проектов, в которых все наоборот?
Скорее, особые типы проектов — это те, в которых большинство требований идентифицируются в начале проекта. Их число примерно равно проектам, уложившимся в проектный треугольник — не так ли? Какой их процент? По факту, заказчик обычно говорит, что он совсем не то имел в виду, именно в конце этапа, когда увидел релиз. И вот тут аналитик ощущает жизнь во всей ее полноте
Конечно, итерационная разработка позволяет избежать этого, но какой процент компаний работает по тому же Scrum-у?
nvb>>В необходимости переводчика присутствуют риски, связанные с его незаменимостью, и, как следствие, перегруженностью. Именно эти риски следует убирать в первую очередь, переводя его работу хотя бы на лидов. Что и пытается сделать автор темы. Не спорю, перенести сразу на программеров — во много раз лучше, но во столько же раз дольше, дороже и рискованнее.
G>Риски тут вторичны. Корень проблемы не в рисках. Лишнее звено в коммуникации способствует искажению информации, и замедлению обмена этой информацией. И все. Особенно, если звено перегружено — искажений будет гораздо больше, причем, это незаметно и трудноуловимо, выяснять вы это будете именно на сдаче.
А это разве не то, что называется описанием рисков?
G> Причем, вместо того, чтобы устранить звено вместе с проблемой, во многих аналогичных случаях принимаются дорогие и неэффективные меры по "налаживанию процесса", которые еще больше понизят КПД.
По стоимости эти варианты примерно одинаковы, но "устранение звена" эффективнее — если выбирать только из этих двух.
G>А лиды они на то и лиды, чтобы очень хорошо разбираться в предметной области.
Так человек-то пишет, что проблемы есть и с лидами. Ему хочется хотя бы с лидами разобраться, а потом, может быть, и до программеров руки дойдут.
nvb>>А от DDD зачем избавляться? Он здесь совершенно не при чем. Ну хочется человеку поиграться с новым процессом — пускай, если условия позволяют. Уже в третий раз пишу: возьмите любой другой процесс — проблемы останутся те же.
G>Процесс здесь очень даже причем. Человек сместил фокус с проблемы, и непосредственного восприятия действительности, на "процесс", глядя на реальность через его "призму", существенно снизив собственные шансы докопаться до природы проблемы, и ее исправления. Все потому, что придает ему слишком большое значение. Тут я, разумеется, догадываюсь, может быть, он на самом деле вовсе не придает ему большого значения. Но мне пока кажется так.
Повторяю — сам процесс не при чем. Про ненужное смещение фокуса внимания топикстартера — с людей на процесс — согласен. Но это пройдет только со временем, либо целенаправленным воспитанием его вышестоящими товарищами (именно товарищами)
nvb>У вас в CQG был свой процесс, в котором упор делался на индивидуальные компетенции. Он доказал свою жизнеспособность, но, наверное, что-то было в нем особенное, что помешало всем остальным компаниям пойти за вами вслед. Полагаю, это были люди, которые ставили этот процесс
Обычно "не очень хорошие" менеджеры замыкают комепетенцию на себя, а программистов нанимают "чтобы подешевле". Это происходит обычно не из-за какого-то злого умысла, а просто потому что подругому не умеют. И во "всех остальных" таких бОльшая часть.
nvb>Не надо добавлять дополнительные условия. Сразу после найма, разумеется, свежеиспеченный выпускник-программер будет читать книжки по предметной области — куда ж ему деваться, бедняге. А вот через пару лет после найма — тут бабушка надвое сказала.
Через пару лет должно быть то же самое, если конечно специалист не "в лес смотрит", а это уже вопрос мотивации.
nvb>Скорее, особые типы проектов — это те, в которых большинство требований идентифицируются в начале проекта. Их число примерно равно проектам, уложившимся в проектный треугольник — не так ли? Какой их процент? По факту, заказчик обычно говорит, что он совсем не то имел в виду, именно в конце этапа, когда увидел релиз. И вот тут аналитик ощущает жизнь во всей ее полноте nvb>Конечно, итерационная разработка позволяет избежать этого, но какой процент компаний работает по тому же Scrum-у?
Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?
Здравствуйте, VGn, Вы писали:
nvb>>У вас в CQG был свой процесс, в котором упор делался на индивидуальные компетенции. Он доказал свою жизнеспособность, но, наверное, что-то было в нем особенное, что помешало всем остальным компаниям пойти за вами вслед. Полагаю, это были люди, которые ставили этот процесс
VGn>Обычно "не очень хорошие" менеджеры замыкают комепетенцию на себя, а программистов нанимают "чтобы подешевле". Это происходит обычно не из-за какого-то злого умысла, а просто потому что подругому не умеют. И во "всех остальных" таких бОльшая часть.
Это только до времени сдачи своего первого проекта. Потом они прозревают — если, конечно, в компании по окончании проекта предусмотрен разбор полетов и по его итогам — морковка, спереди или сзади. Либо переходят в другую компанию, с прежними убеждениями, как непонятые гении
nvb>>Не надо добавлять дополнительные условия. Сразу после найма, разумеется, свежеиспеченный выпускник-программер будет читать книжки по предметной области — куда ж ему деваться, бедняге. А вот через пару лет после найма — тут бабушка надвое сказала.
VGn>Через пару лет должно быть то же самое, если конечно специалист не "в лес смотрит", а это уже вопрос мотивации.
"Честные люди должны получать достойную зарплату а воры должны сидеть в тюрьме" — утверждение из той же оперы. Да, согласен, но редко встречал на практике. Может быть, мне в жизни не повезло
nvb>>Скорее, особые типы проектов — это те, в которых большинство требований идентифицируются в начале проекта. Их число примерно равно проектам, уложившимся в проектный треугольник — не так ли? Какой их процент? По факту, заказчик обычно говорит, что он совсем не то имел в виду, именно в конце этапа, когда увидел релиз. И вот тут аналитик ощущает жизнь во всей ее полноте nvb>>Конечно, итерационная разработка позволяет избежать этого, но какой процент компаний работает по тому же Scrum-у?
VGn>Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?
Это хорошо подходит для продуктовых проектов, в заказной разработке сложнее — обычно из-за неопределенности в контракте процесса внесения изменений в требования. И, как следствие, в сроки и цену — контракт-то подписан ДО прототипирования. А вообще — никто не мешает, конечно. Есть еще множество способов избежать вышеописанного геморроя. Но почему-то их не используют и проекты проваливаются.
Здравствуйте, nvb, Вы писали:
VGn>>Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?
nvb>Это хорошо подходит для продуктовых проектов, в заказной разработке сложнее — обычно из-за неопределенности в контракте процесса внесения изменений в требования. И, как следствие, в сроки и цену — контракт-то подписан ДО прототипирования. А вообще — никто не мешает, конечно. Есть еще множество способов избежать вышеописанного геморроя. Но почему-то их не используют и проекты проваливаются.
Если при заказной разработке в условиях неопределенности не сделать прототипа, не управлять требованиями и не получать обратной связи, все вылетит в трубу еще быстрее и вернее, чем при продуктовой. И никакие мЕтОдОлОгИи не помогут, если этого не делать. Природу не обманешь.
Насчет изменений в тьребованиях. Процесс внесения изменений в требования в контракт не вносится, потому как достаточно четко определен в ЕСПД (ГОСТ 19). Достаточно в договоре прописать ссылки на него. Более того, в контракте можно не прописывать сумму, она, так же как состав, сроки, и стоимость этапов, является частью ТЗ, процедура изменения которого определена. Более того, сроки и стоимость этапов (но не их состав) могут быть вынесены в отдельный документ — "ведомость исполнения" или "план-график", которые править еще легче.
И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.
Насчет множества способов избежать вышеописанного геморроя — их все-таки не множество, а ровно два. Прототипы и ранняя обратная связь за счет укорачивания цикла разработки и "итеративности", и второй — анализ требований, что что полагается на внутреннюю экспертизу в предметной области. Все, ничего радикально другого человечество не придумало, все остальное — частности и вариации. И знаете, их очень многие используют, и проекты не проваливаются. Некоторые даже не стесняются использовать комбинацию этих способов .
Здравствуйте, Gaperton, Вы писали:
VGn>>>Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?
nvb>>Это хорошо подходит для продуктовых проектов, в заказной разработке сложнее — обычно из-за неопределенности в контракте процесса внесения изменений в требования. И, как следствие, в сроки и цену — контракт-то подписан ДО прототипирования. А вообще — никто не мешает, конечно. Есть еще множество способов избежать вышеописанного геморроя. Но почему-то их не используют и проекты проваливаются.
G>Если при заказной разработке в условиях неопределенности не сделать прототипа, не управлять требованиями и не получать обратной связи, все вылетит в трубу еще быстрее и вернее, чем при продуктовой. И никакие мЕтОдОлОгИи не помогут, если этого не делать. Природу не обманешь.
Я постоянно открещиваюсь от методологий, а мне их с упорством приписывают
G>Насчет изменений в тьребованиях. Процесс внесения изменений в требования в контракт не вносится, потому как достаточно четко определен в ЕСПД (ГОСТ 19). Достаточно в договоре прописать ссылки на него.
Подскажите, в каком ГОСТе это есть, очень интересно. Все контракты, что проходили через меня, обычно ограничивались фразой типа "Изменение Заказчиком требований оформляется дополнительным соглашением Сторон с приложением протокола контрактной цены, которые с момента их подписания являются неотъемлемой частью настоящего контракта. Объем доптребований и цена контракта не могут быть изменены более чем на хх %". Говоря коротко — только через допсоглашение.
G> Более того, в контракте можно не прописывать сумму, она, так же как состав, сроки, и стоимость этапов, является частью ТЗ, процедура изменения которого определена. Более того, сроки и стоимость этапов (но не их состав) могут быть вынесены в отдельный документ — "ведомость исполнения" или "план-график", которые править еще легче.
Э.. Я сейчас подумал — может я чего забыл, и просмотрел ГОСТ на ТЗ. Как ни странно, ничего нового не обнаружил. Допускается в ТЗ вводить пункт "Стадии и этапы разработки", это да, но умные люди так обычно не поступают, во всяком случае — дважды, поскольку пересогласовать ТЗ на нескольких десятках страниц — это совсем не то же самое, что пересогласовать ведомость исполнения на двух страницах. Ведомость как была приложением к контракту, так и осталась. Про нее никакого упоминания в 201 ГОСТе нет. Да и с точки зрения здравого смысла, это логично — срыв сроков не должен приводить к переделке ТЗ. ТЗ — обычно приложение №1 к контракту, ведомость исполнения — приложение №2.
Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.
G>И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.
Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов
G>Насчет множества способов избежать вышеописанного геморроя — их все-таки не множество, а ровно два. Прототипы и ранняя обратная связь за счет укорачивания цикла разработки и "итеративности", и второй — анализ требований, что что полагается на внутреннюю экспертизу в предметной области. Все, ничего радикально другого человечество не придумало, все остальное — частности и вариации. И знаете, их очень многие используют, и проекты не проваливаются. Некоторые даже не стесняются использовать комбинацию этих способов .
Ну я же написал третий, и думаю, что не последний Не всегда возможна итеративность — если система сложная, первая итерация появится не скоро — и не всегда возможна экспертиза — если компания лезет в новую для себя (или вообще для человечества) прикладную область. Хотя для 95% проектов, согласен, более чем достаточна вышеописанная комбинация. Я-то писал, что беда в том, что она не всегда применяется.
G>>Насчет изменений в тьребованиях. Процесс внесения изменений в требования в контракт не вносится, потому как достаточно четко определен в ЕСПД (ГОСТ 19). Достаточно в договоре прописать ссылки на него.
nvb>Подскажите, в каком ГОСТе это есть, очень интересно. Все контракты, что проходили через меня, обычно ограничивались фразой типа "Изменение Заказчиком требований оформляется дополнительным соглашением Сторон с приложением протокола контрактной цены, которые с момента их подписания являются неотъемлемой частью настоящего контракта. Объем доптребований и цена контракта не могут быть изменены более чем на хх %". Говоря коротко — только через допсоглашение.
G>> Более того, в контракте можно не прописывать сумму, она, так же как состав, сроки, и стоимость этапов, является частью ТЗ, процедура изменения которого определена. Более того, сроки и стоимость этапов (но не их состав) могут быть вынесены в отдельный документ — "ведомость исполнения" или "план-график", которые править еще легче.
nvb>Э.. Я сейчас подумал — может я чего забыл, и просмотрел ГОСТ на ТЗ. Как ни странно, ничего нового не обнаружил. Допускается в ТЗ вводить пункт "Стадии и этапы разработки", это да, но умные люди так обычно не поступают, во всяком случае — дважды, поскольку пересогласовать ТЗ на нескольких десятках страниц — это совсем не то же самое, что пересогласовать ведомость исполнения на двух страницах. Ведомость как была приложением к контракту, так и осталась. Про нее никакого упоминания в 201 ГОСТе нет. Да и с точки зрения здравого смысла, это логично — срыв сроков не должен приводить к переделке ТЗ. ТЗ — обычно приложение №1 к контракту, ведомость исполнения — приложение №2.
nvb>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.
Бывает ещё одностраничный документ "Этапная программа". Обычно так деньги проще всего по кусочкам выскребать . Военка кстати так и работает.
nvb>Ну я же написал третий, и думаю, что не последний Не всегда возможна итеративность — если система сложная, первая итерация появится не скоро — и не всегда возможна экспертиза — если компания лезет в новую для себя (или вообще для человечества) прикладную область. Хотя для 95% проектов, согласен, более чем достаточна вышеописанная комбинация. Я-то писал, что беда в том, что она не всегда применяется.
В таких случаях итеративность возможна на отдельных фазах.
А вообще не плохо бы тогда не пропускать фазы по ГОСТу: бумага
Здравствуйте, VGn, Вы писали:
nvb>>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.
VGn>Бывает ещё одностраничный документ "Этапная программа". Обычно так деньги проще всего по кусочкам выскребать . Военка кстати так и работает.
Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.
Да и деньги по кусочкам очень даже неплохо выскребать через ведомость исполнения — разбить работы на этапы и прописать цену каждого этапа. Правда, в этом случае появляются дополнительные накладные расходы на закрытие каждого этапа, связанные с рожанием определенного количества бумаг.
Можно получить описание этого документа — ссылку или что-то еще?
Здравствуйте, nvb, Вы писали:
nvb>Здравствуйте, VGn, Вы писали:
nvb>>>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.
VGn>>Бывает ещё одностраничный документ "Этапная программа". Обычно так деньги проще всего по кусочкам выскребать . Военка кстати так и работает.
nvb>Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.
nvb>Да и деньги по кусочкам очень даже неплохо выскребать через ведомость исполнения — разбить работы на этапы и прописать цену каждого этапа. Правда, в этом случае появляются дополнительные накладные расходы на закрытие каждого этапа, связанные с рожанием определенного количества бумаг.
nvb>Можно получить описание этого документа — ссылку или что-то еще?
Сссылку не дам. Но где-то видел.
Описание простое:
Таблица работ, планируемых на этап со стоимостью.
Обычно на одном листке A5 умещается, включая печати и подписи.
Для военных заказов прокатывала даже этапная программа, заверенная и присланная заказчиком по факсу.
Обычно подписывается после получения денег за прошлый этап.
Так всем спокойнее.
В космических изделиях неопределённость со стоимостью и сроками практически такая же, как и в разработке ПО, включая то же самое и относительно подрядчиков.
nvb>Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.
Много видел в интернете военных контрактов?
Там же гриф минимум "конфиденциально".
Здравствуйте, nvb, Вы писали:
nvb>Подскажите, в каком ГОСТе это есть, очень интересно. Все контракты, что проходили через меня, обычно ограничивались фразой типа "Изменение Заказчиком требований оформляется дополнительным соглашением Сторон с приложением протокола контрактной цены, которые с момента их подписания являются неотъемлемой частью настоящего контракта. Объем доптребований и цена контракта не могут быть изменены более чем на хх %". Говоря коротко — только через допсоглашение.
Ну да, это звучит похоже на правду. Насчет процедуры изменения ТЗ я могу уточнить у нашего гуру по ТЗ. Это и в самом деле интересно.
G>> Более того, в контракте можно не прописывать сумму, она, так же как состав, сроки, и стоимость этапов, является частью ТЗ, процедура изменения которого определена. Более того, сроки и стоимость этапов (но не их состав) могут быть вынесены в отдельный документ — "ведомость исполнения" или "план-график", которые править еще легче.
nvb>Э.. Я сейчас подумал — может я чего забыл, и просмотрел ГОСТ на ТЗ. Как ни странно, ничего нового не обнаружил. Допускается в ТЗ вводить пункт "Стадии и этапы разработки", это да, но умные люди так обычно не поступают, во всяком случае — дважды, поскольку пересогласовать ТЗ на нескольких десятках страниц — это совсем не то же самое, что пересогласовать ведомость исполнения на двух страницах. Ведомость как была приложением к контракту, так и осталась. Про нее никакого упоминания в 201 ГОСТе нет. Да и с точки зрения здравого смысла, это логично — срыв сроков не должен приводить к переделке ТЗ. ТЗ — обычно приложение №1 к контракту, ведомость исполнения — приложение №2.
Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения. Традиция выполнения заказов по линии ФАП/минпромторг, не иначе.
nvb>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.
Общая сумма не появляется, однако по этапам — могут. Я своими глазами видел такое ТЗ, пришедшее из ФАП-а.
G>>И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.
nvb>Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов
Допускается. В случае, когда совсем жопа, ТЗ вообще полагается делать результатом отдельного НИР. И делают. Скажем, ТЗ на новый комплекс ПВО вообще делает отдельный НИИ, сильно напрягая при этом мозк. Также, допускается делать ТЗ результатом первого этапа — такая опция упоминалась, хотя на практике я с таким не сталкивался (а это наиболее интересный вариант). Кстати, это все я видел именно в военном ГОСТе на радиоэлекетронные изделия. И кроме того, ТЗ может быть достаточно общим, дающим большую свободу (может и не быть, но тут уж надо быть аккуратным). Пока не зафиксирована программа и методика испытаний — свобода в выполнении и в трактовке требований есть, и очень большая.
Вообще же уточнение ТЗ на этапе эскизного проекта, как предлагаете вы — это также отличный вариант. Вот видите — все вы знаете лучше меня . Зачем народ пугаете тогда? Можно, можно нормально работать на fixed cost. Руки только в циркулярную пилу совать не надо, и все будет хорошо .
G>>Насчет множества способов избежать вышеописанного геморроя — их все-таки не множество, а ровно два. Прототипы и ранняя обратная связь за счет укорачивания цикла разработки и "итеративности", и второй — анализ требований, что что полагается на внутреннюю экспертизу в предметной области. Все, ничего радикально другого человечество не придумало, все остальное — частности и вариации. И знаете, их очень многие используют, и проекты не проваливаются. Некоторые даже не стесняются использовать комбинацию этих способов .
nvb>Ну я же написал третий, и думаю, что не последний Не всегда возможна итеративность — если система сложная, первая итерация появится не скоро — и не всегда возможна экспертиза — если компания лезет в новую для себя (или вообще для человечества) прикладную область. Хотя для 95% проектов, согласен, более чем достаточна вышеописанная комбинация. Я-то писал, что беда в том, что она не всегда применяется.
Итеративность возможна всегда в том или ином виде. Результат первых итераций не обязан обладать полной функциональностью и быть качественным — это прототип в том или ином виде. Скажем, прототипом микропроцессора является его потактовая модель на обычном языке программирования. Собирается с целью изучения свойств предлагаемых подходов. Цель — это основное, отличает прототип от изделия, остальное частности.
А то, что не всегда применяется — ну так что на это сетовать. Не заставлять же людей, когда они просто не умеют. Я вот, например, уверен, что причина в том, что существующие методические материалы по менеджменту никуда не годятся. Ни к черту.
Здравствуйте, VGn, Вы писали:
nvb>>Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.
VGn>Много видел в интернете военных контрактов? VGn>Там же гриф минимум "конфиденциально".
Название документов перечислено в военном ГОСТ-е, а он вполне может лежать в сети. Документ действительно странный, я тоже никогда не слышал такого термина. С "план-графиком" не перепутал?
Здравствуйте, Gaperton, Вы писали:
G>Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения. Традиция выполнения заказов по линии ФАП/минпромторг, не иначе.
Да тут дело даже и не в удобстве. Если заказчик скажем так, странен, он вполне может вместе с измененным графиком изменить и требования. Я один раз наткнулся на такое — обещали поменять один пункт в ТЗ, а поменяли три, никак об остальных двух не уведомив. Случайно наткнулся, проформы ради листая перед подписанием. Заказчик потом клялся и божился, что это его подчиненные напортачили, безо всякого злого умысла, машинально сохранив изменения, но, как говорится, осадок остался
G>>>И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.
nvb>>Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов
G>Допускается. В случае, когда совсем жопа, ТЗ вообще полагается делать результатом отдельного НИР. И делают. Скажем, ТЗ на новый комплекс ПВО вообще делает отдельный НИИ, сильно напрягая при этом мозк. Также, допускается делать ТЗ результатом первого этапа — такая опция упоминалась, хотя на практике я с таким не сталкивался (а это наиболее интересный вариант).
В этом случае все равно будет ТЗ на ТЗ Или хотя бы технические требования на ТЗ. Ибо деньги платят за что-то, и это что-то фиксируется документально, причем отдельным документом. Причина вот в чем:
Давайте представим, что у нас описание работ, с кучей подробностей, включено в проект текста контракта. Вы несете его на согласование к юристам. Прочитав его, они, перемежая мат с юридическими формулировками, объясняют, что не знают, что такое Oracle, и от этого совершенно не страдают, и это совсем не мешает им быть хорошими юристами, и документ, в котором они девять десятых не понимают, подписывать не будут. И советуют сделать, как у всех — разбить контракт на несколько частей — текст собственно контракта, который они готовы проверить и поставить свою подпись, и технические приложения, на которые они даже смотреть не хотят.
Далее. Представим, что мы продавили своих юристов и они поставили свою подпись. Но есть еще и другая сторона, с которой история повторяется — и на них способов давления существенно меньше.
Теперь представим, что мы изменили одно-единственное требование. Понятно, что будет дальше
Разумеется, все вышесказанное справедливо только для крупных работ, имеющих сколь-нибудь значимое IP. Если надо поставить в магазин десять ящиков пива, в контракте так и напишут, на четырех пустых строчках прямо в тексте типового контракта.
G>Итеративность возможна всегда в том или ином виде. Результат первых итераций не обязан обладать полной функциональностью и быть качественным — это прототип в том или ином виде. Скажем, прототипом микропроцессора является его потактовая модель на обычном языке программирования. Собирается с целью изучения свойств предлагаемых подходов. Цель — это основное, отличает прототип от изделия, остальное частности.
Да я не спорю, прототипировать можно все — вопрос в степени приближенности прототипа к реальности. Модель системы на UML — это ведь тоже прототип, весьма полезный, кстати. Чем не первая итерация?
А вот если взять упомянутый процессор, и вписать в ТЗ фразу "военный диапазон температур", то первый работающий в железе прототип удатся получить хорошо, если через год, и никакие симуляторы не помогут узнать его реальную тактовую частоту, пока не будут созданы, оттестированы и нормализованы библиотеки элементов для разводчиков чипа, применительно к конкретному заводу.
Здравствуйте, nvb, Вы писали:
G>>Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения. Традиция выполнения заказов по линии ФАП/минпромторг, не иначе.
nvb>Да тут дело даже и не в удобстве. Если заказчик скажем так, странен, он вполне может вместе с измененным графиком изменить и требования. Я один раз наткнулся на такое — обещали поменять один пункт в ТЗ, а поменяли три, никак об остальных двух не уведомив. Случайно наткнулся, проформы ради листая перед подписанием. Заказчик потом клялся и божился, что это его подчиненные напортачили, безо всякого злого умысла, машинально сохранив изменения, но, как говорится, осадок остался
Без вашей подписи это все равно не пройдет, так что не проблема. Дело на мой взгляд в первую очередь в удобстве. Проверять ясен хрен надо. "Понятия", впрочем, также никто не отменял. Ходы то все записаны. Случайно прошедшие случайные изменения можно потом отменить. С накатом по шаловливым ручонкам.
nvb>>>Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов
G>>Допускается. В случае, когда совсем жопа, ТЗ вообще полагается делать результатом отдельного НИР. И делают. Скажем, ТЗ на новый комплекс ПВО вообще делает отдельный НИИ, сильно напрягая при этом мозк. Также, допускается делать ТЗ результатом первого этапа — такая опция упоминалась, хотя на практике я с таким не сталкивался (а это наиболее интересный вариант).
nvb>В этом случае все равно будет ТЗ на ТЗ Или хотя бы технические требования на ТЗ. Ибо деньги платят за что-то, и это что-то фиксируется документально, причем отдельным документом. Причина вот в чем:
Будет безусловно. ТЗ на НИР, с постановкой проблемы. Причина, собственно, в том, что ТЗ просто должно быть как на НИР так и на ОКР, и все . Просто там будут написаны разные вещи — ТЗ на НИР и ОКР натурально отличаются. Цель НИР — "исследование возможностей создания", в то время как цель ОКР — собственно "создание". Формы ТЗ, как вы безусловно знаете, немного разные на НИР и ОКР. В случае НИР, насколько я смутно припоминаю (года 2 с ними не сталкивался), всего где-то примерно три основных части в ТЗ, и оно сильно проще.
G>>Итеративность возможна всегда в том или ином виде. Результат первых итераций не обязан обладать полной функциональностью и быть качественным — это прототип в том или ином виде. Скажем, прототипом микропроцессора является его потактовая модель на обычном языке программирования. Собирается с целью изучения свойств предлагаемых подходов. Цель — это основное, отличает прототип от изделия, остальное частности.
nvb>Да я не спорю, прототипировать можно все — вопрос в степени приближенности прототипа к реальности. Модель системы на UML — это ведь тоже прототип, весьма полезный, кстати. Чем не первая итерация?
Да практически ничем. Это не прототип ни в коем разе, ибо его нельзя испытать и исследовать его свойства экспериментально. Это один из артефактов "эскизного проекта". UML-диаграмма — это гипотеза. Испытания прототипа — это эксперимент. Инженерия использует физический подход гипотеза-эксперимент.
nvb>А вот если взять упомянутый процессор, и вписать в ТЗ фразу "военный диапазон температур", то первый работающий в железе прототип удатся получить хорошо, если через год, и никакие симуляторы не помогут узнать его реальную тактовую частоту, пока не будут созданы, оттестированы и нормализованы библиотеки элементов для разводчиков чипа, применительно к конкретному заводу.
Да никаких проблем нет с этим требованием. Симуляторы, во-первых, помогут узнать его реальную тактовую частоту — уже симуляция на раннем этапе (нетлист) дает коридор точности примерно 20%. Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика. А "военный температурный диапазон" вообще имеет много общего с "расширенным индустриальным", что не фокус ни разу. Вот у нашего гражданского чипа сейчас заложен этот самый "военный" температурный диапазон — и вообще никто не париццо. Все равно военный тираж тираж небольшой — можно тупо сделать отсев холодильной камерой, и все, вообще не заморачиваясь. В чем проблема-то?
Здравствуйте, VGn, Вы писали:
G>>С "план-графиком" не перепутал? VGn>Нет. VGn>План граФИК, на сколько я помню, об этапаХ. VGn>А этапная программа о этапЕ. VGn>Ведомость будет после.
Что ж, я бы с удовольствием посмотрел на заполненный пример этого документа. Вообще, все проекты, которые я видел, обходились без него. Нафига он, собственно, нужен, этот документ?
Здравствуйте, Gaperton, Вы писали:
G>Без вашей подписи это все равно не пройдет, так что не проблема. Дело на мой взгляд в первую очередь в удобстве. Проверять ясен хрен надо. "Понятия", впрочем, также никто не отменял. Ходы то все записаны. Случайно прошедшие случайные изменения можно потом отменить. С накатом по шаловливым ручонкам.
Зависит от отношений с заказчиком, а они на финальном этапе могут испортиться.
nvb>>Да я не спорю, прототипировать можно все — вопрос в степени приближенности прототипа к реальности. Модель системы на UML — это ведь тоже прототип, весьма полезный, кстати. Чем не первая итерация?
G>Да практически ничем. Это не прототип ни в коем разе, ибо его нельзя испытать и исследовать его свойства экспериментально. Это один из артефактов "эскизного проекта". UML-диаграмма — это гипотеза. Испытания прототипа — это эксперимент. Инженерия использует физический подход гипотеза-эксперимент.
Пожалуй, соглашусь, хотя неизвестно, что лучше — некий как-то работающий код или детализированная до уровня классов и объектов UML диаграмма. Но, конечно, иметь работающий прототип — это во много раз лучше, чем его не иметь.
nvb>>А вот если взять упомянутый процессор, и вписать в ТЗ фразу "военный диапазон температур", то первый работающий в железе прототип удатся получить хорошо, если через год, и никакие симуляторы не помогут узнать его реальную тактовую частоту, пока не будут созданы, оттестированы и нормализованы библиотеки элементов для разводчиков чипа, применительно к конкретному заводу.
G>Да никаких проблем нет с этим требованием. Симуляторы, во-первых, помогут узнать его реальную тактовую частоту — уже симуляция на раннем этапе (нетлист) дает коридор точности примерно 20%.
На нетлисте можно лишь выявить основные причины снижения тактовой частоты и ликвидировать их. Говорить про точность симуляции частоты на этом этапе вообще нет смысла, хотя бы из-за неизвестности задержек элементов. Можно взять типовые и поиграться с ними, но не более того.
G>Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика.
Подойдите к военпреду с этим предложением — использовать фабричные библиотеки западных заводов для военных целей, и послушайте, что он скажет. Предварительно убрав женщин из комнаты. Топология — это вопрос очень чувствительный. Уж на что раздолбаи в Элвисе — а даже они на своих библиотеках делали... ну, во всяком случае, декларировали. Вот запустят линию 90 нм на Ангстреме — тогда можно будет использовать фабричные, но сколько до этого еще осталось...
G>А "военный температурный диапазон" вообще имеет много общего с "расширенным индустриальным", что не фокус ни разу. Вот у нашего гражданского чипа сейчас заложен этот самый "военный" температурный диапазон — и вообще никто не париццо. Все равно военный тираж тираж небольшой — можно тупо сделать отсев холодильной камерой, и все, вообще не заморачиваясь. В чем проблема-то?
Потому что есть у военных жесткое правило — "Отбор запрещен". Температурные параметры микросхем, равно как и все прочие, должны обеспечиваться на стадии проектирования. Понятно, что есть искушение схитрить и использовать отбор, но оно легко пресекается процедурой приемки. Поговорите с военпредом, возьмите у него документ, описывающий эту процедуру. Если у вас заложен военный диапазон — а он пару лет назад был расширен — это самое серьезное требование в ТЗ, которое съест больше всего денег и времени. Риски огромные, а вы никак не реагируете на них(вернее, реагируете стратегией "принятие"), что очень опасно.
В России выпущен десяток процессоров с тактовой 40-100МГц, которые декларируют военный диапазон, но когда начинаешь спрашивать подтверждающие официальные документы — просят позвонить через пол-года, потому что сейчас у них идут испытания. Прототипы, блин, испытывают, причем все разом
А вообще-то мы ушли от темы, как проектного управления, так и программирования. Давайте больше не будем про процессоры, хорошо? Или в личку.
Здравствуйте, nvb, Вы писали: G>>Да практически ничем. Это не прототип ни в коем разе, ибо его нельзя испытать и исследовать его свойства экспериментально. Это один из артефактов "эскизного проекта". UML-диаграмма — это гипотеза. Испытания прототипа — это эксперимент. Инженерия использует физический подход гипотеза-эксперимент.
nvb>Пожалуй, соглашусь, хотя неизвестно, что лучше — некий как-то работающий код или детализированная до уровня классов и объектов UML диаграмма. Но, конечно, иметь работающий прототип — это во много раз лучше, чем его не иметь.
Зачем же между ними выбирать. Ничто не лучше. Это разные инструменты, служат разным целям, одно другое не исключает. Если надо делать прототип для проверки клюючевых решений — то он делается, вполне возможно — на том же этапе эскизного проекта. Цель прототипа — уточнить подход к решению.
G>>Да никаких проблем нет с этим требованием. Симуляторы, во-первых, помогут узнать его реальную тактовую частоту — уже симуляция на раннем этапе (нетлист) дает коридор точности примерно 20%.
nvb>На нетлисте можно лишь выявить основные причины снижения тактовой частоты и ликвидировать их. Говорить про точность симуляции частоты на этом этапе вообще нет смысла, хотя бы из-за неизвестности задержек элементов. Можно взять типовые и поиграться с ними, но не более того.
При симуляции нетлиста используется таблица реальных задержек вполне конкретных библиотечных элементов, поэтому про точность симуляции частоты на нетлисте говорить имеет смысл. О точности симуляции частоты не имеет смысла говорить при симуляции RTL. Это разные вещи.
G>>Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика.
nvb>Подойдите к военпреду с этим предложением — использовать фабричные библиотеки западных заводов для военных целей, и послушайте, что он скажет. Предварительно убрав женщин из комнаты.
Правда? А это мне кажется, что я несколько лет назад от руководителя направления микроэлектроники УРБВТ (я припоминаю, его фамилия Малофеев была) слышал (и вместе со мной целый зал людей), что допускается использование стандартных библиотек западных фабрик, и единственное требование — чтобы разработка топологии была in-house? А это ничего, например, что модулевские Нейроматриксы для военки делались на фуджитсовских гейтэррэях? Знаете, что такое gate array?
nvb>Топология — это вопрос очень чувствительный.
Ерунда это. Стандартные библиотеки единственное чего не дают — это защиты от радиации. Да и то — для практических нужд достаточно загрубить техпроцесс и навесить на память ECC. И будет не только температурный диапазон, но и радхард.
G>>А "военный температурный диапазон" вообще имеет много общего с "расширенным индустриальным", что не фокус ни разу. Вот у нашего гражданского чипа сейчас заложен этот самый "военный" температурный диапазон — и вообще никто не париццо. Все равно военный тираж тираж небольшой — можно тупо сделать отсев холодильной камерой, и все, вообще не заморачиваясь. В чем проблема-то?
nvb>Потому что есть у военных жесткое правило — "Отбор запрещен".
Что, правда? Отбор таки совсем-совсем запрещен? Они что, правда не испытывают микросхемы, которые ставят в свою технику, чтобы отсеять брак? Чудеса какие-то.
nvb>Температурные параметры микросхем, равно как и все прочие, должны обеспечиваться на стадии проектирования. Понятно, что есть искушение схитрить и использовать отбор, но оно легко пресекается процедурой приемки. Поговорите с военпредом, возьмите у него документ, описывающий эту процедуру. Если у вас заложен военный диапазон — а он пару лет назад был расширен — это самое серьезное требование в ТЗ, которое съест больше всего денег и времени. Риски огромные, а вы никак не реагируете на них(вернее, реагируете стратегией "принятие"), что очень опасно.
Да ничего он не съест. Технологические параметры для _цифорвых_ схем — это совершеннейшая ерунда. Цифра не аналог, можно и без кольцевых транзисторов обойтись. Все необходимые параметры дает симуляция топологии до запуска. И не надо мне рассказывать про огромные риски, и оценивать, как я на них реагирую, ладно?
nvb>В России выпущен десяток процессоров с тактовой 40-100МГц, которые декларируют военный диапазон, но когда начинаешь спрашивать подтверждающие официальные документы — просят позвонить через пол-года, потому что сейчас у них идут испытания. Прототипы, блин, испытывают, причем все разом
В России выпущено процессоров, имеющих частоты выше 40-100 Мгц, которые декларируют военный диапазон. Посмотрите на технику Корунд-М, и полюбопытствуйте, на каких процессорах она собрана ("Комдив" называются), какие у нее диапазоны, и какие там на самом деле частоты.
nvb>А вообще-то мы ушли от темы, как проектного управления, так и программирования. Давайте больше не будем про процессоры, хорошо? Или в личку.
Вот вы и не пишите больше про процессоры. Я вообще не знаю, что вас дернуло меня микроэлектронике учить .
Здравствуйте, Gaperton, Вы писали:
G>>>Да никаких проблем нет с этим требованием. Симуляторы, во-первых, помогут узнать его реальную тактовую частоту — уже симуляция на раннем этапе (нетлист) дает коридор точности примерно 20%.
nvb>>На нетлисте можно лишь выявить основные причины снижения тактовой частоты и ликвидировать их. Говорить про точность симуляции частоты на этом этапе вообще нет смысла, хотя бы из-за неизвестности задержек элементов. Можно взять типовые и поиграться с ними, но не более того.
G>При симуляции нетлиста используется таблица реальных задержек вполне конкретных библиотечных элементов, поэтому про точность симуляции частоты на нетлисте говорить имеет смысл. О точности симуляции частоты не имеет смысла говорить при симуляции RTL. Это разные вещи.
Нет еще пока вполне конкретных библиотечных элементов... если только их работающая параллельно группа к тому времени не сделала. В этом вся соль. Можно взять готовые — но какие готовые?
Для второго чипа — да, полностью согласен.
G>>>Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика.
nvb>>Подойдите к военпреду с этим предложением — использовать фабричные библиотеки западных заводов для военных целей, и послушайте, что он скажет. Предварительно убрав женщин из комнаты.
G>Правда? А это мне кажется, что я несколько лет назад от руководителя направления микроэлектроники УРБВТ (я припоминаю, его фамилия Малофеев была) слышал (и вместе со мной целый зал людей), что допускается использование стандартных библиотек западных фабрик, и единственное требование — чтобы разработка топологии была in-house? А это ничего, например, что модулевские Нейроматриксы для военки делались на фуджитсовских гейтэррэях? Знаете, что такое gate array?
Увы, я не слушал Малофеева и у меня нет доступа к закрытой информации от Модуля. Воспользуемся открытыми источниками, откуда, по статистике, вытаскивается от 60 до 90% информации, поставляемой разведкой Плюс немного логики.
Идем на сайт Модуля и смотрим информацию по NM6403. На главной странице по процессору написано:
"условия эксплуатации: -60...+85 C" — вроде бы соответствует старому военному ГОСТ (сейчас +125, ну да ладно). Но мы же недоверчивые, и поэтому открываем ссылку на юзер мануал с той же страницы. И видим мы такую строчку в таблице 13-5 "Предельно допустимые электрические и температурные режимы работы" — "TSTG Температура хранения -40 125 °C". Т.е. изделие с этим процессором ниже -40 даже хранить нельзя.
Но это еще не все. Идем на следующую таблицу "Табл. 13-6. Рекомендуемые условия эксплуатации" и в ней видим строчку "TCASE Температура на поверхности корпуса -40 85 °C". А чтобы слово "Рекомендуемые" не вводило в заблуждение, первое примечание к таблице гласит "1) Внешние воздействия, значения которых выходят за пределы указанных диапазонов, могут приводить к сбоям в работе микросхемы;"
Итак, что получается? А получается чип, работающий в индустриальном диапазоне температур, и слово "Военный" — это только реклама, не более того. Маркетологи слышали звон... Засим мы, в принципе, можем использовать стандартные заводские библиотеки для индустриального диапазона, ибо никто в этом диапазоне в здравом уме и твердой памяти гадить не будет. Можно даже выдать их за свои, если есть желание.
Однако, в военном диапазоне начинаются совсем другие игры. Поставка в Россию микросхем в military диапазоне разрешается только с разрешения госдепа США, причем потребуется подробно описать изделие, в котором эти микросхемы применяются, и быть готовым ответить на вопросы, буде таковые возникнут. Не верите — позвоните, скажем, в российское представительство Actel и попросите продать парочку CPLD в military диапазоне.
Вопрос — чем отличаются чипы military от industrial? Конечно, есть и схемотехнические решения, и корпусировка, но основное — это библиотеки. И кто же отдаст эти библиотеки в свободный доступ? Чипмейкер? У него их попросту нет, поскольку доля military чипов в общем объеме продукции ничтожно мала, он лучше деньги в улучшение стандартных библиотек вложит — защита от статики и все такое. Заказчик? А Вы бы свои, выстраданные десятком итераций, библиотеки отдали? Даже если не давали подписку, а особые отделы и на Западе есть. Нет, это ваше ноу-хау, в него деньги немалые вложены. Жалко.
В принципе, можно пойти привычным путем — эти библиотеки украсть, но где гарантия, что украдено именно нужное, а не подсадка АНБ или чего там. Собственно, именно этого и боятся военпреды.
И если при разводке Нейроматрикса использовались каким-то чудом добытые military библиотеки, а в итоге получился industrial чип — то не зря военпреды боятся. Но я склонен думать, что industrial и использовались при разводке. Впрочем, Вам виднее — у меня-то информации нет.
nvb>>Топология — это вопрос очень чувствительный.
G>Ерунда это. Стандартные библиотеки единственное чего не дают — это защиты от радиации. Да и то — для практических нужд достаточно загрубить техпроцесс и навесить на память ECC. И будет не только температурный диапазон, но и радхард.
Даже спорить не буду, ибо Вы кругом правы. По слухам, в Штатах до сих пор используется старая линия для выпуска 8086, которые радхард. Вот только тактовая частота мала. С чего бы?
G>>>А "военный температурный диапазон" вообще имеет много общего с "расширенным индустриальным", что не фокус ни разу. Вот у нашего гражданского чипа сейчас заложен этот самый "военный" температурный диапазон — и вообще никто не париццо. Все равно военный тираж тираж небольшой — можно тупо сделать отсев холодильной камерой, и все, вообще не заморачиваясь. В чем проблема-то?
nvb>>Потому что есть у военных жесткое правило — "Отбор запрещен".
G>Что, правда? Отбор таки совсем-совсем запрещен? Они что, правда не испытывают микросхемы, которые ставят в свою технику, чтобы отсеять брак? Чудеса какие-то.
Выборочные испытания и отбраковочные испытания (отбор) — принципиально разные вещи.
А вообще — я сразу не подумал — если в ТЗ нет требования серийного выпуска, а нужны только опытные образцы — это совсем другое дело. Тогда действительно, отбор рулит. Я ведь не знаю, что у вас в ТЗ написано.
nvb>>Температурные параметры микросхем, равно как и все прочие, должны обеспечиваться на стадии проектирования. Понятно, что есть искушение схитрить и использовать отбор, но оно легко пресекается процедурой приемки. Поговорите с военпредом, возьмите у него документ, описывающий эту процедуру. Если у вас заложен военный диапазон — а он пару лет назад был расширен — это самое серьезное требование в ТЗ, которое съест больше всего денег и времени. Риски огромные, а вы никак не реагируете на них(вернее, реагируете стратегией "принятие"), что очень опасно.
G>Да ничего он не съест. Технологические параметры для _цифорвых_ схем — это совершеннейшая ерунда. Цифра не аналог, можно и без кольцевых транзисторов обойтись. Все необходимые параметры дает симуляция топологии до запуска.
См.выше. Нет еще топологии.
G> И не надо мне рассказывать про огромные риски, и оценивать, как я на них реагирую, ладно?
Это действительно не мое дело. Извините.
G>В России выпущено процессоров, имеющих частоты выше 40-100 Мгц, которые декларируют военный диапазон. Посмотрите на технику Корунд-М, и полюбопытствуйте, на каких процессорах она собрана ("Комдив" называются), какие у нее диапазоны, и какие там на самом деле частоты.
Я выше уже написал про Модулевский процессор. К сожалению, посмотреть на Корунд-М не могу, поскольку в свободном доступе на нее почти ничего нет. Если приведете фразы из ТУ на Комдив — буду благодарен. Дело в том, что информация на сайте — не более чем реклама, а за информацию в ТУ производителю приходится серьезно отвечать.
G>Что ж, я бы с удовольствием посмотрел на заполненный пример этого документа. Вообще, все проекты, которые я видел, обходились без него. Нафига он, собственно, нужен, этот документ?
Здравствуйте, nvb, Вы писали:
nvb>Здравствуйте, Gaperton, Вы писали:
G>>Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения.
При предварительном указании состава всех этапов теряется итеративная гибкость планирования.
G>>Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика.
nvb>Подойдите к военпреду с этим предложением — использовать фабричные библиотеки западных заводов для военных целей, и послушайте, что он скажет. Предварительно убрав женщин из комнаты. Топология — это вопрос очень чувствительный. Уж на что раздолбаи в Элвисе — а даже они на своих библиотеках делали... ну, во всяком случае, декларировали. Вот запустят линию 90 нм на Ангстреме — тогда можно будет использовать фабричные, но сколько до этого еще осталось...
Соответствие стандартов подтверждается либо согласованной документацией (редко), либо независимым аудитом (чаще всего), либо собственными испытаниями.
Поскольку делать надо, то неразрешимых проблем нет. Вопрос в цене.
Здравствуйте, VGn, Вы писали:
G>>Что ж, я бы с удовольствием посмотрел на заполненный пример этого документа. Вообще, все проекты, которые я видел, обходились без него. Нафига он, собственно, нужен, этот документ?
VGn>Для денег за этап.
Поговорил я с еще более знающими людьми. Тоже никто об этапной программе не слышал, но сказали, что состав документов по контракту для военных ГОСТом, в общем случае, не регламентируется. Т.е. можно писать какие угодно документы, главное, чтобы они не противоречили существующему законодательству.
Зачем — это вопрос второй. По-моему, это неудобно, по сравнению с ведомостью исполнения, но это в моем представлении. На его единственную правильность я не претендую
Да, кстати — точно этот документ на А5? Может, на А4 все-таки?
Здравствуйте, VGn, Вы писали:
VGn>Здравствуйте, nvb, Вы писали:
nvb>>Здравствуйте, Gaperton, Вы писали:
G>>>Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения.
VGn>При предварительном указании состава всех этапов теряется итеративная гибкость планирования.
Да, мы как-то позабыли, что кроме fixed-price бывают и другие типы контрактов Спасибо за напоминание.
VGn>>Для денег за этап.
nvb>Поговорил я с еще более знающими людьми. Тоже никто об этапной программе не слышал, но сказали, что состав документов по контракту для военных ГОСТом, в общем случае, не регламентируется. Т.е. можно писать какие угодно документы, главное, чтобы они не противоречили существующему законодательству.
Очередное заседание Совета директоров во главе с председателем Совета директоров В.В. Дорохиным состоялось 18 апреля 2006 г.
В ходе заседания глава комитета по стратегическому развитию В.Н.Тренев выступил с докладом о ходе работ по совершенствованию системы управления концерном и его структурными подразделениями. Консалтинг по данному направлению осуществляет ЗАО "Консалтинговая группа "РОЭЛ Консалтинг".
В результате обсуждения Совет директоров концерна одобрил предложенный консультантами перечень работ. После рассмотрения комитетами по стратегическому развитию и корпоративному управлению этапная программа выполнения работ будет вынесена на утверждение Совета директоров. (INFOLine, ИА (по материалам компании) 25.04.06)
Здравствуйте, nvb, Вы писали:
G>>>>Да никаких проблем нет с этим требованием. Симуляторы, во-первых, помогут узнать его реальную тактовую частоту — уже симуляция на раннем этапе (нетлист) дает коридор точности примерно 20%.
nvb>>>На нетлисте можно лишь выявить основные причины снижения тактовой частоты и ликвидировать их. Говорить про точность симуляции частоты на этом этапе вообще нет смысла, хотя бы из-за неизвестности задержек элементов. Можно взять типовые и поиграться с ними, но не более того.
G>>При симуляции нетлиста используется таблица реальных задержек вполне конкретных библиотечных элементов, поэтому про точность симуляции частоты на нетлисте говорить имеет смысл. О точности симуляции частоты не имеет смысла говорить при симуляции RTL. Это разные вещи.
nvb>Нет еще пока вполне конкретных библиотечных элементов... если только их работающая параллельно группа к тому времени не сделала. В этом вся соль. Можно взять готовые — но какие готовые?
Пока нет вполне конкретных библиотечных элементов — нет и нетлиста, который можно моделировать, потому что тупо не во что производить синтез. В этом вся соль. Можно взять готовые. Какие? Вот действительно, проблема. Она решается неожиданно — берут готовые, с той фабрики, на которой будет производится запуск. Как неожиданно, правда?
К вашему сведению, не раскрывая особой военной тайны — могу чисто конфиденциально сообщить: на немецкой фабрике XFab стандартный техпроцесс 0,35 обеспечивает военные требования (пятая приемка) как по температуре (что проблемой вообще не является, ибо в изделиях решается просто — перед стартом техника элементарно греется), так и по радиации (что на самом деле является проблемой). При СТАНДАРТНЫХ библиотеках. Это — факты. Топологи, которые располагают этими фактами, к слову, у меня в соседней комнате сидят. И у них уже уши вянут — я на всякий случай передал им ваши слова, пока наливал кофе.
Кроме того, температурный диапазон вообще не относится к параметрам, которые обеспечиваются моделями транзисторов (библиотек вообще-то два типа — кроме вентилей надо еще транзисторы с заданными характеристиками из слоев собрать) — это свойство техпроцесса, а не библиотеки. Радиационная стойкость также во многом характеристика техпроцесса (в целом — чем он грубее, тем более стойкие изделия) однако, на нее таки оказывает влияние то, как устроены транзисторы. Скажем, кольцевые транзисторы более стойкие к радиации.
G>>>>Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика.
nvb>>>Подойдите к военпреду с этим предложением — использовать фабричные библиотеки западных заводов для военных целей, и послушайте, что он скажет. Предварительно убрав женщин из комнаты.
G>>Правда? А это мне кажется, что я несколько лет назад от руководителя направления микроэлектроники УРБВТ (я припоминаю, его фамилия Малофеев была) слышал (и вместе со мной целый зал людей), что допускается использование стандартных библиотек западных фабрик, и единственное требование — чтобы разработка топологии была in-house? А это ничего, например, что модулевские Нейроматриксы для военки делались на фуджитсовских гейтэррэях? Знаете, что такое gate array?
nvb>Увы, я не слушал Малофеева и у меня нет доступа к закрытой информации от Модуля. Воспользуемся открытыми источниками, откуда, по статистике, вытаскивается от 60 до 90% информации, поставляемой разведкой Плюс немного логики.
Понятно. Знаете — а у меня по странному стечению обстоятельств есть доступ к информации от Модуля. Какое совпадение — я сейчас там работаю по контракту — меня там очень настойчиво попросили помочь сделать одну сложную микросхему для цифрового ТВ по 0,90.
Кстати, между нами — "военными". А я то думал, что реальные "военные" пацаны пользуются списком электронных компонент, разрешенных к применению в военной технике . Знаете — книжечка такая небольшая. А оказывается — логикой и открытыми источниками. Не по военному как-то.
nvb>Итак, что получается?
... nvb>И если при разводке Нейроматрикса использовались каким-то чудом добытые military библиотеки, а в итоге получился industrial чип — то не зря военпреды боятся. Но я склонен думать, что industrial и использовались при разводке. Впрочем, Вам виднее — у меня-то информации нет.
Итак, получается, что вы таки не знаете, что такое gate array. Я объясню, это очень просто. http://ru.wikipedia.org/wiki/БМК
Ловушка была в том, что gate array предполагает использование одной, заранее предопределенной библиотеки. Той, элементы которой на нем разведена. Все, что вы можете делать с gate array — это добавлять металлизацию. Так что, никаких military библиотек на gate array от Fujitsu использовать нельзя даже в том фантастическом случае, если их удастся добыть . На gate array вас просто не пускают к слоям, на которых делаются транзисторы .
И трагедии никакой нет — дело в том, что техпроцесс 0,5 от Fujitsu также дает стойкость к радиации и расширенный температурный диапазон на стандартных библиотеках.
Мне просто жутко интересно стало, насколько вы на самом деле разбираетесь процессе разработки микроэлектроники, вот я и упомянул gate array. Надеюсь, вы простите мне эту маленткую шалость?
nvb>>>Топология — это вопрос очень чувствительный.
G>>Ерунда это. Стандартные библиотеки единственное чего не дают — это защиты от радиации. Да и то — для практических нужд достаточно загрубить техпроцесс и навесить на память ECC. И будет не только температурный диапазон, но и радхард.
nvb>Даже спорить не буду, ибо Вы кругом правы. По слухам, в Штатах до сих пор используется старая линия для выпуска 8086, которые радхард. Вот только тактовая частота мала. С чего бы?
Техпроцесс грубый потому что. Да, спорить действительно не надо. Честно — я вообще плохо понимаю, какое удовольствие спорить на "неродную" себе тему.
G>>Что, правда? Отбор таки совсем-совсем запрещен? Они что, правда не испытывают микросхемы, которые ставят в свою технику, чтобы отсеять брак? Чудеса какие-то.
nvb>Выборочные испытания и отбраковочные испытания (отбор) — принципиально разные вещи. nvb>А вообще — я сразу не подумал — если в ТЗ нет требования серийного выпуска, а нужны только опытные образцы — это совсем другое дело. Тогда действительно, отбор рулит. Я ведь не знаю, что у вас в ТЗ написано.
Какие по вашему тиражи микросхем в военке при серийном выпуске? Миллионы штук? Военная тайна: тысячи изделий в год — это крупный тираж для военки. Для процессоров — тираж сотни штук в год более реалистичен. На таких тиражах устраивать выборочные испытания для высоконадежной техники как то странно, не находите?
G>>В России выпущено процессоров, имеющих частоты выше 40-100 Мгц, которые декларируют военный диапазон. Посмотрите на технику Корунд-М, и полюбопытствуйте, на каких процессорах она собрана ("Комдив" называются), какие у нее диапазоны, и какие там на самом деле частоты.
nvb>Я выше уже написал про Модулевский процессор. К сожалению, посмотреть на Корунд-М не могу, поскольку в свободном доступе на нее почти ничего нет. Если приведете фразы из ТУ на Комдив — буду благодарен. Дело в том, что информация на сайте — не более чем реклама, а за информацию в ТУ производителю приходится серьезно отвечать.
Насколько я помню — техпроцесс 0,35, частота в районе 200 Мгц, приемка 5 с температурой и радиационной стойкостью. Схема цифровая, стандартные библиотеки.
Здравствуйте, VGn, Вы писали:
G>>Что ж, я бы с удовольствием посмотрел на заполненный пример этого документа. Вообще, все проекты, которые я видел, обходились без него. Нафига он, собственно, нужен, этот документ?
VGn>Для денег за этап.
А. Тогда понятно. Это калькуляция затрат на этап? Что-то вроде сметы? Кстати, я бы реально хотел образец такого документа. В хозяйстве пригодится, полезная штука. Можно получить в личную почту?
Здравствуйте, Gaperton, Вы писали:
nvb>>Нет еще пока вполне конкретных библиотечных элементов... если только их работающая параллельно группа к тому времени не сделала. В этом вся соль. Можно взять готовые — но какие готовые?
G>Пока нет вполне конкретных библиотечных элементов — нет и нетлиста, который можно моделировать, потому что тупо не во что производить синтез. В этом вся соль. Можно взять готовые. Какие? Вот действительно, проблема. Она решается неожиданно — берут готовые, с той фабрики, на которой будет производится запуск. Как неожиданно, правда?
G>К вашему сведению, не раскрывая особой военной тайны — могу чисто конфиденциально сообщить: на немецкой фабрике XFab стандартный техпроцесс 0,35 обеспечивает военные требования (пятая приемка) как по температуре (что проблемой вообще не является, ибо в изделиях решается просто — перед стартом техника элементарно греется)
Ну, это Вы сгоряча написали. Представьте себе истребитель на аэродроме в Сибири. Или в Алжире. Электронный блок греть или охлаждать — это технику специальную подгонять надо. Кроме того, есть такой параметр — время готовности. Именно для этого и делаются процессоры с -60 +125(85).
Да и потом — эти системы подогрева-охлаждения стоят денег и весят немало, это тоже надо учитывать.
G>, так и по радиации (что на самом деле является проблемой). При СТАНДАРТНЫХ библиотеках. Это — факты. Топологи, которые располагают этими фактами, к слову, у меня в соседней комнате сидят. И у них уже уши вянут — я на всякий случай передал им ваши слова, пока наливал кофе.
Ну, значит есть библиотеки и ими пользуются. Вашим топологам виднее.
G>Кроме того, температурный диапазон вообще не относится к параметрам, которые обеспечиваются моделями транзисторов (библиотек вообще-то два типа — кроме вентилей надо еще транзисторы с заданными характеристиками из слоев собрать) — это свойство техпроцесса, а не библиотеки. Радиационная стойкость также во многом характеристика техпроцесса (в целом — чем он грубее, тем более стойкие изделия) однако, на нее таки оказывает влияние то, как устроены транзисторы. Скажем, кольцевые транзисторы более стойкие к радиации.
Какое именно свойство техпроцесса, поделитесь.
G>>>>>Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика.
nvb>>>>Подойдите к военпреду с этим предложением — использовать фабричные библиотеки западных заводов для военных целей, и послушайте, что он скажет. Предварительно убрав женщин из комнаты.
G>>>Правда? А это мне кажется, что я несколько лет назад от руководителя направления микроэлектроники УРБВТ (я припоминаю, его фамилия Малофеев была) слышал (и вместе со мной целый зал людей), что допускается использование стандартных библиотек западных фабрик, и единственное требование — чтобы разработка топологии была in-house? А это ничего, например, что модулевские Нейроматриксы для военки делались на фуджитсовских гейтэррэях? Знаете, что такое gate array?
nvb>>Увы, я не слушал Малофеева и у меня нет доступа к закрытой информации от Модуля. Воспользуемся открытыми источниками, откуда, по статистике, вытаскивается от 60 до 90% информации, поставляемой разведкой Плюс немного логики.
G>Понятно. Знаете — а у меня по странному стечению обстоятельств есть доступ к информации от Модуля. Какое совпадение — я сейчас там работаю по контракту — меня там очень настойчиво попросили помочь сделать одну сложную микросхему для цифрового ТВ по 0,90.
Прекрасно! Тогда можете огласить информацию из ТУ на 6403 о предельных значениях температуры — рабочих и хранения? Она ведь не ДСП?
G>Кстати, между нами — "военными". А я то думал, что реальные "военные" пацаны пользуются списком электронных компонент, разрешенных к применению в военной технике . Знаете — книжечка такая небольшая. А оказывается — логикой и открытыми источниками. Не по военному как-то.
Речь идет о "списке ЦНИИ-22"? Там, мягко говоря, сведения не совсем достоверные. Например, для Элвиса МС-24 там указан военный температурный диапазон, но попробуйте получить от Элвиса официальные ТУ, подтверждающее этот диапазон — не получится. Этот список используется, чтобы прикрыть задницу для военной приемки, не более того. Там в параметрах пишутся данные из ТЗ, а не фактические. Есть разница.
И потом, Вы видели, сколько там информации по компонентам? Кот наплакал. Кстати, я сегодня туда посмотрел, но инфы по 6403 там нет. Почему — загадка.
nvb>>Итак, что получается? G>... nvb>>И если при разводке Нейроматрикса использовались каким-то чудом добытые military библиотеки, а в итоге получился industrial чип — то не зря военпреды боятся. Но я склонен думать, что industrial и использовались при разводке. Впрочем, Вам виднее — у меня-то информации нет.
G>Итак, получается, что вы таки не знаете, что такое gate array. Я объясню, это очень просто. G>http://ru.wikipedia.org/wiki/БМК
G>Ловушка была в том, что gate array предполагает использование одной, заранее предопределенной библиотеки. Той, элементы которой на нем разведена. Все, что вы можете делать с gate array — это добавлять металлизацию. Так что, никаких military библиотек на gate array от Fujitsu использовать нельзя даже в том фантастическом случае, если их удастся добыть . На gate array вас просто не пускают к слоям, на которых делаются транзисторы .
Я и не претендую на эксперта. Просто общался в основном с разработчиками аналоговой микроэлектроники, которую на БМК не делают. Отсюда и вопросы, и пропуск теста на gate array — я его за обычную ячейку принял. Она, кстати, и есть обычная, только тополог ее в случае с БМК поменять не может. БМК ведь не единственный способ изготовить процессор, а просто более дешевый.
G>И трагедии никакой нет — дело в том, что техпроцесс 0,5 от Fujitsu также дает стойкость к радиации и расширенный температурный диапазон на стандартных библиотеках.
Расширенный — надеюсь, военный имеется в виду?
Тогда ответьте на простой вопрос. Есть некий техпроцесс, обеспечивающий 5 приемку. Тем не менее, процессоры, по нему выпущенные, работают в гораздо более узком диапазоне температур. Почему?
Это не подколка именно для Модуля, я не ставлю перед собой цель посадить Вас в лужу, мне на самом деле интересно — почему так у всех производителей процессоров, с которыми я имел дела. В чем затык?
G>Мне просто жутко интересно стало, насколько вы на самом деле разбираетесь процессе разработки микроэлектроники, вот я и упомянул gate array. Надеюсь, вы простите мне эту маленткую шалость?
Ох уж мне эта деликатность... Спросили бы напрямую, да это и по вопросам было ясно. Я раньше делал системы-на-плате, и приходилось интересоваться причинами проблем с чипами. Поэтому ходил общаться к разработчикам чипов.
nvb>>>>Топология — это вопрос очень чувствительный.
G>>>Ерунда это. Стандартные библиотеки единственное чего не дают — это защиты от радиации. Да и то — для практических нужд достаточно загрубить техпроцесс и навесить на память ECC. И будет не только температурный диапазон, но и радхард.
nvb>>Даже спорить не буду, ибо Вы кругом правы. По слухам, в Штатах до сих пор используется старая линия для выпуска 8086, которые радхард. Вот только тактовая частота мала. С чего бы?
G>Техпроцесс грубый потому что. Да, спорить действительно не надо. Честно — я вообще плохо понимаю, какое удовольствие спорить на "неродную" себе тему.
Она мне не совсем и чужая. Несколько лет назад я искал для одного изделия процессор с тактовой выше 80 МГц, даже не с пятой приемкой, а всего лишь с военным температурным диапазоном. Не нашел. Вот и интересно — почему это так.
Это как с колбасой — пока ей не отравишься, не заинтересуешься технологиями ее изготовления и хранения А вот после отравления — становится интересно.
G>>>Что, правда? Отбор таки совсем-совсем запрещен? Они что, правда не испытывают микросхемы, которые ставят в свою технику, чтобы отсеять брак? Чудеса какие-то.
nvb>>Выборочные испытания и отбраковочные испытания (отбор) — принципиально разные вещи. nvb>>А вообще — я сразу не подумал — если в ТЗ нет требования серийного выпуска, а нужны только опытные образцы — это совсем другое дело. Тогда действительно, отбор рулит. Я ведь не знаю, что у вас в ТЗ написано.
G>Какие по вашему тиражи микросхем в военке при серийном выпуске? Миллионы штук? Военная тайна: тысячи изделий в год — это крупный тираж для военки. Для процессоров — тираж сотни штук в год более реалистичен.
Это не потому, что больше не надо. Это потому, что народ видит, что рекламная надпись про приемку 5 — фикция, и предпочитает использовать старые решения, с подогревом и охлаждением. Военных систем, требующих быстрой обработки данных, выпускается и модернизируется много больше, чем тысяча в год. А ведь есть еще и МЧС, и спецслужбы.
G>На таких тиражах устраивать выборочные испытания для высоконадежной техники как то странно, не находите?
Это определяется не логикой, а нормативными документами К опытному образцу и серии предъявляются различные требования, в том числе по приемке. Разница — в количестве и типах испытаний.
G>>>В России выпущено процессоров, имеющих частоты выше 40-100 Мгц, которые декларируют военный диапазон. Посмотрите на технику Корунд-М, и полюбопытствуйте, на каких процессорах она собрана ("Комдив" называются), какие у нее диапазоны, и какие там на самом деле частоты.
nvb>>Я выше уже написал про Модулевский процессор. К сожалению, посмотреть на Корунд-М не могу, поскольку в свободном доступе на нее почти ничего нет. Если приведете фразы из ТУ на Комдив — буду благодарен. Дело в том, что информация на сайте — не более чем реклама, а за информацию в ТУ производителю приходится серьезно отвечать.
G>Насколько я помню — техпроцесс 0,35, частота в районе 200 Мгц, приемка 5 с температурой и радиационной стойкостью. Схема цифровая, стандартные библиотеки.
Откуда эта информация? Вы видели официальное ТУ, или смотрели список ЦНИИ-22? Какой процессор, кстати — 1890ВМ3Т или ВМ4?
G>А. Тогда понятно. Это калькуляция затрат на этап? Что-то вроде сметы? \
Всё правильно. Что-то типа сметы высокоуровневой.
G>Кстати, я бы реально хотел образец такого документа. В хозяйстве пригодится, полезная штука. Можно получить в личную почту?
Нету. Предприятие режимное было. Документы не выносил.
) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3, 
Мы уже победили, просто это еще не так заметно...
