Có ai đã làm chứng chỉ CSDP chưa? [đóng cửa]


15

Tôi đã xem xét một số chứng chỉ có khả năng nâng cao kiến ​​thức và giá trị thị trường của tôi với tư cách là Kỹ sư phần mềm. Chuyên gia phát triển phần mềm được chứng nhận (CSDP) của IEEE đã thu hút sự chú ý của tôi. Khi tôi tìm kiếm trên mạng cho bất kỳ trải nghiệm người dùng nào với nó, tôi không thể tìm thấy bất cứ điều gì đáng kể. Có vẻ không quá phổ biến. Và tôi chắc chắn chưa nghe thấy ai trong tổ chức hoặc bạn bè của tôi đã thực hiện nó.

Tôi muốn biết từ các thành viên cộng đồng nếu có ai đã làm chứng nhận này và kinh nghiệm của họ với điều tương tự. Là chứng nhận hữu ích về mặt kiến ​​thức. Có phải nó đã thêm trọng lượng vào sơ yếu lý lịch của bạn (không phải là trọng lượng!)?


1
computer.org/portal/web/certification/why_certify/employers có một danh sách các công ty sử dụng chủ sở hữu chứng chỉ CSDP; rõ ràng đó không phải là dấu hiệu rõ ràng về giá trị của nó, nhưng sẽ hữu ích đôi chút ...
Brian Driscoll

Nếu bạn muốn gây ấn tượng với tôi trong một bản lý lịch, thì hãy viết một trình biên dịch không tầm thường. Đó sẽ là đỉnh cao của tất cả mọi thứ bạn nên biết về lập trình.
Công việc

Câu trả lời:


14

Tôi hiện đang giữ chứng chỉ Liên kết phát triển phần mềm được chứng nhận của IEEE (CSDA) và tôi sẽ tham dự kỳ thi CSDP khi tôi đủ điều kiện (tôi vẫn cần ~ 2-3 năm kinh nghiệm).

Giống như bất kỳ chứng chỉ nào, đó chỉ là bằng chứng cho thấy bạn biết một số chủ đề nhất định, theo mẫu sách. Họ không thực sự nói nhiều về cách bạn sẽ thực hiện trong công việc. Lịch sử công việc trong quá khứ của bạn sẽ làm điều đó hiệu quả hơn nhiều.

Đối với tôi, tôi đã thi CSDA vì nó liên quan rất chặt chẽ với chương trình kỹ thuật phần mềm của trường đại học của tôi. Bằng cách tham gia và vượt qua kỳ thi, tôi xác nhận rằng tôi không chỉ biết các tài liệu liên quan đến lĩnh vực của mình theo chiều sâu và chiều rộng được ủy quyền bởi trường đại học của tôi (mà còn được chứng minh bằng việc hoàn thành chương trình cấp bằng), mà còn về độ sâu và chiều rộng được đề xuất bởi một tổ chức được quốc tế công nhận có kinh nghiệm và nền tảng kiến ​​thức sâu rộng trong lĩnh vực công nghệ phần mềm.

Làm thế nào các nhà tuyển dụng xem chứng chỉ rất khác nhau, giữa các ngành công nghiệp và tổ chức. Một số ngành công nghiệp ủng hộ một số chứng chỉ hơn những ngành khác. Các tổ chức cũng đặt trọng lượng riêng của họ đối với nhân viên quan điểm và các chứng chỉ họ nắm giữ. Trong các bình luận về câu hỏi của bạn, Brian Driscoll đã đăng một liên kết đến danh sách các công ty nắm giữ chứng chỉ CSDP / CSDA . Nếu bạn để ý, rất nhiều thứ liên quan đến quốc phòng, y học, viễn thông, tài chính và kỹ thuật nói chung (xây dựng hệ thống phần cứng). Đây là những ngành mà việc tuân thủ các quy định và kỹ thuật chính xác (khả năng chịu đựng thất bại hoặc khiếm khuyết thấp) rất quan trọng.

Nếu tôi sắp được chứng nhận, tôi chắc chắn sẽ xem xét các tổ chức được công nhận trên thế giới như Hiệp hội máy tính IEEE , Viện quản lý dự án (PMI) , Viện Kỹ thuật phần mềm tại Đại học Carnegie-Mellon , Hiệp hội chứng nhận bảo mật hệ thống thông tin (( ISC) 2) và các trường đại học cung cấp chứng chỉ chuyên môn / sau đại học trái ngược với các công ty đào tạo doanh nghiệp.

Khi bạn cân nhắc các chứng chỉ, bạn cần xác định nơi bạn muốn xuống và loại kiến ​​thức bạn cần phải có và cần chứng minh rằng bạn có. Ví dụ: chứng chỉ IEEE CSDP bao trùm bề rộng của công nghệ phần mềm - bạn đang thể hiện năng lực trong các chủ đề chính được xác định trong Cơ quan kiến ​​thức về Kỹ thuật phần mềm. Đó là một chứng nhận tốt, chung cho bất kỳ ai từ một nhà phát triển "xuống dốc" đến một người lãnh đạo phần mềm hoặc người quản lý dự án phần mềm. Tuy nhiên, SEI cung cấp các chứng chỉ chuyên sâu về các chủ đề như CMMI, quản lý quy trình và cải tiến quy trình (trong số nhiều thứ khác). Đối với một người như tôi, người làm việc trong ngành công nghiệp quốc phòng nơi tất cả các cầu thủ trải qua đánh giá CMMI, được đào tạo và chứng chỉ từ tổ chức phát triển CMMI và đào tạo các thẩm định viên CMMI có thể có giá trị. Nếu bạn không làm việc trong một tổ chức áp dụng CMMI, chứng chỉ này không có giá trị.


Cảm ơn Thomas, đó là một câu trả lời thực sự chi tiết và cân bằng. Tôi đã biết về một số chứng nhận SE cụ thể của từng quốc gia, nhưng không phải về Carnegie-Mellon. Tôi sẽ xem xét nó như một giải pháp thay thế cho CSDP
DPD

@DPD Những gì CMU cung cấp không phải là sự thay thế cho CDSP. Giống như CDSP của IEEE, chúng được công nhận trên toàn thế giới (đặc biệt là các chứng chỉ CMMI). Chúng được cấp bởi một tổ chức khác và không nhất thiết phải bắt nguồn từ Cơ quan Kiến thức Kỹ thuật phần mềm. Những gì SEI cung cấp chủ yếu là chứng nhận trong công việc họ làm. CSDP là một chứng chỉ phạm vi rộng bao trùm bề rộng của công nghệ phần mềm. Ngoại trừ các chứng chỉ CAPM và PMP của PMI (bao gồm hơi thở của quản lý dự án), các vấn đề khác đều hướng đến một chủ đề rất cụ thể, chi tiết.
Thomas Owens

Câu hỏi của tôi là bạn đã học CSDA như thế nào? Bất kỳ cuốn sách khóa học của chúng tôi có sẵn?
Jason Krs

@JasonKrs Tôi học ngành Kỹ thuật phần mềm để lấy bằng đại học và làm bài kiểm tra trong năm học cuối cùng. Các khóa học của tôi gần như trùng lặp chính xác với CSDA. Tôi gần như không học ngoài các khóa học của mình, ngoại trừ việc theo dõi một số nội dung từ những năm trước.
Thomas Owens

Được rồi ... Bạn vừa xóa câu hỏi của tôi (tôi biết rằng nó sẽ bị xóa ... lol) bạn sẽ trò chuyện với tôi Tôi muốn hỏi bạn vài thứ
Jason Krs

4

Đây là ngắn và ngọt ngào: Nó sẽ đạt được đà.

Rất nhiều nhà tuyển dụng đã tập trung rất nhiều vào kinh nghiệm trong quá khứ, các trường bạn đã đến và - vì thiếu một cách tốt hơn để nói "bị đốt cháy". Trái với niềm tin phổ biến, phát triển phần mềm gần như không phải là một nỗ lực sáng tạo mà nhiều người trong chúng ta trong công nghệ muốn tin tưởng. Trong các lĩnh vực mà nó cho phép và thậm chí đòi hỏi sự sáng tạo, nó thường đòi hỏi phải hiểu các câu chuyện / câu chuyện của người dùng cuối, yêu cầu hệ thống, lĩnh vực kinh doanh, kinh tế, quy trình công nghệ phần mềm và kiến ​​trúc phần mềm trước khi bạn bắt đầu xây dựng phần mềm [mã hóa].

Kể từ khi phong trào Agile trỗi dậy, sự đồng thuận đã bị nhầm lẫn khi đặt trọng tâm vào tiền mã hóa & nhà phát triển trước tiên. Đây thực sự là một sự giải thích sai về những gì các tác giả của Tuyên ngôn Agile đang cố gắng đạt được mặc dù có thể khó lượm lặt được điều đó từ Tuyên ngôn. Agile đã vay mượn rất nhiều từ và thậm chí trực tiếp áp dụng các nguyên tắc LEAN. LEAN tập trung vào nhân viên triển khai, nhưng chỉ từ góc độ thực tế là những cá nhân này gần nhất với khách hàng thực tế của công ty [ đọc: khách hàng hợp đồng ].

Tại sao sự phân biệt này lại quan trọng? Nhân viên thực hiện cảm thấy tác động của nhiều quyết định - cả tốt và xấu - trực tiếp. Do đó, chúng được định vị độc đáo để thực hiện các thay đổi đơn giản có thể có tác động lớn đến hiệu suất và chất lượng. Đáng buồn thay, họ thường không tham gia đầy đủ vào kiến ​​thức của họ về khách hàng cuối cùng, để lại nhiều cơ hội để cải thiện hiệu suất và chất lượng sản phẩm trên bàn. Nhiệm vụ của LEAN là luôn cung cấp giá trị lớn hơn cho khách hàng cuối bằng cách đạt được mức độ hiệu quả ngày càng cao thông qua việc loại bỏ chất thải làm tăng tốc độ giao hàng và cải thiện chất lượng. Agile đã đẩy phong bì về loại bỏ chất thải trong không gian xây dựng phần mềm, nhưng hiệu quả thực sự từ quan điểm của khách hàng cuối [cũng như người dùng cuối hợp đồng] là tối thiểu.

Cuối cùng, đáng chú ý là những thành tựu tích cực về tốc độ và chất lượng, chẳng hạn như sự cải thiện rõ rệt về Nghề thủ công mã [pha trộn khoa học và nghệ thuật] đã thúc đẩy chúng tôi tiến lên trên mặt trận xây dựng, nhưng trong quá trình chúng tôi đã đánh mất tầm nhìn quan trọng - khách hàng. Và tôi không có nghĩa chỉ là người dùng cuối, mà là khách hàng cuối cùng của doanh nghiệp. Giống như trong LEAN, mọi thứ bắt đầu từ khách hàng thực tế và hoạt động ngược. Vậy điều này có liên quan gì với CSDA & CSDP của IEEE? Rất nhiều.

Để bắt đầu, người ta thường bắt nguồn từ kiểu hiểu biết được phản ánh trong các ngành kỹ thuật để hoàn toàn nắm bắt rằng một quy trình phải luôn được tập trung vào mục tiêu tổng thể trong khi tính đến hiệu quả thực tế, các cột mốc và các thuộc tính chất lượng. Nếu bạn thiếu bất kỳ ai trong những đặc điểm đó, bạn sẽ không cung cấp đầy đủ giá trị cho khách hàng [doanh nghiệp] theo hợp đồng của mình, điều này có thể tạo ra một làn sóng các sự kiện làm giảm giá trị cho khách hàng của khách hàng cuối / công ty. Không tốt.

Hơn nữa, khả năng đảm nhận trách nhiệm lãnh đạo [mà nếu bạn có một nhóm tự định hướng {như nhiệm vụ Agile} đòi hỏi mọi người phải có khả năng dẫn đến một mức độ nào đó] thường đòi hỏi phải có bề rộng và hiểu biết sâu sắc về vấn đề trong tay, các chức năng mà nó tương tác với, cũng như khả năng truyền đạt kiến ​​thức này đến nhiều bên liên quan từ nhiều nền tảng khác nhau. Thực tế là cho dù mô tả trong công việc là gì, mọi người mong đợi rằng các nhà phát triển là các kỹ sư chuyên sâu. Rằng họ là những người thông minh, tài năng với bề rộng và chiều sâu cho các kỹ năng của họ, bao gồm việc làm chủ các hoạt động chính của họ, cũng như khả năng hiểu và giải quyết cho bất kỳ vấn đề nào của khách hàng theo hợp đồng.

Vậy tại sao ol lớn lại nói về Agile khi thảo luận về CSDA & CSDP? Đơn giản - Foundation. Nếu bạn có một nhóm CSDA và CSDP, ngay cả khi họ bị lừa bằng cách nào đó, họ vẫn sẽ có một số kiến ​​thức đúng đắn về tất cả các quy trình và kỷ luật trong Kỹ thuật phần mềm, tại sao họ lại ở đó và khi nào quay trở lại với họ như một phương tiện về sự thống nhất hiểu biết trước khi tiến về phía trước theo một hướng mới. Tổ chức đó sẽ tạo cơ hội phân phối các thực tiễn phát triển Phần mềm nhất quán, qua các phương pháp SDLC và khả năng xoay vòng giữa và / hoặc kết hợp các phương pháp SDLC khá dễ dàng. IEEE đã tạo ra một con đường cho các chuyên gia điện toán - cho dù là chuyên ngành kỹ thuật, sinh viên tốt nghiệp CS, chuyên gia CNTT hay nhà phát triển tự học - để thống nhất và thể hiện sự hiểu biết cơ bản về Phát triển phần mềm, Phân phối, và quy trình ngừng hoạt động như một môn học Kỹ thuật đáng được tôn trọng và cần được đối xử với sự trì hoãn. Và vì những yếu tố này, nó sẽ đạt được đà.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.