Написание хорошего ТЗ для разработки сайта еще та проблема, и я поделюсь своим опытом по созданию “человеко-понятного” описания для заказчика для разработчика.

Начну из далека, не судите строго…

Шаг ноль. Заказчик.

Манипулирование.

Начнем с первой встречи с заказчиком. Произвести впечатление серьезного человека, с которым можно и нужно работать – вот Ваша основная задача – так что отложите Ваш любимый костюм цвета хаки – джинсы и рубашечка – будет самое оно.
Место встречи тоже очень важно – MacDonalds – не лучший выбор – лично я выбираю кофейни – тихая спокойная обстановка распологает к продуктивной беседе. Кстати – тут Вам и первый звоночек – если заказчик угощает – это хорошо, иначе – работайте по предоплате.
На этой первой встречи Вы должны убедить заказчика в том, что из Вас двоих именно Вы профессионал, и именно Вы знаете чего он хочет. Берите инициативу на себя во время деловых встреч и переговоров. Не стесняйтесь давать подсказки заказчику, приводите примеры, но только такие какие Вам нравятся, и Вам они выгодны (к примеру лежит у Вас в заначке готовый сайтец). Не дело если заказчик сядет Вам на голову – может он где-то и директор, но только не с Вами – для Вас он просто один из многих.

Аналоги.

Добейтесь от заказчика аналогов его детища (я сильно сомневаюсь в уникальности идеи, такие встречаются крайне редко), так вы быстрее поймете суть того чего от вас добиваются. Очень хорошо если у Вас есть ноут с доступом в и-нет, и Вы сможете все сразу посмотреть. (раскошельтесь на PCMCIA GSM модем – это производит впечатление).

Деньги.

Тут нужно быть очень внимательным – Вы должны точно понять и уяснить каким образом проект будет зарабатывать (пусть и в перспективе). Понятно, что на сайты-визитки это не распространяется.

ТЗ.

Во время разговора записывайте важные моменты – не надейтесь на память – обязательно проколитесь. Если у Вас возникают вопросы – задавайте их, ответы опять же стоит записывать. По окончанию беседы перед Вами должен лежать черновик ТЗ.

А теперь наступает самый трудный момент – Вы должны убедить заказчика в том, что именно Вы пишите ТЗ, и он за него должен заплатить. Если таковое не получилось – пришлите ему образец – пусть помучается, в итоге, если он ценит своё время – он таки согласиться на Ваши услуги.

Шаг первый. ТЗ.

Писательство.

Перед началом работы над ТЗ Вы должны твердо уяснить для себя – данный документ должен трактоваться однозначно не только Вами и заказчиком, но и любым другим разработчиком, и это достаточно сложная задача.

Небольшое лирическое отступление в начали пути – имхо, считаю что одно из самых правильных способов подачи информации есть графический, т.е. лучше один раз увидеть, чем сто раз услышать. Так что будем рисовать макеты (mock-up’ы) страниц – для этого подойдет даже MS Word (хотя конечно лучше воспользоваться чем-то вроде Axure RP Pro):

В качестве подопытного возьмем сайт представляющий собой доску объявлений по купле-продаже автомобилей.

Как Вы видите – это главная страница сайта, на ее “рисование” у меня ушло чуть меньше 5-ти минут, теперь можно попробовать описать словами:

Сверху должен располагаться логотип, правее форма для авторизации пользователей, чуть ниже логотипа – ссылки сайта, под ссылками – топ комментируемых новостей, и еще ниже блок рекламы. По центру должна находиться форма поиска, под ней – последние добавленные объявления, затем блок рекламы, и последние новости. Под формой авторизации должен располагаться блок с последними комментариями на форуме, и ниже блок рекламы. В самом низу страницы будут находиться счетчики-пузомерки, а так же копирайты

Ух, описание конечно – много буков, и много вопросов, макетик более однозначный. Ладно поехали дальше, ближе к сути.

Для начала необходимо выделить сущности, роли пользователей и определить уровни доступа (буду краток – приведу таблицу):

Где:

• R – чтение
• W – создание
• E – редактирование
• X – полный доступ (создание/редактирование/удаление)
• M – модерирование (редактирование/удаление)
• * – особенности реализации отображены в документации

Теперь перед нами стоит следующая задача:

• Для всех R – создать макеты страниц
• Для всех W, E – описать полностью формы – т.е. какие поля редактируемы, и по каким правилам
• Для всех X, M – mock up’ы страниц с навигацией + формы создания/редактирования

Начнем с простого – R – для объявлений:

И для новостей:

Далее приведу пример описание формы для комментариев (W):

• Имя – буквы кирилицы и латиницы, цифры, символ подчеркивания и дефис, обязательное
• E-mail – в соответствии со стандартом RFC-2822, обязательное
• Ссылка на Сайт – в соответствии со стандартом RFC-2616
• Текст – непустое поле больше 3-х не пробельных символов
• CAPTCHA – тест Тьюринга для защиты от спама, обязательное

И соответствующий mock up:

Как видите – подобные макеты достаточно информативны, а так же подготавливают заказчика к будущему продукту.

Так же не забудьте приготовить шаблоны писем (вот вам примерчик):

Еще пригодится диаграмма прецедентов (вполне вероятно, Вы могли её нарисовать еще на этапе обсуждения проекта с заказчиком):

Проектирование архитектуры и БД.

Почему я включил сюда этот пункт? Всё очень просто – по своему опыту скажу – когда документация по проекту заходит в отдел и начинается разработка архитектуры и БД, то возникает очень много вопросов, о которых даже мысли не возникало при прочтении доки. В итоге проектная команда простаивает, пока менеджер, краснее перед заказчиком, выясняет эти нюансы. Было бы намного логичнее быть на шаг впереди, и набросать архитектуру и БД уже на этом этапе – это часа 3-4 работы, которая сможет сэкономить и время, и деньги, и нервы (конечно архитектура в таком варианте будет слишком сыра, но уже сможет выявить несколько подводных камней).

Архитектуру я описывать не буду – так как в данном примере особо и проектировать нечего, а low-level нам продиктует фреймворк.

А вот приблизительный набросок БД это всегда пожалуйста (опять же особо не заморачиваясь на подробности):

Шаг второй. Оценка проекта.

О данном этапе советую прочитать статью “Оцениваем проекты” (правда, я скромный?)

Вывод

Я очень надеюсь, что данная статья поможет Вам избежать ошибок на первом этапе жизни проекта, зачастую именно недопонимание разработчиком ТЗ по проекту ведет к увеличению стоимости разработки, затягиванию сроков, а так же к более серьезным последствиям…

Другие посты на эту тему

• No Related Post

Одной из основных моих активностей на работе является оценка проектов. И в данной статье я постараюсь поделиться своим опытом в данной области.

По данной теме написано очень много книг и статей, но зачастую все примеры из них описывают многомиллионные проекты расчитанные на несколько лет, и адаптировать их под нужды небольших проектов до 1000 часов довольно проблематично, для таких проектов необходима “экспертная” оценка – т.е. оценка человека, который знаком с технологиями и разрабатывал или рукводил разработкой подобных проектов. И так предположим, что Вы и есть тот самый человек, кому прийдется оценивать проект.

Дабы не ходить вокруг да около, лучше всего будет привести пример, поэтому возьмем абстрактный проект со следующими мутными требованиями:

“Хочу сайт, где пользователи смогут писать посты с картинками, оставлять комментарии, выставлять рейтинги, обмениваться сообщениями, а так же на сайте будет магазин с книгами, книги будет добавлять администратор сайта, он так же будет следить за порядком на сайте. Сайт должен иметь “лёгкий” дизайн и соответствовать web 2.0″

Начнем по порядку:

1. Пытаемся понять бизнес-идею заказчика, если у Вас это не получилось – необходимо добиться этого понимания, глядя на данное описание можно предположить 2 варианта для получения отдачи с сайта – процент с продажи книг и контекстная реклама (о которой не было сказано ни слова, но очень часто предполагается по умолчанию)
2. Задайте следующие вопросы заказчику:
   • Какие нагрузочные требования к системе, сколько будет зарегистрированных пользователей, сколько онлайн (я сомневаюсь, что заказчик адекватно поймет словосочетание “конкурирующие запросы”)?
   • Нужна ли поддержка мультиязычности?
   • В каких браузерах должен корректно отображаться сайт?
   • Какие требования к безопасности сайта (понятно, что мы не будем писать дырявое приложение, но лучше заранее знать что сайт будет работать по HTTPS и URL будут уникальны для каждого пользователя)
3. Разбейте проект на составляющие – составьте фиче-лист проекта
4. Все вопросы которые возникают – записываем, и не забываем задать их заказчику, каждый вопрос желательно сопровождать пояснениями, дабы не смущать заказчика, а так же не мешало бы подталкивать его к правильному ответу, который бы минимизировал часть рисков (к примеру на вопрос о поддержке различных браузеров, лучше упомянуть, что самые популярные нынче это IE6.0+, FF 2.0+ и Safari 3.0+, иначе есть риск, что придется подгонять дизайн под какие-нить ископаемые, типа Netscape 8.0)
5. Итоговую оценку с подробными комментариями и вопросами отсылаем заказчику в формате XLS – пусть он сам попробует добавить/убрать некоторые пункты

Составление фиче-листа

Данный пункт требует определенных навыков, дабы расшифровать требования и ничего не упустить, и вот некоторые советы по составлению фиче-листа:

1. Каждый пункт должен включать 2 оценки – среднюю, и максимальную (это если сработают все риски, риски лучше сразу описывать)
2. Выделите следующие части в отдельные пункты
   • разработка и внедрение дизайна
   • разработка архитектуры системы
   • разработка БД
   • анализ требований (собственно это чем вы будете заниматься до старта проекта, включая написания документации)
   • если у Вас команда разработчиков, то так же должен быть пункт “Передача знаний” – это время на митинги, и тому подобные рабочие процессы, которые кушают бюджет
   • менеджмент – включает в себя общение с заказчиком и сам менеджмент как таковой
   • тестирование – нам же нужна “живая” система
   • деплоймент системы на сервер заказчика
3. Выделите отдельным пунктом “бесплатный сыр” – то что Вы бы сделали, даже если бы не было такого требования, к примеру – интеграция WYSIWYG редактора или поддержка User Friendly URL, интеграция Google Analytics и Google AdSense

А теперь попытаемся выделить основные пункты из нашего “описания”:

1. Обычное явление для сайта – присутствие страниц со статической информацией, которая может изменятся администратором, по личному опыту – для 90% сайтов необходимо было реализовывать данный функционал
2. У нас на сайте присутствует как минимум 3 роли : гость, зарегистрированный пользователь, администратор, а может еще будет модератор?
3. У нас есть как минимум 5 сущностей кроме пользователей: книги, посты, комментарии и рейтинги, а так же сообщения для приватных бесед, если чуть-чуть подумать, то появляются еще категории для книг и тэги для постов (дабы следовать web 2.0), необходимо все предположения уточнить у заказчика.
4. Дизайн аля web 2.0 может оказаться и с flash’ом или заказчик видел где-то, что-то и он хочет подобное, так что продолжаем формировать список вопросов
5. Если у нас электронный магазин, предполагается ли интеграция payment gateway’ев, если да, то каких.
6. Обмен сообщениями между пользователями – тоже довольно скользкий момент, возможно заказчик имеет ввиду чат, или всё же простенькую систему внутренних сообщений? Пользователи могут отсылать сообщения любому другому пользователю, или будет список друзей?

Промежуточный фиче-лист включает в себя следующие пункты:

• Entities:
  • Static Pages
  • Users
  • Users Friends
  • Blog Posts
  • Blog Posts Tags
  • Blog Rates
  • Blog Comments
  • Books
  • Books Categories
  • Messages
• Free Section
  • User Friendly URL
  • WYSIWYG Editor
  • Google Analytics
  • Google AdSense
• Design
• Architecture
• Database Architecture
• Knowledge transfer
• Management
• Testing
• Deployment

Далее лучше всего разбить данный список по ролям (гость, пользователь, администратор), а для таких пунктов как менеджмент, тестирования, анализ требований и передача знаний оценка будет указана в процентах от общего времени разработки, на данный момент это 10% для менеджмента, 30% для базового тестирования и по 5% на анализ и передачу знаний (такие значения выведены личным опытом и здравым смыслом).

В итоге у меня получился фиче-лист с очень приблизительной оценкой, впрочем описание тоже не радует деталями. В действительности после выяснений всех деталей, может оказаться, что заказчик хотел всего лишь что-то наподобие WordPress MU, а магазин представлял бы всего-лишь – ссылки на Amazon с указанием реферала, хотя, с таким же успехом, заказчик может хотеть и социальную сеть, со всеми соответствующими атрибутами…

Если Вам интересна данная тема, могу посоветовать прочитать еще статейку о клоне YouTube.

Другие посты на эту тему

• No Related Post

Теперь я “сертифицированный специалист по оценке проектов” :)

Я знаю “Rough order of magnitude”, “Large Scale Analogy”, “WideBand Delphi”, “Wild Altogether Guess”, “SLIM” и много других страшных слов, но гвоздь программы – это COCOMO II (COnstructive COst Model) – с этим зверем мне любая оценка по зубам.

В теории конечно, на практике пока COCOMO еще не использовал, всё как-то больше применяю экспертную оценку, а времени на параллельную оценку, к сожалению, нету…

Другие посты на эту тему

• No Related Post

С возросшей популярностью сервиса YouTube.com многим захотелось организовать подобный сервис, но как это сделать? Приведу небольшой рецепт организации такого сервиса.

Функциональность

Для начала опишем основной функционал сайта (сразу определимся и с ролями пользователей):

1. Гость
   • просмотр видеофайлов на сайте
2. Пользователь
   • аплоад видеофайлов
3. Администратор
   • управление пользователями
   • управление файлами

WEB 2.0 фичи

А теперь расширем наш базовый функционал, чтобы привлечь аудиторию:

1. Гость
   • просмотр комментариев к видеофайлам
   • поиск файлов (по категории, по тегам)
2. Пользователь
   • возможность оставлять комментарии к видеофайлам
   • возможность записывать видеофайлы с web-камеры
   • возможность связывать видеоролик с категорией
   • возможность связывать видеоролик с несоклькими тегами (tags)
   • выставление рейтинга видеофайла
   • организация списка друзей
   • внутренняя mail система
   • закладки
3. Администратор
   • управление комментариями
   • управление категориями

Это конечно не весь функционал YouTube, но ведь нужно с чего-то начинать

Конфигурация сервера

Наша система будет базироваться на LAMP:

• Linux
• Apache (версия 2.2 и выше)
• MySQL (версия 5.0 и выше)
• PHP (версия 5.2 и выше)

Возможные проблемы

А теперь расскажем о проблемах с которыми Вам предстоит столкнуться

Конвертирование Видео

Если позволить каждому из посетителей сайта заливать на сервер видеоролики в произвольном формате, то для того, чтобы просмотреть их все, Вам прийдется устанавливать на свой компьютер очень много кодеков, а если требовать определенный формат от пользователя – то, с очень большой вероятностью, это отпугнет от вашего сайта поситителей. И что же делать? Правильно, конвертировать все видеофайлы в один формат, и будем конфертировать в формат FLV (flash video – можно просматривать в большинстве операционных систем, поскольку он использует широко распространённый Adobe Flash Player и плагины к большинству браузеров, а также поддерживается многими программами для воспроизведения видео, например, MPlayer, VLC media player и другими программами, работающими с помощью DirectShow).

Нам понадобятся следующие програмные средства (всё opensource):

1. mencoder или FFmpeg
2. flvtool2 (требует наличия Ruby)
3. PHP Program Package (‘example.php’ пример конвертации с использованием mencoder’a) или ffmpeg class (‘ffmpeg.example1.php’ пример конвертации с использованием ffmpeg)

Дополнительно можно еще использовать mplayer для получения информации о оригинальном видеоролике.

Замечательно, если мы всё установили и правильно собрали, то мы теперь можем конвертировать…

Статус загрузки

Еще такой момент – пользователям не нравиться сидеть и ждать пока файл загрузится на сервер, пользователь он же любознательный, ему хотя бы вывести progress bar надо:

• http://www.emllabs.com/article.php?articleId=121/ (используя Flash8 и PHP)
• http://tomas.epineer.se/tesupload/
• http://www.raditha.com/megaupload/
• http://www.obokaman.com/p/descripcion-y-fuentes-del-upload-php-ajax-con-barra-de-progreso-1596
• http://labs.beffa.org/w2box/demo/
• http://trydobe.com/?page_id=3
• http://ecosmear.com/relay/ (прикольный примерчик, используется perl)

Все ссылки нарыл на форуме xajax’a http://community.xajaxproject.org/viewtopic.php?pid=10100

Ресурсы

Так, на сервер мы залили видеофайл, показали как он быстро к нам заливался, но вот беда, если мы будем на нашем web-сервере конвертировать видео ролики – то сайт у нас будет скорее мёртв, чем жив. Для этой цели нам надо будет использовать еще один (как минимум) сервер, который будет забирать неотконвертированный файлы с web-сервера и отправлять назад отконвертированные ролики. Т.е. для решение данной проблемы нам понадобиться еще железо…

Распределение нагрузки

Конвертирование это ресурсоемко, а отдавать видеоролики всем желающим?… Это конечно не будет так нагружать процессор, но вот канал точно умрет… как выход у нас появляются еще сервера, которые и хранят у себя видеофайлы:

• http://mirror1.myphptube.com
• http://mirror2.myphptube.com
• и т.д.

Как распределять нагрузку – это уже решать Вам. Но прежде, чем городить огород Вы должны определить какой приблизительно объем данных Вам прийдеться хранить, и далее уже решать какая схема больше подойдет, ориентируемся, что 1 пользователь заливает на сервер 20mb в месяц (234Gb на 1000 пользователей в год), не популярные ролики не сохраняются более года):

• Объём данных ~ 0.3Tb – 1.5Tb:
  на каждом зеркале у нас хранятся все видеоролики
  у нас есть mirror1 – сервер на котором всегда первым появляется переконвертированный видеоролик, остальные с ним синхронизируются
• Объём данных ~ 1.5Tb – 3 Tb:
  все видеоролики храняться только на одном главном сервере, если у видеоролика растет популярность, он заливается и на другие зеркала
• Объём данных > 3Tb:
  видеролик заливается на ближайшее зеркало (подразумеваем, что ролик залитый китайцем будут смотреть в основном китайцы, следовательно заливаем его на зеркало в Китае)
  по мере роста популярности ролика зеркалим его на сервер ближайший к эпицетру популярности (пример: китаец живет в США, его ролик залит на зеркало расположенное в США, смотрят его в основном в Китае, видя это ролик будет отзеркален на Китайский сервер)

Числа взяты с потолка, против китайцев ничего не имею (просто взяты для примера), пишите свои варианты…

База данных

Далее я опишу простенькую архитектуру БД:

Небольшое примечание:

• для полей ввида date_create и date_update используем функцию gmdate(’Y-m-d H:i:s’) – время по Гринвичу, это облегчит в дальнейшем жизнь при отображении времени на сайте.

Команда

Какую лучше всего собрать команду для разработки такого проекта? Я предлагаю следующий вариант:

• 2 PHP-разработчика
• Flash разработчик / дизайнер
• 1 администратор
• 1 тестировщик
• 1 менеджер

Оценка

Да уж, не мало – 421 часа, т.е. примерно 2,5 месяца разработки… и это еще очень оптимистическая оценка, с учётом, что разработчики используют свои наработки или какую-либо CMF систему аналогичную Zend Framework или phpXCore, а так же организовываем простейшее хранилище файлов. Если же разработка будет вестись с нуля – то можно смело умножать данную оценку на 2.


Итого, такой проект будет стоить не менее $10 000…

P.S.

Основная проблема не в реализации системы, а в привличениии аудитории, кто будет пользоваться вашим сервисом если есть YouTube (и даже PornoTube)? Чем завлечь? Если есть идеи – пишите каменты…

На момент написания статьи домен MyPHPTube.com не был зарегистрирован, если вы его таки зарегистрировали, вышлете пива на мой домашний адрес… ;)

Есть несколько причин побудивших написать данную статью:

1. хотелось написать умную статью для своего блога (или претендующую на “умную”)
2. хотелось показать, что Package Program таки может пригодиться
3. продемонстрировать, что OpenSource и LAMP тоже рулит ;)

Другие посты на эту тему

• Обновление сервиса Charts.HoHli.com
• JavaScript: программируем жесты мышкой
• PHP CookBook: MyPHPTube.com (YouTube clone)

With the increased popularity of the YouTube.com service many people wanted to organize a similar service, but don’t know how to do this. If you are one of them – this article is for you

Features

First of all describe the basic site’s functions (and also determine and the role of users) :

1. Guest
   • View video online
2. Member
   • Upload videos
3. Administrator
   • Manage users
   • Manage files

WEB 2.0 Features

We need to extend base functions, because we need to get more traffic:

1. Guest
   • view comments on video
   • search for files (using categories or tags)
2. Member
   • comment on videos
   • record video from Web (using webcam)
   • assign category to video
   • assign tag to video
   • rate video
   • organize list of friends
   • manage favorites
   • send in-mails
3. Administrator
   • Manage comments
   • Manage categories

These are certainly not all the features of YouTube, but at least something to start with

Server Configuration

Our system will be based on LAMP:

• Linux
• Apache (version 2.2 and higher)
• MySQL (version 5.0 and higher)
• PHP (version 5.2 and higher)

Troubleshooting

And now describe the problems that you may encounter

Video Conversion

To gain user attention we need to allow them uploading videos in any format, but it’s more comfortable to users to get videos in one specific format (this will allow not to have a codecs-zoo on your machine and on the other hand if site requires some extra actions from user – it is very likely that user will forget your site – you know we are lazy. And what can be done with this? The answer is obvious – convert video files into a single format, and the format should be FLV. Flash-video can be viewed on most operating systems because it uses the widespread Adobe Flash Player software preinstalled on most browsers, and this format is also supported by many programs for video playback, such as MS MPlayer and almost all other players.

We need the following software tools (all opensource):

1. mencoder or FFmpeg
2. flvtool2 (need Ruby)
3. PHP Program Package (‘example.php’ contains example using mencoder) or ffmpeg class (‘ffmpeg.example1.php’ uses ffmpeg)

You can use mplayer to get additional information about original video file.

If we properly assembled and installed, we can now convert…

Upload

People did not like to sit and wait while the file is silently downloaded to a server, the users are curious, so we would have to show progress bar:

• http://www.emllabs.com/article.php?articleId=121/ (use Flash8 and PHP)
• http://tomas.epineer.se/tesupload/
• http://www.raditha.com/megaupload/
• http://www.obokaman.com/p/descripcion-y-fuentes-del-upload-php-ajax-con-barra-de-progreso-1596
• http://labs.beffa.org/w2box/demo/
• http://trydobe.com/?page_id=3
• http://ecosmear.com/relay/ (nice example, using perl)

All references are from xajax forum http://community.xajaxproject.org/viewtopic.php?pid=10100

Resources

ТIf we will use the same server for webste and video conversion then website will be more dead than alive. For this purpose we will have to use another (one at least) server that will take original files from the web and put it back converted in a while. In other words we need more than 1 server to create a working solution.

Load distribution

If we store all data in one server, it will not carry the load. We must have several servers to store data :

• http://mirror1.myphptube.com
• http://mirror2.myphptube.com
• etc

You must decide themselves how to distribute the load. You have to estimate the amount of data to be stored and then choose appropriate scheme, (let’s assume that one user uploads to a server 20mb per month (234Gb for 1000 users per year), and not popular files are not stored more than a year):

• Stored data ~ 0.3Tb – 1.5Tb:we keep all the videos on each mirror. We have main mirror – server on which converted video always appears first and all other mirrors sync with it
• Stored data ~ 1.5Tb – 3 Tb:
  All videos are stored in one central server, if the video is growing in popularity, it is poured into other mirrors
• Stored data > 3Tb:
  Video is uploaded to the nearest mirror (example : assume that the video uploaded from China will be mostly popular in China, thus place it to the mirror in China) With the growing popularity of this video we will copy it to the server closest to the epicentre of popularity (example : Chinese living in the United States, the video file upload to a mirror located in the United States, watched videos in China, in this situation video file will be copied to the Chinese server)

This is not statistical numbers, they are for illustrative purposes. China cited as an example (nothing personal). Write an opinion in the comments…

DataBase

Next, I will describe simple architecture DB:

A small note:

• For the columns date_create and date_update using a gmdate (’Y-m-d H:i:s’) – GMT, it will make the life easier in the future when displaying the time on the site

Team

How to gather a team to develop such a project best? I propose the following:

• 2 PHP-Developer
• Flash Developer / Designer
• 1 UNIX-administrator
• 1 Tester
• 1 Manager

Estimation

So we have 421 hours, or approximately 2.5 months of development. Did you expect such a number? I thought it will be more :)


That’s very optimistic estimation that includes several assumptions:

• the developers will use CMF system similar to phpXCore or Zend Framework
• the developers are familiar with the CMF choosen (i.e. won’t learn in while coding)
• the simplest file storage will be used (all mirrors store all files)

If development will be done from scratch you can easily multiply this assessment by 2.

Total, the project will cost at least $ 10,000…

P.S.

The main problem is not in the system, main problem is drawing audience. Who will use your service if there is YouTube (and even PornoTube)? If you have ideas, write in comments…

At the time of writing this article MyPHPTube.com domain was not registered. If you register it, send a beer at my home address… ;)

Другие посты на эту тему

• Обновление сервиса Charts.HoHli.com
• JavaScript: программируем жесты мышкой
• PHP CookBook: MyPHPTube.com (клонируем YouTube)