Bài giảng Công nghệ phần mềm - Lê Nguyễn Tuấn Thành

 hơn
Thời gian phát triển
bị ước lượng quá
thấp
Xem xét mua thêm thành phần, xem xét sửa dụng một trình
tạo mã chương trình tự động
Giám sát rủi ro
(Risk monitoring)
79
 Đánh giá thường xuyên từng rủi ro để quyết định liệu nó
đang trở nên ít xảy ra hơn hay ngược lại
 Đánh giá liệu ảnh hưởng của rủi ro có thay đổi không
 Mỗi rủi ro chính nên được thảo luận tại các buổi họp
quản lý tiến trình
Tóm tắt Quản lý dự án phần mềm (1/2)
80
 Quản lý dự án tốt là cần thiết cho sự thành công của dự
án
 Bản chất phi vật thể của phần mềm gây khó khăn cho
việc quản lý
 Những nhà quản lý có vai trò đa dạng nhưng những hoạt
động quan trọng nhất của họ là:
 lập kế hoạch (planning),
 ước lượng (estimating) và
 lập lịch trình (scheduling)
 Lập kế hoạch và ước lượng là những quá trình lặp lại
được tiếp tục trong suốt quá trình thực hiện dự án
Tóm tắt Quản lý dự án phần mềm (2/2)
81
 Một cột mốc (milestone) dự án là một trạng thái có thể
dự đoán được, tại đó một báo cáo chính thức về tiến độ
được trình bày cho ban quản lý
 Lập lịch trình dự án liên quan đến chuẩn bị những biểu
diễn đồ họa khác nhau để hiển thị những hoạt động của
dự án, khoảng thời gian và nhân sự
 Quản lý rủi ro liên quan đến xác định những rủi ro có thể
ảnh hưởng đến dự án và lập kế hoạch để đảm bảo rằng
những rủi ro này không trở thành những các mối đe dọa
lớn
4. Quy trình Phần mềm
Software Processes
82
Mục tiêu
83
 Giới thiệu những mô hình quy trình phát triển phần mềm
 Mô tả những mô hình quy trình chung và khi nào chúng
có thể được sử dụng
 Mô tả phác thảo những mô hình quy trình cho yêu cầu kỹ
thuật (requirement engineering), phát triển phần mềm
(software development), kiểm thử (testing) và tiến hóa
(evolution)
 Giải thích mô hình RUP (Rational Unified Process)
 Giới thiệu công nghệ CASE để hỗ trợ những hoạt động
tiến trình phần mềm
Chủ đề được đề cập
(Topics covered)
84
 Những mô hình quy trình phần mềm (Software Process
Models)
 Quy trình lặp (Process Iteration)
 Những hoạt động trong quy trình (Process Activities)
 RUP (Rational Unified Process)
 CASE (Computer-aided Software Engineering)
Quy trình phần mềm là gì?
85
 Một tập các hành động có cấu trúc mà mục
đích của chúng là sự phát triển hoặc tiến hóa
của phần mềm.
Mô hình Quy trình Phần mềm
(Software Process Model)
86
 Một mô hình quy trình phần mềm là một biểu diễn
trừu tượng được đơn giản hóa của quy trình phần
mềm.
 Trình bày miêu tả về một vài khía cạnh cụ thể của quy trình.
 Khía cạnh luồng công việc (workflow perspective): chuỗi
những hành động trong quy trình;
 Khía cạnh luồng dữ liệu (data-flow perspective): luồng
thông tin trong quy trình
 Khía cạnh vai trò (role/action perspective): ai làm việc gì
trong quy trình
Những Mô hình Quy trình Phần mềm
87
 Mô hình thác nước (waterfall)
 Tuần tự, tách biệt và làm rõ những giai đoạn của đặc tả và phát
triển
 Phát triển tiến hóa (evolutionary development)
 Các giai đoạn đặc tả, phát triển và kiểm chứng được xen kẽ
nhau
 Mô hình dựa trên thành phần (component-based)
 Hệ thống được lắp ráp từ những thành phần sẵn có
 Mô hình phát triển lặp (iterative development)
Mô hình Thác nước
(Waterfall)
88
Mô hình Thác nước
(Waterfall)
89
Mô hình thác nước:
Các giai đoạn
90
1. Phân tích và định nghĩa yêu cầu (Requirement analysis &
definition)
2. Thiết kế hệ thống và phần mềm (System & software
design)
3. Cài đặt và kiểm thử đơn vị (Implementation & unit
testing)
4. Tích hợp và kiểm thử hệ thống (Integration & system
testing)
5. Vận hành và kiểm thử (Operation & maintenance)
Mô hình thác nước:
Phân tích
91
 Yếu điểm chính: khó khăn trong việc thích ứng với thay
đổi sau khi tiến trình đã được tiến hành.
 Một giai đoạn phải được hoàn thành trước khi chuyển sang giai
đoạn tiếp theo
 Phải chờ đợi lâu trước khi có sản phẩm cuối
 Chỉ thích hợp khi những yêu cầu được hiểu rõ và
những thay đổi sẽ bị giới hạn trong tiến 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.
 Mô hình này hầu như được sử dụng cho những dự án kỹ
thuật hệ thống lớn
Mô hình chữ V
(V Model)
92
Mô hình Phát triển Tiến hóa
(Evolutionary Development)
93
 Ý tưởng:
 Xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét,
 Sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thỏa
mãn yêu cầu của người sử dụng thì dừng lại
 2 phương pháp:
 Phát triển thăm dò: mục đích là để làm việc với khách hàng và
đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu
 Thường bắt đầu thực hiện với những yêu cầu được tìm hiểu rõ ràng
và sau đó, bổ sung những đặc điểm mới được đề xuất bởi KH
 Loại bỏ mẫu thử: mục đích là để tìm hiểu các yêu cầu của hệ thống
 Thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin.
 Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử
dụng
 Từ đó có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này
mẫu thử không còn cần thiết nữa
Mô hình Phát triển Tiến hóa
Minh họa
94
Mô hình Phát triển Tiến hóa
Phân tích
95
 Vấn đề
 Thiếu tầm nhìn của cả quy trình
 Hệ thống thường hướng cấu trúc nghèo nàn
 Yêu cầu những kỹ năng đặc biệt (ví dụ: về mặt ngôn ngữ để
tạo nguyên mẫu nhanh)
 Tính ứng dụng:
 Cho những hệ thống tương tác vừa và nhỏ
 Cho những phần (module) của hệ thống lớn (ví dụ: giao diện
người dùng)
 Cho những hệ thống có vòng đời ngắn
Mô hình dựa trên thành phần
(Component-based Software Engineering)
96
 Dựa trên việc tái sử dụng có hệ thống,
 Hệ thống được tích hợp từ những thành phần sẵn có hoặc từ
những hệ thống COTS (Commercial-off-the-shelf)
 Những giai đoạn:
 Phân tích thành phần
 Thay đổi yêu cầu
 Thiết kế hệ thống với việc sử dụng lại
 Phát triển và tích hợp
 Cách tiếp cận này đang ngày càng được sử dụng nhiều khi
các tiêu chuẩn thành phần được đưa vào sử dụng
Phát triển hướng Tái sử dụng
(Reuse-oriented development)
97
Quy trình lặp
(Process iteration)
98
 Các yêu cầu hệ thống LUÔN LUÔN tiến hóa trong quá
trình thực hiện dự án
 vì thế lặp quy trình luôn là một phần của quy trình cho những
hệ thống lớn
 Quá trình lặp có thể được áp dụng với bất kỳ mô hình
quy trình chung nào
 Hai cách tiếp cận liên quan
 Phân phối gia tăng (incremental delivery)
 Phát triển xoắn ốc (spiral development)
Mô hình Bản mẫu
(Prototyping Model)
99
Phân phối gia tăng
(Incremental delivery)
100
 Thay vì phát triển và phân phối hệ thống một lần, sự
phát triển và phân phối được chia ra thành nhiều
vòng, tăng dần, gọi là các gia số (increment)
 Mỗi gia số phân phối một tập con các chức năng được yêu
cầu
 Những yêu cầu người dùng được sắp ưu tiên và yêu cầu ưu
tiên cao nhất được bao gồm trong những gia số đầu tiên
Phát triển gia tăng
(Incremental development)
101
Phát triển gia tăng
(Incremental development)
102
Phát triển gia tăng
Ưu điểm
103
 Khách hàng không phải đợi cho đến khi toàn bộ hệ
thống được phân phối trước khi có thể thu được giá
trị từ nó.
 Những gia số bước đầu giống như một nguyên mẫu để
giúp phát hiện những yêu cầu cho những gia số bước sau
 Bản phát hành đầu tiên sẽ thỏa mãn hầu hết những
yêu cầu quan trọng nhất của KH
 KH có thể sử dụng phần mềm ngay lập tức
 Những dịch vụ hệ thống có độ ưu tiên cao nhất được
phân phối trước tiên, và có xu hướng nhận được kiểm
thử nhiều nhất
 Nguy cơ thất bại toàn bộ dự án thấp hơn
Mô hình phát triển xoắn ốc
(Spiral development)
104
 Được biểu diễn theo một hình xoắn ốc thay vì một
chuỗi tuần tự những hành động với cơ chế truy vết
ngược
 Mỗi vòng lặp trong sơ đồ xoắn ốc biểu diễn một pha của
quy trình
 Không có những pha cố định như đặc tả hay thiết kế -
những vòng lặp trong sơ đồ xoắn ốc được chọn dựa vào
điều gì được yêu cầu
 Rủi ro được đánh giá và giải quyết trong suốt quy trình
Những Hoạt động của Mô hình xoắn ốc
(Spiral model sectors)
105
 Thiết lập mục tiêu (objective setting)
 Các mục tiêu cụ thể của từng pha được xác định
 Đánh giá và giảm thiểu rủi ro
 Rủi ro được đánh giá và những hành động được đưa ra để
giảm thiểu những rủi ro chính
 Phát triển và đánh giá
 Một mô hình phát triển cho hệ thống được chọn
 Lập kế hoạch
 Dự án được đánh giá và giai đoạn tiếp theo của vòng xoắn
được lên kế hoạch
Mô hình Xoắn ốc
(Boehm – IEEE 1988)
106
Phát triển Phần mềm Linh hoạt
(Agile Development)
107
SCRUM (1/2)
SCRUM (2/2)
Nhắc lại:
Những Hoạt động chung trong Quy trình PM
110
 Đặc tả phần mềm (software specification)
 Thiết kế và cài đặt phần mềm (software design and
implementation)
 Xác thực phần mềm (software validation)
 Tiến hóa phần mềm (software evolution)
Đặc tả Phần mềm
(Software specification)
111
 Quá trình thiết lập những dịch vụ gì được yêu cầu và
những rằng buộc với thao tác và phát triển hệ thống
 Quy trình kỹ thuật tạo yêu cầu (requirements
engineering process)
 Nghiên cứu khả thi (feasibility study)
 Đưa ra và Phân tích yêu cầu (requirements elicitation &
analysis)
 Đặc tả yêu cầu (requirements specification)
 Xác thực yêu cầu (requirements validation)
Yêu cầu kỹ thuật
(Requirements engineering process)
112
Thiết kế và Cài đặt Phần mềm
(Software design and implementation)
113
 Là quá trình của việc chuyển những đặc tả hệ thống thành
một hệ thống có thể chạy được
 Thiết kế phần mềm
 Thiết kế một cấu trúc phần mềm phù hợp với đặc tả
 Cài đặt phần mềm
 Chuyển cấu trúc này thành một chương trình có thể chạy
được
 Những hoạt động thiết kế và cài đặt có liên hệ gần gũi
với nhau và có thể đan xen
Những Hoạt động trong Quá trình Thiết kế
(Design process activities)
114
 Thiết kế kiến trúc (architectural design)
 Đặc tả trừu tượng (abstract specification)
 Thiết kế giao diện (interface design)
 Thiết kế thành phần (component design)
 Thiết kế cấu trúc dữ liệu (data structure design)
 Thiết kế thuật toán (algorithm design)
Quá trình Thiết kế Phần mềm
(Software design process)
115
Những Phương pháp có cấu trúc
(Structured methods)
116
 Là những cách tiếp cận có hệ thống để phát triển một
thiết kế phần mềm
 Thiết kế thường được tài liệu hóa như một tập các mô
hình đồ họa
 Các mô hình có thể là:
 Mô hình đối tượng (object model)
 Mô hình trình tự (sequence model)
 Mô hình chuyển trạng thái (state transition model)
 Mô hình cấu trúc (structural model)
 Mô hình luồng dữ liệu (data-flow model)
Lập trình và Gỡ rối
(Programing and Debugging)
117
 Là quá trình chuyển từ thiết kế thành chương trình và
loại bỏ lỗi (errors) từ chương trình đó
 Lập trình là một hoạt động cá nhân – không có tiến trình
lập trình chung
 Lập trình viên thực hiện một vài kiểm thử chương trình
để phát hiện lỗi (faults) trong chương trình và loại bỏ
những lỗi này trong quá trình gỡ rối (debugging)
Quá trình Gỡ rối
(Debugging process)
118
Xác thực Phần mềm
(Software validation)
119
 Xác minh và xác thực (verification & validation – V & V)
được dự định để chỉ ra rằng một hệ thống phù hợp với
đặc tả của nó và tuân theo những yêu cầu của khách hàng
 Liên quan đến việc kiểm tra và xem xét lại những quá
trình và kiểm thử hệ thống
 Kiểm thử hệ thống liên quan đến chạy hệ thống với
những trường hợp thử nghiệm (test cases), được bắt
nguồn từ đặc tả của dữ liệu thật được xử lý bởi hệ thống
Quy trình Kiểm thử
(Testing process)
120
Những Giai đoạn Kiểm thử
(Testing stages)
121
 Kiểm thử thành phần hay kiểm thử đơn vị (Component
or unit testing)
 Những thành phần cá nhân được kiểm thử độc lập
 Thành phần có thể là những hàm hoặc những đối tượng hoặc
những nhóm kết hợp (coherent groups) của những thực thể
này
 Kiểm thử hệ thống (System testing)
 Kiểm thử cả hệ thống như một toàn thể. Kiểm thử những đặc
tính khẩn cấp (emergent properties) là cực kỳ quan trọng
 Kiểm thử chấp nhận (Acceptance testing)
 Kiểm thử với dữ liệu khách hàng để kiểm tra xem hệ thống có
tuân theo những nhu cầu của khách hàng không
Các pha Kiểm thử
(Testing phases)
122
Giới thiệu về
Mô hình RUP và công cụ CASE
123
RUP (1/2)
(Rational Unified Process)
124
 Một mô hình quy trình hiện đại xuất phát từ công việc
trên UML và quá trình liên quan
 Thông thường RUP được miêu tả với 3 khía cạnh
(perspectives)
1. Khía cạnh động (dynamic perspective): hiển thị những giai
đoạn theo thời gian
2. Khía cạnh tĩnh (static perspective): hiển thị những hành động
của quy trình
3. Khía cạnh thực hành (pratice perspective): gợi ý thực hành
tốt
RUP (2/2)
125
Mô hình giai đoạn của RUP
126
Cái giai đoạn của RUP
127
 Khởi đầu (Inception)
 Thiết lập các trường hợp nghiệp vụ (business case) cho hệ
thống
 Nghiên cứu (Elaboration)
 Phát triển hiểu biết về miền vấn đề (problem domain) và kiến
trúc hệ thống
 Xây dựng (Construction)
 Thiết kế hệ thống, lập trình và kiểm thử
 Chuyển đổi (Transition)
 Triển khai (deploy) hệ thống trong môi trường vận hành của
nó
Thực hành với mô hình RUP
(RUP good practice)
128
 Phát triển phần mềm lặp nhiều lần
 Quản lý yêu cầu
 Sử dụng kiến trúc dựa trên thành phần
 Trực quan hóa mô hình phần mềm
 Xác thực chất lượng phần mềm
 Kiểm soát sự thay đổi với phần mềm
Quy trình công việc tĩnh (1/2)
(Static workflows)
129
Luồng công việc Miêu tả
Mô hình hóa nghiệp vụ
(Business modelling)
Quy trình nghiệp vụ được mô hình hóa sử dụng các trường hợp
nghiệp vụ (business use cases)
Yêu cầu (requirements) Các tác nhân tương tác với hệ thống được xác định và các trường
hợp (use cases) được phát triển để mô hình hóa yêu cầu hệ thống
Phân tích và thiết kế
(Analysis and design)
Một mô hình thiết kế được tạo ra và tài liệu hóa sử dụng những mô
hình kiến trúc, mô hình thành phần, mô hình đối tượng và mô hình
tuần tự (sequence models)
Cài đặt (Implementation) Những thành phần trong hệ thống được cài đặt và cấu trúc vào
những hệ thống con. Quá trình sinh mã tự động từ những mô hình
thiết kế giúp đẩy nhanh quá trình này
Kiểm thử (Testing) Kiểm thử là một quá trình lặp lại, được tiến hành kết hợp với quá
trình cài đặt. Kiểm thử hệ thống theo thực hiện sau khi hoàn thành
việc cài đặt
Triển khai (Deployment) Một bản phát hành của sản phẩm được tạo ra, phân phối tới người
dùng và cài đặt vào nơi làm việc của họ
Quy trình công việc tĩnh (2/2)
(Static workflows)
130
Luồng công việc Miêu tả
Quản lý cấu hình và sự
thay đổi (Configuration
and change management)
Luồng công việc phụ trợ này quản lý những thay đổi của hệ thống
Quản lý dự án (Project 
management)
Luồng công việc phụ trợ này quản lý phát triển hệ thống
Môi trường (Environment) Luồng công việc này liên quan đến việc tạo những công cụ phần
mềm thích hợp sẵn sàng cho nhóm phát triển sử dụng
CASE là gì? (1/2)
(Computer-Aided Software Engineering)
131
 CASE là những hệ thống phần mềm hỗ trợ cho quá trình
phát triển và tiến hóa phần mềm
 Tự động hóa hoạt động (activity automation)
 Trình soạn thảo bằng đồ họa (graphical editors) cho quá trình
phát triển mô hình hệ thống
 Từ điển dữ liệu (data dictionary) để quản lý những thực thể
trong thiết kế (design entities)
 Trình tạo giao diện đồ họa (graphical UI builder) cho việc xây
dựng giao diện người dùng
 Trình gỡ rối (debuggers) để hỗ trợ việc tìm lỗi chương trình
(program fault)
 Trình dịch tự động (automated translators) để tạo những phiên
bản mới cho chương trình
CASE là gì? (2/2)
(Computer-Aided Software Engineering)
132
 CASE thường được dùng cho hỗ trợ phương pháp
 Upper-CASE:
 Những công cụ hỗ trợ những hành động tiến trình ở giai đoạn
đầu: xác định yêu cầu (requirements) và thiết kế (design)
 Lower-CASE:
 Những công cụ hỗ trợ những hành động ở giai đoạn sau như:
lập trình (programming), debugging và testing
Công nghệ CASE
133
 Công nghệ CASE dẫn tới những cải tiến đáng kể trong
tiến trình phần mềm. Tuy nhiên đây không phải là những
cải tiến lớn như đã từng được dự đoán
 Công nghệ phần mềm đòi hỏi phải có tư duy sáng tạo – điều
này không dễ dàng có thể được tự động hóa
 Công nghệ phần mềm là một hoạt động nhóm và với những dự
án lớn, phải sử dụng nhiều thời gian trong việc tương tác nhóm.
Công nghệ CASE không thực sự hỗ trợ điều này
Phân loại CASE
(CASE classification)
134
 Sự phân loại giúp chúng ta hiểu những kiểu khác nhau của
công cụ CASE và những hỗ trợ của chúng cho hoạt động
tiến trình
 Khía cạnh chức năng (functional perspective)
 Phân loại dựa theo chức năng cụ thể của chúng
 Khía cạnh quy trình (process perspective)
 Phân loại dựa theo những hoạt động quy trình được hỗ trợ
 Khía cạnh tích hợp (integration perspective)
 Phân loại dựa theo tổ chức của chúng trong những đơn vị
được tích hợp
Phân loại công cụ chức năng (1/2)
(Functional tool classification)
135
Kiểu công cụ Ví dụ
Công cụ lập kế hoạch Công cụ PERT, công cụ ước lượng, bảng tính (spreadsheet)
Công cụ soạn thảo Trình soạn thảo văn bản, biểu đồ, bộ xử lý từ ngữ
Công cụ quản lý sự
thay đổi
Công cụ truy xuất yêu cầu, hệ thống kiểm soát sự thay đổi
Công cụ quản lý cấu 
hình
Hệ thống quản lý phiên bản, công cụ xây dựng hệ thống
Công cụ tạo nguyên 
mẫu
Ngôn ngữ ở mức rất cao, bộ tạo giao diện người dùng
Ngôn ngữ hỗ trợ
phương thức
Trình thiết kế, từ điển dữ liệu, bộ sinh mã
Công cụ xử lý ngôn 
ngữ
Trình biên dịch (compilers), trình thông dịch (interpreters)
Công cụ phân tích 
chương trình
Bộ tạo tham chiếu chéo, trình phân tích tĩnh, trình phân tích 
động
Phân loại công cụ chức năng (2/2)
(Functional tool classification)
136
Kiểu công cụ Ví dụ
Công cụ kiểm thử Bộ tạo dữ liệu kiểm thử, trình so sánh tệp tin
Công cụ gỡ rối Hệ thống gỡ rối tương tác
Công cụ tài liệu hóa Chương trình bố trí trang, trình xử lý hình ảnh
Công cụ tái kỹ thuật Hệ thống tham chiếu chéo, hệ thống tái cấu trúc chương 
trình
Phân loại công cụ dựa trên hành động
(Activity-based tool classification)
137
Tích hợp CASE
(CASE integration)
138
 Công cụ
 Hỗ trợ những tác vụ quy trình cá nhân như kiểm tra tính nhất
quán của thiết kế, soạn thảo văn bản,
 Workbench
 Hỗ trợ một giai đoạn quy trình như đặc tả, thiết kế. Thường
bao gồm một số lượng công cụ được tích hợp
 Môi trường
 Hỗ trợ tất cả hoặc phần lớn của toàn bộ quy trình phần mềm.
Thường bao gồm nhiều workbench được tích hợp
Công cụ, Workbench, Môi trường
139
Tóm tắt Quy trình Phần mềm (1/2)
(Key points)
140
 Quy trình phần mềm là những hoạt động liên quan đến
việc tạo ra và tiến hóa một hệ thống phần mềm
 Mô hình quy trình phần mềm là những biểu diễn trừu
tượng của những quy trình này
 Những hoạt động chung là: đặc tả, thiết kế và cài đặt,
xác thực và tiến hóa
 Những mô hình quy trình chung miêu tả tổ chức của
những quy trình phần mềm. Ví dụ: mô hình thác nước,
mô hình phát triển tiến hóa và mô hình kỹ thuật
phần mềm dựa trên thành phần
 Những mô hình quy trình lặp miêu tả tiến trình phần
mềm như một vòng tròn của những hành động
Tóm tắt Quy trình Phần mềm (2/2)
(Key points)
141
 Kỹ thuật tạo yêu cầu là một quá trình của việc phát triển đặc
tả phần mềm
 Quá trình thiết kế và cài đặt chuyển đổi đặc tả thành một
chương trình có thể chạy được
 Xác thực (validation) liên quan đến đảm bảo rằng hệ thống
đáp ứng đặc tả của nó và yêu cầu người dùng
 Tiến hóa liên quan đến thay đổi hệ thống sau khi nó đã đi vào
hoạt động
 RUP là một mô hình quy trình chung để phân chia các hành
động theo các giai đoạn
 Công cụ CASE là những hệ thống phần mềm được thiết kế để
hỗ trợ những hoạt động thông thường trong quy trình phần
mềm như: soạn thảo sơ đồ thiết kế, kiểm tra tính nhất quán của
sơ đồ, lưu vết những thử nghiệm chương trình được chạy 
Tài liệu Tham khảo
142
 Giáo trình chính: Software Engineering, Ian
Sommerville, 8th Edition, 2007
 Tham khảo:
 Object-Oriented Software Engineering Practical Software
Development using UML and Java, Lloseng.com,
Lethbridge/Laganièr,2001
 Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm,
PhạmThị Quỳnh