CHƯƠNG 1: CÔNG NGHỆ YÊU CẦU

1. Tìm hiểu

- Mục đích: phần mềm thiết kế nhằm một mục đích nào đó, thường là phức tạp, từ các hoạt động của con người

- Phân tích yêu cầu: nhằm xác định chính xác mục đích này

- Chất lượng của một hệ thống phần mềm là đáp ứng được các mục tiêu và mục đích mà hệ thống pm đó đặt ra…

2. Các hệ thống “mềm

• Các thành phần phần mềm cùng loại: lõi HĐH, DV mạng, … (chức năng ổn định, chịu tác động con người)
• Hệ thống quản lý: điều hành máy bay/tiến trình CN (quy trình tự nhiên, cách thức giao tiếp quyết định)
• Hệ thống thông tin: tự động hóa vp, pm nhóm, web services, pm hỗ trợ kinh doanh (ko thể tách rời khỏi hđ, dựa trên hđ của con người)

3. Công nghệ yêu cầu

Requirements Engineering (RE) là một tập các hoạt động (Ko phải 1 thời kì hay 1 giai đoạn) liên quan tới việc xác định và truyền đạt (truyền đạt rất quan trọng khi ptich)  mục tiêu (Chất lượng=Đáp ứng mục tiêu) của một hệ thống phần mềm chuyên nghiệp, trong lĩnh vực (cần biết hđ ở đâu và ntn) mà chúng được sử dụng. Ở đây, các hoạt động RE như là cầu nối giữa các nhu cầu trong thực tế (yêu cầu là một phần của nhu cầu) của người dùng, khách hàng, và những ứng viên (tất cả các đối tác ngoài người dùng và khách hàng) khác có ảnh hưởng đến một hệ thống phần mềm, và những khả năng và cơ hội (thực hiện được gì) được tạo ra bởi những kỹ thuật phần mềm chuyên nghiệp.

- Chất lượng = Đáp ứng mục tiêu

- Một tiến trình phát triển phần mềm điển hình bao gồm: Phân tích yêu cầu – Thiết kế phần mềm – Lập trình -Kiểm thử sự phát triển - Kiểm thử sự chấp thuận – Vận hành

- Hậu quả của sai sót: Giá sửa lỗi ngày càng tăng cao vào thời điểm phát hiện. Cần dành thời gian tìm hiểu kỹ vấn đề và thu thập yêu cầu thật chính xác trong giai đoạn đầu tiên

- Nguyên nhân:

• • 1. Yêu cầu không hoàn chỉnh (13.1%)
  • 2. Thiếu sự hợp tác người dùng (12.4%
  • 3. Thiếu tài nguyên (10.6%)
  • 4. Mong muốn phi thực tế (9.9%)
  • 5. Thiếu hỗ trợ pháp lý (9.3%)
  • 6. Thay đổi yêu cầu và đặc tả (8.7%)
  • 7. Thiếu hoạch định (8.1%)
  • 8. Hệ thống không cần đến nữa (7.5%)

- Nhà phân tích là một tác nhân của sự thay đổi, là chuyên gia trong phạm vi vấn đề

- Cần định nghĩ đc “vấn đề”

• (Which) Vấn đề nào cần được giải quyết ? (Xác định ranh giới vấn đề – Boundaries)
• (Where) Vấn đề ở đâu ? (Hiểu ngữ cảnh/ phạm vi vấn đề – Context/Problem Domain)
• (Whose) Vấn đề của ai? (Định nghĩa Đối tác – Stakeholders)
• (Why) Tại sao cần giải quyết? (Định nghĩa Mục tiêu đối tác – ‘stakeholders’ Goals)
• (How) Hệ thống phần mềm sẽ hỗ trợ như thế nào? (Thu thập Kịch bản – Scenarios)
• (When) Khi nào cần phải giải quyết ? (Định nghĩa các ràng buộc phát triển – Development Constraints)
• (What) Điều gì ngăn chặn việc giải quyết chúng? (Định nghĩa tính khả thi và độ rủi ro – Feasibility and Risk)

- Khảo sát về RE: Không cần theo tuần tự; RE xuyên suốt quá trình phần mềm; Có thể ko sát thực tế; Đặc tả ko mang lại lợi nhuận; Chỉ là dự kiến ko phải cố định.

- Yêu cầu là gì?: bao gồm:

• • Đặc tính lĩnh vực: Những thứ có thật
  • Các yêu cầu: Những thứ chúng ta muốn
  • Sự đặc tả: CT phải làm để đáp ứng yêu cầu

- Tiêu chuẩn: 

• Tiêu chuẩn chính xác:
  • Chương trình: thực hiện trên máy tính đáp ứng đặc tả
  • Đặc tả: các thuộc tính thỏa mãn các yêu cầu
• Tiêu chuẩn hoàn thiện:
  • Hiểu tất cả các yêu cầu quan trọng
  • Hiểu tất cả các thuộc tính liên quan

4. Phần mềm

- Vô hình, mơ hồ, trừu tượng

- Không có quy luật tự nhiên

- Không có ràng buộc tự nhiên

- Không mệt mỏi

- Thưc hiện cv lặp đi lặp lại

5. Quản lý dự án

- Nhà quản lý:

• 4 Kiểm soát
  • Tài nguyên (có thể tăng thêm tiền, tiện ích, nhân lực) 
  • Thời gian (có thể tăng thời gian, trì hoãn thời hạn, etc.) 
  • Sản phẩm (có thể giảm chức năng – e.g. các yêu cầu quá rắc rối) 
  • Rủi ro (có thể quyết định các rủi ro nào chấp nhận được)
• 4 Theo dõi
  • Công sức – Cần tốn công sức nhiều thế nào? Tiêu hao bao nhiêu? 
  • Thời gian – Lịch biểu được mong đợi ra sao? Còn bao lâu nữa ? 
  • Kích cỡ – Kế hoạch vấn đề lớn như thế nào? Phải thiết kế ra sao? 
  • Hạn chế – Đã tạo ra bao nhiêu lỗi ? Bao nhiêu lần phát hiện lỗi?

—> Khởi đầu, nhà quản lý phải đánh giá đúng –> Phân tích thấu đáo vấn đề

- Lý do khởi đầu tự án

• • Hướng vấn đề (Problem-driven): sự cạnh tranh, sự khủng hoảng,…
  • Hướng thay đổi (Change-driven): nhu cầu mới, sự lớn mạnh, thay đổi doanh nghiệp hoặc môi trường,…
  • Hướng cơ hội (Opportunity-driven): bùng nổ một kỹ thuật mới,…
  • Hướng kế thừa (Legacy-driven): một phần của kế hoạch trước đó, công việc chưa hoàn thành, …
  • Green field

- Các kiểu dự án

• Customer-specific – một khách hàng với vấn đề cụ thể :
• một công ty khác, 
•  
• một bộ phận trong cùng công ty
• Market-based – hệ thống bán ra thị trường : sản phẩm sinh ra khách hàng, Đội ngũ tiếp thị thay thế khách hàng
• Community-based – tiện ích cho cộng đồng : công cụ nguồn mở, các công cụ NCKH
• Hybrid (kết hợp những kiểu trên)

6. Mô hình phần mềm (5)

• Tuần tự: Waterfall, V model :
  • Quản trị cấp cao ở cấp độ lớn
  • Vấn đề: Cái nhìn tĩnh, thiếu biến đổi, thiếu người dùng liên quan, tách biệt ko thực tế, ko hỗ trợ bản mẫu, tái sử dụng…
• Lập bản mẫu nhanh (Rapid Prototyping) :
  • Hiểu yêu cầu giao diện, hướng thiết kế, khảo sát quy tắc hệ thống
  • Vấn đề: ng dùng xem bản mẫu là giải pháp, một đặc tả ko hoàn chỉnh
• Giai đoạn: Incremental, Evolutionary : Song song nhau, nhiều version.
• Vòng lặp: Xoắn ốc (Spiral)
• Linh hoạt (Agile Models): eXtreme Programming
  • Giảm rào cản truyền thông, tài liệu, niềm tin con người, đáp ứng khách hàng
  • Khó bảo trì, thiếu rõ ràng, ko đưa ra khác nhau, thiếu tầm nhìn xa

CHƯƠNG 2: QUY TRÌNH CÔNG NGHỆ YÊU CẦU (The Requirements Engineering)

- Quy trình : là một tập các hoạt động nhằm dẫn đến việc phát sinh định nghĩa và đặc tả yêu cầu.

- Quy trình Công nghệ yêu cầu dùng để khảo sát, phân tích và kiểm chứng tính hợp lệ của các yêu cầu hệ thống

1. Nghiên cứu khả thi

- Đánh giá sự đáp ứng cho yêu cầu phần cứng và phần mềm

- NCKT quyết định hệ thống có hiệu quả về kinh doanh và phù hợp với ngân sách hiện tại… Phải rẻ và nhanh chóng…

- Báo cáo khả thi: Quyết định + Bản báo cáo tính khả thi hệ thống + Tài liệu đặc tả người dùng

2. Thu thập và phân tích yêu cầu

- Quá trình: Khảo sát ht hiện tại, thảo luận người dùng, phân tích công việc

- Tiến trình:

• Hiểu phạm vi vấn đề (Domain understanding)
•  Thu thập yêu cầu (Requirements collection)
•  Phân loại (Classification)
•  Giải quyết mâu thuẫn (Conflict resolution)
•  Sắp ưu tiên (Prioritisation)
•  Kiểm tra yêu cầu (Requirements checking)

3. Kiểm chứng yêu cầu hợp lệ

- Xác định yêu cầu là hoạt động chuyển thông tin phát sinh trong suốt tiến trình phân tích thành tài liệu định nghĩa tập hợp các yêu cầu

- Phản ánh điều người dùng muốn

- Tài liệu viết cho người dùng cuối và khách hàng hệ thống

- Lỗi trong định nghĩa đc xem xét kĩ lưỡng

4. Quản trị yêu cầu

- Quản lý yêu cầu là tiến trình quản lý sự thay đổi của yêu cầu trong suốt quy trình công nghệ yêu cầu và phát triển hệ thống

- Vấn đề: Yêu cầu ko hoàn thiện và nhất quán ; yêu cầu mới phát sinh ; Quan điểm khác nhau làm mâu thuẫn ; Tài liệu thay đổi thường xuyên

CHƯƠNG 3: NGHIÊN CỨU KHẢ THI (Feasibility Study)

1. Tìm hiểu chung

- Mục tiêu: cung cấp cho nhà quản trị: dự án có thể ko + Sp cuối cùng + Cần thay đổi gì + Có thể hoàn thiện?

- Sau khi NCKT, nhà quản trị sẽ quyết định: tiếp tục hay ko? Cần xem xét chiến lược kinh doanh

2. Khảo sát hiện trạng

— PIECES : định nghĩ vấn đề cần giải quyêt và cấp bách

• Performance (Độ thực thi) – thời gian đáp ứng của hệ thống
• Information (Sự truyền thông) – I/O save, store
• Economy (Tính kinh tế) – lợi nhuận
• Control (Sự kiểm soát) – bảo mật, an toàn thông tin
• Efficiency (Tính hiệu quả) – nhanh/tiết kiệm
• Services (Các dịch vụ) – các chức năng

3. Khảo sát khả thi

• Kỹ thuật 
  • KT đc đề xuất hoặc giải pháp : có làm chủ KT và nhà chuyên môn?
  • KT mà chúng ta cần : Công nghệ tiên tiến, hoàn thiện và trải nghiệm
  • KT có sẵn ko?
• Kinh tế 
  • Lợi nhuận
    • Lợi nhuận Hữu hình: có thể số lượng hóa thành tiền tệ (Tăng doanh thu, giảm chi phí, giảm nhân công, tăng nhập liệu…)
    • Lợi nhuận Vô hình : Khó số lượng hóa nhưng có thể quan trọng hơn (tăng linh hoạt, tăng chất lượng, quan hệ khách hàng tốt, cải thiện tinh thần nhân viên…)
  • Chi phí
    • Chi phí Phát triển :
      • Chi phí phát triển/buôn bán (Đội ngũ, tư vấn, phần mềm, phần cứng, tiện ích)
      • Chi phí khởi tạo/chuyển đổi (Khởi tạo HT, huấn luyện nhân viên, chuyển đổi hồ sơ…)
    • Chi phí Vận hành :
      • Bảo trì hệ thống (Phần cứng/mềm, tiện ích)
      • Nhân sự (vận hành, nhập liệu, sao lưu, hỗ trợ bảo trì)
      • Chi phí huẩn luyện
• Lịch biểu
  •  Phải mất bao lâu để tinh thông kỹ thuật ?
  •  Đánh giá lịch biểu rủi ro kinh tế (Deadline)
  •  Điều gì là ràng buộc thực sự trên hạn cuối dự án?
• Vận hành
  • Bạn và nhà quản lý đánh giá các thay đổi khi áp dụng thực tiễn

4. Nội dung báo cáo khả thi

• 1. Mục đích và phạm vi nghiên cứu
  • Các mục tiêu (của nghiên cứu)
  • Ai được ủy quyền và ai thực hiện nó,
  • Các nguồn thông tin,
  • Các quy trình dùng cho việc nghiên cứu,
  • Tốn bao nhiêu thời gian,…
• 2. Mô tả hiện trạng
  • Môi trường tổ chức, các hệ thống hiện tại.
  • Những tác nhân và các ràng buộc liên quan.
• 3. Vấn đề và các yêu cầu
  • Cái gì là sai trong hiện trạng ?
  • Thay đổi gì thì cần thiết?
• 4. Các mục tiêu của hệ thống mới
  • Các mục tiêu cầu đạt và mối liên hệ giữa chúng.
• 5. Những thay đổi có thể bao gồm cả ‘không thực hiện gì’.
• 6. Tiêu chuẩn so sánh
  • Định nghĩa các tiêu chuẩn
• 7. Phân tích các thay đổi
  • Mô tả mỗi thay đổi
  • Đánh giá với các khía cạnh tiêu chuẩn
  • Phân tích chi phí/lợi nhuận và những gợi ý đặc biệt.
• 8. Kiến nghị
  • Kiến nghị điều gì và các gợi ý
  • Tiếp theo cần làm gì;
  • E.g. có thể đề nghị một giải pháp tạm thời và một giải pháp lâu dài
• 9. Phụ lục
  • Bao gồm mọi tài liệu hỗ trợ.

5. Tính toán

- Giá trị hiện tại (Present Value): Giá trị đồng ở “năm hiện tại” cho chi phí/lợi nhuận năm n trong tương lai đối với một tỷ lệ chiết khấu i

- Giá trị hiện tại thuần (Net Present Value): Đo lường tổng giá trị đầu tư với tất cả các con số được điều chỉnh bằng giá trị đồng ($) hiện tại

NPV = PV cộng dồn của tất cả lợi nhuận – PV cộng dồn của tất cả chi phí

- Điểm hòa vốn: Số năm sẽ hoàn lại chi phí Tích lũy (Lợi nhuận tích lũy/chu kì sống > Chi phí tích lũy)

- ROI (Return on Investment) : Lợi nhuận trên vốn đầu tư : Cho phép so sánh lợi nhuận suốt chu kỳ sống của một giải pháp lựa chọn. (Đo lường ROI là tỷ lệ giá trị của một sự đầu tư trên chi phí của nó.)

Hoặc:  ROI = Giá trị hiện tại thuần / Chi phí chu kỳ sống 

• Trong ví dụ trên:
  • ROI = (795,440 – 488,692) / 488,692 ≈ 63%,
  • hoặc ROI = 306,748 / 488,692 ≈ 63%

- Ví dụ:

- Tiêu chuẩn so sánh: Cột tương ứng với các giải pháp ứng viên; Dòng tương ứng với các tiêu chuẩn khả thi

CHƯƠNG 4: THU THẬP YÊU CẦU

• Ranh giới (Boundaries)  Phạm vi của vấn đề 
•  Các đối tác (Stackholders) Xác định những người làm chủ vấn đề 
•  Mục tiêu (Goals)  Định nghĩa các tiêu chuẩn thành công
•  Kịch bản (Scenarios) Sử dụng các ví dụ cụ thể để hiểu vấn đề

1. Làm rõ các yêu cầu

Định nghĩa được “vấn đề” :  Kỹ thuật W6H

• (Which) Vấn đề nào cần được giải quyết ? (Ranh giới – Boundaries)
• (Where) Vấn đề ở đâu ? (hiểu ngữ cảnh/ phạm vi vấn đề – Context/Problem Domain)
• (Whose) Vấn đề của ai? (Định nghĩa các Đối tác – Stakeholders)
• (Why) Tại sao cần giải quyết? (Định nghĩa Mục tiêu đối tác – ‘stakeholders’ Goals)
• (How) Hệ thống phần mềm sẽ hỗ trợ như thế nào? (Thu thập Kịch bản – Scenarios)
• (When) Khi nào cần phải giải quyết ? (Định nghĩa các ràng buộc phát triển – Development Constraints)
• (What) Điều gì ngăn chặn việc giải quyết chúng? (Định nghĩa tính khả thi và độ rủi ro - Feasibility and Risk)

2. Nguồn bổ sung yêu cầu – Volere

3. Các đối tác (Stackholders)

• • Người dùng (Users)
  • Nhà thiết kế (Designers)
  • Nhà phân tích hệ thống (Systems analysts)
  • Đội ngũ huấn luyện và hỗ trợ người dùng (Training and user support staff)
  • Nhà phân tích kinh doanh (Business analysts)
  • Các tác giả kỹ thuật (Technical authors)
  • Người quản lý dự án (The project manager)
  • ”Khách hàng” (“The customer”)

4. Tìm kiếm đối tác – Biểu đồ Org

5. Cấp độ phân quyền

• Quản trị cấp cao (top)
  • Thiết lập các mục tiêu
  • Lập kế hoạch trên phạm vi rộng
  • Xác định thị trường mới và sản phẩm cần phát triển
  • Quyết định đối tượng liên doanh và kết quả đạt được.
•  Quản trị trung gian (middle)
  • Sắp đặt các mục tiêu
  • Phân phối & kiểm soát tài nguyên
  • Thực hiện kế hoạch
  • Đo lường sự thực thi
•  Quản trị cấp thấp (lower)
  • Giám sát hoạt động hàng ngày
  • Điều chỉnh các hành động khi cần thiết.
•  Cấp vận hành
  • Thực hiện các hoạt động hàng ngày

6. Mô hình hóa mục tiêu

- Mục tiêu cố định (Hardgoals): Mô tả các chức năng cần phải thực hiện, hoàn toàn đạt đc. (Sự đáp ứng các mục tiêu, Việc thông tin các mục tiêu)

- Mục tiêu linh hoạt: Không thể thực sự đáp ứng một cách đầy đủ. E.g. Tính chính xác, Độ thực thi, Tính bảo mật, …

- Các tác nhân: Là chủ của các mục tiêu

7. Mô hình mục tiêu

• Một mục tiêu hỗ trợ đạt đến cái khác (+)
• Một mục tiêu làm hại sự đạt đến cái khác (-)
• Một mục tiêu phát sinh cái khác (++)
• Một mục tiêu ngăn chặn cái khác (–)

8. Kịch bản

-Mô tả hệ thống sẽ được dùng như thế nào trong thực tế, là dòng đặc tả giao tiếp giữa người thực hiện và hệ thống.
- Rất hữu ích cho việc thu thập yêu cầu vì con người có thể quan hệ dễ dàng hơn là các câu lệnh trừu tượng khi họ yêu cầu từ hệ thống
- Có khuynh hướng ngắn gọn
- Có thể là kịch bản động (yêu cầu có hành vi) hoặc tĩnh (không cần sự tương tác)
- Có thể trình diễn (mô tả hệ thống hiện tại) hoặc suy diễn (nó sẽ thực hiện thế nào)

•  Thuận lợi
  • Rất tự nhiên: các đối tác có khuynh hướng sử dụng chúng một cách tự động
  • Các kịch bản ngắn thì rất tốt cho việc minh họa các giao tiếp cụ thể
•  Bất lợi
  • Thiếu cấu trúc
  • Khó để kiểm tra tính hoàn thiện

CHƯƠNG 5: PHÂN TÍCH LÀM RÕ YÊU CẦU (Eliciting Requirements)

1. Khó khăn khi thu thập yêu cầu

- Kiến thức hẹp về lĩnh vực: Biểu mẫu không rõ ràng, phân tán, mẫu thuẫn…  (Nhân viên ở các Ngân hàng khác nhau có ý kiến khác nhau –> mâu thuẫn)

- Kiến thức ẩn ý: khó mô tả công việc bằng lời (luật cho vay ko được viết ra)

- Thiếu quan sát (Quan sát có thể khác với cách họ làm)

- Thiên bị (Bias) : người ta không nói điều mà mình cần biết

• Thiên  vị về tính thuyết phục
• Thiên vị về quan sát
• Thiên vị về nhận thức
• Thiên vị về ký pháp

2. Các kỹ thuật làm rõ yêu cầu

a) Kỹ thuật truyền thống

- Tự xem xét

- Đọc tài liệu cơ bản

- Phân tích “dữ liệu cứng”

- Phỏng vấn

• Không cấu trúc (câu hỏi mở)
• Cấu trúc (câu hỏi đóng) )

- Khảo sát / Lập bảng câu hỏi

- Hội thảo

b) Kỹ thuật hợp tác

- Tập trung nhóm

• Brainstorming
• Hội thảo JAD/RAD

- Lập bản mẫu
- Cùng thiết kế

c) Hướng ngữ cảnh (xã hội)

- Kỹthuật cộng đồng

• Tham gia quan sát
• Nhân chủng học

- Phân tích ngôn từ

• Phân tích cuộc đàm thoại
• Phân tích lời nói

- Phương pháp xã hội học

• Phân tích hệthống mềm

d) Kỹ thuật nhận thức

- Phân tích công việc
- Phân tích giao thức
- Các kỹthuật làm rõ tri thức

• Card Sorting
• Laddering
• Repertory Grids
• ProximityScalingTechniques

3. Đọc tài liệu cơ bản

- Nguồn: 

• Các báo cáo của công ty
• Sơ đồ tổ chức
• Tài liệu hướng dẫn giải pháp
• Quy trình nghiệp vụ
• Tài liệu hệ thống hiện hành…

- Thuận lợi:

• Hiểu về tổ chức đó trước khi làm việc với họ
• Chuẩn bị về nhiều mặt trước khi tìm hiểu
• Có yêu cầu  chi tiết về hệ thống hiện hành

- Bất lợi:

• Tài liệu không hoàn toàn phù hợp với thực tế
• Có thể dài dòng nhiều chi tiết không liên quan

- Trường hợp sử dụng: Khi không thân thiện với tổ chức sắp khảo sát

4. Phân tích dữ liệu “cứng” và lấy mẫu (Sampling)

- Nguồn: các thông tin chính xác

• Các biểu mẫu, Hóa đơn, Báo cáo tài chính,…
• Báo cáo được dùng để ra quyết định,…
• Kết quả thống kê, dữ liệu tiếp thị,…

- Lấy mẫu: chọn đại diện từ 1 tập phổ biến.

• Xác định mục đích, mẫu liên quan –> chọn ngẫu nhiên –> phân tầng & chọn mẫu trên mỗi tầng –> Chọn đại diện
• Kích thước mẫu: rất quan trọng, cần cân đối

- Tiến trình:

• Xác định thu thập dữ liệu gì – e.g. các giao dịch ngân hàng
• Xác định tập phô biến – e.g. tất cả các giao dịch ở 5 chi nhánh trong 1 tuần
• Chọn kiểu của mẫu – e.g. simple random sampling
• Chọn kích thước mẫu – e.g. cứ mỗi 20 giao dịch

5. Phỏng vấn

- Dạng (2) : cấu trúc và không cấu trúc

- Thuận lợi:

• Thu thập nhiều thông tin
• Tốt cho mục tiêu, quan điểm, cảm giác
• Thăm dò sâu hơn để hiểu rõ

- Bất lợi:

• Khó phân tích dữ liệu định tính
• Khó so sánh những người khác nhau
• Phỏng vấn là kỹ năng khó

- Lưu ý:

• Những câu hỏi không thể trả lời
• Kiến thức ẩn chứa ngầm
• Sự sai lệch từ ngữ cảnh
• Thái độ người phỏng vấn có thể tạo ra một số thiên vị

- Kinh nghiệm: 

• Bắt đầu thoải mái: câu hỏi xung quanh
• Chính sách ghi âm
• Hỏi câu hỏi dễ trước rồi đến điều cần quan tâm
• Câu hỏi bỏ ngỏ đặt ở cuối

6. Bảng câu hỏi

- Cần được lập mẫu và kiểm tra

- Thuận lợi: 

• Thu thập thông tin từ nhiều người một cách nhanh chóng
• Quản lý từ xa
• Thông tin quan điểm, niềm tin, tính cách…

- Bất lợi: 

• Không chuyển tải hết nội dung người dùng

- Lưu ý:

• Thành kiến việc chọn mẫu người, câu hỏi cá nhân…
• Mẫu nhỏ
• Câu hỏi mở khó phân tích, câu hỏi mơ hồ, câu hỏi chỉ đạo, câu hỏi riêng tư…

7. Hội thảo

-Mục đích:

• Dùng cho việc tổng kết và phản hồi:
• Gặp gỡ đối tác cuối mỗi giai đoạn để thảo luận, kết luận, thỏa thuận vấn đề
• Xác nhận điều khảo sát, thảo luận phương hướng

- Hội thảo là công cụ quản lý quan trọng

• Bác bỏ dự án đã thay đổi
• Làm sáng tỏ mục tiêu, giải quyết vấn đề, mâu thuẫn
• Cần lập kế hoạch kỹ lưỡng: thời gian, lịch biểu, báo cáo, quy luận, thảo luận…

8. Làm việc nhóm

- Dạng : Nhóm tập trung, Chiến lượt động não

- Thuận lợi:

• Giao tiếp tự nhiên giữa mọi người
• Đo lường phản ứng (mô hình, bảng truy vấn)

- Bất lợi

• Có thể nhóm không thân thiện
• Phát sinh ý kiến cá nhân
• Cung cấp giải pháp thiển cận
• Đòi hỏi kỹ năng huấn luyện cao

- Lưu ý:

• Có định kiến, sự áp đảo và phục tùng

9. Phát triển ứng dụng nhanh Join/Rapid

- Nguyên tắc JAD & RAD:

• Nhóm phải làm việc linh động (hội thảo)
• Phương tiện nghe nhìn: biểu đồ, máy chiếu, màn ảnh
• Tiến trình tổ chức: động não –> top-down
• Lập tài liệu sau mỗi cuộc họp

- Lưu ý: 

• Lựa chọn người kỹ lưỡng
• Thời gian 3-5 ngày
• Lãnh đạo chuẩn bị kỹ, cần thời gian quyết định
• Phòng đầy đủ phương tiện

10. Tham gia quan sát

- Hướng tiếp cận: dành thời gian quan sát vấn đề, tham gia lâu để trở thành thành viên, xem xét chiều dọc vấn đề

- Thuận lợi :

• Có kiến thức về môi trường làm việc
• Phát hiện được nhiều chi tiết

- Bất lợi :

• Rất tốn thời gian
• Quá nhiều kết quá khó phân tích
• Ko thể nói nhiều về sự thay đổi đầu ra

- Chú ý: Phải hòa nhập cộng đồng

11. Điều tra xã hội học

- Lập luận cơ sở: môi trường xã hội có trật tự. Cần xem xét ý nghĩa của phát triển và tiến hóa trong ngữ cảnh.

- Dùng phạm trù chủ thế: Thừa nhận các tập quán, tục lệ theo hướng cộng đồng

CHƯƠNG 6. MÔ HÌNH HÓA YÊU CẦU (Modelling)

1. Các định nghĩa

- 2 tiêu chí cho kiểm tra :

• Chương trình: thực hiện trên máy tính cụ thể đáp ứng đặc tả
• Đặc tả: thuộc tính lĩnh vực thỏa mãn yêu cầu

- 2 tiêu chí cho kiểm chứng :

• Xem xét và hiểu tất cả yêu cầu quan trọng?
• Xem xét và hiểu tất cả thuộc tĩnh lĩnh vực liên quan?

2. Mô hình hóa (MHH)

• - MHH có thể hướng suy luận : giúp đưa ra câu hỏi, làm rõ câu ẩn ý
• - MHH có thể cung cấp sự đo lường
• - MHH giúp phơi bày vấn đề : giải quyết mâu thuẫn, xung đột, nhầm lẫn thuật ngữ, phạm vi
• - MHH có thể kiểm tra sự thấy hiểu : Hiểu kết quả, giúp quan sát/kiểm chứng các yêu cầu

- PTYC gồm nhiều bước MHH

- “Mô hình hóa tốt hơn chỉ là sự mô tả” : có hiện tượng và quan hệ chủ thể với các hiện tượng (Vd: quan hệ Sách – Tác giả – Độc giả)

- Chú ý: 

• Hiện tượng trong mô hình thì không hiện diện trong lĩnh vực ứng dụng (Không có 2 người cùng tên cùng ngày sinh –> Ko thực tế)
• Hiện tượng trong lĩnh vực ứng dụng thì không có trong mô hình (Tác giả ma, bút danh, nặc danh… –> mô hình ko nắm bắt đc)

- Mô hình thường ko hoàn hảo, không nên tốn thời gian tìm kiếm sự hoàn hảo của mô hình

3. Chọn ký pháp cho việc MHH : có 3 loại

- Ngôn ngữ tự nhiên: Diễn cảm. linh hoạt nhưng khó nắm bắt các quan hệ

- Ký pháp bán hình thức : (UML) : Nắm cấu trúc và ngữ nghĩa, kiểm tra nhất quán, trực quan, chuyển thông tin nhanh chóng…

- Ký pháp hình thức : Ngữ nghĩa chính xác, có thể suy luận rộng (mô hình toán học) ; rất chi tiếp nhưng không chấp nhận việc MHH, khác với KHMT khác

4. Mục tiêu ký pháp MHH (8)

- Cài đặt độc lập : hiển thị dữ liệu, cách tổ chức bên trong
- Tính trừu tượng : Đưa ra các khía cạnh thiết yếu
- Tính hình thức : không mơ hồ, ngữ nghĩa biểu cảm
- Tính kiến trúc : thiết kế từng phần để kiểm soát độ phức tạp và kích thước, cần có sự giao tiếp dễ dàng
- Dễ phân tích : Cho phép phân tích dữ liệu mơ hồ, chưa đầy đủ và không nhất quán
- Dễ lần vết : Cho phép tham chiếu, liên kết với thiết kế cài đặt
- Tính khả thi : có thể cho mô hình hoạt động để so sánh nó với thực tế
- Tối thiểu hóa : Không dư thừa các khái niệm trong lược đồ

5. Phân loại (3)

- Mô hình hóa nghiệp vụ

• Mục đích & Mục tiêu (KAOS, CREWS)
• Kiến trúc tổ chức (i*, SSM, ISAC)
• Công việc & các phụ thuộc
• Tác nhân, vai trò, dự định

- Mô hình hóa thông tin & hành vi

• Cấu trúc thông tin
• Quan điểm hành vi (Kịch bản và tình huống ; Mô hình máy trạng thái ; Dòng thông tin)
• Các yêu cầu về thời gian/trình tự
• Ví dụ:

• • Mô hình hóa thông tin: E-R, Class Diagrams. 
  • Phân tích cấu trúc: SADT, SSADM, JSD
  • Phân tích hướng đối tượng: OOA, OOSE, OMT, UML
  • Các phương pháp hình thức: SCR, RSML, Z, Larch, VDM

- Mô hình hóa chất lượng hệ thống

• Những gì ‘có thể’: Có thể sử dụng, đáng tin cậy, có thể phát triển, an toàn, bảo mật, khả thi, tương tác,…
• Thỏa thuận chất lượng: QFD, win-win, AH
• Đặc tả NFRs: Timed Petri nets (mức độ thực thi) ; Task models (tính dễ sử dụng) ; Probabilistic MTTF (độ tin cậy)

6. Unified Modelling Language (UML)

• - Hướng đối tượng thế hệ thứ ba :
• Booch, Rumbaugh & Jacobson
• Hoàn toàn là ký pháp
• Đã trở thành một công nghệ chuẩn (IBM/Rational)

- Khung mô hình chuẩn (meta-model) :

• Use case diagrams
• Class diagrams
• Message sequence charts
• Activity diagrams
• State Diagrams
• Module Diagrams
• Platform diagrams

- Dễ dàng sửa đổi và tái sử dụng: Những nhà phân tích thường sử dụng lại các thành phần + cấu trúc (mô hình họ xây dựng trước đó) ; hoạch định cho tương lai
- Các ý niệm hữu ích:

• Trừu tượng hóa (Abstraction) : Tháo bỏ các chi tiết để tập trung vào những thứ quan trọng
• Phân tách (Partitioning) : Phân chia vấn đề thành các phần độc lập, để khảo sát riêng biệt
• Quy chiếu (Projection) : Phân chia các khía cạnh (views) khác nhau và mô tả chúng một cách riêng biệt
• Mô-đun hóa (Modularization) : Chọn lựa các cấu trúc ổn định theo thời gian để dễ định vị sự thay đổi
• Mẫu (Patterns) : Cấu trúc của một mô hình đã có xuất hiện trong nhiều ứng dụng khác nhau

7. Nguyên tắc MHH

- Nguyên tắc 1: Phân tách

• Nắm rõ được sự tập hợp/quan hệ
• Phân chia hệ thống thành các phần nhỏ
• Chú ý: đây không phải thiết kế, chỉ là sự phân tích vấn đề
• Cách chọn lựa của phân tách vấn đề sẽ có thể được phản ánh trong thiết kế

- Nguyên tắc 2: Trừu tượng hóa

• Là cách tìm kiếm sự tương tự giữa các khái niệm bằng việc lờ đi một số các chi tiết
• Tập trung vào mối quan hệ tổng quan/cụ thể giữa các hiện tượng
• Nhóm các thực thể
• Quan hệ kế thừa : tương tự giữa các lớp trong 1 quan hệ ‘(is_a)’

- Nguyên tắc 3: Quy chiếu

• Phân chia thành nhiều khía cạnh tương tự các phép chiếu trong xây dựng
• Vd: Phân chia mô hình về yêu cầu (độ an toàn ; khả năng chỉ huy ; khả năng chịu lỗi ; đúng thời gian và trình tự)

- Chú ý:

-  Quy chiếu và Phân tách thì tương tự nhau:

• • Phân tách định nghĩa một ‘phần’ của quan hệ
  • Quy chiếu định nghĩa một ‘khía cạnh’ của quan hệ

- Phân tách thừa nhận mỗi phần thì tương đối độc lập

-Ví dụ: patient

• Quan hệ kế thừa (trừu tượng) –> :in và :out
• Quan hệ tập hợp (phân chia) –> :heeart :eye :skin

8. Kết luận

- Mô hình hóa đóng vai trò trọng tâm trong RE

• Cho phép khảo sát vấn đề một cách hệ thống
• Cho phép kiểm tra sự hiểu biết

- Có nhiều lựa chọn ký pháp cho mô hình

• Chúng ta sẽ dùng các dạng ký pháp của UML 

- Tất cả các mô hình thường thiếu chính xác : hiệu chỉnh liên tục ; mục đích riêng không được biểu diễn trong mô hình –> cần có một sự giải thích

CHƯƠNG 7. MÔ HÌNH QUAN HỆ THỰC THỂ (Entity Relationship Modelling)

1. Khái niệm

- Lược đồ quan hệ thực thể: Mô tả yêu cầu dữ liệu cho một hệ thống. Dùng kí hiêu trực quan dễ hiểu. Trừu tượng hơn lược đồ quan hệ

- Thực thể: lớp các đối tượng cùng đặc điểm.

- Quan hệ: kết nối logic 2 hay nhiều thực thể

- Quan hệ đệ quy: thực thể có quan hệ với chính nó

- Quan hệ 3 (Ternary)

- Quan hệ AND/XOR

- Thuộc tính: các giá trị của thực thể

- Thuộc tính hợp thành: nhóm các thuộc tính có cùng tính chất. Ví dụ: Person(Name, Age, Sex, Address –> Street + HouseNo + PostCode)

2. Bản số

- Là số tối đa và tối thiểu của các thể hiện quan hệ mà thể hiện của thực thể tham gia vào. Cặp số nguyên không âm (a,b)

• a<=b
• a = 0 –> tham gia tùy ý
• a = 1 –> tham gia bắt buộc
• b = 1 –> mỗi thể hiện của thực thể liên kết với 1 thể hiện của quan hệ
• b = N –> mỗi thể hiện của thực thể liên kết tùy ý với thể hiện quan hệ

- Ví dụ ERM

- Các thuộc tính cũng có thể có bản số. Mặc định (1,1). Tùy chọn (0,1)

- Các bản số thuộc tính đa trị khó giải quyết –> thêm vào các liên kết  với quan hệ 1-N hoặc N-N

3. Khóa

- Khóa xác định : có thể đc tạo ra từ 1 hay nhiều thuộc tính

- Phân loại: 

- 1 khóa xác định có thể có 1 hoặc nhiều thuộc tính

- 1 khóa ngoại có thể có 1 hoặc nhiều thực thể

- Đa khóa: 1 thực thể có nhiều khóa xác định thì bản số tối thiểu bằng 0

4. Khái quát hóa

- Chỉ ra quan hệ “là-một” (is-a) giữa các thực thể.

• Mỗi thể hiện của thực thể con là thể hiện của thực thể cha
• Mỗi thuộc tính của thực thể cha là thuộc tính của thực thể con

- Phân loại (2) 

• Khái quát hóa hoàn toàn: thể hiện thực thể cha là 1 trong số các thực thể con. Ví dụ Person (Man or Woman). Mũi tên đậm
• Khái quát hóa loại trừ: cha có ít  nhất  thể hiện trong số con. Ví dụ People ( Nhân viên hoặc học sinh hoặc sinh viên …. ). Mũi tên rỗng.

CHƯƠNG 8. MÔ HÌNH HƯỚNG ĐỐI TƯỢNG (Objects)

1. Phân tích hướng đối tượng

- Mô hình hóa lĩnh vực ứng dụng

- Khi triển khai, thường thay đổi chức năng hơn là đối tượng –> ko ổn định

- Thiết kế hướng đối tượng giúp ổn định và được duy trì, nhấn mạng sự quan trọng giữa giao tiếp của các đối tượng.

2. UML (Unified Modeling Language)

- Công nghệ chuẩn cho việc mô hình hóa phần mềm hướng đối tượng

- Là kết quả của sự thống nhất hệ thống ký hiệu của 3 phương pháp hướng đối tượng tiêu biểu :

• OMT (James Rumbaugh) – Object Modeling Technique
• OOSE (Ivar Jacobson)- Object-Oriented Software Enginering
• Booch91 (Grady Booch)

- Được hỗ trợ bởi một số CASE tools: Rational ROSE + TogetherJ 

- Mô hình 80% của hầu hết vấn đề bằng cách dùng chỉ khoảng 20% UML
- Mọi thứ đều có thể mô hình hóa

3. Lớp

- Một lớp mô tả một nhóm các đối tượng (objects) với :

• Các đặc tính tương tự (thuộc tính – attributes), (name, ID, depart…)
• Cùng hành vi ứng xử (phương thức – operations), (hire, work, join…)
• Quan hệ như nhau đối với các object khác.
• Và có chung ngữ nghĩa (“semantics”).

- Loại bỏ lớp khi: 

• Không nằm trong phạm vi phân tích;
• Tham chiếu đến toàn bộ hệ thống;
• Trùng với các lớp khác;
• Có quá nhiều mơ hồ hoặc quá chi tiết

- Các thể hiện của 1 lớp gọi là đối tượng (khi có giá trị cụ thể)

- Hai đối tượng khác nhau có thể có các giá trị thuộc tính giống nhau (như hai người với tên và địa chỉ giống nhau)

4. Quan hệ kết hợp

- Đối tượng không tồn tại độc lập với những cái khác

- Các kiểu quan hệ trong UML:

• Quan hệ kết hợp (Association)
• Quan hệ tập hợp (Aggregation) và Quan hệ hợp thành (Composition)
• Quan hệ thừa kế(Generalization)
• Quan hệ phụ thuộc (Dependency)
• Quan hệ hiện thực hóa (Realization)

- Chú ý : Hai quan hệ cuối không hữu ích trong quá trình phân tích yêu cầu

- Biểu diễn bản số trong quan hệ kết hợp:

• Tùy chọn (0 hoặc 1)  —>  0..1
• Chính xác 1  —>  1 = 1..1
• 0 hoặc nhiều  —>   0..* = *
• 1 hoặc nhiều  —>   1..*
• Một vùng giá trị  —> 2..6

- Các lớp quan hệ kết hợp: đôi khi quan hệ kết hợp với một lớp với chính quan hệ

- Quan hệ tập hợp (Aggregation): Đây là một quan hệ “Có một (Has-a)” hay “Toàn thể/Bộ phận (Whole/part)”. Hình thoi màu trắng

- Quan hệ hợp thành (Composition): Là dạng mạnh hơn của quan hệ tập hợp dùng chứng tỏ quyền sở hữu: Hình thoi màu đen

•  nếu đối tượng toàn thể bị hủy, đối tượng bộ phận cũng bị hủy theo.
•  đối tượng toàn thể chịu trách nhiệm về sự sắp xếp các thành phần của nó.

- Quan hệ kế thừa :

• Lớp con kế thừa thuộc tính, quan hệ và phương thức từ lớp cha.
• Một lớp con có thể bỏ qua một khía cạnh kế thừa
• Các lớp cha có thể khai báo {abstract}, nghĩa là chúng không có thể hiện
• Lợi ích: Có thể dễ dàng thêm vào các lớp con mới khi có thay đổi tổ chức
• Tìm kiếm quan hệ kế thừa theo 2 cách:
  • Trên xuống (Top Down)
  • Dưới lên (Bottom Up)

5. Sơ đồ lớp

- Sơ đồ lớp thiết kế tốt khi:

• Có quan hệ trực quan giữa các đối tượng trong lĩnh vực
• Khảo sát các quy tắc nghiệp vụ và giả thiết thông qua bản số
• Đặc tả cấu trúc của thông tin để (cuối cùng) lưu trữ

6. Kết luận

- Hướng đối tượng OO là một cách thức tốt để khảo sát các chi tiết của vấn đề

- Trong RE, sơ đồ lớp KHÔNG phản ánh các lớp chương trình

- UML là bản phát họa chứ ko phải bản thiết kế (có thể thành thiết kế khi được dùng trong đặc tả)

- Sơ đồ ER tương tự như sơ đồ lớp trong UML 

• UML nhấn mạnh thứ bậc lớp và các phương thức
• ER nhấn mạnh các mối quan hệ và khóa xác định

- ER cung cấp nhiều ký hiệu hơn cho khái niệm cơ sở dữ liệu:

• ER cho phép các quan hệ đa chiều
  • UML chỉ cho phép quan hệ 2 chiều
• ER cho phép các thuộc tính đa giá trị.
• ER cho phép đặc tả các khóa xác định.

- Sự lựa chọn tùy thuộc vào mục tiêu cài đặt:

• UML cho kiến trúc hướng đối tượng
• ER cho CSDL quan hệ

CHƯƠNG 9. MÔ HÌNH HÓA TƯƠNG TÁC HỆ THỐNG (Interactions)

1. Use case

- Dùng để chỉ :

• Các chức năng hệ thống
• Tác nhân dùng những chức năng này

- Mỗi Use Case là:

• Một mẫu ứng xử được yêu cầu biểu diễn
• Một trình tự các hành động có liên quan thực thi bởi một tác nhân thông qua đối thoại

- Tác nhân : tương tác với hệ thống, có thẻ là con người, vai trò, hệ thống khác

- Ranh giới hệ thống : như một cái hộp chứa các use case có liên quan, tác nhân nằm bên ngoài ranh giới

- Đường kết nối : nối tác nhân và use cáe

- Quan hệ:

• <<extends>> : thêm hành vi ứng xử
• <<uses>> : use case khác gọi đến, như thủ tục

Ví dụ: (Thường chỉ có 1 extend và nhiều users)

2. Quan hệ kế thừa

- Lớp tác nhân : các tác nhân cũng một lớp, các tác nhân kế thừa use case từ lớp

- Lớp use case : định nghĩa quan hệ kế thừa của một số use cáe

- QHKT đọc là : “là một thành viên của” hoặc “là một”

3. Tác nhân

- Nhận biết: hỏi câu hỏi

• Ai là người dùng chính
• Ai bảo trì, quản lý, điều hành…
• Quản lý phần cứng nào
• Tương tac với hệ thống khác nào

- 3 loại tác nhân chính

• Người dùng (sinh viên, nhân viên, khách hàng… )
• Hệthống khác.
• Sự kiện thời gian (Kết thúc tháng, đến hạn…)

4. Tài liệu use case

- Gồm luồng  sự kiện, mô tả cái hệ thống cần phải làm

- Các nội dung đặc trưng:

• Use case bắt đầu và kết thúc như thế nào;
• Tiến trình bình thường của các sự kiện;
• Tiến trình thay phiên của các sự kiện;
• Tiến trình ngoại lệ của các sự kiện;

- Kiểu tài liệu: Chọn lựa cách hiển thị use case:

• Biểu đồ hoạt động (Activity Diagrams) – tốt cho tiến trình công việc
• Biểu đồ hợp tác (Collaboration Diagrams) – tốt cho thiết kế cấp cao
• Biểu đồ trình tự (Sequence Diagrams) – tốt cho thiết kế chi tiết

- Ví dụ luồng sự kiện ATM

- Biểu đồ trình tự: từng bước trong một use case

CHƯƠNG 10. YÊU CẦU PHI CHỨC NĂNG (Non-Functional Requirements (NFRs))

1. Yêu cầu phi chức năng

• Là các hệ số chất lượng, tiêu chuẩn thiết kế; các độ đo
• Là các ràng buộc toàn thể

- Các cách tiếp cận:

• Tiếp cận hướng sản phẩm: chất lượng và tiêu chuẩn (Sự tin cậy)
• Tiếp cận hướng tiến trình : các yêu cầu phi chức năng
  • Tiếp cận định lượng : thang đo chất lượng, tính toán mức độ
  • Tiếp cận định tính : quan hệ mục tiêu chất lượng, sự thỏa hiệp

- Khó khăn:

• Khó mô hình
• Trạng thái ko hình thức
• Khó tạo ra tiêu chuẩn đo lường

- Ví dụ :

• Yêu cầu giao diện : “thân thiện”
• Yêu cầu thực thi :
  • Giới hạn về thời gian / không gian. “hệ thống phải kiểm soát 1000 giao dịch trên giây”
  • Độ tin cậy : nguyên vẹn thông tin dùng duy trì hệ thống, có thời gian bảo trì
  • Tính bảo mật : thông tin lưu hành, hoặc phân quyền
  • Khả năng chịu lỗi : tồn tại khi có sự cố tự nhiên
• Yêu cầu vận hành : Các ràng buộc vật lý, Dễ bảo trì, Điều kiện về môi trường
• Yêu cầu chu trình sống :
  • “Future-proofing” :  bảo trì, mở rộng, khả chuyển, vòng đời sản phẩm
  • Những giới hạn phát triển : giới hạn thời gian phát triển, Tài nguyên sẵn dùng, Các chuẩn về phương pháp
• Yêu cầu kinh tế : đúng thời gian, vốn dài hạn

2. Các dạng biểu đồ trong UML

3. Mô hình không thuộc UML

-  Mô hình mục tiêu

• Nắm bắt các mục tiêu chiến lược của các đối tác
• Tốt cho việc khảo sát các câu hỏi ‘how’ và ‘why’ với các đối tác
• Tốt để phân tích các thỏa hiệp trade-offs, đặc biệt trên các chọn lựa thiết kế

- Mô hình Cây bắt lỗi (Fault Tree Models) - như một ví dụ trong kỹ thuật phân tích rủi ro

• Nắm bắt các lỗi tiềm ẩn của một hệthống và nguồn gốc nguyên nhân
• Tốt cho phân tích rủi ro, đặc biệt trong những ứng dụng với tiêu chuẩn an toàn

- Mô hình chiến lược phụ thuộc (Strategic Dependency Models (i*))

• Nắm bắt quan hệ giữa các tác nhân trong một tổchức
• Hữu ích cho quan hệ giữa mục tiêu đối tác với tổ chức thiết lập chúng
• Tốt cho việc thấu hiểu tổ chức sẽ thay đổi như thế nào

- Mô hình quan hệ – thực thể

• Nắm bắt quan hệ về cấu trúc thông tin được lưu trữ
• Tốt cho việc hiểu các ràng buộc và những giả thiết về phạm vi chủthể
• Lập nền tảng tốt cho thiết kế CSDL

- Các kiểu bảng lớp, bảng sự kiện và bảng điều kiện

• Nắm bắt hành vi động của một hệ thống phản ứng trong thực tế
• Tốt cho việc biểu diễn chức năng kết hợp từ inputs đến outputs
• Tốt cho việc tạo các mô hình hành vi chính xác, như suy diễn tự động

4. Yếu tố và tiêu chuẩn

- Yếu tố chất lượng liên quan đến quan hệ khách hàng (hiệu năng, tính toàn vẹn, độtin cậy, tính chính xác, khảnăng chịu lỗi, sựtiện dụng,..)

- Tiêu chuẩn thiết kế liên quan tới kỹ thuật (quản lý các bất thường, tính hoàn thiện, tính ổn định, khảnăng lưu vết, tính trực quan,..)

- Yếu tố chất lượng và tiêu chuẩn thiết kế có liên quan với nhau

• Tính chính xác phụ thuộc vào tính hoàn thiện, tính ổn định, khả năng lưu vết,…
• Tính khả thi phụ thuộc vào sự mô-đun hóa, tính linh động và tính đơn giản

- Trong quá trình phân tích:

• Xác định quan hệ quan trọng của mỗi yếu tố chất lượng từ quan điểm của khách hàng
• Xác định tiêu chuẩn thiết kế
• Thiết lập độ đo lường các yêu cầu

5. Boehm’s NFR list

6. McCall’s NFR list

7. Thiết lập độ đo

- Các yếu tố chất lượng –> Tiêu chuẩn đo lường –> Đếm số lần từ kết quả hiển thị

8. Đo độ tin cậy

- Định nghĩa : Khả năng của hệ thống hành xử một cách thống nhất theo phương cách người dùng có  thể chấp nhận được khi hệ thống vận hành bên trong môi trường mà nó dự định thực hiện

- Các chú thích :

• Được xác dịnh dưới dạng phần trăm
• Ví dụ: Phần mềm sẽ có không nhiều hơn X lỗi trên 1000 dòng mã lệnh

- Công thức : Ước lượng số lỗi = (nhân lỗi * lỗi phát hiện) / nhân lỗi được phát hiện

CHƯƠNG 11. ĐẶC TẢ YÊU CẦU (Requirements Specifications)

1. Đặc tảyêu cầu phần mềm

- SRS (Software Requirement Specification)

- Mục tiêu SRS :

•  Chuyển tải thông tin
• Lập hợp đồng
• Cơ sở cho việc đánh giá phần mềm
• Cơ sở cho việc quản lý thay đổi

- Người dùng SRS :

• Khách hàng & Người dùng
• Nhà phân tích (yêu cầu) hệthống
• Người phát triển, Lập trình viênKiểm thửviên
• Quản lý dựán

- Biến dạng, 1 ‘SRS’ có thể được viết bởi :

• Nhà thầu (the procurer)
• Người đấu thầu (the bidders)
• Nhà phát triển được tuyển chọn
• hoặc bởi một người thầu RE độc lập

- Chọn lựa trên quan điểm nào để hoàn thành hợp đồng

• Sớm (giai đoạn khái niệm) : chỉ có thể đánh giá các nhà đấu thầu trên năng lực và khả năng biểu lộ
• Trễ (giai đoạn đặc tảchi tiết) : nhiều công việc hơn cho nhà thầu; các kỹ năng RE phù hợp có thể không có sẵn
• Chuẩn IEEE đề nghị SRS nên được cùng xây dựng bởi nhà thầu và người phát triển

2. Các đặc tính của một SRS

• Hợp lệ (hoặc “đúng”) : Diễn tả được nhu cầu thực sự của  các đối tác
• Không mơ hồ : Mỗi câu chỉ có thể đọc chính xác theo một cách
• Hoàn chỉnh : tất cả mọi thứ đều phải được hoàn thiện
• Dễ hiểu : không chuyên môn cũng hiểu đc
• Nhất quán : Không có mâu thuẫn trong thuật ngữ
• Có thứ bậc : Chỉ rõ các quan hệ
• Dễ kiểm tra : kiểm thử sự thỏa mãn yêu cầu
• Dễ sửa lỗi : cấu trúc tốt và tham khảo chéo
• Dễ lần vết : Nguồn gốc rõ ràng, gán nhãn cho tham khảo sau này dễ

–> Không có SRS nào là hoàn chỉnh!

3. Dùng kí pháp

- Ngôn ngữ tự nhiên hoặc bảng quyết định (T/F)

• Phát sinh trong chức năng then chốt?
• Xuất hiện trong quy trình then chốt?
• Không có lỗi nào tìm ra nguyên nhân?

4. Nội dung SRS cần chú trọng

• Chức năng hóa.
• Yêu cầu thực thi.
• Các thuộc tính chất lượng.
• Các ràng buộc thiết kếphải tuân theo trong quá trình cài đặt.

- Không cần bao gồm :

• Kế hoạch phát triển dự án (chi phí, đội ngũ, lịch biểu, phương pháp), đảm bảo chất lượng (cấu hình, kiểm thử), các thiết kế…

5. Các lỗi điển hình

6. Chuẩn IEEE cho SRS

7. Chuẩn IEEE STD Mục 3

• - Yêu cầu giao diện bên ngoài
  • Giao diện người dùng
  • Giao diện phần cứng
  • Giao diện phần mềm
  • Giao diện truyền thông tin
• - Các yêu cầu chức năng
• - Các yêu cầu thực thi
• - Các ràng buộc thiết kế
• - Các đặc tính của hệthống phần mềm
  • Độ tin cậy
  • Tính sẵn dùng
  • Tính bảo mật
  • Khả năng bảo trì
  • Tính khảchuyển
• Các yêu cầu khác

8.Kết luận

- Đặc tả yêu cầu nhằm một số mục đích:

• Chuyển tải thông tin
• Lập hợp đồng
• Làm cơ sở cho việc kiểm tra
• Làm cơ sở cho việc quản lý các thay đổi

- Đặc tả yêu cầu có một số dạng người dùng:

• Có chuyên môn và không chuyên môn

- Đặc tả tốt thì rất khó viết

CHƯƠNG 12. KIỂM TRA VÀ KIỂM CHỨNG (Verification and Validation)

1. Khái niệm

- Kiểm chứng (Verification) :

• Xây dựng đúng hệ thống?
• Khai báo đã nắm bắt vấn đề thực tế?
• Có đáp ứng nhu cầu các đối tác?

–> Dựng hoạt cảnh ; các thay đổi hình thức ; WHAT IF ; khảo sát trạng thái

- Kiểm tra (Vadidation) :

• Xây dựng hệ thống đúng?
• Thiết lập, cài đặt đặt tả
• Hệ thống thực hiện điều nó làm
• Yêu cầu thống nhất với hệ thống khác?

–> Có định dạng chuẩn ? ; Các thành phần có thống nhất ?

2. Khái niệm: Tiêu chuẩnV&V

- Sự khác biệt:

• DomainProperties: luôn luôn đúng
• Requirements: mong là đúng trong lĩnh vực ứng dụng
• Specification: chương trình cần thực hiện để đáp ứng với các yêu cầu

- Hai tiêu chuẩn kiểm tra (verification)

• (Program) thực hiện trên một (Computer) cụ thể đáp ứng với đặc tả (Specification)
• (Specification) được cho trong thuộc tính của lĩnh vực (Domain properties) thỏa mãn các yêu cầu (Requirements)

- Hai tiêu chuẩn kiểm chứng (validation)

• Xem xét (và hiểu) tất cả các (Requirements) quan trọng?
• _____ thuộc tính lĩnh vực(Domain properties) liên quan.

3. Chu trinh dieu tra

- Kiến thức có trước –> (Quan sát –> Mô hinh –> Thiết kế –> Can thiệp)

- Chu trình điều tra nhanh: Kiến thức có trước –> (Quan sát –> Mô hình (Phân tích mô hình  –> Kiểm tra đặc tính) / (Lập bản mẫu –> Cho người dùng thử))

4. Lap ban mau (Prototyping)

- Một bản mẫu phần mềm là kiến trúc được cài đặt cụ thể trước để khách hàng, người dùng, nhà phát triển có thể hiểu rõ hơn về vấn đề hay giải pháp

- Lập bản mẫu là tiến trình xây dựng mô hình làm việc của hệ thống

- Huong tiep can lap ban mau:

• Bản mẫu trinh dien :  chứng minh khái niệm; giải thích đặc tính, minh họa và thông báo – sau đó bỏ đi
• Bản mẫu tham do : xác định vấn đề, thu thập, làm rõ mục tiêu, so sánh, Không hình thức, không cấu trúc và cũng được bỏ đi.
• Bản mẫu thu nghiem : đặc tính kỹ thuật; kiểm tra sự thích hợp, không bao gồm người dùng/khách hàng
• Bản mẫu tien trien (“bản mẫu vận hành”, “hệ thống lái máy bay”) : tiến trình tiếp diễn sẽ tương thích với hệ thống, “Bản mẫu như một phân phối sớm, để tiếp tục cải tiến.

- Bản mẫu dung thu:

• Mục đích : nghiên cứu nhiều hơn về vấn đề, bỏ đi cái ko mong muốn
• Cách dùng : sớm hoặc trễ
• Hướng tiếp cận : Chiều ngang, 1 tầng – Quick and dirty
• Thuận lợi : Hội tụ sớm, phân phối+kiểm thử+chi phí thấp, thành công
• Bất lợi : Lãng phí nếu yêu cầu thay đổi ; yêu cầu khách hàng cao ; có thể phát triển thành sp cuối

- Ban mau tien hoa:

• Mục đích : nghiên cứu nhiều hơn, giảm rui ro
• Cách dùng : phát triển dần, làm tiến hóa
• Hướng tiếp cận : theo chiều dọc, từng phần, mở rộng/thích ứng
• Thuận lợi : Yêu cầu ko nhất thiết cố định, linh động, trả phiên bản sau cùng nếu có lỗi
• Bất lợi : hệ thống phức tạp, khó bảo trì, kiến trúc kém, ko tối ưu, thiếu kiểm soát…

5. Các định nghĩa khác

- “Management reviews” : preliminary design review (PDR), critical design review (CDR), …;   sự chắc chắn thiết kế ; nhà quản trị và các nhà bảo trợ (khách hàng) ; “dog-and-pony show”
- “Walkthroughs” : Kỹ thuật của người phát triển (thường không hình thức) ; cải tiến chất lượng sản phẩm ; tìm kiếm khuyết điểm
- “(Fagan) Inspections” : quản lý tiến trình (luôn hình thức); cải tiến chất lượng ; Thu thập dữ liệu lỗi để ; Viết output ; Đóng vai trò chính

6. Lợi ích của kiểm duyệt hình thứ

- Đối với lập trình ứng dụng:

• Hiệu quả hơn kiểm thử
• Reviewed chính xác lần đầu tiên
• So sánh: 10-50 lần thử kiểm tra/gặp lỗi

- Dữ liệu từ các dự án lớn

• Giảm lỗi bởi một nguyên nhân : 5
• Cải thiện hiệu quả: 14% đến 25%
• Phần trăm lỗi đươc phát hiện bởi kiểm duyệt: 58% đến 82%
• Giảm chi phí 50%-80% cho V&V

- Hiệu quả trên thu nhập của nhân viên:

• Tăng tinh thần, giảm thay đổi nhân sự
• Lập lịch biểu và đánh giá tốt hơn
• Quản lý tốt năng lực nhân viên

7. Các vai trò (Roles)

- Lãnh đạo Review :

• Chủ trì cuộc họp
• Bảo đảm các sự chuẩn bị
• Giữ sự tập trung review
• Báo cáo kết quả

 - Người ghi chép : Giữ vết của các kết quả công bố

- Reader : Tổng kết các mẫu sản phẩm
- Tác giả : Người tham dự một cách tích cực
- Các Reviewers khác :  tìm và viết ra báo cáo

- Người điều tiết (Moderator) :

• Phải là một lập trình viên thành thạo
• Cần được huấn luyện đặc biệt
• Có thể đến từ dự án khác

- Người thiết kế : Các lập trình viên – người phát sinh thiết kế
- Người viết code/cài đặt : Các lập trình viên có trách nhiệm
- Người kiểm thử : viết/thực thi các tình huống kiểm thử

8 . Lập cấu trúc sự kiểm duyệt

- Checklist : các câu hỏi kiểm tra/vấn đề ; review được cấu trúc trong danh sách
- Walkthough : có mặt trong từng bước kiểm tra ; review cấu trúc sản phẩm
- Round Robin : reviewer nêu ra vấn đề ; review được cấu trúc bởi đội review
- Tốc độ Review : 3 phút xem xét lại 1 vấn đề –> chuyển người kế tiếp ; Tốt đánh giá khả năng

9. V&V độc lập

- V&V được thực hiện bởi một nhà thầu riêng

• Để đáp ứng : cần một quan điểm kỹ thuật độc lập.
• Chi phí 5% – 15% chi phí phát triển
• Các khảo sát tăng gấp 5 lần lợi nhuận trên vốn đầu tư:
  • Lỗi phát hiện sớm, rẻ hơn để sửa, rẻ hơn để thửlại
  • Đặc tả rõ hơn
  • Các nhà phát triển thích dùng các thực nghiệm tốt hơn.

- 3 kiểu của sự độc lập:

• Độc lập quản lý:
  • Phân chia trách nhiệm
  • Khi nào và ở đâu cần tập trung V&V
• Độc lập tài chánh:
  • Phân chia chi phí và nguồn tài chính
  • Không mạo hiểm phân phối nguồn tài nguyên
• Độc lập kỹ thuật:
  • Tổ chưc nhân sự riêng biệt
  • Dùng những công cụ và kỹ thuật khác nhau

10. Kết luận

• Kiểm chứng : bạn đã giải quyết đúng vấn đề.
  • Prototyping – cho phản hồi của khách hàng sớm
  • Inspection – các chuyên gia lĩnh vực đọc đặc tả một cách kỹ lưỡng
  • Formal Analysis – phân tích toán học các mô hình

• Kiểm tra (Verification) các bước trong công nghệ là đúng
  • Kiểm tra tính nhất quán – các mô hình có thống nhất?
  • Khả năng lưu vết –thiết kế/viết mã lệnh/kiểm thử đúng các yêu cầu?

• Sử dụng V&V thích hợp :
  • Lấy thông tin khách hàng sớm nếu chỉ là phác thảo.
  • Phân tích và kiểm tra tính nhất quán nếu là bản đặc tả
  • V&V độc lập nếu hệ thống cần an toàn nghiêm ngặt.

CHƯƠNG 13. SẮP XẾP YÊU CẦU ƯU TIÊN (Requirements Prioritizatino)

- Tại sao phải sắp xếp thứ tự ưu tiên yêu cầu

—> Cần cân bằng các yêu khác nhau để đạt được sự kết hợp tốt nhất

1. Cơ sở của sự ưu tiên

- Cái gì cần được chọn để cài đặt

• Khách hàng (thường) hỏi quá nhiều về cách thức
• Cân đối giữa thời gian tiếp thị với tổng số các chức năng
• Quyết định đặc tính nào sẽ được phát hành kế tiếp

- Đối với yêu cầu/đặc tính cần hỏi : tính quan trọng, chi phí, rủi ro…

- Thực thi khẩn cấp : Yêu cầu bắt buộc/loại bỏ/hợp lý

2. Ước lượng chi phí và giá trị

- 2 cách tiếp cận:

Định mức tuyệt đối (giá trị đồng $$$) : phải có kinh nghiệm chuyên môn

Các giá trị liên quan (ít, rất, một chút…) : làm rõ hơn, sắp thứ tự ưu tiên

- Quá trình so sánh/chọn lựa

• Cơ sở sắp xếp : n*(n-1)/2 bước
• Dựng cây thứ tự nhị phân O(nlogn) bước
• Dựng cây phủ tối tiểu n-1 bước

3. Một vài rắc rối

• - Khó xác định mức độ chênh lệch
• - Không phải mọi yêu cầu đều so sánh đc
• - Các yêu cầu có thể ko độc lập
• - Đối tác có thể ko kiên định
• - Các đối tác không đồng nhất

4. Đánh giá chi phí Analytic Hierarchy Process (AHP)

5. Cơ sở giải quyết mâu thuẫn

- Đàm phán : thăm dò sự cộng tác

- Cạnh tranh : không quan tâm đến độ hài lòng.

- Giải pháp thứ 3 : các thành viên được hỗ trợ từ bên ngoài