Cho hỏi: 1: Thực hiện đo lường ở slide 7 là đo cái gì vậy? 2: Chính thức hóa các yêu cầu thay đổi là ntn? 3.Các độ đo của phần mềm ảnh hưởng đến 2 mặt: Quản lý (thủ tục) Kỹ thuật (phương pháp) vậy nó ảnh hưởng ntn?
1. Nhân tố chất lượng ở nhóm trước vừa nói rồi nhé! có 11 nhân tố chia làm 3 loại gồm có: Loai1: Đặc trưng chức năng(tính đúng đắn, tính tin tưởng được, tnh hiệu quả, tính toàn vẹn, tính khả dụng) Loại 2: Khả năng đương đầu với thay đổi(tính bảo trì được, tính mềm dẻo, tính thử nghiệm được) và Loại 3: Khả năng thích nghi với môi trường mới( tính mang chuyển được, tính sử dụng lại được, tính liên tác được) 2. chuẩn dự định trước theo mình hiểu là các chuẩn (đặc tả) được đưa ra theo 1mức nào đó có các nhân tố và độ đo chất lượng được yêu cầu cho phần mềm.
Nhóm bạn không đánh số slide à. Mình xin hỏi Câu 1: Cải lượng chất lượng sản phẩm là gì? Câu 2: Trong 10 điều tối thiểu có điều Rà soát sản phẩm, không rà soát người làm nó nghĩa là gì?
1.slide 5 Các kỹ sư phần mềm, Nhà quản lý DA , Khách hàng ,Người bán hàng , có trách nhiệm ntn trong việc DBCLPM?Và trong những nhân tố đó thì nhân tố nào giữu vai trò qua trọng nhất? 2.slide 7 cho mình hỏi bước thực hiện đo lường tiến hành ntn, công cụ để thưc hiện nó 3.Tiến hành rà soát kỹ thuật chính thức là ntn? 4.ở slide 11 có nhắc đến 1 trong những mục tiêu quan trọng của SQA là Đánh giá ảnh hưởng của đổi thay về phương pháp luận và thủ tục lên CLPM, vậy cho mình hỏi phương pháp luận trong trường hợp này là gì vậy? p/s:nhóm bạn k đánh trang làm mình đếm đi đếm lại mấy lần :(
Câu số 1: Slide số 15: Chi phí để khắc phục khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn: thiết kế tốn 1.0, trước kiểm thử 6.5, trong kiểm thử 15, sau phân phối từ 65-100. Ở đấy đơn vị của các số liệu là gì? Các bạn ko nêu rõ nên rất khó hiểu. Câu số 2: Slide số 16: Lỗi còn tồn tại của các bước trước Lỗi phóng đại lên do các nhân tố ảnh hưởng của các lỗi bước trước Vậy hai cái này đều có điểm chung là “lỗi từ các bước trước”. Vậy điểm khác biệt là gì?
Người phát triển sử dụng theo quy tắc “cần-thì-biết” – trong suốt quá trình dự án Quy tắc CẦn-Thì-Biết là ntn?
Mình xin nêu ý kiến cá nhân như sau: Trong các công hiện nay, tùy thuộc vào dự án. Ví dụ như bên Fsoft. Người quản lý họ chia nhỉ dự án ra thành các phần và chia về cho các nhà phát triển. Người phát triển chỉ biết phần việc của mình là như thế mà không hề hay biết về các phần khác của dự án cũng như cái mà mình phát triển sẽ dành để kếp hợp với phần của người nào cũng như theo cách nào.
Như vậy được gọi là "cần-thì-biết". Họ hạn chế tối đa thông tin gẫy nhiễu cho người phát triển, chỉ những thông tin quan trọng mà chủ chốt được cung cấp
- Slide số 6: Các bạn có nói "người trong nhóm SQA phải đóng vai trò là người đại diện cho khách hàng xem xét CLPM với quan điểm của KH". Vậy quan điểm của khách hàng(có phải KH là khách hàng không nhỉ ^^) ở đây là gì? và nếu đứng trên quan điểm của khách hàng như vậy thì các yếu tố như "các nhân tố chất lượng" ,"các chuẩn dự định trước ", "thủ tục, phương pháp, kỹ thuật", khách hàng có thể biết được những yếu tố này không mà người trong nhóm SQA lại có thể đứng dưới quan điểm của họ để xem xét được?
Trả lời câu hỏi bạn Phạm Thanh Tùng Câu 1: Một sinh viên hỏi: “Chất lượng phần mềm là gì? Bạn em bảo em chất lượng nghĩa là phần mềm không có lỗi nhưng thầy giáo của em nói chất lượng là đạt tới sự thoả mãn của khách hàng. Ai đúng?"
Đáp: Có nhiều định nghĩa về chất lượng phần mềm tuỳ the các cách nhìn khác nhau. Từ cách nhìn của khách hàng, chất lượng có thể được xác định là việc đáp ứng nhu cầu của họ và đạt tới thoả mãn của họ. Từ cách nhìn của người phát triển, chất lượng có thể được định nghĩa là phần mềm được thiết kế tốt thế nào và sản phẩm tuân thủ tốt thế nào theo thiết kế đó (Đáp ứng yêu cầu đặc tả chức năng). Từ cách nhìn của người quản lí dự án, chất lượng có thể được xác định là đáp ứng các mục đích của dự án như chi phí, lịch biểu và yêu cầu của khách hàng. Từ cách nhìn của người chủ công ti, chất lượng được dựa trên khách hàng sẵn lòng trả bao nhiêu tiền cho sản phẩm. Từ cách nhìn hàn lâm hay cách nhìn của các giáo sư, chất lượng có thể được xác định như qui trình hiệu quả tạo ra sản phẩm mà không có lỗi nào và cung cấp giá trị đo được cho những người tạo ra sản phẩm và người dùng nó. Tôi chắc là còn nhiều định nghĩa nữa.
Bởi vì có nhiều định nghĩa, mọi người đều đúng theo góc nhìn của họ. Nếu sản phẩm phần mềm đầy lỗi, thì không ai sẽ mua nó (góc nhìn của người chủ công ti). Nếu phần mềm không đáp ứng nhu cầu của người dùng hay không thực hiện tương ứng, thì khách hàng sẽ không hài lòng và có thể không muốn làm kinh doanh với công ti thêm nữa (cách nhìn của khách hàng). Nếu phần mềm mất quá lâu mới dựng xong, không đáp ứng lịch biểu, vượt quá ước lượng chi phí, với nhiều lỗi thì việc làm của người quản lí dự án có thể thành vấn đề nghiêm trọng (góc nhìn của người quản lí dự án). Nếu phần mềm không được thiết kế tốt, đầy vấn đề và không đáp ứng đặc tả thiết kế thì người phát triển sẽ phải chữa chúng, hay làm lại nó. Trong trường hợp đó họ có thể không có khả năng để giữ việc làm lâu (cách nhìn của người phát triển). Nếu phần mềm không được phát triển theo qui trình được xác định, đầy lỗi và không cung cấp giá trị đo được cho người dùng thì có thể chương trình đào tạo là không tốt (góc nhìn hàn lâm). Tuy nhiên, không lỗi chỉ là "ước muốn", không thể có không lỗi được dù bạn kiểm thử bao nhiêu lần cho phần mềm. Không ai có thể đảm bảo rằng phần mềm không có lỗi.
Ở slide số 21: "2. Lập chương trình nghị sự và duy trì nó" nghĩa là gì? Ở slide số 22 "6. Giới hạn số người tham dự và kiên trì các dự kiến", cho mình hỏi "kiên trì các dự kiến" ở đây có nghĩa là gì?
Trả Lời câu hỏi bạn Trịnh Minh Vương: -Mục tiêu của việc rà soát kỹ thuật chính thức FTR: Phát hiện các lỗi trong chức năng, trong logic và trong triển khai Kiểm thử sự phù hợp của phần mềm và yêu cầu Khẳng định phần đã đạt yêu cầu Đảm bảo PM phù hợp với các chuẩn đã định sẵn Đảm bảo PM được phát triến một cách nhất quán Làm cho dự án dễ quản lý hơn Dùng làm cơ sở huấn luyện cho người phát triển PM -Lợi ích của việc rà soát phần mềm: Sớm phát hiện ra các khuyết điểm của PM để chỉnh sửa Các nghiên cứu của công nghệ phần mềm (Nippon Electric, Mitre Corp…) đã chỉ ra: các hoạt động thiết kế tạo ra 50-60% các khiếm khuyết phần mềm Chi phí để khắc phục khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn: thiết kế tốn 1.0, trước kiểm thử 6.5, trong kiểm thử 15, sau phân phối từ 65-100
- Cũng giống như một dự án bình thường. Khi bàn giao dự án, sẽ có phần nghiệm thu. Ở đây 1 phần mềm được rà soát sẽ đc phát hiện những lỗi nhỏ, hay lỗi phát sinh. Như vậy so với 1pm chưa đc rà soát thì khả năng xuất hiện lỗi của pm đã đc rà soát là ít hơn.
. Câu 1: Thật sự là m cũng chưa rõ về đơn vị của các số đó, ý này m lấy trong tài liệu của thày. Câu này có lẽ nhóm sẽ trả lời trong buổi thuyết trình.
.Câu 2: Theo ý m hiểu thì điểm khác nhau ở đây là "các nhân tố" đúng như trong câu. Một cái là lỗi trực tiếp, một cái là lỗi phát sinh do các nhân tố của giai đoạn trc. :v
Quan điểm của khách hàng về phần mềm sẽ tùy thuộc vào từng khách hàng . Khách hàng sẽ yêu cầu phần mềm của mình sẽ như thế nào , có tính năng gì , giao diện có dễ sử dụng với KH không , Bạn thử đặt mình vào vị trí bạn muốn mua 1 phần mềm thì bạn sẽ hiểu .
Do là bản demo nên bạn thông cảm !! Mình xin trả lòi câu 1 của bạn. Các kỹ sư phần mềm, Nhà quản lý DA , Khách hàng ,Người bán hàng , có trách nhiệm xem xet phần mem có đáp ứng được các nhân tố chất lượng,có tuân theo các tiêu chẩn dự định ra không,các thủ tục, phương pháp, kỹ thuật có thực hiện đúng vai trò của nó trong hoạt động SQA. Mình thấy nhân tố nào cũng có nhiệm vụ riêng của nó!! va theo tơ thấy có thể nói Những người trong nhóm SQA la nhân tố giãu vai trò quan trong nhất nhưng song hanh cung đó là 2 nhân tố cũng rất quan trong la Các kỹ sư phần mềm va Nhà quản lý DA.
Bạn có thể xem ở slide 13 của nhóm mình: việc xem xét rà soát, đánh giá sản phẩm được tiến hành mỗi giai đoạn, để phát hiện ra những khiếm khuyết cần sửa chữa trước khi sang giai đoạn sau. Và sản phẩm chính là dự án chúng ta thực hiện.
Thử phát xem có đc k?
Trả lờiXóanhóm bạn k đánh số slide nên mình tạm cho là slide 5..:D
Trả lờiXóacó thể cho tớ hiểu thêm về: Nhân tố chất lượng và Chuẩn dự định trước là ntn?
Cho hỏi:
Trả lờiXóa1: Thực hiện đo lường ở slide 7 là đo cái gì vậy?
2: Chính thức hóa các yêu cầu thay đổi là ntn?
3.Các độ đo của phần mềm ảnh hưởng đến 2 mặt: Quản lý (thủ tục) Kỹ thuật (phương pháp) vậy nó ảnh hưởng ntn?
Người phát triển sử dụng theo quy tắc “cần-thì-biết” – trong suốt quá trình dự án
Trả lờiXóaQuy tắc CẦn-Thì-Biết là ntn?
1. Nhân tố chất lượng ở nhóm trước vừa nói rồi nhé! có 11 nhân tố chia làm 3 loại gồm có:
Trả lờiXóaLoai1: Đặc trưng chức năng(tính đúng đắn, tính tin tưởng được, tnh hiệu quả, tính toàn vẹn, tính khả dụng)
Loại 2: Khả năng đương đầu với thay đổi(tính bảo trì được, tính mềm dẻo, tính thử nghiệm được)
và Loại 3: Khả năng thích nghi với môi trường mới( tính mang chuyển được, tính sử dụng lại được, tính liên tác được)
2. chuẩn dự định trước theo mình hiểu là các chuẩn (đặc tả) được đưa ra theo 1mức nào đó có các nhân tố và độ đo chất lượng được yêu cầu cho phần mềm.
Được =)))))))
Trả lờiXóaNhóm bạn không đánh số slide à.
Trả lờiXóaMình xin hỏi
Câu 1:
Cải lượng chất lượng sản phẩm là gì?
Câu 2:
Trong 10 điều tối thiểu có điều Rà soát sản phẩm, không rà soát người làm nó nghĩa là gì?
Minh xin trả lời câu hỏi của bạn Ngân:
Trả lờiXóa1.thực hiện đo lường là : tìm các khả năng có xảy ra trước và sau khi đưa sản phẩm ra ứng dụng.
2. chính thức hoá yêu cầu thay đổi là : khi 1 dự án khi thực hiện sẽ có nhiều yêu cầu thay đổi từ người thực hiện lẫn khách hàng và cái cái yêu cầu đc chấp nhận là sẽ thực hiện chính là chính thức hoá yêu cầu thay đổi.
đây mới là demo nên chưa đánh số trang. Nhưng nếu bạn down về sẽ thấy số trang, bọn tớ chưa đánh số trang với mong muốn các bạn down về để lấy tài liệu..
Trả lờiXóaMột phần mềm được thực hiện rà soát và một phần mềm chưa qua rà soát thì có gì khác nhau?
Trả lờiXóaTrịnh Minh Vương
1.slide 5 Các kỹ sư phần mềm, Nhà quản lý DA , Khách hàng ,Người bán hàng , có trách nhiệm ntn trong việc DBCLPM?Và trong những nhân tố đó thì nhân tố nào giữu vai trò qua trọng nhất?
Trả lờiXóa2.slide 7 cho mình hỏi bước thực hiện đo lường tiến hành ntn, công cụ để thưc hiện nó
3.Tiến hành rà soát kỹ thuật chính thức là ntn?
4.ở slide 11 có nhắc đến 1 trong những mục tiêu quan trọng của SQA là Đánh giá ảnh hưởng của đổi thay về phương pháp luận và thủ tục lên CLPM, vậy cho mình hỏi phương pháp luận trong trường hợp này là gì vậy?
p/s:nhóm bạn k đánh trang làm mình đếm đi đếm lại mấy lần :(
Câu số 1:
Trả lờiXóaSlide số 15:
Chi phí để khắc phục khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn: thiết kế tốn 1.0, trước kiểm thử 6.5, trong kiểm thử 15, sau phân phối từ 65-100.
Ở đấy đơn vị của các số liệu là gì? Các bạn ko nêu rõ nên rất khó hiểu.
Câu số 2:
Slide số 16:
Lỗi còn tồn tại của các bước trước
Lỗi phóng đại lên do các nhân tố ảnh hưởng của các lỗi bước trước
Vậy hai cái này đều có điểm chung là “lỗi từ các bước trước”. Vậy điểm khác biệt là gì?
Người phát triển sử dụng theo quy tắc “cần-thì-biết” – trong suốt quá trình dự án
Trả lờiXóaQuy tắc CẦn-Thì-Biết là ntn?
Mình xin nêu ý kiến cá nhân như sau: Trong các công hiện nay, tùy thuộc vào dự án. Ví dụ như bên Fsoft. Người quản lý họ chia nhỉ dự án ra thành các phần và chia về cho các nhà phát triển. Người phát triển chỉ biết phần việc của mình là như thế mà không hề hay biết về các phần khác của dự án cũng như cái mà mình phát triển sẽ dành để kếp hợp với phần của người nào cũng như theo cách nào.
Như vậy được gọi là "cần-thì-biết". Họ hạn chế tối đa thông tin gẫy nhiễu cho người phát triển, chỉ những thông tin quan trọng mà chủ chốt được cung cấp
- Slide số 5: Các bạn có thể nói rõ vai trò của từng người có trách nhiệm trong việc đảm bảo chất lượng phần mềm được không?
Trả lờiXóa- Slide số 5: Cho mình hỏi những người trong nhóm SQA là những ai?
Trả lờiXóa- Slide số 6: Các bạn có nói "người trong nhóm SQA phải đóng vai trò là người đại diện cho khách hàng xem xét CLPM với quan điểm của KH". Vậy quan điểm của khách hàng(có phải KH là khách hàng không nhỉ ^^) ở đây là gì? và nếu đứng trên quan điểm của khách hàng như vậy thì các yếu tố như "các nhân tố chất lượng" ,"các chuẩn dự định trước ", "thủ tục, phương pháp, kỹ thuật", khách hàng có thể biết được những yếu tố này không mà người trong nhóm SQA lại có thể đứng dưới quan điểm của họ để xem xét được?
Trả lờiXóaTrong một loạt những hoạt động của SQA từ slide 8 -> 12 thì hoạt động nào là hoạt động chính, quan trọng nhất của SQA?
Trả lờiXóa-Trong SLide số 19, tại sao cuộc họp rà soát không nên < 2h?, nếu rà soát xong trước 2h thì có phải thực hiện rà soát lại không?
Trả lờiXóaTrả lời câu hỏi bạn Phạm Thanh Tùng
Trả lờiXóaCâu 1:
Một sinh viên hỏi: “Chất lượng phần mềm là gì? Bạn em bảo em chất lượng nghĩa là phần mềm không có lỗi nhưng thầy giáo của em nói chất lượng là đạt tới sự thoả mãn của khách hàng. Ai đúng?"
Đáp: Có nhiều định nghĩa về chất lượng phần mềm tuỳ the các cách nhìn khác nhau. Từ cách nhìn của khách hàng, chất lượng có thể được xác định là việc đáp ứng nhu cầu của họ và đạt tới thoả mãn của họ. Từ cách nhìn của người phát triển, chất lượng có thể được định nghĩa là phần mềm được thiết kế tốt thế nào và sản phẩm tuân thủ tốt thế nào theo thiết kế đó (Đáp ứng yêu cầu đặc tả chức năng). Từ cách nhìn của người quản lí dự án, chất lượng có thể được xác định là đáp ứng các mục đích của dự án như chi phí, lịch biểu và yêu cầu của khách hàng. Từ cách nhìn của người chủ công ti, chất lượng được dựa trên khách hàng sẵn lòng trả bao nhiêu tiền cho sản phẩm. Từ cách nhìn hàn lâm hay cách nhìn của các giáo sư, chất lượng có thể được xác định như qui trình hiệu quả tạo ra sản phẩm mà không có lỗi nào và cung cấp giá trị đo được cho những người tạo ra sản phẩm và người dùng nó. Tôi chắc là còn nhiều định nghĩa nữa.
Bởi vì có nhiều định nghĩa, mọi người đều đúng theo góc nhìn của họ. Nếu sản phẩm phần mềm đầy lỗi, thì không ai sẽ mua nó (góc nhìn của người chủ công ti). Nếu phần mềm không đáp ứng nhu cầu của người dùng hay không thực hiện tương ứng, thì khách hàng sẽ không hài lòng và có thể không muốn làm kinh doanh với công ti thêm nữa (cách nhìn của khách hàng). Nếu phần mềm mất quá lâu mới dựng xong, không đáp ứng lịch biểu, vượt quá ước lượng chi phí, với nhiều lỗi thì việc làm của người quản lí dự án có thể thành vấn đề nghiêm trọng (góc nhìn của người quản lí dự án). Nếu phần mềm không được thiết kế tốt, đầy vấn đề và không đáp ứng đặc tả thiết kế thì người phát triển sẽ phải chữa chúng, hay làm lại nó. Trong trường hợp đó họ có thể không có khả năng để giữ việc làm lâu (cách nhìn của người phát triển). Nếu phần mềm không được phát triển theo qui trình được xác định, đầy lỗi và không cung cấp giá trị đo được cho người dùng thì có thể chương trình đào tạo là không tốt (góc nhìn hàn lâm). Tuy nhiên, không lỗi chỉ là "ước muốn", không thể có không lỗi được dù bạn kiểm thử bao nhiêu lần cho phần mềm. Không ai có thể đảm bảo rằng phần mềm không có lỗi.
Ở slide số 21:
Trả lờiXóa"2. Lập chương trình nghị sự và duy trì nó" nghĩa là gì?
Ở slide số 22
"6. Giới hạn số người tham dự và kiên trì các dự kiến", cho mình hỏi "kiên trì các dự kiến" ở đây có nghĩa là gì?
Câu 2 : Không rà soát người làm ra nó chính là k rà soát người làm ra sản phẩm phần mềm ý
Trả lờiXóaPhạm Thanh Tùng
Trả lờiXóaCâu 2:
Không rà soát người làm ra nó chính là không rà soát người làm ra sản phẩm phần mềm đấy
Trả Lời câu hỏi bạn Trịnh Minh Vương:
Trả lờiXóa-Mục tiêu của việc rà soát kỹ thuật chính thức FTR:
Phát hiện các lỗi trong chức năng, trong logic và trong triển khai
Kiểm thử sự phù hợp của phần mềm và yêu cầu
Khẳng định phần đã đạt yêu cầu
Đảm bảo PM phù hợp với các chuẩn đã định sẵn
Đảm bảo PM được phát triến một cách nhất quán
Làm cho dự án dễ quản lý hơn
Dùng làm cơ sở huấn luyện cho người phát triển PM
-Lợi ích của việc rà soát phần mềm:
Sớm phát hiện ra các khuyết điểm của PM để chỉnh sửa
Các nghiên cứu của công nghệ phần mềm (Nippon Electric, Mitre Corp…) đã chỉ ra: các hoạt động thiết kế tạo ra 50-60% các khiếm khuyết phần mềm
Chi phí để khắc phục khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn: thiết kế tốn 1.0, trước kiểm thử 6.5, trong kiểm thử 15, sau phân phối từ 65-100
aaaaaa
Trả lờiXóa- Cũng giống như một dự án bình thường. Khi bàn giao dự án, sẽ có phần nghiệm thu. Ở đây 1 phần mềm được rà soát sẽ đc phát hiện những lỗi nhỏ, hay lỗi phát sinh. Như vậy so với 1pm chưa đc rà soát thì khả năng xuất hiện lỗi của pm đã đc rà soát là ít hơn.
Trả lờiXóaNhungwc người trong nhom SQA gôm:Các kỹ sư phần mềm , Nhà quản lý DA Khách hàng , Người bán hàng , Những người trong nhóm SQA
Trả lờiXóa. Câu 1: Thật sự là m cũng chưa rõ về đơn vị của các số đó, ý này m lấy trong tài liệu của thày. Câu này có lẽ nhóm sẽ trả lời trong buổi thuyết trình.
Trả lờiXóa.Câu 2: Theo ý m hiểu thì điểm khác nhau ở đây là "các nhân tố" đúng như trong câu. Một cái là lỗi trực tiếp, một cái là lỗi phát sinh do các nhân tố của giai đoạn trc. :v
Quan điểm của khách hàng về phần mềm sẽ tùy thuộc vào từng khách hàng . Khách hàng sẽ yêu cầu phần mềm của mình sẽ như thế nào , có tính năng gì , giao diện có dễ sử dụng với KH không , Bạn thử đặt mình vào vị trí bạn muốn mua 1 phần mềm thì bạn sẽ hiểu .
Trả lờiXóaDo là bản demo nên bạn thông cảm !!
Trả lờiXóaMình xin trả lòi câu 1 của bạn.
Các kỹ sư phần mềm, Nhà quản lý DA , Khách hàng ,Người bán hàng , có trách nhiệm xem xet phần mem có đáp ứng được các nhân tố chất lượng,có tuân theo các tiêu chẩn dự định ra không,các thủ tục, phương pháp, kỹ thuật có thực hiện đúng vai trò của nó trong hoạt động SQA.
Mình thấy nhân tố nào cũng có nhiệm vụ riêng của nó!! va theo tơ thấy có thể nói Những người trong nhóm SQA la nhân tố giãu vai trò quan trong nhất nhưng song hanh cung đó là 2 nhân tố cũng rất quan trong la Các kỹ sư phần mềm va Nhà quản lý DA.
Cả 7 hoạt động đều là chính. Và quan trọng như nhau
Trả lờiXóaMục tiêu của SQA? các hoạt động chính đảm bảo chất lượng phần mềm là các hoạt động nào?
Trả lờiXóaKhi nào cần tiến hành rà soát? cần rà soát những sản phẩm gì?
Trả lờiXóaMình xin trl bạn là 2h là 1 con số tương đối mà sau nhiều lần ra soát chất lượng ngta đưa ra. nếu sấp sỉ hoặc hơn 2h ta có thể dừng còn sớm hơn quá nhiều chúng ta sẽ rà soát lại. và theo mình thì sự chênh lệch quá nhiều sẽ hiếm khi xảy ra.
Trả lờiXóaBạn có thể xem ở slide 13 của nhóm mình:
Trả lờiXóaviệc xem xét rà soát, đánh giá sản phẩm được tiến hành mỗi giai đoạn, để phát hiện ra những khiếm khuyết cần sửa chữa trước khi sang giai đoạn sau.
Và sản phẩm chính là dự án chúng ta thực hiện.
Câu hỏi thứ 2 của bạn cũng chính là câu trả lời cho câu hỏi thứ nhất đó a. Mục tiêu của SQA chính là đảm bảo chất lượng phần mêm.
Trả lờiXóaGồm 7 hoạt động chính ở slide 7 bạn có thể tham khảo thêm.