Câu 1: Phân tích mô hình thác nước. Liên hệ với bài tập lớn em đã làm

Trả Lời:

Mô hình thác nước xem quá trình xây dựng một sản phẩm phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì chuyển đến giai đoạn sau

+) Ưu Điểm:

-         Dễ quản lí

-         Ước lượng thời gian và chi phí rất chính xác

+) Nhược Điểm:

-         Rủi ro cao

-         Đòi hỏi khách hàng đưa ra yêu cầu chính xác ngay từ đầu

+) Ứng Dụng:

-         Khách hàng đưa ra yêu cầu ngay từ đầu

-         Nhà phát triển hiểu hệ thống

So với bài tập lớn em đã làm thì em áp dụng mô hình thác nước trong suốt quá trình làm bài tập lớn. Theo đúng cách hoàn thành xong giai đoạn này thì chuyển sang giai đoạn khác

Câu 2: Phân tích mô hình xoắn ốc, liên hệ với bài tập lớn em đã làm

Trả Lời:

Mô hình xoắn ốc có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu và đồng thời thêm một thành phần mới – Phân tích rủi ro. Bao gồm 4 hoạt động chính

Planning: Xác định mục tiêu, tương tác và ràng buộc

Riskanalysis: Phân tích các lựa chọn và chỉ định / giải quyết rủi ro

Engineering: Phát triển sản phẩm

Customerevaluation: Đánh giá kết quả xây dựng

+) Ưu Điểm:

-         Loại bỏ được khoảng cách giữa nhà sản xuất và khách hàng

-         Khắc phục được nhược điểm của mô hình khác

-         Sử dụng mô hình mẫu + phân tích rủi ro

-         Sử dụng mô hình thác nước + mô hình lặp

+) Khuyết điểm:

-         Mô hình mới

-         Đòi hỏi khách hàng có kĩ năng đánh giá tốt và việc phân tích rủi ro cũng phải tốt

Câu 3: So sánh mô hình mẫu và mô hình tiến hoá

Trả Lời :

+) Giống nhau:

-         Rút ngắn khoảng cách giữa khách hàng và người phát triển hệ thống

-         Hệ thống dễ kết cấu kém

-         Khách hàng không hiểu rõ về hệ thống

+) Khác nhau:

Mô Hình Mẫu

- Khách hàng có thể biết được hệ thống ngay từ ban đầu

- Mô hình này dễ thất bại

- Người sản xuất hiểu được hệ thống

- Người sản xuất không chắc về hiệu quả giao diện

Mô Hình Tiến Hoá

- Không lãng phí các bản mẫu

- Nhà sản xuất không hiểu biết về công nghệ

- Khách hàng không thể biết được hệ thống từ ban đầu

Câu 4 : So Sánh mô hình lặp và mô hình tăng dần

Trả Lời :

+) Giống nhau: Giống mô hình tiến hoá nhưng mà mẫu thì được đưa vào sử dụng

-         Phiên bản mẫu đầu tiên thì phải có được 1 số chức năng chính cốt lõi, phần mềm

+) Khác Nhau

Mô Hình Lặp

Có đầy đủ các chức năng ở phiên bản đầu -> tiếp tục lặp và phát triển các phiên bản sau

- Đội ngũ phát triển quen thuộc với lĩnh vực dự án nhưng không có nhiều kinh nghiệm, nhất là về công nghệ được dùng phát triển dự án.

- Khách hàng không hiểu rõ về hệ thống

- Có nhiều rủi ro về mặt kĩ thuật

Mô Hình Tăng Dần

- Phiên bản đầu không đầy đủ các chức năng mà là do phiên bản thứ 2 bổ xung vào các chức năng đó riêng khi chu trình thứ 2 thì không bắt buộc phải làm như khúc đầu mà có thể áp dụng ở mô hình khác

- Đội ngũ phát triển quen thuộc với lĩnh vực của dự án và có nhiều kinh nghiệm.

- Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai sớm một số phần của hệ thống

Câu 5: Mô tả sơ lược các kĩ thuật thu thập yêu cầu

Trả Lời: 

PP1: Phỏng vấn

+) Lúc ban đầu

-         Chào hỏi, giới thiệu

-         Đặt câu hỏi dễ, mang tính bao quát

-         Chú ý tới câu trả lời để dẫn dắt phần tiếp theo

-         Chú ý tới thái độ, trung thực của người phỏng vấn

+) Đoạn giữa:

-         Vấn đề chính

-         Với những vấn đề quan trọng, không được trả lời rõ ràng thì chúng ta nên gợi ý

+) Kết thúc: Tổng quát-> khách hàng

            Ưu điểm: Cơ bản lấy được đầy đủ thông tin

            Nhược điểm: Không thu thập được nhiều ý kiến

PP2: Phương pháp họp nhóm :

Ba người trở lên

o       Chuẩn bị nội dung : Lịch trình từ trước

o       Cung cấp nội dung, lịch trình trước cho người tham gia

o       Tập trung để lấy những thông tin: Tổng quát, chi tiết nhất

Ưu điểm:

-         Lấy được thông tin , tổng quát, chi tiết

-         Lấy được thông tin từ nhiều người

Nhược điểm: Gây nhiều tranh cãi

PP3: Phương pháp quan sát thủ công

+) Thủ công : Quan sát , ghi chép lại, những hoạt động xử lí

+) Tự động : Hoạt động xử lí trong máy tính

Tiến trình

-         Hỏi ý kiến người bị quan sát

-         Chọn vị trí thích hợp

-         Chọn lọc thông tin theo chủ đề định trước

+) Điều tra qua bảng câu hỏi

Điều tra qua câu hỏi là xây dựng các câu hỏi để phỏng vấn trên giấy hoặc máy tính. Các câu hỏi được dùng để nhận các thông tin từ số lượng lớn người sử dụng và thường ở dạng khả năng lựa chọn, người trả lời chỉ việc đánh dấu. Các mục câu hỏi, như là phỏng vấn, có thể là câu hỏi mở hoặc câu hỏi đóng nhưng không chỉ rõ tên, dẫn đến các câu trả lời trung thực hơn nhiều phỏng vấn.

Ưu điểm :

§         Các trả lời không cần biết tên nên quan điểm và cảm nhận thu được là trung thực

§         Có thể tiến hành với nhiều người

Hạn chế :

§         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

§         Khó tiến hành

§         Chỉ dùng nó như một phương pháp bổ sung,...

PP4: Xem xét tài liệu

            Qui định, qui chế , phiếu, bảng biểu

            Lấy những thông tin chi tiết, qui trình

è    Thông tin qui trình CSDL -> đưa ra những câu hỏi

Hệ thống cũ lấy những thông tin về quá trình, chức năng, lấy những thông tin cần bổ xung, nâng cấp ở phần mềm trước

Câu 6: Nêu cấu trúc của bản đặc tả yêu cầu

Trả lời:

Trả lời:

Bản đặc tả yêu cầu gồm các phần

1.      Giới thiệu mô tả mục đích khái quát, chức năng, thuật ngữ, từ viết tắt, từ chuyên ngành,

Mô tả về mô hình chung cho hệ thống

·        Mô tả chức năng hay phi chức năng

·        Những yêu cầu chức năng

·        Những yêu cầu phi chức năng

·        Hướng phát triển của hệ thống : làm được gì, giới hạn, định hướng

·        Đặc tả chi tiết các yêu cầu

·        Có thể có các thành phần

·        Nêu ra các phần cứng

·        Mục lục

·        Yêu cầu về cơ sở dữ liệu

Tài liệu đặc tả yêu cầu dựa theo chuẩn IEEE

1. Giới thiệu

     1.1. Mục đích của tài liệu yêu cầu

1.2. Phạm vi của sản phẩm

1.3. Các định nghĩa, từ viết tắt

1.4. Các tham chiếu

1.5. Tổng quan về tài liệu yêu cầu

2. Mô tả chung           

2.1. Giới thiệu chung về sản phẩm

2.2. Các chức năng của sản phẩm

2.3. Đặc điểm của người sử dụng

2.4. Các ràng buộc

2.5. Giả thiết và các phụ thuộc

3. Đặc tả yêu cầu: bao gồm các yêu cầu chức năng, phi chức năng, miền ứng dụng và giao diện.

4. Phụ lục

5. Chỉ mục

6.  Đánh giá các yêu cầu

Đánh giá yêu cầu phần mềm liên quan tới việc cho biết các yêu cầu đã được định nghĩa có đáp ứng được các đòi hỏi của khách hàng không. Nếu việc đánh giá này không chính xác thì việc thiết kế hệ thống và triển khai hệ thống cũng bị ảnh hưởng. Chi phí sửa chữa lỗi sẽ rất lớn.

Một số vấn đề của yêu cầu cần được đánh giá là:

§         Giá trị: người dùng có thể nghĩ rằng hệ thống cần một số chức năng, tuy nhiên sau một số phân tích, có thể xác định các chức năng khác cần được đưa vào. Vì vậy cần xác định đầy đủ các yêu cầu.

§         Chắc chắn: mọi yêu cầu không được mâu thuẫn với các yêu cầu khác

§         Hoàn chỉnh: định nghĩa cần phải bao gồm mọi chức năng và các ràng buộc,

§         Hiện thực: không có các yêu cầu đặc biệt đến mức phi hiện thực.

Các xem xét yêu cầu có thể là hình thức hoặc phi hình thức. Xem xét phi hình thức liên quan tới việc các người ký hợp đồng thảo luận các yêu cầu với khách hàng. Nhiều vấn đề có thể được giải quyết dễ dàng khi thảo luận trực tiếp với khách hàng. Đối với các yêu cầu xem xét hình thức, đội phát triển phải dẫn dắt khách hàng thông qua các yêu cầu hệ thống, giải thích các triển khai của mỗi yêu cầu.

Câu 7: Nêu cấu trúc phân cấp của 1 phần mềm và 1 số yêu cầu thiết kế khi thiết kế kiến trúc phần mềm

Trả Lời:

Một số chỉ số của bản cấu trúc phân cấp thủ tục:

§         Chiều rộng: độ trải rộng của toàn bộ cấu trúc phân cấp

§         Chiều sâu: độ cao của cấu trúc phân cấp

§         Số module ra của một module: số các module trực tiếp bị điều khiển của module đó

§         Số module vào của một module: số các module trực tiếp điều khiển module đó

§         Thượng cấp: là module điều khiển module khác

§         Thuộc cấp: là module bị module khác điều khiển

Cấu trúc một chương trình và các chỉ số được minh họa như hình dưới đây:

Một số yêu cầu thiết kế khi thiết kế kiến trúc phần mềm là:

Yêu cầu:

·        Vạch ra các thành phần của phần mềm

·        Mô hình của phần mềm

·        Giải thích, đặc tả về mô hình

·        Dễ hiểu và dễ đọc

·        Linh hoạt với những yêu cầu thay đổi

·        Giảm kích thước của mô hình

·        Giảm chiều rộng

·        Giảm chiều sâu

·        Chỉ rõ các module chưa làm được

·        Giả sử giao diện của modunle

Câu 8: Nêu các yêu cầu thiết kế giao diện phần mềm, phân biệt sự khác nhau giữa yêu cầu người dùng và yêu cầu hệ thống

Trả Lời :

Các yêu cầu khi thiết kế giao diện phần mềm :

Đảm bảo sự quen thuộc của người dùng

Giao diện phải có tính thống nhất

Đảm bảo khả năng phục hồi

Giao diện phải có tính đa dạng

Yêu Cầu Người Dùng

Không quan tâm đến cấu truc bên trong

Đánh giá và cảm nhận qua giao diện tương tác

Yêu Cầu Hệ Thống

Chú trọng cấu trúc bên trong của hệ thống

Đánh giá hệ thống qua các chức năng và cấu trúc của nó

Câu 10: Nêu sơ lược các bước trong một qui trình kiểm thử phần mềm

Trả Lời :

Quy trình kiểm thử phần mềm bao gồm các bước

·        Lập kế hoạch kiểm tra

·        Thiết kế test case

·        Phát triển test script

·        Thực hiện test

·        Đánh giá kết quả test

+) Lập kế hoạch : Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch KTPM bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực lượng kiểm tra viên

+) Thiết kế test: Nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phiên PM. Giai đoạn thiết kế test là hết sức quan trọng, hết sức quan trọng , nó đảm bảo tất cả các tình huống kiểm tra hết tất cả các yêu cầu

            Các bước thiết kế test

·        Xác định và mô tả test cây

·        Mô tả các bước chi tiết để kiếm tra

·        Xem xét và khảo sát độ bao phủ của việc kiểm tra

·        Xem xét test case và các bước kiểm tra

+) Phát triển test Script: Bước này thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạy trên máy tính giúp tự động hoá việc thực thi các bước kiểm tra đã định nghĩa ở các bước thiết kế test

+) Thực hiện test

Mục đích thực hiện các bước kiểm tra đã thiết kế và ghi nhận kết quả

+) Đánh giá test

Mục đích: Đánh giá toàn bộ quá trình kiểm tra bao gồm xem xét và đánh giá kết quả kiểm tra lỗi, chỉ định các yêu cầu thay đổi và tính toán số liệu liên quan, đến quá trình kiểm tra

Câu 11: Nêu sơ lược các mức độ kiểm thử phần mềm

Trả Lời :

1. Kiểm thử đơn vị :là tiến trình kiểm thử tập trung vào các đơn vị nhỏ nhất của thiết kế phần mềm đó là hàm, các lớp, các thủ tục hoặc các phương thức. Kiểm thử đơn vị bao giờ cũng hướng theo hộp trắng và bước này có thể được tiến hành song song cho nhiều môđun.

 Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản nên không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng một đơn thể đơn vị đang kiểm tra. Thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức độ kiểm tra sau đó.

 Unit Test thường do lập trình viên thực hiện. Công đoạn này được thực hiện cùng với giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.

 Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng.

2.2.  Kiểm thử tích hợp (Integration Test)

Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành. Kiểm thử mức đơn vị là kiểm tra các thành phần, các đơn vị riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

 Integration Test có 2 mục tiêu chính:

§      Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

§      Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ, và cuối cùng là nguyên hệ thống hoàn chỉnh để chuẩn bị kiểm tra ở mức hệ thống.

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Với các Unit đã qua giai đoạn Unit test với các giao tiếp giả lập thì vẫn cần thiết phải thực hiện Itegration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến nhiều tình huống khác với giả lập giao tiếp.

2.3.  Kiểm thử mức hệ thống (System Test)

Mục đích của kiểm tra hệ thống là kiểm tra 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.

Có 2 cách :

·        Kiểm thử Alpha

-   Được bên phát triển tiến hành

-   Phần mềm sẽ được dùng trong bối cảnh tự nhiên để người phát triển đứng vào vai trò người sử dụng và báo cáo các sai và các vấn đề sử dụng

-   Được tiến hành trong một môi trường được điều khiển (theo kế hoạch của người phát triển)

·        Kiểm thử Beta

-   Được một hay nhiều người đặt hàng tiến hành

-   Không có sự 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 đề mà họ gặp trong quá trình kiểm thử cho người phát triển một cách định kỳ

-   Dựa theo báo cáo đó người phát triển tiến hành sửa đổi và chuẩn bị phân phối bản phát hành cho toàn bộ các người đặt hàng

2.4.  Kiểm thử chấp nhận phần mềm (Acceptance Test)

Kiểm thử chấp nhận được khách hàng thực hiện. Mục đích của kiểm thử chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm chưa.

Kiểm thử chấp nhận có ý nghĩa quan trọng, mặc dù hầu hết mọi trường hợp, các phép kiểm tra của kiểm thử hệ thống và kiểm thử chấp nhận gần tương tự như nhau, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả của kiểm thử chấp nhận sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu và sự mong chờ của khách hàng

2.5.  Kiểm thử hồi quy (Regression Test)

Kiểm thử hồi quy không phải là một mức kiểm tra như các mức khác nói trên. Nó đơn thuần kiểm tra lại phần mềm sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản phần mềm mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng đã hoạt động tốt. Kiểm thử hồi quy có thể thực hiện tại mọi mức kiểm tra.