"Jimmy" <nospam@sql.ru>; wrote in message news:3060252@sql.ru...

Hi!

> Зачем в одном документе? Очень просто - Вы когда нибудь пробовали
> утвердить и согласовать достаточно объемный документ в большой
> организации? А два?.. По моему опыту, на утверждение ТЗ, в лучшем
> случае, уходит около 2-х рабочих недель (бывало до 2-х месяцев доходило).
> Умножить это на 2?

У нас в конторе вообще нет такого понятия, как ТЗ, которое зачем-то нужно
утверждать и которое почему-то разработчик пишет сам себе, ибо это
все неэффективно. Потому и проблем таких нет. Все гораздо проще.
Есть требования заказчика, которые обсуждаются (уточняются)
между заказчиком и проектировщиком. Это стадия анализа.

Когда требования становятся достаточно внятными, проектировщиком
пишется набор спецификаций. Это спецификации на общую
архитектуру системы, информационно-логические модели данных,
протоколы передачи данных, пользовательский интерфейс, и т.д.
Одновременно другими сотрудниками пишутся свои спецификации.
Например, QA пишет спецификации тестирования. Спецификации
согласовываются с заказчиком, разработчиками, тестерами
и уточняются. Разработчики делают макеты с целью проверки
выполнимости спецификаций (устранение рисков на ранней
стадии). Это стадия проектирования.

Только после этого становится возможно оценить объем работ,
сроки и стоимость проекта. Далее идет стадия реализации и т.д.

На любой стадии любым участником проекта допускается
инициировать процедуру внесение изменений в любую спецификацию
и, соответственно, пересогласование документов. При этом
возможен пересчет сроков и стоимости проекта. У нас в ходе
выполнения проекта пересогласование происходит десятки раз.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3

"ЮВ" <nospam@sql.ru>; wrote in message news:3063393@sql.ru...

Hi!

> Вообще-то проверка принципиальной возможности реализации
> какой-либо идеи, сроков и трудозатрат, необходимых материальных
> ресурсов и т. п. выявляется на стадии НИР
> (Научно-иссследовательская работа), результатом которой
> и может быть ТЗ (Техническое задание) на выполнение проекта.

Да можно хоть горшком назвать. Но мы предпочитаем понятные
по смыслу термины. Мы диссертаций не пишем, потому вовсе
не научная и не исследовательская. Просто проектирование.
И результатом является не задание, а описание с необходимым
уровнем детализации того, как должна работать система (обычно
это десятки разных документов).

Задание подразумевает, что заказчик что-то задает исполнителю
и в процессе работ это задание изменению не подлежит.
На практике это не так. Заказчик может лишь составить
список требований не более десятка предложений. Обычно
невнятных и противоречивых. Называть это "документом"
не имеет смысла. Потому реально обычно исполнитель
предлагает заказчику спецификацию того, что должно быть
сделано. И если заказчика все устраивает, то можно
приступать к реализации. В процессе либо у исполнителя
может что-то не получаться, либо, что чаще, у заказчика
появляются дополнительные требования и в спецификацию
вносятся изменения.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3

"byur" <nospam@sql.ru>; wrote in message news:3063769@sql.ru...

Hi!

> А принимает заказчик систему по архитектурной спецификации?

Принимает заказчик систему после ее установки и запуска
в опытную эксплуатацию. И если тут выявляются архитектурные
проблемы, то исправлять уже поздно. Надо все переделывать.
Именно в целях исключения таких рисков архитектурные (как и почти
все остальные) спецификации согласовываются с заказчиком.

> Требования то как-то фиксировать нужно и потом доказывать
> на приемке что они реализованы.

Существует такой документ, как "обсуждение спецификаций".
То есть, список рассылки, форум, типа этого форума, где
обсуждаются вопросы между заказчиками и исполнителями.
Его всегда можно распечатать и предъявить заказчику, когда
и что он говорил, на чем настаивал и о чем его предупреждали.
Говоря проще, из спецификаций понятно, какие именно решения
были приняты. Но почему были приняты именно такие, а не другие,
понятно лишь из обсуждения.

И если система сделана по-дурацки только потому, что заказчик
на этом настоял, то на приемке ему и предъявляются эти спецификации
с их обсуждением.

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

Другой вариант: заказчик формулирует прямо противоположные
требования. Чисто формально я могу их реализовать через задний
проход и на приемке чисто формально доказать, что они реализованы.
В процессе эксплуатации заказчик быстро поймет, что ни ту ни другую
функциональность на практике эффективно заюзать все равно
невозможно.

Третий вариант: заказчик формулирует избыточные требования.
Например хочет, чтобы к системе был веб-интерфейс, ибо так
сейчас модно. Необходимо доказать заказчику, что веб-интерфейс
к системе ему не нужен. В системе очень сложный интерфейс,
который невозможно реализовать на банальном HTML. Как минимум,
это DHTML с кучей скриптов. Нужно решать проблемы совместимости
с разными браузерами. Другой аспект - трафик. Когда в системе
под 500 одновременно работающих юзеров, в том числе и по медленным
каналам, то это критично. Если нужно просто отсортировать таблицу
по другому столбцу, то глупо заново получать все данные с сервера.
И вообще, перегрузка страницы на любой чих - заведомо не работающее
решение. Передаваться должны только данные, и только необходимые
в данный момент. Отображение - забота клиента. Вывод: нужно делать
достаточно сложный апплет на яве, который будет исполняться
на клиенте, обмениваться XML пакетами данных с сервером приложений
и общаться с юзером.

А теперь вопрос: нафига это делать, если все то-же самое уже давно
есть в старом клиенте на C++, учитывая, что клиент будет работать
только под виндами.

Как многие заметили, я работаю с форумом через обычный
Outlook Express по NNTP, ибо сильно удобнее и быстрее, чем
через веб-интерфейс. А если платить за трафик через GRPS,
то еще и в разы дешевле.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3

"ЮВ" <nospam@sql.ru>; wrote in message news:3066245@sql.ru...

Hi!

> Если вы разрабатываете аналог (прототип) какой-либо
> достаточно известной системы (например,1С для
> какой-нибудь новой операционной среды), то стадия
> НИР здесь совершенно не нужна - все проектные
> решения известны.

Ну прям счаз. Допустим, 1C для КПК. Исходные данные:
очень маленький экран, очень мало кнопок. Очень мало
памяти для программ и данных. Если связь с сервером
по GPRS, то канал во-первых не жирный, во-вторых
нестабильный, в-третьих оплата по трафику. Как минимум,
пользовательский интерфейс нужно полностью
перепроектировать.

> Другое дело - разработка принципиально новой системы,
> о которой мало что известно (в смысле - а можно ли ее
> реализовать ?).

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

Повторюсь: всего лишь мелкая фича для уже давно
существующей системы.

> Если вы сразу начнете писать требования и спецификации,
> то вы действительно крутые специалисты, которым нет цены.

Начать с чего-то все равно нужно. Именно сразу. Пересогласовать
спецификации можно и позже. Допустим я пишу, что такие-то
функции системы реализуются на АБАПе. Разработчик под R3
либо точно знает, как это сделать, либо проверяет. Если у него
есть другие соображения по этому вопросу, он их высказывает.
Разработчик под R3 находится за 1000 километров. Заказчик
тоже за 1000 километров, но в другую сторону. Возможности
совещаний и приватных бесед нет. Потому сразу спецификация.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3

"iscrafm" <nospam@sql.ru>; wrote in message news:3063801@sql.ru...

Hi!

> Вы его просто по другому называете, но от этого смысл
> не меняется. То что Вы привели - состав ТЗ. Хоть
> спецификациями его назовите.

Вот как раз смысл и меняется.

> И кто Вам сказал, что ТЗ пишет разработчик сам себе?

Потому как больше некому. У нас спецификации пишут
проектировщики, разработчики, тестеры. И все сразу
встает на свои места.

> Стереотип срабатывает или байки?

Срабатывает стереотип у заказчика. Он понимает под ТЗ
совсем другое. И на идею пересогласовать ТЗ в середине
проекта выпадает в ступор.

> У Вас все гладко? А много фирм бьюся за подписями под
> актами...

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

> Теплица прямо какая-то.

Всего лишь тщательно продуманный и хорошо организованный
бизнес-процесс.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3

"!!!" <nospam@sql.ru>; wrote in message news:3068709@sql.ru...

Hi!

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

Бывает. Некоторые подписывают документы не читая, покупают
не глядя, платят деньги не глядя на сумму счета. Но это не наш
случай.

> ему, как правило, не интересны подробности реализации,
> его интересует решение задач.

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

> При чем здесь обсуждение? Есть согласованный документ,
> на основании которого и осуществляется сдача-приемка.

Согласованный кем? Бухгалтерами? Дворниками? Сантехниками?
И что такое "сдача-приемка" в вашем понимании? У нас это просто:
"...исполнитель передал компакт-диск с софтом и 12 томов печатной
документации, а заказчик принял компакт-диск и 12 томов печатной
документации. Дата. Подпись."

> Вы опять возвращаетесь к подробностям реализации, которые заказчика не
> интересуют

Если в спецификации написано "...для работы нужно 10Gb оптоволокно
к каждому компьютеру, суперкомпьютер Cray и пара мейнфреймов...", тоже
будете утверждать, что заказчика это не интересует? Ваши заказчики подмахнут
такое не глядя?

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

Оно не фиксируется. Оно постоянно меняется, уточняется и дополняется
по ходу проекта. Именно по этому у нас его и не называют ТЗ.

> Требования пишет не заказчик, а бизнес-аналитики разработчика.

Упс. А что тогда пишет заказчик? Набор "предметов для начала разговора"?
И чем в случае "необходимо, чтобы система работала в удаленных офисах"
могут помочь бизнес-аналитики? Я не спорю, специфика предметной области
в данной задаче присутствует. Например, у нас предметная область наложила
весьма неприятное ограничение: принципиальную невозможность работы
в оффлайне. То есть, независимо от количества юзеров и удаленности филиалов
сервер данных может быть только один и только в онлайне.

Опять-же, кто такие "бизнес-аналитики" в вашем понимании и какую
работу они выполняют.

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

Если настаивает и лишние бабки+время есть, то разумеется. Тем не менее,
объяснить ему бессмысленность такого требования необходимо. Иначе
объяснят другие. Заказчик ведь тоже не на необитаемом острове живет.
Желающих высказаться по поводу такого требования найдется достаточно
даже в этом форуме.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3

"!!!" <nospam@sql.ru>; wrote in message news:3068715@sql.ru...

Hi!

> А вот и подтверждение из первых рук

Подтверждения чему?

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

ТЗ не пишет никто, поскольку по смыслу русского языка,
это задание от заказчика к исполнителю (а не программиста
самому себе, почитайте форум и найдите хоть одно сообщение,
где бы разработчика не заставляли писать ТЗ). Заказчик
не в состоянии написать ТЗ. Это объективный факт.
У нас это осознали и потому такого документа просто нет.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3