Là phát triển phần mềm là một ngành kỹ thuật?

Phát triển phần mềm có thể được coi là kỹ thuật? Nếu không, những thứ mà nó thiếu để có đủ điều kiện là một ngành kỹ thuật là gì? Liên quan đến vấn đề này là câu hỏi trên Stack Overflow về sự khác biệt giữa lập trình viên và kỹ sư phần mềm .

Có Viện Kỹ thuật phần mềm tại Đại học Carnigie Mellon quy định và duy trì các tiêu chuẩn CMMI. Đây có phải là một cái gì đó sẽ biến phát triển thành kỹ thuật?

Là kỹ thuật phát triển phần mềm? Nếu không, những thứ mà nó thiếu để có đủ điều kiện như vậy là gì?

Vâng, kỹ thuật phần mềm là một ngành kỹ thuật.

Wikipedia định nghĩa kỹ thuật là "ứng dụng toán học, cũng như kiến ​​thức khoa học, kinh tế, xã hội và thực tiễn để phát minh, đổi mới, thiết kế, xây dựng, bảo trì, nghiên cứu và cải tiến cấu trúc, máy móc, công cụ, hệ thống, thành phần, vật liệu , quy trình, giải pháp và tổ chức. " Kết quả của công nghệ phần mềm là một hệ thống phần mềm có thể cải thiện cuộc sống của con người và nó có thể bao gồm một số sự kết hợp của kiến ​​thức khoa học, toán học, kinh tế, xã hội hoặc thực tế.

Xét về cách nó được xem, về mặt học thuật và chuyên nghiệp, nó khác nhau. Các chương trình kỹ thuật phần mềm có thể được ABET công nhận là chương trình kỹ thuật. Các kỹ sư phần mềm có thể là thành viên của IEEE. Một số công ty coi công nghệ phần mềm là một chuyên ngành kỹ thuật, trong khi những công ty khác thì không - thực sự là một vấn đề.

Cuốn sách hay nhất về chủ đề 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, Nghề nghiệp nâng cao . Nó nhìn vào công nghệ phần mềm là một nghề, quá trình tiến hóa từ một nghề để một nghề, các khoa học về phát triển phần mềm, sự khác biệt giữa phần mềm kỹ thuật và phần mềm kỹ thuật (áp dụng thực hành kỹ thuật để phần mềm so với các kỹ sư người xảy ra để xây dựng các phần mềm, với một nghiên cứu trường hợp đó bao gồm trường cũ của tôi ), chứng nhận và cấp phép, và đạo đức.

Glenn Vanderburg có một loạt các cuộc nói chuyện gọi là "Kỹ thuật phần mềm thực sự" đã được đưa ra từ năm 2010 đến 2015 tại một số hội nghị, cùng với hai cuộc hội đàm liên quan, "Thủ công, Kỹ thuật và Tinh hoa lập trình" (được đưa ra vào năm 2011 như một bài phát biểu tại RailsConf) và "Kỹ thuật thủ công và phần mềm" (được đưa ra vào năm 2011 tại QCon London). Tôi nghĩ những cuộc nói chuyện này là một lập luận khá toàn diện cho lý do tại sao công nghệ phần mềm là một ngành kỹ thuật.

Một cuộc tranh luận, mà Vanderburg đưa ra một cách ngắn gọn trong các cuộc nói chuyện của mình, là cuộc tranh luận của Jack W. Reeves năm 1992 (và xem xét lại vào năm 2005) về thiết kế phần mềm là gì và cách mã hóa là đầu ra của các hoạt động thiết kế kỹ thuật phần mềm ( đây cũng là thảo luận về wiki C2). Một khi bạn thoát khỏi các trường phái tư tưởng cũ, nơi đặc tả và mô hình hóa là thiết kế phần mềm và thành mã là thiết kế phần mềm, một số mối quan hệ giữa công nghệ phần mềm và các ngành kỹ thuật khác trở nên dễ thấy hơn. Một số khác biệt và lý do cho những khác biệt đó càng trở nên rõ ràng hơn sau khi bạn thấy rằng kinh tế phát triển phần mềm khác biệt rất nhiều so với nhiều ngành khác - xây dựng là rẻ (trong hầu hết các trường hợp), trong khi thiết kế là phần đắt đỏ.

Đó có phải là [CMMI] thứ gì đó sẽ biến sự phát triển thành kỹ thuật không?

CMMI là một khung cải tiến quy trình cung cấp hướng dẫn cho các tổ chức về loại hoạt động nào hữu ích khi xây dựng phần mềm. Các ngành kỹ thuật thường có một quy trình kỹ thuật. Có một quá trình như vậy là rất quan trọng để hoàn thành thành công các dự án chất lượng cao. Điều đó nói rằng, CMMI (hoặc bất kỳ khung quy trình hoặc phương pháp luận nào khác) chỉ là một công cụ duy nhất - sử dụng nó sẽ không giúp bạn tiến bộ một cách kỳ diệu từ nhà phát triển sang kỹ sư. Tuy nhiên, không tuân theo một số loại quy trình, theo tôi, là một dấu hiệu của một dự án không phải là một dự án kỹ thuật.

Ngoài ra, ý kiến ​​của bạn về các khóa học / chứng chỉ kỹ thuật phần mềm là gì?

Nó chỉ có giá trị như những người khác đặt vào nó. Có những khóa học hữu ích và có những khóa học vô dụng. Có những chứng chỉ có giá trị và những chứng chỉ không xứng đáng với giấy mà chúng được in trên đó. Có rất nhiều yếu tố, từ người chứng thực hoặc công nhận khóa học hoặc người đang cấp chứng chỉ cho ngành công nghiệp hiện tại của bạn cho công việc hiện tại và nơi bạn muốn đi.

Xuất thân từ một nền tảng kỹ thuật điển hình, nhưng tạo dựng sự nghiệp trong phát triển phần mềm, tôi thấy sự tương đồng lớn giữa cả hai thế giới. Ngoài định nghĩa chính xác về kỹ thuật, tôi thấy trong thực tế phát triển phần mềm không khác gì phát triển một sản phẩm vật lý. Ít nhất tôi nghĩ nó không nên quá khác biệt.

Cho dù bạn thiết kế máy bay hay ứng dụng phần mềm, cho cả hai bạn đều cần:

• làm thiết kế
• định nghĩa các hệ thống con và các thành phần
• làm nguyên mẫu
• chỉ định và thực hiện các bài kiểm tra
• Vân vân.

Tôi đã đọc ở đâu đó trong một câu trả lời khác rằng thiết kế phần mềm là khác nhau bởi vì bạn không thiết kế mọi thứ trước khi bạn bắt đầu lập trình. Thực tế ở mức độ thấp hơn cũng là trường hợp khi bạn thiết kế một sản phẩm vật lý. Thiết kế và tạo mẫu và thử nghiệm là một quá trình lặp đi lặp lại.

Ngoài ra, khi các dự án phần mềm tăng kích thước, việc xác định các hệ thống con, thành phần và giao diện rõ ràng cũng tương tự như việc thiết kế các sản phẩm phức tạp như máy bay.

Đó là lý do tại sao tôi coi việc phát triển phần mềm là kỹ thuật.

Tôi sẽ tranh luận rằng thực sự có một thứ như kỹ thuật phần mềm.

Kỹ thuật liên quan đến việc áp dụng hệ thống kiến ​​thức khoa học vào giải pháp cho các vấn đề. Sự phức tạp của các vấn đề được giải quyết ngày nay không khác với những vấn đề được giải quyết bởi một kỹ sư điện trong việc tạo ra một mạch điện hoặc một kỹ sư hóa học trong việc tạo ra một quy trình sản xuất hoặc một kỹ sư cơ khí trong việc tạo ra một thiết bị.

Thực tế là cũng có một cách tiếp cận thực tế khi áp dụng các kế hoạch hiện có (phát triển trong trường hợp này) đơn giản tương tự như trong các lĩnh vực khác, ai đó thực hiện các kế hoạch đó (ví dụ, công nhân xây dựng).

Đúng là hầu hết các nhà phát triển cũng thực hiện các nhiệm vụ kỹ thuật phần mềm và giáo dục của chúng ta thường không phải là lập trình mà là kỹ thuật phần mềm. Vì vậy, chúng tôi có được bàn tay của chúng tôi bẩn trong khi một kỹ sư dân sự sẽ không.

Tuy nhiên, khả năng áp dụng ngôn ngữ lập trình và chương trình không biến một người thành kỹ sư: Tôi đã gặp những chia sẻ của tôi về những nhà phát triển thiếu hiểu biết thực sự về sự phức tạp và các vấn đề bên ngoài đoạn mã hiện tại của họ.

Đối với câu hỏi của bạn về CMU: Áp dụng tiêu chuẩn hoặc thực hành (ví dụ: CMMI) không tự động biến công việc của một người thành kỹ thuật. Tuy nhiên, thực tế là có những tổ chức thực hiện nghiên cứu khoa học để cung cấp các thực hành mới một lần nữa là một dấu hiệu cho thấy có một thứ như kỹ thuật.

Không, đó không phải là kỹ thuật. Chúng tôi không khoa học và chúng tôi không phải vượt qua bất kỳ bài kiểm tra kỹ thuật nhà nước nào. Trên thực tế, việc gọi cho bạn một "kỹ sư" ở một số nơi là bất hợp pháp do thiếu kiểm tra.

IMHO thuật ngữ 'công nghệ phần mềm' được đặt ra để cố gắng mô tả tốt hơn phạm vi của những thứ mà nhà phát triển làm, thay vì chỉ là một 'lập trình viên' (có quá nhiều quá trình cơ học với ít suy nghĩ hoặc sáng tạo).

Cá nhân tôi thích sự tương tự mới nổi của một nhà phát triển như một "thợ thủ công", được các lập trình viên thực dụng, trong số những người khác, vô địch.

Trong lịch sử, mọi người đã cố gắng tương tự việc tạo phần mềm với sản xuất. Tôi nghĩ rằng Jack Reeves đã đưa ra một lập luận khá hay để làm mất uy tín ý tưởng này trong bài viết của mình Thiết kế phần mềm là gì .

Từ Wiki:

Kỹ thuật:

Công nghệ phần mềm là việc áp dụng một cách tiếp cận có hệ thống, có kỷ luật, có thể định lượng để phát triển, vận hành và bảo trì phần mềm và nghiên cứu các phương pháp này; đó là ứng dụng kỹ thuật vào phần mềm

Phát triển phần mềm

Phát triển phần mềm là tập hợp các hoạt động dẫn đến các sản phẩm phần mềm. Phát triển phần mềm có thể bao gồm nghiên cứu, phát triển mới, sửa đổi, tái sử dụng, tái thiết kế, bảo trì hoặc bất kỳ hoạt động nào khác dẫn đến các sản phẩm phần mềm. [1]

Đặc biệt là giai đoạn đầu tiên trong quy trình phát triển phần mềm có thể có sự tham gia của nhiều bộ phận, bao gồm tiếp thị, kỹ thuật, nghiên cứu và phát triển và quản lý chung.

Vì vậy, chúng khá giống nhau và cũng có thể có nghĩa tương tự.

Từ điển.com : vi · gi · neer · ing / ndʒəˈnɪərɪŋ /

Tập hợp 1. nghệ thuật hoặc khoa học ứng dụng thực tế các kiến ​​thức về khoa học thuần túy, như vật lý hoặc hóa học, như trong việc xây dựng các động cơ, cầu, tòa nhà, mỏ, tàu và nhà máy hóa chất.

Tôi muốn nói rằng việc tạo ra phần mềm là ứng dụng thực tế của toán học và khoa học máy tính, và có khả năng của bất kỳ số lượng khoa học thuần túy nào khác tùy thuộc vào ứng dụng.

[EDIT] FWIW, tôi không tự gọi mình là kỹ sư phần mềm, mà là nhà phát triển phần mềm nên tôi không có cổ phần cá nhân trong việc này.

Theo quan điểm của tôi, Kỹ sư phần mềm và Nhà phát triển phần mềm là hai điều khác nhau.

Tôi thấy một kỹ sư phần mềm là một người lập kế hoạch, chẳng hạn như vòng đời sẽ phát triển, yêu cầu / thông số kỹ thuật, v.v ... Về cơ bản, một kỹ sư phần mềm xử lý rất nhiều tài liệu. Điều này có thể được thực hiện bởi một nhà phát triển phần mềm và / hoặc người quản lý dự án.

Một nhà phát triển phần mềm sẽ liên quan chặt chẽ hơn với một lập trình viên nhưng có nhiều kỹ năng hơn trong các lĩnh vực khác như quản lý cơ sở dữ liệu, v.v.

Một điều thú vị để đưa lên là Kiến trúc . Một số người cũng tham gia tìm ra phần cứng / phần mềm nào sẽ cần thiết cho vòng đời của dự án.

Tôi sẽ đi với "Không" ở đây. Anh trai tôi là một kỹ sư cơ khí, và anh ấy mô tả kỹ thuật là "Nghệ thuật rẻ tiền":

"Các kỹ sư quan tâm nhiều hơn đến việc hoàn thành công việc nhanh nhất có thể, với chi phí thấp nhất có thể, với ít vật liệu nhất có thể. "

Trong phản ứng, tôi đã đến để mô tả phát triển phần mềm (không phải kỹ thuật phần mềm - về cơ bản chúng thực sự là hai lĩnh vực riêng biệt) là "Nghệ thuật hiệu quả":

"Các nhà phát triển quan tâm nhiều hơn đến việc hoàn thành công việc nhanh nhất có thể, với chi phí thấp nhất có thể, với số lần lặp lại ít nhất có thể. "

Sự khác biệt là trong phần cuối của những câu đó.

Là kỹ thuật phát triển phần mềm?

Không. Trở thành kỹ sư có nghĩa là dự án của bạn tuân theo mốc thời gian nguyên nhân - bạn tuân theo các quy tắc xây dựng, do đó tòa nhà của bạn không bị đổ (hoặc ít nhất bạn không thể đổ lỗi nếu có). Viết phần mềm, bạn có thể làm theo tất cả các hướng dẫn đang diễn ra (và có rất nhiều phần khác nhau để lựa chọn!) Và phần mềm vẫn có thể bị treo / gặp sự cố / đưa ra câu trả lời sai (trừ khi bạn tham gia vào lĩnh vực viết nhỏ các chương trình có thể chứng minh được ngôn ngữ chức năng không hiệu quả).

Tôi thấy một kỹ sư (cơ khí, kết cấu, phần mềm) là người thiết kế sản phẩm dựa trên nhu cầu đã hiểu và hiểu về những gì và làm thế nào để áp dụng các vật liệu để đáp ứng nhu cầu đó.

Ví dụ, bạn có thể thường thấy một kỹ sư kết cấu tìm kiếm các cường độ khác nhau của thép và áp dụng các quy tắc vật lý để tính toán các vật liệu cần thiết và cách chúng nên được thực hiện. Kỹ thuật kết cấu là một ví dụ điển hình bởi vì bạn luôn kết thúc với một kế hoạch chi tiết (đặc điểm kỹ thuật) về những gì bạn sẽ xây dựng trước khi bạn xây dựng. Điều đó không phải lúc nào cũng xảy ra với phần mềm.

Đối với tôi, điểm khác biệt của kỹ sư phần mềm và lập trình viên là kỹ sư có khả năng xây dựng đặc tả cho những gì sẽ được tạo ra trước khi viết bất kỳ mã nào, trong đó lập trình viên chỉ viết mã dựa trên thông số kỹ thuật của ai đó hoặc là một trong số đó lập trình viên miền tây hoang dã người viết mã mà không có thông số kỹ thuật. Cũng như, kỹ sư có bằng cấp của mình.

Tôi ví sự khác biệt giữa một công nhân xây dựng và một kỹ sư kết cấu với sự khác biệt giữa một lập trình viên và một kỹ sư phần mềm.

Để làm rõ, tôi chỉ có bằng tốt nghiệp đại học, vì vậy không thể gọi mình là kỹ sư.

Tôi sẽ không coi thuật ngữ "kỹ thuật" là phù hợp nhất để mô tả phát triển phần mềm, vì 2 lý do chính:

• Nó truyền tải rất nhiều ý tưởng, khái niệm cũ và cái gọi là "quy tắc vàng" bắt nguồn từ các ngành kỹ thuật truyền thống như công nghiệp, dân dụng, hải quân hoặc cơ khí. Tôi đang nói về các quy tắc trong phân công lao động, quy trình sản xuất, tiêu chuẩn chất lượng ... Những điều này thường chỉ áp dụng một chút cho phần mềm.

• Nó không thể mô tả một cách thỏa mãn những gì lập trình có nhiều hơn các ngành khác (và tôi tin rằng nó có nhiều và khác biệt nhiều), và những thách thức mới mà các nhà phát triển phải đối mặt hàng ngày so với các đối tác truyền thống của họ lĩnh vực liệt kê. Bản chất ảo và phi vật chất của phần mềm đóng một vai trò rất lớn trong đó.

Phát triển phần mềm từ lâu đã được coi là "chỉ là một ngành kỹ thuật khác". Xem xét tỷ lệ thất bại của các dự án phần mềm mà chúng tôi đã biết từ khi chúng được đo lường, đã đến lúc chúng tôi nhận ra sự phát triển là một động vật hoàn toàn mới, mã là một vòng đời vật liệu và ứng dụng thực sự đặc biệt như một chu kỳ sản xuất hoàn toàn khác và ngừng cố gắng một cách tuyệt vọng để áp dụng công thức nấu ăn cũ cho họ.

Có, người ta sẽ có thể áp dụng các tiêu chuẩn và nguyên tắc để đi đến một sản phẩm phong nha. Điều gây khó khăn là suy nghĩ của khách hàng (chỉ là mã - không nên tốn quá nhiều tiền để thay đổi), cực kỳ khó khăn trong việc mã hóa những gì sản phẩm nên làm thành mã máy (ngôn ngữ nói / viết thành mã) và định lượng " chất lượng". Định nghĩa của bạn về chất lượng không phải là của tôi.

Nó cũng lặp lại. Lấy một bộ các yêu cầu và đưa nó cho hai đội. Khi bạn có thể hiểu điều tương tự (không có các đội nói chuyện với nhau), bạn khá gần với kỹ thuật.

Các lĩnh vực kỹ thuật khác cũng có hình phạt và xem xét cứng nhắc và ký tắt. Trách nhiệm giải trình.

Không. Kỹ thuật phần mềm không phải là kỹ thuật. Theo tôi, sự khác biệt nằm ở lượng sáng tạo liên quan. Trong Kỹ thuật Xây dựng, ví dụ, có thể có rất ít hoặc không có sự sáng tạo. Đây là một điều tốt.

Để xây dựng một cây cầu, bạn có một bộ thông số kỹ thuật (tôi cần phải đưa số lượng ô tô này từ bên này sang bên kia sông).

Từ điều này, tôi có thể suy luận:

1. số làn đường tôi cần (sử dụng tính toán tiêu chuẩn do chính phủ xác định);
2. tải tôi sẽ cần hỗ trợ (sử dụng các tính toán được xác định bởi chính phủ)
3. các vật liệu tôi cần sử dụng để hỗ trợ các tải trọng đó (sử dụng một trong hai vật liệu tiêu chuẩn mà tôi có thể nhận được từ một số nhà cung cấp khác nhau hoặc vật liệu không chuẩn mà sau đó tôi phải chứng minh sẽ có các đặc tính chính xác).

Sau đó, tôi phải được thiết kế phê duyệt và kiểm tra bởi bên thứ ba (một công ty khác) để đảm bảo rằng tôi đã thực hiện các tính toán của mình một cách chính xác.

Sau đó, khi cây cầu thực sự được xây dựng, công việc sẽ được thực hiện bởi những người có trình độ theo cách tiêu chuẩn. Họ sẽ làm những công việc mà họ đã làm hàng trăm, có thể hàng ngàn lần trước đây.

Đừng hiểu sai ý tôi, mỗi dự án kỹ thuật dân dụng đều khác nhau, nhưng dường như mỗi lần tôi phát triển một ứng dụng / trang web mới, mọi thứ lại được thực hiện khác nhau.

Có, tôi đoán rằng sự phát triển là một tập hợp con của kỹ thuật:

• Công nghệ phần mềm bao gồm các đặc điểm kỹ thuật ban đầu ("chúng ta cần loại phần mềm nào ở đây?"), Được cho là có trước sự phát triển
• "Kỹ thuật" cũng có thể bao gồm ví dụ: xác định Quy trình đảm bảo chất lượng, chắc chắn có liên quan đến phát triển nhưng cũng có thể được cho là nằm ngoài phạm vi của chính 'công trình'.

Code Complete định nghĩa "xây dựng" là đồng nghĩa với mã hóa và gỡ lỗi (và nhận xét), cũng với thiết kế chi tiết trước và với kiểm tra đơn vị và tích hợp sau đó. Chương 1, Chào mừng bạn đến với Xây dựng phần mềm (PDF) bắt đầu bằng cách liệt kê nhiều chủ đề trong Vòng đời phát triển phần mềm tổng thể (bao gồm Định nghĩa sự cố, Kiến trúc phần mềm, Bảo trì khắc phục, v.v.), sau đó nói,

Như số liệu chỉ ra, xây dựng chủ yếu là mã hóa và gỡ lỗi nhưng cũng bao gồm thiết kế chi tiết, lập kế hoạch xây dựng, thử nghiệm đơn vị, tích hợp, thử nghiệm tích hợp và các hoạt động khác. Nếu đây là một cuốn sách về tất cả các khía cạnh của phát triển phần mềm, thì nó sẽ có các cuộc thảo luận cân bằng độc đáo về tất cả các hoạt động trong quá trình phát triển. Bởi vì đây là một cuốn sổ tay về kỹ thuật xây dựng, tuy nhiên, nó đặt trọng tâm sai lệch vào xây dựng và chỉ chạm vào các chủ đề liên quan. Nếu cuốn sách này là một con chó, nó sẽ rúc vào xây dựng, vẫy đuôi trong thiết kế và thử nghiệm, và sủa vào các hoạt động phát triển khác.

Phát triển phần mềm là kỹ thuật.

Một vài lập luận được đưa ra bởi những người khác về lý do tại sao công nghệ phần mềm không đáp ứng tiêu chuẩn kỹ sư:

Một số người nói rằng các kỹ sư đang kinh doanh trong việc thiết kế "những thứ" vì lợi ích công cộng - ICBM, Tanks, v.v ... có phải là hàng hóa công cộng không? Một số người sẽ nói đồng ý (một hành vi phạm tội tốt là phòng thủ tốt) những người khác sẽ nói không. Tuy nhiên, tôi không nghĩ ai sẽ không đồng ý rằng anh chàng thiết kế hệ thống nhắm mục tiêu xe tăng thế hệ tiếp theo là một kỹ sư. Công tốt có thể chủ quan. Ở bất kỳ giá nào, rất nhiều phần mềm là vì lợi ích công cộng, vì vậy vấn đề là phải đi theo một trong hai cách.

Những người khác nói rằng các kỹ sư thiết kế họ không xây dựng. Tôi đã thấy một số ý kiến ​​loại "kỹ sư cơ khí không hàn". Tôi sẽ lập luận rằng các kỹ sư cơ khí sản xuất đồ án - thiết kế chi tiết mà một cái gì đó khác thực hiện. Nếu một kỹ sư cơ khí sản xuất một kế hoạch chi tiết và cung cấp cho máy CNC thì điều đó khiến họ không còn là kỹ sư cơ khí nữa - bởi vì một cỗ máy đã thực hiện thay vì một người? Tôi sẽ lập luận rằng mã nguồn là một bản kế hoạch chi tiết được cung cấp cho một máy thực hiện và tôi không thấy nó khác với mã cấp liệu MechE cho máy CNC như thế nào. Và bây giờ chúng ta có máy in 3d, điều đó có nghĩa là sự kết thúc của các kỹ sư cơ khí? Có phải họ đang phát triển cơ khí?

Giấy phép là chủ đề khác mà tôi thấy xuất hiện. Hiện tại chỉ có một vài kỹ sư phần mềm giấy phép tài phán. Không có (cho đến nay) không có giấy phép kỹ sư phần mềm rộng rãi của Hoa Kỳ (tôi nghĩ chỉ Texas mới làm như vậy). Một số người đã sử dụng điều này như một lý do để nói rằng công nghệ phần mềm không nên được gọi là kỹ thuật. PE cho các kỹ sư phần mềm đang đến. Nhưng ở cấp độ triết học hơn chỉ vì một số nhà lập pháp tiểu bang chọn (hoặc không) để gọi kỹ thuật phát triển phần mềm không có tác dụng đối với thực tế.