Một cách nhìn khác về Rational Unified Processes (RUP).

Tìm hiểu cơ bản về Rational Unified Processes (RUP).

Đôi khi khi xin phỏng vấn đi làm, bạn thường được hỏi có biết về RUP hay không. Đây là một trong nhưng kiến thức được yêu cầu khi làm trong các dự án phần mềm. Kiến thức này cũng có được giới thiệu trong môn học Công nghệ phần mềm trong các trường ĐH nhưng ít được chú ý tới.

Thông thường mọi người đều cho rằng phát triển một phần mềm sẽ đi quá các bước Phân tích - Thiết kế - Viết code - Test - Triển khai - Bảo trì. Tuy nhiên RUP thì hơi khác một chút, Tôi tóm ở đây 4 điểm quan trọng theo tham khảo từ một bài viết trên Internet như sau:

Large in serial:

Một dự án phần mềm sẽ được chia thành 4 pha tuần tự nhau:

• Inception 
• Elaboration 
• Construction 
• Transition.

Small in interaction:

Trong mỗi pha sẽ gồm có một chu trình gồm hàng loạt các bước như sau:

• Business Modeling 
• Requirement  Analysis & Design 
• Implementation 
• Test 
• Deployment 
• Configuration & Change Management 
• Project Management 
• Environment

Delivering incremental releases over time:

Theo như tác giả, một phần mềm sẽ tiến hóa theo thời gian qua các phiên bản khác nhau. Sau khi kết thúc 1 chu kỳ 4 pha, các tính năng mới hoặc các yêu cầu mới, các cải tiến về công nghệ sẽ được thêm vào hệ thống bằng 1 chu kỳ 4 pha khác. Trong mỗi pha của chu kỳ mới này, lần lượt 9 discipline sẽ được thực hiện.

Following proven best practice:

Khi làm bất cứ một công việc gì dù lớn hay nhỏ đều cần có qui trình, qui trình giúp phân công công việc hợp lý và đảm bảo chất lượng. RUP là một chuẩn qui trình đã được nghiên cứu, xây dựng, và áp dụng phổ biến trong ngành công nghiệp phần mềm, cho nên việc sử dụng lại thay vì tự xây dựng 1 qui trình riêng cho mình là một điều cần lưu ý.

Những kinh nghiệm xương máu được đúc kết:

• Adapt process:
• Nghĩa là phải customize các qui trình này cho phù hợp với hoàn cảnh thực tế chứ không máy móc áp dụng
• Balance competing stakeholder priorities:
• Các stakeholders (thành phần tham gia trong dự án) có những ưu tiên riêng, do vậy cần phải cân bằng không nên thái quá.
• Collaborate across teams:
• Nói ngắn gọn chính là phải có teamwork, phải biết phối hợp và chuyền bóng
• Demonstrate value iteratively:
• Cái này có vẻ quan trọng, nghĩa là trong mỗi pha, cần phải cho khách hàng thấy được prototype của sản phẩm ở mức độ nào đó để họ có thể cho phản hồi và nếu có thay đổi thì có thời gian điều chỉnh sớm hơn.
• Thuật ngữ chuyên ngành gọi là "Change Management", nghĩa là các yêu cầu vốn luôn thay đổi của khách hàng cần phải được kiểm soát.
• Elevate the level of abstraction.
• Nâng cao mức độ trừu tượng để thấy hết các rủi ro, khả năng đáp ứng của công nghệ để có thể xây dựng 1 kiến trúc phù hợp
• Focus continuously on quality.
• Cái này khỏi bàn, vì chất lượng là yếu tố quyết định của bất cứ sản phẩm gì. JavadeveloperVietnam Training sẽ có 1 loạt bài bình luận thêm về vấn đề rất hấp dẫn này (Software verification and validation).
• Đảm bảo chất lượng phần mềm phải được thực hiện ở các bước chứ không chỉ riêng bước testing.
• Trong Agile Development, Test Driven Devlelopement, nghĩa là viết unit test trước khi viết code thực sự, được thực hiện nhằm đảm bảo các dòng code viết ra đảm bảo chất lượng.

Bình luận JDVT:

Đau đầu nhất trong phát triển phần mềm là thay đổi yêu cầu hoặc không hiểu hết yêu cầu của nghiệp vụ. Các biện pháp nêu ở trên chỉ có thể làm giảm nhẹ thiệt hại chứ không thể giải quyết triệt để vấn đề bởi vì nhiều lý do

• Cái chúng ta biết là hữu hạn, cái chưa biết là vô hạn.
• Side effect (hiệu ứng lề): sửa cái này nó ảnh hưởng cái khác
• Ở các dự án phần mềm viết mới, vấn đề này làm đau đầu nhất. 
• Còn trong các dự án triển khai phần mềm có sẵn, chỉnh sửa theo yêu cầu, vấn đề sẽ nhẹ nhàng hơn.
• Băn khoăn thiết kế (tạm dịch: dilema of design): cùng một yêu cầu nên thiết kế thế nào cho phù hợp, chọn nhanh nhưng cứng hay chọn mềm dẻo nhưng mất thời gian.

Ở Việt Nam, và có lẽ cả trên thế giới, hiện nay các công ty phần mềm quản lý đều dần đi theo xu hướng làm phần mềm chuyên dụng, tạm gọi là làm một lần - bán nhiều nơi. Các nhóm lập trình phần mềm nghiệp dư, đầu tư ít, lấy giá xây dựng phần mềm rẻ, làm lan man nhiều loại phần mềm khác nhau sẽ khó tồn tại vì nhiều vì lý do:

• Chất lượng phần mềm viết ra không đảm bảo
• Viết cứng (hardcode) nhiều chỗ nên khó có thể bán ở chỗ khác
• Do viết phần mềm đủ các lĩnh vực nên không chuyên, thiếu kiến thức
• Cuối cùng, bởi vì không có thương hiệu, uy tín thấp, sản phẩm không chất lượng nên chỉ có thể bán cho các công ty nhỏ, giá rẻ --> không đủ tiền để bù chi phí bỏ ra --> chán nản, dẹp tiệm.

 Nguồn: Java Developer Viet Nam Training.