Chuong 3. cnpm
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Chuong 3. cnpm

on

  • 1,347 views

fgdsgdsg

fgdsgdsg

Statistics

Views

Total Views
1,347
Views on SlideShare
1,347
Embed Views
0

Actions

Likes
1
Downloads
63
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Chuong 3. cnpm Presentation Transcript

  • 1. CHƯƠNG 3. QUY TRÌNH XÂY DỰNG PHẦN MỀM Bộ môn Công nghệ thông tin Trường Đại học Thương mại 1
  • 2. Nội dung3.1. Phân tích và đặc tả yêu cầu phần 3.4. Kiểm thửmềm 3.4.1. Khái niệm 3.1.1. Đặc tả yêu cầu phần mềm 3.4.2. Các phương pháp kiểm thử 3.1.2. Phân tích yêu cầu hệ thống 3.4.3. Các kỹ thuật kiểm thử3.2. Thiết kế phần mềm 3.4.4. Các loại kiểm thử 3.2.1. Thiết kế giao diện 3.4.5. Các hoạt động kiểm thử 3.2.2. Thiết kế chương trình 3.5. Cài đặt phần mềm 3.2.3. Thiết kế các tập tin dữ liệu 3.5.1. Lập kế hoạch cài đặt3.3. Lập trình 3.5.2. Biến đổi dữ liệu 3.3.1. Khái niệm 3.5.3. Biên soạn tài liệu hệ thống 3.3.2. Phương pháp lập trình 3.6. Bảo trì phần mềm 3.3.3. Ngôn ngữ lập trình 3.3.4. Phong cách lập trình 2
  • 3. 3.1. Phân tích và đặc tả yêu cầu phần mềm Phân tích và đặc tả yêu cầu là bản đặc tả các dịch vụ mà hệ thống cung cấp và các ràng buộc để xây dựng và vận hành hệ thống. Quá trình tìm kiếm, phân tích, tư liệu hoá, và kiểm tra các dịch vụ và các ràng buộc của hệ thống được gọi là kỹ thuật xác định yêu cầu (Requirements Engineering - RE). 3
  • 4. 3.1. Phân tích và đặc tả yêu cầu phần mềm Chúng ta cần phải viết các yêu cầu ở các mức chi tiết khác nhau vì có nhiều người sử dụng khác nhau sử dụng chúng theo những cách khác nhau. Phân tích yêu cầu là khâu kỹ thuật đầu tiên trong quá trình xây dựng phần mềm. Bên phát triển và khách hàng cần phối hợp thực hiện, tìm hiểu xem hệ thống cần làm gì. 4
  • 5. 3.1.1. Đặc tả yêu cầu phần mềm Yêu cầu phần mềm: là tất cả các yêu cầu về phầm mềm do khách hàng - người sử dụng phần mềm - nêu ra, bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác. Thông thường các yêu cầu phần mềm được phân loại 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) 5
  • 6. 3.1.1. Đặc tả yêu cầu phần mềm Mục đích: mục đích của yêu cầu phần mềm là 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. Lý do: 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ọ, người phát triển 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, người phát triển cần nắm bắt được các thay đổi đó và sửa đổi các mô tả một cách hợp lý 6
  • 7. 3.1.1. Đặc tả yêu cầu phần mềm 7
  • 8. 3.1.1. Đặc tả yêu cầu phần mềm Mục tiêu của quy trình xác định yêu cầu là đưa ra các tài liệu yêu cầu của hệ thống. Quy trình xác định yêu cầu biến đổi phụ thuộc vào miền ứng dụng, con người và tổ chức xây dựng yêu cầu. Tuy nhiên, những quy trình này vẫn có chung một số hoạt động sau: phát hiện yêu cầu, phân tích yêu cầu, đánh giá yêu cầu và quản lý yêu cầu. 8
  • 9. 3.1.1. Đặc tả yêu cầu phần mềm Nội dung – 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) – Mô 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á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) 9
  • 10. 3.1.1. Đặc tả yêu cầu phần mềm Tuy nhiên, trong thực tế, các yêu cầu luôn luôn thay đổi, thậm chí ngay cả khi đang xây dựng hệ thống. Vì vậy, người ta thường sử dụng mô hình xoắn ốc để xác định các yêu cầu. Mô hình này cho phép việc xác định yêu cầu và cài đặt hệ thống được thực hiện cùng lúc. 10
  • 11. Mô hình xắn ốc trong quy trình xác địnhyêu cầu Mô hình xắn ốc trong quy trình xác định yêu cầu 11
  • 12. Phân tích và phát hiện yêu cầu PM 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. 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 người phát triển xác định yêu cầu phần mềm. Xác định “môi trường kỹ thuật” (technical environment) 12
  • 13. Phân tích và phát hiện yêu cầu PM Xác định các “ràng buộc lĩnh vực” (domain constraints) Thu hút sự tham gia của nhiều chuyên gia, khách hàng để người phát triển có được các quan điểm xem xét phần mềm khác nhau từ phía khách hàng Thiết kế các kịch bản sử dụng của phần mềm Phân tích dựa trên khung nhìn cho phép phát hiện nhiều khía cạnh khác nhau của một vấn đề và giúp phát hiện ra sự xung đột giữa các yêu cầu. 13
  • 14. Phân tích và phát hiện yêu cầu PM Khung nhìn được chia thành 3 loại chính và mỗi loại sẽ cung cấp các yêu cầu khác nhau. – Khung nhìn tương tác: là những người hoặc hệ thống khác tương tác với hệ thống. Trong hệ thống ATM, khách hàng và CSDL tài khoản là những khung nhìn tương tác – Khung nhìn gián tiếp: là những stakeholder không sử dụng hệ thống trực tiếp nhưng có ảnh hưởng tới hệ thống. Trong hệ thống ATM, nhân viên quản lý và bảo mật là những khung nhìn gián tiếp. – Khung nhìn miền ứng dụng: là những đặc điểm và ràng buộc của miền ứng dụng, có ảnh hưởng tới các yêu cầu. Trong hệ thống ATM, các chuẩn để giao tiếp giữa nhiều ngân hàng là một ví dụ. 14
  • 15. Phân tích và phát hiện yêu cầu PM Ta có thể phát hiện khung nhìn dựa trên: – Người cung cấp và người nhận các dịch vụ của hệ thống – Các hệ thống tương tác trực tiếp với hệ thống cần xây dựng. – Các chuẩn và các quy tắc – Tài nguyên và các yêu cầu phi chức năng – Marketing và các khung nhìn nghiệp vụ khác. 15
  • 16. Ví dụ Ví dụ về hệ thống quản lý thư viện (HTQLTV) có yêu cầu sau: – Trường đại học X cần xây dựng một Hệ thống thư viện có chức năng cung cấp một giao diện đơn giản để lưu cơ sở dữ liệu về các bài báo trên các thư viện khác nhau. Người sử dụng có thể tìm kiếm, download và in những tài liệu này. 16
  • 17. Ví dụ Khung nhìn phân cấp của HTQLTV 17
  • 18. Phân tích và phát hiện yêu cầu PM Phỏng vấn hình thức hoặc phi hình thức là một trong những phần quan trọng nhất của quy trình xác định yêu cầu. Trong quá trình phỏng vấn, những người xác định yêu cầu sẽ đặt ra các câu hỏi cho các bên liên quan về hệ thống hiện tại họ đang sử dụng và hệ thống sẽ được xây dựng. Và các yêu cầu sẽ được lấy ra từ những câu trả lời của người sử dụng. 18
  • 19. Phỏng vấn được chia thành hai loại:– Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa trước và có nhiều đáp án để người sử dụng lựa chọn trả lời.– Phỏng vấn mở: tất cả các vấn đề không được xác định trước và người sử dụng phải tự giải thích và phát biểu theo quan điểm của mình. 19
  • 20. 3.1.1. Đặc tả yêu cầu phần mềm Kết quả của giai đoạn đặc tả yêu cầu phần mềm chúng ta thu được các tài liệu sau: – 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 20
  • 21. 3.1.1. Đặc tả yêu cầu phần mềm Đặc tả các yêu cầu phần mềm là công việc 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 Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức – Tính rõ ràng, chính xác – Tính phù hợp – Tính đầy đủ, hoàn thiện 21
  • 22. 3.1.1. Đặc tả yêu cầu phần mềmCác thành phần của hồ sơ đặc tả – Đặc tả phi hình thức (Informal specifications) được viết bằng ngôn ngữ tự nhiên – Đặc tả hình thức (Formal specifications) được viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽ – Đặc tả vận hành 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 tả mô tả (Descriptive specifications) – đặc tả các đặc tính đặc trưng của phần mềm. 22
  • 23. 3.1.1. Đặc tả yêu cầu phần mềmCác yêu cầu của hệ thống phần mềm thường đượcchia thành ba loại: yêu cầu chức năng, yêu cầu phichức năng và yêu cầu miền ứng dụng. Tuy nhiên,trong thực tế chúng ta rất khó phân biết ba loại yêucầu này một cách rõ ràng.Trong phần này chúng ta tìm hiểu: – a. Các loại đặc tả – b. Phương pháp xác định các yêu cầu hệ thống – c. Đặc tả miềm ứng dụng – d. Một số kỹ thuật đặc tả yêu cầu HT 23
  • 24. a. Đặc tả chức năng Đặc tả chức năng (Operational Specifications): Yêu cầu chức năng mô tả hệ thống sẽ làm gì. Nó mô tả các chức năng hoặc các dịch vụ của hệ thống một cách chi tiết. Đặc điểm của yêu cầu chức năng: – Tính mập mờ, không rõ ràng của các yêu cầu: Vấn đề này xảy ra khi các yêu cầu không được xác định một cách cẩn thận. Các yêu cầu mập mờ có thể được người xây dựng và người sử dụng hiểu theo nhiều cách khác nhau. – Tính hoàn thiện và nhất quán: Về nguyên tắc, yêu cầu phải chứa tất cả các mô tả chi tiết và không có sự xung đột hoặc đối ngược giữa các yêu cầu. Tuy nhiên, trong thực tế rất khó có thể đạt được điều này. 24
  • 25. a. Đặc tả chức năng Thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các công cụ tiêu biểu sau – 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) 25
  • 26. a. Đặc tả chức năng Ví dụ xác định các yêu cầu chức năng của HTQLTV – Người sử dụng có thể tìm kiếm tất cả CSDL hoặc một tập con của CSDL. – Hệ thống sẽ cung cấp những giao diện thích hợp để người sử dụng đọc tài liệu. – Tất cả những hoá đơn mà người sử dụng đăng ký để in sao tài liệu có một mã duy nhất. 26
  • 27. b. Đặc tả phi chức năng Đặc tả phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. Yêu cầu phi chức năng thường định nghĩa các thuộc tính như: độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ …và các ràng buộc của hệ thống như: khả năng của thiết bị vào/ra, giao diện … Một số đặc tả phi chức năng còn có liên quan đến quy trình xây dựng hệ thống. Ví dụ: các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình … Các đặc tả phi chức năng có thể là hạn chế hơn những đặc tả chức năng. Nhưng nếu nó không được thoả mãn thì hệ thống sẽ không sử dụng được. 27
  • 28. b. Đặc tả phi chức năng Các đặc tả phi chức năng xuất hiện là do yêu cầu của người sử dụng, ràng buộc về ngân sách, các chính sách của tổ chức sử dụng hệ thống, yêu cầu tương thích giữa phần cứng và phần mềm và đặc tả phi chức năng như sau: – Các đặc tả về sản phẩm xác định ứng xử của sản phẩm như: hiệu năng, khả năng sử dụng, độ tin cậy … của sản phẩm. – Các đặc tả về tổ chức: các đặc tả này được lấy từ những chính sách và quy tắc của khách hàng hoặc tổ chức sử dụng hệ thống. – Các đặc tả ngoài: được xác định từ các tác nhân ngoài của hệ thống. 28
  • 29. Phân loại các yêu cầu phi chức năng 29
  • 30. b. Đặc tả phi chức năng Khó xác định chính xác và rất khó thẩm tra những yêu cầu phi chức năng mập mờ. Do đó, trong tài liệu đặc tả yêu cầu, người ta thường bổ sung các mục tiêu. Mục tiêu rất hữu ích đối với người phát triển hệ thống khi nó truyền tải được những mong muốn của người sử dụng hệ thống. Còn với những đặc tả phi chức năng có thể thẩm định được là những yêu cầu có thể kiểm thử một cách khách quan. Tuy nhiên, trong nhiều trường hợp thường xảy ra xung đột giữa các đặc tả phi chức năng đối với những hệ thống phức tạp. 30
  • 31. b. Đặc tả phi chức năng Ví dụ xác định các đặc tả phi chức năng của HTQLTV – Đặc tả về sản phẩm: HTQLTV phải được cài đặt bằng HTML mà không có frame hoặc Java applets. – Đặc tả về mặt tổ chức: Quy trình xây dựng hệ thống và các tài liệu chuyển giao phải thoả mãn các quy tắc đã được định nghĩa trong phần phụ lục của tài liệu HTQLTV. – Yêu cầu ngoài: Hệ thống không được để lộ các thông tin cá nhân của khách hàng. 31
  • 32. Các đặc tả phi chức năng có thể thẩm định đượccủa HTQLTV– Mục tiêu của hệ thống là dễ sử dụng đối với những người sử dụng có kinh nghiệm và được tổ chức để sao cho tối thiểu hoá được lỗi.– Các đặc tả phi chức năng có thể thẩm định được: Những người sử dụng có kinh nghiệm có thể sử dụng được tất cả các chức năng của hệ thống chỉ sau hai tiếng tập huấn. Sau khoá huấn luyện này, số lỗi chương trình gây ra bởi người sử dụng là không quá hai lỗi một ngày. 32
  • 33. c. Đặc tả miền ứng dụng Đặc tả miền ứng dụng được xác định từ miền ứng dụng của hệ thống và phản ánh các thuộc tính và ràng buộc của miền ứng dụng. Nó có thể là yêu cầu chức năng hoặc phi chức năng. 33
  • 34. c. Đặc tả miền ứng dụng Nếu đặc tả miền ứng dụng không được thoả mãn thì có thể hệ thống sẽ không làm việc được. Một số vấn đề liên quan: – Khả năng có thể hiểu được: các yêu cầu được biểu diễn dưới ngôn ngữ của lĩnh vực ứng dụng. – Ẩn ý: Các chuyên gia có hiểu biết về lĩnh vực của họ nhưng họ không biết cách xây dựng những yêu cầu miền ứng dụng một cách rõ ràng, mang tính kỹ thuật. 34
  • 35. c. Đặc tả miền ứng dụng Ví dụ về đặc tả miền ứng dụng của HTQLTV: – Giao diện người dùng chuẩn cho tất cả các CSDL đều dựa trên chuẩn phù hợp với mô hình mạng Client- Server. – Vì vấn đề bản quyền nên một số tài liệu phải xoá ngay khi vừa chuyển đến. – Phụ thuộc vào yêu cầu của người sử dụng, những tài liệu đó có thể được in ngay trên server và chuyển đến cho người sử dụng hoặc gửi đến cho máy in mạng. 35
  • 36. d. Một số kỹ thuật đặc tả yêu cầu HT 1. Đặc tả bằng ngôn ngữ hướng cấu trúc: – Sử dụng ngôn ngữ hướng cấu trúc sẽ yêu cầu người viết đặc tả tuân theo những mẫu được định nghĩa trước. Tất cả các yêu cầu đều được viết theo chuẩn và các thuật ngữ được sử dụng có thể bị hạn chế. – Ưu điểm của phương pháp này là đạt được mức độ diễn tả cao nhất của ngôn ngữ tự nhiên nhưng mức độ đồng nhất lại bị lạm dụng trong các đặc tả. 36
  • 37. d. Một số kỹ thuật đặc tả yêu cầu HT 2. Đặc tả dựa biểu mẫu (Form-based): – Đặc tả dựa biểu mẫu định nghĩa các chức năng hoặc thực thể, mô tả đầu vào và nơi xuất phát của nó, mô tả đầu ra và nơi nó sẽ đến. Đặc tả dựa biểu mẫu chỉ rõ những thực thể cần thiết, các điều kiện trước và sau (nếu thích hợp), các ảnh hưởng của chức năng. 3. Biểu đồ trình tự: – Biểu đồ trình tự biểu diễn trình tự các sự kiện xảy ra khi người sử dụng tương tác với hệ thống. Nếu ta đọc biểu đồ này từ đầu đến cuối thì ta sẽ thấy được thứ tự của các hành động được thực hiện. 37
  • 38. 3.1.1. Đặc tả yêu cầu phần mềmĐặc tả mô tả (Descriptive Specifications) – Biểu đồ thực thể liên kết (Entity-Relationship Diagrams) – Đặc tả Logic (Logic Specifications) – Đặc tả đại số (Algebraic Specifications) 38
  • 39. Tài liệu đặc tả yêu cầu Tài liệu đặc tả yêu cầu là những yêu cầu chính thức về những gì cần phải thực hiện bởi đội phát triển hệ thống. Tài liệu đặc tả yêu cầu nên bao gồm cả các định nghĩa về yêu cầu của người sử dụng và đặc tả yêu cầu hệ thống. Tài liệu đặc tả yêu cầu không phải là tài liệu thiết kế hệ thống. Nó chỉ thiết lập những gì hệ thống phải làm, chứ không phải mô tả rõ làm như thế nào. 39
  • 40. Các yêu cầu của 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
  • 41. Ví dụ tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE: – 1. Giới thiệu 1.1. Mục đích của tài liệu yêu cầu 1.2. Phạm vi của sản phẩm 1.3. Các định nghĩa, từ viết tắt 1.4. Các tham chiếu 1.5. Tổng quan về tài liệu yêu cầu – 2. Mô tả chung 2.1. Giới thiệu chung về sản phẩm 2.2. Các chức năng của sản phẩm 2.3. Đặc điểm của người sử dụng 2.4. Các ràng buộc 2.5. Giả thiết và các phụ thuộc – 3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền ứng dụng và giao diện. – 4. Phụ lục – 5. Chỉ mục 41
  • 42. 3.1.2. Phân tích hệ thống 42
  • 43. 3.1.2. Phân tích hệ thốngNghiªn cøu Ph©n tÝch kh¶ thi yªu cÇu X¸c ®Þnh yªu cÇu §Æc t¶ B¸o c¸o yªu cÇu kh¶ thi Tài liệu mô tả hệ thống Tµi liÖu ®Þnh nghÜa yªu cÇuQuá trình Tµi liÖu hình Thẩm định ®Æc t¶ yªu cÇuthành yêu cầu Tµi liÖu yªu cÇu 43
  • 44. 3.1.2. Phân tích hệ thống Xác định khách hàng, cùng khách hàng phát triển các yêu cầu Xây dựng mô hình phân tích (hiểu bài toán): – dữ liệu – chức năng – trạng thái Làm bản mẫu đối với các chức năng chưa rõ ràng Tạo đặc tả yêu cầu phần mềm Thẩm định đặc tả yêu cầu 44
  • 45. 3.1.2. Phân tích hệ thống Các nguyên lý phân tích Các phương pháp mô hình hóa 45
  • 46. Nguyên lý 1 Nội dung: Mô hình hóa miền thông tin Phải hiểu và biểu diễn được miền thông tin (problem domain) – định danh dữ liệu (đối tượng, thực thể) – định nghĩa các thuộc tính – thiết lập các mối quan hệ giữa các dữ liệu Từ điển dữ liệu, mô hình thực thể mối quan hệ, mô hình khái niệm 46
  • 47. Nguyên lý 2 Nội dung: Mô hình hóa chức năng Bản chất của phần mềm là biến đổi thông tin – định danh các chức năng (biến đổi thông tin) – xác định cách thức dữ liệu (thông tin) di chuyển trong hệ thống – xác định các tác nhân tạo dữ liệu và tác nhân tiêu thụ dữ liệu Mô hình phân rã chức năng, mô hình luồng dữ liệu 47
  • 48. Nguyên lý 3Nội dung: Mô hình hóa hành viPhần mềm (hệ thống) có trạng thái (hành vi) xác định các trạng thái của hệ thống xác định các dữ kiện làm thay đổi hành vi hệ thống ví dụ: bàn phím, chuột, các cổng thông tin... Biểu đồ trạng thái 48
  • 49. Nguyên lý 4Nội dung: Phân hoạch các mô hình Làm mịn, phân hoạch và biểu diễn các mô hình ở các mức khác nhau – làm mịn các mô hình dữ liệu – tạo cây (mô hình) phân rã chức năng – biểu diễn hành vi ở các mức chi tiết khác nhau Mô hình luồng dữ liệu các mức 1,2,3,.. 49
  • 50. Mô hình hóa Biểu đồ phân rã chức năng (FDD) Biểu đồ luồng dữ liệu (DFD) Biểu đồ thực thể mối quan hệ (ER) 50
  • 51. Mô hình hóa với FDDBiểu đồ phân rã chức năng (Function Decomposition Diagram)• Xác định phạm vi của hệ thống• Phân hoạch chức năng• Tạo nền tảng cho thiết kế kiến trúc hệ thống chức năng liên kết 51
  • 52. Mô hình hóa với FDD (2)• Ví dụ bán hàng nhận đơn hàng xử lý đơn hàng gửi hàng 52
  • 53. Ví dụ mô hình phân cấp chức năng đối với HTQLTV HỆ THỐNG QUẢN LÝ THƯ VIỆN CẬP NHẬT TÌM KIẾM XỬ LÝ THỐNG KÊ Cập nhật Cập nhật Tìm kiếm Tìm kiếm Xử lý Xử lý Xử lý Thống kê Thống kê bạn đọc Sách bạn đọc sách mượn Trả Sách mất Sách bạn đọcNhập Sửa, Nhập Sửa Tìm Tìm Tìm Tìm Tìm Tìm Tìm TK TK TK TK TK TK TKthông Xoá thông ,Xoá theo theo theo theo theo tên nhà Nhà Sách Loại sách tên bạn bạn tin thông tin thông mã tên mã tên Loại tác xuất xuất bổ sách đang tác đọc đọc bạn tin sách tin mượn đang bạn bạn sách sách sách giả bản bản sung giả quá đọc bạn sách mượn đọc đọc sách hạn đọc 53
  • 54. Mô hình hóa với DFDBiểu đồ luồng dữ liệu - Data Flow Diagram • Cách thức dữ liệu được xử lý trong hệ thống • Có nhiều mức chi tiết khác nhau (có cấu trúc) • Có nhiều biến thể và mở rộng khác nhau 54
  • 55. Mô hình hóa với DFD (2) • Các đối tượng trong DFD (cã nhiÒu c¸ch biÓu diÔn kh¸c nhau) T¸c nh©n ngoµi - ®èi t−îng bªn ngoµi hÖ thèng - ph¸t sinh hoÆc tiÕp nhËn th«ng tin TiÕn tr×nh - thao t¸c ®èi víi th«ng tin (biÕn ®æi) 55
  • 56. Mô hình hóa với DFD (3)• Các đối tượng trong DFD (cã nhiÒu c¸ch biÓu diÔn kh¸c nhau) Luång d÷ liÖu - luång th«ng tin di chuyÓn trong hÖ thèng Kho d÷ liÖu - n¬i l−u tr÷ d÷ liÖu 56
  • 57. Mô hình hóa với DFD (4)• Các bước để xây dựng o Ph©n r· chøc n¨ng hÖ thèng o LiÖt kª c¸c t¸c nh©n, c¸c kho¶n môc d÷ liÖu o VÏ DFD cho c¸c møc 57
  • 58. Mô hình hóa với DFD (5)•Một số nguyên tắc oC¸c tiÕn tr×nh ph¶i cã luång vµo vµ luång ra o Kh«ng cã luång d÷ liÖu trùc tiÕp gi÷a t¸c nh©n víi t¸c nh©n hay kho d÷ liÖu o Luång d÷ liÖu kh«ng quay l¹i n¬i xuÊt ph¸t 58
  • 59. Mô hình ngữ cảnh HTQLTV Yêu cầu Nhà xuất bản Yêu cầu cấp thẻ đặt sách Yêu cầu hủy thẻ Lý do từ chối Phiếu thu /chi Từ chốiBạn đọc Hệ thống Cung cấp sách Cấp thẻ quản lý thư viện Nhắc trả sách Kết qủa Yêu cầu Yêu cầu mượn - trả Báo cáo Chỉ đạo Yêu cầu tìm kiếm Kết quả Ban giám đốc 59
  • 60. Biểu đồ DFD mức đỉnh của HTQLTV Kết quả Y / C tìm kiếm NHÀ XUẤT BẢN BAN GIÁM ĐỐC Y/C Cung Y/C Sách mượn Từ Kết đặ t cấ p tìm Yêu cầu cấp thẻ chối quả sách sách kiếm Yêu cầu hủy thẻ Bạn đọc TÌM KIẾM Lý do từ chối CẬP NHẬT (2) (1) Cấp thẻ Phiếu thu Yêu cầu mượn– trả Phiếu thu chi SáchBẠN ĐỌC XỬ LÝ MƯỢN THỐNG KÊ Lý do từ chối TRẢ (4) (3) Thông tin về sách Kết Y/C Phiếu chi quả, Bạn đọc chỉ báo đạo cáo Sách mượn BAN GIÁM ĐỐC 60 Nhắc trả sách
  • 61. DFD mức dưới đỉnh chức năng QLTT Bạn đọc Yêu cầu cấp thẻ Lý do từ chối Bạn đọc Thêm thông Cấp thẻ tin bạn đọc Phiếu thu ( 1.1.1 )Bạn đọc Yêu cầu hủy - sửa thẻ Phiếu thu chi Lý do từ chối Sửa, xóa thông Phiếu chi tin bạn đọc Thông tin bạn đọc ( 1.1.2 ) Bạn đọc Sách mượn 61
  • 62. DFD mức dưới đỉnh chức năng Xử lý mượn trả Yêu cầu mượn - trả Lý do từ chối Xử lý Thông tin sách Mượn - Trả ( 3.1 ) Bạn đọc + Sách mất Sách mượn + Số thẻBạn đọc Sách Xử lý Phiếu thu Sách mất ( 3.2 ) Phiếu thu chi 62
  • 63. DFD mức dưới đỉnh chức năng Tìmkiếm sách Tìm kiếm Yêu cầu tìm kiếm Yêu cầu tìm kiếm theo mã sách Kết quả Kết quả ( 2.2.1) Sách Bạn đọc Ban quản lý Yêu cầu tìm kiếm Kết quả Tìm kiếm Kết quả Yêu cầu tìm kiếm theo Tên sách ( 2.2.2 ) 63
  • 64. DFD mức dưới đỉnh chức năng Thốngkê bạn đọc Yêu cầu Thống kê BĐ Nhắc trả sách Báo cáo quá hạn ( 4.1.1 ) Bạn Ban Sách mượn Bạn đọc đọcquản lý Yêu cầu Thống kê BĐ đang mượn Báo cáo ( 4.1.2 ) 64
  • 65. Mô hình hóa với ER Mô hình dữ liệu được sử dụng để mô tả cấu trúc logic của dữ liệu được xử lý bởi hệ thống. Thông thường, chúng ta hay sử dụng mô hình quan hệ -thực thể (ER) nhằm thiết lập mối quan hệ giữa các thực thể và thuộc tính của các thực thể. Mô hình này được sử dụng trong thiết kế CSDL và thường được cài đặt trong các CSDL quan hệ. 65
  • 66. Mô hình hóa với ER Biểu đồ thực thể mối quan hệ (Entity Relationship Diagram) • Mô tả mối quan hệ vốn có của thế giới thực o Thực thể o Mối quan hệ Phân tích dữ liệu độc lập với xử lý Tạo ra mô hình trừu tượng hướng khách hàng 66
  • 67. Mô hình hóa với ER (2)•Các đối tượng Thùc thÓ - lµ c¸c ®èi t−îng thÕ giíi thùc mµ chóng ta muèn xö lý - cã thÓ lµ ®èi t−îng thùc hoÆc trõu t−îng Thuéc tÝnh - ®Æc ®iÓm cña thùc thÓ 67
  • 68. Mô hình hóa với ER (3)• Các đối tượng Mối quan hệ - mèi liªn hÖ gi÷a c¸c thùc thÓ - lµ th«ng tin cÇn l−u tr÷/xö lý KÕ thõa - quan hÖ kÕ thõa gi÷a c¸c thùc thÓ 68
  • 69. Mô hình hóa với ER (4)• Ví dụ tªn m· sv ®Þa chØ sinh viªn phim l−u bản sao tr÷ 69
  • 70. Mô hình hóa với ER (5)• Lực lượng tham gia mối quan hệ (0, m) object1 relationship object 2 (1, 1) object1 relationship object 2 (0, m) (1, 1) 70
  • 71. Mô hình hóa với ER (6)•Xây dựng các thực thể và mối quan hệ Thùc thÓ - lµ c¸c danh tõ (trong c©u m« t¶ yªu cÇu) - cã c¸c thuéc tÝnh khãa (x¸c ®Þnh duy nhÊt) Mối quan hệ - ho¹t ®éng xÈy ra gi÷a c¸c thùc thÓ - cã nghÜa víi ho¹t ®éng cña hÖ thèng - lµ ®éng tõ 71
  • 72. Mô hình hóa với ER (7)• Các bước mô hình hóa với ER o Xác định các thực thể và các thuộc tính của các thực thể o Xác định các mối quan hệ giữa các thực thể o Mô tả các thực thể, mối quan hệ và các thuộc tính 72
  • 73. Ví dụ mô hình ER của HTQLTV 73
  • 74. Từ điển dữ liệu Trên thực tế, mô hình dữ liệu thường không chi tiết. Người phát triển có thể sử dụng từ điển dữ liệu làm công cụ bổ trợ. Từ điển dữ liệu là danh sách tất cả các tên gọi được sử dụng trong các mô hình hệ thống. Đó có thể là các thực thể, quan hệ và các thuộc tính … Ưu điểm của từ điển dữ liệu là: – hỗ trợ quản lý tên và tránh trùng lặp tên, – lưu trữ kiến thức một cách có tổ chức kết nối pha phân tích, thiết kế và cài đặt. 74
  • 75. Ví dụ: từ điển dữ liệu của HTQLTV Tên Mô tả KiểuSach Tên quyển sách có Thực thể trong thư việnTacgia Tên tác giả viết Thuộc tính sáchNXB Địa chỉ nhà xuất Thuộc tính bản quyển sách… … … 75
  • 76. 3.2. Thiết kế phần mềm3.2.1. Thiết kế giao diện3.2.2. Thiết kế chương trình3.2.3. Thiết kế các tập tin dữ liệu 76
  • 77. 3.2. Thiết kế phần mềm Là thiết kế cấu hình phần cứng và cấu trúc phần mềm (gồm cả chức năng và dữ liệu) để có được hệ thống thỏa mãn các yêu cầu đề ra. Đặc điểm: – Phân chia mô hình phân tích ra các hệ con – Tìm ra sự tương tranh (concurrency) trong hệ thống – Phân bố các hệ con cho các bộ xử lý hoặc các nhiệm vụ (tasks) – Phát triển thiết kế giao diện – Chọn chiến lược cài đặt quản trị dữ liệu 77
  • 78. 3.2. Thiết kế phần mềm Đặc điểm: – Tìm ra nguồn tài nguyên chung và cơ chế điều khiển truy nhập chúng – Thiết kế cơ chế điều khiển thích hợp cho hệ thống, kể cả quản lý nhiệm vụ – Xem xét các điều kiện ràng buộc được xử lý như thế nào 78
  • 79. 3.2. Thiết kế phần mềm Lưu ý trong quá trình thực hiện thiết kế phần mềm: (1) Có thể trích được luồng dữ liệu từ hệ thống: đó là phần nội dung đặc tả yêu cầu và giao diện (2) Xem xét tối ưu tài nguyên kiến trúc lên hệ thống rồi quyết định kiến trúc (3) Trong quá trình biến đổi dữ liệu, hãy xem những chức năng được kiến trúc như thế nào (4) Từ kiến trúc các chức năng theo (3), hãy xem xét và chỉnh lại, từ đó chuyển sang kiến trúc chương trình và thiết kế chi tiết 79
  • 80. 3.2. Thiết kế phần mềm(5) Quyết định các đơn vị chương trình theo các chức năng của hệ phần mềm có dựa theo luồng dữ liệu và phân chia ra các thành phần(6) Khi cấu trúc chương trình lớn quá, phải phân chia nhỏ hơn thành các môđun(7) Xem xét dữ liệu vào-ra và các tệp dùng chung của chương trình. Truy cập tệp tối ưu(8) Hãy nghĩ xem để có được những thiết kế trên thì nên dùng phương pháp luận và những kỹ thuật gì? 80
  • 81. 3.2.1. Thiết kế giao diện Giao diện người dùng cần phải được thiết kế sao cho phù hợp với kỹ năng, kinh nghiệm và sự trông đợi của người sử dụng nó. Người sử dụng hệ thống thường đánh giá hệ thống thông qua giao diện hơn là chức năng của nó. Giao diện hệ thống nghèo nàn có thể khiến người sử dụng tạo ra các lỗi hết sức nghiêm trọng. Đó là lý do tại sao nhiều hệ thống phần mềm không bao giờ được sử dụng. 81
  • 82. 3.2.1. Thiết kế giao diện Tác nhân con người trong thiết kế giao diện – Một nhân tố quan trọng ảnh hưởng tới quá trình thiết kế giao diện đó chính là người sử dụng hệ thống. Do đó, chúng ta phải tìm hiểu một số đặc điểm của người sử dụng có liên quan đến giao diện hệ thống: Khả năng nhớ tức thời của con người bị hạn chế: con người chỉ có thể nhớ ngay khoảng 7 loại thông tin. Nếu ta biểu diễn nhiều hơn 7 loại, thì có thể khiến người sử dụng không nhớ hết và gây ra các lỗi. 82
  • 83. – Người sử dụng có thể gây ra lỗi: khi người sử dụng gây ra lỗi khiến hệ thống sẽ hoạt động sai, những thông báo không thích hợp có thể làm tăng áp lực lên người sử dụng và do đó, càng xảy ra nhiều lỗi hơn.– Người sử dụng là khác nhau: con người có những khả năng khác nhau. Những người thiết kế không nên chỉ thiết kế giao diện phù hợp với những khả năng của chính họ.– Người sử dụng thích các loại tương tác khác nhau: một số người thích hình ảnh, văn bản, âm thanh … 83
  • 84. 3.2.1. Thiết kế giao diện Các nguyên tắc thiết kế giao diên – Sự quen thuộc của người sử dụng: giao diện phải được xây dựng dựa trên các thuật ngữ và các khái niệm mà người sử dụng có thể hiểu được hơn là những khái niệm liên quan đến máy tính. Ví dụ: hệ thống văn phòng nên sử dụng các khái niệm như thư, tài liệu, cặp giấy … mà không nên sử dụng những khái niệm như thư mục, danh mục … – Thống nhất: hệ thống nên hiển thị ở mức thống nhất thích hợp. Ví dụ: các câu lệnh và menu nên có cùng định dạng … – Tối thiểu hoá sự bất ngờ: nếu một yêu cầu được xử lý theo cách đã biết trước thì người sử dụng có thể dự đoán các thao tác của những yêu cầu tương tư. 84
  • 85. 3.2.1. Thiết kế giao diện Các nguyên tắc thiết kế giao diên – Khả năng phục hồi: hệ thống nên cung cấp một số khả năng phục hồi từ lỗi của người sử dụng và cho phép người sử dụng khôi phục lại từ chỗ bị lỗi. Khả năng này bao gồm cho phép làm lại, hỏi lại những hành động như xoá, huỷ … – Hướng dẫn người sử dụng: như hệ thống trợ giúp, hướng dẫn trực tuyến … – Tính đa dạng: hỗ trợ nhiều loại tương tác cho nhiều loại người sử dung khác nhau. Ví dụ: nên hiển thị phông chữ lớn với những người cận thị 85
  • 86. 3.2.1. Thiết kế giao diện Biểu diễn thông tin – Biểu diễn thông tin có liên quan tới việc hiển thị các thông tin trong hệ thống tới người sử dụng. Thông tin có thể được biểu diễn một cách trực tiếp hoặc có thể được chuyển thành nhiều dạng hiển thị khác như: dạng đồ hoạ, âm thanh … – Thông tin cần biểu diễn được chia thành hai loại: – Thông tin tĩnh: được khởi tạo ở đầu của mỗi phiên. Nó không thay đổi trong suốt phiên đó và có thể là ở dạng số hoặc dạng văn bản. – Thông tin động: thay đổi trong cả phiên sử dụng và sự thay đổi này phải được người sử dụng quan sát 86
  • 87. 3.2.1. Thiết kế giao diện Quy trình thiết kế giao diện người dùng – Thiết kế giao diện người dùng là một quy trình lặp lại bao gồm sự cộng tác giữa người sử dụng và người thiết kế. Trong quy trình này gồm 3 hoạt động cơ bản: Phân tích người sử dụng: tìm hiểu những gì người sử dụng sẽ làm với hệ thống. Lập mẫu thử hệ thống: xây dựng một tập các mẫu thử để kiểm thử Đánh giá giao diện: kiểm thử các mẫu thử cùng với người sử dụng. 87
  • 88. Quy trình thiết kế giao diện người dùng 88
  • 89. 3.2.1. Thiết kế giao diện Thiết kế về các thủ tục người dùng và các giao diện b1. Thủ tục người dùng/chức năng thủ công – Gồm: Mã hoá thông tin thu nhập Kiểm soát và sửa chữa thông tin Nhập thông tin Kiểm tra tài liệu xuất Phân phối tài liệu xuất – Yêu cầu thiết kế chức năng thủ công: Miêu tả nội dung công việc rõ ràng: Mục đích cần đạt đáp ứng yêu cầu của hệ thống, các bước thực hiện, yêu cầu của mỗi bước Thông tin chính xác; Ấn định độ chính xác phải đạt Ấn định mức năng suất cần thiết (gõ phím ít nhất), hướng dẫn mức xử lý khi có sai sót 89
  • 90. 3.2.1.Thiết kế giao diệnb2. Thiết kế việc thu nhập dữ liệu thông qua các biểu mẫu (tờ khai, các phiéu điều tra, v..v) – Chọn phương thức thu nhập : On-line Trì hoãn Từ xa – Xác định khuôn mẫu thu nhập: Khung (để điền) Câu hỏi (câu hỏi đóng: trả lời xác định trước, câu hỏi mở: gợi ý) – Yêu cầu biểu mẫu: Thuận tiện cho người điều tra Thuận tịện mã hoá Thuận tiện người gõ phím Nội dung đơn giản, rõ ràng, chính xác 90
  • 91. 3.2.1.Thiết kế giao diệnb3. Thiết kế các tài liệu xuất Tài liệu xuất: – Các bảng biểu thống kê, tổng hợp – Các chứng từ giao dịch (đơn hàng, hóa đơn v..v) Xác định: – Phương tiện: giấy, màn hình, đĩa, v..v – Phương thức: lập tức hay trì hoãn – Dạng tài liệu xuất : có cấu trúc hay không có cấu trúc – Cách trình bày: đầu _ thân_cuối Yêu cầu: – Đủ, chính xác (kiểm tra không nhập nhằng), dễ hiểu, dễ đọc. 91
  • 92. 3.2.1.Thiết kế giao diệnb4. Thiết kế các màn hình và đơn chọn: giao diện đối thoại giữa người dùng và máy tính – Dựa trên yêu cầu của người dùng và việc hiển thị chi tiết về dữ liệu, các dạng hội thoại thường gồm: Câu lệnh, câu nhắc: Máy hỏi hay nhắc, người đáp lại Đơn chọn (Menu): Người dùng chọn một mục trong nhiều mục Điền mẫu: Người dùng điền thông tin vào ô mẫu trên màn hình Sử dụng các biểu tượng (Icon) để tăng tính trực quan – Yêu cầu thiết kế: Vào / ra gần nhau Thông tin thường tối thiểu (cần đâu lấy đấy) Sáng sủa (dễ nhìn, dễ đọc) Lệnh phải rành mạch (muốn gì? Làm gì?) 92
  • 93. Ví dụ thiết kế giao diện HTQLTV 93
  • 94. Giao diện chức năng Thêm bạn đọc 94
  • 95. Giao diện chức năng Sửa thông tin bạn đọc 95
  • 96. Giao diện chức năng Hủy thẻ bạn đọc 96
  • 97. Giao diện chức năng Thêm đầu sách 97
  • 98. Giao diện chức năng Mượn sách 98
  • 99. Giao diện chức năng Trả sách 99
  • 100. Giao diện chức năng Tìm kiếm thông tin 100
  • 101. Giao diện chức năng Thông kê bạn đọcmượn sách quá hạn 101
  • 102. 3.2.2.Thiết kế chương trình Thiết kế nội dung của chương trình mà không phải viết chương trình cụ thể. Người phát triển cần thiết kế: – Chức năng như trong BLD. Ngoài ra: – Chức năng đối thoại – Chức năng xử lí lỗi – Chức năng xử lí vào/ ra – Chức năng tra cứu CSDL – Chức năng Module điều hành 102
  • 103. 3.2.2.Thiết kế chương trình Nội dung chủ yếu trong giai đoạn thiết kế chương trình là: – Xác định cấu trúc tổng quát – Phân định các Module CT – Xác định mối liên quan giữa các Module đó (thông qua lời gọi và các thông tin trao đổi) – Đặc tả các Module chương trình – Gộp các Module thành chương trình – Thiết kế các mẫu thử 103
  • 104. 3.2.2.Thiết kế chương trình Thiết kế chương trình theo mô hình kiến trúc client-server – Là một mô hình hệ thống trong đó hệ thống bao gồm một tập hợp các server cung cấp dịch vụ và các client truy nhập và sử dụng các dịch vụ đó. Các thành phần chính của mô hình này bao gồm: Tập hợp các server sẽ cung cấp những dịch vụ cụ thể như: in ấn, quản lý dữ liệu… Tập hợp các client truy nhập đến server để yêu cầu cung cấp dịch vụ. Hệ thống mạng cho phép client truy cập tới dịch vụ mà server cung cấp. 104
  • 105. Mô hình Client – Server Client (máy khách) phải biết tên của Server (máy chủ) và các dịch vụ mà server cung cấp. Nhưng server thì không cần xác định rõ client và hiện tại có bao nhiêu client. Client tạo ra một yêu cầu tới server và chờ server trả lời. Ưu điểm của mô hình client - server: – Phân tán dữ liệu rõ ràng – Sử dụng các hệ thống được kết nối mạng một cách hiệu quả và chi phí dành cho phần cứng có thể rẻ hơn. – Dễ dàng bổ sung hoặc nâng cấp server 105
  • 106. Mô hình Client – Server Nhược điểm của mô hình client - server: – Không phải là mô hình dữ liệu dùng chung nên các hệ thống con có thể sử dụng các tổ chức dữ liệu khác nhau. Do đó, việc trao đổi dữ liệu có thể không hiệu quả. – Quản lý mỗi server không thống nhất, dư thừa. – Không đăng ký tên và dịch vụ tập trung. Điều này làm cho việc tìm kiếm server hoặc các dịch vụ rất khó khăn. 106
  • 107. Mô hình Client – Server của hệ thống thư viện phim và ảnh 107
  • 108. 3.2.3. Thiết kế các tập tin dữ liệu Thiết kế tập tin dữ liệu phải dựa vào: – Biểu đồ cấu trúc dữ liệu: mô hình quan hệ, mô hình quan hệ thực thể liên kết E-R – Biểu đồ luồng dữ liệu trong đó đặc biệt quan tâm đến kho dữ liệu. – Hệ Quản trị CSDL có sẵn: Mỗi hệ quản trị CSDL đều có ngôn ngữ định nghĩa dữ liệu sẵn. 108
  • 109. 3.2.3. Thiết kế các tập tin dữ liệu Khi thiết kế các tập tin dữ liệu/CSDL phải đảm bảo sao cho các dữ liệu phải đủ, không trùng lặp, việc truy cập đến các tập tin dữ liệu phải thuận tiện, tốc độ nhanh. – Bổ xung thêm một số thuộc tính tính toán, lặp lại một số thuộc tính, ghép một số thực thể thành một tập tin.... – Đôi khi đã chuẩn hóa dữ liệu đạt chuẩn 3 NF, BCNF.. nhưng để phục vụ các thao tác tìm kiếm, xử lý nhanh chóng, thì các chuẩn trên có thể bị phá vỡ thành các chuẩn mức thấp hơn. 109
  • 110. 3.3. Lập trình 3.3.1. Khái niệm 3.3.2. Phương pháp lập trình 3.3.3. Ngôn ngữ lập trình 3.3.4. Phong cách lập trình 110
  • 111. 3.3.1. Khái niệm Lập trình là quá trình chuyển đổi từ thiết kế chi tiết sang mã lệnh Lựa chọn ngôn ngữ lập trình - Phụ thuộc vào cấu hình máy – Phụ thuộc vào số lượng ngôn ngữ lập trình sẵn có – Phụ thuộc vào thói quen sử dụng ngôn ngữ lập trình – Phụ thuộc vào khách hàng 111
  • 112. 3.3.1. Khái niệm Người lập trình cần xây dựng thông tin tối thiểu cho một mô-đun chương trình, bao gồm: – Tên mô-đun – Mô tả vắn tắt các công việc mô-đun phải thực hiện – Tên lập trình viên – Ngày viết – Ngày chỉnh sửa – Danh sách các tham số – Danh sách các biến 112
  • 113. 3.3.2. Phương pháp lập trình Lập trình tuyến tính Lập trình cấu trúc Lập trình Hướng đối tượng 113
  • 114. Lập trình tuyến tính Chương trình được viết tuần tự với các câu lệnh thực hiện từ đầu đến cuối. Không có/thiếu các lệnh có cấu trúc (for, while..) Thiếu khả năng khai báo biến cục bộ Ngôn ngữ lập trình: assembly, basic.. 114
  • 115. Lập trình tuyến tính Ngôn ngữ lập trình tuyến tính không có khả năng kiểm soát phạm vi nhìn thấy của các dữ liệu. Mọi dữ liệu trong chương trình đều là dữ liệu toàn cục, nghĩa là chúng có thể bị sửa đổi ở bất kỳ phần nào của chương trình. Việc dò tìm các thay đổi không mong muốn đó của các phần tử dữ liệu trong một dãy mã lệnh dài thường làm cho các lập trình viên mất rất nhiều thời gian. Lập trình tuyến tính được sử dụng trong các phần mềm còn rất đơn giản. Hiện nay, khoa học máy tính ngày càng phát triển, các phần mềm đòi hỏi ngày càng phức tạp và lớn hơn rất nhiều, phương pháp lập trình tuyến tính được coi là kém hiệu quả. 115
  • 116. Lập trình cấu trúc Phương pháp lập trình thủ tục hay lập trình cấu trúc: hệ thống chia các chức năng (hàm) thành các chức năng nhỏ hơn. Các chức năng nhỏ này lại được chia tiếp thành các chức năng nhỏ hơn nữa cho đến khi được các khối (hàm) chương trình đủ nhỏ. Việc phân tích này được thể hiện trực quan theo sơ đồ khối. Chương trình được tổ chức thành các chương trình con. Chương trình = Cấu trúc dữ liệu + giải thuật 116
  • 117. Lập trình cấu trúc Lập trình có cấu trúc sử dụng các lệnh có cấu trúc, sử dụng chương trình con, biến cục bộ. Các ngôn ngữ hỗ trợ lập trình hướng cấu trúc phổ biến là Pascal, C, Foxpro Lập trình hướng cấu trúc đã trở nên rất phổ biến trong những năm 80 và đầu những năm 90, nhưng do những hạn chế và những nhược điểm rõ ràng khi lập trình hệ thống lớn, lập trình hướng cấu trúc đã dần bị thay thế cho phương pháp lập trình hướng đối tượng 117
  • 118. Lập trình cấu trúc Những ngôn ngữ lập trình hướng cấu trúc chỉ còn được sử dụng để dạy học và lập trình những chương trình nhỏ mang tính chất cá nhân. Trong thương mại, nó đã không còn được dùng đến nhiều. 118
  • 119. Lập trình Hướng đối tượng Lập trình hướng đối tượng (Object Oriented Programming-OOP): Là phương pháp lập trình lấy đối tượng làm nền tảng để xây dựng thuật giải, xây dựng chương trình. OOP là kĩ thuật lập trình hỗ trợ công nghệ đối tượng. OOP được xem là giúp tăng năng suất, đơn giản hóa độ phức tạp khi bảo trì cũng như mở rộng phần mềm bằng cách cho phép lập trình viên tập trung vào các đối tượng phần mềm ở bậc cao hơn. 119
  • 120. Lập trình Hướng đối tượng Dữ liệu + Hành vi của dữ liệu = Đối tượng Những đối tượng trong một ngôn ngữ OOP là sự kết hợp giữa mã và dữ liệu mà chúng được nhìn nhận như là một đơn vị duy nhất. Mỗi đối tượng có một tên riêng biệt và tất cả các tham chiếu đến đối tượng đó được tiến hành qua tên của nó. 120
  • 121. Lập trình Hướng đối tượng Như vậy, mỗi đối tượng có khả năng nhận vào các thông báo, xử lý dữ liệu (bên trong của nó), và gửi ra hay trả lời đến các đối tượng khác hay đến môi trường. Các ngôn ngữ hỗ trợ lập trình hướng đối tượng phổ biến là: C#, C++, Java, Perl, PHP, Smalltalk.. 121
  • 122. 3.3.3. Ngôn ngữ lập trình Lập trình là một trong những giai đoạn không thể thiếu trong công nghệ phần mềm. Ngôn ngữ lập trình là phương tiện để liên lạc giữa con người và máy tính. Tiến trình lập trình - sự liên lạc thông qua ngôn ngữ lập trình - là một hoạt động con người. 122
  • 123. 3.3.3. Ngôn ngữ lập trình Đối với từng dự án phần mềm khác nhau người ta sẽ lựa chọn ngôn ngữ lập trình phù hợp. Tuy nhiên, ngôn ngữ lập trình được lựa chọn cần có các đặc trưng sau: – dễ dịch thiết kế sang chương trình, – có trình biên dịch hiệu quả, – khả chuyển chương trình gốc, – có sẵn công cụ phát triển: – dễ bảo trì. 123
  • 124. Lựa chọn ngôn ngữ lập trình Dựa vào: – Đặc trưng của ngôn ngữ: Năng lực (kiểu biến, các cấu trúc): Có cấu trúc, câu lệnh phong phú, hỗ trợ nhiều kiểu dữ liệu, hỗ trợ con trỏ, đệ qui, hỗ trợ hướng đối tượng, thư viện phong phú.. Tính khả chuyển: khi thay đổi phần cứng, thay đổi OS Mức độ hỗ trợ của các công cụ (editor, debugger, linker, make..): nhằm hỗ trợ biên dịch tốc độ cao, khả năng tối ưu cao, khả năng khai thác các tập lệnh, kiến trúc phần cứng mới. – Miền ứng dụng của ngôn ngữ – Năng lực, kinh nghiệm của nhóm phát triển – Yêu cầu của khách hàng 124
  • 125. Lựa chọn ngôn ngữ lập trình Các đặc trưng của ngôn ngữ lập trình sẽ quyết định miền ứng dụng của ngôn ngữ. Miền ứng dụng là yếu tố chính để chúng ta lựa chọn ngôn ngữ cho một dự án phần mềm. Ngôn ngữ FORTRAN: có khả năng tính toán với độ chính xác cao và thư viện toán học phong phú thường được sử dụng trong các dự án phần mềm trong lĩnh vực khoa học kỹ thuật. COBOL: là ngôn ngữ cho ứng dụng kinh doanh và khai thác CSDL lớn. Tuy nhiên, hiện nay các ngôn ngữ thế hệ thứ tư đã dần dần chiếm ưu thế so với COBOL. 125
  • 126. Lựa chọn ngôn ngữ lập trình PASCAL và C: là ngôn ngữ hay được chọn cho việc phát triển phần mềm hệ thống LISP, PROLOG hay OPS5: là ngôn ngữ thường được dùng trong các ứng dụng trí tuệ nhân tạo. C++: Với đặc trưng hướng đối tượng, tính hiệu quả thực hiện cũng như có nhiều công cụ và thư viện, C++ hiện đang được sử dụng rộng rãi trong lĩnh vực phát triển các ứng dụng nghiệp vụ. Smalltalk, C++, Java: là các ngôn ngữ lập trình hướng đối tượng được dùng rộng rãi nhất trong việc phát triển phần mềm hướng đối tượng. 126
  • 127. Java: là ngôn ngữ hướng đối tượng đang được sửdụng rộng rãi cho phát triển các dịch vụ Web vàphần mềm nhúng vì các lý do độ an toàn cao, tínhtrong sáng, tính khả chuyển và hướng thành phần.ASP, JavaScript, PERL: là các ngôn ngữ biêndịch (script) với những câu lệnh và thư việnmạnh. Các ngôn ngữ này hiện đang được sử dụngrộng rãi trong lập trình Web. 127
  • 128. 3.3.4. Phong cách lập trình Phong cách lập trình được coi là tốt khi: – Tuân theo các chuẩn thông dụng – Chú giải đầy đủ mỗi khi không tuân theo chuẩn Tuân theo chuẩn: – Cách đặt tên hàm và biến – Cách xây dựng câu lệnh, cấu trúc chương trình – Các viết chú thích – Cách xử lý lỗi Nhằm hướng tới phong cách làm cho mã nguồn: dễ hiểu, dễ sửa đổi, an toàn (ít lỗi) 128
  • 129. Cách đặt tên hàm và biến Đặt tên biến, tên hàm có nghĩa, gợi nhớ – Sử dụng các ký hiệu, từ tiếng Anh có nghĩa – Viết tên hàm dễ đọc: ví dụ viết DateOfBirth thay cho dateofbirth – Tránh đặt tên quá dài – Thống nhất cách dùng biến trong toàn bộ chương trình 129
  • 130. Cách xây dựng cấu trúc chương trình Chương trình cần được chia thành nhiều mô đun (hàm). Không viết hàm quá dài: – không quá 2 trang màn hình – tạo ra các hàm thứ cấp để giảm độ dài từng hàm – Không dùng quá nhiều biến cục bộ: vì lập trình viên khó có thể theo dõi đồng thời hoạt động của nhiều biến (thông thường một mô đun không quá 7 biến cục bộ). 130
  • 131. Cách viết chú thích Mọi thứ trong chương trình đều được chú thích: – Mục đích sử dụng của các biến – Chức năng của khối lệnh, câu lệnh các lệnh điều khiển các lệnh phức tạp – Chú thích các mô đun mục đích, chức năng của mô đun tham số, giá trị trả lại (giao diện) - các mô đun thuộc cấp cấu trúc, thuật toán nhiệm vụ của các biến cục bộ - tác giả, người kiểm tra, thời gian 131
  • 132. Cách xử lý lỗi Nhất quán trong xử lý lỗi: – phân loại lỗi – thống nhất định dạng thông báo lỗi,… Có thể phát hiện lỗi trong khi thực hiện, ví dụ lỗi chia cho 0 Các hàm thư viện nên tránh việc tự đưa ra thông báo lỗi. 132
  • 133. 3.4. Kiểm thử 3.4.1. Khái niệm 3.4.2. Các phương pháp kiểm thử 3.4.3. Các kỹ thuật kiểm thử 3.4.4. Các loại kiểm thử 3.4.5. Các hoạt động kiểm thử 133
  • 134. 3.4.1. Khái niệm Kiểm thử là một trong những giai đoạn quan trọng trong phát triển phần mềm, là mấu chốt của đảm bảo chất lượng phần mềm Kiểm thử là tiến trình xem xét lại đặc tả, thiết kế và mã hoá…nhằm phát hiện lỗi phần mềm. Kiểm thử thành công khi phát hiện ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử dở (Theo Sue A.Conger- The New SE) 134
  • 135. 3.4.1. Khái niệm Một phép thử được gọi là thành công nếu nó phát hiện ra khiếm khuyết của phần mềm. Kiểm thử chỉ chứng minh được sự tồn tại của lỗi trong hệ thống chứ không chứng minh được hệ thống không có lỗi. Một phép kiểm thử (ca kiểm thử) bao gồm – tên của mô đun kiểm thử – dữ liệu vào – dữ liệu ra mong muốn (kết quả đúng) – dữ liệu ra thực tế (khi đã tiến hành kiểm thử) Các ca kiểm thử nên được thiết kế khi chúng ta tạo các tài liệu phân tích và thiết kế, chứ không phải là khi đã viết xong mã nguồn. 135
  • 136. Những lưu ý khi kiểm thử1) Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử(2) Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình(3) Người kiểm thử và người phát triển nên khác nhau. 136
  • 137. Những lưu ý khi kiểm thử (4) Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần có những dữ liệu kiểm thử mà phát hiện ra lỗi. (5) Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, mà phải thiết kế trước cả dữ liệu kết quả sẽ có. (6) Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trước đó để tránh ảnh hưởng lan truyền sóng khi kiểm thử. 137
  • 138. 3.4.2. Các phương pháp kiểm thử Kiểm thử tĩnh Kiểm thử trên máy 138
  • 139. Kiểm thử tĩnh Kiểm thử tĩnh (hay kiểm thử trên bàn): sử dụng giấy và bút, kiểm tra logic, lần từng chi tiết ngay sau khi lập trình xong. Kiểm thử tĩnh thường được tiến hành trước nhằm tạo ra kịch bản cho kiểm thử động. Có 2 kỹ thuật được sử dụng – Đi xuyên suốt (walk through) – Thanh tra (inspection) 139
  • 140. Kiểm thử trên máy Kiểm thử trên máy hay kiểm thử động: Dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình. 9 bước của trình tự kiểm thử bằng máy: (1) Thiết kế trường hợp thử theo kiểm thử tĩnh (2) Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu được (3) Dịch chương trình nguồn và tạo môđun tải để thực hiện 140
  • 141. (4) Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước trên bàn việc xác định miền của các tệp(5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử(6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình)(7) Thực hiện môđun tải và ghi nhận kết quả(8) Xác nhận kết quả với kết quả kỳ vọng(9) Lặp lại thao tác (5)-(8) 141
  • 142. 3.4.3. Các kỹ thuật kiểm thử Kiểm thử hộp trắng hay kiểm thử cấu trúc Kiểm thử hộp đen (black box testing) hay kiểm thử chức năng (functional testing) 142
  • 143. Kiểm thử hộp trắng Kiểm thử hộp trắng (white box testing): sử dụng các ca kiểm thử để kiểm tra mã nguồn ở mức các mô đun đơn vị nhằm mục đích phát hiện ra các lỗi trong các chi tiết thủ tục (thuật toán), các luồng điều khiển, các trạng thái của chương trình (dữ liệu). Kiểm thử hộp trắng là sự kiểm thử dựa trên việc phân tích chương trình. Kỹ thuật chính ở đây là xác định đường đi của chương trình (điều khiển) từ đầu vàô (input) đến đầu ra (output). 143
  • 144. Kiểm thử hộp trắng Mục đích của kiểm thử hộp trắng là kiểm tra tất cả các đường đi có thể. Tức là đảm bảo mọi lệnh đều được thực hiện ít nhất một lần trong một ca thử nhiệm nào đó. Kiểm thử hộp trắng chú trọng vào phân tích các cấu trúc rẽ nhánh và các vòng lặp.. 144
  • 145. Kiểm thử hộp đen Kiểm thử hộp đen (black box testing) hay kiểm thử chức năng: sử dụng các ca kiểm thử được thiết kế dựa trên đặc tả yêu cầu, tài liệu người dùng nhằm mục đích phát hiện ra các khiếm khuyết, các lỗi của từng mô đun chương trình và toàn bộ hệ thống. 145
  • 146. Kiểm thử hộp đen Kiểm thử chức năng nhìn nhận mô đun được kiểm thử như là một hộp đen, và chỉ quan tâm đến chức năng (hành vi) của mô đun, tức là kiểm tra xem có hoạt động đúng với đặc tả hay không. Các ca kiểm thử bao gồm các trường hợp bình thường và không bình thường (dữ liệu không hợp lệ...) của mô đun. 146
  • 147. 3.4.4. Các loại kiểm thử1. Kiểm thử đơn vị: là bước kiểm thử đối với từng chức năng (hàm) nhằm mục đích chính phát hiện lỗi lập trình. Người ta thường sử dụng nhiều kiểm thử cấu trúc.2. Kiểm thử mô đun: là hình thức kiểm thử từng mô đun riêng lẻ hoặc có thể liên kết với một số hàm, mô đun khác có liên quan.3. Kiểm thử hệ con: nếu hệ thống bao gồm một số hệ con độc lập thì đây là bước tiến hành kiểm thử với từng hệ con riêng biệt. 147
  • 148. 3.4.4. Các loại kiểm thử4. Kiểm thử hệ thống (tích hợp): kiểm thử sự hoạt động tổng thể hệ thống, kiểm tra tính đúng đắn của giao diện, tính đúng đắn với đặc tả, và tính dùng được. Chủ yếu sử dụng kiểm thử chức năng.5. Kiểm thử thu (alpha): kiểm thử được tiến hành bởi một nhóm nhỏ người sử dụng dưới sự hướng dẫn của người phát triển, sử dụng các dữ liệu thực, thẩm định tính dùng được của hệ thống. 148
  • 149. 3.4.4. Các loại kiểm thử6. Kiểm thử beta: là mở rộng của kiểm thử alpha, được tiến hành với một số lớn người sử dụng không có sự hướng dẫn của người phát triển, kiểm tra tính ổn định, điểm tốt và không tốt của hệ thống. 149
  • 150. 3.4.5. Các hoạt động kiểm thử Bắt đầuLập kế hoạch Lập kế hoạch Test Thiết kế Test Chuẩn bị Cài đặt và chuẩn bị Test Test tích hợp Test Xem xét và Đánh giá kết quả test Test hệ thống Phân tích kết quả Tổng hợp, báo cáo Kết thúc 150
  • 151. 3.4.5. Các hoạt động kiểm thử Bắt đầu Lập kế hoạch Test Kế hoạch test Test case Thiết kế Test Test procedure Test scrip Cài đặt và chuẩn bị Test data Test Môi trường Test tích hợpLỗi Xem xét và Đánh giá Bcáo KQ testBiên bản test kết quả test Đề xuất Test hệ thống Tổng hợp, báo cáo Bcáo tổng hợp test Hồ sơ Kết thúc 151
  • 152. 3.4.5. Các hoạt động kiểm thử Bắt đầu Initiation (khởi động) Definition (Xác định yêu cầu)Definition Lập kế hoạch Test Xác định yêu cầuSolution Thiết kế kiến trúc Solution (Thiết kế kiến trúc) Thiết kế Test Cài đặt và chuẩn bị Construction (Xây dựng)Construction Lập trình Test Coding (lập trình)Construction Thử nghiệm Test tích hợp Xem xét và Đánh giá Testing (thử nghiệm) kết quả test Test hệ thống Tổng hợp, báo cáo Kết thúc Transition (Triển khai) Termination (Kết thúc) 152
  • 153. 3.5. Cài đặt phần mềm 3.5.1. Lập kế hoạch cài đặt 3.5.2. Biến đổi dữ liệu 3.5.3. Biên soạn tài liệu hệ thống 153
  • 154. 3.5.1. Lập kế hoạch cài đặt Từ HTTT cũ sang HTTT mới, cần phải: Chuyển đổi phần cứng Chuyển đổi phần mềm Chuyển đổi cơ sở dữ liệu Chuyển đổi công nghệ quản lý Chuyển đổi hệ thống biểu mẫu (thông dụng) Chuyển đổi các phương pháp truyền đạt thông tin Chuyển đổi các phương thức lưu trữ dữ liệu, thông tin Chuyển đổi tác phong của lãnh đạo và các nhân viên 154
  • 155. 3.5.1. Lập kế hoạch cài đặt Trong quá trình lập kế hoạch cài đặt, việc chuyển đổi kỹ thuật tương đối đơn giản. Tuy nhiên, việc chuyển đổi về con người tương đối phức tạp và kéo dài do sức ỳ và tâm lý ngại thay đổi của người sử dụng. Vì vậy, phải lập kế hoạch chuyển đổi tỷ mỷ, bao quát tất cả các lĩnh vực của hệ thống thông tin. 155
  • 156. 3.5.2. Biến đổi dữ liệu Dữ liệu giữa hai hệ thống cũ và mới thường không tương thích với nhau về phương thức lưu trữ cũng như quy cách truy cập. Do đó rất dễ dẫn đến sai sót khi biến đổi dữ liệu.Qúa trình biến đổi dữ liệu: Xác định khối lượng và chất lượng của dữ liệu (độ chính xác, tính đầy đủ và thứ tự). Làm ổn định một bản dữ liệu và tổ chức những thay đổi cho phù hợp. 156
  • 157. 3.5.2. Biến đổi dữ liệuQúa trình biến đổi dữ liệu: Tổ chức và đào tạo đội ngũ thực hiện công việc biến đổi dữ liệu. Lập lịch thời gian của quá trình biến đổi dữ liệu. Bắt đầu quá trình biến đổi dữ liệu dưới sự chỉ đạo thống nhất. 157
  • 158. 3.5.2. Biến đổi dữ liệu Thực hiện những thay đổi trong các tệp dữ liệu; Nếu trong hệ thống cũ có các tệp dữ liệu thì tốt nhất tổ chức biến đổi các tệp dữ liệu này trước, sau đó mới đến các tệp mới chuyển từ phương thức tổ chức thủ công sang. Thực hiện bước kiểm chứng lần cuối cùng để đảm bảo các tệp dữ liệu đã biến đổi phù hợp với các yêu cầu của hệ thống quản lý mới. 158
  • 159. 3.5.3. Biên soạn tài liệu hệ thống Một phần mềm khi được chuyển giao cho phía khách hàng (người sử dụng) thường kèm theo 2 loại tài liệu sau: – Tài liệu hướng dẫn sử dụng, thông tin được thu thập từ các nguồn khác nhau bao gồm các báo cáo xác định vấn đề, nghiên cứu tính thức thi, đề xuất hệ thống và – Tài liệu kỹ thuật cho người lập trình và bảo trì hệ thống. 159
  • 160. 3.6. Bảo trì phần mềm Là pha cuối cùng của vòng đời hệ thống Các hoạt động cần thực hiện – Quản lý hoạt động bảo trì – Chuẩn hóa hoạt động bảo trì (IEEE 840-1992) 160
  • 161. Các hoạt động bảo trì phần mềm Các yêu cầu bảo trì Chăm sóc Yêu cầuKhách hàng khách hàng bảo trì được đề xuất Yêu cầu bào trì được chấp nhận Ban quản lý thay đổi Kỹ sư bảo trì Mã nguồn & tài liệu hiện thời Mã nguồn & tài liệu đã được sửa 161
  • 162. Các hoạt động bảo trì phần mềm Marketing Các yêu cầu bảo trì Chăm sóc Yêu cầuKhách hàng khách hàng bảo trì được đề xuất Quản lý bảo trì Yêu cầu bào trì được chấp nhận Ban quản lý thay đổiKỹ sư bảo trì Mã nguồn & tài liệu hiện thời Yêu cầu bị Mã nguồn từ chối & tài liệu đã được sửa 162
  • 163. Các hoạt động bảo trì phần mềm Các công việc cần thực hiện: 1. Hiểu kĩ yêu cầu bảo trì 2. Phân loại yêu cầu: sửa đổi hay nâng cấp? 3. Thiết kế các sửa đổi được yêu cầu 4. Kế hoạch chuyển đổi từ thiết kế cũ 5. Đánh giá các ảnh hưởng của sửa đổi lên ứng dụng 6. Triển khai các sửa đổi 7. Thực hiện các kiểm thử đơn vị cho các phần thay đổi 8. Tiến hành kiểm thử tăng dần, thực hiện kiểm thử hệ thống với các khả năng mới 9. Cập nhật các tài liệu cấu hình, yêu cầu, thiết kế và kiểm thử. 163
  • 164. Ví dụ về chi phí hoạt động bảo trì Đánh Đánh giá giáHoạt động (person- Hoạt động (person- days) days)1. Hiểu yêu cầu và xác địnhchức năng cần sửa đổi hay 2-5 6. Dịch và tích hợp 2-3thêm vào 7. Kiểm thử chức năng2. Thay đổi thiết kế 1-4 2-4 thay đổi3. Phân tích ảnh hưởng trình 1-4 8. Kiểm thử trình diễn 2-4diễn4. Triển khai các thay đổi 9. Đưa ra bản mới và 1-4 1thành mã nguồn báo cáo kết quả5. Thay đổi thông tin cấu hình 2-6 TỔNG 14 - 35 164
  • 165. Chuẩn hóa hoạt động bảo trì Hiện nay, chuẩn IEEE 840-1992 thường được dùng trong các hoạt động bảo trì phần mềm.Các bước bảo trì phần mềm theo chuẩ 840-1992 1. Xác định vấn đề 2. Phân tích 3. Thiết kế 4. Triển khai 5. Kiểm thử hệ thống 6. Kiểm thử chấp nhận 7. Chuyển giao phần mềm 165
  • 166. Ví dụ bảo trì phần mềm đối với giai đoạn thiết kế •Tài liệu dự án gốc a. Đầu vào •Các phân tích từ pha trước •Tạo ra các trường hợp kiểm thử (test cases) b. Tiến trình •Duyệt (các yêu cầu; kế hoạch triển khai) c. Điều khiển •Kiểm chứng thiết kế •Kiểm tra thiết kế và các trường hợp kiểm thử •Duyệt( các sửa đổi; phân tích chi tiết; kế hoạch triển khai) d. Đầu ra •Cập nhật(thiết kế gốc; kế hoạch kiểm thử) •Độ linh hoạt (của thiết kế) e. Nhân tố chất •Khả năng lần vết (traceability) lượng liên quan •Khả năng sử dụng lại (Reusability) •Khả năng có thể hiểu (Comprehensibility) •Chi phí người-giờ f. Độ đo •Thời gian •Số lượng tiếp nhận thay đổi 166
  • 167. Câu hỏi ôn tập1. Nhiệm vụ chính của giai đoạn phân tích và đặc tả yêu cầu? Các công việc cần thực hiện? Các tài liệu cần bàn giao sau giai đoạn phân tích và đặc tả yêu cầu?2. Các mô hình sử dụng trong quá trình phân tích và đặc tả yêu cầu?3. Trình bày tầm quan trọng của thiết kế giao diện khi xây dựng phần mềm. Những điểm cần chú ý trong thiết kế giao diện4. Các nguyên tắc thiết kế tập tin dữ liệu, những lưu ý khi thiết kế tập tin dữ liệu là gì? 167
  • 168. Câu hỏi ôn tập5. Người phát triển lựa chọn ngôn ngữ lập trình dựa trên những yếu tố nào? Phong cách lập trình ảnh hưởng tới chất lượng phần mềm như thế nào?6. Trình bày các hoạt động kiểm thử phần mềm?7. Những lưu ý trong quá trình lập kế hoạch cài đặt phần mềm?8. Bảo trì phần mềm là gì? Hoạt động nào trong bảo trì phần mềm là chính yếu ? 168