Đồ Án Công nghệ quản lý chất lượng phần mềm

Thảo luận trong 'Chưa Phân Loại' bắt đầu bởi Thúy Viết Bài, 5/12/13.

  1. Thúy Viết Bài

    Thành viên vàng

    Bài viết:
    198,891
    Được thích:
    173
    Điểm thành tích:
    0
    Xu:
    0Xu
    LỜI CẢM ƠN
    Trong quá trình học tập tại trường, em đã được quý thầy cô truyền đạt tất cả các kiến thức nền tảng, chuyên môn thiết thực và quý giá. Đó là những kiến thức cần thiết làm cơ sở nghiên cứu cho việc phát triển trong ngành công nghệ thông tin, cũng như trong công việc sau khi ra trường. Trong đó đồ án tốt nghiệp là cơ hội để em có thể áp dụng, tổng kết lại những kiến thức mà em đã học. Đồng thời, rút ra được những kinh nghiệm thực tế và quý giá trong suốt quá trình thực hiện đề tài.
    Nhờ sự chỉ bảo tận tình của thầy, các thầy cô trong khoa và bạn bè cũng như sự nỗ lực tìm tòi của bản thân, đã giúp em hoàn thành đề tài một cách thuận lợi. Tuy nhiên do thông tin cập nhật và kinh nghiệm thực tế còn có phần hạn chế nên kết quả của Đề tài cũng chỉ dừng lại ở chỗ học tập và trao đổi kinh nghiệm do đó tính khả thi của Đề tài còn chưa cao. Bởi vậy em mong là sẽ nhận được sự góp ý của các thầy cô cùng toàn thể các bạn để đề tài được hoàn thiện hơn.
    Một lần nữa em xin chân thành cảm ơn các thầy cô giáo trong khoa Công Nghệ Thông Tin đã dạy dỗ em trong những năm qua.
    Em xin chân thành cảm ơn thầy đã tận tình giúp đỡ, chỉ bảo và tạo điều kiện để em có thể hoàn thành Đồ án tốt nghiệp này.
    TPHCM, ngày tháng năm 2011
    Sinh viên




    Mục lục

    nLỜI CẢM ƠN 1
    Chương I: Mở đầu 7
    Chương II: Quản lý chất lượng phần mềm 9

    2.1 Quản lý chất lượng phần mềm 9
    2.2 Quản lý cấu hình phần mềm 11
    2.2.1 Quy trình xây dựng phần mềm 11
    2.2.2 Định nghĩa quản lý cấu hình phần mềm 12
    2.2.3 Tác dụng của quản lý cấu hình phần mềm 13
    2.2.4 Khi nào quản lý cấu hình phần mềm 14
    Chương III: Quản lý cấu hình phần mềm 14
    3.1 Hoạt động của quan lý cấu hình phần mềm 14
    3.1.1 Kế hoạch quản lý cấu hình (CMP) 15
    3.1.2 Định danh/ đánh số CI 16
    3.1.3 Kiểm soát phiên bản (Version Control) 17
    3.1.4 Quản lý baseline (Baseline Management) 18
    3.1.5 Kiểm soát thay đổi (Change Control) 19
    3.1.6 Kiểm kê tình trạng cấu hình (Configuration Status Accounting) 20
    3.1.7 Audit 20
    3.1.8 Quản lý Release (Release Management) 21
    3.1.9 Lưu trữ và chép dự phòng (Backup & Archive) 22
    3.1.10 Vai trò của các thành viên trong dự án 23
    3.2 Quy trình quản lý cấu hình phần mềm 24
    3.2.1 Bối cảnh tổ chức 24
    3.2.2 Hạn chế và hướng dẫn cho tiến trình SCM 25
    3.2.3 Kế hoạch SCM (Planing SCM) 26
    3.2.4 Bản kế hoạch SCM (SCM Plan) 31
    3.2.5 Cấu hình giám sát của phần mềm quản lý (Surveillance of SCM) 31
    3.3 Nhận dạng cấu hình phần mềm (Software configuration identification) 33
    3.3.1 Nhận dạng các mục để được kiểm soát (Identifying items to be controlled) 33
    3.3.2 Thư viện phần mềm (Software Library) 36
    3.4 Kiểm soát cấu hình phần mềm (Software configuration control) 37
    3.4.1 Yêu cầu, đánh giá và phê duyệt các thay đổi phần mềm 38
    3.4.2 Thực thi các thay đổi phần mềm (Implementing software change) 40
    3.4.3 Độ lệch và (waivers) 41
    3.5 Kiểm kê trạng thái cấu hình phần mềm (Software configuration status accounting) 41
    3.5.1 Thông tin trạng thái cấu hình phần mềm (Software configuration status information) 41
    3.5.2 Báo cáo trạng thái cấu hình phần mềm (Software configuration status reporting) 42
    3.6 Ghi nhận cấu hình phần mềm (Software configuration auditing) 42
    3.6.1 Ghi nhận cấu hình chức năng phần mềm (Software functional configuration audit) 43
    3.6.2 Ghi nhận cấu hình vật lý phần mềm (Software physical configuration audit) 43
    3.6.3 Trong quá trình ghi nhận của một phần mềm baseline 43
    3.7 Phát hành phần mềm quản lý và giao hàng (Software release management divery) 44
    3.7.1 Xây dựng phần mềm 44
    3.7.2 Phát hành phần mềm quản lý 45
    Chương IV: Công cụ quản lý phần mềm 47
    4.1 Giới thiệu về Borland StarTeam 47
    4.1.1 Khả năng quản lý thay đổi và cấu hình phần mềm 47
    4.1.2 Quản lý sự thay đổi 49
    4.1.3 Borland StarTeam Enterprise 49
    4.1.4 Borland StarTeam Enterprise Advange 50
    4.2 Sử dụng Borland StarTeam 50
    4.2.1 Server configuration 50
    4.2.2 Project 52
    4.2.3 Group and User 52
    4.2.4 Task 54
    4.2.5 View 54
    4.2.6 File 55
    4.2.7 Change request 59
    4.2.8 Audit 66
    4.2.9 Branching 68
    4.2.10 Merging 69
    Chương V: Kết luận 70
    5.1 Quản lý cấu hình phần mềm 70
    5.2 Borland StarTeam 72
    Phụ lục 75
    Phụ lục I : HƯỚNG DẪN CÀI ĐẶT BORLAND STARTEAM 75

    1. Cài đặt Borland StarTeam Server 75
    1.1 Hệ thống yêu cầu cho StarTeam Server 75
    1.2 Cài đặt StarTeam Server 79
    2. Cài đặt Borland StarTeam Client 85
    2.1 Hệ thống yêu cầu cho StarTeam Cross-Platform Client 85
    2.2 Cài đặt StarTeam Cross-Platform Client 86
    Phụ lục II : CHUẨN IEEE CHO KẾ HOẠCH QUẢN LÝ CẤU HÌNH PHẦN MỀM 89
    1. Tổng quan 89
    1.1 Phạm vi 89
    2. Tham chiếu (references) 90
    3. Các định nghĩa và từ viêt tắt (acronyms) 90
    3.1 Định nghĩa 90
    3.2 Acronyms (từ viết tắt) 91
    4 Kế hoạch quản lý cấu hình phần mềm (The Software Configuration Management Plan) 91
    4.1 Lời giới thiệu 93
    4.2 SCM quản lý 94
    4.3 Các hoạt động SCM (SCM activities) 95
    4.4 SCM kế hoạch (SCM schedules) 104
    4.5 SCM tài nguyên (SCM resources) 105
    4.6 SCM kế hoạch duy trì (SCM plan maintenance) 105
    5 Sự biến đổi của plan (Tailoring of the plan) 106
    5.1 Upward tailoring 106
    5.2 Downward tailoring 106
    5.3 Format 107
    6 Conformance to the standard 107
    6.1 Minimum imformation 107
    6.2 Presentation format 108
    6.3 Consistency criteria 108
    6.4 Conformance declaration 108
    Tài liệu tham khảo 109


    Mục lục hình vẽ

    Hình 1: Bản đồ của các công cụ và thủ tục để SCM hoạt động.
    Hình 2: Thu nhận của các mục
    Hình 3: Quy trình cung cấp các thủ tục chính thức để kiểm soát thay đổi.
    Hình 4: Check-in file
    Hình 5: Check-out file
    Hình 6: Change request tracking system model
    Hình 7: Change request lỗi
    Hình 8: New Change request
    Hình 9: Audit file
    Hình 10: Branch và child branch
    Hình 1.1: Các xử lý cấu hình nhận dạng.

    Một số kí hiệu viết tắt
    CM - Configuration Management
    SCM – Software Configuration Management
    SEP – Software Engineering Process
    CI – Configuration Item
    CMP – Configuration Management Plan
    CCB – Configuration Control Board
    CSAR – Configuration Status Accounting Report
    PCA – Physical Configuration Audit
    FCA – Functional Configuration Audit
    SCMP – Software Configuration Management Plan
    SQA – Software Quality Assurance
    SCI – Software Configuration Item
    SCR – Software Change Request
    PM – Project Manager
    SCSA – Software Configuration Status Accouting








    Chương I: Mở đầu
    1. Mở đầu

    Những ai quan tâm tới quy trình sản xuất phần mềm, chắc hẳn không ít lần gặp khái niệm về quản lý cấu hình (Configuration Management). Ta dễ dàng tìm thấy các yêu cầu về quản lý cấu hình một cách trực tiếp hay gián tiếp trong các bộ tiêu chuẩn hoặc mô hình quy trình sản xuất phần mềm thông dụng hiện nay như CMM/CMMI, ISO 15504 hoặc ISO 9001:2000. Trong CMM và CMMI, quản lý cấu hình là yêu cầu bắt buộc ngay từ mức 2, là mức cơ bản của mô hình này. Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về quản lý cấu hình, tuy rằng chúng vẫn có những điểm chung cơ bản.
    Chắc hẳn trong mỗi chúng ta khi làm các dự án về phần mềm đã ít nhất một lần gặp những tình huống như:
    ã Một lỗi nào đó của phần mềm đang xây dựng đã tốn nhiều công sức sửa chữa, bỗng “thình lình” xuất hiện trở lại.
    ã Một chức năng (function) nào đó của phần mềm đã được phát triển và kiểm tra cẩn thận bỗng thất lạc hoặc biến mất một cách khó hiểu.
    ã Một chương trình (program) đã được kiểm tra hết sức cẩn thận, bỗng nhiên không “chạy” được nữa.
    ã Một chương trình gồm nhiều đơn thể (module), mỗi đơn thể gồm nhiều chức năng, các chức năng được chia ra cho nhiều lập trình viên, mỗi chức năng bao gồm nhiều tập tin mã nguồn (source code) với nhiều phên bản (version) khác nhau. Khi tích hợp hệ thống và biên dịch, trong hang chục tập tin source code với hàng trăm version, tập tin nào, version nào là đúng và cần thiết phải lấy để tiến hành tích hợp?
    Các vấn đề trên chắc hẳn không xảy ra nếu như trong dự án, việc quản lý cấu hình được thực hiện nghiêm túc và kiểm soát chặt chẽ với mục đích để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án đó.
     

    Các file đính kèm:

Đang tải...