Bài giảng Nhập môn Công nghệ phần mềm - Chương 1: Tổng quan về công nghệ phần mềm (Phần 2)

Nội dung text: Bài giảng Nhập môn Công nghệ phần mềm - Chương 1: Tổng quan về công nghệ phần mềm (Phần 2)

1. II. Quy trình phát triển phần mềm 1. Cách giải quyết vấn đề 2. Một số mô hình 3. Các công đoạn chính 4. Các tiêu chuẩn
2. Quy trình phát triển phần mềm Quy trình phát triển phần mềm (còn gọi tắt là quy trình phần mềm) là một tập hợp các hành động phải được thực hiện trong quá trình xây dựng một hệ thống phần mềm.
3. Cách giải quyết vấn đề Từ lập trình đi lên Các tri thức liên quan đến lập trình Tri thức về cách hoạt động của công cụ xử lý thông tin (tư duy giải thuật) Tri thức về cách triển khai, giải quyết vấn đề bằng máy tính (tư duy hệ thống)
4. Cách giải quyết vấn đề  Các giai đoạn của lập trình 1. Nhận yêu cầu tính toán 2. Tìm hiểu bài toán đặt ra 3. Phát triển giải thuật giải quyết bài toán 4. Chuyển thuật toán thành chương trình máy tính 5. Chạy chương trình để kiểm tra và sửa chữa 6. Thực hiện tính toán và chuyển giao kết quả đến nơi yêu cầu
5. Cách giải quyết vấn đề Vấn đề, giải pháp và giải quyết vấn đề Yêu cầu của khách hàng: Vấn đề hay bài toán Sản phẩm, dịch vụ giải quyết các yêu cầu: Giải pháp. Công nghệ chỉ là công cụ, phương tiện, cần có con người áp dụng để đạt được mục đích
6. Cách giải quyết vấn đề  Để giải quyết vấn đề, giữa khách hàng và người cung cấp phải có các văn bản pháp lý ràng buộc, dưới dạng các dự án và hợp đồng.  Dự án là nổ lực giải quyết vấn đề.  Phương pháp xác định ra cách tiến hành các nổ lực giải quyết vấn đề  Tiến trình là việc thực hiện của phương pháp
7. Cách giải quyết vấn đề Góc nhìn chung về giải quyết vấn đề
8. Cách giải quyết vấn đề Góc nhìn chi tiết về giải quyết vấn đề
9. Các nhân tố
10. Một số mô hình phát triển phần mềm Mô hình thác nước Mô hình xây dựng tiến triển Công nghệ phần mềm dựa thành phần Mô hình phát triển lặp lại, tăng thêm Mô hình xoắn ốc
11. Mô hình thác nước
12. Mô hình thác nước  Thực hiện một cách tuần tự.  Nhược điểm chính là rất khó khăn trong việc thay đổi các pha đã được thực hiện.  Thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế.  Thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định
13. Mô hình Prototype
14. Mô hình Prototype  Có hai phương pháp để thực hiện mô hình này:  Phát triển thăm dò: mục đích là để làm việc với khách hàng và để đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu.  Loại bỏ mẫu thử: mục đích là để tìm hiểu các yêu cầu của hệ thống
15. Mô hình Prototype  Nhược điểm của mô hình là thiếu tầm nhìn của cả quy trình; Các hệ thống thường hướng cấu trúc nghèo nàn, Yêu cầu các kỹ năng đặc biệt (Ví dụ: các ngôn ngữ để tạo ra mẫu thử nhanh chóng)  Chỉ nên áp dụng với những hệ thống có tương tác ở mức độ nhỏ hoặc vừa; trên một phần của những hệ thống lớn; hoặc những hệ thống có thời gian chu kỳ tồn tại ngắn.
16. Công nghệ phần mềm dựa thành phần
17. Công nghệ phần mềm dựa thành phần  Mô hình này dựa trên kỹ thuật tái sử dụng một cách có hệ thống; trong đó hệ thống được tích hợp từ nhiều thành phần đang tồn tại hoặc các thành phần thương mại COTS (Commercial- off-the-shelf).
18. Mô hình phát triển lặp lại, tăng thêm
19. Mô hình phát triển lặp lại, tăng thêm  Mô hình này được đề xuất dựa trên ý tưởng thay vì phải xây dựng và chuyển giao hệ thống một lần thì sẽ được chia thành nhiều vòng, tăng dần. Mỗi vòng là một phần kết quả của một chức năng được yêu cầu.  Các yêu cầu của người sử dụng được đánh thứ tự ưu tiên. Yêu cầu nào có thứ tự ưu tiên càng cao thì càng ở trong những vòng phát triển sớm hơn.
20. Mô hình xoắn ốc
21. Mô hình xoắn ốc (tt)  Gồm bốn hoạt động chính:  Lập kế hoạch: xác định mục tiêu, 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á của khách hàng: khẳng định kết quả của kỹ nghệ
22. Mô hình xoắn ốc (tt)  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 góc phần tư 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.
23. Mô hình xoắn ốc (tt)  Mô hình 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 đòi hỏi năng lực quản lý tốt, nếu không 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ò).  Mô hình còn tương đối mới, chưa được sử dụng rộng rãi. Cần có thêm thời gian trước khi người ta có thể xác định được tính hiệu quả với sự chắc chắn hoàn toàn.
24. Các công đoạn chính tổng quát  Giai đoạn đặc tả: xác định các tính năng và điều kiện hoạt động của hệ thống. (thu thập yêu cầu và phân tích)  Giai đoạn phát triển: Thiết kế phần mềm (software design), viết code (code generation)  Giai đoạn đánh giá: kiểm tra phần mềm (software testing), kiểm tra tính hợp lý của phần mềm.  Giai đoạn bảo trì, cải tiến: Sửa lỗi (correction), thay đổi môi trường thực thi (adaptation), tăng cường (enhancement)
25. Đặc tả
26. Phát triển  Thiết kế  Viết code
27. Đánh giá phần mềm  Kiểm tra  Xem xét lại  Kiểm thử hệ thống
28. Bảo trì, cải tiến  Sửa lỗi  Cải tiến
29. Các tiêu chuẩn trong CNPM  The capability Maturity Model (CMM) của Software Engineering Institue (SEI) - Đại học Carnegie Mellon: Chú trọng đến tính hệ thống và khả năng quản trị của các công ty phần mềm hơn là một quy trình (process) cụ thể.  The process Improvement Paradigm (PIP) của Software Engineering Laboratory (SEL) – NASA’s Goddard Space Flight Center: Tương tự như CMM, chú trọng đến tính hệ thống và những hướng dẫn để tăng cường tính năng của các quá trình quản lý.
30. Các tiêu chuẩn trong CNPM  Các chuẩn khác của Department of Defense MIL – STD 2167A ; MIL-STD 1574A ; MIL- STD 882C  The electronic Industries Association (EIA) chuẩn SEB-6-A  The European ESPRIT project  International Standards Organisation - ISO 9001  United Kingdom MOD 0055
31. Chuẩn CMM •Continuous Improvement Optimized •Các hệ thống quality control và qualify đã được sử dụng hiệu quả (Level 5) •Có khả năng dự đoán (Predictability) Managed •Các quy trình quản lý và tiêu chuẩn được chi tiết hóa Risk (Level 4) Defined •Xác lập các tiêu chuẩn quản lý •Các vấn đề documentation đã xác lập (Level 3) Competitiveness Repeatable •Bắt đầu có khả năng quản lý (Level 2) •Quản lý dựa vào kinh nghiệm tương tự Initial •Largely Ad-hoc (Level 1) •Phụ thuộc vào cá nhân
32. III. Nghề nghiệp kỹ sư phần mềm 1. Mục tiêu và những kỹ năng 2. Loại hình công việc
33. Mục tiêu & những kỹ năng Mục tiêu:  Sản xuất ra các sản phẩm phần mềm có chất lượng cao và phù hợp với quy trình phát triển chuẩn mực Những kỹ năng cần có:  Đinh danh, đánh giá, cài đặt, lựa chọn một phương pháp luận thích hợp và các công cụ CASE  Biết lựa chọn ngôn ngữ, phần cứng, phần mềm  Quản lý, lập sơ đồ và kiểm soát việc phát triển tiến trình  Biết cách kiểm tra chương trình sẽ áp dụng  Lựa chọn và sử dụng kỹ thuật bảo trì phần mềm  Đánh giá và quyết định khi nào loại bỏ hay nâng cấp
34. Loại hình công việc Phát triển ứng dụng  Lập trình viên  Kỹ sư phần mềm (phân tích/thiết kế)  Kỹ sư tri thức (KE) Hỗ trợ ứng dụng  Chuyên gia ứng dụng  Nhà quản trị dữ liệu  Nhà quản trị CSDL (DBA)  Kỹ sư trí tuệ nhân tạo  Nhà tư vấn
35. Loại hình công việc Chuyên gia kỹ thuật  Phân tích thông tin  Kỹ sư truyền thông  Chuyên gia mạng  Lập trình viên hệ thống  Chuyên gia hỗ trợ phần mềm (SSP) Chuyên viên  Chuyên viên bảo mật  Kiểm soát viên EDP  Chuyên viên đào tạo và huấn luyện
36. Loại hình công việc  Chuyên viên phát triển các chuẩn  Người viết kỹ thuật  Đảm bảo chất lượng (QA)  Lập kế hoạch công nghệ Những người khác  Hỗ trợ sản phẩm  Tiếp thị sản phẩm  Chuyên viên người dùng cuối