Tài liệu Tìm hiểu quy trình quản lý yêu cầu và kiểm thử tại phòng phát triển phần mềm trung tâm tin học đại học khoa học tự nhiên. xây dựng ứng dụng hỗ trợ

Lời cám ơn Lời đầu tiên, chúng con xin gửi đến cha mẹ lòng biết ơn, sự tôn kính của chúng con. Cha mẹ đã sinh dưỡng và không ngại khó khăn tạo mọi điều kiện tốt nhất cho chúng con có được ngày hôm nay. Chúng em xin chân thành cám ơn thầy Trần Đan Thư, thầy Nguyễn Trọng Tài đã tận tâm hướng dẫn chúng em, giúp đỡ chúng em hoàn thành đề tài này. Chúng em cũng xin cám ơn các anh chị làm việc trong phòng phát triển phần mềm Trung tâm Tin học trường Đại học Khoa học Tự nhiên đã sẵn sàng giúp đỡ chúng em, cung cấp các thông tin cho chúng em trong quá trình khảo sát. Chúng em cũng xin cám ơn các thầy cô, cán bộ giảng viên trẻ đã nhiệt tình đóng góp những kinh nghiệm, ý Đ kiến quý báu cho chúng em. Chúng em xin gửi lời cám ơn tất cả các quý thầy cô đã giảng dạy, cung cấp cho – chúng em vốn kiến thức quý báu suốt những năm học vừa qua. C N TT Chúng em cám ơn khoa Công nghệ thông tin trường Đại học Khoa học Tự nhiên đã tạo điều kiện cho chúng em thực hiện đề tài này. Chúng tôi cũng xin cám ơn các bạn đã nhiệt tình giúp đỡ khi chúng tôi vướng phải những khó khăn, động viên chúng tôi trong suốt quá trình thực hiện đề tài luận K H O A văn tốt nghiệp này. Mặc dù chúng em đã cố gắng rất nhiều để hoàn thành tốt luận văn, nhưng chắc chắn không tránh khỏi những thiếu sót, chúng em rất mong được sự cảm thông và tận tình giúp đỡ của quý thầy cô. Tp. Hồ Chí Minh, 07/2004 Nhóm sinh viên thực hiện Nguyễn Khánh Chi- Tăng Nguyễn Trung Hiếu 1 Lời mở đầu Sau cuộc khủng hoảng trong ngành công nghệ thông tin vào đầu những năm K H TN 2000, đến nay, công nghệ sản xuất phần mềm trên thế giới và nhất là Việt Nam đang tiến những bước tiến mạnh mẽ hơn. Vượt qua cuộc khủng hoảng này, ngoài những kinh nghiệm trong kinh doanh, các công ty tin học Việt Nam nhận thức được rằng quy trình sản xuất phần mềm của chính công ty họ cần được nâng cấp với mục tiêu đầu tiên là nâng cao chất lượng, gia tăng tính chuyên nghiệp trong sản xuất phần mềm. Một điều không thể tranh cãi , quy trình đóng một vai trò rất quan trọng trong H việc sản xuất phần mềm. Hiện nay có rất nhiều quy trình sản xuất phần mềm như Quy Đ trình RUP, Quy trình xoắc ốc, Quy trình thác nước.., nhưng điều cốt lõi nhất là ứng dụng những quy trình đó như thế nào và ứng dụng như vậy sẽ đạt được những thuận lợi – gì, quá trình sản xuất phần mềm có tốt hơn không, chất lượng phần mềm có được nâng C N TT cao hay không. Trong một quy trình sản xuất phần mềm, ngoài việc thành lập các chuẩn coding, phân công sắp xếp các công việc cho các thành viên trong tổ chức, một yếu tố rất quan trọng là việc quản lý các tài liệu bao gồm các bản đặc tả yêu cầu, bản phân tích thiết kế chương trình, chương trình nguồn, các bản báo cáo kiểm thử và vô số những tài liệu không tên khác. Trong bối cảnh đó, chúng em đã thực hiện đề tài “Tìm hiểu về quản lý yêu cầu K H O A và kiểm thử tại Phòng phát triển phần mềm Trung Tâm Tin Học trường ĐHKHTN_Xây dựng phần mềm hỗ trợ” nhằm có thể hiểu rõ hơn việc quản lý yêu cầu và kiểm thử, những mục tiêu, thuận lợi mà hai tiến trình này đem lại. Đề tài này có thể được xem như một phần trong việc quản lý cấu hình, trong đó chú trọng ở hai giai đoạn khảo sát và kiểm thử. Luận văn của chúng em được trình bày với tám chương chính, bao gồm : 2 - Chương 1 Mở đầu - Chương 2 Tổng quan về SQA (Software Quality Assurance) và các công việc quản lý yêu cầu, quản lý kiểm thử Chương 3 Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay. - K H TN - Chương 4 Giới thiệu về ứng dụng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements and Testing Management) Chương 5 Thực hiện _ Kiểm tra ứng dụng - Chương 6 Tổng kết K H O A C N TT – Đ H - 3 Mục lục Chương 1 Mở đầu................................................................................................................ 9 Khái quát vai trò quy trình phát triển phần mềm........................................................... 9 1.2 Tầm quan trọng của việc quản lý quy trình .................................................................. 10 1.3 Hiện trạng phát triển phần mềm tại T3H...................................................................... 10 1.4 Đánh giá hiện trạng ........................................................................................................ 19 1.4.1 1.4.2 1.5 K H TN 1.1 Quản lý yêu cầu : ............................................................................................................................19 Quản lý kiểm thử :...........................................................................................................................19 Mục tiêu đề tài ................................................................................................................ 20 Chương 2 Tổng quan về SQA và các công việc quản lý yêu cầu, quản lý kiểm thử ...... 21 Vai trò của việc quản lý chất lượng phần mềm ............................................................. 21 2.2 Tại sao cần quản lý chất lượng ?.................................................................................... 24 2.3 Tổng quan về quản lý yêu cầu........................................................................................ 25 Đ H 2.1 2.4.1 2.4.2 2.4.3 Tổng quan về quản lý kiểm thử...................................................................................... 28 Mục tiêu của quản lý kiểm thử........................................................................................................28 Các thông tin cần quản lý trong quản lý kiểm thử...........................................................................29 Giới thiệu tiến trình Verification (VER) trong CMMI....................................................................30 Chương 3 3.1 Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay 32 Công cụ hỗ trợ quản lý yêu cầu...................................................................................... 32 Giới thiệu : ......................................................................................................................................32 Định nghĩa công cụ quản lý yêu cầu ...............................................................................................33 Các loại công cụ..............................................................................................................................33 Tại sao phải sử dụng các công cụ quản lý yêu cầu :........................................................................34 Kiến trúc chức năng : ......................................................................................................................35 So sánh với các phần mềm có chức năng tương tự : .......................................................................37 Đánh giá các công cụ quản lý yêu cầu ............................................................................................38 K H O A 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 C N TT 2.4 Quản lý yêu cầu là gì ?....................................................................................................................25 Các thông tin cần quản lý trong quản lý yêu cầu. ..........................................................................25 Giới thiệu tiến trình RM (Requirement Management) trong CMMI...............................................27 – 2.3.1 2.3.2 2.3.3 3.2 3.2.1 3.2.2 Công cụ kiểm thử : ......................................................................................................... 38 Các loại công cụ kiểm thử :.............................................................................................................38 Một số công cụ quản lý kiểm thử :..................................................................................................41 Chương 4 Xây dựng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements and Testing Management)....................................................................................................... 44 4.1 Mục tiêu của ứng dụng................................................................................................... 44 4.2 Thủ tục cho các quy trình được xây dựng mới.............................................................. 44 4.3 Đặc tả yêu cầu................................................................................................................. 49 4 4.4 Thiết kế ứng dụng........................................................................................................... 51 4.5 Mô hình dữ liệu .............................................................................................................. 72 4.5.1 4.5.2 Mô hình use case.............................................................................................................................51 Đặc tả use case ................................................................................................................................52 Kiến trúc hệ thống...........................................................................................................................73 Thiết kế màn hình ...........................................................................................................................77 Chương 5 Thử nghiệm ứng dụng..................................................................................... 89 K H TN 4.4.1 4.4.2 5.1 Dữ liệu thử nghiệm ......................................................................................................... 89 5.2 Kết quả thực hiện chương trình..................................................................................... 91 Giới thiệu project thử nghiệm : .......................................................................................................89 Bộ dữ liệu thử nghiệm :...................................................................................................................90 Chương 6 6.1 Tự đánh giá..................................................................................................................... 92 6.1.1 6.2 Tổng kết ............................................................................................................ 92 Những kết quả đạt được : ................................................................................................................92 Hướng phát triển của chương trình. .............................................................................. 93 H 5.1.1 5.1.2 Đ Phụ lục ..................................................................................................................................... 95 Mô tả dữ liệu ................................................................................................... 95 Phụ lục B. RM Tool Survey Summary [INCOSE]............................................................ 98 K H O A C N TT – Phụ lục A. 5 Danh sách các hình K H O A C N TT – Đ H K H TN Hình 1-1 Mô hình phát triển phần mềm theo quy trình thác nước tại T3H .............................. 11 Hình 1-2 Sơ đồ tổ chức các vai trò của nhân sự trong 1 đề án phần mềm ............................... 14 Hình 1-3 Mô hình quản lý yêu cầu tại T3H .............................................................................. 16 Hình 1-4 Mô hình kiểm thử tại T3H......................................................................................... 18 Hình 2-1 Các hoạt động trong CM ........................................................................................... 22 Hình 2-2 Tổng quan về CM...................................................................................................... 23 Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI) ............................................................. 27 Hình 5-1 Mô hình tiến trình quản lý yêu cầu cho hệ thống mới............................................... 45 Hình 5-2 Mô hình quản lý kiểm thử cho hệ thống mới ............................................................ 48 Hình 5-3 Mô hình usecase ....................................................................................................... 51 Hình 5-4 Kiến trúc hệ thống ..................................................................................................... 73 Hình 5-5 Kiến trúc Phần mềm quản lý yêu cầu và kiểm thử.................................................... 75 Hình 5-6 Các lớp xử lý yêu cầu ................................................................................................ 76 Hình 5-7 Các lớp xử lý kiểm thử .............................................................................................. 76 Hình 5-8 Sơ đồ màn hình cho phần truy cập cơ sở dữ liệu ...................................................... 77 Hình 5-9 Sơ đồ các trang tổng quát .......................................................................................... 77 Hình 5-10 Sơ đồ nhóm các màn hình liên quan đến phần quản lý yêu cầu.............................. 78 Hình 5-11 Sơ đồ các màn hình liên quan đến phần kiểm thử................................................... 79 Hình 5-12 MH. Trang chính ..................................................................................................... 80 Hình 5-13 MH.Thông tin yêu cầu tổng quát............................................................................ 81 Hình 5-14 MH. Cập nhật tài liệu mô tả yêu cầu. ...................................................................... 82 Hình 5-15 MH. Cây kiến trúc của project ................................................................................ 83 Hình 5-16 MH. Thiết lập mối liên hệ giữa các yêu cầu và phân hệ ......................................... 84 Hình 5-17 MH. Các release trong Project................................................................................. 84 Hình 5-18 MH. Cập nhật môi trường kiểm tra. ........................................................................ 85 Hình 5-19 MH. Các release và file đã được lập testcase. ......................................................... 86 Hình 5-20 MH. Cập nhật thông tin review ............................................................................... 87 6 Thuật ngữ / Từ viết tắt / Khái niệm Là những chương trình, những thủ tục Phần mềm _Software được gắn liền với các tài liệu mô tả và các K H TN dữ liệu có liên quan đến tác vụ của một hệ thống máy tính.[PGSQM] Việc thỏa mãn một sản phẩm theo đúng sự Chất lượng _Quality mong đợi của khách hàng, dựa vào những Quality Control định trước đó nhằm dò tìm, dẫn chứng qua các tài liệu, phân tích, và hiệu chỉnh các – Assurance hay Kiểm soát chất lượng _ Là một tập các hành động đã được dự Đ Việc đảm bảo chất lượng _Quality H yêu cầu cho sản phẩm.[PGSQM] C N TT lỗi của sản phẩm cũng như quản lý các thay đổi của sản phẩm.[PGSQM] Quản lý chất lượng _ Quality Là việc ủy nhiệm, xúc tiến nhà sản xuất Management nhận ra, chấp thuận các cải tiến cho tiến trình sản xuất sản phẩm.[PGSQM] Software Quality Assurance SQS Software Quality System CM Configuration management T3H Phòng phát triển phần mềm Trung tâm K H O A SQA Tin học trường Đại học Khoa học Khoa học Tự nhiên. Mỗi khi việc coding hoàn tất ở một phân Internal release 7 hệ hay một phần cụ thể nào đó của project, project manager hay coding manager sẽ compile cho một bản release. Bản release này sẽ được kiểm tra, sửa lỗi K H TN dùng trong nội bộ cơ quan. Release sẽ được giao cho khách hàng khi Release chương trình đã hoàn tất Capability Maturity Model Integration RM Requirement Management K H O A C N TT – Đ H CMMI 8 Chương 1 Mở đầu Chương 1 Mở đầu 1.1 Khái quát vai trò quy trình phát triển phần mềm K H TN Thưở ban đầu của ngành công nghiệp máy tính nói chung và công nghệ phần mềm nói riêng, việc phát triển phần mềm được xem như một quá trình “viết và sửa” (code and fix), không có bất kỳ một kế hoạch nào trước đó. Quá trình này thành công cho đến khi các chương trình phần mềm bắt đầu có quy mô lớn hơn, độ phức tạp cao hơn, cần có sự hợp tác của nhiều người hơn, do đó các phương pháp phát triển phần mềm hay quy trình phần mềm ra đời.Thực tế cho thấy, hầu hết các dự án thất bại do H các nguyên nhân sau 1 : Đ · Hiểu không đúng yêu cầu người dùng · Không thể thích ứng với các thay đổi về yêu cầu đối với hệ thống. – · Các module không khớp với nhau. C N TT · Phần mềm khó bảo trì và nâng cấp, mở rộng. · Phát hiện trễ các lỗ hổng của dự án. · Chất lượng phần mềm kém. · Hiệu năng của phần mềm thấp. K H O A · Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi nào, ở đâu, tại sao phải thay đổi. · Quá trình build-and-release không đáng tin cậy. Để khắc phục những rủi ro này đòi hỏi việc phát triển phần mềm phải theo một quy trình cụ thể đảm bảo phần mềm được xây dựng đảm bảo được chất lượng, thỏa mãn các yêu cầu của người dùng. 1 [LVRUP99] 9 Chương 1 Mở đầu 1.2 Tầm quan trọng của việc quản lý quy trình Như đã đề cập ở trên, việc thỏa mãn nhu cầu (Fitness for purpose) của người dùng rất quan trọng, đó là đích cuối cùng cho mọi sản phẩm được sản xuất ra. Vì vậy, K H TN việc đảm bảo chất lượng phần mềm cũng là một phần rất quan trọng trong quá trình sản xuất phần mềm và do đó, việc quản lý chất lượng cũng được đặt ra. Hơn thế nữa, quan điểm hiện đại về việc đảm bảo chất lượng ngày càng phức tạp hơn, không còn giới hạn ở mục tiêu thỏa yêu cầu khách hàng. Một sản phẩm phần mềm chất lượng cao (high quality product) phải kết hợp được nhiều nhân tố chất lượng (quality factors) hay thuộc tính chất lượng (Quality Attributes), trong đó có thể chia H làm ba loại, đó là những nhân tố có thể tìm thấy trong đặc tả yêu cầu ví dụ như tính Đ linh động (portability), là “cutural factors” ví dụ như tính hiệu dụng (usability), và những nhân tố mà người lập trình sẽ chú trọng nhưng người dùng thì không, đơn cử là – tính tái sử dụng (reusability). Để một sản phẩm đặt ra đạt được những nhân tố chất lượng này không phải là một việc dễ dàng, vì vậy, việc quản lý chất lượng phần mềm C N TT là một công việc không thể tránh khỏi trong công nghệ phần mềm. 1.3 Hiện trạng phát triển phần mềm tại T3H T3H phát triển phần mềm theo quy trình thác nước bao gồm các giai đoạn sau : · Khảo sát hiện trạng – xác định yêu cầu K H O A · Lập giải pháp khả thi · Phân tích · Thiết kế · Coding · Kiểm thử · Triển khai và bảo trì Quy trình được minh họa qua sơ đồ 10 Chương 1 Mở đầu NV quaûn lyù ñeà aùn Thieá t keá phaà n meàm Xaây döïng phaà n meà m – NV laäp trình Kieåm tra & thöû nghieä m noäi boä C N TT NV phaân tích _ thieát keá NV kieåm tra NV laäp trình K H TN NV phaân tích _ thieát keá Khaû o saù t phaân tích H NV phaân tích _ thieát keá Laä p giaû i phaùp khaû thi Đ NV phaân tích _ thieát keá NV quaûn trò heä thoáng Laäp keá hoaïch & theo doõi tieá n ñoä â NV huaán luyeän Trieå n khai NV huaán luyeän K H O A NV phaân tích _ thieát keá NV laäp trình NV quaûn lyù caáu hình Hoaø n chænh saû n phaåm Quaû n lyù caá u hình Hình 1-1 Mô hình phát triển phần mềm theo quy trình thác nước tại T3H 11 MÔ TẢ CÁC GIAI ĐOẠN TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM Mô tả công việc chung Kết quả đầu ra 1. 2. 3. Tài liệu khảo sát phân tích 1. Khảo sát chi tiết 2. Mô tả và phân tích hiện trạng (chi tiết hơn Giải pháp khả thi) : - Quy trình nghiệp vụ - Sơ đồ tổ chức xử lý - Mối liên quan với hệ thống khác 3. Phân tích sơ bộ - Mô hình dữ liệu sơ bộ - Yêu cầu nghiệp vụ - Yêu cầu hệ thống - Yêu cầu giao diện - Yêu cầu sao lưu - Yêu cầu bảo mật - Yêu cầu đường truyền (gửi/nhận) dữ liệu - Yêu cầu về chuyển đổi, cập nhật dữ liệu cũ 4. Tập hợp các tài liệu đã thu thập từ quá trình khảo sát 1. Thiết kế kiến trúc phần mềm 2. Thiết kế dữ liệu mức vật lý. 3. Thiết kế chiến lược: - Các quy ước chung - Cơ chế phát sinh khóa - Kiểm tra RBTV - Xử lý và thông báo lỗi - Sao lưu và phục hồi dữ liệu - Bảo mật - Truyền (gửi/nhận) dữ liệu 4. Thiết kế chức năng: - Sơ đồ màn hình - Màn hình chính và hệ thống thực đơn -Màn hình - Báo biểu - Thuật tóan xử lý chính trên các màn hình và báo biểu 5. Xây dựng prototype chương trình H 1. Khảo sát khả thi 2. Mô tả và phân tích hiện trạng : chú trọng đến tính khả thi của quy trình nghiệp vụ sẽ được tin học hóa. 3. Xác định yêu cầu nghiệp vụ 4. Xác định yêu cầu kỹ thuật 5. Đề xuất giải pháp thực hiện - Kiến trúc kỹ thuật - Vấn đề chuyển đổi, cập nhật dữ liệu cũ - Kinh phí - Thời gian thực hiện 6. Thương thảo hợp đồng Tài liệu giải pháp khả thi Lập kế họach và theo dõi tiến độ Quản lý cấu hình Xem xét và duyệt kết quả công việc 4. Tập huấn, chuyển giao kết quả công việc -Tài liệu giải pháp khả Tài liệu khảo sát phân tích thi -Hợp đồng đã ký K H O A Mô tả công việc cụ thể của giai đoạn Thiết kế phần mềm Đ Tài liệu đầu vào Khảo sát – phân tích – Lập giải pháp khả thi Xây dựng phần mềm Kiểm tra và thử nghiệm nội bộ - Tài liệu khảo sát phân tích - Tài liệu khảo sát phân tích - Tài liệu thiết kế phần - Tài liệu thiết kế phần mềm mềm - Chương trình - Prototype chưong trình 1. Thiết kế chung kỹ thuật: - Biến dùng chung - Thư viện hàm: các hàm dùng chung, các hàm hệ thống - Các lớp đối tượng (hoặc màn hình) cơ sở 2. Thiết kế chi tiết chức năng 3. Cài đặt CSDL 4. Lập trình và kiểm thử cục bộ 1.Thiết kế kịch bản kiểm tra 2.Kiểm tra từng chức năng: - Kỹ thuật - Nghiệp vụ 3. Kiểm tra tích hợp 4.Chỉnh sửa các lỗi của chương trình 5.Thủ nghiệm chuyển đổi từ dữ liệu cũ 6. Lập tài liệu hướng dẫn C N TT Gđoạn K H TN Chương 1 Mở đầu - Tài liệu thiết kế phần mềm - Prototype chương trình 12 - Tài liệu Xây dựng phần mềm - Script phát sinh CSDL - Chương trình -Tài liệu Kết quả -Kiểm tra chương trình -Tài liệu hướng dẫn -Chương trình đã kiểm tra Chương 1 Mở đầu · Các vai trò tham gia trong một quy trình phát triển phần mềm - NVPhân tích thiết kế - Quản trị hệ thống : hoạt động chủ yếu trong giai đoạn lập giải pháp khả thi & khảo sát phân tích, các hồ sơ, tài liệu cuối cùng được lưu trữ chủ yếu là văn bản giấy, nếu có lưu trữ trên máy thì cũng lưu trữ trên máy của nhân viên phụ trách.. Sau khi kết thúc quá trình khảo sát, nhân viên đổi thì ghi nhận lại ngay trên document đó. K H TN ghi nhận các yêu cầu từ khách hàng, lưu lại dưới dạng document. Khi có sửa - NV Phân tích thiết kế : Khảo sát phân tích, thiết kế phần mềm lưu lại dưới dạng các document, không theo chuẩn nhất định và cũng được sửa chồng khi có sự thay đổi. Việc chuyển giao sang giai đoạn khác được thực hiện thông qua H việc ký nhận văn bản. Đ - NV Lập trình : chịu trách nhiệm lập trình, chỉnh sửa code, đưa ra các release. Mỗi nhóm lập trình sẽ được phân công từng module cụ thể. Quản lý các phiên – bản bằng Visual Source Safe. Khi source code thay đổi sẽ phát sinh 1 phiên C N TT bản mới, tuy nhiên nó không thể hiện được sự thay đổi này ảnh hưởng đến những module nào. Việc phân công coding cũng được thực hiện bằng tay. - NV Kiểm tra : Sau khi 1 module được coding xong hay đến 1 thời điểm quy định, chương trình được test bởi nhóm NVKiểm tra. Việc kiểm tra được thực hiện trên giấy. Khi phát hiện lỗi, nhân viên kiểm tra ghi nhận lại lỗi, và thực hiện lặp lại cho đến hết module. Sau khi test xong một module, bảng tường K H O A trình lỗi sẽ được gởi đến người chịu trách nhiệm đánh giá lỗi, thường là quản lý dự án. Nếu là lỗi có thể sửa sẽ đựơc xác nhận và chuyển giao cho bộ phận lập trình. Nếu lỗi có thể bỏ qua, người quản lý dự án sẽ xác nhận và kết thúc việc test. (xem chi tiết mô hình bên dưới) - NV quản lý đề án : là người có chức vụ cao nhất trong quy trình phát triển phần mềm, quản lý toàn bộ các thành viên, chịu trách nhiệm phân công, lên kế hoạch, theo dõi tiến độ thực hiện. - Trưởng dự án : chịu trách nhiệm xem xét duyệt lại các tài liệu, kiểm soát các tiến trình, đảm bảo các tiến trình được thực hiện đúng đắn và đúng tiến độ. 13 Chương 1 Mở đầu - NV Quản lý cấu hình : chịu trách nhiệm về việc tổ chức quản lý những tài liệu có liên quan đến đề án đang thực hiện như : quản lý các thành phần của từng phiên bản có trong đề án, tạo các phiên bản test và phiên bản giao cho khách hàng, đóng gói sản phẩm... - NV Quản lý kiểm thử : chịu trách nhiệm về việc lên kế hoạch kiểm thử, cho K H TN từng giai đoạn của đề án, đánh giá kết quả của việc kiểm thử. Và cùng với nhân viên quản lý đề án, trưởng dự án quyết định khi nào thì ngưng việc kiểm thử trong trường hợp chương trình vẫn còn lỗi nhưng những lỗi đó không nghiêm trọng, có thể chấp nhận để giao cho khách hàng vì thời giao đã gần kề... Wednesday, February 25, 2004 TRUNG TAÂM TIN HOÏC H Tröôøng ñaïi hoïc Khoa hoïc Töï nhieân Ñaïi hoïc Quoác gia TpHCM Đ PHOØNG PHAÙT TRIEÅN PHAÀN MEÀM 2/25/2004 K H O A C N TT – Sô ñoà caùc vai troø trong moät ñeà aùn Subtitle Quaûn lyù döï aùn Tröôûng döï aùn NV Quaûn lyù caáu hình NV Quaûn trò heä thoáng NV Quaûn lyù kieåm thöû NV Phaân tích thieát keá NV kieåm thöû NV laäp trình NV huaán luyeän Hình 1-2 Sơ đồ tổ chức các vai trò của nhân sự trong 1 đề án phần mềm Trong các quy trình phát triển trên, đề tài chú trọng đến hai tiến trình : Quản lý yêu cầu và quản lý kiểm thử 14 Chương 1 Mở đầu · Quản lý yêu cầu - Khách hàng đặt hàng, T3H đồng ý nhận đơn đặt hàng, chuẩn bị tiến hành khảo sát - Quản lý dự án lập kế hoạch ban đầu, đặc tả các nhiệm vụ, phân công. Bảng kế hoạch được in giấy, phân phát cho nhân viên liên quan. Khảo sát viên tiến hành khảo sát, sau mỗi lần khảo sát, một bản mô tả K H TN - hiện trạng, yêu cầu khách hàng được thiết lập. Đến thời hạn, nhân viên này đưa bản báo cáo cuối cùng cho Quản lý dự án. Khảo sát viên hoàn toàn tự quản lý các tài liệu này và chỉ giao cho Quản lý dự án bản cuối cùng. - Khi tiến hành phân tích thiết kế, phân tích viên hay nhân viên thiết kế H sẽ làm việc trên tài liệu mà Quản lý dự án đưa. Nếu có thay đổi, nhân lại cho Quản lý dự án. Cuối giai đoạn này, một bản đặc tả yêu cầu và phân tích thiết kế được – - Đ viên đó sẽ thay đổi trên tài liệu này, ghi nhận và đến thời hạn sẽ giao - C N TT đưa ra. Thông thường, khảo sát viên, nhân viên phân tích thiết kế là một và là quản lý dự án. K H O A Quá trình này được mô hình hóa thông qua mô hình sau : 15 Chương 1 Mở đầu QUẢN LÝ YÊU CẨU (Hệ thống hiện tại) Trưởng dự án Quản lý dự án Tiếp xúc với KH Đưa ra các yêu cầu Xem xét việc tiến hành dự án H Bảng yêu cầu (tự quản lý thông tin) Y C N TT Đặc tả nhiệm vụ & phân công Trưởng dự án Khảo sát viên N K H TN Tiến hảnh khảo sát Đ Không thực hiện dự án Nhận đơn đặt hàng từ KH – N Khảo sát viên Khách hàng chấp thuận bản yêu cầu Y Tài liệu đặc tả yêu cầu cuối cùng K H O A Kết thúc khảo sát Toản bộ các tiến trình được thực hiện bằng tay. Các tài liệu được phát sinh trong giai đoạn này do người phụ trách tự quản lý. Chỉ có bản yêu cầu cuối cùng được gửii cho các thành viên phát triển dự án Hình 1-3 Mô hình quản lý yêu cầu tại T3H 16 Chương 1 Mở đầu Quản lý kiểm thử : · - Sau mỗi lần coding xong ra một internal release, công việc kiểm thử được tiến hành. - Thông qua kinh nghiệm và kiến thức về nghiệp vụ, nhân viên kiểm tra liệu kiểm thử. - K H TN lập ra các bộ kiểm thử (test case) và ghi nhận lại kết quả này bằng tài Đến thời hạn, nhân viên này đưa lại cho trưởng bộ phận kiểm thử (Test manager) xem xét đánh giá lỗi trên tài liệu kiểm thử và đưa lại bản tài liệu đã được đánh giá cho người lập trình sửa lỗi. K H O A C N TT – Đ H Quá trình này được mô hình hóa bên dưới : 17 K H O A C N TT – Đ H K H TN Chương 1 Mở đầu Hình 1-4 Mô hình kiểm thử tại T3H 18 Chương 4 Đánh giá hiện trạng quản lý yêu cầu và quản lý kiểm thử tai T3H 1.4 Đánh giá hiện trạng 1.4.1 Quản lý yêu cầu : · Hiện tại T3H làm phần mềm có quy trình, các nhân viên đều nắm được nhưng việc thủ tục hóa từng quy trình không có, kết quả là không có một K H TN mẫu biểu chuẩn ghi nhận lại nên thông tin có thể không nhất quán. · Khi các yêu cầu thay đổi trong quá trình thực hiện đề án, nhân viên không nhất thiết phải ghi lại thông tin thay đổi nên có thể họ sẽ quên một số thông tin, điều này có thể gây ra sự bất đồng bộ trong việc thực hiện phần mềm ở những bộ phận khác nhau. · Đối với một công ty nhỏ như T3H chỉ gồm khoảng trên dưới 30 nhân viên thì H việc trao đổi thông tin bằng miệng như hiện nay rất dễ dàng. Khi có một Đ vướng mắc nào đó họ có thể hỏi ngay tại đó để làm rõ vấn đề. Nhưng đặt nay sẽ rất khó khăn. – trường hợp PPTPM mở rộng, phát triền hơn thì với việc quản lý như hiện C N TT · Khi yêu cầu thay đổi, yêu cầu mới được ghi chồng lên các yêu cầu cũ mà không có sự ghi nhận rõ ràng ( người sửa, ngày sửa, nguyên nhân,…) do đó không lưu vết được các yêu cầu, gây ra khó khăn khi cần xem xét lại tài liệu hoặc truy cứu trách nhiệm khi yêu cầu sai. · Khi một yêu cầu được thay đổi người trưởng dự án không biết được yêu cầu K H O A này ảnh hưởng đến những module nào, và khó biết yêu cầu mới có bị trùng lặp với những yêu cầu cũ hay không. 1.4.2 Quản lý kiểm thử : · Như phần hiện trạng đã đề cập ở trên, các test case được chính người kiểm thử đề ra, và cũng người đó thực hiện việc kiểm tra, nên những người khác hoàn toàn không biết về những test case này nếu nó không có xảy ra lỗi. Như vậy các nhân viên khác khó có thể học hỏi kinh nghiệm test cũng như chưa kể người thực hiện kiểm thử có thể quên hoặc thiếu một số trường hợp test. 19 Chương 4 Đánh giá hiện trạng quản lý yêu cầu và quản lý kiểm thử tai T3H · Do thông tin về những lỗi không lưu lại, những lỗi xuất hiện trong đề tài nào thì người phát triển đề tài đó biết. Đặt trường hợp nếu lỗi đó xuất hiện trong một đề tài khác, do người khác phụ trách kiểm thử, nếu như người đó biết đã có người gặp phải lỗi đó thì người đó có thể biết ngay cách chỉnh sửa. Nhưng đặt trường hợp người đó không biết có người gặp phải lỗi này, thì người đó K H TN có thể phải tự tìm tòi, chưa kể nếu lỗi đó xuất hiện nhiều lần lại phải tốn nhiều công sức đầu tư. · Do không quản lý phiên bản test, nên trong một sản phẩm, có những lỗi đã được phát hiện rồi, sửa rồi, nhưng phiên bản cuối cùng lại là phiên bản cũ, có lỗi. H · Từ việc chuyển giao các test case đến người lập trình viên để cập nhật kết quả đến việc xem xét lại các testcase, cho đến việc kiểm và sữa chữa lỗi trải Đ qua nhiều giai đoạn, do đó các hồ sơ dễ bị thất lạc và không đúng phiên bản C N TT 1.5 Mục tiêu đề tài – hiện hành. Tìm hiểu về việc quản lý yêu cầu và quản lý kiểm thử trong quá trình phát triển phần mềm. Ứng dụng xây dựng phần mềm hỗ trợ việc quản lý yêu cầu và kiểm thử tại T3H · Tìm hiểu công việc quản lý yêu cầu và quản lý kiểm thử nhằm bảo đảm K H O A chất lượng phần mềm. Trong đó, chú trọng các thông tin cần phải quản lý trong hai tiến trình này. · Ứng dụng những kiến thức đó, xây dựng chương trình nhằm cải tiến và hỗ trợ công việc quản lý yêu cầu và quản lý kiểm thử tại Phòng phát triển phần mềm, Trung tâm Tin học trường Đại học Khoa học Tự nhiên. 20