Mục lục

Chương I : TỔNG QUAN PHẦN MỀM................................................................. 3

Chương II: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM................................ 5

                 Định nghĩa, vòng đời ................................................................................... 5

                 Tiến trình phát triển phần mềm ................................................................... 6

                 Mô hình thác nước ...................................................................................... 6

                 Mô hình làm bản mẫu .................................................................................. 6

                 Mô hình xoắn ốc .......................................................................................... 7

                 Mô hình gia tăng.......................................................................................... 7

                 Mô hình theo thành phần ............................................................................ 8

                 Mô hình ứng dụng nhanh............................................................................. 8

                 Mô hình RUP............................................................................................... 9

                 Mô hình hình thức ....................................................................................... 9

Chương III: PHÂN TÍCH HỆ THỐNG................................................................... 9

                 Phân loại yêu cầu ......................................................................................... 10

                 Đặc tả yêu cầu hệ thống .............................................................................. 10

                 Kỹ thuật xác định phân tích yêu cầu ........................................................... 11

                 Quy trình phân tích...................................................................................... 11

                 Phương pháp cấu trúc.................................................................................. 12

                 Phương pháp OOP ...................................................................................... 13

Chương IV: THIẾT KẾ PHẦN MỀM .................................................................... 17

                 Mô hình kiến trúc phần mềm........................................................................ 17

                 Tiến trình thiết kế giao diện ........................................................................ 17

                 Thiết kế phần mềm UML............................................................................. 22

                 Thiết kế hệ thống thời gian thực.................................................................. 25

Chương V: LẬP TRÌNH VÀ TÍCH HỢP............................................................... 25

Chương VI: BẢO ĐẢM CHẤT LƯỢNG PHẦN MỀM ....................................... 27

                 Độ tin cậy phần mềm................................................................................... 27

                 Rà soát phần mềm........................................................................................ 27

                 Tiêu chuẩn của sản phẩm phần mềm ........................................................... 30

Chương VII: KIỂM THỬ PHẦN MỀM ................................................................. 30

                 Xác minh và  thẩm đinh............................................................................... 30

                 Kiểm thử hộp trắng...................................................................................... 31

                 Kiểm thử hộp đen......................................................................................... 32

                 Kiểm thử từng modul................................................................................... 33

                 Kiểm thử tích hợp........................................................................................ 33

                 Kiểm thử hồi quy......................................................................................... 33

                 Kiểm thử tính năng...................................................................................... 34

                 Kiểm thử theo kịch bản................................................................................ 34

Chương VIII: QUẢN LÝ DỰ ÁN............................................................................ 35

Chương I : TỔNG QUAN PHẦN MỀM

            Khái niệm:PM là một tập hợp cac câu lệnh được viết bằng một hoặc nhiều ngôn ngữ lập trình, nhằm thực hiện một số các chức năng giải quyết một bài toán nào đó. Như là 1 khái niệm đối nghĩa với PC. Lúc đầu cho k hoặc bán kèm theo máy, sau đó bán riền và giá ngày càng cao.

Kỹ sư PM là người biết phát triền PM một cách hệ thống và phải có những kỹ năng cơ bản:Định danh, đánh giá, cài đặt, lựa chọn 1 phương pháp luận và các công cụ thích hợp cho việc phát triển phần mềm ; Biết cách sử dụng các mẫu phần mềm.;Biết cách lựa chọn ngôn ngữ, thiết bị phần cứng;Quản lý cấu hình, lập sơ đồ và kiểm soát việc phát triển các tiến trình.;Đánh giá và quyết định khi nào loại bỏ và nâng cấp các ứng dụng.

Công cụ hỗ trợ PM ( CASE): Là PM khác nhau được xd trên cơ sở những mô hình và phương pháp cụ thể.Cung cấp trợ giúp cho việc tự động hay bán tự động hóa các hoạt động phát triển PM; Có 2 mức: bàn thợ ( thông tin được tạo ra có thể dùng cho công cụ khác hay giai đoạn) và môi trường phát triển(hệ thống trợ giúp phát triển PM.) được gọi là kỹ nghệ PM có sự trợ giúp của máy tính(case);Có 2 loại case: Upper case: hỗ trợ các hđ ban đầu như đặc tả yêu cầu và thiết kế.Lower case: hỗ trợ các hđ sau như lập trình, gỡ lỗi và kiểm thử;Ngôn ngữ mô hình hóa thống nhất UML: cung cấp ngôn ngữ chung cho tất cả các giai đoạn phát triển phần mềm hướng đối tượng;Một môi trường case chuẩn gồm: một kho chứa, công cụ đồ họa, PM soạn thảo văn bản, PM giao diện kho chứa, PM đánh giá, giao diện người sử dụng.

Đặc tính:So sánh PM với PC

HW : vật chất, hữu hình, sx công nghiệp bởi máy móc là chính, định lượng là chính, hỏng hóc, hao mòn; SW: trừu tượng, vô hình, sx bởi con người là chính, không hao mòn mà tốt lên sau mỗi lần có lỗi được phát hiện và sửa, vỗn chứa lỗi tiềm tàng theo quy mô càng lớn thì khả năng chứa lỗi càng cao.

Đặc tính chung của PM: chức năng phần mềm thường biến hóa, thay đổi theo hiệu ứng thời gian, hiệu ứng theo làn sóng trong thay đổi PM, PM vốn chưa ý tưởng và sáng tạo của tc giả, cần khả năng “tư duy nhị phần” trong xây dựng, phát triển PM, có thể sao chép đơn giản.

Phân loại :Có 7 loại PM chính: nhóm các hệ điều hành, nhóm chương trình dịch, nhóm chương trình hệ thống, nhóm các tiện ích và trò chơi, nhóm các hqt csdl, nhóm chương trình ứng dụng có tính hệ thống.

Các giai đoạn phát triển PM : Tìm hiểu nhu cầu của KH -> xác định rõ các chức năng hệ thống -> thử nghiệm và sửa chữa nếu thấy cần thiết -> bàn giao sp cho KH, tìm hiểu ý kiến KH để quyết định nhân bản nếu tốt hoặc sửa đổi -> đào tạo người sử dụng.

Kiên trúc PM : Chỉ 1 cấu trúc phầnm mềm và qua đó cung cấp 1 sự tích hợp chặt chẽ về mặt khái niệm của hệ thống. Vai trò: là công cụ giao tiếp giữa những người liên quan;Để phân tích hệ thống;Sử dụng lại ở quy mô lớn.

Kiến trúc phần mềm tác động sâu rộng đến quá trình phát triển phàn mềm , nó là 1 mô tả phần mền cho phép kĩ sư PM thực hiện công việc: Tăng cường hiểu biết vè hệ thống cần xây dựng; Phân tích hiệu quả; Xem xét, sửa đổi kiến trúc từ sớm, giảm rủi ro

            Phát triển PM: cơ sở khoa học cho phát triển PM

Phương pháp luận: những  chuẩn mực cơ bản để sản xuất phần mềm với các chỉ tiêu định tính.

Tính modul:Là khả năng phân chia PM thành các môdun ứng với các chức năng đồng thời cho phép quản lí tổng thể.Quan hệ giữa các  môdun là qua các đối số.

Chi tiết hóa từng bước:

Che giấu thông tin: Để phân rã PM thành các môdun  tốt nhất cần tuân theo nguyên lí che giấu thông tin:” các môdun nên đc đặc trưng những quyết định thiết kế sao cho mỗi modun ẩn kín đối với các môdun khác”; Rất hữu ích cho kiểm thử  và bảo trì phần mềm.

Trừu tượng hóa:cho phép tập trung vấn đề ở mức tổng quát, gạt đi nhữg chi tiết mức thấp ít liên quan. Có 3 mức trừu tượng: trừu tượng thủ tục :dãy các chỉ thị với các chức năng đặc thù và giói hạn nào đó; Trừu tượng dữ liệu: tập hợp dữ liệu mô tả đối tượng dl nào đó;Trừu tượng điều khiển: cơ chế điều khiển chương tình không cần đặc tả những chi tiết bên trong;

Các phương pháp kỹ thuật: những trình tự cụ thể để tạo phần mềm và là cách tiếp cận khoa học mang tính định lượng;

            Những chỉ tiêu cơ bản của PM: giá thành không vượt quá ước lượng ban đầu;Chứa tí lỗi tiềm tàng; PM có thể thay đổi thuật iện với yêu cầu người dùng;Tính ổn định ,bảo mật và an toàn của phần mềm;Sử dụng hiệu quả tài nguyên của hệ thống cho công việc : độ phưc tạp tính toán thấp, thời gian hồi đáp nhanh, sử dụng tài nguyên hữu hiệu:CPU, RAM, HDD..;Giao diện và phương thức phải phù hợp với người dùng, đáp ứng vói đúng yêu cầu của người dùng: kiến trúc và cấu trúc dễ hiểu , dễ kiểm tra, kiểm thử,

Chương 2: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM

I. Định nghĩa: CNPM là 1 lĩnh vực nghiên cứu của tin học nhằm đưa ra các nguyên lý, phương pháp, công cụ, phương tiện giúp cho việc thiết kế và cài đặt 1 sp phần mềm đạt được các yc sau 1 cách tốt nhất: phải có tính đúng đắn và khoa học, dễ tiếp cận và cải tiến, phổ dụng, độc lập với các thiết bị.

II. Vòng đời CNPM : tính từ khi phần mềm được sinh ra cho tới lúc chết đi ( từ khi hình thành đáp ứng yc, vận hành, bảo dưỡng à bị loại bỏ k đâu dùng). Được phân làm các pha chính : phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người)

(1) Pha xác đinh yc và thiết kế có vtro qđ chất lượng PM, chiếm phần lớn công sức so với lập trình và kiểm thử và chuyển giao PM.

(2) Pha cụ thể hóa cấu trúc PM phụ thuộc nhiều vào suy nghĩ từ trên xuống và trừu tượng hóa, cũng như chi tiết hóa.

(3) Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì từ dưới lên.

(4) Trước khi chuyển sang pha thiết kế phải đảm bảo pha hiện thời được kiểm thử k còn lỗi.

(5)Cần có cơ chế kiểm tra chất lượng,xét duyệt giữa các pha nhằm đảm bảo k gây lỗi cho pha sau

(6)Tư liệu của mỗi pha k chỉ dùng cho pha sau, mà chính là đối tượng quan trọng cho ktra và đảm bảo chất lượng của từng quy trình và của chính phần mềm.

(7)Chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu cho từng pha, nhằm đảm bảo chất lượng PM.

(8)Thao tác bảo trì PM là việc xử lý quay vòng trở lại các pha trong vòng đời PM nhằm biến đổi, sửa chữa, nâng cấp PM.

Phương pháp luận và kỹ thuật cho từng pha

Tên pha

Nội dung nghiệp vụ

Phương pháp, kỹ thuật

Xác định yêu cầu

Đặc tả yc người dùng

Ptich cấu trúc hoặc HĐT

Thiết kế hệ thống

Thiết kế cơ bản PM

Ptich cấu trúc hoặc HĐT

Thiết kế chương trình

Thiết kế chi tiết: cấu trúc bên trong PM(đvị chương trình, modul)

Thiết kế cấu trúc hoặc HĐT

Lập trình

Viết ctrinh bằng 1 ngôn ngữ nào đó

Lập trình thủ tục hoặc HĐT

Đảm bảo chất lượng

Ktra chất lượng PM đủ phát triển

Phương pháp kiểm thử ctrinh

Vận hành, bảo trì

Sd, vận hành PM để phát triển.Biến đổi, điều chỉnh PM

Chưa cụ thể

III. Tiến trình phát triển phần mềm

Hoạt động chính: Xác định yc: nắm bắt yêu cầu từ KH để đưa ra đặc tả yc(chức năng hệ thống, ràng buộc hệ thống);Phát triển PM: sau khi có đặc tả yc, đội phát triển sẽ làm việc và tạo ra hệ thống vận hành được;Kiểm thử PM:từ đặc tả yc và ptrien pm ktra, đảm bảo hệ thống đáp ứng đòi hỏi trong đặc tả yc(k lỗi).Tiến hóa PM: khi có nhân tố thay đổi tác động( lỗi ctrinh, môi trường, kh) sẽ thay đổi PM.

Vai trò: thể hiện phương pháp phát triển PM

Mô hình phát triển PM ( mô hình tuần tự tuyến tính(mô hình thác nước), mô hình tiến hóa(mô hình nguyên mẫu, các mô hình lặp lại : xoắn ốc, gia tăng), mô hình RAD, mô hình hình thức, mô hình hướng thành phần.

o   Mô hình thác nước

+Phân tích: Xác định & ptich các yc cho ht(chức năng, ràng buộc). KH à tài liệu yc(danh sách yc, mô tả chi tiết yc)

+Thiết kế: Xây dựng giải pháp thiết kế cho yc phần mềm.Tài liệu cần, môi trường triển khai à mô hình kiến trúc ht, mô hình thiết kế chi tiết ( dữ liệu, thuật toán, giao diện)

+Lập trình&ktra modul: Viết chương trình.Ktra, giám sát mã lệnh.Gỡ rối.Tài liệu thiết kế à chương trình thực hiện được, tài liệu chương trình

+Kiểm thử: Phát hiện, sửa lỗi phần mềm.Đảm bảo pm thỏa mãn yc kh.Tài liệu yc, tài liệu tk, chương trình, tài liệu chương trình à tài liệu kết quả kiểm thử

+Bảo trì: Đưa vào hệ thống vận hành.Sửa lỗi pm.Làm thích nghi pm với môi trường mới.Thay dổi pm đáp ứng yc mới

Ưu điểm: Xuất hiện sớm, có ý nghĩa về lý thuyết.Các pha được xđ rõ ràng.Thấy được trình tự từ đầu tới cuối sp.Bảo trì thuận lợi.Thích hợp khi yc rõ ràng. Nhược điểm: Tách biệt giữa các pha, tiến hành tuần tự( khó tuân thủ tuần tự,khó đáp ứng yc thay đổi của kh).Sai sót muộn sẽ là thẩm họa của dự án.Chậm có phiên bản thự hiện được.

o   Mô hình làm bản mẫu

Nhu cầu làm bản mẫu: dự án phức tạp,kh thường là khó nói được điều họ mong đợi, người pát triển hiểu sai yc kh, kh phát hiện sai sót khi dùng sp à tạo môi trường để thâu tóm yc.

Mục tiêu: thâm tóm yc người dùng, giảm sai sót. Đảm bảo yc là những gì kh mong đợi.

Hoạt động: khởi đầu bằng pha thu thập ycà thiết kế nhanhàxây dựng bản mẫu à đánh giá của kh à Nếu chưa được sp thì chuyển sang thiết kế nhanh và lặp lại.

Thiết kế: là hđ quan trọng của quá trình làm bản mẫu. Trình diễn khía cạnh pm mà kh nhìn thấy. Phải nhanh & ít công sức. Phụ thuộc vào các yếu tố(loại bản mẫu, định hướng bản mẫu).

Các loại bản mẫu: trên giấy, thực hiện 1 phần chức năng, giao diện, hướng tới sp.

Khi nào được sd: khi mới chỉ rõ mục đích chung của pm, chưa rõ chi tiết đầu vào hay xử lý ra sao, chưa rõ yc đầu ra. Dùng như hệ sơ Mụci để thu thập yc người dùng qua các thiết kế nhanh. Các giải thuật, kỹ thuật dùng trong làm bản mẫu có thể chưa nhanh, chưa tat, miễn là có mẫu để thảo luận để gợi yc của người dùng.

Ưu điểm: k có giai đoạn tích hợp, người dùng được tiếp cận với ht ngay từ giai đoạn đầu để bổ sung hoàn thiện pm theo đúng yc.Nhược điểm: phức tạp hơn phương pháp thác nước.

o   Mô hình xoắn ốc

Ưu nhược điểm: tốt cho các hệ pm có quy mô lớn. Dễ kiểm soát các mạo hiểm ở mức tiến hóa. Khó thuyết phụ kh là phương pháp tiến hóa xoắn ốc có thể kiểm soát được. Chưa được dùng rộng rãi như các mô hình tuyến tính hoặc chế thử.

o   Mô hình gia tăng:

Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu. SP lõi với yc cơ bản nhất của ht được ưu tiên phát triển trước. Các chức năng với những yc khác được phát triển thêm sau. Lặp lại quy trình để hoàn thiện. Biểu diễn trực quan thành các gđ.

Mô hình xoắn ốc

Mô hình gia tăng

- Gđ sau bắt đầu khi gđ trước kết thúc

- K mất công để tích hợp nhưng sẽ lâu hơn

- Những chức năng được thử nghiệm, ktra nhiểu lần

- Ưu điểm: dễ kiểm soát các mạo hiểm

- Nhược: khó thuyết phục khách hàng là mô hình xoắn ốc có thể kiểm soát được.

- Các gđ phát triển gần như là //

- Mất công tích hợp. Mỗi bản tăng tiếp thep phải được tích hợp với bản tăng trước. Đây là khâu khó khăn nhất. Khâu thiết kế phải thống nhất về chuẩn hóa mới có thể tích hợp được

- Các chức năng được thử nghiệm và ktra nhiều lần

- Ưu:Có sp dùng được trong thời gian ngắn: đáp ứng nhanh yc kh, chiếm lĩnh thị trương. Bản tăng trước là bản mẫu cho bản  tăng sau. Rủi ro được loại bỏ sớm. Dịch vụ ht được ưu tiên mức cao nhất, được kiểm thử nhiều nhất.

- Nhược:Khó khăn trong tích hợp bản tăng. Tổng chi phí phát triển cao hơn. Tổng thời gian để chuyển giao lớn hơn.

o   Mô hình theo thành phần

Dựa trên kỹ thuật tái sử dụng 1 cách có ht, được tích hợp từ nhiều tp đang tồn tại hoặc các tp thương mại. Các trạng thái chính của quy trình ( Phân tích tp có sẵn, Điều chỉnh yc, Thiết kế hê thống với kỹ thuật tái sd, Xd và tích hợp ht). Gắn với những công nghệ HĐT, có nhiều tương đồng với mô hình xoắn ốc. Ưu điểm: tái sử dụng các tp qua thư viện/kho các lớp: tiết kiệm 70% thời gian, 80% giá thành.

o   Mô hình phát triển ứng dụng nhanh

Là quy trình phát triển pm gia tăng, tăng dần từng bước, với mỗi chu trình phát triển rất ngắn(60-90 ngày). Là phương pháp luận gộp các  hđ phân tích, tk, xd vào 1 loạt vòng lặp phát triển ngắn.

Xd dựa trên hướng thành phần, có khả năng tái sd.

Gồm 1 số nhóm, mỗi nhóm làm 1 RAD theo các pha: mô hình nghiệp vụ, mô hình dữ liệu, mô hình xử lý, tạo ứng dụng, kiểm thử và đánh giá…

Hướng đến nhu cầu đưa người sd tam gia vào pttk bằng cách sd case. Đáp ứng nhu cầu hiệu quả và chi phí bảo trì thấp. Thích hợp cho đội phát triển nhỏ.

Mô hình nghiệp vụ: luồng thông tin được mô hình hóa để trả lời các câu hỏi: Thông tin nào được điều khiển xử lý nghiệp vụ? Thông tin gì được sinh ra:? Ai sinh ra nó? Thông tin đi đến đâu? Ai xử lý chúng?

Dữ liệu&tiến trình mô hình hóa: Mô hình hóa dl( các đối tượng dl cần để hỗ trợ nghiệp vụ. Định nghĩa các thuộc tính của từng đối tượng & xác lập quan hệ các đối tượng). Tiên trình mô hình hóa( các đối tượng dl được chuyển sang luồng thông tin thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý dễ cập nhật từng đối tượng dữ liệu)

Phát triển ứng dụng & kiểm thử: phát triển ứng dụng: dùng các kỹ thuật thế hệ 4 để tạo pm từ các tp có sẵn hoặc tạo ra các tp có thể tái sd lại sau này. Dùng các công cụ tự động để xd pm. Kiểm thử và quay vòng: kiể thử các thành phần mói cà kiểm chứng mọi giao diện.

Hạn chế: cần nhiều nhân lực để tạo các nhóm cho các chức năng chính. Yêu cầu 2 bên giao kèo trong thời gian ngắn phải có pm hoàn chỉnh, thiếu trách nhiệm của 1 bên à dự án đổ vỡ. RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng k thể modul hóa hoặc đòi hỏi tính năng cao. Mạo hiểm kỹ thuật cao thì k nên dùng RAD.

o   Mô hình RUP

Là mô hình dành riêng cho HĐT. Có 3 đặc trưng ( Lấy kiến trúc làm trung tâp. Điều khiển bởi các ca sd. Lặp lại và tăng dần). Tương đồng với mô hình xoắn ốc, tuy nhiên mỗi bước lặp của RUP, nội dung hđ có nội dung riêng gắn với ngôn ngữ mô hình hóa thống nhất UML.

o   Mô hình hình thức

Các bước gồm: Xđ yc, đặc tả hình thức, biến đổi hình thức, kiểm thử tích hợp và hệ thông.

Tư tưởng chính là biểu diễn các đặc tả yc bằng các ký pháp toán học.

Áp dụng khi chuyển đổi các biểu diễn của đặc tả được chi tiết dần nhưng luôn được đảm bảo tính đúng đắnà chương trình là triển khai đúng của đặc tả.

Thường dùng trong phát triển pm cần độ an toàn rất cao.

Ưu điểm: Có thể áp dụng chứng minh tính đúng đắn của đặc tả. Chứng mình chương trình đáp ứng được yc của đặc tả đã cho. Chi phí đặc tả cao, nhưng chi phí sau đó lại nhỏ hơn nhiều so với phương pháp khác. Dễ theo dõi các bước nhỏ trong quá trình chuyển đổi.

Nhược: việc đặc tả đòi hỏi trình độ trừu tượng cao.Việc chứng minh tính đúng đắn là khó khăn

Chương III : PHÂN TÍCH HỆ THỐNG

Phân tích hệ thống:Là bước đầu tiên rất quan trọng cho việc phát triển dự án phát triển PM. Công việc : thu thập yc và quy trình nghiệp vụ htai, ptich và xác lập quy trình sẽ được phát triển/ thay thế bằng máy tính, các thực các yc / tính năng của ht.Kêt quả việc ptich là các tài liệu đặc tả chức năng. Kết quả được dùng cho việc xác thực các tính năng của hệ thống với khách hàng. Đầu vào tiếp theo của qtrinh thiết kế hệ thống.Tùy thuộc vào công nghệ phát triển mà sử dụng các phương pháp phân tích phù hợp.

Khó khăn trong phân tích hệ thống: Cách biệt về lĩnh vực chuyên môn cần phân tích;Sự hiểu biết của những người end user về quy trình làm việc và khả năng ứng dụng phần mềm cho công việc của họ;Những vấn đề về điều kiện hạ tầng hỗ trợ hoạt động của hệ thống;Tính sẵn sàng thông tin của các hệ thống đang có sẽ tương tác với hệ thống cần xây dựng;Định hướng ứng dụng lâu dài chưa có/ chưa rõ ràng;Công cụ/ngôn ngữ sử dụng để đặc tả hệ thống / kết quả phân tích

Phân loại yêu cầu:

Yc chức năng: mô tả hệ thống sẽ làm gì, mô tả chức nưng hoặc các dịch vụ của hệ thống 1 cách chi tiết, đặc điểm : mập mờ, không rõ ràng ( các yc k được xđ cẩn thận). tính hoàn thiện và nhất quán ( chứa các mô tả chi tiết vá k có sự xung đột, đối ngược giữa các yc)

Yc phi chức năng:

K đề cập trực tiếp tới các chức năng cụ thể mà thường được đn bởi các thuộc tính : độ tin cậy, thời gian đáp ứng,… và các ràng buộc của hệ thống như : khả năng thiết bị vào/ra, giao diện… Các yc này có thể là hạn chế hơn những yc chức năng. Nhưng nếu nó k được thỏa mãn thì ht sẽ k sd được

Các yêu cầu này xuất hiện là do yêu cầu của người sử dụng, ràng buộc về ngân sách, các chính sách của tổ chức sử dụng hệ thống….

Phân loại ( 3 loại) :Các yêu cầu về sản phẩm như: hiệu năng, khả năng sử dụng, độ tin cậy, không gian, linh động … của sản phẩm. Các yêu cầu về tổ chức: các yêu cầu này được lấy từ những chính sách và quy tắc của khách hàng hoặc tổ chức sử dụng hệ thống như: chuyển giao, cài đặt và hợp chuẩn. Các yêu cầu ngoài: được xác định từ các tác nhân ngoài của hệ thống như: tương thích, hợp quy tắc, luật, riêng tư và an toàn.

Yc miền ứng dụng:

Được xđ từ miền ứng dụng của ht và phản ánh các thuộc tính&ràng buộc của miền ứng dụng. Nó có thể là yc chức năng hoặc phi chức năng. Nếu k được thỏa mãn ht sẽ k làm việc được.

Một số vđ liên quan: Khả năng có thể hiểu được(các yc được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng). Ẩn ý( Các chuyên gia hiểu biết các lĩnh vực của họ nhưng k xđ được yc miền ứng dụng 1 cách rõ ràng, mang tính kỹ thuật).

Đặc tả yêu cầu hệ thống.

Ngôn ngữ tự nhiên: thường được sd để viết các đặc tả yc hệ thống cũng như yc của người sd. Tuy nhiên thường có những khó khăn: K rõ ràng( ngôn ngữ tự nhiên có bản chất là mập mờà kdos đạt được yc). Quá mềm dẻo(có nhiều cách khác nhau để đặc tả 1 vđ). Thiếu khả năng modul hóa ( cấu trúc của ngôn ngữ tự nhiên k tương xứng với cấu trúc của yc hệ thống) à Thường gây khó hiểu.Ngôn ngữ hướng cấu trúc: yc phải tuân thủ theo mẫu được đn sẵn. Tất cả yc đều được viết theo chuẩn và các thuật ngữ được sd có thể bị hạn chế. Ưu: đạt được mức đọc diễn tả cao nhất của ngôn ngữ tự nhiên nhưng mức độ đồng nhất lại bị lạm dụng trong đặc tả.Dựa vào biểu mẫu: đn các chức năng, thực thể, mô tả đầu vào và nơi xuất phát của nó, mô tả đầu ra và nơi nó sẽ đến. chỉ rõ những thực thể cần thiết, các đk trước, sau. Các ảnh hưởng của chức năng.Biểu đồ trình tự: biểu diễn các sự kiện xảy ra khi người sd tương tác với ht. nếu ta đọc biểu đồ này từ đầu tới cuối thì sẽ thấy được thứ tự các hđ được thực hiện.

Đặc tả giao tiếp: Tài liệu yc pm:Là những yc chính thức về những gì cần làm bởi đội phát triển ht. bao gồm đn về yc của người sd và đặc tả yc ht.Đây k phải là tài liệu tkht.Nó chỉ lập những gì ht phải làm.Cấu trúc: 5 mục chính ( Giới thiệu, mô tả tổng quan, các yc cụ thể, phụ lục, chỉ mục). Người sd: người sd hệ thống(chỉ định các yc và đọc sau đó ktra xem đã đúng yc ht cầnchưa, có thể đưa ra sự thay đổi). Người quản lý( sd tài liệu để lập 1 hợp đồng cho hệ thống và tiến trình). Kỹ sư ht(sd tài liệu để hiểu về ht được phát triển). Kỹ sư ktra ht(sd tài liệu để phát triển các bộ kiểm thử cho ht). Kỹ sư bảo trì hệ thống(sd tài liệu để hiểu về ht và liên kết giữa các phần).Yc của tài liệu: (6yc) chỉ mô tả các hđ của ht từ bên ngoài. Chỉ ra được các ràng buộc của ht trong qtrinh vận hành. Dễ thay đổi. Phục vụ như tài liệu tham khảo cho người bảo trì ht. Mô tả được đáp ứng đối với sự cố, thay đổi ngoài dự tính.

Kỹ thuật xác định phân tích  yc:

Tiếp cận định hướng khung nhìn: Ghi nhận cách nhìn khác nhay của những người liên quan và sd nó vào tiến trình phát hiện yc và tổ chưc các yc. Các góc độ khác nhau có thể được xem xét( Từ nguồn hay đích của dữ liệu. Từ khung làm việc. Từ sự tiếp nhận dịch vụ). Xác định yc định hướng cách nhìn gồm 4 gđ cơ bản( Xđ khung nhìn. Cấu trúc khung nhìn. Làm tài liệu khung nhìn. Ánh xạ ht khung nhìn)

Dựa trên mô hình: được sd rộng rãi để pt yc.Kỹ thuật này đi theo 2 hướng tiếp cận( Tiếp cận định hướng chức năng. Tiếp cận hướng đối tượng). Tập trung hướng vào mô tả nghiệp vụ của ht thực, kết quả thu được là mô hình nghiệp vụ. Mô hình nghiệp vụ theo pp này gồm : Mô hình ngữ cảnh(mô tả ht được xét trong môi trường của nó), các mô hình cấu trúc chức năng mô tả cấu trúc chức năng của ht, mô tả chi tiết các chức năng cho tới mức thấp nhất, mô tả các đối tượng dữ liệu(theo hướng cấu trúc là bao gồm các hồ sơ và bản mẫu, theo HĐT gồm các đặc tả và khái niệm của thế giới thực), mô rả các mối liên kết của dl và chức năng- chỉ cần thiết với cách tiếp cận hướng cấu trúc,từ điển gthich

Kỹ thuật phân tích hình thức hóa: dựa trên việc sd các khái niêm, ký pháp và mô hình toán học để phân tích và biểu diễn ht. Phân tích sẽ k tách thành các mô hình riêng, kết quả của việc ptich và mô hình hóa cho ta ngay đặc tả của ht.

Quy trình phân tích

Thu thập thông tin hệ thống hiện tại và nghiên cứu khả thi

Thu thập thông tin hệ thống hiện tại và nghiên cứu khả thi:Thu thập các quy trình hoạt động, nghiệp vụ. phươn g thức và ý nghĩa của các quá trình xử lý. Dữ liệu của hệ thống. Điều kiện hạ tầng, thiết bị, con người.

Nghiên cứu khả thi:Phân tích ý nghĩa của hệ thống đối với hoạt động chung của toàn cơ quan? Có thể triển khai hệ thống với các công nghệ, chi phí và lịch trình nào? Sự tích hợp của hệ thống?

Trên cơ sở nghiên cứu hệ thống: cần đưa ra phương án phát triển và luận chứng khả thi nhằm đưa ra 1 ht đáp ứng được yc của khà có tính khả thi cao nhất. Các phương án đưa ra phải quyết định có tiếp tục phát triển theo 1 phương án nào đó k? Chỉ khi dự án khả thi mới được chấp nhận, quá trình triển khai mới được bắt đầu. Nên phân loại dự án(thấp, trung bình, cao). Phân tích khả thi thường tập trung vào các mặt : kinh tế, kỹ thuật, pháp lý, hoạt động, thời gian.

Thu thập và phân tích yc

Xác định yc: các yc về chức năng của ht. Các yc về môi trường vận hành: thiết bị, con người.

Phân tích yc: phân tích các yc theo quy trình xử lý. Bổ sung các quy trình cho phù hợp với máy tính. Yc bổ sung các thông tin.

Khảo sát yc của kh và người sd về miền ứng dụngà ptich thành tài liệu cần xđ các yc. Giai đoạn này bao gồm cả việc phát triển thử nghiệm 1 hay nhiều mô hình hệ thống khác nhau. Quá trình này thường gặp khó khăn vì chính người sd k biết mình cần gì ở ht, có thể bị ảnh hưởng vởi yếu tố chính trị do hoàn cảnh cụ thể của các tổ chức, môi trường kinh doanh biến động thường xuất hiện các yc mới mà k dự báo trước,một số yc k thể định nghĩa được k có công thức trước. Tiến trình này được bắt đầu bằng việc tìm hiểu lĩnh vự ứng dụng và kết thúc bằng việc thẩm định yc.

Các bước của tiến trình phát hiện và phân tích yc: tìm hiểu miền ứng dụngàthu thâpj ycàPhân loại ycàGiải quyết xung độtàSắp ưu tiênàKtra yc.

Đặc tả yc: Mô tả chính xác và chi tiết yêu cầu của hệ thống để làm cơ sở cho giao kèo giữa khách hàng và người phát triển hệ thống. Thường phải sd những công cụ đặc biêt. Việc lập tài liệu này thường được tiến hành // với các thiết kế ở mức cao (thiết kế sơ bộ). Khi viết tài liệu này, các sai sót trong xđ yc sẽ được phát hiện và sửa chữa.

Thẩm định yc: Xác thực với người dùng về tính hơp lý và đầy đủ cuẩ các tính năng: Xác thực các quy trình nghiệp vụ và xác thực các ràng buộc. Các thuộc tính cần thẩm định gồm: tính đúng đắng, tính nhất quán, đầy đủ, tính hiện thực, tính có thể kiểm chứng được. Các lỗi có thể phát hiện: Bỏ sót thông tin, không nhất quán, sai sự thật, không rõ ràng.

Kiểm tra tính hợp lệ, hơn nữa suy nghĩ và phân tích có thể xđ các chức năng bổ sung khác nhau mà bắt buộc. Kiểm tra tính nhất quán: yc k nên xung đột. Kiểm tra đầy đủ:yc tài liệu phải bao gồm các yc, trong đó xác định chức năng và hạn chế của người sd ht. Kiểm tra hiện thực: sd kiến thức về công nghệ hiện có, các yc cần được ktra để đảm bảo rằng họ thực sự có thể được thực hiện. Kiểm chứng được: Để giảm khả năng tranh chấp giữa khách hàng và nhà thầu, yc ht phải luôn được viết để họ có thể kiểm chứng được.

Rà soát lại: Ai tham gia rà soát(tác giả, người hiểu ht, người tổ chức thiết kế, người có nhiệm vụ bảo trì, người có khả năng  k liên quan trực tiếp như kỹ sư phần mềm

Phương pháp cấu trúc: các bước được thực hiện đồng thời và xen kẽ nhau, thường sd lược đồ: DFD, ERD, STD

Yếu tố căn bản của mô hình:

Lưu đồ dòng chảy dữ liệu (DFD):

Mô hình chức năng và dòng thông tin:DFD, PSPEC. Mô tả dòng thông tin di chuyển xuyên qua các hệ thống thiên về phần mềm. Diễn tả các tương tác xuất nhập dữ liệu với con người và các hệ thống khác.

Lưu đồ dòng chảy dữ liệu DFD cung cấp 4 ký hiệu cơ bản để mô hình sự di chuyển của dòng thông tin(thực thể : tạo ra hoặc sd thông tin, nằm bên ngoài thế giới của phạm vi thông tin ht. chức năng xử lý: thực hiện chức năng nào đó, tiêu thụ và tạo ra thông tin, nằm bên ngoài phạm vi thông tin ht. Thông tin thay đổi dữ liệu. Kho dữ liệu : lưu dữ liệu mà được sd bởi nhiều chức năng xử lý). Được xd qua nhiều mức khác nhau.

Kỹ thuật phân tích hệ thống: tiếp xúc, phỏng vấn các người dùng trong ht thu thập các thông tin về nghiệp vụ của người dùng. Thiết lập đoạn văn miêu tả chức năng cho ht cần xd. Xây dựng DFD ở các mức khác nhau(thiết lập sơ đồ ngữ cảnh(0), phân hoạch DFD vào các mức cao hơn, luôn tuân theo tính liên tục của dòng dữ liệu). viết PSPEC cho các chức năng của DFD mức cao nhất.

DFD mức 0 : nhận diện các thực thể và dữ liệu input, output. DFD mức 1 hình thành 1 số chức năng chính.

Hạn chế của DFD: ý nghĩa của các ký pháp sd được xđ bởi các định danh lựa chọn của người sd.

Lưu đồ dịch chuyển trạng thái(STD):

Mô hình hành vi của hệ thống. Lược đồ dịch chueyenr trạng thái thể hiện : các trạng thái khác nhau của ht, sự dc giữa các trạng thái đó. Mô tả chi tiết hơn đk xảy ra các hành vi. Cung cấp 1 hình ảnh động về ht.STD chứa: tập hữu hạn các trạng thái, tập hữu hạn các đầu vào, các chức năng chuyển tiếp.

Lưu đồ quan hệ thực thể(ERD): đặc tả thông tin về dữ liệu của hệ thống. Cấu trúc dữ liệu. Các quan hệ và ràng buộc dữ liệu.

Từ điển dữ liệu: đặc tả đối tượng dữ liệu.

Phương pháp OOP

Mô hình nghiệp vụ - Thu thập yc:

Quan điểm thu thập/phân tích yc của mô hình nghiệp vụ: hệ thống gồm có Ai? Làm gì? Khi nào? Lược đồ Use-case:actor&user-case, các mối quan hệ( Actor – Actor ; Actor-Use-case, - Use-case-Usace). Actor xđ 1 bộ vai trò mà người hoặc vật sẽ đóng vai khi tương tác với ht ngoài pm ( actor nằm ngoài phạm vi ht, chỉ quan tâm tới các thông điệp mà actor gửi hay nhận, không quan tâm tới cấu trúc bên trong của actor).Phân loại actor:Chủ yêu/thứ yếu, tích cực/thụ động.

Nhận diện các actor: ai là người sd các chức năng chính của ht? Ai cần sự hỗ trợ ht để thực hiện cv của họ? Ai phải thực hiện cv bảo dưỡng, quản trị và giữ cho ht hoạt động? Ht sẽ kiểm soát thiết bị phần cứng nào? Ht đang xây dựng cần tương tác với những ht khác hay k? Ai hoặc vật thể nào quan tâm đến hay chịu ảnh hưởng bởi kết quả mà ht pm tạo ra?

Biểu diễn actor trong UML : được biểu diễn bằng kí hiệu hình người, được xem là 1 lớp, giữa các actor có thể có quan hệ tổng quát hóa.

User-case: biểu diễn 1 chức năng của hệ thống pm. Được biểu diễn bằng 1 chuỗi các thông điệp trao đổi bên trong ht và 1 hoặc 1 số thông điệp trao đỏi với actor. Quy ước: luôn bắt đầu bằng thông điệp đến từ actor, phải hoàn tất chuỗi thông điệp phải kết thúc bằng kết quả cụ thể. Lỗi thường gặp: chia nhỏ use-case thành các chức năng vụn vặt.

Biểu diễn: bằng hình elip. Điểm mở rộng là 1 vtri trong use-case mà tại đó có thể chèn chuỗi sụ kiện của 1 use-case khác. Có thể chứa đk rẽ nhánh, xử lý lỗi ngoại lệ…

Tìm kiếm use-case: Trả lời các câu hỏi: Actor yêu cầu chức năng gì của ht? Actor cần phải đọc, tạo, xóa, sửa đổi, lưu trữ thông tin nào đó của ht k? Actor cần thiết phải được cảnh báo về những sự kiện trong ht hay actor cần phải báo hiệu cho ht về vđ nào đó k? ht có thể hỗ trợ 1 số cv thường nhật của actor nào đó hay k?. hoặc 1 số câu hỏi : hệ thống cần sl iput/output nào? Dữ liệu đó đến từ đâu? Những khó khăn nào liên quan đến thực hiện của ht hiện tại.

Quan hệ giữa use-case và actor thường có quan hệ liên kết( được actor nào kích hoạt) có thể là lk 1 chiều hay 2 chiều. Actor kích hoạt use-case và nhận kêt quả trả vể(2 chiều). Actor kích  hoạt use-case không quan tâm kết quả trả về ( 1 chiều)

Quan hệ gộp giữa 2 use-case: Dùng để lk 2 use-case có stereotype là <<include>> trong use-case nguồn có điểm mở rộng mà tại đó bắt buộc phải chèn use-case đích vào ( Tại điểm mở rộng, diễn tiến của use-case nguồn tạm thời ngừng lại để chuyển sang diễn tiến của use-case đích.Khi kết thúc use-case đích,diễn tiến của use-case nguồn tại tiếp tục)

Quan hệ mở rộng giữa 2 use-case:dùng để lk 2 use-case có stereotype là <<extend>>  trong use-case nguồn có 1 điểm mở rộng mà tại đó có thể hoặc k chèn use-case đích, tùy thuộc vào đk rẽ nhánh hoặc tương tác từ actor( Tại điểm mở rộng, nếu được mở rộng thì diễn tiến của use-case nguồn tạm thời ngừng lại để chuyển sang diễn tiến của use-case đích. .Khi kết thúc use-case đích,diễn tiến của use-case nguồn tại tiếp tục)

Quan hệ tổng quát hóa: mối quan hệ các đối tượng cùng nhóm tạo nên 1 đối tượng mang những tính chất chung của các đối tượng kia. Quan hệ tổng quát hóa giữa các Actor: nhiều actor có chung một số vai trò -> hình thành actor tổng quát hóa mang vai trò chung đó. Quan hệ thổng quát hóa giữa các Use-case: khi có nhiều use-case là trường hợp cụ thể một use-case trừu tượng.

Xây dựng mô hình use-case: các yc của phần mềm được mô tả trong mô hình hình use-case. Mô hình use-case bao gồm lược đồ use-case và có thể một số packet(gom 1 số use-case thành 1 bộ chức năng con của ht). Phương pháp thực hiện(Xác định các actor và use-case của ht. Xác lập các quan hệ giữa các đối tượng này( Quan hệ mở rộng hay gộp giữa 2 use-case một chiều hoặc 2 chiều thường có stereotype là <<communicate>>. Quan hệ mở rộng hay gộp giữa 2 use-case quan hệ liên kết với stereotype <<extend>> hay <<include>>. Quan hệ tổng quát hóa giuwac actor: nhiều actor có vai trò của một actor trừu tượng. Quan hệ tổng quát hóa giuwac các use-case nhiều use-case là trường hợp cụ thể của một use-case trừu tượng.). Trình bày thành lược đồ use-case theo chuẩn UML. Có thể xác định các packet.

Mô hình phân tích – phân tích yêu cầu

Mô hình nghiệp vụ biểu diễn các chức năng pm cần xd dưới dạng use-case.

Mô hình phân tích sẽ tìm kiếm các đối tượng “sống” trong ngữ cảnh của phần mềm. Các đối tượng sẽ tương tác với nhau để tạo nên các chức năng mô tả bởi use-case. Lược đồ Class phân tích diễn tả cấu trúc, mối quan hệ giữa các đối tượng/lớp trong hệ thống. Chưa quan tâm đến hành vi cụ thể và nhiệm vụ chi tiết của chúng trong ngữ cảnh của ht. Nguyên tắc: mô hình phân tích phải độc lập với o/s, ngôn ngữ lập trình, công cụ phát triển.

Xây dựng mô hình phân tích được diễn đạt trong UML bằng lược đồ lớp phân tích. Các công việc xd lược đồ phân tích (Tìm kiếm các đối tượng/lớp trong ht( đối tương/lớp thực thể. Đối tượng/lớp biên. Đối tượng/lớp control). Xác định các thuộc tính của đối tượng/lớp. Xác định các tác vụ của đối tượng/lớp. Nhận diện các lớp trừu tượng qua mối quan hệ tổng quát hóa. Xác lập các mối quan hệ giữa các lớp(tổng quát hóa, liên kết, bao gộp)). Biểu diễn thành lược đồ phân tích.

Nhận diện đối tượng/lớp: Dựa vào đặc tả của từng use-case để tìm kiếm các đối tượng. Các đối tượng thường xuất hiện trong các danh từ hay nhóm danh từ. Một số lưu ý( k nên dùng đối tượng để biểu diễn 1 dl đơn. Đối tượng/lớp phải thực sự cần thiết cho sự hoạt động của ht. Đối tượng/lớp>< bảng csdl. Đối tượng/lớp>< actor.

Phân loại đối tượng/lớp: Đối tượng thực thể (entity): biểu diễn các thông tin thiết yếu của hệ thống, có thể được lưu trong cơ sở dữ liệu. Đối tượng biên (boundary): thực hiện chức năng giao tiếp với actor. Đối tượng điều khiển (control): điều khiển các đối tượng khác

Trong UML, lớp được biểu diễn bằng một hình chữ nhật gồm 3 phần: tên, các thuộc tính và các tác vụ.  Có thể áp dụng stereotype cho lớp: <<entity>>, <<boundary>>, <<control>>... .Đối tượng cũng được biểu diễn bằng hình chữ nhật, thông thường gồm 2 phần: tên đối tượng +”:”+ tên lớp (được gạch chân), giá trị các thuộc tính (trạng thái của đối tượng)

Đối tượng/lớp thực thể: Biểu diễn cho các thực thể xuất hiện một cách tự nhiên trong hệ thống. Thông tin về các đối tượng thực thể có thể phải được lưu trữ lâu dài (database, file...). Trong UML, được gán stereotype <<entity>> . Dễ nhận diện các thuộc tính của chúng

Đối tượng/lớp biên: Thực hiện chức năng giao tiếp với actor. Thường chứa các phần tử hoặc điều khiển giao diện người dùng (nút nhấn, hộp danh sách, tuỳ chọn, menu...). Trong UML, được gán stereotype <<boundary>> . Khó nhận biết các thuộc tính và tác vụ trong mô hình phân tích.

Đối tượng/lớp điều khiển: Có nhiệm vụ điều khiển các lớp khác hoặc  Những lớp không phải là lớp thực thể và lớp biên . Trong UML, được gán stereotype <<control>> .  Lớp biên thường có quan hệ liên kết hoặc phụ thuộc với các lớp khác. Ví dụ: Đối tượng biểu diễn một số lệnh thông thường như cắt, dán, thay đổi thông số nhìn trong hiển thị đồ hoạ …

Nhận diện các thuộc tính : Dựa vào đặc tả của từng use-case, tìm kiếm các danh từ hoặc nhóm danh từ liên quan đến đối tượng đang xét.

Trả lời câu hỏi: những thành phần nào cấu thành đối tượng đang xét ?Lưu ý: cùng một đối tượng trong các ngữ cảnh khác nhau chúng ta có thể tìm được các thuộc tính khác nhau

Nên xác định (tuy nhiên không bắt buộc) trong mô hình phân tích:  Kiểu của thuộc tính: một số kiểu cơ bản; Bậc của thuộc tính: số ít hoặc số nhiều ; Visibility của thuộc tính: mức độ cho phép truy xuất thuộc tính từ bên ngoài

 UML: thuộc tính được miêu tả tường minh hoặc thông qua quan hệ với các lớp khác

Xác định mức độ truy cập của thuộc tính: Mức độ truy cập và phạm vi mà thuộc tính đó có thể được tham khảo đến trực tiếp

UML định nghĩa 3 mức độ truy xuất thuộc tính (visibility):  public (+): có thể truy xuất thuộc tính từ tất cả các vị  trí khác nhau.  protected  (#): bản thân lớp đang xét và các lớp con của nó có thể truy xuất thuộc tính.  private (-): chỉ có lớp đang xét có thể truy xuất thuộc tính

Thông thường nên đặt mức độ truy xuất thuộc tính là private hoặc protected (cho các lớp cơ sở), không nên là public.Thuộc tính nên được truy xuất thông qua tác vụ get/set

Nhận diện các tác vụ:  Dựa vào đặc tả của từng use-case, tìm kiếm các động từ hoặc nhóm động từ liên quan đến đối tượng đang xét.  Chú ý xem đối tượng được tạo ra và bị huỷ bỏ đi như thế nào ? Trong thời gian đó nó gửi/nhận thông điệp ra sao ? Các đối tượng biên có các tác vụ nhận lệnh từ actor.Xem xét mức độ truy xuất của tác vụ tương tự như đối với các thuộc tính; các tác vụ thường có visibility là + hoặc #.  Một số tác vụ không xuất hiện một cách tự nhiên trong mô hình phân tích à mô hình thiết kế sẽ nghiên cứu kỹ trách nhiệm và hành vi của từng đối tượng.

Nhận diện lớp cơ sở : Lớp cơ sở (base class) được nhận diện sau khi đã nhận diện các lớp cụ thể. Sự xuất hiện của lớp cơ sở làm cho mô hình phân tích có tính tái sử dụng lại cao (reusability) và dễ mở rộng (scalability). UML hỗ trợ quan hệ tổng quát hoá (generalization). Lớp cơ sở trừu tượng (không thể cụ thể hoá tạo ra đối tượng) có tên in nghiêng.Lớp cơ sở được hình thành bằng cách xác lập các quan hệ tổng quát hóa của các lớp cụ thể có chung một số thuộc tính và/hay một số tác vụ. Đối với các đối tượng/lớp thực thể, tìm các thuộc tính chung để hình thành lớp cơ sở. (Ví dụ : Trong hệ thống quản lý thư viện qua WEB: các đối tượng Book, Magazine có một số thuộc tính chung Þ hình thành lớp LibraryItem; Đối với hệ thống đăng ký môn học tín chỉ qua WEB: lớp PeopleInfo là lớp cơ sở của StudentInfo và LecturerInfo; Chương trình vẽ bề mặt địa hình: lớp MapCurve là lớp cơ sở của đường đồng mức Isoquant và đứt gãy Fracture). Giữa lớp cơ sở và các lớp cụ thể có mối quan hệ tổng quát hóa có thể biểu diễn được trong UML.

Biểu diễn lớp cơ sở và quan hệ tổng quát hóa: UML định nghĩa quan hệ tổng quát hoá giữa một lớp tổng quá hơn với một lớp cụ thể hơn: lớp cụ thể hơn có tất cả thuộc tính, tác vụ và quan hệ của lớp kia + những thuộc tính/tác vụ riêng của nó.  Ký hiệu: mũi tên có đầu là một tam giác nhỏ. Lớp tổng quát hơn nằm về phía mũi tên

Nhận diện các mối quan hệ: Sau khi xác định các lớp/đối tương kể cả các đối tượng cơ sở, các quan hệ giữa các lớp cần được xác lập. Trong mô hình phân tích các đối tượng/lớp có quan hệ với nhau.  Một số quan hệ mà UML hỗ trợ ( Tổng quát hoá (generalization); Liên kết (association); Bao gộp (aggregation)).  Các quan hệ khác được áp dụng cho mô hình thiết kế( Phụ thuộc (dependency); Cụ thể hoá (realization))

Quan hệ liên kết: Quan hệ liên kết là mối quan hệ giữa 2 đối tượng/lớp. Về ý nghĩa và ký hiệu giống như quan hệ liên kết trong mô hình nghiệp vụ. Áp dụng cho 2 lớp có mối tương quan mang ý nghĩa nhất định. Chú ý ghi rõ (nếu có thể được) :  Bậc và tên vai trò của mỗi lớp trong quan hệ và  Tên của chính quan hệ liên kết. Dựa vào mô hình nghiệp vụ xác định các mối quan hệ liên kết

Quan hệ bao gộp: UML định nghĩa quan hệ bao gộp là trường hợp đặc biệt của quan hệ liên kết, khi mà một đầu nối liên kết trở thành đầu nối bao gộp (aggregation). Lớp ở đầu nối bao gộp sẽ bao hàm lớp kia.Ký hiệu của đầu nối bao gộp là một hình thoi tô hoặc không tô đen.Có hai dạng bao gộp :  Chia xẻ (shared): chia xẻ giữa các bao gộp khác nhau và  Hoàn toàn (composite): sở hữu đầy đủ. Xác lập các mối quan hệ bao gộm và biểu diễn chúng lên lược đồ lớp.

Xây dựng lược đồ lớp: Lược đồ lớp (class diagram) biểu diễn cấu trúc của một số lớp và quan hệ giữa chúng à mô tả khía cạnh tĩnh (static) của hệ thống.Hệ thống phức tạp có nhiều lớp à cần xây dựng nhiều lược đồ lớp, mỗi lược đồ mô tả một phần của hệ thống.Lược đồ lớp được bổ sung và hoàn thiện trong mô hình thiết kế (thêm một số lớp, chi tiết các thuộc tính và tác vụ, làm rõ các quan hệ).Lược đồ lớp được xây dựng qua các bước : Xác định các lớp;Xác định thuộc tính và tác vụ của các lớp;Xác định các lớp cơ sở và quan hệ tổng quát hoá;Xác định các quan hệ liên kết và bao gộp.

Thiết lập Paclkage: Package là một cơ chế để tổ chức các phần tử vào các nhóm có liên hệ về ngữ nghĩa với nhau . Package có thể import các phần tử từ một package khác. Có thể chỉ ra quan hệ giữa các package : Phụ thuộc và  Tổng quát hoá. Mức độ truy xuất của package : Private: chỉ nó và các package import nó có thể truy xuất nội dung; Protected: giống như private nhưng cho phép thêm các package dẫn xuất; Public: các package khác có thể truy xuất nội dung; Implementation: không cho phép import, có thể áp dụng cho các phần tử bên trong package. UML cho phép biểu diễn các PACKAGE và các mối quan hệ PACKAGE

            Tổng kết : Phân tích hệ thống theo OOP trên UML chia làm 2 bước:Thu thập yêu cầu bằng mô hình nghiệp vụ và Phân tích và xác định tính năng hệ thống bằng mô hình phân tích.  Mô hình phân tích nhận diện các đối tượng/lớp: thực thể, biên, điều khiển. Nhận diện các thuộc tính và một số tác vụ, tuy nhiên chưa làm rõ hành vi của chúng (à mô hình thiết kế). UML hỗ trợ một số phần tử: lớp, đối tượng, lược đồ lớp, package;

Chương 4: THIẾT KẾ PHẦN MỀM

            Khái niệm :Là quá trình chuyển hóa các đặc tả yêu cầu phần mềm thành 1 biểu diễn thiết kế của hệ thống PM cần xây dựng, sao cho người lập trình có thể ánh xạ nó thành 1 chương trình. Hoạt động chính (Nghiên cứu để hiểu 1 ván đề. Chọn 1 số giải pháp thiết kế và xác định các đặc điểm thô của nó. Mô tả trừu tượng cho mỗi giải pháp thiết kế, các sai sót cần phát hiện và chỉnh sửa trước khi lập tài liệu thiết kế chính thức.)

Vai trò: Là cách duy nhất để chuyển hóa 1 cách chính xác các yêu cầu của khách hàng thành mô hình thiết kế hệ thống phần mềm cuối cùng, và làm cơ sở cho việc triển khai chương trình PM.Là công cụ giao tiếp giữa các nhóm cùng tham gia phát triểm phần mềm, quản lý rủi ro, đạt được PM hiệu quả.Là tài liệu cung cấp đầy đủ các thông tin cần thiết cho để bảo trì HT. Nếu không có TK thì hệ thống không tin cậy -> nguy cơ thất bại cao.  Thiết kế tốt là chìa khóa làm cho PM hữu hiệu

Các khái niệm trong tk phần mềm: Trừu tượng hóa ( chia 3 mức cao nhất: vấn đè cấn thiết được mô tả 1 cách khái quát sd thuật ngữ hướng vđ, mức thấp hơn: hướng tới thủ tục xử lý chi tiết kết hợp các thuật ngũ hướng đến hiện thực, mức thấp nhất: vấn đề được mô tả theo cách có thể hiện thực trục tiếp. Phân làm 3 loại : trừu tượng hóa thủ tục là chuỗi các lệnh lên tiếp thực hiện chức năng nào đó, trừu tượng hóa dữ liệu là tổ hợp dữ liệu mô tả 1 đối tượng dữ liệu.). Tinh chế là làm rõ vấn đề. Tinh chế và trừu tượng hóa là 2 khái niệm bù trừ nhau càng tinh chế thì càng hạ thấp mức trừu tượng hóa.

Các giai đoạn trong thiết kế pm:Thiết kế kiến trúc (Xác định các hệ con tạo nên hệ thống tổng thể và mối quan hệ giữa chúng). Đặc tả trừu tượng(Mô tả trừu tượng các dịch vụ của hệ con). Thiết kế giao diện thành phần, Thiết kế hệ thống giao diện người dùng. Thiết kế thủ tục.

Hình thức biểu diễn : biểu đồ, ngôn ngữ mô tả ctrinh,dạng văn bảng k hình thức hóa.

Mô hình kiến trúc pm: Mô hình kiến trúc tĩnh(các hệ con hay các thành phần được phát triển độc lập). mô hình tiến trình động (hệ thống được tổ chức thành các tiến trình vận hành). Mô hình giao diện (xác định giao diện đưa ra các dịch vụ). Mô hình liên kết(chỉ ra mối liên kết giữa các hệ con hay giữa các thành phần)

Trong hệ thống các hệ con cần trao đổi dữ liệu với nhau để làm việc hiệu quả. Có 2 cách để tổ chức thực hiện:  Mô hình kho dữ liệu – tổ chức dữ liệu tập trung (Tất cả các dữ liệu chia sẻ được lưu trữ tại kho trung tâm, các hệ con đều có thể truy cập.Thích hợp với ứng dụng khi DL của các hệ con sinh ra độc lập và có thể sử dụng lại). Mô hình server/client –tổ chức dữ liệu phân tán(Dữ liệu và xử lý được phân bổ trên các máy khác nhau,Thành phần chính bao gồm(Các máy dịch vụ - cung cấp dịch vụ cho hệ con khác,Các máy khách gọi để sử dụng dịch vụ từ các máy dịch vụ.

 Mạng liên kết cho phép máy khách truy cập đến máy d/ vụ)

Tiến trình thiết kế giao diện(giao tiếp)

Các hoạt động: bắt đầu với việc tạo ra các mô hình khác nhau về chức năng hệ thống. Phác họa ra các nhiệm vụ hướng con người và máy tính để đạt tới chức năng hệ thống. Xem xét các giải pháp t/kế được áp dụng cho mọi t/kế giao diện. Sử dụng các công cụ làm bản mẫu. Cài đặt cho mô hình t/kế và đánh giá kết quả về chất lượng.

Các mô hình thiết kế: Mô hình TK do KS PM xây dựng: tổ hợp b/diễn dữ liệu, k/trúc và thủ tục của PM để th/hiện được c/năng. Mô hình người dùng: do KS PM XD, nó mô tả sơ lược hệ thống cho người dùng cuối. Mô hình người dùng cảm nhận hệ thống do người dùng cuối cùng xây dựng. Hình ảnh hệ thống do người cài đặt hệ thống xây dựng, nó tổ hợp các biểu lộ bên ngoài của hệ thống dựa trên máy tính. Phân tích mô hình hóa hệ thống, tương tự như phân tích chức năng các đối tượng nội thất, được áp dụng cho đối tượng con người.

Các bước của tiến trình TK G/diện thực hiện theo các cách: Thiết lập mục tiêu và ý đồ cho nhiệm vụ, Ánh xạ thành dãy các hành động, Xđ dãy hành động khi nó thực hiện ở mức g/diện, Chỉ ra trạng thái của hệ thống, Xđ cơ chế điều khiển. Chỉ ra cách thức cơ chế điều khiển, Chỉ ra cách người dùng diễn giải trạng thái của HT từ thông tin được cung cấp qua giao diện.

Tiến hóa và đánh giá: Sau khi có bản mẫu giao diện người dùng thì phải đánh giá sự đáp ứng nhu cầu NSD. Sử dụng phương pháp làm bản mẫu cho cho tiến trình tiến hóa thiết kế GD NSD. Khi phát triển giao diện chú ý đến các  thuộc tính như: khả năng học, tốc độ thao tác, sự vững chắc, khả năng phục hồi, khả năng thích nghi thường được đánh giá. Một số phương pháp để thu thập thông tin phục vụ việc phân tích đánh giá GD: Làm bảng hỏi điều tra, quan sát người

Tính năng của công cụ tk giao diện: quản lý thiết bị nhấp. Hiệu chỉnh thông tin input. Kiểm soát lỗi và hiển thị thông báo lỗi. Cung cấp trợ giúp và hiển thị thông báo nhắc nhở. Kiểm soát cửa sổ và vùng, khả năng cuộn. Thiết lập giao tiếp giữa chương trình với giao diện (vd: hàm đáp ứng). Cách ly chương trình với các hàm quản lý giao diện. Cho phép tuỳ biến giao diện.

Cách tiếp cần chung và đặc trưng của các phương pháp thiết kế ( Xem xét 3 phương pháp thiết kế : hướng cấu trúc, hướng đối tượng, ht tương tranh). Chiến lược và phương pháp hướng cấu trúc : (Hệ thống được phân chia thành các chức năng, bắt đầu ở mức cao nhất, và được làm mịn dần; Thường có 2 hoạt động độc lập: thiết kế dữ liệu và thiết kế xử lý; 3 cấu trúc chuẩn là tuần tự, chọn và lặp. ).  Chiến lược và phương pháp hướng đối tượng ( Hệ thống được nhìn nhận như 1 bộ các đối tượng tương tác với nhau, đ/tượng gồm d/liệu + thao tác; Một lớp được xác định = thuộc tính+phương thức, có tính kế thừa cao; Các đối tượng liên lạc với nhau bằng các thông điệp; Một số công cụ hỗ trợ mạnh như: Rational Rose, Jbuilder;). Chiến lược thiết kế hệ thống tương tranh: (Được thực hiện với các hệ thống thời gian thực, các tính toán đồng thời; Đảm bảo việc chia sẻ tài nguyên dùng chung; Thường sử dụng phương pháp máy trạng thái hữu hạn làm công cụ biểu diễn thiết kế cho hệ thời gian thực.)

Các tiêu chí thiêt kế: Sự kết dính: Sự kết dính của các thành phần được chia ra theo các mức theo thứ tự tăng dần (kết dính gom góp, kết dính hội hợp logic, theo thời điểm, thủ tục, truyền thông, tuần tự, chức năng, đối tượng). Các mức độ liên độ liên quan giữa các thành phần của 1 modul (Kết dính gom góp : Các phần của thành phần không liên quan với nhau, song lại bị bó vào một thành phần. Kết dính gom góp: Các phần của thành phần không liên quan với nhau, song lại bị bó vào một thành phần.Kết dính hỗn hợp logic: Các thành phần cùng thực hiện chức năng tương tự, chẳng hạn như vào, xử lý lỗi… là được đặt vào trong một thành phần.  Kết dính theo thời điểm: Tất cả các thành phần cùng hoạt hoá một lúc, chẳng hạn như khởi sự và kết thúc… là được bó vào với nhau. Kết dính thủ tục: Các phần tử trong thành phần được ghép lại trong một dãy điều khiển. Kết dính truyền thông: Các phần trong thành phần cùng thao tác trên cùng một dữ liệu và và đưa ra cùng một dữ liệu ra. Kết dính tuần tự: Trong một thành phần, “ra” của phần tử này là “vào” của phần tử khác. Kết dính chức năng: Mỗi phần của thành phần đều cần thiết để thi hành một chức năng nào đó. )

Sự ghép nối : chỉ ra mức độ độc lập giữa các đơn vị thành phần của một chương trình. Có 5 loại kết nối được xếp theo thứ tự từ tốt đến xấu: Ghép nối dữ liệu, ghép nối nhãn, ghép nối điều khiển, ghép nối chung, ghép nối nội dung. Thông thường chúng ta nói đến các hệ thống được module hóa. Sự ghép nối chính là một trong những tiêu chí đánh giá module hóa. Thể hiện mức độ liên kết giữa các module. Kiểu ghép nối trong các hệ thống HĐT (Ghép nối tương tác: Phương thức của lớp này kích hoạt phương thức của lớp khác. Ghép nối thành phần: Các lớp chia sẻ biến hoặc lớp này là tham số phương thức của lớp kia. Ghép nối thừa kế: Lớp này là lớp con của lớp kia.)

Tính hiểu được – liên quan tới các đặc trưng: Tính kết dính, đặt tên, soạn tư liệu, độ phức tạp.

Độ phức tạp thuật toán : Độ phức tạp của thuật toán càng cao thể hiện mối quan hệ giữa các thành phần.  Độ phức tạp của thuật toán chỉ đánh giá một phần độ dễ hiểu của thuật toán, ngoài ra nó còn phụ thuộc vào việc chọn lựa dữ liệu và cách mô tả thiết kế.

Tính thích nghi: được cho quá trình bảo trì – được ghép nối lỏng lẻo: Thuận tiện cho bảo dưỡng và bảo trì hệ thống.

Đánh giá thiết kế tốt : Thiết kế phần mềm được gọi là tốt nếu nó sản sinh ra 1 chương trình tối ưu. Càng chặt chẽ, gọn ngàng và nhẹ càng tốt, đồng thời thiết kế dễ bảo dưỡng thích nghi, bổ sung cải tiến. Dễ đọc, dễ hiểu, các thành phần của thiết kế phải gắn kết với nhau theo một quan hệ logic chặt chẽ.  và Giữa các thành phần của thiết kế được ghép nối một cách dễ dàng.

Giải pháp cho 1 tk tốt: Một thiết kế sẽ tốt nếu thực hiện đúng tiến trình t/kế PM thông qua việc áp dụng các nguyên lý thiết kế cơ bản, các phương pháp luận hệ thống, các công cụ trợ giúp và việc xét duyệt nghiêm túc. Những hướng dẫn cần được vận dụng trong thiết kế (Tổ chức phân cấp. Tổ chức theo các modul.  Biểu diến phân biệt và tách biệt dữ liệu và thủ tục. Hình thành giao diện. Sử dụng lại các thành phần phần mềm đã có)

Nguyên lý thiết kế cần :Cần tính đến mọi cách tiếp cận khác nhau thay vì 1 cách. Có thể lần vết trở lại mô hình hay bước trước đó. Không nên giải quyết vấn đề đã được giải quyết mà nên sử dụng lại. Phải rút ngắn khoảng cách phần mềm và vấn đề tồn tại hệ thực. Thể hiện được tính nhất quán và tích hợp. Cần được cấu trúc để dễ thay đổi. Thiết kế không phải là mã hóa và ngược lại. Cần được theo dõi ngay từ đầu để tránh lỗi. Cần được đánh giá và rà soát chất lượng .

·        Thiết kế pm- phương pháp lập trình cấu trúc : Phân chia Module. Thiết kế dữ liệu Thiết kế kiến trúc. Thiết kế giao diện. Thiết kế thủ tục(xử lý)

Ưu điểm : Quen thuộc; Xây dựng hệ thống thông qua biểu đồ luồn dữ liệu, mô tả việc biến đổi dữ liệu một cách logic. Đây là kết quả hợp nhất của nhiều phương pháp diễn tả dữ liệu vào ra qua một dãy biến đổi. Ngoài ra người ta còn phải xây dựng các bảng biểu dữ liệu, các mỗi liên kết cũng như lược đồ cấu trúc để thể hiện cấu trúc của hệ thống.Nhược điểm:Do chung nhau trạng thái ht nên việc thay đổi một chức năng nào đó thì sẽ ảnh hưởng đến các chức năng khácà Phương pháp này chỉ được sử dụng tốt khi các biến dùng chung, các trạng thái chung ít và phải được xác định một cách rõ ràng.

Phân chia modul: Modul là : Tập hợp của một hay nhiều câu lệnh kế tiếp nhau được đặt tên; Các phần khác trong chương trình có thể kích hoạt với tên được đặt; Có tập hợp các tên biến riêng biệt; Module là một khối đơn các mã lệnh có thể kích hoạt giống như thủ tục, hàm hay phương thức.Cách phân chia modul:Số lượng module phụ thuộc vào độ phức tạp của hệ thống phần mềm cần xây dựng . Quá ít hoặc quá nhiều module đều không tốt

Kiến trúc phần mềm mô tả các thành phần (component) kiến tạo nên hệ thống phần mềm và sự giao tiếp giữa các thành phần đó. Tp có thể là (Các module mã nguồn, Các file thực thi (*.dll, *.exe, *.class...), Các thành phần của kiến trúc hệ thống: ActiveX control, bean..., Các trang HTML, *.asp, *.jsp...

Tiêu chí quan trọng nhất của phân chia module hiệu quả là:

Độ kết dính: Dùng để đo sự phụ thuộc lẫn nhau giữa những tác vụ (task) bên trong của một module. Module có độ kết dính cao nhất khi nó chỉ đảm nhận đúng một tác vụ à kết dính chức năng. Thiết kế kiến trúc phần mềm: cố gắng tăng độ kết dính. Mức độ kết dính: Ngẫu nhiên(các tác vụ không liên hệ với nhau); Logíc( Module thực hiện chuỗi các hành động có liên quan logic với nhau). Nhất thời(các tác vụ phải được thực thi trong một khoảng thời gian nào đó); Giao tiếp(các tác vụ có sử dụng chung một dữ liệu nào đó); Thủ tục(các tác vụ phải được thực hiện theo một trật tự nhất định đúng trình tự của một thủ tục). Chức năng(chỉ thực hiện một tác vụ).

Sự liên kết: Sự liên kết dùng để đo đạc quá trình giao tiếp giữa các module: giao tiếp của module chứa nhiều tác vụ và nhiều thông số gọi thì sự liên kết càng cao. Thiết kế kiến trúc phần mềm: cố gắng giảm sự liên kết. Các mức liên kết :Liên kết nội dung(sử dụng dữ liệu và điều khiển của module khác); Liên kết chung(có sử dụng chung dữ liệu toàn cục);Liên kết ngoại vi(module phụ thuộc vào một I/O nào đó);Liên kết điều khiển(thông số truyền ảnh hưởng đến điều khiển); Liên kết stamp(truyền cấu trúc dữ liệu phức tạp); Liên kết dữ liệu(truyền các thông số đơn giản

Nguyên lý che dấu thông tin:Che dấu thông tin là một trong những nguyên lý quan trọng của việc phân chia module.Các module giao tiếp với nhau bằng những thông tin thật sự cần thiết.Những thông tin về thủ tục và dữ liệu cục bộ của mỗi module phải được che dấu khỏi các module khác. Lợi ích: kiểm soát được thay đổi và sửa lỗi dễ dàng

Các Heuristic trong phân chia module: Sửa lại thiết kế ban đầu để tăng độ kết dính và giảm sự liên kết;Khi chiều sâu tăng, hạn chế fan-out và nên sử dụng fan-in;Giữ cho tầm ảnh hưởng của một module nằm bên trong tầm điều khiển của nó;Loại bỏ dư thừa trong giao tiếp của các module;Ưu tiên các module tất định, hạn chế các module nhiều ràng buộc;Đóng gói các module để đạt được tính khả chuyển (portability)

Thiết kế dữ liệu csdl: Gồm 2 bước: Thiết kế cơ sở dữ liệu logic( gồm các thực thể và quan hệ giữa chúng). Thiết kế CSDL vật lý(Thực hiện trên cơ sở mô hình quan hệ nhận được, lựa chọn hệ quản trị CSDL tiến hành phi chuẩn hóa, thiết kế tệp)

Cấu trúc dữ liệu là thiết kế cơ sở dữ liệu động trong hệ thống. Cấu trúc dữ liệu mô tả sự tổ chức, phương thức truy xuất, mức độ liên kết và các xử lý khác của thông tin. Dữ liệu đơn là dạng cấu trúc dữ liệu đơn giản nhất chỉ bao gồm một phần tử thông tin mà có thể được truy xuất bằng một định danh . Một số dạng phức tạp hơn: vector, ma trận, mảng nhiều chiều, danh sách liên kết, hàng đợi, ngăn xếp, cây nhị phân…Được biểu diễn ở các mức trừu tượng hoá khác nhau.

Một số nguyên tắc: Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất. Chú ý sử dụng từ điển dữ liệu. Trì hoãn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này. Che dấu biểu diễn bên trong của cấu trúc dữ liệu. Phát triển một thư viện các cấu trúc dữ liệu + tác vụ thường gặp

Thiết kế kiến trúc:Gồm 2 bước :Thiết kế xử lý logic(Xuất phát từ luồng DL vật lý, bỏ đi các y/tố vật lý và cấu trúc lại để mô hình vẫn đảm bảo thực hiện đúng các chức năng).Thiết kế kiến trúc modul(Trước hết cần xác định luồng hệ thống từ biểu đồ luồng DL bằng cách chọn các tiến trình máy thực hiện và phương thức thực hiện)

Mục tiêu: là xây dựng sơ đồ phân cấp module từ DFD. Đặt nền móng để thiết kế chi tiết thủ tục và dữ liệu.Phân biệt dòng transform và dòng transaction trong DFD. Thực hiện ánh xạ cho từng vùng của DFD tuỳ theo nó là dòng transform hay transaction(Xác định các module và các mối liên hệ theo DFD quá trình xử lý).

            Thiết kế thủ tục: Là thiết kế thuật giải cho các module đã kiến tạo sao cho có thể dễ dàng mã hoá bằng ngôn ngữ lập trình có cấu trúc. Có thể biểu diễn thuât giải bằng: lưu đồ thuật giải(Flowchart), kí hiệu dạng bảng, ngôn ngữ PDL.

Ngôn ngữ PDL:  vay mượn từ vựng của ngôn ngữ tự nhiên và cú pháp của ngôn ngữ lập trình có cấu trúc. Nó có các tính chất sau(Cú pháp chặt chẽ của các từ khoá hỗ trợ đặc tả cấu trúc, khai báo dữ liệu, phân chia module;  Cú pháp tự do của ngôn ngữ tự nhiên giúp miêu tả xử lý;Phương tiện mô tả dữ liệu đơn cũng như dữ liệu tổ hợp; Cơ chế định nghĩa chương trình con và phương cách gọi)

·        Thiết kế phần mềm UML: gồm lược đồ cộng tác, lược đồ tuần tự, lược đồ trạng thái các lớp/đối tượng, lược đồ hành động, hoàn chỉnh lược đồ lớp.

Ưu điểm: - Dễ bảo trì vì các đối tượng là độc lập. Các đối tượng có thể hiểu và cải biến như là một thực thể độc lập. Thay đổi trong thực hiện một đối tượng hoặc thêm vào các dịch vụ sẽ không làm ảnh hưởng đến các đối tượng hệ thống khác.- Các đối tượng là rất tốt cho việc sử dụng lại (do tính độc lập của chúng). Một thiết kế sau có thể dùng lại các đối tượng đã có trong bản thiết kế trước đó.- Có một vài lớp hệ thống thể hiện phản ánh quan hệ rõ ràng giữa các thực thể có thực (chẳng hạn như các thành phần dùng chung) với các đối tượng điều khiển trong ht. Điều này làm cho thiết kế trở lên dễ hiểu, dễ tiếp cận hơn.

Nhược: khó thực hiện vì khó xđ đtượng của ht.Thường cách nhìn tự nhiên là nhìn chức năng

Mô hình động : Lược đồ lớp chỉ mô tả khía cạnh tĩnh của hệ thống. Hành vi của hệ thống được mô tả bằng mô hình động bao gồm(Tương tác giữa các đối tượng: cộng tác hay trình tự, Trạng thái của đối tượng/lớp, Quá trình hoạt động của lớp/đối tượng )

Tương tác giữa các đối tượng:Đtg tương tác với nhau (interaction) bằng cách gửi/nhận kích hoạt (stimulus). Actor cũng có thể gửi kích hoạt đến đối tượng. Kích hoạt khiến một tác vụ thực thi, một đối tượng được tạo ra hay huỷ đi, hoặc gây ra một tín hiệu.Thông điệp (message)là đặc tả của kích hoạt.Các loại thông điệp (đơn giản, đồng bộ, bất đồng bộ, trả về của gọi hàm).

Sự cộng tác- lược đồ cộng tác:Cộng tác (collaboration) định nghĩa tập hợp các thành phần tham gia và quan hệ giữa chúng.Các thành phần tham gia là vai trò mà đối tượng/lớp đóng vai khi tương tác với nhau. Các vai trò của đối tượng thường chỉ có nghĩa đối với một mục đích nào đó.Lược đồ cộng tác (collaboration diagram) được thiết lập để cụ thể hoá một use-case hoặc một tác vụ . Lược đồ cộng tác là một đồ thị liên kết các vai trò của các đối tượng hình thành nên các chức năng của hệ thống (các usecase).Mỗi cạnh liên kết 2 vai trò được biểu diễn bằng một đoạn thẳng. Tương tác được thể hiện bằng gửi/nhận thông điệp. Hai vai trò liên kết với nhau khi có trao đổi thông điệp. Mỗi thông điệp được thể hiện bằng mũi tên (như đã miêu tả) cộng với phần đặc tả. Lược đồ cộng tác có thể được thiết lập ở một trong 2 dạng( Dạng cụ thể: mỗi vai trò được biểu diễn bằng một ký hiệu của đối tượng cụ thể, các thông điệp được trao đổi trên các đường liên kết. Dạng đặc tả: mô tả các lớp; các đường liên kết được ánh xạ vào các thông điệp). Thiết lập lược đồ cộng tác giúp cụ thể hoá (realize) các use-case và nhận diện thêm một số tác vụ của các đối tượng/lớp ptích

Miêu tả trình tự: Lược đồ cộng tác miêu tả sự tương tác theo khía cạnh không gian. Để nhấn mạnh trình tự của tương tác ta dùng lược đồ tuần tự (sequence diagram).Lược đồ tuần tự miêu tả các đối tượng tương tác với nhau theo thời gian sống của nó.Các thông điệp được trao đổi theo trình tự thời gian.Các mối liên kết không được thể hiện trong lược đồ

Lược đồ tuần tự: có 2 dạng(Dạng tổng quát: thể hiện cả vòng lặp và rẽ nhánh.  Dạng cụ thể: miêu tả một kịch bản cụ thể). Thời gian sống của mỗi đối tượng được mô tả theo một đường thẳng đứng. Thông thường thời gian trôi theo chiều từ trên xuống dưới.Ít khi quan tâm đến khoảng thời gian, thường chỉ quan tâm đến trình tự mà thôi.Thanh hình chữ nhật mô tả sự thực thi của một tác vụ để đáp ứng lại thông điệp gửi đến. Độ dài của thanh chữ nhật phản ánh thời gian thực thi của tác vụ và tính chất lồng nhau (nested) giữa chúng. Các dòng text phụ trợ (mô tả tác vụ, ràng buộc thời gian...) được viết ở lề trái    

Trạng thái của đối tượng:Chuẩn UML đưa ra lược đồ trạng thái để biểu diễn hành vi của một phần tử bất kỳ bằng cách chỉ ra đáp ứng của nó đối với các sự kiện bên ngoài.Thông thường lược đồ trạng thái được áp dụng cho đối tượng/lớp à biểu diễn hành vi của lớp.Trạng thái của mỗi đối tượng (định nghĩa gốc ?) ít nhiều sẽ bị thay đổi trong suốt chu kỳ sống của đối tượng.Tên trạng thái là duy nhất trong lược đồ; có thể không có tên (trạng thái vô danh).Các hành động bên trong: các hành động hoặc tác vụ được thực hiện khi đối tượng nằm ở trạng thái đang xét; có cú pháp như sau: action-label ’/’ action-expression. Một số nhãn hành độc được quy ước (entry: thực hiện hành động tại thời điểm bắt đầu trạng thái;exit: thực hiện hành động tại thời điểm kết thúc trạng thái;do: thực hiện hành động suốt trạng thái hoặc cho đến khi kết thúc nó;include: triệu gọi một máy trạng thái con khác). Các nhãn hành động khác chỉ ra sự kiện kích hoạt hành động tương ứng trong biểu thức hành động (action-expression).Cú pháp của biểu thức hành động (event-name ’(‘ parameter-list ’)’ ’[‘guard-condition’]’ ’/’ action-expression)

Lược đồ trạng thái: kí hiệu(Trạng thái bắt đầu: khi đối tượng được tạo ra hoặc trạng thái tổng hợp được xác định; Trạng thái kết thúc: khi đối tượng bị huỷ bỏ hoặc trạng thái tổng hợp trở nên không xác địnhTrạng thái tổng hợp (composite) được phân rã thành nhiều trạng thái con đồng thời hoặc các trạng thái con loại trừ nhau).

Sự kiện(event) kích hoạt dịch chuyển trạng thái có thể là (Một điều kiện trở nên đúng,chú ý khác với guard-condition.Một đối tượng nhận tín hiệu từ đối tượng khác.Một phép gọi tác vụ. Một khoảng thời gian đã trôi qua kể từ một sự kiện nào đó.

Cú pháp của sự kiện: event-name ’(’ parameter-list ’)’ .

Dịch chuyển trạng thái là quan hệ giữa hai trạng thái theo đó đối tượng đang ở trạng thái thứ nhất sẽ chuyển sang trạng thái thứ hai đồng thời sẽ thực hiện một số hành động khi sự kiện tương ứng xảy ra và thoả mãn một số điều kiện nhất địn.  Được ký hiệu như một mũi tên hướng từ trạng thái nguồn đến trạng thái đích và được gán nhãn. Nhãn có cú pháp: event-signature ’[’ guard-condition ’]’ ’/’ action-expression

Lược đồ hoạt động:  Lược đồ hoạt động (activity diagram) là một biến thể của lược đồ trạng thái trong đó trạng thái là sự thực thi một hành động và sự dịch chuyển được kích hoạt khi hành động hoàn tất. Được dùng để mô tả một thủ tục hay thuật giải Þ tập trung vào các hành động

Nhận diện 1 số lớp thiết kế: Mô hình thiết kế phần nào Mô hình thiết kế phần nào chịu ảnh hưởng từ ngôn ngữ lập trình, thư viện hỗ trợ, framework, hệ điều hành và loại máy tính.  Một số lớp sẽ xuất hiện khi áp dụng những yếu tố trên( Ngôn ngữ lập trình: template, CObject...; Thư viện hỗ trợ: lớp Date, Time, List, Map, vector, iostream…; Framework: Applet, Panel, CDocument, CView, HttpServlet…; Hệ điều hành: các lớp thao tác file, mở cầu nối network, các phần tử giao diện….). Một số lớp khác xuất hiện làm chức năng duyệt (iterate) một lớp khác hay thực hiện các tính toán phức tạp...Sử dụng trực tiếp các lớp do thư viện hay ngôn ngữ cung cấp, hoặc  Tạo ra lớp mới bằng cách thừa kế hay tích hợp các lớp có sẵn, Bổ sung các lớp mới vào lược đồ lớp đồng thời cập nhật các mối quan hệ mới (bao gộp, phụ thuộc).Đặc tả chi tiết các thuộc tính: Trong mô hình phân tích cần phải chỉ rõ kiểu (hoặc cấu trúc dữ liệu) và mức độ truy xuất của các thuộc tính. Có thể chọn một lớp cung cấp bởi thư viện lập trình để cụ thể hoá kiểu hay cấu trúc dữ liệu à bổ sung lớp của thư viện và quan hệ bao gộp vào lược đồ lớp.Nhận diện chính xác các tác vụ: Các lược đồ mô tả hành vi (cộng tác, tuần tự, trạng thái, hành động) giúp nhận diện chính xác các tác vụ của các lớp. Dựa vào các thông điệp hay hành động để xác định signature của các tác vụ.Ví dụ: nhận diện một tác vụ của lớp Database : fetchStudent( code: Long ): StudentInfo; setReg( reg: Registration );

            Hoàn chỉnh lược đồ lớp: Cập nhật các lớp mới, thuộc tính, tác vụ và các mối quan hệ mới. UML định nghĩa quan hệ phụ thuộc (dependency) giữa 2 lớp hoặc package: thay đổi ở một lớp, package kéo theo thay đổi ở lớp, package kia. Ký hiệu của quan hệ phụ thuộc là mũi tên đứt nét: lớp, package ở phía đuôi mũi tên phụ thuộc vào lớp, package phía đầu mũi tên. Một số stereotype quy ước trước: <<call>>, <<instantiate>>, <<import>>, <<refine>>, <<realize>>, <derive>>,<<trace>>

Packet : Chú ý sử dụng package để tổ chức các phần tử liên quan với nhau: các lớp về bản đồ địa hình, về thông tin sinh viên/giảng viên, về cửa sổ giao diện, về các servlet…; Các package thể hiện kiến trúc phần mềm, thông thường chịu ảnh hưởng từ framework (Document/View, 3-tiers...); Mỗi package chứa một hoặc một vài lược đồ lớp, trong đó có thể tham chiếu đến một số lớp thuộc các package khác.

Thiết kế hệ thống thời gian thực

Tiến trình hệ thống thời gian thực: Hệ thống thời gian thực là hệ thống mà sự hoạt động đúng đắn của nó phụ thuộc vào kết quả được tạo ra và thời gian kết quả được xuất ra; Thường là hệ thống nhúng;Có thể được xem là hệ kích thích/đáp ứng.Có 2 loại kích thích: Định kỳ và không định kỳ; PM thời gian thực bao gồm(Một thành phần thu thập dữ liệu;Một thành phần phân tích;Một thành phần kiểm soát đáp ứng). Thường gồm các bước(Xác định các tác nhân kích thích mà hệ phải đáp ứng;Với mỗi kích thích tương ứng xác định các ràng buộc;Phân tích các kích thích và quá trình xư lý đáp ứng thành 1 tiến trình song song;Với mỗi cặp kích thích/đáp ứng thiết kế các thuật toán tương ứng;Thiết kế hệ thống lập lịch đảm bảo các quá trình được bắt đầu ở đúng thời điểm thích hợp;Tích hợp ht dưới sự điều khiển của một bộ điều phối thời gian thực.Mô hình hoá máy trạng thái:  Được sử dụng rộng rãi cho việc thiết kế thời gian thực; Gồm một bộ chức năng Khống chế, hàm, dữ liệu; Cái vào gây kích thích, khi đó chuỗi hành vi được kích hoạt và đáp ứng yêu cầu.Bộ điều phối không gian thực:Chịu trách nhiệm quản lý quá trình và định vị tài nguyên trong hệ thời gian thực;Tương tự hệ điều hành trong máy tính với mục đích khái quát hóa;Với các h/thống cần cung cấp dịch vụ liên tục thì cần thêm bộ quản lý cấu hình và bộ quản lý lỗi;Các kích thích tùy theo mức độ quan trọng mà có mức ưu tiên khác nhau, gồm 2 mức(Mức ngắt: Là mức ưu tiên cao nhất;Mức đồng hồ: Mức sau)Hệ giám sát và điều khiển, hệ thu nhận dữ liệu: Hệ giám sát và khống chế là 1 lớp quan trọng của hệ thời gian thực, Nó liên tục kiểm tra các kích thích đầu vào; Hệ giám sát sẽ có hoạt động tương ứng khi có cảm biến ngoại lệ;Thiết kê này dựa trên sự phân tích cụ thể từng cặp kích thích/ đáp ứng của thiết bị giám sát;Hệ thu nhận dữ liệu là lớp khác của hệ thời gian thực. Hệ này thu thập DL từ các cảm biến cho việc phân tích và xử lý nối tiếp nhau.

Chương V: LẬP TRÌNH VÀ TÍCH HỢP

Lập trình là 1 phần đơn giản nhưng mất nhiều thời gian, công sức và chi phí trong các dự án phát triển phần mềm.Các giai đoạn lập kế hoạch, phân tích, thiết kế và quản trị giữ vai trò quyết định thành công hay thất bại của dự án chứ ko phải giai đoạn lập trình.

Cài đặt là một công đoạn trong việc phát triển phần mềm và được xem là một hệ quả tất yếu của thiết kế.: Là giai đoạn chuyển từ thiết kế chi tiết sang mã lệnh, cho ra sản phẩm cuối cùng. Được thực hiện bởi nhiều người. Việc chọn lựa ngôn ngữ lập trình cũng tác động đên độ rủi ro của dự án nên cần đánh giá độ rủi ro này.Lựa chọn ngôn ngữ theo loại phần mềm, theo đặc trưng của ngôn ngữ, theo năng lực và kinh nghiệm của nhóm phát triển, theo yêu cầu của khách hàng…Yêu cầu của giai đoạn cài đặt:Kỹ năng lập trình tốt;Viết mã lệnh chuẩn;Các dạng cài đặt và tích hợp;Lựa chọn trường hợp kiểm thử module;Các phương pháp tạo dữ liệu kiểm thử.

Kỹ năng lập trình tốt: Hiểu rõ ngôn ngữ;Sử dụng tên biến thích hợp và có nghĩa(thống nhất về ngôn ngữ đê đặt tên biến, tên biến rõ ràng …);Tên biến phải được diễn giải ngay từ đầu;Nên có các chú thích bên trong module;Các vấn đề về sử dụng tham số;Mã lệnh dễ đọc, sử dụng các cặp dấu ngoặc, canh đầu dòng;Nên có các dòng trắng để phân biệt các công việc

Viết mã lệnh chuẩn: Thống nhất quy ước đặt tên module, tên biến,…;Nên sử dụng các qui tắc sau(Độ lồng nhau của lệnh if tối đa là 3;Mỗi module có khoảng 35 đến 50 mã lệnh thực thi;Không sử dụng lệnh goto, có thể sử dụng để bắt lỗi);Chịu sự kiểm thử của nhóm SQA;Có khả năng tái sử dụng(Những phần trong đặc tả, hợp đồng, kế hoạch, thiết kê, các module;Một số thiết bị phần cứng liên quan.)

Cài đặt và tích hợp:Nếu việc cài đặt được thực hiện riêng rẽ và sau đó tích hợp lại toàn bộ và được kiểm thử chung → Kết quả sẽ không tốt;Sẽ tốt hơn nếu việc cài đặt và tích hợp được thực hiện song song.

Các cách cài đặt :

Cài đặt và tích hợp từ trên xuống: Nếu module a gọi module b thì a được cài đặt trước b;Nếu khi thêm một module new vào thì chỉ có thể xảy ra lỗi tại các vị trí: module new hoặc giao diện giữa module new và phần còn lại;Các module có thể chia thành 2 dạng: Module logic:Tổ hợp các dòng điều khiển quyết định trong sản phẩm như và Module hoạt động: hoạt động thực sự của sản phẩm.

Cài đặt và tích hợp từ dưới lên:Nếu module a gọi module b thì b được cài đặt trước a;Nếu gặp lỗi ở các module logic thì sẽ khó khăn khi lần vết sửa đổi trở lại trên các module đã thực hiện cài đặt và tích hợp.

Cài đặt và tích hợp hỗn hợp : kết hợp cài đặt từ trên xuống và từ dưới lên.

So sánh các phương pháp cài đặt và tích hợp

Cách tiếp cận

Điểm mạnh

Điểm yếu

Cài đặt trước, tích hợp sau

Không cô lập được lỗi, chậm phát hiện lỗi thiết kế.

Cài đặt và tích hợp trên xuống

Cô lập được lỗi, sớm phát hiện lỗi thiết kế chính

Các module sử dụng lại không được kiểm thử đầy đủ

Cài đặt và tích hợp dưới lên

Cô lập được lỗi,các module sử dụng lại được kiểm thử đầy đủ

Chậm phát hiện lỗi thiết kế chinh

Cài đặt và tích hợp hỗn hợp

Cô lập được lỗi, sớm phát hiện lỗi thiết kế chính, các module sử dụng lại được kiểm thử đầy đủ

Tóm tắt lại các yêu cầu: Cần phải xây dựng chương trình chạy được từ kết qủa của giai đoạn thiết kế; Chọn ngôn ngữ lập trình để cài đặt;Chọn phương pháp cài đặt và tích hợp như thế nào để đạt hiệu quả? ; Chương trình sẽ được cài đặt ra sao trên tài nguyên tính toán ?

Chương 6: BẢO ĐẢM CHẤT LƯỢNG PHẦN MỀM

Sản phẩm phần mềm được gọi là đúng nếu nó thực hiện được chính xác những tiêu chuẩn mà người thiết kế  đặt ra. Để có một đánh giá chính xác về cấp độ đúng của phần mềm, ta phải kiểm tra chất lượng phần mềm.

Kiểm tra dựa trên các yếu tố sau:Độ tin cậy phần mềm;Rà soát phần mềm; Tiêu chuẩn sản phẩm phần mềm; Hồ sơ của sản phẩm phần mềm

Độ tin cậy PM:

Chất lượng phần mềm: là sự đáp ứng yêu cầu về chức năng, sự hoàn thiện và các chuẩn, các đặc trưng mong chờ từ mọi phần mềm chuyên nghiệp.Đảm bảo chất lượng phần mềm gồm nhiều nhiệm vụ liên kết với các họat động chính sau:(Áp dụng các phương pháp kỹ thuật; Tiến hành các cuộc xét duyệt kỹ thuật chính thức (rà soát); Kiểm thử phần mềm; Buộc tôn trọng các chuẩn; Kiểm soat thay đổi; Đo chất lượng; Báo cáo, lưu giữ kết quả)

Độ tin cậy phần mềm: Các lỗi thường gặp (Lỗi chiến lược: ý đồ thiết kế sai; Phân tích các yêu cầu không đầy đủ hoặc lệch lạc; Hiểu sai về các chức năng; Vi phạm nguyên lý đối tượng; Lỗi tại các thủ tục chịu tải, đây là những lỗi nặng; Lỗi lây lan: lỗi được truyền từ chương trình này sang chương trình khác; Lỗi cú pháp: viết sai quy định của ngôn ngữ.); Hiệu ứng phụ: lỗi xảy ra khi một đơn vị chương trình làm thay đổi giá trị của một biến ngoài ý kiến của lập trình viên). Độ tin cậy phần mềm : Là độ đo về mức độ tốt của các dịch vụ mà hệ thống cung cấp. Là hệ số tỉ lệ nghịch với số thất bại của phần mềm. Một số cách đo độ tin cậy phần mềm : Tính xác suất xuất hiện thành công hay thất bại;Đo độ dài khoảng thời gian trung bình giữa hai lần thất bại liên tiếp; Khả năng sẵn sàng hoạt động lại của hệ thống.

Để phát triển phần mềm không có lỗi thì người ta phải tuân theo các yếu tố sau:Phát triển phần mềm dựa trên đặc tả hệ thống chính xác;Phải dựa trên che dấu và bao gói thông tin;Tăng cường việc duyệt lại trong quá trình phát triển phần mềm;Đưa chất lượng lên hàng đầu.

Có một số phần mềm tiềm ẩn 1 số lỗi nhỏ không đáng kể, nhưng rất khó để khắc phục => coi phần mềm không có lỗi. Việc làm này gọi là thứ lỗi.Để thứ lỗi, người ta phải tiến hành một số hành động sau:

            Rà soát phần mềm: Rà soát là việc xem xét, đánh giá sản phẩm được tiến hành mỗi giai đoạn để phát hiện ra những khiếm khuyết cần sửa chữa trước khi sang giai đoạn sau.

Mục tiêu: Chỉ ra các chỗ khiếm khuyết cần phải cải thiện;Khẳng  định những sản phẩm đã đạt yêu cầu;Kiểm soát việc đạt chất lượng kỹ thuật tối thiểu của các sản phẩm.

Các hình thức của hoạt động rà soát. Có nhiều kiểu rà soát khác nhau:Các cuộc họp xét duyệt không chính thức;Cuộc trình bày chính thức trước cử tọa gồm khách hàng, nhà quản lý, nhân viên kỹ thuật. (chỉ tập trung vào các rà soát kỹ thuật chính thức);

            Rà soát kỹ thuật chính thức: Là hoạt động đảm bảo chất lượng phần mềm do những người đang tham gia phát triển phần mềm thực hiện.

Mục tiêu: Phát hiện các lỗi trong chức năng, trong logic, trong triển khai;Kiểm thử sự phù hợp của PM với yêu cầu;Bảo đảm rằng phần mềm phù hợp với các chuẩn đã định sẵn ;Đảm;ảo PM đã được phát triển theo một cách thức nhất quán;Làm cho dự án dễ quản lý hơn;Ngoài ra dùng để làm cơ sở huấn luyện các kỹ sư  trẻ và có ích ngay cả cho những kỹ sư đã có kinh nghiệm.

Tiến trình hoạt động rà soát:

Họp rà soát phần mềm:

Thành phần: Có từ 3 đến 5 người liên quan tới việc rà soát, gồm có:lãnh đạo rà soát, các cá nhân rà soát, người tạo ra sản phẩm được rà soát

Thời gian: Phải có sự chuẩn bị trước, tuy nhiên mỗi người không quá 2 giờ chuẩn bị.

Công việc cần làm: Trọng tâm của các cuộc họp rà soát là về sản phẩm: một thành phần (một thành phần của đặc tả yêu cầu, một thiết kế modul chi tiết, một danh sách mã nguồn cho một modul);Phải đưa ra một trong 3 quyết định sau đây:(Chấp nhận sản phẩm không cần chỉnh sửa;Khước từ sản phẩm vì những lỗi nghiêm trọng;Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải có cuộc họp rà soát lại).Mọi thành viên tham gia cuộc họp phải ký vào quyết định

Phương châm rà soát:Cần thiết lập trước phương châm rà soát, phân phát cho những người làm nhiệm vụ rà soát, thống nhất và tuân thủ. Một rà soát mà không khống chế được thì có thể còn xấu hơn là không rà soát;

            Tiến trình rà soát: Tiến trình phát triển chung nhất gồm 4-5 giai đoạn:Kỹ nghệ hệ thống;Phân tích, xác định yêu cầu phần mềm;Thiết kế phần mềm;Kiểm thử phần mềm;Bảo trì (với sản phẩm đặt hàng).

            Sản phẩm của cuộc họp rà soát là:Báo cáo các vấn đề nảy sinh do các cá nhân rà soát nêu ra;Một danh sách các vấn đề cần giải quyết do cuộc họp thống nhất;Một văn bản tổng kết cuộc họp rà soát đó, văn bản này phải chỉ rõ (Rà soát cái gì?Ai rà soát?Tìm thấy cái gì? và kết luận). Mục tiêu: thẩm định và xác minh yêu cầu phần mềm (Các yêu cầu phải nhất quán, nghĩa là không mâu thuẫn nhau;Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà người dùng đã nhắm đến;Các yêu cầu phải là hiện thực, tức là có khả năng thực hiện được).Nội dung: tập trung vào khả năng viết ra các yêu cầu hệ thống phần mềm (chức năng, phi chức năng, ngoại lai).Sự phù hợp và tính đúng đắn của mô hình phân tích.

Rà soát thiết kế phần mềm:

 Mục tiêu: Hướng đến thiết kế đảm bảo yêu cầu;Phản ánh đúng các yêu cầu đặc tả, đủ các phần, đủ chức năng và ràng buộc, đủ dữ liệu, thuật toán tốt, cấu trúc tốt….

 Nội dung: Rà soát kỹ thuật chính thức cho khâu thiết kế tập trung vào; thiết kế dữ liệu, thiết kế kiến trúc và thiết kế thủ tục;Có 2 kiểu rà soát thiết kế (rà soát thiết kế sơ bộ :đánh giá việc dịch các yêu cầu thành thiết kế dữ liệu và thiết kế kiến trúc và rà soát thiết kế trọn vẹn tập trung vào tính đúng đắn của thuật toán. ).

Danh mục : Rà soát thiết kế sơ bộ :Các yêu cầu phần mềm có được phản ánh trong kiến trúc phần mềm hay không?; Có đạt được sự môđun hoá hiệu quả không? Các môđun có độc lập chức năng hay không; Kiến trúc chương trình có đươc phân tách không?; Các giao diện đã được xác định cho các môđun và các phần tử hệ thống ngoại lai chưa?; Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?; Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm chưa?;Khả năng bảo trì đã được xem xét chưa?; Các nhân tố chất lượng đã được đánh giá rõ ràng chưa? .

Rà soát thiết kế toàn bộ: Thuật toán có hoàn thành chức năng mong muốn không? ; Thuật toán có đúng đắn logic không? ; Giao diện có phù hợp với thiết kế kiến trúc không?;Độ phức tạp logic có phải chăng hay không?; Xử lý sai đã được đặc tả chưa?;Cấu trúc dữ liệu cục bộ có thật sự đã được xác định?;Kiến tạo lập trình cấu trúc đã xuyên suốt chưa?;Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa?;Dùng các đặc điểm hệ điều hành hay là phụ thuộc ngôn ngữ?;Khả năng bảo trì đã được xét tới chưa).

Rà soát việc viết mã phần mềm:

Mục tiêu: rà soát hướng đến mã nguồn đạt được phản ánh đầy đủ, phù hợp với thiết kế;phù hợp với ngôn ngữ sử dụng (chuẩn, cú pháp, khai báo dữ liệu...);Văn bản chương trình tốt (không lỗi chính tả, có cấu trúc, nhất quán ...)

Danh mục: Thiết kế có thực sự được dịch thành mã chưa?Có thực sự dùng các quy ước ngôn ngữ hay không? Có phục tùng về các chuẩn mẫu lập mã đối với phong cách ngôn ngữ, ghi chú ...Có ghi chú nào không đúng đắn hoặc mơ hồ?Kiểu dữ liệu và khai báo dữ liệu có chính xác hay không?Các hằng số vật lý có đúng đắn hay không?Có phải tất cả các khoản mục của danh sách  rà soát thiết kế trọn vẹn là được áp dụng lại hay không?

Rà soát kiểm thử phần mềm

Mục tiêu:Đánh giá một cách phê phán các kế hoạch kiểm thử và các thủ tục kiểm thử; Hướng đến đảm bảo các phương pháp, các chiến lược và các kỹ thuật được sử dụng và có kế hoạch tốt

Nội dung:Chiến lược kiểm thử (từ trên xuống, từ dưới lên); Kỹ thuật kiểm thử: ( kiểm thử hộp đen, kiểm thử hộp trắng, kiểm thử tải trọng, kiểm thử luồn sợi (cho hệ thời gian thực), sử dụng CASE)

     Danh mục:Các pha thử nghiệm chủ yếu có thực sự được định rõ và được xắp xếp tuần tự hay không?Theo dõi các yêu cầu (tiêu chuẩn) có được thiết lập như một phần của pha phân tích yêu cầu phần mềm hay không?Các chức năng chủ yếu có được trình diễn sớm không?Kế hoạch thử nghiệm có phù hợp với kế hoạch dự án tổng thể hay không?Lịch trình thử nghiệm có được xác định rõ ràng hay không?Nguồn lực và công cụ thử nghiệm đã được xác định và đã sẵn sàng hay chưa?Đã thiết lập cơ chế lưu trữ các báo cáo chưa?

            Tiêu chuẩn của sản phẩm phần mềm:

Tiêu chuẩn 1: Tính đúng đắn :Các sản phẩm phần mềm phải thực hiện được chính xác các mục tiêu được đặt ra ở giai đoạn thiết kế, không bị treo máy hoặc ra kết quả sai đối với bộ dữ liệu nằm trong phạm vi yêu cầu; yêu cầu đặt ra phần mềm trước hết phải có thuật toán đúng và chương trình trình phải tương ứng với thuật toán.

Tiêu chuẩn 2: Tính khoa học. Tính khoa học về cấu trúc: Thuật toán và chức năng được xây dựng một cách có cấu trúc. Tính khoa học về nội dung: Thuật toán được xây dựng dựa trên những thành tựu mới của toán học và tin học.  Tính khoa học về hình thức thao tác: Mỗi lệnh của chương trình cần phải được tối ưu. Muốn vậy, các lệnh phải được xây dựng một cách hợp lý, logic và phù hợp với tư duy tự nhiên của người sử dụng. Các lỗi phải được thông báo một cách rõ ràng.

 Tiêu chuẩn 3: Tính hữu hiệu. Thể hiện ở các mặt sau:+ Hữu hiệu về kinh tế: Có giá trị kinh tế hoặc có ý nghĩa giá trị thu được khi áp dụng sản phẩm đó.+Hữu hiệu về tốc độ xử lý: Có số lượng lớn các đối tượng được xử lý trong một đơn vị thời gian.+ Hữu hiệu về dung lượng bộ nhớ: Tốn càng ít càng tốt.

Tiêu chuẩn 4: Tính sáng tạo.Sản phẩm phải mới mẻ và độc đáo.

 Tiêu chuẩn 5: Tính an toàn.Sản phẩm phần mềm phải có cơ chế bảo mật chống xâm phạm, sao chép trộm và làm biến dạng chương trình.Có cơ chế bảo vệ đối tượng mà nó phát sinh và quản lý, có cơ chế hồi phục khi có sự cố.

 Tiêu chuẩn 6: Tính đầy đủ và toàn vẹn Sản phẩm thực hiện được đầy đủ yêu cầu của khách kh.

Tiêu chuẩn 7: Tính độc lập với các thiết bị. Sản phẩm có thể sử dụng trên nhiều loại máy khác nhau và sử dụng nhiều các thiết bị đi kèm khác nhau. Độc lập cả với cấu trúc của đối tượng mà nó phát sinh ra.

Tiêu chuẩn 8: Tính phổ dụng. Có thể sử dụng được rộng rãi trong nhiều lĩnh vực và ở nhiều chế độ làm việc.

Tiêu chuẩn 9: Tính dễ học và dễ sử dụng, cải tiến.Sản phẩm hợp với yêu cầu người dùng về ngôn ngữ, hệ thống các chức năng,các thông báo, cú pháp đơn giản, rõ ràng, dễ thao tác, dễ tăng cường các chức năng, dễ mở rộng và cải tiến.

Hồ sơ của sản phẩm phần mềm

Phải có chương trình nguồn, chương trình đích để trên đĩa.: + Đính kèm các phần mềm tiện ích có liên quan.+ Các bản in chương trình nguồn, trên đó có lời giải thích rõ ràng để tiện cho việc chứng minh tính đúng đắn của chương trình.+ Bản mô tả các thuật toán của chương trình.+ Bảng hướng dẫn sử dụng chi tiết, các lỗi có thể có và cách xử lý lỗi.+ Các thông số đặc trưng của chương trình, các thông tin về sản phẩm: tên đầy đủ, tên vắn tắt, số hiệu phiên bản, ngày tháng thiết kế và cài đặt, các chức năng của hệ thống, chế độ làm việc (hộp hội thoại, menu, …).+ Cấu hình tối thiểu của hệ thống, các thiết bị đi kèm. Cấu hình tối đa sử dụng hết công suất của sản phẩm.+ Cơ chế bảo mật và một số phần mềm tương thích.

Chương 7: KIỂM THỬ PHẦN MỀM

Xác minh và thẩm định phần mềm là 1 quá trình liên tục và xuyên suốt mọi giai đoạn của quá trình phần mềm, xác  minh và thẩm định là từ chung cho các quá trình kiểm tra để đảm bảo phần mềm thỏa mãn các yêu cầu của chúng là thỏa mãn người dùng . Xác minh và kiểm thử có 2 mục tiêu :Phát hiện các khuyết tật trong hệ thống; Đánh giá xem hệ thống liệu có dùng đc hay ko?

 Sự khác nhau giữa xác minh và thẩm định :Thẩm định: Xem xét cái được xây dựng có là sản phẩm đúng không? Tức làkiểm tra xem chương trình có được như mong đợi của người dùng hay không.; Xác minh: Xem xét cái được xây dựng có đúng là sản phẩm không? Nhưthế, xác minh là kiểm tra chương trình có phù hợp với đặc tả hay không.

Tại sao phải kiểm thử phần mềm ? Kiểm thử phần mềm là yếu tố quyết định chất lượng phần mềm và khâu điển hình của rà soát đặc tả thiết kế và lập mã

Lý do cần kiểm thử phần mềm: Muốn nhìn thấy phần mềm như là một phần tử của hệ thống hoạt động;Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này.    

Mục tiêu của kiểm thử phần mềm là tìm ra lỗi (nếu có) với chi phí thấp nhất. Theo Glen Myers: *) Kiểm thử là một quá trình vận hành chương trình để tìm ra lỗi.Một ca kiểm thử thắng lợi là phải làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ.

 Kiểm thử phần mềm giúp:Phát hiện được lỗi trong chương trình (nếu có).Chứng minh phần mềm hoạt động đúng như đã thiết kế.Chứng minh phần mềm được viết đúng Chứng minh phần mềm đáp ứng yêu cầu của user.Góp phần chứng minh chất lượng của phần mềm.

Phân loại kiểm thử :Thử thống kê :cho nhiều bộ dữ liệu khác nhau để chạy thử và tính tần suất thất bại. Thử khuyết tật : cho những dữ liệu thật đặc biệt để chạy thử , phép thử thành công nếu phơi đc nhiều khuyết tật. Thử giới hạn : tăng dần tải cho tới khi không chịu đc

Ca kiểm thử : Một ca kiểm thử tốt: là ca kiểm thử có xác suất cao trong việc tìm ra một lỗi chưa được phát hiện.Một ca kiểm thử thành công: là một ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa được phát hiện

Biểu đồ dòng thông tin kiểm thử

(1) Cấu hình phần mềm: Bản Đặc tả yêu cầu phần mềm, bản Đặc tả thiết kế, chương trình gốc

(2) Cấu hình kiểm thử: Kế hoạch và thủ tục kiểm thử, các công cụ kiểm thử dự định dùng, các ca kiểm thử cùng kết quả dự kiến.

Kỹ thuật kiểm thử :

Kiểm thử hộp trắng:Đối với cách test Black Box Testing thì chỉ quan tâm dến giá trị đầu vào và giá trị đầu ra có đúng không mà không quân tâm đến code bên trong ra sao.Nhưng đối với cách test White Box Testing  không nhửng kiểm tra giá trị đầu vào và đầu ra mà còn test dựa trên code của chương trình.Phương pháp test này kiểm tra chặt chẻ hơn , tạo ra các trường hợp thử nghiệm để thực hiện chương trình 1 cách logic hơn., thường dùng cho những những module nhỏ.

Kiểm thử các đường độc lập cơ bản , bảo đảm số phép thử là ít nhất đủ để phát hiện lỗi;Tất cả các đường thực thi độc lập được qua ít nhất 1 lần ;Thử các điều kiện rẽ nhánh ở 2 nhánh : true và false;Thử qua vòng lặp tại biên cũng như bên trong;Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó

 Có 2 loại test White Testing: Control Flow : Là việc test dựa vào các lệnh trong cách ngôn ngử lập trình như lệnh tuần tự,lệnh rẽ  nhánh(như if... else...) ,vòng lập (for, while, loop…).

 Data Flow Là tập trung vào kiểm tra giá trị của các biến trong chương trình Biến sẽ xuất hiện theo 2 dạng: khai báo và gán giá trị Biến sẽ được sử dụng theo 2 cách: predicate (kiểm tra điều kiện) và computational (tính toán) .

*** chú ý : kiểm thử viên hiểu rõ cấu trúc bên trong mã nguồn.thực hiện kiểm thử sự đúng đắn của mã nguồn.thường được sử dụng để thẩm định.

Kiểm thử hộp đen: Là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao,bao gồm các đặc tả yêu cầu(requirements), các sự kiện(events). Phương pháp này thường dùng để test chức năng của chương trình. 

Kiểm thử hộp đen tìm  các lỗi thuộc nhóm sau : Hàm không có hoặc không đúng ;Lỗi giao diện ;Lỗi trong cấu trúc dữ liệu được sử dụng bởi các giao diện;Lỗi hiệu năng hoặc lỗi hành vi;Lỗi bắt đầu và lỗi chấm dứt.

Các phương pháp testing phổ biến :Phương pháp phân đoạn tương đương (Equivalence Class Partitioning):Chia dữ liệu vào thành các đoạn, mỗi đoạn đại diện cho một số dữ liệu vì vậy việc kiểm thử chỉ thực hiện trên đại diện đó.Mục đích làm giảm số lượng test bằng cách chọn các tập dữ liệu đại diện.Phương pháp này thường được dùng để test các yêu cầu ở mức trừu tượng hơn là test theo trường.Áp dụng để test màn hình,menu hay test mức quá trình. Phương Pháp Phân Tích Giá Trị Biên (Boundary Value Analysis) : Là trường hợp riêng của phương pháp phân đoạn tương đương (Equivalence.Partitioning).Phương pháp này thường dùng để test giá trị biên của các giá trị đầu vào, các miền giá trị. Thường sử dụng để test module chức năng của chương trình.Kỹ Thuật Cause-Effect Graphing : đối với kỹ thuật Cause-Effect Graphing  cho phép xác định ra các trường hợp kiểm thử hiểu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loài thành các lớp Kỹ thuật này gồm 4 bước như sau : Xác định Cause ( điều kiện nhập vào) và effect ( là hành động) cho mổi một module cần kiểm định;  Xây dựng đồ thị cause-effect; Đồ thị được chuyển thành bảng quyết định; Những phần/luật trong bảng quyết định được chuyển thành các trường hợp kiểm thử.

Ưu điểm của kiểm thử hộp đen là khả năng đơn giản hóa việc kiểm thử tại các mức độ được đánh giá là khó kiểm thử. 

Nhược điểm của kiểm thử hộp đen là khó đánh giá nhửng giá trị nào chưa được kiểm thử hay không. kiểm thử viên không cần (không nên) biết mã nguồn.( nên không nhất thiết phải là lập trình viên).Mã nguồn như 1 hộp đen đối với họ.Họ chỉ biết đưa vào hộp đen cái gì và hộp đen sẽ trả ra ngoài cái gì.

Sự khác biệt giữa kiểm thử hộp đen và hộp trắng :

Chiến thuật kiểm thử phần mềm :tích hợp các phương pháp tạo ra test-case trở thành một chuỗi các bước có thứ tự để có thể kiểm thử  phần mềm thành công với chi phí thấp.Bao gồm các công việc:  Lập kế hoạch kiểm thử ; Sinh test-case; Thực hiện kiểm thử , thu thập kết qủa và đánh giá; Xác minh : các hành động để đảm bảo cho phần mềm được thực thi đúng theo 1 chứu năng cụ thể nào đó;Thẩm định : các hành động để đảm bảo cho phần mềm được xây dựng theo đúng yêu cầu của khách hàng

Một chiến thuật kiểm thử phổ biến : gồm Phát triển(Phân tích toàn bộ hệ thống ;Phân tích yêu cầu ;Thiết kế;Lập trình ) .Kiểm thử gồm (Kiểm thử đơn vị ;Kiểm thử tích hợp ;Kiểm thử tính năng ;Kiểm thử toàn bộ hệ thống)

Kiểm thử từng module :Tiến hành kiểm thử  trên từng đơn vị nhỏ nhất của phần mềm, đó là module mã nguồn, sau khi đã thiết kế, mã hoá và biên dịch thành công

Thường dùng kỹ thuật kiểm thử  white-box;Có thể tiến hành kiểm thử  cùng lúc nhiều module;Một số vấn đề trong việc xây dựng các test case;Test case nào?Dữ liệu đầu vào và đầu ra có tử đâu?Tính độc lập/phụ thuộc hoạt động của các module;Mỗi module mã nguồn không phải là một chương trình hoàn chỉnh và đôi khi phải gọi các module chưa được kiểm thử  khác à có thể phải thiết lập driver và/hoặc stub: phí tổn khá lớn (70%)

Kiểm thử tích hợp :Từng module mã nguồn đã hoạt động đúng. Liệu khi kết hợp chúng lại thành một nhóm lớn chúng có hoạt động đúng không?

Phải tiến hành kiểm thử  tích hợp để phát hiện lỗi liên quan đến giao tiếp giữa các module; Tránh tích hợp kiểu big-bang: tất cả các module được kết hợp lại, và toàn bộ chương trình sẽ được kiểm thử  một lúc;Nên tích hợp tăng dần: từ trên xuống hoặc từ dưới lên;Module chính được dùng như là driver, và stub được thay thế bởi các module con trực tiếp của của module chính nàyTuỳ thuộc vào cách tích hợp theo chiều sâu (depth-first) hoặc chiều ngang(breath-first), mỗi stub con được thay thế một lần bởi module tương ứng đã kiểm thử ;Tiến hành kiểm thử  khi có sự thay thế mới;Tiến hành kiểm thử  hồi quy để phát hiện các lỗi khác trong từng module ;Gồm có : Tích hợp từ trên xuống và Tích hợp từ dưới lên

Kiểm thử hồi quy :Việc kết hợp các module lại với nhau có thể ảnh hưởng đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module.

Điều đó làm lộ ra một số lỗi không thể phát hiện được khi tiến hành kiểm thử  theo đơn vị nên  Phải kiểm thử  hồi quy khi tích hợp

Kiểm thử  hồi quy có thể được tiến hành thủ công bằng cách thực hiện lại các test-case đã tạo ra. Hoặc có thể dùng một công cụ capture-playback để thực hiện tự động.

Kiểm thử tính năng : hiểu theo cách đơn giản nhất là: kiểm tra các chức năng của phần mềm đáp ứng được nhu cầu của khách hàng đã được xác định trong văn bản đặc tả yêu cầu của phần mềm.  Áp dụng kỹ thuật black-box

Kiểm thử  tính năng bao gồm:  Xem xét lại cấu hình phần mềm theo lược đồ triển khai; Kiểm thử  alpha; Kiểm thử  beta

Kiểm thử hướng đối tượng :  về cơ bản giống thứ tự như kiểm thử cổ điển :

Không thể tách rời từng tác vụ của đối tượng/lớp để kiểm thử ; Tác vụ được đóng bao trong lớp; Các lớp con có thể override một tác vụ nào đó;Kiểm thử  đơn vị hướng đối tượng tập trung vào các lớp à kiểm thử  hành vi của lớp

Kiểm thử theo kịch bản: dựa vào các use – case để soạn ra các kịch bản

Nghệ thuật gỡ rối : gỡ rối là 1 quá trình nhằm loại bỏ các lỗi được phát hiện trong quá trình kiểm tra .Gỡ rối được thực hiện như là một kết quả của việc kiểm tra: lỗi phát hiện được à tìm kiếm nguyên nhân à sửa lỗi.  Có 3 hình thức gỡ rối:Brute force : là phương pháp phổ biến nhất nhưng lại hiểu quả nhất Triết lý của phương pháp này là : hãy để máy tính tìm ra lỗi Loại trừ nguyên nhân  : dưạ trên nguyên tắc chia nhị phân; Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên nhân có thể gây ra lỗi;  Danh sách này được thử  lại để loại bỏ dần các nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất;  Khi đó dữ liệu kiểm thử  sẽ được tinh chế lại để tiếp tục tìm lỗi  và theo vết: Là 1 phương pháp gỡ lỗi phổ biến , cách thực hiện : bắt đầu từ dòng mã nguồn có triệu chứng lỗi thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm được thấy dòng gây ra lỗi . Nên dùng kết hợp cả 3 hình thức này.

Các lỗi có thể mắc trong thiết kế và cài đặt phần mềm :Lỗi thứ 1 : lỗi về ý đồ thiết kế sai: Đây là lỗi nặng nhất. Hệ thống mà chúng ta xây dựng sẽ không thể đáp ứng được yêu cầu của khách hàng.Lỗi thứ 2 : lỗi phân tích các yêu cầu không đầy đủ hoặc sai lệch :Đây là lỗi cũng thường xảy ra. Thực tế cho thấy, những người làm chuyên môn thì không hiểu sâu về tin học nên không cung cấp được những thông tin cần thiết cho những người làm tin học. Ngược lại, những người làm tin học là không hiểu hết về chuyên môn nghiệp vụ của khách hàng. Do vậy mà việc thu thập thông tin sẽ không đầy đủ hoặc thiếu chính xác. Chính vì vậy mà dễ mắc lỗi. Lỗi thứ 3 : lỗi hiểu sai chức năng :Đây là lỗi thường hay mắc phải do trong hệ thống có thể có các chức năng hay lĩnh vực có tính chuyên môn cao. Các từ chuyên ngành. Dẫn đến khó hiểu đối với nhà phát triển phần mềm. Lỗi thứ 4 :lỗi bỏ sót các chức năng :. Lỗi này các nhà phát triển phần mềm cũng hay mắc phải, do điều kiện thời gian và chuyên môn có hạn, đôi khi các chức năng không thể được đưa ra một cách đầy đủ.Lỗi thứ 5 : lỗi tại các đối tượng chịu tải:Lỗi xảy ra tại các hàm hoặc các thủ tục cấp thấp xây dựng lên các thủ tục khác. Lỗi này cũng là một lỗi nặng, có thể kéo theo sai xót ở một loạt các hàm hoặc thủ tục khác. Lỗi thứ 6 :lỗi lây lan :Đây là lỗi do virus có thể lây từ chương trình này sang chương trình khác.Lỗi thứ 7 : lỗi cú pháp: Lỗi này sinh ra do việc viết sai các quy định về văn phạm. Lỗi thứ 8 : lỗi do hiệu ứng phụ :Lỗi xảy ra do việc sử dụng hàm, thủ tục hay chương trình con, có các phép tính biến đổi chương trình con nằm ngoài ý muốn của người lập trình.

Chương 8: QUẢN LÝ DỰ ÁN

Dự án: Là một tập hợp các công việc, được thực hiện bởi một tập thể nhằm đạt được một kết quả dự kiến, trong một thời gian dự kiến, với một kinh phí dự kiến. Trong đó, 4 yếu tố không thể thiếu của dự án :Tập thể thực hiện dự án: nguồn nhân lực, mỗi người có chuyên môn và năng lực nhất định. Thời gian dự kiến thực hiện dự án: Ngày bắt đầu, ngày kết thúc, thời điểm trung gian ứng với kết quả trung gian.Kết quả dự kiến: Sản phẩm sau cùng của dự án, phải hình dung và mô tả được. Kết quả có đặc tính/đặc điểm gì, giá trị sử dụng như thế nào? hiệu quả ra làm sao?. Kinh phí dự kiến: tiền để thực hiện dự án. Người (hoặc đơn vị) cấp tiền (cấp vốn) được gọi là chủ đầu tư.

Nội dung cơ bản của các dự án đó đều xoay quanh:Phần cứng; phần mềm.  Sự tích hợp giữa phần cứng/phần mềm và con người. Mục tiêu của dự án:Sản phẩm cuối cùng của dự án đáp ứng các yêu cầu của người dùng, đảm bảo thời gian và kinh phí không vượt quá 10-20% dự tính ban đầu; Người dùng hài lòng với quá trình thực hiện dự án, thực sự tham dự và góp phần công sức của mình trong các hoạt động của dự án. Đặc biệt đối với các dự án ứng dụng CNTT, vai trò của những cán bộ nghiệp vụ trong việc xác định yêu cầu, phân tích quy trình, thông tin... tại chính đơn vị của mình là rất quan trọng; Các cấp quản lý phía trên của dự án (BCĐ CNTT, Bộ Tài chính...) được cung cấp đầy đủ thông tin về tình hình thực hiện dự án. Phương pháp và kĩ thuật quản lí dự án: Áp dụng các kiến thức, kỹ năng, công cụ và kỹ thuật để thực hiện mục đích quản lý nêu trên;Trong suốt vòng đời của dự án, các công việc ở mỗi giai đoạn phải bao hàm những nội dung chủ yếu sau: (Xác định rõ các yêu cầu về phạm vi, thời gian, chi phí, rủi ro, chất lượng; Phân công, đôn đốc, theo dõi và kiểm tra các thành viên trong đội dự án). Nhóm thành viên sản xuất phần mềm: Người chủ nhiệm đề tài ; Người phân tích thiết kế hệ thống ;Người phụ trách phần cứng ;Người phụ trách phần mềm ;Các lập trình viên;Những người phụ trách marketing. Tiến trình quản lí dự án: