-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Lamer_Scorp
Guest
_RVK_
очень остроумно, ты бы ещё написал ссылку: g UML
2NetFly
Спасибо.
очень остроумно, ты бы ещё написал ссылку: g UML
2NetFly
Спасибо.
Domovoj
Guest
Это только для внутреннего пользования? Или и в ТЗ тоже уходит на ознакомление клиентам?
Я только попытался это начать изучать и столкнулся с тем, что в разных источниках (несколько книг вскользь проглядел) информация противоречит друг другу. Например (я так понял что это стандартный пример), диаграма use cases для "банкомата". Каких только версий нет. И все - разные. Причём в условии везде одно и тоже пишут. Я думал что это вроде как стандарт и он един для всех. А похоже, что каждый просто под себя его подстраивает/переписывает... Можешь подсказать какие-нибудь стоящие книги по этой теме, а то у меня подозрение что много болтунов на эту тему сейчас пишет?
Royal Flash
-=MaestrO=-
Про ТЗ - все очень просто. Звониш на несколько контор, которые занимаются разработкой того, что тебе нужно. Говориш: "Хочу у вас это заказать", просиш ТЗ и оставляеш e-mail. Конечно, еще и пообщатся нужно с конторой, чтобы не подумали, что тебе от них только ТЗ и нужно 
А потом сли будут доставать, когда закажеш проэкт - скажеш, что тебя ихние услуги больше не интересуют - заказал в другом месте. Чем дороже услуги конторы - тем лучше ТЗ.
А по поводу гостов... ТЗ с гостами необходимо только для крупных, ну или очень нудных клиентов. Большинство устроит и просто ТЗ, примеры структуры которых были в начале топика. Главное постораться описать в ТЗ как можно больше ньюансов, чтобы потом небыло глупых вопросов от клиента, наподобии: "А почему у меня на сайте нет картинки с голой женщиной"
А потом сли будут доставать, когда закажеш проэкт - скажеш, что тебя ихние услуги больше не интересуют - заказал в другом месте. Чем дороже услуги конторы - тем лучше ТЗ.А по поводу гостов... ТЗ с гостами необходимо только для крупных, ну или очень нудных клиентов. Большинство устроит и просто ТЗ, примеры структуры которых были в начале топика. Главное постораться описать в ТЗ как можно больше ньюансов, чтобы потом небыло глупых вопросов от клиента, наподобии: "А почему у меня на сайте нет картинки с голой женщиной"
robocomp
Новичок
Где скачать UML?
Это инетерсный вопрос.
например, описание языка есть тут
uml.org
Средство, которое позволяет рисовать диаграммы и при этом жжот
sybase PowerDesigner (стоит дорого, пхп-классы по диаграммам строить не умеет)
Вот эта программа, конечно, немного по-тормозней и мне как-то не такой красивой показалась, как повердизайнер, но
http://sourceforge.net/projects/argouml/
тоже пойдет
Кстати, вот тут есть скан книжки по УМЛ. Книжка хорошая
http://alice.stup.ac.ru/~dvn/uproc/books/uml_user_guide/index.htm
О реальном использовании UML в проектировании Веб-Приложений.
Могу сказать вот чего. В одной знакомой мне веб-студии пишут аналитики какие-то документы в формате ворд, где свалено в кучу все. И сценарии использования системы, и интерфейсы и все. В общем, "ТЗ на разработку сайта" в самом что ни на есть лучшем его виде.
Мне как-то пару при разработке систем удалось их предварительно, хотя бы на первую итерацию (2 мес) спроектировать в UML
Что делал?
1. Составлял варианты использования в виде документов ворд
2. Строил диаграммы вариантов использования
3. Строил диаграммы классов
4. диаграммы последовательностей. По двум последним диаграммам получал примерный набор методов и атрибутов выявленных классов
переносил все в argouml в виде xmi-файла
и генерил описания классов
Затем брал и колбасил коды ужо.
СОбственно, вот. Моуг сказать, что это успешно. ПОтому что можно с заказчиком сесть и чётко проиграть все вараинты использования.
С коллегами-разработчиками, которые живут в другом городе, как было у меня, можно обменяться идеями в стандартном графическом виде
В общем, времени требует не много, пользы приносит достаточно.
Это инетерсный вопрос.
например, описание языка есть тут
uml.org
Средство, которое позволяет рисовать диаграммы и при этом жжот
sybase PowerDesigner (стоит дорого, пхп-классы по диаграммам строить не умеет)
Вот эта программа, конечно, немного по-тормозней и мне как-то не такой красивой показалась, как повердизайнер, но
http://sourceforge.net/projects/argouml/
тоже пойдет
Кстати, вот тут есть скан книжки по УМЛ. Книжка хорошая
http://alice.stup.ac.ru/~dvn/uproc/books/uml_user_guide/index.htm
О реальном использовании UML в проектировании Веб-Приложений.
Могу сказать вот чего. В одной знакомой мне веб-студии пишут аналитики какие-то документы в формате ворд, где свалено в кучу все. И сценарии использования системы, и интерфейсы и все. В общем, "ТЗ на разработку сайта" в самом что ни на есть лучшем его виде.
Мне как-то пару при разработке систем удалось их предварительно, хотя бы на первую итерацию (2 мес) спроектировать в UML
Что делал?
1. Составлял варианты использования в виде документов ворд
2. Строил диаграммы вариантов использования
3. Строил диаграммы классов
4. диаграммы последовательностей. По двум последним диаграммам получал примерный набор методов и атрибутов выявленных классов
переносил все в argouml в виде xmi-файла
и генерил описания классов
Затем брал и колбасил коды ужо.
СОбственно, вот. Моуг сказать, что это успешно. ПОтому что можно с заказчиком сесть и чётко проиграть все вараинты использования.
С коллегами-разработчиками, которые живут в другом городе, как было у меня, можно обменяться идеями в стандартном графическом виде
В общем, времени требует не много, пользы приносит достаточно.
Alexandre
PHPПенсионер
Unified Modeling Language
если перевести то Универсальный язык моделирования.
Логику работы и взаимодействия модулей (скриптов или страниц) можно вполне описать в разрезе диаграм УМЛ, ГОСТ против этого ничего не имеет
-~{}~ 17.06.05 15:20:
Groove, лично я работал с ТЗ и за 500 уе (умолчу о стоимости ПО)
все зависит от функциональности
Sparrow
Новичок
IMHO тз по ГОСТУ (насколько я это помню по институту) для _большинства_ веб-проектов - стрельба из пушки по воробьям. Ни один заказчик (как правило, не имеющий инженерного или технического образования) не будет вчитываться в многостраничные талмуды, где описываются цели, задачи и экономическое обоснование, а также алгоритмы.
По моему опыту в ТЗ (точнее, в задании на разработку) для корп. сайта должна быть максимально полно описана гл. страница (возможно с прототипом макета в виде диаграммы), пожелания к дизайну (шрифты, цвета, и.т.п.), а также все динамические блоки с довольно подробным описанием (например: выводить 10 последних заголовоков новостей раздела "новости компании", при этом предусмотреть возможность запретить показ отдельных новостей). Т.е максимально просто, понятно клиенту, но и максимально четко. И обязательно оговорить пункт, что если в ТЗ что-то не оговорено, то делается на усмотрение разработчика, и переделка данного пункта после сдачи проекта делается за отдельные деньги. Очень важен этот пункт для больбы с заказчиками, которые пытаются сдалать серьезный сайт за копейки, поставив простую задачу, а потом (после того, как договор подписан и все уже сделано) садятся на шею и требуют бесконечных усовершенствований, руководствуясь правилом, что клиент всегда прав.
По моему опыту в ТЗ (точнее, в задании на разработку) для корп. сайта должна быть максимально полно описана гл. страница (возможно с прототипом макета в виде диаграммы), пожелания к дизайну (шрифты, цвета, и.т.п.), а также все динамические блоки с довольно подробным описанием (например: выводить 10 последних заголовоков новостей раздела "новости компании", при этом предусмотреть возможность запретить показ отдельных новостей). Т.е максимально просто, понятно клиенту, но и максимально четко. И обязательно оговорить пункт, что если в ТЗ что-то не оговорено, то делается на усмотрение разработчика, и переделка данного пункта после сдачи проекта делается за отдельные деньги. Очень важен этот пункт для больбы с заказчиками, которые пытаются сдалать серьезный сайт за копейки, поставив простую задачу, а потом (после того, как договор подписан и все уже сделано) садятся на шею и требуют бесконечных усовершенствований, руководствуясь правилом, что клиент всегда прав.
Dimush
Guest
> по институту) для _большинства_ веб-проектов - стрельба из пушки по воробьям
Если под «корпоративным веб-сайтом» понимается сайт из 4-х страничек, с контактной информацией и прайс-листом, то здесь соответственно так же как и заказ рекламного буклета в типографии: согласовали информацию, подобрали цвета и шрифты, показали макет, наштамповали.
Если рассматривать сайт, как информационную систему, от которой должен быть какой-то прок, то соответственно так же как и для любой ИС, для начала необходимо обследовать предметную область объекта, после чего обработать полученные данные, и на основе этих данных составить техническое задание, как план проведения проектных работ, в котором должны быть отражены требования, ограничения и экономическое обоснование(что бы было ясно по силам ли это заказчику и исполнителю), после чего уже можно приступить к проектированию, которое заключает в себе этап концептуального проектирования(во время которого более атомарно рассматривается объект и варианты решения поставленных задач) и этап реализации, в заключение этап отладки и внедрения.
Этап составления технического задания, самый короткий, и нужен для того, что бы предложить заказчику возможные сценарии дальнейшей реализации проекта.
Т.е. тут два варианта, либо относим веб-сайт к декоративно-рекламной продукции, либо к ИС(или как минимум в качестве интерфейса к некой ИС) и подходим к разработке соответствующим образом.
Если под «корпоративным веб-сайтом» понимается сайт из 4-х страничек, с контактной информацией и прайс-листом, то здесь соответственно так же как и заказ рекламного буклета в типографии: согласовали информацию, подобрали цвета и шрифты, показали макет, наштамповали.
Если рассматривать сайт, как информационную систему, от которой должен быть какой-то прок, то соответственно так же как и для любой ИС, для начала необходимо обследовать предметную область объекта, после чего обработать полученные данные, и на основе этих данных составить техническое задание, как план проведения проектных работ, в котором должны быть отражены требования, ограничения и экономическое обоснование(что бы было ясно по силам ли это заказчику и исполнителю), после чего уже можно приступить к проектированию, которое заключает в себе этап концептуального проектирования(во время которого более атомарно рассматривается объект и варианты решения поставленных задач) и этап реализации, в заключение этап отладки и внедрения.
Этап составления технического задания, самый короткий, и нужен для того, что бы предложить заказчику возможные сценарии дальнейшей реализации проекта.
Т.е. тут два варианта, либо относим веб-сайт к декоративно-рекламной продукции, либо к ИС(или как минимум в качестве интерфейса к некой ИС) и подходим к разработке соответствующим образом.
alexbra
Guest
Перред тем как писать ТЗ нужно знать зачем оно тебе нужно...
Если ТЗ не написать есть вариант того ,что клиент не слезет с тебя.
Вы договоритесь о разработке хомепаге за 100 у.е. практически без дизайна и прочее, а через два дня после сдачи проекта до оплаты он начнет тебя проситт вставить разные "мелочи" на сайт... за те же самые деньги.
Чтобы такого не было - нужно просто грамотно писать ТЗ.
А грамотно писать научишься, когда забесплатно доработаешь пару проектов...
Если ТЗ не написать есть вариант того ,что клиент не слезет с тебя.
Вы договоритесь о разработке хомепаге за 100 у.е. практически без дизайна и прочее, а через два дня после сдачи проекта до оплаты он начнет тебя проситт вставить разные "мелочи" на сайт... за те же самые деньги.
Чтобы такого не было - нужно просто грамотно писать ТЗ.
А грамотно писать научишься, когда забесплатно доработаешь пару проектов...
robocomp
Новичок
Вообще-то, чтобы не просили забесплатно дорабатыват надо сначала деньги получать, потом проект переносить на хостинг клиента.
В таком случае он тебя _ничего_ забесплатно не попросит.
Ну или, если попросит, ты можешь и отказать.
При чём тут ТЗ?
Если ты ему проект перенёс, а денег не получил, клиент может сказать, что он в гробу видел твоё тз и денег ты не получишь, пока не сделаешь маленькую доработку.
И что ты возразишь? В тз этого не было? Врядли это поможет.
В таком случае он тебя _ничего_ забесплатно не попросит.
Ну или, если попросит, ты можешь и отказать.
При чём тут ТЗ?
Если ты ему проект перенёс, а денег не получил, клиент может сказать, что он в гробу видел твоё тз и денег ты не получишь, пока не сделаешь маленькую доработку.
И что ты возразишь? В тз этого не было? Врядли это поможет.