Я не знаю примеров, когда был просто выбран или "выбран в результате тендера" (тендер - в отдельных бОООльших кавычках) адекватный подрядчик для разработки IT-системы по госзаказу.
И я уверен, что для Палм это легко выполнимая задача
А я вот не думаю. Я думаю все спецы оттуда уже поразбежались по конкурентам.
У КПК сейчас одна проблема - размер. Он уже достаточно мал, как у моего старенького Qtek S110, но хочется тоньше и легче. И я думаю отнюдь не Palm имеет инженерные ресурсы для радикального решения этой проблемы. Динамичнее всего тут движется HTC.
Вообще ТЗ - такой расплывчатый документ и надо иметь общее понимание его предназначения.
Я ТЗ называю приложение к договору, в котором описываются границы проекта, чтобы исполнитель не сделал меньше, чем получил денег, а заказчик не требовал больше, чем заплатил. Т.е. это документ, который можно достаточно быстро разработать, без больших временных затрат со своей стороны и без финансовых затрат со стороны клиента.
Я в ТЗ включаю:
1) Общие сведения
2) Основание для разработки (ссылка на договор)
3) Назначение разработки (цели и задачи)
4) Требования:
- к функциональным характеристикам (для сайта - общее описание структуры и интерактивных элементов);
- к надежности;
- условия эксплуатации;
- к информационной и программной совместимости;
- к поставке;
- к документации.
5) Стадии и этапы разработки (этапы и содержание работ)
6) Порядок контроля и приемки
Структура сайта и шаблоны страниц с той степенью проработки, что у вас в статье, это уже скорее часть эскизных или технического проекта (по госту), или Functional Requirements, а может и Software Requirements (по RUP-у).
У вас получается, что ТЗ - это такой супер-документ про "все сразу". Не понятно, когда его разрабатывать: до подписания договора и подписывать вместе с договором, или уже после подписания договора, но тогда что приложить к договору, чтобы ограничить обе стороны?
Optimus Maximus и не расчитан на всех, кто тут удивляется её цене. Она в первую очередь для профессионального пременения.
Много видел разные клавиатуры для систем монтажа и всяких 3D, у которых отдельные группы кнопок раскрашены. Вот там этим клавам и место. И цена в полторы штуки там никого не смутит.
Да и никогда первые на рынке не продавали что-либо задешево. Так что адекватная цена.
Я делал большой магазин www.fortnumandmason.com на Microsoft Commerce Server. Он стоит кучу денег, в нем куча функциональности, но и куча геммороя.
Так что в любом решении будут плюсы и минусы. Всегда хочется сделать самому "в сто раз лучше", но часто это или переоценка своих сил или пустое расходование ресурсов.
Главное - бюджет. Если клиент оплатить разработку магазина с нуля или есть желание инвестировать свое время, то да.
У меня сейчас желания такого нет и нужно готовое решение. Указаный ниже osCommerce VAM Edition похоже единственный вериант, где есть весь функционал и интеграции для русского магазина. А с дизайном думаю разберемся :)
Долгой загрузки никогда не замечал, тем более в IE. Все работает замечательно и в IE и в Firefox (в том числе и на Маках). Все кэшируется и сжимается.
Если под этим имеется ввиду WYSIWYG-редактор, то беру свой хабратопик обратно :)
Решением будет какое-то радикальное открытие, которое отразится на всей отрасли мобильных устройств.
А я вот не думаю. Я думаю все спецы оттуда уже поразбежались по конкурентам.
У КПК сейчас одна проблема - размер. Он уже достаточно мал, как у моего старенького Qtek S110, но хочется тоньше и легче. И я думаю отнюдь не Palm имеет инженерные ресурсы для радикального решения этой проблемы. Динамичнее всего тут движется HTC.
Думаю в составе и содержании проектной документации многое зависит от механизма продажи и клиента.
Я ТЗ называю приложение к договору, в котором описываются границы проекта, чтобы исполнитель не сделал меньше, чем получил денег, а заказчик не требовал больше, чем заплатил. Т.е. это документ, который можно достаточно быстро разработать, без больших временных затрат со своей стороны и без финансовых затрат со стороны клиента.
Я в ТЗ включаю:
1) Общие сведения
2) Основание для разработки (ссылка на договор)
3) Назначение разработки (цели и задачи)
4) Требования:
- к функциональным характеристикам (для сайта - общее описание структуры и интерактивных элементов);
- к надежности;
- условия эксплуатации;
- к информационной и программной совместимости;
- к поставке;
- к документации.
5) Стадии и этапы разработки (этапы и содержание работ)
6) Порядок контроля и приемки
Структура сайта и шаблоны страниц с той степенью проработки, что у вас в статье, это уже скорее часть эскизных или технического проекта (по госту), или Functional Requirements, а может и Software Requirements (по RUP-у).
У вас получается, что ТЗ - это такой супер-документ про "все сразу". Не понятно, когда его разрабатывать: до подписания договора и подписывать вместе с договором, или уже после подписания договора, но тогда что приложить к договору, чтобы ограничить обе стороны?
Но, с другой стороны, хорошее ТЗ и проработанные требования снижают риски для обеих сторон. Но снижение рисков опять же стоит денег.
В общем, сплошные компромисы )
Если было желание обсудить авторство на облако тэгов, то можно было или просто спросить или погуглить, без упоминания этих ваших местных "разборок".
Рынок всех расставляет по местам: и заказчиков и исполнителей. Или Вы хотите чтобы все по 100 получали?
Или чтобы заказчик всегда Вас выбирал? :)
Много видел разные клавиатуры для систем монтажа и всяких 3D, у которых отдельные группы кнопок раскрашены. Вот там этим клавам и место. И цена в полторы штуки там никого не смутит.
Да и никогда первые на рынке не продавали что-либо задешево. Так что адекватная цена.
А угрожает системе доменных имён ICANN и супер-пупер многоязычные доменные имена.
Так что в любом решении будут плюсы и минусы. Всегда хочется сделать самому "в сто раз лучше", но часто это или переоценка своих сил или пустое расходование ресурсов.
У меня сейчас желания такого нет и нужно готовое решение. Указаный ниже osCommerce VAM Edition похоже единственный вериант, где есть весь функционал и интеграции для русского магазина. А с дизайном думаю разберемся :)