Wikipedia

Khác biệt giữa bản sửa đổi của “The Mythical Man-Month”

Duyệt lịch sử tương tác
← Thay đổi trướcThay đổi sau →
Nội dung được xóa Nội dung được thêm vào
Trực quanMã wiki
Không có tóm lược sửa đổi
Không có tóm lược sửa đổi
Dòng 10:
}}
 
'''''The Mythical Man-Month: Essays on Software Engineering''''' là một cuốn sách về quản trị dự án phần mềm được viết bởi [[Fred Brooks]], tập trung ở đó là phát biểu "Thêm người vào một dự án đang bị trễ sẽ làm cho nó trễ hơn." Ý tưởng này được biết đến như là [[luật của Brooks]], andcó ismặt presentedcùng along with thevới [[second-systemhiệu effectứng hệ thống thứ 2]] andvà advocacysự ofủng hộ tích cực của [[SoftwareMẫu đầu tiên của phần prototyping|prototypingmềm]]. Lần đầu tiên xuất bản năm [[1975]], sau đó được tái bản như là phiên bản kỷ niệm vào năm [[1995]] (ISBN 0-201-83595-9) với tiểu luận "[[No Silver Bullet]]" và lời chú của tác giả.
 
Những quan sát của Brooks dựa trên kinh nghiệm làm việc của ông tại [[IBM]] khi quản lý dự án phát triển Hệ điều hành [[OS/360]]. Ông đã có một sai lầm khi thêm nhân lực vào một dự án đang bị trễ so với kế hoạch. Ông còn mắc phải một sai lầm khi đánh giá một dự án viết một ngôn ngữ lập trình tên là Algol sẽ cần sáu tháng mà không chú ý đến số lượng nhân lực sẽ tham gia. Khuynh hướng những quản trị dự án lặp lại những sai lầm tương tự khiến Brooks đặt tên cuốn sách là "Thánh kinh của phát triển phần mềm" bởi vì "Mọi người đều đọc nó nhưng không ai làm tương tự"
 
==Ý tưởng==
====TheHuyền Mythicalthoại về Man-Month====
Phân công thêm nhiều lập trình viên vào một dự án đang bị trễ tiến độ sẽ làm cho nó trễ hơn, do thời gian cần thiết để một lập trình viên mới học về dự án, cũng như làm quá tải sự trao đổi thông tin trong nội bộ nhóm. Khi N người phải giao tiếp với nhau, khi N tăng, output M của họ giảm và có thể trở thành âm (<0)(ví dụ: tổng khối lượng công việc còn lại vào cuối ngày lớn hơn tổng khối lượng công việc vào đầu ngày hôm đó, cụ thể là khi nhiều lỗi được tạo ra)
:* Công thức tính khối lượng thông tin trao đổi trong nhóm: <math> n (n - 1)/2 </math>
:* Ví dụ: 50 lập trình viên -> <math> 50 (50 - 1)/2 = 1225 </math> kênh giao tiếp thông tin
 
====TheHiệu Second-systemứng EffectHệ thống thứ 2====
Hệ thống thứ hai hay Hiệu ứng hệ thống thứ hai một kỹ sư thiết kế là hệ thống nguy hiểm nhất mà kỹ sư đó đã từng thiết kế, khi kỹ sư đó hướng tới việc tích hợp chặt chẽ tất cả những tính năng cộng thêm anh ta đã tạo ra nhưng lại không thêm vào hệ thống đầu tiên (do sự giới hạn thời gian). Vậy thì, khi bắt đầu thực hiện hệ thống thứ hai, một kỹ sư nên luôn ghi nhớ rằng anh ta nên nhạy cảm với việc tăng cường nhiều tính năng kỹ thuật.
The [[Second-system effect|second system]] an engineer designs is the most dangerous system he will ever design, since he will tend to incorporate all of the additions he originated but did not add (due to the inherent time constraints) to the first system. Thus, when embarking upon a second system an engineer should be mindful that he is susceptible to over-engineering it.
 
====Progress Tracking====
====Quản lý tiến trình====
Question: How does a large software project get to be one year late? Answer: One day at a time! Incremental slippages on many fronts eventually accumulate to produce a large overall delay. Continued attention to meeting small individual milestones is required at each level of management.
Câu hỏi: Một dự án lớn sẽ trở thành trễ một năm như thế nào? Câu trả lời: Một ngày tại một thời điểm! Việc không giữ đúng thời hạn tăng dần cuối cùng sẽ dồn lại và phát sinh sự chậm trễ lớn. Tiếp tục chú ý để đạt các mốc nhỏ rất cần thiết tại mỗi cấp quản lý.
====Conceptual Integrity====
====Nhận thức về tính toàn vẹn của hệ thống====
To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. A "super cool" idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide '''''fewer''''' features than it is capable of. The point is that if a system is too complicated to use, then many of its features will go unused because no one has the time to learn how to use them.
Để tạo một hệ thống thân thiện với người dùng, một hệ thống phải có một nhận thức toàn vẹn, điều chỉ có thể đạt được bằng cách tách biệt kiến trúc khỏi việc thực thi. Một kiến trúc sư trưởng (hoặc một nhóm nhỏ kiến trúc sư), sẽ hành động như là một user, quyết định cái gì sẽ được để vào và cái gì sẽ được bỏ ra khỏi hệ thống. Một "ý tưởng siêu hạng" bởi một người sẽ không được thêm vào nếu nó không phù hợp với toàn bộ thiết kế hệ thống. Thực tế, để đảm bảo một hệ thống thân thiện với người dùng, một hệ thống có thể có ít hơn những tính năng mà nó có thể có nhưng những tính năng đó đều được cân nhắc thận trọng. Nếu một hệ thống sử dụng quá phức tạp, nhiều tính năng sẽ trở thành vô dụng vì không ai có thời gian để học hỏi nó.
 
====The Manual====
Hàng 54 ⟶ 55:
{{reflist}}
 
==Các tham khảo khácngoài==
*[http://tal.forum2.org/mythman A review by Tal Cohen]
*[http://www.cs.unc.edu/~brooks/ Frederick P. Brooks, Jr. Homepage]
Lấy từ “https://vi.wikipedia.org/wiki/The_Mythical_Man-Month”