Bài giảng Kỹ nghệ phần mềm - Nguyễn Quốc Toản
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Kỹ nghệ phần mềm - Nguyễn Quốc Toản", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
Tài liệu đính kèm:
- bai_giang_ky_nghe_phan_mem_nguyen_quoc_toan.pdf
Nội dung text: Bài giảng Kỹ nghệ phần mềm - Nguyễn Quốc Toản
- Đại học quốc gia Hà Nội - Khoa công nghệ Bộ môn công nghệ phần mềm ___ PGS. Nguyễn Quốc Toản, PGS.TS. Nguyễn Văn Vỵ, PGS.TS.Vũ Đức Thi, TS. Lê văn Phùng Bài giảng Kỹ nghệ phần mềm (nhập môn) Hà Nội - 2000
- Kỹ nghệ phần mềm ___ Mở đầu Sau 20 năm phát triển, kỹ nghệ phần mềm (SE-Software Engineering) đến nay đ−ợc thừa nhận là một bộ môn chính thống nh−ng còn là một lĩnh vực tranh luận sôi nổi. Trong ngành công nghiệp: ng−ời lập trình → kỹ s− phần mềm. Kỹ nghệ phần mềm (hay còn gọi là công trình học phần mềm ) đ−ợc xem nh− là một tên gọi công việc. Các ph−ơng pháp, công cụ, thủ tục của SE đã đ−ợc chấp nhận và ứng dụng thành công trong rất nhiều lĩnh vực ứng dụng công nghiệp. Các nhà quản lý và chuyên gia công nghệ thông tin đều nhận ra nhu cầu về cách tiếp cận có nguyên tắc hơn tới việc phát triển phần mềm . Bản chất thực của cách tiếp cận SE vẫn còn ch−a đ−ợc thống nhất, còn nhiều ý kiến trái ng−ợc nhau. Ph−ơng pháp tiếp cận của ng−ời thực hành: theo sát các hoạt động tổng quát đã đ−ợc thực hiện bất kể tới mô hình SE đã đ−ợc chọn thay vì duy trì một quan điểm vòng đời chặt chẽ. Các chủ đề quan tâm: 1. Vấn đề quản lý dự án phần mềm (tiến trình phát triển dự án phần mềm và việc quản lý nó) 2. Phân tích hệ thống và yêu cầu phần mềm (các vấn đề cơ bản trong phân tích, ph−ơng pháp mô hình hoá yêu cầu, các kí pháp, ) 3. Thiết kế và cài đặt phần mềm (nhấn mạnh tới các định mức thiết kế cơ bản dẫn tới hệ thống chất l−ợng cao và các ph−ơng pháp thiết kế để chuyển một mô hình phân tích thành giải pháp phần mềm) 4. Đảm bảo, kiểm chứng và duy trì tính toàn vẹn phần mềm (nhấn mạnh vào các hoạt động đ−ợc ứng dụng để đảm bảo chất l−ợng trong suốt tiến trình phần mềm ) 5. Vai trò của tự động hoá (nhấn mạnh sự hỗ trợ của máy tính lên tiến trình phát triển phần mềm ) Quan tâm đến thiết kế : chủ đề 3 Quan tâm đến ph−ơng pháp: cả 5 chủ đề Quan tâm đến quản lý: chủ đề 1 và 4 Công trình học phần mềm không phải là chính việc sản sinh ra sản phẩm mà nó liên quan đến việc sản sinh ra sản phẩm một cách hiệu quả. Với những nguồn lực không hạn chế thì đa số các vấn đề phần mềm là giải quyết đ−ợc. Thử thách đối với kỹ s− phần mềm là tạo ra phần mềm chất l−ợng cao với hạn chế về nguồn lực và phải theo một lịch định tr−ớc. ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 1
- Kỹ nghệ phần mềm ___ Ch−ơng 1 Phần mềm và kỹ nghệ phần mềm 3 Ch−ơng II Đặc tả phần mềm 25 Ch−ơng III thiết kế phần mềm 52 h−ơng IV Lập trình hiệu quả 84 ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 2
- Kỹ nghệ phần mềm ___ Ch−ơng 1 Phần mềm và kỹ nghệ phần mềm I.1.Sự phát triển của phần mềm .1.1.1.Quá trình tiến hoá của phần mềm 1.1.2.Các thách thức đối với phần mềm máy tính 1.2.Phần mềm 1.2.1.Mô tả về phần mềm 1.2.2.Các đặc tr−ng phần mềm 1.2.3. Các thành phần của phần mềm 1.2 4 Việc ứng dụng phần mềm 1.3. Kỹ nghệ phần mềm 1.3.1. Định nghĩa 1.3.2. Mô hình Vòng đời cổ điển 1.3.3. Mô hình làm bản mẫu 1.3 4.Mô hình xoắn ốc 1.3.5. Kỹ thuật thế hệ thứ 4 1.3.6. Tổ hợp các khuôn cảnh 1.4. Các b−ớc tổng quát trong tiến trình kỹ nghệ phần mềm 1.4.1 Giai đoạn xác định 1.4.2. Giai đoạn phát triển 1.4.3. Giai đoạn bảo trì I.5.Đánh giá tổng quát về chất l−ợng hệ thống ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 3
- Kỹ nghệ phần mềm ___ Ch−ơng 1 Phần mềm và kỹ nghệ phần mềm 1980, trong tạp chí Business week, dòng tiêu đề "phần mềm - lực điều khiển mới hay phần mềm đã vào một thời đại" → đánh dấu chủ đề đáng quan tâm của các tạp chí → báo hiệu cho một cách hiểu mới về tầm quan trọng của phần mềm máy tính → đem đến những cơ hội và thách thức mới. Phần mềm (SW) bây giờ đã v−ợt trội hơn phần cứng (HW): điều mấu chốt cho sự thành công của nhiều hệ thống dựa trên máy tính Phần mềm -nhân tố đánh giá sự khác biệt, điều này thể hiện ở chỗ: . Tính đầy đủ và đúng thời hạn của thông tin do phần mềm cung cấp (và các CSDL liên quan) → khác biệt một công ty này với các đối thủ cạnh tranh . thiết kế và " tính thân thiện con ng−ời" của sản phẩm phần mềm cũng làm khác biệt nó với các sản phẩm cạnh tranh có cùng chức năng t−ơng tự khác. Sự thông minh và chức năng do phần mềm đ−ợc nhúng trong đó đ−a ra th−ờng làm khác biệt 2 sản phẩm tiêu thụ hay công nghiệp t−ơng tự nhau Nh− vậy, chính phần mềm tạo ra sự khác biệt đó I.1.Sự phát triển của phần mềm Thách thức tr−ớc những năm 1990: phát triển phần cứng nhằm giảm giá thành xử lý và l−u trữ dữ liệu. Ví dụ vào những năm 1980 tiến bộ trong vi điện tử: phát sinh năng lực tính toán mạnh, giá thành thấp đáng kể Thách thức trong những năm 1990: cải thiện chất l−ợng và giảm giá thành của các giải pháp dựa trên máy tính - giải pháp đ−ợc cài đặt bằng phần mềm Khả năng l−u trữ của phần cứng biểu thị cho tiềm năng tính toán. Còn phần mềm -một cơ chế giúp chúng ta chế ngự và khai thác tiềm năng này .1.1.1.Quá trình tiến hoá của phần mềm 1.Những năm đầu(từ 1950 đến 1960): Phần cứng thay đổi liên tục, phần lớn đ−ợc chuyên dụng cho ứng dụng đặc biệt. Phần mềm đ−ợc coi là nghệ thuật, ch−a có ph−ơng pháp hệ thống. Phát triển phần mềm ch−a đ−ợc quản lý Môi tr−ờng phần mềm có tính cá nhân→ thiết kế -tiến trình không t−ờng minh, th−ờng không có tài liệu. Kết quả: Học đ−ợc việc cài đặt hệ thống dựa trên máy tính, không học đ−ợc mấy về kỹ nghệ hệ thống máy tính 2.Thời kỳ trải rộng từ những năm 1960 đến cuối 1970: - Hệ thống đa lập trình và đa ng−ời sử dụng → khái niệm mới về t−ơng tác ng−ời máy. Kỹ thuật t−ơng tác mở ra thế giới mới cho các ứng dụng và mức độ mới tinh vi cho cả phần mềm và phần cứng ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 4
- Kỹ nghệ phần mềm ___ - Hệ thống thời gian thực: thu thập, phân tích và biến đổi dữ liệu từ nhiều nguồn khác nhau→kiểm soát đ−ợc các tiến trình và sản xuất ra cái ra trong phần nghìn giây thay vì nhiều phút - Tiến bộ l−u trữ trực tuyến→ thế hệ đầu tiên của hệ quản trị CSDL - Số l−ợng các hệ thống dựa trên máy tính phát triển → th− viện phần mềm mở rộng→ phát sinh số l−ợng lớn câu lệnh→ cần sửa chữa khi gặp lỗi, cần sửa đổi lại khi yêu cầu của ng−ời dùng thay đổi hay phải thích nghi với những phần cứng mới vừa mua→ bảo trì phần mềm . 3. Thời kỳ giữa những năm 1970 đến nay: - Hệ thống phân bố (bao gồm nhiều máy tính, mỗi máy thực hiện một chức năng t−ơng tranh và liên lạc với các máy khác) → tăng độ phức tạp - Mạng toàn cục và cục bộ, liên lạc số giải thông cao, tăng nhu cầu thâm nhập dữ liệu → yêu cầu lớn phát triển phần mềm - Tiến bộ lớn và sử dụng phổ cập các bộ vi xử lý (ô tô, robot, lò vi sóng, thiết bị chẩn đoán máu, ) máy tính cá nhân và các máy trạm để bàn - Chi phí phần mềm có khuynh h−ớng > chi phí mua máy tính 4. Thời kỳ sau 1990 (Thời kỳ thứ t− mới chỉ bắt đầu): - Kỹ nghệ h−ớng sự vật là cách tiếp cận mới đang nhanh chóng thay thế nhiều cách tiếp cận phát triển phần mềm truyền thống trong các lĩnh vực ứng dụng - Hệ chuyên gia và phần mềm trí tuệ nhân tạo: chuyển từ phòng thí nghiệm → thực tế - Phần mềm mạng nơ ron nhân tạo: mở ra khả năng nhận dạng và thực hiện khả năng xử lý thông tin kiểu con ng−ời 1.1.2.Các thách thức đối với phần mềm máy tính Các thách thức đối với phần mềm máy tính gia tăng vì những nguyên nhân sau: 1. Sự tinh vi của phần cứng đã v−ợt quá khả năng của chúng ta để xây dựng phần mềm đạt tới tiềm năng của phần cứng 2. Khả năng xây dựng các ch−ơng trình mới không thể giữ cùng nhịp với nhu cầu có các ch−ơng trình mới 3. Khả năng bảo trì các ch−ơng trình hiện có rất khó khăn vì thiết kế sơ sài, tài nguyên không thích hợp Tất cả các thách thức trên→ chấp nhận thực hành kỹ nghệ phần mềm 1.2.Phần mềm 1.2.1.Mô tả về phần mềm Việc mô tả phần mềm trong sách giáo khoa có 1 trong những dạng sau: -Các lệnh (ch−ơng trình máy tính) khi đ−ợc thực hiện thì đ−a ra hoạt động và kết quả mong muốn -Các cấu trúc dữ liệu làm cho ch−ơng trình thao tác thông tin thích hợp -Các tài liệu mô tả thao tác và cách dùng ch−ơng trình Nhận xét: ch−a đủ→ cần đ−a ra định nghĩa hình thức hơn ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 5
- Kỹ nghệ phần mềm ___ 1.2.2.Các đặc tr−ng phần mềm Phần mềm là phần tử hệ thống logic ch−a không phải là hệ thống vật lý. Do đó phần mềm có đặc tr−ng khác biệt đáng kể với các đậc tr−ng của phần cứng 1.Phần mềm đ−ợc phát triển hay đ−ợc kỹ nghệ hoá, nó không đ−ợc chế tạo theo nghĩa cổ điển: thiết kế chế tạo sản phẩm tốt HW: → → → chất l−ợng chất l−ợng thiết kế sửa đổi sản phẩm tốt SW: → → → chất l−ợng chất l−ợng Hai quá trình này phụ thuộc vào con ng−ời Chi phí phần mềm tập trung vào kỹ nghệ → khái niệm x−ởng phần mềm → khuyến cáo sử dụng công cụ tự động 2.Phần mềm không "hỏng đi" Phần mềm không cảm ứng đối với những khiếm khuyết môi tr−ờng vốn gây cho phần cứng bị mòn cũ đi chết yểu Tỷ lệ mòn cũ hỏng giữ tỷ lệ cho đến khi lạc hậu t t Đ−ờng cong hỏng hóc cho HW Đ−ờng cong hỏng hóc cho SW (lý t−ởng) Thực tế, phần mềm sẽ trải qua sự thay đổi (bảo trì). Khi thay đổi đ−ợc thực hiện có thể là một số khiếm khuyết mới sẽ đ−ợc đ−a vào, gây ra cho đ−ờng cong tỷ lệ hỏng hóc trở thành có đầu nhọn nh− trong hình vẽ d−ới đây. Tr−ớc khi đ−ờng cong đó có thể trở về tỷ lệ hỏng hóc ổn định ban đầu thì một thay đổi khác lại đ−ợc yêu cầu, lại gây ra đ−ờng cong phát sinh đỉnh nhọn một lần nữa. Dần dần, mức tỷ lệ hỏng hóc tối thiểu bắt đầu nâng lên- phần mềm bị thoái hoá do sự thay đổi. thay đổi Đ−ờng cong thực tế tỷ lệ hỏng Đ−ờng cong lý t−ởng thời gian Đ−ờng cong hỏng hóc thực tế của phần mềm Nhận xét: Đ−ờng cong lý t−ởng ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 6
- Kỹ nghệ phần mềm ___ Phần cứng hỏng có "vật t− thay thế", nh−ng không có phần mềm thay thế cho phần mềm . Mọi hỏng hóc phần mềm đều chỉ ra lỗi trong thiết kế hay trong tiến trình chuyển thiết kế thành mã máy thực hiện đ−ợc. Do đó, việc bảo trì phần mềm bao gồm độ phức tạp phụ thêm đáng kể so với bảo trì phần cứng. 3.Phần lớn phần mềm đều đ−ợc xây dựng theo đơn đặt hàng, chứ ít khi đ−ợc lắp ráp từ các thành phần có sẵn Cách thiết kế và xây dựng phần cứng điều khiển cho một sản phẩm dựa trên bộ vi xử lý: vẽ sơ đồ mạch số → thực hiện phân tích để đảm bảo chức năng đúng → phân loại các danh mục thành phần → gắn cho mỗi mạch tích hợp (th−ờng gọi là "IC" hay "chip") một số hiệu một chức năng đã định và hợp lệ, một giao diện đã xác định rõ, một tập các h−ớng dẫn tích hợp chuẩn hoá Phần mềm: -Không có danh mục các thành phần -Đặt hàng với đơn vị hoàn chỉnh, không phải là những thành phần có thể đ−ợc lắp ráp lại thành ch−ơng trình mới. 1.2.3. Các thành phần của phần mềm Phần mềm máy tính (gọi tắt là phần mềm ) là thông tin tồn tại d−ới 2 dạng cơ sở: thành phần máy không thực hiện đ−ợc và các thành phần máy thực hiện đ−ợc. ở đây chỉ xét những thành phần phần mềm trực tiếp đ−a tới các lệnh máy thực hiện đ−ợc Mọi thành phần phần mềm đều bao gồm một cấu hình Thành phần phần mềm đ−ợc tạo ra thông qua một loạt những hoạt động chuyển hoá (translation) yêu cầu của ng−ời dùng thành mã máy thực hiện đ−ợc: một mô hình yêu cầu (hay bản mẫu) → dịch → thiết kế → dịch→ dạng ngôn ngữ xác định cấu trúc dữ liệu, thuộc tính, thủ tục phần mềm, các yêu cầu liên quan → dịch → lệnh mã máy thực hiện đ−ợc Tính tái dụng là một đặc tr−ng quan trọng của thành phần phần mềm chất l−ợng cao, tức là thành phần cần đ−ợc thiết kế và cài đặt sao cho ng−ời ta có thể dùng lại chúng trong nhiêù ch−ơng trình khác nhau (th− viện ch−ơng trình con mẫu về khoa học) Chú ý: ngày nay đã mở rộng cách nhìn về việc dùng lại để bao hàm không chỉ các thuật toán mà còn cả cấu trúc dữ liệu. Ví dụ: các giao diện t−ơng tác th−ờng đ−ợc xây dựng bằng cách dùng các thành phần dùng lại có khả năng tạo ra cửa sổ đồ hoạ, menu kéo xuống và rất nhiều cơ chế t−ơng tác. Cấu trúc dữ liệu và chi tiết xử lý cần để xây đựng giao diện đ−ợc đặt bên trong các th− viện các thành phần dùng lại. Các thành phần phần mềm đ−ợc xây dựng bằng cách nào? Dùng ngôn ngữ lập trình với vốn từ vựng hạn chế, một văn phạm hoàn toàn xác định rõ cùng với các quy tắc thành lập chặt chẽ về cú pháp và ngữ nghĩa. Các thuộc tính này là điều chủ chốt trong việc dịch thành mã máy. Các dạng ngôn ngữ hiện dùng ngày nay là các ngôn ngữ mức máy, ngôn ngữ cấp cao và ngôn ngữ phi thủ tục. +Ngôn ngữ mức máy: là một biểu diễn ký hiệu cho tập lệnh của đơn vị xử lý trung tâm -Nếu phần mềm viết tốt, bảo trì đ−ợc, t− liệu tốt → ngôn ngữ máy giúp sử dụng bộ nhớ hiệu quả, tăng đ−ợc tốc độ thực hiện -Nếu phần mềm thiết kế tồi, ít tài liệu → ngôn ngữ máy trở thành cơn ác mộng +Ngôn ngữ cấp cao: Cho phép ng−ời phát triển phần mềm và ch−ơng trình đ−ợc độc lập với máy song từ vựng, văn phạm, cú pháp, ngữ nghĩa phức tạp hơn nhiều so với ngôn ngữ máy. ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 7
- Kỹ nghệ phần mềm ___ Trong hàng trăm ngôn ngữ lập trình đ−ợc dùng, phổ biến chỉ khoảng 10 loại: cobol, fortran, Pascal,C,Ada,C++, Pascal đối t−ợng, eiffei, các ngôn ngữ đặc thù (APL, LIST,OPS5, PROLOG và các ngôn ngữ mô tả cho mạng nơ ron nhân tạo Mã máy, hợp ngữ, ngôn n gữ lập trình cấp cao th−ờng còn đ−ợc coi nh− là "3 thế hệ đầu" của ngôn ngữ máy tính. Với những ngôn ngữ này, bản thân ng−ời lập trình phải quan tâm cả tới việc đặc tả cấu trúc thông tin lẫn điều khiển ch−ơng trình. Do đó các ngôn ngữ trong 3 thế hệ này còn đ−ợc gọi là các ngôn ngữ thủ tục +Ngôn ngữ phi thủ tục: Có trên một thập kỷ qua, thay vì phải yêu cầu ng−ời phát triển phần mềm cần xác định chi tiết thủ tục thì các ngôn ngữ phi thủ tục đ−a đến một ch−ơng trình bằng cách "xác định kết quả mong muốn thay vì xác định hành động cần để đạt đ−ợc kết quả đó". Phần mềm hỗ trợ sẽ dịch đặc tả thành ch−ơng trình máy thực hiện đ−ợc. 1.2.4.Việc ứng dụng phần mềm Phần mềm có thể đ−ợc áp dụng khi đã có một tập các b−ớc thủ tục (nh− một thuật toán) đã đ−ợc xác định tr−ớc (trừ phần mềm hệ chuyên gia và phần mềm mạng nơron) Nội dung thông tin và tính tất định là các nhân tố quan trọng trong việc xác định bản chất của ứng dụng phần mềm : -Nội dung thông tin nói tới ý nghĩa và hình dạng của thông tin vào và ra -Tính tất định thông tin nói tới việc tiên đoán tr−ớc trật tự và thời gian của thông tin Phân loại phần mềm ứng dụng (7 loại): 1. Phần mềm hệ thống: -Là một tập hợp các ch−ơng trình đ−ợc viết để phục vụ cho các ch−ơng trình khác -Xử lý cấu trúc thông tin phức tạp nh−ng xác định (trình biên dịch, trình soạn thảo, tiện ích quản lý tệp) -Đặc tr−ng bởi t−ơng tác chủ yếu với phần cứng máy tính -Phục vụ nhiều ng−ời dùng -Cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài 2. Phần mềm thời gian thực Phần mềm điều phối hoặc phân tích hoặc kiểm soát các sự kiện thế giới thực ngay khi chúng xuất hiện đ−ợc gọi là phần mềm thời gian thực. Phần mềm thời gian thực bao gồm các yếu tố: -Một thành phần thu thập dữ liệu để thu và định dạng thông tin từ ngoài -Một thành phần phân tích để biến đổi thông tin theo yêu cầu của ứng dụng -Một thành phần kiểm soát hoặc đ−a ra đáp ứng môi tr−ờng ngoài -Một thành phần điều phối để điều hoà các thành phần khác sao cho có thể duy trì việc đáp ứng thời gian thực. Hệ thống thời gian thực phải đáp ứng trong những ràng buộc thời gian chặt chẽ 3.Phần mềm nghiệp vụ Xử lý thông tin nghiệp vụ là lĩnh vực ứng dụng phần mềm lớn nhất Các hệ thống rời rạc: hệ thông tin quản lý Các ứng dụng phần mềm nghiệp vụ còn bao gồm cả tính toán t−ơng tác (nh− xử lý giao tác cho các điểm bán hàng) ngoài ứng dụng xử lý dữ liệu 4.Phần mềm khoa học và công nghệ -Đ−ợc đặc tr−ng bởi các thuật toán ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 8
- Kỹ nghệ phần mềm ___ -Trong ứng dụng mới, thiết kế có máy tính trợ giúp (CAD), có chú ý đến các đặc tr−ng thời gian thực và cả phần mềm hệ thống. 5. Phần mềm nhúng -Nằm trong bộ nhớ chỉ đọc và đ−ợc dùng để điều khiển các sản phẩm và hệ thống cho ng−ời dùng và thị tr−ờng công nghiệp -Có thể thực hiện các chức năng rất giới hạn và huyền bí (điều khiển bàn phím cho lò vi sóng) hay đ−a ra các khả năng điều khiển và vận hành (chức năng số hoá ở ô tô, kiểm soát xăng, biểu thị bảng đồng hồ, hệ thống phanh) 6.Phần mềm máy tính cá nhân -Bùng nổ trong hơn thập kỷ qua (xử lý văn bản, trang tính, đồ hoạ, quản trị CSDL) -Tiếp tục biểu thị thiết kế giao diện ng−ời-máy: đ−ợc cải tiến nhiều nhất. 7.Phần mềm trí tuệ nhân tạo -Dùng các thuật toán phi số để giải quyết các vấn đề phức tạp mà tính toán hay phân tích trực tiếp không quản lý nổi -Hoạt động mạnh nhất là hệ chuyên gia (hệ cơ sở tri thức) -Lĩnh vực nhận dạng (hình ảnh và tiếng nói) -Chứng minh định lý và chơi trò chơi -Phát triển mạng nơ ron nhân tạo: mô phỏng cấu trúc của việc xử lý trong bộ óc. 1.3. Kỹ nghệ phần mềm 1.3.1. Định nghĩa Fritz Bauer nêu ra định nghĩa ban đầu về kỹ nghệ phần mềm : Kỹ nghệ phần mềm là việc thiết lập và sử dụng các nguyên lý công nghệ đúng đắn để thu đ−ợc phần mềm một cách kinh tế vừa tin cậy vừa làm việc hiệu quả trên các máy thực Các định nghĩa về sau đều nhấn mạnh vào yêu cầu về một kỷ luật công nghệ trong việc phát triển phần mềm Kỹ nghệ phần mềm - sự phát triển của kỹ nghệ phần cứng và hệ thống. Nó bao gồm một tập các b−ớc chứa đựng 3 yếu tố chủ chốt: - Ph−ơng pháp -Công cụ -Thủ tục Các yếu tố này giúp ng−ời quản lý kiểm soát đ−ợc tiến trình phát triển phần mềm và cung cấp cho ng−ời kỹ s− phần mềm một nền tảng để xây dựng phần mềm chất l−ợng cao theo một cách thức hiệu quả 1.Các ph−ơng pháp (đ−a ra các "cách làm" về mặt kỹ thuật để xây dựng phần mềm ): Các ph−ơng pháp bao hàm trong nhiều nhiệm vụ: lập kế hoạch, −ớc l−ợng dự án, phân tích yêu cầu hệ thống và phần mềm , thiết kế cấu trúc dữ liệu, kiến trúc ch−ơng trình và thủ tục thuật toán, mã hoá kiểm thử và bảo trì Các ph−ơng pháp cho kỹ nghệ phần mềm th−ờng đ−a ra các ký pháp đồ hoạ hay h−ớng ngôn ngữ đặc biệt, đ−a ra một tập các tiêu chuẩn về chất l−ợng sản phẩm phần mềm. 2.Các công cụ (cung cấp sự hỗ trợ tự động hay bán tự động cho từng ph−ơng pháp): Khi các công cụ đ−ợc tích hợp đến mức các thông tin do chúng tạo ra có thể đ−ợc dùng cho các công cụ khác thì hệ thống hỗ trợ cho việc phát triển phần mềm đã đ−ợc thiết lập và còn đ−ợc gọi là kỹ nghệ phần mềm có máy tính hỗ trợ (CASE) ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 9
- Kỹ nghệ phần mềm ___ 3.Các thủ tục (chất keo dán các ph−ơng pháp và công cụ lại với nhau và làm cho chúng đ−ợc sử dụng hợp lý và đúng hạn trong quá trình phát triển phần mềm): Thủ tục: -Xác định ra trình tự các ph−ơng pháp sẽ đ−ợc áp dụng, -Tạo sản phẩm cần bàn giao (tài liệu báo cáo, bản mẫu, ) cần cho việc kiểm soát để đảm bảo chất l−ợng và điều hoà thay đổi, -Xác định những cột mốc để cho ng−ời quản lý phần mềm nắm đ−ợc tiến độ. Nh− vậy, kỹ nghệ phần mềm bao gồm một tập các b−ớc bao hàm cả ph−ơng pháp, công cụ và thủ tục đã đ−ợc xác định ở trên. Các b−ớc này th−ờng đ−ợc gọi là các khuôn cảnh (paradigm) kỹ nghệ phần mềm . Mỗi b−ớc trong kỹ nghệ phần mềm đ−ợc lựa chọn dựa trên bản chất của dự án, dựa vào ph−ơng pháp và công cụ sử dụng, vào cách kiểm soát, cách bàn giao. Sau đây, chúng ta sẽ xét tới 4 cách tiếp cận cơ bản trong tiến trình phát triển phần mềm: 1.3.2. Mô hình Vòng đời cổ điển (cách tiếp cận 1) Kỹ nghệ phần mềm đ−ợc minh hoạ theo khuôn cảnh vòng đời cổ điển. Mô hình vòng đời cổ điển đôi khi còn đ−ợc gọi là mô hình thác n−ớc. Khuôn cảnh vòng đời yêu cầu tiếp cận một cách hệ thống, tuần tự tới việc phát triển phần mềm, bắt đầu ở mức hệ thống và tiến dần xuống phân tích, thiết kế, mã hoá, kiểm thử và bảo trì. Nh− vậy khuôn cảnh vòng đời bao gồm các hoạt động trong mô hình thác n−ớc sau: Kỹ nghệ hệ thống Phân tích & định rõ yêu cầu Thiết kế hệ thống & phần mềm Mã hoá Kiểm thử đơn vị, tích hợp & hệ thống Vận hành và Bảo trì 1.Kỹ nghệ và phân tích hệ thống ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 10
- Kỹ nghệ phần mềm ___ Vì phần mềm bao giờ cũng là một phần tử của hệ thống lớn hơn → bắt đầu từ việc thiết lập yêu cầu cho mọi phần tử của hệ thống → cấp phát một tập con các yêu cầu đó cho phần mềm Kỹ nghệ và phân tích hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống với một l−ợng nhỏ thiết kế và phân tích mức đỉnh 2. Phân tích yêu cầu phần mềm -Tiến trình thu thập yêu cầu đ−ợc tập trung và làm sạch đặc biệt vào phần mềm -Tìm hiểu lĩnh vực thông tin đối với phần mềm, các chức năng cần có, hiệu năng và giao diện -Lập t− liệu về yêu cầu cho hệ thống và phần mềm → khách hàng duyệt lại 3. Thiết kế -Tiến trình nhiều b−ớc, tập trung vào 4 thuộc tính phân biệt của ch−ơng trình: +Cấu trúc dữ liệu +Kiến trúc phần mềm +Chi tiết thủ tục +Đặc tr−ng giao diện -Chuyển hoá các yêu cầu thành mô tả phần mềm tr−ớc khi mã hoá -Lập t− liệu thiết kế (một phần của cấu hình phần mềm ) 4.Mã hoá -Dịch thiết kế thành dạng mã máy đọc đ−ợc 5. Kiểm thử -Việc kiểm thử bắt đầu sau khi đã sinh ra mã -Tiến trình kiểm thử tập trung vào phần logic bên trong ch−ơng trình đảm bảo tất cả các câu lệnh đều đ−ợc kiểm thử. Về phần chức năng bên ngoài thì đảm bảo rằng việc kiểm thử phát hiện ra lỗi và đảm bảo những cái vào xác định sẽ tạo ra kết quả thực tế thống nhất với kết quả muốn có. 6.Bảo trì Phần mềm chắc chắn có những thay đổi sau khi đ−ợc bàn giao cho khách hàng (trừ phần mềm nhúng) Do lỗi hoặc thích ứng với thay đổi trong môi tr−ờng bên ngoài (hệ điều hành mới, thiết bị ngoại vi mới) hoặc yêu cầu nâng cao chức năng hay hiệu năng → bảo trì Bảo trì áp dụng lại các b−ớc vòng đời cho ch−ơng trình hiện tại ( không phải mới) Nhận xét: -Vòng đời cổ điển là khuôn cảnh cũ nhất và đ−ợc sử dụng rộng rãi nhất cho kỹ nghệ phần mềm -Các dự án thực hiếm khi tuân theo dòng chảy tuần tự. Việc lập bao giờ cũng xuất hiện và gây ra các vấn đề khi áp dụng khuôn cảnh này -Khách hàng khó phát biểu hết yêu cầu t−ờng minh của dự án → dễ có bất trắc -Khách hàng phải kiên nhẫn. ở cuối thời gian dự án mới có bản ch−ơng trình làm việc đ−ợc. Nếu ch−ơng trình gặp lỗi → thảm hoạ -Có vị trí quan trọng và xác định trong công việc và kỹ nghệ phần mềm: đ−a ra các ph−ơng pháp khoa học, đ−a ra các b−ớc tổng quát áp dụng đ−ợc cho mọi khuôn cảnh kỹ nghệ phần mềm → còn là mô hình thủ tục đ−ợc sử dụng rộng rãi -Còn điểm yếu nh−ng vẫn tốt hơn đáng kể so với cách tiếp cận ngẫu nhiên ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 11
- Kỹ nghệ phần mềm ___ 1 3.3. Mô hình làm bản mẫu (cách tiếp cận 2) 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: -Khách hàng xác định đ−ợc mục tiêu tổng quát cho phần mềm, 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ó Làm bản mẫu là một tiến trình giúp ng−ời phát triển có khả năng tạo ra một mô hình cho phần mềm cần xây dựng. Mô hình có thể lấy một trong 3 dạng: 1.Bản mẫu trên giấy hay trên PC mô tả giao diện ng−ời-máy d−ới dạng làm cho ng−ời dùng hiểu đ−ợc cách các t−ơng tác xuất hiện 2.Bản mẫu làm việc cài đặt một tập con chức năng phần mềm mong muốn 3.Một ch−ơng trình mà có thực hiện một phần hay tất cả chức năng mong muốn nh−ng cần cải tiến thêm các tính năng khác tuỳ theo khả năng phát triển . Dãy các sự kiện của khuôn cảnh làm bản mẫu đ−ợc minh hoạ trong hình sau: Bắt đầu → Tập hợp yêu cầu và làm mịn→ xác định mục tiêu tổng thể, khảo sát thêm để định rõ thiết kế Kết Sản phẩm yêu cầu nhanh thúc (input, output) → (vi chỉnh Y/C) Xây dựng Làm mịn bản mãu bản mãu Đánh giá của khách hàng về bản mãu giống nh− mọi cách tiếp cận tới việc phát triển phần mềm, việc làm bản mẫu với việc thu thập yêu cầu. 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 nào đã biết, miền nào cần khảo sát thêm. Rồi đến việc thiết kế nhanh. 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 (cách đ−a vào và định dạng đ−a ra). Thiết kế nhanh → xây dựng một bản mẫu → ng−ời dùng đánh giá → làm mịn các yêu cầu cho phần mềm. Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu đ−ợc “vi chỉnh” thoả mãn yêu cầu của khách, đồng thời giúp ng−ời phát triển hiểu kỹ hơn cần phải thực hiện nhu cầu nào. ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 12
- Kỹ nghệ phần mềm ___ 1.3.4.Mô hình xoắn ốc (cách tiếp cận 3) -Bao gồm các tính năng tốt nhất của cả vòng đời cổ điển và làm bản mẫu + phân tích rủi ro -Xác định bởi 4 hoạt động chính: 1. Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc 2. Phân tích rủi ro: phân tích các ph−ơng án và xác định/ giải quyết rủi ro 3. Kỹ nghệ: phát triển sản phẩm “mức tiếp theo” 4. Đánh giá của khách hàng: khẳng định kết quả của kỹ nghệ -Với mỗi lần lặp xung quanh xoắn ốc (bắt đầu từ tâm), xác định thêm các phiên bản đ−ợc hoàn thiện dần. Nếu phân tích rủi ro chỉ ra rằng không chắc chắn trong các yêu cầu thì việc làm bản mẫu có thể đ−ợc sử dụng trong góc phần t− kỹ nghệ; các mô hình và các mô phỏng khác cũng đ−ợc dùng để làm rõ hơn vấn đề và làm mịn yêu cầu Khách đ−a ra những gợi ý thay đổi→vòng xoáy mới. Tại mỗi vòng xung quanh xoắn ốc, cao điểm của việc phân tích rủi ro là quyết định ”tiến hành hay không tiến hành”. Nếu rủi ro quá lớn thì có thể đình chỉ dự án Mọi mạch đi xung quanh xoắn ốc đều đòi hỏi kỹ nghệ (góc đông-nam) có thể đ−ợc thực hiện bằng cách tiếp cận vòng đời và làm bản mẫu. Tất nhiên số các hoạt động phát triển phải tăng lên khi hoạt động chuyển xa hơn ra khỏi trung tâm vòng xoáy ốc Nhận xét: -Khuôn cảnh mô hình xoắn ốc đối với kỹ nghệ phần mềm hiện tại là cách tiếp cận thực tế nhất đến việc phát triển cho các hệ thống và phần mềm quy mô lớn. Trong đó ng−ời ta dùng cách làm bản mẫu nh− một cơ chế làm giảm bớt rủi ro. -Mô hình này t−ơng đối mới và còn ch−a đ−ợc sử dụng rộng rãi nh− vòng đời/ làm bản mẫu tập hợp yêu phân tích rủi cầu ban đầu ro dựa trên và kế hoạch yêu cầu ban dự án đầu kế hoạch phân tích rủi ro phân tích rủi ro dựa dựa trên ý kế hoạch trên phản ứng của kiến của khách hàng khách hàng Quyết định có tiếp tục hay không ? (cao điểm của việc phân tích rủi ro) đánh giá của khách H−ớng tới hệ thống hàng Đánhgiácủakhách hoàn chỉnh kỹ nghệ bản mẫu ban đầu bản mẫu tiếp theo Cách tiếp cận thực tế nhất cho việc phát triển các hệ thống và phần mềm có quy mô lớn 1.3.5. Kỹ thuật thế hệ thứ 4 (cách tiếp cận 4) Thuật ngữ “kỹ thuật thứ 4” (4GT) bao gồm một phạm vi rộng các công cụ phần mềm có một điểm chung: ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 13
- Kỹ nghệ phần mềm ___ -Mỗi công cụ đều cho phép ng−ời phát triển phần mềm xác định một số đặc tr−ng của phần mềm ở mức cao. Công cụ đó tự động sinh ra mã ch−ơng trình gốc theo nhu cầu của ng−ời phát triển. Khuôn cảnh 4GT tập trung vào khả năng xác định phần mềm ở mức độ gần với ngôn ngữ tự nhiên hay dùng một ký pháp ứng với chức năng. Môi tr−ờng phát triển phần mềm hỗ trợ cho khuôn cảnh 4GT bao gồm một số hoặc tất cả các công cụ sau: -Ngôn ngữ phi thủ tục để truy vấn CSDL -Bộ sinh báo cáo -Bộ thao tác dữ liệu -Bộ t−ơng tác và xác định màn hình -Bộ sinh ch−ơng trình/mã (code generation) -Khả năng đồ hoạ mức cao -Khả năng làm trang tính Khuôn cảnh 4GT cho kỹ nghệ phần mềm đ−ợc thể hiện trên sơ đồ: Tập hợp yêu cầu Chiến l−ợc thiết kế Cài đặt sử dụng Kiểm thử Nhận xét: -Việc dùng khuôn cảnh 4GT còn nhiều tranh cãi: +Ng−ời ủng hộ: cho rằng 4GT làm giảm đáng kể thời gian phát triển phần mềm, tăng hiệu suất của ng−ời phát triển phần mềm +Ng−ời phản đối: cho rằng 4GT không phải tất cả đều dễ dàng hơn các ngôn ngữ lập trình, các ch−ơng trình gốc do các công cụ này tạo ra là “không hiệu quả” và rằng việc bảo trì các hệ thống phần mềm lớn hơn đ−ợc phát triển bằng cách dùng 4GT sẽ sinh ra nhiều vấn đề mới. -Đối với CSDL lớn, 4GT chỉ mới giới hạn vào các ứng dụng hệ thông tin nghiệp vụ, đặc biệt, việc phân tích thông tin và làm báo cáo (nhân tố chủ chốt cho các CSDL lớn). -Đối với ứng dụng vừa và nhỏ, thời gian thu thập dữ liệu sơ bộ cần để tạo phần mềm đ−ợc giảm đáng kể. Khối l−ợng thiết kế cho các ứng dụng nhỏ cũng đ−ợc rút bớt -Để phát triển phần mềm lớn đòi hỏi tập trung nhiều vào phân tích, thiết kế và kiểm thử để đạt tới việc tiết kiệm thời gian là chủ yếu. ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 14
- Kỹ nghệ phần mềm ___ -Các kỹ thuật thế hệ 4 đã trở thành phần quan trọng của việc phát triển phần mềm trong lĩnh vực ứng dụng hệ thông tin. Bản chất thay đổi của sự phát triển phần mềm đ−ợc thể hiện nh− sau: áp dụng các kỹ thuật thế hệ 4 Nhu Nhu cầu trung bình cầu phần mềm 1970 1980 1990 1.3.6. Tổ hợp các khuôn cảnh Bất kỳ một trong các khuôn cảnh cũng đều là có thể dùng làm nền tảng để tích hợp các khuôn cảnh khác Tập hợp các yêu cầu ban đầu (xác định các mục tiêu, các ph−ơng án, các ràng buộc) phân tích yêu cầu làm b ản mẫu 4GT Mô hình xoáy ốc thiết kế 4GT Bản mẫu: vòng thứ n Mã hoá Mô hình: vòng thứ n 4GT Kiểm chứng hệ thống hoạt động Sơ đồ tổ hợp các khuôn cảnh Bảo trì Trong mọi tr−ờng hợp, công việc bắt đầu: xác định mục tiêu, ph−ơng án, ràng buộc (thu thập yêu cầu sơ bộ). Từ điểm này, bất kỳ một con đ−ờng nào rẽ nhánh đều có thể chọn. Ví dụ: đ−ờng bên trái (vòng đời cổ điển). Nếu yêu cầu còn ch−a đ−ợc chắc chắn thì có thể sử dụng bản mẫu để xác định yêu cầu đầy đủ hơn. Bằng cách dùng bản mẫu nh− một bản h−ớng dẫn, ng−ời phát triển có thể trở lại vòng đời cổ điển (thiết kế, mã hoá, kiểm thử). Theo một cách khác, bản mẫu có thể tiến hoá thành hệ thống sản xuất, quay trở về khuôn cảnh vòng đời để kiểm thử. Các kỹ thuật thế hệ 4 đ−ợc dùng để cài đặt bản mẫu hay cài đặt hệ thống sản xuất trong b−ớc mã hoá của vòng đơì. 4GT có thể đ−ợc dùng kèm với mô hình xoáy ốc cho các b−ớc làm bản mẫu hay mã hoá ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 15
- Kỹ nghệ phần mềm ___ Chú ý: Không nên cứng nhắc về việc chọn khuôn cảnh cho kỹ nghệ phần mềm. Dựa vào bản chất của ứng dụng mà ấn định ra cách tiếp cận cần đ−ợc chọn. Bằng cách tổ hợp các cách tiếp cận thì ích lợi một tổng thể sẽ còn lớn hơn là tổng của từng thành phần. 1.4. Các b−ớc tổng quát trong tiến trình kỹ nghệ phần mềm Tiến trình phát triển kỹ nghệ phần mềm chứa 3 giai đoạn chính: -Xác định (trọng tâm là phân tích và xác định yêu cầu phần mềm ) -Phát triển (cấu trúc dữ liệu , kiến trúc phần mềm , thủ tục thuật toán, giao diện) -Bảo trì (sửa lỗi, thích nghi, nâng cao) trong mọi miền ứng dụng, mọi cỡ dự án, mọi độ phức tạp. 1.4.1.Giai đoạn xác định +Tập trung vào cái gì? -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ó -Tiêu chuẩn hợp lệ nào cần có -Yêu cầu chủ chốt của hệ thống và phần mềm +Các ph−ơng pháp: Các ph−ơng pháp thay đổi tuỳ theo khuôn cảnh kỹ nghệ phần mềm (hay tổ hợp các khuôn cảnh) đ−ợc áp dụng, song tối thiểu cần có 3 b−ớc riêng d−ới dạng: - Phân tích hệ thống : Đã đ−ợc mô tả trong vòng đời cổ điển Xác định vai trò của từng phần tử trong hệ thống dựa trên máy tính Vạch ra vai trò mà phần mềm giữ - Lập kế hoạch dự án phần mềm : Xác định nhiệm vụ, công việc Lập lịch - Phân tích yêu cầu : Xác định phạm vi cho phần mềm Xác định chi tiết lĩnh vực thông tin và chức năng phần mềm phải đảm nhận tr−ớc khi sang giai đoạn phát triển. • Hệ thống máy tính bao gồm 3 phần: 1. Các máy tính: máy chủ, máy trạm, máy đơn lẻ, các trang thiết bị mạng, hỗ trợ mạng và truyền thông 2. phần mềm hệ thống : hệ điều hành mạng, trạm, các ch−ơng trình dịch, các ngôn ngữ lập trình, các hệ quản trị dữ liệu 3. Các phần mềm ứng dụng: giải quyết một lớp bài toán cụ thể nào đó +Các b−ớc tổng quát cần thực hiện : ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 16
- Kỹ nghệ phần mềm ___ tính khả thi đảm bảo chức năng lập kế phân tích & tính hợp lệ phần mềm hoạch dự duyệt xác định yêu duyệt án phần xét cầu phần xét mềm mềm hay bản mẫu Đặc tả kế hoạch dự yêu cầu án (đ−ợc cấp bản quản lý dự án mẫu xét duyệt) tài liệu bàn giao • .Lập kế hoạch phần mềm (b−ớc khởi đầu): Cần: Xây dựng ra 1 mô tả vắn tắt về phạm vi hoạt động của phần mềm Phân tích rủi ro Dự kiến tài nguyên cần cho việc xây dựng phần mềm Thiết lập các −ớc l−ợng chi phí và lịch biểu Mục tiêu: -Đ−a ra một chỉ dẫn sơ bộ về tính khả thi của dự án với các ràng buộc về chi phí và lịch biểu mà có thể thiết lập tr−ớc -Cần tạo ra đ−ợc bản kế hoạch dự án phần mềm và đ−ợc cấp quản lý dự án xét duyệt • Phân tích và xác định yêu cầu phần mềm : +Xác định chi tiết phần tử hệ thống đ−ợc cấp phát cho phần mềm +Có 2 cách phân tích và xác định yêu cầu : -Phân tích lĩnh vực thông tin hình thức: sử dụng mô hình luồng và cấu trúc thông tin → mở rộng để trở thành đặc tả phần mềm -Xây dựng bản mẫu phần mềm + khách đánh giá →củng cố yêu cầu / giới hạn tài nguyên → dịch thành các đặc tr−ng thiết kế phần mềm +Phân tích tổng thể phần mềm → xác định ra những tiêu chuẩn hợp lệ → phục vụ kế hoạch kiểm thử → tỏ rằng các yêu cầu đ−ợc đáp ứng + Do cả ng−ời xây dựng phần mềm lẫn khách hàng tiến hành • .Bản đặc tả yêu cầu phần mềm : -là tài liệu bàn giao, đ−ợc tạo ra do kết quả của b−ớc phân tích yêu cầu và xác định phần mềm -thể hiện đỉnh điểm kết quả cuộc họp xét duyệt kỹ thuật giữa khách hàng và ng−ời phát triển phần mềm • Kế hoạch dự án phần mềm -Hình thành khi các yêu cầu (chấp nhận đ−ợc) đã đ−ợc xác định -Là cơ sở để đánh giá lại tính đúng đắn -Là tài liệu bàn giao của giai đoạn xác định cho giai đoạn tiếp theo 1.4.2. Giai đoạn phát triển ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 17
- Kỹ nghệ phần mềm ___ +Tập trung vào thế nào? Khi xác định, ng−ời phát triển phần mềm cố gắng xác định cách cấu trúc dữ liệu và kiến trúc phần mềm cần đ−ợc thiết kế, cách các chi tiết thủ tục đ−ợc cài đặt, cách dịch thiết kế thành ngôn ngữ lập trình, cách thực hiện kiểm thử + Ph−ơng pháp áp dụng: thay đổi nh−ng có 3 b−ớc đặc thù bao giờ cũng xuất hiện d−ới dạng: 1.Thiết kế phần mềm: thiết kế việc chuyển hoá các yêu cầu về phần mềm → tập các biểu diễn (dựa trên đồ hoạ, bảng, hay ngôn ngữ) +mô tả cấu trúc dữ liệu , +kiến trúc phần mềm +mô tả thủ tục thuật toán, +đặc tr−ng giao diện 2.Mã hoá: các biểu diễn thiết kế dịch thành 1 ngôn ngữ nhân tạo → kết quả là các lệnh thực hiện đ−ợc trên máy tính 3.Kiểm thử phần mềm : phát hiện khiếm khuyết khi vận hành, trong logic và trong cài đặt +Các b−ớc tổng quát cần đ−ợc thực hiện : Đây là giai đoạn xây dựng hoặc triển khai việc chuyển hoá các yêu cầu thành phần tử hệ thống vận hành mà ta quen gọi là phần mềm ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 18
- Kỹ nghệ phần mềm ___ thiết kế dữ thiết lập Kiểm liệu và duyệt kế thủ duyệt trình duyệt thử (đơn vị, tích gỡ lỗi kiến trúc xét tục xét xét hợp và hợp lệ) Đặc tả Đặc tả Kế hoạch, thiết kế thủ tục, thiết kế bản chi tiết kết quả sơ bộ mẫu mã gốc kiểm thử ch−ơng trình tài liệu bàn tài liệu bàn giao giao • B−ớc đầu cần hoàn thành thiết kế : -Mô tả về thiết kế kiến trúc và dữ liệu (tức là xây dựng một kiến trúc modul xác định giao diện, thiết lập cấu trúc dữ liệu, các tiêu chí định giá chất l−ợng) -Thiết kế sơ bộ: xét duyệt tính đầy đủ và khả năng theo dõi các yêu cầu phần mềm -Đặc tả thiết kế là bản thảo sơ bộ đ−ợc bàn giao và trở thành một phần của cấu hình phần mềm • Thiết kế thủ tục: -Xét thủ tục cuả từng thành phần modul của thiết kế -Các mô tả thủ tục chi tiết đ−ợc bổ sung vào bản đặc tả thiết kế • Mã hoá: dùng ngôn ngữ lập trình thích hợp/ công cụ CASE -Đ−ợc đánh giá là kết quả của việc thiết kế tốt -Bản in ch−ơng trình ngôn n gữ gốc cho từng modul thành phần phần mềm là cấu hình bàn giao • Hoạt động kiểm chứng và làm hợp lệ: -Kiểm thử hiệu suất chức năng của từng modul -Kiểm thử tích hợp chức năng và giao diện -Kiểm thử tính hợp lệ (xác nhận mọi yêu cầu đã đ−ợc đáp ứng ch−a) Sau từng b−ớc có thể tiến hành gỡ lỗi-chẩn đoán-sửa lỗi • Kế hoạch và thủ tục kiểm thử: xây dựng cho từng b−ớc kiểm thử 1.4.3. Giai đoạn bảo trì Giai đoạn bảo trì tập trung vào những thay đổi. 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 hoá và sự nâng cấp 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 trong hoàn cảnh phần mềm đã có. +Có 3 kiểu thay đổi gặp phải trong giai đoạn bảo trì: 1.Sửa đổi: thay đổi phần mềm để khắc phục khiếm khuyết 2.Thích nghi: môi tr−ờng ban đầu thay đổi (CPU, hệ điều hành, ngoại vi) để phát triển phần mềm → 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. ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 19
- Kỹ nghệ phần mềm ___ 3.Nâng cao: chức năng phụ phát sinh→ 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ó +Các b−ớc tổng quát cần thực hiện : Sai sót có thể gây ra việc trở lại các b−ớc tr−ớc Kiểm thử phát hành Bảo trì (đơn vị, Gỡ lỗi và phân duyệt (sửa đổi, duyệt tích hợp phối xét thích nghi xét và hợp lệ) môi tr−ờng, nâng cao) Tài liệu Tài liệu Kế hoạch, ng−ời đã sửa thủ tục và Ch−ơng dùng kết quả trình vận mã gốc việc kiểm hành ch−ơng chứng tài liệu trình bàn giao tài liệu bàn giao tài liệu tài liệu bàn giao bàn giao Đây là giai đoạn kiểm chứng, bàn giao và bảo trì: cần tìm ra tối đa số lỗi tr−ớc khi bàn giao sản phẩm cho khách hàng, chuẩn bị phần mềm để bàn giao, bảo trì phần mềm thông qua cuộc đời có ích của nó. • Tr−ớc khi bàn giao: cần tiến hành một loạt hoạt động đảm bảo chất l−ợng, chú ý các tài liệu bàn giao có chứa danh mục, cơ chế kiểm soát, cấu hình thích hợp • Sau khi bàn giao: Bảo trì- sửa lỗi, thích nghi môi tr−ờng và nâng cao chức năng. Những thay đổi về phần mềm bao gồm không chỉ có mã máy mà còn phải có toàn bộ cấu hình (nh− mọi ch−ơng trình, dữ liệu, t− liệu đã đ−ợc phát triển trong các giai đoạn xác định và xây dựng) Nhận xét: -Trong các khuôn cảnh vòng đời cổ điển và mô hình xoáy trôn ốc: các giai đoạn và các b−ớc đ−ợc mô tả đều đ−ợc xác định một cách t−ờng minh -Trong các khuôn cảnh làm bản mẫu và 4GT: một số b−ớc đ−ợc nêu ra nh−ng không đ−ợc xác định t−ờng minh. Cách tiếp cận tới từng b−ớc có thể biến động từ khuôn cảnh nọ sang khuôn cảnh kia, nh−ng toàn bộ cách tiếp cận yêu cầu bao gồm việc xác định, phát triển và bảo trì vẫn không thay đổi. -Có thể tiến hành từng giai đoạn theo kỉ luật và ph−ơng pháp đã đ−ợc xác định rõ hoặc cũng có thể làm lộn xộn qua mỗi b−ớc một cách ngẫu nhiên. Từ đây, chúng ta quan tâm đến cách tiếp cận tới việc phát triển phần mềm nhấn mạnh vào kỷ luật và ph−ơng pháp đã đ−ợc xác định rõ - một cách tiếp cận quen gọi là kỹ nghệ phần mềm -Ng−ời ta có thể chia việc phát triển phần mềm bao gồm 4 pha: +Phân tích và xác định yêu cầu +Thiết kế hệ thống và thiết kế phần mềm +Thực hiện và thử nghiệm các đơn vị của phần mềm +Tích hợp và thử nghiệm hệ thống ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 20
- Kỹ nghệ phần mềm ___ Khi đó vòng đời phần mềm đ−ợc biểu diễn theo 5 giai đoạn: 1.Giai đoạn phân tích và xác định yêu cầu 2.Giai đoạn thiết kế hệ thống và thiết kế phần mềm 3.Giai đoạn thực hiện và thử nghiệm các đơn vị của phần mềm 4.Giai đoạn tích hợp và thử nghiệm hệ thống 5.Giai đoạn vận hành và bảo trì -Mô hình quá trình phần mềm: tạo nguyên mẫu (phát triển một hệ để cho ng−ời dùng thực nghiệm, rồi thiết lập các yêu cầu mới, tạo nguyên mẫu mới cho tới khi sản phẩm đạt yêu cầu) là gần giống nh− mô hình thăm dò (phát triển càng nhanh càng tốt một hệ thống rồi cải biên hệ thống đó cho tới khi nó thực hiện đ−ợc những yêu cầu) Trong một số tr−ờng hợp riêng biệt, mô hình quá trình phần mềm có thể theo kiểu tập hợp các thành phần dùng lại đ−ợc để xây dựng phần mềm thoả mãn các yêu cầu. -Bên cạnh mô hình thác n−ớc phổ dụng (quá trình phần mềm đ−ợc chia thành một số giai đoạn, khi mỗi giai đoạn kết thúc thì quá trình chuyển sang giai đoạn kế tiếp), ng−ời ta có nghiên cứu các mô hình khác nh−: +Mô hình biến đổi hình thức: phát triển một đặc tả hình thức của một hệ phần mềm, biến đổi đặc tả đó (bảo đảm tính đúng đắn của các phép biến đổi) cho tới khi có đ−ợc một ch−ơng trình thoả mãn các yêu cầu. -Theo Raccoon thì trong những năm gần đây ng−ời ta quan tâm đến mô hình xoắn ốc nhiều hơn cả. Mô hình đ−ợc Boehm đ−a ra năm 1988. Mô hình này dựa trên việc phân tích yếu tố rủi ro. Quá trình phát triển đ−ợc chia thành nhiều thời kỳ, mỗi thời kỳ bắt đầu bằng việc phân tích rủi ro rồi tạo nguyên mẫu, cải tạo và phát triển hệ thống, duyệt lại, và cứ thế tiếp tục -Theo Ian Sommerville thì Boehm đã đ−a ra các tỷ lệ chi phí trong phần việc nh− bảng sau: Kiểu hệ thống phân tích yêu cầu thực hiện (mã thử nghiệm & thiết kế (%) hoá) (%) (%) 1.Các hệ thống lệnh và điều khiển 46 20 34 2.Các hệ thống điều hành 33 17 50 3.Các hệ thống khoa học 44 26 30 4.Các hệ thống tác nghiệp 44 28 28 I.5.Đánh giá tổng quát về chất l−ợng hệ thống Việc đánh giá tổng quát về chất l−ợng hệ thống bao gồm việc đánh giá chất l−ợng tài liệu đặc tả, chất l−ợng thiết kế và chất l−ợng của phần mềm công trình (kỹ nghệ) tốt thông qua các thuộc tính chung. Bốn thuộc tính chủ chốt mà một hệ phần mềm tốt hẳn là phải có: • Có thể bảo trì đ−ợc: phần mềm tuổi thọ dài phải đ−ợc viết và đ−ợc lập t− liệu sao cho việc thay đổi có thể tiến hành đ−ợc mà không quá tốn kém • Đáng tin cậy: phần mềm phải thực hiện đ−ợc điều mà ng−ời tiêu dùng mong mỏi và không thất bại nhiều hơn những điều đã đ−ợc đặc tả ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 21
- Kỹ nghệ phần mềm ___ • Có hiệu quả: hệ thống phải không lãng phí nguồn lực bộ nhớ, bộ xử lý. Không đòi hỏi phải cực đại hoá độ hiệu quả vì rằng việc đó có thể làm cho phần mềm rất khó thay đổi • Có giao diện ng−ời sử dụng thích hợp: giao diện ng−ời sử dụng phải phù hợp với khả năng và kiến thức của ng−ời dùng hệ thống Giá cả phải đ−ợc tính đến khi xây dựng 1 phần mềm công trình tốt. Bảo trì đ−ợc coi là thuộc tính chủ chốt vì rằng các chi phí gắn kết với sản phẩm phần mềm chủ yếu là trong giai đoạn phần mềm đó đ−ợc đ−a vào sử dụng Việc tối −u hoá mọi thuộc tính này là rất khó khăn. Quan hệ giữa chi phí và sự cải thiện từng thuộc tính không phải là tuyến tính và các cải thiện nho nhỏ trong bất kỳ thuộc tính nào cũng là rất đắt. ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 22
- Kỹ nghệ phần mềm ___ Tóm tắt Phần mềm đã trở thành phần tử chủ chốt trong tiến hoá của các hệ thống và sản phẩm dựa trên máy tính. Hơn 40 năm qua, bản thân phần mềm đã tiến hoá từ một công cụ phân tích thông tin và giải quyết vấn đề → một ngành công nghiệp Kỹ nghệ phần mềm là một bộ môn tích hợp cả các ph−ơng pháp, công cụ, thủ tục để phát triển kỹ nghệ phần mềm máy tính. Có thể đề ra một số khuôn cảnh khác nhau cho kỹ nghệ phần mềm, mỗi khuôn cảnh đều có điểm mạnh, điểm yếu, nh−ng nói chung tất cả đều có một dãy các giai đoạn tổng quát. ? củng cố 1. Môn học kỹ nghệ phần mềm (SE) phục vụ cho ai là chính và tại sao họ cần nó ? 2. Ph−ơng pháp tiếp cận của ng−ời thực hành là gì ? 3. Các chủ đề cần quan tâm trong SE ? 4. Tại sao nói phần mềm là nhân tố để đánh giá sự khác biệt ? 5. Việc chấp nhận thực hành SE là do các thách thức nào ? 6. Các thành phần phần mềm đ−ợc xây dựng bằng cách nào ? 7. Bản chất của ứng dụng phần mềm đ−ợc xác định bởi các nhân tố nào ? 8. Phần mềm ứng dụng đ−ợc phân loại theo các chủ đề nào ? 9. Anh (chị) hiểu thế nào là SE ? 10. So sánh các cách tiếp cận cơ bản trong tiến trình phát triển phần mềm ? (chú ý đến các sơ đồ) 11. ý nghĩa của việc tổ hợp các khuôn cảnh ? (chú ý đến các sơ đồ) 12. Nêu và phân tích các b−ớc tổng quát trong tiến trình SE ? (chú ý đến sơ đồ) 13. Giới thiệu tóm tắt các kiểu mô hình quá trình phần mềm ? 14. Nêu các thuộc tính chủ chốt mà hệ phần mềm tốt phải có? 2 December, 2008 ___ Nguyễn Quốc Toản - Nguyên văn Vỵ - Vũ Đức Thi - Lê Đình Phùng 23
- Kỹ nghệ phần mềm ___ Ch−ơng II Đặc tả phần mềm Đặc tả phần mềm bao gồm các nội dung chính sau đây: II.1.Việc hình thành các yêu cầu và cách đặc tả II.1.1.Việc hình thành các yêu cầu II.1.2.Cách đặc tả II.1.3. Các mức trừu t−ợng II.1.4. Các hoạt động cơ sở của tiến trình phân tích hệ thống II.2.Đặc tả yêu cầu II.2.1.Phân tích và nắm bắt nhu cầu II.2.2.Xác định các yêu cầu II.2.3.Đặc tả yêu cầu II.3.Đặc tả hệ thống và việc tạo nguyên mẫu II.3.1 Đặc tả hệ thống II.3.2. Tạo nguyên mẫu II.4. Đặc tả các yêu cầu phần mềm II.4.1.Dàn bài đặc tả II.4.2.Xét duyệt đặc tả ___Ch−ơng II. 25 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ II.1.Việc hình thành các yêu cầu và cách đặc tả II.1.1.Việc hình thành các yêu cầu Phân tích và định rõ yêu cầu là b−ớc kỹ thuật đầu tiên trong tiến trình kỹ nghệ phần mềm. Hoạt động phân tích và định rõ yêu cầu h−ớng tới đặc tả yêu cầu phần mềm đ−ợc thể hiện trong các khuôn cảnh nh− sau: Thiết Mô lập Nghiên hình nhu cứu tính hoá cầu hệ khả thi hệ thống thống Xác định yêu cầu Báo cáo nhu cầu (tài liệu quan niệm về hệ thống) Đặc tả yêu cầu ( đặc tả chức Báo cáo khả thi năng) Đặc tả thiết kế hệ thống và phần Mô hình hệ mềm (mô tả thống trừu t−ợng cho phần Yêu cầu đã mềm ) qua thẩm định Tài liệu đặc Tài liệu đặc tả thiết kế T− liệu yêu cầu tả yêu cầu (tài liệu đặc tả các yêu cầu hệ thống và các yêu cầu phần mềm ) II.1.2.Cách đặc tả và biểu diễn 1.Đặc tả Đặc tả một vấn đề là mô tả (một cách rất riêng nhờ các kỹ thuật thể hiện) các đặc tr−ng của vấn đề đó. Vấn đề có thể là đối t−ợng, khái niệm hoặc một thủ tục nào đó Yêu cầu đầu tiên của đặc tả là tính chính xác Các đặc tả th−ờng mang tính trừu t−ợng. Càng ở mức cao (những mức đầu tiên của quá trình làm mịn hoặc chính xác hoá) đặc tả càng trừu t−ợng. Càng xuống các mức thấp, đặc tả càng tiếp cận dần tới cụ thể- tức là tới một thể hiện trên một máy tính cụ thể với một ngôn ngữ lập trình cụ thể Hai Kiểu Đặc tả hình thức và phi hình thức: -Đặc tả hình thức: là những đặc tả chính xác tức là không thể dẫn tới những cách hiểu khác nhau. Đặc tả hình thức sử dụng công cụ chủ yếu là đại số và logic -Đặc tả phi hình thức: diễn đạt bằng những ngôn ngữ, tuy không chặt chẽ nh−ng đ−ợc nhiều ng−ời biết và có thể trao đổi với nhau để chính xác hoá những điểm ch−a rõ, những khái niệm mơ hồ. -Đặc tả hỗn hợp: phối hợp hai kiểu đặc tả trên ___Ch−ơng II. 26 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ Trong thực tế, có nhiều loại hình đặc tả, ví dụ nh− : +Đặc tả cấu trúc dữ liệu (Mô tả các thành phần của dữ liệu +Đặc tả chức năng (mô tả chức năng thông qua việc m ô tả tính chất của input, output +Đặc tả đối t−ợng (bao gồm đặc tả cấu trúc và đặc tả chức năng +Đặc tả thao tác (mô tả các thao tác cần thực hiện +Đặc tả cú pháp (mô tả cách lắp ghép các kí hiệu, các từ lại thành ch−ơng trình +Đặc tả qua sơ đồ +Đặc tả xử lý +Đặc tả thuật toán Kiểu đặc tả cần phù hợp với giải pháp. Các yêu cầu phần mềm có thể đ−ợc phân tích theo một số cách khác nhau. Các kỹ thuật phân tích có thể dẫn tới những đặc tả trên giấy hay trên máy tính (đ−ợc xây dựng nhờ dùng CASE) có chứa các mô tả ngôn ngữ đồ hoạ và tự nhiên cho yêu cầu phần mềm. Việc làm bản mẫu đã giúp đặc tả thực hiện đ−ợc, tức là bản mẫu thể hiện một cách biểu diễn các yêu cầu. Các ngôn ngữ đặc tả hình thức dẫn tới biểu diễn hình thức. 2.Các Nguyên lí đặc tả Đặc tả có thể đ−ợc xem nh− một tiến trình biểu diễn. Mục đích cuối cùng của đặc tả: các yêu cầu đ−ợc biểu thị sao cho dẫn tới việc cài đặt phần mềm thành công. Balzer và Goldman đề nghị 8 nguyên lý đặc tả tốt: Nguyên lý #1: Phân tách chức năng với cài đặt Tr−ớc hết, theo định nghĩa, đặc tả là một mô tả về điều mong muốn, chứ không phải là cách thực hiện nó (cài đặt). Đặc tả có thể chấp nhận hai dạng hoàn toàn khác nhau. Dạng thứ nhất là dạng của các hàm toán học: với một tập cái vào đã cho, tạo ra một tập cái ra đặc biệt. Dạng tổng quát của những đặc tả nh− thế là tìm ra (một/tất cả những) kết quả ứng với P (cái vào), với P biểu thị một tân từ bất kỳ. Trong những đặc tả nh− thế, kết quả cần thu đ−ợc phải hoàn toàn đ−ợc diễn đạt theo dạng cái gì (không phải là thế nào). Một phần điều này là vì kết quả của một hàm (toán học) của cái vào (phép toán có các điểm bắt đầu và kết thúc đã xác định rõ) và không bị ảnh h−ởng bởi môi tr−ờng bao quanh. Nguyên lí #2: Cần tới ngôn ngữ đặc tả hệ thống h−ớng tiến trình Xét tình huống trong đó môi tr−ờng là động và sự thay đổi của nó ảnh h−ởng tới hành vi của thực thể nào đó t−ơng tác với môi tr−ờng đó (nh− trong "hệ thống máy tính nhúng"). Hành vi của nó không thể biểu diễn đ−ợc ở dạng hàm (toán học) của cái vào. Thay vì thế, cần phải sử dụng cách biểu diễn khác- cách mô tả h−ớng tiến trình, trong đó đặc tả cái gì đạt đ−ợc bằng cách xác định một mô hình hành vi mong muốn của hệ thống d−ới dạng các đáp ứng chức năng đối với các kích thích khác nhau từ môi tr−ờng. Nhận xét: Những đặc tả h−ớng tiến trình nh− vậy, 1. trình bày một mô hình về hành vi hệ thống, 2. thông th−ờng đã không thuộc ngôn ngữ đặc tả hình thức. 3. lột tả đ−ợc bản chất của nhiều tình huống phức tạp cần phải đặc tả. 4. trong những tình huống cần tự động hoá, cả tiến trình lẫn môi tr−ờng tồn tại của nó đều phải đ−ợc mô tả một cách hình thức. Muốn vậy, toàn bộ hệ thống các bộ phận t−ơng tác phải đ−ợc đặc tả chứ không chỉ đặc tả một thành phần. Nguyên lý #3: Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần ___Ch−ơng II. 27 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ Một hệ thống bao gồm các thành phần t−ơng tác nhau. Chỉ bên trong hoàn cảnh của toàn bộ hệ thống và t−ơng tác giữa các thành phần của nó thì hành vi của một thành phần riêng mới có thể đ−ợc xác định. Nói chung, một hệ thống đ−ợc mô hình hoá nh− một tập hợp các sự vật tích cực và thụ động. Những sự vật này có liên quan lẫn nhau và qua thời gian dẫn đến mối quan hệ giữa các sự vật thay đổi. Mối quan hệ động này đ−a ra sự kích thích cho các sự vật tích cực, còn gọi là các tác nhân, đáp ứng. Sự đáp ứng có thể gây ra những thay đổi thêm nữa, và do đó, tạo ra thêm kích thích để cho các tác nhân có thể đáp ứng lại Nguyên lý #4: Đặc tả phải bao gồm cả môi tr−ờng mà hệ thống vận hành Môi tr−ờng trong đó hệ thống vận hành và t−ơng tác phải đ−ợc xác định. Bản thân môi tr−ờng cũng là một hệ thống bao gồm các sự vật t−ơng tác, cả tích cực lẫn thụ động, mà trong đó hệ thống chỉ là một tác nhân. Các tác nhân khác, theo định nghĩa là không thay đổi bởi vì chúng là một phần của môi tr−ờng, giới hạn phạm vi của việc thiết kế và cài đặt về sau. Trong thực tế, sự khác nhau duy nhất giữa hệ thống và môi tr−ờng của nó là ở chỗ nỗ lực thiết kế và cài đặt về sau sẽ vận hành chỉ trong đặc tả cho hệ thống. Đặc tả môi tr−ờng làm cho "giao diện" của hệ thống đ−ợc xác định theo cùng cách nh− bản thân hệ thống chứ không đ−a vào cách hình thức hoá khác. Đặc tả hệ thống chính là bức tranh của tập hợp các tác nhân xoắn xuýt nhau cao độ, phản ứng lại những kích thích trong môi tr−ờng (thay đổi các sự vật). Chỉ có thông qua những hành động điều phối của tác nhân mà hệ thống mới đạt đ−ợc các mục tiêu của nó. Thiết kế tuân theo đặc tả và quan tâm đến việc phân rã một đặc tả thành các mẩu gần tách biệt để chuẩn bị cho cài đặt. Tuy nhiên đặc tả phải vẽ lại chính xác bức chân dung của hệ thống và môi tr−ờng của nó nh− cộng đồng ng−ơì dùng cảm nhận tới mức chi tiết, phục vụ cho các giai đoạn thiết kế và cài đặt. Vì mức độ chi tiết cần thiết này là khó thấy tr−ớc, nếu không nói là không thể, nên đặc tả, thiết kế và cài đặt phải đ−ợc thừa nhận nh− một hoạt động t−ơng tác. Do đó điều mấu chốt là công nghệ cần bao quát thật nhiều các hoạt động này khi bản đặc tả đ−ợc soạn thảo và thay đổi (trong cả hai giai đoạn phát triển khởi đầu và bảo trì về sau). Nguyên lí #5: Đặc tả hệ thống phải là một mô hình nhận thức -Đặc tả hệ thống phải là một mô hình nhận thức chứ không phải là một mô hình thiết kế hay cài đặt. -Mô tả một hệ thống gần đạt nh− sự cảm nhận của cộng đồng ng−ời sử dụng. Các sự vật mà nó thao tác phải t−ơng ứng với các sự vật của lĩnh vực đó; các tác nhân phải đ−ợc mô hình hoá cho các cá nhân, tổ chức và trang thiết bị trong lĩnh vực đó; còn các hành động họ thực hiện thì phải đ−ợc mô hình hoá cho những hoạt động thực tế xuất hiện trong lĩnh vực. -Phải có khả năng tổ hợp vào trong đặc tả những quy tắc hay luật bao trùm các sự vật thuộc lĩnh vực: + Một trong những luật này bài trừ những trạng thái nào đó của hệ thống (nh− "hai sự vật không thể đồng thời ở cùng một chỗ và vào cùng một lúc"), và do đó giới hạn hành vi của các tác nhân hay chỉ ra nhu cầu bổ trợ để ngăn cản những trạng thái này khỏi nảy sinh. +Các luật khác mô tả cách các sự vật đáp ứng lại khi bị kích thích (nh− luật chuyển động của Newton). Những luật này, biểu thị cho "tính vật lý" của lĩnh vực, là phần cố hữu của đặc tả hệ thống . Nguyên lí #6: Đặc tả phải thể hiện tính vận hành Đặc tả phải đầy đủ và mang tính hình thức để có thể đ−ợc dùng trong việc xác định rằng liệu một cài đặt đ−ợc đề nghị có thoả mãn đặc tả cho những tr−ờng hợp kiểm thử tuỳ ý không. Tức là, với kết quả của việc cài đặt trên một tập dữ liệu đ−ợc chọn một cách tuỳ ý, phải có thể dùng đặc tả để xác định tính hợp lệ cho những kết qủa đó. Điều này kéo theo rằng đặc tả, mặc dầu không phải là ___Ch−ơng II. 28 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ một đặc tả hoàn toàn về cách thức, vẫn có thể hành động nh− một bộ sinh các hành vi. Do đó, theo một nghĩa mở rộng, đặc tả này phải thể hiện tính vận hành kết quả cài Quá trình cài đặt đặt xác định kiểm tính hợp lệ chứng đặc đặc đặc đặc đặc tả tả tả tả tả Nguyên lí #7: Đặc tả hệ thống chấp nhận dung sai về tính không đầy đủ và vì vậy có tính nâng cao Không đặc tả nào có thể là đầy đủ hoàn toàn. Môi tr−ờng mà hệ thống tồn tại trong đó quá phức tạp Một đặc tả bao giờ cũng là một mô hình-một sự trừu t−ợng hoá-của một tình huống thực (hay đ−ợc m−ờng t−ợng) nào đó. Do đó, nó sẽ không đầy đủ. Hơn thế nữa, nó tồn tại ở nhiều mức chi tiết. Các công cụ phân tích đ−ợc sử dụng để giúp đặc tả và kiểm thử đặc tả phải có khả năng xử lý với tính không đầy đủ. Nguyên lí #8: Đặc tả phải đ−ợc cục bộ hoá và đ−ợc ghép lỏng lẻo Các nguyên lý tr−ớc xử lý đặc tả nh− một thực thể tĩnh. Nguyên lí này nảy sinh từ tính động của đặc tả. Cần phải thừa nhận rằng mặc dầu mục tiêu chính của một đặc tả là để dùng làm cơ sở cho thiết kế và cài đặt một hệ thống nào đó, nó không phải là một sự vật tĩnh dựng sẵn mà là một sự vật động đang trải qua thay đổi đáng kể. Việc thay đổi (động) của đặc tả xuất hiện trong 3 hoạt động chính: -phát biểu, khi một đặc tả ban đầu đang đ−ợc tạo ra, -phát triển, khi đặc tả đ−ợc soạn thảo trong quá trình thiết kế -lặp, để phản ánh môi tr−ờng đã thay đổi và/ hoặc các yêu cầu chức năng phụ. Với nhiều thay đổi xuất hiện đối với đặc tả, điều mấu chốt là nội dung và cấu trúc của đặc tả đ−ợc chọn để làm phù hợp thay đổi này. Yêu cầu chính cho sự phù hợp đó là ở chỗ: +thông tin bên trong đặc tả phải đ−ợc cục bộ hoá sao cho chỉ một phần nhỏ (một cách lí t−ởng) cần phải sửa đổi khi thông tin thay đổi, +đặc tả cần đ−ợc cấu trúc (ghép) một cách lỏng lẻo để cho từng phần có thể đ−ợc thêm vào hay loại bỏ một cách dễ dàng, và cấu trúc đ−ợc điều chỉnh một cách tự động. 3.Biểu diễn Các yêu cầu phần mềm có thể đ−ợc biểu diễn theo nhiều cách. Cách biểu diễn tốt nên tuân theo h−ớng dẫn sau: -Định dạng và nội dung biểu diễn theo h−ớng liên quan tới vấn đề: +Theo một dàn bài chung cho nội dung của bản đặc tả các yêu cầu phần mềm. +Dạng biểu diễn có trong bản đặc tả có thể thay đổi theo lĩnh vực ứng dụng. (Chẳng hạn, đặc tả cho hệ thống tự động hoá chế tạo sẽ dùng cách kí hiệu khác, biểu đồ và ngôn ngữ khác với đặc tả cho trình biên dịch ngôn ngữ lập trình). -Thông tin chứa trong bản đặc tả nên đ−ợc lồng nhau: +Các biểu diễn nên làm lộ ra các tầng thông tin sao cho độc giả có thể di chuyển tới mức chi tiết mình mong muốn. ___Ch−ơng II. 29 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ +Đoạn và các sơ đồ đánh dấu nên chỉ ra mức độ chi tiết đang đ−ợc trình bày. Đôi khi cũng nên trình bày cùng một thông tin ở các mức trừu t−ợng khác nhau để hiểu tốt hơn. -Các biểu đồ và các dạng kí pháp khác nên giảm thiểu và nhất quán trong sử dụng. Chẳng hạn, cách kí hiệu nh− sau có thể hiểu theo nhiều cách: có thể diễn giải theo ít nhất ba (hoặc 5 hay 6) cách khác nhau. Lẫn lộn hay không nhất quán trong kí pháp, dù là đồ hoạ hay kí hiệu cũng đều làm suy giảm việc hiểu và làm phát sinh lỗi. -Biểu diễn nên th−ờng đ−ợc xem lại: Nội dung của đặc tả sẽ thay đổi. Vì vậy biểu diễn nên th−ờng đ−ợc xem lại để đảm bảo tính thống nhất. Một cách lí t−ởng, các công cụ CASE nên có sẵn để cập nhật tất cả các biểu diễn bị ảnh h−ởng bởi từng thay đổi. -Nên sử dụng các kí hiệu, sơ đồ quen thuộc nh−ng có chọn lọc: Ng−ời ta đã tiến hành nhiều cuộc điều tra về nhân tố con ng−ời liên quan đến đặc tả. D−ờng nh− ít có hoài nghi rằng cách kí hiệu và thu xếp có ảnh h−ởng tới việc hiểu. Tuy nhiên các kỹ s− thích các dạng kí hiệu, các sơ đồ riêng biệt. Sự quen thuộc th−ờng thuận cho mọi ng−ời, nh−ng các nhân tố chọn lọc nh− cách bố trí không gian, các mẫu hình dễ nhận thức và mức hợp lý của hình thức sẽ giúp cho việc đặc tả có lợi về sau. II.1.3. Các mức trừu t−ợng của đặc tả Các đặc tả đ−ợc thể hiện ở vài mức trừu t−ợng khác nhau cùng với mối t−ơng liên giữa các mức ấy. Mỗi mức nhắm đến các đối t−ợng đọc khác nhau mà họ có quyền quyết định về việc mua sắm và thực hiện. Các mức đó là: ắ Định ra yêu cầu: +Thể hiện bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ thống sẽ phải cung cấp. +phải đ−ợc viết sao cho dễ hiểu đối với khách hàng và ng−ời quản lý hợp đồng, ng−ời sẽ mua sắm và ng−ời sẽ sử dụng ắ Đặc tả yêu cầu: +Tài liệu nêu ra các dịch vụ một cách chi tiết hơn. Tài liệu này (th−ờng đ−ợc gọi là đặc tả chức năng ) +Đòi hỏi chính xác tới mức nó có thể làm cơ sở cho hợp đồng giữa ng−ời mua sắm hệ thống và ng−ời phát triển phần mềm. +Đ−ợc viết dễ hiểu đối với các nhân viên kỹ thuật ở cả nơi mua lẫn nơi phát triển. +Kỹ thuật đặc tả hình thức hẳn là thích hợp cho các đặc tả kiểu nh− vậy, nh−ng nó cũng tuỳ thuộc ở trình độ kiến thức cơ bản của ng−ời mua sắm hệ thống. ắ Đặc tả phần mềm /đặc tả thiết kế (đây là một mô tả trừu t−ợng cho phần mềm): +Dùng làm cơ sở cho việc thiết kế và thực thi. +Thể hiện một quan hệ rõ ràng giữa t− liệu này và đặc tả yêu cầu. +Đối t−ợng đọc ở đây chủ yếu là các kỹ s− phần mềm chứ không phải là ng−ời sử dụng hoặc ng−ời quản lý. + Sử dụng kỹ thuật đặc tả hình thức là thích hợp cho t− liệu này. II.1.4. Các hoạt động cơ sở của tiến trình phân tích hệ thống 1.Xác định nhu cầu -B−ớc dầu tiên của tiến trình phân tích hệ thống bao gồm việc xác định nhu cầu. Để bắt đầu, ng−ời phân tích giúp cho khách hàng trong việc xác định các mục tiêu của hệ thống (sản phẩm): +Thông tin nào cần phải tạo ra? +Thông tin nào cần đ−ợc cung cấp? ___Ch−ơng II. 30 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ +Cần những chức năng và hiệu suất nào? -Ng−ời phân tích phải phân biệt đ−ợc giữa "nhu cầu của khách hàng (những tính năng chủ chốt cho sự thành công của hệ thống) và "điều mong muốn" của khách hàng (những tính năng tốt nên có nh−ng không bản chất) -Một khi các mục tiêu tổng thể đã đ−ợc xác định thì nhà phân tích chuyển sang việc đánh giá các thông tin phụ: +Liệu có công nghệ để xây dựng hệ thống không ? +Cần có những tài nguyên ch ế tạo và phát triển đặc biệt nào? +Cần phải đặt giới hạn nào về chi phí và lịch bỉểu? -Nếu hệ thống mới thực tế là một sản phẩm xây dựng để bán cho nhiều khách hàng thì nên có những câu hỏi sau: +Đâu là thị tr−ờng tiềm năng cho sản phẩm này? +Sản phẩm này so với các sản phẩm cạnh tranh khác nh− thế nào? +Sản phẩm này sẽ giữ vị trí nào trong tuyến sản phẩm của cả công ty? Thông tin thu đ−ợc trong b−ớc xác định nhu cầu đ−ợc kết tinh trong Tài liệu quan niệm về hệ thống. Tài liệu quan niệm nguyên bản đôi khi đ−ợc khách hàng chuẩn bị tr−ớc cuộc gặp gỡ với ng−ời phân tích. Sự trao đổi th−ờng xuyên giữa khách hàng-ng−ời phân tích tạo ra những thay đổi cho tài liệu này. 2.Nghiên cứu khả thi Mọi dự án đều khả thi với 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. Cho nên cần phải thận trọng trong đánh giá tính khả thi của dự án từ thời điểm sớm nhất có thể đ−ợc. 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 chất l−ợng sẽ bị giảm đi. Trong kỹ nghệ hệ thống, chúng ta tập trung vào bốn lĩnh vực quan tâm chính: 1. Khả thi về kinh tế: đánh giá về chi phí phát triển cần phải cân xứng với lợi tức cuối cùng hay lợi ích mà hệ thống đ−ợc xây dựng đem lại 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 3. Khả thi về hợp pháp: phán quyết về bất kỳ sự xâm phạm, vi phạm hay khó khăn nào có thể gây ra từ việc xây dựng hệ thống 4. Các ph−ơng án: đánh giá tính khả thi của ph−ơng án tiếp cận tới việc xây dựng hệ thống Khảo cứu khả thi không đảm bảo cho các hệ thống trong đó việc biện minh kinh tế là hiển nhiên, rủi ro kỹ thuật thấp, ít các vấn đề pháp lý và không có các ph−ơng pháp hợp lý khác. Tuy nhiên, nếu bất kỳ điều kiện nói trên không đ−ợc đáp ứng thì phải tiến hành khảo cứu • Luận chứng kinh tế nói chung là xem xét "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 ứng dụng công nghệ cao nh− ch−ơng trình không gian). Luận chứng kinh tế bao gồm: +các mối quan tâm kể cả phân tích chi phí-lợi ích, +chiến l−ợc lợi tức công ty dài hạn, +ảnh h−ởng tới các trung tâm hay 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 • Khả thi kỹ thuật th−ờng là lĩnh vực khó thâm nhập nhất tại giai đoạn này của tiến trình phát triển hệ thống. Đ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 ___Ch−ơng II. 31 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ hành song song với việc xác nhận tính khả thi kỹ thuật. Theo cách này có thể đánh giá các đặc tả cụ thể khi xác định chúng. 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 chức năng và hiệu suất cần thiết làm lộ rõ 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 ? ắ 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? Ng−ời phát triển các hệ thống về bản chất đều lạc quan. Tuy nhiên, trong đánh giá tính khả thi kỹ thuật, việc đánh giá sai trong giai đoạn này có thể là một thảm hoạ. • 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 mà th−ờng là các nhân viên kỹ thuật không biết tới. • Mức độ các ph−ơng án đ−ợc xem xét tới th−ờng bị giới hạn bởi các ràng buộc chi phí và thời gian . Có thể soạn t− liệu về nghiên cứu khả thi thành một báo cáo riêng cho cấp quản lý trên và đính kèm nh− phụ lục cho đặc tả hệ thống . Mặc dầu định dạng của báo cáo khả thi có thể thay đổi, phần đại c−ơng đ−ợc nêu trong bảng d−ới đây đã bao quát đ−ợc hầu hết những điểm quan trọng: Bảng: Đại c−ơng về nghiên cứu khả thi I.Giới thiệu A.Phát biểu vấn đề B.Môi tr−ờng thực hiện C.Ràng buộc II.Tóm tắt quản lý và khuyến cáo A.Những tóm l−ợc quan trọng B.Bình luận C.Khuyến cáo D.Tác động III.Các ph−ơng án A.Các cấu hình hệ thống theo ph−ơng án B.Các tiêu chuẩn đ−ợc dùng trong chọn lựa cách tiếp cận cuối cùng IV.Mô tả hệ thống A.Phát biểu vắn tắt về phạm vi B.Tính khả thi của các phần tử trong hệ thống V.Phân tích chi phí-lợi ích VI.Đánh giá rủi ro kỹ thuật VII.Các chi nhánh pháp lý VIII.Các chủ đề khác chuyên cho dự án IX. Kết luận Bản nghiên cứu khả thi tr−ớc tiên đ−ợc cấp quản lý dự án xem xét (để đánh giá độ tin cậy nội dung) rồi đến cấp quản lý cao hơn (để đánh giá trạng thái dự án). Bản nghiên cứu phải đề xuất quyết định "tiến hành/không tiến hành". Cũng cần chú ý rằng các quyết định tiến hành hay không tiến hành khác sẽ đ−ợc đ−a ra trong các b−ớc lập kế hoạch, đặc tả và xây dựng cho cả công nghệ phần cứng và phần mềm. 3.Mô hình hoá hệ thống Việc mô hình hoá và mô phỏng hệ thống đ−ợc sử dụng để loại bỏ những điều bất ngờ khi xây dựng hệ thống. Những công cụ CASE đ−ợc áp dụng trong các tiến trình kỹ nghệ hệ thống. ___Ch−ơng II. 32 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ Vai trò của mô hình hoá và mô phỏng đ−ợc tóm tắt nh− sau: -Cung cấp một ph−ơng án cho tiến trình thiết kế, cài đặt và kiểm thử thông qua cách tiếp cận của câu lệnh (một công cụ mô hình hoá và mô phỏng). -Cho phép xây dựng một mô hình đề cập tới tất cả các vấn đề luồng chức năng và dữ liệu thông th−ờng đồng thời còn bao quát cả các khía cạnh hành động, hành vi của hệ thống. Có thể kiểm thử mô hình này bằng các công cụ phục vụ giám định và gỡ lỗi cho đặc tả và tìm kiếm thông tin. -Dùng để "kiểm thử sự hoạt động" của đặc tả hệ thống: bằng cách kiểm thử mô hình đặc tả, ng−ời kỹ s− hệ thống có thể hình dung đ−ợc cách thức mà hệ thống sẽ hành xử ra sao khi đ−ợc caì đặt. Ng−ời ta có thể trả lời câu hỏi "cái gì xảy ra nếu" đi theo các kịch bản xác định, kiểm tra rằng những tình huống mong muốn nào đó có xuất hiện hay không, và các tình huống không mong muốn khác sẽ không xuất hiện hay lại xuất hiện. ___Ch−ơng II. 33 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ II.2.Đặc tả yêu cầu II.2.1.Phân tích và nắm bắt nhu cầu Nhu cầu của ng−ời dùng và yêu cầu của ng−ời dùng không phải là nh− nhau. Một tổ chức có thể quyết định rằng họ cần một phần mềm trợ giúp công việc kế toán. Nh−ng việc trình một nhu cầu đơn giản nh− thế cho một kỹ s− phần mềm chấp nhận đ−ợc và dùng tốt là điều không dễ dàng. Các thông tin của vấn đề cần giải quyết phải đ−ợc thu thập, phân tích và phải đ−ợc xác định một cách rõ ràng. Khi đó thì giải pháp phần mềm mới có thể đ−ợc thiết kế và thực thi. Để giải quyết vấn đề này ng−ời ta phải thực hiện các b−ớc đầu tiên của tiến trình phân tích hệ thống nh− xác định nhu cầu, nghiên cứu khả thi và mô hình hoá hệ thống (giai đoạn tiền khả thi). Việc phân tích và nắm bắt yêu cầu là giai đoạn đầu của quá trình thiết lập các dịch vụ (mà hệ thống phải giải quyết) và các ràng buộc (mà hệ thống phải tuân theo). Kết quả của công việc này là bản đặc tả yêu cầu. Đó th−ờng là t− liệu chính thức đầu tiên đ−ợc tạo ra trong quá trình phần mềm. Khó khăn có tính nguyên lý của công việc thiết kế các hệ thống phần mềm là các vấn đề của độc, nó là các vấn đề không có công thức định nghĩa. Mỗi phát biểu hình thức (các yêu cầu) của vấn đề là rất riêng và sự nhận biết của ng−ời phát triển trong tiến trình là liên tục thay đổi. Nhận xét: +Hiểu bản chất vấn đề cần nghiên cứu trong hệ thống th−ờng là vô cùng phức tạp, dù rằng hệ thống đó là mới hay đang tồn tại. +Việc hiểu biết đầy đủ về các yêu cầu phần mềm là điều chủ chốt cho sự thành công của nỗ lực phát triển phần mềm . Thiết kế & lập trình tốt + một ch−ơng trình phân tích và đặc tả nghèo nàn → ng−ời dùng thất vọng +Nhiệm vụ phân tích yêu cầu là một tiến trình khám phá, làm mịn, mô hình hoá và đặc tả . Phạm vi phần mềm, ban đầu do ng−ời phân tích thiết lập, làm mịn dần trong việc lập kế hoạch dự án phần mềm, sẽ đ−ợc chi tiết thêm: • Các mô hình của thông tin cần tới • Luồng thông tin • Hành vi vận hành • Nội dung dữ liệu đ−ợc tạo ra +Cả ng−ời phát triển và khách hàng đều đóng vai trò quan trọng trong việc phân tích và đặc tả yêu cầu. Khách hàng đặt vấn đề. Ng−ời phân tích hoạt động nh− một ng−ời tích hợp, ng−ời cố vấn và ng−ời giải quyết vấn đề. +Việc phân tích và đặc tả yêu cầu là một nhiệm vụ không đơn giản. Nội dung trao đổi giữa hai bên là rất lớn. Hiểu lầm, hiểu sai, mơ hồ rất dễ phạm phải. +Phân tích yêu cầu là nhiệm vụ kỹ nghệ phần mềm để bắc nhịp cầu nối giữa kỹ nghệ hệ thống máy tính với thiết kế phần mềm : ___Ch−ơng II. 34 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ kỹ nghệ hệ thống phân tích máy yêu cầu tính phần mềm thiết kế phần mềm +ích lợi cho cả ng−ời phát triển và khách hàng • Giúp ng−ời phân tích hệ thống có thể xác định đ−ợc chức năng và hiệu suất phần mềm; chỉ ra giao diện cuả phần mềm với các phần tử hệ thống khác; xác lập những ràng buộc thiết kế mà phần mềm phải đáp ứng • Cho phép ng−ời phân tích tinh chế lại phần mềm và xây dựng mô hình tiến trình, dữ liệu, các lĩnh vực hành vi sẽ đ−ợc phần mềm xử lý • Giúp ng−ời thiết kế phần mềm một cách biểu diễn thông tin và chức năng - cơ sở để dịch thành thiết kế dữ liệu, kiến trúc và thủ tục • Cung cấp cho ng−ời phát triển và khách hàng các ph−ơng tiện để xác quyết về chất l−ợng phần mềm sau khi xây dựng nhờ đặc tả yêu cầu a)Nhiệm vụ phân tích 5 lĩnh vực phân tích : 1.Nhận thức vấn đề 2.Đánh giá và tổng hợp 3.Mô hình hoá 4.Đặc tả 5.Xét duyệt Nhiệm vụ phân tích bao gồm các b−ớc chính sau: • Nghiên cứu bản Đặc tả hệ thống (nếu có) và bản Kế hoạch dự án phần mềm . Điều quan trọng là hiểu phần mềm trong hoàn cảnh hệ thống và xem xét phạm vi phần mềm đ−ợc dùng để sinh ra −ớc l−ợng kế hoạch. • Tiến hành trao đổi: giúp ng−ời phân tích có thể đảm bảo nhận thức đúng vấn đề. Ng−ời phân tích phải lập đ−ợc mối tiếp xúc với cấp quản lý và nhân viên kỹ thuật của tổ chức ng−ời dùng khách hàng và tổ chức phát triển phần mềm . Ng−ời quản lý dự án có thể phục vụ nh− ng−ời điều phối để tạo điều kiện thuận lợi cho việc thiết lập đ−ờng trao đổi. Mục tiêu của ng−ời phân tích là nhận thức đ−ợc các phần tử vấn đề cơ bản nh− khách hàng đã cảm nhận • Đánh giá vấn đề và tổng hợp giải pháp. Cần thực hiện các b−ớc: -Đánh giá luồng và nội dung thông tin -Xác định và soạn thảo các chức năng phần mềm -Hiểu hành vi phần mềm theo hoàn cảnh của các sự kiện ảnh h−ởng tới hệ thống -Thiết lập các đặc tr−ng giao diện -Để lộ ra những ràng buộc thiết kế Mỗi một trong những nhiệm vụ này đều phục vụ cho việc mô tả vấn đề sao cho có thể tổng hợp đ−ợc một cách tiếp cận hay giải pháp tổng thể. ___Ch−ơng II. 35 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ Ví dụ, ng−ời ta cần tới một hệ thống quản lý kho cho một nhà cung cấp các phụ tùng ô tô chính. Ng−ời phân tích thấy rằng các vấn đề với hệ thống thủ công hiện tại bao gồm: .Không có khả năng thu đ−ợc trạng thái của các phụ tùng một cách nhanh chóng (thiếu thông tin ) .Phải mất đến 2 hay 3 ngày mới nhập đ−ợc thẻ kho (vấn đề thời gian ) .Có nhiều mức đặt hàng lại với cùng một nhà cung cấp bởi vì không có cách nào liên kết nhà cung cấp vơí kho. Một khi các vấn đề này đã đ−ợc xác định thì ng−ời phân tích sẽ xác định hệ thống mới cần phải tạo ra thông tin nào và dữ liệu nào cần đ−ợc cung cấp cho hệ thống. Chẳng hạn, khách hàng muốn có báo cáo hàng ngày chỉ rõ phụ tùng nào đã đ−a ra khỏi kho và bao nhiêu phụ tùng còn lại. Khách hàng chỉ ra rằng ng−ời coi kho sẽ vào sổ số hiệu cuả từng phụ tùng khi chúng ra khỏi khu vực kho. Một khi đánh giá đ−ợc các vấn đề hiện tại và thông tin mong muốn (cái vào và cái ra), ng−ời phân tích bắt đầu tổng hợp một hay nhiều giải pháp. Tiến trình −ớc l−ợng và tổng hợp vẫn tiếp tục cho tới khi cả ng−ời phân tích lẫn khách hàng để tin rằng phần mềm có thể đ−ợc xác định thích hợp cho những b−ớc phát triển kế tiếp Thông qua −ớc l−ợng và tổng hợp giải pháp, ng−ời phân tích tập trung chủ yếu vào "cái gì" chứ không phải "thế nào". Hệ thống tạo ra và sử dụng dữ liệu nào, hệ thống phải thực hiện chức năng nào, giao diện nào cần xác định, và hệ thống nằm trong các ràng buộc nào? Trong hoạt động đánh giá tổng hợp giải pháp, ng−ời phân tích tạo ra các mô hình hệ thống nhằm hiểu rõ hơn luồng dữ liệu và điều khiển xử lý chức năng, thao tác hành vi và nội dung thông tin. Mô hình này đ−ợc lấy làm nền tảng cho thiết kế phần mềm và là cơ sở cho việc tạo ra một đặc tả phần mềm. L−u ý: 1. Không thể có đ−ợc đặc tả chi tiết trong giai đoạn này. Khách hàng có thể không chắc chắn cần gì. Ng−ời phát triển cũng không chắc chắn rằng một cách tiếp cận cụ thể có thực hiện đúng chức năng và hiệu suất mong muốn không → tìm cách tiếp cận khác- làm bản mẫu 2. Các nhiệm vụ liên quan tới phân tích và đặc tả hệ thống đ−ợc mô tả sao cho khách hàng có thể duyệt và chấp thuận. Lý t−ởng nhất là khách hàng xây dựng bản đặc tả yêu cầu phần mềm , thực tế không có →kết hợp giữa ng−ời phát triển và khách hàng 3.Việc chỉnh kế hoạch trong thực tế th−ờng đ−ợc gợi ý qua sơ đồ sau: ___Ch−ơng II. 36 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ mô tả thông tin , chức năng , Xác định các tiêu chuẩn hợp lệ kiểm thử hiệu suất, hành vi và giao diện để biểu diễn cách hiểu về việc cơ sở cài đặt phần mềm thành công Viết ra đặc tả yêu cầu hình Xác định các đặc thức tr−ng và thuộc tính của phần mềm Soạn nháp tài liệu ng−ời Khách hàng dùng sơ l−ợc khi ch−a xong duyệt lại bản mẫu Xét duyệt yêu cầu Chỉnh kế hoạch dự án phần mềm b)Ng−ời phân tích Ng−ời ta đặt khá nhiều tên gọi cho nhà phân tích: ng−ời phân tích hệ thống, kỹ s− hệ thống, ng−ời thiết kế hệ thống, Các yêu cầu đối với ng−ời phân tích: • 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 • 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 trao đổi tốt thông qua dạng viết và nói • Khả năng "thấy rừng qua cây" Hai đòi hỏi cơ bản để đạt đ−ợc phần mềm tốt (trong giai đoạn phân tích): Các yêu cầu phần mềm phải bộc lộ theo ph−ơng thức "trên- xuống". Các chức năng, giao diện và thông tin chủ yếu phải đ−ợc hiểu hoàn toàn rõ tr−ớc khi xác định chi tiết các tầng kế tiếp Ng−ời phân tích cũng phải hiểu từng khuôn cảnh phần mềm và đánh giá đ−ợc các b−ớc kỹ nghệ phần mềm tổng quát, áp dụng đ−ợc bất kể khuôn cảnh nào cần dùng. Nhiều yêu cầu phần mềm không t−ờng minh (nh− thiết kế cho bảo trì) đ−ợc tổ hợp vào Bản đặc tả yêu cầu chỉ nếu ng−ời phân tích hiểu đ−ợc kỹ nghệ phần mềm . II.2.2.Xác định các yêu cầu Comment [BTL1]: Phan nay co trong phan on tap Xác định yêu cầu là mô tả trừu t−ợng các dịch vụ (mà hệ thống đ−ợc mong đợi phải cung cấp) và các ràng buộc (mà hệ thống phải tuân thủ khi vận hành). Nó chỉ đặc tả tính chất bên ngoài ___Ch−ơng II. 37 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ của hệ thống mà không hề liên quan đến các đặc tính thiết kế . Nó phải đ−ợc viết sao cho ng−ời ta có thể hiểu đ−ợc 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 đ−ợc chia làm 2 loại: 1.Các yêu cầu hệ thống chức năng : các dịch vụ mà hệ thống phải cung cấp 2.Các yêu cầu không chức năng : các ràng buộc mà hệ thống phải tuân theo Về nguyên tắc, các yêu cầu của hệ thống phải là vừa đầy đủ, vừa không gây ra mâu thuẫn. Thực tế đối với các hệ lớn và phức tạp thì thực khó đạt đ−ợc tính đầy đủ và tính không gây mâu thuẫn cho phiên bản đầu của t− liệu yêu cầu phần mềm . Vấn đề là khi duyệt lại hoặc trong các pha sau này của vòng đời phần mềm ng−ời ta phát hiện ra các sự không thoả mãn đó thì t− liệu yêu cầu phải đ−ợc chỉnh lý lại. Xác định yêu cầu th−ờng đ−ợc viết bằng ngôn ngữ tự nhiên cộng thêm việc dùng các bảng, các biểu đồ để cho ng−ời dùng dễ hiểu (xem nh− ng−ời dùng không biết các khái niệm chuyên môn). Ngôn ngữ đ−ợc dùng trong việc xác định yêu cầu th−ờng là không chính xác và mơ hồ. Sự lầm lẫn giữa các biểu thị khái niệm và các biểu thị chi tiết đòi hỏi việc mô tả thông tin cần đ−ợc biểu diễn ở nhiều mức chi tiết khác nhau. Chú ý: +Vì việc xác định yêu cầu ch−a hoàn hảo tr−ớc khi bắt đầu phát triển hệ thống nên việc vận dụng mô hình quá trình dựa trên việc tạo mẫu hệ thống sẽ thích hợp hơn là mô hình thác n−ớc. +Cần phân biệt giữa mục tiêu của hệ thống và yêu cầu của hệ thống: Yêu cầu là một cái gì đó có thể kiểm tra đ−ợc. Mục tiêu lại là một đặc tr−ng khái quát hơn mà hệ thống phải thể hiện. Chẳng hạn mục tiêu của hệ thống có thể là thân thiện với ng−ời sử dụng. Nh−ng sự thân thiện vớí ng−ời sử dụng lại không phải là một thuộc tính khách quan. T− liệu các yêu cầu phần mềm Heninger đòi hỏi 6 yêu cầu cho t− liệu các yêu cầu phần mềm : 1. Chỉ đặc tả phẩm hạnh bên ngoài của hệ thống 2. Đặc tả các ràng buộc về sự thực hiện 3. Phải là dễ thay đổi 4. Phải đ−ợc dùng làm công cụ tham khảo cho ng−ời bảo trì hệ thống 5. Phải báo cáo dự tính tr−ớc về vòng đời của hệ thống 6. Phải đặc tr−ng hoá các đáp ứng chấp nhận đ−ợc cho các sự kiện bất ngờ Cấu trúc của một t− liệu yêu cầu Cấu trúc của một t− liệu yêu cầu đ−ợc gợi ý theo kết cấu sau: 1. Phần dẫn nhập 2. Phần mô hình hệ thống 3. Phần tiến triển của hệ thống 4. Phần các yêu cầu chức năng 5. Phần tự điển thuật ngữ II.2.3.Đặc tả yêu cầu Việc xác định yêu cầu là việc đặc tả h−ớng khách hàng và đ−ợc viết bởi ngôn ngữ của khách hàng. Khi đó có thể dùng các khái niệm không chính xác, ngôn ngữ tự nhiên và các biểu đồ. Đặc tả yêu cầu (đ−ợc gọi là đặc tả chức năng ) là cơ sở cho hợp đồng làm hệ thống: nó phải không đ−ợc mơ hồ, mà mơ hồ đó có thể dẫn tới sự hiểu lầm bởi khách hàng hoặc bởi ng−ời ký hợp đồng. Rất nhiều vấn đề của kỹ nghệ phần mềm là khó khăn đối với đặc tả yêu cầu. Với một yêu cầu mơ hồ thì ng−ời phát triển sẽ thực hiện nó sao cho rẻ nhất. Trong khi đó khách hàng lại không ___Ch−ơng II. 38 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ muốn nh− vậy. Sau các cuộc đấu khẩu kéo dài thì các yêu cầu mới sẽ đ−ợc thiết lập và có các đổi thay đối với hệ thống. Dĩ nhiên việc đó làm trì hoãn ngày phân phát hệ thống và làm tăng chi phí. Chi phí do các sai sót trong việc phát biểu các yêu cầu có thể là rất cao, đặc biệt là nếu các sai này còn vẫn ch−a đ−ợc phát hiện tr−ớc khi hệ thống đ−ợc thực hiện . Boehm báo cáo rằng trong một vài hệ thống lớn thì có đến 95% các mã đã phải viết lại để thoả mãn các yêu cầu của ng−ời dùng đã đổi thay và 12% các lỗi đ−ợc phát hiện trong quá trình ba năm đầu sử dụng là các lỗi do đặc tả yêu cầu không đúng đắn Chi phí do thay đổi một yêu cầu là đắt hơn nhiều so với chi phí sửa chữa thiết kế hoặc do lỗi mã Việc đặc tả bằng ngôn ngữ tự nhiên có những hạn chễ sau: 1. Ng−ời đọc và ng−ời viết đặc tả bằng ngôn ngữ tự nhiên buộc phải hiểu mỗi từ theo cùng một khái niệm. Điều đó là không thể đ−ợc do sự mơ hồ là bản tính cố hữu của ngôn ngữ tự nhiên và cũng vì không có một từ điển thuật ngữ máy tính chuẩn mực 2. Một đặc tả bằng ngôn ngữ tự nhiên là quá mềm dẻo: nó cho phép các yêu cầu liên quan đ−ợc biểu thị trong các cách hoàn toàn khác nhau 3. Các yêu cầu là không phân hoạch đ−ợc một cách hữu hiệu: hiệu quả của việc đổi thay chỉ có thể đ−ợc xác định bởi toàn bộ các yêu cầu chứ không phải là một nhóm các yêu cầu liên quan. Có ng−ời đề nghị rằng các ngôn ngữ đặc tả hình thức toán học nên đ−ợc dùng để biểu thị các yêu cầu hệ thống. Nh−ng đa số các khách hàng lại không hiểu đặc tả hình thức toán học. Hall (1990) đề xuất con đ−ờng để đi vòng qua khó khăn đó là viết thêm các chú giải dài dòng ngay bên cạnh cho ng−ời dùng dễ hiểu. Khi nào ng−ời dùng trở nên quen thuộc hơn với những −u điểm của đặc tả hình thức và các kỹ s− phần mềm không còn miễn c−ỡng dùng các ph−ơng pháp hình thức thì sẽ có nhiều các đặc tả yêu cầu sẽ dựa trên các mô hình hình thức của chức năng hệ thống. Các yêu cầu phi chức năng: Một yêu cầu phi chức năng của hệ thống là một hạn chế hoặc ràng buộc về các dịch vụ của hệ thống. Các yêu cầu đó có thể đ−ợc đ−a ra: - vì nhu cầu của ng−ời dùng, - vì hạn chế của kinh phí, - vì chính sách của tổ chức, - vì sự cần thiết t−ơng tác giữa các phần cứng và phần mềm hoặc - vì các nhân tố bên ngoài nh− các quy tắc an toàn, luật lệ bí mật riêng t−, Có 3 kiểu yêu cầu phi chức năng chính: 1. Các yêu cầu sản phẩm : đây là các yêu cầu về hệ thống đ−ợc phát triển , chẳng hạn yêu cầu về tốc độ, về bộ nhớ, về độ tin cậy, về tính di chuyển đ−ợc và về tính dùng lại đ−ợc 2. Các yêu cầu về quá trình: đây là các yêu cầu về quá trình phát triển, chẳng hạn nh− các chuẩn cần phải theo, các yêu cầu về sự thực hiện nh− là các ngôn ngữ lập trình, ph−ơng pháp thiết kế , yêu cầu về phân phát 3. Các yêu cầu ngoại lai: tức là các yêu cầu không phải về sản phẩm cũng không phải về quá trình phát triển: chẳng hạn nh− về giao tiếp với các hệ thống khác, về pháp lý, về chi phí, về nhóm những ng−ời phát triển và Tuỳ theo các tổ chức cụ thể, đặc tả yêu cầu có thể đ−ợc thể hiện bằng các cách khác nhau kể từ mức phát biểu bằng ngôn ngữ tự nhiên về các dịch vụ mà hệ cần cung cấp đến mức đặc tả hệ thống một cách hình thức kiểu toán học. Danh giới giữa các yêu cầu và đặc tả hình thức là một thứ rất tinh tế và các thuật ngữ này lại còn có thể đ−ợc dùng theo nghĩa nh− nhau. Việc xác định đặc tả yêu cầu là khó khăn vì những lí do sau: ___Ch−ơng II. 39 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ 1. Các hệ phần mềm lớn th−ờng đ−ợc yêu cầu cải thiện dựa trên nguyên trạng: hoặc không có hệ thống nào hoặc có một hệ thống không đầy đủ. Mặc dầu có thể biết các khó khăn của hệ thống hiện có nh−ng lại rất khó dự đoán đ−ợc hiệu quả của hệ thống đã đ−ợc cải thiện đối với tổ chức đó. 2. Các hệ thống lớn th−ờng có một cộng đồng ng−ời sử dụng đa dạng, họ có những yêu cầu và −u tiên khác nhau, thậm chí là mâu thuẫn với nhau. Cuối cùng thì các yêu cầu hệ thống cũng không thể tránh đ−ợc sự thoả hiệp. 3. Những ng−ời bỏ tiền ra mua sắm hệ thống và những ng−ời sử dụng hệ thống hiếm khi lại là một. Những ng−ời mua sắm hệ thống đặt ra các yêu cầu theo những ràng buộc của tổ chức cơ quan và của ngân sách. Những cái đó lại th−ờng mâu thuẫn với các yêu cầu thực sự của ng−ời dùng. Thẩm định yêu cầu Một khi đã thiết lập các yêu cầu thì phải thẩm định xem chúng có thoả mãn các nhu cầu của ng−ời mua hệ thống hay không. Nếu việc thẩm định không phù hợp thì các sai lầm có thể lan truyền sang các giai đoạn thiết kế và thực hiện. Khi đó có thể cần đến các sự cải biên hệ thống tốn kém để làm cho nó đúng đắn. Có 4 b−ớc liên quan đến việc thẩm định yêu cầu : 1. Phải chỉ ra rằng các nhu cầu của ng−ời dùng là đ−ợc thoả mãn 2. Các yêu cầu phải không gây ra mâu thuẫn nhau 3. Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà ng−ời dùng đã nhắm đến 4. Các yêu cầu phải là hiện thực II.3.Đặc tả hệ thống và việc tạo nguyên mẫu II.3.1 Đặc tả hệ thống a.Đặc tả hệ thống Bản Đặc tả hệ thống: +là một tài liệu nền tảng cho kỹ nghệ phần cứng, kỹ nghệ phần mềm , kỹ nghệ cơ sở dữ liệu và kỹ nghệ con ng−ời. +mô tả về chức năng và hiệu suất của hệ thống và những ràng buộc hệ thống. +quy định cả giới hạn cho từng phần tử hệ thống. Chẳng hạn, chỉ dẫn về vai trò của phần mềm trong hệ thống và các hệ thống con khác nhau đ−ợc mô tả trong biểu đồ luồng kiến trúc. +mô tả thông tin (dữ liệu và điều khiển) vào và ra khỏi hệ thống . Dàn bài về bản đặc tả hệ thống sẽ đ−ợc trình bày sau đây. Tuy nhiên cần l−u ý rằng đây chỉ là một trong nhiều dàn bài có thể đ−ợc dùng để định nghĩa một tài liệu mô tả hệ thống. Định dạng và nội dung thực tế có thể còn tuỳ vào các chuẩn kỹ nghệ hệ thống hay phần mềm. Nó đ−ợc điều chỉnh theo yêu cầu và tính −a chuộng của ng−ời dùng. Ví dụ về dàn bài đặc tả hệ thống: I.Giới thiệu A.Phạm vi và mục tiêu của dự án B.Tổng quan 1.Mục tiêu 2.Ràng buộc ___Ch−ơng II. 40 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ II.Mô tả chức năng và dữ liệu A.Kiến trúc hệ thống 1.Biểu đồ ngữ cảnh kiến trúc 2.Mô tả về biểu đồ ngữ cảnh hệ thống III.Mô tả các hệ thống con A.Đặc tả biểu đồ kiến trúc cho hệ con n 1.Biểu đồ luồng kiến trúc 2.Chú giải modul hệ thống 3.Vấn đề về hiệu suất 4.Ràng buộc thiết kế 5.Cách tạo các thành phần hệ thống B.Từ điển kiến trúc C.Biểu đồ và mô tả liên nối hệ thống IV.Các kết quả mô hình hoá và mô A.Mô hình hệ thống đ−ợc dùng cho mô phỏng phỏng hệ thống B.Kết quả mô phỏng C.Vấn đề hiệu suất đặc biệt V.Vấn đề dự án A.Chi phí xây dựng dự phòng B.Lịch biểu dự phòng VI.Phụ lục b)Xét duyệt về đặc tả hệ thống Cuộc xét duyệt đặc tả hệ thống đánh giá tính đúng đắn của định nghĩa đ−ợc chứa trong bản đặc tả hệ thống . +Cuộc họp đ−ợc cả ng−ời phát triển và khách hàng đảm bảo rằng: 1. Phạm vi của dự án đã đ−ợc vạch ra đúng 2. Các chức năng , hiệu suất và giao diện đã đ−ợc định nghĩa đúng 3. Phân tích về rủi ro môi tr−ờng và tính khả triển của dự án 4. Ng−ời phát triển và khách hàng có cùng cảm nhận về mục tiêu hệ thống . + Cuộc họp đặc tả hệ thống đ−ợc tiến hành trong hai đoạn: Đ−a ra những quan điểm quản lý áp cho hệ thống Tiến hành đánh giá kỹ thuật về các phần tử và chức năng hệ thống +Về khía cạnh quản lý, đặc tả hệ thống cần phải thoả những câu hỏi sau: • Nhu cầu kinh doanh của hãng đã đ−ợc thiết lập c h−a? Luận chứng hệ thống có nghĩa không ? • Có cần môi tr−ờng (hay thị tr−ờng) riêng cho hệ thống đã đ−ợc mô tả hay không ? • Những ph−ơng án nào đã đ−ợc xem xét? • Rủi ro phát triển cho từng phần tử hệ thống là gì? • Các tài nguyên đã có sẵn cho việc xây dựng hệ thống ch−a? • Các giới hạn chi phí và lịch biểu có ý nghĩa gì không ? Các câu hỏi trên nên đ−ợc đặt ra và trả lời một cách đều đặn trong nhiệm vụ phân tích . Mỗi câu hỏi nên đ−ợc xem xét lại tại giai đoạn đánh giá kỹ thuật . Mức độ chi tiết trong giai đoạn đánh giá kỹ thuật (họp xét duyệt hệ thống) phụ thuộc vào mức độ chi tiết trong nhiêm vụ xác định ban đầu. Việc xét duyệt nên bao gồm các vấn đề sau: • Về chức năng của hệ thống: có phù hợp với những định giá về rủi ro phát triển, chi phí và lịch biểu hay không ? • Các chức năng đ−ợc xác định đã đủ chi tiết ch−a? • Giao diện giữa các phần tử hệ thống và với môi tr−ờng đã đ−ợc xác định đủ chi tiết ch−a? • các vấn đề độ tin cậy, hiệu suất và bảo trì đã đ−ợc đề cập tới trong bản đặc tả ch−a? ___Ch−ơng II. 41 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ • Liệu bản đặc tả hệ thống có cung cấp đủ nền tảng cho các b−ớc kỹ nghệ phần cứng và phần mềm tiếp sau không ? Nhận xét: • Sau cuộc họp xét duyệt, đồng thời tiến hành các tiến trình kỹ nghệ t−ơng ứng với các phần tử hệ thống chủ chốt nh− phần mềm , phần cứng, con ng−ời và CSDL.Các phần tử phần cứng, con ng−ời và CSDL của hệ thống đ−ợc đề cập tới nh− phần t−ơng ứng của các tiến trình kỹ nghệ • Tại b−ớc phân tích hệ thống, ng−ời phân tích xác định ra nhu cầu của khách hàng, xác định tính khả thi kinh tế - kỹ thuật, xác định chức năng và hiệu suất cho các phần tử hệ thống chủ chốt (phần mềm, phần cứng, con ng−ời và CSDL). • Bản đặc tả hệ thống (tài liệu nền tảng cho toàn bộ công việc kỹ nghệ tiếp sau đó) đ−ợc coi là đỉnh cao của nhiệm vụ kỹ nghệ hệ thống. • Phải đảm bảo việc trao đổi đều đặn và liên lạc giữa khách hàng và nhà phân tích vì nếu trao đổi giữa nhà phân tích và khách hàng bị gián đoạn tại giai đoạn này thì sự thành công của toàn bộ dự án sẽ bị đe doạ. • Khó khăn là ở chỗ phải lập các t− liệu hệ thống sao cho: +dễ hiểu cho ng−ời sử dụng +xuất ra một đặc tả hệ thống (cùng với đặc tả yêu cầu đ−ợc dùng làm cơ sở cho một hợp đồng giữa ng−ời mua và ng−ời cung cấp phần mềm đó). Nói chung, ng−ời dùng −a thích một mô tả hệ thống trừu t−ợng chứ không thích một đặc tả chi tiết. II.3.2. Tạo nguyên mẫu Duyệt lại là một phần của quá trình thẩm định yêu cầu. Từ đặc tả yêu cầu t−ởng t−ợng đ−ợc hệ thống sẽ đ−ợc sử dụng nh− thế nào. Một chức năng đ−ợc mô tả trong một đặc tả là hữu ích và đã đ−ợc xác định tốt nh−ng thực tế việc sử dụng chức năng đó kết hợp với các chức năng khác lại để lộ ra rằng cái nhìn ban đầu của ng−ời sử dụng đã không đúng và không đầy đủ. Một cách giải quyết khó khăn đó là phát triển một nguyên mẫu hệ thống cho phép ng−ời sử dụng thí nghiệm trên nguyên mẫu đó. Các yêu cầu của hệ thống đ−ợc thẩm định và ng−ời dùng phát hiện ra các sai sót. Sự khác biệt với nguyên mẫu phần cứng: Nguyên mẫu phần mềm hoàn toàn khác với nguyên mẫu phần cứng. Khi phát triển các hệ thống phần cứng, thì thực tế ng−ời ta phát triển một nguyên mẫu hệ thống để thẩm định thiết kế hệ thống. Một nguyên mẫu hệ thống điện tử có thể đ−ợc thực hiện và đ−ợc thử nghiệm bằng cách dùng các thành phần ch−a đ−ợc lắp ráp vào vỏ tr−ớc khi đầu t− vào các mạch tích hợp chuyên dụng đắt tiền để thực hiện một đời sản phẩm mới của hệ thống. Một nguyên mẫu phần mềm là không phải nhằm vào việc thẩm định thiết kế (thiết kế của nó th−ờng là hoàn toàn khác với hệ thống đã phát triển cuối cùng), mà là để thẩm định yêu cầu của ng−ời sử dụng. Lợi ích của việc phát triển nguyên mẫu ngay từ sớm trong quá trình phần mềm là: 1. Sự hiểu lầm giữa những ng−ời phát triển phần mềm và những ng−ời sử dụng phần mềm có thể đ−ợc nhận thấy rõ khi các chức năng của hệ thống đ−ợc trình diễn 2. Sự thiếu hụt các dịch vụ ng−ời dùng có thể đ−ợc phát hiện 3. Sự khó sử dụng hoặc sự nhầm lẫn các dịch vụ ng−ời dùng có thể đ−ợc thấy rõ và đ−ợc sửa sang lại 4. Đội ngũ phát triển phần mềm có thể tìm ra đựơc các yêu cầu không đầy đủ hoặc không kiên định khi họ phát triển nguyên mẫu 5. Một hệ thống hoạt động đ−ợc (mặc dầu là hạn chế) là bằng chứng thuyết m inh cho tính khả thi và tính hữu ích của ứng dụng đó cho các nhà quản lý ___Ch−ơng II. 42 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ 6. Nguyên mẫu đó đ−ợc dùng làm cơ sở cho việc viết đặc tả một sản phẩm Mặc dù mục tiêu chủ yếu của việc tạo nguyên mẫu là để thẩm định các yêu cầu phần mềm cũng nên chỉ ra rằng một nguyên mẫu phần mềm cũng có các ứng dụng khác: 1. Dùng để huấn luyện ng−ời sử dụng ngay từ tr−ớc khi hệ thống đ−ợc phân phối 2. Dùng trong quá trình thử nghiệm hệ thống. Điều đó nghĩa là cùng các tr−ờng hợp thử nh− nhau vừa dùng cho thử nguyên mẫu vừa cho thử hệ thống. Kết quả khác nhau có nghĩa là có sai sót Tạo nguyên mẫu là một kỹ thuật giảm bớt rủi ro. Một rủi ro lớn trong việc phát triển phần mềm là các sai sót mà đến giai đoạn cuối mới phát hiện và chỉnh sửa là rất tốn kém. Kinh nghiệm cho hay rằng việc tạo nguyên mẫu sẽ giảm bớt số các vấn đề của đặc tả yêu cầu và giá cả tổng cộng của việc phát triển có thể là thấp hơn nếu ta phát triển nguyên mẫu. Có 4 giai đoạn trong việc phát triển nguyên mẫu: 1. Thiết lập các mục tiêu của việc tạo nguyên mẫu, quyết định chọn input, output cho nguyên mẫu 2. Chọn các chức năng cho việc tạo nguyên mẫu và quyết định những đặc tả phi chức năng nào cần phải tạo nguyên mẫu 3. Phát triển nguyên mẫu 4. Đánh giá hệ nguyên mẫu Cần phải làm rõ ràng các mục tiêu tạo nguyên mẫu tr−ớc khi bắt đầu công việc. Mục tiêu đó có thể là phát triển một hệ thống liên quan chủ yếu đến tạo nguyên mẫu giao diện ng−ời dùng; nó cũng có thể là việc phát triển một hệ thống thẩm định các yêu cầu hệ thống chức năng , nó cũng có thể là phát triển một hệ thống để trình diễn tính khả thi của ứng dụng cho các nhà quản lý xem xét, Cùng một nguyên mẫu không thể đạt đ−ợc tất cả các mục tiêu. Nếu mục tiêu còn ch−a rõ ràng thì ng−ời quản lý hoặc ng−ời sử dụng có thể hiểu nhầm chức năng của nguyên mâũ và không đạt đ−ợc lợi ích thiết thực đầy đủ của việc tạo nguyên mẫu. Giai đoạn tiếp theo trong quá trình này là quyết định xem cái gì đ−ợc đ−a vào và cái gì đ−ợc lấy ra từ hệ nguyên mẫu đó. Nguyên mẫu của phần mềm là đắt nếu nó đ−ợc thực hiện bằng cách dùng cùng các công cụ và các chuẩn y nh− cho chính hệ thống cuối cùng Bởi vậy, có thể quyết định tạo nguyên mẫu tất cả các chức năng của hệ thống nh−ng ở mức thu gọn. Cũng có thể chỉ một số chức năng hệ thống đ−ợc tạo mẫu. Bình th−ờng trong thực tế ng−ời ta hay bỏ bớt các yêu cầu phi chức năng chẳng hạn nh− yêu cầu về tốc độ, về không gian nhớ. Việc xử lý sai sót và việc quản lý có thể lờ đi và có thể là d− thừa trừ phi mục tiêu của việc tạo mẫu là thiết lập một giao diện ng−ời máy. Các chuẩn của độ tin cậyvà của chất l−ợng ch−ơng trình có thể ch−a tính đến. Giai đoạn cuối cùng của quá trình này là đánh giá nguyên mẫu, Có ng−ời cho rằng đây là giai đoạn quan trọng nhất của việc tạo nguyên mẫu. Phải dự tính cho việc huấn luyện ng−ời sử dụng trong giai đoạn này và và các mục tiêu của việc tạo mẫu hẳn là nên dẫn ra một kế hoạch đánh giá. Phải có đủ thời gian cho ng−ời sử dụng trở nên dễ chịu với hệ thống và thiết lập một mẫu sử dụng chuẩn tắc và bởi vậy phát hiện đ−ợc các sai sót yêu cầu . Việc tạo nguyên mẫu là kỹ thuật chính trong mô hình quá trình xoắn ốc hỗ trợ định giá rủi ro. Tạo nguyên mẫu trong quá trình phần mềm Vấn đề cơ bản là khó đánh giá phần mềm mới đ−ợc xây dựng có ảnh h−ởng thế nào tới công việc của ng−ời dùng. Đối với các hệ thống mới, đặc biệt là đối với các hệ thống lớn và phức tạp thì có lẽ là không thể đánh giá đ−ợc tr−ớc khi hệ thống đ−ợc xây dựng xong và đ−a vào ứng dụng ___Ch−ơng II. 43 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ Một cách để v−ợt qua khó khăn này là sử dụng cách tiếp cận thăm dò để phát triển hệ thống . Điều này có nghĩa là trình bày cho ng−ời dùng một hệ thống ch−a đầy đủ và rồi cải biên nó tăng c−ờng hệ thống đó khi mà các yêu cầu thực của ng−ời dùng trở nên trong suốt. Sau khi đánh giá nguyên mẫu đó bị thải loại và một hệ chất l−ợng tốt hơn đ−ợc xây dựng. ___Ch−ơng II. 44 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ Thiết lập đặc tả, Thiết lập nguyên tắc chung phát triển nguyên mẫu đánh giá nguyên mẫu đặc tả hệ thống thiết kế và thực thi hệ thống thẩm định hệ thống Việc tạo nguyên mẫu trong quá trình phần mềm Sự khác biệt của hai cách tiếp cận: 1. Lập trình thăm dò bắt đầu với một hiểu biết mơ hồ về yêu cầu hệ thống và hệ thống sẽ đ−ợc tăng c−ờng một khi các yêu cầu mới đ−ợc phát hiện. Chẳng có gì giống nh− một đặc tả hệ thống !, và sự thật hệ thống đ−ợc phát triển theo cách tiếp cận này không thể đặc tả đ−ợc. (một vài hệ trí tuệ nhân tạo là không thể đặc tả đ−ợc). 2. Cách tiếp cận tạo nguyên mẫu: +nhằm phát hiện ra đặc tả hệ thống để kết quả của giai đoạn phát triển nguyên mẫu là đặc tả đó. +mở rộng quá trình phân tích yêu cầu nhằm rút bớt tổng số chi phí cho toàn bộ vòng đời phần mềm . +làm sáng tỏ các yêu cầu, +cung cấp các thông tin phụ cho ng−ời quản lý để họ đánh giá các rủi ro của quá trình. Sau khi đánh giá, nguyên mẫu đó không dùng để phát triển hệ thống nữa. Thay thế cho việc dẫn xuất ra đặc tả từ nguyên mẫu, đôi khi ng−ời ta đề xuất là đặc tả hệ thống chính là sự thực hiện nguyên mẫu đó. Chỉ dẫn này giúp ng−ời ký hợp đồng chỉ đơn giản là hãy viết một hệ thống kiểu nh− thế này. Hạn chế của cách tiếp cận tạo nguyên mẫu: 1. Các đặc điểm hệ thống quan trọng có thể nằm ngoài nguyên mẫu để đơn giản hoá việc thực hiện nhanh. Sự thật hẳn là không thể tạo nguyên mẫu một vài phần quan trọng nhất của hệ nh− các đặc điểm về sự an toàn-nguy kịch. 2. Các yêu cầu phi chức năng nh− các yêu cầu liên quan đến độ tin cậy, tính mâu thuẫn và độ an toàn là không thể biểu thị đầy đủ trong một thực hiện nguyên mẫu 3. Ng−ời dùng có thể không dùng nguyên mẫu y nh− cách dùng một hệ đang hoạt động Một vài lý do dẫn tới việc tái tạo nguyên mẫu khi một hệ thống lớn và tuổi thọ cao đ−ợc phát triển: ___Ch−ơng II. 45 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ 1. Các đặc tr−ng hệ thống quan trọng chẳng hạn nh− sự thực thi, sự an ninh, tính không mâu thuẫn, độ tin cậy có thể đ−ợc lờ đi khi tạo nguyên mẫu để cho có thể thực thi nhanh nguyên mẫu. Bản chất của nguyên mẫu có thể lại là những thứ đó không thể thêm vào nguyên mẫu. 2. Trong quá trình phát triển nguyên mẫu thì nguyên mẫu sẽ bị thay đổi để phản ánh các nhu cầu của ng−ời dùng và hình nh− là các thay đổi đó sẽ đ−ợc tiến hành theo một cách không thể khống chế đ−ợc 3. Các thay đổi trong quá trình phát triển nguyên mẫu sẽ có thể làm giảm sút cấu trúc hệ thống đến mức mà do yêu cầu baỏ trì thì các thay đổi tiếp theo càng ngày càng trở nên khó hơn Phát triển tiến hoá là dễ quản lý hơn lập trình thăm dò vì rằng các chuẩn quá trình phần mềm chuẩn tắc là đ−ợc tuân theo. Các kế hoạch và các t− liệu có thể viết thêm cho mỗi phần gia tăng. Các b−ớc tiến hành làm bản mẫu phần mềm : B−ớc 1: Đánh giá yêu cầu phần mềm và xác định liệu phần mềm cần xây dựng có xứng đáng để làm bản mẫu không Không phải tất cả các phần mềm đều có thể đ−a tới làm bản mẫu. Ta có thể xác định một số nhân tố làm bản mẫu: lĩnh vực ứng dụng, độ phức tạp ứng dụng, đặc tr−ng khách hàng và đặc tr−ng dự án Nói chung, bất kỳ ứng dụng nào tạo ra việc hiển thị trực quan động, t−ơng tác nhiều với con ng−ời, hay yêu cầu các thuật toán hay việc xử lý tổ hợp mà cần phải đ−ợc xây dựng theo một cách tiến hoá thì đều có thể làm bản mẫu. Tuy nhiên, những lĩnh vực ứng dụng này phải đ−ợc cân nhắc dựa trên độ phức tạp của ứng dụng. Nếu một ứng dụng yêu cầu xây dựng tới 10 ngàn dòng mã lệnh thì phần chắc là nó quá phức tạp không thể làm bản mẫu đ−ợc. Tuy nhiên nếu ta có thể phân hoạch độ phức tạp thì vẫn có thể làm bản mẫu cho từng phần của phần mềm. Để đảm bảo tính t−ơng tác giữa khách hàng với bản mẫu cần: 1. Khách hàng phải cam kết dùng tài nguyên để đánh giá và làm mịn bản mẫu 2. Khách hàng phải có khả năng đ−a ra những quyết định về yêu cầu một cách kịp thời Bản chất của dự án quyết định tính hiệu quả của làm bản mẫu B−ớc 2: Với một dự án chấp thuận đ−ợc, ng−ời phân tích xây đựng một cách biểu diễn vắn tắt cho yêu cầu Tr−ớc khi có thể bắt đầu xây dựng một bản mẫu, ng−ời phân tích phải biểu diễn miền thông tin và các lĩnh vực hành vi và chức năng của vấn đề rồi xây dựng một cách tiếp cận hợp lý tới việc phân hoạch. Có thể ứng dụng các nguyên lí phân tích nền tảng (trên xuống) và các ph−ơng pháp phân tích yêu cầu . B−ớc 3: Sau khi đã duyệt xét mô hình yêu cầu, tạo ra một đặc tả thiết kế vắn tăt cho bản mẫu Việc thiết kế phải xuất hiện tr−ớc khi bắt đầu làm bản mẫu. Tuy nhiên thiết kế tập trung chủ yếu vào các vấn đề thiết kế dữ liệu và kiến trúc mức đỉnh chứ không tập trung vào thiết kế thủ tục chi tiết. B−ớc 4: phần mềm bản mẫu đ−ợc tạo ra, kiểm thử và làm mịn. Một cách lý t−ởng, các khối xây dựng phần mềm hiện có đ−ợc dùng để tạo ra bản mẫu một cách nhanh chóng B−ớc 5: Một khi đã kiểm thử xong bản mẫu thì có thể trình bày nó cho khách hàng ___Ch−ơng II. 46 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng
- Kỹ nghệ phần mềm ___ Ng−ời sẽ kiểm thử ứng dụng và gợi ý những thay đổi. B−ớc này là cốt lõi của cách tiếp cận làm bản mẫu. Chính ở đây mà khách hàng có thể xem xét cách biểu diễn đ−ợc cài đặt cho yêu cầu phần mềm, gợi ý những thay đổi làm cho phần mềm đáp ứng tốt hơn với các nhu cầu thực tế B−ớc 6: Lặp lại các b−ớc 4 và 5 cho tới khi tất cả các yêu cầu đã đ−ợc hình thức hoá hay cho tới khi bản mẫu đã tiến hoá thành một hệ thống sản xuất Khuôn cảnh làm bản mẫu có thể đ−ợc tiến hành với một trong 2 mục tiêu: 1. Mục tiêu của việc làm bản mẫu là thiết lập một tập hợp các yêu cầu hình thức có thể đ−ợc dịch thành phần mềm (sản xuất bằng các ph−ơng pháp và kỹ thuật của kỹ nghệ phần mềm ) 2. Mục tiêu cuả việc làm bản mẫu là cung cấp động lực liên tục thúc đẩy phát triển tiến hoá phần mềm. Các ph−ơng pháp và công cụ làm bản mẫu Để việc làm bản mẫu phần mềm đ−ợc hiệu quả, phải xây dựng nhanh chóng bản mẫu sao cho khách hàng có thể định giá đ−ợc kết quả và khuyến cáo những thay đổi. Để xây dựng bản mẫu nhanh, hiện đã có 3 lớp ph−ơng pháp và công cụ sẵn có: 1. Các kỹ thuật thế hệ 4 2. Thành phần phần mềm dùng lại 3. Đặc tả hình thức và môi tr−ờng làm bản mẫu • Kỹ thuật thế hệ 4 Các kỹ thuật thế hệ 4 (4GT) bao gồm một phạm vi rộng các ngôn ngữ hỏi CSDL và làm báo cáo, các bộ sinh ch−ơng trình và ứng dụng các ngôn ngữ phi thủ tục cấp rất cao khác. Bởi vì 4GT sinh đ−ợc mã thực hiện rất nhanh nên chúng là lí t−ởng cho việc làm bản mẫu nhanh. Mặc dầu lĩnh vực ứng dụng cho 4GT hiện tại vẫn còn bị giới hạn vào các hệ thông tin kinh doanh, nh−ng công cụ cho các ứng dụng kỹ nghệ đang bắt đầu chiếm −u thế. • Thành phần phần mềm dùng lại Một cách tiếp cận khác tới việc làm bản mẫu nhanh là lắp ráp, thay vì xây dựng, bản mẫu bằng cách dùng một tập hợp các thành phần phần mềm đã có sẵn. Một thành phần phần mềm có thể là một cấu trúc dữ liệu (hay CSDL) hay một thành phần kiến trúc phần mềm (nh− ch−ơng trình) hay một thành phần thủ tục (nh− một modul). Trong mỗi tr−ờng hợp thành phần phần mềm phải đ−ợc thiết kế theo cách thức làm cho nó có thể dùng lại đ−ợc mà không cần biết chi tiết về cách làm việc bên trong Việc làm bản mẫu và việc dùng lại các thành phần ch−ơng trình chỉ hoạt động đ−ợc nếu hệ thống th− viện đã đ−ợc phát triển sao cho các thành phần thực tồn tại có thể đ−ợc đ−a vào danh mục rồi tìm kiếm. Mặc dầu ng−ời ta đã tạo ra một số công cụ để đáp ứng nhu cầu này, vẫn còn nhiều việc cần phải làm nữa. Cũng nên l−u ý rằng một sản phẩm phần mềm hiện có thể đ−ợc dùng nh− bản mẫu cho một sản phẩm cạnh tranh "mới, đã đ−ợc cải tiến". Mặt khác, đây cũng là một hình thức của việc dùng lại cho việc làm bản mẫu phần mềm • Đặc tả hình thức và môi tr−ờng làm bản mẫu Một số ngôn ngữ và công cụ đặc tả hình thức cũng đã đ−ợc xây dựng xem nh− một sự thay thế cho các kỹ thuật đặc tả theo ngôn ngữ tự nhiên. Các ngôn ngữ này đang trong tiến trình phát triển các môi tr−ờng t−ơng tác: 1. Làm cho ng−ời phân tích tạo ra cách t−ơng tác một đặc tả về hệ thống hay phần mềm dựa trên ngôn ngữ 2. Gọi tự động các công cụ dịch đặc tả dựa trên ngôn ngữ này thành mã thực hiện đ−ợc 3. Làm cho khách hàng có thể dùng bản mẫu ch−ơng trình theo mã thực hiện đ−ợc để làm mịn các yêu cầu hình thức. Các ngôn ngữ đặc tả nh− PSL,RSL,IORL,GYPSY,OBJ và nhiều ngôn ngữ ___Ch−ơng II. 47 Nguyễn Quốc Toản- Nguyên văn Vỵ - Vu Đức Thi- Lê Đình Phùng