CÔNG NGHỆ PHẦN MỀM Câu 1: Tóm tắt các bước trong quá trình phát triển phần mềm? 1. Pha xác định yêu cầu Người phát triển phần mềm sẽ tiếp thu các yêu cầu, chức năng các công việc cần thực hiện của phần mềm mà khách hàng yêu cầu. người phát triển phần mềm cần tìm hiểu thực chất khách hàng cần gì? Những yêu cầu về chức năng công việc, những điều kiện về phần mềm là gì? Tuy nhiên khách hàng có thể do một vài lí do hoặc do khách hàng k có kiến thức về máy tính nên có thể k hài lòng về phần mềm cần sửa đổi và viết lại. Lúc này người phát triển phần mềm thường viết nhanh một phần mềm thực hiện các yêu cầu của khách hàng. Phiên bản này được gọi là bản mẫu nhanh. Kiểm thư pha yêu cầu: do nhóm đảm bảo chất lượng phần mềm(SQA) làm nhiệm vụ bảo đảm rằng phần mềm hoạt động tốt và đáp ứng các yêu cầu của khách hàng. Nhóm SQA bắt đầu thực hiện vai trò của mình ngay từ pha khởi đầu. Tài liệu báo cáo trong pha yêu cầu: bao gồm bản mẫu và các ghi chép trong quá trình trao đổi với khách hàng. Tài liệu này được kiểm tra bởi khách hàng và một số người sử dụng trước khi được SQA kiểm tra kỹ lưỡng và chi tiết. 2. Pha đặc tả (đặc tả): xác định tài liệu đặc tả Chi tiết và chính xác hóa các tài liệu của pha yêu cầu để có tài liệu của phân tích. Tài liệu đặc tả cần chỉ rõ đầu vào và đầu ra của phần mềm Báo cáo đặc tả là cơ sở tạo ra bản hợp đồng Tài liệu đặc tả đóng vai trò quan trọng trong việc kiểm thử và bảo trì phần mềm Xây dựng chi tiết và ước lượng thời gian hoàn thành và giá trị phần mềm Phân công nhân sự cho từng giai đoạn Kế hoạch quản lý dự án phần mềm cần được biên soạn kĩ lưỡng nhằm phản ánh các giai đoạn khác nhau của quá trình phát triển phần mềm, những thành viên tham gia trong từng giai đoạn và thời hạn cần hoàn thành. Thời điểm sớm nhất để xây dựng sản phẩm phần mềm là khi phần đặc tả kết thúc. Thành phần chính của kế hoạch là những sản phẩm chuyển giao cho khách hàng chi phí của các sản phẩm này. Bản kế hoạch mô tả tỷ mỷ quy trình phần mềm bao gồm mô hình vòng đời phần mềm được sử dụng, cơ cầu tổ chức của các công ty phần mềm, mục tiêu của dự án, các kĩ thuật, các công cụ CASE được sử dụng, lịch trình làm việc chi phí Kiểm thử pha đặc tả: Nhóm SQA cần kiểm tra tài liệu đặc tả một cách kĩ lưỡng, tính khả thi của tài liệu đặc tả. Tài liệu đặc tả phải có thể kiểm thử được các phần, các mục được đánh số tương ứng tài liệu xác định yêu cầu để tiện theo dõi. Cách tốt nhất để kiểm tra tài liệu đặc tả là xem xét. Đại diện nhóm đặc tả và nhóm khách hàng cùng ngồi xem xét kỹ lưỡng bản đặc tả, phát hiện những sai sót hoặc những điều chưa chính xác dưới sự chủ tọa của các thành viên nhóm SQA Tài liệu báo cáo trong pha đặc tả gồm: bản báo cáo đặc tả và bản kế hoạch quản lý dự án phần mềm(SPMP) 3. Giai đoạn thiết kế Nhóm thiết kế xác định cấu trúc bên trong của phần mềm. Họ phân chia phần mềm thành các modul. Sau khi chia các modul là thiết kế chi tiết cho các modul. Mỗi modul cần chọn các thuật toán và cấu trúc dữ liệu thích hợp. Trong quá trình thiết kế chia các modul nên ghi chép lại các bước quy định là lí do lựa chọn để khi công việc bế tắc quay lại dễ hơn,thuận tiện cho công tác bảo trì. Kiểm thử pha thiết kế: Bản thiết kế mang tính chuyên nghiệp kiểm tra bản thiết kế thì thường khách hàng k có mặt. Công việc xem xét này được nhóm SQA thực hiện. Có thể gặp các lỗi logic, giao tiếp, thiếu xử lý các trường hợp ngoại lệ, k tương thích với báo cáo đặc tả. Có thể gặp lỗi ở các pha trước mà chưa được phát hiện Tài liệu báo cáo trong pha thiết kế: Sản phẩm chính trong pha này là bản thiết kế kiến trúc và chi tiết. Các bản thiết kế chi tiết được chuyển cho lập trình viên để thực hiện công việc lập trình 4. Cài đặt Lập trình viên viên viết chương trình cho các modul theo thiết kế chi tiết Kiểm thử pha cài đặt:mỗi modul cần kiểm thử trong quá trình thực thi và sau khi hoàn thành do lập trình viên thực hiện. Sau đó nhóm SQA sử dụng một số phương pháp đã có để thử lại các modul. Cùng với việc chạy thử các số liệu mẫu, việc xem xét các mã nguồn cũng là một cách kiểm thử hiệu quả tìm ra lỗi lập trình. Người lập trình sẽ giới thiệu các dòng lệnh, cách hoạt động của các modul. Nhóm xem xét mã nguồn cần có đại diện của nhóm SQA. Các hoạt động kiểm thử cần ghi chép lại Tài liệu báo cáo trong pha cài đặt là các mã nguồn của mỗi modul cùng với các lời giải thích. Bổ sung thêm các tài liệu khác để hỗ trợ bảo trì về sau 5. Tích hợp Các modul được tích hợp thành phần mềm và kiểm tra các chức năng của phần mềm có hoạt động chính xác hay k? Nên thực hiện pha cài đặt và tích hợp song song với nhau. Kiểm thử pha tích hợp: Kiểm tra các modul có được một cách chính xác để tạo phần mềm đúng trong các bước đặc tả k? cần chú ý đến phần giao tiếp giữa các modul. Sauk hi kiểm tra xong, nhóm SQA chuyển sang kiểm thử. Nên đửa ra nhiều trường hợp thử khi kết thúc phần mềm đặc tả. Kiểm thử tính chính xác và cả tính ổn định của chương trình. Bước cuối cùng của kiểm thử tích hợp là kiểm thử chấp nhận: chương trình được cài đặt trên máy của khách hàng chạy với chương trình và số liệu thực Tài liệu báo cáo trong pha tích hợp: là tài liệu hướng dẫn sử dụng, tài liệu hướng dẫn vận hành, giải thích cơ sở dữ liệu…Tóm lại là tất cả các tài liệu cần thiết cùng với phần mềm để chuyển giao cho khách hàng 6. Bảo trì Khi phần mềm được chấp nhận bởi khách hàng và cài đặt trên máy của họ thì mọi thay đổi về phần mềm từ đó được gọi là bảo trì. Bảo trì thường có chi phí lớn hơn tất cả các pha khác, trải qua nhiều thách thức nhất trong quá trình sản xuất Kiểm thử trong pha bảo trì:Kiểm tra xem phần mềm có được sửa đúng theo yêu cầu đặt ra chưa?;sau khi sửa lại một phần của phần mềm thì phần mềm còn lại có bị ảnh hưởng k?; Tài liệu báo cáo trong pha bảo trì: Các ghi chép và các sửa đổi đã được thực hiện cùng với các lý do khi phần mềm được sửa đổi thì cẩn thực hiện kiểm thử hồi quy – là một phần quan trọng trong tài liệu này. 7. Thôi sử dụng Sự thay đổi do khách hàng đưa ra quá lớn Sau nhiều lần thực hiện sửa đổi trên thiết kế ban đầu làm cho các phần của phần mềm trở nên quá phụ thuộc lẫn nhau ảnh hưởng đến phần mềm, bảo trì khó khăn làm phần mềm mới Sau nhiều lần sửa đổi nhưng các tài liệu lại k cập nhật đầy đủ nên k kiểm soát được các lỗi hồi quy Câu 2: Hãy nêu các mô hình phát triển phần mềm?Vẽ mô hình và trình bày đặc điểm, ưu nhược điểm của mỗi mô hình . 1. mô hình xây dựng và hiệu chỉnh 2. mô hình thác nước 3. mô hình bản mẫu 4. mô hình phát triển 5. mô hình phát triển đồng thời 6. mô hình đồng bộ ốn định 7. mô hình xoắn ốc 1. Mô hình xây dựng và hiệu chỉnh - Trong mô hình này không có các pha phân tích thiết kế. Phần mềm được xây dựng như sau: Người phát triển sau khi trao đổi với khách hàng sẽ viết phiên bản đầu tiên. Tiếp theo, phần mềm được chạy thử với sự quan sát của khách hàng và liên tục được hiệu chỉnh cho đến khi khách hàng vừa ý (tức là đáp ứng được yêu cầu của khách hàng). Sau khi được khách hàng chấp nhận, phần mềm được đưa vào sử dụng và bảo trì. - Mô hình này có thể biểu diễn trong sơ đồ sau: - Nhược điểm của mô hình thể hiện rõ trong giai đoạn bảo trì. Công việc bảo trì thường là sửa lỗi và cập nhật. Nếu phần mềm vừa mới được đưa vào sử dụng và tác giả vẫn còn chịu trách nhiệm công việc này thì không có vấn đề gì lắm. Tuy nhiên nếu phần mềm đã được sử dụng sau một thời gian dài, khiến cho chính người viết chương trình cũng quên đi ý nghĩa các dòng lệnh; hoặc việc bảo trì lại do một người khác thực hiện thì sẽ rất khó khăn - Mô hình xây dựng-và-hiệu chỉnh chỉ thích nghi cho phần mềm nhỏ, một người viết và ít khả năng phải sửa đổi trong quá trình sử dụng. Xây dựng phiên bản đầu tiên Hiệu chỉnh cho đến khi khách hàng chấp nhận Sử dụng và bảo trì Thôi sử dụng Phát triển Bảo trì 2. Mô hình thác nước (mô hình xây dựng và hiệu chỉnh, mô hình thác nước, mô hình bản mẫu, mô hình phát triển, phát triển đồng thời, đồng bộ ổn định, mô hình xoắn ốc) - Trong mô hình này, quá trình phát triển phần mềm được coi như một dòng chảy trải qua các pha yêu cầu, phân tích, thiết kế, cài đặt, tích hợp và bảo trì - Có tính độc lập của từng pha, nghĩa là nếu trong 1 pha người ta phát hiện ra sai sót hoặc không phù hợp thì sẽ quay lại hiệu chỉnh ở pha trước - Ưu điểm: Các giai đoạn được định nghĩa với đầu vào và đầu ra rõ ràng, Bảo trì thuận lợi - Nhược điểm: Các dự án trong thực tế hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Mặc dầu mô hình cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là những thay đổi có thể gây ra lẫn lộn khi nhóm phát triển làm việc. Trong mô hình này đòi hỏi 1 bản yêu cầu đầy đủ và chính xác từ phía khách hàng. Khách hàng chỉ tham gia dự án ở giai đoạn phân tích yêu cầu và test - Áp dụng: Mô hình này chỉ nên áp dụng khi đội dự án đã có kinh nghiệm, yêu cầu từ khách hàng được xác định rõ ngay từ đâu và ít có khả năng thay đổi Xác định yêu cầu Phân tích Thiết kế Cài đặt Tích hợp Bảo trì Thôi sử dụng Thay đổi yêu cầu 3. Mô hình bản mẫu ( mô hình xây dựng và hiệu chỉnh, mô hình thác nước, mô hình bản mẫu, mô hình phát triển, phát triển đồng thời, đồng bộ ổn định, mô hình xoắn ốc) - Mô hình bản mẫu xây dựng dựa trên ý tưởng xây dựng 1 mẫu thử ban đầu và đưa cho người sử dụng xem xét; sau đó tinh chỉnh mẫu thử qua nhiểu phiên bản cho tới khi thỏa mãn yêu cầu người sử dụng thì dừng lại - Mẫu thử ban đầu như là một cơ chế nhận chính xác yêu cầu của khách hàng - Mẫu thử ban đầu có thể trở thành sản phẩm. Khi các yêu cầu của người sử dụng được thỏa mãn cũng là lúc chúng ta xây dựng xong hệ thống - Mẫu thử ban đầu có thể loại bỏ, mẫu thử chỉ có tác dụng làm sáng tỏ yêu cầu của người sử dụng - Mô hình - Ưu điểm: Người sử dụng sớm hình dung ra chức năng và đặc điểm của hệ thống Cải thiện sự liên lạc giữa các nhà phát triển và người sử dụng - Nhược điểm: Khi bản mẫu không chuyển tải hết các chức năng, đặc điểm của hệ thống phần mềm thì người sử dụng có thể thất vọng và mất đi sự quan tâm đến hệ thống sẽ được phát triển Bản mẫu thường được làm nhanh, thậm chí vội vàng theo kiểu “hiện thực – sửa” và có thể thiếu sự phân tích đánh giá một cách cẩn thận tất cả các khía cạnh liên quan đến hệ thống cuối cùng. - Áp dụng: Mô hình bản mẫu được áp dụng cho: + Những hệ thống tương tác ơ mức độ nhỏ và vừa + Hệ thống chủ yếu dựa trên giao diện nguời dùng + Hệ thống có thời gian chu kì ngắn Bản mẫu Phân tích Thiết kế Cài đặt Tích hợp Bảo trì Thôi sử dụng Thay đổi yêu cầu 4. Mô hình tăng dần ( mô hình xây dựng và hiệu chỉnh, mô hình thác nước, mô hình bản mẫu, mô hình phát triển, phát triển đồng thời, đồng bộ ổn định, mô hình xoắn ốc) - Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần (build) tương đối độc lập nhau. Mỗi thành phần như vậy được coi như một phần mềm nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng. - Sơ đồ sau mô tả mô hình tăng dần. - Ưu điểm + Thuận tiện cho bảo trì và phát triển + Các modul có thể thay đổi trong quá trình thiết kế và cài đặt + Với mô hình này, tại mỗi giai đoạn khách hàng có được sản phẩm thực hiện một phần công việc theo yêu cầu + Không đòi hỏi khách hàng phải có kinh phí lớn và khách hàng có thể dừng phát triển bất kì lúc nào + Khách hàng có thể tham gia đóng góp ý kiến - Nhược điểm + Đòi hỏi tính chuyên nghiệp của người thiết kế + Khó khăn khi kết hợp build vào cấu trúc hiện thời là làm sao không phá huỷ cấu trúc đã xây dựng. Như vậy, yêu cầu cấu trúc phải mở. Yêu cầu này là chung cho mọi mô hình cần chọn. + Mô hình này uyển chuyển hơn so với các mô hình thác nước và làm bản mẫu vì dễ thay đổi theo yêu cầu của khách hàng. Tuy nhiên, nó có thể suy biến thành mô hình làm bản mẫu và khó điều phối chung Câu 3:Trình bày các phương pháp khảo sát 1. Phỏng vấn Phát triển Bảo trì Xác định yêu cầu Phân tích Thiết kế kiến trúc Với mỗi build thực hiện: Thiết kế chi tiết, lập trình, tích hợp, kiểm thử rồi chuyển giao cho khách hàng Bảo trì Thôi sử dụng • Phỏng vấn là việc tập hợp một số lượng ít người cho 1 thời gian cố định với 1 mục đích cụ thể. Trong quá trình phỏng vấn, các câu hỏi có thể được thay đổi • Phỏng vấn được chia 2 loại: phỏng vấn có cấu trúc(câu hỏi đóng và được chuẩn bị trước) và phỏng vấn có không có cấu trúc ( câu hỏi có tính mở: tất cả các vấn đề không được xác định trước và stakeholder phải tự giải thích và phát biểu theo quan điểm của mình) Phỏng vấn có cấu trúc Phỏng vấn không có cấu trúc Ưu điểm - Dùng dạng chuẩn cho nhiều câu hỏi - Dễ quản lý và đánh giá - Đánh giá được nhiều mục đích - Không cần đào tạo nhiều - Có kết quả trong các phỏng vấn - Có khả năng mềm dẻo nhất - Cần chăm chỉ nghe và có kỹ năng mở rộng câu hỏi - Có thể bao hết thông tin chưa biết - Đòi hỏi có thực hành Nhược điểm - Chi phí chuẩn bị lớn - Tính cấu trúc có thể không thích hợp cho mọi tình huống - Giảm tính chủ động của người phỏng vấn - Lãng phí thời gian phỏng vấn - Người phỏng vấn có thể định kiến với các câu hỏi - Tốn thời gian lựa chọn và phân tích thông tin - Một phỏng vấn tốt • Thu thập được tất cả hiểu biết về công việc phải làm của stakeholder( các bên liên quan) • Nắm rõ họ tương tác với hệ thống như thế nào - Để phỏng vấn thành công, người phỏng vấn nên: Cởi mở, sẵn sàng lắng nghe Không có định kiến Đưa ra câu hỏi gợi mở, thân thiện - Kỹ thuật phỏng vấn: Bước 1: Những câu hỏi căn bản, ngữ cảnh bất kì Bước 2: nhằm hiểu sâu hơn vấn đề Bước 3: Những câu hỏi về hiệu quả của việc gặp gỡ - Các bước phỏng vấn: Đặt cuộc hẹn Chuẩn bị tốt, hiểu kỹ về đối tượng Đúng giờ và có kế hoạch mở đầu - Ưu điểm: Phỏng vấn thích hợp cho việc nhận các thông tin bảo đảm cả số lượng và chất lượng Các kiểu thông tịnh định tính là các ý kiến, niềm tin, thói quen, chính sách, và mô tả Các kiểu về thông tin định lượng bao gồm tần suất, số lượng, định lượng các mục được dùng trong ứng dụng - Nhược điểm: Phỏng vấn và các dạng khác của thu thập dữ liệu có thể làm bạn lạc lối, thiếu chính xác hoặc thông tin k liên quan, k thích hợp Bạn cần học cách đọc ngôn ngữ cử chỉ và thói quen để quyết định được các điều cần thiết cho cùng 1 thông tin Đòi hỏi kỹ năng Có thể có kết quả thiên vị Đòi hỏi 3 người để kiểm tra kết quả và thường k thích hợp với số lượng lớn người 2. Họp nhóm Họp nhóm là việc tập hợp nhiều hơn ba hoặc 1 số người cho một thời hạn nhất định để thảo luận một số chủ đề. Họp nhóm có thể vừa bổ sung và thay thế phỏng vấn.Nó bổ sung phỏng vấn bằng việc cho phép nhóm kiểm tra lại các p/vấn cá nhân. Nó thay thế cho phỏng vấn bằng cách cung cấp một diễn đàn cho mọi người sử dụng cùng ra các đòi hỏi và các giải pháp cho ứng dụng Ưu điểm: - Có thể tạo ra quyết định - Nhận được cả thông tin tổng hợp và chi tiết - Phương pháp tốt cho các yêu cầu bên ngoài - Tập hợp được nhiều người dùng liên quan Nhược điểm: - Nếu số đại biểu nhiều sẽ tốn thời gian cho việc ra quyết định - Tốn thời gian - Các ngắt quãng làm phân tán sự chú ý - Mời k đúng thành viên nên dẫn đến chậm có kết quả - Dễ chuyển sang chủ đề k liên quan 3. Quan sát Quan sát là hoạt động có thể tiến hành thủ công hoặc tự động như sau: - Theo cách thủ công: Người quan sát ngồi tại 1 chỗ và ghi chép các hoạt động, các bước xử lý công việc. Ghi chép or băng ghi hình được dùng để phân tích cho các sự kiện, các mô tả động từ chính, hoặc các hoạt động chỉ rõ lý do, công việc hoặc các thông tin về công việc - Theo cách tự động: máy tính sẽ lưu giữ các chương trình thường trú, lưu lại vết của các chương trình được sử dụng, email và các hoạt động khác được xử lý bởi máy. Các file nhật kí của máy sẽ được phân tích để mô tả công việc - Kỹ sư phần mềm có thể nhận được sự hiểu biết tốt về môi trường công tác hiện tại và quá trình xử lý thông qua quan sát - Kỹ sư phần mềm có thể tập trung vào vấn đề mà k bị ảnh hưởng bởi người khác - Các ngăn cách giữa kỹ sư phần mềm và người được phỏng vấn sẽ được vượt qua bởi quan sát Nhược điểm - Thời gian của quan sát có thể không biểu diễn cho các công việc diễn ra thông thường - Ý nghĩ là đang bị quan sát có thể làm thay đổi thói quen hàng ngày của người bị quan sát - Tốn thời gian 4. Kỹ thuật dùng bảng câu hỏi - Phải trình bày rõ:  Mục đích của bảng câu hỏi,  Mục đích sử dụng những thông tin trong bảng câu hỏi,  Tính bảo mật thông tin trả lời (không tiết lộ ai là người cung cấp thông tin, không để lộ ra ngoài tổ chức…) - Hướng dẫn cách điền: rất cần thiết, cần lưu ý để tránh hiểu nhầm - Thời hạn trả về:  Cần nhắc khi gần đến thời hạn - Câu hỏi trình bày rõ ràng - Hình thức bảng câu hỏi phải dễ dàng để xử lý tự động - Cần để dành chỗ để ghi câu trả lời.  Thêm chỗ cho lời bình  Không phải chỉ ở cuối trang, hay cuối bảng câu hỏi,  Nên dự kiến những câu hỏi nào sẽ có ý kiến thêm thì nên có sẵn chỗ để ghi lời bình ngay dưới câu hỏi đó) - Ưu điểm: Có thể tiến hành với nhiều người Thích hợp với các câu hỏi đóng và hữu hạn - Hạn chế: Các câu hỏi k có trả lời nghĩa là k thu được thông tin Thực hiện và đánh giá có thể chậm Các câu hỏi có thể khó hiệu Không thể thêm các thông tin khi đã tiến hành công việc Thông tin thu được hạn chế trong một phạm vi hẹp Chỉ dùng nó như một biện pháp bổ sung 5. Nghiên cứu tài liệu  Các tài liệu (có thể tìm hiểu những văn bản chung)  Những quy định nội bộ, Các báo cáo liên quan  Những quy định về quy trình nghiệp vụ  Rất khó có đầy đủ văn bản quy định về quy trình nghiệp vụ  Đơn vị đạt chuẩn ISO?  Những quy định “bất thành văn”  Thường dễ hơn kỹ thuật phỏng vấn hay bảng câu hỏi  Thường được tiến hành trước làm cơ sở chuẩn bị cho việc phỏng vấn hay dùng bảng câu hỏi Câu 4: Phân tích sự khác nhau giữa yêu cầu chức năng và yêu cầu phi chức năng - Yêu cầu chức năng: - là danh sách các công việc sẽ được thực hiện trên máy tính cùng với các thông tin mô tả tương ứng. - Cho biết hệ thống sẽ làm gì, chức năng hoặc các dịch vụ của hệ thống một cách chi tiết. - Một số yêu cầu chức năng: Chức năng tính toán Chức năng lưu trữ Chức năng tìm kiếm Chức năng kết xuất Chức năng backup, restore - Yêu cầu phi chức năng - là các yêu cầu liên quan đến chất lượng phần mềm, là sự ràng buộc cách thức thực hiện các yêu cầu chức năng. - Yêu cầu phi chức năng không đề cập trực tiếp tới các chức năng cụ thể của hệ thống. - Yêu cầu phi chức năng thường xác định: Độ tin cậy, tính tiến hoá, tính tương thích, thời gian đáp ứng, các yêu cầu về lưu trữ, bảo mật thông tin Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình - Các yêu cầu phi chức năng xuất hiện là do: Yêu cầu của người sử dụng Ràng buộc về ngân sách Các chính sách của tổ chức sử dụng hệ thống Yêu cầu tương thích giữa phần cứng và phần mềm Các tác nhân ngoài khác - Phân loại các yêu cầu phi chức năng Các yêu cầu về sản phẩm: hiệu năng, khả năng sử dụng, độ tin cậy Các yêu cầu của tổ chức sử dụng hệ thống: thời gian bàn giao, yêu cầu phù hợp với hệ thống cũ Các yêu cầu ngoài được xác định từ các tác nhân bên ngoài như yêu cầu về luật pháp, yêu cầu tôn trọng tính riêng tư Câu 5: Trình bày phương pháp cài đặt và tích hợp từ trên xuống (Top-down) và dưới lên (Bottom up). So sánh ưu nhược điểm 1. Cài đặt và tích hợp từ trên xuống Trong phương pháp cài đặt và tích hợp theo kiểu trên xuống (top-down implementation and integration), nếu module A có lời gọi đến module B thì A được cài đặt và kiểm thử trước B. Để kiểm thử A thì B cần được cài đặt dưới dạng stub. Sau khi A được kiểm thử thì cài đặt stub của B được mở rộng thành cài đặt thực sự [...]... thiết lập từ bên ngoài và được coi như một cơ sở để đề ra kế hoạch của công việc bảo trì Ngoài ra trong nội bộ cơ quan phần mềm, một báo cáo thay đổi phần mềm cũng được tạo ra Nó chỉ ra công sức đòi hỏi để thỏa mãn: một đơn yêu cầu bảo trì, trạng thái ban đầu của yêu cầu sửa đổi, mức ưu tiên yêu cầu, các dữ liệu cho việc sửa đổi 3.3 Lưu giữ các hồ sơ Các thông tin cần lưu giữ trong các tài liệu bảo trì... người đặt hàng 4 Kiểm thử chấp nhận - Kiểm thử chấp nhận tập trung vào 4 yếu tố chính của phần mềm là: tính đúng đắn, tính ổn định, các công việc thực hiện và tài liệu kèm theo - Là kiểm thử cuối cùng đối với phần mềm và được khách hàng thực hiện ( hoặc ủy quyền cho một nhóm thứ 3 thực hiện) - Mục đích của kiểm thử chấp nhận : Chứng minh phần mề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... tra như trường hợp các vòng lặp dạng đơn • Nếu không: kiểm tra như trường hợp các vòng lặp lồng nhau - Vòng lặp không có cấu trúc 3 Kiểm thử Belta - được một hay nhiều người đặt hàng tiến hành - không hiện diện người phát triển - áp dụng phần mềm trong môi trường thực, không có sự kiểm soát của người phát triển - khách hàng sẽ báo cáo tất cả các vấn đề (thực hoặc tưởng tượng) mà họ gặp trong quá trình... hay một nhóm quản lý và chuyên gia kỹ thuật cao cấp 3.2 Báo cáo - Tất cả các yêu cầu về việc bảo trì phần mềm cần được trình bày theo 1 tiêu chuẩn Người phát triển phần mềm thường cung cấp 1 đơn yêu cầu bảo trì còn được gọi là báo cáo các lỗi phần mềm Báo cáo này được người sử dụng điền vào khi yêu cầu công việc bảo trì Nếu xuất hiện lỗi, bản mô tả đầy đủ các tình huống dẫn đến lỗi bao gồm dữ liệu, đoạn... sánh Có thể thấy rằng phương pháp bottom-up có ưu điểm hơn phương pháp topdown ở chỗ là không phải tạo cài đặt dạng stub (các module ở tầng dưới cùng thường phải thử với các driver) Tuy nhiên nó cũng có một nhược điểm khá lớn là: nếu lỗi phát hiện ra muộn, tức là ở các mức ở gần gốc của cây chẳng hạn, lúc đó toàn bộ phần dưới của cây phải xem xét lại Câu 6:Trình bày các phương pháp kiểm thứ phần mềm. .. Mục đích của bảo trì? Tóm tắt các công việc của bảo trì? - Bảo trì phần mềm chính là hoạt động chỉnh sửa chương trình sau khi nó đã được đưa vào sử dụng - Bảo trì thường không bao gồm những thay đổi chính liên quan tới kiến trúc của hệ thống Những thay đổi trong hệ thống thường được cài đặt bằng cách điều chỉnh những thành phần đang tồn tại và bổ sung những thành phần mới cho hệ thống 1 Mục đích của... pháp kiểm thứ phần mềm 1 Kiểm thử hộp đen - Không cần biết cấu trúc bên trong của phần mềm, chỉ quan tâm đến đầu vào và xem kết quả đầu ra có đúng như mong muốn không - Còn được gọi là kiểm thử dựa trên đặc tả (specification based testing) hay kiểm thử chức năng (functional testing): biết chức năng thực hiện ra sao, và kiễm tra nó có thực hiện đúng như mô tả không – Output được tạo ra từ input là chính... có vai trò cân bằng nhau, mỗi nhóm đại diện cho một tập dữ liệu Nguyên tắc là bằng cách kiểm tra triệt để một mục của mỗi tập hợp, chúng ta có thể chấp nhận tất cả các mục tương đương khác của tập hợp đó cũng sẽ được kiểm tra một cách kỹ càng  Phân tích cực biên: Phân tích giá trị cực biên là một dạng nghiêm ngặt của phân hoạch cân bằng có sử dụng các giá trị biên hơn là bất cứ giá trị nào trong tập. .. được thiết lập và bảng tiêu chuẩn những đánh giá được vạch rõ 3.1 Cơ cấu bảo trì - Mặc dù những tổ chức bảo trì chuẩn k được thiếp lập nhưng sự ủy thác trách nhiệm là rất cần thiết kể cả cho các tổ chức phát triển phần mèm nhỏ Những yêu cầu bảo trì được chuyển qua cho người kiểm soát công việc bảo trì và từ đây chuyển tiếp yêu cầu tới người quản lý hệ thống để đánh giá Người quản lý hệ thống là thành... của nhóm kỹ thuật Những nhân viên này là một phần nhỏ của chương trình sản phẩm Khi một yêu cầu được đánh giá, người ủy quyền quản lý việc thay đổi phải quyết định hành động nào được thực hiện tiếp - Cơ cấu được miêu tả ở trên phục vụ cho viêc thiết lập các phạm vi trách nhiệm với công việc bảo trì Người kiểm soát và người ủy quyền quản lý việc thay đổi có thể là 1 người hay một nhóm quản lý và chuyên . để mô tả công việc - Kỹ sư phần mềm có thể nhận được sự hiểu biết tốt về môi trường công tác hiện tại và quá trình xử lý thông qua quan sát - Kỹ sư phần mềm có thể tập trung vào vấn đề mà k bị. hoạch mô tả tỷ mỷ quy trình phần mềm bao gồm mô hình vòng đời phần mềm được sử dụng, cơ cầu tổ chức của các công ty phần mềm, mục tiêu của dự án, các kĩ thuật, các công cụ CASE được sử dụng,. CÔNG NGHỆ PHẦN MỀM Câu 1: Tóm tắt các bước trong quá trình phát triển phần mềm? 1. Pha xác định yêu cầu Người phát triển phần mềm sẽ tiếp thu các yêu cầu, chức năng các công việc cần