Bài giảng Quản lý dự án Phần Mềm - Thạc Bình Cường

Nội dung text: Bài giảng Quản lý dự án Phần Mềm - Thạc Bình Cường

1. TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI KHOA CÔNG NGHỆ THÔNG TIN o0o Thạc Bình Cường Bài giảng điện tử môn học QUẢN LÝ DỰ ÁN PHẦN MỀM 1
2. Lêi giíi thiÖu 1 Néi dung c¸ch viÕt cuèn s¸ch 7 Tæ chøc 7 Ch−¬ng1: Qu¶n lý phÇn mÒm cæ truyÒn 9 1.1.M« h×nh th¸c n−íc 11 1.1.1.Lý thuyÕt 11 1.1.2.Trong thùc hµnh 16 1.2. Qu¶n lý phÇn mÒm th«ng th−êng 22 Ch−¬ng 2: Sù tiÕn ho¸ nÒn kinh tÕ phÇn mÒm 26 2.1.NÒn kinh tÕ phÇn mÒm 26 2.2.Sù −íc l−îng chi phÝ phÇn mÒm thùc dông 31 Ch−¬ng 3: C¶i tiÕn kinh tÕ phÇn mÒm 36 3.1.Gi¶m kÝch th−íc s¶n phÈm phÇn mÒm 38 3.1.1.C¸c ng«n ng÷ 39 3.1.2.C¸c Ph−¬ng ph¸p h−íng ®èi t−îng vµ mÉu trùc quan 42 3.1.3.T¸i sö dông 43 3.1.4.C¸c thµnh phÇn th−¬ng m¹i 45 3.2.C¶i tiÕn c¸c tiÕn tr×nh phÇn mÒm 46 3.3.C¶i tiÕn hiÖu qu¶ nhãm lµm dù ¸n 48 3.4.C¶i tiÕn kü thuËt tù ®éng ho¸ qua c¸c m«i tr−êng phÇn mÒm 52 3.5.§¹t ®−îc yªu cÇu chÊt l−îng 55 3.6.Chó ý vµo viÖc kiÓm tra: mét quan ®iÓm thùc dông 57 Ch−¬ng 4: C¸ch cò vµ c¸ch míi 60 4.1.C¸c nguyªn t¾c cña kü thuËt phÇn mÒm truyÒn thèng 60 4.2.C¸c nguyªn t¾c qu¶n lý phÇn mÒm hiÖn ®¹i 68 4.3.ChuyÓn sang mét tiÕn tr×nh lÆp 72 Ch−¬ng 5: C¸c giai ®o¹n cña vßng ®êi 75 5.1.Giai ®o¹n c«ng nghÖ vµ giai ®o¹n s¶n xuÊt 76 5.2.Giai ®o¹n khëi ®Çu 79 5.3. Giai ®o¹n cô thÓ ho¸ 80 5.4. Giai ®o¹n x©y dùng 82 5.5. Giai ®o¹n chuyÓn tiÕp 84 Ch−¬ng 6: T¹o t¸c qui tr×nh 87 6.1.TËp mÉu 88 6.1.1.TËp ®iÒu hµnh 88 6.1.2.TËp c«ng nghÖ ( The engineering sets) 90 6.1.3.Sù tiÕn ho¸ cña qu¸ tr×nh t¹o t¸c qua vßng ®êi cña nã 95 6.1.4.T¹o t¸c kiÓm tra 97 6.2 T¹o t¸c ®iÒu hµnh 99 6.3.T¹o t¸c kü thuËt 106 6.4.T¹o t¸c trong thùc tÕ 108 2
3. Ch−¬ng 7: MÉu kiÕn tróc phÇn mÒm dùa trªn m« h×nh 111 7.1. KiÕn tróc: Tõ gãc nh×n vÒ qu¶n lý 112 7.2. KiÕn tróc: Tõ gãc nh×n kÜ thuËt 113 Ch−¬ng 8: Luång lµm viÖc cña tiÕn tr×nh 118 8.1 Luång lµm viÖc cñatiÕn tr×nh phÇn mÒm 118 8.2 Luång lÆp (Iteration workflows) 123 Ch−¬ng 9: C¸c ®iÓm kiÓm tra qu¸ tr×nh 126 9.1.C¸c cét mèc chÝnh 127 9.2.C¸c cét mèc phô 134 9.3.C¸c ®¸nh gi¸ t×nh tr¹ng ®Þnh k× 135 Ch−¬ng 10: LËp kÕ ho¹ch tiÕn tr×nh lÆp 138 10.1. Ph©n ®Þnh c¬ cÊu c¸c c«ng viÖc chi tiÕt 139 10.1.1.KÕt qu¶ cña WBS theo quy −íc 139 10.1.2.ViÖc ph©n ®Þnh c¬ cÊu c«ng viÖc chi tiÕt hiÖn ®¹i 142 10.2.C¸c nguyªn t¾c lËp kÕ ho¹ch 147 10.3.Qu¸ tr×nh −íc tÝnh vÒ chi phÝ vµ lÞch tr×nh cña dù ¸n 150 10.4.Qu¸ tr×nh x©y dùng kÕ ho¹ch lÆp, kÐo dµi vßng chu kú cña dù ¸n 151 10.5 Thùc hiÖn kÕ ho¹ch 154 Ch−¬ng 11: Tæ chøc vµ chÞu tr¸ch nhiÖm dù ¸n 156 11.1.Tæ chøc ngµnh kinh doanh 156 11.2.Tæ chøc dù ¸n 159 11.3.TiÕn triÓn cña c¸c tæ chøc 167 Ch−¬ng 12: Tù ®éng ho¸ qu¸ tr×nh 168 12.1.C¸c c«ng cô 169 12.2.M«i tr−êng dù ¸n 173 12.2.1.Kü thuËt trän vßng(round-trip engineering) 174 12.2.2.Qu¶n lý sù thay ®æi(change management) 175 12.2.3.C¬ së h¹ tÇng 182 Ch−¬ng 13: KiÓm so¸t dù ¸n vµ C«ng cô xö lý 188 13.1.B¶y metrics c¬ b¶n 189 13.2.BiÓu thÞ qu¶n lý 192 13.2.1.C«ng viÖc vµ tiÕn ®é 193 13.2.2.Gi¸ dù to¸n vµ chi phÝ 193 13.2.3.Bè trÝ nh©n viªn vµ nhãm ®éng 197 13.3.BiÓu thÞ chÊt l−îng 198 13.3.1.L−u l−îng thay ®æi vµ tÝnh æn ®Þnh 199 13.3.2.Chia nhá vµ tÝnh modul ho¸ 199 13.3.3.Lµm l¹i vµ tÝnh t−¬ng thÝch 199 13.3.4 MTBF vµ tÝnh thµnh thôc 200 13.4.C¸c dù tÝnh vßng ®êi 202 13.5.C¸c metric phÇn mÒm thùc dông 203 3
4. 13.6.Metric tù ®éng ho¸ 205 Ch−¬ng 14: Sù biÕn ®æi tiÕn tr×nh - tailoring the process 211 14.1. Ph©n biÖt c¸c tiÕn tr×nh 211 14.1.1.Qui m« 213 14.1.2.Liªn kÕt hoÆc c¹nh tranh 216 14.1.3.TiÕn tr×nh mÒm dÎo hay kh«ng mÒm dÎo 218 14.1.4.Sù thuÇn thôc tiÕn tr×nh 219 14.1.5.Rñi ro kiÕn tróc 220 14.1.6.Kinh nghiÖm trong lÜnh vùc 221 14.2.VÝ dô vÒ dù ¸n qui m« nhá chèng l¹i dù ¸n qui m« lín 222 Chương 15: Những sơ thảo về dự án tiên tiến 225 15.1.Tích hợp liên tục 226 15.2.Giải quyết sớm những rủi ro 227 15.3.Những yêu cầu phát triển 229 15.4.Sự hợp tác giữa các cổ đông 229 15.5.10 Nguyên tắc quản lý phần mềm tốt nhất 230 15.6.Những ứng dụng thực tiễn tốt nhất của quản lý phần mềm 231 Ch−¬ng 16: ThÕ hÖ tiÕp theo cña qu¶n lý kinh tÕ phÇn mÒm 234 16.1.M« h×nh ®Þnh gi¸ thÕ hÖ tiÕp theo 234 16.2. Kinh tÕ häc phÇn mÒm thÕ hÖ tiÕp theo 239 Ch−¬ng 17: Sù qu¸ ®é sang xö lÝ hiÖn ®¹i 242 17.1.Sù qu¸ ®é xÐt ë khÝa c¹nh v¨n ho¸ 242 17.2.§o¹n kÕt 246 4
5. Lời giới thiệu Cuốn sách này trình bày cách tiếp cận tới những thế hệ thực hành về quản lý phần mềm. Rất nhiều tổ chức vẫn bám vào mô hình thác nước, thậm chí nó không được hoàn thiện lắm nhưng nó đưa ra được một hướng dẫn quản lý khá tỉ mỉ, cách để tiến hành để xử lý các tình trạng phần mềm đưa ra. Trên thực tế khó đưa ra được một cách tiếp cận quản lý đầy đủ thích hợp với những vấn đề như là các vấn đề về tích hợp các thành phần thương mại, tái sử dụng phần mềm, quản lý rủi ro và các tiến trình phần mềm tăng trưởng xoáy chôn ốc. Cuốn sách này cung cấp một khung kiểm tra bằng các kinh nghiệm và tập các hướng dẫn để xử lý nó như thế nào? Ông Walker Royce đã phát triển và kiểm tra cách tiếp cận quản lý phần mềm trong quá trình tham gia từ khảo sát sơ bộ đến phân phối sản phẩm phần mềm cho không lực của Mỹ. Nền công nghiệp phần mềm đã hướng tới một phương pháp mới để quản lý độ phức tạp không ngừng tăng nhanh của các dự án phần mềm. Trước đây chúng ta đã từng thấy cuộc cách mạng, cuộc biến đổi và những vấn đề đang diễn ra kể cả thành công và thất bại. Trong khi những công nghệ các tiến trình và các phương pháp phần mềm đang phát triển một cách nhanh chóng thì kỹ nghệ phần mềm vẫn còn là một quá trình đòi hỏi sự nghiên cứu sâu sắc của con người. Tài liệu này sẽ đề cập đến các nhận thức tổng quan về quản lý phần mềm và nhấn mạnh một cách nhìn cân đối những yếu tố sau: ƒ Lý thuyết và thực tiễn. ƒ Kỹ thuật của con người. ƒ Yêu cầu giá trị của khách hàng và lợi ích của nhà cung cấp. ƒ Chiến lược và sách lược. Mặc dù vậy bạn cũng nên quan tâm đến một vấn đề quản lý quan trọng đó là sự điều chỉnh cân đối. Điều đặc biệt quan trọng là đạt tới các mục tiêu của các cổ đông khác nhau, người mà có giao tiếp với những người khác bằng những ngôn ngữ và các ký hiệu khác nhau. Đây là sự thúc đẩy những nhà sáng lập, một sự mô tả trừu tượng của hòn đá Rosetta. Ba ngôn ngữ biểu diễn cơ bản vốn có trong công nghệ phần mềm là với các yêu cầu (ngôn ngữ của không gian vấn đề), với thiết kế (ngôn ngữ chuyển dịch của kỹ sư phần mềm) và với cài đặt (ngôn ngữ thực hiện không gian vấn đề trên máy tính). Chỉ có những mốc như là những hòn đá Rosetta mới có thể chuyển dịch được các ký tự Hy Lạp, các kỹ thuật phần mềm có thể chuyển dịch những vấn đề thành các giải pháp mà nó thoả mãn tất cả các cổ đông. Không có một cuốn sách chế biến nào cho quản lý phần mềm. Không có một công thức làm món ăn nào cho một thực tiễn rõ ràng. Tôi sẽ cố gắng tiếp cận đến các vấn đề một cách 5
6. khoa học hiện thực và kinh nghiệm nhất, nhưng việc quản lý là một vấn đề rất rộng trong việc đánh giá theo một nghĩa chung và quyết định phụ thuộc vào tình huống. Đó là điều tại sao mà các nhà quản lý được động viên. Một vài chương bao gồm những phần thực dụng và thường được xử lý chặt chẽ trong các chủ đề cụ thể. Để phân biệt thế giới thực với các mô hình xử lý chung: các kỹ thuật và nguyên lý, thì phần đầu của mỗi một chương có từ thực dụng (pragmatic). Bởi nghĩa thực dụng có nghĩa là không có sự ảo tưởng và về mặt thực tiễn, nó là chính xác về ý nghĩa của những phần này. Chúng sẽ bao gồm những ý kiến mạnh và những vị trí khiêu khích và nó sẽ làm cho thần kinh của độc giả, những người bảo thủ trong một số thực hành, công cụ hoặc kỹ thuật lỗi thời hay quá hạn. Tôi sẽ cố gắng để phân biệt trong các kỹ thuật đưa ra, những cách tiếp cận mới và những kỹ thuật lỗi thời bằng cách sử dụng những cách chứng minh phù hợp. Trong hầu hết các trường hợp tôi ủng hộ những quan điểm với những lí lẽ kinh tế đơn giản và nghĩa chung cùng với những kinh nghiệm vặt từ những ứng dụng. Rất nhiều những tư liệu giả thuyết đã rút ra từ cách quản lý những dự án thành công trên 10 năm qua (những vấn đề của thực tiễn). Mặt khác một số những tư liệu trình bày những vấn đề đã được chứng minh (những vấn đề của nghệ thuật), những cách tiếp cận về giả thuyết mà không có việc chứng minh rõ ràng trong thực tiễn. Chúng ta phải đấu tranh với một quan điểm của cuốn sách này được coi là giáo dục về quản lý hay là đào tạo về quản lý. Việc phân biệt này dường như là sự bới lông tìm vết nhưng nó rất quan trọng, một ví dụ là chúng ta hãy nghe việc minh hoạ sự khác nhau 15 năm trước đây. Giả sử rằng một bé gái của bạn từ trường về nhà vào một ngày nào đó và hỏi: "Thưa cha mẹ! Con có thể tham dự một khoá học về giáo dục giới tính ở trường được không?". Phản ứng của bạn hẳn là sẽ khác nếu như bé gái hỏi: " Con có thể tham dự một khoá huấn luyện về giới tính ở trường được không? " (điều này có nghĩa phần nào giúp tôi hiểu rằng con gái đã trưỏng thành). Quá trình đào tạo huấn luyện có một khía cạnh về tri thức ứng dụng mà làm cho tri thức hữu ích hoặc kém hữu ích hơn ngay lập tức. Mặt khác giáo dục là tập trung về việc giảng dạy các nguyên lý dựa vào kinh nghiệm và tinh thần của các mục tiêu với việc ứng dụng của những tri thức này dành cho người học. Tôi cố gắng để tập trung vào cuốn sách này như là một sự chuyển tải giáo dục quản lý. (Tôi không chắc chắn một điều rằng việc đào tạo quản lý khác với kinh nghiệm vừa học vừa làm). Tôi sẽ không ngụy biện rằng lời khuyên của tôi là có thể áp dụng được trực tiếp trên mọi dự án. Mặc dù tôi đã cố gắng chứng minh các quan điểm nếu có thể được, một số quan điểm sẽ không được chứng minh vì nó chỉ thuần tuý là giả thuyết. Tôi hy vọng rằng sự phỏng đoán và lời khuyên của tôi sẽ khuyến khích các cuộc tranh luận và sự tiến triển sau này. Các bạn đọc của tôi đang thực hiện một bản gam (gamut) những thực hành chuyên môn về phần mềm. Các đọc giả chính là những người ra quyết định: những người có trách nhiệm đầu tư và chi phí về ngân sách phần mềm. Nhóm này bao gồm các nhà quản lý về tổ chức, những nhà quản lý về dự án, những nhân viên yêu cầu phần mềm và cán bộ của họ. Đối 6
7. với đọc giả này tôi sẽ cố gắng đưa ra các hướng dẫn có thể ứng dụng được trực tiếp đối với việc sử dụng các quyết định thực tế ngày nay và đầu tư chiến lược trong tương lai. Một loại đọc giả quan trọng khác là những người thực hành phần mềm mà họ thoả thuận và thực hiện kế hoạch, triển khai phần mềm trên những mục tiêu dự án và tổ chức. Nội dung cách viết cuốn sách Bởi vì tôi viết cho lượng lớn độc giả nên tôi đã không đi sâu vào chi tiết kỹ thuật hoặc những nguyên lý kỹ thuật, những vấn đề này được trình bày tốt hơn trong những cuốn sách khác. Thay vào đó tôi đưa ra một cách bàn luận khá sâu sắc về kinh tế, về mẫu quản lý, về những chiến lược phân chia công việc, về chiến lược tổ chức, những độ đo; đó là những điều cần thiết để xây dựng kế hoạch và thực hiện thành công một dự án phần mềm. Có nhiều minh hoạ sẽ làm cho những chủ đề phức tạp trở nên dễ hiểu hơn. Sự chính xác và đúng đắn của các hình vẽ và các bảng là sự minh hoạ tốt nhất. Trong khi hầu hết các dữ liệu số mô tả chính xác một số khái niệm, xu hướng, kỳ vọng hoặc các quan hệ, thì các cách thức trình bày mang tính không chính xác vì mục đích. Trong khung cảnh quản lý phần mềm sự khác biệt giữa tính chính xác và tính đúng đắn là không đáng kể vì có thể từ hai lý do: 1. Quản lý phần mềm là những vùng đầy màu xám, nó phụ thuộc vào tình trạng và những trả giá nhập nhằng. Đó là sự khó khăn nếu không muốn nói là không thể chứng minh tính đúng đắn của nhiều khái niệm và giữ lại sự chính xác của cách trình bày trong một lĩnh vực rộng lớn. 2. Hiểu được sự khác nhau giữa chính xác và đúng đắn là kỹ năng cơ bản của những nhà quản lý phần mềm giỏi, người phải dự đoán một cách đúng đắn những ước lượng rủi ro và những ảnh hưởng của sự thay đổi. Độ chính xác không hiệu chỉnh trong các yêu cầu hoặc kế hoạch đã được chứng minh dù chưa rõ ràng, nhưng nó thường gây trở ngại tới thành công của dự án. Trong rất nhiều cách biểu diễn số, các giá trị tuyệt đối thường là không quan trọng và hoàn toàn thay đổi trong các lĩnh vực và các tình huống dự án khác nhau. Các giá trị quan hệ của nó tạo nên hầu hết các hình vẽ và bảng biểu. Nhân tiện tôi đưa ra những chứng cứ và kinh nghiệm thực tế để các nhà quản lý hướng tới những ngữ cảnh cụ thể, và liên hệ với những tiêu chuẩn đúng đắn và chính xác trong các điều kiện cụ thể. Một số phần phụ lục sẽ làm sáng tỏ các kỹ thuật được trình bày ở đây có thể đã được ứng dụng trên thực tế như thế nào. Một thí về hệ thống tàu đô đốc sẽ được nghiên cứu xuyên suốt trong tài liệu, đây là một dự án lớn và thành công, đã đưa ra một ví dụ cụ thể là làm thế nào có thể quản lý tốt được công việc. Nó cũng cung cấp một một khuôn khổ để hợp lý hoá một số tiến trình cải tiến và kỹ thuật. Tổ chức Cuốn sách được chia thành 5 phần , mỗi phần gồm một số chương: 7
8. Phần I, thời kỳ phục hưng của quản lý phần mềm. Phần này mô tả hiện trạng của nền kinh tế phần mềm và thực tiễn quản lý phần mềm và đưa ra sự chuyển dịch cần thiết đối với phần mềm được cải thiện về đầu tư. Phần II, những khuôn khổ của quản lý phần mềm. Mô tả các nguyên lý về xử lý và khuôn khổ cho việc quản lý phần mềm tiên tiến bao gồm : các pha về vòng đời, pha về chế tạo thử, pha về dòng công việc, và các điểm kiểm tra. Phần III, nguyên lý quản lý phần mềm. Phần này tóm tắt một vài kỹ thuật áp dụng cho lập kế hoạch, điều khiển và tự động hoá một quá trình phần mềm tiên tiến. Phần IV, xu hướng phát triển. Các giả thuyết về các hiệu năng của dự án tiên tiến và nền kinh tế phần mềm trong thế hệ tới và bàn luận về sự dịch chuyển văn hoá cần thiết cho sự thành công. Phần V, các ví dụ cụ thể và tài liệu tham khảo. Gồm 5 phụ lục, đưa ra những cái cơ bản cho việc chứng minh một vài nhận xét, chỉ dẫn và ý kiến được trình bày ở một vài nơi. 8
9. Chương 1 Quản lý phần mềm cổ truyền Thời kì phục hưng của quản lý phần mềm Nền công nghiệp phần mềm đã có một kinh nghiệm trong thời kì phục hưng. Rất nhiều những nguyên lý công nghệ phần mềm đã hằn sâu đang bị bó hẹp và lỗi thời bởi những kỹ thuật mới hoặc thay thế bằng những kỹ thuật tốt hơn hoặc mức độ tự động hoá cao hơn. Cho dù nguyên lý nào đi chăng nữa thì điều quan trọng là người làm thực tế phải hiểu được trạng thái hiện tại trước khi biến đổi, chuyển dịch sang cái mới. Trước khi cân nhắc một khuôn khổ quản lý phần mềm cho tương lai thì cần thiết phải hiểu nền công nghiệp hiện nay đang ở đâu và làm sao có thể chiếm lĩnh được nó. Trong 10 năm đã qua tôi đã tham gia và đóng góp để cải tiến các quá trình phần mềm của trên 500 công ty. Mục tiêu cụ thể của các đóng góp này là đạt được 2X, 3X, hoặc 10X tăng lên về năng suất, chất lượng, thời gian đối với thị trường hoặc tổ hợp của cả 3 điều trên. ở đây X là tương ứng với độ tốt lên của công ty đó giờ đây như thế nào. Một điều hài hước rằng rất nhiều các tổ chức này không có ý tưởng X là cái gì theo nghĩa mục tiêu. Những chương trong phần I giới thiệu trạng thái thực tế trong nền công nghiệp phần mềm và xác định X trong các tiến trình quản lý phần mềm thông thường. 9
10. Điểm chính : ¾ Những thực tiễn quản lý phần mềm cổ truyền dường như chỉ là lý thuyết nhưng thực tiễn vẫn còn gắn chặt với công nghệ và kỹ thuật cổ xưa. ¾ Nền kinh tế phần mềm cổ truyền đưa ra những tiêu chuẩn về hiệu suất của các nguyên lý quản lý phần mềm cổ truyền. Một điều tốt nhất về phần mềm đó là tính linh hoạt mềm dẻo: Nó có thể được lập trình để thực hiện hầu hết mọi việc. Điều tồi nhất về phần mềm cũng là tính linh hoạt mềm dẻo: các đặc tính "hầu như mọi thứ" rất khó trong lập kế hoạch, tiến độ và điều khiển sự phát triển phần mềm. Việc không dự đoán này là điều cơ bản của cuộc ''khủng hoảng phần mềm'' trên 30 năm nay. Vào giữa những năm 1990 ít nhất có 3 phân tích quan trọng về nền công nghiệp kỹ nghệ phần mềm được thực hiện kết quả được công bố trong các ấn phẩm 1. Patterns of Software Systems Failure and Success (Jones, 1996). 2. Chaos (Standish Group , 1995). 3. Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially (Defense Science Board, 1994). Phụ lục A làm nổi bật một và kết quả có liên quan. Tất cả 3 phân tích đó cùng đạt tới một kết luận chung: Mức độ thành công đối với dự án phần mềm là rất thấp. Mặc dù các phân tích này có một vài nhận thức khác nhau nhưng thông báo chủ yếu của họ được bổ sung cho nhau và rất kiên định. Chúng ta có thể tóm tắt như sau: 1. Việc phát triển phần mềm vẫn là cái không dự đoán được rất cao chỉ có khoảng 10% các dự án phần mềm được coi là thành công, với những ước lượng về ngân sách và tiến độ ban đầu. 2. Các nguyên lý về quản lý nặng về phán đoán thành công hay thất bại hơn là các tiến bộ về kỹ thuật. 3. Mức độ manh mún của phần mềm cũng như sự không kế thừa đã chỉ ra một tiến trình còn non nớt Ba phân tích này đã giới thiệu cách quản lý các phần mềm và những tiêu chuẩn hiện tại đối với quá trình quản lý phần mềm cổ truyền. Có rất nhiều mảnh đất để phát triển. Hãy nhớ những tóm tắt của các chương về khung tiến trình quản lý phần mềm mà hầu hết những phần mềm truyền thống đã được sử dụng. Trong khi những khuôn khổ mà chúng ta đã biết là mô hình thác nước có rất nhiều sự biến động đó là tiến trình vạch danh giới đối với hầu hết những kinh nghiệm của dự án phần mềm đã được tích luỹ cho tới ngày nay. Và trong 10
11. khi sự lo ngại đang phát sinh thì điều quan trọng được đặt ra là môi trường tốt cho các kỹ thuật cải tiến tiến trình sẽ được thảo luận trong suốt cuốn sách này. 1.1.Mô hình thác nước Hầu hết nội dung công nghệ phần mềm trình bày theo mô hình thác nước coi như là nguồn gốc của tiến trình phần mềm truyền thống. Chú ý rằng nó sẽ là tiêu chuẩn hơn quá trình đó. Phần này sẽ xem xét và đánh giá mô hình thác nước, sau đó xem nền công nghiệp đã được thực hành tiến trình phần mềm truyền thống như thế nào? Trên thực tế mặc dù nền công nghiệp này đã bỏ qua rất nhiều phần lý thuyết, nó vẫn còn được quản lý để mở ra nhiều thực hành tốt (và một vài thực tiễn không tốt lắm) đặc biệt khi nó sử dụng các kỹ thuật tiên tiến. 1.1.1. Lý thuyết Vào năm 1970 cha tôi ông Winston Royce đã đưa ra một bài báo với tiêu đề " Quản lý việc phát triển hệ thống phần mềm lớn" trên tạp chí IEEE WESCON (Royce, Winston, 1970) bài báo này dựa và các bài giảng về quản lý các dự án phần mềm lớn mà nó còn giữ lại gốc của mô hình thác nước. Nó đã đưa ra một tóm tắt ngắn gọn và sáng sủa về tính triết học của quản lý phần mềm truyền thống trong khoảng những năm 1970 và hầu như những lời khuyên trong 30 năm qua đã được thời gian kiểm nghiệm trước tốc độ thay đổi của công nghệ. Bài báo này đã đưa ra 3 luận điểm quan trọng (Phần để trong dấu nháy và các đoạn được in nghiêng). 1. Có hai bước cần thiết để phát triển một chương trình máy tính: phân tích và lập trình. 2. Để quản lý và điều khiển tất cả những sự tự do sáng tạo với phát triển phần mềm người ta sẽ giới thiệu một vài bước "ở phía trước (overhead)" , gồm xác định các yêu cầu của hệ thống, xác định yêu cầu phần mềm, thiết kế chương trình và kiểm sửa. Những bước này bổ sung cho các bước phân tích và lập trình. Hình 1.1 sẽ minh hoạ sơ thảo dự án đưa ra và những bước cơ bản trong việc phát triển một chương trình quy mô lớn. 3. Khuôn khổ cơ bản đã mô tả trong mô hình thác nước sẽ có những rủi ro và những sai sót. Giai đoạn kiểm thử xuất hiện tại cuối của vòng phát triển mà đầu tiên là thời gian, bộ nhớ, truyền vào ra là những kinh nghiệm khi phân biệt từ bước phân tích. Sự thay đổi của các thiết kế đưa ra hầu như nó sẽ phá vỡ tất cả các yêu cầu phần mềm khi mà việc thiết kế dựa vào các yêu cầu bị phá huỷ. Hoặc là các yêu cầu này phải thay đổi hoặc phần thay đổi thiết kế trọng yếu phải được bảo hành. Phần 1 của mô hình thác nước: Hai bước cơ bản để xây dựng một chương trình. 11
12. Ph©n tÝch vµ lËp tr×nh sÏ Ph©n tÝch bao gåm c¸c c«ng viÖc s¸ng t¹o mµ nã ®ãng gãp trùc tiÕp tíi tÝnh h÷u dông cña s¶n phÈm. LËp tr×nh Phần 2 của mô hình thác nước: Cách tiếp cận của hệ thống lớn Yªu cÇu hÖ thèng Yªu cÇu phÇn mÒm Ph©n tÝch ThiÕt kÕ ch−¬ng LËp tr×nh KiÓm söa Thùc hiÖn Phần 3 của mô hình thác nước: Năm sự cải tiến cần thiết để tiếp cận công việc. 1. Hoàn thiện thiết kế chương trình trước khi phân tích và viết chương trình. 2. Bảo trì hiện hành và hoàn thiện tài liệu. 3. Thực hiện công việc hai lần nếu có thể. 4. Lập kế hoạch, điều khiển và điều hành kiểm sửa. 5. Trao đổi và thu hút khách hàng. Hình 1-1. Mô hình thác nước Mục 1, dường như quan trọng, sau này nó sẽ được mở rộng thành một trong những chủ đề quản lý toàn bộ : Sự phân chia giai đoạn công nghệ từ giai đoạn sản phẩm. Bẩy trong chín trang của bài báo để dành cho mô tả 5 bước phát triển tiến trình thác nước cơ bản mà nó sẽ loại bỏ đi hầu hết những rủi ro được nói đến trong mục 3. Năm sự cải 12
13. tiến được trình bày tiếp sau. (Phần để trong dấu nháy và những đoạn được in nghiêng, kèm theo đó là những nhận xét của tôi về những công nghệ và thuật ngữ ngày nay). 1. Đầu tiên là giai đoạn thiết kế chương trình. Việc đầu tiên để giải quyết vấn đề là bổ sung một thiết kế chương trình sơ bộ vào giữa giai đoạn xác định yêu cầu phần mềm và giai đoạn phân tích. Bằng kỹ thuật này, các nhà thiết kế chương trình qủa quyết rằng phần mềm sẽ không bị sai vì bộ nhớ, thời gian, và sự thay đổi dữ liệu. Khi phân tích được tiến hành trong giai đoạn tiếp theo thì người thiết kế chương trình phải tác động với các nhà phân tích các hạn chế về bộ nhớ, thời gian và tác nghiệp theo cách mà anh ta cảm nhận thấy. Nếu như tất cả các nguồn tài nguyên sẽ dùng đến không đủ đáp ứng hoặc những thiết kế về tác nghiệp bị sai sót thì nó sẽ được phát hiện tại trạng thái sớm hơn và việc lặp lại các yêu cầu và thiết kế sơ bộ có thể được lặp lại trước khi thiết kế, lập trình và kiểm sửa. Làm thế nào để thủ tục thiết kế chương trình được thực hiện. Nó đòi hỏi các bước sau đây: Bắt đầu quá trình thiết kế với các nhà thiết kế không phải các nhà phân tích hoặc các nhà lập trình. Thiết kế , định nghĩa và xác định chế độ xử lý dữ liệu thậm chí cả các rủi ro. Chỉ định các chức năng xử lý, thiết kế cơ sở dữ liệu xác định thời gian thực hiện, xác định giao diện và chế độ xử lý với hệ điều hành, mô tả quá trình xử lý vào ra và xác định các thủ tục thao tác sơ bộ. Viết một tài liệu tổng quan rễ đọc, dễ hiểu , đầy đủ thông tin và mang tính thời sự để cho mọi người tham gia dự án có thể nắm bắt được những nét cơ bản về hệ thống. ¾ Bản chất của quá trình xử lý mà tôi trình bày trong những chương sau là sự phát triển đầu tiên về kiến trúc. Mặc dù một vài thuật ngữ có thể thay đổi (chẳng hạn như từ kiến trúc có thể được thay thế bằng thiết kế chương trình), nhưng bản chất của các quá trình tiên tiến luôn phù hợp với việc giải thích đưa ra ở đây. Như sự mô tả sau này thì kiến trúc sẽ được làm trước, và nó sẽ được thiết kế và phát triển song song với việc lập kế hoạch và xác định yêu cầu như là một bộ phận của một giai đoạn công nghệ trong một dự án. 2. Lập tài liệu thiết kế. Toàn bộ số tài liệu yêu cầu về những chương trình phần mềm là rất lớn, chắc chắn nó phải nhiều hơn những tài liệu do những người lập trình, những người phân tích hoặc những người thiết kế chương trình đưa ra. Tại sao chúng ta phải làm nhiều tài liệu như vậy? (1).Mỗi một người thiết kế phải trao đổi với những nhà thiết kế khác, những nhà quản lý và thậm trí với cả những khách hàng.(2). Ngay trong những giai đoạn ban đầu thì tài liệu cũng là một thiết kế. (3). Giá trị bằng tiền thực tế của các tài liệu cũng hỗ trợ việc sửa đổi sau này do một nhóm kiểm sửa độc lập, do một nhóm bảo trì độc lập và do những cá nhân không có kiến thức về phần mềm thực hiện. 13
14. ¾ Nếu như chúng ta lờ bỏ đi sự thiếu hụt không tương thích về kỹ thuật trong một khung thời gian mà tài liệu được viết thì thực chất thông điệp của "lập tài liệu cho thiết kế " vẫn còn giá trị. Việc trình bày một cách dễ hiểu các khuôn mẫu mà các cổ đông và các nhóm có thể truy xuất được là điều cốt yếu. Tuy nhiên ưu điểm chính trong các ký hiệu, ngôn ngữ, cách duyệt, công cụ và phương pháp đã đáp lại những yêu cầu đối với những sự lạc hậu về tài liệu. Trong chương sau , tôi chỉ rõ ràng rằng nếu tập trung quá nhiều về tài liệu thì sẽ không tốt và phản tác dụng. Bởi vì các công nghệ hiện nay dã hỗ trợ cho cách biểu diễn những ký hiệu của tài liệu rất chính xác để xác định yêu cầu, thiết kế và thể hiện. 3. Làm hai lần. Nếu như một chương trình máy tính được phát triển lần đầu tiên thì việc chỉnh lý làm ra phiên bản cuối cùng cấp phát cho khách hàng để triển khai thực hiện thực sự là phiên bản thứ hai mà đã được đánh giá và thực hiện. Chú ý rằng đây là một sự đơn giản của toàn bộ quá trình được thực hiện thu nhỏ lại, về mặt thời gian điều này là rất nhỏ theo khía cạnh của toàn bộ sự nỗ lực. Trong phiên bản đầu tiên, toàn đội phải có một nỗ lực đặt biệt mà họ có thể nhanh chóng cảm nhận được các điểm trục trặc trong thiết kế, trong mô hình, sự lựa chọn mô hình, quên đi những khía cạnh trực diện của thiết kế mà không có giá trị nghiên cứu tại điểm khởi đầu và cuối cùng thu được một chương trình không còn lỗi nữa. ¾ Đây là một cách mô tả súc tích và ngắn gọn sự phát triển kiến trúc đầu tiên, mà trong đó nhóm kiến trúc phải chịu trách nhiệm về những công nghệ ban đầu. Bằng cách tạo ra một thực tiễn, mà sau này tôi sẽ làm, đưa ra một cách tiếp cận "làm N lần", đó là nguyên tắc cơ bản của sự phát triển lặp tiên tiến ngày nay. Người quản lý dự án phải có óc phán đoán nếu không có giai đoạn đầu tiên này. Với một bước mô phỏng đầu tiên, ở mức kiểm sửa kinh nghiệm về các giả thiết và các phạm vi những cái mà do con người phán đoán trong các lĩnh vực thiết kế chương trình máy tính (như là việc ước lượng về trọng số nhại lại, chi phí hoàn thành hoặc những gấp bội hàng ngày ) là những cái thường xảy ra và cái tối ưu trầm trọng. ¾ Đây là sự mô tả rất quan trọng trên tinh thần của sự phát triển tuần hoàn và những thuận lợi cố hữu cho quản lý rủi ro. 4. Lập kế hoạch, điều khiển và kiểm tra chất lượng. Không có đòi hỏi, người dùng lớn nhất của nguồn nhân lực của dự án, thời gian (xử lý) máy tính và /hoặc đánh giá quản lý là pha kiểm tra. Đây là pha rủi ro lớn nhất trong kì giá trị và lập lịch, khi cách lưu trữ lại là giá trị tối thiểu sẵn có, nếu trong mọi trường hợp. Ba điều giới thiệu trước đây tất cả tập trung vào việc khám phá và giải quyết các vấn đề trước khi đi vào pha kiểm tra. Tuy nhiên, thậm chí sau khi được thực hiện những điều đó, vẫn còn pha kiểm tra và vẫn có nhiều điều quan trọng cần được làm, bao gồm: (1) việc làm của đội ngũ kiểm tra những người mà không chịu trách nhiệm về thiết kế ban đầu; (2) công việc 14
15. kiểm định trực quan để đánh dấu những lỗi rõ ràng như là rơi xuống dấu âm, thiếu hai nhân tố, nhảy tới các địa chỉ sai sót ( không sử dụng máy tính để dò tìm lỗi này, nó quá đắt ); (3) kiểm tra các đường dẫn logic; (4) công việc kiểm tra cuối cùng trên các máy đích. ¾ ở đây chúng ta có vài lời khuyên tốt và một vài lời khuyên lỗi thời, các mục 1 và 4 vẫn là những lời khuyên tốt, nó được thảo luận kỹ lưỡng trong các chương sau. Mục 2 vẫn chắc chắn là một cách thích thú kì cục phổ biến ( sử dụng các phần mềm kiểm tra), nhưng mục đích của nó như đẫ trình bày ở đây hầu như đã lỗi thời. Mặc dù có thể nó đã là một sản phẩm có giá trị hiệu quả thực hiện trong kỹ thuật của những năm 70, nhưng nó không phù hợp với ngày nay. Các máy tính, các bộ diễn dịch , bộ phân tích và những công cụ khác đã là những máy móc có hiệu suất cao hơn để bắt kịp các lỗi rõ ràng. Như ở mục 3, việc kiểm tra các đường dẫn logic rất khó đầy đủ trong những năm 70, nếu không có việc thêm vào các phần tử phân phối phức tạp, các phần tử dùng lại được và một vài nhân tố phức tạp khác. Nó chắc chắn không khả thi với hầu hết các hệ thống ngày nay. Đây là điều đặc biệt đúng với các phân phối việc tính toán, trong đó, với thời gian như một hướng thêm vào, đó là một số vô tận những đường dẫn logic. Trong một xử lý tiên tiến, việc kiểm tra là một vòng đời hoạt động khi mà việc thực hiện đúng đắn các yêu cầu ít hơn tổng số tài nguyên và những khám phá phát hiện ra còn dễ dàng hơn trong vòng đời , khi lưu trữ lại vẫn có thể được sử dụng. 5. Thu hút khách hàng. Có một vài lý do, một thiết kế phần mềm nào đó sẽ được làm là một chủ đề được diễn giải rộng rãi, thậm chí sau cả hợp đồng trước đó. Đó là điều quan trọng để thu hút khách hàng trong một cách thức hình thức vì vậy khách hàng đã chuển giao lại cho chính họ những điểm dễ hơn trước khi giao hàng cuối cùng. Có ba điểm sau đây, các yêu cầu được định nghĩa là sự hiểu thấu bên trong sự vật (insight), sự phán đoán và sự tận tình (commitment) của khách hàng có thể ủng hộ sự nỗ lực phát triển. Nó bao hàm việc "xem xét lại phần mềm sơ thảo" sau bước thiết kế chương trình sơ thảo, một tuần tự "xem xét lại phần mềm thiết kế tới hạn" trong suốt chương trình thiết kế và một "xem xét lại phần mềm chấp nhận cuối cùng" sau đó kiểm thử. ¾ Sự hiểu thấu bên trong sự vật này đã được theo đuổi trong nhiều năm và những nơi được thực hiện đã sản xuất cho những kết quả đáng tin cậy. Lôi kéo khách hàng với những luận chứng dễ dàng và kế hoạch giải phóng anpha / beta là đã được chứng minh, một kỹ thuật có giá trị. Tôi đã luôn nhấn mạnh (lấn át bằng) sự thấu hiểu bản chất đã được trình bày trên trang giấy này. Trong khi hầu hết công nghệ đã sử dụng nguồn năng lượng đập vào được coi như gần với mô hình thác nước, tôi chỉ thấy những lỗi nhỏ trong lý thuyết thậm chí khi nó đã được áp dụng trong hoàn cảnh của công nghệ hiện nay. Sự phê phán sẽ là mục tiêu trong thực hành cách tiếp cận, nơi kết hợp các giá trị không tốt khác nhau với những yếu tố không thể thực hiện 15
16. được. Tôi nghi ngờ rằng hầu hết những người phê phán chưa bao giờ thực sự hiểu được lý thuyết này; họ mới chỉ hiểu phần thực hành định trước. Trong suốt cuốn sách này, tôi tham khảo vấn đề thực hành trong quá khứ và hiện tại gần với mô hình thác nước, sẽ tiếp tục được thảo luận, như "quy ước (conventional)" tiếp cận hay xử lý phần mềm quản lý. Tôi chứng tỏ rằng nó không dài hơn một khung làm việc tốt cho kỹ nghệ phần mềm hiện đại về mặt thực hành và và kỹ thuật, và tôi sử dụng nó như là một tiêu chuẩn thực sự để hợp lý hoá một cải tiến xử lý mà loại bỏ đi một vài sai sót cơ bản của nó. 1.1.2. Trong thực hành Mặc dù lời khuyên của nhiều chuyên gia phần mềm và lý thuyết sau mô hình thác nước, nhưng một vài dự án phần mềm vẫn thực hiện gần giống với quản lý phần mềm truyền thống. Tuy nhiên, bởi vì sử dụng của nó đang tàn tạ và là nhiều điều phổ biến hơn trong quá khứ, tôi chứng minh nó là một thời quá khứ đã qua. Điều hữu ích để tóm tắt đặc điểm của xử lý truyền thống như là đặc tính trưng đã được áp dụng, điều mà không cần thiết như nó đã là một ý định. Các dự án thường xuyên có các phiền hà thể hiện ra ở các triệu chứng sau đây: • Kéo dài sự tích hợp và điểm gãy thiết kế muộn . • Sự phân tích rủi ro muộn. • Các yêu cầu điều khiển phân rã (phân huỷ) chức năng. • Các quan hệ đối thủ đặt cược (người giữ tiền đặt cược). • Chủ điểm trong tài liệu và xem lại gặp gỡ. Kéo dài sự tích hợp và điểm gãy thiết kế muộn. Cho một điển hình phát triển dự án là sử dụng một mô hình thác nước để quản lý tiến trình, Hình 1-2 minh hoạ sự phát triển tiến triển gắn với (đấu với) thời gian. Sự tiến triển đã được định nghĩa bằng phần trăm chương trình, đó là, có thể giải thích được trên mẫu biểu đích của nó. (Phần mềm có thể dịch được và có thể thực hiện (chạy) được; nó không nhất thiết cần đầy đủ, tương đối dễ dãi, cũng không cần chỉ định rõ ràng). Tuần tự sau đây là (sự tiến triển) chung: • Sớm thành công qua những thiết kế trên giấy và những chỉ dẫn rất đầy đủ, tường tận (thường quá tường tận). • Sự tận tình để mã hoá muộn (bổ sung) trong vòng đời. • Sự phân tích các rủi ro (nguy cơ) phải trả giá đến các thực hiện bất ngờ phát sinh và những sự nhập nhằng giữa các mặt chung. • Bao nặng và sức ép lập lịch sẽ cho hệ thống làm việc. 16
17. • Sắp xếp lại các thiết kế muộn không tối ưu, nếu không có thời gian để thiết kế lại. • Một sản phẩm yếu ớt, không thể giữ được đã được phát ra muộn. Dạng Văn bản Sơ đồ Chương Vạch ranh giới cấu không theo luồng trình hình thể thức nguồn Hoạt Yêu cầu Thiết kế Lập trình Tích hợp theo tỉ lệ động phân tích chương và kiểm mở rộng và kiểm trình thử sửa Sản Tài liệu Tài liệu Chương Vạch ranh giới yếu phẩm trình ớt Các hoạt động kế tiếp: yêu cầu - thiết kế - lập trình – tích hợp - kiểm sửa 100% B¾t ®Çu tÝch hîp §iÓm gi¸n ®o¹n thiÕt kÕ chËm lËp tr×nh) Ngµy ®¹t môc TiÕn ®é ph¸t triÓn (% ®é TiÕn tiªu gèc LÞch tr×nh dù ¸n Hình 1-2. Tiến trình sơ thảo của một dự án phần mềm cổ truyền. 17
18. Bảng 1-1. Phí tổn cho các hoạt động của một dự án phần mềm. Hoạt động Chi phí Quản lý 5% Yêu cầu 5% Thiết kế 10% Lập trình và kiểm tra 30% Tích hợp và kiểm sửa 40% Triển khai 5% Môi trường 5% Tổng 100% Dựa trên ngôn ngữ và kĩ thuật chưa chín muồi được sử dụng trong cách tiếp cận truyền thống, đã có tầm quan trọng đáng kể trong sự hoàn thành "phần mềm thiết kế " trước khi chuyển nó sang ngôn ngữ lập trình mục đích, ở đó nó sẽ rất khó hiểu và thay đổi. Thực hành này đã cho kết quả trong sử dụng nhiều khuôn mẫu (các yêu cầu bằng tiếng Anh , thiết kế sơ bộ trong các sơ đồ luồng, các thiết kế chi tiết trong ngôn ngữ thiết kế chương trình và việc thực hiện đầy đủ trong ngôn ngữ mục đích chẳng hạn như FORTRAN, COBOL, hoặc C ) và những sự dịch chuyển giữa lỗi dễ xảy ra, lao động chuyên sâu và các định dạng. Các kỹ thuật truyền thống được áp dụng vào cho mô hình thác nước trong tiến trình thiết kế thì sẽ không tránh khỏi kết quả trong tích hợp và sự cổ vũ thực hiện. Trong mô hình truyền thống, toàn bộ hệ thống đã được thiết kế trên giấy, sau đó được thực hiện (thử nghiệm) một lần, sau đó được tích hợp. Chỉ tại giai đoạn cuối của tiến trình này thì nó mới được thử nghiệm trên hệ thống kiểm tra để thẩm tra lại rằng kiến trúc thiết yếu (giao diện và cấu trúc) đã đúng đắn. Một chủ chủ đề tuần hoàn (lặp lại) của các dự án tiếp tục sau tiến trình truyền thống là kiểm tra các hoạt động, nó chiếm tới 40% hoặc trên 40% vòng đời của phương pháp. Bảng 1-1 cung cấp một kiểu sơ thảo về các chi phí phải trả qua toàn bộ phạm vi của các hoạt động phần mềm. Phân tích rủi ro chậm. Một sự phát sinh nghiêm trọng được kết hợp với vòng đời (chu trình) thác nước đã thiếu mất sự phân tích rủi ro sớm. Đây không phải là kết quả của chu trình thác nước mà là tiêu điểm trong các tạo tác sớm trên giấy, một trong các giai đoạn thiết kế thật, thực hiện và tích hợp các rủi ro vẫn tương đối khó nắm bắt. Hình 1-3 minh hoạ một kiểu phác thảo rủi ro trong 18
19. các dự án mô hình thác nước truyền thống. Nó gồm 4 chu kỳ bản chất rủi ro khác biệt, những nơi mà rủi ro được định nghĩa là có khả năng mất giá trị, lịch trình, đặc trưng hoặc mục tiêu chất lượng. Tính dễ dãi trong vòng đời như là các yêu cầu phải rõ ràng, các (trình bày) rủi ro hoạt động rất khó đoán trước được. Sau một thiết kế chấp nhận được đã có sẵn có phải cân bằng các hiểu biết về các yêu cầu, thậm chí nó mới chỉ trên giấy, thì trình bày về rủi ro cũng đã phải vững vàng. Tuy nhiên thường nó chỉ vững vàng ở một mức tương đối bởi vì cũng có vài sự việc rõ ràng với một nhà Yªu cÇu ThiÕt kÕ-LËp tr×nh TÝch hîp KiÓm söa Cao §Þnh h−íng tËp trung chu k× gi¶i §iÒu khiÒn chu k× tr×nh rñi ro qu¶n lý rñi ro íng rñi ro cña dù ¸n dù ro cña rñi íng − Chu k× khai Chu k× chi tiÕt ho¸ ChiÒu h th¸c rñi ro rñi ro ThÊp Vßng ®êi dù ¸n Hình 1-3. Rủi ro ban đầu của dự án phần mềm qua vòng đời của nó. quản lý phần mềm có được một đánh giá khách quan. Như hệ thống đã được mã hoá (lập trình), một vài thành phần rủi ro riêng lẻ đã được giải quyết (phân tích). Sau đó sự tích hợp được bát đầu, và phẩm chất thực của mức hệ thống và các rủi ro đã bắt đầu trở nên rõ ràng. Thường thì trong suốt chu kì này nhiều thiết kế phát sinh được giải quyết và các trả giá kỹ thuật đã được tạo ra. Tuy nhiên, quyết định các phát sinh muộn đó trong vòng đời, khi một kìm hãm cố định lớn thay đổi các tạo tác chính, là rất đắt giá. Kết quả là các dự án có chiều hướng kéo dài pha tích hợp (như minh hoạ trong hình 1-2) như là khả năng tái thiết kế cơ bản đã được thực hiện. Tiến trình này theo chiều hướng giải quyết các rủi ro quan trọng, mà nó không mất đi chất lượng của sản phẩm cuối cùng, đặc biệt là tính năng bảo trì của nó. Tôi sử dụng kỳ tái thiết kế khá lỏng lẻo. Hỗu hết những kết quả đạt được này sẽ được miêu tả tốt hơn như sự gán ghép muộn và sự chắp vá thành những hiệu lực sẵn có. Vì vậy toàn bộ kết quả đạt được vẫn là nhỏ nhất. Những sự thay đổi sắp xếp đó đã không bảo toàn được tất cả các thiết kế và sự tương hợp tính bảo trì. 19
20. Phân tích chức năng yêu cầu-điều khiển. Theo truyền thống, tiến trình phát triển phần mềm là yêu cầu - điều khiển: Một sự nỗ lực là đảm bảo đưa ra một lời định nghĩa yêu cầu chính xác và sau đó để thực hiện chính xác các yêu cầu đó. Cách tiếp cận này phụ thuộc vào việc định rõ các yêu cầu một cách đầy đủ và rõ ràng trước khi các hoạt động phát triển khác bắt đầu. Sự thiếu chuyên môn sẽ xem xét toàn bộ các yêu cầu quan trọng như nhau và phụ thuộc vào các yêu cầu cố định còn lại đó trong vòng đời phát triển phần mềm. Những điều kiện hiếm hoi này lại xuất hiện trong thế giới thực. Đặc điểm kỹ thuật của các yêu cầu là một phần khó và quan trọng của tiến trình phát triển phần mềm. Như tranh luận trong phụ lục A, hầu như mọi chương trình phần mềm chính đều phải trải qua những thử thách khắc nghiệt trong các đặc điểm yêu cầu kỹ thuật. Hơn nữa tất cả các yêu cầu xử ký bình đẳng đều thoát ra khỏi số giờ kỹ thuật tất yếu, từ điều chỉnh các yêu cầu và lãng phí những sự cố gắng đó trên công việc văn phòng kết hợp với tính theo dõi, tính kiểm thử được, sự hỗ trợ hậu cần, và vì vậy công việc văn phòng chắc chắn sẽ bị loại bỏ muộn hơn. do việc điều chỉnh các yêu cầu và tính kế thừa các thiết kế tiên tiến đã biết. Một ví dụ, xem xét một dự án lớn như dự án CCPDSR , được trình bày như một thí dụ nghiên cứu tiêu biểu (case study) trong phụ lục D, nơi mà các yêu cầu phần mềm bao gồm 2000 "shall" (Một "shall" là một yêu cầu riêng rẽ nghĩa là "hệ thống phải chịu đựng tất cả những hư hỏng phần cứng đơn lẻ mà không mất đi các khả năng tới hạn). Sự quan hệ tương xứng với định hướng thiết kế trong hệ thống như vậy (đặc biệt chỉ có từ 20 đến 50 "shall") là rất khó khăn khi sự chuẩn hoá giao ước yêu cầu toàn bộ 2000 shall được xác định trước và được xử lý tại mọi mốc chính. Mức nỗ lực công nghệ mà nó có thể được tiêu phí trong vấn đề thiết kế quan trọng là bị mờ nhạt bởi việc tiến hành vượt quá 1950 shalls và việc xử lý tính theo dõi được, tính kiểm thử được, tài liệu hoá được Một tính chất khác của cách tiếp cận truyền thống là các yêu cầu được xác định cụ thể theo nghĩa chức năng. Việc xây dựng quá trình thác nước cổ điển là giả định cơ bản mà phần mềm này tự phân rã thành các chức năng, các yêu cầu này đã được thiết lập thành những thành phần. Việc phân rã này thường rất khác với việc phân rã dựa trên thiết kế hướng đối tượng và sử dụng những thành phần hiện có. Việc phân rã chức năng cũng trở thành ràng buộc trong các hợp đồng, phụ lục hợp đồng và cấu trúc phân rã công việc, thông thường nó loại bỏ cách tiếp cận kiến trúc. Hình 4-1 minh hoạ kết quả của tiếp cận hướng yêu cầu, đó là một cấu trúc phần mềm mà được tổ chức xung quanh các cấu trúc xác định yêu cầu. Những mối quan hệ cổ đông đối phương. Tiến trình truyền thống dẫn tới kết quả trong quan hệ cổ đông đối phương, trong mối quan hệ lớn, bởi vì sự khó khăn trong việc xác định các yêu cầu và sự trao đổi thông tin chỉ qua những tài liệu giấy mà nó có thể bao gồm những thông tin công nghệ không theo thể thức. Sự thiếu những ký hiệu chặt chẽ xảy ra trong hầu hết các xem xét vấn đề và sự bảo thủ khi thay đổi thông tin. 20
21. Yªu cÇu hÖ Yªu cÇu phÇn Thµnh phÇn phÇn C¸c khèi phÇn thèng mÒm mÒm mÒm Fa Fb Fc Ra Fa Fb Fc Rb Rc Fi Fj Fk R1 Ri Fi Fj Fk R2 Rj Rn Rk Fx Fy Fz Rx Fx Fy Fz Ry Rz Hình 1-4. Tổ chức các thành phần của phần mềm tối ưu hoá cục bộ từ cách tiếp cận hướng yêu cầu. Dãy các sự kiện sau đây có thể được áp dụng đối với hầu hết những nỗ lực phần mềm có hợp đồng. 1. Người làm hợp đồng chuẩn bị một tài liệu hợp đồng nháp mà nó đề cập tới những mẫu tác trực tiếp và phân phát cho khách hàng để đánh giá. 2. Khách hàng sẽ được đề nghị để cung cấp những nhận xét (đặc biệt trong vòng từ 15 đến 30 ngày) . 3. Người chủ hợp đồng sẽ tổng hợp những nhận xét này và đệ trình một phiên bản cuối cùng để đánh giá (đặc biệt trong vòng từ 15 đến 30 ngày). Quá trình xem xét ngắn gọn này thể hiện sự nhạy cảm cao độ giữa khách hàng và chủ hợp đồng. Quá trình xem xét sự thay đổi chỉ chiếu trên một trang giấy như vậy là không thể được. Cách tiếp cận này cũng đưa ra một mối quan hệ giữa khách hàng và chủ hợp đồng sẽ làm suy đồi sự không tin cậy lẫn nhau, làm khó khăn để đạt tới sự thoả thuận về các yêu cầu về kế hoạch và chi phí. Trọng tâm các tài liệu và thảo luận trong các cuộc gặp gỡ. Tiến trình truyền thống chú trọng vào việc đưa ra những tài liệu khác nhau để mô tả những sản phẩm phần mềm, mà thiếu chú trọng vào sự tăng trưởng thực tế của chính các sản phẩm đó. Những mốc chính thường được thực hiện như những nghi thức gặp gỡ được viết (định 21
22. Bảng 1-2. Kết quả của việc xem xét lại thiết kế của dự án phần mềm truyền thống. Những kết quả rõ Những kết quả thực tế ràng Chỉ dẫn rộng rãi cho Chỉ một tỉ lệ phần trăm nhỏ độc giả hiểu phần nhiều loại độc giả mềm. Những chỉ dẫn và tài liệu trình bày một vài giá trị quan trọng và những rủi ro của hệ thống phần mềm phức tạp. Một thiết kế xuất hiện Có sự không rõ ràng xác thực của sự dễ dãI khá dễ dãi. Sự dễ dãi với các yêu cầu mập mờ là một lượng nhỏ giá trị. Các yêu cầu gộp (hàng Một vài (khoảng 10) là các điều khiển thiết kế. trăm loại) Giải quyếta các yêu cầu làm mờ nhạt trọng tâm các điều khiển tới hạn. Một thiết kế được coi Thiết kế luôn luôn có lỗi là "vô tội cho đến khi Các dòng thiết kế đã được bày ra muộn hơn được chứng minh là có trong vòng đời. tội" nghĩa) một cách đơn điệu trong các thuật ngữ của các tài liệu cụ thể. Những nhà đầu tư thường đưa ra hàng tấn những giấy tờ để đạt được những mốc và những quá trình mô phỏng cho cổ đông hơn là họ sử dụng các năng lực của mình đối với công việc mà nó sẽ làm giảm rủi ro và đưa ra những phần mềm có chất lượng. Đặc biệt những người trình bày và những người nghe sẽ xem xét lại những điều đơn giản mà họ đã hiểu hơn là những vấn đề quan trọng và phức tạp. Bởi vậy hầu như việc xem xét lại thiết kế sẽ đưa ra những giá trị công nghệ rất thấp mà chi phí cao theo sự nỗ lực và lập lịch trong việc chuẩn bị và điều khiển của họ. Họ trình bày hầu như là bề ngoài của quá trình. Bảng 1-2 tóm tắt những kết quả việc xem xét lại thiết kế. Việc chuẩn đoán năm triệu chứng của dự án gây ra những trục trặc có thể là rất khó khăn (như chúng ta vừa thảo luận) đặc biệt trong những pha ban đầu của vòng đời khi vấn đề với cách tiếp cận thông thường hầu như rất dễ điều trị. Bởi vậy các dự án phần mềm hiện đại phải sử dụng một cơ chế để đánh giá độ mạnh của dự án trong những pha đầu của vòng đời và nó sẽ được tiếp tục với việc kiểm tra theo chu kì và khách quan (có mục tiêu). 1.2. Quản lý phần mềm thông thường Một trang của Barry Boehm "danh sách dẫn đầu 10 độ đo phần mềm công nghiệp" [Boehm, 1987] là một đặc trưng khách quan tốt của tình hình phát triển phần mềm. (Có rất ít 22
23. các chứng cớ của những sự thay đổi quan trọng.) Mặc dù rất nhiều các độ đo, chúng đã mô tả một vài mối quan hệ kinh tế đơn giản mà nó là kết quả từ những quá trình phần mềm thông thường thực hành trên 30 năm qua. Trong các đoạn sau, được trích dẫn từ danh sách 10 độ đo dẫn đầu của Boehm sẽ được trình bày bằng chữ in nghiêng, sau đó là phần giải thích: 1. Phát hiện và chỉnh sửa các sai sót phần mềm sau khi phân phối có chi phí gấp hơn 100 lần so với việc phát hiện và chỉnh sửa các sai sót. ¾ Cách này chiếm ưu thế chính trong hầu hết mọi hướng cải tiến tiến trình được nói đến ở đây hay trong bất kỳ cuốn sách nào khác. Nó không phải là cách độc nhất để phát triển phần mềm. Khi một trong những nhà máy ô tô lớn thi hành việc gọi lại một sản phẩm khiếm khuyết đã phát tán (ra thị trường), thì giá sắp xếp sửa chữa có thể lớn hơn nhiều so với chi phí sửa chữa khiếm khuyết đó trong giai đoạn kỹ thuật hoặc giai đoạn sản xuất. 2. Bạn có thể nén lịch trình phát triển phần mềm tới 25% nhưng không được vượt quá. ¾ Một lý do cho N% này giảm xuống trong lịch trình sẽ kéo theo M% kia tăng lên trong nguồn nhân lực (giả sử rằng các thông số còn lại khác giữ nguyên). Bất kỳ sự tăng lên về số lượng nhân lực nào cũng yêu cầu tổng phí quản lý lớn hơn. Nói chung, sự linh hoạt của giới hạn trong tổng phí này, theo lịch trình phù hợp với các hoạt động, bảo vệ dãy các hoạt động và các nguồn bắt buộc khác, vào khoảng 25%. Một cách tối ưu, sự nỗ lực của 100 nhân viên trong một tháng cũng sẽ bằng sự nỗ lực của 10 người trong 10 tháng. Công việc này có thể thực hiện được trong một tháng với 100 người không? Hay có thể thực hiện trong hai tháng với 50 người được không? Hoặc trong khoảng 5 tháng với 20 người không? Điều rõ ràng là, sự lựa chọn này là phi thực tế. Độ đo nén 25% nói rằng giới hạn trong sự lựa chọn này là 7 tháng rưỡi (và có thể đòi hỏi thêm có lẽ là khoảng 20 nhân viên làm việc theo chế độ bình thường). Bất kỳ lịch trình nén nào xa hơn cũng sụp đổ thành đống tro tàn. Trên một phương diện khác, một lịch trình tối ưu có thể bị kéo dài một cách tuỳ tiện và phụ thuộc vào con người, có thể được thực hiện trong thời gian dài hơn với nguồn nhân lực nhiều hơn đôi chút. Thí dụ, nếu bạn có một lịch trình xa xỉ trong 25 tháng, thì bạn có thể chỉ cần 75 nhân viên và 3 người làm việc theo chế độ bình thường. 3. Sử dụng một đôla cho việc phát triển, nhưng bạn sẽ phải sử dụng 2 đôla cho việc bảo trì. ¾ Boehm gọi điều này là "luật thép phát triển phần mềm." Dù bạn xây dựng một sản phẩm có tuổi thọ cao mà phiên bản ngoài thị trường nâng cấp 2 lần một năm hoặc xây dựng một hệ thống phần mềm đã đặt trước, số tiền được dùng để bảo trì vòng 23
24. đời của sản phẩm có thể sẽ nhiều gấp đôi số tiền đã được dùng để phát triển vòng đời sản phẩm. Sẽ rất khó khăn để nói rằng mối quan hệ đầu tiên này là tốt hay xấu. Trong miền sản phẩm lưu hành, quan hệ điều khiển chính này là sự thành công của sản phẩm trên thị trường. Các sản phẩm phần mềm thành công (như Oracle, các chương trình ứng dụng của Microsoft, Rational Rose, và hệ điều hành Unix) đã sống trên thị trường rất lâu và có thể kết quả là tỉ lệ giữa chi phí bảo trì và chi phí phát triển còn cao hơn nhiều. Trên một phương diện khác những nhà quản lý một trong các loại dự án phần mềm, hiếm thấy có một kế hoạch để chi tiêu nhiều như bảo trì phần mềm. Mặt khác, bất kỳ người nào đã làm việc trong nền công nghiệp phần mềm từ trên 10 đến 20 năm đều biết rằng phần mềm đang trong hoạt động được coi như là rất khó bảo trì. 4. Các chi phí phát triển và bảo trì phần mềm là một chức năng chính của số lượng các dòng chương trình nguồn. ¾ Độ đo này là kết quả cơ bản của ưu thế của phát triển phần mềm đặt trước, thiếu tính hợp thành thương mại và thiếu tính kế thừa những cái sẵn có trong kỷ nguyên tiến trình cổ điển. 5. Sự biến đổi trong tính toán của con người là sự khác biệt lớn nhất trong các sản phẩm phần mềm. ¾ Đây là chìa khoá của sự thông thái truyền thống: Thuê nhân công tốt. Độ đo này là một chủ đề của cả sự quá cường điệu và dưới mức cường điệu. Khi bạn không biết một cách khách quan tại sao lại bạn thành công hay thất bại, sự bung xung (scapegoat) rõ ràng là khả năng chuyên môn của con người. Sự đánh giá này là khách quan và khó thách thức. 6. Toàn bộ tỉ lệ các chi phí về phần cứng đến phần mềm đều vẫn đang tăng trưởng. Năm 1955 tỉ lệ này là 15:85; năm 1985 là 85:15. ¾ Thực tế phần mềm chiếm 85% giá trị của hầu hết các hệ thống là không quá nhiều đối với hiệu suất phần mềm (điều mà có thể cho rằng nó không tốt như chúng ta cần) như là khoảng mức chức năng đã được chỉ định đối với phần mềm trong hệ thống phân tán. Điều cần thiết cho phần mềm, tính rộng rãi của các chương trình ứng dụng, và tính phức tạp tiếp diễn để tăng trưởng không có giới hạn. 7. Chỉ 15% nỗ lực phát triển phần mềm là được chuyển biến thành chương trình. ¾ Đây là một chỉ báo quan trọng của sự cần thiết cho sự cân bằng. Nhiều hoạt động ngoài việc lập trình là cần thiết cho sự thành công của các dự án phần mềm. Quản lý yêu cầu, thiết kế , kiểm sửa, điều khiển dự án , quản lý thay đổi và các công cụ được xem xét tầm quan trọng như nhau mà nó chi phí khoảng 85% nguồn tài nguyên. 24
25. 8. Các hệ thống phần mềm và các sản phẩm tiêu biểu có giá trị nhiều hơn 3 lần trên một SLOC so với các chương trình phần mềm riêng rẽ. Các sản phẩm phần mềm hệ thống (ví dụ, hệ thống của các hệ thống) có giá trị nhiều gấp 9 lần. ¾ Mối quan hệ luỹ thừa này là cần thiết cho những gì mà ta gọi là sự không kinh tế của các thang chia. Không giống như những hàng hoá khác càng có nhiều phần mềm được xây dựng thì chi phí càng cao đối với mỗi một dòng lệnh nguồn 9. Vượt qua được trên 60% các lỗi. ¾ Điều này là thực tế. Tuy nhiên, độ đo 1 đã cho sự vượt quá này là không nắm bắt được cái sai sót mà những phần chính và những sự chắc chắn không nắm bắt được đủ sớm trong vòng đời. Toàn bộ các phát hiện ra là không bằng nhau. Nhìn chung sự vượt qua và những dạng khác của các thanh tra con người đủ để nắm bắt được toàn bộ vấn đề và kiểu loại vấn đề. Nếu chúng ta sử dụng những kí hiệu thiết kế không theo chuẩn thì sự xem xét của con người có thể là một cơ chế đảm bảo chất lượng cơ bản nhưng nó không được tốt trong việc khắc phục những vấn đề bậc 2, bậc 3, và bậc thứ n. Hơn nữa, một vài người rất giỏi trong việc xem xét lại những vấn đề ngữ nghĩa trong đoạn mã nguồn. 10. 80% sự đóng góp đến từ 20% những nhà đóng góp. ¾ Đây là một phát biểu có trách nhiệm mà nó thực sự đúng trong hầu hết các nguyên lý công nghệ (hoặc là các nguyên lý chuyên nghiệp đối với vấn đề đó). Tôi sẽ mở rộng độ đo này trong việc giải thích cụ thể hơn đối với phần mềm. Sự thừa nhận cơ bản sau đây với một tỉ lệ cho các khuôn mẫu xử lý, quản lý phần mềm hiện đại: 80% công nghệ là chi phí bởi 20% của các yêu cầu 80% giá trị phần mềm là chi phí bởi 20% thành phần 80% sai sót là nguyên nhân bởi 20% thành phần 80% sự phế thải và làm lại phần mềm là bởi 20% của sai sót 80% các nguồn tài nguyên là tiêu phí bởi 20% thành phần 80% các công nghệ là hoàn thành bởi 20% công cụ 80% sự tiến bộ là được làm bởi 20% con người. Những mối này đã đưa ra một và tiêu chuẩn tốt để đánh giá sự cải tiến của quá trình và công nghệ. Chúng biểu diễn các quy tắc thô mà nó đặc trưng cho tính chủ quan sự thực thi của quá trình quản lý phần mềm và kỹ thuật truyền thống. Trong những chương sau chúng ta sẽ quay trở lại những độ đo này để hợp lý hoá một cách tiếp cận mới bảo vệ cách tiếp cận cũ và cải thiện công nghệ và tiến trình. 25
26. Chương 2 Sự tiến hoá nền kinh tế phần mềm Những điểm chính: ¾ Những kết quả kinh tế của dự án phần mềm truyền thống phản ánh một nền công nghiệp bị chi phối bởi các tập quán phát triển, quy trình đặc biệt và tỉ lệ phi kinh tế. ¾ Giá trị của các mô hình hiện nay là cơ sở chính trong các cơ sở dữ liệu dự án thực nghiệm với một vài câu chuyện hợp thời lặp lại về thành công phát triển. ¾ Giá trị của một phần mềm tốt được ước lượng là rất khó được hoàn thiện, người đưa ra quyết định phải tập trung xử lý những ước lượng không chính xác. ¾ Một khuôn khổ tiến trình hiện đại tấn công vào tài nguyên cơ bản của tỉ lệ phi kinh tế cố hữu trong tiến trình phát triển phần mềm. Công nghệ phần mềm đã bị chi phối bởi các hoạt động trí tuệ mà trọng tâm là việc giải quyết các vấn đề phức tạp rộng lớn với nhiều điều chưa biết trong các phối cảnh tham dự. Những cách tiếp cận phần mềm sớm trong những thập niên 60 và 70 có thể rất tốt được mô tả như một sự điêu luyện với mỗi dự án sử dụng một tiến trình và những công cụ định trước. Trong những thập niên 80 và 90, nền công nghệ phần mềm đã hoàn thiện và chuyển biến sang một kỹ thuật có kỷ luật hơn. Tuy nhiên hầu hết các dự án phần mềm trong kỷ nguyên này vẫn chủ yếu là đi sâu nghiên cứu, bị chi phối bởi những ngươi tạo ra và tỉ lệ phi kinh tế. Các tiến trình phần mềm thế hệ tiếp theo, đặc biệt là các kỹ thuật trình bày trong cuốn sách này là nhằm hướng tới một cách tiếp cận chuyên sâu được chi phối bởi kỹ thuật tự động hoá và tỉ lệ phi kinh tế. 2.1.Nền kinh tế phần mềm Hầu hết các mô hình giá trị phần mềm có thể được trừu tượng hoá thành một hàm có 5 tham số cơ bản là: kích thước, tiến trình, đội ngũ cán bộ, môi trường và yêu cầu chất lượng. 1. Kích thước của sản phẩm phần mềm cuối cùng (các thành phần của nó do con người tạo ra) cái mà tiêu chuẩn điển hình là số lượng câu lệnh nguồn hoặc số lượng các điểm chức năng đòi hỏi để phát triển các chức năng yêu cầu. 2. Tiến trình được sử dụng để sản xuất ra sản phẩm cuối cùng, đặc biệt khả năng của tiến trình để tránh các hoạt động thêm vào vô giá trị (sửa chữa làm lại, nhân viên nghỉ, tổng phí truyền thông.) 3. Năng lực của đội ngũ kỹ thuật viên phần mềm và đặc biệt là kinh nghiệm của họ về khoa học máy tính và các miền ứng dụng của dự án. 26
27. 4. Môi trường, nơi mà đã có sẵn các công cụ và kỹ thuật đã được tạo ra để tăng cường hiệu năng phát triển phần mềm và để tự động hoá tiến trình. 5. Yêu cầu chất lượng của sản phẩm bao gồm: các đặc tính, hiệu năng, sự tin cậy và tính phù hợp. Các quan hệ giữa các tham biến này và việc ước lượng giá trị có thể được viết như sau: Công sức = (Đội ngũ nhân viên)(Môi trường)(Chất lượng)(Kích thướcTiến trình). Một vài mô hình tham số đã được phát triển để ước lượng giá trị phần mềm; hầu hết chúng có thể còn khá trừu tượng đối với mẫu biểu này. Một khía cạnh quan trọng của nền kinh tế phần mềm (như đã trình bày trong các mô hình chi phí phần mềm hiện nay) là mối quan hệ giữa công sức và kích thước trưng bày một tỉ lệ phi kinh tế. Tỉ lệ phi kinh tế của phát triển phần mềm là kết quả của sự ủng hộ tiến trình,tỉ lệ này lớn hơn 1.0. Điều trái ngược đối với hầu hết các tiến trình sản xuất là càng nhiều phần mềm được xây dựng thì nó lại càng đắt hơn trên một đơn vị khoản mục. Ví dụ, cho một ứng dụng ,10000 dòng giải pháp phần mềm sẽ có giá trị nhỏ hơn trên một dòng so với 100000 dòng giải pháp phần mềm. Sự nhỏ hơn này là bao nhiêu? Giả sử rằng 100000 dòng hệ thống đòi hỏi 900 nhân viên-tháng để phát triển, hay khoảng 111 dòng trên một nhân viên-tháng, hay 1,37 giờ trên một dòng. Nếu cùng một hệ thống này, nhưng chỉ có 10000 dòng và tất cả các thông số khác giữ nguyên không đổi, thì hệ thống này sẽ được ước lượng là vào 62 nhân viên-tháng hay khoảng 175 dòng trên một nhân viên-tháng, hay 0,87 giờ trên một dòng. (Hình B-1 trong Phụ lục B sẽ đưa ra một mô tả chi tiết hơn về ví dụ này sử dụng mô hình ước lượng giá trị COCOMO.) Giá trị trên dòng đối với một ứng dụng nhỏ nhỏ hơn nhiều so với một ứng dụng lớn hơn. Nguyên nhân chính là sự phức tạp trong quản lý sự hoà hợp các cá nhân truyền thông như là số lượng các thành viên của đội (và sự phù hợp các mục tiêu, chiến thắng các điều kiện, các sai lệch kỹ thuật) tăng lên. Tỉ lệ phi kinh tế này là tính chất của bất kỳ dự án nghiên cứu nào nơi mà sản phẩm là một loại ví dụ của tài sản trí tuệ. Hình 2-1 trình diễn 3 thế hệ kỹ thuật nâng cao cơ bản là các công cụ, các thành phần và các tiến trình. Các mức độ yêu cầu về chất lượng và đội ngũ nhân viên được giả thiết là không đổi. Tung độ của hình vẽ quy vào giá trị đơn vị phần mềm (đặt theo sở thích của bạn: trên một SLOC, trên một điểm chức năng, trên một phần tử) được thực hiện (bán ra) bởi một tổ chức. Hoành độ biểu diễn vòng đời của thương mại phần mềm được thuê bởi một tổ chức. Ba thời kỳ phát triển phần mềm được định nghĩa như sau: 1. Thời kỳ cổ truyền: thủ công, vào những thập niên 60 và 70. Việc tổ chức sử dụng các công cụ, các tiến trình tập quán cổ truyền và thực sự toàn bộ các phần tử được xây dựng lên từ các ngôn ngữ nguyên thuỷ. Hiệu năng của dự án được dự đoán cao trong các giá trị, lịch trình và chất lượng mục tiêu đó nhưng hầu hết chúng luôn không đạt được như dự đoán. 27
28. 2. Thời kỳ quá độ: kỹ thuật phần mềm, vào những thập niên 80 và 90. Việc tổ chức sử dụng nhiều hơn các tiến trình lặp, các công cụ không lỗi thời và hầu hết (>70%) các thành phần tập quán được xây dựng trên các ngôn ngữ bậc cao hơn. Một vài thành phần (<30%) sẵn có từ trước như những sản phẩm thương mại, bao gồm hệ điều hành, hệ quản trị cơ sở dữ liệu, mạng máy tính, và giao diện đồ hoạ người dùng. Trong suốt những năm 80, một vài tổ chức đã bắt đầu giành được hiệu quả kinh tế, nhưng với sự tăng trưởng trong các ứng dụng phức tạp (các hệ thống chính đang chuyển sang hệ phân tán), những ngôn ngữ, những kỹ thuật và công nghệ đã có không đủ để làm nhụt (làm bẩn) được mong muốn về hiệu năng thương mại. 3. Thời kỳ hiên đại: sự sản xuất phần mềm, những năm 2000 và thời kỳ sau đó. Triết lý của cuốn sách này là nguồn gốc trong việc quản lý và phân phối các tiến trình, tích hợp các môi trường tự động, và hầu hết (70%) các thành phần không lỗi thời. Có lẽ khoảng 30% thành phần cần được làm theo sự đặt trước. Với những tiến bộ trong công nghệ phần mềm và sự tích hợp trong các môi trường sản xuất, các hệ thống thành phần cơ bản đó có thể được sản xuất rất nhanh chóng. 28
29. Mục tiêu đích: Cải tiến ROI ( kết quả đầu tư ) - Result of investmend Ý Chi ph ROI phÇn mÒm KÝch th−íc phÇn mÒm -1960s-1970s -1980s-1990s -2000 vµ sau ®ã -M« h×nh th¸c n−íc -C¶i tiÕn tiÕn tr×nh -Sù ph¸t triÓn lÆp ®i lÆp l¹i -ThiÕt kÕ chøc n¨ng -Dùa vµo bao boc -Thµnh phÇn -TØ lÖ phi kinh tÕ -TØ lÖ phi kinh tÕ -KÕt qu¶ ®Çu t− Sự phù hợp môi trường, kích thước, và các công nghệ tiến trình Môi Môi trường/Công Môi trường/Công trường/Công cụ cụ cụ Không lỗi thời, Không lỗi thời, Tập quán riêng rẽ tích hợp Kích thước: Kích thước: Kích thước: 100% tập 30% Dựa vào thành 70% Dựa vào thành quán phần-cơ bản phần-cơ bản 70% tập quán 30% tập quán Tiến trình: Tiến trình: Tiến trình: Theo trường hợp Có thể lặp lại Quản lý/ Phân đặc biệt phối Hiệu năng dự án điển hình Khả năng dự đoán tồi Không có khả năng dự đoán Có khả năng dự đoán Luôn luôn: Không thường xuyên: Thường xuyên: Vượt quá ngân sách Đúng ngân sách Đúng ngân sách Vượt quá lịch trình Đúng lịch trình Đúng lịch trình 29
30. Hình 2-1. Ba giai đoạn của nền kinh tế phần mềm dẫn tới mục tiêu đích. Các công nghệ đối với môi trường tự động, sự giảm kích thước, và cải tiến tiến trình không độc lập với những điều khác. Trong mỗi kỷ ngyuên mới, chìa khoá là sự tăng trưởng hoàn thiện toàn bộ các công nghệ. Ví dụ một tiến trình tiên tiến sẽ không thể được sử dụng một cách thành công nếu thiếu các thành phần công nghệ mới và sự tăng trưởng của công cụ tự động hoá. ROI đạt được qua đường thương mại. Đầu tư vào kiến trúc, tiến Hệ thống Hệ Hệ thống thứ N trình, và môi trường chung đầu tiên thống cho toàn bộ các hệ thống thứ hai đường thương mại Vòng đời kinh doanh: hệ thống kế tiếp ROI đạt được qua một dự án với nhiều sự lặp lại. Đầu tư vào kiến trúc thô, tiến Sự lặp lại Sự lặp lại Sự lặp lại trình lặp chín chắn, và tiến đầu tiên thứ hai thứ N trình tự động hóa. Vòng đời dự án: Cách lập liên tục ROI đạt được qua một vòng đời của sản phẩm bán ra. Đầu tư vào kiến trúc, sản phẩm Lần bán đầu Lần bán Lần bán N trường chung cho toàn bộ các tiên thứ 3 hệ thống đường thương mạI quá trình bán và tự động hoá tiến trình. Vòng đời sản phẩm: Hình 2-2. Kết quả đầu tư trong những miền khác nhau. 30
31. Sự quá độ lên mô hình hiện đại và sự hứa hẹn cải tiến nền kinh tế phần mềm không có nghĩa là nó đã được bảo đảm. Chúng ta phải thực tế trong sự so sánh tính khả thi của sự hứa hẹn, tiến trình thế hệ tiếp theo sử dụng các công nghệ hiện đại chống lại những thực tế không tốt còn lại của lịch sử. Một điều đánh cuộc chắc chắn rằng nhiều tổ chức đang cố gắng mang về các dự án hiện đại với những kỹ thuật và công nghệ hiện đại nhưng cũng kết thúc với sự hỗn độn tương tự trước đó. Nhiều tổ chức đang đạt được tỉ lệ kinh tế tốt hơn trong kỷ nguyên công nghệ kế tiếp với những dự án rất lớn (những hệ thống của hệ thống), các sản phẩm tuổi thọ cao và các đường thương mại chứa nhiều dự án tương tự. Hình 2-2 đưa ra một điều tra tổng quát về kết quả đầu tư (ROI) ban đầu có thể đạt được trong sự nỗ lực kế tiếp qua các vòng đời của các miền khác nhau. 2.2.Sự ước lượng chi phí phần mềm thực dụng Một vấn đề giới hạn trong việc ước lượng chi phí phần mềm là thiếu một tài liệu chuẩn làm căn cứ để nghiên cứu các dự án mà sử dụng một cách tiếp cận phát triển lặp lại. Mặc dù mô hình chi phí mà những người bán khẳng định rằng các công cụ của họ là phù hợp đối với ước lượng sự phát triển các dự án, một vài cơ sở trong các cơ sở dữ liệu dự án thực nghiệm với những câu chuyện hiện đại về sự thành công phát triển lặp lại. Hơn nữa, bởi vì nền công nghiệp phần mềm có sự không đồng nhất trong việc định nghĩa các độ đo hoặc các đơn vị đo đạc nguyên tố, dữ liệu từ các dự án hoạt động có dấu hiệu đáng ngờ cao trong giới hạn kiên định và tính so sánh được. Sẽ khó có thể thu lượm đủ các bộ dữ liệu dự án đồng nhất trong một tổ chức, sẽ cực kỳ khó để đồng nhất các dữ liệu qua các tổ chức khác nhau với những tiến trình, những ngôn ngữ, và các miền khác nhau v.v Ví dụ, kích thước đơn vị cơ bản (một đường mã nguồn hay điểm chức năng) có thể, và được đo khác nhau qua nền công nghiệp. Đó là điều ngẫu nhiên mà ngôn ngữ chuẩn hiện đại (như Ada 95 và Java) cũng không tạo ra một định nghĩa đơn giản về một đường thông báo nguồn bằng bộ dịch của nó. Định nghĩa chính xác về điểm chức năng hoặc một SLOC là không thật quan trọng, nó cũng chỉ như độ dài chính xác của một foot (0,8085 mét) hay một mét là bằng giá trị tuỳ ý. Điều quan trọng đơn giản là mọi người cùng sử dụng một cách định nghĩa. Có nhiều thế đứng dài được thảo luận giữa những người phát triển và những người bán các mô hình và công cụ ước lượng chi phí phần mềm. Ba chủ đề của các thảo luận đặc biệt thú vị sau đây: 1. Mô hình ước lượng chi phí được sử dụng. 2. Có hay không một cách đo kích thước phần mềm trong các đường mã nguồn hay điểm chức năng. 3. Những gì cấu thành nên một ước lượng tốt. 31
32. Khoảng 50 nhà cung cấp (bán) các công cụ ước lượng chi phí phần mềm ,dữ liệu và các dịch vụ hoàn thiện ở trong nền công nghiệp phần mềm. Các mô hình ước lượng chi phí (như COCOMO, CHECKPOINT, ESTIMACS, KnowledgePlan, Price-S, ProQMS, SEER, SLIM, SOFTCOST, và SPQR/20) tốt như đông đảo các mô hình tổ chức-rõ ràng. Bởi vì kinh ngiệm đầu tay của tôi với các mô hình này là trọng tâm của COCOMO và những người thành công với nó, Ada COCOMO và COCOMO II, đó là nền tảng trong nhiều lí lẽ và triển vọng về nền kinh tế phần mềm của tôi. COCOMO cũng là một trong những mô hình mở nhất và sự ước lượng chi phí được tài liệu hoá tốt. Sự phát triển của COCOMO sang phiên bản hiện tại của nó, COCOMO II, đã được tổng kết trong phụ lục B. Trong khi các phần của phụ lục không thể trực tiếp áp dụng các kỹ thuật và công nghệ hiện nay, thì nó đưa ra một triển vọng lịch sử thú vị trong sự phát triển những phát sinh và những ưu tiên của nền kinh tế phần mềm qua 20 năm qua. Việc đo đạc kích thước phần mềm là chủ đề của nhiều bài hùng biện. Điều cơ bản về 2 điểm mục đích của quan điểm: các đường mã nguồn và các điểm chức năng. Cả hai triển vọng đều đã được chứng minh là có giá trị hơn cái thứ ba, nó là mục tiêu hay điểm đặc biệt của quan điểm thực hành của nhiều tổ chức non nớt mà sử dụng không theo hệ thống đo đạc kích thước. Nhiều nhà chuyên môn phần mềm đã chỉ rõ rằng SLOC là một cách đo đạc kích thước tồi tệ. Tuy nhiên khi đoạn mã là mô tả như 1000 dòng lệnh chương trình nguồn, thì hầu hết mọi người đệu cảm thấy thoải mái với tổng thể "khối" của nó. Nếu sự mô tả là 20 điểm chức năng, 6 lớp, 5 trường hợp sử dụng, 4 điểm đối tượng, 6 tệp, 2 hệ thống con, 1 phần tử hoặc 6000 byte, hầu hết mọi người, bao gồm cả chuyên gia phần mềm, cũng sẽ hỏi những câu hỏi xa xôi để đạt được một sự hiểu biết về đối tượng mã chương trình. (Nhiều người trong số họ sẽ hỏi có bao nhiêu SLOC). Vì vậy SLOC vẫn là một cách đo đạc còn một vài giá trị. Tôi là một SLOC cuồng tín một thập kỷ trước đây bởi vì SLOC đã làm việc rất tốt trong các ứng dụng mà hầu hết được đặt trước và bởi vì SLOC là một phương pháp đo đạc dễ tự động hoá và dễ cung cấp. Ngày nay, ngôn ngữ bậc cao và sử dụng các phần tử, sự sinh ra tự động hoá mã nguồn và sự hướng đối tượng đã làm cho SLOC có nhiều đo đạc nhập nhằng hơn. Như một ví dụ sắc bén, trường hợp nghiên cứa trong phụ lục D mô tả rất cẩn thận các cách tiếp cận thủ công đối với đo đạc SLOC để điều tiết việc sử dụng lại, tập quán phát triển, và các công cụ sinh mã trong một dự án phần mềm lớn. Việc sử dụng những điểm chức năng có một sự noi theo lớn, bao gồm Capers Jones, người trích dẫn (cites) sự kết hợp đầy may rủi với việc sử dụng độ đo SLOC cho các chương trình hướng đối tượng [ Jones,1994 ]. Tổ chức "Nhóm của người sử dụng điểm chức năng quốc tế" (The International Function Point User's Group), được thành lập năm 1884, là tổ chức đo đạc phần mềm tiêu biểu trong công nghiệp. Ưu điểm chính trong việc sử dụng các điểm chức năng là phương pháp này độc lập với công nghệ và vì thế có nhiều điều tốt hơn đơn vị nguyên thuỷ để so sánh giữa các dự án và các tổ chức. Nhược điểm chính của nó là các định nghĩa 32
33. nguyên thuỷ khá trừu tượng và cách thức đo đạc không dễ bắt nguồn trực tiếp từ việc mở ra các tạo tác. Mặc dù cả hai cách đo đạc kích thước đều có trở ngại của chúng, nhưng tôi nghĩ một tổ chức có thể tạo ra cả hai trong một công việc. Việc sử dụng một vài cách đo là tốt hơn không dùng cách nào. Bất kỳ người nào đang làm các phép so sánh qua các dự án hoặc tổ chức thì đều nên sử dụng các điểm chức năng như là cách đo đạc kích thước. Các điểm chức năng cũng có thể ước lượng chính xác hơn trong những pha sớm của một vòng đời dự án. Tuy nhiên trong những pha muộn hơn, SLOC sẽ trở nên hữu ích và rõ ràng hơn phép đo đạc cơ bản của những độ đo triển vọng khác nhau. Chương 16 trình bày giả thuyết của tôi về một mô hình chi phí thế hệ tiếp theo mô hình mà có thể nhỏ nhất hay thậm chí lỗi thời điều cần thiết đối với phương pháp đo SLOC. Sự đúng đắn nói chung của các mô hình chi phí truyền thống (như COCOMO) đã được mô tả như "ở trong 20% các hoạt động, 70% thời gian." Mức không thể dự đoán này trong tiến trình phát triển phần mềm truyền thống sẽ thực sự khủng khiếp đối với mọi nhà đầu tư, đặc biệt trong trong ánh sáng của thực tế một vài dự án bị mất ước lượng của nó bởi những việc làm tốt hơn sự mong đợi. Đây là một hiện tượng thú vị được coi trọng khi lập lịch trình công sức lao động chuyên sâu. Trừ khi sự khuyến khích cụ thể được cung cấp để đánh vào toàn bộ lịch trình, các dự án hiếm khi thực hiện tốt hơn kế hoạch đã đặt ra. Tại sao vậy? Đồng đội và các cá nhân thực hiện kế hoạch con (một phần kế hoạch) để gặp nhau ở các mục tiêu chung của họ. Nếu mục tiêu thời gian là không khắt khe, họ sử dụng hết nguồn năng lượng ở một nơi nào đó (trong đào tạo từ xa, những sự giúp đỡ khác, hay sử dụng vào mục đích ngu ngốc) hoặc họ tiếp tục tăng thêm chất lượng vượt xa những gì cần thiết. Hầu hết họ chưa bao giờ đề nghị thực thi nhanh lịch trình. Nếu họ làm , đề nghị của họ hầu như sẽ gặp sự chống đối của các cổ đông khác, người mà đang mong đợi sự đồng bộ hoá. Vì vậy các kế hoạch cần phải mập mờ như nó có thể đạt được. Nhµ qu¶n lý phÇn mÒm, nhµ qu¶n lý kiÕn tróc phÇn mÒm, nhµ qu¶n lý ph¸t triÓn "Dù ¸n nµy ph¶i cã gi¸ trÞ lµ $X ®Ó chiÕn phÇn mÒm, nhµ qu¶n lý ®Þnh th¾ng trong nÒn th−¬ng m¹i nµy" gi¸ phÇn mÒm "§©y lµ sù biÖn hé nµo ®ã vÒ gi¸ trÞ ®ã " M« h×nh chi phÝ C¸c rñi ro, sù lùa chän, tr¶ gi¸, thay thÕ Chi phÝ −íc l−îng Hình 2-3. Tiến trình ước lượng chi phí nổi bật. 33
34. Hầu hết thực tế thế giới sử dụng các mô hình chi phí từ dưới lên (bottom-up) (chứng minh một chi phí đích) nhiều hơn là sử dụng mô hình từ trên xuống (top-down) (ước lượng chi phí "cần"). Hình 2-3 minh hoạ thực hành nổi bật: Nhà quản lý dự án phần mềm định nghĩa chi phí đích của phần mềm, sau đó vận động theo các tham biến và kích thước cho đến khi chi phí đích có thể được bào chữa. Nguyên nhân cơ bản để chi phí đích có thể vượt qua một dự kiến, để thu hút khách hàng tài trợ, để dành được tài trợ của các đoàn thể bên trong, hay để đạt được một vài mục đích khác. Tiến trình được miêu tả ở Hình 2-3 là không hoàn toàn không tốt. Trong thực tế nó là một sự lỗi thời cần thiết để phân tích chi phí rủi ro và để hiểu được sự nhạy cảm và để trả giá một cách khách quan. Nó bắt buộc nhà quản lý phần mềm phải thẩm tra các rủi ro kết hợp với việc đạt được các chi phí đích và để bàn thảo các thông tin này với những cổ đông khác. Kết quả thường là các trạng thái lo lắng khác nhau trong các kế hoạch, các thiết kế, tiến trình, hay các phạm vi đã được đề xuất. Tiến trình này đưa ra một phương tiện truyền bá tốt cho nền tảng của ước lượng và toàn bộ chi phí phân tích. Một bài thực hành được học tập từ trong lĩnh vực là độc lập với các ước lượng chi phí (những điều đó đã được làm bởi những người độc lập trong đội ngũ phát triển) là thường không đúng đắn. Con đường duy nhất để sản sinh ra một ước lượng đúng đắn là để cho một đội quản lý dự án phần mềm và nhà kiến trúc phần mềm, nhà phát triển, và những nhà quản lý kiểm thử có đủ khả năng (giỏi) để ước lượng lặp đi lặp lại vài lần và nhạy cảm trong phân tích. Đội ngũ này phải nắm lấy quyền sở hữu ước lượng chi phí đó cho các dự án thành công. Điều gì cấu thành nên một ước lượng chi phí phần mềm tốt? Câu hỏi dai dẳng này đã được bàn thảo chi tiết ở trong chương 10. Tóm lại, một ước lượng tốt có các thuộc tính sau đây: • Nó đã được hiểu và ủng hộ của nhà quản lý dự án, đội ngũ kiến trúc, đội ngũ phát triển và đội ngũ kiểm tra có trách nhiệm thực thi công việc. • Nó đã được chấp nhận bởi tất cả các cổ đông như sự mập mờ nhưng có thể nhận thức được. • Nó được cơ sở trong một mô hình chi phí phần mềm được định nghĩa tốt với một nền tảng đúng đắn. • Nó được cơ sở trong một cơ sở dữ liệu của dự án có kinh nghiệm phù hợp nó bao gồm những tiến trình tương tự, công nghệ tương tự , môi trường tương tự, yêu cầu chất lượng tương tự, và những con người tương tự. • Nó được định nghĩa đầy đủ chi tiết đến nỗi mà các vùng rủi ro chính của nó đã được nhận biết và khả năng thành công là đánh giá khách quan. 34
35. Sự ngoại suy từ một ước lượng tốt, một quan niệm ước lượng sẽ nhận được từ một mô hình chi phí trưởng thành với một nền tảng kinh nghiệm đã được phản chiếu từ nhiều dự án tương tự đã được thực hiện bởi cùng một đội ngũ với những tiến trình và công cụ trưởng thành tương tự. Mặc dù hoàn cảnh này hiếm khi tồn tại khi một đội ngũ làm dự án bắt tay vào một dự án mới, những ước lượng tốt có thể đạt được trong một cách thức thẳng thắn trong pha vòng đời muộn hơn của một dự án chín muồi sử dụng một tiến trình chín muồi. 35
36. Chương 3 Cải tiến kinh tế phần mềm Những điểm chính: ¾ Công nghệ phần mềm hiện đại cho phép các hệ thống được xây dựng với các dòng tài nguyên sinh ra từ nhiều người hơn. ¾ Các tiến trình hiện đại lặp đi lặp lại ¾ Sự phát triển phần mềm và môi trường bảo quản hiện đại là sự phân chia máy móc cho tiến trình tự động. Sự cải tiến trong phát triển kinh tế phần mềm không chỉ khó đạt được mà còn khó đo đạc và chứng minh. Trong các sách phần mềm, các báo thương mại, và các sản phẩm văn học, sự bàn luận về chủ đề này được quấy đảo bởi những biệt ngữ trái ngược, những đơn vị đo đạc trái ngược, sự bất đồng giữa các chuyên gia, và những lời cường điệu không dứt. Nếu chúng ta thẩm tra bất kỳ một khía cạnh nào của sự cải tiến kinh tế phần mềm, thì chúng ta cũng kết thúc trên những kết luận khá hẹp và một sự quan sát được giới hạn giá trị. Tương tự, nếu một tổ chức chú trọng quá nhiều vào cải tiến một khía cạnh của tiến trình phát triển phần mềm, thì sẽ không nhận ra bất kỳ một sự cải tiến kinh tế có ý nghĩa nào thậm chí nó chỉ cải tiến một khía cạnh đẹp mắt đó. Chìa khóa để chứng minh sự cải tiến là sự tấn công cân bằng vào một vài quan hệ định hướng. Tôi có cơ cấu trình bày các định hướng quan trọng xung quanh 5 tham số cơ bản của mô hình chi phí phần mềm đã trình bày trong chương 2. 1. Giảm kích thước hoặc sự phức tạp của những điều cần thiết cho phát triển. 2. Cải tiến tiến trình phát triển. 3. Sử dụng nhiều hơn những nhân viên lành nghề và đội ngũ lao động tốt hơn (không cần thiết những điều tương tự). 4. Sử dụng môi trường tốt hơn (công cụ để tự động hóa tiến trình). 5. Trả giá hoặc không lùi (hạ thấp) giới hạn điểm khởi đầu chất lượng. Những tham số đưa ra theo thư tự ưu tiên đối với hầu hết các phần mềm. Bảng 3-1 là danh sách một vài công nghệ phát triển, nỗ lực cải tiến tiến trình và quản lý cách tiếp cận mục tiêu trong cải tiến kinh tế của sự phát triển phần mềm và sự tích hợp. Hầu hết các chuyên gia phần mềm đều công nhận tính độc lập có ý nghĩa giữa các chiều hướng này. Ví dụ, các công cụ cho phép kích thước giảm xuống và sự cải tiến tiến trình,sự giảm kích thước sẽ dẫn tới tiến trình bị thay đổi và sự cỉa tiến tiến trình sẽ tác động đến công cụ yêu cầu. Xem như là miền của phần mềm giao diện người dùng. Trong 2 thập kỷ qua, các đội ngũ đang phát triển một giao diện người dùng đã tiêu tốn một thời gian phân tích thao tác 36
37. và nhân tố con người rộng lớn, cách bày hcí màn chắn, và màn chắn động. Tất cả những điều này đã được làm trên giấy, bởi vì nó cực kỳ đắt giá nếu phạm vào thiết kế, thậm chí nó không hợp lệ với các mẫu gốc, để có thể thực hiện mã hóa được. Vì thế tiến trình được nhấn mạnh một cách khá nặng nề trong các tạo tác sớm trên giấy và hoà hợp người dùng, vì vậy "những yêu cầu" này có thể bị đóng băng và các chi phí xây dựng cao có thể trở nên nhỏ nhất. Bảng 3-1. Các chiều hướng quan trọng trong cải tiến kinh tế phần mềm. Các tham số mô hình chi phí Các chiều hướng Kích thước Các ngôn ngữ trật tự bậc cao (C++, Sự trừu tượng và các thành phần Ada 95, Java, Visual Basic ) công nghệ phát triển cơ bản Hướng đối tượng (phân tích, thiết kế , lập trình) Tái sử dụng Các phần tử thương mại. Tiến trình Lặp lại sự phát triển Các phương pháp và kĩ thuật Tiến trình các mô hình chín muồi Kiến trúc phát triển đầu tiên Cải tổ đạt được Đội ngũ nhân viên Đào tạo và phát triển đội ngũ lao Các nhân tố con người động lành nghề Đội ngũ công nhân Chiến thắng các yếu tố văn hoá Môi trường Tích hợp các công cụ (mô hình trực quan, bộ dịch, người biên tập, Các công nghệ và công cụ tự động hoá người gỡ rối, quản lý thay đổi ) Các hệ thống mở Hiệu năng nền phần cứng Tự động hoá lập trình, tài liệu, kiểm thử, phân tích Chất lượng Hiệu năng nền phần cứng Hiệu năng, độ tin cậy, tính đúng Luận chứng cơ sở đánh giá đắn Điều chỉnh chất lượng thống kê 37
38. Công nghệ giao diện người dùng đồ hoạ (GUI - Graphical User Interface) là một ví dụ tốt về các công cụ cho phép một điều mới và một tiến trình khác. Khi công nghệ GUI đã chín muồi, quy trình giao diện người dùng truyền thống đã trở nên lỗi thời. Người xây dựng công nghệ GUI đã cho phép đội ngũ kỹ thuật xây dựng một giao diện người dùng có thể được thực hiện nhanh hơn và chi phí thấp hơn. Những mô tả trên giấy bây giờ đã không cần thiết nữa, trong thực tế chúng là một trở lực đối với hiệu năng của tiến trình. Các thao tác phân tích và nhân tố con người phân tích vẫn còn quan trọng, nhưng những hoạt động này hiện nay đã được làm trong môi trường mục tiêu thực tế sử dụng những cái nguyên thuỷ sẵn có và những nền tảng đang xây dựng. Kỹ thuật và các vòng phản hồi mà được sử dụng để làm trong hàng tháng trước đây thì nay có thể được làm trong ngày hoặc tuần. Tiến trình cũ đã ăn khớp theo hướng bảo đảm giao diện người dùng đã hoàn toàn được phân tích và thiết kế, bởi vì dự án chỉ có đủ cho một vòng xây dựng. Tiến trình đã ăn khớp theo hướng tạo nên giao diện người dùng qua một vài phiên bản thực tế, hợp nhất tất cả phản hồi người dùng theo quá trình và đạt được một hiểu biết ổn định về các yêu cầu và thiết kế phát sinh để cân bằng với một quá trình khác. Có thể khẳng định rằng tiến trình tiên tiến ( như sự cần thiết đối với sự lặp lại và sự thử nghiệm trong việc định nghĩa các giao diện người dùng ) đã điều khiển sự phát triển của các công cụ, hay các công nghệ tiên tiến đã làm tiến trình thay đổi. Thực tế có thể là hỗn hợp của cả hai. Điều đó nói lên rằng năm tham biến cơ bản của sự cân bằng ước lượng chi phí là không qua lại riêng biệt, chúng cũng không độc lập với cái khác. Chúng có một sự quan hệ qua lại. Một nhân tố quan trọng khác đã có ảnh hưởng đến sự cải tiến công nghệ phần mềm, ở một mặt khác là sự nâng cấp hiệu năng phần cứng. Sẵn có nhiều chu kỳ hơn, nhiều bộ nhớ hơn, và nhiều dãy tần số trong băng hơn đã loại bỏ nhiều tài nguyên phần mềm thực hiện phức tạp. Đơn giản hơn, những giải pháp bắt buộc mạnh mẽ giờ đây là có thể chấp nhận được, và sự cải tiến phần cứng có thể được cho phép nâng cấp sau hầu hết những cải tiến công nghệ phần mềm thực chất. 3.1 Giảm kích thước sản phẩm phần mềm Cách có ý nghĩa nhất để có thể cải tiến và có thành quả đầu tư (ROI) là thường xuyên sản xuất một sản phẩm mà đạt được mục tiêu thiết kế với một tổng phí tài nguyên vật chất sinh ra của con người thấp nhất. Sự phát triển thành phần cơ bản được giới thiệu ở đây như giới hạn chung cho việc giảm kích thước ngôn ngữ "nguồn" cần thiết để đạt được giải pháp phần mềm. Việc tái sử dụng công nghệ hướng đối tượng, tự động hoá sự sản xuất chương trình và ngôn ngữ lập trình thứ tự bậc cao là toàn bộ trọng tâm trong việc đạt được hệ thống với ít dòng tài nguyên trực tiếp của con người hơn (lời phát biểu). Sự giảm kích thước này là động cơ thúc đẩy chính sau những sự cải tiến trong các ngôn ngữ thứ tự bậc cao (như là C++, Ada 95, Java, Visual Basic, và các ngôn ngữ thế hệ thứ 4), các bộ sinh mã tự động (các công cụ CASE (Computer Aid Software Engineering - Công nghệ phần mềm có máy tính hỗ trợ), các công cụ 38
39. làm mô hình trực quan, người xây dựng GUI (giao diện người dùng đồ hoạ)), tái sử dụng các thành phần thương mại (hệ điều hành, môi trường cửa sổ, hệ quản trị cơ sở dữ liệu, thiết bị trung gian, mạng máy tính) và công nghệ hướng đối tượng (ngôn ngữ làm mẫu thống nhất, các công cụ làm mẫu trực quan, kiến trúc các khung công việc). Một sự báo trước đã được chứng nhận khi đang bàn luận sự giảm xuống của kích thước sản phẩm. Trên bề mặt, sự giới thiệu này xuất phát từ một sự quan sát đơn giản: Mã không ở đó thì không cần được phát triển và không thể bị hỏng. Nhưng đây là nhánh không toàn vẹn. Sự giảm xuống được định nghĩa trong giới hạn tài nguyên vật chất được sinh ra của con người. Nhìn chung khi các công nghệ làm giảm kích thước được sử dụng, thì chúng làm giảm số lượng dòng tài nguyên được sinh ra của con người. Tuy nhiên, tất cả chúng quay về tăng tổng số tiến trình có thể thực hiện mã hoá trên máy tính. Vì vậy phần đầu tiên của sự quan sát phải là đúng, nhưng phần hai thì không nhất thiết phải đúng. Dòng dưới cùng, như kinh ngiệm của nhiều đội làm dự án, là sự chín muồi và các công nghệ giảm kích thước đáng tin cậy là cực kỳ mạnh mẽ trong việc sản sinh lợi nhuận kinh tế. Những công nghệ giảm kích thước chưa chín muồi có thể giảm sự phát triển kích thước nhưng đòi hỏi nhiều sự đầu tư để đạt được các mức chất lượng và hiệu năng cần thiết đến nỗi mà chúng có một tác động phản tác dụng lên toàn bộ hiệu năng dự án. 3.1.1 Các ngôn ngữ Toàn bộ các điểm chức năng (UFPs) là những nhà ước lượng hữu dụng đối với ngôn ngữ độc lập, các ước lượng vòng đời sớm. Đơn vị cơ bản của các điểm chức năng là các đầu vào của người dùng bên ngoài, các đầu ra bên ngoài, các nhóm dữ liệu logic bên trong, các giao diện dữ liệu bên ngoài và các yêu cầu bên ngoài. Các phương pháp đo SLOC là những nhà ước lượng hữa dụng đối với phần mềm sau một giải pháp ứng cử đã được làm thành công thức và một ngôn ngữ thực thi đã biết. Dữ liệu quan trọng đã được tài liệu hoá quan hệ SLOC với các điểm chức năng [Jones, 1995]. Một vài kết quả này được trình bày trong bảng 3-2. Dữ liệu trong bảng minh hoạ tại saolại quan tâm đến các ngôn ngữ hiện đại như là C++, Ada 95, Java, và Visual Basic: Mức độ có thể biểu diễn được là rất hấp dẫn. Tuy nhiên, sự bảo Bảng 3-2. Tính xúc cảm ngôn ngữ của một vài ngôn ngữ phổ biến ngày nay. Ngôn ngữ SLOC trên UFP ( Điểm chức năng ) Assembly 320 C 128 FORTRAN 77 105 39
40. COBOL 85 91 Ada 83 71 C++ 56 Ada 95 55 Java 55 Visual Basic 35 dưỡng phải được tạo ra để áp dụng vào các dữ liệu này bởi vì nhiều khả năng có thể bị lạm dụng. Trong khi tôi tin rằng dữ liệu đúng đắn trình bày lại một mối quan hệ quan trọng, những số nhiều một cách quá rõ ràng. ( Chúng không thắc mắc sự rõ ràng trung bình của một vài số không rõ ràng). Mỗi một ngôn ngữ có một miền sử dụng. Visual Basic rất diễn cảm (expressive)và mạnh mẽ trong xây dựng các ứng dụng tương tác đơn giản, nhưng nó không phải là sự lựa chọn khôn ngoan đối với một chương trình thời gian thực, chương trình nhúng, chương trình khoa học điện tử áp dụng vào hàng không. Tương tự, Ada 95 có thể là ngôn ngữ tốt nhất đối với một hệ thống chi phí lỗi thảm khốc mà điều khiển một kế hoạch năng lượng hạt nhân, nhưng nó không phải là sự lựa chọn tốt nhất đối với các chương trình song song cao, chương trình khoa học, chương trình xử lý số chạy trên siêu máy tính. Dữ liệu công nghiệp phần mềm như vậy, cái mà mở rộng các miền ứng dụng, các tập đoàn, và những phát sinh công nghệ phải được diễn dịch và đươc sử dụng với sự bảo dưỡng rất lớn. Hai sự quan sát thú vị trong dữ liệu có liên quan khác nhau và mối quan hệ giữa Ada 83 và Ada 95, và giữa C và C++. Điều thú vị của Cục bảo vệ (DOD- Department of Defense) trong phát triển Ada 83 đã thừa hưởng trong phần để tăng tính tính diễn cảm (expressiveness) của nó. (Những nguyên nhân khác bao gồm tính tin cậy, sự ủng hộ đối với chương trình thời gian thực, tính có thể bảo trì được, và cải tiến ROI qua ngôn ngữ tiêu chuẩn hoá). Một sự thúc đẩy kinh tế có ý nghĩa là khả năng để phát triển một chương trình trong thực tế với số dòng mã hóa ít hơn đòi hỏi lựa chọn trong ngôn ngữ truyền thống như là FORTRAN, COBOL, C, và hợp ngữ (asembly). Biểu hiện trong ngôn ngữ Ada là nhiều công nghệ kỹ thuật phần mềm tiên tiến, bao gồm ngôn ngữ làm cho được cấu hình điều khiển, sự chia cắt giao diện, và sự thực thi, kiến trúc điều khiển nguyên thuỷ, sự tóm tắt, sự ủng hộ đồng thời, và nhiều thứ khác. Ada 95 trình bày một sự nâng cấp ngôn ngữ có kế hoạch tốt để điều tiết công nghệ mới và kết hợp các bài đã học trong một khía cạnh ứng dụng. Điều khác biệt trong tính có thể xúc cảm giữa Ada 83 và Ada 95 là thừa hưởng chủ yếu để những nét đặc trưng được thêm vào để bổ xung chương trình hướng đối tượng. Theo đó, một sự ước lượng giá trị của chương trình hướng đối tượng có thứ tự đầu tiên mà nó cho phép các chương trình được viết giảm đi 30% dòng nguồn. 40
41. Sự khác biệt giữa C và C++ thậm chí còn sâu sắc hơn. C++ kết hợp một vài (mặc dù không kết hợp toàn bộ) với sự hỗ trợ các tiến bộ tốt của Ada cho chương trình hướng đối tượng. Tuy nhiên, C++ cũng đã phát triển để hỗ trợ C như một bộ con. Yêu cầu này có chiều thuận và chiều nghịch. Trên một phương diện, tính tương hợp của C làm cho nó rất rễ đối với những nhà lập trình C chuyển sang C++. Trên một phương diện khác, một xu hướng đáng chú ý trong công nghiệp là một số lượng đông đảo các nhà lập trình sử dụng bộ dịch C++ nhưng bộ óc chương trình là C, vì thế thiếu sót này chấp nhận tính nhạy cảm của C++ hướng đối tượng. Sự tiến triển của Java đã loại trừ nhiều vấn đề của ngôn ngữ C++ (đặc trưng tự nhiên là hỗ trợ đối với C, hỗ trợ một vài chương trình thực hành nguy hiểm) trong khi bảo vệ các đặc trưng hướng đối tượng và cộng thêm những hỗ trợ xa hơn đối với tính khả chuyển và sự phân phối. Toàn bộ các điểm chức năng có thể được sử dụng để chỉ ra kích thước chương trình quan hệ được yêu cầu được thực thi một chức năng đưa ra. Ví dụ, để đạt được một ứng dụng được đưa ra với một số lượng hỗn hợp các điểm chức năng, một kích thước chương trình như sau có thể đòi hỏi: 1.000.000 dòng hợp ngữ 400.000 dòng ngôn ngữ C 220.000 dòng ngôn ngữ Ada 83 175.000 ngôn ngữ Ada 95 hoặc C++. Các giá trị biểu thị mối quan hệ nhạy cảm được đưa ra bởi nhiều ngôn ngữ khác nhau. Các thành phần thương mại và các bộ sinh mã tự động (như là công cụ CASE và những người xây dựng GUI) có thể làm giảm nhiều hơn kích thước chương trình nguồn sinh ra bởi con người, lần lượt giảm kích thước đội ngũ làm dự án và thời gian cần cho sự phát triển. Mở rộng ví dụ này ra, thêm vào một hệ quản trị cơ sở dữ liệu thương mại, người xây dựng GUI thương mại, và trung gian thương mại có thể làm giảm kích thước kết quả của sự phát triển xuống kích thước cuối cùng sau đây: 75000 dòng ngôn ngữ Ada 95 hoặc C++ cộng với sự tích hợp của một vài thành phần thương mại. Bởi vì sự khác nhau giữa các dự án lớn và dự án nhỏ là lớn hơn đường tác động trong vòng đời chi phí, việc sử dụng ngôn ngữ bậc cao nhất và để dành các phần tử thương mại có một tiềm năng tác động lớn đối với chi phí. Hơn nữa, đơn giản hơn là tính tổng quan tốt hơn: Sự giảm kích thước thường làm tăng khả năng có thể hiểu được, tính có thể thay đổi được, và tính có thể tin cậy được. Một kết quả mặt trái điển hình là mức trừu tượng cao hơn các công nghệ hướng về sự suy biến hiệu năng, tăng sự tiêu thụ tài nguyên như là chu kì bộ xử lý, bộ nhớ, và bề dày các băng thông tin. Hầu hết những trở ngại này sẽ được vượt qua bởi sự cải tiến hiệu năng phần cứng và một cái nhìn lạc quan. Những cải tiến này kém xa hiệu quả trong các nền nhúng. 41
42. 3.1.2.Các Phương pháp hướng đối tượng và mẫu trực quan Đã có một sự chuyển động rộng lớn trong những năm 90 hướng tới công nghệ hướng đối tượng. Tôi sử dụng rất ít thời gian trong chủ đề này bởi vì công nghệ hướng đối tượng không thích hợp với hầu hết các chủ đề quản lý phần mềm được bàn luận ở đây, và có rất nhiều sách nói về công nghệ hướng đối tượng. Một vài nghiên cứu đã kết luận rằng sự xuất hiện các ngôn ngữ chương trình hướng đối tượng đã làm lợi cho cả các sản phẩm phần mềm và chất lượng phần mềm [Jones, 1994], nhưng lợi ích kinh tế vẫn chưa được chứng minh bởi vì chi phí sườn dốc của việc đào tạo trong các phương pháp thiết kế hướng đối tượng như Ngôn ngữ mẫu kết hợp (UML - Unified Modeling Language). Từ việc cung cấp nhiều ký hiệu chính thức hoá hơn cho việc nắm được và hình dung được sự trừu tượng của phần mềm, tác động nền tảng của công nghệ hướng đối tượng là trong việc giảm toàn bộ kích thước của những gì cần được phát triển. Booch đã mô tả 3 lý do khác mà chắc chắn các dự án hướng đối tượng sẽ thành công [Booch, 1996]. Có một ví dụ thú vị về những mối tương quan giữa các chiều hướng cải tiến kinh tế phần mềm. (Các đoạn được trình bày in nghiêng.) 1. Một vấn đề về mô hình hướng đối tượng và giải pháp của nó khuyến khích một từ vựng chung giữa những người dùng cuối cùng của hệ thống và những người phát triển nó, do đó việc tạo ra một sự chia sẻ kiến thức về vấn đề là cần được giải quyết. ¾ Đây là một ví dụ về công nghệ hướng đối tượng nào đó cho phép những sự cải tiến phù hợp trong việc kết hợp (chung sức) và thông tin giữa các cá nhân với nhau. 1. Việc sử dụng sự tích hợp tiếp theo tạo nên sự hài hoà để nhận ra rủi ro sớm và làm tăng những sửa chữa thiếu tính không ổn định toàn vẹn công sức phát triển. ¾ Khía cạnh này của công nghệ hướng đối tượng cho phép một kiến trúc tiến trình đầu tiên, nơi mà sự tích hợp là một vòng đời hoạt động sớm và một vòng đời tiếp theo. 2. Một kiến trúc hướng đối tượng đưa ra một sự phân chia rõ ràng về sự quan tâm lo lắng giữa các thành phần khác hẳn nhau của hệ thống, tạo nên bức tường lửa chống lại sự thay đổi trong từng phần của hệ thống từ việc phá nát kết cấu của kiến trúc toàn vẹn. ¾ Đặc trưng này của công nghệ hướng đối tượng là tính quyết định cho việc ủng hộ các ngôn ngữ, và các máy tính sẵn có để thực thi các kiến trúc hướng đối tượng. Booch cũng tổng kết 5 đặc điểm của một dự án hướng đối tượng thành công. 42
43. 1. Một trọng tâm tàn nhẫn (ruthless) trong sự phát triển hệ thống là đưa ra một sự lựa chọn kiến thức tốt của các đặc điểm tối thiểu cần thiết. 2. Sự tồn tại của một nền văn hoá là trung tâm trong các kết quả, khuyến khích thông tin, và vẫn chưa sợ thất bại. 3. Hiệu quả sử dụng mô hình hướng đối tượng. 4. Sự tồn tại của một sức nhìn kiến trúc mạnh. 5. ứng dụng của một quản lý lặp lại và việc gia tăng vòng đời phát triển tốt. Các đặc điểm này có ít điều phải làm với sự định hướng đối tượng. Tuy nhiên, các phương pháp hướng đối tượng, các kí hiệu và mẫu trực quan đưa ra công nghệ mạnh trợ giúp cho tiến trình khung công việc. 3.1.3.Tái sử dụng Việc tái sử dụng các thành phần đang có và xây dựng các thành phần có thể tái sử dụng là các hoạt động kỹ thuật phần mềm tự nhiên kể từ khi có những sự cải tiến sớm nhất trong các ngôn ngữ chương trình, các phương pháp thiết kế phần mềm luôn luôn giải quyết một cách tuyệt đối việc tái sử dụng có trật tự để tối thiểu hoá các chi phí phát triển, trong khi đạt được tất cả các thuộc tính yêu cầu khác của hiệu năng, bộ đặc tính, và chất lượng. Việc tái sử dụng đạt được không chỉ đáng quan trọng trong cộng đồng (community) bởi vì chúng ta không làm nó tốt như chúng ta nên làm. Trong toàn bộ các kỹ thuật và kỉ luật sản xuất khác, việc tái sử dụng là nhiều hơn hay ít hơn một giả định ở mức dưới, không cần thiết phải phá bỏ cản trở công nghệ. Tôi cố gắng đề cập tái sử dụng như một phần trần tục của việc đạt được kết quả trong đầu tư. Các kiến trúc chung, các tiến trình chung, kinh nghiệm tiền lệ, và các môi trường chung là tất cả những thí dụ của việc tái sử dụng. Một trong những trở ngại lớn nhất để tái sử dụng là sự vỡ ra từng mảnh của các ngôn ngữ, của hệ điều hành, các kí hiệu, các kiến trúc máy, các công cụ, và thậm chí các "chuẩn." Như một ví dụ trái ngược, mức độ tái sử dụng được tạo ra có thể do sự thành công của Microsoft trên máy PC đã rất rộng lớn. Nhìn chung, nhiều thứ cho phép được tái sử dụng vì các lý do kinh tế. Bởi thế, độ đo chính trong việc nhận diện hoặc một thành phần (hoặc một lớp các thành phần, hoặc một sản phẩm thương mại) đúng là có thể tái sử dụng là để thấy hoặc là một vài tổ chức đang tạo ra tiền bạc trên nó. Không có sự vận động kinh tế này, các thành phần tái sử dụng là rất hiếm. Chú ý việc "mở" các thư viện tái sử dụng được đỡ đầu bởi các tổ chức phi lợi nhuận. Chúng thiếu sự chuyển động kinh tế, tính chất đáng tin cậy, và trách nhiệm giải trình đối với chất lượng, sự ủng hộ, sự cải tiến, và tính sử dụng được. Hầu hết các giá trị của thành phần thực sự có thể tái sử dụng được là việc chuyển thành các sản phẩm thương mại được hỗ trợ bởi các tổ chức với các đặc điểm sau: • Chúng có một sự chuyển động kinh tế đối với sự ủng hộ liên tục. 43
44. • Chúng làm chủ sở hữu sự cải tiến chất lượng sản phẩm, thêm các đặc tính mới, và chuyển sang các công nghệ mới. • Chúng có một khách hàng rộng lớn đủ làm cơ sở để có thể có lợi nhuận. Chi phí phát triển một thành phần có thể tái sử dụng là không tầm thường. Hình 3-1 kiểm tra việc trả giá. Đường cong dốc ban đầu minh hoạ trở lực kinh tế đối với sự phát triển các thành phần có thể tái sử dụng. Sẽ khó để phát triển một nhánh thương mại có tính thuyết phục đối với sự phát triển trừ khi mục tiêu là việc ủng hộ tái sử dụng qua nhiều dự án. Các nhánh thương mại lạc quan hiếm khi xảy ra trong các tổ chức phát triển phần mềm mà không được chú trọng trong việc bán các thành phần thương mại như đường thương mại chính của chúng. Hầu hết các tổ chức không thể tham gia tính kinh tế với các tổ chức thương mại đã thiết lập đầu tư của họ được hoàn trả dần qua người dùng cơ sở. Để đem lại thành công trên thương trường cho các thành phần thương mại, một tổ chức cần 3 yếu tố lâu dài: một nhóm phát triển, một cơ sở hạ tầng hỗ trợ, và một bày bán hướng sản phẩm và một thị trường cơ sở hạ tầng. Một sự ân cần khác là tính phức tạp và chi phí phát triển các thành phần có thể tái sử dụng được thường được đánh giá thấp một cách chất phác. Gi¶i ph¸p nhiÒu dù ¸n: Thao t¸c víi gi¸ trÞ cao trªn ®¬n vÞ ®Çu t−, c¸c s¶n phÈm th−¬ng m¹i ®iÓn h×nh 5 gi¶i ph¸p dù ¸n: trªn 125% chi phÝ vµ trªn 150% thêi gian tµi nguyªn 2 gi¶i ph¸p dù ¸n: trªn 50% chi phÝ vµ 100% thêi gian 1 gi¶i ph¸p dù ¸n: $N vµ M th¸ng Ph¸t triÓn chi phÝ vµ lËp lÞch lÞch lËp vµ phÝ chi triÓn Ph¸t Số dự án sử dụng thành phần có thể tái sử dụng được Hình 3-1.Chi phí và lịch trình đầu tư cần thiết để đạt được các thành phần có thể tái sử dụng được. Mặc dù giá trị tái sử dụng có thể rất rộng lớn, tôi chưa bao giờ là một cổ động viên của việc định danh tái sử dụng như là một ngăn cách "công nghệ". Việc tái sử dụng là một kỷ luật quan trọng, nó có tác động vào khả năng của toàn bộ luồng công việc và chất lượng của hầu hết các tạo tác. Tôi nghĩ nó như sự đồng bộ đối với thành quả trong đầu tư, điều mà sẽ là một sự ân cần trong hầu hết mọi hoạt động và quyết định. Có một vài câu chuyện rất thành công trong việc tái sử dụng các thành phần phần mềm ngoại trừ đối với các sản phẩm thương mại như các hệ điều hành, hệ quản trị cơ sở dữ liệu, bộ trung gian, mạng, người xây dựng GUI, và các ứng 44
45. dụng văn phòng. Trên một phương diện khác, mọi câu chuyện thành công về phần mềm, có lẽ đã khai thác một vài cách tiếp cận chính của việc tái sử dụng (không có việc gọi như vậy) để đạt được những kết quả khả quan. 3.1.4.Các thành phần thương mại Một cách tiếp cận chung đã được theo đuổi ngày nay trong nhiều miền là sự tối đa hoá sự tích hợp các thành phần thương mại và các sản phẩm không lỗi thời. Trong khi việc sử dụng các thành phần thương mại chắc chắn là đáng khao khát như một phương tiện của việc giảm sự phát triển theo tập quán cũ, nó đã không được chứng minh thẳng thắn trong thực hành. Bảng 3- 3 định danh một vài ưu điểm và nhược điểm của việc sử dụng các thành phần thương mại (những trả giá này là là đặc thù khắc nghiệt trong các miền giới hạn nhiệm vụ.). Bởi vì trả giá thường xuyên có hiệu lực rộng lớn trong chất lượng, chi phí, tính có thể hỗ trợ được, và sự lựa chọn các thành phần thương mại qua sự phát triển của các thành phần tập quán (cũ-custom) có ý nghĩa tác động vào toàn bộ kiến trúc của một dự án. Thông báo cực cao ở đây (được bàn luận xâu hơn ở trong chương 7) là những quyết định này phải được tạo ra sớm trong vòng đời như một phần của kiến trúc thiết kế. Bảng 3-3. Các ưu điểm và nhược điểm của các thành phần thương mại chống lại phần mềm truyền thống. Cách tiếp Ưu điểm Nhược điểm cận Thường xuyên nâng cấp Các thành Khả năng dự đoán đăng ký chi phí Trả trước đăng kí thù lao phần Được sử dụng rộng rãi, công Định kỳ bảo trì thù lao thương mại nghệ chín muồi Tính phụ thuộc vào người bán Sẵn có ngày nay Hy sinh hiệu xuất thời gian chạy Tổ chức ủng hộ tận tâm Sự ép buộc chức năng Phần cứng/ Phần mềm độc lập Sự tích hợp luôn không tầm thường Sự phong phú của chức năng Không điều khiển trên những nâng cấp và bảo trì Các đặc trưng không cần thiết tiêu thụ hết các tài nguyên phụ Thường không đầy đủ độ tin cậy và độ ổn định Tính không tương hợp đa người bán Tập quán Hoàn thiện thay đổi tự do Đắt, không có khả năng dự đoán sự phát phát triển Nhỏ hơn, thường đơn giản hơn triển sự thực thi Không có khả năng dự đoán ngày sẵn có Hiệu năng thường tốt hơn Không định nghĩa được mô hình bảo trì Điều khiển sự phát triển và nâng Thường không chín muồi và dễ hỏng cao Tiêu phí nguồn tài nguyên chuyên môn 45
46. 3.2.Cải tiến các tiến trình phần mềm Tiến trình là một thời kỳ đặt quá tải. Đối với các tổ chức hướng phần mềm, có nhiều tiến trình và tiến trình con. Tôi sử dụng 3 tiến trình riêng biệt có triển vọng. • Siêu tiến trình (metaprocess): những kiểm soát, thủ tục, và thực hành của một tổ chức đối với sự theo đuổi một tuyến phần mềm chuyên sâu trong thương mại. Trọng tâm của tiến trình này là trong tổ chức kinh tế, các chiến lược dài hạn, và một ROI phần mềm. • Đại tiến trình (macroprocess): những kiểm soát, thủ tục, và thực hành của một dự án đối với việc sản xuất một phần mềm hoàn thiện, ở trong chi phí chắc chắn, lịch trình và sự cưỡng ép chất lượng. Trọng tâm của đại tiến trình là trong việc tạo ra một thí dụ đầy đủ của siêu tiến trình đối với một bộ ép buộc cụ thể. • Tiểu tiến trình (microprocess): những kiểm soát, thủ tục, và thực hành của một đội làm dự án đối với việc đạt được một tạo tác của tiến trình phần mềm. Trọng tâm của tiểu tiến trình là trong việc đạt được một đường danh giới sản phẩm trung gian với đầy đủ chất lượng và đầy đủ chức năng về phương diện kinh tế và nhanh chóng đi vào thực hành. Mặc dù 3 mức tiến trình chồng chéo lên nhau một phần nào đó, nhưng chúng có các mục tiêu, độc giả, độ đo, sự liên quan và nấc thang thời gian khác nhau như trình bày trong bảng 3- 4. Đại tiến trình là tiến trình mức dự án mà hiệu quả mô hình chi phí ước lượng đã được bàn luận trong chương này. Để đạt được sự thành công, hầu hết các dự án phần mềm đều yêu cầu một mớ phức tạp khó tin nổi của các bước nối tiếp và song song. Như tỉ lệ của một dự án tăng lên, nhiều bước trên phải bao gồm việc quản lý mớ phức tạp này. Tất cả các tiến trình dự án trùng khớp của các hoạt động sản xuất và hoạt động trên. Kết quả các hoạt động sản xuất trong các tiến trình thực tế hướng tới sản phẩm cuối cùng. Đối với các công sức phần mềm, các hoạt động này bao gồm tạo mẫu, mô hình hoá, mã hoá, gỡ rối, và cung cấp tài liệu người dùng. Các hoạt động trên có một tác động thực tế vào sản phẩm cuối cùng đã được yêu cầu trong sự chuẩn bị kế hoạch, sự cung cấp tài liệu, tiến trình giám sát, sự ước định rủi ro, sự ước định tài chính, điều khiển cấu hình, sự ước định chất lượng, tích hợp, kiểm thử, phế thải muộn (loại bỏ những thứ không tốt ở giai đoạn muộn) và sửa lại (thiết kế lại), quản lý, đào tạo nhân lực, điều hành thương mại, và nhiều nhiệm vụ khác. Các hoạt động trên bao gồm nhiều nỗ lực thêm các giá trị, nhưng nhìn chung, nỗ lực (công sức) nhỏ hơn đã cống hiến cho các hoạt động này, nỗ lực lớn hơn có thể được dùng (tiêu tốn) trong các hoạt động sản xuất. Mục tiêu của việc cải tiến tiến trình là tối đa hoá việc phân phối các tài nguyên cho các hoạt động sản xuất và tối thiểu hoá tác động của các hoạt động trên vào các tài nguyên như nguồn nhân lực, máy tính và lịch trình. 46
47. Bảng 3-4. Ba mức tiến trình và các thuộc tính của nó. Thuộc tính Siêu tiến trình Đại tiến trình Tiểu tiến trình Chủ đề Tuyến thương mại Dự án Tích hợp Mục tiêu Lợi nhuận tuyến Lợi ích dự án Quản lý tài nguyên thương mại Quản lý rủi ro Sự giải quyết rủi ro Tính cạnh tranh Ngân sách dự Mốc (quan trọng) ngân án,lịch trình, chất sách, lịch trình, chất lượng lượng Độc giả Giành được nhà Những nhà quản lý Những nhà quản lý dự cầm quyền, khách dự án phần mềm án con hàng Các kỹ sư phần Các kỹ sư phần mềm Quản lý tổ chức mềm Độ đo Khả năng dự đoán Trong ngân sách, Trong ngân sách, trong dự án trong lịch trình lịch trình Thu nhập, chia sẻ Mốc thành công Mốc tiến bộ chính thị trường chính Giải thoát/tích hợp phế Phế thải dự án và thải và sửa lại sửa lại Lợi lộc Thói quan liêu Chất lượng chống Nội dung chống lại lập (liên quan) chống lại sự tiêu lại hiệu năng tài lịch chuẩn hoá chính Tỉ lệ thời 6 đến 12 tháng 1 đến nhiều năm 1 đến 6 tháng gian Một vài người có thể bị làm bực dọc bởi sự phân loại của tôi về phế thải muộn, việc sửa lại và đào tạo nhân lực như các hoạt động trên cần được tối thiểu hoá. Tôi đã giảm bớt phế thải và sửa lại muộn để tạo sự khác biệt giữa nó với phế thải và sửa lại thường, phế thải và sửa lại thường là một sản phẩm tư nhiên của công sức tạo mẫu ban đầu (mẫu gốc). Phế thải và sửa lại sớm là một quá trình xảy ra tất yếu đối với hầu hết các dự án để giải quyết vô số những điều xa lạ (không ai biết) trong không gian giải pháp, nhưng rõ ràng là không ai ưa thích nó trong những pha muộn hơn của vòng đời. Với một tiến trình tốt, nó rõ ràng là không cần thiết. Người ta sẽ khẳng định rằng đào tạo nhân lực không thể là một điều tồi tệ, nhưng đó là đối với dự án. Việc đào tạo là một trách nhiệm tổ chức, không phải là trách nhiệm dự án. Bất kì một nhà quản lý dự án nào mà mang gánh nặng đào tạo con người trong các tiến trình, các công nghệ, và các công cụ sẽ thấy tồi hơn một nhà quản lý dự án mà đã được đào tạo công việc đầy đủ. Việc cung cấp cho dự án một sự đào tạo công việc đầy đủ có thể là điều không thể thực hiện nhưng công việc đào tạo con người luôn tốt hơn việc không đào tạo con người, những điều khác giữ nguyên. Trong cảm nhận này việc đào tạo không được xem là một hoạt động thêm giá trị. 47