Pha kiến trúc phần mềm
Một sinh viên hỏi: “Khác biệt gì giữa pha kiến trúc và pha thiết kế? Em bị lẫn lộn vì vòng đời phần mềm chỉ nhắc tới yêu cầu, thiết kế, viết mã và kiểm thử. Cái gì xảy ra trong pha thiết kế? Kiến trúc làm gì trong pha này? Xin thầy giải thích.”
Đáp: Về căn bản, pha kiến trúc là mức trừu tượng cao nhất của hệ thống phần mềm và pha thiết kế là mức thấp hơn hội tụ vào các chi tiết như mô đun và cấu phần. Kiến trúc là việc phân bổ các yêu cầu hệ thống (phần cứng, phần mềm, giao diện, v.v.) cho các cấu phần hệ thống cũng như giao diện giữa các cấu phần này. Thiết kế thường giải quyết với việc lập chức năng cho từng cấu phần một cách chi tiết hơn. Chẳng hạn, khi bạn xây ngôi nhà bạn cần kiến trúc sư để thiết kế mọi cấu phần của ngôi nhà như nền móng, trụ nhà, mái và tường nhưng bạn không cần kiến trúc sư để thiết kế bếp chi tiết hay phòng ngủ trong nhà. Những chi tiết này thường được trao cho công nhân xây dựng và người trang trí nội thất.
Khi bạn xây dựng một hệ thống phần mềm lớn và phức tạp, bạn cần phân chia hệ thống thành các cấu phần nhỏ hơn để dễ thực hiện hơn. Pha kiến trúc là bước bản chất để chắc các cấu phần được xác định và tương tác giữa chúng được nhận diện rõ ràng. Đôi khi mọi người coi pha kiến trúc là pha “thiết kế mức cao” và thiết kế là pha “thiết kế chi tiết”. Vòng đời thác đổ coi cả hai pha này đều là “thiết kế” để giữ cho nó đơn giản và dễ dàng hơn cho sinh viên học. Vì phần lớn các dự án trong trường đều nhỏ và đơn giản nơi phần cứng và tương tác với phần mềm đã được biết, sinh viên không quan tâm tới phần cứng có thể bắt đầu từ pha thiết kế phần mềm. Tuy nhiên trong công nghiệp, phần lớn dự án phần mềm đều lớn và phức tạp và bạn cần biết mọi cấu phần của toàn thể hệ thống (cả phần cứng và phần mềm) cho nên bạn phải học về kiến trúc phần mềm cho tốt để xây dựng hệ thống có chất lượng.
Trong pha kiến trúc, bạn phải nhận diện hoàn cảnh và phạm vi của dự án bằng việc thiết lập biên giới dựa trên yêu cầu của khách hàng. Bạn cần xác định cả cách nhìn chức năng cũng như phi chức năng và mọi ràng buộc. Bạn cần nhận diện mọi cấu phần như cách nhìn qui trình, cách nhìn logic, cách nhìn vật lí, cách nhìn giao diện, cách nhìn kết cấu nền, cách nhìn vận hành và cách nhìn an ninh cho hệ thống phần mềm đầy đủ.
Phần lớn những người phát triển phần mềm thường chú ý tới các chức năng của hệ thống nhưng không chú ý tới cách nhìn phi chức năng (thuộc tính chất lượng). Bởi vì phần lớn các cách nhìn phi chức năng không được xác định rõ, dự án thường lâm vào vấn đề về sau vì đây là những điều khách hàng mong đợi nhưng hiếm khi nhắc tới trong các yêu cầu. Đây là chỗ những người phát triển có kinh nghiệm đang làm tốt hơn những người không có kinh nghiệm vì họ học nhiều năm làm việc bằng việc biết cái gì để hỏi khách hàng. Khách hàng có thể nói: “Hệ thống phải chạy nhanh “, đó là yêu cầu phi chức năng nhưng điều đó là quá mông lung. Người phát triển có kinh nghiệm biết cách hỏi khách hàng về những chi tiết đặc biệt hơn để chắc yêu cầu này là đo được và kiểm thử được. (Ông muốn nhanh như thế nào? Ông ngụ ý gì bởi nhanh? Bao nhiêu giây? v.v.) Họ biết rằng để đạt tới sự thoả mãn của khách hàng họ cần chắc rằng tất cả các cách nhìn phi chức năng đều được xác định. Những điều này bao gồm các đặc trưng khi chạy như hiệu năng, tính đổi qui mô, tính sẵn có và tính an ninh v.v. Đó là lí do tại sao các kĩ sư yêu cầu là quan trọng thế trong hệ thống lớn hơn và phức tạp để xác định các yêu cầu phi chức năng này.
Bởi vì phần lớn các yêu cầu phi chức năng đều là vấn đề hệ thống, pha kiến trúc phải nhận diện chúng cũng như xác định tương tác giữa chúng kiểu như khi xây nhà kiến trúc sư phải tính toán sức mạnh của móng và tất cả các cột giữ cho ngôi nhà đứng tại chỗ. Chẳng hạn, nhà lớn hơn yêu cầu nền móng tốt hơn và nhiều cột để đỡ trọng lượng của ngôi nhà. Bởi lí do này pha kiến trúc là quan trọng trong các hệ thống lớn. Khi mọi yêu cầu chức năng và phi chức năng được xác định, bước tiếp là hội tụ vào cách từng cấu phần được thực hiện. Trong pha này, kiến trúc sư phần mềm quyết định về công nghệ nào được dùng, cấu phần nào được xây dựng trong nhà, cấu phần nào được mua từ nhà cung cấp, cấu phần nào có thể được khoán ngoài. Họ phải ra quyết định dựa trên các yếu tố như chi phí, cấp phép, quan hệ với nhà cung cấp, tính tương hợp, tính liên tác, sự hỗ trợ và môi trường người dùng v.v. Những quyết định này là sống còn cho thành công của dự án bởi vì chúng là rủi ro mà phải giải quyết. Kiến trúc sư phần mềm phải giảm rủi ro chỗ có độ phức tạp hay bất định cao bằng việc tiến hành phân tích bù trừ để quản lí rủi ro và phải chắc dự án có thể được thực hiện bên trong chi phí và lịch biểu. Mọi quyết định đều phải được kiểm điểm và đánh giá bởi kiến trúc sư, người lãnh đạo tổ, người quản lí dự án và khách hàng.
Vấn đề chính với hệ thống phần mềm lớn và phức tạp là ở chỗ khó cho mọi người hiểu làm sao những cấu phần này làm việc cùng nhau. Đó là lí do tại sao kiến trúc sư phần mềm phải dùng công cụ như các biểu đồ theo ngôn ngữ mô hình hoá thống nhất – Unified Modeling Language (UML) để truyền đạt kiến trúc cho người khác. Kiểm điểm của kiến trúc sư là chỗ mà tổ dự án, tổ hỗ trợ (đảm bảo chất lượng phần mềm SQA và quản lí cấu hình phần mềm SCM, chuyên gia cơ sở dữ liệu, chuyên gia an ninh v.v.) cũng như cấp quản lí và khách hàng phải tham gia vào để hiểu cách toàn thể hệ thống sẽ làm việc. Kiến trúc sư phần mềm phải chắc rằng kiến trúc được xác định là được hiểu bởi mọi người tham gia. Tất nhiên, tổ phát triển phải hiểu chúng vì họ sẽ phải thiết kế và thực hiện từng cấu phần nhưng tổ hỗ trợ cũng phải biết rõ kiến trúc. Người quản lí cấu hình phải đặt tuyến cơ sở để đảm bảo rằng mọi thay đổi đều trong kiểm soát. Đảm bảo chất lượng phải kiểm điểm mọi cấu phần kiến trúc và phải chắc rằng chúng tuân thủ theo chuẩn và thủ tục. Chuyên gia an ninh phải chắc rằng kiến trúc đã lấy các bước cần thiết để đảm bảo tính toàn vẹn của hệ thống v.v.
Nếu kiến trúc được chấp thuận, bước tiếp là phân công các thành viên tổ bắt đầu qui trình thiết kế cho từng cấu phần. Mặc dầu kiến trúc sư không tham gia vào trong thiết kế và viết mã cho các nhiệm vụ, nhưng người đó phải tích cực giúp các thành viên tổ để chắc rằng họ đang làm nó đúng bên trong kiến trúc đã xác định. Về căn bản pha kiến trúc là quan trọng nhất trong dự án phần mềm lớn. Nếu nó được làm tốt, sẽ có ít vấn đề về sau nhưng nếu nó không được xác định tốt, cơ hội để dự án thất bại có thể rất cao. Một kiến trúc được xác định kém sẽ dẫn tới thiết kế dở và thiết kế dở sẽ dẫn tới dự án thất bại và đó là lí do tại sao nhiều dự án phần mềm thất bại. Chúng không bao giờ thất bại vì việc viết mã nhưng bởi vì thiết kế dở và kiến trúc được xác định nghèo nàn. Đó là lí do tại sao tôi nghĩ kĩ nghệ phần mềm bao quát mọi pha của phát triển phần mềm là được cần cho mọi sinh viên phần mềm.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Kĩ nghệ phần mềm
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
