Большой проект (клиент-серверная система)

Гость

Я Вас обманул?

Вроде как нет. Так используйте их.

Потому что нужны ГАРАНТИИ. А у Вас есть ВЫБОР или платить за ГАРАНТИИ, или ОБУЧАТЬСЯ!

W-O-W! Супер! Даздравствует JBuilder! Он умеет делать EJB!

Я в Вас ни секунды не сомневался и именно это хотел показать. А тут

тоже посмеялся. Просто вспомнил, как на рабочем столе ярлычки делают.

Это просто идеология. Не стоит обсуждения.

HorstWessel добавил [date]1114071488[/date]:
jek

В этой отрасли специалистов "широкого профиля" нет.

 

Bob
Эт точно. Вообще изначальный вопрос звучит смешно.
HorstWessel

Что вы под эти понимаете. Если что надо хорошо знать одно средство, а не изучать кучу разных то да на 100%. Но опять же это не говорит что одно лучше другого.

 

а, вот еще в огонь маслица подолью.
HorstWessel, замените в Ваших рассуждениях J2EE на .Net.
за .Net платить не надо - все в составе Windows Server.

 

HorstWessel

бизнесу нужны гарантии, а не обучаться. Мы же ведем разговор о некоей будущей системе, а не о том, нужно ли мне обучаться или нет.

Я рад, что я Вам открыл глаза. Но не все jbuilder-ы одинаковые даже в пределах одной версии. Если это для Вас тоже открытие, то я еще больше рад.

Ярлычок - обалденное средство для запуска приложения тупым пользователем.

AlTk

Он уже отвечал на этот вопрос.

что по его понятиям, подразумевает то, что это использовать нельзя.
на это можно ответить, а как же айбиэмовские AS/400 и AIX и вся сопутствующая линейка, и HP, с его HP-UX? Закрыто же все. Нет, конечно можно сказать, что IBM двинулась к эклипсу и джаве. Но это все равно ерунда. Как известно, крупнейшим производителем программного обеспечения является не Microsoft, а IBM. Вот так вот, с закрытыми стандартами то.
Хотя говорить о закрытых стандартах говорить в этом случае все равно нельзя. Стандарты открытые, исходные тексты - да, закрыты. а стандарты - нет. если бы они были закрыты, то и программировать под них было нельзя. А под .NET можно. да еще бесплатно. SDK же включает в себя компилятор C#, да еще и не за деньги.

2 dj
После всего этого многостороннего бреда сделайте для себя выводы следующего свойства:
1. Для того, что бы определится со всем что вам нужно, необходимо провести предпроектые исследования и собрать требования к Вашему будущему продукту. требования нужно разделить на несколько групп: бизнес требования, требования к доступности, требования к тех.обеспечению, возможно требования к архитектуре, если будут, и т.д.
на основании этих требований составляется документ, в котором оцениваются трудозатраты, применияемые технологии, архитектура и соответственно бюджет.
2. Не имея этого документа на руках, или имея его, но не согласованный с заказчиком, или с не удовлетворительным бюджетом браться за дальнейшие дела даже не стоит.

 

Гость,
"бизнесу нужны гарантии, а не обучаться. Мы же ведем разговор о некоей будущей системе, а не о том, нужно ли мне обучаться или нет."
именно так. для Заказчика известие о том, что система будет работать не гарантированно, но за то разработчики этой системы обучились, будет не совсем приятным.

"Он уже отвечал на этот вопрос."
да, там много написано, всего и не углядишь.

"...собрать требования к Вашему будущему продукту. требования нужно разделить на несколько групп: бизнес требования, требования к доступности..."
о! есть здравые люди (в Волгограде?).

HorstWessel,
J2EE не является полностью масштабируемой - нельзя с крупного просто так перепрыгнуть на малое и наооборот. кстати, в отличие от той/того же .Net.

 

Наконец то начали появляться разумные мысли. Надо ещё посоветовать прочитать MSF. Или нечто аналогичное, если есть алергия на изделия МС.

 

Bob,
"... Или нечто аналогичное..."
да сколько угодно:
ISO12207, CMM, MSF, RUP, SCRUM, XP, CRYSTAL, ASD, PRINCE2.

 

AlTk

В Волгограде.

2 dj
Еще есть FDD. Есть такая небольшая, но очень полезная книжка, называется "Функционально=ориентированная разработка ПО". Замечательная вещь. особенно для Вас, видимо. Есть пара глав, о том, как нужно собирать требования и как их группировать, и что с ними делать дальше. Сама книжка в качестве примеров использует Java и J2EE, но она (методика) применима к любой архитектуре.

 

AlTk

А Windows Server есть на Красном Октябре с кряком! Поздравляю Вас, это как раз то что нужно заказчику. Bob, случайно не это есть "разумная мысль".

Но кто их обеспечит? Заказчик? Тогда какой ценой? Или собственный IT? Во всяком случае, еще раз повторю, у Вас есть выбор! Вы же навязывете автору топика свои

и уже требуете с него

При этом пугают людей: "А знаете сколько стоит J2EE?"


А вообще мне понравилось:

Сначала в адрес открытых стандартов

Следующее предложение

Затем суровый вердикт: (Вы случаем не из IBM?:D)

И потом опять

Господа, Вы хоть вдумывайтесь в то, что пишите! Дальше поговорите между собой, мне уже просто надоело.

 

HorstWessel
О как! Нет слов!
Я вообще-то всегда думал, что бизнес обычно является заказчиком. А перед тем как что-то делать надо узнать, чего же хотят от того, что я сделаю.

А про Мирософт и IBM - это чистая правда. Мне и самому было удивительно, но это так.

 

HorstWessel,
Вы когда на радиорынок за крякнутым Windows Server пойдете, то заодно уж тысячи три долларов для "бесплатного" линуксового сервера прихватите.

 

Замечание Гостя очень даже верное, можно даже сказать принципиальное, ибо в противном случае проект обречен.

 

О чем вообще речь? Впечатление, что эта тема не для Софта, а для Флэйма!
Ребятушки захотели сделат вечный двигатель на коленках и за копейки, но не знают как?
Начинать надо действительно с бюджета. Но надо и понимать какие задачи каким путем необходимо решать.
Мухи должны быть отдельно, а котлеты отдельно.
И не стоит думать что все можно сделать программным путем. Если рабочие станции отстойные, то лучше в любом случае работать либо через браузер, либо использовать терминальные решения.
И что означает сделать универсальную систему не заточенную под конкретную организацию, но при этом не конструктор. Чем вам не нравятся конструкторы?
Системы автоматизации существуют и развиваются не одно десятилетие. И уже давно выработались два подхода к их разработке и внедрению пользователям.
Один из них как раз "конструкторы", а второй предполагает, что разработчики "уже заложили все необходимое в системе" и вам только надо перелопатить бизнес-процессы своей фирмы под систему. И оба подхода живут и здравствуют.
Причем по второму пути идет в основном компания SAP, особенно с SAP-R3 (на сколько я знаю). Но если вы хотите повторить SAP-R3? Флаг вам в руки, только бюджета не хватит, однозначно.

 

Tiamat,
"... эта тема не для Софта, а для Флэйма!..."
дадада.

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

"Причем по второму пути идет в основном компания SAP, особенно с SAP-R3 (на сколько я знаю). "
опять неправда Ваша. это тоже конструктор.

 

AlTk

Это конечно конструктор. Но путь однозначно второй. Достаточно посмотреть на пропорции между реинжинирингом БП и настройкой ПО в проектах.
Кстати много кто на самом деле идет вторым путем. Т.е. крайностей то почти нет. Но вот тяготение явно присутствует.

 

AlTk

Согласен!
А что SAP тоже конструктор... ну все мы немного лошади! И без возможностей доработки вообще ни кто не обходится. Вопрос даже больше не в технической возможности, а в подходе к вопросу внедрения. Даже с системами, которые позиционируют именно с "широкими возможностями для доработки под задачи заказчика". Если фирма-внедренец обладает уже готовой разработкой подходящей под отрасль заказчика, то клиента будут гнуть на изменение бизнес-процессов, а не дорабатывать систему под его специфику. Ведь это быстрее и дешевле, а денежки возьмут по взрослому :D