Насколько я понимаю, под болезненностью Вы подразумеваете косвенные потери от простоя и снижения эффективности работы? Тогда они точно превысят прямые затраты на модернизацию. Вот тут то и подумаешь, "А на фига менять стабильно работающую систему и терять при этом кучу бабла?"
Иллюзия. Вы пробовали заточить под себя тот же OpenOffice, например в части совместимости с MS WORD ( а куда ж партнеров то девать? Они то прелестей OpenSource не признают), например при вложенных во Witer графиках, построенных на основе табличного процессора? Там идеология на уровне ядра различается.
А с чего Вы взяли, что я как то связан с MS? Просто есть три основные схемы лицензирования ПО. Вы говорите, что одна из них самая худшая.
Не совсем так. Большую часть ядра Linux написали штатные программисты SUN и IBM, под руководством штатных системных архитекторов и аналитиков. :)
Ой, не скажите. Давайте доточим Джумлу до полной кальки MS SharePoint. Даже немного упростим задачу и не будем требовать редактирования вложенных файлов одним кликом, ибо ActiveX - не стандарт. А все остальное можно реализовать на Java aplets. Для примера возьмем небольшого заказчика, конторку этак человек на 40 - 50. В какие рубли и трешки и в какие сроки Ваш программист сделает необходимую "заточку"?
Страшное заблуждение. При использовании OpenSource вы так же связаны по рукам и ногам лицензиями. Это просто совершенно другая схема бизнеса. Почитайте внимательно лицензии на OS продукты, найдете много для себя интересного.
Почему надо забыть. Желательно не просто навалить кучу дерьма, но и заодно объяснить, как производить переход, и во что это удовольствие выльется. OpenSource это не всегда бесплатно. Даже если Вы устанавливаете бесплатный софт, это все равно требует времени и денег.
На встроенном контроллере и на SATA хардюках ставьте 10.
Это как так? У меня в серваке 6 SCSI дисков. 2 - в зеркале (1) для системы, логов и приложений, 3 - в пятом райде. Еще один в горячем резерве. В прошлом году при вылете одного из дисков система сама подцепила резервный диск и все синхронизировала. Нам осталось только через несколько дней вытащить убитый диск и поставить вместо него новый. Правда у меня контроллер хоть и на матери но это полноценный Adaptec с IBM-овской прошивкой. На софтовых рейдах, говорят, все не так гладко.
Мы пользуем Quickr от IBM.
Для каждого проекта создается мини сайт, называемый Place, в который приглашаются участники. Каждому изначально можно задать уровень доступа. Из стандартных фич каждого Place - Главная страница с целями и задачами проекта, Форум, Библиотека документов, Задачи, Календарь. Внутри Place можно создавать кабинеты, доступные нескольким участникам Place. Для каждого документа можно указывать круг лиц, которые могут читать или редактировать документ.
Из приятных фич - возможность автономной работы ( Place можно реплицировать на ноут и работать с документами в самолете, а потом еще раз реплицировать) и интеграцией с виндовым эксплорером и Офисом. В результате чего можно редактировать или сохранять файлы прямо в Place. Правда для этих фич надо скачивать небольшие драйвера и доступны они только для MS Windows. А так, в отличии от MS Share Point ( кстати, тоже неплохая штука для таких целей ), через броузер работает в любых OC ( по крайней мере пробовали в SuSe с КDE и Leopard ) и всех броузерах, ибо ActiveX везде может быть замененн Java аплетами.
Есть встроенные средства разработки. При небольшом напряжении ума головы можно на нем написать даже несложную систему документооборота.
Из минусов - пропертилитарный ( лицензируется на каждое рабочее место ) и работает только на WebSphere или Domino ( Не шибко популярные Web сервера )
Вот тут небольшое описание на русском языке
Это зависит от того, как процесс калькуляции стоимости поставить.
Мне заказчик обычно дает свое ХЗ ( Правда в нашей терминологии это Функциональные Спецификации ). Из него никогда не следует однозначного определения трудозатрат и стоимости.
Поэтому я начинаю задавать уточняющие вопросы по механизмам реализации и управления. В результате появляются Технические требования. Как раз именно их я и включаю в договор на разработку и внедрение. И только по ним производится
Второй вариант - Это отдельный договор на ТЗ, на основании которого не только мы но и любые разработчики смогут его реализовать.
Грамотный админ, даже на Colo сервере, будет :)
Простите меня за убожество, но я работаю в другой технологии и не знаю тонкостей PHP+Apache.
Разве системный администратор не может лимитировать максимальное время выполнения скрипта на уровне Web сервера? Т.е. Любой программист может завесить процесс сняв лимит на его выполнение и отправив в бесконечный цикл?
Как бы вам это не показалось странным, но офис-менеждер и бухгалтер - это такие же участники проекта как и системные аналитики, программисты и тестеры. И нужно это для того, чтобы программист и аналитик максимально эффектно использовали свое время, а не отвлекались на всякую фигню.
Это как в армии - службы тыла и штабы составляют тем большую часть штата, чем выше уровень соединения.
Ну хоть убей меня, чем крупнее проект тем меньше в нем кодерских трудозаорат.
1. Общий менеджмент проекта, написание технических требований, функциональных спецификаций, ТЗ.
2. Организация работы программистов ( хотя бы чтобы интернет бесперебойно работал, кофе в кофемашине всегда было, бухгалтерия опять же )
3. Организация взаимодействия программистов ( планирование работ, контроль )
4. Организация взаимодействия с ИС заказчика
5. Разработка документации
6. Тестирование
7. Внедрение и обучение персонала заказчика.
Где тут время программиста?
Или это все тоже программист должен делать?
Все абсолютно верно. Но, как всегда бывает "любовная лодка разбилась о быт".
Нормальному заказчику нужна максимальная эффективность за минимальный бюджет. Не все могут осилить бюджет экстремального программирования. Следовательно, в большинстве заказных работ рефакторинг не катит. Зато через 5-7 лет эксплуатации продукта заказчик может выделить отдельный бюджет на новую версию продукта.
Все верно. Я как раз и пишу о том, что надо изначально все правильно проектировать. Только не понимаю, зачем копи-пасте, можно и библиотеки использовать :)
А вот копи-пасте, да еще с модификацией кода по месту - кратчайший путь к бардаку и потере управления :).
Мэкс добавил 09.06.2008 в 10:02
Вообще - то цикл действий по внесению изменений что по частям, что целиком - один:
1. Планирование изменений и определение зависимых процессов и данных по изменению.
2. Внесение изменений в прототип
3. Тестирование
4. Исправление ошибок
5. Еще раз тестирование
6. Разработка конвертора данных ( как правило структура баз данных меняется )
7. Тестирование конвертора данных
8. Импорт реальных данных в прототип
9. Проверка импортированных данных
10. Документирование изменений или выпуск новой версии документации
12. Принятие решения о модификаци рабочей системы.
13. Модифиация рабочей системы.
И все это только в случае, если мы можем остановить систему на несколько часов для апдейта.
Остановка системы например в банке или пенсионном фонде - это огромные организационные и технические трудности.
Если мы не можем останавливать систему, все усложняется в разы.
Внесение непосредственно изменений программистом в таком процессе - не более 10% трудозатрат.
Вы хотите сказать, что можете сделать рефакторинг при необходимости смены архитектуры системы?
