Разработка технических заданий и спецификаций программных продуктов.

[Alf]

В данном топике, который возник как естественное расширение темы тестирования, предлагаю обсудить следующие вопросы:

- от кого и в каком виде мы получаем задания на разработку программ;

- что нас в этом не устраивает и мешает работать;

- как должны выглядеть идеальные с нашей точки зрения спецификации;

- какие формализмы могут помочь приблизиться к этому идеалу;

- какие инструменты и технологии могут оказаться реально полезными для этого;

- что нужно сделать, чтобы из хорошей спецификации получить качественный программный продукт (место и роль спецификаций в технологической цепочке);

- плюс ваши пожелания, если я упустил что-то важное.

[nikedeforest]

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

[Alf]

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

Не знает, зачем нужна программа и что она должна делать, и при этом готов взять на себя оплату полного цикла ее разработки?! Да на такого заказчика молиться нужно! Ведь за его деньги можно делать все что угодно, не противореча техническому заданию. Где только зав. каф. таких находит, я тоже хочу...

[nikedeforest]

Как я понимаю это чаще всего переходит в долгострой.
Странно, что ты не прокоментировал первую часть, видимо к первой части претензий нет.

[Alf]

Формальных претензий к первой части нет, суть отражена правильно. Только уж больно общая формулировка, а неконкретными фразами очень трудно руководствоваться в практической деятельности, хоть они и звучат правильно.

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

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

[Джон]

Скажу только, что прав зав.каф. На самом деле на практике действительно получается, что

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

С "незнает зачем" конечно утрировано, поэтому я зачеркнул, но всё остальное на 100%
И нет ничего хуже неопределённости, или, что тоже самое - описания в общих чертах желаний. "Это этот... как его? Волюнтаризм!" Особенно в наш век информационного перенасыщения умов, когда каждый всё знает. И каждый мог бы быть программистом, просто у него времени на всё не хватает. Но зато он очень хорошо может научить тебя КАК тебе надо программировать, абсолютно нифига не представляя ЧТО ему самому надо.

А молиться хочется действительно на

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

Только таких ещё ни разу не попадалось.

А только - "братан, короче прога нужна, вот это типа как фотошопе, вот тут как типа в ворде, а вон там типа как в эксель, ну ты понял?" И сиди и думай, что ему надо?
А самое гнусное, что когда ты сделаешь концепцию и "ВСЁ ПРЕДУСМОТРИШЬ" это принимается клиентом на ура! Он всем доволен, он видел прототип и это именно то, о чём он всю жизнь мечтал. Но через год, он получает бетту и выясняется, что таких наворотов никому не надо. Что 98% пользователей вообще уверены, что компьютер это Word+Excel, а земля плоская. И теперь надо сделать тоже самое, только граздо проще. Это ведь так легко! Сделайте кнопку чтобы переключать из profi режима в dummy, для тех 2%, на которых первоначально  было всё заточено. И всё! Не ну они конечно заплатят... за кнопку, только если это с самого начала не было предусмотрено системой, то надо менять систему, всё выкидывать и начинать сначала.
На это ессно никто не идёт, и получаются сплошные workarround. В ущерб фичам предусмотренным первоначальной концепцией. И дальнейшее развитие проекта превращается в бардак, в котором ни одни теоретические методы не работают.
По началу это сильно убивало и угнетало. Я даже аллегорию придумал - с карточным домиком. Те сначала ты делаешь очень сложный карточный небоскрёб, а потом тебя просят поменять вооон те три пиковые дамы в середине на одну треф. А потом ещё и ещё...

Ничего, со временем привык.

В общем "Дикари! Плакать хочется."

[Dimka]

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

Но никто не говорил, что он останется доволен результатом и не будет портить нервы, присылая ежедневно по 20 новых пожеланий и уточнений. Конечно, если он подписал себе полный произвол разработчика, можно его "прессовать". Но обычно происходит наоборот: продавцы с целью извлечения из клиента большего количества денег соглашаются на всё, и под "прессом" оказывается разработчик, энтропия которого должна быть выше энтропии невменяемого заказчика, но при этом должна получаться формализованная программная система. Главной технологией становится формализация процесса зарождения желаний у заказчика, чтобы заложить этот процесс в архитектуру системы.

С "незнает зачем" конечно утрировано

Ничуть не утрировано. Вопрос "зачем" главнее вопроса "что". При ответе на вопрос "зачем" принимается принципиальное решение: использовать программное обеспечение или так обойдёмся. А при ответе на вопрос "что" уже описываются детали.

В ситуации повального компьютерного фетишизма у мелких и средних заказчиков, впервые берущихся что-нибудь себе автоматизировать, когда полагается, что "компьютер за нас всё решит", вопрос "зачем" становится первоочередным для разработчика, ибо заказчик в своих фантазиях всегда отвечает на него "да". Так из-за одушевления компьютера заказчик уподобляется дитяте, играющему с огнём. Вроде интересно и красиво, а потом оказывается, что проблема не решилась, а лишь усугубилась, хаос увеличился, а деньги меж тем уже потрачены. Догадайтесь с трёх раз, на кого падёт "праведный" гнев заказчика? Ведь его "обманули", обвели вокруг пальца, навешали лапши, развели и т.д.

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

Риск можно уменьшать по двум направлениям: улучшать спецификации и... (см. ЛЕС ).

[Hooter]

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

Например, в моей ситуации: требований к системе - в природе не существует, зато есть ТЗ на систему, основанное на этих требованиях . ТЗ умещается на нескольких страницах. Это при том, что техническое описание проекта уже занимает пять толстых томов . Естесственно, ни на какое ТЗ при разработке опираться нельзя. Попытались решить эту проблему задав вопрос конечным пользователям "А что же вам действительно нужно". Пользователи долго думали, в конце концов выдали ответ типа: "Всё нужно!". Имхо, такая ситуация - уже классика.

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

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

ЗЫ. Сорри за оффтоп, но темы очень связанные. С точки зрения заказчика: как заставить разработчика выполнять обязательства и выдать в конце достаточно качественный продукт?
http://offline.computerra.ru/offline/2006/628/255292/
Себя никто не узнаёт? Я узнал. Я все время удивлялся, каким образом совершенно разные проекты могут заканчиваться одним и тем же - непринятым продуктом, потраченными деньгами и ссорой заказчика и исполнителя?

Добавлено через 2 часа, 30 минут и 22 секунды:
В соседней ветке возник момент, который мне показалсяя интересным
Привожу цитаты, чтобы было понятно, о чем речь.

Заказчик просит разработать некий компонент и получает его через некоторое время. Требования к компоненту следующие: способность работать в режиме 1 и режиме 2. Для компонента существуют модульные тесты (они же функциональные, в данном случае), которые проверяют работоспособность функций, требуемых пользователю: набор тестов 1 и набор 2 для каждого режима. Через некоторое время заказчик жалуется на ошибку выполнения. Поблема была локализована, и анализ кода довел нас до куска программы:

Код:

int f(Mode m)
{
    int res;
    if (Mode1 == m)
    {
       res =f1();
    }
    if (Mode2 == m)
    {
        res = f2();
    }
return res;

Анализ исходного кода показал, что отсутствует обработка случая, когда режим работы не является ни режимом 1, ни режимом 2. Был создан набор модульных тестов для третьего случая - набор тестов 3. Спецификация обновлена, проблема устранена и обновленная версия передена заказчику.

...
То есть, здесь не все так однозначно. Простой пример:

Заказчик просит разработать некий компонент и получает его через некоторое время. Требования к компоненту следующие: способность работать в режиме 1 и режиме 2.
...
Анализ исходного кода показал, что отсутствует обработка случая, когда режим работы не является ни режимом 1, ни режимом 2.

Я бы скорее увидел здесь не ошибку программиста, а дефект спецификации. Не оговорены ведь действия модуля в случае, если режим не равен ни 1, ни 2. Вызывать функцию с недопустимым аргументом - все равно что делить на нуль или извлекать квадратный корень из отрицательного числа: добром это дело не кончится. ...

Что считать ошибкой программиста, а что считать дефектом спецификации?
Кстати, Alf, о какой спецификации речь: о требованиях к компоненту, или о спецификации продукта, поставляемой с готовым продуктом?

В примере действительно не оговаривались такие требования к продукту, как его поведение в случае №3. Но, имхо, любая спецификация по умолчанию подразумевает стабильность работы компонента/продукта, а отсутствие обработки в программе случая 3 приводило к нарушению стабильности работы. Это первое.

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

Вопрос: кто ответственен за создавшуюся ситуацию? Заказчик, который описал требования к системе только в виде "позитивных тестов" (терминология Бейзера), или исполнитель, который не проверял компонент с помошью "негативных тестов" или простых тестов покрытия условий?

[PooH]

ИМХО, в указаном коде нет ошибки, при условии, что тип Mode является перечислимым типом допустимых режимов (Mode1 и Mode2). То есть, контроль за диапазоном входных значений лежит на приведении типов. А если иначе, то это явная ошибка программиста, не проверевшего входные параметры.

Вопрос: кто ответственен за создавшуюся ситуацию?

По-моему, программист. Ибо то, что "дадено" в условии, то же надо проверять. Точнее, то что система не работает в третьем режиме - ошибка спецификации. А вот определить, как реагирует на этот режим система - полностью задача программиста.

Если рассматривать приведенные код, как отдельный проект. То условия спецификации выполнены. Код работает в двух режимах. В других не работает. Вопрос в том как "не работает"? Или ошибку выдает и завершатся или перезагружает систему предварительно форматнув винт.

[Alf]

Что считать ошибкой программиста, а что считать дефектом спецификации?

Я бы разделил эти недочеты таким образом.

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

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

Кстати, Alf, о какой спецификации речь: о требованиях к компоненту, или о спецификации продукта, поставляемой с готовым продуктом?

Я думаю, что неполной была спецификация компонента. Поскольку заказчику требовалась не библиотека подпрограмм, а готовое изделие, внутреннее строение его не должно волновать.

В примере действительно не оговаривались такие требования к продукту, как его поведение в случае №3. Но, имхо, любая спецификация по умолчанию подразумевает стабильность работы компонента/продукта, а отсутствие обработки в программе случая 3 приводило к нарушению стабильности работы. Это первое.

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

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

См. предыдущий пункт.

Вопрос: кто ответственен за создавшуюся ситуацию? Заказчик, который описал требования к системе только в виде "позитивных тестов" (терминология Бейзера), или исполнитель, который не проверял компонент с помошью "негативных тестов" или простых тестов покрытия условий?

Я полагаю, неправ системный архитектор, который должен был выполнить одно из двух действий:

1) добавить в спецификацию модуля требования к реакции на ошибку (перечень исключений, список кодов ошибки, ...);

либо

2) гарантировать в вызывающем коде корректность параметра (либо 1, либо 2, но ничего более); решение спорное и не слишком изящное, но в этом случае допустимо исключить проверку в самом модуле.

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

[Hooter]

Я пока еще не буду комментировать ответы, может быть кто-нибудь еще заинтересуется этим вопросом. У меня есть мысли по этому поводу, но это конечно же - имхо.

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

Я задавал вопрос, исходя из абстрактных терминов "заказчик-исполнитель".
Если PooH говорит "виноват программист", то тут ответ однозначный - виноват исполнитель.
Alf, ты говоришь "виноват системный архитектор". На чьей он стороне? Фирмы исполнителя или фирмы заказчика? В варианте "ведущий программист-рядовой программист" системный архитектор вообще выступает третьей стороной...

[Alf]

Alf, ты говоришь "виноват системный архитектор". На чьей он стороне? Фирмы исполнителя или фирмы заказчика?

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

В варианте "ведущий программист-рядовой программист" системный архитектор вообще выступает третьей стороной...

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

[Dimka]

По-моему, программист. Ибо то, что "дадено" в условии, то же надо проверять. Точнее, то что система не работает в третьем режиме - ошибка спецификации. А вот определить, как реагирует на этот режим система - полностью задача программиста.

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

По поводу проверок входных данных. В пятницу как раз обсуждали у себя этот вопрос, выбрав в качестве объекта рассмотрения бизнес-процесс.

Бизнес-процесс представляет собой систему, состояния которой необратимо изменяются по какому-то алгоритму. Для выполнения шагов бизнес-процесса обычно требуется запрашивать данные, хранящиеся в БД. Однако на каждом шаге бизнес-процесса требования к этим данным (можно сказать, предусловия) специфичны. Возьмём какой-нибудь сложный идентификатор-код, где в особом формате хранится некоторая информация. Для одного шага бизнес-процесса этот код нужен лишь как строка для вывода пользователю, для другого шага уже требуется расшифровка кода. Соответственно, требования к корректности идентификатора-кода у этих шагов разные.

Возьмём ситуацию изменяющихся со временем бизнес-процессов (и требований к ним, соответственно). Многочисленные и периодически возникающие доработки по модулям постоянно изменяют предусловия и постусловия выполняемых в модулях алгоритмов. В конце концов отслеживание корректности данных, циркулирующих между модулями, становится задачей практически нереальной - никто не в состоянии упомнить, что где изменялось. Более того, возможность работы со старыми данными при помощи нового кода не всегда возможна - требуется поддержка всех версий системы за всю историю её жизненного цикла, либо ограниченное время жизни данных.

Решений здесь несколько (и они не являются альтернативными, скорее, дополняющими друг друга).

1) Автономность данных разных модулей друг от друга. Автономность в том числе и на уровне БД. Каждый модуль "владеет" своей БД или куском БД, доступ к которому никто кроме него не имеет. (Можно это назвать инкапсуляцией.) При этом, повышая устойчивость системы, резко увеличиваем избыточность данных, но это источник ошибок целостности данных системы. В случае сбоя в одном из модулей система в общем сохраняет работоспособность, однако на входе сбойного шага бизнес-процесса накапливаются очереди.

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

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

4) Контроль версий. Данные должны быть помечены версией системы, в которой они должны быть обработаны. Каждый модуль, ориентируясь на версию, выполняет те действия, которые требуются для поступивших к нему данных. Это усложняет код, однако увеличивает стабильность системы при работе с разнообразными историческими данными.

Эти подходы прямо относятся как к разработке спецификаций, так и к тестированию. Естественно, всё перечисленное лежит в сфере ответственности архитектора проекта, а не программиста. Например, если программист по своему мнению, ни с кем не согласованному, оснастит модуль высокопроизводительной системы разнообразными проверками - этот модуль грозит стать узким местом всей системы. Если программист по своему мнению решит, что некорректные входные данные - это не проблемы его модуля, пусть всё валится, такое поведение системы может стать для кого-то неожиданным.

[PooH]

хочу не много пояснить свои слова, чтобы не возникло недопонимания:

По-моему, программист. Ибо то, что "дадено" в условии, то же надо проверять.

Под "программистом" понимается исполнитель (фирма, отдел и т.д.).
Под "то же надо проверять" понимается любой способ проверки (важен факт присутствия проверки).

[Hooter]

Традиционно системный архитектор входит в команду разработчиков, и не просто входит, а играет в ней ведущую роль.

То есть все-таки виноват исполнитель?

Ладно, ближе к делу. Два из тезисов темы: "от кого и в каком виде мы получаем задания на разработку программ; что нас в этом не устраивает и мешает работать;".

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

Мы тут высказывались по поводу того, что заказчик порой сам не знает чего хочет. Он и не может знать всего, что требует исполнитель! Он может сформулировать только какие-то общие требования, но не более того. Хотя бы из-за того, что у заказчика ограниченные познания в технологиях и подробностях реализации. Поставьте себя на его место: заказчик общими словами говорит, что он хочет  и при этом надеется что "это" будет работать стабильно. Заказчик физически не в состоянии написать такое ТЗ, которое будет охватывать все мелочи.

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

В примере: опытный системный архитектор не всегда есть под рукой, а если и есть, то дорого стоит и не всем по карману. Поэтому частенько архитектура рождается в обсуждениях, а не в результате кропотливой работы одного человека. Но это не так важно. Важно то, что у фирмы исполнителя не было ориентировки на общение с заказчиком. Мысли рядового программиста "а чо, я ж по спецификации делал... и пошли все нафик" скорее всего отражают политику всей фирмы. "Мы делаем по спецификации, а там хоть трава не расти." Это неправильно.

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

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

"Что нас не устраивает и мешает работать"? Пассивность. И если в случае заказчика - это оправдано, то в случае исполнителя - преступление.

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

Идеальных спецификаций не бывает. Приблизится к ним поможет только отсутствие пассивности со стороны исполнителя и взаимодействие с заказчиком.

Добавлено через 6 минут и 39 секунд:
Наверное, нужно преносить обратно в тему тестирования

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

Позвольте, а что же делать его модулю с некорректными входными данными?

Например, если программист по своему мнению, ни с кем не согласованному, оснастит модуль высокопроизводительной системы разнообразными проверками - этот модуль грозит стать узким местом всей системы.

Узкое или не узкое место - покажут тесты производительности. А вот о системах, в которых производительность ценится выше отказоустойчивости, я как-то мало слышал.

[Dimka]

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

Э, нет. Если программист что-то написал, он потратил оплачиваемое рабочее время на то, о чём его не просили. Поэтому сперва нужно выяснить, а потом уже делать. Это может сильно тормозить процесс. Но в этом случае полезно иметь соглашение "по умолчанию" со всеми заинтересованными сторонами. Что ради сохранения темпов работы в неоговоренных слуачаях программист будет использовать такой-то метод их обработки.

[Dimka]

Позвольте, а что же делать его модулю с некорректными входными данными?

Alf же отвечал уже - это зависит от контекста системы - принятой стратегии обработки. За стратегию отвечает архитектор. Если что-то непонятно - спросить архитектора.

А вот о системах, в которых производительность ценится выше отказоустойчивости, я как-то мало слышал.

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

[Hooter]

Решение ситуации в примере могло быть следующим: программист (сам или при тестировании) увидел, что не все условия обрабатываются. Проявил инициативу

Э, нет. Если программист что-то написал, он потратил оплачиваемое рабочее время на то, о чём его не просили. Поэтому сперва нужно выяснить, а потом уже делать. Это может сильно тормозить процесс. Но в этом случае полезно иметь соглашение "по умолчанию" со всеми заинтересованными сторонами. Что ради сохранения темпов работы в неоговоренных слуачаях программист будет использовать такой-то метод их обработки.

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

С точки зрения управляющего финансами в фирме исполнителя: лучше заплатить разаработчику за лишный час работы, чем потом терпеть убытки куда бОльшие, когда выяснится, что виноват свой же системный архитектор.

[PooH]

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

и

Опытный системный архитектор не всегда есть под рукой, а если и есть, то дорого стоит и не всем по карману.

Поэтому и существуют конторы, которые на этом зарабатывают. Они как раз и осуществляют действия:

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

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

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

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

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

[Dimka]

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

[PooH]

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

[Hooter]

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

Согласен, но, возможно, это отклонение от изначальной темы.

[Hooter]

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

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

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

[Dimka]

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

Зато, скажем, в парадигме ООП есть такое замечательное средство, как разделение абстракций и специализаций. И его можно (и нужно) активно использовать при составлении ТЗ и спецификаций.

Это означает, что все ситуации обобщаются в классы, и классы выстраиваются в иерархию. Классы ситуаций, находящиеся на самом верху иерархии, описывают самые общие случаи и хорошо известны, так как встречаются во всех или в большинстве проектов. Ниже по иерархии следуют ситуации более специфические для проекта. Для каждой конкретной ситуации определяется её класс. Для каждого класса ситуации определяется стратегия поведения исполнителя и заказчика: приостановить работу и запросить заказчика; реагировать на ситуацию согласно заранее согласованному плану; обрабатывать по усмотрению исполнителя; обрабатывать согласно оговоренному умолчанию, запросив подтверждение заказчика и т.д.

Поэтому всегда есть возможность предусмотреть те или иные проектные ситуации, вопрос лишь в детальности описания того, что предусмотрено.

И вообще, эта тема тесно связана с темой управления рисками проекта. Тоже можно вынести в отдельную.

[Alf]

То есть все-таки виноват исполнитель?

Без вариантов - да.

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

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

Мы тут высказывались по поводу того, что заказчик порой сам не знает чего хочет. Он и не может знать всего, что требует исполнитель! Он может сформулировать только какие-то общие требования, но не более того.

Возможно, мне везло с заказчиками. Ни разу не встречал среди них невменяемого человека, готового платить свои деньги неизвестно за что. Он может не уметь программировать (иначе не заказывал бы, а сделал своими силами), но уж определить, решили его задачу или водят за нос, способен всегда.

...заказчик общими словами говорит, что он хочет  и при этом надеется что "это" будет работать стабильно. Заказчик физически не в состоянии написать такое ТЗ, которое будет охватывать все мелочи.

Ни один умственно полноценный заказчик не скажет мне при составлении ТЗ: "Да, кстати, ты ж не забудь там в функции foo() выкинуть исключение BadModeException, если режим не равен 1 или 2", а если попытается, я вежливо, но твердо попытаюсь убедить его, что это мои и только мои проблемы. Заказчик лишь рассчитывает получить устойчиво работающий продукт.

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

Например, если я приобретаю комплект тормозных колодок, я вряд ли буду спрашивать продавца, а будет ли машина тормозить при движении задним ходом или при повороте направо. Она должна тормозить при нажатии на соответствующую педаль. Точка.

В примере: опытный системный архитектор не всегда есть под рукой, а если и есть, то дорого стоит и не всем по карману.

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

Мысли рядового программиста "а чо, я ж по спецификации делал... и пошли все нафик" скорее всего отражают политику всей фирмы. "Мы делаем по спецификации, а там хоть трава не расти." Это неправильно.

Приведенный фрагмент кода блестяще проиллюстрировал именно такой пофигистический подход.

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

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

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

Идеальных спецификаций не бывает. Приблизится к ним поможет только отсутствие пассивности со стороны исполнителя и взаимодействие с заказчиком.

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

[Alf]

Всегда можно предусмотреть непредусмотренные ситуации...

Замечательные слова, жизнеутверждающие. А также объять необъятное, познать непознаваемое, смочь невозможное...

[Hooter]

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

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

[PooH]

ну думаю в самом общем случае:
1. Описание входных данных
2. Описание биснес-логики
3. Описание выходных данных (в том числе исключительные ситуации (те самые непредусмотренные ситуации))

PS: Под "описанием" понимается текст (в документе) который относится к пункту.

Добавлено через 5 минут и 40 секунд:

Всегда можно предусмотреть непредусмотренные ситуации...

Замечательные слова, жизнеутверждающие. А также объять необъятное, познать непознаваемое, смочь невозможное...

А так обычно и получается...


А по теме, можно просто обговорить: "при возникновении вопросов у исполнителя звонить по телефону ххх в любое время суток. ответ на вопрос должен быть получен в течении 1 часа.". А лучше, сначала полностью спланировать систему, а уж потом браться за реализацию, на этапе планирования пропадет, точно более половины вопросов, которые не были отражены в спецификации.

И хочу отдельно отметить, что ТЗ составляет не заказчик.

[Alf]

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

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

Я лишь против стихийной инициативы. Что толку выбрасывать исключение, которое никто не намерен обрабатывать? Программа все раавно слетит, только с другой диагностикой. Получится "хотели как лучше, а получилось как всегда"... В рассмотренном случае несложный рефакторинг с заменой условных операторов полиморфизмом существенно улучшил бы проект, но затронул при этом его архитектуру (пусть и в лучшую сторону), поэтому партизанские действия тут недопустимы.

[PooH]

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

минимальные требования: отобразить на экране надпись "Hello, world!" (или, вообще, круто - калькулятор)

есть желающие выступить в роли заказчика и исполнителя... описать процесс создания данного проекта?