Đề cương công nghệ phần mềm

I. Giới thiệu chung về Công nghệ phần mềm

1. Khái niệm phần mềm, Công nghệ phần mềm, nguyên nhân ra đời của Công nghệ phần mềm?

a, khái niệm phần mềm

- Phần mềm máy tính là sản phẩm do kỹ sư phần mềm thiết kế và xây dựng, bao gồm các yếu tố sau:

+ Các chương trình máy tính (các tập lệnh) cung cấp các chức năng mong muốn cụ thể nào đó,

+ Các cấu trúc dữ liệu trợ giúp chương trình thao tác với thông tin, và

+ Các tài liệu mô tả hoạt động cũng như sử dụng chương trình.

- Phần mềm là đối tượng logic, không giống như là phần cứng:

+ Việc phát triển phần mềm không theo cách thức truyền thống của sản phẩm

+ Phần mềm không bị hỏng hóc theo thời gian

+ “Custom-built”

b, khái niệm công nghệ phần mềm

- Công nghệ phần mềm là một 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 một sản phẩm phần mềm đạt được các yêu cầu sau một 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ị.

- Công nghệ phần mềm là sự thiết lập và sử dụng các nguyên lý kỹ thuật đúng đắn để xây dựng các phần mềm một cách kinh tế, tin cậy, và có thể làm việc trên mọi máy tính

c, nguyên nhân ra đời của Công nghệ phần mềm

Vào những năm 1950 khi mt ra đời chính thức (k chỉ đc dùng trong các phòng thí nghiệm mà bắt đầu ứng dụng trong các hđ xã hội) các pm đầu tiên cũng đc ra đời với số lượng còn rất ít ỏi và chủ yếu phục vụ cho lĩnh vực tính toán (đặc biệt trong quốc phòng).

          Đến những năm 1960, trải qua 10 năm phát triển số lượng các pm đã tăng lên rất nhiều và đc ứng dụng rất rộng rãi trong nhiều lĩnh vực. Vào thời điểm này phát sinh 1 số vấn đề mà các chuyên gia gọi là “cuộ khủng hoảng pm”. Cuộc khủng hoảng pm thể hiện 2 yếu tố chính:

- số lượng các pm tăng vọt (do sự phát triển của phần cứng: tăng khả năng, giá thành hạ).

- có quá nhiều khuyết điểm trong các pm đc dùng trong xã hội:

+ thực hiện k đúng yêu cầu (tính toán sai, k ổn đinh, …)

+ thời gian bảo trì, nâng cấp quá lâu, tốn chi phí cao, hiệu quả thấp.

+ khó sử dụng.

+ thực hiện chậm.

+ khó chuyển đổi dữ liệu giữa các pm.

          Để giải quyết vấn đề trên, 1 hội nghị đã đc triệu tập để bàn về cách giải quyết. Hội nghị đã tiến hành xem xét, phân tích và xác định nguyên nhân gây ra cuộc khủng hoảng pm. Kết luận như sau:

- việc tăng vọt của số lượng pm là điều hợp lý và điều này sẽ còn tiếp diễn.

- các khuyết điểm của pm có nguồn gốc chính từ phương pháp, cách thức tiến hành xd pm:

+ cảm tính: mỗi ng theo 1 phương pháp riêng.

+ thô sơ, đơn giản: chỉ tập trung vào việc lập trình mà ít quan tâm đến các công việc cần làm khác trc khi lập trình (khảo sát hiện trạng, phân tích yêu cầu, thiết kế, …)

+ thủ công: công cụ hỗ trợ chính khi xd pm chỉ là trình biên dịch.

          Với các kết luận như trên, hội nghị đã đề xuất khai sinh 1 ngành hc mới: công nghệ pm với nhiệm vụ chính là nghiên cứu về các phương pháp tiến hành xd pm.

2. Phân loại phần mềm?

- Nhóm chương trình dịch: mỗi một ngôn ngữ có một chương trình dịch riêng.

- Nhóm các chương trình hệ thống (bao gồm cả các phần mềm hđh): Gồm có những chương trình soạn thảo vb, các chương trình đồ hoạ, hệ điều hành, …

- Nhóm các tiện ích và trò chơi: chương trình xử lí bảng tính điện tử, chương trình tìm và diệt virus, tất cả các trò chơi.

- Nhóm các hệ quản trị CSDL

- Nhóm các chương trình ứng dụng có tính hệ thống:

+ Nhóm các chương trình xử lí dữ liệu đa năng: Chương trình hệ chuyên gia, hệ mô phỏng, hệ tự động thiết kế, dạy học và tự học.

+ Chương trình xử lí nhận dạng, phân tích, tổng hợp tiếng nói, hình ảnh.

+ Tất cả những chương trình điều khiển qui trình công nghiệp.

- Nhóm các phần mềm thời gian thực

- Nhóm các phần mềm nhúng

- Nhóm các phần mềm thông minh

3. Nội dung của Công nghệ phần mềm?

- Tìm hiểu yêu cầu của bài toán

- Đặc tả

- Thiết kế và lập trình

- Kiểm thử

- Quản lý chất lượng

- Quản lý quy trình

4. Các giai đoạn phát triển phần mềm?

- Tìm hiểu nhu cầu của khách hàng: Đây là giai đoạn đầu tiên và không thể thiếu được trong việc xây dựng phần mềm cho một hệ thống nào đó. Sản phẩm phần mềm mà nhóm phát triển tạo ra suy cho đến cùng thì phải đáp ứng được (có thể không phải là toàn bộ) nhu cầu của khách hàng.

- Xác định rõ các chức năng: Chia ra từng khối lớn tương đối độc lập và giao cho từng nhóm người thực hiện. Mỗi nhóm người phải chụ trách nhiệm từ việc thiết kế - sản xuất - thử nghiệm theo một nguyên tắc nhất định và một ngôn ngữ cùng với cơ sở dữ liệu thống nhất. Sau đó ghép nối các khối thành khối lớn

- Sửa chữa và thử nghiệm nếu thấy cần thiết: Đây là giai đoạn mang tính nội bộ của nhóm phát triển phần mềm. Hệ thống có thể được chia thành nhiều phần nhỏ (module) rời rạc nhau. Do vậy khi xây dựng xong chúng ta cần phải thử nghiệm cho từng module đó. Sau đó tiến hành tích hợp các module lại để tạo thành hệ thống hoàn chỉnh. Việc kiểm thử tích hợp phải được tiến hành. Các thay đổi có thể được thêm vào; các ý kiến đóng góp của khách hàng cũng được ghi nhận và đưa vào trong phần mềm tại giai đoạn cuối cùng này.

- Bàn giao sản phẩm cho khách hàng, tìm hiểu ý kiến của khách hàng để quyết định nhân bản nếu nó tốt hoặc là để sửa đổi. Đào tạo người sử dụng : Trong quá trình từ khi tìm hiểu nhu cầu của khách hàng cho đến khi hoàn thiện, trong thời kỳ trước kia, trung bình mỗi người trong một ngày chỉ làm được 5 hoặc 6 lệnh. Khi đó có thể nói “Lập trình phần mềm hết sức nặng nhọc”. Chính vì vậy người ta phải cố gắng sử dụng những chương trình con (modul) chương trình của những người đi trước tạo ra (thường để trong thư viện) và đồng thời người ta cũng tạo ra các modul thêm vào thư viện để người khai thác có thể dùng.

* Các giai đoạn phát triển phần mềm nhìn một cách tổng quan hơn:

- gđ xác định (Definition phase): Xác định nội dung sẽ thực hiện (what)

- gđ phát triển (Development phase): Xác định cách thức phát triển (how)

- gđ hỗ trợ (support phase): Hỗ trợ thay đổi có thể xảy ra và bảo trì hệ thống

5. Các mô hình của quy trình phát triển phần mềm, ưu nhược điểm?

a, Mô hình thác nước

Là mô hình trải qua 4 giai đoạn tuần tự, kết thúc giai đoạn này chuyển qua giai đoạn sau :
+ Giai đoạn xác định các yêu cầu của bài toán và đề tài.
+ Giai đoạn thiết kế.
+ Giai đoạn thử nghiệm.
+ Giai đoạn tổng hợp.
- Ưu điểm: Được sử dụng quen thuộc từ trước đến nay.
- Nhược điểm: Nhiều khi đến giai đoạn tích hợp thường xảy ra nhiều vấn đề trục trặc trong vấn đề ghép nối

b, Mô hình thăm dò

Phát triển càng nhanh càng tốt các chức năng chính sau đó cải tiến hoàn chỉnh dần cho đến khi thảo mãn tất cả yêu cầu của người sử dụng.

- Hạn chế: Thích hợp với những pm qui mô vừa và nhỏ.

c, Mô hình tạo nguyên mẫu (Prototyping)

 Tương tự như mô hình thăm dò, lựa chọn nhanh những chức năng chính để phát triển sau đó đưa cho người sử dụng đóng góp ý kiến, đưa người dùng dùng thử cho đến khi đạt yêu cầu.
- Ưu điểm: Không có giai đoạn tích hợp, người dùng được tiếp cận với hệ thống ngay từ những giai đoạn đầu để bổ sung hoàn thiện phần mềm theo đúng yêu cầu
d, Mô hình biến đổi hình thức

 Là mô hình mà người ta đặc tả hệ thống dưới dạng tổng thể, khái quát rồi cụ thể hoá, chi tiết hoá dần đến khi có thể chuyển thẳng sang một ngôn ngữ lập trình cụ thể nào đó.

- Ưu điểm:

+ Có thể áp dụng chứng minh tính đúng đắn của đặc tả

+ Chứng minh chương trình đáp ứng được yêu cầu 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 điểm:

+ Việc đặc tả đòi hỏi trình độ trừu tượng cao

+Việc chứng minh sự đúng đắn là khó khăn

+ Phương pháp này là tương đối khó
e. Mô hình tập hợp các thành phần dùng lại được

 Là mô hình thực hiện với những phần mềm đã có sẵn được sử dụng từ trước đến nay. Có một số chức năng vẫn được sử dụng tốt, một số chức năng đã trở lên lạc hậu. Người ta xây dựng phần mềm mới bằng cách thu lượm tất cả các chức năng modul còn sử dụng được của phần mềm trước và thêm vào những chức năng mới cho đến khi thỏa mãn yêu cầu.
- Ưu điểm: Tiết kiệm thời gian, công sức sản xuất ra những cái có rồi.
- Nhược điểm: Tuỳ từng trường hợp, hạn chế trong ngôn ngữ sử dụng.

6. Các CASE tools?

- Soạn thảo biểu đồ

- Công cụ phân tích mô hình và kiểm tra

- Ngôn ngữ truy vấn

- Công cụ tạo và định nghĩa báo cáo

- Công cụ định nghĩa form

- Bộ dịch

- Công cụ tạo mã lệnh tự động

II. Phân tích yêu cầu phần mềm và đặc tả hệ thống

1. Khái niệm yêu cầu phần mềm, phân loại?

a, Khái niệm yêu cầu phần mềm

- Yêu cầu hệ thống là các mô tả dịch vụ được cung cấp bởi hệ thống và các ràng buộc khi vận hành (operational constraints).

- Thể hiện nhu cầu của người sử dụng đối với hệ thống.

b, phân loại yêu cầu

Có 2 loại yêu cầu chính:

* Yêu cầu chức năng: các chức năng của pm là các công việc khi đc thực hiện trên mt bằng pm. Yêu cầu chức năng là danh sách các công việc sẽ đc thực hiện trên mt cùng với các thông tin mô tả tương ứng. Đc chia thành 2 loại (theo ý nghĩa sd):

- Yêu cầu chức năng nghiệp vụ: các chức năng của pm tương ứng với công việc có thật trong thế giới thực. Có 4 loại chức năng chính ứng với 4 loại nghiệp vụ thông dụng nhất trong các lĩnh vực.

+ Chức năng lưu trữ: tương ứng với công việc ghi chép thông tin trên sổ sách (theo các quy định cần kiểm tra khi ghi chép).

+ Chức năng tra cứu: tương ứng với công việc tìm kiếm và xem thông tin tương ứng, theo dõi hoạt động.

+ Chức năng tính toán: tương ứng với các công việc tính toán (theo quy định công thức cho trước).

+ Chức năng kết xuất: tương ứng với các công việc viết các báo cáo (theo biểu mẫu cho trước).

- Yêu cầu chức năng hệ thống: đó là các chức năng phần mềm phải phát sinh thêm khi tiến hành công việc trên mt thay vì trong thế giới thực, or các chức năng không tương ứng với bất kỳ công việc nào hiện tại trong thế giới thực (có nhu cầu nhưng không thể thực hiện bằng thủ công). Một số chức năng hệ thống thông dụng như sau:

+ phân quyền sd giữa các loại ng dùng.

+ sao lưu (backup), phục hồi thông tin (restore).

+ định cấu hình thiết bị, ngày giờ làm việc, …

+ mô phỏng hoạt động thế giới thực.

+ báo động nhắc nhở ng dùng.

* Yêu cầu phi chức năng: các yc về chất lượng pm. Các yc này đc phân thành các loại theo các tính chất liên quan đến chất lượng pm như:

- tính tiến hóa: cho phép ng dùng thay đổi lại mô tả liên quan đến 1 yc chức năng nào đó.

- tính tiện dụng: đây là các yc liên quan đến hình thức giao diện của pm (hình thức trình bày trong quá trình sd các chức năng).

- tính hiệu quả: yc này quy định thời gian thực hiện các chức năng or giới hạn dung lượng lưu trữ (với số lượng cho trước).

- tính tương thích: đây là các yc liên quan đến việc chuyển đổi dữ liệu giữa pm đang xét và pm khác.

Ngoài ra còn có các ràng buộc trên việc thực hiện các yc chức năng như:

+ ràng buộc về môi trg khai thác: yc về phần cứng, chạy trên môi trg nào, …

+ tài liệu chương trình: tài liệu hướng dẫn sd, tài liệu hướng dẫn cài đặt, …

+ công tác huấn luyện sd pm.

+ an toàn và bảo mật.

+ xử lý lỗi: dự kiến 1 số lỗi có thể xảy ra -> ng xd pm sẽ quy định cách thức xử lý lỗi.

2. Các kỹ thuật đặc tả yêu cầu phần mềm?

- Đặc tả bằng ngôn ngữ tự nhiên

- Đặc tả bằng ngôn ngữ hướng cấu trúc

+ Sử dụng ngôn ngữ hướng cấu trúc sẽ yêu cầu người viết đặc tả tuân theo những mẫu được định nghĩa trước. Tất cả các yêu cầu đều được viết theo chuẩn và các thuật ngữ được sử dụng có thể bị hạn chế.

+ Ưu điểm của phương pháp này là đạt được mứ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ác đặc tả.

- Đặc tả dựa vào biểu mẫu

+ Định nghĩa các chức năng hoặc 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 điều kiện trước và sau (nếu thích hợp), các ảnh hưởng của chức năng.

- Biểu đồ trình tự

+ Biểu đồ trình tự biểu diễn trình tự các sự kiện xảy ra khi người sử dụng tương tác với hệ thống.

+ Nếu ta đọc biểu đồ này từ đầu đến cuối thì ta sẽ thấy được thứ tự của các hành động được thực hiện.

3. Quy trình xác định yêu cầu?

Gồm 4 giai đoạn chính:

- Nghiên cứu tính khả thi (Feasibility study):

+ Liệu hệ thống đóng góp vào mục tiêu chung của toàn cơ quan?

+ Hệ thống có thể triển khai được sử dụng công nghệ hiện tại, với một giới hạn về chi phí và lịch trình?

+ Sự tích hợp của hệ thống?

+ Cần đưa ra phương án phát triển và luận chứng sự khả thi

+ Thực hiện công việc này sẽ quyết định đưa ra một hệ thống đáp ứng được yêu cầu của khách hàng ->có tính khả thi cao nhất

+ Việc thực hiện công việc này phải nhanh và rẻ

+ Quyết định có tiếp tục phát triển theo phương án đó không

+ Chỉ khi dự án khả thi được chấp nhận, quá trình triển khai mới được bắt đầu

+ Nên phân loại phương án: phương án thấp, phương án trung bình, phương án cao

+ Phân tích khả thi thường tập trung vào các mặt:

Khả thi về kinh tế: chi phí và hiệu quả, lợi ích cuối

Khả thi về kỹ thuật: khả năng đáp ứng của kỹ thuật

Khả thi về pháp lý: loại trừ sự vi phạm, xâm phạm

Khả thi về hoạt động: vận hành trong môi trường cụ thể

Khả thi về thời gian: thời gian hoàn thành

- Phát hiện và phân tích yêu cầu (Requirements elicitation and analysis):

+ Là bước khảo sát yêu cầu của khách hàng và người sử dụng về miền ứng dụng -> Phân tích thành tài liệu xác định các yêu cầu. Tài liệu phải phản ánh được mong muốn của khách hàng, được viết sao cho mọi người đều hiểu được

+ Phải chú ý cả những đối tượng khác nhau liên quan đến hệ thống như các kỹ sư, người quản lý nghiệp vụ, chuyên gia

+ Giai đoạn này bao gồm cả việc phát triển thử nghiệm một hay nhiều mô hình hệ thống khác nhau. Việc làm bản mẫu hệ thống có thể được thực hiện trong giai đoạn này

+ Quá trình này thường gặp khó khăn vì: Người sử dụng (hoặc liên quan – stakeholders) không biết thực sự cần gì từ hệ thống, thường trình bày theo cách riêng, có nhiều người có các yêu cầu khác và giống nhau. Có thể bị ảnh hưởng bở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 yêu cầu mới mà không dự báo trước. Một số yêu cầu không thể định nghĩa được, không 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ực ứng dụng và kết thúc bằng việc thẩm định yêu cầu.

- Đặc tả yêu cầu (Requirement Specification):

+ 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 sử dụng 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 song song với các thiết kế ở mức cao (thiết kế sơ bộ)

+ Khi viết tài liệu đặc tả, các sai sót trong xác định yêu cầu sẽ được phát hiện và sửa chữa.

- Thẩm định yêu cầu (Requirement Validation):

+ Là việc xem xét các đặc tả yêu cầu có mô tả chính xác những gì đặt ra trong hệ thống có thể thực hiện được không?

+ Các lỗi trong tài liệu yêu cầu có thể dẫn tới rất nhiều công việc làm lại trong quá trình phát triển cũng như trong quá trình phần mềm được đưa vào sử dụng

4. Cần làm gì khi nghiên cứu tính khả thi của phần mềm?

- Liệu hệ thống đóng góp vào mục tiêu chung của toàn cơ quan?

- Hệ thống có thể triển khai được sử dụng công nghệ hiện tại, với một giới hạn về chi phí và lịch trình?

- Sự tích hợp của hệ thống?

- Cần đưa ra phương án phát triển và luận chứng sự khả thi

- Thực hiện công việc này sẽ quyết định đưa ra một hệ thống đáp ứng được yêu cầu của khách hàng ->có tính khả thi cao nhất

- Việc thực hiện công việc này phải nhanh và rẻ

- Quyết định có tiếp tục phát triển theo phương án đó không

- Chỉ khi dự án khả thi được chấp nhận, quá trình triển khai mới được bắt đầu

- Nên phân loại phương án: phương án thấp, phương án trung bình, phương án cao

- Phân tích khả thi thường tập trung vào các mặt:

+ Khả thi về kinh tế: chi phí và hiệu quả, lợi ích cuối

+ Khả thi về kỹ thuật: khả năng đáp ứng của kỹ thuật

+ Khả thi về pháp lý: loại trừ sự vi phạm, xâm phạm

+ Khả thi về hoạt động: vận hành trong môi trường cụ thể

+ Khả thi về thời gian: thời gian hoàn thành

5. Cần làm gì trong thẩm định yêu cầu?

- Là việc xem xét các đặc tả yêu cầu có mô tả chính xác những gì đặt ra trong hệ thống có thể thực hiện được không?

- Các lỗi trong tài liệu yêu cầu có thể dẫn tới rất nhiều công việc làm lại trong quá trình phát triển cũng như trong quá trình phần mềm được đưa vào sử dụng

6. Các kỹ thuật phân tích và xác định yêu cầu?

- Tiếp cận định hướng cách nhìn:

+ Ghi nhận những cách nhìn khác nhau của những người liên quan và sử dụng nó vào tiến trình phát hiện yêu cầu và tổ chức các yêu cầu

+ Các góc độ khác nhau có thể được xem xét:

Từ nguồn hay đích tới của dữ liệu

Từ khung làm việc

Từ sự tiếp nhận dịch vụ

+ Xác định yêu cầu định hướng cách nhìn gồm 4 giai đoạn cơ bản:

Xác định viewpoint

Cấu trúc viewpoint

Làm tài liệu viewpoint

Ánh xạ hệ thống viewpoint

- Kỹ thuật phân tích yêu cầu dựa trên mô hình:

+ Được sử dụng rộng rãi để phân tích yêu cầu

+ 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 (Hướng cấu trúc dựa trên luồng dữ liệu)

Tiếp cận hướng đối tượng

+ Tập trung hướng vào mô tả nghiệp vụ của hệ thống thực, kết quả thu được là MÔ HÌNH NGHIỆP VỤ

+ Mô hình nghiệp vụ theo phương pháp này gồm:

Mô hình ngữ cảnh: Mô tả hệ thống đượ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 hệ thống

Mô tả chi tiết các chức năng: cho đến 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 tất cả các hồ sơ và bản mẫu, theo HĐT gồm các đối tượng và khái niệm của thế giới thực

Mô tả các mối liên kết của dữ liệu 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 giải thích

- Kỹ thuật phân tích hình thức hoá :

+ Dựa trên việc sử dụng 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 hệ thống

+ Phân tích sẽ không tách thành mô hình riêng. Kết quả của việc phân tích và mô hình hóa cho ta ngay đặc tả của hệ thống.

7. Các kỹ thuật và phương pháp hỗ trợ phân tích yêu cầu?

- Các mô hình hệ thống: Phương pháp biểu diễn yêu cầu hệ thống một cách có kỹ thuật (thay vì văn bản dạng text)

- Use Case (UC):

+ UC chỉ ra chức năng của một hệ thống bằng cách mô tả hành vi của hệ thống (nghĩa là tương tác giữa người sử dụng và hệ thống).

+ UC có thể được sử dụng để mô tả hành vi của hệ thống phần mềm.

+ Các khái niệm cơ bản trong UC:

Actor: Nhân vật sự dụng hệ thống để đạt được một mục đích nào đó.

Primary actor là nhân vật chính khởi tạo một UC.

Hoạt cảnh (Scenario): Tập hợp các hành động nhằm đạt được mục đích

- Data Flow Diagram (DFD):

+ DFD phổ biến trong phân tích bài toán.

+ DFD thể hiện dòng dữ liệu trong một hệ thống. DFD coi hệ thống như là một hàm chuyển dữ liệu đầu vào thành dữ liệu đầu ra.

+ DFD biểu diễn sự di chuyển dữ liệu giữa các tiến trình xử lý dữ liệu.

+ Ký hiệu trong DFD:

Tiến trình : Đường tròn

Dòng dữ liệu là đường cong có mũi tên

Hình chữ nhật là nguồn sinh hay tiêu thụ dữ liệu

Sự cần thiết nhiều dòng dữ liệu được biểu dễn bởi “*” đặt giữa hai dòng (AND).Nghĩa là cả hai dòng đều cần thiết.

Tương tự, kí hiệu “+”  dùng cho phép toán OR.

- Các mô hình khác:

+ Mô hình ER cho phân tích dữ liệu

+ Mô hình đối tượng cho phân tích dự liệu

III. Kiến trúc phần mềm

1. Khái niệm kiến trúc phần mềm, thiết kế kiến trúc phần mềm?

- Kiến trúc phần mềm (Software Architecture) <-> một cấu trúc phần mềm và qua đó cung cấp một sự tích hợp chặt về mặt khái niệm của hệ thống

- Qui trình thiết kế các hệ thống con cũng như mô hình điều khiển/giao tiếp giữa các hệ thống con <-> architectural design. Kết quả của qui trình thiết kế này chính là software architecture.

- Kiến trúc phần mềm của một hệ thống bao gồm các thành phần phần mềm, các thuộc tính của chúng cũng như mối quan hệ giữa các thành phần.

2. Vai trò của kiến trúc phần mềm?

- Có vai trò quan trọng trong p/triển PM:

+ Công cụ giao tiếp giữa những người liên quan (understanding and communication): Tài liệu mô tả kiến trúc sẽ đựoc sử dụng bởi nhiều thành viên liên quan tới dự án phần mềm

+ Để phân tích hệ thống/xây dựng hệ thống: Kiến trúc phần mềm có thể được sử dụng để chỉ ra/dự đoán các thuộc tính của hệ thống. Ngoài ra nếu kiến trúc phần mềm có phân hoạch tốt, thì việc sử dụng phân hoạch để phát triển các chức năng dễ dàng hơn.

+ Sử dụng lại ở quy mô lớn: Chúng ta có xu hướng sử dụng lại các phần của phần mềm, do đó, kiến trúc là thông thông tin quan trọng trong việc hiểu biết các phần của phần mềm.

- Kiến trúc không phải là thành phần hoạt động nhưng nó có tác động sâu rộng đến quá trình phát triển PM, nó là một lọat mô tả PM mà cho phép các 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

3. Các mô hình kiến trúc phần mềm chủ yếu?

Có nhiều mô hình khác nhau, thường được nhìn nhận dưới một số mặt:

- 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

- Mô hình phân tán

* Cách nhìn khác:

- Mô hình Module:

+ Hệ thống được coi như là tập hợp các đơn vị mã. Mỗi đơn vị sẽ đảm nhiệm một vài phần chức năng  -> Kiến trúc tĩnh

+ Ví dụ: Package, classes,…

- Mô hình cấp phát:  Mô hình xác định cách các đơn vị phần mềm được cấp phát cho các đơn vị phần cứng.

- Mô hình C&C:

+ Mô hình là tập hợp các thực thể runtime   -> Kiến trúc liên kết

+ Ví dụ: Tập hợp các đối tượng

+ Connector cung cấp mối liên hệ giữa các thành phần

+ Đây là mô hình phổ biến nhất

4. Mối quan hệ với các yếu tố chất lượng, các yêu cầu phi chức năng của phần mềm?

- Kiến trúc phần mềm có ảnh hưởng lớn tới các đặc tính chất lượng phi chức năng như: hiệu suất, độ tin cậy, độ an toàn, vv…

- Chúng ta sẽ sự dụng những đặc tính này để đánh giá kiến trúc

+ Dùng các phương pháp hình thức

+ Dùng phương pháp thủ tục lấy ý kiến từ phía stakeholders

- Mối quan hệ với các yêu cầu chất lượng:

+ vẫn đảm bảo tính đúng đắn nhưng thỏa mãn thêm các yêu cầu khác (tiến hóa, tốc độ nhanh, lưu trữ tối ưu).

+ cần chú ý đảm bảo tính đúng đắn khi cải tiến sơ đồ logic.

5. Tài liệu kiến trúc phần mềm có những nội dung gì?

Bao gồm:

+ Ngữ cảnh hệ thống: nhận dạng các stakeholders và các mối quan tâm của họ;

+ Mô tả mô hình kiến trúc;

+ Các cách nhìn nhận khác nhau.

IV. Thiết kế hệ thống phần mềm

1. Khái niệm thiết kế, vai trò của thiết kế?

* Khái niệm thiết kế:

- Hoạt động thiết kế sẽ được thực hiện sau khi tài liệu yêu cầu được xác định.

- Là quá trình chuyển hóa các đặc tả yêu cầu phần mềm thành một biểu diễn thiết kế của hệ thống phần mềm cần xây dựng, sao cho người lập trình có thể ánh xạ nó thành một chương trình.

- Mục đích: Tạo ra bản thiết kế đúng

- Một số hoạt động chính:

+ Nghiên cứu để hiểu vấn đề

+ Chọn một 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ò của thiết kế:

- Là cách duy nhất để chuyển hóa một 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 làm cơ sở cho việc triển khai chương trình của phần mềm

- 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 phần mềm 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ì hệ thống

- Nếu không có thiết kế 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 phần mềm hữu hiệu.

2. Các bước cần trải qua trong giai đoạn thiết kế?

- 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ế các thành phần

- Thiết kế cấu trúc dữ liệu

- Thiết kế thủ tục (thuật toán): Stepwise refinement

3. Các nguyên lý thiết kế?

- 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

4. Thế nào là một 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 một chương trình hiệu quả. 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ẽ.

- 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.

- Các giải pháp cho một thiết kế tốt: Một thiết kế sẽ tốt nếu thực hiện đúng tiến trình thiết kế phần mềm 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.

5. Phương pháp thiết kế 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

* Thiết kế dữ liệu hướng cấu trúc:

- Gồm 2 bước: Thiết kế dữ liệu logic và thiết kế CSDL vật lý

- Thiết kế dữ liệu logic: Đầu vào của bước này là mô hình thực thể quan hệ, được mô tả

- 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

* Thiết kế xử lý:

- Gồm 2 bước: thiết kế xử lý logic & thiết kế kiến trúc modul

- Thiết kế xử lý logic:  Xuất phát từ luồng dữ liệu 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 module: Trước hết cần xác định luồng hệ thống từ biểu đồ luồng dữ liệu 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

* Ưu nhược điểm của phương pháp thiết kế dữ liệu hướng cấu trúc:

- Đã có thời gian phát triển lâu dài nên các phương pháp và các công cụ cũng đã hoàn thiện

- Có các hệ quản trị CSDL mạnh: SQLServer, Oracle trợ giúp việc lưu trữ và tự động hóa cao

- Thích hợp với các bài toán xử lý trên các dữ liệu có thể mô tả ở dạng bảng

- Tuy nhiên hạn chế với các bài toán dữ liệu đa dạng và đòi hỏi nhiều đối tượng tương tác với nhau

- Nếu hệ thống sử dụng CSDL dùng chung thì khó sử dụng lại và sai sót ở một số bộ phận thì ảnh hưởng đến toàn hệ thống

* Các bước trong thiết kế hệ thống hướng cấu trúc:

- Phát biểu lại bài toán như một DFD

- Chỉ ra các thành phần dữ liệu vào/ra

- Phân chia mức cao

- Phân chia ở mức chi tiết

* Đánh giá phương pháp thiết kế hướng cấu trúc:

- Ưu điểm:

+ Quen thuộc.

+ Xây dựng hệ thống thông qua biểu đồ luồng 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 hệ thống 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.

6. Phương pháp thiết kế hướng đối tượng?

- Hệ thống được nhìn nhận như một bộ các đối tượng tương tác với nhau, đối 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

- Hiện nay đã có một số công cụ hỗ trợ mạnh.

* Khái niệm về Thiết kế hướng đối tượng:

- Là một phần của của chiến lược phát triển định hướng đối tượng

- Đầu vào là các mô hình nhận được ở giai đoạn phân tích

- Gồm các bước:

+ Xác định kiến trúc của hệ thống

+ Sắp thứ tự ưu tiên các gói

+ Với mỗi gói thiết kế ca sử dụng tương ứng

+ Xây dựng biểu đồ tương tác

+ Thiết kế chi tiết các lớp

+ Phân tích và hoàn thiện biểu đồ lớp dựa trên mẫu thiết kế

* Ưu và nhược điểm của phương pháp:

- Dễ bảo trì, mọi thay đổi của đối tượng không làm ảnh hưởng đến các đối tượng khác

- Các đối tượng có thể sử dụng lại được

- Có thể phản ánh được thế giới thực một cách cụ thể

- Tuy nhiên có nhược điểm như: khó thực hiện vì khó xác định đối tượng của hệ thống. Thường cách nhìn tự nhiên là nhìn chức năng.

7. Cấu trúc của tài liệu đặc tả thiết kế theo chuẩn IEEE 1016-1998?

- Introduction (giới thiệu):

+ purpose (mục đích).

+ scope (phạm vi).

+ definitions, acronyms, and abbreviations (định nghĩa, viết tắt).

- References (tham khảo).

- Decomposition description (mô tả phân rã).

- Dependency description (mô tả phụ thuộc).

- Interface description (mô tả giao diện).

- Detailed design (thiết kế chi tiết).

V. Thiết kế giao diện người dùng

1. Khái niệm và vai trò giao diện người sử dụng?

- Khái niệm giao diện người dùng (User Interface – UI): Là không gian, nơi mà sự tương tác giữa người sử dụng và máy tính được thực hiện

- UID là thành phần quan trọng trong thiết kế phần mềm

- Yếu tố con người phải được coi trọng đặc biệt (user-centric design)

+ Chúng ta có trí nhớ giới hạn

+ Chúng ta đều có thể có sai lầm trong thao tác với phần mềm

+ Chúng ta có khả năng vật lý khác nhau: nghe nhìn, vv

+ Chúng ta có sở thích tương tác với phần mềm khác nhau

- Người sử dụng thông thường đánh giá phần mềm thông qua giao diện hơn là chức năng

- Giao diện tồi là nguyên nhân mà phần mềm không được sử dụng

- Phần lớn là giao diện đồ họa, nói đến UID thường là nói đến GUI design

3. Các nguyên tắc thiết kế giao diện người sử dụng?

- Thân thiện người sử dụng:

+ Tránh áp đặt cách sử dụng cho người sử dụng

+ Sử dụng các khái niệm phổ biến

+ Gắn với môi trường làm việc cụ thể

- Thống nhất:

+ Định dạng thống nhất giữa các đối tượng

+ Thống nhất định dạng sẽ giúp cho việc giảm thời gian học sử dụng phần mềm

+ Điều gi nếu một phần mềm khác sử dụng “Ctrl+S” cho một chức năng khác thay vì SAVE?

- Ổn định: Giảm thiểu các hành động không mong đợi khi người sử dụng thao tác với giao diện phần mềm

- Khắc phục sự cố:

+ Nên có câu hỏi khẳng định (confirm) những hành động có thể gây ra sự mất mát

+ Cung cấp công cụ/thao tác undo

+ Điểm kiểm tra (checkpointing): cho phép ghi lại công việc theo một chu kỳ nhất định

- Hướng dẫn:

+ Các hệ thống help

+ Thông tin help cần ngắn gọn xúc tích

- Đa dạng:

+ Tương tác với người sử dụng cần phải đa dạng theo các thể loại người sử dụng.

+ Người sử dụng thông thường thì cần trợ giúp nhiều hơn

+ Người sử dụng chuyên nghiệp thì cần shortcuts nhiều hơn

4. Tiến trình thiết kế giao diện người sử dụng?

- Tiến trình lặp (chi tiết):

+ 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 hoạt động UID - tổng quát:

+ Phân tích người sử dụng: hiểu biết về nhiệm vụ của người sử dụng, môi trường làm việc,vv…

+ Xây dựng bản mẫu hệ thống: có thể trình bày với người sử dụng trước

+ Đánh giá giao diện: thông qua tương tác với người sử dụng

VI. Kỹ thuật lập trình

1. Đặc điểm của lập trình cấu trúc?

- LTCT bắt đầu từ những năm 70 nhằm mục đích tạo ra các code mà không có “goto”

- Ngoài ra, múc đích khác của LTCT là trợ giúp quá trình quá trình kiểm chứng mã nguồn.

- Câu lệnh không chỉ đơn thuần là gán

- Ba cấu trúc lệnh cơ bản:

+ Selection: if B then S1 else S2 if B then S1

+ Iteration: While B do S hoặc repeat S until B

+ Sequencing: S1; S2; S3;...

- Luôn luôn có: Single-entry, single-exit

2. Đặc điểm của lập trình hướng đối tượng?

- Là kĩ thuật lập trình hỗ trợ công nghệ đối tượng. OOP được xem là giúp tăng năng suất, đơn giản hóa độ phức tạp khi bảo trì cũng như mở rộng phần mềm bằng cách cho phép lập trình viên tập trung vào các đối tượng phần mềm ở bậc cao hơn. Ngoài ra, nhiều người còn cho rằng OOP dễ tiếp thu hơn cho những người mới học về lập trình hơn là các phương pháp trước đó.

- Một cách giản lược, đây là khái niệm và là một nỗ lực nhằm giảm nhẹ các thao tác viết mã cho người lập trình, cho phép họ tạo ra các ứng dụng mà các yếu tố bên ngoài có thể tương tác với các chương trình đó giống như là tương tác với các đối tượng vật lý.

- Những đối tượng trong một ngôn ngữ OOP là các kết hợp giữa mã và dữ liệu mà chúng được nhìn nhận như là một đơn vị duy nhất. Mỗi đối tượng có một tên riêng biệt và tất cả các tham chiếu đến đối tượng đó được tiến hành qua tên của nó. Như vậy, mỗi đối tượng có khả năng nhận vào các thông báo, xử lý dữ liệu (bên trong của nó), và gửi ra hay trả lời đến các đối tượng khác hay đến môi trường.

- Ra đời từ những năm 1980.

3. Các nguyên lý lập trình?

- Nhiệm vụ chính của lập trình viên là tạo ra code với ít lỗi nhất với thời gian ít nhất.

- Kỹ năng lập trình thu nhận được thông qua thực tế viết code.

- Lập trình tốt không phụ thuộc vào một ngôn ngữ cụ thể

* Một số lưu ý thực tế:

- Control Constructs: Sử dụng nhiều cấu trúc single-entry, single-exit. Tăng cường sử dụng các cấu trúc chuẩn.

- Gotos: Không nên sử dụng các lệnh goto quá nhiều. Chỉ sử dụng trong các trường hợp bất khả kháng.

- Che dấu thông tin: nên được sử dụng rộng rãi. Truy nhập thông tin nên theo cơ chế hàm.

- Kiểu dữ liệu User-Defined: Nếu ngôn ngữ lập trình cho phép thì nên sử dụng các kiểu dữ liệu tự định nghĩa.

- Lồng (Nesting): Nên tránh các Lặp sâu (deep nesting). For example, consider the following construct of nested

+ if-then-elses:

·        if C1 then S1;

·        else if C2 then S2;

·        else if C3 then S3;

·        else if C4 then S4;

+ Nếu các điều kiện là không liên kết disjoint thì ta nên:

·        if C1 then S1;

·        if C2 then S2;

·        if C3 then S3;

·        if C4 then S4;

- Module Size: Việc sử dụng hàm với nhiều tham số phải hết sức cẩn thận (>= 100). Kích thước lớn có thể làm cho việc quản lý kết dính và kết nối khó khăn.

- Module Interface: (rule of thumb), bất kỳ một giao diện module mà có nhiều hơn 5 tham số thì phải đặc biệt cẩn thận và nên được chia thành nhiều module nhỏ hơn.

- Side Effects: Hiện tượng thay đổi trạng thái chương trình mà không thay đổi giá trị tham số. Thường xảy ra khi ta thay đổi biến toàn cục.

- Robustness: Xử lý tốt các điều kiện ngoại lệ.

- Switch Case with Default: Đảm bảo hành vi của chương trình ổn định.

- Empty Catch Block: nên có chặn bắt lỗi, tránh để trống.

- Empty if, while Statement: Không làm gì sau các câu lệnh if, while: Nên tránh.

- Read Return to Be Checked: Giá trị trả về sau lệnh đọc nên được kiểm tra

- Return from Finally Block: Không nên để return trong khối finally

- Correlated Parameters: Thông thường, sẽ tồn tại mối quan hệ giữa các tham số.

- Trusted Data Sources: Kiểm tra dữ liệu nên được thực hiện trước khi truy nhập chúng

- Give Importance to Exceptions: Chú trọng điều khiển ngoại lệ.

4. Cách phát triển mã nguồn tăng dần?

- Hoạt động lập trình bắt đầu khi một số thiết kế hoàn thành.

- Mỗi module sẽ do một hoặc nhiều lập trình viên đảm nhiệm.

- Chính vì vậy mà nhu cầu quản lý qui trình này là rất cao.

* Tiến trình tăng dần: Lập trình cho module, sau đó kiểm thử, và sửa lỗi. Sau đó code được chuyển tải đến các bộ phận khác trong dự án.

5. Cách quản lý mã nguồn?

- Xây dựng và quản lý Source Code:

+ Trong một dự án thường có nhiều nhóm người khác nhau cùng tham gia phát triển code. Mỗi lập trình viên làm việc với một file mã nguồn, những file này sẽ được biên dịch với nhau để tạo nên phần mềm.

+ Trong quá trình phát triển code, các lập trình viên thường luôn thay đổi các file mã nguồn do họ tạo ra, cũng như những file không do họ tạo ra.

+ Với mục đích kiểm soát tất cả các file mã nguồn và quá trình thay đổi của chúng, các công cụ kiểm soát mã nguồn như CVS trong Linux (www.cvshome.org) hay Visual Source Safe (VSS) trong Windows (msdn.microsoft.com/vstudio/previous/ssafe) thường được sử dụng.

- Cách xử lý đụng chạm khi lập trình nhóm:

+ Tạo một bản sao mã nguồn trên máy cá nhân.

+ Thay đổi bản sao trên máy cá nhân.

+ Cập nhật, báo cáo.

- Cập nhật thay đổi – refactoring: Thay đổi cấu trúc bên trong mà không làm thay đổi hành vi của phần mềm

- Yếu tố dẫn đến sự cần thiết sửa đổi:

+ Nhận bản code - Duplicate Code.

+ Tên Phương thức dài - Long Method.

+ Tên Lớp dài - Long Class.

+ Danh sách tham số dài - Long Parameter List.

+ Các câu lệnh Switch - Switch Statements.

+ Tổng quát hóa - Speculative Generality.

+ Quá nhiều kết nối - Too Much Communication Between Objects.

+ Dây chuyền thông điệp - Message Chaining.

6. Thanh tra mã nguồn?

- Thanh tra mã nguồn:

+ Thanh tra mã nguồn được thực hiện bởi người lập trình và dành cho người lập trình.

+ Là một tiến trình với các qui định về vai trò rõ ràng.

+ Trọng tâm tìm ra lỗi defects.

+ Dữ liệu thanh tra được ghi lại và dùng để đánh giá mức độ hiệu quả của quá trình thanh tra

- Lập kế hoạch thanh tra:

+ Mục tiêu của giai đoạn lập kế hoạch là để chuẩn bị cho thanh tra.

+ Đội thanh tra được thành lập sẽ bao gồm các lập trình viên mà code của họ đang cần xem xét.

+ Đội thanh tra nên bao gồm ít nhất ba người, mặc dù đôi khi có bốn hoặc năm thành viên.

+ Đội thanh tra phải có một người phụ trách.

- Họp kiểm tra theo nhóm:

+ Nhằm đưa ra danh sách chung về các lỗi của chương trình

+ Thảo luận về khả năng sửa chữa

- Phép đo đánh giá mã nguồn:

+ Kích thước code: thường được dùng trong ước lượng chi phí.

ü Phổ biến: Số dòng lệnh

ü Hạn chế: Phục thuộc vào ngôn ngữ

ü Phần lớn là sử dụng việc đếm dòng lệnh.

ü Tuy nhiên, hiện nay đã có mốt số phương pháp ước lượng dựa trên số lượng toán tử và toán hạng

+ Độ phức tạp:

ü Số lượng cấu trúc thể hiện các nhánh của FOC (follow of control),

ü Số lượng biến được sử dụng trong một module – live variables

ü Độ sâu của nesting

VII. Thẩm định và xác minh phần mềm (Verification and Validation)

1. Khái niệm V&V, mục đích, vai trò, tầm quan trọng?

* Khái niệm V&V:

- Verification –Xác minh:

+ "Are we building the product right": Chúng ta có xây dựng phần mềm một cách đúng đắn hay không?

+ The software should conform to its specification: Phần mềm cần tuân thủ các đặc tả

- Validation – Thẩm định:

+ "Are we building the right product": Chúng ta có xây dựng đúng phần mềm được yêu cầu hay không?

+ The software should do what the user really requires: Phần mềm cần tuân thủ các yêu cầu của người sử dụng.

- Thẩm định phần mềm:  Là xem phần mềm cho kết quả đúng hay không và có thỏa mãn yêu cầu của người sử dụng hay không.

- Xác minh phần mềm: Là xem sản phẩm có đúng là sản phẩm được yêu cầu không và chương trình có đúng với đặc tả không.

- Thẩm định và xác minh phần mềm là 2 quá trình liên tục, xuyên suốt từ lúc phân tích các yêu cầu của khách hàng cho đến khi giao sản phẩm, với mục đích:

+ Xem hệ thống có đáp ứng yêu cầu của khách hàng không, phát hiện lỗi của phần mềm.

* Mục đích của V&V:

- Tạo sự tự tin về phần mềm sẽ đạt được mục tiêu đề ra.

- Điều này không có nghĩa là sẽ tạo ra phần mềm không có lỗi chút nào.

- Kiểu sử dụng phần mềm sẽ quyết định mức độ tự tin cần thiết.

2. Các thức tiến hành V&V?

- Để thẩm định và xác minh phần mềm người ta phải thử nghiệm (kiểm thử) hay thanh tra.

- Hai cách thức này thường có liên hệ với nhau:

+ Thanh tra phần mềm: Liên quan đến việc phân tích hệ thống trong trạng thái tĩnh (không chạy) để phát hiện các vấn đề (Xác minh tĩnh).

+ Kiểm thử phần mềm: Liên quan đến việc cho chạy và quan sát hành vi của phần mềm (Xác minh động).

3. Xác minh tĩnh và động?

- Thanh tra phần mềm: Liên quan đến việc phân tích hệ thống trong trạng thái tĩnh (không chạy) để phát hiện các vấn đề (Xác minh tĩnh)

+ Có thể sử dụng các công cụ phân tích tài liệu và phân tích mã nguồn để hỗ trợ

- Kiểm thử phần mềm: Liên quan đến việc cho chạy và quan sát hành vi của phần mềm (Xác minh động).

+ Hệ thống được cho chạy cùng với dữ liệu kiểm thử và hành vi của nó sẽ được quan sát

4. Thanh tra phần mềm?

- Liên quan đến việc kiểm tra mã nguồn để tìm ra các vấn đề bất thường và khuyết tật

- Không yêu cầu chạy phần mềm trước và khi thanh tra

- Có thể tiến hành thanh tra mọi đối tượng cấu hình của phần mềm (các bản đặc tả yêu cầu, thiết kế, dữ liệu test,…)

- Là một kỹ thuật hiệu quả để phát hiện ra lỗi

- Nhiều khuyết tật khác nhau có thể được phát hiện chỉ bởi một lần thanh tra.

- Trong một lần kiểm thử, một khuyết tật có thể chưa được phát hiện, vì vậy cần phải tiến hành nhiều lần

- Các lĩnh vực tái sử dụng và tri thức lập trình cho phép phát hiện các loại lỗi thường hay xảy ra

5. Khái niệm phương pháp hình thức?

VIII. Phương pháp kiểm thử phần mềm

1. Khái niệm kiểm thử, mục tiêu của kiểm thử?

* Khái niệm kiểm thử :Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau.

* Mục tiêu kiểm thử:

- 3 mục tiêu:

+ Kiểm thử là một quá trình vận hành chương trình để tìm ra lỗi.

+ Thiết kế cá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

+ Nghiên cứu thiết kế các ca kiểm thử thắng lợi. Một ca kiểm thử thắng lợi 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

- Một ca kiểm thử thắng lợi làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ:

+ chứng tỏ rằng các chức năng phầm mềm làm việc tương ứng với đặc tả,

+ chứng tỏ các yêu cầu thực thi là phù hợp

+ có thêm các chỉ số độ tin cậy phần mềm và các chỉ số về chất lượng phần mềm nói chung

+ Kiểm thử không thể chứng minh được việc không có khiếm khuyết, nó chỉ có thể chứng minh rằng khiếm khuyết phần mềm hiện hữu

2. Quy trình kiểm thử?

- Hai lớp được cung cấp cho tiến trình 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.

- Kiểm thử được tiến hành và tất cả các kết quả được đánh giá bằng cách so sánh với kết quả dự kiến. Khi phát hiện lỗi, việc gỡ lỗi bắt đầu được tiến hành.

- Tiến trình gỡ lỗi thường không dự kiến được thời gian nên việc lập lịch kiểm thử trở nên khó khăn.

+ Ví dụ: 1 lỗi chỉ ra sự sai biệt độ 0.01% giữa kết quả trông đợi và thực tại có thể mất 1 giờ, 1 ngày hay 1 tháng để chuẩn đoán và sửa chữa.

- Khi các kết quả kiểm thử được thu thập và đánh giá thì chất lượng và độ tin cậy phần mềm dần được khẳng định.

+ Nếu hay gặp phải lỗi nghiêm trọng yêu cầu sửa đổi thết kế thì chất lượng và độ tin cậy là đáng ngờ và cần kiểm thử thêm.

- Mặt khác, nếu các chức năng phần mềm dường như làm việc đúng và lỗi gặp phải là dễ sửa thì có thể rút ra một trong hai kết luận:

+ (1) Chất lượng và độ tin cậy phần mềm chấp nhận được

+ (2) Kiểm thử không tương xứng để làm lộ ra những lỗi nghiêm trọng.

- Nếu việc kiểm thử không làm lộ ra lỗi nào thì có thể hoài nghi rằng cấu hình kiểm thử chưa được cân nhắc đúng mức, các lỗi vẫn còn ẩn núp trong phần mềm và sẽ bị phát hiện bởi người dùng.

3. Nguồn dữ liệu kiểm thử?

Dữ liệu vào
Dữ liệu của chương trình: số, xâu ký tự, tập tin,
Môi trường thử nghiệm: phần cứng, hệ điều hành,
Thứ tự thao tác (kiểm thử giao diện)

4. Khái niệm test case?

- Test Case là một cặp <input, expected outcome>

-  Đối với những hệ thống State-less (phi trạng thái): (ví dụ compiler là một hệ thống)

+ Test cases rất đơn giản: Outcome chỉ phụ thuộc vào input hiện tại

- Đối với những hệ thống có trạng thái State-oriented: Ví dụ như máy ATM

+ Test cases không đơn giản. Một test case có thể bao gồm một chuỗi <input, expected outcome>

ü Outcome phụ thuộc cả vào trạng thái hiện tại của hệ thống và input hiện tại

ü ATM example:

< check balance, $500.00 >,

< withdraw, “amount?” >,

< $200.00, “$200.00” >,

< check balance, $300.00 >

* Test case design:

- Liên quan đến việc thiết kế các test cases (inputs và outputs) để kiểm thử hệ thống.

- Mục đích của thiết kế test case là để tạo ra một tập hợp các bài test có hiệu quả trong thẩm định và kiểm tra khuyết tật.

- Các cách tiếp cận khi thiết kế test case:

+ Dựa trên yêu cầu (Requirements-based testing);

+ Phân lớp (Partition testing);

+ Dựa vào cấu trúc (Structural testing).

5. Các phương pháp kiểm thử?

* Testing Levels:

- Component testing (Unit testing):

+ Kiểm thử các từng thành phần chương trình độc lập;

+ Thông thường đây là trách nhiệm của các thành viên phát triển các thành phần (ngoại trừ một số trường hợp hệ thống cực kỳ quan trọng);

+ Tests được tạo ra từ kinh nghiệm của các thành viên phát triển.

- System testing:

+ Kiểm thử các nhóm thành phần chương trình được tích hợp với nhau để tạo ra các hệ thống hoặc hệ thống con;

+ Là trách nhiệm của một đội kiểm thử độc lập;

+ Tests được tạo ra dựa trên đặc tả hệ thống.

* System testing:

- Liên quan đến việc tích hợp các thành phần để tạo ra hệ thống hoặc hệ thống con.

- Có thể có sự tham gia của khách hàng trong giai đoạn này.

- Hai phases:

+ Integration testing – Đội kiểm thử cần truy cập đến mã nguồn hệ thống. Hệ thống được kiểm thử như các thành phần được tích hợp với nhau.

+ Release testing – Đội kiểm thử kiểm thử hệ thống như một hộp đen.

* Integration testing:

- Liên quan đến việc xây dựng hệ thống từ các thành phần của nó và kiểm thử để tìm các vấn đề có thể phát sinh từ việc tích hợp.

- Top-down integration: Phát triển bộ khung của hệ thống và đưa vào đó các thành phần tương ứng.

- Bottom-up integration: Tích hợp các thành phần hạ tầng sau đó là các thành phần chức năng chính.

- Để đơn giản hóa việc tìm ra vị trí lỗi, hệ thống nên được tích hợp dần dần.

* Testing approaches của integration testing:

- Architectural validation: Top-down integration testing tốt hơn để phát hiện ra các lỗi kiến trúc hệ thống.

- System demonstration: Top-down integration testing cho phép một sự trình diễn hữu hạn hệ thống tại giai đoạn sớm trong quy trình phát triển.

- Test implementation: Thường dễ dàng hơn với bottom-up integration testing.

- Test observation: Là vấn đề đối với cả hai cách tiếp cận. Code bổ sung có thể được yêu cầu để thực hiện các tests.

* Release testing:

- Là quá trình kiểm thử một phiên bản hệ thống sẽ được bàn giao cho khách hàng.

- Mục tiêu chính là là tăng sự tự tin của nhà cung cấp (nhà phát triển) về sự phù hợp của hệ thống với các yêu cầu của nó.

- Release testing thường sử dụng phương pháp black-box hoặc functional testing

+ Chỉ dựa trên đặc tả hệ thống;

+ Các Testers không cần biết về việc hệ thống được hiện thực như thế nào.

* Testing levels (detailed):

- Unit testing:  Kiểm thử các đơn vị chương trình độc lập như các thủ tục, hàm, phương thức một cách riêng rẽ

- Integration testing: Kiểm thử việc ghép nối các đơn vị chương trình

- System testing: Bao gồm một dải kiểm thử rộng như tính chức năng, khả năng chịu tải

- Acceptance testing

+ Khách hàng kiểm tra những kỳ vọng của mình về hệ thống

+ Hai loại acceptance testing:

ü UAT (User acceptance testing): Hệ thống đáp ứng các tiêu chí của hợp đồng

BAT (Business Acceptance Testing): Hệ thống chưa, nhưng sẽ đáp ứng được user acceptance test

* Performance testing:

- Một phần của release testing có thể liên quan đến việc kiểm thử các tính chất quan trọng của hệ thống như hiệu suất và độ tin cậy.

- Các tests hiệu suất thường liên quan đến việc lập kế hoạch cho một loạt các bài kiểm tra khả năng chịu tải tăng dần cho đến khi hệ thống không thể thực hiện được nữa.

* Stress testing:

- Là các thử nghiệm hệ thống vượt quá khả năng chịu tải của nó. Việc thử nghiệm quá tải thường giúp phát hiện các khuyết tật của hệ thống.

- Tập trung vào vấn đề hư hại của hệ thống. Không có hệ thống nào không thể không hỏng. Stress testing kiểm tra sự mất mát dịch vụ và dữ liệu không thể chấp nhận được (giới hạn mất mát dữ liệu và dịch vụ).

- Stress testing đặc biệt quan trọng đối với các hệ thống phân tán là những hệ thống dễ bị sụp đổ nhanh chóng, ví dụ như một mạng khi bị quá tải.

IX. Quản lý chất lượng phần mềm

1. Khái niệm chất lượng phần mềm, đảm bảo chất lượng phần mềm?

- Khái niệm về chất lượng phần mềm:

+ Từ điển American Heritage định nghĩa chất lượng là "một đặc tính hoặc thuộc tính của một cái gì đó"

+ Với quan niệm là một thuộc tính của một mục, chất lượng đề cập đến đặc tính đo lường được - điều mà chúng ta có thể so sánh với các đại lượng chuẩn được biết đến như chiều dài, màu sắc, tính chất điện.

+ Tuy nhiên, phần mềm, được biết rộng rãi là một thực thể trí tuệ, sẽ khó khăn hơn để định nghĩa chất lượng so với các đối tượng vật lý.

+ Chất lượng phần mềm được định nghĩa là: Sự phù hợp của phần mềm với các yêu cầu về chức năng, hiệu suất, với các tiêu chuẩn phát triển được quy định rõ ràng bằng văn bản và phù hợp với các đặc điểm ngầm định ​​của tất cả các phần mềm được phát triển chuyên nghiệp.

- Software quality management:

+ Quan tâm đến việc đảm bảo mức độ yêu cầu về chất lượng được tuân thủ trong một sản phẩm phần mềm

+ Liên quan đến việc xác định các tiêu chuẩn, các thủ tục chất lượng phù hợp và đảm bảo việc  chúng được tuân thủ

+ Có mục đích để phát triển một "văn hóa chất lượng", theo đó chất lượng được xem là trách nhiệm của mọi người

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

+ Đảm bảo chất lượng bao gồm các chức năng kiểm toán và báo cáo về quản lý.

+ Mục tiêu của đảm bảo chất lượng là cung cấp cho công việc quản lý các dữ liệu cần thiết để nhận được thông tin về chất lượng sản phẩm, từ đó có cái nhìn sâu sắc và sự tự tin rằng chất lượng sản phẩm đáp ứng các mục tiêu của nó.

+ Nếu dữ liệu được cung cấp thông qua đảm bảo chất lượng chỉ ra các vấn đề, thì đó là trách nhiệm của ban quản lý để giải quyết các vấn đề và áp dụng các nguồn lực cần thiết để giải quyết các vấn đề chất lượng.

+ Thiết lập các thủ tục cho tổ chức và thiết lập các tiêu chuẩn chất lượng

2. Những công việc chính trong đảm bảo chất lượng phần mềm?

Đảm bảo chất lượng phần mềm bao gồm một loạt nhiệm vụ liên quan tới 2 nhóm người:

- Các kỹ sư phần mềm, những người thực hiện các công việc kỹ thuật;

- Nhóm SQA có trách nhiệm lập kế hoạch đảm bảo chất lượng, giám sát, lưu trữ hồ sơ, phân tích, báo cáo.

* The SQA group:

+ Chuẩn bị kế hoạch SQA cho một dự án.

+ Tham gia vào công việc mô tả quá trình phần mềm của dự án.

+ Rà soát các hoạt động kỹ nghệ phần mềm để xác minh tính phù hợp với quá trình phần mềm đã được xác định.

+ Kiểm toán các sản phẩm phần mềm được chỉ định để xác minh sự tuân thủ với những quy định của chúng như là một phần của quá trình phần mềm.

+ Đảm bảo rằng độ lệch giữa các sản phẩm phần mềm thực tế và đặc tả được ghi chép và xử lý bằng văn bản.

+ Ghi chép lại mọi sự không phù hợp và báo cáo cho người quản lý cấp cao hơn.

3. Các cuộc họp rà soát?

* Họp rà soát:

- 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

+ tất cả 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ị.

+ Cuộc họp nên ít hơn 2 giờ. Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ, cụ thể.

- 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

* Họp rà soát - 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 tán thành 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

- 10 điều tối thiểu trong phương châm rà soát kỹ thuật chính thức:

+ Rà soát sản phẩm, không rà soát người làm nó

+ Lập chương trình nghị sự và duy trì nó.

+ Hạn chế tranh luận và bác bỏ: các vấn đề tranh luận nên để ghi nhớ cho các thảo luận tiếp tục

+ Trình bày rõ ràng mạch lạc các vùng có vấn đề nhưng không được gượng ép giải quyết mọi vấn đề nhận thấy: FTR không giải quyết vấn đề, việc giải quyết vấn đề sau FTR và thường do chính người làm ra sản phẩm thực hiện, có thể nhờ sự trợ giúp của vài cá nhân khác.

+ Nên có ghi chú trên bảng tường

+ Giới hạn số người tham dự và kiên trì các dự kiến

+ Lập một danh sách các kiểm tra cho từng sản phẩm sẽ được rà soát:

ü Giúp nhà lãnh đạo rà soát cấu trúc các cuộc họp FTR

ü Giúp người rà soát  tập trung vào các vấn đề quan trọng

ü Danh sách kiểm tra lập cho từng loại sản phẩm:ành cho việc phân tích, thiết kế, mã hoá kiểm tra và bảo trì

ü Một tập thể các đại diện sẽ xem lại danh sách này để trình.

+ Cấp phát nguồn lực và thời biểu cho các FTR: xem nó là một nhiệm vụ trong quá trình  phát triển phần mềm, và cũng phải dự tính các cải biên cần  thiết cho sự kiện chưa dự đoán được

+ Cần phải tiến hành huấn luyện chính thức cho các cá nhân ra soát: Rà soát lại các rà soát trước đây.

* Sản phẩm của cuộc họp rà soát:

- 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.

+ để nhận ra vùng có vấn đề trong sản phẩm được rà soát

+ dùng như một danh sách các khoản mục hành động để chỉ cho người làm ra sản phẩm cần chỉnh sửa

+ Cần thiết lập một thủ tục để bảo đảm rằng các khoản mục trong danh sách đó sẽ được chỉnh sửa thực sự

- 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

4. Rà soát phân tích yêu cầu, phân tích thiết kế, coding, kiểm thử?

* Rà soát phân tích yêu cầu phần mềm:

- Mục tiêu: thẩm định và xác minh yêu cầu phần mềm

+ phải chỉ ra các nhu cầu của người dùng là được thoả mãn

+ 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.

+ Với các hệ thống lớn cần tăng cường: đánh giá các nguyên mẫu cũng như các cuộc họp với khách hàng 

- Danh mục: xem xét các chủ đề sau:

+ Phân hoạch vấn đề (hệ con) có đầy đủ hay không?

+ Các giao diện trong và ngoài đã thực sự đ­ược xác định chưa?

+ Phân tích lĩnh vực thông tin có đầy đủ, phi mâu thuẫn và chính xác hay ko?

+ Mô hình dữ liệu đã thực sự phản ánh các đối tượng dữ liệu, các thuộc tính và các quan hệ?

+ Tất cả các yêu cầu có thể lần vết đư­ợc ở mức hệ thống không?

+ Đã làm bản mẫu dành cho người sử dụng (khách hàng) chư­a?

+ Liệu có thực hiện đ­ược với những ràng buộc quy định bởi các phần tử hệ thống khác hay không?

+ Các yêu cầu có phù hợp với lịch biểu, nguồn lực và kinh phí hay không?

+ Các chuẩn thẩm định có đầy đủ hay không?

* Rà soát phân tích thiết kế phần mềm:

- Mục tiêu: Hướng đến thiết kế đảm bảo hai 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 đủ, phù hợp

+ Có chất lượng tốt

+ Cấu trúc tốt (phân hoạch, giao diện, modul hoá)

+ Thuật toán tốt (ít phức tạp, tốc độ cao, dễ hiểu)

+ Dữ liệu tốt (cấu trúc, biểu diễn)

+ Có thể lần vết được (dễ hiểu, dễ kiểm tra)

- 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

+ thiết kế thủ tục.

+ Có 2 kiểu rà soát thiết kế (phù hợp với bước triển khai):

+ rà soát thiết kế sơ bộ - preliminary design review (đá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),

+ rà soát thiết kế trọn vẹn - design walkthrough (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ữ?

ü Đó dùng logic compound hoặc logic inverse?

ü Khả năng bảo trì đã đ­ược xét tới chưa

* Rà soát coding:

- 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ó các sai sót chính tả hoặc in ấn nào không?

+ 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ử:

- 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à 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

ü vụ nổ lớn (big bang)

+ 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

+ Kế hoạch kiểm thử tổng thể :

ü Giới thiệu chung

§  Mô tả hệ thống cần kiểm thử

§  Các mục tiêu kiểm thử

§  Phương pháp sử dụng

§  Tài liệu hỗ trợ

ü Kế hoạch :

§  Thời gian, địa điểm

§  Tài liệu kiểm thử: các ca kiểm thử, tiến trình, lịch trình

§  Điều kiện

ü Các yêu cầu: phần cứng, phần mềm, nhân sự

ü Kiểm soát quá trình kiểm thử

- 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 minh đị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?

+ Các bộ lái (driver) và các cuống (stub) thử nghiệm đã đ­ược minh định ch­ưa?; công việc phát triển chúng đã được lập lịch chư­a?

+ Thử nghiệm c­ường độ chịu áp lực cho phần mềm đã được đặc tả chư­a?

+ Cả hai loại thử nghiệm hộp trắng và hộp đen đã đư­ợc đặc tả ch­ưa?

+ Có phải tất cả các đư­ờng logic độc lập đều đ­ược thử nghiệm?

+ Có phải tất cả các ca thử nghiệm đều đã đ­ược minh định và lập danh sách với đủ các kết qủa chờ mong?

+ Việc xử lý sai có đ­ược thử nghiệm?

+ Các giá trị biên có đư­ợc thử nghiệm?

+ Các yêu cầu thời gian và sự diễn tiến có đư­ợc thử nghiệm?

+ Các biến thể chấp nhận đ­ược của kết quả thử nghiệm mong đợi đã đ­ược đặc tả chưa?

5. Các tiêu chí của chất lượng 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. Để đạt được yêu cầu này, các sản phẩm phần mềm trước hết phải có thuật toán đúng và chương trình tì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: Các sản phẩm phần mềm được chia thành các đơn vị nhỏ cân đối và có quan hệ hữu cơ không trùng lặp và có thể tổ hợp từng nhóm để tạo ra các chức năng mới. 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. Các chương trình phải được xây dựng trên các ngôn ngữ lập trình mới và phổ dụng.

+  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 (lỗi số bao nhiêu, vị trí lỗi, nội dung lỗi, cách khắc phục).

- 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. Lượng tối đa của sản phẩm quản lý được (ví dụ: trong Excel quản lý được 65536 bản ghi, FoxPro quản lý được 255 trường).

+ 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. Nếu phát triển trên cái cũ thì phải tiếp theo được những cái hay của nó đồng thời phải cung cấp được các chức năng mới tốt hơn so với cái đã có.

- 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 hàng. Các chức năng phải có tính đối xứng, nghĩa là: có tạo lập thì có xoá bỏ, có mở thì có đóng, có tiếp theo thì cũng cho phép trở về, …

- 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 (menu), các thông báo, cú pháp đơn giản, rõ ràng, dễ nhớ, dễ thao tác, dễ tăng cường các chức năng, dễ mở rộng và cải tiến.

6. Tiêu chuẩn ISO 9126?

- Functionality. Mức độ mà phần mềm đáp ứng các yêu cầu, được thể hiện qua các thuộc tính con sau: tính phù hợp, độ chính xác, khả năng tương tác, tính tuân thủ, an ninh toàn.

- Reliability. Lượng thời gian mà phần mềm sẵn sàng cho sử dụng, được thể hiện qua các thuộc tính con sau: sự trưởng thành, khả năng chịu lỗi, khả năng phục hồi.

- Usability. Phần mềm được sử dụng dễ dàng, được thể hiện qua các thuộc tính con sau: dễ hiểu, dễ học, dễ thao tác.

- Efficiency. Phần mềm sử dụng các tài nguyên hệ thống một cách tối ưu, được thể hiện qua các thuộc tính con: thời gian thực hiện, lượng tài nguyên sử dụng.

- Maintainability. Phần mềm dễ sửa chữa, được thể hiện qua các thuộc tính con: khả năng phân tích được, dễ thay đổi, ổn định, kiểm thử được.

- Portability. Phần mềm dễ chuyển từ môi trường này sang môi trường khác, được thể hiện qua các thuộc tính con: tính thích ứng, dễ cài đặt, tính phù hợp, dễ thay thế.

X. Các chủ đề khác trong SE

1. Vấn đề quản lý dự án phần mềm, các công việc chính trong quản lý dự án?

* Quản lý dự án phần mềm:

-  Liên quan đến các hoạt động đảm bảo:

+ Phần mềm được giao vào thời gian và đúng tiến độ;

+ Phù hợp với các yêu cầu của các tổ chức phát triển và khách hàng.

- Quản lý dự án là cần thiết vì: Việc phát triển phần mềm luôn bị hạn chế ngân sách và lịch trình được thiết lập bởi tổ chức phát triển phần mềm.

* Những nét riêng của Software management:

- Sản phẩm vô hình.

- Phần mềm là loại sản phẩm linh hoạt duy nhất.

- Quy trình phát triển phần mềm không được chuẩn hóa.

- Nhiều dự án phần mềm chỉ được thực hiện một lần.

* Management activities:

- Proposal writing (viết đề xuất).

- Project planning and scheduling (Lập kế hoạch và lập lịch dự án).

- Project costing (Lập chi phí dự án).

- Project monitoring and reviews (Giám sát và ra soát dự án).

- Personnel selection and evaluation (Lựa chọn nhân sự và đánh giá).

- Report writing and presentations (Ghi chép và báo cáo thống kê).

2. Vấn đề quản lý rủi ro?

Quản lý rủi ro để giảm tối thiểu khả năng rủi ro trong khi đó tăng tối đa những cơ hội tiềm năng. Những tiến trình chính bao gồm:

- Lập kế hoạch quản lý rủi ro: quyết định tiếp cận và hoạch định những công việc quản ký rủi ro cho dự án như thế nào

- Nhận biết rủi ro: xác định yếu tố rủi ro nào ảnh hưởng tới 1 dự án và tài liệu về những đặc điểm của chúng.

- Phân tích tính chất rủi ro: đặc điểm, phân tích rủi ro, ưu tiên xem xét những ảnh hưởng của chúng tới mục tiêu của dự án.

- Phân tích mức độ rủi ro: xem xét khả năng có thể xảy ra và hậu quả của những rủi ro.

- Kế hoạch đối phó rủi ro: thực hiện những bước đề cao những cơ hội và cắt giảm bớt những mối đe dọa đáp ứng những mục tiêu của dự án.

- Giám sát và kiểm soát rủi ro: giám sát rủi ro đã phát hiện, nhaann biết rủi ro mới, cắt giảm rủi ro và đánh giá hiệu quả của việc cắt giảm rủi ro.

3. Vấn đề lập lịch trong quản lý dự án?

- Project scheduling:

+ Chia dự án thành các nhiệm vụ và dự toán thời gian, nguồn lực cần thiết để hoàn thành mỗi nhiệm vụ.

+ Tổ chức thực hiện các nhiệm vụ đồng thời để sử dụng tối ưu lực lượng lao động.

+ Giảm thiểu sự phụ thuộc giữa nhiệm vụ để tránh sự chậm trễ gây ra bởi một nhiệm vụ nào đó để dự án hoàn thành đúng tiến độ.

+ Phụ thuộc vào trực giác và kinh nghiệm quản lý dự án.

- Scheduling problems:

+ Đánh giá mức độ khó khăn của vấn đề và chi phí phát triển giải pháp là một bài toán khó.

+ Năng suất lao động không tỷ lệ thuận với số lượng người làm việc trên một nhiệm vụ.

+ Thêm người vào dự án chậm làm cho dự án bị kéo dài do phát sinh các chi phí truyền thông.

4. Cách định giá phần mềm?

- xây dựng yêu cầu công việc, chuẩn hóa nhu cầu thông tin.

- khảo sát, xây dựng và tối ưu hóa các quy trình công việc, các phương pháp/công nghệ thực hiện công việc.

- thiết lập các tiêu chuẩn đánh giá hiệu quả của đề án Ứng dụng CNTT sẽ triển khai và phương pháp đo tính các hiệu quả này.

- thiết kế giải pháp pm và chuẩn hóa các quy trình công việc.

- lập trình pm, xây dựng tài liệu hướng dẫn và các công cụ trợ giúp liên quan.

- kiểm thử pm (testing).

- thiết lập cấu hình hệ thống ban đầu và chuyển đổi dữ liệu.

- tái cơ cấu tổ chức và xây dựng các quy định liên quan cho phù hợp với quy trình công việc mới.

- tổ chức triển khai áp dụng bước đầu đào tạo và hướng dẫn sd.

- đo tính hiệu quả của đề án theo các phương pháp đã đề ra.

- hiệu chỉnh pm và các quy trình công việc.

- xd phương pháp triển khai đại trà.

- tổ chức triển khai áp dụng đại trà và đào tạo hướng dẫn sd.

- công tác hỗ trợ bảo trì sau triển khai.

- đánh giá tổng thể đề án, quyết toán và nghiệm thu đề án.

5. Vấn đề cải tiến quy trình?

- Hiểu biết về các quy trình hiện có và giới thiệu quá trình thay đổi để cải thiện chất lượng sản phẩm, giảm chi phí hoặc đẩy nhanh tiến độ.

- Hầu hết các công việc cải tiến quy trình cho đến nay tập trung vào việc giảm khiếm khuyết. Điều này phản ánh sự quan tâm ngày càng tăng của ngành công nghiệp đối với chất lượng.

- Tuy nhiên, các thuộc tính khác của quá trình sản xuất phát triển cũng cần được cải tiến.

6. Chuẩn CMM/CMMI?

- CMMI viết tắt cho Capability Maturity Model Integration - Mô hình trưởng thành năng lực tích hợp - và là khuôn khổ cho cải tiến qui trình phần mềm. Nó dựa trên khái niệm về các thực hành tốt nhất về kĩ nghệ phần mềm và giải thích kỉ luật mà các công ty có thể dùng để cải tiến các qui trình của họ.

- Mô hình CMMI là một khung các giải pháp tối ưu cho quá trình sản xuất phần mềm. Phiên bản CMMI-DEV hiện nay (CMMI cho chuyên viên phát triển), mô tả những giải pháp tốt nhất trong quá trình kiểm soát, đo lường và kiểm tra các quy trình phát triển phần mềm. Mô hình CMMI không tập trung mô tả chính các quá trình mà chỉ mô tả đặc điểm của các quá trình hiệu quả, vì vậy mô hình CMMI đưa ra chỉ dẫn cho các công ty để họ có thể tự mình phát triển hoặc điều chỉnh chính các quá trình của họ.
          - Mô hình CMMI được mô tả trên trang web chính thức CMMI website: Dự án CMMI là một nỗ lực chung nhằm cung cấp các mô hình để cải thiện nâng cấp các sản phẩm và quy trình. Trọng tâm chính của dự án là tập trung xây dựng các công cụ hỗ trợ việc cải thiện các quy trình dùng để phát triển và ổn định các hệ thống và sản phẩm. Kết quả của dự án CMMI là một bộ các sản phẩm cung cấp một phương pháp tiếp cận tích hợp trên toàn doanh nghiệp để cải thiện các quy trình sản xuất mà vẫn có thể giảm bớt nhân công dư thừa, độ phức tạp, và chi phí từ việc sử dụng các mô hình CMM (quy trình quản lý sản xuất phẩn mềm) riêng lẻ và nhiều mô hình CMM.

- Khác biệt giữa ISO 9001:2000 và CMM/CMMI:
+ ISO 9001 là một tiêu chuẩn quốc tế về quản lý, các điều khoản gọi là “yêu cầu” quy định những điểm cần phải làm (what to do), không chỉ ra việc đó nên làm như thế nào (how to do).
+ CMM/CMMi là một mô hình, cung cấp các hướng dẫn và kinh nghiệm thực tế dùng để phát triển, cải tiến và đánh giá năng lực của quy trình.

+ CMMi không phải là một tiêu chuẩn, tùy vào từng tổ chức, cách thực hiện khác nhau rất nhiều.

+ Về nguyên tắc, ISO bao gồm (ở mức cao) hầu hết các quy trình chủ chốt của CMM/CMMi, tuy nhiên ISO được dùng cho hầu hết mọi ngành nghề, do vậy không cụ thể và gần gũi với công việc đặc thù có liên quan đến phần mềm như CMM/CMMi. ISO không cung cấp các ví dụ và kinh nghiêm cụ thể như CMM/CMMi

- Lợi ích CMMI:

+ The CMMI Product Suite is at the forefront of process improvement because it provides the latest best practices for product and service development and maintenance.     Cải tiến năng lực của các tổ chức phần mềm bằng cách nâng cao kiến thức và kỹ năng của lực lượng lao động.

+ Đảm bảo rằng năng lực phát triển phần mềm  là thuộc tính của tổ chức không phải của một vài cá thể.

+ Hướng các động lực của cá nhân với mục tiêu tổ chức.

+ Duy trì tài sản con người, duy trì nguồn nhân lực chủ chốt trong tổ chức.

+ Lợi ích CMM mang lại cho Doanh nghiệp gói gọn trong  4 từ: Attract, Develop, Motivate và Organize.

- Lợi ích CMM mang lại cho người lao động:

+  Môi trường làm việc, văn hóa làm việc tốt hơn.

+  Vạch rõ vai trò và trách nhiệm của từng vị trí công việc.

+  Đánh giá đúng năng lực, công nhận thành tích.

+ Chiến lược, chính sách đãi ngộ luôn được quan tâm.

+ Có cơ hội thăng tiến.

+ Liên tục phát triển các kỹ năng cốt yếu.