Ngời ta dùng mô hình thác nớc để biểu diễn vòng đời phát triển của phần
mềm với hai ý nghĩa:
Khẳng định đây là các giai đoạn của một quy trình thống nhất, không
tách rời và có mối quan hệ mật thiết với nhau.
Trong mô hình này các công đoạn càng ở phía dới thì càng phải chịu sự
tác động của các giai đoạn phía trên, chỉ trừ có công đoạn công nghệ hệ thống
là không chịu sự tác động của công đoạn nào.
Để xây dựng đợc hệ thống phần mềm ta phải mô tả đợc vấn đề và yêu
cầu của khách hàng bằng trả lời các câu hỏi nh vấn đề của hệ thống là gì? Và hệ
thống cần phải làm gì?. Pha phân tích của tiến trình tập trung vào việc điều tra
vấn đề thay cho việc tìm ra giải pháp. Để có tài liệu phân tích đầy đủ và đúng
đắn thì phải phân tích lĩnh vực vấn đề. Lĩnh vực vấn đề là khu vực tác nghiệp
của con ngời trong đó phần mềm đợc xây dựng.
Những ngời tham gia vào xây dựng hệ thống phần mềm nh khách hàng,
phân tích viên, lập trình viên theo phơng pháp thác nớc rất ít khi làm việc cùng
với nhau để chia sẻ các hiểu biết sâu sắc về vấn đề đang giải quyết. Do vậy họ
mất nhiều thời gian để xây dựng đợc hệ thống phần mềm.
Mô hình thác nớc còn đợc biểu diễn dới dạng chữ V trong đó quy trình
kiểm tra đợc thực hiện đồng thời với các quy trình phát triển khác ví dụ kiểm tra
chức năng đợc thực hiện trong quá trình phân tích, kiểm tra tích hợp đợc thực
hiện trong quá trình thiết kế, kiểm tra module trong quy trình lập trình.
1.3. Mô hình lặp và tăng dần
Mô hình thác nớc không cho ta đi ngợc lại chuỗi trình tự phát triển phần
mềm, theo mô hình này thì phải xác định toàn bộ yêu cầu, nó đợc thực hiện
thông qua bàn bạc với ngời sử dụng hệ thống và khảo sát các chi tiết tiến trình
tác nghiệp. Thực tế thì khi kết thúc công việc, may mắn lắm chỉ 80% nhu cầu
của hệ thống là đợc thu thập trong quy trình phân tích do khi đặt hàng bản thân
khách hàng chỉ mới liệt kê ra các mong muốn và nguyện vọng của mình về
phần mềm mà cha hình dung đợc một cách cụ thể những khả năng mà phần
mềm sẽ đạt đợc, đồng thời kỹ s phần mềm ngay từ đầu nhận đơn đặt hàng cũng
không thể hình dung hết kiến trúc tổng quát của phần mềm mà mình xây dựng.
Tiếp theo là quy trình thiết kế, nơi kiến trúc hệ thống sẽ đợc xác định, quy trình
này tập trung vào những nhiệm vụ nh đặt chơng trình ở đâu, cần phần cứng
nào trong khi thực hiện công việc này, chúng ta có thể tìm ra một số nhiệm
vụ mới của hệ thống của hệ thống. Do đó xuất hiện nhu cầu đi ngợc lại ngời sử
dụng để trao đổi bàn bạc về nó; có nghĩa là chúng ta phải trở lại quy trình phân
tích. Sau khi lặp lại vài lần nh vậy chúng ta mới chuyển đến quy trình lập trình
hệ thống. Khi mã hoá chơng trình, chúng ta phát hiện ra một vài quyết định khi
thiết kế là không thể cài đặt. Vậy ta phải quay trở lại quy trình phân tích để xem
xét lại yêu cầu. Sau quy trình lập trình, quy trình kiểm thử bắt đầu. Trong khi
kiểm thử chúng ta nhận thấy một vài yêu cầu cha đủ chi tiết, giải thích nhầm
lẫn có thể xảy ra. Vậy ta phải trở lại quy trình phân tích để xem xét lại yêu cầu.
Sau một vài lần lặp lại nh vậy ta có đợc hệ thống hoàn chỉnh và bàn giao cho
khách hàng. Vấn đề về luật pháp, quy trình kinh doanh có thể thay đổi theo thời
gian khi xây dựng hệ thống, ngời sử dụng có thể phàn nàn về các vấn đề này,
sản phẩm làm ra không đúng nh họ mong đợi. Nguyên nhân có thể là sự thay
đổi của pháp luật, môi trờng kinh doanh; ngời sử dụng không truyền đạt đúng
cái họ muốn; đội ngũ dự án không tuân thủ tiến trình Đội ngũ phát triển th-
ờng lập ra các biểu đồ và vô số tài liệu, văn bản, nhng ngời dùng không phải lúc
nào cũng hiểu cái mà đội ngũ phát triển cung cấp cho họ. Giải pháp nào để
tránh các vấn đề này? Câu trả lời là mô hình hoá trực quan có thể giúp họ.
Phát triển phần mềm là tiến trình phức tạp. Nếu bỏ qua khả năng quay trở
lại của các bớc thực hiện trớc đó thì thiết kế hệ thống có thể sai lầm và thiếu sót
nhu cầu. Để có thể đi ngợc lại các bớc phát triển hệ thống phần mềm chúng ta
có phơng pháp mới, phơng pháp phát triển lặp. Phát triển lặp là làm đi làm lại
việc gì đó. Trong phơng pháp này ta sẽ đi qua các bớc phân tích, thiết kế, phát
triển, kiểm thử và triển khai phần mềm theo từng bớc nhỏ nhiều lần. Bởi chúng
ta khó có thể thu thập đợc đầy đủ mọi yêu cầu vào công đoạn đầu tiên của dữ
án. Các vấn đề mới nảy sinh, vậy ta phải lập kế hoạch lặp trong dự án. Theo
quan niệm này thì dự án đợc coi là các thác nớc nhỏ, mỗi thác nớc đợc thiết kế
đủ lới để sao cho có thể hoàn thiện từng bộ phận quan trọng của của dự án và
đủ nhỏ để tối thiểu nhu cầu đi trở lại.
Theo mô hình lặp và tăng dần thì mỗi chu kỳ lặp là một vòng đời thác n-
ớc nhỏ. Vòng lặp sau đợc hình thành trên cơ sở tiến hoá của vòng lặp trớc đó.
Nh vậy các quy trình truyền thống đợc lặp đi lặp lại và tăng dần. Trong phơng
pháp này, phân tích viên, ngời thiết kế, ngời lập trình hợp tác làm việc với
nhau để hiểu biết sâu sắc hệ thống, chia sẻ các ý tởng mới dẫn đến xây dựng đ-
ợc một hệ thống mạnh, phức tạp hơn.
2. Cấp bậc kiến trúc phần mềm
Cấp bậc kiến trúc của phần mềm đợc hiểu là thứ bậc trình tự các khối và
mối liên kết giữa chúng với nhau. Nh vậy đứng trớc một vấn đề thực tiễn ngời
kỹ s phần mềm có thể đa ra nhiều giải pháp khác nhau để giải quyết vấn đề đó,
cấp bậc kiến trúc phần mềm hoàn toàn phụ thuộc vào trình độ chuyên môn của
mỗi ngời.
Yêu cầu của mỗi kiến trúc phần mềm là phải đạt đợc hai vấn đề
+ Đảm bảo tính chặt chẽ trong kiến trúc để không xảy ra những lỗ hổng
trong phần mềm.
+ Kiến trúc phải đảm bảo không quá phức tạp để khi dịch thành chơng
trình thì quy mô của chơng trình không quá lớn và khi thực hiện mỗi chức năng.
Mô hình chuyển từ bài toán thực tế sang bài toán logic (problem
-solution).
Mô hình này cho ta thấy với một vấn đề thực tế nhng qua bàn tay chế tác
của kỹ s phần mềm có thể trở lên rất nhiều kiến trúc phần mềm khác nhau. Tiêu
chuẩn duy nhất để lựa chọn một kiểu kiến trúc nào đó là không quá phức tạp
nhng vẫn đảm bảo tính năng hoạt động của phần mềm. Đây chính là quá trình
cấu trúc hóa các vấn đề phi cấu trúc.
3. Các quy trình thiết kế phần mềm
Mỗi quy trình bao gồm các bớc
- Mục đích của quy trình
- Dấu hiệu của quy trình để phân biệt với mỗi quy trình khác
- Lu đồ của quy trình đợc biểu diễn dới dạng sơ đồ khối
- Các thông số của quy trình trong đó xác định rõ tên chức
danh, tham số đầu vào, sản phẩm cần phải giao nộp, phơng pháp đánh
giá hiệu quả
- Các quá trình liên quan
- Phân đoạn các quá trình của qui trình
Qui trình 1: Xác định yêu cầu ngời sử dụng (Khách hàng)
Mục đích: Mục đích của quy trình này bao gồm:
- Xác định một cách chính xác các yêu cầu của ngời sử dụng
về phần mềm
- Phân tích hệ thống và các quá trình có liên quan
- Phân tích yêu cầu của ngời sử dụng tơng lai có liên quan
đến phần mềm tơng lai
Dấu hiệu: Quy trình này đợc đặc trng bởi các dấu hiệu sau
- Khảo sát
- Phân tích nghiệp vụ
- Phân tích yêu cầu
Lu đồ
Bắt đầu
Kết thúc
Khảo sát hệ thống
Lập kế hoạch xác định yêu cầu
Phân tích nghiệp vụ
Phân tích yêu cầu người sử dụng
Mô tả hoạt động hệ thống
Các thông số của quy trình
Thông số Mô tả công việc Yêu cầu công việc
1. Thông số chung Chức danh cán bộ
xác định yêu cầu
Tiêu chuẩn của
khách hàng
Điều kiện bắt đầu - Yêu cầu của
khách hàng
- Quyết định của
công ty
Công ty phần
mềm
2. Input Văn bản yêu cầu
của khách hàng
Các tiêu chuẩn
sản xuất phần mềm
Công ty phần
mềm
3. Sản phẩm - Phân tích nghiệp
vụ
- Phân tích yêu
cầu
- Mô tả hoạt động
Công ty phần
mềm
4. Đánh giá - Tỉ lệ các tài liệu
hoàn thành đúng thời
hạn
- Độ chênh lệch
giữa dự kiến và thực tế
>90%
Chênh lêch 20%
5. Các quá trình
liên quan
- Giá trị dự án
- Xây dự và quản
lý hợp đồng phần mềm
Công ty phần
mềm
Phân đoạn các hoạt động
S
TT
Tên hoạt động ĐK bắt đầu ĐK kết thúc
1 Lập kế hoạch Bắt đầu quy
trình 1
Khách hàng đợc
quản trị viên dự án phê
duyệt
2 Khảo sát kế
hoạch
Kết thúc bớc 1 Báo cáo khảo sát
đợc quản trị viện phê
duyệt
3 Phân tích
nghiệp vụ
Kết thúc bớc 2 Quản trị viên và
khách hàng chấp nhận
4 Phân tích yêu
cầu
Kết thúc bớc 3 Khách hàng chấp
nhận
5 Mô tả hoạt
động
Kết thúc bớc 4 Quản trị viên phê
duyệt
6 Tổng hợp Kết thúc bớc 5 Quản trị viên và
khách hàng chấp nhận
Quy trình 2: Xây dựng và quản lý hợp đồng phần mềm
Mục đích: Xem xét các giải pháp, soạn thảo ký kết theo dõi quá trình thực
hiện hợp đồng, thanh toán thanh lý và nghiệm thu các hợp đồng phần mềm
Dấu hiệu:
- Đa ra các giải pháp kĩ thuật
- Soạn thảo hợp đồng phần mềm
- Tiến hành theo dõi việc thực hiện thanh toán thanh lý hợp
đồng
Lu đồ:
Bắt đầu
Kết thúc
Theo dõi việc thực hiện hợp đồng phần mềm
Đưa ra các giải pháp kĩ thuật
Soạn thảo hợp đồng phần mềm
Thanh toán, thanh lý hợp đồng phần mềm
Đề xuất xây dựng hợp đồng phần mềm
Lập báo cáo về tiến trình quản lý hợp đồng phần mềm
Không có nhận xét nào:
Đăng nhận xét