-
Thông tin
-
Quiz
Chương 2 Quy trình xây dựng phần mềm | Công nghệ phần mềm | Trường Đại học Công nghiệp TP.HCM
Chương 2 Quy trình xây dựng phần mềm môn Công nghệ phần mềm của Trường Đại học Công nghiệp Thành phố Hồ Chí Minh. Hi vọng tài liệu này sẽ giúp các bạn học tốt, ôn tập hiệu quả, đạt kết quả cao trong các bài thi, bài kiểm tra sắp tới. Mời các bạn cùng tham khảo chi tiết bài viết dưới đây nhé.
21
11 lượt tải
Tải xuống
Môn: Công nghệ phần mềm (Software Engineering) 28 tài liệu
Trường: Đại học Công nghiệp Thành phố Hồ Chí Minh 386 tài liệu
Thông tin:
47 trang
1 tháng trước
Tác giả:
lOMoARcPSD|40651217
lOMoARcPSD|40651217
MÔN HỌC
CÔNG NGHỆ PHẦN MỀM
Chương 2
Quy trình xây dựng phần mềm
TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM
lOMoARcPSD|40651217
Chương 2 : Quy trình xây dựng phần mềm
2.1 Quy trình (process)
2.2 Một số quy trình xây dựng phần mềm
2.2.1 Mô hình thác nước
2.2.2 Mô hình phát triển gia tăng
2.2.3 Mô hình RAD
2.2.4 Mô hình bản mẫu
2.2.5 Mô hình xoắn ốc
lOMoARcPSD|40651217
2.3 Các quy trình khác
2.3.1 Quy trình RUP
2.3.2 Phương pháp phát triển phần mềm linh hoạt (PTPMLH
- Agile software development)
Yêu cầu
Hiểu rõ một số quy trình phần mềm cơ bản
Trong thực tế người ta thường kết hợp nhiều quy trình
Những quy trình giới thiệu là những phương pháp cơ bản có
tính nghiêm ngặt, hiện nay người ta áp dụng những quy trình
mới có tính linh hoạt cao, tạo sự thoải mái cho người làm việc
và phát huy tính sáng tạo nhưng vẫn phải tuân thủ các nguyên
tắc
lOMoARcPSD|40651217
2.1 Quy trình (process)
Quy trình (process) phần mềm bao gồm một tập hợp các
hoạt ộng ược tổ chức mà mục ích của nó là xây dựng và
phát triển phần mềm.
Quy trình: Phải thực hiện những công việc gì?
Phương pháp: Chỉ ra cách thực hiện những công việc cụ
thể (“how to”)
a “quality” focus
process
methods
tools
lOMoARcPSD|40651217
Quy trình khung (Process framework)
Process framework
Framework
activities
work tasks
work
products
milestones &
deliverables
QA checkpoints
Umbrella Activities
lOMoARcPSD|40651217
Quy trình khung
Truyền thông
Lập kế hoạch
Mô hình hóa
Xây dựng
Triển khai
Các hoạt ộng
khung
Liên quan ến
Công việc (Work tasks)
Sản phẩm công tác (Work products)
Communication
Planning
Modeling
Analysis of requirements
Design
Construction
Code generation Testing
Deployment
lOMoARcPSD|40651217
Mốc thời gian và thành quả chuyển giao (Milestones
& deliverables)
Thời iểm kiểm tra chất lượng (QA checkpoints)
Hoạt ộng hỗ trợ
Quản lý dự án
Kiểm tra kỹ thuật hình thức
Bảo ảm chất lượng phần mềm
Quản lý cấu hình phần mềm
Chuẩn bị và tạo sản phẩm
Quản lý sử dụng lại
Đo lường
Quản lý rủi ro
Software project management
Formal technical reviews
Software quality assurance
Software configuration
management
Work product preparation and
production
Reusability management
Measurement
Risk management
lOMoARcPSD|40651217
2.1 Mô hình phát triển phần mềm (Process Model)
Mô hình phát triển phần mềm là một thể hiện trừu
tượng của quy trình phần mềm.
Nó biểu diễn các ặc tả về quy trình từ những khía
cạnh cụ thể, do ó, nó chỉ cung cấp một phần thông
tin về quy trình phần mềm
lOMoARcPSD|40651217
Lựa chọn mô hình phát triển dựa vào:
Bản chất của dự án và ứng dụng
Nhận thức rủi ro
Sự hiểu biết và kỹ năng của các kỹ sư
Kiến thức miền của người phát triển
Phương pháp và công cụ ược dùng
Cách thức kiểm soát và các kết quả chuyển giao
ược yêu cầu
Năm mô hình phát triển phần mềm
Mô hình Thác nước (Waterfall Model)
Mô hình xử lý tăng dần (Incremental Process
Models)
lOMoARcPSD|40651217
Mô hình tăng dần (Incremental Model)
Mô hình RAD (Rapid Application Development Model)
Mô hình Qui trình tiến hóa (Evolutionary Process
models)
Mô hình Tạo bản mẫu (Prototyping Model) Mô hình Xoắn ốc
(Spiral Model)
Không có quy trình
Inputs
Outputs
lOMoARcPSD|40651217
Không thể biết khi nào hoàn thành do không có phân
tích và thiết kế chính thức
Không có cách ánh giá các yêu cầu, và tiêu chuẩn
chất lượng có ược thỏa mãn hay không
Mô hình thác nước (Waterfall Model)
Mô hình thác nước [Winston Royce] ưa ra vào năm
1970 nhằm thay thế cho phương pháp “code-and-fix”
Lần ầu tiên ưa ra chính thức một cơ cấu gồm những
giai oạn phát triển phần mềm dựa vào yêu cầu ã xác
ịnh và ược tạo tư liệu trong giai oạn
ầu
lOMoARcPSD|40651217
Mô hình thác nước
lOMoARcPSD|40651217
Đặc iểm mô hình thác nước
Phát triển theo trình tự các bước. Mỗi giai oạn xác ịnh tiêu
chuẩn vào và ra. Mô hình dễ hiểu và dễ thực hiện ối với mọi
người liên quan. Nó cung cấp một cấu trúc rõ ràng cho những
nhân viên thiếu kinh nghiệm hay yếu về kỹ thuật.
Việc chuyển từ một giai oạn này tới giai oạn kế tiếp ược thực
hiện khi thỏa một kiểm tra (review) chính thức, xác ịnh một sự
ồng thuận giữa những thành viên dự án và khách hàng.
Áp dụng cho những phần mềm chất lượng cao, khi yêu cầu
chất lượng nổi trội hơn những yêu cầu về lịch biểu và chi phí
Mô hình thác nước – nhược iểm
Mô hình có tính tuần tự theo 5 giai oạn nên khi muốn quay lui ể làm
úng một vấn ề hay một kết quả thì sẽ tốn kém nhiều chi phí và thời
gian. Do ó cần phải quản lý chặt chẽ các hoạt ộng, phải ặc tả tất cả
yêu cầu một cách chính xác và ầy ủ ngay từ ban ầu.
lOMoARcPSD|40651217
Khó ánh giá tình trạng của dự án, ánh giá kết quả của dự án ở thời
iểm kiểm tra do việc tích hợp chỉ thực hiện ở giai oạn cuối.
Tồn tại việc phải chờ (“delay”) trong nhóm làm việc.
Việc thực hiện trình tự không tự nhiên, tính lặp thường diễn ra trong
thực tế.
Khi nào sử dụng mô hình thác nước
Khi xác ịnh sản phẩm ổn ịnh và những vấn ề về kỹ thuật ã
biết rõ:
Nếu một công ã xây dựng một hệ thống như kế toán, bán
hàng… thì những dự án xây dựng những sản phẩm
tương
lOMoARcPSD|40651217
tự có thể sử dụng mô hình thác nước
Tạo một phiên bản mới của một sản phẩm ang tồn tại
trong ó những biến ổi (change) ược xác ịnh và kiểm soát
lOMoARcPSD|40651217
Mô hình tăng dần
lOMoARcPSD|40651217
Mô hình tăng dần
Các yêu cầu ược xác ịnh và phân loại theo ộ ưu tiên, ộ ưu tiên
cao cho những chức năng chính và những chức năng có ộ rủi
ro cao
Phân chia các yêu cầu cho các vòng và thiết kế kiến trúc của
toàn bộ hệ thống
Vòng ầu tiên tạo ra sản phẩm lõi (core product)
Các bước sau bổ sung các chức năng khác và tích hợp vào
hệ thống nhằm hoàn thiện dần sản phẩm
Hệ thống tích hợp phải ược kiểm tra ánh giá thường xuyên
theo từng giai oạn
Các yêu cầu và kiến trúc của toàn bộ hệ thống sẽ ược iều
chỉnh dựa vào những sản phẩm phát hành theo từng vòng
lOMoARcPSD|40651217
Mô hình tăng dần – ưu iểm
Những chức năng của hệ thống có thứ tự ưu tiên càng cao
(chức năng chính, chức năng rủi ro cao) sẽ ược thực hiện
trước, do ó chúng sẽ ược kiểm thử nhiều hơn, sản phẩm ươc
hoàn thành phần cơ bản sớm
Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả cho
khách hàng. Những kết quả này óng vai trò là mẫu thử ể giúp
tìm hiểu thêm các yêu cầu ở những vòng tiếp theo. Có thể
thực hiện nhiều bước ồng thời.
Nhân viên có thể thực hiện những công việc tương tự ở các
vòng một cách liên tục
Mô hình tăng dần – khuyết iểm
Phải xác ịnh chức năng ầy ủ và hoàn chỉnh trước khi xác ịnh
các vòng gia tăng (thác nước?)
lOMoARcPSD|40651217
Phải xác ịnh rõ các giao tiếp (interface) cho các module mà
thời gian hoàn thành cách biệt nhiều
Việc kiểm tra khó khăn hơn trên một hệ thống hoàn chỉnh
Khách hàng khi thấy sản phẩm lõi có thể nghĩ là công việc ơn
giản ít tốn kém
Đòi hỏi phải có kế hoạch và thiết kế tốt, phân chia công việc
hợp lý, các nhân viên phải cộng tác tốt
Mô hình tăng dần - khi nào sử dụng
Khi tất cả yêu cầu ược hiểu khá rõ nhưng mong
muốn có sự tiến hóa dần của sản phẩm
Khi cần phải nhanh chóng ưa sản phẩm với chức
năng cơ bản ra thị trường sớm
Mô hình RAD (Rapid Application Development Models)
lOMoARcPSD|40651217
Mô hình này ược ưa ra bởi IBM vào những năm 1980, qua
sách của James Martin
Rapid Application Development một mô hình tiến trình phần
mềm gia tăng với chu kỳ phát triển ngắn (60-90 ngày)
Mô hình RAD dựa vào sử dụng thành phần (component) và
sử dụng các ứng dụng tạo mã tự ộng
Bấm Tải xuống để xem toàn bộ.