» Техническое задание

Писал в конторе один проект по автоматизации, потом не сошлись в деньгах - ушел (там остался старый проект, но в связи с расширением он не годится).
Сейчас есть возможность его закончить, но сначала они хотят ТЗ, потому как сами написать его не могут, и только после согласования будут решать - писать его
мне или отдать. Я не против его написать, хотя с изложением у меня туговато, но они хотят ТЗ с написанием гуя, подробной документации+руководство,
описания всех алгоритмов на клиенте и бд!... Показывают на ГОСТ-ы, но там каждый может понять по своему. Об "основные требования к АСУ" можно сказать
"чтобы работала бухгалтерия" или расписывать все на несколько листов/часов/дней/ и тд... Никогда не писал ТЗ и спрашиваю у окружающих как написать ТЗ, чтобы каждая из сторон
взяла свое и после не было недоразумений (вроде работает, но думал тут будет так, а тут эдак)+(алгоритмы и структуру БД описывать/писать в ТЗ не собираюсь)+сколько это будет стоить + как лучше обговорить оплату?
Немного о проекте : контора занимается транспортными-эксп. услугами по России и ближнему зарубежью, а также некоторые филиалы оказывает другие услуги населению,
филиалы находятся по всей Росии + куча всякий "мелочей".

PS. 50-70% от необходимого в бд и клиенте есть, осталось написать недостающее, самое главное - деньги. А также перенести старую бд на новую (общего в их структурах маловато)

Посмотри здесь
http://forum.ru-board.com/topic.cgi?forum=33&topic=5838#1

Цитата:

но сначала они хотят ТЗ, потому как сами написать его не могут

Что же получается: "Организация приглашает на работу физика-ядерщика со своей испытательной базой"

Цитата:

50-70% от необходимого в бд и клиенте есть, осталось написать недостающее, самое главное - деньги. А также перенести старую бд на новую (общего в их структурах маловато

Если структура БД полностью меняется - то это фактически новый проект

Цитата:

Посмотри здесь

смотрел

Цитата:

то же получается: "Организация приглашает на работу физика-ядерщика со своей испытательной базой"

в этой конторе 3 года работал, знаю что да как. Конкретного ТЗ никогда не было, просто писал, что видел.

Цитата:

Если структура БД полностью меняется

нет. дополняется

drunk2
В моём понимании ТЗ - это то что должна делать программа. А вот то что да как программа делает скорее всего называется инструкция програмиста(это точно будет самое нудное).

Цитата:

но они хотят ТЗ

То что от тебя хотят, отнюдь не ТЗ. Это называется:
Цитата:

"с написанием гуя...+руководство"

"руководство пользователя"
Цитата:

подробной документаци

"описание программы"
Цитата:

описания всех алгоритмов на клиенте

"руководство программиста". Причём это три разных документа, предназначенных для трёх разных случаев. И делаются они по окончании работы над проектом, а не наоборот - проект на их основе. Пусть не вешают лапшу на уши - я сам по ГОСТам работал - и не перекладывают на чужие плечи свои обязанности. Автор имеет право от заказчика требовать ТЗ, а не по наитию что-то там выдумывать, чтобы заказчик выдвигал замечания или соглашался.
Цитата:

Показывают на ГОСТ-ы...

Пусть сначала сами почитают.

От них требовать ничего не получится. Они не могут составить ТЗ. Хотят, чтобы я составил требования и их же выполнял после подписания. Итого:
Цитата:

Пишу ТЗ по ГОСТу исключая элементы проектирования и способы реализации. Проект буду сдавать по частям.

Добавлено:
Всем спасибо.
Примерами ТЗ поделится не прошу, знаю, что не дадите.

Когда писать его будешь, ненадо углубляться в подробности и создавать себе заранее лишние барьеры. Применяй максимум абстрактных обтекаемых формулировок. Описывать алгоритмы ни в ТЗ, ни в Руководстве Пользователя вообще смысла нет (бывают исключения, но это явно не твой случай).

Требовать от заказчика ТЗ бессмысленно очень часто. Нормальное явление, когда разработка уже на завершающей стадии (опытная эксплуатация например), а ТЗ еще не подписано. Твое дело написать ТЗ по гостам с миниманым количеством технических подробностей и дать им на рассмотрение. Где они считают важным, сами пусть внесут ясность.

Судя по всему от тебя хотят не только ТЗ, но и Технические Требования, и Технические Условия, и Руководство Пользователя. Разработка полного комплекта документации всегда дело непростое, долгое и весьма неплохо оплачиваемое (может быть сравнимо со стоимостью самой разработки).

Писал недавно ТЗ по ГОСТУ, если надо могу с понедельника уточнить на работе какой ГОСТ.

RffR255
было бы замечательно

В понедельник вечером отпишу.

Цитата:

Автор имеет право от заказчика требовать ТЗ, а не по наитию что-то там выдумывать, чтобы заказчик выдвигал замечания или соглашался

Это интересно когда так было? Я в свое время немного позанимался промышленной автоматизацией и не помню ни одного случая когда заказчик делал бы сам ТЗ.
Теперь что касается ГОСТов:
1) ГОСТ 19.102-77 - Стадии разработки программ и программной документации.
2) ГОСТ 19.201-78 - Требования к содержанию и оформлению технического задания.

нашел: _http://standards.narod.ru/gosts/gost19/gost19.htm

Ну что же, смотрю меня опередили.

Arion
А я и не имел в виду, что это всегда не так. Я говорил - "имеет право". И кстати, это "имеет право" ИМХО необходимо в ГОСТах оформить, как обязательное требование, а не желаемое. Я зарёкся писать что-то на заказ без ТЗ. Пусть даже формального. Иначе заказчик потом душу из тебя вытрясывает и тебя же во всех смертных грехах обвиняет, типа воспользовался нашей неграммотностью, нагло подставил, сделал фигню и ещё денег требует. Если заказчик сам не может сформулировать, "чего ему надобно" © Золотая Рыбка, о какой работе речь-то?

Когда сказал, что ТЗ по ГОСТ-у займет месяц - переобулись и сейчас хотят чего нить "побыстрому". Сейчас сам хочу все расписать, чтобы не было карусели как до денег дойдет.

Мне приходилось принимать участие в составлении ТЗ.
Дело обстоит так. Согласно, ЕСПД, ТЗ должен писать РАЗРАБОТЧИК и согласовывать с ЗАКАЗЧИКОМ. То же самое говорится и в RUP (только там это называется слегонца по другому).
Вкратце. ТЗ нужно именно для разработчика и оно должно урегулировать все вопросы, связанные с функционированием системы у заказчика. То есть делается так.
Разработчик долго зависает у заказчика (или наоборот). В процессе этого зависания они оговаривают, как должна работать система.
Если заказчику принципиально, что это окошко должно иметь 2 кнопки "Хочу" и "Не хочу", это надо отражать в ТЗ. Если разработчик сумел убедить заказчика, что это ему должно быть пофиг, это не пишется.
Далее, в ТЗ могут(!) оговариваться вопросы, связанные с требованиями к аппаратуре, софту, обслуживающиму персоналу и пользователям (Это особенно важно при работе с некоторыми заказчиками, которые любят сваливать свою косорукость на недоработки программы).
В этот документ могут вписываться требования заказчика по скорости работы модулей, времени реакции и т.д.
В ТЗ может отражаться структура БД, если это принципиально для заказчика. Если вы с ним договоритесь, что структуру разрабатываешь ты - нифига писать не надо.

Ну и так далее.

Вместо заключения.
ТЗ - это твоя защита перед заказчиком, что ты сделал все что ему было надо. На случай, если он вдруг решит, что кнопочка не так называется или не туда падает. Ответ обычный - "в ТЗ не было и идите лесом". Поэтому это очень важный документ и твоей т.з. и с заказчиковой. К нему надо подходить сурьезно.

А структура БД, рисунки форм, правила инсталляции и администрирования должны описываться ПОСЛЕ разработки в соответствующих руководствах. По ЕСПД их должно быть минимум три - Руководство пользователя, руководство программиста и руководство администратора. Те еще книжонки.

Mickey_from_nsk
Цитата:

Согласно, ЕСПД, ТЗ должен писать РАЗРАБОТЧИК и согласовывать с ЗАКАЗЧИКОМ.

Вот это-то мне и не нравится. Лучше наоборот.
Цитата:

По ЕСПД их должно быть минимум три - Руководство пользователя, руководство программиста и руководство администратора. Те еще книжонки.

Там, где я по ГОСТам работал, в обязательном порядке было ещё Описание программы. По мне - так самое не напрягающее из вышеперечисленного. ИМХО придётся и её писать тоже.

Qraizer

Цитата:

Вот это-то мне и не нравится. Лучше наоборот.

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

Поверю. Мой опыт возможно, не так широк. Но всё равно, ты меня не убедил. Так что моё ИМХО - это моё ИМХО.

Qraizer
Пардон. Про опыт - это наверно я зря пальцЫ загнул.
Но за тебя рад, если тебе попадались заказчики, которые знали чего хотят и могли это расписать так, чтобы ты согласился это делать.

Добавлено:
Qraizer

Цитата:

Там, где я по ГОСТам работал, в обязательном порядке было ещё Описание программы. По мне - так самое не напрягающее из вышеперечисленного. ИМХО придётся и её писать тоже.

Чет только сейчас обратил внимание на этот абзац.
Если не ошибаюсь, описание программы входит в состав Руководства программиста. Отдельного такого документа по ЕСПД нет. Да и, честно говоря, не представляю, кому он нужен кроме программиста.

Mickey_from_nsk
Цитата:

Иначе потом не отопрешься от его претензий, что "я подразумевал, что кнопка должна быть синей"...

Спокойно отмажешься, если это не было ЗАПИСАНО с ТЗ

Mickey_from_nsk
Цитата:

...Но за тебя рад, если тебе попадались заказчики, которые знали чего хотят и могли это расписать так, чтобы ты согласился это делать.

Не совсем так. ТЗ давалось моим начальником, который собственно и утрясал все моменты "предварительных переговоров". Но хоть он это и делал весьма грамотно, как неспециалист в моей области косяков хватал.
Цитата:

Цитата: Там, где я по ГОСТам работал, в обязательном порядке было ещё Описание программы. По мне - так самое не напрягающее из вышеперечисленного. ИМХО придётся и её писать тоже.

...
Если не ошибаюсь, описание программы входит в состав Руководства программиста. Отдельного такого документа по ЕСПД нет. Да и, честно говоря, не представляю, кому он нужен кроме программиста.

VovIK

Цитата:

Спокойно отмажешься, если это не было ЗАПИСАНО с ТЗ

Квак бы не квак. Если в ТЗ написано, что-нибудь типа "кнопка "ХАЧУ" должна соответствовать стилю интерфейса" (или что-то еще замудренее, заказчики это могут), фигу ты им потом докажешь, что она соответствует. Там где в ТЗ не прописаны объективные критерии качества программы, заказчик (если припрет) может докопаться до любой запятой.
Qraizer

Цитата:

Руководство программиста - это документ который нужен, если твоё произведение экспортирует программный интерфейс, используемый другими.

Давненько в ЕСПД не заглядывал, но с последнего заглядывания помнится, что руководство программиста может составляться еще если ты передаешь исходники заказчику и он собирается продолжать развитие программы своими силами. Вот тогда описание программы и нуна. В противном случае это все можно закрыть словами KHOW-HOW и оговорить это в договоре на разработку. Если даешь библиотеку, тогда - да. Надо описывать все что торчит наружу. Но это скорее "руководство пользователя", чем "руководство программиста", хотя пользователем в этом случае будут программисты заказчика.
В твоем определении "Руководство программиста" - это некий внутренний документ для разработчиков твоей компании, который должен быть снабжен соотвествующим грифом и который заказчику не предоставляется.

Цитата:

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

Я тоже давно не заглядывал (и слава богу). Но в "моём определении" - это как раз "Описание программы". А Руководство программиста как раз наоборот - описание открытого интерфейса программного модуля. Впрочем, я не настаиваю. Это всё по памяти, а заглядывать в ЕСПД чё-то не хочется.

ТЗ готово, смущает один момент, тк я физ. лицо:
...
В соответствии с договором №___ между "ФИО" (далее Разработчик) и ООО «Контора» (далее Заказчик), Разработчик проектирует базу данных и клиентское приложение для программного комплекса «Программа» (далее ПК).
...
будет ли это в силе после подписания или необходимо создавать ЧП?

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

Mickey_from_nsk

Цитата:

Квак бы не квак. Если в ТЗ написано, что-нибудь типа "кнопка "ХАЧУ" должна соответствовать стилю интерфейса" (или что-то еще замудренее, заказчики это могут), фигу ты им потом докажешь, что она соответствует. Там где в ТЗ не прописаны объективные критерии качества программы, заказчик (если припрет) может докопаться до любой запятой.

Такие заказчики:
1 - отсеиваются на стадии ДО написания ТЗ;
или
2 - им популярно обьясняется, сколько будет стоит написание такого ТЗ

VovIK

Цитата:

Такие заказчики:
1 - отсеиваются на стадии ДО написания ТЗ;
или
2 - им популярно обьясняется, сколько будет стоит написание такого ТЗ

1. Заказчик имеет КОНКРЕТНОЕ БАБЛО и конкретно хочет чего-то, а чего - сам не знает. Писать ему еще как лениво. Кидать его и говорить, чтобы шел в другую контору - себе дороже.
2. Объясняется, причем они согласны за это платить. Бабла много - платят легко.

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

Сдал конторе ПК, поставил на тестовый сервер, показал принцип работы. Оказалось, они думали, что я подыму базу во всех филиалах, покажу всем, как работает клиент … и много чего еще. Хочу переписать договор (я частное лицо), скорей всего это не имеет юр. силы, но они ссылаются но прошлый договор – типа мы считали, что под этим подразумевается то и се. Сейчас пишу, чего там точно не будет за бесплатно и хочу изменить принцип оплаты. Так сойдет?
про то, что им предоставляется только клиент и бд (Без внедрения, оно идет отдельно. Считают, что им необходимо посмотреть как все филиалы работают, а потом решат - работает ли ПК и стоит ли его внедрять):

Цитата:

По окончанию первого, второго и третьего этапов, Разработчик устанавливает БД "..." на тестовый сервер и демонстрирует Заказчику работу ПК в соответствии с требованиями, изложенными в данном Техническом задании

про деньги:

Цитата:

Работы по проектированию ПК производятся в четыре этапа.
...
Длительность четвертого этапа составляет 30 дней, стоимость Хр. Предоплата 50%.
...
Началом этапа считается день, следующий за днем сдачи ПК в эксплуатацию, расчета Заказчика с Разработчиком за предыдущий этап а также предоплатой за следующий.

ЗЫ поднять бд на серверах они не могут, тк не сошлись в деньгах с прошлым админом, и теперь "админ по *nix" пытается это сделать уже две недели%)

В идеале в тз должен указываться порядок приемки и внедрения системы,
и гост немного другой посмотри ГОСТ 34.602-89