Tải bản đầy đủ (.pdf) (92 trang)

chu trình sống của phần mềm - tiến trình phát triển phần mềm

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.78 MB, 92 trang )

PHẦN 2:
Chu trình sống củaphầnmềm/
Tiến trình phát triểnphầnmềm
TS. TRẦN CAO ĐỆ
NĂM 2010
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 2
Các bước chính trong tiếntrìnhPM
Bài toán
Đặctả yêu cầu
Đặctả chương trình
Chương trình
Chương trình làm việc
Bảotrì
Kiểmthử
Cài đặt
Thiếtkế
Tìm hiểuyêucầu
Chương 9:
Đặc tả yêu cầu
Requirement Engineering
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 4
1. Khái niệm đặctả yêu cầu
• The hardest single part of
building a system is
deciding what to build
• Đặctả yêu cầuphần
mềm
–Bước đầu tiên trong tiến
trình phầnmềm
–Cácyêucầucủangười
dùng về hệ thống tương lai


phải đượcthuthậpvàtài
liệu hóa. Chỉ tập trung vào
what và bỏ qua how
• Đặctả yêu cầukhácvới
phân tích yêu cầuvàđặc
tả hệ thống.
•Nội dung đặctả
–Yêucầuchứcnăng
–Yêucầukhôngchứcnăng:
hiệuquả củahệ thống, độ tin
cậy, tài liệungười dùng, tập
huấn, giá thành,…
•Kếtquả của đặctả: tài liệu đặc
tả yêu cầu
–Phản ánh sự hiểubiết
chung về vấn đề cầngiải
quyếtgiữangười phân tích
và khách hàng.
–Cơ sởđểnghiên cứukhả
thi.
–Cơ sởđểkiểmthử-chấp
nhận.
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 5
2. Yêu cầu về tài liệu đặc tả yêu cầu
•Tàiliệu đặc tả phải đáp ứng:
– rõ ràng và dễ hiểu đốivới khách hàng (dễ thuyết phục).
– đầy đủ và chi tiết vì đây là nguồn thông tin duy nhất dành cho
nhóm phân tích & thiết kế.
• Đặc điểm:
–Cáclỗi xảy ra trong giai đoạn này sẽ ảnh hưởng đến các giai

đoạn còn lại củatoànbộ tiến trình.
– Là hợp đồng (contract) giữa khách hàng và nhà phát triển.
–Phải bao gồm các ràng buộcmàsảnphẩmphải đáp ứng
– Đặctả yêu cầurấtkhóđộclậpvới phân tích, thiếtkế.
•Loại đặctả
– Client – driven
–Market –driven
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 6
3. Nội dung đặc tả
•Phần mềm:
– Môi trường làm việccủa
phần mềm: OS, DBMS
– Các phần mềmgiaotiếp
vớiphần mềmmuốn phát
triển:
•Cáchệ thống đang tồntại
•Dữ liệu: nguồndữ liệu,
format, dùng lại CSDL cũ.
•Giải thuật
•Phần cứng: khả năng của
phần cứng.
–Khả năng lưu trữ
–Khả năng đáp ứng mộttác
vụ …
• Con người: các lớp
người dùng, trình độ
–người dùng
–ngườiquản trị…
•Tàiliệu
–Cácyêucầu về tài liệu

– Các biểumẫu
•Thủ tục
– Qui trình nghiệpvụ
•Chức năng
–Cácchức năng theo từng
nhóm người dùng
•Chất lượng
–Yêucầu chất lượng
– Giá thành
–Thời gian đáp ứng
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 7
4. Hình thức đặc tả
• Dùng ngôn ngữ tự nhiên
–Ngữ nghĩa không rõ ràng, thường có nhiềulỗi
xảy ra
–Ngônngữ tự nhiên không phảilàphương
cách tốt để đặctả sảnphẩm
• Dùng ngôn ngữ qui ước
– Bán hình thức/ đồ họa
• Phân tích theo cấu trúc
•Môhìnhthựcthể quan hệ
• OOP
–Ngônngữ hình thức
• Z, VDM, Petri net.
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 8
Case study - Thảoluận
•Viết đặctả yêu cầucho“hệ thống QL thư
viện”
– Nhóm các user
•Ngườithủ thư

• Đọcgiả
•Ngườiquảnlí
•Ngườiquảntrị hệ thống
– Nhóm các yêu cầutheo
•Chứcnăng
•Chấtlượng
•Côngnghệ: DB, bộ nhớ, phầncứng
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 9
5. Ba bước chính trong đặctả yêu cầu
•Nắmbắtyêucầu
(requirement
elicitation): hiểucác
yêu cầu
– Nhà phân tích # chuyên
gia củalĩnh vực.
• Đặctả các yêu cầu:
mô tả các yêu cầu Æ
tài liệu hóa
•Kiểm tra và xác nhận:
–Kiểm tra (verification):
yêu cầu được phát biểu
đúng.
–Kiểm tra – xác nhận
(validation): yêu cầu
đúng đã được phát biểu
và tài liệu hóa.
user
elicitation
User
requirements

Problem
domain
Domain
knowledge
specification validation
knowledge
Request more
knowledge
Requirements
model
validation
results
Domain
knowledge
User
feedback
Models to be
validated by
user
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 10
6. Phát biểuyêucầu
•Cácyêucầuphải được phát
biểutường minh và tài liệu hóa
• Mô hình hóa: mộtphầncủathế
giớithực được quan tâm:
universe of discourse (UoD)
•Mỗingười lên quan trong UoD
đềucómộtmôhìnhriêng,
không tường minh về thế giới
đó.

•Phátbiểuyêucầu
(requirements elicitation) là
phát biểutường minh về mô
hình không tường minh đó.
•Vaitròngười phân tích:
– Phân tích bài toán
–Thương thảocácyêucầu
•Cácyêucầuvề hệ thống
phải đượcphátbiểu
chính xác và đầy đủ
–Nhiềungười liên quan
–Trìnhđộ khác nhau
–Tầm nhìn khác nhau
•Cácđiểmcầnlưuý
–Con ngườithường có
thành kiếnvớiphỏng vấn
–Con ngườithường không
có suy nghĩ logic nhất quán
–Ngườitathường không thể
chính xác hóa cái mình
muốn
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 11
7. Các kỹ thuật dùng để phát biểu yêu cầu
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 12
8. Tài liệu đặctả yêu cầu
•Tàiliệu đặctả: là sp cuối cùng
củabước đặctả, là đầuvào
củabước phân tích-thiếtkế hệ
thống để có đặctả hệ thống
(kiếntrúchệ thống)

•Tàiliệu đặctả phải
–Dễđọc
–Dễ hiểu
– Đúng đắn (xác nhậnbởiuser)
– Không “mù mờ”
– Đầy đủ (chứcnăng, chất
lượng…)
–Nhất quán: các yêu cầu không
mâu thuẫn nhau.
–Cóthứ tự: quan trọngÆít
quan trọng
–Kiểmtrađược: các đặctả
phải định lượng để có thể test
– Thay đổi được
–Lầnvết được
•Chuẩnchotàiliệu đặctả:
IEEE 830
•Dàný chomộttàiliệu đặctả
(theo IEEE 830)
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 13
Tài liệu đặctả yêu cầu (tt)
•Phần 3 “specific requirements”
là phần dài nhất trong tài liệu,
bao trùm nhiềukhíacạnh:
– Mode: chếđộvậnhành(thử
nghiệm, thí điểm, dùng)
– User class: nhóm người dùng
– Objects: các đốitượng trong
thế giớithực
– Response: trả lời(đầura)

– Functional hierarchy: tổ chức
phân cấpcácchứcnăng.
(tham khảomộttàiliệu đặctả
trang 228-229)
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 14
9. Kỹ thuật đặctả yêu cầu
•Tàiliệu đặctả yêu cầuphụcvụ
cho:
–Người dùng
–Ngườithiếtkế
•Tàiliệuthường đượcviếtbằng
NN tự nhiên và NN củangười
dùng:
–Nhiễu (noise): dư thừa nhiều
thông tin không cầnthiết
–Imlặng (silence): cái chính lại
không được đề cập
– Đặctả thừa: đề cập đếncách
giải quyếthơnlàvấn đề phải
giải quyết
–Mâuthuẫn: 1 vấn đề đặctả
nhiềulần không nhất quán
–Nhậpnhằng
– Tham khảovề phía sau
–Mơ mộng (wishful thingking):
mô tả siêu thực
• Môhìnhthựcthể quan hệ
•Máytrạng thái hữuhạn
• SADT
•CácsơđồUML

– Use case
– Class
– State
–Cooperation
–…
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 15
Ví dụ về bộ điềukhiển an toàn (két sắt)
• J = {Khóa an toàn, A, B, Không khóa an toàn, Chuông báo động }
• K = {1T, 1P, 2T, 2P, 3T, 3P}
•T = như hình vẽ
• S = {Khóa an toàn}
• F = {Không khóa an toàn, Chuông báo động}
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 16
Phân tích
• Phântíchlàbước trung gian giữa
đặctả và thiếtkế
•Mục đích:
– Làm rõ thêm các yêu cầu
– Trình bày các yêu cầubằng các
mô hình phân tích
– Định nghĩarõcácthuậtngữ (từ
điểndữ liệu)
• Phân tích = xây dựng mô hình hệ
thống
–ERD
–DFD
– State diagram
•Kếtquả củagiaiđoạn phân
tích Æ MÔ HÌNH PHÂN TÍCH
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 17

10. Đặctả các yêu cầuphi chứcnăng
•Yêucầu phi chứcnăng (non-
functional requirements)
–Giaodiệnvới ht khác( External
interface)
–Yêucầuvề hiệuquả
–Ràngbuộcvề thiếtkế
–Cácđặctínhcủahệ thống
•Giaodiệnvới ht khác và ràng
buộcvề thiếtkếđược xem như là
những yêu cầubắtbuộc, ví dụ:
–Phầncứng, phầnmềmvàgiao
tiếpgiữa chúng
–Giaodiệnngười dùng theo chuẩn
củacôngty.
–Format củatàiliệu, báo cáo
–Ràngbuộcvề qui trình (vd ISO
9000)
–Giớihạncủaphầncứng
•Cácyêucầuphi chứcnăng đôi khi
còn được xem như yêu cầuvề
chấtlượng
–Phảixácđịnh và test được
vd: 80% giao dịch được đáp ứng
trong 1s; 20% còn lại đáp ứng
trong 3s.
•Lưuý:
–Cácyêucầu phi chứcnăng
có giá để thựchiện
Æ phảikhả thi trong sự cân

bằng với ngân sách.
Æ Phảikhả thi trên thựctế
Æ Nếucầnthiếtphải nghiên
cứukhả thi trước.
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 18
11. kiểm tra (verification) và
kiểm tra-xác nhận (validation)
•Tàiliệu đặctả phải được:
–Kiểm tra (verification): đúng
đắn, đầy đủ, nhất quán.
Nghĩalàtàiliệu đặctả có
chấtlượng.
–Kiểm tra-xác nhận
(validation): tài liệu đặctả
mô tảđúng đắnyêucầu
của khách hàng. Xác nhận
có hiệulực/ giá trị.
• Đốichiếulạitàiliệu đặctả
vớimột danh sách kiểm
tra (checklist). Ví dụ:
– đãchỉ rõ các tài nguyên
phầncứng?
– đãchỉ rõ các tiêu chuẩn
chấpthuận?
•Bằng việckiểmtratàiliệu
đặctả yêu cầu
–Thiếtlập test plan
–Xácđịnh nguồnlực, pp để
kiểmthử trong quá trình
phát triển.

–Xácđịnh kế hoạch kiểm
thử bàn giao (acceptance
test)
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 19
Tổng kếtchương
• Đặctả yêu cầu:
– Làm rõ yêu cầucủa bài
toán
– Làm rõ các ràng buộc trong
giải pháp
–Xácđịnh cụ thể chứcnăng
phải bàn giao và các yêu
cầubắtbuộcvề môi
trường hoạt động
• Đặctả yêu cầulàquá
trình lặpcủabahoạt
động chính:
– Requirement elicitation: để
hiểuvấn đề
– Requirement specification:
để mô tả vấn đề
– Requirement validation: để
thống nhấtvề vấn đề.
•Côngcụđểmô tả vấn đề:
–Ngônngữ tự nhiên
–Ngônngữ bán hình thức:
hình ảnh, biểu đồ
–Ngônngữ hình thức
•Tàiliệu đặctả phảimôtả:
–Yêucầuchứcnăng

–Yêucầu phi chứcnăng
•Tàiliệu đặctả phải được
kiểm tra, xác nhận, phê
chuẩn.
– Làm cơ sở cho kế hoạch
kiểmthử & kiểmthử
– Làm cơ sở cho hợp đồng &
bàn giao sảnphẩm.
Chương 10:
Kiếntrúcphầnmềm
Software architecture
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 21
1. Thiếtkế kiếntrúc
•Xâydựng PM = xây dựng hệ thống Æ có thiết
kế Æ kiếntrúcpm.
•Kiếntrúc= thiếtkế
– Quá trình xác định các hệ thống con trong hệ thống
và khung cho giao tiếpvàđiềukhiểncáchệ thống
con gọi là TKKT
–Sảnphẩmcủa quá trình TKKT là kiến trúc PM.
–Kiếntrúccủamộtxácđịnh các thành phần tính toán
và tương tác giữa chúng trong hệ thống (Shaw,95)
–Kiến trúc pm (củamộtct hoặcmột ht tính toán) là cấu
trúc củahệ thống, bao gồm các thành phần, các tính
chấtnhìnthấy đượccủa các thành phần và quan hệ
giữa chúng.
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 22
Ví dụ mộthệ thống máy (robot) đóng gói
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 23
Yêu cầucủamộtthiếtkế

•Mộtthiếtkế tốt
–Dễđọc, hiểu
– Tin cậy
–Dễ phát triển
– bao trùm tấtcả các yêu cầutường minh
–Cungcấphìnhảnh tồng quan về pm
•KiếntrúcPM phụcvụ:
–Trừutượng hóa về hệ thống.
–Traođổi, thương thảogiữa các bên liên quan.
–Trợ giúp quyết định.
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 24
Đặctrưng củaKTPM
•KiếntrúcPM ảnh hưởng bởi:
– nhà phát triển.
–kiếnthức và kinh nghiệmcủangười phân tích.
–Môitrường kỹ thuậtvàtổ chức.
•Mộtkiếntrúccóthể gồm nhiều thành phầncó
cấutrúc. Mỗi thành phầncócấutrúccóthể xem
xét riêng biệtcòngọi là khung nhìn (view)
– Conceptual/logical view
– Implementation view
– Process view
– Deployment view.
CÔNG NGHỆ PHẦN MỀMTS. TRẦN CAO ĐỆ 2010 Trang 25
2. Mô hình kiếntrúc
• Dùng để tài liệu hóa mộtkiếntrúc.
• Môhìnhcấutrúctĩnh: các thành phần
chính củaHT.
• Môhìnhcấutrúcđộng: cấutrúccủatiến
trình trong HT.

• Mô hình giao diện: giao tiếpgiữacácHT
con.
• Mô hình quan hệ: quan hệ giữacácHT
con.

×