By | April 14, 2022

Để hiểu được sự cần thiết của kỹ thuật phần mềm, chúng ta phải tạm dừng một thời gian ngắn để nhìn lại lịch sử gần đây của máy tính. Lịch sử này sẽ giúp chúng ta hiểu những vấn đề bắt đầu trở nên rõ ràng vào cuối những năm 60 và đầu những năm 70, và các giải pháp đã dẫn đến sự ra đời của lĩnh vực kỹ thuật phần mềm. Những sự cố này được một số người gọi là “Cuộc khủng hoảng phần mềm”, được đặt tên theo các triệu chứng của sự cố. Tình huống này cũng có thể được gọi là “Rào cản phức tạp”, vì vậy được đặt tên cho nguyên nhân chính của các vấn đề. Một số đề cập đến cuộc khủng hoảng phần mềm trong quá khứ. Cuộc khủng hoảng còn lâu mới kết thúc, nhưng nhờ sự phát triển của nhiều kỹ thuật mới mà ngày nay được đưa vào dưới tên gọi kỹ thuật phần mềm, chúng tôi đã và đang tiếp tục đạt được tiến bộ.

Trong những ngày đầu của máy tính, mối quan tâm hàng đầu là xây dựng hoặc mua lại phần cứng. Phần mềm gần như được kỳ vọng sẽ tự lo liệu. Sự đồng thuận cho rằng “phần cứng” là “khó thay đổi”, trong khi “phần mềm” là “mềm” hoặc dễ thay đổi. Theo hầu hết mọi người trong ngành đều lên kế hoạch cẩn thận cho việc phát triển phần cứng nhưng lại ít suy nghĩ trước về phần mềm. Nếu phần mềm không hoạt động, họ tin rằng, có thể dễ dàng thay đổi nó cho đến khi nó hoạt động. Trong trường hợp đó, tại sao phải nỗ lực lập kế hoạch?

Chi phí của phần mềm chỉ bằng một phần nhỏ so với chi phí của phần cứng mà không ai coi nó là rất quan trọng để quản lý sự phát triển của nó. Tuy nhiên, mọi người đều thấy tầm quan trọng của việc tạo ra các chương trình hiệu quả và chạy nhanh vì điều này tiết kiệm thời gian trên phần cứng đắt tiền. Thời gian của con người được cho là tiết kiệm thời gian của máy móc. Làm cho quy trình con người hiệu quả nhận được ít ưu tiên.

Cách tiếp cận này tỏ ra khả quan trong những ngày đầu của máy tính, khi phần mềm còn đơn giản. Tuy nhiên, khi máy tính trưởng thành, các chương trình trở nên phức tạp hơn và các dự án ngày càng lớn hơn trong khi các chương trình đã được chỉ định, viết, vận hành và duy trì thường xuyên bởi cùng một người, các chương trình bắt đầu được phát triển bởi các nhóm lập trình viên để đáp ứng kỳ vọng của người khác.

Nỗ lực cá nhân đã nhường chỗ cho nỗ lực đồng đội. Sự giao tiếp và phối hợp vốn từng diễn ra trong đầu một người nhưng lại phải xảy ra giữa những người đứng đầu của nhiều người, khiến toàn bộ quá trình trở nên phức tạp hơn rất nhiều. Kết quả là, giao tiếp, quản lý, lập kế hoạch và tài liệu trở nên quan trọng.

Hãy xem xét sự tương tự này: một người thợ mộc có thể làm việc một mình để xây một ngôi nhà đơn giản cho riêng mình mà không có khái niệm chung về kế hoạch. Anh ấy hoặc cô ấy có thể giải quyết mọi việc hoặc thực hiện các điều chỉnh khi công việc tiến triển. Đó là cách các chương trình ban đầu được viết ra. Nhưng nếu ngôi nhà được xây dựng cầu kỳ hơn, hoặc nếu nó được xây dựng cho người khác, người thợ mộc phải lên kế hoạch cẩn thận hơn về cách xây dựng ngôi nhà. Các kế hoạch cần được xem xét với chủ sở hữu tương lai trước khi bắt đầu xây dựng. Và nếu một ngôi nhà được xây dựng bởi nhiều thợ mộc, toàn bộ dự án chắc chắn phải được lên kế hoạch trước khi bắt đầu công việc sao cho một người thợ mộc xây một phần của ngôi nhà, người khác không xây phần kia của một ngôi nhà khác. Lập lịch trình trở thành yếu tố then chốt để các nhà thầu xi măng đổ tường tầng hầm trước khi thợ mộc bắt đầu đóng khung. Khi ngôi nhà trở nên phức tạp hơn và nhiều công việc của con người phải được điều phối, thì cần phải có các bản thiết kế và kế hoạch quản lý.

Khi các chương trình trở nên phức tạp hơn, các phương pháp ban đầu được sử dụng để tạo bản thiết kế (sơ đồ) không còn thỏa mãn để thể hiện sự phức tạp lớn hơn này. Và do đó trở nên khó khăn cho một người cần một chương trình được viết ra để truyền đạt cho người khác, lập trình viên, chỉ những gì họ muốn, hoặc để các lập trình viên truyền đạt cho nhau những gì họ đang làm. Trên thực tế, nếu không có các phương pháp biểu diễn tốt hơn, thì ngay cả một lập trình viên cũng khó theo dõi những gì họ đang làm.

Thời gian cần thiết để viết các chương trình và chi phí của chúng bắt đầu vượt quá mọi ước tính. Không có gì lạ khi các hệ thống có chi phí cao hơn gấp đôi những gì đã ước tính và mất nhiều tuần, vài tháng hoặc nhiều năm hơn dự kiến ​​để hoàn thành. Các hệ thống được chuyển cho khách hàng thường không hoạt động chính xác vì tiền hoặc thời gian đã hết trước khi các chương trình có thể hoạt động như dự định ban đầu. Hoặc chương trình quá phức tạp nên mọi nỗ lực sửa chữa một vấn đề đều tạo ra nhiều vấn đề hơn là nó đã được khắc phục. Cuối cùng khi khách hàng nhìn thấy những gì họ nhận được, họ thường thay đổi ý định về những gì họ muốn. Ít nhất một dự án hệ thống phần mềm quân sự rất lớn trị giá vài trăm triệu đô la đã bị bỏ rơi vì nó không bao giờ có thể hoạt động bình thường.

Chất lượng của các chương trình cũng trở thành mối quan tâm lớn. Khi máy tính và các chương trình của chúng được sử dụng cho các nhiệm vụ quan trọng hơn, như giám sát thiết bị hỗ trợ sự sống, chất lượng chương trình có ý nghĩa mới. Vì chúng tôi ngày càng phụ thuộc vào máy tính và trong nhiều trường hợp không thể hòa hợp được nữa nếu không có chúng, chúng tôi phát hiện ra tầm quan trọng của việc chúng hoạt động chính xác.

Thực hiện một thay đổi trong một chương trình phức tạp hóa ra lại rất tốn kém. Thông thường, ngay cả việc khiến chương trình thực hiện một điều gì đó hơi khác một chút đã khó đến mức dễ dàng bỏ chương trình cũ và bắt đầu lại. Điều này, tất nhiên, rất tốn kém. Một phần của sự phát triển trong cách tiếp cận kỹ thuật phần mềm là học cách phát triển các hệ thống được xây dựng đủ tốt ngay từ đầu để có thể dễ dàng thực hiện các thay đổi đơn giản.

Đồng thời, phần cứng ngày càng ít tốn kém hơn. Các ống được thay thế bằng bóng bán dẫn và bóng bán dẫn được thay thế bằng mạch tích hợp cho đến khi máy tính siêu nhỏ có giá dưới ba nghìn đô la trở thành vài triệu đô la. Như một dấu hiệu cho thấy sự thay đổi diễn ra nhanh chóng như thế nào, chi phí của một lượng máy tính nhất định giảm một nửa sau mỗi hai năm. Với sự sắp xếp lại này, thời gian và chi phí để phát triển phần mềm không còn quá nhỏ so với phần cứng, đến mức chúng có thể được bỏ qua.

Khi chi phí phần cứng giảm mạnh, phần mềm tiếp tục được viết bởi con người, với mức lương tăng lên. Việc tiết kiệm từ các cải tiến năng suất trong phát triển phần mềm từ việc sử dụng trình lắp ráp, trình biên dịch và hệ thống quản lý cơ sở dữ liệu không tiến triển nhanh như tiết kiệm chi phí phần cứng. Thật vậy, ngày nay chi phí phần mềm không những không còn có thể bị bỏ qua mà chúng đã trở nên lớn hơn chi phí phần cứng. Một số phát triển hiện tại, chẳng hạn như các ngôn ngữ phi thủ tục (thế hệ thứ tư) và việc sử dụng trí tuệ nhân tạo (thế hệ thứ năm), cho thấy hứa hẹn về việc tăng năng suất phát triển phần mềm, nhưng chúng ta mới chỉ bắt đầu nhìn thấy tiềm năng của chúng.

Một vấn đề khác là trong các chương trình trước đây thường trước khi người ta hiểu rõ chương trình đó cần làm gì. Khi chương trình đã được viết xong, khách hàng bắt đầu bày tỏ sự không hài lòng. Và nếu khách hàng không hài lòng, thì cuối cùng nhà sản xuất cũng không hài lòng. Theo thời gian, các nhà phát triển phần mềm đã học cách trình bày với giấy và bút chì chính xác những gì họ định làm trước khi bắt đầu. Sau đó, họ có thể xem xét các kế hoạch với khách hàng để xem liệu chúng có đáp ứng được mong đợi của khách hàng hay không. Việc thay đổi phiên bản giấy và bút chì này đơn giản và ít tốn kém hơn là thực hiện chúng sau khi hệ thống đã được xây dựng. Sử dụng kế hoạch tốt sẽ giúp ít có khả năng phải thực hiện các thay đổi sau khi chương trình kết thúc.

Thật không may, cho đến vài năm trước, không có phương pháp biểu diễn tốt nào tồn tại để mô tả thỏa đáng các hệ thống phức tạp như những hệ thống đang được phát triển ngày nay. Sự thể hiện tốt duy nhất về những gì sản phẩm sẽ trông như thế nào là chính sản phẩm đã hoàn thành. Các nhà phát triển không thể hiển thị cho khách hàng những gì họ đang lên kế hoạch. Và khách hàng không thể biết liệu phần mềm có phải là thứ họ muốn cho đến khi nó được xây dựng cuối cùng hay không. Sau đó, nó là quá đắt để thay đổi.

Một lần nữa, hãy xem xét sự tương tự của việc xây dựng tòa nhà. Một kiến ​​trúc sư có thể vẽ sơ đồ mặt bằng. Khách hàng thường có thể hiểu được những gì kiến ​​trúc sư đã lên kế hoạch và cung cấp lại nguồn cấp dữ liệu xem nó có phù hợp hay không. Sơ đồ mặt bằng hợp lý dễ hiểu đối với người dân bởi vì hầu hết mọi người đều quen thuộc với các bản vẽ đại diện cho các đối tượng hình học. Kiến trúc sư và khách hàng chia sẻ các khái niệm chung về không gian và hình học. Nhưng kỹ sư phần mềm phải đại diện cho khách hàng một hệ thống liên quan đến logic và xử lý thông tin. Vì họ chưa có ngôn ngữ của các khái niệm chung, kỹ sư phần mềm phải dạy một ngôn ngữ mới cho khách hàng trước khi họ có thể giao tiếp.

Hơn nữa, điều quan trọng là ngôn ngữ này phải đơn giản để nó có thể được học một cách nhanh chóng.