Một người phát triển phần mềm đã viết cho tôi: “Thiết kế phần mềm có phải là khái niệm thiết kế được dạy trong đại học nhưng không được dùng trong công nghiệp không? Em đã làm việc như người phát triển phần mềm trong hai năm nhưng hiếm khi thấy bất kì thiết kế nào trong công ti em. Chúng em thường đi từ yêu cầu tới viết mã để làm cho dự án được nhanh hơn. Thiết kế có cần không? Thầy có thể giải thích về thiết kế phần mềm không?”
Đáp: Thiết kế phần mềm không phải là khái niệm được dạy trong đại học. Nó được dùng rộng rãi trong công nghiệp. “Mã trước, hỏi câu hỏi sau” là thói quen xấu và không nên được dùng. Dường như là cấp quản lí công ti bạn không được đào tạo đúng về qui trình phát triển phần mềm.
Theo định nghĩa, thiết kế phần mềm là qui trình giải quyết vấn đề và lập kế hoạch cho giải pháp phần mềm. Trong phần mềm, có nhiều giải pháp có thể. Không có “giải pháp “đúng” hay “sai” nhưng chỉ có “tốt hơn” hay “kém hơn” tuỳ theo vấn đề mà bạn đang cố giải quyết. Vì phần mềm là sản phẩm của tâm trí, không phải là thứ vật lí như phần cứng, nhà, hay cầu, bạn không có qui tắc tường minh để phải theo. Tuy nhiên, có hai yếu tố sẽ xác định ra việc thiết kế cho giải pháp của bạn: Bạn hiểu vấn đề rõ thế nào? Và bạn hiểu giải pháp của bạn rõ thế nào?
Trong phần mềm, hiểu vấn đề nghĩa là bạn phải biết về các ràng buộc kĩ thuật, yêu cầu chức năng, thuộc tính chất lượng, và ràng buộc doanh nghiệp. Bằng việc biết những ràng buộc này, bạn sẽ đặt ra giới hạn của giải pháp của bạn. Các yêu cầu chức năng là điều giải pháp phải làm trong khi các thuộc tính chất lượng giải quyết một số chức năng thực hiện tốt thế nào. Ràng buộc doanh nghiệp là những giới hạn do lí do doanh nghiệp như ngân sách hay lịch biểu. Bạn không thể vượt quá số tiền nào đó hay cứ xây dựng phần mềm mãi.
Giải pháp là mọi khả năng bạn có thể nghĩ tới. Là người phát triển, chính việc làm của bạn là chọn lựa giải pháp tốt nhất cho vấn đề. Hiểu biết của bạn về vấn đề giới hạn chọn lựa của bạn vào vài giải pháp cho nên bạn phải phân tích chúng và lựa chọn giải pháp tốt nhất. Nếu bạn không thể quyết định được, bạn có thể xây dựng “bản mẫu” hay giải pháp tạm thời và đề nghị khách hàng ra quyết định cho bạn.
Trong phát triển phần mềm, có vài cách tiếp cận cơ sở. Thiết kế theo kế hoạch yêu cầu rằng thiết kế phải được hoàn thành trước khi bạn có thể thực hiện. Cách tiếp cận này được liên kết với vòng đời thác đổ. Nó được giả định rằng bạn biết mọi yêu cầu và chúng sẽ không thay đổi. Thiết kế tiến hoá cho phép bạn thiết kế ra giải pháp tăng dần khi nó được thực hiện. Bạn bắt đầu thiết kế theo từng mảnh nhỏ rồi thực hiện nó để xem nó làm việc thế nào rồi tiếp tục lặp lại cùng bước đó lần nữa cho tới khi được thực hiện xong. Cách tiếp cận này được liên kết với vòng đời xoáy ốc hay vòng đời đưa ra gia tăng. Cách Thiết kế Nổi lên cho phép thiết kế hệ thống xuất hiện khi hệ thống được thực hiện mà không có chủ định đặc biệt. Nó thường được liên kết với cách tiếp cận Agile như Scrum. Vì các yêu cầu có thể thay đổi bất kì lúc nào do đó thiết kế cũng có thể thay đổi theo từng chặng nước rút Sprint.
Không có giải pháp hoàn hảo cũng như không có cách tiếp cận hoàn hảo trong phần mềm. Điều bạn làm được xác định bằng khối lượng rủi ro mà tổ của bạn sẽ nhận. Ít rủi ro ngụ ý rằng bạn dự đoán ít thay đổi vì nó cho bạn nhiều tuỳ chọn hơn trong thiết kế của bạn. Kiến trúc và thiết kế sẽ tuỳ thuộc vào ưa chuộng và kinh nghiệm của tổ của bạn. Tổ ít kinh nghiệm không nên chọn thiết kế phức tạp vì điều đó là rủi ro. Bạn càng hiểu vấn đề và ràng buộc của nó, bạn càng đi tới thiết kế tốt hơn. Nếu bạn có ít thời gian, nếu ngân sách của bạn eo hẹp thì bạn không có mấy chọn lựa trong thiết kế. Bạn càng biết ít về vấn đề thì bạn sẽ có khó khăn trong việc quyết định về thiết kế của bạn và đó là lí do tại sao các kĩ sư yêu cầu và kiến trúc sư hệ thống là quan trọng thế trong dự án phần mềm.
Để đi tới thiết kế tốt hơn, bạn phải học thêm về vấn đề mà bạn đang định giải quyết. Nếu tổ của bạn cảm thấy rằng họ không biết đủ về vấn đề dựa trên đặc tả yêu cầu, bạn cần tiến hành thảo luận với khách hàng và người dùng để làm tăng tri thức của bạn về vấn đề. Nếu tổ cảm thấy có nhiều rủi ro về dự án thì bạn nên thăm dò cách tiếp cận bản mẫu để cho người dùng thử. Tuỳ chọn khác là tuân theo qui trình thiết kế như Phương pháp luận thiết kế là trung tâm Architecture Centric Design Methodology (ACDM). ACDM là qui trình thiết kế được phân giai đoạn khuyến khích tổ thăm dò thiết kế qua thực nghiệm bằng việc đề cập tới các vấn đề trong thiết kế được đề nghị. ACDM hội tụ mạnh vào thuộc tính chất lượng và sẽ giúp cho tổ của bạn hướng tới cách tiếp cận thiết kế theo kế hoạch nhưng qui trình có thể được điều chỉnh để dùng thiết kế khác nếu tổ của bạn muốn dùng.
—-English version—-
Software Design
A software developer wrote to me: “Is software design a theoretical concept to be taught in college but not used in industry? I have worked as developer for two years but rarely saw any design in my company. We often go from requirements to code to get projects complete faster. Is design necessary? Can you explain about software design?”
Answer: Software design is not a concept to be taught in college. It is widely used in software industry. “Code first, ask question later” is a bad habit and should not be used. It seems that your company management is not properly trained on software development process.
By definition, software design is a process of problem solving and planning for a software solution. In software, there are many possible solutions. There is no “right” or “wrong” solution but only “better” or “worse” depending on the problem that you are trying to solve. Because software is a product of the mind, not physical things like hardware, a house, or a bridge, you have no explicit rule that you must follow. However, there are two factors which will determine the designing of your solution: How well do you understand the problem? and how well do you understand your solution?
In software, understanding the problem means you must know about technical constraints, functional requirements, quality attributes, and business constraints. By knowing these constraints, you will set the limitation of your solution. Functional requirements are what the solution must do while quality attributes deal with how well it performs certain functions. The business constraints are limitation due to business reasons such as budget or schedule. You cannot exceed certain amount of money or take forever to build software.
The solution is all the possibilities that you can think of. As developer, it is your job to select the best possible solution to a problem. Your understanding of the problem limits your selection to a few so you must analyze them and select the best. If you cannot make decision, you may build a “prototype” or temporary solution and ask the customers to make decision for you.
In software design, there are few basic approaches. A Planned Design requires that the design must be completed before you can implement. This approach is associated with waterfall lifecycles. It is assumed that you know all requirements and they will not change. An Evolutionary Design allows you to design the solution incrementally as it is implemented. You start design in small piece then implement it to see how it work then continue to repeat the same step again until done. This approach is associated with the Spiral lifecycle or Incremental release lifecycle. The Emergent Design allows the design of the system to occur as the system is implemented without specific intentions. It is often associated with Agile approach such as Scrum. Since requirements may change anytime therefore design may also change with each Sprint.
There is no perfect solution as well as no perfect design approach in software. What you do is determined by the amount of risk that your team is going to take. Less risk implies that you anticipate less change as it gives you more options in your design. Architect and Design will depend on your team’s preferences and experience. A less experienced team should not choose a complex design because it is risky. The more you understand the problem and its constraints, the better you can come up with a design. If you time is short, if your budget is tight then you do not have much choice in designing. The less you know about a problem then you will have difficulty in making decision about your design and that is why requirements engineer and system architect are so important in software project.
To come up with better design, you must learn more about the problem that you are trying to solve. If your team feels that they do not know enough about the problem based on the requirements specification, you need to conduct discussions with customer and users to increase your knowledge about the problem. If the team feels there is a lot of risk on the project then you should explore prototype approach then get your users to try. Another option is to follow a design process such as the Architecture Centric Design Methodology (ACDM). ACDM is a staged design process that encourages teams to explore the design through experiments by addressing issues in proposed designs. ACDM strongly focuses on quality attributes and will help your team toward a planned design approach but the process can be adjusted to use a different design if your team wants to.
