Bài giảng môn Công nghệ Phần mềm (Bản đẹp)

giai đoạn của dự án, nhu cầu về con người là khác nhau. Phần mềm dùng lại được - Thành phần đóng gói (dùng ngay) - Thành phần đã kiểm nghiệm tốt (sửa dùng được) - Thành phần có thể dùng (chi phí sửa lớn) Phần cứng/công cụ phần mềm chia sẻ 2.4.2 Cấu trúc kế hoạch thực hiện dự án: - Mở đầu - Tổ chức thực hiện dự án - Phân tích các rủi ro - Yêu cầu về nguồn lực(tài nguyên): Nhân lực, phần cứng, phần mềm - Bảng phân rã công việc - Lập lịch dự án - Cơ chế kiểm soát và báo cáo - Các kế hoạch phụ trợ Tổ chức hoạt động dự án: - Tổ chức bộ máy và cơ chế hoạt động: ban quản lý, các nhóm làm việc (team, sub-Team), chơ chế điều hành giám sát, báo cáo. - Hoạt động dự án cần tổ chức tạo ra các đầu ra thấy được của mỗi tiến trình quản lý. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Cột mốc (Milestone) là điểm cuối của một tiến trình hoạt động có xuất phẩm và các báo cáo yêu cầu. - Xuất phẩm (Diliverables) là kế quả dự án gửi đến khách hàng/quản lý dự án giám sát tại mỗi thời điểm. 2.4.3 Quy trình lập kế hoạch thực hiện dự án Nội dung hoạt động kế hoạch 1. Xây dựng bảng phân rã công việc: Đội dự án và người quản lý dự án xác định các nhiệm vụ (gói công việc) cần thực hiện để tạo ra các sản phẩm. 2. Xác định các mối quan hệ giữa các công việc được phân rã: đặt các gói công việc theo một tiến trình có trình tự trước-sau. 3. Ước lượng các gói công việc: mỗi gói công việc có ước lượng công lao động, số trang thiết bị và thời gian cần thiết để thực hiên. 4. Xây dựng lịch biểu ban đầu: tính toán thời gian thực hiện dự án, thời gian bắt đầu sớm nhất & kết thúc muộn nhất của từng công việc. 5. Gán nguồn lực thực hiện, điều chỉnh lịch: sau khi gán nguồn lực, cần chính xác hoá lịch biểu khi tính đến các ràng buộc về nguồn lực. Các nhiệm vụ được lập lịch sao cho tối ưu hoá việc sử dụng lao động và các nguồn lực khác. Hình 2.3: Qui trình lập kế hoạch dự án 2.4.4 Lập lịch dự án 2.4.4.1 Bảng phân rã công việc Cấu trúc bảng phân rã công việc bao gồm: - Các công việc - Mối liên hệ (trước-sau) giữa các công việc Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Thời gian thực hiện - Nguồn lực cần thực hiện công việc Ý nghĩa của bảng phân rã công việc: - Hình dung đầy đủ công việc dự án cần làm - Cơ sở để ước lượng chi phí và thời gian - Cơ sở cho lập lịch - Cơ sở để bố trí nguồn lực và phân bổ tài nguyên Các bước xây dựng bảng phân rã công việc Bước 1: Viết ra sản phẩm chung nhất (lấy ra từ bản dự án cơ sở) Bước 2: Tạo danh sách các sản phẩm chi tiết ở các mức thấp hơn (khoảng 2,3 mức) Bước 3: Tạo danh sách các công việc thực hiên sản phẩm ở mức thấp nhất, phân rã các công việc để được các công việc ở mức thấp hơn đến mức đạt yêu cầu. Bước 4: Đánh mã số cho mỗi công việc, nhóm lại. Bước 5: Xét duyệt lại bảng công việc. Hình 2.4: Quy trình xây dựng bảng phân rã công việc 2.4.4.2 Lập lịch dự án Nội dung hoạt động lập lịch dự án Đầu vào: Bảng phân rã công việc, các nguồn lực thực hiện và tổng số. Tiến hành lập lịch: - Lập mạng công việc - Tính thời gian bắt đầu sớm nhất - Tính thời gian kết thúc muộn nhất Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Tính thời gian dự phòng - Tính công việc găng, đường găng (Critical path) - Tối ưu hoá thực hiện công việc khi tính đến các ràng buộc về nguồn lực Tính thời gian thực hiện các công việc: Ước lượng PERT (Program Evaluation and Review Technique) Thích hợp với các dự án đòi hỏi tính sáng tạo Quan trọng chất lượng kết quả công việc hơn thời gian hoàn thành dự án Công thức PERT Cần 3 ước lượng thời gian cho mỗi công việc Kết hợp để cho con số cuối cùng – Ước lượng khả dĩ (ML – Most Likely): Thời gian cần hoàn thành công việc trong điều kiện bình thường hay hợp lý. – Ước lượng lạc quan nhất (MO – Most Optimistic): Thời gian cần hoàn thành công việc trong điều kiện tốt nhất hay lý tưởng. – Ước lượng bi quan nhất (MP – Most Pessimistic): Thời gian cần hoàn thành công việc trong điều kiện xấu nhất. – Ước lượng thời gian theo công thức: EST = (MO + 4ML + MP)/6 Sau đó tăng một ít thời gian cho các công việc (thời gian lãng phí giữa chừng) thông thường tăng thêm từ 7-10%. Xây dựng biểu đồ PERT Hình 2.5: Biểu đồ PERT Ưu điểm của PERT: – Buộc tính đến nhiều yếu tố khi xác định các giá trị MO, MP, ML – Người quản lý phải trao đổi với nhiều người để đạt được sự đồng thuận Đại học Đông Á Bài giảng môn Công nghệ Phần mềm – Giá trị nhận được là cân bằng giữa hai thái cực, có ý nghĩa đáng tin cậy để lập kế hoạch chi tiết hơn. Nếu ước lượng > 2 tuần hoặc 80 giờ thì thực hiện phân rã công việc tiếp. Nhược điểm: – Tốn thời gian khi có nhiều công việc – Có thể xảy ra tranh luận nhiều dẫn tới sự chán nản của các thành viên dự án. – Có thể dẫn đến tính vụn vặt. Lập lịch bằng công cụ Microsoft Project: Lập biểu đồ Gantt công việc: Hình 2.6: Lập biểu đồ Gantt bằng Microsoft Project Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Xác định đường găng trên biểu đồ Gantt: Đường găng là đường thực hiện công việc có thời gian dài nhất trên sơ đồ mạng công việc. Các công việc trên đường găng không được phép trễ hạn. Chỉ cần một công việc trên đường găng trễ hạn là cả dự án trễ theo. Do đó ưu tiên và quan tâm đến các công việc trên đường găng, phân công nhân sự giỏi, có kinh nghiệm, thiết bị tốt, thường xuyên cập nhật thay đổi trên đường găng. Hình 2.7: Xác định đường găng trên biểu đồ Gantt Sơ đồ mạng công việc: Hình 2.8: Sơ đồ mạng công việc Đại học Đông Á Bài giảng môn Công nghệ Phần mềm 2.5 Quản lý rủi ro 2.5.1 Định nghĩa rủi ro và quản lý rủi ro Định nghĩa rủi ro Những sự kiện có thể làm phá vỡ một dự án. Những điều không chắc chắn, những khoản nợ hay những điểm yếu có thể làm cho dự án không đi theo đúng kế hoạch đã định. Có thể quản lý được. Định nghĩa quản lý rủi ro Quy trình quản lý rủi ro nhằm giảm tối thiểu ảnh hưởng của những sự cố không biết trước cho dự án bằng cách xác định và đưa ra những giải pháp tình huống trước khi có những hậu quả xấu xảy ra Lý do cần quản lý rủi ro - Tất cả các dự án đều phụ thuộc vào rủi ro - Tiến trình sẽ không đúng theo kế hoạch trong một số giai đoạn của dự án - Rủi ro không thể được loại trừ triệt để Giá trị của quản lý rủi ro - Giảm thiểu ảnh hưởng của các sự cố không biết trước cho dự án - Nâng cao xác suất thực hiện thành công dự án - Tạo ra ý thức kiểm soát - Có được các giải pháp hiệu quả và kịp thời 2.5.2 Nhận diện rủi ro - Nhận diện các rủi ro tiềm tàng - Ai tham gia nhận diện và giải quyết - Tầm quan trọng: được chuẩn bị. Phần mềm là một lĩnh vực khó. Nhiều thứ có thể sai, đó là lý do mà phải chuẩn bị - việc hiểu rủi ro và làm những công việc ước lượng trước để tránh hay quản lý chúng – là một thành phần cơ bản của hoạt động quản lý dự án phần mềm - Những bước nào sẽ phải làm việc để quản lý rủi ro - Sản phẩm của người làm quản lý: RMMM (risk mitigation, monitoring & management)  Cần đưa ra một chiến lược phòng, chống rủi ro tổng quát trong CNPM Ba loại rủi ro - Rủi ro dự án là mối đe doạ cho kế hoạch dự án: Kế hoạch lịch trình sai sẽ làm tăng chi phí. Có thể sai trong dự tính ngân sách, kế hoạch, cá nhân(nhân viên, tổ chức), tài nguyên, khách hàng, và những yêu cầu và ảnh hưởng của chúng Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Rủi ro kĩ thuật là mối đe doạ chất lượng và tính đúng đắn của phần mềm được sản xuất. Nếu một lỗi kĩ thuật trở thành hiện thực, sự cài đặt có thể trở lên khó khăn hoặc không thể. Rủi ro kĩ thuật được tìm ra trong thiết kế, cài đặt, giao diện, sự kiểm tra, và vấn đề bảo trì. Thêm vào đó, sự tối nghĩa, kĩ thuật không vững chắc, kĩ thuật lỗi thời, và công nghệ “giới hạn sự hướng dẫn” cũng là tác nhân của rủi ro. Rủi ro kĩ thuật xảy ra vì vấn đề khó giải quyết hơn chúng ta nghĩ nó sẽ xảy ra. - Rủi ro nghiệp vụ là mối đe doạ khả năng tồn tại của phần mềm được xây dựng. Rủi ro nghiệp vụ thường gây nguy hiểm cho dự án hoặc sản phẩm. Dự tính có 5 loại rủi ro nghiệp vụ có thể là (1) rủi ro thị trường, (2) rủi ro chiến lược), (3) xây dựng một sản phẩm với nỗ lực để bán nhưng không hiểu phải bán như thế nào, (4) rủi ro quản lý), và (5) rủi ro ngân sách). Nhận diện rủi ro - Quy mô sản phẩm (product size) - Ảnh hưởng của thị trường (Businees Impact) - Đặc tính của khách hàng (Customer Characteristics) - Xác định quy trình (Process Definition) - Môi trường phát triển - Công nghệ để xây dựng phần mềm - Quy mô và kinh nghiệm của nhân viên 2.5.3 Quy trình quản lý rủi ro Hình 2.5: Quy trình quản lý rủi ro Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Chương 3: Lập trình 3.1 Ngôn ngữ lập trình Ngôn ngữ lập trình là phương tiện để liên lạc giữa con người và máy tính. Tiến trình lập trình - sự liên lạc thông qua ngôn ngữ lập trình - là một hoạt động con người. Lập trình là bước cốt lõi trong tiến trình kỹ nghệ phần mềm. 3.1.1 Đặc trưng của ngôn ngữ lập trình Cách nhìn kỹ nghệ phần mềm về các đặc trưng của ngôn ngữ lập trình tập trung vào nhu cầu xác định dự án phát triển phần mềm riêng. Mặc dầu người ta vẫn cần các yêu cầu riêng cho chương trình gốc, có thể thiết lập được một tập hợp tổng quát những đặc trưng kỹ nghệ: (1) dễ dịch thiết kế sang chương trình, (2) có trình biên dịch hiệu quả, (3) khả chuyển chương trình gốc, (4) có sẵn công cụ phát triển, (5) dễ bảo trì. Bước lập trình bắt đầu sau khi thiết kế chi tiết đã được xác định, xét duyệt và sửa đổi nếu cần. Về lý thuyết, việc sinh chương trình gốc từ một đặc tả chi tiết nên là trực tiếp. Dễ dịch thiết kế sang chương trình đưa ra một chỉ dẫn về việc một ngôn ngữ lập trình phản xạ gần gũi đến mức nào cho một biểu diễn thiết kế. Một ngôn ngữ cài đặt trực tiếp cho các kết cấu có cấu trúc, các cấu trúc dữ liệu phức tạp, vào/ra đặc biệt, khả năng thao tác bit, và các kết cấu hướng sự vật sẽ làm cho việc dịch từ thiết kế sang chương trình gốc dễ hơn nhiều (nếu các thuộc tính này được xác định trong thiết kế). Mặc dầu những tiến bộ nhanh chóng trong tốc độ xử lý và mật độ nhớ đã bắt đầu làm giảm nhẹ nhu cầu chương trình siêu hiệu quả, nhiều ứng dụng vẫn còn đòi hỏi các chương trình chạy nhanh, gọn (yêu cầu bộ nhớ thấp). Các ngôn ngữ với trình biên dịch tối ưu có thể là hấp dẫn nếu hiệu năng phần mềm là yêu cầu chủ chốt. Tính khả chuyển chương trình gốc là một đặc trưng ngôn ngữ lập trình có thể được hiểu theo ba cách khác nhau: - Chương trình gốc có thể được chuyển từ bộ xử lý này sang bộ xử lý khác và từ trình biên dịch nọ sang trình biên dịch kia với rất ít hoặc không phải sửa đổi gì. - Chương trình gốc vẫn không thay đổi ngay cả khi môi trường của nó thay đổi (như việc cài đặt bản mới của hệ điều hành). - Chương trình gốc có thể được tích hợp vào trong các bộ trình phần mềm khác nhau với ít hay không cần thay đổi gì vì các đặc trưng của ngôn ngữ lập trình. Trong số ba cách hiểu về tính khả chuyển này thì cách thứ nhất là thông dụng nhất. Việc đưa ra các chuẩn (do tổ chức tiêu chuẩn quốc tế IFO hay Viện tiêu chuẩn quốc gia Mĩ - ANSI) góp phần làm nâng cao tính khả chuyển. Tính sẵn có của công cụ phát triển có thể làm ngắn bớt thời gian cần để sinh ra chương trình gốc và có thể cải thiện chất lượng của chương trình. Nhiều ngôn ngữ lập trình có thể cần tới một loạt công cụ kể cả trình biên dịch gỡ lỗi, trợ giúp định dạng chương trình gốc, các tiện nghi soạn thảo có sẵn, các công cụ kiểm soát chương trình gốc, thư viện chương trình con mở rộng trong nhiều lĩnh vực ứng dụng, các trình duyệt, trình biên dịch chéo cho phát triển bộ vi xử lý, khả năng bộ xử lý Đại học Đông Á Bài giảng môn Công nghệ Phần mềm macro, công cụ kỹ nghệ ngược và những công cụ khác. Trong thực tế, khái niệm về môi trường phát triển phần mềm tốt (bao hàm cả các công cụ) đã được thừa nhận như nhân tố đóng góp chính cho kỹ nghệ phần mềm thành công. Tính dễ bảo trì của chương trình gốc có tầm quạn trọng chủ chốt cho tất cả các nỗ lực phát triển phần mềm không tầm thường. Việc bảo trì không thể được tiến hành chừng nào người ta còn chưa hiểu được phần mềm. Các yếu tố của cấu hình phần mềm (như tài liệu thiết kế) đưa ra một nền tảng cho việc hiểu biết, nhưng cuối cùng thì chương trình gốc vẫn phải được đọc và sửa đổi theo những thay đổi trong thiết kế. Tính dễ dịch thiết kế sang chương trình là một yếu tố quan trọng để dễ bảo trì chương trình gốc. Bên cạnh đó, các đặc trưng tự làm tài liệu của ngôn ngữ (như chiều dài được phép của tên gọi, định dạng nhãn, định nghĩa kiểu, cấu trúc dữ liệu) có ảnh hưởng mạnh đến tính dễ bảo trì. 3.1.2 Lựa chọn ngôn ngữ lập trình Các đặc trưng của ngôn ngữ lập trình sẽ quyết định miền ứng dụng của ngôn ngữ. Miền ứng dụng là yếu tố chính để chúng ta lựa chọn ngôn ngữ cho một dự án phần mềm. C thường là một ngôn ngữ hay được chọn cho việc phát triển phần mềm hệ thống. Trong các ứng dụng thời gian thực chúng ta hay gặp các ngôn ngữ như Ada, C, C++ và cả hợp ngữ do tính hiệu quả của chúng. Các ngôn ngữ này và Java cũng được dùng cho phát triển phần mềm nhúng. Trong lĩnh vực khoa học kỹ thuật thì FORTRAN với khả năng tính toán với độ chính xác cao và thư viện toán học phong phú vẫn còn là ngôn ngữ thống trị. Tuy vậy, PASCAL và C cũng được dùng rộng rãi. COBOL là ngôn ngữ cho ứng dụng kinh doanh và khai thác CSDL lớn nhưng các ngôn ngữ thế hệ thứ tư đã dần dần chiếm ưu thế. BASIC vẫn đang tiến hóa (Visual Basic) và được đông đảo người dùng máy tính cá nhân ủng hộ mặc dù ngôn ngữ này rất hiếm khi được những người phát triển hệ thống dùng. Các ứng dụng trí tuệ nhân tạo thường dùng các ngôn ngữ như LISP, PROLOG hay OPS5, tuy vậy nhiều ngôn ngữ lập trình (vạn năng) khác cũng được dùng. Xu hướng phát triển phần mềm hướng đối tượng xuyên suốt phần lớn các miền ứng dụng đã mở ra nhiều ngôn ngữ mới và các dị bản ngôn ngữ qui ước. Các ngôn ngữ lập trình hướng đối tượng được dùng rộng rãi nhất là Smalltalk, C++, Java. Ngoài ra còn có Eiffel, Object- PASCAL, Flavos và nhiều ngôn ngữ khác. Với đặc trưng hướng đối tượng, tính hiệu quả thực hiện cũng như có nhiều công cụ và thư viện, C++ hiện đang được sử dụng rộng rãi trong lĩnh vực phát triển các ứng dụng nghiệp vụ. Java cũng là một ngôn ngữ hướng đối tượng đang được sử dụng rộng rãi cho phát triển các dịch vụ Web và phần mềm nhúng vì các lý do độ an toàn cao, tính trong sáng, tính khả chuyển và hướng thành phần. Theo một số thống kê thì tốc độ phát triển một ứng dụng mới bằng Java cao hơn đến 2 lần so với các ngôn ngữ truyền thống như C hay thậm chí C++. Các ngôn ngữ biên dịch (script) với những câu lệnh và thư viện mạnh hiện đang rất được chú ý. ASP, JavaScript, PERL... đang được sử dụng rộng rãi trong lập trình Web. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm 3.1.3 Ngôn ngữ lập trình và và sự ảnh hưởng tới kỹ nghệ phần mềm Nói chung, chất lượng của thiết kế phần mềm được thiết lập theo cách độc lập với các đặc trưng ngôn ngữ lập trình. Tuy nhiên thuộc tính ngôn ngữ đóng một vai trò trong chất lượng của thiết kế được cài đặt và ảnh hưởng tới cách thiết kế được xác định. Ví dụ như khả năng xây dựng mô đun và bao gói chương trình. Thiết kế dữ liệu cũng có thể bị ảnh hưởng bởi các đặc trưng ngôn ngữ. Các ngôn ngữ lập trình như Ada, C++, Smalltalk đều hỗ trợ cho khái niệm về kiểu dữ liệu trừu tượng - một công cụ quan trọng trong thiết kế và đặc tả dữ liệu. Các ngôn ngữ thông dụng khác, như PASCAL, cho phép định nghĩa các kiểu dữ liệu do người dùng xác định và việc cài đặt trực tiếp danh sách móc nối và những cấu trúc dữ liệu khác. Các tính năng này cung cấp cho người thiết kế phạm vi rộng hơn trong các bước thiết kế sơ bộ và chi tiết. Các đặc trưng của ngôn ngữ cũng ảnh hưởng tới kiểm thử phần mềm. Các ngôn ngữ trực tiếp hỗ trợ cho các kết cấu có cấu trúc có khuynh hướng giảm bớt độ phức tạp của chương trình, do đó có thể làm cho nó dễ dàng kiểm thử. Các ngôn ngữ hỗ trợ cho việc đặc tả các chương trình con và thủ tục ngoài (như FORTRAN) thường làm cho việc kiểm thử tích hợp ít sinh lỗi hơn. 3.2 Phong cách lập trình Phong cách lập trình bao hàm một triết lý về lập trình nhấn mạnh tới tính dễ hiểu của chương trình nguồn. Các yếu tố của phong cách bao gồm: tài liệu bên trong chương trình, phương pháp khai báo dữ liệu, cách xây dựng câu lệnh và các kỹ thuật vào/ra. 3.2.1 Tài liệu chương trình Tài liệu bên trong của chương trình gốc bắt đầu với việc chọn lựa các tên gọi định danh (biến và nhãn), tiếp tục với vị trí và thành phần của việc chú thích, và kết luận với cách tổ chức trực quan của chương trình. Việc lựa chọn các tên gọi định danh có nghĩa là điều chủ chốt cho việc hiểu chương trình. Những ngôn ngữ giới hạn độ dài tên biến hay nhãn làm các tên mang nghĩa mơ hồ. Cho dù một chương trình nhỏ thì một tên gọi có nghĩa cũng làm tăng tính dễ hiểu. Theo ngôn từ của mô hình cú pháp/ngữ nghĩa tên có ý nghĩa làm “đơn giản hóa việc chuyển đổi từ cú pháp chương trình sang cấu trúc ngữ nghĩa bên trong”. Một điều rõ ràng là: phần mềm phải chứa tài liệu bên trong. Lời chú thích cung cấp cho người phát triển một ý nghĩa truyền thông với các độc giả khác về chương trình gốc. Lời chú thích có thể cung cấp một hướng dẫn rõ rệt để hiểu trong pha cuối cùng của kỹ nghệ phần mềm - bảo trì. Có nhiều hướng dẫn đã được đề nghị cho việc viết lời chú thích. Các chú thích mở đầu và chú thích chức năng là hai phạm trù đòi hỏi cách tiếp cận có hơi khác. Lời chú thích mở đầu nên xuất hiện ở ngay đầu của mọi modul. Định dạng cho lời chú thích như thế là: 1. Một phát biểu về mục đích chỉ rõ chức năng mô đun. 2. Mô tả giao diện bao gồm: - Một mẫu cách gọi - Mô tả về dữ liệu - Danh sách tất cả các mô đun thuộc cấp Đại học Đông Á Bài giảng môn Công nghệ Phần mềm 3. Thảo luận về dữ liệu thích hợp (như các biến quan trọng và những hạn chế, giới hạn về cách dùng chúng) và các thông tin quan trọng khác. 4. Lịch sử phát triển bao gồm: - Tên người thiết kế modul (tác giả). - Tên người xét duyệt và ngày tháng. - Ngày tháng sửa đổi và mô tả sửa đổi. Các chú thích chức năng được nhúng vào bên trong thân của chương trình gốc và được dùng để mô tả cho các khối chương trình. 3.2.2 Khai báo dữ liệu Thứ tự khai báo dữ liệu nên được chuẩn hóa cho dù ngôn ngữ lập trình không có yêu cầu bắt buộc nào về điều đó. Các tên biến ngoài việc có nghĩa còn nên mang thông tin về kiểu của chúng. Ví dụ, nên thống nhất các tên biến cho kiểu số nguyên, kiểu số thực... Cần phải chú giải về mục đích đối với các biến quan trọng, đặc biệt là các biến tổng thể. Các cấu trúc dữ liệu nên được chú giải đầy đủ về cấu trúc và chức năng, và các đặc thù về sử dụng. Đặc biệt là đối với các cấu trúc phức tạp như danh sách móc nối trong C hay Pascal. 3.2.3 Xây dựng câu lệnh Việc xây dựng luồng logic phần mềm được thiết lập trong khi thiết kế. Việc xây dựng từng câu lệnh tuy nhiên lại là một phần của bước lập trình. Việc xây dựng câu lệnh nên tuân theo một qui tắc quan trọng hơn cả: mỗi câu lệnh nên đơn giản và trực tiếp. Nhiều ngôn ngữ lập trình cho phép nhiều câu lệnh trên một dòng. Khía cạnh tiết kiệm không gian của tính năng này khó mà biện minh bởi tính khó đọc nảy sinh. Cấu trúc chu trình và các phép toán điều kiện được chứa trong đoạn trên đều bị che lấp bởi cách xây dựng nhiều câu lệnh trên một dòng. Cách xây dựng câu lệnh đơn và việc tụt lề minh họa cho các đặc trưng logic và chức năng của đoạn này. Các câu lệnh chương trình gốc riêng lẻ có thể được đơn giản hóa bởi: - tránh dùng các phép kiểm tra điều kiện phức tạp - khử bỏ các phép kiểm tra điều kiện phủ định - tránh lồng nhau nhiều giữa các điều kiện hay chu trình - dùng dấu ngoặc để làm sáng tỏ các biểu thức logic hay số học - dùng dấu cách và/hoặc các ký hiệu dễ đọc để làm sáng tỏ nội dung câu lệnh - chỉ dùng các tính năng chuẩn của ngôn ngữ Để hướng tới chương trình dễ hiểu luôn nên đặt ra câu hỏi: Liệu có thể hiểu được điều này nếu ta không là người lập trình cho nó không? 3.2.4 Vào/ra Vào ra của các mô đun nên tuân thủ theo một số hướng dẫn sau: - Làm hợp lệ mọi cái vào. - Kiểm tra sự tin cậy của các tổ hợp khoản mục vào quan trọng. - Giữ cho định dạng cái vào đơn giản. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Dùng các chỉ báo cuối dữ liệu thay vì yêu cầu người dùng xác định “số các khoản mục”. - Giữ cho định dạng cái vào thống nhất khi một ngôn ngữ lập trình có các yêu cầu định dạng nghiêm ngặt. 3.3 Lập trình tránh lỗi Tránh lỗi và phát triển phần mềm vô lỗi dựa trên các yếu tố sau: i) Sản phẩm của một đặc tả hệ thống chính xác. ii) Chấp nhận một cách tiếp cận thiết kế phần mềm dựa trên việc bao gói dữ liệu và che dấu thông tin. iii) Tăng cường duyệt lại trong quá trình phát triển và thẩm định hệ thống phần mềm. iv) Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phần mềm. v) Việc lập kế hoạch cẩn thận cho việc thử nghiệm hệ thống để tìm ra các lỗi chưa được phát hiện trong quá trình duyệt lại và để định lượng độ tin cậy của hệ thống. Có hai cách tiếp cận chính hỗ trợ tránh lỗi là: Lập trình có cấu trúc: Thuật ngữ này được đặt ra từ cuối những năm 60 và có nghĩa là lập trình mà không dùng lệnh goto, lập trình chỉ dùng các vòng lặp while và các phát biểu if để xây dựng điều khiển và trong thiết kế thì dùng cách tiếp cận trên - xuống. Việc thừa nhận lập trình có cấu trúc là quan trọng bởi vì nó là bước đầu tiên bước từ cách tiếp cận không khuôn phép tới phát triển phần mềm. Lập trình có cấu trúc buộc người lập trình phải nghĩ cẩn thận về chương trình của họ, và vì vậy nó ít tạo ra sai lầm trong khi phát triển. Lập trình có cấu trúc làm cho chương trình có thể được đọc một cách tuần tự và do đó dễ hiểu và dễ kiểm tra. Tuy nhiên nó chỉ là bước đầu tiên trong việc lập trình nhằm đạt độ tin cậy tốt. Có một vài khái niệm khác cũng hay dẫn tới các lỗi phần mềm: i) Các số thực dấu chấm động: các phép toán số thực được làm tròn khiến cho việc so sánh các kết quả số thực, nhất là so sánh bằng giữa hai số thực là không khả thi. Số thực dấu phẩy động có độ chính xác khác nhau khiến cho kết quả phép tính không theo mong muốn. Ví dụ, trong phép tính tính phân chúng ta cần cộng các giá trị nhỏ trước với nhau nếu không chúng sẽ bị làm tròn. ii) Các con trỏ và bộ nhớ động: con trỏ là các cấu trúc bậc thấp khó quản lý và dễ gây ra các lỗi nghiệm trọng đối với hệ thống. Việc cấp phát và thu hồi bộ nhớ động phức tạp và là một trong các nguyên nhân chính gây lỗi phần mềm. iii) Song song: lập trình song song đòi hỏi kỹ thuật cao và hiểu biết sâu sắc về hệ thống. Một trong các vấn đề phức tạp của song song là quản lý tương tranh. iv) Đệ quy. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm v) Các ngắt. Các cấu trúc này có ích, nhưng người lập trình nên dùng chúng một cách cẩn thận. Phân quyền truy cập dữ liệu: Nguyên lý an ninh trong quân đội là các cá nhân chỉ được biết các thông tin có liên quan trực tiếp đến nhiện vụ của họ. Khi lập trình người ta cũng tuân theo một nguyên lý tương tự cho việc truy cập dữ liệu hệ thống. Mỗi thành phần chương trình chỉ được phép truy cập đến dữ liệu nào cần thiết để thực hiện chức năng của nó. Ưu điểm của việc che dấu thông tin là các thông tin bị che dấu không thể bị sập đổ (thao tác trái phép) bởi các thành phần chương trình mà được xem rằng không dùng thông tin đó. Tiến hóa của sự phân quyền truy cập là che dấu thông tin, hay nói chính xác hơn là che dấu cấu trúc thông tin. Khi đó, chúng ta có thể thay đổi cấu trúc thông tin mà không phải thay đổi các thành phần khác có sử dụng thông tin đó. 3.3.1 Lập trình thứ lỗi Đối với các hệ thống đòi hỏi độ tin cậy rất cao như hệ thống điều khiển bay thì cần phải có khả năng dung thứ lỗi (fault tolerance), tức là khả năng đảm bảo cho hệ thống vẫn hoạt động chính xác ngay cả khi có thành phần sinh lỗi. Có bốn hoạt động cần phải tiến hành nếu hệ thống là thứ lỗi: i) Phát hiện lỗi. ii) Định ra mức độ thiệt hại. iii) Hồi phục sau khi gặp lỗi: Hệ thống phải hồi phục về trạng thái mà nó biết là an toàn. Cũng có thể là chỉnh lý trạng thái bị hủy hoại (hồi phục tiến), cũng có thể là lui về một trạng thái trước mà an toàn (hồi phục lùi). vi) Chữa lỗi: Cải tiến hệ thống để cho lỗi đó không xuất hiện nữa. Tuy nhiên trong nhiều trường hợp phát hiện được đúng nguyên nhân gây lỗi là rất khó khăn vì nó xẩy ra bởi một tổ hợp của thông tin vào và trạng thái của hệ thống. Thông thường, thứ lỗi được thực hiện bằng cách song song hóa các chức năng, kết hợp với bộ điều khiển thứ lỗi. Bộ điều khiển sẽ so sánh kết quả của các khối chương trình thực hiện cùng nhiệm vụ và sử dụng nguyên tắc đa số để chọn kết quả. 3.3.2 Lập trình phòng thủ Lập trình phòng thủ là cách phát triển chương trình mà người lập trình giả định rằng các mâu thuẫn hoặc các lỗi chưa được phát hiện có thể tồn tại trong chương trình. Phải có phần mềm kiểm tra trạng thái hệ thống sau khi biến đổi và phải đảm bảo rằng sự biến đổi trạng thái là kiên định. Nếu phát hiện một mâu thuẫn thì việc biến đổi trạng thái là phải rút lại và trạng thái phải trở về trạng thái đúng đắn trước đó. Nói chung một lỗi gây ra một sự sụp đổ trạng thái: các biến trạng thái được gán các trị không hợp luật. Ngôn ngữ lập trình như Ada cho phép phát hiện ra các lỗi đó ngay trong thời gian biên dịch. Tuy nhiên việc kiểm tra biên dịch chỉ hạn chế cho các giá trị tĩnh và một vài phép kiểm tra thời gian thực là không thể tránh được. Một cách để phát hiện lỗi trong chương trình Ada là dùng cơ chế xử lý bất thường kết hợp với đặc tả miền trị. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Hồi phục lỗi là một quá trình cải biên không gian trạng thái của hệ thống sao cho hiệu ứng của lỗi là nhỏ nhất và hệ thống có thể tiếp tục vận hành, có lẽ là trong một mức suy giảm. Hồi phục tiến liên quan đến việc cố gắng chỉnh lại trạng thái hệ thống. Hồi phục lùi liên quan đến việc lưu trạng thái của hệ thống ở một trạng thái đúng đã biết. Hồi phục tiến thường là một chuyên biệt ứng dụng. Có hai tình thế chung mà khi đó hồi phục tiến có thể thành công: 1) Khi dữ liệu mã bị sụp đổ: Việc sử dụng kỹ thuật mã hóa thích hợp bằng cách thêm các dữ liệu dư thừa vào dữ liệu cho phép sửa sai khi phát hiện lỗi. 2) Khi cấu trúc nối bị sụp đổ: Nếu các con trỏ tiến và lùi đã có trong cấu trúc dữ liệu thì cấu trúc đó có thể tái tạo nếu như còn đủ các con trỏ chưa bị sụp. Kỹ thuật này thường được dùng cho việc sửa chữa hệ thống tệp và cơ sở dữ liệu. Hồi phục lùi là một kỹ thuật đơn giản liên quan đến việc duy trì các chi tiết của trạng thái an toàn và cất giữ trạng thái đó khi mà sai lầm đã bị phát hiện. Hầu hết các hệ quản trị cơ sở dữ liệu đều có bộ hồi phục lỗi. CSDL chỉ cập nhật dữ liệu một khi giao dịch đã hoàn tất và không phát hiện được vấn đề gì. Nếu giao dịch thất bại thì CSDL không được cập nhật. Một kỹ thuật khác là thiết lập các điểm kiểm tra thường kỳ mà chúng là các bản sao của trạng thái hệ thống. Khi mà một lỗi được phát hiện thì trạng thái an toàn đó được tái lưu kho từ điểm kiểm tra gần nhất. Trường hợp hệ thống dính líu tới nhiều quá trình hợp tác thì dãy các giao tiếp có thể là các điểm kiểm tra của các quá trình đó không đồng bộ và để hồi phục thì mỗi quá trình phải trở lại trạng thái ban đầu của nó. 3.4 Lập trình hướng hiệu quả thực hiện 3.4.1 Tính hiệu quả chương trình Tính hiệu quả của chương trình gốc có liên hệ trực tiếp với tính hiệu quả của thuật toán được xác định trong thiết kế chi tiết. Tuy nhiên, phong cách lập trình có thể có một tác động đến tốc độ thực hiện và yêu cầu bộ nhớ. Tập hợp các hướng dẫn sau đây bao giờ cũng có thể áp dụng được khi thiết kế chi tiết được dịch thành chương trình: - Đơn giản hóa các biểu thức số học và lôgic trước khi đi vào lập trình. - Tính cẩn thận từng chu kỳ lồng nhau để xác định liệu các câu lệnh hay biểu thức có thể được chuyển ra ngoài hay không - Khi có thể, hãy tránh dùng mảng nhiều chiều - Khi có thể hãy tránh việc dùng con trỏ và danh sách phức tạp - Dùng các phép toán số học “nhanh” - Không trộn lẫn các kiểu dữ liệu, cho dù ngôn ngữ có cho phép điều đó - Dùng các biểu thức số học và logic bất kì khi nào có thể được Nhiều trình biên dịch có tính năng tối ưu tự động sinh ra chương trình hiệu quả bằng cách dồn nén các biểu thức lặp, thực hiện tính chu trình, dùng số học nhanh và áp dụng các thuật toán có hiệu quả liên quan khác. Với những ứng dụng trong đó tính hiệu quả có ý nghĩa quan trọng, những trình biên dịch như thế là công cụ lập trình không thể thiếu được. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm 3.4.2 Hiệu quả bộ nhớ Tính hiệu quả bộ nhớ phải được tính vào đặc trưng phân trang của hệ điều hành. Nói chung, tính cục bộ của chương trình hay việc bảo trì lĩnh vực chức năng qua các kết cấu có cấu trúc là một phương pháp tuyệt vời làm giảm việc phân trang và do đó làm tăng tính hiệu quả. Hạn chế bộ nhớ trong phát triển phần mềm nhúng là mối quan tâm rất thực tế, mặc dầu bộ nhớ giá thấp, mật độ cao vẫn đang tiến hóa nhanh chóng. Nếu yêu cầu hệ thống cần tới bộ nhớ tối thiểu (như sản phẩm giá thấp, khối lượng lớn) thì trình biên dịch ngôn ngữ cấp cao phải được trù tính cẩn thận với tính năng nén bộ nhớ, hay như một phương kế cuối cùng, có thể phải dùng tới hợp ngữ. 3.4.3 Hiệu quả vào/ra Các thiết bị vào ra thường có tốc độ chậm hơn rất nhiều so với khả năng tính toán của máy tính và tốc độ truy cập bộ nhớ trong. Việc tối ưu vào ra có thể làm tăng đáng kể tốc độ thực hiện. Một số hướng dẫn đơn giản để tăng cường hiệu quả vào/ra: • Số các yêu cầu vào/ra nên giữ mức tối thiểu • Mọi việc vào/ra nên qua bộ đệm để làm giảm phí tổn liên lạc. • Với bộ nhớ phụ (như đĩa) nên lựa chọn và dùng phương pháp thâm nhập đơn giản nhất chấp nhận được. • Nên xếp khối vào/ra với các thiết bị bộ nhớ phụ. • Việc vào/ra với thiết bị cuối hay máy in nên nhận diện các tính năng của thiết bị có thể cải tiến chất lượng hay tốc độ. 3.5 Tổng kết Bước lập trình là một tiến trình dịch (chuyển hóa) thiết kế chi tiết thành chương trình mà cuối cùng được biến đổi thành các lệnh mã máy thực hiện được. Các đặc trưng của ngôn ngữ lập trình có ảnh hưởng lớn đến quá trình xây dựng, kiểm thử cũng như bảo trì phần mềm. Phong cách lập trình quyết định tính dễ hiểu của chương trình gốc. Các yếu tố của phong cách bao gồm việc làm tài liệu bên trong, phương pháp khai báo dữ liệu, thủ tục xây dựng câu lệnh, và kỹ thuật lập trình vào/ra. Lập trình cần hướng tới hiệu quả thực hiện, tức là tích kiệm tài nguyên phần cứng (mức độ sử dụng CPU, bộ nhớ...). Mặc dầu tính hiệu quả có thể là yêu cầu cực kì quan trọng, chúng ta nên nhớ rằng một chương trình hoạt động hiệu quả mà lại không dễ hiểu dẫn đến khó bảo trì thì giá trị của nó cũng bị hạn chế. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Chương 4: Kiểm nghiệm và bảo trì phần mềm 4.1 Kiểm nghiệm phần mềm 4.1.1 Khái niệm kiểm nghiệm phần mềm Lý do phải kiểm nghiệm phần mềm Mặc dù được tự động hoá một phần bởi các công cụ CASE, rất nhiều công đoạn trong quá trình sản xuất phần mềm vẫn được thực hiện bởi con người  vẫn có khả năng xảy ra lỗi. Lỗi có thể xảy ra trong tất cả các giai đoạn: phân tích yêu cầu, thiết kế, mã hoá  Do đó phải kiểm nghiệm chương trình trước khi chính thức sử dụng Khái niệm kiểm nghiệm phần mềm Kiểm nghiệm phần mềm là hoạt động thực thi chương trình với mục đích tìm ra lỗi. Phân loại: - Kiểm nghiệm black-box: kiểm tra các chức năng cụ thể của phần mềm, không quan tâm cấu trúc bên trong, thường áp dụng cho những module lớn. - Kiểm nghiệm white-box: kiểm tra cấu trúc điều khiển bên trong chương trình, thường dùng cho những những module nhỏ. Mỗi loại kiểm nghiệm có khả năng tìm ra những nhóm lỗi khác nhau  nên kết hợp cả hai Mục tiêu của kiểm nghiệm phần mềm Mục tiêu của kiểm nghiệm phần mềm là tìm ra lỗi (nếu có) với chi phí thấp nhất. Kiểm nghiệm phần mềm giúp: - Phát hiện được lỗi trong chương trình (nếu có). - Chứng minh được phần mềm hoạt động đúng như đã thiết kế. Chứng minh phần mềm được viết đúng - Chứng minh được phần mềm đáp ứng yêu cầu của user Góp phần chứng minh chất lượng của phần mềm. Quá trình kiểm nghiệm phần mềm là tốt khi - Có khả năng tìm ra lỗi cao. - Không dư thừa. - Biết chọn lọc: chỉ kiểm nghiệm những phần nào có khả năng tìm ra lỗi đặc trưng. - Không quá phức tạp cũng không quá đơn giản. Chú ý: Kiểm nghiệm phần mềm không khẳng định được phần mềm không còn khiếm khuyết, chỉ khẳng định được phần mềm có lỗi và giúp giảm thiểu lỗi. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm 4.1.2 Các nguyên lý kiểm nghiệm phần mềm - Việc kiểm nghiệm nên hướng về yêu cầu của khách hàng - Nên được hoạch định trước một thời gian dài. - Áp dụng nguyên lý Pareto (nguyên tắc 80-20): - 80% lỗi có nguyên nhân từ 20% các module  cô lập và kiểm tra những module khả nghi nhất. - Nên tiến hành từ nhỏ đến lớn: bắt đầu từ những module riêng biệt rồi sau đó tích hợp các module lại. - Không thể kiểm nghiệm triệt để một phần mềm. - Nên được thực hiện bởi những đối tượng KHÔNG tham gia vào quá trình phát triển phần mềm. 4.1.3 Phương pháp kiểm nghiệm – Test Case - Thiết lập các test case – vận hành thử - so sánh kết quả - Khái niệm test-case + Dữ liệu input + Thao tác kiểm nghiệm + Dữ liệu output hay đáp ứng mong đợi của chương trình - Test-case cho kiểm nghiệm black-box: chủ yếu dựa vào các yêu cầu cụ thể của chức năng phần mềm. - Test-case cho kiểm nghiệm white-box: chủ yếu dựa vào cấu trúc điều khiển của phần mềm  vấn đề đặt ra: số lượng test-case cần thiết là quá lớn Kiểm nghiệm các đường độc lập cơ bản Kiểm nghiệm white-box dựa vào cấu trúc điều khiển của thiết kế thủ tục để sinh các test-case với tiêu chí - Kiểm nghiệm các đường độc lập cơ bản là một trong những phương cách kiểm nghiệm white-box - Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗi - Tất cả các đường thực thi độc lập được thử qua ít nhất một lần - Thử các điều kiện rẽ nhánh ở cả 2 nhánh true và false - Thử qua vòng lặp tại biên cũng như bên trong - Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó 4.1.3.1 Đồ thị dòng chảy - Mỗi node hình tròn biểu diễn một hoặc một vài tác vụ (hơi khác so với lưu đồ thuật giải) - Cạnh có hướng miêu tả đường thực thi - Đồ thị dòng chảy được xây dựng từ lưu đồ thuật giải Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Hình 4.1: Lưu đồ thuật giải Xây dựng đồ thị dòng chảy Hình 4.2: Xây dựng đồ thị dòng chảy procedure: DoSomething 1: do while x=0 2: if y=0 then 3: z=0; 4: elseif k=0 then 5: z=1; 6: else x=1; 7: endif; endif; 8: enddo 9: end Hình 4.3: Ví dụ xây dựng đồ thị dòng chảy Phải phân rã tất cả các điều kiện phức trở thành các điều kiện đơn Mỗi node mô tả một điều kiện đơn được gọi là predicate Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Hình 4.4: Phân rã điều kiện phức thành điều kiện đơn Hình 4.5: Ví dụ Procedure AnalyzeTriangle Các đường độc lập cơ bản - Đường thực thi - Đường thực thi cơ bản - Các đường thực thi độc lập cơ bản Từ node bắt đầu đến node kết thúc, các đường thực thi cơ bản được liệt kê theo một thứ tự nào đó để đảm bảo rằng: đường đang liệt kê ít nhất đi qua một cạnh chưa được duyệt qua bởi các đường đã liệt kê trước đó - Tổng số đường thực thi cơ bản độc lập nhau được tính bằng V = P + 1; trong đó P là số node phân nhánh (predicate) Đối với chương trình con DoSomething - Tổng số đường : V = 3 + 1 = 4 - Đường 1: 1-9 - Đường 2: 1-2-3-8-1 - Đường 3: 1-2-4-5-7-8-1 Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Đường 4: 1-2-4-6-7-8-1 Chú ý: dấu 3 chấm () mang ý nghĩa “không quan tâm”, từ đó có thể đi theo bất kỳ cạnh nào bởi vì các cạnh sau đó đã được duyệt qua rồi Đối với chương trình con AnalyzeTriangle - Tổng số đường : V = 6 + 1 = 7 - Đường 1: 1-3-12 - Đường 2: 1-2-3-12 - Đường 3: 1-2-4-5-12 - Đường 4: 1-2-4-6-7-12 - Đường 5: 1-2-4-6-8-7-12 - Đường 6: 1-2-4-6-8-9-10-12 - Đường 7: 1-2-4-6-8-9-11-12 4.1.3.2 Thiết lập các Test Case - Thiết lập một test-case cho mỗi đường thực thi cơ bản - Dựa vào thuật giải để tìm ra một dữ liệu input, sau đó tính ra dữ liệu output hay đáp ứng mong đợi của thuật giải - Chú ý: có thể không tạo ra được test-case cho một đường thực thi nào đó - Ví dụ Sinh test-case cho chương trình con AnalyzeTriangle - Test-case cho đường 1: Input: a = 3, b = 2, c = 0 Output mong đợi: type = “Error” - Test-case cho đường 2: Input: a = 17, b = 5, c = 4 Output mong đợi: type = “Error” - Test-case cho đường 3: Input: a = 6, b = 6, c = 6 Output mong đợi: type = “Equilateral” 4.2 Chiến thuật kiểm nghiệm phần mềm 4.2.1 Khái niệm Chiến thuật kiểm tra phần mềm tích hợp các phương pháp tạo ra test-case trở thành một chuỗi các bước có thứ tự để có thể kiểm nghiệm phần mềm thành công với chi phí thấp. Bao gồm các công việc – Lập kế hoạch kiểm nghiệm – Sinh test-case Đại học Đông Á Bài giảng môn Công nghệ Phần mềm – Thực hiện kiểm nghiệm, thu thập kết qủa và đánh giá Verification: các hành động để đảm bảo cho phần mềm được hiện thực đúng theo một chức năng cụ thể nào đó  “Are we building the product right?” Validation: các hành động để đảm bảo cho phần mềm được xây dựng theo đúng yêu cầu của khách hàng  “Are we building the right product?” 4.2.2 Chiến thuật kiểm nghiệm phần mềm phổ biến - Bắt đầu tại từng module rồi tích hợp lớn dần đến toàn bộ hệ thống. - Các kỹ thuật khác nhau được sử dụng thích hợp tại các giai đoạn khác nhau. - Kiểm nghiệm có thể được tiến hành bởi người phát triển phần mềm, nhưng đối với các dự án lớn thì việc kiểm nghiệm phải được tiến hành bởi một nhóm độc lập. - Kiểm nghiệm và sửa lỗi là các hoạt động độc lập nhưng việc sửa lỗi phải phù hợp với các chiến thuật kiểm nghiệm. Hình 4.6: Chiến thuật kiểm nghiệm phần mềm phổ biến 4.2.3 Kiểm nghiệm từng modul – Unit test - Tiến hành kiểm nghiệm trên từng đơn vị nhỏ nhất của phần mềm, đó là module mã nguồn, sau khi đã thiết kế, mã hoá và biên dịch thành công - Thường dùng kỹ thuật kiểm nghiệm white-box - Có thể tiến hành kiểm nghiệm cùng lúc nhiều module. - Một số vấn đề trong việc xây dựng các test case + Test case nào? + Dữ liệu đầu vào và đầu ra có tử đâu? + Tính độc lập/phụ thuộc hoạt động của các module Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Hình 4.7: Kiểm nghiệm module Mỗi module mã nguồn không phải là một chương trình hoàn chỉnh và đôi khi phải gọi các module chưa được kiểm nghiệm khác  có thể phải thiết lập driver và/hoặc stub: phí tổn khá lớn (70%) Driver là một chương trình chính có nhiệm vụ nhận dữ liệu kiểm nghiệm, chuyển dữ liệu đó xuống cho module để kiểm tra và in ra các kết quả kiểm tra tương ứng. Stub thay thế các module được gọi bởi module đang kiểm tra.  Làm thế nào để giảm các chi phí tạo driver hay stub 4.2.4 Kiểm nghiệm tích hợp - Từng module mã nguồn đã hoạt động đúng. Liệu khi kết hợp chúng lại thành một nhóm lớn chúng có hoạt động đúng không ? - Phải tiến hành kiểm nghiệm tích hợp để phát hiện lỗi liên quan đến giao tiếp giữa các module. - Tránh tích hợp kiểu big-bang: tất cả các module được kết hợp lại, và toàn bộ chương trình sẽ được kiểm nghiệm một lúc - Nên tích hợp tăng dần: từ trên xuống hoặc từ dưới lên Đại học Đông Á Bài giảng môn Công nghệ Phần mềm 4.2.4.1 Kiểm nghiệm tích hợp từ trên xuống Hình 4.8: Kiểm nghiệm tích hợp top-down - Module chính được dùng như là driver, và stub được thay thế bởi các module con trực tiếp của của module chính này. - Tuỳ thuộc vào cách tích hợp theo chiều sâu (depth-first) hoặc chiều ngang(breath-first), mỗi stub con được thay thế một lần bởi module tương ứng đã kiểm nghiệm. - Tiến hành kiểm nghiệm khi có sự thay thế mới - Tiến hành kiểm nghiệm hồi quy để phát hiện các lỗi khác trong từng module - Tích hợp kiểu từ trên xuống theo hình thức depth-first - Tiết kiệm được chi phí tạo các driver 4.2.4.2 Kiểm nghiệm tích hợp từ dưới lên - Các module mức thấp nhất được kết hợp thành các nhóm thể hiện một chức năng con đặc biệt của phần mềm. - Một driver được tạo ra để thao tác các test-case - Các module được kiểm nghiệm theo từng nhóm (Cluster): là nhóm các module mà module phía trên cần đến khi kiểm nghiệm - Driver được bỏ đi và các nhóm module được kết hợp dần lên phía trên trong sơ đồ phân cấp của chương trình. - Tiết kiệm được chi phí tạo các stub Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Hình 4.9: Kiểm nghiệm tích hợp bottom-up 4.2.4.3 Kiểm nghiệm hồi quy - Việc kết hợp các module lại với nhau có thể ảnh hưởng đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module - Điều đó làm lộ ra một số lỗi không thể phát hiện được khi tiến hành kiểm nghiệm theo đơn vị Phải kiểm nghiệm hồi quy khi tích hợp - Kiểm nghiệm hồi quy có thể được tiến hành thủ công bằng cách thực hiện lại các test-case đã tạo ra. Hoặc có thể dùng một công cụ capture-playback để thực hiện tự động 4.2.4.4 Kiểm nghiệm tính năng Kiểm nghiệm tính năng hiểu theo cách đơn giản nhất là: kiểm tra các chức năng của phần mềm đáp ứng được nhu cầu của khách hàng đã được xác định trong văn bản đặc tả yêu cầu của phần mềm Áp dụng kỹ thuật black-box Kiểm nghiệm tính năng bao gồm - Xem xét lại cấu hình phần mềm theo lược đồ triển khai - Kiểm nghiệm alpha - Kiểm nghiệm beta Kiểm nghiệm alpha - Được tiến hành ngay tại nơi sản xuất phần mềm. - Nhà phát triển phần mềm sẽ quan sát người sử dụng dùng sản phẩm và ghi nhận lại những lỗi phát sinh để sửa chữa. Kiểm nghiệm beta - Phần mềm được kiểm tra bên ngoài phạm vi của đơn vị sản xuất. Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại cho nhà phát triển sửa chữa. 4.2.4.5 Kiểm nghiệm hướng đối tượng Về cơ bản chiến thuật kiểm nghiệm hướng đối tượng cũng theo thứ tự giống như kiểm nghiệm cổ điển: Hình 4.10: Kiểm nghiệm hướng đối tượng Không thể tách rời từng tác vụ của đối tượng/lớp để kiểm nghiệm – Tác vụ được đóng bao trong lớp – Các lớp con có thể override một tác vụ nào đó Kiểm nghiệm đơn vị hướng đối tượng tập trung vào các lớp  kiểm nghiệm hành vi của lớp 4.2.4.6 Kiểm nghiệm tích hợp hướng đối tượng Khái niệm sơ đồ phân cấp không còn nhiều ý nghĩa trong chương trình hướng đối tượng  kiểm nghiệm tích hợp theo cách khác Hai hình thức kiểm nghiệm tích hợp hướng đối tượng – Kiểm nghiệm trên cơ sở thread: tích hợp các lớp tạo thành một thread để phục vụ cho một input nào đó của chương trình – Kiểm nghiệm trên cơ sở sử dụng: các lớp client sẽ được tích hợp để sử dụng dịch vụ nào đó cung cấp bởi các lớp server 4.2.4.7 Kiểm nghiệm theo kịch bản Dựa vào các use-case để soạn ra các kịch bản Ví dụ: một kịch bản cho hệ thống đăng ký môn học qua WEB 1. Login với username = “e59306547”, password = “6547” 2. Chọn chức năng đăng ký môn học 3. Chọn 5 nhóm môn học của 5 môn: CNPM, AI, XLTHS, PTTK, XLSS trong đó có 2 nhóm trùng thời khoá biểu 4. Nhấn nút Submit  Chương trình phải báo lỗi và liệt kê 2 nhóm bị trùng thời khoá biểu Đại học Đông Á Bài giảng môn Công nghệ Phần mềm 4.3 Bảo trì phần mềm 4.3.1 Khái niệm và phân loại bảo trì Bảo trì là công việc tu sửa, thay đổi phần mềm đã được phát triển (chương trình, dữ liệu, JCL, các loại tư liệu đặc tả, . . .) theo những lý do nào đó Các hình thái bảo trì: bảo trì để – Tu chỉnh – Thích hợp – Cải tiến – Phòng ngừa Bảo trì để tu sửa Là bảo trì khắc phục những khiếm khuyết có trong phần mềm. Một số nguyên nhân điển hình: – Kỹ sư phần mềm và khách hiểu nhầm nhau – Lỗi tiềm ẩn của phần mềm do sơ ý của lập trình hoặc khi kiểm thử chưa bao quát hết – Vấn đề tính năng của phần mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, . . . Thiết kế sai, biên tập sai . . . – Thiếu chuẩn hóa trong phát triển phần mềm (trước đó) Kỹ nghệ ngược (Reverse Engineering): dò lại thiết kế để tu sửa Những lưu ý – Mức trừu tượng – Tính đầy đủ – Tính tương tác – Tính định hướng Bảo trì để thích hợp Là tu chỉnh phần mềm theo thay đổi của môi trường bên ngoài nhằm duy trì và quản lý phần mềm theo vòng đời của nó. Thay đổi phần mềm thích nghi với môi trường: công nghệ phần cứng, môi trường phần mềm. Những nguyên nhân chính: – Thay đổi về phần cứng (ngoại vi, máy chủ,. . .) – Thay đổi về phần mềm (môi trường): đổi OS – Thay đổi cấu trúc tệp hoặc mở rộng CSDL Bảo trì để cải tiến Là việc tu chỉnh hệ phần mềm theo các yêu cầu ngày càng hoàn thiện hơn, đầy đủ hơn, hợp lý hơn. Những nguyên nhân chính: Đại học Đông Á Bài giảng môn Công nghệ Phần mềm – Do muốn nâng cao hiệu suất nên thường hay cải tiến phương thức truy cập tệp. – Mở rộng thêm chức năng mới cho hệ thống. – Cải tiến quản lý kéo theo cải tiến tư liệu vận hành và trình tự công việc. – Thay đổi người dùng hoặc thay đổi thao tác. Còn gọi là tái kỹ nghệ (re-engineering). Mục đích: đưa ra một thiết kế cùng chức năng nhưng có chất lượng cao hơn. Các bước thực hiện: – Xây dựng lưu đồ phần mềm – Suy dẫn ra biểu thức Bun cho từng dãy xử lý – Biên dịch bảng chân lí – Tái cấu trúc phần mềm Bảo trì để phòng ngừa Là công việc tu chỉnh chương trình có tính đến tương lai của phần mềm đó sẽ mở rộng và thay đổi như thế nào. Thực ra trong khi thiết kế phần mềm đã phải tính đến tính mở rộng của nó, nên thực tế ít khi ta gặp bảo trì phòng ngừa nếu như phần mềm được thiết kế tốt . Mục đích: – Sửa đổi để thích hợp với yêu cầu thay đổi sẽ có của người dùng – Thực hiện những thay đổi trên thiết kế không tường minh – Hiểu hoạt động bên trong chương trình – Thiết kế / lập trình lại – Sử dụng công cụ CASE 4.3.2 Trình tự nghiệp vụ bảo trì Quy trình bảo trì là gì ? Đó là quá trình trong vòng đời của phần mềm, cũng tuân theo các pha phân tích, thiết kế, phát triển và kiểm thử từ khi phát sinh vấn đề cho đến khi giải quyết xong. Thao tác bảo trì: Gồm 2 loại – Tu chỉnh cái đã có (loại 1) – Thêm cái mới (loại 2) Hiểu phần mềm đã có - Theo tài liệu nắm chắc các chức năng - Theo tài liệu chi tiết hãy nắm vững đặc tả chi tiết, điều kiện kiểm thử,... - Dò đọc chương trình nguồn, hiểu trình tự xử lý chi tiết của hệ thống 3 việc trên đều là công việc thực thi trên bàn Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Tu sửa phần mềm đã có - Bảo trì chương trình nguồn, tạo các môđun mới và dịch lại - Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặc tả - Chú ý theo sát tác động của môđun được sửa đến các thành phần khác trong hệ thống Phát triển phần mềm mới - Khi thêm chức năng mới phải phát triển chương trình cho phù hợp với yêu cầu - Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm thử unit - Phản ảnh vào giao diện của phần mềm (thông báo, phiên bản,...) Hình 4.11: Sơ đồ bảo trì Lập biểu quản lý bảo trì Cần quản lý tình trạng bảo trì Lập biểu quản lý tình trạng bảo trì - Ngày tháng, giờ - Nguyên nhân - Tóm tắt cách khắc phục - Chi tiết khắc phục, hiệu ứng làn sóng - Người làm bảo trì - Số công Những vấn đề lưu ý khi bảo trì phần mềm Phương pháp cải tiến thao tác bảo trì: Đại học Đông Á Bài giảng môn Công nghệ Phần mềm - Sáng kiến trong quy trình phát triển phần mềm - Sáng kiến trong quy trình bảo trì phần mềm - Phát triển những kỹ thuật mới cho bảo trì Sáng kiến trong quy trình phát triển phần mềm 1. Chuẩn hóa mọi khâu trong phát triển phần mềm 2. Người bảo trì chủ chốt tham gia vào giai đoạn phân tích và thiết kế 3. Thiết kế để dễ bảo trì Sáng kiến trong quy trình bảo trì phần mềm 1. Sử dụng các công cụ hỗ trợ phát triển phần mềm 2. Chuẩn hóa thao tác bảo trì và thiết bị môi trường bảo trì 3. Lưu lại những thông tin sử bảo trì 4. Dự án nên cử một người chủ chốt của mình làm công việc bảo trì sau khi dự án kết thưc giai đoạn phát triển Phát triển những kỹ thuật mới cho bảo trì - Công cụ phần mềm hỗ trợ bảo trì - Cơ sở dữ liệu cho bảo trì - Quản lý tài liệu, quản lý dữ liệu, quản lý chương trình nguồn, quản lý dữ liệu thử, quản lý sử bảo trì - Trạm bảo trì tính năng cao trong hệ thống mạng lưới bảo trì với máy chủ thông minh Đại học Đông Á Bài giảng môn Công nghệ Phần mềm Tài liệu tham khảo 1. Bài giảng Công nghệ Phần mềm – Nguyễn Cao Trí, Đại học Bách Khoa Tp Hồ Chí Minh 2. Bài giảng Công nghệ Phần mềm – Bộ môn Công nghệ Phần mềm, Viện Công nghệ Thông tin và Truyền thông, Đại học Bách Khoa Hà Nội. 3. Bài giảng Công nghệ Phần mềm – Nguyễn Việt Hà, Đại học Bách Khoa Hà Nội 4. Bài giảng Công nghệ Phần mềm – Nguyễn Văn Vỵ, Đại học Công Nghệ, Đại học Quốc gia Hà Nội 5. Giáo trình Phân tích và thiết kế hệ thống thông tin với UML – Ts Dương Kiều Hoa, Tôn Thất Hoà An 6. Giáo trình Phân tích thiết kế hệ thống thông tin – Học viện Công nghệ Bưu chính Viễn thông. 7. Introduction to Software Engineering – Ronald J. Leach, CRC Press 8. Software Engineering – Ian Sommerville , Fifth edition 9. Software Engineering – A practitioner’s approach, R.S.Pressman, McGraw-Hill, 1997 10. OMG Unified Modeling Language Specification, version 1.3, Object Management Group (www.omg.org), 1999 11. UML Toolkit, Hans – Erik Eriksson & Magnus Penker, 1998 12. Object–Oriented Software Engineering, A Use-Case Driven Approach, I. Jacobson, ACM Press/Addison-Wesley, 1992 13. Object– Oriented Analysis and Design with Applications, G. Booch, The Benjamin Cummings Publishing Company, 1994 14. Website: www.dayhoctructuyen.com,