1. Trang chủ
  2. » Giáo án - Bài giảng

TIẾN TRÌNH VÀ MÔ HÌNH TIẾN TRÌNH PHÁT TRIỂN PHẦN MỀM

35 80 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 35
Dung lượng 0,94 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Là một tập các hoạt động có cấu trúc nhằm phát triển và tiến hoá một phần mềm. Các hoạt động chung nhất: Đặc tả: Xác định đầy đủ và chi tiết các chức năng của hệ thống và những ràng buộc khi vận hành hệ thống. Thiết kế và cài đặt: Phần mềm được xây dựng nhằm thỏa mãn đặc tả của nó. Đánh giá: Kiểm định xem phần mềm có đáp ứng được yêu cầu của khách hàng không? Cải tiến: Điều chỉnh phù hợp với những thay đổi về yêu cầu hệ thống.

Trang 1

CHÀO MỪNG CÔ VÀ CÁC BẠN ĐẾN VỚI

BÀI HỌC HÔM NAY

Giảng Viên: Nguyễn Minh Hiền Nhóm SV thực hiện: Nhóm 3

- Nguyễn Quốc Huy

Trang 3

 Thiết kế và cài đặt: Phần mềm được xây dựng

nhằm thỏa mãn đặc tả của nó

 Đánh giá: Kiểm định xem phần mềm có đáp ứng

được yêu cầu của khách hàng không?

 Cải tiến: Điều chỉnh phù hợp với những thay đổi về yêu cầu hệ thống

Trang 4

- Lập kế hoạch: Ước lượng công việc, lập lịch

biểu, phân công công việc

- Phân tích yêu cầu: Xác định yêu cầu chi tiết

(chức năng, ràng buộc), đặc tả yêu cầu

Trang 5

 Phần mềm được xây dựng nhằm thỏa mãn

đặc tả của nó:

- Thiết kế (design): Dịch các yêu cầu thành

bản thiết kế (kiến trúc, giao diện, thành phần,

cấu trúc dữ liệu, thủ tục xử lý, thuật toán,)

- Mã hoá (coding): Chuyển thiết kế thành chương trình máy tính ( trong một ngôn ngữ lập trình)

1.2 Thiết kế và Cài đặt

Trang 6

 Phát hiện và sửa lỗi chương trình (lỗi lập trình, lỗi thiết kế) Hay phần mềm phải được đánh giá

để chắc chắn rằng nó làm những gi mà khách hàng muốn.

1.3 Đánh giá

Trang 7

 Hoàn thiện hệ thống sau khi đưa vào sử dụng

- Sửa lỗi : Sửa lỗi phần mềm.

- Thích nghi : Sửa đổi để thích nghi với môi

trường thay đổi.

- Nâng cao : Thêm các chức năng mới.

1.4 Cải tiến

Trang 9

2 Quy trình Công nghệ Phần mềm

 Phân tích : Mô tả mức phác thảo các thành phần phần mềm

 Thiết kế : Mô tả mức chi tiết các thành phần của phần mềm

 Lập trình : Thực hiện các thành phần của phần mềm

 Kiểm tra : Kiểm chứng các thành phần của phần mềm

Trang 11

MÔ HÌNH THÁC NƯỚC ( WATERFALL MODEL)

1 Khái niệm:

model ) là một mô hình của quy trình phát triển

phần mềm, trong đó quy trình phát triển trông

giống như một dòng chảy, với các pha được thực

hiện theo trật tự nghiêm ngặt và không có sự

quay lui hay nhảy vượt pha.

2 Các pha của mô hình thác nước bao gồm:

- Phân tích và xác định các yêu cầu

- Thiết kế hệ thống và phần mềm

- Cài đặt và kiểm thử đơn vị

- Tích hợp và kiểm thử hệ thống

- Vận hành và bảo trì.

Trang 12

Mô hình thác nước

Trang 13

Định nghĩa yêu cầu:

- Có 2 loại yêu cầu: yêu cầu chức năng và yêu cầu phi chức năng.

- Trong giai đoạn này là giai đoạn sống còn, vì yêu cầu là rất khó biết Vì vậy, việc xác định yêu cầu đúng là rất quan trọng trong suốt quá trình làm phần mềm.

- Mục tiêu của giai đoạn thu thập yêu cầu là xác định phần mềm

sẽ làm được những gì dựa trên các nhu cầu của khách hàng

Thiết kế:

Giai đoạn này chúng ta sẽ thiết kế các thuật toán, và thiết kế mô hình dữ liệu, cho ra một mô hình lớp và dữ liệu ở mức chi tiết.

Mô hình thác nước

Trang 14

Cài đặt và kiểm thử đơn vị:

Sau khi pha thiết kế hoàn tất, lập trình viên sẽ triển khai thực hiện (mã hóa, viết mã) đồ án họ nhận được Sau đó thực hiện hoạt động kiểm thử đơn vị để phát hiện các khiếm khuyết, sửa các khiếm khuyết này và chỉ ra rằng chúng đã được cài đặt theo đúng tài liệu yêu cầu.

Mô hình thác nước

Trang 15

Vận hành và bảo trì:

Đưa phần mềm vào sử dụng trong thực tế và tiến hành các sửa đổi cần thiết nếu người dùng phát hiện ra khiếm khuyết.

3 Ưu điểm

 Có thể dễ dàng phân chia quá trình xây dựng phần mềm thành

những giai đoạn hoàn toàn độc lập nhau.

 Thay đổi yêu cầu được giảm tới độ tối thiểu khi dự án bắt đầu.

 Chuỗi các hoạt động được thực hiện theo quy trình rõ ràng.

 Dễ quản lý, uớc lượng thời gian và chi phí rất chính xác.

 Thấy được trình tự kỹ nghệ từ đầu đến cuối sản phẩm.

Mô hình thác nước

Trang 16

4 Nhược điểm

Hệ thống phải kết thúc ở từng giai đoạn (có khi dài) do đó

nó khó có thể thực hiện đầy đủ các yêu cầu của khách hàng

Mối quan hệ giữa các giai đoạn không được thể hiện

Không thấy được sự tiến hóa của sản phẩm

Rủi ro cao, không thể quay lại

Rất khó khăn trong việc thay đổi các pha đã được thực hiện

Đòi hỏi khách hàng đưa ra yêu cầu chính xác ngay từ đầu

Sai sót phát hiện muộn có thể là hiểm họa

Mô hình thác nước

Trang 17

• Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự

án, 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

Mô hình thác nước

Trang 18

6 Khi nào nên sử dụng Waterfall Model

 Khi các yêu cầu phần mềm được xác định rõ ràng,

đầy đủ và cố định

 Định nghĩa về sản phẩm (hệ thống phần mềm)

không thay đổi

 Các công nghệ liên quan cần thiết được nắm vững

 Các nguồn lực và kinh nghiệm của nhóm phát triển

phần mềm đủ đáp ứng

 Thời gian thực hiện dự án ngắn (không kéo dài)

Mô hình thác nước

Trang 19

Mô hình Bản mẫu

Trang 20

Ưu điểm của mô hình bản mẫu

Người sử dụng được tham gia tích cực vào trong quá

trình phát triền phần mềm

Các lỗi, vấn đề có thể được phát hiện từ sớm

Sớm có được các phản hồi đánh giá từ người sử dụng, giúp có được các giải pháp phát triển phần mềm tốt hơn

Các chức năng còn thiếu có thể được phát hiện sớm

Các chức năng không rõ ràng hoặc khó thao tác có thể được phát hiện

Trang 21

Nhược điểm mô hình bản mẫu

- Khách hàng có thể không nhất quán trong việc diễn đạt các yêu cầu

- Thường được làm nhanh nên thiếu sự phân tích đánh giá cẩn thận

- Nguyên mẫu không giống hoàn toàn hệ thống cuối cùng khách hàng sẽ có các phản ứng khác nhau

Trang 22

Mô hình bản mẫu thường được sử dụng khi

Khi yêu cầu không được biết rõ, khi các yêu cầu không

ổn định, việc thông tin không được đáp ứng tốt

Khi người phát triển không chắc chắn việc dùng giải

thuật hay kiến trúc nào là tối ưu Trên những hệ thống dựa vào kỹ thuật mới mà những yêu cầu khó xác định rõ

Phù hợp với những hệ thống:

 User-interface intensive systems

 Interactive online systems

 First-of-a-kind products

 Decision support systems,…

Trang 23

Trong mô hình xoắn ốc, quy trình phát triển phần mềm được biểu diễn như một vòng xoắn ốc Các pha trong mô hình tiến hoá xoắn ốc bao gồm:

Thiết lập mục tiêu: Xác định mục tiêu cho từng pha của dự án

Đánh giá và giảm thiểu rủi ro: Rủi ro được đánh giá và thực hiện các hành động để giảm thiểu rủi ro

Phát triển và đánh giá: sau khi đánh giá rủi ro, một mô hình xây dựng hệ thống sẽ được lựa chọn từ mô hình chung

Lập kế hoạch: đánh giá dự án và pha tiếp theo của mô hình xoắn ốc sẽ được lập kế hoạch

Mô hình Xoắn ốc

Trang 24

Nhấn mạnh việc đánh giá các rủi ro

kì tương ứng với một sản phẩm của 1 giai đoạn phát triển:

Xác định các mục tiêu, giải pháp, rang buộc

Đánh giá các giải pháp, xác định các nguy cơ và tìm cách giải quyết chúng

Phát triển và kiểm thử của chu kì này

Lập kế hoạch cho chu kì tiếp theo

Mô hình Xoắn ốc

Trang 25

Lập kế hoạch: Xác lập tài nguyên, thời hạn,…cho dự án.

Phân tích rủi ro: Xem xét các mạo hiểm có thể xảy ra

Thiết kế: Phát triển một phiên bản PM

Giao tiếp với khách hàng: Khách hàng đánh giá về phiên bản đã phát triển, làm mịn,sửa đổi các yêu cầu

Xây dựng và xuất xưởng: xây dựng, kiểm thử, cài đặt và cung cấp hỗ trợ người dùng (tư liệu, huấn luyện,…

Đánh giá của khách hàng: Nhân các phản hồi của người

sử dụng về biểu diễn phần mềm trong giai đoạn kỹ nghệ và cài đặt

Trang 26

Mô hình Xoắn ốc Boehm

Trang 27

Ưu điểm

Nhận được phản hồi từ khách hang sớm

Dễ kiểm soát các mạo hiểm ở từng bước tiến hoá

Trang 28

Ứng dụng

 Các hệ thống phần mềm quy mô lớn, các dự án lớn phức tạp có nhiều rủi ro hay sự thành công

của dự án không 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ũ thuhực hiện dự án có khả năng phân tích rủi ro

Mô hình Xoắn ốc

Trang 29

Một số mô hình khác

Mô hình chữ V:

Trang 30

Một số mô hình khác

Mô hình Tiếp cận lặp (Iterative Model):

Example:

Diagram:

Trang 31

Một số mô hình khác

Mô hình Tăng trưởng (Incremental Model):

Example:

Diagram:

Trang 32

Một số mô hình khác

Mô hình RAD ( Rapid Application

Development Model):

Trang 33

Một số mô hình khác

Mô hình Agile ( Agile Model):

Trang 34

Một số mô hình khác

Mô hình Scrum ( Scrum Model):

Ngày đăng: 25/02/2021, 11:02

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w