2236

Проектирование / Можно ли вообще спроектировать и реализовать систему без архитектуры?

« : 17 Октября 2010, 19:12:25 »

Приглашаю к дискуссии, если она, конечно, интересна

Как Вы считаете: Можно ли вообще спроектировать и реализовать систему без архитектуры?

Предусловия:
1. имеются в виду сложные системы
2. имеются в виду системы, интенсивно использующие ИКТ (информационно-коммуникационные технологии)

Сторонников положительного и отрицательного ответов призываю излагать аргументы

2237

Конференции Семинары и Тренинги / Re: Управление изменениями требований: подготовка к семинару

« : 17 Октября 2010, 18:57:02 »

Если вас волнует тема управления изменениями требований в проектах и вы хотите попасть в МСК на мой бесплатный семинар на эту тему, пройдите пожалуйста опросник.

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

2238

Варианты Использования (Use Case) / Re: Насколько ПО должно быть близко к реальности?

« : 15 Октября 2010, 11:44:51 »

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

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

2239

Варианты Использования (Use Case) / Re: Насколько ПО должно быть близко к реальности?

« : 14 Октября 2010, 22:27:57 »

Уважаемый

.

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

2240

Варианты Использования (Use Case) / Re: Насколько ПО должно быть близко к реальности?

« : 14 Октября 2010, 18:54:07 »

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

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

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

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

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

2241

Варианты Использования (Use Case) / Re: Насколько ПО должно быть близко к реальности?

« : 14 Октября 2010, 18:50:11 »

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

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

Поменял

2242

Варианты Использования (Use Case) / Re: Можно ли достичь нужной гибкости ПО?

« : 14 Октября 2010, 18:49:03 »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2243

Варианты Использования (Use Case) / Насколько ПО должно быть близко к реальности?

« : 14 Октября 2010, 08:45:11 »

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

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

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

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

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

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

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

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

2244

Системный Анализ и Требования / Re: Противоречивость требований

« : 07 Октября 2010, 17:24:59 »

НУ как раз зарплату мне косвенно платит пользователь. Будет он доволен - будут заказы - будет бабло. Моему непосредственно руководству вообще пофиг на спор бухгалтеров заказчика. Ему важно, что проект был успешно реализован.

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

2245

Для всех / Re: нужна помощь по техническому заданию!

« : 06 Октября 2010, 22:57:30 »

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

Каким образом, поясните мне, пользователь должен пользоваться классом? Тоже странная постановка вопроса. Пользователь пользуется не классом. Он взаимодействует с системой через интерфейс, вероятнее всего через GUI. Для этого предназначена рабочая документация - инструкции пользователю, справка и т.п.

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

2246

Sparx / Re: Импорт модели из Visual Paradigm

« : 06 Октября 2010, 14:40:51 »

ИМХО, нужно спрашивать на форуме Спаркса.

ИМХО, нужно спрашивать на форуме Visual Paradigm

2247

Системный Анализ и Требования / Re: Противоречивость требований

« : 06 Октября 2010, 14:39:57 »

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

2248

Консалтинг и Внедрение / Re: Расчет эффективности

« : 06 Октября 2010, 14:37:34 »

Эффективность внедрения на мой взгляд определяется тем, достигнуты ли поставленные задачи и цели. Потому то, очень важно, когда заказчик ставит некую цель, спросить его, что означает для него успешность проекта, т.е. по сути эффективность системы. Как он будет это проверять? Об этом говорил на ЛАФ2010 уважаемый мною Сергей Мартыненко. Правильно говорил.

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

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

2249

Теория моделирования и нотации / Re: Какой тип диаграммы использовать для описания данных из апстрим в мою систему?

« : 04 Октября 2010, 18:49:22 »

Могу ошибаться, но

• тип диаграммы (UML или IDEF) который подходит для такого описания?

IDEF я бы не посоветовал вообще

На диаграмме хотелось бы отразить:

• отдельные системы блоками

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

• способ выделить среди систем мои, апстрим, даунстрим

стереотип, актеры

• интерфейсные части этих систем в виде компонентов блоков

через интерфейсы, через чупа-чупс, через порты на композитных диаграммах

• передачу данных стрелками с некоторой детализацией (описанием что именно передаётся)

через интерфейсы, через классы-сигналы, на диаграммах деятельности или последовательности

• передачу уведомлений стрелками с некоторой детализацией (когда и по какой причине приходит это уведомление)

см. выше

• передачу команд стрелками с некоторой детализацией

см выше

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

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

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

диаграмма размещения наверное

2250

Варианты Использования (Use Case) / Re: Как долго "длится" ВИ?

« : 04 Октября 2010, 18:40:29 »

Я думаю тут следует понять на каком уровне смотреть. Но в любом слкучае Salar прав. Если почитать того же Крэга Лармана, то он говорит:
что ВИ следует выделять
 - это элементарный бизнес-процесс (или задача)
 - это то, что одобрит руководство
 - это нечто достаточно компактное по времени

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