Môn học
PHÁT TRIỂN VẬN HÀNH VÀ
BẢO TRÌ PHẦN MỀM
KHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN CNPM
0O0
GIỚI THIỆU MÔN HỌC
• Số ĐVHT: 3
• Các môn học trước:
CNPM, Phát triển phần mềm hướng đối tương, lập
trình hướng đối tượng, kiểm thử phầm mềm, đặc
tả hình thức
• Nội dung tóm tắt:
– Các khái niệm liên quan đến công nghệ
phần mềm
– Nhấn mạnh các hoạt động trong hai giai
đoạn cuối của quy trình sản xuất phần
mềm theo công nghệ: Phát triển, vận hành
và bảo trì sản phẩm phần mềm
GIỚI THIỆU MÔN HỌC(tt)
• Tài liệu tham khảo
[1] Software Engineering a Practitioner's
approach; Roger S.Pressman
[2] Designing Object System; Steve Cook,
John Danniels
[3] Analyzing Requirement and Defining
Solution Architechtures; Ian Lewis - Bruce
Nielson
[4] UML toolkit; Hans-Erick Ericsson
[5] A Discipline for software engineering;
Watts S.Humphrey
1.1.1 Định nghĩa CNPM
1.1.2 Tiến trình, phương pháp, công cụ
1.1.3 Một cái nhìn tổng quan về CNPM
1.2 Mô tả chu trình phát triển của một phần mềm
1.2.1 Sản xuất phần mềm – một BT phức tạp
1.2.2 Chu trình phát triển của một sản phẩm p/m
1.2.3 Các g/đoạn của chu trình phát triển p/m
1.1 Nhắc lại một số khái niệm
liên quan đến CNPM
1.1.1 Định nghĩa CNPM
* Định nghĩa CNPM cổ điển (Fritz Bauer)
“
Công nghệ phần mềm là sự thiết lập và sử
dụng các nguyên tắc khoa học nhằm mục
đích tạo ra các sản phầm phần mềm một
cách kinh tế mà các sản phầm phần mềm
lại hoạt động một cách hiệu quả và tin cậy
trên các máy tính”
* Định nghĩa khác về CNPM
- CNPM là các quy trình đúng kỷ luật và có định
lượng được áp dụng cho sự phát triển, thực thi
và bảo trì các hệ thống thiên về phần mềm.
- CNPM tập trung vào quy trình, sự đo lường,
sản phẩm, tính đúng thời gian và chất lượng
1.1.2 Tiến trình, phương pháp, công cụ
• Tiến trình (process):
Định nghĩa một bộ khung các tiêu chuẩn
được thiết lập để triển khai CNPM
• Phương pháp (method):
Chỉ ra cách thức (“how to”) thực hiện
• 1.2.3 Các giai đoạn ↑ P/M
1.2.1 Sản xuất p/m – một bài toán phức tạp
• Một số lý do thường gặp:
– Developers khó hiểu đúng những gì Users
cần
– Yêu cầu thường thay đổi trong (t) phát
triển
– Yêu cầu thường được mô tả bằng văn
bản, dài dòng, khó hiểu, thậm chí mâu
thuẫn
=> k/n phát triển?
Một số lý do thường gặp:
– Developers khó nhận thức thấu đáo các
mối quan hệ tiềm ẩn và phức tạp cần được
thể hiện chính xác trong các ứng dụng lớn
– Khả năng nắm bắt các dữ liệu phức tạp
của con người tại một thời điểm là có hạn
– Khó định lượng chính xác hiệu xuất của
các thành phần và thỏa mãn chính xác sự
mong chờ từ phía người dùng
– Lựa chọn p/c và p/m thích hợp cho 1
solution là 1 trong những thách thức lớn
đối với Designers
Một số lý do thường gặp:
• P/M cần phải có khả năng thích ứng và
mở rộng
=> P/m đứng vững trước những biến đổi trong môi
trường dù từ phía cộng đồng người dùng hay công
nghệ
=> Một số khuyết điểm thường gặp:
- xác định xem nhân lực, phương pháp và
công nghệ máy tính có thể
=> nhằm cải thiện một cách tốt nhất công tác
của tổ chức này ( => p/m có ý nghĩa, được mong
muốn)
Nhà thiết kế
• T/kế hệ thống theo hướng cấu trúc của
database, screens, forms và reports
• Quyết định các y/cầu về p/cứng và
p/mềm cho hệ thống cần được phát
triển.
Chuyên gia lĩnh vực
(Domain Experts)
• Là những người hiểu thực chất vấn đề
và tất cả những sự phức tạp của hệ
thống cần tin học hoá
=> Q/trình p/triển p/m sẽ có rất nhiều thuận lợi
nếu đội ngũ làm p/mềm có được sự trợ giúp
của họ
Lập trình viên
• Là những người dựa trên các phân tích
và thiết kế để viết chương trình
(coding) cho hệ thống bằng ngôn ngữ
lập trình đã được thống nhất.
Người dùng
Là đối tượng phục vụ của hệ thống cần
được phát triển