¿Alguien ha hecho la certificación CSDP? [cerrado]

Estaba buscando algunas certificaciones que potencialmente pueden mejorar mi conocimiento y valor de mercado como ingeniero de software. El profesional certificado en desarrollo de software (CSDP) del IEEE me llamó la atención. Cuando busqué en la red cualquier experiencia de usuario con él, no pude encontrar nada sustancial. No parece muy popular. Y ciertamente no he oído hablar de nadie en mi organización o círculo de amigos que lo haya hecho.

Me gustaría saber de los miembros de la comunidad si alguien ha hecho esta certificación y sus experiencias con la misma. ¿La certificación fue útil en términos de conocimiento? ¿Agregó peso a su currículum (no peso muerto)?

Actualmente tengo el certificado IEEE Certified Software Development Associate (CSDA) , y estaré listo para el examen CSDP cuando sea elegible (todavía necesito ~ 2-3 años de experiencia).

Al igual que cualquier certificado, es solo una prueba de que conoce ciertos temas, según el formulario del libro. Realmente no dicen mucho sobre cómo se desempeñará en el trabajo. Su historial de trabajo pasado lo hará con mucha más eficacia.

Para mí, tomé el CSDA porque se correlacionaba muy estrechamente con el programa de ingeniería de software de mi universidad. Al tomar y aprobar el examen, validé que no solo conocía el material relevante para mi campo de acuerdo con la profundidad y amplitud exigidas por mi universidad (lo cual se demuestra al completar el programa de grado), sino también con la profundidad y amplitud recomendado por una organización reconocida internacionalmente que tiene una amplia experiencia y una base de conocimientos en el campo de la ingeniería de software.

La forma en que los empleadores ven los certificados varía ampliamente entre industrias y organizaciones. Algunas industrias favorecen ciertas certificaciones sobre otras. Las organizaciones también ponen su propio peso hacia los empleados en perspectiva y los certificados que poseen. En los comentarios sobre su pregunta, Brian Driscoll publicó un enlace a una lista de empresas que poseen titulares de certificados CSDP / CSDA . Si observa, muchos están involucrados en defensa, medicina, telecomunicaciones, finanzas e ingeniería general (construcción de sistemas de hardware). Estas son industrias donde el cumplimiento de las regulaciones y la ingeniería de precisión (baja tolerancia a fallas o defectos) son importantes.

Si iba a obtener la certificación, definitivamente miraría organizaciones reconocidas mundialmente como la IEEE Computer Society , el Project Management Institute (PMI) , el Software Engineering Institute en la Carnegie-Mellon University , el Information Systems Security Certification Consortium (( ISC) 2) , y universidades que ofrecen certificados profesionales / graduados en comparación con las empresas que realizan capacitación corporativa.

Cuando esté sopesando las certificaciones, debe determinar dónde desea estar en el futuro y qué tipo de conocimiento necesita tener y demostrar que tiene. Por ejemplo, la certificación IEEE CSDP cubre la amplitud de la ingeniería de software: está demostrando competencia en los temas clave identificados en el Cuerpo de Conocimientos de Ingeniería de Software. Es una buena certificación general para cualquier persona, desde un desarrollador "en las trincheras" hasta un líder de software o gerente de proyecto de software. Sin embargo, el SEI ofrece certificados intensivos sobre temas como el CMMI, la gestión de procesos y la mejora de procesos (entre muchos otros). Para alguien como yo, que trabaja en la industria de defensa, donde todos los jugadores se someten a evaluaciones de CMMI, puede ser valioso obtener entrenamiento y un certificado de la organización que desarrolló CMMI y capacita a los evaluadores de CMMI. Si no está trabajando en una organización que aplica el CMMI, este certificado no es tan valioso.

Aquí está lo corto y lo dulce: va a ganar impulso.

Muchos empleadores han puesto mucho énfasis en la experiencia pasada, las escuelas a las que fuiste y, a falta de una mejor manera de decir "quemado". Contrariamente a la creencia popular, el desarrollo de software no es tan creativo como muchos de nosotros en tecnología quisiéramos creer. En las áreas en las que sí permite e incluso requiere creatividad, generalmente requiere comprender las personas / historias del usuario final, los requisitos del sistema, los dominios comerciales, la economía, el proceso de ingeniería de software y la arquitectura de software mucho antes de entrar en la construcción del software [codificación].

Desde el surgimiento del Movimiento Ágil, el consenso ha sido erróneamente poner énfasis en la codificación y el desarrollador primero. Esto en realidad ha sido una interpretación errónea de lo que los autores del Manifiesto Ágil estaban tratando de entender, aunque podría ser difícil deducir eso del Manifiesto. Agile ha tomado mucho prestado e incluso ha adoptado directamente los principios LEAN. LEAN se enfoca en el empleado de implementación, pero solo desde la perspectiva del hecho de que estas personas están más cercanas a los clientes reales de la empresa [ léase: cliente contractual ].

¿Por qué es importante esta distinción? Los empleados de implementación sienten el impacto de muchas decisiones, tanto buenas como malas, directamente. Como tales, están en una posición única para realizar cambios simples que pueden tener un impacto dramático en el rendimiento y la calidad. Lamentablemente, a menudo no están completamente comprometidos por su conocimiento del cliente final, dejando muchas oportunidades para mejorar el rendimiento y la calidad del producto sobre la mesa. La misión de LEAN es brindar un mayor valor al cliente final de manera consistente al lograr niveles cada vez mayores de efectividad a través de la eliminación de desechos, aumentando la velocidad de entrega y la mejora de la calidad. Agile empujó el sobre sobre la eliminación de desechos dentro del espacio de construcción del software, pero la verdadera efectividad desde la perspectiva del cliente final [así como la del usuario final del cliente contractual] ha sido mínima.

Con ese fin, vale la pena señalar que los logros positivos en velocidad y calidad, como una clara mejora en la Artesanía del Código [mezcla de ciencia y arte] nos han impulsado hacia el frente de la construcción, pero en el proceso hemos perdido de vista lo que es importante - el cliente Y no me refiero solo al usuario final, sino al cliente final de la empresa. Al igual que en LEAN, todo comienza desde el cliente real y avanza hacia atrás. Entonces, ¿qué tiene esto que ver con CSDA y CSDP de IEEE? Mucho.

Para comenzar, a menudo se necesita una persona que tenga sus raíces en el tipo de comprensión reflejada en las disciplinas de ingeniería para comprender que un proceso siempre debe centrarse en el objetivo general, teniendo en cuenta su eficacia real, hitos y atributos de calidad. Si le falta alguno de esos rasgos, no está entregando el valor total a su cliente contractual [de la empresa], lo que a su vez podría generar una ola de eventos que disminuyen el valor para los clientes finales / clientes de la empresa. No está bien.

Además, la capacidad de asumir responsabilidades de liderazgo [que si tiene un equipo autodirigido {como exige Agile} requiere que todos sean capaces de liderar hasta cierto punto] generalmente requiere una buena amplitud y profundidad de comprensión del tema en cuestión, el funciones con las que interactúa, así como la capacidad de comunicar este conocimiento a múltiples partes interesadas de una variedad de orígenes. La realidad es que, independientemente de la descripción del trabajo, la gente espera que los desarrolladores sean ingenieros en el fondo. Que son personas inteligentes y talentosas con amplitud y profundidad en sus habilidades, que incluyen el dominio de sus actividades principales, así como la capacidad de comprender y resolver el problema de cualquier cliente contractual.

Entonces, ¿por qué la gran queja sobre Agile cuando se habla de la CSDA y la PCSD? Simple - Fundación. Si tiene un equipo de CSDA y CSDP, incluso si de alguna manera hicieron trampa, todavía tendrán un conocimiento decente de dónde van todos los procesos y disciplinas dentro de Ingeniería de Software, por qué están allí y cuándo volver a ellos como un medio de unificar la comprensión antes de avanzar en una nueva dirección. Esa Fundación creará una oportunidad para la entrega constante de prácticas de desarrollo de Software, a través de metodologías SDLC y la capacidad de pivotar entre y / o combinar métodos SDLC con bastante facilidad. IEEE ha creado una vía para que los profesionales de la computación, ya sean estudiantes de ingeniería, graduados de CS, profesionales de TI o desarrolladores autodidactas, se unifiquen y demuestren una comprensión básica del desarrollo de software, entrega, y el proceso de desmantelamiento como una disciplina de ingeniería que es digna de respeto y debe tratarse con deferencia. Y debido a estos factores, ganará impulso.