3

QUẢN LÝ DỰ ÁN PHẦN MỀM: KHÁI NIỆM VÀ QUI TRÌNH

Nội dung

3.1 Định nghĩa

3.2 Con người

3.3 Sản phẩm

3.4 Quy trình

3.5 Dự án

3.1 Định nghĩa

Quản lý dự án là tổ chức, lập kế hoạch và thiết lập lịch trình dự án. Cụ thể:

3.1.1 Khái niệm dự án

Một dự án:

- Là riêng biệt, độc lập

- Có điểm bắt đầu và điểm kết thúc

- Có sản phẩm cụ thể cuối cùng

- Là duy nhất, hoặc về sản phẩm hoặc về môi trường của nó

3.1.2 Quản lý dự án

Quản lý dự án là để đưa ra một sản phẩm cuối cùng:

- Đúng hạn

- Trong phạm vi ngân sách hay nguồn tài chính cho phép

- Phù hợp theo các đặc tả

- Với một mức độ chất lượng để phục vụ các nhu cầu kinh doanh và đáp ứng các tiêu chuẩn chuyên môn và kỳ vọng của công tác quản lý

3.1.3 Các lĩnh vực của quản lý dự án

- Con người (People)

- Sản phẩm (Product)

- Qui trình (Process)

- Dự án (Project)

3.2 Con người

Những nhà quản lý tranh luận rằng con người là chủ chốt nhưng hành động của họ đôi khi lại đi ngược với lời nói của họ. Trong phần này, chúng ta sẽ đề cập đến những người tham gia (player) vào quy trình phát triển phần mềm và cách thức mà họ được tổ chức để thực hiện phát triển phần mềm hiệu quả.

3.2.1 Những người tham gia

Trong quy trình phần mềm (và mọi dự án phần mềm) có sự tham gia của con người và được phân loại theo 5 nhóm:

1. Quản lý cao cấp (Senior manager): Là những người xác định các vấn đề nghiệp vụ có ảnh hưởng quan trọng tới dự án.

2. Quản lý dự án (Project/Technical manager): Là những người lập kế hoạch, thúc đẩy, tổ chức và kiểm soát những người phát triển phần mềm.

3. Người đang hành nghề/Người phát triển phần mềm (Practioners): Là những người sử dụng các kỹ năng về mặt kỹ thuật cần thiết để xây dựng một sản phẩm hoặc một ứng dụng.

4. Khách hàng (Customer): Là những người đưa ra các yêu cầu cho phần mềm và những cổ đông khác.

5. Người dùng cuối (End User): Là những người tác động tới phần mềm khi phần mềm đó được phát hành để sử dụng.

Để đạt được hiệu quả cao thì đội dự án phải được tổ chức theo cách phát huy tối đa khả năng và kỹ năng của mỗi người và đó là công việc của người lãnh đạo đội.

3.2.2 Lãnh đạo đội

Một cách nhìn khác về các đặc trưng xác định một người quản lý dự án hiệu quả tập trung vào 4 điểm chính:

- Giải quyết vấn đề (Problem solving):

- Đồng nhất trong quản lý (Managerial identity):

- Thành tích (Achievement):

- Uy tín và xây dựng đội (Influence and team building)

3.2.3 Đội phần mềm (Software team)

Cấu trúc đội "tốt nhất" phụ thuộc vào cách quản lý trong tổ chức của bạn, số lượng người tham gia đội, mức độ kỹ năng của họ và độ khó của toàn bộ vấn đề. Mantei đã đưa ra ba tổ chức đội tổng quát như sau:

- Phân quyền dân chủ (Democratic decentralized - DD).

- Quản lý dân chủ (Controlled decentralized - CD).

- Quản lý tập trung (Controlled Centralized - CC).

Mantei mô tả 7 nhân tố cho một dự án cần được xem xét khi lập cấu trúc của các đội phát triển phần mềm như sau:

o Mức độ khó khăn của vấn đề cần giải quyết

o Kích thước của (các) chương trình theo số dòng mã nguồn hoặc theo các điểm chức năng (function point)

o Thời gian đội sẽ làm việc cùng nhau (thời gian sống của đội)

o Mức độ vấn đề có thể chia ra (mô-đun hóa)

o Chất lượng và độ tin cậy cần có của hệ thống cần xây dựng.

o Mức độ không linh động của ngày bàn giao

o Mức độ hòa đồng (giao tiếp) cần cho dự án

Constantine đề xuất bốn "mô hình tổ chức" cho các đội phát triển phần mềm như sau:

1. Mô hình đóng (Closed paradigm) xây dựng một đội theo phân cấp truyền thống về quyền hạn (tương tự như đội CC).

2. Mô hình ngẫu nhiên (Random paradigm) xây dựng một đội lỏng lẻo và phụ thuộc vào năng lực, sáng kiến của các thành viên trong đội.

3. Mô hình mở (Open paradigm) xây dựng một đội theo cách để có được những kiểm soát kết hợp với mô hình đóng nhưng cũng có nhiều đổi mới khi sử dụng mô hình ngẫu nhiên. C .

4. Mô hình đồng bộ (Synchronous paradigm) phụ thuộc vào khả năng phân chia của các vấn đề và tổ chức các thành viên trong đội làm việc trên các mảng công việc đã phân chia với ít mức độ liên lạc không nhiều giữa họ.

3.2.4 Các vấn đề về liên lạc và phối hợp

Có rất nhiều lý do gây ra trục trặc cho các dự án phần mềm: Khả năng co dãn (scale) tình trạng không chắc chắn (Uncertainty), khả năng thao tác giữa các phần (Interoperability). Những đặc trưng này của phần mềm hiện tại - khả năng co dãn, tình trạng không chắc chắn và khả năng thao tác giữa các phần - là những thực tế của đời sống. Để giải quyết chúng hiệu quả, một đội phát triển phần mềm phải thiết lập những phương thức hiệu quả để phối hợp con người làm việc. Kraul và Streeter đã khảo sát trên một tập các kỹ thuật phối hợp của dự án và phân loại theo cách sau:

- Các hướng tiếp cận hình thức, chung, không riêng tư (Formal, impersonal approaches)

- Các thủ tục hình thức giữa cá nhân với nhau (Formal, interpersonal procedures)

- Các thủ tục không hình thức giữa các cá nhân với nhau (Informal, interpersonal procedures)

- Liên lạc điện tử (Electronic communication)

- Hoạt động mạng giữa các cá nhân với nhau (Interpersonal networking)

3.3 Sản phẩm

Chúng ta cần xem xét sản phẩm và vấn đề cần giải quyết tại thời điểm bắt đầu dự án. Những điểm sau cần quan tâm:

Hoạt động quản lý dự án phần mềm đầu tiên chính là việc quyết định phạm vi phần mềm (software scope). Phạm vi được xác định bằng cách trả lời các câu hỏi sau:

Ngữ cảnh (Context). Làm thế nào để phần mềm được xây dựng phù hợp với một hệ thống, sản phẩm hoặc ngữ cảnh nghiệp vụ lớn hơn và kết quả của ngữ cảnh là ràng buộc gì cần có?

Các mục tiêu thông tin (Information objectives). Những đối tượng dữ liệu nào khách hàng có thể nhìn thấy được được tạo ra như đầu ra của phần mềm? Những đối tượng dữ liệu nào cần thiết cho đầu vào?

Chức năng và hiệu năng (Function and performance). Chức năng nào mà phần mềm cần thực hiện để chuyển đổi từ đầu vào thành đầu ra? Có yêu cầu đặc biệt gì về hiệu năng không?

Phân rã vấn đề

Phân rã vấn đề (Problem decomposition), đôi khi được gọi là phân chia (partitioning) hay chuẩn bị kỹ lưỡng vấn đề (problem elaboration), là một hoạt động cốt lõi của công việc phân tích yêu cầu phần mềm. Trong suốt hoạt động đưa ra phạm vi phần mềm, không có sự phân rã toàn bộ vấn đề. Hơn nữa, sự phân rã này được áp dụng thành hai lĩnh vực lớn: (1) chức năng cần được bàn giao và (2) quy trình sẽ được sử dụng để bàn giao chức năng đó.

3.4 Qui trình

Mười mô hình được quan tâm và áp dụng tuỳ theo qui mô, loại dự án khác nhau:

o Mô hình tuần tự tuyến tính

o Mô hình nguyên mẫu

o Mô hình RAD

o Mô hình gia tăng

o Mô hình xoáy ốc

o Mô hình WINWIN xoáy ốc

o Mô hình phát triển dựa thành phần

o Mô hình phát triển song song

o Mô hình theo các phương pháp hình thức

o Mô hình với các kỹ thuật thế hệ 4

3.5 Dự án

Để quản lý một dự án phần mềm thành công, chúng ta cần phải biết những nguyên nhân gì dẫn đến một dự án thất bại và những yếu tố nào dẫn đến sự thành công.

3.5.1 Sự thất bại của dự án và các nguyên nhân

Một dự án mà:

• Không đạt được các mục tiêu của dự án, và/hoặc

• Bị vượt quá ngân sách ít nhất 30%

Tại sao dự án thất bại ?

Nguyên nhân

1. Cán bộ không hiểu các yêu cầu của khách hàng

2. Phạm vi của dự án không rõ ràng

3. Quản lý thay đổi yếu kém

4. Công nghệ được lựa chọn bị thay đổi

5. Các yêu cầu nghiệp vụ bị thay đổi

6. Hạn công việc không thực tế

7. Khách hàng cản trở

8. Nhà tài trợ bị thay đổi

9. Thiếu cán bộ có kỹ năng thích hợp

10. Các nhà quản lý lảng tránh các kinh nghiệm và các bài học tốt.

3.5.2 Các yếu tố thành công

- Bắt đầu bằng đối xử đúng với đúng quyền hạn

- Luôn quan tâm, chăm sóc định kỳ

- Luôn theo dõi ghi chép tiến trình

- Ra quyết định đúng đắn, sáng suốt

- Tiến hành phân tích đúc rút bài học kết thúc dự án.

10 nguyên tắc vàng

1. Quản lý dự án thành công chính là vấn đề về con người nhưng không được quên quản trị

2. Khám phá các nguồn hỗ trợ và chống đỡ

3. Sự hiện diện có thể là dối trá - xem xét lịch trình ẩn đằng sau

4. Phải hiểu rằng những con người khác nhau thì có những cách nhìn khác nhau, hãy đặt mình vào địa vị của họ

5. Thiết lập kế hoạch của bạn sao cho có thể chỉnh sửa dễ dàng

6. Đối mặt với từng sự kiện như là nó đã có từ trước

7. Sử dụng quản trị để hỗ trợ cho các mục đích của dự án

8. Thời gian mục tiêu đối với từng nhiệm vụ không được giống như đã nêu trong kế hoạch

9. Đọc lại phạm vi và các mục tiêu của dự án mỗi tuần 1 lần

10. Không ngạc nhiên!

Nguyên tắc 5W2H (Boehm)

- Tại sao hệ thống lại đang được phát triển (Why)?

- Cái gì sẽ được hoàn thành, khi nào (What, When)?

- Ai chịu trách nhiệm cho một chức năng nào đó (Who)?

- Chúng sẽ được tổ chức đặt ở đâu (Where)?

- Công việc sẽ được hoàn thành về mặt kỹ thuật và được quản lý như thế nào (How)?

- Lượng tài nguyên cần thiết là bao nhiêu (How much)?

Nguyên tắc W5HH của Boehm có thể áp dụng mà không quan tâm đến kích thước và độ phức tạp của một dự án phần mềm. Các câu hỏi trên đây cung cấp một phác thảo kế hoạch tốt cho người quản lý dự án và nhóm phần mềm.

4

CÁC KỸ NĂNG THỰC TIỄN

Nội dung

4.1. Quản lý rủi ro

4.2 Quản lý chất lượng

4.3 Quản lý cấu hình

4.4 Quản lý phiên bản

4.1. Quản lý rủi ro

4.1.1 Khái niệm?

Rủi ro là:

- Những sự kiện có thể làm phá vỡ một dự án

- Những điều không chắc chắn, những khoản nợ

hay những điểm yếu có thể làm cho dự án không đi theo đúng kế hoạch đã định

=> Có thể quản lý được

Lý do :

- Tất cả các dự án đều phụ thuộc vào rủi ro

- Tiến trình sẽ không đúng theo kế hoạch trong một số giai đoạn của dự án

- Rủi ro không thể được loại trừ triệt để

 Quy trình quản lý rủi ro nhằm giảm tối thiểu ảnh hưởng của những sự cố không biết trước cho dự án bằng cách xác định và đưa ra những giải pháp tình huống trước khi có những hậu quả xấu xảy ra

Khi nào ?

- Lập kế hoạch quản lý

- Khi trách nhiệm đối với dự án sẵn sàng thực thi

- Khi khôi phục một dự án đã bỏ dở

- Trong suốt quá trình rà xét dự án

- khi có sự sai lệch lớn so với kế hoạch xảy ra

4.1.2 Qui trình quản lý rủi ro

4.2 Quản lý chất lượng

4.1.1 Khái niệm về chất lượng phần mềm

Chất lượng phần mềm được định nghĩa như sau:

"Việc tuân thủ các yêu cầu chức năng và sự hoàn thiện đã được phát triển tường minh, các chuẩn phát triển đã được tư liệu hoá tường minh, và các đặc trưng không tường minh được trông đợi từ tất cả các phần mềm đã được phát triển theo cách chuyên nghiệp."

Định nghĩa này nhấn mạnh ba điểm quan trọng:

1. Các yêu cầu phần mềm là nền tảng để từ đó tiến hành đo đạc chất lượng. Việc thiếu tuân thủ các yêu cầu này là thiếu chất lượng.

2. Các chuẩn đặc biệt xác định ra một tập các tiêu chuẩn phát triển hướng dẫn cách thức phần mềm được sản xuất theo công nghệ. Nếu những tiêu chuẩn này không được tuân theo thì kết quả gần như chắc chắn là thiếu chất lượng.

3. Có một tập các yêu cầu không tường minh thường không được để ý tới (như mong muốn bảo trì tôt). Nếu phần mềm tuân thủ các yêu cầu tường minh nhưng lại không đáp ứng các yêu cầu không tường minh thì chất lượng phần mềm vẫn còn có phần đáng ngờ.

4.1.2 Mộ số nhân tố ảnh hưởng đến Chất Lượng phần mềm

- Tính đúng đắn. Phạm vi mà trong đó chương trình thoả mãn đặc tả của nó và thoả mãn các mục đích công việc của khách hàng.

- Tính tin cậy. Phạm vi trong đó chương trình được trông đợi thực hiện chức năng dự kiến của nó với độ chính xác được yêu cầu.

- Tính hiệu quả. Khối lượng tài nguyên tính toán và mã chương trình cần tới để thực hiện chức năng của nó.

- Tính toàn vẹn. Phạm vi trong đó việc thâm nhập vào phần mềm hay dữ liệu của những người không có quyền có thể được kiểm soát.

- Tính sử dụng được. Nỗ lực cần có để học, vận hành, chuẩn bị cái vào và hiểu cái ra của chương trình.

- Tính bảo trì được. Nỗ lực cần có để định vị và ấn định lỗi trong chương trình.

- Tính mềm dẻo. Nỗ lực cần có để thay đổi một chương trình đang vận hành.

- Tính kiểm thử được. Nỗ lực cần có để kiểm thử một chương trình để đảm bảo rằng nó thực hiện đúng chức năng dự định.

- Tính khả chuyển. Nỗ lực cần có để truyền chương trình từ môi trường hệ thống phần cứng và/hoặc phần mềm này sang môi trường khác.

- Tính tái dụng. Phạm vi trong đó một chương trình (hay bộ phận của chương trình) có thể được dùng lại trong các ứng dụng khác có liên quan tới việc đóng gói và phạm vi các chứcnăng chương trình thực hiện.

- Tinh liên tác. Nỗ lực cần có để gắn hệ thống này với hệ thống khác.

4.1.3 Đảm bảo chất lượng phần mềm

Đảm bảo chất lượng phần mềm (SQA) là một "mẫu hình hành động có hệ thống và có kế hoạch", điều hay được đòi hỏi để đảm bảo chất lượng trong phần mềm

Việc đảm bảo chất lượng phần mềm bao gồm nhiều nhiệm vụ liên kết với bẩy hoạt động chính: (1) áp dụng các phương pháp kĩ thuật, (2) tiến hành các cuộc xét duyệt kĩ thuật chính thức, (3) kiểm thử phần mềm, (4) buộc tôn trọng các chuẩn, (5) kiểm soát thay đổi, (6) đo và (7) lưu giữ và báo cáo kết quả ghi lại.

Chất lượng phần mềm được thiết kế bên trong sản phẩm hay hệ thống. Nó không bị ép buộc theo sự kiện. Bởi lí do này, SQA thực tế bắt đầu với tập các phương pháp và công cụ kĩ thuật để giúp cho người phân tích đạt tới đặc tả chất lượng cao còn người thiết kế thì phát triển thiết kế chất lượng cao

Qui trình đảm bảo chất lượng phần mềm

4.3 Quản lý cấu hình

Thay đổi là điều không thể tránh khỏi khi phần mềm máy tính được xây dựng. Và thay đổi làm tăng mức độ lẫn lộn trong các kĩ sư phần mềm, những người đang làm việc trên dự án.

4.3.1 Mục đích

Việc quản lí cầu hình phần mềm (SCM) là một hoạt động "bảo trợ" được áp dụng trong toàn bộ tiến trình kĩ nghệ phần mềm. Vì thay đổi có thể xuất hiện bất kì lúc nào, nên các hoạt động SCM được phát triển để (1) xác định sự thay đổi, (2) kiểm soát sự thay đổi, (3) đảm bảo rằng thay đổi được thực hiện đúng và (4) báo cáo về thay đổi cho người khác, những người có thể có quan tâm.

Điều quan trọng là cần phân biệt rõ giữa bảo trì phần mềm và quản lí cấu hình phần mềm. Bảo trì là một tập hợp các hoạt động kĩ nghệ phần mềm xuất hiện sau khi phần mềm đã được bàn giao cho khách hàng và đưa vào hoạt động. Quản lí cấu hình phần mềm là một tập hợp các hoạt động theo dõi và kiểm soát bắt đầu ngay khi dự án phát triển phần mềm bắt đầu và chỉ kết thúc khi phần mềm không còn được đưa vào hoạt động nữa.

4.3.2 Quản lý cấu hình

Việc quản lí cấu hình phần mềm là một tập các hoạt động đã được phát triển để quản lí thay đổi trong toàn bộ vòng đời phần mềm. SCM có thể được coi như một hoạt động đảm bảo chất lượng phần mềm, được áp dụng trong tất cả các giai đoạn của tiến trình kĩ nghệ phần mềm. Trong các mục sau đây, chúng ta sẽ xem xét các nhiệm vụ SCM chính và các khái niệm quan trọng giúp ta quản lí sự thay đổi.

Trong hai thập kỉ qua một số chuẩn về quản lí cấu hình phần mềm đã được đề nghị. Nhiều chuẩn SCM ban đầu, như MIL-STD-483, DOS-STD-480A và MIL-STD-1521A, tập trung vào phần mềm được phát triển cho các ứng dụng quân sự. Tuy nhiên, chuẩn ANSI/IEEE gần đây hơn như chuẩn ANSI/IEEE 828-1983, 1042-1987 và 1028-1988 là áp dụng được cho cả phần mềm phi quân sự và đang được giới thiệu cho cả các tổ chức kĩ nghệ phần mềm lớn và nhỏ.

4.4 Quản lý phiên bản

Việc kiểm soát phiên bản tổ hợp các thủ tục và công cụ để quản lí những bản khác nhau của các đối tượng cấu hình đã được tạo ra trong tiến trình kĩ nghệ phần mềm.

Việc quản lí cấu hình cho phép người dùng xác định các cấu hình phương án cho hệ thống phần mềm thông qua việc chọn các phiên bản thích hợp. Điều này được hỗ trợ bởi việc liên kết các thuộc tính với từng bản phần mềm, và cho phép một cấu hình được xác định (và được xây dựng) bằng việc mô tả tập hợp các thuộc tính mong muốn.

Một biểu diễn cho các phiên bản khác nhau của hệ thống là một đồ thị tiến hoá được trình bày trong hình dưới đây. Mỗi nút trên đồ thị này là một đối tượng tụ tập, tức là một phiên bản đầy đủ về phần mềm. Mỗi phiên bản của phần mềm đều là một tập hợp các SCI (chương trình gốc, tài liệu, dữ liệu), và mỗi phiên bản có thể gồm nhiều biến thể khác nhau.

Tổng kết

Quản lí cấu hình phần mềm SCM là một hoạt động hỗ trợ được áp dụng trong toàn bộ tiến trình kĩ nghệ phần mềm. SCM xác định, kiểm soát, kiểm toán và báo cáo những thay đổi thường xuất hiện khi phần mềm đang được phát triển và sau khi nó đã được đưa ra cho khách hàng. Tất cả các thông tin được tạo ra như một phần của tiến trình kĩ nghệ phần mềm trở thành một phần của cấu hình phần mềm. Cấu hình này được tổ chức theo cách thức làm cho việc kiểm soát sự thay đổi có trật tự.

Cấu hình phần mềm bao gồm một tập các đối tượng liên quan hệ với nhau, cũng còn được gọi là các khoản mục cấu hình phần mềm, đều được tạo ra như kết quả của một hoạt động kĩ nghệ phần mềm nào đó. Bên cạnh các tài liệu, chương trình và dữ liệu, môi trường phát triển được dùng để tạo ra phần mềm cũng được đặt dưới sự kiểm soát cấu hình.

Chúng ta có thể hình dung quá trình quản lý cấu hình và các thay đổi theo sơ đồ sau: