chuong 2. cnpm

1

CHƯƠNG 2. CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM

Bộ môn Công nghệ thông tinTrường Đại học Thương mại

2

Nội dung2.1. Vòng đời phát triển phần mềm2.2. Các hoạt động phát triển phần mềm2.3. Các mô hình phát triển phần mềm

2.3.1. Mô hình thác nước (Water Fall Model)2.3.2. Mô hình V2.3.3. Mô hình bản mẫu2.3.4. Mô hình phát triển ứng dụng nhanh2.3.5. Các mô hình tiến hóa

2.3.5.1. Mô hình gia tăng2.3.5.2. Mô hình xoắn ốc2.3.5.3. Mô hình xoắn ốc WINWIN

2.3.6. Mô hình phát triển đồng thời2.3.7. Mô hình hướng thành phần2.3.7. Mô hình hướng sử dụng lại2.3.8. Mô hình hợp nhất

2.4. Một số lưu ý

3

2.1. Vòng đời phát triển PM

Là khoảng thời gian tính từ khi phần mềmđược đề xuất cho đến khi bỏ đi: cụ thể làtừ khi được đặt hàng, phát triển, sử dụngđến khi bị loại bỏ.Vòng đời phần mềm được phân chia thànhcác pha chính như xác định yêu cầu, triểnkhai, kiểm thử, bảo trì (vận hành)... Phạmvi, thứ tự các pha khác nhau tùy theo từngmô hình, dự án cụ thể

4

2.1. Vòng đời phát triển PM(2)

Tùy mô hình áp dụng mà việc phân chia cácpha, các bước có thể có sự khác nhau: từ 3 đến 20 pha.

Xác định yêu cầu Triển khai Kiểm thử

(VËn hµnh) Bảo trì

Vòng đời phần mềm

5

2.2. Các hoạt động phát triển PM

Phân tích tính khả thiPhân tích và đặc tả yêu cầuThiết kếMã hóaKiểm thửBảo trì

6

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

Phân tích tính khả thi– Xác định vấn đề cần giải quyết– Xem xét các giải pháp và kỹ thuật khác nhau (đánh

giá ưu nhược điểm của từng giải pháp)– Đá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ân tích

7

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

8

Phân tích và đặc tả yêu cầuĐặc tả yêu cầu (hay còn gọi là kỹ thuật xác định yêu cầu) là quy trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu vàcác ràng buộc trong quá trình vận hành và xây dựng hệ thống.Quy trình xác định yêu cầu bao gồm bốn pha chính: 1. Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định những yêu

cầu của người sử dụng có thoả mãn những công nghệ hiện tại hay không. Về góc độ kinh doanh, nghiên cứu khả thi nhằm xác định hệthống đưa ra có mang lại lợi nhuận không. Việc nghiên cứu khả thi nên được thực hiện một cách nhanh chóng và không quá tốn kém. Kết quả của việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây dựng hệ thống nữa hay không.

2. Phân tích và rút ra các yêu cầu: đây là quy trình đưa ra các yêu cầu hệ thống thông qua một số phương pháp như: quan sát hệ thống hiện tại, phỏng vấn và thảo luận với người sử dụng, phân tích nhiệm vụ, phân tích tài liệu hoặc hệ thống cũ … Trong pha này, chúng ta có thể phải xây dựng một hoặc nhiều mô hình hệ thống vàcác mẫu thử.

9

3. Đặc tả yêu cầu: Pha này sẽ tư liệu hoá những thông tin thu thập được. Có hai loại yêu cầu cần được xác định:

* Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tựnhiên bổ sung thêm cho các biểu đồ của các dịch vụ mà hệ thống cung cấp và các ràng buộc vận hành của nó. Kiểu yêu cầu này được viết bởi người sử dụng.

* Yêu cầu hệ thống: là những tài liệu có cấu trúc mô tả chi tiết về các chức năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu cầu hệ thống sẽ định nghĩa những gì cần phải xây dựng, cho nên nó có thể trở thành bản hợp đồng giữa khách hàng và nhà thầu.

4. Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem chúng có đúng thực tế hay không, có thống nhất không, có đầy đủ không. Nếu phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này.

10

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

Phân tích và đặc tả yêu cầu– Xác định nhu cầu của khách hàng/người sử dụng

Xác định bài toán, chứ không phải là giải pháp

– Khó khănKhách hàng không biết rõ cái họ cầnKhách hàng không trình bày rõ cái họ muốn thay đổi

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

11



12

Thiết kế phần mềmThiết kế phần mềm là quá trình thiết kế cấu trúc phần mềm dựa trên những tài liệu đặc tả. Hoạt động thiết kế bao gồm những công việc chính sau:

– Thiết kế kiến trúc: Các hệ thống con cấu thành lên hệ thống cần xây dựng và mối quan hệ giữa chúng được xác định và tư liệu hoá.

– Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả vềcác dịch vụ của nó và những ràng buộc khi nó vận hành.

– Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với những hệ thống con khác phải được thiết kế và tư liệu hoá.

– Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác và các giao diện tương tác với chúng phải được thiết kế.

– Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để cài đặt hệ thống phải được thiết kế một cách chi tiết và cụ thể.

– Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các dịch vụ phải được thiết kế chi tiết và chính xác.

13

Thiết kế phần mềm

Các công việc trong thiết kế phần mềm

14

Thiết kế phần mềm

Các phương pháp thiết kếHướng chức năngHướng đối tượng

15

Mã hóa và gỡ rối

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ìnhViết tài liệuChuẩn lập trìnhLập trình theo cấpCông cụQuản lý phiên bản

– 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

16

Kiểm thửKiểm thử - Đánh giá phần mềm hay còn gọi làthẩm tra và đánh giá (V&V - Verification and validation) được sử dụng để chỉ ra rằng hệthống đã thực hiện theo đúng các đặc tả vàthoả mãn mọi yêu cầu của khách hàng.Kiểm thử bao gồm các công đoạn: kiểm tra, xem xét lại, và kiểm thử hệ thống. Kiểm thửhệ thống tức là cho hệ thống thực hiện trên những trường hợp có dữ liệu thật được lấy từtài liệu đặc tả hệ thống. Quy trình kiểm thửgồm các pha sau:

17

– Kiểm thử thành phần (đơn vị): các thành phần được kiểm thử một cách độc lập, thành phần cóthể là một chức năng hoặc một đối tượng hoặc một nhóm các thực thể gắn kết với 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 của khách hàng hay không.

18

Kiểm thử– Khi chuyển giao hệ thống cho khách hàng thì quy

trình kiểm thử beta sẽ được thực hiện. Khách hàng sẽ thông báo các lỗi cho đội dự án. Những lỗi này sẽ được chỉnh sửa và tiếp tục kiểm thử beta hoặc chuyển giao thực sự cho khách hàng.

– Các công việc cần làm trong quá trình kiểm thửPhát hiện lỗi trong chương trìnhLậ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ử

19

Kiểm thử

Các phương pháp kiểm thử– Kiểm thử tĩnh– Kiểm thử động

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

20

Bảo trì hệ thống

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– Cài đặt các yêu cầu mới– Xử lý các lỗi khi vận hành– Sản phẩm: chương trình

21

Cải tiến phần mềm

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.

22

2.3. Các mô hình phát triển PMHiện nay có rất nhiều mô hình phát triển phần mềm, và thường được phân thành 2 loại: mô hình tuyến tính và mô hình lặp.– Mô hình tuyến tính: các bước được thực hiện tuần

tự, không lặp lại.Mô hình thác nướcMô hình V…

– Mô hình lặp: các bước có thể thực hiện song song, có thể lặp lại một số bước.

Mô hình tiến hóaMô hình xoắn ốcMô hình hợp nhất…

23

2.3.2. Mô hình Thác nước

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

24

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ì.

25

2.3.1. Mô hình Thác nước

Là mô hình cổ điểnPhương pháp áp dụng 1 lầnĐiều khiển hiệu quảPhạm vi giới hạn của vòng lặpVòng đời dàiKhông thích hợp với các hệ thống không rõràng

26

Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. Giảsử, pha phân tích và xác định yêu cầu đã hoàn tất vàchuyển sang pha kế tiếp, nhưng lúc này lại có sự thay đổi yêu cầu của người sử dụng; thì chỉ còn cách làphải thực hiện lại từ đầu. Mô hình này chỉ 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ế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định.

27

Ưu điểm:– Chỉ phù hợp với các dự án nhỏ hoặc– Yêu cầu xác định

Nhược điểm:– Không phù hợp với dự án lớn– Thời gian thực hiện lâu

28

2.3.2. Mô hình V

Phân tích yêucầu

Thiết kế hệthống

Thiết kếchương trình

Lập trình

Kiểm thử đơn vị vàtích hợp

Kiểm thử hệthống

Bảo trì

Kiểm thử chấp nhận

29

2.3.2. Mô hình V

Trong mô hình V:

– Các tiến trình kiểm thử được thêm vào

– Kết nối kiểm thử với phân tích và thiết kế

– Thích hợp với những trường hợp bài toán không

nhất quán

30

2.3.3. Mô hình bản mẫu

Nghe Kháchtrình bày

Tạo / sửabản mẫu

Khách kiểm trabản mẫu

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

31

2.3.3. Mô hình bản mẫu

Mục đích– Xem xét yêu cầu người sử dụng ở giai đoạn ban đầu

– Giảm bớt rủi ro và không chắc chắn– Kiểm chứng thiết kế và thực thi

Nên thường xuyên trả lời các câu hỏi chuyênbiệt; mục đích phải được xác định

32

Lợi ích của bản mẫu

Học bằng cách làm việcTăng cường giao tiếpTăng sự tham gia của người dùng vào dự ánLàm rõ các yêu cầu chỉ biết một phần

33

Tuần tự làm bản mẫu

Tập hợp yêu cầuThiết kế nhanhXây dựng bản mẫuĐánh giá của khách hàngLàm mịnQuay lại thiết kế nhanh để điều chỉnhXây dựng sản phẩm

34

Ưu điểm: phù hợp với– Hệ thống rủi ro cao– Yêu cầu không chắc chắn– Giao diện chưa rõ ràng– Chiến lược cài đặt chưa rõ ràng

35

Hạn chế:– Khách hàng có thể cho rằng nguyên mẫu là hệ

thống thựcMong đợi không thực tế về tiến triển của dự án

– Người phát triển có sự chọn lựa không tốtPhù hợp cho nguyên mẫu, nhưng không phù hợp cho hệthống thực

– 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

36

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

– Khi mới rõ mục đích chung chung của phần mềm, chưa rõ chi tiếtđầu vào hay xử lý ra sao hoặc chưa rõ yêu cầu đầu ra

– Dùng như “Hệ sơ khai” để thu thập yêu cầu người dùng qua cácthiết kế nhanh

– Các giải thuật, kỹ thuật dùng làm bản mẫu có thể chưa nhanh, chưa tốt, miễn là có mẫu để thảo luận gợi yêu cầu của người dùng

37

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

Mô hình phát triển ứng dụng nhanh (Rapid Application Development: RAD) là mô hình phát triển phần mềm giatăng, tăng dần từng bước (Incrimental softwaredevelopment) 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 (Component-based construction) với khả năng tái sử dụng (reuse)Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theocác pha: Mô hình nghiệp vụ, Mô hình dữ liệu, Mô hìnhxử lý, Tạo ứng dụng, Kiểm thử và đánh giá (Business, Data, Process, Appl. Generation, Test)

38

BusinessModeling

BusinessModeling

DataModeling

DataModeling

ProcessModelingProcessModeling

ApplicationGeneration


Testing &Turnover

Testing &Turnover

60 - 90 days

BusinessModeling

BusinessModeling

DataModeling

DataModeling

ProcessModeling

ProcessModeling



Testing &Turnover

Testing &Turnover

BusinessModeling

BusinessModeling

DataModeling

DataModeling

ProcessModeling

ProcessModeling



Testing &Turnover

Testing &Turnover

Team #1

Team #2

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

39

RAD: Mô hình nghiệp vụ

Luồng thông tin được mô hình hóa để trả lời các câuhỏ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 ?

40

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ácthuộc tính của từng đối tượng và xác lậpquan hệ giữa các đối tượngProcess modeling: Các đối tượng dữ liệuđược chuyển sang luồng thông tin thực hiệnchức năng nghiệp vụ. Tạo mô tả xử lý đễ cậpnhật (thêm, sửa, xóa, khôi phục) từng đốitượng dữ liệu

41

RAD: Tự sinh ứng dụng và kiểm thử

Application Generation: Dùng các kỹ thuậtthế hệ 4 để tạo phần mềm từ các thànhphần có sẵn hoặc tạo ra các thành phần cóthể tái dụng lại sau này. Dùng các công cụtự động để xây dựng phần mềmTesting and Turnover: Kiểm thử các thànhphần mới và kiểm chứng mọi giao diện(các thành phần cũ đã được kiểm thử vàdùng lại)

42

RAD: Hạn chế ?Cần nguồn nhân lực dồi dào để tạo các nhóm cho các chức năngchínhYêu cầu hai bên giao kèo trong thời gian ngắn phải có phầnmềm hoàn chỉnh, thiếu trách nhiệm của một bên dễ làm dự ánđổ vỡRAD không phải tốt cho mọi ứng dụng, nhất là với ứng dụngkhông thể môđun hóa hoặc đòi hỏi tính năng caoMạo hiểm kỹ thuật cao thì không nên dùng RAD

43

2.3.5. Mô hình tiến hóa

Phần lớn các hệ phần mềm phức tạp đều tiến hóatheo thời gian: môi trường thay đổi, yêu cầu phátsinh thêm, hoàn thiện thêm chức năng, tính năngCác mô hình tiến hóa (evolutionary models) có tínhlặp lại. Kỹ sư phần mềm tạo ra các phiên bản(versions) ngày càng hoàn thiện hơn, phức tạp hơnCác mô hình: gia tăng (incremental), xoắn ốc (spiral), xoắn WINWIN (WINWIN spiral) mô hình phát triển đồng thời (concurrent development model)

44

Mô hình tiến hóa

45

2.3.5. Mô hình tiến hóa

Ưu điểm: phù hợp với– Dự án vừa và nhỏ– Các phần của dự án phức tạp– Các hệ thống có thời gian sống ngắn

Hạn chế– Cấu trúc hệ thống tồi– Tiến trình không rõ ràng

46

2.3.5.1. Mô hình gia tăng

Mô hình gia tăng (The incremental model): Kếthợp mô hình tuần tự và ý tưởng lặp lại của chế bảnmẫuSản phẩm lõi với những yêu cầu cơ bản nhất củahệ thống được phát triểnCác chức năng với những yêu cầu khác được pháttriển thêm sau (gia tăng)Lặp lại quy trình để hoàn thiện dần

47

2.3.5.1. Mô hình gia tăng

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

System/info.Engineering

Calendar time




Gia tăng 1

Xuất xưởng 1

Gia tăng 2 Xuất xưởng 2

Gia tăng 3 Xuất xưởng 3

Gia tăng 4 XX 4

48

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 giai đoạn, tăng dần. Mỗi giai đoạn 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 giai đoạn phát triển sớm hơn.

49

Mô hình gia tăng

50

Ưu điểm của mô hình phát triển gia tăng: – Sau mỗi lần tăng vòng thì có thể chuyển giao kết

quả thực hiện được cho khách hành nên các chức năng của hệ thống có thể nhìn thấy sớm hơn.

– Các vòng trước đóng vai trò là mẫu thử để giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo.

– Những chức năng của hệ thống có thứ tự ưu tiên càng cao thì sẽ được kiểm thử càng kỹ.

51

2.3.5.2. Mô hình xoắn ốc

Giao tiếpkhách hàng

Lập kế hoạchPhân tích rủi ro

Thiết kế

Xây dựng & Xuất xưởng

Khách hàngđánh giá

Khái niệm

Làm mới

Nâng cấp

Bảo trì

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

52

2.3.5.2. Mô hình xoắn ốc (Boehm 1987)

Kế hoạch cho giai đoạn tiếp

Xác định mục đích, lựa chọn và ràngbuộc

Đánh giá lựa chọn; xác định và giải

quyết rủi ro

Phát triển và kiểmchứng sản phẩm

mức tiếp theo

Lập kế hoạchyêu cầu

Lập kế hoạchphát triển

Kế hoạch kiểmthử và tích hợp

Chức năng

Phân tíchrủi ro

Phân tíchrủi ro

Phân tíchrủi ro

Bản mẫu

Bản mẫuBản mẫu

Yêu cầu phần mềm

Kiểm thử yêucầu

Thiết kếhệthống

Kiểm thửthiết kế

Kiểm thửchấp nhận

Tích hợp vàkiểm thử

Kiểmthử đơn vị

Lậptrình

Thiết kếchi tiết

Chi phí tăng thêm

53

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 quy trình phát triển 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ừ những 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.

54


Nhấn mạnh việc đánh giá các rủi roPhần mềm được xây dựng theo nhiều chu kỳ. Mỗi chu kỳ tương ứng với một sản phẩm của 1 giai đọan phát triển– Xác định các mục tiêu, giải pháp, ràng 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ử sản phẩm của chu kỳ này– Lập kế hoạch cho chu kỳ tiếp theo

55

2.3.5.2. Mô hình xoắn ốc (tiếp)Giao tiếp khách hàng: giữa người phát triển và kháchhàng để tìm hiểu yêu cầu, ý kiếnLập kế hoạch: Xác lập tài nguyên, thời hạn và nhữngthông tin khácPhân tích rủi ro: Xem xét mạo hiểm kỹ thuật và mạohiểm quản lýThiết kế: Xây dựng một hay một số biểu diễn của ứngdụng

56

2.3.5.2. Mô hình xoắn ốc (tiếp)

Xây dựng và xuất xưởng: xây dựng, kiểmthử, 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ồicủa người sử dụng về biểu diễn phần mềmtrong giai đoạn kỹ nghệ và cài đặt

57

2.3.5.2. Mô hình xoắn ốc (tiếp)

Ưu điểm– Hạn chế rủi ro sớm– Nhận được phản hồi (feedbacks) từ khách hàng

sớm– Dễ kiểm soát các mạo hiểm ở từng mức tiến hóa

Hạn chế– Khó thuyết phục khách hàng là phương pháp tiến

hóa xoắn ốc có thể kiểm soát được– Chưa được dùng rộng rãi như các mô hình tuyến

tính hoặc chế thử.

58


Mô hình xoắn ốc phù hợp với – Các hệ phần mềm quy mô lớn, các dự án lớn,

phức tạp– Hệ thống cần phát triển nhiều phiên bản– Các hệ thống có yêu cầu chưa xác định rõ ràng

59

2.3.5.3. Mô hình xoắn ốc WINWIN

Là mô hình xoắn ốc nhằm thỏa hiệp giữa người phát triểnvà khách hàng, cả hai cùng “Thắng” (win-win)

– Khách thì có phần mềm thỏa mãn yêu cầu chính– Người phát triển thì có kinh phí thỏa đáng và thời gian hợp lý

Các hoạt động chính trong việc xác định hệ thống:– Xác định cổ đông (stakeholders)– Xác định điều kiện thắng của cổ đông– Thỏa hiệp điều kiện thắng của các bên liên quan

60

2.3.5.3. Mô hình xoắn ốc WINWIN

1. Xác định mứctiếp của cổ đông

2. Xác định điều kiệnthắng của cổ đông

3a. Hòa hợp điều kiện thắng3b. Thiết lập mục tiêu mức tiếp

và các ràng buộc, dự kiến

4. Đánh giá tiến trình vàdự kiến sản phẩm,giải quyết rủi ro

5. Xác định mức tiếp củasản phâm và quy trình,kể cả phân chia nhỏ

7. Xét duyệt và đánh giá6. Kiểm định sản phẩm

và quy trình

61

2.3.6. Mô hình phát triển đồng thời

Mô hình phát triển đồng thời (The concurrent development model):

– Xác định mạng lưới những hoạt động đồng thời (Network ofconcurrent activities)

– Các sự kiện (events) xuất hiện theo điều kiện vận động trạngthái trong từng hoạt động

– Dùng cho mọi loại ứng dụng và cho hình ảnh khá chính xácvề trạng thái hiện trạng của dự án

– Thường dùng trong phát triển các ứng dụng khách/chủ(client/server applications): hệ thống và các thành phần(componets) trong hệ thống được phát triển đồng thời.

62

2.3.7. Mô hình hướng thành phần

Mô hình hướng thành phần (Component-based model): Gắn với những công nghệ hướng đối tượng (Object-oriented technologies) qua việc tạo các lớp (classes) cóchứa cả dữ liệu và giải thuật xử lý dữ liệuCó nhiều tương đồng với mô hình xoắn ốcVới ưu điểm tái sử dụng các thành phần qua Thư viện / kho các lớp: tiết kiệm 70% thời gian, 80% giá thành.Mô hình hướng thành phần sử dụng UML như một chuẩn công nghiệp

63

2.3.7. Mô hình hướng thành phần

Giao tiếpkhách hàng

Lập kế hoạchPhân tích rủi ro

Kỹ nghệXây dựng & Xuất xưởng

Khách hàngđánh giá

Xác địnhthành phầnứng viên

Tìmthành phầntừ thư viện

Lấythành phần

nếu có

Xây dựngthành phầnnếu kh.có

Đặtthành phầnvào thư viện

Xây dựngbước lặp thứ ncủa hệ thống

64

2.3.7. Mô hình hướng sử dụng lại

Mô hình này phát triển định hướng sử dụng lại(Reuse)

Hệ thống được tích hợp từ các thành phầnđã tồn tại hay hệ thống phi thương mạiCác giai đoạn của tiến trình– Phân tích thành phần– Cải biến các yêu cầu– Thiết kế hệ thống hướng sử dụng lại– Phát triển và tích hợp

65

2.3.7. Mô hình hướng sử dụng lạiPhát triển định hướng sử dụng lại (2)

Đặc tả yêucầu

Phát triển vàtích hợp

Thay đổiyêu cầu

Thẩm địnhhệ thống

Phân tíchthành phần

Thiết kế HT dùng lại

Hướng phát triển này rất quan trọng nhưngkinh nghiệm và công cụ còn hạn chế

66

2.3.8. Mô hình hợp nhấtMô hình hợp nhất sử dụng Các kỹ thuật thế hệ 4 (Fourth generation techniques): Tập hợp các côngcụ cho phép xác định đặc tính phần mềm ở mứccao, sau đó tự động sinh mã nguồn dựa theo đặc tảđó.Các công cụ 4GT điển hình: ngôn ngữ phi thủ tụccho truy vấn CSDL, tạo báo cáo, xử lý dữ liệu, tươngtác màn hình, tạo mã nguồn, khả năng đồ họa bậccao, khả năng bảng tính, khả năng giao diện Web.Từ thu thập yêu cầu cho đến sản phẩm: đối thoại giữa khách và người phát triển là quan trọng.Không nên bỏ qua khâu thiết kế: 4GT chỉ áp dụng đểtriển khai thiết kế qua 4GL

67

2.3.8. Mô hình hợp nhất

Tiến trình hợp nhất có thể được nhìn dưới hai góc nhìn khác nhau– Góc nhìn quả lý: quan tâm đến lĩnh vực kinh tế,

chiến thuật, con người. Tiến trình gồm 4 giai đoạn.

– Góc nhìn kỹ thuật: quan tâm đến công nghệ, kiểm tra chất lượng, phương pháp.

Tiến trình gồm nhiều bước lặp.

68


Góc nhìn quản lý

69


Góc nhìn kỹ thuật: các bước lặp– Mỗi bước lặp gồm các hoạt động

Đặc tảPhân tíchThiết kếMã hóa Kiểm thửCài đặt

– Mỗi bước lặp là một tiến trình thác đổ

70


Góc nhìn kỹ thuật

71


Kết hợp hai góc nhìn

72


Mô hình hợp nhất và UML

73


Ưu điểm: giảm thời gian phát triển và tăng năng suất lao động.Nhược điểm: 4GT khó dùng hơn ngôn ngữlập trình, mã khó tối ưu và khó bảo trì cho hệthống lớn ⇒ cần kỹ năng của kỹ sư phần mềmTrong tương lai: kết hợp 4GT với mô hình hướng thành phần.

74

Kết luận

Trong thực tế, người ta thường kết hợp nhiều mô hình cho một dự án– Đối với Hệ thống phức tạp, cần chia dự án thành

các hệ thống con– Áp dụng mô hình xoắn ốc hay mô hình hợp nhất

cho toàn bộ dự án.– Mỗi hệ thống con có thể áp dụng một mô hình

khác nhauÁp dụng mô hình nguyên mẫu cho các hệ thống con phức tạpÁp dụng mô hình thác nước cho các hệ thống con khác

75


Lựa chọn mô hìnhPhụ 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

Yêu cầu chưa rõ ràng, độ phức tạp caoYêu cầu có khả năng thay đổiKhông chắc chắn về tính hiệu quả, tính khả thi

=> Làm bản mẫu, mô hình xoắn ốc

76


Tổ hợp các mô hình: Có thể tổ hợp các mô hình để đem lại hiệu quả

77


Lặp tiến trình: Mỗi phần của tiến trình được lặp theo 2 cách tiếp cận

• Phát triển tăng• Phát triển xoắn ốc

78


Chuẩn hóa tiến trình: Tăng năng lực của tổ chức phát triển phầnmềm

� ISO 9000-03 (International Standards Organization )

• CMM (Software Engineering Institute)

79

• tái sử dụng: thư viện thương mại,...• tự sinh mã: công cụ tạo giao diện,...• hướng đối tượng: kế thừa, bảo trì• ngôn ngữ bậc cao: năng lực biểu diễn cao


Giảm chi phí phát triển:Sử dụng các phương pháp, công cụ tiên tiến

80


Thực hiện các pha phát triển: Pha 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ứcso với mã hóa, kiểm thửKhi chuyển tiếp giữa các pha phát triển phải thẩmđịnh để đảm bảo lỗi không ảnh hưởng đến pha sauTà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ầnmềm và dùng trong khâu bảo trìCần chuẩn hóa mẫu biểu, cách thức ghi chép, tạo tàiliệu nhằm đảm bảo chất lượng phần mềm.

81

CÂU HỎI ÔN TẬP1. Phân biệt các mô hình tiến trình2. Khi có yêu cầu phát triển một hệ thống:

– Cần lưu ý gì trong việc lựa chọn mô hình tiến trình– Lựa chọn mô hình phù hợp bằng cách nào– Có những chỉ dẫn gì trong việc lựa chọn mô hình

3. Xác định tiến trình phát triển như thế nào?4. Vấn đề chuẩn hóa tiến trình

– Tìm hiểu và viết báo cáo, trình bày về mô hình phát triển phần mềm (mỗi nhóm 1 mô hình)

chuong 2. cnpm

Documents