Bài giảng Nhập môn công nghệ phần mềm (Bản đầy đủ)

ised by revised by Main trunk revised by Branch 1.2.1 derived from merged with released as Branches: CVS ::= . ::= . ::= . | ::= ::= MUE.1.1:Release MUE.1.2:Release MUE.1.3:Release 1.2.1.1:Release 1.2.1.2:Release MUE.2.0:Release 6. SCM planning • Lập kế hoạch quản lý cấu hình phần mềm bắt đầu trong giai đoạn đầu của dự án. • Kết quả của giai đoạn lập kế hoạch SCM là Kế hoạch quản lý cấu hình phần mềm (SCMP) có thể được mở rộng hoặc sửa đổi trong phần còn lại của dự án. • SCMP có thể tuân theo tiêu chuẩn công khai như IEEE 828 hoặc tiêu chuẩn nội bộ (ví dụ: của công ty). The Software Configuration Management Plan • Xác định các loại tài liệu được quản lý và sơ đồ đặt tên tài liệu. • Xác định người chịu trách nhiệm về các thủ tục CM và việc tạo ra các baseline. • Xác định các chính sách để kiểm soát thay đổi và quản lý phiên bản. • Mô tả các công cụ nên được sử dụng để hỗ trợ quá trình CM và bất kỳ hạn chế nào trong việc sử dụng chúng. • Xác định cơ sở dữ liệu quản lý cấu hình được sử dụng để ghi lại thông tin cấu hình. Outline of a Software Configuration Management Plan (SCMP, IEEE 828- 1990)• 1. Introduction – Describes purpose, scope of application, key terms and references • 2. Management (WHO?) – Identifies the responsibilities and authorities for accomplishing the planned configuration management activities • 3. Activities (WHAT?) – Identifies the activities to be performed in applying to the project. • 4. Schedule (WHEN?) – Establishes the sequence and coordination of the SCM activities with project mile stones. • 5. Resources (HOW?) – Identifies tools and techniques required for the implementation of the SCMP • 6. Maintenance – Identifies activities and responsibilities on how the SCMP will be kept current during the life- cycle of the project. 7. Tools for Software Configuration Management • Quản lý cấu hình phần mềm thường được hỗ trợ bởi các công cụ với các chức năng khác nhau. • Examples: – RCS • very old but still in use; only version control system – CVS • based on RCS, allows concurrent working without locking – Perforce • Repository server; keeps track of developer’s activities – ClearCase • Multiple servers, process modeling, policy check mechanisms An example of change management process Request change Assess request Approve request Reject request Assign change Implement change Validate change Anybody Control Board Developer [inconsistent with goals] [consistent with goals] Quality Control Team Summary • Quản lý cấu hình phần mềm là một phần cơ bản của kế hoạch quản lý dự án để quản lý các hệ thống phần mềm đang phát triển và điều phối các thay đổi đối với chúng. • SCM được thực hiện theo kế hoạch SCM. Kế hoạch này có thể tuân theo tiêu chuẩn công khai (ví dụ IEEE 828) hoặc tiêu chuẩn nội bộ. • Cần phải điều chỉnh một tiêu chuẩn cho một dự án cụ thể: – Các dự án lớn cần có kế hoạch chi tiết để thành công – Các dự án nhỏ không đủ khả năng gánh vác những kế hoạch như vậy • SCM được hỗ trợ bởi các công cụ. Chức năng của chúng thay đổi từ các công cụ lưu trữ phiên bản đơn giản đến các hệ thống rất phức tạp với các quy trình tự động để kiểm tra chính sách và hỗ trợ tạo tài liệu SCM. NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (INTRODUCTION TO SOFTWARE ENGINEERING) 1 Chương 5: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) • 1. Tổng quan về yêu cầu phần mềm • 2. Quy trình xác định yêu cầu phần mềm • 3. Phương pháp và công cụ đặc tả yêu cầu phần mềm • 4. Nguyên lý phân tích yêu cầu sử dụng 2 Khái niệm • Các đặc tính của hệ thống hay sản phẩm do khách hàng - người sử dụng PM - đặt ra → Xác định được phần mềm đáp ứng được các yêu cầu và mong muốn của khách hàng - người sử dụng phần mềm 3 Lĩnh vực ứng dụng của hệ thống/sản phẩm Nhu cầu và ràng buộc của những người có quyền lợi và nghĩa vụ liên quan đến hệ thống /sản phẩm Bài toán của khách hàng cần giải quyết Ngữ cảnh nghiệp vụ: tương tác của hệ thông/sản phẩm và đóng góp về mặc nghiệp vụ của hệ thống Mục đích xác định yêu cầu phần mềm • Khách hàng chỉ có những ý tưởng còn mơ hồ về phần mềm cần phải xây dựng để phục vụ công việc của họ. • Cho nên chúng ta phải sẵn sàng, kiên trì theo đuổi để đi từ các ý tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng cần thiết” • Khách hàng rất hay thay đổi các đòi hỏi của mình, chúng ta nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý 4 Phân loại yêu cầu • Theo 4 thành phần của phần mềm: – Các yêu cầu về phần mềm (Software) – Các yêu cầu về phần cứng (Hardware) – Các yêu cầu về dữ liệu (Data) – Các yêu cầu về con người (People, Users) • Theo cách đặc tả phần mềm – Các yêu cầu chức năng – Các yêu cầu ngoài chức năng – Các ràng buộc khác 5 2. Quy trình xác định yêu cầu PM • Phát hiện các yêu cầu phần mềm (Requirements elicitation) • Phân tích các yêu cầu phần mềm và thương lượng với khách hàng (Requirements analysis and negotiation) • Đặc tả các yêu cầu phần mềm (Requirements specification) • Mô hình hóa hệ thống (System modeling) • Kiểm tra tính hợp lý của các yêu cầu phần mềm (Requirements validation) • Quản trị các yêu cầu phần mềm (Requirements management) 6 Last Update8-07 Dept. of SE, 2002 SE-III.7 Quy trình xác định yêu cầu PM (tiếp) Vấn đề Xác định yêu cầu Xây dựng một nguyên mẫu (prototype) Tạo ra mô hình phân tích Phát triển đặc điểm kỹ thuật Xem duyệt Phát hiện yêu cầu phần mềm • Đánh giá tính khả thi về kỹ thuật và nghiệp vụ của phần mềm định phát triển • Tìm kiếm các nhân sự (chuyên gia, người sử dụng) có những hiểu biết sâu sắc nhất, chi tiết nhất về hệ thống giúp chúng ta xác định yêu cầu phần mềm • Xác định môi trường kỹ thuật trong đó sẽ triển khai phần mềm • Xác định các ràng buộc về lĩnh vực ứng dụng của phần mềm (giới hạn về chức năng/hiệu năng phần mềm) 8 Phát hiện yêu cầu phần mềm • Xác định các phương pháp sử dụng để phát hiện các yêu cầu phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ đối tác, v.v. • Thu hút sự tham gia của nhiều chuyên gia, khách hàng để chúng ta có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàng • Xác định các yêu cầu còn nhập nhằng để làm mẫu thử • Thiết kế các kịch bản sử dụng của phần mềm để giúp khách hàng định rõ các yêu cầu chính. 9 Đầu ra của bước phát hiện yêu cầu phần mềm • Bảng kê (statement) các đòi hỏi và chức năng khả thi của phần mềm • Bảng kê phạm vi ứng dụng của phần mềm • Mô tả môi trường kỹ thuật của phần mềm • Bảng kê tập hợp các kịch bản sử dụng của phần mềm • Các nguyên mẫu xây dựng, phát triển hay sử dụng trong phần mềm (nếu có) • Danh sách nhân sự tham gia vào quá trình phát hiện các yêu cầu phần mềm - kể cả các nhân sự từ phía công ty- khách hàng 10 Phân tích các yêu cầu PM và thương lượng với khách hàng N h ó m c ô n g n g h ệ p h ầ n m ề m N h ó m k h á c h h à n g 11 Phân tích các yêu cầu phần mềm và thương lượng với khách hàng 12 Cần thiết ? Nhất quán + đầy đủ ? Khả thi ? Yêu cầu không cần thiết Yêu cầu không đầy đủ, yêu cầu mâu thuẫn Yêu cầu không khả thi Đặt thứ tự ưu tiên cho các yêu cầu Thảo luận về các yêu cầu Nhất trí về các yêu cầu Thương lượng Phân tích Phân tích các yêu cầu phần mềm và thương lượng với khách hàng • Phân loại các yêu cầu phần mềm và sắp xếp chúng theo các nhóm liên quan • Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan hệ của nó với các yêu cầu phần mềm khác • Thẩm định từng yêu cầu phần mềm theo các tính chất: phù hợp, đầy đủ, rõ ràng, không trùng lặp • Phân cấp các yêu cầu phần mềm theo dựa trên nhu cầu và đòi hỏi khách hàng / người sử dụng • Thẩm định từng yêu cầu phần mềm để xác định: – Các yêu cầu PM có khả năng thực hiện được trong môi trường kỹ thuật hay không – Có khả năng kiểm định các yêu cầu phần mềm hay không 13 Phân tích các yêu cầu phần mềm và thương lượng với khách hàng • Thẩm định các rủi ro có thể xảy ra với từng yêu cầu phần mềm • Đánh giá thô (tương đối) về giá thành và thời gian thực hiện của từng yêu cầu phần mềm trong giá thành sản phẩm phần mềm và thời gian thực hiện phần mềm • Giải quyết tất cả các bất đồng về yêu cầu phần mềm với khách hàng / người sử dụng trên cơ sở thảo luận và thương lượng các yêu cầu đề ra 14 Đặc tả yêu cầu phần mềm • Đặc tả các yêu cầu phần mềm: xây dựng các tài liệu đặc tả, trong đó có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học hình thức (a formal mathematical model), tập hợp các kịch bản sử dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên • Phương pháp đặc tả: – Đặc tả phi hình thức (Informal specifications): viết bằng ngôn ngữ tự nhiên – Đặc tả hình thức (Formal specifications): viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ngữ nghĩa (sematic) rất chặt chẽ, thí dụ ký pháp đồ họa dùng các lưu đồ. • Tiêu chí đánh giá chất lượng của hồ sơ đặc tả: – Tính rõ ràng, chính xác – Tính phù hợp – Tính đầy đủ, hoàn thiện 15 Ví dụ: Các yêu cầu về hồ sơ đặc tả • Đặc tả hành vi bên ngoài của HT • Đặc tả các ràng buộc về cài đặt • Dễ thay đổi • Dùng như công cụ tham khảo cho bảo trì • Sự ghi chép cẩn thận về vòng đời của HT, nghĩa là dự đoán các thay đổi • Các đáp ứng với các sự cố không mong đợi 16 Các thành phần của hồ sơ đặc tả • Đặc tả vận hành hay đặc tả chức năng (Operational specifications): mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng: – Các dịch vụ mà hệ thống phải cung cấp – Hệ thống sẽ phản ứng với đầu vào cụ thể ra sao – Hành vi của hệ thống trong các tình huống đặc biệt. • Đặc tả mô tả hay đặc tả phi chức năng (Descriptive specifications): đặc tả các đặc tính, đặc trưng của phần mềm: – Các ràng buộc về các dịch vụ hay các chức năng hệ thống cung cấp như thời gian, ràng buộc về các quá trình phát triển, các chuẩn, • Ngoài ra còn có yêu cầu về lĩnh vực, bắt nguồn từ lĩnh vực của ứng dụng hệ thống và các đặc trưng của lĩnh vực này. 17 Đặc tả chức năng • Miêu tả các chức năng của hệ thống, phụ thuộc vào kiểu phần mềm và mong đợi của người dùng – Tương tác giữa phần mềm và môi trường, độc lập với việc cài đặt – Ví dụ: Hệ thống đồng hồ phải hiển thị thời gian dựa trên vị trí của nó • Các công cụ đặc tả tiêu biểu: – Biểu đồ luồng dữ liệu (Data Flow Diagrams) – Máy trạng thái hữu hạn (Finite State Machines) – Mạng Petri (Petri nets), – Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự nhiên. 18 Đặc tả phi chức năng và ràng buộc • Yêu cầu phi chức năng: Định nghĩa các khía cạnh sử dụng phần mềm, không liên quan trực tiếp tới các hành vi chức năng: – Các tính chất của hệ thống như độ tin cậy, thời gian trả lời, dung lượng bộ nhớ, • Thời gian trả lời phải nhỏ hơn 1 giây • Ràng buộc: do khách hàng hay môi trường thực thi phần mềm đặt ra – Các yêu cầu do tổ chức qui định như qui định chuẩn về quá trình tiến hành, chuẩn tài liệu, • Ngôn ngữ cài đặt phải là COBOL – Các yêu cầu từ bên ngoài • Phải giao tiếp với hệ thống điều phối được viết vào năm 1956. • Thường sử dụng các công cụ – Biểu đồ thực thể liên kết (Entity-Relationship Diagrams) – Đặc tả Logic (Logic Specifications) – Đặc tả đại số (Algebraic Specifications) → Khó phát biểu chính xác, Rất khó kiểm tra 19 Tài liệu yêu cầu • Tài liệu về yêu cầu là các phát biểu chính thức về cái được yêu cầu bởi các nhà phát triển HT • Nó bao gồm cả 2 phần: định nghĩa và đặc tả yêu cầu • Nó không phải là tài liệu thiết kế. Tốt hơn có thể nó chỉ là 1 tập các cái mà HT phải làm hơn là HT phải làm thế nào (PT chứ không phải là TK) 20 Nội dung cần có của tài liệu yêu cầu 21 Khách hàng hệ thống Nhà quản lý Kỹ sư hệ thống Kỹ sư kiểm thử hệ thống Kỹ sư bảo trì hệ thống Xác định các yêu cầu, đọc hiểu để kiểm tra xem có đúng với nhu cầu hay không. Họ xác định các thay đổi về yêu cầu. Sử dụng tài liệu về yêu cầu để lên kế hoạch đấu thầu cho hệ thống và lên kế hoạch cho quá trình phát triển hệ thống Sử dụng yêu cầu để hiểu về hệ thống sẽ phát triển Sử dụng yêu cầu để phát triển các trường hợp kiểm thử cho hệ thống Sử dụng yêu cầu để hiểu về hệ thống và mối liên hệ giữa các phấn khác nhau của hệ thống 3. Phương pháp và công cụ đặc tả yêu cầu phần mềm • Biểu đồ phân cấp chức năng - WBS (work break down structure) • Biểu đồ luồng dữ liệu – DFD (data flow diagram) • Máy trạng thái – FSM (Finite state machine) • Sơ đồ thực thể liên kết – ERD (entity relation diagram) 22 Đặc tả chức năng với DFD • Hệ thống (System): tập hợp các dữ liệu (data) được xử lý bằng các chức năng tương ứng (functions) • Các ký pháp sử dụng: Thể hiện các chức năng (functions) Thể hiện luồng dữ liệu Kho dữ liệu Vào ra dữ liệu và tương tác giữa hệ thống và người sử dụng 23 Ví dụ: mô tả biểu thức toán học bằng DFD + * * + b a a d c (a+b)*(c+a*d)-e*(a+b) 24 Ví dụ đặc tả các chức năng của thư viện qua DFD Có sách Tìm theo chủ đề Yêu cầu từ người mượn Kho sách Danh sách tác giả Danh sách tên sách Danh sách chủ đề Chủ đề yêu cầu Đưa ra Tên sách Danh sách người mượn Thông tin về sách Sách Chủ đề Tên tác giả Tên sách Liệt kê các tên sách liên quan đến chủ đề Tên sách; Tên người mượn Sách Tên sách, tác giả Tên người mượn 25 Các hạn chế của DFD • Ý nghĩa của các ký pháp sử dụng được xác định bởi các định danh lựa chọn của NSD • Ví dụ: DFD của chức năng tìm kiếm sách: If NSD nhập vào cả tên tác giả và tiêu đề sách Then tìm kiếm sách tương ứng, không có thì thông báo lỗi Elseif chỉ nhập tên tác giả Then hiển thị danh sách các sách tương ứng với tên tác giả đã nhập và yêu cầu NSD lựa chọn sách Elseif chỉ nhập tiêu đề sách Then . . . Endif 26 Các hạn chế của DFD • Trong DFD không xác định rõ các hướng thực hiện (control aspects) • Biểu đồ DFD này không chỉ rõ đầu vào là gì để thực hiện chức năng D và đầu ra là gì sau khi thực hiện chức năng D. • Chức năng D có thể cần cả A, B và C • Chức năng D có thể chỉ cần một trong A, B và C để thực hiện • Chức năng D có thể kết xuất kết quả cho một trong E và F • Chức năng D có thể kết xuất kết quả chung cho cả E và F • Chức năng D có thể kết xuất kết quả riêng cho cả E và F A B C D F E 27 Các hạn chế của DFD • DFD không xác định sự đồng bộ giữa các chức năng / mô-đun – A xử lý dữ liệu và B được hưởng (nhận) các kết quả được xử lý từ A – A và B là các chức năng không đồng bộ (asynchronous activities) vì thế cần có buffer để ngăn chặn tình trang mất dữ liệu A B 28 Đặc tả trạng thái với FSM - Finite State Machines • FSM chứa – Tập hữu hạn các trạng thái Q – Tập hữu hạn các đầu vào I – Các chức năng chuyển tiếp • ON OFF Báo động áp lực cao Báo động nhiệt độ cao Khởi động lại δ : Q x I → Q 29 Ví dụ: quản lý thư viện • Xét các giao dịch: – Mượn sách / Trả sách – Thêm đầu sách / Loại bỏ đầu sách – Liệt kê danh sách các đầu sách theo tên tác giả hay theo chủ đề – Tìm kiếm sách theo các yêu cầu của người mượn – Tìm kiếm sách quá hạn trả, . . . 30 Đặc tả yêu cầu • Độc giả không được mượn quá một số lượng sách nhất định, trong một thời gian nhất định • Một số sách không được mượn về • Một số người không được mượn một số loại sách nào đó, . . . 31 Đặc tả các đối tượng • Các đối tượng: – Tên sách – Mã quyển – Nhân viên phục vụ – Người mượn • Cần có: – tập hợp (danh sách) các tiêu đề sách – danh sách các tác giả cho từng quyển sách, – danh sách các chủ đề liên quan của các quyển sách 32 FSM đặc tả trạng thái • Ta có tập hợp các sách (mỗi đầu sách có thể có nhiều quyển sách trong thư viện). • Mỗi quyển sách có thể có 1 trong 5 trạng thái sau: – (AV) Available: được phép mượn, – (CO) - (BR): đã mượn (Check Out; Borrow), – (L): Last, – (R): Remove CO AV BR L R Có thể có hạn chế về số sách được mượn cho 1 nhóm độc giả hoặc mọi độc giả, . . . 33 Đặc tả dữ liệu với Mô hình thực thể liên kết -ERD • Mô hình khái niệm cho phép đặc tả các yêu cầu logic của hệ thống, thường được sử dụng trong các hệ thống dữ liệu lớn • ER Model – Thực thể – Quan hệ – Thuộc tính • Biểu đồ thực thể 34 Thực thể • Thực thể : tập hợp các thông tin liên quan cần được xử lý trong phần mềm • Thực thể có thể có mối quan hệ: – người sở hữu ôtô • Thực thể có các thuộc tính Người sở hữu Ôtô 35 Thuộc tính • Tính chất của một thực thể hoặc một đối tượng dữ liệu – đặt tên cho 1 mẫu (instance) của đối tượng dữ liệu – mô tả mẫu (instance) – tạo liên kết (reference) đến các mẫu khác Car Ford Blue ID Automobile Company Ford Tập các thuộc tính của 1 đối tượng dữ liệu được xác định thông qua ngữ cảnh của bài toán. 36 Quan hệ • Chỉ ra mối liên quan gữa các đối tượng dữ liệu Bookstore Orders Books 1 N ➢ Cardinality : chỉ ra định lượng của mối quan hệ 1:1 one-to-one 1:N one-to-many M:N many-to-many ➢Modality : 0 – có thể có, có thể không có quan hệ 1 – bắt buộc có quan hệ Customer Is provided with Repair Action 1 N 37 Ví dụ: ERD mô tả thư viện Area Title Author Deals with Written by Belongs to Copy holds Was held by Borrower state 1 M N N N Text 1 limit 38 So sánh 39 DFD FSM ERD Đơn giản, dễ hiểu. Mô tả luồng dữ liệu Không xác định rõ hướng thực hiện Không thể hiện tính tuần tự hay song song của tiến trình Có thể phức tạp với số lượng trạng thái lớn Mô tả trạng thái của thực thể Xác định rõ hướng thực hiện Thể hiện tốt tính song song và tuần tự Đơn giản, dễ hiểu Mô tả trừu tượng cơ sở dữ liệu Không xác định rõ hướng thực hiện Không thể hiện tính tuần tự hay song song Thế nào là một đặc tả tốt? • Dễ hiểu với người dùng • Có ít điều nhập nhằng • Có ít quy ước khi mô tả, có thể tạo đơn giản • Với phong cách từ trên xuống (topdown) • Dễ triển khai cho những pha sau của vòng đời: thiết kế hệ thống và thiết kế chương trình và giao diện dễ làm, đảm bảo tính nhất quán, . . . 40 Thế nào là một đặc tả tốt? 41 Hệ thống đặt hàngKhách hàng Kho hàng Đặt hàng Hoá đơn Khách hàng mới Mặt hàng Phiếu hàng Thông báo chuyển hàng 42 Customer 2.1 Verify Customer Order D Customer 1 Master Need to establish Customer 2.2 Verify Item Order D Inventory 2 Master Notify Valid 2.3 Check Available 2.4 Update Commit 2.5 Create Order D Inventory 2 Master D Shipping 4 Taxes D Back 3 Order Valid Item Back Order Avail Update Tax Ord Pending Order 4. Nguyên lý phân tích yêu cầu sử dụng Mô hình hóa dữ liệu • Xác định các đối tượng dữ liệu • Xác định các đặc tính của các đối tượng dữ liệu • Thiết lập các mối quan hệ giữa các đối tượng dữ liệu 43 Mô hình hóa các chức năng • Xác định các chức năng chuyển đổi đối tượng dữ liệu • Chỉ ra luồng dữ liệu đi qua hệ thống như thế nào • Biểu diễn bộ phận sản sinh dữ liệu và bộ phận tiêu thụ dữ liệu 44 Mô hình hóa hành vi • Chỉ ra các trạng thái (states) khác nhau của hệ thống • Đặc tả các hiện tượng (events) làm hệ thống thay đổi trạng thái 45 Phân mảnh các mô hình • Tinh lọc từng mô hình để biểu diễn các mức trừu tượng thấp hơn • Lọc đối tượng dữ liệu • Tạo ra phân cấp chức năng • Biểu diễn hành vi (behavior) ở các mức chi tiết khác nhau 46 Bản chất của việc phân tích • Hãy bắt đầu bằng cách tập trung vào bản chất của vấn đề chứ không xem xét những chi tiết cài đặt 47 NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (INTRODUCTION TO SOFTWARE ENGINEERING) 1 Chương 8: Xây dựng phần mềm • 1. Khái niệm 2 1. Khái niệm • Mã hóa là quá trình chuyển đổi thiết kế của một hệ thống sang một ngôn ngữ máy. • Giai đoạn viết mã này liên quan đến việc chuyển đặc tả thiết kế thành mã nguồn. • Việc biên soạn tài liệu đi kèm với mã nguồn là cần thiết để có thể dễ dàng xác minh sự phù hợp giữa mã với bản đặc tả của nó. • Công việc mã hóa được thực hiện bởi lập trình viên là người độc lập với người thiết kế. Mục tiêu không phải là giảm nỗ lực và chi phí của giai đoạn mã hóa, mà là để cắt giảm chi phí của các giai đoạn sau. • Chi phí kiểm thử và bảo trì có thể được giảm đáng kể với việc mã hóa hiệu quả. 3 Mục tiêu của lập trình • 1. Để chuyển thiết kế của hệ thống sang ngôn ngữ máy, thực hiện các tác vụ theo chỉ định của thiết kế. • 2. Để giảm chi phí của các giai đoạn sau: Chi phí kiểm tra và bảo trì có thể giảm đáng kể với việc mã hóa hiệu quả. • 3. Làm cho chương trình dễ đọc hơn: Chương trình phải dễ đọc và dễ hiểu. Việc mã hóa cần đảm bảo mục tiêu làm tăng khả năng hiểu mã và đọc mã trong quá trình tạo ra phần mềm dễ bảo trì. Để tiến hành việc cài đặt thiết kế, cần phải sử dụng ngôn ngữ lập trình bậc cao. 4 Translating from High-level Language to Binary 5 Total = 0 Current = 100 do while current 0 Total = Total + Current Current = Current - 1 Loop 10111000 101110001 00000000 01100100 00000001 11001000 01001001 01110101 11111011 Translation Program High level language program Machine language progam 2. Lịch sử ngôn ngữ lập trình • Các ngôn ngữ thế hệ thứ nhất: – Ngôn ngữ lập trình mã máy (machine code) – Ngôn ngữ lập trình assembly • Các ngôn ngữ thế thế thứ hai: – FOTRAN, COBOL, ALGOL, BASIC – Phát triển 1950-1970 • Các ngôn ngữ thế hệ thứ ba – Ngôn ngữ lập trình cấp cao vạn năng (cấu trúc) – Lập trình hướng đối tượng – Lập trình hướng suy diễn – logic • Các ngôn ngữ thế hệ thứ tư 6 7Các loại ngôn ngữ lập trình Procedural: Các chương trình nguyên khối chạy từ đầu đến cuối và không có sự can thiệp của người dùng ngoài đầu vào Basic, QBasic, QuickBasic COBOL FORTRAN C Object Oriented/Event Driven (OOED): Các chương trình sử dụng các objects để đáp ứng các sự kiện (events); sử dụng các đoạn mã cho mỗi object JAVA Visual Basic Visual Basic for Applications (VBA) Visual C++ Các đặc điểm của ngôn ngữ lập trình 8 3. Các công cụ lập trình • Môi trường: DOS, WINDOWS, UNIX/LINUX • Editors, Compilers, Linkers, Debuggers • TURBO C, PASCAL • MS C, Visual Basic, Visual C++, ASP • UNIX/LINUX: C/C++, gcc (Gnu C Compiler) • JAVA, CGI, perl • C#, .NET 9 Các công cụ lập trình • Công cụ lập trình C/C++: – Turbo C – Visual Studio – Eclipse • Công cụ lập trình Java – Eclipse – Netbean • Công cụ lập trình C#, .NET – Visual Studio.NET – MSDN Library • Công cụ lập trình web – Visual Studio và SQL Server 10 4. Quy trình lập trình • Xác định bài toán – Đầu vào – Đầu ra • Các bước xử lý để tạo kết quả Input Processing Output Num-1 Read 3 numbers Total Num-2 Add numbers together Num-3 Print Total number Các bước trong lập trình • Lập trình • Kiểm tra thuật toán đã được cài đặt • Thực hiện chương trình trên máy tính – Compile – Correct syntax errors – Run program with test data – Correct logic errors • Viết tài liệu Phương pháp lập trình có cấu trúc • Outline Solution – Nhiệm vụ chính – Các bước xử lý chính – Các cấu trúc điều khiển chính (vòng lặp, rẽ nhánh, v.v.) – Các biến chính Phương pháp lập trình có cấu trúc • Chia toàn bộ chương trình thành các mô-đun nhỏ để chương trình trở nên dễ hiểu. Mục đích của lập trình cấu trúc là tuyến tính hóa luồng điều khiển thông qua một chương trình máy tính sao cho trình tự thực thi tuân theo trình tự mà mã được viết. • Cấu trúc động của chương trình giống với cấu trúc tĩnh của chương trình. Điều này nâng cao khả năng đọc, khả năng kiểm tra và khả năng sửa đổi của chương trình. Luồng kiểm soát tuyến tính này có thể được quản lý bằng cách hạn chế tập hợp các cấu trúc ứng dụng được phép thành một mục nhập duy nhất, các định dạng lối ra duy nhất. • Chúng tôi sử dụng lập trình có cấu trúc vì nó cho phép người lập trình hiểu chương trình một cách dễ dàng. Nếu một chương trình bao gồm hàng nghìn lệnh và một lỗi xảy ra thì rất phức tạp để tìm ra lỗi đó trong toàn bộ chương trình, nhưng trong lập trình có cấu trúc, chúng ta có thể dễ dàng phát hiện lỗi và sau đó đến vị trí đó và sửa nó. Điều này giúp tiết kiệm rất nhiều thời gian. 14 Lập trình có cấu trúc • Cho phép người lập trình hiểu chương trình một cách dễ dàng. • Trong lập trình có cấu trúc, chúng ta có thể dễ dàng phát hiện lỗi và tìm đến vị trí để sửa nó. • Điều này giúp tiết kiệm rất nhiều thời gian. 15 Rule 1: Code Block 16 • Nếu điều kiện đầu vào đúng, nhưng điều kiện thoát sai thì lỗi đó phải nằm trong khối. Điều này không đúng nếu việc thực thi được phép nhảy vào một khối (do đó lỗi có thể ở bất kỳ đâu trong chương trình, gỡ lỗi trong những trường hợp này khó hơn nhiều). • Rule 1 of Structured Programming: Một khối mã được cấu trúc, như thể hiện trong hình. Trong điều kiện biểu đồ luồng, một hộp có một điểm vào và một điểm thoát được cấu trúc. Lập trình có cấu trúc là một phương pháp làm rõ ràng rằng chương trình là đúng. Rule 2: Sequence • Một chuỗi khối là đúng nếu điều kiện thoát của mỗi khối khớp với điều kiện vào của khối sau. • Toàn bộ chuỗi có thể được coi là một khối duy nhất, có điểm vào và điểm ra. • Rule 2 of Structured Programming: Hai hoặc nhiều khối được kết nối liền nhau 17 Rule Three: Alternation • Rule 3 of Structured Programming: Tùy chọn If-then-else, mỗi lựa chọn là một khối mã. Cấu trúc rẽ nhánh được sử dụng để đáp ứng điều kiện thoát. 18 Rule 4: Iteration • Rule 4 of Structured Programming: Vòng lặp (trong khi) gồm một điểm vào và một điểm ra. Điểm vào có điều kiện phải được thỏa mãn và điểm ra có các yêu cầu sẽ được đáp ứng. Không có bước nhảy vào biểu mẫu từ các điểm bên ngoài của mã. 19 Rule 5: Nested Structures • Rule 5 of Structured Programming: Một cấu trúc có một điểm vào và ra duy nhất 20 21 Object-Oriented Event-driven Programming (OOED) OOED sử dụng các đối tượng objects, hoặc các modules độc lập kết hợp dữ liệu và mã chương trình để chuyển các message cho nhau. OOED dễ làm việc hơn vì nó trực quan hơn các phương pháp lập trình truyền thống. Ví dụ: Visual Basic Người dùng có thể kết hợp các đối tượng một cách tương đối dễ dàng để tạo ra các hệ thống mới hoặc mở rộng các hệ thống hiện có. Thuộc tính của đối tượng là thuộc tính liên kết với một đối tượng. Phương thức của đối tượng là những hoạt động mà đối tượng có thể thực hiện. Đối tượng phản hồi các sự kiện. 22 OOED Programming Process Quy trình sáu bước để viết một chương trình máy tính OOED: 1. Xác định vấn đề. 2. Tạo giao diện 3. Phát triển logic cho các đối tượng hành động 4. Viết và kiểm tra mã cho các đối tượng hành động 5. Kiểm tra dự án tổng thể 6. Làm tài liệu Bất kể một chương trình được viết tốt như thế nào, mục tiêu sẽ không đạt được nếu chương trình không giải quyết được vấn đề (sai). 23 Step One: Define Problem • Trước khi tạo ứng dụng máy tính để giải quyết một vấn đề, trước tiên cần phải xác định rõ nó. • Cần xác định đầu vào và đầu ra. • Phải xác định dữ liệu được đưa vào chương trình và kết quả được xuất ra từ nó. • Phác thảo giao diện (giao tiếp) ứng dụng. • Xác định các hành động của các đối tượng cần mã hóa. 24 Ví dụ. Giao diện tính toán doanh thu 25 Step Two: Create Interface • Ví dụ: tạo giao diện tính toán doanh thu. – button for action – inputBox for input (Selling Price) – inputBox for input (Units Sold) – MessageBox for output 26 Calculate Revenue Interface - Input 27 Calculate Revenue Interface - Output 28 Step Three: Develop Logic for Action Objects • Xác định mỗi đối tượng hành động làm gì để phản ứng với các sự kiện. Đây là logic cho từng đối tượng. • Sử dụng Bảng Nhập / Xử lý / Đầu ra (IPO) và Mã giả để phát triển logic • Bảng IPO hiển thị các đầu vào, đầu ra và quá trình xử lý để chuyển đầu vào thành đầu ra 29 IPO Table for Calculate Revnue Button Input Processing Output Unit Price Quantity Sold revenue = unitPrice X quantitySold Revenue 30 Pseudocode for Count High Values Button Begin procedure Input Selling Price Input Quantity Sold Revenue = Selling Price x Quantity Sold Output Revenue End procedure 31 Step Four: Write and Test Code of Action Objects • Chuyển đổi logic được thể hiện trong mã giả sang ngôn ngữ lập trình (sử dụng bộ từ vựng và cú pháp của một ngôn ngữ). • Kiểm tra và sửa mã đối tượng được viết, giai đoạn này được gọi là gỡ lỗi. 32 VBA Code for Calculate Revenue Button Sub CalculateRevenue() Dim unitPrice As Currency Dim quantitySold As Integer Dim revenue As Currency ' Get the user's inputs, then calculate revenue. unitPrice = InputBox("Enter the unit selling price.", "Selling price") quantitySold = InputBox("Enter the number of units sold.", "Units sold") revenue = unitPrice * quantitySold ' Report the results. MsgBox "The revenue from this product was " & Format(revenue, "$#,##0") _ & ".", vbInformation, "Revenue" End Sub 33 Step Five: Test Overall Project • Kiểm tra toàn bộ project cần đảm bảo mỗi câu lệnh phải hoàn toàn chính xác nếu không thì chương trình có thể sẽ có lỗi. • Cần đảm bảo chương trình được kiểm tra trên môi trường và dữ liệu thực thi thực tế mà chương trình sẽ được sử dụng. 34 Step Six: Document Project in Writing • Tài liệu bao gồm các mô tả bằng hình ảnh và văn bản của phần mềm trong đó chứa các mô tả phần lập trình và các mô tả hoặc hướng dẫn bên ngoài. • Tài liệu là cần thiết vì dù sớm hay muộn, chương trình sẽ cần được bảo trì (sửa lỗi, thêm tính năng mới, xử lý các vấn đề chưa từng nghĩ tới, v.v.) Điều này KHÔNG thể thực hiện được nếu không có tài liệu. • Tài liệu có thể bao gồm sách, hướng dẫn sử dụng và các mục tiêu của phần mềm. 5. Quy ước viết mã 35 Hướng dẫn viết mã • Nguyên tắc viết mã cung cấp cho lập trình viên một tập hợp các phương pháp • làm cho các chương trình đễ đọc và bảo trì. 36 Hướng dẫn viết mã 37 Hướng dẫn viết mã 1. Line Length: It is considered a good practice to keep the length of source code lines at or below 80 characters. Lines longer than this may not be visible properly on some terminals and tools. Some printers will truncate lines longer than 80 columns. 2. Spacing: The appropriate use of spaces within a line of code can improve readability. Example: Bad: cost=price+(price*sales_tax) fprintf(stdout ,"The total cost is %5.2f\n",cost); Better: cost = price + ( price * sales_tax ) fprintf (stdout,"The total cost is %5.2f\n",cost); 3. The code should be well-documented: As a rule of thumb, there must be at least one comment line on the average for every three-source line. 38 Hướng dẫn viết mã 4. The length of any function should not exceed 10 source lines: A very lengthy function is generally very difficult to understand as it possibly carries out many various functions. For the same reason, lengthy functions are possible to have a disproportionately larger number of bugs. 5. Do not use goto statements: Use of goto statements makes a program unstructured and very tough to understand. 6. Inline Comments: Inline comments promote readability. 7. Error Messages: Error handling is an essential aspect of computer programming. This does not only include adding the necessary logic to test for and handle errors but also involves making error messages meaningful. 39 Phong cách lập trình • Các kỹ thuật được sử dụng để viết mã nguồn cho một chương trình. Hầu hết các phong cách lập trình được thiết kế để giúp lập trình viên nhanh chóng đọc và hiểu chương trình cũng như tránh mắc lỗi. • Một phong cách viết mã tốt có thể khắc phục nhiều khiếm khuyết của ngôn ngữ lập trình. • Mục tiêu của phong cách lập trình tốt là cung cấp mã đơn giản và dễ hiểu. • Phong cách lập trình được sử dụng trong một chương trình khác nhau có thể bắt nguồn từ các tiêu chuẩn mã hóa hoặc quy ước mã của một công ty hoặc tổ chức máy tính khác, cũng như sở thích của lập trình viên thực tế. 40 Phong cách lập trình 41 Phong cách lập trình • 1. Clarity and simplicity of Expression: The programs should be designed in such a manner so that the objectives of the program is clear. • 2. Naming: In a program, you are required to name the module, processes, and variable, and so on. Care should be taken that the naming style should not be cryptic and non-representative. • For Example: a = 3.14 * r * r area of circle = 3.14 * radius * radius; • 3. Control Constructs: It is desirable that as much as a possible single entry and single exit constructs used. • 4. Information hiding: The information secure in the data structures should be hidden from the rest of the system where possible. Information hiding can decrease the coupling between modules and make the system more maintainable. 42 Phong cách lập trình • 5. Nesting: Deep nesting of loops and conditions greatly harm the static and dynamic behavior of a program. It also becomes difficult to understand the program logic, so it is desirable to avoid deep nesting. • 6. User-defined types: Make heavy use of user-defined data types like enum, class, structure, and union. These data types make your program code easy to write and easy to understand. • 7. Module size: The module size should be uniform. The size of the module should not be too big or too small. If the module size is too large, it is not generally functionally cohesive. If the module size is too small, it leads to unnecessary overheads. • 8. Module Interface: A module with a complex interface should be carefully examined. • 9. Side-effects: When a module is invoked, it sometimes has a side effect of modifying the program state. Such side-effect should be avoided where as possible. 43 NHẬP MÔN CÔNG NGHỆ PHẦN MỀM (INTRODUCTION TO SOFTWARE ENGINEERING) 1 MỘT SỐ CHỦ ĐỀ KHÁC • Ước lượng chi phí phần mềm (SE Cost Estimation) 1. Năng suất (Productivity) 2. Các kỹ thuật ước lượng (Estimation Techniques) 3. Mô hình chi phí thuật toán (Algorithmic Cost Model) 4. Nhân lực và thời gian dự án (Project duration and staffing) • Quản lý chất lượng (Quality Management) • Cải tiến quy trình (Process Improvement) • Khác 2 1. Năng suất (Productivity) • Năng suất là số đơn vị đầu ra trên số giờ làm việc • Trong SE, năng suất có thể ước lượng bởi một số thuộc tính chia cho tổng số nỗ lực để phát triển: – Số đo kích thước (thí dụ số dòng lệnh) – Số đo chức năng (số chức năng tạo ra trên 1 khoảng thời gian ) SE-VI.3 2. Các kỹ thuật ước lượng (Estimation Techniques) • Mô hình chi phí thuật toán: sử dụng các thông tin có tính lịch sử (thường là kích thước) – Ý kiến chuyên gia – Đánh giá tương tự: chỉ áp dụng khi có nhiều dự án trong cùng một lĩnh vực – Luật Parkinson: chi phí phụ thuộc thời gian và số nhân công – Giá để thắng thầu: phụ thuộc khả năng KH SE-VI.4 3. Mô hình chi phí thuật toán (Algorithmic Cost Model) • Nguyên tắc: Dùng một phương trình toán học để dự đoán (Kitchenham 1990a) dạng: Cố gắng = C x PMs x M với: – C là độ phức tạp – PM là số đo năng suất – M là hệ số phụ thuộc và quá trình, năng suất – s được chọn gần với 1, phản ánh độ gia tăng của yêu cầu với các dự án lớn • Chú ý: – Rất khó dự đoán PM vào giai đoạn đầu – Việc dự đoán C và M là khách quan và có thể thay đổi từ người này sang người khác. SE-VI.5 a. Mô hình COCOMO (Boehm 1981) • Mô hình COCOMO tuân theo PT trên, với các lựa chọn sau: – Đơn giản: PM = 2,4 (KDSI)1,05 x M – Khiêm tốn: PM = 3,0 (KDSI)1,12 x M – Lồng nhau: PM = 3,6 (KDSI)1,20 x M • với KDSI (kilo delivered source instructions) là số lệnh nguồn theo đơn vị nghìn SE-VI.6 b. Mô hình định cỡ (calibrate model) • Sử dụng một mô hình ước đoán có hiệu quả, do vậy cần có 1 CSDL về phân lịch và các cố gắng của một dự án trọn vẹn. • Có thể dùng kết hợp với mô hình COCOMO 7 c. Mô hình chi phí thuật toán trong lập kế hoạch dự án • Dùng để đánh giá chi phí đầu tư nhằm giảm chi phí • Có 3 thành phần phải xem xét trong khi tính chi phí DA. – Chi phí phần cứng của HT – Chi phí phương tiện, thiết bị (máy tính, phần mềm) trong phát triển HT – Chi phí của các nỗ lực yêu cầu • Chi phí phần mềm (Software Cost) được tính: – SC = Basic Cost x RELY x TIME x STOR x TOOL x EXP x lương TB 1 người/tháng với: STOR là không gian lưu trữ, TIME là thời gian cần thiết, TOOL là công cụ, EXP là kinh nghiệm, RELY là độ tin cậy (có thể chọn là 1,2) SE-VI.8 4. Nhân lực và thời gian dự án (Project duration and staffing) • Mô hình COCOMO cũng dự đoán lịch cho một DA trọn vẹn: – Dự án đơn giản: TDEV = 2.5 (PM)0.38 – Dự án trung bình: TDEV = 2.5 (PM)0.35 – Dự án lồng: TDEV = 2.5 (PM)0.32 với TDEV là tổng thời gian cần thiết cho một DA SE-VI.9 MỘT SỐ CHỦ ĐỀ KHÁC • Ước lượng chi phí phần mềm (SE Cost Estimation) • Quản lý chất lượng (Quality Management) 1. Đảm bảo chất lượng quá trình 2. Xem xét lại chất lượng 3. Các chuẩn phần mềm 4. Các chuẩn tài liệu 5. Độ đo phần mềm 6. Độ đo chất lượng sản phẩm • Cải tiến quy trình (Process Improvement) • Khác 10 1. Đảm bảo chất lượng quy trình • Đảm bảo chất lượng quy trình là một khái niệm đa chiều. chưa có định nghĩa rõ ràng. Nhìn chung khái niệm này có thể xem như là phát triển SP phải đáp ứng được đặc tả của nó (Crossby, 1979) • Đặc tả phải hướng về đặc trưng SP mà KH muốn • Chúng ta không biết đặc tả thế nào về chất lượng • Đặc tả phần mềm luôn luôn không đầy đủ • Quản lý chất lượng là đáp ứng 3 loại hoạt động sau: • Đảm bảo chất lượng • Kế hoạch chất lượng: chọn thủ tục tương ứng, chuẩn và kích thước • Điều khiển chất lượng: các thủ tục và chuẩn phải được tôn trọng SE-VI.11 Đảm bảo chất lượng quy trình(tiếp) SE-VI.12 Định nghĩa Quá trình Phát triển sản phẩm KĐ chất lượng sản phẩm Quá trình cải tiến Chất lượng Quá trình chuẩn hoá C K Chất lượng dựa vào quá trình 2. Xem xét lại chất lượng • Là phương pháp chính để khẳng định chất lượng của quá trình sản xuất • 3 kiểu xem xét: – Thanh tra thiết kế hay chương trình – Xem xét tiến triển – Xem xét chất lượng SE-VI.13 Lựa chọn đội ngũ Sắp xếp vị trí và thời gian Phân bố tài liệu Xem xét xem xét đầy đủ 3. Các chuẩn phần mềm • Vai trò quan trọng của ĐBCLPM là chuẩn hoá các sản phẩm và quá trình • Tầm quan trọng: – Cung cấp SP tương ứng và thực tế – Cung cấp các framework để cài đặt cá quá trình ĐBCL – Đảm bảo tính liên tục: công việc thực hiện bởi 1 người có thể thực hiện tiếp bởi người khác SE-VI.14 4. Các chuẩn tài liệu • Tài liệu là 1 phần quan trọng trong SE để theo dõi, để hiểu và để làm • 3 kiểu chuẩn tài liệu: – Các chuẩn của quá trình lập tài liệu: Qui định chuẩn khi tạo tài liệu – Chuẩn TL: Chuẩn để quản trị chính TL đó – Chuẩn trao đổi TL: Dùng trong trao đổi qua E-mail, copy hay lưu trữ trong CSDL SE-VI.15 5. Độ đo phần mềm (Software Metric) • Độ đo phần mềm là một kiểu độ đo liên quan đến HT phần mềm, quá trình hay TL, Thí dụ như số dòng lệnh, số thông báo lỗi khi cung cấp SP • Hai lớp độ đo: Độ đo ĐK và độ đo dự đoán SE-VI.16 Quá trình PM Sản phẩm PM Độ đo ĐK Độ đo Dự đoán Các quyết định QL 6. Độ đo chất lượng SP • Việc biểu diễn, đánh giá độ đo bằng các số liệu hơn là kinh nghiệm • Độ đo chất lượng thiết kế – tính liên kết – độ liên kết – dễ hiểu – thích hợp • Độ đo chất lượng chương trình – chiều dài mã – Độ phức tạp – Mức lồng điều kiện SE-VI.17 MỘT SỐ CHỦ ĐỀ KHÁC • Ước lượng chi phí phần mềm (SE Cost Estimation) • Quản lý chất lượng (Quality Management) • Cải tiến quy trình (Process Improvement) 1. Chất lượng quy trình và sản phẩm 2. Mô hình hoá và phân tích quy trình 3. Độ đo 4. Mô hình thuần thục khả năng SEI 5. Phân loại quy trình • Khác 18 Mở đầu • Cải tiến quy trình có nghĩa hiểu quy trình tồn tại và thay đổi quy trình này để nâng cao chất lượng SP hay giảm chi phí & thời gian phát triển • Không đơn giản là chấp nhận 1 phương pháp hay công cụ đặc biệt nào hay sử dụng 1 mô hình quy trình đã sử đâu đó • Cải tiến quy trình phải được xem xét như 1 hoạt động đặc biệt trong 1 tổ chức hoặc 1 phần của tổ chức lớn SE-VI.19 Sơ đồ khái quát của Quá trình cải tiến quy trình SE-VI.20 Phân tích Quy trình Xác định Các cải tiến Xác định các thay đổi Đào tạo đội ngũ Hiệu chỉnh Các thay đổi Mô hình Quy trình Lập kế hoạch Kế hoạch đào tạo Mô hình xem xét lại Phản hồi Phân tích quy trình: xem xét quy trình đã tồn tại, tạo ra mô hình quy trình để lập TL và hiểu quy trình đó Xác định cải tiến: sử dụng kết quả phân tích để xác định chất lượng, lập lịch hay chi phí những pha gay cấn Xác định thay đổi: Thiết lập các thủ tục, phương pháp, công cụ mới và tích hợp với các cái đã tồn tại Đào tạo: không đào tạo quy trình sẽ thất bại Hiệu chỉnh thay đổi: các thay đổi có tác dụng ngay với HT 1. Chất lượng quy trình và sản phẩm • Xem chương trước 21 2. Mô hình hoá và phân tích quy trình • Vai trò: nghiên cứu các quy trình đang tồn tại và phát triển mô hình trừu tượng cho các quy trình này (thâu tóm các đặc trưng) • Phân tích là nghiên cứu để hiểu mối liên quan giữa các phần của quy trình. Điểm xuất phát là mô hình hình thức đã sử dụng • Kỹ thuật: – Hỏi và phỏng vấn – Kỹ thuật Ethnographic: dùng để hiểu bản chất của phát triển phần mềm như các hoạt động của con người SE-VI.22 Mô hình hoá (tiếp) • Các ký pháp dùng trong mô hình: – Activity (hoạt động): biểu diễn bởi hình chữ nhật tròn – Process (quá trình): tập các hoạt động, biểu diễn bởi hình chữ nhật tròn có bóng mờ – Deliverable (phân phối): biểu diễn bởi 1 hình chữ nhật có bóng mờ. Nó là đầu ra của 1 hoạt động – Condition (điều kiện): biểu diễn bởi 1 hình chữ nhật. Nó là tiền hay hậu điều kiện – Role (vai trò): biểu diễn bởi hình tròn – Exception (Ngoại lệ): Hộp bao kép. Việc thay đổi do một sự kiện nào đó – Communication (Giao tiếp): Biểu diễn trao đổi thông tin giữa con người với nhau hay với HT SE-VI.23 3. Độ đo quy trình • Độ đo của 1 quy trình là các dữ liệu định lượng về quy trình phần mềm (Tập các độ đo là chủ yếu cho quá trình cải tiến quy trình –Humphey, 1989). • Phân loại: – Thời gian để thực hiện 1 quy trình đặc biệt – Tài nguyên yêu cầu cho 1 quy trình đặc biệt – Số các biến cố • Khó khăn: Cái nào là cần định lượng đo đếm. Tuy nhiên có thể xem: mục đích (Goals, Câu hỏi, Độ đo) SE-VI.24 4. Mô hình thuần thục khả năng (của SEI) • Viện CNPM (SEI) Carnegie-Melon-University đề xuất. Mô hình SEI phân quá trình phần mềm thành 5 mức khác nhau: – Mức khởi đầu: 1 tổ chức không quản lý thực sự các thủ tục hay DA. Phần mềm có thể phát triển song không thể dự đoán trước (ngân sách, thời gian, . . .) – Mức lặp: 1 tổ chức có thể có quản lý hình thức về đảm bảo chất lượng, các thủ tục điều khiển cấu hình. Tổ chức có thể lặp lại các DA cùng kiểu – Mức có định nghĩa: ở mức này, một tổ chức có định nghĩa các qua trình của mình mà như vậy có 1 cơ sở cho quá trình cải tiến chất lượng. Các thủ tục hình thức đảm bảo rằng các quá trình đã định là sẽ được tuân thủ SE-VI.25 Mô hình thuần thục khả năng SEI (tiếp) – Mức được quản trị: 1 tổ chức đã định nghĩa các quá trình và 1 CT để thu thập dữ liệu về chất lượng. Số đo quá trình và thủ rục được sưu tập cho quá các hoạt động của quá trình cải tiến – Mức tối ưu: Đã thoả thuận tiếp tục quá trình cải tiến. Quá trình này có ngân sách và kế hoạch để thực hiện và là phần tích hợp của quá trình tổ chức SE-VI.26 5. Phân loại quy trình • Việc phân loại độ chín của các quy trình như trên thường áp dụng cho các DA lớn • Phân loại: – Quy trình không hình thức : các quá trình mà mô hình không định nghĩa 1 cách chặt chẽ – Quy trình được quản lý: mô hình quá trình được định nghĩa (định hướng) – Quy trình có phương pháp: một số phương pháp phát triển đã được định nghĩa – Quy trình cải tiến: SE-VI.27 MỘT SỐ CHỦ ĐỀ KHÁC • Ước lượng chi phí phần mềm (SE Cost Estimation) • Quản lý chất lượng (Quality Management) • Cải tiến quy trình (Process Improvement) • Khác 1. Phương pháp hình thức (Formal methods) 2. Công nghệ học phần mềm phòng sạch (Cleanroom SE) 3. CNHPM hướng thành phần (CBSE) 4. CNHPM khách/chủ (Client/Server SE) 5. Kỹ nghệ Web (Web Engineering) 6. Tái kỹ nghệ (Re-engineering) 7. CNHPM dựa trên máy tính (CASE) 8. (Chi tiết xem trong các tài liệu) 28 Tái kỹ nghệ phần mềm (Software Re-engineering) • Dịch chuyển mã nguồn • Cấu trúc lại CT • Tái lập DL • Kỹ nghệ ngược 29 Phát triển và tái kỹ nghệ SE-VI.30 Đặc tả hệ thống Thiết kế và Cài đặt Hệ thống mới Forward Engineering Hệ thống đang tồn tại Hiểu và dịch chuyển Hệ thống Hệ thống được tái tạo Tái kỹ nghệ phần mềm • Tập đề thi tự luận • Tập hợp về bộ câu hỏi trắc nghiệm • Tập hợp các projects. • Tìm hiểu, biên tập lại (thầy TrungTT). 31 Một số chủ đề nâng cao • Ước lượng chi phí phần mềm (SE Cost Estimation) • Quản lý chất lượng (Quality Management) • Cải tiến quy trình (Process Improvement) • Khác 32 Ước lượng chi phí phần mềm (SE Cost Estimation) 1. Năng suất (Productivity) 2. Các kỹ thuật ước lượng (Estimation Techniques) 3. Mô hình chi phí thuật toán (Algorithmic Cost Model) 4. Nhân lực và thời gian dự án (Project duration and staffing) 33 Quản lý chất lượng (Quality Management) 1. Đảm bảo chất lượng quá trình 2. Xem xét lại chất lượng 3. Các chuẩn phần mềm 4. Các chuẩn tài liệu 5. Độ đo phần mềm 6. Độ đo chất lượng sản phẩm 34 Cải tiến quy trình (Process Improvement) 1. Chất lượng quy trình và sản phẩm 2. Mô hình hoá và phân tích quy trình 3. Độ đo 4. Mô hình thuần thục khả năng SEI 5. Phân loại quy trình 35 Các chủ đề khác 1. Phương pháp hình thức (Formal methods) 2. Công nghệ học phần mềm phòng sạch (Cleanroom SE) 3. CNHPM hướng thành phần (CBSE) 4. CNHPM khách/chủ (Client/Server SE) 5. Kỹ nghệ Web (Web Engineering) 6. Tái kỹ nghệ (Re-engineering) 7. CNHPM dựa trên máy tính (CASE) 8. (Chi tiết xem trong các tài liệu) 36 Nhập môn Công nghệ phần mềm Introduction to Software Engineering (IT3180) Tổng kết và ôn tập Nội dung chính của môn học • Mô hình vòng đời phần mềm • Quy trình phát triển phần mềm • Giới thiệu tổng quan về các phương pháp luận và các kĩ thuật trong xây dựng phần mềm • Giới thiệu chung quá trình quản lý dự án phần mềm, đảm bảo chất lượng phần mềm • Các xu hướng trong nghiên cứu về công nghệ phần mềm Các chủ đề kiến thức môn học STT Nội dung 1 Giới thiệu môn học Chương 1: Tổng quan về Công nghệ phần mềm 1.1 Phần mềm là gì? 1.2 Phân loại phần mềm 1.3 Công nghệ phần mềm là gì? 1.4 Các vấn đề trong Công nghệ phần mềm 2 Chương 2: Vòng đời phần mềm 2.1 Hệ thống vs Phần mềm 2.2 Vòng đời hệ thống/phần mềm 2.3 Quy trình phát triển phần mềm 2.4 Các mô hình quy trình phần mềm: Thác nước, mẫu thử, tăng dần, nhanh, xoắn ốc Ví dụ và bài tập 3 2.5. So sánh các mô hình quy trình phần mềm 2.6. Thảo luận nhóm và lựa chọn mô hình quy trình phù hợp Các chủ đề kiến thức môn học 4 Chương 3: Phương pháp Agile 3.1 Khái niệm 3.2 Các nguyên lý cơ bản 3.2 Ưu, nhược điểm của phương pháp Agile 3.3 Extreme Programming 3.4 Scrum 3.5 Các phương pháp Agile khác 5 Chương 4: Quản lý cấu hình phần mềm 4.1 Khái niệm quản lý cấu hình phần mềm 4.2 Quy trình cấu hình phần mềm 4.3 Quản lý phiên bản 4.4 Quản lý thay đổi 6 Chương 5: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) 5.1 Khái niệm 5.2 Tầm quan trọng của yêu cầu phần mềm 5.3 Yêu cầu chức năng và yêu cầu phi chức năng 5.4 Các hoạt động chính trong kỹ nghệ yêu cầu phần mềm: Thu thập, Phát hiện, Phân tích, Đặc tả, Thẩm định, Quản lý 7 5.5. Quy trình kỹ nghệ yêu cầu phần mềm Các chủ đề kiến thức môn học 8 Chương 6: Thiết kế phần mềm 6.1 Tổng quan về thiết kế phần mềm 6.2 Các khái niệm trong thiết kế phần mềm 6.3 Tính móc nối (Coupling) và tính kết dính (Cohesion) 6.4 Thiết kế kiến trúc 6.5 Thiết kế chi tiết 9 6.6 Thiết kế giao diện người dùng −Các vấn đề thiết kế −Quy trình thiết kế UI −Phân tích người dùng −Tạo mẫu thử giao diện, mẫu thử tương tác −Đánh giá UI −Các công cụ thiết kế UI 10 Chương 7: Xây dựng phần mềm 7.1 Khái niệm 7.2 Quy trình xây dựng phần mềm 7.3 Quy ước viết mã nguồn 7.4 Tái cấu trúc mã nguồn 7.5 Rà soát mã nguồn Các chủ đề kiến thức môn học 11 Chương 8: Quản lý chất lượng phần mềm 8.1 Mô hình V&V 8.2 Các thuật ngữ về kiểm thử 8.3 Phương pháp kiểm thử hộp trắng - Khái niệm, Vai trò - Kỹ thuật bao phủ luồng điều khiển 8.4 Phương pháp kiểm thử hộp đen - Khái niệm, Vai trò - Kỹ thuật phân vùng tương đương 8.5 Quản lý chất lượng phần mềm 12 Chương 9: Quản lý dự án phần mềm 9.1 Khái niệm về dự án phần mềm. −Yếu tố con người: Stokeholder/ TeamLeader/ Software Team/ Communication issue −Yếu tố Sản phẩm: Software scope/ Processs/ Project 9.2 Quy trình quản lý dự án phần mềm. −Ước lượng dự án −Lập kế hoạch dự án −Quản lý rủi ro dự án Đánh giá môn học • Hình thức: thi trên giấy (tự luận và trắc nghiệm) – Không sử dụng tài liệu, thời gian khoảng ~90’ • Trắc nghiệm về các chủ đề: – Chu trình phần mềm và các mô hình phát triển phần mềm – Phương pháp Agile – Phân tích yêu cầu phần mềm và các kĩ thuật lấy yêu cầu phần mềm – Thiết kế phần mềm và các kĩ thuật thiết kế – Quản lý cấu hình phần mềm – Quản lý dự án phần mềm – Kiểm thử phần mềm, Bảo trì phần mềm, • Tự luận (bài tập hoặc câu hỏi viết): – Bài tập xác định yêu cầu phần mềm (xác định tác nhân, usecase, xây dựng biểu đồ usecase, đặc tả usecase, ràng buộc đầu vào,) – Bài tập về phân tích và thiết kế phần mềm (các sơ đồ phân tích (UML: biểu đồ trình tự, giao tiếp, hoạt động), xây dựng và đặc tả sơ đồ lớp thiết kế, thiết kế dữ liệu, thiết kế giao diện màn hình) – Bài tập về kiểm thử (hộp đen và hộp trắng) – Câu hỏi về Quản lý dự án phần mềm, Tài liệu học tập • Tài liệu chính: slides và bài tập hàng tuần / bài tập lớn môn học mà nhóm đã thực hiện • Tài liệu tham khảo: ▪ [1] I. Sommerville, Software Engineering 10th Edition, Addison Wesley 2017 ▪ [2] R. Pressman, Software Engineering: A practitioner’s approach, 8th Edition, McGraw Hill 2016