Quy trình phát triển phần mềm ở Nhật Bản

danh-sach-top-5-sim-gia-re-o-nhat-ban
Quy-trinh-phat-trien-pham-mem-o-Nhat-Ban
Kỹ sư cầu nối

Quy trình phát triển phần mềm ở Nhật Bản

thong-bao-tokyodayroi Hướng dẫn cách tạo CV tiếng Nhật online xem tại đây.

Sau một thời gian hành tẩu giang hồ (làm Brse chứ không phải chỉ ngày ngày đi đánh nhau không cần làm gì mà vẫn có tiền ăn nhậu như các anh hùng phim tàu đâu nhé ? ) . Mình cũng tìm hiểu được đôi chút kiến thức về quy trình phát triển phần mềm. Nên hôm nay mình sẽ chia sẻ hiểu biết của mình về quy trình phát triển phần mềm tại Nhật Bản để bạn nào chưa biết có thể tham khảo nha.

Quy trình thường sẽ qua 6 bước và các công đoạn chính như sau:

Bước 1: Lập kế hoạch dự án

Để có thể bắt đầu dự án được thì trước hết cần phải có kế hoạch cụ thể để có thể chuẩn bị nhân lực cũng như chi phí. Cụ thể kế hoạch cần chỉ rõ thời gian phát triển dự án (dự kiến ở mức tương đối và có hỏi ý kiến người có chuyên môn hoặc tham khảo các chức năng tương tự) và khi nào bắt đầu đưa chương trình vào sử dụng và vận hành.

Khi kế hoạch được các cấp có thẩm quyền duyệt thì mới có thể tiến tới các bước tiếp theo dưới đây.

Bước 2: Xác định yêu cầu của dự án

■Công đoạn lấy yêu cầu và tạo tài liệu định nghĩa yêu cầu (要件定義 hay 要求定義)

Khi khác hàng muốn làm mới hay maintain các chức năng đã có trong hệ thống, thì sẽ gửi yêu cầu cho bên team IT hoặc các vendor để nhờ làm. Lúc này bên IT sẽ cần người đến để nghe và lấy yêu cầu về chương trình mà khách hàng muốn làm. Người có thể lấy được yêu cầu sẽ thường là người có nhiều năm kinh nghiệm trong việc làm phần mềm để có thể đánh giá yêu cầu về sản phẩm đó có làm được hay không.

Từ các yêu cầu thu thập được từ khách hàng sẽ tổng hợp và viết thành tại liệu định nghĩa yêu cầu.

❖ Đầu vào của công đoạn này ( input) :

- Mô tả yêu cầu của khách hàng, tài liệu liên quan đến chức năng mà khách hàng muốn làm.

❖ Thành phẩm của công đoạn này 「成果物」 (ouput) :

- Tài liệu định nghĩa yêu cầu (要件定義 hay 要求定義)

- Tài liệu mô tả cách để hiện thực được yêu cầu của khách hàng (実現方式書)

Đây là công đoạn thuộc giai đoạn đầu của dự án (上流工程 ) và rất quan trong đối với toàn dự án. Nếu người lấy yêu cầu không hiểu rõ yêu cầu của khách hàng hoặc mô tả không đầy đủ trong tài liệu thì sau này sẽ phải chỉnh sửa nhiều ở các tài liệu basic hay detail.

Bước 3: Thực hiện làm tài liệu thiết kế liên quan

lam-tai-lieu-thiet-ke-it

■Công đoạn làm tài liệu thiết kế cơ sở (外部設計- External Design hay 基本設計 - Basic design )

Dựa vào tài liệu định nghĩa yêu cầu cũng như tài liệu mô tả cách hiện thực được yêu cầu của khách hàng. Ở công đoạn này team phát triển sẽ tiến hành thiết kế các màn hình, viết tài liệu thiết kế basic design và thiết kế bảng để lưu dữ liệu cần thiết.

❖ Thành phẩm của công đoạn này 「成果物」 (ouput) :

- Tài liệu thiết kế cơ bản (Basic Design)

- Tài liệu mô tả cơ sở dữ liệu

- ERD hay ER図 (ERD là một sơ đồ, thể hiện các thực thể có trong database, và mối quan hệ giữa chúng với nhau.)

- Tài liệu mô tả di chuyển màn hình 画面遷移図

■Công đoạn làm tài liệu thiết kế chi tiết (内部設計- Detail Design)

Ở tài liệu BD đã mô tả rõ được các chức năng, giao diện cũng như cơ sở dữ liệu,...làm đầu vào cho công đoạn này. Tiếp đến cần phải làm tài liệu thiết kế chi tiết DD để mô tả các hàm, biến cụ thể, cách lấy dữ liệu dùng trong chương trình. Tài liệu này sẽ thiên về xử lý ngầm phía dưới mà người dùng không nhìn thấy.

Thực tế nếu người viết tài liệu BD mà viết chi tiết chút thì có khi không cần phải viết DD thì cũng có thể code được rồi đó (Nếu dự án không quá khó).

❖ Thành phẩm của công đoạn này 「成果物」 (ouput) :

- Tài liệu thiết kế chi tiết (Detail Design)

- Tài liệu mô tả các hàm xử lý.

Bước 4: Lập trình tạo ứng dụng

■Công đoạn thực hiện code tạo chương trình (プログラミング)

Đây là công đoạn mà chắc các anh em IT đều quen thuộc cả rồi. Đó chính là code ra chương trình theo như thiết kế đã tạo ở các công đoạn trên. Là công đoạn trực tiếp tạo ra sản phẩm, phải OT nhưng thực tế lương lại không cao bằng mấy cái ông làm thiết kế và lấy yêu cầu ở trên. Bất công không nào ? Không hề nhé, để viết được tài liệu như thế cần phải có kiến thức và kinh nghiệm mới có thể làm tốt được, chứ không thiết kế ra mấy cái tào lao để các bác chửi chết à. Bác nào muốn lương cao thì cố gắng tích lũy kinh nghiệm để lên làm thiết kế nha :D

❖ Thành phẩm của công đoạn này 「成果物」 (ouput) :

- Chương trình (phần mềm) chạy như thiết kế.

- Script sql tạo bảng cần sử dụng.

Tuy nhiên sản phẩm chưa được test, nên chúng ta sẽ cần đến công đoạn tiếp theo đây.

Bước 5: Kiểm tra (Test)

cac-loai-test-trong-quy-trinh-phat-trien-phan-mem

■Công đoạn test theo từng chức năng (単体テスト Unit Test)

Sau khi các anh DEV miệt mài OT và tạo ra các chương trình có thể chạy được rồi. Tuy nhiên không biết nó có chạy đúng như yêu cầu hay không thì cần phải trải qua quá trình test của các em tester mặn mòi. UT này chỉ test từng chức năng của chương trình, đảm bảo nó chạy đúng như thiết kế đã mô tả.

Ở đây chỉ test các thao tác đơn như kiểu click vô button thì sẽ hiển thị message ABC gì đó...

❖ Đầu vào của công đoạn này ( input) :

- Chương trình đã code xong

- Tài liệu mô tả các test case, kịch bản test.

❖ Thành phẩm của công đoạn này 「成果物」 (ouput) :

- Kết quả test

- Bằng chứng kết quả test (Evidence)

- Danh sách bug đã phát hiện.

■Công đoạn test tích hợp (結合テスト)

Sau khi đã pass qua quá trình test UT thì tiếp đến là công đoạn test tích hợp các chức năng của chương trình lại với nhau xem chúng có chạy đúng hay không. Lần này sẽ cần đến các kịch bản test dài hơn, nhiều thao tác hơn.

VD: Vào màn hình XX sau đó nhập tên vào rồi nhấn chọn button 「登録」 thì sẽ xảy ra cái gì...

❖ Thành phẩm của công đoạn này 「成果物」 (ouput) :

- Kết quả test.

- Bằng chứng kết quả test (Evidence)

- Danh sách bug đã phát hiện.

■Công đoạn test tích hợp các hệ thống (システムテスト hay 総合テスト)

Ở đây sẽ cần thực hiện test với các hệ thống khác có liên quan đến chức năng đã phát triển. Đảm bảo chương trình hoạt động tốt và không có ảnh hưởng gì đến các hệ thống khác.

VD: Test việc lấy dữ liệu API của hệ thống khác về sau khi nhấn vào button 「データ取得」 và xử lý data đúng như với thiết kế.

❖ Thành phẩm của công đoạn này 「成果物」 (ouput) :

- Kết quả test.

- Bằng chứng kết quả test (Evidence)

- Danh sách bug đã phát hiện.

■Công đoạn test kiểm tra hoạt động phía người dùng (運用テスト)

Sau khi vượt qua được các ải test nghiêm ngặt ở trên, cuối cùng cũng hết bug và xác nhận hoạt động đúng như thiết kế rồi. Lúc này sản phẩm sẽ bàn giao lại cho các bạn bên người dùng. Chính là những người đã đưa ra các yêu cầu, mô tả về chương trình mà đã được làm ra đây.

Các bạn ấy sẽ test lại để đảm bảo chương trình hoạt động đúng như cái mà họ muốn. Nếu không có vấn đề gì thì sẽ pass và được cấp phép đưa deploy lên hệ thống để enduser sử dụng.

Bước 6: Triển khai lên hệ thống và đưa vào sử dụng vận hành

■Công đoạn Deploy lên hệ thống (システム移行 - リリース)

Đây là công đoạn sau khi sản phẩm hoàn thành và được xác nhận không có vấn đề gì, có thể deploy lên hệ thống.

Vào ngày deploy đã định sẵn thì chương trình sẽ được đưa lên serve và chính thức đi vào hoạt động.

Nếu bạn chưa biết quy trình để deploy lên hệ thống ở Nhật như thế nào có thể tham khảo bài viết dưới đây.

THAM KHẢO: Đang cập nhật

■Công đoạn vận hành và bảo trì 運用・保守

Sau khi đã được vào sử dụng chính thức thì sẽ cần phải có team vận hành và hướng dẫn cho khách hàng sử dụng chức năng mới này. Đồng thời nếu có vấn đề phát sinh sẽ báo lại cho bên phát triển để fix.

Phần này sẽ có tài liệu hướng dẫn sử dụng để cho khách hàng có thể tham khảo và sử dụng.

Một số từ viết tắt:

❖ Basic Design ➺ BD

❖ Detail Design ➺ DD

❖ Over Time ➺ OT

Out put của công đoạn trước sẽ là input của công đoạn tiếp theo nên mình không viết lại để tránh lặp đi lặp lại nếu không cần thiết.


Nếu có bất kỳ câu hỏi nào xin hãy để lại bình luận phía dưới hoặc cùng thảo luận trên diễn đàn tokyodayroi.com với bọn mình và mọi người nhé.

Chúc các bạn thành công !


DANH SÁCH BÌNH LUẬN

Chưa có bình luận nào cả. Hãy là người đầu tiên bình luận bài viết này !



Ý KIẾN CỦA BẠN