CHƯƠNG 2: TIÊU CHUẨN CỦA SẢN PHẨM PHẦN MỀM VÀ QUẢN LÝ DỰ ÁN PHẦN MỀM
Mục tiêu của công nghệ phần mềm là sản xuất ra những phần mềm tốt, có chất lượng cao. Các nhân tố ảnh hưởng đến chất lượng phần mềm có thể được phân thành hai nhóm chính: các nhân tố có thể đo trực tiếp và các nhân tố chỉ có thể đo gián tiếp.
Tuỳ theo công dụng của sản phẩm và nhu cầu thực tế của người sử dụng, các chuẩn của quốc gia, quốc tế, nền văn minh của cộng đồng, thời điểm,... mà các tiêu chuẩn để lượng hoá phần mềm có thể thay đổi.
Chương này nhằm tìm hiểu các tiêu chuẩn hiện nay được dùng để đánh giá một sản phẩm phần mềm và cách thức để quản lý dự án phần mềm.
2.1. TIÊU CHUẨN CỦA SẢN PHẨM PHẦN MỀM
Để đánh giá được sản phẩm của một nền công nghệ là tốt hay xấu, chúng ta phải nghiên cứu để đưa ra được những tiêu chuẩn đánh giá chúng. Chất lượng của sản phẩm phần mềm bao gồm nhiều yếu tố dựa trên các tiêu chuẩn đã được tổng kết.
2.1.1. Tính đúng
Một sản phẩm thực hiện được gọi là đúng nếu nó thực hiện chính xác những chức năng đã đặc tả và thỏa mãn các mục đích công việc của khách hàng.
Như vậy, một sản phẩm phải được so sánh chuẩn đặt ra để kiểm tra tính đúng và điều này dẫn đến có nhiều bậc thang về tính đúng.
Liệt kê theo thang giảm dần, tính đúng của phần mềm có thể:
+ Tuyệt đối đúng,
+ Đúng ,
+ Có lỗi,
+ Có nhiều lỗi,...
Ví dụ: Một hệ thống xử lý dữ liệu không chạy được khi file cơ sở dữ liệu rỗng hoặc có quá 104 bảng ghi,...là những hệ thống vi phạm tính đúng.
2.1.2. Tính khoa học
Tính khoa học của phần mềm được thể hiện qua các mặt
- Khoa học về cấu trúc.
- Khoa học về nội dung.
- Khoa học về hình thức thao tác.
2.1.3. Tính tin cậy
Tính tin cậy của sản phẩm phần mềm thể hiện ở sản phẩm được trông chờ thực hiện các chức năng dự kiến của nó với độ chính xác được yêu cầu.
2.1.4. Tính kiểm thử được
Phần mềm có thể kiểm thử được là phần mềm mà nó có cách dễ dàng để có thể kiểm tra được. Đảm bảo rằng nó thực hiện đúng các chức năng dự định.
2.1.5. Tính hữu hiệu
Tính hữu hiệu của phần mềm được xác định qua các tiêu chuẩn sau:
- Hiệu quả kinh tế hoặc ý nghĩa; giá trị thu được do áp dụng sản phẩm đó.
- Tốc độ xử lý sản phẩm.
- Giới hạn tối đa của sản phẩm hoặc miền xác định của chương trình được xác định qua khối lượng tối đa của các đối tượng mà sản phẩm đó quản lý.
2.1.6. Tính sáng tạo
Một sản phẩm phần mềm có tính sáng tạo khi nó thảo mãn một trong các tính chất sau:
- Sản phẩm được thiết kế và cài đặt đầu tiên.
- Sản phẩm được phục vụ cho những đặc thù riêng.
- Sản phẩm có những đặc điểm khác về mặt nguyên lý so với các sản phẩm hiện hành.
- Sản phẩm có những ưu thế nổi bậc so với sản phẩm hiện hành.
2.1.7. Tính an toàn
Tính an toàn của sản phẩm phần mềm được đánh giá thông qua:
- Có cơ chế bảo mật và bảo vệ các đối tượng do hệ thống phát sinh hoặc quản lý.
- Bản thân sản phẩm được đặt trong một cơ chế bảo mật nhằm chống sao chép trộm hoặc làm biến dạng sản phẩm đó.
2.1.8. Tính toàn vẹn
Sản phẩm phần mềm có tính toàn vẹn khi nó:
- Có cơ chế ngăn ngừa việc thâm nhập bất hợp pháp vào phần mềm hay dữ liệu và ngăn ngừa việc phát sinh ra những đối tượng (dữ liệu, đơn thể...) sai quy cách hoặc mâu thuẩn với các đối tượng sẳn có.
- Không gây ra nhập nhằng trong thao tác. Đảm bảo nhất quán về cú pháp.
- Có cơ chế phục hồi lại toàn bộ hoặc một phần những đối tượng thuộc toàn bộ hoặc một phần những đối tượng thuộc diện quản lý của sản phẩm trong trường hợp có sự cố như hỏng máy, mất điện đột ngột.
2.1.9. Tính đối xứng và đầy đủ chức năng
Sản phẩm cung cấp đủ các chức năng cho người sử dụng và các chức năng của sản phẩm có các cặp loại trừ lẫn nhau, ví dụ các chức năng đối xứng thường gặp:
+ Tạo lập - Hủy bỏ,
+ Thêm - Bớt (xem - xóa),
+ Tăng - Giảm,
+ Dịch chuyển lên - xuống; phải - trái,
+ Quay xuôi - ngược chiều kim đồng hồ,...
2.1.10. Tính tiêu chuẩn và tính chuẩn
Sản phẩm phần mềm cần đạt được một số tiêu chuẩn tối thiểu được thừa nhận trong thị trường hoặc trong khoa học, và có thể chuyển đổi dạng cấu trúc dữ liệu riêng của hệ thống sang chuẩn và ngược lại.
Tính chuẩn của phần mềm thể hiện ở sản phẩm đó phù hợp với các chuẩn quốc gia hoặc quốc tế.
Trong khi xây dựng phần mềm, cần tuân theo nguyên tắc chuẩn hoá sau:
+ Chỉ thiết kế và xây dựng phần mềm sau khi đã xác định được chuẩn.
+ Mọi thành phần của phần mềm phải được thiết kế và cài đặt theo cùng một chuẩn (tối tiểu thì các chuẩn phải tương thích nhau).
2.1.11. Tính độc lập
Phần mềm cần và nên đảm bảo được tính độc lập với các đối tượng sau:
- độc lập với thiết bị,
- độc lập với cấu trúc của đối tượng mà sản phẩm đó quản lý,
- độc lập với nội dung của đối tượng mà sản phẩm đó quản lý.
2.1.12. Tính dễ phát triển, hoàn thiện
Thể hiện ở phần mềm có thể mở rộng cho các phương án khác hoặc mở rộng, tăng cường về mặt chức năng một cách rõ ràng.
2.1.13. Một số tính chất khác
Ngoài các tính chất trên, tuỳ theo công dụng mà sản phẩm phần mềm cần phải được bổ sung các tính chất sau:
1. Tính phổ dụng: có thể áp dụng cho nhiều lĩnh vực theo nhiều chế độ làm việc khác nhau.
2. Tính đơn giản: mang những yếu tố tâm lý: dễ thao tác, dễ học, dễ hoàn thiện kỹ năng khai thác sản phẩm, trong sáng, dễ hiểu, dễ nhớ...
3. Tính liên tác: là tính chất cần có để có thể gắn hệ thống này với hệ thống khác.
4. Tính súc tích: là độ gọn của chương trình tính theo số mã dòng lệnh.
5. Tính dung thứ sai lầm: tức là những hỏng hóc xuất hiện khi chương trình gặp phải lỗi được chấp nhận.
6. Tính module: là sự độc lập chức năng của các thành phần trong chương trình.
7. Tính đầy đủ hồ sơ: hệ thống phải có đầy đủ hồ sơ pháp lý khi xây dựng.
8. Tính theo dõi được, tính dễ vận hành,...
2.2. QUẢN LÝ DỰ ÁN PHẦN MỀM
2.2.1. Các hoạt động chuẩn bị dự án
Lựa chọn phương án để phát triển hệ thống là một quyết định hệ trọng. Sơ đồ lựa chọn phương án cho một dự án phần mềm được trình bày như sau:
Trước khi lập kế hoạch dự án, cần phải thiết lập các mục tiêu và phạm vi của dự án. Người quản trị dự án và kỹ sư phần mềm lên kế hoạch điều khiển dự án, đăng ký đội ngũ nhân viên làm nhiệm vụ sau đó tiến hành lựa chọn giải pháp, phương án.
Nếu không có những thông tin này thì không thể xác định được những ước lược hợp lý và chính xác về chi phí, không thể tiến hành chia nhỏ các nhiệm vụ thực tế và không thể xác định được thời gian biểu cho dự án.
Khi các mục tiêu và phạm vi đã được hiểu rõ thì xem xét tới các giải pháp khác, những ràng buộc khác như: hạn giao hàng, khả năng nhân sự, ràng buộc ngân sách, giao diện kỹ thuật,.... để lựa chọn phương án phát triển hệ thống.
2.2.2. Lập kế hoạch dự án
Người quản trị dự án và kỹ sư phần mềm xác định nhân tố con người, máy tính và các tài nguyên tổ chức yêu cầu để phát triển ứng dụng.
Kế hoạch dự án chính là sơ đồ các nhiệm vụ, thời gian và các mối quan hệ giữa chúng. Việc lên kế hoạch, nói chung, thường gồm các bước sau:
+ Liệt kê các nhiệm vụ: gồm các nhiệm vụ phát triển ứng dụng, các nhiệm vụ đặc trưng của dự án, các nhiệm vụ về tổ chức giao diện, sự xem xét lại và các việc phê chuẩn.
+ Định danh phụ thuộc giữa các công việc.
+ Xác định nhân viên dựa vào kỹ năng và kinh nghiệm.
+ Ấn định thời gian hoàn thành cho mỗi công việc bằng các tính toán thời gian hợp lý nhất cho mỗi công việc.
+ Định danh hướng đi tới hạn.
+ Xem xét lại các tài liệu theo khía cạnh đầy đủ, nội dung, độ tin cậy và độ chắc chắn.
+ Thương lượng, thỏa thuận và cam kết ngày bắt đầu và kết thúc công việc.
+ Xác định các giao diện giữa các ứng dụng cần thiết, đặt kế hoạch cho việc thiết kế giao diện chi tiết.
Các nhiệm vụ trong lập kế hoạch dự án thường bao gồm:
1. Do tất cả các tài liệu, kế họach và công việc của nhóm là phụ thuộc vào người sử dụng, do vậy tổ chức này bao gồm người quản lý, người sử dụng, kiểm toán,...phải đưa các kiến thức chuyên ngành của mình vào những tài liệu ứng dụng một cách thích hợp.
2. Cần đạt được sự đồng ý, cam kết từ các ngành, phòng ban bên ngoài trong quá trình cung cấp tài liệu. Bên cạnh đó, bộ phận đảm bảo chất lượng phải xem xét để tìm ra các sai sót và không đồng nhất của tài liệu và tất cả các hoạt động này đều phải đạt kế hoạch.
3. Xác định các đòi hỏi về giao diện ứng dụng.
4. Đánh giá khối lượng công việc. Thời gian cho mỗi công việc phụ thuộc vào tính phức tạp và mục tiêu của nó - có ba loại thời gian cần tính đến: thời gian bi quan (P), thời gian thực tế (R), thời gian lạc quan (O). Thời gian lịch trình được tính = (O+2R+P)/4
5. Vấn đề tiếp theo là xác định kỹ năng và kinh nghiệm cần có của người thi hành nhiệm vụ để xác định dùng bao nhiêu người và có kỹ năng gì cho dự án. Sau đó xác định lịch trình làm việc và người quản trị dự án xác định ngân sách. Ở đây cần có sự trao đổi để hạn chế các trục trặc có thể xảy ra.
6. Sau khi hoàn tất, kế hoạch, lịch trình và dự toán ngân sách được đưa cho người sử dụng và người quản lý hệ thống để bổ sung hoặc thông qua.
Chú ý rằng bản kế hoạch không nên đóng cứng, nó có thể thay đổi khi công đoạn nào đó có sự cố xảy ra hoặc thời hạn tỏ ra không phù hợp hay có những thay đổi quan trọng trong mục tiêu của dự án.
2.2.3. Nghiên cứu tính khả thi dự án
a. Đề cương nghiên cứu:
1. Giới thiệu
• Phát biểu bài toán
• Môi trường thực hiện
• Các ràng buộc
2. Tóm tắt về quản lý và khuyến cáo
• Yêu cầu của quản lý
• Bình luận, nhận xét
• Khuyến cáo
• Tác động
3. Các phương án
• Cấu hình của hệ thống
• Các tiêu chuẩn để lựa chọn phương án
4. Mô tả hệ thống
• Mô tả phạm vi hoạt động của hệ thống
• Mô tả tính khả thi
5. Phân tích các phí tổn và các lợi ích
6. Đánh giá về rủi ro - mức độ rủi ro về kỹ thuật
7. Những vấn đề khác
b. Thuật toán nghiên cứu tính khả thi của một số dự án tin học
1. Tổ chức nhóm nghiên cứu tính khả thi: giai đoạn 1
2. Tìm kiếm lời giải: giai đoạn 2
3. Phân tích tính khả thi: giai đoạn 3
4. Lựa chọn lời giải: giai đoạn 4
2.2.4. Lựa chọn giải pháp
Mọi ứng dụng đều phải có chiến lược cài đặt, môi trường cài đặt và phương pháp luận. Người quản trị dự án và kỹ sư phần mềm phải lựa chọn giải pháp tốt nhất cho hệ thống.
2.2.4.1. Chiến lược cài đặt
Đây là việc lựa chọn giữa lập trình theo lô, trực tuyến, thời gian thực hay trộn lẫn giữa chúng. Việc quyết định lựa chọn phương pháp nào dựa trên sự phối hợp các yêu cầu của người sử dụng về sự chính xác của dữ liệu, dung lượng giao dịch mỗi ngày, số người làm việc trong ứng dụng vào mỗi thời điểm. Tất cả các số liệu này được đánh giá trong giai đoạn lập kế hoạch của ứng dụng, và có thể thay đổi.
Để ý rằng việc quyết định chiến lược cũng có thể thay đổi và sau đây là bảng tham khảo lựa chọn chiến lược dựa vào thời gian dữ liệu lưu hành (tính trên đơn vị giờ) và dung lượng giao dịch (tính trên đơn vị phút)
2.2.4.2. Môi trường cài đặt
Môi trường cài đặt bao gồm phần cứng, ngôn ngữ, phần mềm và các công cụ trợ giúp máy tính được sử dụng khi phát triển và triển khai ứng dụng. Quyết định không kết thúc ở giai đoạn thực hiện và lập kế hoạch, mà có các lựa chọn và một quyết định có khả năng nhất được xác định. Các đường lối được giải quyết để xác định một quyết định cuối cùng. Thường quyết định dựa trên kinh nghiệm của các quản trị viên dự án, kỹ sư hệ thống, và khả năng của các thành viên trong dự án.
Nguyên tắc chỉ đạo khi lựa chọn môi trường cài đặt là phải xuất phát từ người sử dụng. Họ đã có các trang thiết bị mà họ muốn sử dụng hay chưa? Chúng được cấu hình như thế nào? Trang thiết bị có các phần mềm hay ứng dụng gì? Người sử dụng có khả năng thay đổi cấu hình để thích hợp với ứng dụng mới không?
2.2.4.3. Phương pháp luận
Giải pháp cuối cùng được thử nghiệm quyết định là dùng phương pháp luận gì và quy trình sản xuất như thế nào? Người quản lý phải biết rằng không phải tất cả các dự án đều giống nhau, do đó cách triển khai các dự án cũng không thể giống nhau.
Với giả thiết không có yêu cầu cài đặt đặc biệt nào cả, ứng dụng tự nó phải là nhân tố cơ bản để quyết định phương pháp luận.
+ Trong môi trường kinh doanh, các quy luật cơ bản để lựa chọn phương pháp luận nhằm đánh giá sự phức tạp của ứng dụng một cách tốt nhất,
+ Nếu sự phức tạp là trong thủ tục, một phương pháp hướng xử lý là tốt nhất,
+ Nếu sự phức tạp là trong liên kết dữ liệu, một phương pháp luận hướng dữ liệu là tốt nhất,
+ Nếu bài toán dễ dàng chia nhỏ ra thành một chuỗi các bài toán nhỏ, một phương pháp đối tượng sẽ là tốt nhất,
+ Nếu dự án là nhằm xử lý trí tuệ nhân tạo hoặc bao gồm suy diễn, một phương pháp luận ngữ nghĩa là tốt nhất,...
Vấn đề lựa chọn chu kỳ tồn tại cũng đòi hỏi một số quyết định về kiểu gì và có bao nhiêu người sử dụng. Các ứng dụng phức tạp với các yêu cầu được biết thường đi kèm theo một quy trình thác nước. Nếu một số tỷ lệ của ứng dụng - yêu cầu, phần mềm, ngôn ngữ - là mới và chưa được kiểm nghiệm, kiểu tạo mẫu sẽ được sử dụng. Kỹ thuật hướng đối tượng đảm bảo kiểu mẫu và lặp. Nếu vấn đề là duy nhất, một phần trong vấn đề trước đây chưa bao giờ được tự động hóa, ngay cả một kiểu mẫu học để sử dụng hoặc một chu kỳ vòng sống sản phẩm kiểu lặp có thể được sử dụng.
2.2.5. Giám sát và kiểm soát
Khi xây dựng dự án, các thành viên của nhóm phải báo cáo việc sử dụng thời gian cho mỗi hoạt động ở các giai đoạn. Hơn nữa, mỗi cá nhân phải viết một báo cáo ngắn về tiến bộ của bản thân. Báo cáo này sẽ tóm lược chất lượng công việc, những vấn đề còn tồn tại và các sai sót hoặc các mâu thuẫn khác có thể làm trì hoãn công việc. Nếu một công việc bị chậm so với kế hoạch, thì anh ta phải giải trình về sự chậm trễ. Quản trị viên dự án và kỹ sư hệ thống phải xem xét báo cáo và thời gian biểu để xem liệu có cần bổ sung thêm gì không.
Cả kỹ sư phần mềm và quản trị viên dự án phải vạch ra các tiến bộ thật sự của các cá nhân so với thời gian biểu dự kiến. Khi sự tiến triển có vẻ chậm lại, quản trị viên dự án cần phải hỏi anh ta về các tồn tại cụ thể. Liệu đã đủ tiềm lực, hoặc liệu anh ta có nghĩ anh ta có thể đáp ứng được các hoạch định không. Nếu công việc đã bị đánh giá thấp, kế hoạch phải được kiểm tra lại để xem việc phân chia thời gian có làm chậm trễ công việc hay không, ảnh hưởng tích lũy của sự thay đổi phải được kiểm tra để xem công việc có được hoàn tất không. Nếu không, quản trị viên dự án cần thảo luận vấn đề với người quản lý của anh ta và họ sẽ quyết định các hành động cần thiết phải làm.
Cần chú rằng phải sớm chỉ ra các vấn đề tiềm tàng trước khi chúng trở thành những vấn đề lớn. Nếu một người không thể hoàn thành công việc chỉ vì anh ta được phân quá nhiều công việc, phải phân công lại cho một người khác. Nếu họ không có đủ thời gian kiểm định, phải thu xếp để có thêm thời gian. Sự quản lý tích cực sẽ ngăn chặn được nhiều vấn đề. Vấn đề tiếp theo là tính kỹ luật và lao động ảnh hưởng lên kế hoạch các công việc thay thế, điều chỉnh kế hoạch khi cần thiết và tiếp tục kiểm soát các vấn đề cho đến khi chúng được giải quyết.
Khi cần thiềt, phải nói cho khách hàng biết về các vấn đề có thể không giải quyết được do vậy họ sẽ được chuẩn bị cho sự chậm trễ nếu điều đó là không tránh khỏi. Khi sự thay đổi là cần thiết, cho khách hàng biết về sự thay đổi về ngày giờ kế hoạch thậm chí khi ngày hoàn tất công việc không thay đổi.
Có nhiều dạng vấn đề tồn đọng có thể xảy ra và quản trị viên dự án phải giám sát, thay đổi trong suốt quá trình phát triển của dự án.
i. Trong việc xác định phạm vi dự án, quản trị viên dự án phải xem xét các điều sau:
• Khách hàng có hợp tác không?
• Tất cả các đối tác có nhìn nhận và quan tâm?
• Những người sử dụng được phỏng vấn có đưa ra những thông tin đầy đủ và chính xác?
• Những người sử dụng có tham gia như mong đợi?
• Liệu có vấn đề chính sách bên ngoài nào được nêu ra?
• Quy mô, các công việc được xác định đã hợp lý chưa?
• Bằng việc phân tích, quản trị viên dự án biết hầu hết người sử dụng và họ làm việc thế nào, cần chỉ ra những vấn đề chính sách tiềm tàng và giải quyết chúng và nên hài lòng với quy mô dự án.
ii. Các hoạt động được giao cho các ban liên quan:
• Liệu tất cả các nhà phân tích có biết quy mô hoạt động và làm việc trong khuôn khổ đó?
• Công việc phân tích nhấn mạnh vào cái gì và như thế nào?
• Liệu mọi người có quan tâm và thích thú với công việc?
• Liệu có va chạm giữa các nhân viên của ban hoặc giữa những người sử dụng?
• Liệu mọi người có biết họ đang làm gì không?
• Có sự phản hồi liên tục được người sử dụng sửa đúng lại, trong kết quả phỏng vấn?
• Các thành viên của ban có bắt đầu hiểu công việc và tình hình của người sử dụng?
• Các thành viên của ban dự án có khách quan và không ép người sử dụng theo những ý tưởng của họ.
• Các tài liệu viết ra đã hoàn thiện? Người sử dụng có đồng ý?
• Việc phân tích có chỉ đúng ra các vấn đề tồn tại của người sử dụng? Các nhân viên có phân tích và mô tả chính xác các việc cần làm mà không thêm thắt?
• Việc đánh máy, in ấn, sao chụp và các hỗ trợ biên chép khác là có thể chấp nhận?
• Sự giao tiếp giữa các ban và giữa các ban và người sử dụng có đáng hài lòng không?
• Dự án có đúng thời hạn? Tình trạng đường lối phê bình? Có thay đổi nếu công việc kết thúc sớm?
• Tồn tại lớn nhất hiện tại ở đâu? Làm thế nào để làm nhẹ bớt các vấn đề tồn tại?
• Điều gì chúng ta không biết có thể làm thiệt hại đến công việc?
iii. Các yêu cầu chức năng là kết quả từ việc phân tích cần mô tả ứng dụng nào sẽ được áp dụng, và phải luôn cẩn thận trước các yêu cầu của người sử dụng. Một vấn đề mà nhiều dự án gặp phải là người sử dụng muốn một ứng dụng chức năng đơn thuần nhưng các nhà phân tích lại tạo ra một ứng dụng giá cao với các chức năng của người sử dụng nhưng có nhiều đặc tính không cần thiết. Vấn đề này, nếu xảy ra, phải được giải quyết trước khi việc phân tích kết thúc hoặc các chức năng phụ thêm sẽ được đưa vào ứng dụng kết quả. Khi vấn đề thiết kế quá mức nảy sinh, điều quan trọng là phải cố gắng truy cập đến các phân tích cụ thể để tái huấn luyện. Do vậy, quản trị viên dự án quan tâm đến:
• Các nhà phân tích có biết đến các ứng dụng?
• Việc chuyển dịch sang môi trường hoạt động có đúng và hoàn tất?
• Những người sử dụng có tham gia như mong đợi? Những người sử dụng có quan tâm đúng mức đến việc thiết kế màn hình chạy thử và chấp nhận các phê bình?
• Mọi người có quan tâm và thích thú công việc?
• Có sự va chạm giữa các nhân viên hoặc giữa nhân viên và người sử dụng?
• Mọi người có biết họ đang làm gì?
• Các nhân viên có chú ý tới sự thay đổi trách nhiệm của họ và họ có cảm thấy thoải mái để có thể tiếp tục công việc?
• Sự giao tiếp giữa các ban dự án và người sử dụng có hài lòng?
• Dự án diễn biến đúng kế hoạch? Tình trạng phê bình thế nào? Có thay đổi do công việc hoàn thành sớm không?
• Vấn đề lớn nhất bây giờ là gì? Có thể làm gì để giảm nhẹ các vấn đề?
• Điều có thể gây nguy hại cho chúng ta mà không biết? Môi trường thực hiện có thích hợp cho ứng dụng?
• Phần mềm quản lý dữ liệu có thể phù hợp với ứng dụng này không?
iv. Do sự phát triển của chương trình nên số các thành viên dự án có thể thường xuyên tăng thêm ngày càng nhiều. Sự trao đổi các thông tin là cần thiết để nắm bắt được vị trí của mọi thành viên dự án và các thành viên cũng nắm bắt được sự phát triển của dự án. Nên quá trình viết và kiểm thử chương trình sẽ được điều chỉnh trong quá trình trao đổi thông tin và chạy chương trình.
Để đáp ứng được, phải quan tâm:
• Các thành viên dự án có biết được vai trò phần việc của họ trong dự án hay không? Họ có đánh giá được phần việc của mình hay không? Các thành viên hiện tham gia dự án có đảm đương được công việc mà họ và các thành viên đang làm không?
• Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa?
• Các thành viên dự án có đủ hiểu biết về các công nghệ họ đang sử dụng để làm việc độc lập được không?
• Các thành viên mới có đủ trình độ để làm việc với các cố vấn có kinh nghiệm hay không?
• Người sử dụng có yêu cầu thêm những thay đổi hay không?
• Người sử dụng có tham gia vào quá trình kiểm thử thiết kế, có dùng các tài liệu về phát triển, nâng cấp, hướng dẫn hay không?
• Các thành phần sữa chữa phản hồi có gây cho khách hàng các nghi ngờ chương trình có lỗi hay không?
• Các giao thức sẽ được sử dụng ngày càng nhiều có thể hiện được ứng dụng hoạt động như thế nào hay không?
• Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này có thể điều chỉnh được không?
v. Trong suốt quá trình thực hiện chương trình cũng như trong quá trình thực hiện các bước kiểm thử, các kiểm tra về sự thích ứng của chương trình và về các mức hệ thống liên quan sẽ tăng dần. Các cơ sở dữ liệu được thiết lập và hoàn chỉnh dần. Môi trường điều hành được chuẩn bị.
Các cơ cấu liên quan được đưa ra từ ứng dụng được thực hiện dưới dạng mã làm cho nó được thực thi một cách chính xác. Các dạng câu hỏi đặt ra cho người quản lý có thể có các dạng sau:
• Các thành viên hiện tại của dự án có đảm nhiệm được phần công việc của mình hay không? Mọi thành viên có hiểu được công việc họ đang làm hay không?
• Thời gian kiểm thử chương trình đã đủ chưa? Thông tin truy cập đã đầy đủ chưa?
• Người sử dụng có yêu cầu thêm những thay đổi hay không? Người sử dụng có tham gia vào quá trình kiểm thử hay không?
• Các thành phần sửa chữa phản hồi có gây cho khách hàng các nghi ngờ chương trình có lỗi hay không?
• Qua từng bước thực hiện chương trình, có phát sinh ra lỗi không? Những lỗi này có thể điều chỉnh được không?
• Quá trình kiểm tra ở mức độ hệ thống có thể hiện được các chức năng như đã đặt ra hay không?
• Quá trình kiểm tra sự thích ứng có xác thực được tất cả các liên kết trung gian hay không? Nó có tác dụng như thế nào tới việc chứng tỏ độ tin cậy của các liên kết này trong suốt quá trình kiểm thử hệ thống.
• Chúng ta không biết những gì về môi trường điều hành mà nó có thể ảnh hưởng tới dự án?
• Phần mềm cơ sử dữ liệu làm việc có hoàn hảo không? Quy trình phục hồi và lưu trữ dữ liệu có đầy đủ cho quá trình kiểm thử hay không?
• Chúng ta có thể sử dụng các kiểm tra về sự thích ứng của chương trình và về hệ thống như thế nào để phát triển các giai đoạn kiểm tra hồi quy.
• Các thông tin đã hoàn tất chưa? Các thành viên dự án đã làm việc đúng khả năng chưa? Chúng ta có thể đưa các thành viên trong dự án đến thực hiện các dự án khác được không? Nếu chúng ta cho phép họ đi, thì ai sẽ thay thế vị trí họ khi có các vấn đề xảy ra?
vi. Khi quá trình kiểm thử kết thúc, các phần của ứng dụng đã thực sự sẵn sàng cho sử dụng. Nên có một sơ đồ cho ứng dụng điều hành thực tế, điều đó sẽ dễ dàng cho người sử dụng trong việc dùng chương trình để tránh có quá nhiều hỏng hóc. Sự dễ dàng trong quá trình sử dụng này sẽ tạo cho người lập dự án có thời gian cố định những lỗi sai đã phát hiện trong quá trình viết chương trình mà không có áp lực giám sát nào. Vấn đề hiện tại là tập trung vào việc đưa ra ứng dụng làm việc trong môi trường đã được định hướng cho người sử dụng nó. Các câu hỏi liên quan sẽ bao gồm:
• Vị trí đã được chuẩn bị đầy đủ chưa? Điều kiện về không gian đã đầy đủ? Thiết kế về ánh sáng và môi trường làm việc đã đầy đủ?
• Người sử dụng đã được đào tạo hoàn hảo và đã sẵn sàng làm việc?
• Chu trình làm việc và đánh giá kết quả đã được chỉ ra đầy đủ cho phép việc tiến hành và kiểm tra các kết quả đạt được.
• Khi tìm ra lỗi chúng có thể điều chỉnh được không?
• Người sử dụng có nắm bắt được công việc như dự kiến?
• Các thành viên hiện tại của dự án có thể đảm nhiệm được phần việc của họ? Tất cả mọi người có đủ công việc để làm không? Họ có thời gian rỗi để tham gia các dự án khác không?
• Thông tin trao đổi giữa các nhóm với nhau và giữa các nhóm với người sử dụng có xuất hiện phù hợp không? Người sử dụng có thể nói bất kỳ khi nào có vấn đề xảy ra không? Họ có tham gia vào quá trình lập nên các quy định cho vấn đề sửa chữa lỗi hay không?
Các câu hỏi trên là những vấn đề kỹ thuật và nên được trình lên cho chủ dự án. Quản trị viên dự án là người nắm bắt và quan tâm đến tất cả các vấn đề. Việc biên dịch các báo cáo về tiến trình hoạt động cá nhân và tiến trình hoạt động dự án trong một dự án cho phép người quản lý và bất kỳ nhân viên nào đều có thể xem xét lại những quyết định, các vấn đề xuất hiện trong quá trình tiến hành.
2.2.6. Quản lý nhân sự
Đây chính là hoạt động để bảo đảm nhân sự cho dự án. Bao gồm các giai đoạn:
+ Thuê mướn nhân sự,
+ Thẩm định, đáng giá khả năng,
+ Đào tạo, huấn luyện,
+ Tạo môi trường làm việc,
+ Sa thải.
2.3. HỒ SƠ CỦA SẢN PHẨM PHẦN MỀM
Bao gồm các thành phần liệt kê sau: tuy nhiên theo yêu cầu quản lý và bản quyền của tác giả phần mềm có thể bỏ bớt hay bổ sung thêm một số thành phần khi cần thiết:
1. Đặc tả hệ thống.
2. Kế hoạch dự án phần mềm.
a. Đặc tả yêu cầu phần mềm.
b. Bản mẫu thực hiện được hay "trên giấy".
3. Tài liệu người dùng sơ bộ
4. Đặc tả thiết kế.
a. Mô tả thiết kế dữ liệu.
b. Mô tả thiết kế kiến trúc.
c. Mô tả thiết kế module.
d. Mô tả thiết kế giao diện.
e. Mô tả sự vật (nếu kỹ thuật hướng sự vật được dùng).
5. Bản in chương trình gốc.
a. Chương trình nguồn.
b. Bản in chương trình nguồn (listing).
c. Bản mô tả thuật toán tương ứng với chương trình nguồn.
d. Kế hoạch và thủ tục kiểm thử.
e. Các trường hợp kiểm thử và kết quả ghi lại.
6. Tài liệu vận hành và cài đặt.
a. Bản liệt kê các lỗi và cách xử lý.
b. Bản liệt kê các thông số đặc trưng của hệ thống.
7. Chương trình thực hiện được.
a. Các module mã - thực hiện được.
b. Các module móc nối.
c. Chương trình đích lưu trữ trên vật mang tin.
8. Mô tả cơ sở dữ liệu.
a. Sơ đồ và cấu trúc tệp.
b. Nội dung ban đầu.
9. Tài liệu người sử dụng đã xây dựng.
a. Bản hướng dẫn sử dụng chi tiết.
b. Bản tóm tắt hướng dẫn sử dụng.
c. Các chương trình trợ giúp có liên quan.
10. Tài liệu bảo trì.
a. Báo cáo vấn đề phần mềm.
b. Yêu cầu bảo trì.
c. Trình tự thay đổi kỹ nghệ.
11. Các chuẩn và thủ tục cho kỹ thuật phần mềm .
12. Các tư liệu khác: hợp đồng, phiên bản, tài liệu pháp lý,...
Câu hỏi
1. Vì sao cần có tiêu chuẩn của phần mềm? Anh (chị) hãy đánh giá các phần mềm mà anh (chị) đã sử dụng có đáp ứng được các tiêu chuẩn phần mềm hay chưa.
2. Anh (chị) đã từng tham gia trong một dự án tin học nào chưa? Hãy đánh giá trung thực công việc bạn đã trải qua. Với nhiệm vụ đã tham gia, bạn đã gặp các thuận lợi và khó khăn nào?
3. Nếu được giao quản lý một dự án phần mềm, bạn làm gì để dự án thành công.
.jpg)
