Kỹ nghệ phần mềm - Bài 3: Tiến trình phần mềm

Tài liệu Kỹ nghệ phần mềm - Bài 3: Tiến trình phần mềm: Bộ môn Công nghệ phần mềm- Khoa CNTT- ĐHCN Email: vynv@coltech.vnu.vn Kỹ nghệ phần mềm Software Engeneering Nguyễn Văn Vỵ Bộ mụn Cụng nghệ phần mềm – ĐHCN 2 NguyễnVănVỵ Nội dung „ Tiến trình vμ mô hình tiến trình „ Các giai đoạn của tiến trình „ Tiến trình vμ vấn đề liên quan Bài 3: Tiến trỡnh phần mềm Bộ mụn Cụng nghệ phần mềm – ĐHCN 3 NguyễnVănVỵ TÀI LiỆU THAM KHẢO 1. Nguyễn Văn Vỵ, Nguyễn Việt Hà. Giỏo trỡnh kỹ nghệ phần mềm. Nhà xuất bản Đại học Quốc gia Hà nội, 2008 2. Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling language User Guid. Addison-Wesley, 1998. 3. M. Ould. Managing Software Quality and Business Risk, John Wiley and Sons, 1999. 4. Roger S.Pressman, Software Engineering, a Practitioner’s Approach. Fifth Edition, McGraw Hill, 2001. 5. Ian Sommerville, Software Engineering. Sixth Edition, Addison- Wasley, 2001. 6. Nguyễn Văn Vỵ. Phõn tớch thiết kế hệ thống thụng tin hiện đại. Hướng cấu trỳc và hướng đối tượng, NXB Thống kờ,...

pdf59 trang | Chia sẻ: hunglv | Lượt xem: 1352 | Lượt tải: 0download
Bạn đang xem trước 20 trang mẫu tài liệu Kỹ nghệ phần mềm - Bài 3: Tiến trình phần mềm, để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
Bộ môn Công nghệ phần mềm- Khoa CNTT- ĐHCN Email: vynv@coltech.vnu.vn Kỹ nghệ phần mềm Software Engeneering Nguyễn Văn Vỵ Bộ mụn Cụng nghệ phần mềm – ĐHCN 2 NguyễnVănVỵ Nội dung „ Tiến trình vμ mô hình tiến trình „ Các giai đoạn của tiến trình „ Tiến trình vμ vấn đề liên quan Bài 3: Tiến trỡnh phần mềm Bộ mụn Cụng nghệ phần mềm – ĐHCN 3 NguyễnVănVỵ TÀI LiỆU THAM KHẢO 1. Nguyễn Văn Vỵ, Nguyễn Việt Hà. Giỏo trỡnh kỹ nghệ phần mềm. Nhà xuất bản Đại học Quốc gia Hà nội, 2008 2. Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling language User Guid. Addison-Wesley, 1998. 3. M. Ould. Managing Software Quality and Business Risk, John Wiley and Sons, 1999. 4. Roger S.Pressman, Software Engineering, a Practitioner’s Approach. Fifth Edition, McGraw Hill, 2001. 5. Ian Sommerville, Software Engineering. Sixth Edition, Addison- Wasley, 2001. 6. Nguyễn Văn Vỵ. Phõn tớch thiết kế hệ thống thụng tin hiện đại. Hướng cấu trỳc và hướng đối tượng, NXB Thống kờ, 2002, Hà Nội. Bộ mụn Cụng nghệ phần mềm – ĐHCN 4 NguyễnVănVỵ Các loại mô hình tiến trình ƒ Mô hình thác n−ớc ƒ Các mô hình phát triển tiến hóa ƒ Các mô hình phát triển hình thức ƒ Phát triển dựa trên sử dụng lại ƒ Khác 5 loại mô hình tiến trình phần mềm tiêu biểu: Mỗi loại bao gồm một số các mô hình tiến trình. Bộ mụn Cụng nghệ phần mềm – ĐHCN 5 NguyễnVănVỵ Mô hình vòng đời truyền thống Mô hình thác n−ớc – waterfall model phân tích yêu cầu& đặc tả thiết kế HT & phẩn mềm Mã hoá &kiểm thử đơn vị kiểm thử tích hợp & HT Vận hμnh & bảo trì Ngiên cứu lập KHDA Bộ mụn Cụng nghệ phần mềm – ĐHCN 6 NguyễnVănVỵ Mô hình thác n−ớc: đặc điểm ■ Tách biệt giữa các pha, tiến hμnh tuần tự  Khó tuân thủ tuần t−: dự án lớn th−ờng phải quay lại  Khó đáp ứng yêu cầu th−ờng thay đổi của khách ■ Chậm có phiên bản thực hiện đ−ợc  đòi hỏi khách hμng phải kiên nhẫn  sai sót phát hiện muộn có thể lμ thảm họa ■ Đặc tả kỹ, phân công chuyên trách, h−ớng tμi liệu  Tμi liệu quá nhiều, tốn sức ng−ời, thời gian dμi ™ Có sớm vμ đ−ợc sử dụng rộng rãi (tốt > tự nhiên) ™ Thích hợp khi yêu cầu hiểu tốt, hệ lớn & phức tạp ™ Bảo trì thuận lợi Bộ mụn Cụng nghệ phần mềm – ĐHCN 7 NguyễnVănVỵ Phiên bản cuối cùng Đặc tả Phiên bản khởi đầu tl e s ri o Đặc tả khái quát Phiên bản trung gian Phát triển Thẩm định Mô hình phát triển tiến hóa b1. L−ợc đồ chung nhất Bộ mụn Cụng nghệ phần mềm – ĐHCN 8 NguyễnVănVỵ L−ợc đồ chung nhất ■ Phát triển ban đầu ƒ Lμm việc với khách, đặc tả khái quát hệ thống (bắt đầu với hiểu biết có thể ch−a đầy đủ) ■ Thực hiện phát triển bằng cách lμm mẫu ƒ Mục tiêu lμ để hiểu hệ thống. Bản mẫu ban đầu có thể còn sơ sμi. ■ Thẩm định phiên bản có đ−ợc, lặp lại các b−ớc cho đến khi có phiên bản cuối cùng Bộ mụn Cụng nghệ phần mềm – ĐHCN 9 NguyễnVănVỵ L−ợc đồ chung „ Hạn chế  Không trực quan  Hệ thống th−ờng có cấu trúc nghèo nμn  Đòi hỏi có kỹ năng đặc tả (ngôn ngữ lμm mẫu) „ Khả năng ứng dụng  Cho các hệ t−ơng tác vừa, nhỏ  Cho những phần của hệ lớn  Hệ có vòng đời ngắn Bộ mụn Cụng nghệ phần mềm – ĐHCN 10 NguyễnVănVỵ sản phẩm cuối cùng lμm mịn bản mẫu xây dựng bản mẫu thiết kế nhanh đánh giá của khách xác yêu cầu- thu thập tt. sơ bộ Mô hình làm bản mẫu - Prototyping model Bắt đầu Kết thúc Mô hình lμm bản mẫu Bộ mụn Cụng nghệ phần mềm – ĐHCN 11 NguyễnVănVỵ Mô hình lμm bản mẫu Loại mẫu:  mẫu trên giấy  mẫu mô tả một phần chức năng  mẫu giao diện  mẫu h−ớng tới sản phẩm Mức độ mẫu:  mẫu dùng xong bỏ đi (throw-away approach)  mẫu dùng tiếp cho b−ớc sau (CASE chuyên dụng)  mẫu lμ phần hệ thống vận hμnh đ−ợc (dựa trên thμnh phần dùng lại) Bộ mụn Cụng nghệ phần mềm – ĐHCN 12 NguyễnVănVỵ −u thế:  nhanh chóng xác định đ−ợc yêu cầu, tốt  tạo cơ sở ký kết hợp đồng  giúp đμo tạo huấn luyện ng−ới sử dụng Nh−ợc điểm: Thích hợp: ƒ các yêu cầu ch−a rõ rμng ƒ input/output ch−a rõ rμng ƒ khó đánh giá tính hiệu quả thuật toán ƒ tính cấu trúc không cao ƒ khách hμng ít tin t−ởng Mô hình lμm bản mẫu Bộ mụn Cụng nghệ phần mềm – ĐHCN 13 NguyễnVănVỵ Mô hình xoắn ốc (spiral model) „ Cải tiến của mô hình tuần tự vμ lμm mẫu „ Thêm phân tích rủi ro „ Lμ quá trình lặp h−ớng mở rộng, hoμn thiện dần  Lập kế hoạch: xác lập vấn đề, tμi nguyên, thời hạn.  Phân tích rủi ro: xem xét mạo hiểm, tìm giải pháp  Kỹ nghệ: phát triển một phiên bản của phần mềm (chọn mô hình thích hợp: lμm mẫu, thác n−ớc,..)  Đánh giá của khách: khách đánh giá phiên bản phát triển; ặ lμm mịn, sửa đổi Bộ mụn Cụng nghệ phần mềm – ĐHCN 14 NguyễnVănVỵ Mô hình xoắn ốc spiral model lập kế hoạch phân tích rủi ro đánh giá kỹ nghệ tập hợp yêu cầu ban đầu, lập kế hoạch dự án kế hoạch dựa trên yêu cầu của khách đánh giá của khách, sửa đổi, hoμn thiện phân tích rủi ro, tim giai pháp bản mẫu / áp dụng p.pháp phát triển thích hợp tiếp tuc hay không? phân tích rủi ro, lây ý kiến khách hμng Bộ mụn Cụng nghệ phần mềm – ĐHCN 15 NguyễnVănVỵ Mô hình xoắn ốc: đặc điểm „ Hợp với hệ lớn có thể phân chia phần cốt lõi ặ thứ yếu „ Có thể kiểm soát rủi ro ở từng mức tiến hóa „ Khó thuyết phục khách lμ kiểm soát đ−ợc sự tiến hóa linh hoạt (đòi hỏi năng lực quản lý, năng lực phân tích rủi ro -> chi phi chuyên gia lớn) „ Ch−a đ−ợc dùng rộng rãi nh− mô hình thác n−ớc hoặc lμm mẫu Bộ mụn Cụng nghệ phần mềm – ĐHCN 16 NguyễnVănVỵ Mô hình phát triển ứng dụng nhanh Rapid Application Development- RAD đội 2 Tạo sinh ứng dụng Mô hình dữ liệu Kiểm thử chuyển giao Mô hình nghiệp vụ Mô hình xử lý đội 1 60-90 ngμy Tạo sinh ứng dụng Mô hình dữ liệu Kiểm thử chuyển giao Mô hình nghiệp vụ Mô hình xử lý đội 3 Tạo sinh ứng dụng Mô hình dữ liệu Kiểm thử chuyển giao Mô hình nghiệp vụ Mô hình xử lý Bộ mụn Cụng nghệ phần mềm – ĐHCN 17 NguyễnVănVỵ RAD - đặc điểm „ Hợp với các hệ thống có khả năng môđun hóa cao „ h−ớng thμnh phần, tái sử dụng „ sử dụng công cụ tự động „ Thời gian phát triển sản phẩm ngắn (60~90 ngμy) „ Không phù hợp với sản phẩm: „ khó phân chia thμnh các thμnh phần „ đòi hỏi hiệu năng cao Bộ mụn Cụng nghệ phần mềm – ĐHCN 18 NguyễnVănVỵ Mô hình tăng tr−ởng (incremental model) Phân tích Thiết kế M∙ hoá Kiểm thử System/information engineering Phân tích Thiết kế M∙ hoá Kiểm thử Bản tăng 2 Chuyền giao bản tăng 4 Thời gian Bản tăng 3 Bản tăng 1 Bản tăng 4 Chuyền giao bản tăng 1 Chuyền giao bản tăng 2 Chuyền giao bản tăng 3 Phân tích Thiết kế M∙ hoá Kiểm thử Phân tích Thiết kế M∙ hoá Kiểm thử Bộ mụn Cụng nghệ phần mềm – ĐHCN 19 NguyễnVănVỵ Mô hình tăng tr−ởng „ Chuyển giao dần từng phần của hệ thống ƒ Sản phẩm chia thμnh từng phần tăng theo yêu cầu chức năng ƒ Yêu cầu ng−ời dùng −u tiên theo thứ tự phần tăng „ Cho sản phẩm dùng trong thời gian ngắn  đáp ứng nhanh yêu cầu của khách  chiếm lĩnh thị tr−ờng  khác với bản mẫu „ Công ty phát triển phải có tiềm lực cao (công nghệ, tμi sản phần mềm) Bộ mụn Cụng nghệ phần mềm – ĐHCN 20 NguyễnVănVỵ Lập trình cực đoan (Extreme Programming-XP) „ Cách tiếp cận dựa trên việc phát triển, chuyển giao dần từng phần nhỏ chức năng „ Tạo các ca thử nghiệm tr−ớc khi lập trình ƒ đòi hỏi phải nắm vững yêu cầu; giao diện tr−ớc khi bắt tay vμo mã hóa „ Lập trình đội ƒ tránh lỗi, nâng cao chất l−ợng ƒ đảm bảo sự tuân theo các chuẩn XP đã đề ra „ Viết lại khi có thể ƒ chủ động tấn công lỗi Bộ mụn Cụng nghệ phần mềm – ĐHCN 21 NguyễnVănVỵ Kỹ thuật thế hệ thứ 4 Fourth generation technology - 4GT „ Các kỹ thuật xác định đặc tr−ng phần mềm ở mức cao:  h−ớng mục đích (chức năng)  tự động sinh mã ch−ơng trình theo đặc tả „ Các công cụ/ứng dụng điển hình  truy vấn CSDL (SQL)  tạo báo cáo, bảng tính  sinh giao diện (giao diện Web) Bộ mụn Cụng nghệ phần mềm – ĐHCN 22 NguyễnVănVỵ 4GT: đặc điểm „ Phân tích/thiết kế vẫn lμ b−ớc quan trọng „ 4GT chỉ trợ giúp (tự động hóa) việc sinh mã ch−ơng trình đối với từng chức năng cụ thể „ ứng dụng còn hạn chế; không phải mọi 4GTcũng dễ dùng „ Tíết kiệm công sức cho phát triển phần mềm nhỏ „ Không hiệu quả với phần mềm lớn: mã hóa chỉ chiếm một tỷ lệ nhỏ so với phân tích thiết kế Bộ mụn Cụng nghệ phần mềm – ĐHCN 23 NguyễnVănVỵ Phát triển hệ thống hình thức hóa formal systems development Các b−ớc của tiến trình phát triển (đặc tả yêu cầu 1 cách hình thức bằng các công cụ toán học trừu t−ợng) Xác định yêu cầu Kiểm thử tích hợp & hệ thống Biến đổi hình thức Bán tự động tự động Đặc tả hình thức Bộ mụn Cụng nghệ phần mềm – ĐHCN 24 NguyễnVănVỵ Biến đổi hình thức Các phép biến đổi hìmh thức Các chứng minh tính đúng đắn của phép biến đổi R2Đặc tả hình thức R3 Ch−ơng trình thực hiện đ−ợc P2 P3 P4 T1 T2 T3 T4 R1 P1 Bộ mụn Cụng nghệ phần mềm – ĐHCN 25 NguyễnVănVỵ Hạn chế phát triển hình thức hóa „ Hạn chế  Cần có kỹ năng đặc tả vμ sử dụng kỹ thuật tiên tiến  Khó đặc tả đ−ợc mọi khía cạnh của hệ thống, chẳng hạn nh− giao diện „ Khả năng ứng dụng  Những hệ thống quan trọng cần phảI đảm bảo độ an toμn, bảo mật tr−ớc khi đ−a vμo sử dụng, xử lý nhiều, t−ơng tác hạn chế.  ít nhμ phát triển có thể sử dụng. Bộ mụn Cụng nghệ phần mềm – ĐHCN 26 NguyễnVănVỵ Phát triển h−ớng sử dụng lại „ H−ớng sử dụng lại dựa trên nền tảng của phát triển hệ thống h−ớng đối t−ợng „ ý t−ởng hướng đối tượng: Mô hình cấu trúc của hệ thống  Hệ thống cấu thμnh từ các đối t−ợng  Đối t−ợng bao gói cả dữ liệu vμ xử lý  Liên kết với nhau bằng truyền thông Bộ mụn Cụng nghệ phần mềm – ĐHCN 27 NguyễnVănVỵ Phát triển h−ớng đối t−ợng „ bao gói, che dấu thông tin: tác động cục bộ, dễ bảo trì, dễ dùng lại Do bao gói cả dữ liệu vμ xử lý nên độc lập t−ơng đối, cho một chức năng xác định, che thông tin với bên ngoμi „ tính kế thừa:  xây dựng đ−ợc các lớp cơ sở (chung)  khi thêm các chi tiết dùng cho tr−ờng hợp cụ thể nâng cao khả năng dùng lại „ liên kết tự do, yếu mở rộng đơn giản, không hạn chế Bộ mụn Cụng nghệ phần mềm – ĐHCN 28 NguyễnVănVỵ Các h−ớng sử dụng lại „ Các h−ớng sử dụng lại:  Định h−ớng thμnh phần (component - mã nguồn)  Định h−ớng mẫu (pattern - phân tích, thiết kế)  Phát triển khung lμm việc (framworks: lớp ứng dụng) „ Các giai đoạn của tiến trình  Phân tích hệ thống thμnh các phần yêu cầu nhỏ  Cải biên các yêu cầu h−ớng (thμnh phần, mẫu, khung)  Thiết kế hệ thống h−ớng tới tμi sản sử dụng lại  Phát triển vμ tích hợp „ Quan trọng, cần kinh nghiệm, công cụ còn hạn chế Bộ mụn Cụng nghệ phần mềm – ĐHCN 29 NguyễnVănVỵ Tiến trình h−ớng sử dụng lại đặc tả yêu cầu phát triển và tích hợp cải biên yêu cầu thẩm định hệ thống phân tích thành phần thíết kế HT dùng lại Tiến trình phát triển Tham chiếu Sử dụng Khung lμm việc Th− viện thμnh phần Th− viện thμnh phần Th− viện mẫu Th− viện mẫu Bộ mụn Cụng nghệ phần mềm – ĐHCN 30 NguyễnVănVỵ Kỹ nghệ h−ớng thμnh phần Component-based software engineering Nội dung  Thμnh phần lμ mô đun chức năng mã đóng  Lắp ráp các thμnh phần đúng với yêu cầu  Dùng lại thμnh phần độc lập với ngôn ngữ  Thay thế thμnh phần lμ động (không cần dịch), không cần đ−ờng dẫn, chỉ cần định danh. Ưu, nh−ợc ™ Nhanh, ổn định, hiệu quả ™ Cần có các thμnh phần đ−ợc mô tả, hiểu về nó, có cách tìm kiếm tốt file.com file.exe file.exe file.com file.exe file.com file.exe file.comfile.exe Bộ mụn Cụng nghệ phần mềm – ĐHCN 31 NguyễnVănVỵ Phân tích thiết kế h−ớng mẫu pattern oriented analysis & design - POAD Nội dung  Phân tích yêu cầu h−ớng theo mẫu  Xem xét các mẫu đã có (từ th− viện)  Tìm, lựa chon mẫu thích hợp cho phần đ−ợc phân tích  Chuyển thiết kế thμnh ch−ơng trình (tự động, bán tự động) Ưu, nh−ợc ™ Bắt đầu ứng dụng rộng rãi ™ Cần có khả năng phân tích tốt ™ Có hiểu biết thμnh thạo về mẫu AbstractFigure Draw() Figures() Include() Decompose() Add() Remove() AttributeFigure Draw() Draw() Figures() Include() Decompose() Add() Remove() CompositeFigure PertFigure Start() notifyPostTask() updateDuration() late() notifyPreTask() updateLate() …. Bộ mụn Cụng nghệ phần mềm – ĐHCN 32 NguyễnVănVỵ Phát triển khung lμm việc Framework development Xây d−ng khung làm việc Xác định lớp bμi toán cần giải quyết Xây dựng khung bμi toán (dựa trên patterns)  Lμm sẵn các tiêu bản mẫu (dùng ngay đ−ợc) Triển khai ™Phân tích bμi toán theo khung ™Xác định tiêu bản thích hợp ™Lắp ghép hay tìm phần thay thế Bộ mụn Cụng nghệ phần mềm – ĐHCN 33 NguyễnVănVỵ Phát triển khung lμm việc Framework development Điểm cắm Mô hình frameworrk Quản lý khách sạn Thanh toán quản lý phòng lế tân tiền phòng dịch vụ Khung chính Tiêu bản làm sẵn Bộ mụn Cụng nghệ phần mềm – ĐHCN 34 NguyễnVănVỵ Phát triển phần mềm mã nguồn mở „ Công khai thiết kế, công khai mã nguồn, dùng chung y chất l−ợng tăng, chuẩn hóa cao? „ Phát triển phân tán, nhiều ng−ời tham gia „ Xuất phát từ các mối quan tâm chung „ Nhiều vấn đề đ−ợc giải quyết • Lý do, lợi ích, động lực ch−a rõ „ Ví dụ: GNU, Linux Bộ mụn Cụng nghệ phần mềm – ĐHCN 35 NguyễnVănVỵ Lựa chọn mô hình „ Phụ thuộc vμo bμi toán, vμo môi tr−ờng cụ thể „ Yêu cầu rõ rμng: Mô hình thác n−ớc thích hợp „ Hệ phức tạp, điều khiển: H−ớng sử dụng lại „ Khác:  Yêu cầu ch−a rõ rμng, độ phức tạp cao  Yêu cầu có khả năng thay đổi  Không chắc chắn về tính hiệu quả, tính khả thi Sử dụng: Lμm bản mẫu, mô hình xoắn ốc Bộ mụn Cụng nghệ phần mềm – ĐHCN 36 NguyễnVănVỵ „ Lμ quá trình thiết lập các chức năng, dịch vụ mμ hệ thống cần có vμ các rμng buộc lên sự phát triển vμ vận hμnh hệ thống „ Tiến trình kỹ nghệ yêu cầu bao gồm:  Nghiên cứu khả thi  Phân tích vμ xác định yêu cầu  Đặc tả yêu cầu  Thẩm định yêu cầu Các giai đoạn của tiến trình Đặc tả yêu cầu phần mềm Bộ mụn Cụng nghệ phần mềm – ĐHCN 37 NguyễnVănVỵ Tiến trình kỹ nghệ yêu cầu Báo cáo khả thi Mô hình hệ thống Yêu cầu ng−ơi dùng, hệ thống Tμi liệu yêu cầu Nghiên cứu khả thi Xác đinh, phân tích yêu cầu đặc tả yêu cầu Thẩm định yêu cầu Bộ mụn Cụng nghệ phần mềm – ĐHCN 38 NguyễnVănVỵ Thiết kế phần mềm „ Chuyển yêu cầu thμnh đặc tả thμnh hệ thống nh− nó tồn tại trong thế giới thực với các giải pháp công nghệ thích hợp để ng−ời lập trình có thể chuyển thμnh ch−ơng trình vận hμnh trên máy „ Chiến l−ợc thiết kế phù hợp với phân tích „ Lμ quá trình lặp: có thể quay lại hoμn thiện phân tíchặ rồi lại thiết kế „ Hai giai đoạn thiết kế: logicặthiết kế vật lý Bộ mụn Cụng nghệ phần mềm – ĐHCN 39 NguyễnVănVỵ Tiến trình thiết kế phần mềm thiết kế kiến trúc Đặc tả Yêu cầu đặc tả Trừu t−ợng thiết kế Giao diện thiết kế thành phần thiết kế dữ liệu thiết kế hủ tục Kiến trúc hệ thống Sản phẩm thiết kế đặc tả phần mềm đặc tả giao diện đặc tả thành phần đặc tả cấu trúc dữ liệu đặc tả thủ tục Hoạt động thiết kê Bộ mụn Cụng nghệ phần mềm – ĐHCN 40 NguyễnVănVỵ Các ph−ơng pháp thiết kế „ Cách tiếp cận mang tính hệ thống, có ph−ơng pháp „ Tμi liệu thiết kế ở dạng một tập các mô hình đồ họa vμ chú giải đi kèm „ Các mô hình th−ờng gặp:  Mô hình kiến trúc theo nhiều khung nhìn  Mô hình luồng dữ liệu (xử lý)  Mô hình Thực thể – mối quan hê/ MH Quan hệ (dữ liệu)  Mô hình cấu trúc mô đun (cấu trúc)  Các mô hình lớp đối t−ợng (kiến trúc, thực thi) Bộ mụn Cụng nghệ phần mềm – ĐHCN 41 NguyễnVănVỵ Lập trình vμ gỡ rối „ Lμ chuyển thiết kế thμnh ch−ơng trình, bắt lỗi vμ sửa lỗi „ Lμ một hoạt động cá nhân không có một tiến trình chung cho mọi ng−ời „ Ng−ời lập trình phải tiến hμnh kiểm thử để gỡ lỗi ch−ơng trình. Gỡ lỗi lμ hoạt động của lập trình „ Lập trình đòi hỏi chọn ngôn ngữ thích hợp vμ có kinh nghiệm  phong cách lập trình tốt „ Để đảm bảo độ tin cây, cần biết lập trình tránh lỗi, thứ lỗi vμ ném ngoại lệ Bộ mụn Cụng nghệ phần mềm – ĐHCN 42 NguyễnVănVỵ Thẩm định phần mềm „ Thẩm định vμ xác minh nhằm đảm bảo hệ thống phù hợp với đặc tả vμ đáp ứng yêu cầu ng−ời dùng „ Nội dung bao gồm việc thanh tra, xét duyệt vμ kiểm thử hệ thống. Kiểm thử lμ quan trọng nhất „ Có nhiều mức: • Xác minh: kiểm thử đợn vị, tích hợp, hệ thống • Thẩm định: lμm mẫu yêu cầu, kiểm thử chấp nhận „ Có nhiều ph−ơng pháp kiểm thử. Mỗi ph−ơng pháp áp dụng ở mức xác định, vμ sử dụng kỹ thuật nhất định „ Mục tiêu kiểm thử lμ tìm ra lỗi với chi phí ít nhất có thể Bộ mụn Cụng nghệ phần mềm – ĐHCN 43 NguyễnVănVỵ Tiến trình kiểm thử Kiểm thử đơn vị Kiểm thử mô đun Kiểm thử Hệ con Kiểm thử hệ thống Kiểm thử Chấp nhận lập trình viên chuyên viên ng−ời dùng Bộ mụn Cụng nghệ phần mềm – ĐHCN 44 NguyễnVănVỵ Tiến hoá phần mềm „ Phần mềm phải mềm dẻo vì nó cần phải thay đổi. „ Môi tr−ờng nghiệp vụ vμ kỹ thuật luôn thay đổi: Phần mềm cần thay đổi để phù hợp với chúng ặ tiến hóa lμ tất yếu „ Phân định phát triển vμ tiến hoá lμ t−ơng đối: giữa chúng có quan hệ chặt chẽ với nhau. Phát triển lμ lμm mới, tiến hóa trên cơ sở hệ đã có. Bộ mụn Cụng nghệ phần mềm – ĐHCN 45 NguyễnVănVỵ Tiến trình tiến hoá Hệ thống mới Xác định yêu cầu hệ thống Hệ thống hiện tại đánh giá hệ thống hiện tại đề xuất thay đổi hệ thống Cải biên hệ thống Bộ mụn Cụng nghệ phần mềm – ĐHCN 46 NguyễnVănVỵ Trợ giúp tự động hoá phát triển „ Computer-aided software engineering:CASE lμ các phần mềm trợ giúp phát triển vμ tiến hoá hệ thống „ Các công cụ th−ờng gặp:  Bộ soạn thảo đồ thị: để phát triển mô hình hệ thống  Từ điển dữ liệu: để quản lý các thực thể thiết kế  Bộ xây dựng giao diện: để thiết kế giao diện  Bộ gỡ rối: trợ giúp tìm lỗi trong ch−ơng trình  Bộ chuyển đổi tự động: tạo sinh các phiên bản mới từ thiết kế / hay ch−ơng trình Bộ mụn Cụng nghệ phần mềm – ĐHCN 47 NguyễnVănVỵ Công nghệ CASE (CASE technology) „ CASE góp phần đáng kể hoμn thiện tiến trình phần mềm cả về trình tự, tiến độ vμ chất l−ợng: tự động hóa một phần hoạt động mô hình hóa vμ quản lý „ Những hoạt động không thể tự động hóa:  Sự suy nghĩ sáng tạo trong SE  Lựa chọn giải pháp công nghệ  Giao tiếp khi lμm việc nhóm  Thực hiện việc quản lý Bộ mụn Cụng nghệ phần mềm – ĐHCN 48 NguyễnVănVỵ Công nghệ CASSE Các công cụ đơn bộ sửa lỗi Môi tr−ờng tiến trình Bàn thợ Lập trình gỡ lỗi Phân tích vμ thiết kế Bộ soạn thảo Môi tr−ờng Môi tr−ờng tích hợp Kiểm thử các loại Bμn thợ đơn ph−ơng pháp Ch.trình dịch Bμn thợ đa ph−ơng pháp Bμn thợ ngôn ngữ cụ thể Công nghệ CASE Bμn thợ mục tiêu chung Bộ mụn Cụng nghệ phần mềm – ĐHCN 49 NguyễnVănVỵ Phân loại CASE „ Phân loại CASE giúp hiểu vμ sử dụng chúng trong phát triển „ Có thể phân loại CASE theo:  H−ớng chức năng: Công cụ cho các chức năng cụ thể: soạn thảo, lập kế hoạch, lμm mẫu,..  H−ớng tiến trình: Công cụ cho hoạt động của tiến trình đ−ợc trợ giúp: mô hình nghiệp vụ, E-R  H−ớng tích hợp: Công cụ trợ giúp tổ chức việc tích hợp các đơn vị các mức trong hệ thống  Dựa trên loại hoạt động: Đặc tả, thiết kế, triển khai, thẩm định vμ xác minh Bộ mụn Cụng nghệ phần mềm – ĐHCN 50 NguyễnVănVỵ CASE tích hợp „ Các công cụ đơn (Tools) : trợ giúp những nhiệm vụ riêng rẽ của tiến trình: kiếm tra sự nhất quán, soạn thảo, tạo mô hình „ Bàn thợ (Workbenches): trợ giúp 1 pha của tiến trình phát triển, nh− đặc tả, thiết kê,.. „ Môi tr−ờng phát triển (Environments): trợ giúp toμn bộ hay một phần của toμn tiến trình phần mềm (có thể bao gồm một số bμn thợ) Bộ mụn Cụng nghệ phần mềm – ĐHCN 51 NguyễnVănVỵ Các vấn đề liên quan „ Xác định yêu cầu vμ thiết kế có vai trò quyết định đến chất l−ợng phần mềm, chiếm phần lớn công sức so với phát triển „ Khi chuyển tiếp giữa các pha phát triển phải thẩm định tốt để đảm bảo lỗi không ảnh h−ởng đến pha sau „ Tμi liệu tạo ra ở mỗi pha không chỉ dùng cho pha kế tiếp mμ còn dùng để đảm bảo chất l−ợng của phần mềm vμ bảo trì „ Cần chuẩn hóa mẫu biểu, cách thức ghi chép, tạo tμi liệu nhằm đảm bảo chất l−ợng phần mềm Bộ mụn Cụng nghệ phần mềm – ĐHCN 52 NguyễnVănVỵ Tính khả thi của tiến trình phát triển Phần tử logic, khó kiểm soát  tạo ra các tμi liệu  xét duyệt tμi liệu mỗi b−ớc nghiên cứu khả thi; đặc tả yêu cầu; đặc tả thiết kế Ví dụ tμi liệu: So sánh:  vòng đời cổ điển khả thi cao  lμm bản mẫu kém  4GT ?? Bộ mụn Cụng nghệ phần mềm – ĐHCN 53 NguyễnVănVỵ Vấn đề: „ Tạo ra chi phí phụ của phát triển (ng−ời lập trình không thích viết tμi liệu) „ Sử dụng các giải pháp cục bộ để tránh sửa đổi tμi liệu „ Sử dụng các mẫu có sẵn „ Sử dụng CASE trợ giúp lμm tμi liệu theo chuẩn Lμm tμi liệu phần mềm Bộ mụn Cụng nghệ phần mềm – ĐHCN 54 NguyễnVănVỵ Sản phẩm (tμi liệu) của dự án Mã máy, dữ liệu, tμi liệu Mã nguồn, chú thích Thiết kế Yêu cầu Phi hình thức, trừu t−ợng Hình thức hoá, cụ thể Bộ mụn Cụng nghệ phần mềm – ĐHCN 55 NguyễnVănVỵ Giảm kích cỡ, chi phí phần mềm „ Phần mềm ngμy cμng lớn, phức tạp „ Tổ chức lμm việc theo nhóm, tiến hμnh song song „ Cần phân rã chức năng; giảm kích cỡ (mã nguồn), tăng năng suất:  tái sử dụng: th− viện th−ơng mại,...  tự sinh mã: công cụ tạo giao diện,...  h−ớng đối t−ợng: kế thừa, bảo trì  ngôn ngữ bậc cao: năng lực biểu diễn cao Bộ mụn Cụng nghệ phần mềm – ĐHCN 56 NguyễnVănVỵ Quan hệ tiến trình vμ sản phẩm Tiến trình vμ sản phẩm lμ hai mặt của phát triển: „ Tiến trình tốt đảm bảo rμng buộc về sản phẩm „ Sản phẩm tốt lμ sự tổng hoμ của nhiều yếu tố:  Tiến trình thích hợp  Đội ngũ chuyên môn tốt  Công cụ trợ giúp mạnh  Năng lực quản lý tiến trinh của tổ chức cao (CMM) 5 mức CMM (Capability Maturity Model): 1. Tùy biến 3. Đ−ợc xác định 2. Lặp lại đ−ợc 4. Đ−ợc quản lý 5. Tối −u hóa Bộ mụn Cụng nghệ phần mềm – ĐHCN 57 NguyễnVănVỵ Câu hỏi ôn tập 1. Có mấy loại mô hình tiến trình? Lμ loại nμo? 2. Trình bμy nội dung của các mô hình: thác n−ớc, lμm mẫu, xoáy ốc, tiến hoá, tăng tr−ởng, ứng dụng nhanh, hình thức hoá, đối t−ợng, mô hình sử dụng lại, mô hình mã nguồn mở, mô hình thế hệ thứ 4 theo các nội dung sau: ƒ Nội dung? đặc tr−ng? ƒ −u, nh−ợc điểm? ƒ cần yêu cầu gì? ƒ thích hợp khi nμo? 3. Mô tả tiến trình kỹ nghệ yêu cầu? 4. Mô tả tíên trình thiết kế phần mềm? Nêu các mô hình thiết kế th−ờng sử dụng? Bộ mụn Cụng nghệ phần mềm – ĐHCN 58 NguyễnVănVỵ Câu hỏi ôn tập (t) 5. Định nghĩa thẩm định phần mềm? Thẩm định vμ xác minh gồm những hoạt động gì? 6. Có những loại kiểm thử nμo? Mô tả tiến trình kiểm thử? 7. Tiến hoá phần mềm lμ gì? Lý do? 8. Mô tả tiến trình tiến hoá hệ thống? 9. CASE lμ gì? Các cách phân loại CASE? 10. CASE tích hợp gồm những loại nμo? vẽ sơ đồ cấu trúc các loại CASE? 11. Lμm thế nμo để đảm bảo khả thi của mô hình phát triển? So sánh sự khả thi giữa các mô hình, giải thích vì sao? 12. Lμm thế nμo để có thể giảm kích cỡ, chi phí của mô hình? Những mô hình nμo, ngôn ngữ nμo có −u thế về mặt nμy? Bộ mụn Cụng nghệ phần mềm – ĐHCN 59 NguyễnVănVỵ Câu hỏi và thảo luận

Các file đính kèm theo tài liệu này:

  • pdfUnlock-1cSEV_TientrinhFM.pdf