ĐẠi học quốc gia hà NỘi trường Đại học Công nghệ Nguyễn Việt Hà Bài giảng
tải về 454.68 Kb.
|
- Điều hướng trang này:
- 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.5 Kỹ thuật thế hệ thứ tư
- 1.3.6 Mô hình lập trình cực đoan
- 1.3.7 Tổ hợp các mô hình
- 1.3.8 Tính khả thị của quá trình kỹ nghệ
- 1.3.9 Vấn đề giảm kích cỡ của phần mềm
1.3 Kỹ nghệ phần mềm1.3.1 Định nghĩaMột định nghĩa ban đầu về kỹ nghệ phần mềm do Fritz Bauer nêu ra 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. Kỹ nghệ phần mềm là một quá trình gồm một loạt 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, 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ả, trong những giới hạn nhất định.
a. Các phương phápChỉ ra cách làm về mặt kỹ thuật để xây dựng phần mềm, được sử dụng trong các bước: 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ã hóa 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 đồ họa hay hướng ngôn ngữ đặc biệt, cách thức thực hiện và một tập các tiêu chuẩn về chất lượng của sản phẩm phần mềm. b. Các công cụCung cấp sự hỗ trợ tự động hay bán tự động để phát triển phần mềm theo từng phương pháp khác nhau. 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ợ 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 - Computer Aided Software Engineering). c. Các thủ tụcCác thủ tục là chất keo dán các phương pháp và công cụ lại với nhau 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 bao gồm: - Xác định ra trình tự các phương pháp sẽ được áp dụng cho mỗi dự án. - 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 hòa thay đổi. - Xác định những cột mốc mà tại đó có các sản phẩm nhất định được bàn giao để cho người quản lý phần mềm nắm được tiến độ và kiểm soát được kết quả. Sau đây, chúng ta sẽ xem xét một số cách tiếp cận (còn gọi là mô hình hay khuôn cảnh) cơ bản trong tiến trình phát triển phần mềm.
a. Kỹ nghệ và phân tích hệ thốngKỹ 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. Mục đích của bước này là xác định khái quát về phạm vi, yêu cầu cũng như tính khả thi của phần mềm. b. Phân tích yêu cầu phần mềm- Phân tích yêu cầu được tập trung việc thu thập và phân tích các thông tin cần cho phần mềm, các chức năng cần phải thực hiện, hiệu năng cần có và các giao diện cho người sử dụng. - Kết quả của phân tích là tư liệu về yêu cầu cho hệ thống và phần mềm (đặc tả yêu cầu) để khách hàng duyệt lại và dùng làm tài liệu cho người phát triển. c. Thiết kế- Là quá trình chuyển hóa các yêu cầu phần mềm thành các mô tả thiết kế - Thiết kế gồm nhiều bước, thường tập trung vào 4 công việc chính: thiết kế kiến trúc phần mềm, thiết kế cấu trúc dữ liệu, thiết kế chi tiết các thủ tục, thiết kế giao diện và tương tác. - Lập tư liệu thiết kế (là một phần của cấu hình phần mềm) để phê duyệt
d. Mã hóaBiểu diễn thiết kế bằng một hay một số ngôn ngữ lập trình và dịch thành mã máy thực hiện được. e. Kiểm thửTiến trình kiểm thử bao gồm việc i) phát hiện và sửa lỗi phần logic bên trong chương trình hay còn gọi là lỗi lập trình, ii) kiểm tra xem phần mềm có hoạt động như mong muốn không, tức là phát hiện và sửa lỗi về chức năng như thiếu hụt, sai sót về chức năng; và kiểm tra xem phần mềm có đảm bảo tính hiệu quả trong thực hiện hay không.
f. Bảo trìBao gồm các công việc sửa các lỗi phát sinh khi áp dụng chương trình hoặc thích ứng nó 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, yêu cầu người dùng) hoặc yêu cầu bổ sung chức năng hay nâng cao hiệu năng cần có. Một số các vấn đề có thể gặp phải khi dùng mô hình vòng đời cổ điển là: 1. Các dự án thực hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Bao giờ việc lặp lại cũng xuất hiện và tạo ra các vấn đề trong việc áp dụng mô hình này. 2. Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh từ đầu. Vòng đời cổ điển đòi hỏi điều này và thường khó thích hợp với sự bất trắc tự nhiên tồn tại vào lúc đầu của nhiều dự án. 3. Đòi hỏi khách hàng phải kiên nhẫn. Bản làm việc được của chương trình chỉ có được vào lúc cuối của thời gian dự án. Một sai sót nhỏ trong phân tích/thiết kế nếu đến khi có chương trình làm việc mới phát hiện ra, có thể sẽ là một thảm họa. Tuy vậy, mô hình vòng đời cổ điển có một vị trí quan trọng trong công việc về kỹ nghệ phần mềm. Nó đưa ra một tiêu bản trong đó có thể bố trí các phương pháp cho phân tích, thiết kế, mã hóa, kiểm thử và bảo trì. Vòng đời cổ điển vẫn còn là một mô hình được sử dụng rộng rãi, nhất là đối với các dự án vừa và nhỏ. 
Hình 1.1: Mô hình vòng đời cổ điển. 1.3.3 Mô hình làm bản mẫuCách tiếp cận làm bản mẫu cho kỹ nghệ phần mềm là cách tiếp cận tốt nhất khi: - Mục tiêu tổng quát cho phần mềm đã xác định, nhưng chưa xác định được input và output. - Người phát triển không chắc về hiệu quả của thuật toán, về thích nghi hệ điều hành hay giao diện người máy cần có. Khi đã có bản mẫu, người phát triển có thể dùng chương trình đã có hay các công cụ phần mềm trợ giúp để sinh ra chương trình làm việc. Làm bản mẫu là tạo ra một mô hình cho phần mềm cần xây dựng. Mô hình có thể có 3 dạng: 1. Bản mẫu trên giấy hay trên máy tính mô tả giao diện người-máy làm người dùng hiểu được cách các tương tác xuất hiện. 2. Bản mẫu cài đặt chỉ một tập con chức năng của phần mềm mong đợi. 3. Bản mẫu là một chương trình có thể thực hiện một phần hay tất cả chức năng mong muốn nhưng ở mức sơ lược và cần cải tiến thêm các tính năng khác tùy theo khả năng phát triển. Trước hết người phát triển và khách hàng gặp nhau và xác định mục tiêu tổng thể cho phần mềm, xác định các yêu cầu đã biết, các miền cần khảo sát thêm. Tiếp theo là giai đoạn thiết kế nhanh, tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng (input và output), và xây dựng một bản mẫu. Người dùng đánh giá và làm mịn các yêu cầu cho phần mềm. Tiến trình này lặp đi lặp lại cho đến khi bản mẫu thoả mãn yêu cầu của khách hàng, đồng thời giúp người phát triển hiểu kỹ hơn nhu cầu nào cần phải thực hiện (hình 1.2). Một biến thể của mô hình này là mô hình thăm dò, trong đó các yêu cầu được cập nhật liên tục và bản mẫu được tiến hóa liên tục để trở thành sản phẩm cuối cùng. Mô hình làm bản mẫu có một số vấn đề như: • Do sự hoàn thiện dần (tiến hóa) của bản mẫu, phần mềm nhiều khi có tính cấu trúc không cao, dẫn đến khó kiểm soát, khó bảo trì. • Khách hàng nhiều khi thất vọng với việc phát triển phần mềm do họ nhầm tưởng bản mẫu là sản phẩm cuối cùng hướng tới người sử dụng. Khách hàng cũng có thể không dành nhiều công sức vào đánh giá bản mẫu.  
Hình 1.2: Mô hình làm bản mẫu. 1.3.4 Mô hình xoắn ốcMô hình xoắn ốc được Boehm đưa ra năm 1988. Mô hình này đưa thêm vào 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 bước lặp lại, mỗi bước bắt đầu bằng việc phân tích rủi ro rồi tạo bản mẫu, cải tạo và phát triển bản mẫu, duyệt lại, và cứ thế tiếp tục (hình 1.3). Nội dung một bước gồm bốn hoạt động chính: - Lập kế hoạch: xác định mục tiêu, các giải pháp và ràng buộc - 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 - Kỹ nghệ: phát triển sản phẩm “mức tiếp theo” - Đánh giá: đánh giá của khách hàng về kết quả của kỹ nghệ Với mỗi lần lặp xoắn ốc (bắt đầu từ tâ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 yêu cầu không chắc chắn thì bản mẫu có thể được sử dụng trong giai đoạn 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. Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “tiến hành tiếp hay dừng”. Nếu rủi ro quá lớn thì có thể đình chỉ dự án. Mô hình xoắn ốc cũng có một số vấn đề như khó thuyết phục những khách hàng lớn rằng cách tiếp cận tiến hóa là kiểm soát được. Nó đòi hỏi tri thức chuyên gia đánh giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt được thành công. Mô hình xoắn ốc đòi hỏi năng lực quản lý cao, nếu không quản lý tốt thì rất dễ rơi vào trạng thái sửa đổi cục bộ không có kế hoạch của mô hình làm bản mẫu (thăm dò). Và mô hình này còn tương đối mới và còn chưa được sử dụng rộng rãi như vòng đời hoặc làm bản mẫu. Cần phải có thêm một số năm nữa trước khi người ta có thể xác định được tính hiệu quả của mô hình này với sự chắc chắn hoàn toàn.  
Hình 1.3: Mô hình xoắn ốc. 1.3.5 Kỹ thuật thế hệ thứ tưThuật ngữ kỹ thuật thế hệ thứ tư (4GT - fourth generation technology) bao gồm một phạm vi rộng các công cụ phần mềm có các điểm chung: 1. Cho phép người phát triển xác định một số đặc trưng của phần mềm ở mức cao. 2. Tự động sinh ra mã chương trình gốc theo nhu cầu của người phát triển. Hiển nhiên là phần mềm được biểu diễn ở mức trừu tượng càng cao thì chương trình có thể được xây dựng càng nhanh hơn. Mô hình 4GT đối với kỹ nghệ phần mềm tập trung vào khả năng xác định phần mềm đối với một máy ở mức độ gần với ngôn ngữ tự nhiên hay dùng một ký pháp đem lại chức năng có ý nghĩa. Hiện tại, một 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ố hay tất cả các công cụ sau: 1. ngôn ngữ phi thủ tục để truy vấn CSDL 2. bộ sinh báo cáo 3. bộ thao tác dữ liệu 4. bộ tương tác và xác định màn hình 5. bộ sinh chương trình 6. khả năng đồ họa mức cao 7. khả năng làm trang tính 8. khả năng tạo tài liệu Mỗi một trong những công cụ này đã tồn tại, nhưng chỉ cho vài lĩnh vực ứng dụng đặc thù. Ví dụ: các tính năng macro trong các phần mềm bảng tính, cơ sở dữ liệu, khả năng tự sinh mã trong các công cụ thiết kế giao diện “kéo - thả”... Với những ứng dụng nhỏ, có thể chuyển trực tiếp từ bước thu thập yêu cầu sang cài đặt bằng công cụ 4GT. Tuy nhiên với những hệ thống lớn, cần phải có một chiến lược thiết kế. Việc dùng 4GT thiếu thiết kế (với các dự án lớn) sẽ gây ra những khó khăn như chất lượng kém, khó bảo trì khiến cho người dùng khó chấp nhận. Vẫn còn nhiều tranh cãi xung quanh việc dùng khuôn cảnh 4GT: - Người ủng hộ cho là 4GT làm giảm đáng kể thời gian phát triển phần mềm và làm tăng rất nhiều hiệu suất của người xây dựng phần mềm. - Những người phản đối cho là các công cụ 4GT hiện tại không phải tất cả đều dễ dùng hơn các ngôn ngữ lập trình, rằng 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 được phát triển bằng cách dùng 4GT lại mở ra vấn đề mới. Có thể tóm tắt hiện trạng của cách tiếp cận 4GT như sau: 1. Lĩnh vực ứng dụng hiện tại cho 4GT mới chỉ 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 là nhân tố chủ chốt cho các cơ sở dữ liệu lớn. Tuy nhiên, cũng đã xuất hiện các công cụ CASE mới hỗ trợ cho việc dùng 4GT để tự động sinh ra khung chương trình. 2. Đối với các ứng dụng vừa và nhỏ: thời gian cần cho việc tạo ra phần mềm được giảm đáng kể và khối lượng phân tích/thiết kế cũng được rút bớt. 3. Đối với ứng dụng lớn: các hoạt động phân tích, thiết kế và kiểm thử chiếm phần lớn thời gian và việc loại bỏ bớt lập trình bằng cách dùng 4GT nhiều khi đem lại hiệu quả không đáng kể so với tính rườm rà, kém hiệu quả của phần mềm xây dựng bằng phương pháp này. Tóm lại, 4GT đã trở thành một phần quan trọng của việc phát triển phần mềm nghiệp vụ và rất có thể sẽ được sử dụng rộng rãi trong các miền ứng dụng khác trong thời gian tới.
Hai khái niệm độc đáo mới và quan trọng hàng đầu trong XP là “tạo các ca thử nghiệm trước tiên” và “lập trình đôi”. a) Tạo các ca thử nghiệm trước tiênThông thường, thử nghiệm (và trước đó là tạo ca thử nghiệm) được tiến hành vào giai đoạn cuối của quá trình phát triển, khi bạn đã có mã nguồn và chuyển sang kiểm chứng tính đúng đắn của nó. Nhiều trường hợp việc kiểm thử không được coi trọng và chỉ được tiến hành khi bạn còn thời gian và kinh phí. XP thay đổi quan niệm này bằng cách đặt cho kiểm thử một tầm quan trọng ngang bằng (có thể là lớn hơn) việc viết mã. Các ca kiểm thử được thiết kế trước khi viết mã và phải được thực hiện thành công mỗi khi chương trình đích được tạo ra. Tạo ca thử nghiệm trước đem lại nhiều lợi thế. Thứ nhất, nó giúp bạn xác định một cách rõ ràng giao diện của modun. Hơn thế, để tạo được ca thử nghiệm, bạn cần phải hiểu rõ chức năng của nó. Tức là, XP yêu cầu bạn phải hiểu một cách rõ ràng các yêu cầu của modun trước khi bạn bắt tay vào phát triển nó. b) Lập trình đôiXP đưa ra khái niệm mang tính cách mạng (và trái ngược lại quan niệm từ trước đến nay) là mã nguồn của một môđun phải được viết bởi 2 lập trình viên dùng chung một máy tính. Giá trị của lập trình đôi là trong khi một người viết mã thì người thứ hai nghĩ về nó. Người thứ hai này sẽ có trong đầu một bức tranh toàn thể về vấn đề cần giải quyết, chứ không chỉ là giải pháp của đoạn mã lúc đó. Điều này sẽ gián tiếp đảm bảo một chất lượng tốt hơn và dẫn tới một giải pháp mang tính tổng thể hơn. Đồng thời, điều này giúp cho họ theo được các chỉ dẫn của XP, đặc biệt là việc “tạo ca thử nghiệm trước”. Nếu chỉ một người lập trình, họ sẽ rất dễ từ bỏ việc này, nhưng với hai người lập trình cùng làm việc thì họ có thể thay đổi nhau và giữ được các nguyên tắc của XP. 1.3.7 Tổ hợp các mô hìnhChúng ta đã xem xét các mô hình kỹ nghệ phần mềm như là các cách tiếp cận khác nhau tới kỹ nghệ phần mềm chứ không phải là các cách tiếp cận bổ sung cho nhau. Tuy nhiên trong nhiều trường hợp chúng ta có thể và cũng nên tổ hợp các khuôn cảnh để đạt được sức mạnh của từng khuôn cảnh cho một dự án riêng lẻ. Ví dụ, khuôn cảnh xoắn ốc thực hiện điều này một cách trực tiếp, tổ hợp cả làm bản mẫu và các yếu tố của vòng đời cổ điển trong một cách tiếp cận tiến hóa tới kỹ nghệ phần mềm. Các kỹ thuật thế hệ thứ tư có thể đượ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ã hóa của vòng đời cổ điển. Chúng ta có thể làm bản mẫu trong bước phân tích của mô hình vòng đời cổ điển. Kết luận ở đây là chúng ta không nên bị lệ thuộc với bất cứ khuôn cảnh cụ thể nào. Tính chất và qui mô của phần mềm cần phát triển sẽ là yếu tố quyết định tới chọn khuôn cảnh. Mỗi cách tiếp cận đều có ưu điểm riêng và bằng cách tổ hợp khéo léo các cách tiếp cận thì chúng ta sẽ có một phương pháp hỗn hợp ưu việt hơn các phương pháp được dùng độc lập. 1.3.8 Tính khả thị của quá trình kỹ nghệDo đặc điểm là các phần tử lôgic nên quá trình phát triển phần mềm rất khó kiểm soát. Người ta tìm cách khắc phục vấn đề này bằng cách làm cho quá trình phát triển trở nên “nhìn thấy được”, tức là ở mỗi bước (hoạt động) trong tiến trình phát triển phải tạo ra một sản phẩm hay tài liệu tương ứng. Người quản lý dự án và cả khách hàng sẽ tiến hành xét duyệt các tài liệu này. Các tài liệu sẽ trở nên rất hữu ích cho công đoạn kiểm thử và nâng cấp phần mềm. Ví dụ, đối với hoạt động phân tích chúng ta có các tài liệu như: báo cáo nghiên cứu khả thi, mô hình hệ thống, phác họa yêu cầu, đặc tả yêu cầu... Chúng ta hãy so sánh tính khả thị của các khuôn cảnh đã biết: - Vòng đời cổ điển có tính khả thị cao do các bước phát triển tường minh, mô hình xoắn ốc cũng có tính khả thị tốt. - Đối với mô hình làm bản mẫu, nếu tần số sửa chữa là lớn thì tính khả thị kém và việc tạo ra tài liệu là không hiệu quả. - 4GT thì mới chỉ dùng với những ứng dụng nghiệp vụ đặc thù nên khó phát biểu gì về tính khả thị của nó. Việc xây dựng tài liệu cũng có những vấn đề như: - Tạo ra các chi phí phụ làm chậm tiến trình phát triển - Khi phát hiện vấn đề về thiết kế, nhiều khi do không muốn thay đổi các tài liệu đã được xét duyệt, người phát triển có xu hướng dùng các giải pháp cục bộ không hiệu quả. Các mô hình phát triển truyền thống thường chú trọng tới khâu lập tài liệu để nâng cao tính khả thị. Ngược lại, mô hình lập trình cực đoan (XP) lại không khuyến khích việc tạo nhiều tài liệu.
- Dùng lại: dùng lại các thư viện đã phát triển, các thư viện thương mại... - Tự sinh mã: sử dụng các công cụ tự động hỗ trợ kỹ nghệ phần mềm (visual modeling tools, GUI builders, CASE tools...) - Kỹ thuật hướng đối tượng: kỹ thuật hướng đối tượng hỗ trợ phát triển modun có tính dùng lại cao nhờ có cơ chế che dấu thông tin và khả năng kế thừa - Dùng các ngôn ngữ bậc cao (các ngôn ngữ có cấu trúc và năng lực biểu diễn cao) Chúng ta xem xét ví dụ về việc lựa chọn ngôn ngữ. Việc chọn ngôn ngữ phụ thuộc nhiều vào miền ứng dụng, các ràng buộc về hiệu năng của phần mềm, tuy nhiên năng lực biểu diễn của ngôn ngữ cũng là một yếu tố quan trọng. Bảng 1.1 đưa ra một thống kê liên quan đến năng lực biểu diễn của ngôn ngữ: số dòng lệnh/đơn vị chức năng. VB không phải là một ngôn ngữ có cấu trúc cao nhưng được sử dụng rộng rãi trong các ứng dụng vừa và nhỏ cho môi trường Windows. Ngoài tính dễ học, dễ dùng, một trong những nguyên nhân giúp VB lan rộng chính là năng lực biểu diễn cao.
Каталог: upload -> ebooks upload -> CHỦ TỊch nưỚC upload -> Kính gửi Quý doanh nghiệp upload -> VIỆn chăn nuôi trịnh hồng sơn khả NĂng sản xuất và giá trị giống của dòng lợN ĐỰc vcn03 luậN Án tiến sĩ NÔng nghiệp hà NỘI 2014 ebooks -> BÀi giảng hóa học vô CƠ Người soạn : ĐẶng kim triếT ebooks -> Lý thuyết viễn thông Hệ thống viễn thông điện tử 1 Hệ thống viễn thông điện tử ngày nay ebooks -> 500 CÂu hỏi trắc nghiệm cơ BẢn về chứng khoán và thị trưỜNG chứng khoán câu L ebooks -> Chương 1 CƠ SỞ LÝ luận về du lịch và MÔi trưỜng lý luận chung 1 Du lịch ebooks -> MỘt thế giới không có ĐÀn bà (Bùi Anh Tấn) tải về 454.68 Kb. Chia sẻ với bạn bè của bạn:
|