436

Системный Анализ и Требования / Re: Модель штатного расписания

« : 18 Февраля 2010, 15:54:13 »

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

по обоим пунктам - это же хорошо!

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

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

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

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

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

437

Системный Анализ и Требования / Re: Модель штатного расписания

« : 18 Февраля 2010, 12:42:26 »

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

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

:о))

438

Системный Анализ и Требования / Re: Модель штатного расписания

« : 17 Февраля 2010, 18:07:10 »

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

439

Системный Анализ и Требования / Re: Модель штатного расписания

« : 17 Февраля 2010, 18:05:09 »

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

как говорится, "чую, но обосновать не могу".

440

Системный Анализ и Требования / Re: Модель штатного расписания

« : 17 Февраля 2010, 14:48:26 »

я-таки не понимаю, в чем проблема?

441

Системный Анализ и Требования / Re: Модель штатного расписания

« : 17 Февраля 2010, 14:07:23 »

ШР - не отчет, а динамическая структура (дерево ну или список, если так проще). можно плодить версии этого дерева, можно распечатывать отчет = результат обхода в определенном (желательно всегда одном, хотя необязательно) порядке

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

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

расчеты месячного ФОТ с любыми вариантами - суть те самые отчеты

442

Системный Анализ и Требования / Re: Модель штатного расписания

« : 17 Февраля 2010, 13:08:21 »

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

насчет технических особенностей существующих продуктов они вряд ли помогут. IMHO в любом случае нужно иметь бизнес-описание того, что должно получиться (в новом варианте) и как потом с этим будут работать сотрудники. при составлении этого (с позволения сказать) описания бизнес-процесса на мой взгляд нужно абстрагироваться от текущих функциональных возможностей имеющегося продукта и в некотором смысле от возможностей его адаптации.
Далее, имея описание бизнес-уровня "переводим" его в описание технического уровня, те же диаграммы сущность-связь и т.п. По возможности это тоже следует изолировать от внутренностей продукта, хотя полностью этого сделать не удастся (да-да, как ни напрягай аналитиков).
А потом тупо (или нетупо) делается мэппинг того что надо, на то что есть. Тем самым формируется проект (как угодно можно называть эскизный или технический) того, что должно быть сделано, чтобы переделать то, что есть в то, что надо (по-нашему, по-бразильски: путь из AS IS в TO BE).
Далее, приоритизация отдельно взятых задач по переделке в целях, например, быстрее выдать в законченном варианте какой-то значимый кусок (= бизнес-процесс). В ходе работы контролировать ситуацию, отклонения, внешние воздействия - в общем всё как обычно, чтобы "довести свой поезд в целости и сохранности до конечной станции".
Обращу внимание на правильную расстановку приоритетов. Это очень важно. Т.к. сейчас существуют определенные проблемы (бизнес-уровня), которые одним махом не решить. Все ваши потребители это в целом понимают, но каждый по-своему. Так вот, нужно выбрать и последовательно реализовать цепочку так называемых квиквинов (quick wins - промежуточных результатов), уверенное и последовательное появление которых будет подтверждать правильность выбранного пути и делом доказывать реализуемость "этого призрачного проекта".
Ну и менеджер проекта нужен хороший, в идеале еще и архитектор не помешал бы.

или что-то другое нужно? типа, диаграмму поправить? IMHO проблема не в диаграмме, а как раз в подходе.

443

Системный Анализ и Требования / Re: Модель штатного расписания

« : 17 Февраля 2010, 12:02:18 »

так что модель за ваших аналитиков нарисовать? а где гарантия, что условия задачи сформулированы ими правильно?
IMHO проще взять давно существующий на рынке продукт. Вопрос, что подойдет для вашего вуза?

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

444

Системный Анализ и Требования / Re: Модель штатного расписания

« : 16 Февраля 2010, 23:18:50 »

Например нам не удалось найти внятных нормативных документов

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

445

Обучение / Re: Обучение процессу разработки

« : 29 Декабря 2009, 00:26:43 »

на самом деле с точки зрения преподавателя всё более-менее успешно, и вопрос даже в том, сколько человек пошло на экзамен, а сколько получили экзамен автоматом :о))

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

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

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

446

Обучение / Re: Обучение процессу разработки

« : 28 Декабря 2009, 19:28:06 »

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

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

447

Обучение / Re: Обучение процессу разработки

« : 28 Декабря 2009, 16:31:43 »

Я бы охарактеризовал ситуацию, как у Райкина: "к пуговицам претензии есть - нет, не оторвать" :о))

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

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

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

448

Книги, статьи и ресурсы / Re: BABOK. Народ, нас дурачат :)

« : 25 Декабря 2009, 14:27:48 »

Думаю, что еще много чего можно взять, чтобы найти что-то соответвующее чему-то еще :о))

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

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

449

Методологии / Re: Cobit

« : 25 Декабря 2009, 10:48:57 »

Я хотел спросить:Имеете какой-либо опыт работы с Cobit?

имею. длительный. продолжаю регулярно использовать.

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

450

Примеры / Re: Uml-модель экономической системы общества.

« : 24 Ноября 2009, 10:22:36 »

2 Michaj:
Мне Ваша схема действительно понравилась, так что ваше художественное в/о как минимум не пошло прахом. Однако Ваше превознесение учетного подхода несколько необоснованно.
Больше всего меня "радует" очередная попытка делать заключение о "любви/нелюбви" других людей к чему бы то ни было. Это обычная религиозная догма: раз я ..., то и все должны. Так что Вы тут неправы, каждый инструмент хорош по своему назначению, но это я уже повторяюсь.
В завершение (надеюсь, мы к этому больше не вернемся по крайней мере в рамках исходной темы) повторю чьи-то слова о том, что бухгалтерия основана на регистрации фактов свершившейся (!) хозяйственной деятельности с использованием регламентированных (ПБУ, помним?) регистров, и это сродни управлению автомобилем с помощью зеркала заднего вида. Так было и в Италии в период зарождения двойной записи (действительно замечательное изобретение, проверенное временем), так есть и сейчас везде - во всем мире, в том числе и у нас. Тем не менее, Вы ведь сами указываете на отсутствие фантазии у носителей этой технологии. Как же, используя эти методы и данные, предсказывать и планировать будущее? Подтверждения у меня нет, но не сомневаюсь, что не одна компания, исповедующая подобный (бухгалтерский) подход к управлению, потерпела фиаско и исчезла с рынка.

Заодно хотелось бы понять, как с помощью бухгалтерской методы можно было бы показать перспективы развития того или иного предприятия. Уверяю Вас (и практика показывает), что подобные решения в большинстве своем иррациональны, взять тот же АвтоВАЗ, который следовало бы закрыть еще лет 15 назад, может быть потерь было бы меньше. Кстати, он не единственный пример в автомобильной отрасли, есть и положительные примеры, в том числе и последних лет: Рено, Опель.

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

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

P.S. а вообще действительно, может я прикалываюсь :о))