Bài giảng Công nghệ phần mềm - Nguyễn Khắc Quốc - Chương 1: Phần mềm và công nghệ phần mềm

 thiện dần.
- Nếu phân tích rủi ro chỉ ra rằng yêu cầu không chắc
chắn thì bản mẫu có thể được sử dụng trong giai đoạn
kỹ nghệ; các mô hình và các mô phỏng khác cũng
được dùng để làm rõ hơn vấn đề và làm mịn yêu cầu.
- Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến
quyết định “tiến hành tiếp hay dừng”.
- Nếu rủi ro quá lớn thì có thể đình chỉ dự án.
1.3.4 Mô hình xoắn ốc (tt)
Mô hình xoắn ốc cũng có một số vấn đề như khó
thuyết phục những khách hàng lớn:
- Cách tiếp cận tiến hóa là kiểm soát được.
- Đòi hỏi tri thức chuyên gia đánh giá rủi ro chính xác.
- Đòi hỏi năng lực quản lý cao
- Mô hình này còn tương đối mới và còn chưa được
sử dụng rộng rãi như vòng đời hoặc làm bản mẫu.
1.3.4 Mô hình xoắn ốc (tt)
- Cho phép người phát triển xác định một số đặc trưng
của phần mềm ở mức cao.
- Tự động sinh ra mã chương trình gốc theo nhu cầu
của người phát triển.
- Mô hình 4GT đối với kỹ nghệ phần mềm tập trung vào
khả năng xác định phần mềm đối với một máy ở mức
độ gần với ngôn ngữ tự nhiên hay dùng một ký pháp
đem lại chức năng có ý nghĩa.
1.3.5 Kỹ thuật thế hệ thứ tư
Môi trường phát triển phần mềm hỗ trợ cho khuôn cảnh
4GT bao gồm một số hay tất cả các công cụ sau:
1. Ngôn ngữ phi thủ tục để truy vấn CSDL
2. Bộ sinh báo cáo
3. Bộ thao tác dữ liệu
4. Bộ tương tác và xác định màn hình
5. Bộ sinh chương trình
6. Khả năng đồ họa mức cao
7. Khả năng làm trang tính
8. Khả năng tạo tài liệu
1.3.5 Kỹ thuật thế hệ thứ tư (tt)
- Lập trình cực đoan (XP - eXtreme Programming) do
Kent Beck đề xuất là một phương pháp tiếp cận mới
cho phát triển phần mềm.
- XP đưa ra nhiều hướng dẫn mới, đôi khi trái ngược
lại với các cách thức phát triển phần mềm được đề
xuất từ trước đến nay.
- Hai khái niệm độc đáo mới và quan trọng hàng đầu
trong XP là:
+ tạo các ca thử nghiệm trước
+ lập trình đôi
1.3.6 Mô hình lập trình cực đoan
a) Tạo các ca thử nghiệm trước
XP thay đổi quan niệm:
- Kiểm thử có tầm quan trọng ngang bằng (có
thể là lớn hơn) việc viết mã.
- Các ca kiểm thử được thiết kế trước khi viết
mã và phải được thực hiện thành công mỗi khi chương
trình đích được tạo ra.
Tạo ca thử nghiệm trước đem lại nhiều lợi thế.
- Giúp bạn xác định một cách rõ ràng giao diện
của modun.
- Yêu cầu phải hiểu một cách rõ ràng các yêu
cầu của modun trước khi bắt tay vào phát triển nó.
1.3.6 Mô hình lập trình cực đoan (tt)
b) Lập trình đôi
- Mã nguồn của một môđun phải được viết bởi 2 lập trình
viên dùng chung một máy tính.
- Giá trị của lập trình đôi là trong khi một người viết mã
thì người thứ hai nghĩ về nó.
- Người thứ hai này sẽ có trong đầu một bức tranh toàn
thể về vấn đề cần giải quyết, chứ không chỉ là giải pháp
của đoạn mã lúc đó.
- Điều này sẽ gián tiếp đảm bảo một chất lượng tốt hơn
và dẫn tới một giải pháp mang tính tổng thể hơn.
- Đồng thời, điều này giúp cho họ theo được các chỉ dẫn
của XP, đặc biệt là việc “tạo ca thử nghiệm trước”.
1.3.6 Mô hình lập trình cực đoan (tt)
- Trong nhiều trường hợp chúng ta nên tổ hợp các mô
hình để đạt được sức mạnh của từng khuôn cảnh cho
một dự án riêng lẻ.
- Chúng ta không nên bị lệ thuộc với bất cứ mô hình cụ
thể nào.
- Tính chất và qui mô của phần mềm cần phát triển sẽ
là yếu tố quyết định tới chọn mô hình.
- Mỗi cách tiếp cận đều có ưu điểm riêng và bằng cách
tổ hợp khéo léo các cách tiếp cận thì sẽ có một
phương pháp hỗn hợp ưu việt hơn các phương pháp
được dùng độc lập.
1.3.7 Tổ hợp các mô hình
Tổng hợp yêu cầu ban đầu
Phân tích yêu 
cầu
Làm bản 
mẫu
4GT Mô hình 
xoắn ốc
Bản mẫu:
Vòng thứ n Mô hình:
Vòng thứ n
4GT
Thiết kế
Mã hóa
Kiểm thử
Hệ thống hoạt động
Bảo trì
4GT
1.3.7 Tổ hợp các mô hình
Tổ hợp các mô hình
Do đặc điểm là các phần tử lôgic nên quá trình phát
triển phần mềm rất khó kiểm soát.
- Người ta tìm cách khắc phục vấn đề này bằng cách
làm cho quá trình phát triển trở nên “nhìn thấy được”
- Tức là ở mỗi bước (hoạt động) trong tiến trình phát
triển phải tạo ra bằng một sản phẩm hay tài liệu tương
ứng.
- Người quản lý dự án và cả khách hàng sẽ tiến hành
xét duyệt các tài liệu này.
- Các tài liệu sẽ trở nên rất hữu ích cho công đoạn kiểm
thử và nâng cấp phần mềm.
1.3.8 Tính khả thị của quá trình
So sánh tính khả thị của các khuôn cảnh:
- Vòng đời cổ điển có tính khả thị cao do các bước phát
triển tường minh, mô hình xoắn ốc cũng có tính khả thị
tốt.
- Đối với mô hình làm bản mẫu, nếu tần số sửa chữa là
lớn thì tính khả thị kém và việc tạo ra tài liệu là không hiệu
quả.
- 4GT thì mới chỉ dùng với những ứng dụng nghiệp vụ đặc
thù nên khó phát biểu gì về tính khả thị của nó.
1.3.8 Tính khả thị của quá trình (tt)
Việc xây dựng tài liệu cũng có những vấn đề:
- Tạo ra các chi phí phụ làm chậm tiến trình phát triển
- Khi phát hiện vấn đề về thiết kế, nhiều khi do không
muốn thay đổi các tài liệu đã được xét duyệt, người
phát triển có xu hướng dùng các giải pháp cục bộ
không hiệu quả.
- Các mô hình phát triển truyền thống thường chú trọng
tới khâu lập tài liệu để nâng cao tính khả thị.
- Ngược lại, mô hình lập trình cực đoan (XP) lại không
khuyến khích việc tạo nhiều tài liệu.
1.3.8 Tính khả thị của quá trình (tt)
- Phần mềm hiện nay càng lớn, càng phức tạp.
- Năng lực của nhóm lập trình không phải là tuyến tính
so với năng lực của từng cá nhân.
- Độ phức tạp cũng tăng theo cấp số nhân, kéo theo chi
phí cũng tăng theo cấp số nhân so với kích cỡ của
chương trình cần phát triển.
-> Việc tìm cách giảm kích cỡ, độ phức tạp của chương
trình là ưu tiên hàng đầu của công nghệ phần mềm.
1.3.9 Vấn đề giảm kích cỡ của phần mềm
Tại các bước phân tích thiết kế:
Giảm kích cỡ được thực hiện thông qua áp dụng chiến
lược “chia để trị”.
- Chia phần mềm thành các modun con có tính độc
lập cao.
- Độ phức tạp của từng modun sẽ nhỏ hơn nhiều so
với cả hệ thống,
- Các modun con cũng có thể được phát triển song
song.
1.3.9 Vấn đề giảm kích cỡ của phần mềm (tt)
Tại giai đoạn mã hóa:
- Dùng lại: dùng lại các thư viện đã phát triển, các thư
viện thương mại...
- Tự sinh mã: sử dụng các công cụ tự động hỗ trợ kỹ
nghệ phần mềm (visual modeling tools, GUI builders,
CASE tools...)
- Kỹ thuật hướng đối tượng: kỹ thuật hướng đối
tượng hỗ trợ phát triển modun có tính dùng lại cao
nhờ có cơ chế che dấu thông tin và khả năng kế thừa
- Dùng các ngôn ngữ bậc cao (các ngôn ngữ có cấu
trúc và năng lực biểu diễn cao)
1.3.9 Vấn đề giảm kích cỡ của phần mềm (tt)
Tiến trình phát triển công nghệ phần mềm chứa ba giai
đoạn chính: xác định, phát triển và bảo trì
Giai đoạn xác định tập trung vào khái niệm cái gì.
- Xác định thông tin nào cần được xử lý,
- Chức năng và hiệu năng nào là cần có,
- Giao diện nào cần được thiết lập,
- Ràng buộc thiết kế nào hiện có và tiêu chuẩn hợp lệ
nào cần có để xác định ra một hệ thống thành công.
1.4 Cái nhìn chung về công nghệ phần mềm
Mặc dầu các phương pháp được áp dụng trong giai
đoạn xác định thay đổi tùy theo mô hình công nghệ
phần mềm (hay tổ hợp các mô hình) được áp dụng, có
ba bước riêng vẫn xuất hiện dưới dạng:
1.Phân tích hệ thống
2.Lập kế hoạch dự án phần mềm
3. Phân tích yêu cầu
1.4 Cái nhìn chung về công nghệ phần mềm (tt)
Giai đoạn phát triển tập trung vào khái niệm thế nào.
- Xác định cách cấu trúc dữ liệu và kiến trúc phần mềm
cần xây dựng,
- Các chi tiết thủ tục được cài đặt,
- Cách dịch thiết kế vào ngôn ngữ lập trình
- Cách thực hiện kiểm thử.
1.4 Cái nhìn chung về công nghệ phần mềm (tt)
1. Thiết kế phần mềm: Là quá trình “dịch” các yêu cầu
phần mềm thành một tập các biểu diễn, mô tả cho cấu trúc
dữ liệu, kiến trúc, thủ tục thuật toán và đặc trưng giao
diện.
2. Mã hóa: Các biểu diễn thiết kế phải được biểu diễn bởi
một (hay một vài) ngôn ngữ nhân tạo mà sẽ tạo ra kết quả
là các lệnh thực hiện được trên máy tính.
3. Kiểm thử phần mềm: Một khi phần mềm đã được cài
đặt dưới dạng máy thực hiện được, cần phải kiểm thử nó
để phát hiện các lỗi phân tích, thiết kế, cài đặt và đánh giá
tính hiệu quả.
1.4 Cái nhìn chung về công nghệ phần mềm (tt)
Giai đoạn bảo trì tập trung vào những thay đổi
- Gắn với việc sửa lỗi, thích ứng khi môi trường phần
mềm phát triển và sự nâng cao gây ra bởi sự thay đổi
yêu cầu của người dùng.
- Giai đoạn bảo trì áp dụng lại các bước của giai đoạn
xác định và phát triển, nhưng là việc thực hiện trong
hoàn cảnh phần mềm hiện có.
1.4 Cái nhìn chung về công nghệ phần mềm (tt)
Có ba kiểu thay đổi gặp phải trong giai đoạn bảo trì:
1. Sửa đổi: Cho dù có các hoạt động bảo đảm chất
lượng tốt nhất, vẫn có thể là khách hàng sẽ phát
hiện ra khiếm khuyết trong phần mềm.
2. Thích nghi: Qua thời gian, môi trường ban đầu
(như CPU, hệ điều hành, ngoại vi) để phát triển
phần mềm có thể sẽ thay đổi. Bảo trì thích nghi thực
hiện việc sửa đổi phần mềm để thích hợp với
những thay đổi môi trường ngoài.
3. Nâng cao: Khi phần mềm được dùng, khách
hàng/người dùng sẽ nhận ra những chức năng phụ
sẽ có lợi. Bảo trì hoàn thiện mở rộng phần mềm ra
ngoài các yêu cầu chức năng gốc của nó.
1.4 Cái nhìn chung về công nghệ phần mềm (tt)
Giới thiệu một số phần mềm
1. Phần mềm hỗ trợ phân tích:
WinA&D; Analyst Pro…
2. Phần mềm hỗ trợ thiết kế:
QuickUML; PowerDesigner; Oracle Designer…
3. Phần mềm hỗ trợ lập trình:
Visual Studio; Visual Basic; Visual C++…
4. Phần mềm hỗ trợ kiểm chứng:
WinRuner…
5. Phần mềm xây dựng phương án và lập kế hoạch:
MS Project; Visio…
- Phần mềm đã trở thành phần tử chủ chốt của các hệ
thống máy tính.
- Phát triển phần mềm đã phát triển từ xây dựng một
công cụ xử lý thông tin thành một ngành công nghiệp.
- Phần mềm là phần tử lôgíc cho nên việc kiểm soát nó
khó hơn nhiều so với phần tử vật lý.
- Khó có thể tối ưu hóa đồng thời các tính năng cần có
của phần mềm.
- CNPM là một bộ môn tích hợp cả các phương pháp,
công cụ và thủ tục để phát triển phần mềm máy tính.
- Có nhiều mô hình khác nhau mỗi mô hình đều có
những mặt mạnh và điểm yếu, nhưng tất cả đều có một
dãy các giai đoạn cơ bản là:
xác định, phát triển và bảo trì.
Kết chương