Giáo trình Quy trình phát triển phần mềm - Trường Đại học Hàng Hải
TRƢỜNG ĐẠI HỌC HÀNG HẢI VIỆT NAM
KHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN HỆ THỐNG THÔNG TIN
-----***-----
BÀI GIẢNG
QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
TÊN HỌC PHẦN
MÃ HỌC PHẦN
: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
: 17408
TRÌNH ĐỘ ĐÀO TẠO
: ĐẠI HỌC CHÍNH QUY
DÙNG CHO SV NGÀNH : CÔNG NGHỆ THÔNG TIN
HẢI PHÒNG - 2011
2
MỤC LỤC
Nội dung
Trang
Chƣơng 1: Giới thiệu
1.1. Tổng quan về quy trình phát triển phần mềm
1.2. Các hoạt động cơ bản của phát triển phần mềm
Chƣơng 2: Các quy trình phát triển phần mềm truyền thống
2.1. Mô hình thác nước (Waterfall)
2.2. Mô hình phát triển ứng dụng nhanh (RAD)
2.3. Mô hình lặp lại và tăng trưởng (Incremental)
2.4. Mô hình xoắn ốc (Spiral)
Chƣơng 3: Quy trình phát triển phần mềm thống nhất Rational Unified
Process (RUP)
3.1. Giới thiệu
3.1.1 Kiến trúc của RUP
3.1.2 So sánh RUP với một số quy trình phát triển phần mềm khác
3.2. Vòng đời của một dự án RUP
3.2.1 Khởi tạo (Inception)
3.2.2 Phác thảo (Elaboration)
3.2.3 Xây dựng (Construction)
3.2.4 Chuyển giao (Transition)
3.3. Các luồng công việc chính trong RUP
3.3.1 Mô hình nghiệp vụ (Business modeling)
3.3.2 Quản lý yêu cầu (Requirements management)
3.3.3 Phân tích và thiết kế (Analysis and design)
3.3.4 Cài đặt (Implementation)
3.3.5 Kiểm thử (Test)
3.3.6 Triển khai ứng dụng (Deployment)
3.3.7 Quản lý cấu hình và sự thay đổi(Change management)
3.3.8 Quản lý dự án (Project management)
3.3.9 Quản lý môi trường ứng dụng (Environment)
Chƣơng 4: Quy trình phát triển phần mềm eXtreme Programming (XP)
4.1. Giới thiệu về XP
4.2. Vai trò, quyền hạn và trách nhiệm của các tác nhân trong XP
4.3. Các giá trị cốt lõi của XP
4.3.1. Sự giao tiếp (Communication)
4.3.2. Sự đơn giản (Simplicity)
4.3.3. Sự phản hồi (Feedback)
4.3.4. Sự dũng cảm (Courage)
4.4. Vòng đời phát triển của một dự án XP
4.4.1. Khởi tạo (Exploration )
4.4.2. Lập kế hoạch (Planning)
4.4.3. Chuyển giao từng phần (Iterations to Release)
4.4.4. Triển khai hoàn thiện sản phẩm (Productionizing)
4.4.5. Duy trì sản phầm (Maintenance)
4.5. Các công việc cốt lõi trong XP
4.5.1. Lập kế hoạch (The Planning Game)
4.5.2. Chuyển giao từng phần (Small releases)
4.5.3. Bảng định danh (Metaphor)
4.5.4. Thiết kế đơn giản (Simple design)
3
4.5.5. Kiểm thử liên tục (Testing)
4.5.6. Hoàn thiện liên tục (Refactoring)
4.5.7. Lập trình theo đôi (Pair programming)
4.5.8. Chia sẻ công việc (Collective ownership)
4.5.9. Tích hợp liên tục (Continuous integration)
4.5.10. Làm việc cùng khách hàng (On-site customer)
4.5.11. Sử dụng các chuẩn viết mã (Coding standards)
4.5.12. Giới hạn 40 giờ/tuần (40-hour week)
Một số đề thi mẫu
4
Tên học phần: Các quy trình phát triển phần mềm
Bộ môn phụ trách giảng dạy: Hệ thống Thông tin
Mã học phần: 17408
Loại học phần: 3
Khoa phụ trách: CNTT.
Tổng số TC: 3
Tổng số tiết Lý thuyết Thực hành/ Xemina
Tự học
Bài tập lớn
Đồ án môn học
Không
60
45
0
0
Có
Học phần học trƣớc: Nhập môn Công nghệ Phần mềm.
Học phần tiên quyết: Không yêu cầu.
Học phần song song: Không yêu cầu.
Mục tiêu của học phần:
Cung cấp các kiến thức cơ bản về quy trình phát triển phần. Giúp sinh viên nắm được các quy trình
phát triển phần mềm phổ biến hiện nay và vận dụng vào thực tế.
Nội dung chủ yếu:
Tổng quan về quy trình phát triển phần mềm; Giới thiệu các quy trình phát triển phần mềm cơ bản;
Vòng đời phát triển và công việc chính của các quy trình phát triển phần mềm: Rational Unified
Process (RUP), Extreme Programming (XP).
Nội dung chi tiết:
PHÂN PHỐI SỐ TIẾT
TÊN CHƢƠNG MỤC
TS LT TH BT KT
Chƣơng 1: Giới thiệu
3
3
1.1. Tổng quan về quy trình phát triển phần mềm
1.2. Các hoạt động cơ bản của phát triển phần mềm
Chƣơng 2: Các quy trình phát triển phần mềm truyền thống 10
2.1. Mô hình thác nước (Waterfall)
2.2. Mô hình phát triển ứng dụng nhanh (RAD)
2.3. Mô hình lặp lại và tăng trưởng (Incremental)
2.4. Mô hình xoắn ốc (Spiral)
9
1
1
Chƣơng 3: Quy trình phát triển phần mềm thống nhất
Rational Unified Process (RUP)
3.1. Giới thiệu
16
15
3.1.1 Kiến trúc của RUP
3.1.2 So sánh RUP với một số quy trình khác
3.2. Vòng đời của một dự án RUP
3.2.1 Khởi tạo (Inception)
3.2.2 Phác thảo (Elaboration)
3.2.3 Xây dựng (Construction)
3.2.4 Chuyển giao (Transition)
3.3. Các luồng công việc chính trong RUP
3.3.1 Mô hình nghiệp vụ (Business modeling)
3.3.2 Quản lý yêu cầu (Requirements management)
3.3.3 Phân tích và thiết kế (Analysis and design)
3.3.4 Cài đặt (Implementation)
3.3.5 Kiểm thử (Test)
3.3.6 Triển khai ứng dụng (Deployment)
3.3.7 Quản lý cấu hình và sự thay đổi(Change management)
3.3.8 Quản lý dự án (Project management)
3.3.9 Quản lý môi trường ứng dụng (Environment)
Chƣơng 4: Quy trình phát triển phần mềm eXtreme
Programming (XP)
13
12
1
4.1. Giới thiệu về XP
4.2. Vai trò, quyền hạn và trách nhiệm của các tác nhân trong
XP
5
4.3. Các giá trị cốt lõi của XP
4.3.1. Sự giao tiếp (Communication)
4.3.2. Sự đơn giản (Simplicity)
4.3.3. Sự phản hồi (Feedback)
4.3.4. Sự dũng cảm (Courage)
4.4. Vòng đời phát triển của một dự án XP
4.4.1. Khởi tạo (Exploration )
4.4.2. Lập kế hoạch (Planning)
4.4.3. Chuyển giao từng phần (Iterations to Release)
4.4.4. Triển khai hoàn thiện sản phẩm (Productionizing)
4.4.5. Duy trì sản phầm (Maintenance)
4.5. Các công việc cốt lõi trong XP
4.5.1. Lập kế hoạch (The Planning Game)
4.5.2. Chuyển giao từng phần (Small releases)
4.5.3. Bảng định danh (Metaphor)
4.5.4. Thiết kế đơn giản (Simple design)
4.5.5. Kiểm thử liên tục (Testing)
4.5.6. Hoàn thiện liên tục (Refactoring)
4.5.7. Lập trình theo đôi (Pair programming)
4.5.8. Chia sẻ công việc (Collective ownership)
4.5.9. Tích hợp liên tục (Continuous integration)
4.5.10. Làm việc cùng khách hàng (On-site customer)
4.5.11. Sử dụng các chuẩn viết mã (Coding standards)
4.5.12. Giới hạn 40 giờ/tuần (40-hour week)
Chƣơng 5: Ứng dụng các quy trình phát triển phần mềm
5.1. Giới thiệu một số dự án phần mềm
5.2. Đánh giá các dự án phần mềm
3
3
Nhiệm vụ của sinh viên:
Tham dự các buổi học lý thuyết và thực hành, làm các bài tập được giao, làm các bài thi giữa
học phần và bài thi kết thúc học phần theo đúng quy định.
Tài liệu học tập:
1. Roger S. Pressman, Software Engineering: A Practitioner's Approach, McGraw-Hill, 2001.
2. Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified Software Development
Process, Addison Wesley, 1999.
3. Philippe Kruchten, The Rational Unified Process An Introduction, Second Edition, Addison
Wesley, 2000.
4. Ron Jeffries, Ann Anderson, Chet Hendrickson, Extreme Programming Installed, Addison
Wesley, 2000.
Hình thức và tiêu chuẩn đánh giá sinh viên:
- Hình thức thi: tự luận.
- Tiêu chuẩn đánh giá sinh viên: căn cứ vào sự tham gia học tập của sinh viên trong các buổi
học lý thuyết và thực hành, kết quả làm các bài tập được giao, kết quả của các bài thi giữa học phần
và bài thi kết thúc học phần.
Thang điểm: Thang điểm chữ A, B, C, D, F.
Điểm đánh giá học phần: Z = 0,3X + 0,7Y.
Bài giảng này là tài liệu chính thức và thống nhất của Bộ môn Hệ thống Thông tin, Khoa
Công nghệ Thông tin và được dùng để giảng dạy cho sinh viên.
Ngày phê duyệt:
/
/
Trƣởng Bộ môn
6
Chương 1: Giới thiệu
1.1. Tổng quan về quy trình phát triển phần mềm
Công nghệ phần mềm hay kỹ nghệ phần mềm (tiếng Anh: Software Engineering) là sự áp dụng một
cách tiếp cận có hệ thống, có kỷ luật, và định lượng được cho việc phát triển, hoạt động và bảo trì
phần mềm. Ngành học kỹ nghệ phần mềm bao trùm kiến thức, các công cụ, và các phương pháp
cho việc định nghĩa yêu cầu phần mềm, và thực hiện các tác vụ thiết kế phần mềm, xây dựng phần
mềm, kiểm thử phần mềm (software testing), và bảo trì phần mềm. Kỹ nghệ phần mềm còn sử dụng
kiến thức của các lĩnh vực như kỹ thuật máy tính, khoa học máy tính, quản lý, toán học, quản lý dự
án, quản lý chất lượng, công thái học phần mềm (software ergonomics), và kỹ nghệ hệ thống
(systems engineering).
Quá trình phát triển phần mềm là tập hợp các thao tác và các kết quả tương quan để sản xuất ra một
sản phẩm phần mềm. Hầu hết các thao tác này được tiến hành bởi các kỹ sư phần mềm. Các công
cụ hỗ trợ máy tính về kỹ thuật phần mềm có thể được dùng để giúp trong một số thao tác.
1.2. Các hoạt động cơ bản của phát triển phần mềm
Có 4 thao tác là nền tảng của hầu hết các quá trình phần mềm là:
1. Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải được
định nghĩa.
2. Cài đặt phần mềm: Để phần mềm đạt được những yêu cầu trong đặc tả thì phải có quá trình
cài đặt.
3. Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng nó làm những gì mà
khách hàng muốn.
4. Sự tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay đổi các yêu cầu
của khách hàng.
Bài tập
1) Quy trình phát triển phần mềm là gì?
2) Các hoạt động cơ bản của phát triển phần mềm
7
Chương 2: Các quy trình phát triển phần mềm truyền thống
2.1. Mô hình thác nước (Waterfall)
1. Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục tiêu được hình
thành bởi sự trợ ý của hệ thống người tiêu dùng. Sau đó các yếu tố này được định nghĩa sao
cho có thể hiểu được bởi cả người phát triển và người tiêu dùng.
2. Thiết kế phần mềm và hệ thống: Thiết kế hệ thống các quá trình, các bộ phận và các yêu cầu
về cả phần mềm lẫn phần cứng. Hoàn tất hầu như tất cả kiến trúc của các hệ thống này.
Thiết kế phần mềm tham gia vào việc biểu thị các chức năng hệ thống phần mềm mà có thể
được chuyển dạng thành một hay nhiều chương trình khả thi.
3. Thực hiện và thử nghiệm đơn vị: Trong giai đoạn này, thiết kế phần mềm phải được chứng
thực như là một tập hợp nhiều chương trình hay nhiều đơn vị nhỏ. Thử nghiệm đơn vị bao
gồm xác minh rằng mỗi đơn vị thỏa mãn đặc tả của nó.
4. Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ hay các chương trình
được tích hợp lại và thử nghiệm như là một hệ thống hoàn tất và chứng tỏ được các yêu cầu
của phần mềm được thỏa mãn. Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu
dùng.
5. Sản xuất và bảo trì: Thông thường (nhưng không bắt buộc) đây là pha lâu nhất của chu kỳ
sống (của sản phẩm). Phần mềm được cài đặt và được dùng trong thực tế. Bảo trì bao gồm
điều chỉnh các lỗi mà chưa được phát hiện trong các giai đọan trước của chu kì sống; nâng
8
cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là các phát hiện
vê yêu cầu mới.
Chỗ yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra thành những phần
riêng của các giai đoạn. Hệ thống phân phối đôi khi không dùng được vì không thỏa mãn được yêu
cầu của khách hàng. Mặc dù vậy mô hình này phản ảnh thực tế công nghệ. Như là một hệ quả đây
vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm - phần cứng.
2.2. Mô hình phát triển ứng dụng nhanh (RAD)
Mô hình phát triển nhanh (RAD – Rapid Application Development) chính là mô hình tăng dần với
chu kỳ phát triển cực ngắn. Để đạt được mục tiêu này, RAD dựa trên phương pháp phát triển trên
cơ sở 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. RAD thích hợp
cho những hệ thống quản lý thông tin.
2.3. Mô hình lặp lại và tăng trưởng (Incremental)
Phân loại sự phát triển tiến hóa
1. Lập trình thăm dò: đối tượng của quá trình bằng cách làm việc với khách hàng để thăm dò
các yêu cầu và phân phối phần mềm dứt diểm. Sự phát triển nên bắt đầu với những phần nào
đã được hiểu rõ. Phần mềm sẽ được thêm vào các chức năng mới khi mà nó được đề nghị
cho khách hàng (và nhận về các thông tin).
2. Mẫu thăm dò: đối tượng của phát triển tiến hoá này là nhằm hiểu các yêu cầu của khách
hàng và do đó phát triển các định nghĩa yêu cầu tốt hơn cho phần mềm. Các mẫu tập trung
trên các thí nghiệm với những phần đòi hỏi nào của khách hàng mà có thể gây sự khó hiểu
hay ngộ nhận.
Phân tích mô hình: Mô hình phát triển tiến hóa này hiệu quả hơn mô hình thác nước. Tuy
nhiên, nó vẫn còn các khuyết điểm:
1. Quá trình thì không nhìn thấy rõ được: Các nhà quản lý cần phân phối thường xuyên
để đo lường sự tiến bộ. Nó không kinh tế trong việc làm ra các hồ sơ cho phần mềm.
9
2. Phần mềm thường dược cấu trúc nghèo nàn: Sự thay đổi liên tục dễ làm đổ vỡ cấu
trúc của phần mềm, tạo ra sự khó khăn và tốn phí.
3. Thường đòi hỏi những kỹ năng đặc biệt: Hầu hết các hệ thống khả dĩ theo cách này
được tiến hành bởi các nhóm nhỏ có kỹ năng cao cũng như các cá nhân phải năng
động.
Mô hình này thích hợp với:
1. Phát triển các loại phần mềm tương đối nhỏ
2. Phát triển các loại phần mềm có đời sống tương đối ngắn
3. Tiến hành trong các hệ thống lớn hơn ở những chỗ mà không thể biểu thị được các
đặc tả chi tiết trong lúc tiến hành. Thí dụ của trường hợp này là các hệ thống thông
minh nhân tạo (AI) và các giao diện cho người dùng.
10
2.4. Mô hình xoắn ốc (Spiral)
Đây là mô hình phát triển từ mô hình thác nước cho thấy mức độ tổng quát hơn của các pha sản
xuất của một sản phẩm. Mô hình này có thể chỉ ra các rủi ro có thể hình thành trên căn bản của mô
hình quá trình (sản xuất) tổng quát.
Mô hình Boehm có dạng xoắn ốc. Mỗi vòng lặp đại diện cho một pha của quá trình phần mềm.
Vòng trong cùng tập trung về tính khả thi, vòng kế lo về định nghĩa các yêu cầu, kế đến là thiết
kế,...
Không có một pha nào được xem là cố định trong vòng xoắn. Mỗi vòng có 4 phần tương ứng với
một pha.
1. Cài đặt đối tượng: Chỉ ra các đối tượng của pha trong đề án. Những khó khăn của quá trình
và của sản phẩm được xác định và được lên kế hoạch chi tiết. Xác định các yếu tố rủi ro của
đề án. Các phương án thay thế tùy theo các rủi ro này có thể được dự trù.
2. Lượng định và giảm thiểu rủi ro. Tiến hành phân tích mỗi yếu tố rủi ro đã xác định. Các
bước đặt ra để giảm thiểu rủi ro.
3. Phát triển và đánh giá: Sau khi đánh giá các yếu tố rủi ro, một mô hình phát triển cho hệ
thống được chọn.
4. Lên kế hoạch: Đề án được xem xét và quyết định có nên hay không tiếp tục pha mới trong
vòng lặp.
Bài tập
1) Trình bày mô hình thác nước
2) Trình bày mô hình lặp và tăng trưởng
5. Trình bày mô hình xoắn ốc
11
Chương 3: Quy trình phát triển phần mềm thống nhất
Rational Unified Process (RUP)
3.1. Giới thiệu
Trong phát triển phần mềm, có những sai sót làm ảnh hưởng không nhỏ đến chất lượng sản phẩm.
Các sai sót này có thể phát sinh từ nhiều nguồn khác nhau trong quá trình xây dựng hệ thống, chẳng
hạn như không quản lý được các yêu cầu, không phát hiện lỗi kịp thời, không quản lý được các thay
đổi của dự án.
-
RUP là một quy trình vòng lặp phát triển phần mềm được tạo ra bởi công ty Rational
Software, một bộ phận của IBM từ năm 2002 (IBM Rational).
RUP không phải là một quy trình bó hẹp cụ thể đơn nhất nhưng là một nền tảng quy trình
-
thích ứng với sự phát triển các tổ chức và các nhóm dự án phần mềm, tất cả sẽ chọn các yếu tố cần
thiết của quy trình để phù hợp với nhu cầu, quy mô của công ty, dự án và sản phẩm.
-
Unified Process được thiết kế từ đặc điểm chung, quy trình phạm vi rộng lớn và RUP là một
mô tả chi tiết cụ thể.
-
RUP hỗ trợ các hoạt động giữa các nhóm, phân chia công việc cho từng thành viên trong
nhóm, trong từng giai đoạn khác nhau của quá trình phát triển phần mềm.
-
UML.
-
RUP sử dụng hệ thống ký hiệu trực quan của UML và RUP được phát triển song song với
RUP là một sản phẩm tiến trình có thể tùy biến.
3.1.1 Kiến trúc của RUP
Cấu trúc của quy trình RUP, được thể hiện theo hai chiều:
-
Trục hoành: là chiều biểu diễn thời gian và vòng đời của quy trình: thể hiện mặt động của
chu kì (cycles), được biểu diễn dưới dạng các giai đoạn (phase), các vòng lặp (interations) và các
cột mốc thời gian (milestones).
-
Trục tung: là chiều biểu diễn các tiến trình của quy trình, là các công việc được nhóm lại
một cách logic theo bản chất của chúng, thể hiện mặt tĩnh dưới dạng các thành phần của chu trình
như các tiến trình, các kết quả sinh ra (artifacts_WHAT), cá nhân hay một nhóm thực hiện
(worker_WHO), giai đoạn công việc hoạt động liên quan với nhau (workflows_WHEN) và các đơn
vị công việc (activities_HOW).
12
-
Luồng công việc chính:
Business modeling
Requirement
Analysis & Design
Implemention
Test
Deployment
- Luồng công việc hỗ trợ:
Project Management
Configuration and Change Management
Enviroment
3.1.2 So sánh RUP với một số quy trình phát triển phần mềm khác
So sánh RP với XP:
RUP không đề cập tỉ mỉ đến những định lý, tuy nhiên những nguyên lý cơ bản của phương pháp
luận được đề ra rõ ràng và ta có thể thấy rõ, ví dụ như phản hồi từ khách hàng, sự thay đổi tăng dần,
đầu tư ban đầu ít, thử nghiệm cụ thể và tuỳ biến theo từng nơi.
Có một số điểm tương đồng trong chiến lược lập kế hoạch, cả hai phương pháp đều phát biểu là
không lập kế hoạch quá cụ thể ngay từ ban đầu bởi vì bạn không thể biết công việc gì là quan trong
ngay từ lúc đầu. Cả hai phương pháp sử dụng quan niệm vòng quay của dự án, và nhấn mạnh sự ưu
tiên theo mức độ quan trọng của các chức năng. User story và use case đều được dùng để định
hướng kiến trúc phần mềm và đóng vai trò quyết định cho việc lập kế hoạch cũng như quá trình
phát triển.
13
Phương pháp luận hướng đối tượng đều là công cụ chính của cả hai phương pháp.
User story trong XP giống hệt với Use case trong RUP.
Trong các yếu tố quan trọng cấu thành dự án là phạm vi dự án, tính đúng hạn, chất lượng và tài
nguyên dự án, XP khuyến cáo chúng ta cần giữ cố định mục tiêu tính đúng hạn, chất lượng và tài
nguyên. Phạm vi dự án có thể được phép điều chỉnh. RUP không đặt quan điểm một cách chặt chẽ
như vậy, tuy nhiên RUP cho phép chúng ta dùng phương pháp xây dựng ma trận quyết định, trong
đó các yếu tố đó có thể được điều chỉnh để phù hợp theo đặc tính của từng dự án. Dẫu RUP không
phát biểu cụ thể như vây về sự cho phép thay đổi phạm vi dự án, tuy nhiên quan điểm tương đồng
cũng thể hiện ở phương pháp phát triển phần mềm “to dần” của RUP.
Việc kiểm tra chương trình một cách tự động đều được XP và RUP khuyến cáo. XP dựa trên việc
này để đảm bảo chi phí thấp cho mỗi sự thay đổi, tuy nhiên RUP thì không đòi hỏi.
Khác nhau
Sự khác biệt đáng kể giữa RUP và XP là RUP hướng đến những dự án lớn hơn so với XP và vì thế,
nó phức tạp hơn.
Chi phí cho thay đổi và rủi ro:
RUP cho rằng chi phí thay đổi tăng theo hàm mũ và tập trung vào cho những bước đầu tiên để giảm
thiểu những chi phí về sau trong quá trình phát triển phần mềm. RUP quan tâm nhiều đến việc giảm
thiểu rủi ro, theo dõi để tìm kiếm rủi ro và tiếp cận mục tiêu này từng bước từ quá trình xây dựng
kiến trúc đến các quá trình phát triển phần mềm sau này.
XP cho rằng chi phí thay đổi không lớn lắm. XP cũng được xây dựng với mục tiêu giảm thiểu rủi ro
(rủi ro ở đây định nghĩa là “những vấn đề cơ bản”) và hướng tới một thiết kế và kiến trúc tốt cũng
như với mục tiêu trước tiên là cho ra lò những chức năng quan trọng nhất. Tuy nhiên, với sự giả
định là giá cho sự thay đổi thấp, kiến trúc của phần mềm được phép phát triển một cách hữu cơ, như
một bộ xương chỉ cần phát triển vừa đủ để nâng đỡ cơ thể tại thời điểm nhất định. Điều then chốt
trong XP là sự đơn giản.
3.2. Vòng đời của một dự án RUP
Từ phương diện quản lý, vòng đời của một phần mềm theo RUP được chia theo thời gian qua
bốn giai đoạn nối tiếp nhau, mỗi giai đoạn có một mốc quan trọng, mỗi giai đoạn thực chất là
khoảng giữa của 2 điểm mốc. Cuối mỗi giai đoạn, bộ phận kiểm định sẽ thực hiện thẩm định các
đối tượng của giai đoạn này, nếu việc kiểm tra thích hợp thì dự án sẽ được chuyển sang giai đoạn
tiếp theo.
14
3.2.1 Khởi tạo (Inception)
Trong giai đoạn khởi động cần đưa ra tình huống về mặt nghiệp vụ có thể có đối với hệ thống
và xác định phạm vi của dự án. Các tình huống nghiệp vụ gồm: đánh giá sự thành công, đánh giá
rủi ro, xác định các nguồn lực cần thiết cho dự án và một bản kế hoạch tóm tắt chỉ ra lịch trình của
các điểm mốc chủ yếu của dự án, rủi ro của các yêu cầu, các chức năng nghiệp vụ cũng phải được
chỉ ra trước khi dự án bắt đầu.
Trong giai đoạn này cũng đề cập đến việc cải tiến từ các hệ thống đã có, tuy nhiên vẫn chỉ tóm
tắt, giai đoạn này chú trọng đến cả 2 điều quan trọng của dự án: đáng để làm hay không và khả năng
thực hiện.
Cuối giai đoạn này cần kiểm tra các mục tiêu của quá trình phát triển của dự án và quyết định có
tiếp tục quá trình phát triển hay không. Kết quả của giai đoạn này là đạt được sự nhất trí giữa tất cả
những người đóng vai trò chủ chốt về các mục tiêu của dự án.
-
Mục tiêu chính của giai đoạn Inception:
Thiết lập phạm vi phần mềm và các điều kiện biên của dự án, bao gồm: nhìn nhận khả năng
thực hiện, các điều kiện thỏa thuận và những gì sản phẩm mong đợi và không mong đợi
Nhận định đúng đắn về các chức năng của hệ thống, kịch bản của các hành vi trong hệ thống sẽ
đóng vai trò định hướng quan trọng cho kết quả của phần thiết kế.
Trình bày, demo một số kiến trúc ứng cử viên cho một vài kịch bản chính. Dự trù tất cả chi phí, lập
kế hoạch cho toàn bộ dự án.
Dự trù các rủi ro tiềm ẩn.
Chuẩn bị môi trường hỗ trợ cho dự án.
15
3.2.2 Phác thảo (Elaboration)
Kết quả của giai đoạn này là tạo ra một baseline cho kiến trúc của hệ thống, tạo cơ sở cho quá
trình thiết kế và thực thi trong giai đoạn construction. Kiến trúc này mở rộng việc phân tích các yêu
cầu quan trọng của hệ thống (các yêu cầu có sự ảnh hưởng lớn đến hệ thống) và đánh giá các rủi ro.
Sự ổn định của kiến trúc được đánh gia qua nhiều nguyên bản của kiến trúc.
Mục tiêu của giai đoạn này là phân tích các vấn đề nghiệp vụ, xác định kiến trúc hợp lý, xây
dựng kế hoạch cho dự án, giới hạn các yếu tố rủi ro cao nhất. Những quyết định về mặt kiến trúc
cần được đưa ra cho toàn bộ hệ thống, đồng thời cần mô tả hầu hết các yêu cầu của hệ thống.
Cuối giai đoạn này cần kiểm tra các mục tiêu và phạm vi chi tiết của hệ thống, sự lựa chọn về
kiến trúc và cách xử lý các rủi ro có thể đồng thời quyết định có tiếp tục chuyển sang giai đoạn xây
dựng hay không.
3.2.3 Xây dựng (Construction)
Trong giai đoạn này bạn phát triển một cách tái lập và tăng dần toàn bộ sản phẩm đầy đủ, xây
dựng sản phầm và phát triển các phiên bản, kiến trúc, các kế hoạch cho đến khi đạt được phiên bản
hoàn thiện nhất sẵn sàng chuyển giao tới người sử dụng. Giai đoạn này bao gồm việc mô tả các yêu
cầu còn lại chưa được xác định, xác định các tiêu chuẩn, làm mịn thiết kế và hoàn thành việc lập
trình ứng dụng.
Cuối giai đoạn này cần xác định liệu hệ thống phần mềm, các điểm triển khai và người dùng đã
sẵn sàng đi vào hoạt động chưa để có thể chuyển giao cho người dùng.
Giai đoạn này sẽ được kết luận dựa vào các mốc là khả năng thực hiện các chức năng yêu cầu
ban đầu đã xác định.
16
3.2.4 Chuyển giao (Transition)
Trong giai đoạn này, cần đưa hệ thống phần mềm tới người sử dụng. Khi hệ thống đã tới tay
người sử dụng thì các vấn đề thường phát sinh đòi hỏi những bước tiếp theo là căn chỉnh hệ thống,
xác định các vấn đề chưa được phát hiện trước đó hay hoàn thiện các chức năng trước đó bị trì
hoãn. Giai đoạn này thường bắt đầu với việc tung ra phiên bản Beta và sau đó là thay thế bởi bản
chương trình đầy đủ.
Chuyển giao sản phẩm cho những người sử dụng bao gồm: hoàn chỉnh sản phẩm, phân phối,
huấn luyện, hỗ trợ và bảo trì cho đến khi người sử dụng hài lòng.
Giai đoạn này được kết luận thông qua mốc các phiên bản của sản phẩm, kết thúc từng chu trình
lặp của giai đoạn này.
3.3. Các luồng công việc chính trong RUP
3.3.1 Mô hình hoá nghiệp vụ (Business modeling)
Mô tả cấu trúc và quy trình nghiệp vụ. Mục tiêu của mô hình hoá nghiệp vụ là:
- Hiểu được vấn đề đang tồn tại trong tổ chức và đề xuất cải tiến
17
- Để đảm bảo khách hàng, người dùng cuối, người phát triển có sự hiểu biết thống nhất về hệ thống
- Để tìm ra những yêu cầu hệ thống cần thiết
Các ký hệu quy ước cho mô hình hoá nghiệp vụ
3.3.2 Quản lý yêu cầu (Requirements management)
Mô tả nghiệp vụ bằng phương pháp “tình huống sử dụng” (use case base method). Mục tiêu của
luồng công việc này là:
- Thiết lập và duy trì sự đúng đắn về yêu cầu của khách hàng hoặc các nhân tố khác về những
gì mà hệ thống sẽ thực hiện
- Giúp cho người phát triển hiểu rõ hơn về những yêu cầu của hệ thống
- Xác định giới hạn của hệ thống
- Giúp cho việc ước lượng thời gian và chi phí phát triển hệ thống
Các yêu cầu của hệ thống bao gồm yêu cầu về chức năng và yêu cầu ngoài chức năng (độ tin cậy,
hiêu suất, sự hỗ trợ,..).
19
Biểu đồ luồng công việc Phân tích và thiết kế
20
3.3.4 Cài đặt (Implementation)
Thực hiện các việc xây dựng chương trình bằng ngôn ngữ lập trình. Mụch đích của luồng công việc
này là:
- Xác định cách thức viết mã cài đặt
- Cài đặt các lớp và đối tượng như là các thành phần
- Tích hợp vào trong một hệ thống có thể thực thi được
Những người thực hiện và các tài liệu
Tải về để xem bản đầy đủ
40 trang
14120
Free
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Quy trình phát triển phần mềm - Trường Đại học Hàng Hải", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- giao_trinh_quy_trinh_phat_trien_phan_mem_truong_dai_hoc_hang.pdf
