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.
—English version—
Software architecture phase
A student asked: “What is the difference between an architecture phase and a design phase? I am confused because the software lifecycle only mentions requirements, design, code, and test. What happen in the architecture phase? What does an architect do in this phase? Please explain.”
Answer: Basically, architecture phase is the highest level of abstraction of a software system and the design phase is the lower level that focuses on the details such as modules and components. Architecture is the allocation of system requirements (Hardware, Software, Interface etc.) to system components as well as the interaction between these components. Design usually deals with the functioning of each component in more details. For example, when you build a house you need an architect to design all the components of a house such as foundation, columns, roofs and walls but you do not need the architect to design the detailed kitchen or a bed rooms in the house. These details are often given to construction workers and the interior decorators.
When you build a large and complex software system, you need to divide the system into smaller components for easier implementation. Architecture phase is an essential step to make sure all these components are defined and the interaction between them is clearly identified. Sometime people consider architecture phase as the “high design” phase and design as the “detailed design” phase. The waterfall lifecycle considers both phases as “design” to keep it simple and easier for students to learn. Since most projects in school are small and simple where hardware and the interaction with software are known, students do not concern with hardware can start with the design phase of software. However in the industry, most software projects are large and complex and you need to know all components of the entire system (Both hardware and software) so you must learn software architecture well in order to build a quality system.
In the architecture phase, you must identify the context and scope of the project by set up boundary based on the customers’ requirements. You need to define both functional as well as non-functional views and all constraints. You need to identify all components such as the process view, logical view, physical view, interface view, infrastructure view, operational view, and security view for a complete software system.
Most software developers often pay attention to the functions of the system but not pay enough attention to the non-functional views (The quality attributes). Because most non-functional views are not well defined, projects often get into problem later because these are what customers’ expect but rarely mention in the requirements. This is where experienced developers are doing better than inexperienced ones as they learn through years of working by knowing what to ask customers. The customers may say: “The system must be fast”, it is a non-function requirements but that is too vague. Experienced developers know how to ask customers for more specific details to make sure that this request is measurable, and testable. (How fast do you want? What do you mean by fast? How many second? Etc.) They know that to achieve customers’ satisfaction they need to make sure that all of the important non-functional views are defined. These include the runtime characteristics such performance, scalability, availability and security etc. That is why the role of requirements engineers is so important in larger and complex system to clearly define these non-functional requirements.
Because most of the non-functional requirements are systemic issues, the architecture phase must identifies them as well as defines the interaction among them just like when building a house the architect must calculate the strength of the foundation and all the columns that keep the house in place. For example, larger house requires better foundation and more columns to withstand the weight of the house. For this reason the architecture phase is important in large software system. When all the functional and non-functional requirements are defined, the next step is to focus on how each component is implemented. In this phase, the software architect decides on what technologies are used, which components are built in house, which ones are brought from vendors, which one can be outsourced. They have to make decision based on factors such as cost, licensing, vendor relationships, compatibility, interoperability, support, and user environments etc. These decisions are vital to the success of the project because they are risks that must be deal with. Software architect must reducing risk where there is high degree of complexity or uncertainty by conducting trade-off analysis to manage risks and make sure the project can be done within costs and schedules. All decisions must be reviewed and evaluated by the architect, team leaders, project manager and customers.
The main problem with large and complex software system is that it is difficult for people to understand how these components work together. That is why software architect must use tool such as the Unified Modeling Language (UML) diagrams to convey the architecture to others. The architect review is where the project team, the support team (SQA and SCM, database specialists, security specialists etc.) as well as management and customers must participate to understand how the entire system will work. The software architect must make sure that the defined architecture is understood by everybody involved. Of course, development team must understand them since they will have to design and implement each component but support team must also know the architecture well. Configuration Management people must set a baseline to assure that all changes are under controlled. Quality Assurance must review all architecture components and make sure that they comply with standards and procedures. Security specialist must make sure that the architecture has taken necessary steps to ensure the integrity of the system etc.
If the architecture is approved, the next step is assign team members to start the design process for each component. Although the architect does not involved in the design and coding tasks, but he must actively helping team members to make sure that they are doing it correctly within the defined architecture. Basically the architecture phase is the most important in large software project. If it is done well, there will be les problems later but if it is not well defined, the chance that the project will fail may be very high. A poorly defined architecture will lead to bad design and bad design will lead to project failure and that is why so many software projects fail. They never fail because of coding but because of bad design and poorly defined architecture. That is why I think software engineering that covers all phases of software development is needed for all software students.
