Lịch sử của công nghệ máy tính hiện đại là rất ngắn, nó mới quãng 70 năm. Lịch sử của phần mềm còn ngắn hơn, nó khoảng 50 năm. Phần lớn các phương pháp phát triển phần mềm chưa hình thành đầy đủ mãi tới những năm 1970. Về căn bản, có hai cách để phát triển phần mềm:
“Cách cổ điển” hay “cách được dẫn lái theo sản phẩm” coi phát triển phần mềm là hoạt động xây dựng với từng viên gạch (mã) đặt đặt lên nhau cho tới khi chúng trở thành sản phẩm phần mềm. Nó coi bất kì ai có kĩ năng lập trình đều có thể xây dựng phần mềm và hoạt động đó dẫn tới sản phẩm phần mềm là “dạng tự do” vì từng người lập trình đều biết điều mình làm. Cách nhìn này tới từ những ngày đầu của máy tính, thời kì mà phần mềm vẫn còn là điều huyền bí phụ thuộc vào người lập trình để viết mã phần mềm. Nó dựa trên các kĩ thuật và tri thức cá nhân có trong đầu người đó và không được làm tài liệu.
“Cách hiện đại” hay “cách được dẫn lái theo qui trình” xuất hiện vào cuối những năm 1970 dựa trên khu vực chế tạo điều hội tụ vào cách phần mềm được xây dựng để xác định chất lượng của sản phẩm. Cách này coi phần mềm là tập các nhiệm vụ nhỏ tuân theo một qui trình nơi từng nhiệm vụ có thể được kiểm soát và đo. Nó loại bỏ quan niệm rằng phát triển phần mềm là “dạng tự do”. Nó nhấn mạnh rằng chính kỉ luật được dùng tốt nhất dưới những qui tắc nghiêm ngặt theo đó mối quan hệ giữa các nhiệm vụ được xác định rõ một cách tường minh. Những quan hệ này, cũng còn được biết là “qui trình”, nhận diện các nhiệm vụ cần để tạo ra một sản phẩm phần mềm và hướng dẫn nó qua bản lộ trình có tên là “Vòng đời phát triển phần mềm”.
Phần lớn các dự án phần mềm ngày nay hoặc tuân theo cách thức “cổ điển” hay “hiện đại tuỳ theo giáo dục và đào tạo người phát triển. Giữa những năm 1970 tới 1990, công nghiệp phần mềm hội tụ chủ yếu vào cách cổ điển vì hầu hết phần mềm vào thời đó đều tương đối nhỏ và đơn giản hơn. Tuy nhiên chất lượng của những phần mềm đó không rất tốt với nhiều lỗi. Dịch chuyển từ “Cách cổ điển” sang “Cách hiện đại” bắt đầu vào cuối những năm 1980 khi chính phủ Mĩ muốn cải tiến chất lượng phần mềm trong các hệ thống nhúng của quân sự bằng việc đòi hỏi rằng mọi công việc phần mềm cho chính phủ đều phải tuân theo các chuẩn nghiêm ngặt. Điều này được biểu lộ bằng ngôn ngữ lập trình Ada và khuôn khổ của nó cho phương pháp và công cụ chung như DOD-STD-2167.
Việc thiết lập Viện Kĩ nghệ phần mềm Software Engineering Institute (SEI) tại Đại học Carnegie Mellon vào cuối những năm 1980 là nỗ lực để cải tiến chất lượng phần mềm trong toàn nước Mĩ. Việc phát triển và áp dụng Mô hình trưởng thành năng lực cho phần mềm Capability Maturity Model for Software (CMM) và nhiều mô hình qui trình xuất hiện về sau đã làm thay đổi cách mọi người phát triển phần mềm ở Mĩ rồi ở các nước khác.
Trong thời kì chuyển tiếp, có bất đồng chính giữa những người được đào tạo theo “Cách cổ điển” và “Cách hiện đại”. Nhóm này coi việc tuân theo “qui trình” phá huỷ tính sáng tạo cá nhân. Nhóm kia coi không tuân theo qui trình là hỗn độn và mất kiểm soát. Có nhiều tranh cãi và tranh luận giữa những người phát triển cho tới khi có bằng chứng từ công nghiệp chứng minh rõ ràng rằng qui trình được chuẩn hoá có thể cải tiến năng lực của dự án để quản lí chi phí, lịch biểu và lỗi. Ngay cả khi công ti bắt đầu chấp nhận “Cách hiện đại”, các đại học vẫn còn dạy “Cách cổ điển” cho nên sinh viên bị lẫn lộn. Họ được đào tạo để làm bất kì cái gì họ có thể làm (dạng tự do) để xây dựng phần mềm trong bốn năm đại học của họ nhưng khi họ làm việc trong công nghiệp, họ bị buộc phải tuân theo “qui trình” mà phần lớn họ không hiểu. Nhiều người cảm thấy không thoải mái bởi “quan liêu không cần thiết” trong nỗ lực dẫn lái theo qui trình. Điều này dẫn tới cuộc nổi dậy vào đầu những năm 2000 chống lại bất kì qui trình “nặng nề” nào như CMMI hay ISO 9000. Một nhóm những người phát triển tạo ra qui trình nhẹ cân thay thế mà bây giờ được biết tới dưới cái tên “qui trình agile” (mau lẹ).
Sự kiện là với dự án lớn và phức tạp, bạn cần qui trình có kỉ luật để đảm bảo khía cạnh chất lượng và kiểm soát. Có đủ bằng chứng để chỉ ra rằng việc tuân theo qui trình phát triển phần mềm có thể đem tới chất lượng cao hơn và sản phẩm phần mềm tốt hơn đúng thời gian, trong lịch biểu và chi phí. Tuy nhiên, với dự án nhỏ, điều chấp nhận được là có ít cách hạn chế hơn như Lập trình cực đoan, Scrum, Phát triển phần mềm thích ứng. Điều quan trọng là hiểu ích lợi của cả hai qui trình (cách hiện đại và cách mau lẹ Agile) nhưng điều cũng quan trọng là chỉ ra rằng người phát triển không nên quay lại cách thức cổ điển của dạng tự do, làm bất kì cái gì bạn thích để xây dựng phần mềm.
—-English version—-
A brief history of software development
History of modern computer technology is very short, it is only about 70 years. History of software is shorter, it is about 50 years. Most software development methods do not fully take shape until 1970s. Basically, there are two ways to develop software:
The “Classical way” or the “Product-driven way” considers develop software is a building activity with each brick (Code) putting on top of each other until they become the software product. It considers that anyone with programming skills can build software and that activities leading to a software product are “free form” as each programmer know what he is doing. This view came from the early days of computer, a time in which software was still a mystery that depended on programmers to code software. It relies on the individual techniques and knowledge that is in his head and not documented.
The “Modern way” or the “Process-driven way” appeared in the late 1970s is based on the manufacturing area which focus on the way software is built to determines the product’s quality. This way considers software as a set of small tasks that follow a process where each can be controlled and measured. It discards the concept that software development is a “free-form”. It insists that it is a discipline that is best done under strict rules in which relationships between tasks are well defined explicitly. These relationships, also known as “process”, identify the tasks needed to produce a software product and guide it through a roadmap called “Software development life cycle”.
Most software projects today either follow the “Classical” or the “Modern” way depends on the education and training of developers. Between 1970s to 1990s, the software industry focused mostly on the classical way since most software at that time were relatively small and more simple. However the quality of those software was not very good with many defects. The shift from “Classical way” to “Modern way” began in the late 1980s when the US government’s wanted to improve the quality of software in military embedded systems by demanded that all software works for government must follow strict quality standards. This was manifested with the Ada programming language and its frameworks for common methods and tools such as DOD-STD-2167.
The establishment of the Software Engineering Institute (SEI) at CarnegieMellonUniversity in late 1980s is the attempt to improve quality of software throughout the U.S. The development and application of the Capability Maturity Model for Software (CMM) and several process models appeared later have changed the way people develop software in the U.S and then to other countries.
During the transition time, there is major disagreement between people who are trained in the “Classical way” and the “Modern way”. One group consider following a “process” destroys the individual’s creativity. The other consider not following a process is chaotic and out of control. There are many arguments and debates among developers until evidences from industry clearly demonstrated that standardized process can improve projects’ ability to manage cost, schedule, and defects. Even when companies begin to accept the “Modern way”, universities are still teaching the “Classical way” so students are confused. They are trained to do whatever they can (Free-form) to build software during their four years in college but when they work in the industry, they are forced to follow a “process” in which most do not understand. Many feel uncomfortable by the “ unnecessary bureaucracy” in strongly process-driven efforts. This led to a rebellion in the early 2000s against any “heavyweight” processes such as the CMMI or ISO 9000. A group of developers create a light weight alternative process now known as “The agile processes”.
The fact is for large and complex project, you do need the discipline process to ensure the quality and control aspects. There are enough evidences to show that following a software development process can bring higher quality and better software product on time, within schedule and cost. However, for smaller project, it is acceptable to have a less restriction ways such as Extreme Programming, Scrum, Adaptive Software Development. It is important to understand the benefits of both processes (Modern ways and Agile way) but it is also important to point out that developers should not return to the old classical way of free-form, do whatever you like to build software.
