Một sai lầm thông thường trong các sinh viên về phần mềm là ở chỗ phát triển phần mềm chỉ là lập trình. Khi họ nghĩ về lập trình, họ nghĩ tới các ngôn ngữ như C, C++, Java v.v. và chừng nào họ còn có thể viết mã trong các ngôn ngữ đó, họ có thể làm phần mềm. Thực ra, lập trình chỉ là một phần nhỏ của qui trình phát triển phần mềm. Có nhiều điều phải được thực hiện trước khi việc lập trình có thể xảy ra.
Qui trình của việc phát triển phần mềm bao gồm nhiều bước. Tổng của mọi bước được gọi là vòng đời phát triển phần mềm. Có nhiều vòng đời phát triển phần mềm như mô hình thác đổ, mô hình xoáy ốc, mô hình đưa ra tăng dần v.v. Tuy nhiên, tất cả các mô hình này đều bao gồm năm qui trình cơ bản tạo nên vòng đời phần mềm: Yêu cầu, Thiết kế, Thực hiện (viết mã), Tích hợp & kiểm thử, và Bảo trì.
Qui trình yêu cầu: Điển hình, tổ dự án nhận được đặc tả yêu cầu từ khách hàng. Tổ kiểm điểm, phân tích các yêu cầu này rồi gặp gỡ khách hàng để thảo luận và làm hợp thức các yêu cầu này. Người quản lí dự án và một số thành viên then chốt phải dùng một số kĩ thuật để đánh giá “nhu cầu thực” của khách hàng. Sai lầm thông thường trong các sinh viên là coi đặc tả yêu cầu là đủ tốt để bắt đầu dự án cho nên họ không học phân tích và thẩm tra các yêu cầu này. Thực ra, phần lớn các đặc tả yêu cầu do khách hàng viết đều không tốt. Phần lớn có nhiều yêu cầu xung đột hay thiếu và không biểu thị “nhu cầu thực” của khách hàng. Nhiều yêu cầu chỉ là “ước muốn” chứ không phải là “nhu cầu” và một số thậm chí đã áp đặt giải pháp cho người phát triển. Đó là lí do tại sao tổ dự án phải phân tích, kiểm điểm và làm hợp thức chúng với khách hàng trước khi dự án có thể bắt đầu. Nếu qui trình yêu cầu không được thực hiện đúng, phần mềm cuối cùng có thể không hữu dụng cho khách hàng hay không đáp ứng nhu cầu của họ.
Đặc tả yêu cầu được khách hàng viết thường phản ánh cái nhìn của người dùng. Tổ dự án phải phân tích và hiểu nhu cầu của người dùng, cách nó sẽ được dùng, và biến đổi chúng thành cái nhìn của người phát triển, nơi họ có thể thực hiện. Nếu yêu cầu không được xác định rõ vì khách hàng có thể không biết điều họ thực sự muốn, tổ dự án có thể phải dùng kĩ thuật như làm bản mẫu nhanh theo đó một “bản mẫu” đơn giản được xây dựng mô phỏng chức năng của phần mềm cuối cùng được mong đợi. Bằng việc dùng “bản mẫu” này để trình diễn cho khách hàng, tổ dự án có thể thảo luận chi tiết với khách hàng để hiểu các sản phẩm cuối cùng sẽ được dùng và xác định “yêu cầu thực”. Qui trình yêu cầu được hoàn tất khi bản đặc tả yêu cầu phần mềm được chuyển đầy đủ sang cách nhìn của người phát triển để cho tổ dự án có thể chuyển sang pha tiếp. (Lưu ý: Tổ dự án càng để nhiều nỗ lực vào qui trình này, các yêu cầu sẽ càng ít có khả năng thay đổi và cơ hội cho dự án phần mềm đạt tới sự thoả mãn của khách hàng là cao.)
Qui trình thiết kế: Trong qui trình này, tổ dự án quyết định “cách” họ sẽ xây dựng sản phẩm phần mềm để cho nó đáp ứng các đặc tả được chấp thuận. Thông thường qui trình thiết kế trải qua vài bước từ mức cao (kiến trúc) tới các mức thấp hơn (thiết kế chi tiết). Tại mức kiến trúc, các yêu cầu được tổ chức thành các kiểu hay cách nhìn khác nhau. Cách nhìn là biểu diễn của tập các cấu phần hệ thống và mối quan hệ giữa chúng. Đây là chỗ cấu phần phần cứng, cấu phần phần mềm và cấu phần giao diện được nhận diện và được tổ chức về cách chúng sẽ được thực hiện. Qui trình này được gọi là “làm mịn dần” (từng bước một) vì nó cho phép tổ dự án quản lí độ phức tạp của phần mềm. Bắt đầu ở mức cao tại tầng cấu phần, tổ dự án có thể phân rã chức năng thành các nhiệm vụ đặc biệt hơn ở câu lệnh ngôn ngữ lập trình. Khi thiết kế được hoàn tất, nó được ghi lại trong tài liệu đặc tả thiết kế. (Lưu ý: Tổ dự án càng để nhiều nỗ lực vào qui trình này, sản phẩm cuối cùng sẽ càng trở nên có chất lượng cao hơn và cấu trúc tốt hơn. Các thuộc tính nào đó như tính hiệu năng, tính đổi qui mô, tính bảo trì v.v được nhận diện trong qui trình thiết kế)
Qui trình thực hiện (viết mã): Trong qui trình này, tổ dự án bắt đầu viết mã của phần mềm dựa trên cấu phần thiết kế. Phần mềm được chia thành các đơn vị tách rời được gọi là mô đun để giải quyết độ phức tạp của qui trình lập trình. Tổ phải thực hiện những mô đun này tương ứng theo chuẩn và thủ tục viết mã. Thành viên tổ cũng chịu trách nhiệm cho làm tài liệu đúng mô tả cho mã của họ và cho kiểm thử mã để đảm bảo tính đúng đắn.
Thành viên tổ phải kiểm thử công việc riêng của họ để chắc chúng làm việc tốt (kiểm thử đơn vị) trước khi trao chúng cho qui trình tiếp. (Lưu ý: Qui trình này không yêu cầu nhiều nỗ lực nếu các qui trình trước đó được thực hiện đúng. Viết mã thường chỉ là thực hiện của thiết kế chi tiết. Nếu thiết kế được làm tốt, dự án không bao giờ có vấn đề với viết mã.)
Qui trình tích hợp & kiểm thử: Trong qui trình này, tổ dự án làm hợp thức và thẩm tra rằng phần mềm đáp ứng yêu cầu và làm việc như mong đợi. Vì các mô đun đã được phát triển tách biệt, kiểm thử là rất quan trọng để chắc rằng chúng tất cả đều cùng làm việc với nhau như đã lập kế hoạch. Ngay cả với thiết kế tốt, sự không tương hợp giữa các mô đun có thể xảy ra và chúng cần được nhận diện và sửa để làm đầy đủ việc tích hợp khi mọi mô đun riêng được tổ hợp để tạo nên sản phẩm phần mềm tích hợp. Có một số kiểm thử phải được thực hiện như kiểm thử chức năng, kiểm thử hệ thống, kiểm thử tích hợp, kiểm thử hiệu năng, kiểm thử an ninh v.v. (Lưu ý: Với dự án nhỏ, tổ dự án tiến hành tất cả những kiểm thử này. Với dự án lớn hơn, thường có tổ kiểm thử độc lập sẽ tiến hành các kiểm thử này. Mọi kiểm thử đều phải được lập kế hoạch, tổ chức và các trường hợp kiểm thử phải được kiểm điểm và chấp thuận trước khi việc kiểm thử có thể được thực hiện.)
Sau khi tất cả kiểm thử được hoàn tất thành công tổ dự án chuyển giao phần mềm cho khách hàng. Thường khách hàng sẽ tiến hành kiểm thử chấp nhận trên phần mềm để xác định liệu nó có đáp ứng đặc tả yêu cầu hay không, điều cả hai bên đã đồng khi trong qui trình yêu cầu. Nếu phần mềm được chấp nhận, nó được cài đặt và dùng bởi khách hàng.
Qui trình bảo trì: Phần lớn các sản phẩm phần mềm là không tĩnh tại mà sẽ thay đổi. Trong bảo trì, tổ dự án tiếp tục cung cấp hỗ trợ bằng việc sửa lỗi (nếu có), thêm chức năng mới, thay đổi phần mềm được dùng cho nền mới, hay thích nghi phần mềm với công nghệ mới. Mặc dầu nhiều sinh viên tin rằng dự án hoàn thành chuyển giao cho khách hàng, công việc tổ đáng phải xong, nhưng trong thực tế, mọi sản phẩm phần mềm đều tiến hoá qua thời gian để đáp ứng nhu cầu thay đổi của khách hàng. Bảo trì có lẽ là qui trình lâu nhất trong vòng đời phát triển phần mềm, nó có thể kéo dài vài năm sau khi phần mềm được chuyển giao cho khách hàng.
Nếu bạn hiểu qui trình phát triển phần mềm này, bạn có thể áp dụng nó cho bất kì mô hình nào như thác đổi, gia tăng hay xoáy ốc tuỳ theo kiểu dự án bạn đang dùng.
—-English version—-
Software process
A common mistake among students about software is that software development is just programming. When they think of programming, they think of language such as C, C++, Java etc. and as long as they can code in those languages, they can do software. In fact, programming is only a small part of the software development process. There are many things that must be done before programming can take place.
The process of software development consists of many steps. The sum of all steps is called the software development life cycle. There are several software life cycle models such as the waterfall model, the spiral model, the incremental release model etc. However, all of them consists of five basic processes that make up the software life cycle: Requirements, Design, Implement, (Code), , Integration & Test, and Maintenance.
Requirements process: Typically, project team receives a requirements specification from customer. The team reviews, analyzes these requirements then meet with customers to discuss and validate these requirements. Project manager and some key members must use certain techniques to assess the “real needs” of customers. It is a common mistake among students that requirements specification is good enough to start the project so they do not learn to analyze and verify these requirements. In fact, most requirements specification are not well- written by customers. Most have many conflicting or missing requirements and do not represent “the real needs” of customers. Many requirements are only “Wishes” not “Needs” and some even have imposed solutions for developers. That is why the project team must analyze, review and validate them with customers before the project can start. If the requirements process is not done properly, the final software may not be useful to customers or meet their needs.
The requirements specification written by customer usually reflects the view of users. The project team must analyze and understand users’ need, how it will be used, and transforms them into the developers’ view where they can implement. If the requirements are not well defined as customer may not know what they really want. The project team may have to use technique such as rapid prototyping in which a simple “prototype” is built that mimic the functionality of the desired final software. By using this “prototype” as a demonstration to customer, the project team can discuss with customers in details to understand how the final product will be used and determine the “real requirements”. The requirements process is completed when the software requirements specification is completely transformed into the developers’ view so the project team can move to the next phase. (Note: The more efforts that project team puts in this process, the less likely requirements will change and the chance the software project will achieve customers’ satisfaction is high.)
Design process: In this process, the project team decides “How” they will build the software product so that it meets the approved requirements specifications. Usually the design process goes through several steps from high level (Architecture) to lower levels (Detailed design). At the architecture level, requirements are organized into different types or views. A view is a representation of a set of system components and relationships among them. This is where the hardware components, software components and interface components are identified and organize on how they will be implemented. This process is called “stepwise refinement” (Step by step) as it allows the project team to manage the complexity of software. Starting at the high level at component layers, project team can decompose the function into more detailed specific tasks at the programming language statement. When the design is complete, it is recorded in the design specification document. (Note: The more efforts the project team put in this process, the higher quality and better structure the final product will become. Certain quality attributes such as performance, scalability, maintainability etc are identified during the design process)
Implementation process (Coding): During this process, the project team begin to write code of the software based on the design components. The software is divided into separate units called modules in order to handle the complexity of the programming process. The teams must implement these modules according to a coding standard and procedures. Team members are also responsible for proper documentation describing their code and for testing the code to insure correctness.
Team members must test their own works to make sure they work well (Unit test) before handing them to the next process.
(Note: This process is not required a lot of efforts if the previous processes are done properly. Coding is usually just an implementation of the detailed design. If the design is well done, project should never have problem with coding)
Integration & Test process: During this process, project team validate and verify that the software meets the requirements and work as expected. Since the modules were developed separately, testing is very important to make sure that they all work together as planned. Even with a good design, incompatibilities between modules may happen and they need to be identified and corrected to complete the integration as all individual modules are combined to form the integrated software product. There are number of tests that must be executed such as Function test, System test, Integration test, Performance test, Security test etc. (Note: For small project, the project team conducts all these tests. For larger project, there is often an independent test team will conduct these tests. All tests must be planned, organized and test cases must be reviewed and approved before testing can be done)
After all tests completed successfully, the project team deliver the software to the customers. Usually the customers will conduct acceptance testing on the software to determine whether or not it meets the requirements specifications that both sides agreed upon in the requirements process. If the software is accepted, it is installed and used by the customers.
Maintenance process: Most software products are not static but will change. During maintenance, the project team continues to provide support by fixing defects (If any), add new functionality, change the software to be used in new platforms, or adapt the software to new technologies. Although many students believe that when the project complete and deliver to customers, the team work should be done. In reality, all software products evolve over time to meet the changing needs of the clients. Maintenance is probably the longest process in the development life cycle, it may last several years after the software is delivered to customers.
If you understand this software development process, you can apply it to any model such as waterfall, incremental or spiral depend on the type of project that you are using.