Mục Lục
CÂU HỎI ÔN TẬP MÔN HOC IT4460 PHÂN TÍCH CÁC YÊU CẦU PHẦN MỀM
1.1 Các quan điểm khác nhau trong định nghĩa về yêu cầu phần mềm. Định nghĩa chuẩn theo IEEE.
Trả lời:
Các quan điểm khác nhau trong định nghĩa về yêu cầu phần mềmü Alan Davis (1993) : Các nhu cầu của người sử dụng (Các đặc tính, chức năng và đặc điểm) của hệ thống cần phải thể hiện từ các quan sát bên ngoài vào hệ thống.
ü Jones(1994) : Các yêu cầu và phát biểu của người sử dụng khởi sự quá trình phát triển phần mềm.
ü Somemervile và Sawyer(1997): Yêu cầu của người sử dụng là các đặc tả mô tả cần phải làm cái gì. Các đặc tả này giải thích các thuộc tính các đặc trưng của hệ thống và các hoạt động chức năng của hệ thống.
Định nghĩa chuẩn theo IEEEü (1) Điều kiện hay khả năng cần thiết để người sử dụng giải quyết được vấn đề hoặc mục tiêu hay đối tượng của họ.
ü (2) Điều kiện hay khả năng được hiểu là đáp ứng của hệ thống hay thành phần hệ thống thỏa mãn hợp đồng, tiêu chuẩn, đặc tả hoặc các văn bản bắt buộc khác.
ü (3) Văn bản thể hiện các điều kiện hoặc khả năng đã thể hiện ở (1) và (2)
1.2 Hãy nêu bản chất của yêu cầu phần mềm
Trả lời:
Bản chất của yêu cầu phần mềm là mâu thuẫn.
Sự mâu thuẫn thể hiện ở ý niệm về yêu cầu phần mềm xuất phát từ khách hàng và từ người sử dụng.
· Các yêu cầu phần mềm xuất phát từ người sử dụng đối với người phát triển phần mềm thông thường quá trừu tượng, ở mức cao.
· Ngược lại yêu cầu phần mềm được mô tả từ người phát triển đối với người sử dụng lại ở mức quá thấp, quá chi tiết cho nên người sử dụng không thể hiểu hết được.
1.3 Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng
Trả lời:
Định nghĩa IEEE về yêu cầu phần mềm từ phía khách hàng:
· Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để giải quyết một vấn đề hoặc để giải quyết một mục tiêu. (1)
1.4 Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần mềm
Trả lời:
Thói quen tốt:
· Luôn hỏi lại người dùng những gì mình chưa hiểu hết về yêu cầu của họ.
· Không chỉ khảo sát yêu cầu với một loại người sử dụng, mà phải bao quát tất cả những người sử dụng.
· Đánh dấu những điểm chưa rõ trong đặc tả: Đôi khi chúng ta thiếu một số thông tin về các yêu cầu phần mềm, chúng ta cần thảo luận với người sử dụng để hiểu chi tiết hơn. Tất cả những chỗ như vậy đc đánh đấu là TBD( Tobe determined). à Tất cả TBD này phải đc giải quyết trước khi bắt đầu quá trình phân tích và xây dựng phần mềm.
Thói quen không tốt:
· Tự mình nghĩ ra những yêu cầu của người dùng, hay tự cho mình là người dùng phần mềm.
· Người sử dụng là chuyên viên trong lĩnh vực nào đó nên có thói quen nghĩ là tất cả các phân tích viên đề là các chuyên gia trong lĩnh vực đó à Đưa ra các yêu cầu ngắn gọn mà ko miêu tả kỹ lưỡng hơn chúng là gì.
1.5 Nêu các thuộc tính chất lượng của yêu cầu phần mềm. Quan hệ giữa các thuộc tính chất lượng.
Trả lời:
Các thuộc tính chất lượng của yêu cầu phần mềm:
Đối với người sử dụngü Đáp ứng
ü Hiệu quả
ü Mềm dẻo
ü Bảo mật
ü Khả năng kết hợp với hệ thống
ü Tin cậy
ü Khả năng kiểm soát các dữ liệu không chính xác
ü Dễ sử dụng
Đối với nhà phát triểnü Bảo dưỡng
ü Hiệu quả
ü Mềm dẻo
ü Bảo mật
Các yêu cầu này có liên hệ với nhau. Khi muốn tăng thuộc tính nào thì phải giảm bớt thuộc tính khác đi. Chính vì vậy cần cân bằng các thuộc tính chất lượng
1.6 Nêu các phương pháp phân loại yêu cầu phần mềm. Phân tích đặc điểm của từng phân loại (note)
Trả lời:
Chúng ta có thể phân loại yêu cầu phần mềm theo các mặt đánh giá như:
a) Phân loại theo yêu cầu chức năng và phi chức năng.
- Các yêu cầu chức năng mô tả những chức năng mà phần mềm sẽ thực hiện. Ví dụ như căn lề văn bản hay thu tín hiệu.
- Các yêu cầu phi chức năng là các yêu cầu đưa ra các ràng buộc của giải pháp thực hiện. Có thể gọi yêu cầu phi chức năng là các yêu cầu về tính ràng buộc và về chất lượng phần mềm.
b) Phân loại các yêu cầu phần mềm theo nguồn gốc từ một hay nhiều yêu cầu ở cấp cao hơn hoặc các thuộc tính nổi bật (emergent property), hoặc độ chịu ảnh hưởng của phần mềm bởi người đại diện sử dụng (stake holder) hoặc một số nguồn khác:
- Định nghĩa về emergent property: Có một số yêu cầu phần mềm sẽ có các emergent property. Đó là các yêu cầu không thể xác định cho một thành phần đơn lẻ, mà còn tùy thuộc vào tính tương thích khi tích hợp các thành phần trong hệ thống. Ví dụ như yêu cầu của một trung tâm gọi điện thoại (tổng đài) sẽ phụ thuộc vào sự kết hợp của hệ thống telephone, hệ thống thông tin và các điều kiện khác. Các emergent property đặc biệt phụ thuộc vào kiến trúc hệ thống.
c) Phân loại theo các yêu cầu đặt ra cho sản phẩm hoặc là trên từng tiến trình. Các yêu cầu trên các quá trình phát triển khác nhau sẽ có thể đưa ra những ràng buộc bởi lựa chọn của những người tài trợ (contractor), hoặc là những chuẩn được đặt ra.
d) Phân loại theo độ ưu tiên phần mềm: Thông thường, các yêu cầu có độ ưu tiên cao hơn là những yêu cầu quan trọng hơn. Độ ưu tiên được xây dựng dựa trên một số yếu tố như sự ủy nhiệm, độ mong muốn, hoặc tính có hay không bắt buộc.
e) Phân theo phạm vi yêu cầu phần mềm: Phạm vi yêu cầu phần mềm được đánh giá dựa vào độ ảnh hưởng của yêu cầu lên phần mềm và các thành phần của phần mềm.
f) Phân loại theo độ dễ biến động/ tính ổn định (volatility/ stability): Một số yêu cầu phần mềm sẽ thay đổi trong vòng đời của phần mềm, và thậm chí ngay cả trong quá trình phát triển của yêu cầu phần mềm. Chúng ta có thể phân loại các yêu cầu bằng cách thông kê những thay đổi mà yêu cầu có thể phát sinh.
Ngoài ra, còn một số cách phân loại khác có thể chính xác hơn trong một số trường hợp, dựa trên kinh nghiệm thực tế của tổ chức phát triển phần mềm và bản thân các ứng dụng.
Tài liệu: Guide to the Software Engineering Body of Knowledges – 2004 trang số 39/202. Chú ý là cái chữ nâu ví dụ về emergent property chỉ là chú thích thêm cho dễ hiểu, các bạn có thể bỏ qua khi trả lời
1.7 Mô tả Quy trình công nghệ học yêu cầu phần mềm (Requirement Engineering Process)
Trả lời:
Quy trình công nghệ học phần mềm được chia thành 2 giai đoạn: Phát triển yêu cầu và Quản lý yêu cầu. Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn: Phát hiện yêu cầu, Phân tích yêu cầu, Đặc tả yêu cầu và kiểm thử yêu cầu.
 |
| HÌNH 1-2. Phân cấp công nghệ học yêu cầu. |
- Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn:
Phát hiện yêu cầu
Phân tích yêu cầu
Đặc tả yêu cầu
Kiểm thử yêu cầu.
- Quản lý yêu cầu được hiểu là :”thiết lập và duy trì một thoả thuận với khách hàng về các yêu cầu của dự án phần mềm” (CMU/SEI 1995). Quản lý yêu cầu gồm các bước sau.
Xác định giới hạn yêu cầu phần mềm. (Requirement basel
Duyệt các giới hạn của phần mềm.
Quản lý các thay đổi yêu cầu phần mềm.
Quy trình phát triển được thể hiện trên hình vẽ sau:
 |
| HÌNH 1-3. Biên phân chia giữa phát triển yêu cầu và quản lý yêu cầu. |
Mô tả quy trình như sau:
Maketing Customer Managerment lấy yêu cầu từ khách hàng, sau đó các yêu cầu đó được tổng hợp lại, phân tích, thỏa thuận với khách hàng, rà soát lại ( Đây là quá trình phát triển yêu cầu ). Kết quả của quá trình phát triển yêu cầu là bản Basel
Phiên bản cơ sở 1.0 được gửi cho khách hàng, bộ phận MCM lại tiếp tục đàn phán với khách hàng trên cơ sở phiên bản này, những yêu cầu thay đổi được tổng hợp, xử lý cập nhập lại Baseline Requirements.
Với mỗi thay đổi cập nhập lại gồm : thay đổi cái gì, ai là người thay đổi, thay đổi ảnh hưởng như thế nào đến hệ thống, đề phòng ra sao. Tất cả các thông tin trên được chuẩn hóa thành phiên bản 1.1.
Bây giờ phiên bản 1.1 được lấy làm cơ sở. Quy trình cứ tiếp tục cho đến khi có sự thống nhất từ khách hàng và đội phát triển.
1.8 Nêu vai trò của từng tác nhân trong yêu cầu phần mềm. Ảnh hưởng của các tác nhân đến các thuộc tính chất lượng yêu cầu phần mềm.
Trả lời:
Vai trò của từng tác nhân trong yêu cầu phần mềmTác nhân trong yêu cầu phần mềm gồm Người sử dụng và Người phát triển.
- Người sử dụng:
ü Cung cấp yêu cầu công việc(Business Requirement): thể hiện các mục tiêu yêu cầu ở mức cao của tổ chức hay khách hàng về khả năng, phạm vi ứng dụng và giới hạn của phần mềm; cung cấp các thông tin về từng nhiệm vụ cụ thể mà họ sẽ làm việc với phần mềm
ü Yêu cầu người sử dụng (user requirement): thể hiện các nhiệm vụ cụ thể mà NSD cần phải hoàn thành, làm được với phần mềm.
ü Thương lượng,thỏa thận với người phát triển các yêu cầu phần mềm.
- Người phát triển:
ü Phát hiện các yêu cầu
ü Phân tích các yêu cầu
ü Đặc tả các yêu cầu
ü Kiểm thử các yêu cầu
Ảnh hưởng của các tác nhân đến các thuộc tính chất lượng yêu cầu phần mềm:- Người sử dụng: có ảnh hưởng tớithuộc tínhchất lượng yêu cầu phần mềm thể hiện ở việc:
ü Đưa những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình phát triển phần mềm như viết code …
ü Đưa ra những yêu cầu và đề nghị rất khó chấp nhận và gây khó khăn cho các PTV
ü Các yêu cầu phần mềm mơ hồ nhập nhằng
Theo đánh giá của các nhà phân tích: làm lại yêu cầu phần mềm thường chiếm khaỏng 40% quá trình xây dựng nó và 70, 80% các đặc tính xây dựng lại có thể dẫn đến các lỗi
ü NSD đưa ra những yêu cầu quá ngắn gọn mà không miêu tả kỹ lưỡng hơn chúng là gì
- Người phát triển:có ảnh hưởng tớithuộc tínhchất lượng yêu cầu phần mềm thể hiện ở việc:
ü Phân tích được các vấn đề
ü Hiểu biết về nhu cầu sử dụng
ü Hiểu được hệ thống
ü Hiểu phạm vi quản trị
ü Tinh chỉnh các tính năng hệ thống
1.9 Nêu các phương pháp để phát hiện yêu cầu phần mềm và nguồn gốc yêu cầu phần mềm
Trả lời:
1. Các phương pháp xác định yêu cầu phần mềm
· Kĩ thuật phỏng vấn
· Kĩ thuật hội thảo
· Kĩ thuật BrainStorming
· Kĩ thuật storyBoarding
· Kĩ thuật thuật Use Case
· Kĩ thuật Protopyting
2. Nguồn gốc yêu cầu phần mềm
Bản chất của yêu cầu phần mềm là mâu thuẫn.
Sự mâu thuẫn thể hiện ở ý niệm về yêu cầu phần mềm xuất phát từ khách hàng và từ người sử dụng.
· Các yêu cầu phần mềm xuất phát từ người sử dụng đối với người phát triển phần mềm thông thường quá trừu tượng, ở mức cao.
· Ngược lại yêu cầu phần mềm được mô tả từ người phát triển đối với người sử dụng lại ở mức quá thấp, quá chi tiết cho nên người sử dụng không thể hiểu hết được.
Vì sự mâu thuẫn đó nên IEEE 1997 đã đưa ra một định nghĩa yêu cầu phần mềm nhìn từ góc độ người sử dụng và người phát triển, và những yêu cầu đó cần được đúc kết thành một văn bản để thống nhất giữa 2 bên.
Định nghĩa IEEE:
· Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để giải quyết một vấn đề hoặc để giải quyết một mục tiêu. (1)
· Điều kện hay khả năng cần phải thỏa mãn hoặc cần có của 1 hệ thống hoặc 1 thành phần hệ thống nhằm đáp ứng 1 hợp đồng, 1 tiêu chuẩn hoặc 1 đặc tả của một tài liệu khác.(2)
Văn bản thể hiện các điều kiện khả năng được thể hiện ở (1) và (2).
1.10 So sánh đánh giá các kỹ thuật phát hiện yêu cầu phần mềm
Trả lời:
6 kỹ thuật phát hiện yêu cầu phần mềm
ü Phỏng vấn
ü Tổ chức hội thảo
ü Brainstorming và Idea Reduction
ü Storyboarding
ü Áp dụng các Use-case
ü Prototyping
| | Phỏng vấn | Hội thảo | Brainstorming | Storyboarding | Use case | Prototyping |
| Đối tượng tham gia | Khách hàng, người phỏng vấn | Những bên liên quan | Những bên liên quan | Người sử dụng, người phân tích | Kĩ sư | Người phát triển, khách hàng |
| Loại yêu cầu | Tất cả | Tất cả | Tập trung vào một yêu cầu | Tất cả | Tất cả | Tất cả |
| Nội dung chuẩn bị | Chuẩn bị câu hỏi phỏng vấn | Chuẩn bị tài liệu họp | Đánh giá ý tưởng | Chuẩn bị hình ảnh, bản phác thảo và kết quả cuối | Mô hình Use case | Chuẩn bị mẫu thử, bản beta |
| Đánh giá phương pháp | Trực tiếp và đơn giản | Trực tiếp, quá trình chuẩn bị công phu | Trực tiếp, là một phần trong tổ chức hội thảo | Trực tiếp, các số liệu, hình ảnh đưa ra phải chính xác | Gián tiếp, cần có use case chính xác, là phương pháp luận chính xác nhất | Trực tiếp, qua mẫu thử |
1.11 Trình bày các yêu cầu khi xác định nhiệm vụ và phạm vi của phần mềm
Trả lời:
Trong phát triển phần mềm, có nhiều yếu tố cấu thành phạm vi của dự án. Phạm vi dự án là một hàm của:
· Chức năng cần có để đáp ứng nhu cầu người dùng.
· Tài nguyên sẵn sàng cho dự án.
· Thời gian cần có để có thể thực hiện dự án.
Phạm vi dự án.
v Tài nguyên, trước hết bao gồm lao động từ developers, testers, tech writers, nhân viên đảm bảo chất lượng...
Nếu thời gian đủ dài, kết quả công việc có thể được tăng lên, nhưng nó không tăng tỷ lệ với tài nguyên đầu tư thêm. Hiệu quả tổng thể của dự án vì thế mà sẽ bị giảm sút. Thêm tài nguyên thậm chí có thể làm chậm dự án bởi vì cần phải đào tạo và hỗ trợ cho nhân sự mới, vì thế sẽ làm giảm năng suất của dự án.
Nhằm mục đích phân tích phạm vi, ta coi tài nguyên là không đổi trong suốt dự án.
v Thời gian, có thể thay đổi nếu như tài nguyên sẵn có không đủ để hoàn thành các chức năng mong muốn. Để phân tích phạm vi, ta coi như thời gian là yếu tố cố định.
v Chức năng tổng thể bị giới hạn bởi thời gian (cố định) và tài nguyên (cũng cố định), vì thế phạm vi khả thi chính là hình chữ nhật màu trắng.
Nếu hiệu năng đòi hỏi phải bổ sung đặc tính của hệ thống bằng với tài nguyên trên thời gian sẵn có thì dự án có phạm vi khả thi.
Thông thường trong công nghiệp, các dự án đều là dự án vượt phạm vi.
1.12 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Phỏng vấn (interview)
Trả lời:
Đặt ra các câu hỏi về bản chất của các vấn đề người dùng. Để giải quyết vấn đề này, cần sử dụng các câu hỏi:
- Người sử dụng là ai?
- Khách hàng là ai?
- Nhu cầu của họ có khác nhau không?
- Trong trường hợp nào thì có thể tìm thấy giải pháp cho vấn đề này?
Nội dung của cuộc phỏng vấn có thể được thực hiện theo mẫu như sau:
- Thiết lập tiểu sử người dùng hay khách hàng.
- Đi vào vấn đề
- Tìm hiểu về môi trường người dùng
- Tóm tắt lại những gì thu được.
- Phân tích đầu vào trên các vấn đề của khách hàng.
- Đi vào giải pháp của mình (nếu thích hợp).
- Đi vào cơ hội.
- Đi vào sự đáng tin cậy, hiệu quả và các nhu cầu hỗ trợ.
- Những yêu cầu khác
- Bao quát lại
- Tổng kết phân tích.
Những điểm cần lưu ý khi tiến hành phỏng vấn:
- Chuẩn bị trước nội dung cần phỏng vấn. Xem lại các câu hỏi trước khi tiến hành phỏng vấn.
- Trước cuộc phỏng vấn nên tìm hiểu về nền tảng của các bên liên quan và công ty được phỏng vấn.
- Ghi lại những câu trả lời trong quá trình phỏng vấn (Không cố gắng lấy ra thông tin trong lúc này).
- Tham khảo mẫu trong quá trình phỏng vấn để đảm bảo đặt ra những câu hỏi đúng đắn.
1.13 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Hội thảo
Trả lời
1. Quy trình thực hiện
- Chuẩn bị Hội thảo
- Quảng bá nội dung
- Đảm bảo các bên liên quan sẽ tham dự.
- Chuẩn bị hậu cần tốt.
- Khởi động vật chất (warm-up materials): gửi material ra trước hội thảo để chuẩn bị tham dự và cũng để tăng hiệu quả của cuộc hội thảo. Có 2 loại warm-up materials:
- Thông tin cụ thể về dự án. Trong đó có thể bao gồm bản phác thảo của các tài liệu yêu cầu, liệt kê những tính năng được đề nghị, bản sao các cuộc phỏng vấn với những người dùng tiềm năng, báo cáo phân tích về xu hướng, thư từ khách hàng, báo cáo lỗi về hệ thống hiện hành, chỉ thị quản lý mới, dữ liệu marketing mới….
- Chuẩn bị cách suy nghĩ vượt ra khỏi giới hạn.
- Chuẩn bị vai trò cho facilitator (vai trò như người dẫn chương trình hay người chủ tọa):
o Đó là người bên ngoài, có kinh nghiệm.xử lý về quản lý yêu cầu hoặc.
o Là một thành viên trong nhóm và đã đạt được những thành tựu nhất định.
ü Đã từng qua đào tạo
ü Chứng minh được kỹ năng xây dựng sự đồng lòng hay xây dựng nhóm vững chắc.
ü Là người được cả các thành viên trong nhóm và ngoài nhóm tôn trọng.
ü Có đủ vững vàng đối mặt với những thách thức trong hội thảo.
- Lên lịch trình Hội thảo
- Chạy chương trình
o Các vấn đề và phương pháp thương mại
o Brainstorming
o Sự trình bày và những việc tiếp theo: sau Hội thảo, facilitator ghi lại các kết quả thu được. Sau đó, facilitator kết thúc nhiệm vụ của mình và chuyển sang cho nhóm phát triển.
2. Đặc điểm
- Hội thảo yêu cầu có lẽ là kỹ thuật mạnh mẽ nhất để gợi ra các yêu cầu
- Nó tập hợp các bên liên quan lại với nhau trong thời gian ngắn nhưng tập trung cao độ
- Việc sử dụng một người điều khiển bên ngoài có kinh nghiệm trong quản lý yêu cầu có thể đảm bảo sự thành công của hội thảo.
- Brainstorming là phần quan trọng nhất của một hội thảo.
3. Kỹ thuật
- Phần quan trọng nhất của một cuộc hội thảo là quá trình brainstorming. Kỹ thuật này thật sự thích hợp trong thiết lập các hội thảo. Nó khuyến khích tính sáng tạo và bầu không khí tích cực từ tất cả các bên liên quan.
1.14 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Brainstorming
Trả lời
Brainstorming gồm có 2 pha:
- Nêu ra các ý tưởng: Mục đích là đưa ra được càng nhiều ý tưởng càng tốt, mục đích mới là bề rộng, chưa cần có chiều sâu.
- Thâu tóm lại ý tưởng: Phân tích các ý tưởng được đưa ra, chọn lọc, tổ chức, đánh giá, mở rộng theo chiều sâu, tinh chỉnh ... chúng lại thành ý tưởng thích hợp.
Kỹ thuật này có những lợi ích chính sau:
· Khuyến khích được mọi thành viên tham gia.
· Cho phép các thành viên tranh luận với nhau về các ý kiến đề xuất.
· Người điều phối hoặc thư ký duy trì cuộc hội thảo không bị gián đoạn.
· Diễn ra nhanh chóng.
· Đưa ra các giải pháp khả thi cho vấn đề.
· Khuyến khích các ý tưởng, suy nghĩ sáng tạo, độc đáo.
Quy định:
ü Không được phép tranh cãi, phê bình gay gắt.
ü Tự do sáng tạo, tưởng tượng.
ü Đưa ra càng nhiều ý tưởng càng tốt
ü Nghiên cứu tổng hợp lại ý tưởng hay.
1.15 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Storyboarding
Trả lời:
Có 3 loại Storyboarding:
ü Bị động: Gồm các bản phác thảo, những hình ảnh, slide ... Người phân tích đảm nhiệm vai trò hệ thống và hiểu rõ về người sử dụng thông qua storyboard.
ü Chủ động: Làm người sử dụng thấy được kết quả cho dù nó chưa được hoàn thành.
ü Tương tác: Tạo cho người dùng kinh nghiệm về hệ thống. Các thành viên đóng vai trò như người sử dụng.
Những chú ý:
ü Không nên đầu tư quá nhiều vào Storyboarding
ü Storyboard nên dễ chỉnh sửa.
ü Không nên làm quá chi tiết. Điều đó sẽ gây khó khăn khi sử dụng các kỹ thuật hoặc công cụ khác nhau khi cài đặt sau này.
ü Cố gắng làm cho storyboard liên hệ với nhau, tương tác được với nhau.
1.16 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Áp dụng Usecase
Trả lời:
Use Case là một phương pháp luận trong ngôn ngữ mô hình hóa UML. Đó là một phương pháp luận khá hoàn chỉnh cho việc phát triển phần mềm hướng đối tượng. Use case được mô tả qua biểu đồ Use-case.
Use case mô tả tương tác giữa người dùng với hệ, nó cho biết các actor (Các tác nhân) , các chức năng của hệ thống. Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía hệ thống (tức là Use case). Các tác nhân và các Use case được mô hình hóa cùng các mối quan hệ và được miêu tả trong biểu đồ Use case của UML. Mỗi một Use case được mô tả trong tài liệu, và nó sẽ đặc tả các yêu cầu của khách hàng.
Xây dựng mô hình Use-case:
- Bước đầu tiên của quá trình mô hình hóa Use-Case là định nghĩa hệ thống(Xác định phạm vi của hệ thống – Hình chữ nhật liền nét) : Vì hệ thống là một thành phần của mô hình Use Case nên ranh giới của hệ thống mà ta muốn phát triển cần phải được định nghĩa rõ ràng. Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải bao giờ cũng là việc dễ dàng, bởi không phải bao giờ người ta cũng rõ ràng nhìn ra tác vụ nào có khả năng được tự động hóa tốt nhất ở hệ thống này và tác vụ nào thì tốt nhất nên thực hiện thủ công hoặc dành cho các hệ thống khác. Một khía cạnh khác cần chú ý là hệ thống cần phải lớn tới mức độ nào trong phiên bản đầu tiên của nó. Cố gắng tối đa cho phiên bản đầu tiên của hệ thống thường là cách mà người ta hay thực hiện, thế nhưng những mục tiêu quá tầm như vậy có thể khiến cho hệ thống trở nên quá lớn và thời gian để cung cấp hệ thống quá lâu.
- Tìm ra các tác nhân(Actor) và các use-case
o Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống. Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn nói rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các thông tin cùng với hệ thống. Nói một cách ngắn gọn, tác nhân thực hiện các Use Case. Thêm một điều nữa, một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví dụ như là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một loại trang thiết bị phần cứng nào đó tương tác với hệ thống).
o Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận được. Một Use Case trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể. Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống.
- Mô tả các Use-case
- Định nghĩa mối quan hệ giữa các Use-case
- Kiểm tra và phê chuẩn mô hình.
Ví dụ:
1.17 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Prototyping
Trả lời:
Prototyping là phương pháp xác định yêu cầu phần mềm bằng cách đưa ra các mẫu thử. Người phát triển sẽ dựa vào các yêu cầu khảo sát để đưa ra 1 sản phẩm ban đầu phác thảo có thể bằng công nghệ khác với công nghệ sẽ được sử dụng. Sau đó có sự trao đổi với người sử dụng, từ đó tìm ra các yêu cầu một cách cụ thể, rõ ràng hơn, đặc biệt là các yêu cầu có tính “mờ”. Việc tạo mẫu thử có thể được sử dụng nhiều lần ở nhiều phần và giai đoạn khác nhau. Các mẫu thử được tạo ra có thể có khả năng tái sử dụng, các mẫu thử sau sẽ phát triển liên tiếp nên nền các mẫu thử trước.(Mô hình tiến hóa)
Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm như là sự thực thi riêng lẻ của hệ thống, nhằm mục đích giúp đỡ người phát triển, người sử dụng và khách hàng hiểu cặn kẽ hơn về yêu cầu của hệ thống.
Với mục đích phân tích yêu cầu ta có thể chon xây dựng các mẫu thử : throwaway, horizontal, user interface. (Nếu muốn nói cụ thể từng loại mọi người đọc sách Managing Requirement Software chương 13 nhe)
Để xây dựng các mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát các yêu cầu của hệ thống, tiến hành trao đổi đàm phán với khách hàng. Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử. Dựa vào các yêu cầu đã khảo sát tạo bản mẫu rồi tro đổi với người sử dụng, với khách hàng, để phát hiện cụ thể hơn các yêu cầu đặc biệt các yêu cầu có tính “mờ”. Tiến hành phát triển theo mẫu thử đã được phê duyệt, sau bước đó tiếp tục tạo các mẫu thử có thể sử dụng các mẫu thử đã có từ trước.
1.18 Nêu các phương pháp phân nhóm yêu cầu phần mềm. Mục đích của phân nhóm. Đánh giá kết quả phân nhóm.
Trả lời:
??????
1.19 Nêu các phương pháp mô hình hóa các yêu cầu phần mềm. Trong BTL (Về Website của các Trường/Viện) nhóm đã áp dụng phương pháp nào.
Trả lời:
- Dữ liệu và kiểm soát luồng (data and control Flows)
- Các mô hình trạng thái (state models)
- Dò vết sự kiện (Event tracing)
- Tương tác với người dùng (user interaction)
- Các mô hình đối tượng (object models)
- Các mô hình dữ liệu (data models)
- Mô hình hóa use case
- Mô hình hóa nghiệp vụ
- Mô hình hóa dữ liệu
Nhóm em đã áp dụng phương pháp:
- Mô hình hóa use case
- Mô hình hóa nghiệp vụ
- Mô hình hóa dữ liệu
1.20 Trình bày các bước (quy trình) Phân tích các yêu cầu phần mềm
Trả lời:
- Phân loại các yêu cầu phần mềm:
Các yêu cầu chức năng thể hiện hệ thống hoạt động như thế nào, các hành vi của hệ thống. Những yêu cầu này thường là hướng hoạt động, hoạt động của người dùng.
Các yêu cầu phi chức năng: tính sử dụng được, độ tin cậy, hiệu năng, khả năng hỗ trợ…
Các giới hạn về thiết kế: phụ thuộc hệ thống khác, pháp luật, …
- Mô hình hóa khái niệm:
Mục đích của nó là để hỗ trợ việc hiểu rõ vấn đề, thêm vào đó là bắt đầu thiết kế giải pháp. Mô hình hóa khái niệm kết hợp các mô hình của thực thể để phản ánh mối quan hệ và sự phụ thuộc giữa chúng.
Một số loại mô hình có thể được phát triển: dữ liệu và kiểm soát luồng, mô hình trạng thái, dấu vết sự kiện, tương tác người dùng, mô hình đối tượng, mô hình dữ liệu …
Một số loại mô hình có thể được phát triển. Các yếu tố ảnh hưởng đến việc lựa chọn mô hình
bao gồm:
- Bản chất của vấn đề, một số loại yêu cầu phần mềm cần được phân tích đặc biệt
- Chuyên môn của các kỹ sư. Thường các kỹ sư hay áp dụng các mô hình mà họ có kinh nghiệm
- Yêu cầu về phương pháp của khách hàng
- Khả năng đáp ứng của phương pháp và công cụ
- Thiết kế kiến trúc và phân bố yêu cầu
- Thiết kế kiến trúc là giai đoạn mà tại đó các yêu cầu trùng lặp với thiết kế phần mềm hay hệ thống, minh họa khả năng không thể tách rời của hai nhiệm vụ này.
- Phân bổ là rất quan trọng cho phép phân tích chi tiết các yêu cầu. Do đó, một tập các yêu cầu được chia thành các nhóm.Trong một dự án lớn, phân chia các yêu cầu thúc đẩy việc phân tích các yêu cầu ở mức sâu hơn.
- Thiết kế kiến trúc được xác định chặt chẽ với mô hình hóa khái niệm. Mô hình hóa khái niệm và thiết kế kiến trúc đều áp dụng cùng các ký hiệu và các phương pháp.
- Chuẩn IEEE 2000 cho mô tả kiến trúc phần mềm.
- Đàm phán các yêu cầu
- “giải quyết xung đột”: khi các bên liên quan cung cấp các chức năng không tương thích, hay giữa yêu cầu và khả năng không phù hợp, hoặc giữa các yêu cầu chức năng và yêu cầu phi chức năng.
- Trong hầu hết mọi trường hợp, kỹ sư phần mềm không nên đưa ra một quyết định đơn phương mà nên tham khảo ý kiến với các bên liên quan, để đạt được một sự đồng thuận về một sự thỏa hiệp hợp lý. Người dùng là nhân tố quan trọng để đưa ra quyết định cuối cùng.
1.21 Nêu các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm
Trả lời:
1. Mã giả (Pseudocode)
2. Biểu đồ use case
3. Máy trạng thái hữu hạn (Finite state machines)
4. Cây quyết định (Decision trees)
5. Cây quyết định dạng đồ thị (Graphic decision trees)
6. Biểu đồ hoạt động (Activity diagrams (flowcharts))
7. Mô hình thực thể liên kết (Entity relationship models)
8. Phân tích hướng đối tượng (Object-oriented analysis)
9. Phân tính cấu trúc (Structured analysis)
10. Biểu đồ luồng dữ liệu (Data flow Diagrams)
1.22 Trình bày kỹ thuật thương lượng và thỏa thuận yêu cầu phần mềm. Đánh giá quan hệ giữa các tiêu chí "chất lượng", "thời gian thực hiện" trong thương lượng.
Trả lời:
Một thuật ngữ khác được sử dụng cho chủ đề này là “ conflict resolution” . Điều quan tâm này giải quyết vẫn đề với các yêu cầu mà sự xung đột xảy ra giữa hai yêu cầu của các bên liên quan cùng các tính năng không tương thích , giữa các yêu cầu và nguồn lực hoặc giữa yêu cầu chức năng và yêu cầu phi chức năng.
Trong tất cả các trường hợp , nó không thận trọng cho các kĩ sư phần mềm làm các quyết định đơn phương và do đó nó cần thiết tham khảo từ các bên liên quan để đạt được một sự đồng thuận trên sự thỏa hiệp thích hợp.
Sử dụng Use Cases
ü Để hỗ trợ các hoạt động thiết kế và mã hóa, các Use Case phát triển trong các hoạt động suy luận hơn là xây dựng đầy đủ.
ü Các Use Cases thích hợp nhất khi hệ thống giàu chức năng và phải hỗ trợ các loại người dùng khác nhau.
ü Các Use Case không có hiệu quả khi áp dụng đến hệ thống với một vài hoặc không có giao diện người dùng tối thiểu, chủ yếu là những yêu cầu phi chức năng và những hạn chế khi thiết kế.
Phần đánh giá thì có thể chém thêm
1.23 Các chức năng của EA hỗ trợ trong phân tích các yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL
Trả lời:
Sử dụng cửa sổ Hierachy. Khi lựa chọn 1 Requirement, ta sẽ xem được các thông tin về:
Quan hệ phân cấp của Requirement: cho biết nó là con của các Requirement nào, cha của các Reqiurement nào, quan hệ thuộc loại nào (sở hữu hay kết tập) … Quan hệ về cài đặt của Requirement: nó được cài đạt bởi các Element nào. Nếu Requirement có các Requirement con, EA có thể chi tiết việc cài đặt của từng Requirement con đó.Sử dụng ma trận quan hệ (Relationship Matrix): thông qua cửa sổ Relationship Matrix. Cho biết quan hệ giữa các đối tượng trong 2 package
Sử dụng cửa sổ Audit View: ghi chép lại các thay đổi đã thực hiện.
Kích hoạt Audit View:
Mở cửa sổ Audit View Chọn Audit Settings Enable AuditingSử dụng menu Project | Documentation
Lập các báo cáo đặc tả thông thường : thông tin về Requirement và các Requirement con tương ứng. Có nhiều định dạng văn bản khác nhau như: Rich Text Format, HTML,… Báo cáo quan hệ cài đặt Báo cáo quan hệ phụ thuộc ….1.24 Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm
Trả lời
ü Gán nhãn các yêu cầu phần mềm
ü Đánh dấu những điểm chưa rõ ràng trong đặc tả
ü Mối liên quan giữa đặc tả và giao diện người sử dụng
ü Không phụ thuộc vào các yêu cầu được tìm được ra hay xây dựng như thế nào
ü Trong đặc tả phải nêu được cả business requirement , phạm vi ứng dụng , giới hạn của ứng dụng.
ü Trong đặc tả phải nêu được đầy đủ các user requirement, sử dụng mẫu (template) của các trường hợp sử dụng của từng yêu cầu.
ü Thỏa mãn các tiêu thức đánh giá một đặc tả: tính nhất quán, tính thân thiện, tính dễ sử dụng.
1.25 Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm
Trả lời:
Khái niệm:
Là hiểu biết hệ thống của khách hàng vào thời điểm thiết kế và phát triển phần mềm. Đó là hợp đồng đảm bảo về cả khách hàng và sự hiểu biết hệ thống,các nhu cầu khác trước khi ấn định thời điểm.
- Các tiêu chí để đánh giá 1 đặc tả: tính nhất quán, tính thân thiện và tính dễ sử dụng.
- Trong đặc tả yêu cầu phần mềm phải nêu được cả yêu cầu thương mại, phạm vi ứng dụng, giới hạn của ứng dụng.
- Trong đặc tả phải nêu đầy đủ được các yêu cầu người sử dụng, sử dụng các mẫu(template) của các trường hợp sử dụng của từng yêu cầu [n1]
Thành phần :
· Ghi lại các nguyên tắc công việc.
Khi người sử dụng miêu tả cho chúng ta một hoạt động nào đấy chỉ được thực hiện trong những điều kiện nhất định, do những tác nhân nhất định..tức là chúng ta đã có 1 nguyên tắc công việc.
· Đặc tả các yêu cầu phần mềm theo mẫu.
Là đặc tả chức năng hệ thống, sự thỏa thuận về chức năng, đặc tả hệ thống.(SRS)
ü Gán nhãn các yêu cầu phần mềm.
ü Đánh dấu những điểm chưa rõ trong đặc tả.
ü Mối liên quan giữa đặc tả vào giao diện người sử dụng.
1.26 Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU)
Trả lời:
Giao diện
-Chức năng
-Cơ sở dữ liệu
-Bảo mật
-Chất lượng
-Hạn chế.
IEEE:
· Giới thiệu
ü Mục đích tài liệu
ü Văn bản quy ước.
ü Đối tượng dự kiến và góp ý.
ü Phạm vi sản phẩm.
ü Tài liệu tham khảo.
· Mô tả chung
ü Đặc điểm sản phẩm
ü Chức năng sản phẩm
ü Đặc điểm user
ü Môi trường vận hành
ü Thiết kế và ràng buộc
ü Giả định và phụ thuộc
· Yêu cầu về giao diệ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 tương tác
· Tính năng hệ thống
ü Hệ thống tương lai
ü Mô tả và ưu tiên
ü Kích cầu/ thứ tự đáp ứng.
ü Yêu cầu chức năng
· Yêu cầu phi chức năng.
ü Yêu cầu trình diễn
ü Yêu cầu an toàn
ü Yêu cầu bảo mật
ü Yêu cầu chất lượng các thành phần phần mềm
ü Nguyên tắc công việc
ü Tài liệu người sử dụng
· Các yêu cầu khác
ü Thuật ngữ
ü Mô hình phân tích
ü Danh sách định dạng
CMU:
1.27 Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào trong tài liệu SRS.
Trả lời:
a. Trong cấu trúc Đặc tả yêu cầu phần mềm ( SRS ) :
- System Requirement ( yêu cầu hệ thống ) : Nêu lên cấu hình hiện tại của cơ sở hạ tẩng thông tin của hệ thống sẽ được phát triển phần mềm như : Cấu hình hạ tầng mạng, hệ thống máy tính, các thiết bị ngoại vi đang có, …. và ảnh hưởng của chúng lên phần mềm sẽ xây dựng. Nó xác định cách mà phần mềm mới phải tương tác với hệ thống đã có và những ràng buộc quan trọng phải được quản lý cẩn thận.
- Software Requirement được hiểu là các yêu cầu về phần mềm 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... do khách hàng đưa ra.
b. Trong tài liệu SRS System Requirement được đặt phía trước Software Requirement:
- System Requirement được đặc tả trong phần các yêu cầu chung nhất đối với hệ thống phần mềm sẽ phát triển.
- Software Requirement là phần chính của tài liệu SRS, bao gồm mô tả chi tiết yêu cầu đối với từng chức năng mà hệ thống cần phải đạt được , nó được đặc tả ở phần trung tâm của tài liệu SRS.
1.28 Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm
Trả lời:
1. Giả ngôn ngữ
Giả ngôn ngữ là một sự kết hợp giữa ngôn ngữ tự nhiên với những cú pháp chặt chẽ, những cấu trúc điều khiển của một ngôn ngữ lập trình để diễn giải thuật toán hay chương trình theo một cách dễ hiểu nhất.
2. Máy trạng thái hữu hạn
Máy trạng thái hữu hạn (FSMS) rất phổ biến cho một số loại ứng dụng lập trình hệ thống, nhắn tin, chuyển đổi hệ thống, hệ điều hành và hệ thống điều khiển quá trình. FSMS là một cách để mô tả sự tương tác giữa người sử dụng nhân lực bên ngoài và hệ thống.
3. Cây quyết định
Thường được sử dụng trong việc xem xét yêu cầu dựa trên sự kết hợp của các thông tin đầu vào, những sự kết hợp khác nhau của các thông tin đầu vào sẽ dẫn đến các hành vi khác nhau hoặc các kết quả khác nhau của các kết quả đầu ra. Việc xây dựng cây quyết định thường gắn với những câu lệnh điều kiện “if – then” lồng nhau.
4. Biểu đồ hoạt động
Với việc sử dụng ngôn ngữ mô hình hóa UML, các đặc tả có thể được diễn giải thành các hình khối rất trực quan giúp cho người sử dụng có thể dễ dàng nắm bắt được nội dung của SRS.
5. Mô hình thực thể liên kết
ERD cung cấp 1 kiến trúc cấp cao của dữ liệu, nó sẽ được tiếp tục tăng cường với các chi tiết thích hợp về các thông tin cần thiết để mô tả.
6. Phân tích hướng đối tượng
Là một lối tư duy về vấn đề theo lối ánh xạ các thành phần trong bài toán vào cac đối tượng ngoài đời thực. Giúp người sử dụng dễ hiểu.
1.29 Phân tích vai trò của từng thành phần trong cấu trúc tài liệu yêu cầu phần mềm
Trả lời:
Cấu trúc tài liệu yêu cầu phần mềm: 11 thành phần
- Introduction (Giới thiệu)
- Glossary (từ điển thuật ngữ)
- Use Cases (trường hợp sử dụng)
- Design Overview (thiết kế tổng quan)
- System Object Model (mô hình đối tượng hệ thống)
- Object Descriptions (mô tả đối tượng)
- Object Collaborations (đối tượng hợp tác)
- Data Design (thiết kế dữ liệu)
- Dynamic Model (mô hình động)
- Non-functional Requirements (yêu cầu phi chức năng)
- Supplementary Documentation (tài liệu bổ sung)
1. Introduction: cho ta biết
- Mục đích:
· Cung cấp một mô tả về các thiết kế của một hệ thống đầy đủ để cho phép phát triển phần mềm.
· Cung cấp thông tin cần thiết để cung cấp mô tả chi tiết cho các phần mềm và hệ thống được xây dựng
- Phạm vi: cho biết phạm vi của hệ thống
- Các từ viết tắt,các định nghĩa: giúp tài liệu trở nên ngắn gọn hơn, người đọc dễ đọc, dễ hiểu hơn.
- Sự tham khảo
- Tổng quan: giúp người đọc có cái nhìn tổng quan về hệ thống cần xây dựng
2. Glossary:cung cấp các thuật ngữ và định nghĩa để sử dụng nội bộ của tài liệu
3. Use Cases: xác định được những ai sẽ sử dụng hệ thống, tác nhân kích hoạt, đại diện và quản trị hệ thống
4. Design Overview: đưa ra một tổng quan về thiết kế, cho nó vào một ngữ cảnh với các hệ thống bên ngoài. Cho phép người đọc và người sử dụng tài liệu định hướng cho bản thân để thiết kế và nhìn thấy một bản tóm tắt trước khi tiếp tục thiết kế các chi tiết.
5. System Object Model : cho phép mô tả các hệ thống một cách tổng thể, cho thấy các nhóm khác nhau của các phần vào các hệ thống tương ứng
6. Object Descriptions: mô tả các đối tượng trong tài liệu
7. Object Collaborations: mô tả mối quan hệ các đối tượng
8. Data Design: Sơ đồ thực thể liên kết: cho biết các liên kết giữa các đối tượng (1-1, 1-nhiều, nhiều-nhiều)
9. Dynamic Model:
- Sơ đồ trình tự: cho thấy mức độ tổng quan về hình thức trình tự di chuyển từ dữ liệu và mẫu để có một tài liệu
- Sơ đồ chỉnh sửa tài liệu: cho thấy mức độ tổng quan về trìn tự di chuyển từ một tài liệu ban đầu chưa sửa đổi cho một tài liệu sửa đổi
10. Non-functional Requirements: cung cấp các yêu cầu thực hiện (các yêu cầu phi chức năng)
11. Supplementary Documentation: có thể là tài liệu tham khảm, có thể là công cụ được sử dụng để tạo biểu đồ
1.30 Ý nghĩa của đặc tả hệ thống trong đặc tả yêu cầu phần mềm
Trả lời:
ý nghĩa của đặc tả hệ thống trong đặc tả yêu cầu phần mềm
Đặc tả hệ thống là đặc tả chức năng hệ thống: Định nghĩa các chức năng phần mềm mà người phát triển cần phải xây dựng để có thể đáp ứng được tất cả các nhiệm vụ đã miêu tả trong yêu cầu người sử dụng.
1.31 Các kỹ thuật đăc tả các yêu cầu chức năng trong đặc tả yêu cầu phần mêm. Phương pháp mã hóa các đặc tả chức năng và kiểm soát quan hệ giữa các yêu cầu chức năng
Trả lời
Các kĩ thuật đặc tả yêu cầu chức năng.
Các phương pháp kỹ thuật để xác định các yêu cầu phù hợp với mô tả yêu cầu là quá phức tạp đối với ngôn ngữ tự nhiên.
Các phương pháp kỹ thuật để xác định các yêu cầu phù hợp với mô tả yêu cầu là quá phức tạp đối với ngôn ngữ tự nhiên.
1 số phương pháp kĩ thuật bao gồm:kỹ thuật mã giả,máy trạng thái hữu hạn,cây quyết định,sơ đồ hoạt động, mô hình thực thể-quan hệ, phân tích hướng đối tượng, và phân tích cấu trúc.
Bạn có thể chọn từ nhiều phương pháp đặc tả kỹ thuật:
1.Mã giả
1.Mã giả
2.Máy trạng thái hữu hạn.
3.Cây quyết định
4.Biểu đồ hoạt động
5.Mô hình thực thể quan hệ
6.Phân tích hướng đối tượng
7.Phân tích cấu trúc(Biểu đồ luồng dữ liệu)
1.Mã giả
Mã giả là một "chuẩn" lập trình ngôn ngữ,kết hợp các phi chính thức của ngôn ngữ tự nhiên với cú pháp chặt chẽ, cấu trúc điều khiển của một ngôn ngữ lập trình. Mã giả bao gồm sự kết hợp của:
Câu bắt buộc với một động từ duy nhất và một đối tượng duy nhất.
Thường không quá 40-50, các "hành động theo định hướng" động từ mà từ đó các câu phải được xây dựng
Quyết định đại diện có cấu trúc IF-ELSE-ENDIF
Lặp đi lặp lại các hoạt động biểu diễn với DO-WHILE hay cấu trúc FOR-NEXT
Hình 28-1 cho thấy một ví dụ về một đặc tả mã giả của thuật toán để tính doanh thu.
Mã giả là một "chuẩn" lập trình ngôn ngữ,kết hợp các phi chính thức của ngôn ngữ tự nhiên với cú pháp chặt chẽ, cấu trúc điều khiển của một ngôn ngữ lập trình. Mã giả bao gồm sự kết hợp của:
Câu bắt buộc với một động từ duy nhất và một đối tượng duy nhất.
Thường không quá 40-50, các "hành động theo định hướng" động từ mà từ đó các câu phải được xây dựng
Quyết định đại diện có cấu trúc IF-ELSE-ENDIF
Lặp đi lặp lại các hoạt động biểu diễn với DO-WHILE hay cấu trúc FOR-NEXT
Hình 28-1 cho thấy một ví dụ về một đặc tả mã giả của thuật toán để tính doanh thu.
2.Máy trạng thái hữu hạn.
Trong một số trường hợp, đó là thuận tiện để mô tả mối quan hệ rời rạc của 1 nhóm các hệ thống. Trong phản ứng với một đầu vào, chẳng hạn như nhập dữ liệu từ người sử dụng hoặc nhập vào từ một thiết bị bên ngoài, máy tính này thay đổi trạng thái của nó và sau đó tạo ra sản phẩm hoặc thực hiện một hành động.
Thiết kế phần cứng đã sử dụng máy trạng thái hữu hạn (FSMS) trong nhiều thập niên.
Hình 28-2 minh họa chuyển trạng thái cho các hộp đèn
Thiết kế phần cứng đã sử dụng máy trạng thái hữu hạn (FSMS) trong nhiều thập niên.
Hình 28-2 minh họa chuyển trạng thái cho các hộp đèn
FSMS đang rất phổ biến cho một số loại ứng dụng lập trình hệ thống, chẳng hạn như nhắn tin, chuyển đổi hệ thống, hệ điều hành, và hệ thống điều khiển quá trình.
3.Cây quyết định.
Nó phổ biến để xem một yêu cầu với một sự kết hợp của các yếu tố đầu vào, kết hợp khác nhau của các yếu tố đầu vào dẫn đến các hành vi khác nhau hoặc kết quả đầu ra.
Hình 28-3 cho thấy một cây quyết định sử dụng để mô tả các trình tự khẩn cấp HOLIS.
Nó phổ biến để xem một yêu cầu với một sự kết hợp của các yếu tố đầu vào, kết hợp khác nhau của các yếu tố đầu vào dẫn đến các hành vi khác nhau hoặc kết quả đầu ra.
Hình 28-3 cho thấy một cây quyết định sử dụng để mô tả các trình tự khẩn cấp HOLIS.
4.Biểu đồ hoạt động.
Các hoạt động sơ đồ UML, có lợi thế là hiểu biết hợp lý: Ngay cả người không có đào tạo liên quan đến máy tính đều có thể hiểu được. 
5.Mô hình thực thể-quan hệ
Nếu các yêu cầu trong thiết lập liên quan đến một mô tả về cấu trúc và các mối quan hệ giữa các dữ liệu trong hệ thống, nó thường thể hiện bằng sơ đồ thực thể-quan hệ (ERD). Hình 28-5 cho thấy một ERD điển hình.
Nếu các yêu cầu trong thiết lập liên quan đến một mô tả về cấu trúc và các mối quan hệ giữa các dữ liệu trong hệ thống, nó thường thể hiện bằng sơ đồ thực thể-quan hệ (ERD). Hình 28-5 cho thấy một ERD điển hình.
Các ERD không chính xác tập trung vào các hành vi bên ngoài của hệ thống mà cho phép chúng ta xác định những câu hỏi như "Có thể có nhiều hơn một địa chỉ thanh toán cho mỗi hoá đơn?" Trả lời: không có.
Mặc dù một ERD là một kỹ thuật mô hình hóa mạnh mẽ nhưng không phải là tất cả mọi người đều có thể hiểu được nó.
Mặc dù một ERD là một kỹ thuật mô hình hóa mạnh mẽ nhưng không phải là tất cả mọi người đều có thể hiểu được nó.
6.Mô hình hướng đối tượng.
Với sự phổ biến của OO và UML, các sơ đồ này được coi là nổi bật hơn cả trong số các kỹ thuật, trong các mô hình triển khai để thực hiện các chức năng của hệ thống.
Trong hình 28-6
Trong hình 28-6
7.Biểu đồ luồng dữ liệu
Ví dụ hình 28-7.
Biểu đồ luồng dữ liệu (DFD) các mô hình khá giống như mô hình ERD nhưng nó dễ hiểu hơn so với ERD.
1.32 Các kỹ thuật đăc tả các yêu cầu phi chức năng trong đặc tả yêu cầu phần mêm. Phương pháp mã hóa các đặc tả phi chức năng và kiểm soát quan hệ giữa các yêu cầu phi chức năng
Trả lời:
Yêu cầu phi chức năng là các ràng buộc về các loại giải pháp thỏa mãn các yêu cầu chức năng. Các yêu cầu này mô tả về chính hệ thống, và về việc nó cần thực hiện các chức năng của mình tốt đến mức độ nào, chẳng hạn yêu cầu loại này là yêu cầu về tính sẵn có, khả năng kiểm thử, khả năng bảo trì, và tính dễ sử dụng. Có thể chia các yêu cầu phi chức năng thành hai loại:
ü Ràng buộc về hiệu năng: chẳng hạn "hệ thống cần phục vụ liên tục từ 5 giờ sáng đến 9 giờ tối.", "mỗi đơn đặt hàng cần được lưu trữ trong tối thiểu 7 năm".
ü Ràng buộc về quá trình phát triển hệ thống: thời gian, tài nguyên, chất lượng. Ví dụ: khi nào hệ thống cần hoàn thành (thời gian); tổng chi phí cho phát triển hệ thống (tài nguyên); cần áp dụng các tiêu chuẩn nào cho quá trình phát triển hệ thống, trong đó có các phương pháp quản lý dự án và phát triển hệ thống (chất lượng).
Các kỹ thuật chính:
ü Làm rõ yêu cầu (Eliciting requirements): giao tiếp với khách hàng và người sử dụng để xác định các yêu cầu của họ.
ü Xem xét yêu cầu (Analyzing requirements): xác định xem các yêu cầu được đặt ra có ở tình trạng không rõ ràng, không hoàn chỉnh, đa nghĩa, hoặc mâu thuẫn hay không, và giải quyết các vấn đề đó.
ü Làm tài liệu yêu cầu (Recording requirements): các yêu cầu có thể được ghi lại theo nhiều hình thức, chẳng hạn các tài liệu ngôn ngữ tự nhiên, các tình huống sử dụng(use case), câu chuyện sử dụng(user story), hoặc các đặc tả tiến trình.
Làm rõ yêu cầu khách hàng có thể sử dụng một số kỹ thuật sau như:
ü Các cuộc phỏng vấn
ü Thành lập các nhóm trọng tâm (focus group) với các cuộc họp bàn về yêu cầu (requirements workshops)
ü Tạo ra các danh sách yêu cầu
ü Tạo nguyên mẫu(prototyping)
ü Tạo tình huống sử dụng
1.33 Nêu các phương pháp đánh giá chất lượng tài liệu đặc tả yêu cầu phần mềm
Trả lời:
Tài liệuyêucầu:
ü Chỉ mô tả về chức năng, ràng buộc
ü Không mô tả về phương pháp cài đặt
ü Phải dễ thay đổi (có cấu trúc)
ü Khó xác định được đầy đủ chính xác ngay
ü Phải qua nhiều bước xét duyệt lại
Các nguyên tắc chỉ đạo khi viết tài liệu đặc tả:
(1) Cố gắng viết các câu và đoạn văn ngắn gọn, không dài dòng
(2) Sử dụng các thuậtngữ dễ hiểu, đã có trong glossary
(3) Viết các câu văn trong sáng, đúng ngữ pháp
(4) Tránh sử dụng những từ mang tính chất quảng cáo: giao diện
thân thiện, hệ thống hoạt động hiệu quả, v.v một cách chung
chung mà cần chỉ rõ như thế nào là thân thiện, như thế nào
là hiệu quả
(5) Tránh sử dụng những tính từ so sánh: tốt hơn tốt nhất mà nên
chỉ ra rõ ràng các tiêu thức đánh giá trong đặc tả.
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
1.34 Phân tích vai trò của từng tác nhân trong xem xét và thông qua (phê duyệt) tài liệu đặc tả yêu cầu phần mềm
Trả lời:
Các tác nhân tham gia vào quá trình xem xét và thông qua (phê duyệt) tài liệu yêu cầu đặc tả phần mềm:
- Các đại diện của người sử dụng (Product Champions): Thực hiện quá trình xác nhận các yêu cầu (Requirements Validation). Căn cứ vào tài liệu đặc tả và các yêu cầu thực tế của hệ thống, họ sẽ phải trả lời câu hỏi “Tôi có đang mô tả đúng phần mềm hay không?”. Các tiêu chí để xác nhận gồm có:
o Tính chính xác (Correct)
o Tính khả thi (feasible)
o Tính cần thiết (necessary)
o Độ ưu tiên (prioritized) của các yêu cầu.
- Các phân tích viên (Requirements Analysts): Thực hiện quá trình xác minh các yêu cầu (Requirements Verification). Căn cứ vào tài liệu đặc tả và các yêu cầu người dùng, họ sẽ phải trả lời cho câu hỏi “Tôi có đang xây dựng phần mềm đúng không?”. Các tiêu chí xác minh gồm:
o Tính ngắn gọn, súc tích (concise)
o Khả năng truy vết (traceable)
o Không dư thừa (non-redundant)
o Tổ chức tốt (organized)
o Đúng quy chuẩn (conformant to standards)
o Khả năng kiểm chứng (verifiable)
- Ngoài ra còn có các thành viên của công ty phần mềm tham gia vào qua trình thực hiện phát triển phần mềm: Lập trình viên, các nhà kiểm thử…
1.35 Các chức năng của EA hỗ trợ mô hình hóa các yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL
Trả lời:
Mô hình hóa use case
Mô hình hóa dữ liệu
Mô hình hóa nghiệp vụ
Requirements Modeling
Trong Enterprise Architect bạn có thể thu được hoặc thấy các yêu cầu một cách trực tiếp theo dạng mô hình, sử dụng thành phần Requirement cho phép từ bảng Requirements của Toolbox. Đây được coi là những yêu cầu bên ngoài. (Bảng Requirements đặt ở phía bên trái của giao diện EA trong Toolbox)
Sử dụng thành phần UML cho phép các yêu cầu được theo dõi đến các thành phần UML khác như là những yêu cầu khác, những use case, test case, và các thành phần phân tích hoặc thiết kế. Thành phần này có thể được sử dụng để mô hình hóa hoặc tài liệu hóa bất kì yêu cầu nào từ những yêu cầu dạng nghiệp vụ cho đến những yêu cầu về hiệu năng hoặc bảo mật. Những yêu cầu này có thể được thể hiện theo dạng sơ đồ với những quan hệ đi kèm( Hình 1). Những thông tin cốt lõi phía sau bất kì một yêu cầu nào cũng được định nghĩa trong phần properties (Hình 2) người dùng định nghĩa các “attributes” sử dụng Tagged Values và Profiles
Hình 1
Hình 2
Cách tạo External Requirement
· Chuột trái vào ‘Custom Button’ trong ‘UML Toolbox’ để mở bảng custom
· Click và kéo ‘Requirement’ từ bảng vào sơ đồ
· EA cho phép bạn xác định vài thuộc tính của yêu cầu
o Một trường ‘Short Description’ sẽ hiển thị trên sơ đồ
o Nhìn ‘External Requirement Attributes’ bên dưới để rõ hơn
· Click Ok để kết thúc
· Những thuộc tính này có thể sử chữa lại sau này bằng cách double-click vào requirement
· Một requirement mới được hiển thị trong ‘Project View’
Tên của requirement có thể đơn giản là dạng text hoặc được đánh số phía trước tên nhãn. EA hỗ trợ đánh số tự động các requirements (xem phần auto-naming elements bên dưới)
Các thuộc tính của External Requirement
Double-click vào các Requirement để gán các thuộc tính cho requirement. EA hỗ trợ các thuộc tính của Requirement như là status, difficulty, priority, and type. Ví dụ: xem hình 2 bên trên. Thay đổi chỉnh sửa dễ dàng à nhần OK để apply.
Những đặc trưng hữu ích cho External Requirement
Khi sử dụng external requirements, có một vài cách để thay đổi dữ liệu và cách nhìn các chi tiết.
Ví dụ:
· Tạo những thuộc tính user-definable sử dụng tagged values
· Viewing Requirement sử dụng Elements list view hoặc diagram view
· Thiết lập những mối quan hệ giữa các yêu cầu, như quan hệ với các thành phần UML khác như use case, class, test case v.v
· Những quan hệ dò vết giữa những yêu cầu và những thành phần khác.
· Tạo một cây yêu cầu kế thừa sử dụng thành phần child hoặc packages.
Thêm Additional Attributes của Requirements
Thông thường có một chuỗi các thuộc tính yêu cầu được xác định cho một dự án nào đó. Bạn có thể nhập vào một số bất kì những thuộc tính thêm vào này như độ tin cậy, giá thành, độ trễ phạt thông qua việc sử dụng ‘tagged values’.
Tagged values có thể định nghĩa trên một one-off cơ bản cho vài thành phần hoặc được định nghĩa trức khi thêm vào trong việc tạo ra một thành phần mới.
Tagged values data cho một thành phần được cho phép như là một cửa sổ riêng biệt, để truy xuất sử dụng Ctrl + Shift + 6 ( hoặc từ Main menu View| Tagged Values). Ví dụ xem hình 3
Hình 3
Predefining Tagged Values Types for Requirements
Những thành phần trong EA, bao gồm những thành phần yêu cầu, có thể có một tập các thuộc tính mở rộng đã được định nghĩa cho một dự án. Các thuộc tính thành phần này có thể được định nghĩa trước sử dụng một UML profile hoặc EA Template. Ví dụ xem hình 4 một thành phần sử dụng tập tagged values predefined cho những yêu cầu của một dự án.
Hình 4
Những thuộc tính mở rộng này có thể thấy được trực tiếp trên sơ đồ. Để thiết lập chế độ này right-click vào diagram và trong menu context lựa chọn Properties| Elements| Show Compartments| [v] Tags. Ví dụ xem hình 5
Hình 5
Element Numbering
EA hỗ trợ việc tạo một cây phân cấp những thành phần dưới dạn package. Việc đánh số kết hợp với cấu trúc phân cấp cho phép các thành phần bên trong một Package được đánh số theo dạng 1.1.1. Những đặc trưng này có thể được thiết lập trên bất kì package nào và áp dụng cho những thành phần chứa trong root of package (không áp dụng cho child package)
Ví dụ Element hierarchy với Element Numbering
Hình 6
Để cho phép lựa chọn này
· Select một package trong Project Browser
· Right-click và từ menu context select: Show Level Numbering
Hình 7
Từ Project View, các thành phần được đánh số có thể được sắp xếp lại đơn giản bằng cách kéo một child element vào một element khác. Những elements con sẽ được đánh số lại để phù hợp với elements cha.
Hình 8
Different Views of Requirements Using the Element List View
Thông thường nhưng yêu cầu được định nghĩa bởi người dùng không giống với sơ đò UML. EA hỗ trợ một text-based view của những yêu cầu, trong khi vẫn duy trì cấu trúc phân cấp trong Project View.
Vài đặc trưng là:
· The Project View. Cái này có thể gắn ở phía trái màn hình để hiển thị cây phân cấp.
· The Element List View. Sơ đồ này có thể thiết lập về chế độ text view
o Để thay đổi chế độ diagram view và Elements List View từ main menu, sleect View| Element List.
· The Notes and Tagged Value windows có thể thiết lập là default view
o Để xem the notes window select View| Notes
o Để xem the tagged values window select View| Tagged Values.
Dưới đây là ví dụ của text-based mode
Hình 9
Bên dưới là ví dụ text-based với Tagged Value window và the Notes window được mở:
Hình 10
Việc mô hình hóa này còn một số phần nhưng nó dính sang phần ‘Traceability’ và ‘Change Control’ thuộc những câu khác nên các bạn tham khảo để chém thêm nhé.
1.36 Các chức năng của EA hỗ trợ xây dựng đặc tả yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL
Trả lời:
ü Tạo ra các yêu cầu phần mềm bên ngoài (External Requirements)
+ Tạo trong biểu đồ ( Diagram )
· Mở Custom pages trong Enterprise Architect UML Toolbox. Chọn Requirements
· Cầm đối tượng Requirement, thả vào trong biểu đồ
· Nhập tên và các thông tin khác cho Requirement. Save lại
+ Tạo trong gói ( Package)
· Nháy phải vào gói, chọn Insert | New Element ( hoặc Ctrl + M )
Trong hộp thoại New Element, chọn
· Nhập tên và các thông tin khác cho Requirement. Save lại.
ü Tạo ra các yêu cầu phần mềm bên trong một Element khác (Internal Requirements)
Ta có thể tạo ra các yêu cầu phần mềm bên trong 1 Element khác như Usecase, Class,… để chỉ ra rằng Element đó có nhiệm vụ cài đặt các yêu cầu đã nêu.
Để thực hiện việc này, ta thực hiện như sau:
· Mở hộp thoại Properties của Element.
· Chọn Tab Require
· Nhập tên Requirement và các thuộc tính của nó.
· Bấm Save để lưu Requirement lại
· Nếu muốn, bấm New để tạo tiếp Internal Requirement khác cho Element, cũng hoặc thực hiện các thao tác quản lý khác ( sắp xếp, sửa, xóa )
· Bấm OK để đóng hộp thoại
ü Chuyển yêu cầu bên trong ra ngoài
· Mở hộp thoại Properties của Element. Chọn Tab Require
· Chọn Requirement cần chuyển. Bấm Move External
· Trong hộp thoại mở ra, chọn package để lưu External Requirement
ü Quản lý các thuộc tính cơ bản của yêu cầu:
Các thuộc tính cơ bản của yêu cầu được quản lý trong EA:
· Tên
· Trạng thái thực hiện (đề xuất, đã phê chuẩn, đang cài đặt, bắt buộc, đã kiểm tra)
· Độ khó
· Độ ưu tiên
· Loại yêu cầu ( Chức năng, hiển thị, báo cáo, kiểm thử , …)
· Ghi chú
· Các thông tin khác
ü Ghi chú các thông tin bổ sung
· Sử dụng thuộc tính Note
· Sử dụng đối tượng chú thích Note
· Sử dụng Tagged Values (lựa chọn, mở cửa sổ Tagged Values, tạo ra các cặp Key – Value lưu trữ các thông tin bổ sung cho yêu cầu )
ü Xóa, sắp xếp các yêu cầu
Thực hiện trong cửa sổ Project Browser, thông qua các button trên toolbox hoặc menu ngữ cảnh.
ü Tạo cấu trúc phân cấp cho yêu cầu
Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha.
Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement: 1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn.
ü Đánh số cho các Requirement:
Nháy phải vào package, chọn Show Level Numbering
ü Kết xuất thành văn bản
· Lựa chọn Requirement cần kết xuất
· Vào menu, chọn Project | Documentation
· Lựa chọn loại báo cáo phù hợp ( Rich Text Format, HTML,…)
· Trong hộp thoại mở ra, nhập các thông số cần thiết. Chú ý chọn Use template là requirement template
….
1.37 Phân biệt các khái niệm Kiểm thử và Đánh giá các yêu cầu phần mềm
Trả lời:
* Kiểm thử các yêu cầu phần mềm (Testing): Việc kiểm thử yêu cầu phần mềm nhằm xác định các yêu cầu có đáp ứng được các yêu cầu của người sử dụng không. Công việc được thực hiện như sau:
· Viết các trường hợp kiểm thử cho các yêu cầu.
· Sử dụng mô hình hộp đen từ các trường hợp kiểm thử để đánh giá họat động hành vi của hệ thống.
· Duyệt các hành vi và theo dõi các hoạt động để kiểm tra hệ thống đang đặc tả có đáp ứng yêu cầu của người sử dụng hay không.
Quy trình kiểm thử:
•Business Requirement
•Use Case
•Functional Requirement
Các công cụ sử dụng:
•Dialog Map
•Test Case
•Ma trận theo dõi các trường hợp sửdụng
* Đánh giá các yêu cầu phần mềm
Khác với kiểm thử yêu cầu phần mềm là xem xét xem yêu cầu phần mềm có phù hợp với yêu cầu người sử dụng hay không, việc đánh giá yêu cầu phần mềm lại dựa trên tính nhất quán, thân thiện, và dễ sử dụng của tài liệu đặc tả yêu cầu phần mềm.
Cụ thể việc đánh dựa vào các đặc điểm sau:
a. Các đặc điểm đối với từng yêu cầu phần mềm tốt.
a. Đầy đủ ( complete )
b. Chính xác (Correct)
c. Khả thi ( feasible)
d. Cần thiét ( necessary).)
e. Xếp hạng tính quan trọng và ổn định (Ranked for importance and stability)
f. Rõ ràng.
g. Có thể kiểm tra được (Verifiable)
b. Các đặc điểm của một tài liệu đặc tả phần mềm tốt.
a. Đầy đủ.
b. Có thể sửa đổi (Modifiable)
c. Có thể thể theo dõi được (Traceable)
d. Thống nhất ( consistent)
(Có thể trả lời theo đặc tính chất lượng).
1.38 Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm. Nêu tên một số phương pháp kiểm thử yêu cầu phần mềm thông dụng mà em biết.
Trả lời:
Việc kiểm thử đánh giá các yêu cầu phần mềm là cần thiết bởi vì qua việc kiểm thử đánh giá, chúng ta mới có thể thẩm định được tính đúng đắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm mà chúng ta đã miêu tả trong SRS. Các yêu cầu đó phải đúng là những yêu cầu từ khách hàng, giải quyết được các công việc của họ.
Một số phương pháp kiểm thử yêu cầu phần mềm thông dụng:
- Kiểm thử hộp đen
- Kiểm thử hộp trắng
1.39 Nêu các phương pháp xem xét lại yêu cầu phần mềm. Những tác nhân nào tham gia vào xem xét lại yêu cầu phần mềm
Trả lời:
· Quy trình xem xét:
o Lập kế hoạch
o Các buổi họp mặt
o Chuẩn bị
o Các buổi họp duyệt
o Làm sửa đổi
o Kết thúc
· Công cụ sử dụng, mẫu sử dụng
o Các tiêu thức đánh giá
o Requirement Inspection Checklist
· Các tác nhân tham gia vào quá trình duyệt các yêu cầu phần mềm (review):
o Các PTV – Phát Triển Viên
o Các đại diện của NSD (Product champions)
o Tất cả các thành viên của Cty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm: LTV, các nhà kiểm thử…
1.40 Phân tích các nguyên nhân dẫn tới thay đổi yêu cầu phần mềm
Tác động bên ngoàiü có thay đổi đòi hỏi chúng ta phải giải quyết bài toán mới
ü người dùng thay đổi ý kiến của họ
ü môi trường ngoài thay đổi
ü một hệ thống mới tồn tại trong đó
Tác động bên trongü Thất bại trong việc lấy yêu cầu từ người dùng ( chưa lấy đầy đủ yêu cầu từ nhiều người dùng)
ü Thất bại trong việc tạo một quy trình thực hành giúp quản lý sự thay đổi yêu cầu phần mềm
1.41 Nêu vai trò phương pháp prototyping trong duyệt và kiểm soát yêu cầu phần mềm
Trả lời:
Vai trò:
Phương pháp Prototyping có vai trò trong duyệt và kiểm soát yêu cầu phần mềm giúp hoàn thiện hơn về yêu cầu, đáp ứng được yêu cầu của người dùng
Cho người dùng dùng thử mẫu thử như là mẫu thử bản beta từ đó người dùng sẽ dùng thử và đưa ra những điểm tốt , điểm không tốt của mẫu thử, cái nào không cần thiết của mẫu thử từ đó người phân tích viên có thể duyệt yêu cầu nào đã đạt được yêu cầu nào hay những yêu cầu nào rườm ra có thể bỏ qua hay nên bổ sung những yêu cầu gì để thỏa mãn được yêu cầu của người dùng
Ví dụ: khi cho người dùng delete một bản ghi thì đòi hỏi phải có yêu cầu là có nên delete hay không?
Mẫu thử cho thẩm định yêu cầu giải thích các yêu cầu và giúp các bên liên quan khám phá được vấn đề
Thẩm định mẫu thử sẽ hoàn thành có hiệu quả cao và thiết thực. nó có thể dụng chúng trong cách giống nhau như là yêu cầu hệ thống
Tài liệu đào tạo cho người sử dụng sẽ được cung cấp
1.42 Nêu kỹ thuật duyệt mô hình hệ thống của các yêu cầu phần mềm. Các nội dung cần duyệt trong đánh giá mô hình
Trả lời:
Thẩm định mô hình hệ thống là một yêu tố cần thiết trong quá trình thẩm định
Có thể kiểm tra với một số công cụ tự động
Những giải thích về mô hình là một kỹ thuật kiểm tra có hiệu quả (kết quả)
Thành phần của mô hình hệ thống:
ü Để giải thích mỗi mô hình là phù hợp
ü Nếu có một vài mô hình của hệ thống để giải thích những sự phù hợp bên trong và bên ngoài.
ü Để giải thích rằng các mô hình có tính chính xác với các yêu cầu thực của những bên liên quan đến hệ thống. đây là một việc rất khó khăn.
1.43 Vai trò của kiểm thử chấp nhận trong duyệt và kiểm soát các yêu cầu phần mềm
1.44 Các kỹ thuật kiểm thử chấp nhận trong duyệt và kiểm soát các yêu cầu phần mềm
Trả lời:
Các kỹ thuật kiểm thử chấp nhận:
- Phát hiện lỗi: Các chương trình được thực hiện và kết quả là thứ cần kiểm tra. Nếu kết quả đúng, tiếp tục thực hiện bình thường. Một kiểm tra thất bại là triệu chứng của một lỗi. Kiểm thử chấp nhận hiệu quả nhất nếu nó được dựa trên các tiêu chí độc lập với chức năng đang được thử nghiệm và có thể tính toán một cách đơn giản để biết trước kết quả.
- Chẩn đoán lỗi: Kiểm thử chấp nhận không dùng để xác định cái gì đã sai. Nó chỉ có thể nói rằng có cái gì đó đã sai
- Ngăn chặn lỗi: Kiểm thử chấp nhận tạo ra rào cản không cho lỗi lan rộng.
- Che giấu lỗi: Kiểm thử chấp nhận che giấu một giá trị xấu nếu kết quả thử lại hoặc thay thế chính xác trong thời gian quy định trước khi tuyên bố thất bại
- Bồi thường lỗi: Nếu một chương trình thất bại trong kiểm thử chấp nhận có thể thay thế bằng một trường hợp dự phòng. Nếu trường hợp dự phòng thành công, có thể sử dụng đề bù đắp cho trường hợp ban đầu
- Sửa lỗi:
- ------------------------------------------Nguồn------------------------------------------------------
- 4.3 Acceptance Test Techniques
- The fault detection mechanism used influences the remainder of the fault tolerance activities (diagnosis, containment, masking, compensation, and recovery). The two common mechanisms for fault detection are acceptance tests and comparison.
-
- Acceptance tests are the more general fault detection mechanism in that they can be used even if the system is composed of a single (non-redundant) processor. The program or sub-program is executed and the result is subjected to a test. If the result passes the test, execution continues normally. A failed acceptance test is a symptom of a fault. An acceptance test is most effective if it is based on criteria that can be derived independently of the function being tested and can be calculated more simply that the function being tested (e.g., multiplication of a result by itself to verify the result of a square root function).
-
- An acceptance test cannot generally be used to determine what has gone wrong. It can only tell that something has gone wrong.
-
- An acceptance test provides a barrier to the continued propagation of a fault. Further execution of the program being tested is not allowed until some form of retry successfully passes the acceptance test. If no alternatives pass the acceptance test, the subsystem fails, preferably silently. The silent failure of faulty components allows the rest of the system to continue in operation (where possible) without having to worry about erroneous output from the faulty component [Schlichting 83].
-
- An acceptance test successfully masks a bad value if a retry or alternate results in a new, correct result within the time limit set for declaring failure.
-
- A program that fails an acceptance test can be replaced by an alternate, as described in the next section. If the alternate passes the acceptance test, its result may be used to compensate for the original result. Notice that the alternate program run during a retry may be a very simple one that just outputs a "safe" value to compensate for the faulty subsystem. A common approach in control systems is to "coast" the result by providing the value calculated from the last known good cycle.
-
- Acceptance tests are usually used in a construct known as a recovery block. A recovery block provides backward fault recovery by rolling program execution back to the state before the faulty function was executed. This repairs the faulty state and the result. When a result fails an acceptance test, the program can be executed again before leaving the recovery block. If the new result passes the acceptance test, it can be assumed that the fault originally detected was transient. If the software is suspect, an alternative can be executed in place of the original program fragment. If a single processor is used, the state of the processor must be reset to the beginning of the function in question. A mechanism called the recovery cache has been proposed to accomplish this [Anderson 76]. A recovery cache records the state of the processor at the entrance to each recovery block. Although a recovery cache is best implemented in hardware, implementations to date have been limited to experimental software. Where multiple processors are available, the retry may take the form of starting the program on a backup processor and shutting down the failed processor. Recovery blocks can be cascaded so that multiple alternatives can be tried when an alternate result also fails the acceptance test.
- ----------------------------------------------------------------------------------------------------------------
-
1.45 Các chức năng cơ bản của EA hỗ trợ người dùng trong duyệt và kiểm soát yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL
Trả lời:
EA hỗ trợ tính năng theo dõi thay đổi định nghĩa yêu cầu. Chúng bao gồm kiểm toán, quản lý đường cơ sở, yêu cầu thay đổi thành phần và vấn đề khai thác
Các tính năng kiểm toán cho phép bạn ghi lại những thay đổi mô hình trong EA. Nó ghi chi tiết của người thay đổi một yếu tố, khi nào và những gì đã được thay đổi, cùng với tình trạng trước của mô hình. Điều này có thể đặc biệt hữu ích để ghi lại lịch sử các thay đổi cho mô hình yêu cầu.
Để kích hoạt tính năng này:
1. Từ menu chính bạn chọn: View | Other Project Tools | Audit View,sẽ mở ra:
2. Bạn chọn Audit Settings
3. Nó sẽ mở ra cửa sổ Audit Settings :
4. Trong cửa sổ Audit Settings bạn thiết lập kích hoạt tính năng kiểm toán như hình vẽ trên.
Ví dụ dưới đây có Element List xem các tùy chọn thiết lập.cửa sổ Output | Audit History cho thấydanh sách các thay đổi cho các phần tử được lựa chọn:
Lịch sử đầy những thay đổi có thể xem được bằng cách loại phần tử bằng cách sử dụng Audit View:
Để biết thêm thông tin về cách sử dụng tính năng kiểm toán xem trợ giúp của EA :Projects and
Teams | Change Management | Tracking Changes | Auditing
Các tính năng kiểm toán nêu trên, cung cấp liên tục theo dõi và ghi các thay đổi yêu cầu. tính năngBaseline Management hỗ trợ thêm để so sánh vàsáp nhập thay đổi. Nó cho phép đường cơ sở của một mô hình được tạo ra trên cơ sở định kỳ (nghĩa là theo tháng, phiên bản, giai đoạn hoặc xây dựng). Đường cơ sở đó có thể được so sánh với mô hình nhà nước hiện hành và thay đổi lựa chọn kết hợp.
Để biết thêm thông tin về thiết lập đường cơ sở và xem sự khác biệt xem phần trợ giúp:
Projects and Teams | Change Management | Tracking Changes | Package Baselines
ea hỗ trợ đăng nhập của biến đổi, yêu cầu đối với yêu cầu. Điều này có thể được xác định
sử dụng hai phương pháp khác nhau:
sử dụng hai phương pháp khác nhau:
-Dùng Maintenance View để thay đổi danh sách, khiếm khuyết, vấn đề và nhiệm vụ chống lại mỗi phần tử.
-Sử dụng các yếu tố tùy thuộc loại "Issue " và "Change " liên kết với các yêu cầu ngoài
được thay đổi.
được thay đổi.
Mỗi cái đã sử dụng khác nhau được liệt kê như sau:
có thể được sử dụng để đăng nhập thay đổi đối với bất cứ phần tử hoặc trọn gói. Điều này cung cấpdanh sách cho:
o Element khiếm khuyết
o Thay đổi Element
o Các vấn đề Element
o Element Nhiệm vụ
o Element khiếm khuyết
o Thay đổi Element
o Các vấn đề Element
o Element Nhiệm vụ
Chúng bao gồm các lĩnh vực để ghi âm "by whom and when " yêu cầu đã được thực hiện và hoàn thành, cũnglà trạng, mô tả, ưu tiên và lịch sử.
Maintenance View có thể được truy cập từ trình đơn chính bằng cách sử dụng:View | Other Element Tools |Maintenance or (Alt+4) . Hình sau đây là một ví dụ của một tập hợp các thay đổi được liệt kê cho một phần tử:
Việc sử dụng chung cho quản lý yêu cầu là để đăng nhập chi tiết Yêu cầu-vấn đề và thay đổi-Yêu cầu đối với bất kỳ yếu tố yêu cầu hiện có.
các yếu tố bảo dưỡng của EA bao gồm các yếu tố của loại Issue và Change.Đây là những truy cập từ Toolbox | Maintenance hoặc Toolbox | Custom
Bảo trì các yếu tố có thể được liên kết bằng cách sử dụng một kết nối đến bất kỳ yếu tố (nghĩa là một yêu cầu đối ngoại) để hiển thị một sự thay đổi hay vấn đề một.
Lời khuyên:
-Những yếu tố có thể được lưu trữ trong gói có chứa các yêu cầu liên quan hoặc trong mộtriêng gói có chứa một bộ các thay đổi.
-Chúng có thể được liên kết với yêu cầu yếu tố trong biểu đồ thông thường hoặc bằng cách sử dụng các mối quan hệMa trận.
-Những yếu tố có thể được tùy chỉnh như là một phần của một hồ sơ để bao gồm các đặc tính mở rộng.
-Những yếu tố có thể được lưu trữ trong gói có chứa các yêu cầu liên quan hoặc trong mộtriêng gói có chứa một bộ các thay đổi.
-Chúng có thể được liên kết với yêu cầu yếu tố trong biểu đồ thông thường hoặc bằng cách sử dụng các mối quan hệMa trận.
-Những yếu tố có thể được tùy chỉnh như là một phần của một hồ sơ để bao gồm các đặc tính mở rộng.
Sơ đồ sau đây minh họa việc sử dụng một phần tử hành liên kết với một yêu cầu.
Dưới đây là cùng một dữ liệu xem trong Element List xem cùng với Relationship cửa sổ hiển thị các yếu tố liên quan đến việc phát hành lựa chọn:
1.46 Kiểm thử (testing) yêu cầu phần mềm
Trả lời:
Kiểm thử yêu cầu phần mềm là công việc thực hiện lại sau khi có được các yêu cầu phần mềm từ phía NSD, chủ dự án…Qúa trình này là một quá trình cân nhắc về khả năng đáp ứng lại yêu cầu phần mềm do những hạn chế về nhân lực, thời gian và tài chính của đội ngũ phát triển phần mềm.
Quá trình kiểm thử phát hiện các yêu cầu phần mềm đi quá phạm vi và giới hạn của phần mềm, ảnh hưởng đến kiến trúc hệ thống.
Nhìn chung kiểm thử phần mềm là một quá trình kiểm tra các yêu cầu phần mềm, từ đó đưa ra những yêu cầu hợp lý và những phương án chấp nhận được, thỏa mãn cả hai bên là người sử dụng và người phát triển hệ thống.
Tại sao phải kiểm thử yêu cầu phần mềm:
- Do tính chất 2 mặt của yêu cầu phần mềm: Cách nhìn và suy nghĩ về phần mềm từ phía người sử dụng và cách nhìn, suy nghĩ về phần mềm từ phía nhà phát triển.
- Người sử dụng đưa ra những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình phát triển phần mềm
- NSD đưa ra các yêu cầu và đề nghị rất khó chấp nhận là gây khó khăn cho các lập trình viên
- NSD đưa ra các yêu cầu nhập nhằng và mơ hồ, quá trình kiểm thử sẽ có trách nhiệm làm rõ các yêu cầu này.
- Phát hiện các đặc tính thừa do người phát triển hệ thống đưa thêm vào hoặc các yêu cầu phụ phần mềm từ phía người sử dụng gây tốn kém và không cần thiết
- Kiểm tra khả năng đáp ứng về mặt kỹ thuật
- Đặc tả rõ ràng và chi tiết các yêu cầu
Tiêu chí kiểm thử yêu cầu phần mềm
- Hoàn thiện
- Chính xác
- Khả thi
- Cần thiết
- Rõ ràng
- Kiểm tra được, xác minh được
Quy trình kiểm thử yêu cầu phần mềm:
· Bussiness Requirement
· Use Case
· Functional Requirement
Các công cụ sử dụng:
· Dialog Map
· Test Case
· Ma trận theo dõi các trường hợp sử dụng
1.47 Nêu các phương pháp theo dõi vết của yêu cầu phần mềm.
Trả lời:
· Có 2 loại theo dõi vết: Tường minh và không tường minh.
o Tường minh: Các mối quan hệ được thêm vào một cách tường minh bởi đội dự án. Ví dụ: Mối quan hệ giữa yêu cầu và các use case.
o Không tường minh: Ví dụ mối quan hệ phân cấp giữa các yêu cầu với nhau. Yêu cầu cha có mối quan hệ không tường minh với các yêu cầu con.
· Phương pháp: (từ sách SE – Pressman – p289)
Sau khi xác định yêu cầu, chúng ta lập các bảng theo dõi vết. Các bảng này cho phép chúng ta biết khi thay đổi một yêu cầu thì nó sẽ ảnh hưởng đến những nhân tố nào trong hệ thống sẽ xây dựng. Một số bảng theo dõi vết:
o Features traceability table: Cho biết mối quan hệ giữa yêu cầu và các tính năng mà khách hàng sẽ thấy được trong sản phẩm.
o Source traceability table: Xác định nguồn của từng yêu cầu.
o Dependency traceability table: Cho biết mối quan hệ giữa các yêu cầu với nhau.
o Subsystem traceability table: Phân loại các yêu cầu theo các phân hệ mà nó có ảnh hưởng.
o Interface traceability table: Cho biết mối quan hệ giữa yêu cầu và các giao diện của hệ thống (cả giao diện ngoài và giao diện trong).
1.48 Phân tích các thành phần trong ma trân vết yêu cầu phần mềm. Vai trò của ma trận trong theo dõi các thay đổi yêu cầu phần mềm
Trả lời:
Ma trận vết (theo dõi) yêu cầu phần mềm (Requirements Traceability Matrix - RTM)
Vai trò :
Phương pháp hay được sử dụng nhất để liên kết các yêu cầu phần mềm và các thành phần khác của hệ thống là sử dung ma trận vết (theo dõi) các yêu cầu phần mềm.
Việc sử dụng các RTM tăng cường quá trình quản lý phạm vi. Nó cũng hỗ trợ việc kiểm soát quy trình và quản lý chất lượng. RTM cũng có thể được coi như là một quá trình ghi chép các kết nối và mối quan hệ giữa các yêu cầu ban đầu của dự án và sản phẩm cuối cùng, dịch vụ sản xuất.
Thành phần :
Bao gồm các thành phần trong sơ đồ
Các liên kết này thường được thể hiện giữa các thành phần của ma trận:
• Các trường hợp sử dụng (yêu cầu phần mềm)
• Các yêu cầu chức năng (functional requirement)
• Các thành phần thiết kế (design element)
• Mã chương trình (code)
• Trường hợp kiểm thử (test case)
• Các yêu cầu chức năng (functional requirement)
• Các thành phần thiết kế (design element)
• Mã chương trình (code)
• Trường hợp kiểm thử (test case)
Các mối liên kết có thể được phân chia:
•Một-Một
•Một-Nhiều
•Nhiều-Nhiều
Các dạng biểu diễn ma trận:
•Lập bảng liên kết
•Lập ma trận liên kết
1.49 Kỹ thuật quản lý thay đổi yêu cầu phần mềm
Trả lời:
Tại sao các yêu cầu phần mềm thay đổi?
- Nhân tố ngoài: Vấn đề thay đổi, NSD thay đổi suy nghĩ, Môi trường thay đổi,….
- Nhân tố trong: Chúng ta đã thất bại trong việc đặt đúng câu hỏi cho đúng đối tượng đúng thời điểm trong suốt quá trình thu thập yêu cầu ban đầu. Chúng ta thất bại trong việc tạo ra một quá trình thích hợp để trợ giúp cho việc quản lý các thay đổi tron yêu cầu phần mềm
Một tiến trình quản lý các thay đổi :
1. Nhận thức được rằng, sự thay đổi trong yêu cầu phần mềm là không thể tránh khỏi và phải lên kế hoach cho nó
2. Vạch ra các yêu cầu cơ sở.
3. Thiết lập một kênh duy nhất để kiểm soát các thay đổi.
4. Sử dụng một hệ thống kiểm soát thay đổi để nắm bắt những thay đổi
5. Quản lý thay đổi thứ bậc.
Quản lý cấu hình yêu cầu:
- Ngăn cản các sự thay đổi trái phép và có khả năng phá hủy hoặc hư hại tới yêu cầu
- Lưu giữ các phiên bản tài liệu của yêu cầu.
- Tạo điều kiện cho việc thu hồi và/(hoặc) xây dựng lại các phiên bản tài liệu trước.
- Hỗ trợ quản lý, tổ chức các chiến lược cơ bản để cải tiến cập nhật hệ thống.
- Ngăn chặn việc cập nhật đồng thời các tài liệu hoặc các thông tin mẫu thuẫn nhau.
1.50 Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm
Trả lời:
Thuộc tính của các sản phẩm phần mềm là các đặc tính xuất hiện của sản phẩm một khi nó được cài đặt và được đưa ra dùng. Các thuộc tính này không bao gồm các dịch vụ được cung cấp kèm theo sản phẩm đó.
VD: mức độ hiệu quả, độ bền, khả năng bảo trì, khả năng dùng ở nhiều nền…
Các thuộc tính biến đổi tùy thuộc phần mềm, tuy nhiên, có một số thuộc tính tối quan trọng sau:
1. Khả năng bảo trì: có khả năng thực hiện những tiến triển để thỏa mãn yêu cầu của khách hàng.
2. Khả năng tin cậy: bao gồm hàng loạt các đặc tính như độ tin cậy, độ an toàn, bảo mật… Phần mềm tin cậy không thể tạo ra các thiệt hại vật chất hay kinh tế trong trường hợp hư hỏng.
3. Độ hữu hiệu: phần mềm không thể phí phạm các nguồn tài nguyên như là bộ nhớ và các chu kỳ xử lý.
4. Khả năng sử dụng: phần mềm nên có một giao diện tương đối dễ cho người sử dụng và có đầy đủ các hồ sơ về phần mềm.
Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm
ü Tính chính xác của yêu cầu?
ü Yêu cầu có bị lặp lại hay không?
ü Tính hợp lý của yêu cầu?
1.51 Nêu phương pháp theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần mềm
Trả lời:
1.52 Nêu các phương pháp đo đánh giá yêu cầu phần mềm
Trả lời :
* Đánh giá các yêu cầu phần mềm
Khác với kiểm thử yêu cầu phần mềm là xem xét xem yêu cầu phần mềm có phù hợp với yêu cầu người sử dụng hay không, việc đánh giá yêu cầu phần mềm lại dựa trên tính nhất quán, thân thiện, và dễ sử dụng của tài liệu đặc tả yêu cầu phần mềm.
Cụ thể việc đánh dựa vào các đặc điểm sau:
c. Các đặc điểm đối với từng yêu cầu phần mềm tốt.
h. Đầy đủ ( complete )
i. Chính xác (Correct)
j. Khả thi ( feasible)
k. Cần thiét ( necessary).)
l. Xếp hạng tính quan trọng và ổn định (Ranked for importance and stability)
m. Rõ ràng.
n. Có thể kiểm tra được (Verifiable)
d. Các đặc điểm của một tài liệu đặc tả phần mềm tốt.
e. Đầy đủ.
f. Có thể sửa đổi (Modifiable)
g. Có thể thể theo dõi được (Traceable)
h. Thống nhất ( consistent)
(Có thể trả lời theo đặc tính chất lượng).
Theo mình nghĩ phương pháp đo đánh giá yêu cầu phần mềm đó là làm đặc tả yêu cầu phần mềm tốt. Các phương pháp đặc tả yêu cầu là
· Pseudocode (Giả ngôn ngữ)
· Finite state machines (máy trạng thái hữu hạn)
· Decision trees (Cây quyết định)
· Activity diagrams (flowcharts) (Biểu đồ hoạt động)
· Entity relationship models (Mô hình thực thể quan hệ)
· Object-oriented analysis (Phân tích hướng đối tượng)
· Structured analysis (Phân tích hướng cấu trúc)
Đo chất lượng cho mô hình Use Case Đo chất lượng cho gói SRS Đo chất lượng dựa vào đánh giá các thuộc tính chất lượng yêu cầu phần mềm1.53 Các chức năng của EA trợ giúp trong theo dõi yêu cầu phần mềm
Trả lời:
Lập ma trận theo dõi yêu cầu phần mềm
- Phương pháp hay được sử dụng nhất để liên kết các yêu cầu phần mềm và các thành phần khác của hệ thống là sử dụng ma trận theo dõi các yêu cầu phần mềm.
- Các liên kết này thường được thể hiện giữa các thành phần:
· Các trường hợp sử dụng (yêu cầu phần mềm)
· Các yêu cầu chức năng (functional requirement)
· Các thành phần thiết kế (design element)
· Mã chương trình (code)
· Trường hợp kiểm thử (test case)
- Các mối liên kết co thể được phân chia:
· Một – Một
· Một – Nhiều
· Nhiều – Nhiều
- Các dạng biểu diễn ma trận:
· Lập bảng liên kết
· Lập ma trận liên kết
Quá trình lập ma trận:
- Xác định các mối liên kết và các khả nang lập ma trận
- Chọn dạng ma trận: tổng hợp hay chi tiết
- Chọn các chức năng/ các yêu cầu cần theo dõi
- Xác định phương pháp gán nhãn các yêu cầu
- Xác định nguồn các thông tin về các yêu cầu phục vụ cho sự liên kết
- Thông báo cho những người tham gia về sự liên kết
- Kiểm soát sự liên kết trong quá trình phát triển phần mềm.
Sử dụng ma trận quan hệ (Relationship Matrix): thông qua cửa sổ Relationship Matrix. Cho biết quan hệ giữa các đối tượng trong 2 package
1.54 Các chức năng của EA trợ giúp trong quản lý thay đổi yêu cầu phần mềm
Trả lời:
a. Auditing
Chức năng Audit cho phép bạn ghi lại những thay đổi mô hình trong EA. Nó ghi chi tiết những ai thay đổi một thành phần, khi nào và những gì được thay đổi, cùng với trạng thái trước của mô hình. Điều này có thể đặc biệt hữu dụng cho việc ghi lại lịch sử thay đổi của những mô hình yêu cầu.
Để cho phép chức năng này:
1. Từ menu chính chọn: View | Audit View, để mở
2. Chọn nút Audit Settings
3. Ta được cửa sổ Audit Settings:
4. Trong cửa sổ Audit Settings check vào enable Auditing như hình trên.
Chọn Ouput | Audit History cửa sổ sẽ hiển thị danh sách những thay đổi cho thành phần đã chọn
Lịch sử đầy đủ của sự thay đổi được hiển thị bởi loại nhân tố sử dụng Audit View.
Để biết thêm thông tin về việc sử dụng chức năng Auditing xem trợ giúp của EA:
Help | Help Contents | Model Management | Auditing
b. Using Baselines
Chức năng auditing nêu trên, cung cấp theo dõi liên tục và ghi các thay đổi của yêu cầu. chức năng Baseline Management cung cấp hỗ trợ thêm cho so sánh và kết nối các thay đổi. Nó cho phép đường cơ sở của một mô hình được tạo ra trên cơ sở định kì ( ví dụ theo tháng, giai đoạn, phiên bản hoặc xây dựng. Baseline có thể được so sánh với mô hình trạng thái hiện tại và thay đổi kết hợp chọn lọc.
Để biết thêm thông tin về thiết lập baseline và xem sự khác biệt, xem phần trợ giúp:
Help | Help Contents | Model Management | Baselines, Diffirencing and Merges
c. Change Requests and Issues on External Requirements
EA hỗ trợ việc ghi nhận những yêu cầu thay đổi dựa theo những yêu cầu. Nó có thể được định nghĩa sử dụng hai phương thức khác nhau:
- Sử dụng Maintenance View để liệt kê những thay đổi, khiếm khuyết, vấn đề và nhiệm vụ dựa theo mỗi nhân tố.
- Sử dụng những nhân tố tự chọn của kiểu “Issue” và “Change” liên kết với các yêu cầu ngoài được thay đổi
Mỗi một cách sử dụng khác nhau được liệt kê như sau:
Using the Maintenance View
Maintenance View có thể được sử dụng để ghi nhận những thay đổi dựa theo bất kì nhân tố hay gói nào. Nó cung cấp danh sách cho:
· Yếu tố khiếm khuyết
· Yếu tố thay đổi
· Yếu tố vấn đề
· Yếu tố nhiệm vụ
Chúng bao gồm các lĩnh vực để ghi “ bởi người nào và khi nào” yêu cầu đã được hoàn thành, cũng như tình trạng, mức độ, miêu tả và lịch sử.
Maintenance View có thể được truy cập từ menu chính sử dụng: View | Maintenance or (Alt+4)
Việc sử dụng chung cho quản lí yêu cầu là để ghi nhận chi tiết các vấn đề yêu cầu và những yêu cầu thay đổi theo bất kì nhân tố yêu cầu nào tồn tại.
Using Maintenance Elements for Changes and Issues
Những nhân tố bảo trì của EA gồm những nhân tố loại: Issue và Change. Có thể truy cập từ Toolbox | Custom
Những nhân tố bảo trì có thể được liên kết bằng cách sử dụng một kết nối tới bất kì nhân tố nào (ví dụ một yêu cầu ngoài) để hiển thị một thay đổi hay một vấn đề.
- Những nhân tố đó được lưu trữ trong gói chứa các yêu cầu liên quan hoặc trong một gói riêng biệt chứa một tập những sự thay đổi.
- Chúng có thể được liên kết tới những nhân tố yêu cầu trong biểu đồ thông thường hoặc sử dụng ma trận quan hệ.
- Những nhân tố có thể được tùy chỉnh như là một phần của một hồ sơ để bao gồm các đặc tính mở rộng.
Biểu đồ dưới đây minh họa việc sử dụng một nhân tố Issue được liên kết với một yêu cầu
Dưới đây là cùng một dữ liệu được hiển thị trong Element List cùng với các cửa sổ quan hệ hiển thị những nhân tố liên quan tới những vấn đề đã chọn:
Nội dung các bài tiểu luận
Bài tập 1. Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm
Bài tập 2. Các kỹ thuật phân tích các yêu cầu phần mềm.
Bài tập 3. Xây dựng tài liệu đặc tả yêu cầu phần mềm
Bài tập 4. Các kỹ thuật duyệt và kiểm soát yêu cầu phần mềm
Bài tập 5. Các kỹ thuật truy hồi và đánh giá chất lượng yêu cầu phần mềm.
[n1]Các yêu cầu đối với bản đặc tả
phan tich yeu cau phan mem anhthai2645
Trả lờiXóa