Tổng quan về Công nghệ Phần mềm

Chương 3: Tổng quan về Công nghệ Phần mềm(software Engineering) Phạm Thủy Vân Bộ môn Công nghệ phần mềm Khoa Công nghệ thông tin Trường Đại học Nông Nghiệp Hà Nội Van.nuages@gmail.com Nội dung Lịch sử phát triển Công nghệ phần mềm Sự tiến triển của các P.Pháp thiết kế phần mềm Định nghĩa Công nghệ phần mềm Vòng đời của phần mềm Quy trình phát triển phần mềm Software crisis Software crisis Lịch sử phát triển cuả CNPM Nửa đầu 1960: ít quan tâm đến phần mềm, chủ yếu tập trung nâng cao tính năng và độ tin cậy của phần cứng Giữa những năm 1960: Phát triển hệ điều hành như phần mềm lớn (IBM OS/360, EC OS). Xuất hiện nhu cầu về quy trình phát triển phần mềm lớn và quy trình gỡ lỗi, kiểm thử trong phạm vi giới hạn Lịch sử phát triển cuả CNPM Năm 1968: Tại Tây Đức, Hội nghị khoa học của NATO đã đưa ra từ “Software Engineering”. Bắt đầu bàn luận về khủng khoảng phần mềm và xu hướng hình thành CNHPM như một chuyên môn riêng Nửa cuối 1960: IBM đưa ra chính sách phân biệt giá cả giữa phần cứng và phần mềm. Từ đó, ý thức về phần mềm ngày càng cao. Bắt đầu những nghiên cứu cơ bản về phương pháp luận lập trình Lịch sử phát triển cuả CNPM Nửa đầu những năm 1970: Nhằm nâng cao chất lượng phần mềm, không chỉ có các nghiên cứu về lập trình, kiểm thử, mà có cả những nghiên cứu đảm bảo tính tin cậy trong quy trình sản xuất phần mềm. Kỹ thuật: lập trình cấu trúc hóa, lập trình môđun, thiết kế cấu trúc hóa, vv Giữa những năm 1970: Hội nghị quốc tế đầu tiên về CNHPM được tổ chức (1975): International Conference on SE (ICSE) Lịch sử phát triển cuả CNPM Nửa sau những năm 1970: Quan tâm đến mọi pha trong quy trình phát triển phần mềm, nhưng tập trung chính ở những pha đầu. ICSE tổ chức lần 2, 3 và 4 vào 1976, 1978 và 1979 Nhật Bản có “Kế hoạch phát triển kỹ thuật sản xuất phần mềm” từ năm 1981 Cuộc “cách tân sản xuất phần mềm” đã bắt đầu trên phạm vi các nước công nghiệp Lịch sử phát triển cuả CNPM Nửa đầu những năm 1980: Trình độ học vấn và ứng dụng CNHPM được nâng cao, các công nghệ được đưa vào thực tế. Xuất hiện các sản phẩm PM và các công cụ khác nhau làm tăng năng suất sản xuất phần mềm đáng kể ICSE tổ chức lần 5 và 6 năm 1981 và 1982 với trên 1000 người tham dự mỗi năm Nhật Bản sang “Kế hoạch phát triển các kỹ thuật bảo trì phần mềm” (1981-1985) Hiện nay Công nghiệp hóa sản xuất phần mềm bằng cách đưa những kỹ thuật công nghệ học (Engineering techniques) thành cơ sở khoa học của CNHPM Thể chế hóa lý luận trong sản xuất phần mềm và ứng dụng những phương pháp luận một cách nhất quán Tăng cường nghiên cứu và tạo công cụ trợ giúp sản xuất phần mềm Mô hình đánh giá năng lực sản xuất phần mềm CMM/CMMi Mô hình CMM/CMMi do Viện Kỹ Thuật SEI (Software Engineering Institute) liên kết với Đại Học Carnegie Mellon - Hoa Kỳ phát triển. Mô hình CMM trước đây gồm có 5 mức: khởi đầu, lặp lại được, được định nghĩa, được quản lý và tối ưu. Mô hình đánh giá năng lực sản xuất phần mềm CMM/CMMi Một điểm đặc biệt là mỗi doanh nghiệp có thể áp dụng mô hình CMM ở bất kỳ mức nào mà không cần tuân theo bất kỳ một qui định nào, không cần phải đạt mức thấp trước rồi mới có thể đạt mức cao (có thể đi thẳng lên mức cao, hoặc cũng có thể tự hạ xuống mức thấp hơn). Về nguyên tắc, SEI không chính thức đứng ra công nhận CMM mà thông qua các tổ chức tư vấn, các đánh giá trưởng được SEI ủy quyền và thừa nhận. Mô hình đánh giá năng lực sản xuất phần mềm CMM/CMMi CMMI cung cấp một nền tảng mà từ đó các công ty phát triển phần mềm có thể liên tục tối ưu hóa chất lượng quản lý, phát triển và phân phối các sản phẩm. Nó được chia thành 5 cấp tương ứng với 5 mức độ trưởng thành về năng lực trong hoạt động sản xuất phần mềm. Mô hình CMMI do SEI phát triển nhằm tích hợp các quy trình quản lý phát triển hệ thống để cung cấp một nền tảng mà từ đó các công ty phát triển phần mềm có thể liên tục tối ưu hóa chất lượng quản lý, phát triển và phân phối các sản phẩm thậm chí khi công ty đã đạt được chuẩn CMMI cấp 5 - mức cao nhất. Mô hình đánh giá năng lực sản xuất phần mềm CMM/CMMi Xét đến thời điểm này, chưa có số liệu chính xác về số lượng doanh nghiệp phần mềm đang áp dụng mô hình đánh giá năng lực sản xuất phần mềm CMM/CMMi tại Việt Nam, nhưng có thể nhắc đến những tên tuổi như PSV (CMMi mức 5: 2005), GCS (CMMi mức 4: 2006), FPT Software (CMM mức 5: 2004) và SilkRoad (CMM mức 3). Nội dung Lịch sử phát triển Công nghệ phần mềm Sự tiến triển của các P.Pháp thiết kế phần mềm Định nghĩa Công nghệ phần mềm Vòng đời của phần mềm Quy trình phát triển phần mềm Sự tiến triển của các PP TK PM Phương pháp luận trong CNHPM: bắt đầu từ những năm 1970 Trong phát triển phần mềm: nâng cao năng suất, độ tin cậy, giá thành - tính năng (productivity, reliability, cost-performance) Tiến triển phương pháp thiết kế: Sơ khởi, Trưởng thành, Phát triển và Biến đổi Sự tiến triển của các PP TK PM Sơ khởi: nửa đầu 1970 Khái niệm về tính môđun, cụ thể hóa từng bước trong phương pháp luận thiết kế Nilaus Wirth: Chi tiết hóa từng giai đoạn. Thiết kế trên xuống. “Program Development by Stepwise Refinement” “The Generalized 8-Queens Problem” Algorithms + Data Structures = Programs Sự tiến triển của các PP TK PM Trưởng thành: nửa cuối 1970 Phương pháp luận về quy trình thiết kế phần mềm với phương pháp phân chia môđun và thiết kế trong từng môđun. L.L. Constantine, 1974: Thiết kế cấu trúc hóa (phân chia môđun); E.W. Dijkstra, 1972: Lập trình cấu trúc hóa (trong môđun) Phương pháp M.A. Jackson (1975) và J.D. Warnier (1974) Trừu tượng hóa dữ liệu: B.H. Liskov (1974);D.L. Parnas (1972) Sự tiến triển của các PP TK PM Phát triển: nửa đầu 1980 Triển khai các công cụ hỗ trợ phát triển phần mềm dựa trên các phương pháp và kỹ thuật đưa ra những năm 1970 Bộ khởi tạo chương trình (program generators: pre-compiler; graphics-input editors, etc.) Ngôn ngữ đối thoại đơn giản (4GL, DB SQL) Hệ trợ giúp: Hệ trợ giúp kiểm thử; Hệ trợ giúp quản lý thư viện; Hệ trợ giúp tái sử dụng Sự tiến triển của các PP TK PM Biến đổi: nửa cuối 1980 - nay Đưa ra các môi trường mới về phát triển phần mềm. Triển khai mới về kết hợp giữa CNHPM và CNH Tri thức (Knowledge Engineering) Triển khai những môi trường bậc cao về phát triển phần mềm; Tự động hóa sản xuất phần mềm; Chế phần mềm theo kỹ thuật chế thử (Prototyping); Lập trình hướng đối tượng - OOP; Hướng thành phần; Hỗ trợ phát triển phần mềm từ các hệ chuyên gia, … Hiện nay Animation de diagrammes UML Use (UML- base Specification Environment) UML Executable Sự tiến triển của các PP TK PM Đưa ra các kỹ thuật, phương pháp luận ứng dụng thực tế vào từng quy trình Cải biên, biến đổi vào từng sản phẩm và công cụ phần mềm (máy tính hóa từng phần) Tổng hợp, hệ thống hóa cho từng loại công cụ (Máy tính hóa toàn bộ quy trình sản xuất phần mềm) Hướng tới sản xuất phần mềm tự động Nội dung Lịch sử phát triển Công nghệ phần mềm Sự tiến triển của các P.Pháp thiết kế phần mềm Định nghĩa Công nghệ phần mềm Vòng đời của phần mềm Quy trình phát triển phần mềm Định nghĩa công nghệ phần mềm Bauer [1969]: CNHPM là việc thiết lập và sử dụng các nguyên tắc công nghệ học đúng đắn dùng để 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 Parnas [1987]: CNHPM là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người Ghezzi [1991]: CNHPM là một lĩnh vực của khoa học máy tính, liên quan đến xây dựng các hệ thống phần mềm vừa lớn vừa phức tạp bởi một hay một số nhóm kỹ sư Định nghĩa công nghệ phần mềm IEEE [1993]: CNHPM là (1) việc áp dụng phương pháp tiếp cận có hệ thống, bài bản và được lượng hóa trong phát triển, vận hành và bảo trì phần mềm; (2) nghiên cứu các phương pháp tiếp cận được dùng trong (1) Pressman [1995]: CNHPM là bộ môn tích hợp cả quy trình, các phương pháp, các công cụ để phát triển phần mềm máy tính Định nghĩa công nghệ phần mềm Công nghệ học phần mềm là lĩnh vực khoa học về các phương pháp luận, kỹ thuật và công cụ tích hợp trong quy trình sản xuất và vận hành phần mềm nhằm tạo ra phần mềm với những chất lượng mong muốn [Software Engineering is a scientìic field to deal with methodologies, techniques and tools integrated in software production-maintenance process to obtain software with desired qualities] Công nghệ học trong CNPM (1) Như các ngành công nghệ học khác, CNHPM cũng lấy các phương pháp khoa học làm cơ sở (2) Các kỹ thuật về thiết kế, chế tạo, kiểm thử và bảo trì phần mềm đã được hệ thống hóa hóa thành phương pháp luận và hình thành nên CNHPM (3) Toàn bộ quy trình quản lý phát triển phần mềm gắn với khái niệm vòng đời phần mềm, được mô hình hóa với những kỹ thuật và phương pháp luận trở thành các chủ đề khác nhau trong CNHPM Công nghệ học trong CNPM (4) Trong vòng đời phần mềm không chỉ có chế tạo mà bao gồm cả thiết kế, vận hành và bảo dưỡng (tính quan trọng của thiết kế và bảo dưỡng) (5) Trong khái niệm phần mềm, không chỉ có chương trình mà cả tư liệu về phần mềm (6) Cách tiếp cận công nghệ học (khái niệm công nghiệp hóa) thể hiện ở chỗ nhằm nâng cao năng suất (tính năng suất) và độ tin cậy của phần mềm, đồng thời giảm chi phí giá thành Nội dung Lịch sử phát triển Công nghệ phần mềm Sự tiến triển của các P.Pháp thiết kế phần mềm Định nghĩa Công nghệ phần mềm Vòng đời của phần mềm Quy trình phát triển phần mềm Summery CNPM bao gồm cả những nghiên cứu về công nghệ, các phương thức và công cụ để xây dựng một phần mềm. Việt phát triển một hệ thống phần mềm không chỉ bó hẹp trong phạm vi code. Khách hàng thường quan tâm: Đó có phải là một sản phẩm tốt? Giá thành rẻ? Thời gian có được sản phẩm? Sản phẩm dễ dàng cải tiến để đáp ứng những thay đổi về nhu cầu cuả người sử dụng? Vòng đời phần mềm Vòng đời phần mềm là thời kỳ tính từ khi phần mềm được sinh (tạo) ra cho đến khi chết đi (từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại bỏ không đâu dùng) Quy trình phần mềm (vòng đời phần mềm) được phân chia thành các pha chính: phân tích, thiết kế, chế tạo, kiểm thử, bảo trì. Biểu diễn các pha có khác nhau theo từng người Các giai đoạn phát triển PM Requirements Engineering Specification Design Coding Test Test Test Giai đoạn xác định yêu cầu Hiểu lĩnh vực thông tin, chức năng, hành vi, tính năng và giao diện của phần mềm sẽ phát triển. Cần phải tạo tư liệu và bàn thảo với khách hàng, người dùng Sản phẩm: “cahier des charges” giai đoạn phân tích để xây dựng một phần mềm chất lượng Giai đoạn đặc tả Mô hình hoá yêu cầu hoặc giải pháp phát triển Các yêu cầu được cấu trúc hoá và được diễn tả chính xác Mô tả các chức năng chính và giao diện Sản phẩm: tài liệu tham khảo cho các giai đoạn tiếp theo Giai đoạn thiết kế Là quá trình nhiều bước với 4 thuộc tính khác nhau của một chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ tục (thuật toán). Cần tư liệu hóa và là một phần quan trọng của cấu hình phần mềm Đảm bảo tính performances, Evolution của phần mềm Giai đoạn coding Chuyển thiết kế thành chương trình máy tính bởi ngôn ngữ nào đó. Nếu thiết kế đã được chi tiết hóa thì lập trình có thể chỉ thuần túy cơ học Áp dụng các techniques informatique để “sản xuất” phần mềm: Langages BD OS … Các giai đoạn kiểm thử Kiểm tra các chương trình và môđun cả về lôgic bên trong và chức năng bên ngoài, nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thì cho kết quả mong muốn Chứng minh rằng tất cả các mục tiêu của từng giai đoạn đáp ứng trong sản phẩm Các hoạt động xuyên suốt Điều hành dự án Phân phối thời gian và quản lý nguồn nhân lực Ước lượng kinh phí dự án Xác định và cảnh báo sớm các rủi ro Đưa ra được sản phẩm đúng thơì gian và giá thành hợp lý nhất Các hoạt động xuyên suốt Điều hành dự án Phân phối thời gian và quản lý nguồn nhân lực Ước lượng kinh phí dự án Xác định và cảnh báo sớm các rủi ro Đưa ra được sản phẩm đúng thơì gian và giá thành hợp lý nhất Đảm bảo chất lượng sản phẩm cuối cùng thông qua việc kiểm soát và các tiến trình điều khiển việc thực hiện dự án. Nâng cấp và bảo trì Vòng đời cuả phần mềm chưa kết thúc ở giai đoạn bàn giao sản phẩm Đáp ứng những thay đổi, nâng cấp phần mềm đã phát triển do sự thay đổi của môi trường, nhu cầu Bảo trì vận hành: sửa lỗi phát sinh Bản trì cải tiến: đáp ứng những thay đổi về môi trường và yêu cầu của người sử dụng Ex: thêm chức năng mới Thay đổi OS Suy nghĩ mới về vòng đời PM (1) Pha 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 lập trình, kiểm thử và chuyển giao phần mềm (2) Pha cụ thể hóa cấu trúc phần mềm phụ thuộc nhiều vào suy nghĩ trên xuống (top-down) và trừu tượng hóa, cũng như chi tiết hóa (3) Pha thiết kế, chế tạo thì theo trên xuống, pha kiểm thử thì dưới lên (bottom-up) Suy nghĩ mới về vòng đời PM (4) Trước khi chuyển sang pha kế tiếp phải đảm bảo pha hiện nay đã được kiểm thử không còn lỗi (5) Cần có cơ chế kiểm tra chất lượng, xét duyệt giữa các pha nhằm đảm bảo không gây lỗi cho pha sau (6) Tư liệu của mỗi pha không chỉ dùng cho pha sau, mà chính là đối tượng quan trọng cho kiểm tra và đảm bảo chất lượng của từng quy trình và của chính phần mềm Suy nghĩ mới về vòng đời PM (7) Cần chuẩn hóa mẫu biểu, cách ghi chép tạo tư liệu cho từng pha, nhằm đảm bảo chất lượng phần mềm (8) Thao tác bảo trì phần mềm là việc xử lý quay vòng trở lại các pha trong vòng đời phần mềm nhằm biến đổi, sửa chữa, nâng cấp phần mềm “off-shore” Giai đoạn Coding, thiết kế chi tiết và một vài giai đoạn kiểm thử được thực hiện ở những nước có giá thành nhân công rẻ Các giai đoạn còn laị được thực hiện ở “gần” khách hàng hoặc thích hợp với kỹ năng nghề nghiệp cuả công ty Nội dung Lịch sử phát triển Công nghệ phần mềm Sự tiến triển của các P.Pháp thiết kế phần mềm Định nghĩa Công nghệ phần mềm Vòng đời của phần mềm Quy trình phát triển phần mềm Các yếu tố cơ bản của quy trình Thủ tục (procedure) Hướng dẫn công việc (Activity Guidelines) Biểu mẫu (Forms/templates) Danh sách kiểm định (Checklists) Công cụ hỗ trợ (Tools) Các nhóm công việc chính Đặc tả yêu cầu (requirements Specification): Chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng. Phát triển phần mềm (Development): tạo ra PM thỏa mãn các yêu cầu được chỉ ra trong “Đặc tả yêu cầu”. Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”. Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng. Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng. Vòng đời PM Vòng đời PM được xác định bởi tập hợp các pha và mối liên hệ giữa các pha Mỗi pha bao gồm nhiệm vụ, các ràng buộc, nguồn và phương thức thực hiện Phần lớn các mô hình vòng đời đều bao gồm các hoạt động cơ bản nt nhưng cách tổ chức khác nhau Có rất nhiều mô hình vòng đời trong phát triển PM Mỗi mô hình thích hợp với một tổ chức và kiểu phần mềm khác nhau (Ex: embarqué) Có rất ít công cụ để thiết kế vòng đời phần mềm Các mô hình phát triển PM Các mô hình một phiên bản Waterfall model (mô hình tuyến tính) Mô hình chữ V Các mô hình nhiều phiên bản Mô hình mẫu (Prototype) Mô hình tiến hoá Mô hình lặp và tăng dần (Incremental & iterative) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Mô hình xoắn ốc (Spiral model) Waterfall model Waterfall model Các giai đoạn xử lý nối tiếp nhau: Phân tích yêu cầu và tài liệu đặc tả (Requirements&Specifications): Hệ thống sẽ làm gì? Fonctions & no fonctions Kết qủa: “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification) Phân tích hệ thống và thiết kế (System Analysis and Design): “Làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó. Waterfall model Thực hiện & kiểm thử từng TP (Coding and Unit Test): Thực hiện theo cấu trúc được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế” Kiểm thử (Test): Kiểm thử mã (code) đã được hiện thực Kiểm thử tích hợp cho nhóm các thành phần Kiểm thử toàn hệ thống (system test). Khâu kiểm thử cuối cùng: Nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không. Waterfall model Cài đặt và bảo trì (Deployment and Maintenance): Cài đặt, cấu hình và huấn luyện khách hàng. Sửa chữa những lỗi của phần mềm (nếu có) Phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng / đặc điểm của hệ thống). Waterfall model “Code and fix” Lập trình trước, sửa sau Phát triển tự nhiên, “hoang dã” Phân tích nhanh, ưu tiên cho code Code version 0 Thay đổi Waterfall model Mô hình nguyên thủy Không phù hợp để phát triển trong equipe hoặc trong các dự án lớn Waterfall model Mô hình có lặp Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại để sửa chữa.  Iterative Waterfall (Hình trên) Có lặp lại sau mỗi bước Linh hoạt hơn nhưng khó quản lý Số lượng lặp có giới hạn Waterfall model - ưu điểm Đơn giản, dễ hiểu Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng. Đầu vào và đầu ra đều là tài liệu. Một pha không thể kết thúc trước khi tài liệu cuả nó được kiểm chứng Việc kiểm định gắn liền với từng giai đoạn Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xây dựng phần mềm theo trình tự rõ ràng. Waterfall model - nhược điểm Tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. Đa số dự án thực tế: yêu cầu phần mềm thường ẩn chứa những điểm không chắc chắn. Các dự án hiếm khi được thực hiện đầy đủ các bước trong suốt chu kỳ dự án (Đặc biệt là giai đoạn kiểm thử), nếu có trục trặc xảy ra do yêu cầu phần mềm không rõ ràng hay thiết kế có lỗi, xu hướng là mã nguồn được sửa đổi trực tiếp mà không qua các bước bổ sung theo đúng mô hình  Bản đặc tả PM & một số SP trung gian (bản thiết kế) cho dù có được cập nhật sau không phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn. Waterfall model - nhược điểm Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử dụng chỉ có thể nhận ra rằng hệ thống phần mềm không phù hợp cho nhu cầu của họ vào thời điểm cuối dự án. Nói chung, mô hình này thường ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng (được minh họa trong hình vẽ) và chi phí để sửa chữa có thể rất cao. Waterfall model - ứng dụng Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi, thường xuất phát từ sản phẩm đã đạt mức ổn định. Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ đầu dự án Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có nhiều kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm. Dự án được xác định hầu như không có rủi ro. Vẫn còn tương đối phổ biến, nhất là đối với những người lập trình không chuyên. Các mô hình phát triển PM Các mô hình một phiên bản Waterfall model (mô hình tuyến tính) Mô hình chữ V Các mô hình nhiều phiên bản Mô hình mẫu (Prototype) Mô hình tiến hoá Mô hình lặp và tăng dần (Incremental & iterative) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Mô hình xoắn ốc (Spiral model) Mô hình chữ V Mô hình chữ V Waterfall: kiểm thử được thực hiện trong một giai đoạn riêng biệt. Mô hình chữ V: toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau Phát triển Kiểm thử Tinh thần chủ đạo của V-model : các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống Mô hình chữ V - Ưu điểm Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạt động liên quan đến đặc tả yêu cầu và thiết kế. Mô hình này khuyến khích các hoạt động liên quan đến kế hoạch kiểm thử được tiến hành sớm trong chu kỳ phát triển, không phải đợi đến lúc kết thúc giai đoạn cuối Giảm được độ rủi ro trong quá trình phát triển phần mềm Mô hình chữ V - Nhược điểm & sử dụng Giống mô hình waterfall Các mô hình phát triển PM Các mô hình một phiên bản Waterfall model (mô hình tuyến tính) Mô hình chữ V Các mô hình nhiều phiên bản Mô hình mẫu (Prototype) Mô hình tiến hoá Mô hình lặp và tăng dần (Incremental & iterative) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Mô hình xoắn ốc (Spiral model) Mô hình mẫu - Prototype Thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu tổng thể của hệ thống PM Ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ. Mô hình mẫu - Prototype Ý tưởng: xây dựng các prototype để hiểu rõ hơn những điểm phức tạp (exigences, technologies) Mô hình mẫu - Prototype Thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm.  Tinh chỉnh yêu cầu  Giúp đội ngũ phát triển thông hiểu hơn những gì cần được phát triển. Mô hình mẫu - Prototype Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác. Prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó. Mô hình mẫu - ưu điểm Người sử dụng sớm hình dung ra chức năng và đặc điểm của hệ thống. Cải thiện sự liên lạc giữa nhà phát triển và người sử dụng. Làm sáng tỏ những điểm phức tạp Cho phép đánh giá những rủi ro và kiểm tra giải pháp Có ích trong tất cả các pha của vòng đời PM Có một số tiện ích làm maquettage/Prototypage (Axure, JMap®, SOLAP) Mô hình mẫu - nhược điểm Khi mẫu (prototype) không chuyển tải hết các chức năng, đặc điểm của hệ thống phần mềm thì người sử dụng có thể thất vọng và mất đi sự quan tâm đến hệ thống sẽ được phát triển. Prototype thường được làm nhanh, thậm chí vội vàng, theo kiểu “hiện thực - sửa” và có thể thiếu sự phân tích đánh giá một cách cẩn thận tất cả khía cạnh liên quan đến hệ thống cuối cùng. Nói chung mô hình này vẫn chưa thể cải thiện được việc loại trừ khoảng cách giữa yêu cầu và ứng dụng cuối cùng. Mô hình mẫu - ứng dụng Hệ thống chủ yếu dựa trên giao diện người dùng (GUI) Khách hàng, nhất là người sử dụng cuối, không thể xác định rõ ràng yêu cầu. Các mô hình phát triển PM Các mô hình một phiên bản Waterfall model (mô hình tuyến tính) Mô hình chữ V Các mô hình nhiều phiên bản Mô hình mẫu (Prototype) Mô hình tiến hoá Mô hình lặp và tăng dần (Incremental & iterative) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Mô hình xoắn ốc (Spiral model) Mô hình tiến hoá Mô hình tiến hoá Là một dạng dựa trên mô hình mẫu, tuy nhiên có sự khác biệt: Mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau. Những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng trong những phiên bản sau Một số phần của hệ thống phần mềm có thể đuợc xây dựng sớm ngay từ giai đoạn thực hiện phân tích yêu cầu và thiết kế Mô hình tiến hoá - Ưu điểm Chú trọng việc tái sử dụng mẫu. Một phần của hệ thống có thể được phát triển ngay trong các giai đoạn phân tích phát triển yêu cầu và thiết kế. Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự án. Mô hình tiến hoá - Nhược điểm Làm chậm quá trình phát triển yêu cầu và có thể ảnh hưởng sự chú ý đến các công việc trung gian như kiểm tra mã nguồn, thực hiện kiểm thử cấp thấp… Dễ dẫn đến kết cấu của hệ thống kém. Thường thì với mô hình này, tính chặt chẽ, minh bạch của qui trình kém. Mô hình tiến hoá - Ứng dụng Hệ thống tương tác nhỏ và vừa; Phần GUI của những hệ thống lớn; Những hệ thống cần chu kỳ phát triển ngắn. Đội ngũ phát triển không quen thuộc với lĩnh vực của dự án. Các mô hình phát triển PM Các mô hình một phiên bản Waterfall model (mô hình tuyến tính) Mô hình chữ V Các mô hình nhiều phiên bản Mô hình mẫu (Prototype) Mô hình tiến hoá Mô hình lặp và tăng dần (Incremental & iterative) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Mô hình xoắn ốc (Spiral model) Mô hình lặp và tăng dần Mô hình lặp và tăng dần có lúc được hiểu là một. Điểm giống nhau : Dựa trên tinh thần của mô hình tiến hóa; Nhắm đến việc cung cấp một phần hệ thống để khách hàng có thể đưa vào sử dụng trong môi trường hoạt động sản xuất thực sự mà không cần chờ cho đến khi toàn bộ hệ thống được hoàn thành; Mô hình lặp và tăng dần Trong mô hình mẫu hay tiến hóa, các phiên bản mẫu hay trung gian đều không nhắm đến đưa vào vận hành thực sự cho khách hàng, trừ phiên bản cuối cùng. Để khách hàng có thể sử dụng, mỗi phiên bản đều phải được thực hiện như một qui trình đầy đủ các công việc từ phân tích yêu cầu với khả năng bổ sung hay thay đổi, thiết kế, hiện thực cho đến kiểm nghiệm và có thể xem như một qui trình (chu trình) con. Các chu trình con có thể sử dụng các mô hình khác nhau (thông thường là waterfall) Mô hình lặp và tăng dần Mục tiêu của phiên bản đầu tiên là phát triển phần lõi và nhóm các chức năng quan trọng. Sau mỗi phiên bản được đưa vào sử dụng, các kết quả đánh giá sẽ được phản hồi và lập kế hoạch cho chu trình con của phiên bản tiếp theo để thực hiện: Những thay đổi cho phiên bản trước đó nhằm đáp ứng nhu cầu khách hàng tốt hơn Có thể thêm những chức năng hoặc đặc điểm bổ sung Mô hình lặp và tăng dần Mô hình phát triển tăng dần So với sản phẩm được hoàn thành trong chu trình con trước: Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm Mô hình lặp và tăng dần Mô hình phát triển lặp So với sản phẩm được hoàn thành trong chu trình con trước: Mô hình lặp (Iterative): thay đổi sản phẩm Một SEP có thể kết hợp cả hai mô hình lặp lẫn tăng dần, Ex: UP (Rational Unified Process) Mô hình lặp và tăng dần - Principes Chia projet thành các increments Mỗi increment  một phần chức năng của sản phẩm cuối cùng Mỗi increment thêm các chức năng mới Mỗi increment được kiểm tra như sản phẩm cuối cùng Các increment được xác định thứ tự ưu tiên (phân lớp các yêu cầu bởi khách hàng - nếu có thể) Mô hình lặp - Principes Trong mô hình lặp, phiên bản đầu tiên được đưa ra giống như 1 chiếc phong bì hoàn chỉnh Mỗi phiên bản mới đưa ra như một phần nhỏ của hệ thống theo kiến trúc được xác định ban đầu Các Increments có thể phát triển song song Mô hình lặp và tăng dần - ưu điểm Phiên bản đầu tiên được đưa ra sớm Phản hồi sớm về vốn đầu tư Giảm căng thẳng cho người quản lý Nói chung, phiên bản đầu tiên ít được đưa vào sử dụng Giảm được rủi ro trong quá trình phát triển phần mềm Phát hiện sớm các vấn đề Những phần quan trọng của hệ thống được kiểm tra nhiều lần trong suốt quá trình phát triển phần mềm Khách hàng có thể thêm các yêu cầu mới vào bất kỳ thời điểm nào. Mô hình lặp và tăng dần - ưu điểm Những yêu cầu quan trọng thường được xây dựng và chuyển đến người sử dụng sớm. Phản hồi của nguời sử dụng về những vấn đề phát sinh trong phiên bản trước được dùng để cải tiến và ngăn ngừa những vấn đề tương tự xảy ra trong những phiên bản tiếp theo. Mô hình lặp và tăng dần - nhược điểm Tổng chi phí lập kế hoạch phát triển cho toàn hệ thống có thể cao hơn Trong thực tế, nếu ứng dụng hợp lý, toàn bộ chi phí và thời gian cho đến khi sản phẩm được nghiệm thu có thể thấp hơn so với mô hình khác. Các yêu cầu về kế hoạch và hoạt động trong qui trình cụ thể sẽ phức tạp hơn. Mô hình lặp và tăng dần - nhược điểm Đối với các increments Để bao phủ được hết các yêu cầu trên các increments là rất phức tạp Quá ít increments: quay trở lại cách tiếp cận theo mô hình thác nước Quá nhiều increments: Khó điều khiển và quản lý Mô hình lặp và tăng dần - nhược điểm Đối với kiến trúc Khó có thể thiết kế được kiến trúc ổn định ngay từ đầu Khó cải tiến (evolutive) Khó xác định các dịch vụ kỹ thuật (technique services) chung cho tất cả các increments Khó quản lý những thay đổi và yêu cầu cải tiến sản phẩm (do sự ràng buộc về cấu trúc) Mô hình lặp - ứng dụng Đội ngũ phát triển quen thuộc với lĩnh vực dự án nhưng không có nhiều kinh nghiệm, nhất là về công nghệ được dùng phát triển dự án Có nhiều rủi ro về mặt kỹ thuật Mô hình tăng dần - ứng dụng Rủi ro được phân tích và xác định ngay từ đầu. Giao tiếp giữa các module cũng được xác định rõ ràng từ đầu. Đội ngũ phát triển quen thuộc với lĩnh vực của dự án và có nhiều kinh nghiệm. Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai sớm một số phần của hệ thống. Các mô hình phát triển PM Các mô hình một phiên bản Waterfall model (mô hình tuyến tính) Mô hình chữ V Các mô hình nhiều phiên bản Mô hình mẫu (Prototype) Mô hình tiến hoá Mô hình lặp và tăng dần (Incremental & iterative) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Mô hình xoắn ốc (Spiral model) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Là quy trình phát triển phần mềm gia tăng, tăng dần từng bước (Incrimental software development) với mỗi chu trình phát triển rất ngắn (60-90 ngày) Xây dựng dựa trên hướng thành phần (Component-based construction) với khả năng tái sử dụng (reuse) Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hình xử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business, Data, Process, Appl. Generation, Test) Mô hình phát triển ứng dụng nhanh Business Modeling Data Modeling Process Modeling Application Generation Testing & Turnover 60 - 90 days Team #1 Team #2 Team #3 RAD - Business modeling Luồng thông tin được mô hình hóa để trả lời các câu hỏi: Thông tin nào điều khiển xử lý nghiệp vụ ? Thông tin gì được sinh ra? Ai sinh ra nó ? Thông tin đi đến đâu ? Ai xử lý chúng ? RAD - Data and Process modeling Data modeling: các đối tượng dữ liệu cần để hỗ trợ nghiệp vụ (business). Định nghĩa các thuộc tính của từng đối tượng và xác lập quan hệ giữa các đối tượng Process modeling: Các đối tượng dữ liệu được chuyển sang luồng thông tin thực hiện chức năng nghiệp vụ. Tạo mô tả xử lý đễ cập nhật (thêm, sửa, xóa, khôi phục) từng đối tượng dữ liệu RAD - Appl. Generation and Testing Application Generation: Dùng các kỹ thuật thế hệ 4 để tạo phần mềm từ các thành phần có sẵn hoặc tạo ra các thành phần có thể tái dụng lại sau này. Dùng các công cụ tự động để xây dựng phần mềm Testing and Turnover: Kiểm thử các thành phần mới và kiểm chứng mọi giao diện (các thành phần cũ đã được kiểm thử và dùng lại) RAD - ưu điểm Cho phép giảm thời gian phát triển các ứng dụng CSDL và có nhiều giao diện người dùng hay tích hợp các thành phần có sẵn. Người sử dụng sẽ tham gia vào các hoạt động kiểm thử. RAD - nhược điểm Khó có sự nhất quán giữa những thành phần được phát triển bởi các nhóm khác nhau. Không phù hợp cho những ứng dụng đòi hỏi hiệu suất vì thường phụ thuộc vào sự hỗ trợ của môi trường phát triển và ngôn ngữ cấp cao. RAD - ứng dụng Hệ thống quản lý thông tin kiểu những ứng dụng dựa trên GUI và CSDL. Có sự hỗ trợ của công cụ hay sử dụng ngôn ngữ cấp cao. Hệ thống không yêu cầu khắt khe về hiệu suất. Các mô hình phát triển PM Các mô hình một phiên bản Waterfall model (mô hình tuyến tính) Mô hình chữ V Các mô hình nhiều phiên bản Mô hình mẫu (Prototype) Mô hình tiến hoá Mô hình lặp và tăng dần (Incremental & iterative) Mô hình phát triển ứng dụng nhanh (RAD - Rapid Application Development) Mô hình xoắn ốc (Spiral model) Mô hình xuắn ốc Mô hình này được xây dựng bởi Barry Boehm, Đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản chất của mô hình lặp. Việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung vào thiết kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung. Mô hình xuắn ốc Ví dụ: Sự thiếu hụt về nguồn nhân lực Thời gian và ngân sách không khả thi Phát triển các chức năng không thích hợp Phát triển giao diện người dùng không hợp lý Sản phẩm không có giá trị thực sự (plaques or) Các yêu cầu dễ thay đổi Vấn đề về hiệu năng Những yêu cầu, đòi hỏi khó đo lường bằng các tiêu chuẩn về công nghệ … Mô hình xuắn ốc Mô hình xuắn ốc - Lưu ý Mô hình xuắn ốc thực chất là một meta - model Mô hình đưa ra một giới hạn trong đó mỗi vòng (boucle) phải bao gồm đầy đủ các giai đoạn Có thể định nghĩa trong mô hình: 1 vòng nghiên cứu tính khả thi 1 vòng làm prototype Các vòng phát triển lặp, …  Phải tìm ra các mô hình thích hợp cho mỗi vòng Mô hình xuắn ốc - 4 etaps trong chu kỳ Xác định mục tiêu chất lượng cho sản phẩm được thực hiện, xác định sự lựa chọn mua, tái sử dụng hay tự thiết kế và hiện thực các thành phần của hệ thống. Phân tích sự lựa chọn và các rủi ro có thể xảy ra. (Thực hiện bởi nhiều hoạt động khác nhau thông qua làm mẫu hay mô phỏng. Phát triển và kiểm định sản phẩm ở mức tiếp theo dựa trên kết quả định hướng được chỉ ra trong giai đoạn con số 2 (phân tích rủi ro) Kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đó và lập kế hoạch cho chu kỳ lặp tiếp theo. Mô hình xuắn ốc - Exemple Phân tích nhanh yêu cầu: Xây dựng một phần mềm quản lý việc mượn tài liệu trong một thư viện rất hiện đại. Tài liệu cuả thư viện bao gồm nhiều nguồn khác nhau (multimedia) Phần mềm cho phép hiển thị, mượn, download và đặt trước tài liệu Phần mềm phải được sử dụng những công nghệ mới nhất Những người sử dụng trong tương lai không biết hết những công nghệ mới Exemple - Problemes Đó là một sản phẩm mới Không thể dựa trên sản phẩm đã có Nguồn và kiểu dữ liệu mới Sử dụng các công nghệ mới, chưa được huấn luyện thành thục Yêu cầu của khách hàng cần phải làm mịn Exemple - Approach Tiếp cận theo phương pháp lặp với 5 vòng (boucle) Vòng 1: nghiên cứu tính khả thi Vòng 2: làm mẫu (Prototype) Vòng 3: Chức năng hiển thị Vòng 4: Chức năng mượn và download tài liệu Vòng 5: Các chức năng đặt trước (reserve) Exemple – Boucle 1 Mục tiêu: Nghiên cứu tính khả thi Tập trung vào công nghệ → Không làm prototype Tìm các công nghệ thay thế khi có sự cố Xác định rủi ro sự hiểu biết về công nghệ còn yếu →Đào tạo ngay Kế hoạch và thực hiện 1 tháng làm việc + 1 tuần đào tạo 2 người (phân chia công việc) Exemple – Boucle 2 Mục tiêu: Xây dựng mẫu (prototype) Đề xuất giao diện người máy Xác định rủi ro sự hiểu biết về quy trình làm việc trong thư viện chưa đầy đủ → Tổ chức các buổi trao đổi Kế hoạch và thực hiện 1 tháng làm việc 4 người Exemple – Boucle 3 Mục tiêu: Đưa ra một kiến trúc ổn định Thực hiện chức năng hiển thị Xác định rủi ro Truy cập vào cơ sở dữ liệu của các tài liệu  Nhân đôi một phần dữ liệu Kế hoạch và thực hiện 6 tháng làm việc 6 người Exemple – Boucle 4 Mục tiêu: Sử dụng lại và cập nhật kiến trúc đã tồn tại Thực hiện chức năng cho mượn và download Xác định rủi ro Vấn đề an ninh  Liện hệ với các chuyên gia và tinh lược các yêu cầu. Kế hoạch và thực hiện 9 tháng làm việc 6 người Exemple – Boucle 5 Mục tiêu: Sử dụng lại và thay đổi kiến trúc đã tồn tại Thực hiện chức năng đặt trước tài liệu Xác định rủi ro Lo lắng về việc chậm tiến độ  Thoả thuận với khách hàng để xác định phương án “hoãn binh” tốt nhất. Hiệu suất  Sự tương thích giữa các cấu trúc Kế hoạch và thực hiện 6 tháng làm việc 6 người Mô hình xuắn ốc - ưu điểm Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi “spiral” để tăng mức độ tin cậy của dự án. Kết hợp những tính chất tốt nhất của mô hình waterfall & tiến hóa Cho phép thay đổi tùy theo đk thực tế dự án tại mỗi “spiral”. Đây chính là mô hình tổng quát nhất, tất cả các mô hình khác đều có thể xem là một hiện thực của mô hình tổng quát này, hay cũng có thể xem nó là mô hình tổng hợp các mô hình khác. Đặc biệt, nó được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát triển phần cứng. Mô hình xuắn ốc - nhược điểm Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro. Cần có kỹ năng tốt về phân tích rủi ro. Mô hình xuắn ốc - ứng dụng Dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự đảm bảo nhất định; Những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ trợ quyết định. Đội ngũ thực hiện dự án có khả năng phân tích rủi ro.