На каких средствах создавать систему ЦДДП

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

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

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

   Тенденции такого развития видны многим, поэтому есть фирмы «быстрого реагирования». Они быстро постигают смысл насущных задач и создают программы «на злобу дня». Безусловно таким фирмам требуются средства. на которых легче, а значит и быстрее, создавать программы.

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

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

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


   Обозначим основные преимущества разработчика готовых продуктов, которые свойственны ему по определению.
     Профессионализм.  Разработчик интегрирует не только опыт многих разработок, но и многих «живых» систем, то есть реальных предприятий, которые ему пришлось автоматизировать.
     Реализм. Разработчик вынужден отчетливо представлять степень реализуемости задания, тем самым предохраняя заказчика от неоправданных затрат финансов и/или времени на нереализуемые проекты. Это самое важное преимущество.
Грубовато, но ярко обозначил эту ситуацию Себастиан Брандт в «Корабле дураков»:
        Наобещает Вам дурак,
        То, что свершить нельзя никак.
        Весь мир того не совершит,
        Что посулить дурак спешит.
     Ответственность. Разработчик рыночного продукта в отличие от собственного или случайного, несет перед заказчиком юридическую и финансовую ответственность в полном объеме.
     Экономическая целесообразность. Разработку системы для предприятия может выполнить только подготовленный коллектив, имеющий концептуальные, инструментальные и технологические заделы. На оснащение, обкатку и наработку всего этого уходит немало времени и средств, поэтому при относительно небольших планируемых сроках на эту работу (до двух лет) и несмотря на ее разовый характер на данном предприятии, разработка внешним опытным исполнителем будет стоить дешевле, чем собственным или случайным.
    К созданию своих коллективов разработчиков обычно тяготеют те фирмы, которые сами специализируются в этой или близких областях. Собирая или приглашая к себе коллектив разработчиков, они чаще всего имеют в виду, что выполнив работу для них, этот коллектив впоследствии создаст рыночный продукт, который окупит разработку и сохранит коллектив для последующих усовершенствований созданной программы.
   Конечно, резон в таком подходе есть, есть и  примеры успешной его реализации. Однако есть и обратные примеры.
   В общем случае, стимулы у коллектива, который находится «на прокорме» в организации (т.е. на постоянной зарплате), гораздо менее сильные, чем у фирмы, которая привлечена для выполнения конкретной работы за конкретное вознаграждение.

   Есть еще один психологический момент, связанный с разработкой, выполненной собственным коллективом.
   После того как работа выполнена и ее стали использовать на предприятии, база данных системы начинает очень быстро насыщаться информацией.
   Если концепция и средства разработки были выбраны неудачно, то это ведет к стремительному падению эффективности ее применения.
   Руководство в этом случае требует ее доработки, даже если понимает, что ущербна сама концепция системы. Приходится вкладывать все больше и больше средств, а желаемый эффект так и остается недостижимым.
   Разум подсказывает, что надо заказывать новую разработку, но страх и амбиции не позволяют это сделать. Ведь принять решение о создании или приобретении новой системы - значит, признать свою ошибку при принятии первоначального решения.
   А это всегда не просто.
   Если первоначальное решение было инициировано персоналом, то над ним будет довлеть страх увольнения.
   Если же это решение инициировал руководитель или владелец, то им может владеть стыд. Как же я такую глупость сотворил?! Но если я изменю свое решение, все будут считать меня дураком!)
   И он готов поддерживать деньгами свое глупое решение, пока не разорится...
 
   
   Приобрести книгу можно в интернет-магазине Озон  https://ozon.ru/t/p5D2PQC