Giáo trình Kỹ thuật phần mềm - Bài 3: Tiến trình phần mềm - Nguyễn Văn Vy

59 trang huongle 2650

Download

Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Kỹ thuật phần mềm - Bài 3: Tiến trình phần mềm - Nguyễn Văn Vy", để 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:

giao_trinh_ky_thuat_phan_mem_bai_3_tien_trinh_phan_mem_nguye.pdf

Nội dung text: Giáo trình Kỹ thuật phần mềm - Bài 3: Tiến trình phần mềm - Nguyễn Văn Vy

Kỹ nghệ phần mềm Software Engeneering Nguyễn Văn Vỵ Bộ môn Công nghệ phần mềm- Khoa CNTT- ĐHCN Email: vynv@coltech.vnu.vn
Bài 3: Tiến trỡnh phần mềm 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ộ mụn Cụng nghệ phần mềm – ĐHCN 2
TÀI LiỆU THAM KHẢO NguyễnVănVỵ 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 3
Các loại mô hình tiến trình NguyễnVănVỵ 5 loại mô hình tiến trình phần mềm tiêu biểu: 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 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 4
Mô hình vòng đời truyền thống NguyễnVănVỵ Ngiên cứu lập KHDA 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ì Mô hình thác n−ớc – waterfall model Bộ mụn Cụng nghệ phần mềm – ĐHCN 5
Mô hình thác n−ớc: đặc điểm NguyễnVănVỵ ■ 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 6
Mô hình phát triển tiến hóa b1. L−ợc đồ chung nhất NguyễnVănVỵ Đặc tả Phiên bản khởi đầu tl e Phiên bản Đặc tả Phát triển kháisrio quát trung gian Thẩm định Phiên bản cuối cùng Bộ mụn Cụng nghệ phần mềm – ĐHCN 7
L−ợc đồ chung nhất NguyễnVănVỵ ■ 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 8
L−ợc đồ chung NguyễnVănVỵ 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 9
Mô hình lμm bản mẫu NguyễnVănVỵ Bắt đầu xác yêu cầu- thu thập tt. sơ bộ Kết thúc sản phẩm thiết kế cuối cùng nhanh lμm mịn xây dựng bản mẫu bản mẫu đánh giá của khách Mô hình làm bản mẫu - Prototyping model Bộ mụn Cụng nghệ phần mềm – ĐHCN 10
Mô hình lμm bản mẫu NguyễnVănVỵ 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 11
Mô hình lμm bản mẫu NguyễnVănVỵ Nh−ợc điểm: tính cấu trúc không cao khách hμng ít tin t−ởng −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 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 Bộ mụn Cụng nghệ phần mềm – ĐHCN 12
Mô hình xoắn ốc (spiral model) NguyễnVănVỵ 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 13
Mô hình xoắn ốc NguyễnVănVỵ tập hợp yêu phân tích rủi ro phân tích rủi ro, cầu ban đầu, lập kế hoạch tim giai pháp lập kế hoạch dự án phân tích rủi ro, lây ý kiến kế hoạch khách hμng dựa trên yêu cầu của tiếp tuc hay khách không? đánh giá bản mẫu / áp của khách, sửa đổi, dụng p.pháp phát hoμn thiện đánh giá kỹ nghệ triển thích hợp spiral model Bộ mụn Cụng nghệ phần mềm – ĐHCN 14
Mô hình xoắn ốc: đặc điểm NguyễnVănVỵ 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 15
Mô hình phát triển ứng dụng nhanh Rapid Application Development- RAD NguyễnVănVỵ đội 3 Mô hình đội 2 nghiệp đội 1 vụ Mô hình Mô nghiệp hình dữ Mô hình liệu Mô vụ Mô hình hình xử nghiệp dữ liệu lý Tạo sinh ứng dụng vụ Mô hình Mô hình Kiểm thử dữ liệu xử lý chuyển Tạo sinh giao Mô hình ứng dụng xử lý Kiểm thử chuyển Tạo sinh giao ứng dụng Kiểm thử chuyển giao 60-90 ngμy Bộ mụn Cụng nghệ phần mềm – ĐHCN 16
RAD - đặc điểm NguyễnVănVỵ 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 17
Mô hình tăng tr−ởng (incremental model) NguyễnVănVỵ System/information Bản tăng 1 engineering Phân Thiết M∙ Kiểm Chuyền tích kế hoá thử giao bản tăng 1 Bản tăng 2 Phân Thiết M∙ Kiểm Chuyền tích kế hoá thử giao bản tăng 2 Phân Thiết M∙ Kiểm Chuyền Bản tăng 3 tích kế hoá thử giao bản tăng 3 Phân Thiết M∙ Kiểm Chuyền Bản tăng 4 tích kế hoá thử giao bản tăng 4 Thời gian Bộ mụn Cụng nghệ phần mềm – ĐHCN 18
Mô hình tăng tr−ởng NguyễnVănVỵ 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 19
Lập trình cực đoan (Extreme Programming-XP) NguyễnVănVỵ 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 20
Kỹ thuật thế hệ thứ 4 Fourth generation technology - 4GT NguyễnVănVỵ 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 21
4GT: đặc điểm NguyễnVănVỵ 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 22
Phát triển hệ thống hình thức hóa formal systems development NguyễnVănVỵ Bán tự động tự động Xác định Đặc tả Biến đổi Kiểm thử tích hợp yêu cầu hình thức hình thức & hệ thống 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) Bộ mụn Cụng nghệ phần mềm – ĐHCN 23
Biến đổi hình thức NguyễnVănVỵ Các phép biến đổi hìmh thức T1 T2 T3 T4 Đặc tả R2 R3 Ch−ơng trình R1 thực hiện đ−ợc hình thức P1 P2 P3 P4 Các chứng minh tính đúng đắn của phép biến đổi Bộ mụn Cụng nghệ phần mềm – ĐHCN 24
Hạn chế phát triển hình thức hóa NguyễnVănVỵ 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 25
Phát triển h−ớng sử dụng lại NguyễnVănVỵ 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: 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 Mô hình cấu trúc của hệ thống Bộ mụn Cụng nghệ phần mềm – ĐHCN 26
Phát triển h−ớng đối t−ợng NguyễnVănVỵ bao gói, che dấu thông tin: 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ác động cục bộ, dễ bảo trì, dễ dùng lạ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 27
Các h−ớng sử dụng lại NguyễnVănVỵ 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 28
Tiến trình h−ớng sử dụng lại NguyễnVănVỵ ThTh−−việnviện ThTh−−việnviện Khung ththμμnhnh phần phần mẫumẫu lμm việc đặc tả phân tích cải biên thíết kế HT yêu cầu thành phần yêu cầu dùng lại Tham chiếu phát triển và thẩm định Sử dụng tích hợp hệ thống Tiến trình phát triển Bộ mụn Cụng nghệ phần mềm – ĐHCN 29
Kỹ nghệ h−ớng thμnh phần Component-based software engineering NguyễnVănVỵ Nội dung file.com file.exe 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ữ file.com Thay thế thμnh phần lμ động (không cần dịch), file.exe không cần đ−ờng dẫn, chỉ cần định danh. file.exe Ưu, nh−ợc file.com Nhanh, ổn định, hiệu quả file.exe 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.exe file.com Bộ mụn Cụng nghệ phần mềm – ĐHCN 30
Phân tích thiết kế h−ớng mẫu pattern oriented analysis & design - POADNguyễnVănVỵ Nội dung Phân tích yêu cầu h−ớng theo mẫu AbstractFigure Draw() Xem xét các mẫu đã có (từ th− viện) Figures() CompositeFigure Include() Draw() Decompose() Tìm, lựa chon mẫu thích hợp cho Figures() Add() Include() phần đ−ợc phân tích Remove() Decompose() Chuyển thiết kế thμnh ch−ơng trình Add() (tự động, bán tự động) Remove() AttributeFigure Ưu, nh−ợc Draw() PertFigure Start() Bắt đầu ứng dụng rộng rãi notifyPostTask() updateDuration() Cần có khả năng phân tích tốt late() notifyPreTask() Có hiểu biết thμnh thạo về mẫu updateLate() . Bộ mụn Cụng nghệ phần mềm – ĐHCN 31
Phát triển khung lμm việc Framework development NguyễnVănVỵ 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 32
Phát triển khung lμm việc Framework development NguyễnVănVỵ Điểm cắm Khung chính Quản lý khách sạn Thanh toán quản lý phòng tiền phòng Tiêu bản làm sẵn lế tân dịch vụ Mô hình frameworrk Bộ mụn Cụng nghệ phần mềm – ĐHCN 33
Phát triển phần mềm mã nguồn mở NguyễnVănVỵ 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 34
Lựa chọn mô hình NguyễnVănVỵ 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 35
Các giai đoạn của tiến trình Đặc tả yêu cầu phần mềm 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 Bộ mụn Cụng nghệ phần mềm – ĐHCN 36
Tiến trình kỹ nghệ yêu cầu NguyễnVănVỵ Nghiên cứu Xác đinh, phân khả thi tích yêu cầu đặc tả yêu cầu Báo cáo Thẩm định khả thi yêu cầu 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 Bộ mụn Cụng nghệ phần mềm – ĐHCN 37
Thiết kế phần mềm NguyễnVănVỵ 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 38
Tiến trình thiết kế phần mềm NguyễnVănVỵ Đặc tả Yêu cầu Hoạt động thiết kê thiết kế đặc tả thiết kế thiết kế thiết kế thiết kế kiến trúc Trừu t−ợng Giao diện thành phần dữ liệu hủ tục Kiến trúc đặc tả đặc tả giao đặc tả đặc tả cấu đặc tả hệ thống phần mềm diện thành phần trúc dữ liệu thủ tục Sản phẩm thiết kế Bộ mụn Cụng nghệ phần mềm – ĐHCN 39
Các ph−ơng pháp thiết kế NguyễnVănVỵ 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 40
Lập trình vμ gỡ rối NguyễnVănVỵ 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 41
Thẩm định phần mềm NguyễnVănVỵ 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 42
Tiến trình kiểm thử NguyễnVănVỵ Kiểm thử đơn vị Kiểm thử mô đun Kiểm thử Hệ con lập trình viên Kiểm thử hệ thống Kiểm thử Chấp nhận chuyên viên ng−ời dùng Bộ mụn Cụng nghệ phần mềm – ĐHCN 43
Tiến hoá phần mềm NguyễnVănVỵ 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 44
Tiến trình tiến hoá NguyễnVănVỵ Xác định yêu đánh giá hệ đề xuất thay Cải biên hệ cầu hệ thống thống hiện tại đổi hệ thống thống Hệ thống Hệ thống hiện tại mới Bộ mụn Cụng nghệ phần mềm – ĐHCN 45
Trợ giúp tự động hoá phát triển NguyễnVănVỵ 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 46
Công nghệ CASE (CASE technology) NguyễnVănVỵ 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 47
Công nghệ CASSE NguyễnVănVỵ Công nghệ CASE Các công cụ đơn Bàn thợ Môi tr−ờng Bộ soạn Ch.trình bộ sửa Môi tr−ờng Môi tr−ờng thảo dịch lỗi tích hợp tiến trình Phân tích vμ Lập trình gỡ Kiểm thử các thiết kế lỗi loại Bμn thợ đa Bμn thợ đơn Bμn thợ mục Bμn thợ ngôn ph−ơng pháp ph−ơng pháp tiêu chung ngữ cụ thể Bộ mụn Cụng nghệ phần mềm – ĐHCN 48
Phân loại CASE NguyễnVănVỵ 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 49
CASE tích hợp NguyễnVănVỵ 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 50
Các vấn đề liên quan NguyễnVănVỵ 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 51
Tính khả thi của tiến trình phát triển NguyễnVănVỵ 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 Ví dụ tμi liệu: nghiên cứu khả thi; đặc tả yêu cầu; đặc tả thiết kế 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 52
Lμm tμi liệu phần mềm 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 Bộ mụn Cụng nghệ phần mềm – ĐHCN 53
Sản phẩm (tμi liệu) của dự án NguyễnVănVỵ Phi hình thức, trừu t−ợng Yêu cầu Thiết kế Mã nguồn, chú thích Hình thức hoá, cụ thể Mã máy, dữ liệu, tμi liệu Bộ mụn Cụng nghệ phần mềm – ĐHCN 54
Giảm kích cỡ, chi phí phần mềm NguyễnVănVỵ 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 55
Quan hệ tiến trình vμ sản phẩm NguyễnVănVỵ 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 56
Câu hỏi ôn tập NguyễnVănVỵ 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 57
Câu hỏi ôn tập (t) NguyễnVănVỵ 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 58
Câu hỏi và thảo luận NguyễnVănVỵ Bộ mụn Cụng nghệ phần mềm – ĐHCN 59