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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (3.06 MB, 90 trang )

<span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">



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



[IEEE] “Computer programs, procedures, and possibly associated

documentation and data pertaining to the operation of a computer system.”

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

Phần cứng và hạ

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

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

McCall’s software quality factors [2.pg509]

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

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

6. Tính liên tác(Interoperability)7. Tính khả chuyển(Portability)8. Tính tái dụng(Reusability)

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

9. Tính bảo trì(Maintainability)10. Tính linh hoạt(Flexibility)

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

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

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

</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">



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

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

<b>mềm</b>

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

<b>cho phát triển phần mềm</b>

<b>Project Management</b>

<b>Quality Assurance</b>

</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">

<b>2.1.2. Prototyping</b>

</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">

<b>2.1.3. Incremental</b>

</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">

<b>2.1.4. Spiral</b>

</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">

<b>2.1.5 Mơ hình chữ V (V-Model)</b>

</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">

<b>2.2 Rational Unified Process (RUP)</b>

◼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ả

</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">

RUP hỗ trợ đáp ứng 6 vấn đề thực tiễn

➢

Phát triển lặp

➢

Quản lý yêu cầu

</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">

<small>Qui trình RUP được tổ chức theo 2 chiều:Công việc (Workflows)</small>

<small>và thời gian (Phases)</small>

</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">



Transition: Chuyển giao

◼

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

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

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

</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">

<b>RUP: Các công việc [*: p10-14]</b>

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

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

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

4.Thi hành

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

</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">

<b>RUP: Sản phẩm RUP</b>

◼

Đượ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)

◼

class="text_page_counter">Trang 30</span><div class="page_container" data-page="30">

<b>Thảo luận chung</b>

</div><span class="text_page_counter">Trang 31</span><div class="page_container" data-page="31">

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

</div><span class="text_page_counter">Trang 33</span><div class="page_container" data-page="33">

<small>1.</small> Khái niệm

<small>2.</small> Nghiên cứu khả thi<small>3.</small> Mục đích sử dụng SRS<small>4.</small> Sự cần thiết của SRS<small>5.</small> Phân loại yêu cầu<small>6.</small> Thế nào là 1 SRS tốt<small>7.</small> Thành phần của 1 SRS

</div><span class="text_page_counter">Trang 34</span><div class="page_container" data-page="34">



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ó.

</div><span class="text_page_counter">Trang 35</span><div class="page_container" data-page="35">



[5], [IEEE]:A requirement is:



A condition or capability needed by a stakeholder to solve a problem or achieve an 1 objective.



A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specifcation, or other formally

imposed documents.



A documented representation of a condition or capability as in (1) or (2).

</div><span class="text_page_counter">Trang 36</span><div class="page_container" data-page="36">

<small>◼</small> 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)

<small>◼</small> 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)

</div><span class="text_page_counter">Trang 37</span><div class="page_container" data-page="37">

<small>◼</small> Thực hiện trước khi phân tích, xác định yêu cầu.<small>◼</small> Nhằm trả lời:

<small></small> Có nên phát triển hệ thống này khơng?

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

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

</div><span class="text_page_counter">Trang 38</span><div class="page_container" data-page="38">

<small>◼</small> 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)<small>◼</small> SRS là

<small></small> 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)

</div><span class="text_page_counter">Trang 39</span><div class="page_container" data-page="39">

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

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

<small></small> Hiểu rõ về những gì được trơng đợi

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

<small>◼</small> Chất lượng SRS ảnh hưởng tới chất lượng phần mềm<small>◼</small> SRS tốt giúp giảm chi phí phát triển phần mềm

</div><span class="text_page_counter">Trang 41</span><div class="page_container" data-page="41">

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/ operability)

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

Khả chuyển (Portability)

Văn hóa

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

</div><span class="text_page_counter">Trang 43</span><div class="page_container" data-page="43">

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

<small></small> Introduction (Giới thiệu)

<small></small> Overall description (mô tả tổng thể)

<small></small> Specific requirement (đặc tả yêu cầu)

</div><span class="text_page_counter">Trang 44</span><div class="page_container" data-page="44">

Mục đíchPhạm vi

ĐỊnh nghĩa, từ & chữviết tắt

Tài liệu tham khảoTổ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ể

<small>ảnh: IEEE Recommended Practice for Software Requirements Specifications</small>

</div><span class="text_page_counter">Trang 45</span><div class="page_container" data-page="45">

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

</div><span class="text_page_counter">Trang 46</span><div class="page_container" data-page="46">

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

</div><span class="text_page_counter">Trang 48</span><div class="page_container" data-page="48">

<small>1.</small> Thiết kế phần mềm là gì?<small>2.</small> Các phương pháp thiết kế<small>3.</small> Thiết kế kiến trúc phần mềm<small>4.</small> Thiết kế giao diện người dùng

</div><span class="text_page_counter">Trang 49</span><div class="page_container" data-page="49">

<small>◼</small> 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.

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

<small></small> Thiết kế kiến trúc (Architechtural Design)

<small></small> Thiết kế mức cao (High-level Design)

<small></small> Thiết kế chi tiết (Detailed Design)

</div><span class="text_page_counter">Trang 50</span><div class="page_container" data-page="50">

<small>◼</small> Đầ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 q 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

</div><span class="text_page_counter">Trang 51</span><div class="page_container" data-page="51">

<small>◼</small> Thiết kế hướng chức năng<small>◼</small> Thiết kế hướng dữ liệu<small>◼</small> Thiết kế hướng đối tượng

</div><span class="text_page_counter">Trang 52</span><div class="page_container" data-page="52">

<small>◼</small> 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.

<small>◼</small> 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.

<small>◼</small> 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.

</div><span class="text_page_counter">Trang 53</span><div class="page_container" data-page="53">

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

<small>◼</small> Các xử lý cần thiết được xác định theo các đối tượng dữ liệu đã được định danh.<small>◼</small> 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

</div><span class="text_page_counter">Trang 54</span><div class="page_container" data-page="54">

<small>◼</small> 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 đổimà 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

</div><span class="text_page_counter">Trang 56</span><div class="page_container" data-page="56">

<small>◼</small> 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.<small>◼</small> 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

</div><span class="text_page_counter">Trang 57</span><div class="page_container" data-page="57">

<small>◼</small> Một số Kiểu kiến trúc

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

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

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

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

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

</div><span class="text_page_counter">Trang 60</span><div class="page_container" data-page="60">

<small>◼</small> 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.

<small></small> Ư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

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

</div><span class="text_page_counter">Trang 62</span><div class="page_container" data-page="62">

<small>◼</small> 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).

<small>◼</small> Đườ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.

</div><span class="text_page_counter">Trang 64</span><div class="page_container" data-page="64">

<small>◼</small> 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.

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

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

</div><span class="text_page_counter">Trang 66</span><div class="page_container" data-page="66">

<small>◼</small> 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.

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

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

</div><span class="text_page_counter">Trang 67</span><div class="page_container" data-page="67">

<small>◼</small> 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.

<small>◼</small> 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.

</div><span class="text_page_counter">Trang 68</span><div class="page_container" data-page="68">

<b>trong thiết kế giao diện</b>

</div><span class="text_page_counter">Trang 69</span><div class="page_container" data-page="69">

1.Đặc tả yêu cầu giaodiện

</div><span class="text_page_counter">Trang 72</span><div class="page_container" data-page="72">

<b>1. LẬP TRÌNH</b>

</div><span class="text_page_counter">Trang 73</span><div class="page_container" data-page="73">

<small>◼</small> 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

</div><span class="text_page_counter">Trang 74</span><div class="page_container" data-page="74">

<small>◼</small> Lập trình tuần tự

<small>◼</small> Lập trình hướng cấu trúc<small>◼</small> Lập trình hướng đối tượng<small>◼</small> Lập trình hướng dịch vụ

</div><span class="text_page_counter">Trang 75</span><div class="page_container" data-page="75">

<small>◼</small> 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ự.<small>◼</small> Nhược điểm:

<small></small> Gặp khó khăn với bài tốn phức tạp

<small></small> Không tái sử dụng được

</div><span class="text_page_counter">Trang 76</span><div class="page_container" data-page="76">

<small>◼</small> 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 tốn đủ nhỏ để lập trình.

<small>◼</small> 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

<b>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 tốn ban </b>

<small>◼</small> 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ị.

</div><span class="text_page_counter">Trang 77</span><div class="page_container" data-page="77">

<small>◼</small> Ưu điểm:

<small></small> Tiếp cận đơn giản hóa

<small></small> Có thể tái sử dụng các chương trình con<small>◼</small> Nhược điểm:

<small></small> Khơng bảo vệ được dữ liệu khỏi các thay đổi ngoài ý muốn trong các chươngtrình con.

<small></small> Thay đổi các chương trình con có thể làm ảnh hưởng đến tồn bộ chương trình

</div><span class="text_page_counter">Trang 78</span><div class="page_container" data-page="78">

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

<small>◼</small> 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.

<small>◼</small> Các đối tượng tương tác với nhau thông qua cơ chế truyền thơng điệp.<small>◼</small> Có khả năng:

<small></small> Bao gói, che giấu dữ liệu

<small></small> Kế thừa

<small></small> Trừu tượng hóa

<small></small> Đa hình

</div><span class="text_page_counter">Trang 79</span><div class="page_container" data-page="79">

<small></small> Số lượng mã tăng ở những bài tốn đơn giản

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

</div><span class="text_page_counter">Trang 80</span><div class="page_container" data-page="80">

<small>◼</small> 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ịchvụ (service/API) để hệ thống khác sử dụng (mà không phải làm lại)

<small>◼</small> 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

</div><span class="text_page_counter">Trang 81</span><div class="page_container" data-page="81">

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

<small></small> Gia tăng rủi ro

</div><span class="text_page_counter">Trang 82</span><div class="page_container" data-page="82">

<b>2. KIỂM THỬ PHẦN MỀM</b>

</div><span class="text_page_counter">Trang 83</span><div class="page_container" data-page="83">

<small>◼</small> 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 đó.

<i>(IEEE Standard Glossary of Software Engineering Terminology)</i>

</div><span class="text_page_counter">Trang 84</span><div class="page_container" data-page="84">

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

</div><span class="text_page_counter">Trang 85</span><div class="page_container" data-page="85">

<small>◼</small> Có xác xuất phát hiện lỗi cao<small>◼</small> Khơng trùng lặp

<small>◼</small> Phải là lựa chọn kiểm thử tốt nhất<small>◼</small> Không quá đơn giản hay quá phức tạp

</div><span class="text_page_counter">Trang 86</span><div class="page_container" data-page="86">

<small>◼</small> Kiểm thử đơn vị (Unit testing)

<small>◼</small> Kiểm thử tích hợp (Integration Testing)<small>◼</small> Kiểm thử hệ thống (System Testing)

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

</div><span class="text_page_counter">Trang 88</span><div class="page_container" data-page="88">

<small>◼</small> Kiểm thử hộp đen (Black Box Testing)<small>◼</small> Kiểm thử hộp trắng (White Box Testing)<small>◼</small> Kiểm thử hộp xám (Gray Box Testing)

</div><span class="text_page_counter">Trang 89</span><div class="page_container" data-page="89">

<small>◼</small> Với Blackbox Testing

<small></small> Equivalence partitioning (phân vùng tương đương)

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

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

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

<small></small> Use case testing (kiểm thử trường hợp sử dụng)<small>◼</small> Với Whitebox Testing

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

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

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

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

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