---------------На ваш взгяд---------------------------
[1]
Сколько человек должно писать такую систему?
Сколько времени?
Какая квалификация и какого рода (предметные) специалисты требуются?
Сколько $$$ можно просить на заказ такой системы?
На что обратить внимание?
[2]
Какие опасные моменты или ошибки (в существующем проетном решении) вы видите?
[3]
Обладает ли (проектное решение)система необходимым уровнем инновации и интереса, чтобы за XXX времени покрыть стоимость разработки?
Существует ли на Ваш взгляд интерес к такого рода системе со стороны негосудартсвенных организаций?
Бегло прочитал что написано.
F>---------------На ваш взгяд--------------------------- F>[1] F>Сколько человек должно писать такую систему? F>Сколько времени? F>Какая квалификация и какого рода (предметные) специалисты требуются?
Любое количество человек, любое количество времени.
Квалификация — студенты, котороым надо повышать свой уровень. Более высокая квалификация не требуется.
F>Сколько $$$ можно просить на заказ такой системы?
Просить столько, сколько можно получить. F>На что обратить внимание?
На разбиение системы на небольшие части, которые можно было бы сделать в качестве курсовой.
F>[2] F>Какие опасные моменты или ошибки (в существующем проетном решении) вы видите?
Все красиво и хорошо, за исключением того что система в принципе нереализуема.
F>[3] F>Обладает ли (проектное решение)система необходимым уровнем инновации и интереса, чтобы за XXX времени покрыть стоимость разработки?
F>Существует ли на Ваш взгляд интерес к такого рода системе со стороны негосудартсвенных организаций?
Может sourceforge?
F>Спасибо.
Пожалуйста.
Здравствуйте, andsm, Вы писали:
F>>[2] F>>Какие опасные моменты или ошибки (в существующем проетном решении) вы видите? A>Все красиво и хорошо, за исключением того что система в принципе нереализуема.
Здравствуйте, andsm, Вы писали:
AA>Любое количество человек, любое количество времени.
F>>Сколько $$$ можно просить на заказ такой системы? A>Просить столько, сколько можно получить.
Вообще-то, принято говорить оценочные сроки работы и возможные затраты.
НА Ваш взгляд, какими они могут быть?
Re[3]: Помогите оценить трудозатраты
От:
Аноним
Дата:
01.07.04 13:00
Оценка:
Здравствуйте, flax, Вы писали:
F>Здравствуйте, andsm, Вы писали:
AA>>Любое количество человек, любое количество времени.
F>>>Сколько $$$ можно просить на заказ такой системы? A>>Просить столько, сколько можно получить.
F>Вообще-то, принято говорить оценочные сроки работы и возможные затраты.
F>НА Ваш взгляд, какими они могут быть?
За подобный анализ и оценки вообще-то деньги платят.
Это не простая работа.
А так я тебе могу назвать 20 человеко месяцев
это будет не лучше и не хуже любой другой оценки.
Здравствуйте, flax, Вы писали:
F>Здравствуйте, andsm, Вы писали:
AA>>Любое количество человек, любое количество времени.
F>>>Сколько $$$ можно просить на заказ такой системы? A>>Просить столько, сколько можно получить.
F>Вообще-то, принято говорить оценочные сроки работы и возможные затраты.
F>НА Ваш взгляд, какими они могут быть?
Ну ты и нахал! Мы свои то доки читать ленимся, а ты "трактат о агностиках" выкатил...
Сроки и затраты очень зависят от того, кто и как это будет реализовывать...
Вообще что бы дать совет о том, как их оценить, нужно лучше знать Вашу ситуацию. Есть ли у Вас команда, разработчики и какой у них опыт или это пока оценка "в общем"? Насколько спроектиравана система? Какую часть требований к ней вы знаете (примерно — десятую, треть, половину, почти все)?
Расскажите чуть больше — возможно удасться помочь. А так — можно с потолка назвать любую цифру от 18 до 2000 человекомесяцев и оказаться правым...
AF> Ну ты и нахал! Мы свои то доки читать ленимся, а ты "трактат о агностиках" выкатил...
Попробую вскоре выложить не в PDF, short review.
AF> Вообще что бы дать совет о том, как их оценить, нужно лучше знать Вашу ситуацию. AF> Есть ли у Вас команда, разработчики и какой у них опыт или это пока оценка "в общем"?
Команда есть, но она занята под более практические и краткосрочные проекты.
Идея состоит в том, чтобы прийти к некоторому "большому" человеку и положить ему на стол бизнес-план:
Вы нам даете XXXXXXX$ мы вам ?гарантируем? их возвращение через YY time.
Вдобавок, мы для вас с помощью этой же системы сделаем много хорошего.
Таким образом
1) Предполагается получить некоторую сумму
2) Набрать команду разработчиков
3) Создать систему
4) Продать ее ( в гос. секторе есть кому продавать, но хотелось искать и на стороне, зарубежом особенно
AF> Насколько спроектиравана система?
Не намного больше, чем видете в документе.
AF> Какую часть требований к ней вы знаете (примерно — десятую, треть, половину, почти все)?
Требования определяем мы. Такая система, IMHO, очень нужна, хотя это не все понимают и продолжают лепить на коленях. Это мы видим, смотря на те процессы, которые сейчас происходят, и проблемы, которые есть.
Возможно, несколько глобализированные ( т.е. с запасом) общие требования можно увидеть по части 1, "9 проблем построения больших распределенных корпоративных систем". Впрочем, я вскоре постараюсь написать что-либо уменьшенное, чтобы легче было бы понять, что содержится в документе.
Здравствуйте, flax, Вы писали:
F>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Ну ты и нахал! Мы свои то доки читать ленимся, а ты "трактат о агностиках" выкатил... F>Попробую вскоре выложить не в PDF, short review.
Чтож — тогда его и посмотрим...
AF>> Вообще что бы дать совет о том, как их оценить, нужно лучше знать Вашу ситуацию. AF>> Есть ли у Вас команда, разработчики и какой у них опыт или это пока оценка "в общем"? F>Команда есть, но она занята под более практические и краткосрочные проекты.
То есть, резюмируя, команды нет, но зато есть опыт реализации более практических и краткострочных проектов. Это уже хорошо...
F>Идея состоит в том, чтобы прийти к некоторому "большому" человеку и положить ему на стол бизнес-план: F>Вы нам даете XXXXXXX$ мы вам ?гарантируем? их возвращение через YY time. F>Вдобавок, мы для вас с помощью этой же системы сделаем много хорошего.
Идея светлая. Но для того, что бы попробовать её реализовать — нужен бизнес план. А для того, что бы его написать, Вам нужно чётко представлять что и как сможет делать Ваша система и чего она делать не сможет. Т.е. Вам нужно спроектировать систему (если не до уровня кода, то до уровня алгоритмов — точно), оценить трудозатраты и риски по каждому её кусочку, умножить и то и другое на два, аккуратно это оформить в виде бизнес плана и с этим идети к "большому человку". Имейте в виду — полно готовых систем которые фирмы, разработавшие их пытаются хоть кому то продать. Потому будьте готовы к вопросам — а зачем это кому то нужно и чем ваша не написанная система лучше чем вон те 150 готовых и работающих.
F>Таким образом F>1) Предполагается получить некоторую сумму F>2) Набрать команду разработчиков F>3) Создать систему F>4) Продать ее ( в гос. секторе есть кому продавать, но хотелось искать и на стороне, зарубежом особенно
Путь оригинальный. Осталось по нему пройти. Вопрос в заказчике. Будет заказчик(и) — будет система...
AF>> Насколько спроектиравана система? F>Не намного больше, чем видете в документе.
Тогда шансов столько же, сколько шансов что документ сам превратиться в код... Если конечно у Вас уже нет заказчика или гарантии того, что он у вас появится — например лобби в госструктуре.
Что бы этот документ превратился во что то, с чём можно начинать работать, потребуется полгода активной работы по проектированию, изучению рынка, анализа рентабельности и трудозатрат проекта, а так же — рентабельности применения системы.
AF>> Какую часть требований к ней вы знаете (примерно — десятую, треть, половину, почти все)? F>Требования определяем мы. Такая система, IMHO, очень нужна, хотя это не все понимают и продолжают лепить на коленях. Это мы видим, смотря на те процессы, которые сейчас происходят, и проблемы, которые есть.
Требования ВЫ не можете определять. Как я не могу определять требования на систему мониторинга океанского дна. Я просто в этом не разбираюсь. Нужны спецы из предметной области.
Вы далеко не единственные, кто понимает, что такая система нужна. Есть ещё и микромонстры, кто может её легко реализовать. Возможно Вам повезло и Вы нашли золотую жилу. Но гораздо вероятнее, что вы просто чего то не заметили и идея вовсе не так привлекательна
F>Возможно, несколько глобализированные ( т.е. с запасом) общие требования можно увидеть по части 1, "9 проблем построения больших распределенных корпоративных систем". Впрочем, я вскоре постараюсь написать что-либо уменьшенное, чтобы легче было бы понять, что содержится в документе.
Вот именно! Пока это набор общих (безусловно благих) идей, из которого совершенно неочевидно, что из этого может получиться и как это будет выглядеть на практике...
PS. Прошу прощения, если показался черезчур нахальным. Я вовсе не хотел критиковать Вашу идею или систему. Однако что бы что-то получилось — холодный душ бывает весьма полезен. А вот саму инициативу можно только поприветствовать!
Исследуется возможность создания платформы для построения крупных распределенных корпоративных систем.
Краткий обзор:
Глава 1
Вначале главы мы предоставляем определенную информацию, описывающую основные направления развития корпоративных систем:
SOA и повышение открытости данных,
GRID и интегрирация вычислительных ресурсов,
RealTime и мобильность;
1) Мы описываем подходы к построению системы РАСПРЕДЕЛЕННОЙ, КОРПОРАТИВНОЙ И СВЕРХКРУПНОЙ. Этим будет определяться и выбор технологий, и анализ вопросов.
2) Представлен цикл проблем (9 problems), характерных для исследуемых систем.
Указанные проблемы разбиты на 3 блока.
Первый блок вопросов связан с большим размером рассматриваемых систем (The size matters), из-за чего представляется невозможным непосредственно контролировать или влиять на каждый конкретный узел системы. Даже в средних по размеру корпоративных системах, наличие сегментов, находящихся вне прямого видения основных серверов, вопросы развертывания приложений и их подбора, приводят к схожим эффектам.
Предлагается исследовать проблему с точки зрения технологий Autonomic Computing.
Второй блок вопросов связан с некоторыми техническими проблемами (The technologies prevails), которые возникают, например, при больших нагрузках на систему, и о которых разработчики могут не подозревать.
Третий блок вопросов (Domination of the human) связан с проблемой взаимодействия пользователя и системы, а также разработчика и системы.
Описанные вопросы определяют некоторый круг проблем, для решения которых и предназначена система XSorus.
Глава 2
Система должна облегчить процесс обмена информацией между различными участниками, а также обеспечить механизмы по организации информационной системы. Поэтому, в качестве основного примитива системы выбран XML, как формат, который при должном проектировании позволяет осуществлять прозрачный обмен, а также позволяет применять механизмы описания данных.
Организация информационной системы, как набора XML документов, связанных друг с другом с помощью стандартов XInclude, XLink, XPointer, документов, содержание которых описано, например, с помощью схем XSchema, Relax, Schematron, позволяет, на наш взгляд, добиться:
1) Большой доли независимости от конкретных поставщиков решений и обеспечить хороший уровень доступа к данным из разных сред
2) Явного выделения смысловых структур данных
Однако применение в корпоративной среде данных стандартов может быть ограничено в силу многих проблем.
Требование целостности данных и ссылочной целостности, понятие жизненного цикла документа, многочисленные ограничения, связанные с низкой эффективностью XML-ориентированных решений, не позволяют безболезненно применять указанные XML-технологии внутри крупных корпоративных систем.
В настоящих исследованиях сделана попытка рассматривать в качестве базового понятия объект, который
1) поддерживает DOM и SAX интерфейсы доступа
2) имеет интерфейс по вычислению XPath выражений
3) удовлетворяет требованиям Post Schema Validation Infoset, т.е. явно контролирует целостность типов данных и содержит информацию о них.
При явном указании необходимых схем для используемого типа документа, представляется возможным сгенерировать необходимые (под заданный тип) стуктуры данных и алгоритмы, которые позволят эффективно работать с данным типом XML документа.
Затрагивается упрощенный способ построения такого объекта средствами .Net.
В этой же главе рассматривается некоторые дополнительные механизмы обработки данных, такие как пайпы, заимствование и маршрутизаторы XML-документов.
Глава 3
В крупных системах необходимо учитывать множество соглашений нетехнического характера. В определенной степени, выполнение данных соглашений может влиять на принятие пользователями и распространение системы больше, чем любые технические нововведения.
В этой же главе рассматривается проблема построения крупных баз знаний.
Глава 4
В главе описан подход к объектному дизайну некоторых объектов, а также рассказано о тестовых реализованных нами прототипах. Обозначены дальнейшие шаги по реализации этой системы.
Здравствуйте, andsm, Вы писали:
A>Бегло прочитал что написано.
А подумать над прочитанным?
F>>Сколько человек должно писать такую систему? A>Любое количество человек, любое количество времени.
Один не управиться.
F>>Какая квалификация и какого рода (предметные) специалисты требуются? A>Квалификация — студенты, котороым надо повышать свой уровень. Более высокая квалификация не требуется.
Студенты на больших данных не потянут.
F>>На что обратить внимание? A>На разбиение системы на небольшие части, которые можно было бы сделать в качестве курсовой.
Ты курсовые писал? Или знаешь как их пишут?
F>>[2] F>>Какие опасные моменты или ошибки (в существующем проетном решении) вы видите? A>Все красиво и хорошо, за исключением того что система в принципе нереализуема.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, andsm, Вы писали:
A>>Бегло прочитал что написано.
R3>А подумать над прочитанным?
Подумал, поэтому и написал такой ответ.
F>>>Сколько человек должно писать такую систему? A>>Любое количество человек, любое количество времени.
R3>Один не управиться.
На мой взгляд, система нереализуема — поэтому подойдет любое количество человек.
Под нереализуемостью я понимаю доведения системы до уровня, на котором к системе возникнет интерес со стороны заказчиков. Предлагаемое решение пытается во многом повторить функциональность существующих систем, таких как MS Biztalk Server и т.п, но на более сложном уровне. MS почему-то не разрабатывает Biztalk в сторону единой программы для отрасли. Для обьединения данных в рамках отрасли часто используются единые XSD-схемы, для описания общих понятий, и тот же Biztalk или собственные программы. Ни разу не слышал про единую программу для автоматизации бизнес-процессов в отрасли. F>>>Какая квалификация и какого рода (предметные) специалисты требуются? A>>Квалификация — студенты, котороым надо повышать свой уровень. Более высокая квалификация не требуется.
R3>Студенты на больших данных не потянут.
С учетом того что я написал выше, это неважно. — Единственное что можно с этого проекта получить это опыт.
В то что какая-то мелкая команда может написать продукт по функциональности превосходящий множество конкурентов веры почему-то нет.
F>>>На что обратить внимание? A>>На разбиение системы на небольшие части, которые можно было бы сделать в качестве курсовой.
R3>Ты курсовые писал? Или знаешь как их пишут?
Писал, и немало . Как пишут знаю.
F>>>[2] F>>>Какие опасные моменты или ошибки (в существующем проетном решении) вы видите? A>>Все красиво и хорошо, за исключением того что система в принципе нереализуема.
R3> Они решили туда AI запихать?
Здравствуйте, flax, Вы писали:
F>К документу http://opensgd.at.tut.by/Framework.pdf добавилось содержание (через bookmarks), а также исправлены опечатки.
Посмотрел. Довольно интересно. Но то на что вы замахиваетесь (по крайней мере как я понял прочитанное) — не много не мало отраслевой стандарт. Работа уровня микрософт, IBM или Apple. Наверняка её можно сделать, но сколько потребуется ресурсов для подобного проекта лучше спросить у Билла Гейтса или у Стива Джобса.
Чего там не хватает (или по крайней мере я не увидел) — так это конкретики. Для какого конкретно заказчика и для каких именно его задач вы собираетесь использовать систему — хотя бы на начальном этапе? Если рассмотреть Вашу идею с точки зрения конкретного проекта — оценить ресурсы станет возможным.
1) Возможно, ошибаюсь, но мне кажется, что вы не совсем точно истолковали смысл системы.
Существуют различные(!) локальные системы автоматизации.
Необходимо интегрировать информационные потоки между ними.
Нет никакой общей, сколь-либо проработанной, системы уровня управления (информационно-интеграционной) группами предприятий (построенными не на одной, а на различных технологиях).
Т.е такую систему нужно создать. (*)
Мы решили строить систему на базе XML-технологий (причины описаны в документе) (**)
Фактически, к создаваемой системе публикуется интерфейс ( с помощью которого другие смогут общаться как между собой, так и просто к спец. модулям системы). Решено, что данный интерфейс должен обладать некоторыми легкими для понимания (разработчиками) базовыми концепциями.
Размещение информации в виртуальной аналогии файловой системы, понятие XML-файла, поддержка некоторых дополнительных механизмов, на наш вгляд, должны обеспечить легкое понимание и расширяемость системы.
В случае, если отдельное предприятие, или модуль общается с системой весьма интенсивно, мы хотим предложить некоторые библиотеки (объекты), компоновка с которыми обеспечит более высокий, чем при применении стандартных решений, уровень производительности.(***)
Безусловно, на базе концепций системы можно строить различные системы. Но, кажется, мы не постулировали желание, создавать все сами (see Problem 1.1 документа)
2) Впрочем, вы поставили интересный вопрос. Кажется для разработчиков, такой framework может быть интересен?
Вероятно действительно неправильно понял — файл был большой, и внимательно его читать жедания не было, лишь быстро просмотрел.
В таком случае, если вы не собираетесь делать единую программу для отрасли, обьясните чем ваше решение лучше чем MS Biztalk сервер и его аналоги?
Они уже предоставляют систему, которую, после небольшой доработки или без нее — просто конфигурированием — можно использовать для реализации декларируемых вами целей. Какие у вашей системы имеются уникальные конкурентные преимущества?
Суть ясна — здорово! С точки зрения software economics это "обычная" система, т.е выбрав метрику можно оценить ее сложность , например, исходя из функциональности и "эскиза" ее архитектуры, а значить оценить затраты на ее разработку (например, временные), исходя из величин производительностей разработчиков
F>[1]F>Сколько человек должно писать такую систему? F>Сколько времени?
Это зависит от условий проекта (сроки, бюджет, персонал, квалификация и т.п). Как уже было сказано, "теоретически" эту систему может создать 1 разработчик с минимально возможной квалификацией
F>Сколько $$$ можно просить на заказ такой системы?
Чем больше, тем лучше, но все определяется спросом. Возможно, что когда эта система будет закончена, то она не будет пользоваться большим спросом
F>[3]F>Обладает ли (проектное решение)система необходимым уровнем инновации и интереса, чтобы за XXX времени покрыть стоимость разработки?
Чтобы за XXX времени покрыть разработку, нужно знать сколько "ХХХ времени" будет стоить в денежном выражении, т.е фактические затраты. Также следует учесть "обесценивание" этой системы, т.е снижение ее относительной рентабельности — на опрделенном этапе инвесторы(включая разработчиков, "инвестирующих" в проект свой труд) могут выйти из проекта
F>Существует ли на Ваш взгляд интерес к такого рода системе со стороны негосудартсвенных организаций?
Why not? В свете Федеральной программы "Электронная Россия"...
Здравствуйте, RUPman, Вы писали:
F>>Сколько $$$ можно просить на заказ такой системы? RUP>Чем больше, тем лучше, но все определяется спросом.
Не просто спросом, а возможным спросом с учетом рекламы. Две разные вещи.
Они решили туда AI запихать? 
