N.V. Komleva, A.A. Sách giáo khoa khoa học máy tính và lập trình Smirnov. Lập trình ≠ khoa học máy tính

Lập trình

Dịch

Phát triển phần mềm như thể trong mặt tồi tệ nhất khác với các ngành khoa học máy tính khác.

Một vài năm trước tôi đang nghiên cứu các thuật toán và độ phức tạp. Một lĩnh vực sạch đẹp, nơi mọi khái niệm đều được xác định rõ ràng, mọi kết quả đều được xây dựng dựa trên bằng chứng trước đó. Khi bạn biết một sự thật trong lĩnh vực này, bạn có thể dựa vào nó vì chính toán học đã suy luận ra nó. Ngay cả những kết quả không hoàn hảo, như thuật toán gần đúng và xác suất, cũng có sự phân tích nghiêm ngặt về sự không hoàn hảo của chúng. Các ngành khoa học máy tính khác, chẳng hạn như cấu trúc liên kết mạng và mật mã, cũng có trạng thái thỏa đáng tương tự.

Và bây giờ tôi làm việc trong lĩnh vực phát triển phần mềm, và đây là một chủ đề cực kỳ khó hiểu. Không có khái niệm nào được xác định chính xác. Kết quả được đánh giá là “thường” hoặc “nói chung”. Nghiên cứu hôm nay có thể hoặc không thể cung cấp thông tin cho công việc ngày mai. Các phương pháp tiếp cận mới thường đảo ngược các phương pháp trước đó, bùng nổ trong thời gian ngắn và sau đó trở nên lỗi thời khi những hạn chế của chúng xuất hiện. Chúng tôi tin vào lập trình có cấu trúc. Sau đó, họ bắt đầu tin vào các ngôn ngữ thế hệ thứ tư, rồi vào các phương pháp hướng đối tượng, rồi vào lập trình cực đoan, và bây giờ, có lẽ, ở dạng nguồn mở.

Nhưng lập trình chính xác là nơi lốp xe tiếp xúc với nhựa đường. Rất ít người quan tâm liệu nó có thực sự bằng nhau hay không, hoàn toàn vì vẻ đẹp của câu hỏi. Khu vực máy tính giao dịch với máy tính. Đây là việc viết các chương trình để giải quyết các vấn đề thực sự của con người và chạy các chương trình này trên xe thật. Theo luận điểm Church-Turing, mọi thứ Thiết bị máy tính về cơ bản là tương đương. Vậy bây giờ kiến trúc máy tính Thật tuyệt, hạn chế thực sự của khoa học máy tính vẫn là vấn đề tạo ra phần mềm. Chúng ta muốn các chương trình có thể được hoàn thành trong một khoảng thời gian hợp lý và với chi phí hợp lý, hoạt động gần đúng như dự định của nhà thiết kế và chạy không có lỗi.

Với mục tiêu này, tôi luôn trăn trở về một câu hỏi (giống như nhiều nhà nghiên cứu khác): tại sao các lập trình viên không thể đạt được kết quả khắt khe hơn như các lĩnh vực khoa học máy tính khác? Nói cách khác, “Có thể biến bao nhiêu kiến trúc và thiết kế phần mềm thành chính thức và có thể chứng minh được?” Câu trả lời cho câu hỏi này nằm trong Hình 1.

Hình 1: Đường sáng trong khoa học máy tính

Các chủ đề trên dòng này thuộc về phát triển phần mềm. Các lĩnh vực nghiên cứu dưới đường này là các môn học cốt lõi của khoa học máy tính. Sau này có kết quả rõ ràng, chính thức. Vì vấn đề mở trong lĩnh vực này, chúng tôi hy vọng sẽ đạt được những kết quả mới sẽ được hình thành chính thức. Các chủ đề này được xây dựng dựa trên nhau: ví dụ: mật mã về độ phức tạp và trình biên dịch về thuật toán. Hơn nữa, chúng tôi tin rằng kết quả đã được chứng minh trong các lĩnh vực này sẽ vẫn như vậy sau 100 năm nữa.

Vậy vạch sáng này là gì và tại sao không có chủ đề lập trình nào bên dưới nó? Đường dây này là một phẩm chất được gọi là "sự tham gia trực tiếp của con người". Phát triển phần mềm có chất lượng này, nhưng khoa học máy tính truyền thống thì không. Mọi người có thể sử dụng kết quả từ các nguyên tắc dưới dòng nhưng những kết quả này không bị ảnh hưởng trực tiếp ảnh hưởng của người.

Phát triển phần mềm có yếu tố con người vốn có. Ví dụ, độ tin cậy vận hành phần mềm là khả năng con người hiểu, tìm và sửa lỗi. hệ thống phần mềm. Độ tin cậy vận hành có thể bị ảnh hưởng bởi một số khái niệm khoa học máy tính chính thức - có lẽ là độ phức tạp theo chu kỳ của biểu đồ điều khiển phần mềm. Nhưng độ tin cậy trong vận hành phụ thuộc rất nhiều vào con người và khả năng hiểu ý nghĩa cũng như mục đích của mã nguồn. Câu hỏi liệu một hệ thống phần mềm cụ thể có độ tin cậy vận hành cao hay không không thể được trả lời đơn giản bằng cách nghiên cứu phần mềm một cách máy móc.

Bảo mật cũng vậy. Các nhà nghiên cứu đã sử dụng một số phương pháp chính thức để tìm ra tác động của hệ thống phần mềm đối với sức khỏe và tài sản của con người. Nhưng không có cuộc thảo luận nào về bảo mật phần mềm có thể được coi là hoàn chỉnh nếu không đề cập đến thành phần con người của hệ thống đang được nghiên cứu. Tương tự như vậy đối với việc phát triển các yêu cầu. Chúng tôi có thể phát triển bất kỳ kỹ thuật khảo sát nào để đưa ra các yêu cầu chính xác từ các bên liên quan và có thể tạo ra hệ thống khác nhauđể ghi lại chúng. Nhưng không có nghiên cứu nào trong lĩnh vực này sẽ thay đổi được thực tế rằng việc thu thập yêu cầu thường liên quan đến việc nói chuyện hoặc quan sát mọi người. Đôi khi những người này nói với chúng tôi Thông tin chính xác, và đôi khi không. Đôi khi người ta nói dối, có lẽ vì những lý do chính đáng. Đôi khi mọi người thành thật cố gắng truyền đạt thông tin chính xác nhưng không làm được điều đó.

Quan sát này dẫn đến Luận án của Connell:

Phát triển phần mềm sẽ không bao giờ là một ngành học nghiêm ngặt với kết quả đã được chứng minh vì nó liên quan đến hoạt động của con người.

Đây là một phát biểu phi toán học về ranh giới của các hệ thống hình thức. Tôi không có bằng chứng ủng hộ hay chống lại. Nhưng thực tế là vấn đề con người vẫn là vấn đề trọng tâm trong phát triển phần mềm:

Chương trình này phải làm gì? (yêu cầu, khả năng sử dụng, bảo mật)
Chương trình bên trong trông như thế nào để có thể dễ dàng sửa chữa và sửa đổi? (kiến trúc, thiết kế, khả năng mở rộng, tính di động, khả năng mở rộng)
Sẽ mất bao lâu để viết nó? (cấp)
Chúng ta nên phát triển nó như thế nào? (mã hóa, kiểm tra, đo lường, cấu hình)
Làm thế nào để một nhóm làm việc hiệu quả? (quản lý, quy trình, tài liệu)

Tất cả những vấn đề này đều xoay quanh con người.

Luận án của tôi giải thích tại sao việc phát triển phần mềm lại khó khăn và trơn trượt đến vậy. Các phương pháp đã được chứng minh của một nhóm lập trình viên này không hiệu quả với các nhóm khác. Việc phân tích toàn diện các dự án trước đây có thể không hữu ích cho việc đánh giá tốt dự án tiếp theo. Mỗi công cụ phát triển mang tính cách mạng chỉ giúp ích được một chút nhưng sau đó lại không đạt được những hứa hẹn tuyệt vời. Nguyên nhân là do con người quá mềm yếu, dễ thất vọng và khó đoán.

Trước khi chuyển sang ý nghĩa trong tuyên bố của tôi, chúng ta hãy xem xét ba phản đối hợp lý:

Luận án tự nó hiện thực hóa. Nếu một lĩnh vực phát triển phần mềm nào đó đột nhiên có định nghĩa nghiêm ngặt, thì bạn chỉ cần thay đổi định nghĩa phát triển phần mềmđể loại bỏ vấn đề này khỏi nó.

Ở một khía cạnh nào đó, sự phản đối này đúng, nhưng không phải trong mọi việc. Tôi lập luận rằng tập hợp các nguyên tắc thường được gọi là công nghệ phần mềm sẽ tiếp tục thách thức các giải pháp khắt khe. Các khía cạnh hẹp của một số vấn đề có thể phù hợp với cách tiếp cận chính thức, nhưng thành công của chúng sẽ chỉ nằm ở ngoại vi của các vấn đề phát triển cốt lõi.

Kết quả thống kê trong lập trình đã bác bỏ luận điểm này.

Các phương pháp này thường giải quyết vấn đề ước tính và bao gồm Đếm điểm chức năng, COCOMO II, PROBE và các phương pháp khác. Mặc dù có vẻ ngoài toán học nhưng những phương pháp này không phải là bằng chứng hay kết quả chính thức. Những số liệu thống kê như vậy chỉ đơn giản là một nỗ lực nhằm định lượng trải nghiệm chủ quan của con người về các dự án phần mềm trong quá khứ và ngoại suy nó cho các dự án trong tương lai. Đôi khi nó hoạt động. Nhưng những công thức có vẻ nghiêm ngặt trong những kế hoạch này lại là một con lợn với son môi, để sử dụng một cách diễn đạt hiện đại. Ví dụ: một trong các công thức trong COCOMO II trông như thế này: , trong đó , a là một tập hợp năm yếu tố tỷ lệ, chẳng hạn như “sự linh hoạt trong phát triển” và “sự gắn kết của nhóm”. Bản thân công thức có vẻ nghiêm ngặt nhưng nó bị chi phối bởi một chỉ số được tạo thành từ yếu tố con người.

Các quy trình phát triển chính thức, chẳng hạn như phương pháp phòng sạch, đang dần tìm ra những phương pháp nghiêm ngặt và có thể chứng minh được. Họ nâng cao một đường sáng để đưa các chủ đề mờ nhạt trước đây vào bên dưới.

Quả thực, các nhà nghiên cứu quy trình chính thức đang chứng minh sự tiến bộ trong việc giải quyết vấn đề khác nhau. Nhưng họ có thể bị phát hiện vi phạm điều phản đối đầu tiên trong danh sách này: họ định nghĩa việc phát triển phần mềm quá hẹp để có thể đưa mình vào một giải pháp nghiêm ngặt. Các phương pháp chính thức chỉ đơn giản là cung cấp cách giải thích thuận tiện cho bất kỳ vấn đề nào dựa trên sự tham gia và giải thích của con người. Ví dụ, yếu tố then chốt của các phương pháp phát triển hình thức là việc tạo ra các đặc tả nghiêm ngặt, rõ ràng. Các thông số kỹ thuật này sau đó được sử dụng để hướng dẫn (và chứng minh) các bước phát triển tiếp theo. Tất nhiên, một phương pháp hình thức có thể chứa một sơ đồ ký hiệu ngữ nghĩa rõ ràng. Nhưng không có phương pháp chính thức nào chứa đựng một công thức chính xác về cách chuyển tải những suy nghĩ mơ hồ của mọi người một cách rõ ràng về những gì một chương trình nên làm.

Chống lại những phản đối này, tôi cho rằng công nghệ phần mềm về cơ bản khác với khoa học máy tính chính thống, truyền thống. Cái đầu tiên phụ thuộc vào con người, nhưng cái thứ hai thì không. Điều này đưa chúng ta đến Kết luận của Connell:

Chúng ta nên ngừng cố gắng chứng minh những kết quả cơ bản trong phát triển phần mềm và nhận ra rằng những tiến bộ đáng kể trong lĩnh vực này sẽ chỉ là những khuyến nghị chung.

Ví dụ, David Parnas vào năm 1972 đã viết một bài báo khoa học tuyệt vời “Về tiêu chí phân tách một hệ thống thành các mô-đun”. Nó mô tả một thử nghiệm đơn giản mà Parnas đã thực hiện với các chiến lược thiết kế phần mềm thay thế, một chiến lược ẩn thông tin và một thử nghiệm khác với khả năng hiển thị dữ liệu toàn cầu. Sau đó, dựa trên thí nghiệm nhỏ này, ông đã rút ra một số kết luận và đưa ra khuyến nghị. Không có gì trong bài viết được chứng minh và Parnas không đảm bảo rằng mọi người sẽ nhận được kết quả như nhau khi làm theo các khuyến nghị. Nhưng bài viết có lời khuyên khôn ngoan và ảnh hưởng lớn đến sự phổ biến của các ngôn ngữ lập trình hướng đối tượng.

Một ví dụ khác là Bạn đã làm rất tốt học viện kỹ thuật phần mềm tại Đại học Carnegie Mellon, được gọi là CMMI. CMMI bắt đầu như một mô hình quy trình phát triển phần mềm và hiện đã phát triển để bao gồm các loại dự án khác. CMMI dài khoảng 1.000 trang—không bao gồm ví dụ, diễn giải và tài liệu đào tạo—và thể hiện hơn 1.000 năm công tác. Nhiều tổ chức lớn đã sử dụng nó và đạt được tiến bộ đáng kể trong quy trình và sản phẩm phát triển phần mềm của họ. Nhưng không có một kết quả nào được chứng minh chắc chắn về CMMI. Nó chỉ đơn giản là một tập hợp các đề xuất (được nghiên cứu kỹ lưỡng) về cách tổ chức một dự án phần mềm dựa trên các phương pháp đã từng áp dụng cho các tổ chức khác trong quá khứ. Trên thực tế, Viện Kỹ thuật Phần mềm tuyên bố rằng CMMI thậm chí không phải là một quy trình mà là một siêu quy trình, các chi tiết về quy trình này được mỗi tổ chức điền vào.

Các lĩnh vực nghiên cứu khác có cùng quan điểm là các mẫu thiết kế, phong cách kiến trúc, tái cấu trúc có vấn đề, phát triển linh hoạt và trực quan hóa dữ liệu. Những nguyên tắc này có thể mang lại những kết quả đã được chứng minh một phần, nhưng nhìn chung chúng nhắm đến các hệ thống vốn có sự tham gia của con người. Để rõ ràng: chủ đề chính Khoa học Máy tính (bên dưới vạch sáng) là những công cụ quan trọng đối với bất kỳ nhà phát triển nào. Kiến thức về thuật toán rất quan trọng khi thiết kế các ứng dụng hiệu suất cao. Lý thuyết xếp hàng giúp thiết kế hạt nhân hệ điều hành. Phương pháp phòng sạch cũng hữu ích trong một số trường hợp. Phân tích số liệu thống kê có thể hữu ích khi lập kế hoạch cho các dự án tương tự với một nhóm người tham gia tương tự. Nhưng chủ nghĩa hình thức đơn giản là cần thiết chứ không phải đủ điều kiệnđể phát triển tốt. Hãy lấy ngành xây dựng và kiến trúc (tức là nhà ở và công trình kiến trúc) làm ví dụ.

Hãy tưởng tượng một kỹ sư xây dựng xuất sắc, chuyên gia giỏi nhất thế giới về vật liệu xây dựng, mối quan hệ ứng suất-biến dạng, phân bổ tải trọng, bảo vệ chống đứt gió và động đất, v.v. Anh chàng này được liệt kê trong danh sách sổ ghi chép kiến trúc sư ở mọi quốc gia đều gọi cho ông để được tư vấn về mọi dự án xây dựng. Liệu kỹ sư xây dựng huyền thoại này có giỏi thiết kế những tòa nhà mà anh ta phân tích không? Không có gì. Anh ta có thể bị cuốn vào các cuộc trò chuyện với khách hàng, không thể thiết kế những nơi dễ chịu để sống, thiếu trí tưởng tượng để đưa ra giải pháp cho những vấn đề mới và cực kỳ nhàm chán. Kỹ thuật xây dựng rất hữu ích cho các kiến trúc sư thực thụ, nhưng chúng không đủ cho một thiết kế tốt. Kiến trúc thành công đòi hỏi sự sáng tạo, ý tưởng, tư duy liên ngành và chủ nghĩa nhân văn.

Tương tự như vậy, khoa học máy tính cổ điển rất hữu ích trong phát triển phần mềm, nhưng sẽ không bao giờ là đủ. Thiết kế phần mềm tốt còn đòi hỏi tính sáng tạo, ý tưởng, tư duy liên ngành và chủ nghĩa nhân văn. Quan sát này giải phóng các nhà nghiên cứu quy trình phần mềm. Họ có thể dành thời gian để học các kỹ thuật thành công - xây dựng nền tảng kiến thức tổng hợp cho những người thực hành trong tương lai. Chúng ta không nên ép việc phát triển phần mềm vào việc mở rộng khoa học máy tính để cơ sở toán học. Điều này sẽ không hiệu quả và có thể khiến chúng ta mất tập trung vào những khám phá hữu ích vẫn đang chờ được khám phá.

Sự nhìn nhận
Cảm ơn Steve Homer vì cuộc thảo luận đã làm tôi quan tâm đến vấn đề này.

Cuốn sách hướng dẫn này trình bày các khái niệm cơ bản trong lĩnh vực khoa học máy tính và các nguyên tắc cơ bản của lập trình cũng như các ví dụ thực tế.
Cuốn sách này dành cho sinh viên các chuyên ngành sau: - “Quản lý”, “Quản lý tổ chức”, “Quản lý nhân sự”, “Thương mại”, “Tiếp thị”, “Kinh tế thế giới”, “Quản lý khủng hoảng”, “Kế toán, phân tích”. và Kiểm toán”, “Tài chính và tín dụng”, “Ngôn ngữ học”, “Thuế và thuế”, “Tâm lý học”.

Theo khoa học máy tính ở theo nghĩa rộngđược hiểu là tập hợp nhiều ngành khoa học, công nghệ và sản xuất khác nhau có liên quan đến xử lý thông tin. TRONG theo nghĩa hẹp Khoa học máy tính có thể được biểu diễn dưới dạng tập hợp các phần được kết nối với nhau sau đây:
1) phương tiện kỹ thuật (phần cứng);
2) phần mềm;
3) công cụ thuật toán (brainware).
Điều đặc trưng là khoa học máy tính, theo cả nghĩa rộng và nghĩa hẹp, có thể được nhìn nhận từ các quan điểm khác nhau:
- Là một nhánh của nền kinh tế quốc dân;
- như một khoa học cơ bản;
- Là một môn học ứng dụng
Thuật ngữ “thông tin” xuất phát từ từ Latinh“Informatio”, có nghĩa là làm rõ, nhận thức, trình bày. Khoa học máy tính coi thông tin là những thông tin, dữ liệu, khái niệm được liên kết với nhau về mặt khái niệm làm thay đổi quan niệm của chúng ta về một hiện tượng hoặc đối tượng trong thế giới xung quanh. Cùng với thông tin, khái niệm dữ liệu thường được sử dụng trong khoa học máy tính. Dữ liệu có thể được coi là dấu hiệu hoặc quan sát được ghi lại khoảnh khắc này không được sử dụng, nhưng được lưu trữ. Khi dữ liệu được đưa vào sử dụng, nó sẽ biến thành thông tin.

Mục lục
Thông tin về tác giả 5
1. Khoa học máy tính 7
1.1. Thông tin và tin học hóa xã hội 8
1.2. Đo lường và trình bày thông tin 9
1.3. Phương tiện kỹ thuật thực hiện quá trình thông tin 10
1.4. Công cụ phần mềm thực hiện quy trình thông tin 14
1.5. Công nghệ lập trình 15
2. Thuật toán hóa quy trình xử lý dữ liệu 21
2.1. Các khái niệm và định nghĩa cơ bản 22
2.2. Công cụ mô tả thuật toán 23
2.3. Đặc điểm và phân loại dữ liệu 24
3. Cấu trúc ngôn ngữ cơ bản Lập trình Pascal 29
3.1. Các nội dung chính của chương trình trên ngôn ngữ Pascal 30
3.2. Toán tử ngôn ngữ 32
3.3. Điều hành có điều kiện và việc sử dụng nó để tổ chức phân nhánh 34
3.4. Quản lý chi nhánh bằng cách sử dụng câu lệnh Case 35
3.5. Tổ chức các quá trình tuần hoàn 37
3.6. Xử lý thông tin tượng trưng 41
3.7. Tổ chức thực hiện chương trình trong môi trường DELPHI 43
4. Xử lý phần mềm kiểu kết cấu 49
4.1. Tổ chức thông tin dưới dạng mảng 50
4.2. Tổ chức thông tin dưới dạng hồ sơ 52
4.3. Tổ chức thông tin theo tập hợp 55
4.4. Tính năng xử lý thông tin kinh tế, được tổ chức dưới dạng một mảng các bản ghi 58
5. Lập trình mô-đun 65
5.1 Tổ chức cấu trúc mô đun của chương trình 66
5.2. Sử dụng thủ tục 68
5.3. Sử dụng chức năng 72
5.4. Thủ tục và hàm không có tham số 77
5.5. Tổ chức mô-đun bên ngoài 80
Chủ đề công việc trong phòng thí nghiệm 89
Thuật ngữ 90
Danh sách tài liệu được đề xuất 94

Tải xuống miễn phí sách điện tử V. định dạng thuận tiện, xem và đọc:
Tải sách Khoa học và Lập trình Máy tính, Komleva N.V., Smirnov A.A., Khripkov D.V., 2008 - fileskachat.com, tải xuống nhanh và miễn phí.

Tải PDF
Bạn có thể mua cuốn sách này dưới đây giá tốt nhất với mức giảm giá khi giao hàng trên khắp nước Nga.

Sách giáo khoa trình bày nội dung các phương pháp xử lý thông tin dựa trên công nghệ máy tính, giúp bạn nắm được ý tưởng về các thành phần công nghệ và phần mềm của khoa học máy tính. Cuốn sách bao gồm nhiệm vụ thực tế và các bài tập điều khiển, việc hoàn thành chúng sẽ cho phép bạn làm quen với những điều cơ bản về MS DOS và đạt được kỹ năng sử dụng chương trình shell Chỉ huy Norton, cũng như các phương pháp làm việc trong đồ họa môi trường hoạt động Gia đình Windows, nắm vững các kỹ thuật lập trình và chuyển sang tự đào tạo các chương trình. Để làm được điều này, cuốn sách hướng dẫn nghiên cứu các văn bản cụ thể của cấu trúc chương trình và đưa ra các nhiệm vụ cho công việc độc lập.
Dành cho sinh viên đại học và cao đẳng đang theo học trong lĩnh vực Công nghệ thông tin quản lý, cũng như dành cho tất cả những ai muốn độc lập nắm vững các kiến thức cơ bản về lập trình.

Khoa học máy tính là một lĩnh vực kiến thức khoa học và thực tiễn cho phép bạn quản lý các đồ vật khác nhau và các hệ thống dựa trên việc xử lý thông tin. Theo nghĩa này, nó làm phong phú thêm hoạt động nghiên cứu khoa học và thực tiễn ở nhiều lĩnh vực khác nhau. Các môn học, bắt đầu từ việc quản lý các nhóm nhỏ, mở rộng mọi thứ các hình thức đã biết hoạt động của con người, có tác động đáng kể đến việc thực hiện thành công các dự án không gian.
Một trong những lĩnh vực quan trọng của khoa học máy tính là việc sử dụng các phương pháp xử lý thông tin và công nghệ máy tính mới trong việc quản lý hệ thống tổ chức và kinh tế.
Đào tạo chuyên gia để quản lý cơ cấu tổ chức không chỉ bao gồm việc đào tạo sử dụng tích cực công nghệ thông tin(CNTT), mà còn nghiên cứu các phương pháp và phương pháp ứng dụng của chúng để tối ưu hóa và phát triển hệ thống quản lý của tổ chức.

Mục lục
Giới thiệu
Lời nói đầu
Chương 1. Các thành phần cơ bản của công nghệ máy tính
1.1. Công nghệ máy tính Và không gian thông tin 17
1.2. Máy tính: cấu trúc và thông số 18
1.2.1. Sơ đồ kết cấu máy tính 19
1.2.2. Thiết bị bổ sung thông tin đầu vào/đầu ra 22
1.2.3. Phân loại máy tính 24
1.2.4. Mạng dữ liệu 26
1.3. Phần mềm máy tính 27
1.3.1. Phân loại phần mềm 27
1.3.2. Hệ thống tập tin lưu trữ thông tin 29
1 4 Hệ điều hành đĩa MS DOS .31
1.4.1. Thành phần và mục đích của MS DOS .31
1.4.2. Cấp phát bộ nhớ trong MS DOS 32
1 4.3. Cấu trúc tập tinđĩa 33
1.4.4. Tiện ích MS DOS 34
1.4.5. Trình điều khiển thiết bị trong MS DOS 39
1.5. Thực thi các lệnh MS DOS.40
1.6. Chương trình shell Norton Commander, Workshop; làm việc trong môi trường MS DOS. 50
Chương 2. Hệ điều hành đồ họa hệ thống WINDOWS XP 51
2.1 Máy tính để bàn hệ điều hành
2.1.1. Các thành phần cơ bản của máy tính để bàn 55
2.1.2. Trang trí bàn làm việc 66
2.1 3. Quản lý các đối tượng trên desktop 70
2.2. Bảng điều khiển 71
2.3. Định dạng đĩa 76
2.4. Tùy chỉnh thanh tác vụ 76
2.5. Tùy chỉnh menu nút Bắt đầu 77
2.6. ứng dụng Explorer80
2.7. Giỏ hàng ứng dụng 84
2.8. Hồ sơ ứng tuyển 85
2.9. Ứng dụng ghi chú 87
2.10. Ứng dụng Nhiệm vụ theo lịch trình và Ngày giờ 87
2.11. Ứng dụng sơn 89
2.11.1. Yếu tố cần thiết biên tập đồ họa Sơn 90
2.11.2. Trình đơn hệ thốngđồ họa Trình chỉnh sửa sơn 91
2.11.3. Công cụ của trình soạn thảo đồ họa Paint 95
2 11.4. Chèn đồ họa 99
Hội thảo: làm việc trên hệ điều hành đồ họa thuộc dòng Windows 100
Chương 3. Cơ bản về lập trình trong Turbo Pascal 7.0
3.1. Quy trình lập trình 115
3.2. Tích hợp bộ công cụ Turbo Pascal 118
3.2.1. Tùy chọn menu chính 118
3.2.2. Mục đích các phím chức năng 125
3.2.3. Trình soạn thảo văn bản 127
3.2.4. Hoạt động 127
3.3. Ngôn ngữ lập trình Turbo Pascal 7.0 128
3.3.1. Từ vựng ngôn ngữ 128
3.3.2. Ngữ pháp ngôn ngữ 132
3 4. Người vận hành 133
3.4.1. Câu lệnh nhập và xuất dữ liệu 134
3.4.2. Đơn giản Goto 136
3.4.3. Câu lệnh có cấu trúc 137
3.5. Các kiểu dữ liệu 145
3.5.1 Các loại đơn giản dữ liệu 145
3 5.2. Các kiểu dữ liệu có cấu trúc 148
3.6. Thủ tục và chức năng - 166
3.7. Mô-đun trong Turbo Pascal 173
3.7.1. Thư viện module chuẩn SP 176
3.7.2. Thư viện module chuẩn Đồ thị 184
3.7.3. Hệ thống module tiêu chuẩn thư viện 211
3.8. Phát triển hệ thông thông tin thực hành kinh doanh 215
Hội thảo: lập trình trong Turbo Pascal 226
Chương 4. Phân công công việc độc lập
4.1. Làm việc với Norton Commander 318
4 2 Làm việc trong môi trường đồ họa Paint 320
4.3. Các lệnh cơ bản môi trường tích hợp Turbo Pascal 320
4.4. Giao diện cửa sổ trong chương trình người dùng 324
4.5. Chương trình cấu trúc tuyến tính 324
4.6. Chương trình cơ cấu phân nhánh 325
4.7. Tổ chức chu kỳ 326
4.8. Sự đối đãi mảng đa chiều dữ liệu 326
4.9. Xử lý dữ liệu ký tự 327
4.10. Xử lý dữ liệu chuỗi 327
4.11. Xử lý dữ liệu kiểu Record" 328
4.12. đã gõ và tập tin văn bản 328
4.13. Thủ tục và chức năng 329
4.14. Xử lý bộ dữ liệu 329
4.15. Hàng và bản ghi 330
Chương 5. Dịch vụ thông tin Internet 331
5.1. Kết cấu mạng lưới toàn cầu 331
5.1.1. Dịch vụ thông tin mạng 331
5.1.2 Giao thức mạng 333
5.2. Người xem tài liệu mạng thông tin 335
5.2.1. Giao diện cửa sổ trình duyệt Netscape Communicator 336
5.2.2. Giao diện cửa sổ trình duyệt MS trình duyệt web IE 341
5.3. Email 346
5.3.1. Cài đặt hộp thư 346
5.3.2. Chỉnh sửa tập tin cài đặt 350
5.3.3. Kết cấu e-mail 350
5.3.4. Sự đối đãi tin nhắn thư 356
5 3.5. Làm việc với sổ địa chỉ 359
Hội thảo: công nghệ ứng dụng E-mail 361
5.4. Làm việc với tài liệu web 364
5.4.1. Các phương pháp truy cập tài liệu web 364
5.4.2. Thiết lập trang tìm kiếm 372
5 4 3. Sao chép trang web 372
5.b. Tham gia hội nghị từ xa 374
5.5.1. Cơ cấu dịch vụ 374
5.5.2. Đọc tin tức 375
5 5.3. Đọc các bài viết trong nhóm tin 377
5 5.4. Xem tài liệu hội nghị truyền hình 379
5 5.5. Gửi tài liệu tới hội nghị từ xa 380
5.6. Công cụ tìm kiếm và thư mục tài nguyên 381
5 6 1. Các trang vàng của phân khúc Internet ở Nga 382
5 6.2. Khoa học và Công nghệ 384
5 6 3. Giáo dục 385
5 6.4. Cửa hàng trực tuyến 389
5.6.5. Thư viện ảo 390
5.7. Hiệp hội Internet của mạng thông tin Nga 392
5.7.1. Nhà cung cấp Internet toàn quốc 393
5.7.2. Nguồn thông tin Internet 395
Hội thảo: tìm kiếm và xử lý thông tin trên Internet 395
Chương 6. HTML - Ngôn ngữ đánh dấu siêu văn bản
6.1. Cấu trúc của ngôn ngữ HTML 401
6.1.1. Ký hiệu tài liệu HTML 403
6.1.2. Tiêu đề tài liệu 403
6.1.3. Nội dung tài liệu 404
6.2. Viết văn bản tài liệu web 404
6.2.1. Đầu đoạn và cuối dòng 405
6.2.2. Kiểu tiêu đề 405
6 2.3. Phong cách vật lý 406
6.2.4. Kiểu Boolean 407
6.2.5. Văn bản được định dạng sẵn 407
6.2.6. Danh sách 408
6.2.7. Ký hiệu đặc biệt 409
6.3. Tổ chức liên kết siêu văn bản 410
6.3 1. tạo con trỏ 411
6 3 2. Tạo mục lục sử dụng tên chỉ mục 411
6.3 3. Sử dụng siêu liên kết để tạo mục lục cho tài liệu web hiện tại 412
Hội thảo - tạo văn bản của tài liệu web 412
6.4. Màu văn bản và hinh nên 416
6 5. Lắp đặt các thành phần bảng 418
6.5.1 Thẻ bảng cơ bản 418
6.5.2. Chỗ ở bảng phức tạp 421
6.5.3. Kết hợp văn bản và bảng trên lề tài liệu 423
Hội thảo: danh sách và bảng biểu về lĩnh vực trang web 425
6.6. Vị trí của các yếu tố đồ họa 429
6 6.1 Đường ngang 429
6 6.2. Hình ảnh đồ họa 430
6 6.3. Con trỏ liên kết 433
6 6.4. Yếu tố đồ họaở lề của bảng 433
6 7 Bản đồ hình ảnh trên trường tài liệu web 436
6.8 Tổ chức các trang web bằng Frame 439
Hội thảo: sử dụng đồ họa và khung để sắp xếp tài liệu web
Bảng chú giải thuật ngữ 445
Văn học 458

1. Thuật toán và các thuộc tính của nó. Các phương tiện trực quan của thuật toán: lời nói, công thức-lời nói, sơ đồ khối. Hỗ trợ trực quan các thuật toán: sơ đồ cấu trúc, mã giả, ngôn ngữ lập trình 3

2. Lập trình có cấu trúc. Nguyên tắc cơ bản của phương pháp cấu trúc. Thiết kế từ trên xuống và ứng dụng của nó. Lập trình mô-đun. Mã hóa cấu trúc Các cấu trúc kinh điển cơ bản được sử dụng trong thiết kế các thuật toán cho các quá trình tính toán tuyến tính, phân nhánh và tuần hoàn 4

3. Phân loại ngôn ngữ lập trình. Đặc điểm chung của ngôn ngữ Pascal. Cấu trúc của một chương trình Pascal. Nhận xét về mục đích của các phần. Định dạng và quy tắc thực thi toán tử gán. Khái niệm và ứng dụng của toán tử ghép. 6

4. Khái niệm thủ tục và hàm trong Pascal. Mục đích, ứng dụng, lựa chọn vị trí trong chương trình 9

5. Quy tắc xây dựng thủ tục, đặt thủ tục vào chương trình, truy cập thủ tục từ chương trình gọi. Trao đổi thông tin giữa thủ tục và chương trình gọi điện: khái niệm về tham số hình thức và tham số thực tế. Công nghệ truyền tham số – theo tham chiếu và theo giá trị. Ứng dụng các công nghệ này 10

6. Quy tắc xây dựng hàm trong Pascal, đặt hàm vào chương trình, truy cập hàm từ chương trình gọi. Trao đổi thông tin giữa một hàm và chương trình gọi: khái niệm về các tham số hình thức, mô tả của chúng, các tính năng của công nghệ để trả về kết quả. 12

7. Phân tích so sánh khả năng về thủ tục và chức năng. Khả năng chuyển đổi một thủ tục thành một hàm và ngược lại. 13

8. Khái niệm đệ quy. Thủ tục đệ quy và chức năng, ứng dụng, ưu điểm và nhược điểm 13

9. Phạm vi (khả năng hiển thị) của tên. Các biến toàn cục và cục bộ. Ưu điểm và nhược điểm của việc sử dụng các biến và tham số toàn cục khi trao đổi thông tin giữa các chương trình. Khuyến nghị sử dụng 14

10. Ghi dưới dạng kiểu dữ liệu. Làm việc với bản ghi: mô tả bản ghi, toán tử nối thêm, bản ghi có biến thể. Sử dụng hồ sơ. 15

11. Các tập tin trong Pascal. Khái niệm về tập tin vật lý và logic, mối quan hệ giữa chúng. Các loại tệp và mô tả của chúng, các thủ tục chuẩn và các chức năng làm việc với tập tin. Đặc điểm chung 16 phương pháp truy cập tập tin

12. Bộ nhớ tĩnh và động. Thông tin chung về quản lý bộ nhớ động sử dụng các quy trình và chức năng tiêu chuẩn (GetMem, FreeMem; Mới, Vứt bỏ). 19

13. Cấu trúc động dữ liệu. Mảng động(một chiều và hai chiều), làm việc với chúng 22

14. Cấu trúc dữ liệu động. Danh sách. Các loại danh sách chính Hành động với danh sách 24

15. Danh sách một chiều (tuyến tính). Mô tả, tạo, xem danh sách, thêm và xóa các phần tử 28

16. Danh sách đối xứng, hai chiều. Mô tả, tạo, xem danh sách, thêm và xóa các phần tử 31

17. Danh sách vòng, tuần hoàn. Mô tả, tạo, xem danh sách, thêm và xóa các phần tử 34

18. Cây nhị phân. Các định nghĩa và khái niệm cơ bản. Tìm kiếm cây nhị phân. Hình thành cây nhị phân theo phương pháp này 36

19. Cây nhị phân. Các thao tác cơ bản với cây nhị phân. Các phương pháp duyệt cây nhị phân. Tùy chọn tìm kiếm cây nhị phân. 38

20. Đệ quy khi làm việc với danh sách và cây. Xếp hàng, xếp chồng, xếp hàng như các hình thức làm việc với danh sách, các thao tác trên chúng 40

21. Thử nghiệm. Khái niệm và mục đích của thử nghiệm. Định nghĩa đúng và sai về kiểm thử. Định nghĩa cơ bản. Kiểm thử hộp đen. Kiểm tra bằng cách sử dụng " hộp trắng» 42

22. Gỡ lỗi. Nguyên tắc chung, phương pháp gỡ lỗi. Mối quan hệ giữa quá trình kiểm tra và gỡ lỗi, sử dụng phương tiện tự động gỡ lỗi 44

23. Nguyên tắc cơ bản của lập trình hướng đối tượng: đóng gói, kế thừa, đa hình. Sự khác biệt giữa cách tiếp cận hướng đối tượng và cách tiếp cận mô-đun khi phát triển chương trình 46

24. Lớp và đối tượng: định nghĩa, mối quan hệ giữa chúng. Vai trò của các thành phần lớp - trường, thuộc tính, phương thức. Các thông số truy cập được xuất bản, công khai, riêng tư, được bảo vệ. Hàm tạo và hàm hủy, vai trò của chúng. Sự kiện và cách sử dụng chúng trong quản lý chương trình. 48

25. Sự khác biệt chính giữa ngôn ngữ Object Pascal (Delphi) và Turbo Pascal. Mảng động trong Delphi: mô tả, tính năng, ứng dụng. 50

26. Cấu trúc các module trong Delphi. Giao diện, phần thực thi, phần khởi tạo và phần kết thúc. Thủ tục và chức năng: tính năng trong Delphi 51

27. Làm việc với các tập tin và thư mục trong Delphi: các thủ tục và hàm chuẩn, Tính năng bổ sung So với Pascal, các cửa sổ hộp thoại để làm việc với các tập tin. 53

28. Định nghĩa thuật ngữ “chứng nhận”, các loại chứng nhận. Hệ thống chứng nhận của tổ chức 56

29. Chức năng chính của tổ chức chứng nhận. 57

30. Cơ sở pháp lý chứng nhận trong Liên Bang Nga. Yêu cầu đối với phòng thử nghiệm 58

31. Ý nghĩa của đo lường phần mềm nâng cao chất lượng và khả năng cạnh tranh 60

32. Chất lượng phần mềm và việc đánh giá phần mềm. Chỉ số chất lượng phần mềm 61

33. Độ tin cậy của phần mềm và đánh giá phần mềm. Các mô hình độ tin cậy 63

34. Các vấn đề, mục đích và mục đích của phân tích kinh tế và kỹ thuật trong phát triển phần mềm. Các chỉ số phân tích kỹ thuật và kinh tế. 65

35. Đánh giá hiệu quả kinh tế Công cụ phần mềm. 67

36. Chứng nhận, đo lường và tiến bộ khoa học công nghệ. 68

1. Thuật toán và các thuộc tính của nó. Các phương tiện trực quan của thuật toán: lời nói, công thức-lời nói, sơ đồ khối. Hỗ trợ trực quan của thuật toán: sơ đồ cấu trúc, mã giả, ngôn ngữ lập trình

Thuật toán hóa là quá trình xây dựng một thuật toán để giải quyết một vấn đề, kết quả của nó là xác định các giai đoạn của quá trình xử lý dữ liệu, ghi lại chính thức nội dung của các giai đoạn này và xác định thứ tự thực hiện của chúng.

Thuật toán- đây là một quy định chính xác xác định quá trình tính toán từ việc thay đổi dữ liệu ban đầu đến kết quả mong muốn.

Thuộc tính thuật toán:

1) tính tất định – tính chính xác của các hướng dẫn, loại trừ việc giải thích tùy tiện;

2) tính rời rạc – khả năng chia quá trình tính toán thành các phép toán cơ bản riêng biệt, khả năng này là không thể nghi ngờ;

3) tính hiệu quả - chấm dứt quy trình sau một số bước nhất định với kết quả mong muốn hoặc thông báo về việc không thể tiếp tục quá trình tính toán;

4) ký tự khối lượng - sự phù hợp của thuật toán để giải quyết tất cả các bài toán của một lớp nhất định.

Ngôn ngữ thuật toán– một tập hợp các ký hiệu và quy tắc để hình thành và giải thích các cấu trúc từ các ký hiệu này để viết các thuật toán.

Phương tiện trực quan chính của thuật toán là phương pháp sau đây mục của họ:

bằng lời nói;

Công thức-bằng lời nói;

Sơ đồ khối;

Mã giả;

Sơ đồ kết cấu;

Ngôn ngữ lập trình.

bằng lời nói– Nội dung của các bước tính toán được quy định bằng ngôn ngữ tự nhiên trong hình thức miễn phí với các chi tiết cần thiết.

Công thức-lời nói– hướng dẫn cài đặt bằng cách sử dụng ký hiệu toán học và cách diễn đạt kết hợp với giải thích bằng lời nói.

Sơ đồ khối- Cái này hình ảnh đồ họa cấu trúc logic thuật toán trong đó mỗi giai đoạn của quá trình xử lý dữ liệu được biểu diễn dưới dạng hình dạng hình học(khối) có cấu hình nhất định tùy thuộc vào tính chất của các hoạt động được thực hiện.

Mã giả- cho phép bạn mô tả chính thức logic chương trình mà không cần lo lắng về các tính năng cú pháp ngôn ngữ cụ thể lập trình. Điển hình là sự kết hợp giữa ngôn ngữ lập trình và các câu lệnh ngôn ngữ tự nhiên. Nó là một phương tiện biểu diễn logic chương trình có thể được sử dụng thay cho sơ đồ khối.

Sơ đồ cấu trúc- có thể được sử dụng như sơ đồ khối cấu trúc, để hiển thị các kết nối đa mô-đun, để hiển thị cấu trúc dữ liệu, chương trình và hệ thống xử lý dữ liệu. Có nhiều sơ đồ cấu trúc khác nhau: sơ đồ Nussi-Shneiderman, sơ đồ Warnier, sơ đồ Jackson, sơ đồ MESID, v.v.

Ngôn ngữ lập trình- phương tiện trực quan để thực hiện trực tiếp chương trình trên máy tính. Chương trình là một thuật toán được viết dưới dạng mà máy tính có thể hiểu được.

Dịch

Phát triển phần mềm dường như kém hơn so với các ngành khoa học máy tính khác.

Và bây giờ tôi làm việc trong lĩnh vực phát triển phần mềm, và đây là một chủ đề cực kỳ khó hiểu. Không có khái niệm nào được xác định chính xác. Kết quả được đánh giá là “thường” hoặc “nói chung”. Nghiên cứu hôm nay có thể hoặc không thể cung cấp thông tin cho công việc ngày mai. Các phương pháp tiếp cận mới thường đảo ngược các phương pháp trước đó, bùng nổ trong thời gian ngắn và sau đó trở nên lỗi thời khi những hạn chế của chúng xuất hiện. Chúng tôi tin vào lập trình có cấu trúc. Sau đó, họ bắt đầu tin vào các ngôn ngữ thế hệ thứ tư, rồi vào các phương pháp hướng đối tượng, rồi vào lập trình cực đoan, và bây giờ, có lẽ, vào nguồn mở.

Nhưng lập trình chính xác là nơi lốp xe tiếp xúc với nhựa đường. Rất ít người quan tâm liệu nó có thực sự bằng nhau hay không, hoàn toàn vì vẻ đẹp của câu hỏi. Lĩnh vực máy tính liên quan đến máy tính. Đó là viết chương trình để giải quyết các vấn đề thực tế của con người và chạy các chương trình đó trên máy thật. Theo luận điểm Church-Turing, tất cả phần cứng máy tính về cơ bản đều tương đương nhau. Vì vậy, mặc dù kiến trúc máy tính rất tuyệt vời nhưng hạn chế thực sự trong khoa học máy tính vẫn là vấn đề tạo ra phần mềm. Chúng ta muốn các chương trình có thể được hoàn thành trong một khoảng thời gian hợp lý và với chi phí hợp lý, hoạt động gần đúng như dự định của nhà thiết kế và chạy không có lỗi.

Hình 1: Đường sáng trong khoa học máy tính

Các chủ đề trên dòng này thuộc về phát triển phần mềm. Các lĩnh vực nghiên cứu dưới đường này là các môn học cốt lõi của khoa học máy tính. Sau này có kết quả rõ ràng, chính thức. Đối với những vấn đề còn ngỏ trong lĩnh vực này, chúng tôi mong đợi những kết quả mới sẽ được công bố chính thức. Các chủ đề này được xây dựng dựa trên nhau: ví dụ: mật mã về độ phức tạp và trình biên dịch về thuật toán. Hơn nữa, chúng tôi tin rằng kết quả đã được chứng minh trong các lĩnh vực này sẽ vẫn như vậy sau 100 năm nữa.

Phát triển phần mềm có yếu tố con người vốn có. Ví dụ, độ tin cậy vận hành phần mềm là khả năng một người hiểu, tìm và sửa các lỗi trong hệ thống phần mềm. Độ tin cậy vận hành có thể bị ảnh hưởng bởi một số khái niệm khoa học máy tính chính thức - có lẽ là độ phức tạp theo chu kỳ của biểu đồ điều khiển phần mềm. Nhưng độ tin cậy trong vận hành phụ thuộc rất nhiều vào con người và khả năng hiểu ý nghĩa cũng như mục đích của mã nguồn. Câu hỏi liệu một hệ thống phần mềm cụ thể có độ tin cậy vận hành cao hay không không thể được trả lời đơn giản bằng cách nghiên cứu phần mềm một cách máy móc.

Bảo mật cũng vậy. Các nhà nghiên cứu đã sử dụng một số phương pháp chính thức để tìm ra tác động của hệ thống phần mềm đối với sức khỏe và tài sản của con người. Nhưng không có cuộc thảo luận nào về bảo mật phần mềm có thể được coi là hoàn chỉnh nếu không đề cập đến thành phần con người của hệ thống đang được nghiên cứu. Tương tự như vậy đối với việc phát triển các yêu cầu. Chúng tôi có thể phát triển bất kỳ kỹ thuật khảo sát nào để đưa ra các yêu cầu chính xác từ các bên liên quan và có thể tạo ra nhiều hệ thống khác nhau để ghi lại chúng. Nhưng không có nghiên cứu nào trong lĩnh vực này sẽ thay đổi được thực tế rằng việc thu thập yêu cầu thường liên quan đến việc nói chuyện hoặc quan sát mọi người. Đôi khi những người này cung cấp cho chúng tôi thông tin chính xác, đôi khi thì không. Đôi khi người ta nói dối, có lẽ vì những lý do chính đáng. Đôi khi mọi người thành thật cố gắng truyền đạt thông tin chính xác nhưng không làm được điều đó.

Quan sát này dẫn đến Luận án của Connell:

Phát triển phần mềm sẽ không bao giờ là một ngành học nghiêm ngặt với kết quả đã được chứng minh vì nó liên quan đến hoạt động của con người.

Chương trình này phải làm gì? (yêu cầu, khả năng sử dụng, bảo mật)
Chương trình bên trong trông như thế nào để có thể dễ dàng sửa chữa và sửa đổi? (kiến trúc, thiết kế, khả năng mở rộng, tính di động, khả năng mở rộng)
Sẽ mất bao lâu để viết nó? (cấp)
Chúng ta nên phát triển nó như thế nào? (mã hóa, kiểm tra, đo lường, cấu hình)
Làm thế nào để một nhóm làm việc hiệu quả? (quản lý, quy trình, tài liệu)

Tất cả những vấn đề này đều xoay quanh con người.

Trước khi chuyển sang ý nghĩa trong tuyên bố của tôi, chúng ta hãy xem xét ba phản đối hợp lý:

Luận án tự nó hiện thực hóa. Nếu một lĩnh vực phát triển phần mềm nào đó đột nhiên có định nghĩa nghiêm ngặt, thì bạn chỉ cần thay đổi định nghĩa phát triển phần mềmđể loại bỏ vấn đề này khỏi nó.

Kết quả thống kê trong lập trình đã bác bỏ luận điểm này.

Các quy trình phát triển chính thức, chẳng hạn như phương pháp phòng sạch, đang dần tìm ra những phương pháp nghiêm ngặt và có thể chứng minh được. Họ nâng cao một đường sáng để đưa các chủ đề mờ nhạt trước đây vào bên dưới.

Quả thực, các nhà nghiên cứu quy trình chính thức đang chứng minh sự tiến bộ trong việc giải quyết nhiều vấn đề khác nhau. Nhưng họ có thể bị phát hiện vi phạm điều phản đối đầu tiên trong danh sách này: họ định nghĩa việc phát triển phần mềm quá hẹp để có thể đưa mình vào một giải pháp nghiêm ngặt. Các phương pháp chính thức chỉ đơn giản là cung cấp cách giải thích thuận tiện cho bất kỳ vấn đề nào dựa trên sự tham gia và giải thích của con người. Ví dụ, yếu tố then chốt của các phương pháp phát triển hình thức là việc tạo ra các đặc tả nghiêm ngặt, rõ ràng. Các thông số kỹ thuật này sau đó được sử dụng để hướng dẫn (và chứng minh) các bước phát triển tiếp theo. Tất nhiên, một phương pháp hình thức có thể chứa một sơ đồ ký hiệu ngữ nghĩa rõ ràng. Nhưng không có phương pháp chính thức nào chứa đựng một công thức chính xác về cách chuyển tải những suy nghĩ mơ hồ của mọi người một cách rõ ràng về những gì một chương trình nên làm.

Chúng ta nên ngừng cố gắng chứng minh những kết quả cơ bản trong phát triển phần mềm và nhận ra rằng những tiến bộ đáng kể trong lĩnh vực này sẽ chỉ là những khuyến nghị chung.

Ví dụ, David Parnas vào năm 1972 đã viết một bài báo khoa học tuyệt vời “Về tiêu chí phân tách một hệ thống thành các mô-đun”. Nó mô tả một thử nghiệm đơn giản mà Parnas đã thực hiện với các chiến lược thiết kế phần mềm thay thế, một chiến lược ẩn thông tin và một thử nghiệm khác với khả năng hiển thị dữ liệu toàn cầu. Sau đó, dựa trên thí nghiệm nhỏ này, ông đã rút ra một số kết luận và đưa ra khuyến nghị. Không có gì trong bài viết được chứng minh và Parnas không đảm bảo rằng mọi người sẽ nhận được kết quả như nhau khi làm theo các khuyến nghị. Nhưng bài viết chứa đựng những lời khuyên khôn ngoan và có ảnh hưởng lớn đến sự phổ biến của các ngôn ngữ lập trình hướng đối tượng.

Ví dụ khác là nỗ lực khổng lồ từ Viện Kĩ nghệ Phần mềm tại Đại học Carnegie Mellon có tên là CMMI. CMMI bắt đầu như một mô hình quy trình phát triển phần mềm và hiện đã phát triển để bao gồm các loại dự án khác. CMMI dài khoảng 1.000 trang—không bao gồm ví dụ, diễn giải và tài liệu đào tạo—và thể hiện hơn 1.000 năm công tác. Nhiều tổ chức lớn đã sử dụng nó và đạt được tiến bộ đáng kể trong quy trình và sản phẩm phát triển phần mềm của họ. Nhưng không có một kết quả nào được chứng minh chắc chắn về CMMI. Nó chỉ đơn giản là một tập hợp các đề xuất (được nghiên cứu kỹ lưỡng) về cách tổ chức một dự án phần mềm dựa trên các phương pháp đã từng áp dụng cho các tổ chức khác trong quá khứ. Trên thực tế, Viện Kỹ thuật Phần mềm tuyên bố rằng CMMI thậm chí không phải là một quy trình mà là một siêu quy trình, các chi tiết về quy trình này được mỗi tổ chức điền vào.

Các lĩnh vực nghiên cứu khác có cùng quan điểm là các mẫu thiết kế, phong cách kiến trúc, tái cấu trúc có vấn đề, phát triển linh hoạt và trực quan hóa dữ liệu. Những nguyên tắc này có thể mang lại những kết quả đã được chứng minh một phần, nhưng nhìn chung chúng nhắm đến các hệ thống vốn có sự tham gia của con người. Nói rõ hơn: các chủ đề cốt lõi của khoa học máy tính (bên dưới đường sáng) là những công cụ quan trọng đối với bất kỳ nhà phát triển nào. Kiến thức về thuật toán rất quan trọng khi thiết kế các ứng dụng hiệu suất cao. Lý thuyết xếp hàng giúp thiết kế nhân hệ điều hành. Phương pháp phòng sạch cũng hữu ích trong một số trường hợp. Phân tích số liệu thống kê có thể hữu ích khi lập kế hoạch cho các dự án tương tự với một nhóm người tham gia tương tự. Nhưng chủ nghĩa hình thức chỉ đơn giản là điều kiện cần chứ chưa phải là điều kiện đủ để phát triển tốt. Hãy lấy ngành xây dựng và kiến trúc (tức là nhà ở và công trình kiến trúc) làm ví dụ.

Hãy tưởng tượng một kỹ sư xây dựng xuất sắc, chuyên gia giỏi nhất thế giới về vật liệu xây dựng, mối quan hệ ứng suất-biến dạng, phân bổ tải trọng, bảo vệ chống đứt gió và động đất, v.v. Anh chàng này nằm trong sổ ghi chép của các kiến trúc sư khắp nơi để gọi anh ta để tư vấn về từng dự án xây dựng. Liệu kỹ sư xây dựng huyền thoại này có giỏi thiết kế những tòa nhà mà anh ta phân tích không? Không có gì. Anh ta có thể bị cuốn vào các cuộc trò chuyện với khách hàng, không thể thiết kế những nơi dễ chịu để sống, thiếu trí tưởng tượng để đưa ra giải pháp cho những vấn đề mới và cực kỳ nhàm chán. Kỹ thuật xây dựng rất hữu ích cho các kiến trúc sư thực thụ, nhưng chúng không đủ cho một thiết kế tốt. Kiến trúc thành công đòi hỏi sự sáng tạo, ý tưởng, tư duy liên ngành và chủ nghĩa nhân văn.

Tương tự như vậy, khoa học máy tính cổ điển rất hữu ích trong phát triển phần mềm, nhưng sẽ không bao giờ là đủ. Thiết kế phần mềm tốt còn đòi hỏi tính sáng tạo, ý tưởng, tư duy liên ngành và chủ nghĩa nhân văn. Quan sát này giải phóng các nhà nghiên cứu quy trình phần mềm. Họ có thể dành thời gian để học các kỹ thuật thành công - xây dựng nền tảng kiến thức tổng hợp cho những người thực hành trong tương lai. Chúng ta không nên ép việc phát triển phần mềm vào phần mở rộng toán học của khoa học máy tính. Điều này sẽ không hiệu quả và có thể khiến chúng ta mất tập trung vào những khám phá hữu ích vẫn đang chờ được khám phá.

Sự nhìn nhận
Cảm ơn Steve Homer vì cuộc thảo luận đã làm tôi quan tâm đến vấn đề này.

N.V. Komleva, A.A. Sách giáo khoa khoa học máy tính và lập trình Smirnov. Lập trình ≠ khoa học máy tính

Phát triển phần mềm sẽ không bao giờ là một ngành học nghiêm ngặt với kết quả đã được chứng minh vì nó liên quan đến hoạt động của con người.

Luận án tự nó hiện thực hóa. Nếu một lĩnh vực phát triển phần mềm nào đó đột nhiên có định nghĩa nghiêm ngặt, thì bạn chỉ cần thay đổi định nghĩa phát triển phần mềmđể loại bỏ vấn đề này khỏi nó.

Kết quả thống kê trong lập trình đã bác bỏ luận điểm này.

Các quy trình phát triển chính thức, chẳng hạn như phương pháp phòng sạch, đang dần tìm ra những phương pháp nghiêm ngặt và có thể chứng minh được. Họ nâng cao một đường sáng để đưa các chủ đề mờ nhạt trước đây vào bên dưới.

Chúng ta nên ngừng cố gắng chứng minh những kết quả cơ bản trong phát triển phần mềm và nhận ra rằng những tiến bộ đáng kể trong lĩnh vực này sẽ chỉ là những khuyến nghị chung.

Phát triển phần mềm sẽ không bao giờ là một ngành học nghiêm ngặt với kết quả đã được chứng minh vì nó liên quan đến hoạt động của con người.

Luận án tự nó hiện thực hóa. Nếu một lĩnh vực phát triển phần mềm nào đó đột nhiên có định nghĩa nghiêm ngặt, thì bạn chỉ cần thay đổi định nghĩa phát triển phần mềmđể loại bỏ vấn đề này khỏi nó.

Kết quả thống kê trong lập trình đã bác bỏ luận điểm này.

Các quy trình phát triển chính thức, chẳng hạn như phương pháp phòng sạch, đang dần tìm ra những phương pháp nghiêm ngặt và có thể chứng minh được. Họ nâng cao một đường sáng để đưa các chủ đề mờ nhạt trước đây vào bên dưới.

Chúng ta nên ngừng cố gắng chứng minh những kết quả cơ bản trong phát triển phần mềm và nhận ra rằng những tiến bộ đáng kể trong lĩnh vực này sẽ chỉ là những khuyến nghị chung.