QUẢN LÝ DỰ ÁN PHẦN MỀM
QUẢN LÝ DỰ ÁN PHẦN MỀM
- Là một tập hợp các hành động mà mục đích của nó là xây dựng và phát triển phần mềm
- Bao gồm các hoạt động:
. Đặc tả
. Phát triển: Thiết kế và cài đặt
. Kiểm thử
. Mở rộng: Bảo trì, cải tiến
1.1 Đặc tả
- Còn gọi là kỹ thuật xác định yêu cầu
-Là quy trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu và các ràng buộc trong quá trình vận hành và xây dựng hệ thống.
-Gồm 4 pha chính
. Nghiên cứu khả thi
. Phân tích và rút ra các yêu cầu
. Đặc tả yêu cầu
. Đánh giá yêu cầu
1.2 Thiết kế
- Là quá trình thiết kế cấu trúc phần mềm dựa trên những tài liệu đặc tả
-Gồm các công việc chính
. Thiết kế kiến trúc
. Đặc tả trừu tượng
. Thiết kế giao diện
. Thiết kế thành phần
. Thiết kế cấu trúc dữ liệu
. Thiết kế thuật toán
1.3 Cài đặt
-Là quá trình chuyển đổi từ tài liệu đặc tả hệ thống thành một hệ thống thực, có thể vận hành được và phải loại bỏ các lỗi của chương trình
-Hoạt động cá nhân
-Không có quy trình chung
1.4 Kiểm thử
-Xác minh và thẩm định
-Kiểm thử phần mềm
+ Lập kế hoạch kiểm thử
+ Bố trí nhân viên kiểm thử.
+ Thiết kế các trường hợp kiểm thử.
+ Xử lý đo lường kiểm thử bằng cách thu thập dữ liệu.
+ Đánh giá sản phẩm phần mềm.
1.4 Kiểm thử
- Kiểm thử đơn vị ( Unit test)
- Kiểm thử tích hợp ( Intergration test)
+ Tích hợp dần các đơn vị phần mềm
+ Phát hiện lỗi giao tiếp và sự không tương thích
+ Tại mỗi thời điểm, chỉ tích hợp thêm 1 đơn vị phần mềm
1.4 Kiểm thử
- Kiểm thử tích hợp: Có 4 loại kiểm thử cơ bản trong kiểm thử tích hợp
. Kiểm thử cấu trúc
. Kiểm thử chức năng
. Kiểm thử hiệu năng
. Kiểm thử khả năng chịu tải
-Lập kế hoạch khi thiết kế chi tiết
-Kiểm thử hệ thống
1.5 Bảo trì và cải tiến phần mềm
1.5.1 Bảo trì
- Hoạt động chỉnh sửa chương trình sau khi nó đã được đưa vào sử dụng
- Bảo trì là không thể tránh khỏi vì:
. Các yêu cầu hệ thống thường thay đổi
. Các hệ thống có gắn kết chặt chẽ với môi trường của nó.
. Các hệ thống phải được bảo trì nếu chúng muốn là những phần hữu ích trong môi trường nghiệp vụ.
Phân loại bảo trì:
- Bảo trì sửa lỗi
- Bảo trì tích hợp hệ thống vào một môi trường khác
- Bảo trì để bổ sung hoặc chỉnh sửa các yêu cầu chức năng của hệ thống
Các nhân tố anh hưởng đến bảo trì:
-Sự ổn định của đội dự án
-Những trách nhiệm đã cam kết
-Kỹ năng của nhân viên
-Tuổi thọ và cấu trúc chương trình
Các công việc bảo trì:
-Thiết lập cơ cấu bảo trì
-Báo cáo
-Lưu giữ các hồ sơ
-Xác định giá bảo trì
1.5 Bảo trì và cải tiến phần mềm
1.5.2 Cải tiến
Phải cải tiến vìthay đổi phần mềm làmột điều không thểtránh khỏi vìnhững lído sau:
- Những yêu cầu mới sẽxuất hiện khi sửdụng phần mềm
- Môi trường nghiệp vụthay đổi
- Các lỗi phần mềm cần phải sửa chữa
- Máy tính vàcác thiết bịmới được bổsung vào hệthống
- Hiệu năng hoặc độtin cậy của hệthống phải được cải thiện.
1.7 Quản lý thay đổi phần mềm
-Các ứng dụng thường xuyên phải thiết kếlại
-Các thay đổi cóthểlàcác yêu cầu, thiết kế, chương trình, giao diện, phần cứng hoặc phần mềm phải mua.
-Việc quản lýthay đổi ứng dụng giúp cho nhóm triển khai bỏqua những ýthích chợt nảy ra của người sửdụng trong khi vẫn cho phép thực hiện các yêu cầu hợp lý
2. Quản lý dự án CNPM
- Lập kế hoạch dự án
-Độ đo phần mềm
-Ước lượng phần mềm
-Quản lý nhân sự
-Quản lý cấu hình
-Quản lý rủi ro.
2.1 Lập kế hoạch dựán
a. Là bước kỹ thuật đầu tiên và cũng xuyên suốt quá trình sản xuất phần mềm, mục tiêu của lập kế hoạch dựán là đảm bảo được các yếu tố:
- Đúng thời hạn
- Không vượt dự toán
- Đầy đủ các chức năng đã thỏa thuận
- Thỏa mãn được khách hàng
b. Sau khi lập kế hoạch dự án, người quản lý dự án phải làm các công việc sau:
- Thiết lập viết đề án
- Ước lượng chi phí
- Viết và báo các kế hoạch
- Chọn người
- Theo dõi và kiểm soát dự án
- Viết báo cáo và trình diễn sản phẩm
c. Sau khi lập kế hoạch dự án, và xác định các công việc cần là, người quản lý dự án phải có trách nhiệm và quyền hạn như sau:
- Thời gian:
+Tạo lập và điều chỉnh kế hoạch
+Kiểm tra/đối chiếu các tiến trình con với kế hoạch
+Dữ một độ mềm dẻo với kế hoặc
+Phân phối các tiến trình con
- Tài nguyên: thêm tiền, thêm thiết bị, thêm người
- Thêm bớt chức năng của sản phẩm
- Rủi ro: phân tích và tìm phương pháp xử lý, chấn nhận nhưng rui ro
Ngoài ra người quản lý phải tìm mối liên hệ với các dự án khác và phải thông tin cho người quản lý cấp trên.
d. Phương pháp tiếp cận của người quản lý dự án.
- Hiển rõ mục tiêu: tìm cách định lượng các mục tiêu bất cứ lúc nào.
- Hiển rõ các ràng buộc: hiển rõ tính năng, chi phí, lịch biểu…
- Giám sát và điều chỉnh kế hoạch
- Tạo môi trường làm việc năng động cho nhóm
Một người quản lý tồi sẽ dẫn đến thất bại về tính năng, chi phi, thời gian…
2.2 Độ đo phần mềm
- Độ đo này bao gồm đo phần mềm: kích cỡ , chất lượng, hiệu năng… của phần mềm và đo quy trình phát triển phần mềm.
- Có hai cách để đo phần mềm: một là đo số dòng lệnh(Line Of Code-LOC), độ đo này khá dễ nhưng còn phụ thuộc vào ngôn ngữ lập trình và hai là đo điểm chức năng(Function Points-FP)
- Với cách dùng LOC chúng ta có thể tính được một số giá trị như:
+ Hiệu năng=LOC/người/tháng
+ Chất lượng=số khiếm khuyết/LOC
+ Chi phí=giá thành/LOC
Chúng ta còn có thể dùng các thông số của phần mềm trước đó để phục vụ cho việc ước lượng cho phần mềm sau.
- Ngoài ra còn một độ đo dựa trên thống kê, ở đây chúng ta chi đo về thời gian trung bình giữa những lần thất bại: Mean Time Between Failure(MTBF), độ đo này bằng
MTBF=MTTF+MTTR
Trong đó: MTTF là thời gian trung bình của thất bại và MTTR là thời gian trung bình để sửa chữa những thất bại tương ứng
2.3 Ước lượng
a. Công việc đầu tiên của người quản lý dự án là ước lượng - ước lượng về kích cỡ, chi phí, thời gian tiến hành dự án. Việc này thông thường được tiến hành bằng cách phân rã phần mềm cần phát triển thành các khối nhỏ và áp dụng các kinh nghiệm (các thông số như kích cỡ, chi phí, năng lực nhân viên...) đối với các phần mềm đã phát triển để ước lượng, đánh giá công việc.
b. Một mô hình ước lượng hay được dùng là mô hình COCOMO - Constructive Cost Model ước lượng chi phí từ số dòng lệnh. Dùng mô hình này ta sẽ có thể ước lượng các thông số sau:
- Nỗ lực phát triển E = aLb
- Thời gian phát triển T = cEd
- Số người tham gia N = E/T
Trong đó L là số dòng lệnh được tính theo đơn vị hàng ngàn
- Nỗ lực phát triển E = aLb
- Thời gian phát triển T = cEd
- Số người tham gia N = E/T
Trong đó a,b,c,d là các tham số tùy thuộc vào từng loại dự án.
d. Những khó khăn khi ước lượng phần mềm
- Hầu hết các thông số đều không đo được một cách trực quan
- Rất khó thẩm định được các thông số
- Không có mô hình tổng quát
- Các kỹ thuật đo còn đang thay đổi
Chúng ta không thể kiểm soát được quá trình sản xuất phần mềm nếu không ước lượng nó.
2.4 Quản lý nhân sự
Chi phí (trả công) con người là phần chính của chi phí xây dựng phần mềm. Ngoài ra, năng lực của người phát triển phần mềm lại rất biến thiên, kéo theo sự phức tạp trong tính toán chi phí. Phát triển phần mềm được tiến hành theo nhóm. Kích thước tốt của nhóm là từ 3 đến 8 người. Phần mềm lớn thường được xây dựng bởi nhiều nhóm nhỏ.
Một nhóm phát triển có thể gồm các thành viên sau:
- Người phát triển
- Chuyên gia về miền ứng dụng
- Người thiết kế giao diện
- Người quản lý cấu hình phần mềm
- Người kiểm thử
Một nhóm phát triển cần có người quản lý, và người có vai trò lãnh đạo về mặt kĩ thuật.
Một đặc trưng của làm việc theo nhóm là sự trao đổi thông tin (giao tiếp) giữa các thành viên trong nhóm. Thời gian dùng cho việc giao tiếp có thể chiếm đến nửa tổng thời gian dành cho pháp triển phần mềm. Ngoài ra, thời gian không dùng cho phát triển sản phẩm cũng chiếm một phần lớn thời gian còn lại của người lập trình.
Một người có thể đồng thời làm việc cho nhiều nhóm (dự án) phần mềm khác nhau. Điều này làm cho việc tính toán giá thành phần mềm phức tạp.
Một số điểm cần chú ý:
- Năng lực của các thành viên là không đồng đều
- Người tốt (nhất) có thể sản xuất hơn 5 lần trung bình, người kém có thể không cho kết quả gì
- Một số công việc quá khó đối với mọi người
Không nên tăng số thành viên một cách vô ý thức, vì như thế chỉ làm tăng sự phức tạp giao tiếp giữa các thành viên, khiến công việc nhiều khi chậm lại. Một số việc (phức tạp, đăc thù) chỉ nên để một người làm.
2.5 Quản lý cấu hình
Quản lý cấu hình phần mềm (còn gọi là quản lý mã nguồn) là một công việc quan trọng trong sản xuất phần mềm. Mã nguồn (và dữ liệu) là sản phẩm chính của dự án phần mềm.
Quản lý cấu hình được tự động hóa thông qua các công cụ. Nhiệm vụ chính của công cụ quản lý là:
- Lưu trữ mã nguồn
- Tạo ra một điểm truy cập duy nhất (phiên bản thống nhất) cho người lập trình sửa đổi, thêm bớt mã nguồn. Do đó chúng ta có thể dễ dàng:
+ Kiểm soát được tính thống nhất của mã nguồn
+ Kiểm soát được sự sửa đổi, lý do của sự sửa đổi, lý lịch các lần sửa đổi dễ dàng lưu trữ và truy cập tới các phiên bản khác nhau của phần mềm
+Tối ưu hóa vùng đĩa cần thiết cho lưu trữ
Phương thức hoạt động của các công cụ này là:
- Quản lý tập chung (mã nguồn, tài liệu, công cụ phát triển...)
- Các tệp được tạo một lần duy nhất, các phiên bản sửa đổi chỉ ghi lại sai phạm đối với bản gốc
- Sử dụng phương pháp check out/check in khi sửa đổi tệp
Thông thường, người phát triển khi muốn sửa đổi mã nguồn sẽ thực hiện thao tác check out tệp đó. Khi tệp đã bị check out thì các người phát triển khác chỉ có thể mở tệp dưới dạng chỉ đọc. Khi kết thúc sửa đổi và ghi tệp vào CSDL, người sửa đổi tiến hành check in để thông báo kết thúc công việc sửa đổi, đồng thời có thể ghi lại các thông tin liên quan (lý do sửa đổi...) đến sự sửa đổi
Dữ liệu được lưu trữ của dự án thông thường bao gồm:
- Mã nguồn
- Dữ liệu
- Tài liệu
- Công cụ phát triển (chương trình dịch...), thường cần để đảm bảo tương thích với các phiên bản cũ, và để đảm bảo chương trình được tạo lại (khi sửa lỗi...) đúng như cái đã phân phát cho khách hàng các ca kiểm thử
2.6 Quản lý rủi ro
Quản lý rủi ro là một công việc đặc biệt quan trọng và khó khăn trong phát triển phần mềm. Có các nguyên nhân (rủi ro) sau dẫn đến chấm dứt dự án:
- Chi phí phát triển quá cao
- Quá chậm so với lịch biểu
- Tính năng quá kém so với yêu cầu
Quản lý rủi ro bao gồm các công việc chính sau:
- Dự đoán rủi ro
- Đánh giá khả năng xảy ra và thiệt hại
- Tìm giải pháp khắc phục
Dưới đây là các rủi ro thường xẩy ra khi phát triển phần mềm và các phương pháp khắc phục chúng:
- Thiếu người phát triển: sử dụng những người tốt nhất; xây dựng nhóm làm việc; đào tạo người mới
- Kế hoạch, dự toán không sát thực tế: ước lượng bằng các phương pháp khác nhau; lọc, loại bỏ các yêu cầu không quan trọng.
- Phát triển sai chức năng: chọn phương pháp phân tích tốt hơn; phân tích tính tổ chức/mô hình nghiệp vụ của khách hàng
- Yêu cầu quá cao: lọc bớt yêu cầu; phân tích chi phí/lợi ích.
- Thay đổi yêu cầu liên tục: áp dụng thiết kế che dấu thông tin; phát triển theo môhình tiến hóa
Bạn đang đọc truyện trên: AzTruyen.Top