Phương pháp mô hình hóa - Quy trình phát triển phần mềm với SDLC

Click to edit Master title style Click to edit Master text styles Second level Third level Fourth level Fifth level 03/11/2013 ‹#› Phương Pháp Mô Hình Hóa Quy Trình Phát Triển Phần Mềm Với SDLC 03/11/2013 1 GV:ThS. Nguyễn Công Hoan Thành Viên Nhóm: Nguyễn Trọng Văn 11520686 Nguyễn Hiếu Trung 11520669 Quy trình phát triển phần mềm (SDLC). 1 2 3 Mô hình phát triển ứng dụng nhanh RAD. Mô hình thác nước. Nội dung 03/11/2013 2 Phát triển phần mềm Một bài toán phức tạp. Cần có khả năng thích ứng và mở rộng. Trước đây: lập trình ngay dù có hoặc không có kiến thức đầy đủ về hệ thống sẽ phát triển. Ngày nay: luôn có kế hoạch phát triển hệ thống từ đầu đến cuối. 03/11/2013 3 SDLC (Software Development Life Cycle) là gì? SDLC là một chuỗi các hoạt động để phát triển và thực hiện một hệ thống thông tin. SDLC rất hữu ích khi xây dựng một hệ thống phức tạp. 03/11/2013 4 Chuỗi hoạt động SDLC Nhà phân tích(Analyst): nghiên cứu yêu cầu của khách hàng. Nhà thiết kế (Designer): Thiết kế hệ thống – quyết định các yêu cầu về phần cứng và phần mềm. Chuyên gia lĩnh vực (Domain Experts): hiểu thực chất vấn đề cùng tất cả những sự phức tạp của hệ thống cần tin học hóa. Lập trình viên (Programmer): dựa trên phân tích và thiết kế để viết chương trình. Người dùng (User): sử dụng hệ thống được phát triển. 03/11/2013 5 Tại sao cần hiểu về SDLC? Không có những quy trình và phương pháp phù hợp thì rất dễ làm chậm trễ dự án và mất nhiều kinh phí hơn. Dễ dàng hơn trong việc bảo trì nâng cấp và mở rộng phần mềm Cải thiện chất lượng công việc và cải thiện hiệu năng làm việc. 03/11/2013 6 Điều gì xảy ra với SDLC? Phát triển phần mềm ngày nay không còn là công việc mà bạn có thể làm một mình. Nhiều nhóm các nhà thiết kế, phát triển, kiểm tra lập thành 1 nhóm cùng làm việc. Hệ thống phần mềm hiện nay đôi khi có thể mất nhiều năm trước khi chúng được sử dụng 03/11/2013 7 Các giai đoạn chính trong SDLC Phân tích tính khả thi (Feasibility analysis): Phân tích yêu cầu và đặc tính kỹ thuật (Requirement analysis and specification) Thiết kế (Design). Mã hóa (Coding). Kiểm thử (Testing). Bảo trì (Maintenance). 03/11/2013 8 Mô hình RAD (Rapid Application Development) Mô hình này đưa ra bởi IBM vào những năm 1980, qua sách của James Martin Là mô hình phát triển phần mềm gia tăng, tăng dần từng bước 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 với khả năng tái sử dụng và sử dụng các ứng dụng tạo mã tự động 03/11/2013 9 Mô hình RAD (Rapid Application Development) Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha: 03/11/2013 10 RAD: Mô hình nghiệp vụ 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? 03/11/2013 11 RAD: Mô hình tiến trình và dữ liệu 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 03/11/2013 12 RAD: Tự sinh ứng dụng và kiểm thử Application Generation: Dùng các kỹ thuật thế hệ thứ 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 sử dụng 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 dùng thử và dùng lại) 03/11/2013 13 Điểm mạnh của RAD là gì? Thời gian phát triển giảm nhờ dùng công cụ „Nhanh chóng cho phép hình dung ra sản phẩm „Dùng hiệu quả các framework và công cụ đóng gói (off-the-shelf tools and frameworks) „Giảm rủi ro nhờ có sự tham gia của khách hàng 03/11/2013 14 RAD: Điểm yếu „Người phát triển phải có kỹ năng và được huấn luyện tốt cho việc sử dụng công cụ và thời gian phát triển nhanh Rủi ro không thể hoàn thành được dự án Không tốt với những ứng dụng không thể môđun hóa hoặc đòi hỏi tính năng cao Khó sử dụng lại các hệ thống cũ „Người phát triển và khách hàng phải nỗ lực Quản lý phức tạp Người quản lý phải làm việc tận tụy với nhóm phát triển và khách hàng để nhanh chóng đạt được các thỏa thuận 03/11/2013 15 Khi nào sử dụng RAD? Hệ thống dễ dàng phân chia module và có thể mở rộng „Hệ thống mà những yêu cầu được biết rõ và hợp lý „Người dùng có thể tham gia tốt qua toàn bộ chu kỳ sống (life cycle) „Dự án có thời gian phát triển ngắn „Những thành phần sử dụng lại có sẵn trong kho phần mềm „Những hệ thống nhỏ, những hệ thống không có tính nghiêm ngặt (critical)…. 03/11/2013 16 MÔ HÌNH THÁC NƯỚC ( WATERFALL) 03/11/2013 17 Như một dòng chảy tuần tự, tuyến tính Một giai đoạn được bắt đầu khi hoàn tất giai đoạn trước nó. Sang giai đoan mới không thể quay lại giai đoạn trước nó. 03/11/2013 18 Khảo sát hiện trạng Hiện trạng bài toán: Mô hình tổ chức Nghiệp vụ Tin học của khách hàng mà phần mềm nhắm tới. Mục tiêu: Hiểu rõ quy trình nghiệp vụ khách hàng. Có bao nhiêu quá trình nghiệp vụ. Họ làm gì với những nghiệp vụ đó. 03/11/2013 19 Trả lời được câu hỏi: Xây dựng làm gì? Ứng dụng vào lĩnh vực nào . Đáp ứng yêu cầu, nhu cầu người dùng: Chức năng: Mô tả hệ thống phải làm gì, khả năng thực hiện những công việc gì… Phi chức năng: độ tin cậy, thời gian đáp ứng, lưu trữ, tương thích giữa phần cứng và phần mềm… Xác định yêu cầu 03/11/2013 20 Là 1 bước quan trọng Tập hợp lại các yêu cầu đã xác định Các yêu cầu tích hợp vào hệ thống như thế nào. Mô hình hóa các yêu cầu. Tạo sơ đồ lớp các đối tượng sẽ sử dụng trong chương trình. Phân tích 03/11/2013 21 Một bản thiết kế tốt là chìa khóa dẫn đến sự thành công. Nhìn thấu các yêu cầu và khả năng trong từng phần thiết kế. Gồm: Nghiên cứu, tìm hiểu vấn đề Xác định đăc trưng của giải pháp. Các mô tả mang tính trừu tượng được sử dụng. Thiết kế 03/11/2013 22 03/11/2013 23 Cài đặt Mã hóa: Cài đặt các thiết kế bằng ngôn ngữ lập trình.Không đơn thuần chỉ là lập trình. Viết tài liệu. Chuẩn lập trình. Lập trình theo cấp. Công cụ. Gỡ rối: Phát hiện các lỗi trong quá trình lập trình. Sản phẩm: chương trình sơ bộ với các chức năng như yêu cầu của khách hàng. 03/11/2013 24 Kiểm thử Kiểm thử: đánh giá phần mềm hay còn gọi là thẩm tra và đánh giá, được sử dụng để chỉ ra rằng hệ thống đã thực hiện theo đúng các đặc tả và thỏa mãn mọi yêu cầu của khách hàng. 03/11/2013 25 Quy trình kiểm thử Kiểm thử thành phần: kiểm thử cách độc lập, thành phần có thể la một chức năng hoặc đối tượng, một nhóm các thực thể gắn kết nhau… Kiểm thử hệ thống: kiểm thử toàn bộ hệ thống. Kiểm thử chấp thuận: kiểm thử trên dữ liệu của khách hàng để kiểm tra hệ thống có đáp ứng tất cả các yêu cầu khách hàng hay không. 03/11/2013 26 Triển khai phần mềm Bảo trì hệ thống: Bảo đảm chương trình vận hành tốt Cài đặt các thay đổi Xử lý các lỗi khi vận hành 03/11/2013 27 Cải tiến phần mềm Khi các yêu cầu hệ thống thay đổi theo sự thay đổi của các yêu cầu nghiệp vụ thì phần mềm phải cải tiến và thay đổi để hỗ trợ khách hàng. Thông thường chi phí để bảo trì và cải tiến thường đắt hơn nhiều so với chi phí xây dựng phần mềm. 03/11/2013 28 Ưu nhược điểm của mô hình Ưu điểm: Dễ hiểu dễ thực hiện. Các pha được xác định rõ ràng. Đầu vào và đầu ra rõ ràng nên dễ phân công công việc. Ước lượng thời gian và chi phí rất chính xác. Kiến trúc hàng đơi ổn định. Quá trình phát triển đơn giản nên phù hợp với những dự án có ít thay đổi Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế. 03/11/2013 29 Nhược điểm: Không quay lui được. Mất nhiều thời gian. Thiết kế phải rõ ràng khi dự án bắt đầu. Không thấy được sự tiến hóa của sản phẩm. Đôi khi dự án bị chậm trễ, mất nhiều kinh phí. Không thể phát triển tiếp sau khi phát hành sản phẩm. Khó đáp ứng yêu cầu khách hàng, khách hàng không chủ động được trong quá trình phát triển phần mềm. Nếu 1 bước không hoàn thiện rủi ro rất cao. Khó cho người sử dụng khi muốn thay đổi yêu cầu. 03/11/2013 30 Những dự án nào nên tiến hành theo mô hình waterfall? Sử dụng khi mà đội dự án đã có kinh nghiệm làm việc, bởi mô hình này đòi hỏi sự chính xác ngay từ đầu. Waterfall hợp với những dự án mà khách hàng xác định được yêu cầu cụ thể, chính xác ngay từ đầu và ít có khả năng thay đổi Đối với những khách hàng lớn mà phong cách làm việc của họ chủ yếu theo mô hình truyền thống (waterfall) hoặc những khách hàng lo ngại có nhiều thay đổi trong dự án Nên áp dụng waterfall với những dự án cố định. 03/11/2013 31 So sánh WATERFALL và RAD Giống nhau: Thường sử dụng cho các hệ thống, phần mềm nhỏ. 03/11/2013 32 Khác nhau: 03/11/2013 33 Câu hỏi 1, SDLC là gì? 2, Có mấy giai đoạn chính trong SDLC? 3, Mô hình RAD thường được sử dụng khi nào? 4, Mô hình thác nước thường được sử dụng khi nào? 03/11/2013 34 1,SDLC là gì? SDLC là một chuỗi các hoạt động của nhà phân tích, nhà thiết kế, người phát triển, người sử dụng để phát triển và thực hiện một hệ thống thông tin 03/11/2013 35 2, Có mấy giai đoạn chính trong SDLC? Có 6 giai đoạn chính trong SDLC: Phân tích tính khả thi (Feasibility analysis) Phân tích yêu cầu và đặc tính kỹ thuật (Requirement analysis and specification) Thiết kế (Design). Mã hóa (Coding). Kiểm thử (Testing). Bảo trì (Maintenance). 03/11/2013 36 4,Mô hình thác nước thường được sử dụng khi nào Sử dụng khi mà đội dự án đã có kinh nghiệm làm việc, bởi mô hình này đòi hỏi sự chính xác ngay từ đầu. Waterfall hợp với những dự án mà khách hàng xác định được yêu cầu cụ thể, chính xác ngay từ đầu và ít có khả năng thay đổi. Đối với những khách hàng lớn mà phong cách làm việc của họ chủ yếu theo mô hình truyền thống (waterfall) hoặc những khách hàng lo ngại có nhiều thay đổi trong dự án Nên áp dụng waterfall với những dự án cố định 03/11/2013 37