CNPM

May 4, 2018 | Author: Anonymous | Category: Documents
Report this link


Description

4. Hiểu thế nào là các phương pháp trong kỹ nghệ phần mềm? Nêu các thành phần chính của một phương pháp. Các phương pháp trong kĩ nghệ phần mềm là chỉ ra cách thực hiện những công việc cụ thể như: phân tích yêu cầu, thiết kế, xây dựng chương trình, kiểm thử,… VD: Phương pháp hướng đối tượng: Pha yêu cầu,Pha đặc tả/phân tích, Pha thiết kế, Pha cài đặt, Pha tích hợp, Pha bảo trì, Pha loại bỏ. 5. Công cụ cho kỹ nghệ phần mềm là gì? Có những loại công cụ nào? CASE là gì? Ý nghĩa của nó. Công cụ (tool) cung cấp các hỗ trợ tự động hay bán tự động đối với chu trình và phương pháp Các loại công cụ: + Công cụ phân tích(analytical tool) + công cụ phân loại(case Taxonomy) + Case tool Các công cụ được tích hợp tạo thành Case(Computer Aided Softwave Engineering) Là các hệ thống được sử dụng để hỗ trợ các hoạt động trong quy trình phát triển phần mềm. Ý nghĩa: + giúp đỡ các kĩ sư phần mềm những công việc khó khăn trong việc phát triển phần mềm bao gồm cả sự sáng tạo, cách tổ chức chẳng hạn như kế hoạch, hợp đồng, đặc điểm kĩ thuật,mã nguồn, thông tin quản lí 7. Tiến trình phần mềm là gì? Mô hình tiến trình là gì? Hãy trình bày mô hình của một số tiến trình cơ bản. Tiến trình phần mềm là “phương cách” sản xuất ra phần mềm Mô hình tiến trình là phương pháp phát triển or sản xuất ra phần mềm. Các tổ chức khác nhau có mô hình phát triển phần mềm khác nhau. Evolution-tree model(tiến hóa) mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau,những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng trong những phiên bản sau .:Ưu:Chú trọng việc tái sử dụng, 1 phần của hệ thống có thể phát triển ngay trong giai đoạn phân tích, thiết kế. Nhược: Làm chậm quá trình phát triển yêu cầu, giảm sự chú ý đến các công việc trung gian dẫn đến hệ thống kém. Iterative and incremental life cycle model(Lặp và tăng dần)Ưu: Giảm rủi ro sớm trong chu kỳ phát triển phần mềm. Những yêu cầu quan trọng thường được phát triển và chuyển đến người sử dụng sớm.Nhược: Tổng chi phí lập kế hoạch phát triển cho toàn hệ thống có thể cao hơn, Các yêu cầu về kế hoạch và hoạt động trong qui trình cụ thể sẽ phức tạp hơn. Code-and-fix model(xây và sửa): không thiết kê, không thông số kĩ thuật. Là cách dễ nhất để phát triển phần mềm nhưng chi phí đắt nhất Waterfall model(Thác nước):đặc trưng bởi lặp phản hồi và điều khiển tài liệu. Ưu: tài liệu chi tiết tỉ mỉ, dễ bảo trì hơn so với code-and-fix. Nhược: Tài liệu dễ gây nhàm chán khó hiểu với khách hàng Rapid prototyping(Bản mẫu nhanh): phần mềm đc phát triển theo dạng tuyến tính tiến hành thừ khi làm bản mẫu nhanh đến khi giao sản phẩm, ko có vòng lặp trong mô hình này. Ưu: nhanh, tăng tốc độ phát triển sản phẩm. Nhược:Xây dựng tài liệu đặc tả mà k tham khảo ý kiến khách hàng, dùng tài liệu đó để thiết kế mà k cập nhật yêu cầu khách hàng. Open-Source Life-Cycle Model(nguồn mở): 1 cá nhân xây dựng phiên bản đầu tiên rồi đưa lên mạng. người dùng trở thành người đồng phát triển để mở rộng sản phẩm Ưu: Nhươc: Agile(Tăng tốc)k có moo hình cụ thể mà dựa trên 1 số nguyên tắ như: Ít nhấn mạnh vào phân tích thiết kê,Phần mềm đc coi là tài liệu quan trọng,Đáp ứng đc thay đổi, Hợp tác chặt chẽ với khách hàng. Ưu:Hoạt động tốt khi yêu cầu của khách hàng k rõ ràng Nhược: Phù hợp với dự án quy mô nhỏ Synchronize-and Stabilize Model(Đồng bộ và ổn định):Phỏng vấn khách hàng, chia dự án thành nhiều phần nhỏ và phát triển song song đồng bộ(thử nghiệm, gỡ lỗi) vào cuối thời hạn, và ổn định(đóng băng) khi kết thúc dự án Ưu:Đáp ứng đc nhu cầu người dùng, phù hợp vs phần mềm lớn Nhược: k phổ biến,nhiều lỗi tiềm ẩn Spiral model(xoắn ốc): trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản chất của mô hình lặp.Trong mô hình này, việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung vào thiết kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung Ưu: Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi “spiral” để tăng mức độ tin cậy của dự án. Kết hợp những tính chất tốt nhất của mô hình waterfall và tiến hóa. Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi “spiral”. Nhược: Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro. Cần có kỹ năng tốt về phân tích rủi ro. 10. Chất lượng phần mềm là gì? Các tiêu chí của chất lượng phần mềm. Chất lượng phần mềm là khả năng đáp ứng toàn diện nhu cầu toàn diện của người dùng về tính năng và công dụng đc nêu ra 1 cách tường minh or k tường minh Các tiêu chí của chất lượng phần mềm theo chuẩn ISO: + Tính chức năng: gồm: phù hợp, đúng đắn, liên kết giữa con người-hệ thống-dữ liệu,bảo mật + Tính tin cậy: gồm: xử lý tin cậy, khả năng khôi phục dữ liệu, tìm lỗi- báo lỗi + tính tiện lợi:Dễ hiểu, dễ sử dụng + Tính hiệu quả: Quản lý nguồn tài nguyên, quản lý thời gian + Tính duy trì:chạy ổn định, khả năng ptich dữ liệu, thay đổi phù hợp, khẳ năng kiểm tra + Tính dễ mang theo: khă năng cài đặt,thay đổi, nâng cấp, thích hợp với nhiều cấu hình 11. Bài tập lớn của anh/chị làm theo mô hình vòng đời nào? Tại sao? Gặp khó khăn/thuận lợi gì khi làm theo cách đó? 14. process là gì? Khác gì với workflow? Process(Tiến trình):Là phương cách sản xuất ra phần mềm. Process khác với workflow là + bao gồm nhiều quy trình trong việc tạo ra 1 phần mềm + Có thể có nhiều mô hình khác nhau trong 1 process + Process có thể sử dụng mô hình workflow để làm ra phần mềm 15. workflow là gì? Khác gì với process? Workflow(Luồng công việc)mô tả chuỗi các hoạt động trong 1 quy trình phần mềm. Khác với process là Là 1 cách thực hiện cụ thể của process Các workflow ko phân rõ 1 việc phân tích, đặc tả, thiết kế nằm trong workflow nào, mà mỗi workflow đều bao gồm tất cả các việc đó (chỉ chú trọng vào việc nào trong workflow nào). Quy định cụ thể các workflow trong 1 process 16. Tại sao không có pha kiểm thử? Vì kiểm thử là hoạt động được thực hiện trong mọi pha của sản xuất phần mềm + Kiểm tra(verification): Kiểm tra sau mỗi pha + Kiểm định(validation):Thực hiện trc khi giao sản phẩm cho khách hàng 17. Tại sao không có pha làm tài liệu? Vì Mọi pha phải đc viết tài liệu trc khi bắt đầu 1 pha mới vì + Tài liệu bị hoãn lại thì se k bao giờ hàn thành + Cá nhân chịu trách nhiệm trong pha trc có thể chuyển sang bộ phận khác + SP thường xuyên thay đổi khi phát triển nên cần tài liệu để ghi lại điều này 18. Tại sao không có pha lập kế hoạch? Chúng ta k thể lập kế hoạch vào đầu dự án vì chúng ta chưa biết chính xác những gì mà chúng ta sẽ xây dựng. Chúng ta chỉ có thể lập kế hoạch sơ bộ cho pha yêu cầu và pha phân tích khi bắt đầu mỗi dự án. Kế hoạch quản lý dự án phần mềm chỉ đc đưa ra khi các chi tiết kỹ thuật mà khách hàng đưa ra đã được hoàn tất. 19. Nếu không áp dụng các mô hình vòng đời phần mềm thì có phát triển được phần mềm không? Tại sao? Nếu không áp dụng các mô hình vòng đời thì rất khó để phát triển phần mềm. Vì + khó kiểm soát đc phần mềm(nhiều lỗi tiềm ẩn, khả năng gắn kết các module kém) + Khả năng tái sử dụng module kém + Chi phí để sản xuất 1 phần mềm cao 20. Tại sao người ta phải dùng nhiều mô hình vòng đời khác nhau để phát triển phần mềm? + Các mô hình vòng đời có các ưu điểm, nhược điểm khác nhau phù hợp với những điều kiện phát triển phần mềm khác nhau. + Quy mô của các dự án phát triển phần mềm khác nhau nên đòi hỏi các mô hình vòng đời khác nhau phù hợp với kinh phí phát triển dự án đó 21. Yêu cầu phần mềm là gì? Phân biệt yêu cầu và nhu cầu. Phân loại yêu cầu theo đối tượng sử dụng. Yêu cầu của phần mềm là đặc tả lại các yêu cầu của khác hàng đối với phần mềm sao cho phù hợp nhất vs phần mềm. Yêu cầu là cái khách hàng cần - nhu cầu là cái khác hàng muốn Phân loại yêu cầu theo đối tượng sử dụng: + yêu cầu đối với người dùng + Yêu cầu đối với khách hàng + Yêu cầu đối với người lập trình phần mềm + Yêu cầu đối với người quản trị phần mềm 22. Ý nghĩa của scenario(kịch bản) và ngoại lệ? + Hiểu rõ thêm về chức năng của hệ thống mà ta xây dựng + từ scenario ta làm rõ được chức năng của use case và sự tương tác giữa người dùng/ người quản trị với hệ thống + Từ scenario ta cũng xác định được các ngoại lệ và cách xử lí ngoại lệ của hệ thống. 24. Ý nghĩa của sơ đồ cộng tác? + Biểu diễn mối quan hệ giữa các đối tượng; các đối tượng với các tác nhân + Nhấn mạnh vai trò của các đối tượng trong tương tác + Cũng có các messgage giống với biểu đồ tuần tự nhưng các đối tượng đc đặt 1 cách tự do trong biểu đồ 25. Ý nghĩa của sơ đồ lớp? + Mối tương tác giữa các đối tượng trong hệ thống sẽ đc thể hiện thông qua mối quan hệ giữa các lớp + Mô tả 1 hướng nhìn tĩnh về 1 hệ thống bằng các lớp, các thuộc tính, phương thức của lớp, và mỗi quan hệ giữa chúng. 26. Phân loại yêu cầu theo tính chất của nó? Giải thích nội dung mỗi loại. Yêu cầu phi chức năng có thể phân cấp như thế nào? Cho ví dụ về mỗi loại. Yêu cầu chức năng: Liên quan đến chức năng của phần mềm VD:tính lương theo 1 công thức nào đó Yêu cầu phi chức năng: Mô tả các tính chất của phần mềm +Tính bảo trì đươc: Có khả năng bảo trì +Tính tin cậy: khả năng khôi phục dữ liệu, phát hiên lỗi, báo lỗi + Liên quan đến môi trường mà phần mềm sẽ chạy:VD: có phần mềm chỉ chạy được trên 1 số HĐH nhất định Câu 27: Trình bày tiến trình kỹ nghệ yêu cầu. Nội dung nghiên cứu khả thi là gì? I. Kĩ nghệ yêu cầu. Là một hoạt động nhằm thu thập vào quản lý yêu cầu nó được mô tả như sau: Kĩ nghệ yêu cầu Phát triển yêu cầu Quản lý yêu cầu Phát hiện Quản lý yêu cầu được hiểu là “Thiết lập và duy trì một thỏa thuận với khách hàng về các yêu cầu của dự án hieenhiện phần mềm”. Quản lý yêu cầu gồm các bước sau: Phân tích Kiểm • Xác định giới hạn yêu cầu phần mềmĐặc tả • Duyệt các giới hạn của phần mềm thử • Quản lý các thay đổi yêu cầu phần mềm Nghiên cứu khả thi: Nhằm xác định xem dự án phần mềm thực hiện có khả thi hay không, tức là đáp ứng các yêu cầu về kinh tế, thời gian, khả năng triển khai...... 1. Khả thi về kinh tế: chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống được xây dựng đem lại. 2. Khả thi về kỹ thuật(rủi ro, tài nguyên, công nghệ....): khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng tới khả năng đạt tới một hệ thống chấp nhận được. 3. Khả thi về pháp lý: nghiên cứu và đưa ra phán quyết về có hay không sự xâm phạm, vi phạm pháp luật hay khó khăn pháp lý từ việc xây dựng và vận hành hệ thống. 4. Tính khả thi về hoạt động: đánh giá tính khả thi của việc vận hành hệ thống. Câu 28: Trình bày các bước của tiến trình phát hiện và phân tích yêu cầu. Trình bày một số kỹ thuật để nhận biết và phân tích yêu cầu. Phân tích yêu cầu :  Làm rõ yêu cầu: 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: 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: 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 use case. Một vài kĩ thuật Kĩ thuật phỏng vấn. (Tạo ra một tập các câu hỏi để hỏi khách hàng.........) Kĩ thuật hội thảo. (Xây dựng một buổi hội thảo để tập hợp các yêu cầu....) Kĩ thuật Use-Case (Dùng biểu đồ use-case để biểu diễn các yêu cầu từ từng đối tượng) Kĩ thuật BrainStorming (Làm việc theo nhóm, đưa ra cùng một tập các câu hỏi cho các thành viên trả lời, rồi thảo luận....) Câu 30: Trình bày phương pháp phân tích yêu cầu theo hướng đối tượng. Phân tích yêu cầu là: quá trình mịn hóa và mở rộng tập yêu cầu ban đầu Tập yêu cầu ban đầu gốm: Yêu cầu chức năng và yêu cầu phi chức năng Các HĐ: - Theo dõi đc: Các yêu cầu phải đc đánh số để nhóm SQA(nhóm quản lí chất lượng phần mềm)có thể theo dõi đc trong đặc tả, thiết kế, mã hóa - Đưa cho khách hàng kiểm tra và xếp thứ hạng ưu tiên các yêu cầu trong tài liệu, yêu cầu nào k đúng, yêu cầu nào cần bỏ… - Gặp các cá nhân đã phỏng vấn để rà soát lại yêu cầu, các yêu cầu bỏ đi, các yêu càu thêm vào… - Xây dựng bản mẫu nhanh để thể hiện chức năng quan trọng của sản phẩm 31. Thế nào là lớp giao diện? Lớp này thường tương tác với các lớp nào? Lớp giao diện là lớp có chức năng tương tác giữa môi trường bên ngoài và phần mềm. Thường là các giao diện vào ra với người dung. Lớp này tương tác với lớp điều khiển để trao đổi thông tin giữa người dung và hệ thống. 32. Thế nào là lớp điều khiển? Lớp này thường tương tác với các lớp nào? Lớp điều khiển là lớp thực hiện các chức năng lien quan đến tính toán phức tạp hoặc thuật toán. Thường là các chức năng tính toán hoặc xử lý thông tin. Lớp này tương tác với cả 2 lớp thực thể và giao diện lầm nhiệm vụ tính toán, xử lý thong tin. 33. Thế nào là lớp thực thể? Lớp này thường quan hệ với các lớp nào? Lớp thực thể là lớp liên quan đến dữ liệu tĩnh(thông tin tồn tại lâu dài), không liên quan đến usecase. Thường là các danh từ trong kịch bản. Lớp này thường tương tác với lớp điều khiển để cung cấp và lưu trữ thông tin. 34. Scenario và sơ đồ tuần tự có liên hệ gì với nhau? Biểu đồ tuần tự minh hoạ các đối tượng tương tác với nhau ra sao. Bao gồm 1 trục nằm dọc chỉ thời gian, trụ nằm ngang chỉ ra một tập hợp các đối tượng. Một biểu đồ tuần tự nêu lên sự tương tác trong một kịch bản (Scenario) : Sự tương tác xảy ra tại một thời điểm nào đó trong quá trình thực thi của hệ thống. Ngược lại, kịch bản chính là nội dung của sự tương tác của các đối tượng được thể hiện trong biểu đồ tuần tự 35. Scenario và sơ đồ lớp có quan hệ gì với nhau? Một nhóm đối tượng có chung một số thuộc tính và phương thức sẽ tạo thành một lớp. Mối tương tác giữa các đối tượng trong hệ thống sẽ được biểu diễn thông qua mối quan hệ giữa các lớp. Biểu đồ lớp được tạo thành từ các lớp (bao gồm các thuộc tính và các phương thức) cùng với các mối quan hệ của nó. Mỗi lớp trong biểu đồ lớp sẽ bao gồm đầy đủ các thuộc tính và các phương thức cùng mối quan hệ của chúng đã được thể hiện trong Kịch bản (Scenario). Ngược lại, kịch bản đưa ra những thuộc tính, phương thức mà biểu đồ lớp cần thể hiện. 36. Việc trích lớp và xây dựng các lớp là việc của pha thiết kế, tại sao người ta lại bắt đầu ngay trong pha phân tích 37. Kĩ thuật trích danh từ được dùng để trích các lớp nào? Có thể dùng để trích các lớp biên và lớp điều khiển được không? Kỹ thuật trích danh từ được dùng để trích lớp thực thể. Lớp biên và lớp điều khiển ko dùng phương pháp này vì trong phần kịch bản của 1 use case, chỉ có mô tả tương tác giữa người dùng và hệ thống mà ko nói đến cách thức hệ thống xử lý, điều khiển các chức năng. Vậy nên ko thể dùng phương pháp trích danh từ cho lớp biên và lớp điều khiển 38. Trình bày kĩ thuật trích lớp điều khiển? Số lượng lớp điều khiển nhiều hay ít thì tốt? Kỹ thuật trích lớp điều khiển: thực tế, mỗi một phép tính toán đáng kể đều được biểu diễn bằng 1 lớp điều khiển (each nontrivial computation is modeled by a control class) Số lượng nhiều hay ít thì tốt: ??? 39. Đặc tả yêu cầu là gì? Nêu một số kỹ thuật được sử dụng để đặc tả yêu cầu? Đặc tả yêu cầu là việc xây dựng các tài liệu đặc tả, mô tả đầy đủ các hành vi của hệ thống, bao gồm một tập hợp các chức năng để mô tả tương tác giữa người dùng và hệ thống, các yêu cầu phi chức năng ràng buộc thiết kế và cài đặt. Một sỗ kỹ thuật được sử dụng để đặc tả yêu cầu:  Phỏng vấn  Sử dụng bảng câu hỏi  Kiểm tra các hình thức nghiệp vụ  Quan sát trực tiếp 40. Thẩm định yêu cầu là gì? Cần phải thẩm định những nội dung gì của yêu cầu? Nêu một số kỹ thuật thẩm định yêu cầu. Thẩm đinh yêu cầu là xác định chính xác những yêu cầu của khách hàng và những ràng buộc mà khách hàng đưa ra. Những nội dung cần phải thẩm định: yêu cầu chức năng và phi chức năng, các rang buộc của khách hàng 41. Trình bày tiến trình làm bản mẫu phần mềm. Lợi ích của làm bản mẫu phần mềm trong xác định yêu cầu? Làm bản mẫu nhanh là một kỹ thuật phân tích yêu cầu chính xác và mạnh mẽ nhất. Khách hàng và nhóm phát triển dễ hiểu nhau: Khách hàng và người sử dụng thí nghiệm với sản phẩm mẫu, đề xuất yêu cầu,…Nhóm phát triển sẽ ghi lại những yêu cầu, đề nghị sửa đổi, và thương lượng để cho ra version tiếp theo Lợi ích của làm bản mẫu phần mềm trong xác định yêu cầu: Nhóm PT có thể thể hiện được nhanh chóng các chức năng mấu chốt của sản phẩm Khách hàng nhanh chóng hiểu được sản phẩm Hữu hiệu khi xây dựng giao diện người dùng 42. Tầm quan trọng của thiết kế phần mềm. Nêu các giai đoạn thiết kế cần trải qua. Tầm quan trọng của thiết kế phần mềm: Bước phân tích sau khi hoàn thành chưa thể cài đặt được chương trình, vì thế thiết kế sẽ phải tiếp tục làm rõ hơn đến chi tiết về ngôn ngữ lập trình, các hàm , các biến,… các kĩ thuật lập trình để có thể cài đặt được. Nêu các giai đoạn thiết kế cần trải qua: Thiết kế hướng đối tượng là sự kết hợp giữa hướng dữ liệu và hướng hành động, nó trải qua 2 bước chính: Bước 1: Hoàn thiện biểu đồ lớp: a. ĐỊnh nghĩa kiểu thuộc tính cho lớp b. ĐỊnh nghĩa khuôn mẫu phương thức cho lớp c. Gán các phương thức cho các lớp Cần lưu ý 3 nguyên tắc khi gán phương thức cho lớp: 1. ẩn giấu thông tin: chỉ khai báo get(), set() khi cần; các phương thức nên để private; nên sử dụng lớp trừu tượng 2. nguyên tắc khái quát hóa: nơi nào thực hiện hành động thì nơi đó chứa phương thức 3. nguyên tắc thiết kế hướng trách nhiệm Bước 2: Thiết kế chi tiết a. Lập bảng thiết kế chi tiết (tên , kiểu, thuật toán..) b. Xây dựng biểu đồ hoạt động c. Xây dựng biểu đồ triển khai 43. Ý nghĩa của sơ đồ trạng thái hữu hạn? Nó biểu diễn trạng thái của hệ thống, của lớp hay của phương thức? Ý nghĩa: Mô tả các sự kiện và hoạt động của từng hệ thống, lớp hoặc phương thức, cụ thể trong từng thao tác và gắn với phương thức/trường hợp xảy ra với từng đối tượng. Sơ đồ trạng thái hữu hạn sử dụng cho cả hệ thống, các lớp và phương thức 46. Trình bày các khái niệm sử dụng trong thiết kế. 47. Trình bày ý tưởng của chiến lược phát triển hướng đối tượng. Phương pháp lập trình hướng đối tượng được chia thành 2 hướng như sau: - Hướng lập trình: Từ lập trình đơn thể sang lập trình hướng đối tượng với lý thuyết cơ bản dựa trên việc trừu tượng hóa dữ liệu. - Hướng hệ quản trị CSDL: Phát triển thành CSDL hướng đối tượng. Mô hình hướng đối tượng được phát triển và duy trì theo bốn cách: - Sản phẩm bao gồm các thành phần độc lập - Đóng gói - Ẩn giấu thông tin - Thông điệp là cách liên lạc duy nhất 50. Làm thế nào để trích các lớp? Cần dùng các sơ đồ nào của UML? Nghiên cứu kĩ các use case và kịch bản để tìm ra các danh từ có vai trò nào đấy trong kịch bản -> các danh từ này sẽ thành các ứng cử viên Loại bỏ các ứng cử viên dư thừa: do có 2 hay nhiều danh từ cùng chỉ 1 thực thể; các danh từ không liên quan đến phạm vi bài toán; các danh từ ko mô tả các lớp rõ ràng; các danh từ chỉ là một vai trò trong mối liên hệ với một lớp khác; các danh từ biểu diễn các công cụ xây dựng phần mềm hoặc các thuật ngữ Sơ đồ cần dùng: sơ đồ quan hệ các lớp (Communication Diagram) 51. Làm thế nào để trích các phương thức của lớp? Cần dùng các sơ đồ/công cụ nào của UML? Dựa trên các lớp đã xác định, tiếp tục nghiên cứu các use case và kịch bản để trả lời các câu hỏi: + Với mỗi lớp, những danh từ nào mô tả thông tin của lớp đó -> tìm ra các thuộc tính + Những thông tin nào của lớp thực sự liên quan đến lĩnh vực quan tâm của hệ thống -> loại bỏ những thuộc tính không cần thiết + Những thông tin nào là thông tin riêng của lớp (các thuộc tính private), những thông tin nào có thể được chia sẻ trong mối liên hệ với các lớp khác (các thuộc tính protected hoặc public) Sau đó ta xem xét các động từ đi kèm với các danh từ biểu diễn lớp trong kịch bản và xem xét các động từ đó có trở thành phương thức hay không . Trong pha phân tích thì chỉ xác định được 1 số phương thức dễ nhận thấy Với pha thiết kế: sau khi đã xây dựng biểu đồ tuần tự với các message, ta thực hiện các bước sau: + Xem xét các message trong biểu đồ tương tác để xác định hành động tương ứng với message đó thuộc trách nhiệm của lớp nào + Các phương thức cần thiết để chuyển đổi các trạng thái trong biểu đồ trạng thái của một lớp + Xác định xem với mỗi lớp, lớp đó cần hàm khởi tạo và hủy không Sau đó là xác định chi tiết các giá trị trả về và tham số liên quan với mỗi phương thức Sơ đồ cần dùng: Sequence Diagram (tuần tự), Class Diagram (Sơ đồ lớp dạng ô vuông có thể điền thuộc tính và phương thức) 52. Nếu cho các phương thức add/update/delete đối tượng vào lớp thực thể tương ứng thì có được không? Tại sao? ĐƯợc. KHi đó lớp điều khiển sẽ là nơi gọi hàm còn lớp thưc thể là nơi định nghĩa hàm. 54. Sơ đồ lớp và sơ đồ cộng tác có gì khác nhau? Biểu đồ lớp là 1 loại biểu đồ tĩnh chỉ ra cấu trúc bên trong của các lớp trong hệ thống, bao gồm các thuộc tính, phương thức .Các lớp quan hệ với nhau theo nhiều dạng thức: liên kết, kế thừa ….với nhau Biểu đồ cộng tác chỉ ra sự tác động giữa các đối tượng với nhau, xác định các đối tượng và quan hệ giữa chúng, thể hiện sự trao đổi thông điệp (tương tác) thông qua các mũi tên theo 1 dòng chảy thông điệp giữa các đối tượng. 55. Mỗi trạng thái của sơ đồ trạng thái thường ứng với một lớp hay một phương thức, tại sao? Mỗi trạng thái của sơ đồ trạng thái ứng với 1 phương thức bởi vì: Trạng thái là một kết quả của các hoạt động trước đó đã được đối tượng thực hiện và nó thường được xác định qua giá trị của các thuộc tính cũng như các nối kết của đối tượng với các đối tượng khác. Một lớp có thể có một thuộc tính đặc biệt xác định trạng thái, hoặc trạng thái cũng có thể được xác định qua giá trị của các thuộc tính “bình thường" trong đối tượng. Mỗi sự chuyển trạng thái được ánh xạ thành 1 phương thức của lớp, mỗi hành động tác động vào trạng thái được ánh xạvà phương thức tương ứng. 56. Trình bày nguyên lí A của phần gán phương thức cho lớp? Nguyên lí này thường dùng cho các lớp loại nào? Nguyên lý che giấu thông tin: Các thược tính của lớp phải để dạng private cần các phương thức get, set tương ứng để cho các đối tượng khác truy cập vào ác thược tính này. Áp dụng cho lớp thực thể,các thuộc tính để dạng private, mỗi thuộc tính có một cặp get/set tương ứng 57. Trình bày nguyên lí B của phần gán phương thức cho lớp? Nguyên lí này thường dùng cho các lớp loại nào? Nguyên lí B: Nếu có nhiều đối tượng X gọi đến một hành động k của đối tượng Y, thì phương thức để thực hiện hành động k nên gán cho lớp của đối tượng Y, mà không nên gán cho lớp của đối tượng X 58. Trình bày nguyên lí C của phần gán phương thức cho lớp? Nguyên lí này thường dùng cho các lớp loại nào? Nguyên lí C: Thiết kế hướng trách nhiệm. Nếu một hành động mà không thể gán thành phương thức cho lớp khác, thì lớp của đối tượng cần thực hiện hành động đó phải chứa phương thức tương ứng hành động đó 61. Các bước thiết kế hướng đối tượng. Nêu ưu, nhược điểm của nó. - Xác định kiến trúc của hệ thống - Sắp thứ tự ưu tiên các gói - Với mỗi gói, thiết kế cho mỗi use case thuộc gói bằng cách xác định các lớp thiết kế tham gia triển khai các lớp phân tích - Xây dựng biểu đồ tương tác giữa các lớp - Thiết kế chi tiết các lớp - Phân tích và hoàn thiện biểu đồ lớp dựa trên các mẫu thiết kế Ưu điểm: - Dễ bảo trì(các đối tượng được hiểu như các thực thể hoạt động độc lập) - Dễ tái sử dụng (độ độc lập cao, có khả năng kế thừa) - Dễ hiểu (1 vài lớp hệ thống phản ánh 1 quan hệ rõ ràng giữa các thực thể có thực và đối tượng hệ thống) Nhược điểm: - Không dễ nhận ra các đối tượng của 1 hệ thống (vì cách nhìn tự nhiên nhiều hệ thống là cách nhìn chức năng) 66. Trình bày các phương pháp lập trình phổ biến. Các phương pháp lập trình phổ biến 1,lập trình hướng cấu trúc: phân chia ct chính thành nhiều ct con, mỗi ct con thực hiện 1 công việc xác định - Là phương pháp thiết kế từ trên xuống - Không hỗ trợ sd lại - Không dùng cho phần mềm lớn 2, lập trình hướng đối tượng: tập trung vào 2 đối tượng của hệ thống : dữ liệu và hành động Gồm các nguyên tắc : - Trừu tượng hóa - Tính đóng gói và ẩn dấu thông tin - Tính modul hóa - Tính phân cấp Ưu điểm : - Sử dụng cho phần mềm lớn - Hỗ trợ sd lại mã nguồn 67. Nêu các đặc trưng của phương pháp lập trình hướng đối tượng. - ẨN giấu thông tin - Đa hình - kế thừa, tái sử dụng lại 68. Nêu các nội dung liên quan đến phong cách lập trình. 69. Trình bày nội dung của lập trình tránh lỗi, lập trình thứ lỗi và xử lý ngoại lệ. 70. Những nội dung gì đặt ra liên quan đến lập trình hướng hiệu quả thực hiện? 71. Môi trường phát triển đặc trưng bằng các yếu tố gì? Chúng trợ giúp gì cho giai đoạn lập trình? 72. Thẩm định và xác minh là gì (V&V)? Tầm quan trọng của chúng? Xác minh và thẩm định một hệ phần mềm là một quá trình liên tục xuyên suốt mọi giai đoạn của quá trình phần mềm.Xác minh và thẩm định là từ chung cho các quá trình kiểm tra để đảm bảo rằng phần mềm thỏa mãn các yêu cầu của chúng và các yêu cầu đó thỏa mãn các nhu cầu của người sắm phần mềm. Xác minh và thẩm định là một quá trình kéo dài suốt vòng đời. Nó bắt đầu khi duyệt xét yêu cầu. Xác minh vàthẩm định có hai mục tiêu: i) Phát hiện các khuyết tật trong hệ thống. ii) Đánh giá xem hệ thống liệu có dùng được hay không? Sự khác nhau giữa xác minh vàthẩm định là: i)Thẩm định: Xem xét cái được xây dựng có là sản phẩm đúng không? Tức là kiểm tra xem chương trình có được như mong đợi của người dùng hay không. ii) Xác minh: Xem xét cái được xây dựng có đúng là sản phẩm không? Như thế, xác minh là kiểm tra chương trình có phù hợp với đặc tả hay không. 73. Có những loại V&V nào? Mô tả nội dung mỗi loại. Kiểm tra là một quá trình của tìm kiếm lỗi.Một kiểm tra tốt có khả năng cao tìm kiếm các lỗi chưa được phát hiện.Một kiểm tra thành công là kiểm tra tìm ra các lỗi mới, một kiểm tra tồi là kiểm tra mà không tìm được lỗi. Có hai kiểu lỗi trong ứng dụng và các kiểm tra tốt sẽ xác định cả hai loại đó. Cụ thể: Không làm những điều cần phải làm: lỗi bỏ sót thường xuất hiện đối với ứng dụng mới được phát triển. Làm những điều không cần làm: lỗi của lệnh đã cư trú trước trong các ứng dụng bảo trì. Kiểm tra phát triển bao gồm kiểm tra đơn vị, kiểm tra hệ thống con, kiểm tra tích hợp và các kiểm tra hệ thống. Kiểm tra đơn vị (Unit test) được tiến hành cho mỗi đơn vị mã nhỏ nhất. Kiểm tra tích hợp (Subsystem integration test) kiểm tra mặt logic và xử lý cho phù hợp của các khối, kiểm tra việc truyền tin giữa chúng. Kiểm tra hệ thống (System test) đánh giá các đặc tả chức năng có được đáp ứng, các thao tác giao diện người có giống thiết kế không, và các công việc của ứng dụng trong môi trường thao tác mong muốn, đối với các ràng buộc. 74. inspection là gì? Khác gì với walkthrough? -inspection là giám định,kiểm tra phần thiết kế và lập trình. -Khác với walkthrough là: +Mục đích của việc giám định là tìm kiếm phát hiện lỗi trong tài liệu,không phải cách khắc phục lỗi. +có bảng liệt kê các lỗi có thể xảy ra. +có bảng ghi thống kê các khuyết điểm. +đội giám định sử dụng bảng liệt kê các câu hỏi để hỗ trợ trong việc tìm ra các khuyết điểm. +việc giám định bao gồm 5 bước:xem xét tổng quát,chuẩn bị, giám định, xem xét lại, theo dõi. +quá trình giám định tốn thời gian hơn đội kiểm thử. +việc giám định là công cụ tốt và tiết kiệm chi phí trong việc phát hiện khuyết điểm. +Đội giám định gồm có 4 người:1 người điều hành,1 ng thiết kế,1ng lập trình,1 ng kiểm thử +Phải có 1 đại diện của nhóm chịu trách nhiệm trong giai đoạn được giám định cũng như của nhóm kế tiếp. +người thiết kế làm các thiết kế +ng lập trình chuyển các thiết kế đó thành code. 75. walkthrough là gì? Khác gì với inspection? -walkthrough là kiểm thử, phát hiện ra những khuyết điểm của phần mềm. -Nhiệm vụ của đội kiểm thử không phải là sửa các khuyết điểm mà là ghi chép lại cho sự hiệu chỉnh sau này. -Khác với inspection là: +những khuyết điểm được phân tích một cách có phương pháp +Đội kiểm thử nên có từ 4 đến 6 người. - +Đội kiểm thử nghiệm gồm: +ít nhất có 1 đại diện của nhóm chịu trách nhiệm phác thảo các đặc tả kỹ thuật. +người quản lý có trách nhiệm trong pha phân tích +một đại diện của khách hàng +một đại diện của nhóm thiết kế +một đại diện của nhóm đảm bảo chất lượng(SQA),thành viên của nhóm SQA làm chủ cho đội thử nghiệm. 76. Người ta nói « nhóm SQA tạo ra chất lượng cho phần mềm » đúng hay sai? Tại sao? -Đúng,bởi + Những người trong nhóm SQA giữ vai trò như người đại diện của khách hàng để thay mặt khách hàng xem chất lượng của phần mềm với quan điểm của họ. + Nhóm SQA (phần mềm đảm bảo chất lượng) sẽ xem xét chất lượng phần mềm có đáp ứng được các nhân tố chất lượng hay không? Có tuân theo các chuẩn dự định trước hay 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 không? Chứ khách hàng chỉ là người đưa ra những yêu cầu phần mềm của họ cần những gì . 84. Nêu các phương pháp kiểm thử thường dùng. Trả lời: Các phương pháp test thường dùng là :  White box test  Black box test  Grey box test 85. Trình bày phương pháp kiểm thử hộp trắng: cơ sở phương pháp; các yêu cầu cần kiểm tra, các kỹ thuật được sử dụng. - Cơ sở phương pháp: tập trung vào cấu trúc bên trong của phần mềm với mục đích đảm bảo rằng tất cả các câu lệnh và rẽ nhánh đều được thực hiện. -Các yêu cầu cần kiểm tra:  Độ bao phủ câu lệnh.  Độ bao phủ rẽ nhánh.  Độ bao phủ đường cơ bản.  Tình tuyến tính của mã tuần tự. - Các kỹ thuật cần sử dụng:  Kiểm thử đường cơ bản (basic path testing): xem xét các điểm quyết định trong ứng dụng.  Phân vùng tương đương (equivalence) : chia nhỏ thành các tập hợp có thể gán vào các lớp tương đương và chỉ có một giá trị trong các lớp tương đương cần được test.  Phân tích giá trị biên (boundary value analysis) 86. Trình bày phương pháp kiểm thử hộp đen: cơ sở phương pháp; các yêu cầu cần kiểm tra, các kỹ thuật được sử dụng. - Cơ sở phương pháp: tập trung vào yêu cầu chức năng và dữ liệu kiểm thử xuất phát từ đặc tả yêu cầu.Người kiểm thử coi phần mềm như 1 hộp đen và chỉ quan tâm tới việc tìm ra các chức năng mà phần mềm xử lý không đúng theo đặc tảcó thể phát hiện các lỗi giao diện, lỗi cơ sở dữ liệu…. - Các kỹ thuật cần sử dụng:  Phân vùng tương đương (equivalence partitioning) : chia nhỏ thành các tập hợp có thể gán vào các lớp tương đương và chỉ có một giá trị trong các lớp tương đương cần được test.  Phân tích giá trị biên (boundary value analysis)  Kiểm thử tất cả các cặp (all-pairs testing)  Dựa trên model (model-based)  Dùng bảng để đưa ra quyết định (decision table) 87. Kiểm thử đơn vị đối tượng là gì? Ai thực hiện. Các phương pháp và kỹ thuật nào được sử dụng? Kiểm tra những loại lỗi nào? Kiểm thử riêng rẽ từng đơn vị được gọi là kiểm thử đơn vị(đơn vị là các mô-đun hay chương trình, đối với phần mềm phát triển theo hướng đối tượng, một đơn vị có thể là một phương thức hay thậm chí một lớp). Loại kiểm thử này thường được viết bởi các DEV như công việc của họ trong việc code Test white-box: để bảo đảm rằng từng hàm riêng biệt hoạt động đúng theo mong muốn. Test-white-box kiểm tra tính logic và cấu trúc của mã nguồn,kiểm tra tất cả những trường hợp có thể xảy ra trong mã nguồn như:cấu trúc điều khiển,cấu trúc lặp Test-black-box thường được sử dụng để kiểm thử đơn vị.Các dữ liệu thử sẽ thường được tạo ra dựa trên phân tích tài liệu đặc tả, tài liệu thiết kế 88. Các chiến lược nào sử dụng trong kiểm thử tích hợp? Ưu điểm và hạn chế mỗi loại? 1. Kiểm thử từ dưới lên(bottom-up testing) Ưu điểm: tránh phải tạo các stub phức tạp hay tạo các kết quả nhân tạo.Thuận tiện cho phát triển các mô đun thứ cấp dùng lại được.Dễ dàng quan sát kết quả kiểm thử Nhược điểm:phát hiện chậm các lỗi thiết kế.Chậm có phiên bản thực hiện được của hệ thống 2. Kiểm thử từ trên xuống(top-dow testing) Ưu điểm:phát hiện sớm các lỗi thiết kế.có phiên bản hoạt động sớm Nhược điểm:khó có thể mô phỏng được các chức năng của mô đun thứ cấp phức tạp.Không kiểm thử đầy đủ các chức năng 3. kiểm thử hồi quy(regression testing) Ưu điểm: Chạy lại những test case để xác định rằng những sữa đổi không gây hỏng kết quả và hệ thống kia luôn đáp ứng yêu cầu với những chi tiết kỹ thuật. nhược điểm: Kiểm định chất lượng không testing, không thực hiện tìm lỗi.Hao phí thời gian lớn.Không hiệu quả để thực hiện lại tất cả các kiểm thử cho mọi chức năng chương trình mỗi lần có thay đổi xảy ra 89. Giải thích khái nhiệm stub và driver? Chúng được sử dụng ở đâu và vì sao? Driver là module có nhiệm vụ kích hoạt các testcase để kiểm thử module đang cần kiềm thử. Stub là một hiện thực ở mức độ tối thiểu nào đó cho 1 module chức năng được dùng bởi module đang cần kiểm thử. Stub và drive được sử dụng trong kiểm thử không tăng tiến. Mỗi module mã nguồn không phải là một chương trình hoàn chỉnh và đôi khi phải gọi các module chưa được kiểm nghiệm nên cần phải thiế lập driver và/hoặc stub 90. Kiểm thử hệ thống nhằm kiểm tra cái gì? Ai thực hiện? Các phương pháp? 1.Kiểm thử hệ thống là kiểm thử thiết kế và toàn bộ hệ thống(sau khi tích hợp có thỏa mãn yêu cầu đặt ra hay không).Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi,nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khácliên quan đến chất lượng của toàn hệ thống 2.System Test thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án.(Có thể là đội test của chính công ty đó,hoặc không thì có thể là đội test của khách hàng) Phương pháp áp dụng chủ yếu là: Kiểm thử hộp đen (Black box test),ngoài ra còn có thể áp dụng các phương pháp khác( white box test,Gray test...) 91. Trình bày các kiểm thử được thực hiện trong kiểm thử hệ thống? Các kiểm thử được thực hiện trong kiểm thử hệ thống? 1.Kiểm thử chức năng (Functional Test):Bảo đảm các hành vi của hệ thỏa mãn đúng yêu cầu thiết kế. 2.Kiểm thử phi chức năng a.Kiểm thử hiệu năng (Performance Test):Bảo đảm tối ưu việc phân bổtài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gianxử lý hay đáp ứng câu truy vấn... b.Kiểm thử khả năng chịu tải (Stress Test hay Load Test):Bảo đảm hệthống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùnglúc). Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết",các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM...)... c.Kiểm thử cấu hình (Configuration Test). d.Kiểm thử bảo mật (Security Test):Bảo đảm tính toàn vẹn, bảo mật củadữ liệu và của hệ thống. e. Kiểm thử khả năng phục hồi (Recovery Test):Bảo đảm hệ thống cókhả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tàinguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịchnhư ngân hàng trực tuyến... 92. Kiểm thử chấp nhận là gì? Trong đó có những kiểm thử nào được thực hiện? Phân biệt. -Kiểm thử chấp nhận: Là giai đoạn kiểm thử mức chấp nhận từ phía khách hàng ( chú ý:Acceptance Test là do khách hàng thực hiện). Mục đích để chứng minh sản phẩm thỏa mãn tất cả các yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm 2.Phân loại - Acceptance Test có 3 kiểu: + Với sản phẩm dành cho đối tượng khách hàng là số ít: sau giai đoạn System Test sẽ chuyển sang cho khách hàng kiểm tra lại trực tiếp. Thường thì từ phía đội sản xuất sẽ chuẩn bị một kịch bản User Acceptance Test cho khách hàng để họ thực hiện. Tester, cụ thể ở đây là Test Leader của dự án tiếp nhận lỗi phản ánh từ khách hàng và cho kiểm tra lại, fix hoặc trả lời để khách hàng rõ, .... + Với sản phẩm dành cho thị trường mass (như Windows của Microsoft, Acrobat, ....) là các sản phẩm dành cho người dùng cá nhân với thị phần đông đảo thì thường trải qua 2 giai đoạn: Alpha Test và Beta Test. Alpha Test: là giai đoạn Acceptance Test, trong đó người đóng vai trò thực hiện là các Khách hàng tiềm năng hoặc người đóng vai trò người sử dụng nhưng với số lượng ít và làm việc trực tiếp với đơn vị sản xuất ra phần mềm đó để sửa lỗi (nếu có). Beta Test: là giai đoạn Acceptance Test sau khi thực hiện xong Alpha Test. Sau khi test với số lượng khách hàng tiềm năng trước, các công ty sản xuất phần mềm mass sẽ tung ra thị trường cho người dùng sử dụng thử nghiệm. Giai đoạn đó gọi là Beta Test. Một bộ phận tiếp nhận phản hồi từ vô vàn user sẽ phân loại ý kiến người dùng, theo dõi và sửa chữa (nếu cần) trước khi công bố phiên bản chính thức của phần mềm. 101. Mô hình CMM là gì? Có những mức tăng trưởng nào trong mô hình CMM? Nội dung của mỗi mức? - Mô hình CMM hay còn gọi là SW-CMM là mô hình đánh giá năng lực sản xuất phần mềm. Mức1: Initial (Khởi đầu) +Level 1 là bước khởi đầu của CMM, mọi doanh nghiệp, công ty phần mềm, cá nhóm, cá nhân đều có thể đạt được. + Ở lever này CMM chưa yêu cầu bất kỳ tính năng nào. Ví dụ: không yêu cầu quy trình, không yêu cầu con người, miễn là cá nhân, nhóm, doanh nghiệp… đều làm về phầm mềm đều có thể đạt tới CMM này. Mức 2:Repeatable (Lặp lại)Quản lý phần mềm cơ bản: -Requirement Management(Lấy yêu cầu khách hàng, quản lý các yêu cầu đó) -Software Project Planning(Lập các kế hoạch cho dự án) -Software Project Tracking(Theo dõi kiểm tra tiến độ dự án) -Software Sub Contract Managent(Quản trị hợp đồng phụ phần mềm) -Software Quality Assurance(Đảm bảo chất lượng sản phẩm) -Software Configuration Management(Quản trị cấu hình sản phẩm=>đúng yêu cầu của khách hàng không Mức 3:Defined (Xác định) +tập trung quy trình cấp tổ chức +định nghĩa quy trình cấp tổ chức +chương trình đào tạo +tích hợp quản lý phần mềm +kỹ thuật phát triển phần mềm +điều phối liên nhóm +xem xét ngang hàng Mức 4:Managed Level +quảnl ý quy trình chất lượng +quản lýchất lượng phần mềm. Mức 5:Optimizing(tối ưu) +phòng ngừa sai sót +quản lý thay đổi kỹ thuật , công nghệ +quản lý thay đổi quy trình 102. Làm thế nào để một tổ chức đạt được các mức tăng trưởng trong CMM? Đâu là giải pháp và thước đo về các mức tăng trưởng? - Phải phát triển và duy trì một Hệ thống quản lý chất lượng phần mềm. -Xây dựng chất lượng phần mềm cho phần mềm ngay từ giai đoạn bắt đầu..Điều này đồng nghĩa với việc đảm bảo các yêu cầu cho phần mềm từ mọi nguồn khác nhau phải được định nghĩa, diễn đạt và hiểu một cách đúng đắn, giữa người đưa ra yêu cầu và người thực hiện yêu cầu. - Đảm bảo chất lượng của phần mềm xuyên suốt quá trình phát triển. 103. Nêu các chuẩn quốc tế về phần mềm. Trình bày sự khác nhau giữa mô hình CMM và các chuẩn đó. Khác nhau CMM ISO 9000-series ISO/IEC 15504 - Không có mô hình vòng đời - CMM được tạo ra để giúp đỡ cho việc quản lý các tổ chức phát triển phần mềm. - Là chuẩn quản lý quy trình chất lượng của các sản phẩm phần mềm được áp dụng cho từng loại hình công ty khác nhau. - Là một bộ khung (framework) những chuẩn đề ra cho một tiến trình sản xuất phần mềm hiệu quả, các tổ chức áp dụng nó sẽ mang lại sử khả dụng về mặt chi phí, thời gian biểu, chức năng và chất lượng sản phẩm phần mềm. ISO 9000:2000: Hệ thống quản lí chất lượng – Cơ sở và từ vựng. ISO 9000:2000 mô tảcơ sở của các hệ thống quản lí chất lượng và quy định các thuật ngữ dùng trong các hệ hống quản lí chất lượng thuộc nhóm này. ISO 9001:2000: Hệ thống quản lí chất lượng – Các yêu cầu. Đây là tiêu chuẩn được sử dụng để đánh giá hệ thống quản lí chất lượng của một tổ chức và cấp chứng chỉ phù hợp. ISO 9004:2000: Hệ thống quản lí chất lượng – Hướng dẫn cải tiến. ISO 9004:2000 cung cấp các hướng dẫn xem xét, cải tiến tính hiệu lực và hiệu quả của hệ thống quản lí chất lượng. ISO / IEC 15504 có thể được sử dụng để thực hiện cải tiến quy trình trong một tổ chức công nghệ. -Là sáng kiến cải thiện quy trình quốc tế. -Bao gồm cải thiện quy trình và cung ứng phần mềm. -Mở rộng và cải tiến CMM,ISO 9000 -Là một bộ khung(framework), không phải là một phương pháp. -Thu được những lợi ích xác thực,giảm đc rủi ro trong ptriển phần mềm. ISO 9003:2000 được sử dụng khi áp dụng ISO 9003 trong việc phát triển, cung cấp và bảo trì phần mềm,hơn nữa nó còn chỉ rõ rằng hệ thống chất lượng tạo ra phải được tích hợp lại trong toàn bộ chu kỳ sản xuất.


Comments

Copyright © 2024 UPDOCS Inc.