| small software development team | can make development more complex and lead to designs that have higher coupling |  |
| is a subtopic of 11.4 - Building Software Engineering Teams | |
| is a kind of software development team | |
| software development team | can be proud of evolving a high-quality product such that it continues to meet the needs of customers | |
| can be assigned to one subsystem of a larger project | |
| can be organized as a hierarchical manager-subordinate structure, as an egoless team, or somewhere in between | |
| can be positively affected by a certain amount of deadline pressure | |
can work faster if- it has good access and rapport with its customers and users
- if the project has a single user or customer
| |
| can work more efficiently if it has skilled management and a mature development methodology that includes such things as quality assurance, risk management, and iterative development | |
| does not have constant size | |
| has optimal team size for a given estimated development effort - doubling the size of a team will not halve the development time | |
| has part configuration management specialist | |
| has part database specialist | |
| has part hardware and third-party software specialist | |
| has part modeller | |
| has part project manager | |
| has part requirements specialist | |
| has part software architect | |
| has part software developer | |
| has part technical writer | |
| has part technology specialist | |
| has part tester | |
| has part user interface designer | |
may be slowed down by - following an ad-hoc approach
- poor access and rapport with the customers
- delays caused by slow or poor decision making
- many customers and users needing time to negotiate decisions and requiring compromises to satisfy everyone
| |
| may often work on legacy system | |
| must coordinate with other software development teams working on the same project | |
| must understand only the overall software architecture, the details of its own subsystem, plus the interfaces to related subsystems | |
| should be sized such that the total amount of required knowledge and exchange of information is reduced | |
| should follow guidelines found in process standards | |
| should include an experienced modeller | |
| should include at least two people capable of performing each role, so that if somebody leaves or is sick, the project is not paralyzed | |
| should not add people to a team if it gets behind schedule, in the hope of catching up because the new people will take time to learn what has been done, and will require support from the other people in the meantime, slowing them down | |
Object Oriented Software Engineering View all facts Glossary Help
