Mô tả mức khởi đầu

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Quản lý quy trình phần mềm theo mô hình CMM - thực tiễn và ứng dụng ở Việt Nam Luận văn ThS Công nghệ thông tin 01.01.10 (Trang 43)

Qui trình sản xuất PM còn lô ̣n xô ̣n , không khoa ho ̣c, khả năng rủi ro cao. Mô ̣t số công đoa ̣n bi ̣ phu ̣ thuô ̣c vào mô ̣t, hai cá nhân nào đó.

- Thiếu / hiểu sai yêu cầu

- Ƣớc lƣợng / Lập kế hoạch kém - Thiếu qui trình đƣợc xác định - Các dấu hiệu cảnh báo bị bỏ qua - Quá hạn là chuyện thƣờng.

- Không có huấn luyện về qui trình - Hiếm khi đáp ứng ràng buộc ngân sách - Hiếm khi đáp ứng ràng buộc lịch biểu

- Thiếu phản hồi có thể gây ra nỗ lực bị lãng phí - Khách hàng và nhân viên ít đƣợc thoả mãn.

Hình 3. 3 : Mức lặp lại được

* Chuyển từ mức (1) sang (2)

- Mức (1) = lung tung, chỉ cốt việc đƣợc làm!

- Mức (2) = các qui trình quản lí dự án đƣợc làm tƣ liệu và thực hiện. Hội tụ vào dự án.

2.1. Hiểu mức tăng trưởng lặp lại 2

Quy trình đã có sƣ̣ kiểm soát bằng viê ̣c lên kế hoa ̣ch , rút kinh nghiệm từ thành công của nhƣ̃ng dƣ̣ án trƣớc. Mƣ́c này đã thiết lâ ̣p mô ̣t số qui trình quản lý dƣ̣ án cơ bản nhƣ theo dõi chi phí, thời ha ̣n và chƣ́c năng.

- Các qui trình quản lí dự án đƣợc làm tƣ liệu và tuân theo.

- Thực hành thành công đƣợc phát triển dựa trên các dự án trƣớc đƣợc lặp lại. (Phân tích nhân quả)

- Chính sách của tổ chức động viên việc thiết lập các qui trình quản lí dự án xác định tốt.

Hình 3. 4 : Mô tả mức lặp lại được

* Qui trình đƣợc làm tƣ liệu chứa những gì? - Mục đích và mục tiêu

- Ngƣời đƣợc dự định đọc - Các giả định

- Thủ tục về cách cải tiến qui trình - Cái vào/ra qui trình chi tiết (Giao diện) - Các bƣớc qui trình chi tiết (có lí do) 1 .. N - Xác định cách đo qui trình để đạt hiệu quả đo - Chuẩn và nguyên tắc chỉ đạo qui trình

- Ngƣời liên hệ, danh sách viết tắt, từ điển dữ liệu

2.2. Các KPA cho mức lặp lại 2

1. Quản lí yêu cầu (RM)

2. Lập kế hoạch dự án phần mềm (PP)

3. Theo dõi và giám sát dự án phần mềm (PT) 4. Quản lí nhà thầu phần mềm (SM)

5. Đảm bảo chất lƣợng phần mềm (QA) 6. Quản lí cấu hình phần mềm (CM)

2.2.1. Quản Lý Yêu Cầu

Mục đích của Quản Lý Yêu Cầu là thiết lập một hiểu biết chung giữa khách hàng và dự án phần mềm nhằm thực hiện yêu cầu khách hàng.

Quản Lý Yêu Cầu liên quan đến thiết lập và duy trì một thoả thuận với khách hàng về các yêu cầu cho dự án phần mềm. Sự thoả thuận này đƣợc nói đến nhƣ là "các yêu cầu hệ thống chỉ định cho phần mềm". "Khách hàng" có thể đƣợc hiểu nhƣ là nhóm kỹ sƣ hệ thống, nhóm tiếp thị, một tổ chức nội bộ khác, hoặc một khách hàng bên ngoài. Sự thoả thuận bao gồm cả các yêu cầu kỹ thuật và phi kỹ thuật (ví dụ: các ngày chuyển giao). Sự thoả thuận hình thành cơ sở để ƣớc tính, lập kế hoạch, thực hiện, và theo dõi các hoạt động của dự án phần mềm trong suốt vòng đời phần mềm.

Sự chỉ định yêu cầu hệ thống cho phần mềm, phần cứng và các thành phần hệ thống khác (ví dụ: ngƣời) có thể đƣợc thực hiện bởi một nhóm bên ngoài nhóm kỹ nghệ phần mềm (software engineering group) (ví dụ nhóm kỹ sƣ hệ thống), và nhóm kỹ nghệ phần mềm có thể không kiểm soát trực tiếp sự chỉ định này. Trong phạm vi các ràng buộc của dự án, nhóm kỹ nghệ phần mềm thực hiện các bƣớc thích hợp để bảo đảm rằng các yêu cầu hệ thống chỉ định cho phần mềm, những yêu cầu mà họ chịu trách nhiệm, đƣợc lập thành tài liệu và kiểm soát.

Để đạt đƣợc sự kiểm soát này, nhóm kỹ nghệ phần mềm xem xét lại các yêu cầu hệ thống chỉ định cho phần mềm – khi bắt đầu và đã đƣợc xét duyệt - để giải quyết các vấn đề trƣớc khi chúng đƣợc tích hợp vào dự án phần mềm. Bất cứ khi nào các yêu cầu hệ thống chỉ định cho phần mềm thay đổi, các kế hoạch phần mềm, công việc phần mềm và các hoạt động bị ảnh hƣởng đƣợc điều chỉnh để bảo đảm nhất quán với các yêu cầu đã đƣợc cập nhật.

Mục tiêu 1: Những yêu cầu hệ thống về phần mềm cần đƣợc kiểm soát nhằm lập thành một phiên bản sử dụng trong quản lý và kỹ nghệ phần mềm.

Mục tiêu 2: Các kế hoạch, sản phẩm và hoạt động phần mềm cần đƣợc giữ nhất quán với các yêu cầu hệ thống về phần mềm

Hành động 1: Nhóm kỹ nghệ phần mềm xem xét các yêu cầu đƣợc chỉ định trƣớc khi chúng đƣợc tích hợp và dự án phần mềm.

Hành Động 2: Nhóm kỹ nghệ phần mềm sử dụng các yêu cầu chỉ định nhƣ là cơ sở cho các kế hoạch, sản phẩm công việc và các hoạt động phần mềm.  Hành Động 3: Các thay đổi về các yêu cầu chỉ định đƣợc xem xét và tích

2.2.3. Lập Kế Hoạch Dự án Phần Mềm

Mục đích của Lập Kế Hoạch Dự án Phần Mềm là thiết lập các kế hoạch hợp lý để thực hiện các hoạt động kỹ nghệ phần mềm và quản lý dự án phần mềm.

Lập Kế Hoạch Dự án Phần Mềm liên quan tới phát triển các ƣớc tính cho công việc cần thực hiện, thiết lập các cam kết cần thiết, và định nghĩa kế hoạch để thực hiện công việc.

Việc lập kế hoạch bắt đầu bằng một phát biểu về công việc đƣợc thực hiện và các ràng buộc khác và các mục tiêu nhằm định nghĩa và đặt phạm vi cho dự án phần mềm (những thứ đƣợc thiết lập bởi các thực hành của vùng qui trình then chốt Quản Lý Yêu Cầu). Qui trình lập kế hoạch bao gồm các bƣớc để ƣớc tính cỡ của các sản phẩm công việc phần mềm và các tai nguyên cần thiết, đƣa ra một lịch trình, xác định và đánh giá các rủi ro phần mềm, và thƣơng lƣợng các cam kết. Việc lặp lại các bƣớc này có thể là cần thiết để lập kế hoạch cho dự án phần mềm (nghĩa là kế hoạch phát triển phần mềm)

Kế hoạch này cung cấp nền tảng để thực hiện và quản lý các hoạt động của dự án phần mềm và giải quyết các cam kết của khách hàng với dự án phần mềm theo các khả năng, các ràng buộc, và các tài nguyên của dự án phần mềm.

Mục Tiêu 1: Các ƣớc tính phần mềm cần đƣợc ghi thành tài liệu để sử dụng trong việc lập kế hoạch và theo dõi dự án phần mềm.

Mục Tiêu 2: Các hoạt động và cam kết của dự án phần mềm cần đƣợc lập kế hoạch và ghi thành tài liệu.

Mục Tiêu 3: Các nhóm và cá nhân ảnh hƣởng đến dự án đồng ý với các cam kết của họ liên quan dự án phần mềm.

Hành Động 1: Nhóm kỹ nghệ phần mềm tham gia vào đội đề xuất dự án.  Hành Động 2: Việc lập kế hoạch dự án phần mềm đƣợc khởi động trong

những giai đoạn đầu hoặc song song với việc lập kế hoạch dự án nói chung.  Hành Động 3: Nhóm kỹ nghệ phần mềm tham gia cùng với các nhóm bị ảnh

hƣởng khác trong việc lập kế hoạch dự án nói chung theo suốt thời gian của dự án.

Hành Động 4: Các cam kết dự án phần mềm mà đã đƣợc thiết lập với các cá nhân và nhóm bên ngoài tổ chức cần đƣợc xem xét lại với các nhà quản lý cấp cao tuỳ theo một thủ tục đƣợc ghi thành văn bản.

Hành Động 5: Một vòng đời phần mềm với các giai đoạn có kích cỡ quản lý đƣợc đã đƣợc định nghĩa trƣớc cần đƣợc nhận diện hoặc định nghĩa.

Hành Động 6: Kế hoạch phát triển phần mềm của dự án đƣợc phát triển dựa theo một thủ tục đã đƣợc ghi thành văn bản

Hành Động 7: Kế hoạch dự án phần mềm đƣợc ghi thành văn bản

Hành Động 8: Các sản phẩm công việc phần mềm mà cần để thiết lập và kiểm soát dự án phần mềm cần đƣợc nhận biết.

Hành Động 9: Các ƣớc tính về kích cỡ của các sản phẩm công việc phần mềm (hoặc các thay đổi về cỡ các sản phẩm công việc phần mềm) đƣợc dẫn xuất theo một thủ tục đƣợc ghi thành văn bản.

Hành Động 10: Các ƣớc tính về công sức (effort) và chi phí cần đƣợc dẫn xuất theo một thủ tục đã đƣợc ghi thành văn bản.

Hành Động 11: Các ƣớc tính về các tài nguyên máy tính quan trọng cho dự án cần đƣợc dẫn xuất theo một thủ tục đã đƣợc ghi thành văn bản.

Hành Động 12: Lịch trình làm việc phần mềm của dự án cần đƣợc dẫn xuất theo một thủ tục đã đƣợc ghi thành văn bản.

Hành Động 13: Các rủi ro phần mềm dính tới chi phí, tài nguyên, lịch trình và các khía cạnh kỹ thuật của dự án đƣợc nhận diện, đánh giá và ghi thành tài liệu.

Hành Động 14: Các kế hoạch cho các công cụ hỗ trợ và trang thiết bị kỹ nghệ phần mềm của dự án đƣợc chuẩn bị.

Hành Động 15: Dữ liệu lập kế hoạch phần mềm đƣợc ghi lại

2.2.4. Theo Dõi và Giám Sát Dự án Phần Mềm

Mục tiêu của Theo Dõi và Giám Sát Dự án Phần Mềm là thiết lập cái nhìn thích hợp vào tiến độ thực của dự án từ đó nhà quản lý có thể có những hành động hiệu

quả khi hiệu suất của dự án phần mềm chệch nghiêm trọng khỏi kế hoạch phần mềm.

Theo Dõi và Giám Sát Dự án Phần Mềm liên quan tới việc theo dõi và xem lại các công việc phần mềm đã hoàn thành và các kết quả dựa vào các ƣớc tính, các cam kết, và các kế hoạch, và tinh chỉnh các kế hoạch này dựa trên các kết quả và công việc hoàn thành thực.

Một kế hoạch đƣợc viết thành văn bản cho dự án phần mềm (nghĩa là kế hoạch phát triển phần mềm, nhƣ là đƣợc mô tả trong vùng qui trình then chốt Lập Kế Hoạch Dự án Phần Mềm) sẽ đƣợc dùng nhƣ là cơ sở để theo dõi các hoạt động phần mềm, tình trạng giao tiếp, và xem lại các kế hoạch. Các hoạt động phần mềm đƣợc giám sát bởi cấp quản lý. Tiến độ đƣợc quyết định chủ yếu bằng cách so sánh kích cỡ, công sức, chi phí và lịch trình phần mềm thực với kế hoạch khi các sản phẩm công việc phần mềm đƣợc lựa chọn đã hoàn thành tại các mốc đƣợc lựa chọn. Khi quyêt định rằng các kế hoạch dự án phần mềm không đạt, các hành động sửa sai đƣợc thực hiện. Các hành động này có thể bao gồm việc xem lại kế hoạch phát triển phần mềm để phản ánh lại các việc hoàn thành thực và lập kế hoạch lại cho các công việc còng lại hoặc thực hiện các hành động để cải tiến hiệu suất.

Mục Tiêu 1: Các kết quả và hiệu suất thực đƣợc theo dõi trên các kế hoạch phần mềm.

Mục Tiêu 2: Các hành động sửa chữa đƣợc thực hiện và quản lý đến nơi đến chốn khi các kết quả và hiệu suất thực đi chệnh nghiêm trọng so với các kế hoạch phần mềm.

Mục Tiêu 3: Các thay đổi về cam kết phần mềm đƣợc các nhóm và cá nhân bị ảnh hƣởng đồng ý

Hành Động 1: Một kế hoạch phát triển phầm mềm đã đƣợc ghi lại thành văn bản cần đƣợc sử dụng để theo dõi các hoạt động phần mềm và tình trạng giao tiếp.

Hành Động 2: Kế hoạch phát triển phần mềm của dự án đƣợc duyệt lại theo một thủ tục đã đƣợc ghi thành văn bản

Hành Động 3: Các cam kết và thay đổi cam kết về dự án phần mềm của các cá nhân và nhóm ngoài tổ chức đƣợc xem xét lại với quản lý cấp cao theo một thủ tục đã đƣợc ghi lại thành văn bản

Hành Động 4: Các thay đổi đã đƣợc chấp thuận về các cam kết mà ảnh hƣởng tới dự án phần mềm đƣợc truyền đạt tới các thành viên của nhóm kỹ nghệ phần mềm và các nhóm liên quan tới phần mềm khác

Hành Động 5: Cỡ của các sản phẩm công việc phần mềm (hoặc cỡ của các thay đổi về các sản phẩm công việc phần mềm) đƣợc theo dõi, và các hành động sửa sai đƣợc thực hiện khi cần thiết.

Hành Động 6: Các chi phí và công sức phần mềm của dự án đƣợc theo dõi và các hành động sửa sai đƣợc thực hiện khi cần thiết

Hành Động 7: Các tài nguyên máy tính quan trọng của dự án đƣợc theo dõi và các hành động sửa sai đƣợc thực hiện khi cần thiết

Hành Động 8: Lịch trình phần mềm của dự án đƣợc theo dõi và các hành động sửa sai đƣợc thực hiện khi cần thiết

Hành Động 9: Các hoạt động kỹ nghệ phần mềm của dự án đƣợc theo dõi và các hành động sửa sai đƣợc thực hiện khi cần thiết

Hành Động 10: Các rủi ro phần mềm liên quan tới chi phí, tài nguyên, lịch trình và các khía cạnh kỹ thuật của dự án đƣợc theo dõi.

Hành Động 11: Dữ liệu đo đạc thực và dữ liệu trƣớc khi lập kế hoạch cho dự án phần mềm đƣợc ghi lại

Hành Động 12: Nhóm kỹ nghệ phần mềm dẫn dắt các buổi xem xét nội bộ định kỳ để theo dõi tiến độ kỹ thuật, các kế hoạch, hiệu suất, và các vấn đề dựa theo kế hoạch phát triển phần mềm.

Hành Động 13: Các buổi xem xét chính thức về sự hoàn thành và kết quả của dự án phần mềm đƣợc dẫn dắt tại các mốc đƣợc lựa chọn của dự án theo một thủ tục đƣợc ghi thành văn bản.

2.2.5. Quản Lý Hợp Đồng Phụ Phần Mềm

Mục tiêu của Quản Lý Hợp Đồng Phụ Phần Mềm là lựa chọn các nhà thầu phụ phần mềm có đủ khả năng và quản lý họ một cách hiệu quả.

Quản Lý Hợp Đồng Phụ Phần Mềm liên quan tới việc chọn nhà thầu phụ, thiết lập các cam kết với nhà thầu phụ, theo dõi và xem xét lại các kết quả và hiệu suất của nhà thầu phụ. Các thực hành này bao phủ sự quản lý hợp đồng phụ phần mềm (chỉ phần mềm thôi), cúng nhƣ là sự quản lý thành phần phần mềm của hợp đồng phụ mà bao gồm phần mềm, phần cứng, và có thể cả các thành phần hệ thống khác.

Nhà thầu phụ đƣợc lựa chọn dựa trên khả năng thực hiện công việc của họ. Nhiều nhân tố góp phần vào quyết định về thuê hợp đồng phụ cho một phần công việc của hợp đồng chính. Các nhà thầu phụ có thể đƣợc lựa chọn dựa trên các liên minh kinh doanh chiến lƣợc, cũng nhƣ là dựa trên các xem xét kỹ thuật. Các thực hành của vùng qui trình then chốt này giải quyết qui trình tìm kiếm truyền thống liên kết với việc thuê hợp đồng phụ một phần công việc đã xác định cho tổ chức khác.

Khi ký hợp đồng phụ, một thoả thuận viết thành văn bản bao phủ các yêu cầu kỹ thuật và phi kỹ thuật đƣợc thành lập và đƣợc sử dụng nhƣ là nền tảng để quản lý hợp đồng phụ. Công việc sẽ đƣợc thực hiện bởi nhà thầu phụ và các kế hoạch công việc cần đƣợc ghi thành tài liệu. Các chuẩn mà nhà thầu phụ phải tuân theo cần tƣơng thích với các chuẩn của nhà thầu chính.

Các hoạt động lập kế hoạch, theo dõi và giám sát phần mềm thực hiện với công việc đã đƣợc thầu lại cần đƣợc thực hiện bởi nhà thầu phụ. Nhà thầu chính bảo đảm rằng các hoạt động lập kế hoạch, theo dõi và giám sát này đƣợc thực hiện một cách thích hợp và rằng các sản phẩm phần mềm đƣợc chuyển giao bởi nhà thầu phụ thoả mãn các tiêu chuẩn chấp nhận của chúng. Nhà thầu chính làm việc với nhà thầu phụ để quản lý sản phẩm của họ và các giao diện qui trình.

Mục Tiêu 1: Nhà thầu chính lựa chọn các nhà thầu phụ phần mềm có đủ khả

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Quản lý quy trình phần mềm theo mô hình CMM - thực tiễn và ứng dụng ở Việt Nam Luận văn ThS Công nghệ thông tin 01.01.10 (Trang 43)

Tải bản đầy đủ (PDF)

(96 trang)