Frederick nghiên cứu về tháng con người thần thoại hoặc cách hệ thống phần mềm được tạo ra. Các luận điểm ngắn gọn từ cuốn sách "The Mythical Man-Month, or How Software Systems Are Created

The Mythical Man-Month, hay Cách các hệ thống phần mềm được tạo ra bởi Frederick Brooks là một cuốn sách cần phải đọc đối với mọi lập trình viên. Nó được xuất bản vào năm 1975, nhưng không hề mất đi tính liên quan của nó.

Tôi đã xem qua cuốn sách này vào đúng thời điểm. Tôi vừa tốt nghiệp đại học và bắt đầu làm lập trình viên. Nó rất khó khăn trong thời gian đầu. Có rất ít sách CNTT hồi đó. Tôi đọc cuốn sách này trong thư viện, nó khá tồi tàn. Và tôi đã rất ngạc nhiên về việc nó chứa đựng bao nhiêu giá trị. Những lời khuyên của Brooks đã giúp tôi rất nhiều trong thời kỳ đầu của sự nghiệp. Và cuốn sách này đặc biệt hữu ích khi bản thân tôi bắt đầu dẫn dắt các lập trình viên.

Fredericks Brooks làm việc tại IBM và giám sát sự phát triển của hệ điều hành System / 360. Vào thời điểm đó, nó là dự án phần mềm lớn nhất trên thế giới. Trong quá trình làm việc, khó khăn bất ngờ nảy sinh. Brooks là một người tinh ý và hiểu được bản chất của những khó khăn này. Ông đã có thể hình thành các nguyên tắc cơ bản của phát triển phần mềm giúp phân biệt lập trình với các ngành khác.

Những nguyên tắc này là gì?

Kết luận chính, mà ông gọi là định luật Brooks, là:

Nếu dự án lập trình không đáp ứng thời hạn, thì việc bổ sung nhân lực sẽ chỉ làm trì hoãn việc hoàn thành của nó.

Luật này thường được minh họa như sau: “Dù có chín người phụ nữ tụ họp lại thì cũng không thể sinh con trong một tháng”.

Do đó, tiêu đề của cuốn sách. Trong các ngành công nghiệp khác, việc tăng số lượng nhân viên cho phép thực hiện công việc nhanh hơn. Mười máy đào nhanh hơn năm. Nhưng kỳ lạ thay, mười lập trình viên sẽ làm việc chậm hơn năm người.

Phương pháp của Wirth

Theo Brooks, phương pháp phát triển phần mềm tốt nhất là Niklaus Wirth, tác giả của ngôn ngữ Pascal.

Theo Virtue, thiết kế được coi là một chuỗi các bước làm rõ dự án. Đầu tiên, một công thức thô của vấn đề được phác thảo và một phương pháp thô cho giải pháp của nó được đề xuất, giúp chúng ta có thể có được một câu trả lời cơ bản. Hơn nữa, mô tả được biên soạn chi tiết hơn, cho phép bạn thấy rằng kết quả khác với mong muốn. Các bước giải pháp lớn được chia thành các bước nhỏ hơn.

Đó là phương pháp phát triển phần mềm mà tôi đã áp dụng và trong nhiều năm, nó đã giúp tôi viết các chương trình hiệu quả hơn.

Phương pháp này có một tính năng hữu ích khác. Bạn có thể nhanh chóng phác thảo bố cục của một chương trình làm việc và nói chuyện với khách hàng một cách chi tiết. Bởi vì khách hàng của chương trình hoàn toàn không biết chính xác điều gì sẽ xảy ra cuối cùng. Gói tối thiểu giải quyết vấn đề này.

OOP là một căn bệnh

Trong cuốn sách này, lần đầu tiên tôi đọc được một ý kiến ​​phản biện về công nghệ phát triển phần mềm hướng đối tượng đang là mốt thời đó.

Theo tôi, các phương pháp luận hướng đối tượng có một trường hợp đặc biệt xấu là căn bệnh vốn có nhiều cải tiến trong phương pháp luận. Có một khoản chi phí trả trước đáng kể - chủ yếu là để dạy các lập trình viên suy nghĩ theo một cách hoàn toàn mới, cũng như chuyển đổi các hàm thành các lớp chung chung.

Gọi OOP là một căn bệnh nghiêm trọng - lúc đó rất táo bạo, nhưng sau đó tôi đã nhiều lần bị thuyết phục về tính đúng đắn của chẩn đoán này. Bởi vì chi phí lập trình OOP lớn hơn nhiều lần so với những lợi ích nhỏ.

Các bản sửa lỗi làm rối loạn chương trình

Khi một lập trình viên đưa ra bản phát hành chương trình, những người dùng biết ơn ngay lập tức bắt đầu yêu cầu các tính năng mới. Có vẻ như điều này là tốt. Nhưng không phải mọi thứ đều đơn giản như vậy. Mọi người có quan điểm rất khác nhau về cách một chương trình nên phát triển. Vì vậy, có mọi khả năng là chương trình sẽ nhanh chóng biến thành một con quái vật vụng về bị nhồi nhét đầy lỗi.

Lehman và Beladi đã nghiên cứu lịch sử của các bản phát hành liên tiếp của một hệ điều hành lớn. Họ tin rằng tổng số mô-đun tăng tuyến tính với số phiên bản, nhưng số mô-đun bị ảnh hưởng tăng theo cấp số nhân với số phiên bản. Tất cả các bản sửa lỗi đều có xu hướng phá hủy cấu trúc, tăng entropi và làm mất tổ chức hệ thống. Ngày càng ít nỗ lực được dành cho việc sửa lỗi trong dự án ban đầu, và ngày càng nhiều năng lượng được dành cho việc loại bỏ hậu quả của các lần sửa trước đó.

Tốt hơn là trình bày rõ ràng các yêu cầu đối với chương trình và thực hiện chúng. Vì vậy, chương trình làm một việc, nhưng làm tốt điều đó.

Tôi không cho rằng tất cả những thay đổi trong mục tiêu và yêu cầu của khách hàng có thể hoặc cần được tính đến trong dự án. Rõ ràng, phải có một ngưỡng quy định và phải ngày càng cao khi quá trình phát triển tiến bộ, nếu không sẽ không có sản phẩm nào được tạo ra.

Năng suất của lập trình viên thay đổi đáng kể

Lần đầu tiên các lập trình viên có năng suất khác biệt đáng kể, tôi đã học được từ cuốn sách của Brooks. Lúc đó tôi không tin. Nhưng cuộc sống đã hoàn toàn khẳng định vị trí này.

Trong một nghiên cứu, Sackman, Erikson và Grant đã đo lường năng suất của một nhóm lập trình viên có kinh nghiệm. Riêng trong nhóm này, tỷ lệ giữa kết quả tốt nhất và kém nhất là khoảng 10: 1 về năng suất lao động và 5: 1 về tốc độ của chương trình và bộ nhớ cần thiết cho chúng! Nói tóm lại, một lập trình viên kiếm được 20.000 đô la một năm có thể có năng suất cao hơn gấp mười lần so với một lập trình viên kiếm được 10.000 đô la.

Điều này đặc biệt rõ ràng trong gương của các sinh viên. Khi tôi bắt đầu dạy lập trình ở trường đại học, tôi thấy trong các bài kiểm tra rằng một số sinh viên đọc vấn đề và nhanh chóng viết mã hoàn thành, trong khi những người khác có thể tìm hiểu cả một vài cách gỡ lỗi trong một chương trình đơn giản.

Không có viên đạn bạc

Dự báo thú vị nhất của Brooks là trong tương lai gần sẽ không có công nghệ nào có khả năng tăng tốc độ phát triển lên một bậc. Đã nhiều năm trôi qua, và dự đoán của Brooks đã hoàn toàn trở thành sự thật. Giống như bốn mươi năm trước, các lập trình viên viết chương trình bằng tay. Không có công nghệ nào mà bạn gắn đặc điểm kỹ thuật của khách hàng vào và nó sẽ tạo ra mã hoàn chỉnh.

Tất nhiên, tất cả các ý tưởng của Brooks không thể được kể lại. Tôi khuyên bạn nên đọc nó để không dẫm lên nhiều vết rách.

Dành riêng cho hai người đã làm cho những năm tháng của tôi tại IBM trở nên đặc biệt phong phú:

Thomas J. Watson, Jr., người luôn quan tâm sâu sắc đến mọi người trong công ty của mình, và Bob O. Evans, người có khả năng lãnh đạo can đảm đã biến công việc trở thành một cuộc phiêu lưu.

Cống hiến của phiên bản 1995

Dành riêng cho Nancy, món quà của Chúa cho tôi.

Trước sự ngạc nhiên và thích thú của tôi, The Mythical Man-Month vẫn được yêu thích sau 20 năm kể từ khi phát hành. Số lượng phát hành vượt quá 250.000 bản. Tôi thường được hỏi rằng những đánh giá và khuyến nghị nào được trình bày vào năm 1975 mà tôi vẫn tin là đúng, những đánh giá và khuyến nghị nào đã trải qua những thay đổi, và chính xác là những gì. Mặc dù thực tế là trong các bài giảng của tôi vấn đề này thỉnh thoảng được đề cập đến, tôi đã chờ đợi cơ hội để trình bày nó trên bản in từ lâu.

Peter Gordon, hiện là đồng sở hữu của Addison-Wesley, đã kiên nhẫn và có lợi với tôi kể từ năm 1980. Ông đề nghị chuẩn bị một ấn bản năm thánh. Chúng tôi quyết định không sửa bản gốc mà in lại nguyên vẹn, ngoại trừ những bản in sai thông thường, và bổ sung vào đó những suy nghĩ nảy sinh sau này.

Chương 16 tái bản bài báo “Không có viên đạn bạc: Bản chất và tai nạn trong kỹ thuật phần mềm,” do IFIPS (Liên đoàn quốc tế về các hiệp hội xử lý thông tin) xuất bản năm 1986, và là kết quả kinh nghiệm của tôi khi đứng đầu Ủy ban Khoa học Quân sự. Các đồng tác giả của tôi trong nghiên cứu này, cũng như thư ký điều hành của chúng tôi, Robert L. Patrick, đã vô cùng quý giá trong việc giúp tôi quay trở lại với các dự án phần mềm lớn và thực tế. Bài báo đã được in lại trên IEEE "Computer" vào năm 1987, nhờ đó nó được biết đến rộng rãi.

Bài "Không có viên đạn bạc" đã bạc bẽo. Người ta dự đoán rằng trong vòng một thập kỷ tới sẽ không có phương pháp lập trình nào, việc sử dụng chúng sẽ làm tăng năng suất phát triển phần mềm theo một mức độ lớn, tất cả những thứ khác đều như nhau. Còn một năm nữa là hết thập kỷ này, và có vẻ như dự đoán của tôi đã trở thành sự thật. Bài báo đã gây ra nhiều cuộc thảo luận trên báo in hơn The Mythical Man-Month, vì vậy Chương 17 giải đáp một số chỉ trích đã xuất bản và sàng lọc các quan điểm năm 1986.

Trong quá trình phân tích hồi cứu và sàng lọc của The Mythical Man-Month, tôi ngạc nhiên về số lượng tuyên bố mà nó chứa bị chỉ trích, cả được chứng minh và bác bỏ bởi kinh nghiệm và nghiên cứu sau đó trong kỹ thuật phần mềm. Đối với tôi, có vẻ hữu ích khi hệ thống hóa những tuyên bố này ở dạng thuần túy, không kèm theo bằng chứng và dữ liệu. Tôi đã đưa bài luận này vào cuốn sách dưới dạng chương 18, hy vọng rằng những phát biểu thuần túy này sẽ kích hoạt việc tìm kiếm các lập luận và dữ kiện để chứng minh, bác bỏ, sửa đổi hoặc sàng lọc.

Chương 19 thực sự là một nỗ lực để xem xét lại các tuyên bố ban đầu. Người đọc cần được cảnh báo rằng những quan điểm mới đưa ra còn lâu mới được “kinh nghiệm chiến đấu” ủng hộ ở mức độ tương tự như trường hợp trong phần đầu của cuốn sách. Vấn đề là gần đây tôi đang làm việc trong môi trường đại học, không phải ngành công nghiệp, và các dự án quy mô nhỏ hơn là quy mô lớn. Từ năm 1986, tôi chỉ dạy phát triển phần mềm, không nghiên cứu. Công việc nghiên cứu của tôi thiên về môi trường ảo và các ứng dụng của chúng.

Wheeler và Edward Yordon. Fay Ward đã hoàn thành xuất sắc công việc kỹ thuật xuất bản các chương mới.

Tôi biết ơn các đồng nghiệp của tôi tại Nhóm Phần mềm Quân sự của Ủy ban Khoa học Quân sự Gordon Bell, Bruce Buchanan, Rick Hayes-Roth và đặc biệt là David Parnass vì những ý tưởng hiệu quả của họ và Rebekah Bierly, vì đã chuẩn bị cho xuất bản bài báo được xuất bản trong cuốn sách này như Chương 16. Việc phân tích các vấn đề lập trình trong các hạng mục thực chất và tình cờ nảy sinh nhờ Nancy Greenwood Brooks, người đã sử dụng phân tích này.

Phong tục của Addison-Wesley không cho phép tôi bày tỏ lòng biết ơn đối với các nhân viên vì vai trò quan trọng của họ trong việc giới thiệu ấn bản năm 1975. Hai người đóng góp đặc biệt đáng chú ý: Norman Stenton, người là biên tập viên điều hành, và Herbert Boes, người biên tập nghệ thuật. Bose đã tạo ra một phong cách duyên dáng mà một trong những người đánh giá đặc biệt lưu ý: "lề rộng và sử dụng sáng tạo kiểu và bố cục." Quan trọng hơn, anh ấy đã đưa ra lời khuyên quan trọng là hãy đặt một bức tranh về bản thân ở đầu mỗi chương. (Vào thời điểm đó, tôi chỉ có những bức ảnh về Pit Pits và Nhà thờ Reims.) Tôi đã mất cả năm để tìm tất cả các bức ảnh, nhưng tôi vĩnh viễn biết ơn những lời khuyên.

Soli Deo gloria - vinh quang chỉ một mình Chúa!

F. P. B., Jr. Đồi Chapel, Bắc Carolina tháng 3 năm 1995

Theo nhiều cách, quản lý một dự án phát triển phần mềm lớn cũng giống như bất kỳ công việc chính nào khác - nhiều hơn những gì các lập trình viên thường nghĩ. Tuy nhiên, nó khác theo nhiều cách - nhiều hơn những gì mà các nhà quản lý chuyên nghiệp thường giả định.

Quá trình tích lũy kiến ​​thức chuyên môn trong lĩnh vực này đang được tiến hành. Một số hội nghị, cuộc họp tại các hội nghị AFIPS đã diễn ra, một số sách và bài báo đã được xuất bản. Nhưng kiến ​​thức vẫn chưa thành hình khi nó có thể được trình bày một cách hệ thống trong sách giáo khoa. Tuy nhiên, có vẻ thích hợp để cung cấp cuốn sách ngắn này, chủ yếu phản ánh quan điểm cá nhân của tôi.

Sự phát triển chuyên môn của tôi trong lĩnh vực máy tính ban đầu gắn liền với lập trình, nhưng trong giai đoạn 1956-1963, khi các chương trình điều khiển tự động và ngôn ngữ cấp cao được phát triển, tôi chủ yếu tham gia vào kiến ​​trúc máy tính. Khi tôi trở thành giám đốc dự án cho dự án phát triển Hệ điều hành / 360 vào năm 1964, tôi thấy rằng thế giới lập trình đã hoàn toàn thay đổi nhờ những tiến bộ đạt được trong vài năm qua.

Ban lãnh đạo phát triển OS / 360 đã rất hướng dẫn, mặc dù rất khó chịu. Nhóm phát triển, bao gồm cả người kế nhiệm của tôi, F. M. Trapnell, có rất nhiều điều để tự hào. Hệ thống chứa nhiều giải pháp tuyệt vời về thiết kế và chức năng, và đã được áp dụng rộng rãi. Một số ý tưởng, đáng chú ý nhất là vào / ra không phụ thuộc vào thiết bị và quản lý thư viện bên ngoài, đã trở thành cải tiến kỹ thuật và hiện đang được sử dụng rộng rãi. Bây giờ hệ thống này khá đáng tin cậy, đủ hiệu quả và rất linh hoạt.

Tuy nhiên, dự án không thể được gọi là thành công hoàn toàn. Mọi người dùng OS / 360 nhanh chóng trở nên rõ ràng rằng hệ thống có thể tốt hơn đến mức nào. Các lỗi thiết kế và thực thi đặc biệt dễ nhận thấy trong chương trình điều khiển hơn là trong các trình biên dịch ngôn ngữ. Hầu hết những tính toán sai lầm này đề cập đến giai đoạn 1964-65 và do đó nên được quy cho tôi. Hơn nữa, hệ thống ra đời có độ trễ, yêu cầu nhiều bộ nhớ hơn dự kiến, chi phí phát triển cao gấp nhiều lần so với kế hoạch và một vài phiên bản đầu tiên hoạt động không tốt.

"Tháng con người thần thoại hoặc cách hệ thống phần mềm được tạo ra"- một cuốn sách của Frederick Brooks về quản lý dự án trong phát triển phần mềm, chủ đề trọng tâm của nó là việc đưa lực lượng mới vào dự án trong giai đoạn phát triển muộn chỉ làm trì hoãn thời hạn của dự án. Ý tưởng này được gọi là Định luật Brooks. Cuốn sách được xuất bản lần đầu tiên trong năm, đồng thời nó cũng được xuất bản bằng tiếng Nga. Cuốn sách được tái bản dưới dạng một ấn bản năm 1995, cùng với lời bình của tác giả và một tiểu luận mới “Không có viên đạn bạc”. Tại Nga, ấn bản thứ hai được xuất bản bởi nhà xuất bản Symbol-Plus, ISBN 5-93286-005-7.

Những quan sát của Brooks dựa trên kinh nghiệm của anh ấy tại IBM khi quản lý dự án hệ điều hành OS / 360. Để tăng tốc độ phát triển, ông đã cố gắng không thành công trong việc thu hút thêm công nhân vào một dự án đã bị gián đoạn. Nhận thấy xu hướng lặp lại những sai lầm như vậy của các nhà quản lý, Brooks đã chế nhạo gọi cuốn sách của mình là "kinh thánh về kỹ thuật phần mềm": "Mọi người đều đọc nó, nhưng không ai làm theo nó!"

Brooks cũng lập luận rằng việc viết một trình biên dịch Algol sẽ mất sáu tháng - bất kể số lượng người tham gia vào dự án.

Ý tưởng chính

Thần thoại man-tháng

Thời gian thực hiện dự án không tỷ lệ nghịch với số lượng lập trình viên, vì ít nhất 2 lý do.

1. Trong lập trình, không giống như hái bông, chẳng hạn, công việc không thể được chia thành nhiều phần độc lập một cách tùy tiện. Các phần của dự án phụ thuộc lẫn nhau và một số nhiệm vụ chỉ có thể được bắt đầu sau khi các nhiệm vụ khác đã hoàn thành.
2. Các lập trình viên nên dành một ít thời gian của họ để tương tác với nhau.

Nếu có N lập trình viên, thì số cặp lập trình viên là N (N-1) / 2, tức là, khi số lượng lập trình viên tăng lên, thời gian dành cho tương tác tăng theo bậc hai. Do đó, bắt đầu từ một số N, số lượng lập trình viên tăng lên chậm lại thực hiện dự án.

Nếu thời hạn bị bỏ lỡ, việc thuê lập trình viên mới sẽ làm chậm dự án vì một lý do khác: người mới bắt đầu mất thời gian tìm hiểu. Cuốn sách trình bày rõ Định luật Brooks:

Nếu dự án không đạt đúng thời hạn, thì việc bổ sung nhân lực sẽ càng làm chậm trễ hơn.

Với một số lượng rất lớn các lập trình viên, dự án có thể không bao giờ hoàn thành: do sự nhầm lẫn chung, các nỗ lực sửa lỗi hiện có tạo ra các lỗi mới, do đó hệ thống không cải thiện.

Chương trình và sản phẩm phần mềm

Sản phẩm phần mềm khác với chương trình:

• phạm vi tổng quát nhất và loại dữ liệu đầu vào
• kiểm tra nghiêm ngặt, đó là một bước khó khăn ngoài mong đợi
• sự sẵn có của tài liệu chi tiết

Sản phẩm phần mềm đòi hỏi thời gian gấp 3 lần phần mềm.

Hiệu ứng hệ thống thứ hai

Lập trình viên phát triển thứ hai hệ thống, có xu hướng thêm tất cả các tính năng mà anh ta không thể thêm vào hệ thống đầu tiên của mình (do thiếu thời gian). Do đó, hệ thống thứ hai thường bị quá tải với các khả năng.

Khái niệm toàn vẹn

Để đảm bảo tính toàn vẹn về mặt khái niệm của hệ thống, cần phải tách kiến ​​trúc ra khỏi việc triển khai. Một kiến ​​trúc sư trưởng (hoặc một nhóm nhỏ), hoạt động vì lợi ích tốt nhất của người dùng, quyết định những gì nên và không nên đi vào hệ thống. Một ý tưởng "rất hay" có thể bị từ chối nếu tính năng được đề xuất không phù hợp với thiết kế tổng thể của hệ thống. Sự đơn giản là rất quan trọng; có thể hữu ích khi chỉ nhận ra một phần nhỏ các khả năng mà hệ thống có khả năng, bởi vì nếu hệ thống quá phức tạp, một số khả năng của nó sẽ không được sử dụng.

Kiến trúc sư trưởng nên xây dựng các quyết định của mình dưới dạng một hướng dẫn sử dụng.

Tài liệu chính thức

Mỗi người quản lý dự án phải lập một tập hợp nhỏ các tài liệu chính thức mô tả các mục tiêu của dự án, làm thế nào, bởi ai và khi nào chúng sẽ được thực hiện cũng như chi phí của chúng. Những tài liệu này có thể tiết lộ sự mâu thuẫn mà nếu không sẽ khó phát hiện ra.

Mỗi nhóm phát triển nhận được một tập hợp các yêu cầu cho bộ phận của họ trong hệ thống, bao gồm mô tả chính xác về chức năng của nó và các giới hạn về thời gian của bộ xử lý, mức sử dụng bộ nhớ, dung lượng đĩa, v.v.

Sự tương tác

Để ngăn chặn thảm họa, các nhóm phát triển phải tương tác với nhau theo mọi cách có thể. Thay vì đưa ra các giả định về chức năng mà họ đang thực hiện, nhà phát triển nên hỏi kiến ​​trúc sư những câu hỏi làm rõ, vì các giả định có thể sai hoàn toàn.

Hệ thống thí điểm

Trước khi phát triển hệ thống cuối cùng, cần phải phát triển một hệ thống thí điểm. Hệ thống thí điểm sẽ xác định các lỗi thiết kế, sau đó nó phải được thiết kế lại hoàn toàn.

Nhóm phẫu thuật

Sẽ rất hợp lý nếu có một lập trình viên "giỏi" trong nhóm phát triển triển khai các phần quan trọng nhất của hệ thống và một số người khác giúp anh ta hoặc triển khai các phần ít quan trọng hơn. Đây là cách các hoạt động phẫu thuật được thực hiện. Ngoài ra, theo Brooks, những lập trình viên giỏi nhất nhanh hơn những người còn lại từ 5-10 lần.

Tiện ích chuyên biệt

Thay vì mỗi lập trình viên viết các tiện ích của riêng họ, mỗi nhóm phát triển nên có một lập trình viên chịu trách nhiệm viết các tiện ích cho nhóm của họ (ví dụ: một trình tạo mã tạo mã theo một số thông số kỹ thuật). Cũng nên có một nhóm tạo ra các tiện ích cho mọi người làm việc trên một hệ thống nhất định.

Các phiên bản và hệ thống bị đóng băng

Khi hệ thống được xây dựng, yêu cầu của người dùng đối với nó có thể thay đổi, bị ảnh hưởng bởi trải nghiệm của họ với hệ thống chưa hoàn thiện. Những mong muốn này của người dùng cần được tính đến, nhưng chỉ đến một thời điểm nhất định, nếu không công việc trên hệ thống sẽ không bao giờ được hoàn thành. Sau đó, các thông số kỹ thuật bị đóng băng và tất cả các yêu cầu thay đổi tiếp theo sẽ bị hoãn lại cho đến khi công việc trên phiên bản tiếp theo bắt đầu.

Giảm chi phí phát triển

Brooks cung cấp 2 cách để giảm chi phí phát triển phần mềm:

• Chỉ thuê lập trình viên sau khi kiến ​​trúc hệ thống được xây dựng. Nếu không, với thời gian của giai đoạn này, ví dụ, vài tháng, các lập trình viên sẽ không phải làm gì.
• Mua một phần mềm từ các nhà phát triển khác.

Gần đây tôi có đọc lại một cuốn sách đã trở thành kinh điển từ lâu. Tháng con người thần thoại hoặc cách hệ thống phần mềm được tạo ra... 25 năm trước, F. Brooks đã mô tả chính lỗi trong việc tạo hệ thống thông tin... Công việc này vẫn còn phù hợp cho đến ngày nay. Tôi đã viết ra những luận điểm chính của cuốn sách cho chính mình.

Các luận điểm chính của cuốn sách

Vì lập trình viên đang làm việc với những ý tưởng thuần túy, chúng tôi không mong đợi nhiều khó khăn trong việc thực hiện. Nhưng bản thân các ý tưởng của chúng tôi có thể sai - do đó là lỗi trong các chương trình.

Các dự án phần mềm có nhiều khả năng thất bại do thiếu thời gian theo lịch hơn là vì tất cả các lý do khác cộng lại. Các phương pháp ước tính dựa trên chi phí của chúng tôi kết hợp chi phí với kết quả. Tháng người là một ảo tưởng sai lầm và nguy hiểm, vì nó giả định rằng tháng và số người có thể được hoán đổi. Việc phân chia một nhiệm vụ cho một số người sẽ tạo ra thêm chi phí cho việc đào tạo và trao đổi thông tin. Bên cạnh đó, không phải tất cả các nhiệm vụ đều có thể được phân chia. Bạn cần hiểu rằng, 9 người phụ nữ mang thai sẽ không sinh được một đứa trẻ trong một tháng.

Luật Brooks: Nếu dự án không đạt thời hạn, thì việc bổ sung lao động sẽ càng làm chậm trễ hơn. Việc bổ sung nhân lực làm tăng tổng chi phí theo ba cách: lao động vẽ lại các nhiệm vụ và dẫn đến gián đoạn công việc, đào tạo người mới, giao tiếp bổ sung.

Nhóm dự án

Ngay cả trong một nhóm thiết kế lớn, một hoặc hai người cũng cần ủy quyền thiết kế các kết quả để đảm bảo tính nhất quán của các giải pháp nhỏ.

Dữ liệu ICL của Portman cho thấy rằng các lập trình viên toàn thời gian chỉ dành khoảng 50 phần trăm thời gian của họ để viết mã và gỡ lỗi, và phần còn lại của họ bị chiếm bởi các nhiệm vụ bổ sung khác nhau.

Mỗi dự án có hai vị trí lãnh đạo: giám đốc dự án và kiến ​​trúc sư (giám đốc kỹ thuật). Chức năng của chúng hoàn toàn khác nhau và yêu cầu những khả năng khác nhau. Bất kỳ kiểu quan hệ nào giữa hai vị trí này (kể cả một người) đều có thể khá hiệu quả.

Điều cần thiết là người dùng phải đặc biệt chú ý đến những thay đổi đã xảy ra kể từ lần đọc cuối cùng và với những ghi chú về ý nghĩa của chúng.

Điều quan trọng là kiến ​​trúc sư phải trả lời các câu hỏi của người thi công trong các cuộc điện đàm. Bắt buộc phải ghi lại những cuộc trò chuyện này vào nhật ký và đưa chúng vào sự chú ý chung. Ngày nay, email được ưu tiên hơn cho việc này.

Sự miễn cưỡng của các lập trình viên trong việc ghi lại một dự án không phải do sự lười biếng mà từ sự không chắc chắn liệu có đáng để cam kết bảo vệ các giải pháp mà nhà thiết kế biết là “sơ bộ” hay không.

Kiến trúc hệ thống thông tin

Kiến trúc chi tiết và chăm chút không chỉ giúp sản phẩm dễ sử dụng hơn mà còn dễ phát triển và ít lỗi hơn.

Tính toàn vẹn của khái niệm là yếu tố quan trọng nhất cần xem xét khi thiết kế hệ thống. Để đạt được tính toàn vẹn về mặt khái niệm, dự án phải được tạo ra bởi một người hoặc một nhóm người cùng chí hướng.

Tách kiến ​​trúc khỏi quá trình triển khai là một cách hiệu quả để đạt được tính toàn vẹn về khái niệm khi làm việc trên các dự án rất lớn.

Nếu bạn muốn hệ thống có tính toàn vẹn về khái niệm, người ta phải nắm quyền lãnh đạo các khái niệm. Đây là tầng lớp quý tộc không cần một lời xin lỗi.

Trong suốt quá trình thực hiện, kiến ​​trúc sư hệ thống phải luôn cảnh giác để đảm bảo tính toàn vẹn của hệ thống mọi lúc.

Bảo trì hệ thống thông tin

Sản phẩm phần mềm bị đe dọa lỗi thời ngay cả trước khi hoàn thành. Nếu hệ thống không được phát triển, nó sẽ trở nên lỗi thời về mặt đạo đức.

Tất cả các bản sửa lỗi đều có xu hướng phá hủy cấu trúc, tăng entropi và làm mất tổ chức hệ thống. Ngay cả phần đệm điêu luyện nhất của chương trình cũng chỉ trì hoãn khoảnh khắc nó rơi vào trạng thái hỗn loạn không thể cứu vãn, cách thoát ra là phải thiết kế lại từ đầu.

Đôi khi nhu cầu thực sự để cập nhật chương trình, chẳng hạn, để cải thiện hiệu suất, gây ra nhu cầu thay đổi ranh giới bên trong của cấu trúc. Những ranh giới ban đầu thường là nguyên nhân của những thiếu sót tiếp theo.

Sửa một lỗi với xác suất cao (20 đến 50 phần trăm) sẽ tạo ra một lỗi khác. (do kiến ​​trúc bị hao hụt trong quá trình bảo trì).

Sau mỗi lần sửa chữa, bạn cần chạy toàn bộ tập hợp các trường hợp thử nghiệm mà hệ thống đã được thử nghiệm trước đó, để đảm bảo rằng nó không bị hỏng theo một cách nào đó.

Tên: Người đàn ông thần thoại - tháng hoặc cách hệ thống phần mềm được tạo ra.

Cuốn sách này là một ấn bản kỷ niệm (đã được sửa đổi và sửa đổi) của một loại kinh thánh dành cho các nhà phát triển phần mềm trên khắp thế giới, được viết bởi Brooks vào năm 1975. Đồng thời, cuốn sách đã được xuất bản bằng tiếng Nga và từ lâu đã trở thành một tài liệu quý hiếm. Tại Hoa Kỳ, người ta tin rằng nếu không đọc cuốn sách của Brooks thì không một nhà quản lý dự án phần mềm lớn nào có thể thành công. Nếu bạn chưa bao giờ nghe nói về cuốn sách này, bạn có thể tìm kiếm trên Internet các liên kết đến nó (Frederick P. Brooks, The Mythical Man-Month). Mọi thứ sẽ ngay lập tức trở nên rõ ràng với bạn.

Nội dung
Lời nói đầu của ấn bản 1995
Lời nói đầu của ấn bản đầu tiên
Chương 1. Hố Tar
Chương 2. "Tháng đàn ông" thần thoại này
Chương 3. Nhóm vận hành
Chương 4. Chế độ quý tộc, Dân chủ và Kỹ thuật Hệ thống
Chương 5. Ảnh hưởng của hệ thống thứ hai
Chương 6. Lấy từ ra
Chương 7. Tại sao không thể xây dựng Tháp Babel?
Chương 8. Thông báo đòn đánh
Chương 9. Hai trong một
Chương 10. Giả thuyết tài liệu
Chương 11. Lên kế hoạch cho vụ xả súng
Chương 12. Công cụ sắc bén
Chương 13. Toàn bộ và các bộ phận
Chương 14. Thảm họa đang diễn ra
Chương 15. Mặt trái
Chương 16. Không Viên đạn Bạc - Bản chất và Tai nạn trong Kỹ thuật Phần mềm
Chương 17. Phát súng mới "Không có viên đạn bạc"
Chương 18. Những câu nói thần thoại về một tháng đàn ông: Đúng hay Sai?
Chương 19. Người đàn ông thần thoại hai mươi năm sau
Phần kết
Ghi chú và liên kết.

Đạt được sự toàn vẹn về khái niệm.
Mục đích của hệ thống lập trình là tạo điều kiện cho việc sử dụng máy tính. Đối với điều này, các ngôn ngữ và các công cụ khác nhau được cung cấp, trên thực tế, là các chương trình được gọi và điều khiển bởi các khả năng của ngôn ngữ. Nhưng những khoản tiền này lại tốn kém tiền bạc: khối lượng mô tả bên ngoài của hệ thống lập trình lớn hơn từ mười đến hai mươi lần so với mô tả về hệ thống máy tính thực tế. Người dùng dễ dàng đặt bất kỳ chức năng nào đã chọn dễ dàng hơn nhiều, nhưng sự lựa chọn rất lớn và có nhiều tùy chọn và định dạng hơn để ghi nhớ.

Nó chỉ dễ sử dụng hơn nếu thời gian đạt được trong việc xác định chức năng vượt quá thời gian dành cho việc học, ghi nhớ và tìm kiếm sách hướng dẫn. Các hệ thống lập trình hiện đại mang lại những lợi ích như vậy, nhưng có vẻ như trong những năm gần đây, tỷ lệ chi phí - lợi ích đã giảm do kết quả của việc bổ sung ngày càng nhiều chức năng phức tạp. Tôi thường nghĩ việc sử dụng IBM 650 dễ dàng như thế nào, ngay cả khi không có trình lắp ráp hay bất kỳ phần mềm nào.

Tải xuống miễn phí sách điện tử ở định dạng thuận tiện, xem và đọc:
Tải sách Người Đàn Ông Thần Thoại - Tháng Hay Cách Các Hệ Thống Phần Mềm Được Tạo Ra - Brooks F. - fileskachat.com, download nhanh và miễn phí.

Tải PDF
Dưới đây, bạn có thể mua cuốn sách này với giá chiết khấu tốt nhất và giao hàng trên khắp nước Nga.