Quelqu'un a-t-il fait la certification CSDP? [fermé]

Je cherchais des certifications qui peuvent potentiellement améliorer mes connaissances et ma valeur commerciale en tant qu'ingénieur logiciel. Le professionnel certifié de développement logiciel (CSDP) de l' IEEE a attiré mon attention. Lorsque j'ai cherché sur le net des expériences utilisateur avec, je n'ai rien trouvé de substantiel. Cela ne semble pas trop populaire. Et je n'ai certainement entendu parler d'aucun membre de mon organisation ou de mes amis qui l'ait fait.

J'aimerais savoir auprès des membres de la communauté si quelqu'un a fait cette certification et leurs expériences avec celle-ci. La certification était-elle utile en termes de connaissances. A-t-il ajouté du poids à votre CV (pas un poids mort!)?

Je détiens actuellement le certificat IEEE Certified Software Development Associate (CSDA) et je passerai l'examen CSDP lorsque je serai éligible (j'ai encore besoin de 2 à 3 ans d'expérience).

Comme tout certificat, ce n'est que la preuve que vous connaissez certains sujets, par la forme du livre. Ils ne disent pas grand-chose sur la façon dont vous vous comporterez au travail. Vos antécédents professionnels le feront beaucoup plus efficacement.

Pour moi, j'ai suivi le CSDA parce qu'il était très étroitement lié au programme de génie logiciel de mon université. En prenant et en réussissant l'examen, j'ai validé que non seulement je connaissais le matériel pertinent dans mon domaine à la profondeur et à l'étendue prescrites par mon université (ce qui est prouvé par l'achèvement du programme d'études), mais aussi à la profondeur et à l'étendue recommandé par une organisation de renommée internationale qui possède une vaste expérience et une base de connaissances dans le domaine du génie logiciel.

La façon dont les employeurs perçoivent les certificats varie considérablement selon les industries et les organisations. Certaines industries privilégient certaines certifications par rapport à d'autres. Les organisations accordent également leur propre poids aux employés en perspective et aux certificats qu'ils détiennent. Dans les commentaires sur votre question, Brian Driscoll a publié un lien vers une liste d'entreprises détenant des certificats CSDP / CSDA . Si vous remarquez, beaucoup sont impliqués dans la défense, la médecine, les télécommunications, la finance et l'ingénierie générale (systèmes de matériel de construction). Ce sont des industries où la conformité aux réglementations et l'ingénierie de précision (faible tolérance aux pannes ou défauts) sont importantes.

Si je voulais obtenir une certification, je regarderais certainement des organisations de renommée mondiale telles que l' IEEE Computer Society , le Project Management Institute (PMI) , le Software Engineering Institute de l'Université Carnegie-Mellon , le Information Systems Security Certification Consortium (( ISC) 2) et les universités qui offrent des certificats professionnels / diplômés par opposition aux entreprises qui dispensent une formation en entreprise.

Lorsque vous pesez les certifications, vous devez déterminer où vous voulez être sur la route et quel type de connaissances vous devez avoir et devez démontrer que vous en avez. Par exemple, la certification IEEE CSDP couvre toute l'étendue du génie logiciel - vous démontrez vos compétences dans les sujets clés identifiés dans le corpus de connaissances en génie logiciel. C'est une bonne certification générale pour quiconque, du développeur "dans les tranchées" au responsable logiciel ou au chef de projet logiciel. Cependant, le SEI propose des certificats intensifs sur des sujets tels que le CMMI, la gestion des processus et l'amélioration des processus (parmi beaucoup d'autres). Pour quelqu'un comme moi, qui travaille dans l'industrie de la défense où tous les joueurs subissent des évaluations CMMI, obtenir une formation et un certificat de l'organisation qui a développé CMMI et forme les évaluateurs CMMI pourrait être utile. Si vous ne travaillez pas dans une organisation qui applique le CMMI, ce certificat n'est pas si précieux.

Voici le court et le doux: il va prendre de l'ampleur.

Beaucoup d'employeurs ont beaucoup insisté sur l'expérience passée, les écoles dans lesquelles vous êtes allé, et - faute d'une meilleure façon de dire «brûlé». Contrairement à la croyance populaire, le développement de logiciels n'est pas aussi créatif que beaucoup d'entre nous en technologie aimeraient le croire. Dans les domaines où cela permet et même requiert de la créativité, cela nécessite généralement de comprendre les personnages / histoires des utilisateurs finaux, les exigences du système, les domaines d'activité, l'économie, les processus d'ingénierie logicielle et l'architecture logicielle bien avant de vous lancer dans la construction de logiciels [codage].

Depuis la montée du mouvement Agile, le consensus a été à tort de mettre l'accent sur le codage et le développement en premier. Cela a en fait été une interprétation erronée de ce que les auteurs du Manifeste Agile essayaient de comprendre, bien qu'il puisse être difficile de glaner cela dans le Manifeste. Agile a beaucoup emprunté et même adopté directement les principes LEAN. LEAN se concentre sur l'employé chargé de la mise en œuvre, mais uniquement du point de vue du fait que ces personnes sont les plus proches des clients réels de l'entreprise [ lire: client contractuel ].

Pourquoi cette distinction est-elle importante? Les employés chargés de la mise en œuvre ressentent directement l'impact de nombreuses décisions, bonnes ou mauvaises. En tant que tels, ils sont particulièrement bien placés pour apporter des modifications simples qui peuvent avoir un impact spectaculaire sur les performances et la qualité. Malheureusement, ils ne sont souvent pas pleinement engagés pour leur connaissance du client final, laissant sur la table de nombreuses opportunités d'améliorer les performances et la qualité des produits. La mission de LEAN est de toujours fournir une plus grande valeur au client final en atteignant des niveaux d'efficacité toujours plus élevés grâce à l'élimination des déchets, ce qui augmente la vitesse de livraison et l'amélioration de la qualité. Agile a repoussé les limites de l'élimination des déchets dans l'espace de construction de logiciels, mais la véritable efficacité du point de vue du client final [ainsi que de l'utilisateur final du client contractuel] a été minime.

À cette fin, il convient de noter les réalisations positives en termes de vitesse et de qualité, telles qu'une nette amélioration de l'artisanat du code [alliant science et art] nous a fait avancer sur le front de la construction, mais dans le processus, nous avons perdu de vue ce qui est important - le client. Et je ne parle pas seulement de l'utilisateur final, mais du client final de l'entreprise. Tout comme dans LEAN, tout part du client réel et revient en arrière. Alors qu'est-ce que cela a à voir avec le CSDA et le CSDP de l'IEEE? Beaucoup.

Pour commencer, il faut souvent une personne qui est enracinée dans le type de compréhension reflété dans les disciplines d'ingénierie pour bien comprendre qu'un processus doit toujours être axé sur l'objectif global tout en tenant compte de son efficacité réelle, de ses jalons et de ses attributs de qualité. Si vous manquez l'un de ces traits, vous ne parvenez pas à fournir la pleine valeur à votre client contractuel [d'entreprise], ce qui pourrait à son tour générer un raz de marée qui diminue la valeur pour les clients finaux / clients de l'entreprise. Pas bon.

En outre, la capacité à assumer des responsabilités de leadership [qui, si vous avez une équipe autogérée {en tant que mandats Agile}, exige que tout le monde soit capable de diriger dans une certaine mesure] nécessite généralement une bonne étendue et une profonde compréhension du sujet traité, le fonctions avec lesquelles il interagit, ainsi que la capacité de communiquer ces connaissances à de multiples parties prenantes issues d'horizons divers. La réalité est que, quelle que soit la description du travail, les gens s'attendent à ce que les développeurs soient des ingénieurs au fond. Qu'ils sont des personnes intelligentes et talentueuses avec une étendue et une profondeur de leurs compétences, ce qui inclut la maîtrise de leurs activités principales, ainsi que la capacité de comprendre et de résoudre le domaine de problème de tout client contractuel.

Alors, pourquoi le gros ol rant d'Agile lors de la discussion du CSDA & CSDP? Simple - Fondation. Si vous avez une équipe de CSDA et de CSDP, même s'ils ont en quelque sorte triché, ils auront toujours une bonne connaissance de où vont tous les processus et disciplines du génie logiciel, pourquoi ils sont là et quand y revenir comme moyen d'unifier la compréhension avant de marcher dans une nouvelle direction. Cette fondation créera une opportunité pour la mise en œuvre cohérente des pratiques de développement de logiciels, à travers les méthodologies SDLC et la capacité de pivoter entre et / ou combiner des méthodes SDLC assez facilement. L'IEEE a créé une avenue pour les professionnels de l'informatique - qu'ils soient des ingénieurs majeurs, des diplômés CS, des professionnels de l'informatique ou des développeurs autodidactes - pour unifier et démontrer une compréhension de base du développement, de la livraison de logiciels, le processus de déclassement en tant que discipline d'ingénierie qui mérite d'être respectée et doit être traitée avec déférence. Et en raison de ces facteurs, il prendra de l'ampleur.