Bankir.Ru
8 декабря, четверг 23:14

Объявление

Свернуть
Пока нет объявлений.

Процесс разработки проектов для создания ИС

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

  • Процесс разработки проектов для создания ИС

    Уважаемые коллеги!
    Начал аудит сабжа и столкнулся вот с чем:
    Для начала вот программа аудита:
    1. Нормативной базы
    2. Методологии разработки проектов
    3. Требований при разработке проектов
    4. Оценки качества разработки проектов
    5. Использования стандартов
    6. Контроля над разработкой проектов
    7. Развития и поддержка систем
    Проблемы:
    - Постановщики умные люди (это не проблема ) и поэтому прибалтывать умеют не хуже меня! При этом постоянно пытаются раскрутить меня на то, чтобы я написал в отчёт о необходимости обучения, создании дополнительных штатных единиц и т.д. Так вот! Вопрос мой такой:
    1. Каково должно быть соотношение постановщиков к общему числу АйТишников или общему числу работников банка (может вопрос некорректен, но может предложите что-то ещё)
    2. Что можете сказать по поводу обучения? Они говорят, что в сети информации практически нет! Я имею ввиду по продуктам типа Rational Rose, стандартам и т.д.
    3. Как Вы думаете, ГОСТы типа 34 ещё целесообразно применять для создания проектов или уже давно пора переходить на буржуйские?
    Вот, пока всё... Может ещё добавите чего...
    Спасибо!
    Удача любит подготовленный разум...

  • #2
    2 Хэванс_До:
    Каково должно быть соотношение постановщиков к общему числу АйТишников или общему числу работников банка
    Честно говоря, я всегда, по наивности природной, думал, что консультант привлекается для выработки оптимального решения поставленной задачи.
    В таком случае ответ примитивен - ноль! Если, естественно, мы говорим о банке. IMHO, банк - кредитная организация, а не фирма-разработчик и заниматься разработкой не по его профилю. Ведь недаром в народе говорят "Беда, коль сапоги начнет тачать пирожник...".

    Комментарий


    • #3
      2Cost : Вы, уважаемый, выдаёте желаемое за действительное.
      WBR, Александр Турчин

      Комментарий


      • #4
        Cost
        Я понимаю Ваше желание привлечь наше внимание к аутсорсингу, это - Ваш хлеб, но!
        Такая структура в нашем банке существует, и мне необходимо её проверить. Замечу, что мы не коммерческий банк, а что-то вроде Вашего Центробанка.
        Тогда так: я прошу всё же помочь мне с сабжем, однако подниму ещё один вопрос.
        Так как наш банк не является коммерческим, значит и зароботная плата соответсвующая. Вот поэтому мы и являемся некой кузницей кадров. У нас отличная техническая база, замечательные специалисты (остались ещё). Вот и получается, что мы набираем АйТи спецов, обучаем их, а они через некоторое время уходят на другую работу. И это понятно, ведь им предлагают больше денег за их труд.
        Что вы думаете по этому поводу? Только плиз, не говорите о повышении зарплаты... Пока я ничего лучше аутсорсинга не придумал.
        Удача любит подготовленный разум...

        Комментарий


        • #5
          Хэванс_До

          Вот поэтому мы и являемся некой кузницей кадров

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

          Скушно, уважаемый... Поскольку понятно, на кого Вы работаете, узнайте, чего ихнее начальство НА САМОМ ДЕЛЕ хочет... и лапшички, лапшички побольше на уши. А цифры в таких случаях кроме как с потолка взять неоткуда (или вот я с умным видом посоветую - один постановщик на два программиста - так считалось в одном БОЛЬШОМ НИИ...).

          Хотя по моему опыту (а я работаю и как проектировщик/архитектор, и как программист) при "подготовленном разуме" и заказчике, знающем, чего он хочет (то есть имеющем спецификацию требований) на проектную спецификацию уходит примерно 10% времени. А вот сколько у заказчика уходит на спецификацию требований - очень трудно сказать. Бывает, люди месяцами размышляют, а вот видел пример, когда список требований родился за пару часов - и это для немаленького по сложности проекта.
          М.Голованов

          Комментарий


          • #6
            mgolovanov
            Поскольку понятно, на кого Вы работаете, узнайте, чего ихнее начальство НА САМОМ ДЕЛЕ хочет
            Что-то я не совсем понял... Что значит ихнее??? Это и моё начальство! Я ВНУТРЕННИЙ аудитор! И с лапшичкой не проканает... Мне потом с этой лапшичкой работать!
            Судя по вашему высказыванию, штат должен соответсвовать задачам, но это и так понятно. Окей, с штатом замнём, как на счёт других вопросов? Обучение, стандарты?
            Кстать, как вы лично справляетесь с таким количеством обязанностей?? И постановщик и программер??? Я что-то себе это с трудом представляю, хотя может быть у Вас особые условия или небольшое количество задач...
            Cost
            Чтож, при грамотном обосновании можно заменить весь штат на привлечённых специалистов и сторонний продукт. Но это слишком простое и дорогое решение (а мы простых путей не ищем , а тем более дорогих). Тем более, что:
            Нашими айтишниками уже написан АБС, который в общем-то удовлетворяет всем требованиям бухгалтерии и др. подразделений.
            Представьте, сколько было израсходовано средств и времени:
            - Сервера Sun
            - Oracle с лицензиями (продукт построен не на тонком клиенте)
            - Обучение специалистов
            И куда теперь это всё девать??? Начальство не поймёт. Или поймёт, если таки грамотно обосновать! Или всё-таки смириться с текучкой кадров, обучать новых спецов и считать это расходами на поддержку ИС?? ))
            Или вот ещё вопрос:
            Возможно такие компании, как Ваша, может тюнить и поддерживать уже созданные системы??? Хотя это утопия, дешевле, наверное, своих перцев обучать...[/B]
            Удача любит подготовленный разум...

            Комментарий


            • #7
              Возможно такие компании, как Ваша, может тюнить и поддерживать уже созданные системы???
              WBR, Александр Турчин

              Комментарий


              • #8
                Александр_Турчин
                Хмммм... Вот сам это как шутку писал казалось бы.... А узнал, что и такое бывает, оказывается!
                Хотя, конечно, это противоречит принципам аутсорсинга, но за деньги можно обо всём договориться.
                Удача любит подготовленный разум...

                Комментарий


                • #9
                  2 Хэванс_До:
                  Представьте, сколько было израсходовано средств и времени:
                  - Сервера Sun
                  - Oracle с лицензиями (продукт построен не на тонком клиенте)
                  - Обучение специалистов
                  И куда теперь это всё девать??? Начальство не поймёт. Или поймёт, если таки грамотно обосновать! Или всё-таки смириться с текучкой кадров, обучать новых спецов и считать это расходами на поддержку ИС??

                  Вот Вы сами на свой вопрос и ответили. Попробуйте просчитать во что Вам обойдется собственная поддержка и развитие ИС, скажем в год, далее прикиньте среднюю цену поддержки "промышленных" АБС за тот же период и, если поддержка стороннего разработчика окажется дешевле, разделите стоимость смены системы на разницу в стоимости поддержки. Полученное число будет сроком окупаемости смены АБС в годах. Если это число получится меньше 10 - проект смены АБС имеет смысл начинать или хотя бы готовить. Если намного больше 10 - смиритесь.

                  Комментарий


                  • #10
                    Cost
                    Согласен.
                    Удача любит подготовленный разум...

                    Комментарий


                    • #11
                      Спецы всегда будут искать, где лучше. Для предотвращения этого и существует мотивация в виде пряников.
                      Нормально, если после обучения , срок обязательной отработки составит полгода, или потребует возврата денег.

                      Уверен, что использование промышленной АБС потребует наличия спецов. И новых спецов, нужно обучать или платить им. И они будут искать где лучше, приобретя сертификаты, трейнинги или освоив профессию, если не увидят возможность к росту в организации.

                      Только баласт сидит тихо и не дергается, дрожа, чтобы не выгнали.

                      >>>Если это число получится меньше 10 - проект смены АБС имеет смысл >>>начинать или хотя бы готовить. Если намного больше 10 - смиритесь.
                      А не крутовато? Может все-таки год, если не полгода. И может оценивать нужно не мизерную зарплату, а стратегические показатели и надежность поддержки и развития системы.

                      >>>Или всё-таки смириться с текучкой кадров, обучать новых спецов и считать >>>это расходами на поддержку ИС??
                      А какой процент текучки в ИТ отделе в год?
                      А какой процент текучки в банке в год?
                      Последний раз редактировалось AAL; 18.11.2002, 14:23.

                      Комментарий


                      • #12
                        2 AAL:
                        >>>Если это число получится меньше 10 - проект смены АБС имеет смысл >>>начинать или хотя бы готовить. Если намного больше 10 - смиритесь.
                        А не крутовато? Может все-таки год, если не полгода. И может оценивать нужно не мизерную зарплату, а стратегические показатели и надежность поддержки и развития системы.

                        Естественно, оценить ...стратегические показатели и надежность поддержки и развития системы гораздо лучше и показательнее. Но и намного затратнее и труднее.
                        А окупаемость за год или полгода, IMHO, - это несбыточная мечта всех времен и народов. Если есть возможность окупить смену АБС за полгода-год - это скорее всего означает, что текущая АБС просто "пожиратель средств" или вновь выбранная слишком слаба для работы.

                        Комментарий


                        • #13
                          Хэванс_До

                          И постановщик и программер??? Я что-то себе это с трудом представляю

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

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

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

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

                          Комментарий


                          • #14
                            Хэванс_До

                            Нашими айтишниками уже написан АБС, который в общем-то удовлетворяет всем требованиям бухгалтерии и др. подразделений.
                            Представьте, сколько было израсходовано средств и времени:
                            - Сервера Sun
                            - Oracle с лицензиями (продукт построен не на тонком клиенте)
                            - Обучение специалистов
                            И куда теперь это всё девать???


                            Как знакомо!... А кто крайний? Кто-то все это заварил, снял пенки и смылся?

                            Я тут в Москве в последнее время стал встречать дядек, делающих бизнес на впаривании разного рода софта, который в приличных объемах (и, разумеется, при никуда не годном качестве) понаделан в разных окологосударственных конторах. Сидит такой хитрован и рассказывает, что вот-де "разработана бухгалтерская программа... под Ораклом... ребята хорошие... ну, вот главный ушел... а я тут договорился с какой-то чукотской фабрикой, на Урале целый город какой-то можно обасучить..." Под водочку и хороший откат все можно впарить - может, и Вам этим заняться? А то как бы Вам козлом не стать... отпущения.
                            М.Голованов

                            Комментарий


                            • #15
                              2 М.Голованов
                              Я думаю, что мораль в этом аспекте продаж хороша, но не уместна. Если человек "впараивает" хорошо в рамках закона (аморальность "отката" и водочки очень спорный вопрос особенно в многонациональной стране) то он хороший продавец на том рынке, который есть.
                              Есть кто-то что-то готов купить таким образом, то он покупатель, хотя возможно и лох. Если он жадный лох, то он платит дважды и трижды. И не одна Россия в Европе такая. Это нормально, в том плане что существует массово. Германия и Франция как пример.

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

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

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

                              Стандартов нет есть скорее принципы, как опыт лучших, - PMI IPMA ITIL...

                              Комментарий


                              • #16
                                AAL
                                мораль в этом аспекте продаж хороша, но не уместна

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

                                AAL
                                да и организация производства чего либо и софта и ИТ в том чилсе - вопрос искусства

                                Ну я бы не согласился.

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

                                Во-вторых, сами же себе далее противоречите - все-таки принципы есть. А дальше можно сказать, что есть и методы создания ПО, и способы огранизации процессов, и так далее. Кстати, не знаю, что там Микрософт рекомендует пользователям своих девелопмент тулз, а у самих у них внутри все организовано в лучших традициях Extreme Programming - есть постановщики - это в основном IT-аналитики и маркетологи, выступающие в конечном счете как представители пользователей, выражающие их требования (разумеется, с учетом руководящих указаний парня Билла и его другана Стива) и формулирующие эти требования, и разработчики - более или менее оформленные группы по продуктам, внутренняя огранизация которых формализована весьма слабо и напоминает этакие артели, где все все умеют, но каждый в данный момент делает что-то определенное в зависимости от принятого группой плана.

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

                                Комментарий


                                • #17
                                  2 М.Голованов
                                  Спорить не буду, ибо вы сказали тоже самое другими словами, а понятия в данном случаем для меня не существенны. Главное человеку помочь.

                                  "В общем, есть разные проекты - и разные подходы." /М.Голованов/

                                  Комментарий


                                  • #18
                                    Почитайте пожалуйста, книжку "Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем. ISO/IEC TR 15504 CMM) М:2001 и-во "Книга и бизнес", ISBN 5-212-00884-0

                                    В ней можно найти большинство технологических ответов, в том числе и по единой терминологии :-)

                                    Удачи !

                                    Комментарий


                                    • #19
                                      Раз уж речь зашла про литературу, могу порекомендовать следующие книжки, которые не очень заумные, но тем не менее полезные:
                                      1. М.Кантор "Управление программными проектами" (ISBN: 5-8459-0294-0, 0-201)
                                      2. Ф.Крачтен "Введение в Rational Unified Process" (ISBN: 5-8459-0239-8)

                                      Обе покупались мной в "Болеро".

                                      Первая книжка ненавязчиво рассказывает про подходы к проектированию ПО (основные этапы, содержание этапов).
                                      Вторая - проектирование ПО с применением RUP.

                                      Комментарий


                                      • #20
                                        Механизатор учёта
                                        2. Ф.Крачтен "Введение в Rational Unified Process"
                                        Если Вам интересен RUP, то очень рекомендую почитать "отцов-основателей"
                                        А.Якобсон, Г.Буч, Дж.Рамбо "Унифицированный процесс разработки программного обеспечения" (ISBN: 5-318-00358-3)
                                        Добро всегда побеждает зло. Потому что кто победил - тот и добро.

                                        Комментарий


                                        • #21
                                          Хэванс До
                                          Где-то я читал (вроде западные мерки, но не уверен), что автоматизаторов должно быть 10% от штата. Я думаю, что это верно для организаций, которые активно разрабатывают софт своими силами. Количество постановщиков (системных аналитиков) мне кажется нормативами не определишь. Правильнее разбить всех на группы по направлениями разработки и в каждой группе должен быть как минимум один аналитик. Все это очень индивидуально, т.к. согласитесь, что разрабатывать главную книгу или еще кредиты, депозиты, частные вклады и дилинг - совсем разный объем знаний. По RUP'у книг сейчас навалом, но ему лучше учиться на курсах ключевым сотрудникам.
                                          Оценка качества проектов - другая задача и ей лучше заниматься после того, как сможете перейти на промышленные методы разработки.

                                          Комментарий


                                          • #22
                                            Accounter

                                            Если Вам интересен RUP

                                            Конечно интересен, но хочется пройти от простого к сложному. Именно для этого и "Введение" (глава из книжки по сексологии ) от Крачтена. Кстати, он также из корпорации Rational.

                                            Комментарий


                                            • #23
                                              Механизатор учёта
                                              Кстати, он также из корпорации Rational
                                              Не знал.

                                              но хочется пройти от простого к сложному.
                                              Тогда очень рекомендую
                                              Д. Леффингуэлл, Д. Уидриг "Принципы работы с требованиями к программному обеспечению" (ISBN 5-8459-0275-4)
                                              Сильно понравилось. Товарисчи (методологи) тоже из Rational.
                                              Добро всегда побеждает зло. Потому что кто победил - тот и добро.

                                              Комментарий


                                              • #24
                                                Доброе утро, коллеги!
                                                Тааак, ну уже ближе что-то... Подобрались к RUPу.
                                                Поговорил я с парнями, они оказывается пытаются работать по RUPу, но как-то полулегально, так как единый стандарт у нас ГОСТ. И руководство не приветствует таких нововведений... нужно будет с руководством этим поговорить...
                                                За пару лет работы в банке я понял одно, руководство наше готово костьми лечь лишь бы не допускать вреиенных неудобств и простоев в связи с инновациями, переходом на новые продукты и т.д. Чтож, буду работать в этом направлении!
                                                mgolovanov
                                                Вот не соглашусь я с Вами! Я до того как стал аудитором был программером, думаю даже, что неплохим и мне было гораздо удобнее, когда мне полностью формализовал задачу постановщик, описывал все этапы, сам разговаривал с заказчиками, писал документацию... И он абсолютно не был лишним звеном! Я за него был готов глотку перегрызть любому! Тем более, что он ко всему тому был ещё и докой в бухгалтерии! В общем мы с ним всегда укладывались во все сроки, никогда не было проблем с заказчиками, я не писал всякие там бумажки, документации, согласования! Я просто садился и писал прогу!
                                                Да, кстати, вы перед написанием кода пишите всякие постановки задачи, спецификации, согласования со структурными подразделениями, документации по программному продукту? В общем проходите весь жизненный цикл ИС?
                                                arc
                                                Простите, от штата банка или АйТишников 10%?
                                                Удача любит подготовленный разум...

                                                Комментарий


                                                • #25
                                                  Хэванс_До
                                                  Вот не соглашусь я с Вами

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

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

                                                  Упоминаемые здесь методологии типа RUP (и более ранние типа структурного программирования, STRADIS и пр.) есть по большому счету лишь изложение опыта конкретных людей, преломленное через призму некоторых общих принципов (типа принципа разделения процесса на проектирование, разработку и тестирование). Скажем, в чистом виде RUP будет работать в формальном коллективе с разделением труда только при соответствующей обученности и квалификации участников процесса с тем, чтобы они ОЧЕНЬ ХОРОШО понимали друг друга (да и психосовместимость не помешает). Книжки можно читать... там все правильно написано, но известные мне примеры применения. скажем, RUP имеют два исхода: либо получается бюрократическая система, откуда стоящие работники бегут (пример - Vested Development, Inc.), либо сам RUP существенно приспосабливается к реальному коллективу и дает те плоды, которые может дать в конкретных условиях (кстати, я сам, работая индивидуально, все-таки работаю по большому счету по некоей разновидности RUP с акцентом на итеративность).
                                                  М.Голованов

                                                  Комментарий


                                                  • #26
                                                    mgolovanov
                                                    ибо сам RUP существенно приспосабливается к реальному коллективу и дает те плоды, которые может дать в конкретных условиях
                                                    Абсолютно с Вами согласен. Воспринимать RUP как догму нельзя категорически.
                                                    Да и сложно ее в полном объеме поднять.
                                                    Добро всегда побеждает зло. Потому что кто победил - тот и добро.

                                                    Комментарий


                                                    • #27
                                                      Сколько приходилось управлять в формальных коллективах с таким разделением труда - сплошная головная боль.
                                                      mgolovanov, как сказала мне одна бухгалтерша "это наша боль!"

                                                      Комментарий


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

                                                        А ведь так бывает. И они выигрывают. "Одна голова хорошо, а полторы .... А про три и разговора нет". Это про одиночные разработки.

                                                        Комментарий

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

                                                        Свернуть

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

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