Nhiều sinh viên được đào tạo tốt trong viết mã vì đa số thời gian của họ ở đại học tập trung vào viết mã nhưng ít tập trung vào qui trình phát triển phần mềm.

Một số sinh viên coi phát triển phần mềm là công việc cá nhân vì họ thường nhận được phân công cá nhân điều mỗi người phải làm và phần lớn nhiệm vụ được phân là về viết mã. Khi họ đi làm nhiều người có xu hướng bắt đầu viết mã ngay lập tức sau khi nhận được phân công mà không hiểu đầy đủ vấn đề. Vì yêu cầu thường xuyên thay đổi và họ phải sửa mã của mình, họ thường phạm sai lầm cần sửa. Chúng càng được sửa, mã của họ càng trở nên phức tạp hơn. Cuối cùng, sẽ quá khó không thể hiểu nổi cấu trúc mã của họ và logic của họ cho kiểm thử hay bảo trì. Nếu người phát triển chỉ viết mã và sửa bất kì cái gì họ muốn thì sẽ khó mà tích hợp mã của họ vào một sản phẩm phần mềm cố kết.

Khi sinh viên được đào tạo về qui trình phát triển phần mềm, họ hiểu rằng phát triển không chỉ là viết mã mà nó là nỗ lực tổ. Trước khi bắt đầu, tổ phải có hiểu biết chung về vấn đề mà họ phải giải quyết, mục đích dự án, hoạt động dự án nơi từng thành viên tổ có vai trò và trách nhiệm nào đó cho công việc. Qui trình phần mềm là bản lộ trình chỉ ra cho tổ cách phát triển phần mềm từ mức cao tới mức chi tiết. Có một trật tự trình tự được gọi là vòng đời phát triển nơi toàn thể qui trình được phân chia thành vài pha và từng pha có vai trò, trách nhiệm nào đó cho các thành viên tổ.

Qui trình phần mềm bắt đầu bằng việc hiểu vấn đề qua việc thẩm tra các yêu cầu với khách hàng. Bởi vì khách hàng thường không mô tả nhu cầu của họ rõ ràng và thường đổi ý của họ, tổ phải chắc điều khách hàng đã đòi hỏi là điều họ cần. Chỉ khi các yêu cầu này được thảo luận và xác nhận, tổ mới bắt đầu làm tài liệu chúng thành đặc tả yêu cầu phần mềm. Bằng việc tuân theo qui trình, tổ hiểu rằng nguyên nhân thông thường nhất của thất bại dự án là các yêu cầu không ổn định hay xác định kém và bằng việc có các yêu cầu được kiểm nghiệm đầy đủ họ có thể giảm bớt rủi ro của yêu cầu thay đổi. Sau khi khách hàng đã chấp nhận tài liệu yêu cầu, tổ bắt đầu thảo luận riêng của họ để chắc rằng mọi thành viên của tổ hiểu vấn đề đủ rõ trước khi họ chia dự án thành những nhiệm vụ nhỏ hơn mà họ phải làm.

Bằng việc tuân theo qui trình phần mềm, tổ xác định kiến trúc của hệ thống qua nhiều cấu phần. Các thành viên tổ nhận diện giao diện giữa các cấu phần này và thế rồi thẩm tra rằng mọi cấu phần có thể được dõi vết trở lại các yêu cầu để cho sản phẩm sẽ đáp ứng nhu cầu của khách hàng. Điều này là quan trọng bởi vì bất kì lỗi nào trong kiến trúc cũng có thể tạo ra vấn đề trong việc tích hợp phần mềm trong pha sau. Khi dự án tiến từ pha yêu cầu sang pha kiến trúc, tổ sẽ khám phá ra rằng có nhiều “yêu cầu suy dẫn” mà cần được thực hiện. Thỉnh thoảng danh sách các yêu cầu suy diễn còn nhiều hơn các yêu cầu nguyên gốc vì kiến trúc sư phải xem xét mọi thứ như hiệu năng, tính đổi qui mô, tính dùng được, và tính bảo trì mà khách hàng mong đợi nhưng không đòi hỏi. Dựa trên kiến trúc, tổ chọn công cụ phần mềm mà họ sẽ dùng để xây dựng hệ thống. Đồng thời, các thành viên tổ có thể bắt đầu tạo ra tập các kiểm thử đơn vị để được áp dụng một khi họ kết thúc viết mã. Nhiều người phát triển không nghĩ về kiểm thử mãi cho tới khi họ kết thúc viết mã nhưng nếu họ bắt đầu phát triển kiểm thử đơn vị sớm trong pha kiến trúc, họ có thể tránh được nhiều sai lầm mà thường xảy ra trong pha thiết kế. Bằng cách làm việc trên kiểm thử đơn vị sớm, họ hiểu các yêu cầu tốt hơn, điều giúp cho họ thiết kế sản phẩm tốt hơn.

Pha thiết kế là nơi logic nội bộ của từng cấu phần được tổ chức. Trong pha này, các thành viên tổ làm việc trên chi tiết về cấu trúc dữ liệu và thuật toán của từng cấu phần. Trong pha kiến trúc, hội tụ chính là vào nhận diện các cấu phần và mối quan hệ của những cấu phần này và cách chúng tương tác lẫn nhau. Trong pha thiết kế, hội tụ là vào thiết kế logic cho từng cấu phần trong những cấu phần này. Các thành viên tổ tuân theo qui trình và dùng tập các kĩ thuật và hướng dẫn như phân hoạch vấn đề và trừu tượng hoá. Việc dùng trừu tượng hoá cho phép các thành viên tổ hội tụ vào một nhiệm vụ mỗi lúc, không lo nghĩ về chi tiết của các nhiệm vụ khác. Khi mọi nhiệm vụ đều được thực hiện, tổ phải tuân theo qui trình trắc nghiệm bằng việc có cuộc kiểm điểm thiết kế của từng cấu phần. Một cách điển hình, người quản lí dự án, kiến trúc sư hệ thống, và đảm bảo chất lượng phải tham gia vào kiểm điểm để chắc rằng mọi việc đều được thực hiện tương ứng theo kế hoạch, kiến trúc hệ thống tổng thể, và trong tuân thủ theo qui trình chuẩn.

Khi thiết kế được thẩm tra đầy đủ và chấp thuận, các thành viên tổ có thể bắt đầu pha thực hiện (viết mã). Nhiều người thích viết mã ngay nhưng nếu họ tuân theo qui trình, họ phải chọn cấu trúc dữ liệu đáp ứng nhu cầu của thiết kế; giữ cho cấu trúc logic đơn giản nhất có thể được; lựa chọn các tên biến có nghĩa nhất quán với chuẩn. Bằng việc lựa cấu trúc dữ liệu trước, rồi bắt đầu với tổ chức logic của cấu trúc mã họ có thể tránh được nhiều sai lầm thường xảy ra trong pha này. Sau khi hoàn thành việc viết mã đầu tiên, thành viên tổ phải tiến hành buổi thảo duyệt để kiểm điểm mã của họ để chắc chúng tuân thoe chuẩn viết mã và cấu trúc của chúng là nhất quán với cách dự án được tổ chức và được lập kế hoạch. Từng thành viên tổ phải thực hiện kiểm thử đơn vị và sửa các lỗi đã được tìm ra trước khi chuyển sang pha tiếp.

Trong pha kiểm thử, các thành viên tổ chuyển mã của họ cho tổ kiểm thử. Kiểm thử là quá trình thực hiện một chương trình với ý định tìm ra lỗi. Kiểm thử tốt là kiểm thử có xác suất cao tìm ra lỗi. Bằng việc tuân theo qui trình, thành viên tổ hiểu rằng kiểm thử nên được lập kế hoạch sớm trong pha thiết kế và mọi kiểm thử đều phải dõi vết được về yêu cầu của khách hàng. Việc kiểm thử phải bắt đầu trong phần nhỏ nhất và tiến tới kiểm thử phần lớn hơn và cuối cùng tới toàn thể sản phẩm phần mềm. (Kiểm thử đơn vị, kiểm thử chức năng, kiểm thử tích hợp, kiểm thử hệ thống v.v.)

—-English version—-

Software development process

Many students are well trained in coding because a majority of their time in university is focusing on coding but little on software development process. Some students consider software development is an individual work as they often receive individual assignments that each must do and most assignments are about writing code. When they go to work, many have a tendency to start coding immediately after receive an assignment without fully understand the problem. As requirements often change and they have to modify their code, they often make mistakes that need fixing. The more they are fixed, the more complex their code becomes. Eventually, it will be too difficult to understand the structure of their code and their logic for testing or maintaining. If developers just code and fix and do whatever they want then it would be difficult to integrate their codes into a cohesive software product.

When students are trained on software development process, they understand that development is not just writing code and it is a team effort. Before starting, the team must have common understanding of the problems that they must solve, the project goals, the project activities where each team member has certain roles and responsibilities for the work. The software process is a roadmap that shows the team how to develop software from the high level to the detail level. There is a sequence order called the development life cycle where the entire process is dividing into several phases and each has certain roles, responsibilities for team members.

The software process starts with the understanding of the problem by verify the requirements with customers. Because customers often do not describe their needs clearly and often change their minds, the team must make sure what customers have asked for is what they needs. Only when these requirements are discussed and confirmed, the team begins to document them into the software requirements specification. By following the process, the team understands that the most common cause of project failure is unstable or poorly defined requirements and by having the requirements fully validated they can reduce the risk of changing requirements. After having customers approved the requirements document, the team starts their own discussion to make sure that every team member understands the problem well enough before they divide the project into smaller tasks that they must do.

By following the software process, the team defines the architect of the system with several components. Team members identify the interfaces between these components and then verify that all components can be traced back to the requirements so that the product will meet customer’s needs. This is important because any error in architecture can create issues during software integration in later phase. When a project moves from requirements phase to architecture phase, the team will discover that there are many “Derived requirements” that need to be done. Sometime the list of derived requirements is much more than the original requirements because an architect must consider things such as performance, scalability, usability, and maintainability that customers expect but do not ask for. Based on the architecture, the team selects software tools that they will use to build the system. At the same time, team members can begin to create a set of unit tests to be applied once they finish their code. Many developers do not think about testing until they finish coding but if they start to develop unit tests early during architecture phase, they can avoid many mistakes that often happen during design phase. By working on unit tests early, they understand the requirements better that help them to design the product better.

Design phase is where the internal logic of each component is organized. During this phase, team members work on the details of the data structures and the algorithmic of each component. In architect phase, the main focus is on identifying the components and the relationship of these components and how they interact with each others. During the design phase, the focus is on designing the logic for each of the components. Team members follow a process and using a set of techniques and guidelines such as problem partitioning and abstraction. The use of abstraction allows team members to focus one task at a time, without worrying about the details of other tasks. When all tasks are done, the team should follow a verification process by having a review of the design of each component. Typically, the project manager, the system architect, and the quality assurance must participate in the review to make sure that all works are done according to the plan, the overall system architect, and in compliance with the standard process.

When a design is fully verified and approved. Team members can start the implementation phase (Coding). Many people like to write code right away but if they follow the process, they must select data structure that meets the needs of the design; keep the logic structure as simple as possible; select meaningful variable names consistent with the standards. By select data structure first, then start with a logical organization of the coding structure they can avoid a lot of mistake often happen during this phase. After complete the first coding, team member must conduct a code walkthrough to review their code to make sure they follow the coding standard and their structures are consistent with the way the project is organized and planned. Each team member must perform unit tests and correct uncovered errors before move to the next phase.

In the testing phase, team members transfer their code to the testing team. Testing is the process of executing a program with the intent of finding error. A good test is one that has a high probability of finding error. By following the process, team members understand that tests should be planed early during architecture phase and all tests should be traceable to customer requirements. Testing should start in the smallest part and progress toward testing in the larger part and eventually the entire software product. (Unit test, Function test, Integration test, System test etc.)