tailieunhanh - Software Engineering A PRACTITIONER’S APPROACH phần 2

sáng tạo khi làm việc trong mô hình khép kín. 2. Mô hình cấu trúc ngẫu nhiên một nhóm lỏng lẻo và phụ thuộc vào sáng kiến cá nhân của các thành viên trong nhóm. Khi sự đổi mới hoặc "Làm việc với những người khó khăn, nhưng không phải không thể." | 62 PART TWO MANAGING SOFTWARE PROJECTS equate Working with people is difficult but not impossible. Peter Drucker XRef The role of the librarian exists regardless of team structure. See Chapter 9 for details. CC and CD teams have been found to produce fewer defects than DD teams but these data have much to do with the specific quality assurance activities that are applied by the team. Decentralized teams generally require more time to complete a project than a centralized structure and at the same time are best when high sociability is required. Constantine CON93 suggests four organizational paradigms for software engineering teams 1. A closed paradigm structures a team along a traditional hierarchy of authority similar to a CC team . Such teams can work well when producing software that is quite similar to past efforts but they will be less likely to be innovative when working within the closed paradigm. 2. The random paradigm structures a team loosely and depends on individual initiative of the team members. When innovation or technological breakthrough is required teams following the random paradigm will excel. But such teams may struggle when orderly performance is required. 3. The open paradigm attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm. Work is performed collaboratively with heavy communication and consensus-based decision making the trademarks of open paradigm teams. Open paradigm team structures are well suited to the solution of complex problems but may not perform as efficiently as other teams. 4. The synchronous paradigm relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves. As an historical footnote the earliest software team organization was a controlled centralized CD structure originally called the .