Giới thiệu môn họcCông nghệ phần mềm

(Software Engineering)

Thông tin môn họcTên Môn: Công nghệ phần mềm (Software Engineering)Thời lượng: 45 tiết (11 buổi)Chia nhóm bài tập lớn (4 người/nhóm)Lý thuyết 8 buổi + báo cáo bài tập

Giảng viên: Lê Bá CườngEmail: cuonglb304@gmail.com –

at6b.kma@gmail.comPhone: 0974.087.348

Giới thiệu môn họcTài liệu tham khảo:

Bài giảng trên lớp (slide môn học)

Giáo trình kỹ nghệ phần mềm, nxb ĐHQGHN

Software Engineering, Ian Sommerville, 7th edition

Các tài liệu điện tử trên internet (sv tự tìm kiếm)

Nội dung môn họcKhái niệm phần mềm và quy trình phần mềmPhân tích đặc tả yêu cầuThiết kế phần mềmCài đặtKiểm thử và bảo trìQuản lý dự án

Phần mềmCác loại phần mềm (Software) ứng dụng:

PM hệ thống: tập các ctrình phục vụ các chươg trình khác

PM thời gian thực: điều phối, phân tích và kiểm soát các sự kiện thời gian thực ngay khi chúng xảy ra

PM nghiệp vụ: phục vụ các mục đích kinh doanh của doanh nghiệp

PM nhúng

PM trí tuệ nhân tạo (hệ chuyên gia)

Phần mềmPhần mềm gồm 3 phần:

Chương trình máy tính (mã nguồn, mã máy)Cấu trúc dữ liệu (bộ nhớ ngoài, trong)Tài liệu liên quan (User’s guide, technical

reference, specification, design, test)Phần mềm tốt (có 4 thuộc tính chủ chốt)

Đáng tin cậyDễ sử dụngHiệu quảCó thể bảo trì được

Đặc trưng của phần mềmThoái hóa theo thời gian (do môi trường thay đổi,

nhu cầu thay đổi)Không được lắp ráp từ những mẫu có sẵn (vì do

y/c của từng người dùng đ/v PM)Phức tạp, khó hiểu, vô hìnhCần phát triển theo nhóm:

Quy mô lớn & y/c kỹ thuật khác nhauNhu cầu bàn giao nhanh=> vđề: khó kiểm soát & đồng bộ, trao đổi thông

tin lớn, mỗi cá nhân ảnh hưởng đến kquả của nhóm...

Khái niệm Software EngineeringSE là thiết lập và sử dụng các nguyên lý công

nghệ đúng đắn để được một phần mềm 1 cách tinh tế, vừa tin cậy vừa làm việc hiệu quả trên các máy tính thực (Bauer – 1969)

SE là nguyên lý kỹ nghệ liên quan đến tất cả các mặt lý thuyết, phương pháp và công cụ của phần mềm (Sommerville – 1995)

SE là bộ môn tích hợp cả quy trình, các phương pháp, các công cụ để phát triển phần mềm máy tính (Pressman- 1995)

Các mô hình phát triển phần mềmMô hình thác nước:

Phân tích

Thiết kế

Cài đặt

Kiểm thử

Bảo trì

Mô hình thác nướcPhân tích:

Thu thập và phân tích thông tin về yêu cầu phần mềm, chức năng, hiệu năng, giao diện

Kquả: tài liệu đặc tả để khách hàng duyệt lại và làm tài liệu cho người phát triển

Thiết kế: là quá trình chuyển hóa yêu cầu phần mềm thành các mô tả thiết kếCông việc: thiết kế kiến trúc phần mềm, thiết kế

cấu trúc dữ liệu, thiết kế các thủ tục, giao diện và tương tác

Lập tài liệu thiết kế

Mô hình thác nướcCài đặt: biểu diễn thiết kế bằng một ngôn ngữ lập

trình và dịch thành mã máy để thực hiệnKiểm thử:

Phát hiện và sửa lỗi logic (lỗi lập trình)Phát hiện và sửa lỗi chức năng, tính hiệu quả trong

vận hành thực tế có bảo đảm khôngBảo trì: sửa các lỗi phát sinh khi triển khai ra môi

trường thực hoặc yêu cầu bổ sung chức năng hoặc nâng cao hiệu năng cần có

? Ưu điểm/ nhược điểm của mô hình này

Mô hình thác nước – đặc điểmTách biệt giữa các pha, tiến hành tuần tự

Khó tuân thủ thứ tự (dự án lớn thường phải quay lại)

Khó đáp ứng y/c thay đổi của khách hàngChậm có phiên bản thực hiện được

Đòi hỏi khách hàng phải kiên nhẫnSai sót phát hiện muộn có thể là thảm họa

Có sớm -> đc sử dụng rộng rãiThích hợp khi yêu cầu được hiểu tốtBảo trì thuận lợi

Mô hình bản mẫu

Mô hình bản mẫuLoại mẫu:

Mẫu trên giấyMẫu mô tả một phần chức năngMẫu giao diệnMẫu hướng tới sản phẩm

Các loại mẫu:Dùng xong bỏDùng tiếp cho bước sauMẫu là một phần hệ thống vận hành được

Mô hình bản mẫuƯu điểm:

Nhanh chóng xác định được yêu cầuTạo cơ sở ký kết hợp đồngGiúp đào tạo huấn luyện người sử dụng

Nhược điểmTính cấu trúc không caoKhách hàng ít tin tưởng

Thích hợp:Các yêu cầu chưa rõ ràngInput/output chưa rõ ràngKhó đánh giá tính hiệu quả của thuật toán

Mô hình xoắn ốc (spiral model)

Mô hình xoắn ốc (spiral model)Là cải tiến của mô hình tuần tự và bản mẫuCó thêm: phân tích rủi roLà quá trình lặp, hướng mở rộng và hoàn thiện

dầnLập kế hoạch: xác lập vđề, tài nguyên, thời hạnPtích rủi ro: xem xét mạo hiểm, tìm giải phápKỹ nghệ: phát triển một phiên bản của phần mềm

(chọn mô hình thích hợp: thác nước or bản mẫu)Đánh giá của khách: khách hàng đánh giá phiên

bản phát triển -> làm mịn, sửa đổi

Mô hình xoắn ốc: đặc điểmThích hợp với hệ lớn, có thể phân chia thành

phần cốt lõi -> phần thứ yếuCó thể kiểm soát rủi ro ở từng mức tiến hóaKhó thuyết phục đc khách hàng là kiểm soát được

sự tiến hóa linh hoạt (đòi hỏi năng lực qlí,ptích rủi ro -> chi phí chuyên gia lớn)

Chưa phổ biến nên ít đc dùng hơn thác nước và bản mẫu

Kỹ thuật thế hệ thứ 44GT ( fourth generation technology) gồm một phạm vi

rộng các công cụ phần mềm có các đặc điểm chung:Cho phép người phát triển xác định một số đặc trưng

của phần mềm ở mức caoTự động sinh mã chương trình theo nhu cầu người phát

triểnCác công cụ:

Truy vấn CSDLTạo báo cáo, bảng tínhBộ sinh chương trìnhKhả năng đồ họa mức cao…

Kỹ thuật thế hệ thứ 4: đặc điểmPhân tích thiết kế vẫn là bước quan trọng

4GT chỉ trợ giúp sinh mã với những chức năng cụ

thể

ứng dụng còn hạn chế vì không dễ dùng

Tiết kiệm công sức cho phát triển phần mềm nhỏ

Không hiệu quả với phần mềm lớn: vì mã hóa chỉ

chiếm tỉ lệ nhỏ so với phân tích và thiết kế

Bài tập nhómChia nhóm: 5 người/nhóm

Yêu cầu: đọc tài liệu Software Engineering – Ian

Somerville và báo cáo kết quả.

Danh sách đề tàiTìm hiểu, báo cáo kết quả:

C6 (software requirements) vs C7 (requirements

engineering processes) – Cho nhóm nào nhiều

members nhất

chương 8 – System models

Chương 9 – Critical systems specification

Chương 10 – Formal specification

Chương 11 – Architectural design

Danh sách đề tài (tiếp)Tìm hiểu, báo cáo kết quả:

Chương 12 – Distributed system architectures

Chương 14 – Object oriented design

Chương 19 – Component-based software engineering

Chương 22 – Verification and Validation

Chương 26 – Software cost estimation

Chương 30 – Security engineering

Danh sách đề tài (tiếp)Bài toán phân tích thiết kế máy rút tiền ATM

Requirement & Use cases: y/c nhóm đọc tài liệu

UML, chỉ rõ cách làm Req & UCs -> áp dụng cho

bài toán ATM

Analysis Classes & Class Diagram: y/c như trên

Interaction diagram: y/c như trên