sergey888 В данном контексте - "плохо масштабируемую".

Назовите мне ERP систему, которая могла бы оптимально загрузить работой все процессоры, скажем 12-ти процессорого сервака?
По опыту скаду, если из 12 процессоров оставить работать 2 процессора, то система работает намного быстрее, чем с 12 процессорами.
Почему? Потому что ОС рассчитана на процессор и сопроцессор. Что делать с остальными процессорами она не знает.Хорошенько нагрузив диски (некий отчетец за весь период существования системы, например), Вы загрузите сервак так, что все равно, какие там у него процессоры и сколько их.

Какая, кстати, ОС?.. Windows 2000 Server? ;)

Сколько стоит 12-проц. сервак, если 2-проц. стоит 5 тонн, а 4-проц. 12...25?.. Кто его еще купит.

guest_20040621> Как это требования могут носить "рекламный характер?"

Вы действительно ни разу не встречали идиотских требований, которые ничем, кроме конъюнктуры, объяснить нельзя?А чем плохо такое объяснение?

guest_20040621> вероятность коммерческого успеха проекта, скажем так, немного
> уменьшится.

Imho нет. Коммерческий успех никак не связан с качеством продукта.Ясно, делаем строго удовлетворяющее спецификациям дерьмо, нанимаем гениев маркетинга. В таком случае действительно незачем разрабатывать качественные вещи (и спецификации тоже).

sergey888
1.Какая ОС грамотно загрузит 12 или 20 процессорный сервак?
чем?

sergey888ОС рассчитана на процессор и сопроцессор:)

guest_20040621выбор стандартов и спецификаций - на самом деле занятие очень непростое. И предполагает уровень квалификации ПМ сильно выше среднего. ;) В таких условиях "дерьмо" получится сильно вряд ли.Это разве дело ПМ? ПМ - прораб.

guest_20040621> Это разве дело ПМ? ПМ - прораб.

;) Боюсь, Вы слишком узко оцениваете роль ПМ.Как раз я-то нет; я высказал общепринятое понимание - я - ПМ!, я - аналитик!, а если я - программист, то распишите мне систему классов, но я не кодер а Программист! и платите мне много денег.

А я за широкий кругозор ;)

guest_20040621> А я за широкий кругозор ;)

...в свободное от работы время или проектах, не связанных с основной работой. ;) Как-то не вяжется с превознесением роли ПМ - он у Вас и системный архитектор, и менеджер проекта, и вообще исследователь, и одновременно практик с большим количеством набитых шишек :) И с никаким знакомством со смежными отраслями деятельности и историей собственной специальности.

guest_20040621С ERP закончили, я правильно понимаю? Или все только начинается? ;)Можно новый виток организовать.

Для начала стоило бы определиться с портретом типичного потребителя этой самой ERP. Сколько народу, какие производственные (ах, простите, бизнес-) процессы. Круг отраслей народного хозяйства.

А до того еще разок определить, что мы понимаем под ERP. Кивать что это общеизвестно не будем, так как стандарта нет.

Мне вообще не нравится термин ERP, чем плоха аббревиатура АСУ?

guest_20040621
Хороший ПМ - это формальный баланс между кривизной реализации (которая на самом деле присутствует в любом проекте) и стоимостью реализации. ;)Только никто этого не говорит вслух

guest_20040621Плохая реализация: явно указанные идентификаторы (ИНН и пр.); реализация чуть лучше: явно выделенные группы и имена идентификаторов; реализация еще чуть лучше: зависимость типов и имен идентификаторов от стран; реализация еще чуть лучше: зависимость типов и имен идентификаторов от стран и/или экстерриториальных образований; реализация еще чуть лучше: предыдущий вариант + локализация (т. е. языковые эквиваленты); реализация еще чуть лучше: предыдущий вариант + соответствия идентификаторов (т. е. функционально-смысловые эквиваленты); реализация еще чуть лучше: ... ;)) Любой из перечисленных вариантов может удовлетворять техническому заданию, но на самом деле imho ни один из них неприемлем. ;) Почему - это уже другой вопрос; хочу отметить, что, начиная с некоторого варианта изменения коснутся всей (или значительной части) структуры данных. Хороший ПМ об этом знает и не даст выйти разработчику за пределы оплаченной и/или согласованной работы. ;) Называть это знаниями предметной области? Смежных областей? Или все-таки опытом? ;)1. Чисто из опыта. Погоня за возможно большей обобщенностью структуры данных в итоге приводит к тому, что над СУБД с ее типами данных мы имеем а-ля то же самое, только более медленно работающее. Далеко не всегда имеет смысл иметь вместо поля inn поле в связанной таблице целочисленных атрибутов, в еще одной таблице название, в еще одной таблице локализованное название... Почему я и говорил, что вначале надо определиться с оправданной глубиной абстрагирования от свойств сущностей типа ИНН, адрес и т.п.
2. Определенные области структуры данных нельзя отдавать на откуп даже вашему очень хорошему ПМ; другие можно; про третьи (стандарты на структуру вновь добавляемых справочников, выбор степени нормализации структуры данных и т.д. и т.п., вплоть до именования и выбора типов полей) достаточно написать указивку для разработчиков и за несоблюдение бить плетьми нещадно.
3. Структура данных - часть модели предметной (проблемной? так и не знаю как правильно) области. Какая модель, такая и структура. Алгоритмы в модели у вас присутствуют? Вот под них надо и структуру проектировать. Если алгоритмов нет, то только, извините, чувство жопы ПМ может определить верный уровень "абстрактности" для структур данных.

guest_20040621Кстати, по-Вашему мнению, как поставит задачу ПМ? Хороший ПМ? Очень хороший ПМ? Почему? ;)Да как, очень хороший - по аналогии с известными ему решениями, если задача типовая, или в соответствии с объемом ресурсов, выделяемых на "эксперименты", если область неосвоеннная. Хороший (?) же поставит как написано в ТЗ, а потом будет по ходу дела пытаться понять, что (где) надо выбросить/упростить/схалявить, чтобы уложиться в сроки и т.д.

guest_20040621> Для начала стоило бы определиться с портретом типичного потребителя этой самой ERP.
> Сколько народу, какие производственные (ах, простите, бизнес-) процессы. Круг отраслей народного хозяйства.

Хм... так издалека? ;) Кстати, странно: вроде как "отрасли народного хозяйства" вышли из употребления вместе с народным хозяйством? Или мне так кажется?Народ остался, хозяйство тоже, посмотрите в окно, товарищ. Выбор терминологии - мое дело ;) Или вы кальки с американского предпочитаете? "Кейс" там и все такое?

Вообще да, именно так издалека, ибо 1000 или 100 пользователей - надо иметь в виду, употребимые методологии учета и анализа надо иметь в виду при проектировании. Хотя нет, не надо, потом мы поменяем названия кнопок и содержимое тестового примера и будем пиарить отраслевые решения (еще худшие чем оригинальное). Сделаем ERP сразу для всех.

guest_20040621> Мне вообще не нравится термин ERP, чем плоха аббревиатура АСУ?

Imho управление - более объемная задача.Ага. Для управления надо иметь ERP+CRM+ECM+EDMS+... хорошо бы покупатели ERP понимали границы применимости оных ERP.