hermione_1010

New Member

Download miễn phí Bài giảng Kỹ nghệ phần mềm





Mục lục
1 Phần mềm và kỹ nghệ phần mềm 1
1.1 Tầmquantrọngvàsựtiếnhóacủaphầnmềm . 1
1.1.1 Tiến hóa của phần mềm . . 1
1.1.2 Sự ứng dụng của phần mềm . 2
1.2 Khókhăn,tháchthứcđốivớipháttriểnphầnmềm. 4
1.2.1 Phần mềm và phần mềm tốt. 4
1.2.2 Đặc tr-ngpháttriểnvàvậnhànhphầnmềm . 5
1.2.3 Nhu cầu và độ phức tạp . 6
1.3 Kỹnghệphầnmềm. . 7
1.3.1 Định nghĩa . . . . . . . . . 7
1.3.2 Mô hình vòng đời cổ điển. 8
1.3.3 Mô hình làm bản mẫu . . . . 9
1.3.4 Mô hình xoắn ốc . . . . . . . 10
1.3.5 Kỹ thuật thế hệ thứ t- . 11
1.3.6 Mô hình lập trình cực đoan . . 12
1.3.7 Tổ hợp các mô hình . . . . . 13
1.3.8 Tính khả thị của quá trình kỹ nghệ . . . . . . . . . . . . . . . . 14
1.3.9 Vấnđềgiảmkíchcỡcủaphầnmềm . 14
1.4 Cái nhìn chung về kỹ nghệ phầnmềm . 15
2 Phântíchvàđặc tả yêucầu 18
2.1 Đại c-ơngvềphântíchvàđặc tả . . 18
2.2 Nghiên cứu khả thi . . . . . . . . 19
2.3 Nền tảng của phân tích yêu cầu . . 21
2.3.1 Các nguyên lý phân tích . 21
2.3.2 Mô hình hóa . . . . . . . . . 21
2.3.3 Ng-ờiphântích . . 24
2.4 Xác định và đặc tả yêu cầu . 24
2.4.1 Xác định yêu cầu . . . . . 24
2.4.2 Đặctảyêucầu . 25
2.4.3 Thẩm định yêu cầu . . . . . . 26
2.5 Làm bản mẫu trong quá trình phântích. . 26
2.5.1 Các b-ớclàmbảnmẫu. . 27
2.5.2 Lợi ích và hạn chế của phát triển bản mẫu . . . . . . . . . . . . 27
2.6 Địnhdạngđặc tả yêucầu . . 28
3 Thiết kế phần mềm 32
3.1 Khái niệm về thiết kế phầnmềm . . 32
3.1.1 Kháiniệm . . 32
3.1.2 Tầm quan trọng . . . . . . . 32
3.1.3 Quá trình thiết kế . . . 33
3.1.4 Cơ sở của thiết kế . . . . 34
3.1.5 Môtảthiếtkế . 35
3.1.6 Chất l-ợngthiếtkế. . 36
3.2 Thiết kế h-ớngchứcnăng . . . 39
3.2.1 Cách tiếp cận h-ớng chức năng . . . . . . 39
3.2.2 Biểu đồ luồng dữ liệu . 40
3.2.3 L-ợcđồcấutrúc. 40
3.2.4 Các từ điển dữ liệu . . . 40
3.3 Thiết kế h-ớng đối t-ợng. . 40
3.3.1 Cách tiếp cận h-ớng đối t-ợng . . 40
3.3.2 Ba đặc tr-ng của thiết kế h-ớng đối t-ợng . . 41
3.3.3 Cơ sở của thiết kế h-ớng đối t-ợng. . 41
3.3.4 Các b-ớcthiếtkế. 42
3.3.5 Ưu nh-ợc điểm của thiết kế h-ớng đối t-ợng . 42
3.3.6 Quan hệ giữa thiết kế và lập trình h-ớng đối t-ợng . . 43
3.3.7 Quan hệ giữa thiết kế h-ớng đối t-ợng và h-ớng chức năng . . 43
3.4 Thiết kế giao diện ng-ời sử dụng . . . . . . . . 44
3.4.1 Một số vấn đề thiết kế . 45
3.4.2 Một số h-ớngdẫnthiếtkế. . 46
4Lậptrình 48
4.1 Ngônngữlậptrình . . 48
4.1.1 Đặc tr-ngcủangônngữlậptrình . 48
4.1.2 Lựa chọn ngôn ngữ lập trình . . 49
4.1.3 Ngôn ngữ lập trình và và sự ảnh h-ởng tới kỹ nghệ phần mềm . 50
4.2 Phong cách lập trình . . . . . 50
4.2.1 Tài liệu ch-ơngtrình. . 51
4.2.2 Khai báo dữ liệu . . . . . 51
4.2.3 Xây dựng câu lệnh . . . . 52
4.2.4 Vào/ra. . 52
4.3 Lập trình tránh lỗi . . . . . . 53
4.3.1 Lập trình thứ lỗi . . . . 54
4.3.2 Lập trình phòng thủ . . . 54
4.4 Lập trình h-ớng hiệu quả thực hiện . . . 55
4.4.1 Tính hiệu quả ch-ơngtrình . . 55
4.4.2 Hiệu quả bộ nhớ . . . . . . . 56
4.4.3 Hiệu quả vào/ra . . . . . . 56
5 Xác minh và thẩm định 57
5.1 Đại c-ơng. . 57
5.2 Kháiniệmvềphépthử . . 58
5.3 Thử nghiệm chức năng và thử nghiệm cấu trúc . . . . . . . . . . . . . . 58
5.3.1 Thử nghiệm chức năng . . 58
5.3.2 Thử nghiệm cấu trúc . . . 60
5.4 Quá trình thử nghiệm . . . . 60
5.4.1 Thử nghiệm gây áp lực . . . 61
5.5 Chiến l-ợcthửnghiệm . . 61
5.5.1 Thử nghiệm d-ớilên. . 61
5.5.2 Thử ngiệm trên xuống . . . . 62
6 Quản lý dự án phát triển phần mềm 63
6.1 Đại c-ơng. . 63
6.2 Độđophầnmềm . . 64
6.2.1 Đo kích cỡ phần mềm . . . 64
6.2.2 Độ đo dựa trên thống kê . 65
6.3 Ước l-ợng. . 65
6.4 Quảnlýnhânsự . . . 66
6.5 Quản lý cấu hình . . . . . . . . . 67
6.6 Quảnlýrủiro. . 68



Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí

Tóm tắt nội dung tài liệu:

hiều các từ nh− nhau.
ii) Ngôn ngữ tự nhiên quá mềm dẻo do đó các yêu cầu liên quan đến nhau có thể
đ−ợc biểu diễn bằng các hình thức hoàn toàn khác nhau và ng−ời phát triển không nhận
ra các mối liên quan này.
iii) Các yêu cầu khó đ−ợc phân hoạch một cách hữu hiệu do đó hiệu quả của việc
25
đổi thay chỉ có thể xác định đ−ợc bằng cách kiểm tra tất cả các yêu cầu chứ không phải
một nhóm các yêu cầu liên quan.
Các ngôn ngữ đặc tả (đặc tả hình thức) khắc phục đ−ợc các hạn chế trên, tuy nhiên
đa số khách hàng lại không thông thạo các ngôn ngữ này. Thêm nữa mỗi ngôn ngữ đặc
tả hình thức th−ờng chỉ phục vụ cho một nhóm lĩnh vực riêng biệt và việc đặc tả hình
thức là một công việc tốn kém thời gian.
Một cách tiếp cận là bên cạnh các đặc tả hình thức ng−ời ta viết các chú giải bằng
ngôn ngữ tự nhiên để giúp khách hành dễ hiểu.
2.4.3 Thẩm định yêu cầu
Một khi các yêu cầu đã đ−ợc thiết lập thì cần thẩm định xem chúng có thỏa mãn các
nhu cầu của khách hàng hay không. Nếu thẩm định không đ−ợc tiến hành chặt chẽ thì
các sai sót có thể lan truyền sang các giai đoạn thiết kế và mã hóa khiến cho việc sửa
đổi hệ thống trở nên rất tốn kém.
Mục tiêu của thẩm định là kiểm tra xem yêu cầu mà ng−ời phân tích xác định có
thỏa mãn 4 yếu tố sau không:
1. Thỏa mãn nhu cầu của ng−ời dùng: cần thỏa mãn đ−ợc các nhu cầu bản
chất của ng−ời dùng (khách hàng).
2. Các yêu cầu không đ−ợc mâu thuẫn nhau: với các hệ thống lớn các yêu cầu rất
đa dạng và có khả năng sẽ mâu thuân nhau. Khi đó ng−ời phân tích phải loại bớt các
yêu cầu (không chủ chốt) để sau cho các yêu cầu đ−ợc mô tả trong tài liệu yêu cầu
không mâu thuẫn nhau.
3. Các yêu cầu phải đầy đủ: cần chứa mọi chức năng và ràng buộc mà ng−ời dùng
đã nhắm đến.
4. Các yêu cầu phải hiện thực: yêu cầu phải hiện thực về các khía cạnh kỹ thuật,
kinh tế và pháp lý.
2.5 Làm bản mẫu trong quá trình phân tích
Đối với các hệ thống phức tạp, nhiều khi chúng ta không nắm chắc đ−ợc yêu cầu của
khách hàng, chúng ta cũng khó đánh giá đ−ợc tính khả thi cũng nh− hiệu quả của hệ
thống. Một cách tiếp cận đối với tr−ờng hợp này là xây dựng bản mẫu. Bản mẫu vừa
đ−ợc dùng để phân tích yêu cầu vừa có thể tiến hóa thành sản phẩm cuối cùng.
Bản mẫu phần mềm hoàn toàn khác với bản mẫu phần cứng. Khi phát triển các hệ
thống phần cứng, thì thực tế ng−ời ta phát triển một bản mẫu hệ thống để thẩm định
thiết kế hệ thống. Một bản mẫu hệ thống điện tử có thể đ−ợc thực hiện và đ−ợc thử
nghiệm bằng cách dùng các thành phần ch−a đ−ợc lắp ráp vào vỏ tr−ớc khi đầu t− vào
các mạch tích hợp chuyên dụng đắt tiền để thực hiện một đời sản phẩm mới của hệ
thống. Bản mẫu phần mềm không phải nhằm vào việc thẩm định thiết kế (thiết kế của
nó th−ờng là hoàn toàn khác với hệ thống đ−ợc phát triển cuối cùng), mà là để thẩm
26
định yêu cầu của ng−ời sử dụng.
2.5.1 Các b−ớc làm bản mẫu
Xây dựng bản mẫu bao gồm 6 b−ớc sau:
B−ớc 1: Đánh giá yêu cầu phần mềm và xác định liệu phần mềm cần xây dựng có
xứng đáng để làm bản mẫu không
Không phải tất cả các phần mềm đều có thể đ−a tới làm bản mẫu. Ta có thể xác
định một số nhân tố làm bản mẫu: lĩnh vực ứng dụng, độ phức tạp ứng dụng, đặc tr−ng
khách hàng và đặc tr−ng dự án.
Để đảm bảo tính t−ơng tác giữa khách hàng với bản mẫu, chúng ta cần đảm bảo các
điều kiện:
1. Khách hàng phải cam kết dùng tài nguyên để đánh giá và làm mịn bản mẫu (chi
tiết hóa yêu cầu)
2. Khách hàng phải có khả năng đ−a ra những quyết định về yêu cầu một cách kịp
thời
B−ớc 2: Với một dự án chấp thuận đ−ợc, ng−ời phân tích xây dựng một cách biểu
diễn vắn tắt cho yêu cầu.
Tr−ớc khi có thể bắt đầu xây dựng một bản mẫu, ng−ời phân tích phải biểu diễn
miền thông tin và các lĩnh vực, hành vi và chức năng của vấn đề rồi xây dựng một cách
tiếp cận hợp lý tới việc phân hoạch. Có thể ứng dụng các nguyên lý phân tích nền tảng
(phân tích top-down) và các ph−ơng pháp phân tích yêu cầu.
B−ớc 3: Sau khi đã duyệt xét mô hình yêu cầu, phải tạo ra một đặc tả thiết kế vắn
tắt cho bản mẫu
Việc thiết kế phải xuất hiện tr−ớc khi bắt đầu làm bản mẫu. Tuy nhiên thiết kế tập
trung chủ yếu vào các vấn đề thiết kế dữ liệu và kiến trúc mức đỉnh chứ không tập
trung vào thiết kế thủ tục chi tiết.
B−ớc 4: Phần mềm bản mẫu đ−ợc tạo ra, kiểm thử và làm mịn.
Bản mẫu nên đ−ợc xây dựng một cách nhanh chóng và với một chi phí nhỏ. Một
cách lý t−ởng, bản mẫu nên đ−ợc lắp ráp từ các khối chức năng (th− viện...) đã có. Có
thể dùng các ngôn ngữ bậc cao hay các công cụ tự động để xây dựng bản mẫu.
B−ớc 5: Khách hàng đánh giá và làm mịn yêu cầu
B−ớc này là cốt lõi của cách tiếp cận làm bản mẫu. Chính ở đây mà khách hàng có
thể xem xét cách biểu diễn đ−ợc cài đặt cho yêu cầu phần mềm, gợi ý những thay đổi
làm cho phần mềm đáp ứng tốt hơn với các nhu cầu thực tế.
B−ớc 6: Lặp lại các b−ớc 4 và 5 cho tới khi tất cả các yêu cầu đã đ−ợc hình thức
hóa đầy đủ hay cho tới khi bản mẫu đã tiến hóa thành một phần mềm hoàn thiện.
2.5.2 Lợi ích và hạn chế của phát triển bản mẫu
Phát triển bản mẫu đem lại các lợi ích sau:
27
1. Sự hiểu lầm giữa những ng−ời phát triển phần mềm và những ng−ời sử dụng phần
mềm có thể đ−ợc nhận thấy rõ khi các chức năng của hệ thống đ−ợc trình diễn.
2. Sự thiếu hụt các dịch vụ ng−ời dùng có thể đ−ợc phát hiện.
3. Sự khó sử dụng hay sự nhầm lẫn các dịch vụ ng−ời dùng có thể đ−ợc thấy rõ và
đ−ợc sửa lại.
4. Đội ngũ phát triển phần mềm có thể tìm ra đựơc các yêu cầu không đầy đủ hoặc
không kiên định khi họ phát triển bản mẫu.
5. Một hệ thống hoạt động đ−ợc (mặc dầu là hạn chế) là bằng chứng thuyết minh
cho tính khả thi và tính hữu ích của ứng dụng cho các nhà quản lý.
6. Bản mẫu đó đ−ợc dùng làm cơ sở cho việc viết đặc tả một sản phẩm.
Mặc dù mục tiêu chủ yếu của việc tạo bản mẫu là để phát triển, thẩm định các yêu
cầu phần mềm, nó cũng có các lợi ích khác nh−:
1. Dùng để huấn luyện ng−ời sử dụng ngay từ tr−ớc khi hệ thống đ−ợc phân phối.
2. Dùng trong quá trình thử nghiệm hệ thống. Điều đó nghĩa là cùng các tr−ờng
hợp thử nh− nhau vừa dùng cho thử bản mẫu vừa cho thử hệ thống. Kết quả khác
nhau có nghĩa là có sai sót.
Tạo bản mẫu là một kỹ thuật giảm bớt rủi ro. Một rủi ro lớn trong việc phát triển
phần mềm là các sai sót mà đến giai đoạn cuối mới phát hiện và việc chỉnh sửa vào
thời điểm đó là rất tốn kém. Kinh nghiệm cho thấy việc tạo bản mẫu sẽ giảm bớt số
các vấn đề của đặc tả yêu cầu và giá cả tổng cộng của việc phát triển có thể là thấp
hơn nếu ta phát triển bản mẫu.
Hạn chế của cách tiếp cận tạo bản mẫu là:...
 
Top