Гoсподам программерам или 5000 человек-месяц.

[Nikita]

По мотивам дискуссии позволю себе высказаться. Я работаю на одну "широко известную в узких кругах" зарубежную компанию, занятую в telecom-бизнесе. В частности, я участвую в разработке ПО для GSM-телефонии. Хочу внести свою лепту в обсуждение.

Это письмо – отклик на личный опыт нашего читателя "Какие мозги нужны программисту" – ред.

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

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

Во-первых, по поводу доли участия системных аналитиков в разработке ПО на примере нашей компании. У нас (в нашем отделении) есть прекрасные аналитики. Как русские, так и партнеры-французы.

Они разрабатывают прекрасные вещи с точки зрения архитектуры. Но это все должно быть согласовано с тем, что уже есть – уже выпущено более 10 версий продукта и сильные изменения не допускаются.


Потом все это должно быть согласовано с так называемыми project line менеджерами – людьми, определяющими, что (какие новые возможности) и когда будет продано – в этой версии, в следующей или во время очередного patch-обновления.

После согласования с предыдущими версиями и с project line management архитектура уже получается изуродованной. Затем слово берут тестеры. Если они говорят, что не успеют что-то протестировать – это что-то выкидывается, причем никто не утруждает себя соблюдением целостности архитектуры. В моей практике был случай, когда выкинули ту часть программного компонента, ради которого собственно компонент и создавался. А всю остальную косметику оставили!

К моменту начала кодирования архитектура доходит в таком виде, что понять первоначальный замысел могут далеко не все.


Кодирование – это отдельная песня. Начиная с выпуска альфа-версии весь контроль над изменениями берут на себя тестеры – все, что им не по нраву или они не успевают протестировать, они запрещают. Даже те изменения, которые очевидно и значительно улучшают качество продукта.

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

Во-вторых, собственно по поводу образования программистов. Я по образованию математик (факультет ВМиК). У нас работают также радиофизики и "инженеры-программисты" – выпускники политеха, которые выучивают четыре языка (один из них С++) за три года в соответствии с учебным планом.

Могу сказать, что все архитекторы – выпускники ВМиК. Радиофизики тоже могут решать архитектурные задачи, но они очень мало задумываются над оптимизацией кода, как следствие, то, что они написали, очень быстро становится "unsupportable". На то, что творят выпускники политеха, без слез не взглянешь. Так что какое-никакое профильное образование должно быть.

Другое дело, что у нас мало computer science. Но у математиков есть преимущество – они более-менее представляют, где можно научиться самим.


Остальные измеряют качество образования программиста только количеством языков, синтаксис которых человек знает.

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

В общем, я считаю, что при написании программ имели, имеют и будут иметь место серьезные требования к квалификации программистов. Я также считаю, что эти требования не будут и не должны предъявляться ко всем программистам. Если воспользоваться удачной аналогией – есть санитары, есть медсестры, а есть врачи высочайшей квалификации.

Маленькие программерские группы максимум 10 человек ... это то что надо для счастья !
И как они умудряются вообще что либо производить да еще и деньги зарабатывать. Я думаю что в таких организациях не о программерах нужно говорить а о мэнеджерах ... это в натуре мастера своего дела !

[Reckon_]

Здесь был мой пост.

[Agregat]

Выскажусь касательно вузов. В Киеве например я говорил с ребятами, там ВТ куда лучше, чем Универ по нашей специальности. В Москве, наскока я могу судить наоборот. В Ереване странный паритет... на мой скромый ИMNSHO

[Hans Andersen]

Originally Posted by accemic26

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

[Nikita]

Агрегат.
А как ты думаеш, какой ВУЗ Армении дает лучших специалистов в сфере ИТ ? Если конечно размазать различия между программами.
Ну например если сравнить ВТ политехнического, Прикладную математику ЕГУ, и например Славянский универ, который не смотря на ярмо кооператива выпускает не плохих специалистов.

[Agregat]

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

[Pascal]

[MODERATORIAL]
Voprosy kompetentnosti userov obsuzhdayutsya v private.
V sleduyushiy raz zakroyu topic.

Regards

[Agregat]

ладно отмодерирую я сам оба поста.

[tig]

Originally Posted by Reckon_

Здесь был мой пост.

что ж ты так ? хороший же пост был

интересно, автор догадываеться вообще о технологиях организации процесса производства програмного продукта ?

[Nikita]

За непрерывным потоком сенсационных сообщений о новинках как-то незаметно теряется смысл того, что происходит сейчас в информационных технологиях. А происходит очередной диалектический кризис программирования.



Пятый кризис



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



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



Сейчас мы переживаем пятый кризис, причина которого - массовое внедрение ИТ в бизнес и быт и широкое распространение распределенных систем. Нынешнее время - это время повсеместного использования ИС. Потребность в индивидуальных приложениях составляет миллионы экземпляров. Кому из рядовых пользователей нужны операционные системы или СУБД сами по себе? Кого они интересуют? Как правило, большинство пользователей и не осознает, что пользуется ОС: «Что ты делаешь на компьютере? - Баланс считаю и документы в «Ворде» готовлю». Пользователя интересуют прикладные функции ИС: управление документооборотом, планирование ресурсов предприятия, взаимодействие с клиентами и поставщиками и т. п.



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



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



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



Таким образом, технология разработки ИС проходит три этапа: эзотерическое искусство, доступное единицам; наука, овладение которой по силам многим, но требует длительного времени; наконец, массовое ремесло. Значит ли это, что программирование как искусство умрет? Скорее всего, нет. Просто потребность в высокоталантливых, выдающихся программистах придет в соответствие с числом этих программистов - их ведь, мягко говоря, не много. Уже сейчас можно наблюдать тенденцию к разделению функций для тех, кто занимается созданием ИТ:



программисты: разработка инструментальных и системных средств (операционные системы, компиляторы, СУБД и т. п.). Требование к квалификации - знания в области математических основ функционирования и архитектуры вычислительных систем;



разработчики ИС: проектирование логики работы системы, организация информационных потоков и т. п.

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


Отдельной третьей профессией, возможно, станет:



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



Цена многообразия



Чем больше требуется ИС, тем дороже обходится многообразие базовых программно-аппаратных средств. Разработчикам приходится поддерживать параллельно и одновременно версии одной и той же ИС, предназначенной для разных архитектур, разных ОС и разных СУБД. Каждый из этих элементов программно-аппаратной платформы требует своей команды квалифицированных специалистов-разработчиков; в систему приходится вносить зависящие от платформы изменения, которые не всегда работают так же, как на той платформе, где система разрабатывалась. Все это приводит к значительным затратам еще на уровне разработки.



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



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



В результате сложилась тенденция уменьшения количества различных платформ, в полном соответствии с принципом Оккама: «не умножайте сущностей сверх необходимости». И сегодня мы видим, что из всего многообразия ОС осталось практически две (семейства UNIX и Microsoft Windows), число профессиональных СУБД тоже постепенно сокращается, да и на рынке микропроцессоров осталось лишь несколько архитектур. Хочется подчеркнуть важную мысль: унификация - следствие объективного процесса развития ИТ, обусловленного требованиями потребителей, требованиями рынка. В то же время опыт показывает: станет ли тот или иной элемент платформы (аппаратная архитектура, ОС, СУБД) стандартом де-факто, зависит не от технического совершенства этого элемента, а от его распространения (installed base).



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



Закрытие технических решений или установление монопольно высоких цен на тот или иной элемент платформы парадоксальным образом ведет к потере монополии из-за появления открытой или более дешевой альтернативы. Именно так архитектура IBM PC вытеснила другие архитектуры вначале с рынка ПК, а затем и серверов, именно так развиваются сегодня события на рынке ОС.



Куда мы идем?



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



Есть основания полагать, что в ближайшее десятилетие мы увидим следующее:



стоимость аппаратных средств будет продолжать снижаться;



стоимость ОС, основных инструментальных средств разработчика и СУБД упадет до нуля;



значительная часть прикладных программных систем непроизводственного назначения (включая средства обработки мультимедийной информации) и так называемые офисные пакеты войдут в состав ОС и будут распространяться бесплатно;



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



после этого стоимость таких унифицированных систем тоже начнет снижаться, падая до нуля для массовых секторов (бухгалтерские программы, системы CAD и др.);



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



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