Угу - с высказываниями полностью согласен. Менеджмент и уровень IT-продвинутости начальства в России оставляет желать лучшего. У меня на работе тоже самое твориться - начальство просто отдало мне на откуп проект, я сам набрал людей, сам выбрал инструментарий для разработки и сам же координирую действия разработчиков, трясу постановщиков, работаю с клиентами по постановке и тестированию. Начальство только интересует в этом проекте 3 вещи:
- прога должна быть написанна на современных технологиях (слово SQL почему то очень их радует, и какой сервак СУБД используется им до лампочки, хоть MySQL, главное чтобы в названии было SQL)
- клиентская часть должна быть очень красивой, никаких стандартных интерфейсов и серых формочек (вот мы упарились с этим требованием), чтобы можно было клиентам впаривать
- проект должен писаться быстро (хотя с учетом предыдущего требования это они погорячились, хотя все в мире относительно, в том числе и быстро)

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

3 человека в команде разработчиков, я вроде как руководитель проекта, DBA и ведущий разработчик клиентской части (ядро, компоненты, интерфейсы и т.д.). Второй человек программист клиентской части - рисование форм, бизнес-логики клиента. Третий чел занимается отчетами и различными конверторами - конвертор с существующей версии зп в конторе (кошмар - писана на ДОСовом стареньком MS C), связь с бух-системами для импорта-экспорта. Пара постоянных постановщиков (не повезло им, что со мной в одном офисе сидят) и плюс еще не опознанное кол-во народу, частично знающих постановку (бухгалтерия и внедренцы, задействованные в старом проекте), которые по очереди мной отлавливаются. В кач-ве тестеров используем внедренцев старого проекта и самых патриотичных клиентов.

Система клиент-сервер. В кач-ве сервера изначально был использован MSSQL 2000 из за того, что он уже применялся в конторе в других проектах. Однако в конце концов удалось убедить начальство перевести БД на Sybase ASA 8, мотивируя это его недорогой стоимостью (400$), низким требованиям к аппаратуре (P166 4MB RAM) и скоростью работы, что было подтверждено начальству документально демонстрацией абсолютно 2 одинаковых по структуре и коду баз на MSSQL 2000 и Sybase ASA 8 (благо что они полностью совместимы) и расчетом 1000 сотрудников на тестовой базе со следующим результатом - MSSQL - 20 сек, Sybase ASA - 5 сек. О том, что ASA имеет еще WatcomSQL и кучу фич, значительно облегчающих написание сложной логики в БД начальству было скромно не сказано, все равно бы ничего не поняли.

В качестве клиента был взят Delphi 5 по нескольким причинам - делать его на Java было бы непростительной роскошью в отношении ресурсов, тоже относиться и .NET, правда он в GUI еще настолько плох, что делать на нем было бы непростительной глупостью. Power Builder отпал по 2 причинам - я не нашел бы в Москве так сразу человека, квалификация которого позволила бы на PB лепить сложного клиента (а в зп действительно он сложный), во вторых как я уже упоминал требованием заказчика софта было неординарность интерфейса, т.е. никаких выскакивающих форм или MDI. Я кстати уже пожалел о том, что в свое время все таки не настоял на отмене этого требования, так как на разработку и тестирование собственных компонент для создания такого плоского интерфейса ушло немало полезного времени. Было бы легче взять за основу все таки PB, толкового программера и натаскать на PB. Так же в кач-ве визуальных компонент используется DevExpress Quantum Grid под 5 Delphi, правда значительно мной доработанный и исправленный от ненужного кол-ва глюков.

К качестве отчетного средства используется Crystal Report 8, в зп отчеты встречаются довольно сложные и не хотелось связываться с тем же FastReport, который на них бы стал выдавать глюки и пришлось бы тратить время на его дописку.

Сами алгоритмы расчетов зп полностью хранятся в БД, причем довольно хитро - описания и взаимосвязи расчетных обьектов и их алгоритмов хранятся в таблицах, для работы с их структурой существует собственный Developer, скрипты расчетов в ХП. Движок расчетов получился более менее универсальный - расчет ведется по описаниям и зависимостям обьектов, изначально поддерживается сторнирование данных, с учетом того, что все расчеты разбиты по ХП имеется возможность хранить всю историю изменения алгоритмов расчетов и даже заносить их задним числом и сторнировать предыдущие расчеты. Так же поддерживаются пользовательские расчетные обьекты, позволяющие на основе специальных стандартных алгоритмов (есть на все случаи жизни) и указанием их свойств долепливать без программистов свои начисления (премии, постоянные и т.д.)

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

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

Интересно, что сложнее всего заказчикам было обьяснить отсутствие в клиенте кнопки "РАСЧЕТ". То, что в любой момент из любого места программы можно моментально посмотреть на сотрудника его полный расчет зп на текущий момент было для них шоком и пришлось долго их убеждать, что на самом деле это GOOD и при правильном подходе избавит от многих ошибок пользователей, очень иногда забывчивых, о том, что они меняли, не считали или не печатали.

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

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

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

Насчет человека все просто - у нас в конторе существует несколько продуктов, причем автоматизирующих разные отрасли, соотвествующе работает несколько команд. Основных команд две - это ЗП и ЖКХ, причем ЖКХ имеет больший вес, так как старая зп много доходов не приносит. Естественно в этой команде идет постоянный поиск/набор сотрудников, особенно связанных с отчетами, так как работы по обслуживанию ДЭЗов очень много. Однако из за того, что их ведущий программист не отличается коммуникабельностью, идет очень большая текучка и отсев кандидатов. В свою очередь мне лично остается только присутствовать негласно на собеседованиях, если человек перспективен пытаться устроить его в контору, далее можно посмотреть как он будет работать в команде конкурентов, а так как организованные там принципы работы и "характер" ведущего программера обычно приводят к тому, что человек начинает подумывать о том, куда он попал, всегда можно попытаться перетащить его в свою команду. Способ конечно прозаический, но очень действенный, главное что человек мне уже достается проверенный временем и не я выпрашивал вакансию, а мне его просто перевели, чтобы не потерять специалиста.

Что мне не понравилось GUI в CLR:

1. Иеархия классов - чем то смахивает на обрезанную версию VCL
2. Разработка компонентов - легче чокнуться, чем разработать сложный компонент с редакторами под IDE
3. Глюкавость компонент, входящих в стандартный комплект поставки (особенно это касается грида и отчетника)
4. Отсутствие Layout manager (управление расположением контролов) и Shema manager (управление скинами)
5. Не продуманность событийной модели у многих компонент
6. Закрытость CLR - отсутствие исходников и краткое описание иеархии классов

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

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

Вообще у меня сложилось мнение, что местами CLR излишне усложнена, а в других местах излишне упрощенна, но как говорится это мое личное мнение :)

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

Почитать проблемы, возникающие с разработкой компонент и их решения наверное легче всего на сайте ASP.NET Mania . Там есть народ, очень хорошо разбирающийся в разработке компонент под .NET, который так же до всего доходил сам, за это можно сказать большое спасибо MS, которые информацию по потрохам CLR в помощь положили в урезанном виде и предложили всем заинтересованным разработчикам компонент подключиться к их специальной программе "обкомпонентивования" CLR с получением необходимой доки и наработок всего то за некоторое кол-во тыс. баков. Хитро придумали, ничего не скажешь.

В том то и дело, что разбивка функционала по подклассам для расширения функциональности не есть самый лучший способ. В Java пошли другим путем, делая впервую очередь упор на интерфейсы и используя парадигму "Модель-Документ-Представление". Это позволило добиться большей гибкости и простоты при меньших кол-вах классов, а главное стандартизации логики работы.