Luận văn TÌm hiểu qui trình phần mềm cá nhân (Personal Software Process – PSP) - Mô hình hỗ trợ việc phát triển qui trình cho kỹ sư phát triển phần mềm

thiết kế lại và kiểm thử một quy trình mới cũng là chi phí phòng ngừa. Chi phí để viết một prototype nhỏ cũng là chi phí phòng ngừa. 3.9.5 Tính toán chi phí của chất lượng PSP tính chi phí chất lượng theo một cách đơn giản. Vì thời gian bỏ ra khi biên dịch bao gồm một số thời gian biên dịch không lỗi, PSP tính tất cả các thời gian biên dịch này là chi phí sai sót. Tương tự như vậy với việc kiểm thử. Thời gian xem lại bao gồm một số chi phí sửa chữa nhưng PSP tính tất cả thời gian xem lại là chi phí đánh giá. Bạn có thể tính toán giá trị COQ với các phương pháp được mô tả trong phần Tính toán chi phí chất lượng thật sự 3.9.8, nhưng nó liên quan đến rất nhiều công việc và không thay đổi đáng kể các phép đo. Vì vậy bạn nên sử dụng các định nghĩa PSP đơn giản: Chi phí chất lượng được tính là phần trăm của tổng thời gian phát triển. Với PSP, chi phí đánh giá và sai sót được tính như sau: - Chi phí đánh giá là phần trăm tổng thời gian xem lại với tổng thời gian phát triển. 140 Sinh viên Sinh viên X Ngày 9/12/96 Chương trình Chương trình # 15 Người hướng dẫn Thầy Z Ngôn ngữ Ada Tóm tắt Kế hoạch Thực tế Đến ngày Phút/LOC 5.48 4.60 5.35 LOC/Giờ 10.95 13.04 11.21 Sai sót/KLOC 92.53 52.6 86.7 Hiệu suất 40.0 100.0 45.5 A/FR 0.375 1.93 0.44 Kích thước chương trình (LOC) Tổng mới và thay đổi 49 57 392 Kích thước tối đa 62 Kích thước tối thiểu 36 Thời gian trong pha (phút) Kế hoạch Thực tế Đến ngày Đến ngày % Lên kế hoạch 17 20 140 6.7 Thiết kế 29 38 233 11.1 Cài đặt 116 119 911 43.4 Xem lại mã 21 29 174 8.3 Biên dịch 15 5 105 5.0 Kiểm thử 41 10 289 13.8 Tổng kết 30 41 247 11.7 Tổng cộng 269 262 2099 100.0 Kích thước tối đa 340 Kích thước tối thiểu 197 Sai sót mắc phải Kế hoạch Thực tế Đến ngày Đến ngày % Sai sót/giờ Lên kế hoạch Thiết kế 1 5 14.7 1.29 Cài đặt 4 3 28 82.4 1.84 Xem lại mã Biên dịch 1 2.9 Kiểm thử Tổng cộng 5 3 34 100.0 Sai sót loại bỏ Kế hoạch Thực tế Đến ngày Đến ngày % Sai sót/giờ Lên kế hoạch Thiết kế Cài đặt Xem lại mã 2 3 15 44.1 5.17 Biên dịch 2 13 38.2 7.43 Kiểm thử 1 6 17.1 1.25 Tổng cộng 5 3 34 100.0 Bảng 3.9.1 Ví dụ bản tổng kết kế hoạch dự án - Chi phí sai sót là phần trăm tổng thời gian biên dịch và kiểm thử với tổng thời gian phát triển. 141 Ví dụ, giả sử bạn có dữ liệu quy trình cho trong bảng tóm tắt kế hoạch ở bảng 3.9.1. Bạn có thể tính chi phí đánh giá như sau: - Tổng thời gian phát triển thực tế = 262 phút - Thời gian xem lại code thực tế = 29 phút - Chi phí đánh giá = 100*29/262=11.07% Với chi phí sai sót: - Thời gian biên dịch thực tế = 5 phút - Thời gian kiểm thử thực tế = 10 phút - Chi phí sai sót = 100*(5+10)/262=100*15/262=5.73% 3.9.6 Tỉ lệ chi phi đánh giá/sai sót(A/FR – Appraisal/Failure Ratio) A/FR = chi phí đánh giá / chi phí sai sót Trong ở ví dụ phần trên, với chi phí đánh giá là 11.07% và chi phí sai sót 5.73% thì: A/FR = 11.07 / 5.73 = 1.93 Cách đơn giản hơn để tính A/FR: A/FR = thời gian xem lại code / tổng thời gian biên dịch và kiểm thử. = 29/(5+10)=1.93 (cho kết quả tương tự như trên) Dưới đây là các chỉ dẫn cập nhật cuối cùng cho bản tổng kết kế hoạch PSP: Mục đích Mẫu này ghi nhận các thông tin ước lượng và thực tế của đề án Đầu trang Nhập các thông tin: - Tên và ngày hiện tại - Tên và mã số chương trình - Tên người hướng dẫn - Ngôn ngữ sử dụng để lập trình Tóm tắt Phút/LOC Trước khi phát triển: - Nhập giá trị Phút/LOC dự kiến cho đề án này. Sử dụng tốc độ Đến ngày từ chương trình gần nhất trong bản ghi công việc hay bản tổng kết kế hoạch dự án. Sau khi phát triển: - Chia tổng thời gian phát triển cho độ lớn chương trình thực tế để có chỉ số Phút/LOC thực tế và Đến ngày - Ví dụ, nếu dự án phát triển mất 196 phút và gồm 29 LOC, chỉ số Phút/LOC sẽ là 196/29=6.76 LOC/Giờ Trước khi phát triển: - Tính LOC/Giờ dự kiến bằng cách lấy 60 chia cho Phút/LOC dự kiến Sau khi phát triển: - Để tính LOC/Giờ thực tế và Đến ngày, lấy 60 chia cho Phút/LOC thực 142 tế Đến ngày Ví dụ: Với chỉ số Phút/LOC thực tế là 6.76, chỉ số LOC/Giờ thực tế là 60/6.76=8.88 Sai sót/KLOC Trước khi phát triển: - Tìm số sai sót/KLOC trong các chương trình gần đây nhất. - Sử dụng giá trị này như là số sai sót/KLOC kế hoạch cho dự án này. Sau khi phát triển: - Tính số sai sót/KLOC thực tế và Đến ngày cho chương trình này. - Với giá trị thực tế: Tổng số sai sót thực tế *1000 / Tổng LOC Mới và Thay đổi thực tế - Tính toán tương tự cho giá trị Đến ngày - Ví dụ: với 17 sai sót Đến ngày và 153 LOC Mới và Thay đổi thì chỉ số sai sót/KLOC Đến ngày là = 1000*17/153 = 111.11 Hiệu suất Tính hiệu suất kế hoạch, thực tế và Đến ngày. Hiệu suất = 100 * (sai sót loại bỏ trước khi biên dịch) / (sai sót mắc phải trước khi bên dịch) Với 5 sai sót mắc phải và 4 sai sót loại bỏ, hiệu suất = 100*4/5=80.8% A/FR Tính giá trị A/FR kế hoạch, thực tế và Đến ngày. Ví dụ với A/FR thực tế = (Thời gian xem lại code thực tế) / (Tổng thời gian biên dịch và kiểm thử thực tế) Với thời gian biên dịch 29 phút, thời gian biên dịch 5 phút và kiểm thử là 10 phút, A/FR = 29/(5+10)=1.93 Độ lớn chương trình (LOC) Trước khi phát triển: - Nhập giá trị Tổng cộng, Tối đa và tối thiểu của LOC Mới & Thay đổi Sau khi phát triển: - Đếm và nhập giá trị LOC Mới & Thay đổi thực tế. - Với Đến ngày, cộng thêm LOC Mới và Thay đổi thực sự với LOC mới và Thay đổi Đến ngày của chương trình trước đó. Thời gian bỏ ra ở từng giai đoạn Kế hoạch Đối với Tổng thời gian phát triển (Total Development time), nhân LOC Mới & Thay đổi với Phút/LOC Đối với Thời gian tối đa, nhân độ lớn tối đa (Maximum size) với Phút/LOC. Đối với Thời gian tối thiểu, nhân độ lớn tối thiểu (Minimum size) với Phút/LOC. Từ bản tổng kết kế hoạch dự án của chương trình gần nhất, tìm giá trị Đến ngày % cho mỗi pha. Sử dụng Đến ngày % từ chương trình trước đó, tính toán thời gian kế hoạch cho mỗi pha. Thực tế Sau khi hoàn tất, nhập thời gian thực tế tính theo phút trong mỗi pha phát trỉển. Lấy dữ liệu này từ Bản ghi nhận thời gian Đến ngày Với mỗi pha, điền vào tổng thời gian thực tế và thời gian Đến ngày từ chương trình gần nhất. Đến ngày % Với mỗi pha, điền vào (thời gian Đến ngày * 100) / Tổng thời gian Đến 143 ngày. Sai sót mắc phải Kế hoạch Trước khi phát triển, ước lượng tổng số sai sót sẽ có thể mắc phải trong chương trình: sai sót/KLOC kế hoạch * LOC Mới và Thay đổi kế hoạch của chương trình / 1000 Ví dụ, với sai sót/KLOC kế hoạch là 75.9 và LOC Mới và Thay đổi là 75, tổng số sai sót kế hoạch = 75.9*75/1000 = 5.96, làm tròn thành 6. Trước khi phát triển, ước lượng sai sót mắc phải trong từng pha bằng cách sử dụng tổng sai sót ước lượng và sự phân bố sai sót mắc phải Đến ngày % của chương trình trước. Thực tế Sau khi phát triển, tìm và điền số lượng sai sót thực tế mắc phải trong mỗi pha Đến ngày Với mỗi pha, nhập vào tổng số sai sót thực tế và sai sót Đến ngày từ chương trình gần nhất. Đến ngày % Với mỗi pha, nhập vào 100*(Sai sót Đến ngày của pha đó)/(Tổng sai sót Đến ngày) Sai sót loại bỏ Kế hoạch Ở dòng tổng cộng, điền vào tổng số sai sót ước lượng. Sử dụng các giá trị Đến ngày từ chương trình gần nhất, tính toán sai sót kế hoạch loại bỏ được trong mỗi pha. Thực tế Sau khi phát triển, tìm và điền số lượng sai sót thực tế loại bỏ trong mỗi pha Đến ngày Với mỗi pha, nhập vào tổng số sai sót thực tế và sai sót Đến ngày từ chương trình gần nhất. Đến ngày % Với mỗi pha, nhập vào 100*(Sai sót Đến ngày của pha đó)/(Tổng sai sót Đến ngày) Bảng 3.9.2 Chỉ dẫn cho bản tổng kết kế hoạch A/FR đo lượng thời gian tiêu tốn tương đối trong việc tìm lỗi trước khi biên dịch lần đầu. Khi A/FR<1, việc kiểm thử chương trình thường tìm ra nhiều lỗi. Mặc dù điều này là không bảo đảm, hầu hết các chương trình nằm trong giới hạn này có một số lượng khá cao sai sót kiểm thử/KLOC. Ngoài ra, các quy trình với A/FR>2 có ít lỗi hơn là quy trình có A/FR=2 để tạo ra sản phẩm không lỗi. Sử dụng giá trị A/FR Để đạt được A/FR trên 2.0, hãy xem lại thời gian kiểm thử và biên dịch lịch sử, lên kế hoạch để dùng ít nhất 2 lần lượng thời gian đó trong việc xem lại code lần tới. Bạn có thể làm tăng A/FR bằng cách chỉ việc dùng nhiều thời gian hơn trong việc xem lại code. Tuy nhiên, chỉ trừ khi bạn tìm thấy sai sót, còn nếu không nó sẽ không cải tiến chất lượng chương trình. 144 Chừng nào mà hiệu suất của bạn chưa đạt được giới hạn 80% đến 100%, hãy tiếp tục tăng A/FR lên. Tuy nhiên bạn không được làm điều này bằng cách chỉ đơn thuần thực hiện nhiều thời gian hơn mà còn phải xem lại dữ liệu sai sót cho các chương trình phát triển gần đây và nghĩ ra cách để tìm thấy tất cả các sai sót mà bạn thường hay bỏ sót. Sau đó, thêm vào các bước thích hợp trong danh sách xem lại code. Cuối cùng, theo các bước xem lại khi bạn thực hiện xem lại code. Nếu bạn làm như vậy, bạn sẽ mất thời gian hơn cho thời gian xem lại, sẽ tìm ra nhiều lỗi hơn và sẽ tăng A/FR, đồng thời giảm số sai sót bạn tìm thấy trong biên dịch và kiểm thử. Điều này sẽ tiết kiệm rất nhiều thời gian kiểm thử, giảm chi phí sai sót và tạo ra sản phẩm có chất lượng cao hơn. Chú ý rằng khi chỉnh sửa các chương trình lớn hơn, thường cần kiểm thử nhiều hơn cho dù không có sai sót nào. Trong những trường hợp này, giá trị A/FR thường sẽ thấp hơn. 3.9.7 Cải tiến tốc độ xem lại Đừng quan tâm đến tốc độ xem lại sai sót/giờ cho đến khi bạn tìm thấy hầu hết các lỗi trước khi biên dịch và kiểm thử một cách ổn định. Tuy nhiên, một khi bạn đã tìm ra hầu hết lỗi trong xem lại code, hãy nghĩ đến việc cải tiến tốc độ xem lại bằng cách: nhận diện bất cứ bước xem lại nào mà không tìm thấy lỗi cũng như là bỏ sót lỗi. Kế đó, kiểm tra lại các lý do tại sao ban đầu bạn đưa các bước này vào. Nếu các vấn đề này không còn là vấn đề nữa thì bỏ qua các bước này. Mặt khác, nếu bạn nghĩ chúng vẫn còn quan trọng, kết hợp một vài trong số chúng để bạn có thể thực hiện chúng nhanh chóng. Với mỗi chương trình, tiếp tục giám sát dữ liệu sai sót và phục hồi lại các bước xem lại đã bắt được lỗi mà sau đó bạn đã bỏ sót. Tuy nhiên, khi các bước không hiệu quả, đừng do dự bỏ chúng. 3.9.8 Tính toán chi phí chất lượng thật sự Với PSP, các tính toán chi phí chất lượng đơn giản là thích hợp. Tuy nhiên, khi bạn làm việc với các dự án phát triển lớn, bạn có thể muốn sử dụng phép đo chi phí chất lượng chính xác hơn. Để thực hiện, bạn phải chia các thời gian xem lại, biên dịch và kiểm thử thành các thành phần đánh giá và sai sót tương ứng. Ví dụ, chúng ta có thể ghi nhãn cho thời gian biên dịch khi không có sai sót được tìm thấy là biên dịch đánh giá hay CA và thời gian vá lỗi suốt quá trình biên dịch là biên dịch sai sót hay CF. Vì vậy, CF + CA = C (tổng thời gian 145 biên dịch). Với thời gian xem lại và kiểm thử, RF + RA = R (tổng thời gian xem lại), và TF + TA = T (tổng thời gian kiểm thử). Tính toán như sau: Chi phí chất lượng đánh giá = 100*(RA + CA + TA )/(tổng thời gian phát triển) Chi phí chất lượng sai sót = 100*(RF + CF + TF )/(tổng thời gian phát triển) Loại sai sót 10 Sưu liệu 60 Kiểm tra 20 Cú pháp 70 Dữ liệu 30 Xây dựng, đóng gói 80 Chức năng 40 Chỉ định 90 Hệ thống 50 Giao diện 100 Môi trường Sinh viên Sinh viên X Ngày 9/12/96 Người hướng dẫn Thầy Z Chương trình # 15 Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 12/9 1 40 cài đặt xem lại 2 Mô tả Thiếu khai báo Set_X Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 2 80 thiết kế xem lại 8 Mô tả quên rằng chỉ tiến lên 1 bước trong vòng lặp while nếu lẻ Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 3 20 cài đặt xem lại 1 Mô tả thiếu “;” Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa Mô tả Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa Mô tả Bảng 3.9.3 Ví dụ bản ghi ghi chép sai sót Ví dụ sau sử dụng dữ liệu trong bảng tóm tắt kế hoạch dự án trong bảng 3.9.1 và bản ghi ghi chép sai sót trong bảng 3.9.3. Đầu tiên tính các giá trị RA, CA, TA, RF, CF, TF như sau: 146 - RF: tính từ bản ghi ghi chép sai sót, là tổng của thời gian vá các lỗi trong xem lại code: RF = 2+8+1=11 - RA = R-RF = 29-11=18 - Vì không có lỗi được tìm thấy trong biên dịch nên tất cả thời gian là thời gian đánh giá: CA = 5 và CF = 0 - Vì không có lỗi được tìm thấy trong kiểm thử, tất cả thời gian kiểm thử là thời gian đánh giá, vì vậy TA = 10 và TF = 0 Với các giá trị này, chúng ta tính các giá trị đánh giá và sai sót như sau: Chi phí chất lượng đánh giá = 100*(RA + CA + TA )/(tổng thời gian phát triển) = 100*(18+5+10)/262 = 100*33/262 = 12.60% Chi phí chất lượng sai sót = 100*(RF + CF + TF )/(tổng thời gian phát triển) = 100*(11+0+0)/262 = 100*11/262 = 4.20% Các giá trị này hơi khác so với các giá trị được tính trước đây. Chúng cũng đưa ra một giá trị A/FR cao hơn đáng kể là 3.0 thay vì 1.93. Vì các giá trị A/FR và COQ chính xác hơn này khá nhạy với thời gian sửa lỗi nên bạn không nên sử dụng phương pháp này trừ khi bạn đo thời gian sửa lỗi bằng đồng hồ bấm giờ. Bạn cũng sẽ muốn đưa ra một mục tiêu A/FR khác vì A/FR có giá trị là 2.0 bây giờ có thể dẫn đến quá nhiều sai sót kiểm thử. 147 Chương 4. Một số kết quả áp dụng PSP vào trong thực tế 4.1 Trong môi trường công nghiệp [5] Mặc dù PSP đã được giới thiệu khá nhiều về mặt lý thuyết, nhưng về mặt thực tế áp dụng thì vẫn còn khá ít công ty, tổ chức sử dụng nó. Nguyên nhân là do việc đem áp dụng rộng rãi PSP vào trong các kỹ sư đòi hỏi phải có thời gian và sự nỗ lực. Bên cạnh đó, PSP cũng đòi hỏi phải có những dữ liệu lịch sử. Đó chính là điểm hạn chế mà cho đến hiện nay, những số liệu sử dụng hiệu quả PSP còn khá ít. Tuy nhiên, có 3 nhóm phát triển phần mềm đã sử dụng PSP và đã ghi nhận lại các số liệu chứng minh tính hiệu quả của việc sử dụng nó. Ba nhóm này là: Advanced Information Services, Motorola Paging Products Groups và Union Switch & Signal Inc. Mỗi nhóm này đã huấn luyện một đội ngũ các kỹ sư sử dụng PSP và đo kết quả của một vài dự án có sử dụng PSP. Ngôn ngữ sử dụng trong các dự án của 3 công ty trên đều là C và C++. 4.1.1 Advanced Information Services (AIS) 4.1.1.1 Giới thiệu AIS có trụ sở chính đặt tại Illinois và một bộ phận hỗ trợ đặt tại Madras, Ấn Độ, là một công ty phần mềm chuyên phát triển những sản phẩm phần mềm, các dịch vụ mạng và huấn luyện qui trình. Để thử nghiệm tính hiệu quả của PSP, AIS đã gửi những kỹ sư của công ty đến viện SEI để học tập và sử dụng qui trình này. Sau khi kết thúc khoá học, các kỹ sư đã áp dụng những điều đã học vào trong quá trình thực hiện công việc của mình. AIS đã ghi nhận số liệu của 7 dự án có sử dụng qui trình PSP. 4.1.1.2 Kết quả thu được 4.1.1.2.1 Dự án A Dự án đầu tiên có sử dụng PSP vào năm 1995 có sự tham gia các của các kỹ sư ở Illinois và Madras. Các thành phần (component) trong dự án này có kích thước từ 500 đến 2200 LOC. Trước tháng 4 năm 1995, các kỹ sư đã hoàn tất các thành phần 1, 2 và 3 nhưng dự án vẫn không thực hiện đúng như ngày đã lập kế hoạch. Do đó, dự án A đã phải lên kế hoạch lại và công ty phải thương lượng với khách hàng về thời gian bàn giao sản phẩm. 148 Đến thời điểm này, người trưởng dự án đã quyết định sử dụng PSP. Các kỹ sư trong nhóm phát triển lúc này sẽ tự lên kế hoạch và phát triển các thành phần từ 4 đến 9. Hình 4.1.1 Ước lượng kế hoạch cho dự án A của AIS Trong hình trên, ở các thành phần từ 1 đến 3, mức độ chênh lệch giữa số tuần ước lượng và số tuần thực tế đã thực hiện chênh lệch khá nhiều. Tuy nhiên, ở những thành phần sau, sự chênh lệch giảm dần và đặc biệt ở thành phần 8, sự ước lượng và thực tế là bằng nhau. Hình 4.1.2 Tỉ lệ chênh lệch kế hoạch trong dự án A của AIS Hình trên cho thấy, trước khi sử dụng PSP, tỉ lệ sai sót trong ước lượng là 394% (thành phần 1) nhưng ở thành phần 4 tỉ lệ này còn – 10.4%. 149 Hình 4.1.3 Chất lượng của dự án A Trong hình trên, ở Illinois (location 1), trong những thành phần đầu (từ 1 đến 3), do các kỹ sư không sử dụng PSP, tỉ lệ sai sót là 0.76 sai sót/1000LOC (Location 1 Non – PSP). Nhưng sau khi áp dụng PSP, từ các thành phần 4 đến 9, tỉ lệ sai sót là 0.17 sai sót/1000LOC => chất lượng đã tăng 78%. Ở Madras (location 2), các kỹ sư không được huấn luyện PSP, tỉ lệ sai sót là 0.85 sai sót/1000 LOC. Hình 4.1.4 Hiệu quả làm việc của các kỹ sư Hình trên mô tả, ở Illinois (Location 1), trước khi sử dụng PSP, hiệu suất làm việc của các kỹ sư là 7.99 LOC/giờ. Sau khi huấn luyện PSP (Location 1 - PSP), hiệu suất tăng lên 8.58 LOC/giờ, nghĩa là tăng 7.4%. Với các kỹ sư ở Madras (location 2) hiệu suất chỉ là 6.4 LOC/giờ. 4.1.1.2.2 Dự án B, C, D, E, F, G Dự án B sử dụng 3 kỹ sư và cả 3 kỹ sư này đều được huấn luyện PSP. Tổng số sai sót trong quá trình kiểm tra là 1 và không có những sai sót do khách hàng báo lại. Dự án kết thúc sớm hơn so với kế hoạch, do đó đáp ứng đúng yêu cầu thời hạn giao sản phẩm cho khách hàng. 150 Dự án Kỹ sư được huấn luyện PSP Kỹ sư không được huấn luyện PSP Kích thước sản phẩm Kế hoạch/Thực tế (Tháng) Số sai sót trong pha kiểm tra Số sai sót trong quá trình khách hàng sử dụng B 3 0 24 yêu cầu 7/5 1 0 C 0 3 19 yêu cầu 2/5 11 1 D 0 3 30 yêu cầu 10/19 6 14 E 1 0 2255 LOC 6/6 0 0 F 1 0 1400 LOC 2/2 0 0 G 2 1 6196 LOC 2/2 0 3 Bảng 4.1.1 bản tổng kết của các dự án B, C, D, E, F, G Dự án C sử dụng tổng cộng 3 kỹ sư và 3 kỹ sư này chưa được huấn luyện PSP. Tuy nhiên, dự án B và C được đánh giá là tương tự nhau về các mặt ngôn ngữ lập trình, độ phức tạp của yêu cầu… Ba kỹ sư sử dụng trong dự án này là những người có kinh nghiệm hàng đầu trong công ty. Kết quả là dự án C trễ thời hạn giao cho khách hàng. Sai sót trong pha kiểm tra là 11 và sau khi bàn giao sản phẩm vẫn còn 1 sai sót do khách hàng báo lại. Các dự án E, F sử dụng đội ngũ kỹ sư đều được huấn luyện PSP thì kết quả rất tốt. Giao sản phẩm đúng lịch với khách hàng, sai sót trong pha kiểm tra và những sai sót do khách hàng báo lại không có. Trong khi đó, dự án G, sử dụng 2 kỹ sư được huấn luyện PSP và một kỹ sư không được huấn luyện PSP, kết quả là phần mềm vẫn kịp thời gian giao cho khách hàng nhưng sau khi bàn giao vẫn còn 3 sai sót do khách hàng báo lại. Hình dưới cho thấy, nhóm 1 gồm những dự án mà các kỹ sư không được huấn luyện PSP, tỉ lệ sai sót/KLOC cao. Nhóm 2 gồm những dự án có một số phần kỹ sư được huấn luyện PSP, số còn lại không được huấn luyện thì tỉ lệ sai sót thấp hơn so với nhóm 1 nhưng vẫn còn ở mức cao. Trong khi đó nhóm 2 với những dự án sử dụng 100% kỹ sư được huấn luyện PSP thì tỉ lệ này rất thấp và có khi đạt được giá trị là 0. Hình 4.1.5 Chất lượng của các dự án B, C, D, E, F, G 151 Ngoài những lợi ích đã bàn ở trên, khi sử dụng PSP trong quá trình phát triển phần mềm, các tổ chức phần mềm cũng đã giảm thiểu khá lớn thời gian kiểm tra hệ thống. Dữ liệu cụ thể như sau: Kích thước Thời gian kiểm tra hệ thống Dự án không sử dụng kỹ sư được huấn luyện PSP A1 15800 LOC 1.5 tháng C 19 yêu cầu 3 vòng kiểm tra (test cycles) D 30 yêu cầu 2 tháng H 30 yêu cầu 2 tháng Dự án có sử dụng kỹ sư được huấn luyện PSP A2 11700 LOC 1.5 tháng B 24 yêu cầu 5 ngày E 2300 LOC 2 ngày F 1400 LOC 4 ngày G 6200 LOC 4 ngày I 13300 LOC 2 ngày Bảng 4.1.2 Một số dữ liệu về thời gian kiểm tra hệ thống Trước khi sử dụng PSP, thời gian dành cho việc kiểm tra hệ thống tốn khá nhiều. Tuy nhiên với những dự án có sử dụng đội ngũ kỹ sư được huấn luyện PSP thì thời gian kiểm tra hệ thống giảm xuống rất nhiều. Trong dự án A2, thời gian kiểm tra hệ thống nhiều vì dự án này phải được kiểm tra kết hợp với dự án A1. 4.1.2 Motorola Paging Products Group 4.1.2.1 Giới thiệu Motorola Paging Products Group là một công ty chuyên sản xuất các thiết bị di động hay máy nhắn tin… Trụ sở của công ty đặt tại bãi biển Boynton, Florida. Ba người quản lý của Motorola và 2 giáo sư từ đại học Embry – Riddle Aeronautical đã giới thiệu PSP vào trong công ty. Cho đến nay thì Motorola đã tổ chức 3 lớp huấn luyện PSP, huấn luyện được 40 kỹ sư và 22 người quản lý. Motorola đánh giá khá cao quy trình này và đã sử dụng khoảng 8 giờ/tuần cho việc huấn luyện và 4 giờ khác cho việc tập luyện cải tiến quy trình. Bên cạnh đó, để khuyến khích các kỹ sư sử dụng PSP, ban giám đốc còn xây dựng logo cho các đội thể thao của công ty mang biểu tượng PSP. Những cá nhân hoàn thành tốt khoá học PSP đều có thưởng về tài chính và được tham gia câu lạc bộ PSP hoạt động vào hàng tháng. 152 4.1.2.2 Kết quả thu được Số dự án Kích thước (LOC) Số tháng sử dụng Tổng sồ sai sót Sai sót trong quá trình kiểm tra Sai sót trong quá trình sử dụng 1 463 18 13 5 0 2 5465 NA 69 10 0 3 1571 NA 47 8 0 4 3381 NA 69 22 0 5 5 9 0 0 0 6 22 5 2 0 0 7 1 18 1 0 0 8 2081 10 34 0 1 9 114 8 15 2 0 10 364 NA 29 2 0 11 7 5 0 0 0 12 620 3 12 2 0 13 720 NA 9 2 0 14 3894 NA 20 2 0 15 2075 NA 79 27 0 16 1270 NA 20 1 0 17 467 NA 17 3 0 18 3494 8 139 50 0 Tổng cộng 25114 NA 575 136 1 Bảng 4.1.3 Dữ liệu của 18 dự án trong quá trình thử nghiệm hiệu quả của PSP Trong dự án 1, thời gian thực tế nhiều hơn thời gian lập kế hoạch, nhưng do thời gian sử dụng trong pha kiểm tra giảm 60% so với những dự án trước (không sử dụng PSP) nên tổng thời gian sử dụng cho toàn dự án ít hơn 44% so với thời gian kế hoạch. Trong dự án 2, tổng cộng sai sót trong dự án là 69, tuy nhiên phần lớn các sai sót này đều đã được tìm thấy và loại bỏ từ các pha trước. Đến pha kiểm tra thì chỉ còn lại 10 sai sót do đó dự án đã giảm được hơn 80% sai sót trước khi đến pha kiểm tra. Những giá trị NA trong cột số tháng sử dụng là những số mà Motorola không xác định được. 4.1.3 Union Switch & Signal Inc 4.1.3.1 Giới thiệu Công ty Union Switch & Signal (US & S) chuyên sản xuất nhiều sản phẩm phẩn cứng phục vụ cho các ngành công nghiệp vận chuyển. Công ty chuyên phát triển và lắp đặt các hệ thống điều khiển thời gian thực. Trụ sở của công ty đặt tại Pittsburgh và có khoảng 100 nhân viên phần mềm. 153 US & S đã tổ chức 3 lớp học PSP cho 9 người quản lý và 25 kỹ sư phần mềm. 4.1.3.2 Kết quả thu được Sau khi huấn luyện PSP, các kỹ sư đã thực hiện 5 dự án và con số thực tế thu thập được sau khi thực hiện 5 dự án này như sau: Sản phẩm LOC Số tháng sử dụng Số sai sót trong tìm thấy trong pha kiểm tra Số sai sót tìm thấy trong khi sử dụng M45 193 9.0 4 0 M10 453 7.5 2 0 M77 6133 4.0 25 0 M54 477 3.5 5 0 M53 1160 1.0 21 0 Tổng cộng 8416 NA 57 0 Bảng 4.1.4 Dữ liệu thực tế của các dự án sau khi kỹ sư được huấn luyện PSP 4.1.4 Một số nhóm phát triển phần mềm khác Ngoài cuộc khảo sát kết quả sử dụng của 3 công ty trên do sự phối hợp của 3 công ty với viện SEI, nhiều tổ chức đã áp dụng PSP và cũng thu được những kết quả khả quan. Công ty FIDA: một công ty được chứng nhận ISO 9001 chuyên sản xuất các điều khiển số học. FIDA bắt đầu sử dụng PSP vào tháng 4/1997. Trước khi sử dụng PSP, việc ước lượng trong dự án chủ yếu dựa vào sự tương tự. Nghĩa là, công ty xem xét dự án mới có gần giống với những dự án nào trước đó và tính ra được thời gian và chi phí. Tuy nhiên, sau khi sử dụng PSP, công ty đã sử dụng mối quan hệ giữa kích thước và thời gian để ước lượng. Thêm vào đó, hiệu quả công việc, tỉ lệ sai sót cũng giảm thiểu đáng kể. [6] Teradyne sử dụng qui trình PSP, xây dựng một hệ thống gồm tổng cộng 90000 LOC. Sau khi hoàn thành, thời gian lúc đầu dự kiến là 77 tuần nhưng khi thực hiện chỉ 71 tuần (sớm hơn 8%), chất lượng phần mềm tăng 100 lần so với những dự án trước đó, mật độ sai sót là 0.02 sai sót/KLOC. [7] Căn cứ quân sự hàng không Hill đã phát triển một dự án gồm 25820 LOC. Sản phẩm hoàn thành trước thời gian là 1 tháng, chi phí gần bằng với chi phí ước lượng, việc chênh lệch trong lịch biểu giảm từ 22% xuống còn 2.7%. [7] 4.2 Trong các trường đại học Năm 1997, viện SEI tổ chức 1 khoá dạy PSP gồm 298 sinh viên (trong đó có cả kỹ sư). Quy trình huấn luyện cũng đi từ PSP0 đến PSP2. Sau khi kết thúc khoá học, Watt S.Humphrey đã thu thập được dữ liệu từ hơn 30000 chương trình viết có sử dụng PSP: 154 Hình 4.2.1 Độ chính xác trong ước lượng kích thước Trong hình trên, ở những giai đoạn đầu khi làm quen với PSP, việc ước lượng còn chưa được chính xác. Mức độ chênh lệch giữa ước lượng và thực tế còn cao. Lí do là lúc này các kỹ sư vẫn chưa có nhiều dữ liệu kích thước của chương trình cũ. Công việc ước lượng dựa chủ yếu trên sự phán đoán. Càng ở những giai đoạn về sau (cấp độ PSP sau), các kỹ sư đã có dữ liệu nên khả năng ước lượng chính xác hơn. Hình 4.2.2 Độ chính xác trong ước lượng thời gian 155 Trong hình trên, ở những qui trình PSP0, số các chương trình có phần ước lượng sai sót so với thực tế rất nhiều và sự chênh lệch cũng cao (biểu hiện bằng phần bên trái trục Kích thước nhiều hơn rất nhiều bên phải trục kích thước). Ở cấp độ PSP1, số lượng các chương trình sai sót trong dự đoán kích thước đã giảm xuống và đến cấp độ thì cả hai phần xấp xỉ gần bằng nhau. Hình 4.2.3 Số sai sót/KLOC được loại bỏ trong pha biên dịch Trong hình trên, trục X biểu thị số sai sót/KLOC, còn trục đứng (y) biểu diễn số kỹ sư báo về mật độ sai sót ở một giá trị x. Cũng tương tự như những đánh giá ở trên, về mặt tổng thể càng ở những cấp độ sau thì số sai sót/KLOC được loại bỏ trong pha biên dịch cũng giảm xuống và số kỹ sư phạm phải nhiều sai sót cũng giảm đáng kể. Hình 4.2.4 Số sai sót/KLOC được loại bỏ trong pha kiểm chứng 156 Hình 4.2.5 Chất lượng qui trình Mean Yield: hiệu suất trung bình với chương trình không sử dụng phương pháp PSP. PSP Level Yield: hiệu suất của những chương trình có sử dụng PSP. Khi không sử dụng PSP, mặc dù phần trăm số sai sót được loại bỏ trước pha biên dịch có lúc cao lúc thấp không ổn định. Còn với những chương trình có sử dụng PSP, phần trăm tăng đều và tương đối ổn định. Hình 4.2.6 Chất lượng sản phẩm Hình trên mô tả số sai sót/KLOC. Những chương trình từ 1 – 3 nằm trong cấp độ PSP0 và PSP0.1, 4 – 6 nằm trong cấp độ PSP1 và PSP1.1, từ 7 – 9 nằm trong PSP2 và 157 PSP2.1. Các chương trình còn lại là 10 – 11 nằm trong cấp độ PSP3. Như vậy ở những cấp độ đầu thì do chưa quen nên số sai sót còn nhiều. Ở những cấp độ sau, số sai sót/KLOC giảm xuống và có xu hướng đi vào ổn định. Hình 4.2.7 Hiệu suất công việc Hình trên đề cập đến hiệu suất làm việc của các kỹ sư (LOC/giờ) trong quá trình thực hiện PSP. Ở những cấp độ đầu PSP0 và PSP0.1, hiệu suất không tăng mà có vẻ ổn định. Ở những cấp độ về sau (từ 7 – 9 ), số LOC/giờ làm việc tăng và có xu hướng đi vào ổn định. Tuy nhiên, với những chương trình không sử dụng PSP, số LOC/giờ làm việc có thể cao hơn hay thấp hơn nhưng không ổn định và biến động khá nhiều. Một ví dụ khác về hiệu quả của PSP. Trong những năm 1995 và 1996, SEI đã tổ chức hai khoá dạy PSP (một khoá vào hè 1995 và khoá còn lại vào mùa đông năm 1996). Sau đó viện SEI đã phân tích để đánh giá hiệu quả của PSP. Dữ liệu phân tích được lấy từ những chương trình của 124 sinh viên trong khoá học và dữ liệu của những sinh viên này trong vòng 6 tháng sau khi kết thúc khoá học. Kết quả như sau: [8] Số sai sót/KLOC Chương trình 1,2,3 (PSP0 và PSP0.1) Số sai sót/KLOC Chương trình 8,9,10 (PSP2 và PSP2.1) % Sự cải tiến Lớp 1 93 66 29 Lớp 2 50 40 20 Tổng kết 72 52 27.7 Bảng 4.2.1 Kết quả khóa học PSP 158 Với lớp 1: Ở các chương trình đầu, số sai sót là 93, còn ở các chương trình sau, sai sót giảm xuống còn 66 => % sự cải tiến là: (93 - 66)*100%/93 = 29 % Với lớp 2: Ở các chương trình đầu, số sai sót là 50, còn ở các chương trình sau, sai sót giảm xuống còn 40 => % sự cải tiến là: (50 - 40)*100%/50 = 20 % Tổng cộng, ở các chương trình đầu, số sai sót là 72, còn ở các chương trình sau, sai sót giảm xuống còn 52 => % sự cải tiến là: (72 - 52)*100%/72 = 27.7 % 4.3 Kết quả áp dụng PSP của bản thân. 4.3.1 Hướng áp dụng Để thử nghiệm tính hiệu quả của các phương pháp luận sử dụng trong PSP, chúng tôi đã bắt tay vào ghi nhận thời gian thực hiện của việc: đọc tài liệu. Thời gian tiến hành thử nghiệm bắt đầu từ ngày 1/5/2005 và kết thúc ngày 30/6/2005. Với phần đọc tài liệu, mục tiêu của chúng tôi là: ¾ Nghiên cứu các cấp độ của PSP. ¾ Nghiên cứu phương pháp ước lượng PROBE. ¾ Nghiên cứu kết quả áp dụng PSP trong thực tiễn. Với phần đọc tài liệu, chúng tôi sử dụng biểu mẫu sau để ghi nhận thông tin: Tên: Trương thị Ngọc Phượng Ngày: Công việc # Ngày Tiến trình Ước lượng Thực tế Đến ngày Thời gian Đơn vị Thời gian Đơn vị Tốc độ Thời gian Đơn vị Tốc độ GTLN GTNN 1 Mô tả Đọc file Bảng 4.3.1 Bản ghi thời gian 4.3.2 Kết quả thu được 4.3.2.1 Phần đọc tài liệu Cuối tuần, chúng tôi thực hiện việc đánh giá. Việc đánh giá cho 1 tuần được thực hiện bắng cách tính tỉ lệ chênh lệch giữa thời gian ước lượng và thời gian thực tế. Một ví dụ về đánh giá hiệu quả cho tuần 1 (1/5/2005 đến 7/5/2005) 159 Tên: Trương thị Ngọc Phượng Ngày 1/5/2005 Công việc # Tiến trình Ước lượng Thực tế Đến ngày Thời gian Đơn vị Thời gian Đơn vị Tốc độ Thời gian Đơn vị Tốc độ GTLN GTNN Đọc tài liệu 20 25 60 25 2.4 60 25 2.4 2.4 2.4 1 Mô tả : Đọc file se_psp.pdf [9] Đọc tài liệu 12 6 30 6 5 90 31 2.9 5 2.4 2 Mô tả : Đọc file : KR.pdf [10] Đọc tài liệu 228 76 180 76 2.37 270 107 2.52 5 2.37 3 Mô tả : Đọc file Empirical Study of PSP.pdf [11] Đọc tài liệu 140 55 300 55 5.45 570 162 3.52 5.45 2.37 4 Mô tả : Đọc file 00tr022.pdf [12] Đọc tài liệu 120 34 60 34 1.76 630 196 3.21 5.45 1.76 5 Mô tả : Đọc file Tutorial Using PSP0.ppt [13] Đọc tài liệu 48 16 15 16 0.938 645 212 3.04 5.45 0.938 6 Mô tả : Đọc file Tutorial Using PSP0.1.ppt [14] Đọc tài liệu 72 24 30 24 1.25 675 236 2.86 5.45 0.938 7 Mô tả : Đọc file Tutorial Using PSP1.ppt [15] Đọc tài liệu 35 12 30 12 2.5 705 248 2.84 5.45 0.938 8 Mô tả : Đọc file Tutorial Using PSP1.1.ppt [16] Đọc tài liệu 50 18 50 18 2.78 755 266 2.84 5.45 0.938 9 Mô tả : Đọc file Tutorial Using PSP2.ppt [17] Đọc tài liệu 35 12 30 12 2.5 785 278 2.82 5.45 0.938 10 Mô tả : Đọc file Tutorial Using PSP2.1.ppt [18] Kết quả thực hiện của tuần 1 như sau: Tài liệu (Thời gian thực tế - Thời gian ước lượng)/Thời gian thực tế 1 66.67% 2 60% 3 -26.67% 4 53.33% 5 - 100% 6 - 220% 7 -140% 8 -16.67% 9 0% 10 -16.67% Bảng 4.3.2 Kết quả thực hiện trong 1 tuần 160 Độ chênh lệch ước lượng trung bình của cả tuần: (Tổng thời gian thực tế - Tổng thời gian ước lượng)/Tổng thời gian ước lượng = (785 – 760)*100%/785 = 3.18% Kết quả thực hiện sau 8 tuần thực hiện Tuần Độ chênh lệch ước lượng trung bình 1 3.18% 2 18.25% 3 2.45% 4 1.32% 5 -1.35% 6 -0.22% 7 - 0.12% 8 -0.03% Bảng 4.3.3 Kết quả thực hiện sau 8 tuần Mặc dù độ chênh lệch chưa đạt được giá trị 0% (ước lượng bằng thực tế) nhưng càng ở những tuần sau thì con số ước lượng gần đúng với thực tế hơn. Mặc dù những tỉ lệ âm không phải là tối ưu nhưng ít ra con số đó cũng phản ảnh việc chúng tôi hoàn thành công việc trước thời gian qui định. 4.4 Kết luận về việc sử dụng PSP Việc áp dụng PSP trong môi trường công nghiệp đem lại hiệu quả khá lớn. Tuy nhiên, tính đến thời điểm hiện nay thì qui trình này vẫn chưa được sử dụng rỗng rãi ở mức toàn cầu. Lý do là vì mức độ nghiêm ngặt của nó. Mặc dù PSP chỉ áp dụng trên mức độ cá nhân, nhưng việc áp dụng PSP sẽ làm thay đổi thói quen làm việc của cá nhân nên trong công nghiệp, việc huấn luyện cùng một lúc số lượng lớn các kỹ sư gặp khó khăn. Thêm vào đó, một yếu tố khác ảnh hưởng đến kết quả thực hiện PSP là mức độ phức tạp của công việc trong thực tế. Ở những khoá học dạy PSP, các kỹ sư (sinh viên) được hướng dẫn cách thực hiện PSP trên những bài tập (chương trình nhỏ). Do đó, trong các pha phân tích, lập kế hoạch, thiết kế dễ kiểm soát. Khi áp dụng vào trong công việc đòi hỏi kỹ sư phải có kinh nghiệm. Tháng 12/2000, giáo sư Alan R.Hevner kết hợp với viện SEI đã thực hiện một cuộc khảo sát đánh giá việc sử dụng PSP trong thực tế đối với các công ty và kỹ sư đã được huấn luyện PSP. Kết quả thu như sau: [6] 161 Giá trị Số dự án sử dụng PSP Trung bình 24 Khoảng chênh lệch 0 – 18 PSP được sử dụng như thế nào Chỉ những dự án quan trọng Chỉ những dự án không quan trọng Những dự án quan trọng và không quan trọng 36% 25% 39% Phần trăm dự án sử dụng PSP 0% 1% đến 25% 26% đến 50% 51% đến 75% Nhiều hơn 75% 10% 26% 13% 14% 37% Loại dự án sử dụng PSP Chỉ chứng minh khái niệm (proof of concept) Chỉ những dự án nhỏ Cả những dự án lớn và nhỏ Chỉ những dự án lớn Tất cả các dự án 31% 10% 28% 7% 24% Những pha trong dự án sử dụng PSP Pha xác định yêu cầu Pha phân tích Pha thiết kế Pha thực thi chương trình Pha kiểm chứng Pha bảo trì 32% 40% 80% 92% 65% 24% Bảng 4.4.1 Kết quả khảo sát đánh giá việc sử dụng PSP Đối với cá nhân chúng tôi, sau khi thử áp dụng thực hiện phương pháp quản lý và ước lượng thời gian của PSP, chúng tôi gặp một số khó khăn sau: Đối với phần ước lượng: Khi đọc các file pdf sử dụng font chữ lớn số lượng trang nhiều nhưng nội dung thì ít. Cũng có những file pdf, mặc dù ít trang nhưng font chữ nhỏ và nội dung có đề cập đến nhiếu vấn đế quan trọng. Do đó, con số ước lượng dựa vào công thức (số trang/phút của những tài liệu trước) * số trang của tài liệu hiện tại đôi khi cho kết quả chênh lệch rất nhiều. Đối với phần theo dõi thời gian thực hiện công việc: PSP sử dụng đơn vị là phút. Trong quá trình theo dõi, đôi khi cũng có lúc quên cập nhật dữ liệu. Đến khi nhớ ra thì lúc này con số ghi nhận chỉ ở mức độ tương đối và có thể là chênh lệch nhiều. Hơn nữa, khi sử dụng đơn vị là phút, chúng tôi thường phải nhẩm xem tương ứng với số phút đó là bao nhiêu giờ thì mới có thể hình dung được độ lớn của khoảng thời gian. 162 Thời gian đầu khi thực hiện công việc theo dõi, chúng tôi cảm thấy khó khăn. Vấn đề khó khăn ở đây không hẳn chỉ là các con số ghi nhận mà việc ghi nhận là một việc hoàn toàn mới mà trước đây chúng tôi ít dùng. Sau khoảng 2 tuần đầu, khi thực hiện đánh giá kết quả hàng tuần chúng tôi thấy hiệu quả của việc ước lượng có được cải thiện đôi chút và lúc này, việc ghi nhận bước đầu cũng đã dần dần không còn khó thực hiện như trước nữa. Tuy nhiên, cần phải thực hiện trong một khoảng thời gian ít nhất là 3 tháng thì thói quen này mới có thể hình thành được. 163 Chương 5. Ứng dụng minh họa 5.1 Giới thiệu Qui trình phần mềm cá nhân ít nhiều đã chứng minh được hiệu quả trong việc cải thiện chất lượng công việc của từng cá nhân. PSP dựa trên những nguyên lý quản lý về thời gian và sai sót một cách chi tiết và tỉ mỉ. Chính vì thế, nếu sử dụng thành thục PSP, người kỹ sư sẽ ngày càng nâng cao khả năng kiểm soát lịch biểu và công việc của mình. Với mong muốn có thể áp dụng các nguyên lý của PSP, chúng tôi dự định xây dựng một ứng dụng để hỗ trợ cá nhân quản lý công việc và cũng là để minh họa cho nghiên cứu của mình. Tuy nhiên, để phát triển một chương hoàn chỉnh theo dự định thì phải mất rất nhiều thời gian và công sức. Hơn nữa, thời gian thực hiện của một luận văn lại không cho phép. Do đó, chúng tôi chỉ viết một ứng dụng nhỏ minh họa và hỗ trợ một phần nào đó mà thôi. Cụ thể chúng tôi sẽ xây dựng một ứng dụng hỗ trợ việc lên kế hoạch dự án, ghi lại dữ liệu của việc thực hiện kế hoạch đó để làm dữ liệu lịch sử cho các ước lượng sau. Sau khi kết thúc dự án, ứng dụng sẽ đưa ra một số nhận xét về việc lên kế hoạch của cá nhân đó. Ứng dụng này được xây dựng trên Web để giúp các thành viên xây dựng dự án có thể làm việc ở bất cứ nơi đâu và dễ dàng trao đổi thông tin về dự án. Hơn nữa, sau này ứng dụng có thể được phát triển tiếp để hỗ trợ nhiều chức năng quản lý phần mềm khác trên Web. 5.2 Yêu cầu Ứng dụng được xây dựng có những yêu cầu sau: 1. Hệ thống được cài đặt ở một máy chủ trong phòng SELAB. Các thành viên trong phòng khi muốn sử dụng sẽ đăng nhập vào hệ thống. 2. Đối với các thành viên của hệ thống: a. Các user chưa có account có thể cung cấp thông tin cụ thể để đăng ký là thành viên hệ thống. b. Admin có thể tạo hàng loạt account cho các user. c. Hệ thống cho phép quản lý thông tin các thành viên thuộc phòng SELAB và một số thành viên không thuộc phòng SELAB nhưng có vai trò quan trọng trong các dự án của phòng. 164 d. Hệ thống cho phép quản lý thông tin các nhóm đang tham gia các dự án. e. Hệ thống chỉ phân 2 quyền: admin, user. f. Admin có thể tạo các các group cho các dự án và chỉ định project manager. g. Các user có thể chỉnh sửa những thông tin cá nhân thông qua hệ thống. h. Tạo mới các template thông tin cho các email gửi cho các account. 3. Đối với các dự án: a. Quyền hạn admin: - Tạo mới các project kèm theo các thông tin hỗ trợ cho việc thực hiện dự án. - Phân công việc cho các thành viên trong dự án. - Khi gặp một dự án có một số chức năng giống như những chương trình trước, admin có thề xem lại thông tin như thời gian thực tế, thời gian ước lượng đầu tiên, user thực hiện để lên kế họach cho dự án mới. - Khi bắt đầu thực hiện dự án, admin sẽ phân dự án thành các công việc nhỏ hơn và giao cho các thành viên. Admin cũng đưa ra những con số ước lượng về thời gian thực hiện cho từng công việc nhỏ. - Trong quá trình thực hiện dự án, admin có thể cập nhật lại con số ước lượng. - Khi kết thúc dự án, admin sẽ được cung cấp những thông tin: thời gian thực tế đã sử dụng cho mỗi công việc nhỏ, số lần chỉnh sửa ước lượng. Từ những đối chiếu này, người kỹ sư sẽ có cái nhìn tổng quan hơn về hiệu quả của việc ước lượng công việc của mình. Và qua đó cũng sẽ nâng dần khả năng dự đóan chính xác cho những dự án sau. - Bên cạnh đó, khi kết thúc dự án, admin có thề đưa ra các nhận xét, các ý kiến để cải tiến hơn hiệu quả qui trình. Phần này sẽ có lợi cho bản thân và là sưu liệu cho các dự án sau. b. Quyền hạn user. - Có thể xem các thông tin về dự án sẽ tham gia (không có phần phân công việc) - Xem thông tin các dự án đã tham gia, thông tin chi tiết các công việc nhỏ hơn do bản thân các kỹ sư đã phân ra để thực hiện dự án, kèm theo các thông tin về thời gian thực tế và ước lượng. - Khi nhận được công việc từ project manager, user sẽ lên danh sách các công việc nhỏ hơn để thực hiện kèm theo các con số ước lượng. Các thông tin này sẽ được ghi nhận vào hệ thống. 165 - Trong quá trình thực hiện, user có thể biết được tổng thời gian đã sử dụng cho mỗi công việc tính đền thời điểm đang xét. - Trong quá trình thực hiện, user có thể chỉnh sửa các con số ước lượng đã lưu trong hệ thống. - Khi kết thúc dự án, user sẽ được hệ thống đưa ra những con số thực tế đã sử dụng cho mỗi công việc nhỏ, số lần chỉnh sửa ước lượng. c. Ngoài ra, cả user và admin đều có thể trao đổi thắc mắc và khó khăn thông qua forum (mỗi project sẽ có một forum). 4. Đối với việc quản lý thời gian a. Các user, admin đều có thể lên lịch biểu cho các công việc hàng tuần của mình. Loại công việc gồm có 3 loại: Fixtime (những công việc bắt buộc phải thực hiện đúng giờ và thường là ít không thay đổi như ăn cơm, tham gia một lớp học trong một học kỳ…), thời gian trong một dự án nào đó, và thời gian để thực hiện các loại công việc khác (như xin visa, đám cưới ….) b. Mỗi ngày, các user, admin sẽ ghi nhận lại chi tiết thời gian sử dụng vào trong hệ thống. c. Các user, admin có thể xem lại lịch làm việc đã lên trong ngày, trong tuần, trong tháng. d. Hàng tuần, user, admin có thể xem lại bảng thổng kết quỹ thời gian dùng cho các công việc là bao nhiêu để biết được tình hình làm việc của bản thân. 5. Các chức năng khác a. Vì việc ghi nhận thời gian là liên tục trong ngày, nếu mỗi lần ghi nhận phải truy cập vào hệ thống thì tốn khá nhiều thời gian. Do đó, user, admin sẽ ghi thông tin vào một ứng dụng trên Window. Sau đó sẽ Export ra XML và import vào trong server. b. Đối với thông tin các dự án đang được thực hiện thì cũng được export từ server ra XML và import vào trong ứng dụng Window c. Ngoài ta các thành viên có thể trao đổi những tin nhắn với nhau qua hệ thống. 166 5.3 Bảng chú giải 5.3.1 Giới thiệu Tài liệu này được dùng để định nghĩa các thuật ngữ đặc thù trong lĩnh vực của bài toán, giải thích các từ ngữ có thể không quen thuộc đối với người đọc trong các mô tả use case hoặc các tài liệu khác của dự án. Thường thì tài liệu này có thể được dùng như một từ điển dữ liệu không chính thức, ghi lại các định nghĩa dữ liệu để các mô tả use case và các tài liệu khác. 5.3.2 Các định nghĩa Bảng chú giải này bao gồm các định nghĩa cho các khái niệm chính trong Hệ thống. 5.3.2.1 User Người tham gia vào hệ thống và có khả năng thực hiện một số chức năng của hệ thống. 5.3.2.2 Admin Cũng là người tham gia vào trong hệ thống. Ngoài những chức năng mà user có, admin còn có thêm một số chức năng tạo mới các account hay chấp nhận account tham gia hệ thống. 5.3.2.3 Project manager Cũng là người tham gia vào trong hệ thống. Ngoài những chức năng mà user có, project manager còn có thêm một số chức năng liên quan đến việc tạo và phân bố công việc trong các dự án cho các user. 5.3.2.4 Time recording log Bảng ghi nhận thời gian thực hiện cho các công việc. Các công việc này có thể là các công việc thuộc một dự án hay là một công việc mà người dùng cần thực hiện. 5.3.2.5 Weekly Activity Summary Bảng tổng kết hoạt động trong tuần, bao gồm danh sách các công việc đã lập kế hoạch và thời gian thực hiện được ghi nhận trong bảng Time recording log. 5.3.2.6 Task Với mỗi dự án (project), project manager sẽ phân ra thành các module nhỏ hơn và giao cho các user. Các module này được xem là các task đối với các user. 167 5.3.2.7 To do Khi user nhận được các task thì họ sẽ phân ra thành các công việc nhỏ hơn cần thực hiện để hoàn thành task. Các công việc nhỏ hơn này là To do 5.4 Thiết kế 5.4.1 Use case Manage AccountsAdmin Manage User group Project Manager New project Project : Export XML Calendar : Export XML Register Login Record time Maintain messages Summarize Weekly Activity Plan Schedule Maintain project info >> View Calendars > User View user info Import XML > Hình 5.4.1 Mô hình use case của ứng dụng 5.4.2 Đặc tả bổ sung Xem tập tin đính kèm: Baocaochinh\Dactabosung.doc 168 5.4.3 Các activity diagram chính trong ứng dụng Yeu cau dang nhap he thong Nhap Password Nhap username Xac nhan yeu cau dang nhap Thong bao nhap sai username hay password Manage Accounts Log out Hien thi form dang nhap Doc va kiem tra username & password Ghi nhan trang thai login Khong hop le Hop le Kiem tra quyen han adminDung He thongUser : User Hình 5.4.2 Activity Diagram - Các chức năng cho user 169 Hình 5.4.3 Activity Diagram - Chức năng cho admin 170 Hình 5.4.4 Activity Diagram - Chức năng cho project manager 171 5.4.4 Các sequence diagram chính trong ứng dụng 5.4.4.1 Log in : Users HomePage LoginPage UserController UserEntity 1://truy cap URL 2://hien thi login page 3://Nhap username (string) 4://Nhap password (string) 5://Chon Log in 6://KiemtraLogin(string,string) 7://Tim username va password(string,string) 8://Hien thi HomePage va ghi nhan trang thai login Hình 5.4.5 Sequence Diagram - Log in 172 5.4.4.2 View Project info User : Users HomePage ProjectPage Usercontroller UserEntity 1://Chon quan ly thong tin du an 4://Hien thi trang quan ly du an 2://Doc danh sach cac du an chua hoan thahnh co user tham gia 3://doc danh sach cac du an 5://Chon du an muon xem chi tiet 6://Lay thong tin chi tiet cua du an 7://Doc thong tin chi tiet cua du an 8://hien thi thong tin du an Hình 5.4.6 Sequence Diagram - View Project Info 173 5.4.4.3 Chình sửa thông tin dự án User : Users HomePage ProjectPage Usercontroller UserEntity MessageBox 1://Chon quan ly thong tin du an 2://Doc danh sach cac du an chua hoan thahnh co user tham gia 4://Hien thi trang quan ly du an 3://doc danh sach cac du an 5://Chon du an muon xem chi tiet 6://Lay thong tin chi tiet cua du an 7://Doc thong tin chi tiet cua du an 8://hien thi thong tin du an 9://Chinh sua thong tin du an 10://Chon Update 11://Chinh sua thong tin du an 12://Chinh sua thong tin du an 13://Hien thi thong bao chinh sua thanh cong Hình 5.4.7 Sequence Diagram - Chỉnh sửa thông tin dự án 174 5.4.4.4 Thêm mớí time record User : Users HomePage Recordtimepage Timelogcontroller TimelogEntity 1://Chon ghi nhan thoi gian 2://Xac dinh username cua nguoi dung 4://Lay danh sach time log cua nguoi dung trong ngay 3://Lay thong tin ngay 5://Doc danh sach time log trong ngay 6://hien thi danh sach time log 7://tao moi mot time record 8://kiem tra thong tin hop le 9://Ghi thong tin time record moi 10://Ghi thong tin time record moi Hình 5.4.8 Sequence Diagram - Thêm mới record 175 5.4.4.5 Chỉnh sửa thông tin time record User : Users HomePage Recordtimepag e Timelogcontroller TimelogEntity 1://Chon ghi nhan thoi gian 2://Xac dinh username cua nguoi dung 3://Lay thong tin ngay 4://Lay danh sach time log cua nguoi dung trong ngay 5://Doc danh sach time log trong ngay 6://hien thi danh sach time log 7://chon time record muon chinh sua 8://hien thi thong tin time record 11://Chinh sua thong tin time record 12://Chinh sua thong tin time record 9://Chinh sua thong tin time record 10://kiem tra thong tin chinh sua hop le Hình 5.4.9 Sequence Diagram - Chỉnh sửa thông tin time record 176 5.4.4.6 Tìm kiếm thông tin dự án User : Users HomePage ProjectPage Usercontroller UserEntity 1://Chon quan ly thong tin du an 2://Doc danh sach cac du an chua hoan thahnh co user tham gia 4://Hien thi trang quan ly du an 3://doc danh sach cac du an 5://Chon du an muon xem chi tiet 6://Lay thong tin chi tiet cua du an 7://Doc thong tin chi tiet cua du an 8://hien thi thong tin du an 9://Nhap keyword 10://Nhap loai cong viec (project, task, to do hay all) 11://tim kiem danh sach cong viec 12://Lay danh sach cong viec 13://Hien thi danh sach cong viec Hình 5.4.10 Sequence Diagram - Tìm kiếm thông tin dự án 5.4.4.7 Các sequence diagram khác: Xem tập tin đính kèm: baocaochinh\diagrams.mdl 177 5.4.5 Mô hình thực thể kết hợp Hình 5.4.11Mô hình thực thể kết hợp của ứng dụng 178 Chương 6. Một số kết luận và hướng phát triển 6.1 Kết quả đạt được: 6.1.1 Về mặt lý thuyết ¾ Tài liệu tổng hợp, phân tích PSP theo hai hướng tiếp cận: tiếp cận phương pháp luận và tiếp cận thực hiện qui trình. ¾ Trình bày và phân tích chi tiết hai phương pháp luận chính sử dụng trong PSP: o Quản lý thời gian và kế hoạch – quy trình lên kế hoạch o Quản lý chất lượng sản phẩm – quy trình quản lý sai sót ¾ Trình bày và hướng dẫn cách áp dụng PSP cho từng cá nhân. ¾ Nêu ra một số kết quả của việc áp dụng PSP vào thực tế. 6.1.2 Về mặt ứng dụng Xây dựng ứng dụng web sử dụng nguyên lý quản lý thời gian và kế hoạch của PSP để hỗ trợ: ¾ Các nhóm phát triển phần mềm lập kế hoạch thời gian cho dự án. ¾ Các cá nhân theo dõi tiến độ thực hiện công việc. ¾ Cá nhân đánh giá độ chính xác việc ước lượng của bản thân. 6.2 Hướng phát triển ¾ Phát triển thêm các chức năng quản lý sai sót. ¾ Tăng thêm tính tiện dụng cho người dùng. ¾ Xây dựng công cụ ghi nhận thời gian trên Desktop, máy Palm, PDA và các cập nhật thông tin này vào ứng dụng Web bằng cách đồng bộ các thông tin về dự án theo format XML. 179 Tài liệu tham khảo [1] Watts S. Humphrey, The Personal Software ProcessSM(PSPSM), Carnegie Mellon – Software Engineering Institute, 11/2000, pp. 17 [2] Menegos – Stavros, Process Improvement Experiment Final Report, Computer Logic S.A, 28/9/1998 [3] Stephen M. Shook, Personal Software ProcessSM & Team Software ProcessSM, Illinois State University, 03/11/2004 [4] Watts S. Humphrey, Introduction to the Personal Software ProcessSM, Addison Wesley Longman, Inc., 1999 [5] Pat Ferguson – Watts S. Humphrey – Soheil Khajenoori – Susan Macke, Results of Applying the Personal Software Process [6] Gina C. Green - Alan R. Hevner, The Successful Diffusion of Innovations: Guidance for Software Development Organizations [7] John C. Donoghue, Personal Software Process (PSP)sm, 14/12/2000 [8] Iraj Hirmanpour – Soheil Khajenoori, Personal Software Process Technology: An Experiential Report, Department of Computing and Mathematics – Embry-Riddle Aeronautical University [9] Mike Grasso, Ph.D, The Personal Software Process, University of Maryland Baltimore County [10] Elina Koivumaki Heli Rasilainen, Personal Software Process (PSP) and quality [11] Will Hayes & James W.Over, The Personal Software ProcessSM: An Empirical Study of the Impact of PSP on Individual Engineers, Carnegie Mellon University, 12/1997 [12] Watt S.Humphrey, The personal Software Process, Carnegie Mellon University, 12/2000 [13] Watt S.Humphrey, Tutorial using PSP0, Carnegie Mellon University, 2/2005 [14] Watt S.Humphrey, Tutorial using PSP0.1, Carnegie Mellon University, 2/2005 [15] Watt S.Humphrey, Tutorial using PSP1, Carnegie Mellon University, 2/2005 [16] Watt S.Humphrey, Tutorial using PSP1.1, Carnegie Mellon University, 2/2005 [17] Watt S.Humphrey, Tutorial using PSP2, Carnegie Mellon University, 2/2005 [18] Watt S.Humphrey, Tutorial using PSP2.1, Carnegie Mellon University, 2/2005