Nhập môn Công nghệ phần mềm - Nguyễn Thế Dũng

Nội dung text: Nhập môn Công nghệ phần mềm - Nguyễn Thế Dũng

1. NGUYỄN THẾ DŨNG NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Trƣờng Đại học Sƣ phạm - Đại học Huế Huế, tháng 11 năm 2014 1
2. Giáo trình này được viết bởi Nguyễn Thế Dũng, giảng viên Khoa Tin học, Trường ĐHSP - Đại học Huế. Giáo trình này được dùng để giảng dạy và học tập học phần: Nhập môn Công nghệ phần mềm. Mã số: TINS4392 2
3. Lời nói đầu Môn học Nhập môn Công nhệ phần mềm là học phần bắt buộc trong khung chương trình của hầu hết sinh viên ngành Sư phạm Tin học. Hiện nay đã có khá nhiều tài liệu về môn học này. Tuy vậy phần lớn được trình bày dưới dạng sách chuyên khảo, do đó sinh viên rất khó khăn trong việc học môn này. Bên cạnh đó với các đặc thù của sinh viên ngành Sư phạm, nên việc học tập môn học mang nặng tính lý thuyết suông đối với sinh viên. Ngay từ đầu giáo trình, chúng tôi đưa ra mục tiêu và tóm tắt nội dung học phần mà khung chương trình đã quy định để làm rõ mục đích cần đạt được khi học môn học này của sinh viên Sư phạm Tin học so với sinh viên các ngành chuyên về Công nghệ phần mềm. Cuối các chương mục, chúng tôi đưa vào phần ôn tập chương cùng các câu hỏi và bài tập nhằm giúp sinh viên dễ học tập và có một cái nhìn rộng hơn về thực tiễn hay các vấn đề mở mà giáo trình chưa đề cập đến do giới hạn khuôn khổ. Do trong khung chương trình, phần quản lý dự án phần mềm được tách riêng thành một học phần gồm 2 tín chỉ, nên giáo trình sẽ không bao gồm phần này như thường thấy trong một số giáo trình khác. Giáo trình được chia thành 7 chương. Chương 1. Tổng quan về công nghệ phần mềm Chương 2. Qui trình phát triển phần mềm Chương 3. Phân tích và đặc tả yêu cầu Chương 4. Thiết kế Chương 5. Lập trình Chương 6. Kiểm thử Chương 7. Triển khai và bảo trì. 3
4. Trong quá trình biên soạn giáo trình này, chúng tôi có tham khảo một số tài liệu của một số tác giả khác nhằm mang lại những kiến thức phong phú, phù hợp nhất cho sinh viên, nhưng có thể chưa kịp liên hệ được với chính các tác giả ấy. Mong các Thầy, cô vì sự học của các sinh viên mà niệm tình bỏ quá. Tác giả chân thành cảm ơn các thầy cô Hà Viết Hải, Lê Văn Tường Lân, Nguyễn Thị Hoàng Anh đã góp ý cho bản thảo rất tận tình. Đồng thời xin chân thành cảm ơn quý Thầy cô khác cũng đã giúp đỡ chúng tôi rất nhiều. Chúng tôi cũng gửi lời cảm ơn đến rất nhiều bạn sinh viên đã giúp chúng tôi sưu tầm các tư liệu làm cơ sở để hoàn thành giáo trình này. Giáo trình không tránh khỏi những thiếu sót và đặc biệt là sự thiếu cập nhật thông tin đối với một môn học có tính thời sự công nghệ này. Rất mong sự góp ý, đánh giá, nhận xét của quý Thầy cô, Sinh viên để giáo trình được hoàn thiện hơn. Xin chân thành cảm ơn. Huế, Ngày 10 tháng 09 năm 2014 Nguyễn Thế Dũng Khoa Tin học – ĐHSP Huế. zungnguyen2003@yahoo.com 4
5. Dưới đây là trích dẫn mục tiêu và tóm tắt nội dung của học phần được khung chương trình đào tạo giáo viên Tin học Trung học phổ thông do Bộ Giáo dục và Đào tạo đưa ra năm 2007. Mục tiêu học phần NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Giúp cho sinh viên nắm được quá trình phát triển một phần mềm một cách hiệu quả, mang tính công nghiệp và hiểu được những khái niệm cơ bản thuộc lĩnh vực này. Trên cơ sở đó sinh viên có định hướng đúng đắn khi học tập nghiên cứu các môn khác cũng như đi sâu vào nghiên cứu và thực hành làm phần mềm. Tóm tắt nội dung học phần NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Nội dung môn học bao gồm: các quy trình xây dựng và đánh giá một phần mềm; vận dụng để xây dựng được những phần mềm cỡ nhỏ đáp ứng thực tế công việc và các đề án. 5
6. MỤC LỤC CHƢƠNG 1. TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM 9 1. Một số khái niệm 9 2. Nhân tố con người và phân loại nghề nghiệp trong công nghệ phần mềm. 15 3. Sản phẩm phần mềm – đặc trưng và phân loại 22 Chƣơng 2. QUI TRÌNH PHÁT TRIỂN PHẦN MỀM 28 1. Qui trình phát triển phần mềm 28 2. Mô hình phát triển phần mềm 34 3. Trợ giúp tự động hoá phát triển 46 Chƣơng 3. PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU 49 1. Đại cương về phân tích và đặc tả yêu cầu. 49 2. Phân tích và đặc tả yêu cầu 53 3. Nguyên lý phân tích và mô hình hóa 66 4. Đặc tả yêu cầu 74 5. Thẩm định yêu cầu 76 6. Làm bản mẫu trong quá trình phân tích 77 7. Định dạng đặc tả yêu cầu 79 8. Quản lý yêu cầu 82 9. Phân tích và đặc tả yêu cầu theo mô hình tiến trình hợp nhất (Unified Process Model). 84 Chƣơng 4. THIẾT KẾ 102 1. Khái niệm về thiết kế phần mềm 102 2. Thiết kế hướng chức năng 114 3. Thiết kế kiến trúc 118 4. Thiết kế giao diện người dùng 128 5. Thiết kế thủ tục 133 6. Thiết kế hướng đối tượng 135 Chƣơng 5. LẬP TRÌNH 151 1. Khái niệm 151 2. Ngôn ngữ lập trình 152 3. Phong cách lập trình 154 4. Kỹ thuật lập trình 156 5. Lập trình hướng hiệu quả thực hiện 158 Chƣơng 6. KIỂM THỬ 161 6
7. 1. Đại cương về kiểm thử phần mềm 161 2. Các mức độ kiểm thử 163 3. Các hoạt động kiểm thử 167 4. Kỹ thuật kiểm thử 169 5. Chiến thuật kiểm thử phần mềm 169 6. Kiểm thử hướng đối tượng 178 7. Chứng minh toán học tính đúng đắn của chương trình. 180 Chƣơng 7. TRIỂN KHAI VÀ BẢO TRÌ 189 1. Triển khai phần mềm 189 2. Hiện thực và triển khai phần mềm được xây dựng theo mô hình hướng đối tượng 193 3. Bảo trì 198 7
8. BẢNG THUẬT NGỮ Phần mềm Software 9 Phần cứng Hardware 9 Công nghệ phần Software 5 mềm Technology Kỹ nghệ phần Software 13 mềm Engineering CASE Computer- aided software engineering Đặc tả yêu cầu Software phần mềm Requirement Specification 8
9. CHƢƠNG 1. TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM Mục đích Trình bày các khái niệm thiết yếu của Công nghệ phần mềm như định nghĩa, đối tượng nghiên cứu, con người, sản phẩm Yêu cầu Biết được những khái niệm thiết yếu trong Công nghệ phần mềm. Biết được tổ chức nhân sự và vai trò của từng thành viên trong nhóm phát triển phần mềm. Biết được các loại tài liệu kỹ thuật. 1. Một số khái niệm Thuật ngữ phần mềm (software) cần được hiểu trong sự đối chiếu với thuật ngữ phần cứng (hardware) được đưa ra trong ngành điện tử. Theo đó phần cứng (hardware) là những thiết bị có thể sờ mó cầm nắm, trong khi đó phần mềm là những gì làm cho các thiết bị vô tri vô giác đó có thể hoạt động được. Phần mềm trong Tin học có thể được hiểu bao gồm: - Tập các lệnh máy tính nhằm thực hiện các chức năng xác định. - Các cấu trúc dữ liệu cho phép chương trình thao tác với dữ liệu. - Các tài liệu giúp cho người dùng có thể vận hành được phần mềm. 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. Theo nghĩa hẹp: Phần mềm là tập các chương trình dịch vụ để 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). Theo nghĩa rộng: Phần mềm 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. Nếu hiểu theo nghĩa rộng thì phần mềm bao gồm các nhóm minh họa như dưới đây: 9
10. 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ể hóa một hệ thống; Các phương pháp tiếp cận giải quyết vấn đề; Các trình tự thiết kế và phát triển được chuẩn hóa; 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 Đó là phần giao diện với phần cứng, tạo thành từ các nhóm lệnh chỉ thị cho máy tính biết trình tự thao tác xử lý dữ liệu. Phần mềm cơ bản: với chức năng cung cấp môi trường thao tác dễ dàng cho người sử dụng nhằm tăng hiệu năng xử lý của phần cứng (ví dụ như các hệ điều hành, các chương trình hệ thống). Phần mềm ứng dụng: dùng để xử lý nghiệp vụ thích hợp nào đó (quản lý, kế toán, . . .), phần mềm đóng gói, phần mềm của người dùng, Nhóm các tư liệu Đó là những tư liệu hữu ích, có giá trị cao cần thiết để phát triển, vận hành và bảo trì phần mềm. Để sản xuất ra phần mềm với độ tin cậy cao cần tạo ra các tư liệu chất lượng cao: đặc tả yêu cầu, mô tả thiết kế từng loại, điều kiện kiểm thử, thủ tục vận hành, hướng dẫn thao tác, Một số giáo trình về môn học này dùng các thuật ngữ có khác nhau về tên môn học này như Công nhệ phần mềm, Kỹ nghệ phần mềm, Công trình học phần 10
11. mềm Nên ở đây chúng ta cần xem xét một số vấn đề liên quan đến kiến thức chung là: Khoa học, công nghệ, kỹ nghệ và công nghiệp. Công nghiệp, là một bộ phận của nền kinh tế, là lĩnh vực sản xuất hàng hóa vật chất mà sản phẩm được "chế tạo, chế biến" cho nhu cầu tiêu dùng hoặc phục vụ hoạt động kinh doanh tiếp theo. Đây là hoạt động kinh tế, sản xuất quy mô lớn, được sự hỗ trợ thúc đẩy mạnh mẽ của các tiến bộ về công nghệ, khoa học và kỹ thuật. Một nghĩa rất phổ thông khác của từ “công nghiệp” là "hoạt động kinh tế quy mô lớn, sản phẩm (có thể là phi vật thể) tạo ra trở thành hàng hóa". Theo nghĩa này, những hoạt động kinh tế chuyên sâu khi đạt được một quy mô nhất định sẽ trở thành một ngành công nghiệp, ngành kinh tế như: công nghiệp phần mềm máy tính, công nghiệp điện ảnh, công nghiệp giải trí, công nghiệp thời trang, công nghiệp báo chí, v.v Công nghệ (tiếng Anh: technology) là sự tạo ra, sự biến đổi, việc sử dụng, và kiến thức về các công cụ, máy móc, kỹ thuật, kỹ năng nghề nghiệp, hệ thống, và phương pháp tổ chức, nhằm giải quyết một vấn đề, cải tiến một giải pháp đã tồn tại, đạt một mục đích, hay thực hiện một chức năng cụ thể. Công nghệ cũng có thể chỉ đến một tập hợp những công cụ như vậy, bao gồm máy móc, những sự sắp xếp, hay những quy trình. Công nghệ ảnh hưởng đáng kể lên khả năng kiểm soát và thích nghi của con người cũng như của những động vật khác vào môi trường tự nhiên của mình. Thuật ngữ có thể được dùng theo nghĩa chung hay cho những lĩnh vực cụ thể, ví dụ như "công nghệ xây dựng", "công nghệ thông tin". Trong tiếng Việt, các từ "khoa học", "kỹ thuật", và "công nghệ" đôi khi được dùng với nghĩa tương tự nhau hay được ghép lại với nhau (chẳng hạn "khoa học kỹ thuật", "khoa học công nghệ", và "kỹ thuật công nghệ"). Tuy vậy, công nghệ khác với khoa học và kỹ thuật. Khoa học là toàn bộ hoạt động có hệ thống nhằm xây dựng và tổ chức kiến thức dưới hình thức những lời giải thích và tiên đoán có thể kiểm tra được về vũ trụ. Còn kỹ thuật là việc ứng dụng kiến thức khoa học, kinh tế, xã hội, và thực tiễn để thiết kế, xây dựng, và duy trì các cấu trúc, máy móc, thiết bị, hệ thống, vật liệu, và quá trình. Công nghệ (có nguồn gốc từ technologia, hay τεχνολογια, trong tiếng Hy Lạp; techne có nghĩa là thủ công và logia có nghĩa là "châm ngôn") là một thuật 11
12. ngữ rộng ám chỉ đến các công cụ và mưu mẹo của con người. Tuỳ vào từng ngữ cảnh mà thuật ngữ công nghệ có thể được hiểu: + Công cụ hoặc máy móc giúp con người giải quyết các vấn đề; + Các kỹ thuật bao gồm các phương pháp, vật liệu, công cụ và các tiến trình để giải quyết một vấn đề; + Các sản phẩm được tạo ra phải hàng loạt và giống nhau. + Sản phẩm có chất lượng cao và giá thành hạ. Kỹ nghệ (engineering) nói tới một tập hợp các công nghệ được bố trí theo một qui trình nhất định, được con người dùng các phương pháp và thực hiện qua các công cụ để tạo ra những sản phẩm nhất định. Kỹ nghệ là việc sử dụng phối hợp các công nghệ cần thiết để sản xuất ra các sản phẩm của một ngành nào đó. Cần phân biệt công nghệ là nói đến những kỹ thuật được phát triển cho một loại vấn đề nào đó, còn kỹ nghệ nói đến các qui trình nghiêm ngặt phối hợp các công nghệ, phương pháp và công cụ để làm ra sản phẩm có chất lượng. Định nghĩa công nghệ do Uỷ ban Kinh tế và Xã hội khu vực Châu Á - Thái Bình Dương (ESCAP): Công nghệ là kiến thức có hệ thống về quy trình và kỹ thuật dùng để chế biến vật liệu và thông tin. Nó bao gồm kiến thức, thiết bị, phương pháp và các hệ thống dùng trong việc tạo ra hàng hoá và cung cấp dịch vụ. Mặc dù theo tiến trình phát triển, hiện nay khái niệm Kỹ nghệ phần mềm được dùng cho môn học. Nhưng do yếu tố lịch sử và khách quan của tên môn học trong khung chương trình chung của sinh viên, nên trong giáo trình này cụm từ Công nghệ phần mềm và Kỹ nghệ phần mềm được dùng với nghĩa tương tự nhau. Rất mong người đọc suy xét. Theo IEEE [1993]: Kỹ 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 hóa 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 được dùng trong (1) 12
13. Theo Pressman [2001]: Kỹ nghệ phần mềm 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. Theo Sommerville [2007]: Kỹ nghệ phần mềm 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. Như vậy có thể khái quát: Kỹ nghệ phần mềm (software engineering): là việc áp dụng các công cụ, các kỹ thuật một cách hệ thống trong việc phát triển các ứng dụng dựa trên máy tính. Đó chính là việc áp dụng các quan điểm, các tiến trình có kỷ luật và lượng hoá được, có bài bản và hệ thống để phát triển, vận hành và bảo trì phần mềm. Theo quan điểm của nhiều nhà nghiên cứu, có thể nhìn nhận kỹ nghệ phần mềm là một mô hình được phân theo bốn tầng mà tất cả các tầng này đều nhằm tới mục tiêu chất lượng, chi phí, thời hạn phát triển phần mềm. Công cụ Phương pháp Quy trình Chất lượng Ở đây, tầng chất lượng hướng đến việc đảm bảo chất lượng và kiểm thử phần mềm. Tầng quy trình liên quan tới vấn đề quản trị phát triển phần mềm như lập kế hoạch, quản trị chất lượng, tiến độ, chi phí, mua bán sản phẩm phụ, cấu hình phần mềm, quản trị sự thay đổi, quản trị nhân sự (trong môi trường làm việc nhóm), việc chuyển giao, đào tạo, tài liệu; Tầng phương pháp hay cách thức, công nghệ, kỹ thuật để làm phần mềm: liên quan đến tất cả các công đoạn phát triển hệ thống như nghiên cứu yêu cầu, thiết kế, lập trình, kiểm thử và bảo trì. Phương pháp dựa trên những nguyên lý cơ bản nhất cho tất cả các lĩnh vực công nghệ kể cả các hoạt động mô hình hoá và kỹ thuật mô tả. 13
14. Tầng công cụ liên quan đến việc cung cấp các phương tiện hỗ trợ tự động hay bán tự động cho các tầng quá trình và phương pháp (công nghệ). Kỹ sư phần mềm (software engineer): là một người biết cách áp dụng rộng rãi những kiến thức về cách phát triển ứng dụng vào việc tổ chức phát triển một cách có hệ thống các ứng dụng. Công việc của người kỹ sư phần mềm là: đánh giá, lựa chọn, sử dụng những cách tiếp cận có tính hệ thống, chuyên biệt, rõ ràng trong việc phát triển, đưa vào ứng dụng, bảo trì, và thay thế phần mềm. Do đặc điểm nghề nghiệp, người kỹ sư phần mềm phải có những kỹ năng cơ bản như: - Định danh, đánh giá, cài đặt, lựa chọn một phương pháp luận thích hợp và các công cụ CASE (Computer-aided software engineering). - Biết cách sử dụng các mẫu phần mềm (software prototyping). - Biết cách lựa chọn ngôn ngữ, phần cứng, phần mềm. - Quản lý cấu hình, lập sơ đồ và kiểm soát việc phát triển của các tiến trình. - Lựa chọn ngôn ngữ máy tính và phát triển chương trình máy tính. - Đánh giá và quyết định khi nào loại bỏ và nâng cấp các ứng dụng. Mục tiêu của kỹ sư phần mềm là sản xuất ra các sản phẩm có chất lượng cao và phù hợp với các quy trình phát triển chuẩn mực. Việc phát triển (development): được bắt đầu từ khi quyết định phát triển sản phẩm phần mềm và kết thúc khi sản phẩm phần mềm được chuyển giao cho người sử dụng. Việc sử dụng (operations): là việc xử lý, vận hành hằng ngày sản phẩm phần mềm. Việc bảo trì (maintenance): thực hiện những thay đổi mang tính logic đối với hệ thống và chương trình để sửa những lỗi cố định, cung cấp những thay đổi về công việc, hoặc làm cho phần mềm được hiệu quả hơn. Việc loại bỏ (retirement): thường là việc thay thế các ứng dụng hiện thời bởi các ứng dụng mới. Đối tƣợng nghiên cứu của công nghệ phần mềm 14
15. Hướng đến việc xây dựng các phần mềm có chất lượng như đã nêu, ngành công nghệ phần mềm đưa ra 3 đối tượng nghiên cứu chính: Qui trình công nghệ, Phương pháp phát triển, Công cụ và Môi trường phát triển phần mềm. - Qui trình công nghệ phần mềm: Hệ thống các giai đoạn mà quá trình phát triển phần mềm phải trải qua. Với mỗi giai đoạn cần xác định rõ mục tiêu, kết quả nhận từ giai đoạn trước đó cũng chính là kết quả chuyển giao cho giai đoạn kế tiếp. - Phương pháp phát triển phần mềm: Hệ thống các hướng dẫn cho phép từng bước thực hiện một giai đoạn nào đó trong qui trình công nghệ phần mềm. - Công cụ và môi trường phát triển phần mềm: Hệ thống các phần mềm trợ giúp chính trong lĩnh vực xây dựng phần mềm. Các phần mềm này sẽ hỗ trợ trong các bước xây dựng phần mềm theo một phương pháp nào đó với một qui trình được chọn trước. 2. Nhân tố con ngƣời và phân loại nghề nghiệp trong công nghệ phần mềm. 2.1. Nhân tố con ngƣời trong ngành công nghiệp phần mềm Đối với một sản phẩn phần mềm, một người không thể hoàn thành mà là kết quả lao động của một nhóm người, ta gọi là nhóm phát triển phần mềm. Như vậy, một nhóm phát triển phần mềm như thế nào gọi là một nhóm hợp lý? Sau đây là một vài yếu tố cần xem xét: - Nhóm có bao nhiêu thành viên, - Nhóm được tổ chức như thế nào, - Tình hình thực tế của mỗi thành viên trong nhóm, - Môi trường, điều kiện mà nhóm đang làm việc, Mỗi thành viên trong nhóm phải có một số kiến thức cần thiết tuỳ thuộc vào vai trò trong nhóm để phát triển phần mềm. 2.2. Phân loại nghề nghiệp Yêu cầu hiện nay của sự phát triển Công nghệ Thông tin (CNTT) ở Việt nam đòi hỏi cần có những người lao động trong tất cả các ngành kinh tế biết sử dụng hữu hiệu CNTT trong công việc của mình, và đồng thời cần có những người 15
16. trực tiếp tham gia vào sản xuất, kinh doanh, vận hành về CNTT. Do vậy cần có những lớp người lao động sau: Những người biết vận dụng sáng tạo CNTT vào nghiệp vụ chuyên môn. Những người tham gia quản lí và vận hành các hệ thống CNTT Những người tham gia trực tiếp vào việc phát triển và xây dựng ra các sản phẩm CNTT. Việc phân loại nghề nghiệp trong các hệ thống thông tin có thể được phân chia dựa vào các tiêu chuẩn như: mức độ kinh nghiệm, loại hình công việc, Loại hình công việc Ở đây, các loại hình công việc được bàn luận, dựa vào cách phân loại gồm: phát triển ứng dụng, hỗ trợ ứng dụng, chuyên ngành kỹ thuật, nhân viên và những vấn đề khác. a. Phát triển ứng dụng Lập trình viên: Các lập trình viên chuyển đổi những đồ án chi tiết kỹ thuật sang các module mã và tự kiểm tra các đơn vị. Các lập trình viên có thể luân phiên chịu trách nhiệm giữa phát triển ứng dụng và bảo trì. Những chuyên gia lập trình ở trình độ đại học thực hiện những nhiệm vụ bên ngoài việc lập trình. Kỹ sư phần mềm: Một kỹ sư phần mềm thực hiện những chức năng của các nhà phân tích, các nhà thiết kế và các lập trình viên. Các phân tích gia ở trình độ đại học luôn luôn tham gia vào tổ chức có cấp độ cao để lập kế hoạch và nghiên cứu khả thi. Các kỹ sư phần mềm có thể làm cả ba việc phân tích, thiết kế và lập trình cũng như đứng ra lãnh đạo dự án hoặc quản lý dự án. Một kỹ sư quản lý phần mềm sơ cấp thường dành nhiều thời gian lập trình trong khi một kỹ sư có trình độ cao cấp lại tập trung vào việc lập kế hoạch, nghiên cứu khả thi, phân tích và thiết kế. Phân tích viên hệ thống: Phân tích viên hệ thống đóng vai trò đặc biệt quan trọng trong tiến trình phân tích. Ngoài kinh nghiệm, một phân tích viên tốt cần có các khả năng sau: - Khả năng hiểu thấu các khái niệm trừu tượng, có khả năng tổ chức lại thành các phân tích logic và tổng hợp các giải pháp dựa trên từng dải phân chia. 16
17. - Khả năng rút ra các sự kiện thích đáng từ các nguồn xung khắc và lẫn lộn. - Khả năng hiểu được môi trường người dùng/khách hàng. - Khả năng áp dụng các phần tử hệ thống phần cứng và/hoặc phần mềm vào môi trường người sử dụng/khách hàng. - Khả năng giao tiếp tốt ở dạng viết và nói. - Khả năng trừu tượng hóa/tổng hợp vấn đề từ các sự kiện riêng lẻ. Kỹ sư tri thức (Knowledge Engineer): Các kỹ sư tri thức suy luận ra những mô hình ngữ nghĩa từ các chuyên gia để từ đó xây dựng những hệ chuyên gia và trí tuệ nhân tạo. Các kỹ sư tri thức tương tự như các kỹ sư phần mềm nhưng được chuyên môn hoá các kỹ năng để áp dụng vào các vấn đề trí tuệ nhân tạo. Việc phát triển các mô hình và các chương trình của cấu trúc trí tuệ đòi hỏi khả năng quan sát, kỹ năng phỏng vấn sâu sắc, khả năng trừu tượng hoá những vấn đề không phải của chuyên môn cá nhân để tạo ra những ý thức lập luận và thông tin cần thiết và khả năng phát triển những dự đoán về thông tin và tính chính xác với các chuyên gia. b. Hỗ trợ ứng dụng Chuyên gia ứng dụng: Chuyên gia ứng dụng có những vùng vấn đề được chuyên môn hoá cho phép họ tham khảo ý kiến của các đội dự án về một loại ứng dụng cụ thể. Ví dụ một nhà phân tích cao cấp về chuyển tiền thời gian thực có thể phân chia được thời gian giữa các dự án chuyển tiền trong nước và quốc tế, biết trước được những quy tắc, luật lệ phải tuân theo của ngân hàng dự trữ liên bang cũng như của các tổ chức chuyển tiền khác. Quản trị dữ liệu: Người quản lý dữ liệu quản lý thông tin như một nguồn thống nhất. Với chức năng này, bộ phận quản lý dữ liệu giúp cho người sử dụng xác định được tất cả dữ liệu được sử dụng, các dữ liệu có ý nghĩa trong quá trình thực hiện chức năng của công ty. Những người quản lý dữ liệu thiết lập và bảo lưu những chuẩn mực để thống nhất dữ liệu. Khi dữ liệu đã được xác định, người quản lý dữ liệu sẽ làm việc để định dạng và xác định cấu trúc cơ sở dữ liệu để sử dụng với ứng dụng. Với việc phát triển ứng dụng mới, những người quản lý dữ liệu làm việc với bộ phận phát triển ứng dụng để định vị những số liệu đã được tự động và với bộ phận quản trị CSDL 17
18. để cung cấp những nhóm ứng dụng dễ dàng truy nhập những cơ sở dữ liệu đã được tự động hoá. Quản trị cơ sở dữ liệu (DBA - DataBase Administrator): Những người quản lý cơ sở dữ liệu quản lý môi trường dữ liệu vật lý của một tổ chức. DBA phân tích, thiết kế, xây dựng và bảo lưu cơ sở dữ liệu cũng như môi trường phần mềm cơ sở dữ liệu. Làm việc cùng với những người quản lý dữ liệu xác định dữ liệu. DBA xác định các cơ sở dữ liệu vật lý và nạp thông tin thực tế vào chúng. Một người quản lý cơ sở dữ liệu làm việc với các nhóm phát triển ứng dụng để cung cấp truy nhập đến dữ liệu tự động và để định nghĩa rõ ràng cơ sở dữ liệu cần thiết cho thông tin được tự động. Kỹ sư trí tuệ nhân tạo: Các kỹ sư trí tuệ nhân tạo làm việc như cố vấn giúp các đội dự án xác định, thiết kế và cài đặt trí tuệ vào các ứng dụng. Kỹ sư trí tuệ nhân tạo cùng với các kỹ sư tri thức dịch và kiểm tra những vấn đề miền dữ liệu và thông tin lập luận bằng một ngôn ngữ của trí tuệ nhân tạo. Các kỹ sư trí tuệ nhân tạo đạt được trình độ chuyên môn cao hơn các kỹ sư tri thức. Nhà tư vấn: Người tư vấn thì biết mọi vấn đề và thực hành được tất cả. Số năm kinh nghiệm càng cao thì kiến thức có được càng nhiều. Lĩnh vực chuyên môn có thể bao gồm một vài loại công việc được đề cập đến trong phần này. Người tư vấn được nhờ đến trong hầu hết các trường hợp lắp đặt hệ thống và cung cấp những kỹ năng bên ngoài không sẵn có. Bởi vậy họ thường đào tạo đội ngũ bên trong trong suốt quá trình thực hiện công việc. Khi được nhờ đến, người tư vấn được mong chờ có những kỹ năng chuyên biệt và sẽ áp dụng những kỹ năng này trong việc thực hiện tư vấn. c. Chuyên ngành kỹ thuật Nhà phân tích và kỹ sư truyền thông: Các nhà phân tích và kỹ sư truyền thông phân tích, thiết kế, đàm phán và/hoặc cài đặt các thiết bị và phần mềm truyền thông. Họ đòi hỏi liên quan chặt chẽ tới kỹ thuật truyền thông và có thể làm việc trên mainframe hoặc các mạng truyền thông dựa vào máy tính cá nhân. Để bắt đầu ở mức xuất phát thì nền tảng kiến thức phải có là điện tử, kỹ thuật, các ứng dụng, khoa học máy tính và truyền thông. Chuyên gia về mạng cục bộ: Các chuyên gia mạng cục bộ đặt kế hoạch, lắp đặt, quản lý và duy trì những khả năng của mạng cục bộ. Điểm khác nhau duy 18
19. nhất giữa các chuyên gia mạng cục bộ và các chuyên gia truyền thông là phạm vi. Các chuyên gia truyền thông làm việc với nhiều mạng kể cả mainframe; còn chuyên gia mạng cục bộ chỉ làm việc trên những mạng có giới hạn về mặt địa lý và được cấu thành bởi nhiều máy tính cá nhân. Một người quản lý mạng cục bộ tạo ra người sử dụng mới, thực hiện hoặc thay đổi mức hoặc mã bảo mật, cài đặt những version mới của phần mềm điều hành mạng cục bộ, cài đặt những version mới của cơ sở dữ liệu hoặc phần mềm cơ sở mạng cục bộ khác. Giám sát tài nguyên cung cấp qua mạng cục bộ, cung cấp bản sao và khả năng phục hồi cho mạng cục bộ, và quản lý cấu hình mạng cục bộ. Lập trình viên hệ thống: Các lập trình viên hệ thống cài đặt và bảo dưỡng hệ điều hành và ứng dụng hỗ trợ phần mềm. Định giá những đặc điểm mới và xem xét chúng có cần thiết ở một thời điểm nào đó không là một kỹ năng mà lập trình viên hệ thống cần phát triển. Giám sát hàng trăm ứng dụng để xem xét những rắc rối của nó có liên quan đến vấn đề của hệ thống hay không là một nhiệm vụ quan trọng. Chuyên gia hỗ trợ phần mềm (SSP – Sofware Support): Hỗ trợ phần mềm ứng dụng tương tự nhưng khác với lập trình viên hệ thống. SSP cài đặt và bảo dưỡng gói phần mềm sử dụng bởi cả các nhà phát triển ứng dụng và người sử dụng. Chúng có thể là cơ sở dữ liệu, ngôn ngữ hỏi đáp, sao lưu và phục hồi, bảng tính, quản lý khoảng trống đĩa, giao diện, truyền thông. d. Nhân viên Chuyên gia về bảo mật: Một chuyên gia bảo mật chịu trách nhiệm bảo mật và sẵn sàng phục hồi thảm hoạ. Để bảo mật, một chuyên gia phải thiết lập các chuẩn cho bảo mật dữ liệu, giúp đỡ các đội dự án trong việc quyết định các yêu cầu bảo mật và thiết lập các chuẩn cho trung tâm bảo mật dữ liệu. Tương tự để phục hồi thảm hoạ, chuyên gia bảo mật giúp đỡ những người quản lý và các đội dự án trong việc xác định các dữ liệu nguy cấp cần thiết cho tổ chức. Sau đó chuyên gia giúp trung tâm dữ liệu và các đội dự án trong việc phát triển và thử nghiệm các kế hoạch phục hồi thảm hoạ. Kiểm soát viên: Các kiểm soát viên thực hiện việc kiểm tra khả năng tin cậy của những thiết kế ứng dụng. Bất kỳ ứng dụng nào duy trì những quy định hợp 19
20. pháp, trách nhiệm hoặc dùng bản hướng dẫn của công ty cũng có thể bị tạo lại bất kỳ giao dịch nào và phát hiện ra tiến trình của nó. Các kiểm soát viên đảm bảo rằng những mất mát của công ty là nhỏ nhất qua việc thiết kế những ứng dụng tốt. Những khía cạnh thiết kế được các kiểm soát viên đánh giá là rãnh kiểm soát, khả năng phục hồi và bảo mật. Đào tạo: Một người đào tạo kỹ thuật học công nghệ mới, các sản phẩm đại lý, những đặc điểm ngôn ngữ mới, sau đó dạy những người khác trong tổ chức sử dụng. Đào tạo có thể thực hiện trong nội bộ tổ chức những cũng có thể do một công ty đào tạo có chuyên môn đảm nhận. Người viết các chuẩn và kỹ thuật: Những người phát triển chuẩn làm việc với những người quản lý để định ra những mặt công việc họ muốn chuẩn hoá và để tiêu chuẩn hoá những yêu cầu thành những chính sách và thủ tục chuẩn hoá cho tổ chức. Những kỹ năng quan trọng nhất đối với người phát triển chuẩn là ngôn ngữ và chữ viết truyền thông. Phát triển tiêu chuẩn và việc viết kỹ thuật là các hoạt động có liên quan với nhau. Người viết kỹ thuật lấy thông tin và sản phẩm phần mềm, ứng dụng hoặc những sản phẩm công nghệ thông tin khác và viết tài liệu để mô tả những đặc điểm, chức năng, công dụng của chúng. Người viết kỹ thuật phải có kỹ năng giao tiếp tốt trong cả lĩnh vực kỹ thuật và phi kỹ thuật. Người viết dùng các kỹ năng giao tiếp kỹ thuật để nói và phát triển sự hiểu biết về sản phẩm được giới thiệu. Đảm bảo chất lượng (QA): Các dạng kiểm tra khác nhau tuỳ thuộc vào sản phẩm được duyệt. Một phân tích đảm bảo chất lượng thường được thực hiện với một kế hoạch phát triển khi nó bắt đầu. Anh ta hay cô ta cần phải tham gia đến khi sản phẩm đầu tiên của nhóm phát triển xuất hiện. Sau đó khi mà tài liệu đã có, người phân tích đảm bảo chất lượng phải xem xét sự thống nhất, hoàn thiện, chính xác uyển chuyển linh động của nó. Bất cứ vấn đề nào xuất hiện trong quá trình xem xét phải được ghi lại để trình lên người quản lý dự án. Những người phân tích đảm bảo chất lượng phải có kỹ năng giao tiếp, kỹ năng giải quyết vấn đề để thực hiện công việc kiểm tra chất lượng. Họ cần phải có kinh nghiệm trong tất cả các khía cạnh phát triển của dự án để biết nên làm cái gì và vấn đề nảy sinh từ đâu. Đồng thời sự nhạy cảm và khả năng phát hiện ra những vấn đề cần phê bình cũng rất quan trọng. Không ai muốn bị nói trước công chúng 20
21. là mình có lỗi mặc dù về mặt lý trí họ đều biết rằng công việc dự án sẽ có lợi từ những phê bình đó. Nhân viên đảm bảo chất lượng cần phải nhạy cảm với cả những chính sách và vấn đề được phát hiện. Lập kế hoạch công nghệ: Các chuyên gia giám sát sự phát triển công nghệ xác định các xu hướng, lựa chọn các công nghệ thích hợp để thử nghiệm trong tổ chức và cuối cùng chạy đua trong thực hiện các kỹ thuật mới trong tổ chức. Những nhân viên cao cấp là cầu nối giữa thế giới bên ngoài và cộng đồng các đại lý với công ty. Đội ngũ nhân viên sơ cấp có thể làm việc với nhân viên cao cấp để tìm ra những chỉ dẫn trong hợp tác và quản lý công nghệ. e. Những vấn đề khác Hỗ trợ sản phẩm: Nhân viên hỗ trợ sản phẩm làm việc cho nhóm người dùng cuối hoặc bán hàng để cung cấp những chuyên môn kỹ thuật liên quan đến sản phẩm hoặc những hỗ trợ trên đường dây nóng khác. Ngoài những kiến thức kỹ thuật về sản phẩm, các cá nhân trong công việc này còn phải có kỹ năng trả lời điện thoại tốt và phải nói bằng ngôn ngữ không chuyên đối với người sử dụng về các vấn đề. Tiếp thị sản phẩm: Nhân viên hỗ trợ tiếp thị làm việc cho nhà bán hàng để cung cấp những thông tin kỹ thuật cho đại diện bán hàng trong các tình huống tiếp thị. Loại công việc này đòi hỏi khả năng giao tiếp và kỹ năng giao tiếp tốt với một vài kiến thức về tiếp thị, chẳng hạn như thu hẹp phạm vi giao tiếp, đề cập đến các kỹ thuật để giới thiệu một cách hiệu quả với người đại diện bán hàng. Tất cả các công ty tư vấn và phần cứng, phần mềm đều có người để làm những công việc này. Thông thường nó được các nhân viên cao cấp thực hiện nhưng nếu bạn có trình độ chuyên môn ở những lĩnh vực cần thiết thì bạn cũng có thể làm được mà không cần là nhân viên cao cấp. Chuyên gia người sử dụng cuối: Chuyên gia người dùng cuối là người chuyển những yêu cầu sử dụng thành những ngôn ngữ kỹ thuật cho nhóm phát triển sử dụng. Trong một vài tổ chức, đây là chức năng của người phân tích hệ thống hoặc là kỹ sư phần mềm. Ở các công ty khác, có những môi giới giữa người sử dụng cuối với bộ phận sử dụng để thực hiện chức năng này. Tóm lại mọi công ty đều phải có sự kết hợp của những đặc điểm công việc khác nhau ở tất cả các bộ phận. 21
22. Có thể liệt kê các thành viên quan trọng của nhóm phần mềm. 1. Lập trình viên 2. Kỹ sư phần mềm (phân tích thiết kế) 3. Kỹ sư tri thức 4. Chuyên gia ứng dụng 5. Quản lý dữ liệu 6. Quản lý cơ sở dữ liệu 7. Kỹ sư trí tuệ nhân tạo 8. Chuyên viên tư vấn 9. Phân tích thông tin 10. Kỹ sư thông tin 11. Chuyên viên mạng 12. Lập trình viên hệ thống 13. Chuyên viên hỗ trợ phần mềm 14. Bảo mật 15. Kiểm soát 16. Huấn luyện 17. Tiêu chuẩn 18. Kế hoạch kỹ thuật 19. Hỗ trợ sản phẩm 20. Tiếp thị sản phẩm 21. Chuyên viên người dùng Khi nghiên cứu một công nghệ để sản xuất một sản phầm, chúng ta cần chỉ ra các đặc trưng của sản phẩm đó, vì đặc trưng của sản phầm sẽ có ảnh hưởng rất lớn đến qui trình công nghệ. 3. Sản phẩm phần mềm – đặc trƣng và phân loại 3.1. Đặc trƣng của phần mềm 22
23. Chúng ta có thể thấy khó khăn hàng đầu của việc phát triển phần mềm là do phần mềm là một hệ thống logic. Do đó nó có đặc trưng khác biệt đáng kể so với các đặc trưng của phần cứng. Dưới đây là các đặc trưng chính tạo ra sự phức tạp trong quá trình phát triển cũng như sử dụng, bảo trì phần mềm. a. Phần mềm không được chế tạo theo nghĩa cổ điển Phần mềm cũng được thiết kế, phát triển như phần cứng, nhưng nó không được định hình trước. Chỉ khi phát triển xong người ta có sản phẩm cụ thể và hiểu được nó có hiệu quả hay không. Tức là ở các bước trung gian, chúng ta rất khó kiểm soát chất lượng của phần mềm. Giá thành của phần cứng chủ yếu bị chi phối bởi giá thành nguyên vật liệu và chúng ta tương đối dễ kiểm soát. Trong khi đó, giá thành phần mềm chủ yếu tập chung vào chi phí nhân công. Quá trình phát triển phần mềm phụ thuộc vào con người (hiểu biết, khả năng vận dụng, kinh nghiệm và cách thức quản lý) và được tiến hành phát triển trong điều kiện môi trường (kỹ thuật, xã hội) đa dạng và không ngừng thay đổi. Do đó chúng ta rất khó ước lượng được chi phí cũng như hiệu quả của phần mềm. 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). Chúng có thể sao chép dễ dàng. b. Phần mềm không hỏng đi nhưng thoái hóa theo thời gian Chất lượng phần mềm không suy giảm đi mà có xu hướng tốt lên sau mỗi lần có lỗi được phát hiện và sửa chữa. Phần mềm không cảm ứng đối với những tác động của môi trường vốn gây cho phần cứng bị mòn cũ đi, nhưng nó cũng thoái hóa theo thời gian. Thực tế, phần mềm trải qua thời gian sử dụng cần phải được thay đổi (bảo trì) để đáp ứng nhu cầu luôn thay đổi của tổ chức sử dụng nó. Mỗi khi thay đổi, sẽ xuất hiện thêm một số khiếm khuyết mới không thể tránh làm cho số lỗi tiềm ẩn trong phần mềm tăng lên. Dần dần, phần mềm bị thoái hóa do tỷ lệ sai hỏng ngày càng tăng lên đến mức gây ra những thiệt hại không thể chấp nhận được. Việc bảo trì phần mềm phức tạp hơn nhiều và có bản chất khác hẳn so với bảo trì phần cứng do sự phức tạp của hệ thống phần mềm và sự không có sẵn phần 23
24. thay thế cho bộ phận bị lỗi. Chúng ta không thay thế bộ phận bị lỗi bằng cái có sẵn mà thực tế phải tạo ra một module mới. Do đó, thông thường chỉ có nhà sản xuất phần mềm mới bảo trì (sửa chữa) được hỏng hóc. Sẽ rất khó ước lượng được chi phí cho bảo trì phần mềm. 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. Lỗi của phần mềm dễ được phát hiện bởi người ngoài. c. Phần lớn phần mềm đều được xây dựng từ đầu, ít khi được lắp ráp từ thành phần có sẵn • Phần mềm không có danh mục các thành phần cố định như phần cứng. • Phần mềm thường được đặt hàng theo một đơn vị hoàn chỉnh, theo yêu cầu riêng của khách hàng. • Phần mềm ít khi có thể lắp ráp theo một khuôn mẫu có sẵn. Yêu cầu với phần mềm thay đổi theo môi trường cụ thể mà ở đó nó được xây dựng. Môi trường của phần mềm (gồm phần cứng, phần mềm nền, con người và tổ chức) không thể định dạng từ trước và lại thay đổi thường xuyên. Những yếu tố này dẫn đến chi phí cho phần mềm cao và rất khó đảm bảo được lịch biểu cho phát triển phần mềm. d. Phần mềm là phức tạp, khó hiểu, vô hình Phần mềm là hệ thống logic khó hiểu,chứa nhiều khái niệm khác nhau, khó hiểu. Mối liên kết trong phần mềm mang tính logic, để hiểu nó cần phải tư duy trừu tượng. Phần mềm có tính không nhìn thấy, vì nó không phải vật thể vật lý. Mỗi biểu diễn chỉ một khía cạnh (dữ liệu, hành vi, cấu trúc, giao diện), mà không phải là một hệ thống tổng thể. e. Sự thay đổi là bản chất của phần mềm Phần mềm là mô hình thế giới thực thay đổi theo thời gian do môi trường nghiệp vụ thay đổi, do nhu cầu con người thay đổi. Phần mềm phải thay đổi thích ứng với môi trường vận hành, do các hệ phần mềm nền (hệ điều hành, ), thiết bị phần cứng thay đổi. Có thể phân loại phần mềm theo chức năng như sau: 24
25. + Phần mềm hệ thống và trợ giúp tiện ích (hệ điều hành, driver; BIOS, Network Operating system, communications protocol, messaging protocol, hệ quản trị cơ cở dữ liệu, ngôn ngữ lập trình, ) + Phần mềm ứng dụng (phần mềm văn phòng, phần mềm nghiệp vụ, Real- time software, Business software, Engineering/scientific software, Embedded software, PC software, AI software, WebApps (Web applications)). Trong phần mềm ứng dụng có thể chia thành 2 nhóm sau: Sản phẩm đặt hàng – Sản xuất theo đơn đặt hàng (hệ thống thông tin quản lý ) – Sản xuất đơn chiếc với yêu cầu đặc thù (nhận dạng) Sản phẩm chung (software pakages) – bán rộng rãi – thỏa mãn yêu cầu chung số lớn người dùng. +. Phần mềm công cụ (Tools, CASE): Nhằm trợ giúp cho quá trình phát triển phần mềm như các ngôn ngữ lập trình (soạn thảo, dịch, gỡ rối, ), các công cụ trợ giúp một hay nhiều giai đoạn phát triển (phân tích, thiết kế, quản lý dự án, kiểm thử, ). + Phần mềm khoa học kỹ thuật, phần mềm nhúng, phần mềm máy tính cá nhân, phần mềm trí tuệ nhân tạo, phần mềm dựa trên nền Web 3.2. Những khó khăn trong sản xuất phần mềm (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. (2) Với những phầnmềm quy mô lớn, tư liệu đặc tả đã cố định trong 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. (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), sẽ dẫn đến sự 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, dẫn đến những đặc tả không rõ ràng sẽ làm giảm chất lượng phần mềm. 25
26. (5) Việc kiểm thử phải được diễn ra thường xuyên qua các giai đoạn phát triển phần mềm chứ không chỉ xảy ra trong giai đoạn cuối. (6) Việc xem nhẹ khâu thiết kế thường dẫn đến làm giảm chất lượng phần mềm. (7) Việc xem thường việc tái sử dụng phần mềm (software reuse), dẫn đến năng suất lao động của nhóm làm phần mềm giảm. (8) Sự tự động hóa trong công nghệ phần mềm chưa cao. (9) Việc chứng minh tính đúng đắn của phần mềm là khó khăn, do vậy độ tin cậy của phần mềm cũng giảm đi. (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) Đầ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) Việc 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, làm kéo dài thời hạn và vượt kinh phí của dự án. Trên đây là những vấn đề phản ánh các khía cạnh khó khăn trong việc sản xuất phần mềm, do vậy cần nghiên cứu các quy trình công nghệ để tạo ra những phần mềm tốt. TỔNG KẾT Chúng ta đã bước đầu tìm hiểu các khái niệm cơ bản như định nghĩa, đối tượng nghiên cứu của Công nghệ phần mềm, nhằm định hướng những điều cốt lõi của môn học Các vấn đề về sản phẩm phần mềm, nhằm nêu lên những đặc trưng của sản phẩm có ảnh hưởng như thế nào tới qui trình công nghệ để sản xuất sản phẩm ấy. Các chức năng, chuyên môn, kiến thức cần có của các con người có vai trò khác nhau trong Công nghệ phần mềm cũng được đưa ra giúp các bạn sinh 26
27. viên ngành Sư phạm Tin học định hướng nghề nghiệp cho học sinh khi giảng dạy ở trường Phổ thông. Câu hỏi và bài tập 1. Định nghĩa phần mềm? 2. Tầm quan trọng của phần mềm? (mức độ: hệ thống, cá nhân, tổ chức, quốc gia, ứng dụng)? 3. Các đặc trưng của phần mềm và giải thích? 4. Các loại phần mềm? Giải thích nội dung mỗi loại? 5. Phân biệt chương trình và sản phẩm? 6. Tiến hóa phần mềm tương ứng với công nghệ, nhu cầu? 7. Khó khăn phát triển phần mềm (bản chất, sự thay đổi môi trường kỹ thuật, nghiệp vụ, xã hội)? 8. Thách thức đối với phát triển phần mềm? (nhu cầu, bảo trì, thời gian, giá cả, khả năng phần cứng) 9. Phân biệt khoa học máy tính với Công nghệ Phần mềm? 10. Phân biệt Công nghệ Hệ thống với Công nghệ Phần mềm? 11. Tìm hiểu thêm trên Internet để biết khi xây dựng một sản phẩm phần mềm phải đầu tư những chi phí nào ? 12. Định nghĩa kỹ nghệ phần mềm – SE theo một trích dẫn nào đó và cho ý nghĩa của định nghĩa khi xác định các vấn đề cần quan tâm của kỹ nghệ phần mềm? 13. Tìm hiểu thêm trên Internet về các giai đoạn lịch sử phát triển của SE? đặc trưng của mỗi giai đoạn (sản phẩm, phương pháp, công cụ, quản lý và tổ chức làm việc)? 14. Giải thích nội dung các yếu tố cơ bản trong SE? Lấy ví dụ minh hoạ về phương pháp, công cụ? 27
28. Chƣơng 2. QUI TRÌNH PHÁT TRIỂN PHẦN MỀM Mục đích Giới thiệu một số mô hình phát triển phần mềm thường được ứng dụng với những đặc điểm riêng. Yêu cầu • Hiểu rõ quy trình phần mềm. • Nắm được một số mô hình phát triển phần mềm. • Xác định những công việc phải làm trong quy trình phát triển phần mềm và cách thực hiện chúng. • Đặc điểm của mỗi mô hình phát triển phần mềm. 1. Qui trình phát triển phần mềm 1.1. Vòng đời phát triển hệ thống (Systems Development Life Cycle – SDLC) Mỗi vòng đời hệ thống có 4 giai đoạn, mỗi giai đoạn bao gồm một tập các bước và cần được tài liệu hóa. Các giai đoạn có thể được thực hiện một cách tuần tự, tăng trưởng dần, lặp hay theo một số cách khác. Đối với mỗi giai đoạn, các câu hỏi sau cần trả lời để đề ra các hoạt động cho từng giai đoạn. 28
29. Ở giai đoạn vạch kế hoạch: Tại sao chúng ta xây dựng hệ thống này? Nó sẽ mang lại những lợi ích gì? Cần bao lâu để xây dựng nó? Ở giai đoạn phân tích: Ai sẽ dùng nó? Nó làm được những gì cho ta? Ở đâu và khi nào nó sẽ được sử dụng? Ở giai đoạn thiết kế: Chúng ta sẽ xây dựng nó như thế nào? Các hoạt động chính của từng giai đoạn là: Giai đoạn vạch kế hoạch a. Khởi tạo dự án Ở hoạt động này chúng ta cần phát triển/tiếp nhận các yêu cầu về hệ thống, do đó dẫn đến một sự phân tích về tính khả thi, gồm: khả thi về kỹ thuật; khả thi về kinh tế; khả thi về tổ chức. b. Quản lý dự án Ở hoạt động này, chúng ta cần xây dựng một kế hoạch làm việc; tập hợp nhân sự cho dự án; kiểm soát và điều khiển dự án. Tóm lại giai đoạn này chúng ta cần trả lời câu hỏi: Tại sao chúng ta phải thực hiện dự án? Giai đoạn phân tích Bao gồm: a. Phát triển một chiến lược phân tích Nhằm mô hình hóa hệ thống hiện tại; xác lập hệ thống mới. b. Thu thập yêu cầu Nhằm phát triển một hệ thống lôgic; tạo một mô hình nghiệp vụ để trình bày: Dữ liệu nghiệp vụ; Các tiến trình xử lý nghiệp vụ c. Phát triển một hệ thống yêu cầu Giai đoạn này nhằm trả lời câu hỏi: Cái gì hệ thống sẽ làm cho ta? Ở đâu và khi nào hệ thống sẽ được dùng? Giai đoạn thiết kế Bao gồm: 29
30. a. Phát triển một chiến lược thiết kế b. Thiết kế kiến trúc và giao diện c. Phát triển cơ sở dữ liệu và các đặc tả file d. Phát triển thiết kế chương trình để xác định: Chương trình nào phải viết? Mỗi chương trình sẽ làm gì? Giai đoạn triển khai Bao gồm: a. Tiến hành xây dựng hệ thống: + Tạo dựng hệ thống (viết mã) + Kiểm tra thử nghiệm b. Cài đặt hệ thống và triển khai một kế hoạch tập huấn cho người sử dụng. c. Xác lập kế hoạch hỗ trợ hệ thống (bảo trì) Mỗi giai đoạn bao gồm một số bước tạo ra các sản phẩm cụ thể. Sản phẩm của giai đoạn này là đầu vào của các giai đoạn sau. Hệ thống tiến hóa thông qua sự tinh chỉnh dần. Hình 2.1. Các giai đoạn và các sản phẩm cơ bản của từng giai đoạn tƣơng ứng 1.2. Qui trình phát triển phần mềm. 30
31. Cũng như mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án. Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao, cũng như đồng bộ hóa hoạt động trong dự án. Điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm củng cố và phát triển cùng với nền công nghiệp phần mềm đầy tính cạnh tranh. Quy trình phát triển phần mềm (quy trình/tiến trình phần mềm) là một tập hợp các hoạt động được tổ chức và cần phải thực hiện trong quá trình xây dựng một hệ thống phần mềm. Quy trình phát triển phần mềm gồm 4 hoạt động cơ bản: + Đặc tả yêu cầu: chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng. + Phát triển phần mềm: tạo ra phần mềm thỏa mãn các yêu cầu được chỉ ra trong “Đặc tả yêu cầu”. + Kiểm thử phần mềm: để bảo đảm phần mềm sản xuất ra đáp ứng những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”. + Thay đổi phần mềm: đáp ứng nhu cầu thay đổi của khách hàng. Ở đây, đặc tả là quá trình xác định những dịch vụ được yêu cầu, những ràng buộc trong phát triển và hoạt động của hệ thống. Phần chính yếu là xác định yêu cầu. Qui trình kỹ nghệ yêu cầu gồm: Nghiên cứu khả thi; Phân tích yêu cầu; Đặc tả yêu cầu; Đánh giá yêu cầu. Hoạt động thiết kế và cài đặt là quá trình chuyển những đặc tả hệ thống thành một hệ thống thực thi. Thiết kế nhằm hiện thực những đặc tả thành những cấu trúc phần mềm. Cài đặt nhằm chuyển cấu trúc thành chương trình thực thi. Thiết kế bao gồm: Đặc tả trừu tượng; Thiết kế đối tượng dữ liệu; Thiết kế hệ 31
32. thống; Thiết kế kiến trúc; Thiết kế giao diện; Thiết kế thành phần; Thiết kế cấu trúc dữ liệu; Thiết kế giải thuật Lập trình là giai đoạn chuyển thiết kế thành chương trình, bắt lỗi và sửa lỗi, đây là một hoạt động cá nhân không có một tiến trình chung cho mọi người. Người lập trình phải tiến hành kiểm thử để gỡ lỗi chương trình. Gỡ lỗi là hoạt động của lập trình. Lập trình đòi hỏi chọn ngôn ngữ thích hợp và có kinh nghiệm, phong cách lập trình tốt. Để đảm bảo độ tin cậy, cần biết lập trình tránh lỗi, thứ lỗi và ném ngoại lệ. Đánh giá phần mềm hay còn gọi là kiểm chứng và thẩm định được sử dụng để chỉ ra rằng hệ thống đã thực hiện theo đúng các đặc tả và thoả mãn mọi yêu cầu của khách hàng hay không? Để đánh giá cần phải kiểm thử hệ thống. Cải tiến phần mềm nhằm duy trì và cải tiến hệ thống theo những biến đổi về yêu cầu. Phần mềm phải mềm dẻo vì nó cần phải thay đổi. Môi trường nghiệp vụ và kỹ thuật luôn thay đổi, vì vậy phần mềm cần thay đổi để phù hợp với chúng, do đó tiến hóa là tất yếu. Việc phân định phát triển và tiến hoá là tương đối; giữa chúng có quan hệ chặt chẽ với nhau. Phát triển là làm mới, tiến hóa trên cơ sở hệ thống đã có. 1.3. Ba giai đoạn chính của quy trình phát triển phần mềm. Tiến trình phát triển kỹ nghệ phần mềm chứa ba giai đoạn chính, bất kể mô hình kỹ nghệ phần mềm được chọn lựa. Ba giai đoạn này là xác định, phát triển và bảo trì, được gặp trong mọi dự án phát triển phần mềm, bất kể tới miền ứng dụng, kích cỡ và độ phức tạp. Giai đoạn xác định tập trung vào khái niệm “cái gì”. Tức là trong khi xác định, người phát triển phần mềm cố gắng tập trung vào xác định thông tin nào cần được xử lý, chức năng và hiệu năng nào là cần có, giao diện nào cần được thiết lập, ràng buộc thiết kế nào hiện có và tiêu chuẩn hợp lệ nào cần có để xác định ra một hệ thống thành công. Yêu cầu chủ chốt của hệ thống và phần mềm cũng được xác định. Mặc dầu các phương pháp được áp dụng trong giai đoạn xác định thay đổi tùy theo mô hình kỹ nghệ phần mềm (hay tổ hợp các mô hình) được áp dụng, có ba bước riêng: 32
33. 1. Phân tích hệ thống: Phân tích hệ thống xác định ra vai trò của từng phần tử trong một hệ thống dựa trên máy tính, tức là vạch ra vai trò mà phần mềm (cần phát triển) sẽ giữ. 2. Lập kế hoạch dự án phần mềm: Một khi vai trò của phần mềm đã được thiết lập, rủi ro đã được phân tích, tài nguyên đã được cấp phát, chi phí đã được ước lượng thì phải xác định cụ thể các công việc cần thực hiện và lập lịch thực hiện chúng. 3. Phân tích yêu cầu: Trong bước phân tích hệ thống chúng ta chỉ xác định được vai trò chung của phần mềm. Sau khi đã chính thức quyết đinh phát triển phần mềm, chúng ta cần phải phân tích để xác định chi tiết lĩnh vực thông tin, các chức năng cũng như các ràng buộc khi vận hành của phần mềm. Phân tích yêu cầu là khâu kỹ thuật quan trọng đầu tiên để đảm bảo chất lượng của phần mềm. Nếu xác định sai yêu cầu thì các bước kỹ thuật khác có tốt đến đâu thì phần mềm cũng sẽ không được đưa vào sử dụng. Qui trình kỹ nghệ yêu cầu gồm: Nghiên cứu khả thi (Feasibility study); Phân tích yêu cầu; Đặc tả yêu cầu (specification); Đánh giá yêu cầu. Giai đoạn phát triển tập trung vào khái niệm thế nào. Tức là, trong giai đoạn này người phát triển phần mềm từng bước xác định cách cấu trúc dữ liệu và kiến trúc phần mềm cần xây dựng, cách các chi tiết thủ tục được cài đặt, cách dịch thiết kế vào ngôn ngữ lập trình (hay ngôn ngữ phi thủ tục) và cách thực hiện kiểm thử. Phương pháp được áp dụng trong giai đoạn phát triển sẽ thay đổi tùy theo mô hình nhưng có ba bước đặc thù xuất hiện dưới dạng: 1. Thiết kế phần mềm: Là quá trình “dịch” các yêu cầu phần mềm thành một tập các biểu diễn (dựa trên đồ họa, bảng, hay ngôn ngữ), mô tả cho cấu trúc dữ liệu, kiến trúc, thủ tục thuật toán và đặc trưng giao diện. Thiết kế bao gồm: Đặc tả trừu tượng; Thiết kế đối tượng dữ liệu; Thiết kế hệ thống; Thiết kế kiến trúc (Architectural design); Thiết kế giao diện; Thiết kế thành phần; Thiết kế cấu trúc dữ liệu; Thiết kế giải thuật 2. Mã hóa: Các biểu diễn thiết kế phải được biểu diễn bởi một (hay một vài) ngôn ngữ nhân tạo (ngôn ngữ lập trình qui ước hay ngôn ngữ phi thủ tục được dùng trong khuôn cảnh công nghệ phần mềm thế hệ thứ tư - 4GT) mà sẽ tạo ra kết quả là các lệnh thực hiện được trên máy tính. 33
34. 3. Kiểm thử phần mềm: Một khi phần mềm đã được cài đặt dưới dạng máy thực hiện được, cần phải kiểm thử nó để phát hiện các lỗi phân tích, thiết kế, cài đặt và đánh giá tính hiệu quả. Giai đoạn bảo trì tập trung vào những thay đổi gắn với việc sửa lỗi, thích ứng khi môi trường phần mềm tiến hóa và sự nâng cao gây ra bởi sự thay đổi yêu cầu của người dùng. Giai đoạn bảo trì áp dụng lại các bước của giai đoạn xác định và phát triển, nhưng là việc thực hiện trong hoàn cảnh phần mềm hiện có. Có ba kiểu thay đổi gặp phải trong giai đoạn bảo trì: 1. Sửa đổi: Cho dù có các hoạt động bảo đảm chất lượng tốt nhất, vẫn có thể là khách hàng sẽ phát hiện ra khiếm khuyết trong phần mềm. Bảo trì sửa đổi làm thay đổi phần mềm để sửa các khiếm khuyết (lỗi lập trình, thuật toán, thiết kế ). 2. Thích nghi: Qua thời gian, môi trường ban đầu (như CPU, hệ điều hành, ngoại vi) để phát triển phần mềm có thể sẽ thay đổi. Bảo trì thích nghi thực hiện việc sửa đổi phần mềm để thích hợp với những thay đổi môi trường ngoài. 3. Nâng cao: Khi phần mềm được dùng, khách hàng/người dùng sẽ nhận ra những chức năng phụ sẽ có lợi. Bảo trì hoàn thiện mở rộng phần mềm ra ngoài các yêu cầu chức năng gốc của nó. 2. Mô hình phát triển phần mềm Mô hình phát triển phần mềm (mô hình tiến trình phát triển phần mềm) là sự trừu tượng tiến trình phát triển theo góc nhìn nào đó. Với một tiến trình có các góc nhìn sau: + Luồng công việc: trình tự các hoạt động của tiến trình phát triển. + Luồng dữ liệu: luồng các dữ liệu di chuyển khi phát triển hệ thống phần mềm. + Vai trò/hành động: hành vi của tác nhân đối với hệ thống phần mềm. Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng. Một số mô hình tiến trình phát triển phần mềm phổ biến: 34
35. Mô hình thác nước (Water Fall Model) Mô hình phát triển tiến hóa (Evolutionary development Model) Mô hình bản mẫu (Prototyping Model) Mô hình xoắn ốc (Spiral Model) Mô hình RAD (Rapid Application Development Model) Mô hình tăng trưởng (Incremental Model) Mô hình phát triển hệ thống hình thức (Formal systems development Model) Mô hình phát triển dựa trên sử dụng lại (Reuse-based development Model) Mô hình dựa trên kỹ nghệ thứ hệ thứ 4 (4 GT) Mô hình RUP (Rational Unified Process Model) Nhìn chung các mô hình tiến trình phát triển phần mềm đều có một khung làm việc như sau: - Khung tiến trình (Process framework) gồm: + Khung công việc (Framework activities) o Các tác vụ (work tasks) o Các sản phẩm (work products) o Các mốc thời điểm và phát hành sản phẩm (milestones & deliverables) o Các điểm kiểm tra chấp nhận sản phẩm (QA checkpoints) + Các hoạt động hỗ trợ (Umbrella Activities) - Các hoạt động trong khung công việc như: Hoạt động truyền thông; Lập kế hoạch; Mô hình hóa; Phân tích yêu cẩu; Thiết kế; Xây dựng; Sinh mã; Kiểm thử; Triển khai - Hoạt động hỗ trợ (umbrella activities) như: Điều khiển và lần vết dự án phần mềm; Quản lý rủi ro; Bảo đảm chất lượng phần mềm; Kiểm tra kỹ thuật hình thức; Đo lường; Quản lý cấu hình phần mềm; Quản lý sử dụng lại; Tạo và chuẩn bị những sản phẩm cộng tác. 35
36. Dưới đây là một số mô hình phát triển phần mềm tiêu biểu 2.1. Mô hình thác nƣớc (The waterfall model) Đôi lúc còn được gọi là mô hình cổ điển (classic model) hay mô hình tuyến tính (the linear sequential model). Mô hình này xem quá trình xây dựng một sản phẩm phần mềm bao gồm nhiều 5 giai đoạn tách biệt gồm: phân tích yêu cầu, thiết kế, cài đặt và kiểm thử đơn thể, tích hợp tổng thể và kiểm thử, bảo trì và phát triển, sau khi hoàn tất một giai đoạn thì chuyển đến giai đoạn sau. Mô hình này được tóm tắt như sau: Phân tích yêu cầu Thiết kế Cài đặt và thử nghiệm đơn thể Thử nghiệm và tích hợp tổng thể Bảo trì và phát triển Hình 2.2. Mô hình thác nƣớc Ưu điểm: Các pha được xác định rõ ràng (đầuvào/ra); Thấy được trình tự kỹ nghệ từ đầu đến sản phẩm cuối; Bảo trì thuận lợi; Thích hợp khi yêu cầu của sản phẩm là được hiểu tốt. 36
37. Nhược điểm: Mô hình này chỉ thích hợp khi các yêu cầu rõ ràng và những thay đổi được giới hạn. Tuy vậy, bản chất của phát triển phần mềm là quá trình lặp đi lặp lại chứ không phải tuần tự. Khách hàng không thể đặc tả tất cả yêu cầu một cách chính xác và đầy đủ ngay từ ban đầu. Do đó khó đáp ứng yêu cầu thay đổi của khách hàng và khi sai sót phát hiện muộn có thể là thảm họa cho dự án. Khách hàng thường phải chờ đợi rất lâu để thấy được phiên bản đầu tiên thực hiện được của sản phẩm, đòi hỏi khách hàng phải kiên nhẫn. Tồn tại sự chờ đợi giữa các đội phát triển trong nhóm làm việc. 2.2. Mô hình bản mẫu (Prototyping model) Thường thì khách hàng thường khó nói rõ được điều họ mong đợi và người phát triển thường hiểu sai yêu cầu của khách hàng. Khách hàng thường phát hiện sai sót khi dùng sản phẩm, vì vậy dẫn đến nhu cầu tạo nên môi trường để thu thập yêu cầu của khách hàng. Điều này là phù hợp với đặc trưng dùng lại của phần mềm. Mô hình bản mẫu dựa trên ý tưởng xây dựng một mẫu thử ban đầu (Prototype – nguyên mẫu) và đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thỏa mãn yêu cầu của người sử dụng thì dừng lại. Mẫu thử ban đầu như là một cơ chế để nhận diện chính xác yêu cầu của khách hàng và có thể trở thành sản phẩm. Khi các yêu cầu của người sử dụng được thỏa mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống. Mẫu thử ban đầu có thể loại bỏ, mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng. Cách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm là cách tiếp cận tốt nhất khi: - Mục tiêu tổng quát cho phần mềm đã xác định, nhưng chưa xác định được input và output. - Người phát triển không chắc về hiệu quả của thuật toán, về thích nghi hệ điều hành hay giao diện người máy cần có. Khi đã có bản mẫu, người phát triển có thể dùng chương trình đã có hay các công cụ phần mềm trợ giúp để sinh ra chương trình làm việc. 37
38. Làm bản mẫu là tạo ra một mô hình cho phần mềm cần xây dựng. Mô hình có thể có 3 dạng: 1. Bản mẫu trên giấy hay trên máy tính mô tả giao diện người-máy làm người dùng hiểu được cách các tương tác xuất hiện. 2. Bản mẫu cài đặt chỉ một tập con chức năng của phần mềm mong đợi. 3. Bản mẫu là một chương trình có thể thực hiện một phần hay tất cả chức năng mong muốn nhưng ở mức sơ lược và cần cải tiến thêm các tính năng khác tùy theo khả năng phát triển. Trước hết người phát triển và khách hàng gặp nhau và xác định mục tiêu tổng thể cho phần mềm, xác định các yêu cầu đã biết, các miền cần khảo sát thêm. Tiếp theo là giai đoạn thiết kế nhanh, tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng (input và output), và xây dựng một bản mẫu. Người dùng đánh giá và làm mịn các yêu cầu cho phần mềm. Tiến trình này lặp đi lặp lại cho đến khi bản mẫu thoả mãn yêu cầu của khách hàng, đồng thời giúp người phát triển hiểu kỹ hơn nhu cầu nào cần phải thực hiện Một biến thể của mô hình này là mô hình thăm dò, trong đó các yêu cầu được cập nhật liên tục và bản mẫu được tiến hóa liên tục để trở thành sản phẩm cuối cùng. Có thể tóm lược 6 bước làm bản mẫu như sau: + Khởi đầu bằng pha thu thập yêu cầu + Tiến hành thiết kế nhanh + Xây dựng bản mẫu + Đánh giá của khách hàng + Làm mịn bản mẫu + Nếu chưa được sản phẩm thì chuyển sang thiết kế nhanh và lặp lại. Mô hình làm bản mẫu có một số vấn đề như: - Do sự hoàn thiện dần (tiến hóa) của bản mẫu, phần mềm nhiều khi có tính cấu trúc không cao, dẫn đến khó kiểm soát, khó bảo trì. - Khách hàng nhiều khi thất vọng với việc phát triển phần mềm do họ nhầm tưởng bản mẫu là sản phẩm cuối cùng hướng tới người sử dụng. Khách 38
39. hàng hối thúc nhà phát triển hoàn thành sản phẩm một khi thấy được các prototype đầu tiên. Khách hàng cũng có thể không dành nhiều công sức vào đánh giá bản mẫu. - Thiếu tầm nhìn của cả quy trình. - Các hệ thống được cấu trúc một cách nghèo nàn. Những chọn lựa không tốt có thể được tích hợp trong hệ thống. - Yêu cầu kỹ năng đặc biệt (sử dụng công cụ CASE). Nên áp dụng mô hình này cho: • Những hệ thống tương tác ở mức độ nhỏ hoặc vừa. • Trên một phần của những hệ thống lớn hay những hệ thống có thời gian chu kỳ tồn tại ngắn. 2.3. Mô hình xoắn ốc (The spiral model) Mô hình này được Boehm đưa ra nên đôi lúc còn được gọi là mô hình Boehm's (The Boehm's spiral model). Nó có thể xem là sự kết hợp giữa mô hình thác nước (tính trình tự tốt nhưng rủi ro cao) và mô hình mẫu (loại trừ rủi ro nhưng trình tự không rõ ràng) và đồng thời thêm một thành phần mới - phân tích rủi ro. Bao gồm bốn hoạt động chính: Lập kế hoạch (Planning): Xác định mục tiêu, tương tác và ràng buộc. Phân tích rủi ro (Risk analysis): Phân tích các lựa chọn và các chỉ định/giải quyết rủi ro. Kỹ nghệ (Engineering): Phát triển sản phẩm Đánh giá của khách hàng (Customer evaluation): Đánh giá kết quả xây dựng từ phía khách hàng. Mô hình được tóm tắt như sau: 39
40. Kế hoạch Phân tích rũi ro Lập kế hoạch và thu Phân tích rủi ro trên thập yêu cầu ban cơ sở các yêu cầu ban đầu đầu Kế hoạch dựa trên Phân tích rũi ro trên các đánh giá của cơ sở các phản ứng khách hàng của kh hàng Hƣớng hoàn thiện của hệ thống Đánh giá Bản mẫu đầu tiên sản phẩm Tiếp tục phát Các bản mẫu tiếp theo triển hệ thống? Khách hàng đánh giá Xây dựng sản phẩm Hình 2.3. Mô hình xoắn ốc Trong vòng đầu tiên của xoáy ốc, mục đích, lựa chọn, các ràng buộc được định nghĩa và các nguy cơ được xác định và phân tích. Nếu phân tích các lỗi chỉ ra rằng có một vài yêu cầu không chắc chắn, tạo mẫu có thể dược tiến hành để giúp đỡ nhà phát triển và khách hàng. Mô phỏng và các mô hình khác có thể được sử dụng để xác định vấn đề và làm mịn các yêu cầu. Khách hàng đánh giá công việc và đưa ra các gợi ý. Trên cơ sở ý kiến đó, phần tiếp theo của lập kế hoạch và phân tích lỗi xuất hiện. Mô hình xoáy ốc hiện nay là mô hình hướng tiếp cận hiện thực nhất để phát triển các hệ thống lớn. Nó sử dụng mô hình mẫu như là cơ chế loại trừ lỗi, cho phép nhà phát triển áp dụng mô hình mẫu tại mỗi chu trình phát triển. Nó kế thừa cách tiếp cận hệ thống từng bước từ chu kỳ sống cổ điển nhưng kết hợp với quá trình lặp lại phù hợp với thực tế. Giống như các quy trình khác, mô hình xoáy ốc không phải là công cụ vạn năng. Đối với những hệ thống lớn, khó có thể điều khiển sự tiến hóa của phần mềm. Nó đòi hỏi phải có kỹ năng đánh giá lỗi. Hơn nữa cần phải có thêm thời gian để kiểm thử phương pháp mới này. Khó thuyết phục khách hàng về việc 40
41. kiểm soát tiến trình. Cần dựa vào những chuyên gia đánh giá rủi ro, các rủi ro phải được phát hiện và quản lý. 2.4. Mô hình tăng trƣởng (Incremental Model) Thay vì chuyển giao một lần, quá trình phát triển và chuyển giao được chia làm nhiều lần, mỗi chuyển giao đáp ứng một phần chức năng. Yêu cầu người dùng được phân loại ưu tiên, mức cao sẽ thuộc phần chuyển giao sớm. Khi phát triển một phiên bản, yêu cầu tương ứng là cố định, tuy nhiên yêu cầu cho phiên bản vẫn phát triển. Hình 2.4. Mô hình tăng trƣởng Trong mô hình này ở các bước (iteration) đầu tập trung vào yêu cầu của phần mềm và thiết lập một kiến trúc ổn định cho hệ thống (ít phải thay đổi sau này). Các bước tiếp theo tập trung vào việc xây dựng sản phẩm để cuối cùng chuyển sang giai đoạn kiểm tra hệ thống. Mỗi bước hiện thực một phần cụ thể trong toàn bộ yêu cầu của hệ thống. Quá trình xây dựng và chiến thuật kiểm tra theo kiểu tăng trưởng và dựa trên phương pháp kiểm tra hồi quy. Đối với mô hình này, qui trình phát triển phần mềm được chia thành nhiều bước. Mỗi bước thực hiện chỉ một số yêu cầu, tạo ra được một sản phẩm tạm thời chứa chức năng theo các yêu cầu đã thực hiện. Bước kế tiếp sẽ được thực hiện nhằm tăng cường chức năng theo các yêu cầu kế tiếp chưa được thực hiện. Cứ tiếp tục các bước cho tới khi tạo ra được sản phẩm hoàn chỉnh. Các yêu cầu của người sử dụng được đánh thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên càng cao thì càng 41
42. ở trong những bước phát triển sớm hơn. Các bước lặp đầu tiên tạo ra sản phẩm lõi (core product) giao cho khách hàng. Các bước sau tập trung vào việc hoàn thiện dần sản phẩm. Mỗi bước hiện thực một phần cụ thể trong toàn bộ yêu cầu của hệ thống. Sau mỗi lần tăng trưởng thì có thể chuyển giao kết quả cho khách hàng nên các chức năng của hệ thống có thể có được sớm hơn. Các bước trước đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những bước tiếp theo. Ưu điểm: Có sản phẩm dùng được trong thời gian ngắn; đáp ứng nhanh yêu cầu của khách hàng nhằm chiếm lĩnh thị trường; Phiên bản trước như là bản mẫu cho phiên bản sau; Rủi ro được loại bỏ sớm; Dịch vụ hệ thống có mức ưu tiên cao nhất được kiểm thử nhiều nhất. Đồng thời với mô hình này, chúng ta có thể thực hiện nhiều bước đồng thời, và có thể tách nhỏ công việc. Nhược điểm: Tổng chi phí phát triển là cao hơn bình thường; Tổng thời gian để chuyển giao toàn bộ chức năng là lớn hơn; Kế hoạch chuyển giao mang tính quyết định sự thành công, nếu sai lầm sẽ dẫn đến thảm họa. 2.5. Mô hình RAD – phát triển ứng dụng nhanh (Rapid Application Development). Hình 2.5. Mô hình RAD Mô hình RAD (Rapid Application Development) là mô hình tuần tự tuyến tính có thời gian phát triển rất ngắn (60-90 ngày). Sử dụng các thành phần có sẵn càng nhiều càng tốt. Sử dụng công cụ lập trình ở dạng tự động sinh mã chứ không phải các ngôn ngữ truyền thống. Hạn chế: Phải đủ người cho nhóm phát triển phần mềm; Cần có sự hợp tác tốt với khách hàng; Hệ thống phải dễ module hóa; Khó áp dụng cho hệ thống yêu cầu cao về thể hiện, hệ thống dễ bị những rủi ro về kỹ thuật (ứng dụng nặng về sử dụng kỹ thuật mới). 2.6. Mô hình phát triển dựa trên cấu phần 42
43. Xuất phát từ quan điểm: "Buy do not build", tư tưởng của phát triển dựa trên thành phần là lắp ráp hệ thống từ những thành phần đã có. Do vậy, kiến trúc phần mềm của hệ thống dựa vào kiến trúc phần mềm của các thành phần phần mềm tiêu chuẩn nên hệ thống đạt chất lượng cao hơn. Phương pháp phát triển dựa trên thành phần gần tương tự như phương pháp phát triển hướng đối tượng. Hoạt động công nghệ bắt đầu với sự chỉ ra các lớp tham dự để phát triển hệ thống. Nếu các lớp này được tìm thấy trong thư viện và sự thích nghi là tốt, chúng sẽ được lấy ra và phát triển hệ thống. Ngược lại, chúng sẽ được phát triển để sử dụng và bổ sung vào thư viện sử dụng lại. Thành phần phần mềm được sử dụng lại có độ chính xác cao và có thể nói là không chứa lỗi. Mặc dầu không thường xuyên được chứng minh về mặt hình thức nhưng với việc sử dụng lại, lỗi được tìm thấy và loại trừ; chất lượng của thành phần được cải thiện như là một kết quả. Khi những thành phần sử dụng lại được ứng dụng thông qua tiến trình phần mềm, chúng ta ít tốn thời gian để tạo ra kế hoạch, mô hình, tài liệu, mã và dữ liệu mà chúng là cần thiết để tạo ra hệ thống. Thêm vào, chức năng cùng mức được phân phối cho người sử dụng với đầu vào ít công sức hơn, do vậy, hiệu suất phần mềm được cải thiện. Những điểm chính của mô hình được tóm tắt dưới đây: 43
44. Thành phần để xây dựng Phân tích lỗi hệ thống Kế hoạch Hợp nhất cho Tìm kiếm Giao tiếp phiên bản hệ trong thư viện thống thứ n thành phần với khách Bổ sung thành Sử dụng nếu hàng phần mới vào thành phần Đánh giá thư viện thích hợp Xây dựng nếu của khách Xây dựng thành phần không thích hợp hàng hay dừng hệ Hình 2.6: Mô hình phát triển dựa trên cấu phần thống 2.7. Kỹ thuật thế hệ thứ 4 Kỹ thuật thế hệ thứ 4 (4GT - Fourth generation technique) là kỹ thuật dựa vào nhiều công cụ phần mềm có đặc điểm: Dựa vào đặc tả phần mềm ở mức cao theo một cách thức định trước, công cụ sẽ tự động sinh mã. 4GT thích hợp cho ứng dụng vừa và nhỏ. 4GT tăng năng suất đáng kể. Một số ý kiến cho rằng: ƒ + Một số công cụ của 4GT khó sử dụng. ƒ + Chương trình tạo ra khá cồng kềnh. ƒ + Việc bảo trì cho các hệ thống lớn thực sự là một vấn đề cần đặt ra. 2.8. Mô hình RUP Mô hình phát triển phần mềm thống nhất (RUP - Rational Unified Process) là một trong những mô hình phát triển dựa trên thành phần dùng ngôn ngữ mô hình thống nhất (UML-Unified modeling language). Mô hình RUP nhằm giải quyết các vấn đề sau của tiến trình phần mềm: Phát triển sản phẩm theo vòng lặp; Quản lý yêu cầu; Sử dụng lại các thành phần; Có mô hình trực quan; Thẩm định được chất lượng; Kiểm soát thay đổi RUP là một tiến trình chứa các giai đoạn và các luồng công việc. Ở đây: 44
45. + Các giai đoạn mô tả hệ thống tiến triển theo thời gian như thế nào? + Các luồng công việc là một tập các nhiệm vụ xuất hiện trong suốt vòng đời hệ thống. Các giai đoạn của RUP Giai đoạn 1: Khởi đầu (Inception) . Giai đoạn này xác định: • Phạm vi dự án, yêu cầu người dùng và ràng buộc. • Yêu cầu nghiệp vụ, rủi ro, kếhoạch dựán (phân công, chi phí) • Thiết kế kiến trúc (chi phí, lịch, tài nguyên) • Cấu hình môi trường làm việc, công cụ. Giai đoạn 2: Hình thành (Elaboration). Trong giai đoạn này: • Tinh chỉnh tài liệu • Hoạch định những bước lặp • Xây dựng kếhoạch phát triển : tiến trình, công cụ CASE • Tinh chỉnh kiến trúc và chọn thành phần (component) Giai đoạn 3 : Xây dựng (Construction). Ở giai đoạn này cần : • Quản lý tiến trình tạo sản phẩm: năng suất, đảm bảo chất lượng • Tạo sản phẩm (alpha, beta, các phiên bản test khác) • Đưa ra kế hoạch triển khai ứng dụng: phần mềm, người sửdụng, hỗ trợ Giai đoạn 4 : Chuyển giao (Transition). Giai đoạn này nhằm: • Tạo sản phẩm xuất xưởng • Kiểm tra sản phẩm, thu thập phản hồi 45
46. • Hoạt động hỗ trợ: quản lý dự án (cải tiến, phân phối sản phẩm ), quản lý chất lượng, quản lý cấu hình, quản lý môi trường Các luồng công việc trong RUP + Các luồng kỹ nghệ: Mô hình hóa nghiệp vụ; Xác lập yêu cầu; Phân tích; Thiết kế; Cài đặt; Kiểm thử; Triển khai. + Các luồng hỗ trợ: Quản lý dự án; Quản lý cấu hình và thay đổi; Môi trường; Vận hành và hỗ trợ; Quản lý hạ tầng 3. Trợ giúp tự động hoá phát triển CASE (Computer-Aided Software Engineering) là các phần mềm trợ giúp phát triển và tiến hoá hệ thống. Các công cụ thường gặp: •+ Bộ soạn thảo đồ thị: để phát triển mô hình hệ thống. •+ Từ điển dữ liệu:để quản lý các thực thể thiết kế •+ Bộ xây dựng giao diện: để thiết kế giao diện •+ Bộ gỡ rối: trợ giúp tìm lỗi trong chương trình •+ Bộ chuyển đổi tự động: tạo sinh các phiên bản mới từ thiết kế / hay chương trình. CASE góp phần đáng kể hoàn thiện tiến trình phần mềm cả về trình tự, tiến độ và chất lượng: tự động hóa một phần hoạt động mô hình hóa vàquản lý. Tuy vậy, có những hoạt động không thể tự động hóa như: Sự suy nghĩ sáng tạo trong SE; Lựa chọn giải pháp công nghệ; Giao tiếp khi làm việc nhóm; Thực hiện việc quản lý Phân loại CASE Phân loại CASE giúp hiểu và sử dụng chúng trong phát triển phần mềm. Có thể phân loại CASE theo: + Hướng chức năng: Công cụ cho các chức năng cụ thể: soạn thảo, lập kế hoạch, làm mẫu, + Hướng tiến trình: Công cụ cho hoạt động của tiến trình được trợ giúp: mô hình nghiệp vụ, liên kết thực thể (E-R). 46
47. + Hướng tích hợp: Công cụ trợ giúp tổ chức việc tích hợp các đơn vị các mức trong hệ thống. + Dựa trên loại hoạt động: Đặc tả, thiết kế, triển khai, thẩm định và xác minh. CASE tích hợp Các công cụ đơn (Tools): trợ giúp những nhiệm vụ riêng rẽ của tiến trình như: kiếm tra sự nhất quán, soạn thảo, tạo mô hình. Bàn thợ (Workbenches): trợ giúp 1 pha của tiến trình phát triển, như đặc tả, thiết kế, Môi trường phát triển (Environments): trợ giúp toàn bộ hay một phần của toàn tiến trình phần mềm (có thể bao gồm một số bàn thợ). TỔNG KẾT Quy trình phần mềm chung đã được giới thiệu. Những công việc phải làm trong quy trình phần mềm và cách thực hiện chúng cũng được trình bày. Một số mô hình phát triển phần mềm. Đặc điểm của mỗi mô hình phát triển phần mềm cũng đã được đề cập. Các vấn đề nhằm giúp chúng ta một cái nhìn tổng quan các kỹ thuật, công nghệ của ngành học, đồng thời việc xác định mô hình phát triển phần mềm mà dự án sẽ triển khai sản phẩm cũng có một ý nghĩa lớn cho vấn đề tham gia và quản lý dự án phần mềm. Câu hỏi và bài tập 1. Hãy mô tả các thành phần trong vòng đời phát triển hệ thống? 2. Vẽ bản đồ tư duy cho 3 giai đoạn chính của quá trình phát triển phần mềm. 3. Có mấy loại mô hình tiến trình? Gồm những loại nào? 4. Trình bày nội dung của các mô hình: thác nước, làm bản mẫu, xoắn ốc, tiến hoá, tăng trưởng, ứng dụng nhanh, hình thức hoá, đối tượng, sử dụng lại, mô hình mã nguồn mở, kỹ thuật thế hệ thứ 4 theo các ý sau: + Nội dung? đặc trưng? 47
48. + Ưu, nhược điểm? + Các yêu cầu ? + Thích hợp với dự án phần mềm nào? 5. Tiến hoá phần mềm là gì? Lý do? 6. Mô tả tiến trình tiến hoá hệ thống 7. Hãy nêu ý nghĩa của việc xác định mô hình phát triển phần mềm mà dự án sẽ triển khai sản phẩm. 48
49. Chƣơng 3. PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU Mục đích Trình bày các vấn đề về phân tích và đặc tả yêu cầu. Các vấn đề về thẩm định và quản lý yêu cầu, cũng như đặc tả hệ thống và làm bản mẫu cùng qui trình phân tích và đặc tả yêu cầu theo mô hình RUP cũng được đưa ra. Yêu cầu Biết được các loại yêu cầu phần mềm. Nắm được qui trình xác định yêu cầu. Hiểu được cách thu nhận yêu cầu sử dụng phỏng vấn, hợp tác phát triển ứng dụng, bảng hỏi, phân tích tài liệu, quan sát Vận dụng phân tích yêu cầu với việc mô hình hóa. Hiểu được qui trình Thẩm định và quản lý yêu cầu Xây dựng các đặc tả hệ thống và làm bản mẫu Vận dụng được qui trình Phân tích và đặc tả yêu cầu theo mô hình RUP. 1. Đại cƣơng về phân tích và đặc tả yêu cầu. Phân tích và đặc tả yêu cầu là bước kỹ thuật đầu tiên trong tiến trình kỹ nghệ phần mềm. Công việc ở bước này là tìm hiểu xem chúng ta phải phát triển cái gì, chứ không phải là phát triển như thế nào. Đích cuối cùng của khâu phân tích là tạo ra đặc tả yêu cầu, là tài liệu ràng buộc giữa khách hàng và người phát triển và là cơ sở của hợp đồng. Phân tích yêu cầu gồm nhiều bước nhỏ: nghiên cứu khả thi, phân tích mô hình hóa, đặc tả - thẩm định yêu cầu, quản lý yêu cầu. Giai đoạn này được tiến hành phối hợp giữa bên phát triển và khách hàng và nó có vai trò đặc biệt quan trọng trong tiến trình phát triển phần mềm. 49
50. Hoạt động phân tích là hoạt động phối hợp giữa khách hàng và người phân tích (bên phát triển). Khách hàng phát biểu yêu cầu và người phân tích hiểu, cụ thể hóa và biểu diễn lại yêu cầu. Hoạt động phân tích giữ một vai trò đặc biệt quan trọng trong phát triển phần mềm, giúp cho đảm bảo chất lượng của phần mềm (phần mềm đáng tin cậy). Phần mềm đáng tin cậy có nghĩa là phải thực hiện được chính xác, đầy đủ yêu cầu của người sử dụng. Nếu phân tích không tốt dẫn đến hiểu lầm yêu cầu thì việc sửa chữa sẽ trở nên rất tốn kém. Chi phí để sửa chữa sai sót về yêu cầu sẽ tăng lên gấp bội nếu như sai sót đó được phát hiện muộn, ví dụ như ở bước thiết kế hay mã hóa. Việc phân tích, nắm bắt yêu cầu thường gặp các khó khăn như: - Các yêu cầu thường mang tính đặc thù của tổ chức đặt hàng, do đó thường khó hiểu, khó định nghĩa và không có chuẩn biểu diễn. Các định nghĩa yêu cầu có thể không đầy đủ. Một số yêu cầu có thể không được biết ở thời điểm ban đầu. Việc kiểm tra và kiểm chứng các yêu cầu nhiều khi rất khó khăn. - Các hệ thống thông tin lớn có nhiều người sử dụng thì các yêu cầu thường rất đa dạng và có các mức ưu tiên khác nhau, thậm chí mâu thuẫn lẫn nhau. - Người đặt hàng nhiều khi là các nhà quản lý, không phải là người dùng thực sự do đó việc phát biểu yêu cầu thường không chính xác. Phân tích viên có thể không tiếp xúc với những người sử dụng thích hợp. Có thể tóm lược các hoạt động của tiến trình kỹ nghệ yêu cầu như sau: + Nghiên cứu khả thi với sản phẩm là dự án khả thi. + Phân tích, xác định yêu cầu cho ra các mô hình hệ thống. + Đặc tả yêu cầu kết quả là các yêu cầu được đặc tả. + Thẩm định yêu cầu với mục đích là đưa ra tài liệu yêu cầu. Trong phân tích cần phân biệt giữa yêu cầu và mục tiêu của hệ thống. Yêu cầu là một đòi hỏi mà chúng ta có thể kiểm tra được còn mục tiêu là cái trừu tượng hơn mà chúng ta hướng tới. 50
51. Một yêu cầu là một tuyên bố điều gì mà hệ thống phải làm hoặc tính chất gì nó phải có. Yêu cầu là cái mà sẽ được tiến triển thành các mô tả kỹ thuật về việc hệ thống phải được thiết lập như thế nào. Trong khi phân tích, các yêu cầu được viết từ góc độ người làm nghiệp vụ. Ví dụ: “Giao diện của hệ thống phải thân thiện với người sử dụng” là một mục tiêu và nó tương đối không khách quan và khó kiểm tra. Với một phát biểu chung chung như vậy thì khách hàng và nhà phát triển khó định ra được một ranh giới rõ ràng để nói rằng phần mềm đã thỏa mãn được đòi hỏi đó. Với một mục tiêu như vậy, một yêu cầu cho nhà phát triển có thể là “Giao diện đồ họa mà các lệnh phải được chọn bằng menu”. Mục đích của giai đoạn phân tích là xác định rõ các yêu cầu của phần mềm cần phát triển. Tài liệu yêu cầu nên dễ hiểu với người dùng, đồng thời phải chặt chẽ để làm cơ sở cho hợp đồng và để cho người phát triển dựa vào đó để xây dựng phần mềm. Do đó yêu cầu thường được mô tả ở nhiều mức chi tiết khác nhau phục vụ cho các đối tượng đọc khác nhau. Các mức đó có thể là: • Định nghĩa (xác định) yêu cầu: mô tả một cách dễ hiểu, vắn tắt về yêu cầu, hướng vào đối tượng người đọc là người sử dụng, người quản lý • Đặc tả yêu cầu: mô tả chi tiết về các yêu cầu, các ràng buộc của hệ thống, phải chính xác sao cho người đọc không hiểu nhầm yêu cầu, nên hướng vào đối tượng người đọc là các kỹ sư phần mềm (người phát triển), kỹ sư hệ thống (sẽ làm việc bảo trì) Các tài liệu yêu cầu cần được thẩm định để đảm bảo thỏa mãn nhu cầu người dùng. Đây là công việc bắt buộc để đảm bảo chất lượng phần mềm. Đôi khi việc xác định đầy đủ yêu cầu trước khi phát triển hệ thống là không thực tế và khi đó việc xây dựng các bản mẫu để nắm bắt yêu cầu là cần thiết. Những người đọc yêu cầu: + Người dùng hệ thống + Người quản lý của khách hàng + Kỹ sư của khách hàng 51
52. +Người quán lý nhà thầu + Nhà kiến trúc hệ thống + Các nhà phát triển vàbảo trì phần mềm Do đó yêu cầu viết ra cần đáp ứng được tất các đối tượng nói trên. Các chiến lược phân tích yêu cầu Tiến trình cơ bản của việc phân tích có thể chia thành: + Hiểu hệ thống hiện tại (as-is system) + Xác định các cải tiến hệ thống hiện tại + Xây dựng các yêu cầu cho hệ thống mới (to-be system) Có 3 chiến lược phân tích yêu cầu: + Tự động hóa quy trình nghiệp vụ. + Cải tiến quy trình nghiệp vụ. + Tái cấu trúc quy trình nghiệp vụ. Chiến lược tự động hóa quy trình nghiệp vụ: Chiến lược này nhằm cung cấp một cách thức cơ bản trong đó vận hành của tổ chức không thay đổi và sử dụng các kỹ thuật máy tính để làm một số công việc. Với chiến lược này thường thì nguy cơ thấp, nhưng lợi ích mang lại thấp. Nó đòi hỏi các nhà hoạch định kế hoạch phải dành nhiều thời gian để hiểu hệ thống hiện tại. Các kỹ thuật được sử dụng cho chiến lược này là: Phân tích vấn đề và Phân tích nguyên nhân vấn đề. Với kỹ thuật phân tích vấn đề, chúng ta cần: Hỏi người sử dụng để xác định các vấn đề của hệ thống hiện tại và cách thức họ giải quyết các vấn đề. Kỹ thuật này có xu hướng giải quyết vấn đề chứ không phải là tận dụng cơ hội, các cải tiến thường là nhỏ và theo hướng gia tăng dần. Với kỹ thuật phân tích nguyên nhân vấn đề, những người sử dụng được hỏi không phải là về giải pháp mà là về danh sách (có mức độ ưu tiên) của các vấn đề, các nguyên nhân gốc rễ gây ra các vấn đề này. Các nhà phân tích nghiên cứu từng nguyên nhân gốc rễ để tìm: Các giải pháp cho các vấn đề có mức ưu tiên cao nhất; Nguyên nhân gốc rễ chung cho nhiều vấn đề. Một khi các nguyên nhân được nhận biết, các giải pháp có thể được phát triển. Chiến lược cải tiến quy trình nghiệp vụ 52
53. Chiến lược cải tiến quy trình nghiệp vụ nhằm làm thay đổi ở mức trung bình cách thức tổ chức hoạt động để tận dụng những cơ hội mới được cung cấp bởi công nghệ hoặc sao chép những gì đối thủ cạnh tranh đang làm. Các hoạt động thường có của chiến lược này là: + Phân tích thời hạn: Xác định thời gian cần thiết để hoàn thành mỗi bước trong quy trình nghiệp vụ; So sánh thời gian này với tổng số thời gian cần thiết cho toàn bộ quy trình. Nếu có sự khác biệt lớn cho thấy qui trình nghiệp vụ đang có có thể được giải quyết bằng cách: Tích hợp một số bước cùng nhau hay thực hiện một số bước đồng thời (song song). + Tính giá thành dựa trên hoạt động: tương tự như phân tích thời hạn nhưng áp dụng cho giá thành + Đo điểm chuẩn (benchmarking) phi chính thức: phân tích các quy trình tương tự trên các tổ chức thành công. Chiến lược tái cấu trúc quy trình nghiệp vụ: Chiến lược tái cấu trúc quy trình nghiệp vụ nhằm thay đổi căn bản cách thức mà tổ chức đang vận hành. Tổ chức sẽ được thay đổi tối đa: “Thay đổi cái cũ và tiến vào cái mới”. Dành một lượng thời gian nhỏ để hiểu hệ thống hiện tại, bởi vì mục tiêu là tập trung trên các ý tưởng mới và cách thức mới để thực hiện nghiệp vụ. Các kỹ thuật cho chiến lược này là: Phân tích kết quả: khách hàng mong muốn điều gì ở cuối cùng? Phân tích kỹ thuật: áp dụng các kỹ thuật mới cho các quy trình nghiệp vụ và xác định lợi ích; Loại bỏ hoạt động: loại bỏ từng hoạt động trong quy trình kinh doanh trong một bài tập “force-fit“. 2. Phân tích và đặc tả yêu cầu Ba mục tiêu của giai đoạn phân tích yêu cầu là: + Mô tả những gì khách hàng yêu cầu. + Thiết lập một nền tảng cho thiết kế phần mềm. + Xác định một tập những yêu cầu mà có thể thẩm định khi phần mềm được xây dựng. Phân tích yêu cầu nhằm xác định các đặc trưng của phần mềm, xác định giao tiếp của phần mềm với những thành phần khác, đồng thời thiết lập những ràng buộc mà phần mềm phải có. 53
54. Các yêu cầu có thể chứa các phát biểu trừu tượng mức cao của dịch vụ và những ràng buộc cho tới những đặc tả chức năng toán học chi tiết. Yêu cầu cần được phát biểu rõ ràng, có thể là cơ sở cho việc xác định giá cả và cho việc thực hiện. Đối với yêu cầu người dùng, cần thấy rằng ở đây là viết cho người dùng. Các yêu cầu thường được mô tả bằng ngôn ngữ tự nhiên cộng với các biểu đồ, nhằm: mô tả các dịch vụ và những ràng buộc hoạt động. Đối với yêu cầu hệ thống, tài liệu cần có cấu trúc mô tả chi tiết chức năng, dịch vụ và ràng buộc. Chúng có thể là một phần của hợp đồng, xác định những gì cần phải thực hiện. Hình 3.1. Các hoạt động của phân tích và đặc tả yêu cầu 2.1. Phân loại yêu cầu: • Yêu cầu chức năng: đó là các chức năng dịch vụ mà hệ thống cần cung cấp. • Yêu cầu phi chức năng: những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển mà hệ thống cần tuân thủ. • Yêu cầu miền ứng dụng: phản ảnh những đặc trưng của miền ứng dụng. Một số yêu cầu chức năng: ƒ + Chức năng tính toán ƒ + Chức năng lưu trữ 54
55. ƒ + Chức năng tìm kiếm ƒ + Chức năng kết xuất ƒ + Chức năng backup, restore ƒ + Chức năng đa người dùng ƒ + Chức năng đa phương tiện Một số yêu cầu phi chức năng: ƒ + Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ ƒ + Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình ƒ + Yêu cầu của người sử dụng ƒ + Ràng buộc về ngân sách ƒ + Các chính sách của tổ chức sử dụng hệ thống ƒ + Yêu cầu tương thích giữa phần cứng và phần mềm ƒ + Các tác nhân ngoài khác Phân loại yêu cầu phi chức năng: + Các yêu cầu về sản phẩm: hiệu năng, khả năng sử dụng, độ tin cậy, tốc độ, bộ nhớ, tính khả chuyển và tái sử dụng + Các yêu cầu quá trình của tổ chức sử dụng hệ thống: thời gian bàn giao, yêu cầu phù hợp với hệ thống cũ, các chuẩn phải tuân theo, phương pháp thiết kế, ngôn ngữ lập trình, hệ điều hành sử dụng + Các yêu cầu ngoài: được xác định từ các tác nhân từ bên ngoài như các yêu cầu về luật pháp, yêu cầu tôn trọng tính riêng tư, chi phí, thành viên nhóm phát triển phần mềm Những yêu cầu phi chức năng khó phát biểu chính xác, nó có thể mơ hồ, vì vậy cần bổ sung bằng mục tiêu và một số chỉ số đo lường. Ví dụ: + Hệ thống dễ sử dụng cho những người đã quen và người dùng có thể hạn chế lỗi thấp nhất. 55
56. + Yêu cầu phi chức năng có thể kiểm tra bằng định lượng hóa: Người dùng có kinh nghiệm có thể sử dụng tất cả các chức năng sau 2 giờ huấn luyện. Sau khi huấn luyện người dùng có kinh nghiệm sẽ không mắc trung bình quá 2 lỗi/ngày. Tranh chấp giữa các yêu cầu phi chức năng thường xảy ra trong các hệ thống lớn. Một số ví dụ về yêu cầu phi chức năng: + Yêu cầu về vận hành • Hệ thống phải đặt vừa trong một cái túi hoặc ví • Hệ thống có thể tích hợp với hệ thống quản lý kho hiện có. + Yêu cầu về hiệu năng • Mọi tương tác giữa người dùng và hệ thống không được vượt quá 2 giây. • Hệ thống phải nhận được thông tin cập nhật về tồn kho mỗi 15 phút + Yêu cầu về bảo mật • Chỉ có những người quản lý trực tiếp mới có thể nhìn thấy các thông tin cá nhân của nhân viên • Khách hàng có thể nhìn thấy lịch sử đặt hàng của họ chỉ trong giờ làm việc. + Yêu cầu về văn hóa và chính trị • Hệ thống phải có khả năng phân biệt giữa tiền Mỹ và Châu Âu • Hệ thống phải tương thích với các chuẩn công nghiệp bảo hiểm. Yêu cầu miền ứng dụng: Yêu cầu miền ứng dụng được xác định từ lãnh vực ứng dụng của hệ thống nó phản ánh các thuộc tính và ràng buộc của lãnh vực ứng dụng. Yêu cầu miền ứng dụng có thể là yêu cầu chức năng hoặc phi chức năng. Ví dụ: Trong hệ thống quản lý thư viện, do vấn đề bản quyền vài tài liệu phải được xóa ngay, là một yêu cầu có tính chất đặc thù của miền ứng dụng. Các vấn đề về yêu cầu miền ứng dụng: 56
57. + Tính hiểu được: Yêu cầu cần diễn đạt theo ngôn ngữ miền ứng dụng nên thường khó hiểu cho người phát triển. + Chứa ẩn ý: Những chuyên gia miền thường quá quen thuộc trong lãnh vực của mình nên họ thường nêu những yêu cầu miền ứng dụng không tường minh. 2.2. Qui trình xác định yêu cầu (Kỹ nghệ yêu cầu - Requirements Engineering) Qui trình xác định yêu cầu có thể mô tả qua mô hình sau: Hình 3.2. Qui trình xác định yêu cầu Qui trình xác định yêu cầu có thế được theo mô hình xoắn ốc để có thể xác định yêu cầu cho các hệ thống phức tạp như sau: 57
58. Hình 3.3. Mô hình xoắn ốc của qui trình xác định yêu cầu 2.2.1. Nghiên cứu khả thi Đây là giai đoạn có tầm quan trọng đặc biệt, vì nó liên quan đến việc lựa chọn giải pháp. Trong giai đoạn này người phân tích phải làm rõ được các điểm mạnh và điểm yếu của hệ thống cũ, đánh giá được mức độ, tầm quan trọng của từng vấn đề, định ra các vấn đề cần phải giải quyết (ví dụ: những dịch vụ mới, thời hạn đáp ứng, hiệu quả kinh tế). Sau đó người phân tích phải định ra một vài giải pháp có thể (sơ bộ) và so sánh cân nhắc các điểm tốt và không tốt của các giải pháp đó (như tính năng của hệ thống, giá cả cài đặt, bảo trì, việc đào tạo người sử dụng ). Đó là việc tìm ra một điểm cân bằng giữa nhu cầu và khả năng đáp ứng. Mọi dự án đều khả thi khi nguồn tài nguyên vô hạn và thời gian vô hạn. Nhưng việc xây dựng hệ thống lại phải làm với sự hạn hẹp về tài nguyên và khó (nếu không phải là không hiện thực) bảo đảm đúng ngày bàn giao. Phân tích khả thi và rủi ro có liên quan với nhau theo nhiều cách. Nếu rủi ro của dự án là lớn thì tính khả thi của việc chế tạo phần mềm có chất lượng sẽ bị giảm đi. Trong giai đoạn nghiên cứu khả thi, chúng ta tập trung vào bốn lĩnh vực quan tâm chính: 58
59. 1. Khả thi về kinh tế: chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống được xây dựng đem lại. Tính khả thi về kinh tế thể hiện trên các nội dung sau: - Khả năng tài chính của tổ chức cho phép thực hiện dự án. - Lợi ích mà dự án phát triển hệ thống thông tin mang lại đủ bù đắp chi phí phải bỏ ra xây dựng nó. - Tổ chức chấp nhận được những chi phí thường xuyên khi hệ thống hoạt động. Một thuật ngữ hay dùng để chỉ tài liệu nghiên cứu khả thi về kinh tế là luận chứng kinh tế. Luận chứng kinh tế nói chung được coi như nền tảng cho hầu hết các hệ thống (các ngoại lệ là hệ thống quốc phòng, hệ thống luật, các hệ thống phục vụ cho các nghiên cứu đặc biệt). Luận chứng kinh tế bao gồm: - Các mối quan tâm, nhất là phân tích chi phí/lợi ích - Chiến lược phát triển dài hạn của công ty - Sự ảnh hứởng tới các sản phẩm lợi nhuận khác - Chi phí cho tài nguyên cần cho việc xây dựng và phát triển thị trường tiềm năng. 2. Khả thi về kỹ thuật: Khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng tới khả năng đạt tới một hệ thống chấp nhận được. Nói cách khác, khả thi kỹ thuật là xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự định áp dụng hay không. Khả thi kỹ thuật thường là lĩnh vực khó thâm nhập nhất tại giai đoạn phân tích. Điều thực chất là tiến trình phân tích và xác định nhu cầu cần được tiến hành song song với việc xác nhận tính khả thi kỹ thuật. Các xem xét thường được gắn với tính khả thi kỹ thuật bao gồm: Rủi ro xây dựng: liệu các phần tử hệ thống có thể được thiết kế sao cho đạt được chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích không? Có sẵn tài nguyên: có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang xét không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho việc xây dựng hệ thống không? 59
60. Công nghệ: công nghệ liên quan đã đạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chưa? Tóm lại chúng ta đưa ra câu hỏi: Chúng ta có khả năng xây dựng phần mềm hay không? 3. Khả thi về pháp lý: nghiên cứu và đưa ra phán quyết về có hay không sự xâm phạm, vi phạm pháp luật hay khó khăn pháp lý từ việc xây dựng và vận hành hệ thống. Tính khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, nghĩa vụ pháp lý, sự vi phạm và vô số các bẫy pháp lý khác mà thường là các nhân viên kỹ thuật không biết tới. Hiện nay, vấn đề khả thi về pháp lý vẫn chưa được coi trọng một cách đúng mức mặc dù đã có một số luật liên quan đến CNTT và bảo hộ bản quyền. 4. Khả thi về hoạt động: đánh giá tính khả thi của việc vận hành hệ thống. Trong mỗi phương án người ta cần xem xét hệ thống có thể vận hành trôi chảy hay không trong khuôn khổ tổ chức và điều kiện quản lý mà tổ chức đó (người dùng, khách hàng) có. Mức độ các phương án được xem xét tới trong nghiên cứu khả thi thường bị giới hạn bởi các ràng buộc về chi phí và thời gian. Những câu hỏi thường được đặt ra để phân tích khả thi: ƒ + Nếu hệ thống không được cài đặt thì sao? ƒ + Vấn đề xử lý hiện tại như thế nào? ƒ + Hệ thống đề xuất sẽ trợ giúp theo cách thức nào? ƒ + Những rắc rối về việc tích hợp là gì? ƒ + Có cần kỹ thuật mới không? Đòi hỏi kỹ năng gì? ƒ + Hệ thống đề nghị hỗ trợ những tiện ích gì? 2.2.2. Phát hiện và phân tích yêu cầu 2.2.2.1. Qui trình phát hiện yêu cầu Phát hiện/nắm bắt yêu cầu là mô tả trừu tượng về các dịch vụ mà hệ thống cần cung cấp và các ràng buộc mà hệ thống cần tuân thủ khi vận hành. Nó chỉ mô tả các hành vi bên ngoài của hệ thống mà không liên quan tới các chi tiết thiết kế. 60
61. Yêu cầu nên được viết sao cho có thể hiểu mà không cần một kiến thức chuyên môn đặc biệt nào. Các yêu cầu phi chức năng thường rất đặc thù với từng khách hàng và do đó khó phân tích và đặc tả một cách đầy đủ và chính xác. Về nguyên tắc, yêu cầu của hệ thống phải vừa đầy đủ vừa không được mâu thuẫn nhau. Đối với các hệ thống lớn phức tạp thì chúng ta khó đạt được hai yếu tố này trong các bước phân tích đầu. Trong các bước duyệt lại yêu cầu cần phải bổ sung, chỉnh lý tư liệu yêu cầu. Trong giai đoạn này, nhân viên của nhóm làm phần mềm và khách hàng cùng hợp tác để xác định: các dịch vụ mà hệ thống cung cấp, các ràng buộc vận hành của hệ thống Các nguồn thông tin để có thể xác định yêu cầu là: tài liệu, các bên có liên quan đến dự án phần mềm (Stakeholder), đặc tả của hệ thống tương tự Ở đây Stakeholder gồm: Người sử dụng cuối; Người quản lý; Người phụ trách kỹ thuật; Chuyên gia lĩnh vực Các hoạt động chính của qui trình nắm bắt yêu cầu: • Phát hiện yêu cầu. • Phân loại và sắp xếp yêu cầu. • Sắp thứ tự ưu tiên và điều chỉnh các yêu cầu. • Tư liệu hóa yêu cầu. • Quản lý yêu cầu 61
62. Hình 3.4. Qui trình nắm bắt yêu cầu 2.2.2.2. Các phƣơng pháp nắm bắt yêu cầu Các phương pháp nắm bắt yêu cầu chủ yếu là: Phỏng vấn; Quan sát; Điều tra bằng bảng hỏi; Nghiên cứu tài liệu; Joint Application Design – JAD; Làm bản mẫu; Mô hình hóa a. Phỏng vấn Phỏng vấn bao gồm phỏng vấn hình thức hoặc phỏng vấn phi hình thức là một trong những phần quan trọng nhất của quy trình xác định yêu cầu. Phỏng vấn được chia thành hai loại: + Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa trước và có nhiều đáp án để các bên liên quan (stakeholder) lựa chọn trả lời. + Phỏng vấn mở: tất cả các vấn đề không được xác định trước và stakeholder phải tự giải thích và phát biểu theo quan điểm của mình. Một phỏng vấn tốt cần thu thập được tất cả các hiểu biết về công việc phải làm của stakeholder, cần nắm rõ họ tương tác với hệ thống như thế nào. Chúng ta thường gặp khó khăn vì không thể hiểu được các thuật ngữ của miền ứng dụng, hay việc diễn đạt của người phỏng vấn. Để phỏng vấn thành công, người phỏng 62
63. vấn nên: cởi mở, sẵn sàng lắng nghe stakeholder, không có định kiến, đưa ra những câu hỏi gợi mở, thân thiện. Kỹ thuật phỏng vấn: • Bước 1: Những câu hỏi căn bản, ngữ cảnh bất kỳ ƒ Ai là người đưa đến những yêu cầu? ƒ Ai là người sử dụng giải pháp? ƒ Giải pháp thành công sẽ mang đến những lợi ích gì? ƒ Có thể có cách khác để thực hiện giải pháp? • Bước 2: Nhằm hiểu sâu hơn vấn đề ƒ Giải pháp tốt sẽ có output như thế nào? ƒ Những vấn đề giải pháp cần giải quyết? ƒ Hãy cho biết môi trường của giải pháp? ƒ Những vấn đề về thực thi và những ràng buộc ảnh hưởng? • Bước 3: Những câu hỏi về hiệu quả của việc gặp gỡ. ƒ Bạn là người được quyền trảlời những câu hỏi nhằm xây dựng giải pháp? Câu trả lời của bạn có chính thức không? ƒ Câu hỏi của tôi có phù hợp với vấn đề mà bạn đang gặp? ƒ Tôi đã hỏi quá nhiều câu hỏi? ƒ Những ai có thể cung cấp những thông tin thêm? ƒ Tôi có nên hỏi bạn những điều gì khác? Các bước phỏng vấn: Đặt cuộc hẹn Chuẩn bị tốt, hiểu kỹ về đối tượng Đúng giờ và có kế hoạch mở đầu ƒGiới thiệu về bản thân ƒSử dụng câu hỏi mở để bắt đầu ƒLuôn chú ý câu trả lời 63
64. ƒCó kế hoạch cho nội dung chính ƒKết hợp câu hỏi mở và đóng ƒBám sát trình bày và phát triển chi tiết. ƒLuôn cung cấp thông tin phản hồi ƒHạn chế ghi chép ƒCó kế hoạch kết thúc ƒTóm tắt nội dung, yêu cầu hiệu chỉnh ƒCho biết ngày họ nhận báo cáo ƒThống nhất ngày lấy lại bản hiệu chỉnh ƒXác nhận lại lịch làm việc Soạn câu hỏi: • Xác định mục cần hỏi và đối tượng trả lời • Viết vài câu hỏi và chọn câu 1, 2 câu phù hợp nhất • Phân loại câu hỏi • Kiểm tra lại ƒ Nhiều hơn 2 câu hỏi về một vấn đề ƒ Câu hỏi tối nghĩa ƒ Câu hỏi không có câu trả lời ƒ Câu hỏi tạo định hướng ƒ Không xác định được hết các trường hợp trả lời ƒ Gây nhầm lẫn về thứ tự trả lời • Sửa chữa lỗi • Thử lại với nhóm nhỏ (5-10). Yêu cầu góp ý • Phân tích góp ý • Phân tích câu trả lời • Kết quả không như mong đợi, kiểm tra lại câu hỏi 64
65. • In câu hỏi theo hình thức dễ đọc • Phân phát câu hỏi, hướng dẫn cách gởi lại, tem, địa chỉ. b. Phƣơng pháp cùng phát triển ứng dụng (JAD – Joint Application Design). Tổ chức hội thảo theo định kỳ giữa bên phát triển và bên khách hàng. Mục đích: Nhận ra yêu cầu; Hiểu yêu cầu; Thiết kế giải pháp; Điều khiển dự án cho tới khi hoàn thành. Đây là phương pháp hữu ích nhất để thu thập thông tin từ người dùng. Người tham gia: Chủ đầu tư; Người dùng nghiệp vụ; Người quản lý dự án; Nhà phân tích hệ thống; Chuyên gia khác. Một số lưu ý: • Người tham dự phải quan tâm toàn bộ cuộc họp. • Tất cả người tham dự là như nhau • Phải chuẩn bị chu đáo • Chuẩn bị tài liệu sẵn sàng • Vị trí họp ở ngoài (off-site) thường được ưa chuộng hơn. • Tạo lịch biểu và cố gắng tuân thủ nó • Không sa vào chi tiết. • Buổi họp có thể được điện tử hóa và ẩn danh nhằm giảm được các vấn đề trong việc thiết lập nhóm và có thể tiến hành từ xa. c. Kỹ thuật lập bảng hỏi Một tập các câu hỏi viết được dùng để thu thập thông tin từ các cá nhân. Có thể sử dụng giấy hoặc dạng điện tử (ví dụ: dùng web). Kỹ thuật này thường dùng trong trường hợp: Số lượng lớn người sử dụng; Cần cả thông tin và ý kiến. Đây là kỹ thuật thông dụng với các hệ thống dành cho sử dụng bên ngoài tổ chức (khách hang, người bán hàng ). Các bước sử dụng bảng hỏi Chọn người tham dự 65
66. + Xác định người tham gia liên quan + Sử dụng kiểu lấy mẫu với số lượng người tham gia lớn Thiết kế câu hỏi + Lựa chọn câu hỏi cẩn thận + Loại bỏ các nhập nhằng Quản trị bảng hỏi + Làm việc để có được tỷ lệ trả lời cao + Cung cấp một sự khích lệ (VD: một cây bút miễn phí) Dõi theo sau bảng hỏi + Gửi các kết quả đến người tham dự + Gửi một lời cảm ơn. Để thiết kế tốt các bảng hỏi, nên bắt đầu với những câu hỏi không nặng nề và thú vị. Nhóm các mục thành các phần logic mạch lạc. Các mục không quan trọng để vào cuối. Không chèn lấn một trang với quá nhiều mục, tránh chữ viết tắt. Nên tránh các mục hoặc các điều khoản thiên vị hoặc gợi ý, đánh số câu hỏi để tránh nhầm lẫn. Cần kiểm tra trước để xác định câu hỏi khó hiểu, có thể cung cấp phướng án giấu tên người trả lời. d. Kỹ thuật nghiên cứu tài liệu Kỹ thuật này nhằm cung cấp những manh mối về hệ thống hiện tại, xem xét các tài liệu kỹ thuật có sẵn hay xem xét các tài liệu sử dụng điển hình như: Biểu mẫu, báo cáo, các hướng dẫn chính sách sử dụng. Lƣu ý: Mặc dù các vấn đề như mô hình hóa, làm bản mẫu là 2 vấn đề của phân tích và đặc tả yêu cầu. Vấn đề thẩm định, đánh giá yêu cầu, tư liệu yêu cầu cũng là các giai đoạn con của công nghệ phân tích và đặc tả yêu cầu. Nhưng do bố cục của phần 2 chương này quá dài, chúng ta tạm phân chia các vấn đề vừa nêu trên thành các mục riêng. Để tiện theo dõi đề nghị theo dõi lại các hình vẽ đã nêu ở đầu chương này. 3. Nguyên lý phân tích và mô hình hóa 66
67. Các mô tả yêu cầu trong giai đoạn xác định yêu cầu chỉ mô tả chủ yếu các thông tin liên quan đến việc thực hiện các nghiệp vụ trong thế giới thực chưa và chưa thể hiện rõ nét việc thực hiện các nghiệp vụ này trên máy tính. Mô tả thông qua các văn bản dễ gây ra nhầm lẫn và không trực quan. Ví dụ: Xét yêu cầu lập hóa đơn bán sách, yêu cầu này chỉ mô tả biểu mẫu về hóa đơn, qui định lập hóa đơn và chưa thể hiện cách thức lập hóa đơn trên máy tính như thế nào. Mục tiêu của việc mô hình hóa: Cho phép ta hiểu một cách chi tiết hơn về ngữ cảnh vấn đề cần giải quyết một cách trực quan và bản chất nhất (thông tin cốt lõi) yêu cầu. Kết quả của mô hình hóa nhằm cho một mô hình mô tả lại toàn bộ hoạt động của hệ thống thực. Mỗi phương pháp phân tích đưa ra một kiểu sơ đồ hay mô hình để xây dựng hệ thống. Kỹ thuật phân tích là cách tiến hành sao cho thu thập được những yêu cầu của người sử dụng từ đó trình bày lại nhu cầu đó trên mô hình, chi tiết hóa sơ đồ hay mô hình bằng đặc tả chức năng, đặc tả dữ liệu thông qua phân tích góc nhìn, phân tích đối tượng, phân tích dữ liệu thu thập được ở các bước trên. Trước khi đi vào tìm hiểu các phương pháp biểu diễn bằng mô hình, chúng ta hãy xem qua một số nguyên lý phân tích. 3.1. Nguyên lý mô hình hóa Trong giai đoạn phân tích yêu cầu, chúng ta cần xác định khách hàng và làm việc với họ để đưa ra yêu cầu mức sản phẩm. Lúc này cần xây dựng mô hình phân tích, các mô hình cần tập trung vào dữ liệu, xác định chức năng và nhằm biểu diễn hành vi của hệ thống. Nguyên lý phân tích 1 Mô hình miền dữ liệu nhằm: Xác định đối tượng dữ liệu; Mô tả thuộc tính của dữ liệu và thiết lập quan hệ dữ liệu. Nguyên lý phân tích 2 Bản chất của phần mềm là biến đổi thông tin, do đó, 67
68. • Mô hình chức năng nhằm: Xác định những chức năng biến đổi thông tin; ƒ Chỉ ra luồng dữ liệu đi qua hệ thống và biểu diễn những đối tượng tạo và tiêu thụ dữ liệu. Nguyên lý phân tích 3 • Mô hình hành vi được đưa ra để: Xác định những trạng thái của hệ thống và những sự kiện gây ra biến đổi trạng thái. Như vậy, các mô hình mô tả cho thông tin, chức năng và hành vi hệ thống cần phải được xây dựng. Miền thông tin của vấn đề phải được biểu diễn lại và hiểu rõ. Nguyên lý phân tích 4 (Phân tách mô hình) Trong phân tích cần tinh chế mô hình nhằm biểu diễn những mức trừu tượng thấp hơn, bao gồm: Tinh chế những đối tượng dữ liệu; Tạo hệ thống cấp bậc chức năng và biểu diễn hành vi ở các mức chi tiết khác nhau. Như vậy các mô hình (và vấn đề) phải được phân hoạch theo cách để lộ ra các chi tiết theo kiểu phân tầng (hay cấp bậc). Nguyên lý phân tích 5 (Sự thiết yếu) Tập trung vào những vấn đề thiết yếu và không quan tâm tới chi tiết thực thi. Do đó tiến trình phân tích phải đi từ thông tin bản chất hướng tới chi tiết cài đặt. 3.2. Mô hình hóa Mô hình hóa dữ liệu Mô hình hóa chức năng Mô hình hóa hành vi 68
69. Các mô hình được tạo ra trong khi phân tích yêu cầu đóng một số vai trò quan trọng: • Mô hình trợ giúp cho người phân tích trong việc hiểu về thông tin, chức năng và hành vi của hệ thống, do đó làm cho nhiệm vụ phân tích yêu cầu được dễ dàng và hệ thống hơn. • Mô hình trở thành tiêu điểm cho việc xem xét và do đó, trở thành phần mấu chốt cho việc xác định tính đầy đủ, nhất quán và chính xác của đặc tả. • Mô hình trở thành nền tảng cho thiết kế, cung cấp cho người thiết kế một cách biểu diễn chủ yếu về phần mềm có thể được “ánh xạ” vào hoàn cảnh cài đặt. Dưới đây là một số mô hình thường được dùng trong phân tích: a. Biểu đồ luồng dữ liệu Khi thông tin đi qua phần mềm nó bị thay đổi bởi một loạt các phép biến đổi. Biểu đồ luồng dữ liệu (Data Flow Diagram - DFD) là một kỹ thuật vẽ ra luồng dữ liệu di chuyển trong hệ thốngvà những phép biến đổi được áp dụng lên dữ liệu. Ký pháp cơ bản của biểu đồ luồng dữ liệu được minh họa trên hình sau. Hình 3.5: Ký pháp DFD. 4 phần tử chính của biểu đồ là: + Thực thể: tạo ra hoặc tiêu thụ thông tin, nằm bên ngoài biên giới của phạm vi thông tin hệ thống. + Chức năng xử lý: thực hiện chức năng nào đó, tiêu thụ và tạo ra thông tin, nằm bên trong phạm vi thông tin hệ thống. + Thông tin hay dữ liệu. + Kho dữ liệu: lưu trữ dữ liệu được sử dụng bởi nhiều chức năng xử lý. 69
70. Biểu đồ luồng dữ liệu có thể được dùng để biểu diễn cho một hệ thống hay phần mềm ở bất kì mức trừu tượng nào. Trong thực tế, DFD có thể được phân hoạch thành nhiều mức biểu diễn cho chi tiết chức năng và luồng thông tin ngày càng tăng. Do đó phương pháp dùng DFD còn được gọi là phân tích có cấu trúc. Một DFD mức 0, cũng còn được gọi là biểu đồ nền tảng hay biểu đồ ngữ cảnh hệ thống, biểu diễn cho toàn bộ phần tử phần mềm như một hình tròn với dữ liệu vào và ra được chỉ ra bởi các mũi tên tới và đi tương ứng. Một DFD mức 1 cụ thể hóa của DFD mức 0 và có thể chứa nhiều hình tròn (chức năng) với các mũi tên (luồng dữ liệu) nối lẫn nhau. Mỗi một trong các tiến trình được biểu diễn ở mức 1 đều là chức năng con của toàn bộ hệ thống được mô tả trong biểu đồ ngữ cảnh. Ví dụ: Dưới đây là một số biểu đồ DFD các mức của chương trình điều khiển các thiết bị báo động chống trộm bảo vệ nhà cửa. DFD mức ngữ cảnh (mức 0): nhận diện các thực thể và dữ liệu input, output. 70
71. b. Sơ đồ phân rã chức năng Sơ đồ phân rã chức năng (Function Decomposition Diagram – FDD) nhằm nêu lên các chức năng thông qua việc mô tả các tính chất của đầu vào và đầu ra: ƒ + Xác định phạm vi của hệ thống ƒ + Phân hoạch chức năng ƒ + Tạo nền tảng cho thiết kế kiến trúc hệ thống Ví dụ: 71