Bài giảng nhập môn công nghệ phần mềm it40 Đại học mở hà nội

Phần cứng và hạ tầng công nghệ càng phát triển thì các bài toán mà phần mềm phải giải quyết càng phức tạp Phần cứng và hạ tầng công nghệ càng phát triển thì các bài toán mà phần mềm phải giải quyết càng phức tạp 1. linn aung aan (Correctn 2. Tính tin cậy(Reliability) 3. Tính khả dụng(Usability) 4. Tính toàn vẹn(Integrity) 5. Tính hiêu auả(Efficiency''''

3 Hướng dẫn chi tiết

Thảo luận,giải đáp thắc mắc

Khái niệm:

[3] “Computer programs and associated documentation Software products may

be developed for a particular customer or may be developed for a general market”

[IEEE] “Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.”

Phần cứng và hạ

thì các bài toán mà phần mềm phải giải quyết càng phức tạp

McCall’s software quality factors [2.pg509]

• Các đặc trưng của phần mềm

6 Tính liên tác(Interoperability)

7 Tính khả chuyển(Portability)

8 Tính tái dụng(Reusability)

9 Tính bảo trì(Maintainability)

10 Tính linh hoạt(Flexibility)

11 Tính kiểm thử được(Testability)

 1.2.1 Software crisis (khủng hoảng về phần

mềm):

khoa học máy tính để chỉ sự khó khăn khi tạo ra những chương trình máy tính hữu dụng và hiệu quả trong thời gian cần thiết

 Phần mềm không đáp ứng yêu cầu

 Dự án không thể quản lý và code không thể bảo trì

 Phần mềm không thể bàn giao

1.2.2 Định nghĩa:

“The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software” (IEEE)

CNPM là giải pháp cho Software Crisis

mềm

cho phát triển phần mềm

Project Management

Quality Assurance

3 Hướng dẫn chi tiết

Thảo luận,giải đáp thắc mắc

2.1.2 Prototyping

2.1.3 Incremental

2.1.4 Spiral

2.1.5 Mô hình chữ V (V-Model)

2.2 Rational Unified Process (RUP)

◼ Là 1 qui trình công nghệ cho phát triển phần mềm (Software Engineering Process)

◼ Cung cấp cách tiếp cận có kỷ luật để phân công nhiệm vụ và trách nhiệm trong một tổ chức.

◼ Mục tiêu: đảm bảo sản xuất phần mềm chất lượng cao đáp ứng nhu cầu của người dùng cuối, trong thời gian và ngân sách dự đoán được.

◼ Là hướng dẫn để sử dụng UML một cách hiệu quả

Qui trình RUP được tổ chức theo 2 chiều:

Công việc (Workflows)

và thời gian (Phases)

Transition: Chuyển giao

◼Mỗi pha trong RUP có thể được chia nhỏ thành các lần lặp mà

mỗi lần đó sẽ tạo ra 1 sản phẩm (bản nội bộ hoặc phát hành) theo cơ chế tăng tiến

[*]Rational Unified Process Best Practices for Software Development Team Rational Software White Paper, 2005.

RUP: Các công việc [*: p10-14]

1 Mô hình hóa nghiệp vụ (Business Modeling)

2 Xác định yêu cầu (Requiments)

3 Phân tích & Thiết kế (Analysis & Design)

4 Thi hành (Implementation)

5 Kiểm thử (Test)

6 Phân phối (Deployment)

7 Quản lý dự án (Project Management)

8 Quản lý cấu hình và

sự thay đổi (Configuration &

Change Management)

9 (Thiết lập) Môi trường

RUP: Sản phẩm RUP

◼Được cung cấp gồm:

Tài nguyên trên Web (hướng dẫn, mẫu biểu, …)

Microsoft Project Plan

Công cụ phát triển (để tùy biến RUP)

Sách viết về RUP ("Rational Unified Process — An Introduction", by Philippe Kruchten, published by AddisonWesley)

◼http://sce.uhcl.edu/helm/rationalunifiedprocess/process/templates.htm

Thảo luận chung

anhtt@ehou.edu.vn

Chúc Anh/chị học tập tốt

Yêu cầu (Requirement) là gì:

Một yêu cầu là một tuyên bố về những gì hệ thống phải làm hoặc những đặc tính cần thiết mà nó phải có

◼ Sản phẩm của pha Xác định yêu cầu: Văn bản đặc tả yêu cầu phần mềm (SRS,

Software Requirement Specification)

◼ SRS: một bản đặc tả đầy đủ về những gì mà hệ thống dự kiến cần làm (WHAT, not HOW)

◼ Thực hiện trước khi phân tích, xác định yêu cầu.

◼ Nhằm trả lời:

 Có nên phát triển hệ thống này không?

 Cần nguồn lực như thế nào?

 Phải liên tác với những hệ thống nào?

◼ SRS thể hiện sự thống nhất cơ bản giữa người dùng và người cung cấp (phần mềm)

◼ SRS là

 Trung gian kết nối hiểu biết, đặc tả nhu cầu của người dùng mà các bên liênquan đều có thể hiểu được (một cách thống nhất)

◼ Giúp người dùng hiểu được những gì họ cần

◼ SRS cung cấp căn cứ cho việc xác nhận sản phẩm cuối cùng:

 Hiểu rõ về những gì được trông đợi

 Xác nhận “phần mềm đáp ứng đúng SRS”

◼ Chất lượng SRS ảnh hưởng tới chất lượng phần mềm

◼ SRS tốt giúp giảm chi phí phát triển phần mềm

 Yêu cầu chức năng

 Hệ thống/từng thành phần,

cá nhân thuộc hệ thống phải/cần làm gì?

là những đặc điểm mà hệ thống nên có

 Tin cậy (Reliability)

 Hiệu năng (Performance)

 Hữu dụng (Usability)

 Bảo mật (Security)

 Tương thích (Compatibility/ inter- operability)

 Khả năng bảo trì (Maintainability)

 Khả chuyển (Portability)

 Văn hóa

 Đáp ứng Pháp luật/Qui định

◼ Cấu trúc SRS được chia làm 3 phần:

 Introduction (Giới thiệu)

 Overall description (mô tả tổng thể)

 Specific requirement (đặc tả yêu cầu)

Mục đích Phạm vi ĐỊnh nghĩa, từ & chữ viết tắt

Tài liệu tham khảo Tổng quan

Giới thiệu

Quan điểm về sảnphẩm

Các chức năngĐặc điểm người dùngRàng buộc

Các giả định và phụthuộc

Mô tả tổng thể

ảnh: IEEE Recommended Practice for Software Requirements Specifications

3.7 Thành phần của SRS (tiếp)

 Giao diện bên ngoài

 Yêu cầu chức năng

 Yêu cầu hiệu năng

 Ràng buộc thiết kế

 Thuộc tính hệ thống phần mềm

 Yêu cầu khác

anhtt@hou.edu.vn

Chúc Anh/chị học tập tốt

◼ Thiết kế phần mềm là 1 tiến trình nhằm chuyển đổi yêu cầu của người dùng sang một số dạng phù hợp giúp người lập trình thực hiện được công việc (lập trình) củamình để tạo ra phần mềm.

◼ Các mức độ thiết kế phần mềm:

 Thiết kế kiến trúc (Architechtural Design)

 Thiết kế mức cao (High-level Design)

 Thiết kế chi tiết (Detailed Design)

◼ Đầu ra của thiết kế phần mềm sẽ được sử dụng cho quá trình xây dựng và kiểm thử nên việc đánh giá một thiết kế có phù hợp hay không rất quan trọng, nếu một thiết kế sai sẽ dẫn đến tất cả các quá trình sau đó cũng sai và cần phải chỉnh sửa nếu thiết

kế được chỉnh sửa

◼ Thiết kế hướng chức năng

◼ Thiết kế hướng dữ liệu

◼ Thiết kế hướng đối tượng

◼ Thiết kế hướng chức năng là một cách tiếp cận thiết kế phần mềm trong đó bản thiết

kế được phân rã thành một bộ các mô-đun được tác động lẫn nhau, mà mỗi mô-đun đáp ứng một chức năng xác định

◼ Thiết kế hướng chức năng: thông tin trạng thái của hệ thống không được che dấu →

dễ xảy ra xung đột khi dữ liệu bị thay đổi ngoài ý muốn

◼ Thiết kế hướng chức năng thích hợp cho những hệ thống cỡ nhỏ và đơn giản

◼ Là phương pháp thiết kế tập trung trên dữ liệu của hệ thống

◼ Các xử lý cần thiết được xác định theo các đối tượng dữ liệu đã được định danh

◼ Khi cấu trúc dữ liệu thay đổi, các xử lý và thuật toán liên quan cũng phải thay đổi

theo

◼ Hệ thống được tiếp cận như một bộ các đối tượng, phân tán, mỗi đối tượng cónhững thông tin trạng thái riêng của nó Các đối tượng là độc lập, sẵn sàng thay đổi

mà không ảnh hưởng tới các đối tượng khác Các đối tượng tương tác với nhaubằng cách truyền các thông điệp

◼ Bản thiết kế kiến trúc là phiên bản trừu tượng nhất về hệ thống Nó xác định phầnmềm như là một hệ thống với nhiều thành phần (components) tương tác với nhau.

◼ Một kiến trúc phần mềm là tập hợp các cấu trúc cần thiết để suy luận về hệ thống, trong đó bao gồm các yếu tố phần mềm, mối quan hệ giữa chúng và đặc tính của cả hai

◼ Một số Kiểu kiến trúc

 Kiến trúc thường (VD: phân tầng, pipes and filter, blackboard)

 Các hệ thống phân tán (VD: client- server, three- tiers, broker)

 Các hệ thống tương tác (VD: MVC, Presentation- Abstraction- Control, WPF)

 Các hệ thống mô phỏng (VD: microkernel, reflection)

 Các kiểu khác (VD: batch, interperters, process control, rule- based)

◼ Lựa chọn kiến trúc:

 Thiết kế kiến trúc là một quá trình sáng tạo nhằm đáp ứng các yêu cầu trên cơ

sở kết hợp các hiểu biết về các kiểu kiến trúc đã biết

 Các yêu cầu phi chức năng có thể là cơ sở cho sự lựa chọn kiến trúc:

◼ Tính Hiêu năng

◼ Tính Bảo mật

◼ Tính khả dụng

◼ Tính bảo trì

◼ Mẫu phân lớp xác định các lớp (nhóm các mô-đun cung cấp một tập hợp dịch vụ gắn kết) và mối quan hệ được phép sử dụng một chiều giữa các lớp.

 Ưu điểm: tận dụng được các đặc điểm của phương pháp hướng đối tượng, cókhả năng mở rộng

 Nhược điểm: tăng kích cỡ của phần mềm

◼ Dữ liệu được chuyển đổi từ đầu vào bên ngoài của hệ thống thành đầu ra thông qua một loạt các phép biến đổi được thực hiện bởi các bộ lọc (Filter) của hệ thống được kết nối bằng đường ống (Pipe).

◼ Đường ống nối các cổng đầu ra của bộ lọc với các cổng đầu vào của bộ lọc Các bộ lọc được kết nối phải thống nhất về loại dữ liệu được truyền dọc theo đường ống kết nối

◼ Các yêu cầu dịch vụ do khách hàng tạo sẽ đến dưới dạng các sự kiện Chúng được xếp hàng đợi, và sau đó được chuyển hướng đến một trình xử lý sự kiện thích hợp theo một số chính sách ứng dụng

◼ Ưu điểm: khả năng mở rộng cao

◼ Nhược điểm: hiệu suất và khả năng phục hồi thấp

◼ Mẫu MVC chia chức năng hệ thống thành ba thành phần: mô hình, chế độ xem và bộ điều khiển làm trung gian giữa mô hình và chế độ xem.

◼ Ưu điểm: tách biệt nhiệm vụ giữa các thành phần

◼ Nhược điểm: sự phức tạp không đáng có với phần mềm đơn giản

◼ Thiết kế giao diện người dùng là một phần quan trọng quá trình thiết kế phần mềm Thiết kế giao diện và xử lý tương tác với người sử dụng là một yếu tố quan trọng ảnhhưởng đến việc sử dụng phần mềm.

◼ Sản phẩm thiết kế giao diện phải làm sao để phù hợp với kĩ năng, kinh nghiệm và mong đợi từ phía người sử dụng phần mềm

trong thiết kế giao diện

1 Đặc tả yêu cầu giao

1 LẬP TRÌNH

◼ Lập trình là việc lập trình viên sử dụng các ngôn ngữ lập trình và phần mềm hỗ trợ

để viết ra những đoạn code theo thuật toán để tạo ra những phần mềm/ứng dụng chạy trên các thiết bị (máy tính, điện thoại, ) nhằm đáp ứng một nhu cầu nào đó của con người

◼ Lập trình tuần tự

◼ Lập trình hướng cấu trúc

◼ Lập trình hướng đối tượng

◼ Lập trình hướng dịch vụ

◼ Giải quyết các bài toán đơn giản với số ít dòng lệnh thực hiện tuần tự.

◼ Nhược điểm:

 Gặp khó khăn với bài toán phức tạp

 Không tái sử dụng được

◼ Bài toán phức tạp được phân rã thành các bài toán đơn giản hơn Việc phân rã đượclặp lại cho đến khi thu được bài toán đủ nhỏ để lập trình.

◼ Mỗi bài toán nhỏ được giải quyết bởi 1 đơn vị chương trình (chương trình con) dạng

hàm hay thủ tục Các chương trình con được kết hợp lại để giải quyết bài toán ban

đầu

◼ Chương trình con có thể nhận vào các tham số (tham biến, tham trị), có thể trả lạicác giá trị

◼ Ưu điểm:

 Tiếp cận đơn giản hóa

 Có thể tái sử dụng các chương trình con

◼ Bài toán được tiếp cận như là mối quan hệ của các đối tượng

◼ Các đối tượng có thông tin (thuộc tính) và hành động (phương thức), có cơ chế baogói, che giấu dữ liệu

◼ Các đối tượng tương tác với nhau thông qua cơ chế truyền thông điệp

 Số lượng mã tăng ở những bài toán đơn giản

 Có sự trùng lặp, nhập nhằng (nếu thiết kế không tốt)

◼ Các nghiệp vụ đã được giải quyết được các hệ thống cung cấp dưới dạng các dịch

vụ (service/API) để hệ thống khác sử dụng (mà không phải làm lại)

◼ Phục vụ giải quyết bài toán lớn, phát triển hệ sinh thái phần mềm

 Độ phụ thuộc cao (về mạng, giữa các hệ thống)

 Gia tăng rủi ro

2 KIỂM THỬ PHẦN MỀM

◼ Kiểm thử là tiến trình vận hành hệ thống hoặc thành phần dưới những điều kiện xác định, quan sát, ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành phần đó

(IEEE Standard Glossary of Software Engineering Terminology)

◼ Nhằm giúp sản phẩm phần mềm đạt chất lượng mong muốn.

◼ Có xác xuất phát hiện lỗi cao

◼ Không trùng lặp

◼ Phải là lựa chọn kiểm thử tốt nhất

◼ Không quá đơn giản hay quá phức tạp

◼ Kiểm thử đơn vị (Unit testing)

◼ Kiểm thử tích hợp (Integration Testing)

◼ Kiểm thử hệ thống (System Testing)

◼ Kiểm thử chấp nhận (Acceptance Testing)

◼ Kiểm thử hộp đen (Black Box Testing)

◼ Kiểm thử hộp trắng (White Box Testing)

◼ Kiểm thử hộp xám (Gray Box Testing)

◼ Với Blackbox Testing

 Equivalence partitioning (phân vùng tương đương)

 Boundary value analysis (phân tích giá trị biên)

 Decision table testing (kiểm thử bảng quyết định)

 State transition testing (kiểm thử chuyển đổi trạng thái)

 Use case testing (kiểm thử trường hợp sử dụng)

◼ Với Whitebox Testing

 Statement testing (kiểm thử câu lệnh)

 Decision testing (kiểm thử quyết định)

 Condition testing (kiểm thử điều kiện)

 Multiple condition testing (kiểm thử đa điều kiện)

 Path testing (kiểm thử đường hoạt động của chương trình)

◼ Manual Testing (thủ công)

◼ Automation Testing (tự động hóa)