Bankir.Ru
4 декабря, воскресенье 02:47

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

Показать больше
Показать меньше

"АБС Next. Система следующего поколения"

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • "АБС Next. Система следующего поколения"

    II семинар состоится 26 июня 2003 года.
    Посмотрим.

  • #2
    Прошу прощения

    "АБС Next. Система следующего поколения"

    Комментарий


    • #3
      Не мог не удержаться.

      А "следующего поколения" это какого? Или оно всегда "следующее"?
      Добро всегда побеждает зло. Потому что кто победил - тот и добро.

      Комментарий


      • #4
        Следующее - это использующее новейшие технологии !

        Комментарий


        • #5
          Угу. Я так и понял. "Generation" оно завсегда "next".
          Добро всегда побеждает зло. Потому что кто победил - тот и добро.

          Комментарий


          • #6
            Предлагаю прийти на семинар с бэджиками с названиями ников

            Комментарий


            • #7
              arc Хорошая идея!!! А мне как быть? Меня не пригл-А-А-А-А-с-И-И-И-И-ли...
              И мой бэджик с моим ником ничего Вам нового не скажет...

              ... А про "НЕКСТ"... Говорят, что "Кворумяне" базовое ядро показывать будут!!!
              Да пребудет с Тобою Великая Сила! ©

              Комментарий


              • #8
                К_Маркелов А ты пошли заявку на seminars@quorum.ru и попросись.

                Комментарий


                • #9
                  Ребята, вы про несчастных провинциалов, которым никакие семинары не светят не забывайте, ладно ?
                  Убедительно прошу, после семинара хоть чуть-чуть поделиться впечатлениями.
                  Если не публично, то хотя бы в мыло....

                  Комментарий


                  • #10
                    Да, да, да...
                    Присоединяюсь к высказыванию предыдущего оратора.

                    Комментарий


                    • #11
                      Составим полный отчет ...

                      Комментарий


                      • #12
                        RedPank А ты пошли заявку на seminars@quorum.ru и попросись.
                        Я??? ПО-ПРО-СИСЬ??? Нет уж! Если уж мы в Вашем Банке проект ведём, то
                        1) либо сами пригласят,
                        2) либо ваш начальник - мой тёзка нам расскажет...

                        Я ленивый... Я сам только на Банкир.Ру пишу... А проситься на семинар... Не... Не буду... лень...

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

                        Комментарий


                        • #13
                          К_Маркелов
                          Кстати, приятно видеть, как в соседней теме по Кворуму вопросы задают одни спецы из одного хорошо знакомого Банка, а отвечают - другие спецы из этого же самого Банка... Это игра такая. Только я не понял про кого это ???

                          Комментарий


                          • #14
                            Впечатления о семинаре:

                            1. Собралось не более 30-ти человек. Если учесть, что не по одному из каждого банка, то получается, что были представители 8-10 ти банков.
                            2. Рассказывали про ядро системы и про формирование отчетов
                            3. По поводу ядра - в голове полная каша
                            4. По поводу печати: Точно будет Кристал Репортс, который будет общаться с БД через некий симантический слой. Текстовые отчеты - под вопросом.
                            6. Фуршет: Пирожки, соки, воды, коффе, чай.
                            На столах стояли тарелочки с лимонами и фужеры ссответствующей формы. Самого напитка что-то не наблюдалось ...
                            7. Демонстрация. К сожадению долго оставаться не могли - дела.

                            P.S.
                            Очень "порадовало" сообщение о том, что в К отказались использовать механизмы Оракла для хранения объетов. А чем их заменить - есче не решили. Так-же не решен вопрос на каком языке бкдет реализована система и какой язык смогут использовать в банках ...
                            Система прав так-же есче не проработанна ...


                            Это в кратце

                            Комментарий


                            • #15
                              RedPank
                              Прочитали с интересом. Спасибо !
                              Но можно было и чуть-чуть подробнее, например в этом месте: По поводу ядра - в голове полная каша
                              И еще в этом: Демонстрация

                              P.S.
                              Очень "порадовало"
                              ...
                              - Мы отсебятиной все заполним,
                              Пусть плачем взорвется форум !
                              Движок перестроим, ОрАкл похороним -
                              Пусть знают, чтО может Кворум !

                              Комментарий


                              • #16
                                Для начала ...

                                Основные понятия АБС Next:

                                - Договор
                                - Субъект
                                - Банковский продукт

                                Между Субъектами заключается договор на выполнение ряда услуг.
                                Услуга выполняется банковским продуктом.

                                Любая банковская услуга выполняется на основе договора.

                                Пример:
                                договор на РКО -> Услуги {списание с р/с, зачисление на р/с, кассовое обсл.}

                                Комментарий


                                • #17
                                  Кворум на проводе...

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

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

                                  Кроме этого, речь шла о представлении внешнего интерфейса к системе для построения отчетов - семантического слоя.

                                  Если вопросы еще остались, то в меру сил попробую на них ответить.

                                  Всех благ,
                                  Олег.

                                  Комментарий


                                  • #18
                                    Большое видится на расстоянии
                                    После кратковременного отпуска можно описать свои впечатления от семинара.
                                    Что не удовлетворило - не было представлено четкой формализованной концепции бизнес архитектуры системы. Несколько невразумительные понятия Субъекты, Банковский продукт, работа от Договоров к сожалению не дают четких ответов на многие вопросы. Я откровенно говоря рассчитывал, что нам презентуют концепцию системы, а под нее покажут пример реализации. Было только второе. Где получить первое не знаю.
                                    Насторожило, что нет четкой позиции по нескольким принципиальным вопросам: язык серверной логики (неформальные ответы), использование клиентских алгоритмов (в каком виде: DLL, VBS, ActiveX ?), какой Репортер. По отчетности вообще как-то все было сыро, даже что касается инструментария.
                                    Вообщем вопросов гораздо больше чем ответов, причем вопросов, которые касаются только постановки.

                                    Комментарий


                                    • #19
                                      Еще раз здравствуйте!

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

                                      Что до языка серверной логики, то нет никакого сомнения, что это PL/SQL и никаких новых языков выдумываться не будет. Что до клиентских алгоритмов, то они по возмождности будут сведены к минимуму, но пока мейнстрим это DLL, а поскольку клиент разрабатывается на C#, то вряд ли речь пойдет о VBS, да и ActiveX несколько накладно. Но дело разумеется не в том на чем писать, а в том как писать, но если будет необходимость, можно предложить даже CORBA-интерфейсы, правда не уверен, что они вас удовлетворят по производительности.

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

                                      Что до Субъекта, Банковского продукта и Договора, то куда уж конкретнее, чем абстрактное понятие бизнес-объект и т.п.

                                      Вообщем на следующем семинаре оставшиеся вопросы можно будет разрешить, а если вы подробнее опишите интересующие вас темы, то можно будет им уделить особое внимание.

                                      С уважением,
                                      Олег.

                                      Комментарий


                                      • #20
                                        ОС
                                        нет никакого сомнения, что это PL/SQL и никаких новых языков выдумываться не будет
                                        я это услышал в курилке, а не в докладах

                                        пока мейнстрим это DLL, а поскольку клиент разрабатывается на C#, то вряд ли речь пойдет о VBS, да и ActiveX несколько накладно
                                        что-то не понял, в чем накладность того же VBS ? Если смотреть со стороны банка, то механизм DLL довольно не удобен для оперативных замен и из приведенных механизмов для нас самый худший.

                                        Что до Субъекта, Банковского продукта и Договора, то куда уж конкретнее, чем абстрактное понятие бизнес-объект
                                        Одни и те же абстрактные понятия можно реализовать совершенно различными способами и от этого будет зависить привлекательность системы по разным критериям. Все пишут на ООП, но программы почему то есть хорошие и плохие. Потому что объектная модель у каждого своя и не у всех она оптимальная. Вот это и интересовало и это как раз практически не было озвучено. Заявить о 3-4 абстактных терминах для меня, извините, ничего не сказать. Если у вас концепция АБС не разработана, то зачем тогда показывать тестовый пример ? Если разработана, то почему ее не обсудить ? Если она не разработана, то какова реальность планов по срокам ?

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

                                        Комментарий


                                        • #21
                                          Насчет скриптовых языков, то еще со времен FoxPro или 1С (кому что ближе) скриптовые среды, где можно поменять везде и все отличались большим количеством всплывающих из недр "пузырей", плохой нагрузочной способностью и невыскокй скорострельностью. Так что сдается мне, что если и применять скриптовые языки, то в очень узких рамках, о чем сейчас и разговаривать смысла нет. Речь идет скорее о технологии хранения скомпилированного кода в репозитории (БД, но возможно и на локалке, если каналы плохие), а DLL пока просто не накладывает огранчений, таких как обязательные интерфейсы компонент (COM, CORBA, etc.)


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

                                          Комментарий


                                          • #22
                                            ОС
                                            Так что сдается мне, что если и применять скриптовые языки, то в очень узких рамках, о чем сейчас и разговаривать смысла нет
                                            Я даже и не заикался о том, что скриптовые языки надо широко применять для бизнес-логики, наоборот наш банк стоит на позиции использования только PL/SQL в чистом виде. Но есть часть вспомогательных задач (некоторые проверки, выгрузки данных в EXCEL, подключение собственных функций) которые правильнее делать на клиенте. Вот для этих задач и хотелось бы иметь клиентские алгоритмы. VBS, лежащий в сетевом каталоге (или репозитории) по моему мнению легко поменять "на ходу", с DLL это большая проблема, если учесть, что банк работает практически круглосуточно, а клиентов обслуживают до 20-00. Так что это не теоретическая проблема, а самая что есть практическая.

                                            Так что концепции все те же, подход от процессов, бизнес объектов, поддержка внедрения, т.е. версий и связей между объектами через репозиторий, высокая производительность и надежность
                                            Бла-бла-бла... Зачем повторять общие фразы, не несущие за собой никакого смысла. В предыдущем постинге я уже отвечал на это - нет смысла повторяться.
                                            Добавлю только, что в предыдущем проекте Stelth (вы знаете о таком ?) г-н Ерошин разработал такую концепцию архитектуры АБС, что мы просто за голову схватились и 6 часов с пеной у рта доказывали, что так делать нельзя. Не уверен, что к нам на фирме прислушались, но жизнь доказала нашу правоту.

                                            Комментарий


                                            • #23
                                              arc
                                              Бла-бла-бла... Зачем повторять общие фразы, не несущие за собой никакого смысла
                                              Наверное не стоит так категорично... Фразы наверное все же смысл несут... О высокой производительности, в частности, на семинаре было сказано довольно конкретно. Приятно осозновать, что при сравнении с опубликованными данными по производительности других разработок, у Next`а есть хороший задел.

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

                                              Относительно концепции бизнес архитектуры... Честно говоря я так и не понял, что это за документ, что в нем должно содержаться. У меня есть какие-то предположения, но четкого представления нет. И в методологии RUP такого документа также нет... Если что-то мы не раскрыли ни в темах докладов, ни в курилке, приносим извинения. Темы семинара мы написали в приглашениях, их и придерживались.

                                              И последнее, если есть еще пожелания, каким вопросам уделить больше внимания на следующем семинаре, пишите сюда или на мейл.

                                              Спасибо,
                                              Волков Максим
                                              Руководитель проекта Next
                                              Последний раз редактировалось nnax; 25.07.2003, 14:09.

                                              Комментарий


                                              • #24
                                                nnax
                                                Фразы наверное все же смысл несут... О высокой производительности, в частности, на семинаре было сказано довольно конкретно. Приятно осозновать, что при сравнении с опубликованными данными по производительности других разработок, у Next`а есть хороший задел.

                                                Сравнивать существующие системы и даже не прототип новой системы, по моему не очень корректно.

                                                Относительно концепции бизнес архитектуры... Честно говоря я так и не понял, что это за документ, что в нем должно содержаться. У меня есть какие-то предположения, но четкого представления нет. И в методологии RUP такого документа также нет...
                                                Давайте не сравнивать RUP с Библией (или законами Моисеевыми ).
                                                Я себе представляю бизнес архитектуру в виде модели объектов и списком документов с пояснениями к ней, т.к. не все видно из модели объектов (например: остаток хранится: за каждый день/когда работал счет/на последний операционный день).
                                                Кстати почти такой документ представлял Ерошин для Stelth, глядя на который я просто ужаснулся.
                                                Может я конечно забегаю вперед паровоза, но когда мне объявляют сроки (довольно сжатые) выпуска первой версии, а бизнес модели не представляют, то у меня это вызывает естественное беспокойство за то, что будет выпущено.

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

                                                Предлагаю темы семинаров:
                                                1) Инструментарий новой системы - было
                                                2) Демострация чего-то - было
                                                3) Бизнес архитектура системы - бизнес модель
                                                4) Инструментарий клиентских приложений (для отчетности ЦБ и аналитики, клиентской логики, администратора и т.д.), механизмы смены версий и перехода с Кворум Оракл версии - можно объединить с п.3
                                                5) Демонстрация действующего прототипа системы

                                                Комментарий


                                                • #25
                                                  Разрешите вставить свои 2 с половиной копейки, хоть и не совсем в тему, но не флейма ради, а токмо в качестве моральной поддержки обсуждающих.

                                                  Уважаемые arc , nnax и ОС ! Ни в коем случае не смейте думать, что вы тут остались одни, и кроме вас тема никому не интересна. Уверяю, многие люди ваши постинги внимательно и с интересом читают. Пожалуйста, продолжайте в том же коструктивном духе !

                                                  Я очень сожалею, что в силу своего служебного статуса не могу присутствовать на семинарах Кворума и не являюсь в своем банке ЛПР (Принимающим Решение) о дальнейшем выборе АБС. Тем не менее считаю, что вполне вероятно мне придется работать на новых версиях Кворума, и в силу этого любая информация о них интересна.

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

                                                  Комментарий


                                                  • #26
                                                    Я то думал, что мы тут междусобойчиком, а оказывается мы - участники "За стеклом - 5"

                                                    Комментарий


                                                    • #27
                                                      arc Сравнивать существующие системы и даже не прототип новой системы...
                                                      Прототипирование - это подход к разработке, при котором качественная оценка законченого решения (идеи, концепции) осуществляется на живом>> примере, в условиях, приближенных к боевым>>! Подчеркну главное качественная оценка законченного решения . На заре туманной юности и знакомства с RUP`ом я и коллеги называли прототипом любое НЕзаконченное программное решение, которое как-то можно показывать Заказчику, говоря при этом: Не смотрите на ошибки, кривизну подхода, тормоза... Ну а в целом-то, правда здорово???>>.
                                                      Прототип демонстрирует законченное решение! Отличает его от готовой системы, то что этих решений, идей, концепций там недостаточное для промышленного функционирования количество.

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

                                                      Та же история с прототипами:
                                                      1. среды workflow,
                                                      2. концепции сценариев для описания банковских продуктов и условий договоров.
                                                      3. концепции семантического слоя.
                                                      У каждого прототипа была своя цель.

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

                                                      Попробую пояснить:
                                                      Я себе представляю бизнес архитектуру в виде модели объектов и списком документов с пояснениями к ней, т.к. не все видно из модели объектов (например: остаток хранится: за каждый день/когда работал счет/на последний операционный день).
                                                      Документы Design Model и Software Architecture Document (SAD) учетного ядра, которые были переданы в Ваш банк, дают ответ на Ваш вопрос в абстракциях учетного ядра:
                                                      Плановый и фактические остатки по аналитическому счету сохраняются на конец каждого учетного периода, в котором были соответствующие обороты по этому аналитическому счету.
                                                      Прикладное же ядро, отвечающее за бухгалтерскую модель учета, может внести, а может и не вносить коррективы в поведение системы при описании своего уровня абстрации (версия документа также передавалась). К примеру по (уже) лицевому счету сохраняются остатки на конец (уже) операционного дня , в котором были соответствующие обороты по этому лицевому счету. Но если поставить вопрос, а как в Next`е реализована работа по заключительным оборотам, предыдущий ответ будет неполным, если не сказать некорректным.
                                                      У заключительных оборотов по счету учетный период - год! И прикладное ядро, на своем уровне, как бы, вносит, коррективы в представление о поведении системы.
                                                      Вернемся к документам и библиям: не имея представления об уровнях абстракции (слои в документе - SAD), не имея моделей слоев и связей между ними, и, самое главное, не имея перед глазами документ с целями, которые хотелось бы достичь, можно долго спорить, какое решение лучше, какое - хуже. Именно так, неконструктивно, заканчивались публичные обсуждения в ФИДО и форумах, что лучше: Кворум, Диасофт, R-Style, западные системы...
                                                      Мне видится лишь один документ, который может в общем, кратенько, доступно и не скучно изложить бизнес концепцию системы - рекламная листовка
                                                      Кому нужно, могу выслать

                                                      Может теперь попробуем вместе сформулировать тему следующего семинара?
                                                      Ваша идея №4 по семинару полностью поддерживается, единственное законченного решения по миграции с Кворума на Next мы к концу октября предложить не сможем. Чуть позже.

                                                      И последнее Ваш призыв, arc, сформулировать требования к новой системе, что-то не нашел отклика. Пользуясь случаем, хочу...
                                                      На нынешнем этапе разработки это, пожалуй, самое ценное, что мы форумянины-разработчики ждем от вас, господа Банкиры.
                                                      Пожалуйста, высказывайтесь!
                                                      Последний раз редактировалось nnax; 27.07.2003, 16:34.

                                                      Комментарий


                                                      • #28
                                                        heg ответы специалистов Кворума также порадовали меня своей терпимостью Спасибо! Очень рад, что кто-то это отмечает...

                                                        Мне лично (ИМХО и еще раз IMHO !) кажется, что кворумовцы подходят к вопросу со своей стороны, технически, и просто не до конца понимают, что банки видят ситуацию совсем не так.
                                                        А вот это очень зря, что Вам так кажется. Мы абсолютно четко понимаем, что банки видят ситуацию совсем не так
                                                        Если серьезно, в нашей команде есть люди, которым знаком взгляд на систему со стороны банка, причем как со стороны бизнес-специалиста, так и со стороны специалиста ИТ-служб.
                                                        Если бы Вы спросили немного поконкретнее о нашей работе, или хотя бы сделали более конкретное утверждение, я бы обязательно ответил (подтвердил, опровергнул). А так сложно сказать: ну да, разделение труда присутствует
                                                        Это я про:
                                                        каждый делает свой отдельный кусочек, а потом из получившихся частей собирают целое
                                                        Мне даже сложно себе представить, как команда, почти из 50 человек, каждый кусочек системы делает совместно, дружной семьей Не обижайтесь, видимо Вы, имели ввиду что-то совсем иное, я просто не понял.

                                                        А вот людей, четко видящих ситсему целиком, судя по обсуждению не хватает
                                                        Да нет, вроде и ОС - системный архитектор проекта, и Ваш покорный слуга, имеет, скажем так, представление о системе Next и текущем ее состоянии.
                                                        Видимо на такое высказывание Вас натолкнуло, сослагательное наклонение некоторых наших высказываниях о системе... Ну так действительно есть еще белые пятна на карте решений.
                                                        Кстати это дает повод подискутировать. В частности, тема: что лучше DLL или VBS при описании клиентской логики... На данный момент мы склоняемся к первому. Если интерес к дискуссии есть, можно создать отдельную тему в рамках этого форума...

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

                                                        Комментарий


                                                        • #29
                                                          nnax
                                                          Документы Design Model и Software Architecture Document (SAD) учетного ядра, которые были переданы в Ваш банк, дают ответ на Ваш вопрос в абстракциях учетного ядра:
                                                          Оба-на ! Я то все говорю, все прошу, а оказывается все документы у меня под подушкой хранятся ! Максим, ты что-то напутал. У меня этих документов нет, иначе я бы их уже вовсю изучал. Кому ты их давал в нашем банке и когда ? Поверь, спрашиваю не ради флейма.

                                                          Вернемся к документам и библиям: не имея представления об уровнях абстракции (слои в документе - SAD), не имея моделей слоев и связей между ними, и, самое главное, не имея перед глазами документ с целями, которые хотелось бы достичь, можно долго спорить, какое решение лучше, какое - хуже. Именно так, неконструктивно, заканчивались публичные обсуждения в ФИДО и форумах, что лучше: Кворум, Диасофт, R-Style, западные системы...
                                                          Для меня речь не идет сейчас сравнивать, что лучше. Недостатки перечисленных систем у меня давно в голове хранятся. Меня интересует какова будет ваша новая система, не будут ли у нее в основе неверные решения.

                                                          И последнее Ваш призыв, arc, сформулировать требования к новой системе, что-то не нашел отклика
                                                          Грущу вместе со всей фирмой Кворум Значит мы такие - пользователи АБС Кворум, на кого роптать, кроме себя ?

                                                          Комментарий


                                                          • #30
                                                            А меня интересует следующее:
                                                            - сколько человек работает над проектом ? "Идеологов", программистов, ...
                                                            - что будет с существующими АБС ?
                                                            У меня впечатление, что уже сейчас с 2-мя не справляетесь. А с 3-мя ??? А ведь у вас есть есче и другие проекты.

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X