Привет! Нужно реализовать сложный Web-проект. Подскажите в каком виде лучше предоставить общую суть проекта, алгоритмы, логику работы конечному испольнителю? У кого какой опыт был...
http://ru.wikipedia.org/wiki/Экстремальное_программирование "Игра в планирование" ("Planning game"). Карточки с пожеланиями
По моему опыту (как исполнителя), наиболее доходчивым методом будет вербальный. Который, конечно, не помешает подкрепить какими-либо бумажками, но именно устное изложение того чего надо, я считаю основным.
В XP нет строго классического ТЗ и это правильно 1. ТЗ полюбому не может польностью описать задачу 2. Все меняется
Да. да. да.... Все такие прогресивные советую писать в UML, заодно прочитать книжку про XP.... А в итоге, что? Придет к тому, что объясните мне, покажите мне..... Я хочу сделать так, что бы масса вопросов отпала.... реальный опыт у кого есть?
Реальный опыт создания сложных проектов есть. А опыта занятия бюрократией особого нет. В первую очередь нужно самому понять, что нужно. А потом уже UML и т.д. и т.п.
хм... ТЗ значит... и в чём проблема?! начинаем со слов "я хочу" и по порядку перечисляем всё, что приходит в голову касательно проекта .... вот и всё... ТЗ пишится в свободной форме и никаких общепринятых стандартов тут нет.
Вы немного не поняли.... Это не класическое "я хочу..." и водой... Там будет много алгоритмов и логики, все это надо как-то доступно донести до исполнителя. В виде блок схем? Я не решил... Т.е. все жестко описано, что и как.... Отсается вопрос о инструментах или средах в которых это будет сделано для макисмально быстрой реализации программистами....
MS Word Adobe Photoshop можно в Paint нарисовать... Программисту должно быть абсолютно всё равно! Можно даже от руки написать и нарисовать... Я бы и на формате А2 принял, главное, чтобы читабельно было )))
1. Вообще ТЗ пишется для заказчика, что бы ему было по чему тестировать сайт. 2. В техническом задании указывается дизайн всех страниц которые вы хотите видеть на сайте (или предоставляется готовый шаблон). 3. В ТЗ должныбыть: структурная схема сайта, блок схема сайта логическая схема сайта.
Если вы заказчик, то НА СЛОВАХ расскажите о проекте исполнителю, а он пусть записывает или запоминает, это его проблемы. Где-то через недельку он принесет вам ТЗ на согласование, вы естественно скажете, что все это фигня, еще раз объясните, что должно быть реализовано и ... две-три такие итерации и ТЗ готово. А вот если вы руководитель проекта... 1. Узнаете у заказчика, что ему нужно (см. "Если вы заказчик...") 2. Собираешь рабочую группу (всех, всех, всех) 3. Рассказываешь суть дела 4. Мозговой штурм (определяетесь с дизайном, как и на чем будет реализовано, готовите наброски, шаблоны... все что угодно, даже обсудите где будете отмечать успешное завершение проекта), на это действие понадобится МАКСИМУМ один день, минимум час 5. Берешь ГОСТ по разработке ТЗ для информацинонных систем (номер ГОСТа найдешь если будет нужен), и готовишь ТЗ используя данные полученные в пункте 4. 6. Несешь ТЗ заказчику 7. см. "Если вы заказчик..." Вот видишь, конечный исполнитель поучаствовал в разработке ТЗ и объяснять ему ничего не нужно, пока не нужно. Вы не один раз еще будете обсуждать проект с исполнителями, особенно когда начнут меняться требования.
Могу посоветовать после техзаданием разработать техническую и функциональную спецификацию с подробным описанием всехмодулей, всех страниц и т.д. Лучше описывать это не одним документом, а структурой маленьких документов. Описание каждого модуля, каждой функциональности, каждой странички - в отдельный файл. Для полной уверенности в контроле можно еще и опсиание прецедентов настряпать. Все это дело сразу же помещается в любимую CVS или SVN, чтобы с документацие могли работать несколько человек, чтобы можно было восстановить предыдущие версии, и самое главное, чтобы все всегда были в курсе вносимых изменений, поскольку изменения будут, и будет их много. Когда процесс налажен - остается только следить за тем, чтобы документация была актуальной. Если в спешке доки начнут терять актуальность, то вся польза от них пропадет, и они будут только обременять. Здесь, в общем, уместна старая известная поговорка: поспешишь - людей насмешишь.
1. Топик не имеет отношения к форуму "Программирование на пхп" поэтому переносится. 2. По ГОСТу я когда то искал, нашел 198*- какого-то года. Причем содержание можно было сравнить с планом по работе с картофелем. 3. Нет четких правил написания ТЗ, но желательно чтобы там было: Перечень всех функциональных блоков, перечень всех ключевых страниц(схемы), логика функциональных блоков, для дизайнера цветовая гамма, ссылки на понравившиеся ресурсы, дизайн плавающий/фиксированный. 4. Примерная оценка времени в часах на выполнение каждого пункта. 5. UML - это лишнее. ПХП это язык программирования на котором пишут быстро, использование UML убивает это свойство, а если придется переделовать то убивает в квадрате. Читай про XP и все вопросы отпадут. Маленький или большой ресурс - не важно. Важно чтобы ты и заказчик одинакого хорошо понимали что нужно получить в результате и за какой срок.
А чтобы не приходилось переделовать, для этого есть соответствующие методологии разработки ПО UML - это не средство на все случаи жизни. UML даст результат, если использовать его с подходящей методологией разработки. А если строго придерживаться выбранной методики и не халтурить, то переделывать не прийдется. Потому что такие способы разработки предполагают тщательное планирование. А тщательное планирование подразумевает, что прежде чем что-то делать, все тщательно продумывается. Если ты почти доделал проект, и вдруг понял ,что нужно все переделывать, то никаким тщательным планированием здесь и не пахнет ) Другое дело, что в различных ситуациях подходят различные методики. В каком-то случае лучше экс-пи, а в каком-то - руп. Методики на все случаи жизни не бывает, какими бы унифицированными они не были бы.
Думаю на С++ или Java писал бы намного медленнее . И много порталов ты описал на UML??? Раз уж всплыло слово методологии, читаем господина Фаулера http://www.maxkir.com/sd/designDead_RUS.html С уважением, vb.
Сравнивал. Скорость набора кода примерно одинаковая )) Не много. Не надо. Если я все прочитаю, то стану таким умным, что зазнаюсь. Мне гораздо интересснее было бы сейчас услышать твою мысль. Господина Фаулера я всегда могу почитать. А твоей книги у меня на полке пока нет.
Надеюсь немного это больше 0 [/quote] Моя мысль была выше. Конкретезируй что еще хочешь услышать, если так интересно. УМЛ - это зло. Так нормально? А моей книги ты наверное никогда не увидишь - слишком ленивый и глупый я для книги . С уважением, vb
Зря надеешься. Не больше. Как раз приблизительно столько. Да, нормально. Четко, ясно, лаконично. Мысль понял, спасибо. Посему и предположил, что обмен мнениями будет продуктивнее, чем ожидание книг в исполнении друг друга
Наиболее оптимально: продумать тему, написать ее для себя и попрактиковаться на домашних. а затем на пальцах объяснить заказчику