Adakah yang sudah melakukan sertifikasi CSDP? [Tutup]

Saya melihat beberapa sertifikasi yang berpotensi meningkatkan pengetahuan dan nilai pasar saya sebagai Insinyur Perangkat Lunak. Profesional Pengembangan Perangkat Lunak Bersertifikat IEEE (CSDP) menarik perhatian saya. Ketika saya mencari di internet untuk setiap pengalaman pengguna dengan itu saya tidak dapat menemukan sesuatu yang substansial. Sepertinya tidak terlalu populer. Dan tentu saja saya belum pernah mendengar ada orang di organisasi saya atau teman-teman lingkaran yang telah melakukannya.

Saya ingin tahu dari anggota masyarakat apakah ada yang telah melakukan sertifikasi ini dan pengalaman mereka dengan hal yang sama. Apakah sertifikasi bermanfaat dalam hal pengetahuan. Apakah itu menambah bobot pada resume Anda (bukan bobot mati!)?

Saat ini saya memegang sertifikat Associate Pengembangan Perangkat Lunak (CSDA) IEEE , dan saya akan mengikuti ujian CSDP ketika saya memenuhi syarat (saya masih membutuhkan ~ 2-3 tahun pengalaman).

Seperti halnya sertifikat apa pun, itu hanya bukti bahwa Anda mengetahui topik tertentu, melalui formulir buku. Mereka tidak banyak bicara tentang bagaimana Anda akan melakukan pekerjaan. Riwayat kerja masa lalu Anda akan melakukannya dengan jauh lebih efektif.

Bagi saya, saya mengambil CSDA karena berkorelasi sangat erat dengan program rekayasa perangkat lunak universitas saya. Dengan mengikuti dan lulus ujian, saya memvalidasi bahwa saya tidak hanya mengetahui materi yang relevan dengan bidang saya dengan kedalaman dan luas yang diamanatkan oleh universitas saya (yang dibuktikan dengan selesainya program gelar), tetapi juga untuk kedalaman dan luasnya direkomendasikan oleh organisasi yang diakui secara internasional yang memiliki pengalaman dan basis pengetahuan yang luas di bidang rekayasa perangkat lunak.

Cara pengusaha melihat sertifikat sangat bervariasi, antara industri dan organisasi. Beberapa industri lebih menyukai sertifikasi tertentu daripada yang lain. Organisasi juga menempatkan bobot mereka sendiri terhadap karyawan perspektif dan sertifikat yang mereka pegang. Dalam komentar pada pertanyaan Anda, Brian Driscoll memposting tautan ke daftar perusahaan yang memiliki pemegang sertifikat CSDP / CSDA . Jika Anda perhatikan, banyak yang terlibat dalam pertahanan, kedokteran, telekomunikasi, keuangan, dan teknik umum (membangun sistem perangkat keras). Ini adalah industri di mana kepatuhan terhadap peraturan dan rekayasa presisi (toleransi rendah terhadap kegagalan atau cacat) adalah penting.

Jika saya akan mendapatkan sertifikasi, saya pasti akan melihat organisasi yang diakui dunia seperti IEEE Computer Society , Project Management Institute (PMI) , Institut Rekayasa Perangkat Lunak di Universitas Carnegie-Mellon , Konsorsium Sertifikasi Keamanan Sistem Informasi (( ISC) 2) , dan universitas yang menawarkan sertifikat profesional / lulusan sebagai lawan dari perusahaan yang melakukan pelatihan perusahaan.

Ketika Anda mempertimbangkan sertifikasi, Anda perlu menentukan di mana Anda ingin berada di ujung jalan dan jenis pengetahuan apa yang Anda perlu miliki dan perlu menunjukkan bahwa Anda memiliki. Misalnya, sertifikasi IEEE CSDP mencakup luasnya rekayasa perangkat lunak - Anda menunjukkan kompetensi dalam topik-topik utama yang diidentifikasi dalam Badan Rekayasa Perangkat Lunak Pengetahuan. Ini adalah sertifikasi umum yang baik untuk siapa saja mulai dari pengembang "di parit" hingga pemimpin perangkat lunak atau manajer proyek perangkat lunak. Namun, SEI menawarkan sertifikat intensif tentang topik-topik seperti CMMI, manajemen proses, dan peningkatan proses (di antara banyak lainnya). Bagi seseorang seperti saya, yang bekerja di industri pertahanan di mana semua pemain menjalani penilaian CMMI, mendapatkan pelatihan dan sertifikat dari organisasi yang mengembangkan CMMI dan melatih penilai CMMI mungkin berharga. Jika Anda tidak bekerja di organisasi yang menerapkan CMMI, sertifikat ini tidak terlalu berharga.

Inilah yang singkat dan manis: Ini akan mendapatkan momentum.

Banyak majikan telah memberikan penekanan besar pada pengalaman masa lalu, sekolah-sekolah yang Anda kunjungi, dan - karena tidak ada cara yang lebih baik untuk mengatakan "terbakar". Berlawanan dengan kepercayaan populer, pengembangan perangkat lunak hampir tidak sama kreatifnya dengan usaha keras yang ingin diyakini oleh banyak orang di bidang teknologi. Di bidang yang memang memungkinkan dan bahkan membutuhkan kreativitas, biasanya diperlukan pemahaman tentang karakter / cerita pengguna akhir, persyaratan sistem, domain bisnis, ekonomi, proses rekayasa perangkat lunak, dan arsitektur perangkat lunak sebelum Anda memasuki konstruksi [koding] perangkat lunak.

Sejak Munculnya Gerakan Agile, konsensus telah keliru untuk menempatkan penekanan pada pengkodean & pengembang terlebih dahulu. Ini sebenarnya merupakan salah tafsir tentang apa yang coba diupayakan oleh penulis Agile Manifesto meskipun mungkin sulit untuk mendapatkannya dari Manifesto. Agile telah meminjam banyak dari dan bahkan secara langsung mengadopsi prinsip-prinsip LEAN. LEAN memang fokus pada karyawan pelaksana, tetapi hanya dari perspektif fakta bahwa orang-orang ini paling dekat dengan pelanggan aktual perusahaan [ baca: klien kontraktual ].

Mengapa perbedaan ini penting? Karyawan implementasi merasakan dampak dari banyak keputusan - baik dan buruk - secara langsung. Dengan demikian, mereka diposisikan secara unik untuk membuat perubahan sederhana yang dapat memiliki dampak dramatis pada kinerja dan kualitas. Sayangnya, mereka sering tidak sepenuhnya terlibat untuk pengetahuan mereka tentang konsumen akhir, meninggalkan banyak peluang untuk meningkatkan kinerja dan kualitas produk. Misi LEAN adalah untuk secara konsisten memberikan nilai lebih kepada pelanggan akhir dengan mencapai tingkat efektivitas yang semakin meningkat melalui pembuangan limbah yang meningkatkan kecepatan pengiriman dan peningkatan kualitas. Agile mendorong amplop pada pembuangan limbah dalam ruang konstruksi perangkat lunak, tetapi efektivitas sebenarnya dari pelanggan akhir [serta pengguna akhir klien kontrak] sangat minim.

Untuk itu, perlu dicatat pencapaian positif dalam kecepatan & kualitas seperti peningkatan yang jelas dalam Pengerjaan Kode [memadukan ilmu pengetahuan dan seni] telah mendorong kami maju di bidang konstruksi, tetapi dalam prosesnya kami telah kehilangan pandangan tentang apa yang ada. penting - pelanggan. Dan yang saya maksud bukan hanya pengguna akhir, tetapi pelanggan akhir perusahaan. Sama seperti di LEAN, semuanya dimulai dari pelanggan aktual dan bekerja dengan cara mundur. Jadi apa hubungannya dengan CSDA & CSDP IEEE? Banyak.

Untuk memulainya, sering dibutuhkan seseorang yang berakar pada jenis pemahaman yang tercermin dalam disiplin ilmu teknik untuk sepenuhnya memahami bahwa suatu proses harus selalu difokuskan pada tujuan keseluruhan sambil memperhitungkan efektivitas, tonggak & atribut kualitas aktualnya. Jika Anda kehilangan salah satu dari sifat-sifat itu, Anda kurang memberikan nilai penuh kepada klien [perusahaan] kontraktual Anda, yang pada gilirannya dapat menghasilkan gelombang pasang peristiwa yang menurunkan nilai kepada pelanggan akhir / klien perusahaan. Tidak baik.

Lebih jauh, kemampuan untuk memikul tanggung jawab kepemimpinan [yang jika Anda memiliki tim yang diarahkan sendiri {seperti mandat Agile} mengharuskan setiap orang mampu memimpin hingga tingkat tertentu] biasanya membutuhkan keluasan dan kedalaman pemahaman yang baik tentang materi pelajaran yang ada, fungsi yang berinteraksi dengannya, serta kemampuan untuk mengkomunikasikan pengetahuan ini kepada banyak pemangku kepentingan dari berbagai latar belakang. Kenyataannya adalah bahwa apa pun yang ada dalam deskripsi pekerjaan tersebut, orang berharap bahwa pengembang adalah insinyur yang mendalam. Bahwa mereka adalah orang-orang yang cerdas dan berbakat dengan keluasan dan kedalaman keterampilan mereka, yang meliputi penguasaan kegiatan utama mereka, serta kemampuan untuk memahami dan menyelesaikan untuk domain masalah klien kontrak apa pun.

Jadi mengapa masalah besar tentang Agile saat membahas CSDA & CSDP? Simple - Foundation. Jika Anda memiliki tim CSDA dan CSDP, bahkan jika mereka curang, mereka masih akan memiliki pengetahuan yang layak tentang ke mana perginya semua proses dan disiplin dalam Rekayasa Perangkat Lunak, mengapa ada, dan kapan mengembalikannya sebagai sarana. mempersatukan pemahaman sebelum bergerak maju ke arah yang baru. Foundation itu akan menciptakan peluang untuk pengiriman praktik pengembangan perangkat lunak yang konsisten, melintasi metodologi SDLC dan kemampuan untuk berputar di antara dan / atau menggabungkan metode SDLC dengan cukup mudah. IEEE telah menciptakan jalan bagi para profesional komputasi - apakah jurusan teknik, lulusan CS, pro IT, atau pengembang otodidak - untuk menyatukan dan menunjukkan pemahaman dasar tentang Pengembangan Perangkat Lunak, Pengiriman, dan proses dekomisioning sebagai disiplin ilmu teknik yang layak dihormati dan harus diperlakukan dengan hormat. Dan karena faktor-faktor ini, itu akan mendapatkan momentum.