Ну вот я и добрался до дома :) Бум отвечать по порядку.
aag
Ведение истории есть. По ФИО не ведется, так как в самой постановке задаче это не востребованно. В тех же частях, от которых зависят расчеты и отчетная часть история обязательная часть проекта (например история изменения тарифной сетки, подоходнего налога, налоговых вычетов, учета табельного времени, наименования и значения кодов дохода и т.д.). Там, где данные могут изменяться задним числом история ведется с учетом изменения задним числом. Как ни странно, но по постановке фактически в 80% случаев требуется история изменения информации, из них 50% с учетом изменения задним числом. Причем в некоторых случаях даже смешно получается - например как оказалось дата увольнения задним числом сотрудника очень даже часто встречающаяся вещь в мире расчетчиков зп. Проект я бы не сказал, что сильно усложнен, так как на ведение истории на любую часть данных и особенно задним числом, я очень тщательно взвешивал все за и против, консультируясь с постановщиками, сопровожденцами и клиентами и анализируя все случаи уникальных отклонений от постановки. То есть грубо говоря при проектировке я старался задействовать только общие случаи, чтобы реализовать частный случай какого то усложнения в системе народу приходилось очень долго мне обьяснять и доказывать, что он востребован. Далее с учетом архитектуры БД если отклонение было единичным случаем в практике сопровождения старого проекта заработной платы и при желании его всегда можно было дописать в систему, не изменяя архитектуры, я фиксировал у себя как возможно не решенную проблему дополнительного характера и пропускал ее реализацию. Иначе проблема приравнивалась к блоку основного функционала, проектировалась и реализовывалась в архитектуре БД. Для поддержки в системе данных с историей существует 2 типа вьюверов - возвращающие информацию на текущий расчетный месяц и возвращающие информацию на указанный расчетный месяц (в MSSQL эту функцию выполняли UDF, в ASA UDF не могут возвращать набор данных, зато есть поддержка глобальных переменных и вьюверы могут на них ссылаться. Я их для удобства называю параметризированными вьюверами).
Пример вьювера, возвращающего последние значения тарифных ставок (последние, потому что в течение месяца ставка может поменяться и плюс ставка может измениться задним числом) , действующие на текущий расчетный месяц:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
ALTER view v_SalaryValue_Current ()
-- Вернуть текущие значения окладов и тарифов
as
select sv.Salary_id, sv.WorkDate, sv.SalaryValue, sv.TarifValue
from SalaryValue sv
inner join (
-- получаем последние даты действия
select svw.Salary_id, svw.WorkDate, Max(svw.SaveDate) as MaxSaveDate
from SalaryValue svw
inner join (
-- получаем последние даты изменения
select Salary_id, Max(WorkDate) as MaxWorkDate
from SalaryValue
where SaveDate <= @@CalcDate and
WorkDate <= @@CalcDateLast
group by Salary_id
) as svs on svs.Salary_id = svw.Salary_id and
svs.MaxWorkDate = svw.WorkDate
where svw.SaveDate <= @@CalcDate
group by svw.Salary_id, svw.WorkDate
) as svm on svm.Salary_id = sv.Salary_id and
svm.MaxSaveDate = sv.SaveDate and
svm.WorkDate = sv.WorkDate
Такой вьювер стабильно вернет последние значения всех действующих ставок на текущий расчетный месяц, учитывая момент, что они могли быть изменены задним числом. Поле
WorkDate означает начало действия тарифа,
SaveDate месяц его ввода, в кач-ве конца этих дат выступают более старшие по времени даты.
@@CalcDate и
@@CalcDateLast - глобальные переменные, доступные в любой сессии к БД и хранящие первый и последний день текущего расчетного месяца (глобальных переменных в БД много и они автоматически инициализируются сразу при подключении соединения на уровне СУБД. Есть даже переменные флаги признака наличия супервизорских прав или отладочного режима для текущего соединения).
Такие вьювера служат в основном для быстрого доступа к истории с клиентской и отчетной части. В скриптах расчетов они не участвуют, так как информацию требуется во многих расчетных алгоритмах и их постоянный вызов привел бы к накладным расходам. Для расчетов как я уже и писал выше вся входящая информация, к которой доступ из за реализации ее хранения затруднен, осуществляется через кэши.
Вообще можно немножко смело сказать, что на самом деле архитектура БД, с учетом того, что уже исходя из постановки задачи, история ведется почти на все и по многому ведутся перерасчеты задним числом, фактически позволяет проводить расчеты на любой период давности, в не зависимости от изменения законодательства и условий постановки в дальнейшем при сопровождении проекта.
Далее больше пойдет для
Циничный Кот
Меня можно обвинить в усложние постановки, однако изначально задача ориентировалась как тиражный продукт, распостраняемый по многим уголкам страны (есть очень крупные заказчики на Севере, есть в Москве, есть и на Юге). Согласитесь при таких условиях изначально к проекту предьявлялись следующие требования: скорость из за крупности многих заказчиков, многофункциональность из за различной специфики работы во многих отраслях и легкость в сопровождении из за географической удаленности клиентов.
Если бы меня наняли делать калькулятор для расчета зп в мелких конторах с численностью до 500 человек, то я бы просто на такой проект и не согласился по той причине, что написано их предостаточно и ничего интересного в кач-ве опыта проектирования БД я бы для себя не приобрел.
Теперь насчет изменения в законодательстве. Проект планируется написать и начать производить запуск с начала следующего года. Изменения в налоговом законодательстве проект затронут по любому, я и не утверждал кстати нигде что это универсальный проект. Расчетная часть не изменится вообще по той простой причине, что принимается решение снизить ставки соц. налогов для легализации официальной зарплаты, как Вы знаете, а такие вещи у меня вместе с историей храняться в налоговых таблицах и проекту не страшны даже возврат к расчету налогов по "планкам", так как там все это реализовано. Другое дело что по графику работ именно сейчас разрабатываются налоговые ведомости, так как это последний шаг к выпуску бета-версии программы и началу ее пробных запусков на клиентах (планируется в начале осени). Нет никакой гарантии, что отчетность останется преждней из за изменениях в законодательстве и в следующем году не придется переписывать отчеты, а заодно и ХП, которые строят для них данные. Это не смертельно, но сбивает график работ, так как именно в это время планируется создания экспорта данных в существующие бух. системы и конверторов перевода данных с других зарплат (в том числе и старой), что фактически означает выход финальной версии зп и массивному распостранению ее среди клиентов. Далее по идее можно будет начать реализовывать дополнительный функционал системы (северные коэффициенты, премии КТУ, и т.д.). Однако сбитие графика работ может привести к отсрочке запуска проекта на полгода по самой простой причине - началу весны, а значит отчетной поры, в которую клиентов будет бестолку пытаться куда то пересадить. Кстати некоторые отчеты вызывают благовейный ужас, используя в кач-ве информации почти всю расчетную информацию БД в течении года и имея довольно сложную структуру отчета (как раз особенно по соц.налогам). Так что тут мои переживания думаю довольно понятны.
Varivan
Книжек про безнадежные проекты читал не мало и кстати имею опыт в построении сложных систем, даже с недостаточной постановкой или ограничением ресурсами. Всего мной за 12 лет работы было написано 3 крупных проекта, каждый писался порядка 2 лет и прошу заметить они все до сих пор работают без моего личного участия. В той ветке форума я высказал опасения действиями своего руководства, игнорирующими изменения в условиях написания проекта. Проект я не могу считать безнадежным по следующим причинам:
1. Не смотря на нежелание выделить дополнительные ресурсы для форсирования проекта, фирма кровно заинтересована в его написании, так как старый расчет зп написан на ДОСовом Си, работает у кучи клиентов, использует для работы 640 кб (ох и времечко веселое было :) ), уже сложно поддается сопровождению и постоянно висит угроза увольнения программиста, его сопровождающего, так как рано или поздно все это ему надоест.
2. Фирма работает еще в другой отрасли и дела там пошли не самым лучшим образом (потери крупных клиентов), наверное из за излишней самоуверенности руководства, что означает востребованность в конторе достаточного крупного и перспективного проекта в кач-ве тыла.
3. Не смотря не на что мы пережили смену руководства, деньги нам платят исправно, желание писать проект не остыло.
Фактически если дословно привести сообщения с форума Работы я в соотвествующем форуме заметил, что мои работодатели явно странные люди, если видя что их основной на данных момент проект рушиться, вместо того, чтобы форсировать разработку запасного варианта, забирают у меня сотрудника, который отвечал за разработку отчетов и начинают перекидывать все материальные и людские ресурсы на гибнущий проект, периодически все таки выхватывая людей из команды зп на свои нужды. В итоге их проект поглощает все как черная дыра и продолжает исправно тонуть по той простой причине, что писался по той формуле, которой тут многие и советовали - сляпать за полгода основной функционал, запустить и потом дорабатывать. Так все и было - за полгода было сляпано нечто, изначально с не продуманной архитектурой, что потом в течении 4 лет исправно обрастало притыками и заплатками. Теперь условия постановки изменились, плюс я бы сказал был достигнут некий критический предел, когда приткнуть там уже новую функциональность не куда и проект при попытке его переработке просто "рухнул". Я бы на такие проекты вешал табличку - "Не трогай, а то упадет". Сразу вспоминается анекдот про отца-программиста, сына и солнце.
Лично я могу поручится за любую часть проекта, что она спроектирована правильно, с учетом постановки задачи и стоит на золотой середине между фунциональностью и универсальносью. Может с точки бизнеса, как кстати думают многие, в том числе и мое руководства, главное чего то впихнуть клиенту, а потом драть деньги и латать систему, заставляя сопровождающих ее людей совершать героические поступки под крики "Срочно, но я как разработчик проектов стараюсь помнить о том, что после того, как я его напишу и запущу, на нем долго и кропотливо будут работать его сопровождающие программисты и мне не хотелось бы, чтобы они вспоминали меня и мою мать, я же не Билл :)
P.S. Кстати для справки - официально я занимаю должность ведущего разработчика, а не руководителя проекта, в роли которого себя считает начальство, так что обвинять меня как плохого руководителя бестолку - я им не был и не хочу быть. Если мне и приходится предпринимать какие то действия в "политике" предприятия, то они обуславливаются только моим желанием успешно дописать и запустить проект, и фактически осуществляются только благодаря моему "авторитету" на фирме и важностью проекта.
Уф, ей богу - хватит политики. Будем надеятся, что все будет хорошо и проект успешно начнет работать, приносить деньги фирме, уверенность клиентам и легкость в сопровождении программистам. Ну а мне будет достаточно соотвествующей галочки в резюме :)
Завтра постараюсь описать вышеобещанные мною реализации частей проекта, если конечно время позволит. Спасибо за участие и критику тоже (только желательно конструктивную) :)
