Các yếu tố làm ảnh hưởng đến năng suất và chất lượng phần mềm

• Năng lực cá nhân: Năng khiếu, lòng yêu nghề, tính sáng tạo, tính cần cù

Kỹ năng trao đổi trong tổ, nhóm

• Nói một cách thuyết phục

Mình nói người khác hiểu, người khác nói mình hiểu

Nói một cách thuyết phục

• Độ phức tạp của phần mềm

Nhiều dòng lệnh, thuật toán phức tạp, nhiều module

Phụ thuộc vào nghiệp vụ phức tạp hay đơn giản

• Cách tiếp cận hệ thống
• Thời gian được phép

Nếu thời gian căng thẳng quá => phần mềm bị làm gấp sẽ nhiều lỗi

• Khả năng hiểu thấu vấn đề, hiểu nghiệp vụ, hiểu công cụ lập trình
• Độ ổn định của các yêu cầu
• Kỹ năng đòi hỏi của những công nghệ mới: Công nghệ client/server, công nghệ Web
• Môi trường làm việc, công cụ
• Sự đào tạo, huấn luyện của tổ chức
• Kỹ năng quản lý
• Các rủi ro xảy ra

Những hạn chế của một lập trình viên mới

• Khả năng diễn đạt vấn đề
• Hiểu nghiệp vụ của những lĩnh vực ứng dụng
• Chưa có ý thức về việc bảo hành, bảo trì phần mềm
• Làm việc trong một khuôn khổ, bài bản của quản lý dự án
• Làm việc trong nhóm

Thu thập, đánh giá hiện trạng

Thu thập hiện trạng là: Dùng mọi phương sách để xác định xem các công việc (nói riêng) và toàn bộ dự án (nói chung) hiện nay đang tiến triển thế nào.

- Các bước:

1. Thu thập các dữ liệu về hiện trạng theo định kỳ (1 hoặc hai tuần). Công bố cho anh em biết
2. Thu thập dữ liệu hiện trạng từ mọi thành viên của tổ dự án.
3. Tránh đưa ra đánh giá (vội vã) khi thu thập dữ liệu. (Cần phân tích kỹ lưỡng)
4. Làm tài liệu tổng hợp (tốt nhất là tổng hợp từ các tài liệu, báo cáo điện tử)

- Mục đích cuối cùng của đánh giá: Làm rõ sự khác biệt giữa Dự kiến và Thực tế

Khác biệt có thể là xấu hoặc tốt.

Khác biệt không nhất thiết là tốt hay xấu (tuỳ từng trường hợp cụ thể)

Sai biệt lịch biểu = Ngày bắt đầu và kết thúc theo kế hoạch -

Ngày bắt đầu và kết thúc thực tại

Sai biệt ngân sách

Sai biệt chi phí = Chi phí ngân sách - Chi phí thực tế

- Nhiệm vụ của người quản lý dự án: trả lời câu hỏi

Tại sao có sự khác biệt?

Sự khác biệt là tốt hay xấu?

Có cần những hành động uốn nắn, điều chỉnh dự án hay không?

Nếu có, thì là gì?

Lập kế hoạch phòng ngừa rủi ro

- Dựa trên phân tích rủi ro, lập biểu sau:

Mô tả	Giả thiết	Xác suất	ảnh hưởng	Phản ứng
[1]	[2]	[3]	[4]	[5]

1. Mô tả: Xác định vấn đề (rủi ro)
2. Giả thiết: Hoàn cảnh có thể làm xuất hiện rủi ro
3. Xác suất: Ước lượng khả năng xuất hiện (%)
4. Đánh giá ảnh hưởng đối với dự án
5. Cách giải quyết (đối sách)

- Cần liệt kê tất cả các giả thiết ảnh hưởng tới quyết định cách giải quyết. Nếu sau này hoàn cảnh không còn hợp với các giả thiết nữa, có thể thay đổi đối sách.

- Cần được sự ủng hộ của những người chịu tác động của rủi ro.

- Với những "sự cố" đã xẩy ra mà không dự kiến được, cần ghi lại nhật ký

Mô tả	Độ quan trọng	Người chịu trách nhiệm	Ngày giải quyết
[1]	[2]	[3]	[4]

1. Mô tả, thuật lại sự cố
2. Tầm quan trọng của sự cố.
3. Tên người giải quyết sự cố.
4. Thời gian vấn đề đã được hay sẽ được giải quyết.

Kiểm soát tài liệu dự án

- Ý nghĩa của kiểm soát tài liệu

Tài liệu là sản phẩm. Phần mềm chỉ được hiểu qua tài liệu

Tài liệu cũng là công cụ làm việc

Mỗi tài liệu thuộc một loại nào đó, nhằm mục đích sử dụng nào đó: đặc tả yêu cầu, đặc tả thiết kế, báo cáo công việc, báo cáo sự cố/rủi ro, báo cáo tài chính,...

Viết tài liệu cũng khó như viết văn

Trong thực tế: tài liệu là khâu thường bị bôi bác

Không chuyển sang công việc tiếp sau, nếu tài liệu không sát thực, đầy đủ, dễ hiểu, nhất quán

Kết luận: làm tài liệu tốt trong quá trình thực hiện dự án là vấn đề khó

- Các tiêu chuẩn xem xét, đánh giá tài liệu

• Tính chính xác

Tài liệu viết có chính xác không?

Có lỗi nào hiển nhiên không?

Các mô tả về tài nguyên, môi trường của hệ thống có hợp lý không?

v.v...

• Tính rõ ràng

Tài liệu có được trình bày sáng sủa, dễ hiểu không?

Những chỗ cần dùng bảng hoặc biểu đồ thay lời nói thì có dùng hay không?

• Tính đầy đủ

Những thông tin trong tài liệu có phù hợp với mục đích tài liệu không?

Có những điểm nào quan trọng bị bỏ sót không?

Trong trường hợp một tài liệu là phát triển tiếp tục của một tài liệu khác, những điểm cần thiết của tài liệu trước có được nhắc lại hay không?

• Tính nhất quán

Cách đánh số các chương, mục, điều khoản trong tài liệu có nhất quán không?

Các ký hiệu có thống nhất không? Hoặc có theo chuẩn không?

• Mức độ chi tiết

Đủ chi tiết như mục đích và yêu cầu của tài liệu không?

Liệu có phần nào cần hoàn thiện chi tiết hơn nữa không?

- Một số tài liệu chính cần có khi thực hiện vòng đời của dự án

• Xác định, phân tích yêu cầu

Bao gồm

a/ Mô tả khái lược về hệ thống (sâu hơn tài liệu mô tả dự án)

b/ Tài liệu về yêu cầu và đặc tả

c/ Tài liệu về kế hoạch phát triển phần mềm

Chú ý: Phải đảm bảo những nội dung sau:

• Nhu cầu của khách hàng được diễn đạt theo một cách thức rõ ràng, chi tiết, mô tả hệ thống phải làm gì.
• Phải làm việc với các chuyên gia trong lĩnh vực chuyên môn để hiểu được các khái niệm nghề nghiệp, hoạt động nghiệp vụ
• Nên tận dụng những phần mềm mà khách hàng trước đây đã sử dụng (nếu có). Xem xét và thảo luận trên những phần mềm đó (về ưu/khuyết của các modules, về quan điểm thiết kế, ...)
• Mô tả những loại dữ liệu vào, ra
• Các tài liệu trên phi được đánh giá và thông qua trong 1 (hoặc một số) cuộc họp

• Thiết kế

Tên tài liệu: Tài liệu thiết kế chi tiết, làm c sở cho lập trình

Chú ý: Phải đảm bảo những nội dung sau:

• Xác định kiến trúc của phần mềm sao cho phù hợp với đặc tả hệ thống
• Phân rã các yêu cầu thành các hệ thống con
• Chi tiết hoá kiến trúc phần mềm (làm mịn dần dần), cố gắng chi tiết tới mức gần như có thể lập trình được
• Thiết kế các sơ đồ theo chức năng hoặc định hướng theo đối tượng
• Mô tả mọi dữ liệu được nhập bởi người dùng, các kết quả cần cho (ví dụ: trên màn hình, trên máy in, ...)
• Thủ tục, quy trình vận hành phần mềm
• Mô tả từng đơn vị chưng trình: chức năng, thuật toán thực hiện, giao diện, dữ liệu vào, dữ liệu ra
• Tài liệu trên phải được đánh giá và thông qua trong 1 (hoặc một số) cuộc họp

• Lập trình

a/ Tài liệu ngoài chương trình

Đặc biệt quan trọng khi

Phát triển những phần mềm lớn, thuộc những dự án lớn.

Phải xây dựng những phần mềm với sự tham gia của nhiều người. Sẽ xẩy ra trường hợp một người lập trình phải gỡ lỗi và đọc những đoạn chương trình của người khác viết. Thậm chí người này đã chuyển sang cơ quan khác.

• Việc viết tài liệu cho chương trình phi đủ rõ ràng để bảo trì chương trình
• Tài liệu cho chương trình không liên quan đến mã lệnh của chương trình.
• Nội dung chính: Mô tả chung chưng trình, mục đích chung của chưng trình, ai viết, viết khi nào, các thuật toán riêng có sử dụng, chương trình được thiết kế và phát triển cho những hệ thống nào, nguồn dữ liệu vào, những yêu cầu cần có đối với dữ liệu vào, format của dữ liệu vào, hình thức của kết quả đưa ra, v.v...
• Tài liệu cho chương trình còn bao gồm sơ đồ cấu trúc của chưng trình

b/ Tài liệu trong chương trình

Là một bài viết ngắn đặt ở đầu chương trình, dưới dạng comment. Bài viết này thường chứa những thông tin sau:

• Tên tác giả, tên nhiệm vụ, ngày giao nhiệm vụ, ngày phải hoàn thành
• Mô tả vấn đề cần giải quyết
• Cách tiếp cận để giải quyết vấn đề. Mô tả vắn tắt thuật toán, hoặc tên thuật toán nếu thuật toán đã quen thuộc đối với mọi người. Có thể chỉ ra tên tài liệu tham khảo liên quan đến thuật toán.
• Các yêu cầu khác đối với chương trình: ngôn ngữ sử dụng, chương trình dịch, nguồn của dữ liệu vào (vào bằng tay, đọc từ file,...)
• Các yêu cầu đối với chương trình còn chưa đáp ứng được, hoặc có thể cải tiến cho tốt hơn
• Các lỗi còn xuất hiện, chưa gỡ được
• v.v...

c/ Nội dung của chương trình

Những khía cạnh cần xem xét trong nội dung chương trình

• Cách đặt tên biến, tên hàm, tên lớp
• Định lề cho mỗi dòng lệnh
• Sự sáng sủa của chưng trình
• Giải thích cho chương trình (comment)
• Tổ chức chương trình
• Tính khả chuyển

Kinh nghiệm thực tế cho thấy rằng:

• Để phát triển và hoàn thiện một chương trình (đặc biệt là các chương trình lớn), lập trình viên mất 70% thời gian vào việc xem lại và cải tiến các đoạn chưng trình cũ, chỉ 30% thời gian dành cho việc viết mã lệnh mới.
• Ngoài ra, rất nhiều tình huống trong thực tế đòi hỏi người này phải đọc chương trình của người kia (để gỡ lỗi, hoặc để mở rộng thêm một số chức năng)
• Nhiều khi phải xem lại mã chương trình sau hàng tháng, hoặc hàng năm.
• Thông thường, lập trình viên làm việc dưới một sức ép về thời gian, do đó không quan tâm đến hậu quả của những đoạn mã lệnh sản sinh ra, miễn là chương trình chạy được.

• Kiểm thử và Chấp nhận phần mềm

Tên tài liệu: Tài liệu kiểm thử phần mềm

Kế hoạch và kịch bản kiểm thử (được viết dựa trên tài liệu về yêu cầu và đặc tả hệ thống)

Các hoạt động điều chỉnh

Kiểm soát thay đổi

Thực tế cho thấy: kế hoạch và thực tế không bao giờ giống nhau.

Chỉnh sửa kế hoạch – Lập kế hoạch lại

- Khi nào phải làm lại kế hoạch

• Phát hiện ra những lỗi lầm trong kế hoạch đang thực hiện
• Gặp những thay đổi quá lớn, nếu không làm lại kế hoạch thì không thể đi tiếp được

- Khi lập kế hoạch lại có thể phải cấu trúc lại một phần hay toàn bộ dự án => yêu cầu thời gian, kinh phí,...

- Làm lại kế hoạch, tức là có thể thay đổi lại tất cả những nội dung đã xây dựng: mục đích mục tiêu, mô tả sản phẩm, ước lượng thời gian, kinh phí, lịch biểu,....

• Cần tận dụng những kết quả, kinh nghiệm đã có trong lần lập kế hoạch trước => có 1 kế hoạch tốt hơn
• Xác định rõ những lý do, nguyên nhân phải lập lại kế hoạch
• Xác định rõ những thay đổi cần có trong kế hoạch mới (khác với kế hoạch cũ)
• Phải được sự đồng thuận của Ban Quản lý dự án, nhà tài trợ (có thể cả của khách hàng)
• Thời gian chi phí cho việc lập lại kế hoạch:

Nếu nhiều quá: ảnh hưởng đến tiến độ dự án

Nếu ít quá: => kế hoạch có thể sơ sài, tiềm ẩn những sai lầm

- Tránh phải lập lại kế hoạch nhiều lần