Кто-нибудь прошел сертификацию CSDP? [закрыто]

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

Я хотел бы узнать от членов сообщества, прошел ли кто-нибудь этот сертификат и их опыт работы с ним. Была ли сертификация полезна с точки зрения знаний. Это добавило вес вашему резюме (не дедвейту!)?

В настоящее время у меня есть сертификат IEEE Certified Software Development Associate (CSDA) , и я буду сдавать экзамен CSDP, когда у меня будет право (мне все еще нужно ~ 2-3 года опыта).

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

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

То, как работодатели рассматривают сертификаты, широко варьируется между отраслями и организациями. Некоторые отрасли предпочитают определенные сертификаты другим. Организации также придают большое значение перспективным сотрудникам и имеющимся сертификатам. В комментариях к вашему вопросу Брайан Дрисколл опубликовал ссылку на список компаний, имеющих владельцев сертификатов CSDP / CSDA . Если вы заметили, многие вовлечены в оборону, медицину, телекоммуникации, финансы и общее машиностроение (создание аппаратных систем). Это отрасли, в которых важно соблюдение правил и точное проектирование (низкая устойчивость к сбоям или дефектам).

Если бы я собирался пройти сертификацию, я бы определенно посмотрел на всемирно признанные организации, такие как IEEE Computer Society , Институт управления проектами (PMI) , Институт разработки программного обеспечения в Университете Карнеги-Меллона , Консорциум по сертификации безопасности информационных систем (( ISC) 2) , а также университеты, которые предлагают профессиональные / дипломные сертификаты, в отличие от компаний, которые проводят корпоративное обучение.

Когда вы взвешиваете сертификаты, вам необходимо определить, где вы хотите быть в будущем, и какие знания вам нужно иметь и должны продемонстрировать, что у вас есть. Например, сертификация IEEE CSDP охватывает широкий спектр разработки программного обеспечения - вы демонстрируете компетентность в ключевых темах, определенных в Своде знаний по разработке программного обеспечения, Это хорошая, общая сертификация для любого, от разработчика "в окопах" до руководителя программного обеспечения или менеджера программных проектов. Однако SEI предлагает интенсивные сертификаты по таким темам, как CMMI, управление процессами и улучшение процессов (среди многих других). Для кого-то вроде меня, который работает в оборонной промышленности, где все игроки проходят аттестацию CMMI, получение обучения и сертификат от организации, которая разработала CMMI и обучает оценщиков CMMI, может быть ценной. Если вы не работаете в организации, которая применяет CMMI, этот сертификат не так уж ценен.

Вот краткое и сладкое: оно будет набирать обороты.

Многие работодатели уделяют большое внимание прошлому опыту, школам, в которые вы ходили, и - из-за отсутствия лучшего способа сказать «сгорел». Вопреки распространенному мнению, разработка программного обеспечения далеко не так творчески, как хотелось бы верить многим из нас в области технологий. В тех областях, где это допускает и даже требует творчества, обычно требуется понимание персон / историй конечного пользователя, системных требований, бизнес-областей, экономики, процессов разработки программного обеспечения и архитектуры программного обеспечения задолго до того, как вы приступите к разработке программного обеспечения [кодирование].

С момента появления Agile-движения консенсус ошибочно ставит акцент на программирование и разработчиков в первую очередь. На самом деле это было неверным истолкованием того, к чему пытались добраться авторы Agile Manifesto, хотя, возможно, было бы трудно подобрать это из Manifesto. Agile активно заимствовал и даже непосредственно принял принципы LEAN. LEAN фокусируется на сотруднике, занимающемся внедрением, но только с точки зрения того факта, что эти лица наиболее близки к фактическим клиентам [ читай: договорный клиент ].

Почему это различие важно? Сотрудники внедрения напрямую ощущают влияние многих решений - как хороших, так и плохих. Таким образом, они имеют уникальные возможности для внесения простых изменений, которые могут оказать существенное влияние на производительность и качество. К сожалению, они часто не в полной мере заинтересованы в своих знаниях о конечном клиенте, оставляя много возможностей для повышения производительности и качества продукции на столе. Миссия LEAN состоит в том, чтобы постоянно повышать ценность для конечного потребителя путем достижения все более высоких уровней эффективности за счет удаления отходов, увеличения скорости доставки и улучшения качества. Agile расширил возможности удаления отходов в пространстве разработки программного обеспечения, но реальная эффективность с точки зрения конечного пользователя [и конечного пользователя по контракту] была минимальной.

В связи с этим стоит отметить положительные достижения в скорости и качестве, такие как явное улучшение в Code Craftsmanship [смешение науки и искусства], которые продвинули нас вперед в области строительства, но в процессе мы потеряли из виду то, что главное - заказчик. И я имею в виду не только конечного пользователя, но и конечного потребителя предприятия. Как и в LEAN, все начинается с фактического клиента и работает в обратном направлении. Так какое это имеет отношение к CSDA и CSDP IEEE? Много.

Начнем с того, что человеку, укоренившемуся в типе понимания, отраженном в инженерных дисциплинах, часто требуется полное понимание того, что процесс всегда должен быть сосредоточен на общей цели с учетом его фактической эффективности, основных этапов и качественных характеристик. Если вам не хватает какой-либо из этих черт, вы не в состоянии предоставить полную стоимость вашему клиенту по контракту [предприятие], что, в свою очередь, может вызвать волну событий, которые уменьшают ценность для клиентов конечных клиентов / фирмы. Не хорошо.

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

Так почему же сплетничают о Agile при обсуждении CSDA и CSDP? Простое - фундамент. Если у вас есть команда CSDA и CSDP, даже если они каким-то образом обманули, они все равно будут иметь приличные знания о том, куда идут все процессы и дисциплины в Software Engineering, почему они существуют и когда возвращаться к ним в качестве средства. объединения понимания, прежде чем идти вперед в новом направлении. Этот Фонд создаст возможность для последовательной доставки методов разработки Программного обеспечения в рамках методологий SDLC и способности достаточно легко перемещаться между и / или комбинировать методы SDLC. IEEE создал канал для профессионалов в области вычислительной техники - будь то инженерные специальности, выпускники CS, ИТ-специалисты или разработчики-самоучки - чтобы объединить и продемонстрировать базовое понимание разработки программного обеспечения, поставки, и процесс вывода из эксплуатации как инженерная дисциплина, которая заслуживает уважения и должна восприниматься с уважением. И из-за этих факторов он будет набирать обороты.