1. Trang chủ
  2. » Giáo Dục - Đào Tạo

công nghệ phần mềm chuẩn CMMI

40 387 3

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 40
Dung lượng 776,85 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Nó có thể được sử dụng để định hướng quản lý, định hướng phát triển cho một dự án, một bộ phận của tổ chức hoặc toàn bộ tổ chức đó..  CMM là phương thức được sử dụng để đánh giá, xác đị

Trang 1

CÔNG NGHỆ PHẦN MỀM

CHUẨN CMMI

Trang 2

I Giới thiệu về CMMi

1. Giới thiệu:

. CMMi (Capability Maturity Model Integration) là một mô hình quản lý chất lượng cho các tổ

chức Nó có thể được sử dụng để định hướng quản lý, định hướng phát triển cho một dự án, một bộ phận của tổ chức hoặc toàn bộ tổ chức đó. 

. CMMi được tạo ra và duy trì bởi một nhóm gồm có các thành viên của công nghiệp, chính

phủ và Software Engineering Institute (SEI) . 

Trang 3

1 Giới thiệu

CMMi đưa vào trong mỗi một doanh nghiệp theo từng đối tượng kinh doanh Các doanh nghiệp không thể tự cấp chứng nhận CMMi Do đó, doanh nghiệp cần phải được xác định từ cấp độ 1 đến 5 Kết quả thẩm tra này sẽ được đưa ra bởi các tổ chức thẩm tra.

Trang 4

I Giới thiệu về CMMi

2 Nguồn gốc:

Được phát triển dựa trên CMM- một mô hình phát triển phần mềm được đưa ra bởi Viện kỹ

nghệ phần mềm SEI tại trường đại học Carnegie Mellon, Mỹ.

CMM (Capability Maturity Model) mô hình phát triền phần mềm được định nghĩa lần đầu

vào năm 1989 trong cuốn sách “Managing the Software Process” được viết bởi Watts Humphrey.

CMM là phương thức được sử dụng để đánh giá, xác định độ phát triển của quy trình phát

triển phần mềm trong mỗi tổ chức

Trang 5

2 Nguồn gốc:

CMM được phát triển với mục đích ban đầu là để phục vụ quá trình phát triển phần mềm nhưng sau đó được sử dụng rộng rãi cho các mô hình kinh doanh cơ bản, công nghiệp và cả trong cơ quan nhà nước.

Software CMaM v2.0

SE-CMM

SECAM

SA-CMM v1.01

SA-CMM v1.01

IPD-CMM v0.98

IPD-CMM v0.98

EIA/IS 731 SECM

EIA/IS 731 SECM

CMMI v1.0x

CMMI v1.0x

CMMI v1.1x CMMI v1.1x

Trang 6

3 Lợi ích từ CMMi

Với mô hình CMMi, các doanh nghiệp có thể:

 Có thêm những quyết định rõ ràng, dứt khoát trong việc quản lý và hoạt động cho các đối tượng kinh doanh của họ

 Giải thích về phạm vi và tầm nhìn trong vòng đời phát triển của phần mềm, cũng như các hoạt động nhằm đảm bảo sản phẩm hoặc dịch vụ đáp ứng được nhu cầu của khách hàng

 Thực hiện thêm đầy đủ và thuần thục với cách thức làm việc

Trang 7

3 Lợi ích từ CMMi

 Kết hợp những gì đã có được và cộng thêm vào những thực hành tốt nhất Ví dụ như cách đo lường, quản lý mạo hiểm, quản lý cung cấp

 Thêm vào chức năng nhận phê bình từ sản phẩm và dịch vụ của công ty

 Thêm vào hoàn toàn những điều tuân theo chuẩn ISO

Trang 8

Cải ti

ến quy tr ình , n âng ca

o n ăng su

ất, chấ

t lư ợng sả

n p hẩm , n âng ca

o lợ

i

nhu ận.

•Cải ti

ến quy tr ình , n âng ca

o n ăng su

ất, chấ

t lư ợng sả

n p hẩm , n âng ca

o lợ

i

nhu ận.

2

Cải th iện kh

ả n ăng qu

ản

và giả

i q uyế

t v

ấn đề, rủ

o tí

nh

ổn địn

h c

ho các ho

ạt đ ộng và sự ph

át t riể

n c

ủa

tổ chứ

c chứ tổ ủa n c riể át t ph sự và ộng ạt đ ho các ho h c địn ổn nh o tí bả Đảm •c

4 Mục đích sử dụng

Về cơ bản có 3 mục đích chính:

Trang 9

(System Engineering)

SW (Software Engineering)

IPPD (Integrated Product and Process

Development)

SS (Supplier sourcing)

II PHÂN LOẠI MÔ HÌNH CMMi

Trang 11

Là mô hình bao gồm các phương pháp tiếp cận, liên hệ giữa các bộ phận trong suốt vòng đời của sản phẩm để thỏa mãn yêu cầu, mong muốn của khách hàng Có thể được tích hợp với các quy trình khác của của tổ chức

Integrated Product and Process DevelopmentIPPD

Trang 12

Là mô hình sử dụng nhà cung cấp để giải quyết những vấn đề phát sinh trong quá trình triển khai dự án khi việc sử dụng nhà cung cấp là phương pháp tối ưu nhất để giải quyết vấn đề.

Tuy nhiên cần phải chú trọng đến khâu chọn nhà cung cấp để tránh phát sinh các rủi ro nghiêm trọng hơn

Supplier Sourcing

SS

Trang 13

Là mô hình bao trùm toàn bộ quá trình phát triển phần mềm sử dụng các phương pháp đánh giá, định lượng cho quá trình phát triển và vận hành phần mềm.

Software Engineering

SW

Trang 14

III CẤU TRÚC CỦA CMMi

Levels - Mức độ

Process areas – Miền quy trình

Goals – Mục tiêu

Common Feature – Các đặc tính thông dụng

Practices – Các bài luyện tập

Trang 15

 Sơ đồ cấu trúc của CMMi

Maturity Levels

Process Area1 Process

Area 2 Process Area 3

Specific

Goals

Generic Goals

Verifying Implementation

Generic Practices

Common Features

Trang 16

Process Area 1 Process Area 2 Process Area 3

Specific

Goals

Generic Goals

Specific

Practices

Specific Practices

Capability Levels

Trang 17

1 Levels:

Gồm có:

Maturity Levels ( Mức độ phát triển):

• Là một tính năng được áp dụng từ mô hình Software CMM, dùng để định nghĩa ra các cấp độ trưởng thành của quy trình từ đó đưa ra các process area tương ứng

Capability Levels (Mức độ năng lực):

• Là một tính năng được áp dụng từ mô hình SECM (software engineering capability model) và IPD-CMM (intergrated product development) được dùng để định nghĩa ra một

số process area đặc biệt và những vấn đề liên quan

Trang 19

3 Goals- Generic and Specific

Là những yếu tố mọi process area đều có, được dùng để hệ thống hóa mỗi quy trình.

Ví dụ để hệ thống hóa một quy trình phát triển phần mềm, ta định nghĩa ra các quy trình trình như quản lý tiến độ, quản lý kế hoạch…

Gồm có:

 Generic

 Specific

Trang 20

4 Common Feature:

Các đặc tính thông dụng đơn giản là nhóm các bài luyện tập tổng quatslaij với nhau trong một

PA theo các chức năng mà các bài luyện tập này đảm nhiệm.

Là thuộc tính dùng để chỉ ra lúc nào, ở đâu một process area có hiệu quả, được lặp lại hoặc kết thúc.

Trang 21

5 Practices- Generic and Specific:

Ứng với mỗi goals là một tập các practices để đạt được goals đó

Ví dụ: sau khi định nghĩa ra các goals là quản lý tiến độ, quản lý kế hoạch… ta phải định nghĩa ra các hành động để đảm bảo cho mục tiêu quản lý tiến độ, quản lý kế hoạch…

Trang 22

IV Martury Levels và Process Area

Trong quá trình áp dụng cũng như phát triển quy trình theo mô hình CMMi mỗi tổ chức thường trải qua 5 cấp độ (level) Ở mỗi cấp độ việc áp dụng các quy trình quản lý được thực hiện một cách nghiêm túc và có hệ thống hơn những cấp độ trước đó Sau đây là chi tiết của từng cấp độ trong CMMi.

Trang 24

1 Mức 1: Đầu vào - Initial

Là cấp độ khởi đầu, mọi cá nhân, tổ chức chỉ cần làm về phần mềm là có thể đạt được cấp này Đặc điểm:

 Không có quy trình

 Phát triển hỗn độn

 Quản lý lỏng lẻo

 Chất lượng sản phẩm không biết trước

Nhận xét: Đây là một giai đoạn không tốt

Trang 25

Là cấp độ tiếp theo sau level 1, tại level này quy trình đánh giá và phân tích được áp dụng trong quá trình phát triển phần mềm Đặc điểm:

 Gắn vào các chính sách quản lý

 Thực hiện theo kế hoạch và mô tả tiến trình

 Phù hợp quỹ và tài nguyên

 Duy trì, đảm bảo về trách nhiệm và bản quyền

 Đào tạo con người

 Quản lý tiến trình

 Kiểm tra và điều khiển các quá trình

 Xem lại các tiến trình, ghi lại điều không phù hợp

2 Mức 2: Quản lý – Managed

Trang 26

 Kiểm tra các hoạt động và thực hiện các hành động chuẩn xác.

 Xác định và hợp tác với người liên quan

Bắt đầu việc luyện tập cơ bản và tiếp tục tăng độ phức tạp.

2 Mức 2: Quản lý (tiếp)

Trang 27

Là cấp độ mà tại đó ngoài các quy trình được áp dụng ở level 2 còn có thêm các quy trình khác như: phát triển yêu cầu, giải pháp kỹ thuật, tích hợp hệ thống, kiểm định, phê duyệt, quản lý rủi ro và phân tích quyết định Đặc điểm:

 Tiêu chuẩn, quy trình, thủ tục trong dự án được biến đỏi để phù hợp với quy trình tiêu chuẩn của mỗi dự án đặc thù hoặc cho mỗi phần của tổ chức

 Các quy trình được định nghĩa chi tiết và khắt khe hơn so với level 2

3 Mức 3: Định nghĩa – Defined

Trang 28

3 Mức 3 (tiếp)

 Quy trình chỉ được quản lý theo phỏng đoán

 Quy trình được quản lý một cách chủ động hơn

Tiếp tục định nghĩa một tổ chức lớn mạnh.

Trang 29

4 Mức 4: Quản lý chất lượng

Thỏa mãn mức 2 và 3.

Thiết lập mục đích định lượng đối với chất lượng sản phẩm, chất lượng phục vụ và thực hiện các quy trình.

Thiết lập thực hiện tiến trình dự đoán trước và thống kê ổn định.

Thiết lập các thống kê để biết khi nào thì một tiến trình đạt được các mục đích tại mức hiện tại.

Trang 30

5 Mức 5: Tối ưu hóa

Thỏa mãn các mức 2, 3 và 4.

Thiết lập mục đích cải tiến chất lượng quá trình.

Nhận dạng và ngăn chặn các lỗi chung.

Nhận dạng và bắt đầu quá trình phát triển và sáng tạo cá cải tiến kỹ thuật.

Trang 32

V GOALS & PRACTICES

Goals (G – mục tiêu) có 2 loại:

 Specify Goals (xác định mục tiêu) – SG: Là các hành động cho PA xác định trong quá trình nghiên cứu phát triển

 Generic Goals (mục tiêu chung) – GG: Là mục tiêu chung cho nhiều PA trong toàn bộ mô hình Chúng giúp xác định cho việc PA là chuẩn của Oganization

Quan hệ giữa Goals và Practices:

 Các PA có một vài G phải được đáp ứng bởi các G này ở mức cao nên mỗi G phải kết hợp với các Practices (P) Các P xác định các nhiệm vụ cụ thể sẽ được thực thi trong PA nhằm hoàn thành G

Trang 33

 Các G và P liên quan tới nhiều PA.

 Ở mức 2:

• Thiết lập các chính sách

• Lên kế hoạch cho quy trình

• Huấn luyện nhân viên

Trang 34

 Mỗi một mức chỉ có một GG và mỗi GP chỉ ánh xạ duy nhất 1 GG.

chế hóa quy trình Các GG và GP cung cấp sự thể chế hóa và nâng cao tính tinh tế cho các PA còn G và P cung cấp sự thực hiện cho các PA.

Trang 35

 Đây là mức đầu tiên làm nền tảng cho các mức cao hơn do đố người ta không đưa ra

Requirement Development (phát triển yêu cầu)– RD

Trang 36

 TRACING – TRUY XUẤT

 Trong CMMi dành cho phần mềm thì Traceability(Truy xuất nguồn gốc) được thực hiện sớm ngay ở mức 2

 Không thể quản lý các thay đổi của yêu cầu nếu không có cách Tracing bằng nhiều phương pháp Các tổ chức lập lên Requirement Traceability Matrix(yêu cầu truy xuất nguồn gốc ma trận) – RTM để quản lý

 Trong CMMi thì RTM chỉ là một P

 Mục đích là tìm ra lỗi và nhanh chóng sửa lỗi

Trang 37

 Lập kế hoạch cho dự án

 Mục đích là thiết lập và duy trì kế hoạch

• Thiết lập và duy trì kế hoạch không phải là khởi tạo mới và điều hành mà phải định ra kế hoạch, văn bản hóa kế hoạch, dùng kế hoạch để giám sát những gì xảy ra trong khi thực hiện kế hoạch và đánh giá kết quả

 Lập kế hoạch cho dự án không chỉ dừng lại ở phần mềm mà còn bao gồm kế hoạch thiết kế và chuyển giao sản phẩm

Trang 38

 Xác định và xây dựng văn bản về phạm vi dự án, ước lượng kích cỡ và độ phức tạp của dự án, ước lượng công việc, năng lực, giá thành, vòng đời của dự án, xác định ngân sách và lập lịch, xác định và làm tài liệu rủi ro về dự án, lập kế hoạch mở rộng để giao nhiệm vụ cho các cá nhân đảm bảo sự thành công của dự án, lập ké hoạch quản lý thông tin, nhân viên, tài nguyên phần cứng, lập ké hoạch cho việc đào tào thành viên tham gia dự án.

Trang 39

Các bài luyện tập là các hành động mà phải được thực hiện nhằm đáp ứng các mục tiêu cho mỗi PA Mỗi một bài luyện tập chỉ liên quan đến một mục tiêu nào đó Có 2 kiểu bài luyện tập:

 Luyện tập cụ thể(Spaccify Practices): là bài luyện tập cho một mục tiêu cụ thể

 Luyện tập tổng quan(Generic Practices): được kết hợp với các mục tiêu tổng quan nhằm đưa thành chuẩn hay thể chế hóa bài luyện tập

Practices – các bài luyện tập

Trang 40

 Common Feature

 Các Practices mà Common Feature quản lý:

• Cam kết thực hiện (Commitment to Perform – CO)

• Khả năng thực hiện (Ability to Perform – AB)

• Hướng thực thi (Directing Implementation – DI)

• Kiểm tra việc thực thi (Verifying Implementation – VE)

Ngày đăng: 19/11/2017, 20:03

TỪ KHÓA LIÊN QUAN

w