Qt Tkptpm 011

QUY TRÌNH THIẾT KẾ, PHÁT TRIỂN PHẦN MỀM

Mã số : QT-TK,PTPM

Lần ban hành :

Ngày hiệu lực :

1. MỤC ĐÍCH1. MỤC ĐÍCH

Tài liệu này được xây dựng để hướng dẫn cụ thể cho công đoạn thiết kế, lập trình trong quá

trình phát triển hoặc triển khai phần mềm:

- Đảm bảo chất lượng và tiêu chuẩn của phần mềm thỏa mãn các yêu cầu được đề ra

trong tài liệu đặc tả yêu cầu.

- Cho phép hiểu được kiến trúc và hình dung được về phần mềm sẽ xây dựng.

- Cho phép thay đổi và kiểm soát được khi có yêu cầu thay đổi.

- Phù hợp với môi trường, các công cụ và phương pháp phát triển được lựa chọn

2. PHẠM VI ÁP DỤNG2. PHẠM VI ÁP DỤNG

Quy trình được áp dụng cho các công việc thiết kế, lập trình, kiểm thử trong các dự án của

LMT và bất kỳ một hoạt động thiết kế, lập trình, nâng cấp phần mềm nào liên quan đến sản

phẩm phần mềm của LMT đã được chính thức đưa ra thị trường.

3. DANH MỤC CÁC3. DANH MỤC CÁC ĐỊNH NGHĨA VÀ TỪ VIẾT TẮT

TT Nội dung

1 QTDA Quản trị dự án

2 TNTK Trưởng nhóm thiết kế

3 TNLT Trưởng nhóm lập trình

4 CBTK Cán bộ thiết kế

5 LTV Lập trình viên

4. NỘI DUNG QUY TRÌNH

4.1. Sơ đồ Quy trình thiết kế, lập trình phần mềm:

4.1.1. Quy trình thiết kế phần mềm

QT-TKPTPM-01 1/4



Lần ban hành :


4.1.2. Quy trình phát triển phần mềm

QT-TKPTPM-01 2/9



Lần ban hành :


4.2 Mô tả quy trình

4.2.1. Quy trình thiết kế phần mềm

4.2.1.1. Lập kế hoạch thiết kế

- Nghiên cứu các yêu cầu chức năng, yêu cầu phi chức năng, làm rõ các yêu cầu chưa rõ

ràng (nếu cần)

- TNTK xác định các công cụ, phương pháp áp dụng cho quá trình thiết kế (ví dụ phương

pháp hướng đối tượng, công cụ vẽ sơ đồ, ..)

- TNTK xác định các tiêu chuẩn sản phẩm áp dụng cho phần mềm cần thiết kế (từ mức cao

như nền tảng-platform đến chi tiết như hệ quản trị CSDL,..)

- TNTK xác định các tiêu chuẩn, công cụ, yêu cầu về đào tạo và biểu mẫu được áp dụng

cho quá trình thiết kế

- TNTK lập kế hoạch thiết kế: bao gồm phạm vi, mục tiêu, giai đoạn, điểm mốc và các kết

quả. Xác định thời gian thực hiện và nhân sự tham gia.

- QTDA phê duyệt kế hoạch thiết kế.

- TNTK tiến hành đào tạo phương pháp, kỹ năng, công cụ cho các cán bộ tham gia thiết kế.

(nếu cần)

4.2.1.2. Thiết kế tổng thể

- CBTK phân tích các yêu cầu nghiệp vụ và tài liệu đặc tả yêu cầu phần mềm, các tài liệu

khác (nếu cần).

- CBTK nhận biết và xác định các phương án thiết kế/giải pháp tổng thể và các điểm mấu

chốt của kiến trúc hệ thống như mô hình logic, mô hình dữ liệu, mô hình hoạt động, mô

hình triển khai, cấu trúc chương trình...Đưa ra mô hình phần mềm. Có thể đưa ra nhiều

hơn 1 phương án để thảo luận, lựa chọn và xây dựng chương trình mẫu – prototype (nếu

cần)

- Xem quy trình phân tích và ra quyết định để lựa chọn các giải pháp thiết kế và điều kiện

để lựa chọn. Nó có thể giúp cán bộ thiết kế lựa chọn được mô hình và giải pháp kiến trúc

tốt nhất được yêu cầu cho dự án.

- Trường hợp một hoặc nhiều chức năng chưa xác định rõ yêu cầu để phân tích, hoặc đã

phân tích nhưng bị sai quy trình, CBTK sẽ gửi lại yêu cầu để TNTK, CBTK cùng phối

hợp và chỉnh sửa (xem mục 4.2.1.3)

- Trường hợp các chức năng sau phân tích đã xác định, TNTK và nhóm thiết kế xây dựng

tài liệu thiết kế tổng thể đồng thời tiến hành tiếp tục phân tích để thiết kế chi tiết: màn

hình, chức năng, các yêu cầu phi chức năng… (xem mục 4.2.1.4)

4.2.1.3. Chỉnh sửa

QT-TKPTPM-01 3/9



Lần ban hành :


- TNTK chuẩn bị các tài liệu cần xem xét, thông báo cũng như các tài liệu về chức năng,

hoặc các vấn đề cần chỉnh sửa:

o Tài liệu thiết kế tổng thể

o Checklist các vấn đề thiết kế

o Báo cáo cần chỉnh sửa

- QTDA, QA, TNLT, TNTK, CBTK tổ chức họp xem xét thiết kế tổng thể, đánh giá chất

lượng, kiểm tra sự đáp ứng của tài liệu với thiết kế tổng thể, các chuẩn thiết kế, phù hợp

với quá trình lập trình và trao đổi đưa ý kiến bàn bạc về chức năng cần chỉnh sửa.

- QTDA, Các trưởng nhóm, QA, khách hàng (nếu cần) xem xét thiết kế kiến trúc, kiểm tra

sự đáp ứng của tài liệu thiết kế tổng thể đối với các yêu cầu mức cao của phần mềm.

(phải có biên bản họp, để chốt phương án thiết kế)

- CBTK thực hiện chỉnh sửa thiết kế chi tiết. (nếu cần)

- TNTK kiểm tra lại các kết quả chỉnh sửa thiết kế và yêu cầu thực hiên lại nếu cần.

- QTDA, khách hàng (nếu cần) phê duyệt kiến trúc phần mềm, TNTK, CBTK tiếp tục xây

dựng thiết kế chi tiết (xem mục 4.2.1.4)

4.2.1.4. Thiết kế chi tiết

- CBTK nghiên cứu kiến trúc hệ thống, thử nghiệm các công cụ thiết kế chi tiết (nếu cần)

- CBTK xây dựng thiết kế chi tiết cho dữ liệu. (Database Design)

- CBTK xây dựng thiết kế chi tiết cho màn hình & luồng tương tác màn hình. (Srceen

Design)

- CBTK xây dựng thiết kế chi tiết cho các thành phần của hệ thống. (Component hoặc

Class Design)

- CBTK xây dựng các giải thuật và thuật toán (ví dụ thuật toán, câu truy vấn SQL, ...) đối

với các thành phần quan trọng, khó về kỹ thuật.

- CBTK xây dựng chương trình mẫu (prototype) để chứng minh sự đáp ứng thiết kế tổng

thể hoặc đáp ứng các yêu cầu khó (nếu cần)

- Nhóm degisn dựa vào các prototype do CBTK xây dựng để thiết kế màn hình và cắt giao

diện hoàn chỉnh cho đội code ghép.

4.2.1.5. Tổng hợp kết quả

- TNTK tập hợp các tài liệu thiết kế, các kết quả xem xét vào hồ sơ thiết kế

- TNTK thu thập các số liệu và chỉ tiêu của quá trình thiết kế, liên quan tới khối lượng, lỗi

phát hiện từ hoạt động xem xét thiết kế.

- Số lượng class được thiết kế, mức độ phức tạp

- Số lượng lỗi phát hiện trong quá trình thiết kế

QT-TKPTPM-01 4/9



Lần ban hành :


- QTDA phê duyệt các kết quả thiết kế trước khi bàn giao tới khách hàng (nếu cần)

- QTDA bàn giao các tài liệu thiết kế tới các nhóm liên quan: kiểm tra phần mềm, lập

trình, quản lý cấu hình, khách hàng (nếu cần)

- CBTK lập báo cáo kết quả thiết kế và các công việc tiếp theo (có báo cáo)

- CBTK thực hiện duy trì và cập nhật thiết kế tổng thể và chi tiết trong trường hợp cần thay

đổi thiết kế.

4.2.2. Quy trình phát triển phần mềm

4.2.2.1. Lập kế hoạch lập trình

- Lập trình viên nghiên cứu các tài liệu thiết kế: tổng thể, chi tiết

- TNLT xác định nguồn lực và điều kiện để thực hiện lập trình, unit-test & integration test

(nếu cần). Cách thức phối hợp giữa các nhóm hoặc cá nhân liên quan (kiểm tra, quản lý

cấu hình, SQA).

- TNLT lập kế hoạch lập trình bao gồm: mục tiêu, phạm vi, các kết quả cần ban giao &

điều kiện nghiệm thu, thời gian thực hiện & phân công trách nhiệm cho các thành viên,

các yêu cầu về đào tạo (có bản Kế hoạch)

- TNLT xác định hoặc xây dựng tiêu chuẩn lập trình được sử dụng trong quá trình lập

trình.

- Quản trị dự án xem xét và phê duyệt kế hoạch lập trình.

- TNLT thực hiện đào tạo về phương pháp, các thức làm việc, các tiêu chuẩn lập trình, kỹ

năng, các mô hình lập trình mẫu được sử dụng trong tài liệu thiết kế v.v…đối với các

thành viên trong nhóm. (nếu cần)

- TNLT lập kế hoạch chốt thời gian chuyển module/chức năng cho đội QA để tiến hành

kiểm thử.

4.2.2.2. Coding, review code

- Trưởng nhóm lập trình xây dựng thiết kế chi tiết cho module, component (nếu cần)

- Nhóm degisn chuyển bản giao diện đã được phê duyệt để nhóm code tiến hành ghép vào

hệ thống.

- Lập trình viên thực hiện lập trình các module được giao, và tuân theo đúng thời gian đã

được xác định trong bản kế hoạch do TNLT lập và đã được QTDA phê duyệt.

- Lập trình viên tuân theo chuẩn lập trình (xem phụ lục mã nguồn trong tài liệu này)

- TNLT tổ chức và phân công thực hiện code review giữa các thành viên lập trình (dựa vào

checklist xem xét mã nguồn). Có thể thực hiện review chéo giữa các thành viên nhóm lập

trình.

QT-TKPTPM-01 5/9



Lần ban hành :


- TNLT tổ chức họp xem xét mã nguồn đối với các module có thuật toán khó có mức độ

ảnh hưởng lớn tới toàn bộ hệ thống (nếu cần). (Biên bản họp)

- Lập trình viên báo cáo kết quả công việc. (Báo cáo công việc)

- Lập trình viên chuyển giao các kết quả lập trình cho TNLT.

4.2.2.3. Unit test

- Lập trình viên thực hiện unit-test. (Unit Test Case) sau khi hoàn thiện từng chức năng.

- Nếu phát hiện lỗi, LTV sẽ chỉnh sửa lại lỗi (xem mục 4.2.2.4)

- Trường hợp hết lỗi, LTV sẽ chuyển module để tester tiến hành kiểm thử hệ thống (xem

mục 4.2.2.5)

4.2.2.4. Chỉnh sửa

- Lập trình viên thực hiện chỉnh sửa và hoàn thiện các module và chương trình phần mềm

khi có lỗi phát sinh.

- Trường hợp tester phát hiện lỗi từ các giai đoạn kiểm thử module, tích hợp hệ thống…

hoặc nhận lỗi từ phía Khách hàng, LTV sẽ tiếp nhận và chỉnh sửa lỗi cho phù hợp yêu

cầu.

- LTV sau khi chỉnh sửa sẽ tiến hành kiểm tra, thực hiện unit test (xem mục 4.2.2.3)

4.2.2.5. Tích hợp các module

- Nhóm QA tiến hành kiểm thử các chức năng sau khi nhóm LTV hoàn thiện hoặc chỉnh

sửa gửi lại.

o Nếu có lỗi mới hoặc lỗi phát sinh sau quá trình chỉnh sửa, tester sẽ gửi lại cho

nhóm LTV để tiếp tục chỉnh sửa (xem mục 4.2.2.4)

o Nếu hết lỗi hoặc lỗi không ảnh hưởng quá nhiều đến hệ thống, tester ghi lại vào

báo cáo test hoặc báo lại với TNLT, Trưởng nhóm test, để kiểm tra, chuẩn bị tích

hợp các module.

- Mỗi phiên bản bàn giao cho nhóm test đều phải kèm theo danh mục những chức năng

hay modules đã sẵn sàng cho việc test

- TNLT kiểm tra kết quả kiểm thử các module được bàn giao trước khi chuyển module cho

việc tích hợp hệ thống.

- TNLT lập kế hoạch tích hợp bao gồm: phương thức, thời gian, thứ tự tích hợp (nếu cần)

- TNLT hoặc Lập trình viên có kinh nghiệm được chỉ định thực hiện việc tích hợp hệ

thống (ghép nối các modules).

- Sau khi các module được tích hợp, nhóm QA, nhóm thiết kế css sẽ tiến hành kiểm thử

toàn hệ thống: các chức năng, giao diện,…

QT-TKPTPM-01 6/9



Lần ban hành :


o Nếu có lỗi mới hoặc lỗi phát sinh sau quá trình chỉnh sửa, tester sẽ gửi lại cho

nhóm LTV để tiếp tục chỉnh sửa (xem mục 4.2.2.4)

o Nếu hết lỗi hoặc lỗi không ảnh hưởng quá nhiều đến hệ thống, tester ghi lại vào

báo cáo test hoặc báo lại với TNLT, Trưởng nhóm test, để kiểm tra, chuẩn bị kế

hoạch triển khai, chạy thử nghiệm hệ thống (xem mục 4.2.2.6)

4.2.2.6. Ban hành, chạy thử nghiệm

- TNLT lập tài liệu hướng dẫn cài đặt và xây dựng công cụ cài đặt (nếu cần)

- TNLT, tester tổ chức việc viết tài liệu hướng dẫn sử dụng hoặc chỉnh sửa tài liệu đã có

(nếu là sản phẩm nâng cấp) (Tài liệu hướng dẫn sử dụng)

- TNLT lập thông báo phát hành sản phẩm phần mềm (Thông báo ban hành)

- TNLT chuyển giao phiên bản thử nghiệm cho nhóm test để phối hợp thực hiện hỗ trợ,

kiểm tra hệ thống cùng khách hàng.

- QTDA & QA xem xét và phê duyệt ban hành chính thức gói sản phẩm phần mềm.

- TNLT lưu trữ các kết quả của quá trình lập trình (chương trình phần mềm, mã nguồn và

các tài liệu kèm theo) cho các nhóm.

5. HỒ SƠ5. HỒ SƠ

Hồ sơ thiết kế chứa các tài liệu liên quan đến thiết kế, xây dựng phần mềm, bao gồm tài liệu

kiến trúc tổng thể, tài liệu thiết kế mức cao, các thiết kế chi tiết (nếu có) và các tài liệu, mã

nguồn liên quan (nếu có):

o Tài liệu thiết kế tổng thể

o Tài liệu thiết kế mức cao

o Tài liệu xem xét thiết kế

o Tài liệu phụ trợ, mã nguồn, chương trình thử nghiệm, sản phẩm mua ngoài,.. nếu có.

o Các tiêu chuẩn, phương pháp, công cụ cho quá trình thiết kế

o Tiêu chuẩn lập trình

o Biên bản xem xét mã nguồn.

o Mã nguồn, unit-test.

o Gói phần mềm.

o Thông báo phát hành gói phần mềm

Các hồ sơ tài liệu trên được lưu trữ tại phòng QA trong thời gian tối thiểu là 5 năm

QT-TKPTPM-01 7/9



Lần ban hành :


Phụ lục xem xét mã nguồn

Mã nguồn

- Mã nguồn có tuân thủ chuẩn viết code áp dụng cho ngôn ngữ này không?

- Có khả năng hiểu được mã nguồn khi đọc nó không?

- Các phương thức/hàm (method) có được đặt tên rõ nghĩa nhằm mô tả phương thức đó

làm gì không?

- Tên các tham số có ý nghĩa không?

- Có sự phân biệt rõ ràng giữa đường đi qua mỗi phương thức trong trường hợp bình

thường với những đường đi ngoại lệ khác (vd: bắt lỗi)?

- Mã nguồn cho các phương thức có quá dài không (trong khi phương thức đó có thể

tách thành các phương thức riêng nhỏ hơn)?

- Mã nguồn cho các phương thức có quá dài không trong khi phương thức đó có thể

giảm được số điểm quyết định (decision points)?

- (Điểm quyết định là 1 phát biểu (statement) làm thay đổi hướng đi của 1 phương thức,

ví dụ: if-, else-, and-, while-, và case-statements.)

- Các vòng lặp có được tối ưu hóa không?

- Các biến nhớ, hằng số có được đặt tên có nghĩa không?

- Mã nguồn có rõ ràng và dễ hiểu hay không? Có tránh dùng những giải pháp “phức tạp

và khó hiểu” không?

- Có những chú giải nhằm giải thích cho những đoạn mã nguồn (code paragraphs) liên

tục không?

- Mỗi khi những đoạn mã nguồn được thay đổi (update), thì có chú giải về sự thay đổi

đó hay không?

- Những đoạn mã nguồn phức tạp, dễ gây hiểu lầm có được giải thích rõ bằng chú giải

hay không?

- Đối với những đoạn mã nguồn có cấu trúc được thể hiện trên nhiều dòng thì có được

viết theo lối có cấu trúc hay không? (mức thụt dòng có hợp lý và đúng không?)

- Một dòng lệnh có chứa hơn nhiều 1 lệnh trên 1 dòng hay không?

- Có sử dụng ngắt dòng (break line) đối với dòng lệnh quá dài hay không?

- Những dòng lệnh có liên quan đến những dòng lệnh trước có đánh mức lùi dòng ở

mức con (mức kế tiếp) hay không?

- Những tên biến có khác với tên đối tượng khác không?

QT-TKPTPM-01 1/4



Lần ban hành :


- Các phương thức được đặt tên theo đúng cách thông thường hay không? (ví dụ: tiền tố

nhằm phân biệt local functions và global functions)

- Tên của các hàm, thủ tục tổng thể (global functions) có khác với các hàm, thủ tục cục

bộ (local functions)

- Tên hàm, thủ tục có ý nghĩa hay không

- Tên các đối tượng (controls, objects,…) có ý nghĩa và có tuân theo chuẩn chung của

công cụ phát triển hay không?

- Tên các thư mục và các thư viện đã được xác định trong bản thiết kế mức cao, thiết kế

chi tiết có thống nhất trong quá trình thực hiện (coding) hay không?

- Tên và kiểu các thư mục có tuân theo đúng nội dung và chuẩn của công cụ phát triển

hay không?

Chú giải

- Chú giải có được cập nhật khi thay đổi mã nguồn không?

- Tất cả các chú giải có rõ ràng và chính xác?

- Các chú giải có tập chung vào việc giải thích tại sao (why), (mà không phải giải thích

là làm như thế nào (not how))?

- Các trường hợp đặc biệt, các tình huống bất ngờ, các lỗi liên quan có thể xảy ra có

được chú thích hết không?

- Mục đích của một quá trình có được chú thích không? (thông thường là block

comment)

- Các sự kiện có liên quan đến mỗi quá trình có được chú giải không?

QT-TKPTPM-01 9/9

Documents

Qt Tkptpm 011