Re[3]: Апплет - за и против
От: nant Россия  
Дата: 07.11.05 18:59
Оценка: 15 (2)
Здравствуйте, MT, Вы писали:

MT>Здравствуйте, nant, Вы писали:


N>>Здравствуйте, MT, Вы писали:


MT>>>Поделитесь мнением и опытом изпользования апплетов на клиентской части.

MT>>>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано.
MT>>>Спасибо.

N>>Приложение используется работниками организации заказчика, или его клиентами?

N>>Каково количество пользователей (единицы, десятки, сотни, тысячи, больше)?

N>>Вопросы имеют принципиальное значение.


MT>Сотрудниками предприятия (офисы удаленные в том числе)


Так я и думал.

Я смотрю там выше по ветке методом последовательных приходят к правильному решению с правильной мотивацией. Мотивация для заказчика — финансовая целесообразность.

Решение вопросов:
1) Стоимости поддержки и наличия deprecation — рефакторинг.
2) Скорости работы — рефакторинг + оптимизация, если таковая понадобится после рефакторинга.
3) Проблем с версией Java — переход на JDK 1.5. Лучше после рефакторинга, так как в общем случае — дешевле.
4) Проблем с установкой Java — сборка инсталляционного пакета, который установит нужную версию Javа или, если таковая уже установлена, сконфигурирует Java Plugin отдельного браузера
Deployment такого пакета — через механизмы ОС ( profile, group policy, etc), либо предложением пользователю: у вас не та версия, поставьте заботливо подготовленный пакет.

А вбухивать деньги (а вы посчитайте во что выльется перетестирование и миграция, да) и время только для того, чтобы уйти с обной технологии на другую, потому как оная не нравится разработчику — я бы на месте заказчика (его CIO как минимум) не стал.

Я виду не все, поэтому может быть и другой вариант развития событий — вы доказываете почему плохо _существующее_решение_, а тезнология на котором оно сделано — это второй план. Даете оценку на создание нового решения и на приведение того, что есть в нужный заказчику вид (что именно этот вид нужен заказчику — нужно доказать). И тогда уже разговор приобретает предметный для закахчика вид. X1 против X2 с возможностями F1 против F2

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

<advise nooffence="on">
Cоздавать себе объем работы манипулированием тем, на какой технологии сделана система — не есть профессиональный подход. Хороший игрок — это тот, кто не проигрывает с плохими картами, а не тот, что выигрывает с хорошими.
</advise>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.