Mô hình thác nước

MOÂ HÌNH THAÙC NÖÔÙC I. Ý nghĩa mô hình: Đây được coi là mô hình thác đổ, hay là mô hình tuyến tính, là một mô hình cổ điển. Mô hình thác nước là mô hình đầu tiên tiếp cận phát triển hệ thống. Nó phổ biến trong thập niên 70 và cho phép cho một số lượng nhất định của thứ thự trong tiến trình . Mô hình này được đưa ra dựa trên nét tương đồng với các phương thức được sử dụng trong các lĩnh vực ngành kỹ thuật khác, ví dụ  như là ngành xây dựng. Việc xây dựng một chiếc cầu bắt đầu với việc xác định các công cụ, sau đó là công thức hoá các nhu cầu để đáp ứng được tiêu chí xây dựng. Bước tiếp theo là thiết kế cầu. Giai đoạn kế tiếp là xây dựng và thẩm định. Công đoạn cuối cùng là bảo vệ cả hệ thống công trình đó. II. Các bước thực hiện của mô hình thác nước : 1.Khảo sát hiện trạng: Hoạt động này đề cập đến sự quan tâm của tất cả những khía cạnh của hàm kinh doanh mục tiêu hoặc tiến trình, với những mục tiêu xác định làm thế nào mỗi khía cạnh liên quan đến một cái khác và khía cạnh này sẽ kết hợp vào trong hệ thống. Đây là giai đoạn đầu tiên nhất trong quá trình phát triển phần mềm, nó cho biết hiện trạng bài toán như thế nào. Ví như hiện trạng về mô hình tổ chức, hiện trạng về các nghiệp vụ, hiện trạng về quá trình tin học của khách hàng mà phần mềm chúng ta nhắm tới. trong đó hiện trạng về nghiệp vụ là quan trọng nhất. Mục tiêu của giai đoạn này là phải hiểu rõ được quy trình nghiệp vụ của khách hàng như là có bao nhiêu quá trình nghiệp vụ, những nghiệp vụ đó họ làm như thế nào?…. 2.Xác định yêu cầu: Có 2 loại yêu cầu là yêu cầu chức năng và yêu cầu phi chức năng. Trong giai đoạn này là giai đoạn sống còn, vì yêu cầu là rất khó biết. Vì vậy việc xác định yêu cầu đúng là rất quan trọng trong suốt quá trình làm phần mềm. Mục tiêu của giai đoạn thu thập yêu cầu là xác định phần mềm sẽ làm được những gì dựa trên các nhu cầu của khách hàng. Nỗ lực này thường mất nhiều thời gian để đảm bảo rằng nhóm phát triển và khách hàng hiểu rõ ràng về phạm vi của sản phẩm, các chức năng của nó và các yếu tố chất lượng cũng như môi trường hoạt động của nó. Để làm được điều này, các Kỹ sư phần mềm phải được huấn luyện làm thế nào để thu thập các yêu cầu một cách chính xác trước khi bắt đầu xây dựng phần mềm. 3.Phân tích: Phân tích hệ thống (System Analysis) : bước này đề cập đến những yêu cầu hệ thống tập hợp với nhau, với mục tiêu của việc xác định làm thế nào những yêu cầu này sẽ được tích hợp vào trong hệ thống. Mở rộng giao tiếp giữa khách hàng và nhóm phát triển là cần thiết. Trong giai đoạn này chúng ta sẽ phân tích các yêu cầu, và mô hình hóa chúng, kết quả của quá trình này là cho ra một sơ đồ lớp đối tượng trong chương trình chúng ta. 4.Thiết kế: Thiết kế hệ thống (System Design) : Mỗi lần yêu cầu được thu thập và phân tích, cần thiết phải xác định chi tiết làm thế nào hệ thống được xây dựng để thực hiện những công việc theo yêu cầu ( những gì được xử lý bởi hệ thống ), xây dựng phần mềm ( làm thế nào ứng dụng được xây dựng ) và thiết kế giao diện và viết mã ( giao diện người dùng như thế nào và đưa mã lệnh để xử lí ra sao ? ). Giai đoạn này chúng ta sẽ thiết kế các thuật toán, và thiết kế mô hình dữ liệu, cho ra một mô hình lớp và dữ liệu ở mức chi tiết. Trong giai đoạn thiết kế, các Kỹ sư phần mềm bắt đầu xây dựng kiến trúc hoạt động của phần mềm dựa trên các yêu cầu (đã có). Họ xác định các bộ phận, sự tương tác giữa các bộ phận và quyết định phương pháp thiết kế cũng như ghi chép tài liệu cần thiết để đảm bảo chất lượng của sản phẩm phần mềm. Nỗ lực này đòi hỏi rất nhiều thời gian để đảm bảo có được một giải pháp đầy đủ và uyển chuyển cho các yêu cầu (đã đặt ra). 5.Cài đặt: Mã hóa : được biết là việc lập trình, bước này liên quan với việc tạo phần mềm hệ thống.Yêu cầu và xác định hệ thống là chuyển sang mã máy.Phần này chúng ta sẽ chính thức bắt tay vào code. Giai đoạn lập trình hay coding tập trung vào việc phát triển chương trình máy tính trên cơ sở thiết kế (đã có). Ngày nay, điểm tập trung chính của nhiều chương trình đào tạo là lập trình, và sinh viên bỏ ra nhiều năm để học lập trình và kiểm thử. Đây là chỗ có thể thấy rõ nhất sự khác biệt giữa việc lập trình và Kỹ nghệ Phần mềm. 6.Kiểm chứng: Kiểm thử : Khi phần mềm được tạo ra và thêm vào sự phát triển của hệ thống, kiểm thử được thực hiện để đảm bảo rằng nó làm việc hoàn toàn chính xác và hiệu quả. Kiểm thử tập trung vào hai lĩnh vực, hiệu quả bên trong và ảnh hưởng bên ngoài. Mục tiêu của hiệu quả bên ngoài kiểm thử là chắc chắn rằng phần mềm là đúng chức năng theo thiết kế hệ thống và đó là thực hiện tất cả những chức năng được yêu cầu. Mục tiêu của kiểm thử bên trong là đảm bảo rằng mã máy là hiệu quả, tiêu chuẩn và làm tài liệu tốt. Mô hình này còn tương đối phổ biến. Tuy nhiên, hoàn toàn ít khi một dự án phần mềm sẽ theo những bước chính xác. Giai đoạn kiểm thử là quá trình kiểm tra sản phẩm phần mềm để tìm kiếm lỗi. Quy trình kiểm thử phần mềm thường được chia ra thành nhiều loại, bắt đầu bằng hình thức kiểm thử đơn vị chương trình (unit test) được phát triển bởi từng người. Loại kiểm thử tiếp theo là kiểm thử tích hợp (integration test) khi các đơn vị chương trình được tích hợp lại thành một chức năng hay nhiều chức năng trước khi kiểm thử toàn bộ hệ thống (system test) của cả sản phẩm. Khi mọi thứ đã được kiểm thử xong, phần mềm sẽ được chuyển đến cho khách hàng xem xét trong quy trình kiểm thử sự chấp nhận của khách hàng (acceptance test) trước khi khách hàng đồng ý rằng phần mềm đã đáp ứng tất cả các yêu cầu của họ. Người Kỹ sư Phần mềm thực sự cần phải liên tục làm nhiều lần kiểm tra phần mềm trong quá trình phát triển để đảm bảo mọi thứ hoạt động như đã tính. Hình thức “đưa chất lượng vào (từ đầu)” qua kiểm tra (ngay trong quá trình phát triển) là rất hiệu quả vì chất lượng của sản phẩm phần mềm được kiểm soát bởi chất lượng của quy trình phát triển ra sản phẩm đó. 7.Triển khai và triển khai: Chương trình sẽ được đem đi triển khai. Giai đoạn bảo trì diễn ra khi phần mềm đã được hoàn tất và đưa vào sử dụng. Hầu hết các phần mềm cỡ lớn đều không cố định mà thường xuyên phải thay đổi. Việc bảo trì bao gồm ba hoạt động: sửa chữa tương thích, chữa lỗi, và tăng cường tính năng. Sửa chữa tương thích là quá trình thay đổi phần mềm để nó có thể thích hợp với môi trường hoạt động mới. Ví dụ: chuyển một hệ thống từ hệ điều hành Windows sang hệ điều hành Linux. Chữa lỗi là quá trình chữa các lỗi còn tồn tại sau khi đã giao phần mềm cho khách hàng. Tăng cường tính năng là quá trình thêm mới chức năng cho phần mềm. Giai đoạn (bảo trì) này rất giống với giai đoạn phát triển mới phần mềm vì nó theo đúng mô hình chu kỳ phát triển phần mềm về yêu cầu, thiết kế, triển khai, và kiểm thử. Vì phần mềm luôn thay đổi theo thời gian, một hoạt động rất quan trọng là quản lý cấu hình phần mềm. Mảng hoạt động này bao gồm việc kiểm soát phiên bản của các bộ phận (chương trình/chức năng) trong phần mềm, quản lý các thay đổi giữa các phiên bản đó, và theo dõi mối quan hệ giữa chúng. Cụ thể, mảng này còn bao gồm việc theo dõi phiên bản, việc quản lý các yêu cầu thay đổi, xây dựng cơ chế quản lý, và theo dõi sự nối kết giữa các phiên bản bộ phận phần mềm khác nhau nhằm tạo nên một tổng thể phiên bản cho cả sản phẩm phần mềm. =►Sự phụ thuộc của các bước thực hiện: Mô hình này đề nghị các hoạt động được tiến hành như các giai đoạn tách biệt, giai đoạn sau sẽ không bắt đầu khi giai đoạn trước chưa hoàn thành. Sản phẩm đầu ra của giai đoạn trước trở thành đầu vào của giai đoạn sau. Những mũi tên ngược từ dưới lên trên cho thấy những sai lầm ở giai đoạn trước có thể được phát hiện ở giai đoạn sau và đòi hỏi việc quay ngược lên để làm lại giai đoạn trước. Tuy nhiên, hoạt động quay lui này chỉ nên được coi là các ngoại lệ mà thôi. Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. Giả sử, pha phân tích và xác định yêu cầu đã hoàn tất và chuyển sang pha kế tiếp, nhưng lúc này lại có sự thay đổi yêu cầu của người sử dụng; thì chỉ còn cách là phải thực hiện lại từ đầu. Cho nên, mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định. Mô hình thác nước chỉ là danh sách sắp xếp theo thời gian của những hoạt động được thể hiện để đạt được một hệ thống công nghệ thông tin. Nhận xét: Mô hình thác nước khó phân biệt rõ ràng giới hạn các pha, nhiều pha gối lên nhau và cung cấp thông tin cho nhau. Khi thiết kế mới nhận ra các yêu cầu mới. Khi viết mã chương trình nhận thấy một vài thiết kế có vấn đề... Khi bảo trì hiệu năng, có thể thực hiện lại một vài hay toàn bộ các bước trước đó. Tiến trình phát triển không phải là mô hình tuyến tính mà là trình tự lặp các hoạt động phát triển. Tiến trình phát triển bao gồm các lặp thường xuyên. Khó nhận ra các điểm mấu chốt để lập kế hoạch và báo cáo kết quả. Do vậy, sau một vài lần lặp thường phải đưa ra các vật phẩm như đặc tả... để tiếp tục các bước sau. Đôi khi rất khó phân hoạch các hoạt động phát triển trong dự án thành các bước trong mô hình. III. Đặc điểm mô hình: Mô hình thác nước có thể được cải tiến bằng cách cho phép quay lui khi phát hiện lỗi trong giai đoạn phía trước. Có ý kiến cho rằng không có một dự án thực tế nào lại thực hiện dạng mô hình này mặt khác thì lại có các ý kiến trái ngược, rằng hầu hết các dự án đều tiến hành theo mô hình thác đổ. Sự trái ngược đó là kết quả của sự khác nhau trong cách nhìn nhận, đánh giá mô hình này. Cách nhìn chặt chẽ coi các buớc như các giai đoạn trong khi thực hiện phần mềm, tiếp theo nhau và không có vòng lặp. Cách nhìn tổng quát coi các bước chỉ có tính khái niệm, cho phép chúng chồng nhau, cho phép vòng lặp - quay lại các bước trước. IV. Ưu điểm, nhược điểm của mô hình thác nước: ©Ưu điểm: Ä Có thể dễ dàng phân chia quá trình xây dựng phần mềm thành những giai đoạn hoàn toàn độc lập nhau. Ä Các đòi hỏi dài của hệ thống được nhận biết dài, phân tích trứơc khi hệ thống bắt đầu. Thay đổi yêu cầu được giảm tới độ tối thiểu khi dự án bắt đầu Chuỗi các hoạt động được thực hiện theo quy trình rõ ràng Dể quản lí. Ước lượng thời gian và chi phí rất chính xác. Các pha được xác định rỏ ràng. Thấy được trình tự kỹ nghệ từ đầu đến cuối sản phẩm. Thích hợp khi yêu cầu tìm hiểu tốt. © Nhược điểm: Luôn luôn nghĩ sẽ là hoàn hảo ngay từ đầu. Hệ thống phải kết thúc ở từng giai đoạn (có khi dài) do đó nó khó có thể thực hiện đầy đủ các yêu cầu của khách hàng. Mối quan hệ giữa các giai đoạn không được thể hiện. Thiết kế phải rõ ràng khi dự án bắt đầu. Không thấy đuợc sự tiến hoá của sản phẩm. Rủi ro cao, không thể quay lại. Không thể phát triển sau khi phát hành sản phẩm. Khó đáp ứng đựơc các yêu cầu của khách hàng. Sản phẩm đựơc hình thành ở giai đoạn cuối của sản phẩm. Đa số những phần mềm ẩn chứa những nhược điểm không ít thì nhiều. Người sử dụng không có cơ hội tham gia vào dự án trong suốt quá trình thực hiện dự án. Đặc biệt là dự án lớn. Họ chỉ thấy vào thời điểm cuối. Đòi hỏi khách hàng đưa ra yêu cầu chính xác ngay từ đầu. Sai sót phát hiện muộn có thể là hiểm họa. Chậm có phiên bản thực hiện được.