Khóa học xuất nhập khẩu thực tế
Các bài viết nghiên cứu khoa học trong sinh viên.
Giới thiệu đến độc giả quy trình thẩm định giá trong doanh nghiệp
Phương Pháp chiết khấu dòng diền thuần vốn chủ ( FCFE - Free cash flows to Equity) là một trong những phương pháp Thẩm định giá
Solidcam là một module đươc viết ra để dành riêng cho môi trường gia công của phần mềm solidworks ngoài nó ra thì còn có Mastercam for solidworks cũng là module hỗ trợ gia công
Cung cấp các kiến thức về lĩnh vực CADCAMCNC, không chỉ mạnh trong ngành cơ khí mà hiện nay nhiều ngành và linh vực khác cũng áp dụng rất nhiều
Sử lý nước thải bằng phân hữu cơ vi sinh aqualift. Xử lý nước ao hồ, kênh rạch bị nhiễm bẩn, dòng sông ô nhiễm, ao nuôi tôm, ao nuôi cá tra.
Hướng dẫn sử dụng phân vi sinh hữu cơ Nhật Bản Aqualift, phân được nhập khẩu từ Nhật Bản sử dụng trong cây trồng lâu năm, lúa và hoa màu. Đồng thời có thể xử lý nước thải cho sông ngòi, kênh rạch
Tiêu đề: Các mô hình trong phát triển phần mềm
Bài viết dưới đây sẽ cho bạn kiến thức tổng quan về các mô hình phát triển phần mềm
Các mô hình SEP
Mô hình SEP còn được gọi là chu trình hay vòng đời phần mềm (SLC - Software Life Cycle). SLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có khá nhiều mô hình SLC khác nhau, trong đó một số được ứng dụng khá phổ biến trên thế giới:
Các mô hình một phiên bản (Single-version models)
• Mô hình Waterfall (Waterfall model)
• Mô hình chữ V (V-model)
• Các mô hình nhiều phiên bản (Multi-version models)
• Mô hình mẫu (Prototype)
• Mô hình tiến hóa (Evolutionary)
• Mô hình lặp và tăng dần (Iterative and Incremental)
• Mô hình phát triển ứng dụng nhanh (RAD)
• Mô hình xoắn (Spiral)
Mô hình Waterfall
Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau.
Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.
Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó.
Hiện thực và kiểm thử từng thành phần (Coding and Unit Test): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”.
Kiểm thử (Test): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.
Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống).
Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại để sửa chữa. Đây chính là kiểu waterfall dạng lặp (Iterative Waterfall).
Mô hình chữ V
Trong mô hình Waterfall, kiểm thử được thực hiện trong một giai đoạn riêng biệt. Còn với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng.
Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống.
Mô hình mẫu
Mô hình mẫu (prototype). Trong đó, qui trình được bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu tổng thể của hệ thống phần mềm sau này, đồng thời ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ.
Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm. Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu hơn những gì cần được phát triển. Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác.
Chú ý, prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó.
Mô hình tiến hóa
Mô hình này thực sự cũng là một dạng dựa trên mô hình mẫu, tuy nhiên có sự khác biệt:
• mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau.
• những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng trong những phiên bản sau.
Mô hình lặp và tăng dần
Mô hình lặp và tăng dần có lúc được hiểu là một. Tuy nhiên, trong bài viết này, ta có thể phân biệt ít nhiều sự khác biệt.
Trước tiên, hai mô hình này đều có điểm giống nhau là đều dựa trên tinh thần của mô hình tiến hóa, và có thêm đặc điểm nhắm đến việc cung cấp một phần hệ thống để khách hàng có thể đưa vào sử dụng trong môi trường hoạt động sản xuất thực sự mà không cần chờ cho đến khi toàn bộ hệ thống được hoàn thành (trong mô hình mẫu hay tiến hóa, các phiên bản mẫu hay trung gian đều không nhắm đến đưa vào vận hành thực sự cho khách hàng, trừ phiên bản cuối cùng). Để khách hàng có thể sử dụng, mỗi phiên bản đều phải được thực hiện như một qui trình đầy đủ các công việc từ phân tích yêu cầu với khả năng bổ sung hay thay đổi, thiết kế, hiện thực cho đến kiểm nghiệm và có thể xem như một qui trình (chu trình) con. Các chu trình con có thể sử dụng các mô hình khác nhau (thông thường là waterfall). Hình 5 minh họa hai mô hình này, trong đó mỗi chu trình con là một waterfall nhỏ.
Mục tiêu của phiên bản đầu tiên là phát triển phần lõi và nhóm các chức năng quan trọng. Sau mỗi phiên bản được đưa vào sử dụng, các kết quả đánh giá sẽ được phản hồi và lập kế hoạch cho chu trình con của phiên bản tiếp theo để thực hiện:
• Những thay đổi cho phiên bản trước đó nhằm đáp ứng nhu cầu khách hàng tốt hơn
• Có thể thêm những chức năng hoặc đặc điểm bổ sung
• Sự khác nhau giữa hai mô hình tăng dần và lặp có thể được hiểu đơn giản như sau (so với sản phẩm được hoàn thành trong chu trình con trước):
• Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm (xem minh hoạ Hình 6).
• Mô hình lặp (Iterative): thay đổi sản phẩm (xem minh họa Hình 6)
• Một SEP có thể kết hợp cả hai mô hình lặp lẫn tăng dần, chẳng hạn RUP (Rational Unified Process).
Mô hình phát triển nhanh
Mô hình phát triển nhanh (RAD - Rapid Application Development) chính là mô hình tăng dần với chu kỳ phát triển cực ngắn. Để đạt được mục tiêu này, RAD dựa trên phương pháp phát triển trên cơ sở thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần thích hợp. RAD thích hợp cho những hệ thống quản lý thông tin.
Mô hình xoắn
Mô hình này được xây dựng bởi Barry Boehm, đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản chất của mô hình lặp.
Trong mô hình này, việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung vào thiết kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung.
Trgon đó mỗi chu kỳ bao gồm 4 giai đoạn con như sau:
1. Xác định mục tiêu chất lượng cho sản phẩm được thực hiện, đồng thời xác định sự lựa chọn mua, tái sử dụng hay tự thiết kế và hiện thực các thành phần của hệ thống.
2. Phân tích sự lựa chọn và các rủi ro có thể xảy ra. Việc này được thực hiện bởi nhiều hoạt động khác nhau thông qua làm mẫu hay mô phỏng.
3. Phát triển và kiểm định sản phẩm ở mức tiếp theo dựa trên kết quả định hướng được chỉ ra trong giai đoạn con số 2 (phân tích rủi ro)
4. Kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đó và lập kế hoạch cho chu kỳ lặp tiếp theo.
Chúng tôi luôn cập nhật kiến thức công nghệ hay tại: https://www.facebook.com/hauisoftware
Tiêu đề: Tổng quan các mô hình phát triển phần mềm
Cũng như mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án.
Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao, điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm củng cố và phát triển cùng với nền công nghệ phần mềm đầy cạnh tranh.
Bài viết phần nào giúp bạn quyết định lựa chọn mô hình thích hợp khi xây dựng qui trình phát triển phần mềm chung cho cấp tổ chức hay cấp dự án.
Qui trình là gì?
Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm. Tương tự như vậy, SEP chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm.
Thông thường một qui trình bao gồm những yếu tố cơ bản sau:
• Thủ tục (Procedures)
• Hướng dẫn công việc (Activity Guidelines)
• Biểu mẫu (Forms/templates)
• Danh sách kiểm định (Checklists)
• Công cụ hỗ trợ (Tools)
Với các nhóm công việc chính:
• Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng.
• Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn các yêu cầu được chỉ ra trong “Đặc tả yêu cầu”.
• Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”.
• Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng.
Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng.
SEP, ISO, CMM/CMMI
Phần này sẽ không đi sâu vào tìm hiểu các mô hình phát triển phần mềm mà chỉ cung cấp một cái nhìn tổng quát về chúng, cũng như mối quan hệ giữa SEP với ISO và CMM/CMMI.
Vấn đề được đặt ra là làm thế nào cải tiến qui trình để cải thiện chất lượng và năng suất? Câu trả lời chính là qui trình khung (Process Framework - PF). PF sẽ chỉ ra những yêu cầu mà một qui trình phải đáp ứng tùy theo mỗi mức độ. PF không chỉ ra bất kỳ một qui trình cụ thể nào mà chỉ đưa ra những yêu cầu ở mỗi mức độ trưởng thành khác nhau của qui trình phải đạt được. Đây chính là những hướng dẫn cho các hoạt động cải tiến để nâng mức độ trưởng thành từ thấp lên cao.
Có nhiều PF, nhưng phổ biến nhất là ISO và CMM (Capability Maturity Model) được các tổ chức thế giới công nhận. ISO nhắm chung đến nhiều loại tổ chức cả sản xuất lẫn dịch vụ, trong khi CMM được dành riêng cho các tổ chức phát triển phần mềm. Đối với phần mềm, ISO chỉ ra mức độ chất lượng yêu cầu tối thiểu mà một SEP phải đạt (ISO certified) và việc cải tiến qui trình được thực hiện thông qua qui trình kiểm định, trong khi CMM bao gồm những thực tiễn tốt nhất (best practices) được tập hợp rút tỉa từ rất nhiều tổ chức phát triển phần mềm khác nhau và chúng được tổ chức thành 5 mức độ trưởng thành khác nhau (Level 1 - Initial, Level 2 - Repeatable, Level 3 - Defined, Level 4 - Managed, Level 5 - Optimizing).
Ngày nay, phần mềm không đứng riêng một mình mà thường là một bộ phận trong hệ thống hoàn chỉnh. Do đó, CMMI (Capability Maturity Model Integration) ra đời hướng đến các qui trình cho việc xây dựng cả hệ thống, bao gồm cả việc tích hợp để xây dựng và bảo trì toàn bộ hệ thống.
Chúng tôi luôn cập nhật kiến thức công nghệ hay tại: https://www.facebook.com/hauisoftware
Lịch sử phát triển công nghệ phần mềm
Nửa cuối những năm 1980 đến nay:
Chất lượng phần mềm tập trung chủ yếu ở năng suất, độ tin cậy và việc bảo trì. Nghiên cứu hỗ trợ tự động hóa sản xuất phần mềm. Nhiều trung tâm, viện nghiên cứu CNPM ra đời. Các trường đưa vào giảng dạy SE.
Hiện nay:
Công nghiệp hóa sản xuất phần mềm bằng cách đưa những kỹ thuật công nghệ học (Engineering techniques) thành cơ sở khoa học của CNPM.
Vận dụng những lý luận trong sản xuất phần mềm và áp dụng các phương pháp luận một cách nhất quán.
Tăng cường nghiên cứu và tạo công cụ trợ giúp sản xuất phần mềm.
Sự tiến triển của các phương pháp phát triển PM
1970.
Phương pháp luận về quy trình thiết kế phần mềm với phương pháp phân chia môđun và thiết kế trong từng môđun.
Phát triển: nửa đầu 1980.
Ngôn ngữ đối thoại đơn giản (4GL, DB SQL).
Hệ trợ giúp: Hệ trợ giúp kiểm thử; Hệ trợ giúp quản lý thư viện mã; Hệ trợ giúp tái sử dụng.
Biến đổi: nửa cuối 1980 đến nay.
Đưa ra các môi trường mới về phát triển phần mềm.
Triển khai mới về kết hợp giữa CNPM và CN Tri thức (Knowledge Engineering). Triển khai những môi trường bậc cao về phát triển phần mềm; Tự động hóa sản xuất phần mềm; Tạo bản mẫu (Prototyping); Lập trình hướng đối tượng - OOP; Hướng sử dụng thành phần (component).
Những thách thức đối với CNPM…
Cứ 6 đề án triển khai thì có 2 bị huỷ bỏ.
Trung bình thời gian thực hiện thực tế bị kéo dài 50% (cá biệt 200-300%).
Các đề án lớn dễ thất bại.
3/4 các hệ thống lớn có lỗi khi thực thi.
Quá trình phân tích yêu cầu (5% công sức): để lại 55% lỗi, có 18% phát hiện được. Quá trình thiết kế (25% công sức): để lại 30% lỗi, có 10% phát hiện được.
Quá trình mã hoá, kiểm tra và bảo trì: để lại 15% lỗi, có 72% phát hiện được.
Chúng tôi luôn cập nhật kiến thức công nghệ hay tại: Xem thêm: https://www.facebook.com/hauisoftware
Một số mô hình phát triển phần mềm
Mô hình phát triển phần mềm là một thể hiện trừu tượng của quy trình phần mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể; do đó, nó chỉ cung cấp một phần thông tin về quy trình phần mềm. Phần sau đây sẽ trình bày năm mô hình phát triển phần mềm phổ biến thường được sử dụng:
- Mô hình thác nước
- Mô hình xây dựng tiến triển
- Công nghệ phần mềm dựa thành phần
- Mô hình phát triển lặp lại, tăng thêm
- Mô hình xoắn ốc Mục tiêu
- Phải hiểu rõ năm mô hình phát triển phần mềm cơ bản.
- Phân biệt được sự khác nhau giữa các mô hình; ưu và nhược điểm của từng mô hình.
- Biết rõ đối với loại hệ thống nào thì nên áp dụng mô hình phát triển nào cho phù hợp.
Mô hình thác nước
Các pha của mô hình thác nước bao gồm:
- Phân tích và xác định các yêu cầu
- Thiết kế hệ thống và phần mềm
- Cài đặt và kiểm thử đơn vị
- Tích hợp và kiểm thử hệ thống
- Vận hành và bảo trì.
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 xây dựng tiến triển
Mô hình xây dựng tiến triển dựa trên ý tưởng xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thoả mãn yêu cầu của người sử dụng thì dừng lại. Có hai phương pháp để thực hiện mô hình này:
- Phát triển thăm dò: mục đích của nó là để làm việc với khách hàng và để đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu. Phương pháp này thường bắt đầu thực hiện với những yêu cầu được tìm hiểu rõ ràng và sau đó, bổ sung những đặc điểm mới được đề xuất bởi khách hàng. Cuối cùng, khi các yêu cầu của người sử dụng được thoả mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống.
- Loại bỏ mẫu thử: mục đích là để tìm hiểu các yêu cầu của hệ thống. Phương pháp này thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử dụng. Từ đó, ta có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này mẫu thử không còn cần thiết nữa. Như vậy, mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng. Tuy nhiên, nhược điểm của mô hình xây dựng tiến triển là: thiếu tầm nhìn của cả quy trình; các hệ thống thường hướng cấu trúc nghèo nàn; yêu cầu các kỹ năng đặc biệt (Ví dụ: các ngôn ngữ để tạo ra mẫu thử nhanh chóng). Mô hình xây dựng tiến triển chỉ nên áp dụng với những hệ thống có tương tác ở mức độ nhỏ hoặc vừa; trên một phần của những hệ thống lớn; hoặc những hệ thống có thời gian chu kỳ tồn tại ngắn.
Công nghệ phần mềm dựa thành phần
Mô hình này dựa trên kỹ thuật tái sử dụng một cách có hệ thống; trong đó hệ thống được tích hợp từ nhiều thành phần đang tồn tại hoặc các thành phần thương mại COTS (Commercial-off-the-shelf). Các trạng thái chính của quy trình bao gồm:
- Phân tích thành phần sẵn có
- Điều chỉnh yêu cầu
- Thiết kế hệ thống với kỹ thuật tái sử dụng
- Xây dựng và tích hợp hệ thống
Mô hình phát triển lặp lại, tăng thêm
Mô hình này được đề xuất dựa trên ý tưởng thay vì phải xây dựng và chuyển giao hệ thống một lần thì sẽ được chia thành nhiều vòng, tăng dần. Mỗi vòng là một phần kết quả của một chức năng được yêu cầu. Các yêu cầu của người sử dụng được đánh thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên càng cao thì càng ở trong những vòng phát triển sớm hơn. Từ đó, chúng ta có thể thấy rõ một số ưu điểm của mô hình phát triển tăng vòng:
- Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả thực hiện được cho khách hành nên các chức năng của hệ thống có thể nhìn thấy sớm hơn.
- Các vòng trước đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.
- Những chức năng của hệ thống có thứ tự ưu tiên càng cao thì sẽ được kiểm thử càng kỹ.
Mô hình xoắn ốc
Trong mô hình xoắn ốc, quy trình phát triển phần mềm được biểu diễn như một vòng xoắn ốc. Các pha trong quy trình phát triển xoắn ốc bao gồm:
- Thiết lập mục tiêu: xác định mục tiêu cho từng pha của dự án.
- Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực hiện các hành động để giảm thiểu rủi ro.
- Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình xây dựng hệ thống sẽ được lựa chọn từ những mô hình chung.
- Lập kế hoạch: đánh giá dự án và pha tiếp theo của mô hình xoắn ốc sẽ được lập kế hoạch.
Xem công nghệ mới nhất tại: https://www.facebook.com/hauisoftware
