Câu 1. Phân biệt các định nghĩa về phần mềm: các quan điểm khác nhau, các định nghĩa theo chuẩn IEEE.

ĐN1:

Các lệnh (chương trình máy tính) khi được thực hiện thì cung cấp những chức năng và kết quả mong muốn

Các cấu trúc dữ liệu làm cho chương trình thao tác thông tin thích hợp

Các tư liệu mô tả thao tác và cách sử dụng chương trình

ĐN2:

Trong một hệ thống máy tính, nếu trừ bỏ đi các thiết bị và các loại phụ kiện thì phần còn lại chính là phần mềm (SW)

• Nghĩa hẹp: SW là dịch vụ chương trình để tăng khả năng xử lý của phần cứng của máy tính (như hệ điều hành - OS)

• Nghĩa rộng: SW là tất cả các kỹ thuật ứng dụng để thực hiện những dịch vụ chức năng cho mục đích nào đó bằng phần cứng

Câu 2. Khái niệm về phần mềm: phân loại phần mềm, đặc tính chung của phần mềm, một số khái niệm cơ bản liên quan đến phần mềm: che phủ thông tin, trừu tượng hóa.

 phân loại phần mềm

o Phần mềm hệ thống (System SW)

o Phần mềm thời gian thực (Real-time SW)

o Phần mềm nghiệp vụ (Business SW)

o Phần mềm tính toán KH&KT (Eng.&Scie. SW)

o Phần mềm nhúng (Embedded SW)

o Phần mềm máy tính cá nhân (Personal computer SW)

o Phần mềm trên Web (Web-based SW)

o Phần mềm trí tuệ nhân tạo (AI SW)

 Đặc tính chung của phần mềm

o Là hàng hóa vô hình, không nhìn thấy được

o Chất lượng phần mềm: không mòn đi mà có xu hướng tốt lên sau mỗi lần có lỗi (error/bug) được phát hiện và sửa

o Phần mềm 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

o Chức năng của phần mềm thường biến hóa, thay đổi theo thời gian (theo nơi sử dụng)

o Hiệu ứng làn sóng trong thay đổi phần mềm

o Phần mềm vốn chứa ý tưởng và sáng tạo của tác giả/nhóm làm ra nó

o Cần khả năng "tư duy nhị phân" trong xây dựng, phát triển phần mềm

o Có thể sao chép rất đơn giản

 Che giấu thông tin

o Để phân rã phần mềm thành các môđun một cách tốt nhất, cần tuân theo nguyên lý che giấu thông tin: "các môđun nên được đặc trưng bởi những quyết định thiết kế sao cho mỗi môđun ẩn kín đối với các môđun khác" [Parnas1972]

o Rất hữu ích cho kiểm thử và bảo trì phần mềm

 Trừu tượng hóa

o Abstraction cho phép tập trung vấn đề ở mức tổng quát, gạt đi những chi tiết mức thấp ít liên quan

o 3 mức trừu tượng

o Trừu tượng thủ tục: dãy các chỉ thị với chức năng đặc thù và giới hạn nào đó

o Trừu tượng dữ liệu: tập hợp dữ liệu mô tả đối tượng dữ liệu nào đó

o Trừu tượng điều khiển: Cơ chế điều khiển chương trình không cần đặc tả những chi tiết bên trong

o Ví dụ: Mở cửa. Thủ tục: Mở gồm . . .; Dữ liệu: Cửa là . . .

Câu 3. Khái niệm kiến trúc phần mềm: quan điểm phân cấp, quan điểm thực thi, các định nghĩa chuẩn về kiến trúc phần mềm.

 Khái niệm: (wiki)

Kiến trúc phần mềm của một chương trình máy tính hay một hệ thống tính toán là cấu trúc của các thành phần trong hệ thống đó. Kiến trúc phần mềm bao gồm các phần tử phần mềm, các thuộc tính và mối quan hệ giữa chúng. Ngoài ra, thuật ngữ "kiến trúc phần mềm" cũng đề cập đến các tài liệu kiến trúc phần mềm của một hệ thống, thuận tiện cho việc trao đổi thông tin giữa các thành viên trong một dự án. Kiến trúc phần mềm giúp việc quyết định ở mức cao trong thiết kế phần mềm dễ dàng hơn và cho phép tái sử dụng các thành phần và mẫu thiết kế của các dự án

 Phần mềm nhìn từ cấu trúc phân cấp

o Cấu trúc phần mềm là cấu trúc phân cấp (hierarchical structure): mức trên là hệ thống (system), dưới là các hệ thống con (subsystems)

o Dưới hệ thống con là các chương trình

o Dưới chương trình là các Modules hoặc Subroutines với các đối số (arguments)

 Một số khung nhìn khác

o Khung nhìn theo các chức năng/view logic (Functional/logic view)

o Khung nhìn theo mã nguồn (Code view)

o Khung nhìn theo tư tưởng phát triển/ cấu trúc (Development/structural view)

o Khung nhìn về xử lý đồng thời /tiến trình / thread (Concurrency/process/thread view)

o Khung nhìn vật lý /view triển khai / (Physical/deployment view )

o Khung nhìn theo hành động người sử dụng (User action/feedback view )

 quan điểm thực thi: ko thấy thông tin

Câu 4. Khủng hoảng phần mềm là gì. Khủng hoảng kinh tế và khủng hoảng phần mềm. Bài học thực tế giai đoạn 1997-2000 và 2006-2010 của thế giới.

 Khủng hoảng phần mềm:

o 10/1968 tại Hội nghị của NATO các chuyên gia phần mềm đã đưa ra thuật ngữ "Khủng hoảng phần mềm" (Software crisis). Qua hàng chục năm, thuật ngữ này vẫn được dùng và ngày càng mang tính cấp bách

o Khủng hoảng là gì ? [Webster's Dict.]

o Điểm ngoặt trong tiến trình của bất kỳ cái gì; thời điểm, giai đoạn hoặc biến cố quyết định hay chủ chốt

o Điểm ngoặt trong quá trình diễn biến bệnh khi trở nên rõ ràng bệnh nhân sẽ sống hay chết

o Trong phần mềm: Day dứt kinh niên (chronic affliation, by Prof. Tiechrow, Geneva, Arp. 1989)

o Là sự day dứt kinh niên (kéo dài theo thời gian hoặc thường tái diễn, liên tục không kết thúc) gặp phải trong phát triển phần mềm máy tính, như

o Phải làm thế nào với việc giảm chất lượng vì những lỗi tiềm tàng có trong phần mềm ?

o Phải xử lý ra sao khi bảo dưỡng phần mềm đã có ?

o Phải giải quyết thế nào khi thiếu kỹ thuật viên phần mềm?

o Phải chế tác phần mềm ra sao khi có yêu cầu phát triển theo qui cách mới xuất hiện ?

o Phải xử lý ra sao khi sự cố phần mềm gây ra những vấn đề xã hội ?

 Bài học thực tế giai đoạn 1997-2000 và 2006-2010 của thế giới.

o Chưa thấy thông tin

Câu 5: Những vấn đề trong sản xuất phần mềm: công nghệ, nhân lực, nhu cầu tăng trưởng, khả năng ứng dụng, bài học về "thế giới phẳng"

Những vấn đề trong sản xuất phần mềm (14 vấn đề chính):

1. Không có phương pháp mô tả rõ ràng định nghĩa yêu cầu của người dùng (khách hàng), sau khi bàn giao sản phẩm dễ phát sinh những trục trặc (troubles)

2. Với những phần mềm quy mô lớn, tư liệu đặc tả đã cố định thời gian dài, do vậy khó đáp ứng nhu cầu thay đổi của người dùng một cách kịp thời trong thời gian đó

3. Nếu không có Phương pháp luận thiết kế nhất quán mà thiết kế theo cách riêng (của công ty, nhóm), thì sẽ dẫn đến suy giảm chất lượng phần mềm (do phụ thuộc quá nhiều vào con người)

4. Nếu không có chuẩn về làm tư liệu quy trình sản xuất phần mềm, thì những đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm

5. Nếu không kiểm thử tính đúng đắn của phần mềm ở từng giai đoạn mà chỉ kiểm ở giai đoạn cuối và phát hiện ra lỗi, thì thường bàn giao sản phẩm không đúng hạn

6. Nếu coi trọng việc lập trình hơn khâu thiết kế thì thường dẫn đến làm giảm chất lượng phần mềm

7. Nếu coi thường việc tái sử dụng phần mềm (software reuse), thì năng suất lao động sẽ giảm

8. Phần lớn trong quy trình phát triển phần mềm có nhiều thao tác do con người thực hiện, do vậy năng suất lao động thường bị giảm

9. Không chứng minh được tính đúng đắn của phần mềm, do vậy độ tin cậy của phần mềm sẽ giảm

10. Chuẩn về một phần mềm tốt không thể đo được một cách định lượng, do vậy không thể đánh giá được một hệ thống đúng đắn hay không

11. Khi đầu tư nhân lực lớn vào bảo trì sẽ làm giảm hiệu suất lao động của nhân viên

12. Công việc bảo trì kéo dài làm giảm chất lượng của tư liệu và ảnh hưởng xấu đến những việc khác

13. Quản lý dự án lỏng lẻo kéo theo quản lý lịch trình cũng không rõ ràng

14. Không có tiêu chuẩn để ước lượng nhân lực và dự toán sẽ làm kéo dài thời hạn và vượt kinh phí của dự án

Bài học về "thế giới phẳng":

Chưa có thông tin

Câu 6: Lịch sử tiến triển Công nghệ học phần mềm, các phương pháp thiết kế phần mềm, quá trình tiến hóa phát triển của các phương pháp thiết kế phần mềm

 Lịch sử học công nghệ học phần mềm:

 Nửa đầu 1960: ít quan tâm đến phần mềm, chủ yếu tập trung nâng cao tính năng và độ tin cậy của phần cứng

 Giữa những năm 1960: Phát triển hệ điều hành như phần mềm lớn (IBM OS/360, EC OS). Xuất hiện nhu cầu về quy trình phát triển phần mềm lớn và quy trình gỡ lỗi, kiểm thử trong phạm vi giới hạn

 Năm 1968: Tại Tây Đức, Hội nghị khoa học của NATO đã đưa ra từ "Software Engineering". Bắt đầu bàn luận về khủng khoảng phần mềm và xu hướng hình thành CNHPM như một chuyên môn riêng

 Nửa cuối 1960: IBM đưa ra chính sách phân biệt giá cả giữa phần cứng và phần mềm. Từ đó, ý thức về phần mềm ngày càng cao. Bắt đầu những nghiên cứu cơ bản về phương pháp luận lập trình

 Nửa đầu những năm 1970: Nhằm nâng cao chất lượng phần mềm, không chỉ có các nghiên cứu về lập trình, kiểm thử, mà có cả những nghiên cứu đảm bảo tính tin cậy trong quy trình sản xuất phần mềm. Kỹ thuật: lập trình cấu trúc hóa, lập trình môđun, thiết kế cấu trúc hóa, vv

 Giữa những năm 1970: Hội nghị quốc tế đầu tiên về CNHPM được tổ chức (1975): International Conference on SE (ICSE)

 Nửa sau những năm 1970: Quan tâm đến mọi pha trong quy trình phát triển phần mềm, nhưng tập trung chính ở những pha đầu. ICSE tổ chức lần 2, 3 và 4 vào 1976, 1978 và 1979

• Nhật Bản có "Kế hoạch phát triển kỹ thuật sản xuất phần mềm" từ năm 1981

• Cuộc "cách tân sản xuất phần mềm" đã bắt đầu trên phạm vi các nước công nghiệp

 Nửa đầu những năm 1980: Trình độ học vấn và ứng dụng CNHPM được nâng cao, các công nghệ được chuyển vào thực tế. Xuất hiện các sản phẩm phần mềm và các công cụ khác nhau làm tăng năng suất sản xuất phần mềm đáng kể

• ICSE tổ chức lần 5 và 6 năm 1981 và 1982 với trên 1000 người tham dự mỗi năm

• Nhật Bản sang "Kế hoạch phát triển các kỹ thuật bảo trì phần mềm" (1981-1985)

 Nửa cuối những năm 1980 đến nay: Từ học vấn sang nghiệp vụ! Chất lượng phần mềm tập trung chủ yếu ở tính năng suất, độ tin cậy và tính bảo trì. Nghiên cứa hỗ trợ tự động hóa sản xuất phần mềm

• Nhật Bản có "Kế hoạch hệ thống công nghiệp hóa sản xuất phần mềm"(SIGMA: Software Industrialized Generator & Maintenance Aids, 1985-1990)

• Nhiều trung tâm, viện nghiên cứu CNHPM ra đời. Các trường đưa vào giảng dạy SE

 Hiện nay:

• Công nghiệp hóa sản xuất phần mềm bằng cách đưa những kỹ thuật công nghệ học (Engineering techniques) thành cơ sở khoa học của CNHPM

• Thể chế hóa lý luận trong sản xuất phần mềm và ứng dụng những phương pháp luận một cách nhất quán

• Tăng cường nghiên cứu và tạo công cụ trợ giúp sản xuất phần mềm

 Lịch sử tiến triển các phương pháp thiết kế phần mềm

Phương pháp luận trong CNHPM: bắt đầu từ những năm 1970

Trong phát triển phần mềm: nâng cao năng suất, độ tin cậy, giá thành - tính năng (productivity, reliability, cost-performance)

Tiến triển phương pháp thiết kế: Sơ khởi, Trưởng thành, Phát triển và Biến đổi

 Sơ khởi: nửa đầu 1970

 Khái niệm về tính môđun, cụ thể hóa từng bước trong phương pháp luận thiết kế

 N. Wirth: Chi tiết hóa từng giai đoạn. Thiết kế trên xuống. Lập trình môđun

 Trưởng thành: nửa cuối 1970

 Phương pháp luận về quy trình thiết kế phần mềm với phương pháp phân chia môđun và thiết kế trong từng môđun.

 L.L. Constantine, 1974: Thiết kế cấu trúc hóa (phân chia môđun);

 E.W. Dijkstra, 1972: Lập trình cấu trúc hóa (trong môđun) . Phương pháp M.A. Jackson (1975) và J.D. Warnier (1974)

 Trừu tượng hóa dữ liệu: B.H. Liskov (1974);D.L. Parnas (1972)

 Phát triển: nửa đầu 1980

 Triển khai các công cụ hỗ trợ phát triển phần mềm dựa trên các phương pháp và kỹ thuật đưa ra những năm 1970

 Bộ khởi tạo chương trình (program generators: pre-compiler; graphics-input editors, etc.)

 Ngôn ngữ đối thoại đơn giản (4GL, DB SQL)

 Hệ trợ giúp: Hệ trợ giúp kiểm thử; Hệ trợ giúp quản lý thư viện; Hệ trợ giúp tái sử dụng

 Biến đổi: nửa cuối 1980 đến nay

 Đưa ra các môi trường mới về phát triển phần mềm. Triển khai mới về kết hợp giữa CNHPM và CNH Tri thức (Knowledge Engineering)

 Triển khai những môi trường bậc cao về phát triển phần mềm; Tự động hóa sản xuất phần mềm; Chế phần mềm theo kỹ thuật chế thử (Prototyping); Lập trình hướng đối tượng - OOP; Hướng thành phần; Hỗ trợ phát triển phần mềm từ các hệ chuyên gia, vv

Câu 7: Định nghĩa Công nghệ học phần mềm: các định nghĩa, quan điểm, các định nghĩa chuẩn của IEEE.

a. IEEE [1993]: CNHPM là

Việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hóa trong phát triển, vận hành và bảo trì phần mềm;

(Nghiên cứu các phương pháp tiếp cận được dùng trong (1)

b. Bauer [1969]: CNHPM là việc thiết lập và sử dụng các nguyên tắc công nghệ học đúng đắn dùng để thu được phần mềm một cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các máy thực

c. Parnas [1987]: CNHPM là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người

d. Ghezzi [1991]: CNHPM là một lĩnh vực của khoa học máy tính, liên quan đến xây dựng các hệ thống phần mềm vừa lớn vừa phức tạp bởi một hay một số nhóm kỹ sư

e. Pressman [1995]: CNHPM là bộ môn tích hợp cả quy trình, các phương pháp, các công cụ để phát triển phần mềm máy tính

f. Sommerville [1995]: CNHPM là lĩnh vực liên quan đến lý thuyết, phương pháp và công cụ dùng cho phát triển phần mềm

g. K. Kawamura [1995]: CNHPM là lĩnh vực học vấn về các kỹ thuật, phương pháp luận công nghệ học (lý luận và kỹ thuật được hiện thực hóa trên những nguyên tắc, nguyên lý nào đó) trong toàn bộ quy trình phát triển phần mềm nhằm nâng cao cả chất và lượng của sản xuất phần mềm

h. Công nghệ học phần mềm: là lĩnh vực khoa học về các phương pháp luận, kỹ thuật và công cụ tích hợp trong quy trình sản xuất và vận hành phần mềm nhằm tạo ra phần mềm với những chất lượng mong muốn

Câu 8: Khái niệm vòng đời của phần mềm: các giai đoạn, đặc điểm, nội dung công việc từng giai đoạn.

Các vòng đời của phần mềm:

 Các pha trong vòng đời phần mềm:

 Pha xác định yêu cầu và thiết kế có vai trò quyết định đến chất lượng phần mềm, chiếm phần lớn công sức so với lập trình, kiểm thử và chuyển giao phần mềm

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

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

 Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm thử không còn lỗi

 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 không gây lỗi cho pha sau

 Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng quan trọng cho kiểm tra và đảm bảo chất lượng của từng quy trình và của chính phần mềm

 Cần 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 phần mềm

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

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

Câu 9: Quy trình phát triển phần mềm - các mô hình cơ bản: Mô hình thác nước, Mô hình chế thử (prototyping), Các mô hình tiến hóa.

 Mô hình tuyến tính (mô hình thác nước):

Điển hình là mô hình vòng đời cổ điển(mô hình thác nước) Classic life cycle /

waterfall model: là mô hình hay đựoc dùng nhất

Mô Hình Thác Nước

 Công nghệ học Hệ thống/Thông tin và mô hình hóa (System/Information engineering and modeling): thiết lập các yêu cầu, ánh xạ một số tập con các yêu cầu sang phần mềm trong quá trình tương tác giữa phần cứng, người và CSDL

 Phân tích yêu cầu (Requirements analysis): hiểu lĩnh vực thông tin, chức năng, hành vi, tính năng và giao diện của phần mềm sẽ phát triển. Cần phải tạo tư liệu và bàn thảo với khách hàng, người dùng

 Thiết kế (Design): là quá trình nhiều bước với 4 thuộc tính khác nhau của một chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ tục (thuật toán). Cần tư liệu hóa và là một phần quan trọng của cấu hình phần mềm

 Tạo mã / lập trình (Code generation / programming): Chuyển thiết kế thành chương trình máy tính bởi ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa thì lập trình có thể chỉ thuần túy cơ học

 Kiểm thử (Testing): Kiểm tra các chương trình và môđun cả về lôgic bên trong và chức năng bên ngoài, nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thì cho kết quả mong muốn

 Hỗ trợ / Bảo trì (Support / Maintenance): Đáp ứng những thay đổi, nâng cấp phần mềm đã phát triển do sự thay đổi của môi trường, nhu cầu

 Điểm yếu của Mô hình tuyến tính

 Thực tế các dự án ít khi tuân theo dòng tuần tự của mô hình, mà thường có lặp lại (như mô hình của Boehm)

 Khách hàng ít khi tuyên bố rõ ràng khi nào xong hết các yêu cầu

 Khách hàng phải có lòng kiên nhẫn chờ đợi thời gian nhất định mới có sản phẩm. Nếu phát hiện ra lỗi nặng thì là một thảm họa!

 Mô hình chế thử (Prototyping model)

 Khi nào sử dụng:

 Khi mới rõ mục đích chung chung của phần mềm, chưa rõ chi tiết đầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra

 Dùng như "Hệ sơ khai" để thu thập yêu cầu người dùng qua các thiết kế nhanh

 Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng

 Các mô hình tiến hóa: gia tăng, xoắn ốc, xoắn WINWIN ...

Phần lớn các hệ phần mềm phức tạp đều tiến hóa theo thời gian: môi trường thay đổi, yêu cầu phát sinh thêm, hoàn thiện thêm chức năng, tính năng

Các mô hình tiến hóa (evolutionary models) có tính lặp lại. Kỹ sư phần mềm tạo ra các phiên bản (versions) ngày càng hoàn thiện hơn, phức tạp hơn

Các mô hình: incremental, spiral, WINWIN spiral, concurrent development model

 Mô hình gia tăng (The incremental model)

 Kết hợp mô hình tuần tự và ý tưởng lặp lại của chế bản mẫu

 Sản phẩm lõi với những yêu cầu cơ bản nhất của hệ thống được phát triển

 Các chức năng với những yêu cầu khác được phát triển thêm sau (gia tăng)

 Lặp lại quy trình để hoàn thiện dần

 Mô hình xoắn ốc (spiral)

 Giao tiếp khách hàng: giữa người phát triển và khách hàng để tìm hiểu yêu cầu, ý kiến

 Lập kế hoạch: Xác lập tài nguyên, thời hạn và những thông tin khác

 Phân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạo hiểm quản lý

 Kỹ nghệ: Xây dựng một hay một số biểu diễn của ứng dụng

 Xây dựng và xuất xưởng: xây dựng, kiểm thử, cài đặt và cung cấp hỗ trợ người dùng (tư liệu, huấn luyện, . . .)

 Đánh giá của khách hàng: Nhận các phản hồi của người sử dụng về biểu diễn phần mềm trong giai đoạn kỹ nghệ và cài đặt

 Mô hình xoắn ốc - mạnh hay yếu?

• Tốt cho các hệ phần mềm quy mô lớn

• Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa

• Khó thuyết phục khách hàng 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ử

 Mô hình xoắn ốc WINWIN

 Nhằm thỏa hiệp giữa người phát triển và khách hàng, cả hai cùng "Thắng" (win-win)

• Khách thì có phần mềm thỏa mãn yêu cầu chính

• Người phát triển thì có kinh phí thỏa đáng và thời gian hợp lý

 Các hoạt động chính trong xác định hệ thống:

• Xác định cổ đông (stakeholders)

• Xác định điều kiện thắng của cổ đông

• Thỏa hiệp điều kiện thắng của các bên liên quan

 Mô hình phát triển đồng thời (The concurrent development model)

 Xác định mạng lưới những hoạt động đồng thời (Network of concurrent activities)

 Các sự kiện (events) xuất hiện theo điều kiện vận động trạng thái trong từng hoạt động

 Dùng cho mọi loại ứng dụng và cho hình ảnh khá chính xác về trạng thái hiện trạng của dự án

 Thường dùng trong phát triển các ứng dụng khách/chủ (client/server applications): system and componets are developed concurrently

Câu 10: Quy trình phát triển phần mềm - các mô hình hiện đại: Mô hình RAD, Phát triển theo thành phần, Quy trình phần mềm theo CMM, CMMI, Mô hình RUP (sơ lược)

 Mô hình theo thành phần (Component-based model)

 Gắn với những công nghệ hướng đối tượng (Object-oriented technologies) qua việc tạo các lớp (classes) có chứa cả dữ liệu và giải thuật xử lý dữ liệu

 Có nhiều tương đồng với mô hình xoắn ốc

 Với ưu điểm tái sử dụng các thành phần qua Thư viện / kho các lớp: tiết kiệm 70% thời gian, 80% giá thành, chỉ số sản xuất 26.2/16.9

 Với UML như chuẩn công nghiệp đang triển khai

 Mô hình RUP (Rational Unified Proces)

 Tổng quan

 Là phương pháp do công ty Phần mềm Rational tạo ra. RUP là một phương pháp khá lớn nên được áp dụng cho các dự án phần mềm lớn. Trong RUP việc tiếp cận được lặp đi lặp lại, mỗi lần lặp bao gồm một hoặc nhiều các bước phát triển.

 Phạm vi sử dụng: RUP có thể sử dụng cho phạm vi khá rộng các dự án, tuy nhiên phương pháp RUP khá phức tạp nên chủ yếu sử dụng trong các dự án phần mềm lớn.

 Ưu điểm

• Hiệu quả cao do lặp lại các bước.

• Thử nghiệm dự án dễ dàng hơn ngay cả khi chưa thực hiện xong.

• Việc giải quyết các vấn đề đã gặp phải trước đó dễ dàng hơn.

• Tiết kiệm thời gian.

 Nhược điểm

• RUP là một sản phẩm thương mại nên muốn sử dụng phải mua nó.

• RUP là một phương pháp rất phức tạp vì phải xây dựng quá trình thiết kế phần mềm rất cụ thể nên sẽ rất khó hiểu cho cả người quản lý dự án và các thành viên dự án. Do đó nó không thích hợp cho các dự án nhỏ.

• Để sử dụng RUP tất cả người tham gia dự án sẽ phải học làm việc với RUP.

• RUP là một sản phẩm thương mại nên muốn sử dụng phải mua nó.

 Các khái niệm căn bản

 Các kỹ thuật thế hệ 4 (Fourth generation techniques)

 Tập hợp các công cụ cho phép xác định đặc tính phần mềm ở mức cao, sau đó sinh tự động mã nguồn dựa theo đặc tả đó

 Các công cụ 4GT điển hình: ngôn ngữ phi thủ tục cho truy vấn CSDL; tạo báo cáo; xử lý dữ liệu; tương tác màn hình; tạo mã nguồn; khả năng đồ họa bậc cao; khả năng bảng tính; khả năng giao diện Web; vv

 4GT: How ?

 Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa khách và người phát triển là quan trọng

 Không nên bỏ qua khâu thiết kế. 4GT chỉ áp dụng để triển khai thiết kế qua 4GL

 Mạnh: giảm thời gian phát triển và tăng năng suất

 Yếu: 4GT khó dùng hơn ngôn ngữ lập trình, mã khó tối ưu và khó bảo trì cho hệ thống lớn Þ cần kỹ năng của kỹ sư phần mềm

 Tương lai: 4GT với mô hình theo thành phần

 Mô hình phát triển ứng dụng nhanh (Rapid Application Development: RAD)

 Là quy trình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày)

 Xây dựng dựa trên hướng thành phần (Component-based construction) với khả năng tái sử dụng (reuse)

 Gồm một số nhóm (teams), 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á (Business, Data, Process, Appl. Generation, Test)

 RAD: Business modeling

 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 đ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 ?

 RAD: Data and Process modeling

 Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng

 Process modeling: Các đối tượng dữ liệu đượ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ý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu

 RAD: Appl. Generation and Testing

 Application Generation: Dùng các kỹ thuật thế hệ 4 để tạo phần mềm từ các thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này. Dùng các công cụ tự động để xây dựng phần mềm

 Testing and Turnover: Kiểm thử các thành phần mới và kiểm chứng mọi giao diện (các thành phần cũ đã được kiểm thử và dùng lại)

 Hạn chế của RAD:

 Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năng chính

 Yêu cầu hai bên giao kèo trong thời gian ngắn phải có phần mềm hoàn chỉnh, thiếu trách nhiệm của một bên dễ làm dự án đổ vỡ

 RAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụng không thể môđun hóa hoặc đòi hỏi tính năng cao

 Mạo hiểm kỹ thuật cao thì không nên dùng RAD

 CMM: Capability Maturity Model SEI: Mô hình thuần thục khả năng

 Tại sao phải sử dụng mô hình CMM trong công nghệ làm phần mềm

 Một số khó khăn khi không sử dụng CMM:

• - Các tiến trình phần mềm thường bị thay đổi cập nhật mà không có sự chuần bị trước. Đặc tả một tiến trình phần mềm không chặt chẽ, dẫn đến sự khủng hoảng khi thực hiện một dự án.

• - Thiếu cơ sở để đánh giá chất lượng phần mềm, để đưa ra phương thức tiến hành và cách giải quyết các vấn đề phát sinh.

 Một số thuận lợi khi sử dụng CMM:

• Dễ dàng quản lý phát triển phần mềm. Các tiến trình được cập nhật qua sự điều khiển của các nhà phần tích và kiểm thử.

• Vai trò, trách nhiệm của mỗi thành viên trong các tiến trình được phân định rõ ràng.

• Quản lý chất lượng của phần mềm, thoả mãn các yêu cầu khách hàng. Có cơ sơ chuẩn xác đánh giá chất lượng, thời gian, chi phí và phân tích dự án và các tiến trình.

 Các khái niệm cơ bản trong CMM

 a. Tiến trình (Process)

• Một tiến trình phần mềm là một tập hợp các hành động, phương thức, thực hành, thay đổi mà người ta dùng để duy trì và phát triển phần mềm cũng như các thành phần liên quan tới chúng (ví dụ: kế hoạch dự án, thiết kế, lập trình, kiểm thử, tài liệu hướng dẫn...).

 b. Khả năng tiến trình phần mềm (Software Process Capability)

• Đây là khái niệm cho biết phạm vi kết quả có thể mong đợi của một tiến trình phần mềm. Đồng thời nó còn dự đoán khả năng làm dự án phần mềm tiếp theo của công ty.

 c. Thực thi tiến trình phần mềm (Software Process Performance)

• Thực thi tiến trình phần mềm cho biết kết quả thực tế của một tiến trình phần mềm. Như vậy nó hướng tới kết quả đạt được còn khả năng tiến trình phần mềm cho thấy kết quả có thể mong đợi. Do phụ thuộc vào đặc trưng của dự án và từng trường hợp cụ thể, nên kết quả thực tế thường không phản ánh đầy đủ khả năng tiến trình của một công ty.

 d. Thuần thục tiến trình phần mềm (Software process maturity)

• Chỉ rõ một tiến trình phần mềm được xác định, quản lý, đánh giá, điều khiển, đạt hiệu quả một cách rõ ràng. Cho biết khả năng phát triển, chỉ ra giá trị của tiến trình phần mềm, tính vững chắc của dự án.

 Mô hình chi tiết các thành phần trong cấu trúc CMM.

 Mô hình 5 mức của CMM

 Mức 1: Khởi đầu (Initial Level)

• a. Tính chất:

Tiến trình phần mềm mang tính chất tuỳ tiện, lộn xộn, có ít tiến trình được xác định trước, hiệu quả của công việc mang tính riêng lẻ. Khó có được một môi trường làm việc ổn định. Kế hoạch và ngân sách, chất lượng sản phẩm và vận hành không thể dự đoán trước được. Quá trình vận hành phụ thuộc vào khả năng của từng cá nhân riêng lẻ, và thường xuyên thay đổi do phụ thuộc vào kỹ năng, trình độ hiểu biết và các hoạt động của từng thành viên trong dự án.

• b. Các KPA:

Không có.

 Mức 2: Lặp (Repeatable Level)

• a. Tính chất:

Có sự cải tiến hơn, chiến lược quản lý dự án và thủ tục để thực thi chiến lược ấy được thiết lập. Các kế hoạch và quản lý dự án mới được dựa trên những kinh nghiệm của dự án cũ. Kết quả là đưa được những hiệu quả quản lý tiến trình của một dự án nµy vào một dự án khác. Điều này cho phép lặp lại (repeatable) những thành công đối với một dự án tương tự mặc dù có thể các dự án này cũng có những điểm khác biệt.

• b. Các KPA

Requirements Management (Các yêu cầu về quản lý )

Software Project Planning (lập kế hoạch dự án phần mềm).

Software Project Tracking and Oversight (điều chỉnh và giám sát dự án phần mềm).

Software Subcontract Management (quản lý các hợp đồng phần mềm phụ)

Software Quality Assurance (đảm bảo chất lượng phần mềm)

Software Configuration Management (quản lý cấu hình phần mềm)

 Mức 3: Định nghĩa (Defined Level)

• a.Tính chất

o Lập được tài liệu tiến trình tiêu chuẩn đối với việc phát triển và bảo trì phần mềm có tổ chức, bao gồm cả công nghệ phần mềm, các tiến trình quản lý, và các tiến trình tích hợp với nhau (nghĩa rằng đầu ra của một tiến trình sẽ là đầu vào của tiến trình tiếp theo ).

o Một tiến trình được định nghĩa tốt gồm có các tính chất như có tiêu chuẩn, đầu vào, tiêu chuẩn và thủ tục rõ ràng để tiến hành công việc, kiểm tra các đầu ra.

• b. Các KPA

o Organization Process Focus (tập trung vào tiến trình tổ chức)

o Organization Process Definition (định nghĩa tiến trình tổ chức)

o Training Program (chương trình tập huấn)

o Integrated Software Management (quản lý phần mềm tích hợp)

o Software Product Engineering (công nghệ sản xuất phần mềm)

o Intergroup Coordination (kết hợp giữa các nhóm)

o Peer Reviews (rà soát ngang hàng)

 Mức 4: Quản lý (Managed Level)

• a. Tính chất của mức 4

o Mục tiêu là điều khiển tiến trình. Các tiến trình phần mềm được quản lý để vận hành ổn định, an toàn. Có những đánh giá phần mềm và chất lượng, hiệu quả các hoạt động trong tiến trình. Do các tiến trình ổn định và được đánh giá đúng nên khi có các trường hợp ngoại lệ, sẽ xác định và chỉ rõ những nguyên nhân gây ra biến đổi.

• b. Các KPA của mức 4

o Quantitative Process Management (quản lý tiến trình định lượng)

o Software Quality Management (quản lý chất lượng phần mềm)

 Mức 5: Tối ưu hoá (Optimizing Level)

• a. Các tính chất

o Tiếp tục cải tiến tiến trình, có thể xác định được những điểm mạnh và điểm yếu của tiến trình, có khả năng phân tích các khiếm khuyết, xác định các nguyên nhân gây ra có tránh các khiếm khuyết này.

• b. Các KPA

o Defect Prevention (phòng chống khiếm khuyết)

o Technology Change Management (quản lý thay đổi về công nghệ)

 Khả năng quan sát tiến trình, khả năng tiến trình và dự đoán trong mô hình CMM

 Khả năng quan sát tiến trình đối với từng mức của CMM ( 5 levels ).

 Khả năng tiến trình và dự đoán theo các mức của CMM

 Cách thức sử dụng mô hình CMM

 Định giá tiến trình phần mềm (Software process assessments ) xác định trạng thái của tiến trình phần mềm hiện tại của tổ chức, xác định mức độ ưu tiên đối với các vấn đề có liên quan tới tiến trình phần mềm khi xử lý chúng và xây dựng hệ thống hỗ trợ phát triển tiến trình phần mềm.

 Đánh giá khả năng phần mềm (Software capability evaluations) xác định các nhà thầu có đủ tư cách triển khai một dự án phần mềm hoặc quản lý hiện trạng của một hệ thống phần mềm đã có sẵn.

