SE2_Mo Hinh Phat Trien Phan Mem

7/23/2019 SE2_Mo Hinh Phat Trien Phan Mem

http://slidepdf.com/reader/full/se2mo-hinh-phat-trien-phan-mem 1/42

Mô hình phát triển phần mềm(2)

Lê Thị Mỹ Hạnh

Bộ môn Công nghệ phần mềm



Nội dung

8/9/2011

y Khái niệm qui trình phần mềm

1

Các hoạt động phát triển phần mềm2

Các mô hình qui trình phần mềm3

Kết luận4

2



Khái niệm qui trình phần mềm

Qui trình là gì?

Chuỗi các hoạt động

Theo thứ tự nhất định

Sản xuất sản phẩm

Pha của qui trình Chuỗi con các hoạt động liên quan

Mỗi pha định nghĩa:

WHAT: làm gi.

WHO: ai tham gia.

INPUT: đầu vào.

OUTPUT: đầu ra.

8/9/20113

Hoạt động 1

Hoạt động 2

Hoạt động N

…

Sản phẩm

Đầu vào

Đầu ra



Khái niệm qui trình phần mềm

Qui trình phát triển/xây dựng phần mềm (Software

Development/Engineering Process – SEP)

là một tập hợp các hoạt động phải được thực hiện trong quá

trình phát triển và tiến hóa một hệ thống phần mềm.

Gồm 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 phần mềm 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.

8/9/20114



Các hoạt động phát triển phần mềm

Phân tích tính khả thi

Phân tích và đặc tả yêu cầu

Thiết kế phần mềm

Mã hóa và sửa lỗi

Kiểm thử phần mềm

Triển khai và bảo trì

8/9/20115




Phân tích tính khả thi

Xác định những vấn đề cần giải quyết,

Xem xét các giải pháp và kỹ thuật khác nhau

Thuận lợi

Bất lợi

Đánh giá về thời gian, giá thành, nguồn tài nguyên cần thiết

Sản phẩm: tài liệu phát triển

8/9/20116




Phân tích và đặc tả yêu cầu

Tìm hiểu xem phải phát triển cái gì (WHAT), không phải là

phát triển như thế nào(HOW).

Là hoạt động phối hợp giữa khách hàng và người phân tích

(bên phát triển).

Giúp cho đảm bảo chất lượng của phần mềm (phần mềm

đáng tin cậy). Khó khăn

Khách hàng không biết cái họ cần

Khách hàng không biết bày tỏ cái mình muốn

Các thay đổi

Sản phẩm: tài liệu đặc tả yêu cầu

8/9/20117




Phân tích và đặc tả yêu cầu – các bước thực hiện

8/9/20118

Phân tích bài tóanThu thập yêu cầu

Nghiên cứu khả thi Phân tíchyêu cầu

Xác định

yêu cầu Đặc tảyêu cầu

Báo cáokhả thi Tài liệu mô

tả hệ thống

Tài liệu địnhnghĩa yêu cầu

Tài liệu đặctả yêu cầuThẩm định

Tài liệu yêu cầu




Phân tích và đặc tả yêu cầu – các bước thực hiện

8/9/20119

Thẩm định

Đặc tả yêu cầu

Xác định yêu cầu

Phân tích yêu cầu

Nghiên cứu khả thiXác định những vấn đề cần giải quyết, xem xét các giải pháp vàkỹ thuật khác nhau (Thuận lợi, Bất lợi).Đánh giá về thời gian, giáthành, nguồn tài nguyên cần thiết

Miền thông tin của vấn đề phải được biểu diễn lại và hiểu rõ.

Các mô hình mô tả cho thông tin, chức năng và hành vi hệ thốngcần phải được xâydựng.

mô tả trừu tượng về các dịch vụ hệ thống cần cung cấp và các ràng buộchệ thống cần tuân thủ khi vận hành.chỉ mô tả các hành vi bên ngoài của hệ thống,không liên quan tới các chitiết thiết kế

mô tả hướng khách hàng và được viết bởi ngôn ngữ của kháchhàng.

có thể dùng ngôn ngữ tự nhiên và các khái niệm trừu tượngXem có thỏa mãn các nhu cầu của khách hàng chưa.các sai sót có thể lan truyền sang các giai đoạn thiết kế và mã hóakhiến cho việc sửa đổi hệ thống trở nên rất tốnkém




Thiết kế phần mềm Chuyển từ tài liệu các yêu cầu thành cấu trúc logic

có thể cài đặt được Giải pháp cho vấn đề đã được đặc tả Gồm các hoạt động

Thiết kế kiến trúc Các mô-đun giao diện các mô đun

Thiết kế giao diện

Thiết kế các mô-đun Cấu trúc dữ liêu Thuật tóan

Sản phẩm: tài liệu thiết kế

8/9/201110

Thiết kế

Mô hình dữ liệu

Mô hình chức năng

Các yêu cầu khác

Lập trình

Thiết kế kiến trúc

Cấu trúcdữ liệu

Thiết kế thuật tóanModule chương

trình





8/9/201111





Các phương pháp thiết kế

Thiết kế hướng chức năng

Thiết kế hướng đối tượng

8/9/201112




Mã hóa và gỡ rối 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 (coding standards) Lập trình theo cặp (pair programming) Công cụ Quản l{ phiên bản

Gỡ rối Tìm và sửa các lỗi trong quá trình lập trình

Sản phẩm: chương trình

8/9/201113




Kiểm thử phần mềm

Phát hiện lỗi trong chương trình

Lập kế hoạch thực hiện kiểm thử

Tạo các trường hợp kiểm thử

Tiêu chuẩn kiểm thử

Nguồn tài nguyên kiểm thử

Mã nguồn được kiểm thử theo tài liệu thiết kế

Sản phẩm: báo cáo kiểm thử

8/9/201114




Kiểm thử phần mềm các hoạt động kiểm thử

Kiểm thử đơn vị

Kiểm thử tích hợp

Kiểm thử hệ thống

Kiểm thử chấp nhận Các phương pháp kiểm thử

Kiểm thử tĩnh

Kiểm thử động Kiểm thử hộp trắng

Kiểm thử hộp đen

8/9/201115




Bảo trì

Bảo đảm các chương trình vận hành tốt

Cài đặt các thay đổi

Cài đặt các yêu cầu mới Xử l{ lỗi khi vận hành

Sản phẩm: chương trình

8/9/201116



Các mô hình qui trình phát triển phân mềm

8/9/201117

Mô hình qui trình phần mềm

Là một thể hiện trừu tượng của quy trình phần mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể

Có nhiều mô hình qui trình phần mềm

Mô hình Code - and - Fix

Mô hình thác nước (Waterfall Model) Mô hình chữ V (V-Shaped Model)

Mô hình bản mẫu (Prototyping Model)

Mô hình RAD (RAD – Rapid Application Development)

Mô hình tiến hóa (Evolutionary Model)

Mô hình lặp và tăng thêm (Iteration & Incremental Model)

Mô hình xoắn ốc (Spiral Model)

...



Các mô hình qui trình phần mềm

8/9/201118

Mô hình “Code and Fix”

u Việc lập trình trong những năm 1940 đến 1950

u Các dự án nhỏ, không có áp lực về tiến độ

u không có một chiến lược có chủ {

u Hoạt động phát triển chỉ gồm hai bước:

Viết mã

Sữa lỗi

Có thể được sử dụng với các hệ thống không có các yêu cầu vềbảo trì




8/9/201119

Mô hình thác nước (Waterfall Model)

Winston Royce đề xuất, 1970.

Thay thế cho “code – and – fix”

Đặc trưng

Qui trình phát triển được chia thành các giai đoạn nối tiếp nhau

Các hoạt động diễn ra tuần tự và độc lập

Tách rời quá trình đặc tả và mã hóa

Chú trọng kiểm thử sau khi hiện thực




8/9/201120





8/9/201121


Ưu điểm

Thực hiện một cách có hệ thống và bài bản => Dễ quản lí.

Thời gian hoàn thành dự án thường được dự báo với độ chính xác cao

Các tài liệu đầu ra của từng giai đoạn được xây dựng đầy đủ và có hệ thống

Nhược điểm Thực tế các dự án ít khi tuân theo dòng tuần tự của mô hình, mà thường có lặp lại

Mô hình đòi hòi một bản yêu cầu (requirement) đầy đủ và chính xác từ phía khách

hàng

Khách hàng cần phải kiên nhẫn. Sản phẩm sẽ chỉ được bàn giao khi tất cả các công

việc liên quan đã được hoàn thành Ứng dụng

Khi đội dự án đã có kinh nghiệm,

Yêu cầu từ khách hàng được xác định rõ ngay từ đầu và ít có khả năng thay đổi.




8/9/201122

Mô hình chữ V (V-Shaped Model)

Toàn bộ qui trình được chia thành hai nhóm giai đoạn : Phát triển và kiểm thử

Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng




8/9/201123

Mô hình chữ V (V-Shaped Model)

Ư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 kz phát triển, không phải đợiđến lúc kết thúc giai đoạn hiện thực.

Nhược điểm

Giống mô hình waterfall

Ứng dụng Giống mô hình waterfall.




8/9/201124

Mô hình bản mẫu (Prototyping Model)

Xây dựng một bản mẫu ban đầu để người sử dụng xem xét

Bản mẫu ban đầu: Bị loại bỏ Được phát triển




8/9/201125

Mô hình nguyên mẫu (Prototyping Model)

Ưu điểm

Khách hàng tương tác sớm với hệ thống

Khách hàng cùng làm việc với người phát triển hệ thống

Thiết kế và phát triển mềm dẽo Nhược điểm

Chất lượng thấp và khó bảo trì

Bị khách hàng hối thúc

Người phát triển sẽ bị rơi vào giai đoạn code – and fix

Ứng dụng

Yêu cầu chưa được biết rõ; yêu cầu không ổn định




8/9/201126


Cải tiến “Code-and-Fix”. Một dạng của mô hình bản mẫu. Phát triển phần mềm qua nhiều phiên bản

Mỗi phiên bản được đưa ra lấy { kiến khách hàng

Cải tiến dần cho đến khi đạt được phiên bản hoàn chỉnh.

Các phiên bản 1, 2, 3 có thể rất khác nhau!

Chú trọng việc tái sử dụng

Hai kiểu mô hình tiến hóa cơ bản

Khám phá và phát triển (exploratory development)

Làm bản mẫu để “vứt đi” (throwaway prototyping)

Ứng dụng Hệ thống tương tác vừa và nhỏ (dưới 500 000 dòng code)

phần GUI của những hệ thống lớn;

những hệ thống cần chu kz phát triển ngắn.




8/9/201127





8/9/201128


Ưu điểm

Khách hàng tham gia sâu hơn vào quá trình phát triển => sản phẩm

cuối cùng thường phản ánh chính xác mong muốn của khách hàng.

Thích ứng tốt với thay đổi

Nhược điểm

Thiếu cái nhìn toàn diện, phần mềm thường không được thiết kế tốt

Việc phát triển qua nhiều phiên bản có thể phá vỡ kiến trúc tổng thể của

phần mềm.

Các tài liệu mô tả cho từng phiên bản thường không được lập đầy đủ.




8/9/201129

Mô hình tăng dần(Incremental Model)

Kết hợp những ưu điểm của mô hình thác nước và mô

hình tiến hóa

Ý tưởng của mô hình là phân chia phần mềm thành những

phần tăng trưởng và phát triển Bàn giao chúng lần lượt cho khách hàng theo mức độ quan trọng.

Phần tăng trưởng nào đến lượt được phát triển thì những yêu cầu

tương ứng sẽ được phân tích.

Chỉ những thay đổi từ phía khách hàng cho những phần chưa

được phát triển mới được chấp nhận




8/9/201130


Chuyển giao bản tăng 4

System/info.Engineering

Calendar time

Ph©n tÝch ThiÕt kÕ LËp tr×nh KiÓm thö



Bản tăng 1

Bản tăng 2

Bản tăng 3

Bản tăng4








8/9/201131


Ưu điểm:

Chức năng chính, chức năng có độ rủi ro cao sẽ được thực hiện trước

Sau mỗi vòng đều có thể chuyển giao cho khách hàng

Giảm rủi ro cho thất bại toàn dự án

Nhược điểm:

Phải xác định chức năng đầy đủ và hoàn chỉnh trước khi qua vòng sau không phải dự án nào cũng có thể được phân chia thành các phần tăng

trưởng nhỏ có thể được phát triển và bàn giao tuần tự.

Khách hàng khi thấy vòng đầu thường nghĩ hệ thống đơn giản

Ứng dụng

Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khaisớm một số chức năng cơ bản của hệ thống.

Khi các yêu cầu đã hiểu rõ nhưng mong muốn có sự tiến hóa dần của sảnphẩm

Độ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.




8/9/201132

Mô hình lặp(Iteration Model)

Phát triển qua nhiều vòng lặp

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.

Cũng dựa trên tinh thần của mô hình tiến hóa




8/9/201133

Mô hình lặp(Iteration Model)

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 (Iterative): thay đổi sản phẩm.

Ứ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ềukinh 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




8/9/201134


Được phát triển bởi IBM năm 1980 qua sách của James Matin

Chu kz phát triển: 60-90 ngày. Vòng đời phát triển cực ngắn.

Thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần

thích hợp và ứng dụng tạo mã tự động

Gồm các giai đoạn

Mô hình hóa nghiệp vụ.

Mô hình hóa dữ liệu.

Mô hình hóa xử l{ Sinh ứng dụng

Kiểm thử và chuyển giao.




8/9/201135





8/9/201136


Ư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ử.

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.

Đối với dự án qui mô lớn, RAD yêu cầu đủ nguồn lực con người để tạo số nhóm RADthích hợp

Ứ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, Hệ thống cóthể dễ dàng phần chia thành nhiều module

Có sự hỗ trợ của công cụ hay sử dụng ngôn ngữ cấp cao, Có thể sử dụng lại nhữngthành phần đã có

Hệ thống nhỏ, không yêu cầu khắt khe về hiệu suất.




8/9/201137





8/9/201138


Được đề nghị bởi Berry Boehm, 1988 Đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết

Qui trình được chia thành các vòng xoáy ốc

Mỗi vòng là một pha của qui trình

Mỗi pha gồm 4 hoạt động

Xác định mục tiêu chất lượng cho sản phẩm được thực hiện, đồng thờixác định sự lựa chọn mua, tái sử dụng hay tự thiết kế và hiện thực cácthà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. Việc này được thựchiệ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ả địnhhướ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ậpkế hoạch cho chu kz lặp tiếp theo




8/9/201139

Mô hình xoắn ốc (Spiral Model) Ưu điểm:

Phân tích đánh giá rủi ro sớm => tăng độ tin cậy của dự án Cho phép thay đổi tùy theo điều kiện thực tế của dự án tại mỗi vòng

xoáy ốc Kết hợp các ưu điểm của mô hình thác nước và tiến hóa

Nhược điểm Cần có kỹ năng tốt về phân tích rủi ro

Đánh giá rũi ro tốn nhiều chi phí Phức tạp, khó quản l{, khó thuyết phục khách hàng

Ứng dụng

Những dự án có độ rũi ro cao, dự án cần nhiều thời gian Những dự án đòi hỏi nhiều tính toán, xử l{ như hệ hỗ trợ quyết định

Đội ngũ thực hiện có khả năng phân tích rủi ro



Kết luận

8/9/201140

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.

Không phải tất cả các mô hình đều thích hợp cho mọi ứng

dụng.

Việc lựa chọn, tùy biến các mô hình cho phù hợp với các

dự án không dễ

Việc vận hành các mô hình vào trong quá trình phát triển

sản phẩm càng khó hơn. Có thể và cũng nên tổ hợp các mô hình để đạt được thế

mạnh của từng mô hình cho một dự án riêng lẻ



Kết luận

8/9/201141

Qui trình là một trong những yếu tố cực kz quan trọng đem lại sự thành

công cho các nhà sản xuất phần mềm giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay

ngoài công ty đều có thể xử l{ đồng bộ công việc tương ứng vị trí của mình

thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án.

Qui trình phát triển/xây dựng phần mềm (Software

Development/Engineering Process - SEP) có tính chất quyết định để tạo ra

sản phẩm chất luợng tốt với chi phí thấp và năng suất cao

điều này có { nghĩa quan trọng đối với các công ty sản xuất hay gia công phần

mềm củng cố và phát triển cùng với nền công nghiệp phần mềm đầy cạnh tranh.

Cần lựa chọn mô hình qui trình phát triển phù hợp tùy theo cấp tổ chức

hay mức độ dự án



KẾT THÚC

Câu hỏi?????

Documents

SE2_Mo Hinh Phat Trien Phan Mem