Deni, именно так. MSF (в отличие от RUP - туда не ходите :)!) это грубо говоря идеология создания любого проекта в IT отрасли. Неважно - вебсайт, софт, прокладка кабеля по зданию для создания сети или поставка оборудования в медицинский центр. По сути нужен не весь MSF, а именно та часть, где описывается самое сложное - взаимодействие команды исполнителя с заказчиком. Тогда вы получите представление об идеальной (с точки зрения майкрософта) модели работы по проекту между заказчиком и исполнителем. Да, там есть и правила для заказчика (утрирую для простоты), без которых сделать проект не удастся.
Понятно, что если вы заказчик, то интересовать вас должна в первую очередь роль Product manager, то есть представителя заказчика в команде и представителя команды в глазах заказчика. Если вы "просечете фишку", то есть поймете чего предлагает Майкрософт идеологически, то и проблем с выбором подрядчика и дальнейшей организацией производственного процесса будет у вас значительно меньше.
Да, конечно, как тут уже сказали, в жизни все будет не так красиво. Но важно не это, а то, что некая идеология даст возможность разложить ваши знания по полочкам и систематизировать их. Также MSF дает некоторые ответы на вопросы, которые вы задавали.
Но есть и другие методы и подходы, более специализированные и конкретные, тот же RUP, RAD и т.д. Но в них мало чего говорится (ИМХО) именно о работе с заказчиком, скорее это процессы внутри компании исполнителя.
Была такая книжка, я читал когда готовился к сдаче экзамена по информационному проектированию (70-100 кажется), так там полкниги было в художественной форме рассказано как делался некий вымышленный проект. И взаимодействие с заказчиком, и сложные случаи разные раскрывались. Познавательно, особенно если ты уже знаешь все это изнутри.
ИМХО, все что на западе придумывается - интенсивно проходит обкатку бизнесом и жизнью. Поэтому чего выжило - то стоящее. У нас с этим беда, к сожалению. Все время изобретаем велосипед.
Да, так бывает. Только есть одно "но" - оценивающая компания (консалтинговая и проч) не только не заинтересована в результате оценки, но и не несет ответственности. Поэтому чисто по бизнесу ИМХО единственно правильный вариант - заказчик должен иметь в штате специалиста, который а) разбирается в бизнесе, б) понимает и разделяет взгляды на решение поставленной задачи и в) может по-русски объяснить исполнителю или, если речь об оценке то эксперту, что должно быть в результате.
В противном случае приходишь ты в управляющую компанию, а тебе и говорят: "Не шмогла я, не шмогла".
Я не спорю, скорее наоборот я согласился с вашим постом с небольшой оговоркой.
Касательно полезности и прочего - да, вероятно иногда это полезно, иногда это не нужно. Это не принципиальный вопрос.
Я не думаю что речь идет сугубо о порталах (типа mail.ru), поскольку таких проектов все равно достаточно мало и там все далеко не в ТЭО будет упираться. Скорее как раз речь идет о массовой разработке типовых проектов сложного внутреннего устройства, то есть не корпоративных сайтах само собой. Ну, ТС поправит нас если что.
Вы неправы. Просто в крупных компаниях есть целые отделы аналитиков и проектировщиков. В Актисе, например, его размер в былые времена составлял до 15 человек. Выделенных аналитиков. Только на веб-проекты общего назначения. А в мелких проектировщик может быть неявным - проджектом, ведущим разработчиком, или вообще эта роль может быть размазана на несколько человек.
Вообще, мне кажется вам стоит посмотреть MSF (Microsoft Solution Framework), конкретно часть связанную с ролями в команде. Их там 6: продакт, проджект, разработчик, тестер, user education и логистик. В MSF 4 их уже 7, добавился архитектор и переименовали education, но это уже детали. Скачать все это можно на майкрософте, также можно почитать что-то из журналистских статей типа http://blog.brodzinski.com/2006/08/msf-basics-team-roles.html.
Мне кажется, что раз вам интересно как все это должно работать, то это будет полезным, хотя впрямую к заданному вопросу про ТЭО это не относится.
ТЭО не пишет студия, ТЭО не пишут аналитики. ТЭО вообще для веб-проектов не пишут. Потому как если проект простой, то экономическое обоснование (сколько и чего на нем заработается) должно быть в голове у бизнесмена-заказчика. Если он не понимает как на этом зарабатывать - проект мертв. А если проект сложный - у него же будет бизнесплан. Это то же самое чего у него в голове, только на бумаге. И сделано для тех, у кого деньги на проект клянчатся - инвесторы и прочие. Все остальное - это пурга. Ни на одном из крупных и успешных веб-проектов с которыми я сталкивался ТЭО не было чем то иным кроме как формальной отпиской.
И вообще, ТЭО - обоснование затрат на то или на се с технической позиции. Для веб-проектов в 99% случаев уже есть прайс, составленный из затрат самим рынком. Все более менее себе представляют во что выльется проект с такой-то постановкой. И заказчики, и исполнители.
Элементарно, Ватсон. Гонишь пользователя на страницу А, оттуда жестко его редиректишь яваскриптом на страницу Б. И все. На странице Б он застрял навсегда (в смысле движения назад).
Также можно прятать панель с кнопками в окне при его открытии, и так далее.
Но все это совершенно неправильно, потому что у пользователя должна быть возможность пойти назад. Всегда. Иначе вы чего-то перестарались с идеей.
Unrecogn1seD, а 10$ это не бесплатно что ли?
Мужики, кончайте писать всякий бред типа "Я вот вчера собрался написать скрипт, уже почти написал. Что он будет уметь в конце разработки я пока не решил. Показать пока нечего, потому что пока ничего не готово. Продавать буду за сущие копейки. Обещаю саппорт пока мне это не надоест но без всяких гарантий потому что пишу для себя". Тошнит уже от подобных постов.
Сначала напиши софтину, покажи людям, протестируй, организуй саппорт, потом продавай сколько влезет. Чужие "мысли вслух" никто покупать не будет, неужели это так сложно понять?
Вообще-то логичнее бэкграунд делать не у инпута, а у клетки таблицы. Тогда вам не придется дергаться как там браузер поле ввода спозиционирует внутри клетки.
Пишите <center> и не заморачивайтесь. Этот тэг для этой цели и придуман. А то, что можно выполнить центровку сотней разных способов - вас волновать не должно.
Вы должны понимать логику работы всей цепочки. Тогда вопрос отвалится сам собой. Во-первых, кодировку контента может выдавать веб-сервер. Он делает это с помощью своих заголовков безотносительно вашей страницы. Если он укажет, что контент сделан в кодировке windows-1251, то браузер будет об этом знать. Далее, если вы укажете в странице кодировку документа с помощью тэга, который вы написали, браузер тоже примет это во внимание. Если не указано ни то, ни другое, браузер (в зависимости от браузера) будет пытаться определить кодировку сам по своим внутренним алгоритмам. И наконец, в браузере может быть принудительно установлена кодировка, в которой выводить контент на экран. Приоритеты такие:
1. кодировка в браузере принудительная
2. кодировка страницы, указанная в HTML коде
3. кодировка серверного ответа
4. автоопределение если не задано ничего, указанные кодировки конфликтуют или контент на страницы смешанный (например один фрейм в Windows-1251, а другой в KOI-8R).
Теперь понятнее? Естественно, поведение разных браузеров может отличаться. Поэтому обычно вебмастеру, который не может повлиять на серверные заголовки, других способов указать браузеру как рисовать текст других способов кроме как META не остается. Поэтому пишите, Шура, пишите.
Да, и по поводу Ноутпада - Kpd прав по своему, но ноутпад совершенно нормальный редактор и многие профи пользуются им и другими простейшими редакторами типа FAR, vi и проч. Умея виртуозно играть на скрипке уже все равно 3 там струны или 2. Ведь HTML редактор это просто редактор текста + иногда подсветка кода, и все. А подсветка в голове любого опытного верстальщика есть даже на монохромном мониторе.
Раз вы не понимаете сути вопроса - повторяю позицию вебмастера, которая должна иметь место быть:
Где гарантии, что статистика посещений, которая будет предоставлена вам не уйдет налево? Желательно в виде договора со штрафными санкциями со стороны Бегуна в случае такого происшествия.
Сначала ответьте на конкретный вопрос, а потом рассуждайте о том что другим людям тяжело, а что нет.