Khái niệm về các mô hình quy trình phần mềm

Trong thế giới phát triển phần mềm, việc hiểu rõ các mô hình quy trình là điều thiết yếu để đảm bảo chất lượng và hiệu quả của sản phẩm cuối cùng.

Các mô hình này không chỉ giúp định hình các bước cần thiết trong quá trình phát triển mà còn cung cấp một khung làm việc chuẩn mực để các nhóm phát triển có thể theo dõi và cải tiến. Từ việc xác định yêu cầu ban đầu đến kiểm thử và triển khai, mỗi mô hình quy trình đều có những đặc điểm và ứng dụng riêng, phù hợp với từng loại dự án và nhu cầu cụ thể.

Hãy cùng VNLibs.com khám phá những mô hình quy trình phần mềm phổ biến và cách chúng có thể được áp dụng để tối ưu hóa quá trình phát triển phần mềm. Mục đích của phần này là, giới thiệu các khái niệm của một quy trình phần mềm một tập hợp nhất quán các hoạt động cho việc sản xuất phần mềm. Khi đọc phần này, chúng ta sẽ hiểu:

Khái niệm về quy trình phần mềm và các mô hình quy trình phần mềm; Ba đặc tính của các mô hình quy trình phần mềm và khi nào chúng được sử dụng; Nhìn chung, các hoạt động trong công nghệ phần mềm bao gồm xác định yêu cầu của phần mềm, phát triển phần mềm, kiểm tra và triển khai; RUP (Rational Unified Process) tích hợp các quy trình phần mềm thực tiễn tạo ra một mô hình quy trình chung, hiện đại.

Một quy trình phần mềm là tập hợp các hoạt động để tạo ra một sản phẩm phần mềm. Các hoạt động đó có thể bao gồm sự phát triển của phần mềm, bắt đầu từ một ngôn ngữ lập trình chuẩn như Java hoặc C. Tuy nhiên, phần mềm mới được phát triển bởi sự mở rộng và thay đổi các hệ thống hiện hành, bởi sự biến đổi và tích hợp phần mềm dùng ngay hoặc các thành phần hệ thống.

Một lý do cho việc hiệu quả các công cụ CASE bị giới hạn là bởi sự đa dạng và phức tạp của các quy trình phần mềm. Đó không phải là quy trình lý tưởng và nhiều tổ chức cải tiến cách tiếp cận của chính họ đối với sự phát triển phần mềm.

Các quy trình phát triển để khai thác các tiềm năng của con người trong một tổ chức, và các đặc trưng của các hệ thống đang được phát triển. Với một vài hệ thống, yêu cầu một quy trình phát triển rất có cấu trúc. Với các hệ thống kinh doanh, có nhu cầu thay đổi nhanh chóng, một quy trình mềm dẻo và nhanh nhạy thì phù hợp hơn.

Mặc dù có nhiều quy trình phần mềm, một số hoạt động cơ bản sau là giống nhau với tất cả các quy trình:

– Đặc tả phần mềm: Chức năng của phần mềm và các yêu cầu với các hoạt động của nó phải được định rõ.

– Thiết kế và thực thi phần mềm: Phần mềm đảm bảo các đặc tả phải được đáp ứng.

– Thẩm định phần mềm: Phần mềm phải được thẩm định để đảm bảo rằng, nó thực hiện những gì khách hàng muốn.

– Phát triển phần mềm: Phần mềm phải phát triển để đáp ứng sự thay đổi yêu cầu của khách hàng.

Mặc dù không có quy trình phần mềm lý tưởng, nhưng có cách để cải tiến quy trình phần mềm trong nhiều tổ chức. Các quy trình có thể bao gồm các kỹ thuật lỗi thời, hoặc không đem lại lợi ích gì cho các quy trình phần mềm công nghệ. Quả thực, có rất nhiều tổ chức, vẫn không sử dụng các phương thức công nghệ trong quy trình phát triển phần mềm của họ.

Các quy trình phần mềm có thể được cải tiến bởi quá trình tiêu chuẩn hóa quy trình, nơi mà tính đa dạng trong các quy trình phần mềm giữa các tổ chức cần được giảm xuống. Điều đó, cải tiến sự truyền thông và giảm thời gian đào tạo, đồng thời làm tự động hóa quy trình, đem lại sự tiết kiệm về kinh tế nhiều hơn. Sự tiêu chuẩn hóa cũng là bước quan trọng đầu tiên, trong việc giới thiệu các phương pháp kỹ thuật phần mềm mới, và các phương thức kỹ thuật phần mềm tốt.

1. Các mô hình quy trình phần mềm là gì?

Một mô hình quy trình phần mềm là sự miêu tả trừu tượng của một quy trình phần mềm. Mỗi mô hình quy trình mô tả một quy trình từ một cách nhìn đặc biệt, và theo đó chỉ cung cấp một phần thông tin về quy trình đó. Trong phần này, chúng ta giới thiệu một số mô hình quy trình rất phổ biến (được gọi là các mẫu quy trình). Chúng ta có thể nhìn thấy nền tảng của quy trình nhưng không thấy chi tiết của các hoạt động đặc biệt.

Các mô hình cơ bản đó không phải là sự mô tả cuối cùng của các quy trình phần mềm. Đúng hơn, chúng là sự trừu tượng hoá của quy trình, có thể được sử dụng để giải thích các cách tiếp cận khác nhau đến sự phát triển phần mềm. Có thể nghĩ về chúng như là các nền móng của các quy trình, có thể được mở rộng và đáp ứng để tạo ra nhiều quy trình kỹ thuật phần mềm đặc biệt hơn.

Các mô hình quy trình mà chúng ta trình bày ở đây là:

– Mô hình thác nước: Cách này dẫn tới các quy trình cơ bản như: sự đặc tả, sự phát triển, sự thẩm định và sự cải tiến; sau đó biểu diễn chúng thành các pha quy trình riêng biệt như sự đặc tả yêu cầu, thiết kế phần mềm, thực hiện, kiểm thử và triển khai. Theo một khảo sát của Standish Group năm 2015, chỉ có khoảng 18% dự án phần mềm sử dụng mô hình thác nước thành công.

– Sự phát triển tiến hoá: Cách tiếp cận này đưa thêm vào sự đặc tả, sự phát triển và thẩm định. Một hệ thống ban đầu được nhanh chóng phát triển từ những đặc tả trừu tượng. Khảo sát của VersionOne năm 2017 cho thấy 71% các tổ chức sử dụng phương pháp Agile (một dạng của phát triển tiến hóa) cho biết họ đã đạt được hiệu quả tốt hơn.

– Kỹ nghệ phần mềm dựa trên các thành phần: Cách tiếp cận này dựa trên một số lượng lớn các thành phần tái sử dụng đang tồn tại. Quy trình phát triển hệ thống tập trung vào việc kết hợp các thành phần vào trong một hệ thống, hơn là phát triển chúng từ đầu. Nghiên cứu cho thấy việc tái sử dụng thành phần có thể giảm thời gian phát triển phần mềm lên đến 50% và chi phí lên đến 70%.

Ba mô hình quy trình cơ bản đó, được mở rộng sử dụng trong kỹ thuật phần mềm hiện hành. Chúng không loại trừ lẫn nhau và thường được sử dụng đồng thời, nhất là sự phát triển các hệ thống lớn.

Ba mô hình quy trình cơ bản đó, được mở rộng sử dụng trong kỹ thuật phần mềm hiện hành. Chúng không loại trừ lẫn nhau và thường được sử dụng đồng thời, nhất là sự phát triển các hệ thống lớn.

Thật vậy, quy trình RUP là sự kết hợp các thành phần của tất cả các mô hình đó. Các hệ thống con bên trong một hệ thống lớn, có thể được phát triển sử dụng các phương pháp khác nhau. Mặc dù, điều đó là thuận lợi để bàn về các mô hình riêng biệt, chúng ta nên hiểu rằng, trong thực tế, chúng thường được kết hợp với nhau.

Tất cả các loại khác nhau của các quy trình cơ bản, đã được dự tính trước và có thể được sử dụng trong một số tổ chức. Biến thể quan trọng nhất gần như chắc chắn, đó là phát triển hệ thống hình thức, nơi một mô hình toán học hình thức của một hệ thống được tạo ra. Mô hình này sau đó được thay đổi thành các mã thực thi, được sử dụng các biến đổi toán học để bảo toàn tính chắc chắn của nó.

Dẫn chứng tốt nhất cho một quy trình phát triển chuẩn là quy trình CLEANROOM, nó được phát triển lần đầu tiên với IBM (Mills, 1987; Selby, 1987; Linger, 1994; Prowell, 1999). Trong quy trình Cleanroom, mỗi số gia phần mềm được mô tả một cách hình thức và sự mô tả đó được biến đổi vào trong một sự thực hiện.

Phần mềm đúng đắn được chứng minh sử dụng một phương pháp hình thức. Đó không phải là kiểm tra các khiếm khuyết trong quy trình, sự kiểm tra hệ thống được tập trung trên việc đánh giá tính tin cậy của hệ thống. Cả phương pháp Cleanroom và các phương pháp khác để phát triển dựa vào phương pháp B (Wordsworth, 1996) đều phù hợp với sự phát triển của các hệ thống có các yêu cầu về sự an toàn nghiêm ngặt, tính tin cậy hoặc bảo mật.

Phương pháp hình thức làm đơn giản hoá việc tạo ra một tình huống an toàn hoặc bảo mật, chứng minh với khách hàng là hệ thống không thường xuyên gặp các yêu cầu về sự an toàn và bảo mật.

Ngoài phạm vi chuyên môn đó, các quy trình dựa trên các biến đổi hình thức không được sử dụng rộng rãi. Chúng yêu cầu các ý kiến chuyên môn và sự thực, phần lớn các quy trình hệ thống đó không có một giá đáng kể, hoặc các lợi thế chất lượng so với các phương pháp khác để phát triển hệ thống.

2. Mô hình thác nước là gì?

Mô hình công cộng đầu tiên của quy trình phát triển phần mềm được bắt nguồn từ các quy trình kỹ thuật hệ thống phổ biến hơn (Royce, 1970). Điều này được minh hoạ trên hình bảng 1 ở trên. Mô hình này được biết đến như là Mô hình thác nước hay chu trình sống của phần mềm. Giai đoạn chính của bản đồ mô hình dựa trên các hoạt động phát triển chủ yếu sau:

– Định nghĩa và phân tích nhu cầu: Các mục tiêu và … dịch vụ hệ thống được xác định bởi việc bàn bạc với những người sử dụng hệ thống. Họ sau đó xác định chi tiết và đáp ứng như một đặc tả hệ thống.

– Thiết kế phần mềm và thiết kế hệ thống: Các phần của quy trình thiết kế hệ thống đòi hỏi yêu cầu, hoặc phần cứng hoặc phần mềm. Nó xác định một kiến trúc máy tính toàn diện. Phần mềm thiết kế bao gồm nhận dạng và mô tả trừu tượng hoá hệ thống phần mềm chủ yếu và các mối quan hệ của chúng.

– Sự thực hiện và kiểm thử từng đơn vị: Trong giai đoạn này, phần mềm thiết kế được nhìn nhận như một tập hợp các đơn vị chương trình. Đơn vị kiểm thử bao gồm sự xác minh mà mỗi đơn vị đáp ứng đặc tả của nó.

– Sự tích hợp và kiểm thử hệ thống: Các đơn vị chương trình riêng lẻ hoặc các chương trình được tích hợp và kiểm thử, như một hệ thống hoàn chỉnh để chắc chắn rằng, các yêu cầu phần mềm đã được đáp ứng. Sau khi kiểm tra, hệ thống phần mềm được phân phối đến khách hàng.

– Quá trình hoạt động và bảo dưỡng: Thông thường (mặc dù không nhất thiết) đây là giai đoạn dài nhất. Hệ thống được cài đặt và đưa vào sử dụng. Sự bảo dưỡng bao gồm các lỗi không được nhận ra trong giai đoạn ban đầu của chu trình sống, cải tiến sự thực hiện các đơn vị hệ thống, và nâng cao các dịch vụ hệ thống như khi các yêu cầu mới xuất hiện.

Nhìn chung, kết quả của mỗi giai đoạn là một hoặc nhiều tài liệu được thẩm định. Giai đoạn tiếp theo, không nên bắt đầu cho đến khi giai đoạn trước kết thúc. Trong thực tế, các giai đoạn này chồng chéo lên nhau, và cho thông tin tới các giai đoạn khác. Trong khi thiết kế, các vấn đề nảy sinh đối các yêu cầu được nhận dạng, trong khi mã hoá các vấn đề thiết kế được tìm thấy.

Quy trình phần mềm không phải là một mô hình tuyến tính đơn, nhưng bao gồm một trình tự của sự lặp lại các hoạt động phát triển. Bởi giá thành của quá trình sản xuất và thẩm định các tài liệu lặp lại là đắt tiền, và phải làm đi làm lại. Do đó, sau một số ít lần lặp lại, nó “đóng băng” phần đã phát triển, như phần đặc tả chẳng hạn và tiếp tục với các giai đoạn phát triển sau.

Các vấn đề được gỡ bỏ trong phiên bản cuối cùng, cũng có thể là được lờ đi hoặc được quy hoạch. Sự “đóng băng” sớm của các yêu cầu có nghĩa là hệ thống, sẽ không làm những gì mà người sử dụng muốn. Điều đó, có thể dẫn tới hệ thống có cấu trúc tồi, khi các vấn đề được thiết kế bị phá vỡ.

Trong giai đoạn cuối của chu trình sống (quá trình hoạt động và bảo dưỡng), phần mềm được đưa vào sử dụng. Các lỗi và các thiếu sót trong các yêu cầu phần mềm ban đầu phải được nhận ra. Các lỗi thiết kế và chương trình xuất hiện, do đó cần các chức năng mới xuất hiện. Những thay đổi (bảo dưỡng phần mềm) có thể bao gồm các giai đoạn quy trình tuần hoàn tiếp theo.

Ưu điểm của mô hình thác nước là những dẫn chứng bằng tài liệu đó, được làm tại mỗi giai đoạn và nó phù hợp với các mô hình quy trình kỹ thuật khác. Việc thay đổi yêu cầu phải được thực hiện tại một giai đoạn đầu của quy trình, đây là giai đoạn khó khăn để phản ứng lại những thay đổi trong yêu cầu của khách hàng.

Giải thích các ký hiệu mũi tên:

→: Biểu thị bước tiếp theo trong quy trình.

↑: Biểu thị mối quan hệ phản hồi, thông tin từ bước sau có thể ảnh hưởng đến bước trước.

↓: Tương tự như ↑, biểu thị mối quan hệ phản hồi.

Do đó, mô hình thác nước chỉ nên được sử dụng khi các yêu cầu là dễ hiểu, và không chắc chắn để thay đổi triệt để trong khi hệ thống được phát triển. Tuy nhiên, mô hình thác nước phản ánh các loại mô hình quy trình được sử dụng trong các công trình kỹ thuật khác.

Bởi vậy, quy trình phần mềm dựa trên cách tiếp cận này, vẫn được sử dụng cho phát triển phần mềm. Đặc biệt khi công trình phần mềm là thành phần của một công trình kỹ thuật hệ thống rộng lớn.

Ví dụ về triển khai Mô hình Thác nước và bài học kinh nghiệm: Dự án Hệ thống Quản lý Hành lý tự động tại Sân bay Quốc tế Denver (DIA) vào những năm 1990 là minh chứng rõ ràng cho việc triển khai Mô hình Thác nước và những hạn chế của nó khi áp dụng vào dự án thực tế.

Sân bay DIA mong muốn xây dựng một hệ thống tự động hiện đại để vận chuyển hành lý giữa các nhà ga, nhằm tăng hiệu quả hoạt động và rút ngắn thời gian chờ đợi cho hành khách. Dự án quy mô lớn này được giao cho BAE Automated Systems Inc. với khoản đầu tư đáng kể.

Dự án được triển khai theo từng giai đoạn của Mô hình Thác nước như sau: DIA hợp tác với BAE để xác định chi tiết các yêu cầu hệ thống, bao gồm số lượng hành lý cần xử lý, tốc độ vận chuyển, độ tin cậy, khả năng mở rộng, và khả năng tích hợp với các hệ thống khác của sân bay; BAE thiết kế hệ thống bao gồm mạng lưới đường ray, xe vận chuyển tự động, hệ thống điều khiển trung tâm, và phần mềm quản lý phức tạp; Các thành phần phần cứng và phần mềm được phát triển và kiểm thử độc lập; Sau khi hoàn thành các thành phần, toàn bộ hệ thống được tích hợp và kiểm thử tổng thể.

Kết quả dự án đã gặp phải nhiều vấn đề nghiêm trọng: Trong quá trình triển khai, yêu cầu của sân bay thay đổi do lượng hành khách tăng và các yếu tố khác. Tuy nhiên, do tính chất cứng nhắc của Mô hình Thác nước, việc điều chỉnh yêu cầu gặp nhiều khó khăn và tốn kém; Hệ thống phức tạp phát sinh nhiều lỗi trong quá trình tích hợp và kiểm thử, dẫn đến sự chậm trễ và đội chi phí; Dự án bị trì hoãn hơn 16 tháng và vượt ngân sách hàng trăm triệu USD; Cuối cùng, hệ thống không thể hoạt động ổn định và đáp ứng yêu cầu ban đầu của sân bay. DIA buộc phải từ bỏ hệ thống tự động và chuyển sang sử dụng hệ thống thủ công.

Phân tích Dự án Hệ thống Quản lý Hành lý của DIA cho thấy những hạn chế của Mô hình Thác nước khi áp dụng vào thực tế: Mô hình này không phù hợp với các dự án có yêu cầu phức tạp và dễ thay đổi; Lỗi thiết kế và phần mềm chỉ được phát hiện ở giai đoạn cuối, gây ra hậu quả nghiêm trọng về thời gian và chi phí; Mô hình này không khuyến khích sự tương tác liên tục với khách hàng, dẫn đến hệ thống có thể không đáp ứng được yêu cầu thực tế.

Bài học kinh nghiệm Dự án DIA là bài học kinh nghiệm quý báu cho các dự án phát triển phần mềm sau này: Nó cho thấy tầm quan trọng của việc lựa chọn mô hình phát triển phù hợp với đặc điểm của dự án, cũng như việc quản lý rủi ro và tương tác với khách hàng một cách hiệu quả. Các mô hình phát triển lặp và tăng trưởng như RUP, Agile ra đời sau đó đã khắc phục được một số hạn chế của Mô hình Thác nước. Mô hình Thác nước có thể phù hợp với một số dự án đơn giản và có yêu cầu rõ ràng, ổn định. Tuy nhiên, đối với các dự án phức tạp, yêu cầu dễ thay đổi, và cần sự tương tác cao với khách hàng, thì các mô hình phát triển linh hoạt hơn sẽ là lựa chọn tối ưu hơn.

3. Thiết kế phần mềm và đưa vào sử dụng

Khâu đưa vào sử dụng trong việc phát triển phần mềm, là một quá trình chuyển đổi từ một đặc tả hệ thống sang một hệ thống có thể thực thi được. Quá trình này thường liên quan đến việc lập trình và thiết kế phần mềm. Tuy nhiên, nếu một cách tiếp cận tiến bộ được sử dụng, nó cũng có thể bao gồm một đặc tả phần mềm tinh xảo.

3.1. Thiết kế phần mềm.

Thiết kế phần mềm là một sự mô tả cấu trúc phần mềm được đưa vào sử dụng, dữ liệu – một phần của hệ thống, và đôi khi là giao diện giữa những bộ phận cấu thành hệ thống, và những thuật toán được sử dụng. Không chỉ dừng lại ở việc hoàn tất bản thiết kế, những nhà thiết kế còn tiếp tục phát triển thiết kế của mình thông qua hàng loạt phiên bản.

Quá trình thiết kế có liên quan đến việc bổ sung thêm những hình thức và chi tiết mới, bởi những bản thiết kế được phát triển từ sự phản hồi liên tục trong quá trình sửa chữa những thiết kế cũ.

Giải thích các ký hiệu mũi tên:

→: Biểu thị bước tiếp theo trong quy trình.

↑: Biểu thị mối quan hệ phản hồi, thông tin từ bước sau có thể ảnh hưởng đến bước trước.

Quá trình thiết kế cũng có thể liên quan đến việc phát triển một số mẫu hệ thống, với sự trừu tượng ở các mức độ khác nhau. Những lỗi và những chi tiết bị bỏ sót trong những khâu trước đó, sẽ được phát hiện ra khi thiết kế được chia nhỏ ra. Những sự phản hồi này, làm cho những mẫu thiết kế trước trở nên hoàn thiện hơn.

Bảng 3 là một ví dụ về quá trình thiết kế này, nó mô tả thiết kế ở những khâu khác nhau. Sơ đồ này cho thấy, các khâu của quá trình thiết kế luôn kế tiếp nhau. Thực tế những hoạt động của quá trình thiết kế luôn xen kẽ nhau. Sự hoàn ngược từ khâu này sang khâu khác, và thiết kế hoạt động là hoàn toàn không thể tránh khỏi trong mọi quy trình thiết kế.

Đặc điểm kỹ thuật của khâu tiếp theo là đầu ra của mỗi hoạt động thiết kế. Đặc điểm này có thể là một sự tách biệt ra, có thể là một chi tiết mang tính hình thức để làm sáng tỏ những yêu cầu, hoặc cũng là một đặc điểm kỹ thuật mà thông qua nó, một phần của hệ thống được hiện thực hoá.

Những đặc điểm kỹ thuật này trở nên chi tiết hơn khi quá trình thiết kế đang diễn ra. Kết quả cuối cùng của quá trình này là những đặc điểm kỹ thuật chính xác, tỉ mỉ của những thuật toán và cấu trúc dữ liệu được đưa vào sử dụng.

Những hoạt động cụ thể của quá trình thiết kế bao gồm:

– Thiết kế kiến trúc: Các hệ thống con tạo nên hệ thống và những mối quan hệ giữa chúng, được xác định và chứng minh.

– Đặc tả trừu tượng: Với mỗi hệ thống con là một đặc tả trừu tượng các dịch vụ của nó và các ràng buộc dưới các hoạt động được tạo ra.

– Thiết kế giao diện: Với mỗi hệ thống con, giao diện của nó có những hệ thống con khác được thiết kế và tài liệu hoá. Đặc tả giao diện không được lưỡng nghĩa, mơ hồ bởi nó phải đảm bảo rằng các hệ thống con phải được sử dụng ngay cả khi người dùng không biết về hoạt động của các hệ thống con này. Những phương pháp về đặc tả mang tính hình thức.

– Thiết kế thành phần: Các dịch vụ của hệ thống phải được phân phối tới các thành phần và giao diện của chúng được thiết kế.

– Thiết kế cấu trúc dữ liệu: Cấu trúc dữ liệu được sử dụng trong hệ thống được thiết kế chi tiết và cụ thể.

– Thiết kế thuật toán: Những thuật toán được sử dụng để cung cấp các dịch vụ được thiết kế chi tiết và cụ thể.

Đây là một mô hình phổ biến của quá trình thiết kế, sự thực những quá trình quan trọng có thể chuyển thể để thích nghi theo những cách khác nhau. Một vài sự thích ứng có thể là:

– Hai khâu cuối của quá trình thiết kế, thiết kế cấu trúc dữ liệu và thiết kế thuật toán, có thể bị trì hoãn tới khi hệ thống được thi hành.

– Nếu một sự tiếp cận thiết kế để thăm dò được thực hiện, giao diện của hệ thống có thể được thiết kế sau khi cụ thể hoá cấu trúc dữ liệu.

– Khâu đặc tả trừu tượng có thể được bỏ qua, mặc dù đây thường là khâu quan trọng nhất của việc thiết kế hệ thống.

Khi những công cụ linh hoạt được sử dụng, đầu ra của quá trình thiết kế sẽ không phải là những tài liệu đặc tả riêng rẽ, mà sẽ được trình bày trong mã chương trình. Sau khi kiến trúc hệ thống được thiết kế, những khâu cuối cùng của thiết kế sẽ tăng lên. Mỗi sự tăng lên được trình bày trong mã chương trình hơn là trong một mô hình thiết kế.

Một cách tiếp cận khác trong việc thiết kế hệ thống là dùng phương pháp cấu trúc, với phương pháp này thì trong một số trường hợp có thể tự động tạo, và trong một số trường hợp có thể tự động tạo mã từ những mô hình này. Phương pháp cấu trúc được phát minh vào những năm 1970 để ủng hộ thiết kế hướng vào chức năng (Constantine and Yourdon, 1979, Gane and Sarson, 1979).

Nhiều phương pháp cạnh tranh ủng hộ thiết kế hướng vào đối tượng được đề xuất (Robinson, 1992; Booch, 1994) và chúng đã được hợp nhất vào những năm 1990 để cho ra đời Ngôn ngữ mô phỏng hợp nhất (Unified Modeling Language UML) và quy trình thiết kế hợp nhất (Rumbaugh, 1991; Booch, 1999; Rumbaugh, 1999a; Rumbaugh, 1999b).

Một phương pháp cấu trúc bao gồm một mẫu về quá trình thiết kế, hệ thống ký hiệu để trình bày thiết kế, định dạng chuẩn, những quy tắc và hướng dẫn thiết kế. Phương pháp này có thể đáp ứng cho một vài hoặc tất cả những mô hình hệ thống dưới đây:

– Một mô hình đối tượng cho biết những lớp đối tượng được sử dụng trong hệ thống và độ tin cậy của chúng.

– Một mô hình dãy cho biết bằng cách nào những đối tượng trong hệ thống tương tác được với nhau khi hệ thống đang hoạt động.

– Một mô hình về trạng thái quá độ cho biết trạng thái của hệ thống và nguyên nhân tạo ra sự quá độ từ trạng thái này đến trạng thái khác.

– Một mô hình cấu trúc nơi những bộ phận cấu thành hệ thống và sự liên kết, thống nhất giữa chúng được chứng minh, xác nhận.

– Một mô hình luồng dữ liệu nơi mà hệ thống được mô hình hoá thông qua sự thay đổi dữ liệu trong quá trình hoạt động. Mẫu này thường không được sử dụng trong những phương pháp hướng đối tượng nhưng lại thường xuyên được sử dụng trong thiết kế thời gian thực và hệ thống kinh doanh.

Trong thực tế, phương pháp cấu trúc thật sự là những hệ thống ký hiệu chuẩn mực và những biểu hiện cho sự hoạt động có hiệu quả. Một thiết kế hợp lý có thể ra đời từ việc làm theo những phương pháp này và áp dụng mọi sự chỉ dẫn.

Khi quyết định phân chia hệ thống và khẳng định rằng, thiết kế đã nắm bắt được những đặc tả hệ thống một cách thích đáng, luôn đòi hỏi người thiết kế phải có khả năng sáng tạo cao.

Việc nghiên cứu những nhà thiết kế trên cơ sở quan sát thực nghiệm (Bansler and Bodker, 1993) đã chỉ ra rằng, họ hiếm khi làm theo những phương pháp trên một cách đơn thuần. Họ chỉ chọn lọc những sự chỉ dẫn từ những tình huống cụ thể.

3.2. Thực thi dựa trên các thiết kế.

Phát triển một chương trình để đưa một hệ thống vào sử dụng, luôn theo sau quá trình thiết kế hệ thống. Mặc dù một vài chương trình, chẳng hạn như các hệ thống để tạo tính an toàn, thường được thiết kế chi tiết trước khi việc thực hiện bắt đầu, những khâu cuối của thiết kế và việc phát triển chương trình nói chung là thường được xen kẽ.

Công cụ CASE có thể được sử dụng để tạo nên khung chương trình từ bản thiết kế. Nó bao gồm mã định dạng và thi hành giao diện, trong một số trường hợp người ta chỉ cần bổ sung một số chi tiết cho sự hoạt động của mỗi bộ phận cấu thành chương trình.

Việc lập trình là một hoạt động cá nhân và thường không có quá trình nào kèm theo. Một vài nhà lập trình thường bắt đầu với những bộ phận mà họ hiểu rõ, phát triển chúng rồi chuyển sang những bộ phận mà họ ít am hiểu hơn. Những người khác thì lại có cách tiếp cận ngược lại, họ để lại những phần quen thuộc bởi họ biết làm thế nào để phát triển chúng.

Một vài nhà phát triển chương trình thích định dạng dữ liệu trước, sau đó dùng chúng để phát triển chương trình; những người khác lại bỏ lại những dữ liệu không rõ ràng lâu nhất có thể. Thông thường, những nhà lập trình kiểm tra mã mà họ vừa phát triển.

Điều này thường để lộ ra những khuyết điểm phải bị loại bỏ khỏi chương trình. Nó được gọi là “sự gỡ rối”. Kiểm tra khuyết điểm và loại bỏ chúng là hai quá trình khác nhau. Việc kiểm tra xác minh sự tồn tại của những thiếu sót. Việc loại bỏ lại liên quan đến việc định vị và sửa chữa những thiếu sót này.

Bảng 4 minh hoạ quá trình sửa lỗi này. Lỗi trong mã cần được định vị và chương trình được thay đổi để đáp ứng những yêu cầu. Việc kiểm tra sau đó phải được làm lại, để chắc chắn rằng, việc thay đổi là đúng đắn. Do đó, quá trình loại bỏ là một phần của việc kiểm tra và phát triển phần mềm.

Giải thích cấu trúc Bảng 5 mô tả quy trình kiểm tra phần mềm, bao gồm 3 giai đoạn chính: Kiểm tra thành phần, Kiểm tra hệ thống và Kiểm tra sự tiếp nhận.

– Mối quan hệ giữa các giai đoạn: Các giai đoạn kiểm tra được thực hiện theo thứ tự từ trên xuống dưới, được biểu thị bằng mũi tên (→).

– Kiểm tra thành phần được thực hiện trước tiên, tập trung vào việc kiểm tra từng thành phần riêng lẻ của phần mềm để đảm bảo chúng hoạt động đúng.

– Sau khi các thành phần đã được kiểm tra, chúng được tích hợp lại thành một hệ thống hoàn chỉnh. Kiểm tra hệ thống được thực hiện để đảm bảo các thành phần hoạt động tốt với nhau và toàn bộ hệ thống hoạt động như mong đợi.

– Cuối cùng, Kiểm tra sự tiếp nhận được thực hiện để đánh giá xem phần mềm có đáp ứng được yêu cầu của người dùng hay không. Giai đoạn này thường được thực hiện bởi người dùng cuối hoặc đại diện của họ.

– Mục đích của quy trình kiểm tra: Mục đích của quy trình kiểm tra là phát hiện và sửa lỗi trong phần mềm, đảm bảo chất lượng và độ tin cậy của phần mềm trước khi đưa vào sử dụng chính thức.

Khi loại bỏ sai sót, sẽ tạo ra những giả thuyết về những hoạt động có thể theo dõi được của chương trình. Sau đó, kiểm tra những giả thuyết này với hy vọng tìm ra những sai sót, làm cho đầu ra trở nên bất bình thường.

Kiểm tra những giả thuyết này, có thể kéo theo việc truy vết mã chương trình. Chúng ta có thể tạo ra những kịch bản kiểm thử theo từng tình huống để khoanh vùng vấn đề. Công cụ loại bỏ sai sót tương tác, có thể chỉ ra những giá trị trung bình của những biến số của chương trình, và những dấu vết của sự trình bày đã được thể hiện. Công cụ này, có thể rất hữu ích cho quá trình loại bỏ sai sót.

4. Sự phát triển của phần mềm.

Sự linh hoạt của hệ thống phần mềm là một trong những lý do quan trọng, giải thích tại sao ngày càng có nhiều phần mềm được tích hợp vào trong những hệ thống lớn và phức tạp. Khi đã quyết định mua một phần cứng, thì để thay đổi thiết kế của nó là rất tốn kém. Tuy nhiên, ta có thể thay đổi phần mềm bất cứ lúc nào, trong hay sau khi hệ thống được phát triển. Mặc dù vậy, những thay đổi lớn này vẫn rẻ hơn sự thay đổi tương ứng đối với hệ thống phần cứng.

Về mặt lịch sử, luôn luôn có sự tách rời giữa quá trình phát triển phần mềm và duy trì phần mềm. Người ta cho rằng việc phát triển phần mềm là một hoạt động sáng tạo, nơi mà hệ thống phần mềm được phát triển từ một khái niệm ban đầu, thành một hệ thống làm việc được. Họ nghĩ việc duy trì phần mềm thật buồn tẻ và nhàm chán. Mặc dù, chi phí của việc duy trì thường gấp vài lần chi phí phát triển ban đầu, quá trình duy trì vẫn thường được coi là ít thử thách hơn việc phát triển phần mềm gốc.

Phân tích Bảng 6 mô tả quy trình phát triển một hệ thống mới, bao gồm các giai đoạn từ việc xác định yêu cầu cho đến khi triển khai hệ thống mới. Mối quan hệ giữa các giai đoạn: Quy trình bắt đầu bằng việc xác định Yêu cầu hệ thống; Sau đó, Hệ thống tồn tại (nếu có) sẽ được phân tích để đưa ra quyết định về việc có cần thay đổi hay không; Nếu cần thay đổi, các Đề xuất thay đổi hệ thống sẽ được đưa ra; Các đề xuất này sẽ được Sửa đổi để tạo ra Hệ thống mới.

Mũi tên biểu thị:

→: Biểu thị bước tiếp theo trong quy trình.

↑: Biểu thị mối quan hệ phản hồi, thông tin từ bước sau có thể ảnh hưởng đến bước trước.

↓: Tương tự như ↑, biểu thị mối quan hệ phản hồi.

Lưu ý: Hệ thống tồn tại có thể được sử dụng để tham khảo trong quá trình quyết định và đề xuất thay đổi; Hệ thống mới sau khi được sửa đổi sẽ thay thế Hệ thống tồn tại. Bảng 6 cung cấp một cái nhìn tổng quan về quy trình phát triển hệ thống, giúp người đọc hiểu được các bước cần thiết để tạo ra một hệ thống mới đáp ứng yêu cầu.

Sự khác biệt giữa phát triển và duy trì phần mềm đang trở nên ngày càng không thích hợp. Ngày nay, một vài hệ thống phần mềm là những hệ thống hoàn toàn mới, nó tạo ra thêm nhiều lý do để xem xét việc phát triển và duy trì phần mềm như một chuỗi liên tục. Việc cho rằng xây dựng phần mềm như một quá trình tuần tự, tự nhiên, mà trong đó phần mềm liên tục được thay đổi để đáp ứng những yêu cầu thay đổi, và nhu cầu của khách hàng đã trở nên thực tế hơn là khi có hai quá trình riêng lẻ.

5. Quy trình phát triển hợp nhất.

RUP (Rational Unified Process) là một quy trình phát triển phần mềm lặp và tăng trưởng được tạo ra bởi Rational Software Corporation (nay là một phần của IBM). Nó cung cấp một cách tiếp cận có kỷ luật để gán nhiệm vụ và trách nhiệm trong một tổ chức phát triển. Mục tiêu chính của RUP là đảm bảo việc sản xuất phần mềm chất lượng cao đáp ứng nhu cầu của người dùng cuối trong thời gian và ngân sách dự kiến.

Quy trình hợp nhất (Rational Unified Process – RUP) là một ví dụ cho một quá trình được xuất phát từ UML và sự kết hợp Quy trình phát triển phần mềm hợp nhất (Rumbaugh, 1999b). Đây cũng là một ví dụ hoàn hảo cho một mô hình quy trình lai ghép. Nó tập hợp lại các yếu tố từ tất cả mô hình quy trình chung, xác nhận lặp lại và minh chứng rằng thiết kế và những đặc tả đã hoạt động tốt.

RUP chỉ ra rằng những mô hình quy trình thông thường chỉ là sự nhìn nhận đơn lẻ về quy trình. Để đối chiếu, RUP thường được mô tả từ ba khía cạnh: Khía cạnh động chỉ ra những pha đã quá thời gian của quy trình; Khía cạnh tĩnh chỉ ra những hoạt động đã được thông qua của quy trình; Khía cạnh thực tế đề xuất cách thực hiện tốt được sử dụng trong suốt quy trình.

Mọi sự mô tả về RUP đều cố gắng để gắn khía cạnh tĩnh và động vào trong một biểu đồ (Kruchten, 2000). Chúng ta nghĩ như vậy sẽ làm cho quá trình thêm khó hiểu, do đó chúng ta đã sử dụng những mô tả riêng biệt để mô tả hai khía cạnh này.

RUP là một mô hình giai đoạn, có thể nhận biết được 4 giai đoạn riêng rẽ trong quy trình phần mềm. Tuy nhiên, không giống như mô hình thác nước, nơi mà các pha được xem như các hoạt động quy trình, biểu diễn các giai đoạn trong RUP, đó là: Khởi tạo (Inception – Xác định phạm vi dự án, mục tiêu kinh doanh và các yêu cầu cơ bản.); Sự chuẩn bị (Elaboration – Phân tích chi tiết các yêu cầu, thiết kế kiến trúc hệ thống và giảm thiểu rủi ro chính.); Sự xây dựng (Construction – Phát triển và kiểm thử phần mềm.); Sự chuyển tiếp (Transition – Triển khai phần mềm cho người dùng cuối.).

Quan điểm của RUP tập trung trên các hoạt động trong suốt quá trình phát triển các tiến trình. Chúng được gọi là các luồng làm việc trong các mô tả RUP. Có 6 tiến trình luồng làm việc trung tâm đã xác định trong tiến trình, và 3 trung tâm hỗ trợ luồng làm việc. RUP được thiết kế trong các liên kết với UML – một mô hình ngôn ngữ hướng đối tượng – bởi vậy các mô tả RUP được hướng quanh liên kết với mô hình UML.

Lợi ích của việc sử dụng RUP: Cải thiện chất lượng phần mềm; Giảm thiểu rủi ro dự án; Dự đoán tốt hơn về thời gian và chi phí; Cải thiện giao tiếp giữa các thành viên trong nhóm; Tăng cường khả năng tái sử dụng. Nhược điểm của RUP: Có thể phức tạp và tốn kém cho các dự án nhỏ; Đòi hỏi sự đầu tư đáng kể vào đào tạo và công cụ; Có thể cứng nhắc và khó thích ứng với những thay đổi trong yêu cầu.

Ưu điểm trong việc mô tả động và các quan điểm tĩnh nằm trong các giai đoạn của tiến trình phát triển không liên kết với các luồng làm việc chỉ định. Trong phần chính, tất cả các luồng làm việc RUP, có thể được hoạt động tại mọi giai đoạn của tiến trình. Tuy nhiên, hầu hết sự cố gắng sẽ có thể trải qua trên luồng làm việc như là các mô hình kinh doanh, và các yêu cầu trong các giai đoạn sớm của tiến trình, cũng như trong việc thử nghiệm và triển khai trong các giai đoạn muộn hơn.

Khía cạnh thực hành trên RUP mô tả một công nghệ phần mềm tốt được yêu cầu cho việc sử dụng trong phát triển hệ thống. Sáu cơ sở thực tiễn nhất được giới thiệu là:

– Phát triển phần mềm một cách lặp lại: Kế hoạch phát triển của hệ thống trên cơ sở quyền ưu tiên của các khách hàng và phát triển, phân phối quyền ưu tiên hệ thống cao nhất trong các tiến trình.

– Quản lý các yêu cầu: Các bản tài liệu rõ ràng về các yêu cầu của khách hàng và theo dõi các thay đổi của chúng. Phân tích các ảnh hưởng của các thay đổi trước khi chấp nhận chúng.

– Sử dụng kiến trúc các thành phần cơ sở: Cấu trúc của các kiến trúc hệ thống vào trong các thành phần như đã được thảo luận trong chương này.

– Mô hình phần mềm: Sử dụng các mô hình đồ hoạ UML để miêu tả các quan điểm tĩnh và động của phần mềm.

– Kiểm tra chất lượng phần mềm: Bảo đảm rằng các phần mềm đáp ứng các chuẩn chất lượng trong các tổ chức.

– Điều khiển các thay đổi tới phần mềm: Quản lý các thay đổi tới phần mềm sử dụng, một hệ thống quản lý thay đổi các thủ tục quản lý cấu hình và các công cụ.

RUP không phải là một tiến trình phù hợp cho mọi dạng của việc phát triển nhưng nó không miêu tả các phát sinh mới. Tất cả các sự đổi mới quan trọng là riêng biệt trong từng giai đoạn và luồng làm việc, quản lý các triển khai phần mềm trong môi trường người dùng là một phần của tiến trình. Các giai đoạn là động và có mục đích. Luồng làm việc là tĩnh và là các kĩ thuật hoạt động mà không được liên kết tới một giai đoạn đơn, nhưng có thể được sử dụng thông qua việc phát triển để đạt được các mục tiêu của từng giai đoạn.

Ví dụ về triển khai Rational Unified Process (RUP): Dự án Hệ thống quản lý bệnh viện. Để hiểu rõ hơn về cách thức RUP được áp dụng trong thực tế, chúng ta hãy cùng phân tích một ví dụ cụ thể: dự án phát triển Hệ thống quản lý bệnh viện (Hospital Management System – HMS) cho một bệnh viện lớn.

Bệnh viện này đang sử dụng một hệ thống quản lý cũ kỹ, kém hiệu quả, gây ra nhiều khó khăn trong việc quản lý thông tin bệnh nhân, lịch hẹn, hồ sơ y tế, thanh toán, và các hoạt động khác. Nhận thức được sự cần thiết phải hiện đại hóa, bệnh viện quyết định triển khai HMS mới. Mục tiêu của dự án là nâng cao hiệu quả hoạt động, giảm thiểu sai sót, và cải thiện chất lượng dịch vụ chăm sóc sức khỏe.

Để đảm bảo dự án HMS thành công, bệnh viện đã lựa chọn RUP làm quy trình phát triển phần mềm. RUP được chia thành 4 giai đoạn chính, mỗi giai đoạn tập trung vào các mục tiêu cụ thể và tạo ra các sản phẩm công việc quan trọng, giúp dự án được kiểm soát chặt chẽ và đạt hiệu quả cao.

Các giai đoạn của RUP trong dự án Hospital Management System:

– Giai đoạn Inception: Giai đoạn này giống như việc lập kế hoạch cho một chuyến đi dài. Bệnh viện và nhóm phát triển cùng nhau xác định “điểm đến” – phạm vi chức năng của HMS. Các tính năng chính như quản lý bệnh nhân, quản lý lịch hẹn, quản lý hồ sơ y tế, quản lý thanh toán sẽ được xác định rõ ràng. Họ cũng “vẽ sơ đồ đường đi” bằng cách phân tích sơ bộ yêu cầu từ các bên liên quan, bao gồm bác sĩ, y tá, nhân viên hành chính, và bệnh nhân, nhằm hiểu rõ nhu cầu và mong muốn của họ. Cuối cùng, họ “chuẩn bị hành trang” bằng cách xây dựng kế hoạch sơ bộ cho dự án, bao gồm thời gian, ngân sách, và nguồn lực cần thiết.

– Giai đoạn Elaboration: Tương tự như việc nghiên cứu kỹ lưỡng bản đồ và địa hình trước khi bắt đầu chuyến đi, nhóm phát triển “khám phá chi tiết” các yêu cầu chức năng và phi chức năng của HMS, ghi lại chúng dưới dạng các trường hợp sử dụng. Họ “xây dựng nền móng” cho hệ thống bằng cách thiết kế kiến trúc, bao gồm cơ sở dữ liệu, giao diện người dùng, và các thành phần phần mềm. Đồng thời, họ “lường trước các khó khăn” bằng cách xác định và quản lý rủi ro tiềm ẩn của dự án, đề xuất các biện pháp giảm thiểu rủi ro.

– Giai đoạn Construction: Đây là lúc “chuyến đi” thực sự bắt đầu. Nhóm phát triển “xây dựng từng phần” của HMS bằng cách phát triển và kiểm thử các thành phần phần mềm. Sau đó, họ “lắp ráp các phần” lại với nhau thông qua tích hợp hệ thống. Cuối cùng, họ “kiểm tra xe” kỹ lưỡng bằng cách kiểm tra toàn bộ hệ thống HMS để đảm bảo chất lượng và độ tin cậy trước khi “xuất phát”.

– Giai đoạn Transition: Giai đoạn này là lúc “đến đích” và “bàn giao xe” cho người dùng. Hệ thống HMS được triển khai tại bệnh viện và người dùng được đào tạo cách sử dụng hệ thống mới. Bệnh viện “bắt đầu sử dụng xe” và nhóm phát triển “hỗ trợ bảo trì” hệ thống HMS thường xuyên để đảm bảo hoạt động ổn định và hiệu quả.

Kết quả: Nhờ áp dụng RUP một cách bài bản và linh hoạt, dự án HMS đã đạt được thành công trên nhiều phương diện: Hệ thống HMS đáp ứng đầy đủ các yêu cầu của bệnh viện và người dùng: Hệ thống mới giúp nâng cao hiệu quả hoạt động, giảm thiểu sai sót, và cải thiện chất lượng dịch vụ chăm sóc sức khỏe; Hệ thống hoạt động ổn định, đáng tin cậy, và dễ sử dụng: Người dùng dễ dàng làm quen và sử dụng hệ thống mới, đảm bảo hoạt động liên tục và hiệu quả của bệnh viện; Dự án được hoàn thành đúng tiến độ và trong ngân sách dự kiến: Việc áp dụng RUP giúp kiểm soát dự án tốt hơn, đảm bảo dự án hoàn thành đúng kế hoạch.

Phân tích: Sự thành công của dự án HMS phần lớn nhờ vào việc áp dụng RUP, mang lại nhiều lợi ích cụ thể: RUP giúp giảm thiểu rủi ro, phát hiện lỗi sớm, và điều chỉnh dự án một cách linh hoạt: Cách tiếp cận lặp và tăng trưởng cho phép nhóm phát triển kiểm soát dự án tốt hơn, phản ứng nhanh với các thay đổi, và giảm thiểu rủi ro phát sinh; RUP tạo ra hệ thống vững chắc, dễ mở rộng và bảo trì: Việc tập trung vào kiến trúc hệ thống ngay từ giai đoạn đầu giúp tạo ra một nền tảng vững chắc cho việc phát triển và bảo trì hệ thống trong tương lai; RUP giúp dự án chủ động xử lý các vấn đề tiềm ẩn: Quá trình quản lý rủi ro được tích hợp trong RUP giúp nhóm dự án chủ động phòng ngừa và giải quyết các vấn đề có thể phát sinh; RUP đảm bảo hệ thống đáp ứng đúng nhu cầu của người dùng: Việc sử dụng các trường hợp sử dụng để thu thập và phân tích yêu cầu giúp đảm bảo hệ thống được thiết kế và phát triển theo đúng nhu cầu thực tế của người dùng.

Kết luận: RUP là một quy trình phát triển phần mềm hiệu quả, đặc biệt phù hợp với các dự án phức tạp như HMS. Bằng cách áp dụng RUP một cách linh hoạt và phù hợp với bối cảnh cụ thể, các tổ chức có thể tăng khả năng thành công của dự án và tạo ra các sản phẩm phần mềm chất lượng cao, đáp ứng nhu cầu của người dùng.

Tài liệu tham khảo

[1] “Software Process Models: A Retrospective” – Barry W. Boehm, 1988, IEEE Computer Society.

[2] “The Rational Unified Process: An Introduction” – Philippe Kruchten, 2003, Addison-Wesley.

[3] “Agile Software Development: Principles, Patterns, and Practices” – Robert C. Martin, 2002, Prentice Hall.

[4] “Software Engineering: A Practitioner’s Approach” – Roger S. Pressman, 2014, McGraw-Hill Education.

[5] “Managing the Software Process” – Watts S. Humphrey, 1989, Addison-Wesley.

[6] “Software Processes and Life Cycle Models” – Ralf Kneuper, 2018, Springer.

[7] “Software Process Improvement and Capability Determination” – Terry Rout, 2014, Springer.

[8] “Process Models in Software Engineering” – Walt Scacchi, 2001, Encyclopedia of Software Engineering.

[9] “The Capability Maturity Model: Guidelines for Improving the Software Process” – Mark C. Paulk, 1995, Addison-Wesley.

[10] “Software Process Definition and Modelling” – Marco Kuhrmann, 2018, Springer.

[11] “Software Engineering: Theory and Practice” – Shari Lawrence Pfleeger, 2010, Pearson.

[12] “Software Process Improvement: Concepts and Practices” – Rory O’Connor, 2010, Springer.

[13] “Software Engineering: Principles and Practice” – Hans van Vliet, 2008, Wiley.

[14] “Software Process Dynamics” – Raymond J. Madachy, 2008, Wiley-IEEE Press.

[15] “Software Engineering: A Practitioner’s Approach” – Roger S. Pressman, 2014, McGraw-Hill Education.

[16] “Software Engineering Economics” – Barry W. Boehm, 1981, Prentice Hall.

[17] “Software Engineering: A Comprehensive Course” – Richard Fairley, 1985, McGraw-Hill.

[18] “Software Engineering: A Practitioner’s Approach” – Roger S. Pressman, 2014, McGraw-Hill Education.

[19] “Software Engineering: A Comprehensive Course” – Richard Fairley, 1985, McGraw-Hill.

[20] “Software Engineering Economics” – Barry W. Boehm, 1981, Prentice Hall.

Tác giả: Thạc Bình Cường

Bạn đang xem bài viết:
Khái niệm về các mô hình quy trình phần mềm
Link https://vnlibs.com/cong-nghe/khai-niem-ve-cac-mo-hinh-quy-trinh-phan-mem.html

Hashtag: #mohinh #phanmem #rup #congnghe #vnlibs #quytrinhphanmem

Mọi người cũng tìm kiếm: “Quy trình phát triển phần mềm hiệu quả”; “Mô hình thác nước trong phát triển phần mềm”; “Phương pháp phát triển phần mềm tiến hóa”; “Kỹ nghệ phần mềm dựa trên các thành phần tái sử dụng”; “Tiêu chuẩn hóa quy trình phần mềm”; “Rational Unified Process (RUP) là gì?”; “Lợi ích của mô hình Cleanroom trong phát triển phần mềm”; “Các giai đoạn trong chu trình sống của phần mềm”; “Quy trình phần mềm là gì?”; “Mục đích và các hoạt động chính của quy trình phần mềm là gì?”; “Các mô hình quy trình phần mềm phổ biến là gì?”; “Mô hình thác nước, phát triển tiến hoá, và kỹ nghệ phần mềm dựa trên các thành phần được mô tả như thế nào?”; “Khi nào nên sử dụng từng mô hình quy trình phần mềm?”; “Đặc điểm và ứng dụng của từng mô hình trong các tình huống khác nhau”; “Làm thế nào để cải tiến quy trình phần mềm?”; “Các phương pháp và lợi ích của việc tiêu chuẩn hóa và tự động hóa quy trình phần mềm”