ПО должно поддерживать реальную жизнь.

Отличный лозунг, девиз, фраза, Максим.

Но не кажется ли Вам, что это, вообще, идеал, который пока не достижим?
Что значит поддерживать реальную жизнь? Это означает, что ПО должно по сути быть настолько гибким, насколько гибка и органична жизнь. Что противоречит самой концепции алгоритмов.

Как обеспечить гибкость? Пример:
есть система работы по кадровому учету.
Работа с кадровыми приказами и работа по штатному расписанию разделена по разным отделам.

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

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

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

Как мы видим, предусмотреть все возможные ситуации вряд ли возможно, а следовательно, обеспечить гибкость, соответствующую реальной жизни нереально
Гибкость будет достигаться конкретными решениями в конкретный момент и обеспечиваться ЧЕЛОВЕКОМ

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

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

ну а ЧЕЛОВЕКА нужно просто учить, чтобы он был предусмотрительным, предвидел и учитывал "всевозможные ситуации"
и конкретные проектные решения, которые он принимает в конкретный момент, были гибкими.

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

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

Насколько я понял из описания примера, в процессе эксплуатации готовой системы возникла проблема, и требуется доработка с целью ее устранения в рамках сопровождения. Это одна часть истории (второй, третий и четвертый извечные вопросы - Что делать?, Кто заплатит за банкет? и Где взять деньги? .
Но при этом хочется выяснить, отчего возникла проблема в первоначальной версии  (первый и самый главный вопрос Кто виноват?
IMHO это именно недоанализ: потребность Необходимо предоставить сотруднику штатного расписания права на ввод и редактирование надбавок не была выявлена. Это была задача Аналитика при выволнении работ по Анализу  требований - ее обнаружить, зафиксировать в том или ином виде в ТЗ (Спецификации требований) и согласовать с Заказчиком (здесь непринципиально, если если Заказчик сам проводил Анализ требований составлял ТЗ - тогда он и есть Аналитик). А недопроектирование -уже следствие.
Ну а ВИ здесь только один из возможный инструментов - упомянуть стоит хотя бы только потому, что тема про ВИ, а то будет совсем уж голимый офтопик . Если бы работа Настройка надбавок была бы выделена в виде ВИ с ДЛ Сотрудник штатного расписания, было бы очевидно, что для последнего нужны права к доступу при раздаче прав по ролям - этого было бы достаточно.
Модель ВИ рисует Аналитик  на стадии Анализа требования.
Проектироващик конечно тоже может конечнопорисовать (даже если Аналитик такую модель не делал), но это уже будет модель сценариев реализации (ВИ со стереотипом Use-Case Realization) и расписать для них ход процесса, нарисовыать диаграммы последовательностей и взаимодействия и т.д. Говорить о длительности наверное лучше применительно к последнему виду ВИ.

О! новая тема. это гуд.

правда я бы предложил назвать ее "насколько ПО должно быть близко к реальности" :о))) а то скатимся на ошибки и работу с ними (хотя это тоже важная и интересная тема). Т.е. нужно ли и до какой степени ПО должно приближаться к жизни - как-то так...

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

Однако дискуссия разгорелась и мне стало очень интересно

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

на само деле совсем не так

Но при этом хочется выяснить, отчего возникла проблема в первоначальной версии  (первый и самый главный вопрос Кто виноват?

Архитектура и три Д как обычно

IMHO это именно недоанализ: потребность Необходимо предоставить сотруднику штатного расписания права на ввод и редактирование надбавок не была выявлена.

Реально была. И была точно и четко поставлена изначально.

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

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

А недопроектирование -уже следствие.

Скорее причина. Реализация кадровых задач была ранее сделана, а по надбавкам уже доделка.

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

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

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

О! новая тема. это гуд.

правда я бы предложил назвать ее "насколько ПО должно быть близко к реальности" :о))) а то скатимся на ошибки и работу с ними (хотя это тоже важная и интересная тема). Т.е. нужно ли и до какой степени ПО должно приближаться к жизни - как-то так...

Поменял

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

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

Релиазция вообще довольно интересная.

Перечень надбавок внедренный объект класса справочник сотрудников. И казалось бы можно определить права именно на него. Но не так просто:
1. связь с внедреным объектом достигается через запись в атрибут объекта сотрудник - нужно право на запись
2. сам внедренный объект - есть нечто типа табличная часть, ссылающаяся на справочник сотрудников - и тут проблем разграничения вроде не видно

Почему избрана именно такая реализация - ну мне неизвестно, я просто заказчик

Уважаемый

.

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

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

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

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

.... Многое зависит от тщательного и продуманного анализа. Но ... возможно ли учесть все нюансы?

Однозначно можно ответить - все ньюансы в аналитической модели учесть невозможно, потому что:
а) Любая модель по определению является упрощением, учитывая только существенные свойства моделируемого объекта, абстрагируясь от несущественных.
б) Бизнес-процессы имеют свойства изменяться во времени, любая модель устаревает
в) Модель отражает только типовые процессы, а в реальной жизни всегда возникают случайные отклонения от типичной схемы, которые заранее учесть невозможно
г) Любая модель субъективна, взгляды и понимание у всех разное + всем людям, включая аналитиков, свойственно просто ошибаться
и т. д.

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

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

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

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

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

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

Разумеется - это нормальное явление. К тому же мы обсуждаем здесь только один блок и одну проблему,  может быть в целом система вполне замечательная:)

на самом деле совсем не так

Ооопс...Кажется я по невнимательности не вполне верно понял ситуацию из примера, отсуда поспешные выводы. Хотя было ясно написано "готовая".
Т.е, заказчик решил приобрести некую не для него разработанную систему, и в процессе внедрения вылезла описанная проблема?
Или не совсем так?

Архитектура и три Д как обычно

На момент приобретения и внедрения - узкое место - конечно именно реализация архитектуры.
Но исторически - возможно имел место (а возможно и нет) недоанализ требований к первоначальной версии модуля управления доступом у  разработчика.
А кто такие три Д? Я знаю только правило ДДД - дай дураку дорогу, но это автомобильное:)

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

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

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

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

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

Возможно