NHỮNG VẤN ĐỀ PHƯƠNG PHÁP LUẬN CƠ BẢN

NHỮNG VẤN ĐỀ PHƯƠNG PHÁP LUẬN CƠ BẢN
1. Một số khái niệm cơ bản về thiết kế và xây dựng phần mềm
1.1 Khái niệm về phần mềm.
Hiện nay có khá nhiều cách định nghĩa phần mềm phụ thuộc vào cách tiếp
cận với hệ thống. Theo cách tiếp cận đơn giản nhất có thể xem phần mềm bao
gồm các câu lệnh và các cấu trúc dữ liệu thích hợp để thực hiện những chức
năng mong muốn; và các tài liệu mô tả thao tác và cách sử dụng chương trình.
- Xét theo nghĩa rộng hơn, phần mềm là tất cả các kỹ thuật làm cho việc sử
dụng phần cứng máy tính đạt hiệu quả cao,bao gồm:
• Nhóm các kỹ thuật, phương pháp luận: Các khái niệm, các trình tự thiết kế và
phát triển, các phương pháp tiếp cận vấn đề, đặc tả yêu cầu, thiết kế hệ thống,
kiểm thử,...
• Nhóm các chương trình: bao gồm các câu lệnh và các cấu trúc dữ liệu thích
hợp để thực hiện những chức năng mong muốn. Phần mềm có hai loại là phần
mềm cơ bản và phần mềm ứng dụng.
Phần mềm cơ bản có chức năng cung cấp môi trường thao tác dễ dàng cho
người sử dụng nhằm tăng hiệu năng xử lý của phần cứng.
Phần mềm ứng dụng dùng để xử lý nghiệp vụ thích hợp nào đó.
• Nhóm các tài liệu: Gồm các tư liệu mô tả thao tác và cách sử dụng chương
trình và một số tài liệu khác: điều kiện kiểm thử, vận hành, bảo trì…
Nhóm các kỹ thuật, phương pháp luận
Nhóm các chương trình
Nhóm các tư liệu
Kinh nghiệm kỹ sư, know-how
• Các kinh nghiệm, khả năng, kỹ năng của kỹ sư (know-how)
Hình 2: Mô hình phần mềm
1.2. Đặc tính chung của phần mềm
• Phần mềm là hàng hóa vô hình
• Chất lượng phần mềm: không giảm đi mà có xu hướng tốt lên sau mỗi lần có
lỗi (error/bug) được phát hiện và sửa
• Phần mềm vốn chứa lỗi tiềm tàng, quy mô phần mềm càng lớn thì khả năng

chứa lỗi càng cao
• Lỗi phần mềm thường dễ được phát hiện bởi người ngoài
• Chức năng của phần mềm thường thay đổi theo thời gian và theo nơi sử dụng
• Hiệu ứng làn sóng trong thay đổi phần mềm
• Phần mềm vốn chứa ý tưởng và sáng tạo của tác giả/nhóm tác giả làm ra nó
• Trong xây dựng, phát triển phần mềm cần khả năng “tư duy nhị phân”
• Phần mềm có thể sao chép rất đơn giản
1.3. Vòng đời phát triển của phần mềm
Vòng đời phần mềm là khoảng thời gian tính từ khi phần mềm được tạo ra
cho đến khi chết đi (tức là từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo
dưỡng cho đến khi loại bỏ không dùng nữa)
Vòng đời phần mềm chia thành 5 pha chính: phân tích, thiết kế, chế tạo,
kiểm thử và bảo trì
• Phân tích: quá trình này nhằm mục đích hiểu được lĩnh vực thông tin, chức
năng, hành vi, tính năng và giao diện của phần mềm sẽ phát triển. Quá trình này
đòi hỏi phải tạo tư liệu và bàn thảo với khách hàng
• Thiết kế: là quá trình gồm nhiều bước với 4 thuộc tính khác nhau của một
chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và thuật
toán. Quá trình này cần tư liệu hóa và là một phần quan trọng của cấu hình phần
mềm
• Chế tạo (lập trình): chuyển thiết kế thành chương trình máy tính bằng một
ngôn ngữ lập trình nào đó
• Kiểm thử: kiểm tra các chương trình và module logic bên trong và chức năng
bên ngoài nhằm phát hiện ra lỗi và đảm bảo với đầu vào xác định thì cho kết
quả mong muốn.
• Bảo trì: đáp ứng những thay đổi, nâng cấp phần mềm đã phát triển do sự thay
đổi của môi trường, nhu cầu.
1.4. Nền tảng thiết kế phần mềm trong sản xuất phần mềm
1.4.1. Khái niệm thiết kế phần mềm
Thiết kế phần mềm được định nghĩa trong IEEE 610.12-96 bao gồm: Quá

trình xác định kiến trúc, các thành phần, giao diện và các đặc tính kỹ thuật của
hệ thống hoặc thành phần
1.4.2. Vai trò của công đoạn thiết kế phần mềm
Thiết kế phần mềm là cơ sở cho giai đoạn tiếp theo là xây dựng phần mềm, nó
đóng vai trò quan trọng trong phát triển phần mềm
• Cho phép xem xét, so sánh các phương án kỹ thuật khác nhau trong thiết kế
phần mềm.
• Cho phép xác định phương án phù hợp nhất với các yêu cầu phần mềm.
• Cho phép lập các kế hoạch chi tiết cho giai đoạn xây dựng phần mềm.
Thiết kế
Lập trình
Kiểm thử
Mô hình chức năng
Mô hình tuyến tính
Thiết kế CSDL
Thiết kế thủ tục
Phần mềm đã tích hợp
Hình 3: Mô hình công đoạn thiết kế phần mềm
Đối với một phần mềm có thiết kế khi phát triển thêm các chức năng cho
phần mềm người ta luôn có một nền tảng định hướng rõ ràng mà sau này khi
phát triển không gây ra những đổ vỡ cho phần mềm.
Khi gặp những va chạm của thực tiễn một phần mềm không được thiết kế
đầy đủ sẽ dễ dẫn đến những sai sót nghiêm trọng.
Người ta thường mô tả một phần mềm có thiết kế và không có thiết kế bằng
hình vẽ sau đây:
Bảo trì
Kiểm thử
Cài đặt
Thiết kế
Kiểm thử

Cài đặt
Bảo trì
Có thiết kế
Không có thiết kế
Hình 4: So sánh phần mềm có thiết kế và không có thiết kế
1.4.3. Một số phương pháp thiết kế phần mềm
1.4.3.1. Khái niệm module hoá
Trong trường phái lập trình cấu trúc người ta dựa trên một ý tưởng gọi là
module hoá mà bản chất của nó khá phù hợp với phương pháp phân tích của
triết học tức là khi nghiên cứu một vấn đề nào đó chúng ta phân rã vấn đề đó
thành những vấn đề nhỏ hơn, chi tiết hơn bao gồm từng bộ phận cấu thành nên
vấn đề lớn. Trong tin học, vấn đề module hoá được sử dụng để khi chuyển từ
vấn đề thực tế sang giải pháp phần mềm. Trong trường hợp này quá trình phân
tích dừng lại ở các module độc lập và thông thường mỗi module tương ứng với
một chương trình. Ta có thể biểu diễn quá trình module hoá thông qua sơ đồ cấu
trúc hình cây sau đây.
P
P11
P12
P13
P21
P22
P31
P32
P1
P2
P3
Hình 5: Quá trình module hoá
Nếu ta coi bài toán chính là module bậc 1 thì module này lại được phân chia
thành các module bậc 2, bậc 3... theo cấu trúc hình cây.

1.4.3.2. Phương pháp thiết kế từ trên xuống (Top Down Design)
Ý tưởng tổng quát của phương pháp thiết kế từ đỉnh xuống là dựa vào quá
trình module hoá một vấn đề thực tế. Khi giải quyết một vấn đề nào đó trước
hết người ta đưa ra các phác thảo tổng quát. Sau đó trên cơ sở của phác thảo này
sẽ tiếp tục chi tiết hoá thành các module ngày càng chi tiết và cụ thể hơn và
dừng lại khi mỗi module tương ứng với một chương trình.
1.4.3.3. Phương pháp thiết kế từ dưới lên (Bottom Up Design)
Ý tưởng của phương pháp này xét theo một góc độ nào đó là ngược lại với
phương pháp thiết kế từ trên xuống và bao gồm các vấn đề sau:
Trước hết tiến hành giải quyết các vấn đề cụ thể, sau đó trên cơ sở đánh giá
mức độ tương tự về chức năng của các vấn đề này trong việc giải quyết bài toán
người ta gộp chúng lại thành từng nhóm cùng chức năng từ dưới lên trên cho
đến module chính. Sau đó sẽ thiết kế thêm một số chương trình làm phong phú
hơn, đầy đủ hơn chức năng của các phân hệ và cuối cùng là thiết kế một chương
trình làm nhiệm vụ tập hợp các module thành một hệ chương trình thống nhất,
hoàn chỉnh.
1.4.4. Tiến trình thiết kế phần mềm
Tiến trình thiết kế trong công nghệ phần mềm được xem xét từ nhiều góc độ
khác nhau. Xuất phát từ quan điểm quản lý dự án thì qui trình thiết kế phần
mềm theo hai bước:
• Thiết kế kiến trúc phần mềm: mục đích xác định mô hình kiến trúc và các thành
phần trong kiến trúc.
• Thiết kế chi tiết phần mềm: Thiết kế chi tiết từng thành phần, xác định đầy đủ
các thông tin tương ứng cho từng thành phần để có thể tiến hành xây dựng phần
mềm.
Xuất phát từ góc độ kĩ thuật thì qui trình thiết kế phần mềm bao gồm bốn
loại:
• Thiết kế kiến trúc.
• Thiết kế dữ liệu.
• Thiết kế thủ tục.

• Thiết kế giao diện.
Hai khía cạnh kĩ thuật và quản lý của qui trình thiết kế có mối liên quan mật
thiết với nhau và được biểu diễn trong hình vẽ tổng quát dưới đây.
Thiết kế kiến trúc
Thiết kế dữ liệu
Thiết kế thủ tục
Thiết kế giao diện
Thiết kế chi tiết
Thiết kế sơ bộ
Quản lý
Kỹ thuật
Hình 6: Quy trình thiết kế phần mềm
1.5. Các qui trình trong sản xuất phần mềm
1.5.1. Xây dựng và quản lý hợp đồng phần mềm
1.5.1.1. Mục đích
Qui trình xây dựng và quản lý hợp đồng phần mềm có mục đích nghiên cứu,
đề xuất giải pháp kĩ thuật tiến hành xây dựng hợp đồng đối với khách hàng;
theo dõi tiến trình thực hiện hợp đồng; tổ chức thanh lý; thanh toán hợp đồng và
lập hồ sơ tổng quát về qui trình hợp đồng phần mềm.
1.5.1.2. Dấu hiệu
Qui trình xây dựng và quản lý hợp đồng phần mềm được đặc trưng bởi các
dấu hiệu sau:
- Xây dựng hợp đông phần mềm với khách hàng.
- Theo dõi thực hiện hợp đồng phần mềm
- Thanh toán, thanh lý hợp đồng phần mềm
1.5.1.3. Lưu đồ
Mở đầu
Xây dựng hợp đồng phần mềm
Theo dõi hợp đồng phần mềm
Thanh toán, thanh lý hợp đồng

Kết thúc
Báo cáo tổng kết qui trình
Nghiên cứu đề xuất XD PM
Lập giải pháp
Hình 7: Lưu đồ quy trình xây dựng và quản lý hợp đồng
1.5.1.4. Các thông số
Thông số Điều kiện bắt đầu Điều kiện kết thúc
1.Thông số chung
(chức danh)
Cán bộ kinh doanh Có đề xuất xây dựng
hợp đồng PM
2. Đầu vào Đề xuất của khách hàng và duyệt của
công ty PM
3. Sản phẩm Hợp đồng PM với khách hàng
Giải pháp kĩ thuật
4. Đánh giá chất
lượng
Tỉ lệ các hạng mục của hợp đồng hoàn
thành đúng hạn >=90%
Chênh lệch thời gian dự kiến và thời gian
thực tế là: +- 20%
5. Các qui trình
liên quan
Xác định yêu cầu PM
1.5.1.5. Phân đoạn các hoạt động
STT Tên hoạt động Bắt đầu Hoàn thành
1 Lập giải pháp Có nhu cầu xây dựng
PM
2 Xây dựng hợp đồng PM Kết thúc bước 1 HĐPM được duyệt
3 Theo dõi HĐPM Kết thúc bước 2

4 Thanh toán thanh lý HĐPM Kết thúc bước 3 Lãnh đạo công ty PM và khách
hàng duyệt
5 Báo cáo qui trình Kết thúc bước 4 Công ty duyệt
1.5.2. Xác định yêu cầu phần mềm
1.5.2.1. Mục đích
Sau khi đã có hợp đồng phần mềm với khách hàng; hợp đồng được
chuyển sang để thực hiện yêu cầu thứ hai nhằm mục đích xác định cụ thể nhu
cầu của khách hàng về phần mềm tương lai bao gồm: các chức năng của phần
mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu
cầu đặc biệt khác. Yêu cầu đặt ra là phải lượng hoá và biểu diễn dưới dạng các
mô hình.
1.5.2.2. Dấu hiệu
Qui trình xác định yêu cầu phần mềm được đặc trưng bởi các dấu hiệu sau:
• Phát hiện các yêu cầu phần mềm (Requirements elicitation)
• Phân tích các yêu cầu phần mềm và thương lượng với khách hàng
(Requirements analysis and negotiation)
• Mô tả các yêu cầu phần mềm (Requirements specification)
• Mô hình hóa hệ thống (System modeling)
• Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements validation)
• Quản trị các yêu cầu phần mềm (Requirements management)
1.5.2.3. Lưu đồ
Lập kế hoạch xây dựng yêu cầu
Mở đầu
Xác định yêu cầu phần mềm
Duyệt
Phân tích nghiệp vụ
Lập mô hình hệ thống
Kết thúc
Báo cáo qui trình
Có

Không
Hình 8: Lưu đồ quy trình xác định yêu cầu phần mềm
1.5.2.4. Các thông số
Thông số Mô tả
Yêu cầu
1.Thông số chung (chức danh) Cán bộ xác định yêu cầu
Theo tiêu chuẩn của công
ty
2. Đầu vào Hợp đồng phần mềm