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

[Хэванс_До]

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

[Константин Красновский]

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

[Александр_Турчин]

2Cost : Вы, уважаемый, выдаёте желаемое за действительное.

[Хэванс_До]

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

[mgolovanov]

Хэванс_До

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

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

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

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

[Хэванс_До]

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

[Александр_Турчин]

Возможно такие компании, как Ваша, может тюнить и поддерживать уже созданные системы???

[Хэванс_До]

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

[Константин Красновский]

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

[Хэванс_До]

Cost
Согласен.

[AAL]

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

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

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

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

>>>Или всё-таки смириться с текучкой кадров, обучать новых спецов и считать >>>это расходами на поддержку ИС??
А какой процент текучки в ИТ отделе в год?
А какой процент текучки в банке в год?

[Константин Красновский]

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

[mgolovanov]

Хэванс_До

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

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

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

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

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

[mgolovanov]

Хэванс_До

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

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

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

[AAL]

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

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

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

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

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

[mgolovanov]

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

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

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

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

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

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

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

[AAL]

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

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

[bantik]

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

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

Удачи !

[Механизатор учёта]

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

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

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

[Accounter]

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

[arc]

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

[Механизатор учёта]

Accounter

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

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

[Accounter]

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

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

[Хэванс_До]

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

[mgolovanov]

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

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

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

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

[Accounter]

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

[Julls]

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

[genak]

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

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