Quy định của ngành công nghiệp phần mềm [đóng]


85

Cứ vài năm lại có người đề xuất quy định chặt chẽ hơn cho ngành công nghiệp phần mềm.

Bài viết này của IEEE đã được chú ý gần đây về chủ đề này.

Nếu các kỹ sư phần mềm viết chương trình cho các hệ thống khiến công chúng gặp rủi ro về vật chất hoặc tài chính biết rằng họ sẽ được kiểm tra dựa trên năng lực của họ, thì suy nghĩ sẽ giảm bớt những sai sót và thất bại trong mã số và có thể cứu được một vài mạng sống.

Tôi nghi ngờ về giá trị và giá trị của việc này. Đối với tôi, nó trông giống như một vùng đất của những người đề xuất nó.

Câu trích dẫn dành cho tôi là:

Bài kiểm tra sẽ kiểm tra kiến ​​thức cơ bản, không nắm vững vấn đề

bởi vì những thất bại lớn (ví dụ THERAC-25 ) dường như là những vấn đề phức tạp, tinh tế mà "kiến thức cơ bản" sẽ không bao giờ đủ để ngăn chặn.

Bỏ qua mọi vấn đề địa phương (chẳng hạn như sự bảo vệ hiện có của Kỹ sư chức danh trong một số khu vực pháp lý):

Mục đích là cao cả - tránh các quacks / charlatans 1 và làm cho sự khác biệt đó rõ ràng hơn với những người mua phần mềm của họ. Liệu quy định chặt chẽ hơn của ngành công nghiệp phần mềm có thể đạt được mục tiêu ban đầu không?

1 Chính xác như quy định của ngành y đã được dự định làm.


3
Tôi hy vọng Thomas Owens đáp ứng điều này bởi vì tôi biết anh ấy có câu trả lời hoàn hảo.
maple_shaft

3
Nhiều như tôi muốn nghe những gì mọi người nói về chủ đề này, nghe có vẻ giống như một câu hỏi thảo luận với tôi để phù hợp với định dạng Hỏi & Đáp của Stack Exchange.
PersonalNexus

12
Thành thật mà nói, tôi ủng hộ việc sửa đổi hiến pháp tạo ra sự tách biệt giữa công nghệ và nhà nước khi Chính phủ dường như không biết gì khi điều chỉnh công nghệ (xem thêm SOPA)
JohnFx

3
Làm thế nào một ngành công nghiệp có thể được quy định khi nó thay đổi mỗi ngày?
Jon Raynor

4
Không có nhiều tình huống "đủ tốt" mà sau này gây ra lỗi thường là lỗi của quản lý / tiếp thị nói: "SHIP SHIP SHIP!"
Aren

Câu trả lời:


105

Quan điểm cho rằng các kỹ sư phần mềm có thể được đưa vào phân loại giống như các chuyên gia y tế hoặc kế toán viên là một quan điểm không biết gì về "vấn đề" mà họ đang cố gắng giải quyết. Trước khi tôi đưa ra ý kiến ​​của mình về vấn đề này, chúng ta hãy phá vỡ một số lập luận của ông Thornton, Phó chủ tịch của cơ quan quản lý đề xuất luật này.

Ngay khi các chuyên gia thực hành như bác sĩ, kế toán và y tá được cấp phép, thì các kỹ sư phần mềm cũng vậy. Công chúng cần có khả năng dựa vào một số loại chứng chỉ khi chọn nhà thầu để viết phần mềm.

- Mitch Thornton, Phó Chủ tịch Cấp phép và Đăng ký của IEEE

Điều này nghe có vẻ rất hợp lý trên bề mặt. Rốt cuộc, có những ngành công nghiệp khác có thể được coi là "quy định thành công". Bằng cách điều chỉnh thành công, tôi có nghĩa là nếu bạn tìm một bác sĩ trong những trang vàng, bạn có thể chắc chắn một cách hợp lý rằng anh ấy hoặc cô ấy đã được giáo dục kỹ lưỡng tại một trường đại học được công nhận và đã vượt qua một số kỳ thi và hoàn thành việc cư trú. Dưới đây là một số ngành "quy định thành công" (về nhân sự chuyên nghiệp).

  • Luật sư
  • Nhiêu bác sĩ
  • Kế toán
  • Kỹ sư hạt nhân
  • Thợ cắt tóc ( không đùa )

Rốt cuộc, bạn không muốn bất cứ ai loại bỏ khối u đó khỏi tuyến tụy của bạn hoặc làm việc trên các máy ly tâm của nhà máy điện hạt nhân đó ngay bên ngoài thị trấn. Tại sao không nên hạn chế tương tự cho các kỹ sư phần mềm?

Chỉ những người có chương trình có thể gây nguy hiểm cho sức khỏe cộng đồng hoặc an toàn, an ninh, tài sản hoặc nền kinh tế mới cần được kiểm tra

Đây là một tuyên bố mơ hồ và mở cho giải thích và ứng dụng tự do. Tôi có thể đưa ra lập luận rằng Apple Inc. hoặc Facebook là một phần không thể thiếu của nền kinh tế Mỹ - tôi có cần giấy phép đặc biệt từ chính phủ để viết mã cho họ ngay bây giờ không, vì nếu tôi hạ thấp trang web với sự bất tài của mình, tôi có thể làm hỏng người Mỹ nên kinh tê? Trong công việc cuối cùng của tôi, tôi đã vô tình tắt một thang máy ngũ cốc với một công việc cron bị lỗi - có thể gây nguy hiểm cho việc cung cấp thực phẩm.

Tôi nhận ra rằng tôi đang tránh ý định thực sự của đề xuất này. Ý tưởng đằng sau đó là đảm bảo rằng người viết mã cho Hệ thống chống bó cứng phanh trên Jetta mới của bạn có thẩm quyền và được cấp phép phù hợp để viết mã cho Hệ thống chống bó cứng phanh. Trên Jetta của bạn.

Đây là vấn đề: công nghệ phần mềm trong thời đại ngày nay bao gồm tất cả mọi thứ và bạn không thể kiểm tra mọi ngành học. Các quy tắc kinh doanh quá cụ thể, và quá đa dạng từ kỷ luật đến kỷ luật. Kỹ sư giả định của chúng tôi viết mã cho hệ thống ABS trên Jetta có thể đang viết một cái gì đó hoàn toàn khác cho hệ thống ABS trên Elantra. Anh ta có phải được chứng nhận lại không?

Và nếu bạn làm bài kiểm tra cho tất cả các môn phái sinh này thì sao? Giả sử trong một khoảnh khắc rằng mọi lập trình viên làm việc trên một trang web thương mại điện tử đều được chứng nhận là một lập trình viên có khả năng thương mại điện tử. Vì thế? Điều này đột nhiên có nghĩa là các lập trình viên và công ty này thực sự sẽ thực hiện xác nhận cần thiết và xây dựng để tuân thủ PCI? Ngay cả khi họ làm - trục trặc vẫn sẽ xảy ra.

Bài kiểm tra sẽ kiểm tra kiến ​​thức cơ bản, không nắm vững vấn đề, theo Mitch Thornton, phó chủ tịch Ủy ban đăng ký và cấp phép của IEEE.

Đây là kicker. Thiếu kiến ​​thức cơ bản không bao giờ là vấn đề. Phanh chống khóa của tôi đã không ngừng hoạt động vì Chuck đang vật lộn với các khái niệm về cấu trúc điều khiển. Họ đã thất bại vì có trục trặc khi ABS bị tắt do chập điện ở đèn đuôi và nguồn điện không được định tuyến lại đúng cách. Hoặc một cái gì đó.

Phần mềm bơm insulin tôi đã viết không ngừng hoạt động vì tôi thiếu các kỹ năng cơ bản; nó dừng lại vì có một lỗi trong cách tôi đo mức độ phân phối insulin khi đồng đội châu Âu của tôi sử dụng hệ thống đo lường và tôi thì không.

Đó là thứ bạn có thể giải thích trong quá trình phát triển, nhưng bạn không bao giờ có thể kiểm tra bằng chứng nhận .

Đây là những gì sẽ xảy ra nếu "chứng nhận" này có hiệu lực: số lượng sự cố sẽ giữ nguyên như cũ. Tại sao? Bởi vì nó không làm gì để loại bỏ vấn đề thực tế của việc bơm ABS hoặc bơm insulin bị hỏng.


33
+1 câu trả lời xuất sắc. Tôi đặc biệt thích: "Thiếu kiến ​​thức cơ bản không bao giờ là vấn đề."
Jonathan Henson

4
Câu trả lời tuyệt vời nhưng nó chỉ tính đến kỹ thuật phần mềm từ góc độ lập trình viên. Kỹ thuật phần mềm thực sự là một nỗ lực nhóm liên quan đến nhiều kỹ năng và kỷ luật, nhà phân tích kinh doanh, đảm bảo chất lượng, quản lý dự án, v.v ... Các sự cố có thể là kết quả của việc lập trình kém khi họ bỏ lỡ các yêu cầu, yêu cầu hiểu sai, các dự án được quản lý kém và kiểm tra không đúng. Liệu bài kiểm tra OP có đề cập đến điều gì không? Tất nhiên không phải vì nó dành cho lập trình viên.
maple_shaft

3
Tôi sẽ thêm vào mặc dù tôi nghĩ rằng toàn bộ ý tưởng của IEEE là rác rưởi để bắt đầu. Tất cả chính phủ phải làm là công việc của mình để khắc phục vấn đề. Giữ mọi người chịu trách nhiệm cho bất kỳ thiệt hại mà họ phải chịu cho bất cứ ai. Điều này một mình sẽ giải quyết vấn đề
Jonathan Henson

16
Không đồng ý với "Thiếu kiến ​​thức cơ bản không bao giờ là vấn đề." Trong thực tế, nó thường vấn đề. Làm thế nào thường xuyên lập trình viên mới (hoặc cũ hơn) bỏ bê vệ sinh đầu vào? Xác minh vụ án phạt góc? Đối với các hệ thống vật lý, tôi có thể đọc một cảm biến. Nó có thể bật hoặc tắt. Thế còn vỡ? Làm thế nào phần mềm của tôi có thể nói? Sau đó, tôi phải làm gì về nó? Giả sử nó là bật hay tắt? Những loại "cơ bản" này thực sự là vấn đề thường gặp.
sdg

3
@JonathanHenson Sau đó, một lần nữa, tôi coi hầu hết các trường hợp tiêm SQL là chính xác - thiếu kiến ​​thức cơ bản ... nhưng nói chung, bài đăng tốt. +1.
Jeff Ferland

72

Thật may mắn làm sao khi không ai chết vì quy định y tế, không ai bị tổn thương vì gian lận nhờ quy định tài chính, không ai bị tịch thu nhà nhờ quy định nhà ở, không ai bị cắt tóc xấu vì quy định của thợ cắt tóc, và không có máy bay nào bị rơi. nhờ quy định máy bay.

Rõ ràng, sự hiện diện của quy định không có nghĩa là không có sai sót hoặc thất bại. Ngược lại, sự hiện diện của sai sót hoặc thất bại không ngụ ý quy định sẽ ngăn chặn những sai sót hoặc thất bại. Các kỹ sư phần mềm đã được quy định cao như là thành viên của các ngành công nghiệp an toàn tương ứng, và bên ngoài các ngành đó không có nhu cầu.


10
+1 cho "Các kỹ sư phần mềm đã được quy định cao như là thành viên của các ngành công nghiệp quan trọng an toàn tương ứng và ngoài các ngành đó không có nhu cầu"
Trevor Boyd Smith

3
Tôi không thích giọng điệu cay độc của câu trả lời này. Bạn có nói rằng không cần quy định, vì quy định không bao giờ giải quyết bất kỳ vấn đề?
Fred Foo

8
Tôi đang nói ngoài một điểm nhất định, nhiều quy định hiếm khi giải quyết nhiều vấn đề. Bắt buộc một số thực hành kiểm thử phần mềm trên các máy có khả năng giết người có ý nghĩa. Việc thi thêm một kỳ thi chứng chỉ kỹ năng cơ bản vào cuối chương trình cấp bằng chỉ làm tăng thêm sự quan liêu.
Karl Bielefeldt

2
@larsmans Tôi đồng ý với Karl, nếu chính phủ đang xử lý tên lửa hoặc thứ gì đó mà nó tin rằng các tiêu chuẩn cao nên được ủy quyền, hãy để họ thuê các lập trình viên và kỹ sư của riêng họ theo bất kỳ tiêu chuẩn nào họ chọn. Khu vực tư nhân không nên kiếm tiền từ bất kỳ rủi ro nào - đó là chủ nghĩa phát xít. Một ngành công nghiệp tư nhân không được phép gây nguy hiểm cho công chúng để bắt đầu. Những người biết những gì họ cần nhất, là những người chấp nhận rủi ro. Hãy để họ xử lý công việc của họ. Và vâng, tôi biết rằng lockheed-martin và những thứ tương tự làm điều này. Họ không nên được phép mặc dù.
Jonathan Henson

3
Xem xét số lượng các tập đoàn lớn đã mất chi tiết thẻ tín dụng trong năm qua hoặc lâu hơn, tôi sẽ nói rằng không có sự tự điều chỉnh thỏa đáng. Bạn có thể lập luận rằng các hệ thống này không quan trọng đến tính mạng - nhưng ảnh hưởng đối với túi tiền của mọi người có thể khó khăn như vậy sau những sự cố này.
HorusKol

32

Lịch sử đã chỉ ra, một cách thông minh, tôi tin rằng, sự khác biệt giữa một nghệ nhân xuất sắc và một người tầm thường không thể được kiểm tra bằng bất kỳ hình thức đo lường khách quan nào. Kiến thức cơ bản không tạo ra một lập trình viên, trí tuệ và kinh nghiệm tuyệt vời - điều không thể thực sự được dạy hoặc đo lường một cách khách quan - về cách áp dụng kiến ​​thức cơ bản đó.

Ngoài ra, các bài kiểm tra này thường chỉ là một vài từ buzz và quy trình cụ thể và không đo lường được bất cứ điều gì đáng kể để bắt đầu.

Nếu ngành công nghiệp phần mềm muốn phát triển một bang hội nào đó, đó sẽ là cách tốt hơn nhiều để tiếp cận vấn đề. Tuy nhiên, tập trung hóa chỉ có sức mạnh để phá hủy sự xuất sắc: không tạo ra nó.

Ngoài ra, các vấn đề mà biện pháp này đang cố gắng ngăn chặn có thể sẽ không bị bắt bởi một bài kiểm tra nào. Dù sao, tôi cũng rất muốn thấy @ThomasOwens trả lời câu hỏi này.

Vai trò của chính phủ, ít nhất là từ hệ tư tưởng Mỹ, sẽ là gì để giữ các công ty phần mềm chịu trách nhiệm cho bất kỳ thiệt hại tài sản nào do phần mềm bị lỗi hoặc không an toàn của họ gây ra. Điều này sẽ khuyến khích các công ty thực thi các tiêu chuẩn của riêng họ và chịu trách nhiệm cá nhân về vấn đề này. Đây luôn là một giải pháp tốt hơn và nó không chứa một chính phủ tập trung vượt qua giới hạn của nó.

Cập nhật

Tôi đã suy nghĩ về điều này nhiều hơn đêm qua trên một hoặc mười bia.

Tất cả những gì điều chỉnh lĩnh vực y tế đã làm là để tiêu diệt tất cả các mô hình trừ một. Nếu mục tiêu của họ là loại bỏ các bác sĩ vi lượng đồng căn và tự nhiên, người mà op vui lòng gọi là "lang băm" thì quy định đó đã thành công. Tuy nhiên, tôi không đồng ý rằng một điều như vậy có lợi cho bất kỳ ai ngoại trừ những người viết luật. Hãy suy nghĩ về những gì điều này đã làm. Nó đã đẩy chi phí chăm sóc sức khỏe lên mức không bền vững, làm tăng đáng kể mức trách nhiệm đối với các MD và đã loại bỏ tất cả quyền lực của người tiêu dùng về sự lựa chọn và quyền tự quyết khỏi thị trường. Không có thêm thị trường cho các ý tưởng trong cộng đồng y tế, và các phương pháp điều trị và cách suy nghĩ mới về y học hiện đang bị loại bỏ. Hơn nữa, rào cản gia nhập lĩnh vực này là vô cùng cao và kết quả là chúng ta thiếu MD tốt S. Ngoài ra, các cơ quan quản lý có quyền kiểm soát việc cung cấp bác sĩ để họ có thể lần lượt kiểm soát giá mà bác sĩ được trả.

Thực sự có một số lợi ích mà chúng tôi đã nhận được từ quy định y tế, nhưng chi phí hoàn toàn quá cao.

Điều này cũng xảy ra với các kỹ sư phần mềm nếu quy định đó được thông qua. Tôi có thể thấy nó bây giờ, các cơ quan quản lý sẽ quy định rằng lập trình hướng đối tượng là tiêu chuẩn duy nhất của thiết kế và các lập trình viên chức năng và thủ tục sẽ không được phép thực hành. Sau đó, họ sẽ bắt đầu nói với chúng tôi rằng chúng tôi không được phép quản lý bộ nhớ của chính mình vì nó không an toàn. Sau đó, họ sẽ nhồi nhét JAVA và C # xuống tất cả các họng của chúng tôi và nói với chúng tôi rằng chúng tôi phải sử dụng nó trong khi Oracle và Microsoft trở nên béo hơn và hạnh phúc hơn. Sự đổi mới sẽ bị kìm hãm và sự sáng tạo sẽ bị đặt ngoài vòng pháp luật. Microsoft và Google sẽ viết luật, vì vậy các quy tắc của thị trường sẽ nghiêng về lợi nhuận của chính họ và chống lại sự thịnh vượng xã hội.

Ngoài ra, hãy để tôi nhắc nhở mọi người rằng máy tính khởi đầu như một người có sở thích và nỗ lực học tập. Khác với các cuộc chiến Unix của thập niên 80 và đầu thập niên 90, chúng tôi đã có các hệ điều hành miễn phí, trình biên dịch miễn phí, chương trình miễn phí, v.v ... Điều này sẽ kết thúc nhanh chóng. Thế giới mà Richard Stallman, Linus Torvalds và Dennis Richtie kế thừa chúng ta sẽ dần dần biến mất khỏi sự tồn tại.

Tóm lại, tôi có cảm thấy mệt mỏi khi phải cạnh tranh với "Tôi sẽ thiết kế cho bạn một trang web wordpress với giá 25 đô la mỗi giờ" hay "bất kỳ ứng dụng iPhone nào cho 500 đô la" không? Không thực sự, tại sao? Bởi vì tôi rất giỏi trong những gì tôi làm và những khách hàng mà tôi muốn sẵn sàng trả cho sự xuất sắc. Khi tôi tham gia một dự án một cách độc lập hoặc tại nơi làm việc của mình, tôi sẽ gặp rủi ro về sự nổi tiếng và danh tiếng của chính mình. Điều đó sẽ theo tôi bất cứ nơi nào tôi đi. Ngoài ra, hầu hết mọi người biết rằng họ nhận được những gì họ phải trả cho. Một khách hàng chỉ sẵn sàng trả cho tôi cái giá mà họ trả cho anh chàng sân cỏ của họ sẽ là một cơn ác mộng đối phó với mọi chuyện. Nếu chính phủ cố định cấu trúc pháp lý để buộc các nhà cung cấp dịch vụ phải bồi thường thiệt hại, thì sẽ có rất ít lập trình viên xấu vẫn có việc làm trong lĩnh vực này.

Nhân tiện, chúng tôi vẫn có những bác sĩ tồi, sự khác biệt duy nhất là có rất ít lực lượng để loại bỏ họ khỏi thị trường. Nếu họ phải chịu trách nhiệm cho hành động của mình, họ sẽ bị loại khỏi công việc trước khi họ có cơ hội khác để tàn phá khách hàng của mình.


8
Mặc dù tôi đồng ý với lực đẩy chung của tuyên bố của bạn, tôi thấy phần thú vị nhất của nó là câu đầu tiên. Bạn mô tả phát triển phần mềm là một nghề thủ công , đó chính xác là vấn đề . Người ta không chế tạo một cây cầu treo; một kỹ sư một cây cầu treo để đảm bảo hiệu quả và an toàn của nó. Các kỹ sư phần mềm vẫn hành động giống như các thợ thủ công hơn là các kỹ sư, bất kể bạn đặt cho họ danh hiệu nào.
Eric Lippert

4
@Jonathan Henson: Nói chung, họ chắc chắn không. Rất nhiều cửa hàng đạt điểm 0 trong bài kiểm tra Joel. ( joelonsoftware.com/articles/fog0000000043.html ) Về việc họ có nên hay không , đó là một quyết định kinh doanh không phải là một quyết định đạo đức. Tất cả những thứ đó đều tốn tiền: rất nhiều và rất nhiều tiền. Nếu bạn đang xây dựng một hệ thống điều khiển máy bay, về lâu dài sẽ có lợi nhuận để đảm nhận các chi phí đó; nếu bạn đang xây dựng một trò chơi facebook, có thể không.
Eric Lippert

1
Không, tem kiến ​​trúc sư tốt như tem PE. Tôi chắc chắn sẽ nói rằng chúng ta cần kết hợp nhiều thứ hiện được gọi là các ngành kỹ thuật, giống như một kiến ​​trúc sư làm. Kiến trúc vẫn được coi là nhiều hơn một nghề thủ công mặc dù. Dù sao, kỹ thuật có lẽ cũng là một nghề thủ công, vì vậy tôi có thể chỉ băm chữ không có gì.
Jonathan Henson

1
@Andy, tôi cho rằng chúng ta nên yêu cầu trao đổi ngăn xếp để thay đổi tiêu đề của trang web này thành softwareengineers.stackexchange.com :)
Jonathan Henson

1
@JonathanHenson Xúc phạm? Không thể nào, đừng lo lắng! :) Tôi nên làm cho nó rõ ràng hơn một chút rằng tôi đã đăng liên kết chỉ vì nó trùng hợp kỳ lạ với bình luận của bạn.
yannis

23

Tin tức Thung lũng Silicon - ngày 31 tháng 6 năm 2015

Kinh dị: Lập trình viên không xác định đã hủy bỏ chương trình

"Tôi sẽ không bao giờ có thể chạy lại", đầu ra cho nạn nhân. Cảnh sát đang điều tra.

Hình sự: Giấy phép của Tiến sĩ H. Acker Jr. bị thu hồi vì sử dụng sai con trỏ và cố đọc từ tệp hệ thống

Advocate nói rằng sẽ có kháng cáo lên Tòa án Tối cao.

Thông báo: Các lập trình viên Cobol được chứng nhận năm 1975 sẽ chứng nhận lại không muộn hơn 2025

Chứng nhận của IEEE đã không thay đổi kể từ đó.

Quảng cáo: Chứng nhận được đảm bảo với Magic Knowledge Stuffers, Inc

Dạy bản thân lập trình trong 21 ngày.


Tôi đang cố gắng quyết định xem đây là một câu trả lời đầy đủ hay một bình luận hài hước. (Cả hai có lẽ?)
Lyndon White

@Oxinabox ngày 31 tháng 6 thật hài hước
gnat

"Dạy bản thân lập trình trong 10 ngày!" hehe
BЈовић

20

Có một số cách khác nhau để áp dụng quy định cho bất kỳ ngành nghề nào - cơ quan kiến ​​thức được xác định rõ, quy tắc đạo đức, công nhận chương trình giáo dục, chứng nhận và cấp phép, và các xã hội chuyên nghiệp hỗ trợ phát triển nghề nghiệp cũng như các khía cạnh khác của nghề nghiệp. Kỹ thuật phần mềm có hầu hết các đặc tính của một nghề.

Tôi thích nghĩ về nó như bắt đầu với Cơ quan Kiến thức Kỹ thuật Phần mềm (SWEBOK)Quy tắc Đạo đức và Thực hành Kỹ thuật Phần mềm . Mặc dù sự chấp nhận chung về những điều này vẫn còn khá hạn chế, tôi nghĩ rằng chúng đóng vai trò là cơ sở tốt để xác định các loại điều mà ai đó tự nhận mình là kỹ sư phần mềm nên có kiến ​​thức và cách một người đó nên hành động trong khả năng chuyên nghiệp. Điều đó không có nghĩa đây là những quy tắc cứng, mà là những tài liệu này hướng dẫn các kỹ sư phần mềm chuyên nghiệp về những gì thường liên quan đến công việc mà họ có thể được yêu cầu. SWEBOK được sửa đổi theo thời gian để đảm bảo rằng nó vẫn phù hợp.

Các đặc điểm tiếp theo là công nhận các chương trình giáo dục. Ở Mỹ, việc công nhận các chương trình kỹ thuật phần mềm được ABET xử lý . Họ cũng công nhận khoa học máy tính, công nghệ thông tin, kỹ thuật máy tính và các ngành nghề liên quan đến máy tính khác. ABET đăng các yêu cầu của họ về các chương trình được công nhận trên trang web của họ - công nghệ phần mềm được coi là Chương trình Kỹ thuật. Mục đích của kiểm định là để đảm bảo sự thống nhất giữa các sinh viên tốt nghiệp các chương trình kỹ thuật khác nhau, ít nhất là về các vấn đề được giảng dạy trong lớp học. Nó không nói gì về chất lượng giáo dục.

Sau khi tốt nghiệp, chứng nhận và cấp phép được sử dụng để đánh giá kiến ​​thức đã học trong lớp (và, trong một số trường hợp, trong công việc) đối với các cơ quan kiến ​​thức tiêu chuẩn. Mặc dù các trường được công nhận có một khối tài liệu được xác định sẽ được dạy, nhưng không có thước đo về việc tài liệu này được dạy tốt như thế nào và học sinh học được bao nhiêu khi hoàn thành chương trình. Chứng nhận và cấp phép cung cấp các phương pháp để thực hiện điều đó - mọi người đều thực hiện các bài kiểm tra giống nhau và thể hiện kiến ​​thức trong các nhóm kiến ​​thức khác nhau mà nghề nghiệp bắt nguồn. Trong công nghệ phần mềm, IEEE cung cấp các chứng chỉ bắt nguồn từ SWEBOK - Phát triển phần mềm được chứng nhận Liên kết cho người cao niên và sinh viên tốt nghiệp gần đây và Chuyên gia phát triển phần mềm được chứng nhậncho những người có kinh nghiệm trong ngành. Để những thứ này tăng thêm giá trị, nó đòi hỏi phải chấp nhận SWEBOK như một định nghĩa tốt về kỹ thuật phần mềm là gì.

Cuối cùng, các hội nghề nghiệp duy trì các tài liệu hướng dẫn cho nghề nghiệp, tạo điều kiện cho các hội nghị và ấn phẩm trao đổi kiến ​​thức và ý tưởng, thu hẹp khoảng cách giữa các học viện và ngành công nghiệp, v.v. Hai xã hội hàng đầu là Hiệp hội máy tính IEEEACM , nhưng có những xã hội khác trên khắp thế giới. Những thứ này gói gọn mọi thứ thành một bó nhỏ xinh xắn và giúp cung cấp thông tin cho đúng người.

Từ đây, có những câu hỏi khác để hỏi. Là sự phát triển của phần mềm là một chuyên ngành kỹ thuật? Có chứng nhận hoặc cấp phép thêm bất kỳ giá trị cho các kỹ sư phần mềm? Chứng nhận có hữu ích không?

Tôi không nghĩ rằng tất cả sự phát triển phần mềm cần sự nghiêm ngặt của một chuyên ngành kỹ thuật. Điều đó không có nghĩa là một nghiên cứu khoa học và thực nghiệm về khoa học và kỹ thuật xây dựng phần mềm không giúp được tất cả mọi người - nó thực hiện. Tuy nhiên, có một sự khác biệt lớn giữa việc phát triển trò chơi video mới nhất, phát triển phần mềm nhúng cho máy tạo nhịp tim hoặc xây dựng tàu vũ trụ tiếp theo. Sự nhấn mạnh là khác nhau trên tất cả chúng - hai trong số ba người xứng đáng nhận được sự chú ý của một kỹ sư lành nghề. Người khác có thể học hỏi từ thực tiễn kỹ thuật, nhưng không cần phải dựa vào họ để hoàn thành dự án thành công.

Chứng nhận và cấp phép đòi hỏi một cơ thể kiến ​​thức được chấp nhận. SWEBOK là một tài liệu tốt cung cấp nền tảng vững chắc, nhưng nó không được chấp nhận rộng rãi. Trừ khi bạn có thể dựa trên các chương trình học tập và các kỳ thi cấp chứng chỉ / cấp phép của mình trên một cái gì đó cụ thể sẽ được các học viên chấp nhận, thì thực sự không có điểm nào. Nếu SWEBOK hoặc tài liệu thay thế trở nên được chấp nhận rộng rãi (ít nhất là trong các lĩnh vực đòi hỏi sự nghiêm ngặt của kỹ thuật), thì có thể sử dụng các kỳ thi cấp chứng chỉ hoặc cấp phép để đánh giá sự hiểu biết về kiến ​​thức cần thiết.

Tuy nhiên, có một vấn đề lớn với chứng nhận - đó là một thử nghiệm trên một cuốn sách. Một số người giỏi đọc, học, ghi nhớ và làm bài kiểm tra. Tuy nhiên, điều đó không có nghĩa là họ là một kỹ sư giỏi. Mọi người trượt qua các vết nứt mọi lúc. Giấy chứng nhận hoặc giấy phép chỉ là một bước duy nhất. Về đào tạo công việc và cố vấn bởi các kỹ sư giàu kinh nghiệm khác là bắt buộc để chuẩn bị một học viên tốt. Ngoài ra, khả năng ngăn chặn mọi người thực hành trong môi trường quan trọng cũng có thể giúp giảm thiểu rủi ro cho xã hội và doanh nghiệp.

Một cuốn sách hay với một cuộc thảo luận khá chuyên sâu về vấn đề này là Phát triển phần mềm chuyên nghiệp của Steve McConnell : Lịch trình ngắn hơn, Sản phẩm chất lượng cao hơn, Dự án thành công hơn và Nghề nghiệp nâng cao .


Tôi là một chút dưới thời tiết, vì vậy nếu tôi bỏ lỡ bất cứ điều gì hoặc một cái gì đó không có ý nghĩa, chọc tôi và tôi sẽ sửa nó. Cảm ơn các bạn.
Thomas Owens

"Hai trong số ba người xứng đáng với sự chú ý của một kỹ sư lành nghề" bạn nói đúng, tàu vũ trụ không quá khó để thực hiện
zzzzBov

+1 cảm ơn vì đã thêm ý kiến ​​của bạn về vấn đề này. Tôi hy vọng bạn sẽ cảm thấy tốt hơn.
Jonathan Henson

12

Nếu các quy định của chính phủ được thông qua, ngành công nghiệp phần mềm ở Hoa Kỳ sẽ ký hợp đồng đáng kể, bởi vì chi phí liên quan đến việc đáp ứng các quy định đó sẽ cao hơn so với các doanh nghiệp khởi nghiệp và các doanh nghiệp nhỏ có thể chi trả.

Sự khan hiếm và chi phí liên quan đến bằng Luật hoặc Bác sĩ Y khoa sẽ ít nhiều xuất hiện trong ngành của chúng tôi. Không tốt khi thay thế là mọi kẻ thù có khả năng xây dựng Facebook tiếp theo.

Mọi người phạm sai lầm, và không có số lượng quy định sẽ ngăn chặn thảm họa xảy ra. Hãy xem xét NASA, nơi có các yêu cầu khắt khe nhất để phát triển phần mềm mà con người biết đến. Họ vẫn có lỗi phần mềm? (Vâng, vâng, và nhiều lần, vâng!)

Thị trường sắp xếp những vấn đề này tốt hơn rất nhiều so với quy định có thể. Các công ty tạo ra phần mềm gây ra sự cố phải chịu trách nhiệm bởi những người họ bị thương. Phần còn lại của chúng tôi không cần phải trả cho những sai lầm của họ.


8
Một bổ sung tuyệt vời cho câu trả lời này sẽ là một danh sách các công ty phần mềm hiện có mà có lẽ sẽ không được bắt đầu nếu các quy định này có hiệu lực. Microsoft và Facebook là một khởi đầu tốt, vì chứng chỉ có thể sẽ yêu cầu bằng cấp (hầu hết mọi ngành nghề bắt đầu bằng thử nghiệm đều thêm yêu cầu bằng cấp nếu họ không bắt đầu bằng một).
psr

1
@maple_shaft, IMO so sánh bác sĩ / luật sư với công nghệ phần mềm là không hợp lệ. Các lĩnh vực quá khác nhau để so sánh (xem câu trả lời của Jarrod Nettles để biết lý do tại sao bạn không thể so sánh kỹ thuật phần mềm với bác sĩ / luật sư).
Trevor Boyd Smith

1
@maple_shaft - Bạn đang ám chỉ rằng chứng nhận sẽ cải thiện chất lượng kỹ thuật. Tôi khá hoài nghi rằng đó sẽ là kết quả. Tôi nghĩ rằng thời gian học tập cho hầu hết các bài kiểm tra là thời gian không dành cho việc học kỹ thuật tốt hơn.
psr

4
Tôi tin rằng tất cả mọi người đang đưa ra một giả định chưa được chứng minh rằng các bác sĩ và luật sư cấp phép thực sự cải thiện chất lượng của các bác sĩ và luật sư. Tôi rất hoài nghi về giả định đó. Tất cả những gì cấp phép đảm bảo là các bác sĩ và luật sư phải trả các khoản phí cực kỳ cao và không có điều gì mà mọi người có thể làm về việc này. Về vấn đề đó, tôi là tất cả để cấp phép cho các kỹ sư phần mềm. Nó sẽ không cải thiện chất lượng của một phần mềm iota, nhưng chắc chắn sẽ làm cho nhiều nhà phát triển phần mềm của chúng ta trở nên giàu có. Haha khi chính phủ bắt giữ đứa trẻ trung học vì thực hành phần mềm mà không có giấy phép.
Dunk

1
@maple_shaft hoàn toàn phụ thuộc vào bản chất của sự thất bại - Facebook không phản hồi là không quan trọng (ngoài việc ảnh hưởng đến túi của nhà đầu tư) - Facebook cung cấp tất cả các chi tiết cá nhân và tin nhắn riêng tư của bạn cho mỗi người dùng internet là một vấn đề khác nhau. Hơn nữa - các ứng dụng / trò chơi lấy thông tin chi tiết về thẻ tín dụng (như trên Facebook) vô tình tiết lộ chi tiết thẻ tín dụng sẽ có tác động nghiêm trọng.
HorusKol

11

Vào năm 1999, ACM đã ban hành một tuyên bố về việc cấp phép khi phần lớn rút ra khỏi công việc của IEEE SWEBOK. Sau khi xem xét các tài liệu SWEBOK có sẵn công khai và tuyên bố ACM, tôi ủng hộ ý kiến ​​của ACM.

Liếc nhìn bài báo, một người có 4 - 6 năm kinh nghiệm được yêu cầu làm bài kiểm tra, bài kiểm tra kiến ​​thức cơ bản. Điều đó thật vô lý, và nên cười ra khỏi cửa.


10

Các thành phần phần mềm của một thiết bị là một chi tiết thực hiện. Ví dụ, trong ngành công nghiệp hệ thống điều khiển, tất cả các thiết bị an toàn thường được sử dụng và mọi người không tin tưởng vào phần mềm. Tuy nhiên, chúng ta hiện đang thấy các thiết bị an toàn dựa trên phần mềm như Rơle an toàn và PLC an toàn. Đây là những cho phép bởi vì họ vẫn phải đáp ứng các quy định của ngành cho các thiết bị an toàn (tùy thuộc vào loại an toàn). Do đó, trong một số trường hợp, các thiết bị cần bộ xử lý dự phòng và mã dự phòng được viết bởi hai nhóm khác nhau, v.v.

Đây là sản phẩm cần đáp ứng các nguyên tắc an toàn nếu được bán và tiêu thụ bởi công chúng. Những quy tắc đó không thay đổi vì sản phẩm có chứa phần mềm. Đó là công việc của Kỹ sư để đảm bảo rằng sản phẩm đáp ứng tất cả các tiêu chí quy định và nếu nó chứa phần mềm, thì họ phải xem xét phần mềm và có thẩm quyền trong lĩnh vực đó . Nếu họ không phải, họ (hoặc công ty của họ) phải chịu trách nhiệm nếu họ phê duyệt thiết kế và hóa ra là bị lỗi.

Bạn không thực sự cần phải điều chỉnh tất cả các lập trình viên chỉ vì một số sản phẩm cần đáp ứng các yêu cầu nghiêm ngặt hơn. Trong trường hợp các sản phẩm đó liên quan đến phần mềm, bạn cần một chuyên ngành kỹ thuật được phát triển tốt để có thể xác định một cách đáng tin cậy rằng thành phần phần mềm đáp ứng các yêu cầu. Nếu bất cứ điều gì, đó là ý nghĩa của IEEE: lĩnh vực Kỹ thuật phần mềm tương đối trẻ cần được phát triển đến mức độ tin cậy và tin cậy của các ngành kỹ thuật khác.

Nó thực sự không liên quan gì đến "lập trình" và mọi thứ liên quan đến "kỹ thuật".

Tất nhiên, điều này đưa chúng ta trở lại vấn đề gây tranh cãi về sự khác biệt giữa nhà phát triển và kỹ sư. Nhìn chung đây là hai vai trò khác nhau thường xuyên chồng chéo. Phần nhà phát triển có nghĩa là bạn tạo ra phần mềm. Phần kỹ thuật của vai trò có nghĩa là nếu bạn đóng dấu thiết kế bạn đang chịu trách nhiệm về an toàn công cộng. Bạn có thể là một mà không có người khác.


5
+1 IMHO, điều bạn thực sự ám chỉ là quy định cần phải có trên sản phẩm chứ không phải các kỹ sư. Ví dụ, các quy định (phê duyệt) cần thiết cho hệ thống Báo cháy và Xâm nhập đảm bảo phần mềm hoạt động, chứ không phải khả năng của các kỹ sư đã viết nó. (Nhiều quy định trông giống như khi các hệ thống được làm hoàn toàn từ các mạch điện tử.)
jwernerny

8

Phần mềm đã được quy định chặt chẽ trong ngành công nghiệp máy bay. Xem DO-178B .

Tôi chắc rằng các tập hợp con khác của ngành có định mức của chúng.

"Phần mềm" bao gồm rất nhiều những ngày này. Tôi nghĩ rằng sẽ là vô lý khi có bất kỳ quy định bao gồm tất cả bắt buộc.


4

Quy định của ngành công nghiệp phần mềm được thực hiện tốt nhất thông qua quy định của các quy trình Đảm bảo chất lượng.

Điều này đã được thực hiện - các công ty phần mềm lớn có vô số người kiểm thử, người quản lý QA, bộ kiểm thử tự động, quy trình xem xét mã, quy trình kiểm tra, bật và tắt. Có những công ty có toàn bộ mục đích là thực hiện kiểm toán chất lượng phần mềm trên các công ty khác. Các tổ chức tiêu chuẩn có hướng dẫn về QA và Kiểm toán QA.

Nội bộ cho một công ty, một kỹ sư phần mềm chịu trách nhiệm về chất lượng công việc của họ. Tuy nhiên, kiểm tra và số dư của họ nằm trong quy trình chất lượng của công ty.


2
Đây chính xác là ý kiến ​​của tôi. Ngành hàng không có các quy tắc nghiêm ngặt để kiểm soát và kiểm tra chất lượng lập trình. Các công ty cần kiểm toán tài sản thông tin của họ và thực hiện nhiều thử nghiệm và xem xét. Tôi nghĩ đây là những ngày đen tối của phần mềm, bởi vì rất nhiều người vẫn đang cắt xén bằng cách không làm những gì họ biết là điều đúng đắn và bản thân các nhà phát triển không đủ để thay đổi ngành công nghiệp.
Tjaart

Điểm tuyệt vời - phần mềm chạy thiết bị cũng là trách nhiệm của công ty đối với kỹ thuật tốt và an toàn như với kỹ thuật công nghiệp.
Jarrod Nettles

3

Nó giống như hầu hết các nỗ lực hiện đại như giải quyết "các vấn đề liên quan đến phần mềm". Những người cố gắng lập pháp có ít kiến ​​thức về tiến trình gốc của vấn đề. Nếu tuân theo quy trình quy định (và mục đích tất nhiên) khi phát triển phần mềm quan trọng an toàn, thì đối với máy bay, các nhà máy hạt nhân của thiết bị y tế, một lỗi duy nhất sẽ không bao giờ đủ để gây ra lỗi. Toàn bộ thuật toán có thể được thực hiện không chính xác với bất kỳ ai bị hại.

Cả FDA và FTA đều yêu cầu phân tích rủi ro và dựa trên đó là chiến lược giảm thiểu. Sau này thường là một chiến lược phô mai Thụy Sĩ trong đó người ta chấp nhận rằng bất kỳ sự giảm thiểu nào là thiếu sót, do đó, nhiều biện pháp giảm thiểu cho cùng một rủi ro được áp dụng (một giảm thiểu cũng có thể được áp dụng cho một số rủi ro) mỗi giảm thiểu giống như một lát phô mai Thụy Sĩ mà bạn có thể xem qua một, có thể hai lát ghép lại với nhau nhưng đặt đủ các lát lại với nhau và điều đó không còn có thể. Ngay cả khi việc giảm thiểu được thực hiện một cách hoàn hảo mà không dẫn đến một thiết bị an toàn 100%. Nếu phân tích rủi ro không chính xác, sẽ có rủi ro không ai nghĩ đến (Y2K).

Bạn có thể kiểm tra các kỹ sư tất cả những gì bạn muốn, thậm chí bạn có thể kiểm tra về vấn đề và yêu cầu trình độ cực kỳ cao nhưng điều đó sẽ quan trọng. Hầu hết các lỗi nghiêm trọng về an toàn là lỗi tích hợp. Chúng không phải là lỗi trong một mã mans nhưng phát sinh do sự sai lệch giữa phần mềm và phần cứng của hai hệ thống phần mềm hoặc do một hạt alpha đánh bật bộ đếm chương trình ra khỏi vị trí thích hợp của nó.

Tôi đã tham gia một số hệ thống quan trọng về an toàn với các nhà phát triển có kinh nghiệm và có khả năng cao, những người sẽ vượt qua bất kỳ thử nghiệm hợp lý nào trong lĩnh vực của họ. Tôi chưa bao giờ tham gia một dự án mà chúng tôi không có lỗi nghiêm trọng về an toàn. (May mắn thay tôi chưa từng ở một nơi mà hệ thống từng làm hại ai)


1
+1 - Dành cho: "Hầu hết các lỗi nghiêm trọng về an toàn là lỗi tích hợp." Trong thực tế, với tất cả quá trình chúng ta trải qua, hầu như không bao giờ xảy ra lỗi mã hóa. 99,98% thời gian là vấn đề hiểu biết giữa các mô-đun và thiết bị khác nhau về cách chúng được cho là hoạt động.
Dunk

@Dunk cảm ơn nó thực sự là một qoute từ Levison. Một sự thật tôi muốn đưa vào văn bản nhưng dường như tôi đã quên :)
Rune FS

2

Người ta không bao giờ có thể loại bỏ hoàn toàn các charlatans và lang băm vì chúng tồn tại trong hầu hết mọi ngành nghề, ngay cả các ngành y mặc dù các tập quán và truyền thống lâu đời.

Mặc dù tuyên bố này là một sự chiếm đoạt đất đai, tôi không chắc chắn sự chồng chéo đáng sợ đen tối của tất cả mọi thứ CNTT đang âm mưu phá hoại sự kiểm soát và điều tiết phát triển phần mềm của anh ta. Nếu bạn thực sự đang nói về IEEE thì chắc chắn họ có khía cạnh pháp lý nhưng việc tuân thủ các tiêu chuẩn của IEEE ít nhiều sẽ tùy ý, và không phải ở điểm ngắm súng. Họ đang cố gắng phát triển các tiêu chuẩn công nghiệp phổ quát để tất cả chúng ta nói cùng một ngôn ngữ và tăng hiệu quả trên bảng.

Hơn nữa các tiêu chuẩn mà họ đưa ra giúp hợp pháp hóa các thông lệ chung và đặt nền tảng cho phát triển phần mềm để cuối cùng trở thành một lĩnh vực kỹ thuật kỷ luật hơn, không giống như kỹ thuật cơ khí, hoặc kỹ thuật hóa học. Trong khi phần mềm đang tiến gần hơn đến mục tiêu đó, nó có thể sẽ không bao giờ hoàn toàn được chấp nhận phổ biến như một môn học kỹ thuật.

Vấn đề cốt lõi là một nhà phát triển phần mềm có thể làm bất cứ điều gì từ việc viết một widget đẹp cho máy tính để bàn, đến việc thực hiện các hệ thống hướng dẫn tên lửa. Trong một mức độ nghiêm trọng và hậu quả của lỗi cao hơn nhiều so với cái khác, và do đó đòi hỏi một kỷ luật kỹ thuật được quy định chặt chẽ để tiếp cận hợp lý, an toàn và hiệu quả. Điều này giống như mức độ nghiêm trọng của lỗi trong một cây cầu được thiết kế không chính xác và kết quả là nó bị sập. Các nhà thiết kế của cây cầu phải tuân theo các tiêu chuẩn kỹ thuật của tôi để đảm bảo chất lượng.


4
Thông thường các quy định như vậy cũng là yêu cầu pháp lý. Ví dụ, kỹ thuật dân dụng cần có PE
Paul Nathan

@PaulNathan Điểm hay, đó là lý do tại sao sự tiến triển tự nhiên đối với một ngành học được chấp nhận phổ biến bắt đầu từ sự tự điều chỉnh (Ví dụ: MPAA) và cuối cùng dẫn đến quy định của pháp luật (hội đồng nhà nước, FCC, v.v.)
maple_shaft

7
Tôi không tin việc phát triển phần mềm đã sẵn sàng để tự điều chỉnh hoặc thậm chí gần với nó. Thành thật mà nói, ý tưởng rằng "các kỹ sư thực sự" có "chất lượng thực sự" là một trò đùa với tôi. Các tàu con thoi đã nổ tung, tên lửa đã thắp sáng, những cây cầu bị đổ, các tòa nhà bị sụp đổ ... vv Thật tốt khi cố gắng áp đặt chất lượng từ trên cao, nhưng, haha.
Paul Nathan

1
So sánh kỹ thuật cơ khí với công nghệ phần mềm khiến tôi tự hỏi tương tự kỹ thuật trong thế giới thực sẽ là gì giống như các hệ điều hành hiện đại.
Thất vọngWithFormsDesigner

1
@maple_shaft - vấn đề cốt lõi sẽ xảy ra là bạn không thể sử dụng Linux / BSD / grep / vi / Firefox, v.v. vì chúng không được viết bởi một SE chính thức. Trong khi ai đó có chứng chỉ MSCE trong VB sẽ ổn.
Martin Beckett

1

Tôi sẽ không gọi đó là quy định chặt chẽ hơn, mà thay vào đó là rào cản gia nhập. Về vấn đề đó tôi nghĩ có công đức. Để tăng chất lượng, điều đó rất gây tranh cãi.

Hiện tại bất kỳ John / Jane Doe đều có thể viết một chương trình. Không có rào cản để nhập cảnh. Chọn một vài cuốn sách về kịch bản và công nghệ web và bắt đầu hack, hoặc tệ hơn là chỉ bắt đầu Google để biết cách "làm" nó.

Khi cả một tập thể quyết định có lẽ đã đến lúc tăng các rào cản gia nhập, giữ cho ngành công nghiệp đạt tiêu chuẩn cao hơn, để phát triển từ hacker / thợ thủ công thành kỹ sư, đó là quy định mà tôi hoàn toàn tuân thủ.

Có quá nhiều cá nhân không đủ tiêu chuẩn lập trình ngày nay. Dù có hoạt động trên các hệ thống quan trọng hay không, họ vẫn đang sản xuất mã, vẫn sản xuất Big Balls of Mud .

Về vấn đề đó, tự điều chỉnh hoặc tạo ra các rào cản để nhập cảnh là một điều tốt. Bởi vì chúng tôi đang nói, hey, bạn không thể ra ngoài đường và tự gọi mình là Kỹ sư phần mềm. Bạn thực sự phải hạ cấp một mức độ kỹ năng.

Kỹ năng khử trùng không chỉ đơn thuần là làm bài kiểm tra hoặc nhận "huy hiệu danh dự". Một bài kiểm tra chỉ là một xác nhận. Xác nhận thực sự là Trường học, thực tập, học việc, cố vấn dưới người cao niên, thực hành, là tất cả một phần của nó.

Tôi có thể thấy những gì mà IEEE đang cố gắng đạt được, nhưng tại thời điểm này, nó là một bài tập không có kết quả. Ngành công nghiệp thay đổi nhanh chóng, quá nhiều nhu cầu đẩy sản phẩm ra khỏi cửa, tư duy "hacker", v.v ... Quy định phải xuất phát từ bên trong nếu có.


Tôi cho +1 vì sẽ có một số cách để tránh riff-raff khỏi một số loại hệ thống nhất định. Tuy nhiên, tôi cho -1 vì hầu hết các phần mềm ngày nay có thể được tin tặc phát triển đầy đủ và để ngăn chặn chúng không thể cung cấp dịch vụ đó để giảm chi phí là trái với lợi ích chung. Tương tự như vậy, các luật sư và bác sĩ cũng vậy. 90% những gì họ làm có thể được xử lý khá hiệu quả và cũng giống như những người có trình độ chuyên môn thấp hơn. Tuy nhiên, với luật pháp ngày nay, họ có thể tự do thu hút công chúng theo ý muốn.
Dunk

Không nên đánh giá các kỹ năng trong quá trình tuyển dụng. Đợi đã, HR thuê người dựa trên thông tin giấy (không thể hiện kiến ​​thức áp dụng trong phát triển phần mềm) và nhân sự hoàn toàn không biết gì về nhu cầu / yêu cầu để phát triển phần mềm. Double fail ...
Evan Plaice

0

Tôi chưa đọc bài báo này, nhưng nếu câu hỏi là liệu quy định của ngành phần mềm có thể mang lại lợi ích cho nhân loại hay không, tôi nghĩ nó phụ thuộc vào hoàn cảnh:

  1. Toàn bộ ngành công nghiệp bao gồm nhiều lĩnh vực khác nhau, một số lĩnh vực rất quan trọng trong cuộc sống (ví dụ: kiểm soát liều lượng phóng xạ trong thiết bị y tế) và một số trong đó không (ứng dụng Facebook "Bạn là ai?"). Tôi không thể thấy bất kỳ đối số nào cho quy định cho các ứng dụng có cổ phần thấp.

  2. Không nên bắt đầu với quy định pháp lý. Thay vào đó, người ta nên bắt đầu với một chương trình chứng nhận cho các nhà phát triển. Chỉ khi chương trình chứng nhận tạo ra một số lợi ích có thể đo lường được thì mới có câu hỏi về quy định pháp lý.

  3. Ngay cả khi một chương trình chứng nhận tạo ra kết quả có thể đo lường được, có khả năng ngành công nghiệp sẽ chuẩn hóa yêu cầu chứng nhận này vì lý do kinh doanh nghiêm ngặt và chúng tôi sẽ không cần quy định pháp lý. (Đây là lý do tại sao các phái đoàn như MCSE tồn tại - các công ty thích thuê MCSE cho các lĩnh vực mà MCSE được đào tạo.)

  4. Như đã nói, vẫn còn những lĩnh vực mà nó có ý nghĩa kinh doanh gây ra tác hại (thường đây là những tác động tiêu cực , đôi khi chúng là kết quả của sức mạnh thị trường đối với một số tổ chức). Ví dụ, một khu vực có thể có một bệnh viện địa phương duy nhất; trong trường hợp này, chất lượng của phần mềm back-end có thể tạo ra sự khác biệt lớn đối với mức độ chăm sóc mà bệnh nhân nhận được, nhưng không tạo ra sự khác biệt nhiều trong việc bệnh nhân chọn bệnh viện. Bệnh viện sau đó không nhất thiết phải có nhiều trường hợp kinh doanh để đầu tư vào các nhà phát triển chất lượng cao hơn. Trong trường hợp này, có thể có một trường hợp y tế công cộng để điều chỉnh các nhà phát triển mà bệnh viện được phép thuê.

IMHO.


0

Tôi phải trả lời cái này ...

Bắt đầu với những gì @JonathanHenson nói và sự gia nhập của @gnat, những gì tôi nói là ổn, những người có tiền có thể trả cho những thứ được chứng nhận, những người hoặc quốc gia không có tiền không thể trả tiền cho giấy phép (rất nhiều cho những thứ được chứng nhận ), vì vậy vẫn sẽ có những cuộc nổi loạn nếu điều đó đi vào thực tế. Ngay cả khi các phương thức phân phối truyền thống (và không quá truyền thống) bị đóng, mọi người vẫn sẽ tìm cách cung cấp phần mềm cho người dùng quan tâm. Ngay cả khi nó có nghĩa là phát triển một giao thức HTTP khác hoặc thậm chí là toàn bộ ngăn xếp mạng thay thế, chỉ tập trung vào việc tạo các kết nối không thể phát hiện được (xem đoạn cuối, để biết ai đó có thể làm điều này).

Ngoài ra, ý tưởng trả tiền cho một thứ gì đó, có nguy cơ, vì thế giới ngày càng nghèo hơn, vì vậy ngày càng nhiều người sẽ có ít tiền hơn để trả cho mọi thứ, thậm chí có những quốc gia chỉ sử dụng phần mềm FOSS, mà không có bất kỳ chứng nhận (Brazil và Ấn Độ đến với tâm trí, nhưng chắc chắn có những người khác), và một số quốc gia đang trở nên lớn, thực sự lớn. Và họ sử dụng phần mềm không chắc chắn được thực hiện bởi các lập trình viên chưa biết, người không biết kỹ năng.

Ngoài ra, ngay cả khi có một số loại chứng nhận, chứng nhận sẽ chỉ chứng nhận kiến ​​thức chứ không phải đạo đức, chỉ nghĩ rằng một số bác sĩ sử dụng nội tạng được lấy ra một cách trái phép từ mọi người, vì vậy cũng sẽ có những lập trình viên được chứng nhận. không có đạo đức và viết mã cẩu thả hoặc cố ý hoặc vô ý. Trong khi trong hầu hết các dự án FOSS, hầu hết các lập trình viên không có kỹ năng cũng xem xét mã từ những người khác và cố gắng tìm lỗi, theo cách làm cho lập trình cặp, một cái gì đó nhỏ.

Cuối cùng, bạn nói gì về các nhóm hack (không phải nhóm hacker mũ đen, mà là nhóm mũ trắng hoặc xám), biết nhiều về bảo mật và phát triển phần mềm bảo mật theo cách chỉ phù hợp với các lập trình viên chuyên nghiệp nhất từ ​​các bộ phận chính phủ nhất định.

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.