(NB) Giáo trình Nhập môn công nghệ phần mềm cung cấp cho sinh viên những kiến thức cơ bản về tất cả mọi hoạt động liên quan đến phát triển phần mềm và kiến thức cơ bản về UML trong phát triển phần mềm.
GIỚI THIỆU CHUNG
Khái niệm về phần mềm
Mục tiêu: Nắm được định nghĩa phần mềm;
Nắm được các đặc tính của phần mềm.
1.1 Định nghĩa chung về phần mềm
Trong ba thập kỷ đầu tiên của thời đại tính toán, mục tiêu chính là phát triển ứng dụng phần cứng máy tính để giảm chi phí xử lý và lưu trữ dữ liệu Đến thập kỷ 80, sự tiến bộ trong vi điện tử đã mang lại năng lực tính toán mạnh mẽ hơn với giá thành thấp hơn đáng kể Hiện nay, thách thức chủ yếu đã chuyển sang cải tiến chất lượng và giảm chi phí cho các giải pháp dựa trên máy tính, chủ yếu được triển khai qua phần mềm.
Vậy phần mềm là gì? Định nghĩa 1:
Phần mềm là tập họp:
1 Các lệnh (chương trình máy tính) khi được thực hiện sẽ cung cấp những chức năng và kết quả mong muốn.
2 Cấu trúc dữ liệu làm cho chương trình thao tác thông tin thích hợp.
3 Các tư liệu mô tả thao tác và cách sử dụng chương trình. Định nghĩa 2:
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à các phần mềm.
Nghĩa hẹp- phần mềm là dịch vụ chương trình để tăng khả năng xử lý của phần cứng máy tính.
Phần mềm được hiểu rộng rãi là tập hợp các kỹ thuật ứng dụng nhằm cung cấp các dịch vụ chức năng cho những mục đích cụ thể thông qua phần cứng.
Tóm lại : Phần mềm được biểu diễn như hình 1.1.
Hình 1.1 Phần mềm là gi?
■ Nhóm các kỹ thuật, phương pháp luận bao gồm:
-Các khái niệm và trình tự cụ thể hoá của một hệ thống;
-Các phương pháp tiếp cận và giải quyết vấn đề;
-Các trình tự thiết kế và phát triển được chuẩn hoá (quy trình);
-Các phương pháp đặc tả, yêu cầu, thiết kế hệ thống, thiết kế chương trình, kiểm thử, toàn bộ quy trình quản lý phát triển phần mềm.
Nhóm các chương trình đóng vai trò là giao diện giữa phần cứng và con người, thông qua các lệnh chỉ thị giúp máy tính hiểu và thực hiện trình tự thao tác xử lý dữ liệu.
-Những tài liệu hữu ích, có giá trị cao và rất cần thiết để phát triển, vận hành và bảo trì phần mềm.
Để phát triển phần mềm đáng tin cậy, việc tạo ra tài liệu chất lượng cao là rất quan trọng Những tài liệu này bao gồm đặc tả yêu cầu, mô tả thiết kế cho từng loại phần mềm, điều kiện kiểm thử, thủ tục vận hành và hướng dẫn thao tác.
Sản xuất phần mềm chủ yếu dựa vào con người, đặc biệt là kỹ sư phần mềm Mỗi kỹ sư có khả năng hệ thống hoá trừu tượng, kỹ năng lập trình, công nghệ và kinh nghiệm làm việc khác nhau, điều này ảnh hưởng đến chất lượng sản phẩm Tầm nhìn và sự hiểu biết của từng cá nhân cũng đóng vai trò quan trọng trong quá trình phát triển phần mềm.
-Phần mềm phụ thuộc nhiều vào ý tưởng và kỹ năng của con người/nhóm tác giả.
Phần mềm có những đặc tính riêng biệt giúp phân biệt nó với phần cứng Trong khi phần cứng được tạo ra thông qua các quy trình sáng tạo của con người như phân tích, thiết kế, xây dựng và kiểm thử, thì phần mềm lại tồn tại dưới dạng hệ thống logic, không phải là hệ thống vật lý Điều này khiến cho phần mềm có những đặc điểm khác biệt so với phần cứng.
Phần mềm được phát triển hay được kỹ nghệ hoá, nó không được chế tạo theo nghĩa cổ điển.
Mặc dù phát triển phần mềm và chế tạo phần cứng có một số điểm tương đồng, nhưng chúng thực sự là hai hoạt động khác biệt Cả hai đều yêu cầu thiết kế tốt để đạt được chất lượng cao, tuy nhiên, trong giai đoạn chế tạo phần cứng, có thể phát sinh các vấn đề về chất lượng mà phần mềm không gặp phải hoặc dễ dàng sửa đổi hơn.
Cả hai hoạt động này đều phụ thuộc vào con người nhưng mối quan hệ giữa người được áp dụng và công việc là hoàn toàn khác nhau.
Phần mềm không hỏng đi
Phần mềm không chịu ảnh hưởng từ môi trường, điều này giúp nó không bị hao mòn như phần cứng Vì vậy, theo lý thuyết, tỷ lệ hỏng hóc của phần mềm sẽ theo một đường cong nhất định, như thể hiện trong hình 1.2.
Những khiếm khuyết chưa được phát hiện có thể khiến chương trình gặp tỷ lệ hỏng hóc cao ngay từ đầu Tuy nhiên, khi những khiếm khuyết này được khắc phục, đường cong hiệu suất trở nên phẳng Mặc dù phần mềm không bị lão hóa, nhưng nó lại rơi vào trạng thái "suy thoái" Sự mâu thuẫn này có thể được giải thích rõ ràng qua hình 1.3.
Hình 1.2 Đường cong hỏng hóc phần mềm (lý tưởng)
Hình 1.3 Đường cong hỏng hóc thực tế của phần mềm
Trong quá trình sử dụng phần mềm, các thay đổi thường xuyên xảy ra, dẫn đến việc xuất hiện những khiếm khuyết mới Điều này làm cho đường cong tỷ lệ hỏng hóc trở nên có đầu nhọn, và trước khi nó trở về mức ổn định ban đầu, một thay đổi khác lại xảy ra, tạo ra đỉnh nhọn mới Qua thời gian, tỷ lệ hỏng hóc tối thiểu dần dần nâng lên, cho thấy phần mềm đang bị thoái hoá do những thay đổi này.
Một điểm khác biệt giữa phần cứng và phần mềm là khi phần cứng bị mòn, nó sẽ được thay thế ngay lập tức Trong khi đó, phần mềm không có phần thay thế nào Mọi sự cố phần mềm thường phản ánh lỗi thiết kế hoặc quá trình chuyển đổi thiết kế thành mã thực thi Vì vậy, việc bảo trì phần mềm phức tạp hơn nhiều so với bảo trì phần cứng.
Phần lớn phần mềm đều được xây dựng theo các đơn đặt hàng, ít khi được lắp ráp từ các thành phần có sẵn.
Hiện tại, không có danh mục rõ ràng cho các thành phần phần mềm, mà chỉ có thể đặt hàng phần mềm dưới dạng một đơn vị hoàn chỉnh Mặc dù có nhiều tài liệu bàn về việc tái sử dụng phần mềm, nhưng hiệu quả từ việc này vẫn còn rất hạn chế.
1.3 Thế nào là một phần mềm tốt ?
■ Các chỉ tiêu cơ bản bao gồm:
- Phản ánh đúng yêu cầu người dùng.
- Chứa ít lỗi tiềm tàng.
- Giá thành không vượt quá ước lượng ban đầu.
- Dễ vận hành sử dụng.
- Tính an toàn, độ tin cậy cao.
■ Hiệu suất xử lý cao:
- Hiệu suất thời gian tốt: Độ phức tạp tính toán thấp, thời gian quay vòng ngắn, thời gian hồi đáp nhanh.
- Sử dụng các tài nguyên như CPU, RAM, HDD, Internet một cách hữu hiệu.
- Kiến trúc và cấu trúc dễ hiểu.
- Dễ kiểm tra, kiểm chứng và bảo trì.
- Có tài liệu mô tả yêu cầu, điều kiện kiểm thử, vận hành, bảo trì với chất lượng cao.
Tính dễ hiểu ngày càng trở thành chỉ tiêu quan trọng với phần mềm.
Tuy nhiên để xây dựng phầm mềm tốt ta phải chú ý các điểm sau:
■ 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, khi bàn giao sản phẩm dễ phát sinh những trục trặc.
Với các phần mềm quy mô lớn và tài liệu đặc tả cố định trong thời gian dài, việc đáp ứng nhanh chóng nhu cầu thay đổi của người dùng sẽ gặp nhiều khó khăn.
■ Nếu không có phương pháp luận thì chất lượng phần mềm sẽ suy giảm.
■ Nếu không có chuẩn về 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.
Việc không kiểm thử tính đúng đắn của phần mềm ở từng giai đoạn mà chỉ tập trung vào giai đoạn cuối có thể dẫn đến việc phát hiện lỗi muộn, gây ảnh hưởng đến thời gian bàn giao sản phẩm.
■ Coi trọng lập trình hơn thiết kế làm cho chất lượng phần mềm giảm.
■ Coi thường tái sử dụng phần mềm làm cho năng suất lao động giảm.
■ Phần lớn trong quy trình phát triền phần mềm do con người thực hiện cũng làm năng suất lao động giảm.
■ Không chứng minh tính đúng đắn của phần mềm làm giảm độ tin cậy của phần mềm.
■ Chuẩn 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.
■ 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.
■ 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 các công việc khác.
Quản lý dự án lỏng lẻo dẫn đến việc quản lý lịch trình không rõ ràng Thiếu tiêu chuẩn trong việc ước lượng nhân lực và dự toán chi phí sẽ kéo dài thời gian thực hiện và vượt quá ngân sách của dự án.
Công nghệ phần mềm
Mụ c tiêu: Nắm được các định nghĩa công nghệ phần mềm. Định nghĩa công nghệ phân mềm
Có nhiều định nghĩa công nghệ phần mềm được đưa ra:
Theo Bauer (1969), công nghệ phần mềm được định nghĩa là việc áp dụng các nguyên lý công nghệ chính xác nhằm phát triển phần mềm có tính kinh tế, độ tin cậy cao và hoạt động hiệu quả trên các hệ thống máy tính thực tế.
Pamas (1987): Công nghệ phần mềm là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người.
Công nghệ phần mềm, theo Ghezzi (1991), là một lĩnh vực trong khoa học máy tính, chuyên về việc phát triển các hệ thống phần mềm lớn và phức tạp, được thực hiện bởi một hoặc nhiều nhóm kỹ sư.
IEEE (1993) : Công nghệ phần mềm là:
1 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 hoá trong phát triển vận hành và bào trì phần mềm.
2 Nghiên cứu các phương pháp tiếp cận nói trên.
Công nghệ phần mềm, theo Pressman (1995), là sự tiến bộ của công nghệ phần cứng và hệ thống, bao gồm ba yếu tố chính: phương pháp, công cụ và thủ tục Những yếu tố này giúp quản lý kiểm soát quá trình phát triển phần mềm, đồng thời cung cấp nền tảng cho các chuyên gia nhằm tạo ra phần mềm chất lượng cao một cách hiệu quả.
Các phương pháp công nghệ phần mềm cung cấp các kỹ thuật để xây dựng phần mềm hiệu quả Chúng bao gồm nhiều nhiệm vụ như lập kế hoạch và ước lượng dự án, phân tích yêu cầu hệ thống và phần mềm, thiết kế cấu trúc dữ liệu, kiến trúc chương trình và thủ tục thuật toán Ngoài ra, các phương pháp này cũng bao gồm mã hoá, kiểm thử và bảo trì phần mềm Thường thì, chúng sử dụng ký pháp đồ hoạ hoặc ngôn ngữ đặc biệt và thiết lập tiêu chuẩn chất lượng phần mềm.
Các công cụ công nghệ phần mềm hiện nay cung cấp hỗ trợ tự động hoặc bán tự động cho các phương pháp phát triển phần mềm Những công cụ này được thiết kế riêng cho từng phương pháp và khi chúng được tích hợp, thông tin do chúng tạo ra có thể được sử dụng bởi các công cụ khác Hệ thống hỗ trợ phát triển phần mềm được hình thành từ đây, được gọi là công nghệ phần mềm hỗ trợ bởi máy tính (CASE) CASE bao gồm tổ hợp phần mềm, phần cứng và cơ sở dữ liệu, chứa thông tin quan trọng về phân tích, thiết kế, mã hóa và kiểm thử, tạo ra một môi trường kỹ nghệ phần mềm tương tự như thiết kế và kỹ nghệ có máy tính hỗ trợ (CAD/CASE) cho phần cứng.
Các thủ tục công nghệ phần mềm kết hợp các phương pháp và công cụ, giúp tối ưu hóa việc phát triển phần mềm máy tính Thủ tục này xác định trình tự áp dụng các phương pháp, sản phẩm bàn giao cần thiết như tài liệu, báo cáo, mẫu nhằm kiểm soát chất lượng và điều chỉnh thay đổi Ngoài ra, nó cũng xác định các cột mốc quan trọng để người quản lý phần mềm theo dõi tiến độ dự án.
CÂU HỎI VÀ BÀI TẬP
2 Các đặc tính của phần mềm.?
3 Thế nào là một phần mềm tốt.?
4 Ứng dụng của phần mềm?
5 Công nghệ phần mềm là gì?.
MỘT SỐ MÔ HÌNH VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM
Các khái niệm cơ bản
Mục tiêu: - Nắm được cách giai đoạn của vòng đời phần mềm, quy trình phát triển phần mềm
Vòng đời phần mềm bao gồm toàn bộ quá trình từ khi phần mềm được phát triển cho đến khi ngừng sử dụng, bao gồm các giai đoạn xác định, phát triển và bảo trì Ba giai đoạn này là yếu tố cốt lõi trong mọi dự án phát triển phần mềm, bất kể lĩnh vực ứng dụng, quy mô dự án hay mức độ phức tạp.
Trong giai đoạn xác định, người phát triển phần mềm tập trung vào việc xác định thông tin cần xử lý, chức năng và hiệu năng cần thiết, giao diện cần thiết, cũng như các ràng buộc thiết kế và tiêu chuẩn hợp lệ để xây dựng một hệ thống thành công Các yêu cầu chủ chốt của hệ thống và phần mềm được làm rõ Mặc dù các phương pháp trong giai đoạn này có thể thay đổi tùy theo bối cảnh công nghệ phần mềm, nhưng ba bước chính luôn xuất hiện.
Phân tích hệ thống- Xác định ra vai trò của từng phần từ trong hệ thống dựa trên máy tính, chỉ ra vai trò của phần mềm.
Lập kế hoạch dự án phần mềm là bước quan trọng khi đã xác định phạm vi, phân tích rủi ro, phân bổ tài nguyên và ước lượng chi phí Giai đoạn này cần xác định rõ nhiệm vụ công việc và lập lịch trình thực hiện để đảm bảo dự án diễn ra suôn sẻ.
Phân tích yêu cầu là bước quan trọng để xác định phạm vi phần mềm, giúp định hướng cho dự án Tuy nhiên, cần phải làm rõ các lĩnh vực thông tin và chức năng cụ thể trước khi bắt đầu triển khai công việc.
Trong giai đoạn phát triển, người phát triển tập trung vào việc xác định cấu trúc dữ liệu và kiến trúc phần mềm, cài đặt các chi tiết thủ tục, dịch thiết kế sang ngôn ngữ lập trình hoặc ngôn ngữ phi thủ tục, và thực hiện kiểm thử Mặc dù phương pháp áp dụng có thể thay đổi, nhưng thường có ba bước đặc thù xuất hiện trong quá trình này.
Thiết kế phần mềm là quá trình chuyển đổi các yêu cầu phần mềm thành các biểu diễn cụ thể, bao gồm đồ họa, bảng hoặc ngôn ngữ lập trình Quá trình này mô tả cấu trúc dữ liệu, kiến trúc hệ thống, các thủ tục thuật toán và đặc điểm giao diện người dùng, nhằm đảm bảo phần mềm hoạt động hiệu quả và đáp ứng nhu cầu của người sử dụng.
Mã hóa là quá trình chuyển đổi các biểu diễn thiết kế thành ngôn ngữ nhân tạo, bao gồm ngôn ngữ lập trình quy ước hoặc ngôn ngữ phi thủ tục trong ngôn ngữ thế hệ 4 (4GT) Kết quả của bước mã hóa là tạo ra các lệnh có thể thực thi trên máy tính.
Kiểm thử phần mềm là quá trình cần thiết sau khi phần mềm được cài đặt dưới dạng mã máy thực thi Mục đích của kiểm thử là phát hiện các khiếm khuyết trong quá trình vận hành, logic và cài đặt của phần mềm.
Giai đoạn bảo trì tập trung vào việc sửa lỗi, thích ứng với sự tiến hóa của môi trường phần mềm và nâng cao dựa trên yêu cầu của người dùng Trong giai đoạn này, các bước của giai đoạn xác định và phát triển được áp dụng lại, nhưng trong bối cảnh phần mềm hiện có Có ba kiểu thay đổi chính thường gặp trong giai đoạn bảo trì.
Phần mềm luôn có khả năng tồn tại lỗi, và mặc dù các quy trình đảm bảo chất lượng được thực hiện tốt, khách hàng vẫn có thể phát hiện ra các khiếm khuyết trong quá trình sử dụng Bảo trì sửa đổi là quá trình điều chỉnh phần mềm nhằm khắc phục những lỗi này.
Thích nghi là quá trình điều chỉnh phần mềm để phù hợp với những thay đổi trong môi trường phát triển ban đầu Việc bảo trì nhằm thích nghi thực hiện các sửa đổi cần thiết, giúp phần mềm vẫn hoạt động hiệu quả trước những biến động từ môi trường bên ngoài.
Nâng cao hiệu suất phần mềm giúp khách hàng và người dùng khám phá những tính năng bổ sung có lợi Việc bảo trì và hoàn thiện phần mềm không chỉ đáp ứng các yêu cầu chức năng ban đầu mà còn mở rộng khả năng sử dụng của nó.
Ngoài các hoạt động cơ bản, nhiều công ty đang áp dụng kỹ nghệ ngược để cải tiến phần mềm Họ sử dụng bộ công cụ CASE đặc biệt nhằm tái cấu trúc phần mềm cũ, giúp người dùng hiểu rõ hơn và nâng cao hiệu suất làm việc của ứng dụng.
1.2 Quy trình phát triển phần mềm
Một quy trình phát triển phần mềm có thể được mô tá như hình 2.1.
Hình 2.1.Quy trình phần mềm
Khung quy trình chung (Common Process Framework) được xây dựng bằng cách xác định các hoạt động khung (Frame Activities) áp dụng cho mọi dự án phần mềm, bất kể kích thước hay độ phức tạp Tập nhiệm vụ công việc (task sets) bao gồm các công việc công nghệ phần mềm, cột mốc dự án, sản phẩm và các điểm bảo đảm chất lượng, giúp các hoạt động khung thích ứng với đặc tính và yêu cầu của dự án Ngoài ra, các hoạt động bao trùm (umbrella activities) đóng vai trò bảo đảm cho chất lượng phần mềm, quản lý cấu hình và bảo trì, diễn ra độc lập và xuyên suốt trong quy trình.
Một số mô hình vòng đời phát triển phần mềm
Mục tiêu: Hiểu được một số mô hình vòng đời phát triển phần mềm.
2.1 Mô hình tuyến tính Điển hình là mô hình vòng đời cổ điển bao gồm các hoạt động sau:
Hình 2.2 Mô hình tuyến tính
Công nghệ học và mô hình hóa hệ thống thông tin đóng vai trò quan trọng trong phát triển phần mềm Quá trình này bắt đầu bằng việc xác định các yêu cầu cho các thành phần của hệ thống, sau đó ánh xạ một số yêu cầu đó sang phần mềm Điều này diễn ra trong bối cảnh tương tác giữa phần cứng, con người và cơ sở dữ liệu, đảm bảo sự hoạt động hiệu quả của toàn bộ hệ thống.
Phân tích yêu cầu phần mềm là quá trình quan trọng giúp hiểu rõ lĩnh vực thông tin, chức năng và hành vi của phần mềm Việc tài liệu hóa yêu cầu cho cả hệ thống và phần mềm là cần thiết, đồng thời cần có sự trao đổi chặt chẽ với khách hàng để đảm bảo các yêu cầu được đáp ứng đầy đủ.
Thiết kế là một quá trình đa bước, tập trung vào bốn thuộc tính chính 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ác yêu cầu thiết kế cần được tài liệu hóa và đóng vai trò quan trọng trong cấu trúc phần mềm.
Lập trình là quá trình chuyển đổi thiết kế thành mã nguồn bằng một ngôn ngữ lập trình cụ thể Khi thiết kế được thực hiện một cách chi tiết, lập trình trở nên đơn giản và mang tính cơ học.
Hỗ trợ và bảo trì phần mềm là quá trình đáp ứng các thay đổi và nâng cấp cần thiết theo yêu cầu và môi trường sử dụng Mặc dù đây là một trong những mô hình lâu đời và phổ biến nhất trong lĩnh vực công nghệ phần mềm, nhưng nó cũng tồn tại một số nhược điểm cần được xem xét.
Các dự án thường không tuân theo quy trình tuần tự như mô hình đề xuất, mà thường xuất hiện sự lặp lại và phát sinh các vấn đề khi áp dụng mô hình này.
Khách hàng thường gặp khó khăn trong việc diễn đạt rõ ràng các yêu cầu của mình, trong khi mô hình dự án lại yêu cầu sự rõ ràng này Điều này dẫn đến việc không thể đáp ứng hiệu quả với những bất trắc tự nhiên có thể xảy ra ngay từ đầu dự án.
■ Khách hàng phải kiên nhẫn chờ đợi trong một thời gian nhất định mới có sản phẩm Nếu phát hiện lỗi là một thảm họa.
2.2 Mô hình thuần thục khả năng
Mô hình này do Software Engineering Institute (SE1) phát triển bao gồm 5 mức sau:
Mức 1 Khởi đầu:Một số quy trình được xác định, sự thành công phụ thuộc vào các nỗ lực cá nhân.
Mức 2 Lặp lại:Quy trình quản lý dự án cơ bản được thiết lập để theo vết của chi phí, lịch trình, chức năng Công việc không phụ thuộc vào cá nhân, làm việc theo quy trình Thành công dự án đáp ứng các ứng dụng cỡ nhỏ.
Mức 3 Xác định:Toàn bộ quy trình phần mềm cho cả các hoạt động quản lý và công nghệ được tư liệu hoá, chuẩn hoá.
Mức 4 Quản trị: Các độ đo chi tiết của quá trình phần mềm và chất lượng sản phẩm được thu thập Toàn bộ quy trình và sản phẩm được điều khiển sử dụng các độ đo chi tiết này Mức này bao gồm các đặc tính xác định ở mức 3.
Mức 5 Tối ưu: Tiếp tục cải tiến quy trình sản xuất bằng cách lấy thông tin phản hồi và đưa ra công nghệ mới.
SEI đã xác định các lĩnh vực quy trình chủ yếu (KPAs) cho từng mức độ, mô tả các chức năng quan trọng trong công nghệ phần mềm như lập kế hoạch dự án và quản lý yêu cầu Mỗi KPA được xây dựng dựa trên các đặc tính chủ yếu nhằm đáp ứng hiệu quả cho từng mức cụ thể.
■Mục đích: Mục tiêu tổng thể mà mỗi KPA đạt được.
■ Cam kết: Yêu cầu cần có để đạt được mục đích, cung cấp các bằng chứng về ý muốn đạt được mục đích.
■Khả năng: Những điều cho phép tổ chức đạt được cam kết.
■Hoạt động: Các nhiệm vụ cụ thể cần thực hiện để đạt được chức năng của KPA.
■Phương thức điều khiển thực hiện:Cách thức các hoạt động được điều khiển.
■Phương thức kiểm tra thực hiện:Cách thức kiểm tra các hoạt động cho K.PA.
18 KPA được xác định trong các mô hình thuần thục được ánh xạ vào trong các mức độ thuần thục, bao gồm:
+ Quản lý cấu hình phần mềm;
+ Bảo đảm chất lượng phần mềm;
+ Quản lý các nhà thầu phụ;
+ Theo vết dự án phần mềm;
+ Lập kế hoạch quản lý dự án phần mềm;
+ Rà soát lại nút mạng;
+ Kỹ nghệ sản phẩm phần mềm;
+ Quản lý phần mềm tích hợp;
+ Xác định quy trình tổ chức;
+ Tập trung quy trình tổ chức
+ Quản lý chất lượng phần mềm;
+ Quản lý quy trình số lượng;
+ Quản lý thay đổi quy trình;
+ Quản lý thay đổi công nghệ;
Trong nhiều trường hợp, khách hàng đã xác định các mục tiêu tổng quát cho phần mềm nhưng chưa rõ ràng về đầu vào, quy trình xử lý hoặc yêu cầu đầu ra Đồng thời, các nhà phát triển cũng có thể không chắc chắn về hiệu quả của thuật toán hoặc sự cần thiết phải điều chỉnh hệ điều hành và giao diện người - máy Do đó, việc tạo ra bản mẫu cho công nghệ phần mềm là một phương pháp hiệu quả để giải quyết những vấn đề này.
Mô hình chế thử là quá trình hỗ trợ các nhà phát triển phần mềm trong việc xây dựng một mô hình cho phần mềm cần thiết Mô hình này có thể được thể hiện dưới ba dạng khác nhau.
■ Bản mẫu trên giấy hay mô hình dựa trên PC mô tả giao diện người máy giúp cho người dùng hiểu cách các tương tác xuất hiện.
■ Bản mẫu làm việc cài đặt một tập con các chức năng của phần mềm mong muốn.
Một chương trình hiện có thể thực hiện một phần hoặc toàn bộ các chức năng mong muốn, nhưng cần được cải tiến để bổ sung thêm các tính năng mới theo nỗ lực phát triển.
Các sự kiện của việc làm bản mẫu được minh họa trong hình 2.3
Nghe khách Tạo sửa trình bày
Việc làm bản mẫu bắt đầu bằng việc thu thập yêu cầu phần mềm thông qua các cuộc gặp gỡ giữa nhà phát triển và khách hàng để xác định mục tiêu tổng thể và các yêu cầu cần thiết Tiếp theo là quá trình "thiết kế nhanh", tập trung vào việc thể hiện các khía cạnh của phần mềm mà người dùng có thể thấy, như cách nhập liệu và định dạng đầu ra Sau đó, bản mẫu được xây dựng và đánh giá bởi khách hàng, từ đó giúp làm rõ các yêu cầu phát triển phần mềm Quy trình này được lặp lại cho đến khi bản mẫu được điều chỉnh để đáp ứng nhu cầu của khách hàng, đồng thời giúp nhà phát triển hiểu rõ hơn về cách thực hiện các yêu cầu đó.
Bản mẫu lý tưởng đóng vai trò là công cụ xác định yêu cầu phần mềm Khi có một bản mẫu hoạt động hiệu quả, các nhà phát triển có thể tận dụng các đoạn mã đã có sẵn hoặc sử dụng các công cụ hỗ trợ như bộ sinh báo cáo và bộ quản lý cửa sổ để nhanh chóng tạo ra chương trình cần thiết.
2.4 Mô hình phát triển ứng dụng nhanh (RAD)
XÁC ĐỊNH VÀ ĐẶC TẢ YÊU CẦU
Tổng quan về yêu cầu phần mềm
Mục tiêu : Nắm được khái niệm yêu cầu phần mềm và phân loại được các yêu cầu phần mềm.
1.1 Khái niệm yêu cầu phần mềm
Yêu cầu phần mềm là tất cả các yêu cầu về phần mềm do khách hàng - người sử dụng đưa ra gồm:
Các chức năng của phần mềm
Hiệu năng của phần mềm.
Các yêu cầu về thiết kế và giao diện.
Các yêu cầu đặc biệt khác.
1.2 Phân loại các yêu cầu phần mềm
Thông thường các yêu cầu phần mềm được phân thành 4 loại sau:
■ Yêu cầu về phần mềm.
■ Yêu cẩu về phần cứng.
■ Yêu cầu về dữ liệu.
■ Yêu cầu về con người.
Mục đích của yêu cầu phần mềm là xác định được phần mềm đáp ứng các yêu cầu và mong muốn của khách hàng, người sử dụng.
Để phát triển phần mềm hiệu quả, việc xác định yêu cầu là rất quan trọng, vì khách hàng thường chỉ có ý tưởng mơ hồ về sản phẩm Chúng ta cần kiên trì thu thập và làm rõ các ý tưởng này để xây dựng phần mềm với đầy đủ tính năng cần thiết Trong quá trình thiết kế, khách hàng có thể thay đổi yêu cầu, vì vậy việc nắm bắt và điều chỉnh các mô hình cho phù hợp là cần thiết để đảm bảo sự thành công của dự án.
Xác định yêu cầu phần mềm
Mục tiêu: Trình bày được quy trình xác định yêu cầu phần mềm.
2.1 Nội dung xác định yêu cầu phần mềm
■ Phát hiện các yêu cầu phần mềm.
■ Phân tích các yêu cầu và thương lượng với khách hàng.
■ Đặc tả các yêu cầu phần mềm.
■ Mô hình hoá hệ thống.
■ Kiểm tra tính hợp lý các yêu cầu phần mềm.
■ Quản lý các yêu cầu phần mềm.
2.2 Phát hiện các yêu cầu phần mềm
Ta phải xác định các vấn đề sau:
Sau khi học xong bài học này, sinh viên có khả năng:
■ Phạm vi của phần mềm.
■ Các thay đổi của hệ thống.
Phương pháp xác định yêu cầu phần mềm:
■ Xác định các phương pháp sử dụng phát hiện các yêu cầu phần mềm như phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác.
Để xác định yêu cầu phần mềm một cách chính xác, việc tìm kiếm nhân sự có chuyên môn sâu và hiểu biết chi tiết về hệ thống là rất quan trọng.
■ Xác định môi trường kỹ thuật.
■ Xác định các ràng buộc lĩnh vực.
■ Thu hút sự tham gia của nhiều chuyên gia, khách hàng để có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàng
Sản phẩm của phát hiện yêu cầu phần mềm:
■ Bảng kê các đòi hỏi và chức năng khả thi của phần mềm.
■ Bảng kê phạm vi ứng dụng của phần mềm.
■ Mô tả môi trường kỹ thuật của phần mềm.
■ Bảng kê các tập hợp các kịch bản sử dụng phần mềm.
■ Các nguyên mẫu xây dựng, phân tích hay sử dụng trong phần mềm (nếu có).
■ Danh sách nhân sự tham gia vào quá trình phát triển các yêu cầu phần mềm kể cả các nhân sự từ phía công ty khách hàng.
2.3 Phân tích các yêu cầu phần mềm và thương lượng với khách hàng
Gồm các công việc sau:
• Phân loại các yêu cầu phần mềm và sắp xếp chúng theo các nhóm liên quan.
• Khảo sát tỷ mỷ từng yêu cầu phần mềm trong mối quan hệ của nó với các yêu cầu phần mềm khác.
■ Thẩm định từng yêu cầu phần mềm theo các tính chất: phù hợp đầy đủ rõ ràng, không trùng lặp.
■ Phân cấp các yêu cầu phần mềm dựa trên nhu cầu và đòi hỏi của khách hàng/người sử dụng.
Thẩm định các yêu cầu phần mềm là bước quan trọng để xác định tính khả thi của chúng trong môi trường kỹ thuật, đồng thời đánh giá khả năng kiểm định các yêu cầu này.
■ Thẩm định rủi ro có thể xảy ra với từng yêu cầu phần mềm.
Đánh giá sơ bộ về chi phí và thời gian thực hiện cho từng yêu cầu phần mềm là rất quan trọng trong việc xác định giá thành sản phẩm phần mềm Việc phân tích này giúp hiểu rõ hơn về các yếu tố ảnh hưởng đến giá và thời gian, từ đó tối ưu hóa quy trình phát triển phần mềm.
Giải quyết mọi bất đồng liên quan đến yêu cầu phần mềm với khách hàng và người sử dụng thông qua thảo luận và thương lượng các yêu cầu đã đặt ra.
Đặc tả yêu cầu
Mục tiêu của bài viết là hướng dẫn cách xây dựng hồ sơ đặc tả thông qua việc tạo ra các tài liệu cần thiết Quá trình này bao gồm việc sử dụng các công cụ như mô hình hóa, mô hình toán học hình thức, cùng với việc tập hợp các kịch bản sử dụng và nguyên mẫu.
Chất lượng của hồ sơ đặc tả được đánh giá qua các tiêu trí:
■ Tính rõ ràng, chính xác.
■ Tính đầy đủ, hoàn thiện.
Các thành phần của hồ sơ đặc tả:
■ Đặc tả phi hình thức (informal specifications) được viết bàng ngôn ngữ tự nhiên.
■ Đặc tả hình thức (formal specifications) được viết bằng tập các ký pháp có các quy định về cú pháp và ngữ nghĩa rất chặt chẽ.
• Đặc tả vận hành chức năng (operational specifications) mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng.
■ Đặc tả mô tả (descriptive specifications) đặc tả các đặc tính đặc trưng của phần mềm.
■ Đặc tả chức năng (functional specifications): thông thường khi đặc tả chức năng của phần mềm người ta sử dụng các công cụ sau:
- Biểu đồ luồng dữ liệu.
- Máy trạng thái hữu hạn.
Ta hãy xét lần lượt từng loại công cụ:
Biểu đồ luồng dữ liệu (DFD)
Biểu đồ luồng dữ liệu (DFD) mô tả các chức năng xử lý của hệ thống và mối liên hệ giữa chúng trong quá trình xử lý và chuyển giao dữ liệu Nó cung cấp cái nhìn tổng quát về hoạt động của hệ thống Tuy nhiên, DFD cũng có những hạn chế cần lưu ý.
■ Ý nghĩa các ký pháp sử dụng được xác định bởi các định danh lựa chọn của khách hàng.
■ Trong DFD không xác định rõ các hướng thực hiện.
■ DFD không xác định rõ sự đồng bộ giữa các chức năng/module.
Máy trạng thái hữu hạn
Máy trạng thái hữu hạn chứa:
■ Các chức năng chuyển tiếp.
Các yêu cầu của đặc tả tốt:
■ Dễ hiểu với người dùng, ít rắc rối.
■ Có ít quy ước khi mô tả.
■ Theo phong cách từ trên xuống (top - down).
Dễ triển khai cho các pha sau của vòng đời: thiết kế hệ thống và thiêt kế chương trình, giao diện dễ làm, đảm bảo tính nhất quán.
Thẩm định yêu cầu
Mục tiêu: Nắm được các nhiệm vụ của phân tích yêu cầu và các loại phân tích yêu cầu.
4.1 Nhiệm vụ của phân tích yêu cầu
Phân tích yêu cầu là một nhiệm vụ quan trọng trong công nghệ phần mềm, giúp kết nối giữa việc cấp phát phần mềm và thiết kế phần mềm Quá trình này cho phép người phân tích hệ thống xác định chức năng, hiệu suất, và giao diện của phần mềm với các phần tử khác trong hệ thống, đồng thời thiết lập các ràng buộc thiết kế cần thiết Qua đó, kỹ sư thiết kế có thể tinh chỉnh việc cấp phát phần mềm và xây dựng các mô hình tiến trình, dữ liệu, và hành vi mà phần mềm sẽ xử lý Phân tích cung cấp cho người thiết kế một cách biểu diễn thông tin và chức năng, từ đó chuyển đổi thành thiết kế dữ liệu, kiến trúc và quy trình Cuối cùng, đặc tả yêu cầu giúp người phân tích và khách hàng đánh giá chất lượng của phần mềm sau khi hoàn thành.
Việc phân tích các yêu cầu phần mềm có thể chia thành 5 lĩnh vực:
2 Đánh giá và tồng hợp.
Người phân tích cần nghiên cứu bản Đặc tả hệ thống và Kế hoạch dự kiến phần mềm để hiểu rõ về phần mềm trong bối cảnh hệ thống và phạm vi ứng dụng Việc thiết lập trao đổi là cần thiết để người phân tích nhận thức đúng vấn đề Họ cũng phải xây dựng mối quan hệ với quản lý và nhân viên kỹ thuật của tổ chức người dùng/khách hàng cũng như tổ chức phát triển phần mềm Người quản lý dự án đóng vai trò điều phối, tạo điều kiện cho việc thiết lập giao tiếp hiệu quả Mục tiêu của người phân tích là nhận diện các vấn đề cơ bản mà người dùng/khách hàng đã cảm nhận.
Đánh giá vấn đề và tổng hợp giải pháp là nhiệm vụ quan trọng của người phân tích Họ cần phân tích luồng và nội dung thông tin, xác định và soạn thảo các chức năng phần mềm, cũng như hiểu hành vi phần mềm trong bối cảnh các sự kiện ảnh hưởng đến hệ thống Ngoài ra, việc thiết lập các đặc trưng giao diện và xác định các ràng buộc thiết kế cũng rất cần thiết Tất cả những nhiệm vụ này nhằm mục đích mô tả vấn đề một cách tổng thể và hiệu quả.
Sau khi đánh giá vấn đề hiện tại và xác định thông tin cần thiết, người phân tích bắt đầu tổng hợp các giải pháp Hệ thống dựa trên thiết bị cuối trực tuyến có thể giải quyết một số vấn đề, nhưng cần xem xét tính phù hợp với phạm vi đã định trong kế hoạch phần mềm và yêu cầu có một hệ cơ sở dữ liệu để mô phỏng cho khách hàng Quá trình ước lượng và tổng hợp tiếp tục cho đến khi cả người phân tích và khách hàng đều đồng ý rằng phần mềm đã sẵn sàng cho các bước phát triển tiếp theo.
Người phân tích chú trọng vào việc xác định "cái gì" trong quá trình ước lượng và tổng hợp giải pháp, thay vì tập trung vào "thế nào" Điều này bao gồm việc xác định loại dữ liệu mà hệ thống sẽ tạo ra và sử dụng, các chức năng mà hệ thống cần thực hiện, giao diện cần thiết và các ràng buộc mà hệ thống phải tuân thủ.
Trong quá trình đánh giá và tổng hợp giải pháp, người phân tích xây dựng một mô hình hệ thống nhằm hiểu rõ hơn về luồng dữ liệu, điều khiển và xử lý chức năng, cũng như thao tác hành vi và nội dung thông tin Mô hình này không chỉ là nền tảng cho thiết kế phần mềm mà còn là cơ sở để phát triển các đặc tả phần mềm.
Trong giai đoạn này, không nên có đặc tả chi tiết vì khách hàng vẫn chưa xác định rõ nhu cầu của mình, và người phân tích cũng chưa chắc chắn về cách tiếp cận sẽ đáp ứng đúng chức năng và hiệu suất mong muốn Do đó, việc áp dụng phương pháp phân tích yêu cầu thông qua việc làm bán mẫu là cần thiết để giải quyết những bất định này.
Khi mô tả thông tin, chức năng và giao diện của phần mềm, việc xác định các tiêu chuẩn hợp lệ là rất quan trọng để thể hiện cách hiểu về việc cài đặt thành công Những tiêu chuẩn này đóng vai trò nền tảng cho các hoạt động kiểm thử trong quy trình phát triển phần mềm Để làm rõ các đặc trưng và thuộc tính của phần mềm, cần viết một đặc tả yêu cầu hình thức, đồng thời có thể soạn thảo các tài liệu liên quan khác.
"Tài liệu người dùng xơ lược" cho trường hợp bản mẫu còn chưa được xây dựng xong.
Tài liệu phân tích yêu cầu, bao gồm bản đặc tả và tài liệu người dùng, là nền tảng quan trọng cho quá trình xét duyệt của khách hàng và các nhà phát triển Trong cuộc họp xét duyệt yêu cầu, thường sẽ phát sinh các thay đổi liên quan đến chức năng, hiệu suất, cách trình bày thông tin, cũng như các ràng buộc và tiêu chuẩn hợp lệ.
4.2 Phân tích có cấu trúc
Phân tích có cấu trúc, tương tự như các phương pháp yêu cầu phần mềm, là một hoạt động xây dựng mô hình quan trọng Việc sử dụng một ký pháp duy nhất trong phân tích giúp tạo ra các mô hình mô tả luồng và nội dung thông tin, bao gồm dữ liệu và điều kiện Đồng thời, phương pháp này cũng phân hoạch hệ thống theo chức năng và hành vi, từ đó mô tả bản chất của nội dung cần được phát triển.
Cơ chế của phân tích có cấu trúc
Tạo biểu đồ luồng dữ liệu
Biểu đồ luồng dữ liệu (DFD) là công cụ quan trọng giúp kỹ sư phần mềm xây dựng các mô hình thông tin và chức năng một cách đồng thời Khi DFD được làm mịn đến mức chi tiết hơn, người phân tích tiến hành phân rã chức năng không tường minh của hệ thống Quá trình làm mịn DFD cũng dẫn đến việc làm mịn dữ liệu tương ứng khi nó di chuyển qua các tiến trình trong ứng dụng.
Một vài hướng dẫn đơn giản sau có thể trợ giúp cho việc suy ra biểu đồ luồng dữ liệu:
1 Biểu đồ luồng dữ liệu mức 0 nên mô tả chỉ là một vòng tròn phần mềm /hệ thống.
2 Đầu vào và đầu ra chính cần được chú thích cẩn thận.
3 Việc làm mịn dần nên bắt đầu từ việc cô lập các tiến trình, khoản mục dữ liệu và kho ứng cử viên được biểu diễn ở mức tiếp.
4 Tất cả các mũi tên và hình tròn nên được gắn nhãn bằng những tên có ý nghĩa.
5 Phải duy trì được tính liên tục luồng thông tin từ mức này sang mức kia.
6 Mỗi lúc chỉ làm mịn một hình tròn.
Có xu hướng tự nhiên làm phức tạp biểu đồ luồng dữ liệu, thường xảy ra khi người phân tích cung cấp quá nhiều chi tiết sớm hoặc tập trung vào các khía cạnh thủ tục của phần mềm thay vì luồng thông tin chính.
Trong DFD mức 0, các tác nhân bên ngoài chủ yếu cung cấp thông tin cho hệ thống và sử dụng thông tin do hệ thống tạo ra Các mũi tên được ghi nhãn biểu thị các khoản mục dữ liệu hợp thành, cho thấy rằng dữ liệu thực sự là tập hợp của nhiều khoản mục dữ liệu phụ.
DFD mức 0 được mở rộng thành DFD mức 1 thông qua phương pháp "phân tích văn phạm", trong đó cô lập các danh từ, cụm danh từ, động từ và cụm động từ trong lời thoại Các danh từ này thường đại diện cho các tác nhân ngoài, khoản mục dữ liệu, điều khiển hoặc kho dữ liệu Bằng cách thực hiện phân tích văn phạm cho một hình tròn ở bất kỳ mức DFD nào, chúng ta có thể thu thập nhiều thông tin hữu ích để cải thiện quá trình làm mịn cho mức tiếp theo.
Các tiến trình trong DFD mức 1 có thể được chi tiết hóa ở các mức thấp hơn Quá trình này sẽ tiếp tục cho đến khi mỗi hình tròn biểu thị một chức năng đơn giản, tức là khi tiến trình được thể hiện bởi một vòng tròn thực hiện một chức năng dễ dàng và được tích hợp như một thành phần trong chương trình.
