Kỹ nghệ phần mềm 03 potx

Nguy nV nVMô hình thác nước: đặc điểm Tách biệt giữa các pha, tiến hμnh tuần tự Chậm có phiên bản thực hiện được Đặc tả kỹ, phân công chuyên trách, hướng tμi liệu ơ Có sớm vμ được sử dụn

K ngh ph n m m

Software Engeneering

Nguy nV nV

N i dung

̈ Tiến trình vμ mô hình tiến trình

̈ Các giai đoạn của tiến trình

̈ Tiến trình vμ vấn đề liên quan

Bài 3: Ti n trỡnh ph n m m

Nguy nV nV

TÀI Li U THAM KH O

1. Nguy n V n V , Nguy n Vi t Hà Giáo trình k ngh ph n

m m Nhà xu t b n i h c Qu c gia Hà n i, 2008

2. Grady Booch, James Rumbaugh, Ivar Jacobson The Unified

Modeling language User Guid Addison-Wesley, 1998.

3. M Ould Managing Software Quality and Business Risk, John

Wiley and Sons, 1999.

4. Roger S.Pressman, Software Engineering, a Practitioner’s

Approach Fifth Edition, McGraw Hill, 2001.

5. Ian Sommerville, Software Engineering Sixth Edition,

5 lo¹i m« h×nh tiÕn tr×nh phÇn mÒm tiªu biÓu:

Mçi lo¹i bao gåm mét sè c¸c m« h×nh tiÕn tr×nh.

Nguy nV nV

Mô hình vòng đời truyền thống

phân tích yêu cầu& đặc tả

thiết kế HT &

phẩn mềm

Mã hoá &kiểm thử đơn vị

kiểm thử tích hợp & HT

Vận hμnh Ngiên cứu

lập KHDA

Nguy nV nV

Mô hình thác nước: đặc điểm

Tách biệt giữa các pha, tiến hμnh tuần tự

Chậm có phiên bản thực hiện được

Đặc tả kỹ, phân công chuyên trách, hướng tμi liệu

ơ Có sớm vμ được sử dụng rộng rãi (tốt > tự nhiên)

ơ Thích hợp khi yêu cầu hiểu tốt, hệ lớn & phức tạp

ơ Bảo trì thuận lợi

Phát triển

Mô hình phát triển tiến hóa

b1 L−ợc đồ chung nhất

Nguy nV nV

Lược đồ chung nhất

Phát triển ban đầu

đầu với hiểu biết có thể chưa đầy đủ)

Thực hiện phát triển bằng cách lμm mẫu

thể còn sơ sμi

Thẩm định phiên bản có được, lặp lại các bước cho đến khi có phiên bản cuối cùng

Nguy nV nV

Lược đồ chung

̈ Hạn chế

º Không trực quan

º Hệ thống thường có cấu trúc nghèo nμn

º Đòi hỏi có kỹ năng đặc tả (ngôn ngữ lμm mẫu)

̈ Khả năng ứng dụng

º Cho các hệ tương tác vừa, nhỏ

º Cho những phần của hệ lớn

Nguy nV nV

sản phẩm cuối cùng

lμm mịn bản mẫu

xây dựng bản mẫu

thiết kế nhanh

đánh giá

của khách

xác yêu thu thập tt

̇ các yêu cầu chưa rõ rμng

̇ input/output chưa rõ rμng

̇ khó đánh giá tính hiệu quả thuật toán

̇ tính cấu trúc không cao

̇ khách hμng ít tin tưởng

Mô hình lμm bản mẫu

Nguy nV nV

̈ Cải tiến của mô hình tuần tự vμ lμm mẫu

̈ Thêm phân tích rủi ro

̈ Lμ quá trình lặp hướng mở rộng, hoμn thiện dần

º Lập kế hoạch: xác lập vấn đề, tμi nguyên, thời hạn.

º Phân tích rủi ro: xem xét mạo hiểm, tìm giải pháp

º Kỹ nghệ: phát triển một phiên bản của phần mềm

(chọn mô hình thích hợp: lμm mẫu, thác nước, )

b¶n mÉu / ¸p dông p.ph¸p ph¸t triÓn thÝch hîp

tiÕp tuc hay kh«ng?

ph©n tÝch rñi ro, l©y ý kiÕn

kh¸ch hμng

Nguy nV nV

Mô hình xoắn ốc: đặc điểm

̈ Hợp với hệ lớn có thể phân chia phần cốt lõi ồ

thứ yếu

̈ Có thể kiểm soát rủi ro ở từng mức tiến hóa

̈ Khó thuyết phục khách lμ kiểm soát được sự tiến

hóa linh hoạt (đòi hỏi năng lực quản lý, năng lực

phân tích rủi ro -> chi phi chuyên gia lớn)

̈ Chưa được dùng rộng rãi như mô hình thác nước

hoặc lμm mẫu

Nguy nV nV

Mô hình phát triển ứng dụng nhanh

Rapid Application Development- RAD

đội 2

Tạo sinh ứng dụng

Mô hình dữ liệu

Kiểm thử chuyển giao

Mô hình nghiệp vụ

Mô hình dữ liệu

Kiểm thử chuyển giao

Mô hình nghiệp vụ

Mô hình

xử lý

đội 3

Tạo sinh ứng dụng

Mô

hình dữ

liệu

Kiểm thử chuyển giao

Mô hình nghiệp vụ

Mô

hình xử lý

Nguy nV nV

Ph©n tÝch ThiÕt kÕ ho¸ M∙ KiÓm thö

System/information engineering

Ph©n tÝch ThiÕt kÕ ho¸ M∙ KiÓm thö B¶n t¨ng 2

ChuyÒn giao b¶n t¨ng 4

Thêi gian

B¶n t¨ng 3 B¶n t¨ng 1

B¶n t¨ng 4

ChuyÒn giao b¶n t¨ng 1

ChuyÒn giao b¶n t¨ng 2

ChuyÒn giao b¶n t¨ng 3

Ph©n tÝch ThiÕt kÕ ho¸ M∙ KiÓm thö

Ph©n tÝch ThiÕt kÕ ho¸ M∙ KiÓm thö

Nguy nV nV

M« h×nh t¨ng tr−ëng

̈ ChuyÓn giao dÇn tõng phÇn cña hÖ thèng

chøc n¨ng

̈ Cho s¶n phÈm dïng trong thêi gian ng¾n

Nguy nV nV

Lập trình cực đoan (Extreme Programming-XP)

̈ Cách tiếp cận dựa trên việc phát triển, chuyển

giao dần từng phần nhỏ chức năng

̈ Tạo các ca thử nghiệm trước khi lập trình

bắt tay vμo mã hóa

̈ Lập trình đội

̈ Viết lại khi có thể

Nguy nV nV

4GT: đặc điểm

̈ Phân tích/thiết kế vẫn lμ bước quan trọng

̈ 4GT chỉ trợ giúp (tự động hóa) việc sinh mã

chương trình đối với từng chức năng cụ thể

̈ ứ ng dụng còn hạn chế; không phải mọi

4GTcũng dễ dùng

̈ Tíết kiệm công sức cho phát triển phần mềm nhỏ

̈ Không hiệu quả với phần mềm lớn: mã hóa chỉ

chiếm một tỷ lệ nhỏ so với phân tích thiết kế

Nguy nV nV

Ph¸t triÓn hÖ thèng h×nh thøc hãa

formal systems development

C¸c b−íc cña tiÕn tr×nh ph¸t triÓn

B¸n t đ ng t đ ng

§Æc t¶

h×nh thøc

Nguy nV nV

H¹n chÕ ph¸t triÓn h×nh thøc hãa

̈ H¹n chÕ

h¹n nh− giao diÖn

̈ Kh¶ n¨ng øng dông

toμn, b¶o mËt tr−íc khi ®−a vμo sö dông, xö lý

Nguy nV nV

Ph¸t triÓn h−íng sö dông l¹i

̈ H−íng sö dông l¹i dùa trªn n n t¶ng cña

Nguy nV nV

Phát triển hướng đối tượng

̈ bao gói, che dấu thông tin:

tác động cục bộ, dễ bảo trì, dễ dùng lại

Do bao gói cả dữ liệu vμ xử lý nên độc lập tương đối, cho một chức năng xác định, che thông tin với bên ngoμi

̈ tính kế thừa:

º xây dựng được các lớp cơ sở (chung)

º khi thêm các chi tiết dùng cho trường hợp cụ thể

nâng cao khả năng dùng lại

Nguy nV nV

C¸c h−íng sö dông l¹i

̈ C¸c h−íng sö dông l¹i:

̈ C¸c giai ®o¹n cña tiÕn tr×nh

º Ph©n tÝch hÖ thèng thμnh c¸c phÇn yªu cÇu nhá

º C¶i biªn c¸c yªu cÇu h−íng (thμnh phÇn, mÉu, khung)

º ThiÕt kÕ hÖ thèng h−íng tíi tμi s¶n sö dông l¹i

º Ph¸t triÓn vμ tÝch hîp

̈ Quan träng, cÇn kinh nghiÖm, c«ng cô cßn h¹n chÕ

thẩm định

phân tích thành phần thíết kế HT dùng lại

Tham chiếu

Khung lμm việc

Th− viện thμnh phần

Th− viện thμnh phần Th− viện Th− viện mẫumẫu

Nguy nV nV

Phân tích thiết kế hướng mẫu

pattern oriented analysis & design - POAD

Nội dung

º Phân tích yêu cầu hướng theo mẫu

º Xem xét các mẫu đã có (từ thư viện)

º Tìm, lựa chon mẫu thích hợp cho phần được phân tích

º Chuyển thiết kế thμnh chương trình (tự động, bán tự động)

Ưu, nhược

AbstractFigure Draw()

Figures() Include() Decompose() Add()

Remove()

AttributeFigure Draw()

Draw() Figures() Include() Decompose() Add()

Remove() CompositeFigure

PertFigure

Nguy nV nV

Phát triển khung lμm việc

Framework development

Xây d−ng khung làm việc

º Xác định lớp bμi toán cần giải quyết

º Xây dựng khung bμi toán (dựa trên patterns)

º Lμm sẵn các tiêu bản mẫu (dùng ngay đ−ợc)

Triển khai

ơ Phân tích bμi toán theo khung

ơ Xác định tiêu bản thích hợp

ơ Lắp ghép hay tìm phần thay thế

Nguy nV nV

Phát triển phần mềm mã nguồn mở

̈ Công khai thiết kế, công khai mã nguồn,

dùng chung

̈ Phát triển phân tán, nhiều người tham gia

̈ Xuất phát từ các mối quan tâm chung

̈ Nhiều vấn đề được giải quyết

• Lý do, lợi ích, động lực chưa rõ

̈ Ví dụ: GNU, Linux

Nguy nV nV

Lựa chọn mô hình

̈ Phụ thuộc vμo bμi toán, vμo môi trường cụ thể

̈ Yêu cầu rõ rμng: Mô hình thác nước thích hợp

̈ Hệ phức tạp, điều khiển: Hướng sử dụng lại

̈ Khác:

º Yêu cầu chưa rõ rμng, độ phức tạp cao

º Yêu cầu có khả năng thay đổi

º Không chắc chắn về tính hiệu quả, tính khả thi

Nguy nV nV

̈ Lμ qu¸ tr×nh thiÕt lËp c¸c chøc n¨ng, dÞch vô mμ

hÖ thèng cÇn cã vμ c¸c rμng buéc lªn sù ph¸t triÓn vμ vËn hμnh hÖ thèng

̈ TiÕn tr×nh kü nghÖ yªu cÇu bao gåm:

º Nghiªn cøu kh¶ thi

Nguy nV nV

Tiến trình kỹ nghệ yêu cầu

Báo cáo khả thi

Mô hình hệ thống

Yêu cầu ngươi dùng, hệ thống

Nghiên cứu

khả thi

Xác đinh, phân tích yêu cầu

đặc tả

yêu cầu

Thẩm định yêu cầu

Nguy nV nV

Thiết kế phần mềm

̈ Chuyển yêu cầu thμnh đặc tả thμnh hệ thống như

nó tồn tại trong thế giới thực với các giải pháp công nghệ thích hợp để người lập trình có thể chuyển

thμnh chương trình vận hμnh trên máy

̈ Chiến lược thiết kế phù hợp với phân tích

̈ Lμ quá trình lặp: có thể quay lại hoμn thiện phân

tíchồ rồi lại thiết kế

̈ Hai giai đoạn thiết kế: logicồthiết kế vật lý

º Mô hình Thực thể – mối quan hê/ MH Quan hệ (dữ liệu)

º Mô hình cấu trúc mô đun (cấu trúc)

º Các mô hình lớp đối t −ợng (kiến trúc, thực thi)

Nguy nV nV

Lập trình vμ gỡ rối

̈ Lμ chuyển thiết kế thμnh chương trình, bắt lỗi vμ sửa lỗi

̈ Lμ một hoạt động cá nhân không có một tiến trình

chung cho mọi người

̈ Người lập trình phải tiến hμnh kiểm thử để gỡ lỗi chương

trình Gỡ lỗi lμ hoạt động của lập trình

̈ Lập trình đòi hỏi chọn ngôn ngữ thích hợp vμ có kinh

nghiệm phong cách lập trình tốt

̈ Để đảm bảo độ tin cây, cần biết lập trình tránh lỗi, thứ

Nguy nV nV

Thẩm định phần mềm

̈ Thẩm định vμ xác minh nhằm đảm bảo hệ thống phù

hợp với đặc tả vμ đáp ứng yêu cầu người dùng

̈ Nội dung bao gồm việc thanh tra, xét duyệt vμ kiểm thử

hệ thống Kiểm thử lμ quan trọng nhất

̈ Có nhiều mức:

• Xác minh: kiểm thử đợn vị, tích hợp, hệ thống

• Thẩm định: lμm mẫu yêu cầu, kiểm thử chấp nhận

̈ Có nhiều phương pháp kiểm thử Mỗi phương pháp áp

dụng ở mức xác định, vμ sử dụng kỹ thuật nhất định

̈ Mục tiêu kiểm thử lμ tìm ra lỗi với chi phí ít nhất có thể

Nguy nV nV

Tiến hoá phần mềm

̈ Phần mềm phải mềm dẻo vì nó cần phải thay đổi.

̈ Môi trường nghiệp vụ vμ kỹ thuật luôn thay đổi:

Phần mềm cần thay đổi để phù hợp với chúng ồ

tiến hóa lμ tất yếu

̈ Phân định phát triển vμ tiến hoá lμ tương đối: giữa

chúng có quan hệ chặt chẽ với nhau Phát triển lμ lμm mới, tiến hóa trên cơ sở hệ đã có.

Nguy nV nV

Tiến trình tiến hoá

Hệ thống mới

Xác định yêu cầu hệ thống

Hệ thống hiện tại

đánh giá hệ thống hiện tại đổi hệ thống đề xuất thay Cải biên hệ thống

Nguy nV nV

Trợ giúp tự động hoá phát triển

̈ Computer-aided software engineering:CASE lμ các

phần mềm trợ giúp phát triển vμ tiến hoá hệ thống

̈ Các công cụ thường gặp:

º Bộ soạn thảo đồ thị: để phát triển mô hình hệ thống

º Từ điển dữ liệu: để quản lý các thực thể thiết kế

º Bộ xây dựng giao diện: để thiết kế giao diện

º Bộ gỡ rối: trợ giúp tìm lỗi trong chương trình

º Bộ chuyển đổi tự động: tạo sinh các phiên bản mới từ

thiết kế / hay chương trình

Nguy nV nV

̈ CASE góp phần đáng kể hoμn thiện tiến trình phần

mềm cả về trình tự, tiến độ vμ chất l−ợng: tự động hóa một phần hoạt động mô hình hóa vμ quản lý

Nguy nV nV

Công nghệ CASSE

Các công cụ đơn

bộ sửa lỗi

Môi trường tiến trình

Bàn thợ

Lập trình gỡ

lỗi

Phân tích vμ thiết kế

Bộ soạn

thảo

Môi trường

Môi trường tích hợp

Kiểm thử các

loại

Bμn thợ đơn phương pháp

Ch.trình dịch

Bμn thợ đa phương pháp

Bμn thợ ngôn ngữ cụ thể

Công nghệ CASE

Bμn thợ mục tiêu chung

Nguy nV nV

Phân loại CASE

̈ Phân loại CASE giúp hiểu vμ sử dụng chúng trong

phát triển

̈ Có thể phân loại CASE theo:

º Hướng chức năng: Công cụ cho các chức năng cụ

thể: soạn thảo, lập kế hoạch, lμm mẫu,

º Hướng tiến trình: Công cụ cho hoạt động của tiến

trình được trợ giúp: mô hình nghiệp vụ, E-R

º Hướng tích hợp: Công cụ trợ giúp tổ chức việc tích

Nguy nV nV

CASE tích hợp

̈ Các công cụ đơn (Tools) : trợ giúp những

nhiệm vụ riêng rẽ của tiến trình: kiếm tra sự nhất quán, soạn thảo, tạo mô hình

̈ Bàn thợ (Workbenches): trợ giúp 1 pha của

tiến trình phát triển, như đặc tả, thiết kê,

̈ Môi trường phát triển (Environments): trợ

giúp toμn bộ hay một phần của toμn tiến trình phần mềm (có thể bao gồm một số bμn thợ)

Nguy nV nV

Các vấn đề liên quan

̈ 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 phát triển

̈ Khi chuyển tiếp giữa các pha phát triển phải thẩm

định tốt để đảm bảo lỗi không ảnh hưởng đến pha sau

̈ Tμi liệu tạo ra ở mỗi pha không chỉ dùng cho pha kế

tiếp mμ còn dùng để đảm bảo chất lượng của phần mềm vμ bảo trì

Nguy nV nV

Tính khả thi của tiến trình phát triển

Phần tử logic, khó kiểm soát

º tạo ra các tμi liệu

º xét duyệt tμi liệu mỗi bước

nghiên cứu khả thi; đặc tả yêu cầu;

đặc tả thiết kế

Ví dụ tμi liệu:

So sánh: º vòng đời cổ điển khả thi cao

º lμm bản mẫu kém

º 4GT ??

Nguy nV nV

Vấn đề:

̈ Tạo ra chi phí phụ của phát triển

( người lập trình không thích viết tμi liệu)

̈ Sử dụng các giải pháp cục bộ để tránh sửa

đổi tμi liệu

̈ Sử dụng các mẫu có sẵn

̈ Sử dụng CASE trợ giúp lμm tμi liệu theo

Lμm tμi liệu phần mềm

Nguy nV nV

S¶n phÈm (tμi liÖu) cña dù ¸n

M· m¸y, d÷ liÖu, tμi liÖuM· nguån, chó thÝch

Nguy nV nV

Quan hệ tiến trình vμ sản phẩm

Tiến trình vμ sản phẩm lμ hai mặt của phát triển:

̈ Tiến trình tốt đảm bảo rμng buộc về sản phẩm

̈ Sản phẩm tốt lμ sự tổng hoμ của nhiều yếu tố:

º Tiến trình thích hợp

º Đội ngũ chuyên môn tốt

º Công cụ trợ giúp mạnh

º Năng lực quản lý tiến trinh của tổ chức cao (CMM)

5 mức CMM (Capability Maturity Model):

1 Tùy biến 3 Đ−ợc xác định

2 Lặp lại đ−ợc 4 Đ−ợc quản lý 5 Tối −u hóa

Nguy nV nV

Câu hỏi ôn tập

1 Có mấy loại mô hình tiến trình? Lμ loại nμo?

2 Trình bμy nội dung của các mô hình: thác nước, lμm mẫu,

xoáy ốc, tiến hoá, tăng trưởng, ứng dụng nhanh, hình thức hoá, đối tượng, mô hình sử dụng lại, mô hình mã nguồn mở, mô hình thế hệ thứ 4 theo các nội dung sau:

̇ Nội dung? đặc trưng?

̇ ưu, nhược điểm?

̇ cần yêu cầu gì?

Nguy nV nV

Câu hỏi ôn tập (t)

5 Định nghĩa thẩm định phần mềm? Thẩm định vμ xác minh

gồm những hoạt động gì?

6 Có những loại kiểm thử nμo? Mô tả tiến trình kiểm thử?

7 Tiến hoá phần mềm lμ gì? Lý do?

8 Mô tả tiến trình tiến hoá hệ thống?

9 CASE lμ gì? Các cách phân loại CASE?

10 CASE tích hợp gồm những loại nμo? vẽ sơ đồ cấu trúc các

loại CASE?

11 Lμm thế nμo để đảm bảo khả thi của mô hình phát triển? So

sánh sự khả thi giữa các mô hình, giải thích vì sao?

12 Lμm thế nμo để có thể giảm kích cỡ, chi phí của mô hình?

Những mô hình nμo, ngôn ngữ nμo có −u thế về mặt nμy?

Nguy nV nV

C©u hái và th o lu n