Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: AndreyB от 27 Февраля 2010, 09:36:55
-
Привет всем!
Вопрос: Кто обычно пишет ТЗ?
Действующие лица:
1 Разработчик - внешняя организация исполнитель
2 Организация заказчик
2.1 Отдел АСУ
2.2 Отдел где будет внядряться ПО
-
Как написано в ГОСТ 34, ТЗ пишет разработчик и согласует у заказчика.
Однако на практике могут быть разные ситуации.
1. Разработчик полностью формирует ТЗ
2. Заказчик сам предоставляет ТЗ (получая его разным способом)
3. Разработчик и заказчик пишут ТЗ по сути вместе в ходе нескольких итераций
4. возможны и другие моменты
-
Как правило, ТЗ пишет тот, кому это больше всего нужно.
-
вообще-то в ГОСТе написано следующее:
Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.).
При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который либо выбирает предпочтительный вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на АС.
-
больше всего соответствует действительности "Как правило, ТЗ пишет тот, кому это больше всего нужно."
Зачастую заказчик не в состоянии писать нормальное ТЗ, а то что у него получается - это некий список требований (функциональных и не очень!!)
Происходит это не в силу того что люди у заказчика глупые а потому что у них других текущих работ море и остановиться подумать над ТЗ им некогда
работал с более менее крупными банками и розницей - почти везде это так
Бывают правда исключения...
-
Происходит это не в силу того что люди у заказчика глупые а потому что
это не их обязанность.
-
если еще точнее, то причина - редко встречающееся сочетание знания предметной области и одновременно достаточный уровень владения теми же информационными технологиями. да и время тоже немаловажный фактор.
заодно могу привести аналогию, когда нужно провести какую-нибудь электрическую сеть или поставить кондиционер, между исполнителем и заказчиком возникают совершенно аналогичные взаимодействия: одни хотят получить готовые требования. а другие ждут, что требования для них сформулирует специалист.
-
Читайте статью Страшная правда о техническом задании (http://tdocs.su/6740), в ней учтены все нормативы, кроме ГОСТ В. Военные ТЗ должен писать заказчик.
-
У меня в группе был опрос на эту тему, вот такая статистика получилась:
Кто пишет ТЗ?
аналитик - 63%
программист - 18%
заказчик - 15%
кто-то другой - 4%
В группе 1/3 участников аналитики (сколько их среди ответивших, не знаю).
-
Не опрашивать надо, а ГОСТы изучать :)
-
Не опрашивать надо, а ГОСТы изучать :)
Какие ГОСТы?.. вы что полагаете, их боги пишут? А в реальном проекте много вы ГОСТов использовали?.. И как, понравилось?...
Любой стандарт несовершенен именно в силу своей универсальности. На практике выкидываешь в среднем половину, в зависимости от задачи.
-
А сколько обычно уходит времени на разработку ТЗ?
-
А сколько обычно уходит времени на разработку ТЗ?
Ну вот, например, у меня на прошлой неделе ушло два дня. :)
Но это, конечно, очень простая система, у которой к тому же есть работающий прототип.
-
А сколько обычно уходит времени на разработку ТЗ?
По-разному.
Могу только на примерах рассказать:
Вот на эту систему (http://bssys.com/credit/special/bank/) я писала ТЗ 3,5 месяца.
Вот на эту (http://bssys.com/credit/special/reporter/) - месяца два.
ТЗ на интеграцию этой системы (http://bssys.com/credit/special/deliver/) с другой системой денежных переводов - 1 месяц.
Это при длительности проектов от 6 месяцев до года.
ТЗ на свой проект (http://analit.biz/) написала за 2 недели, перед этим около месяца потратила на концепцию.
Все зависит от степени проработанности темы и налаженности коммуникации с заказчиком.
Надо понимать, что собственно документ можно написать довольно быстро - но ему предшествует аналитическая работа разного объема, и собственно это и есть постановка задачи.
-
По-разному.
Могу только на примерах рассказать:
Вот на эту систему (http://bssys.com/credit/special/bank/) я писала ТЗ 3,5 месяца.
Вот на эту (http://bssys.com/credit/special/reporter/) - месяца два.
ТЗ на интеграцию этой системы (http://bssys.com/credit/special/deliver/) с другой системой денежных переводов - 1 месяц.
Это при длительности проектов от 6 месяцев до года.
ТЗ на свой проект (http://analit.biz/) написала за 2 недели, перед этим около месяца потратила на концепцию.
Все зависит от степени проработанности темы и налаженности коммуникации с заказчиком.
Надо понимать, что собственно документ можно написать довольно быстро - но ему предшествует аналитическая работа разного объема, и собственно это и есть постановка задачи.
Интересно а я за какое время напишу?Надо написать всего 6 ТЗ.По сложности пока трудно сказать.
Ух глаза боятся а руки делают.
-
Ух глаза боятся а руки делают.
Хороший солдат :) тут ведь как: не попробуешь - не узнаешь.
-
А делал кто-нибудь версии ТЗ?
Я имею ввиду: Одна версия для ген директора(иначе не подпишет) , а другая для разработчиков?
-
К сожалению, был аналогичный опыт.
-
А делал кто-нибудь версии ТЗ?
Я имею ввиду: Одна версия для ген директора(иначе не подпишет) , а другая для разработчиков?
Для ген.директора можно составить концепцию будущей системы (сборник высокоуровневых требований), а для разработчиков, на основании этой концепции, ТЗ.
-
По-разному.
Могу только на примерах рассказать:
Вот на эту систему (http://bssys.com/credit/special/bank/) я писала ТЗ 3,5 месяца.
Вот на эту (http://bssys.com/credit/special/reporter/) - месяца два.
ТЗ на интеграцию этой системы (http://bssys.com/credit/special/deliver/) с другой системой денежных переводов - 1 месяц.
Это при длительности проектов от 6 месяцев до года.
ТЗ на свой проект (http://analit.biz/) написала за 2 недели, перед этим около месяца потратила на концепцию.
Все зависит от степени проработанности темы и налаженности коммуникации с заказчиком.
Надо понимать, что собственно документ можно написать довольно быстро - но ему предшествует аналитическая работа разного объема, и собственно это и есть постановка задачи.
IDA!
А сколько по объему (в листах) получились ТЗ?
-
IDA!
А сколько по объему (в листах) получились ТЗ?
30-80 в среднем.
Больше бывало за счет описаний форматов сообщений (там, где требовалась интеграция разных систем).
Вообще это от степени детализации зависит.
-
Какие ГОСТы?.. вы что полагаете, их боги пишут? А в реальном проекте много вы ГОСТов использовали?.. И как, понравилось?...
Знаете ли, раньше их писали если не боги, то полубоги. Посмотрите состав авторского коллектива на обложке бумажной версии. К разработке ГОСТ привлекались высококвалифицированные специалисты. Сейчас ГОСТ никто не пишет, а просто тупо переводят с какого-нить новозеландского языка и называют эту шнягу ГОСТ Р такой-то...
В реальных проектах я много ГОСТ применяю, а не использую. Очень нравится. С учетом того, что общий стаж у меня без малого 31 год :) И проектов по ГОСТ мной сделано столько, что даже затрудняюсь подсчитать...
-
Знаете ли, раньше их писали если не боги, то полубоги. Посмотрите состав авторского коллектива на обложке бумажной версии. К разработке ГОСТ привлекались высококвалифицированные специалисты.
Да-да, а начальник моего начальника - ИТ директор одного банка - участвовал в разработке ПО для посадки космического корабля "Буран". Всем дружно встать на колени и молиться?...
У каждого проекта есть своя специфика, нет универсальных инструментов - одним подходит ГОСТ, другим на стене пещеры нацарапал - и нормально. Нельзя ж так абсолютизировать стандарты, жизнь-то она динамичная, разнообразная...
-
У каждого проекта есть своя специфика, нет универсальных инструментов - одним подходит ГОСТ, другим на стене пещеры нацарапал - и нормально. Нельзя ж так абсолютизировать стандарты, жизнь-то она динамичная, разнообразная...
Как бы Вам объяснить... Если Вы занимаетесь автоматизированными системами, то ГОСТ 34-й системы - "наиболее общий закон" для них. 34-я система охватывает все без исключения виды АС, а специфика этих АС расписывается в других, "отраслевых" стандартах. Например, для систем электронного документооборота существует свой норматив - ГСДОУ, для автоматизированных измерительно-информационных систем учета электроэнергии - требования ОАО "АТС", ряд Р, РД, МУ, касающихся именно измерительных систем и измерений вообще.
Что касается разнообразия и динамики: в 99 % случаев имеет место быть четкое непонимание разницы между комплексом программ и автоматизированной системой. Разработчик делает комплекс программ для железа заказчика, а документирует не по ГОСТ 19, а по ГОСТ 34. В итоге заказчик устраивает разработчику такое разнообразие и динамику, что вытаскивать проект приходится большой кровью. Где-то год тому назад мои клиенты сдавали огромный программный комплекс ЦентрТелекому, так им предложили (в рамках ГОСТ 34) объехать все объекты ЦентрТелекома и провести дополнительное обследование, задокументировать все, включая кабельную инфраструктуру... Еле уговорили - это же безумие, да еще и за свой счет...
Отсюда вывод: наскальные письмена - штука зверски опасная. Поэтому опираться стоит на ГОСТ, только систему ГОСТ надо правильно выбрать и четко прописать в Договоре, по каким ГОСТ работаем. Тогда проблем не будет. Или их будет минимум. Так что ГОСТ подходит всем :)
-
Как бы Вам объяснить... Если Вы занимаетесь автоматизированными системами
Чем я только не занималась - спасибо, что просветили :) Фаллометрия?... Нет, за 10 лет наигралась :)
Почему-то такие разговоры сводятся обычно к жалобам на заказчика. Я на это могу ответить из своего опыта только: не умеете работать с заказчиками - предоставьте это тем, кто умеет :) А уж они найдут, какие стандарты использовать.
-
Чем я только не занималась - спасибо, что просветили :) Фаллометрия?... Нет, за 10 лет наигралась :)
Почему-то такие разговоры сводятся обычно к жалобам на заказчика. Я на это могу ответить из своего опыта только: не умеете работать с заказчиками - предоставьте это тем, кто умеет :) А уж они найдут, какие стандарты использовать.
М-да... Спасибо, Ида, мне все понятно.