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

Так вот что на самом деле хотел Заказчик.

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

Возможно, я как заказчик (и преподаватель) строг?

1. Если требования были согласованы ранее - нет.
2. Если детальные требования не были согласованы ("проработаны" - не в счет), но бизнес-требование было озвучено именно в таком виде, как здесь процитировано - тоже нет.
3. Если других аргументов, помимо приведенных, у Разработчика нет, он должным образом мотивируется и враскорячку отправляется переделывать прототип.

Да, это одна из целей создания системы

Если это одна из целей, и она от Разработчика не скрывалась, значит Разработчик облажался.

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

Мы играем в отношения между Заказчиком и Разработчиком, или студентами и преподавателем в учебном процессе? Я намеренно утрирую ситуацию под первый случай.

Именно к этому я и призываю сторону разработки. Согласовывать со мной свои решения.

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

Почитайте Вигерса https://drive.google.com/folderview?id=0B-lK9AAeV_5cenFMMnd6Y2l5b0k&usp=sharing

Много его там. С Вашего позволения, я ограничусь материалами этой темы. Тем более, что непонимание, в целом, устранено.

Элла, как теперь изменится твое мнение? И главное почему?

А ты видел эту реализацию? Скорее всего подрядчик начал делать, ему показалось что это не так сложно, но в ходе реализации "прочувсвовал" требования и решил не продолжать. Мнение не поменялось.
Здесь не проработаны бизнес требования. Для чего нужен предопределенный адрес:
1. повышение лояльности клиента. А Клиент кто? Молодой пользователь инета - тогда проще вводить текстом. Пользователь - мазохист, желающий искать из списка адресов? Тогда надо готовить список.
2. отчетность. Какая отчетность конкретно, что она может дать? Нужно ли знать что с 3 этажа активнее заказываеют диетический обед?
3. корректный адрес, по которому безошибочно можно доставить обед. Может эффективнее  что бы диспетчер  перезванивал и уточнял меню и адрес. Так по крайней мере, Клиент будет оповещен что заказ принят.
Ну, а если Заказчик все таки настаивает о предопределенном адресе, то описать реализуемый функционал и оценить трудозатраты по реализации и его сопровождении.
Слова "пшик" , "дорого" для этого не подходят.

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

Спасибо за мнение.

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

Элла, по-моему ты слышишь только себя. Еще раз. Задача учебная. Некоторое описание к ней я дал. Вот Леонид мои пояснения принял.

2. отчетность. Какая отчетность конкретно, что она может дать? Нужно ли знать что с 3 этажа активнее заказываеют диетический обед?

Одна из целей проекта - 75% сотрудников компании активно пользуются услугами COS.
Другая задача - обеспечить более качественно и разнообразное питание. Точно знание адресатов отлично помогает встраивать статистику и управлять ассортиментом и качеством блюд с учетом адресности их заказов.

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

Мы в другой реальности.

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

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

Так вот что на самом деле хотел Заказчик.

1. Если требования были согласованы ранее - нет.
2. Если детальные требования не были согласованы ("проработаны" - не в счет), но бизнес-требование было озвучено именно в таком виде, как здесь процитировано - тоже нет.
3. Если других аргументов, помимо приведенных, у Разработчика нет, он должным образом мотивируется и враскорячку отправляется переделывать прототип.

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

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

Что происходило внутри команды разработчика, как происходил обмен уточненными требованиями мне неизвестно. Я мог как заказчик и преподаватель следить за некоторыми результатами, которые отражались в виде задач в redmine, появление описаний на wiki, коммитов в Visual Paradigm проекте, коммитов на гитхабе kohana-проекте. Уследить за всеми деталями сложно, да и не было такой задачи. Нужно же дать людям делать их собственные ошибки самостоятельно.

Однако за итерацию отсюда - т.е. на прошлой неделе, ко мне обратился тестировщик. У него упал его автоматизированный тест проверки создания учетной записи нового клиента. Он подготовил данные, в которых номер офиса был не числом, но строкой типа Д103.
Оказалось, что тип для офис - int. Он обратился к описаниям ВИ и не нашел указание на целый тип данных. Обратился за разъяснением ко мне - заказчику. В результате программист в дискуссии на форуме великодушно согласился сменить int на string - мол это ничего не стоит.

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

Эд, ну извиняй что не принимаю твоего пояснения. Учебная или неучебная задача, но надо стремиться к реальности, иначе чему научишься?
А по поводу всего 3 списков. Тут как смотреть то. Если с твоей позиции учебной программы, то наверно все просто, а если реальной разработкой, то не совсем просто:
-списки  надо кому то администрировать-значит надо интерфейс писать;
-контроль адреса при вводе, а иначе зачем все это заварили.  Вдруг на 3 этаже совсем не будет первого кабинета. Т.е. надо реализовать хранения матрицы взаимосвязей ну и т.д.
Ну если считать что 2 здания и пару этажей, то можно вообще не на чем не заморачиваться )

Спасибо за ответ.

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

Ну так это же интересно, как реагировать на изменяющиеся требования, а ведь в жизни они меняются

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

Не совсем так. Хотя может быть. Более того я готов на компромисс, если он обоснован

Эд, ну извиняй что не принимаю твоего пояснения. Учебная или неучебная задача, но надо стремиться к реальности, иначе чему научишься?
А по поводу всего 3 списков. Тут как смотреть то. Если с твоей позиции учебной программы, то наверно все просто, а если реальной разработкой, то не совсем просто:
-списки  надо кому то администрировать-значит надо интерфейс писать;
-контроль адреса при вводе, а иначе зачем все это заварили.  Вдруг на 3 этаже совсем не будет первого кабинета. Т.е. надо реализовать хранения матрицы взаимосвязей ну и т.д.
Ну если считать что 2 здания и пару этажей, то можно вообще не на чем не заморачиваться )

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

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

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

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

Тут вот какой интересный возник нюанс.
Первый аналитик разрабатывал требования по управлению пользователями...
Второй аналитик - разрабатывающий вариант использование...

Ситуация "К пуговицам претензии есть"?

Однако за итерацию отсюда - т.е. на прошлой неделе... Оказалось, что тип для офис - int... [тестировщик] Обратился за разъяснением ко мне - заказчику. В результате программист в дискуссии на форуме великодушно согласился сменить int на string - мол это ничего не стоит.

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

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

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

Вообще здОрово у вас все организовано. Реально здОрово. Можно многому научиться.

На мой взгляд - просто караул. Зоопарк средств информационной поддержки, которыми неподготовленный человек воспользоваться не в состоянии (а потому сам Заказчик признается, что не знает, что там происходит). Нет человекочитаемых документов, из которых можно получить представление о том, что, когда и зачем делается. С Заказчиком контактирует кто попало, вне зависимости от компетенций и погруженности в тему. Исполнители  в цепочке еще подумают, проявить ли великодушие и сделать как требуется, или сказать "а все равно пользы от этого пшик". Работу аналитиков никто не координирует, в результате чего пуговицы пришиты крепко, а костюм "в целом" не удовлетворяет Заказчика.
"ЗИС ИЗ... ЭДЖАААЙЛ!"

Ну или я такой мамонт.

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

Вообще здОрово у вас все организовано. Реально здОрово. Можно многому научиться.

Спасибо, Золотая рыбка:)

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

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

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

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

Нет человекочитаемых документов, из которых можно получить представление о том, что, когда и зачем делается. С Заказчиком контактирует кто попало, вне зависимости от компетенций и погруженности в тему. Исполнители  в цепочке еще подумают, проявить ли великодушие и сделать как требуется, или сказать "а все равно пользы от этого пшик". Работу аналитиков никто не координирует, в результате чего пуговицы пришиты крепко, а костюм "в целом" не удовлетворяет Заказчика.
"ЗИС ИЗ... ЭДЖАААЙЛ!"

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

Ну или я такой мамонт.

Может папонт

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

Роль есть, а наладить процесс естественно не просто. Как бы ты его наладила в течение полутора месяцев, не имея  опыта и выполняя проект раз в неделю. Проект УЧЕБНЫЙ.

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

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

Первым делом разработчику нужно понимать, что это поведение - синдром, т.е. болячка. И не следовать ему, а придерживаться некоторой процедуры. Какой именно - зависит от организации конкретной команды. Где-то нужно обратиться к руководителю, где-то - к product owner'у, где-то к аналитикам. В любом случае, разработчику нужно принимать во внимание, что а) если есть требование и проект - над ним работали его коллеги, умные люди, и если он выглядит странно - возможно, к этому есть причины; и б) если у разработчика есть соображения, как улучшить проект или, в пределе, улучшить свойства системы (в т.ч. стоимость, как производную от сложности реализации) за счет отказа от каких-либо требований - он должен вынести эти идеи на тех, кто ранее предложил ему первую версию. А не партизанить, конечно, по тихому "

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

Поступки, которые выражаются в виде конкретных артефактов - разумеется, знаю. Артефакты в тех процессах, которыми занимаюсь я, являются цельными и человекочитаемыми. Т.е. это постановки, спеки и целый выводок ГОСТовой документации.
Еще и в процессе их подготовки аналитиками активно участвую.

А почему вы так решили?

Потому, что задал этот вопрос, и ответа на него не последовало.

Документы есть, есть методология их составления, есть учебная мотивация и стимуляция это делать.

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

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

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

Может папонт

(проверил) Да, совершенно верно.